A RAID Log Nobody Reads Is Not Risk Management

Walk into most transformation programs and you will find a RAID log. Risks, assumptions, issues, dependencies, all captured in a spreadsheet with a tab per workstream and a color scheme someone is quietly proud of. It gets updated the night before the steering committee so the slide reads current. Then it goes back to sleep.

That log is not managing risk. It is documenting the existence of risk. Those are different jobs, and confusing them is how programs sail confidently into failures the team saw coming weeks earlier.

The problem is not detection

On nearly every troubled program I have worked, the people doing the hands-on work knew what was about to break. The integration was going to slip. The data was not clean. The business unit had not actually agreed to the new process, they had just stopped arguing in the meeting.

The failure was almost never that the risk went unnoticed. It was that the warning never reached a decision. It got logged. It got a RAG status. It sat there, orange, for weeks, while the program kept moving on its original plan.

A risk that is visible but never acted on is worse than an unknown risk. An unknown risk you can be forgiven for. A logged red risk that nobody moved on is a decision to ignore it, made by omission, with a paper trail proving you knew.

What a live risk tool actually does

The test for a RAID log is simple. In the last month, how many times did it change what the program did? Did it move budget, cut scope, reassign a person, delay a milestone, escalate to an executive who could act? If the honest answer is zero, you do not have risk management. You have inventory.

A live tool has a few properties that a dead spreadsheet does not.

Every open item has an owner who can act

Not an owner who watches the item and reports on it. An owner with the authority to do something about it. If the person named against a risk cannot move money, change scope, or pull in another team, they are a note-taker, and the risk has no real owner. Name someone who can decide.

Every item carries a decision, not just a description

A risk that reads "integration may slip" is a weather report. A useful entry says what we will do, by when, and what we need from whom. "Integration timeline at risk. Decision needed by Friday: cut phase-two reporting scope or add two weeks and reforecast go-live. Owner: program sponsor." Now the log is asking for something. Now it can be resolved or escalated.

The top items get read out loud where priorities move

Most logs have fifty entries and no hierarchy. The top five matter. Those five belong in the room where budget and priority actually shift, read out loud, with the decision each one is waiting on. The rest is background. Useful to keep, not useful to run the meeting.

Rebuild the path from signal to decision

The fix is less about the tool and more about the wiring between the tool and the people with authority. A few things I insist on when I take over program governance.

• Cut the log to what needs a decision. If an item cannot plausibly change what the program does, it does not belong on the live list. Archive it.
• Give every live item a decision date, not a review date. Reviews recur forever. Decisions force a choice.
• Make escalation a mechanic, not a favor. If a risk owner cannot resolve an item by its decision date, it moves up automatically, with the specific ask attached. No one should have to be brave to escalate.
• Track how the top risks trend week to week. A red that was red last week and is still red this week without a changed action is a governance failure, not a status.

The people, not the platform

A better spreadsheet will not save a program. The RAID log is a proxy for something harder: whether the organization can take a warning from the people closest to the work and turn it into an executive decision fast enough to matter.

That path runs through people. Who feels safe raising a red. Who has authority to act. Who owns the decision when the answer is unpopular. Get that wiring right and almost any format works. Get it wrong and the prettiest dashboard in the world just documents your surprise.

So before you redesign the template, ask the harder question. When your team sees trouble coming, how long does it take to reach someone who can do something about it? Shorten that, and the log starts earning its place.