Come è fatto un rischio

È fondamentale comprendere la definizione di Rischio Individuale di Progetto fornita dal PMI, che sottolinea come esso sia un evento incerto o una condizione incerta che, se si verifica, può avere un impatto positivo o negativo su uno o più obiettivi del progetto.

Per identificare efficacemente i rischi a cui un progetto è esposto, è importante comprendere la struttura di un rischio, che consiste in:

  • una causa che può essere definita come qualcosa che è già successo e che crea le condizioni per l’accadimento di un rischio;
  • un evento incidente che si manifesta a valle dell’avvenimento di un insieme di altri eventi imprevisti. Questo è capace di neutralizzare i sistemi di controllo e pregiudicare la pianificazione.
  • una dinamica di impatto ovvero un insieme di eventi che vanno dalla perdita di controllo all’impatto sugli obiettivi.

Infine, la conseguenza è la deviazione nel grado di raggiungimento degli obiettivi.

È importante essere in grado di identificare queste componenti dei rischi e valutare l’impatto potenziale sugli obiettivi del progetto, in modo da poter implementare le opportune misure di gestione del rischio.

CAUSA (definizione PMBoK) DATO CHE è successo qualcosa.Dato che la pianificazione è molto stretta…
EVENTO INCIDENTE (definizione dell’autore)
POTREBBE succedere qualcosa d’altro.
… potrebbe accadere un ritardo nella consegna delle aree…
DINAMICA DI IMPATTO (definizione dell’autore)
CHE INNESCA eventi che portano da un impatto sugli obiettivi.
… che potrebbe non essere possibile riassorbire nella successiva pianificazione…
CONSEGUENZA  (definizione PMBoK)
Deviazione nel grado di raggiungimento degli obiettivi.
… portando ad un ritardo di alcuni mesi nella consegna.

È opportuno avere un modo preciso e coerente per descrivere i rischi, in modo da poterli identificare e valutare efficacemente. Un buon metodo per descrivere i rischi è quello di utilizzare un metalinguaggio, ovvero un insieme di termini e concetti comuni per descrivere i rischi.

In questo caso, il metalinguaggio utilizzato descrive i rischi come composti dalla:

  • “causa”, la cui descrizione è preceduta dalle parole “DATO CHE”,
  • dall’”evento incidente”, la cui descrizione è preceduta dalle parole “POTREBBE SUCCEDERE CHE”,
  • dalla “dinamica di impatto”, la cui descrizione è preceduta dalle parole “CHE CAUSA”
  • e, infine, da un “impatto su un obiettivo”, descritto subito dopo la dinamica di impatto.

Questa struttura, oltre a permettere di descrivere in modo preciso e coerente i rischi, facilita l’identificazione di quelli ripetuti o parzialmente sovrapposti.

Selezione di obiettivi e KPI

È importante scegliere gli obiettivi del progetto, evitando quelli sui quali le analisi sarebbero inefficaci, inopportuni e inutili.

Ogni analisi di rischio si deve concentrare sull’incertezza che importa[1]. Ciò significa che, mentre alcuni obiettivi possono essere considerati relativamente poco incerti e quindi sicuramente raggiungibili, altri obiettivi potrebbero essere incerti ma avere un impatto limitato sugli obiettivi aziendali dei principali stakeholder. Inoltre, ci sono obiettivi che sono talmente vaghi da non permettere una quantificazione precisa. Pertanto, è importante dedicare le risorse disponibili per analizzare l’impatto dell’incertezza sugli obiettivi più critici.

Per le analisi di Project Risk Management, è quasi sempre opportuno utilizzare solo obiettivi quantificabili per mezzo di opportuni Key Performance Indicator (KPI) in quanto le analisi che riguardano obiettivi non quantificabili finiscono sempre per confermare le opinioni del committente o dell’analista, e non forniscono informazioni utili per la gestione del rischio.

La scelta degli opportuni Key Performance Indicator (KPI) è un’attività cruciale per la gestione del rischio: è necessario che gli analisti del rischio più esperti siano incaricati di scegliere i KPI adeguati, poiché essi devono descrivere correttamente il comportamento di un processo soggetto ad incertezza, ma allo stesso tempo devono essere intuitivi e semplici. Gli scostamenti dovuti all’incertezza dovranno, infatti, essere previsti e stimati attraverso un processo analogico che non permette calcoli complessi.

Obiettivi comunemente utilizzati per le analisi di rischio possono essere:

  • Tempi di consegna di un progetto appaltabile (KPI: Data di consegna)
  • Costi previsti a progetto (KPI: milioni di euro)
  • Tempi di costruzione previsti a progetto (KPI: Mesi)
  • Redditività dei servizi di progettazione (KPI: migliaia di euro)
  • Costi a vita intera dell’opera (KPI: milioni di euro)
  • Tempi di costruzione dell’opera (KPI: Data di consegna)
  • Redditività dei servizi di costruzione (KPI: migliaia di euro)

