communication

It’s one thing to build a project definition and the workplan. It’s another thing to effectively manage the project. If the project manager could just could create the plan and the work assignments and have everyone complete their activities on-time, your life would be much easier. However, the process of managing the team and the workplan is more complex than that. …

Team Resistance to Managing the WorkplanRead More »

Large Projects – Beginning of the Project

Large projects should definitely be capturing metrics that will provide information on the quality of the deliverables and the processes used to create the deliverables. The following process can be used to come up with the appropriate metrics on the project. This process will result in the creation of a Project Scorecard. …

Manage Metrics – Large Projects – Beginning of the ProjectRead More »

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.

• 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