A project drifts for three weeks. When you finally ask why, everyone has been busy, drafting, reviewing, "waiting to hear back." What nobody can tell you is who was supposed to make the call. That gap, between doing the work and owning the decision, is what RACI and RAPID exist to close. They are two of the most widely used tools for writing down, in plain ink, who is responsible for what and who holds the right to decide.

The quick version

  • RACI maps roles to a task or deliverable: Responsible (does the work), Accountable (owns the outcome, exactly one person), Consulted (gives input), Informed (kept in the loop).
  • RAPID maps roles to a decision rather than a task: Recommend, Agree, Perform, Input, Decide, with one decider per decision.
  • The rule that does most of the work in both: one owner. One Accountable, one Decider. Shared accountability usually means no accountability.
  • These are clarity tools, not a substitute for trust or judgement. Over-mapped, they become bureaucracy; the point is to remove ambiguity from the few choices that matter, not to chart everything.

The idea in depth

The two frameworks answer different questions, and confusing them is the first mistake leaders make. RACI is a responsibility assignment matrix: it sits over a list of tasks or deliverables and, for each one, names who does it, who is answerable for it, who must be consulted, and who is merely kept informed. There is no single inventor, it grew out of linear responsibility charts used in consulting and systems engineering, took its modern shape across the 1970s and 1980s, and is now embedded in standards such as the PMBOK (background via the Responsibility Assignment Matrix reference).

Its load-bearing rule is the A. The convention most project-management treatments settle on is exactly one accountable stakeholder per task or deliverable, one person ultimately answerable for whether it lands. Responsible can be many; Accountable is one. So the practical first move is this: before you assign anyone to do the work, find the single name that goes in the A column for each deliverable. If you can't, or if two names are fighting for it, you have found the ambiguity that will cause the drift, not later, but now.

