The RACI Matrix: How to Stop Accountability Getting Lost Between Departments

What is a RACI matrix?

A RACI matrix is a table that lists outputs or decisions in its rows and job roles in its columns, and assigns one of four roles to each cell. The Project Management Institute (PMI) describes them as follows: ^[1]

• Responsible: whoever actually does the work; there can be several.
• Accountable: the one person who owns the outcome and answers for it.
• Consulted: those whose input is sought before the work is complete.
• Informed: those kept up to date on decisions or progress afterwards.

PMI links the matrix to stakeholder management: stakeholder analysis identifies who affects or is affected by the work, and the matrix turns that into clear ownership of specific tasks and decisions. ^[1]

Why one Accountable owner per row?

The core rule is that each task or output has one Accountable owner, even if several people are Responsible. Two names in the Accountable cell create disputes; no name means the work will fall between departments. ^[1]

The UK Government Functional Standard for project delivery (GovS 002) states the same principle: there should be single-point accountability for every component and activity, and accountabilities and responsibilities should be defined, consistent and traceable across management levels. ^[2] In other words, a department’s matrix should not contradict the one above it.

In matrix structures, where staff report both to a functional department and to a project, settling who is Accountable sometimes needs a decision from the sponsor. ^[1]

How do you write the rows?

Write each row as something that produces a verifiable output: “Approve the need for access” is better than “Access”, and “Issue the purchase order” is better than “Procurement”. A vague row makes every role assignment both right and wrong at once.

Note that each wording in the second column contains a moment someone specific can be asked about: was the request approved or not, when, and by whom?

Use job titles in the columns rather than names, and keep a separate list of post holders. Limit the matrix to work that needs coordination across more than one department or that repeatedly causes disputes; tasks internal to one team do not need a row.

Then take the draft to the people with authority before using it. A matrix written by the project coordinator alone reflects their understanding, not the departments’ agreement.

How do you handle sequential approvals and separation of duties?

When a procedure requires two approvals in sequence, such as manager sign-off followed by a security review, give each approval its own row with its own Accountable owner. Merging them puts two Accountable owners in one cell or hides one of the approvals.

Respect the principle of separation of duties: no single user should hold enough privilege to misuse the system alone, as when the person who approves a payment is also the one who prepares it. ^[3] If the matrix puts request and approval in the same role, it reflects a control weakness, not just a mistake in the table.

Check that the Accountable owner actually holds the delegated authority for the decision. The UK standard requires governance frameworks to set authority limits, with decisions beyond them referred upwards. ^[2]

How do you build the matrix step by step?

1. Choose the scope. One procedure or service where disputes recur, not the whole organisation at once.
2. List the outputs and decisions. From start to finish of the procedure, as a verb plus an output, with each approval in its own row.
3. Identify the roles involved. The job titles that actually appear in the procedure, plus those usually consulted or informed.
4. Fill in the Accountable column first. Do it for every row before the other roles, because it surfaces the real disagreements early.
5. Complete Responsible, Consulted and Informed. For every consulted party, ask whether their view actually changes the decision.
6. Review with the people who hold authority. In a single session with representatives of each department, where disputed rows are settled.
7. Publish and link. Make the matrix part of the approved procedure, not a separate file kept by the project coordinator.

A common mistake is to fill the matrix with a “C” for every department just in case, turning consultation into an unspoken approval that slows every decision. Another is to make the most senior manager Accountable for every row; that does not clarify responsibility, it means every decision will wait for them.

Hypothetical example: an urgent access request

Hypothetical example: a Gulf organisation needs to give an employee access to a system holding sensitive data. The employee’s manager approves the need, the security team reviews the sensitive access, and IT applies it once approved.

The routine request went through without problems. But when an urgent exception was requested outside working hours, it emerged that the matrix did not say who could approve bypassing the security review, or where that approval would be kept. The organisation added a separate row, “Approve urgent exception”, with a single Accountable owner, and another row, “Retrospective review of the exception”, within a set period.

The lesson is that a routine case rarely exposes a weak matrix, because everyone knows what to do from repetition. What exposes it is the unusual or urgent request, or one that falls between two remits.

How do you know the matrix works?

Try it on two requests: a routine one and one the departments have argued about before. Note where the answer stops at “we are all responsible”; that is the row that needs a decision.

Warning signs include a row with no Accountable owner, a row with two, or a long list of consulted parties that slows every decision. PMI suggests scaling consultation to risk: full review for regulated or externally binding content, lighter review for routine updates. ^[1]

When should you update the matrix?

Keeping roles accurate on live work is harder than drawing the grid in the first place. ^[1] Update the matrix when the structure, the approval route or the scheme of delegation changes, or when a task moves to an automated system. Show the date of the last update on the matrix itself so users know whether it still applies.

When a task moves to an automated tool or an AI agent, do not delete the row; amend it. PMI suggests making the agent Responsible only for tightly bounded tasks, keeping a human Accountable on every row, and adding rows for governing the agent itself, such as who reviews its outputs and who changes its permissions. ^[1] Automation changes who does the work, but not the need for someone to answer for the result.

Conclusion

The RACI matrix is a simple tool whose value lies in the decisions it forces: one Accountable owner per output, separate approvals, and roles that respect separation of duties and authority limits. Test it on your hardest case before you adopt it.