In a previous post, I talked about the importance of getting clarity, alignment and commitment on individual responsibilities in order to drive project success (Who’s On First) and why it’s important to understand what accountability means (Accountability vs. Responsibility). The primary tool used to support this process is the Responsibilities Matrix…here’s how to create it.
1) Deliverables List
The first key input to the Responsibility Matrix is is your Deliverable List. It should be thorough and organized in alignment with your functional structure. My last industrial project, I used the following;
1) Project Management, 2) Business Development, 3) Regulatory & Permitting, 4) 4) SCM, 5) Engineering, 6) Construction, 7) C&SU, 8) Operations, 9) Maintenance
Every type of project is different so set you functional groups up based the type of project you are working on and how your company is structured. Also use subsection headings to better organize the deliverables within each functional area.
Remember, the deliverables list should be just that…not a bunch of tasks or vague descriptions of things that might have to get done…stick with only the actual deliverables (eg: Project Execution Plan, Piping Isometrics, Construction Contract).
2) Stakeholder List
Most projects vastly underestimate the size of their stakeholder community and that is a big mistake. It’s nice to try to simplify it done to 5 – 10 roles but in reality, a large project can easily have hundreds of stakeholders and every stakeholder has their own unique needs and responsibilities toward the project. Take the time to get a thorough understanding of those stakeholders, both internal and external and organize them by functional area as well. Be sure to Identify actual people as well as their role.
In addition to the people within the functional groups, be sure to also include contractors. And don’t forget things like things like Legal or Finance…other functional areas within the organization that may not own deliverables but will play an important part in their development.
3) Create the Responsibility Matrix Template
In your spreadsheet software, insert the deliverable list on the vertical axis, and insert the Stakeholder List on the horizontal axis. Be sure to use formatting to help visually understand the matrix and provide logical grouping.
4) Identify Individual Responsibilities
Using the RASCI system, begin to identify the Responsible (R) stakeholder for each deliverable. (For more on the RASCI system, see my early post, “Who’s On First“). This is an iterative process that begins with a one-on-one review with each of the functional leads to identify what deliverables their group will take Responsibility for.
Once you have reviewed with all key Functional leaders (and their respective managers) then it’s time to pull the team together to review the chart and get alignment on who is Responsible (R) for what. As per RASCI best practices, the person with the “R” should be the Functional leader who has ultimate authority for the development of the deliverable. They may delegate the deliverable to someone within their team, but during initial planning, it is key that they accept responsibility for all deliverables under their functional area of responsibility.
Overall, you will find pretty good alignment on most Responsibilities and with little discussion or debate will be able to assign all Responsibilities. If there is misalignment between a couple Functional Leads, take it offline and resolve it rather than try to work it out with the entire team.
5) Identify the Customers (A) for each Responsibility
The next step is to next identify your customers. These are the people to whom you are accountable (A) in the development of the deliverable and typically have some form of input on the requirements or standards related to the deliverable or use the deliverable as an input to their own processes.
Remember this tool will help to define your matrix organization where someone may be accountable to you for one deliverable and you are accountable to them for another. Also, rank has no meaning in this process. Just because someone may reside higher on an organization chart, does not diminish their accountability to their customer, who may be several layers lower on that same org chart. A lot of people (and their ego) struggle with this aspect of matrix project teams.
It also allows you to define what it means to have people Accountable to you…it means you set the standards and expectations and then review for conformity to those expectations prior to the deliverable being issued. It doesn’t mean you have veto power and it doesn’t mean you can micromanage. And if you are Accountable to someone, then you have an obligation to answer their questions and resolve their concerns.
It must also be communicated that the Customers (A) MUST define the expectations before the deliverable is developed not during or after. Far to often our project customers don’t spend enough time getting clarity on the expectations so they seem to grow and evolve through the project process. This can be a key contributor to unnecessary scope growth that should have been identified from the beginning.
6) Identify Areas of Concern and Assign Mentors/Consultants (C)
With any project team, you will have Responsible (R) people who really don’t have the knowledge, skill, experience or attitude to be successful in all of their areas of responsibility. There is nothing wrong with this and with today’s workforce, it is actually critical for project success and personal employee growth…you are not learning if you are not doing at least some new things on a project team. But that introduces risk to the project.
If someone has not demonstrated mastery of a specific deliverable, it is essential that the organization assign an individual Consultant (C), either internal (mentor) or external (consultant) who will provide guidance, support and evaluation of the conformance to the stakeholder expectations, standards and specifications.
It is not the Consultant’s role to dictate how the deliverable will be developed or what it should look like, rather its is to ensure that the end product will be safe and meet all stakeholder needs. If the responsible person ignores the advice of the Consultant, they do so at their own risk (and that of the project).
6) Identify the Supporters (S) for Each Deliverable
The Responsible (R) person now must define who will support the development of the deliverable. For example, if I am Responsible (R) for the development of the P&ID drawings, I will likely get someone to draft them (S), someone else to check them (S) and then a team of people to review in the HAZOP (multiple S’). This is also a critical step which will support subsequent Resource Planning (stay tuned for a future post on this) and the development of the tasks (drafting) and sub-tasks (checking) in the next step.
One note of caution, don’t use the Responsibilities Matrix to track action items. These tasks can balloon the matrix into something very unwieldy quite quickly and drive change almost daily Use your Action Item List to better manage and resolve that type of activity. and keep your Responsibility Matrix focused on the project deliverables.
7) Roll Out the Responsibility Matrix
I like to roll out the Responsibilities Matrix at the Project Kick Off with all stakeholders in attendance (either in person or virtually). This gives you a chance to to reinforce the meanings of the levels of responsibility and the commitment to using it as a key project tool to drive improved ownership and accountability.
It also explains your expectations around how the team will deal with challenges as they arise. When an issue does arise, the first question should be, “Who has the ‘R’?”. This significant shift is essential to drive value form the Responsibility Matrix. If the Responsible (R) person is at the centre of the challenge, they are empowered to step up and resolve the challenge.
It also ensures that the Responsible (R) person knows who their customers (A) are and that they are consulted on what the resolution to the challenge will be to ensure it aligns with their needs and expectations.
8) Revise the Responsibility Matrix
The Responsibility Matrix, like all project plans, are a living document. You will never get everything 100% correct so you must be open to changing the matrix as time goes by and as such must be an integral part of Change Management. Whenever a change is introduced that adds, deletes or alters deliverables, the Responsibility Matrix must be revised.
9) Add the Informed (I)
The Responsibility Matrix also serves as a tool for those who want to be informed when a tasks or deliverable is complete. This tool then will replaces the document distribution matrix, advising the Document Management Lead to notify them when a document version has been issued. I often don’t use the I’s as they are often considered a customer who require the Responsible (R) person’s output as an input to their own tasks and deliverables.
This powerful tool is a critical lever in driving organizational and project change to;
1) get better value from your workforce,
2) address project challenges in a timely manner,
3) exceed customer expectations on an ongoing basis,
4) have a more engaged and satisfied workforce.
If you need a blank template to get you started, feel free to send me a request at peter.myers@getmeshed.ca. I have developed these primarily for Industrial Engineering & Construction projects to date. But be sure to work collaboratively with your team to flesh out he Deliverables and Stakeholder Lists.
