RAID Log

A single Risks, Assumptions, Issues, and Dependencies log. Ensures delivery teams are aware of everything that could affect outcomes, with owners and mitigation actions.

AI in this module

How AI suggestions work

Click "Get AI Suggestions" to have the AI draft or improve the whole RAID log in one pass, grounded in the DRP's other content and any AI Knowledgebase documents for the project.

The suggestion appears as a single card in the right-hand panel showing how many rows are proposed. Click "Apply" to replace your current table with the AI's draft; nothing changes until you do.

The AI only proposes entries it can ground in the DRP's existing content — a thin draft usually means the rest of the DRP (Solution Scope, Business Objectives, Business Process) needs more detail first.

This module is the exclusive home for risks, assumptions, issues, and dependencies in a DRP. Every other module's AI drafting is explicitly told not to list them — under any heading, even a "Key Risks" section of its own choosing — and to reference this log by name in one sentence instead if it's relevant. That's why it matters to keep this table genuinely current: it's not just one place a risk could live, it's the only place the rest of the DRP is designed to point back to.

Quality checks

What "Check Quality" looks for here

Real, specific mitigations. Flags placeholder mitigations like "monitor closely" that don't actually protect the project.

Consistent classification. Flags an entry whose Type doesn't match its real content, or one RAID category left noticeably thinner than the others.

What it captures

A single RAID log — Risks, Assumptions, Issues, and Dependencies — the standard way a BA tracks everything that could affect delivery but isn't a requirement.

Using this module

This module is one table covering all four RAID categories, rather than four separate lists — set the Type column per row to keep them together but distinguishable.

  1. 1Use "+ Add row" to add an entry, and the ✕ on a row to remove one.
  2. 2Set Type from the dropdown: Risk, Assumption, Issue, or Dependency.
  3. 3Write a clear Description of the entry itself — what the risk, assumption, issue, or dependency actually is.
  4. 4Set Impact (Low/Medium/High) — most meaningful for risks, but useful for any entry with a real consequence if it goes unmanaged.
  5. 5Set Owner — who is actually responsible for tracking and resolving this entry.
  6. 6Use Mitigation / Action for whatever's appropriate to the type: a risk's mitigation plan, an issue's resolution action, or how a dependency is being managed.
  7. 7Set Status (Open/Mitigated/Closed) and revisit it as things change — a stale RAID log is worse than no RAID log.

Review and approval

Reviewed as a whole — the Overview and the RAID table together, not row by row. A Lead Analyst or Analyst assigns this module's reviewers and approver and steps it through Submit for review → Mark review complete → Approve. Once submitted it is read-only; to change it, press "Reopen to edit", which cancels the round and returns it to In progress.

This DRP's Review Assignments tab shows the module as one row, like any other, with its own review level, reviewers and approver — inherited from the project until you change them here.

Tips

  • "Export CSV", at the top of the page, downloads this table as a spreadsheet file — handy for sharing it with someone who works in Excel.
  • An assumption stated here becomes something the reader is entitled to rely on — don't list something as an assumption if it still needs validating.
  • Keep Status up to date — a risk that's actually been mitigated but still shows "Open" undermines the whole log's credibility.