By Paulius Petravicius

The Spotter warehouse scanning rollout finished on time and on budget. Its business case promised fewer picking errors and faster dispatch. Its benefits realisation plan and register went into the project folder. Nobody in the warehouse accepted ownership, and nobody measured performance before the scanners arrived. The PM moved on. The folder was archived. When finance asked about savings the following year, there was no comparison and nobody to ask. Delivery had succeeded; the benefits were unknown.

Spotter, Sam, Ruth, Hana and the team are fictional teaching characters, not a real project or client. All figures, dates and targets are teaching values, not benchmarks.

A benefits realisation plan is only real when a named owner in the business has accepted each benefit, a baseline exists before go-live, and review dates outlive the project.

My starting point is to look for quantitative benefits where practical, while retaining qualitative benefits that matter. The KPIs need to fit the project. Depending on the change, that might mean comparing customer or promoter scores, delivery times, or the amount of work a team can handle before and after implementation.

I would handle cost and full-time-equivalent (FTE) savings carefully, because the framing is sensitive for the people affected. For an AI solution, an additional measure could be how many more tasks people can take on. Extra capacity should be described honestly, rather than automatically presented as a headcount reduction or a cash saving.

I would include benefits measurement in hypercare where practical. If measurement needs to continue beyond that period, the business should take it on, because project managers usually move to other projects. The project should leave clear measurement guidance as a deliverable so the business can repeat the checks at the agreed points in time.

I would measure what we reasonably can and explain the limitations: what the evidence covers, why some benefits are difficult to measure, and when the extra effort would be disproportionate. If the sponsor wants stronger evidence, I would set out the additional time or resources needed, whether for a larger survey, further analysis or industry research, so they can decide whether that work is worth funding.

Practical measurement detail: For each KPI, agree a baseline, data source, measurement owner and review date. Compare similar periods and account for changes in workload or other initiatives before attributing the difference to the project. Keep qualitative feedback alongside the numbers, and check that greater throughput has not come at the expense of quality. These are measurement recommendations, not claims about results from my own projects.

Education note: The one-page plan outline, the register columns, the status words and the review cadence in this article are InsightSpotter editorial choices for ordinary-sized projects. NISTA, APM, PMI and PRINCE2 Programme Management (formerly MSP) material describes benefits management, but none of it prescribes this exact template. Scale it to your organisation.

For a company booking service or warehouse change, start with a page and a sheet. Make commitments that the business can keep after the delivery team leaves.

Why government guidance feels too big, and what to keep

NISTA’s August 2026 v2.1 guidance addresses major projects undergoing formal assurance. Keep its five stages: identification, valuation, planning, realisation and review. At Gate 4, the practical question is how responsibility transfers into business as usual. Keep that question, historical baselines, dis-benefit monitoring and planned reviews; scale the document set to the work. NISTA’s assurance guidance supplies the principles behind that approach.

PRINCE2 Programme Management, formerly MSP, addresses benefits at programme level. An ordinary single project needs proportionate arrangements rather than a programme’s entire document set.

Benefits realisation plan vs benefits register vs benefit profile

The plan says how and when. The register lists what value, measured how, owned by whom. A profile gives detail for one benefit.

Artefact	Answers	Owner during project	Owner after close	Lives where
Plan	How and when?	PM coordinates; sponsor oversees	Business owner maintains commitments	Shared business workspace
Register	What value and who?	Named benefit owners; PM coordinates	Business benefit owners	Business performance records
Profile	Detail for one benefit?	That benefit’s owner	Same business role, with named successor	Linked to register

On a phone, swipe the table sideways to see all five columns.

APM makes the distinction explicit: “A benefits management framework is not a benefits register”. The framework sets organisational policy and categories; the register records this project’s benefits. APM describes a profile as the information for an individual benefit, including its measure, baseline, target, measurement frequency and associated risks. APM’s framework guide explains these different levels.

Education note: On a small project, a sufficiently detailed register row can serve as the profile. Here, associated risks are cross-references to RAID entries. They are not copied into the row.

Benefits realisation plan template

InsightSpotter teaching template; adapt to your context. Copy this outline and keep answers short. Link to existing evidence instead of repeating the business case.

