ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Benefits realisation is the discipline of proving that a project actually delivered
the value its business case promised. It is the least practised part of project management, for a
simple structural reason: the benefits usually arrive months after the team has disbanded, and by then
nobody has an incentive to go and check.
A project delivers outputs — a system, a building, a process. Outputs enable outcomes, and
outcomes produce benefits: the measurable improvement somebody actually wanted. Benefits realisation
is the management of that chain, from identifying what the benefit is through to confirming it
arrived. (You will also see it spelled benefits realization; the discipline is identical.)
The reason it gets skipped is that every incentive points the other way. The project manager is
measured on delivering to time, cost and scope, all of which are settled at go-live. The benefit lands
in an operational budget six or twelve months later, owned by somebody who was never on the project
board. Nobody is dishonest; the accountability simply runs out before the value shows up.
That gap is why organisations can run a portfolio of projects that all delivered on time and still
find no improvement in the numbers that justified them.
The process breaks into four stages, and treating them as one activity is why it so often collapses
into a paragraph in the business case.
| Stage | What happens | Artefact |
|---|---|---|
| 1. Identification | Map the benefits with the business, name the disbenefits, and check each one is measurable | Benefits map |
| 2. Planning | Baseline each benefit, set the target and the date, and name an owner outside the project | Benefit profile, benefits realisation plan |
| 3. Realisation | Measure against the baseline at the review points you scheduled | Benefits tracker |
| 4. Transition | Hand tracking to the business, because the project is closing before the benefits land | Handover into operational reporting |
Stage four is the one that decides whether any of it was worth doing. A benefits realisation plan
that stays with the project dies with the project.
A disbenefit is an outcome the change will definitely produce that somebody experiences as a loss
— a team that loses autonomy, a customer group whose process gets longer, a capability that is
deliberately retired. It is not a risk, because it is not uncertain; it is a cost you have decided to
accept.
Recording disbenefits alongside benefits does two things. It makes the business case honest, and it
predicts almost exactly where your resistance to change will come from, which is useful long before
go-live.
This is the single most common failure. A benefit stated as “reduced handling time”
cannot be proved, because nobody measured handling time before. Once the new system is in, the old
measurement is gone forever and the claim becomes an assertion.
Measure the baseline before anything changes, even roughly. A benefit with a weak baseline
taken in advance is worth more than a precise measurement taken afterwards with nothing to compare it
against.
The benefits set, with worked samples.
The Project Management Toolkit ships 390+ editable MS Office templates. The benefits set covers a benefits realisation plan and a completed sample, a benefits management plan, a benefit profile, a benefits map, a benefits tracker and a benefits realisation management process checklist — alongside a cost benefit analysis and a project benefits tracker in the initiation set.
Benefits fail at the sentence level long before they fail at the portfolio level. Compare:
Unmeasurable: “Improved customer experience.”
Measurable: “Average call handling time falls from 6m 20s to under 5m by 31 March
2027, measured from the contact centre’s monthly report. Owner: head of service operations. Baseline
taken July 2026.”
The second names five things the first does not: the metric, the baseline, the target, the date and
the owner. Add the data source, as above, and the benefit can be audited by somebody who was never
involved.
A useful test at the identification workshop: for each proposed benefit, ask who would notice if it
did not happen. If the answer is nobody in particular, it is not a benefit — it is a hope
attached to the business case to help it pass.
The owner of a benefit should be the person whose numbers will move. That is almost never the
project manager, and making it the project manager is how benefits quietly become nobody’s job at
closure. Name them during planning, get them to agree the target in writing, and invite them to the
reviews — a benefit owner who first hears about their target at the post-implementation review
will dispute it, reasonably.
Scope gets cut under schedule pressure, and the thing cut is often the thing a benefit depended on.
Every change request should carry an explicit line on benefit impact. Without it, a project can
descope its way to on-time delivery of something that no longer produces the value it was funded for
— and the change log will show every decision as reasonable.
It is not a fringe concern. PMI’s PMBOK Guide
reached its Eighth Edition in November 2025, built on six core principles — one of which is
focus on value — and seven performance domains. PRINCE2 7, available
worldwide since 4 September 2023, treats benefits as one of its performance targets alongside time,
cost, risk, scope, quality and sustainability. And
ISO 21502:2020,
the method-neutral international guidance standard, covers benefits management as a practice in its
own right.
All three make the same point differently: delivering outputs on time is not the objective, it is
the mechanism. That framing is what benefits realisation exists to keep honest.
The last one matters most for the long term. Organisations that record which benefits failed, and
why, get measurably better at estimating the next business case. Organisations that quietly close the
tracker when the numbers disappoint keep making the same case forever.
Everything above works for one project. The reason organisations invest in the discipline is what
happens when you aggregate it.
A portfolio view of benefits answers questions no individual project can: whether two projects are
claiming the same saving, whether the sum of forecast benefits is larger than the total the business
plan assumes, and which categories of benefit the organisation is consistently over-forecasting. All
three are common, and all three are invisible until benefits are recorded in a comparable form.
Double-counting is the most expensive of them. Two projects each claiming three headcount from the
same team produces a business case portfolio that promises six, and an organisation that reduces by
three and cannot explain the shortfall. A shared benefits register with a single owner per metric is
what prevents it — and it is usually the
PMO that ends up holding it, which is worth
writing into the charter rather than assuming.
What is benefits realisation?
The management of a project’s benefits from identification through planning, measurement and handover
to the business — the process that establishes whether the value in the business case actually
arrived.
What is the difference between an output, an outcome and a benefit?
The output is what the project builds. The outcome is the change in how things work. The benefit is
the measurable improvement that change produces.
Who owns benefits realisation?
The sponsor is accountable for it; individual benefit owners sit in the business and own the numbers.
The project manager runs the process during the project and hands it over at
closure.
When should benefits be measured?
At the points named in the benefits realisation plan, which are almost always after the project has
closed. That is exactly why the post-implementation review is scheduled as a separate event.
What is a disbenefit?
A certain negative consequence of the change, as opposed to a risk, which is uncertain. Recording
disbenefits keeps the business case honest and predicts where resistance will come from.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026