How to Build a RACI Model in Three Simple Steps

Erika Flora
Written by Erika Flora

Having trouble getting projects done on time?  Don’t know who’s doing what in a critical business process? Wondering who to turn to when you need advice?  Need to know who should be on that project progress email report? We have the answer for you.  It’s called a RACI chart. And we’ll teach you how to create one in three simple steps.

A RACI chart is a tool or matrix used to map the roles and responsibilities of stakeholders within a process or activity.  To borrow a time-honored sports metaphor, a RACI chart lets you know who’s on first and what’s on second by defining somebody who is responsible, accountable, consulted and informed.

Without a RACI chart, there will be weeping and gnashing of teeth among your team. Why? Because it’s a simple, effective way to communicate the timing and accountability around work to be done. It can be applied within or across projects, processes, or teams, and is often your only line of defense against the common problem of work not getting done correctly (or at all) due to confusion around who should be doing what, when.

Basic RACI charts are easy to create. Like, draw-on-the-back-of-a-napkin-and-snap-a-picture-of-it-with-your-phone easy. They can get a little trickier when applied to complex tasks or processes, but even those charts are built on the same principles. What follows are three simple steps to get your team moving in the right direction with a RACI chart.

RACI Model Example
Write down what needs to get done 

Start by jotting down the main areas of responsibilities or specific tasks that need to be completed, moving top to bottom. You can base your RACI chart on an ITIL process, which is typically what we help teams build, but the tool is highly flexible and can be tailored to a variety of situations and levels within an organization. We’ve helped customers create RACI charts at a very strategic level (Hey look! A free RACI Model template!), but they also work well at a more granular level, defining day-to-day activities of individual team members.

For example, we recently put a RACI chart to work for a customer dividing one large department into two teams. The transition was causing a good deal of confusion among team members – they were struggling to understand the hand-off of responsibilities from one team to the other, as well as what each of the groups did. They put together a RACI chart that helped alleviate the confusion and communicate clear roles and responsibilities, both internally and with people who interacted with each team.

They work well going in the other direction too.  For example, over the past several years we have witnessed more hospital mergers and acquisitions than you can shake a crutch at.  One of the first things hospitals often do when they merge is to consolidate IT departments and service desks.  To be sure, a RACI chart won’t give anybody the “warm and fuzzies.”  But it can help to relieve stress and make the transition process go more smoothly.

Write down who needs to be involved

Everyone who will have a role or be involved with the project, process, etc. in any fashion should be listed from left to right in your RACI chart. A role, simply put, is any “hat” you wear.  Your title may be Service Desk Manager, but you likely wear a lot of different hats throughout your day, including CAB member, solver-of-problems, and occasional hero.

When we say “everyone,” think broadly.  List the person who owns the process, service, or product.  List any managers who may be involved.  Jot down all the roles and/or people on all the teams who do the work on a daily basis.   Write down the roles and/or names of people who provide requirements to you, test your work, approve your work, give you meaningful advice, and even those who do not “do” anything per se but need to be kept in the know.

NOTE: Many people are tempted to list individuals’ names throughout the document when creating their first RACI chart. Initially, this seems like a sensible approach (Joe is responsible for this task). What’s important to remember, though, is that the people who fill certain roles frequently change, making your RACI chart difficult to keep current over time. If you stick with roles, you’ll have a much easier time keeping documentation up-to-date as responsibilities change and teams grow.  And remember, a job title is not necessarily the same as a role.  It is common that roles become delegated or re-allocated from one position to another within an organization.  (Hopefully, you are “off-loading” and not “on-loading” roles.)

Fill in the body of the RACI Chart

RACI is a four-letter word (OK, acronym) for fun.  The fun really starts after you’ve completed steps one and two. Now you can populate the body of the table with ‘R’, ‘A’, ‘C’, and/or ‘I’. Here’s what that means:

‘R’ is for Responsible

This is the person (or people) doing the actual work. Think of this as the worker bee.  A manager can also be in the ‘R’ position if they are actually helping to do the day-to-day work.

‘A’ is for Accountable

This is the person who will be held accountable for the work getting done. In a small organization, the same person is usually Responsible and Accountable (denoted as ‘A/R’). In a larger organization, the manager is often the Accountable party, with the folks who report to this manager being Responsible for doing the work. When you hear Accountable, think “one throat to choke” or “one back to pat”. Where does the buck stop? With the Accountable person. One rule here: You should have exactly one person accountable for any activity. If you have more than one, it becomes easy for people to assume someone else will take ownership. Or, if two “owners” are identified, this inevitably sets up a situation for future conflict when the “owners” disagree on an issue.  We often see two owners identified when one person actually has expertise or decision-making authority and another is being designated as “honorary” owner (even if this isn’t actually what is said).  Just don’t do it! It’s for your own good. On the other hand, don’t fall into the trap of the “A-Hole.”  if you don’t have anyone designated as Accountable, no one will take ownership.

