You’re three weeks into a project when a “surprise” blocker derails your timeline — except it wasn’t really a surprise. Someone flagged it as a risk in a hallway conversation weeks ago, but it was never written down, tracked, or escalated. That’s the gap RAID closes. This blog explains what RAID is, why it’s one of the most practical tools you’ll use as a project manager, and how to start using it on your very next project.
What Does RAID Stand for in Project Management?
RAID is an acronym for Risks, Assumptions, Issues, and Dependencies — the four categories of uncertainty that can quietly derail a project if they’re not tracked in one place. A RAID log is simply a structured document (often a single spreadsheet or table) where a project manager records and monitors all four, giving the whole team one shared view of what could go wrong, what’s being assumed, what’s already gone wrong, and what the project depends on.
For beginners: a Risk is something that might happen and could impact the project (a vendor might deliver late). An Assumption is something you’re treating as true without full proof (assuming the client’s IT team will grant access on time). An Issue is a risk that has already happened and now needs resolving. A Dependency is anything the project relies on outside its direct control, like another team’s deliverable or a third-party approval. If you want the full breakdown of each category with examples, our companion guide on What Does RAID Stand for in Project Management? goes deeper into each element individually.
Why Does a RAID Log Actually Matter for Project Success?
A RAID log matters because inadequate risk management remains one of the leading, preventable causes of project failure — and RAID is the simplest tool for catching those risks before they become issues. According to 2026 project management research, inadequate risk management is cited as a factor in roughly 17% of project failures, making it one of the top two or three causes behind failed delivery.
The pattern shows up again in complexity data: PMI’s Pulse of the Profession 2026 report found that teams highly effective at managing complexity achieve an 88% project success rate, compared to just 14% for teams that manage it poorly — a fivefold difference driven largely by how well those teams identify and track emerging risks and dependencies. A RAID log is one of the most direct, lightweight ways to build that discipline into your own project practice, without adding heavy process overhead.
How Do You Build and Maintain a RAID Log?
You build a RAID log by creating four simple sections — Risks, Assumptions, Issues, Dependencies — and reviewing all four with your team on a fixed cadence, not just at kickoff. Each entry should have an owner, a status, a date raised, and a next action; an entry with no owner is an entry nobody will act on.
- Set it up early. Start your RAID log during project initiation, before work begins, so assumptions are captured while they’re still fresh in stakeholders’ minds.
- Review it weekly. Walk through open items in your regular status meeting — this is where risks get caught before they become issues, and where stale assumptions get challenged before they cause scope problems (a common trigger for scope creep).
- Escalate dependencies early. External dependencies are often the hardest to control, so flag them to stakeholders as soon as they’re identified, not when they’re about to slip.
- Close the loop. Update status as items resolve, and don’t delete closed items — they’re useful lessons-learned data for your next project and directly protect the triple constraints of time, cost, and scope.
In over 15 years of managing projects, the single habit that separated smooth deliveries from chaotic ones was almost always this: a living RAID log the whole team actually looked at, not a document created once and forgotten.
Frequently Asked Questions About RAID in Project Management
A risk is a potential future event that hasn’t happened yet, while an issue is a risk (or unexpected problem) that has already occurred and now requires active resolution.
The project manager typically owns and maintains the RAID log, but individual entries should be assigned to specific team members who are best placed to monitor and act on them.
Most project managers review and update their RAID log weekly, alongside regular status meetings, so new risks and issues are caught early rather than discovered late.
RAID logs align closely with the risk and issue management concepts covered in the PMBOK 8th Edition and are a practical tool PMP-certified project managers commonly use on the job.
Yes. Many Agile teams maintain a lightweight RAID log alongside their backlog, reviewing it during sprint planning or retrospectives to keep risks and dependencies visible.
Want to see exactly how experienced project managers build and run a RAID log on real projects? Subscribe to PMPwithRay on YouTube for practical, real-world PM tutorials, or go deeper with my structured courses on Udemy — built to take you from theory to confident, on-the-job execution.