The Project Manager’s RASCI Matrix: Clarify Responsibility Before Work Begins

By the Diagramium team · 2026-08-12 · 11 min read

RASCI fails as a spreadsheet for one reason: a grid of letters does not show when anything happens. Drawn as a swimlane — one lane per role, tasks in sequence, approvals as explicit gates — the same information becomes something a team will actually read, argue with, and agree to before work starts.

Live interactive diagramUse the player controls to follow the steps

Project RASCI, initiation to closePlaying silently in this guideWatch with narration Open in editor

This compact player stays quiet while you read. Open the full presentation when you want narration and the complete walkthrough.

Why the matrix exists

RASCI answers a question that surfaces late and expensively: who decides? The five letters are Responsible (does the work), Accountable (owns the outcome, and there is exactly one), Support (helps do it), Consulted (opinion is sought before), Informed (told after). The variant without Support is RACI; the distinction only matters if you genuinely have helpers who are not owners.

The letter that causes trouble is A. Two Accountables means nobody is accountable, and that is the failure a RASCI is usually commissioned to fix.

What a good RASCI contains

Exactly one Accountable per task. If you cannot pick one, the task is really two tasks.
Tasks at decision granularity. “Deliver the project” is unassignable. “Approve the migration window” is.
Consulted separated from Informed. Consulted happens before and can change the outcome; Informed happens after and cannot. Blurring them is how review meetings get gate-crashed.
Sequence, not just assignment. This is what the spreadsheet cannot show and the swimlane can: which approval blocks which work.
An end state. Every task chain terminates in a decision, a deliverable or a handover.

Reusable RASCI templates

Three ready-made RASCI matrices plus the ownership diagrams that usually sit beside them. Open any of them, rename the lanes to your roles, and delete the tasks that do not apply.

SwimlaneProject RASCI, initiation to closeInitiation to close, with a lane per role — the general-purpose starting point.View example Use template
SwimlaneLaunch RASCI: who signs off before we shipLaunch sign-off: who must approve before shipping, and in what order.View example Use template
SwimlaneWho decides what on an agile team (RASCI)Decision rights on an agile team, where Accountable is the contested letter.View example Use template
SwimlaneOn-call escalation pathOwnership under time pressure — the same idea applied to an incident.View example Use template
SwimlaneHow a workplace grievance escalatesA process where an unowned step is a legal risk, not just a delay.View example Use template
SwimlaneHow a promotion is calibrated and approvedConsulted versus Accountable, drawn where the distinction actually bites.View example Use template
SwimlaneCustomer-service escalationSupport tiers with explicit handback paths.View example Use template
SwimlaneDesign-to-development handoffThe handoff RASCI is usually written to fix.View example Use template
SwimlaneQuote-to-cash processSales, finance and delivery sharing one revenue process.View example Use template
SwimlaneThe external financial auditExternal parties in the matrix — a lane you do not control.View example Use template

Building yours in Diagramium

Open the closest RASCI template above rather than starting from a blank swimlane. The lane structure is the part that takes longest to get right.
Rename lanes to your roles. Sponsor, project manager, delivery lead, QA, operations, and any external party.
List tasks down the flow in the order they happen, each in its Responsible lane.
Draw approvals as gates. An arrow into the Accountable lane and back out is what makes a blocking sign-off visible.
Use step notes for the Consulted and Informed lists. They clutter a canvas but matter in the record, and notes travel with the document.
Press Present in the kickoff. Revealing one task at a time forces the room to confirm each owner rather than nodding at a wall of letters. Disagreements surface in the meeting, which is the only cheap place to have them.
Export to PNG for the charter, and keep the project file as the version you edit when scope moves.

Design recommendations

Keep the Accountable lane adjacent to the Responsible lanes it governs — long approval arrows across the diagram read as bureaucracy because they are.
Colour approvals, nothing else. One accent on the gates makes the decision path readable at a glance.
Do not letter every cell. Draw R and A; note C and I. A diagram trying to be a spreadsheet loses to the spreadsheet.
Revisit at each phase boundary. Ownership legitimately changes between build and run; a RASCI that never changes is one nobody is using.

Common mistakes

Two Accountables. The single most common defect, and the one that guarantees the diagram will not settle the argument it was drawn for.
Everyone Consulted. If eight roles must be consulted on a task, nothing will ship. Consulted is a cost.
Tasks too coarse to assign. A verb without an object cannot have an owner.
Producing it after work starts. A RASCI written mid-project documents the confusion instead of preventing it.
Never showing it to the people in it. An unreviewed matrix is the project manager's opinion of who is accountable.

The checklist

Run this before you share it.

Exactly one Accountable per task, checked line by line.
Consulted and Informed are distinguished, not merged.
Every task is specific enough to have a single owner.
Approvals appear as gates in sequence, not as letters.
External parties appear if they can block you.
Each named role has seen and agreed to their lane.
It is dated, and there is a point in the plan to revisit it.
The editable original is stored where the next PM will find it.

Ready to build one? Open the Swimlane editor on a blank canvas, or start from one of the templates above — they are all editable.Open the Swimlane editor Browse all templates