A surprising number of projects run on optimism, memory, and scattered Slack messages. That works right up until something important is forgotten. A RAID log exists to prevent exactly that. It gives the team one place to track the uncertainties and constraints most likely to affect delivery.
What a RAID Log Actually Is
RAID stands for Risks, Assumptions, Issues, and Dependencies. A RAID log is a simple working record that captures those four categories in a structured way. It is not meant to be decorative governance. It is meant to help a project team see what could go wrong, what is already going wrong, what the plan depends on, and what the project is currently taking for granted.
What Each Part Means
- Risks are uncertain events that might happen and affect the project if they do.
- Assumptions are things the plan currently treats as true, whether or not they have been proven.
- Issues are problems that already exist and now require active management.
- Dependencies are external inputs, decisions, teams, or deliverables that your progress relies on.
That distinction matters. Teams often mix risks and issues together, or hide assumptions inside timelines. Once that happens, the project loses visibility into what is forecast versus what is already real.
Why Good Teams Use RAID Logs
A RAID log is valuable because it improves the quality of project conversations. Instead of vague concern, the team gets explicit entries with owners, due dates, triggers, and response plans. That makes escalation cleaner, status reporting more credible, and delivery risk easier to explain to stakeholders who do not live in the details every day.
What Strong Entries Look Like
The best entries are specific enough to drive action. A weak risk says, 'Vendor delay.' A strong risk says, 'If the vendor API approval is not confirmed by June 10, integration testing slips by two weeks.' Specific wording forces the team to define impact, timing, and ownership. Without those elements, the log becomes a list of worries instead of a management tool.
How Often It Should Be Reviewed
RAID logs work when they are reviewed as part of the delivery cadence, not only before governance meetings. Serious teams revisit them in weekly project reviews, update entry status, close obsolete items, and add new dependencies as the plan evolves. If the log is only opened to prepare slides, it is already too late.
The Most Common Failure Mode
The failure mode is not complexity. It is neglect. Teams create a RAID log at project kickoff, populate it once, and then quietly abandon it. The fix is simple: keep it short, keep it current, and make each serious item answer four questions clearly. What is happening? Why does it matter? Who owns it? What happens next?
Explore more practical guides on project controls, risk, and delivery discipline.
Start for free →