A RAID log is a single list of the things that could knock your project off course. RAID stands for Risks, Assumptions, Issues and Dependencies. Some teams use the A for Actions and the D for Decisions instead, and many track all six. The point is the same: one place where the team writes down what might go wrong, what has gone wrong, and who is dealing with it.
I have used RAID logs on every programme I have run from the client side. The good ones are short, current and owned. The bad ones are long spreadsheets that nobody opens between steering meetings. This guide explains what is in a RAID log, who owns it, why it is worth the effort, and what a good entry looks like.
What is a RAID log in project management?
Here are the four parts in plain words.
- Risks: things that might happen and would hurt the project if they did. For example, key users may not be released for testing.
- Assumptions: things you are treating as true without proof. For example, the current supplier contract can be extended for six months.
- Issues: problems that are happening now and need action. For example, the test environment has been down for three days.
- Dependencies: things your project needs from someone else, or that others need from you. For example, the new payroll system cannot go live until the HR data migration is finished.
The most common confusion is between a risk and an issue. The difference is time: a risk has not happened yet, an issue already has.
Risk
- Might happen in the future
- Rated by likelihood and impact
- Response: reduce, avoid, transfer or accept
- Owner watches it and acts early
- Becomes an issue if it happens
Issue
- Is happening now
- Rated by impact and urgency
- Response: fix it or escalate it
- Owner drives it to resolution
- Closed when the problem is solved
Assumptions deserve more attention than they get. Every assumption is a risk in disguise. If you assume the data is clean and it is not, you have an issue. Review your assumptions each month and either confirm them or turn them into risks.
Why use a RAID log?
Because problems that are written down get dealt with, and problems that live in people's heads do not. A RAID log gives you three things.
- Early warning. Risks get raised while there is still time and money to do something about them.
- Clear ownership. Every item has a named person, so nothing falls between workstreams.
- Better steering meetings. The sponsor sees the top risks and issues, and can make the decisions only they can make.
It also protects you. When something goes wrong, a dated RAID entry shows the risk was raised, who owned it and what was done. Your project status report should pull its top risks and issues straight from the log.
Who owns the RAID log?
The project manager owns the log itself. They make sure it is kept up to date, reviewed and reported. In a larger programme, a PMO analyst often maintains it day to day. But each item in the log has its own owner, and that person is responsible for acting on it.
- Risk owner: the person best placed to manage the risk, often a workstream lead.
- Assumption owner: the person who can confirm whether it is true.
- Issue owner: the person who will fix it, or escalate it if they cannot.
- Dependency owner: one person on each side, so both teams know the date that matters.
A RAID log example
Here is what one good entry looks like, using an illustrative ERP project. It is a risk raised in the build phase.
- ID and type: R-014, Risk
- Description: If finance key users are not released for user acceptance testing in March, testing will not finish before the quarter-end freeze.
- Likelihood and impact: High and high
- Owner: Finance workstream lead
- Response: Agree release dates with the finance director this week and book backfill cover.
- Due date and status: 14 February, Open
Notice the description. It names the cause, the event and the effect. That is what makes it useful in a steering meeting. Every entry, of any type, should pass this check.
What every RAID entry needs
- A clear description someone outside the team would understand
- A named owner, not a team
- A next action and a due date
- A rating, so the top items rise to the top
- A status that is updated at every review
How to run your RAID log each week
- Capture
Add new risks, issues and decisions from meetings the same day.
- Review
Walk the open items with owners each week. Update status and dates.
- Escalate
Move anything the team cannot solve to the steering committee.
- Close
Close items that are done, and turn risks that happened into issues.
Is a RAID log the same as a risk register? No. A risk register holds only risks. A RAID log holds risks alongside the other three, so you can see how they connect. Escalated items then go to your steering committee for a decision.
Are RAID logs used in agile? Yes, often. Sprints handle the work, but a large programme still has risks, assumptions and dependencies that sit above any single team. Many agile teams review the RAID log at sprint planning or in a weekly cross-team sync.
How ProjectCAPEX handles your RAID log
ProjectCAPEX has separate registers for risks, issues, actions and decisions. Risks are scored by probability and impact, shown on a heatmap, and can be converted to an issue when they happen. Dependencies link tasks in the plan and flag those that cross workstreams. Assumptions are recorded in the scope register.
The RAID Agent reads meeting minutes or notes and proposes risks, issues, actions and decisions. Nothing is added until you approve it. You can open the demo to see a live RAID log, or start a 14-day free trial.