Responsibility Matrx - RACI, RASCI, and More

What is it?

A responsibility matrix, of which the best known variant is the RACI Matrix, describes the level of responsibility of various roles or persons in completing tasks or deliverables that are needed for some project, process, or effort.

For each task or deliverable, a level of responsibility is assigned in the matrix to each role or person. Most frequently, tasks are assigned to a role instead of a specific person as there may be more than one person filling a role, or a single person may be filling multiple roles. However, when there are multiple persons filling the same role (multiple business analysts for example) but the tasks assigned to those persons are not expected to overlap much, you may be better off using actual names instead of roles. This is especially true when there is any chance of confusion on exactly what roles individuals are filling.

There are a number of variant versions of the responsibility matrix structure. These include:

RACI

In a RACI matrix, there are four levels of accountability, each of which corresponds to one of the letters in the name. The levels are:

Responsible Those who are assigned the “Responsible” level of responsibility do the work to achieve the task. For every task or deliverable, there should be at least one role with this level of responsibility. However, other roles can be delegated to assist in the work required (see also RASCI below for separately identifying those who participate in a supporting role).

Accountable (sometimes known as Approver) Those who are assigned the “Accountable” level of responsibility are those that are ultimately answerable for the correct and thorough completion of the deliverable or task. They are also the ones who may delegates the work to those who are “Responsible”. In other words, an “Accountable” must sign off or approve the work that a “Responsible” does. For every task or deliverable, there must be only one role with this level of responsibility.

Consulted (sometimes known as Counsel) Those who are assigned the “Consulted” level of responsibility are those whose opinions are sought during the work to complete the task or deliverable, or who help to review the result of the work to ensure it meets the necessary goals. They are typically subject matter experts or those who may be directly impacted by the work; and two-way communications with them are usually maintained throughout the work process.

Informed Those who are assigned the “Informed” level of responsibility have no required work to support a task or deliverable, but are usually kept up-to-date on work progress. Or they may only be notified once the work or deliverable is completed. Typically, communications with those in an “Informed” role are purely one-way from those who are Accountable or Responsible.

RACI Alternate Schema

An alternate RACI schema uses the following alternative definitions for the "R" and "A" responsibility levels:

Responsible This is the role responsible for the successful completion of the task or deliverable. There should be only one Responsible role for each task. In this schema, the Responsible role takes on the duties of the Accountable role in the normal schema.

Assists This role assists the Responsible role in the completion of the task. It is closer to the Responsible role in the main RACI schema, or the Support role in the RASCI schema below.

RASCI

RASCI (also sometimes known as RASIC) is an expanded version of RACI in which the Responsible role from the RACI schema above is broken into two separate roles. Those roles are:

Responsible Who are responsible for ensuring the task is done as per the Approver’s direction.

Support Who are assigned to the Responsible role in order to help them complete the task as specified.

RACI-VS

This is another expanded version of the standard RACI schema above, in which two additional roles are added. Those new roles are:

Verifier The Verifier role is filled by those who are responsible for ensuring that the work product or deliverable completed by the Responsible party meets the criteria specified by the Accountable role. For example, this might be filled by a testing specialist of some sort, or an SME with high expertise in the necessary area.

Signatory The Signatory role is made up of those who formally approve the Verifiers decision that the work product meets the specifications. In most cases this would probably be the Accountable role. But it might also be filled by a client representative, auditor, compliance officer, or similar role.

CAIRO

Another expanded version of the standard RACI schema is the CAIRO schema, also sometimes known as RACIO. This schema adds an additional role of:

Omitted The Omitted role specifies those who are specifically not involved with a task. This can be especially useful when there is any confusion or dispute about who may be involved in completing a task.

CAIROS

The CAIROS schema is a combination of the RASCI and CAIRO schemas in that it adds two additional roles to the standard RACI schema. Those are the Support role from RASCI and the Omitted role from CAIRO.

DACI

