Ogni progetto porta con se rischi. Ignorarli non li fa sparire: li fa crescere.
La gestione rischi progetto e il processo con cui un team identifica, valuta e riduce le minacce prima che diventino problemi reali.
In questo articolo trovi metodi pratici, un template di risk register e gli errori piu comuni che vedo ancora oggi sul campo.
Puoi applicare queste tecniche sia con metodologie agili sia con approcci tradizionali.
Cosa si intende per gestione rischi progetto
Un rischio e un evento incerto che, se si verifica, ha un impatto sugli obiettivi del progetto.
Il PMBOK Guide 7a edizione del PMI definisce il risk management come una delle dieci aree di conoscenza fondamentali per ogni project manager.
La differenza tra rischio e problema e semplice: il rischio e ancora futuro, il problema e gia presente.
Agire sui rischi ha un costo basso. Agire sui problemi ha un costo alto. Per questo la gestione rischi progetto vale ogni minuto investito.
Rischio positivo e rischio negativo
Non tutti i rischi sono minacce. Alcuni sono opportunita da cogliere.
Un ritardo del fornitore puo sembrare solo un problema. Ma puo anche aprire la porta a un nuovo partner con condizioni migliori.
Gestire entrambi i tipi di rischio e parte del lavoro di un PM maturo.
Le quattro fasi del processo di risk management
Il processo si divide in quattro fasi sequenziali. Saltarne una compromette il risultato finale.
Fase 1 — Identificazione
Si raccolgono tutti i rischi potenziali. Le tecniche piu usate sono il brainstorming con il team, le interviste agli stakeholder e la checklist storica di progetti simili.
Nella mia esperienza, coinvolgere anche i developer o i tecnici in questa fase produce elenchi molto piu completi rispetto a quelli del solo PM.
Fase 2 — Analisi qualitativa
Per ogni rischio si stima la probabilita di accadimento e l’impatto sugli obiettivi. Si usa la matrice probabilita-impatto.
I rischi con alta probabilita e alto impatto vanno trattati per primi. Gli altri si monitorano o si accettano.
Fase 3 — Analisi quantitativa (opzionale)
Si usa su progetti grandi o ad alto rischio finanziario. Si assegna un valore monetario o temporale a ogni rischio per stimare l’impatto totale sul budget.
Per la maggior parte dei progetti medi, l’analisi qualitativa e sufficiente.
Fase 4 — Risposta e monitoraggio
Si scelgono le azioni di risposta e si assegna un owner per ogni rischio. Le strategie principali sono quattro: evitare, trasferire, mitigare, accettare.
Il risk register viene aggiornato a ogni review di progetto, non solo all’inizio.
La matrice probabilita-impatto: come leggerla
La matrice e uno strumento visivo. Sulle righe metti la probabilita (bassa, media, alta). Sulle colonne metti l’impatto (basso, medio, alto).
Ogni rischio entra in una cella. La cella indica la priorita: verde = basso, giallo = medio, rosso = critico.
La semplicita e il punto di forza di questo strumento. Anche un cliente non tecnico capisce subito la situazione.
Errori comuni nella compilazione
Il primo errore e valutare tutti i rischi come “medi” per non creare allarmismo. Questo svuota di significato la matrice.
Il secondo errore e non aggiornare la matrice dopo ogni sprint o milestone. Un rischio che era basso all’inizio puo diventare critico a meta progetto.
Il risk register: struttura e template
Il risk register e il documento centrale della gestione rischi progetto. Contiene tutti i rischi identificati e il loro stato aggiornato.
Un risk register funzionale non e un foglio Excel di 40 colonne. E uno strumento vivo, consultato ogni settimana.
Le colonne minime necessarie sono:
- ID univoco del rischio
- Descrizione chiara (causa → evento → effetto)
- Probabilita: bassa / media / alta
- Impatto: basso / medio / alto
- Score di priorita (P x I)
- Strategia di risposta scelta
- Azione specifica pianificata
- Owner del rischio (nome, non ufficio)
- Data di revisione programmata
- Stato attuale: aperto / in corso / chiuso
Sul blog trovi anche come strutturare un PMO efficace che includa la gestione dei rischi a livello di portafoglio.
Strategie di risposta ai rischi nel dettaglio
Evitare il rischio
Si modifica il piano per eliminare la causa del rischio. E la strategia piu costosa ma piu efficace per i rischi critici.
Esempio: se un fornitore estero ha storicamente ritardi, si cambia fornitore in fase di pianificazione.
Trasferire il rischio
Si sposta l’impatto su un’altra parte, spesso tramite contratti o assicurazioni. Non elimina il rischio: lo sposta.
Usata soprattutto per rischi finanziari o legali nei progetti a contratto.
Mitigare il rischio
Si riduce la probabilita o l’impatto senza eliminare il rischio. E la strategia piu frequente nella pratica quotidiana.
Esempio: fare test di carico prima del go-live riduce il rischio di crash in produzione.
Accettare il rischio
Si decide di non agire, spesso perche il costo dell’azione supera l’impatto atteso. Va documentata come scelta consapevole, non come dimenticanza.
L’accettazione attiva prevede un piano di contingenza pronto. L’accettazione passiva non prevede nulla.
Gestione rischi in ambiente Agile
In Agile il risk management non scompare: si integra nei rituali dello sprint.
Come spiego nell’articolo su Agile e Waterfall ibrido, il contesto ibrido richiede che i rischi vengano rivisti a ogni sprint review.
Il backlog dei rischi si comporta come il product backlog: si ordina per priorita e si porta in sprint quando e il momento di agire.
I rischi tecnici emergono spesso durante la sprint retrospective. Raccoglierli li e un modo efficace per alimentare il risk register senza riunioni dedicate.
Risk management in Scrum
In Scrum non esiste un ruolo dedicato al risk manager. Il Product Owner gestisce i rischi di prodotto, lo Scrum Master gestisce i rischi di processo.
Il team gestisce i rischi tecnici nel daily stand-up, identificando impedimenti prima che diventino blocchi.
Secondo il Scrum Guide ufficiale, la trasparenza e il primo pilastro di Scrum: senza visibilita sui rischi, non c’e empirismo reale.
Domande frequenti sulla gestione dei rischi
Qual e la differenza tra rischio e problema?
Il rischio e incerto e futuro. Il problema e gia accaduto. Un rischio non gestito diventa un problema. Gestire i rischi significa agire prima che si materializzino.
Quando si aggiorna il risk register?
Almeno a ogni milestone o sprint review. In progetti ad alto rischio, ogni settimana. Il risk register fermo da 30 giorni e quasi sempre un segnale di allarme.
Serve un software dedicato al risk management?
No. Un foglio Excel ben strutturato copre il 90% dei casi per progetti medi. I software specializzati servono su programmi con decine di progetti in parallelo.
Chi e responsabile del risk management nel team?
Il PM e il responsabile del processo. Ma ogni rischio ha un owner specifico nel team, che puo essere uno stakeholder, un developer o un fornitore.
Vuoi padroneggiare il risk management sul campo?
La gestione rischi progetto si impara meglio su casi reali che su manuali.
Alla Management Academy trovi percorsi certificati in project management con moduli dedicati al risk management applicato, sia per chi si prepara alla PMP sia per chi vuole strumenti operativi subito.
Se vuoi capire prima come si posiziona questa competenza nel tuo percorso, leggi la guida su come diventare project manager certificato.
