RESPONSIBILITY MATRIX

Instructions
The Responsibility Matrix (RM), also known as the Responsibility Assignment Matrix (RAM), is
used to show the connections between work that needs to be done and project team members.
(PMBOK, 3rd edition) This is a highly versatile tool that can be easily modified to suit multiple
project needs. RMs can be developed at various levels of detail, from high to low. It can be used
during any project phase, including the post-implementation support phase, and is especially
useful when activities require coordination between several different groups, agencies, or
vendors.
This document has the following sections:
1. Description of the Responsibility Matrix
2. Variations of Participation Types
3. Real-life Examples

Description of the Responsibility Matrix

Setting up a Responsibility Matrix is about establishing "what", "who", and level of participation.
As shown in Figure 1, activities are listed on the rows and resources are in the columns. Note that
resources may be persons, roles, groups, or vendors.

Resource
1

Resource
2

Resource
3

Resource
4

Activity
1
Activity
2
Activity
3
Activity
4
Figure 1: Example of a Responsibility Matrix
The intersection points are used to describe each resources level of participation for the activity.
The participation type codes are inserted in these cells. A legend is included to define the codes.

Jerry
Review Resumes
Interview
Applicants
Hire Personnel
Purchase
Equipment

I
R
A

Elaine
R
R
I

Network
George
Staff
S
S
I
R

Legend: R=Responsible, A=Approve, I=Inform, S=Support/Assist

Figure 2: Example of a Responsibility Matrix with Participation Codes and

Legend
As shown in Figure 2, resources might not have a participation type code for every activity.
Every activity should have one resource designated as the one responsible for the activity. Also,
it is recommended that each role for each activity receive just one participation type code. When
more than one code is used, it implies that resources role has not yet been fully resolved, which
can impede the value of this technique in clarifying the level of responsibility for the task.
Because the purpose of the matrix is to gain clarity and agreement on who does what, the
columns and rows can be defined with as much detail as makes sense. For example, a high-level
RM can identify what project team group is responsible for each component of the WBS, while
lower-level RMs can be used to designate the participation level of specific group members for
specific activities. (PMBOK, 3rd edition)
There are a number of ways to create a Responsibility Matrix using different participation types.
One common version is called the RACI matrix. RACI is an acronym for Responsible
Accountable (aka Approver) - Consulted - Informed. Figure 3 is a sample RACI chart.
Geor
ge

Glen
da

To
m

Sus
an

Investigate

Design
Software

Develop UAT
Plan

Obtain Signoff

Activity

Mar Crai
y
g
C

Legend: R=Responsible, A=Accountable, C=Consulted, I=Informed

Figure 3: Example of a RACI Matrix
Here is a detailed explanation of the participation types used in the RACI matrix:

Responsible - The person or role who is assigned to achieve the task. There is only one
resource given this category type. Others may be required to assist in the work but they
are either given another participation code, such as Assist, or are not included as the RM
may only list the key people for the activities.
Accountable This person or role must sign off on work that Responsible provides. They
are ultimately accountable for the correct and thorough completion of the deliverable or
task, and the one to whom Responsible is accountable. There must be only one
Accountable specified for each task or deliverable.
Consulted - Those whose opinions are sought and with whom there is two-way
communication.
Informed - Those who are kept up-to-date on progress, often only on completion of the
task or deliverable, and with whom there is just one-way communication (informational
only).

In order for the matrix to be effective, it must accurately reflect people's expectations and
responsibilities. For instance, if the sponsor agrees that s/he will approve the Business
Requirements, then the matrix will reflect the sponsors approval is required. However, if the
sponsor delegated the approval of Business Requirements to a subordinate, that fact should be
represented on the matrix for all to see and approve. After the matrix is completed, it should be
circulated as a deliverable for the appropriate approval(s).
Figure 4 below is an example of a Responsibility Matrix for the development of project
deliverables. It lists the deliverables as activities and uses roles instead of specific individuals. It
also uses different participation types that may be more appropriate for this activity.

Project Functiona Project

Sponsor l Manager Manager

Project
Team

Steering
Committe
e

Project Definition

Communication
Plan

Business
Requirements

Status Reports

Legend: A=Approve, R=Review, C=Create

Figure 4: Example of a Responsibility Matrix for Deliverables
For this matrix, the participation codes used are:

A means that the person (or role) approves the deliverable.

R means that the person (or role) reviews the deliverable.

C means that the person (or role) creates the deliverable; this could be C (1) for primary,
C (2) for backup. Usually there is only one person who is responsible for creating a
deliverable, although many people may provide input.

In Figure 4, the Project Definition is created by the project manager; approved by the project
sponsor, functional manager and the Steering Committee; and reviewed by the project team. The
Business Requirements are created by the project team; reviewed by the project manager and
the functional manager; and approved by the project sponsor and Steering Committee.

Variations of Participation Types (with thanks to Wikipedia):

You may need to use different participation types than those shown above. This is acceptable as
long as a description of each type is provided so that people know what is expected of them.
Here are some other participation types and definitions that may be useful for your project:

Informed - These people need to be kept in the picture. They need updates on the
progress but they do not need to be formally consulted, nor do they contribute directly to
the task.
Input Required - Those who should be consulted as work is prepared, i.e. the driving input.
Notify Those who need to be notified about some aspect of the task, such as the
completion of the task. Those who are impacted by the project, are provided status, are
informed of decisions, and with whom there is one-way communication (informational
only).
Provides Input Those who should be consulted as work is prepared in order to provide
information.
Support These are resources allocated to Responsible in order to assist in completing the
task.

Verifier - Those who check whether the product meets the acceptance criteria set forth in
the product description.

The following participation types may be used in a Responsibility Matrix for decision-making
roles. The same type name may have slightly different definitions.

Approves Those who are authorized to approve an answer to the decision.

Approver - The Approver decides by vetoing or choosing one of a series of well laid out
options. The Approver is expected to possess the skills and experience to make decisions
that will not be overturned, and helps to mentor/coach others until they gain requisite
experience to become an Approver. Only the Approver may veto all options.
Approver - The Approver may initiate the process and designate the Process Owner. This
person works with the Owner to scope the decision-making matrix. They handle any
escalations from Reviewers and make the final decision based on recommendation from
the Owner.
Consulted - Those whose opinions are sought and with whom there is two-way
communication. Consulted people must not attempt to veto by going to the level above to
overturn a decision.
Executers - Those who carry out the decision once made.
Informed - These people need to be kept in the picture. They need updates on decisions
and are informed after the decision is made, but they do not need to be formally consulted
nor do they contribute directly to the decision. This group represents information-only or
one-way communication recipients.
Participant -These are often self-selected or non-critical path input providers. This group
also represents notification-only or one-way communication recipients.
Process Owner (or Process Leader) - One person has the Process Owner role to drive the
decision making process on behalf of the Approver. The Process Owner is expected to
bring well thought out/researched options to the Approver who will make the final decision.
Recommends - Responsible to recommend an answer to the decision.
Reviewer - These are affected parties who will be impacted by the decision. They can
escalate issues directly to Approver.