Benefit Realisation Checkpoint

A programme retires four systems, closes on plan, and is recorded as a success. Eleven months later finance reports run cost unchanged and nobody can say where the saving went. Nothing failed technically. What failed is that success was declared at the last moment the programme controlled, which is the first moment the benefit stops depending on it.

A benefit realisation checkpoint moves verification past that moment and gives it to someone else: a date, an owner outside the delivery team, a baseline recorded before the work started, and one question — did the line move?

Why it matters

A claimed benefit and a realised benefit differ by one decision that the programme cannot make. A licence saving needs notice served before a renewal date. A capacity release needs a hire stopped or contractor days cut. A cost avoidance needs the avoided project to have actually been budgeted. Each of those decisions belongs to a budget holder, and none of them happens because a delivery plan says it should.

The second reason is cumulative. An organisation that never checks cannot calibrate, so after two unverified programmes the next case is discounted by instinct rather than by analysis, which hurts good proposals more than bad ones.

Implementation patterns

• Record a baseline before approval, not at go-live: run cost split by system, the metric with its current value, the headcount doing the work. Without it there is no comparison, only opinion.
• Name the line, the date and the owner for every cash claim in the business case. If no line can be named, the claim is reclassified rather than deleted.
• Schedule checkpoints at +3, +6 and +12 months after go-live, in the governance calendar, owned by the budget holder. One review is enough to catch a missed renewal date; three catch the slower effects.
• End the decommissioning checklist at the contract: notice served, renewal cancelled, support tier reduced, retention obligation discharged. Notice periods are commonly 60 to 90 days ahead of renewal, so the calendar item comes before the shutdown, not after.
• Publish the misses, because a checkpoint reporting only successes stops being information within two cycles, and keep it to one page so it is not delegated back to the programme being checked.

Industry example

Post-implementation benefit review is a standard requirement in public-sector business-case regimes, which is where most of the written practice comes from, and the pattern it exists to catch is visible in production in any large estate: the benefits least often realised are those expressed as staff time released, because the release is fractional and spread across teams so no budget line changes. The mechanism is identical wherever a programme grades its own homework — the review that matters is the one held 6 to 12 months after go-live by the person whose budget was supposed to fall.

Failure scenarios

• The programme owns its own checkpoint, reports green, and the money never appears.
• No baseline, so the review degenerates into whether people feel things are better.
• Fractional capacity counted as cash: four teams each releasing 0.4 FTE produce 1.6 FTE on paper and nothing in any budget.
• A retired system that keeps billing because the contract auto-renewed.

Trade-offs

The real cost is political. The practice produces documented misses, and an organisation that punishes them gets accurate reporting exactly once, so it has to be introduced as a way of improving estimates.

When not to use it

When the work was never justified by a benefit number. Removing an unsupported platform before an audit, or reducing a concentration of risk, should be checked against that objective; forcing a cash review onto it produces a false negative and teaches the wrong lesson. Check what was claimed.

When the benefit is immeasurable at reasonable cost. If separating the effect from seasonality and three other changes costs more analyst time than the benefit is worth, say so and commit to a leading indicator instead. A checkpoint on a number nobody can compute is theatre.

Interview question

Q: You signed a business case claiming £1.2m of annual savings from consolidation. The programme delivered on time and finance says run cost is flat. Walk me through what you would check, in order, and what you would change for the next case.

What a strong answer covers: splitting the claim into cash, capacity and avoided cost and checking each differently · renewal dates and whether notice was served · whether fractional capacity was ever converted · the missing baseline, which is why it took eleven months to notice · and refusing to restate the claim as a success by redefining the benefit.

Quick check

Quiz: A consolidation switches off four systems in month seven of a twelve-month term. What has been saved? Nothing yet, and nothing at all if notice was not served 60 to 90 days before renewal, because the term keeps billing and then auto-renews.

Flashcard: What has to be true before a benefit counts as realised? — A named budget line moved, on a named date, verified against a pre-recorded baseline by an owner outside the delivery team.