Un rischio è qualcosa che potrebbe accadere e danneggerebbe il progetto se accadesse. La gestione dei rischi consiste nell'identificare quelle minacce in anticipo e decidere cosa fare al riguardo prima che causino danni. L'intuizione semplice: i problemi sono molto più facili da affrontare quando li hai considerati in anticipo.
Un semplice strumento ampiamente utilizzato per tracciare minacce e elementi del progetto:
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
Un progetto dipende da un'API di terze parti che è nuova e non provata. Rischio: potrebbe non funzionare. Probabilità media, impatto alto. Mitigazione: testala presto, costruisci un'astrazione in modo da poter cambiare provider e avere un fallback. Ora un'incognita è un rischio gestito con un piano.
Trattare la gestione dei rischi come una checklist di avvio una tantum. I rischi evolvono — rivedi regolarmente il RAID log e aggiungi nuovi rischi man mano che emergono.
I rischi non gestiti diventano crisi, solitamente nel momento peggiore possibile vicino a una scadenza.
Il costo della gestione di un rischio in anticipo è minuscolo rispetto a spegnerlo dopo che accade.
Nominare i rischi ad alta voce costruisce anche fiducia — gli stakeholder preferiscono "ecco cosa potrebbe andare male e il nostro piano" al silenzio fiducioso seguito da una spiacevole sorpresa.