How to build a RACI matrix

A RACI matrix answers one question for every piece of work: who is doing this, and who answers for it when it goes wrong. It is a grid. Each column is a person or a role, each row is a task or a deliverable, and each cell holds a letter.

The format is old and well travelled: the Project Management Institute describes the RACI chart as one example of a responsibility assignment matrix, the general category of grid that maps people onto work. Most teams meet it as a spreadsheet someone made once and nobody opened again. That version is useless. This guide is about the version that is not.

What the four letters mean

The letters are easy to recite and easy to get wrong, because two of them sound like the same thing.

• R: Responsible. The people who do the work. There can be several.
• A: Accountable. The one person who answers for the result and has the authority to approve it. There is exactly one.
• C: Consulted. People whose input is sought before the work is finished. Two-way: they are asked, and they answer.
• I: Informed. People told what happened afterwards. One-way.

The distinction that carries the whole method is between R and A. Responsible is about effort. Accountable is about authority. If the person you marked A cannot actually reject the work, you have marked the wrong person, and the matrix is describing a hierarchy you wish you had rather than the one you have.

One person can be both. A cell marked A/R is normal and common on small teams: the same person owns the outcome and does the work. What is never acceptable is two different people marked A on one row.

The two rules

Everything else in this guide is advice. These two are rules, and a matrix that breaks either one is not worth distributing.

1. Exactly one A per row. Accountable means a single point of decision. Two accountable people means that when they disagree, nothing can be settled without escalating, which is the precise failure a RACI exists to prevent. Zero accountable people means the task has no owner, and it will be discovered late by whoever is unlucky.
2. At least one R per row. If nobody is responsible, nobody is doing the work. Rows like this are usually aspirations that got typed into a plan.

The RACI builder checks both as you type and flags the rows that break them, because these are exactly the errors that are invisible when you read your own grid.

Building one, in order

The order matters. Most bad matrices are bad because they were filled in left-to-right, one row at a time, which quietly turns into assigning work to whoever is nearest.

1. List the rows before you list the people

Write the deliverables and decisions first, with nobody's name anywhere. You are describing the work, not the team. If you start from the team, you will produce a matrix that justifies the current allocation rather than examining it.

Aim for the level of deliverables and decisions, not activities. "Write and review the code" is a row. "Open a pull request" is not. A useful test: if a row would have exactly the same letters as the row above it, the two rows are one row.

Most real matrices land between six and twenty rows. Past about thirty, nobody reads it, and you are better off splitting it by phase.

2. Add the columns as roles, not names

Use Engineering lead, not Priya. Roles survive people leaving; names do not. Where a role is held by one person and everyone knows it, add the name in brackets.

3. Assign the A first, across every row

Go down the A column before you touch anything else. This is the pass that surfaces the real arguments: the rows where two people both assume they decide, and the rows where everyone looks at everyone else. Resolve those now. They are the reason you are making the matrix.

4. Then the R, then C and I

Responsible next, since that is usually obvious once accountability is settled. Then consulted and informed, and be stingy here. Every C is a person who can hold the work up. A row with five Cs is not thorough; it is a row that will take three weeks.

5. Read it by column, not by row

Now turn the grid ninety degrees. A column with A in almost every row is a bottleneck, and that person is the reason your project is slow. A column with nothing but I is someone who does not need to be on this matrix. A column with no letters at all is a question worth asking out loud.

A worked example

Six rows from a software release, with five roles:

Read down the A column and the structure of the team is visible in about four seconds: the product owner owns scope and communication, the engineering lead owns how it gets built, the release manager owns the act of shipping. Nobody owns everything. That is what a working matrix looks like.

This exact grid is the Software release template in the builder, in all seven languages.

The four ways it goes wrong

Everyone is consulted. The most common failure, and the most expensive. C is a commitment to wait for someone. If you cannot name what you would do differently based on their answer, they are I.

The accountable person has no authority. Marking a project manager A for a decision that only a director can actually make does not transfer the authority; it just means the row is a fiction. Mark the person who can say no.

It is too granular. A forty-row matrix covering individual activities is a document nobody will keep current, which means it will be wrong within a month and misleading within two.

It is written once. A matrix made at kickoff and never revisited becomes wrong quietly; people change roles and the grid does not. Attach it to the document it describes, and review it whenever you review that document. If nothing triggers a review, nothing will trigger a review.

When to use something else

A RACI describes ongoing work: who does what, across many tasks, over time. It is a poor fit for a single decision made once. For that there are purpose-built alternatives: DACI (Driver, Approver, Contributor, Informed), which Atlassian publishes as a Team Playbook play, and RAPID®, developed by Bain and Company and set out in the 2006 Harvard Business Review article "Who Has the D?" by Paul Rogers and Marcia Blenko, which separates the person who decides from the people who carry it out and makes veto rights explicit.

Both are available as modes in the builder, and the differences are worth understanding before you pick: RACI, DACI or RAPID: which one your team actually needs.

Exporting it somewhere people will read it

A matrix only works if it lives where the work lives. The builder exports to Excel and Google Sheets, Word, PowerPoint as an editable table rather than a picture, PDF, CSV, Markdown for Notion, and clipboard HTML that pastes into OneNote or Google Docs with the table intact.

The practical advice: put it in the document it governs (the project plan, the runbook, the charter) rather than in its own file. A matrix in its own file is a matrix nobody opens.