A Benefits Realisation Plan That Survives Handover

A programme closes on time. The system is live, the project team disbands, and the benefits register shows every item as “transferred to business as usual.” Six months later, the expected saving has not appeared. Operations says the process changed but staffing was not reduced. Finance says the benefit was never baselined. The sponsor says the target was a business-case assumption, not a commitment.

The project may have delivered its output. The organisation has not governed the value it expected from that output.

A benefits realisation plan is the record that connects an expected benefit to the conditions required to achieve it, the people who must act, the evidence that will show progress, and the decision route when reality changes. It is not a longer benefits list. If the plan cannot answer “who will do what, by when, based on which measure, if this benefit fails to appear?”, it cannot survive handover.

Download the accessible benefits-realisation plan template. It includes instructions, an editable one-row-per-benefit plan, status choices, and a fictional completed example. Replace or delete that example before use.

Use a plan when benefits require action after delivery

Every investment needs a clear case for value. A detailed benefits plan becomes especially important when value depends on operational adoption, behavioural change, multiple teams, external conditions, delayed measurement, non-financial outcomes, or dependencies outside the delivery team’s control.

That is most programmes. A capability does not automatically create a benefit just because it has been installed.

UK public guidance describes a benefits plan as a management tool that draws milestones from individual benefit profiles into a consolidated view, with review points, post-project governance, and overall SRO oversight. Northern Ireland Department of Finance, Programme and project benefits realisation PMI frames benefits-realisation management as a thread from organisational strategy through project deliverables and success measurement across portfolios, programmes, and projects. PMI, Benefits Realization Management: A Practice Guide These are guidance frameworks, not proof that a template alone creates value.

Ground the terms before building the plan

Teams often put outputs, outcomes, and benefits on the same list. That makes measurement and accountability impossible.

Term	Meaning	Example in a claims-service change
Output	The thing delivered or changed	A redesigned online claim journey and a new evidence-upload capability
Outcome	A change in user, operational, or system behaviour or condition	More eligible applicants complete the journey without assisted contact
Benefit	The value gained from the outcome for a beneficiary	Lower avoidable contact demand, faster valid-claim processing, or a better claimant experience
Disbenefit	A negative consequence that must be accepted, mitigated, or weighed against value	Temporary training load, increased early support contacts, or reduced flexibility for a user group
Value	The overall strategic, financial, operational, social, risk, or user value judged from benefits and disbenefits	Whether the change remains worth the cost, risk, and opportunity cost

A benefit is not always cashable. Service quality, trust, resilience, safety, compliance, and avoided future cost may matter. The UK Government Service Manual notes that benefits can be non-cashable and that a baseline is necessary to know whether performance has improved. UK Government, Measuring the benefits of your service The challenge is not to force every benefit into a spurious currency figure. It is to state the measure, evidence, judgement, and decision use honestly.

Build each row as a testable value hypothesis

The downloadable template uses one row per expected benefit or disbenefit. Each field exists to prevent a predictable failure.

Field	Why it belongs in the plan	Failure prevented
Benefit or disbenefit	Names the value change, not the deliverable	Calling delivery completion a benefit
Beneficiary	States who gains or bears the consequence	Vague claims that “the business” benefits
Benefit hypothesis	Explains why the intervention should create the outcome	Treating a feature as proof of value
Benefit and measurement owners	Separates accountability for realisation from data collection where needed	Assuming the project manager owns an operational result forever
Measure, baseline, and target	Makes the expected change observable and comparable	Measuring success only after the intervention changes the starting point
Evidence and assumptions	Records sources, method, uncertainty, and the conditions the business case depends on	Presenting an estimate as established fact
Dependencies and intervention	Shows what else must happen beyond delivery	Leaving adoption, policy, capacity, or operating-model change as implicit work
Review cadence and current performance	Turns the plan into a recurring control	Discovering a missed benefit only at project close
Decision/action and decision owner	States what happens if evidence changes	Reporting a variance with no corrective authority
End or retirement condition	Defines when the benefit is realised, re-baselined, or retired	Keeping stale benefits alive indefinitely or quietly deleting them

The first group of fields makes the expected value clear; the rest make it governable. Current UK major-project guidance similarly expects baseline circumstances and targets to be documented and benefits reporting to include titles/measures, baseline/target, current performance, benefit owner, and agreed governance intervals. UK Government, Guide for Effective Benefits Management in Major Projects

Establish the baseline before the change contaminates it

The most common measurement error is taking a “baseline” after a new system, policy, training intervention, or market shift has already changed behaviour. The comparison then becomes a story about movement, not evidence of improvement.

For each measure, record:

• Definition: precisely what is counted, included, excluded, and divided by what.
• Starting value and period: a date or representative period that predates the material intervention.
• Source and method: system of record, sample, calculation, data-quality limitation, and who validates it.
• Circumstances: policy, seasonality, demand, staffing, service level, technology, or other context that could make a future comparison misleading.
• Target and rationale: what success looks like, over what period, and why the target is plausible rather than aspirational.

Baseline timing and circumstances should be documented in the benefits plan, according to the UK major-project guide; it also cautions that targets should be realistic and may not be knowable before the preferred option is selected. UK Government, Guide for Effective Benefits Management in Major Projects A target is therefore a managed hypothesis, not a number protected from learning.

