Benefits realisation after project closure

Try this. Pick a project your entity closed two years ago, find the business case, read the benefits section out loud, and ask who has measured it since.

You already know how that goes. The question is why, and the answer is more structural than most people assume.

What is benefits realisation, and why does it stop at closure?

Benefits realisation is the practice of measuring whether the outcome a project promised actually arrived, in the units it was promised in, after the project has finished. It is a separate question from delivery. A project can deliver everything in its scope, on time and within budget, and produce no benefit at all.

Almost every organisation performs the first half of this well and the second half not at all. Benefits are forecast carefully at approval, when the forecast is what wins the funding. They are then measured on the one date when measurement is impossible, the closure date, before anything has had time to change. After that, nothing.

This is the largest credibility gap in portfolio governance and it is unusual in being widely known. Ask anyone in a strategy office whether their closed projects delivered their forecast benefits and you will get a candid answer, often a wry one.

Why do benefit forecasts stop being measured?

Four mechanisms, and they compound.

The team disbands. The project manager who wrote the business case moves to the next programme within weeks. The people who understood how the forecast was built, which assumption carried the saving, what else had to be true, are dispersed. Six months later, when the benefit could finally be measured, nobody left knows what to measure.

The budget ends at closure. A project’s funding covers delivery. Measurement twelve months later has no cost code, so the effort has to be donated by a function that was never asked. Work with no budget line loses to work that has one.

The measure was never specified tightly enough. “Improved processing efficiency” cannot be tested. “Median permit processing time falls from 14 days to 6 days, same case type, twelve months after go-live” can be tested by anyone, including someone who has never heard of the project. The vagueness is not accidental. A vague forecast is easier to approve, and both the author and the approver know it.

Nobody is uncomfortable. No individual is accountable after closure, so no individual is exposed when the benefit fails to arrive. This is how the same saving gets promised by three consecutive programmes: the earlier promise stopped being tracked the day its project shut down, so there is nothing to check the new one against. Nobody is lying. Nobody is checking.

Appraisal guidance has known about the first-order version of this for a long time. The UK Treasury’s Green Book requires an explicit optimism bias adjustment for exactly this reason, and several regional frameworks borrow the idea. What the adjustment cannot do is verify itself afterwards.

What is a benefit register?

The record that keeps every promised outcome alive independently of the project that promised it. A benefit is only a handful of fields, and each has to be present before approval rather than after.

The statement. What will change, as a direction and a quantity. Not an aspiration.

The measure. Which KPI shows it, in which unit, with a baseline value and the date the baseline was taken. If the benefit cannot be pointed at an existing measure, either you create the measure before approval or the benefit is not real. Say that out loud in the appraisal meeting; it works better than it sounds.

The profile. When the change is expected and at what rate. Most benefits do not switch on at go-live, and a saving that ramps over three quarters should be recorded as ramping, so a flat reading at month three is understood rather than escalated.

The accountable individual. A named person who will still hold their role after the delivery team is gone, with the date their accountability starts. Usually closure, not approval.

The measurement dates. Fixed points at which the actual gets taken and compared, scheduled in advance so they do not depend on anyone remembering.

The source initiative. So a pattern of optimistic forecasting becomes visible at the level of a sponsor or a department rather than one project at a time.

The status history. Each measurement, and each forecast revision with its reason and the name of whoever made it. Revising downward on evidence is legitimate governance. Revising quietly is not, and the difference is entirely the name.

MSP and PMI’s benefits realisation guidance both describe versions of this artefact. The register is the list a committee should be able to open at any time and read as one question: of everything we have paid for, what did we say would change, and what changed.

Why measure for 24 months after closure?

Because the interesting period starts after the attention stops.

Most benefits are not observable at closure. A new system goes live and processing times get worse for a quarter while people learn it. A procurement reform produces its saving in the following contract cycle. A measurement taken at closure, or three months after, will often show the opposite of the truth.

Twenty-four months is long enough to see a benefit ramp and then hold, which is the distinction worth having. Plenty of benefits appear on schedule and then decay. The process reverts. The headcount returns under a different label. The manual workaround comes back, because nobody owns the new way of working. A benefit measured once at month twelve and declared realised records the peak and misses all of that. It is also long enough to catch leakage in the quiet quarters, when there is no project team left to notice.

Twenty-four months is a discipline rather than a natural law. Some benefits settle at twelve. Infrastructure and major reform need longer. What matters is that the window is set deliberately at approval and outlasts the optimism that produced the forecast.

The part nobody has solved

Attribution.

Eighteen months after closure your permit processing time has fallen from 14 days to 7. Your project promised 6. Did the project cause it? Partly, probably. Also relevant: a staffing change in the department, a drop in application volume, a policy amendment that removed an approval step. There is no counterfactual. You do not get to run the two years again without the project.

This is not something you can engineer your way out of, and anyone offering clean attribution across a two-year window is overstating what the data carries. Statistical approaches exist and they want comparison groups and stable conditions a single portfolio rarely provides.

So what is a register worth if attribution is unavailable? It shows whether the promised change happened at all, which is a lower bar than causation and still eliminates most bad business cases. And it forces the argument to be had, in front of people, by an owner who has to say in their own words why the number moved.

Who should own a benefit?

Not the project manager. Not the programme. Not the PMO.

Give it to the person accountable for the operational area where the change is supposed to show up. The head of the service whose processing time should fall. The finance owner of the budget line where the saving should appear. The working rule: pick someone who would notice the benefit failing to arrive even if nobody had asked them to look.

That owner is usually not involved in delivery, so they have to be named and have to agree the number before approval. A benefit assigned to an operational head after closure gets disputed rather than measured, and they will be right to dispute it.

Make it a role plus a person, so accountability transfers when the individual moves. And make sure the measure exists independently of the owner. If the only source of the actual is the owner’s own assertion, your register holds an opinion.

The PMO holds the register, schedules the measurements and escalates divergence. It does not own the benefits. A PMO that owns benefits owns everything and is accountable for nothing.

Common questions

When should a benefit first be measured?

At the point set in the benefit profile, which is usually not at closure. For most operational benefits the first meaningful reading falls six to nine months after go-live, once the transition period has passed. Read it earlier and you get a number that gets argued about instead of acted on.

What if the benefit did not arrive?

Record it, with the reason, and keep the entry open. A benefit that did not arrive is more useful to the next business case than one that did, provided the record survives. The failure to avoid is quietly closing the entry, which removes the only evidence that the forecast was optimistic.

How is a benefit different from a KPI?

A KPI is a standing measure of something you care about; it exists whether or not any project is running. A benefit is a specific, time-bound claim that one investment will move that KPI by a stated amount by a stated date. Benefits are measured on KPIs, which is why a benefit whose KPI does not yet exist cannot be measured at all.

Where this comes from

We build TruMandate, a portfolio governance platform for government entities and large enterprises in the UAE and Saudi Arabia, which keeps each benefit attached to the KPI it promised to move for two years past closure. The argument above is why.