What is a RAID log, and how do you use it?

What the interviewer is really testing

• Risk discipline. Do you manage risks before they hit, or do you only react once something breaks?
• Clarity. Do you know the difference between a risk, an assumption, an issue and a dependency? Mixing them up is a red flag.
• Action. Is your RAID log a living tool with owners and dates, or a document that's filled in once and forgotten?

The weak answer vs the strong answer

Here's the weak answer: "It's a list of problems in the project."

That tells the interviewer you treat risks and issues as the same thing, and that the log is just paperwork: no owners, no dates, filled in once and never reviewed.

The strong answer explains each letter, and then, more importantly, shows how you actually use it every week.

The strong answer: four letters and one habit

Here's how I'd answer.

1. R is for Risks: things that might happen. For each one, note the probability, the impact, and the mitigation: what we'll do now so it doesn't happen. For example: the test environment may not be ready on time.
2. A is for Assumptions: things we believe are true but haven't confirmed. Like: the client will provide test data by week three. Every assumption needs an owner to validate it, because an assumption that turns out wrong becomes an issue.
3. I is for Issues: things that have already happened and need action now. The environment is down, or a key requirement still isn't signed off. Issues get an owner, a target date and an escalation path.
4. D is for Dependencies: things we need from other teams or vendors. Another team's API, a vendor's data file, an approval. Each one has an owner on the other side and a date we've agreed.
5. Use it every week. This is the part most candidates miss. Every item has an owner and a due date, I review it with the team every week, and the top items go straight into the status report. A RAID log nobody reads is just a document.

A real example: the late vendor file

A claims system upgrade for a US healthcare payer. Details are anonymised.

1. Spotted. We logged a dependency: a provider data file from a third-party vendor, needed for end-to-end testing by week six. In the weekly review, the vendor kept missing small checkpoints, so we raised it as a risk: high probability, high impact on go-live.
2. Acted. Because it was in the RAID log with an owner and a date, we acted four weeks early. We escalated to the vendor through the client, and in parallel built synthetic test data as a plan B.
3. Result. The file did arrive ten days late, but testing never stopped, because plan B was already running.

We went live on the planned date. And the client's sponsor never heard about it as a surprise: it had been on the status report, in amber, for a month. That's the real value of a RAID log. The risk was cheap to handle in week two. It would have been very expensive in week six.

Want to build one? Try the RAID Log Builder in our Tools section.