Between 2019 and 2024 we were given access to 62 transformation business cases and the post-implementation reviews that followed them, across insurance, manufacturing, healthcare and public sector. Forty-one of the programmes delivered less than 60% of the benefit they projected. Only nine exceeded their case.
The interesting finding is not the failure rate — that is well documented. It is where the failure originates.
The benefit was real. The capacity to capture it was assumed.
In 47 of the 62 cases, the underlying opportunity was correctly identified and correctly sized. The technology was, in the main, delivered. What did not happen was the operating change required to convert the capability into money.
A claims platform that enables straight-through processing does not produce straight-through processing. It produces the option to process straight through, which is realised only if the underwriting rules are rewritten, the adjuster incentive structure stops rewarding manual touch, and someone has the authority to decide which claims are allowed to bypass review.
The business case priced the software. The benefit depended on the decisions.
Three patterns that predicted the gap
Across the sample, three characteristics separated the programmes that realised their case from those that did not.
1. The case named a decision owner, not a project sponsor
Programmes where each benefit line had a named executive who owned the operating decision — not the delivery — realised 84% of projected benefit on average. Where benefits rolled up to a programme sponsor, the average was 51%.
2. Benefits were tracked against the P&L, not the programme
Twenty-two programmes tracked benefit realisation inside the programme's own reporting. Nineteen of those closed before the benefit was measurable, and the tracking stopped with them. The programmes that survived contact with reality had their benefit lines written into departmental budgets before go-live, which meant somebody's targets moved.
3. The operating model change was sequenced first
This is the counterintuitive one. Programmes that made the process and authority changes before the technology landed outperformed those that sequenced technology first by a factor of roughly 1.7 on realised benefit — despite the process change being harder to do without the new system.
The explanation offered most consistently in the post-implementation interviews was that changing process first exposes which parts of the benefit case are actually deliverable. When the system arrives first, the organisation configures the system to preserve the existing process, and the case quietly evaporates.
What we changed in our own practice
Three things, none of them complicated.
We now refuse to write a benefit line that does not name an individual and a budget line it will land in. We run the operating-model design ahead of the build rather than in parallel with it. And we contract for a 90-day benefits review after handover, against the original case, with the results shared with the board whether or not they flatter us.
The last one has cost us two follow-on engagements. It has also produced the most candid client relationships in the firm.