RACI Chart: When You Need One (and When You Don't)

A RACI chart is a grid. Work on one axis, people on the other, one of four letters in every cell: Responsible, Accountable, Consulted, Informed. That’s the entire idea, and every article on page one of Google takes 2,000 words to say it.

What none of them tells you is when not to build one. The pages ranking for this term — Atlassian, Wrike, project-management.com — all sell project management software, so none has any incentive to say “you probably don’t need this.”

I’ve been on both sides. At a 130-person company, a RACI is why a four-team pricing migration shipped in one quarter instead of two. At a six-person startup, I watched a founder spend a Tuesday afternoon on one that was wrong within a fortnight and forgotten within a month. Same tool, opposite outcomes, and the difference wasn’t the template.

RACI in one screen: the four roles and a real matrix

RACI stands for Responsible, Accountable, Consulted, Informed. Here’s what each role permits and forbids — the part the definitions skip:

• Responsible — does the work. Several people can be R on one row. R is a verb, not a job title: if you can’t name what this person will produce, they’re not R.
• Accountable — owns the outcome and signs it off. Exactly one per row, never delegated. The A is often also an R; that’s fine.
• Consulted — two-way. Their input is sought before the work lands, and it can change the outcome. If their opinion can’t change anything, they’re not C.
• Informed — one-way, after the fact. They get told. They don’t get a vote.

That C/I boundary is where most charts leak: people get marked C as a courtesy, then act like they hold a veto, and the R stops moving. Mark someone C only if you’d genuinely change the work because of what they say.

A real matrix — a quarterly pricing change at a 40-person SaaS company:

Deliverable	Founder	Product	Marketing	Eng	Support
Choose the new price points	A	R	C	I	C
Approve the claims on the page	I	A	R	—	—
Ship the page change	I	C	A	R	I
Billing + grandfathering logic	I	C	I	A/R	C
Email existing customers	C	I	A/R	I	C
Update support macros + refunds	I	I	C	I	A/R

Now read it diagnostically, which no template teaches:

• Read the A column top to bottom. Accountability should step down the org as risk falls. If every A is the founder, you don’t have a RACI — you have a bottleneck drawn as a table.
• A row with no R is a wish. Someone approves it, people watch it, nobody makes it.
• A row that’s all C and I is a meeting, not a deliverable. Delete it.
• An A on more than five rows is the next thing to break.

Six deliverables, six owners, no shared accountability. The authority column is the part most charts leave out.

Do you actually need a RACI? A threshold test

A RACI is a purchase: it buys clarity and costs upkeep. The honest question is whether your ambiguity is expensive enough to be worth paying for.

Here’s the arithmetic. If n people could plausibly own a piece of work, the number of “I thought you had it” pairs is n(n−1)/2. Three people: three ways to drop it. Six: fifteen. Ten: forty-five. Ambiguity grows with the square of headcount — which is why the same chart is ceremony at six people and a rescue at 130.

Score the work in front of you, one point each:

1. More than eight people touch it.
2. More than one function has to say yes before it ships.
3. It runs longer than a month.
4. A wrong call takes more than a week to unwind.
5. A handoff crosses a time zone, an agency, or a contractor boundary.
6. Someone will join it mid-flight.

0–1 points: don’t build a chart. Say the owner’s name out loud and move. 2–3 points: you need written ownership, not a matrix. Use the owner list below. 4+ points: build the matrix. The upkeep will pay for itself.

Wrike cites research that only 20% of organisations excel at decision making. Real problem — at scale. Not a reason for a five-person team to draw a grid.

Below the threshold: the one-line owner list

In the 2–3 band, this is what I use. Four columns, not twenty:

Outcome — Owner — What they can decide alone — Date

One line per outcome, one name in the owner column, never two. The third column is the one people skip and the one that does the work — the difference between “Priya owns onboarding” and “Priya owns onboarding and can change the flow, copy and emails without asking; new pricing comes to me.”

It lives in the task list, not a document, and gets corrected weekly — about four extra minutes inside a weekly planning session.

Escalate to a matrix when the same outcome changes owner twice in a month, or when you want a fifth column. Until then, single-owner task hygiene does everything a RACI would, at a fraction of the cost.

Three plausible owners make three pairs of “I thought you had it”. Ten make forty-five.

Is RACI outdated?

People ask Google this constantly, and not one page ranking for the term answers it. So, plainly: no, RACI is not outdated. It is over-applied.

Three real complaints sit behind the question, each partly fair.

“It’s static and projects are dynamic.” True — Atlassian’s own guide admits the matrix is “a static representation of a dynamic project”. That’s an argument for a review cadence, not for abandonment. A chart with a date on it isn’t static.

“It oversimplifies.” Also true. Wrike makes the sharpest version: a business analyst marked C often influences the outcome far more than “consulted” suggests, and real people hold several roles at once. The fix is fewer rows with more precision, not a longer alphabet.

“It conflicts with collective ownership.” The agile objection, and the weakest: teams that own work collectively still have one person who talks to the customer when it breaks. RACI doesn’t create that person, it writes them down.

What has changed: tools absorbed part of RACI’s job — a task with a single assignee is a one-cell RACI — and for pure decisions, decision-specific frameworks have overtaken it. Atlassian, which sells this stuff, says reach for DACI first when the question is decision authority. I agree.

What is the golden rule of RACI?

Exactly one A per row. Not one per project, not one per team — one per row. Every guide states it and none defends it, so here’s the defence.

A cutover I sat through: a database migration with a fixed monthly maintenance window. Two people were marked accountable for the go/no-go — the engineering manager and the ops lead — because both were senior and picking one felt political. Neither fought. That’s what people get wrong about two A’s: they expect a clash. Instead each waited for the other’s signal, the window closed at 4am with nothing shipped, and the next was thirty days out. One line on a chart, one month of runway.

Two Accountables don’t produce conflict. They produce mutual deference, invisible until the deadline. A conflict you can see and resolve; a silence you can’t.

A isn’t a measure of effort or seniority. A is the tiebreak — the answer to “if the people doing this disagree, whose call is it?” Write two names and you’ve documented a deadlock and called it alignment.

The test I use before accepting any A: finish the sentence “When this goes wrong, ___ will be the one explaining it.” If more than one name fits, the row isn’t ready.

The power-dynamics problem — and the fix nobody writes down

Wrike is the only article on the page honest enough to raise this: a junior marked Responsible may still not act without senior approval. It says so in two sentences and moves on — a shame, because this is the most common reason a technically correct RACI produces zero behaviour change.

The chart says Sam is R. The org says Sam’s director will have opinions. Sam, sensibly, asks first, and every “responsible” becomes a request for permission: latency without autonomy.

The fix has three parts, none of them in the template.

1. Assign the A to the decision, not the seniority level. Write it as a sentence with a threshold in it — “approve copy changes that don’t alter a pricing claim” — not a noun like “marketing sign-off”.

2. Give every row an authority envelope. One line stating what R may do without asking and what forces escalation:

R may change layout, copy and imagery. Escalate if the change alters a pricing claim, creates a legal commitment, or costs more than $2k.

This is the field that makes a RACI operational. Without it, “Responsible” means “does the typing”.

3. Put a clock on the Consulted. When a senior stakeholder keeps overriding a junior R, mark them C and give C a response window: input due within 48 hours or R proceeds. Silence becomes consent, with a deadline. That converts an implicit, unlimited veto into a timed input — which is what everyone thought “consulted” meant anyway.

One diagnostic: if an R has asked permission three times for the same class of decision, the envelope is wrong or the A is wrong. Redraw the row. Done well, this buys back a surprising amount of uninterrupted working time — most permission-seeking is just an unwritten envelope.

RACI for distributed and async teams

Nobody ranking for this keyword writes about async work, which is strange, because that’s where the tool earns most. Co-located, “wait, who owns this?” costs thirty seconds. Across an eight-hour offset it costs a working day: ask at 5pm, read the answer tomorrow, act the day after. Same ambiguity, roughly 200x the price. Distributed teams should reach for a RACI earlier than the threshold test suggests, not later.

• Size every C window to the widest gap plus one working day. A 48-hour clock is generous in one office and impossible across Berlin, Lagos and San Francisco. Write actual hours.
• Define I as an artefact, not an event. “Informed” names the thing they’ll read — the Friday update, the release channel. “They were in the meeting” isn’t informing, it’s hoping.
• Add a decision cut-off column. Record the last hour in the R’s day at which a request to the A still gets answered same-day. It sounds fussy. It removes a whole category of silent one-day slips.
• Make the R publish a written definition of done. The A can’t watch the work happen, so it needs something to check against before it starts.

Building one that doesn’t go stale

The build is fast: list deliverables (not activities), draft the letters yourself in twenty minutes, then spend a live half-hour with the team fixing it. Never crowdsource the first draft — a blank grid and six people on a call burns two hours and produces mush.

Maintenance is what nobody quotes, so here’s my honest number: roughly 20 minutes per fortnight per ten rows, most of it re-checking that the A column still reflects who’s actually deciding. A thirty-row chart is an hour a month, forever. That’s the sticker price.

Three rules keep it alive.

The chart needs an A of its own. This omission kills most matrices — a responsibility document with no owner is the joke that writes itself. Name who updates it and date the file.

It has to live where the work lives. Wrike’s best-practice list gets this right — keep it in the tool, not a separate doc — but never connects it to the staleness problem it describes a few paragraphs earlier. Same problem: a matrix in a wiki nobody opens is stale by construction. One cell of a RACI is just a task’s assignee field, which is why I keep ownership on the tasks themselves in Fokus and treat the grid as a summary of what those tasks already say.

Delete it when it goes quiet. If the chart hasn’t been touched in two review cycles, remove it. This feels wasteful and isn’t: a deleted chart makes people ask who owns something, a stale one makes them assume. My weekly review in Fokus is where that call gets made — corrected on a Friday, or retired.

Atlassian names the limitation best: a RACI “doesn’t offer guidance on performing tasks, resulting in inconsistencies caused by varied interpretations of responsibilities”. It tells you who, never how well.

When RACI is the wrong matrix: RASCI, DACI, RAPID and CARS

Pick by the shape of your ambiguity:

• RASCI adds an explicit Supportive role — Cornell’s IT documentation describes it best. Use it when many people help without being on the hook.
• DACI (Driver, Approver, Contributor, Informed) is for decisions, not ongoing work.
• RAPID (Recommend, Agree, Perform, Input, Decide) splits recommending from deciding, for when expertise and authority sit apart.
• CARS (Communicate, Approve, Responsible, Support) is slimmer, for comms-shaped problems.

Rough rule: ambiguity about who decides → DACI or RAPID. About who does the ongoing work → RACI. About which of forty things matters this week → not a matrix at all; that’s a prioritisation problem, and no responsibility chart has ever solved one.

The short version

R does the work, A owns it, C shapes it beforehand, I hears about it after. The golden rule is exactly one A per row, because A is the tiebreak and two tiebreaks is a deadlock in disguise.

RACI isn’t outdated; it’s over-applied. Run the six-question test. Under two points, name an owner and move on. In the middle, write one line per outcome with decision rights spelled out. Above four, build the grid, give every row an authority envelope, put a clock on the Consulted, keep it where the work lives, and delete it the day it stops being true.

A chart that’s right and ignored is worth nothing. A chart that’s wrong and trusted is worth less than nothing.