When people work in teams, confusion about who does what, where decisions get made, and who needs to be kept in the loop can creep in and spoil the fun.
Have you ever had to sit through a meeting having no idea why you were invited? …or have you ever sent an email To: multiple people asking for a decision because you weren’t sure exactly who should make the call? …or received an email that was sent To: multiple people and felt you just HAD to respond, but really the sender was only intending to keep you in the loop?
CAIRO Can Help
CAIRO is an acronym. The letters stand for: Consulted, Accountable, Informed, Responsible, and Omitted.
To build your own CAIRO matrix and start to clear things up, try this:
- Identify and list all of the processes and activities that surround a project or team – one per row.
- List the people or roles involved – one per column.
- For each process or activity mark down who the ‘R’ is. There can only be one. If there’s more than one, try breaking the activity into smaller activities.
- Determine who are Accountable to the Responsible person for getting all or parts of the actual work done.
- Then determine who needs to be Consulted and who needs to be Informed. Consulted parties provide input, unlike Informed parties who are silent.
- Finally, and sometimes this is the tricky part, determine who explicitly will be Omitted. These are people that don’t need to be involved in any way.
The resulting chart is simple, but forcing yourself to think about which letter to assign to everyone for each item will require some thinking and may even stir some debate.
An Example
Try not to get hung up on the details of whether or not this is the right way to assign roles and responsibilities. This example shows an IT organization with activities surrounding the acquisition of hardware for a development team.
To add some color the above matrix, here are a few descriptive paragraphs:
The Director of IT is Responsible for ordering workstations for developers. Although he is ultimately accountable to his boss (**), the Chief Technology Officer for this, the buck stops at the Director of IT when it comes to decisions about the ordering of workstations.
The Director of IT has asked Systems Support to actually carry out the work, so they are Accountable to the Director of IT for ordering workstations for developers.
When workstations are ordered, the Systems Support team is sure to Consult with the project manager to time the order and delivery with the schedules of developers that need them. In addition, the developers are Informed when workstations are ordered.
The COO and Board of Directors are not kept in the loop about developer workstation orders. They are explicitly Omitted from communications relating to the ordering of workstations for developers.
The result of doing this with your team is that everyone will know their role and have a clear understanding of what’s expected of them in terms of team communication. In addition to this, everyone will know what everyone else’s level of involvement is for each activity.
We really enjoyed the insight we got out of doing this matrix (especially the things we should be omitted from, but currently are not), however we went by the role definitions as described on wikipedia which have the Responsible and Accountable roles reversed compared to your description.
http://en.wikipedia.org/wiki/RACI_matrix
I found the terminology in that article to be inconsistent between variations, so I made my own variation that made sense to me. As long as people understand the meaning either method will work.
The Wikipedia-RASIC definition of Accountable didn’t make sense to me. “Accountable to whom?”, was my question. I also see a level above the Accountable role that needed to be included.
Here’s my attempt to translate:
Wikipedia-RASIC defines ‘A’ as the final approving authority (can only be one).
I defined ‘**’ as the final approving authority. I’m not sure of the subtleties of the Wikipedia definition, but I would add that ‘**’ may not be actively involved in the process and can remain hands off; i.e. they have empowered someone (one person).
Wikipedia-RASIC defines ‘R’ as those who do the work to achieve the task.
I defined ‘R’ as the person empowered by ‘**’ (the final approving authority) to get the job done. ‘R’ in turn assigns work to ‘A’s who are Accountable to ‘R’ to get the work done. There is an extra level in my variation. Without that extra level there is no separation between the person actively managing (‘R’) and the person with final approving authority (‘**’).
I like my variation because it translates to natural language nicely. If you’re an ‘R’ for something, that means you’re responsible for getting it done even though your boss likely has the final approving authority. Your boss, the ‘**’, has made you and only you ‘R’esponsible. You will have many people who are ‘A’ccountable to you for getting that work done.
In Wikipedia-RASIC terms this would read: If you’re Accountable for something (to whom?) that means you have final approving authority (you may not). You have no boss, however you will have many people that are ‘R’esponsible for getting the work done.
Considering the number of variations in that article, I wouldn’t say that flipping the R and A is wrong, just that it’s another variation. The best approach is probably just to find what works for you and your team and be clear about the definitions.
One question. Do you have Responsible and Accountable mixed up? My understanding was that there was one and only one that is held Accountable, but many who are Responsible – the ones who do the work to achieve the result.
I’m only basing this on what I read at:
http://en.wikipedia.org/wiki/RACI_matrix
Thanks Hemant. Let me know if my response to Chris clears this up.
Neat post. I was introduced to this recently, but got a very different impression of how it could/should be used, which I also think is useful.
If you have a team where the roles are not well defined, you can use a set of matrices to expose the areas which are unclear. Have multiple people fill in the same matrix, and then discuss the differences.
I think that in this situation, you can’t hope for the advertised result immediately: “everyone will know their role and have a clear understanding of what’s expected of them in terms of team communication”; but it still gives you a great starting point.
I agree Kevin. These things never work in the magic bullet sense of the word, but rather facilitate the conversations necessary to bring improvements.