En risk är något som kan inträffa och skulle skada projektet om det gjorde det. Riskhantering är att identifiera dessa hot tidigt och bestämma vad man ska göra åt dem innan de drabbar. Den billiga insikten: problem är långt mycket lättare att hantera när du har tänkt på dem i förväg.
Ett enkelt, allmänt använt verktyg för att spåra projekt hot och poster:
R — RISKS → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS → things we're taking as true (validate them)
I — ISSUES → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
For each risk, score:
LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
AVOID → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT → live with it, but have a fallback ready
Ett projekt är beroende av ett tredje parts API som är nytt och oprövat. Risk: det kan inte fungera bra. Sannolikhet medel, påverkan hög. Minskning: test det tidigt, bygg en abstraktion så du kan byta leverantörer, och ha en reserv. Nu är det okända en hanterad risk med en plan.
Att behandla riskhantering som en engångs kickoff-checklista. Risker utvecklas — granska RAID-loggen regelbundet och lägg till nya när de uppstår.
Ohanterade risker blir kriser, vanligtvis i värsta möjliga ögonblick nära en deadline.
Kostnaden för att hantera en risk tidigt är minimal jämfört med att bekämpa den efter att den slår till.
Att namnge risker högt bygger också förtroende — intressenter föredrar "här är vad som kan gå fel och vår plan" framför självsäker tystnad följd av en otrevlig överraskning.