The OTR GroupMost projects do not fail because nobody knew something might go wrong. They struggle because the worry lived in someone's head, an old email or a meeting that nobody minuted. A RAID log gives those worries a home. This guide explains what the letters stand for, how to build a simple log and how to keep it alive.
What RAID stands for
Risks are things that might happen and would affect the project if they did. Assumptions are things you are treating as true without having proved them. Issues are problems that have already happened and need action now. Dependencies are things your project needs from someone else, or that someone else needs from you.
The difference between a risk and an issue trips people up. If it might happen, it is a risk. If it has happened, it is an issue. A supplier who may be late is a risk; a supplier who has missed the date is an issue.
Why bother with one log?
Keeping the four lists together shows how they connect. An unchecked assumption often becomes a risk, a risk that lands becomes an issue and a late dependency is frequently the cause of both. Seeing them side by side makes it easier to spot patterns and to decide what deserves attention this week.
Setting up a simple log
A spreadsheet is enough. Use one tab or table, with a column saying which of the four types each row is, or use four tabs if you prefer. Useful columns include:
- a short reference number;
- a one-sentence description written so a newcomer would understand it;
- the date it was raised;
- a named owner (a person, not a team);
- the next action and the date it is due;
- a simple status such as open, in progress or closed.
Writing good entries
For a risk, try the pattern "because of [cause], [event] might happen, which would lead to [effect]". It forces you to say what is actually worrying you. For an assumption, add how and when you will check it. For an issue, state what is affected and what is being done. For a dependency, name who you are relying on and the date you need their input.
A weekly rhythm
- Review the open items. Ask the owner for an update on each, in a few minutes, at your regular project meeting.
- Close what is done. Keep closed items in the log so you can see what was dealt with.
- Re-read the assumptions. Has anything been confirmed, or has anything changed?
- Add what is new. Invite the team to name anything that is worrying them.
- Escalate what you cannot fix. If an item needs a decision above your level, say so plainly and set a date.
Common pitfalls
Logs go stale when no one owns them, when entries are vague and when they are only opened at the end of a project. Avoid very long logs that no one reads; it is better to have fifteen clear lines than a hundred forgotten ones. And remember that the log supports conversation. It does not replace it.
A final thought
A good RAID log is modest and useful. It reminds the team what could go wrong, what they are counting on and who is responsible for the next step. Start small, review it weekly and let it grow only when it earns its place.
This article gives general project management information. Definitions and templates vary between organisations, so follow your own governance standards where they differ.