A nine-month consolidation retired four systems and released about 0.4 FTE of support effort in each of four teams. The programme closed as a success, verified by the delivery plan. Eleven months after the business case was signed, finance reports run cost unchanged and the £1.2m annual saving nowhere in the ledger. What failed, and which decision made it possible?

The trigger

Nothing failed technically. The four systems are off, the traffic moved, no incident was caused. The failure is that the business case counted three kinds of benefit as if they were one kind, and only one of the three lands without a further decision by somebody outside the programme.

Why nothing landed

• Licences and hosting were cancelled in the plan, not in the contracts. Enterprise agreements end at renewal dates, and a system switched off in month seven of a twelve-month term keeps billing until the term ends, then auto-renews if nobody sends notice. Decommissioning is a procurement action with a calendar deadline, and the deadline is usually 60 to 90 days before renewal.
• 0.4 FTE released in four places is not 1.6 FTE saved anywhere. Fractional capacity in different teams cannot be summed and then removed; it is absorbed within days by the work each team already had waiting. It is real, and it is not a saving until one named decision converts it: a stopped hire, a reduced contractor count, or a documented reallocation to work that was otherwise going to be funded separately.
• The avoided cost of the old platform's next upgrade was counted at full value, although it depended on a future decision that nobody had made.

The decision that made all this possible was declaring success on delivery. The programme's definition of done was "the systems are off", which is the last thing the programme controls and the first thing that stops mattering.

Why detection lagged

There was no baseline. Run cost was never split by system before the work started, so there is no comparison that could have shown the saving arriving or not arriving. Finance saw one blended infrastructure line that also absorbed growth elsewhere, which is why eleven months passed before anybody could say anything definite. A benefit you cannot see arriving is indistinguishable from one that never arrives, and the difference matters for the next business case, which will now be disbelieved.

The structural fix versus the tempting local fix

The tempting fix is a benefits-tracking spreadsheet owned by the programme. It produces a green status and no money.

The structural fix is three things, all cheap:

1. A named budget line and a date for every claimed saving, agreed with the budget holder before funding is approved. If no line can be named, the benefit is not cash and must be written as what it is.
2. A benefit owner outside the delivery team — usually the budget holder — who is asked at fixed checkpoints, typically +3, +6 and +12 months after go-live, whether the line moved.
3. A decommissioning checklist that ends at the contract, not at the shutdown: notice served, renewal cancelled, support dropped to the reduced estate, data retention obligation discharged.

Common weak answers

• "The savings were overstated to get approval." Sometimes true and usually not the mechanism. Here each number was defensible on its own terms; what was missing was the conversion step.
• "Add a benefits realisation stage gate to the governance framework." A gate the programme reports through is the same failure with more paperwork. The question has to be asked of someone who does not benefit from the answer being yes.

When this is the wrong answer

When the work was never justified by savings. Consolidation done to reduce a concentration of risk, or to remove an unsupported platform before an audit, should be measured against that objective, and forcing a cash benefit onto it produces a weak case and the wrong checkpoint. Say which kind of benefit you are claiming, and measure the one you claimed.