"Authority opacity is not a leadership failure. It is a design failure — one that gets paid for in weeks of delay, rounds of parallel approval, and the quiet accumulation of decisions made by whoever was available rather than whoever was accountable."
Authority Opacity
There is a particular kind of project stall that project managers recognize immediately but rarely name accurately. The work isn't blocked by a technical problem. The team isn't underperforming. The timeline was reasonable. And yet something has slowed to a stop — decisions are being revisited, approvals are circling between functions, and the weekly status report reads "pending alignment" for the third consecutive week.
What has stalled is authority. Specifically, no one is certain who holds it.
This is authority opacity — the condition that exists when decision rights are either undefined, inconsistently documented, or documented in a way that doesn't reflect how the organization actually operates. It is remarkably common. Project charters list sponsors and steering committees. RACI matrices assign roles. Governance frameworks describe escalation paths. And still, when a real decision arrives — one with cost implications, cross-functional impact, or political weight — the organization hesitates, because none of those documents actually told anyone who can say yes.
The RACI tells you who is responsible. It rarely tells you who is authorized. These are not the same thing — and confusing them is one of the most common structural errors in delivery governance.
Responsibility describes who does the work or leads the process. Authority describes who can commit the organization — who can approve a budget variance, change a scope boundary, override a vendor recommendation, or release a delivery milestone. Organizations that conflate these two in their governance documents create the conditions for authority opacity before the project begins.
The Cost of the Vacuum
Authority vacuums don't sit empty. They fill — with workarounds, with informal power, and with the particular tax that ambiguity places on every decision that passes through it.
Four patterns appear consistently in programs operating without clear decision rights:
-
01
Parallel approval loops When no single person is authorized to decide, decisions get sent to multiple stakeholders simultaneously — each of whom believes they have a say, none of whom believes they have sole authority. The decision circulates until consensus emerges or someone with enough positional weight ends the loop. This can take days. On complex programs, it routinely takes weeks.
-
02
Upward abdication Teams and middle managers, uncertain of their authority boundaries, push decisions upward rather than risk overstepping. Senior leaders accumulate a backlog of decisions that should have been resolved two levels below them. The executives are busy making operational decisions; the operators are waiting for direction that should have been theirs to give.
-
03
Informal authority capture In the absence of formal decision rights, authority migrates to whoever is most assertive, most senior in the room, or most politically connected. This is not always wrong — informal authority sometimes lands in capable hands. But it is inherently unstable, non-transferable, and impossible to audit or improve systematically.
-
04
Retrospective overrides Decisions get made under the assumption of authority, only to be reversed when a more senior stakeholder becomes aware and disagrees. The original decision-maker believed they were authorized. The override creates confusion about what authority they actually hold. Both parties leave the interaction with less clarity than they entered it.
Each of these patterns is costly in time, in team morale, and in delivery confidence. Each one is also entirely avoidable — not by changing the people involved, but by designing the authority structure before these moments arrive.
Why Charters Don't Fix This
The standard response to decision authority problems is governance documentation — project charters, RACI matrices, terms of reference for steering committees. These documents are necessary. They are rarely sufficient.
The gap is specificity. Most governance documents describe authority in organizational terms — "the Project Sponsor is accountable for strategic direction" — without translating that into operational terms that mean something when a real decision arrives. What dollar threshold requires sponsor approval? Does the sponsor decide on scope changes or recommend them to the steering committee? Can the project manager approve a one-week schedule extension without escalation, or does any timeline shift require sign-off?
A governance document that cannot answer "who approves a $15,000 budget variance on this project" has not actually documented authority. It has documented titles.
This distinction is not pedantic. It is the difference between governance that functions as a delivery tool and governance that functions as a compliance artifact — something that exists to satisfy a requirement but adds no structural clarity to the people doing the work.
Real decision rights architecture requires translating organizational authority into operational thresholds. It names specific decision categories. It assigns specific authority levels to specific roles for each category. It defines the conditions under which authority escalates and to whom. It gets reviewed with the people who will use it — not filed and forgotten.
Decision Rights Architecture
Building a decision rights architecture means making explicit what most organizations leave implicit. It requires four components working together:
Decision categories
Not all decisions carry equal weight or involve the same stakeholders. A decision rights framework begins by categorizing the decisions a project will actually need to make — budget variances, scope changes, vendor selections, milestone approvals, risk responses, resource changes. Each category has different authority implications and different threshold sensitivities.
Authority tiers
For each decision category, authority is mapped across tiers — what can be decided at the working level, what requires managerial approval, what requires executive sign-off, what requires the steering committee. The mapping is not hierarchical by default. A low-cost scope change might require steering committee review because it touches a strategic constraint. A large budget variance within a pre-approved contingency might be within the project manager's authority.
Threshold definitions
Authority tiers become operational when paired with specific thresholds. A working-level budget authority without a dollar amount attached is not a decision right — it is an intention. Thresholds translate authority into something a team member can actually use without needing to ask permission to find out if they need to ask permission.
The decision log
A decision rights framework without a corresponding decision log has no memory. The log captures what was decided, by whom, at what authority level, and on what basis. It serves as the audit trail that prevents retrospective overrides and provides the organizational learning that improves future governance design.
Building It Before You Need It
The right time to design decision rights is during project initiation — before delivery pressure begins, before the first contested decision arrives, before the authority vacuum has had time to fill with workarounds. This is when the conversation is easiest. Stakeholders are aligned on objectives and not yet divided by competing delivery pressures. The sponsor is engaged. The governance appetite is highest.
In practice, this conversation is frequently deferred. The governance design work competes for initiation time with scope definition, resourcing, and planning. Decision rights get treated as something that can be worked out as needed. The cost of that deferral compounds from the first week of delivery.
The investment is a half-day workshop with the right stakeholders, a one-page decision rights matrix, and a brief review at the steering committee kickoff. It is not a large ask. The return — in decisions made faster, in conflicts resolved structurally rather than politically, in delivery confidence across the team — is measurable and consistent.
Decision rights failure is not a symptom of poor leadership, difficult stakeholders, or organizational dysfunction. It is a symptom of governance that was designed to document structure rather than enable decisions. The fix is not a better RACI. It is a framework that translates organizational authority into operational clarity — built before the project needs it, reviewed by the people who will use it, and maintained as a living artifact throughout delivery.
Projects don't fail at the milestone. They fail at the moment someone needed to decide and didn't know if they could.
Authority opacity is the leading structural cause of delivery failure — and it is almost entirely preventable. Define the decision categories. Assign authority tiers with specific thresholds. Review them with your steering committee before delivery begins.
The hesitation, the parallel approvals, the political navigation — these are not organizational character flaws. They are the rational response to an environment where no one actually knows who can say yes. Give them that answer before the project starts.