# RAID Log: [Project name]

> Single log for project Risks, Assumptions, Issues and Dependencies, with
> scoring, owners, due dates, status and a review cadence. Based on common
> project management practice. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Keep one RAID log per project and review it on a fixed cadence. A log that is only
  updated before steering meetings is a report, not a management tool.
- Write risks as cause, event and effect: "Because X, Y may happen, which would
  cause Z." Write issues as facts that are happening now.
- Every open item has one owner and a due date for its next action.
- When a risk occurs, close it as "Occurred" and open an issue that links back to it.
-->

| Field | Value |
|---|---|
| Document ID | [RAID-PROJECT-001] |
| Project | [Project name] |
| Owner | [@project-manager] |
| Review cadence | [Weekly project board; monthly steering committee] |
| Last reviewed | YYYY-MM-DD |
| Open items | [Risks n, Assumptions n, Issues n, Dependencies n] |

## 1. Scoring scales

<!-- Guidance: Define the scales once and use them for every risk. Adjust impact thresholds to the size of your project. -->

Risks are scored on probability and impact, each from 1 to 5.

$$\text{Score} = P \times I, \qquad 1 \le \text{Score} \le 25$$

| Rating | Probability (P) | Impact (I): schedule | Impact (I): cost | Impact (I): quality or scope |
|---|---|---|---|---|
| 1 Very low | Below 10% | Under 2 days | Under 1% of budget | Cosmetic |
| 2 Low | 10 to 30% | 2 to 5 days | 1 to 3% | Minor feature degraded |
| 3 Medium | 31 to 50% | 6 to 10 days | 3 to 5% | Important feature degraded |
| 4 High | 51 to 70% | 11 to 20 days | 5 to 10% | Objective partly missed |
| 5 Very high | Above 70% | Over 20 days | Over 10% | Objective missed |

Impact takes the highest of the applicable dimensions. Thresholds: **High** 15 to 25, **Medium** 8 to 14, **Low** 1 to 7.

## 2. Risks

<!-- Guidance: Score before (inherent) and after (residual) the planned response. Response types: avoid, reduce, transfer, accept (for threats); exploit, enhance, share, accept (for opportunities). -->

Risks are uncertain events that would affect objectives if they occurred.

| ID | Risk (cause, event, effect) | P | I | Score | Response type | Response actions | Residual score | Owner | Due | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-001 | *Example:* Because the vendor team is shared with another client, key developers may be unavailable, delaying the front-end build by up to 3 weeks | 4 | 4 | 16 | Reduce | Named-team clause in contract; weekly staffing check | 8 | [@pm] | YYYY-MM-DD | Open |
| RSK-002 | *Example:* Because the identity service is changing its API version, integration may need rework, adding 8 days | 3 | 3 | 9 | Reduce | Build against the new version in sandbox now | 4 | [@tech-lead] | YYYY-MM-DD | Open |
| RSK-003 | *Example:* Opportunity: reuse the group's design system could cut front-end effort by 10% | 3 | 2 | 6 | Exploit | Confirm licence and component coverage | 6 | [@ux-lead] | YYYY-MM-DD | Open |
| [RSK-nnn] | [Cause, event, effect] | [1-5] | [1-5] | [n] | [Type] | [Actions] | [n] | [@owner] | YYYY-MM-DD | [Open / Closed / Occurred] |

## 3. Assumptions

<!-- Guidance: Assumptions are things taken as true for planning. Validate them; an invalid assumption becomes an issue or a risk. -->

Assumptions underpin the plan and are validated by the owner before the date shown.

| ID | Assumption | Basis | Impact if false | Validation method | Owner | Validate by | Status |
|---|---|---|---|---|---|---|---|
| ASM-001 | *Example:* Branch staff can be released for 4 hours of training each | HR agreement in principle | Rollout delayed 2 weeks | Written confirmation from HR director | [@change-lead] | YYYY-MM-DD | Open |
| ASM-002 | *Example:* Existing customer data is clean enough to migrate without manual correction | Sample of 500 records | Data cleansing workstream needed | Full data profiling | [@data-lead] | YYYY-MM-DD | Validated |
| [ASM-nnn] | [Assumption] | [Basis] | [Impact] | [Method] | [@owner] | YYYY-MM-DD | [Open / Validated / Invalid] |

