Everything you need to know about creating a RAID log
Summary
A RAID log is a project management tool used to document any issues or problems that occur during an ongoing project. This tool can help your team stay organized while simultaneously documenting any issues along the way. Learn why RAID logs are great tools to use for projects and how they can help your team through a project lifecycle.
Project management is simple when everything goes smoothly. But that’s not always the case. When things get rough, it’s important to document the changes that happen in the project. This can help your team track changes, learn from these challenges, and apply that information to the next project.
In this article, we’ll explain what a RAID log is and why these logs are great tools to use for project management .
What is a RAID log?
A RAID log is a project management tool used to document any issues or problems that occur during an ongoing project. This tool is created during the project planning phase and used consistently throughout the project to document risks, actions, assumptions, issues, decisions and dependencies as the project progresses. In addition to tracking changes and increasing visibility, you can use this log during a post-mortem meeting to figure out how to prevent similar issues and challenges in future projects.
The RAID acronym stands for:
Risks
Risks are any potential problems that can have an adverse effect on the project. It’s critical to proactively identify project risks before a project begins. That way, you can identify solutions to those risks before they happen, and give your team the tools they need to understand what to do if they encounter project risks along the way. Proactively implementing project risk management can prevent major issues from developing later in the project.
This section of a RAID log is similar to a risk register , which aims to identify, analyze, and solve risks preemptively. If your team actively uses a risk register, you can implement it in the R section of the RAID log. In addition to proactive risk management, you can also use the risks section in your RAID log to document any unexpected risks as they occur. When the team identifies a risk, they should assign a clear owner to manage that issue if it comes up later in the project.
Actions or Assumptions
Depending on how your team sets up your RAID log, the A in RAID can stand for either actions or assumptions. You can use both of these options in your RAID log, or you can choose one individually. If you’re wondering which type works best for your team, choose:
Actions if your project has a lot of moving parts.
Assumptions if it’s a long-term project that requires a lot of forethought.
Actions—or action items —are all things that need to be done throughout the duration of the project. Action items should always have a clear owner so everyone knows who is responsible for each specific item. If there are multiple owners of an action item, clearly identify which individual is responsible for which deliverable. Project managers should regularly check on open project tasks or action items to ensure that the project continues moving.
Assumptions are things that your team anticipates will go a certain way during the planning process. In regards to project management, assumptions are factors that the team is already certain about. This could be because of either experience or expertise. A good example of an assumption in project management is assuming a crucial part of a machine arrives safely and on time.
Since you can’t plan for everything, your team members have to make assumptions along the way. It’s critical to document the assumptions you’re making in a central location. That way, if an unexpected roadblock or unanticipated project risk occurs, you can quickly reference your list of assumptions. If you made an assumption that led to the risk or roadblock, your team can quickly identify the root cause of the issue by proactively discovering whether or not that assumption is true.
Issues
Issues are problems that occurred during the project that you did not expect. Issues are different from risks because you don’t expect them to occur. Risks are a potential problem that you anticipate, while issues pop up unexpectedly. It’s important to track issues as they occur so your team can refer back to how the issues were resolved. If future issues arise because of this initial issue, documentation can help your team identify the root cause.
Decisions or Dependencies
Similar to the “A” in RAID, “D” can stand for either decisions or dependencies. If your project is more free-form, your team might want to highlight the decisions made to get to your solution. If your project has many intricate tasks that rely on each other, dependencies would be a more relevant choice.
Decisions are all of the concrete choices that are made along the way. These are all of the final thoughts and ideas that push a project into fruition. It’s important to document what decision was made, who made it, and why that decision was chosen. If your team uses an iterative process like kaizen , this documentation can be helpful for making improvements for future projects.
A dependency in project management is a task that relies on the completion of a different task. If there are major dependencies in a project that can prevent the project from moving forward, document them in the RAID chart. Visualizing dependencies can help your team members understand what tasks need to be completed first, before moving on to the next step. You can often find dependencies organized in a Gantt chart .
When to use a RAID log
RAID logs are good tools to use when you start planning your project. They’re also best used consistently as your project progresses, so you can document important action items that need to be checked on, any decisions that are made, or big issues that arise.
The RAID log is helpful for quick line items, but this tool shouldn’t be your sole form of project management. Think of a RAID log as an incident log for project management—if there’s a major event in the project, document it on the RAID log. Make sure you’re combining a RAID log with a more robust project management system that keeps all of your team’s work, tasks, and plans on track.
Pros of using a RAID log
RAID logs are a beneficial tool to have in your project management toolbox. Here are a few reasons why.
Fast cataloging
One of the major benefits of using a RAID log is the ability to catalog important information quickly in one central place. As soon as an issue occurs or a decision is made, a project manager can quickly jot down that action in the corresponding section of the RAID log.
Documentation for future changes
Your team should document the processes and decisions made as your project progresses. That way, the changes you make during your current project can help inform decisions on future projects. In that way, RAID logs can help you learn and utilize your experience for future challenges.
Templatize your RAID logs
It's easy to create a RAID log template that fits your team’s needs. In the event that a new project manager comes along or you are training someone on your team’s important processes, the general concept of a RAID log is simple. RAID logs are designed to be used repeatedly. The easiest way to do this is to make a template that best fits your team’s needs and use that same template for every project.
Document all decisions in one place
RAID logs give your team a central place to find information relating to a project. If a team member needs to discuss an issue with the right stakeholder, the RAID log can point them to the right person.
Not only does it document who owns what, but it also serves as a high-level overview of the project’s process. Team members can easily take a look at any actions that are currently in progress or decisions that were made recently. Because each section is clearly labeled, team members can find the information that is most relevant to them.
Cons of using a RAID log
While RAID logs are a helpful tool to use, there are some downsides to using one.
RAID logs are supplemental
Your RAID log should not be the only source of truth when it comes to project management. It’s a helpful tool to jot major decisions, key dependencies, and any issues that come up along the way. However, if you’re looking for more granular information about project specifics, using something like a project plan may suit your needs better.
In addition to a RAID log, make sure your team also has a centralized tool where all of your work information lives. That way, every team member—regardless of department or function—can access the project information they need. The best way to do this is with a work management tool .
RAID logs have to be updated regularly
A RAID log is only up-to-date when a project manager updates it. If a project manager does not consistently add new information in real time, the RAID log becomes obsolete. This can be challenging if a project manager is unable to update the log consistently. Outdated information can create confusion for other stakeholders, so it’s important to have consistent messaging throughout all forms of communication.
RAID logs can become cluttered
If you document every decision made in a RAID log down to the smallest individual choice, the log can quickly become cluttered and finding information can be challenging. Agreeing on the level of detail is an important distinction for your team to maintain their RAID log. Before you begin creating a RAID log, ensure your team has a clear understanding of what decisions and issues should or should not be included.
To prevent clutter, your team should decide specifically what information is the most important to document in a RAID log. This leaves only the most important information in the log, making referencing it easier for project stakeholders to find the information they need.
How to use a RAID log
RAID logs can be as simple as a piece of paper with four quadrants dedicated to each part of the acronym, but they’re most effective when everyone on the team can access information in one place.
To create a RAID log, follow these four steps:
Identify the best way to present your RAID log . As mentioned above, a RAID log can be as simple as a piece of paper divided into four sections. However, this may not be the most efficient way for your team to access this information. Decide with your team if you want to implement this log in a document, spreadsheet, or a different type of software.
Discuss initial risks, assumptions, and dependencies . By being proactive, you can ensure that everyone on your team is aware of potential issues and how to prevent them.
Update the log regularly. The RAID log is only accurate when it’s updated regularly. Use the log as the project progresses and update the corresponding sections appropriately.
Reflect after the project is over. When your team is hosting a project post-mortem, use the RAID log to help in your conversation on how you can improve for your next project.
Using software for a RAID log
Creating a RAID log with work management software like UDN Task Manager can help you organize all of your log items consistently. By clearly defining deadlines, stakeholders, and action items, your team will be able to get back to accomplishing the work they do best.