flowchart TD
  T(["A deliverable
(one row of the matrix)"]) --> A(["Accountable
one owner, answers for it"])
  T --> R(["Responsible
one or more, do the work"])
  T --> C(["Consulted
two-way input before it's done"])
  T --> I(["Informed
one-way, kept up to date"])
RACI reads down a single deliverable: exactly one Accountable, the rest assigned around it. Leaders Loop

Where RAPID is different, and why it exists

RACI is built for execution: who does and owns the work. It is weaker when the bottleneck is a decision, a strategic choice where the hard part isn't doing anything yet, but agreeing who gets to say yes. That is the gap RAPID was designed to fill. Bain & Company partners Paul Rogers and Marcia Blenko set out the thinking in their Harvard Business Review article "Who Has the D? How Clear Decision Roles Enhance Organizational Performance" (January 2006), later expanded in the book Decide & Deliver (Blenko, Mankins & Rogers, Harvard Business Review Press, 2010). The premise is blunt: organisations don't underperform because of bad strategy so much as because nobody is clear on who has "the D", the decision.

RAPID assigns five roles to a single decision. Recommend drives the process and proposes a course of action; Agree must sign off where a veto genuinely belongs (legal, compliance, risk) and is used sparingly; Input supplies the facts and expertise but does not get a vote; Decide is the one person who commits the organisation; Perform are the people who then carry it out (per Bain's own description of the tool). The acronym is deliberately not in sequence, a working order is closer to Input, then Recommend, then Agree, then Decide, then Perform, which is exactly why teams misread it, so spell the roles out rather than assuming the letters tell the story.

flowchart LR
  I(["Input
facts & expertise, no vote"]) --> Rec(["Recommend
drives it, proposes a course"])
  Rec --> Ag(["Agree
sign-off where a veto belongs"])
  Ag --> Dec(["Decide
one person commits the org"])
  Dec --> Per(["Perform
those who carry it out"])
RAPID read as a flow, not the acronym's order, input feeds a recommendation, agreement gates it, one person decides. Leaders Loop

For a decision that keeps stalling, the fix is usually the same: name the single Decider out loud, and be ruthless about the Agree role. An Agree is a veto, and vetoes slow everything down, give one only to people whose sign-off is genuinely required, not to everyone senior who wants to feel included. The most common pathology RAPID surfaces is a decision with five "deciders" and no one who can actually commit.

There is a related, well-evidenced reason to keep the cast small. In Decide & Deliver, the Bain authors offer a "rule of 7": once a decision-making group passes seven people, each additional member reduces decision effectiveness by roughly 10%, so a group of seventeen or more rarely decides anything at all. Treat the exact percentage as a rule of thumb from one firm's client data rather than a law of nature, but the direction is hard to argue with: Input can be wide; the right to decide must be narrow.

Responsible can be many. Accountable is one. The Decider is one. Almost every stalled decision is a violation of that single rule.

An honest limitation: clarity is not the same as good judgement

Both tools are easy to overdo, and a leadership writer who doesn't say so is selling you something. RACI and RAPID describe a tendency toward clarity; they don't guarantee it. Map every task in a large project and you produce a grid nobody reads, the dreaded "RACI of everything" that takes longer to maintain than the work it governs. Worse, a tidy matrix can give the appearance of clarity while the real decision rights still live in informal power, the person who isn't the Decider on paper but whose displeasure quietly kills any choice they dislike.

Neither framework tells you whether the decision was any good, whether the owner has the competence to make it, or whether people will follow through once it's made. They remove ambiguity; they do not manufacture trust or judgement. So point them at the handful of recurring decisions and deliverables that actually cause friction, the ones that stall, get re-litigated, or fall between two teams, and leave the rest to ordinary management. A short RACI on three things that matter beats an exhaustive one on thirty that don't.

A worked example

Take a mid-sized company, call it Harbour, relaunching its website. (Illustrative scenario throughout; not a real organisation.) The project has slipped twice. The design is done, the build is half-finished, and the launch date has moved because, every time it nears, marketing wants different copy, the CFO raises a brand concern, and the engineering lead won't ship without a sign-off nobody can locate.

Pull the two questions apart. First, the deliverables, a RACI. "Homepage build" is Responsible: two engineers; Accountable: the engineering lead (one name, not "the eng team"); Consulted: design and brand; Informed: the wider company. "Launch copy" gets its own row, Accountable to the head of marketing. Suddenly the brand objections have a home: they belong in the Consulted column on specific rows, not as a floating veto over the whole project.

Second, the choice that actually keeps moving the date, "do we launch on the 14th?", is a decision, so it gets a RAPID. Input: engineering (is it stable?), marketing (is the copy ready?), support (can we handle the traffic?). Recommend: the project lead, who weighs that input into a go/no-go proposal. Agree: legal, only on the privacy-policy change, a real veto, narrowly scoped. Decide: the head of digital, one person. Perform: engineering and marketing on launch day.

flowchart TD
  S(["Launch keeps slipping
why?"]) --> Q{"Is it a deliverable
or a decision?"}
  Q -->|"Deliverable: build, copy"| RA(["RACI each row
one Accountable per item"])
  Q -->|"Decision: launch on the 14th?"| RP(["RAPID the call
one Decider, narrow Agree"])
  RA --> O(["Brand objections become
'Consulted', not a floating veto"])
  RP --> O2(["Go/no-go has an owner
the date stops moving"])
The fix isn't more meetings, it's separating who owns the work from who owns the call. Leaders Loop

Nothing about Harbour's team changed. The same people did the same work. What changed is that the brand concern stopped being an ambient veto and became a Consulted input on two rows, and the launch decision acquired a single owner who could finally say "go." That is the whole trick: most paralysis is not a shortage of effort or talent, it's an unwritten ambiguity about rights, and writing it down is nearly free.

Frequently asked questions

What's the difference between Responsible and Accountable in RACI?

Responsible is the person (or people) who does the work. Accountable is the single person answerable for whether it gets done correctly, the one who carries the consequences. You can have several Responsible names on a task, but you should have exactly one Accountable. When the two collapse into the same person, that's fine; when "Accountable" is a team or a committee, you've reintroduced the ambiguity the matrix is supposed to remove.

When should I use RACI versus RAPID?

Reach for RACI when the question is "who does and owns this work?", tasks, deliverables, ongoing processes. Reach for RAPID when the question is "who gets to make this call?", a strategic or contested decision where the bottleneck is the choice itself, not the doing. Many situations need both: a RACI for the deliverables and a RAPID for the one or two decisions that keep stalling them.

Aren't these just bureaucracy in a nicer font?

They can be, if you map everything. Applied to a hundred trivial tasks, a responsibility matrix is overhead that nobody updates. Applied to the handful of decisions and deliverables that actually cause friction, the ones that stall, get re-argued, or fall between two teams, they pay for themselves in a single avoided week of drift. The discipline is restraint: chart the few things that matter, not all the things you could.

What about variants like RASCI or DACI?

They're the same idea with different letters. RASCI adds Support (people who assist the Responsible); DACI swaps in a Driver and is popular in product teams; CAIRO/RACIO adds an Omitted role to record who is deliberately kept out. Pick one and use it consistently, the value is in the shared vocabulary, not the acronym. Switching frameworks mid-project just trades one confusion for another.

Who decides who holds the decision rights?

Usually the leader who owns the outcome the decision serves, and the act of assigning rights is itself a leadership decision worth making openly. The trap is letting decision rights accrete informally, so that the real Decider is whoever has the most political weight rather than the most relevant judgement. Naming it explicitly, in front of the people affected, is what converts an unwritten power map into something a team can actually work with.

Related in the Toolkit

Decision rights are the connective tissue of an operating model, they only make sense against the shape of the organisation (org structures) and the way work actually flows through it (operating models & ways of working), and they sit at the heart of one of the oldest design tensions there is: how much authority lives at the centre versus the edge.

Where to go next