If the steering committee has never chosen between two options, it is not steering.
There is a familiar rhythm to program governance. A pack is circulated. A status is presented — green, amber, occasionally red. Risks are noted. Actions are assigned. The meeting closes on time.
Nothing was decided. The program continued in the direction it was already travelling, and the committee's function was to observe that it did so. Six months later, when the program is in difficulty, the same committee will ask why it was not told earlier. It was told. It was told in a format designed to inform rather than to force a choice, by people who had correctly inferred that choices were not what the forum was for.
This is the central pathology of program governance, and it is not a failure of effort or intelligence. It is a design fault: governance built for projects, where the end state is specified and the question is whether delivery is on track, applied to programs, where the end state is still forming and the question is which way to go next.
The Strategic Context
A project can be specified. Its scope, schedule and cost form a baseline, and governance can sensibly ask whether reality is tracking the baseline.
A program cannot be specified in the same way, and attempting it produces a document that is obsolete before approval. A program's purpose is to achieve an outcome — a changed operating model, a new capability, a different cost base — through a sequence of projects and organisational changes whose later stages depend on what the earlier stages reveal. The end state is directional, not dimensional. It is known in intent and unknown in detail.
Governing this requires something other than variance reporting. It requires deciding, repeatedly, between credible alternatives under uncertainty — which is a different activity, needing different information, different people and a different meeting.
What Leaders Commonly Misread
That a program is a large project. Size is not the distinction; specifiability is. A five-hundred-million-dollar plant replacement with a fixed design is a project. A twenty-million-dollar effort to change how an organisation prices, sells and services its products is a program, because the target operating model will be different at the end from what anyone drew at the start.
That green status means the program is succeeding. Project status reports on delivery against plan. A program can be perfectly on plan and failing, because the plan was built on assumptions that the first tranche has since disproved. The question governance should ask is not "are we on plan" but "is the plan still the right one given what we now know" — and those questions have almost opposite reporting requirements.
That governance is oversight. Oversight is a supervisory posture: watch, assure, escalate. Program governance is a decision-making function: choose the next tranche, reallocate between workstreams, halt a stream that is no longer justified, accept a transition state that is uncomfortable but necessary. A body with no authority to do these things is an audience.
That the transition states are temporary inconveniences. In a program of any length the organisation spends most of its time in intermediate states — partly migrated, running two processes, supporting an old system and a new one. These states have costs, risks and operational consequences that frequently exceed those of either the start or end state, and they are routinely left unplanned because they are not the destination. [Related article: Interfaces, Not Tasks, Break Industrial Programs]
Reframing the Issue
Think of a program not as a plan to be executed but as a sequence of bets, each of which buys information as well as capability.
Under this framing, the tranche is the central governance object. A tranche is not a time period or a convenient grouping of projects. It is a coherent step that delivers a usable increment of capability and resolves a specific uncertainty, ending at a point where the organisation could genuinely choose to continue, redirect or stop.
Three design rules follow.
Every tranche must end at a decision point that is real. If the answer at the end of Tranche 1 can only be "continue", because so much has been committed that stopping is unthinkable, then Tranche 1 was not a tranche — it was the first part of an irreversible commitment dressed as a staged approach. The test is blunt: what would it cost to stop here, and is that cost one the organisation could actually bear?
Every tranche must resolve a named uncertainty. Not "prove the concept" but something specific and falsifiable: whether the operational areas will adopt the new process without headcount relief; whether the data quality in the legacy system supports automated matching; whether customers will accept the revised service model at the current price. If a tranche resolves nothing, the program has bought capability without buying information, and the next decision is no better informed than the last.
Every tranche must leave the organisation in a state it can live in. Because the next tranche may be delayed, reduced or cancelled, and the transition state may become the resting state for longer than anyone intends.
The Information Governance Actually Needs
The standard program pack reports on the wrong things at the wrong granularity. Three items serve a deciding body better than a full status deck.
The assumption ledger. A short, maintained list of what the program depends on being true, with each assumption marked as holding, weakening or broken, and evidence attached. Governance reviews changes, not the whole list. This converts the meeting from "how are we tracking" to "what have we learned", which is the only question that can change a decision. [Related article: What Must Be True for This Investment to Succeed]
The benefit trace. For each expected benefit, the specific operational change that must occur for it to materialise, and the named business owner accountable for that change — not the program manager. Most benefit shortfalls are visible in this trace long before they are visible in the financials, because the operational change quietly did not happen. [Related article: Who Owns the Benefit After the Project Closes?]
The decision register. What this body has decided, when, on what evidence, and what it foreclosed. Programs that keep one develop institutional memory and stop relitigating settled questions; programs that do not, rediscover the same debate every time the sponsor changes.
Note what is absent: the RAG status, the milestone chart, the risk heat map. These are useful for management and largely inert for governance, because they rarely present a choice.
Decision Framework
At each tranche gate, the governing body answers five questions in order. It does not proceed to the next until the current one is answered.
1. What did we learn? Which assumptions changed status since the last gate, and what is the evidence? An honest answer here often contains the whole decision.
2. Is the outcome still worth the remaining cost? Not the total cost — the remaining cost. Money already spent is not a reason to continue and should be explicitly excluded from the discussion.
3. What are the credible alternatives now? At minimum: continue as planned, continue with a changed approach, pause, or stop. Each needs a cost, a benefit consequence and a reversibility note. A gate with one option is a notification.
4. Can the organisation absorb the next tranche? Capacity, change fatigue and competing portfolio demands. The program's readiness is necessary; the organisation's is binding. [Related article: Why Portfolio Balance Fails Before Delivery Does]
5. Who owns the benefits of what we are about to release, and have they accepted? If the receiving business owner has not accepted the operating change, the tranche will deliver output and no outcome.
From Strategy to Execution
Immediately. Change the standing agenda of the program board so that the first item is decisions required and status is last, time-boxed. Agendas shape behaviour faster than terms of reference. Require every paper to present at least two options with a recommendation, and return papers that present one.
Over one to two quarters. Restructure the remaining program into genuine tranches with real stop points and named uncertainties. Establish the assumption ledger and benefit trace, and make the business owners — not the program — accountable for the benefit trace entries. Expect resistance here; it is the moment when benefit ownership becomes real, and it is where most of the value of this reform sits.
Over one to three years. Build the organisational muscle for governing under uncertainty: sponsors who can distinguish between a program in trouble and a program learning; boards comfortable stopping something that is executing well but no longer justified; a culture in which raising a broken assumption early is rewarded rather than treated as a delivery failure. This is a capability, and it transfers to every subsequent program. [Related article: The Decision-Rights Problem]
Signals to Monitor
- Gates that have never resulted in a change of direction. Either the program is unusually well-conceived or the gates are ceremonial.
- Papers arriving with a single recommended option. The decision was made elsewhere; the forum is ratifying.
- Assumptions that never change status. The ledger is not being maintained honestly, or nobody is testing.
- Benefit owners who are program staff. Benefits will be reported, not realised.
- Transition states extending beyond plan without formal acceptance. The interim is becoming permanent by default.
- Escalations arriving already resolved. Issues are being managed below the board until they can no longer be, which removes the board's ability to choose.
- Rising sponsor turnover. Institutional memory is leaving, and the decision register is about to matter.
Questions for the Leadership Team
- When did this board last choose between two genuine alternatives, and what did it decline?
- Which of the program's founding assumptions have weakened since approval, and how do we know?
- If we stopped at the end of the current tranche, what would we have, what would it have cost, and could we live with it?
- Who in the business — by name — is accountable for the operational change behind each expected benefit, and have they said yes?
- Are our transition states planned and costed, or are they treated as gaps between the interesting parts?
- What would we need to see to stop this program, and is anyone empowered to act on it?
Closing Perspective
The purpose of program governance is not assurance. Assurance is valuable and can largely be delegated. The purpose is to make, repeatedly and on the best available evidence, the small number of consequential choices that no one else in the organisation has the authority or the vantage point to make.
A board that receives excellent information and never chooses has outsourced those choices to momentum. Momentum is a poor strategist: it favours what is already underway, protects what is visible, and has no view on what the organisation should become. Replacing it requires very little ceremony and one uncomfortable habit — asking, at every gate, what we would do if we were deciding this today for the first time.
Next in this series: [Related article: Who Owns the Benefit After the Project Closes?] — why value leaks in the months after delivery, and what governance can do about it before it does.