What a RAID log is designed to do
A RAID log — tracking Risks, Assumptions, Issues, and Dependencies — is commonly introduced once a project moves into execution. Its purpose is to make threats to time, cost, and quality visible early, before they turn into surprises.
Risks
Things that might happen and would negatively affect the project if they do. Tracked with likelihood and impact.
Assumptions
Things you are treating as true for planning purposes. If an assumption proves wrong, it often becomes a risk or issue.
Issues
Problems that have already materialised and need active management or escalation. Risks that have crystallised.
Dependencies
Things the project relies on from outside its control — other teams, vendors, decisions, or deliverables.
The question: The theory is clear. But in practice, RAID logs are often created at project kick-off, added to once or twice, then sit untouched until the project review. Does the format itself create value — or is the value entirely dependent on how actively it’s used?
Where RAID tends to work best
Based on the framework’s design and early practitioner input, RAID is most effective in projects with specific characteristics.
Projects where RAID typically delivers value
- Fixed timelines and budgets where surprises have a direct cost
- Multiple stakeholders or vendors whose actions affect each other
- Significant interdependencies across teams or workstreams
- Environments where the sponsor wants active visibility of what could go wrong
- Projects with a governance structure that regularly reviews risk status
How was RAID used in your project? Did it actually help?
This survey collects real experiences from practitioners who have used RAID in live projects. Not theory — what actually happened.
Responses are anonymous and voluntary. Share your experience with context →
What practitioners are saying (early patterns)
This section evolves as responses come in. Early patterns focus less on the tool itself and more on the conditions that determined whether it delivered value.
Review frequency is everything
RAID logs updated weekly in steering meetings had dramatically different outcomes than those updated at project milestones. Frequency drives relevance.
Psychological safety to raise risk
In cultures where raising risks was seen as negativity or complaining, RAID logs were filled with low-severity items. High-impact risks stayed undocumented.
Sponsor involvement signals intent
When the sponsor actively engaged with the RAID log — asking about specific risks, escalating issues — the team treated it as a live tool. Without that, it was ceremonial.
Assumptions are underused
Most practitioners report that the Assumptions column is the least maintained. Yet assumptions that prove wrong are often the root cause of the biggest project surprises.
Patterns matter more than percentages. A tool that works well in one type of project and fails in another gives you something actionable — a decision about fit, not just an average success rate.
How to interpret this experiment
This is not a scientific study. Responses are voluntary and context-dependent. The intent is to surface patterns, not universal truths.
If a RAID log “didn’t work” in your experience — the question is not who maintained it poorly, but what conditions made the format the wrong fit for that environment. We document both what worked and what didn’t, with the context that explains it.
Survey results are directional and will evolve as more responses come in. Insights are always shared with their limitations stated clearly.
Not sure which risk management approach fits your project?
Beyond Theory Guide asks about your project type, team structure, governance model, and constraints before recommending any framework or tool.
Try the advisor free →