En risiko er noe som kunne skje og ville skade prosjektet hvis det gjorde det. Risikostyring er å identifisere disse truslene tidlig og bestemme hva du skal gjøre med dem før de slår til. Det billige innsiktet: problemer er mye lettere å håndtere når du har tenkt på dem på forhånd.
Et enkelt, mye brukt verktøy for å spore projekttrussler og elementer:
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
Et prosjekt avhenger av et tredjepartAPI som er nytt og uprøvd. Risiko: det kan ikke prestere. Sannsynlighet medium, impact høy. Mitigering: test det tidlig, bygg en abstraksjon slik at du kan bytte leverandører, og ha en fallback. Nå er det ukjente en styrt risiko med en plan.
Behandle risikostyring som en engangskickoff-sjekkliste. Risika utvikler seg — gjennomgå RAID-loggen regelmessig og legg til nye etter hvert som de dukker opp.
Usutnyttet risika blir kriser, vanligvis på det verst tenkelige tidspunktet nær en deadline.
Kostnaden for å håndtere en risiko tidlig er minimal sammenlignet med å slukke branner etter at den har inntruffet.
Å nevne risikoer høyt bygger også tillit — interessenter foretrekker "her er hva som kan gå galt og vår plan" fremfor selvtillit fulgt av en ubehagelig overraskelse.