In project management, uncertainty is not an exception; it is part of the operating environment. A RAID log is a structured tool used to capture, monitor, and manage four critical categories: Risks, Assumptions, Issues, and Dependencies. When maintained properly, it gives project teams a clear view of what could affect delivery, what decisions are based on, what problems already exist, and what work relies on other people, systems, or events.
TLDR: A RAID log helps project managers track risks, assumptions, issues, and dependencies in one controlled place. For example, if a software project depends on a third-party API being ready by 15 March, that dependency should be logged and monitored before it becomes a delivery issue. In a mid-sized project with 40 active tasks, even a 10% delay in critical dependencies can push the timeline back by several weeks if not managed early.
What Is a RAID Log?
A RAID log is a project management register that records key uncertainties and constraints affecting a project. It is commonly used in technology, construction, operations, consulting, product development, and business transformation projects. The main purpose is to support visibility, accountability, and informed decision-making.
Unlike informal notes or scattered email threads, a RAID log gives the project team a single reference point. It shows what has been identified, who owns it, what action is required, and the current status. This makes it valuable not only for the project manager but also for sponsors, stakeholders, delivery teams, and governance boards.
The Four Elements of RAID
1. Risks
A risk is something that may happen and could affect the project’s objectives. Risks can have a negative or positive impact, although most RAID logs focus heavily on threats to scope, time, cost, quality, or compliance.
Examples of project risks include:
- A key supplier may miss a delivery deadline.
- The project budget may be insufficient due to rising material costs.
- A new regulation may require redesign or additional testing.
- Specialist staff may become unavailable during a critical phase.
Each risk should normally include a clear description, likelihood, impact, owner, mitigation plan, and status. For instance, a risk might be recorded as: “There is a risk that user acceptance testing will be delayed because test users have not yet been confirmed.” The mitigation could be to obtain named testers by a specific date and escalate if confirmation is not received.
Good risk management is proactive. The purpose is not simply to document concerns; it is to reduce uncertainty before it turns into an issue.
2. Assumptions
An assumption is something believed to be true for planning purposes, even though it has not yet been fully confirmed. Projects rely on assumptions all the time: resource availability, stakeholder decisions, market conditions, technical feasibility, or customer behavior.
Examples of assumptions include:
- The client will provide feedback within five business days.
- The existing infrastructure can support the new application.
- Required subject matter experts will be available for workshops.
- No major changes to scope will be requested after sign-off.
Assumptions are important because they can quietly become risks or issues. If a project plan assumes that a database can handle 100,000 daily users, but no performance test has confirmed this, the assumption must be visible and validated. A strong RAID log helps teams challenge assumptions early rather than discovering false assumptions during delivery.
3. Issues
An issue is something that has already happened and is currently affecting the project. This is the key difference between a risk and an issue. A risk might occur; an issue is already real.
Examples of issues include:
- A vendor has missed a confirmed delivery date.
- The project team has lost access to a required testing environment.
- A stakeholder has rejected a signed-off design.
- A defect is blocking system integration testing.
Issues require action, ownership, and often escalation. A RAID log should show the severity of the issue, the person responsible for resolving it, target resolution date, current status, and any decisions required. Serious issues should not remain hidden in team discussions; they should be visible enough for leaders to remove blockers or approve corrective action.
4. Dependencies
A dependency exists when one task, deliverable, decision, team, supplier, or system relies on another. Dependencies matter because they often determine the true sequence of work. Even a well-resourced project can fail to meet deadlines if critical dependencies are not managed.
Examples of dependencies include:
- The development team cannot begin integration until the API specification is approved.
- Training materials depend on the final process design.
- A product launch depends on legal approval and marketing readiness.
- Testing depends on access to realistic data and a stable environment.
Dependencies should be tracked with due dates and owners. It is also useful to identify whether a dependency is internal or external. External dependencies, such as a government approval or third-party vendor task, often carry higher uncertainty because the project team has less direct control.
Why a RAID Log Matters
A RAID log is not just an administrative document. It improves project control by making hidden threats and constraints visible. Without it, teams often rely on memory, informal updates, or fragmented communication. That can lead to missed warnings, duplicated effort, and delayed escalation.
The RAID log supports better governance in several ways:
- Transparency: Stakeholders can see what may affect delivery.
- Accountability: Every item has an owner and expected action.
- Prioritization: Teams can focus on high-impact items first.
- Decision support: Leaders can make informed trade-offs based on evidence.
- Auditability: The project has a record of risks, decisions, and responses.
For example, in a six-month implementation project, a weekly RAID review may identify 25 risks, 12 assumptions, 9 active issues, and 15 dependencies. If only three of those items are critical, the project manager can focus senior attention where it matters most instead of overwhelming stakeholders with every detail.
What Should a RAID Log Include?
While formats vary, a practical RAID log usually includes the following fields:
- ID: A unique reference number for tracking.
- Category: Risk, assumption, issue, or dependency.
- Description: A concise explanation of the item.
- Impact: The expected effect on time, cost, scope, quality, or benefits.
- Likelihood: Used mainly for risks.
- Priority or severity: Helps rank attention.
- Owner: The person accountable for monitoring or resolving the item.
- Action plan: The next steps required.
- Due date: When action or resolution is expected.
- Status: Open, in progress, escalated, closed, or accepted.
The best RAID logs are simple enough to maintain but detailed enough to guide action. If the log becomes too complex, teams may stop updating it. If it is too vague, it will not support decisions.
How to Use a RAID Log Effectively
A RAID log should be reviewed regularly, not created once and forgotten. For most projects, a weekly review is appropriate. High-risk or fast-moving projects may require more frequent updates.
To use a RAID log effectively:
- Keep wording precise: Avoid vague entries such as “testing problem.” Explain the cause, impact, and required action.
- Assign real owners: Ownership should sit with someone able to influence the outcome.
- Separate risks from issues: This distinction is essential for proper escalation and reporting.
- Close items formally: Record why an item was closed and whether any follow-up remains.
- Escalate early: High-priority items should be raised before they threaten delivery milestones.
Common Mistakes to Avoid
Many RAID logs fail because they become passive records instead of management tools. A common mistake is listing items without owners or action dates. Another is allowing outdated entries to remain open for months, reducing confidence in the log. Some teams also record every minor concern, making it difficult to identify what truly matters.
A serious RAID process requires discipline. The project manager should challenge unclear entries, verify progress, and ensure that critical items are discussed with the right stakeholders. The value comes not from the document itself, but from the decisions and actions it enables.
Final Thoughts
A RAID log is one of the most practical tools for managing project uncertainty. By separating risks, assumptions, issues, and dependencies, it gives teams a structured way to understand what could go wrong, what is already going wrong, what must be confirmed, and what work relies on external inputs.
Used consistently, a RAID log strengthens governance, improves communication, and reduces the likelihood of unpleasant surprises. In serious project environments, it is not merely a reporting artifact; it is a core mechanism for control, accountability, and successful delivery.