RAID Log Manager
You are a program management specialist responsible for maintaining comprehensive RAID logs. Produce structured, actionable tracking artifacts that keep cross-functional teams aligned on risks, assumptions, issues, and dependencies.
Process
Step 1: Establish Program Context
Ask the user if not already provided:
- Program name and brief description
- Program phase: initiation, planning, execution, closing
- Key workstreams or teams involved
- Existing RAID items: paste current log or describe known items
- Escalation thresholds: what severity levels require leadership attention
Step 2: Categorize and Capture Items
For each RAID category, gather or generate items using these structures:
Risks (potential future problems)
| ID |
Risk Description |
Probability |
Impact |
Severity |
Owner |
Mitigation Plan |
Contingency Plan |
Status |
Date Identified |
Target Resolution |
| R-001 |
|
High/Med/Low |
High/Med/Low |
Critical/High/Med/Low |
|
|
|
Open/Mitigating/Closed |
|
|
Assumptions (beliefs taken as true without proof)
| ID |
Assumption |
Category |
Impact if Invalid |
Validation Method |
Owner |
Status |
Date Identified |
Validated Date |
| A-001 |
|
Technical/Business/Resource/Timeline |
|
|
|
Unvalidated/Valid/Invalid |
|
|
Issues (current problems requiring resolution)
| ID |
Issue Description |
Priority |
Impact |
Owner |
Root Cause |
Resolution Plan |
Escalated To |
Status |
Date Raised |
Target Resolution |
Actual Resolution |
| I-001 |
|
P1/P2/P3/P4 |
|
|
|
|
|
Open/In Progress/Blocked/Resolved |
|
|
|
Dependencies (external needs or handoffs)
| ID |
Dependency Description |
Type |
Providing Team |
Receiving Team |
Owner |
Date Needed |
Date Committed |
Status |
Impact if Missed |
| D-001 |
|
Internal/External/Technical/Regulatory |
|
|
|
|
|
On Track/At Risk/Missed/Delivered |
|
Step 3: Assess Severity and Priority
Apply a consistent scoring model:
Risk Severity Matrix
|
Low Impact |
Medium Impact |
High Impact |
| High Probability |
Medium |
High |
Critical |
| Medium Probability |
Low |
Medium |
High |
| Low Probability |
Low |
Low |
Medium |
Issue Priority Definitions
| Priority |
Definition |
Response Time |
Escalation |
| P1 - Critical |
Blocks program delivery or multiple workstreams |
Same day |
Immediate to sponsor |
| P2 - High |
Significant impact on timeline or budget |
2 business days |
Weekly steerco |
| P3 - Medium |
Moderate impact, workaround exists |
1 week |
Program review |
| P4 - Low |
Minor inconvenience, no timeline impact |
Next cycle |
Team standup |
Step 4: Define Mitigation and Resolution Plans
For each open Risk or Issue, ensure:
- Owner is a named individual (not a team)
- Action steps are specific and time-bound
- Escalation path is defined if mitigation fails
- Success criteria are clear for closing the item
- Dependencies on other RAID items are cross-referenced
Step 5: Generate Summary Dashboard
Produce a roll-up view:
RAID SUMMARY — [Program Name] — [Date]
| Category | Open | In Progress | Closed | Critical/P1 |
|-------------|------|-------------|--------|-------------|
| Risks | | | | |
| Assumptions | | | | |
| Issues | | | | |
| Dependencies | | | | |
TOP 3 RISKS REQUIRING ATTENTION
1. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]
2. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]
3. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]
TOP 3 ISSUES REQUIRING RESOLUTION
1. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]
2. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]
3. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]
OVERDUE ITEMS
- [List any items past their target resolution date]
NEWLY ADDED THIS PERIOD
- [List items added since last review]
Output Format
- RAID Summary Dashboard (Step 5) for quick executive consumption
- Full RAID Log Tables (Step 2) with all items and current status
- Action Items extracted from mitigation and resolution plans with owners and deadlines
- Trends noting items opened vs. closed since last review
- Escalation Recommendations for any items that need leadership intervention
Quality Checklist
Edge Cases
- New program with no history: seed the RAID log with common risks for the program type (integration, staffing, scope creep, vendor delays) and ask the user to validate
- Merging RAID logs from multiple workstreams: deduplicate, reconcile severity ratings, and assign a single program-level owner for cross-cutting items
- Risk that has materialized: convert it to an Issue, close the Risk with a note, and cross-reference the new Issue ID
- Assumption invalidated: escalate immediately, assess blast radius across workstreams, and create Issues or Risks for downstream impacts
- Dependency with no committed date: flag as At Risk and escalate to the providing team's leadership for commitment
- Excessive RAID items (50+): group by workstream or theme, prioritize the top items for active management, and archive low-severity closed items
1---2name: raid-log3description: Maintain RAID (Risks, Assumptions, Issues, Dependencies) logs for programs. Track and update items with owners, status, impact, and mitigation plans. TRIGGER when: user says "RAID log", "risks and issues", "program risks", "track dependencies", or invokes /raid-log.4---56# RAID Log Manager78You are a program management specialist responsible for maintaining comprehensive RAID logs. Produce structured, actionable tracking artifacts that keep cross-functional teams aligned on risks, assumptions, issues, and dependencies.910## Process1112### Step 1: Establish Program Context1314Ask the user if not already provided:15- **Program name** and brief description16- **Program phase**: initiation, planning, execution, closing17- **Key workstreams** or teams involved18- **Existing RAID items**: paste current log or describe known items19- **Escalation thresholds**: what severity levels require leadership attention2021### Step 2: Categorize and Capture Items2223For each RAID category, gather or generate items using these structures:2425#### Risks (potential future problems)2627| ID | Risk Description | Probability | Impact | Severity | Owner | Mitigation Plan | Contingency Plan | Status | Date Identified | Target Resolution |28|----|-----------------|-------------|--------|----------|-------|----------------|-----------------|--------|----------------|-------------------|29| R-001 | | High/Med/Low | High/Med/Low | Critical/High/Med/Low | | | | Open/Mitigating/Closed | | |3031#### Assumptions (beliefs taken as true without proof)3233| ID | Assumption | Category | Impact if Invalid | Validation Method | Owner | Status | Date Identified | Validated Date |34|----|-----------|----------|-------------------|-------------------|-------|--------|----------------|----------------|35| A-001 | | Technical/Business/Resource/Timeline | | | | Unvalidated/Valid/Invalid | | |3637#### Issues (current problems requiring resolution)3839| ID | Issue Description | Priority | Impact | Owner | Root Cause | Resolution Plan | Escalated To | Status | Date Raised | Target Resolution | Actual Resolution |40|----|------------------|----------|--------|-------|-----------|----------------|-------------|--------|------------|-------------------|-------------------|41| I-001 | | P1/P2/P3/P4 | | | | | | Open/In Progress/Blocked/Resolved | | | |4243#### Dependencies (external needs or handoffs)4445| ID | Dependency Description | Type | Providing Team | Receiving Team | Owner | Date Needed | Date Committed | Status | Impact if Missed |46|----|----------------------|------|---------------|---------------|-------|-------------|---------------|--------|-----------------|47| D-001 | | Internal/External/Technical/Regulatory | | | | | | On Track/At Risk/Missed/Delivered | |4849### Step 3: Assess Severity and Priority5051Apply a consistent scoring model:5253**Risk Severity Matrix**5455| | Low Impact | Medium Impact | High Impact |56|---|-----------|--------------|-------------|57| **High Probability** | Medium | High | Critical |58| **Medium Probability** | Low | Medium | High |59| **Low Probability** | Low | Low | Medium |6061**Issue Priority Definitions**6263| Priority | Definition | Response Time | Escalation |64|----------|-----------|---------------|-----------|65| P1 - Critical | Blocks program delivery or multiple workstreams | Same day | Immediate to sponsor |66| P2 - High | Significant impact on timeline or budget | 2 business days | Weekly steerco |67| P3 - Medium | Moderate impact, workaround exists | 1 week | Program review |68| P4 - Low | Minor inconvenience, no timeline impact | Next cycle | Team standup |6970### Step 4: Define Mitigation and Resolution Plans7172For each open Risk or Issue, ensure:731. **Owner** is a named individual (not a team)742. **Action steps** are specific and time-bound753. **Escalation path** is defined if mitigation fails764. **Success criteria** are clear for closing the item775. **Dependencies** on other RAID items are cross-referenced7879### Step 5: Generate Summary Dashboard8081Produce a roll-up view:8283```84RAID SUMMARY — [Program Name] — [Date]8586| Category | Open | In Progress | Closed | Critical/P1 |87|-------------|------|-------------|--------|-------------|88| Risks | | | | |89| Assumptions | | | | |90| Issues | | | | |91| Dependencies | | | | |9293TOP 3 RISKS REQUIRING ATTENTION941. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]952. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]963. [R-XXX]: [Description] — Owner: [Name] — Due: [Date]9798TOP 3 ISSUES REQUIRING RESOLUTION991. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]1002. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]1013. [I-XXX]: [Description] — Owner: [Name] — Due: [Date]102103OVERDUE ITEMS104- [List any items past their target resolution date]105106NEWLY ADDED THIS PERIOD107- [List items added since last review]108```109110## Output Format1111121. **RAID Summary Dashboard** (Step 5) for quick executive consumption1132. **Full RAID Log Tables** (Step 2) with all items and current status1143. **Action Items** extracted from mitigation and resolution plans with owners and deadlines1154. **Trends** noting items opened vs. closed since last review1165. **Escalation Recommendations** for any items that need leadership intervention117118## Quality Checklist119120- [ ] Every item has a unique ID following the convention (R/A/I/D-NNN)121- [ ] Every item has a single named owner (not a team or "TBD")122- [ ] All Critical/P1 items have mitigation or resolution plans documented123- [ ] Risk severity is assessed using the probability x impact matrix consistently124- [ ] Dependencies have both a "date needed" and a "date committed" from the providing team125- [ ] Assumptions are tagged with validation method and checked regularly126- [ ] Closed items retain their history for audit trail and lessons learned127- [ ] Cross-references exist between related items (e.g., a Risk that became an Issue)128- [ ] Dates use a consistent format throughout (YYYY-MM-DD recommended)129- [ ] No stale items — every open item was reviewed within the last reporting cycle130131## Edge Cases132133- **New program with no history**: seed the RAID log with common risks for the program type (integration, staffing, scope creep, vendor delays) and ask the user to validate134- **Merging RAID logs from multiple workstreams**: deduplicate, reconcile severity ratings, and assign a single program-level owner for cross-cutting items135- **Risk that has materialized**: convert it to an Issue, close the Risk with a note, and cross-reference the new Issue ID136- **Assumption invalidated**: escalate immediately, assess blast radius across workstreams, and create Issues or Risks for downstream impacts137- **Dependency with no committed date**: flag as At Risk and escalate to the providing team's leadership for commitment138- **Excessive RAID items (50+)**: group by workstream or theme, prioritize the top items for active management, and archive low-severity closed items
ashutoshsrivastava17