When Delivering the Scope Destroys the Value

The project closed on time. The scope was delivered in full, the final report was green, and the sponsor signed the closure paper without a single query. Eighteen months later the organisation was measurably worse off than it had been before the work started, and nobody involved had done anything wrong by the standards they were being measured against.

So can a project be successful and still destroy value? It depends entirely on which question you are asking. A project can perform well against everything in its baseline and still leave the organisation carrying more cost, more risk or less capability than it had before. This happens more often than the tidy language of delivery reporting suggests, and recognising it early is one of the more valuable things a project manager does. It also rarely appears anywhere on a status report, because status reports are built to answer a different question.

Delivery performance and project success are different questions

Delivery performance asks whether the project produced what was planned, within the agreed time and cost, to the agreed quality. It is a question about the project as a piece of managed work, and it is entirely reasonable to ask. Most reporting, most governance meetings and a good deal of professional pride are organised around it.

Project success asks something harder: whether the work created outcomes worth having for the people who paid for it and the people who have to live with it. That question cannot be answered from inside the project's own measurement system, because the project's measurement system was designed around the plan rather than around the benefit. This is consistent with Section 2.1.2 of The Standard for Project Management, which treats the assessment of project success as broader than the classic scope, schedule and cost measures, and accepts that a project can meet its baseline and still fail to create sufficient value.

Most of the time the two questions give the same answer, which is why the distinction is easy to lose. A well-run project delivering a sound business case usually does create value, and treating delivery performance as a proxy for success is a reasonable shortcut on a short project in a stable environment. The shortcut breaks down when the environment moves, when the deliverable changes the cost of running the organisation, or when the original benefit was never measurable in the first place. On a two-year programme in a changing regulatory or commercial setting, assuming the two questions are the same is closer to a gamble than a judgement.

Four ways completed scope leaves an organisation worse off

The first and most common is that the value case moved and the scope did not. The business case was written against a set of conditions, and those conditions changed during delivery. The project kept building what was approved, because that is what change control protects, and nobody re-examined whether the approved thing was still the right thing. Change control is doing exactly its job here. The failure is that no one triggered the wider question.

The second is that the deliverable transfers cost into operations. A system, an asset or a process is handed over that works precisely as specified but requires more licences, more support, more manual reconciliation or a skill the receiving team does not have. The project's cost baseline closed cleanly. The organisation's cost of running increased permanently. Whether that is acceptable depends on the benefit, and the benefit needs to be checked rather than assumed.

The third is timing. Some benefits are only worth having inside a window: ahead of a competitor, before a regulatory deadline, during a funding cycle, while a commercial partner is still interested. Delivering the full scope four months late can be a proportionate schedule variance and a total loss of value at the same time. Delivering a reduced scope on time would have been the better decision, and it is a decision that has to be made early enough to matter.

The fourth is opportunity cost, which almost never appears in project reporting. Finishing every remaining item of scope consumes capacity that had a more valuable use elsewhere in the portfolio. The last twenty per cent of a scope frequently carries a small fraction of the benefit while absorbing a disproportionate share of the scarce people. That is a portfolio judgement rather than a project one, but the project manager is usually the person best placed to see it first.

A repairs system that worked exactly as specified

A housing association managing around eleven thousand homes approved a replacement repairs scheduling system. The business case rested on two measurable benefits: fewer missed appointments, and fewer repeat visits caused by sending an operative without the right parts. The numbers were credible, the supplier was competent, and the project ran predictively with a clear scope and a firm go-live date.

Eight months before go-live, the organisation's reporting obligations around damp and mould reports tightened. Tenants' reports in that category now needed to be logged, categorised, tracked and escalated on a defined timescale. The requirement was raised, assessed against the approved scope and correctly recorded as out of scope for the current phase. The change control process worked as designed. What did not happen was anybody asking whether the business case still held, given that the operational teams now had a substantial new reporting need the new system could not meet.

