The Most Valuable Technology Project May Be the One You Don't Start

Every technology project has a visible cost and an invisible one. The visible cost is the budget. The invisible one is attention — the management time, the meetings, the decisions deferred elsewhere, the disruption to people who were doing something else, and the maintenance obligation that begins on the day it launches and never ends.

Budgets are finite and everybody knows it. Attention is finite and almost nobody accounts for it. That asymmetry is why organisations end up with more initiatives than they can complete, all moving slowly, none finishing well.

What a project actually consumes

Management attention. Every project needs someone senior to make decisions and unblock it. That capacity is small and does not grow. Three concurrent projects usually means three projects each receiving a third of the attention needed.

Staff attention during change. People being trained, adapting, working around a transition. This is real capacity, temporarily removed from the work that generates revenue.

Permanent maintenance. Once live, something must be monitored, updated and supported. Every launch increases the fixed operational load of the business. This obligation is almost never in the business case.

Option value. A project commits you to a direction. Six months later a better opportunity appears and you are mid-implementation. Not starting preserves the ability to choose.

Institutional patience. Each initiative that ships late or disappoints reduces the appetite for the next one. Spending this on a marginal project makes an important one harder to get approved.

Projects that should not start

Some patterns are recognisable early.

The solution looking for a problem. It begins with a technology rather than a difficulty. "We should be using AI for something" is the modern version; every era has had one.

The project justified by feelings rather than numbers. "It would be more professional", "our competitors have one", "it looks dated". These may be true and are not measurable, which means success cannot be assessed and the project cannot be stopped.

The one that requires a behaviour change nobody has agreed to. Systems that only work if staff consistently do something new need that agreement secured first. Many implementations are technically successful and operationally dead because the behaviour never changed.

The one with no owner after launch. If you cannot name the person who will be responsible in a year, the honest forecast is abandonment.

The one whose real purpose is to avoid a conversation. Software introduced so that a difficult conversation about roles or accountability does not have to happen. The conversation still has to happen, and now it happens during a rollout.

The one nobody can describe in a sentence. Vague scope means unbounded scope.

The one being done because it is already budgeted. Money allocated last year for a need that has changed. Handing it back is a good outcome, and it is rarely how it plays out.

Declining well

Refusing a project badly damages the relationship with whoever proposed it and produces a worse decision than agreeing would have. A few things help:

Take the underlying problem seriously. Almost every proposal has a real difficulty behind it, even when the proposed solution is wrong. Address the difficulty; that is what the person actually wants.

Be specific about the constraint. "Not this year, because the operations change is consuming all the capacity we have to absorb" is a reason people can accept. "It is not a priority" is not.

Offer the smaller version. Frequently eighty per cent of the value is available for five per cent of the cost — a manual process, a report run monthly, a rule change. Propose that.

Say what would change your mind. "If enquiry volume goes past X, this becomes worth doing." Now it is a deferred decision with a trigger, not a rejection.

Write it down. A short record of what was considered and why it was declined prevents the same proposal returning every six months as though it were new.

Keeping the discipline

Maintain one list of active projects, with a hard limit. The limit is the point; a list of everything under way is a queue, not a plan. Starting something means finishing or stopping something else.

Include a maintenance estimate in every business case. Ongoing hours per year, and whose. This alone eliminates a share of marginal proposals.

Hold a stopping review. Periodically ask of each active project whether you would start it today knowing what you now know. Projects are stopped far too rarely, mostly because stopping feels like failure and continuing feels like commitment.

Keep a list of what you deliberately did not do, with the reasoning. It is a useful document, it prevents relitigating, and it is a fair record when someone asks later why something was not addressed.

The most experienced technology advisers spend a good portion of their time talking clients out of things. That is not caution; it is recognising that a business's capacity for change is its scarcest asset, and that spending it on the wrong project costs far more than the invoice.