RACI Matrix Template Explained

Shawn West
May 18
5 min read

Updated: Jul 13

A RACI matrix is a table mapping each activity in a project to the people involved, marking each cell with one of four letters: R (Responsible), A (Accountable), C (Consulted), or I (Informed). It exists because the most common project failure mode is ambiguous ownership — the thing that didn't get done was on no one's plate, or on three people's, or someone thought it was someone else's.

This guide is the template, the rules, and the discipline.

The Four Letters

R — Responsible. The person who does the work. Hands-on. Often one person, sometimes a small team.

A — Accountable. The person ultimately answerable. Singular — always one person. The buck stops here.

C — Consulted. People whose input is needed. Two-way communication. Their opinion shapes the outcome.

I — Informed. People who need to know the result. One-way. They learn about it after.

The single most important rule: exactly one A per row. Two A's means no accountability.

The Template

| Activity | Person A | Person B | Person C | Person D | Person E |
|----------|----------|----------|----------|----------|----------|
| Activity 1 | A | R | C | I | I |
| Activity 2 | C | A,R | I | I | C |
| Activity 3 | I | A | R | C | I |

Rows are activities; columns are people or roles. Each cell shows that person's role for that activity.

Filling In the Matrix

Step 1: list the activities. Not deliverables — activities. The work that needs to happen.

For a typical engineering project:

Define requirements
Design technical approach
Build features
Review and approve
Test
Communicate to stakeholders
Deploy
Verify
Support post-launch

Step 2: list the people or roles. Use roles for ongoing processes; use names for specific projects.

Step 3: fill in the cells. For each activity, identify R, A, C, I.

The exercise takes 30-60 minutes for a typical project and surfaces ownership ambiguities that would otherwise emerge during execution.

Rules That Make It Useful

Exactly one A per row. Always.

R and A can be the same person. Often the doer is also the accountable. Mark "A,R" in that case.

Multiple R's are okay when several people share the work, but keep it small.

Be sparing with C. Each consultation costs time. Three is reasonable; ten is unworkable.

I is broadcast. People in the I column don't need individual handling; a status update reaches them.

A Worked Example

For a platform migration project:

| Activity | Eng Lead | PM | SRE | Security | Support | Sponsor | |---|---|---|---|---|---|---| | Define scope | A | R | C | C | I | I | | Design approach | A,R | C | C | C | I | I | | Build migration tools | A,R | I | C | I | I | I | | Security review | C | I | C | A,R | I | I | | Customer comm plan | C | A | I | C | R | I | | Execute migration | A | I | R | I | I | I | | Verify post-migration | A,R | C | C | I | C | I | | Go/no-go decision | C | C | C | C | I | A,R |

Each row has exactly one A. Different activities have different accountable owners — Eng Lead for technical work, PM for product work, Security for review, Sponsor for the final go/no-go decision.

The Conversation Is the Value

The artifact is a table. The value is the conversation that produces it.

Building the matrix surfaces:

Disagreements about who owns what
Activities that no one's accountable for
Activities with too many cooks
Stakeholders who want to be A but should be C

Each of these is a useful discovery that's better surfaced now than during execution.

Reviewing the Matrix

After drafting, review:

Does each row have exactly one A?
Does each A have realistic capacity for the accountabilities they carry?
Are C's actually going to be consulted, or politically named?
Are activities missing?
Are stakeholders missing?

This review catches most gaps. Without it, the matrix can be filled in defensively (everyone wants to be in everyone's column) and lose meaning.

Variants

RASCI: adds S (Supportive). Useful in larger orgs with explicit support roles.

RACI-VS: adds V (Verifier) and S (Signatory) for regulated environments.

DACI: Driver, Approver, Contributors, Informed. Better for decision-making than execution.

Default to plain RACI. Add letters only when there's a specific reason.

Anti-Patterns

The dead matrix. Filled out at kickoff, framed on a wiki, never referenced. Cite it during real decisions to keep it alive.

The political matrix. Roles assigned based on who'd be offended. Diluted; team ignores it.

The granular matrix. 200 activities, 30 people. Unreadable.

The single-A-shared. "Sam and Pat are both accountable." No, one of them is. Pick.

When to Use a RACI

Worth the effort for:

Cross-functional projects
Multi-month initiatives
Repeated processes where ownership keeps getting confused
Compliance-sensitive work

Skip for:

Within-team work with clear ownership
Routine operational work
Anything where the team already has working agreements

Keeping It Visible

A buried matrix doesn't shape behavior. Keep it accessible:

Pinned in the project channel
Linked from project documentation
Referenced in status updates
Walked through at kickoff and revisited at milestones

The signal of a healthy matrix: people on the project can answer "who's accountable for X" without looking it up. They internalized it during the conversation that built it.

Lightweight Alternative

For smaller projects, a full RACI is overkill. The lightweight version: a list of activities and a single owner per activity.

- Define scope: Sam (Eng Lead)
- Design technical approach: Sam (Eng Lead)
- Build migration tools: Pat
- Security review: Riley (Security)
- Communicate to customers: Jordan (PM)
- Execute migration: Sam
- Go/no-go decision: VP Product

Same effect, less ceremony. Reach for full RACI when the project actually needs the C and I clarity; use the lightweight version otherwise.

Key Takeaway

A RACI matrix maps activities to people with four roles: Responsible, Accountable, Consulted, Informed. Exactly one Accountable per activity. The artifact is a table; the real value is the conversation that produces it. Build for cross-functional projects, multi-month efforts, and repeated processes with ownership confusion. Skip for routine within-team work. Keep it visible; cite it in real decisions; update when roles change. The most common failure is treating it as a one-time kickoff artifact rather than a living agreement.

ShiftQuality