RASCI / RASIC: Naming the Hands-On Helpers

Summary

RASCI adds one role to RACI: Support, for people who contribute real effort and resources to a task without owning its delivery. The addition makes invisible work visible, and reading down a Support column across a portfolio shows how loaded a shared function such as IT actually is. Choose it when tasks genuinely need several pairs of hands, when a shared function supports many efforts, or when contribution deserves explicit credit. Stay with plain RACI when support work is rare enough to absorb into Responsible. RASIC is the same matrix with the letters reordered.

The letters

RASCI keeps all four RACI roles and inserts one more: Support.

RASIC is the same matrix with the letters reordered (Responsible, Accountable, Support, Inform, Consult). The two names are interchangeable. The whole point of the addition is the sharp line between S and C: Support has skin in the game and stays involved until the task is done, whereas Consulted offers a view and steps back.

Origin and history

RASCI is not a separate invention so much as the most natural extension of RACI, and it arose from a genuine limitation of the base matrix. In plain RACI, a person who does real hands-on work but is not the primary owner has nowhere obvious to sit: they get folded into Responsible, which inflates the R count, or into Consulted, which understates their contribution.

The Support role has been documented and popularized in serious project and engineering-management literature. It appears prominently in The Art of Scalability by Marty Abbott and Michael Fisher, both former eBay executives, who describe how product-development teams use the Support code to keep track of shared functions. eBay itself is cited as a long-standing user. As with RACI, there is no single named inventor of the S addition; it is a practitioner convention that stabilized because it solved a recurring problem, particularly in IT and operations delivery where a task genuinely needs several pairs of hands.

What problem it solves

RASCI exists to make invisible work visible. When one function, IT being the classic example, is pulled in to support many different initiatives, plain RACI hides that load inside other people’s Responsible cells. By naming Support explicitly, RASCI lets you do something RACI cannot: read down a Support column across a whole portfolio and see how tapped out a shared function is. That turns the matrix from a single-project organizer into a capacity-planning instrument.

At the level of a single task, the benefit is subtler but still real. Support answers the question “who will actually help me get this done”, which is different from “whose opinion do I need” (Consulted) and different again from “who owns it” (Accountable). Distinguishing help from advice prevents the quiet resentment that builds when someone who did substantial work is recorded only as a bystander.

When to choose it, and when not

Choose RASCI when work genuinely depends on hands-on assistance rather than opinion, when a shared function supports many efforts and you need to see its total load, or when cross-functional collaboration means several people contribute effort to one owner’s deliverable. It is the standard upgrade for IT and operations delivery, marketing campaigns, product launches, and annual reporting cycles.

Stay with plain RACI when the tasks rarely involve collaboration and support functions are naturally absorbed into the Responsible role. Adding S to a simple project just creates a column that is always empty or always duplicative.

Look elsewhere when the friction is not about who helps but about who decides (use a decision-rights framework) or about formal control gates (use RACI-VS or PACSI).

Common pitfalls

• Support collapsing into a second Responsible. The most common failure. If S and R are indistinguishable in practice, the matrix gives you nothing. Define S precisely at kickoff: Support means “you do specific tasks on request”, Responsible means “you own delivery”.
• Using Support to dodge accountability. A crowd of Supporters can dilute the sense that one Responsible party still owns the work.
• Over-listing. Not every helper needs an S. Reserve it for people whose contribution is material enough that its absence would stall the task.
• Forgetting the portfolio view. The unique value of RASCI is the vertical read across many tasks. If you only ever read rows, you may as well use RACI.

Worked example

Introducing a new supplier onboarding process in an operations team.

Reading the “Build the process” row: the Ops Analyst does the work (R), the Head of Operations owns it (A), Procurement and IT actively help by providing supplier data and system setup (S), and Finance and Legal are consulted before sign-off because their input shapes the design (C). The “I thought you had it” risk is gone, and the distinct S entries make clear that Procurement and IT are on the hook for real effort, not just a view.

Where it sits in the family

RASCI is the first and most common step up from RACI, adding one role to solve the single most frequent complaint about the baseline. It is the parent of a further extension, DRASCI, which adds a Driver on top of Support for cross-team coordination. Its close cousin RASI takes the opposite path, replacing Consulted with Support and dropping the advisory role, which suits work that needs helpers but never needs outside opinions. If RACI is the default, RASCI is the default’s default upgrade: the one to reach for first when the base matrix feels too coarse.

Sources

Web sources

• RASCI Matrix in Project Management, EPAM SolutionsHub: https://solutionshub.epam.com/blog/post/rasci-matrix
• ARCI, DACI, RASCI, RACI and The Art of Scalability, RACI Solutions: https://www.racisolutions.com/blog/bid/46600/arci-daci-rasci-raci-and-the-art-of-scalability
• RASCI Framework, Mutomorro: https://mutomorro.com/tools/rasci-framework
• Responsibility assignment matrix, Wikipedia: https://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Academic sources

• Cabanillas, C., Resinas, M. and Ruiz-Cortés, A. (2011) ‘Mixing RASCI matrices and BPMN together for responsibility management’, in Proceedings of the VII Jornadas en Ciencia e Ingeniería de Servicios (JCIS 2011), pp. 167-180. The main peer-reviewed treatment of RASCI specifically, formalizing the matrix and wiring it into business process models.
• Cabanillas, C., Resinas, M. and Ruiz-Cortés, A. (2012) ‘Automated resource assignment in BPMN models using RACI matrices’, in On the Move to Meaningful Internet Systems: OTM 2012, Lecture Notes in Computer Science 7565. Berlin: Springer. https://doi.org/10.1007/978-3-642-33606-5_5
• McCann, J.E. and Gilmore, T.N. (1983) ‘Diagnosing organizational decision making through responsibility charting’, Sloan Management Review, 24(2), pp. 3-15. Family-level foundation for the charting technique RASCI extends.
• Abbott, M.L. and Fisher, M.T. (2009) The Art of Scalability. Boston, MA: Addison-Wesley. The engineering-management book that documents the Support role in production use at eBay-scale organizations.