A project normally closes when its outputs are delivered: a working system, a finished building, a newly approved procedure. But the budget was approved on the strength of an expected benefit, such as a faster service or lower cost, and that usually appears only after closure.

When the UK National Audit Office (NAO) reviewed projects that had left the Government Major Projects Portfolio, it found that most had delivered their planned scope, but it was unclear whether they had achieved their intended outcomes, and there was no figure for how much of the expected benefit had been realised. ^[4] The same pattern recurs in any organisation that does not decide who tracks benefits once the project ends.

That is why the UK Government Functional Standard for project delivery (GovS 002) requires benefit tracking to be handed over at closure to, and accepted by, the appropriate business authority, and the sponsoring body to ensure a review of benefits realisation and operational performance against the business case. ^[1]

How do you tell outputs, outcomes and benefits apart?

The UK Infrastructure and Projects Authority (IPA) guide defines a benefit as the measurable improvement resulting from an outcome that one or more stakeholders perceive as an advantage, and which contributes to one or more organisational objectives. ^[2]

To illustrate: launching an online services portal is an output. Customers using it instead of visiting in person is an outcome. Less time spent by customers completing the service is a benefit. Write down the mechanism that links them, such as fewer incomplete requests being returned, and the assumptions it depends on, such as take-up of the new channel and the support team’s capacity to respond.

Record disbenefits too: measurable declines, caused by the project itself, that some stakeholders see as negative. They are not risks that may occur but expected consequences, identified and measured in the same way as benefits. ^[2]

Who owns the benefit after closure?

The UK standard requires each discrete benefit to be assigned to an owner responsible for forecasting and monitoring it. ^[1] The IPA guide explains that the benefit owner represents the business, not the project; is identified early, confirmed and formally handed over before closure; and is responsible for tracking, reporting and addressing any shortfall. It suggests recording the transfer in a handover certificate signed by the project’s senior lead and the benefit owner. ^[2]

UK government benefits assurance reviews explicitly ask, before go-live, who will be responsible for benefits once the project moves into business as usual and how responsibility will transfer from the project team. ^[3] If there is no answer to that question before closure, there is unlikely to be one afterwards.

What goes into the benefits register?

The benefits register lists planned benefits, each with its owner, timing, measurement method, baseline and current value. Each benefit also has a profile setting out its measure, baseline, target, measurement frequency and risks. ^[2]

The baseline is taken at initiation, before performance is affected by the change, and its timing and circumstances are recorded. It also tests whether the problem the project is meant to solve actually exists. ^[2]

When should you measure?

Track intermediate benefits early to see whether the end benefit is on its way, and set the final measurement points after enough time for the change to bed in. The IPA guide notes that projects involving business change may need to wait at least six months before the first measurement, and that reporting frequency should match data availability. ^[2]

An intermediate indicator is an early reading that shows the end benefit is approaching. If the end benefit is less time to complete a service, the intermediate indicator might be the share of transactions submitted through the new channel in the first months. If that share stays low, there is no point waiting for the final measurement; the causes of low take-up need addressing first.

Decide in advance what happens if a reading falls short: who analyses the cause, whether the forecast is revised or corrective action taken, and to whom the result is reported. In UK assurance reviews, the final stage expects forecasts to be compared with the business case and corrective action plans to be in place for benefits not realised on schedule. ^[3]

Hypothetical example: digitising maintenance requests

Hypothetical example: a Gulf organisation closed a project to digitise maintenance requests once the system was handed over, and the service manager took on three indicators: reopened tickets, waiting time and the share of requests logged through the system in each branch.

At the first measurement, waiting time looked better, but the owner noticed that some requests had moved to the telephone without being logged. He asked for a single, consistent record before attributing any improvement to the system, and kept a parallel indicator for the effect on branches with weaker connectivity, so an average would not hide a decline there. Once the record was consistent, he re-measured the same period and reported a more accurate reading of what had been achieved to the sponsoring body, together with an action to encourage the lower-use branches onto the new channel.

How do you avoid counting a benefit twice?

When two initiatives target the same indicator, such as transaction time, each team tends to claim the whole improvement. The IPA guide asks for a move from gross to net benefits, removing what would have happened anyway (deadweight) and what simply moved from one place to another (displacement). ^[2] At portfolio level, the guide distinguishes attributing a benefit to a single initiative from an initiative’s contribution to a shared benefit. ^[2]

In practice: review the projects that use the same indicator, appoint a single owner for the total impact, and record each initiative’s contribution without adding up overlapping estimates. If there is no reliable baseline, state the limits of measurement openly and start collecting comparable data rather than estimating a figure you cannot defend.

What is handed over with the benefit at closure?

Writing the benefit owner’s name in the closure report is not enough. The UK standard requires ongoing risks, issues, actions and benefit tracking to be handed over at closure to the appropriate business authority, information to be archived and unfulfilled requirements to be documented. ^[1] It also requires ongoing operational responsibilities to be agreed and accepted. ^[1]

In practice, the handover pack for the benefit owner includes:

• A profile for each benefit, with its measure, baseline, target and measurement dates.
• The data source and who extracts it, so measurement does not stop when the project team moves on.
• Critical assumptions, such as expected take-up, and what to do if they do not hold.
• Expected disbenefits and who is tracking them.
• The post-implementation review date, who attends and to whom its findings go.

The PMO has a role here even after the project leaves its portfolio: keeping the organisation-wide benefits register, reminding owners of measurement dates and gathering lessons on how accurate earlier estimates were. Those lessons are the most valuable thing the PMO holds when the next business case is reviewed; an organisation that knows how much of its past projects’ benefits were realised can judge new projects’ promises realistically.

Conclusion

Benefits are not realised by closing a project but by tracking led by an operational owner against a measure and baseline set in advance. Make benefits handover a condition of closure, and net off what would have happened anyway before announcing what was achieved.