Tuttavia, è importante sottolineare che questi possono variare a seconda del progetto e dei suoi obiettivi specifici.

Metodologia di identificazione

Verrà, nel seguito, proposta una metodologia di identificazione delle minacce ed opportunità che viene utilizzata per individuare i rischi legati a un progetto che si basa su una combinazione di interlocuzione con il Project Manager (PM), e con pochi collaboratori da lui chiamati, e sull’utilizzo di un database di rischi già identificati in precedenza.

Questa metodologia di identificazione delle minacce ed opportunità prevede la creazione di due liste di rischi: una derivante da una identificazione preliminare e l’altra derivante da una identificazione automatizzata.

La prima lista, quella derivante dall’identificazione preliminare, viene creata chiedendo al Project Manager (PM) di elencare i rischi che ritiene esistenti per la sua commessa. Questi vengono inviati via email e descritti “così come vengono in mente al PM”. Questa lista serve sia a garantire che l’identificazione automatizzata non ignori alcuni rischi specifici del progetto che ad arricchire il database utilizzato nell’ambito della identificazione automatizzata.

La seconda lista, quella derivante dall’identificazione automatizzata, si basa su un database che contiene tutti i rischi identificati in precedenza. Il contenuto del database viene filtrato escludendo i rischi che richiedono obiettivi, attività, stakeholder, fattori e vulnerabilità non presenti nel progetto.

Successivamente le due liste vengono elaborate ed unite da un analista qualificato che effettua un check di copertura, sovrapposizione e completezza per garantire che la lista finale sia precisa e completa.

Questi check portano ad una nuova lista in cui alcuni rischi sono generalizzati ed accorpati. In genere, questa lista contiene tra i 20 ed i 50 rischi per obiettivo. Errori in questo check inficiano completamente i risultati di una futura analisi quantitativa.

Infine, la lista di rischi elaborata viene sottoposta al PM per l’eliminazione dei rischi ritenuti non rilevanti, la modifica e contestualizzazione delle descrizioni dei rischi rimanenti e l’assessment di probabilità ed impatto.

Il problema dell’assessment

L’Assessment dei rischi rappresenta una sfida a causa dell’assenza di metodi precisi per prevedere eventi futuri. I progetti sono processi unici, non può esistere una esperienza, e quindi alcuna statistica, dei loro possibili esiti, e quindi spesso mancano le informazioni necessarie per valutare la probabilità e l’impatto di un evento non ancora accaduto. Pertanto, l’Assessment deve basarsi su valutazioni effettuate da esperti del settore e deve essere condotto in modo da evitare di chiedere ai Project Manager di compiere valutazioni che risultano essere troppo complesse o impossibili da effettuare.

Per ovviare questo problema, è possibile ricorrere ad una valutazione dell’impatto dei rischi basata su scale logaritmiche. Infatti, nonostante non sia normalmente possibile prevedere con precisione l’impatto di un evento descritto, è quasi sempre possibile stimarne l’ordine di grandezza attraverso una scala logaritmica  a base , che ha dimostrato di fornire risultati soddisfacenti. La scala può essere utilizzata per inquadrare l’impatto in classi di gravità, come “uno”, “alcuni”, “circa 10”, “alcune decine”, “circa 100”, “alcune centinaia”,  “circa 1000”, “alcune migliaia” e così via.

Per stimare la probabilità di un evento, è importante evitare di affannarsi nella ricerca di statistiche che potrebbero non essere disponibili. Invece, si può utilizzare il concetto di probabilità soggettiva.

La probabilità soggettiva, secondo la teoria di De Finetti[2], è una concezione di probabilità basata sull’idea che la probabilità di un evento sia legata alle credenze o alle aspettative personali di un individuo o di un gruppo di individui. In altre parole, la probabilità soggettiva è una rappresentazione del grado di certezza o incertezza che un individuo o un gruppo di individui attribuiscono ad un evento futuro.[3]

La probabilità può essere stimata, anche in assenza di statistiche, ponendosi alcune domande quali “Mi aspetto che questo evento accada?”, “Se questo evento si verifica, considero il mio progetto/processo anormale?”, “L’evento implica l’accadimento contemporaneo di più di due circostanze improbabili?”. In base alle risposte a queste domande, si può classificare la probabilità di un evento definendolo “probabile”, “possibile”, “improbabile” o “molto improbabile”.

Ad ognuna di queste valutazioni è possibile quindi associare una adeguata percentuale.

Riquadro 1 – Logiche da utilizzare per la valutazione della probabilità

Ponderazione dei rischi

