RACI Matrix: Template, Examples, and How to Build One

Rock

>

Blog

>

Future of Work

>

A RACI matrix sorts who does what on a project into four roles: Responsible, Accountable, Consulted, and Informed. Done right, it removes the "I thought you had it" moment from projects. Done wrong, it becomes a spreadsheet full of letters that no one consults after the workshop ends.

This guide covers what RACI actually is, how to build one, and a worked example with real assignments. It also covers the honest failure modes nobody else writes about, and when alternatives like DACI or RAPID fit better. The builder below validates your work as you go, warning when a task has zero Accountables or two.

Contents

  1. What is a RACI matrix?
  2. R, A, C, I explained
  3. RACI matrix template
  4. A worked example
  5. When RACI is useful (and when it is theater)
  6. RACI vs DACI vs RAPID vs RASCI
  7. How to run a RACI workshop
  8. FAQ

What Is a RACI Matrix?

A RACI matrix is a responsibility chart that assigns each project task to four role types: Responsible (who does the work), Accountable (who owns the outcome and signs off), Consulted (who gives input), and Informed (who is kept in the loop). It is also called a responsibility assignment matrix (RAM), RACI chart, or responsibility matrix.

  • R, Responsible: does the hands-on work. Can be more than one person per task.
  • A, Accountable: owns the outcome. Exactly one per task.
  • C, Consulted: gives input before decisions. Two-way communication.
  • I, Informed: kept in the loop after decisions. One-way communication.

Build your RACI matrix

Click a cell to cycle through R, A, C, I, and blank. Each task needs exactly one Accountable (A). Click task names and column headers to rename.

R
Responsible: does the work
A
Accountable: owns the outcome
C
Consulted: gives input
I
Informed: kept in the loop
+ Add task
0 tasks
Responsibility clarity in one place. Rock keeps the RACI next to the tasks it governs, so everyone sees who owns what without opening a second tool.
Try Rock free →×

R, A, C, I Explained

Most teams know the letters but misapply two of them. The R vs A distinction is where RACI usually breaks.

Team members representing different RACI roles on a project
A clear R, A, C, I assignment gives every team member a known role on the project.

Responsible (R) is the person who actually does the work. A task can have multiple R assignments if the work is split. Writing the homepage copy might have the copywriter and the designer both marked R, because both contribute to the deliverable. The R role answers "who is doing this?"

Accountable (A) is the person who owns the outcome and makes the final call. A task can have only one A. If two people are accountable for the same task, nobody is. This is the rule most teams break. The A role answers "who approves this and is on the hook if it fails?" Often the Accountable person is also Responsible, but not always. A manager might be Accountable while delegating Responsible to a team member.

Consulted (C) is anyone whose input shapes the task before it is completed. They get asked. Two-way conversation. Legal might be Consulted on a pricing page before it launches. Consulted is valuable but expensive; if 8 people are Consulted on every task, the project stalls in approvals. Cap Consulted roles per task at 2 or 3.

Informed (I) is anyone who needs to know after the task is done, not before. One-way communication. The support team is usually Informed when a new feature ships, not Consulted during design. Informed is cheap and scalable. Overuse does not slow the project; it just fills inboxes.

"Clearly defining roles helps in reducing duplicated efforts, which streamlines processes and minimizes wasted time and resources." - Atlassian Team Playbook

RACI Matrix Template

The builder above gives you a live, editable RACI matrix with validation. For a downloadable version, here is the standard template structure any tool can produce.

Rock workspace showing tasks with assignees across roles
In Rock, every task carries its owner and followers so RACI lives where the work happens.

Rows: project tasks or deliverables. Break the project into the 10-20 tasks that actually need role clarity. Not every subtask needs a row. If a task is obviously one person, skip it.

Columns: project roles. Use roles, not names. "Project Manager" scales to the next project; "Priya" does not. Typical columns for an agency project: Project Lead, Designer, Developer, Copywriter, Client, Stakeholder. Cap at 6-8 roles. More columns make the matrix unreadable. For figuring out who belongs in that column list, run a stakeholder map first.

Cells: one letter per cell. Most cells will be blank. A blank cell means the role has nothing to do with that task. That is normal and correct. A fully-populated matrix is usually over-managed.

Check rule: every row has exactly one A. No exceptions. Rows with zero A have no owner. Rows with two A have no owner either, because "shared accountability" ends up as "no accountability" once deadlines arrive.

Worked Example: Website Redesign

