The RACI matrix explained

Three people are in a project kickoff. Everyone nods when someone says "marketing will handle the launch announcement." Two weeks later, the announcement still hasn't gone out, because the marketing lead thought she was being kept informed rather than asked to write it, and the product manager thought he'd already delegated it. Nobody lied and nobody was lazy. The schedule even had "Launch announcement" sitting on the right date. What the schedule didn't have was a name against a role — and that gap is exactly what a RACI matrix exists to close.

A RACI matrix is a simple grid: the project's tasks or deliverables run down the left side, the people or roles involved run across the top, and every cell where they meet gets exactly one letter — R, A, C, or I. It looks almost too plain to matter. In practice it's one of the fastest ways to surface the kind of ambiguity that sank the launch announcement above, because it forces someone to write down, in public, who is answerable for each piece of work — before the work starts, not after it's late.

What the four letters actually mean

RACI stands for four distinct relationships a person can have to a piece of work, and the tool only works if you keep them genuinely distinct.

• Responsible (R) — the person or people who actually do the work. This is the doer: whoever is at the keyboard, on the tools, or in the room making the task happen. A task can have more than one Responsible person if several people genuinely work on it together.
• Accountable (A) — the person who owns the outcome. They don't necessarily do the work themselves, but they're the one who answers for whether it was done, done correctly, and done on time. Exactly one person holds this role for any given task — more on why below.
• Consulted (C) — people whose input is sought before or during the work, because their expertise or perspective can genuinely change the outcome. This is two-way: you ask, they answer, and the answer feeds into the work.
• Informed (I) — people who need to know what happened, but aren't asked for input. This is one-way: a status update, a completion notice, a heads-up. They don't need consulting, only keeping current.

The direction of the arrow is the whole distinction between C and I: Consulted flows in — their opinion shapes the work. Informed flows out — the work's outcome reaches them. Mixing the two up is how "keeping people informed" quietly turns into a slow-moving committee, which is one of the common mistakes covered below.

Responsible vs Accountable: the distinction that actually trips people up

Every other pair in RACI is fairly intuitive. R and A are not, because in casual speech "responsible for" and "accountable for" are treated as synonyms, and RACI deliberately splits them apart.

Take a homepage redesign. A junior designer builds the actual mockup — she opens the design tool, makes the layout decisions, and produces the file. She is Responsible. The design lead never touches the file, but he reviews it against brand guidelines, approves it before it goes to development, and is the person a stakeholder would go to if the homepage shipped looking wrong. He is Accountable. If the mockup is late or off-brand, the organisation doesn't ask who was clicking the mouse — it asks the design lead, because ownership of the outcome, not the keystrokes, is what Accountable means.

On a small team, R and A are often the same person, and that's completely normal — a solo consultant is both doing the work and answerable for it. RACI earns its keep once work starts crossing desks, which is precisely when people quietly assume someone else has picked up the accountability that nobody actually assigned.

How to build a RACI matrix

1. List your tasks or deliverables down the left. Use the same grain you'd use for a work breakdown structure — specific enough to assign to one owner, broad enough that you don't end up with a hundred rows. "Website" is too broad to assign; "change the button colour on the pricing page" is too granular to bother with.
2. List every role or person across the top. Roles ("Design Lead", "Legal") age better than named individuals if the chart will outlive the current team; names are fine, and often clearer, for a single project with a fixed cast.
3. Assign the Accountable person first, row by row. Deciding who ultimately owns each outcome before deciding who does the work stops accountability from defaulting to whoever's free, and it's the single decision most worth arguing about before you move on.
4. Assign Responsible next. Mark everyone genuinely doing hands-on work — it's fine, and common, if this is the same person as the A.
5. Add Consulted sparingly. Only mark someone C if their input would genuinely change how the task is done. Every C you add is a person the Responsible party has to loop in before finishing — useful when it's the right person, a bottleneck when it isn't.
6. Add Informed last. Mark whoever needs the outcome but has no say in it. If you're tempted to mark someone both C and I, pick one — usually C, since being consulted already keeps them informed of the result.
7. Read every row back. Exactly one A, at least one R, and every C and I earning its place. A row with no R is a task nobody is actually doing — the same failure mode as a Gantt chart bar with no owner, just easier to hide inside a spreadsheet.

Common mistakes

