A RACI chart that enforces single accountability
A RACI matrix makes project roles unambiguous: who does the work, who owns the outcome, who is consulted, and who is informed. This builder lays activities down the rows and people across the columns, lets you assign one role per cell, and — crucially — checks that every activity has exactly one Accountable owner.
How it works
Each row is an activity and each column is a person or role. In every cell you assign one of R, A, C, or I. The core governance rule of RACI is that an activity must have exactly one Accountable owner — one and only one A per row — so ownership is never diluted or missing. The builder counts the A assignments per row and flags any activity that has zero or more than one. When you export, the matrix is emitted as tab-separated values so it drops cleanly into a spreadsheet, with activities down the side and people across the top.
What each role actually means
Understanding the practical difference between roles prevents common mistakes:
R — Responsible: Does the work. There can be multiple R assignments on one row when several people contribute. The key question: who is doing this?
A — Accountable: Owns the outcome and is answerable if it fails. There must be exactly one A per activity. The A may or may not also be an R. The key question: who signs off?
C — Consulted: Provides input before the work is done or a decision is made. Communication flows both ways — the Responsible person must seek and incorporate the Consulted person’s input. The key question: whose expertise is needed before we proceed?
I — Informed: Kept up to date after decisions or milestones. Communication flows one way — they receive information, they do not give it. The key question: who needs to know this happened?
Example RACI matrix
For a software release process with three roles (Engineer, QA Lead, Product Manager):
| Activity | Engineer | QA Lead | Product Manager |
|---|---|---|---|
| Write feature code | R | I | I |
| Write unit tests | R | C | I |
| Conduct QA testing | C | R | I |
| Approve release | I | C | A/R |
| Deploy to production | R | I | A |
Note that “Approve release” has the Product Manager as both A (accountable) and R (doing the approving). This is common for decision activities where the decision-maker and accountable owner are the same person.
Common RACI mistakes to avoid
Too many Consulted assignments: Every C on an activity is a gate — someone must seek that input before proceeding. A matrix with a C in every cell for a senior stakeholder effectively means that person is consulted on everything, creating a bottleneck. Limit C to cases where the input genuinely changes the output.
Confusing Consulted with Informed: Consulted requires a two-way conversation before action. Informed is a one-way notification after action. Misclassifying an Informed stakeholder as Consulted creates unnecessary delays.
Activities that are too broad: “Manage the project” is not a RACI-able activity. “Approve project plan”, “review weekly status report”, and “sign off deliverable” are. Verb-led, specific activities make role assignments obvious and auditable.
Multiple Accountable owners: If two people are both marked A, neither is truly accountable. When you cannot agree on a single A, that is a governance problem that needs to be resolved before the project starts.
In practice
- Paste the tab-separated export into a spreadsheet and colour-code by role (R = green, A = yellow, C = blue, I = grey) for instant visual scanning
- Review the matrix with the team before the project starts — disagreements about who owns what are far better surfaced in a planning meeting than mid-delivery
- Revisit and update the matrix when scope or team composition changes