Governance models in most cross-functional programs define accountability for deliverables. The RACI matrix specifies who is Responsible, Accountable, Consulted, and Informed for each work product. This answers the question: who owns this deliverable? It does not answer the question that causes most execution delays: when a decision crosses functional boundaries, how does it get made? Decision routing is the component of the Governance Model that specifies decision types, decision forums, decision-makers, escalation pathways, and expected turnaround times. Programs that have accountability without decision routing experience a predictable pattern: individual workstreams execute well, but decisions that require cross-functional input stall because there is no mechanism for making them.
Why Accountability Is Not the Same as Decision Authority
Accountability tells the program who is responsible for an outcome. Decision authority tells the program who can make calls that affect multiple workstreams. These are different capabilities, and a RACI matrix captures only the first. Consider a technology platform decision that affects three business unit workstreams. The RACI says the platform lead is Accountable for the platform deliverable. But the decision about data migration sequencing affects all three business units. The platform lead cannot make this decision unilaterally because the business units bear the consequences. The business unit leads cannot make it collectively because the RACI does not define a forum or process for collective cross-workstream decisions. The decision has no home. It waits until someone convenes a meeting, identifies the right participants, frames the decision, and drives it to resolution. This ad hoc process works for the first decision. By the tenth decision, the pattern has cost the program weeks of accumulated delay. The governance problem nobody talks about documents this pattern across multiple programs. The consistent finding: programs with RACI-only governance experience 2-4x more decision-related delays than programs with explicit decision routing.
What Decision Routing Contains
A decision routing framework categorizes decisions by type and assigns each type to a specific mechanism: Workstream-level decisions. Decisions that affect only one workstream are made by the workstream owner. These decisions do not require cross-functional input. The routing is simple: the owner decides. Examples include workstream-internal task sequencing, resource allocation within the workstream, and technical approach choices that do not affect other workstreams. Cross-workstream decisions. Decisions that affect two or more workstreams are made in a defined forum with representation from affected workstreams. The Functional Integration Map identifies these cross-functional touchpoints. The routing specifies: who participates (workstream owners of affected workstreams), who facilitates (typically the program manager), who decides (either consensus with a named tie-breaker, or the most affected workstream owner with consultation from others), and the expected turnaround time. Program-level decisions. Decisions that affect the program’s scope, timeline, budget, or strategic direction are made by program leadership with sponsor input. The routing specifies the escalation criteria (what triggers a decision being classified as program-level), the decision forum (program leadership team), and the sponsor’s role (approval, ratification, or information). Emergency decisions. Decisions that cannot wait for the normal routing because of time sensitivity. The routing specifies who has authority to make emergency calls, what the notification requirements are, and how emergency decisions are ratified after the fact. For each decision type, the routing includes an expected turnaround time. This is the maximum elapsed time from when a decision is identified to when it is resolved. Without turnaround times, decisions sit in queues indefinitely. The architecture nobody builds explains why decision routing is the governance component most often omitted from program architecture. Teams assume decisions will be made through existing organizational mechanisms. Those mechanisms were designed for functional decisions, not cross-functional ones.
The Cost of Missing Decision Routing
Decision latency compounds. Each stalled decision delays dependent work. Dependent work delays downstream milestones. Downstream milestones delay other workstreams that were waiting for those milestones. The cascade effect means that a single decision stall can affect multiple workstreams and multiple weeks of schedule. Three patterns characterize programs without decision routing: The escalation default. Every cross-functional decision escalates to the executive sponsor or steering committee. This works when decisions are rare. In a complex cross-functional program, cross-functional decisions arise weekly or more frequently. The sponsor becomes a bottleneck. Decisions queue for the next steering committee meeting. The program’s execution pace is governed by the sponsor’s calendar rather than by the work itself. The hallway decision. In the absence of a formal forum, decisions get made in informal conversations between whoever happens to be available. These decisions lack representation from all affected parties. They lack documentation. They are frequently revisited when someone who was not in the hallway disagrees with the outcome. The revisitation consumes more time than the original decision would have taken through a formal process. The decision avoidance. When there is no clear mechanism for making a cross-functional decision, teams avoid making it. They work around it, make assumptions, or defer it. The deferred decision resurfaces during execution when the assumptions prove wrong and the workaround fails. By then, the cost of the decision is higher because work has proceeded based on incorrect assumptions. Programs that failed with good plans traces multiple schedule overruns to the escalation default and the hallway decision patterns. Both are symptoms of missing decision routing.
What “Complete” Decision Routing Looks Like
A complete decision routing framework passes four tests:
- Every decision type has a forum. No category of decision requires ad hoc convening. Workstream decisions have owners. Cross-workstream decisions have a defined forum. Program decisions have a leadership mechanism. Emergency decisions have an authority designation.
- Every forum has a tie-breaker. Consensus-based forums specify what happens when consensus is not reached. The tie-breaker is named in advance, not identified during the impasse.
- Turnaround times are specified. Each decision type has a maximum response time. The program manager tracks decisions against their turnaround targets and escalates when targets are missed.
- The sponsor is the exception, not the default. The routing distributes decision authority so that the executive sponsor is only involved in program-level decisions. If the sponsor is involved in every cross-workstream decision, the routing has failed to delegate appropriately.
The meeting before the meeting describes how decision routing, when combined with pre-meeting alignment, prevents the decision stalls that consume governance forums. The question is whether your governance model will route cross-functional decisions to legitimate forums with named decision-makers: or whether your team will default to escalation, hallway conversations, and avoidance until the delays force a structural fix.
Keep Reading
New to the Architecture Blueprint? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: