Benefits Realisation Management: A Register, an Owner, a ₹ Example

Benefits realisation management (BRM) is the set of practices that identify benefits, tie them to strategy, make sure they are realised as delivery progresses, and keep them sustained after delivery ends. PMI's Benefits Realization Management Framework organises this as three stages: Identify, Execute and Sustain.

The confusion that catches most people is the difference between three levels:

A benefit can be tangible, such as money saved or student numbers gained, or intangible, such as reputation or capacity for change, as Oxford Brookes University's project toolkit puts it. A quick test: if the sentence only says something was delivered (a system is live, staff are trained), it is an output. A benefit is a measurable change in the business that would not have happened without the project.

A benefits register row holds nine fields, one row per benefit. The first seven draw on the benefits register content described in the Teal Book, the UK government's Government Project Delivery guidance (chapter 19, last modified 1 July 2026), and on the plan elements in PMI's framework. Review dates and status are our additions, because a register that is never reviewed is a document, not a control.

The Teal Book also advises against giving one owner too many benefits. Keep rows to a number the owner can actually watch.

Slow adoption delays payback by months even when the project is delivered perfectly. Here is our worked model, built on the example row above. The inputs are our assumptions for illustration, not data from a real project.

• Volume: 12,000 invoices a month.
• Saving: ₹180 − ₹95 = ₹85 per invoice, so ₹85 × 12,000 = ₹10.2 lakh a month at full adoption, or ₹1.224 crore a year.
• Project cost: ₹1.8 crore (₹180 lakh).
• Adoption after go-live: 30% in months 1 to 3, 60% in months 4 to 6, 90% in months 7 to 12.

The business case assumes 100% from day one, so payback is 180 ÷ 10.2 = 17.6 months. With the ramp, the first year delivers ₹10.2 lakh × (3 × 0.3 + 3 × 0.6 + 6 × 0.9) = ₹10.2 lakh × 8.1 = ₹82.62 lakh. That leaves ₹97.38 lakh still to recover.

A delivery report would read green in all four rows, because the project was delivered in each. Four of the ten months between the first and last row come from the first-year adoption ramp. The other six come from adoption falling back to 60% once the project team leaves. That second gap is an ownership problem, which the next section addresses. Treat adoption as a risk that the benefit owner reports on at every review.

A named business leader who can change the process that produces the benefit owns it, not the project manager. The Association for Project Management (APM) notes that benefits typically arrive after handover, so the sponsor, not the project manager, stays accountable. The Teal Book defines the benefit owner as the named individual who confirms the benefit, agrees the plan and reports on realisation.

In PMI's 2016 research, naming an accountable owner was far more common in mature organisations. That is an association, not proof of cause, and the data are a decade old. PMI surveyed 774 managers accountable for benefits on projects of US$250,000 or more. In its ownership and accountability study, 94% of high-maturity organisations always formally named who is accountable for benefits, against 19% of low-maturity ones. High maturity meant a score of 60 or more out of 64 on a 16-item practice scale, and low meant under 46. In the same year, PMI's Pulse of the Profession 2016 reported that only 17% of organisations had high benefits realisation maturity, unchanged for three years, and nearly four in ten had low maturity.

Our recommendation for common situations:

Run four tests on each statement before it enters the register. Each has a clear pass or fail.

A benefit that fails the number or owner test is not ready for approval. Fixing it takes a conversation, not a document.

Review each benefit at 3, 6 and 12 months after go-live, plus once on the target date if it falls later. Add at least one review dated after the project closes, with a named person reporting it. This is our recommendation for benefits that depend on people changing how they work. The Teal Book places reviews before closure and again afterwards, through further assurance reviews and formal post-implementation reviews. PMI's framework adds a sustainment plan covering the risks, measures and tools needed to keep benefits flowing.

The early reviews check adoption, the cause of most delay in the model above. The last one checks the number. Record what was measured, by whom, against which baseline, so the figure survives a change of owner.

Module 6 of our Program Management Essentials course, "Benefits Planning & Value Realization", covers benefit identification, categorisation, benefit management, transition and sustainment. It is part of the 12-week course, which includes real-world templates and case studies.

If you are preparing a PgMP® (Program Management Professional) or PfMP® (Portfolio Management Professional) application, a benefits realisation plan, baseline or target is the kind of evidence that shows you protected organisational results. Our PgMP application terminology guide covers how to word it.

Program Management Essentials runs over 12 weeks and costs US$99 as of October 2026.