‘C’ is for Consulted

This is the person (or people) from whom you need feedback throughout the process or project. They’re the subject matter experts whose brains you’ll need to pick for advice or technical guidance. Think two-way communication when you consider who should be listed here.

‘I’ is for Informed

This is the person (or people) who need to be kept informed. If you change a process, for example, you probably need to let someone know it will change how they work. Being Informed is one-way communication

Pro Tips:

A RACI chart will illuminate things about your project/process that you may not have realized were present. Here are some things we’ve found to be really helpful to look at as you create RACI chart:

Too many RRRRRRRs

Look for places where you see the same role Responsible for numerous activities. If you are overloading one person or team with too much work, it may create a bottleneck to getting work done (and wear out your people).

Your CIO is not the A-Role

Slow down when you say that one; otherwise, unintended consequences.  But seriously, some organizations like to make the CIO or CEO the “A” for everything, the theory being “the captain goes down with the ship.”  Yes, your CIO may have a sign on his or her desk, a la Harry Truman that says “the buck stops here.” But we strongly encourage you to pass the buck in this instance.  In other words, assign somebody the “A” role who has enough understanding of how a process or project or initiative works on a day-to-day basis to make a competent decision.  Nothing against our CIO, but I seriously doubt they know the ins and outs of how stuff gets down from day to day (and I wouldn’t expect or want them to).  Also, implicitly, the “A” role must have the authority to make a decision.  This will vary from organization to organization – it could be a director or a manager in yours – but it is almost certainly not the CIO or CEO (unless you are working on a governance RACI chart).

Accountability Cannot be Outsourced

It is possible to hire somebody (even a third party) to be responsible for carrying out a particular task or even an entire project.  But, ultimately, accountability rests within your own organization. Blame the vendor is a popular game to play (and sometimes, alas, the vendor can stand to improve), but your customers, be they internal or external, don’t give a fig about how poorly your vendor performs.  They care about how you are going to make it right.

A or R?

Who me?  Am I the A-role?  Or maybe I’m just an R?  Not to belabor the point; but it’s a point worth belaboring.  It is indeed possible for the owner or “A” to also be an “R.” This often occurs in a small organization or on a small project.  But, often the A and R roles are split. Who is going to get the raise if your project does well?  Who is going to get the boot if it fails?  This should be the person in the A-role.

In some organizations, people are reluctant to claim the A-role.  This normally speaks to a situation where something in the organizational culture punishes failure severely and doesn’t incentivize prudent risk-taking.  Because the “A” could be wrong, the “A” is always assuming risk.  To paraphrase the cult-classic flick, “Office Space,” “the problem is with motivation.”  There is something wrong with the Risk-Reward mechanism.  Nevertheless, somebody has to be the “A.”

A person who comes away from a project or team meeting with a lot of take-away tasks – they have R written all over them.

The Unappreciated C

“She always asks for my advice, but never takes it.”  Ever hear that from one of your teammates?  (Maybe it was you who said it.)  Your “Cs” are your subject matter experts.  You need their wise counsel.  Needless to say, you can’t always take their advice.  Avoid the unappreciated C by setting appropriate expectations up front – “I really want your input on this, but don’t be sore at me if we don’t take your advice.  They are a lot of conflicting priorities on this project.”

The Proliferation of Cs

Look for places where you have a lot of Consulted roles. We see this happen with some of our Higher Ed customers and other collaborative environments. If too many people need to be consulted before a decision can be reached, it may put you in a position of analysis paralysis, which guarantees work will not get done in a timely manner.

I-I-I, too many Is

If you are taking an ITIL or PMP exam, you’ll want to think broadly in terms of identifying stakeholders or “informed” parties.  This is generally good advice. However, there are real world environments where over-communicating with “I’s” can lead to trouble.  For example, just try sending a blanket email to a group of doctors and nurses telling them that a non-critical system that they rarely use will be offline on a Sunday from 3 a.m. to 4 a.m. People you haven’t seen since that last holiday party will call you complaining until your ear has a permanent receiver ring impressed upon it.  Communicate.  Yes!  Open cans of worms?  No!

Some organizations like the idea of using RACI charts but find that when they get down to actually building them, they can be hard to do.  Hopefully, the hints in this article help you overcome some difficulty.  Normally, the biggest challenge is that people in the organization are not used to thinking about the roles they perform in a structured way, and it can take a little time to get used to this.  But a difficult start is not a reason to give up.  Stick with it.

Now that you've got the hang of it...

Download our free RACI Model template and get started!
Download the template

Originally published January 01 2018, updated December 12 2019