Here is a filled RACI matrix for a 6-week website redesign with 5 roles and 8 tasks. Real reasoning per assignment, not placeholder labels.

Team mapping tasks and roles during a RACI workshop
A filled RACI for a real project looks like a shared map more than a spreadsheet.

Task: Write project brief. R: Project Lead. A: Project Lead. C: Client, Stakeholder. I: Designer, Developer. The Project Lead writes the brief (R) and signs it off (A). The Client and Stakeholder are Consulted because their input shapes scope. The Designer and Developer are Informed so they can start thinking about the work.

Task: Design wireframes. R: Designer. A: Project Lead. C: Developer. I: Client. The Designer does the work (R); the Project Lead owns the outcome (A) because wireframes affect scope and timeline. Developer is Consulted (technical feasibility). Client is Informed, not Consulted, because showing wireframes to clients before polish derails design discussions.

Task: Client reviews wireframes. R: Client. A: Project Lead. C: Designer. I: Developer. The Client does the reviewing (R); the Project Lead owns moving the review through (A). Designer is Consulted to clarify intent. Developer is Informed.

Task: Build the page. R: Developer. A: Developer. C: Designer. I: Project Lead, Client. The Developer does the work and owns the deliverable. Designer is Consulted for design questions. PM and Client get status updates (I), not sign-off.

Task: QA and testing. R: Developer, Project Lead. A: Project Lead. C: Designer. I: Client. Both do hands-on QA; PM signs off. Designer is Consulted on visual bugs.

Task: Legal approval of copy. R: Legal (Stakeholder). A: Project Lead. C: Copywriter. I: Client. Legal does the review (R); PM owns the process (A). Copywriter is Consulted to clarify intent.

Task: Launch the page. R: Developer. A: Project Lead. C: Designer. I: Client, Stakeholder. Developer executes. PM owns. Everyone else watches.

Task: Post-launch monitoring. R: Project Lead, Developer. A: Project Lead. I: Designer, Client, Stakeholder. Both monitor; PM owns.

Notice: every task has exactly one A. R and A often overlap (Developer builds and owns the build). Consulted is kept under 2 per task. Informed is used liberally because it is cheap. These four patterns are the difference between a RACI that works and one that collects dust.

When RACI Is Useful (and When It Becomes Theater)

RACI works when three conditions are true: the project has more than 3 people, the work spans multiple weeks, and ownership is actually unclear. If any of those is missing, RACI is overhead.

Skip RACI when the team is under 4 people. Small teams know who does what by default. A formal matrix adds ceremony without clarity.

Skip RACI for short projects (under 2 weeks). The time to build and maintain the matrix exceeds the value. A simple "owner per task" column in a shared doc works better.

Skip RACI when the ambiguity is at the decision level, not the task level. RACI tells you who does the work. It does not tell you who decides. If your problem is "we cannot get approvals," the Bain RAPID framework handles that cleanly (see the comparison below).

"At many companies, decisions routinely get stuck inside the organization like loose change." - Paul Rogers and Marcia W. Blenko, Bain & Company, Harvard Business Review

RACI becomes theater when:

(1) Every task has the same 4 people marked the same way. The matrix is not discriminating anything; it is just a checkbox exercise. Red flag: if Accountable is "Project Manager" for every single row, you do not have a RACI, you have a one-person project with extra paperwork.

(2) The matrix is built once in a workshop and never updated. Real projects change. If the RACI you wrote in week 1 does not match how the team actually works in week 4, either update it or archive it. A stale RACI is worse than no RACI because people cite it when convenient and ignore it when inconvenient.

(3) Consulted lists are 5+ people per task. At that point the project is not being prioritized, it is being approved-to-death. Cap Consulted at 2-3 per task.

(4) Two A's on the same task. Happens when leadership does not want to pick. "We will share accountability" guarantees neither person picks up the phone when the project slips. Force the choice upfront.

RACI vs DACI vs RAPID vs RASCI

RACI is not the only responsibility framework. If RACI does not fit your situation, one of these probably does.

Framework What it stands for Best for Weakness
RACI Responsible, Accountable, Consulted, Informed General project role clarity across a team Becomes paperwork on simple projects
RASCI Adds Supportive to RACI Complex cross-functional work with helpers Adding letters does not fix unclear accountability
DACI Driver, Approver, Contributors, Informed Decision-making (not execution) Too narrow for day-to-day work
RAPID Recommend, Agree, Perform, Input, Decide Strategic decisions at senior leadership level Overkill for operational tasks

Pick RACI when the unclear part is "who does what" on a multi-week project with 4+ people.

