Project benefits realisation: how to define, own and measure benefits

Why benefits get lost after approval

A business case may say that a project will reduce processing time, improve service, lower error rates or increase capacity. Once delivery begins, attention naturally moves to scope, milestones and issues. If nobody owns the promised outcome, the project can finish without anybody checking whether the expected benefit appeared.

The practical control is simple: define the benefit clearly enough to measure, establish where you are starting from, set the intended result, assign an owner and agree when evidence will be reviewed.

1. Make the benefit measurable

Write the benefit as an outcome rather than an activity. “Introduce a new portal” is a deliverable. “Reduce average customer-request handling time” is a potential benefit because you can define a measure and compare results.

Choose one measure and unit for each benefit. If the measure changes halfway through, you may no longer be comparing the same thing.

2. Keep baseline, target and actual in the same unit

The baseline is the starting position. The target is the intended result. The actual is the observed result when you review it. Keep all three in the same unit so the comparison remains meaningful.

Do not invent a baseline because the template has a field for one. If reliable starting data does not exist, record that as a gap and decide whether the project needs to establish it before claiming a measured benefit.

3. Assign a benefit owner

The project manager can maintain the register, but should not automatically own every benefit. The benefit owner should be close enough to the operational result to obtain evidence, explain movement and decide what happens if the expected outcome does not appear.

Confirm ownership while the project is active. It becomes much harder after the delivery team has moved on.

4. Be clear whether improvement means up or down

Some benefits improve when a number increases, such as capacity or adoption. Others improve when it decreases, such as processing time, defects or cost. Record the intended direction so that a lower actual value is not accidentally treated as poor performance when lower is the target.

5. Review status and evidence without pretending to forecast precisely

A benefits register is not a forecasting engine. Use status to focus attention: which benefits have been achieved, which are at risk, which need review and which still lack usable evidence?

Keep the supporting evidence where it belongs. The register can record the measure and current result, while detailed operational reports, finance records, survey outputs or service data remain in their normal systems.

Review dates should reflect when evidence can reasonably exist. A benefit that depends on three months of live operation should not be judged on the day the project deploys.

6. Common benefits-realisation mistakes

• recording deliverables as if they were benefits;
• setting a target without a reliable baseline;
• using different units for baseline, target and actual;
• leaving every benefit with the project manager;
• closing the project before future review ownership is agreed;
• marking a benefit achieved without retaining evidence;
• treating a simple register as an ROI, NPV or enterprise benefits-management system.

Use your organisation's business-case, finance, benefits-management and governance standards where they apply. This guide and workbook are practical project-delivery aids, not accounting, investment or financial advice.