RACI, DACI or RAPID: which one your team actually needs

There is a particular kind of meeting that tells you a team has a decision-rights problem. A choice was made six weeks ago. Someone who was not in the room has since raised an objection, and now the choice is being made again, with a different group, from the start. Nobody is behaving unreasonably. There was simply never an agreement about who got to decide.

Three frameworks exist to prevent that meeting: RACI, DACI and RAPID. They look interchangeable (four or five letters, people mapped to roles), and teams pick between them more or less at random, usually by whichever one a previous employer used. They are not interchangeable. Each was built for a different failure, and using the wrong one produces a document that is busywork at best.

The three failures

It helps to name the failure each framework was designed against, because that is what actually distinguishes them.

RACI is for work that is ongoing and distributed. Its failure mode is diffuse ownership across many tasks: the project where twenty things are in flight and several of them turn out, late, to have belonged to nobody.

DACI is for a single decision. Its failure mode is a decision that never closes: the choice that stays open because no one agreed in advance who would call it.

RAPID is for a significant, cross-functional decision in a large organisation. Its failure mode is the decision that was made and then unmade: the one where someone with real veto power was treated as an advisor, discovered the outcome afterwards, and reopened it.

If you can name which of those three is happening on your team, you have already chosen your framework.

RACI: a map of ongoing work

RACI assigns four roles to every task: Responsible (does the work), Accountable (answers for it, exactly one person), Consulted (asked before it is finished) and Informed (told afterwards). The Project Management Institute treats the RACI chart as one example of a responsibility assignment matrix, the general family of grid that maps people onto work packages.

Its shape tells you what it is for: a grid, many rows, many columns. It describes a body of work over time, not a moment. A software release, a migration, a construction phase, an audit.

Where it works. Any time the question is "across all of this, who is doing what?" The matrix form makes two things visible that prose cannot: the row with no accountable owner, and the column with an accountable owner on every row, the bottleneck everyone complains about and nobody can point at.

Where it fails. RACI has no concept of when. It says the QA lead is responsible for testing; it says nothing about whether testing happens before or after sign-off. It also degrades badly under detail: at forty rows of individual activities it becomes a document nobody maintains, and an unmaintained matrix is worse than none, because people trust it.

And it is genuinely poor at single decisions. You can force one in (one row, letters across it), but the vocabulary is wrong. "Consulted" does not distinguish between someone whose opinion is welcome and someone who can block you.

DACI: a single decision, closed

DACI replaces the letters with four roles aimed at one choice: Driver (coordinates the decision process and keeps it moving), Approver (makes the call, one person), Contributors (supply expertise and analysis) and Informed (told the outcome). Atlassian publishes it as a play in its Team Playbook and uses it internally.

The important move is splitting Driver from Approver. In RACI, the person accountable is often assumed to be the person herding the process. DACI says those are different jobs, and on a real decision they usually are: a product manager runs the process, a director makes the call.

Where it works. Any decision with a deadline and more than three people with opinions. Choosing a vendor. Picking between two architectures. Agreeing a launch date. The artefact is a one-page document, not a grid, and it ends with a decision written down and a date.

Where it fails. DACI has no vocabulary for veto. Everyone who is not the Approver is a Contributor, whether they are a helpful engineer or the head of Legal who can stop the whole thing. In a small organisation that distinction can stay informal. In a large one it is exactly what blows up later.

It is also unsuited to ongoing work. One DACI per decision is fine; forty DACIs describing a project is not a plan.

RAPID: decision rights in a large organisation

RAPID®, developed by Bain and Company and popularised in the 2006 Harvard Business Review article "Who Has the D?" by Paul Rogers and Marcia Blenko, assigns five roles: Recommend (does the analysis and proposes), Agree (must sign off, a genuine veto), Perform (carries out the decision), Input (consulted, without a veto) and Decide (the single person who commits the organisation).

Two things make it different, and both come from the organisations it was built for.

First, Agree is separated from Input. This is the whole point. Most frameworks have one bucket for "people we ask". RAPID splits it into people whose agreement is required and people whose opinion is wanted, and forces you to say which is which in advance. That is the control that stops decisions being unmade.

Second, Perform is a named role in the decision itself. The people who will have to live with the choice are identified while it is being made, which tends to improve the choice.

Where it works. Significant, cross-functional decisions in organisations large enough to have real functional veto power: pricing, entering a market, a platform commitment. It is the most precise of the three.

Where it fails. It is heavy. Running a RAPID on a decision that one person could have made in ten minutes is a tax, and teams that adopt it everywhere quickly stop using it anywhere. In a twelve-person company the Agree role usually collapses into the Decide role, and then you are maintaining a five-letter framework to express a two-letter situation.

Side by side

Choosing, in three questions

1. Is this a body of work, or one choice? A body of work means RACI. One choice means DACI or RAPID. This single question settles most cases, and teams get it wrong surprisingly often, usually by building a RACI for something that was one decision wearing a project's clothes.

2. Can anyone outside the room stop this? If yes, and you cannot simply ask them to decide, you need RAPID, because you need the Agree role. If no, DACI is lighter and will actually get used.

3. Will anyone read it in three months? If not, do not build any of them. Write down who decides, in one sentence, in the document where the work lives. The frameworks are for when the answer has to survive contact with people who were not there.

What none of them fix

It is worth being blunt about this, because these frameworks are sold as cures for problems they do not touch.

They do not create authority. Writing someone's name under Accountable, Approver or Decide does not give them the power to decide. If they cannot say no and make it stick, the document is describing an organisation that does not exist. The correct response is to put the name of the person who can say no in the box, even when that is politically uncomfortable; that discomfort is the information.

They do not substitute for a decision. A completed matrix is not a decision; it is an agreement about who makes one. Teams occasionally finish the framework, feel a sense of progress, and never make the call.

And they do not survive neglect. All three are snapshots. Attach them to the document they govern and review them when you review that document. The failure is never dramatic; nobody announces that the matrix is now wrong. It just quietly stops matching reality, and then someone relies on it.

Using them

All four variants (RACI, RASCI, DACI and RAPID) are modes of the same document in the RACI matrix builder. Switching mode keeps your rows and relabels the letters, so it costs nothing to try a decision as DACI and then as RAPID to see which vocabulary fits what is actually happening.

If you are building your first one, the method is in how to build a RACI matrix, including the ordering trick that surfaces the arguments early rather than at the end.