Why Do Projects Fail Despite Good Governance?

There is a particular kind of project failure that nobody quite wants to own. Not the failure caused by a missing risk register, or a sponsor who was never engaged, or a plan built on guesswork. Those failures are explicable. They have a clear villain: something wasn't done properly.

This is the other kind. The stage gates were passed. The RAID log was maintained. The steering group met on schedule, minutes were taken, actions were assigned. Somewhere in a folder is a beautifully formatted status report, correctly colour coded, that flagged the exact problem that eventually sank the project, weeks before it did.

And still it failed.

This tends to produce two unhelpful reactions. The first is to conclude that governance itself doesn't work, that it's overhead dressed up as assurance, ceremony without teeth. The second is to double down: more reports, more gates, an extra layer of sign off, on the theory that the last failure happened because there wasn't quite enough process yet. Neither reaction is right, and both come from looking at the wrong layer of the problem.

Governance frameworks, whatever flavour you're trained in, are built to do one job well. They surface information. A properly run risk register makes a threat visible. A status report makes drift visible. A stage gate makes a decision point visible, forcing someone to actually look at the project rather than assume it's fine because nobody's complained. What none of these mechanisms do, and what none of them were ever designed to do, is guarantee that anyone acts on what's been surfaced.

That gap, between visibility and action, is where most well-governed projects actually die. It rarely announces itself. Nobody stands up in a steering group and says the risk doesn't matter. What happens instead is quieter and more familiar: the item gets logged, discussed, assigned an owner, and then carried forward. Next meeting, same item, still amber, still assigned to the same owner, who has by now said "still working on it" three times running without anyone asking what working on it actually means. The register is doing its job. The organisation around it has stopped doing its job of taking the register seriously.

A PMO manager once described this to me as the difference between a smoke alarm and a fire brigade. The alarm's entire function is to make noise when something's wrong. It has done its job the moment it goes off. Whether anyone gets up off the sofa is a separate question, and it's the one that actually determines whether the building burns down. Most governance frameworks are extremely good smoke alarms. The failure isn't in the alarm. It's in how many meetings can go by with it quietly going off in the background while everyone in the room has learned, over months, to treat that particular sound as ambient noise rather than information.

This is where the psychology of a project team matters more than the template it's using. A risk that's been amber for eight consecutive reporting cycles stops reading as urgent and starts reading as normal. Escalating it starts to feel like making a fuss about something everyone's already aware of, which is precisely backwards, since staying aware of a risk without escalating it is what allows it to keep drifting. Sponsors disengage from reports that never seem to change, which removes exactly the pressure that would force a change. Project managers, reasonably enough, stop pushing on issues nobody above them seems to want pushed. None of this shows up as a governance failure on paper. The paper looks fine. It's the behaviour around the paper that's failed.

None of this is an argument against structure. A project with no framework at all doesn't have this problem because it doesn't have anything surfacing the risk in the first place, which is a considerably worse position to be in. The frameworks are doing exactly what they were built to do. The mistake is expecting them to also do the part that was always going to depend on people: noticing that the smoke alarm has been going off for two months, and being willing to say so plainly, even when it's the fourth meeting in a row and everyone would rather move to the next agenda item.

It's worth being specific about what that looks like in practice, because "escalate properly" is easy to say and genuinely awkward to do. It rarely means a dramatic intervention. More often it means one person, in an otherwise routine meeting, declining to accept the same status update they've accepted the last three times. Not louder, not more formal, just less willing to let "still working on it" pass without a follow-up question about what's actually changed since the last time that phrase was used. That single habit, repeated consistently across a project, does more to keep a risk register honest than any amount of additional formatting or extra reporting fields ever will. It costs nothing to implement and it's still rare, because it requires a kind of low-grade social friction that most teams, quite understandably, would rather avoid.

The projects that actually hold together under good governance aren't the ones with the most detailed trackers. They're the ones where somebody in the room is still willing to ask, out loud, why an amber item is still amber, and where that question is treated as the job working correctly rather than as friction to be managed around. That's not a template problem. It's harder than a template problem, because it depends on people continuing to react to information they've already seen many times before, which is precisely the thing human attention is worst at doing reliably. If you're looking at your own project's trackers and wondering whether the numbers are telling you something the room has quietly stopped hearing, that's usually the question worth asking first, and it's one I'm always happy to talk through if you want a second perspective, so feel free to get in touch about your project training and delivery options.

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.