I've sat in governance meetings where every agenda item ended the same way: "We'll need to take that offline." A steering committee with senior leaders from four business units, meeting every two weeks, producing no decisions in session. The program was three months behind and accelerating in the wrong direction. The problem wasn't the plan. It wasn't the team. It was that no one in that room knew what they were actually authorized to decide, and no one had ever defined it.
"Most delivery problems aren't planning problems. They're authority problems. The schedule slips, the escalation stalls, the stakeholder disengages, and the diagnosis points to execution. But the root cause is almost always the same: no one designed who decides what, at which level, under which conditions."
The Real Problem
When a project gets into serious trouble, the post-mortem almost always focuses on what went wrong in execution: the missed milestone, the underestimated dependency, the vendor who didn't deliver. These are real. But they are rarely the root cause. They are where the failure became visible. The actual breakdown usually happened earlier, in the governance layer, where authority was ambiguous, decisions weren't made, and problems that could have been resolved at the working level instead drifted upward until they became crises.
The reason this pattern persists is that authority confusion is invisible until it isn't. A team can operate for months with no clear decision rights structure, relying on informal norms, assumed authority, and the goodwill of senior stakeholders to fill in the gaps. This works until it doesn't: until a decision is genuinely contested, until a sponsor is unavailable, until two functions disagree and there is no defined mechanism for resolution.
At that point, the absence of a designed authority structure doesn't just slow the project. It creates a vacuum, and vacuums in organizational systems get filled by whoever is most confident, most senior, or most present in the room, regardless of whether they hold the right authority. The decision gets made, but by the wrong person, using the wrong information, at the wrong level. And the project moves forward carrying the weight of that misaligned call.
PMs tend to misdiagnose this because governance feels like a background condition rather than a design choice. The RACI is filled in, the steering committee is scheduled, the escalation path is nominally documented. The infrastructure of governance exists. What is missing is the substance: a clear, shared, enacted understanding of who is authorized to decide what, and what happens when that authority is in doubt.
What Decision Rights Actually Are
Decision rights are not the same as roles. A role describes what someone is responsible for managing. A decision right describes what they are authorized to resolve. These are related, but they are not identical, and the gap between them is where most governance failures live.
A project manager may be responsible for the delivery plan. That doesn't tell you whether they can approve a scope change, accept a vendor substitution, reallocate budget between workstreams, or authorize a schedule extension. Each of those is a distinct decision, and each carries a different level of organizational risk, stakeholder impact, and financial implication. Without an explicit authority structure, the PM makes a judgment call each time, which means the answer depends on the individual rather than on the design of the governance system.
Responsibility tells you who manages the work. Authority tells you who can resolve it. Governance works when those two things are deliberately aligned. It fails when they are assumed to be the same.
Well-designed decision rights have four characteristics. They are explicit: written down and shared, not carried in someone's head. They are tiered: different categories of decision sit at different levels of the organization, matched to the scope of their impact. They are bounded: each decision type has a defined threshold at which it moves up or down the authority structure. And they are enacted: the people who hold authority actually use it, in the forums designed for that purpose, rather than deferring, delegating, or avoiding.
Most organizations have the first two in some form. Very few have the third and fourth. The threshold and enactment conditions are where governance designs break down in practice, and where the real work of authority design needs to happen.
Six Ways It Breaks Down
Authority confusion doesn't present in a single way. Across delivery environments, six failure patterns appear consistently enough to be named, recognized, and designed against.
Authority Opacity
Roles are defined. Decision rights are not. People know their title but not what they can actually resolve. When a decision arises, the default is to check with someone more senior, regardless of whether that person holds relevant authority. Decisions that should take hours take weeks.
Threshold Blindness
Escalation is driven by urgency or individual discomfort, not defined conditions. There are no written criteria for when a decision must move upward. What gets escalated and what gets resolved locally is inconsistent across similar situations, depending entirely on who is present and how anxious they feel.
Governance Theatre
The steering committee meets. The agenda is full. Nothing is decided in session. Authority flows around the governance forum rather than through it. Decisions happen in corridors, in side conversations, in emails after the meeting. The forum exists to ratify what has already been resolved informally.
Tier Collapse
Executives are pulled into decisions that working teams should own. The escalation path is effectively one level: when in doubt, go to the top. Senior leaders spend significant time on operational questions that don't require their authority. Working teams become dependent and stop developing their own decision confidence.
Informal Authority
Real decision power is understood but not formally assigned. Everyone knows that one function head's approval is required regardless of the formal structure. The org chart says one thing; the actual decision map says another. New team members can't navigate it, and the system is impossible to audit or improve.
Structural Drift
An authority structure existed at the start but has eroded. What was once explicit is now assumed, informally renegotiated, or simply ignored. The team references past agreements rather than a current, active structure. No one has reviewed whether the governance design still fits the program it was built for.
These patterns rarely appear in isolation. A program experiencing Governance Theatre is usually also experiencing Tier Collapse, because when the formal forum doesn't decide, decisions migrate to whoever has informal authority, and that person is almost always more senior than the decision warrants. Threshold Blindness accelerates both: without defined escalation conditions, urgency becomes the only trigger, which floods senior tiers with decisions that should never have reached them. The patterns reinforce each other, and fixing one without addressing the others produces only partial improvement.
What Good Design Looks Like
A functional decision rights structure has three components that work together: an authority map, defined escalation thresholds, and enacted governance forums. Each is necessary. None is sufficient alone.
The authority map assigns every significant category of decision to the correct organizational tier, with a named owner and clarity about who informs, who recommends, and who resolves. It is not a RACI. A RACI describes participation. An authority map describes resolution rights. The question it answers is not "who is involved?" but "who can say yes, and who can say no?"
Escalation thresholds replace escalation by judgment with escalation by rule. Instead of "this feels serious enough to go up," the structure defines specific, verifiable conditions: financial impact above a threshold, schedule impact beyond a set number of days, risks rated above a defined severity, or decisions where two functions are in disagreement and neither holds sufficient authority to resolve alone. When those conditions are met, the decision moves. When they aren't, it stays at the working level. The judgment call about whether to escalate is replaced by a structural rule.
- Decisions escalate when they feel serious enough
- Who decides depends on who's in the room
- Governance forums meet but rarely resolve
- Senior leaders absorb working-level decisions
- Authority is informal, unauditable, and fragile
- Defined triggers move decisions to the correct tier
- Authority is assigned by decision category, not presence
- Governance forums hold real authority and use it in session
- Senior leaders decide what only they can decide
- Authority structure is documented, shared, and maintainable
Enacted governance forums are the hardest component because they require behavioral change in addition to structural change. A steering committee that has operated in Governance Theatre mode for a year does not automatically start deciding things because the authority structure has been redesigned. The redesign creates the conditions for enactment. The enactment itself requires explicit expectation-setting with every member of the forum: what decisions will come to this group, in what format, with what recommendation, and with the expectation that a decision will be made in session rather than deferred.
How to Map It on Your Next Project
The right time to design decision rights is during program initiation, when the governance structure is being established and before any of the patterns above have had time to take hold. In practice, this rarely happens. Most programs inherit whatever governance structure was used last time, with adjustments at the margin. Decision rights are treated as a given rather than as a design choice.
If you are inheriting a program with authority confusion already active, the starting point is diagnosis before redesign. You need to understand which failure patterns are present, how severe they are, and where the most significant decision gaps exist, before you can design a remedy. Redesigning the authority structure without that diagnosis produces a new structure that is better in theory and equally unworkable in practice, because the informal dynamics that created the original confusion have not been named or addressed.
Not tasks. Decisions. Scope changes, budget reallocations, vendor substitutions, timeline extensions, risk acceptance, strategic pivots. Each one is a distinct authority question. Until they are listed explicitly, they cannot be assigned.
On a technology implementation, that list might include: scope changes above a defined size, budget movement between workstreams, timeline extensions over ten business days, vendor substitutions, and acceptance of high-severity risks. Each item is distinct. Each carries a different authority threshold.
Decisions should sit at the lowest organizational level with sufficient authority and context to resolve them well. Working-level decisions stay with the team. Cross-functional or financially significant decisions move to management. Decisions with strategic or organizational implications belong at the executive or governance level. When in doubt, ask: what is the consequence if this decision is wrong? The answer tells you the tier.
For each decision category, write down the specific conditions that would move it to the next tier. Financial thresholds, schedule impacts, stakeholder conflicts, risk severity ratings. These conditions should be verifiable, not felt. A team member should be able to look at a situation and determine, without ambiguity, whether the escalation condition has been met.
A decision rights map that hasn't been agreed by the people named in it is a document, not a governance system. Bring it to the steering committee at kickoff. Walk through each category. Confirm that named decision holders accept the authority being assigned to them and understand what it means for them to use it. The conversation that happens in that session is as important as the document itself.
Decision rights design is not a one-time activity. Authority structures erode as programs evolve, as stakeholders change, as the nature of the decisions shifts. The charter needs to be revisited at significant program milestones, and whenever there is evidence that one of the six failure patterns is reasserting itself.
The programs that sustain functional governance are not the ones with the most documentation. They are the ones where authority design is actively maintained.
Governance that works is governance that is tended. The org chart tells you who reports to whom. The decision rights structure tells you who can actually move things forward. Only one of those is under your control to design.
Seven working documents for delivery leaders dealing with active authority confusion. Includes a scored diagnostic across six failure patterns, an authority mapping tool, escalation threshold templates, and a Decision Rights Charter ready to put in front of your steering committee. Built for programs where governance exists on paper but isn't working in practice.
See the Diagnostic Pack →
The PM Reality Check
Weekly strategies for the human side of delivery. Plus get the free Stakeholder Field Guide on signup.