The OTR GroupA RAID log is one of the simplest tools in project management, and one of the easiest to neglect. RAID is a common shorthand for Risks, Assumptions, Issues and Dependencies. This how-to sets out a light-touch way to keep one so that it helps the team rather than becoming a document that is created once and forgotten.
Step 1: Know what each letter means
Risks are things that might happen and would affect the project. Assumptions are things you are treating as true without having confirmed them. Issues are problems that are happening now. Dependencies are things your project needs from someone else, or that someone else needs from you. Keeping the four apart matters because each needs a different response: a risk needs a plan, an assumption needs checking, an issue needs fixing and a dependency needs a conversation.
Step 2: Keep it on one page
A log that runs to dozens of pages will not be read. Start with one page, in whatever format your team already uses, such as a spreadsheet or a shared document. If it grows beyond a page, that is a sign to close old items and to ask which entries still matter.
Step 3: Give every entry an owner and a date
An entry without a named owner is a wish. For each line, record who is responsible, what the next action is and when it will be reviewed. This echoes a principle that runs through UK government risk guidance, such as the Orange Book: risk management works best when it is a part of everyday decisions and when responsibility is clear.
Step 4: Write entries so a stranger could understand them
Describe the cause, the event and the effect in one sentence. "Supplier may deliver late, which could delay testing by two weeks" is far more useful than "supplier problem". If you cannot explain an entry to someone outside the project, it is probably too vague to manage.
Step 5: Review it on a fixed rhythm
Pick a regular weekly slot of fifteen minutes and protect it. Walk down the page in order: any new risks, any assumptions that have been proved or disproved, any issues that need escalating and any dependencies at risk of slipping. Close what is finished. A short review every week beats a long one every quarter.
Step 6: Turn assumptions into facts early
Assumptions are the quiet source of many project surprises. Each one should have a note of how and when it will be checked. When an assumption proves false it becomes a risk or an issue, so move it across rather than deleting it, and keep the history.
Step 7: Escalate with an ask
When something is beyond the team's control, take it to the sponsor or board with a specific request: a decision, a resource or a change of scope. A log that records a problem but never prompts a decision is only half used.
Common pitfalls
- Treating the log as a compliance exercise rather than a working tool.
- Recording only risks and forgetting assumptions and dependencies.
- Letting entries sit for months without review.
- Having one person keep the log alone, instead of the team contributing.
A final thought
The best RAID log is the one your team opens every week. Keep it short, keep it honest and keep it owned. The format matters far less than the habit.
This is general practitioner guidance for project teams. Check any governance requirements that apply in your organisation or programme.