top of page

Building a RACI Matrix for Change Initiatives

Shawn West
Jul 16
6 min read

Updated: 2 days ago

The customer notification never went out. Not because anyone refused — because it lived on no one's plate, or on three people's, and each of them assumed another had it. That is the exact failure a RACI matrix exists to prevent. It maps every activity in a change to the people involved and marks each cell R (Responsible), A (Accountable), C (Consulted), or I (Informed). The artifact is a table. The value is the argument it forces — about who actually owns what — before the work starts instead of after it slips.


Twenty minutes of that argument at kickoff buys you out of a three-week slip later. That is a trade I'll take every time on a cross-functional change.


This guide is how to actually build one that works, instead of one that becomes a wall decoration.


The Working Template


Copy this grid, swap in your own activities and roles, and fill each cell with R, A, C, or I. One rule the whole thing hinges on: exactly one A per row. A cell can carry two letters when the same person both owns the outcome and does the work (A,R).


RACI MATRIX — <project name>

Legend:
  R = Responsible   does the work — hands on the keyboard
  A = Accountable   answerable for the outcome — exactly one per row
  C = Consulted     two-way input, given before the work is done
  I = Informed      told the result afterward; no input

Activity                     | Role 1 | Role 2 | Role 3 | Role 4 |
-----------------------------|--------|--------|--------|--------|
Define requirements          |        |        |        |        |
Design technical approach    |        |        |        |        |
Build the change             |        |        |        |        |
Review and approve           |        |        |        |        |
Test the change              |        |        |        |        |
Communicate to stakeholders  |        |        |        |        |
Execute the deployment       |        |        |        |        |
Verify success               |        |        |        |        |

Before you circulate it, read straight down every row and confirm there is one A and only one A. A row with none is an activity that will quietly not happen. A row with two is an activity no one is actually on the hook for.


The Four Letters


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


A — Accountable. The person who's ultimately on the hook. The one who'd be asked "why did this fail?" Always one person, never a team. The buck stops here.


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


I — Informed. People who need to know the result, but don't shape it. One-way communication. They learn about it after.


The single most important rule: exactly one A per row. If two people are accountable, no one is.


When to Build a RACI


RACI is worth the time for:


  • Cross-functional initiatives where ownership crosses team boundaries

  • Multi-month projects with many parallel workstreams

  • Compliance-sensitive changes where audit needs documented accountability

  • Repeated processes where the team keeps getting confused about ownership


It's overkill for:


  • Single-team changes with one obvious owner

  • Routine operational work

  • Anything where the team already has clear, working agreements


The signal that you need one: people keep asking "who decides this?" or "whose job is X?"


Building the Matrix


Step 1: list the activities. Not the deliverables, the activities — the actual work that needs to happen. For a typical change initiative, this might include:


  • Define requirements

  • Design the technical approach

  • Build the change

  • Review and approve

  • Test the change

  • Communicate to stakeholders

  • Execute the deployment

  • Verify success

  • Maintain the changed system


Don't go too granular. 8-15 activities is a working number. If you have 50, you've decomposed too far.


Step 2: list the people or roles. Use roles, not names, if turnover is likely. "Senior backend engineer" rather than "Sam." If the matrix is for a specific project with known participants, names are fine.


Step 3: fill in the cells. For each activity, decide who is R, A, C, and I.


This is where the real work happens. Most teams discover, when they actually try to fill in the cells, that ownership is murkier than they thought.


Common Mistakes


Multiple A's. Two people accountable means no accountability. Pick one.


No A. Someone has to own it. If no one does, the activity won't happen on time.


R without A. Possible (R and A can be the same person), but should be deliberate. The doer should know who'd be asked if the work fails.


Too many C's. "Consulted" is expensive. Each consultee has to be brought in, listened to, responded to. Three is reasonable; ten means the activity will drag.


Confusing C and I. If you're going to act on someone's input, they're C. If you're just notifying them, they're I. The difference matters because C implies a real conversation.


Treating it as static. A RACI built at kickoff that's never revisited goes stale. Roles change. Update it.


A Worked Example


Here's a RACI for a typical platform migration project:


Activity

Eng Lead

Product Owner

SRE

Security

Support

Exec Sponsor

Define migration scope

A

R

C

C

I

I

Design technical approach

A,R

C

C

C

I

I

Build migration tooling

A,R

I

C

I

I

I

Security review

C

I

C

A,R

I

I

Communication plan

C

A

I

C

R

I

Customer notification

I

A

I

I

R

I

Execute migration

A

I

R

I

I

I

Post-migration verification

A,R

C

C

I

C

I

Status reporting to leadership

A,R

C

I

I

I

I

Final go/no-go decision

C

C

C

C

I

A,R


Notice: the Engineering Lead is accountable for most technical activities, the Product Owner for product-side activities, and the Exec Sponsor for the final decision. Each activity has exactly one A.


The Conversation Is the Point


The most valuable part of building a RACI isn't the resulting table. It's the conversation that produces it.


In building the example above, the team would likely surface:


  • Disagreement about whether SRE or Engineering owns the actual migration execution

  • Discovery that no one was tracking customer notification

  • Realization that security wanted to be consulted on more than just the formal review

  • Agreement that the exec sponsor had veto on go/no-go, even though previous projects had been ambiguous about this


Each of these is a productive disagreement that's better surfaced now than during execution.


Reviewing the Matrix


After drafting, walk through it asking:


  1. Does each row have exactly one A?

  2. Does each person on the list have enough capacity for their R's and A's? (Spreading one person across many A's is a setup for failure.)

  3. Are the C's actually going to be consulted, or is the team just acknowledging them politically?

  4. Are there activities missing from the row list?

  5. Are there people who don't appear at all who should be involved?


This review takes 15-30 minutes and catches most of the gaps.


Variants Worth Knowing


A few variations on RACI exist for specific contexts.


RASCI adds S for "Supportive" — people who provide resources or assistance but don't do the work themselves. Useful in larger organizations.


RACI-VS adds V (Verifier) and S (Signatory) for regulated environments where verification and sign-off are formally separated.


DACI is similar but oriented toward decisions: Driver, Approver, Contributors, Informed. Used for decision-making rather than execution.


Pick the simplest variant that fits your context. If basic RACI works, don't add letters.


Anti-Patterns


The dead matrix. Filled out at kickoff, framed on a wiki page, never referenced. Fix: cite it explicitly during the project. "Per RACI, security is consulted on this — Pat, what's your input?"


The aspirational matrix. Shows who should own things in an ideal world, rather than who actually owns them. Useless for guiding actual behavior.


The political matrix. Roles assigned based on who'd be offended to be left out, not on who actually contributes. Diluted, and everyone ignores it.


The granular matrix. 200 rows, three people per cell. Unreadable. The team gives up.


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


Keep It Visible


The matrix lives in a place the team references regularly. Pinned in the project channel. Linked from the project README. Mentioned in status updates.


A buried matrix doesn't change behavior. A visible one becomes the de facto agreement, even when memories fade.


Key Takeaway


RACI maps activities to people with four roles: Responsible (does the work), Accountable (owns the outcome), Consulted (input shapes the work), Informed (knows the result). Exactly one Accountable per activity. The artifact is a table; the value is the conversation that builds it. Use RACI for cross-functional initiatives, multi-month projects, and any time the team keeps getting confused about ownership. Skip it when ownership is already clear. The most common failure is treating it as a one-time artifact rather than a living agreement — keep it visible, cite it in real decisions, and update it when roles change.



Part of the Engineering Leadership guide — ShiftQuality's complete map to leading engineers.

bottom of page