A Real Project Manager’s Guide to RAID

This blog is reader-supported. When you purchase something through an affiliate link on this site, I may earn some coffee money. Thanks! Learn more.

Ever wondered what RAID is all about in project management? You’ll hear project managers talking about their RAID logs as part of how to manage a project, or updating the RAID, but what does it all mean?

I’ve been working with RAID logs for over 20 years, so I have plenty of practical tips to share! My RAID log is THE most useful tool I use to keep my projects on track, and it will do the same for you.

Get a RAID log template as part of a complete project workbook here.

In this article, we look at everything RAID in project management — and it’s a key tool for project managers. There’s also a video interview where I talk about how a RAID log saved my project — scroll down for that.

What does RAID stand for in project management?

In project management, RAID is an acronym for:

  • Risks
  • Assumptions
  • Issues
  • Dependencies

These are key things to track as a project manager.

Your RAID log is one of the crucial project planning documents that helps you plan and control the work throughout the project lifecycle.

The RAID components give you a broad understanding of the context of the project and the environment in which you are operating. Here is a bit more detail on each of these elements.

ChatGPT created image of female project manager at work in home office

Risks

Risks are things that might affect your project if they happen. We generally think of risks as things that could cause the project to go wrong, but risk could also be something positive. Anything that might have an impact on the project (but hasn’t happened yet) is a risk.

Talk to the project team, have some brainstorming sessions, look at past lessons learned documentation and use my list of common project risks to help you get started populating this section of the RAID.

Then add the mitigation strategies, risk owner, impact and likelihood scores so you know how best to address this risk.

Sometimes people get confused about the difference between project risk and RAID, because arguably the biggest and most valuable part of the log is the risk register. But risks are only part of your RAID documentation.

Risks are potential issues, so if they come to pass, you’ll create a new entry on the Issues log.

Assumptions

Assumptions are things you have to assume because you don’t yet know if they are true. They may also be things you assume are going to stay the same. You have to work with these assumptions until you have either proven them or disproven them.

Typically, you create a list of assumptions during the project planning work when you get started. They will be things like:

  • We assume all resources are available from July.
  • We assume Joe will have completed his security testing certification by the time of the testing phase and we won’t have to delay testing or hire in an external consultant.

During the project execution, you can test out and consider these assumptions, and make changes to the schedule and documentation (and stakeholder expectations) as necessary.

On a larger project, or one with lots of potential challenges, you could have a dozen or more assumptions being made during planning and scheduling.

When you have more information, you can replan accordingly. That means assumptions can also be risks! Joy. This is where individual numbering of items on the RAID log comes in handy so you can cross-reference. If you have project management software that auto-creates numbers and lets you link items, even better.

Issues

These are things that have happened and are causing a problem on your project. For example, a key project stakeholder who has just gone off sick, or a critical bug that has been discovered during testing that is going to affect the project timeline.

Issues are things you want to keep on top of and make sure no one on the project team forgets about, so you’ll be coming back to this tab regularly to make sure they get closed off.

Issue management means coming up with an action plan, maybe some proactive strategies, and assigning the task of sorting it out to an owner. All this, and all the steps or tasks involved in the resolution, get logged.

Some people also manage changes to the project as issues, but personally, I don’t. I add an extra tab to my RAID spreadsheet to track and manage changes. But RAIDC is difficult to say.

Dependencies

Dependencies are things that your project needs in order to be able to complete according to the plan. That could be a deliverable from another project that forms the basis of your project, input from an expert, or something else.

In my experience, the biggest dependency on projects is management decision-making. They need to make decisions so you can get on with your work!

Read more about dependencies here.

The D in RAID: Dependencies or Decisions?

Formally the ‘D’ in RAID stands for Dependencies, but I get a lot more use out of recording Decisions. Ultimately, it’s up to you what you think is worth documenting on your project. Whether you document decisions in a RAID log or not, it is important to document them somewhere.

If possible, it’s also great to track any information relating to the decision made, such as emails, meeting minutes, or any other supporting documentation. Links or folder references be added to the spreadsheet as well.

It’s hard to remember details going back weeks, months, or even years, but you will be thankful to have it available if the decision comes into question. I’m sure it was an informed decision at the time, but can you prove it now?

