Why Your PRINCE2 Project Keeps Failing Without a Business Case Discipline Behind It

There is a particular kind of project failure that PRINCE2 practitioners find harder to explain than the obvious kind. Nobody missed a stage boundary. The highlight reports went out on time, RAG status mostly green, risks logged and reviewed. The board minutes look tidy enough to use as a training example. And yet, eighteen months in, someone finally asks the question that should have been asked at every gate along the way: why are we still doing this, and is it still worth what it's costing?

Nobody has a good answer. Not because the answer doesn't exist, but because nobody has been keeping it current.

This is not a governance failure in the sense most PRINCE2 training treats governance. The stages happened. The tolerances were set. The exception process, if anyone had needed it, was ready to go. What was missing sat underneath all of that structure, in a document most teams treat as a formality to clear at initiation rather than a discipline to maintain throughout: the business case itself.

Picture a fairly typical mid-sized transformation programme. At initiation, a business case gets built, reviewed, approved, filed. It does its job. It gets the project through the gate. From that point on, the project board's attention moves to delivery, because delivery is where the visible risk sits. Milestones slip, suppliers underperform, scope gets renegotiated under pressure, and each of those moments gets logged, escalated, and resolved through the normal PRINCE2 machinery. What doesn't happen, in scores of projects that otherwise look well run, is anyone going back to the original business case and asking whether the reasons for doing this project at all still hold. The assumptions behind the benefits were set against a market, a budget, a set of dependencies that existed at initiation. None of those things stay fixed for eighteen months. The business case does, because nobody owns the job of unfixing it.

PRINCE2 itself does not let this slide by accident. Continued business justification is one of its seven principles, not a nice-to-have bolted on afterwards. The method is explicit that a project should remain justified throughout its life, and that if it stops being justified, it should stop. That principle is sound and rarely disputed by anyone who has sat through PRINCE2 training. Where it quietly falls apart in practice is that the principle tells you the business case must stay valid. It does not tell you how to build one robust enough to be tested meaningfully, or what testing it should actually look like at each stage boundary beyond a tick-box confirmation that nothing has obviously changed.

That gap is exactly what Better Business Cases and the Five Case Model exist to close, and it is a narrower, more practical thing than its public-sector reputation suggests. Built around HM Treasury's Green Book methodology, it structures a business case across five distinct dimensions: whether the case is strategically sound, whether the economic appraisal actually stacks up against realistic alternatives rather than a single preferred option dressed up as analysis, whether the commercial arrangement is deliverable, whether the financial case is affordable rather than merely approved once, and whether the management case shows the project can actually be delivered as described. A PRINCE2 business case that only answers the strategic and financial questions, which is most of them, has already skipped two-fifths of the discipline that would have caught the drift before it became expensive.

The practical difference shows up clearly at stage boundaries, which is exactly where PRINCE2 already builds in the natural checkpoint. A project board reviewing a stage end report has, in principle, the perfect moment to re-test the business case against the Five Case Model's structure rather than simply confirming the numbers haven't obviously blown up. In practice, that re-test rarely happens with any rigour, because nobody on the board was trained to run it, and the PRINCE2 qualification itself does not teach that skill. The result is a board that is diligently governing delivery risk while leaving justification risk almost entirely unexamined, right up until the point where a change in market conditions, sponsor priorities, or realised benefits forces an uncomfortable and overdue conversation.

It is worth being precise about what actually breaks down, because it is rarely a single dramatic assumption failing. More often it is a slow accumulation of small ones. A benefit that was costed against a supplier rate card that quietly moved. A dependency on another workstream that was descoped without anyone tracing the knock-on effect back to this project's economic case. A commercial arrangement that made sense under one contracting model and stopped making sense the moment the scope shifted, without the financial case being revisited to match. Each of these, taken alone, looks like a minor delivery adjustment, the kind of thing a competent project manager handles without escalating. Taken together, over several stages, they hollow out the original justification until the business case on file bears only a loose resemblance to the project actually being delivered. Nobody lied. Nobody hid anything. The document simply stopped being asked to keep up.

None of this means PRINCE2 needs replacing, or that Better Business Cases is a rival method competing for the same slot. It sits alongside PRINCE2 rather than instead of it, doing a job PRINCE2 assumes is being done but does not itself teach. A project board that pairs PRINCE2's stage discipline with a Five Case Model habit of re-testing the business case at every gate is not adding bureaucracy. It is finally closing the loop that continued business justification was always meant to require. The teams whose projects survive scrutiny eighteen months in are rarely the ones with the cleanest highlight reports. They are the ones who never let the business case go stale enough to need rescuing, because someone kept the discipline alive from the first stage boundary onward. If you're not sure whether your own board's business case would survive that kind of scrutiny, it's worth finding out before a stage boundary forces the question, and you're welcome to get in touch about strengthening your project governance.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.