RACI Names Who Answers for Work, Not Who Decides

A pattern we meet often in payment and digital banking programmes starts with a document everyone is proud of. A card platform migration, a dozen workstreams, a RACI chart with well over a hundred rows. Every deliverable has a responsible team and a single accountable name. Nobody on the programme can point to a task without an owner.

The question with no row

Six weeks before cutover, two workstreams collide. The fraud team's new scoring model is not ready to run on the new platform, and the cutover date is fixed in a commitment to a processing partner. The options are plain. Delay the cutover, launch with the legacy fraud rules carried across, or launch on schedule with a reduced set of card products. Each option has a cost, and each workstream lead is right about their own part of it.

The RACI is consulted, and it has nothing to say. Its rows are tasks: build the scoring model, migrate the card records, run the cutover rehearsal. The choice between delay and reduced scope is not a task. It sits between three rows, and each of those rows has a different accountable name. The chart was complete for the work it described, and the decision that mattered was never part of that work.

What follows is familiar. The question goes to the steering committee, which meets every second week, asks for more analysis and meets again. Part of the delay the committee exists to prevent is caused by the committee.

The difference between decision rights and RACI starts with the unit each one describes. RACI describes a piece of work: who does it, who answers for it, who is consulted while it is done and who is informed when it is finished. Decision rights describe a choice: who selects among the options, whose agreement the choice needs, and what the choice is allowed to commit.

Work divides cleanly, choices do not

Work can be split into parts that each have an owner, which is what makes RACI useful. Choices resist that split. The decisions that stall a programme are almost always trade-offs between parts: capacity one workstream needs and another holds, a date one team promised and another cannot meet, a risk one function would accept and another would not. A chart organised by task places each of those decisions on the boundary between rows, and a boundary has no owner.

This is why adding rows does not help. A programme that answers a stalled decision by writing a new line, decide cutover approach, has given the decision an accountable name without saying what that person may trade away. A row that names an owner but not a limit hands someone the blame for a choice without the authority to make it. The name is usually the programme director, who then finds that the owner of the fraud model reports elsewhere and will not accept a call that changes their scope.

In RACI the A is the person who answers for the outcome. In most organisations that is read, quietly, as the person who decides. The two overlap often enough for the confusion to survive, and they come apart exactly where it matters: in decisions that spend another function's people or another function's risk.

Answerable is not authorised

Answering for a deliverable does not grant authority over what the deliverable depends on. A head of checkout can be accountable for conversion on the payment page and hold no right at all over the fraud thresholds behind many of the declines on it. The RACI records the accountability and is silent on the authority, so the accountable person owns an outcome they cannot steer. The note on who owns the checkout roadmap traces that gap through one product area.

The consulted column has no weight

The C carries a second ambiguity. Consulted can mean that a view is heard and then weighed by someone else, or it can mean that nothing moves until that view is satisfied. RACI does not say which, so the column resolves by seniority. A consulted head of risk becomes a veto, and a consulted analyst becomes a courtesy. A RACI leaves the weight of every voice to be settled in the meeting, which is the most expensive place to settle it. RAPID separates input from agreement for this reason, as the note on the RAPID framework sets out, though changing the letters does not by itself settle anything.

On the card migration, the decision eventually reached the chief operating officer, who made it in a short conversation once the options were laid out on one page. The decision took ten minutes once it reached someone allowed to make it. The six weeks before that were spent finding out who that was.

The decision took ten minutes once it reached someone allowed to make it.

What a written right contains

A decision right, written properly, states four things a responsibility chart has nowhere to put:

• The decision type, narrow enough to test a real case against: a change to cutover scope on a live migration, not the programme as a whole.
• The decider, as one named person, with the limit of what they may commit without going higher.
• The voices that bind and the voices that inform, listed separately.
• The conditions under which the decision may be reopened, and who may reopen it.

The last term is the one most often missing, and its absence is why closed decisions return a month later, as the note on stopping a decision from being reopened describes.

Keeping both

None of this makes RACI wrong. It answers its own question well, and a programme without one loses track of its work. The two documents answer different questions, and the failure comes from asking a task chart to settle a choice. The arrangement that works is a RACI for the work and a short registry of decision types beside it, with each recurring trade-off given its own entry. On the migration, that registry would have held three or four entries. One of them was the decision that cost six weeks.

The first step is to take an existing RACI and mark every place where two rows depend on the same scarce thing: the same engineers, the same date, the same risk limit, the same budget line. Each mark is a decision the chart cannot settle. Listed and given a decider, those marks become the first draft of a registry built from the programme's real collisions rather than from the org chart, in the way the note on inherited decision rights describes.

Our consulting work runs that exercise with programme and leadership teams inside the decision architecture pillar, and writes down the rights the collisions reveal. Our training programmes cover the habit that keeps the registry alive, which is asking who decides before asking who does the work. A responsibility chart is finished when every task has an owner, and a decision architecture is finished when every collision has one.