Responsibility Assignment Matrix

This article discusses how a responsibility assignment matrix can provide a visual view of how WBS tasks are assigned to individuals/teams within the project.

Responsibility Assignment Matrix

The Project Connections web site has a posting on RAMs. They call them Responsibility Allocation Matrix which is not quite true - given the general consensus of the industry. But hey it's their site, they can call it what they want.

They then proceed to confuse us a bit with the statement

RACI has it's place, but this Responsibility Allocation Matrix takes project responsibilities and commitments to a whole new level. Detailed and role-focused, it asks all project team members to consider their key project tasks, the inputs they need, and the outputs they expect to deliver, for a more complete look at the cross-functional dependencies in your plan.

What? RACI means Responsible, Accountable, Consulted and Informed. In RACI the individual assignments (R, A, C, I) can be easily be represented in Excel and plotted in a BIG VISIBLE CHART and hung on the wall.

Next comes the suggestion that the RAM be used during the planning phase. This is true. But the RAM is used during all phases of the project. The RAM can serve as a touch point for all project participants to confirm and re-confirm who is Accountable for what. It should be WBS focused and connected to the Master Schedule, so When the item they are accountable for is due can be shown in the same Big Visible Chart. Here's a picture of how the RAM works extracted and cleaned up from a US Army handbook on RACI. Notice a critical aspect here - defining the ACCOUNTABLE person is the first step. unless the accountable fields in the matrix are filled, the other fields aren't of much value. The next step is to assign the Responsible fields. From there you're pretty much done.


It Is Role Based, But That's Not The Starting Point

The posting suggests the RAM starts with the roles. This is not the place I would start. Instead I'd start with listing the deliverables of the project. These are the artifacts of the project that the project's customer is interested in; the things they are willing to pay for. Get this defined and you've pretty much got the project scope defined - minus the annoying little things needed to make these appear that the project's customer probably isn't willing to pay for explicitly. These are needed, of course, but they probably don't add value to the business process. They're just part of doing the project.

Now with those items in the rows of the RAM, figure out who is ACCOUNTABLE for making them appear. Emphasize "accountable." "The buck stops here" kind of accountability. One and only one person can be accountable. Multiple people can be responsible and certainly others can be informed and consulted.

Why All The Fuss?

Without the RAM there is only tacit agreement on who is accountable for what. With the RAM it is explicit. But don't make this too complex, and certainly you don't have to "pay" to get this information.

A Google search of "Responsibility Assignment Matrix" will get you all the RAMs you'll ever need.

And PCubed will even show you how to build one.

What the RAM does in the end is to connect the Organizational Breakdown Structure (OBS) with the Work Breakdown Structure (WBS). The absolutely critical thing though is to have the WBS represent Deliverables not the functions.


Source: Herding Cats, https://herdingcats.typepad.com/my_weblog/2007/02/responsibility_.html
Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License.

Last modified: Wednesday, November 30, 2022, 3:17 PM