The RACI Matrix , an essential IT Governance tool, is a responsibility assignment chart that maps out every task, milestone or key decision involved in completing a project and assigns which roles are Responsible for each action item, which personnel are Accountable, and, where appropriate, who needs to be Consulted or Informed. The acronym RACI stands for the four roles that stakeholders might play in any project. A RACI matrix (aka RACI Chart) is the simplest, most effective means for defining and documenting project roles and responsibilities. Knowing exactly who is responsible, who is accountable, who needs to be consulted, and who must be kept informed at every step will significantly improve your chances of project success. First introduced in the 1950s, RACI was originally called the “Decision Rights Matrix” and is also known as “Responsibility Charting.”
- Responsible: This refers to those individuals responsible for performing the task and making sure the work is done. Naturally, for every task identified there needs to be at least one individual assigned as Responsible, who makes sure that the task is performed according to specifications and as required by the approver. Others may assist or lend support, but they work as resources allocated to those responsible and this arrangement keeps accountabilities in place.
- Accountable (or Approver): This identifies the individual that approves the completed activity. Since a review is required before an approval, this individual is accountable for making sure the activity is satisfactory and meets performance standards. This person could also be the one who delegates the work. There must be only one accountable person specified for each task.
- Consulted: This role describes those whose knowledge and expertise is important for the task to be completed effectively. Those consulted could be subject matter experts (SMEs) and there is a two-way communication between those responsible and those consulted. This role is a support role, helping through their expertise to enable the completion of tasks or deliverables.
- Informed: This role refers to those who should be kept up to date about the activities being performed, the progress made on them, or their completion. Sometimes the communication occurs only when the task is completed, but that should be agreed upon. It consists of one-way communications.
Creating a RACI Matrix
A RACI chart is a matrix of all project activities associated with the responsible people or roles. “All project activities” includes everything from the day you begin, such as planning, test, design, support, etc. Creating a RACI matrix involves the following steps:
- Decide how to chart the matrix — You can use any number of tools or templates, including a spreadsheet, whiteboard, or software solution.
- Identify the project tasks (or deliverables) — Meet with key stakeholders to develop a list of project tasks. For this discussion, “tasks” include activities such as meetings or events that must take place, as well as deliverables such as features or products. Tasks are labeled across the X or Y axis of the matrix. For example, if you are charting a software project developed under Agile, the Sprint Demo Meeting may be a required activity and should be included in the matrix as a task. Don’t forget to add maintenance of the RACI Matrix as a task. The project manager usually maintains the RACI Matrix.
- Identify the project roles — Project roles are labeled down the axis of the matrix that was not used for tasks. The project roles make the matrix more understandable and can be useful for adding data you may have forgotten. As you identify roles, you’ll remember tasks for those roles, so add them to the task axis. Also, the task axis is useful for identifying roles and clarifying resource allocation. This is a good time to assign names to roles as well - one name per role is optimal.
- Label the intersections of the axes — Where the X and Y axes intersect, label the intersection with an R, A, C, or I to finalize the matrix with who is Responsible, Accountable, Consulted, or Informed on each task.
When to use a RACI Matrix
A RACI chart serves just about every project well. But it’s especially helpful when tasks require multiple resources, run concurrently, or depend on other tasks. Here are a few scenarios when a RACI chart comes in handy:
- The decision-making or approval process could hold up the project.
- There’s conflict about task ownership or decision-making.
- The project workload feels like it’s not distributed evenly.
- You experience turnover on a team and need to onboard someone quickly to a new role.
Alternatives to and Variations of RACI
There are a number of alternatives to the RACI participation types:
- PARIS: This is an early version of a Responsibility Assignment Matrix, with the roles defined as:
- Review Required
- Input Required
- Sign-off Required
- PACSI: This is a version very useful to organizations where the output of activities under the accountability of a single person/function can be reviewed and vetoed by multiple stakeholders, due to the collaborative nature of the culture.
- Perform: The person/function carrying out the activity.
- Accountable: The person/function ultimately answerable for the correct and thorough completion of the deliverable or task, and often the one who delegates the work to the performer.
- Control: The person/function reviewing the result of the activity. He or she has a right of veto; his or her advice is binding.
- Suggest: The person/function consulted to give advice based upon recognized expertise. The advice is non-binding.
- Informed: The person/function who must be informed of the result of the activity.
- RASCI: This is an expanded version of the standard RACI, less frequently known as RASCI, breaking the responsible participation into:
- Responsible: Those responsible for the task, who ensure that it is done as per the approver
- Support: Resources allocated to responsible. Unlike consulted, who may provide input to the task, support helps complete the task.
- RASI: This is an alternative version of the standard RACI, foregoing the consulted participation and replacing it with:
- Support: Resources which play a supporting role in implementation.
- RACIQ: This is an expanded version of the standard RACI, with an additional participation type:
- Quality Review: Those who check whether the product meets the quality requirements.
- RACI-VS: This is an expanded version of the standard RACI, with two additional participation types:
- Verifier: Those who check whether the product meets the acceptance criteria set forth in the product description.
- Signatory: Those who approve the verify decision and authorize the product hand-off. It seems to make sense that the signatory should be the party being accountable for its success.
- CAIRO: This is an expanded version, of the standard RACI, also known as RACIO with one additional participation type.
- Out of the loop (or omitted): Designating individuals or groups who are specifically not part of the task. Specifying that a resource does not participate can be as beneficial to a task's completion as specifying those who do participate.
- DACI: Another version that has been used to centralize decision making, and clarify who can re-open discussions.
- Driver: A single driver of overall project like the person steering a car.
- Approver: One or more approvers who make most project decisions, and are responsible if it fails.
- Contributors: Are the worker-bees who are responsible for deliverables; and with whom there is two-way communication.
- Informed: Those who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.
- RAPID: Another tool used to clarify decision roles and thereby improve decision making, is RAPID, which was created by and is a registered trademark of Bain & Company.
- Recommend: The Recommend role typically involves 80 percent of the work in a decision. The recommender gathers relevant input and proposes a course of action—sometimes alternative courses, complete with pros and cons so that the decision maker's choices are as clear, simple and timely as possible.
- Agree: The Agree role represents a formal approval of a recommendation. The 'A' and the 'R' should work together to come to a mutually satisfactory proposal to bring forward to the Decider. But not all decisions will need an Agree role, as this is typically reserved for those situations where some form of regulatory or compliance sign-off is required.
- Perform: The Perform role defines who is accountable for executing or implementing the decision once it is made. Best-practice companies typically define P's and gather input from them early in the process
- Input: The Input role provides relevant information and facts so that the Recommender and Decider can assess all the relevant facts to make the right decision. However, the 'I' role is strictly advisory. Recommenders should consider all input, but they don't have to reflect every point of view in the final recommendation.
- Decide: The Decide role is for the single person who ultimately is accountable for making the final decision, committing the group to action and ensuring the decision gets implemented.
- RATSI: Another tool used in organization design or roles analysis.
- Responsibility: Identify who is in charge of making sure the work is done.
- Authority: Identify who has final decision power on the work.
- Task: Identify who actually does the work.
- Support: Identify who is involved to provide support to the work.
- Informed: Identify who is informed that the work has been done (or will be started)
- DRASCI: A variant of RASCI developed by three Whitehall theorists (Kane, Jackson, Gilbert). This scheme is adapted for use in matrix management environments, and differs only from RASCI in having an additional role of Driver and a narrower definition of Support:
- Driver: An individual or party that assists those who are Responsible for delivering a task by both producing supporting collateral and setting timescales for delivery in line with the overarching aim of the individual or party who is Accountable for the overall accomplishment of the objective. The distinction between Driver and Support lies in that the former reinforces and clarifies the parameters of the task on behalf of those who are Accountable, while the latter refers to those who help those who are Responsible in reaching a given goal.
- PDQA: A version developed at U Tokyo and MIT for model-based project management. The PDQA set of roles corresponds to demand for capabilities of teams. Roles include those for work on scope, handling of dependencies as coordination, and exception handling through error detection and decisions across a project organization. PDQA is used in agent based modeling to simulate the supply of these capabilities by teams in projects.
- Primary: Provides skill-based effort within capacity to complete scope and also manages dependencies through coordination.
- Decision: Handles any decision, including scope acceptable and exception handling decisions leading to rework.(Does not generation nominal scope).
- Quality: Reviews scope as it progresses to detect poor quality and escalates to decision maker as so. (Does not general nominal scope).
- Assist: Provides skill based effort with capacity to complete scope, in assistance to the primary. (Does not manage dependencies through coordination).
- DCI: A minimal set of decision making categories used in organisation design or roles analysis.
- Decision Maker: Individual(s) who makes the decision and is accountable for its impact on the business.
- Consulted: Individual(s) accountable for providing guidance based on functional expertise and experience, highlighting issues and raising alternatives to support the Decision Maker.
- Informed: Impacted stakeholder(s) are notified after the decision has been made and who will need to support the execution of the decision.
- RASCEIO: To be used when working on governance, risk, compliance (GRC) and outsourcing matters:
- Execute: 3rd parties contracted to execute activities in accordance with a service level agreement
- Overview: Key GRC roles, such as risk owner, policy owner - where accountability is devolved, but a role is needed to oversee whether accountabilities all fit together
There are also a number of variations to the meaning of RACI participation types:
- RACI (alternative scheme): There is an alternative coding, less widely published but used by some practitioners and process mapping software, which modifies the application of the R and A codes of the original scheme. The overall methodology remains the same but this alternative avoids potential confusion of the terms accountable and responsible, which may be understood by management professionals but not always so clearly differentiated by others:
- Responsible: Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.
- Assists: Those who assist completion of the task
- Consulted: Those whose opinions are sought; and with whom there is two-way communication.
- Informed: Those who are kept up-to-date on progress; and with whom there is one-way communication.
- ARCI (decisions): This alternative is focused only on documenting who has the authority to make which decisions. This can work across all sized work groups.
- Accountable: Authorized to approve an answer to the decision.
- Responsible: Responsible to recommend an answer to the decision.
- Consulted: Those whose opinions are sought; and with whom there is two-way communication.
- Informed: Those who are informed after the decision is made; and with whom there is one-way communication.
RACI Matrix Best Practices
Simply creating a RACI matrix is not enough. You must ensure that the matrix maps to a successful strategy. Here, conflicts and ambiguities in the plan must be hammered out. Resolving conflicts and ambiguities in a RACI matrix involves looking across each row and up and down each column for the following:
- Analysis for each stakeholder:
- Are there too many R's: Does one stakeholder have too much of the project assigned to them?
- No empty cells: Does the stakeholder need to be involved in so many of the activities? Can Responsible be changed to Consulted, or Consulted changed to Informed? I.e., are there too many "cooks in this kitchen" to keep things moving? (And if so, what does that say about the culture within which this project is being managed?)
- Buy-in: Does each stakeholder totally agree with the role that they are specified to play in this version of the model? When such agreement is achieved, that should be included in the project's charter and documentation.
- Analysis for each PLC step or deliverable:
- No R's: Who is doing the work in this step and getting things done? Whose role is it to take the initiative?
- Too many R's: Is this another sign of too many "cooks in this kitchen" to keep things moving?
- No A's: Who is Accountable? There must be one 'A' for every step of the PLC. One stakeholder must be Accountable for the thing happening -- "the buck stops" with this person.
- More than one A: Is there confusion on decision rights? Stakeholders with accountability have the final say on how the work should be done and how conflicts are resolved. Multiple A's invite slow and contentious decision-making.
- Every box filled in: Do all the stakeholders really need to be involved? Are there justifiable benefits in involving all the stakeholders, or is this just covering all the bases?
- A lot of C's: Do all the stakeholders need to be routinely Consulted, or can they be kept Informed and raise exceptional circumstances if they feel they need to be Consulted? Too many C's in the loop really slows down the project.
- Are all true stakeholders included in this model: Sometimes this is more of a challenge to ensure, as it's an error of omission. This is often best addressed by a steering committee or management team.
IT Governance Framework
Governance, Risk And Compliance (GRC)
Government Enterprise Architecture (GEA)
Government Interoperability Maturity Matrix (GIMM)
COBIT (Control Objectives for Information and Related Technology)
ITIL (Information Technology Infrastructure Library)
Enterprise Risk Management (ERM)
Technology Strategic Planning
Risk Maturity Model (RMM)
Risk IT Framework
COSO Internal Control- Integrated Framework
Information Technology Risk (IT Risk)
Governance of Risk
Managing Programs and Projects
Project Portfolio Management (PPM)