RACI matrix: who is responsible for what, in the process rather than the project

A RACI matrix assigns every task who carries it out (Responsible), who answers for it (Accountable), who is asked beforehand (Consulted) and who is told afterwards (Informed). That makes clear for every step who plays which role, and where responsibility is missing or assigned twice. The rows are tasks, the columns are roles, and each cell holds a letter.

The four letters

• R (Responsible): does the work. The role that actually carries out the step. There can be several Rs if the work is split.
• A (Accountable): answers for it. The role that signs off the result and decides when in doubt. Every task has exactly one A.
• C (Consulted): is asked beforehand. Roles whose knowledge or agreement is needed before the step is done. A C is a conversation in both directions.
• I (Informed): is told afterwards. Roles that need to know the result but contribute nothing to it. An I is a message in one direction.

What is the difference between responsible and accountable?

Responsible does the work, accountable answers for the result. Often it is the same role, and the cell reads “A/R”. The two come apart as soon as someone other than the person doing the work signs it off: accounts payable checks an invoice (R), the cost centre approves it (A).

Rule of thumb: exactly one A per row. Two As mean that nobody decides when it matters. No A means the same thing, only more honestly.

Example: RACI in invoice processing

Step	Accounts payable	Cost centre	Purchasing	Controlling
Record invoice	A/R
Check content	R	A	C
Approve	I	A/R
Release payment	A/R	I		I

The matrix answers questions a flowchart leaves open: who is allowed to approve? Does purchasing need to be asked, or is it enough to inform them? And who notices when an invoice gets stuck?

Where a RACI matrix usually fails

• Too many Rs. When five roles “carry out” a step, none of them feels responsible when it counts. Several Rs are fine, but they need a split.
• C confused with I. Entering someone as C who only needs to be informed slows every step down. Entering someone as I who needs to be asked leads to surprises.
• People instead of roles. A matrix with names is wrong the first time someone changes jobs. Roles stay stable, people move on.
• The matrix lives next to the process. This is the most common and most expensive mistake, so it gets its own section below.

Why a RACI matrix belongs in the process

Most RACI templates come from project management: one spreadsheet per project, set up at kick-off, filed away at the end. For projects that is fine: they end.

Processes don’t end. A RACI matrix for an ongoing workflow has to stay right for as long as the workflow runs. That is exactly where the spreadsheet next to the process documentation fails: the workflow changes, the spreadsheet doesn’t. Six months later the two describe the same process differently, and nobody knows which version to trust.

The assignment only becomes stable once it is attached to the process step itself: who carries out the step, who approves it and who is asked is recorded where the step is described. The swimlane then shows whose turn it is, the RACI details show who may do what, and the role that answers for the whole workflow is the process owner.

From spreadsheet to workflow

ProcessCollector records roles and responsibilities directly on the process steps: every step has its own field for the RACI assignment. Often the roles are already in your documents, for example in an SOP or a work instruction, and are picked up when they are read in. Who carries out, who approves and who is told then changes along with the workflow instead of going stale in a second file.

Summary

A RACI matrix settles for every step who does the work, who answers for it, who is asked and who is told. The most important rule is a single A per task. For processes it only holds up when it is attached to the workflow itself rather than kept as a spreadsheet next to it.