Free template
Most business cases are approved once and never checked again. This free benefits realisation plan template turns the benefits in the case into a register with owners, baselines, targets and dates, a profile for each one and a tracking rhythm that runs until the last benefit has landed or been written off.
By Christopher Fagan, Managing Partner, PEF Consulting Partners
A note before you start
If I could change one thing about how most organisations run programmes, it would be this: keep checking the business case after it has been approved. Benefits do not arrive on their own. Someone has to own each one, measure it against a baseline and keep reporting it long after the programme team has moved on. This plan is the simplest way I know to make that happen.
Christopher Fagan, Managing Partner, PEF Consulting Partners
Lift every benefit from the business case into the register and give it an owner who will be asked about it by name. Baseline each one before the programme changes anything, because afterwards it is too late. Separate cash benefits from cost avoidance and non financial benefits, and report them separately. Track monthly from go live, and keep tracking after the programme closes, because that is when benefits are usually lost.
[Organisation name] | Version 0.1 | [Date] | Owner: [Name, role]
| ID | Benefit | Type (cash, cost avoidance, revenue, risk, non financial) | Measure | Baseline | Target | Date | Owner | Depends on |
|---|---|---|---|---|---|---|---|---|
| Field | Detail |
|---|---|
| Benefit ID and name | |
| Description and how it will be realised | |
| Measure and data source | |
| Baseline (value and date measured) | |
| Target and date | |
| Owner and who reports it | |
| Programme outputs it depends on | |
| Business changes it depends on | |
| Risks to realisation |
How programme outputs lead to business changes, and business changes lead to benefits. A benefit with no output or change feeding it is an aspiration.
| Programme output | Business change it enables | Benefit it feeds | Owner |
|---|---|---|---|
| Benefit ID | Baseline measure | Value | Date measured | Measured by | Source and evidence |
|---|---|---|---|---|---|
| Benefit ID | Reporting frequency | First report | Reported to | Reported by | Review point |
|---|---|---|---|---|---|
| Benefit | Target to date | Actual to date | Variance | Forecast at completion | Status (on track, at risk, lost) | Action |
|---|---|---|---|---|---|---|
| Disbenefit or risk | Who is affected | Mitigation | Owner |
|---|---|---|---|
Who reviews the benefits report, how often, when the business case is formally re approved, and how a benefit is written off or replaced.
| Role | Name | Date |
|---|---|---|
| Sponsor | ||
| Finance | ||
| Benefits owner(s) |
Template by PEF Consulting Partners, pefconsultingpartners.co.uk. Free to use and adapt.
Related reading: benefits realisation consultancy, the business case template, the ERP business case guide, programme management consultancy.
The document that turns the benefits promised in a business case into something that is measured and delivered: a register with owners, baselines, targets and dates, the changes each benefit depends on and the rhythm for tracking it after go live.
Baselines before the programme changes anything, tracking from go live, and continuing for at least a year after the programme closes. Most benefits are lost in the months after the programme team has moved on.
The business manager whose budget or performance changes when the benefit lands, never the programme manager. If nobody in the business will own a benefit, it should not be in the business case.
If your programme has a business case and nobody tracking the benefits, a short confidential conversation is the fastest way to put that right.