The system went live on time and delivered both original benefits. Missed appointments fell. Repeat visits fell. Meanwhile the housing officers and surveyors had built a parallel spreadsheet to capture the reports the system could not hold, and were manually reconciling it against the scheduling data every week. The reconciliation cost more staff time than the scheduling improvement saved, and it introduced a data risk in exactly the area the organisation could least afford one. The scope was delivered in full, and the organisation ended up worse off.

Raising it without appearing to lose confidence in your own project

The practical difficulty is rarely recognition. Project managers usually sense this well before anyone else, because they can see the operational workaround being designed in the corridor. The difficulty is that raising it feels like arguing against your own project, and can be heard as a lack of commitment or a preparation for failure.

Learn to notice the cues rather than waiting for a formal signal. The benefit owner who used to attend the steering group has gone quiet. The metric in the business case is no longer one the organisation actually reports on. A stakeholder group that mattered has been reorganised. The receiving team starts building a workaround months before go-live. Somebody uses the phrase "we can fix that in the next phase" about something that was central to the justification. None of these prove the value case has broken, but each is a reason to test it properly. If you want to develop this kind of judgement in a structured, instructor-led setting, the PMP® Exam Preparation course works through the same reasoning across governance, value and change decisions.

When you do raise it, bring evidence rather than an opinion. Set out the benefit as it was originally stated, what has changed since, what that does to the expected value, and two or three options with their consequences: continue as planned, adjust the scope, resequence to protect the benefit that still exists, or stop. The decision belongs to the sponsor or the governance body, and framing it as their decision is what makes the conversation possible. Your job is to make the choice visible and informed, not to make it yourself.

Some responses would be premature. Quietly descoping to protect the benefit without authorisation removes the very governance that should be deciding. Telling the team the project has become pointless costs you the delivery you may still need. Escalating before you can articulate the effect on the benefit produces alarm rather than a decision, and spends credibility you will want later.

The approach also changes the mechanics. On a predictive project the machinery exists already in change control and business case review, and the usual failure is that nobody pulls the trigger. On an adaptive project reprioritisation is normal, but a backlog can drift steadily towards locally useful items while the whole investment quietly stops adding up, so somebody still needs to hold the overall value view. On a hybrid project the risk sits in the seam, where the iterative work reprioritises freely and the fixed-scope workstream carries on regardless. In all three, a scheduled value review, separate from delivery reporting and attended by whoever owns the benefit, is worth more than any amount of additional status detail.

For a PMP® candidate, the useful thing here is not a definition. The 2026 PMP Examination Content Outline places value-based delivery inside the Process domain, with tasks that include examining business value throughout the project and checking that a measurement system for benefits is actually in place, and it puts governance escalation paths and thresholds in the Business Environment domain. Read those together and the expected behaviour is fairly clear: value is monitored continuously, not confirmed at closure, and there should be a route to raise it when it moves. In scenario questions, the recognisable pattern is a project performing well against its plan while something in its justification has quietly changed. The response that treats "we are on track" as sufficient is usually the weaker one.

On real projects the payoff is more direct. Organisations tend to remember whether an investment was worth making rather than whether it closed within tolerance, and the project manager who raised the awkward question at month fourteen is remembered differently from the one who delivered a full scope into a problem everyone could see coming. Delivering the scope is the commitment you made. Checking that it is still worth delivering is the judgement you were hired for.

Andre Malowney

Interested in going further?

Deciding when a value case has genuinely moved, and how to put that in front of a sponsor without losing the room, is a judgement that improves considerably with structured practice and discussion. Omega's PMP® Exam Preparation course works through governance, business value and change decisions in the same way, using realistic project situations rather than definitions.

If you want to read how the profession now frames project success beyond scope, schedule and cost, the PMBOK® Guide Eighth Edition sets out that broader view alongside the value delivery system it sits within.

Ad · Amazon affiliate link.

References

A011: Project Success Is More Than On Time and On Budget
A203: How to Handle Competing Constraints in a PMP Scenario
A014: Intended Value vs Realised Value
A013: Value Delivery in Project Management: What It Means in Practice
A012: Outputs, Outcomes, Benefits and Value: What’s the Difference?

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