Benefits Realisation Management: A Field Checklist

Projects are authorised because they are expected to produce benefits -- cost savings, service improvements, revenue growth, risk reduction, or strategic capability. But most project management effort is focused on outputs: did we deliver the system, the facility, the policy, the training programme on time and on budget? Benefits realisation management (BRM) asks a harder and more important question: did those outputs actually produce the outcomes and benefits we were after?

The gap between outputs and benefits is wider than most organisations acknowledge. A new ERP system is an output. A 15% reduction in time spent on month-end close is a benefit. A new community health clinic is an output. A measurable reduction in emergency department visits from the catchment area is a benefit. Many projects close when the output is delivered, before anyone has measured -- or even defined -- whether the intended benefits materialised. The consequences are serious: organisations repeat the same investments without learning whether they worked, and the project management function loses credibility as a value-creating discipline.

Why Benefits Realisation Is Routinely Skipped

Benefits realisation fails for predictable reasons. The project team dissolves at project close, and no one owns the follow-up. Baseline data was never collected before the project started, so there is nothing to compare the post-implementation state against. The benefits were described in vague terms in the business case -- 'improved efficiency', 'enhanced service quality' -- that were never translated into measurable indicators. Post-implementation reviews are planned but perpetually deprioritised when operations teams are busy.

The result is that organisations invest tens or hundreds of millions of dollars in projects, close them when the deliverables are handed over, and then move on to the next project without ever confirming whether the investment produced its intended return.

The Checklist

1. Define benefits before scope. The project business case must identify specific, measurable benefits before project scope is defined. If you cannot describe what success looks like in measurable terms, you are not ready to authorise the project. Each benefit should have: a description, a unit of measurement, a baseline value (current state), a target value (expected state post-implementation), and a measurement date.

2. Assign a benefits owner. Every benefit needs a named individual who is accountable for its realisation. This person is typically a business leader -- not the project manager -- whose operational area will experience the change. The benefits owner role continues after project close. Without a named owner, benefits review meetings have no one to chair them and no one to be held accountable if targets are missed.

3. Build a benefits register and keep it alive. The benefits register is the central tracking document. It lists every benefit, its baseline, its target, its measurement approach, its owner, and the date by which it is expected to be measurable. The register should be reviewed at each project status review and updated as the project evolves. Benefits that turn out to be unmeasurable should be replaced with benefits that are.

4. Plan the measurement approach. Identify, before the project starts, how each benefit will be measured. What data will be collected? By whom? How frequently? Where will it be stored? In many cases, this requires setting up new data collection processes during the project -- not as an afterthought at project close. If the baseline does not exist, collect it during the project initiation phase.

5. Schedule post-implementation reviews at authorisation. Post-implementation reviews (PIRs) should be scheduled as part of the project authorisation process, not left to chance after close. A typical cadence: an early PIR at 3 months post-go-live (to confirm the system is operating as intended and identify early issues), a benefits PIR at 12 months (to measure whether short-cycle benefits have materialised), and a final benefits PIR at 24--36 months for benefits with longer lag times.

6. Close the loop between project close and benefits realisation. Project close should not be the end of accountability. The project sponsor retains accountability for benefits realisation after project close. The project's final report should include: the agreed benefits register, the PIR schedule, the name of the benefits owner for each benefit, and confirmation that the benefits owner has accepted accountability. This is a governance checkpoint, not a formality.

A Note on Realistic Expectations

Not every project benefit will be fully measurable, and some benefits that materialise will be attributable to multiple factors -- a cost reduction may reflect the new system, but also a headcount reduction that happened independently. Good benefits realisation management acknowledges this complexity rather than pretending it does not exist. The goal is not a perfect attribution model; it is a disciplined process for checking whether investments produced their intended results, learning from the cases where they did not, and improving the quality of the next business case.

XNM supports public-sector clients in implementing benefits realisation frameworks and post-implementation review processes. Reach out to XNM's program & project delivery advisory team to discuss how benefits realisation management can be built into your project governance framework.