Quando si dispone della probabilità e dell’impatto di un evento è possibile posizionarlo all’interno di una matrice di rischio e cioè in una tabella in cui alle colonne vengono associate le probabilità di verificarsi di un determinato evento, alle righe vengono associati gli effetti o gli impatti che tale evento potrebbe avere e nelle caselle interne vengono riportati i livelli di rischio associati ad ogni combinazione di probabilità e impatto.

La probabilità e l’impatto individuano una posizione del rischio nella matrice, a cui corrisponde un livello del rischio preventivamente definito come Alto, Medio, Basso.

In questo modo, i rischi sono prioritizzati su più livelli, dal più alto al più basso, per permettere una gestione efficiente delle risorse. La tollerabilità[4] del rischio è definita stabilendo il livello “Grave” dell’impatto, che corrisponde a un rischio intollerabile quando accade nel 50% dei casi. Per ragioni di economicità, si propone di trattare prima i rischi di livello più elevato e poi quelli di livello inferiore.

Risk Register e proposta di un trattamento

Dopo che tutti i rischi identificati sono stati ponderati e prioritizzati per mezzo della matrice di rischio diviene possibile per i risk manager la proposta di un «Trattamento»: ha quindi inizio “La fase attiva del Project Risk management”.

Nella fattispecie, viene emesso un Risk Register che contiene i rischi individuati e la loro valutazione preliminare in termini di livello di rischio associato.

Figura 3 – Esempio di Registro dei Rischi

Si tratta di un documento o una tabella utilizzata nella gestione dei rischi per raccogliere le informazioni emerse nelle fasi di identificazione, valutazione e monitoraggio dei rischi a cui un’organizzazione è esposta. Il Risk Register solitamente include informazioni come la descrizione del rischio, la fonte del rischio, l’impatto potenziale, la probabilità di verificarsi e le azioni di mitigazione o di trattamento del rischio.

Il Risk Register è uno strumento importante nel processo di risk management poiché consente di tenere traccia dei rischi esistenti e di monitorare i cambiamenti nel tempo. Inoltre, può essere utilizzato per comunicare i rischi ai vari livelli dell’organizzazione e per stabilire priorità nella gestione dei rischi.

In generale, un Risk Register è un documento dinamico poiché i rischi possono cambiare nel tempo e le azioni di trattamento del rischio possono essere adattate di conseguenza. Un esperto di Risk Management dovrebbe essere incaricato di mantenere e aggiornare regolarmente il Risk Register.

Il Risk Register viene normalmente inviato al Project Manager per preventiva condivisione aspettandosi che egli, sulla base dei risultati dell’analisi, decida quali rischi debbano essere mitigati (generalmente i rischi a impatto maggiore) e quali debbano monitorati (generalmente i rischi ad impatto minore) sulla base di considerazioni di carattere economico, di opportunità e di propensione al rischio.

Difficoltà nella creazione di valore aggiunto

L’esperienza ha però mostrato un problema: è raro che il processo crei valore aggiunto. L’identificazione dei rischi normalmente segue le idee del PM, così come l’assessment. Inoltre, le azioni di mitigazione sono scelte tra quelle già approvate e finanziate dal PM.

È importante considerare che i rischi sono eventi che potrebbero accadere in futuro e non necessariamente si verificheranno. Di conseguenza, essi hanno sempre una priorità inferiore rispetto ai problemi già esistenti e concretizzati. Inoltre, il livello di rischio massimo per singolo evento non può essere imposto dall’alto, ma dipende dal progetto e deve essere flessibile e deciso dal PM. In definitiva, in un mondo pieno di problemi aperti, un singolo rischio non ha un’importanza tale da giustificare un cambio di programma o un significativo dirottamento delle risorse.

Inoltre, la rappresentazione dell’impatto dell’incertezza sugli obiettivi di un progetto come se fosse la somma degli impatti di molteplici eventi indipendenti e disaccoppiati esaspera la gravità di alcuni problemi teorici ed alcune difficoltà che caratterizzano l’analisi dei rischi, come l’inevitabile incompletezza della identificazione e l’inaffidabilità degli assessment.

I rischi sono infiniti, come la fantasia di coloro che li identificano e dipendono da molte cose (dal contesto, dal progetto, dal cliente, dal Project Manager, dal numero dei rischi e dall’ottimismo o pessimismo di chi effettua l’assessment).

L’assessment è una previsione del futuro, ma gli uomini non possono predire il futuro.

Inoltre, l’impatto e la probabilità dei rischi dipendono dall’accadimento degli altri rischi e i rischi non si sommano, ma si combinano con correlazioni non sempre dirette e mai lineari.

Questi problemi fanno sì che la semplice valutazione dei singoli rischi sia quasi sempre insufficiente alla definizione di efficaci ed efficienti strategie di Risk Management.

Conclusioni

