The project was delivered on time, to budget, in full — and the savings never appeared. Both statements are true, and only one of them was anyone's job.
Every organisation has at least one of these. A system went live successfully. A process was redesigned and rolled out. A facility was commissioned and handed over. The project closure report was positive, the team was thanked, and the business case promised an improvement that, two years later, nobody can find in the numbers.
What follows is usually an investigation into the project. This is almost always the wrong place to look. The project did what projects do: it produced an output. The benefit required something else — a change in how people work, what they stop doing, how many of them there are, or what the organisation charges — and that change was nobody's assigned responsibility once the project team disbanded.
Benefits do not leak during delivery. They leak in the quiet months afterwards, when the capability exists and the behaviour has not changed.
The Strategic Context
The distinction that matters is between output, outcome and benefit.
An output is what a project produces: the system, the plant, the trained staff, the redesigned process. It is tangible, it can be inspected, and its delivery can be verified on a date.
An outcome is the change in how the organisation operates once the output is in use: orders are processed without manual re-entry; maintenance is scheduled against condition rather than calendar; quotes are produced in a day rather than a week. Outcomes are behavioural and take time to establish.
A benefit is the measurable value that follows from the outcome: reduced cost, increased margin, improved availability, avoided risk. Benefits are financial or operational consequences, not activities.
The project delivers the output. Only the receiving part of the business can produce the outcome. And the benefit is a consequence of the outcome, not of the output — which means that a project can discharge its accountability completely while the benefit fails entirely, with no one having done anything wrong.
That gap is a governance design problem, and it can be closed at approval rather than discovered at review.
What Leaders Commonly Misread
That the project manager owns the benefit. They cannot. A project manager has no authority over how an operational area works six months after handover, no control over its headcount, and typically no presence in the organisation by then. Assigning benefit ownership to the project is a way of appearing to assign it while ensuring it is never exercised.
That benefits are realised on a date. Benefits accrue over a period, usually beginning some months after the output is in use, often following a temporary dip while people learn. A benefits plan that shows value starting in the month after go-live is describing a hope.
That measuring the benefit is the same as owning it. Finance can measure. Measuring does not cause the operational change, and a monthly report showing the benefit not arriving is not an intervention.
That the business case is a forecast. In practice it is a negotiation artefact, prepared by people who need approval, reviewed by people who want the initiative to proceed. Treating it afterwards as a commitment — the numbers someone will be held to — changes how it is written, which is precisely the point. [Related article: Evidence Standards for Executive Decisions]
That if the benefit is enabling rather than financial, ownership matters less. It matters more, because enabling benefits have no automatic accounting trail and will simply never be checked unless someone is named.
Reframing the Issue
Treat every expected benefit as a claim made by a named business owner about a change they will make, not as a projection made by a project about an effect that will occur.
This single reframing changes the wording of the business case. Instead of:
The new scheduling system will reduce planning effort by 1.2 FTE.
the claim becomes:
The Operations Manager will reduce the planning team from seven to six roles by the end of Q3 following stabilisation, contingent on the system achieving 95% automated schedule acceptance. Verified by: establishment report and schedule acceptance rate.
The second version is harder to write, will be resisted, and is the only one that can actually be realised. It names the person, the action, the timing, the condition and the evidence. It also makes visible something the first version conceals: that the benefit requires a decision by someone who has not yet agreed to make it.
If no one will sign the second version, the benefit is not real and the business case should be reduced accordingly. That conversation is far cheaper before approval than two years after.
The Handover Gap
Between project closure and benefit realisation lies a period of three to eighteen months in which the organisation has the capability but not yet the outcome. This period has predictable characteristics and is almost never resourced.
Productivity typically falls before it rises, because people are working in an unfamiliar way while still carrying their normal load. Workarounds appear, are locally rational, and quietly preserve the old process inside the new system. The old way remains available, because switching it off felt risky at go-live, and so it is used whenever the new way is inconvenient. Support demand peaks at the moment the project team has been released. Reporting reverts to operational measures, and the benefit measures — which were project measures — stop being produced.
Each of these is manageable. None of them is managed by default, because the project is closed, the program has moved on, and the operational area has absorbed a change on top of its existing accountabilities without additional capacity.
The most effective single intervention is also the least expensive: retain a small, named capability for a defined post-implementation period, with explicit authority to switch off the old path. Turning off the alternative is what converts adoption from a preference into a fact.
Decision Framework
Use this at investment approval, not at closure.
1. The named-owner test. For each benefit, is there a business owner, by name and role, who has read the claim and accepted it? Acceptance means they agree to the action, the timing and the measure. An unaccepted benefit is removed from the case.
2. The behaviour test. What will people do differently? If the answer is only "use the new system", no benefit will follow — using a system is an activity, not an outcome. The answer must describe something that stops, reduces, accelerates or is priced differently.
3. The switch-off test. What existing process, system, role or cost will be discontinued, and on what date? Benefits that depend on something ending are realised only when that thing actually ends, and the date should appear in the plan with an owner against it.
4. The evidence test. What measure will show the benefit, where does it come from, who produces it, and will it still be produced twelve months after the project closes? A measure that only exists while the project exists will not survive it.
5. The stabilisation test. How long is the dip, how will it be supported, and who carries the additional load during it? If the answer is "the operational team, on top of everything else", expect the workaround.
From Strategy to Execution
Immediately. Review the benefits sections of the three largest initiatives currently in flight. For each benefit, identify the named business owner. Where there is none, or where it is the project, that benefit is currently unowned — take it to the sponsor as a decision, not as a finding.
Over one to two quarters. Change the investment approval template so that benefit claims are written in the owner's voice and signed by the owner. Add a mandatory switch-off schedule for any benefit that depends on discontinuation. Establish post-implementation benefit review at a fixed interval after closure — six and twelve months are common — held by the portfolio authority rather than the project, with the business owner presenting.
Over one to three years. Connect benefit ownership to how leaders are measured. As long as delivery is assessed on outputs and operations is assessed on run performance, nobody's objectives contain the outcome, and the gap will persist regardless of process. This is the structural fix and the slow one. [Related article: Closing the Learning Loop: Post-Project Review That Changes Behaviour]
Signals to Monitor
- Old processes still running six months post go-live. The single most reliable predictor of benefit shortfall.
- Benefit measures no longer being produced. Measurement stopped with the project; the benefit is now unobservable.
- Headcount reductions repeatedly deferred. Usually for defensible short-term reasons, and cumulatively fatal to the case.
- Support volumes not declining after stabilisation. Adoption has not occurred; people are being helped to work around rather than to work differently.
- Business owners unable to state their benefit claim from memory. A reliable indicator that they never owned it.
- Post-implementation reviews consistently scheduled and cancelled. The organisation has decided, without deciding, not to find out.
- Benefits re-forecast rather than reported. The claim is being adjusted to the outcome rather than the outcome being pursued.
Questions for the Leadership Team
- For our three largest initiatives, name the individual accountable for each benefit. Would they recognise the claim if we read it to them?
- Which processes or systems are we committed to switching off, and on what dates? Who owns those dates?
- What happened to the benefits of the initiative we closed eighteen months ago — and how do we know?
- Are the measures that prove our benefits still being produced after the project teams disband?
- Who carries the additional operational load during stabilisation, and have we funded it?
- Do any of our executives have a benefit outcome in their objectives, or only delivery and run performance?
- If a benefit does not materialise, what happens — to the initiative, and to anyone?
Closing Perspective
Delivery is the part of value creation that organisations have learned to manage well. It has methods, professionals, standards and visible accountability. Realisation has almost none of these, which is why value routinely survives the difficult part of the journey and is lost in the easy part.
The correction is not a new framework. It is the discipline of refusing to approve a benefit that no one will sign for, and then behaving as though that signature means something. Most organisations already know who should own each benefit. What they avoid is the conversation in which that person is asked, in advance and in writing, whether they will.
That conversation is the cheapest risk control available in the entire investment lifecycle, and it is skipped almost every time — because it is the moment when an attractive business case can become a smaller one.
This concludes the series From Strategy to Benefit. Begin at [Related article: Strategy Is a System of Choices, Not a Document].