Agile Certifications, AI and PM, PDUs
RACI Matrix: A Comprehensive Guide
Aug
RACI matrix: defining decision rights and accountability on projects
A RACI matrix is a responsibility assignment matrix that maps every task or decision to the people involved, using four roles: Responsible, Accountable, Consulted and Informed. This guide covers the role definitions, the rules that make a RACI chart valid, a worked example, and the failure patterns seen most often in practice.
What is a RACI matrix?
A RACI matrix (also called a RACI chart) is a grid with tasks, deliverables or decisions in the rows and roles in the columns. Each cell records how a role participates in that item. Its purpose is to remove ambiguity about who executes the work, who owns the outcome, whose input is required, and who must be kept aware.
In the PMBOK® Guide, the RACI chart is presented as one form of responsibility assignment matrix (RAM), typically built against the work breakdown structure or a process map.
The four roles
| Role | Definition | Rule per task | Communication |
|---|---|---|---|
| R – Responsible | Performs the work to complete the task | At least one | Executes; reports to A |
| A – Accountable | Owns the outcome; approves or signs off; has final decision authority | Exactly one | Delegates to R; answerable upward |
| C – Consulted | Subject-matter expert whose input is required before the work or decision is completed | As few as needed | Two-way, before the fact |
| I – Informed | Kept up to date on progress or outcomes; no input into the work | As few as needed | One-way, after the fact |
Core rule: every row has exactly one A and at least one R. The same person may hold both, recorded as “A/R”.
Why use a RACI matrix?
Most delivery friction comes from unclear ownership rather than lack of capability. A RACI matrix makes ownership explicit and reviewable.
- Clear roles: removes ambiguity about who does what, preventing both duplication and gaps.
- Decision rights: a single Accountable owner per item shortens approval cycles and escalation paths.
- Targeted communication: distinguishes who must be consulted before a decision from who is informed after it.
- Reduced conflict: expectations agreed up front replace assumptions that surface later as disputes.
- Resource visibility: a column dense with Rs and As exposes overload and single points of failure.
- Governance and control: ties every deliverable to an owner, supporting planning, monitoring and audit.
- Onboarding: new team members and stakeholders see the operating model on one page.
How to create a RACI matrix
- List tasks, deliverables and decisions. Derive them from the WBS or process map. Phrase each as a specific, verifiable item (for example “Approve design mockups”, not “Design”).
- List the roles. Use roles or functions rather than individual names, so the matrix survives staffing changes.
- Assign R, A, C and I. Start with the A for each row, then the R, then add C and I only where there is a clear need.
- Validate the matrix. Apply the row and column checks below.
- Review and baseline. Walk through the draft with the named stakeholders, resolve disputes, then publish it alongside the project management plan.
- Maintain it. Re-check at phase gates and whenever scope, organisation or processes change.
Validation checks
| Check | What it signals | Action |
|---|---|---|
| Row has no A | No owner; decisions will stall | Assign exactly one A |
| Row has two or more As | Diffused ownership | Escalate until one owner is agreed |
| Row has no R | Nobody is doing the work | Assign at least one R |
| Row has many Cs | Slow decisions, consensus drag | Keep only essential input |
| Column has many As and Rs | Overloaded role, bottleneck | Rebalance or delegate |
| Column has no letters | Role may not belong on this matrix | Remove or confirm scope |
RACI matrix example: website redesign
The matrix below applies the rules above: one A and at least one R on every row.
| Task | Project Manager | Designer | Developer | Content Writer | Marketing Manager |
|---|---|---|---|---|---|
| Define project scope | A/R | C | C | C | C |
| Design website mockups | A | R | C | C | I |
| Develop website | A | C | R | I | I |
| Write website content | C | C | I | R | A |
| Launch website | A | I | R | I | R |
| Website maintenance | A | C | R | I | I |
Key: R = Responsible · A = Accountable · C = Consulted · I = Informed
Reading the matrix
- Accountability can sit outside the project manager. Marketing owns content because it answers for the brand message.
- Multiple Rs are valid. At launch, the Developer deploys the site while Marketing runs the announcement, but only the Project Manager is accountable for the launch.
- Column check: the Project Manager holds five As, which is typical for a small project but would signal overload on a larger programme.
Best practices
- Keep it proportionate: map the deliverables and decisions where ambiguity is likely, not every routine activity.
- Build it with the people in it: agreement is the purpose of the exercise; a matrix drafted alone will be contested.
- One Accountable owner per item: enforce this without exception.
- Keep C and I lean: every extra C adds delay; every extra I adds noise.
- Make it visible: store it with the project management plan and reference it at kick-off.
- Review at phase gates: update it when scope, people or processes change.
- Use it selectively: reserve it for cross-functional work where roles are genuinely unclear.
Common mistakes to avoid
| Mistake | Consequence | Correction |
|---|---|---|
| More than one Accountable | Confused ownership; no final decision | One A per row |
| A with no R | Work is owned but not done | Assign at least one R |
| Treating R and A as the same | Doers are blamed for decisions they cannot make | Separate execution from ownership |
| Ignoring C | Poor decisions and rework | Consult genuine experts before the decision |
| Over-informing | Information overload, lower efficiency | Inform only those who act on the update |
| Building it in isolation | Inaccuracies and resistance | Review with stakeholders before baselining |
| One-time exercise | Matrix becomes obsolete | Review at phase gates and after changes |
RACI variants
| Model | Additional role | Typical use |
|---|---|---|
| RASCI | S = Support: assists the Responsible role | Large tasks with supporting contributors |
| RACI-VS | V = Verifier, S = Signatory | Regulated or quality-controlled work needing formal verification and sign-off |
| CAIRO | O = Out of the loop | Making explicit who is deliberately excluded |
Frequently asked questions
Responsible, Accountable, Consulted and Informed: the four ways a role can participate in a task or decision.
Responsible performs the work. Accountable owns the outcome, approves it and has final decision authority. One person can hold both, recorded as “A/R”.
No. Each task or decision has exactly one Accountable owner. Multiple owners diffuse accountability and stall decisions.
Yes. Several roles can share the work, provided one role remains Accountable for the result.
Consulted roles provide input before the work or decision is completed (two-way). Informed roles receive updates afterwards (one-way).
A RACI matrix is the most common type of responsibility assignment matrix (RAM). A RAM is any grid linking work to people; RACI uses the four RACI roles.
On cross-functional projects, process changes and governance structures where several teams share responsibility and ownership is not obvious.
Summary
A RACI matrix converts implicit assumptions about ownership into an explicit, reviewable agreement. Apply the core rule of one Accountable owner and at least one Responsible role per item, keep Consulted and Informed lean, build the matrix with the people named in it, and maintain it through the project lifecycle.