Your Steering Committee Watched the Project Crash in Slow Motion

The firewall rule that aged for eleven days

A platform migration I was brought into had a single blocker holding the whole thing hostage: one firewall rule change between two business units. The engineering lead flagged it on a Tuesday. The change needed sign-off from a security architect, a network owner, and the receiving app team. None of them sat in the same reporting line, so the request entered the slow lane: it went onto the weekly Steering Committee deck, where it appeared as a single amber bullet under "dependencies." The committee noted it. Asked the PM to "follow up." Moved on to slide twelve.

Eleven days later that rule was still unapproved. By then the migration window had slipped into a code freeze, the contractor team had been reassigned, and the project status flipped from green to red in a single meeting. The Steering Committee — the body that exists specifically to prevent this — did not prevent it. It documented it, in color, week over week, while it happened.

This is the quiet pathology of enterprise IT governance. We build elaborate machinery to control risk and end up building machinery that manufactures delay. We confuse reporting with executing. The deck is honest; the status is accurate; the project still dies on schedule.

The numbers say this is systemic, not bad luck. Gartner finds that 60% of Project Management Offices are shut down within three years because they cannot demonstrate value — they ossify into overhead instead of acceleration (Gartner: The High Failure Rate of Traditional PMOs). And the people closest to the work are buried in the ritual: project managers spend roughly four hours a week purely on reporting — assembling status nobody acts on (Office Timeline: Project Manager Reporting Overhead Study). That is a tenth of your senior delivery talent spent narrating the past instead of clearing the path forward.

The number nobody on the deck is tracking

Almost every stalled enterprise program I walk into has flawless paperwork. The Risk Register runs fifty rows. The RAID log is current. The Architecture Review Board minutes are archived back to kickoff. What's missing is never documentation. It's speed.

The metric that actually predicts whether a large IT initiative ships is decision latency — the clock that starts when a team raises a blocker and stops when an executive with authority resolves it. In a transformation stuck in committee, that latency compounds in ways a Gantt chart can't show. A 48-hour wait on a firewall approval doesn't cost you 48 hours. It forces a context switch on engineers who've moved to other work, drains the momentum of an in-flight sprint, and — because enterprise calendars are unforgiving — frequently shoves the task past a change freeze into the following quarter.

One hour versus five

The Project Management Institute's research on this is blunt: organizations that resolve decisions in under an hour see a 40% higher project success rate than those that take five hours or more (PMI/Plaky: Decision Latency and Project Success Rates). Read that as an operator, not an analyst: the gap between a program that delivers and one that becomes a budget-variance memo is often measured in how long a yes takes — not in headcount, tooling, or vendor quality.

When I audit a distressed portfolio, the "governance" reliably turns out to be a waiting room. Teams wait for the weekly Steering Committee to bless a change request. They wait for the monthly Architecture Review Board to approve a design that's been ready for three weeks. That waiting is invisible — it doesn't show up as a task in the plan — right up until the moment it's terminal.

Real governance does not ask "Are you on track?" once a week. It asks "What is in your way?" every day and clears it on the spot. If your structure can't resolve a cross-functional deadlock in 24 hours, it isn't governing. It's obstructing — expensively.

What to install in the next 30 days

If you have a critical initiative buried in the mud, more status reporting will not dig it out. You dismantle the theater and stand up a triage system in its place. Three moves, all doable this month.

1. Replace the Steering Committee with a Decision Desk

Kill the weekly hour-long readout. Stand up a daily 15-minute Decision Desk with the smallest set of executives who can actually say yes — typically the CIO or VP of Engineering plus whoever owns budget, security, and the affected app. The rule: any blocker requiring executive authority gets lodged by 9:00 AM. The desk convenes at 10:00. A decision lands by 10:15. Nothing is permitted to age past 24 hours. That firewall rule would have died on day one — or been approved on day one — instead of rotting for eleven.

2. Burn the Risk Register, run a Blocker Board

Nobody reads a fifty-row Risk Register. It's a graveyard where future "I told you so" gets pre-filed. Replace it with a Blocker Board: only live, immediate impediments make the list. Practical governance fixes the three things killing the program today, not the fifty things that might bruise it next year.

3. Measure Block Time, not Percent Complete

"Percent complete" is fiction — it's whatever number keeps the deck green. Track Block Time instead: the cumulative hours a critical-path task sits in a "waiting on a decision" state. It's the operational reading of decision latency, and unlike a percentage it's hard to fake. In 30-day governance recovery work, Block Time is usually the first thing to move — and when it falls toward zero, velocity returns on its own, because the team was never slow. It was waiting.

Governance isn't about control. It's about velocity. Run one diagnostic on every recurring meeting and artifact you own: is this making the team faster? If the honest answer is no, cut it before the next status cycle.