The program has a governance document. It defines the program’s governance bodies (steering committee, program leadership team, workstream leads), their responsibilities, and the escalation pathway. It was reviewed during planning and endorsed by the executive sponsor. The document describes who has authority. It does not describe how that authority is exercised. The gap between a governance document and governance design is the gap between knowing who can make a decision and having a process that ensures decisions actually get made.
What Governance Documents Miss
Governance documents answer: who has authority? Governance design answers: how does that authority operate in practice? Several specific gaps exist. Decision types are not differentiated. The document says the steering committee approves strategic decisions. But what counts as strategic? A scope change that affects one workstream? A resource reallocation between two workstreams? A timeline adjustment on the critical path? Without differentiation, two things happen: decisions that should be fast (the program director can decide) get routed to the steering committee (slow), and decisions that need strategic input (the steering committee should decide) get made by the program director (insufficiently informed). Turnaround times are not defined. The document says the program director makes cross-functional decisions. It does not say how long those decisions should take. When a cross-functional trade-off is identified on Monday, does the program director decide by Wednesday? By Friday? By the next biweekly meeting? Without turnaround expectations, decisions take as long as they take, and teams wait. Information requirements are not specified. The document says the steering committee reviews escalations. It does not say what information an escalation must include. The escalation arrives as a two-sentence email. The steering committee asks for analysis. The analysis takes a week. The steering committee reviews the analysis and asks for additional context. The additional context takes another week. Three weeks have passed because the information requirements were not defined upfront. Programs that failed with good plans documents decision stalls caused by governance that looked complete on paper but could not process decisions in practice.
What Governance Design Actually Does
Governance design operationalizes decision rights by specifying several elements for each decision type. Decision classification. The design identifies five to seven common decision types and classifies each: execution decisions (workstream-level, decided by the workstream lead within their authority), integration decisions (cross-workstream, decided by the program director with input from affected workstream leads), strategic trade-offs (scope, budget, or timeline changes, decided by the steering committee with program director recommendation), and organizational escalations (decisions requiring executive committee involvement). Authority and turnaround. For each type: who makes the decision, within what timeframe. Execution decisions: workstream lead, one to two business days. Integration decisions: program director, three to five business days. Strategic trade-offs: steering committee, one to two weeks. Organizational escalations: executive committee, two to four weeks. The turnaround times create accountability for decision speed. Information requirements. For each type: what information the decision-maker needs. An integration decision requires: the issue description, the options with trade-offs, the affected workstreams’ input, the program director’s recommendation, and the timeline impact of delay. A steering committee escalation requires: the same, plus financial impact analysis and risk assessment. Defining information requirements upfront prevents the back-and-forth that extends decision cycles. Escalation triggers. The conditions that move a decision from one level to the next. If an integration decision is not made within five business days, it automatically escalates to the steering committee. If two workstream leads cannot agree on a dependency resolution, the program director convenes a decision session within three business days. The triggers prevent decisions from stalling at any level. The Decision Escalation Framework sub-artifact is where these triggers, authority levels, and turnaround times are documented. The architecture nobody builds provides the governance hierarchy that governance design operationalizes. Without architecture that defines the decision-making structure, governance design has no framework to build on.
The Decision Stall Pattern
Decision stalls are the most common governance failure in cross-functional programs. The pattern is consistent. An issue is identified. The issue requires a cross-functional decision. The workstream leads discuss it but cannot agree. The issue is raised to the program director. The program director needs information that has not been assembled. The information gathering takes time. The program director makes a recommendation to the steering committee. The steering committee meets on its regular schedule (not when the decision needs to be made). The steering committee discusses but wants additional analysis. The cycle repeats. Each step in the cycle is reasonable. The information request is legitimate. The committee’s desire for analysis is prudent. But the cumulative cycle time is weeks, and during those weeks, dependent workstreams cannot proceed. Governance design breaks the cycle at multiple points. Decision classification routes the issue to the right level immediately (instead of working up through each level sequentially). Turnaround times create urgency at each level. Information requirements ensure the decision-maker receives what they need on the first pass. Escalation triggers prevent decisions from sitting unresolved. The risk nobody put on the register connects to decision stalls: a stalled decision is a risk. Every day a decision is unmade is a day the affected workstreams operate on assumptions rather than direction.
Governance for the Common Decisions
The design does not need to cover every possible decision. It needs to cover the common ones. Five to seven decision types typically account for ninety percent of the decisions a cross-functional program faces. Resource reallocation. When two workstreams need the same resource during the same period, who decides the priority? Classification: integration decision if within the program director’s authority, strategic trade-off if it affects the critical path. Scope adjustment. When a deliverable needs to change based on new information, who approves the change? Classification: execution decision if within one workstream, integration decision if it affects dependencies, strategic trade-off if it changes the program’s scope boundaries. Timeline adjustment. When a milestone needs to move, who approves the change and assesses the cascade? Classification: integration decision if it does not affect the critical path, strategic trade-off if it does. The Operating Rhythm defines the cadence forums where these timeline decisions are surfaced and resolved. Dependency resolution. When a dependency specification needs to change, who mediates between the producing and consuming workstreams? Classification: integration decision with the program director as mediator. Risk response. When a risk materializes, who decides the response? Classification: execution decision if within one workstream, integration decision if it affects multiple workstreams, strategic trade-off if the response requires budget or timeline changes. Designing governance for these five types, with authority, turnaround times, information requirements, and escalation triggers for each, covers the vast majority of decisions the program will face. The question is whether the team designs governance for the decisions the program actually faces: or whether it discovers the process gaps when the first common decision stalls and the cascade has already begun.
Keep Reading
New to the Operating Model? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: