← Insights

Teamwork

How to build a RACI matrix that ends the confusion

July 2026 · 6 min read

Every stalled project produces the same two sentences, usually in the same meeting: "I thought you were doing that" and "nobody asked me". A RACI matrix exists to make both sentences impossible - tasks down the side, roles across the top, and in each cell one of four letters that says exactly what that role does for that task.

It takes an hour to build and it fails in predictable ways. Get the four letters genuinely understood and the three classic conflicts designed out, and it becomes one of the highest-value single pages a project can own.

What the four letters actually mean

R - Responsible. Does the work. There can be several Rs on a big task, but there must be at least one; a task with no R is a wish, not a plan.

A - Accountable. Owns the outcome and answers for it - approves the work, carries the consequence, and is the single throat to choke when the task stalls. The load-bearing rule of the whole method: exactly one A per task. Not zero. Not two.

C - Consulted. Their input is sought before the work is done or the decision made, and it is two-way: they contribute, and their contribution can change the outcome. The test engineer consulted before the design freezes is a C doing its job.

I - Informed. Told after - one-way, for awareness. Nobody waits on an I.

The A/R distinction confuses people most, and hierarchy is the quickest illustration: the quality manager may be Accountable for the internal audit programme while an engineer is Responsible for running the audits. The manager cannot delegate the accountability; they can and should delegate the work.

The three conflicts that break a RACI

No Accountable. The task everyone assumed someone else owned. This is precisely the "I thought you were doing that" failure the matrix exists to prevent - and it is invisible until the deadline passes, unless the matrix itself flags empty-A rows.

Two or more Accountables. Feels generous, works like zero. When two people are accountable, each privately assumes the other is watching; joint accountability is no accountability with better manners. Where two departments genuinely share a stake, split the task until each piece has one owner.

No Responsible. An owner with nobody to do the work. The A will discover this at the worst possible moment.

These three checks are mechanical - which means a spreadsheet can run them for you on every row, live, instead of relying on someone eyeballing a wall of letters. That single feature converts the RACI from a drawing into an instrument.

Building one in practice

• Tasks are deliverables, not activities. "Approve the validation protocol" can have one A; "quality stuff" cannot. If a row needs two As, it is two rows.
• Roles, not names. "Process Engineer", not "Dave". People move; the matrix should survive them. Keep the role count honest too - a matrix with fifteen columns is an organisation chart having an identity crisis.
• Fill it as a group. The disagreements the workshop surfaces - two people who both believed they owned sign-off - are the actual product. Every argument had in front of the matrix is an argument not had at the deadline.
• Watch the column totals. Count each role's letters when you finish. A role that is R on fourteen tasks is your bottleneck-in-waiting; a senior role that is C on everything will slow every decision to their calendar. Rebalance before launch, not after.
• Keep Cs scarce. Every C is a loop that must complete before work proceeds. Consult the people whose input changes outcomes; inform the rest.

The matrix is finished when every row has exactly one A and at least one R, and every column total looks like a workload someone could actually carry.

Then publish it where the work happens and treat it as live: when a task stalls, the first question is "what does the RACI say?" - and if the RACI is wrong, fix the RACI. A matrix that stops matching reality stops being consulted, quietly, and the two sentences come back.