Benefits Management Plan: Who Owns Value After Delivery?
Projects end before their value arrives. The system goes live, the team disperses, the boards come off the wall, and the saving or the improvement that justified the whole thing appears, if it appears, some months later in somebody else's operation. That gap is ordinary and it is where most business cases quietly fail, because nobody was holding the benefit at the moment the project stopped holding it.
A benefits management plan is the document that closes the gap. The PMBOK® Guide Eighth Edition includes it among the artefacts a project maintains in Section 4, and its substance is less about measurement technique than about assignment: who will go and get this, with what, by when.
What the plan has to answer
What the benefit actually is, in operational terms. Not a strategic phrase, but something an operations manager would recognise: four hours a week back on the reconciliation team, a reduction in repeat contacts, an extra eleven percent throughput at the picking station. A benefit that cannot be described in the language of the people who will experience it has not been thought through.
How it will be measured, against what baseline. The measure and its source, and the figure it will be compared with. This is the part with a deadline attached, because the baseline can only be captured before the change happens.
When it should appear. Benefits have a shape over time: some arrive at go-live, most arrive after a period of adjustment during which performance is usually worse, and some depend on a later event such as a contract renewal. Stating the expected profile prevents both the premature conclusion that it has failed and the indefinite patience that lets it fail unnoticed.
Who owns it. A named person, in the receiving organisation, who has agreed to be accountable for the benefit appearing and has the authority to make the changes it depends on. This is the line that most plans leave as a job title, and a job title cannot be asked how it is getting on.
The baseline you cannot capture later
Measure before, deliberately. Once the new process is running, the old performance is gone and what replaces it is recollection, which is generous. Capturing the current figure is usually a week of work and it has to happen before go-live, which means it sits in the delivery plan rather than in a post-implementation activity nobody has scheduled.
Be honest about attribution. Operations change for many reasons at once: volumes move, a competitor does something, another project lands in the same quarter. A plan that claims every subsequent improvement for the project invites reasonable people to disbelieve all of it. Stating what else was happening, and what proportion is plausibly attributable, is what makes the claim credible to a finance director who has seen a few of these.
An implementation whose savings needed a decision
A software company implemented a new case management platform for an insurer's complaints team. The business case rested on a reduction in handling time of about twenty per cent, which the platform genuinely delivered: measured after eight weeks, average handling was down twenty-three per cent.
The saving in the business case was expressed in money, and the money required one of two things to happen. Either the team handled more cases, which meant taking work back from an outsourced provider, or it became smaller, which meant not replacing leavers. Both were real options, both were reasonable, and neither belonged to anybody. The project manager had no standing to take either decision, the complaints manager had not been asked and had no incentive to shrink her team, and the outsourcing contract had a notice period that had quietly passed three weeks before go-live.
Eighteen months later the platform was well regarded, the handling time improvement had held, and not one pound of the business case benefit had been realised. The team was the same size, doing the same volume, more comfortably.
What the insurer changed afterwards applied to every subsequent project. The benefits plan had to name a benefit owner in the operating business, who signed it, and it had to name the decisions the benefit depended on with the dates by which they had to be taken. On the next implementation that produced an uncomfortable conversation in month two about the outsourcing notice period, which is precisely the conversation that should have happened the first time, eleven months before it became impossible.
Ownership across the handover
Name the owner before closure, in writing, with their agreement. An owner who learns about the benefit at the closure meeting has been handed a target rather than a responsibility. Involving them while the design is still moving also improves the design, because they will say which benefits are actually collectable in their operation.
List what else has to happen. Almost no benefit arrives from a delivered system alone. It needs a process change, a decision about capacity, a contract renegotiation, a policy amendment. Those dependencies belong in the plan with owners and dates, and most of them lie outside the project's control, which is exactly why they need to be visible before the project loses its convening power.
Keep a measurement point after the project has gone. A review at six or twelve months, scheduled while the project still exists to schedule it, with the benefit owner presenting. This is the only mechanism by which an organisation learns whether its business cases are worth anything, and it is the first thing dropped when the team disbands.
For a PMP® candidate, the useful reading is that value is realised after delivery by the receiving organisation, so a scenario about a successful delivery with no visible benefit is asking who was accountable for collecting it. A response that measures more carefully leaves the ownership question untouched. A structured PMP exam preparation course works at situations where the project delivered exactly what it promised and the value did not arrive.
Two lines are worth writing this month. Who, by name, will be accountable for the benefit twelve months after go-live, and what decisions outside this project have to be taken for it to appear. If the first name is yours, the plan has a problem, because you will not be there.
Interested in going further?
The distance between a delivered output and a realised benefit is measured in decisions other people have to take. Omega's PMP® Exam Preparation works through value and benefits as accountabilities that outlive the project.
The benefits management plan is one of the artefacts described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A168: Business Case vs Project Charter: What’s the Difference?
A169: Assumption Log vs Risk Register
A170: Decision Log: The Forgotten Project Control
A171: Change Log vs Issue Log
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
