The RAID Log is one of the most underrated templates in project management.
I can say this based on my own experience, and other project managers in my network have echoed this view.
In this article, I’ll explain what a RAID Log is, what makes it so helpful, and its specific uses. You can also download my RAID Log Template for Excel from this page.
What is a RAID Log?
RAID stands for Risks, Assumptions, Issues, and Dependencies. A RAID log captures these points in a clear overview, because keeping those points at the top of our mind is crucial for the success of a project (just think of risks).
As project managers, we create the RAID log during the planning phase with the involvement of project stakeholders, especially the client. During the course of the project, it is our responsibility to regularly review and update the log.
How to use a RAID Log Template
Let’s take a closer look at the specific elements. What goes into the RAID log?
Risks
This includes all major risks that could endanger a project. Think about situations that may arise and cause a project to be delayed, become more expensive than planned, or not achieve the desired outcome.
Of course, we could list all sorts of crazy things that might happen but have a low probability. That wouldn’t make sense and would only make our template unreadable. Therefore, focus on those risks that result from the specific circumstances of the project.
I recommend you read my article on performing a project risk assessment. Here, I cover in depth my approach to identifying project risks, which I have refined during my project management career.
Examples of project risks:
- Your team is also heavily involved in other projects. Therefore, there is a high risk that at some point, there won’t be enough capacity, and tasks in your project will be left undone.
- You are updating your company’s business applications to the latest release, which is not widely used by other companies and therefore may contain major bugs.
- Suppliers may not be able to deliver key materials needed for the project on time.
Project risks are clearly a topic that you cannot dedicate enough attention to during the project planning stage. Many risks cannot be avoided, but at least we can start our project well-prepared, and as much as possible, remove uncertainty from our project plan.
Assumptions
Assumptions in project management are conditions that we take as given for planning a project. We need to make some assumptions to be able to plan at all!
The reason we write down assumptions in the RAID log is simple: when planning projects, assumptions are occasionally made that later turn out to be wrong.
These assumptions should have been discussed beforehand, because they can significantly impact the project’s timeline, budget, and overall success. To address this problem, the RAID log also captures assumptions.
Examples of assumptions:
- For the rollout of a new CRM software, our existing servers can be used. No new hardware needs to be purchased.
- Due to a trade fair, no project activities can take place during the first two weeks of August.
- To save costs, the client wants to perform part of the implementation work themselves (we’d still need to specify exactly which tasks this involves).
Issues
Here we record current issues that are slowing down or blocking project work. Issues can very in nature. Technical issues can stop an IT project, or delivery problems can threaten an engineering project.
Issues can also arise from disagreements between key project stakeholders: one department head wants it one way, while another prefers another way. If the client side is not in agreement and the team cannot move forward, we have a problem that needs to be solved.
Examples of issues:
- A newly implemented user software crashes on certain devices.
- A procured component cannot be delivered due to production shortages.
- There is a disagreement between the finance and sales teams about who is responsible for the ongoing maintenance of customer master data.
Dependencies
There are often dependencies between project tasks. This means a certain step can only begin once a previous step has been successfully completed. We document these exact dependencies in the RAID log template.
Why do we do this? Our focus is to avoid delays. But when there are dependencies between key tasks, there is always a high risk that the entire project may be delayed because one task is not completed on time, preventing the team from moving forward. Even with added buffer in our schedule, we can’t completely avoid these scenarios.
In the RAID log, we remind ourselves, the client, and the team of these dependencies so that the affected tasks are handled with special care and urgency.
Examples of dependencies:
- A special storage area has been set up for project materials. The area must be cleared out first before new project materials can be stored.
- Procurement activities can only begin once the legal department has reviewed and approved the supplier contract.
- A preceding project must reach a certain milestone before a follow-up project can start.
For all items in the RAID Log, define action steps! This is crucial. List concrete actions that will be taken for the purpose of mitigating risks, resolving issues, verifying assumptions or monitoring dependencies.
Evaluate items by priority
The risks, assumptions, issues, and dependencies recorded in the RAID log can be rated by their priority using the dropdown menu. This indicates how important an item is for the project. In other words: How significant is the impact if the item is not resolved or carefully executed?
Why use a RAID Log Template?
The RAID log template is very useful for communication with contributors and stakeholders because it clearly presents the critical elements of the project.
The format is super simple. Even people without knowledge of formal project management methods can easily understand a RAID log – everyone gets what risks, issues, dependencies, and assumptions are. And that’s a great basis for discussing these points and quickly removing bottlenecks.
As project managers, we often forget that the people we work with are usually not project management experts. But the templates and Excel sheets we use can overwhelm most people. The RAID log template is a great tool because it’s easy for everyone to understand.
Scenarios I recommend using a RAID Log Template
Using a RAID log template is generally helpful in all projects. Based on my project management experience, it is especially useful in certain project environments.
These include:
Client projects: Projects where a well-coordinated implementation team works on a project with an end customer. The implementation team handles overall project management and needs to guide the customer team and the customer project manager. The RAID log template is extremely helpful for these types of project scenarios. Why?
The customer doesn’t need to know every project detail. But we must inform them of critical points and remind them of their responsibilities – for example, pushing critical tasks with dependencies or addressing issues that need to be resolved on their side. With the RAID log, we can communicate these points objectively and without the customer feeling offended.
Less mature project environments: In less developed organizations, it’s usually hard to establish formal project management processes, even though they would improve project outcomes. Trying to introduce extensive documentation guidelines or templates in such places would be challenging.
However, we can start with the RAID template, so at least we have a consistent format for capturing critical aspects like project risks. This makes communication easier and provides clarity for project managers, the PMO and stakeholders.
My Tips For Using a RAID Log
- Regularly freeze the current status of your RAID log This allows you to revert to a previous state, which can be useful if there are later discussions about the project (for example during a lessons learned). For instance, if the customer claims they weren’t informed about a project risk in time, you can present evidence to the contrary.
- Use the template to the extent that makes sense for your project. For example, some people don’t track dependencies in the RAID log because they have other monitoring mechanisms for dependencies in place. Instead, they track decisions in the RAID log. Similarly, you could also track scope changes in the document, because as we all know, changes are a regular part of projects.
- Hide, don’t delete. When an item has been closed, hide the respective row instead of deleting it. It’s not uncommon that past issues or discussion points pop up again, and you want to be able to access that information quickly.
Related Project Management Templates
Here are some additional templates you might want to check out assuming you’re currently in the project preparation phase.
Risk Register
A risk register also allows you to document project risks, but with a few more details. Each risk can be classified by risk type. Additionally, you can evaluate risks based on their impact and likelihood of occurrence. I have used this template in all my projects, and I recommend it for large and complex projects.
Project Communication Plan
As mentioned earlier, the RAID log should be reviewed regularly with the major parties involved. To do so, you need to have regular meetings scheduled with them. The project communication plan template helps you create a communication plan for your project, which outlines when and how often you meet with the client and key contributors.
Project Template Pack
This is a complete collection of the templates and Excel forms I created for myself as a project manager. They have been a tremendous help in all my projects. If you want a professional collection of templates covering all aspects of a project, including schedule, budget, requirements, risks and more, check out my template pack.
