A project delivers an output. What the organisation actually bought was a change in how it performs, and the distance between the two is where most of the disappointment in project work lives.
An output is not a benefit
A new claims system is an output. Settling a claim in nine days instead of fourteen is a benefit. The output is finished when the project says so, and the benefit only appears once claims handlers are fluent in the new system, once the old process is switched off, and once enough claims have run 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.
That timing is the awkward part. Most benefits land after the project closes, which means the team that produced them has been disbanded and the status report that would have shown the truth no longer exists. A project judged only on date, cost and scope can be declared a success in a quarter where nothing the organisation wanted has yet happened.
What a benefits management plan says
For each benefit the plan answers four things, and each of them is the answer to a question somebody will ask later.
- What the benefit is, stated as a movement in a measure rather than as a capability. "Faster settlement" is a hope. "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 rather than a measurement.
- Who owns it after handover, named as a person rather than a function.
- 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.
A plan that leaves any one of these blank tends to leave the whole benefit untracked, because the first missing answer is the excuse for not filling in the next.
Why an operational manager owns the benefit
The owner is almost always a line manager in the area receiving the change, rather than the project manager who built it. The reason is control rather than courtesy. 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 keeps pressing after the novelty wears off. Those levers stay with the receiving area long after the project manager has moved on to something else.
The corollary is that the owner has to agree to the number before the business case is approved. An owner who first hears about the benefit at handover will treat it as somebody else's target, and a target nobody accepted is a target nobody chases.
Leading indicators during delivery
Waiting for the benefit measurement date to find out 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 the intended users who have actually used the new capability in the last week. Volume through the new path against the old is another, as is the rate of errors and rework in the first weeks, and 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 rather than the benefit itself. If adoption sits at thirty per cent three months after go live, the settlement time figure will not move, and knowing that early is the difference between fixing it and explaining it.
When the benefit does not arrive
Two very different failures produce the same disappointing number, and they need separating before anyone reaches for a lesson learnt. Either the output was wrong for the job, which is a delivery problem, or the output was fine and the organisation has not changed around it, which is a change and operations problem. The second is far more common, and it is invisible to anyone reading only the project record.
Worth counting too are disbenefits, meaning the outcomes that got worse. A process that is faster for the customer and slower for the back office has both, and a benefits plan that records only the good half will be contradicted by the people living with the other one.