This is a useful tool as it encourages you to consider some essential elements of a project and for a funding application – the Risks, the Assumptions, the Issues and Dependencies – all of which can harm the potential to ‘trip up’ your project and need to be identified in an application.
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.
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.