The DACI responsibility schema is geared more towards defining overall project responsibilities. The roles in the DACI schema are:

Driver There can be only one Driver role per project. In most cases this is the project sponsor and it is this role that is the ultimate decision-maker for all project issues.

Approver The Approver role is responsible for approving most project work, and is the role that bears responsibility for ensuring the work is successful. They are also the parties who will be responsible for failure. In most projects, these are the project managers and stakeholders who make up the core project team.

Contributor The Contributor role does most of the actual project work. In most projects this would be the business analysts, SME’s, systems analysts, developers, and others who actually execute the project. Like the Consulted role in the standard RACI schema, there is usually two-way communication between the Contributor roles and the Approver and Driver roles.

Informed The Informed role is made up of those who impacted by a project. They are provided regular status updates and informed of decisions made by the Approver and Driver roles, but are not actively involved in the decision-making or execution. In most projects, these would be the non-core stakeholders of the project. Like the Informed role in the standard RACI schema, there is usually only 1-way communication between those in the Informed role and those in the Driver, Approver, and Contributor roles.

Why do it?

Responsibility matrices actually have a number uses that business analysts should be aware of, and can be used in (at least) the following ways:

Project / Stakeholder Management

The most common usage of responsibility matrices is in project management, where they provide the following benefits: ^[4]

Defines the agreed upon responsibility for all roles in achieving a particular project or task
Clarifies roles and responsibilities, ensuring that everyone knows who should do what
Helps ensure the right groups involved
Helps eliminate duplication of effort
Reduces the risk of misunderstanding
Defines decision-making responsibility for all tasks

Process Mapping

A responsibility matrix is a great way to add addition information to a process mapping exercise. By creating a RACI or similar matrix for the process, you can identify the different levels of responsibility for each step in the process flow.

Process Re-Engineering

By starting with a responsibility matrix of the as-is process above, a business analyst now has a great deal of information that will help them re-engineer the process. The matrix can help them identify potential process bottlenecks, and when a new process is designed a new matrix can be created that shows new responsibility levels. The old and new matrices can then be compared to ensure no tasks, steps, or stakeholders have been left out of the new process.

Organization Analysis

Like the process mapping usage above, creating a responsibility matrix while analyzing an organization helps a business analyst to better understand who does what and who has what responsibilities.

This can help the BA identify critical business units or SME's, identify potential stakeholders for a project or effort, or just better understand the politics and responsibilities of various business units.

Solution Definition and Analysis

A responsibility matrix should be created for any new IT systems or applications that are deployed as part of a project. The matrix should indicate who “owns” the application (is Accountable), who supports the application (is Responsible), who owns systems that the new application depends on or who depend on the new application (is Consulted), and who has interest in knowing about changes to the application or its status (is Informed).

When considering changes to an existing system, the responsibility matrix for that system can help ensure that all needed stakeholders are involved in discussions and decisions.

Training

The as-is responsibility matrix for a current process, business unit, or organization can be an invaluable tool for helping new employees understand the responsibilities of a new role they are undertaking, and how that role fits in with the overall business process. When combined with a to-be matrix, this is especially useful in training existing employees to understand what changes are occurring as part of a new process or system roll-out.

How do I do it?

Creating a responsibility matrix is a relatively simple process that follows the following steps:

Step 1

Identify the tasks or deliverables that must be completed in order for the result to be achieved. If you have one, a Work Breakdown Structure (WBS) is a great start for this. List these down the left vertical axis of a matrix; preferably in the order they should be done. In Excel, you may start like this:

Step 2

Decide whether you will be assigning responsibility to roles or actual named individuals. Then list the roles or names across the top of matrix, one per column. In Excel, this step might look like the following:

Step 3

Select the responsibility matrix schema that is most appropriate for your needs. Then go through the matrix considering each task in turn. For each task, specify the responsibility level of each role by inputting a capital letter (the first letter of the appropriate responsibility level) that indicates the responsibility level of that role in achieving the task. Unless you are using a schema that includes the Omitted responsibility level, not every role must have a responsibility level assigned.

