You know what can kill your project?
It’s these four things:
- risks – when bad luck strikes
- (false or hidden) assumptions – any assumptions your project is based upon
- issues – nasty problems
- dependencies – tasks being locked to each other
We’ll look at each one in detail below.
What is RAID analysis?
RAID analysis is a popular method in project management. Its goal is to identify key risks (R), assumptions (A), issues (I) and dependencies (D) in a project. The RAID analysis is performed during the initiation phase, and the findings are documented in a RAID log and monitored over the course of a project.
Risks, Assumptions, Issues and Dependencies
Let’s look at each one separately.
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 a ton 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.
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.
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.
Example of a dependency: 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. Hundreds if not thousands.
In order not to loose overview we also track dependencies in a RAID spreadsheet.
Should you spend time on a RAID analysis?
Let’s put it this way:
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 do.
How to run a worthwhile RAID analysis session
The first RAID analyis is performed during the project planning phase.
Steps to perform a session:
1. Block a meeting room for a 2-hour session
2. Invite the customer and the main stakeholders to the meeting.
The meeting invite should be sent out at least a week in advance. This way the participants can prepare for the meeting and the session will be more fruitful.
You can use the following script in your invitation:
I’d like to invite you for our initial RAID analysis workshop.
As part of the workshop we will identify key Risks (R), Assumptions (A), Issues (I) and Dependencies (D) of the project. I know this may sound a bit confusing.
To give you some background:
Key risks: Anything that could jeopardize the success of the project. Key project risks are going to be monitored on an ongoing basis and we’ll establish mitigating actions to reduce the adverse impact.
Assumptions: These are all the assumptions the project project is based on.
Issues: Any major issues that are known to date and must be resolved
Dependencies: Here we want to find out how the project tasks are connected, i.e. we want to understand the order in which the project tasks have to be scheduled.
Looking forward to the workshop!
3. Have the meeting and go through each agenda item: risks, assumptions, issues and dependencies.
Document the results in a RAID analysis sheet (you can download my RAID template below).
4. Share the RAID analyis results
Finally, send out a summary of the findings you gathered during the session.
Depending on the amount of content you put together, it may be a better idea to prepare four slides, with each one showing the top risks, assumptions, issues and dependences.
RAID analysis: Get my all-in-one template
A RAID log is where you document the results of the analysis session. Like in other areas of project management, Excel is the best tool to maintain the log.
My RAID analysis template comes with nice color coding and an easy classification logic. You can get the template by signing up using the form below.