Con questo primo articolo inauguriamo una rubrica dedicata al Risk Management seguendo le riflessioni e le best practice di Italferr, gruppo Ferrovie dello Stato, società con la missione di promuovere l’eccellenza dell’ingegneria ferroviaria italiana sul mercato nazionale ed internazionale.
Ringraziamo il Risk Officer di Italferr, Guido Mastrobuono ed Alessandro Saullo, Lead Project Risk Analyst di Italferr per la loro disponibilità e Italferr stessa per condividere con noi, uno tra gli aspetti più delicati e rilevanti nel governo dei progetti in questo comparto: l’identificazione e la gestione dei rischi.
La Redazione
Le metodologie di Project Management permettono di gestire la realizzazione di opere per mezzo di una sequenza di:
- – progetti e pianificazioni corretti,
- – una esecuzione accurata,
- – attività di controllo in grado di gestire adeguatamente le non conformità.
Questo quadro o framework metodologico funziona bene fin quando è possibile ignorare la complessità del contesto.
I progetti infrastrutturali, per loro natura, sono immersi nel contesto e, come rilevato in una ricerca di Bent Flyvbjerg (relativa alla crescita dei costi)[1], dagli anni Trenta del ‘900 in poi, l’85% delle opere ferroviarie sono costate più del costo preventivato. Ad esempio (figura 1) il 70% dei progetti ha avuto un incremento dei costi del 50% rispetto al budget. Di seguito (Tabella 1) lo stesso studioso riporta gli errori di stima dei costi di diverse tipologie di opere sulla base di un ampio campione statistico.
Figura 1 – Distribuzione degli aumenti dei costi (cost overrun) nelle ferrovie rispetto al budget iniziale. Percentile dei progetti il cui aumento dei costi è risultato al di sotto di una certa percentuale rispetto al preventivo (Bent Flyvbjerg, 2006)
Tabella 1 – Inaccuratezza delle stime di costo per opere di ferrovie, i ponti, le gallerie e le strade (Bent Flyvbjerg, 2006)
Sono state tracciate le più fantasiose teorie sulle origini di questa inaccuratezza ma, in realtà, lo scostamento è inevitabile ogni qual volta il progetto è immerso in un contesto popolato da stakeholder e fattori che non possono essere disabilitati. Le attività del Team di Commessa possono essere pianificate: quelle dei fattori e degli stakeholder, invece, no.
I limiti di tempo, costi e risorse entro i quali bisogna raggiungere un obiettivo, generano la necessità di garantire una ragionevole affidabilità, e quindi predicibilità, della sequenza di attività che compone il progetto stesso.
Questa esigenza di affidabilità è frustrata dal fatto che le opere non possono essere realizzate in un’area asettica e protetta dagli influssi esterni.
A differenza di quanto vorremmo che accadesse (e cioè che un processo di progetto sia sviluppato a valle di un chiaro input del Cliente, e si ottenga un output preciso e prevedibile), nel mondo reale il Cliente fornisce un Input, il Team di Commessa implementa il processo, il contesto genera tutta una serie di input addizionali, tutti questi input influenzano il processo ed il suo output.
Figura 1 – Impatto di Fattori e Stakeholder sul processo produttivo
Cosa sono questi input? Si tratta di eventi, fuori dal nostro campo visivo o dal nostro controllo, che impattano sulla nostra produzione.
Gli eventi di cui parliamo hanno cause efficienti chiamate “fattori”[2] che sono di due tipi:
- – gli stakeholder, persone o organizzazioni che portano avanti una loro agenda ed agiscono con coscienza e volontà;
- – gli altri fattori ambientali, economici, culturali, tecnologici, legali che sono “stati di cose” che impattano sulla nostra produzione.
Quindi, il contesto in cui si realizza un progetto è un “sistema” e cioè un tutto organico in evoluzione composto da elementi (fattori e stakeholder) che interagiscono tra di loro. Con questa prospettiva, anche il Team di Commessa ed il progetto nel suo insieme sono elementi del contesto.
I risultati finali di un’attività di progetto sono generati dalla combinazione di tre addendi:
- il pianificato,
- gli imprevisti accaduti e noti,
- l’impatto di eventi possibili, non pianificati e non accaduti, oppure accaduti ma non rilevati, non conosciuti o non compresi sufficientemente da definirne precisamente l’impatto sugli obiettivi (che però è possibile).
I primi due addendi sono normalmente noti mentre, per quanto riguarda il terzo addendo (e cioè l’impatto dei rischi) è necessario al fornire al Project Manager informazioni utili alla gestione dei rischi (o Risk Management) che è una componente fondamentale della gestione del processo produttivo a lui affidato.
Italferr ha effettuato uno studio del legame tra fattori ed eventi che permette di fondare le previsioni del futuro su qualcosa di presente e non su semplici ipotesi e congetture.
La chiave che ha permesso di passare dalla descrizione di questi fattori ad una rigorosa identificazione di un set di scenari è stato il concetto di vulnerabilità[3]. Si è visto che i Team di Commessa fanno ogni sforzo possibile per “corazzare” il processo e renderlo impermeabile ad influssi esterni. Inevitabilmente, qualunque difesa ha alcuni punti deboli che, però, possono essere sfruttati solo in un determinato modo e solo da determinati fattori e stakeholder.
È stato così possibile mettere a punto uno strumento, metodologico ed informatico, che associa le tipologie di progetto, i fattori di rischio e le vulnerabilità, e genera registri dei rischi (risk register) ragionevolmente affidabili che consentono la tracciatura e il controllo strutturati dei rischi, ad esempio di un progetto o più in generale di un portafoglio di progetti.
Figura 3 – Esempio di Registro dei Rischi
In altre parole, sono stati industrializzati processi precedentemente affidati al genio dei singoli analisti e sono stati messi a punto strumenti efficaci per comparare i diversi progetti.
Quindi, scelto un obiettivo di un progetto, il Risk Management permette di rispondere a tre fondamentali domande.
- Posso affermare con ragionevole certezza che raggiungerò l’obiettivo fissato?
- Quali sono i fattori e gli stakeholder che maggiormente contribuiscono al rischio di fallire?
- Quali vulnerabilità del mio apparato produttivo possono essere utilizzate da ognuno dei fattori o stakeholder elencati più sopra?
Figura 4 – Esempio di profilo di rischio
La risposta a queste tre domande si trova in un profilo di rischio – di cui in Figura 4 è riportato un esempio – e cioè un grafico che, tra le altre cose, permette di capire qual è il migliore risultato credibile, qual è il peggiore risultato credibile, qual è la probabilità che si raggiunga o si superi una soglia di risultato massima o minima (per esempio che si vada in penale o, al contrario, che si vada in utile).
Questo è il “rischio che conta”: l’esistenza di un’alta probabilità che l’intero progetto vada in ritardo, o costi di più, o raggiunga un livello qualitativo/funzionale insufficiente, è una questione (issue) abbastanza importante, da cambiare la pianificazione e mobilitare risorse per la mitigazione del rischio stesso.
Note:
[1] Articolo intitolato “From Nobel Prize to Project Management: Getting Risks Right” di Bent Flyvbjerg, della Aalborg University (Danimarca) pubblicato sul Project Management Journal dell’Agosto 2006;
[2] Questi fattori sono la chiave delle analisi di contesto e rischio in quanto, mentre gli eventi sono futuri, potenziali e non ancora accaduti, questi fattori sono esistenti e presenti nel contesto nel momento dell’analisi e possono essere studiati, rilevati e misurati.
[3] Il concetto di Vulnerabilità è stato preso dalla definizione presente nel capitolo 4 del libro intitolato “La nuova scienza del Rischio” di Federica Spampinato che divulga alcuni concetti elaborati dalla scuola di pensiero di KELONY®. In particolare, nel paragrafo intitolato “La grammatica del rischio” si legge che “La Vulnerabilità è una caratteristica intrinseca di un oggetto che moltiplica la minaccia sull’oggetto. Esiste a prescindere dal rischio”. Inoltre si legge che “L’impatto è il risultato ottenuto da una minaccia che ha incontrato una vulnerabilità in un punto.”
