In his article “How to Turn a Failed Project into a Successful Program”, Shay Shargal noted that one of the reasons projects fail is the “Poor communication and coordination between various stakeholders of the project: Customers, Vendors, Suppliers, Managers, Resources and others.”
When communication breaks down and perceptions on roles and responsibilities are misaligned, the resulting way of work often becomes a “blame game” where escalations are “business as usual”. In this article I would like to share with you the use of the RACIVS-matrix (also known as the Responsibility Assignment Matrix). Many project managers have heard of this project management technique, but its value is generally underestimated. Using RACIVS is an excellent way to describe the roles and responsibilities of stakeholders related to specific deliverables (or activities) and it will bring you one step further in preventing poor communication and coordination.
Here’s how to apply it. List the deliverables, in the project plan section on deliverables, in a matrix. The RACIVS-elements should be filled in for each deliverable. This is what RACIVS stands for:
- Responsible: the person or party responsible for creating the deliverable; i.e. doing the actual work.
- Accountable: the person or party accountable for creating the deliverable; i.e. the person/party that you can appeal to should the work not get done. Note: there can be only one accountable per deliverable!
- Consulted: the person or party that will be actively consulted in the creation of this deliverable.
- Informed: the person or party that will be informed on the (end) results.
- Verifies: the person or party that will review the deliverable and will advice the sign-off person/party to accept / reject the deliverable.
- Signs-Off: the person or party that will sign-off on the deliverable.
Let’s consider a user manual. We could state the following in the project plan: as the user manual has to be delivered by the project, the project manager is accountable that the manual is completed. The senior designer from the project team will write the manual, with active involvement from the key-users. The helpdesk is informed (as they need to be aware of the existence of the manual) and at the end the key-users will review the manual and will give an acceptance advice to the senior user, who can then approve the user manual.
That’s a lot of sentences! More effectively, we can state the same information in a RACIVS-matrix , listing the stakeholders in the appropriate RACIVS column for each deliverable:
Deliverable | R | A | C | I | V | S |
| User Manual | Senior Designer | Project Manager | Key users | Helpdesk | Key users | Senior User |
See how powerful a RACIVS matrix can be? Alternatively, if you have a limited number of stakeholders (or work with teams) it may make more sense to list the stakeholders in the columns and just enter an R, A, C, I, V or S (or combination of these) in the stakeholder cells for each deliverable:
Deliverable | Development Team | Client | Key Users |
| User Manual | RA | IS | CV |
Just experiment with what works best for you. Note that RACIVS-elements do not always need to be assigned. You can use this for instance to make clear that some deliverables do not need a formal sign-off.
Using the RACIVS technique may seem a bit cumbersome, but it actually will save you a lot of discussion on “who should’ve been doing the work in the first place”. I invite you to use this technique in your next project plan and am curious to hear about your experiences.
