RACI Matrix

RACI prevents the most common cause of project failure: nobody is sure who owns what. The framework forces explicit role assignment for each task, and it works only if every task has exactly one Accountable.

Origin

RACI emerged from the project management discipline in the 1950s-60s, formalized in IBM's project management handbooks and later adopted by management consultancies. The acronym is not attributable to a single inventor; the structure has been refined into many variants (RASCI, RACIO, DACI) that adjust the role labels for specific contexts.

RACI Matrix Table showing tasks down the left and roles across the top, with R, A, C, I assignments in cells. Task PM Eng Design Sales Legal Spec A,R C C I I Build I A,R R I Pricing C I A,R C Contract I R A,R
Each task has exactly one Accountable and any number of Responsible, Consulted, or Informed roles.

The four roles

When RACI is the right tool

RACI is the right tool for: cross-functional projects where ownership has been ambiguous; recurring processes where role drift has crept in; new initiatives where decision rights need to be agreed up front; and audits or compliance work where role clarity is required. It's a poor fit for: small teams of fewer than 8 people (the overhead exceeds the value); creative work where the structure inhibits collaboration; or fast-moving operational decisions where the matrix becomes obsolete faster than it can be updated.

How to build a RACI

  1. List tasks vertically. Be specific — "design the form" rather than "design." Granular enough that one person can plausibly own each.
  2. List roles horizontally. Use roles, not names — RACIs by name go stale every time someone changes jobs.
  3. Assign A first. Each task needs one Accountable. If you can't decide between two people, the matrix has surfaced a real problem; resolve it before continuing.
  4. Assign R. Often the Accountable is also Responsible (denoted A,R). Sometimes the Accountable delegates the work to one or more Responsibles.
  5. Assign C and I sparingly. Every consultation costs time; every "informed" notification adds noise. Add only where genuinely needed.
  6. Validate with the people on the matrix. A RACI built in private will be ignored. Walk through it with the team; expect changes.
  7. Revisit when reality changes. RACIs go stale. Review at major project milestones or when team composition changes.

Worked example: a SaaS company launching pricing changes

A 200-person SaaS company is changing its pricing model — moving from per-seat to usage-based for the SMB tier. The change touches product, marketing, sales, finance, customer success, and legal. The RACI:

TaskCFOHead of ProductHead of MarketingHead of SalesLegal
Pricing model designA,RRCRI
Customer impact analysisRRIA,RI
Product changes (metering)IA,RII
Customer communicationCCA,RRC
Legal review (contracts)IIIIA,R
Sales team trainingICIA,R

The matrix surfaces immediate decisions: the CFO is Accountable for pricing model design (not the Head of Product, despite their build role) — a deliberate choice to anchor the decision in financial modeling. Sales is Accountable for customer impact analysis because they own the customer conversations; this prevents marketing from owning a number it can't influence.

How RACI goes wrong

Critique

RACI is procedurally rigid in a way that doesn't always match how knowledge work happens — informal channels often produce better outcomes than the matrix predicts, and over-formalization slows decisions. Variants like DACI (Driver, Approver, Contributor, Informed) better fit cross-functional decisions. The choice of variant matters less than the discipline of explicit role assignment, which is what makes RACI useful at all.