Purpose: business objective and business case reference.
Scope: benefit and dis-benefit IDs; register location.
Ownership: sponsor accountable; named business owner per row;
  written acceptance date, authority and successor arrangements.
Baselines: measure, source, period, collector and deadline before go-live.
Enabling changes: process, training, old process retirement; owner and date.
Measurement: method, frequency, reporter and recipient.
Reviews: readiness before closure, handover, dated reviews after closure.
Dis-benefits: measures, expected duration and monitoring owner.
Handover: register, evidence, open exposures and business review forum.
Closure rule: evidence of realisation, or authorised stop decision and reason.

Treat an unanswered line as work to resolve. A beautifully completed page cannot compensate for a measure that nobody can extract or an owner who cannot change the operating process.

Benefits register template

InsightSpotter teaching template; adapt to your context. Use one row per benefit or dis-benefit. BEN identifies a benefit; DIS identifies a dis-benefit. This shortened view shows Sam’s booking-service trial on 10 November 2026. Every row is an example.

ID	Description	Measure	Baseline	Target	Owner (accepted?)	Next review	Status
BEN-01	Fewer booking calls	Calls/week	To measure	After baseline	Hana, proposed	13 Nov: readiness	Not yet measurable
BEN-02	Fewer missed appointments	No-shows/week	To extract	After baseline	Hana, proposed	13 Nov: readiness	Not yet measurable
BEN-03	Booking outside opening hours	Share of bookings	Zero: no current channel	To agree	Hana, proposed	13 Nov: readiness	Not yet measurable
DIS-01	Extra dual-entry checks	Staff hours/week	Zero extra checks	Zero at public launch	Hana, proposed	13 Nov: readiness	Not yet measurable

On a phone, swipe the table sideways to see all eight columns.

Hana’s acceptance is pending through A-038, due 13 November. The full CSV leaves every acceptance date and latest actual blank. No benefit has been realised at this point. The 13 November entries are preparation reviews, not claims that a post-launch review has happened. Public launch is undated; its first benefits review remains four weeks after launch, with a calendar date to be entered once launch is approved.

Download the benefits register template (CSV) with all four example rows and 21 columns. The full header is below if you would rather paste it into your own sheet.

Benefit ID,Type,Description,Objective it supports,Value type,Measure (KPI),Data source,Baseline value,Baseline period / date,Target value,Target date,Enabling change,Benefit owner,Owner accepted (date),Measurement frequency,Next review date,Latest actual,Actual date,Status,Linked RAID / D / A IDs,Notes / closure reason

Use Not yet measurable until measurement can start; On track or Behind forecast when evidence supports comparison with the agreed trajectory; Realised when the agreed evidence demonstrates the target; Closed when tracking ends with a recorded reason. For a dis-benefit, assess whether the adverse effect remains within the agreed forecast. A blank actual is missing evidence, never zero.

Education note: These status words have no colour mapping. Putting dis-benefits in the same register and simplifying value types to Cash-releasing, Non-cash financial and Non-financial are editorial choices. Use your organisation’s categories where they exist.

Who owns benefits after go-live?

APM distinguishes delivery success criteria from benefits and places accountability for benefits realisation with the sponsor because value often arrives after transition into use. Completing the project is therefore insufficient evidence that its business promise has been met. APM’s explanation of benefits and project success supports that distinction.

PMI’s 2016 thought-leadership report emphasises one owner for continuing measurement and validation. That person may be a business manager, divisional head or product manager. Establishing benefits ownership and accountability is thought leadership, not a mandated project role chart.

Education note: The working split here is the approach this site uses: the sponsor stays accountable for business case benefits; a named business benefit owner is responsible for realising and measuring each one. This is consistent with APM and PMI, rather than a prescribed RACI.

Acceptance needs a written record tied to the benefit IDs. It should confirm the measure, access to its source, enabling changes within the owner’s authority, reporting recipient and review dates in the owner’s diary. Naming Hana in a spreadsheet without her agreement achieves none of that. Avoid giving one person more benefits than they can actively manage.

If the future owner is not in post, name an interim business owner who accepts the same commitments. Record when and how responsibility will transfer to the successor. The departing PM and supplier cannot become the default post-close owners simply because they understand the system.

