Responsibility Matrix
In a large project, there may be many people that have some role in the creation and approval of project deliverables. Sometimes this is pretty straightforward, such as one person writing a document and one person approving it. In other cases, there may be many people who have a hand in the creation and others that need to have varying levels of approval.
For complicated scenarios involving many people, it can be helpful to have a Deliverable Responsibility Matrix. This helps set expectations and ensures people know what is expected from them. For instance, you need to know whether the members of the steering committee need to approve the Business Requirements document. The matrix can describe everyone’s role.
On the matrix, the different people (or roles) appear as columns, with the specific deliverables in question listed as rows. Then, use the intersecting points to describe each person’s responsibility for each deliverable. A simple matrix is shown, followed by suggested responsibility categories.
|
Project Sponsor |
Project Director |
Project Manager |
Project Team |
Steering Committee |
|
| Project Charter |
A |
A |
C |
R |
A |
| Communication Management Plan |
A |
R |
C |
R |
A |
| Business Requirements |
A |
R |
R |
C |
A |
| Status Reports |
R |
R |
C |
R |
R |
- A – Approves the deliverable
- R – Reviews the deliverable (and provides feedback)
- C – Creates the deliverable (could be C (1) for primary, C (2) for backup)
- I – Provides input
- N – Is notified when a deliverable is complete
- M – Manages the deliverables (such as a librarian or person responsible for the document repository)
In the table above, the Project Charter is created by the project manager; approved by the project sponsor, project director 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 project director; and approved by the project sponsor and steering committee.
The purpose of the matrix is to clarify and gain agreement on who does what, so you can define the columns with as much detail as makes sense. For instance, in the above example, the ‘project team’ could have been broken into specific people or the person responsible for creating the Business Requirements could have been broken out into a separate column. After the matrix is completed, it should be circulated for approval. If it is done in the Define the Work step, it can be an addendum to the Project Charter. If it is created as a part of the Analysis Phase, it should be circulated as a separate document.
The ability to gain clarity is vital for the matrix to be effective. It must reflect people’s expectations and responsibilities. For instance, 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. On the other hand, if the sponsor agrees that he will approve the Business Requirements, then, in fact, his approval is required, not that of a subordinate that was delegated the responsibility.
Examples of additional responsibility codes are as follows. Your project may define different codes, as long as you explain the meaning so that people know what is expected of them.
Tenstep.com