How to map roles and responsibilities in a process
How to map roles and responsibilities across a process: one accountable owner per step, lanes for the roles that act, and a RACI only where the diagram cannot carry the answer.
A worked example, stage by stage
Requester versus process owner
The requester raises the need; procurement owns the check for an existing vendor and the due-diligence pack. Whoever asks for something is rarely accountable for the process that follows, and conflating the two is the most common mapping error.
Four reviews, four owners
Legal on contract terms, finance on credit, security on data protection, then a risk tier. Each review sits in one lane. A single "due diligence" step owned by procurement would hide three accountabilities that genuinely belong elsewhere.
Who decides, not who prepares
Procurement holds the due-diligence gate; legal holds the contract. The role that prepares the evidence is not automatically the role that decides on it, and putting the decision in the preparer's lane quietly documents a control weakness.
Separation of duties, drawn
Bank verification and vendor master data both sit with finance, with a callback loop between them — and the person who verifies must not be the person who edits the record. Where the diagram cannot show that constraint, write it on the step.
How it works
Map the process first
Get the steps and decisions down before arguing about ownership. Responsibility discussions held without a shared picture of the work run on generalities, and generalities are exactly where two teams can both feel they are covering something.
Assign one accountable role per step
Use the lane. The test is simple: who gets chased when the step is late? Not who cares about it, not who reports on it. If two names come up, keep asking until one of them is the answer, because that ambiguity is the finding.
Separate deciding from preparing
Check every decision. The role that assembles the evidence is often not the role that should make the call, and where the chart shows them as the same lane you have documented a control weakness rather than a process.
Record consulted and informed on the step
Put the other parties in the step's comment: who must be asked before it proceeds, and who needs to know afterwards. Keeping them on the step rather than in a matrix is what stops the two from drifting apart.
Look for the patterns that indicate trouble
A lane with one box probably is not a lane. A role appearing in every step is either a bottleneck or a manager who should not be in the flow. And a step whose lane nobody will claim is the real output of the exercise.
Get each role to confirm their own lane
Send the chart to each lane owner and ask them to confirm or correct only their own steps. Confirmations at that level are meaningful; a group nod to a whole diagram is not, and it is the mechanism by which unassigned steps survive a review.
Frequently asked questions
What is the difference between responsible and accountable?
Responsible is who does the work; accountable is who answers for it being done. They are often the same person and do not have to be — a service desk agent may be responsible for closing a ticket while the service owner is accountable for closure quality overall. The rule that matters is that accountability is singular. Multiple responsible parties is normal; multiple accountable ones means nobody is, because when the step is missed neither was wrong.
Do I need a RACI matrix if I have a swimlane diagram?
Usually not. The lane already carries accountability, and the sequence already shows who acts when — which is most of what a RACI communicates, in a form people will actually look at. Add the consulted and informed parties to each step's notes and the matrix becomes redundant. Where a separate RACI genuinely helps is a process spanning many teams where governance requires a signed-off table; even then, generate it from the process rather than maintaining it alongside.
How do I handle a step where nobody will claim ownership?
Leave it unassigned on the chart and escalate it as an open question. The temptation is to allocate it to the most plausible team so the diagram looks finished, but an unowned step that has been quietly working is a risk somebody should decide about, and burying it in a lane removes the only evidence you had. Unassigned steps are among the most valuable findings a mapping exercise produces.
Should managers appear as a lane?
Only where they perform steps — an approval, a decision, an escalation. A manager lane that appears at every step usually indicates either a genuine bottleneck or a mapping habit of adding oversight to everything. Both are worth surfacing, and the diagram makes either obvious the moment the lane is drawn.