raid_log_management v1.0.0

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.