È evidente che la comprensione approfondita dei rischi individuali di progetto e la loro analisi qualitativa giocano un ruolo cruciale nella gestione efficace dei progetti. L’approccio sistematico proposto, che include la definizione precisa di cause, eventi incidenti, dinamiche di impatto e conseguenze, fornisce una struttura chiara per l’identificazione e la valutazione dei rischi.

La metodologia di identificazione dei rischi, che combina l’interlocuzione con il Project Manager e l’utilizzo di un database di rischi preesistenti, si dimostra essere uno strumento potente per rilevare sia rischi specifici del progetto sia quelli più generali. Questo processo, unito all’uso di scale logaritmiche e alla nozione di probabilità soggettiva, offre un metodo pragmatico per l’assessment dei rischi, superando le sfide dell’incertezza e della mancanza di dati storici.

È chiaro che i rischi non possono essere trattati in isolamento; piuttosto, devono essere considerati nel contesto dell’intero progetto e delle sue dinamiche complesse. L’analisi dei rischi deve quindi essere integrata in una strategia di gestione del progetto più ampia che tenga conto delle interdipendenze e delle correlazioni tra vari rischi. Solo questo approccio globale e olistico permette di sviluppare strategie di mitigazione e monitoraggio più efficaci, massimizzando così le opportunità di successo del progetto.

In conclusione, l’articolo sottolinea l’importanza di una gestione del rischio ben informata e strategica, che sia in grado di adattarsi alle sfide uniche di ogni progetto. L’adozione di queste pratiche avanzate di analisi del rischio non solo migliora la gestione dei progetti, ma contribuisce anche alla crescita e al successo complessivi dell’organizzazione.


[1] Come detto sopra, nell’articolo intitolato “When is a Risk not a Risk” del Dr. David Hillson, viene chiarita la differenza tra rischio ed incertezza specificando che «il rischio è l’incertezza che conta (“uncertainty that matters”)».

[2] De Finetti ha scritto molti articoli e libri sulla probabilità soggettiva, tra cui “Sul significato soggettivo della Probabilità” del 4 giugno 1939. Tutti questi testi forniscono una descrizione dettagliata della teoria della probabilità soggettiva di De Finetti e del suo contributo al campo del ragionamento probabilistico.

[3] Questa concezione di probabilità si differenzia dalla probabilità oggettiva, che si basa sull’idea che la probabilità di un evento sia legata alle proprietà intrinseche dell’evento stesso.

[4] Se non di effettua alcuna valutazione del rischio globale, è normale considerare intollerabile qualunque rischio alto.
Si badi bene però che, al contrario, se ci si basa una valutazione del rischio globale, la tollerabilità non dipende più dal singolo rischio ma bensì dal loro impatto combinato.

Condividi:

  • GUIDO MASTROBUONO

    Laurea in ingegneria Civile nel 1996. Nel 1997 presta servizio come Vigile del Fuoco, Volontario Ausiliario. Nel 1998 entra in D’Appolonia S.p.A.. Da maggio 2000 a novembre 2003, opera a Copenhagen come “Civil Works Expert” ed “Central Hazard Log Manager” nel Chief Safety Manager Team della metropolitana di Copenaghen (Danimarca). Da aprile 2004 entra in ITALFERR S.p.A. e matura diverse esperienze. Dapprima opera nell’Unità Organizzativa Safety & Security e poi come focal point per l’adattamento dell’Analisi del Valore alla realtà ferroviaria. Successivamente gli viene affidata la responsabilità della struttura che si occupa di innovazione nei prodotti e nelle metodologie di lavoro ed in un secondo tempo la responsabilità dell’attività di Value Engineering. Dopo queste esperienze riceve l’incarico di formare un settore dedicato al Risk Management divenendo di fatto il focal point della Direzione Tecnica di ITALFERR per l’analisi di rischio aziendale (ERM). Da aprile 2018 è il Risk Officer di Italferr.

  • ALESSANDRO PIETRO SAULLO

    Laurea magistrale in ingegneria Gestionale nel 2008. Nel 2008 entra in Capgemini. Dal 2009 al 2012, entra nella struttura di Standard Metodologie e Value Engineering di Italferr S.p.A.. Dopo un’attività di ricerca con l’Università di Roma La Sapienza, dal 2014 al 2015 partecipa per ANAS International Enterprise S.p.A. al progetto di realizzazione in Libia dell'Autostrada Ras Ejdyer-Emssad, in veste di IT manager. Dal 2016 al 2017 assume l’incarico di Quality Manager per la Carlo De Giorgi S.r.l. Da aprile 2017 rientra in ITALFERR S.p.A., dapprima nella struttura di Controllo Computi, e dal 2019 nel Risk Office. Dal 2019 è il Lead Risk Analyst di Italferr.