One of the worst feelings in the world is working late into the night, combing through emails and project artifacts in a panicked rush to document and justify your team’s past actions. This often happens when a project goes off track and you have to explain it to your management team or stakeholders.
Although the term CYA (cover your ass) definitely fits here, I’m not a fan of that term or the underlying philosophy. We want to be proactive and solve problems, not focus on keeping ourselves and our team from getting into trouble. But the reality is that things are going to go wrong at some point on some of your projects. When it does, you will be questioned about what went wrong, and you will have to explain what you and your team did about it.
If you have an up-to-date RAID log, you are covered – it is a detailed historical log of your project. Every issue should have been recorded. Every date slip, every decision made and every response you had to potential risks. The level of detail you track in your log is up to you and the conditions you and your team are working in. But it’s better to spend a few extra minutes a week keeping your RAID log up to date than having to spend hours late at night combing through past emails, calendars and your memory trying to reconstruct historical events and justify your team’s actions. If you’ve been a PM long enough, you know exactly what I mean.
When there are contracts involved or government agencies, the stakes are exponentially higher for project issues, so you should be taking your RAID log very seriously. If your project goes really wrong and there is any litigation around non-performance, your RAID log (or lack thereof) could end up a focal point of the proceedings. The advice I give project managers is this: Treat your RAID log like it is subject to subpoena – because one day, it may be.
Sidebar: Treat your RAID log like it is subject to subpoena – because one day, it may be
