The RAID Log Explained: Risks, Assumptions, Issues, Dependencies

A RAID log is a single table where a project team records four things it must keep an eye on: Risks, Assumptions, Issues and Dependencies. Each line gets a short description, one named owner, a status and the date it will next be checked. The Institute of Risk Management (IRM), in a short guide from its infrastructure risk group, calls it a tool for spotting and managing the risks and issues a project or programme may face, and recommends starting one during planning on large, complex projects.¹

The log is part of the everyday machinery of project management, and it is simple to set up. No study we located has tested whether keeping a RAID log makes projects more successful; its support comes from professional guidance and practitioners’ experience. So the hard part is keeping the log alive. Five steps get one running this week:

1. Agree what your four letters stand for.
2. Set up the four lists with a few columns each.
3. Fill it in a short planning workshop.
4. Give every line one owner and a date.
5. Review it on a fixed rhythm, and close lines as you go.

What does RAID stand for in project management?

RAID usually stands for Risks, Assumptions, Issues and Dependencies, but the letters are not fixed. The IRM’s short guide notes that some teams put Decisions in place of Dependencies, and that some combine actions and decisions into a longer “RAAIDD” log.¹ The University of Waterloo’s project office in Canada uses Risks, Actions, Issues and Decisions.²

The variation exists because the acronym is a convenience, not a standard. Each team logs whatever it most needs to stop forgetting. A team that keeps losing track of who promised what adds Actions. A team whose sponsor keeps reopening settled questions adds Decisions, with the date and who made the call. A team that leans on other departments and suppliers keeps Dependencies.

Agree the letters before the first entry and write them at the top of the log. Two people who read “D” differently will put a supplier’s delivery date in one place and a steering-group decision in the other, and the review will miss both.

A risk might happen; an issue is already happening

The difference between a risk and an issue is timing. PMI, the US-based professional association for project managers, defines a risk as an uncertain event or condition that would affect the project’s objectives if it occurs, and an issue as a current condition that may affect them.³ A risk is about the future; an issue is about now.

That timing changes what you do with each one. A risk calls for prevention or preparation: someone watches for the warning signs and decides whether to act early. An issue calls for a fix, because the damage is already under way. Waterloo’s guidance makes the link explicit: if a risk occurs, move it to the issues list and name someone accountable for resolving it.²

The other pair is easier to mix up. PMI defines an assumption as something treated as true in planning without proof, and a dependency as a relationship in which the timing or completion of one activity hangs on another.³ The 2017 glossary of the PRINCE2 project method adds a useful filter: assumptions worth recording are the ones that would force considerable replanning if they turned out to be wrong.⁴

1. Assumption: treated as true for planning but not yet confirmed; once you start to doubt it, log the doubt as a risk (our suggestion)
2. Risk: might happen and would affect the objectives; if it happens, it moves to the issues list
3. Issue: is happening now and needs an owner and an action
4. Dependency: something the work needs from another task, team or supplier; one that may arrive late is a risk to log (our suggestion)

PRINCE2’s definition of an issue is broader than PMI’s. It covers concerns, queries, suggestions and requests for change raised during a project.⁴ That matters in practice, because many “issues” logged in a meeting are really someone asking for more work. Those belong in the separate routine for handling scope creep and requests for change, not in a list of problems to fix.

What columns should a RAID log have?

A RAID log needs only a handful of columns per list, and each list needs slightly different ones. The IRM guide suggests a description, probability, impact, response and responsible person for risks; a description and potential impact for assumptions; and a description, impact and resolver for issues.¹ Waterloo adds triggers for risks, and dates for actions and decisions.²

The table below shows a compact column set for each list, with an example line from one small project: moving a team of about 30 people to a new office floor over a weekend. The example is illustrative, not taken from a real project.

Notice what each example line includes: a single owner and something checkable. “Furniture might be a problem” is not a risk entry; “the desks arrive late” is, because someone can watch for it and act. Wikipedia’s summary of common practice lists a few more columns that registers often carry, such as a risk category and a score that multiplies likelihood by impact.⁵ Add those only when you have enough lines to need sorting.

Is a RAID log the same as a risk register?

No. A risk register holds risks only; a RAID log keeps risks beside assumptions, issues and dependencies. PMI defines a risk register as the place where the outputs of risk management are recorded, and defines a separate issue log and assumption log.³ PRINCE2 also keeps separate records: a risk register, an issue register for issues handled formally, and a daily log for minor problems the project manager can handle informally.⁴

Our suggestion is to let size decide. A large programme with a risk team, scoring rules and contingency budgets is likely to need a full risk register, and may keep its RAID log as the short, shared view that links to it. In our view, a small project rarely needs both: one RAID log, with the risks tab doing the register’s job, keeps everything in one place for one review. How to score and rank risks in a formal register, and the wider risk process around it, deserve their own guides.

If your organization already requires a risk register, do not copy the same risks into a RAID log. Keep the risks in one place and point to them, or the two copies will drift apart within a month.

