Risk Management in PM²: anticipare l’incertezza prima che diventi un problema
Diciottesimo articolo della serie “Imparare PM² attraverso un progetto”
Un rischio non è un problema già accaduto. È un evento o una condizione incerta che, se si verificasse, potrebbe influire su obiettivi, tempi, costi, qualità, scope o benefici del progetto.
Il Risk Management in PM² non promette di eliminare ogni incertezza. Serve a renderla visibile, valutarla e gestirla con azioni ragionevoli prima che si trasformi in un’issue.
Risk e issue: il confine essenziale
| Termine | Stato | Esempio |
|---|---|---|
| Risk | Possibile, non ancora accaduto | Il provider push potrebbe modificare le proprie policy prima del go-live. |
| Issue | Reale, già presente o già avvenuto | Il provider ha modificato la policy e le notifiche non vengono più inviate. |
Quando un rischio si materializza, non resta semplicemente “un rischio rosso”: diventa un’issue e deve essere gestito come tale. Il Risk Log conserva comunque la storia e l’apprendimento.
Il ciclo di gestione del rischio
flowchart LR
A[Identificare] --> B[Analizzare]
B --> C[Valutare e prioritizzare]
C --> D[Pianificare la risposta]
D --> E[Assegnare owner e azioni]
E --> F[Monitorare rischio residuo]
F --> A
È un ciclo, non un’attività iniziale. Nuove dipendenze, cambi di priorità, risultati dei test, fornitori e stakeholder possono far emergere rischi o cambiare il profilo di quelli già noti.
Identificare bene un rischio
Una formulazione utile collega causa, evento e conseguenza:
A causa di [causa], potrebbe verificarsi [evento], con l’effetto di [conseguenza sul progetto].
Esempio:
A causa della dipendenza da un provider esterno, potrebbe cambiare la policy delle notifiche push, con l’effetto di ritardare il go-live o ridurre una funzionalità prevista.
Scrivere “rischio notifiche” non aiuta a decidere né a definire una risposta.
Analisi: probabilità e impatto
PM² usa l’analisi di probabilità e impatto per ordinare l’attenzione del progetto. L’impatto può riguardare una o più aree: obiettivi, tempi, costi, qualità, scope, sicurezza, reputazione o benefici.
| Probabilità / impatto | Gestione indicativa |
|---|---|
| Bassa / basso | Monitorare in modo leggero. |
| Alta / basso | Ridurre la probabilità se il costo è ragionevole. |
| Bassa / alto | Preparare una risposta o contingency plan. |
| Alta / alto | Priorità immediata; escalation se supera le tolleranze. |
Un punteggio aiuta a confrontare i rischi, ma non sostituisce il giudizio. Un rischio raro con impatto normativo o di sicurezza molto alto può richiedere attenzione prioritaria anche se il prodotto “probabilità × impatto” non sembra massimo.
Le strategie di risposta
Per le minacce, le risposte più comuni sono:
| Strategia | Cosa significa | Esempio |
|---|---|---|
| Avoid — evitare | Cambiare piano per eliminare la causa o il rischio. | Non dipendere da una funzionalità beta di un fornitore. |
| Mitigate — mitigare | Ridurre probabilità o impatto. | Creare un prototipo e testare presto l’integrazione push. |
| Transfer — trasferire | Spostare parte della responsabilità o dell’impatto a terzi, senza eliminare la supervisione. | Contratto con SLA e supporto del provider. |
| Accept — accettare | Decidere consapevolmente di non intervenire oltre il monitoraggio, spesso con contingency. | Accettare un rischio minore con una procedura manuale pronta. |
L’errore è scegliere “accept” perché non si è avuto tempo di analizzare. L’accettazione deve essere consapevole e commisurata all’autorità e alle tolleranze del progetto.
Le opportunità possono essere gestite in modo speculare: sfruttarle, potenziarle, condividerle o accettarle. Il rischio non è sempre solo negativo, anche se nella pratica di progetto il termine viene spesso usato per le minacce.
Risk owner e azioni: senza, il log è solo un archivio
Ogni rischio rilevante deve avere almeno:
| Campo | Utilità |
|---|---|
| Descrizione causa-evento-effetto | Comprendere con precisione cosa può accadere. |
| Probabilità e impatto | Prioritizzare. |
| Risk owner | Persona responsabile di monitorare e far avanzare la risposta. |
| Azioni e scadenze | Rendere concreta la risposta. |
| Trigger / segnali precoci | Sapere quando attivare contingency o escalation. |
| Rischio residuo | Capire cosa resta dopo le azioni. |
Il risk owner non è necessariamente chi esegue tutte le azioni e non è automaticamente il PM. Il PM assicura che il processo funzioni; il risk owner sorveglia quel rischio specifico e segnala variazioni.
Il caso Annotatio: il rischio di adozione
Per Prenotazioni Smart, il team nota che i collaboratori di sala potrebbero continuare a gestire le prenotazioni informalmente, perché sono abituati a WhatsApp e telefonate.
| Elemento | Definizione |
|---|---|
| Causa | Nuovo processo percepito come più lento e poco conosciuto. |
| Evento | I collaboratori non usano sistematicamente Annotatio al go-live. |
| Effetto | Dati incoerenti, posti assegnati due volte, benefici ridotti e supporto più costoso. |
| Probabilità / impatto | Media / alta. |
| Risposta | Mitigare: prova guidata, micro-formazione, istruzioni operative e supporto ravvicinato nella prima settimana. |
| Trigger | Durante il pilota, più del 10% delle prenotazioni è ancora gestito fuori dal sistema. |
| Owner | Business Manager o responsabile operativo della palestra. |
Questo è un rischio di business implementation, non un “problema del team tecnico”. Gestirlo presto può proteggere i benefici più di molte ottimizzazioni di codice.
Risk appetite e tolleranze
Le organizzazioni non accettano tutte lo stesso livello di rischio. Il risk appetite indica quanto rischio sono disposte ad accettare in generale; le tolleranze traducono questa attitudine in limiti pratici per il progetto.
Quando un rischio supera le tolleranze o richiede un trade-off su budget, scope o data, il PM deve fare escalation alla governance competente con un’analisi e una raccomandazione. Aspettare la certezza assoluta può rendere la decisione tardiva e più costosa.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Un rischio è un problema possibile.” | È un evento incerto; quando è presente o si è verificato, diventa un’issue. |
| “Il Risk Log si compila all’avvio.” | Va aggiornato per tutto il progetto. |
| “Accettare un rischio significa ignorarlo.” | Significa decidere consapevolmente una risposta, spesso con monitoraggio e contingency. |
| “Il PM è owner di tutti i rischi.” | Il PM gestisce il processo; il rischio va assegnato all’owner più adatto. |
Tre domande per fissarlo
- Quale causa, evento e conseguenza definiscono questo rischio?
- Quale segnale precoce ti direbbe che sta aumentando?
- Quale risposta riduce davvero probabilità o impatto, e chi ne è owner?
Flashcard
D: Qual è la differenza tra risk e issue?
R: Il risk è incerto e futuro; l’issue è reale, presente o già avvenuta.
D: Cosa deve contenere un rischio ben gestito?
R: Descrizione, valutazione, owner, risposta, azioni, trigger e rischio residuo.
D: Cosa significa accept un rischio?
R: Decidere consapevolmente di non ridurlo ulteriormente, mantenendo monitoraggio e, se opportuno, una contingency.
Domanda in stile esame
Un fornitore comunica che la consegna di un componente potrebbe ritardare di tre settimane. Il PM apre immediatamente un’issue e fissa una nuova data di rilascio.
Qual è l’approccio corretto?
Risposta: finché il ritardo non si è verificato, è un rischio. Il PM deve valutarne probabilità e impatto, definire risposta e contingency, assegnare un owner e fare escalation se supera le tolleranze. Un cambio della baseline di rilascio richiede una decisione di governance, non una modifica automatica.
Fonte
Risk Management, Risk Management Plan, Risk Log e matrice probabilità/impatto sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo: Issue e Decision Management, per affrontare problemi reali e documentare le decisioni che cambiano il corso del progetto.