RASCI Responsibility Matrix: When the S Earns Its Place

Most RASCI matrices in circulation are RACI matrices wearing a fifth column nobody fills in correctly. Teams add the S for Supportive because a template included it, then use it as a dumping ground for anyone who seems vaguely involved. The S row earns its place only when it marks something specific: a person doing real effort on a task without owning its outcome and without being a named Consulted expert. If nothing in the workstream needs that distinction, plain RACI is the better, simpler tool.

The direct answer: A RASCI responsibility matrix is a RACI matrix (Responsible, Accountable, Consulted, Informed) with a fifth role, Supportive, inserted between Responsible and Consulted. Supportive marks a person contributing real effort or resources to a task without owning the outcome or being formally consulted for expertise. Use RASCI only when a workstream has people in that specific position; otherwise the extra column adds noise, not clarity.

What the S Actually Adds to RACI

RACI answers four questions for every task or decision: who does the work (Responsible), who owns the outcome and answers for it (Accountable), whose input is required before acting (Consulted), and who needs to know after the fact (Informed). Most workstreams map cleanly onto those four roles.

RASCI exists for the workstreams that don't. Some tasks have a person who isn't the primary doer and isn't a subject-matter expert being consulted, but who genuinely contributes hours: a junior developer pairing with a senior one, a business analyst pulling data for a PM who owns the analysis, a specialist lending capacity for two days without taking the task. That person is neither Responsible nor Consulted in the strict RACI sense. RASCI gives them a home: Supportive.

The test for whether the S row is earning its place is simple. Ask whether the person did work hours on the task, not whether they had an opinion about it. If the answer is "they gave input," they're Consulted. If the answer is "they helped get it done," they're Supportive. Confusing the two is what turns RASCI into RACI with decoration.

A Filled RASCI Matrix for One Workstream

Here's a RASCI matrix for a single workstream, migrating a client's custom fields during a PM-tool migration, filled out the way it should look when every letter means something specific.

Task	R	A	S	C	I
Map custom fields to new schema	Migration lead	PMO director	Data analyst (pulls source values)	Client PM (confirms field meanings)	Client sponsor
Build field-mapping test set	Migration lead	PMO director	QA engineer (builds test cases)	-	Client PM
Run migration dry run	Migration lead	PMO director	-	Security lead (data handling)	Client sponsor, Client PM
Validate migrated data	Data analyst	PMO director	Migration lead (spot-checks)	Client PM (signs off on samples)	Client sponsor
Cut over to production	Migration lead	PMO director	-	Client PM (go/no-go input)	Client sponsor, Security lead

Notice what's absent as much as what's present. Not every row has an S; the "run migration dry run" and "cut over" rows have no Supportive person because nobody is contributing effort there beyond the Responsible party. Not every row has a C either. A RASCI matrix where every row is fully populated across all five letters isn't more thorough, it's a sign nobody thought about which roles actually apply to which task.

The diagram below shows how the five RASCI roles map against the four RACI roles, and where the Supportive role sits in the sequence.

When RASCI Beats Plain RACI, and When It Doesn't

RASCI earns the extra column when a workstream has a recurring pattern of people contributing hours without owning tasks or being formally consulted, typically team structures with pairing, mentoring, or shared specialist capacity. Engineering teams that pair junior and senior staff, PMOs that loan analysts across workstreams, and creative teams where a second contributor drafts alongside the lead all tend to have real Supportive rows, not decorative ones.

Plain RACI is the better tool when a workstream is small enough that everyone touching a task is either doing it or accountable for it. A five-person project team where each task has one clear owner doesn't need a fifth column; adding one just gives people a place to list themselves without adding information. The RASCI vs RACI vs DACI comparison covers the broader decision, including when DACI's decision-focused roles fit better than either.

According to Wikipedia's overview of responsibility assignment matrices, RASCI (also written RACIS or RASIC) is one of several documented RACI variants built to capture roles the base model doesn't distinguish, which is a useful reminder that the extra letter is meant to solve a specific gap, not to become the new default.

Three Failure Patterns That Break a RASCI Matrix

Two Accountables on one row. The single most common failure in any RACI-family matrix. When a PM and a technical lead are both marked Accountable for the same task, neither actually owns it; each assumes the other is tracking it, and the gap surfaces during an incident review, not before. Fix it by splitting the row: if two people genuinely own different aspects of an outcome, they own different rows, each with one Accountable.

Missing Support that should exist. The opposite failure: someone is clearly logging real hours on a task, but the matrix has no S row for them, so their time is invisible to capacity planning. This usually happens when a RACI template gets copied without revisiting it once real staffing patterns show up. If someone appears in the resource heatmap against a task where they hold no formal role, that's the sign to add them as Supportive.

Consulted inflation. Marking every stakeholder with a passing interest as Consulted instead of Informed. A row with six Consulted names isn't more collaborative, it's a bottleneck: nobody can act until six people weigh in, and most never get asked before the Responsible party moves ahead anyway. The test is whether the task genuinely cannot proceed without that person's input beforehand. If it can, they're Informed, not Consulted.

Building a RASCI Matrix That Survives a Real Project

1. Start from a real work breakdown. A RASCI row only makes sense against an actual task, not a vague phase name. Build or confirm the work breakdown structure first, then assign roles against its lowest-level work packages.
2. Assign Accountable first, one name only. Every other role gets easier to assign once a single owner is locked in for each row.
3. Add Supportive only where real effort exists. Ask "did this person log hours" before adding an S. If the honest answer is "they have an opinion," that's a C, not an S.
4. Cap Consulted at the people whose input genuinely blocks progress. Everyone else who wants visibility becomes Informed.
5. Review the matrix at a milestone, not just at kickoff. Staffing and support patterns shift as a workstream progresses; a RASCI matrix set once at project start and never revisited drifts out of sync with who is actually doing the work.

A RASCI matrix built this way earns the extra column instead of just carrying it. The rest of the blog's PMO governance coverage covers the surrounding practice, from work breakdown structures to portfolio governance, that a responsibility matrix depends on to mean anything.