---
name: "raid_log_management"
description: "Run a RAID log for a project as a living management system: classify risks, assumptions, issues, and dependencies, score and own every entry, run the review cadence, convert entries when facts change, and escalate on pre-agreed thresholds. Use when starting a project, cleaning up a messy RAID log or risk register, preparing a steering or status review, triaging meeting notes into RAID entries, or auditing a log for stale and unowned items."
---

# RAID Log Management

## Purpose

Keep one shared record of the four things that quietly derail projects:
risks, assumptions, issues, and dependencies. This skill covers the whole
system, not just the spreadsheet: entry quality rules, scoring, ownership,
review cadence, conversions between types, and escalation thresholds agreed
in advance so escalation is a procedure, not an argument.

RAID here means Risks, Assumptions, Issues, Dependencies. Some teams use
Actions or Decisions for A and D. This system keeps Assumptions and
Dependencies as categories, and gives every entry an action field and a
decision field, so nothing is lost either way.

## Workflow

1. **Set the log charter first.** One page, agreed with the sponsor: which
   RAID expansion the team uses, the scoring scales, the review cadences,
   the escalation thresholds, and where the single shared copy lives.
   Record the thresholds before the project gets tense. Agreeing them
   later, mid-incident, turns every escalation into a negotiation.

2. **Classify with the four tests.** Ask in order:
   - Issue: is it happening now and hurting the project today?
   - Risk: could it happen, with a cause and a consequence you can state?
   - Assumption: are we treating it as true without proof, to plan on?
   - Dependency: are we waiting on a person, team, vendor, or approval
     outside the doing team's direct control?
   If two tests pass, file it under the one that needs action soonest and
   cross-link the other. Full classification guidance, including the
   assumption to risk to issue chain, is in
   `references/classification-and-scoring.md`.

3. **Write entries that pass the entry gate.** Every entry needs: ID,
   type, one-sentence statement in cause and effect form, owner (a named
   person, not a team), date raised, next action with a date, review date,
   and status. Risks also need probability, impact, response strategy,
   trigger, and contingency. Assumptions need a validation test and a
   validation date. Issues need severity, impact so far, and a resolution
   path. Dependencies need counterparty, what is needed, needed-by date,
   and the relationship type. An entry missing owner or next date is not
   accepted into the log. Reject it politely and send it back.

4. **Score risks and prioritize the log.** Score risks as probability
   (1 to 5) times impact (1 to 5). Use the bands and scale definitions in
   `references/classification-and-scoring.md` and tailor the cost and
   schedule wording to the project in the charter. Score assumptions by
   stability and consequence. Score issues by impact already occurring.
   Score dependencies by days of schedule exposure if the counterparty
   slips. One priority order across all four types comes from the
   escalation thresholds, not from four separate lists.

5. **Assign owners who can act.** The owner is the person closest to the
   work who can drive the next action: mitigating a risk, validating an
   assumption, resolving an issue, chasing a dependency. The project
   manager or PMO owns the log itself: completeness, dates, stale flags,
   and threshold checks. Owning an entry means keeping it visible and
   current, and escalating when a threshold is crossed. It does not mean
   personally solving it.

6. **Run two review cadences, not one.**
   - Working review, weekly (biweekly only for small, slow projects):
     the delivery team walks the full log. New entries, changed scores,
     overdue actions, entries with no movement since last review.
     Timebox it. Work the log, do not solve the items in the room.
   - Steering review, biweekly or monthly: sponsors see only items at
     or above the escalation threshold, items needing a decision, and
     the counts by type and band. Detail stays at working level.
   Before each status report, sweep the log for entries added or changed
   since the last report and carry the top items into the report.

7. **Convert entries when facts change.** Conversions are normal and
   keep the history:
   - Assumption validated: close it, record the evidence.
   - Assumption invalid, or validation date passed untested: convert to
     a risk if harm is still avoidable, to an issue if harm is live.
   - Risk trigger fires or the event occurs: convert to an issue the
     same day. Keep the risk ID in the issue record.
   - Dependency confirmed in writing with a date the plan can hold:
     downgrade and monitor. Dependency date missed: convert the blocked
     work to an issue, keep the dependency open.
   - Issue resolved: close with the resolution and the actual impact.
     Never delete entries. Closed entries are the lessons record.

8. **Escalate on thresholds, automatically.** The log keeper raises any
   entry that crosses a charter threshold at the next review, without
   waiting for the owner to volunteer it. Default thresholds are in the
   scoring reference. Typical triggers: a risk score in the top band,
   an issue blocking critical path work, an assumption past its
   validation date, a dependency inside its lead time with no written
   confirmation, any entry unchanged for three reviews, any entry with
   an overdue action. Escalation states the decision needed, who can
   make it, and the date it is needed by.

9. **Audit and close out.** Monthly, run the checker
   (`bin/raid_check.py`) over the CSV export: unowned entries, missing
   dates, overdue actions, stale reviews, top-band items still open.
   Fix or close what it flags. At project end, review closed entries for
   lessons: which risks landed, which assumptions were wrong, which
   dependencies slipped, and carry the patterns into the next charter.

## Output Contract

A RAID setup delivers: a one-page log charter (expansion, scales,
cadences, thresholds, log location), the log itself in the template
format (`assets/raid-log-template.csv`), and the first working review
date booked.

A review cycle delivers: updated entries with new review dates, a list
of conversions made, an escalation list (entry, threshold crossed,
decision needed, decision owner, needed-by date), and a steering
summary with counts by type and band plus top items only.

An audit delivers: checker output, entries fixed or closed as a result,
and any charter thresholds that need adjusting, with reasons.

Every entry in any output has a named owner and a dated next action.
No entry is reported as a bare description with no owner and no date.

## Operating Rules

- One log, one shared location, one ID scheme: R-001, A-001, I-001,
  D-001, numbered per type and never reused.
- Write risk statements as cause, event, consequence. "Vendor delay"
  is a topic, not a risk. A usable form: "Because the vendor has one
  test environment, if bookings clash then integration testing slips
  and the release date moves."
- Separate facts from beliefs out loud. If evidence exists, cite it and
  close the assumption. If nobody can state the validation test, the
  entry is a worry, not an assumption. Give it a test or drop it.
- A constraint is a known limit, such as a fixed budget or a fixed
  launch date. Record constraints in the charter, not as assumptions.
  Confusing the two hides real limits inside a list of guesses.
- Risk responses use the standard sets. Threats: escalate, avoid,
  transfer, mitigate, accept. Opportunities: escalate, exploit, share,
  enhance, accept. Record the chosen strategy and, for accept, who
  accepted it and what reserve, if any, backs it.
- Acceptance is a recorded decision by a named person. A comment in a
  meeting that the team can live with a risk is not acceptance.
- Dependencies get four labels where they apply: relationship
  (finish-to-start, start-to-start, finish-to-finish, start-to-finish),
  logic (mandatory or discretionary), and control (internal or
  external). Discretionary dependencies are the first candidates to
  relax when the schedule is squeezed.
- Do not let the log become a blame record. Thresholds, stale flags,
  and escalation are applied by the log keeper to everyone equally.
  The moment scores get used to punish owners, owners stop reporting
  early, and the log fills with surprises instead of warnings.
- Keep statements short enough to scan in a review. Detail, evidence,
  and history go in notes linked from the entry.
- If the team will not hold the weekly review, shrink the log rather
  than letting it rot. A short log reviewed weekly beats a complete
  log reviewed never.