Theory Meets Practice: What a PRINCE2 Training Course Teaches Us About the Real Reasons Projects Fail

Why projects really fail — and what PRINCE2 has to say about it

The figures are well known and yet still shocking: for years the Standish Group’s Chaos Report has counted roughly two thirds of IT projects as failed or challenged — cancelled, or significantly missing their cost, time or quality targets. The figure needs reading with care: Standish does not release the underlying data, and an analysis in IEEE Software finds the method unsound. It works as an order of magnitude, not as evidence — and it covers IT projects, not projects in general. The most commonly cited causes? Poor communication, unclear requirements, insufficient resources.

But if you look more closely, there is often a different problem at the root: projects fail because of meaning — not methods.

The 5 most common patterns when projects go off the rails:

• 1. The Business Case exists — but is never looked at again
• 2. Roles are defined, but accountabilities are unclear
• 3. Risks are identified, but nobody actively manages them
• 4. Plans are detailed — but nobody actually works to them
• 5. The sponsor is nominated — but not truly engaged

PRINCE2 addresses all of this — with a consistency and structure that impresses me anew every time I teach it. The framework does not begin with planning. It begins with a fundamental question: Is it even worth starting this project?

The Business Case: The underestimated heart of PRINCE2

In the training I asked: “How many of you have written a Business Case at the start of a project and actively developed it throughout?” The answer: silence. Then, gradually, a few hands.

That is not a criticism — it is reality. Business Cases are often seen as a bureaucratic obligation, not as a living management tool. PRINCE2 sees it differently: the Business Case legitimises a project — and a project loses its justification when the Business Case no longer holds true.

In theory, this sounds logical. In practice, it requires courage: the courage to stop a project when the benefit has disappeared. That is uncomfortable. But it is professional.

The discussion that changed the training

At some point, one participant — a project manager from a mid-sized company — asked directly: “But what do I do when I know that the project no longer makes sense, yet my management refuses to stop it?”

That was the moment the training stopped being a methodology course — and became a genuine practical discussion. We spent a good half hour talking about it. Stakeholder management, escalation paths, the role of the Project Board in PRINCE2. And above all: how do you make yourself heard within the hierarchy without failing politically?

Practical recommendations from the discussion:

• Review the Business Case regularly in the Steering Committee — not as a formality
• Document deviations from the expected benefit early and objectively
• Use Exception Reports to inform management — without drama
• Define tolerances clearly: what does the team decide, and what must be escalated?
• Actively involve the sponsor — they are responsible for the benefit, not just the budget

What the participants took away — and what surprised me

In the end, everyone passed the PRINCE2 Foundation and Practitioner certification. Not because the framework is simple — but because they understood the why behind the processes.

The feedback was clear: what stuck most was not the process diagrams or the seven principles. It was the moments when theory and personal project experience collided — and what had previously just been 'that's the way it is' suddenly made sense.

And me? I took something away too. During the discussion about Exception Reports, one participant showed me a formulation she had developed in her organisation: a two-sentence escalation note containing exactly the right information, without assuming too much prior context. Simple, effective, immediately usable. It is now part of my own template collection.

You never stop learning. Especially not when you are the trainer yourself.

The key insight: methodology is never the problem

PRINCE2 does not fail. Projects fail. And usually not because nobody knows the method — but because nobody applies it consistently.

That sounds harsh. But it is. And at the same time, it is the most encouraging message of all: the tools are there. You just have to use them.

Sources

• The Standish Group: Chaos Report — an ongoing survey of IT projects running since 1994. The underlying data is not public and the sample is predominantly US-based.
• Eveleens, J. L. / Verhoef, C. (2010): The Rise and Fall of the Chaos Report Figures. IEEE Software 27(1), pp. 30–36 — the standard methodological critique of the Chaos figures.
• AXELOS / PeopleCert: Managing Successful Projects with PRINCE2 — the basis for the principles, themes and processes referred to here.