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:
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.
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 (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.
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.
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.
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.
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.
Responsibility matrices actually have a number uses that business analysts should be aware of, and can be used in (at least) the following ways:
The most common usage of responsibility matrices is in project management, where they provide the following benefits: 
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.
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.
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.
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.
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.
Creating a responsibility matrix is a relatively simple process that follows the following steps:
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:
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:
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:
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]
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.
When the responsibility matrix is complete, you should have achieved the following results: