Operations Communication Scripts Communication: push, pull, and interactive approaches What the heck is a RACI? Process and workflows Risk Management Favourites

What the heck is a RACI?

A short but sweet descrip­tion of who’s respon­si­ble, account­able, con­sult­ed, and informed on your projects

The old way

RACIs are a traditional way of tracking various people’s roles in their projects. It tends to follow a very linear, waterfall approach (only one person fulfills one role and phases must finish before another begins). A RACI should tell you who’s accountable, responsible, informed and consulted on your project. Usually, we create a chart and outline our project roles & tasks, and then use the letters R, A, C, or I to initial who does what. RACIs still offer a lot of insight into our project roles if we break them down to their components. So, let’s make it work for your digital projects in a more agile environment.

Screenshot of an old-style RACI spreadsheet

The new way

Internally, your team might have a pretty good idea of who’s responsible for design, development, content, and admin-related tasks, but we often forget to clarify our external stakeholder involvement and respective roles. Will your Point of Contact (POC) be informed and consulted, or just informed? Will your POC of have a boss who will be consulted or informed? Is anyone else accountable for tasks on this project? Who will take the fall if it fails?

The more you know about these stakeholder relationships, the better you can wrangle their expectations and limit mystery voices at the table that will derail you. So forget about complicated spreadsheets, build these RACI roles into your communication plan so you can reference it when things start warming up. Your team and clients will thank you.

R is responsible

This is the person on the team who does the work.

When we’re talking about responsibility, it’s all about who’s doing the work. So when you’re thinking about project tasks, get clarity about whether this work happens on your team or outside of it. Remember to break requirements down small enough and assign them so only one person can be responsible for one task at a time. Different folks can be working on complimentary things in tandem (e.g. code branches), but each knows where their work stops or combines. This allows us to stay agile and collaborative, while still making sure everyone’s clear on who’s working on what/when.

A is Accountable

Internally, this is the project manager. Externally, it’s often your POC.

Who’s accountable that the work gets done? The project manager almost always. When heads are on the line, it’s the PM who is accountable for the project direction and all decisions made. It’s a huge responsibility, so it’s important for you to define project success and failure before you start. Remember that externally, your POC will have her own chain of command to impress. How much power does she really have? Is it real? Or is she a puppet controlled by someone higher up. Hierarchies tend to build fear into this accountability role, so have open conversations early and often to clarify how the power structure works. Find out who can kill the project and who can save it, and build strong allies with your POC as it’s often her head rolling on the other side of the project line. She’s trying to protect her position. Sudden changes to her role or multiple voices disagreeing at the table can tip you off. Beware: Surprise voices are flipping the chain of command and will balloon the project scope or stall it out.

C is Consulted

This is the person who needs to know things before a decision is made.

Your boss, your team, your external stakeholders. They all need to be consulted at various points in the project. The more collaboratively you work, the more folks you’ll have to consult with before making a decision. There are good reasons for this and bad. The good? You’ll all come to unanimous decisions that support your project goals and you decrease misunderstanding. The bad? It takes a lot longer and can lead to stalemates. Word to the wise: define your business and project goals before you start so all decisions must support them. Limit your external stakeholders or charge for the additional voices at the table. Make sure your team understands each other’s roles so consulting isn’t about ego, it’s about doing great work.

I is Informed

This is the person who needs to know things after a decision is made.

Decided to add a new resource? Adjusted a deadline? The key to knowing who should be informed is asking: how will this impact [name]? If it’s minimal and you’ve all agreed to direct the flow of communication before you start, don’t bother people with the bits. Document the decisions, but don’t bother people. If the impact will make someone say, “Hey, why did we change or approve this?” or “I wish I’d known that…” you should make sure you inform the right folks. Teams often get trapped in mini conversations where they make decisions with one or two other people but forget to inform the rest of the team. This can quickly blow up in their faces. Warning! People who are initially informed often try to slide into the ‘consulted’ role—it just feels nice and they want a say. This leads to mystery voices that take you away from your project goals. Call attention to this and adjust your scope if you have more voices at the table. Tell the right people the right things at the right times—and make sure everyone agrees what these things are before you start.

Get our RACI templates

Sign up for our newsletter and get your projects on track with our RACI template pack. You’ll get:

  • A Notion template
  • Google sheets template
  • Printable PDF guide
The cover of our RACI PDF guide

Related resources

Double sided arrow

Communication: push, pull, and interactive approaches

How to create ace interactions with stakeholders, with examples

Our project management manifesto

What it means to be a resilient digital project lead

Talk to us.

Learn more about our programs or just say hi.