## 4. Issues

<!-- Guidance: Issues are happening now. Priority reflects urgency and impact. Record the resolution, not just "closed". -->

Issues are current problems that need action.

| ID | Issue | Raised | Priority | Impact | Action | Owner | Due | Status | Resolution |
|---|---|---|---|---|---|---|---|---|---|
| ISS-001 | *Example:* Test environment unavailable since Monday; integration testing blocked | YYYY-MM-DD | P1 | A05 delayed 3 days so far | Infra ticket escalated; temporary environment requested | [@tech-lead] | YYYY-MM-DD | Open | |
| ISS-002 | *Example:* Two UAT testers reassigned to audit | YYYY-MM-DD | P2 | UAT capacity minus 40% | Replacement agreed with operations head | [@test-lead] | YYYY-MM-DD | Closed | Two testers from QA pool assigned |
| [ISS-nnn] | [Issue] | YYYY-MM-DD | [P1 / P2 / P3] | [Impact] | [Action] | [@owner] | YYYY-MM-DD | [Status] | [Resolution] |

## 5. Dependencies

<!-- Guidance: Record what this project needs from others (inbound) and what others need from it (outbound). Name the counterpart owner. -->

Dependencies link this project to work outside its control.

| ID | Dependency | Direction | Counterpart (project or team) | Needed by | Counterpart owner | Our owner | Status |
|---|---|---|---|---|---|---|---|
| DEP-001 | *Example:* Core banking API v3 released to test | Inbound | Core banking upgrade programme | YYYY-MM-DD | [@cb-pm] | [@tech-lead] | On track |
| DEP-002 | *Example:* New onboarding data feed for CRM project | Outbound | CRM replacement project | YYYY-MM-DD | [@crm-pm] | [@pm] | At risk |
| [DEP-nnn] | [Dependency] | [Inbound / Outbound] | [Counterpart] | YYYY-MM-DD | [@name] | [@name] | [Status] |

## 6. Risk heat map

<!-- Guidance: Place open risk IDs by current probability and impact. Refresh at each review. -->

The heat map shows open risks by probability (rows) and impact (columns). Cells in the High band need steering committee visibility.

| P by I | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| **5** | Medium | Medium | High | High | High |
| **4** | Low | Medium | Medium | **High: RSK-001** | High |
| **3** | Low | Low: RSK-003 | **Medium: RSK-002** | Medium | High |
| **2** | Low | Low | Low | Medium | Medium |
| **1** | Low | Low | Low | Low | Low |

## 7. Summary and trends

<!-- Guidance: A short summary for the status report: counts, top items, movement since last review. -->

Summary at the last review on YYYY-MM-DD:

| Category | Open | Opened since last review | Closed since last review | High or P1 |
|---|---|---|---|---|
| Risks | [n] | [n] | [n] | [n] |
| Assumptions | [n] | [n] | [n] | n/a |
| Issues | [n] | [n] | [n] | [n] |
| Dependencies | [n] | [n] | [n] | [n at risk] |

Top items for escalation: [RSK-001 vendor staffing; DEP-002 CRM data feed].

## 8. Review cadence and rules

<!-- Guidance: Make the review a routine. State what triggers an out-of-cycle review. -->

The RAID log is reviewed as follows.

| Forum | Frequency | Scope | Outcome |
|---|---|---|---|
| Project board | Weekly | All open items | Updated scores, actions, due dates |
| Steering committee | Monthly | High risks, P1 issues, at-risk dependencies | Decisions, risk acceptance |
| Stage gate | At each gate | Whole log | Confirm residual risk is acceptable to proceed |

Out-of-cycle review is triggered by a new High risk, a P1 issue, or a missed dependency date. Closed items stay in the log, filtered from the default view, for lessons learned.

## Standard and licence note

Based on common project management practice for RAID logs and risk
scoring with a probability and impact matrix. This template is original
text written for this collection. Template licence: MIT.