risk-mitigation-plan

Risk Mitigation Plan

Proactively identify what could go wrong, quantify impact, and plan responses before committing to high-stakes decisions.

Context

You are a senior tech lead planning risk mitigation for $ARGUMENTS. Unmitigated risks become firefighting crises. Proactive planning prevents surprises and positions teams to respond confidently when issues arise.

Domain Context

• Risk = impact × probability — severe-but-unlikely risks matter less than frequent-but-tolerable risks. Quantify both dimensions.
• Irreversible vs reversible decisions — reversible decisions need less mitigation planning. Irreversible ones (data migrations, vendor contracts) need comprehensive planning.
• Known unknowns vs unknown unknowns — planning addresses known unknowns ("New framework might have performance issues"). Unknown unknowns are harder. Plan for known ones, design flexibility for unknowns.
• Mitigation strategies: reduce probability (fix root cause), reduce impact (limit blast radius), transfer risk (buy insurance or redundancy), accept risk (document and monitor).

Instructions

1. List risks: Brainstorm with team. "What could go wrong?" For each major decision, identify 5-10 risks. Example decision: migrate from monolith to microservices. Risks: data consistency, operational complexity, development velocity drop, organizational friction.

2. Assess risk severity: For each risk, estimate impact (1-10 scale, 10 is business-threatening) and probability (likelihood in next 12 months, 1-10). Calculate severity = impact × probability. Prioritize top 5-6 risks.

3. Plan mitigation per risk: For each high-severity risk, choose strategy. Example risk "Database migration corrupts data (impact 10, probability 2)": strategy is "reduce impact" via backups and rollback plan, not "reduce probability" (migration will happen). Plan the rollback explicitly.

4. Define monitoring triggers: "If data inconsistency errors exceed 10/day, rollback microservices immediately." "If development velocity drops >30%, pause microservices adoption, investigate." Have triggers that tell you "mitigation failed, execute backup plan."

5. Document and communicate: Risk register should be visible, not buried. Update quarterly or after significant incidents. Show how previous risks were addressed. Builds confidence that risk planning actually works.

Anti-Patterns

• Plans with no teeth: Writing risk mitigation plan, then ignoring it when risk occurs. Plans work only if you act on them. Assign owner to each mitigation. Check in monthly.
• Over-hedging: Mitigating every possible risk at enormous cost. Low-impact risks don't need mitigation. Focus on high-severity (impact × probability) risks only.
• Mitigation nobody can execute: Saying "if database migration fails, we'll restore from backup" without testing the restore. Document mitigation, test it, practice it. Untested mitigations are wishful thinking.
• Ignoring black swan risks: Spending time on predictable risks while ignoring true outliers. Some risk categories (regulatory, security, vendor failure) are impossible to fully mitigate. Design flexibility instead (modular code, data portability).
• No accountability for risk owners: Risk register exists but nobody owns monitoring/escalation. Assign explicit owner per risk. They report monthly: status, whether triggers were hit, actions taken.

Further Reading

• "Risk Management" (PMBOK, Project Management Institute) — comprehensive risk frameworks
• The Black Swan (Nassim Taleb) — unknown unknowns and tail risks
• "Enterprise Risk Management" (COSO framework) — organizational risk planning
• Antifragile (Nassim Taleb) — designing systems that benefit from volatility