Intended Value vs Realised Value

A project can finish exactly as forecast and still leave the organisation unable to say whether it was worth doing. Deliverables accepted, budget held, closure report signed, and eighteen months later nobody can point to the improvement that justified the money. That gap is not usually a delivery failure. It is the distance between intended value and realised value, and the two are separated by time, ownership and evidence.

Intended value is what the organisation expected to gain when it authorised the work. Realised value is what the organisation actually gains once the output is in use. A project manager who treats those as the same thing tends to stop paying attention at exactly the point where the harder half begins.

Two claims, made at different times

Intended value is a forecast. It is written when least is known, normally in a business case or funding paper, and it usually takes the form of a number attached to an assumption: hours of manual effort released, throughput increased, a regulatory cost avoided, a customer segment retained. That is legitimate work and it deserves to be taken seriously. It remains a prediction rather than an observation.

Realised value is the observation. It appears later, under operating conditions, and it is normally visible to someone other than the project team. It depends on how the output was adopted, on whether the surrounding process actually changed, on what happened in the market while the project was running, and on whether anyone is still measuring by the time the effect would show.

Section 2.1 of The Standard for Project Management places project work inside a wider system for delivering value and makes the point that producing the agreed deliverables is not on its own evidence that value has been created. That distinction is worth holding onto, because it separates two questions that get merged constantly: did the project deliver what it said it would, and is the organisation better off. Both matter. They are different measurements, taken at different moments, and they are capable of disagreeing.

Why the gap opens on projects that were run well

The first reason is structural. The intended value was estimated at the point of maximum uncertainty by people who were, quite reasonably, arguing for funding. Estimates made in that position tend to be optimistic, not because anyone is being dishonest, but because a business case competes against other business cases.

The second reason is that conditions move. A twenty-month programme is a long time for a regulation, a supplier market, an interest rate or an organisational priority to stay still. The intended value can quietly stop being the value the organisation now needs, and nobody notices because the plan is still being delivered accurately against the original premise.

The third reason is the one project managers can do most about. Value is realised through use, and use is a behavioural outcome rather than a delivered one. A system that works perfectly and is operated around delivers nothing. A facility built exactly to specification produces no benefit if the process that was meant to run through it never changed. Delivery ends at handover; adoption starts there.

There is a fourth, more mundane reason. In many organisations no measurement route exists. The reporting that tracked cost and schedule was a project artefact, and it was switched off with the project. Nothing replaced it, so realised value is never established either way. The benefit is not disproved, it is simply unobserved, which over time becomes indistinguishable from not having happened.

What the project manager can reasonably be held to

No project manager can be held accountable for realised value on their own. The benefit usually lands in operations, months after the team has dispersed, and it depends on decisions taken by people who never reported to the project. Pretending otherwise sets up an accountability that cannot be discharged.

Four things do sit inside the role, and they are worth treating as obligations rather than good practice.

Know the intended value in specific terms. Not "improve efficiency" but which activity, performed by whom, reduced by how much, observable where. A benefit that cannot be stated specifically cannot be tested later, and vagueness at the start is what makes disputes at the end unresolvable.

Know who owns the benefit after closure, and confirm that they know it. This is more often missing than the measurement itself. A named operational owner who has agreed to the number is a different situation from a business case signed by a sponsor who has since moved role.

Make sure a measurement route survives the project. The current PMP Examination Content Outline places this directly inside the project manager's work: under the Process domain, the task on value-based delivery includes verifying that a measurement system is in place to track benefits, and the Business Environment domain includes defining success metrics as part of establishing governance. These are described as project management responsibilities, not as something handed off to a benefits function.

Raise it when the premise changes rather than when the plan slips. This is the judgement that distinguishes an experienced project manager. Variance against the plan follows a defined route through change control. A shift in the reason the work is being done does not, and it is easy to carry it silently for months because no process asks the question. If you want to work through that kind of escalation judgement in a structured setting, the PMP® Exam Preparation course develops the same habit across governance, stakeholder and business-environment decisions.

What would be premature is treating every wobble in a benefit assumption as grounds for stopping. Assumptions are supposed to be tested and some will be revised. The threshold is not "an assumption looks weaker than it did". It is closer to "if we were writing the business case today, with what we now know, would this work still be authorised". That question belongs to the sponsor, and the project manager's job is to put it in front of them with evidence rather than to answer it alone.

A metering upgrade that worked and did not pay

A fuel terminal replaces manual stock reconciliation with automated metering. The business case claims two things: around 1.5 full-time equivalents of manual recording and checking released across the shift pattern, and faster identification of loss and gain discrepancies. Delivery goes well. The system is commissioned on schedule, accuracy tests pass, operations accept it.

During commissioning the project manager notices that operators are still writing readings into the paper shift log. Two reasons emerge. The standard operating procedure that mandates the manual record was never updated, because it sits with a technical authority function that was outside the project's scope. And the assurance team wants an independent record maintained until the new figures have a track record. Both are defensible. Together they mean the released effort has not been released, and the discrepancy checking is still being performed on the handwritten numbers.

Nothing here is a delivery failure. The intended value has simply not converted, and it will not convert without a decision that no one has been asked to take. What the project manager does with that observation is the whole of the judgement. Overriding the shift procedure is not hers to do. Recording "delivered" and closing is accurate about the output and misleading about the outcome. Escalating it as a project issue invites the response that the project has done its part.

The useful move is narrower. Before closure, she records the benefit as unrealised, names the specific dependency, the function that owns it and the decision the sponsor now faces, and asks for a date by which the parallel record will be reviewed. That converts a vague future disappointment into a live decision with an owner while there is still someone in the room whose job it is to care.

The delivery approach changes when this becomes visible rather than whether it matters. On an adaptive or incremental delivery the same signal would have surfaced during an early release, when a smaller slice of the system was in real use and the procedure conflict would have been exposed cheaply. In a predictive delivery it typically waits for post-implementation review, which is often too late to be anything but a finding. A hybrid arrangement can get much of the benefit by instrumenting the first operational use deliberately, even where the build itself is planned end to end.

For anyone preparing for the PMP exam, the habit worth building is reading situational questions for which of the two values is under discussion. A scenario about a deliverable being accepted and a scenario about a benefit failing to appear look similar on the page and call for different responses. The second usually requires a stakeholder or sponsor decision rather than a technical fix, and the answer that involves the project manager quietly solving it alone is normally the wrong one.

On a real project, the practical test is simpler than any of this. If your project ended tomorrow, could you name the person who will be able to say, twelve months from now, whether it worked, and could you name what they will look at. If both answers exist, intended value has a route to becoming realised value. If either is missing, the work will be judged on whether it was delivered tidily, which is a much smaller claim than the one made to get it funded.

Andre Malowney

Interested in going further?

Working out what a project manager owns, what belongs to the sponsor and when a shift in the business case justifies escalation is the kind of judgement that is difficult to build from reading alone. Our PMP® Exam Preparation course works through governance, value and business-environment decisions in a structured instructor-led setting, using situations close to the ones above.

The Eighth Edition sets out how project work sits inside a wider value delivery system, which is the source material behind the distinction described here.

Ad · Amazon affiliate link.

References

A012: Outputs, Outcomes, Benefits and Value: What's the Difference?
A013: Value Delivery in Project Management: What It Means in Practice
A015: When Delivering the Scope Destroys the Value
A036: Focus on Value: The Principle Behind Better Trade-offs
A092: How Projects Create Value Through Governance

PMP and PMBOK are registered marks of the Project Management Institute, Inc.