In the complex world of project management, keeping track of potential issues, uncertainties, and dependencies is essential for delivering projects on time and within budget.
That is where the RAID log comes in. It is a simple yet powerful tool that helps project managers control and communicate risks, assumptions, issues, and dependencies throughout the project lifecycle.
In this blog, we break down what RAID stands for, why each component matters, how to build and use a RAID log, and how it enhances governance, visibility, and decision-making.
RAID is an acronym that represents four key categories of project control.
| RAID Element | Description |
|---|---|
| R – Risks | Potential events that could affect project success if they occur. |
| A – Assumptions | Things believed to be true at the time of planning but not yet confirmed. |
| I – Issues | Current problems that are impacting the project right now. |
| D – Dependencies | Tasks, decisions, or events that the project depends on, or that depend on it. |
These elements form the core of a RAID log, a central register that project teams and sponsors use to maintain awareness and control over project conditions.
Definition: Future events that may have a positive or negative impact on the project.
Examples:
Potential delay in vendor delivery.
Scope creep due to unclear requirements.
Opportunity to use a new tool that could speed up development.
A risk log includes:
Description.
Probability and impact.
Owner.
Mitigation or response plan.
Tip: Use a risk matrix to prioritise risks by severity.
Definition: Elements accepted as true for planning purposes but that could turn out to be false.
Examples:
Assuming stakeholders will approve documents within 48 hours.
Assuming all team members will be available during deployment week.
An assumption log includes:
Statement of assumption.
Rationale.
Potential impact if incorrect.
Validation plan.
Tip: Challenge assumptions during planning workshops to reduce surprises later in the project.
Definition: Problems that have already occurred and are affecting the project now.
Examples:
A key resource is unexpectedly unavailable.
A defect is discovered in a critical feature.
Budget approval is delayed.
An issue log includes:
Description.
Severity.
Owner.
Resolution plan.
Status (Open, Resolved, or Escalated).
Tip: Hold weekly issue review meetings and track resolution progress in real time.
Definition: Relationships between tasks or external conditions that impact delivery.
Examples:
Waiting on a vendor to complete security configuration.
Data migration must occur before training begins.
A marketing campaign cannot launch until legal review is finished.
A dependency log includes:
Description.
Type (internal or external).
Owner.
Due date.
Impact if delayed.
Tip: Link dependencies to milestones in your schedule or Gantt chart for visibility.
A RAID log can be created in various formats depending on the scale and needs of your project. Common tools include:
Excel or Google Sheets: Simple and shareable for smaller projects.
Microsoft Lists or SharePoint: Ideal for dynamic registers with team collaboration.
pmo365: Integrated RAID tracking across projects and portfolios.
Jira or Azure DevOps: Suitable for Agile teams managing equivalent risks and issues.
A typical RAID log should include columns such as ID, type (R/A/I/D), title, description, owner, status, impact, and next steps.
A RAID log delivers significant value by improving visibility, accountability, and governance. It provides:
Centralised visibility: All potential and active risks, issues, and dependencies in one place.
Proactive management: Enables teams to anticipate and mitigate problems early.
Better decision-making: Keeps sponsors and stakeholders informed with accurate data.
Improved documentation: Creates an audit trail for lessons learned and governance reviews.
Stronger stakeholder trust: Demonstrates control and transparency across the project lifecycle.
| Mistake | Impact | Fix |
|---|---|---|
| Not updating the RAID log | Becomes outdated and unreliable. | Assign an owner and review it regularly. |
| Logging vague items | Confuses accountability and action. | Be specific about each risk, issue, or dependency. |
| Ignoring assumptions | Hidden risks emerge later in the project. | Validate assumptions early and often. |
| Treating RAID as a checklist | Misses opportunities for proactive management. | Use it as a dynamic decision support tool. |
Real-world exampleA program manager leading a digital transformation initiative uses a live RAID log in Power BI. By integrating data from multiple project streams, they can quickly visualise where issues are emerging, which risks are trending, and which dependencies are at risk. This approach allows for real-time escalation and timely intervention to keep projects on track. |
A RAID log is more than a risk register. It is a central hub for effective project governance. By tracking risks, assumptions, issues, and dependencies, you empower your team to act early, communicate clearly, and maintain control throughout delivery.
If you can see it, you can manage it, and the RAID log gives you the visibility to do exactly that.