You hear the term RACI, and inwardly groan. Far from the slightly exciting sounding acronym, it can often become a bit of a beast to create, with headaches caused by trying to work out who should be given which role for every task or deliverable.
The RACI chart (also known as RACI matrix or diagram) should be there to make your life easier as a Project Manager, but can be the elephant in the room at the beginning of the project, that no one wants to complete or review, or even then use. So how can you make your RACI a useful tool that can help you, and your project?
In this article I’m going to help simplify the RACI process by showing you how to use RACI charts in the best and most effective way, giving tips on how to avoid the common problems, and providing a RACI matrix template to use on your project.
Firstly, What Is A RACI Chart?
Put simply, it’s a tool that identifies roles and responsibilities against tasks within a project.
What does RACI stand for?
The RACI maps tasks and deliverables against roles on your project, and decision making and responsibilities are allocated to each role using the above terms. So let’s look a little further at what each of these terms mean.
Responsible: Doing The Task
This person actions the task or deliverable. They are responsible for getting the work done or making the decision. It can sometimes be more than one person, but try to minimise the amount of people involved.
Accountable: Owning The Task
This person or role is responsible for the overall completion of the task or deliverable. They won’t get the work done, but are responsible for making sure it’s finalized. Ideally, this should be one person rather than a group to avoid confusion in terms of who actually owns the task.
This person, role or group will provide information useful to completing the task or deliverable. There will be two-way communication between those responsible and those consulted.
Informed: Keeping Aware
These people or groups will be kept up to date on the task or deliverable. This could be on progress, or when the task or deliverable is completed. They won’t be asked to feedback or review, but they can be affected by the outcome of the task or deliverable. There should be one-way communication to these roles or groups.
Why Should I Care? The Advantages Of A RACI Chart
1. Streamlining Communication
Having a RACI in place can be useful to refer back to throughout the life of a project. Rather than involving every single person in every single decision, you can streamline the communication, involve the right people at the right time and speed up sign-offs and decision making.
2. Avoiding People Overload
You know what it’s like when you get opinions from everyone and it becomes a nightmare trying to incorporate everyone’s point of view? Yep, this is where a RACI can be useful. The great thing about having the distinction between Consulted and Informed is that you can separate those involved in feedback, and those that are only updated on progress on the task.
3. Avoiding Work Overload And Silos
We all know how often a Project Manager wears many hats, taking on a lot of responsibility and often covering multiple roles on a project. The RACI chart can be a useful tool to help delegate, and avoid Project Manager burn-out. It also helps mitigate having a single point of failure, where all knowledge and responsibility for a task rests on one person, therefore creating silos.
4. Setting Clear Expectations
You can create a lot of efficiencies using a RACI chart on your project. When you create a RACI at the beginning of a project, it can be useful to help set expectations for who is managing or responsible for work going forward. People involved in the project should be able to clearly see where they need to be involved, and with which tasks. It can also help eliminate confusion by knowing who is ultimately accountable for a task completion. It’s particularly useful to set expectations with more senior stakeholders who are informed on the project: it will allow them to know what information they will receive as part of the project.
When Should I Use A RACI Chart?
Is a RACI chart useful across all projects? The short answer is no. Throwing in too much complexity and process to some small and fast-moving projects can actually slow things down and create blockers. So if your project team is small, roles are already very clearly defined, or a similar structure has been used successfully previously, then consider just assigning tasks to people. You don’t necessarily need to define everyone’s involvement in every deliverable.
However, on larger projects with multiple stakeholders, not using a RACI and clearly defining responsibility upfront can lead to difficulties further down the line, when people ask why they weren’t involved, or you find out there’s another layer of approval needed. It’s a great way to help avoid unexpected surprises and too much involvement from stakeholders along the course of the project, slowing down decisions and work, and the project as a whole. Primarily, if there is any confusion or questions around who is doing or involved in what, use a RACI to agree roles and responsibilities upfront.
Should I Use A RACI On Agile Projects?
The Scrum Alliance published an article which had an interesting addition to the RACI chart to account for the differences in Scrum, the RACI + F. Unfortunately, the article is no longer online but you can find a summary of it here. F stands for Facilitate, so this chart uses the standard RACI plus this extra role for someone who facilitates or coaches. The article argues that adding this role then accounts for how Scrum is run, and roles can be delegated accordingly.
However, this Facilitator role seems best assigned to the ScrumMaster or Project Manager on the project therefore this just adds another layer of additional information to the chart. I’m also a firm believer in keeping the RACI as simple as possible, and adding another role into the mix doesn’t do this.
Use The RACI Wisely On Agile Projects
Another way to look at Agile projects and the RACI chart is that there is already a clear allocation of responsibility and accountability: Responsible being the team working on the product, and Accountable being the Product Owner. Then you just need to identify contributors and those you share information with. A lot of the principles of Agile empower close and regular communication with the team, so the people that need to be consulted are there and don’t necessarily need to be told that they are a contributor. It’s therefore not the case that every Agile project should use the RACI chart. A lot of the roles are implicit if you are following an Agile methodology, such as Scrum. Assess your needs before going ahead with a RACI—remember, they are not necessary for every project.
Common RACI Pitfalls And How To Avoid Them
As I’ve mentioned throughout this article, there are disadvantages with using a RACI chart:
- It can add confusion by a lack of understanding of differences between the terms
- It can be time-consuming to create
- It’s often ignored after approval
- It can add unnecessary complexity to a project
- It doesn’t account for the approvals on tasks or deliverables
1. Project Manager As The Catch All
Often the default can be to think the Project Manager (or Product Owner) is the person or role Responsible for everything. Since they are delivering the project they are ultimately delivering everything within it. Try and move away from this line of thought. Think where the producers of work should be responsible i.e. designers, developers, business directors, client services, heads of departments etc.
2. Confusing Responsible And Accountable
These terms are quite close in definition which can lead to confusion, because Accountable is the role who’s ultimately responsible for the task or deliverable, whilst Responsible is the role doing the task. This is where other types of matrix definitions can help clarify. I give an overview below of some popular alternatives.
3. Tension Between Consulted And Informed
Since Consulted has positive connotations where people assigned this role will feel more included, and that their feedback will be incorporated, this can sometimes cause tensions when people are assigned Informed. They can feel that they are out of the loop or that their feedback is not being heard. The Informed people or groups will see the deliverable once it’s been completed. Make sure this is clearly communicated upfront and feedback on this assignment of roles is agreed to, to avoid problems down the line.
Quick tips to make your RACI chart succeed
- Make sure having a RACI is going to be beneficial for the project, think about how the RACI will be used and why.
- Pick your model, and make sure you understand the terms. Make sure you have a definition for these terms to hand as you work through, or to share alongside the chart.
- Make sure that only one role should be marked as Accountable, and not a full group to make sure that a sole person is the owner rather than multiple people which can lead to confusion and slower decision making.
- Informed isn’t necessarily everyone on the project, it’s those that the task or deliverable will have an impact on, or those with a vested interest.
- Even if you create the draft of the RACI, don’t do it in isolation. Get core project stakeholders to feed in.
6 Steps To Create A RACI Chart
In the graphic below, I’ve summed up the 6 steps to make a RACI chart:
How To Create A RACI Chart
The lovely Meghan McInerny gave a talk at DPM Summit 2017, and made the genius suggestion that the Lord of the Rings is actually a successful project, and the Fellowship is a team. So to make this a little easier to get, let’s use that project as an example. What’s the project? To get the ring to Mordor and Mt Doom. (Just your standard project, right…?)
Step 1: Identify Project Roles
Think about who is involved. First, I created the below table listing out the names at the top. This highlights the first thing to decide when creating a RACI: do you list roles or specific people? Traditionally, you should define the functional roles along the top. However, I think there are cases when using names is better, and that’s often my preference.
Reasons to specify by role:
- If a single person is fulfilling multiple roles
- It avoids the need to update with a change in personnel
- It avoids having a mix of names and broader groups e.g. ‘customer’ or ‘department X’
Reasons to specify by name:
- It’s simpler to define who is involved in the project
- If multiple people are fulfilling similar roles
Roles are more frequently used as often a single person is filling multiple roles. However, if there are multiple people filling one role, and tasks don’t overlap too much it might be best to use names. For my Lord of the Rings example I’ve used names (Wizard as a role might seem a little too out there…), but you can see an example below of roles. Like I said, my preference is to use names to clearly assign the responsibility.
Step 2: Identify Project Tasks Or Deliverables
Review the project and break it down into clear tasks and deliverables. Put these down the left hand column of your chart. I’ve created four tasks for my LOTR RACI (yes, another acronym). Often there will be quite a few more than this, but try not to go too granular else the chart could become too complex to use effectively later. If you’re following a clear list of deliverables for the project you can also look at listing these.
Step 3: Assign The RACI To Each Role And Task
Work through each task and think about the different roles and what they should be responsible for. Every task or deliverable should have a Responsible and an Accountable at least. Make sure there is only one role or name assigned to Accountable—this is really important. Think carefully who should be Consulted whilst the task is ongoing, and who should be Informed once the task is complete. Take a look at my LOTR RACI example below. Frodo is responsible for getting the ring to Mordor. Gandalf, as leader of the Fellowship is Accountable. However, Sam helps Frodo along the way—he is Consulted, i.e. actively involved. (NB you might disagree with some of my assignments below, but hey, I had no stakeholders to discuss and agree this with!)
Step 4: Agree This With Your Team
This is so important—align any assumptions you have made with your team, do not do this in a silo. Get the Fellowship together! If you haven’t gone through roles with people, have a quick chat through how you’ve set up the RACI, and make sure everyone is happy with their roles and responsibilities on the project.
Step 5: Agree This With The Core Project Stakeholders
Set up a call or meeting to agree this with the core project stakeholders. Gandalf, Frodo and the Fellowship couldn’t call each other on their mobiles, so they held a meeting to discuss and agree. Try to keep this as lean as possible to avoid unwieldy feedback, and time-consuming discussions. Think about who this also needs to be communicated with once it’s agreed to.
Voila! There you have your RACI chart. Now I can put that aside and focus on getting on with my project, right? Well, no. This is one of the biggest issues with documents like a RACI: once created they are then forgotten and consigned to a dusty folder on the server, never to be opened again. So how do you make this a useful, working document?
Step 6: Make It Useful Through The Life Of The Project
- When you action a task or deliverable, refer back to the RACI and align on who is responsible for what.
- Make sure what was set out at the beginning of a project, the roles and responsibilities against tasks, are still accurate.
- A good way to do this is to host a version online, using Google Docs or Confluence, or a tool used in your organisation. For more on project management tools, check out this article here. This is a great way to get people more involved with it.
- In your wash-up or post-mortem at the end of a project, use the RACI to see how the assigned roles and responsibilities worked. Did you need as many people involved? Did the people responsible do the task, or did more people need to be involved? Were people consulted and informed at the right times?
On-demand Mini Course
Looking for a RACI template with samples and video lesson?
In the RACI Chart crash course, you learn everything you need to master RACI charts so you can get alignment on responsibilities, ownership and roles for your project. Plus, you can get:
- RACI Chart Template
- RACI Chart Samples
- RACI Checklist
- RACI Cheatsheet
What Are The Alternatives To A RACI?
I’m going to go through a few of the other types of RACI chart, and why they might be used instead.
Probably the most used alternative to the RACI, the RASCI chart stands for: Responsible, Accountable, Supportive, Consulted, Informed. Supportive accounts for the roles on the team that support the one Responsible in completion of the task. The differentiation between Supportive and Consulted, is that Consulted will give information, whilst Supportive will actively participate on the task.
Taking RACI further, the advocators of the CARS model say that it eliminates unnecessary information that the RACI provides. It stands for:
- Communicate – both consulting and informing
- Approve – the approver who makes the decisions
- Responsible – as in the RACI, the person doing the work
- Support – covering the people helping the Responsible person with the work
Some thought is that the RACI model assigns terms which are pretty obvious—i.e. Accountable is often the Project Manager or Product Owner, and Inform—well isn’t this a wider range of stakeholders in the project that you haven’t defined? CARS becomes more specific to actions, and like the RASCI, adds in the Support role when tasks aren’t completed by one role or person alone.
I like the simplification of this one, as it keeps the terms to Responsible, Approve and Support. However, it doesn’t account for the owner of the task which could create confusion.
Relatively similar to the RACI chart, however swapping Responsible for Drivers and Accountable for Approvers, therefore pushing the descriptions more to action based terms. This serves to clarify what those roles will do, where there can be confusion with the RACI matrix.
A variation on the DACI which again focuses more on the actions involved rather than roles, so Contributes, Leads, Approves, Monitors.
Overall, a lot of the variations on the RACI are more about defining the terms with more clarity, or specifying action further so that any ambiguity between roles is erased. There isn’t a huge amount of difference between the models in terms of what they are trying to achieve, so often you can just review the types and then pick which you prefer or which suits the project best.
A RACI Case Study
As an example, I recently worked on a discovery and definition piece for the set up of a loyalty programme, for a fashion brand. The RACI I created you can see below (I had names in the chart, but I’ve changed to roles to make it anonymous.
As you can see, there are a fair few tasks and deliverables, and also stakeholders. As I was creating this RACI, I came across a few conflicts which I outline below:
Split Between Agency And Client
There were a lot of stakeholders client-side and then also internally at the agency I was working at. To avoid creating the biggest RACI in the world, I kept this chart to mainly client-side stakeholders with the agency holding one role, as we had a small team our side. On smaller projects you could likely split out the agency roles as well, but I had assessed the needs for the chart at the beginning of the project and identified that this chart should be used mainly for the benefit of managing the external stakeholders.
Involving Names And Groups
For the senior stakeholders, I grouped them instead of naming them individually. We identified the core team senior stakeholders and then the wider team so they weren’t all merged together, but still kept them in groups to keep things simpler.
Client Product Owner Being Accountable For Everything
Since the PO client-side was such a strong lead on the project, and a central point of cascading information their side, it would have been easy just to make them Accountable for everything. I had to really think this through and try and assign accountability wider than this to avoid creating a single point of failure and a silo. I then discussed this with them to ensure they agreed to the approach. There was still a tendency for the PO to be Accountable for quite a few tasks though.
People often find problems with RACI charts, saying that they are not granular enough, as they don’t break down what the person assigned the role should actually do. However this is not what RACIs are for. Remember, a RACI is not a project plan.
A RACI is a useful document, as long as it’s a joint effort, it’s used past the beginning of a project and it does suit the project. Make sure you assess the needs of your project at the beginning and make the RACI fit for purpose. Make sure everyone understands the terms you are using (whichever type of chart you use!)
So What Do You Think?
Do you use RACI charts, and how useful do you find them? Are there any other versions you use that you simply love (or hate!) and want to share? Post in the comments below to continue the conversation!