A RAID log keeps four kinds of project information separate: risks, assumptions, issues and dependencies. On a shared whiteboard, the log becomes a reviewable map rather than a long spreadsheet. The team can see what changed, who is coordinating the response and when each item needs another look.
For project planning in Boardmix, place the four registers beside the milestone they affect. Use the risk-matrix guide when an item needs likelihood and impact analysis. The four registers complement each other; a RAID board should not turn every uncertainty into a red risk.
Define the four RAID registers
Give each register a short definition at the top of the board. A risk is a possible future event, an assumption is something the plan currently treats as true, an issue is a problem already happening, and a dependency is an outside condition or handoff the work relies on. When evidence contradicts an assumption, record the resulting problem as an issue and link it to the original assumption.
| Register | Example | First question |
|---|---|---|
| Risk | Security review could delay the release candidate. | What response reduces or contains it? |
| Assumption | The current export format will meet the pilot need. | What evidence would confirm it? |
| Issue | Two test accounts cannot access the new board. | Who is coordinating the fix? |
| Dependency | Another team must publish the API schema. | What handoff and date are needed? |
Use a consistent card format
Every card should be understandable without a separate meeting. Record a short statement, source or evidence, owner, current status, next response and review date. Keep the owner as the person coordinating the next step, not a claim that one person can solve every part.
Use a separate field for context. “Export is blocked” is less useful than “The pilot needs CSV, but the current export omits headers.” Specific context helps the next reviewer decide whether the category or status should change.
Copy this field order onto a note for each item: ID and category · statement · evidence or source · owner · status · next action · review date · linked items. Leave an unknown value marked “to confirm” and assign the check; a blank field does not tell the next reader whether it was forgotten.
Connect RAID items to the plan
Place each item near the milestone, story or decision it can affect. Draw a connector when a dependency has a direct relationship; add a short label so the line has meaning. Do not connect everything to everything. A smaller set of readable relationships is more useful than a dense web.
When a risk becomes an issue, preserve the original statement and add the observed evidence. When an assumption is validated, mark the evidence and move it out of the active register if the team no longer needs to monitor it.
The example follows a report portal being prepared for five pilot customers. A1 assumes that CSV will suit their workflow. A sample export then reveals I2: the file has no column headers. That defect does not, by itself, show that CSV is the wrong format. Keep A1 open until a customer checks a corrected sample, and create I2 to track the observed defect.
| Item | Evidence and status | Owner and next check | Completion condition |
|---|---|---|---|
| R1 — Security review may miss May 18 | The review slot is not confirmed; the delay has not occurred. | Release coordinator: reserve a slot and check its status at the next review. | A reviewer and slot are confirmed, or the release plan is changed. |
| A1 — CSV fits the pilot workflow | Awaiting a customer check of a usable sample. | Pilot coordinator: arrange the sample review after I2 is fixed. | The customer can use the sample for the intended task. |
| I2 — Exported CSV has no headers | The sample file shows the defect; the issue is open. | Priya: coordinate the export fix and retest it against D2. | A new sample has the expected headers and is attached to the record. |
| D2 — Platform team supplies the schema | The export fix depends on an agreed schema. | Platform-team contact: confirm the schema version and handoff date before the export retest. | The export sample matches the agreed schema. |
Label the link from D2 to I2 “schema needed for fix” and the link from I2 to A1 “corrected sample needed for validation.” Fill in the actual people and review dates before using this layout on a project. A missed review date is a prompt to check the item, not evidence that it is resolved.
Run a focused RAID review
- Read the project outcome and the review period.
- Scan new issues first because they may need immediate coordination.
- Check dependencies whose handoff date is near or already missed.
- Challenge assumptions with new evidence instead of debating them abstractly.
- Choose a response or next check for each active risk.
- Confirm the owner, review date and unresolved decisions.
Comments are useful for questions attached to one card; text and notes hold the current register. Boardmix provides the shared canvas, shapes, connectors, comments and sharing controls for this layout. The team still decides the status and response.
Keep the log useful between reviews
Archive resolved cards without deleting the reasoning that matters for the project record. If an item is repeatedly carried forward, rewrite the next response or ask whether its category is wrong. A RAID log should shorten the next conversation, not become a second task list.
Open a Boardmix board, create the four areas and copy the field order above into your first card. For the portal review, the next entry should record the agreed schema, Priya’s corrected export and the customer’s sample check. Close I2 when the defect is fixed; close A1 only when its separate validation is complete.
