A RAID log is a single document that tracks four things a project manager must never lose sight of: risks, assumptions, issues, and dependencies. It is one table, or four tabs of one spreadsheet, reviewed on a fixed cadence. The point is not the acronym. The point is that these four categories interact, and a team that keeps them in four separate places will never notice that the assumption which just broke has turned into the issue that is now blocking the dependency.
Two of the four letters are genuinely contested, and any guide that tells you otherwise is guessing. The A is used for both assumptions and actions. The D is used for both dependencies and decisions. Asana documents RAID as risks, assumptions, issues and decisions. Wrike and most PMO practice use dependencies. Neither is wrong. What matters is that your organization picks one expansion, writes it down, and stops relitigating it in every kickoff.
Key takeaways
- RAID stands for risks, assumptions, issues, and dependencies. Some organizations substitute actions for the A, or decisions for the D. Both variants are in common professional use.
- A risk has not happened yet and has a probability. An issue has already happened and has an owner and a date. Confusing the two is the most common failure in a RAID log.
- An assumption is a thing you are treating as true without proof. Every assumption is a risk with the probability field left blank.
- The log is worthless without an owner and a next review date on every single row. A row with no owner is a note, not a register.
- The project manager maintains the RAID log. The team populates it. The steering committee reads only the exceptions.
- Review weekly at project level. Roll only the escalated rows up to the portfolio, or the PMO drowns.
- A RAID log is not a replacement for a risk register on a large project. It is the lightweight form that works when a full register would go unread.
What does RAID stand for in project management?
RAID stands for risks, assumptions, issues, and dependencies. It is a project management acronym for the four categories of uncertainty and constraint that a project manager tracks continuously across the life of a project, recorded in one place so they can be reviewed together rather than separately.
| Letter | Register | The question it answers | Time direction |
|---|---|---|---|
| R | Risks | What might go wrong that has not gone wrong yet? | Future, probabilistic |
| A | Assumptions | What are we treating as true without having verified it? | Present, unproven |
| I | Issues | What has already gone wrong and is hurting us now? | Present, certain |
| D | Dependencies | What do we need from someone we do not control? | Future, external |
The four are not independent, which is the whole argument for one log. An assumption that fails becomes an issue. A dependency that slips becomes a risk, then an issue. A risk that materializes becomes an issue. Read as four separate documents, these transitions are invisible. Read as one, they are the story of the project.
Does the A in RAID mean assumptions or actions?
Both are used. Assumptions is the more common expansion in PMO practice and in PRINCE2-influenced organizations, because an unverified assumption is a live source of risk. Actions is used by teams who want the log to double as a task tracker. If your team already has a task tracker, use assumptions. The action variant tends to fill the log with routine to-dos and bury the four rows that actually matter.
Does the D in RAID mean decisions or dependencies?
Both are used, and this one is worth thinking about rather than defaulting. Dependencies is the traditional expansion and the more useful one on any project with external interfaces. Decisions is favored by teams who have been burned by decisions getting remade, and who want a durable record of what was decided, by whom, and on what date. Some organizations run RAIDD with both. That is clumsy, and it works.
If you drop dependencies from the log, track them somewhere. On a portfolio of any size they are the single largest source of unplanned delay, and the mechanics of finding them are covered in project dependency management.
Risks and issues are not the same thing
The distinction is simple and teams get it wrong constantly. A risk is a future event with a probability attached. An issue is a present fact with a cost attached. "The vendor may miss the integration date" is a risk. "The vendor missed the integration date" is an issue. The moment the first becomes the second, the response changes entirely: you stop mitigating and start recovering.
Practically, this means a RAID log needs a transition rule and someone whose job is to apply it. When a risk materializes, close the risk row, open an issue row, and reference the closed risk from it. That reference is the most valuable data the log ever produces, because after two or three projects it tells you which of your risk categories you consistently underestimate. Most organizations discover they are excellent at predicting technical risk and blind to organizational risk.
Risks that are large, quantified, and owned at portfolio level belong in a full project risk register rather than in a RAID row. The register carries probability, impact, exposure value, mitigation and residual risk. A RAID log carries a sentence. Use the register when the number matters and the RAID log when the attention matters. On a portfolio, the aggregate of those registers is what portfolio risk management actually manages.
Assumptions are risks with the probability left blank
An assumption is something the plan depends on being true, which nobody has confirmed. "Legal review takes two weeks." "The data migration can run over a single weekend." "The finance team will have capacity in Q3." Each of these is load-bearing. Each is unverified. Each will quietly become an issue if it is wrong, and the project will be surprised, even though it wrote the assumption down at kickoff and never looked at it again.
The discipline that makes the assumptions register earn its place is a validation date on every row: the date by which this assumption must be confirmed or converted into a risk. Assumptions without validation dates are decoration. When the date arrives and nobody has checked, that is itself the finding.
A worked example, illustrative rather than drawn from a specific engagement: a systems replacement assumes the incumbent vendor will export historical data in a usable format. Nobody validates it because the contract says they must. Four months in, the export arrives as a proprietary binary, and a two-week task becomes a two-month reverse-engineering effort. The assumption was recorded on day one. It was never assigned a validation date, and so it was never anyone's job.
Dependencies are the rows that outlive the project
A dependency is anything your project needs from someone your project manager does not control: another project's deliverable, a vendor's release, a regulatory approval, a shared platform team's capacity. They belong in the RAID log because they are the constraint most likely to be discovered late and least likely to be resolvable by effort.
Two properties make a dependency row useful. First, name the person on the other side, not the team. Teams do not commit to dates. People do. Second, record the date you need it by and the date they have committed to, in two separate columns. The gap between those columns, summed across the portfolio, is the most honest schedule risk report a PMO can produce. Worked examples of the common types are in project dependencies examples, and the technique for surfacing them systematically is in dependency mapping.
What columns should a RAID log have?
A working RAID log needs seven columns and resists the eighth. Every additional field is a field that will be left blank, and a log with blank fields trains people to skim it.
| Column | Why it exists |
|---|---|
| ID | So it can be referenced in minutes and in a status report without being retyped. |
| Type | Risk, assumption, issue, or dependency. Enables filtering and the transition rule. |
| Description | One sentence stating the condition and its consequence. Not a paragraph. |
| Owner | A named person. Never a team, never the PM by default. |
| Raised date | Aging is the signal. A 90-day-old open issue is a governance failure, not a project one. |
| Next action and due date | What happens next, by when. Without this the row is an observation. |
| Status | Open, closed, or escalated. Three values. Not eight. |
Severity or priority is the defensible eighth column, and only if it drives behavior, which usually means only the escalated rows carry it. The full copyable layout, with the per-type fields that differ between a risk row and a dependency row, is set out in the RAID log template.
Who owns the RAID log?
The project manager owns and maintains the log. The team populates it, because the people doing the work see the risks first. The sponsor and the steering committee read only the escalated rows, and they read them before the meeting rather than during it.
The failure mode here is subtle. When the PM is the only person who ever adds a row, the log stops being a picture of the project and becomes a picture of what the PM happens to know. The fix is procedural: every team lead brings one new RAID item to the weekly review, or explains why there isn't one. That sounds like theater for about three weeks, and then it starts surfacing things.
How often should a RAID log be reviewed?
Weekly, at the project team meeting, as a standing agenda item that runs on exceptions rather than a read-through of every row. Review new rows, rows whose due date has passed, and rows whose status changed. A full line-by-line review is appropriate monthly, and at every stage gate, where the gate reviewer should be asking which assumptions have still not been validated.
Escalated rows go to the steering committee on its own cadence. Nothing else does. A steering committee handed a 60-row RAID log will read none of it, and the three rows that needed a decision will be lost among the fifty-seven that needed nothing.
How a PMO uses RAID across a portfolio
At project level a RAID log is a delivery tool. At portfolio level it becomes an early-warning instrument, but only if the PMO resists the urge to aggregate everything. Rolling 40 project logs into one master log produces a document nobody reads. What works is rolling up three things and ignoring the rest.
- Escalated rows only. Anything the project manager has formally escalated, with the date it was escalated. Escalation aging across the portfolio is the single best measure of whether governance is actually deciding anything.
- Cross-project dependencies. Every dependency row whose counterparty is another project in the portfolio. These are the rows no individual project manager can resolve, and they are precisely what a PMO exists to resolve. Sum the gap between needed-by and committed-by dates and you have your portfolio's real schedule exposure.
- Assumptions past their validation date. Cheap to collect, and a startlingly good predictor of which projects are about to surprise you.
Those three roll-ups belong on the portfolio dashboard, not in an appendix. The reporting cadence that makes them visible without generating a monthly document nobody opens is covered in PMO reporting and portfolio dashboards, and the specific artifact in the project portfolio dashboard. Where the escalated rows land, and who is allowed to decide on them, is a question of project governance.
Frequently asked questions
What is a RAID log used for?
A RAID log is used to track risks, assumptions, issues and dependencies in one place so a project manager can review them together on a fixed cadence. It gives governance a single reference for what is uncertain, what is broken, and what the project is waiting on, and it creates an auditable record of when each item was raised and who owned it.
Is a RAID log a risk register?
No. A risk register covers risks only, in depth, with probability, impact, exposure value and mitigation. A RAID log covers four categories at a summary level, usually one sentence per row. Large or regulated projects run both: the RAID log for weekly attention, the register for quantified analysis. Small projects run only a RAID log.
What is the difference between a risk and an issue in a RAID log?
A risk has not happened and carries a probability. An issue has already happened and carries a cost. When a risk materializes, close the risk row and open an issue row that references it. Tracking those transitions across projects reveals which categories of risk your organization consistently underestimates.
What is an assumption in a RAID log?
An assumption is a condition the plan depends on that has not been verified. It should carry a validation date: the day by which someone must confirm it or convert it into a risk. Assumptions recorded at kickoff and never revisited are the most reliable source of late surprises on a project.
What is RAID analysis?
RAID analysis is the review activity, not the document. It means working through the four registers together, checking which assumptions are now unvalidated, which risks have materialized into issues, and which dependencies have slipped, then deciding what changes as a result. The log is the artifact. The analysis is the meeting where it earns its keep.
Is a RAID log used in agile?
Yes, though rarely under that name. Impediments map onto issues, and most teams track them on the board. What agile teams routinely lose are assumptions and cross-team dependencies, because neither fits a sprint backlog. Scaled frameworks reintroduce them explicitly: SAFe's program board is a dependency register drawn as a wall, which is exactly the D in RAID.
Who should attend a RAID log review?
The project manager, every team lead, and anyone who owns an open row with a due date inside the next two weeks. The sponsor does not attend. The steering committee does not attend. They receive the escalated rows in advance and arrive to decide on them, which is a different meeting with a different purpose.
How many items should a RAID log have?
There is no correct number, but two patterns signal trouble. A log with fewer than about ten open rows on a project of real size means the team is not raising things. A log with more than roughly fifty means nothing is ever being closed, and the register has become an archive that people have stopped reading.