# RAID Log: Track Risks, Assumptions, Issues & Decisions > Learn what a RAID log is and how to use one to track risks, assumptions, issues, and decisions or dependencies. Includes what to include and an example. Source: https://asana.com/resources/raid-log ## RAID log: Track risks, assumptions, issues & decisions #### Summary A RAID log is a project management tool that tracks risks, assumptions, issues, and decisions throughout a project. Learn what to include in a RAID log, how to use one effectively, and why it's a valuable addition to your project management toolbox.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](/resources/benefits-project-management). ## What is a RAID log? A RAID log is a [project management tool](/uses/project-management) used to track **R**isks, **A**ssumptions (or Actions), **I**ssues, and **D**ependencies (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](/resources/project-post-mortem-tips) 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](/resources/project-risks) before work begins so you can develop [risk mitigation](/resources/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](/resources/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](/resources/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](/resources/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](/resources/continuous-improvement), 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](/resources/project-dependencies) 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](/resources/gantt-chart-basics). ## 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](/resources/incident-management) 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](/templates/issue-log) can help formalize this tracking. - **Note a critical dependency:** A task is blocked until another task is completed. - [建立 RAID 紀錄範本](/templates/raid-log) ## 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](/resources/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](/resources/become-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. - [閱讀：如何從專案管理中汲取經驗](/resources/lessons-learned) ### Templatize your RAID logs It's easy to create a [RAID log template](/templates/raid-log) 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. - [閱讀：流程文件：附帶範例的終極解說](/resources/process-documentation) ### Document 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. - [閱讀：事件指揮官的角色：即時危機控制](/resources/incident-commander) ## Limitations 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](/resources/project-management-plan) or a [change log template](/templates/change-log) 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](/uses/work-management). ### RAID logs have to be updated regularly A RAID log is only up to date when a project manager updates it. Consistent [project tracking](/resources/what-is-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. - [閱讀：為什麼清楚的溝通計劃比您想像的更為重要](/resources/communication-plan) ### RAID 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](/resources/project-stakeholder). 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](/product) 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](/create-account) with Asana today. ## Frequently asked questions about RAID logs #### What is the difference between a RAID log and a RACI chart? A RAID log tracks project risks, assumptions, issues, and decisions, while a RACI chart clarifies team roles by defining who is Responsible, Accountable, Consulted, and Informed for each task. #### Who is responsible for the RAID log? The project manager typically owns the RAID log, but all team members should contribute by flagging new items and providing updates. #### What is RAID in a PMO? In a Project Management Office (PMO), RAID is a standardized framework used to manage risks, assumptions, issues, and dependencies consistently across all projects in a portfolio. This allows the PMO to have a high-level view of potential problems and make strategic decisions to support multiple projects. #### How often should you update a RAID log? Review your RAID log during weekly status meetings and update it in real time whenever a new risk, issue, or key decision arises. - [專案管理](/resources/project-management) - [工作細目結構 (WBS)：WBS 是什麼，要如何使用？](/zh-tw/resources/work-breakdown-structure) 專案管理 #### 內容撰稿人 工作分解結構 (Work Breakdown Structure，簡稱 WBS) 是專案管理中最實用的可視化工具之一。當專案範疇複雜、交付項目眾多時，工作細目結構能將整個專案從最高層級逐步分解為可執行的具體任務，確保每項工作都有明確的負責人和完成日期。由於工作細目結構以可視化方式展示，因此可組合使用工作流程管理軟體與專案管理架構來建立。建立方法包括時間軸、 ... - [制定應變計劃以預防業務風險的 8 個步驟](/zh-tw/resources/contingency-plan) 商業策略 專案規劃 #### 作者 沒有人希望 A 計劃失效，但準備一份強大的 B 計劃是應對任何情況發生的最佳方式。有了可靠的後援計劃，您就可以有效應對非預期事件，並且盡快讓事情重回正軌。應變計劃是一種主動策略，能夠協助您處理事態惡化並確保業務持續進行。在本文中，深入瞭解如何針對非預期事件制定應變計劃，並且制定恢復策略，以確保您的業務維持健康狀態。什麼是業務應變計劃？業務應變計劃是一種策略 ... - [建立成功變更管理流程的 6 個步驟](/zh-tw/resources/change-management-process) 商業策略 靈感與影響力百寶箱 #### 作者 改變是幫助組織成功的必要元素。隨著企業成長，您不可避免地會需要實施新工具、嘗試新策略，或打入新市場，還有更多改變不勝枚舉。小規模的變更或不會衝擊很多人的變更，很容易實施，但若您需要實施徹底性的組織變革，又該怎麼做呢？若無妥善的規劃，而試圖實施組織變革可能導致混亂、困惑並降低公司的成長速度。您反倒是需要小心推出變革 (在正式變革之前就有制定好的計劃和支援)， ... - [15 個秘訣助您建立真正有用的待辦清單](/zh-tw/resources/make-better-to-do-lists) 專案管理 #### 作者 Everyone loves checking things off a to-do list, but when done wrong, lists can cause more harm than good. Disorganized lists lead to missed deadlines and unnecessary stress.The g ... - [Everything you need to know about creating a RAID log](/zh-tw/resources/raid-log) 專案管理 專案管理 - [作者](/author/sarah-laoyan) 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 projec ...