Program Governance Begins With Decision Rights, Not Committees

Governance is effective when authority is clear enough for the program to make difficult decisions before ambiguity becomes delay.

Organisations often begin governance design by drawing boxes: sponsor, steering committee, program manager, PMO, project managers.

The chart can look convincing while leaving the most important questions unanswered.

Who can approve a major change? Who decides when projects compete for scarce resources? Who can accept a benefit reduction? Who can redirect the program when strategy changes? Who can stop a component? What happens when executives disagree?

Those are decision-rights questions. Until they are answered, the committee structure is mostly administrative architecture.

The Strategic Context

Michael Hanford’s 2005 IBM practitioner paper defines program governance through people, roles, structures, policies and decision-making mechanisms. The source is historical and explicitly no longer maintained, but its core governance logic remains useful: programs require direction, oversight, feedback and the ability to adjust as conditions change.

The paper also emphasises assigning decision authority to executive and management roles and recommends making major decision areas explicit. It describes sponsors, steering committees and program managers as distinct parts of the governance system.

The Week 10 teaching material similarly connects governance to strategic alignment, risk, change, quality, decision reviews and component transitions.

The strategic conclusion is that governance is not the committee. Governance is the system through which legitimate authority is exercised.

What Leaders Commonly Misread

The first mistake is to confuse participation with authority. Ten executives may attend a steering meeting, but if nobody knows who has the final decision, the program can remain stuck.

The second is to assume seniority automatically clarifies authority. A powerful executive may own a business function but not have authority to change the program’s investment case. Conversely, a sponsor may formally own the program but lack practical control over resources held by other functions.

The third is to define authority too narrowly around approvals. Governance also needs explicit rights to request evidence, commission assurance, escalate issues, challenge assumptions, redirect work and terminate components.

The fourth is to assume one governance structure fits every program. Hanford’s paper explicitly argues that structure should fit organisational dynamics and culture. A highly regulated public program and a fast-moving digital program may need different cadence, documentation and delegation while preserving the same governance principles.

Related article: Program Management Must Fit the Context, Not the Framework

Reframing the Issue

Program governance can be designed around five decision layers:

Strategic legitimacy: Is the program still the right investment?
Outcome and benefit integrity: Are intended outcomes and benefits still credible?
Program architecture: Should scope, sequencing, components or dependencies change?
Resource and risk exposure: Should funding, people or risk acceptance change?
Delivery control: Which decisions can component and project managers make without escalation?

The purpose of decision rights is to place each decision at the lowest level that has enough information, authority and enterprise perspective to make it well.

Too much centralisation slows delivery. Too much delegation fragments the program.

Hanford distinguishes the sponsor role from steering-committee participation. The sponsor provides direction and oversight and represents accountability for business outcomes. Steering committees may be structured in different ways depending on how affected business segments share ownership and responsibility.

That distinction matters because committees can diffuse accountability. When everyone is responsible, nobody may feel individually accountable for making the difficult call.

A robust model should identify:

who owns the intended business outcome;
who has final authority when consensus fails;
which stakeholders must be consulted because they carry consequences;
which decisions are delegated to the program manager;
which thresholds trigger escalation.

The program manager then integrates the system rather than operating as a substitute executive.

Decision Rights Need Thresholds

Authority becomes useful when tied to thresholds.

For example, the program manager may have authority to move funding within an approved tolerance but require sponsor approval beyond it. A project manager may manage schedule variation within component tolerance but escalate when the change affects another project, a benefit milestone or a regulatory commitment.

Thresholds can relate to:

financial exposure;
schedule or tranche dates;
benefit erosion;
strategic assumptions;
safety or compliance;
customer impact;
resource conflicts;
interdependency effects.

Without thresholds, escalation depends on personality. Cautious managers escalate everything. Confident managers may retain decisions too long.

Decision Framework

Build a Governance Authority Map around material decisions.

Decision area	Recommend	Decide	Consult	Execute	Escalation trigger
Strategic continuation	Program manager / sponsor	Governing body	Portfolio / business owners	Program	Strategy or value case weakens
Major scope change	Program manager	Sponsor / governing body	Benefit owners, affected functions	Program and components	Benefit, cost or dependency threshold crossed
Resource conflict	Program manager	Designated executive	Functional owners	Resource owners	Critical-path or benefit impact
Risk acceptance	Risk owner / program manager	Authority set by exposure	Specialists and affected owners	Program / operations	Tolerance exceeded
Component change	Project manager	Program manager or sponsor by threshold	Dependent components	Project	Cross-program impact

The exact matrix must fit the organisation. The discipline is more important than the format.

Related article: Portfolio Governance Is a Decision-Rights System

From Strategy to Execution

Immediate action: identify the ten decisions most likely to determine program success over the next tranche. Confirm who can recommend, decide, advise and execute each one. Resolve overlaps before the decision is urgent.

Medium-term capability: formalise thresholds, escalation routes and decision records. Make governance packs decision-oriented: the first page should show what requires judgement, not merely what happened.

Long-term positioning: align program decision rights with portfolio and enterprise governance. Programs should not operate parallel authority systems. Strategic continuation, investment changes and benefit trade-offs need clear connections to the level that owns capital and strategy.

Governance Should Preserve Adaptability

A good governance system protects strategic intent without freezing the original plan.

Hanford’s historical paper emphasises periodic strategy reviews during execution. That is a valuable counterweight to governance models that focus only on conformance.

Programs are dynamic. External conditions change, assumptions fail, stakeholder expectations move and component evidence accumulates. Governance should give leaders a disciplined way to update direction without turning every change into an exception or every challenge into a crisis.

This makes reversibility important. Decisions that are difficult to reverse should receive greater evidence, broader consultation and higher authority. Reversible decisions can usually be delegated more aggressively.

Signals to Monitor

Warning signs include decisions repeatedly deferred because “the right person is not in the room”, overlapping approvals, executives revisiting decisions already delegated, program managers seeking informal permission outside governance, and steering meetings dominated by status with few explicit decisions.

Also watch for the opposite problem: governance bodies making detailed project decisions. That often indicates unclear delegation and can strip accountability from delivery leaders.

The clearest signal is decision latency. If known issues sit unresolved because authority is ambiguous, the governance system is failing regardless of how complete the reporting pack looks.

Questions for the Leadership Team

Which program decisions currently have more than one plausible owner?
Who has final authority when major stakeholders disagree?
What can the program manager decide without sponsor approval?
Which thresholds trigger escalation, and are they understood by component managers?
Can the governance system redirect or stop work when the strategic case weakens?
Are irreversible decisions receiving more scrutiny than reversible ones?

Closing Perspective

The purpose of governance is not to create a hierarchy around the program. It is to create legitimate, timely and accountable decisions.

Design authority first. Then build the committees, cadence and reporting required to exercise it.

Related article: A Program Board That Only Receives Reports Is Not Governing

References

Hanford, M. 2005, ‘Defining program governance and structure’, IBM Developer. Historical practitioner source; the publisher notes that the content is no longer maintained.
University of South Australia, Week 10 Study Notes on Governance and the PMO, supplied course material based on PMI 2017.