Work one benefit through delivery and operation

The workbook includes a fictional example: “eligible claim applicants complete without assisted contact.” It illustrates the logic without claiming a real result.

The benefit hypothesis is: if eligibility and evidence requirements are clearer, more applicants will complete a valid claim without needing support. The plan records a 52% baseline, a 70% target, the evidence source, the operations benefit owner, the measurement owner, dependencies such as identity-service availability and policy wording, and the interventions needed beyond software delivery—guidance, a recovery route, and agent training.

During delivery, the programme does not report the benefit as realised just because the redesigned journey reaches beta. It checks whether the baseline remains valid, whether the service can identify an eligible completion consistently, and whether policy or operational changes affect the comparison.

At handover, the operational benefit owner accepts a specific responsibility: maintain the measure, lead the required change actions, bring material variance to the right decision forum, and report the result at the agreed cadence. The delivery team transfers knowledge, data definitions, support arrangements, and open dependencies; it does not transfer a vague sentence saying “operations to realise benefits.”

After handover, a performance shortfall prompts a decision. If completion remains below 60% for two months, the plan routes options to the accountable owner: refine guidance, change the evidence requirement, add assisted support, revise the target with approval, or retire the benefit if the logic no longer holds. The number is not the decision. It is evidence for a decision.

Govern the plan before and after handover

Benefits need two overlapping governance periods.

Period	Delivery and programme focus	Operational benefit-owner focus	Typical decision
Before handover	Confirm the hypothesis, baseline, target, dependencies, intervention plan, measurement method, and transition readiness	Agree ownership, capacity, data access, and the actions required after delivery	Is the capability and operating change ready to create the expected benefit?
At handover	Transfer measures, evidence sources, open assumptions, risks, and review dates	Accept the plan, measurement responsibility, and decision route	Can operational ownership begin without hiding unresolved conditions?
After handover	Provide limited support or close remaining programme conditions	Monitor performance, implement interventions, report variance, sustain, revise, or retire benefits	Does evidence support protecting, changing, or ending the benefit hypothesis?

Role labels vary, but the accountability principle should not. PMI’s benefits-ownership guidance assigns a benefit or business owner overall responsibility for monitoring, measurement, and achievement within a cross-functional effort. PMI, Establish benefits ownership and accountability Current UK efficiency guidance likewise says the benefit owner should work with finance, economist, and analyst teams on the approach, evidence, assumptions, and assurance. UK Government, The Government Efficiency Framework

Do not confuse the person who measures a benefit with the person accountable for realising it. Independence in measurement can improve credibility, but it cannot replace an operational owner who can actually change a process, service, policy, capacity, or behaviour.

Keep uncomfortable benefits visible

Benefits plans become untrustworthy when only good news survives. Use explicit statuses and decisions.

Delayed benefit. Keep the target and reason visible. State what dependency, adoption path, or implementation condition changed, who owns the response, and when the target will be revisited.

Emergent benefit. Add it only when there is a plausible causal link, beneficiary, measure, owner, and decision use. Do not inflate value by counting every unexpected positive observation.

Non-financial benefit. State the evidence type—user research, service performance, compliance result, risk exposure, or professional judgement—and who validates it. Avoid converting a meaningful qualitative benefit into a false cash figure merely because the plan has a finance column.

Disbenefit. Record the negative consequence, affected people, tolerance, mitigation, owner, and review point. A benefit plan that excludes harms creates an unreliable value case.

Retired benefit. Do not delete it. Record that the assumption failed, context changed, a different benefit replaced it, or the organisation consciously accepted a trade-off. Name the authority and evidence behind the retirement. This protects future investment decisions from a false history of success.

Use the workbook as a control, not a filing cabinet

The benefits-realisation plan template has two sheets:

1. Instructions explains the logic for a benefit row, baseline, ownership, dependencies, review, and retirement.
2. Benefits Plan contains the editable table. The first row is a fictional example; the following rows are blank. The status field provides Planned, On track, At risk, Delayed, Realised, and Retired choices.

Start with no more than the benefits your governance can genuinely review. Agree the data definitions and owners with finance, analysis, operations, and the accountable sponsor before presenting targets as commitments. Link each review to a decision: protect the benefit, change the intervention, revise the hypothesis, change the target, accept a disbenefit, or retire the benefit.

The plan has worked when a reader can trace expected value from the investment case through capability, operational change, performance evidence, and an accountable decision. It has failed when it becomes a spreadsheet where green status replaces value.

Sources and editorial limits

• UK Government, Guide for Effective Benefits Management in Major Projects, Northern Ireland Department of Finance, Programme and project benefits realisation, and UK Government Service Manual, Measuring the benefits of your service — public guidance applied as transferable planning principles, not a universal governance prescription.
• PMI, Benefits Realization Management: A Practice Guide, PMI, Establish benefits ownership and accountability, and UK Government, The Government Efficiency Framework — professional/public role, lifecycle, and assurance context with scope limits in the research pack.

The template, field design, fictional example, transition design, and treatment of delayed/emergent/non-financial/retired benefits are Strategica synthesis. The workbook has not been practitioner-tested and is not a substitute for business-case appraisal, accounting, audit, evaluation, legal, regulatory, safety, or formal governance requirements.