Guides › Guide

Benefits realisation plan

Plenty of projects are delivered on time and on budget and still change nothing. A benefits realisation plan is how you find out whether the point of the project actually happened.

Outputs, outcomes and benefits

A project delivers outputs, such as a new system. Those outputs enable outcomes, such as faster order handling. The outcomes produce benefits, such as lower cost or higher revenue. A benefits realisation plan connects all three and says who is responsible for the last one.

The hard truth is that benefits usually arrive after the project team has gone home. So the plan needs an owner in the business, not just in the project.

The benefits register: columns to copy

Keep one row per benefit. Fewer, measurable benefits beat a long list of hopes.

• Benefit title and a one-sentence description.
• Type: financial (cash saved or earned) or non-financial (speed, quality, risk, satisfaction).
• Measure, or KPI, and how it will be collected.
• Baseline: the value today, before the project.
• Target: the value you expect, and the date you expect it.
• Benefit owner (a named business person) and the dependencies that must hold.

A worked example

This example uses made-up round numbers. Suppose a project replaces a manual invoice process. The benefit is lower processing effort. The baseline is 400 invoices a month at 15 minutes each, which is 100 hours. The target is 5 minutes each, which is about 33 hours, so around 67 hours a month released.

At an assumed loaded cost of 30 pounds an hour, that is about 2,000 pounds a month, or 24,000 pounds a year. If the project costs 60,000 pounds, simple payback takes two and a half years. That may be fine, or it may change the decision, and either way you now know.

• Count released hours as a benefit once someone decides how they will be used.
• Separate cashable benefits from capacity benefits in the register.
• Show assumptions beside the numbers so they can be challenged.

Tracking after go-live

Schedule benefit reviews before the project closes, typically at three, six and twelve months. Each review compares the measure with its baseline and target, and records why any gap exists.

A project may close while its benefits plan stays open, handed to the benefit owner. In Senshin the finance and benefits view keeps benefits alongside cost, so the value case is reviewed next to what the project spent.

• Review dates in the diary with named attendees.
• Report benefits in the SteerCo pack, not just delivery status.
• If a benefit slips, ask whether the cause is delivery, adoption or a wrong assumption.
• Retire benefits that are no longer valid, and say so openly.

Where it fits

Start the plan at initiation, because the business case is where benefits are promised in the beginning. Revisit it at each stage gate and again at closure. For a programme, the benefits are held at programme level, since individual projects rarely deliver them alone.

Where this lives in Senshin

Frequently asked questions

More guides

Last updated: 2026-10-22