RACI Matrix Generator

Where RACI came from

RACI has no known inventor. It belongs to a family of charts that project managers call responsibility charts or responsibility assignment matrices: tasks down the side, roles across the top, and a code in each cell. Many articles say these charts date from project management in the 1950s or 1960s. The research for this page could not find a first published RACI chart, or a source that shows who first used the four letters. Treat any page that names an inventor or a year with care.

What can be shown is how practitioners teach it. A guide from the Inland Empire chapter of the Project Management Institute (PMI), by Michael L. Smith and James Erwin, sets out the rules most teams still use¹. Its point is that people hold different pictures of their own jobs. What a person thinks their job is, what others expect of them, and what they actually do often differ. The chart puts all three on one page so the team can settle the differences¹.

• Responsible: the people who do the work. There can be more than one¹.
• Accountable: the one person answerable for the result, with the final yes or no. The guide's first rule is that every task has one A, and only one¹.
• Consulted: people asked for input before the work or decision is done. This is two-way¹.
• Informed: people told after it is done. This is one-way¹.

How to build a RACI matrix well

Name tasks with a verb. "Approve the price" and "Publish the page" can be owned. "Pricing" or "Attend meetings" cannot. The PMI chapter guide suggests starting each row with an action verb and skipping vague rows like "Prepare reports"¹.

Use roles, not names. The chart should still hold if new people filled every role tomorrow¹. A role can be a person, a group or a whole department, including customers or suppliers.

Fill it in order. First mark who does the work (R). Then decide who owns the result (A). Only then add the C's and I's¹. Starting with the A tends to hand every row to the most senior person in the room.

Count the A's in every row. Exactly one. If two people both have a real claim, split the task in two, or decide which one breaks a tie and write it down. One person can be both A and R on a small task.

A weak RACI row and a stronger one

This uses the pricing page launch from the example above. The company and its roles are invented for illustration. The row is "Set the new prices."

The weak row has two A's, so both leaders will think the call is theirs, and no R, so nobody is doing the work. It also asks five people for input on a decision only two can inform.

Common mistakes, and how to spot them

The PMI chapter guide suggests reading the finished chart two ways: across each task, then down each role¹. Most problems show up as a pattern of letters.

Too many C's is the mistake teams make most easily, because adding a name feels polite and removing one feels rude. A useful test: would this person's input change what the R does? If not, they are an I.

Last, share it and revisit it. Send the chart to everyone on it who was not in the room, take their changes, and reissue it¹. A chart nobody has seen since the kickoff is not describing the project any more.

RACI for tasks, a decision-rights tool for decisions

RACI was built for work: who does it and who answers for it. Big decisions are a different problem. Paul Rogers and Marcia Blenko of Bain & Company argue that when decision roles are unclear, decisions get stuck inside the organization². At one carmaker they described in 2006, 83% of the marketing team said marketing decided which features were standard, while 64% of product developers said that call was theirs². A task chart would not have caught that, because both teams did real work on the features.

Tools made for decisions name roles that RACI blurs:

• RAPID, a proprietary tool from Bain & Company, names five roles: Recommend, Agree, Perform, Input and Decide³. "Agree" is a veto that RACI has no letter for, and "Decide" is one person³.
• DACI, set out in Atlassian's Team Playbook, names a Driver who runs the process, one Approver who makes the call, Contributors who have "a voice, but not a vote," and people who are Informed⁴.

A simple rule: use RACI for a project plan or a recurring process. Use a decision tool when the question is "who gets to say yes," especially across teams. Either way, you need one name against each decision. For a leadership team settling who decides what, see aligning a leadership team.

What RACI does not answer, and what to do next

A RACI matrix shows who owns each task. It does not say whether the tasks are the right ones, when they are due, or whether people have time to do them. Fill those gaps before the chart goes out:

• Check this draft. The generator gives one letter per cell. Count the A's in each row, and where the A also does the work, read that cell as A and R. Swap in your real role titles.
• Map the people outside the chart. A stakeholder map shows who has influence over the project and how closely to involve them, which helps decide the C's and I's.
• Add scope and dates. A project charter sets the objectives, scope and milestones the tasks serve.
• List what could go wrong. A risk register rates the likely risks. Give each one a single owner, the same rule as the A.