The RACI Nobody Reads Is the RACI That Gets You Fired

The cutover failed at 03:40 on a Sunday because nobody raised the firewall changes. The ownership matrix had named the person responsible for eleven weeks. It was on page four of a document last opened in March.

Most people get one thing badly wrong about a RACI: they think building it is the work. You get a room, you list deliverables down the left, names across the top, you argue pleasantly about four or five cells, and you leave with a grid. It feels like progress. It looks like governance. Your programme manager is thrilled.

But the grid is a record of a conversation. It isn't the conversation. Nobody becomes accountable because a spreadsheet says they are. They become accountable because they said the words out loud, in front of other people, and nobody in the room objected. If that moment never happened, you don't have a RACI. You have an artefact that will be used to work out whose fault it was, and the first name on that list is usually yours, because the matrix was your idea.

I'll be blunt about it. The matrix that burns you is almost never the one that's wrong. It's the one that's right and unread.

Here's a cheap check you can run this week. Pick any row. Ring the person named as accountable, don't email, ring. Ask them what they own on this project. Say nothing else.

If they can tell you in one sentence, in under five seconds, and it matches the row, that row is real. If they say "let me pull up the sheet", that row is decoration. If they say "I thought that was the integrator", you have just found the thing that's going to hurt you in week 14.

Do this with ten rows and you'll get a number back that tells you how much of your governance actually exists. In my experience it's rarely more than half, and the half that's missing is never evenly spread. It clusters exactly where you'd expect: at the joints. Between your team and the vendor. Between the delivery team and the security function. Between whoever builds it and whoever has to run it at 2am.

Those joints are where projects fail. They are also, funnily enough, the rows people skim past when the matrix goes up on screen, because they aren't anybody's favourite subject.

Here's how the Sunday morning I opened with actually happened.

A water utility exiting a legacy data centre. Fourteen workstreams, two integrators, a 22-person applications team, and a managed service running the firewalls that nobody in the room worked for. The matrix was good. Genuinely good. It had a row that said "firewall rule changes for migrated workloads", with the network integrator as responsible and the utility's own security lead as accountable. Correct, specific, agreed in a workshop in January.

In week 6 the security lead took a job somewhere else. His replacement inherited a mailbox, a calendar, and roughly forty per cent of a handover. Nobody walked her through the matrix, because by then the matrix was finished, and finished things don't get revisited. She turned up to the steering committee, nodded at the right moments, and had no idea that one line in a document made her the person who had to push a third party for rule changes with a six week lead time.

So the rules weren't raised. Not out of negligence. Out of a gap between a document and a human being.

Sunday at 03:40 the migrated workloads couldn't reach the billing platform. The team backed out by 05:15, which is the one part of this story that went well. The next window was six weeks away, so the project lost a quarter of a change calendar and the thing that got said in the post-incident review was "the RACI was clear". It was. That was never the problem.

What the technical lead should have done takes about four minutes. When a name changes on your project, you open the matrix, you find every row with the old name on it, and you have a five minute call with the new person for each one. Not an email. A call, where they say yes and you can hear whether they mean it.

The other reason matrices go unread is that they're enormous. Ninety rows of deliverable, half of them things like "attend weekly call", and a colour legend. Nobody maintains a ninety row grid. They maintain it for two weeks and then it quietly becomes fiction, and fiction that looks authoritative is worse than no document at all, because people stop asking the question it was meant to answer.

Cut it to the rows that would genuinely hurt if the owner was wrong. On most projects that's 10 to 15. Handoffs between organisations. Anything with an external lead time. Anything where the person who decides is different from the person who pays. Anything that touches security, data, or money moving. Everything else can sit in the plan where it belongs.

And put a date on it. Not a version number that nobody increments. An actual review date in the calendar, owned by you, every three or four weeks, where you spend twenty minutes asking one question per row: is this still the right name. That's the whole meeting. You will find something every single time.

One more thing, since it comes up. Yes, you can get an AI to draft the first version of the matrix from your plan and your stakeholder list, and it'll be a decent starting point that saves you an afternoon. It cannot do the part that matters, which is sitting opposite a person while they agree out loud to carry something. Draft with the tool if you like. You own the agreement.

Open the matrix. Find the five rows where a wrong owner would do the most damage, and send each named person one message:

"You're down as the person accountable for X. Is that still right, and have you got what you need to do it? Yes or no is fine."

Read the replies carefully. A "yes" is a row you can trust. A hedge is a row you need to talk about this week. And anyone who hasn't answered by Wednesday isn't an owner, they're a risk with a name attached, and that name goes to your sponsor before it goes anywhere near a post-incident review.