The short answer
A RAID log is one table that tracks a project’s Risks, Assumptions, Issues and Dependencies. Each entry gets a score (probability × impact, each out of 5), a trigger that shows it is happening, one owner and a response. Fill it with a pre-mortem: imagine the project has already failed and list why. Review it weekly, and show leadership only the top five.
What the four letters mean
| Letter | What it is | Example |
|---|---|---|
| Risk | Something that may happen and would hurt the project | The one engineer who knows a system leaves |
| Assumption | Something the plan treats as true but nobody has confirmed | Customers accept a signature captured offline |
| Issue | A risk that has already happened | A key component is nine days late |
| Dependency | Something the project needs from outside the team | App store review before release |
The log puts all four in one place because they turn into each other. An unconfirmed assumption is a risk; a risk that happens becomes an issue; a dependency that is late becomes an issue on the critical path.
The columns of a RAID log
| Column | What goes in it |
|---|---|
| ID | R1, A1, I1, D1, so entries can be referred to in meetings |
| Entry | Written as cause and effect: “Because X, Y may happen” |
| Score | Probability (1–5) × impact (1–5), so 1 to 25 |
| Trigger | The observable sign that the risk is happening |
| Owner | One named role, not “the team” |
| Response | Avoid, mitigate, transfer or accept, with its cost |
| Review date | When it is next checked |
The four standard responses: avoid (change the plan so the risk cannot happen), mitigate (reduce its probability or impact), transfer (move it to someone else, such as an insurer or a supplier) and accept (do nothing, and plan for the impact). Every response except accept has a cost, and the log should state it.
How to build one in six steps
1. Run a pre-mortem
Gather the team and say: “It is six months from now and the project has failed. Write down why.” People name risks as causes of a failure far more readily than they predict them, and the risks they already know about but have never said aloud come out.
2. Sort each item into R, A, I or D
Rewrite each as cause and effect. “Priya” is not a risk; “Because one engineer wrote the sync layer, her leaving would stop the critical path” is.
3. Score probability and impact
Score each from 1 to 5 and multiply. A common rule: a score of 12 or more needs a costed response and an owner this week; under 6 is usually accepted and monitored.
4. Name a trigger for each high score
A trigger turns a worry into something checkable: “fewer than 4 of 5 pilot accounts confirmed by 15 January”.
5. Give each one owner and a costed response
Compare the cost of the response with the cost of the risk happening. If the response costs more, accept the risk and say so.
6. Review weekly, report the top five
Rescore every entry weekly. Leadership sees the five highest scores with their owners, not the whole log.
Worked example: Corbel
The scenario
A board promise, 14 engineers and a release that shipped 11 weeks late
Corbel sells scheduling and dispatch software to heating, air-conditioning and plumbing contractors, with $31 million of annual revenue. Its last major release shipped 11 weeks late and 38% over budget. Now the CEO has told the board that technicians will be able to work offline by the end of Q1 2027.
The pre-mortem produced 23 entries: 14 risks, 5 assumptions, 2 issues and 2 dependencies. The two highest scores came from things the team knew but had never written down: one came from a tech lead’s one-to-one, the other from a calendar.
| ID | Entry | Score | Trigger | Owner and response |
|---|---|---|---|---|
| R1 | Because one engineer wrote the sync layer, her leaving would stop the critical path | 20 | Any sync change reviewed by her alone | Engineering lead: pair a second engineer from week 2 |
| R2 | Because the pilot falls in the heating season, pilot accounts may not give it time | 16 | Fewer than 4 of 5 accounts confirmed by 15 Jan | Head of customer success: recruit 8 accounts, 3 of them plumbing contractors |
| R3 | Because iOS limits background activity, jobs may not sync until the app is reopened | 15 | Background sync test fails beyond 10 minutes | iOS lead: sync on reopen, tested on 4 iOS versions by week 6 |
| A1 | Contractors accept a signature captured offline as proof of completion | – | Confirm with 5 accounts by 30 Nov | Head of product: validate in pilot contracts |
| D1 | Apple and Google app store review, 5 to 10 days | – | Submission not ready by 1 Mar 2027 | Release manager: on the critical path |
R1 shows why each response carries a cost. Pairing a second engineer on the sync layer from week 2 costs 6 engineer-weeks. If Priya left without that cover, the critical path would stand still for about 8 weeks while a replacement learned the system. The response costs less than the risk, so it goes ahead.
R2 came from the calendar. Commercial heating contractors are at full stretch in January and February, exactly when the pilot was scheduled. The response recruits eight pilot accounts instead of five, so the pilot survives if three are too busy.
What a one-line prompt gets wrong
| Where it goes wrong | What usually comes back | What the log needs |
|---|---|---|
| Content | Generic risks: “scope creep”, “resource constraints” | This project’s risks, from a pre-mortem |
| Wording | Single nouns | Cause and effect |
| Scores | High, medium, low | Probability × impact, 1 to 25 |
| Owners | “Project team” | One named role each |
| Responses | “Monitor closely” | Avoid, mitigate, transfer or accept, with the cost |
Try it: a shortened Prompt 07
This is a shortened version of Prompt 07 from the Product & Project Management pack, set up to run on its own. Paste it into ChatGPT, Claude or Gemini and fill in the brackets.
You are a former programme director who has run software and operations projects through board-level review. The risks that sink a project are usually known to someone on the team and never written down, so you run a pre-mortem first and score every entry, instead of listing generic project risks. THE PROJECT: - What it delivers and by when: [scope, deadline, who promised it to whom] - Team and budget: [people, key skills, budget] - The plan's main phases and the critical path: [phases, dates] WHAT THE TEAM KNOWS: - Concerns people have raised, even informally: [paste notes, one-to-one comments] - Outside dependencies: [suppliers, approvals, other teams, app stores, customers] - What went wrong on the last similar project: [if known] Produce: 1. THE PRE-MORTEM. Assume the project has failed. The ten most likely reasons, each written as cause and effect. 2. THE RAID LOG. Every entry sorted into risk, assumption, issue or dependency, with ID, probability (1-5), impact (1-5), score, trigger and one owner. 3. THE RESPONSES. For every risk scoring 12 or more: avoid, mitigate, transfer or accept, with the cost of the response against the cost of the risk. 4. THE TOP FIVE. The five entries leadership should see, in one table. Use only what I tell you about this project. Where an entry rests on your judgement rather than my input, mark it [TO CONFIRM].
The full Prompt 07 has eight parts rather than four, and it reads the Initiative Brief built by prompts 01 to 06, so the pre-mortem is run against the actual business case, requirements and critical path.
Checks before the review
- Every entry is written as cause and effect.
- Every risk has a score, a trigger and one named owner.
- Every response scoring 12 or more states its cost.
- Assumptions each have a date by which they will be confirmed.
- Leadership sees the top five, not the whole log.
Questions
What does RAID stand for?
Risks, assumptions, issues and dependencies. Some teams use D for decisions instead of dependencies; use whichever your organisation already reviews, and keep all four in one log.
What is the difference between a risk and an issue?
A risk may happen; an issue has happened. When a risk’s trigger fires, it moves to the issues section with an action and a date.
How do you score a risk?
Rate its probability and its impact from 1 to 5 and multiply them, giving a score from 1 to 25. Agree what each number means before scoring, so two people give the same risk the same score.
What is a pre-mortem?
A session in which the team imagines the project has already failed and lists the reasons. It surfaces risks people are reluctant to raise when asked to predict problems directly.
Written by a former Gartner Managing Partner and investment banking SVP
The guides and the prompt templates on this site come from a career spent building these documents: board decks, forecasts, business cases and hiring decisions, as Managing Partner at Gartner, SVP in investment banking and Country Manager at international subsidiaries. The worked examples are published in full on each product page. Browse the Prompt Library.
Corbel and the people named are fictional, and the figures are illustrative.
Output from any AI tool should be reviewed before use.