igmarin Identifying Project Risks
Scan plans for risks backed by concrete evidence — not speculation.
HARD-GATE
- Every risk must cite specific evidence (task, requirement).
- Do not flag everything high-risk; use likelihood/impact matrix honestly.
- Provide at least one concrete mitigation per risk.
Core Process
- Receive plan (tasks, tickets, PRD, sprint).
- Scan for six patterns: dependency chains, single points of failure, ambiguous requirements, external dependencies, capacity/resource issues, technical uncertainty.
- Classify each risk: Likelihood (High/Medium/Low), Impact (High/Medium/Low), Proximity (Immediate/Near-term/Future).
- Suggest mitigation (prevention, contingency, owner).
- Validate: remove risks lacking direct evidence.
- Output risk register.
Risk Patterns (six patterns)
- Dependency Chain (task B blocked by task A not done)
- Single Point of Failure (only one owner for critical item)
- Ambiguous Requirement (TBD, vague acceptance criteria)
- External Dependency (third-party API, vendor, regulatory)
- Capacity/Resource (team member over-allocated, holiday overlap)
- Technical Uncertainty (new tech, unproven integration, no spike)
Output
- Risk Register: ID | Risk | Likelihood | Impact | Proximity | Evidence | Mitigation | Owner
- Summary counts by severity and proximity.
- Top 3 risks with detailed mitigations (including owner).
Integration
- estimate-tasks — high-uncertainty tasks
- generate-tasks — dependency risks after task breakdown
- generate-status-report — include risk updates in stakeholder reports