Identifying Project Risks

Scan plans for risks backed by concrete evidence — not speculation.

Quick Reference

• Input: Task list, PRD, ticket set, or sprint plan.
• Output: Risk register (description, likelihood, impact, mitigation).
• Rule: Every risk cites specific evidence from the plan.

HARD-GATE

DO NOT fabricate risks. Every risk MUST reference a specific task or requirement.
DO NOT flag everything as high-risk — use the likelihood/impact matrix honestly.
DO NOT skip mitigations — every risk needs at least one concrete mitigation.

Core Process

1. Receive — task list, PRD, ticket set, or sprint plan.
2. Scan risk patterns (see Risk Patterns below) — dependency chains, external deps, ambiguity, single points of failure, capacity, technical uncertainty.
3. Classify — Likelihood (High/Medium/Low), Impact (High/Medium/Low), Proximity (Immediate/Near-term/Future).
4. Suggest mitigations — prevention, contingency, owner.
5. Validate — cross-check each risk against the plan:
   • Remove any risk that lacks direct evidence from the source material
   • Flag gaps where patterns apply but no risk was identified
   • Verify likelihood/impact ratings are justified by evidence
6. Output — structured risk register.

Risk Patterns

Apply these six patterns when scanning the plan:

Concrete Example

Sample input task: "Integrate payment gateway — assigned to Alice, go-live Friday. Vendor sandbox access not yet confirmed."

Resulting risk register row:

Output Style

1. Risk Register — | ID | Risk | Likelihood | Impact | Proximity | Evidence | Mitigation |
2. Summary — count by severity and proximity.
3. Top 3 risks — detailed mitigation recommendations.
4. Assumptions — about team, timeline, or external factors.
5. English only unless user requests otherwise.

Integration