By Ritvars Mētra, Founder of ReadinessCompassThe business case listed fourteen benefits. At closure, the programme reported that the capability enabling all fourteen had been delivered, which was true.
Two years later nobody can say whether any of them arrived. Not because the answer is bad, but because no one was accountable for finding out, and there was never a baseline to compare against.
The structural problem
A programme is measured on delivery and closes at go-live plus a few months. Benefits accrue to operational budgets over two to five years. The entity that promised the benefit therefore does not exist when it is due, and the entity that would receive it never agreed to it.
Markus and Tanis describe this phase — onward and upward — as the period during which the business realises benefits from the system, if any, and list post-implementation investment audit and continuous business improvement among its typical activities, noting that these are often not performed. They also identify, as a common error of the phase, not assessing system-related outcomes on a routine basis.
So the failure is well documented and structural rather than negligent. It is what happens by default when nobody has been made accountable for a number that falls due after the accountable body has dissolved.
Four things a benefit needs to survive
| What it needs | Why | Usual state |
|---|---|---|
| A named business owner | Someone whose own performance is affected by whether it arrives | Owned by the programme, which will not exist |
| A baseline measured before go-live | Without it, no claim can be evidenced or refuted | Estimated retrospectively, which is not a baseline |
| A date and a measurement method | Benefits with no due date are never overdue | “Over the first three years” |
| A place it lands | A budget line reduced, a hire not made, a target raised | Nowhere — which is why nothing changes |
The fourth row is the uncomfortable one and the most diagnostic. If a benefit is real, some budget, target or headcount plan should change because of it. If nobody’s numbers move, the organisation has not actually decided to take the benefit — and it will be quietly consumed by absorbing other pressures.
This is also the test that distinguishes a benefit from an improvement. “Twenty per cent less time on invoice processing” is an improvement. It becomes a benefit when someone decides what happens to that time.
Assurance asks this before go-live, not after
The Gateway readiness review treats benefit viability as a gate condition. Among the stated purposes of Gate 4: Readiness for service are checking that the final business case is still valid and unaffected by internal and external events, and checking that the original projected business benefit is likely to be achieved.
That question is asked at the moment the organisation still has leverage — before the system is live and the team disperses. Asking it two years later is an audit; asking it before go-live is governance.
Write the profile while the programme still exists
A benefit profile is a short document per benefit, and it takes about an hour each. It should state:
- The owner, by name and role, who has agreed in writing.
- The measure and its current value, taken before go-live.
- What has to be true for it to arrive — usually a behaviour, not a system state. This is the dependency programmes leave out, and it is where benefit leakage begins.
- When it is due, and who will check.
- Where it lands in someone’s plan.
The third item is the one that makes the document honest. A benefit that depends on people using the system rather than a spreadsheet has an adoption dependency, and stating it converts a financial claim into something the organisation can actually manage.
Expect a smaller, truer number
Done properly, this exercise usually reduces the headline benefit figure, because several claimed benefits turn out to have no owner willing to take them into their plan.
That is not a bad outcome. A business case of four benefits with named owners, baselines and landing points is worth considerably more than one with fourteen that nobody will be asked about — and it is the only version under which anyone can later say, with evidence, whether adoption actually caused the benefit.
More on benefits and adoption evidence in the Adoption Risk Hub, or read who owns the process after the programme closes.