Pick RASCI when RACI is close but you keep finding a fifth role type for people who support without being responsible. Adding the S makes the matrix more precise. It does not fix deeper accountability problems; if A is ambiguous, adding S will not help.

Pick DACI when the ambiguity is around decisions, not execution. DACI names the Driver who moves the decision forward and the Approver who makes the call. Good for product, design, and strategy calls where execution is fine but decision speed is broken.

Pick RAPID when the decisions are senior-level and cross-functional, and nobody can name who owns the call. Bain's framework (2006) is heavier than DACI but stronger when org design itself is the problem. The Bain HBR piece quoted above is the canonical source.

How to Run a RACI Workshop

A good RACI workshop takes 60-90 minutes with 4-8 people. Anything more is committee. Anything less is missing stakeholder perspective.

Prep (15 min before). List the 10-20 project tasks that actually need role clarity. Skip trivial or single-owner items. List the 5-8 roles involved. Share both lists 24 hours before the workshop so people form opinions beforehand.

Round 1, individual assignments (15 min). Each person silently fills out the matrix. No discussion. Silence prevents the loudest voice from anchoring the group.

Round 2, surface disagreements (30 min). Review rows where the team disagrees. Usually 20-30 percent of rows. For each: 1-minute debate, then a vote. If it is a tie, the more senior role (or the sponsor) breaks it. Write down the reasoning, not just the letter.

Round 3, validation (10 min). Walk through every row and confirm: exactly one A, Consulted under 3, Responsible clear. Any row that fails goes back for rework before the workshop ends.

Round 4, output and ownership (5-10 min). Document the matrix in a shared doc or task tool. Name the sponsor who owns it. Set a recurring review (monthly for long projects, at each milestone for shorter ones). Archive when the project ends.

What we do at Rock. We run RACI workshops as a pinned note at the top of a project space. The matrix lives next to the task board that tracks the actual work, so when a task comes up in chat, the RACI is one click away. When the project ends, the space stays archived with the RACI attached, which is how we avoid the "who owned this again?" conversation two quarters later.

"In almost every organization I have advised, I have encountered the same problem: far too many projects, and far too few that truly matter." - Antonio Nieto-Rodriguez, Harvard Business Review
RACI matrix grid with tasks on rows and roles on columns
A RACI matrix lays out every project task against every role, with one Accountable per row.

Frequently Asked Questions

What does RACI stand for? Responsible, Accountable, Consulted, Informed. Responsible is who does the work (can be multiple people). Accountable is who owns the outcome (exactly one per task). Consulted is who gives input before the task is done. Informed is who is kept in the loop after.

Who invented the RACI matrix? The concept traces to management consulting in the 1950s-70s, with modern RACI popularized through the Project Management Institute (PMI) and included as a standard responsibility assignment matrix (RAM) technique in the PMBOK Guide. Unlike MoSCoW or RAPID, RACI has no single named inventor.

Can a task have more than one Responsible? Yes. Multiple Responsibles are fine if the work is genuinely shared. What you cannot have is multiple Accountables. R can be 1-to-many; A must be exactly 1.

What is the difference between Responsible and Accountable? Responsible does the work. Accountable owns the outcome and signs off. A task can have many Responsibles but only one Accountable. Often Accountable is also one of the Responsibles, but not always. A team lead can be Accountable while a team member does the work.

Is RACI agile-friendly? Agile teams often skip formal RACI because the structure (product owner, developers, scrum master) already names roles. If your agile team needs RACI, that is a signal the roles are not being held or the project is cross-functional in ways the standard agile roles do not cover.

What are the disadvantages of RACI? Main failures: ballooning Consulted lists that stall decisions, two A's on one task that erase accountability, matrices that never get updated after the kickoff workshop, and teams that use RACI on projects too small to justify the overhead. The "When RACI is theater" section above covers each with a fix.

Running a RACI matrix is only half the battle. Keeping it visible while the work happens is the other half. Rock combines chat, tasks, and notes so the RACI stays next to the tasks it governs. Get started for free.

Rock workspace with chat tasks and notes

More on running projects well: MoSCoW method (sibling framework for scope), how to prioritize tasks with 7 frameworks, how to write a project plan (where RACI fits inside a plan), project vs task, how to define project scope, and how to run a retrospective.

Share this

Rock your work

Get tips and tricks about working with clients, remote work
best practices, and how you can work together more effectively.

Rock brings order to chaos with messaging, tasks,notes, and all your favorite apps in one space.