RAID Log Template (Risks, Assumptions, Issues, Dependencies)

Risks, assumptions, issues and dependencies log with probability x impact scoring, owners, due dates, heat map and review cadence

Управління проєктамиСтандартraid log mathОновлено 20 жовт. 2026 р.

Відкрити в редакторіЗавантажити .md

Як використовувати: Use throughout the project as the working log reviewed every week. Agree the scoring scales first, then record items with one owner and a due date each. Main pitfall: updating the log only before steering meetings, so it stops driving action.

Перегляд

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.

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

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

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

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

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

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

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

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

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.

Схожі шаблони

Управління проєктами