You hear the term RACI and inwardly groan. Far from the slightly exciting-sounding acronym, it can often become a bit of a btaeast to create, with headaches caused by trying to work out who should be given which role for every project task or deliverable.
The RACI chart (also known as responsibility assignment matrix, or RACI matrix, or RACI 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 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 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.
In this article
- What Is A RACI chart?
- RACI Chart Advantages
- When To Use A RACI chart?
- RACI On Agile Projects
- Common RACI Pitfalls And How To Avoid Them
- 6 steps to create a RACI chart
- RACI chart alternatives
- A RACI case study
Firstly, What Is A RACI Chart?
Put simply, it’s a tool that identifies roles and responsibilities against tasks within a project.
What does the acronym RACI mean?
The RACI maps tasks and deliverables against roles on your project, and decision-making and responsibilities are allocated to each project role using the above terms. So let’s look a little further at what each of these terms means.
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 minimize the amount of people involved.
Can you have more than one Responsible in a RACI?
If possible, try to have only one person Responsible for a particular task or deliverable in your responsibility assignment matrix. Sometimes, however, the Responsible individual will need support from another person to complete the task, or they may need someone to delegate to. In this case, you can mark more than one person as Responsible.
Be careful to limit this as much as possible to ensure the roles of multiple Responsible people are clear to the individuals.
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 accountable 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 complete the task or deliverable. There will be two-way communication between those responsible and those consulted. This person is often a subject matter expert.
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 give 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.
What is a RACI model used for?
Your RACI model should be used to plan roles and responsibilities in advance so that when it comes time to complete a task or get feedback on deliverables, everyone already knows who is responsible.
A RACI chart should be referred to and used throughout the project to keep track of which team members are responsible, accountable, consulting, and informed on tasks and deliverables. Our RACI chart example holds up throughout a project and helps you keep track of roles efficiently.
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 lifecycle of a project. Rather than involving every single person in every single decision, you can streamline 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 burnout. 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 for 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 role confusion by knowing who is ultimately accountable for a task’s 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 or 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 on roles and responsibilities upfront.
Looking for a RACI chart sample? We’ve got one that you can use for those larger projects to get everyone on the same page with roles and responsibilities.
Should I Use A RACI On Agile Projects?
The Scrum Alliance published an article that 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 and 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 our RACI chart template to keep it simple and focused.
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 project, 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 to using a RACI chart:
- It can add confusion through 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 approval process on tasks or deliverables
So there are many common pitfalls to be careful of when creating a RACI matrix. Here are a few things to watch out for and ways to mitigate:
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 about 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 the 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, people assigned this role will feel more included and trust 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, and 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 on hand as you work through, or to share alongside the chart.
- Make sure that only one role is marked as Accountable, and not a full group to ensure that a sole person is an 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 and team members to provide input.
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 when 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. As I said, my preference is to use names to clearly assign 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 or 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 Responsible and Accountable at least. Make sure there is only one role or name assigned to Accountable—this is really important. Think carefully about 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 on this with!)
Step 4: Agree on This With Your Team
This is so important—align any assumptions you have made with your team members, and 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 on This With The Core Project Stakeholders
Set up a call or meeting to agree on 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 Throughout The Life Of The Project
- When you activate a task or deliverable, refer back to the RACI and align on who is responsible for what.
- Make sure that what was set out at the beginning of a project, and 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 the project management software tool used in your organization. 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?
RACI Matrix Template
I’ve developed a RACI matrix template for you to download. Once you fill in the cells with R, A, C, and I it automatically populates the colours. Feel free to change the colours to what you want!
What Are The Alternatives To A RACI?
I’m going to go through a few of the other types of RACI charts, and why they might be used instead. While our RACI chart template follows the format covered above, you can adapt it as needed to the formats below.
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 the completion of the task. The differentiation between Supportive and Consulted is that Consulted will give information, whilst Supportive will actively participate in 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 think the RACI model assigns terms that 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, but swaps 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 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. Adapt our RACI chart example to your needs.
A RACI Case Study
As an example, I recently worked on a discovery and definition piece for the setup of a loyalty program 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, as well as 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 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 on 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 of 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 on 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 your 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!
Don’t forget to check the RACI chart template we’ve set up – it’s got everything you need to create RACI charts that are clear and that you’ll actually use throughout your project.