Project delivery
RAID log
Risks, assumptions, issues and dependencies on one sheet with a type column, so a risk that occurs becomes an issue by an edit rather than a copy and paste. Probability and impact on three bands, with an owner and a review date on every row.
What it is
Risks, assumptions, issues and dependencies are four states of the same thing, which is why they belong on one sheet rather than in four documents. A risk that occurs becomes an issue. An assumption that fails becomes an issue. A dependency nobody confirmed becomes an issue. Keeping them together makes each of those an edit rather than a copy and paste, and the edit preserves the record that it was foreseen.
The assumption rows are the ones that predict what will actually go wrong. Every project fills in risks, and the register that would have helped is the list of things being treated as true that nobody has verified. An assumption with a test and a date beside it is a piece of work. An assumption with only a description is a hope.
The last update column is what shows whether this is a control or an artefact. Sort by it before every review, and anything untouched for a month is either closed or being ignored.
When to use it
- The project has risks recorded in three places and nobody is sure which is current.
- Something has gone wrong that somebody remembers predicting, and there is no record of it.
- You are inheriting a project and need one view of what might yet hurt it.
- A dependency on another team keeps slipping and nobody owns the other side of it.
The columns
- Ref
- Type
- Description
- Raised
- Raised by
- Owner
- Probability
- Impact
- Response
- Status
- Due
- Last update
The template
| Ref | Type | Description | Raised | Raised by | Owner | Probability | Impact | Response | Status | Due | Last update |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | The single controls engineer qualified on the legacy rig leaves in March, and no handover is scheduled | 2026-01-14 | K. Osei | K. Osei | High | High | Mitigate. Pair a second engineer with her from February and record the commissioning steps | Open | 2026-02-28 | 2026-02-03 |
| A-01 | Assumption | The finance system will accept the new cost codes without a change request | 2026-01-14 | M. Reyes | M. Reyes | High | Test with a single code in the sandbox before the design is frozen | Testing | 2026-02-10 | 2026-02-03 | |
| I-01 | Issue | The test environment has been unavailable three days a week since January and is costing about a day of delivery per cycle | 2026-02-02 | Delivery team | S. Baptiste | High | Escalated to the platform owner. Dedicated slot agreed from 17 February | Open | 2026-02-17 | 2026-02-05 | |
| D-01 | Dependency | Payment gateway certification is issued by the acquirer and cannot start until the integration is feature complete | 2026-01-20 | S. Baptiste | S. Baptiste | High | Book the certification slot now against the forecast date, and confirm the lead time in writing | Open | 2026-03-06 | 2026-02-05 | |
| A-02 | Assumption | Two thousand historical records will migrate cleanly, based on a sample of fifty | 2026-01-22 | M. Reyes | J. Okafor | Medium | Run a full trial migration in a copy environment rather than extrapolating from the sample | Open | 2026-02-20 | 2026-02-05 | |
| R-02 | Risk | Steel delivery may be delayed by port congestion, which the supplier will confirm within a fortnight | 2026-02-01 | Procurement | Procurement | Medium | High | Identify a second supplier and hold the road closure booking until the supplier confirms | Open | 2026-02-15 | 2026-02-05 |
| I-02 | Issue | Two teams built incompatible interfaces because no integration contract was agreed | 2026-01-28 | Architecture | Architecture | Medium | One interface adopted as the standard. Rework scheduled into the next two cycles | Resolved | 2026-02-11 | 2026-02-11 |
One sheet with a type column rather than four tabs, because the four things move between each other and a tab boundary makes that a copy and paste rather than an edit.
The four types
- Risk. Something that has not happened and might. It carries a probability and an impact, and it has a response chosen from avoid, transfer, mitigate, accept or escalate.
- Assumption. Something being treated as true that nobody has verified. It carries no probability, because an assumption is not uncertain in the same way. What it carries is a test and a date by which the test happens.
- Issue. Something that has already happened and is affecting the project now. It has no probability either, since the probability was resolved when it occurred. It has an owner and a resolution.
- Dependency. Something the project needs from outside it, or something outside needs from the project. It carries a direction, a date and the name of whoever owns the other side.
Why the assumption rows matter most
A risk register is the part everybody fills in and an assumption list is the part that predicts what will actually go wrong. An untested assumption becomes a risk the moment somebody questions it and an issue the moment it turns out to be false, and both of those happen after the plan was built on it.
The discipline is that every assumption gets a test and a date, not just a description. Assumption A-01 above is one sandbox entry away from being settled, and leaving it open until the design freeze is how a change request arrives at the worst moment.
How things move
A risk that occurs becomes an issue. Change the type, keep the reference, and add a line to the description saying it materialised and when. Do not delete the risk row, because the record that it was foreseen is worth more than a tidy log.
An assumption that fails becomes an issue by the same route. An assumption that is proven stops being an assumption and can be closed with a note saying what proved it.
A dependency that is missed becomes an issue. A dependency that has been confirmed in writing can be closed.
Probability and impact
Use three bands rather than five, and define them on this tab so they mean the same thing to everybody.
- High. More likely than not, or an impact that would breach a tolerance and require escalation.
- Medium. A realistic possibility, or an impact absorbed by contingency without breaching anything.
- Low. Unlikely, or an impact absorbed inside normal working.
Five bands invite an argument about whether something is a three or a four, which is time spent on the scale rather than on the response. Where a number is genuinely needed, put probability as a percentage and impact in currency, and multiply them for an expected value.
Keeping it alive
The Last update column is the one that shows whether the log is a control or an artefact. Sort by it before every review, and anything untouched for a month is either closed or being ignored.
A complete log that nobody reads is not a control. The review is what makes it one, and the review only needs the rows that changed, the rows due, and the rows nobody has touched.
Questions people ask
- Why not a separate risk register?
- Because the four categories move between each other constantly. A separate register means a risk that materialises gets closed in one document and opened in another, and the link between them is lost with the reference.
- How many bands should probability and impact use?
- Three, defined on the sheet. Five bands invite an argument about whether something is a three or a four, which is time spent on the scale rather than on the response. Where a number is genuinely needed, use a percentage and a currency figure and multiply them.
- Should closed rows be deleted?
- No. The record that something was foreseen and handled is worth more than a tidy log, and it is the material that makes a lessons register useful later.