ITMPI FLAT 004
Main Menu
Home / Authors / Blogging Alliance / Using the RACI Matrix to Maximize Project Accountability

Using the RACI Matrix to Maximize Project Accountability

BloggingAllianceButton
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.

Responsibilities

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 that 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 that 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.

Roles

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, it might look like this:

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.

Variations

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 ensure 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!

 

For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager

About Dave Gordon

Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). 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. You can view his blog at The Practicing IT Project Manager by clicking the button below.

Check Also

3 Tips to Simplify Project Complexity

Everyone wishes the world were just a little bit simpler, especially if they’re a project …

Leave a Reply

Your email address will not be published. Required fields are marked *