Clarify Roles and Responsibilities Using a RACI Matrix

One of the challenges of planning and controlling a complex project is delineation of roles.  This can be especially challenging when representatives of multiple organizations are participating in the project.  For any particular phase or task, it can be difficult to explain what participation is expected of each assigned team member, as roles might change from one task to another.

The Fourth Edition of the PMBOK includes a brief description of a RACI matrix or chart in the discussion on the Responsibility Assignment Matrix, including a simple depiction of a table with four activities and five people, listing each person’s participation.  However, the description is somewhat minimalist, so I’ll go into a bit more detail.  Let’s start with a description of the elements of the acronym RACI:

Responsible: This is the person who actually performs the task.  For example, if the task is to write the code for a program module, then it’s likely some programmer on the team is responsible for writing that code.

Accountable: This is the person who is accountable for the quality and timeliness of the completion of the task, and is frequently the person to whom the responsible person reports. Following the example above, the software development manager might be accountable.

Consulted: These are the subject matter experts, or other people who provide information needed for correct execution of the task.  There is two-way communication between the person responsible (and sometimes accountable) and those consulted.  Again, following the example, the designer or business analyst might be consulted.

Informed: These are the people who are impacted by the progress of the task, and so are advised of milestones or significant developments.  In the past, I’ve worked on a couple of projects where we used the notation Ix to signify those who are to be “informed of exceptions,” when things don’t go according to plan.  Note that informed is a one-way communication, unlike consulted.  In our running example, the QA team might be informed.

Obviously, not all activities require this level of clarification.  Many project managers only use a RACI chart for those activities which have multiple team members.  Others will only chart WBS activities down to a given level of indenture, rather than each work package.  But in potentially contentious or otherwise complicated projects, a greater level of detail may be called for.

Once you’ve selected the activities to chart, identify the applicable roles.  The activities are listed in the left column, and the roles are listed in the top row.  In each cell, identify whether the person in that role is to be responsible, accountable, consulted, or informed.  Note that at least one role must be responsible for each activity, but there must be only one accountable.  In some cases, the role responsible is also accountable.  Not all activities will have someone consulted or informed and not all roles will participate in all activities.  Following our software module example:

Activity Programmer Development Manager Business Analyst Designer QA Analyst QA Manager
Interface requirements I R A
Interface design A C R I
Interface code and unit test R A C I
Interface integration testing C I C R A

In this example, you can see the flow of work product responsibility from business analyst, to designer, to programmer, to QA analyst.  You can also see that those responsible for an activity frequently consult with those who prepared their task inputs.  Note also that in this example, the designer is accountable for the work of the business analyst.  While this might not be the case in some organizations, since the designer has to use the requirements as input, (s)he should have a say in whether the requirements are complete.  However it works on your project, remember: only one person can be accountable.

Of course, there are some variations on the basic approach.  Some very formal methodologies, including many federal government projects, use RACI-VS.  In this variation, the V is for Verify, meaning the person responsible for independently verifying the quality of the product of the task.  The S is for Signatory, meaning the person who “signs off” on the completion of the task, thus approving release of funds for payment.  In this variation, the business analyst might be both responsible and accountable for the interface requirements, the designer might verify, and the development manager might sign off.  Other, less commonly used variations include  RACIO and RASCI, where the O stands for a role specifically Omitted, and the S stands for a Supporting role, assisting those responsible.   Naturally, some creative types have tried to make these variants more pronounceable, so you might see them written as VARISC, CAIRO, and RASIC, respectively.

A RACI matrix can be especially useful in clarifying the project manager’s vision of how the project will come together, but be sure to review it with both the team and the key stakeholders during planning to be sure they buy into that vision.  After all, the intent of using this technique is to avoid disputes in the execution phase, not to trigger them!

This entry was posted in Best Practices by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.