Who owns and updates the RAID log, and how often?

The project manager usually keeps the RAID log, while each entry has its own owner. Waterloo’s project office says the author and maintainer is often the project or programme manager, that others may update parts of it (especially issues), and that the manager decides who can edit and how versions are controlled.² PMI’s lexicon gives each risk a risk owner who monitors it and chooses the response.³

How often to review it is a judgement call, and the little evidence there is comes from interviews, not trials.

The study

Limited evidence

Monthly, mostly: how UK construction managers said they review risk registers (2012 study)

In interviews with ten project managers from seven UK organizations, the register was generally reviewed monthly by the project team; one manager reviewed it every three to six months and at key project gateways. Seven of the ten called it an extremely significant tool, and the authors called for research on whether registers help control project risk.⁶

This is a small conference study of one industry in one country, about risk registers rather than full RAID logs, so treat it as a description of practice, not proof of what works. A faster-moving project may need a faster rhythm. In a 2021 post on the Association for Project Management (APM) blog, a programme assurance specialist described the RAID log she set up for her own wedding, to be reviewed at least every two weeks.⁷

A useful rule: review the log at least as often as things change. For a project with weekly team meetings, ten minutes at the end of that meeting is usually enough. Go through items due for review, ask each owner for one line of update, and close anything finished.

How to start a RAID log this week

These five steps adapt the IRM’s four-step method for a small team with no special tools.¹ They are practical guidance rather than tested methods, so adjust them to your project.

1. Agree what your four letters stand for

Decide in one conversation whether your D means dependencies or decisions, and whether you need an actions list. Write the agreed meaning at the top of the log, along with the level of detail you will record. The IRM warns that a log which records every small decision becomes cluttered and hard to search.¹

2. Set up the four lists with a few columns each

Use whatever the team already opens every day: a shared spreadsheet with one tab per list is enough. Copy the column sets from the table above and resist adding more until you miss one.

3. Fill it in a short planning workshop

Gather the core team and the sponsor for an hour early in the planning phase of the project life cycle. Ask four questions in turn: what could go wrong, what are we taking for granted, what is already a problem, and what do we need from outside the team? Waterloo also suggests looking at the risks and issues logged on similar past projects.² Nine of the ten project managers in the UK interview study above described a risk workshop or brainstorm as their first step in identifying risks.⁶

4. Give every line one owner and a date

Put one name on every line, even when a group will do the work, and set a date for the next check. Owners should agree to their lines in the workshop rather than discover them later.

5. Review it on a fixed rhythm, and close lines as you go

Put the review in the calendar now. At each one, update status, move any risk that has happened onto the issues list, and close lines that no longer matter. At the end of the project, Waterloo suggests one last pass: which risks happened, which did not, and what goes into the lessons learned.²

Your first RAID log

• Agree what R, A, I and D stand for on this project
• Set up one shared sheet with a tab for each list
• Hold a planning workshop to fill it
• Name one owner and a next-check date for each line
• Book a short, regular review in the calendar
• Move risks that happen onto the issues list
• Close finished lines at each review

Why RAID logs get filled once and never read

A RAID log often fails in a simpler way than a missing column: nobody reads it. Matthew Poole, a project manager at T-Systems, made the point in a 2014 APM blog post that ran as a sponsored blog from his employer, headline sponsor of APM’s awards that year: most project managers have such a log, he observed, before asking how many really use one. The usual complaint he named was having no time to keep it up.⁸

A log nobody reads can be worse than none, because it suggests control that is not there. Helga Drummond argued in a 2011 discussion paper that risk registers can create an illusion of control: the list on the screen gets mistaken for the situation on the ground.⁹ In a published reply, Alexander Budzier argued that registers are still useful as a shared basis for talking about risk inside and outside an organization, and should be judged by how well they support that conversation rather than by how accurate they are.¹⁰ Our reading of both was limited to their abstracts.

Myth

Once the RAID log is filled in, the project's risks are managed.

Fact

The log only records risks. They are managed when an owner acts on a line and the team reviews it on a regular rhythm.

Without outcome studies, there is no evidence that a well-kept log beats no log, only reasons to expect it. Even for risk management as a whole, its value is not a settled question. A 2019 interview study in the International Journal of Project Management found that the value people saw in risk management practices depended on what each stakeholderstakeholder: In project management, anyone who can affect a project, be affected by it, or believe they are affected by it: an individual, a group or an organization. That includes users, suppliers and colleagues whose work changes, not only the people paying.Full entry in the glossary cared about.¹¹

The warning signs of a dead log are easy to spot: review dates in the past, owners who have left the project, issues that have been “in progress” for months, and a risks list that has not changed since kickoff. When you see them, cut the log back to the lines people will discuss, re-assign owners, and restart the review with whatever remains.

The bottom line

Keep four short lists in one shared place, each line naming its owner and its next date: what could go wrong, what you are assuming, what has already gone wrong and what you are waiting for. Agree what your letters mean, keep the columns few, and give the log ten minutes at a meeting the team already holds.