Ask a room why its RACI chart never gets used, and you will hear about unclear labels or an outdated spreadsheet. The real reason a decision rights framework fails is structural: roles get assigned before anyone agrees on the goal, one senior leader draws the whole chart alone, and nobody revisits it as the organization changes.
That is the diagnosis researchers Lindy Greer, Jennifer Jordan and Maxim Sytch reach in the July-August 2026 issue of Harvard Business Review, drawing on their work with more than 100 companies. Tools like RACI and Bain's RAPID promise clarity about who decides what. Most organizations set them up wrong, then wonder why the same meeting keeps producing the same stalled decision.
Four ways decision-rights tools break down
Greer, Jordan and Sytch found four recurring mistakes in how companies use decision-rights tools, and none of them is really about the tool itself.
- Roles come before the goal. Teams assign who is responsible, accountable, consulted and informed before anyone has agreed what the decision is actually trying to achieve. The roles get filled in around a blank.
- One person draws the whole chart. A single senior leader builds the decision-rights map alone and hands it down, so it reflects that leader's assumptions about who matters rather than where the real expertise and stake actually sit.
- The roles get misread. "Consulted" quietly becomes "must agree." "Informed" becomes "can veto after the fact." Without a shared, behavioral definition of each role, the same chart means five different things to five different people.
- Hierarchy overrides the chart anyway. The matrix says a manager three levels down is accountable, but a senior executive re-decides the call in the corridor. The chart still exists on paper. Nobody follows it in practice.
Their fix treats decision rights as an ongoing practice rather than a document: co-create the roles with the people involved in and affected by the decision, define what each role actually does in behavior rather than in a single letter, and revisit the assignments regularly instead of setting them once and filing them away.
None of the four mistakes look dramatic on their own, which is exactly why they survive. A workshop produces a clean-looking chart, everyone nods, and the document goes into a shared drive next to the org chart nobody else opens either. The failure only becomes visible three months later, when a decision that should take a day takes three weeks, and a debrief turns up four different people who each thought they had the final call.
RACI, RAPID, and why swapping the acronym does not help
RACI assigns each decision one of four roles: Responsible (does the work), Accountable (has final say and owns the outcome), Consulted (gives input before the call is made), and Informed (told after the fact). Bain's RAPID uses five, built around a single Decide role that breaks ties when Recommend, Agree, Perform and Input disagree. The letters differ. The failure mode does not.
Neither acronym fixes anything by itself. A company can swap RACI for RAPID, run the same workshop, produce the same clean-looking chart, and hit the identical wall three months later, because the chart was never the problem. If you want the mechanics of building a RACI matrix step by step, we cover that separately. This piece is about why the underlying idea breaks at the level of strategy execution, and what actually holds it together.
The mistake underneath the mistakes
A RACI chart fails for the same reason a cascaded OKR tree fails. In both cases, people treat a naming exercise, who is R, who is A, whose objective sits under whose, as if it were the structural work itself, when the structural work is connecting that name to something real: a goal, a metric, an owner who can actually act.
Workpath calls the missing piece Ownership Clarity, one of the Four Clarities that make alignment steerable instead of theoretical. Ownership Clarity asks a simple question of every goal: who is accountable, who is responsible, and who must be involved? A decision rights framework is that same question asked one level down, applied to a single call instead of a whole objective. RACI and RAPID are attempts to answer it. They fail when the goal a decision is supposed to serve was never made explicit in the first place, because then "who decides" has nothing to anchor to. You end up with a beautifully filled-in chart attached to nothing.
Why decision rights are getting harder to skip
For a long time, informal hierarchy quietly did this job without anyone writing it down. When nobody documented who decided, a manager two levels up usually did, and everyone in the room knew it. That cover is thinning. In Korn Ferry's 2025 workforce survey, 41% of employees said their organization had already cut management layers, and flatter structures keep spreading as companies lean on AI to absorb coordination work. Fewer managers means fewer people quietly resolving ambiguity by default. What used to be implicit now has to be explicit, or it simply does not happen.
What actually works
Co-create the roles, do not hand them down
A chart drawn by one executive and distributed by email will always be a guess about who has the context to decide. Build it with the people who will actually use it: the person closest to the customer or the data usually knows who should hold the Decide role better than the org chart does. This is slower up front and considerably faster every time the decision actually needs to get made.
Co-creation also surfaces disagreements while they are still cheap. If two department heads both assume they hold the final call on a shared decision, that conflict is far easier to resolve in a thirty-minute workshop than in the middle of a live escalation, where the same disagreement now comes with a deadline attached and an audience watching how it gets settled.
Define behaviors, not letters
Instead of writing "Consulted" next to a name, write what that means in this decision: "gives input in writing before the draft is final, does not get a veto after the fact." Instead of "Accountable," write "makes the final call within five business days of receiving the recommendation." A letter is an abstraction people fill with their own assumptions. A behavior is a commitment people can be held to.
Wire the revisit into the cadence you already run
Decision rights decay the same way alignment decays: quietly, usually right after the org chart, the strategy, or the team changes. The fix is not a separate decision-rights audit twice a year. It is the same discipline that keeps check-ins from turning into status theatre: put decision ownership on the agenda when a goal changes owner, when a team is restructured, or when a review surfaces a decision that stalled because nobody was sure who had the call. A decision right that was accurate in January and never looked at again is not a decision right by July. It is a rumor everyone is still politely following.
Keep decision rights next to the goal, not in a separate document
A decision-rights chart that lives in a slide deck disconnected from the goal it serves will drift out of date the moment either one changes, and nobody will notice until a decision stalls. Keeping ownership visible alongside the goal it belongs to, the same way a Goal Graph makes it visible which goal drives which, means a change to one is a prompt to check the other. Decision rights stop being a static artifact and start being part of the same system that keeps goals honest.
Decision rights are not the same as decision-making
It is worth being precise about what a decision rights framework actually fixes, because it is easy to conflate with the broader discipline of strategic decision-making. Decision rights answer who: who provides input, who has the final call, who carries the decision out. The decision-making system answers how: what evidence a decision runs on, how often the right forum meets, whether the loop closes once the call is made.
A team can have a flawless decision rights chart and still make bad decisions slowly, because the chart never determined whether the room had good evidence or the discipline to act on what it found. The two problems compound each other, and they need separate fixes. Get clear on who decides. Then build the system of forums and evidence that helps them decide well once they have the authority to do it.
Frequently asked questions
What is a decision rights framework?
A decision rights framework is a structured way of assigning who provides input, who has the final say, and who carries out a decision. RACI and Bain's RAPID are the two most common versions. It only holds up when each role is tied to a specific goal and revisited as circumstances change; used as a one-time document, it decays within a few months.
Why does RACI fail in most organizations?
Not because the four roles are wrong, but because of how they get set up: assigned before the goal is clear, drawn by one senior leader instead of the people who will use it, interpreted differently by different people because nobody defined the behavior behind each letter, and overridden by hierarchy whenever a senior leader decides to step in anyway.
What is the difference between a decision rights framework and a decision-making process?
A decision rights framework answers who: who has input, who decides, who executes. A decision-making process answers how: what evidence the decision runs on, how the forum operates, and whether the decision actually gets followed through. You need both, and they are separate problems with separate fixes.
How often should decision rights be revisited?
There is no fixed interval, but the trigger points are predictable: a change in team structure, a goal getting a new owner, or a check-in where a decision stalled because ownership was unclear. Tying the review to those events, rather than to a date on the calendar, catches the drift before it costs a quarter.
Is Bain's RAPID a better alternative to RACI?
Not inherently. RAPID's single Decide role can reduce the ambiguity that comes from RACI sometimes implying joint accountability, but swapping labels does not fix a chart that was assigned before the goal was clear, drawn by one person, or left untouched for a year. The framework matters less than whether it is co-created, behaviorally defined, and revisited.
Who should own building a decision rights framework?
Not one senior leader working alone, which is one of the four mistakes to begin with. Ownership sits best with whoever owns the goal the decision serves, working directly with the people who hold the relevant expertise and the people the decision will affect. The output belongs to the group; a single leader signing off at the end is not the same as a single leader drawing the whole chart from scratch.
A decision rights framework only holds up when it is attached to something a team is actually accountable for achieving. That is the same discipline behind how Workpath connects goals to the people who own them: give every goal, and every decision inside it, one clear owner, and check in on both before either one quietly drifts.
