Why Project Governance Fails So Often

  • Traditional governance is broken: It prioritizes scope over actual business outcomes, causing misaligned priorities and chaotic execution.

  • Key failures: No continuity between planning and delivery phases, bloated scopes, and no mechanism to connect decisions with original goals.

  • Value-based governance is the fix: It bridges the gap and ensures every decision supports clear, measurable results.

Traditional project governance is so broken, I'm surprised projects only fail 52% of the time (according to the Project Management Institute 2024 report).

I'm an unapologetic fan of the alternative value-based governance model because it prioritises commercial outcomes from the start of a project, rather than waiting until everything’s done and dusted. I credit Bjarte Bogsnes and his "Beyond Budgeting" approach as a standout in this space.

But some argue that traditional project governance is also focused on value delivery — the “benefit” side of the “cost/benefit” equation or the “business case.”

Theoretically, that’s true. Practically, it’s far from the truth.

Let’s dissect the traditional model to highlight how flawed it is in real-world scenarios.

The Two Phases of All Projects

No matter the delivery approach (traditional, agile, cowboy...), projects have two broad phases: pre-delivery and delivery.

  • Pre-delivery: This is where we develop the business case and secure funding. 

  • Delivery: After funding is approved, a team is assembled to deliver on the promises (in theory).

However, there’s often a significant gap between these phases due to annual budgeting cycles. This delay is precisely what Bogsnes challenges in "Beyond Budgeting."

In this edition, I’m arguing two key points:

  1. Clarity of the business benefit (or commercial outcome) rarely survives the gap between pre-delivery and delivery phases.

  2. Even if it does, the traditional delivery model lacks mechanisms to govern the delivery phase in alignment with value. Instead, it relies on scope, project plans, or timelines.

Pre-Delivery: The Lack of Clear Purpose

Having worked on 300+ projects — many of them rescues or turnarounds — I’ve seen recurring patterns when it comes to clarity of purpose:

  • Benefit statements vs. funding criteria: Benefit statements in business cases are often misaligned with the funding justification. For instance, a project may claim to “improve customer satisfaction,” but the funding hinges on a hard savings promise, like cutting call centre costs by $80 million annually through a 30% reduction in average call handling time.

  • Too many objectives: More than one objective leads to chaos. Different objectives are often owned by different stakeholders. For example, customer satisfaction may be owned by marketing, while efficiency improvements belong to the CFO. Projects with multiple objectives inevitably suffer from competing priorities. In turnarounds, my first step is often splitting these into smaller, sequenced projects.

  • Pre-delivery and delivery teams are separate: Pre-delivery is handled by part-time resources juggling other responsibilities. By the time funding is secured, those people are busy elsewhere or no longer available. Consequently, the delivery team lacks continuity and critical knowledge.

  • Business benefit models aren’t shared: Often, benefit models (usually spreadsheets) are treated as commercially sensitive or simply overlooked. This means delivery teams don’t know the actual goals they’re supposed to achieve.

The Result?

Ask a delivery team, “What are we trying to do here?” and they won’t tell you “reduce average call handling time by 30%.” Without clarity of purpose, a project has no hope of success. As Lewis Carroll’s Cheshire Cat said: "If you don't know where you are going, any road will get you there."

Let’s imagine the pre-delivery team perfectly articulated the business goal: “reduce average call handling time by 30%.” Everyone on the delivery team knows this is the aim.

Now comes the next problem: traditional delivery provides no way to connect day-to-day decisions with the stated goal.

  • Scope-driven delivery: Decisions in traditional delivery are dictated by scope. If “the business” deems a feature “in scope,” it’s included. There’s no mechanism to challenge requirements based on their impact on business outcomes. In our example, no one pushes back on a scope item by asking, “How does this reduce call handling time?”

  • Kitchen sink mentality: To avoid post-project criticism, stakeholders include every conceivable requirement, relevant or not. This results in a bloated scope that detracts from the original objective.

  • Delayed validation: Features are typically released all at once, leaving no room to test whether the project is delivering value incrementally. By the time the project is complete, it’s too late to fix mistakes or pivot.

In the end, the connection between the original business benefit and delivery decisions is completely severed. We are driving a car with no compass, map, or steering wheel.

Silly, No?

Based on my experience with turnarounds, I believe the true failure rate of traditional projects is closer to 75% (as suggested by older Standish Group and US Department of Defence studies), not the PMI’s 52%. While the PMI's definition of success — "Was it worth the money and effort?" — is more meaningful than "Was it on time and on budget?", traditional project governance still falls short.

The good news? There’s a better way. Value-based governance eliminates the pre-delivery/delivery gap and focuses on ensuring that every decision supports the project’s commercial outcomes.

I’ll cover value-based governance in an upcoming edition.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.

Reply

or to participate.