En risiko er noget, der kan ske og ville skade projektet, hvis det gør det. Risikostyring er at identificere disse trusler tidligt og beslutte, hvad man skal gøre ved dem, før de bider. Den billige indsigt: problemer er langt lettere at håndtere, når du har tænkt på dem på forhånd.
Et enkelt og udbredt værktøj til at spore projektproblemer og emner:
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 projekt er afhængigt af et tredjeparternes API, der er nyt og uprøvet. Risiko: det fungerer muligvis ikke. Sandsynlighed medium, påvirkning høj. Mindskning: tester det tidligt, byg en abstraktion så du kan bytte udbydere, og hav en fallback. Nu er det ukendte en styret risiko med en plan.
At behandle risikostyring som en engangs-tjekliste til kickoff. Risici udvikler sig — gennemgå RAID-loggen regelmæssigt og tilføj nye, efterhånden som de opstår.
Ustyrerede risici bliver kriser, normalt på det værst mulige tidspunkt tæt på en deadline.
Omkostningerne ved at håndtere en risiko tidligt er minuscule sammenlignet med at brande den efter, at den rammer.
At nævne risici højt bygger også tillid – interessenter foretrækker "her er, hvad der kunne gå galt og vores plan" frem for selvsikker stilhed efterfulgt af en ubehagelig overraskelse.