# 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

<!-- GUIDANCE: Describe how risks were identified for this project. Common techniques include:
brainstorming sessions, expert interviews, lessons-learned reviews, checklists, and assumption analysis.
Document who participated and when the initial risk identification was conducted. -->

**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

<!-- GUIDANCE: Use these categories consistently across all risk entries to enable
trend analysis and risk reporting by category. -->

| 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

<!-- GUIDANCE: Use this 5-point scale consistently for all risk scoring.
Risk Score = Probability × Impact. Score determines required response level. -->

### 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)

<!-- GUIDANCE: Use this matrix to determine the risk level and required response speed. -->

```
         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

<!-- GUIDANCE: Document the organization's/project's tolerance for risk.
This guides decisions about which risks to accept vs. actively mitigate. -->

**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

<!-- GUIDANCE: Maintain this table throughout the project lifecycle. Update weekly during sprint planning.
Risk Score = Probability Score × Impact Score. Trigger Indicators = early warning signs to watch for.
Response Strategy: Avoid / Mitigate / Transfer / Accept (see Section 6). -->

| 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

<!-- GUIDANCE: Each active risk must have a documented response strategy with specific actions.
Add new rows for each risk requiring a detailed response plan. -->

| 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

<!-- GUIDANCE: Update this heat map monthly. Plot each active risk by its current probability/impact scores.
Replace risk IDs in the appropriate cells below. -->

```mermaid
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

<!-- GUIDANCE: Define explicit triggers for escalation. Removes ambiguity and ensures timely response. -->

| 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

<!-- GUIDANCE: Consistent review cadence is essential. Log each review in the Review Log table. -->

| 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

<!-- GUIDANCE: Never delete closed risks — they form the project's risk history and lessons learned.
Resolution types: Mitigated (controls worked), Occurred (risk happened), Avoided (risk eliminated),
Accepted (risk window passed), Transferred (handed to third party). -->

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