RAID Analysis is best explained in the following way as an analogy – Imagine one day you come into the office. While wandering around you note that your key team member is missing. You check your email. He’s left a note: “Hi, I got called over to my other project. They are having issues and I need to help. Sorry I can’t support you this week.” Damn. You are in trouble. The project can’t move on without this guy.
A common risk has struck your project: You’ve run into a resource issue. That’s just one example of a project risk. There are loads of other risks that can harm your project, and it makes sense to spend some time gathering and analyzing project risks while you kick off a new project. They can be considered as Risks, Assumptions, Issues and Dependencies, or RAID.
In order not to loose overview we also track dependencies in a RAID spreadsheet or you can use a Critical Path Diagram. So should you spend time on a raid analysis?
Yes, you should monitor risks, assumptions, issues and dependencies in a project. Because if you don’t you’ll be navigating a ship without knowing where the cliffs and stormy zones are. However, you don’t have to document everything in a single raid analysis template (file). Instead you can track it in separate files, which is what I would do.