RACI Matrix

Origin & evolution

The RACI matrix belongs to a broader family of responsibility-charting tools that emerged in mid-twentieth-century management practice. Linear responsibility charts, which mapped tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference → against roles in matrix form, appeared in project-management literature and practice well before RACI acquired its current name. No single inventor is credited with the RACI formulation specifically: it grew from common usage across management consulting, project-management bodies, and large organisations trying to coordinate work across departments and functions.

The four letters became standard through their adoption in programme-management frameworks and textbooks through the 1980s and 1990s. The Project Management Institute includes responsibility assignment matrices, of which RACI is the most widely recognised variant🆎VariantGrowthA variant in an A/B testView reference →, in PMBOK guidance. Variants such as RASCI (with an added Supporting role), CAIRO (adding Omitted), and DACI (Driver, Approver, Contributor, Informed) have emerged for teams who find the base model too coarse, but RACI remains the default starting point in most organisations.

How it works in practice

Build the matrix by listing key activities down the rows and roles or individuals across the columns. For each intersection, assign one or more of the four letters:

• R (Responsible): does the work. There should be at least one R per row.
• A (Accountable): owns the result and has final sign-off authority. There should be exactly one A per row. The Accountable person is answerable if the activity is not completed to standard.
• C (Consulted): provides input before the activity or decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → is complete. Communication is two-way.
• I (Informed): receives an update after the activity or decision. Communication is one-way.

A concrete example. A product team releasing a new billing feature⭐FeatureProduct SpecificationA product capability or featureView reference → might list the following activities: write the requirements, review the legal terms, implement the feature, write QA test cases🌵Test CaseQuality AssuranceAn individual test caseView reference →, approve the release🚢ReleaseProduct SpecificationA shipped version of the productView reference →, and notify account managers. Against those rows, roles like Product Manager, Legal, Engineering, QA, and VP of Product each receive their letters. Engineering is R for implementation; VP of Product is A. Legal is C on both requirements and terms review; account managers are I on the release notification. The completed grid makes it immediately obvious if two people share an A on a single row (a common source of stalled decisions) or if a row has no A at all (a common source of dropped work).

When to use it (and when not)

RACI works well when a project or process involves multiple teams or departments, when the same type of work has been mishandled before because ownership was assumed but not stated, and during onboarding or restructures when relationships between roles are new. Kicking off a cross-functional initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference → without a RACI is a reliable way to arrive at delivery with an unresolved disagreement about who had the final call.

The matrix earns its keep less well for small co-located teams where everyone knows their remit: adding RACI overhead in that context produces a document nobody reads. It can also produce false confidence when the rows represent activities at the wrong level of granularity. Too coarse and a single row hides several genuine ownership questions; too fine and the matrix becomes too large to maintain. A common failure mode is assigning C or I too broadly so that everyone appears on every row: that re-creates the confusion the matrix was meant to solve. The goal is a lean grid where each entry carries real meaning.

In the Unified Product Graph

The RACI matrix is a matrix framework in the team process category. Its rows and columns map onto two entity types in the Unified Product Graph:

• Each activity row becomes a key_activity🛠️Key ActivityBusiness ModelA key activity the business performsView reference → entity: a distinct piece of work or decision that needs ownership assigned.
• Each role column, whether Responsible, Accountable, Consulted, or Informed, becomes a role🪪RoleTeam & OrganisationA role within a teamView reference → entity: a named function or position within the team or organisation.

The matrix itself is the cross-product of these two types. In the Unified Product Graph the assignment (which role plays which RACI letter for which activity) lives as a relationship between a role🪪RoleTeam & OrganisationA role within a teamView reference → node and a key_activity🛠️Key ActivityBusiness ModelA key activity the business performsView reference → node. This means the same role🪪RoleTeam & OrganisationA role within a teamView reference → entity can be linked to multiple activities, and the same key_activity🛠️Key ActivityBusiness ModelA key activity the business performsView reference → can carry links to multiple roles with different assignment types, reproducing the full RACI grid without duplicating the underlying nodes.