An example in Excel using the RASCI schema might look like this:

Step 4

The next step is often the hardest. This is to not just review the chart, but to make sure that all parties involved in the project or effort understand the responsibility level they have been assigned and agree with that assignment.

When reviewing the chart, the following are potential issues to look for: ^[2,3]

Are there any roles missing?
Are there any tasks missing?
Should any tasks be further broken down into separate tasks?
Is someone Accountable for each task?
Is there only one person Accountable for each task?
Is someone Responsible for each task?
Is there only one person Responsible for each task?
Are there too many people who are Accountable (thus spreading decision-making responsibility)?
Is everyone Consulted who should be?
Are there too many roles being Consulted for a task, which could result in gridlock?
Is there any role with too many Responsible assignments, possibly indicating a role that may be overburdened?
Are there too few roles who are Responsible, possibly representing a lack in project resources that could result in bottlenecks.
Do the people filling the roles, especially those who are Responsible or Consulted, have sufficient skill or knowledge to be successful? Should a more senior person be assigned to that role?
Do the people filling the roles, especially those who are Consulted or Informed, have too much skill or seniority? Will the responsibility levels assigned require too much of their attention and time, and can the roles be delegated?
Does every role have at least some level of responsibility other than Omitted (if used)? If not, does that role really need to be involved in the effort?

Step 5

Update as necessary. Changes may occur among the project resources, or your knowledge of a task may change. All of these may require that a responsibility matrix be updated.

What Should the Results be?

When the responsibility matrix is complete, you should have achieved the following results:

All tasks necessary for the effort should be identified.
All roles necessary for the completion of the tasks should be identified.
Every person involved should both understand and agree with the roles and responsibilities they have been assigned in order to achieve the effort.

Advantages

Responsibility matrices are invaluable tools for stakeholder management efforts, in that they ensure all stakeholders are aware of and agree to what responsibilities they have to the project.
The help ensure that in the event of project turnover, the new resource is aware of their responsibilities are, or they help re-assign the responsibilities of the departing resource.
They are relatively easy to create and can be used in a variety of non-project scenarios as well.

Disadvantages

The process of getting to an agreed upon responsibility matrix can be a tumultuous one if there is disagreement among stakeholders on what they think their role or responsibilities should be versus what role or responsibilities are being assigned to them.
It can be easy to get bogged down in trying to define every conceivable task before a project gets underway. This can both side-track project work and cause further debate among stakeholders.

Tips

Responsibility Matrices are easily created in Excel (see the template below under Resources), in Word as a table, and even in Visio (also see the template below under Resources).
You may want to consider color-coding the cells of the matrix by responsibility level in order to make it more understandable at a glance. This might make the matrix look like this:

Responsibility matrices exist in Agile project work, but may not be explicitly called out as such.

The Product Owner is Accountable for all tasks / decisions.
The team member who volunteers (self-management) to complete a deliverable (code a feature, etc.) is Responsible.
The Scrum Master, SME’s, and Business Analyst (if there is one) are Consulted.
Developers not working or impacted by the functional code set and other stakeholders are Informed.

References

Wikipedia entry – Responsibility Assignment Matrix. Accessed on June 15, 2013.
Article - How to Do RACI Charting and Analysis: A Practical Guide, from ProjectSmart.co.uk
Book – Business Analysis Techniques: 72 Essential Tools for Success. By Cadle, Paul, and Turner. 2010
Blog Post - Project Management: 6 Steps to Creating a Successful RASCI Chart, from the Canoe Group. 2009

Related Resources

Template - An Excel 2013 RACI Chart template, from Microsoft
Template - A Visio 2010 RACI template, from Microsoft
Article – RACI Charts and Project, from Microsoft. Discusses who to input RACI info into a MS Project.
PDF - How to Develop and Use RASCI Charts, from Ohio State University.
Article - RACI Matrix, from ProjectSmart.co.uk