Why Project Governance Fails — and What Good Governance Actually Looks Like

Ask most project managers what they think of governance and you’ll get a weary answer. Governance means meetings that go on too long. Governance means reports that nobody reads. Governance means a steering group that last met six months ago and can’t remember what the project is trying to do.

That cynicism is understandable, because a lot of governance is genuinely bad. But it exists because the problems that governance is supposed to solve are real. Projects go wrong when nobody is checking that the delivery is still aligned with the strategy. They go wrong when decisions can’t be made because nobody is clear who has the authority to make them. They go wrong when problems stay hidden because there’s no mechanism to surface them safely.

Bad governance doesn’t solve these problems. It creates the paperwork of solving them without doing the actual work. Good governance – which is rarer than it should be – solves them efficiently and proportionately.

Here’s what I’ve learned about the difference.

What governance is actually for

At its simplest, governance exists to maintain alignment between what an organisation is trying to achieve strategically and what a project team is actually delivering.

This sounds obvious. It isn’t. Projects exist in time, and over time things change: the original problem evolves, constraints shift, the environment changes, the organisation’s priorities move. A project that was perfectly aligned with its strategic objectives at initiation can drift significantly over a year of delivery without anyone deliberately deciding to let it drift. Governance is the mechanism that keeps checking whether the drift has happened and, if it has, deciding what to do about it.

The other core function of governance is decision-making. Projects constantly generate questions that can’t be answered within the project team: questions about resources, about scope, about risk tolerance, about trade-offs between time, cost, and quality. Governance structures exist to make sure those questions reach people with the authority and knowledge to answer them, and that the answers get made in time to be useful.

Everything else – the templates, the reports, the meetings, the logs – is in service of those two functions. The moment governance activity stops serving alignment or decision-making, it has become bureaucracy.

How you can spot this happening

The project initiation document that nobody updates. Almost every project produces a PID at the start. Far fewer treat it as the living document it’s supposed to be. A PID written at initiation and filed away is not governance; it’s a time capsule. The document should evolve as the project evolves – capturing the decisions made, the changes to approach, the adjustments to scope. When it doesn’t, you lose the institutional memory of why things are the way they are, and you lose the mechanism for checking whether the current delivery still reflects the original intent.

The board that can’t make decisions. A programme board should be an advisory body to the sponsor, not a committee that governs by consensus. In practice, many governance boards operate as if every decision requires unanimous agreement, which means every significant decision gets deferred. The sponsor – the person with ultimate accountability for the project – often allows this because it feels safer not to make decisions publicly. The result is a project that’s waiting on decisions that should have been made months ago, with the project team working around the gaps as best they can.

Registers as compliance rather than management tools. Risk and issue registers are the core operational tools of a project manager, not documents you produce to satisfy a governance checklist. A risk register that isn’t reviewed every team meeting, that isn’t known inside-out by the project manager, that isn’t brought to governance meetings as a live management document – that register is not managing risk. It’s recording the historical existence of risk management activity for someone else’s benefit.

I’ve walked into projects where the risk register hadn’t been updated since the project kicked off and the issue log had entries from eighteen months ago that were still “Open.” In both cases, the project team had been managing by informal conversation, bilateral email, and collective memory. The formal registers existed, passed cursory inspection, and did nothing useful.

Highlight reports that nobody challenges. The purpose of a highlight report is to give governance stakeholders an accurate picture of where the project is and what decisions are needed. The purpose of the audience is to read critically, ask questions, and challenge where the picture doesn’t match their understanding. When boards receive highlight reports and nod them through without discussion, they’re not governing – they’re witnessing. The project team learns, over time, that honesty in reporting isn’t rewarded, and the reporting gradually becomes more optimistic and less useful.

The wrong people in the room. Governance meetings are expensive. They require time from senior people who have many competing demands. When that time is used for updates that could have been sent by email, or for discussions that require specialists who aren’t present, or for decisions that needed to be made two weeks ago and are now moot, the opportunity cost is significant. Senior leaders start finding reasons not to attend. The meetings become less and less effective. Eventually they’re cancelled or reduced to formality.

What good governance looks like

It is proportionate. A six-month project with a small team and a single workstream does not need the same governance infrastructure as a five-year programme across six organisations. The fundamental elements are the same – a clear objective, a mechanism for alignment, a decision-making structure – but the weight and formality should match the size and complexity of the programme.

It is active. The risk register is reviewed at every team meeting, and the project manager knows it without having to look. The issues log is worked daily. The highlight report reflects the actual situation, including things the team doesn’t want to report. The board asks hard questions and expects honest answers.

It maintains a clear thread from strategic objective to deliverable. The strategic intent of the project – why the organisation is spending this money and this effort – should be traceable through the project documentation all the way to the specific work being done. When that thread breaks, the project may still deliver its outputs without delivering anything of value.

It enables decisions. Governance meetings have clear standing items for risks requiring attention and decisions that need to be made. People arrive having read the papers. Decisions are recorded, with the reasoning, in a decision log that survives the project and can be interrogated later.

And it stays honest. This is the hardest part, because honesty in governance requires people at every level – project manager, sponsor, board member – to say things that are uncomfortable. To report Amber when it feels safer to report Green. To name a decision that isn’t being made. To challenge a timeline that everyone knows is optimistic. The governance structures that work are the ones where that honesty is expected, protected, and valued rather than managed around.

The purpose of governance is not to produce documents. It is to make sure the right people know what is happening, can make the decisions that only they can make, and are maintaining the alignment between what the project is doing and what the organisation actually needs. That’s a narrow function, but it’s an essential one.

When governance is doing that job, it’s almost invisible – the decisions get made, the problems get surfaced and addressed, the project delivers what it set out to deliver. When it isn’t, you end up with filing cabinets full of compliance documents and a project that failed despite all of them.