βΆRisk register vs risk dashboard β what's the difference and when do I use each?
Risk register is a living document (spreadsheet/database) listing all identified risks: ID, description, probability, impact, mitigation owner, status, review date. Risk dashboard visualizes trends and status across the register (which risks are trending up/down, what's overdue for review). Register = detail and accountability; dashboard = executive visibility. Best practice: maintain the register (single source of truth), feed data into dashboard for stakeholders. Update register quarterly minimum; dashboard monthly or real-time if automated.
βΆHow do I assign probability and impact numbers when uncertainty is high?
Use ranges, not point estimates. Probability: 0.1 (rare), 0.3 (unlikely), 0.5 (possible), 0.7 (likely), 0.9 (almost certain). Impact: score in business terms ($M loss, days downtime, customers affected). For unknown risks, use 3-point estimation: pessimistic/most likely/optimistic scenario, calculate expected value. Facilitate with domain experts (not guesses). Document your assumptions β 'we assume X happens' β so reviews can challenge them. Revisit estimates as data arrives; initial estimates are always wrong, and that's expected.
βΆPre-mortem vs post-mortem β when do I run each and why?
Pre-mortem: 1 week before project launch. Team imagines the project failed catastrophically. 'It's 6 months from now, the product flopped. Why?' Reveals blind spots and unknown unknowns that probability-impact matrices miss. Post-mortem: after failure or major incident. Blameless, focus on systems/processes not people. Pre-mortem finds risks proactively; post-mortem learns from realized risks. Best organizations run both: pre-mortem β mitigation β if failure happens β post-mortem β close loop.
βΆQuantitative vs qualitative risk analysis β which should I use?
Qualitative first (risk register, brainstorming) β fast, includes narrative, good for exploration. Then quantitative only for high-impact risks (Monte Carlo simulation, decision trees, cost-benefit of mitigation). Quantitative is expensive: Monte Carlo = weeks of modeling, data collection, sensitivity analysis. Use it when: (1) decision is >$1M, (2) regulatory requires it, (3) risk is highly uncertain. For 80% of risks, qualitative + mitigations are enough. Qualitative scales; quantitative scales badly.
βΆRisk appetite vs risk tolerance β are they the same thing?
No. Risk appetite = organizational strategy: 'We will accept 5% downtime to move faster.' Risk tolerance = guardrail: 'We will not exceed 6% downtime.' Appetite is decided by executives; tolerance is enforced by operations. Example: a fintech startup may have high appetite for product risk (move fast, break things) but low tolerance for security risk (regulatory requirement). You set appetite, then design tolerances to stay within it. Monitoring tolerance triggers escalations, hedge strategies, or controls tightening.
βΆHow do I convince leadership to invest in risk mitigation when the risk hasn't happened yet?
Show expected value: (Probability Γ Impact) = cost to mitigate should be <50% of EV. Example: data breach = 10% probability Γ $10M loss = $1M EV. Spending $300k on security reduces probability to 2% = $200k EV. Insurance is another lens: 'What would insurance cost? Mitigation vs premium trade-off.' Tell stories of competitors who suffered (Equifax breach, Capital One data loss = not abstract). Reframe: 'We're not spending on something that might happen, we're spending on probability reduction.' Board-level: create risk radar (top 10 enterprise risks, each with mitigation spend); prioritize portfolio.
βΆWho owns risk? The CEO, CFO, CTO, or the PM?
All of them, differently. CEO/board owns enterprise risk strategy and risk appetite. CFO owns financial/operational risk, manages insurance, capital allocation. CTO owns technology/security risk. PM/team owns project risk (schedule, scope, budget). Create a RACI: Risk Committee (monthly) with CEO/CFO/CTO/heads of ops. Each brings their domain; CFO or Chief Risk Officer (if you have one) chairs. Team PMs escalate project risks monthly. Enterprise risks feed quarterly board reports. No single owner = risks fall through cracks. Centralize escalation process.
βΆReal-world example: How did a startup use risk assessment to avoid a $2M failure?
A SaaS company was building a new enterprise product. Pre-mortem identified: 'What if our data model doesn't scale? What if the sales cycle is 6 months longer than expected?' Team ran Monte Carlo on 'time to product-market fit' with 50 scenarios. Found 30% chance of cash-out before profitability. Shifted risk: (1) Built MVP in 6 weeks (reduce feature risk), (2) pre-sold 3 customers at discount (reduce sales cycle risk), (3) secured bridge round (reduce cash risk). Result: launched on time, paid back bridge in 8 months. Pre-mortem + quantitative analysis = $2M and 2-year pivot avoided.