RAID Analysis: Nailing down on Risks, Assumptions, Issues and Dependencies

You know what can kill your project?

It’s these four things:

  • riskswhen bad luck strikes
  • (false or hidden) assumptionsany assumptions your project is based upon
  • issuesnasty problems
  • dependencies tasks being locked to each other

We’ll look at each one in detail below.

But first:

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.

Risks:

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.

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:

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:

Hello all,

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!

Best regards,

John

Project manager

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. Just enter your details in the form below and you’ll get to the XLS file.

A RAID analysis template combines risks, assumptions, issues and dependencies in one overview
A RAID log template combines risks, assumptions, issues and dependencies in one overview

 

Leave a Comment