Transformation in Flight
D1

Program Governance

The steering committee meets monthly. Status reports say “green.” But the SI has quietly tripled the change request backlog and the program office cannot explain where the schedule slack went.

Most ERP programs have governance. Very few have governance that actually works. The difference is whether the PMO passively collects status updates from workstream leads and assembles them into a slide deck, or whether it actively drives execution: identifying the three decisions that need to be made this week, surfacing the dependencies no one is tracking, and escalating issues before they become crises.

The pattern is familiar. The SI runs the delivery. The client PMO tracks the schedule. Status reports show green until suddenly they show red, and by then the issue is six weeks old and embedded in three workstreams. The steering committee meets every two weeks, reviews a 40-slide pack, and approves decisions that were actually made in the corridor the previous Thursday. The governance exists on paper but does not govern.

We design and operate governance that functions differently. A PMO that actively challenges workstream output rather than summarizing it. A meeting cadence where Monday’s risk register drives Wednesday’s workstream interventions and Thursday’s leadership decisions. Escalation thresholds that are defined and enforced, not aspirational. The goal is a governance system where no issue survives more than 48 hours without action.

The questions you’re probably asking
Why does the steering committee always hear about problems after it is too late to intervene?
How do we know whether the SI’s reported status reflects actual progress or optimistic forecasting?
Is our PMO driving execution, or is it a reporting function that assembles slides?
What should we actually be measuring at program level beyond milestone completion and budget burn?
How do we hold the SI accountable without damaging the working relationship?
Who owns cross-workstream dependencies, and what happens when they slip?
What’s at stake

A program with broken governance does not fail on the day it misses a milestone. It fails slowly, across months, as small decisions compound into structural problems. Change requests accumulate without impact assessment. Dependencies between workstreams are tracked informally or not at all. The Design Authority stops meeting regularly because everyone is too busy fighting fires. By the time the steering committee recognizes the pattern, the program is six months late and the recovery options are expensive.

Governance design is a small investment with disproportionate impact. The difference between a PMO that passively reports and one that actively governs is typically the difference between a program that delivers on its business case and one that delivers a technical system nobody asked for.

If your governance looks right on paper but does not feel right in practice, we should talk.

Let’s Talk →