1. Keep the four categories genuinely distinct
RAID only works if Risks, Assumptions, Issues, and Dependencies mean different things. A risk is something that might happen; an issue is something that already has. An assumption is a belief you’re treating as true but haven’t confirmed; a dependency is something you need from someone else to make progress.
When teams blur these — logging issues as risks, or burying dependencies in the risk column — the log loses its diagnostic value. Clean categories are what let you see, at a glance, what to worry about versus what to fix versus what to chase.
2. Give every entry an owner and a date
An entry with no owner is a wish. Every risk, issue, and dependency needs one accountable name and a date — a review-by date for risks, a resolve-by date for issues, a required-by date for dependencies. Ownership is what turns a list into action.
“The team” is not an owner. If everyone owns it, no one does. Assign a specific person who is accountable for driving the entry to closure, even if others do the work.
3. Score risks by exposure, not by vibes
Rate each risk on likelihood and impact, and use the combination to prioritize. This keeps attention on the risks that genuinely threaten the outcome rather than the ones that are simply top of mind or loudest in the room.
Exposure scoring also drives good escalation: a high-likelihood, high-impact risk deserves executive visibility and a funded mitigation, while a low-exposure one can be watched. Without scoring, every risk feels equally urgent, which means none of them are.
4. Turn assumptions into validation tasks
Assumptions are unvalidated facts, and unvalidated facts are risks in disguise. “We assume the legacy data is clean” is fine — until it isn’t, mid-migration. For every material assumption, create a task to confirm or kill it, with an owner and a deadline.
The discipline of validating assumptions early is one of the cheapest forms of risk management there is. The assumption you test in week two is a headline you avoid in week twelve.
5. Manage dependencies as commitments with dates
Dependencies are where projects quietly slip, because they live outside your direct control — another team’s deliverable, an access grant, a vendor, a decision. Track each as a commitment with a named provider and a required-by date, and follow up on them like any other critical-path item.
The most dangerous dependencies are the ones nobody is actively chasing. Review them on a cadence and escalate the moment a required-by date is at risk, not after it’s missed.
6. Review on a cadence and escalate by impact
A RAID log is a living document or it is nothing. Build a regular review into your governance rhythm — weekly for active items, with a deeper pass at steering-committee cadence — and use it to drive escalations based on impact rather than volume.
The review is where the log does its real work: reprioritizing, chasing owners, closing what’s done, and escalating what needs a decision. Ten minutes of disciplined review beats a hundred rows nobody reads.
7. Close the loop and retire stale entries
When a risk passes, an issue resolves, or a dependency lands, record the outcome and close it. A log cluttered with stale, resolved, or duplicate entries loses credibility fast, and a log people don’t trust is a log they stop using.
Capturing outcomes also builds a small institutional memory — the risks that materialized, the assumptions that proved false — that makes your next project’s RAID log sharper from day one.