Benefits Realisation: Definition, Tracking and Ownership
Benefits realisation is the process of tracking whether the benefits claimed in a business case actually arrive after delivery. It covers defining each benefit measurably, baselining it before change, assigning an owner in the business, and measuring it over a defined period after go-live. It normally continues past the project's own closure.
What a benefit record holds
A benefit is only trackable if it was written down in a form somebody can measure. That means more than a description and a number.
| Field | Purpose |
|---|---|
| Benefit | What improves, stated as an outcome rather than a feature |
| Type | Cash-releasing, cost-avoiding, revenue, or non-financial |
| Measure | The specific metric, and where the data comes from |
| Baseline | The value before the change, captured before go-live |
| Target | The value expected, with the date it is expected by |
| Owner | A named person in the receiving business function, not the project |
| Realisation profile | How the benefit is expected to build over months or quarters |
| Dependencies | What else has to happen — process change, training, decommissioning |
| Actual | Measured value at each review point |
How it is used
Realisation runs on a longer clock than delivery. Costs are incurred during the project; benefits usually start after go-live and build over quarters. That mismatch is the structural problem: the project team that made the claim has normally disbanded before the first measurement point.
The practical mechanism is a handover. At closure, each benefit line moves from the project to a named owner in the receiving function, along with the baseline, the measure, the target and the review dates. The project closure report carries that handover explicitly, and the project closure guide covers what has to accompany it. The originating numbers, along with the assumptions they depend on, sit in the business case template, which keeps a realisation tab for the year after go-live so the case and the tracking share one set of definitions.
Where several projects are running, the roll-up sits with the PMO. That is a portfolio question rather than a project one — which investments delivered what, against which forecasts — and it is one of the views the portfolio tracker is built to hold.
Where it goes wrong
- No baseline. A benefit measured only after the change has no comparison point, and any improvement claimed is unfalsifiable.
- Ownership left with the project. The project closes, the owner leaves, and the benefit is nobody's.
- Benefits defined as outputs. "New system deployed" is a deliverable. The benefit is what changes because it is there.
- Double counting. Two projects claim the same headcount saving. At portfolio level the total is impossible.
- Measurement point before the profile allows. Reviewing three months after go-live a benefit whose profile builds over eighteen produces a false negative and kills the review process.
- Non-financial benefits left unmeasured. A benefit stated only as improved experience or reduced effort, with no metric attached, is never tested and quietly disappears from the review.
- Enabling change not funded. The system lands, the process does not change, and the benefit does not arrive. The dependency was known and unowned.
Related terms
Business case — where the benefit was first claimed and quantified. Benefit owner — the person in the business accountable for delivering it after handover. Project closure — the point at which benefits are transferred. Hypercare — the stabilisation period that precedes any meaningful measurement. Baseline — the pre-change value the benefit is measured against.
Questions
When should benefits be measured?
At the points set out in the realisation profile, which depend on how the benefit builds. Measuring before the profile predicts anything produces a misleading result and discredits the exercise.
Who is responsible for benefits realisation?
The benefit owner in the receiving business function, with the sponsor accountable overall. The project manager is responsible for defining, baselining and handing over the benefit, not for realising it.
Is benefits realisation the same as benefits management?
Benefits management is the wider discipline covering identification, planning, tracking and review. Realisation is the part concerned with whether the benefit actually materialised.
What happens if a benefit is not realised?
It gets recorded and explained. That record is worth more than the original forecast, because it is the input that makes the next business case in the same domain more accurate.