RAID log: Track risks, assumptions, issues & decisions
Summary
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 so your team can track changes, learn from challenges, and apply that information to future work.
In this article, we'll explain what a RAID log is, what to include in one, and why these logs are great tools to use for project management.
How to build a transformational AI strategy from the ground up
The journey of AI adoption is no longer uncharted territory. Supported by research from our Work Innovation Lab in partnership with frontier AI safety and research company, Anthropic, this guide offers a how-to for navigating the journey of AI adoption.
What is a RAID log?
A RAID log is a project management tool used to track Risks, Assumptions (or Actions), Issues, and Dependencies (or Decisions) throughout a project. Created during the planning phase and updated consistently, it serves as a central record of factors that could affect your project's success. You can also use it during a post-mortem meeting to identify lessons learned for future projects. The RAID acronym stands for:
Risks
Risks are potential problems that could negatively affect your project. It's critical to identify project risks before work begins so you can develop risk mitigation solutions in advance. This gives your team a clear playbook for handling issues if they arise.
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. 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
The A in RAID can stand for either actions or assumptions, and you can use one or both in your log. Here's how to decide which works best for your team:
Actions: Best for projects with many moving parts and tasks to track.
Assumptions: Best for long-term projects that require significant forethought.
Actions, or action items, are all things that need to be done throughout 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 who is responsible for each deliverable.
Assumptions are things that your team anticipates will go a certain way during the planning process. In project management, assumptions are factors the team is already certain about. 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 will make assumptions along the way. Document these in a central location so you can quickly reference them if an unexpected roadblock occurs. This helps your team identify whether a flawed assumption was the root cause.
Issues
Issues are problems that occur during a project that you did not anticipate. Unlike risks, which you plan for in advance, issues pop up unexpectedly and require immediate attention. Tracking how issues are resolved helps your team identify root causes if similar problems arise later.
Risks | Issues |
Potential problems you anticipate | Actual problems that have occurred |
Identified before or during planning | Arise unexpectedly during execution |
Managed through mitigation strategies | Require immediate resolution |
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 depend on one another, dependencies would be a more appropriate choice.
Decisions are the concrete choices that move your project forward. A structured decision-making process helps ensure these choices are well-informed and documented. Documenting them is especially valuable if your team uses an iterative process like kaizen, as it helps inform improvements for future projects.
For each decision, document:
What: The specific decision that was made.
Who: The person or team responsible for making it.
Why: The rationale behind the choice.
A dependency in project management is a task that depends on the completion of another task. If there are major dependencies in a project that could prevent it from moving forward, document them in the RAID chart. 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, decisions, and issues as they arise.
RAID logs are helpful for documenting key events, but they shouldn't be your only project management tool. Think of a RAID log as an incident log for your project. Pair it with a robust project management system that tracks all of your team's work, tasks, and plans.
Use a RAID log when you need to:
Document a new risk: A potential problem has been identified that could affect the project.
Record a key decision: The team has made a choice that shapes the project's direction.
Track an unexpected issue: A problem that requires resolution and documentation. An issue log can help formalize this tracking.
Note a critical dependency: A task is blocked until another task is completed.
What to include in a RAID log
While a RAID log can be simple, including the right details is key to making it useful. A detailed log gives your team the context they need to understand project hurdles and make informed decisions. For each item you add, try to include:
ID number: A unique number to easily reference the item.
Description: A clear, brief summary of the risk, assumption, issue, or decision.
Category: The type of item (Risk, Assumption, Issue, or Decision).
Date identified: The date the item was first logged.
Owner: The person responsible for monitoring the item and seeing any actions through.
Priority: The level of urgency (e.g., High, Medium, Low) to help your team focus on what matters most.
Status: The current state of the item (e.g., Open, In Progress, Closed).
Action plan: The specific steps being taken to address the item.
How to use a RAID log
RAID logs can be as simple as a piece of paper with four quadrants, one for 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. A RAID log can be as simple as a piece of paper divided into four sections. 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 planning ahead, 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.
RAID log example
Seeing a RAID log in action can help clarify how it works. Imagine your team is developing a new mobile app. Here's what a risk entry might look like:
ID number: R-001
Description: The third-party payment API may have a higher-than-expected failure rate during user testing, which could delay the launch.
Category: Risk
Date identified: 08/15/2025
Owner: Alex Martinez
Priority: High
Status: Open
Action plan: The engineering team will build a backup payment processing flow. The QA team will add specific API failure scenarios to the user testing plan.
Benefits of using a RAID log
RAID logs are a valuable tool for 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 quickly catalog important information in a single 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. RAID logs help you learn and apply your experience to future challenges.
Read: How to capture lessons learned in project managementTemplatize your RAID logs
It's easy to create a RAID log template that fits your team's needs. RAID logs are designed to be used repeatedly. The easiest way to do this is to create a template that best fits your team's needs and use it for every project.
Read: Process documentation: The ultimate how-to with examplesDocument all decisions in one place
RAID logs provide your team with a central place to find project information. 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. Because each section is clearly labeled, team members can find the information that is most relevant to them.
Read: The role of an incident commander: Real-time crisis controlLimitations of using a RAID log
While RAID logs are a helpful tool, they also have downsides.
RAID logs are supplemental
Your RAID log should not be the only source of truth for project management. For more granular information about project specifics, a project plan or a change log template may better suit your needs. In addition to a RAID log, make sure your team also has a centralized tool where all of your work information lives. 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. Consistent project tracking habits ensure your log remains accurate and useful. If a project manager does not consistently add new information in real time, the RAID log becomes obsolete. Outdated information can create confusion among other stakeholders, so it's important to maintain consistent messaging across all forms of communication.
Read: Why a clear communication plan is more important than you thinkRAID logs can become cluttered
If you document every small decision, your RAID log can quickly become cluttered. Before creating your log, align with your team on which items to include. Focus on high-impact, relevant information for project stakeholders.
To keep your RAID log focused, document items that are:
High priority: Risks or issues that could significantly affect the project timeline or budget.
Cross-functional: Decisions that affect multiple teams or stakeholders.
Recurring: Assumptions or dependencies that come up repeatedly across projects.
Using software for a RAID log
Creating a RAID log with work management software like Asana 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 doing what they do best.
Manage projects with clarity using Asana
A well-maintained RAID log clarifies the complexities of any project, helping your team stay ahead of potential roadblocks and stay focused on their goals. By tracking risks, assumptions, issues, and decisions in one place, you create a single source of truth that empowers everyone to work together effortlessly.
When you use a work management platform like Asana, you can turn your RAID log into actionable tasks, assign owners, and track progress alongside the rest of your project work. Ready to bring more clarity to your projects? Get started with Asana today.
Create a RAID log template
