One of the great challenges of running any project is figuring out who does what. A RACI (or RASCI, depending on who you ask) charts is a great tool to help you get your team priorities and activities in line.
RACI is an acronym for the different levels of engagement in any project activity.
R – Responsible to perform the task
A – Accountable for the task being completed
C – Consulted with prior to the activity being performed
I – Informed that the task has been completed
Every task will have some combination of these levels, but not always all five. (Some charts add the Support role as well. I prefer to stick with RACI for the sake of simplicity.) Let’s take a look at how these roles might be applied to a project task, such as a software upgrade.
This is the person or persons doing the work. If you have a team of programmers working on a software upgrade, they are Responsible to make sure the coding is performed, tested, and works. Many hands make the work light, it is said, so it is not uncommon to see many Rs on a task.
For any task, someone is in charge of getting it done. This might be the senior programmer, the project manager, or the IT resource leader. If you only have one programmer working on the task, they may have the R and the A assigned to them. But if there is a team, someone coordinates that work and makes sure it is done.
It has been said that if everyone is accountable, no one is. In project work, this is often the case. So while you have many Rs, there can only be one A. They are the Highlander of the project task, I suppose.
You will often have important tasks in a project that must be complete before the next step starts, as well as communications to stakeholders before work on a new task begins. In our software example, we may need to make sure we have a development environment available (so as not to disturb the “live” environment), so we may need to Consult with our system administrators to make sure that environment is ready and no one will be impacted by our programming changes. It ensures a safe place to work, as well as making sure we won’t interrupt or be interrupted by others.
Multiple Cs often exist for a task, depending on the level of complexity of the task. Hopefully those interested parties are part of the normal project communications.
When the work is done, we need to let others know. In this example, we may need to let the system administrator know we no longer need our development environment, that we are ready for user testing or integration testing, that we can reassign our programming resources, etc. Indicating the Is on our chart makes sure we know to whom that communication should be sent.
The optional role of the chart. These are people who make sure the task owners are successful. Support role in our example might be the system administrator who makes sure our development environment is not disturbed, the IT leader who can help provide additional resources as needed, all the way down to the administrative assistant who makes sure the programmers have ample coffee, No-Doz and Mountain Dew supplies to stay productive.
I prefer to leave this role out of the chart, as I mentioned, for simplicity. Most of these roles are either captured in the Rs or Cs, or are not really part of the project team. If you feel the need to include them though, I won’t judge you.
It might be helpful to see a RACI created for a typical HR task. But that’s another show.