Governance That Actually Decides
TL;DR
Governance only adds value when it improves decisions. A tiered structure — steering committee for strategic calls, a delivery governance forum for cross-functional coordination, and working groups used sparingly for technical detail — gives every issue a level where it can actually be resolved. Governance built around outputs (reports, decks, status updates) instead of decisions becomes theatre. Governance built around decisions becomes one of the most valuable enablers of a transformation.
Why governance gets blamed
Governance gets a bad reputation, and in many cases it has earned it. For a lot of teams, the word brings to mind repetitive status reporting, long meetings, thick decks, and senior stakeholders asking questions after the real decisions have already been made. That version of governance does real damage — it slows delivery, creates duplicate conversations, pushes every issue upward, and leaves teams spending more time explaining their work than doing it.
That is not what governance is supposed to do. When it is designed well, governance creates decision clarity. It makes it obvious where an issue belongs, who has the authority to resolve it, what information is needed, and when something genuinely needs to be escalated. In a complex transformation, that kind of clarity is not overhead — it is one of the things that keeps delivery moving.
I have learned to think about governance less as meeting architecture and more as decision architecture. The right question when designing a governance framework is: which decisions need to be made, at what level, by which people, and based on what information?
A simple, tiered structure works best
Across the programs I have run, I typically build governance around two or three tiers. The exact design depends on the size, risk, and complexity of the work, but the principle stays the same: senior stakeholders make senior decisions, middle managers and delivery governance orchestrate delivery, and working groups solve detailed cross-functional problems without pulling everything into broader governance.
Many programs run into trouble because they do not separate those purposes. The steering committee ends up debating task-level detail. Delivery managers wait for executives to resolve issues they could have handled themselves. Working teams raise the same blocker repeatedly because nobody is clear whether it is a delivery issue, a sponsor decision, or a cross-functional trade-off. A tiered model cuts through that confusion and keeps each group focused on the work that belongs to them.
Tier 1: The Steering Committee
The steering committee sits at the top, built around the program sponsor and senior stakeholders who have authority over strategic direction, blockers, risks, cost, scope, and major trade-offs. This forum should not exist to review everything — its job is to decide the things that cannot be decided anywhere else.
The best steering committees I have been part of give direction, resolve conflict, accept or reject risk, make funding and prioritization calls, and assign ownership when an issue cuts across functions. A steering committee decision only has value if it changes what happens next. If the outcome of a discussion is simply that it was noted, the forum has not done its job.
A governance forum without decision authority is just another meeting.
Tier 2: The Delivery Governance forum
This is often where programs are won or lost. I build this tier around middle managers, delivery governance, and operational owners — people close enough to the work to know what is real, and senior enough to align resources and drive department-level planning.
On one program, the sponsor had a clear vision, but it still needed translating into work that multiple departments could actually execute. This tier was where we broke the vision down, challenged unrealistic timelines, surfaced faulty assumptions, and worked out how to navigate the organization to deliver on time and on budget. When this forum works well, dependencies get managed, blockers get resolved, risks get turned into recommendations, and escalations arrive at the steering committee properly prepared.
Tier 3: Working Groups — used sparingly
The third tier is tactical, used only when work needs day-to-day technical scrutiny. These groups need a specific purpose and a defined end date — they should never become another standing meeting. I have used technical working groups to manage clusters of IT changes that needed close monitoring but did not need to dominate the second-tier agenda.
Good governance does not move every issue upward. It moves each issue to the level where it can be resolved.
Charters turn forums into decision points
This structure only works if each forum has a clear charter — not a lengthy document written once and forgotten, but a practical one-page operating framework defining purpose, membership, chair, cadence, inputs, outputs, decision authority, escalation route, and how actions get tracked. Defining what the forum is not responsible for is often where the real value sits.
Governance only adds value when it improves decisions
Leaders ask for stronger governance when priorities are unclear, risks surface too late, or too many decisions happen informally. Delivery teams often experience governance as an expanding set of forums, templates, and approval gates that consume time without clearly improving execution. Both perspectives are understandable — because the problem is rarely governance itself. It is governance detached from decisions.
Research published in the International Journal of Managing Projects in Business (2025) argues that the link between governance and project performance runs through decision-making: governance works when it creates the conditions for competent people to decide better, not simply when it adds more formal structure. PwC’s analysis of transformation governance makes a related point — weak governance introduces cost overruns, missed deadlines, and lost value, while early investment in governance rigor acts as a multiplier rather than a cost.
Strong governance tends to share five characteristics: it is decision-oriented (every forum exists to produce an action), proportionate (scaled to complexity, not anxiety), transparent (everyone understands escalation and accountability), connected to real delivery dynamics rather than abstract assumptions, and evolving as the program matures.
The Association for Project Management’s 2025 guidance draws a useful distinction here: governance is fundamentally about making decisions, while assurance provides the evidence base for those decisions. Confusing the two — mistaking a large volume of reporting for visibility — is one of the most common governance failures. Teams can produce updates that are comprehensive but not decision-useful; leaders receive more information while gaining less insight.
The failure pattern I try to avoid
The governance failures I see most often come down to two patterns. The first is issues not resolved at a low enough level — something the delivery governance forum could have handled gets escalated layer after layer, and by the time it reaches the steering committee, the cost to fix it has gone up. The second is too much detail pushed up to the steering committee, crowding out the strategic conversation senior stakeholders actually need to have.
How AI changes governance — and what it doesn’t change
AI will not eliminate the need for governance, but it will change how we run it. The opportunity is not replacing decision-makers — it is improving the speed and quality of the information flowing between forums: stakeholder coordination, meeting minutes, action tracking, risk monitoring, and decision papers. A PMO that is not spending its time chasing status updates can focus on unblocking work and helping teams deal with new issues as they come up.
But there are real limits. AI can accelerate the evidence. It cannot own the consequence. It can flag that a risk is increasing, but it cannot decide whether the business should accept that risk.
AI can accelerate the evidence. It cannot own the consequence.
The practical test
The real test of governance is not whether the meetings took place. It is whether the program achieved what it set out to do, and successfully managed scope, time, cost, and quality. If the steering committee gives clear direction, the delivery governance forum turns that into coordinated action, and working groups solve the detailed problems that would otherwise stall the program, governance is doing its job.
Good governance is not about control for its own sake. It is about giving teams enough structure to move with confidence — the right people knowing what they own, the right issues reaching the right forum, and the right decisions getting made at the right level.
From the field: I built exactly this kind of tiered, decision-oriented governance to run a 40-project portfolio remediating CBUAE audit findings against a 6-8 month regulatory deadline — landing 10 of the 12 highest-priority projects on time. Read more in Services: Delivery Governance & Audit Remediation.
Sources referenced: Association for Project Management, “From Evidence to Action: The Role of Assurance in Project Success” (2025); PwC, “Program Governance and Delivery Risk in Transformation” (2025); International Journal of Managing Projects in Business, “How Good Governance Leads to Better Project Performance” (2025).
Get new articles by email
One email when I publish something new. No newsletter, no noise.