Risk Register Risk Register: {{PROJECT_NAME}} Project: {{PROJECT_NAME}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}} Document History Version Date Author Changes 0.1 {{DATE}} {{AUTHOR}} Initial draft 1. Risk Identification Methodology Identification Methods Used: Team brainstorming session (Date: {{DATE}}, Participants: {{PARTICIPANTS}}) Lessons learned review from previous projects Risk category checklist (see Section 2) Stakeholder interviews Assumption analysis (see project charter) Technical spike / proof-of-concept findings Initial Risk Assessment Date: {{DATE}} Next Scheduled Review: {{DATE}} Risk Owner: {{RISK_OWNER}} (typically the Project Manager) 2. Risk Categories Category Description Common Examples Technical Technology failures, integration issues, performance, security API changes, infrastructure limits, unknown complexity Resource Team availability, skill gaps, capacity constraints Key person sick leave, agent performance degradation Client Client-side decisions, availability, requirement volatility Delayed approvals, changing priorities, unclear requirements External Third-party dependencies, regulatory changes, market shifts API deprecation, GDPR change, competitor launch Financial Budget overruns, payment delays, cost estimates Underestimated effort, currency exposure, vendor price change Timeline Schedule risks, deadline pressure, estimation errors Milestone slip, hard deadline, dependency delays Quality Defect rate, technical debt, process failures Insufficient testing, rushed delivery, poor documentation Organizational Internal politics, process changes, leadership decisions Reprioritization, team restructure, tool changes 3. Risk Probability & Impact Scale 3.1 Probability Scale Level Score Definition Example Very Low 1 < 10% chance — rare, theoretical Unknown-unknown Low 2 10–30% chance — unlikely but possible Historical precedent rare Medium 3 30–50% chance — may occur Has happened on similar projects High 4 50–70% chance — likely to occur Happens regularly Very High 5 > 70% chance — almost certain Happened before on this type 3.2 Impact Scale Level Score Schedule Impact Budget Impact Quality Impact Negligible 1 < 1 day < 1% Minor fix needed Minor 2 1–3 days 1–5% Some rework needed Moderate 3 3–7 days 5–10% Significant rework Major 4 1–2 weeks 10–20% Deliverable at risk Critical 5 > 2 weeks > 20% Project failure risk 3.3 Risk Matrix (Probability × Impact) IMPACT → 1(Neg) 2(Min) 3(Mod) 4(Maj) 5(Crit) P 5(VH) | 5 | 10 | 15 | 20 | 25 | ← CRITICAL ZONE (≥15) R 4(H) | 4 | 8 | 12 | 16 | 20 | O 3(M) | 3 | 6 | 9 | 12 | 15 | B 2(L) | 2 | 4 | 6 | 8 | 10 | ← MEDIUM ZONE (5-14) ↑ 1(VL) | 1 | 2 | 3 | 4 | 5 | ← LOW ZONE (≤4) Score Risk Level Response Required Escalation 1–4 LOW Monitor; review monthly PM awareness 5–9 MEDIUM Active mitigation plan required PM + Tech Lead 10–14 HIGH Immediate action + weekly review PM + John 15–25 CRITICAL Emergency response; may stop project John + Alem 4. Risk Appetite Statement Overall Risk Appetite: {{LOW | MEDIUM | HIGH}} Risk Category Appetite Rationale Technical Medium Innovation requires technical experimentation Financial Low Budget is fixed; overruns require CEO approval Quality Low Client satisfaction is core to ALAI brand Timeline Medium Some schedule flexibility acceptable if quality maintained Security Very Low Zero tolerance for data breaches or compliance violations Regulatory Very Low Legal exposure is unacceptable Maximum Acceptable Risk Exposure: Score ≤ 9 without escalation to John. Escalation Threshold: Any risk scoring ≥ 10 must be reported to John within 24 hours. 5. Active Risk Register ID Risk Description Category Prob (1-5) Impact (1-5) Score Response Strategy Owner Trigger Indicators Status Date Identified Review Date R-001 {{RISK_DESCRIPTION}} Technical {{1-5}} {{1-5}} {{SCORE}} Mitigate {{OWNER}} {{TRIGGER}} Open {{DATE}} {{DATE}} R-002 Key client contact unavailable for approvals Client 3 4 12 Mitigate PM Slow email responses; missed meetings Open {{DATE}} {{DATE}} R-003 Third-party API deprecates required endpoint External 2 5 10 Mitigate Tech Lead Vendor changelog; API versioning notice Open {{DATE}} {{DATE}} R-004 Scope creep from undiscovered requirements Client 4 3 12 Mitigate BA/PM Frequent "small" change requests Open {{DATE}} {{DATE}} R-005 Performance targets not met under load Technical 3 4 12 Mitigate Tech Lead Slow response in dev testing Open {{DATE}} {{DATE}} R-006 {{RISK_DESCRIPTION}} Open {{DATE}} {{DATE}} R-007 Open R-008 Open 6. Risk Response Strategies Risk ID Strategy Response Actions Contingency Plan Resources Required R-001 {{STRATEGY}} 1. {{ACTION_1}}; 2. {{ACTION_2}} {{CONTINGENCY_IF_RISK_OCCURS}} {{RESOURCES}} R-002 Mitigate 1. Identify backup decision-maker; 2. Set approval deadlines in contract; 3. Async approval process Escalate to John → client sponsor PM time: 2h/week R-003 Mitigate + Accept 1. Abstract API calls behind service layer; 2. Monitor vendor changelog; 3. Build integration tests Switch to alternative vendor; allocate 3-day buffer Tech Lead: 1 day setup R-004 Avoid + Mitigate 1. Detailed BRD sign-off before development; 2. Formal change request process enforced; 3. Weekly scope review Raise change request; negotiate timeline/budget BA: 2h/week scope monitoring Response Strategy Definitions Strategy When to Use Action Avoid High score + feasible to eliminate Change plan to remove the risk source Mitigate Cannot avoid; must reduce probability or impact Implement controls, monitoring, early warning systems Transfer Risk can be shared with third party Insurance, contractual liability transfer, outsourcing Accept (Active) Low score; mitigation cost > risk cost Monitor and create contingency plan Accept (Passive) Negligible score Acknowledge, no action required Escalate Exceeds project authority or appetite Raise to John / Alem / client sponsor 7. Risk Heat Map quadrantChart title Risk Heat Map — {{PROJECT_NAME}} x-axis Low Impact --> High Impact y-axis Low Probability --> High Probability quadrant-1 "CRITICAL — Immediate Action" quadrant-2 "HIGH — Active Management" quadrant-3 "LOW — Monitor" quadrant-4 "MEDIUM — Watch" R-001: [0.7, 0.5] R-002: [0.6, 0.5] R-003: [0.8, 0.3] R-004: [0.5, 0.7] R-005: [0.7, 0.5] Update coordinates as Probability/Impact scores change. X = Impact/5, Y = Probability/5. 8. Escalation Thresholds Threshold Action Responsible Timeframe Any new risk Score ≥ 15 Immediate escalation to John + Alem PM Within 4 hours of identification Any existing risk score increases by ≥ 5 Escalate to John PM Within 24 hours > 3 risks at Score ≥ 10 simultaneously Emergency risk review meeting PM + John Within 48 hours Any risk triggers its contingency plan Notify all stakeholders PM Immediately Risk causes milestone slip > 3 days Formal change request + escalation PM Within 24 hours 9. Risk Review Schedule Frequency Activity Participants Output Weekly (Sprint Planning) Review all active risks, update scores/status PM, Tech Lead Updated register Sprint Retrospective Identify new risks; close resolved risks Full team New risks added Monthly Full risk register review + heat map update PM, John Risk report to stakeholders Ad-hoc New risk identified (any time) Risk identifier + PM New risk logged within 24h Milestone Risk review before each major milestone PM, Tech Lead, John Go/no-go input Review Log Date Reviewer Risks Reviewed New Risks Added Risks Closed Key Changes {{DATE}} {{NAME}} {{COUNT}} {{COUNT}} {{COUNT}} {{SUMMARY}} 10. Closed / Accepted Risks Archive ID Risk Description Resolution Type Resolution Notes Date Closed R-999 Example: Third-party payment provider delays Mitigated Switched to backup provider; no impact {{DATE}} Approval Role Name Date Signature Author Reviewer Project Manager AI Director (John) Project Sponsor