This blog will explain how to examine your RACI Chart to determine if it is happy and
healthy. It’s a step you should take every time you create a RACI, before it is finalized.
If you skip this “audit” step, you might publish a RACI out into the wild that is deeply
flawed. We don’t want that!
There are 5-6 best practices to follow when building a RACI chart, and the look back –
or audit – gives you a chance to see if you applied them.
There are two “vectors” to use in analyzing your RACI. The first is a horizontal analysis
– looking across the chart row by row. Each row has a task to be delivered, or a
decision to be made, and you want to assess the state of the project plan with this
analysis.
The second is a vertical analysis, looking at the chart column by column or, more
accurately, role by role. Use this one to see if a team member is overloaded, or if
authority is concentrated in one role (and could maybe be delegated.)
Each analysis identifies different issues and we’ll cover both in this article.
One of the most common mistakes we see people make when constructing a RACI
chart is using “passive labels” to describe the work to be done. For example, if the
RACI describes a training course to be developed, the line might read “Training
Course”. That’s a passive label, because it doesn’t clearly describe a deliverable. If
you change it to read, “Create training course” or “Write script for training course” you
have made it stronger. Imagine that you are delegating every task on a RACI to its R
owner. Every task on the RACI should be something you want a person – or someday
an AI agent – to DO. Being specific and concrete helps you get the deliverable you
need and avoids ambiguity.
Ok, now that we’ve fixed the passive label problem, it’s time to look at the chart row by
row.
1. No R’s. If there is work to be delivered, there must be an R assigned to do it.
If there isn’t, it’s called an “orphan” task (and it won’t get done).
2. Many R’s/No R-Prime: If there is more than one R – which is great, that
means people are collaborating – there should also be an R-Prime role. The R-
prime orchestrates the work being done on that deliverable. That means they
keep track of progress against deadlines, they know who is stuck or needs help,
and whether a piece of the task needs to be re-assigned to someone with more
bandwidth.
3. Too many A’s? For a single activity, or a single decision, on a single row, we
don’t want to see too many A’s because that adds time to the process. The
Project Management Institute adamantly recommends one A per row, but at
RACI 2.0, we don’t think that’s realistic. Important cross-functional decisions
often require more than one sign-off (or A) but we can still work to streamline the
approval process. Can some of the A’s be demoted to C’s, who give input but
don’t determine the final decision or outcome. And please remember that
anyone who can veto a step, or bring progress to a halt, is acting with “A”
authority.
4. Too Many or Too Few C’s? The “C” role is about stakeholder management and
it’s often tricky. If you bring stakeholders in too late or not at all, there can be
delays. But if you include everyone and their cousin, it can slow you down.
What to do? At RACI 2.0, we recommend that you cast a wide net for
stakeholder “C’s” and get a lot of input. However, we also recommend that you
set a deadline for their input (and then remind them of the deadline 1-2 days
before) so that you and the project can keep moving.
It’s worth mentioning that C’s can and often do disagree with one another. The
whole purpose of getting input/advice from a variety of stakeholders is to
consider multiple perspectives. Because you don’t need everyone to agree (that
would be consensus, and it’s a very slow decision-making model) you can push
for speed. It will fall to the “A” to sort through all the conflicting advice and
perspectives and make a final determination.
And by the way, please consider every C role a C/I role, because you want to
go back to everyone who gave you input, and let them know the final
determination. That’s respectful and it’s good for morale even when you don’t
follow someone’s advice. Closing the loop creates credibility so that when ask
for input the next time, they will take you seriously.
5. Deadline? Does every row (activity/decision) have a deadline assigned to it?
RACI 2.0 recommends that every step in the process have a deadline, because
cross-functional work is notorious for slipping timelines. We know that people
have competing priorities – many of them come from their vertical jobs – and
without clear deadlines, horizontal work stretches out like silly putty.
Next, take a look at your RACI column by column (or role by role). Now you are assessing for capacity, for overload, and making sure that assignments make sense.
6. Overloaded Role? Does one role have too many R’s? If a team member is overloaded they may need support. Designate them as the R-Prime and then designate other people to help them as R’s with creating the deliverable. The consequence of ignoring this problem is either slipping deadlines or employee burnout.
This vertical analysis also makes it easier to bring a new team member up to speed, if you need to replace your overloaded employee with another resource. The RACI chart clearly outlines the deliverables they need to produce.
7. Concentrated authority? A vertical analysis gives you a clear way to see if one role has all the “A’s” for decisions on the project. It gives you a nudge to see if some of the A’s can be delegated elsewhere – maybe to the R-Prime role which would then become R-Prime/A. We push decisions “down” in a hierarchy in order to get decisions made as close to the information as possible. Pushing authority down also relieves a bottleneck at the top.
Put your decisions on deadline, too. If you have deadlines assigned to decision rows in a RACI chart (yes, please do!) it will allow you to measure how long it actually takes to make each decision and compare it to the project timeline. You are hunting for patterns here – you want to see if certain kinds of decisions “slip” or if certain functions are slowing down the team. Then you can either create more realistic timelines or give feedback to your laggards. (Pro tip, often your laggards are senior leaders, so best to bring data and some finesse to the conversation.)
To read more about how to audit your entire decision culture, please see the blog, “How to Change Your Decision-Making Culture: The RACI Decision Audit”.
Link in case you need it …