Hit enter to search or ESC to close
How-to Guides How-to Project Planning PM Skills & Best Practices
RACI Made Simple. How To Create A Responsibility Assignment Matrix That Actually Works
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 free 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 finalised. 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.
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.
How to create a RACI chart. Step 1: Identify project roles
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.
How to create a RACI chart. Step 2: identify project tasks or deliverables.
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!)
How to create a RACI chart. Step 3: assign the RACI to each role and task.
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?
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
So there are many common pitfalls to be careful of when creating a RACI matrix. Here are a few watch-outs for you 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 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.
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.
RACI Matrix Template
A RACI matrix template for download.
I’ve developed a free 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!
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.
A RACI matrix example
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!
Suze Haworth is Freelance Senior Digital Project Manager in London. She has over 10 years’ experience working in agencies, moving through the ranks from her early days in account management before seeing the light, and realising her true calling for project management. She now leads teams on all sorts of digital and web builds, ranging from social campaigns and digital media to large and complex websites.
Suze has managed projects for clients like the BBC, WaterAid, Channel 4, Esso, Lipton Tea, SEAT and Mozilla, to name just a few. She is a certified ScrumMaster, a regular conference speaker, and can also be found posting blogs online. When she’s not managing and talking about digital things (and creating numerous Google spreadsheets), she likes to fuel her obsessions with mountains and coffee.
Project Management Certification: A Complete Guide To Getting Qualified 26/11/2017
DPM Podcast: Happy Holidays For Everyone (With Mackenzie Dysart) 28/11/2018
The Best Productivity Apps: Boost Your Productivity In 2019 28/11/2018
How To Improve Your Technical Skills: 5 Ways For A PM To Upskill 27/11/2018
Most Popular Posts
A Complete Guide To Requirements Gathering 06/11/2018
The 3 Biggest Lies in Project Management 20/11/2018
Project Transition Made Simple (Vacation Has Never Been This Easy!) 13/11/2018
Career Development How-to Guides
How To Improve Your Technical Skills: 5 Ways For A PM To Upskill
PM Skills & Best Practices
The 3 Biggest Lies in Project Management
How-to Guides How-to Managing And Controling PM Skills & Best Practices
Project Transition Made Simple (Vacation Has Never Been This Easy!)
- ianhorsfall says:03/05/2018 at 6:10 am
Thanks Suze, a nice round up off all things RACI.
For me a key element as you suggest is ensuing that members of the team understand the definitions of the roles within the matrix, take their part seriously & resist the urge to avoid responsibility by passing the book or adopting responsibility by committee.Reply
- TE says:25/09/2018 at 4:13 pm
A very useful post indeed. I used this as a refresher in RACI charts as I am stsrting a new role and the RACI is a key document used companywide (unlike within my current role).
I have always found the RACI a useful tool and unfortunately i am all too familiar with some of the pitfalls you have listed. However the most common issue I encounter is with the ‘responsible’ role when an I.T project involves operational users. To use an example to explain this issue, a major back end system change has been implemented but requires throrough operational testing by operational staff. Often the users can becone confused or even feel threatened despite explanation (in extreme cases R’s speak negatively to I’s). This example dates back several years to major business transformation i project managed.
To end on a positive I will study this post again and look to adopt the simple method provided when i begin my new role. All the best, TEReply
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed .
Subscribe to our updates.
The Digital Project Manager is the home of digital project management inspiration, how-to guides, tips, tricks, tools, funnies, training, and jobs. We provide project management guidance for the digital wild west where crazy clients, tiny budgets and stupid deadlines reign supreme.
- Quickly Compare 10 Microsoft Project Alternatives For Creating Gantt Charts
- Kickoff Meeting: The Complete Guide To Starting Projects Right
- 9 Project Management Methodologies Made Simple
- 7 Essential Project Management Skills for 2018
- Why is Project Management Important?
- DPM Podcast: Happy Holidays For Everyone (With Mackenzie Dysart)
- The Best Productivity Apps: Boost Your Productivity In 2019
- How To Improve Your Technical Skills: 5 Ways For A PM To Upskill
- The 3 Biggest Lies in Project Management
- DPM Podcast: Nailing Requirements (With Kelly Suter)
© 2018 The Digital Project Manager.
- How-to Guides
- Agile Project Management
- Career Development
- Leadership Team Management
- PM Hacks Productivity
- PM Methodologies
- PM Skills Best Practices
- Remote Project Management
- Risk Management
- Scope Management
- Stakeholder Management
- Time Management
- The PM Life
- 2018’s Best PM Tools
- Workflow Management Guide
- Resource Management Tools
- Best Marketing PM Software
- Expert Guide To Agile Tools
Responsibility assignment matrix
Jump to navigation
Jump to search
RACI(Q) chart. At least one Responsible and exactly one Accountable person are designated for each task. Optional Consulted and Informed roles may also be denoted.
A responsibility assignment matrix  (RAM), also known as RACI matrix  ( // ) or linear responsibility chart  (LRC), describes the participation by various roles in completing tasks or deliverables for a project or business process .  It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes. 
RACI is an acronym derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed. 
- 1 Key responsibility roles (RACI model)
- 1.1 Role distinction
- 2 Assigning people to facilities
- 3 Alternatives
- 3.1 PARIS
- 3.2 PACSI
- 3.3 RASCI
- 3.4 RASI
- 3.5 RACIQ
- 3.6 RACI-VS
- 3.7 CAIRO
- 3.8 DACI
- 3.9 RAPID
- 3.10 RATSI
- 3.11 DRASCI
- 3.12 DCI
- 3.13 RASCEIO
- 4 Variations
- 4.1 RACI (alternative scheme)
- 4.2 ARCI (decisions)
- 5 References
- 6 External links
Key responsibility roles (RACI model)[ edit ]
R=Responsible, A=Accountable, C=Consulted, I=Informed
- Responsible (also Recommender)
- Those who do the work to complete the task.  There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required (see also RASCI below for separately identifying those who participate in a supporting role)..
- Accountable (also Approver or final approving authority)
- The one ultimately answerable for the correct and thorough completion of the deliverable or task, the one who ensures the prerequisites of the task are met and who delegates the work to those responsible.  In other words, an accountable must sign off (approve) work that responsible provides. There must be only one accountable specified for each task or deliverable. 
- Consulted (sometimes Consultant or counsel)
- Those whose opinions are sought, typically subject matter experts ; and with whom there is two-way communication. 
- Informed (also Informee)
- Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication. 
Very often the role that is accountable for a task or deliverable may also be responsible for completing it (indicated on the matrix by the task or deliverable having a role accountable for it, but no role responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task.
Role distinction[ edit ]
There is a distinction between a role and individually identified people: a role is a descriptor of an associated set of tasks; may be performed by many people; and one person can perform many roles. For example, an organization may have ten people who can perform the role of project manager, although traditionally each project only has one project manager at any one time; and a person who is able to perform the role of project manager may also be able to perform the role of business analyst and tester.
Assigning people to facilities[ edit ]
The matrix is typically created with a vertical axis (left-hand column) of tasks (from a work breakdown structure ) or deliverables (from a product breakdown structure ), and a horizontal axis (top row) of roles (from an organizational chart ).
|Code||Name||Project sponsor||Business analyst||Project manager||Technical architect||Applications development|
|Stage A||Manage sales|
|Stage B||Assess job|
|Stage C||Initiate project|
|– C04||Security governance (draft)||C||C||A||I||I|
|– C10||Functional requirements||A||R||I||C||I|
|– C11||Business acceptance criteria||A||R||I||C||I|
|Stage D||Design solution|
Another example from the maintenance and reliability community
Maintenance Crew KPI RACI Chart.
|Tasks||Maint Supervisors||Maint Analyst||Maint Planner||Maint Technician||Maint Supert||Rel Specialist||CMMS Proj Engr|
|Inputting Failure Data||A||C||I||R||C||C|
|Work Order Completion||R||C||C||C||A||I||I|
|Work Order Close Out||C||R||C||I||I||A|
|QA of Failure Data Input||C||R||I||C||I||C||A|
|Analyze Failure Reports||C||C||I||C||A||R||I|
|Maintenance Strategy Adjustments||C||I||I||C||A||R||R|
|Implementing new strategies||R||I||R||C||A||I||I|
Alternatives[ edit ]
There are a number of alternatives to the RACI participation types:
PARIS[ edit ]
- This is an early version  of a Responsibility Assignment Matrix, with the roles defined as:
- Review Required
- Input Required
- Sign-off Required
PACSI[ edit ]
- This is a version very useful to organizations where the output of activities under the accountability of a single person/function can be reviewed and vetoed by multiple stakeholders, due to the collaborative nature of the culture.
- The person/function carrying out the activity.
- The person/function ultimately answerable for the correct and thorough completion of the deliverable or task, and often the one who delegates the work to the performer.
- The person/function reviewing the result of the activity. He or she has a right of veto; his or her advice is binding.
- The person/function consulted to give advice based upon recognized expertise. The advice is non-binding.
- The person/function who must be informed of the result of the activity.
RASCI[ edit ]
- This is an expanded version  of the standard RACI, less frequently known as RASCI,  breaking the responsible participation into:
- Those responsible for the task, who ensure that it is done as per the approver
- Resources allocated to responsible. Unlike consulted, who may provide input to the task, support helps complete the task.
RASI[ edit ]
- This is an alternative version   of the standard RACI, foregoing the consulted participation and replacing it with:
- Resources which play a supporting role in implementation.
RACIQ[ edit ]
- This is an expanded version of the standard RACI, with an additional participation type:
- Quality Review
- Those who check whether the product meets the quality requirements.
RACI-VS[ edit ]
- This is an expanded version  of the standard RACI, with two additional participation types:
- Those who check whether the product meets the acceptance criteria set forth in the product description .
- Those who approve the verify decision and authorize the product hand-off. It seems to make sense that the signatory should be the party being accountable for its success .
CAIRO[ edit ]
- This is an expanded version,  of the standard RACI, also known as RACIO  with one additional participation type.
- Out of the loop (or omitted)
- Designating individuals or groups who are specifically not part of the task. Specifying that a resource does not participate can be as beneficial to a task’s completion as specifying those who do participate.
DACI[ edit ]
- Another version that has been used to centralize decision making, and clarify who can re-open discussions. 
- A single driver of overall project like the person steering a car.
- One or more approvers who make most project decisions, and are responsible if it fails.
- Are the worker-bees who are responsible for deliverables; and with whom there is two-way communication.
- Those who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.
RAPID[ edit ]
- Another tool used to clarify decision roles and thereby improve decision making overall is RAPID®, which was created by and is a registered trademark of Bain & Company .
- The Recommend role typically involves 80 percent of the work in a decision. The recommender gathers relevant input and proposes a course of action—sometimes alternative courses, complete with pros and cons so that the decision maker’s choices are as clear, simple and timely as possible.
- The Agree role represents a formal approval of a recommendation. The ‘A’ and the ‘R’ should work together to come to a mutually satisfactory proposal to bring forward to the Decider. But not all decisions will need an Agree role, as this is typically reserved for those situations where some form of regulatory or compliance sign-off is required.
- The Perform role defines who is accountable for executing or implementing the decision once it is made. Best-practice companies typically define P’s and gather input from them early in the process
- The Input role provides relevant information and facts so that the Recommender and Decider can assess all the relevant facts to make the right decision. However, the ‘I’ role is strictly advisory. Recommenders should consider all input, but they don’t have to reflect every point of view in the final recommendation.
- The Decide role is for the single person who ultimately is accountable for making the final decision, committing the group to action and ensuring the decision gets implemented.
RATSI[ edit ]
- Another tool used in organisation design or roles analysis.
- Identify who is in charge of making sure the work is done.
- Identify who has final decision power on the work.
- Identify who actually does the work.
- Identify who is involved to provide support to the work.
- Identify who is informed that the work has been done (or will be started)
DRASCI[ edit ]
- A variant of RASCI developed by three Whitehall theorists (Kane, Jackson, Gilbert). This scheme is adapted for use in matrix management environments, and differs only from RASCI in having an additional role of Driver and a narrower definition of Support:
- An individual or party that assists those who are Responsible for delivering a task by both producing supporting collateral and setting timescales for delivery in line with the overarching aim of the individual or party who is Accountable for the overall accomplishment of the objective. The distinction between Driver and Support lies in that the former reinforces and clarifies the parameters of the task on behalf of those who are Accountable, while the latter refers to those who help those who are Responsible in reaching a given goal.
DCI[ edit ]
- A minimal set of decision making categories used in organisation design or roles analysis.
- Decision Maker
- Individual(s) who makes the decision and is accountable for its impact on the business.
- Individual(s) accountable for providing guidance based on functional expertise and experience, highlighting issues and raising alternatives to support the Decision Maker.
- Impacted stakeholder(s) are notified after the decision has been made and who will need to support the execution of the decision.
RASCEIO[ edit ]
To be used when working on governance, risk, compliance (GRC) and outsourcing matters:
- R Responsible
- A Accountable
- S Support
- C Consult
- E Execute (for 3rd parties contracted to execute activities in accordance with a service level agreement)
- I Inform
- O Overview (for key GRC roles, such as risk owner, policy owner – where accountability is devolved, but a role is needed to oversee whether accountabilities all fit together)
Variations[ edit ]
This section does not cite any sources . Please help improve this section by adding citations to reliable sources . Unsourced material may be challenged and removed . (February 2017) ( Learn how and when to remove this template message )
There are also a number of variations to the meaning of RACI participation types:
RACI (alternative scheme)[ edit ]
- There is an alternative coding, less widely published but used by some practitioners and process mapping software, which modifies the application of the R and A codes of the original scheme. The overall methodology remains the same but this alternative avoids potential confusion of the terms accountable and responsible, which may be understood by management professionals but not always so clearly differentiated by others:
- Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.
- Those who assist completion of the task
- Those whose opinions are sought; and with whom there is two-way communication.
- Those who are kept up-to-date on progress; and with whom there is one-way communication.
ARCI (decisions)[ edit ]
- This alternative is focused only on documenting who has the authority to make which decisions. This can work across all sized work groups.
- Authorized to approve an answer to the decision.
- Responsible to recommend an answer to the decision.
- Those whose opinions are sought; and with whom there is two-way communication.
- Those who are informed after the decision is made; and with whom there is one-way communication.
References[ edit ]
- ^ “184.108.40.206 Organization Charts and Position Descriptions”. A Guide to the Project Management Body of Knowledge (PMBOK Guide) (5th ed.). Project Management Institute . 2013. p. 262. ISBN 978-1-935589-67-9 .
- ^ Jacka, Mike; Keller, Paulette (2009). Business Process Mapping: Improving Customer Satisfaction. John Wiley and Sons . p. 257. ISBN 0-470-44458-4 .
- ^ Cleland, David; Ireland, Lewis (2006). Project management: strategic design and implementation. McGraw-Hill Professional . p. 234. ISBN 0-07-147160-X .
- ^ a b Margaria, Tiziana (2010). Leveraging Applications of Formal Methods, Verification, and Validation: 4th International Symposium on Leveraging Applications, Isola 2010, Heraklion, Crete, Greece, October 18–21, 2010, Proceedings, Part 1. Springer. p. 492. ISBN 3-642-16557-5 .
- ^ Brennan, Kevin (2009). A Guide to the Business Analysis Body of Knowledge (BABOK Guide). International Institute of Business Analysis . p. 29. ISBN 0-9811292-1-8 .
- ^ a b Blokdijk, Gerard (2008). The Service Level Agreement SLA Guide – SLA Book, Templates for Service Level Management and Service Level Agreement Forms. Fast and Easy Way to Write Your SLA. Lulu. p. 81. ISBN 1-921523-62-X .
- ^ a b c d Smith, Michael (2005). Role & Responsibility Charting (RACI) ( PDF ). Project Management Forum. p. 5.
- ^ A Guide to the Project Management Body of Knowledge. Project Management Institute. 2000. p. 111. ISBN 1-880410-22-2 .
- ^ Hightower, Rose (2008). Internal controls policies and procedures. John Wiley & Sons. p. 83. ISBN 0-470-28717-9 .
- ^ Baker, Dean (2009). Multi-Company Project Management: Maximizing Business Results Through Strategic Collaboration. J Ross. p. 58. ISBN 1-60427-035-7 .
- ^ Mikes, Joe; Denton, Tara (2011). Training Speeds Continuous Improvement . Life Cycle Engineering.
- ^ Glossary . MG Rush. 2014. Archived from the original on 2004-10-31.
- ^ Bolman, Lee (2008). Reframing organizations: artistry, choice, and leadership. John Wiley & Sons. p. 112. ISBN 0-7879-8799-9 .
- ^ Dickstein, Dennis (2008). No Excuses: A Business Process Approach to Managing Operational Risk. John Wiley & Sons. ISBN 0-470-48110-2 .
- ^ Kendrick, Tom (2006). Results without authority: controlling a project when the team doesn’t report to you. AMACOM Books, division of the American Management Association. p. 106. ISBN 0-8144-7343-1 .
External links[ edit ]
- Comprehensive Series on RACI
- Seventeen Varieties of RACI
- Animation introducing RACI
- Transform Your RACI (Roles and Responsibilities) Into a GANTT Chart
- Understanding Responsibility Assignment Matrix (RACI Matrix)
- RACI Chart Explained
- Project management techniques
- Business terms
- Articles needing additional references from February 2017
- All articles needing additional references
- This page was last edited on 25 November 2018, at 07:18 (UTC).
- Text is available under the Creative Commons Attribution-ShareAlike License ;
- About Wikipedia
- Contact Wikipedia
- Cookie statement
- Mobile view
What is a RACI Chart?
A RACI chart is a useful tool is determining roles within a project and assigning tasks that correlate with each role to the right person at the organization. This matrix maps out a range of information about a project, including workloads, assignments, roadblocks and results. RACI charts serve to simplify project management and provide clear expectations of what each member of the organization must meet for the project to be successful.
Overview of RACI Chart
R – Responsible: Shows what each employee is expected to do for tasks and when their part of the project is due. It also communicates who “owns” the project.
A – Accountable: Identifies who has the final say on completed tasks. This is the decision-maker who takes appropriate action in notifying others or approving work when tasks are completed.
C – Consulted: The person (or persons) who will be made aware of changes, problems, task completions and other issues. They provide feedback and are a source of reliable information throughout progress of the project.
I – Informed: Identifies who must be notified of updates to the project, from budget changes to progress on timeline and overall results.
Take a look below for what a typical example of a RACI chart can look like.
What are the benefits of using a RACI chart?
Clear overview of employee responsibilities: RACI charts serve to limit confusion and wasted resources on a project. This includes balancing heavy workloads, serving as a platform for conflict resolution and redistributing tasks when necessary. In addition, new employees can use this information to see where they fit in an organization, and what’s expected of them in their roles.
Big-picture snapshot of how a company functions: A RACI chart is great way to take a top-level look at how an organization operates. These tools also are key in identifying roadblocks in communications , stunted workflows, and issues that continually arise by showing clearly where the breakdowns in efficiency are occuring.
Simplifies project management: From the perspective of a project manager, a RACI chart shows clearly who’s accountable for what and who reports to who. This limits confusion for the employees they’re managing and helps free managers with a lot on their plates to focus on their work and avoid distracting questions.
Improve day-to-day productivity with Advisicon
Advisicon has the tools and experience to get your business blasting to the next level. We offer consulting services for business software , in-person and online trainings and support to reduce inefficiencies and boost productivity. Contact us to learn more about how we can improve the overall effectiveness of your daily processes.
- Mike Fink
Leave a Comment
- Case Studies
- MS Project
© Advisicon. All rights reserved.