The A in RAID: Actions or Assumptions?

Formally, the ‘A’ in RAID stands for Assumptions. But again, I get more mileage out of recording Actions.

I need to use and update the list of actions daily. The assumptions don’t change that often. You can choose to use both, or one or the other, as long as you are recording, tracking, and managing what you need to adequately manage the project.

You record these items in a RAID log. The picture below shows the RAID log template I use – the worksheet shown is the risk tab.

A screen shot of a computer
This is what the workbook looks like (one tab, anyway). Other worksheets cover the full elements of the RAID template

What is a RAID log?

A RAID log is a list where you record the risks, assumptions, issues, and dependencies on a project. It could be a spreadsheet (like this one) or built into your project management tool in the form of a database or table.

A RAID log is a way of tracking the things that affect and influence your project. It is part of the governance and control mechanisms around your project.

However, in my experience RAID alone is not enough. As I mentioned above, I also use the same format to track:

  • Actions
  • Decisions
  • Constraints
  • Changes.

But that doesn’t make a neat acronym! Who wants to write RAAIDDCC?

When you use a RAID template in a spreadsheet, you can add as many tabs/worksheets as you like so that you can track everything in one place. This makes it easier to work with: you don’t want to be looking in multiple places for information about the key data elements of your project.

For me, my RAID log is the key project document I use daily. That’s mainly because I keep my action log in there too, and that’s what I use every day to manage the work that falls outside of the project schedule.

The RAID log is a way to keep the project on track with all the elements that are not purely schedule related. Any issues, risks, dependencies, actions, constraints etc that are not actively managed might impact your likelihood of success and could affect the schedule.

When to update your RAID log

You’ve got it all set up, but how do you track RAID in project management, on a day-to-day basis?

It’s easy: just open your spreadsheet or project management software and check in with each of the items.

The different elements of your RAID log will be updated at different times. For example, you won’t need to update project constraints every day. They just won’t change that often.

Updating actions

If you are tracking actions – these will generally change the most frequently. I update something in my action log at least once a day.

Updating risks

Risks should be updated at least monthly. Preferably more often, based on your management plan and how you are choosing to manage them.

Updating issues

Issues may need to be updated daily depending on what is going on. If you have hit a major problem and things are moving fast, you’ll want to record the actions taken and what you are doing to stay on top of the issue.

Updating dependencies

I review project dependencies about once a month, normally when I’m doing project reporting for the month. Just to check that nothing substantive has changed.

It’s a good idea to review everything on the log at least once a month to make sure that you haven’t forgotten to take any critical action, and that you know what your priorities are for next month.

pin image with text: a real project manager's guide to RAID

Who updates the RAID log

The project manager should update the RAID log.

If you have project management software that incorporates a database for risks, issues, and changes, then you can delegate updating these items to the risk, issue, or change owner.

There’s no need for a workstream lead who is managing an issue to update you just so that you can update the software. They can just as easily do it themselves.

I prefer to keep ownership of the spreadsheet I use because I don’t want other people changing it. With software tools, you have an audit trail of what was changed and who changed it.

Generally, they can only change what they are tasked with, so they can’t accidentally delete a whole worksheet or update lines that relate to other people’s work.

Plus, I am a bit of a control freak and I like to know what is going on!

Using RAID for future projects

Another great thing about RAID logs is that they are a perfect source of information for lessons learned discussions and future project planning.

Use the info in the logs to set up your next project, as you’ll find many common risks occur on multiple projects.

Get A RAID project management template

My RAID project management template is an Excel spreadsheet. You can use it in Google Sheets or in Excel, or import it into whatever other spreadsheet package you use.

Get a copy now

Project Workbook and Budget Tracker
$6.00

If you're looking for a RAID log to use on your projects, this is the one I've used for years. It's RAID++, as it includes a whole host of extra tabs in the spreadsheet, so you can use one file for all your project tracking.


Everything you need to start tracking your project today. This product includes two spreadsheets. Plus a separate Excel spreadsheet for managing your project budget, with worksheets enabling you to track budgeted and actual project costs, purchase orders and invoices.

If you want to read about decision-making tools for groups check out the post here.