Every business case has a benefits table, and almost every benefits table is fiction by the time the programme closes. Not because anyone lied at the outset, but because the number was built to win approval rather than to survive an audit. It borrowed an optimistic baseline, assumed full adoption from day one, and attributed to the programme every improvement that happened to occur while it was running.
This matters more than it used to. Boards that once tolerated vague benefit stories are now asking finance to trace the number back to source data, and finance teams that once nodded through transformation cases are increasingly the ones killing the next round of funding because the last one did not deliver what it promised. The credibility of the entire function depends on getting this right.
The baseline problem
A benefit is a difference between two states, and the state you started from determines everything about the number you can claim. Programmes routinely set the baseline at the worst point in recent history, so that any improvement looks dramatic, or they set it at a point before a separate initiative had already started fixing the same problem, so the new programme claims credit for someone else's work.
The discipline that actually holds up is boring: freeze the baseline before the programme starts, document exactly how it was measured, and have someone outside the programme team sign off that it is fair. If that step feels like an obstacle, it is usually because the baseline being proposed would not survive it.
A benefit is a number someone is willing to defend a year later, in front of the people who paid for it. Everything else is a forecast dressed up as a fact.
Attribution is the part everyone skips
Costs go down and revenue goes up for many reasons at once: seasonality, market conditions, other initiatives, simple noise in the data. A credible benefits case isolates what the programme itself plausibly caused, and says so explicitly rather than claiming the whole movement.
This is uncomfortable because it usually shrinks the headline number, sometimes by half or more. That is the point. A shrunk number that survives scrutiny is worth more, politically and financially, than a large number that gets quietly abandoned in the next planning cycle.
- 路Separate the change the programme drove from changes that would have happened anyway
- 路Where multiple initiatives touch the same metric, agree attribution shares before results land, not after
- 路Treat unexplained variance as unexplained, not as evidence in your favour
- 路Re-test attribution once external conditions shift, rather than defending the original split indefinitely
Someone has to sign
The most reliable filter for a benefits case is a name. If a finance business partner, an operations director or a named budget holder is prepared to put their name against the number and answer for it at year end, the number tends to be real. If the number belongs to the programme team alone, it tends to evaporate quietly once the programme closes and nobody is left to defend it.
This is why the strongest transformation offices insist on benefit ownership sitting with the business, not with delivery. Delivery can build the capability; only the business can decide whether it changed how work actually gets done, and only the business can be held accountable for banking the saving in next year's budget.
Building a case that survives a hostile reading
Write the benefits case as if a skeptical finance director will read it looking for holes, because eventually one will. State the baseline, the measurement method, the attribution logic and the assumptions in plain language, and flag the assumptions that are most likely to be wrong.
A case that admits its own uncertainty is more credible than one that pretends to precision it does not have. Ranges, not false point estimates, are usually the honest answer, and honesty here is what buys the trust needed for the next investment case.
None of this is exotic. It is the same discipline that finance applies to every other capital decision, applied consistently to technology and transformation spend instead of being waived because the topic feels technical. The organisations that get better at this over time are not the ones with cleverer benefit models; they are the ones willing to have the uncomfortable baseline conversation before the case is approved rather than after it fails.
Get that sequencing right and the benefits case becomes a genuine management tool rather than a piece of theatre performed once to secure funding. Get it wrong and you simply add one more discredited number to a pile that makes the next case harder to sell.