What needs to be finished first
An initiative or program has a clear mandate, stakeholders and timeframe so risks, assumptions, issues and dependencies can be recognized at all.
What needs to be ready before start
Table or database with columns ID, category (R/A/I/D), description, owner, status, date created, date last updated, next action; wiki or sheet link; briefing template for status reports.
One maintenance owner (PM, RTE or program lead); owner per entry from relevant teams; sponsor as escalation recipient; all contributors with write access.
Initiative charter; stakeholder list; current discovery or kickoff notes; known risks, assumptions, dependencies from Pre-Mortem or kickoff.
30 min setup, then 15 min per week
Create table, configure columns. Definition per category as header: Risk = occurrence uncertain, negative impact; Assumption = assumed true, testable; Issue = already occurred, needs action; Dependency = external input needed. Define status values (Open, In Progress, Resolved, Closed).
The one question this method answers
Which risks, assumptions, issues and dependencies are currently open, who takes care of them, and which ones need movement or escalation now?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Set up table and categories | 20 min | Configure columns. Write category definitions. Examples per category from initiative context. Set write permissions and maintenance responsibility. | If definitions blur, Risk and Issue mix. Clear separation: Risk not yet occurred, Issue already occurred. Assumption is hypothesis, Dependency is external input. |
2Phase 2: Transfer initial entries | 30-60 min | Transfer all known entries from kickoff, Pre-Mortem, Risk Storming. Per entry: owner, status, next action, deadline. For external dependencies, name recipient team. | Without owner assignment at entry, the overview fizzles. Better omit entry than add it without owner. |
3Phase 3: Weekly maintenance | 15 min per week | Maintenance owner reviews log: new entries captured, old updated, resolved entries closed, stale entries escalated. Generate stakeholder briefing. | Fixed slot in calendar (for example Friday 14:00). Without cadence, log becomes graveyard. Explicitly address stale entries >4 weeks. |
4Phase 4: Status report briefing | 10 min | Pull weekly highlights from log: new top risks, closed issues, escalated dependencies. Use as status-report section for sponsor and stakeholders. | Log is source, briefing is view. Briefing from log content, not gut feeling. Stakeholder trust grows when briefing is reproducible. |
What comes out at the end
Table in central tool with columns ID, category, description, owner, status, date, next action. Resolved entries archived, not deleted. Weekly briefing as derived view.
Entries with ID and creation date. Changes with date in edit log. Resolved entries by quarter into archive tab. Weekly briefings as wiki page with date, not overwritten.
Compact working template for RAID Log with context, input, output artifacts, and next step.
Keeps risks, assumptions, issues, and dependencies captured in one place.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Risks (5 open)
| ID | Description | Owner | Status | Next action | Deadline |
|---|---|---|---|---|---|
| R-12 | DB replication single-leader | @ben | Mitigation | Multi-leader spike | 2026-05-30 |
| R-15 | PSP breaking change Q3 | @marcus | Owned | Sandbox access | 2026-05-31 |
| R-17 | Performance at >1000 tenants | @anna | Owned | Monitoring | 2026-05-22 |
Assumptions (3)
| ID | Description | Owner | Status | Next action |
|---|---|---|---|---|
| A-04 | Existing parser library fits DATEV format | @anna | Open | Spike before Sprint 24 |
| A-05 | PSP sandbox available by Q3 | @marcus | Open | Clarify with PSP |
Issues (2 open)
| ID | Description | Owner | Status | Next action | Deadline |
|---|---|---|---|---|---|
| I-08 | Compliance audit date delayed | @ben | In Progress | Escalate to Compliance Lead | 2026-05-20 |
| I-09 | Test dataset for tenant migration incomplete | @lisa | Open | Data request to Sales | 2026-05-25 |
Dependencies (4)
| ID | Description | Owner | External team | Status | ETA |
|---|---|---|---|---|---|
| D-03 | DATEV format specification v2 | @anna | DATEV Partner | Pending | 2026-05-30 |
| D-06 | Compliance approval multi-tenant | @ben | Compliance | Pending | 2026-06-15 |
Weekly highlight: I-08 compliance audit date in escalation. R-12 multi-leader spike running on plan.
Recognize symptoms and steer against them
Entry "server fails" lands as Risk although it has already occurred (Issue).
Clear definition: Risk = not yet occurred, Issue = already occurred. Check at entry: has it happened yes/no. Otherwise follow-up actions are prioritized wrongly.
Log contains entries unchanged for 8 weeks, nobody checks them anymore.
Weekly review cadence. Mark and escalate stale entries (>4 weeks without update). Either close, accept or move again.
Owner column contains Team A or IT, nobody feels responsible.
Owner must be named person. Generic owners are ignored. If nobody wants ownership, escalate to sponsor rather than park entry with team label.
Log exists, maintained once per month for steering meeting, otherwise empty.
Log is steering instrument, not report document. Weekly maintenance in program rhythm. If log only exists for steering, choose another process.
Assumptions sit in log, nobody checks them, later they fail as risks.
Set test date or trigger per assumption: when it will be validated. Falsified assumption becomes Issue. Validated becomes Resolved.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.