"Who signs off on this?" Asked in week three, the question is a healthy one. Asked in week twelve, forty-eight hours before a delivery, it is an expensive one. Nothing changed between the two except the moment somebody noticed that nobody had the answer.
Wellingtone finds that only 45 to 50% of organisations consider roles and responsibilities to be clearly defined. Source: Wellingtone, State of Project Management 2021. One organisation in two runs on the implicit, and discovers its grey areas at the moment they block something.
A RACI matrix exists for exactly that: writing down who does the work, who approves it, who gets asked and who gets told, before the question comes up under pressure.
The confusion that wrecks the matrix: responsible is not accountable
Before the four letters, one point of vocabulary. It looks trivial. It is behind most of the matrices that end up useless.
Responsible is the person who performs the task. The doer. Not the person who answers for it, not the person who decides, not the boss. The person who does the work.
The person who answers for the result, the one the board comes looking for when things go wrong, is the Accountable. In everyday speech that is the one most people would call "responsible", which is precisely where it goes wrong.
The consequence is predictable. A project manager reads "R = Responsible", feels responsible for the project, and puts an R on every line. They have just declared themselves the doer of everything, and left the accountable column empty. The matrix now shows the exact opposite of reality.
R is the doer. A is the approver, and A is what most people mean when they say "responsible".
If your team keeps tripping on this, drop the letters from your column headers and write the verbs instead. A matrix headed "Does / Approves / Consulted / Informed" loses the acronym and gains clarity. That is a good trade.
Role and responsibility are not the same thing
A role describes a position on the project: project manager, developer, subject-matter expert, sponsor. It answers "who is who".
A responsibility describes what that position has to produce on one specific task. It answers "who does what, on this line".
One role therefore carries different responsibilities depending on the task. The project manager does the scoping, approves the test plan, and is merely informed about the deployment. Three lines, three responsibilities, one role. That variation is what the matrix makes visible, and what an org chart will never show.
The four letters
- R, Responsible, the doer. They perform the task and produce the deliverable.
- A, Accountable, the approver. They validate the doer's work and settle disagreements. They answer for the result to the rest of the organisation.
- C, Consulted, the adviser. They bring expertise and their opinion is sought before the decision. They do not make it.
- I, Informed, the recipient. They are told afterwards because the task affects them, without taking part in it.
You will run into the RASCI variant, with an S for Support: someone who helps the doer without carrying responsibility for the task. Useful when one team lends resources to another, redundant the rest of the time.
The rule that matters: one R and one A per task
This is the point to hold on to, and the one most matrices break by the third line.
A task has one doer. Exactly one. And one approver. Exactly one.
The moment a line carries two Rs, the task has no owner. It has two people who each assume the other one is on it. Both move forward believing the uncovered part belongs to the other. Nobody is lying, nobody is dodging, and still the task does not advance: it lives in the blind spot between two boundaries nobody drew.
Two As do the same thing to the decision. Each waits for the other to call it, out of deference or caution. The call eventually escalates a level, a week late, and lands with someone who knows the subject less well than either of them.
That is the hot-potato mechanism, and it does not come from the people. It comes from the matrix.
When two names both look legitimate on the same line, the conclusion is almost always the same: the task is too big and needs splitting in two. Two tasks, two doers, two approvers, and the fog clears. It also makes a good test of your work breakdown: a WBS taken down to the right level produces single-R lines without effort.
On this matrix, every line carries exactly one R and one A. That is what yours should look like once filled in. A line with two of either is a line to rework, not a complex line.
Genuine co-delivery does happen, of course. Two developers work on the same feature. But then one of them carries the R and the other is Support, or C. Somebody has to be able to say "yes, it is ready" without checking with anyone.
Telling R from A in one question
The confusion clears with a single question: when it goes wrong, who has to explain themselves to the board?
That person is the A. The one who spent the nights on it is the R. They are frequently two different people, and that is healthy: doing the work and answering for it call for neither the same position in the organisation nor the same availability.
When to build it
The matrix gets filled in once the content of the project is known, and before any dates are committed. It slots in here:
- The work breakdown structure splits the project into deliverables and tasks.
- The RACI assigns responsibilities to those tasks.
- The dependency network orders the tasks against each other.
- The critical path falls out of it, then the schedule.
The order matters. Assigning responsibilities before breaking the work down means handing out roles over content that does not exist yet. Doing it after committing to dates means discovering that a key approver is on leave during acceptance testing week.
How to fill it in
A two-way table: tasks down the rows, parties across the columns. One letter at each crossing.
So you are not starting from an empty grid, the RACI matrix Excel template uses this structure and flags on its own any line that does not have exactly one doer and one approver.
Columns can carry people's names or entities: a department, a function, a supplier. Entities age better, names are clearer. On a short project, use names.
Four questions are enough to fill a line:
- R: who produces the deliverable? One name, not two.
- A: who approves it, and who calls it if it stalls? One name, not two.
- C: whose input would be missing if we decided without them?
- I: who would be annoyed to find out afterwards?
The last two wordings are deliberate. "Who should we consult" attracts courtesy lists. "Whose input would be missing" weeds out the people added to C out of politeness, who slow the circuit down without adding anything to it.
A worked example, on six lines
Rolling out an HR tool. Four parties: HR, who commissioned it; the project manager; IT; and the line managers who will use it.
- Gathering requirements: HR does it, project manager approves, line managers consulted, IT informed.
- Specification: project manager does it and approves it, IT consulted, HR informed.
- Configuration: IT does it, project manager approves, HR consulted.
- Acceptance testing: HR does it and approves it, project manager consulted. The requester signs off on what they asked for.
- Training the managers: project manager does it, HR approves, line managers consulted.
- Go live: IT does it, project manager approves, everybody informed.
Two things show up once the table is written. The project manager approves four lines out of six: consistent with the role, but that is four sign-offs on one person's plate, and a bottleneck to watch. And on acceptance testing, HR both does and approves: normal enough, the requester signs off on what they commissioned, but no outside eye is on that step.
Neither of those was visible before the table. That is the whole point of the exercise.
What the matrix is actually for
It is less about organising than about making the gaps visible. A line with no approver flags a decision nobody will take. A column full of Cs points to someone consulted everywhere and trusted with nothing. A person doing eight lines out of twelve announces an overload the schedule never showed.
It also gives people something to say no with. The PMI puts poor or inadequate communication among the leading causes of failure, at 29% of projects that fail. Source: PMI, Pulse of the Profession 2018, 4,455 practitioners, see the PMI standards. A request that lands straight on a doer, bypassing their approver, now has somewhere to be sent back to, and it stops being a question of personalities.
Where it stops working, and it does
On a three-person, six-week project, the matrix adds a layer of administration for no gain. Everyone already knows who does what. It earns its place when several teams or entities meet, and the overlaps start producing blind spots.
More seriously, RACI assumes an individual decision, with a single identified approver. That is an assumption, and it does not fit every organisation: teams that decide collectively, agile ones in particular, are right to read it as rigidity. On that ground, the matrix is usefully confined to the interfaces between teams, where responsibility has to be named, leaving the inside of each team to organise itself.
Finally, a matrix that is not kept up to date becomes wrong at the first reorganisation, and a wrong matrix is worse than no matrix: it suggests the question has been settled.
Keeping the RACI matrix in Orchesia
In Orchesia, the matrix is not a file sitting next to the project: it is a view of the project. The "RACI" tab crosses the tasks from the breakdown, down the rows, with the team members, across the columns.
Picking a letter in a cell assigns that person to the task with that role, and clearing the letter removes them from it. The matrix and the real distribution of work cannot drift apart, which takes care of a good part of the maintenance problem.
Each role also carries a default workload, adjustable per project: 100% for the doer, 20% for the approver, 10% for the consulted, nothing for the informed. The percentage can then be tuned cell by cell, and it turns up in each person's workload, period by period and across every structured project, time off included. A project manager approving four lines out of six no longer sees four As: they see what those sign-offs weigh in their week.
On a simplified project, the same matrix groups items by phase and updates live while other people are working in it.
In short
A RACI matrix crosses tasks with the people involved to assign four responsibilities: do, approve, advise, be told. It is built after the work breakdown and before any commitment to dates.
Two rules are enough to make it useful. One doer and one approver per task, failing which the matrix organises the very hot potato it was meant to prevent. And never read R as "the person responsible": Responsible is the person who does the work, Accountable is the person who answers for it.
What remains is checking that those responsibilities fit inside each person's available time. That is the subject of the planning that follows from it. In Orchesia the two are read in the same place: the letter placed in the matrix carries a workload, which adds to that person's.
