some introductary text
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.
explanations of the pictures above?
Risks: Risks are any problem or any event that has the potential to derail a project. Common risks include problems around time slippage, budgetary shortfalls, disputes amongst personnel or team members or partners in a multi-agency project. Many bids and tenders request an indication of risk management and mitigation in any proposal. This is certainly the case with EU-funded projects.
Issues: Imagine you are managing an overseas project. You had planned several business trips to the site which is in – let’s say – Kwabala (a fictitious country). Due to political tensions the Kwabala government has restricted entry from the US. Which means: you can’t get into the country! That’s a serious issue! You need to find a workaround for that … maybe carry out the work remotely.
Assumptions: Now imagine this scenario: You’ve organized a staff training for a client’s new software system. Due to the lack of properly-sized meeting rooms the training takes place at a hotel outside of town. The night before the event you wonder: “I hope everyone will bring their laptop“. The next day you arrive at the training site. And what you see is not good: Lots of happy people behind their desk, but no laptops! What a nightmare. You can’t do the training! You had assumed that the client would bring their laptop. And your client’s staff had assumed: we’ll have a great time there.
This is a simple example but now you understand why a RAID analysis is a good thing.
Dependencies: Dependencies exist where one activity can’t start before another activity is completed. If we take a house building project as example, we can’t paint a house before the actual construction is finished. Both tasks are dependent on each other. This is a very obvious case because every child knows that you can only paint a house once its built. In complex projects there are many more dependencies.
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.