RAID Logs Aren't Compliance Theater

In the early days of my PM career, I didn't understand the value of a RAID log. My mental framing was flawed: it was a document detailing all the things I forgot or missed, a diary of my own failures that I had to present to clients and management, unless I found a clever way to not include them, or to undersell their significance. Later in my career, my use of a RAID log changed. It became a CYA tool. See here—I told you about this two weeks ago. Again—I lost the plot.

RAID logs are an accountability tool for the whole project team—clients included, but the reason we don't use them properly is structural. It's another document to open. More data to copy/paste. Switching between apps. You don't use your RAID logs effectively but it's not your fault.

The mistake that kills most RAID logs

Most RAID logs die because they're treated as documentation. Documentation looks backwards. Documentation happens when you have the bandwidth, and you never do. RAID logs get stale.

So what happens? Risks turn into issues, assumptions aren't validated and decisions become frantic sessions of combing through emails looking for who to blame.

The fruit of not respecting your RAID log is a watermelon project. Green on the outside, red on the inside.

How Janus treats your RAID log

There's no cycling through open applications or browser tabs. In the project plan you can see which tasks have risks associated with them. You can review meeting notes and flag a decision. Click a box to include a RAID item in your status update. If you need a deep dive, click on the RAID log tab and you're in the thick of it.