A product owner who remains with the service can be a natural benefit owner, provided they have the authority and acceptance described above. With incremental delivery, establish a baseline before each relevant change and review value as increments reach users. A single ceremonial go-live is unnecessary.

Closure can break continuity. In their 2019 PMI-sponsored research, Aubry, Sergi and El Boukri found that post-project evaluation in the organisations studied tended to favour delivery performance over achieved benefits. They observed three continuity approaches: keeping the sponsor connected, creating a follow-on project, or transferring benefits work to a PMO. They did not establish which approach was more efficient. The Management of Benefits offers options, not a universal solution.

The project health check’s critical question A3 asks whether someone owns benefits after close; acceptance and a dated measurement plan make that ownership usable.

Baselines, targets and dis-benefits

Write the baseline extraction instruction so another person could repeat it. For BEN-01, count booking-related calls from the phone report for 11 November–8 December, the four weeks immediately before staff-only go-live on 9 December. Preserve the weekly counts and the classification rule. Report total booking volume alongside calls so a quieter service does not masquerade as improvement.

The phone system cannot currently separate booking calls. Starting a report on 13 November cannot automatically recover 11–12 November. Hana needs recoverable records that can be classified consistently, or an agreed alternative measurement method. If those days cannot be recovered, record an incomplete baseline and seek a decision about the period or evidence. Never quietly relabel a shorter sample as four weeks.

For BEN-02, extract no-shows from current booking records for 14 October–10 November and retain scheduled appointment totals. Exclude cancelled appointments consistently. Check the denominator as well as weekly no-shows: fewer appointments can mean fewer absences without better attendance. Set targets after validating the baseline, or identify any assumed baseline and its source explicitly.

BEN-03 measures booking timestamps outside published opening hours, divided by all customer bookings in the same period. Its starting assumption is zero because no current out-of-hours booking channel exists; Hana must validate that assumption. Staff-only trial activity cannot demonstrate a customer access benefit. Measurement starts with public launch.

DIS-01 measures the additional hours spent checking bookings in two places during staff-only running. Keep a weekly time record and test whether the burden actually ends when the duplicate process stops. Explain the net position without adding unlike units: report staff capacity, attendance and customer access separately, with the adverse effort alongside them.

NISTA expects historical comparisons, monitoring of adverse effects and a net view of value. It also tests whether claimed cash savings will really leave budgets. Fewer calls can free capacity without reducing expenditure. Do not label that cash-releasing unless finance can identify an actual budget or spending reduction. Compare like periods and note other causes, such as seasonality, changed opening hours or a parallel campaign. A changed number alone does not prove attribution.

Where benefit risks, decisions and actions go

Every project needs both a separate decision log and a separate action log. The benefits register is a legitimate separate artefact because it records value and survives delivery. It is not another list of problems.

Item	Record	Example
Uncertain threat to a benefit	RAID, R-	R-021: baseline may be missed
Benefit problem now	RAID, I-	I-016: calls cannot be separated
Choice about benefits	Decision log, D-	D-014: scope and review proposal
Follow-up	Action log, A-	A-039: begin baseline report
Value and its measurement	Benefits register, BEN-/DIS-	BEN-01: fewer booking calls

On a phone, swipe the table sideways to see all three columns.

Keep benefit risks and issues in the one RAID working list, linked to their benefit IDs. Keep choices in the decision log and follow-ups in the action log. The register needs only its Linked RAID / D / A IDs column to connect them.

Education note: NISTA lists a risk register covering threats to realised benefits in its Gate 4 and Gate 5 documentation. That is a formal major-government-project assurance set. Under this site’s RAID vs risk register model, these threats sit in the one RAID list; a separate risk register is rare and reserved for governance requirements such as PMO, audit, regulator or programme needs.

At closure, project logs close. Transfer open benefit exposures, their owners and responses with the benefits register into the business’s ongoing controls. Open follow-ups and unresolved choices also need an accepted business destination. Archiving the project must not archive responsibility.

Worked example: Sam, Ruth and Hana on 10 November 2026

In the fictional booking-service trial, Sam is PM, Ruth is sponsor and board chair, and Hana manages customer service operations. D-009 sets staff-only go-live for 9 December. D-011 conditionally accepts the 26 November stage finish; it leaves 9 December unchanged. Public launch has no agreed date.

