A statement of work answers many questions about a project, including the purpose, scope, deliverables, and chain of command. There is, however, a need for another document that precisely details the responsibilities of each group involved in a project. This is called a responsibility matrix. The importance of this document is growing as corporations re-engineer themselves and form partnerships and virtual companies. In these kinds of environments, many groups that otherwise might have nothing to do with each other are brought together to work on projects.
A responsibility matrix is ideal for showing cross-organizational interaction.
For example, when a truck manufacturer creates a new cab style, it requires changes in tooling for the supplier as well as on the assembly line. The inevitable questions then arise:
- Who will make design decisions?
- Will the supplier have a voice in these decisions?
- When does each group need to get involved?
- Who is responsible for each part of the project?
The responsibility matrix is designed to answer questions like these.
Setting Up a Responsibility Matrix
A responsibility matrix lays out the major activities in the project and the key stakeholder groups. Using this matrix can help avoid communication breakdowns between departments and organizations because everyone involved can see clearly who to contact for each activity. Let’s look at the steps involved in setting up a responsibility matrix:
List the major activities of the project. As shown in Figure 1, only the major project activities are listed on the vertical axis; detailed task assignments will be made in the project plan. (Figure 1 is a sample responsibility matrix for the training project described in Figure 2.)
Because the responsibility matrix shows interaction between organizations, it needs to emphasize the different roles required for each task. In highlighting the roles of the various stakeholders involved in the project’s major activities, the matrix in Figure 1 uses the same level of detail as the scope statement in Figure 2. On very large projects it can be useful to develop multiple responsibility matrices with different levels of details. These matrices will define sub-projects within the larger project.
List the stakeholder groups. Stakeholder groups are listed on the horizontal axis of the matrix. Notice how groups such as project team and user council are named, rather than individual team members; these individual team assignments are documented in tho project plan, It is appropriate, however, to put individual names on the matrix whenever a single person will be making decisions or has complete responsibility for a significant part of the project.
Code the responsibility matrix. The codes indicate the involvement level, authority role, and responsibility of each stakeholder. While there are no limits to the codes that can be used, here are the most common ones:
- E—Execution responsibility. This group will get the work done.
- C—Must be consulted. This group must be consulted as the activity is performed. The group’s opinion counts, but it doesn’t rule.
- I—Must be informed. This group just wants to know what decisions are being made.
- A—Approval authority (usually an individual). This person has the final word on decisions or on acceptance of the work performed for each activity.
Notice how decisions can be controlled using I, C, and A. Specifying clearly these different levels of authority is especially useful when there are different stakeholders who all want to provide requirements to the project. For example, in Figure 1, the project office has a say in selecting the basic course materials and instructors, but is left out of modifying the training or certifying the instructors. By using the responsibility matrix to specify these responsibilities, the project manager (in the training department) has successfully managed the role of the project office.
Incorporate the responsibility matrix into the project rules. The matrix becomes part of the project rules, which means that once it is accepted, all changes must be approved by those who approved the original version. The advantage to this formal change management process is that the project manager is always left with a written document to refer to in the event of a dispute.
When writing out the responsibility matrix you need to leave no doubt about who must be consulted and which
stakeholder has final authority. This will have the effect of-bringing out any disagreements early in the project.
It’s important to make all these distinctions about authority and responsibilities early, when people are still calm. It’s much more difficult to develop a responsibility matrix during the heat of battle, because people have already been acting on their assumptions and won’t want to back down. Disagreements on these issues later in the project can escalate into contentious, schedule-eating conflicts.