In my previous company, we hired a project manager to handle a complex new venture that would involve multiple stakeholders from across the organization.
Being new, he didn’t know who was responsible for what in the company. So he put together a RACI chart that listed out each task on the project and then asked the project team who was responsible or accountable for each item, as well as who should act as the consulted and informed RACI responsibilities.
This way, everyone involved in the project would know exactly who was responsible for what, and our new project manager could know who to go to for what throughout the project.
In this article, I’ll unpack the potential use case for a RACI chart and I’ll share some tips and tricks for working with stakeholders across your project. As a bonus, I’ll even share a RACI matrix template to use on your project.
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 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.
But first, a quick interlude:
Responsible: Doing The Task
This person actions the task or deliverable. They are responsible for getting the work done or they are noted as the decision-maker. 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 party (an individual, hopefully) 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.
Pro Tip: If you have a lot of support personnel involved in different tasks, you might consider using an adapted version of the RACI chart called the RASCI chart, where the S indicates who is supporting the task or project.
As support individuals are often left out of RACI charts, I find this model super helpful. If you need to identify support personnel, consider adding a supporting role to your RACI chart and make it a RASCI chart! More on this later on in this post—keep reading!
Accountable: Owning The Task
This person or role is responsible for the overall completion of the task or deliverable. They probably won’t do the work themselves, 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.
A great example of the accountable role is the manager of the team that is going to complete the task. If the team doesn’t complete the tasks assigned, the manager is accountable for their work.
Consulted: Assisting with Information & Knowledge
This person, role, or group will provide useful information for completing 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 updates and information provided about project progress or snags the team hits along the way. The informed party won’t be asked to give feedback or review specific items before they are completed, but they will be informed as appropriate. There is typically one-way communication to these roles or groups.
Watch more coverage of RACI charts here!
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.
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; if you’re wrong in your assignments, people will generally tell you.
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 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, such as a Scrum master or agile coach. The article argues that adding this role then accounts for how Scrum is run, and roles can be delegated accordingly.
However, if the facilitator role seems consistently assigned to the Scrum master or project manager on the project, then this model just adds another layer of additional information to the chart.
I’m a firm believer in keeping the RACI as simple as possible, and adding another role into the mix doesn’t do this in the event that the role is well understood and generally fixed. 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.
Many 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. Not every agile project requires use of a RACI chart; in fact, few agile projects I have personally been involved in have needed a RACI chart, largely because the team is small, we talk constantly and everyone knows how they contribute to delivering desired outcomes.
A lot of the roles in an agile project 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.
Why Should I Care? The Advantages Of A RACI Chart
1. 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 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.
2. Streamlining Communication
Having a RACI in place can be useful to refer back to throughout the life cycle 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.
3. 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.
4. 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 burnout as a project manager. 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.
Common RACI Pitfalls And How To Avoid Them
While a RACI can help in many ways, there are a few 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 (but you can manage this!)
- It can add unnecessary complexity to a project
- It doesn’t account for the approval process on tasks or deliverable workflows (consider adding an approver lane, did you just create the RAACI chart??)
So there are many common pitfalls to be careful of when creating a responsibilities 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 to move away from this line of thought, especially if your project manager is not also a developer, graphic or UI designer, copywriter, etc. Think about where the producers of work should be responsible i.e. designers, developers, business directors, client services, heads of departments, etc., and assign the work accordingly.
2. Confusing Responsible And Accountable
The terms responsible and accountable are quite close in definition which can lead to confusion, especially in teams that are not operating in their first language.
When I work with teams in building a RACI for a project, I always take time to educate the team on each RACI role, and we spend extra time on the difference between responsible and accountable. Here’s what I teach them:
You are responsible for a task if it is your job to complete the task. It's on you to get it done.
You are accountable for a task if it is your job to ensure the task is completed. It's on you to be sure it gets done. You might not do it yourself, but you are accountable for it getting done.
Let’s work on an example: You are staying at a nice hotel on a business trip. The housekeeping manager is accountable for ensuring your room is clean and prepared for your arrival. However, they are likely not going to be cleaning your room themselves, unless the person responsible for cleaning the room is unable to complete the task.
The housekeeping manager is accountable for the cleanliness of your room, but a member of their staff is likely responsible for actually doing the cleaning. Let’s hope these roles are not confused next time you need to stay at their hotel!
If this isn’t quite connecting yet, this is where other types of matrix definitions can help clarify. I will 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 simply informed instead of consulted. I find that people on the informed side can begin to feel that they are out of the loop or that their feedback is not being heard (since rarely does anyone get informed and then doesn’t give feedback).
If you run into this problem, consider if the people that you are planning to inform actually need to be consulted. If this isn’t the case, be sure to detail the role of informed is typically a one-way information share. To be informed can happen either synchronously or asynchronous, even via a blog post update. In this case, informed truly means informed, not to also be giving feedback. Keep this in mind when you assign the consulted and informed role in your project.
How To Create A RACI Chart In 6 Steps
In the graphic below, I’ve summed up the 6 steps to make 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. 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 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 a responsible and an accountable at least. make sure there is only one role or name assigned to be 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. (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 action 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?
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. Avoid creating a RACI chart just for the sake of it; be sure it's going to be used if you’re going to spend the time making it.
- Pick your model, make sure you understand the terms, and take time to educate others. Make sure you have a definition for these terms on hand as you work through, or to share alongside the chart. When you get started working with a model and a team, educate them on the model each time you use it, even if some people have heard your spiel before, it's a helpful reminder for those that have already heard it and anyone new to the project will be highly thankful that you took the time to clarify what you’re talking about.
- Make sure that only one role is marked as accountable. A group is not accountable, a person is. That a sole accountable person is the owner. Assigning multiple people as accountable for a task or project is a recipe for confusion, a slow decision-making process, and (hopefully not) disaster. Consider the RACI triangle below for further guidance on how many of each role you should have for any given task. Look! There is only ONE A! Just ONE!
- You don’t have to inform everyone and their best friend and sister. Remember, informed isn’t necessarily everyone on the project or at the company, it’s just those that the task or deliverable will have an impact on, or those with a vested interest. The project as a whole will likely require a different set of stakeholders to be informed at a high-level, you don’t need to capture those details in a task-level RACI, leave that to the stakeholder management plan.
- 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. You can draft it yourself to let folks react to things, however. I often find people LOVE to tell you you’re wrong, so maybe take a first pass at it and show the team and ask them what is right or wrong and iterate on it together! Drafting the RACI will also help you think through the complex project and milestones yourself, you might even uncover some additional project needs along the way.
RACI Matrix Template & Sample
I’ve developed a RACI matrix template for you to download. You’ll also find a sample, checklist, and a cheat sheet. The template automatically populates the colors based on your entries. Feel free to adjust the colors to your liking!
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, and 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 in the task.
Taking RACI further, the advocates 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 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 diagram, 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 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. Adapt our RACI chart example to your needs.
A RACI Example
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, 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 in your next project.
Interested in other flavors of RACI? Learn about RACI 2.0 here.