Every time I've been called in after a program has visibly gone off the rails, the postmortem question is always some version of "how did nobody see this coming?" And almost every time, the honest answer is: someone did see it, it was in a status report or a risk log for months, and the governance forum reviewing it decided, repeatedly, that it didn't need to be the thing that got acted on this cycle.
That's not a monitoring failure. Enterprises are extremely good at generating data about their own programs. It's a decision-forcing failure: governance forums built to make people feel informed rather than built to force a call when a threshold gets crossed.
Informational Meetings Disguised as Governance
Most steering committees I've observed spend the bulk of their time on status restatement: what happened this month, what the RAG rating is, what's planned next. Real decisions - cutting scope, reallocating budget, escalating a vendor dispute - get raised, discussed inconclusively, and deferred to "next month, once we have more information." The problem is that the option to act cheaply usually closes well before "next month."
This isn't a facilitation problem you fix by running a tighter agenda. It's a structural one: if the forum has no explicit decision rights and no pre-agreed trigger for when a decision becomes mandatory, deferral is always the path of least resistance for everyone in the room.
The Fix Is a Trigger, Not a Better Dashboard
The governance redesigns that actually change outcomes have one thing in common: they define, in advance, exactly what variance in budget, schedule, or risk automatically forces a decision at the next forum, not "discussion," a decision. If schedule variance crosses a defined threshold, the forum isn't allowed to just note it; it has to choose a response before the meeting ends.
This sounds like a small procedural change, but it removes the social cost of being the person who insists on acting. Nobody has to argue that now is the moment to intervene: the threshold already decided that, and the meeting's job is simply to pick which of the pre-agreed responses to take.
Sizing Governance to Risk, Not to Hierarchy
The other recurring mistake is applying the same governance intensity to every initiative regardless of actual risk. A low-risk internal tooling project doesn't need the same steering cadence as a regulatory-driven program, but in most organizations, it gets exactly that, because the governance model was built once and applied uniformly. That over-governs the low-risk work (wasting executive attention) while under-governing genuinely risky programs that happen to sit lower in the reporting hierarchy.
Fix the trigger design and the risk-sizing together, and the "surprise" late-stage program failure mostly stops happening, not because problems stop occurring, but because the organization is now structurally forced to act on them while they're still cheap to fix.