Why Project Governance Fails so Often

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 unremorseful fan of the alternative value-based governance model because it facilitates the realisation of commercial outcomes from the beginning of a project, rather than after it's completed and everyone's gone home. I put the excellent work of Bjarte Bogsnes and "Beyond Budgeting" squarely in this space.

But some people have suggested that traditional project governance is also all about the delivery of value .. aka the “benefit” side of the “cost/benefit” model, or the 'business case".

I agree in theory.? In practice though, it’s the furthest thing from the truth.

Let's dissect the traditional model to highlight how silly it really is .. in practice.

The two phases of all projects

Regardless of your delivery model (traditional, agile, cowboy..) .. projects happen in two broad phases: pre-delivery and delivery.

Pre-delivery is where we come up with the business case and secure funding.?

Some time after that, the delivery phase. We hire a team and get on with the job of delivering (in theory at least) the promised business benefit.

There's usually a significant gap between the development of the business case and the commencement of delivery, mostly due to annual budgeting cycles. This is the bit Bogsnes addresses in Beyond Budgeting.

In this edition, I’m going to argue:

1. Clarity of the “business benefit”, or the “commercial outcome” we’re striving for, never survives the gap between pre-delivery and delivery phases.
2. Even if it did, the traditional delivery model has no mechanism to govern the delivery phase according to the value the team is delivering.? Instead it uses “scope” and/or a “project plan” or “timeline”.??

Pre-delivery: clarity of purpose (aka business benefit)

A big chunk of my 300 or so projects have been “rescues” or “turnarounds”.

What I’ve noticed from these are some key patterns with respect to clarity of purpose:

• The benefits “statements” (wording) are often out of sync with the actual commercial figures presented when we’re seeking funding.? We might say “we need to replace the call centre system”.? We might go so far as to mention customer self-service, customer satisfaction or efficiency improvements.? But the funding is granted on the basis that we will reduce call centre costs by $80m per annum by reducing the average call handling time by 30%.
• There are usually too many “benefit statements” or “objectives”.? Any more than one objective is too many because different objectives are owned by different sponsors.? Customer satisfaction is owned by marketing but efficiency is owned by the call centre manager or more likely the CFO (because the call centre manager has a conflict of interest).? More than one benefit statement means that we have more than one boss.? This was one of the things I’d fix first, I’d break the project into multiple projects with different sponsors, which invariably lead to sequencing the projects rather than running them in parallel (to mitigate both the organisational change and financial risks).
• The people involved in pre-delivery are rarely involved in delivery. The pre-delivery team is invariably handled by a bunch of resources attending to the pre-delivery phase on a part time basis, while doing other things full time.? This is because pre-delivery is a drawn out process and generally paid for out of operational budgets rather than project budgets.? By the time funding is approved, these resources are usually working full time on something else, or they move onto the pre-funding phase of another project.? Invariably, so much time has passed that they’ve simply moved on.
• The business benefit model, which is normally in spreadsheet form, isn’t shared with the delivery team.? In some cases this is just an oversight, but more often it’s seen as commercially sensitive because it’s often about reducing costs.?

Practically, this means the delivery team can’t state what they’re trying to achieve in terms of “business benefit”.? I can ask everyone one the delivery team “what are we trying to do here?” and no one will say “cut average call handling time by 30%”.

I argue that we can’t deliver any project unless our entire team can state simply the outcome we’re trying to achieve.??

My favourite quote is Lewis Carrol’s Cheshire Cat: "If you don't know where you are going, any road will get you there."

It’s not good enough to translate the objective into a specification and/or project plan because delivery is a complex thing.? I mean “complex” here in the way that it’s defined in complexity theory, rather than “complicated”.? Imagine that instead of saying to someone “drive to the post office in Brisbane” I give them a 200-step turn-by-turn list of directions.? Do we think they’re going to get there?? No, the smallest mistake in the plan or on the part of the driver will scupper the whole thing.? It’s quite possible that with one mistake, the driver will end up in Orange or Cunnamulla.

Delivery: missing link between "benefit" and "decisions made"

Let’s suspend our disbelief for a second and imagine that our objective of “reduce average call handling time by 30%” has survived and been communicated well to the whole delivery team.? Everyone on the team uses this phrase on a daily basis, we all know what “good” looks like when we’re finished.

Now we run into problem #2: Traditional delivery has no way of driving the work conducted from the original benefit statement.?

Extending the driving analogy, we’re in a car and we’re ready to go to the post office in Brisbane, but someone’s taken off with the compass, the map and the steering wheel.? This sounds absurd, but that’s how I feel about traditional delivery.

To govern according to our goal, we need a way of linking our day-to-day decisions to the goal.??

In traditional delivery, the decision to work on a particular thing is based on whether “the business” requires it. ??

If the business "requires" a thing and it’s deemed “in scope” then we include it in our work schedule.

Given that the pre-delivery “scope” is pretty nebulous and “the business” is going to cover all their bases, this leads to a “kitchen sink” approach. If there’s a risk someone might complain about something being excluded after we’re finished, then it will be included as a requirement because no one wants to be the butt of post-project criticism.

In our call centre example, at no point do we push back on "the business" because their requirement has no bearing on average call handling time. This is not a conversation that ever happens. The business "requires" and we include it in our work.

This is further compounded by the “everything released to everyone at once” approach used in almost all traditional projects, including agile ones in practice.? We’re not able to release the most valuable features earlier in the project to get some runs on the board, so we don’t find out until it’s all over whether we’ve actually achieved our objective.?

In my experience the business outcome is almost never measured, let alone tracked.

So even if we had perfect clarity of purpose from the pre-delivery phase, the traditional delivery methodology has no in-built techniques for ensuring we deliver to that vision. We are driving a parked car.

Silly, no?

My direct real-world experience is somewhat less optimistic than only "52% of projects fail", more like the 75% faiulre metrics from the old Standish, Chaos and US Department of Defence studies done in the nineties and noughties. I do accept the higher quality of the Project Management Institute's surveys and I love their definition of "success" because it's more "was it worth the money and effort" rather than the traditional "was it on time and on budget" .. the latter being particularly meaningless.

My scepticism is quite possibly due to selection bias given my background in rescues/turnarounds - but I’d love to see more organisations abandoning this traditional pre-delivery / delivery approach for a simple value-based governance approach.

I'll do an edition on value-based governance soon.