Benefits realisation is the discipline of obtaining the improvement for which a project's money was approved. A project delivers an output. What the organisation purchased was a change in how it performs, and the distance between these two is where most of the disappointment in project work is found. PMI covers it in the Business Environment domain, and PMBOK 8 puts benefits inside the Finance performance domain alongside the business case, so the examination tests it through scenarios about who owns a benefit and when it is measured.
The sections below draw the line between an output and a benefit, describe what a benefits management plan has to say, explain why the owner sits in the business, list the indicators that can be watched during delivery and separate the two reasons a benefit fails to appear.
An output is not a benefit
A new claims system is an output. Settlement of a claim in nine days where it previously took fourteen is a benefit. An output is finished when the project says so. A benefit appears only once the claims handlers are fluent in the new system, once the old process has been switched off and once enough claims have passed through to move the average.
The project ends one step into the chain. The output crosses the line and the outcome and the benefit both land on the far side of it, in the hands of somebody who was never on the project team, which is why a benefits plan has to name that person before the case is approved.
This timing is the awkward part. Most benefits land after the project has closed, which means the team that produced them has been disbanded and the status report that would have shown the position no longer exists. Where a project is judged only on date, cost and scope, it may be declared a success in a quarter during which nothing the organisation wanted has yet occurred.
What a benefits management plan says
The benefits management plan is the document that survives the team, and for every benefit it answers four things.
- What the benefit is, stated as a movement in a measure. "Faster settlement" is a hope, and "mean settlement time down from fourteen days to nine" is a benefit.
- How it is measured, with the baseline value recorded before the project starts. A baseline reconstructed afterwards is an argument, and no longer a measurement.
- Who owns it after handover, named as a person.
- When it is expected, as a profile over time. Benefits usually ramp, and a single date hides both the ramp and the dip that often precedes it.
Where a plan leaves any one of these blank, the whole benefit tends to go untracked, since the first missing answer becomes the excuse for not supplying the next.
Why an operational manager owns the benefit
The third answer is almost always a line manager in the area receiving the change, and control is the reason. The things a benefit depends on are operational decisions, meaning staffing levels, whether the old process is decommissioned, what people are measured on and whether the manager continues to press once the novelty has worn off. Those levers remain with the receiving area long after the project manager has moved on to something else.
It follows that the owner has to agree to the number before the business case is approved. An owner who first hears of the benefit at handover will treat it as someone else's target, and a target nobody accepted is a target nobody chases.
Leading indicators during delivery
The owner takes over at handover, and waiting until the measurement date to discover whether a benefit will arrive is waiting several months too long. Leading indicators are the preconditions that can be watched while the project is still running.
Adoption is the usual one, meaning the proportion of intended users who have actually used the new capability within the last week. Volume through the new path measured against the old is a second, the rate of errors and rework in the first weeks is a third, and a fourth is whether the support queue is filling with questions the training was supposed to have answered.
Each of these is a condition the benefit depends on, and none of them is the benefit itself. Where adoption sits at thirty per cent three months after go live, the settlement time figure will not move, and knowing this early is the difference between fixing the problem and explaining it.
When the benefit does not arrive
Two very different failures produce the same disappointing number, and they need to be separated before anybody reaches for a lesson learned. In the first, the output was wrong for the job, which is a delivery problem. In the second, the output was sound and the organisation has not changed around it, which is a change and operations problem. The second is by far the more common, and it is invisible to anyone reading only the project record.
Disbenefits are worth counting as well, meaning the outcomes that became worse. A process that is faster for the customer and slower for the back office produces both, and a benefits plan that records only the favourable half will be contradicted by the people living with the other one.