Following Priya’s 6 November health check and Ruth’s board on 9 November, I-015 remains open: Sam must resolve the absence of an accepted post-close benefits measurement owner by 13 November. D-013 records the board’s instruction that Ruth secures a named business benefits owner who accepts by that date. A-038 requires Ruth to obtain that acceptance and a dated measurement plan. The decision exists; its implementation remains open.

On 10 November, Sam and Ruth meet Hana to draft the plan and the four register rows above. Hana is proposed for all four, with acceptance due through A-038 on 13 November. That is a pending commitment, not a completed handover.

Maya owns R-021, the risk that BEN-01’s four-week baseline is missed if the report is not arranged this week. Noor owns I-016, the current inability to separate booking calls, linked to A-040. Those entries remain in RAID.

D-014 is Sam’s proposal covering BEN-01–03 and DIS-01, first benefits review four weeks after public launch, then quarterly until an end point is agreed. It is pending Ruth’s approval at the next board. Neither scope nor cadence is presented as approved on 10 November.

A-039 assigns Hana the weekly booking-call baseline report, due 13 November, including recovery or explicit treatment of the first two days. A-040 assigns Alex confirmation of call-tagging feasibility with the phone supplier by 17 November. Its later deadline creates a real threat to the baseline; it does not erase I-016. A-041 assigns Sam the benefits handover and review arrangements in the closure plan by 20 November, including the mechanism for dating reviews once public launch is agreed. All three actions are open.

Review rhythm after close

Before closure, benefits remain a standing item on the SteerCo agenda. At handover, test acceptance, access to baseline evidence and the business meeting that will receive actuals. PMI’s 2016 Pulse report places continuing attention on the business owner and operations team after transfer. Share measurement lessons as well as the files. Sustain benefits to optimize business value describes that continuing responsibility.

After closure, the owner updates the register through the normal operations review or management pack and reports to the sponsor. Discuss actual against baseline and target, remaining enabling changes, adverse effects and the next review. Add unexpected benefits with an owner and measure; NISTA’s Gate 5 also looks for these.

Education note: Four weeks after public launch, followed by quarterly reviews, is an example cadence. Agree calendar dates when launch is fixed, and agree the end point; none is approved for Sam’s trial yet. If a forecast breaches an agreed benefit tolerance during the project, use management by exception to escalate to the board.

Close a benefit when the agreed evidence shows it has been realised and tracking can end, or when an authorised decision stops tracking with a reason. Retain the evidence and decision reference. Ending measurement does not turn an unrealised forecast into realised value.

What to avoid

• A register with no accepted business owner, or the PM as post-close owner.
• Targets without baselines, sources or a repeatable counting rule.
• Inflated approval promises: Aubry and colleagues warn about “sales rhetoric”.
• A living register trapped in an archived project folder.
• A risks column that becomes a duplicate risk list.
• Mapping benefit status to RAG colours.
• Reviewing only once, at project closure.
• Counting an output such as “system live” as an achieved benefit.

A short vocabulary note

PMI readers will recognise benefits realization management, benefits register and benefits owner. APM uses benefits management and realisation. NISTA talks about benefits owners and disbenefits, with Gate 4 “Work to realise” and Gate 5 “Review performance”. PRINCE2 Programme Management covers the programme context. The practical questions remain owner, baseline, measure and review. For the wider terminology comparison, see PRINCE2 7 vs PMBOK 8. None of these bodies requires the register format used here.

Before closure: a benefits handover checklist

• Each benefit has a named business owner and dated written acceptance.
• The baseline was measured before the relevant change went live.
• The target is set against that baseline, with a target date.
• Enabling business changes have owners and dates.
• Dis-benefits have measures and monitoring arrangements.
• Reviews continue after close, with calendar dates in the owner’s diary.
• Benefit risks and issues sit in RAID with benefit ID cross-references.
• Benefit choices sit in the decision log; follow-ups sit in the action log.
• Handover includes the register, evidence and accepted ongoing exposures.
• Each benefit has an agreed closure rule and decision authority.

Benefits are why the project was funded. The project can deliver the change, but the business has to own the outcome. A short plan and a working register make that ownership visible beyond the closure meeting.

For more practical project governance templates and examples, join the InsightSpotter newsletter.