• Too many A's. The most common failure in the whole tool. Two people marked Accountable on the same row feels collaborative and generous, but it dilutes ownership rather than sharing it — when no single person feels the deadline is theirs to protect, it slips more quietly than if one person was visibly on the hook.
• Everyone is Consulted. Marking half the org chart as C feels inclusive and thorough. It also means the Responsible person has to loop in six people before finishing anything, which makes the best-consulted task on your matrix the slowest one on your schedule. Reserve C for people whose input would actually change the outcome, not everyone who might have an opinion.
• Informed as a blanket cc-list. Marking everyone Informed "just in case" turns a meaningful signal into background noise, and people learn to stop reading status updates that never apply to them. Keep the I column as short and deliberate as the C column.
• Confusing Responsible with Accountable. Assuming the person doing the work also owns the outcome is the default mental model, and it's wrong often enough to cause real damage — especially where a junior person executes and a manager is meant to be checking the work before it ships. Collapse the two and nobody is actually reviewing anything.
• Building it once and abandoning it. People change roles, leave, or get reassigned mid-project, and a RACI that isn't updated starts pointing at authority that no longer exists. Treat it as a living document that changes exactly as often as your task list does.
• Matching the wrong grain. A forty-row RACI for a two-week project is a maintenance chore nobody reads. Match your rows to the work packages in your work breakdown structure, not to every individual step inside them.

A worked example

Here's a small RACI matrix for a company website relaunch, with six roles and seven deliverables. No single role is Responsible for everything, every row has exactly one A, and several cells are simply left blank — not every role touches every task, and leaving a cell empty is the correct answer far more often than filling it in "to be safe."

Task	Project Manager	Designer	Developer	Copywriter	Legal	Marketing Lead
Wireframes and sitemap	A	R	C	I	—	C
Visual design	A	R	I	I	—	C
Page copy	I	C	—	R	—	A
Front-end build	A	C	R	I	—	I
QA testing	A	I	R	—	—	I
Privacy policy review	C	—	—	—	R/A	I
Go-live	A	I	R	I	C	C

Read the "Front-end build" row: the developer does the work (R), the project manager owns whether it lands on time and to spec (A), the designer is consulted because implementation choices can affect the visual result, and the copywriter and marketing lead just need to know when it's done. Nothing in that row is complicated, but writing it down means that if the build slips, everyone already agrees whose problem that is — which is precisely the conversation the launch-announcement mix-up at the top of this guide never had.

How a RACI matrix complements a Gantt chart

A Gantt chart and a RACI matrix answer two different questions about the same list of tasks, and most of the confusion between them comes from expecting one to do the other's job. The Gantt chart answers when: it lays tasks against a calendar, sequences them with dependencies, shows how long each one takes, and tracks progress against that timeline. The RACI matrix answers who: for that same task, who does the work, who owns the outcome, who needs consulting, and who just needs the update. Neither substitutes for the other. A Gantt chart full of perfectly sequenced bars can still contain a task with no real owner, which is exactly the kind of task that slips quietly, because everyone assumes someone else is watching it. A RACI matrix full of correctly assigned letters says nothing about whether the plan's dates are realistic — for that you still need the Gantt chart's dependencies and critical path to know whether the sequence even fits in the time available.

The practical move is to build both off the same task list rather than treating them as separate exercises. Once you've broken the project down — see how to plan a project for the full sequence — the same rows that go onto your Gantt chart as bars can go onto a RACI matrix as rows. Keep the two in step: if a task is added to the schedule mid-project, give it a RACI row in the same sitting, and if a task's owner changes, update both the assignment and whoever the bar's progress updates are meant to reach. Done this way, a slipping bar on the Gantt chart and a stalled row on the RACI point to the same fix — go talk to the Accountable person — instead of triggering a meeting just to work out whose job that conversation is.

The short version

A RACI matrix assigns exactly one Accountable owner and at least one Responsible doer to every task, consults only the people whose input matters, and informs only the people who need the outcome. Get the R and A distinction right, resist the urge to mark everyone C or I, and keep the chart alive as roles change. Paired with a Gantt chart that already tells you when everything happens, a RACI matrix closes the other half of the plan: who is actually answerable for making it happen.

Frequently asked questions

What does RACI stand for?

Responsible, Accountable, Consulted, and Informed — the four roles a RACI matrix assigns to every task or deliverable in a project.

Can one person be both Responsible and Accountable for the same task?

Yes, and on small teams or solo projects it is the default — one person does the work and owns the outcome. The distinction starts to matter once tasks pass between people, which is exactly when R and A quietly diverge without anyone deciding it.

Why can a task only have one Accountable person?

Because accountability that is shared is, in practice, held by no one — when two people are both "on the hook," each can reasonably assume the other caught the problem. A task can have several people marked Responsible for the work; it should only ever have one A.

Is a RACI matrix only useful for large projects?

The table itself matters less on a tiny project, but the underlying habit — naming exactly one person who is answerable for each piece of work before it starts — scales down just as well as it scales up.

What is the difference between RACI and RASCI?

RASCI adds a fifth role, Support, for people who provide resources or assistance to whoever is Responsible without doing the core work themselves. It is a common variant worth adopting once a plain RACI stops giving you enough resolution, not a requirement from day one.