I’m not sure how many of us actually use RACIs.
I’ve found that using the RACI in a project charter (or the beginning of project) inventively results in it being so very high level that its not really about solving problems, its about elaborating spheres or domains of work. This is good for the start.
However, once you really get into the project, people start bumping into each other. Some things don’t get done or communicated. Emotions get frayed and then eventually that results in a situation where people want to do a BIG RACI where they sit and solve communication problems by bringing all parties in the room and working through how things fell through the cracks. These sessions usually start with someone coming with a huge list of tasks along with a lot of people, so therefore the RACI is BIG.
These BIG RACI meets can become massive blames sessions, so I’m not a big fan of doing a BIG RACI.
What I’m finding is that using a targeted baby raci can pinpoint problems, zeroing in on just the small amount of people and few tasks needed to remove a communications blocker and or clarify who does what, to get the team moving again. This is really a MVP (minimal viable product) approach to RACIs- meaning do the smallest amount with the least of amount of people to solve immediate small problems.
For example, UAT seems to be a place where things can get confusing. Its also when the project is getting ready to go live, so a lot of new players enter which makes communication channels explode. A RACI done at the start of the project may have said something like this:
|Task||QA LEAD||PM||Product Owner||UAT Testers||QA Testers|
|Perform Functional Tests||R||A||C||I||R|
This is good to start. But then when you get into UAT it gets complicated. Maybe there’s office politics about who can talk to whom. And then there are the QA leads and offshore teams that need to be started/stopped and perhaps a vendor who needs to drop to the UAT environment and then the infra guys who control the UAT environment and before you know it – somebody is mad at somebody.
At this point, take the people responsible and accountable only. Try to keep it small and work out a baby raci. In this example, the problem is that the ‘managing uat’ task above has really exploded into a bunch of very detailed tasks. For baby racis I think that its good to get super specific on these tasks because usually the specificity will surface where the confusion lies.
Doing a baby RACI could look like this:
|Task||QA Lead||Infra Lead||BA||PM||UAT Testers||QA Testers||Product Owner|
|Creating Test Scenarios||A||I||R||I||C||C||I|
|Creating a UAT Test Plan based on the scenarios||R||I||C||R||C||I||A|
|Communicating with users on a daily basis about their findings||C||I||R||R||C||I||R, A|
|Troubleshooting their Findings||A||I||R||R||I||R||I|
|Scheduling pushes to Staging and Production with Release Management||C||C||I||A, R||C||C||I|
|Halting a release date to solve UAT issues||R||C||I||R||C||C||A|
|Communicating decisions about UAT with The Vendor||R||I||C||R||I||I||A, R|
And then…you’re done. Just stop there with the baby raci. No need to figure out the full gamit – just solve the issue at hand.
A Church Does the baby raci
Another team that does this well is my church. I’m on a team that helps with administration and I’m not sure how the pastors learned about RACIs but we use them really effectively. Basically if there is a new mini-project the pastor will send out the following type of message:
To: All Teams
Subject: Some Improvement we need to do
Body: Hi folks, we are going to do ‘improvement a’. After discussion we feel that this is the best RACI for this project:
- Person A – Accountable
- Person B and Person C – Responsible
- Person D, E, F – Consulted
- The congregation – Informed
Baby raci guidelines
Give it a try. Next time you have a block in your project, and people are confused and getting angry, try to take an hour or less, get a few people in a room and whiteboard out a baby raci. Some guidelines:
- R&A Only: Include only the Responsible and Accountables to build the RACI.
- One Area: Focus in on one problem area, not the whole project.
- Specificity is key: Be very specific in the tasks.
- No Blame: Careful not to get into the blame game. Try to keep people focused on the tasks to solve for past failures, but not on the emotion and frustration of the past failures. You may want to lay the ground by saying something like ‘We are going to focus on clarifing what needs to be done and understanding our relationship to the tasks. Things may have gotten dropped but this meeting is to figure out, as a team, how we can help each other do these tasks effectively, not to blame each other about the past.’
- Confirm: Share with the Consulted and Infromed after the meet for confirmation before you make it official.