Gestire il rischio non è facoltativo
Ogni progetto digitale convive con l’incertezza. Una dipendenza esterna che slitta, un fornitore che cambia API senza preavviso, un membro chiave del team che si ammala nella settimana sbagliata. Il rischio di progetto è la possibilità che un evento incerto, se si verifica, abbia un effetto sugli obiettivi: tempi, costi, qualità, ambito.
La gestione del rischio (risk management) è il processo con cui un project manager rende visibile questa incertezza, la misura e decide cosa farne prima che diventi un problema conclamato. La differenza tra un PM junior e uno senior si vede proprio qui: il primo reagisce agli incendi, il secondo li ha previsti e ha già pronto l’estintore.
Perché il risk management si fa in pianificazione
Il momento giusto per occuparsi dei rischi è all’inizio, durante la pianificazione, e poi in modo continuo per tutta la durata del progetto. Ci sono due ragioni concrete.
La prima è il costo del cambiamento. All’avvio modificare un piano costa poco: sposti una data, rinegozi uno scope, prevedi una riserva. A progetto avviato lo stesso intervento costa molto di più, perché hai già speso budget e tempo. Anticipare i rischi significa intervenire quando le leve costano meno.
La seconda è la riserva. Identificare i rischi ti permette di stimare una contingency, cioè un margine di tempo o budget destinato a coprire gli imprevisti che hai previsto. Senza analisi del rischio quel margine lo metti a caso, oppure non lo metti affatto e il progetto sfora alla prima difficoltà.
La gestione del rischio si appoggia su altri artefatti di pianificazione. Senza un perimetro chiaro del lavoro non sai dove cercare i rischi: per questo conviene partire da una work breakdown structure ben fatta, che scompone il progetto in pacchetti di lavoro analizzabili uno per uno. E i confini complessivi, gli obiettivi e i vincoli da proteggere sono quelli fissati nel project charter.
Il processo in 5 passi
Il risk management non è un’attività una tantum ma un ciclo che gira per tutto il progetto. Lo si descrive di solito in cinque passi.
1. Identificazione
Si compila la lista più completa possibile dei rischi. Le tecniche utili sono il brainstorming con il team, la revisione di progetti simili passati (lessons learned), le checklist di categoria, le interviste agli esperti di dominio e l’analisi degli assunti. L’obiettivo qui è la copertura: meglio un rischio in più da scartare poi che un rischio mancante che ti esplode in faccia.
2. Analisi qualitativa
Ogni rischio identificato viene valutato su due dimensioni: la probabilità che si verifichi e l’impatto che avrebbe se si verificasse. È un’analisi rapida, basata sul giudizio del team, che serve a ordinare i rischi per priorità. La maggior parte dei progetti digitali si ferma qui, e va benissimo: l’analisi qualitativa filtra il rumore e ti dice su cosa concentrarti.
3. Analisi quantitativa
Sui rischi più critici, e solo su quelli, si può fare un passo in più: stimare l’effetto in numeri. Quanti giorni di ritardo, quanti euro di costo aggiuntivo, con quale probabilità. Tecniche come l’analisi del valore atteso (probabilità per impatto economico) o le simulazioni servono a dimensionare la riserva. Per molti progetti digitali questo passo è opzionale e si applica solo dove la posta in gioco lo giustifica.
4. Pianificazione delle risposte
Per ogni rischio prioritario si decide una strategia di risposta e si assegna un responsabile. È il passo che trasforma una lista di paure in un piano d’azione. Lo vediamo in dettaglio più avanti.
5. Monitoraggio e controllo
I rischi non sono statici. Alcuni si verificano, altri scompaiono, altri ancora cambiano probabilità nel corso del progetto, e ne emergono di nuovi. Il monitoraggio è la revisione periodica del registro: si verifica lo stato delle risposte, si aggiornano i punteggi, si chiudono i rischi superati. Senza questo passo il risk register diventa un documento morto compilato una volta e mai più aperto.
La matrice probabilità × impatto
Il cuore dell’analisi qualitativa è la matrice probabilità × impatto. Si valutano entrambe le dimensioni su una scala da 1 a 5 e si moltiplicano per ottenere un punteggio di rischio (risk score) da 1 a 25. Più alto il punteggio, più alta la priorità.
Una scala da 1 a 5 tipica per la probabilità:
| Valore | Probabilità | Significato |
|---|---|---|
| 1 | Molto bassa | Raro, sotto il 10% |
| 2 | Bassa | Improbabile, 10-30% |
| 3 | Media | Possibile, 30-50% |
| 4 | Alta | Probabile, 50-70% |
| 5 | Molto alta | Quasi certo, oltre il 70% |
E una scala analoga per l’impatto, da 1 (trascurabile, assorbibile senza conseguenze) a 5 (critico, mette a rischio gli obiettivi del progetto). Il punteggio finale (probabilità per impatto) si legge con un codice colore che rende immediata la priorità:
| Risk score | Fascia | Codice colore | Azione |
|---|---|---|---|
| 1-5 | Basso | Verde | Accetta e monitora |
| 6-12 | Medio | Giallo | Pianifica una risposta |
| 15-25 | Alto | Rosso | Risposta prioritaria e owner dedicato |
Il colore non è estetica: in una riunione di stato un rischio rosso cattura l’attenzione in un secondo, e questo è esattamente lo scopo. La matrice ti dà un ordine di lavorazione difendibile, basato su criteri espliciti e non sull’istinto di chi urla più forte.
Le strategie di risposta
Identificato un rischio rilevante, hai quattro strategie classiche per le minacce, cioè per i rischi negativi.
Evitare
Elimini la causa del rischio cambiando il piano. Se una tecnologia immatura ti preoccupa, scegli una soluzione collaudata. È la risposta più radicale e si usa quando l’impatto sarebbe inaccettabile.
Trasferire
Sposti la responsabilità del rischio su un terzo. L’esempio tipico è un’assicurazione, una garanzia contrattuale o l’affidamento di una componente critica a un fornitore specializzato con penali. Il rischio non sparisce, ma il suo impatto economico non grava più solo su di te.
Mitigare
Riduci la probabilità o l’impatto, o entrambi, senza eliminarli del tutto. È la strategia più frequente: aggiungi test automatici, prevedi una persona di backup, anticipi un’integrazione delicata per avere tempo di reagire. Mitighi quando il rischio resta ma puoi renderlo gestibile.
Accettare
Decidi consapevolmente di convivere con il rischio. Può essere accettazione passiva (non fai nulla, ma lo monitori) o attiva (prevedi una riserva di tempo o budget da usare se si verifica). Si accetta quando il costo della risposta supererebbe il danno atteso.
Non tutti i rischi sono minacce. Esistono anche le opportunità, cioè rischi positivi, e hanno strategie speculari: sfruttare (rendere certa l’opportunità), condividere (allearsi con chi può realizzarla), potenziare (aumentarne probabilità o impatto) e accettare. Un PM senior tiene d’occhio entrambe le facce: un fornitore che consegna in anticipo è un’opportunità da sfruttare, non solo una sorpresa.
Il risk register colonna per colonna
Il risk register è il documento operativo che tiene insieme tutto il processo. È una tabella, viva e aggiornata, in cui ogni riga è un rischio. Vediamo le colonne essenziali.
- ID: codice univoco del rischio (R-01, R-02…). Serve per riferirsi al rischio in modo non ambiguo nei verbali e nelle comunicazioni.
- Descrizione: l’enunciato del rischio. Scrivilo in forma causa-evento-effetto, ad esempio “a causa della dipendenza da un’API esterna, l’integrazione potrebbe slittare, ritardando il rilascio”.
- Categoria: il tipo di rischio (tecnico, esterno, organizzativo, di gestione progetto). Aiuta a raggruppare e a leggere dove si concentra l’esposizione.
- Probabilità: il valore da 1 a 5 dell’analisi qualitativa.
- Impatto: il valore da 1 a 5.
- Priorità: il risk score (probabilità per impatto) con il suo codice colore.
- Owner: la persona responsabile di monitorare il rischio ed eseguire la risposta. Un rischio senza owner è un rischio di nessuno.
- Risposta: la strategia scelta (evitare, trasferire, mitigare, accettare) e l’azione concreta.
- Stato: aperto, in monitoraggio, mitigato, verificatosi, chiuso. Racconta il ciclo di vita del rischio.
Esempio compilato: progetto digitale
Ecco come potrebbe apparire un estratto di risk register per un progetto di sviluppo software con integrazioni esterne.
| ID | Descrizione | Cat. | P | I | Score | Owner | Risposta | Stato |
|---|---|---|---|---|---|---|---|---|
| R-01 | API del fornitore di pagamenti potrebbe cambiare versione durante lo sviluppo | Tecnico | 3 | 4 | 12 giallo | Tech Lead | Mitigare: layer di astrazione + monitoraggio changelog | In monitoraggio |
| R-02 | Sviluppatrice senior unica su un modulo critico, rischio indisponibilità | Organizzativo | 3 | 5 | 15 rosso | PM | Mitigare: pair programming + documentazione modulo | Aperto |
| R-03 | Requisiti del cliente non ancora stabili sul flusso di checkout | Gestione progetto | 4 | 4 | 16 rosso | Product Owner | Mitigare: prototipo + sign-off anticipato | Aperto |
| R-04 | GDPR: trattamento dati nuovo modulo da validare con il legale | Esterno | 2 | 5 | 10 giallo | PM | Trasferire: revisione a consulente privacy esterno | In monitoraggio |
| R-05 | Picco di traffico al lancio potrebbe degradare le performance | Tecnico | 2 | 3 | 6 giallo | DevOps | Accettare (attiva): riserva budget per scaling on demand | Aperto |
Le categorie di rischio
Ragionare per categorie aiuta a non dimenticare interi tipi di rischio durante l’identificazione. Uno schema utile per i progetti digitali distingue almeno quattro famiglie.
- Tecnici: tecnologie immature, debito tecnico, integrazioni, performance, sicurezza.
- Esterni: fornitori, normativa, mercato, dipendenze fuori dal tuo controllo.
- Organizzativi: risorse, competenze, priorità in conflitto, disponibilità delle persone.
- Di gestione progetto: stime ottimistiche, scope poco chiaro, comunicazione, pianificazione.
Una categoria di rischio sempre più rilevante nei progetti odierni riguarda l’uso dell’intelligenza artificiale: dipendenza da modelli di terze parti, qualità imprevedibile degli output, costi variabili. Su questo fronte vale la pena approfondire come l’AI sta cambiando la gestione del rischio di progetto, sia come fonte di nuovi rischi sia come strumento per identificarli prima.
Manutenzione del registro
Un risk register vale quanto la sua manutenzione. La regola pratica è rivederlo a cadenza fissa, allineata al ritmo del progetto. In un contesto agile la review naturale è a ogni sprint, in fase di pianificazione e di retrospettiva. In un contesto a fasi, una review settimanale o quindicinale è un buon punto di partenza, con una revisione straordinaria a ogni milestone o evento significativo.
In ogni review si fanno quattro cose: si aggiornano probabilità e impatto dei rischi aperti, si chiudono quelli superati, si registrano i nuovi emersi e si verifica che le risposte pianificate siano effettivamente in corso.
Il registro va inoltre collegato alle responsabilità reali del team. La colonna owner non deve mai restare vuota, e gli owner vanno scelti in modo coerente con la matrice RACI del progetto: chi è Responsible o Accountable su una certa area è il candidato naturale a possedere i rischi di quell’area. Se la RACI dice che il Tech Lead è accountable sull’architettura, i rischi tecnici di architettura hanno lui come owner. Questo evita il rischio più insidioso di tutti: un registro pieno di rischi che, sulla carta, non sono responsabilità di nessuno.
Il rischio è una competenza senior
Saper costruire e governare un risk register è uno dei segnali più chiari di maturità di un project manager. Non è una tecnica da imparare a memoria, è un modo di pensare: vedere l’incertezza prima che diventi crisi, quantificarla, assegnarla, monitorarla. È esattamente il tipo di competenza che distingue chi gestisce progetti complessi da chi si limita a seguirli.
Se vuoi sviluppare queste capacità a livello avanzato, con moduli dedicati a KPI, tool e gestione del rischio nei progetti digitali, il percorso giusto è quello executive. Scopri il corso Digital Project Manager Executive: è erogato interamente online, on demand, in 118 ore con accesso 12 mesi, e prepara alle certificazioni CAPM (PMI) e PSM I (Scrum.org). Per la candidatura CAPM, Castro & Partners è Authorized Training Partner PMI e il percorso copre le 23 Contact Hours richieste. Gli esami di certificazione sono esterni e non inclusi (verificare l’importo aggiornato presso l’ente).
Template risk register
Ecco un template di partenza che puoi copiare in un foglio di calcolo o in uno strumento di project management. Adatta scale e categorie al tuo contesto.
RISK REGISTER — Progetto: ______________________ Aggiornato al: __________
Scala probabilità (P) e impatto (I): 1 = molto basso ... 5 = molto alto
Risk score = P x I | 1-5 VERDE | 6-12 GIALLO | 15-25 ROSSO
| ID | Descrizione (causa > evento > effetto) | Categoria | P | I | Score | Owner | Strategia risposta | Azione concreta | Stato |
|------|----------------------------------------|----------------|---|---|-------|-------|-------------------------------|------------------------------|---------------|
| R-01 | | Tecnico | | | | | Evita/Trasferisci/Mitiga/Accetta | | Aperto |
| R-02 | | Esterno | | | | | | | In monitoraggio |
| R-03 | | Organizzativo | | | | | | | Mitigato |
| R-04 | | Gestione prog. | | | | | | | Chiuso |
Legenda Stato: Aperto | In monitoraggio | Mitigato | Verificatosi | Chiuso
Cadenza review: ogni sprint / settimanale / a ogni milestone
Owner = coerente con la matrice RACI del progetto
FAQ
Qual è la differenza tra rischio e problema (issue)?
Un rischio è un evento incerto che potrebbe verificarsi in futuro. Un problema (issue) è un evento che si è già verificato e che stai gestendo adesso. Il risk register tiene traccia dei rischi; quando un rischio si concretizza, diventa un problema e si gestisce con un piano d’azione, mentre nel registro aggiorni il suo stato a “verificatosi”.
Ogni progetto ha bisogno di un risk register?
Praticamente sì, ma con un livello di dettaglio proporzionato. Per un piccolo progetto bastano poche righe su un foglio condiviso; per un progetto digitale complesso con molte dipendenze il registro diventa uno strumento centrale, rivisto a ogni ciclo. Il principio non cambia: rendere visibile l’incertezza è sempre meglio che ignorarla.
Quanti rischi dovrebbe contenere un registro?
Non esiste un numero giusto. Conta la qualità della copertura, non la quantità. Un registro con dieci rischi ben analizzati e con owner assegnati è molto più utile di uno con cinquanta voci generiche che nessuno aggiorna. Concentra l’energia sui rischi della fascia gialla e rossa.
Chi è il responsabile del risk register?
Il project manager è responsabile del processo e del mantenimento del registro, ma non è l’owner di ogni singolo rischio. Ogni rischio ha un proprio owner, scelto in base alle competenze e alla matrice RACI del progetto. Il PM facilita le review, garantisce che il registro sia aggiornato e che le risposte siano in corso.
