Project Risk Management

Transcript

Project Risk Management
IL PROJECT RISK MANAGEMENT
Il Project Risk Management
Introduzione
Gestire il rischio di un progetto significa occuparsi attivamente del suo
successo. Un progetto è per sua natura uno sforzo complesso, temporaneo,
innovativo, interdisciplinare, inusuale e talvolta unico. Per questi motivi esso
è esposto a rischi in misura molto maggiore di quella relativa alle attività
correnti e ripetitive di un’organizzazione [17]. Da una recente ricerca
effettuata su un campione di oltre 3000 progetti (con svariati scope of work)
sviluppati presso 500 aziende statunitensi di medio-grandi dimensioni e
appartenenti a comparti merceologici diversificati, è risultato che soltanto un
progetto su quattro si è concluso con successo, mentre poco meno di un terzo
viene cancellato prima della sua conclusione. I progetti rimanenti (che
costituiscono, quindi, quasi il 50% del totale), presentano tutti, in corso
d’opera, problemi di varia natura, una parte non irrilevante dei quali si può
far risalire ad eventi rischiosi imprevisti (ma non per questo, tutti
imprevedibili) o comunque non correttamente gestiti. Le criticità riguardano
l’allungamento dei tempi di consegna, l’aumento dei costi di realizzazione e
la presenza di difetti nel prodotto finito [1].
Per gestire il rischio bisogna innanzitutto essere in grado di comprendere e
prevedere gli eventi rischiosi e le loro interazioni che, manifestandosi,
possono
ostacolare
il
raggiungimento
degli
obiettivi
progettuali.
Successivamente occorre progettare e mettere in azione un piano di sicurezza
che permetta di intervenire nel modo più appropriato con attività di
prevenzione, sorveglianza e contrasto sui singoli elementi di rischio. Infine
bisogna valutare sia a priori che sul campo l’efficacia del piano di azione
adottato per poter operare le opportune modifiche al sistema di gestione del
rischio. Tutto questo costa tempo, impegno e denaro ma è l’unica strada
percorribile se si vuole minimizzare le perdite attese per ogni specifico sforzo
1
IL PROJECT RISK MANAGEMENT
progettuale. Reagire agli eventi inaspettati mano a mano che questi accadono,
infatti, è indubbiamente un modo di procedere che permette risparmi
immediati ma che purtroppo sono solo apparenti. L’esperienza insegna che la
gestione delle emergenze, infatti, comporta sempre un dispendio di energie
maggiore della gestione delle attività ordinarie. Occorre, quindi, adottare
approcci di lavoro metodici che siano flessibili ed adeguati a trattare ogni
tipologia di progetto perché è pur sempre vero che non si deve spendere in
gestione del rischio più di quanto si può perdere non gestendolo. L’approccio
ideale è, dunque, quello che si adatta alla rilevanza del progetto stesso:
piccoli progetti, dunque, piccolo impegno di gestione; grandi progetti, grande
impegno di gestione [17].
La figura 1 mostra schematicamente come la funzione di Project Risk
Management sia inestricabilmente intrecciata con le rimanenti funzioni che
fanno capo al Project Management [70].
PROJECT
MANAGEMENT
INTEGRATION
SCOPO
Prospettiv
e
F ttibilità
QUALITA’
Scambio
preciso di
idee, ordini,
PROJECT
RISK
Requisiti
Standards
Tempo, obiettivi,
vincoli
TEMPI
Ciclo di vita e
condizioni
ambientali
Costi, obiettivi,
vincoli
INFORMATION/
COMMUNICATION
S
Disponibilità
Produttività
HUMAN
RESOURCE
Servizi,
impianti,
materiali:
CONTRACT/
PROCUREMENT
COSTI
Figura 1: Integrazione del Project Risk Management con le altre funzioni del
Project Management [70]
La capacità delle organizzazioni di tenere sotto controllo gli impatti di
qualsiasi natura derivanti dai loro processi e di migliorare le proprie
prestazioni, anche attraverso una gestione consapevole dei rischi, viene
2
IL PROJECT RISK MANAGEMENT
ribadita in uno degli otto “Principi di gestione per la qualità” riportati nella
UNI EN ISO 9000:2000. La gestione di un’organizzazione richiede di
coordinare tutti i vari aspetti delle attività aziendali in un sistema che
consenta di governare e tenere sotto controllo i propri processi ed i rischi
connessi. Le norme internazionali sinora disponibili affrontano singolarmente
i diversi aspetti delle attività fornendo requisiti legati a qualità, ambiente,
salute e sicurezza sul luogo di lavoro, responsabilità sociale. I rischi legati
all’attività di un’organizzazione sono numerosi e riguardano tutti i processi
aziendali: dai rischi finanziari a quelli legati al prodotto, alla capacità
produttiva, alla sicurezza e salute dei lavoratori, dei clienti e della collettività,
rischi ambientali, ecc.. Si comincia ad avere esperienza, in diversi settori, di
“Sistemi di Gestione Integrata” per qualità, ambiente, sicurezza e, in alcuni
casi, responsabilità sociale.
Il Risk Management è un processo che fa parte del sistema di gestione
generale e interagisce con gli altri processi per contribuire a raggiungere, con
la massima efficacia ed efficienza, gli obiettivi dell’organizzazione e
soddisfare le aspettative di tutte le parti interessate.
Si potrebbero riportare innumerevoli esempi per mettere in evidenza come i
vari aspetti dell’attività di un’organizzazione si influenzano reciprocamente
nel bene e nel male. Una “Gestione Integrata dei Rischi” (integrata tra i vari
aspetti ed impatti conseguenti ed integrata con tutti i processi potenzialmente
interessati) consentirebbe di migliorare le prestazioni dell’organizzazione a
favore di tutte le parti interessate. Il termine “parte interessata” (UNI EN
ISO 9000:2000) risulta essere la traduzione del termine inglese
“stakeholder”. Tale termine include oltre a clienti, proprietà, dipendenti e
collaboratori, fornitori, investitori, banche, assicurazioni, collettività (inclusa
la pubblica amministrazione), anche l’ambiente (come insieme di individui e
non solo) e le future generazioni. Tutte entità coinvolte ed interessate, che
“possono influenzare una o più prestazioni di un’organizzazione, o esserne
influenzate o percepire se stessi come influenzati dalle stesse”.
3
IL PROJECT RISK MANAGEMENT
La UNI EN ISO 9001:2000 promuove la gestione per processi. Questo
approccio si contrappone al modo tradizionale di gestire le aziende “per
funzioni”, che risponde alle esigenze di far crescere le competenze specifiche
e la specializzazione e garantire un buon controllo gerarchico e
amministrativo delle risorse umane e materiali. I processi, però, percorrono
l’organizzazione orizzontalmente e la divisione dell’azienda in funzioni fa sì
che il processo interfunzionale venga suddiviso nelle sue componenti
funzionali, perdendo la sua integrità globale. Il livello di responsabilità è
spesso troppo distante per essere efficace e le persone tendono a sostituire gli
obiettivi di settore agli obiettivi globali di processo, che coincidono con gli
obiettivi aziendali di soddisfazione del cliente e delle altre parti interessate.
Nel passaggio da una funzione all’altra, in sequenza, la qualità tende a
scendere , i costi e i tempi ad aumentare, le responsabilità a perdere efficacia.
L’approccio per processi, invece, consente di bilanciare il potere funzionale
ed allineare gli obiettivi di tutti alle aspettative del cliente e delle altre parti
interessate. Un sistema di gestione integrata è in linea con l’approccio per
processi [5].
A titolo puramente semplificativo, un progetto può essere scomposto in
quattro fasi, ovvero concezione, sviluppo, esecuzione e chiusura. Le prime
due generiche fasi costituiscono la pianificazione di progetto, mentre le
ultime due costituiscono la realizzazione di progetto. L’opportunità e il
rischio generalmente rimangono relativamente alte durante la pianificazione
di progetto ma, poiché in questo periodo il livello di investimenti è
relativamente basso, il valore in gioco rimane basso. Invece, durante la fase
di realizzazione l’opportunità e il rischio progressivamente raggiungono
valori minimi perché i fattori incerti man mano diventano certi. Allo stesso
tempo, il valore in gioco cresce costantemente perché aumentano le risorse
investite per completare il progetto. Questi andamenti sono mostrati nella
figura 2. La figura mostra anche che il periodo di maggiore sensibilità per i
rischi è durante le ultime due fasi. Allo stesso tempo, condizioni avverse
4
IL PROJECT RISK MANAGEMENT
possono anche essere scoperte dal risultato di test d’accettazione o start-up
del progetto. Lo scopo del Risk Management è influenzare la pianificazione
di progetto in modo tale che sia l’incertezza-rischio che l’ammontare in gioco
siano ridotti a livelli accettabili durante il ciclo di vita del progetto [70].
Ciclo di Vita Totale del Progetto
I
N
C
R
E
M
E
N
T
O
R
I
S
C
H
I
O
Pianificazione
Fase 1
Concezione
Fase 2
Sviluppo
Realizzazione
Fase 3
Esecuzione
Fase 4
Conclusione
Opportunità e Rischio
Periodo in cui si
incorrono i
maggiori rischi
Valore in gioco
$
Periodo di
maggiore impatto
dei rischi
V
A
L
U
E
TEMPO
Figura2:Tipico andamento del ciclo di vita, Rischio vs Valore in gioco [70]
In Italia la gestione del rischio, sistematica e strutturata, è un processo
sviluppato ancora in poche organizzazioni; in alcuni casi si limita alla
gestione degli aspetti assicurativi legati al rischio e, a volte in modo
scollegato, alla gestione dei rischi finanziari legati alla solvibilità dei clienti
e/o ai cambi. Probabilmente si fa poco per la prevenzione dei rischi, o
comunque si fa in modo non coordinato e, in molti casi, solo per adempiere
un obbligo di legge, ma non come scelta strategica.
Non si tratta di aggiungere ulteriori requisiti a quelli delle norme per la
certificazione dei Sistemi di Gestione, ma di applicare una metodologia
diversa per tenere sotto controllo rischi significativi che l’organizzazione può
correre, legati ai diversi aspetti della propria attività. Se poi si sposa la
filosofia espressa dalla AS/NZS 4360:2004, che definisce il “Risk
Management” come “la cultura, i processi e le strutture che sono indirizzate
a concretizzare le opportunità potenziali mentre gestiscono gli effetti
negativi”, vorrà dire che ci si sarà convinti che le metodologie legate a questa
5
IL PROJECT RISK MANAGEMENT
disciplina potrebbero aiutare le organizzazioni a essere sempre più
competitive. Forse il vantaggio più importante e più evidente che si può
ottenere da un approccio di questo tipo è che consente di mettere in atto un’
effettiva “gestione consapevole” dell’organizzazione in accordo con il
principio delle “decisioni basate su dati di fatto”. Si sarà cioè in grado di
avere un quadro sempre più preciso dei rischi che corre l’ attività, iterando il
ciclo del processo di gestione del rischio e raccogliendo dati e informazioni
utili a stabilire nuovi traguardi ed obiettivi. Non è affatto vero, ad esempio,
che il riprogettare un processo per ridurre un rischio o per ottemperare ad un
nuovo requisito cogente, si debba sempre tradurre in maggiori costi. Nella
maggior parte dei casi ci si potrà accorgere che, direttamente o
indirettamente, si potranno ottenere dei risparmi o aumentare il valore
percepito dai clienti, quindi i profitti o le quote di mercato [5].
Definizione e tipologia di rischi di progetto
Il successo di un progetto è rappresentato dal raggiungimento degli obiettivi
posti. Un obiettivo è un’idea spesso assunta come primitiva e mai analizzata
in modo più attento ed approfondito. Un obiettivo può essere definito come
“uno stato delle cose gradito ed atteso”. Stato delle cose nel senso di
configurazione di una serie di variabili di ogni genere come quelle
economiche, organizzative, produttive, sociali, legislative; gradito perché se
non fosse tale non si metterebbe in piedi un apparato costoso ed impegnativo
per realizzarlo ed infine atteso perché non solo piace ma ci si vuole arrivare
davvero e dunque si opera al fine di perseguirlo. Obiettivo è ciò a cui si vuole
giungere in un modo o nell’altro; esso è esprimibile in termini di risultato e
generalmente (non sempre) è ciò che rimane quando il progetto è terminato.
Gli obiettivi dei progetti sono posti da una moltitudine di soggetti, talvolta in
contrasto tra loro. Un obiettivo, allora, è quasi sempre legato ad un range di
accettabilità dei suoi valori che è proprio il frutto dell’attività negoziale. La
6
IL PROJECT RISK MANAGEMENT
zona di successo può essere definita come il solido ad n-dimensioni
caratterizzato da tutti i range di tolleranza esistenti sulle variabili importanti
di progetto (tempo, costo, qualità, risorse, etc.). Il successo di un progetto è
dunque riuscire a far rientrare i risultati consuntivi nel volume appena
definito. Da ciò appare chiaro come il rischio di un progetto può essere
definito come la “non capacità di riuscire a perseguire uno o più degli
obiettivi esplicitati e concordati per esso” [17].
Una possibile definizione di rischio è “un evento potenziale riferito sempre al
futuro, mai al passato o al presente, che, al suo verificarsi, provocherà delle
ricadute, negative o positive, sull’andamento del progetto, rispetto a come è
stato previsto nella pianificazione iniziale”. In realtà, nel linguaggio comune,
il termine “rischio” viene usato quasi esclusivamente per indicare eventi
sfavorevoli mentre l’area degli eventi favorevoli da cogliere viene
comunemente chiamata “opportunità”. D’ora in poi per rischio si intenderà
quindi “un evento o una condizione sfavorevole che potrebbe verificarsi nel
corso del progetto, con possibili conseguenze dirette o indirette sul progetto
stesso”, o più brevemente, “l’eventualità di subire un danno, connessa a
circostanze più o meno prevedibili”.
I rischi sono legati alle scelte che vengono fatte nel progetto e all’incertezza
che ogni scelta comporta, ma, sono anche legati ai cambiamenti che
avvengono nel corso del progetto (requisiti, tecnologie, persone, mercato,
ecc.) che obbligano ad una revisione del piano iniziale.
Alcuni rischi sono generici e sono comuni a qualsiasi progetto, altri sono
specifici e per essere identificati richiedono una buona conoscenza
dell’ambito del progetto. I più frequenti rischi di un progetto sono:
•
L’indeterminatezza, ambiguità, scarsa definizione, genericità, scarsa
condivisione degli obiettivi del progetto;
•
La scarsa misurabilità degli obiettivi del progetto, che comporta
l’impossibilità di riconoscerne il raggiungimento e quindi di valutare il
successo del progetto;
7
IL PROJECT RISK MANAGEMENT
•
L’adeguata allocazione delle risorse: risorse giuste ma mal gestite,
risorse non skillate, risorse insufficienti per incapacità di stima iniziale;
•
Una non corretta definizione dei requisiti: frettolosa, superficiale, con
grossolani errori di interpretazione dei bisogni del cliente.
Essere in grado di rilevare il più presto possibile un cambiamento dei
requisiti e di ricalcolare di conseguenza i costi di progetto stimando le risorse
necessarie consente di ridurre drasticamente i rischi di progetto. Alcuni studi
statistici, prendendo come base i risultati di un gran numero di progetti di
vario tipo, hanno dimostrato che il costo di rework causato da variazioni in
corso d’opera dei requisiti può far lievitare mediamente del 40% i costi del
progetto. Non si dimentichi infatti che ogni rischio è associabile al danno
economico diretto o indiretto, più o meno grande, che il verificarsi di una
combinazione di condizioni incerte comporterebbe [16].
Si osserva, dalle precedenti definizioni, che al concetto di rischio viene
associata una caratteristica di natura strettamente probabilistica: un evento (o
le conseguenze che ne possono derivare) può essere classificato come
“rischioso” solo quando non si hanno certezze circa il suo effettivo futuro
accadimento [44]. In un progetto reale, però, oltre che una valutazione di
quali cose possono andare storte e con quale probabilità, è necessario
differenziare le cose importanti da quelle marginali. Ecco che allora la sola
componente di probabilità per la definizione di rischio non basta più. Occorre
introdurre il concetto di “valore atteso” statistico: in altri termini possiamo
asserire che il rischio ( ρ ) è una quantità proporzionale al valore del danno
(impact) causato da un certo problema moltiplicato la sua probabilità
( likelihood) di accadimento. La combinazione fra le due variabili determina
il peso o esposizione o entità di ciascun rischio (risk exposure) che esprime il
danno che il rischio potrebbe provocare e quindi il livello di priorità (ranking
list) con cui il rischio va gestito. In tale modo è possibile focalizzare le
energie gestionali nel controllo di cose che siano davvero rilevanti per il
progetto e non dei semplici fastidi.
8
IL PROJECT RISK MANAGEMENT
ρ = ( Probabilità dell’evento accidentale)x(Valore del danno)=p*d
In base a tale definizione, inoltre, un evento poco probabile, ma che comporta
un danno grave, viene valutato come rischioso al pari di un evento piuttosto
frequente che comporti un danno di piccola entità [17].
Soltanto in presenza anche del minimo dubbio circa la possibilità
dell’effettivo avverarsi di un qualsiasi evento futuro si potrà, dunque, parlare
di situazione rischiosa, e tentarne, nel contempo, la valutazione della
probabilità del suo accadimento.
La mancanza di certezze che, nella quasi totalità dei casi, accompagna la
valutazione dell’evolvere della realtà che ci circonda discende, molto spesso,
da una reale impossibilità di tenere nel debito conto (e a volte, addirittura,
anche soltanto di riuscire ad elencare) la totalità degli elementi che possono
concorrere all’avverarsi dell’evento considerato. E questo non tanto, o non
soltanto, a causa di analisi affrettate o non sufficientemente approfondite, ma
proprio in quanto il numero di variabili in gioco, la carenza di dati oggettivi,
l’inadeguatezza della loro elaborazione riduce in misura sostanziale il
numero di alternative che possono, nella realtà, venire di fatto considerate.
Tali considerazioni non devono assolutamente scoraggiare o indurre in
atteggiamenti attendesti o, ancora peggio, fatalistici. Il ricorso all’utilizzo di
tecniche appropriate può fornire un adeguato supporto in sede di valutazione
del rischio di progetto [44].
Le cause di rischiosità possono essere classificate sotto il profilo della loro
origine, ovvero possono essere suddivise in interne (endogene) o esterne
(esogene). Per quanto riguarda le cause endogene di rischio possiamo pensare
che esse siano legate essenzialmente al buon funzionamento del gruppo di
progetto (capace, motivato, affiatato etc.) ed alla validità delle soluzioni
tecniche ed organizzative che si decide di adottare così come alla capacità di
gestire in modo efficace ed efficiente le risorse disponibili. Per quanto
riguarda le cause esterne possiamo invece osservare che ogni progetto nasce,
9
IL PROJECT RISK MANAGEMENT
sviluppa la sua esistenza e si conclude in relazione ad un particolare contesto
ambientale. Se si paragona il progetto ad un sistema biologico aperto che
scambia informazioni e risorse con altri sistemi esistenti possiamo affermare
che il successo di tale organismo è fortemente dipendente dalla sua capacità
di relazionarsi positivamente con l’ambiente circostante dal quale
sicuramente tende ad essere condizionato. I committenti di un progetto, i suoi
destinatari, i regolatori esterni, i fornitori, i concorrenti sono esempi di attori
che popolano l’ambiente del progetto mentre gli obiettivi, le risorse
finanziarie, le tecnologie, la logistica sono esempi di elementi su cui avviene
uno scambio tra l’interno del “sistema” ed il suo esterno. Riepilogando,
quindi, rientrano nella seconda categoria tutti i rischi derivanti da fenomeni
naturali e la maggior parte dei rischi di natura finanziaria, politica ed
economica, mentre, in linea del tutto generale, possono essere considerati
interni i rischi commerciali, tecnici ed umani.
I rischi interni sono quelli che in qualche modo ricadono sotto il dominio del
project manager (o comunque del suo team), mentre i secondi sono situati
completamente al di fuori del “territorio” governato dal responsabile della
conduzione del progetto. Di conseguenza, mentre relativamente ai primi
risulta, in generale, ipotizzabile l’attuazione, da parte del project manager, di
azioni di contrasto, i secondi non gli consentono alcuna possibilità di
intervento se non quella, nella migliore delle ipotesi, di ricorrere a specifiche
coperture assicurative [17].
Da quanto detto precedentemente, il rischio potrebbe essere più correttamente
definito minaccia o, alternativamente, opportunità a seconda che le
conseguenze associate al suo verificarsi risultino, nel primo caso,
sicuramente sfavorevoli mentre, nel secondo, potrebbero anche (ma non
sicuramente) rivelarsi vantaggiose. In questo senso si può distinguere tra
rischi puri e rischi speculativi: i primi presentano soltanto l’eventualità di
una perdita, mentre i secondi offrono la possibilità sia di una perdita che di
un utile. Ai primi sarà opportuno contrapporsi in ogni caso, cercando di
10
IL PROJECT RISK MANAGEMENT
rimuovere, ove possibile, le cause che li possono generare, o tentando di
ridurne, quantomeno, la prevedibile portata (badando, in ogni caso, che il
costo generato dall’attuazione delle azioni di contrasto venga bilanciato dal
reale beneficio ottenibile); relativamente ai rischi speculativi, al contrario, si
dovranno individuare tutte le azioni che possano agevolare il concretizzarsi
degli eventi potenzialmente favorevoli [37].
Nel seguito ci si riferirà prevalentemente ai soli eventi rischiosi l’avverarsi
dei quali potrebbero determinare effetti sfavorevoli sull’iter realizzativo
pianificato, con ricadute, quindi, soltanto negative sotto il triplice profilo
economico-qualitativo-temporale.
Si
tratteranno,
pertanto,
più
specificatamente le minacce e le tecniche che ne consentono il presidio più
efficace. Si osserva, innanzitutto, che la dimensione dell’impatto determinato
dal concretizzarsi in corso d’opera degli eventi rischiosi negativi dipende
dalla tipologia del contratto e presenta un andamento opposto a seconda che
venga considerato dal committente o dal contraente. Se si rappresentano
sull’asse delle ascisse le diverse tipologie di contratto (che possono
considerarsi tutte comprese tra i due estremi rappresentati dal contratto “a
tempo e spesa” fino al “Turn-Key”) e in ordinate la consistenza dell’impatto
economico-finanziario (intendendo,lo stesso, crescente nel senso dell’asse), il
profilo del rischio progettuale presenta il duplice trend mostrato in figura 3.
Impatt
Committent
Contraent
Tipo di
contratt
Tempo e spesa
Turn
Figura 3: Profilo del rischio di progetto [44]
E’ opportuno sottolineare il fatto che gli eventi possono provocare non
soltanto danni diretti, immediatamente ascrivibili, cioè, al loro stesso
verificarsi, ma, quasi sempre, anche danni indiretti, la cui portata non può
11
IL PROJECT RISK MANAGEMENT
essere sempre considerata del tutto marginale. A determinare tutta una serie
di potenziali conseguenze negative non sono, d’altra parte, soltanto gli eventi
naturali disastrosi: si consideri, ad esempio, l’impossibilità di impiego di
risorse umane con specifico profilo professionale e il conseguente forzato
ricorso a personale con skill tecnico inadeguato: in questi casi non si
originano soltanto sacche di inefficienza e ritardi nella realizzazione, ma
anche cadute nella qualità della fornitura e, ove il committente rilevasse
l’evento, anche una perdita di “immagine” nei suoi confronti.
Pertanto, l’analisi del rischio deve essere estesa ogni volta a tutto il ventaglio
delle possibili conseguenze che possono prevedibilmente originarsi a fronte
del singolo evento. Va inoltre sottolineato il fatto che non sempre lo stesso
evento può essere classificato come rischio puro o, in alternativa, speculativo.
Infatti esistono eventi rischiosi che, a seconda del soggetto che li considera e
del contesto nel quale vengono collocati, possono rappresentare una minaccia
e, al tempo stesso, un’opportunità [44].
3. Gli approcci al Project Risk Management
Gestire
il
rischio
è
un’attività
che
non
può
essere
lasciata
all’improvvisazione, come si è già scritto. Pertanto è necessario che si
definiscano delle procedure o processi di lavoro standard che siano di aiuto a
quanti sono coinvolti nella impostazione, conduzione e valutazione di un
particolare progetto. Questi processi dovranno facilitare le persone incaricate
di individuare, quantificare, prevenire, sorvegliare e contrastare gli eventi
rischiosi. Può valere la pena di sottolineare come il disporre di un metodo
standard di valutazione ha tra gli altri vantaggi quello di poter permettere la
comunicazione e la condivisione, tra soggetti organizzativi diversi, della
percezione della rischiosità del progetto.
Nella pratica corrente, purtroppo, la valutazione del rischio è un’attività che o
non viene svolta in modo esplicito oppure viene svolta solo all’inizio del
12
IL PROJECT RISK MANAGEMENT
progetto. I rischi, invece, cambiano col passare del tempo nella loro natura,
nella probabilità di manifestazione così come nella entità del danno che
possono procurare ed è, quindi, necessario mantenere sempre vivo l’interesse
per questo aspetto iterando più volte il processo apposito. Pertanto, le attività
di gestione del rischio dovranno avvenire sia in particolari momenti canonici
del Ciclo di Vita del progetto (Studio di Fattibilità, Esame delle Specifiche
Funzionali, Rilasci parziali) sia ogni qual volta lo si ritenga necessario per via
della variazione delle condizioni progettuali o della diversa conoscenza che
di esse si ha nel corso del tempo [17].
Il Project Risk Management è un argomento di grande interesse attuale. Esso
viene affrontato attivamente da molti enti governativi e dalle maggiori
associazioni professionali di project management in tutto il mondo. Molti
standard importanti sono stati creati o sono in fase di sviluppo.
Le due organizzazioni professionali più importanti che pubblicano
orientamenti sul Project Risk Management sono:
Œ
il Project Management Institute (PMI), (US); e
Œ
l’Association for Project Management (APM), (UK).
Esistono quattro approcci molto usati per il Project Risk Management e sono:
Œ
l’Australian and New Zealand AS/NZS 4360 del Standards Association of
Australia;
Œ
il Project Management Body of Knowledge (PMBOK) dell’ US Project
Management Institute;
Œ
il Project Risk Analysis and Management (PRAM) dell’ UK Association
for Project Management;
Œ
il Management of Risk (M_o_R) dell’ UK Office of Government
Commerce.
Ognuno di questi ha molto da offrire ma ci sono differenze significative nei
loro obiettivi, stili e approcci. L’ Australian and New Zealand Standard
4360 (AS/NZS 4360) è stato pubblicato la prima volta nel 1995 e aggiornato
nel 1999 e nel 2004. Questo è uno standard generico del risk management
13
IL PROJECT RISK MANAGEMENT
che è facilmente applicabile al project risk management. Infatti, permette non
solo la gestione dei rischi di progetto ma anche la gestione dei rischi legati
alla sicurezza, salute e finanziari. Lavora bene a tutti i livelli, dalle attività
singole all’intera azienda; in particolare, può essere usato come base di un
programma integrato o di un processo di business risk management che
coinvolge un portfolio di progetti. Lo Standard descrive un approccio globale
di risk management, non solo l’analisi del rischio o la valutazione del rischio.
Esso si occupa dei collegamenti tra il processo di risk management e sia la
direzione strategica e sia le azioni giornaliere. Comunque, poiché è un
approccio generico, lo Standard da solo non dice nulla circa i problemi del
progetto specifico e, quindi, deve essere sviluppato in alcuni dettagli per
operare come un metodo di project risk management. Le principali
caratteristiche dello Standard sono illustrate nella figura 4.
Comunicazioni e Consultazioni
Stabilire
il
contesto
Obiettivi
Stakeholde
rs
Criteri
Definizione
Identificazio
ne dei rischi
Analisi
dei rischi
Cosa può
succedere?
Come può
succedere?
Probabilità
Consegue
nze
Livello del
rischio
Valutazio
ne dei
rischi
Valutare i
rischi
Classificare i
rischi
Trattare i
rischi
Identificare le
opzioni
Selezionare le
migliori
soluzioni
Sviluppare
Monitoraggio e Controllo
Figura 4: L’AS/NZS 4360 risk management process [14]
Una parte del Project Management Body of Knowledge (PMBOK) del
PMI è stata scritta specificatamente per il project risk management. Esso è
strutturato in uno schema di input, processi e output, come visto nel primo
capitolo. Tratta della responsabilità del management per il processo e i
collegamenti al più ampio processo di project management contenuto nel
PMBOK. I dettagli del risk management non sono così chiari come
nell’approccio descritto in AS/NZS 4360. La figura 5 illustra il processo.
14
IL PROJECT RISK MANAGEMENT
Risk
management
pianificazione
Pianificazione
dell’attività di risk
Identificazione
dei rischi
Analisi qualitativa
del rischio
Cosa può
succedere?
Come vedere se si
Scale di probalità e
impatto
Priorità
i
ii
Analisi
quantitativa del
rischio
Quantificazione dei
rischi individuali
Pianificazione di
risposta al rischio
Piani per trattare i
rischi
Rischi residui e
i
Monitoraggio e
controllo del
rischio
Mantenere le
valutazioni e i piani
Figura 5: Il PMBOK project management process [14]
Questa parte del PMBOK vede metodi di analisi del rischio sia qualitativi che
quantitativi ma non li collega direttamente. Questo approccio ben si adatta al
caso di progetti tecnologicamente molto complessi.
La Guida Project Risk Analysis and Management (PRAM) separa
deliberatamente il processo di risk management da tecniche dettagliate o
metodi che potrebbero essere utilizzati per implementare le varie fasi del
processo. E’ scritto in una struttura di project management e tratta del
processo e delle responsabilità per gestire il processo. Fornisce esempi di
tecniche per le singole fasi del processo. La figura 6 illustra le fasi principali
e il flusso di dati nel processo della Guida PRAM.
Definire il
progetto
Focalizzare
PRAM
Scopo e obiettivo
Dove e come
Pianificare
l’implementazione
Identificazione
Cosa potrebbe
succedere?
Cosa può essere fatto
Assessment
Struttura
Proprietà
Stimare
Valutazione
Relazioni tra
rischi e piani
base
Semplificare
Responsabil
ità per i
rischi
Probabili
tà
Impatto
Priorità
Problemi
associati alla
gestione dei
Pianificazione
Piani di rischio
attenuato integrati
i i ib
Manageme
nt
Monitoraggio
Figura 6: La PRAM Guide risk management process [14]
15
IL PROJECT RISK MANAGEMENT
Il team che ha prodotto questa guida includeva professionisti, consulenti e
professori universitari. Il materiale è ben strutturato e facile da seguire.
La Guida Management of Risk (M_o_R) è scritta per le organizzazioni del
settore pubblico. Essa si occupa di tutti i rischi al successo di
un’organizzazione ed include una guida al processo di risk management,
asset manageriale, i ruoli e le responsabilità così come checklist per assistere
varie fasi del processo. Discute l’applicazione del risk management dal
livello strategico, includendo la direzione aziendale, fino ai programmi,
progetti e operazioni. C’è una forte enfasi nella guida M_o_R sulla struttura
organizzativa e sulla struttura direzionale che ha luogo nel risk management,
facendo eco alle priorità indicate nella guida PRINCE 2 per il project
management. La guida parla della cultura e di altri problemi relativi alla
corretta implementazione di un efficace risk management all’interno di
un’organizzazione. Allo stesso modo di come la PRAM Guide separa il
processo da specifici strumenti e tecniche, la M_o_R Guide separa il
processo generale di risk management da dettagli della sua implementazione
in strategia, programma, progetto e contesto operativo e da specifici
strumenti e metodi che potrebbero essere impiegati per eseguire una parte del
processo. Il flusso del processo descritto nell’ M_o_R è illustrato nella figura
7.
Definire la
struttura di
risk
Identificar
e i rischi
Identificar
e le
risposte ai
Valutare
i rischi
Implementar
e le risposte
Livelli
accettabili
di rischio
Assicurar
e
efficacia
Fissare il
processo e
revisionare
Figura 7: L’M_o_R Guideline risk management process [14]
Queste fonti alternative di guida al risk management non si scontrano fra loro
e ognuna di essa è valida. Alcune caratteristiche peculiari rendono ogni
approccio adatto in determinati contesti.
16
IL PROJECT RISK MANAGEMENT
L’approccio AS/NZS 4360 valuta i rischi individualmente, eccetto dove siano
identificati fattori comuni che collegano i rischi o le opportunità per offrire
iniziative strategiche che riguardano rischi diversi in una sola volta. E’ spesso
applicato con scale di valutazione qualitative; anche se, misure quantitative di
probabilità e conseguenza di rischio possono essere usate. Si presta bene a un
processo basato sul continuo aggiornamento di un registro dei rischi ed è
prontamente scalabile per adeguarsi alla dimensione e alla complessità del
progetto. La PMBOK Guide prevede principalmente strutture per il processo
di management. In essa alcune tecniche di analisi sono descritte oppure
vengono fatti riferimenti ad altre. Esse comprendono l’uso di scale
qualitative, alberi di decisione, diagrammi di influenza, analisi della
sensibilità e la simulazione Monte Carlo. Esse sono esplicitamente inserite in
un contesto di project management. La valutazione del rischio è indirizzata
sia in termini di rischi individuali sia di rischio aggregato in un progetto per
intero. La M_o_R Guide è, in linea di principio, applicabile generalmente
così come la AS/NZS 4360 ma è mirata e descritta in termini di
organizzazioni del settore pubblico. Alcune tecniche di analisi sono descritte
e c’è un ampio riferimento alle pubblicazioni relative all’OGC. La sua riserva
di metodi di analisi è ampia come quella della PRAM Guide e sono affrontati
separatamente dal processo di risk management come nella PRAM Guide. I
metodi raccomandati per l’uso a livello di progetto permettono sia di trattare i
rischi individualmente che di comprendere il rischio aggregato a un progetto
nell’assieme. Il contesto completo della guida è l’organizzazione dentro cui il
risk management viene applicato e il conseguimento degli obiettivi
dell’organizzazione.
Le fasi nei processi sottolineati possono essere relazionate fra di loro
approssimativamente come mostrato in figura 2. Questa sottolinea come tutti
loro coprono essenzialmente lo stesso campo, come ci si aspetterebbe.
L’M_o_R e l’AS/NZS 4360 sono meno orientati al compito rispetto agli altri
due approcci, essendo più preoccupati dei bisogni del processo ad alto livello.
17
IL PROJECT RISK MANAGEMENT
L’M_o_R, in particolare, si focalizza sul contesto organizzativo e i ruoli e le
responsabilità degli stakeholder durante tutto il processo così che il suo
allineamento alle altre fasi degli altri approcci appare meno chiaro rispetto
all’allineamento degli altri tre [14].
M_o_R
Struttura
Identificazio
ne dei rischi
Livello di
rischio
Valutar
ei
Risposte
Assicurar Fissare e
e
revisiona
AS/NZS
Stabilire
il
Identificazio
ne dei rischi
Analisi
dei
Valutazio
ne dei
Trattament
o dei rischi
Monitoraggio
e controllo
PRAM
Definire Focalizza Identificazion
progett re PRAM
e
Assessment
Pianificazio
ne
Managemen
t
PMBO
Pianificazion
e
Identificazion Analisi
Analisi
Pianificazio
e
qualitativ quantitativ ne della
Monitoraggi
o e controllo
Figura 8: Comparazione processi [14]
Le basi del Project Risk Management
L’obiettivo del risk management è identificare e gestire i rischi significativi.
Esso si compone di diverse fasi chiave, con un feedback realizzato mediante
un processo di monitoraggio e controllo. L’approccio al project risk
management adottato in questo elaborato è in linea con l’AS/NZS 4360
(figura 9). Tale standard è ben provato, copre tutto ciò si ha bisogno di
considerare ed da un supporto cospicuo e crescente sia nel settore pubblico
che privato, in molti paesi del mondo. Come già detto precedentemente, esso
necessita di essere arricchito di strumenti e tecniche, che, verranno estratte
dalla letteratura disponibile in materia.
Da questo schema si rileva immediatamente che si è di fronte ad un processo
iterativo in linea con la filosofia dei sistemi di gestione esaminati. La figura
18
IL PROJECT RISK MANAGEMENT
originale è stata modificata leggermente per mettere in evidenza le fasi del
ciclo “Plan-Do-Check-Act”.
Definire il Contesto
Analizzare i Rischi
Valutare la Significatività dei
Rischi
Risk
Assessmen
t
Pianificare il Trattamento
Risk
Managem
ent Plan
Risk Management
Evaluation Report
Risk
Managem
ent
Monitoraggio e Revisione
Risk Assessment
PLAN
Comunicare e Consultare
ACT
Identificare i Rischi
CHEC
Attuare il Trattamento
DO
Figura 9: Processo di gestione del rischio – Visione complessiva [17]
Come indica la figura 2.9, la prima attività nella gestione del rischio è quella
della Definizione del Contesto. Questa fase chiarisce l’organizzazione e
l’ambiente progettuale nel quale si svilupperà l’analisi del rischio, i principali
obiettivi, i risultati richiesti, un insieme di criteri di riferimento rispetto a cui
misurare le conseguenze dei rischi identificati e un insieme di elementi
chiave per strutturare le fasi di identificazione e valutazione del rischio. Tutto
ciò, che costituirà l’output di questa fase, verrà riportato in un documento
sintetico. Per tale motivo, gli input di questa fase saranno documenti chiave
del progetto, come la strategia esecutiva, la Project Charter, ipotesi di costi e
schedulazione, definizione degli scopi, disegni tecnici, analisi economiche e
altra documentazione rilevante circa il progetto. La fase di Identificazione
dei Rischi, determina ciò che potrebbe accadere, che potrebbe interessare gli
obiettivi di progetto, e come potrebbe presentarsi. Il processo di
identificazione del rischio deve essere accurato, in quanto i rischi che non
19
IL PROJECT RISK MANAGEMENT
sono stati identificati non possono essere valutati, e la loro comparsa in un
secondo momento potrebbe minacciare il successo del progetto e causare
spiacevoli sorprese. La fase dovrebbe essere strutturata utilizzando gli
elementi chiave per esaminare i rischi sistematicamente, in ogni area del
progetto da affrontare. Diverse tecniche possono essere utilizzate per
l’identificazione dei rischi, ma il brainstorming è il metodo preferito per la
sua flessibilità e capacità, se adeguatamente strutturato, di generare una vasta
e diversificata gamma di rischi. Le informazioni usate in questa fase
potrebbero includere dati storici, analisi teoriche, dati empirici, opinioni
informali del team di progetto e di altri esperti, senza contare gli interessi
degli stakeholder. Il risultato è un elenco completo dei possibili rischi che
attentano il buon esito del progetto, di solito sotto forma di registro dei rischi
(Risk Management Database - RMD) con responsabilità di gestione loro
assegnata. Ad essa seguono l’Analisi e la Valutazione dei Rischi che
permettono di ottenere una visione più oggettiva delle percezioni istintive
sulla rischiosità del progetto. L’unione di queste due fasi prende il nome di
Risk Assessment e il suo fine è sviluppare una lista di priorità dei rischi e
una dettagliata comprensione del loro impatto sul successo del progetto
qualora dovessero verificarsi. Infatti l’Analisi dei Rischi prevede l’uso
sistematico delle informazioni disponibili per determinare la frequenza con
cui gli eventi specificati possono verificarsi e la portata delle loro
conseguenze mentre la fase di Valutazione dei Rischi prevede il confronto
dei rischi stimati con i criteri forniti per determinarne l’entità. Le priorità
accordate sono utilizzate per determinare dove dovrebbe essere focalizzato il
maggiore sforzo per il trattamento dei rischi identificati. Esse facilitano la
pianificazione di azioni strutturate e l’allocazione delle risorse. Le
conseguenze, le stime di probabilità e le priorità dei rischi sono tutte
memorizzate nel registro dei rischi. Al termine di queste attività potrà essere
prodotta la bozza di una relazione sulla natura ed il livello di rischio a cui il
progetto è esposto (Risk Assessment Report). Dopo la fase di diagnosi si
20
IL PROJECT RISK MANAGEMENT
passa poi alla individuazione di strategie generali e particolari per ridurre i
fattori di rischio più significativi, secondo la scala di priorità, sia nella loro
probabilità di accadimento che nella entità dei loro possibili effetti,
selezionando le migliori opzioni per il progetto. Questo sarà possibile
attraverso la Pianificazione del Trattamento dei rischi, che permetterà la
formulazione di un Risk Management Plan. Infatti, se non si prenderanno le
misure necessarie, le fasi di identificazione e di quantificazione dei rischi
risulteranno sprecate. Scopo del RMP sarà quello di ridurre il Rischio
Incondizionato (Unconditioned Risk) associato al progetto ad un Rischio
Residuo (Residual Risk) che abbia un livello di accettabilità esplicitamente
definito. Lo standard viene così ad arricchirsi di una seconda sezione: quella
relativa al rischio stimato a posteriori dell’applicazione del piano di gestione
RMP. Sarà possibile a questo punto, attraverso il confronto tra Rischio
Incondizionato e Rischio Residuo, attribuire al piano di gestione RMP un
livello “a priori” di efficacia stimata nella rimozione del rischio misurato
attraverso un indice apposito. Il piano RMP sarà un prezioso input per la
definizione del piano generale di lavoro di progetto col quale deve essere
ovviamente coordinato in quanto le attività di gestione del rischio sono esse
stesse attività progettuali e come tali vanno gestite nel quadro della
pianificazione e controllo integrati. Alla pianificazione degli interventi di
gestione seguirà l’attività di Attuazione del Trattamento nella quale si
metteranno in atto tutte le iniziative di prevenzione previste dal RMP, si
attiveranno tutti i “sensori” progettati al fine di rilevare tempestivamente
l’accadimento di un evento rischioso ed infine si adotteranno tutte le
contromisure necessarie per contrastare i rischi che si saranno eventualmente
tramutati in problemi da neutralizzare o almeno mitigare. Altra fase prevista
dallo standard è quella di continuo Monitoraggio e Controllo dei Rischi
affinché nuovi rischi siano rilevati e gestiti e i piani d’azione siano attuati in
modo efficace. Essa è necessaria al fine di confermare o contestare la validità
del RMP in modo da prevedere eventuali nuovi interventi di prevenzione,
21
IL PROJECT RISK MANAGEMENT
sorveglianza o contrasto più efficaci di quelli adottati fino a quel momento. Il
risultato di questa attività si potrà concretizzare in un documento chiamato
Risk Management Evaluation Report che conterrà valutazioni sulle cose
accadute, sull’efficacia della prevenzione eseguita e delle reazioni adottate.
Questa attività potrà innescare nuovamente sia la fase di diagnosi che la fase
di pianificazione, oltre ad una revisione del registro dei rischi. Infine, la
Comunicazione e la Consultazione con gli stakeholder di progetto potrebbe
essere un fattore critico per il raggiungimento di un buon risk management e
per ottenere risultati di progetto che siano largamente accettati. Essi aiutano i
proprietari, i clienti e gli utilizzatori finali a capire i rischi e i trade-off che
potrebbero esserci in un grande progetto. Questo assicura che tutte le parti
siano pienamente informate in modo da evitare spiacevoli sorprese. Nella
pratica ciò si realizza mediante la redazione, da parte del team di progetto, di
reports che contengono una sintesi dei rischi di progetto, lo stato delle azioni
di trattamento e un’indicazione delle tendenze in termini di incidenza dei
rischi, affinché questi possano comprendere la situazione che si trovano ad
affrontare [14]. I paragrafi successivi forniranno una descrizione degli aspetti
più importanti dello schema presentato.
Definizione del Contesto
Per definire il contesto bisogna specificare i seguenti aspetti.
• Obiettivi: per assicurare che tutti i rischi significativi siano considerati è
necessario conoscere gli obiettivi dell’organizzazione e del progetto [14].
Gli obiettivi principali del progetto sono generalmente noti prima
dell’individuazione dei membri del team di progetto. Peraltro occorre il
concorso del team per chiarire, completare e quantificare questi obiettivi
di massima e per elaborarne descrizioni che siano ben comprese e
accettate da tutti i membri, anche per ottenerne l’impegno convinto.
Hastings e altri osservano che i team devono essere coscienti
22
IL PROJECT RISK MANAGEMENT
dell’esistenza d’una pluralità di aspettative sulla loro performance nel
progetto, aspettative spesso reciprocamente contrastanti e coltivate sia
all’esterno del team, sia al suo stesso interno, dai diversi membri. Questi
autori propongono di considerare la performance e il risultato del progetto
secondo le categorie dell’oggettività quantitativa dei criteri e
dell’eccellenza dei risultati. Nel primo caso si giudica la performance
secondo criteri quantitativi (ben tangibili, riferiti alla misura dei tempi, dei
costi, delle risorse e delle prestazioni tecniche rispetto a determinati
standard) o secondo criteri qualitativi (più soggettivi e meno suscettibili di
riscontro misurabile, ma non per questo meno usati, e riguardano
soprattutto il modo nel quale si realizzano i compiti di progetto, le idee e
gli orientamenti del team di progetto, aspettative anche inespresse del
cliente, e così via). Nel secondo caso, i team ritengono buona la loro
performance, ma ritengono anche di poter fare di meglio. I team si
sforzano d’emergere e d’arrivare un po’ più in là della concorrenza più
agguerrita. Non cessano di ricercare modi nuovi e migliori, come non
cessano di verificare i loro assunti su ciò che è fattibile e di ricercare
soluzioni ai problemi che si presentano sulla loro strada. Questo non
significa
che
sia
opportuno
spingere
i
tecnici
a
migliorare
indefinitivamente la performance del prodotto, andando oltre le specifiche
tecniche (tendenza alla quale si riconduce spesso la responsabilità dei
ritardi e dei costi aggiuntivi nei progetti). Piuttosto, significa sforzarsi
incessantemente di migliorare tutti gli aspetti del progetto, restando entro
i limiti di tempo e di costo stabiliti (è ciò che fanno i team di progetto
meglio riusciti). I miglioramenti riguardano il modo nel quale sono svolti
i compiti, la rapidità e l’efficienza del lavoro, la qualità e l’entità dei
risultati. Tutto, naturalmente, entro i limiti stabiliti per il progetto [24].
Gli obiettivi sono al cuore della definizione del contesto e sono inseriti nel
processo di risk management per mezzo dei criteri utilizzati per misurare i
risultati ottenuti. I criteri, infatti, vengono usati per misurare gli impatti o
23
IL PROJECT RISK MANAGEMENT
le conseguenze dei rischi che potrebbero mettere a repentaglio gli
obiettivi stessi. Si parte con la identificazione del campo di applicazione
del progetto, le principali questioni e temi di interesse per
l’organizzazione e la relazione che sussiste tra progetto, strategia e
obiettivi di business dell’organizzazione. Le esigenze principali per
l’organizzazione che commissiona o contrae il progetto sono spesso
specificate in forma di obiettivi di politica aziendale. I requisiti possono
avere differenti interpretazioni a seconda della fase del ciclo di vita del
progetto.
¾ Nella fase di pianificazione di un progetto, i requisiti sono spesso
relativi a una politica generale e le performance desiderate sono
espresse in termini generali, facendo una stima di massima per ciò che
riguarda la sua realizzazione, il suo costo e le sue scadenze. Inoltre
potrebbero essere presenti alcuni o tutti i criteri di costi e benefici usati
nel processo di valutazione economica. Il risk management è spesso
intrapreso nello stesso tempo come una stima economica.
¾ Nella fase di esecuzione, il valore del denaro è critico, e l’etica
comportamentale
e
la
probità
potrebbero
essere
importanti
considerazioni, specialmente per importanti settori pubblici e privati.
¾ Nelle fasi conclusive di manutenzione e controllo, i criteri sono
probabilmente molto più specifici e concernenti con il completamento
più efficiente del progetto, con le previsioni dei prodotti e servizi e con
la soddisfazione dei bisogni degli utilizzatori. In questo caso, il livello
di domanda, i redditi e le spese, i ritardi rispetto al programma e la
qualità del prodotto e servizio potrebbero essere misure appropriate.
Sebbene i criteri sono usati durante le ultime fasi del progetto, questi
sono sviluppati molto prima. Questi potrebbero essere specificati nel
fascicolo iniziale e nell’analisi dei bisogni degli utilizzatori nella
prima fase del processo di pianificazione dei requisiti.
24
IL PROJECT RISK MANAGEMENT
I requisiti specifici sono tipicamente collegati direttamente allo stesso
progetto. Questi includono alcuni obiettivi come:
¾ controllo dei costi, assicurando che il progetto sia condotto all’interno
del budget disponibile;
¾ controllo della schedulazione, controllando che il progetto sia
completato all’interno dell’arco di tempo accordato;
¾ controllo del livello di qualità, assicurando che il progetto e i suoi
risultati siano conformi con quelli attesi.
• Identificazione ed analisi degli stakeholder: l’analisi degli stakeholder è
importante nella valutazione del rischio per molte attività. Questa è
generalmente intrapresa all’inizio della fase di pianificazione. Tutti i
progetti coinvolgono almeno due stakeholder: l’entità del procuratore
(l’acquirente) e il fornitore di beni e servizi (il venditore). I differenti
obiettivi di queste due parti, e le relazioni contrattuali tra loro, sono fattori
determinanti per l’assegnazione e la gestione del rischio nel processo di
approvvigionamento. Nella maggior parte dei progetti, però, c’è un più
ampio insieme di stakeholder di cui i risultati desiderati devono essere
considerati quando si pianifica un progetto. L’analisi degli stakeholder
fornisce alla direzione un documento con il profilo degli stakeholder per
avere una migliore comprensione dei loro bisogni e interessi. Si tratta di
considerare gli obiettivi di ciascuno dei soggetti interessati in relazione al
requisito. Tale analisi svolge un ruolo importante nel dimostrare
l’integrità del processo e nell’assicurare che gli obiettivi della valutazione
del rischio comprendano tutti gli obiettivi e le aspettative legittime degli
stakeholder. Sul coinvolgimento degli stakeholder si basa l’accettazione e
la generazione di soluzioni costruttive. Sbagliare a identificare e includere
gli stakeholder può portare al fallimento dell’accettazione della proposta e
della strategia da parte del management, i clienti, lo staff, i controllori e la
comunità. Molte analisi sofisticate potrebbero essere appropriate dove
sono previsti maggiori rischi sociali e per la comunità.
25
IL PROJECT RISK MANAGEMENT
• Criteri: i requisiti dell’organizzazione e degli stakeholder chiave sono
usati per dedurre un insieme di criteri per il progetto. Questi saranno usati
per determinare scale specifiche con cui le conseguenze dei rischi saranno
valutate nelle successive fasi di analisi del rischio. Essi possono anche
costituire la base per la valutazione dei progetti al fine dell’acquisizione.
La gamma di criteri può essere ampia. La tabella 1 mostra un esempio di
un progetto di medie dimensioni dove la comunità di accettazione era
importante. Questa lista di criteri è stata una preziosa guida per il project
manager durante le fase iniziale di pianificazione del progetto.
Tabella 1: Criteri per progetti di media entità [14]
Criterio
Note
Disponibilità
La disponibilità delle risorse esistenti deve essere massimizzata
riducendo la disgregazione delle operazioni aziendali occorrenti
come meglio possibile
Relazioni con la società
I più alti livelli di consultazione e relazione con la società devono
essere mantenuti
Economie
Il progetto deve essere chiaramente giustificabile in termini
economici, misurandone la profittabilità e il tasso di ritorno
Ambiente
Le soluzioni a problemi tecnici devono essere compatibili con
l’ambiente, una soluzione alternativa potrebbe essere disponibile
Finanziamenti
Evitare spese al di fuori delle risorse fornite; massimizzare l’uso
di fondi speciali sovvenzionati per il caso specifico
Qualità
Il cliente richiede il prodotto o il servizio che verrà appositamente
progettato e realizzato
Sicurezza
I processi di adempimento del progetto devono assicurare i più
alti standard di sicurezza; le condizioni del contratto devono
contenere clausole specifiche per il caso particolare
Tempi
Il progetto deve essere completato in data specificata per
adempiere alle richieste degli utilizzatori
Sviluppo dello staff
Il metodo di adempimento al progetto e le conseguenze
potrebbero migliorare le skill principali dell’organizzazione e le
abilità dello staff coinvolto
• Elementi chiave. Eccetto nel caso di progetti molto piccoli,
l’identificazione dei rischi sarà improduttiva se si tenta di esaminare il
26
IL PROJECT RISK MANAGEMENT
progetto nel suo complesso. E’ molto più efficace dividere il progetto in
sezioni o elementi chiave per l’identificazione dei rischi. Gli elementi
chiave sono una serie di temi da considerare uno per uno durante
l’identificazione dei rischi. Ogni argomento è piuttosto più piccolo del
progetto nel suo complesso, ciò permette a chi esegue l’identificazione di
concentrare i suoi pensieri e di andare più in profondità di quanto si
potrebbe se si cercasse di occuparsi del progetto nel suo complesso. Un
buon insieme pianificato di elementi chiave stimoleranno pensieri creativi
e assicureranno che tutti i punti importanti di discussione siano
considerati prima per una identificazione dei rischi responsabile. Quando
una riunione di brainstorming è utilizzata per identificare i rischi, gli
elementi chiave formano la base per tale incontro. L’insieme degli
elementi chiave deve essere completo, in modo che esso copra tutti gli
aspetti significativi. Tuttavia, così come il numero di elementi chiave
tende a guidare la durata della fase di identificazione dei rischi, allo stesso
modo esso deve essere contenuto in una scala appropriata. Esso deve
avere un linguaggio specifico a sufficienza per stimolare l’identificazione
dei rischi, cercando di evitare così un atteggiamento superficiale. Gli
elementi chiave potrebbero essere basati su differenti aspetti del progetto,
dipendenti dagli obiettivi e risultati facenti capo all’organizzazione e agli
altri stakeholder. Esistono diversi schemi che aiutano nella selezione degli
elementi. Spesso, la Work Breakdown Structure (WBS) del progetto è il
miglior punto di partenza, con il suo dizionario allegato, che descrive a
parole il significato di ciascun elemento di lavoro. Questo è
particolarmente conveniente in modo che l’analisi del rischio sia in linea
con altri importanti aspetti del progetto, che comprendono la matrice delle
responsabilità, le strutture di progettazione e pianificazione, dei costi e
schedulazione. Sebbene la WBS fornisce un buon punto di partenza per
un insieme di elementi chiave per molti progetti, ci sono generalmente
altri elementi collegati che devono essere aggiunti. Talvolta è opportuno
27
IL PROJECT RISK MANAGEMENT
utilizzare diversi livelli della WBS a seconda della struttura dei costi e dei
rischi e può anche essere necessario modificare la struttura della WBS ai
fini dell’analisi dei rischi. La definizione degli elementi chiave richiede il
parere del manager responsabile. Ci saranno dei punti di incontro tra
l’efficacia del processo di analisi del rischio e l’integrazione dei suoi
risultati con altri aspetti di analisi e pianificazione di progetto. In molte
circostanze, è raccomandato che la struttura che viene scelta sia più
efficace per l’analisi del rischio. L’uso di una struttura inappropriata può
portare a omettere inavvertitamente parti importanti, con conseguenze
potenzialmente serie, tanto da realizzare un processo davvero inefficiente.
Per molti fini di analisi del rischio, una visione ampia di un progetto può
essere più appropriata di una dettagliata, al fine di agevolare una globale
revisione dei rischi che potrebbero influire su di esso. Le assunzioni
principali circa l’elemento dovrebbero essere stabilite esplicitamente, in
particolar modo se diverse persone sono coinvolte in differenti parti del
processo di identificazione e valutazione del rischio, come potrebbe
accadere in un grande progetto. Questo è necessario per assicurare
assunzioni compatibili e consistenti e per facilitare le successive analisi.
Chiaramente le assunzioni stabilite sono particolarmente importanti nelle
prime fasi di un progetto, prima che ogni cosa venga pienamente definita,
quando l’analisi e la valutazione devono essere intraprese sulla base di
pareri professionali ragionati su come le successive fasi di progetto
saranno eseguite [14].
La fase di identificazione dei rischi di progetto
Questa fase comporta l’identificazione dei rischi che derivano da tutti gli
aspetti del contesto descritti nella precedente fase [14]. L’obiettivo di questa
fase è quello di portare all’attenzione esplicita delle parti coinvolte nel
progetto, un insieme il più possibile completo di elementi di criticità che
28
IL PROJECT RISK MANAGEMENT
costituiscono la base per la valutazione del rischio generale e per la
predisposizione delle opportune risposte di governo [17].
Il processo può concentrarsi su una o più possibili aree di impatto rilevanti
per il progetto, ma una metodologia standard dovrebbe essere applicata in
tutte le funzioni. E’ importante assicurare che la maggior parte dei rischi
venga identificata, perché i rischi omessi in questa fase non possono essere
analizzati e trattati nel corso delle fasi successive.
Valide informazioni sono importanti per individuare e comprendere i rischi e
le conseguenze di ognuno di essi. Devono essere accessibili le fonti di
informazioni esistenti e se necessario nuove fonti di dati devono essere
sviluppate. Benché non è sempre possibile avere il meglio o tutte le
informazioni, le risorse a disposizione dovranno essere pertinenti, complete,
accurate e tempestive. Questo significa che è fondamentale avere specialisti e
personale esperto ad assistere l’attività di identificazione dei rischi [14].
Questa attività dovrebbe essere eseguita la prima volta durante lo studio di
fattibilità del progetto. Impegnarsi nell’anticipazione di quelli che possono
essere i fattori cruciali di successo e d’insuccesso per il progetto in un
momento in cui non si sono ancora investite risorse significative e prese
decisioni irrevocabili rappresenta sicuramente una buona prassi gestionale.
Eventi critici che accadono inaspettati, infatti, comportano quasi sempre un
dispendio di risorse significativo e che talvolta non consente neppure di
recuperare la situazione stessa [17]. Però l’identificazione dei rischi è un
processo di tipo iterativo: con il progressivo avanzare del ciclo di vita del
progetto potrebbero infatti venire rilevati rischi nuovi o, quelli individuati,
cambiare in natura o entità. La frequenza dell’iterazione e la tipologia di
persone coinvolte in ciascun ciclo variano da caso a caso. Al processo
dovrebbe comunque prendere parte il gruppo di progetto, in modo che possa
sviluppare e conservare un senso di titolarità e responsabilità nei confronti
dei rischi e delle corrispondenti azioni di risposta. Gli stakeholder esterni al
29
IL PROJECT RISK MANAGEMENT
gruppo di progetto possono fornire delle informazioni aggiuntive da un punto
di vista diverso da quello del gruppo di progetto [52].
Il rischio complessivo di un progetto è determinato dalla composizione ed
interazione di singoli elementi di rischio, indipendenti o correlati tra loro,
ognuno con una sua probabilità di verificarsi ed un suo impatto sul risultato
finale che manifesterebbe se fosse lasciato libero di agire senza controllo. La
composizione precisa delle probabilità parziali per l’ottenimento del rischio
generale è trattato con l’ausilio del calcolo delle probabilità. In un’ipotesi
semplificativa nella quale i vari elementi critici siano tra loro indipendenti
potremo supporre che la probabilità di insuccesso globale sia la somma delle
probabilità degli elementi parziali.
Nell’individuazione di tali elementi di base occorre rifuggire dalla tentazione
di elencare le innumerevoli e normali circostanze da cui dipende l’esecuzione
corretta del lavoro per concentrarsi sui soli fattori critici maggiormente
responsabili della sua riuscita o del suo fallimento secondo la ben nota legge
di Pareto (20% dei fattori, 80% dei risultati) [17].
Esistono molti strumenti e tecniche per l’identificazione dei rischi associati ai
progetti. Alcune di esse, quelle maggiormente utilizzate nella pratica,
vengono elencate nella sottostante tabella 2, insieme ai concetti
precedentemente richiamati.
Tabella 2: Fase di identificazione dei rischi
INPUT
TECNICHE E
STRUMENTI
OUTPUT
SKILL NECESSARI
• Informazioni sul progetto:
•
Brainstorming
•
¾ Descrizione del problema
•
Delphi
(Risk
• Capacità analitiche
¾ Descrizione del contesto
•
Interviste
Management
• Capacità descrittive
¾ Obiettivi del progetto
•
Analisi “swot”
Database)
• Capacità comunicative
¾ Requisiti del progetto
•
Checklist
¾ Vincoli e condizioni
•
Diagrammi causa/effetto
¾ Soggetti coinvolti
•
Tecniche reticolari
¾ Descrizione soluzione
•
Diagramma di contesto
¾ Risorse assegnate
•
Mappa cognitiva del
¾ Piano generale di lavoro
•
RMD
• Creatività
interpersonali
• Esperienza del contesto
applicativo
• Conoscenza
delle
tecniche specifiche
territorio
Informazioni storiche
30
IL PROJECT RISK MANAGEMENT
Brainstorming
Un approccio molto usato per l’identificazione dei rischi all’interno di un
gruppo di lavoro è il Brainstorming. Essa è una metodologia la cui
applicazione richiede la presenza di un insieme di persone che si riuniscono
per ricercare la soluzione del problema in esame. Da ciò si deduce come essa
sia basata sulla capacità creativa dei partecipanti e non sull’uso superficiale
di meccanismi, come le checklist, riducendo così il pericolo di trascurare
nuovi ed emergenti problemi. La Brainstorming è una tecnica che ben si
adatta all’identificazione di un ampio ventaglio di rischi, per tale motivo,
risulta particolarmente appropriata nel caso di progetti grandi o unici [17].
Anche se l’intuizione viene generalmente ritenuta una produzione
tipicamente individuale, l’ideazione, in Azienda, scaturisce, quasi sempre, da
un processo collettivo per due ordini di motivi: innanzitutto in quanto,
nell’impresa moderna, pressoché tutte le decisioni necessitano dell’apporto di
professionalità e di ruoli differenti e, in secondo luogo, in quanto le
particolari scelte che vengono operate non possono prescindere dal peculiare
ambiente culturale e organizzativo del contesto nel quale, le stesse, vengono
sviluppate. Il momento di “messa in comune” se, da una parte, è complicato
dalla dimensione implicita del livello di conoscenza e di professionalità del
quale sono portatori i singoli soggetti coinvolti, dall’altra usufruisce dei
benefici effetti che la riunione di più “menti pensanti” riesce, in genere, ad
ottenere grazie all’ “interazione tra le persone e la moltiplicazione dello
sforzo di ciascuno con quello di un altro” [32]. Secondo Polanyi, “le persone
sanno di più di ciò che pensano di sapere”, ed è proprio questa conoscenza
tacita o inespressa che può manifestarsi a condizione che, durante il raduno, i
singoli partecipanti vengano opportunamente e correttamente sollecitati [53].
Il primo e anche il più famoso tentativo di sistematizzazione della creatività
di gruppo, fu ideato da Alex Osborn il quale, tra gli anni ’40 e ’50, formulò le
31
IL PROJECT RISK MANAGEMENT
norme comportamentali e le prassi operative che sovrintendono allo
svolgimento di una sessione che lui stesso definì di brainstorming [46].
Ciò ribadisce la previsione di un approccio interattivo basato su team,
dipendente per i suoi successi dall’ampiezza dell’esperienza e skill presenti
nel gruppo di brainstorming e nel “facilitator”, ovvero colui che presiede la
sessione. A tale scopo, si è soliti inglobare i membri chiave del team di
progetto, insieme ad altri specialisti che possano portare esperienze
addizionali necessarie al processo.
Brainstorming letteralmente significa “tempesta del cervello” e si riferisce ad
una riunione di persone durante la quale viene sollecitata una discussione di
gruppo il cui scopo consiste nel far emergere il numero più alto possibile di
idee su un ben determinato argomento. Lo scopo della sessione di
brainstorming è capire tutti i potenziali rischi, non esprimendo giudizi sulla
loro importanza nelle fasi iniziali. Infatti, soltanto (e rigorosamente) al
termine della sessione verranno effettuate la selezione, la critica e la
valutazione delle singole idee prodotte. E’ auspicabile che il gruppo sia
composto da personale eterogeneo (per specializzazione lavorativa, per
livello di istruzione, posizionamento gerarchico e così via): la varietà e la
difformità degli skill individuali presenti si rivela, generalmente, un fattore di
successo in quanto incide positivamente sull’originalità delle singole idee
prodotte (solitamente, lo “scontro” tra mentalità diverse apre nuove strade
alla fantasia e all’inventiva dei singoli) [44].
Una sessione di brainstorming spesso comporta una ben definita sequenza di
passaggi. Un facilitator deve essere nominato e il team di brainstorming
selezionato istruito per sommi capi sullo scopo dell’esercizio e dei risultati
desiderati. Dopo che ogni elemento è stato raccolto esso viene osservato in
dettaglio. L’elemento viene definito da qualcuno che ha familiarità con esso.
Dopodiché il team trascorre qualche instante a pensare ai possibili rischi, che
vengono annotati su un foglio. Tipicamente quando gli altri partecipanti
danno il loro contributo la lista potrebbe raddoppiare in grandezza. A questo
32
IL PROJECT RISK MANAGEMENT
punto i rischi simili vengono classificati e raggruppati. Lo scopo
generalmente è quello di creare una lista di circa dieci rischi per ogni voce,
sebbene questo numero varierà molto
dipendentemente dall’elemento che è
stato considerato. Dieci è semplicemente un limite pratico alla dimensione
della lista dei rischi, per evitare uno sforzo eccessivo che viene speso quando
il numero di voci è troppo piccolo. Ad ogni modo dieci non dovrebbe essere
considerato un valore fisso. E’ altrettanto importante documentare quei rischi
che sono scartati, per mantenerne traccia ai fini di un controllo e per facilitare
un’analisi seguente, se necessaria. Una sequenza simile è fatta per ogni
elemento chiave.
Una sequenza strutturata è il format più efficace per il brainstorming. Se ciò è
impraticabile, interviste pianificate da consulenti preparati, questionari o
indagini possono essere usati ed hanno il vantaggio di avere un costo
effettivo probabilmente minore dell’approccio descritto precedentemente.
Qualunque impostazione di brainstorming sia adottata, è imperativo che
nessuna checklist, o altri strumenti di individuazione dei rischi che possono
sorgere, venga considerata prima della chiusura della sessione di
brainstorming, altrimenti in anticipo verrebbe mostrata loro minore
attenzione. Il modo in cui viene gestito il processo deve assicurare che
l’informazione storica non blocchi una valutazione creativa del futuro, per
cui difficoltà mai viste prima non possano emergere.
In definitiva, il brainstorming è consigliabile quando si considera
l’esecuzione di attività nuove o non standard, in modo da incoraggiare un
pensiero vario e innovativo. Per attività routinarie le checklist potrebbero
essere più veloci ed efficienti [14].
Metodo Delphi
Il Metodo Delphi, con la sua particolare struttura, consente, tramite la
somministrazione ripetuta di questionari, di ottenere non soltanto opinioni
33
IL PROJECT RISK MANAGEMENT
singole, ma di sollevare un confronto, una sorta di dibattito “virtuale”,
intorno all’individuazione dei rischi di progetto, tra esperti, appartenenti a
“categorie” diverse, selezionati per il campione. L’applicazione del Metodo
Delphi è particolarmente adatta per quelle problematiche in cui
l’informazione più utile, che si auspica di ricavare, è il giudizio informato di
persone esperte e competenti del settore di riferimento. Si tratta di un metodo
qualitativo, partecipativo, previsionale e di confronto.
Ci sono molti modelli di Metodo Delphi, ma quello classico, “standard”, è
caratterizzato da tre fasi: esplorativa, analitica e valutativa.
Ancora prima di queste tre fasi il ricercatore deve affrontare un momento
determinante per la futura validità, attendibilità dei risultati raggiunti, cioè la
scelta dei partecipanti al gruppo Delphi. La selezione del gruppo Delphi
deve essere condotta secondo un attento ragionamento, in base ad una scelta
mirata di “chi” scelgo, piuttosto che di “quanti” ne scelgo; il criterio guida
non è quindi “più è alto il numero del gruppo, più i risultati saranno
attendibili e rappresentativi”, ma si tratta del criterio dell’expertise.
Nella fase esplorativa si costruisce il primo questionario, da somministrare
al campione, con una serie di domande, per lo più aperte e di carattere
generale sul tipo di progetto da affrontare, che hanno l’intento di far
emergere punti di vista che andranno poi affinati e “distillati” nelle
successive fasi. Si tratta di una fase che ha lo scopo di inquadrare il tema, di
disegnare un quadro generale sul problema indagato, un quadro che
permetterà ai ricercatori di delineare con precisione i rischi che attentano gli
obiettivi di progetto.
L’analisi delle risposte date al primo questionario è l’ultimo momento della
prima fase e il primo momento della seconda, fase analitica, dal quale deriva
la costruzione di un secondo questionario il quale, nella prima parte, riporta i
concetti emersi dall’analisi del precedente e successivamente affronta in
maniera più dettagliata gli aspetti venuti fuori nella fase esplorativa. In questa
fase ogni esperto del campione ha la possibilità, non solo, di ritrovare alcune
34
IL PROJECT RISK MANAGEMENT
sue affermazioni che può, e qui sta un’ulteriore peculiarità del Metodo
Delphi, ritrattare, cambiare, modificare, ma ritrovare anche la sintesi dei
rischi espressi dagli altri esperti con i quali può confrontarsi commentando e
mostrando il proprio accordo o meno. La struttura del Metodo Delphi
consente di creare, quindi, un processo di comunicazione tra i partecipanti al
gruppo di esperti, consentendo a ciascuno di esprimere il proprio sapere,
opinione e rivederla, dopo aver conosciuto, in forma aggregata e anonima
(feedback), il giudizio espresso dagli altri.
Quello che emerge dall’analisi del secondo questionario viene incanalato
verso una progressiva quantificazione dei dati ed è proprio questa la fase
(fase valutativa) che dà originalità all’intero processo, questa integrazione
tra elementi qualitativi ed elementi quantitativi. Il terzo ed ultimo
questionario consente ad ogni esperto di esprimere il proprio giudizio
riguardo ai possibili futuri cambiamenti ai quali potrà essere sottoposto il
progetto oggetto della ricerca. Questo è possibile elencando al campione una
lista di probabili tendenze da valutare, attraverso una rappresentazione
numerica, in relazione alla probabilità di verificarsi [58].
Il Metodo Delphi offre diversi vantaggi nel suo utilizzo, in alcuni casi,
rispetto ad altre metodologie che presuppongono sempre uno scambio
d’informazioni, un confronto e una comunicazione di gruppo (come, per
esempio, conferenze, brainstorming ed altri processi interattivi). Infatti,
l’utilizzo della tecnica Delphi, con la sua struttura a stadi, è particolarmente
indicata quando le tipologie di progetti da esplorare hanno una natura incerta,
le informazioni a disposizione sono poche, difficili da reperire o non
disponibili. La struttura a stadi del Metodo Delphi favorisce anche la
risoluzione di problemi decisionali e di intervento, tramite l’autocorrezione e
la convergenza di valutazioni individuali, consentite dal processo di
feedback. L’altro fattore positivo, dato sempre dalla struttura che procede per
fasi, è la possibilità che ha il team di ricercatori di monitorare la ricerca in
itinere, in modo da “calibrarla”, qualora ce ne fosse bisogno. Per quanto
35
IL PROJECT RISK MANAGEMENT
riguarda gli svantaggi, uno dei grandi limiti di questo metodo è il costo della
sua applicazione. Altra critica mossa alla tecnica Delphi è la mancanza di
rigore scientifico, ma non è metodologicamente meno valida di tecniche
basate su uno scambio di informazioni, come l’intervista, la brainstorming,
che sono ormai fra le più utilizzate come strumenti di identificazione [44].
Analisi S.W.O.T.
Questa metodologia, sviluppata da H. Weihrich nel 1982, viene ormai
comunemente utilizzata in marketing, ma può trovare un impiego efficace
anche nella fase di identificazione dei rischi di progetto. La tecnica S.W.O.T.
consente di sistematizzare e di rendere immediatamente fruibili le indicazioni
che si sono preliminarmente raccolte riguardo alle variabili che caratterizzano
l’ambiente (interno ed esterno) entro il quale si colloca il progetto. Un’analisi
S.W.O.T. richiede pertanto la completezza e la correttezza delle conclusioni
alle quali si è pervenuti in sede di analisi preliminare del contesto: è
indispensabile, infatti, che in questa fase ne vengano poste in luce tutte le
peculiari caratteristiche, strutturali e congiunturali, e vengano, inoltre,
chiaramente evidenziate le eventuali relazioni e le potenziali sinergie con altri
elementi dell’ambiente (interno ed esterno) entro il quale si intende operare.
L’acronimo S.W.O.T. deriva dalle chiavi di lettura utilizzate per la
definizione del contesto in esame: Strenghts (punti di forza), Weakness (punti
di debolezza), Oppurtunities (opportunità) e Threats (minacce).
Le prime due categorie, punti di forza e punti di debolezza, si riferiscono ai
fattori “endogeni” al contesto, a quegli elementi, cioè, che, al momento
dell’analisi, rappresentano gli elementi costitutivi del Sistema entro il quale si
opera e nei confronti dei quali il Project Manager insieme al proprio team
può esercitare un’azione diretta di governo. Ovviamente, una particolare
attenzione dovrà essere riservata in fase di analisi a quei fattori che si
ritengono idonei a determinare una condizione di vantaggio (o di svantaggio)
36
IL PROJECT RISK MANAGEMENT
competitivo. Alle altre due categorie, opportunità e minacce, vengono,
invece, ricondotti i fattori “esogeni” costituiti da quelle variabili che, pur non
fondanti del sistema produttivo (come lo sono, invece, i punti di forza e di
debolezza), sono comunque in grado di condizionarne l’evoluzione in senso
sia positivo che negativo. Proprio in quanto non costitutive dell’ambiente in
cui si opera, le possibilità di azione diretta nei loro confronti si rivelano,
generalmente, piuttosto modeste. Tuttavia, una chiara definizione delle
rispettive peculiarità, oltre che delle presumibili modalità di evoluzione e
della dimensione dell’impatto che potrebbero determinare sul progetto,
possono suggerire al Project Manager l’adozione di misure atte a prevenirne,
o, quantomeno a ridurne i prevedibili effetti negativi e/o ad ampliarne le
auspicabili ricadute positive [44].
Checklist
Gli sforzi per semplificare l’identificazione dei rischi e per minimizzare il
lavoro di chi svolge questa funzione, conducono spesso all’uso di checklist
contenenti rischi standard rilevati in precedenti progetti o che abitualmente
sorgono in un particolare contesto. Le checklist sono rapide da utilizzare, e
forniscono utili guide in campi in cui l’organizzazione ha una certa
esperienza, particolarmente per progetti che sono standard o routinari.
Spesso, le checklist sono parte delle procedure e della documentazione di
assicurazione della qualità dell’organizzazione. Come già detto, le checklist
possono essere valide per attività di routine, ma possono essere il maggior
handicap per progetti non standard o unici. Infatti, quando un progetto non
assomiglia a nessun altro di quelli di cui l’organizzazione si è occupata
prima, allora una checklist può fornire un vincolo al pensiero creativo,
precondizionando le attività di quelli coinvolti e bloccando l’identificazione
dei rischi che vanno al di là di quelli nella lista, così che aspetti unici non
vengono stimati a pieno come necessario [14]. Per progetti che coinvolgono
37
IL PROJECT RISK MANAGEMENT
nuove caratteristiche, quindi, un approccio di brainstorming è raccomandato
inizialmente, con checklist riservate per stimolare le sessioni di
brainstorming, rielaborando il processo di identificazione e assicurando che
problemi non conosciuti vengano fuori. Simili commenti portano ad usare
l’esperienza di precedenti progetti come guida per generare le liste dei rischi.
Diagrammi Causa/Effetto
Il diagramma causa-effetto è applicato per considerare tutte le cause (input),
potenziali o reali, che esercitano un effetto sulle azioni (output). In situazioni
dove le cause non sono ovvie, il diagramma di causa-effetto costituisce un
efficace strumento per la loro individuazione. E’ un modo estremamente
organizzato e visivamente efficace per enumerare le idee, giungere a
conclusioni in merito agli effetti, evidenziare gli aspetti più importanti
riguardo le azioni. Nonostante questo grafico possa essere usato
individualmente, la qualità principale del diagramma causa-effetto è la sua
caratteristica di stimolare le discussioni di gruppo, incoraggiando la
partecipazione degli attori interessati, e completando la conoscenza condivisa
di ciascun membro del team. I passaggi per la costruzione del diagramma
generalmente sono: la definizione dell’effetto, la specificazione delle
tipologie delle cause più importanti e l’identificazione delle possibili cause
previste per ogni tipologia. Quanto più dettagliati sono i diagrammi di causaeffetto, tanto più efficaci essi saranno nell’aiutare il management nella
soluzione del problema [58].
Tecniche reticolari
Nella individuazione dei singoli elementi critici, secondo l’Analisi
Reticolare, è possibile guardare “in avanti” (“forward chaining”), partendo
dalla elencazione delle situazioni che si possono presentare con una certa
38
IL PROJECT RISK MANAGEMENT
probabilità alla ricerca dei possibili danni arrecati da queste al progetto,
oppure “all’indietro” (“backward chaining”), partendo dalle conseguenze
indesiderate alla ricerca delle situazioni che le possono generare [44].
Mappa Cognitiva del Territorio
Si tratta di un sociogramma nel quale si rappresentano in modo grafico e
testuale i diversi “portatori d’interesse” del progetto con le relative relazioni
che li caratterizzano. Le linee di connessione possono essere diversificate in
base alla loro criticità nota o presunta. La stesura del sociogramma permette
di ottenere più vantaggi:
•
non si rischia di trascurare soggetti legittimati ad essere considerati;
•
l’analisi delle interdipendenze porta ad evidenziare le cosiddette
“relazioni pericolose” che generano rischiosità per il progetto;
•
la mappa cognitiva può aiutare ad applicare l’analisi del campo di forze
sugli obiettivi progettuali (forze a favore – forze contro) [17].
Il Diagramma di Contesto
Il diagramma di contesto è uno strumento grafico di forma circolare che serve
a stimolare la ricerca degli elementi di criticità che possono affliggere il
progetto soprattutto, ma non esclusivamente, in rapporto alla sua relazione
con il contesto esterno: l’ambiente cioè nel quale il progetto deve vivere nel
modo più armonico possibile. Il grafico è diviso in zone che rappresentano
l’intersezione tra due modalità diverse di sezionamento del cerchio che sono
gli spicchi e le corone circolari. All’interno delle varie zone vengono
collocati gli elementi di criticità che possono essere di due tipi: i fattori ed i
soggetti. I fattori sono entità inanimate senza facoltà di decisione o azione.
Essi possono essere eventi, circostanze, condizioni, oggetti, configurazioni,
informazioni o altro ancora. Sono caratterizzati dal fatto che possono arrecare
39
IL PROJECT RISK MANAGEMENT
problemi e danni (ma anche vantaggi se ben gestiti) al progetto stesso.
Esempi di fattori sono l’esistenza di una regolamentazione, la disponibilità di
denaro, ecc.. I soggetti, invece, sono entità che hanno facoltà di compiere od
omettere azioni rilevanti per la riuscita del progetto. I soggetti possono essere
persone, unità organizzative e persino sistemi di elaborazione delle
informazioni. Esempi di soggetti sono la concorrenza, l’utente finale, il
consulente, un sistema esperto.
Gli spicchi del diagramma di contesto rappresentano le classi in cui è
possibile ricercare i vari elementi critici. Esse sono, ad esempio, la società, la
politica, le leggi/norme, l’economia, la tecnologia, la logistica, la geografia,
le strategie, l’organizzazione, le competenze. La lista non è esaustiva e se
necessario è possibile definire ed usare nuove classi di riferimento. Tali
classi, poi, non devono essere vissute come un ostacolo all’uso dello
strumento quanto un vantaggio. Non è utile invece, una volta che un certo
elemento sia apparso alla coscienza, spendere più tempo del necessario a
cercare di collocarlo nel giusto spicchio. Vi sono molti elementi, infatti, che
potrebbero essere a cavallo di una o più classi contemporaneamente. Ciò che
importa è l’essere riusciti a tirarli fuori dal regno dell’oblio e non dove li si
debba collocare nel disegno.
E’ importante poter attribuire ad ogni elemento critico individuato un grado
di controllabilità che deriva dalle cosiddette capacità del progetto. Si tratta
del terzo elemento del diagramma di contesto: le corone circolari. Tre sono
le possibilità previste benché anche qui vi sia una gradazione che va dal nero
al bianco attraverso molti grigi:
•
Controllo: il progetto ha la padronanza completa dell’elemento
potendone determinare il comportamento in modo diretto cioè senza
intermediari. Si dice in questo caso che il progetto (inteso come il Project
Manager e le persone che sono considerabili organiche al team di lavoro)
può intervenire sul fattore o sul soggetto impedendo la manifestazione
del relativo problema o riportandolo ad una situazione di innocuità.
40
IL PROJECT RISK MANAGEMENT
•
Considerazione: il progetto non esercita alcun tipo di controllo
sull’elemento ma ne subisce i condizionamenti. In questo caso il progetto
non è in grado di esprimere azioni che permettono di modificare il fattore
o il soggetto in questione alla cui manifestazione del relativo problema
non possiamo opporci. Questo però non significa che non siamo in grado
di annullare gli effetti negativi del problema, solo che non possiamo agire
sull’elemento e dunque siamo costretti ad agire sul progetto stesso. Se
non si può adattare l’ambiente alle proprie necessità si adatteranno le
proprie capacità all’ambiente. Si tratta, allora, di scegliere strategie
fortemente adattative piuttosto che trasformative del contesto.
•
Influenza: il progetto può esercitare solo un’influenza indiretta
sull’elemento e con esiti incerti. Non siamo sicuri di riuscire a modificare
il fattore o influenzare il soggetto: stimiamo cioè il 50% di probabilità di
riuscita ed il 50% di insuccesso. Ancora una volta questo non significa
che non siamo in grado di fare nulla: possiamo invece scegliere una
strategia di comportamento per metà adattativa e per metà trasformativa.
Questa situazione è intermedia alle due estreme presentate prima.
Si potrebbe pensare che il rischio di progetto sia proporzionale a quanti
elementi sono nella zona della considerazione rispetto al totale ma non è così.
Infatti l’assegnazione di un elemento critico ad una capacità o all’altra non
aumenta ne’ diminuisce la sua probabilità di accadimento e neppure il danno
che esso può provocare, cioè in definitiva il suo grado di rischiosità. Il rischio
globale, invece, sarà in qualche modo proporzionale all’insieme degli
elementi individuati, indipendentemente dalla loro collocazione rispetto
all’area di influenza [17].
Il Risk Assessment
Dopo aver identificato le particolari unità di rischio ritenute più significative
per lo specifico progetto, e dopo averne descritto tutte le prevedibili
41
IL PROJECT RISK MANAGEMENT
conseguenze, prima di ricercare le condizioni che possono contrapporsi agli
eventi responsabili del loro insorgere, occorre procedere alla valutazione
degli effetti attesi [67]. Il dimensionamento della reale portata delle
conseguenze ipotizzate viene, di norma, effettuato con l’ausilio di tecniche
diversificate: a seconda che la valutazione riguardi aspetti di natura
economico-finanziaria, o sia rivolta alla determinazione delle ricadute
derivanti da slittamenti temporali, o, ancora, sia mirata a stabilire se il
progetto, nel suo complesso, presenta un’alta probabilità di successo (o di
fallimento), si possono applicare metodologie differenziate. In particolare,
relativamente alla valutazione delle ricadute conseguenti al concretizzarsi
degli eventi rischiosi negativi (minacce), si ricorre nella maggior parte dei
casi all’utilizzo delle tecniche riportate nella tabella 3.
Tabella 3: Il processo di Risk Assessment [17]
INPUT
• Informazioni sul
progetto:
¾ Descrizione del
problema
¾ Descrizione del contesto
¾ Obiettivi del progetto
TECNICHE E
STRUMENTI
Rischi di natura
economica-finanziaria
• Matrice di Contesto
• Risk Exposure Matrix
• Teoria delle decisioni
• Analisi
F.M.E.A./F.M.E.C.A.
¾ Requisiti del progetto
¾ Vincoli e condizioni
• Analisi F.T.A.
Slittamenti temporali
¾ Soggetti coinvolti
¾ Descrizione soluzione
•
Analisi what-if
¾ Risorse assegnate
•
Metodo Montecarlo
¾ Piano generale di lavoro
Database
• Indice di auto
determinazione
• Risk
Management
Database
• Risk Assessment
Report
SKILL
NECESSARI
• Capacità previsionali
• Capacità analitiche
• Capacità descrittive
• Capacità
comunicative
interpersonali
• Esperienza
del
contesto applicativo
• Conoscenza
delle
tecniche specifiche
Successo/insuccesso
• Informazioni storiche
• Risk Management
OUTPUT
globale
•
Analisi S.W.O.T.
•
Expert Judgments
Nel seguito verranno descritte brevemente le metodologie elencate, ponendo
l’accento su quelle caratteristiche che rendono ciascuna particolarmente
adatta in determinate circostanze.
42
IL PROJECT RISK MANAGEMENT
Il dimensionamento della reale portata delle conseguenze di natura
economico-finanziaria ipotizzate può essere effettuato con modalità differenti
a seconda che si adotti un approccio di tipo meramente qualitativo o si
ricorra all’applicazione di un criterio rigorosamente quantitativo: nel primo
caso il risultato dell’analisi consiste in una classificazione della rilevanza
delle conseguenze dannose mentre, nel secondo, si perviene al puntuale
dimensionamento monetario generato dalle stesse.
Matrice di Contesto
La Matrice di Contesto è uno degli strumenti utilizzabili nell’ambito
dell’approccio qualitativo. Consiste nella trasposizione tabellare del
Diagramma di Contesto circolare introdotto precedentemente ed è finalizzata
a valutare, oltre al grado di rischiosità globale, anche il livello generale di
controllabilità che il Project Manager e il suo staff sono in grado di esercitare
sullo specifico progetto [44]. Si tratta di rendere righe gli elementi (fattori e
soggetti) e colonne le capacità. Le Classi, invece, possono essere
rappresentate da raggruppamenti di righe (tutte e sole quelle corrispondenti
agli elementi di una certa classe). All’interno degli incroci tra un elemento di
una classe e la capacità di riferimento corrispondente si può scrivere un voto.
Naturalmente ogni riga avrà un solo incrocio con le colonne che sia
valorizzato
da
un
numero
in
quanto
un
elemento
non
può
contemporaneamente appartenere a più Capacità (Controllo, Influenza o
Considerazione). Tale voto esprimerà il giudizio circa il valore atteso del
danno (probabilità di manifestazione moltiplicata per l’entità del danno
conseguente) che l’elemento critico potrebbe arrecare al progetto se lasciato
libero di agire incontrastato. E’, in sostanza, un voto sulla pericolosità di ogni
particolare elemento rispetto alla riuscita del progetto. I voti possono essere
assegnati su una scala che assume valori da 1 a 10 dove 1 rappresenta il
minimo impatto (un incidente marginale) e 10 il massimo impatto (il
43
IL PROJECT RISK MANAGEMENT
fallimento completo del progetto). E’ consigliabile giungere a tale voto dopo
aver stimato separatamente la probabilità di occorrenza (da 0 a 1) dell’evento
ed il suo impatto in caso di manifestazione (da 1 a 10). Nel fare questa prima
valutazione (Rischio Incondizionato) occorre sforzarsi di non considerare le
possibili contromisure che si possono adottare per mitigare il rischio in
quanto questo sarà espressamente oggetto della seconda valutazione (Rischio
Residuo). E’ possibile osservare come già la numerosità di determinati indici
con valori elevati fornisce un’utile indicazione sulla rischiosità del progetto
in esame. Una volta effettuata la votazione è possibile sommare i voti per
colonna ottenendo tre valori: il totale del controllo (X), quello dell’influenza
(Y) e quello della considerazione (Z). Si può quindi calcolare l’Indice di
Autodeterminazione (Self Determination Index) come segue :
Si tratta di un indice percentuale che assume valori da 0 a 100 e che indica il
grado di auto- o etero- determinazione del progetto. Un indice prossimo a 0
indica che il progetto (eterodeterminato) non è in grado di modificare in
alcun modo gli elementi critici che influenzano in misura maggiore la riuscita
del progetto ma può ad essi reagire adattandosi: esprimendo cioè azioni
introverse, rivolte all’interno del progetto stesso. Un indice prossimo a 100
indica, invece, che il progetto (autodeterminato) è in grado di modificare
tutto ciò che è rilevante ai fini del suo successo e quindi adotterà ed
esprimerà soprattutto comportamenti trasformativi del contesto, cioè azioni
estroverse. Il motivo per cui al valore X si somma anche metà del valore Y
deriva dal fatto che si presuppone una probabilità del 50% di successo nella
capacità di intervento indiretta sull’elemento. Questo equivale ad affermare
che metà dei punti della zona di influenza può essere sommato al controllo e
metà alla considerazione. L’Indice di Autodeterminazione non è, quindi, un
indicatore globale del rischio perché esprime, invece, un rapporto tra due
classi di rischio, il rischio endogeno (zona del controllo) ed il rischio esogeno
44
IL PROJECT RISK MANAGEMENT
(zona della considerazione). Quale dei due sia preferibile è però impossibile
da dire: dipende dalle strategie di risposta che si riesce di volta in volta ad
elaborare. L’Indice di Autodeterminazione è invece un indicatore molto forte
del grado di flessibilità ed adattabilità che bisogna incorporare nel progetto
perché possa avere successo o, se vogliamo, del grado di potenza che il
progetto ritiene di avere. Il valore dell’indice introdotto suggerisce
indicazioni gestionali molto precise atte a favorire i diversi tipi di
comportamento necessari. Ad esempio un progetto con un indice basso deve
adottare scelte che favoriscono la flessibilità e che possono consistere in un
contratto tra le parti aperto, in un team facilmente riconfigurabile, in un
comitato di coordinamento con gli utenti in esso presenti, in un budget
flessibile, nel supporto dell’alta direzione etc. E’ possibile calcolare dei sottoindici di autodeterminazione per classi di elementi in modo da avere una
visione parziale delle aree di maggior auto- od etero-determinazione. I diversi
indici potranno essere rappresentati su un diagramma per avere un’idea
immediata delle aree di scopertura e di copertura del controllo. Venendo,
invece, alla determinazione del rischio generale si può affermare che una sua
analisi rigorosamente matematica risulta inappropriata a questo ambito in
quanto sono troppe le variabili soggettive in gioco. Esistono però alcune
regole empiriche per determinare il livello di rischio complessivo a partire
dai singoli elementi critici di base e dai loro voti.
E’ opportuno ricordare che la valutazione del rischio e di conseguenza l’uso
degli strumenti indotti è dinamica e non statica. I voti assegnati ai vari
elementi critici come la stessa loro natura cambiano col passare del tempo ed
in funzione delle scelte gestionali attuate cioè delle strategie di riduzione del
rischio. Il Diagramma di Contesto, la Matrice di Rischio e l’Indice di
Autodeterminazione sono fotografie del progetto scattate ad un certo istante
che possono non rappresentare più la realtà ad un istante successivo. Ad
esempio un progetto che alla prima analisi appare etero determinato, dopo un
opportuno intervento del Top Management potrebbe aumentare il suo grado
45
IL PROJECT RISK MANAGEMENT
di potenza e divenire autodeterminato. Naturalmente ci si aspetta che la
valutazione del rischio di progetto sia influenzata dall’attuazione del piano di
azione RMP e che quindi si possa parlare di una valutazione di rischio
precedente ed una successiva all’implementazione del piano stesso. Può
essere utile o necessario, dunque, derivare il Diagramma di Contesto, la
Matrice di Rischio, l’Indice di Autodeterminazione ed il livello di rischio
generale sia prima che dopo la definizione del piano di gestione dei rischi
RMP. Il rapporto tra il totale dei voti della matrice di rischio dopo e prima
della stesura del piano d’azione specifico potrà essere considerato un
indicatore di massima dell’efficacia presunta del piano stesso.
Se si definisce, dunque, l’Indice di Efficacia del Piano di Gestione del
Rischio (Risk Management Plan Effectiveness Index) come il valore:
allora tanto maggiore sarà l’RMPEI tanto migliore sarà la capacità di
rispondere agli elementi di criticità. Un valore pari a 30, ad esempio,
significherà che il grado di efficacia nella riduzione del rischio è del 30%
cioè si stima di riuscire a ridurre del 30% il Rischio Incondizionato lasciando
un rischio residuo pari al 70% del Rischio Incondizionato [17].
Risk Exposure Matrix
Per effettuare il dimensionamento della portata delle conseguenze
economico-finanziarie dannose ipotizzate a fronte del reale accadimento
degli eventi rischiosi precedentemente individuati si può ricorrere all’utilizzo
della Matrice di Esposizione al Rischio che può essere elaborata seguendo
un approccio sia qualitativo che quantitativo. In entrambi i casi, la matrice
contiene nelle colonne la probabilità di accadimento e, nelle righe, l’impatto
atteso ed è, pertanto, possibile definire una specifica “soglia di attenzione”
che definisce il livello di esposizione al rischio ritenuto “significativo”.
46
IL PROJECT RISK MANAGEMENT
Ciascun evento rischioso situato nella soglia di attenzione richiederà, in corso
d’opera, un presidio più attento da parte del project manager responsabile. Se
si adotta un approccio di tipo qualitativo, i singoli intervalli di valore, per
l’impatto atteso e per la probabilità di accadimento, vengono definiti
attraverso una scala “aggettivale”.Pressmann ha fornito un modello per la
variabile impatto [54]. Il passo successivo consiste nel fissare la scala di
valori relativa al livello di esposizione al rischio e nello stabilire, infine, i
criteri di confluenza in base ai quali associare a ciascuna casella della matrice
il corrispondente livello di esposizione, ottenendo, in questo modo, una
ripartizione della matrice in diversi settori, ciascuno caratterizzato da un
differente grado di rischiosità. Resta solo da fissare, a questo punto, il settore
della matrice delimitato dalla soglia di attenzione. Alternativamente, si
potrebbe decidere di associare ad ogni intervallo un valore numerico,
riportare in ciascun quadrante della matrice il prodotto tra i rispettivi indici e
definire un valore dell’indice di rischio che delimita la soglia di attenzione.
All’approccio di tipo qualitativo si può, forse, imputare un margine eccessivo
di discrezionalità soggettiva. Poiché l’obiettivo principale dell’applicazione
della Matrice di Esposizione è quello di evidenziare gli eventi rischiosi che,
data la loro elevata criticità, necessitano di un particolare presidio in corso
d’opera, tale scopo è raggiunto nel momento in cui vengono correttamente
interpretati i livelli minimi della “soglia di attenzione”. Ma, almeno per
quanto riguarda la variabile “impatto”, l’opinabilità del giudizio individuale
non riguarda tanto la collocazione o meno dell’evento al di sopra o al di sotto
della “soglia di attenzione”, quanto, piuttosto, il suo posizionamento
all’interno del settore matriciale delimitato dalla stessa. Pertanto,
un’eventuale differente classificazione del medesimo evento effettuata da due
valutatori diversi non inficerebbe in alcun modo il risultato in quanto l’evento
verrebbe comunque posizionato da entrambi nella zona matriciale ad alto
rischio. Conclusioni analoghe, anche se forse derivanti da logiche un po’
meno stringenti, possono essere ripetute relativamente alla variabile
47
IL PROJECT RISK MANAGEMENT
probabilistica. La mancanza di altrettanto rigore deriva dal fatto che, in
questo caso, due eventi che, in assoluto, presentano la stessa aliquota
percentuale di probabilità di accadimento potrebbero dover essere inseriti, in
funzione della propria specifica natura, in differenti intervalli della scala
aggettivale. Esistono diverse formule matematiche in letteratura atte a questo
scopo. Per superare definitivamente l’incertezza connessa al margine di
arbitrarietà che comunque caratterizza l’approccio qualitativo, e allo scopo di
rendere, perciò, assolutamente inopinabile il risultato dell’elaborazione della
Matrice di Esposizione al Rischio, sii può, alternativamente, ricorrere ad
un’approccio di tipo quantitativo che consiste nell’attribuzione a ciascuna
delle due scale aggettivali già utilizzate nell’approccio qualitativo di
altrettante metriche di riferimento che definiscono numericamente gli estremi
dei relativi intervalli. Se con BAC (Budget At Completion) si definisce
l’ammontare totale dei costi preventivi del progetto, si potrebbe attribuire ai
singoli intervalli relativi alla variabile “impatto” diverse percentuali di danni
economico-finanziari. Analogamente per la variabile probabilità di
accadimento si potrebbe applicare una metrica di riferimento. Se l’approccio
di tipo quantitativo assicura l’inopinabilità del risultato finale, la sua
applicazione comporta, in genere, un notevole dispendio di tempo (e, quindi,
di costo) che, almeno in qualche caso, non può ritenersi del tutto secondario.
I
calcoli
che
correttamente)
occorre
svolgere
l’ammontare
delle
per
dimensionare
conseguenze
esattamente
(e
economico-finanziarie
conseguenti all’accadimento dei singoli eventi rischiosi, infatti, non sono
sempre di facile elaborazione (e di incontestabile risultato), soprattutto per
quanto riguarda la valutazione monetaria dei danni indiretti e di quelli
consequenziali. Qualora si decidesse comunque di ricorrervi, si potrebbe
disporre di un indice capace di esprimere il livello di esposizione al rischio
presentato dal progetto nel suo complesso. Se con pi si indica la probabilità di
accadimento dell’i-esimo evento rischioso, e con ei l’entità economico-
48
IL PROJECT RISK MANAGEMENT
finanziaria del danno conseguente al suo effettivo accadimento, è possibile
definire il prodotto tra le due grandezze:
come il valore monetario atteso (Expected Monetary Value) dal
concretizzarsi dell’i-esimo evento rischioso. E’ possibile, allora, definire il
livello di esposizione REL (Risk Exposure Level) presentato dal progetto
come:
La determinazione del REL si dimostra di una certa utilità sia che venga
effettuata già nella fase di proposal (in quanto consente di confrontare il
livello di rischiosità relativo a progetti diversi, e fornisce, quindi un’ulteriore
parametro di valutazione della convenienza a presentare o meno l’offerta
commerciale), sia che venga effettuata a contratto ormai acquisito (in quanto
aiuta il Project Manager a definire la tattica realizzativa più idonea a
modificare il particolare contesto operativo che si fosse rivelato
particolarmente rischioso) [15].
Teoria delle Decisioni e Decision Tree
Il ricorso alle metodologie e alle tecniche sviluppate nel contesto della
Teoria delle Decisioni risulta particolarmente utile in sede di quantificazione
dei rischi di natura economico-finanziaria e fornisce al valutatore un valido
supporto metodologico che gli consente di confrontare l’efficacia associata a
differenti alternative decisionali. Un generico processo decisionale consiste
in un procedimento logico che si sviluppa attraverso una serie di passi
successivi in corrispondenza di ognuno dei quali possono essere assunte
decisioni alternative che, in funzione di differenti circostanze esterne,
producono un guadagno (o una perdita) monetaria. Il primo passo del
processo consiste nell’individuazione delle “n” differenti situazioni (Stati del
49
IL PROJECT RISK MANAGEMENT
Sistema) verso le quali il valutatore ritiene possa evolvere il contesto
operativo entro il quale verrà sviluppato il progetto: Sj (j=1,….,n). Il passo
successivo consiste nella determinazione delle “m” decisioni che il valutatore
ritiene di poter assumere a fronte delle diverse possibili scelte alternative che
si presenteranno in corso d’opera: Di (i=1,…,m). A fronte di ogni possibile
alternativa (e in corrispondenza di ciascuno Stato futuro del Sistema) occorre,
poi, valutare l’entità monetaria delle conseguenze economico-finanziarie
determinate dall’assunzione della specifica decisione. Il guadagno (o la
perdita) stimato come conseguenza della i-esima decisione assunta nel jesimo Stato viene rappresentato dalla: eij (i=1,…,m ; j=1,….,n). Con questi
dati a disposizione è possibile costruire la Matrice dei guadagni e delle
perdite (Pay-off Matrix). L’analisi ragionata dei valori contenuti nella matrice
consente di individuare la decisione che comporta il guadagno massimo (o,
comunque, la perdita più contenuta). E’ bene tener presente, però, che le
singole decisioni possono essere assunte in condizioni di certezza, di rischio
o di incertezza per quanto concerne il concretizzarsi di ogni singolo Stato del
Sistema. Nel primo caso, esiste un unico Stato futuro del Sistema. In questo
caso la matrice dei pay-off sarà costituita da un’unica colonna, mentre la
decisione più conveniente è quella in corrispondenza della quale si rivela
massimo l’ammontare del guadagno stimato (o minimo l’importo della
perdita). Per quanto riguarda decisioni assunte in condizioni di rischio, si è in
presenza di più possibili Stati futuri del Sistema. Per tale motivo, ad ogni
Stato futuro, può essere associata una particolare p(Sj) (con j=1,..,n;
) che indica la probabilità stimata del suo manifestarsi. Per
individuare la più conveniente tra le “m” possibili alternative decisionali è
possibile ricorrere al “criterio a priori” suggerito da Bayes secondo il quale
la decisione raccomandata è quella che rende massimo il guadagno atteso nel
rispetto della distribuzione delle probabilità degli Stati futuri del Sistema:
(i=1,..,n)
dove:
50
IL PROJECT RISK MANAGEMENT
in cui il valore monetario atteso EMVi a fronte del complesso dei risultati
ipotizzati a seguito della particolare i-esima decisione è ottenuto come
somma degli Expected Monetary Value calcolati per ciascun risultato
possibile.
La Teoria delle Decisioni trova nell’ “Albero delle Decisioni” (Decision
Tree) una efficace rappresentazione grafica che, oltre a rendere di immediata
e agevole comprensione il particolare processo logico seguito dal decisionmaker, si dimostra particolarmente utile per evidenziare le alternative ottimali
nel contesto di processi decisionali particolarmente complessi.
Per le decisioni da assumersi in condizioni di assoluta aleatorietà non
esistono regole universali alle quali poter ricorrere in modo indiscriminato,
ma soltanto valutazioni di convenienza che suggeriscono, in ogni circostanza,
come decisione “ottimale” quella che rappresenta il punto di equilibrio tra
tendenze tra loro contrastanti che dipendono dalle caratteristiche personali e
dalle preferenze individuali del soggetto che deve decidere. Quando non
esistono informazioni attendibili circa le modalità con le quali evolveranno le
condizioni al contorno, e, pertanto, risulterebbe del tutto irragionevole
associare una specifica probabilità di effettiva realizzazione a ciascuno degli
Stati futuri del Sistema (che si sono, comunque, ipotizzati), è possibile
applicare una serie di differenti criteri che suggeriscono le scelte decisionali
più vantaggiose. Primo fra tutti è il Criterio del MiniMax che indica di
assumere la decisione in corrispondenza della quale risulta massimo il
minimo valore dei Pay Off .
Tale criterio, quindi, suggerisce di accontentarsi del risultato migliore tra gli
esiti minimi che le differenti decisioni potrebbero generare. Atteggiamento
51
IL PROJECT RISK MANAGEMENT
decisamente ottimistico per il Criterio del MaxiMax, che viceversa
suggerisce di assumere la decisione in corrispondenza della quale risulta
massimo il massimo valore dei Pay Off.
Tra i due si pone il Criterio di Laplace, che, ponendo equiprobabili i futuri
Stati del Sistema, consiglia di assumere la decisione in corrispondenza della
quale risulta massimo il corrispondente Expected Monetary Value.
Analisi F.M.E.A. e F.M.E.C.A.
La metodologia F.M.E.A. (Failure Modes and Effects Analysis) è stata
sviluppata alla fine degli anni ’40 dalle forze armate statunitensi per
catalogare i possibili eventi dannosi sulla base dell’impatto che questi
potevano determinare sul successo delle missioni e sulla sicurezza fisica delle
truppe. Attualmente viene comunemente impiegata da numerosi Sistemi di
Qualità aziendali, e, in particolare, da quelli che utilizzano la metodologia
“Sei Sigma”, ma la sua applicazione può trovare un impiego efficace anche
nella valutazione dei rischi di progetto. La metodologia consiste, in breve,
nella scomposizione del prodotto o processo nelle sue componenti
fondamentali, nell’individuazione, per ciascuno di essi, di tutti gli eventi
dannosi che possono comportarne il cedimento, il guasto o il mancato
funzionamento dello stesso o di altri componenti e l’individuazione delle
contromisure più efficaci. Se si intende far evolvere l’analisi qualitativa
ottenuta applicando la metodologia F.M.E.A. verso un’analisi di tipo anche
quantitativo, si può ricorrere all’analisi F.M.E.C.A. (Failure Modes Effects
52
IL PROJECT RISK MANAGEMENT
and Criticality Analisys) che dimensiona le singole criticità classificando gli
specifici eventi dannosi secondo un indice che tiene conto della probabilità di
accadimento, della severità delle conseguenze dannose e della più o meno
ampia possibilità che i sistemi di controllo dimostrano nella rilevazione del
malfunzionamento. A fronte di ciascun evento dannoso si può calcolare il
relativo RPI (Risk Priority Index), in base alle quale stabilire una scala di
priorità di intervento, definito dalla:
dove:
S = impatto economico;
P = probabilità di accadimento;
C = possibilità di rilevazione da parte dei meccanismi di controllo.
A ciascuno dei tre fattori S, P, C viene assegnato un punteggio compreso nel
range 1-10, facendo attenzione ad utilizzare scale non lineari in modo da
garantire una corretta ponderazione dei tre indicatori. In funzione dei valori
singolarmente assunti, è possibile stabilire una scala di priorità di intervento.
Analisi F.T.A.
A differenza dell’analisi F.M.E.A., che procede dal “particolare” (analisi dei
guasti delle singole componenti) verso il “generale” (guasto dell’intero
processo), la F.T.A., al contrario, indaga sulle relazioni di causa-effetto che
legano i singoli eventi al complesso di fattori che possono determinarne
l’insorgenza, percorrendo, in questo modo, una sorta di cammino all’indietro.
Nata intorno agli anni ’60 presso i laboratori della Bell Telephone, la
metodologia F.T.A. (Fault Tree Analysis) ha trovato, in questi ultimi anni, un
largo impiego sia nel mondo manifatturiero sia in quello dei servizi. Il faulttree consiste in una rappresentazione grafica delle catene causali che possono
determinare l’evento dannoso. Se il processo di analisi è stato condotto in
modo esaustivo, l’esame del grafico evidenzia tutti i percorsi casuali che si
53
IL PROJECT RISK MANAGEMENT
possono originare nel contesto del sistema in osservazione, consentendo al
decision maker di prendere in considerazione quelli che considera più
“pericolosi” e che, pertanto, prioritariamente necessitano dell’attivazione
delle opportune contromisure. D’altra parte, va sottolineato, che la
costruzione di un fault tree necessita di una solida esperienza da parte del
redattore, di una profonda conoscenza del sistema e del processo, e può
richiedere, inoltre, un considerevole lasso di tempo per essere sviluppata.
Tecniche di Simulazione
Nel contesto del Project Risk Management, per “simulazione” si intende
l’elaborazione di un modello capace di tradurre il danno provocato
dall’eventuale concretizzarsi del singolo evento rischioso nell’effetto che
l’insieme degli eventi individuati potrebbe produrre sugli obiettivi generali
del progetto. Per stabilire, ad esempio, la probabilità che i costi consuntivi di
una commessa si discostino da quelli di budget di una determinata aliquota
percentuale si può ricorrere all’applicazione del Metodo Monte Carlo. Per
esso una possibile definizione risulta la seguente: il metodo di Monte Carlo
consiste nella ricerca della soluzione di un problema che viene rappresentata
come parametro di una ipotetica popolazione e la cui stima viene effettuata
esaminandone un campione ottenuto tramite la generazione di numeri
casuali.
Alle tecniche di simulazione si può fare riferimento anche quando ci si
appresta a valutare i rischi collegati alla variabile temporale. In linea
generale, tali tecniche consistono nella verifica degli effetti determinati sulla
durata complessiva del ciclo realizzativo (o su quella di fasi intermedie) da
ipotesi di lavoro alternative applicate ad un modello rappresentativo delle
particolari modalità di espletamento. Il modello più frequentemente utilizzato
è costituito dal reticolo del progetto che rappresenta il piano operativo
costruito dal Project Manager in sede di stesura del preventivo esecutivo.
54
IL PROJECT RISK MANAGEMENT
Tale modello, ottenuto a conclusione della fase di pianificazione iniziale del
progetto, si basa sulla considerazione della durata delle singole attività, delle
relazioni di dipendenza da altre attività, dal calendario di lavoro e da
eventuali date imposte.
Una prima possibilità di valutazione del rischio temporale è rappresentata
dall’applicazione delle differenti tecniche di risoluzione reticolare [64]: la
stima non deterministica della durata delle singole attività concessa dal
PERT (Program Evaluation and Review Technique), ad esempio, o
l’indeterminazione dei cammini, conseguente alla possibilità di rappresentare
sequenze operative alternative, gestita dal GERT (Graphical Evaluation and
Review Technique), anche se non direttamente catalogabili come “tecniche di
simulazione”, costituiscono, comunque, entrambe strumenti idonei a trattare
il fattore “incertezza”, e a fornire, di conseguenza, una valutazione
probabilistica dell’entità globale del rischio connesso con il mancato rispetto
dei tempi di realizzazione contrattuali. Il ricorso a queste particolari tecniche
di risoluzione reticolare risulta, d’altra parte, poco agevole e comunque
sconsigliabile, data la poca dimestichezza e la scarsa conoscenza che, almeno
in generale, può essere vantata nei loro confronti. Evitando, pertanto, la loro
applicazione, ed effettuando quindi la time analysis col consueto metodo
CPM (Critical Path Method), che applica un criterio deterministico secondo il
quale ad ogni attività compresa nel reticolo viene assegnata un’unica durata
che viene considerata “certa”, a livello reticolare possono comunque essere
considerate differenti ipotesi alternative che sostanzialmente possono
riguardare l’allocazione delle risorse, le sequenze operative, le strategie di
implementazione e i percorsi realizzativi.
Metodo S.W.O.T.
Infine, il Metodo S.W.O.T., già introdotto precedentemente nella fase di
identificazione dei rischi, può trovare un impiego efficace anche nella fase di
55
IL PROJECT RISK MANAGEMENT
quantificazione dei rischi di progetto. Ponendo, infatti, in chiara evidenza i
fattori che possono agevolare o, al contrario, ostacolare il conseguimento
degli obiettivi temporali, qualitativi ed economico-finanziari del progetto, è
possibile orientare più efficacemente le scelte strategiche che verranno
operate in sede di pianificazione iniziale e le linee di intervento alle quali si
farà poi ricorso durante l’iter realizzativo. La lettura dei risultati dell’analisi
può schematizzata con una tabella come quella che compare in fig. 10:
Strenghts
Opportunities
Threats
Weakness
Strategia S-O
Strategia W-O
Come utilizzare i punti di
forza per sfruttare le
opportunità
Come superare i punti di
debolezza per sfruttare le
opportunità
Strategia S-T
Strategia W-T
Come utilizzare i punti di
forza per contrastare le
minacce
Come superare i punti di
debolezza per contrastare
le minacce
Figura 10: Tabella S.W.O.T.: analisi delle strategie
Nella porzione di sinistra sono evidenziati gli elementi positivi (punti di forza
e opportunità), mentre i due quadranti di destra contengono i fattori negativi
(punti di debolezza e minacce). Inoltre, i quadranti superiori sono riservati
all’esposizione delle variabili che caratterizzano il contesto nel momento in
cui viene effettuata l’analisi, mentre, quelli inferiori, si riferiscono alla
situazione che si prevede possa realizzarsi nel prossimo futuro.
E’ possibile considerare, quindi, il problema da quattro prospettive diverse (e
tra loro contrastanti) e ciò favorisce il processo decisionale volto ad
individuare le tipologie e le priorità degli interventi da operare per
ottimizzare il risultato finale [23].
Expert Judgments
La tecnica che si basa sul “giudizio emesso dagli esperti”, Expert
Judgments,
si
dimostra
particolarmente
utile
se
finalizzata
alla
56
IL PROJECT RISK MANAGEMENT
quantificazione del rischio di fallimento (o di successo) del progetto inteso
nella sua globalità. Le stime sono quasi sempre effettuate sulla base di giudizi
personali fondati sull’esperienza accumulata e solitamente espresse sotto
forma di valutazioni di tipo qualitativo. A differenza delle tecniche
caratterizzate da approcci più sistematici e rigorosi, proprio in quanto
espressione di convincimenti personali risentono fatalmente degli eventuali
pregiudizi, delle false percezioni e, più in generale, dell’emotività di colui
che li esprime. D’altra parte, la componente di “umanità” insita negli expert
judgments li fa di solito preferire a tecniche di più alto grado di
sofisticazione. Per aumentarne il livello di credibilità occorre che gli expert
judgments vengano formulati ricorrendo a metodiche che, se non scientifiche,
siano almeno sistematiche e che tendano a limitare, per quanto possibile, gli
eccessi di soggettività. Dimensionare in senso numerico la valutazione
attraverso la definizione di ben determinati parametri di riferimento
individuati all’interno della metrica prescelta, contribuisce a rendere meno
opinabile la stima effettuata, senza per questo pretendere di attribuire al
valore numerico un marchio di inoppugnabilità che risulterebbe comunque
ingiustificato. In sostanza si tratta di procedere alla stesura di un questionario
che contenga: le principali fonti di rischio, le componenti di ciascuna fonte di
rischio, le variabili che caratterizzano ciascuna componente e la metrica di
dimensionamento di ciascuna variabile. Non esistono linee-guida alle quali
attenersi nella progettazione del questionario. Un utile suggerimento potrebbe
essere quello di affidare la stesura di una prima bozza del documento ad una
consulenza esterna che, attraverso una serie di interviste agli “esperti”
aziendali e l’analisi dei dati storici relativi a progetti realizzati nel passato,
sintetizzi una prima proposta da sottoporre all’esame degli stessi esperti
precedentemente contattati. Questa prima bozza potrà essere successivamente
perfezionata in sede congiunta. La compilazione del questionario fornisce sia
il dimensionamento del rischio totale
ottenuto dalla somma dei rischi
marginali potenzialmente generabili da ogni singola componente, sia la stima
57
IL PROJECT RISK MANAGEMENT
dell’impatto che le peculiari caratteristiche dell’iter realizzativo potrebbero
determinare sui risultati economici, temporali e qualitativi finali. La
rappresentazione grafica, ottenuta per mezzo di un “diagramma radar”, dei
valori relativi ai fattori di rischio di ciascuna componente fornisce una
sensazione immediata ed incisiva del fenomeno analizzato dal momento che
l’area della superficie è immediatamente indicativa dell’entità del rischio
globale di progetto e la sua eventuale irregolarità evidenzia componenti
particolarmente critiche [44].
Il trattamento dei rischi di progetto
L’analisi condotta fino a questo momento ha permesso l’individuazione dei
soli eventi rischiosi ritenuti significativi e il dimensionamento delle relative
ricadute sul risultato finale del progetto. Il passo successivo consiste
nell’individuare la tipologia e le modalità degli interventi che, in corso
d’opera, si ritiene debbano essere attuati a fronte del reale verificarsi del
singolo evento rischioso, allo scopo di sventare le minacce, rimuovendo le
condizioni che ne potrebbero determinare l’insorgere, con l’intento di
annullare (o, quantomeno, ridurre) i danni conseguenti al loro accadimento.
Prima di passare in rassegna le differenti modalità di intervento alle quali è
possibile ricorrere al fine di contrastare le minacce che potrebbero
concretizzarsi in corso d’opera, si analizza il processo che determina la
perdita monetaria associata al reale accadimento dello specifico evento
rischioso.
Il processo di formazione del rischio si articola in una serie di passi
successivi, schematicamente rappresentati in figura 11.
Un qualsiasi evento rischioso è, per sua stessa natura, sempre legato a tre
fattori che ne possono determinare o impedire l’effettivo insorgere:
•
il rischio: inteso come pericolo teorico connaturato all’oggetto in analisi
che, proprio in quanto risulta intimamente collegato alla natura dello
58
IL PROJECT RISK MANAGEMENT
specifico
elemento,
è
del
tutto
indipendente
dalle
particolari
caratteristiche costruttive e/o strutturali di quest’ultimo;
•
le condizioni agevolanti: rappresentate dal coacervo di fattori che,. in
determinate situazioni, possono concorrere all’effettivo concretizzarsi
dell’evento e/o ampliarne le conseguenze dannose;
•
le condizioni frenanti: costituite dall’insieme dei fattori che possono
impedire l’effettivo concretizzarsi dell’evento dannoso e/o attenuare le
conseguenze.
Favoriscono l’evento e/o
amplificano effetto
Possibilità di verificarsi
evento dannoso
Impediscono l’evento e/o
attenuano effetto
RISCHIO
Condizioni
agevolanti
Condizioni
frenanti
EVENTO
Concretizzarsi eventualità
DANNO
Esito diretto e immediato dell’evento
PERDITA
MONETARIA
Manifestazione negativa del danno
Figura 11: Processo di formazione del Rischio
La condizione necessaria e sufficiente perché l’evento dannoso si concretizzi
è rappresentata dalla prevalenza delle condizioni agevolanti su quelle
frenanti: l’esito immediato e diretto è rappresentato dal danno che investe la
particolare risorsa aziendale coinvolta. La perdita monetaria è costituita
dagli effetti economico-finanziari negativi che il danno può produrre non
soltanto sulla particolare risorsa colpita, ma, più in generale, sulle modalità di
evoluzione dell’iter realizzativo dell’intero progetto.
Le conseguenze monetarie generate dal danno occorso so possono, infatti,
distinguere in:
59
IL PROJECT RISK MANAGEMENT
•
effetti diretti: rappresentati dalle spese che si devono sostenere
immediatamente per riparare il danno occorso e ripristinare le normali
condizioni lavorative;
•
effetti indiretti: costituiti dai costi che si generano nel lasso temporale
intercorrente tra il momento in cui si è verificato l’evento dannoso e
quello in cui è stata completata la riparazione del danno subito;
•
effetti consequenziali: sono quelli che si generano in momenti successivi
alla data di completamento della riparazione.
La rappresentazione schematica del processo di formazione del rischio
consente di evidenziare la correlazione esistente tra i differenti strumenti di
gestione del rischio e i singoli momenti del processo in corrispondenza dei
quali ciascuno di questi trova la propria corretta applicazione.
Per “strumenti di Risk Management” si debbono intendere tutte le azioni, i
comportamenti, le iniziative che si possono porre in atto per tentare, da un
lato, di ridurre la probabilità di accadimento degli eventi dannosi e/o,
dall’altro, di contenerne la portata dell’impatto qualora dovessero, comunque,
concretizzarsi in corso d’opera.
PROCESSO DI FORMAZIONE DEL RISCHIO
La figura 12 mostra le sei possibili tipologie di intervento:
STRUMENTI DI RISK MANAGEMENT EVENTO
1) Elusione
2) Prevenzione
DANNO
CONTROLLO
FISICO
3) Protezione
4) Assicurazione
PERDITA
MONETARIA
5) Trasferimento
CONTROLLO
FINANZIARIO
(non assicurativo)
6) Ritenzione
Figura 12: Gli strumenti del Risk Management
60
IL PROJECT RISK MANAGEMENT
1. elusione: è mirata ad escludere la possibilità di accadimento dell’evento
dannoso. Poiché, come già scritto, a qualsiasi attività operativa sono
associabili un certo numero di rischi che, in quanto connaturati con la sua
stessa essenza, sono, di fatto, ineliminabili, è evidente che l’unica via per
annullare la probabilità del loro accadimento consiste nella rinuncia ad
espletare la particolare attività;
2. prevenzione: mentre l’elusione consiste nell’eliminazione totale del
rischio ottenuta mediante la rinuncia all’espletamento dell’attività che
potrebbe originare l’evento scatenante, la prevenzione è costituita dal
coacervo di misure volte a ridurre la probabilità di accadimento degli
eventi dannosi;
3. protezione: è costituita dall’insieme di misure di sicurezza finalizzate a
contenere l’impatto economico del danno che intervengono, però,
soltanto quando l’evento rischioso si è realmente verificato: in altre
parole, la protezione interviene quando la prevenzione fallisce. La figura
13 chiarisce la differenza concettuale esistente tra prevenzione e
protezione. Le curve R1 ed R2 si riferiscono, ciascuna, a situazioni nelle
quali le situazioni di rischio, pur variando in termini di probabilità di
accadimento e di severità potenziale, si equivalgono sotto il profilo
dell’entità del rischio totale rappresentato dalla specifica situazione di
riferimento: in altri termini il passaggio dalla curva R2 alla curva R1
equivale alla diminuzione del rischio complessivo. Lo spostamento
verticale da una curva all’altra (dal punto “A” al punto “B”), mantenendo
costante la severità del danno potenziale, ma riducendone la probabilità
di accadimento, rappresenta la prevenzione, mentre la protezione (mirata
ad ottenere l’attenuazione della severità del danno, mantenendone
inalterata la probabilità di accadimento) si riferisce ad uno spostamento
parallelo all’asse delle ascisse (dal punto “A” al punto “C”).
4. assicurazione: è del tutto evidente che non è sempre possibile eliminare
tutte le cause potenzialmente responsabili del verificarsi di un evento
61
IL PROJECT RISK MANAGEMENT
dannoso. Non esiste, infatti, alcuna possibilità di totale contrasto
relativamente, ad esempio, a tutte le fonti di rischio esterne. Escludendo,
pertanto, la possibilità di rimozione delle cause che li determinano, tali
eventi dannosi possono essere efficacemente contrastati cercando di
ridurre la consistenza del prevedibile danno economico mediante il
trasferimento ad altri Enti dell’onere monetario associato al loro
accadimento, ma ciò non è sempre possibile e presenta degli
inconvenienti;
5. trasferimento (non assicurativo): per far fronte alle conseguenze
economico-finanziarie derivanti dal danno conseguente all’eventuale
accadimento dell’evento rischioso si può anche optare per una forma di
trasferimento non assicurativo, la traslazione, cioè, del rischio su soggetti
diversi da una compagnia di assicurazione ma comunque esterni sia
all’Azienda sia al ciclo realizzativo del progetto (es. subappalti), oppure
si può decidere per il ribaltamento del potenziale onere finanziario su una
controparte più o meno direttamente coinvolta nel ciclo realizzativo del
progetto;
6. ritenzione: un’altra forma di trasferimento non assicurativo è
rappresentato dalla ritenzione, che vede l’Azienda disposta ad assumersi
direttamente il rischio (o una sua quota) provvedendo al suo
finanziamento con mezzi propri. E’ fondamentale che, grazie ad
un’analisi approfondita ed esaustiva, il Project Manager raggiunga la
completa conoscenza di tutti i rischi che potrebbero minacciare i propri
progetti: in modo che non permanga un’area di ritenzione della quale
viene ignorata la presenza. Oltre alla mancata individuazione del
possibile evento rischioso, questo può accadere anche a causa di una
sottovalutazione della severità potenziale stimata a fronte del rischio o, al
contrario, di una sopravvalutazione dell’efficacia delle specifiche
contromisure che si intendono adottare. Qualora si optasse per la
ritenzione, è del tutto evidente che la stessa deve essere giustificata da un
62
IL PROJECT RISK MANAGEMENT
confronto di convenienza economica rispetto agli altri strumenti di risk
PROBABILITA’
management descritti [44].
Protezione
A
C
R2
Prevenzione
R1
B
SEVERITA’ POTENZIALE
Figura 13: Prevenzione e Protezione del rischio
Da risk a contingency
Quando si stanno valutando dei rischi “interni” relativamente ai quali è
dunque ipotizzabile l’attuazione da parte del Project Manager di azioni di
contrasto, il responsabile del progetto può scegliere se:
•
subire passivamente le conseguenze associate al concretizzarsi
dell’evenienza ipotizzata;
•
fronteggiare gli eventi responsabili della situazione rischiosa.
La prima alternativa, che prevede la ritenzione del rischio e la supina
accettazione di tutte le possibili conseguenze, potrà essere adottata soltanto
nei casi in cui le potenziali ricadute indotte sul progetto non presentino
caratteristiche di particolare criticità e neppure dimensioni economiche di
rilevante consistenza. In tutti gli altri casi il Project Manager deve attivare lo
strumento di Risk Management che ritiene più idoneo a ridurre la probabilità
di accadimento dell’evento dannoso e a contenerne, nella maggior misura
possibile, la severità potenziale associata al suo concretizzarsi.
63
IL PROJECT RISK MANAGEMENT
La fase decisionale traduce, pertanto, i rischi precedentemente individuati in
specifiche contingency di progetto, precisando, nel contempo, le azioni che si
intendono porre in atto a fronte del reale concretizzarsi di ogni singola
evenienza ipotizzata. Prima di procedere alla stesura del piano di azione, è
opportuno che il Project Manager consideri quali minacce intende
contrastare, e stabilisca, quindi, una scala di priorità che disponga in ordine di
“importanza” tutte quelle emerse in sede di individuazione dei rischi. Tale
scala va costruita in modo diverso a seconda che la fase di quantificazione sia
stata condotta con un approccio qualitativo o sia stato adottato quello
quantitativo.
Va comunque sottolineato il fatto che in tutti i contesti operativi caratterizzati
indifferentemente da:
•
una imprecisa definizione degli ambiti progettuali;
•
una marcata precarietà delle specifiche tecniche della fornitura;
•
una obiettiva impossibilità di previsione delle possibili future condizioni
al contorno;
•
la completa assenza di esperienze precedenti che siano almeno
comparabili alle circostanze attuali;
sia l’assegnazione delle priorità ai singoli eventi rischiosi, sia la scelta delle
modalità con le quali contrastarne i prevedibili effetti dannosi, vengono di
fatto affidate all’esperienza, all’abilità e alla competenza del Project Manager
[71].
Il controllo dei rischi di progetto
Durante la fase di effettiva implementazione di un qualsiasi progetto, risulta
assolutamente indispensabile procedere alla rilevazione e all’analisi critica di
quanto sta realmente avvenendo: dallo start-up delle attività operative fino
alla consegna finale dello scopo della fornitura intercorre normalmente, un
consistente arco temporale nel corso del quale l’iter realizzativo, prefigurato
64
IL PROJECT RISK MANAGEMENT
in fase di pianificazione iniziale, subisce molteplici modifiche a seguito dei
continui imprevisti che fatalmente si presentano nella variegata realtà
lavorativa. A fronte di tali imprevisti è possibile che i vincoli temporali e/o
economici relativi alle attività già espletate (o a quelle in corso di
realizzazione) vengano disattesi, con ricadute negative, più o meno
consistenti, che possono interessare anche l’intero progetto.
Proprio per questo motivo è necessario procedere, con carenza periodica, alla
valutazione dell’andamento generale del progetto al fine di misurarne, con
parametri il più possibile certificati, l’effettivo progredire. Il “controllo del
progetto” va visto, dunque, come un’azione rivolta alla ricerca dei possibili
interventi effettuabili nel periodo di tempo che ancora resta prima della
definizione conclusiva dell’iter realizzativo, al fine di far rientrare il progetto
entro i limiti temporali ed economici prefissati o, qualora gli stessi
risultassero rispettati, cercare di migliorare ulteriormente i risultati attesi.
Per risultare davvero efficace, il check di progetto, condotto dal Project
Manager con il supporto del suo team, deve articolarsi in una serie di passi
successivi che, nell’ordine, consistono sostanzialmente nella:
•
analisi degli scostamenti e delle criticità rispetto al piano di riferimento
corrente;
•
individuazione delle cause che hanno determinato tali scostamenti;
•
valutazione delle azioni correttive e dell’impatto sul progetto di possibili
varianti;
•
ripianificazione a finire con l’inclusione delle soluzioni approvate.
Tra le cause responsabili delle deviazioni dell’iter realizzativo rispetto al
modello prefigurato gli eventi rischiosi giocano un ruolo di prim’ordine [69].
Va sottolineato il fatto che, per quanto la fase di identificazione dei rischi sia
stata condotta, in sede di pianificazione iniziale, in modo minuzioso ed
approfondito, esiste sempre un’alta probabilità che non tutti gli eventi
rischiosi siano stati individuati e, di conseguenza, previsti nel Risk Plan di
progetto. Come diretta conseguenza di tale osservazione discende il fatto che
65
IL PROJECT RISK MANAGEMENT
il processo di monitoraggio dei rischi di progetto, la cui schematizzazione è
riportata in figura 14, si sviluppa in maniera differente a seconda che si
rivolga alla gestione di:
•
eventi rischiosi pianificati: in tal caso gli stessi sono già stati analizzati,
quantificati e, a fronte di ciascuno di questi, sono già state definite le
azioni di contrasto che si sono ritenute più appropriate per annullarne (o,
quantomeno, minimizzarne) gli effetti dannosi;
•
eventi rischiosi imprevisti: rappresentati da avvenimenti inattesi derivanti
da mutate condizioni al contorno determinatesi in corso d’opera o, più
PIANIFICAZIONE
INIZIALE
semplicemente, sfuggiti all’analisi condotta in fase di identificazione.
IDENTIFICAZIONE
PRESIDIO ITER
REALIZZATIVO
QUANTIFICAZIONE
Mutate condizioni al contorno
Mancata identificazione iniziale
PIANIFICAZIONE
EVENTI RISCHIOSI
IMPREVISTI
RISK PLAN
QUANTIFICAZIONE
VERIFICA REALE
ACCADIMENTO
IMPREVISTI
PIANIFICAZIONE
UTILIZZO O RECUPERO
CONTINGENCY
MODIFICA
RECUPERO
CONTINGENCY
RISK PLAN
(aggiornato)
INSERIMENTO
NUOVE
CONTINGENCY
Figura 14: Controllo dei rischi di progetto
Monitoraggio degli eventi rischiosi imprevisti
Relativamente agli eventi rischiosi che, del tutto inattesi, comunque si
presentano nella realtà operativa (e che, pertanto, non risultano inclusi nel
66
IL PROJECT RISK MANAGEMENT
Risk Plan di progetto), il Project Manager dovrà innescare il processo
generale di gestione del rischio per valutarne le possibili ricadute sul risultato
complessivo, facendo a meno della fase di identificazione, ma solo di
quantificazione e di pianificazione. Per ciascun evento, pertanto, si dovrà
procedere a:
•
valutare la severità dell’evento, dimensionandone le ricadute temporali
e/o economiche determinate sul progetto;
•
valutare la possibilità che lo stesso evento possa ripresentarsi in futuro,
stimandone, in caso affermativo, frequenza e collocazione temporale;
•
individuare le possibili contromisure, verificandone la convenienza
economica in rapporto al danno;
•
dimensionare il costo aggiuntivo derivante dall’applicazione delle
contromisure individuate;
•
verificare
la
possibilità
di
sostenere
tale
costo
(che
andrà,
inevitabilmente, ad erodere il margine di contribuzione del progetto);
•
se possibile, porre in atto le contromisure definite;
•
aggiornare il Risk Plan corrente con le nuove riserve destinate al
progetto.
Gestione degli eventi rischiosi pianificati
Durante le sessioni che ricorrentemente vedono coinvolti il Project Manager
e il suo tea nell’attività di valutazione dello stato di avanzamento dei lavori, il
responsabile della conduzione del progetto dovrà, tra l’altro, anche
monitorare l’effettivo andamento degli eventi rischiosi che risultano compresi
nel Risk Plan. A questo scopo il Project Manager dovrà innanzitutto
verificare l’eventuale effettivo concretizzarsi degli eventi rischiosi che si era
previsto potessero accadere nel periodo temporale in corso di analisi.
Qualora, infatti, gli stessi non si fossero verificati, i relativi fondi stanziati
vanno recuperati per essere destinati, alternativamente, a:
67
IL PROJECT RISK MANAGEMENT
•
aumentare il valore delle specifiche contingency riservate ai rischi futuri
già compresi nel Risk Plan corrente;
•
costituire la copertura finanziaria a fronte dei rischi che, non previsti
nella fase di identificazione, si sono comunque concretizzati in corso
d’opera;
•
dar luogo ad una nuova riserva finanziaria a copertura di futuri rischi
imprevisti;
•
incrementare il valore del “K di commessa” e pertanto, la redditività del
progetto, grazie all’aumento del relativo margine di contribuzione.
Se, al contrario, un qualsiasi evento rischioso pianificato so fosse
effettivamente
concretizzato,
il
Project
Manager
dovrà
assicurarsi,
innanzitutto, che l’Ente responsabile dell’attuazione delle azioni di contrasto
contenute nel Risk Plan corrente si attivi tempestivamente per porre in atto le
contromisure previste (nei limiti, e secondo le modalità, specificate nel
documento). Inoltre, dovrà verificare il grado di efficacia raggiunto dalla loro
attivazione e potersene, quindi, avvalere in analoghe circostanze future.
Per rendere più mirata, e quindi più efficace, l’attività di monitoraggio e di
controllo dei rischi, può rivelarsi assai produttivo riservare, nel corso delle
ripetute sessioni di check in progress del progetto, un congruo spazio
temporale all’evidenziazione di quegli eventi rischiosi che, di volta in volta,
si ritengono più significativi in quanto latori delle criticità più consistenti.
La Lesson Learned
Uno degli elementi distintivi che contraddistingue il “progetto” è
rappresentato dalla sua “unicità”: tale caratteristica di esclusività dipende da
diversi fattori, ognuno dei quali contribuisce a renderne, di fatto,
improponibile una rappresentazione schematica già collaudata nel passato.
Ogni volta, infatti, si presenta mutato lo scenario economico-finanziario nel
contesto del quale l’Azienda fornitrice si trova ad operare, si modificano le
68
IL PROJECT RISK MANAGEMENT
caratteristiche della fornitura. Se le condizioni di partenza del progetto in
termini di caratteristiche della fornitura, di condizioni economiche-finanziarie
al contorno, di competitività del mercato e di adeguatezza delle risorse
umane, si presentano sempre differenti, anche durante la fase esecutiva
tendono a crearsi, ogni volta, situazioni ed ambienti di lavoro che ricalcano
solo in parte quelli determinatesi, nel passato, per progetti analoghi. Ed è
altrettanto vero che la soluzione ai problemi determinanti dall’insorgenza in
corso d’opera di “disturbi” non previsti in sede di pianificazione iniziale
dell’iter realizzativo va ogni volta ricercata nel contesto dello specifico
progetto, cercando di sfruttare al meglio le risorse che si hanno, in quel
preciso contesto, a propria disposizione.
Se è vero, dunque, che, date queste premesse, appare impossibile stilare una
ricetta generale capace di assicurare il successo del progetto, è altrettanto
vero che nella ricerca delle specifiche soluzioni può essere di valido aiuto
l’esperienza maturata in circostanze analoghe (anche se non identiche) grazie
alla quale si può tentare di mutare alla realtà corrente le soluzioni già adottate
nel passato. In particolare, l’esperienza accumulata relativamente agli esiti
forniti dalle contromisure che sono state concretamente poste in atto in corso
d’opera unitamente alla conoscenza di eventi rischiosi non preventivati, ma
comunque, accaduti nella realtà operativa, non va, dunque dispersa ma, al
contrario, annotata in un apposito archivio al quale poter fare riferimento in
futuro, in sede di stesura del Risk Plan di progetti comparabili. Ancora
meglio, poi, se tali informazioni vengono memorizzate su un apposito
supporto informatico centralizzato: in questo caso non soltanto viene
facilitata (e velocizzata) la ricerca del singolo dato, ma soprattutto,
consentendo agli addetti ai lavori l’accesso all’archivio, si rende possibile la
condivisione dell’informazione che diventa, perciò, un effettivo patrimonio
aziendale e, come tale, a disposizione di tutti i Project Manager. Non è
difficile, inoltre, realizzare un software applicativo grazie al quale diventa
agevole effettuare interrogazioni mirate dell’archivio centrale [6].
69
IL PROJECT RISK MANAGEMENT
Il processo in Azienda
Nel corso delle pagine precedenti si è passato in rassegna e approfondito le
tecniche e le metodologie che trovano più spesso la loro pratica applicazione
nel Project Risk Management. E’ stata più volte sottolineata la convinzione
circa l’indispensabilità di effettuare un costante ricorso alla disciplina
descritta: il Project Risk Management, in altre parole, deve diventare una
pratica irrinunciabile alla quale ricorrere lungo l’intero periodo di
espletamento delle attività progettuali, rifuggendo, dunque, da atteggiamenti
di rifiuto e/o da posizioni di passiva sottomissione. Al contrario, occorre
persuadersi dell’irrinunciabile necessità di esercitare un’azione di presidio dei
rischi di progetto che risulti, al tempo stesso, attenta e professionale, gestendo
dunque il fenomeno rischioso con un’aggressione preventiva dei singoli
eventi alla quale far seguire un’azione di controllo continua ed efficace,
sorretta da un’ approccio sistematico e organizzato, con il costante ricorso
alle metodologie e alle tecniche specifiche della disciplina. L’introduzione di
un Sistema di Project Risk Management all’interno di una qualsiasi struttura
organizzativa preesistente, soprattutto nelle piccole e medie imprese, non si
rivela mai un’impresa di facile attuazione in quanto gli individui che la
compongono
sono
abituati
ad
operare
secondo
regole
(anche
comportamentali) che rispondono a logiche radicate e, come tali,
sostanzialmente condivise da tutti i membri della comunità.
Al fine di creare le condizioni capaci di garantire la risposta efficace e
costruttiva del contesto aziendale e per evitare, perciò, che si manifestino
fenomeni
di
resistenza
all’innovazione,
è
necessario
intervenire
preventivamente sulla “componente culturale” che caratterizza il particolare
sottosistema organizzativo dell’Azienda. Così come accade per tutti i
cambiamenti organizzativi importanti, anche il ricorso formale ed
istituzionalizzato all’utilizzo aziendale di un sistema di Project Risk
Management richiede una fase di introduzione che spesso si rivela lunga ed
70
IL PROJECT RISK MANAGEMENT
onerosa [44]. Come ha osservato Kerzner, il tasso di cambiamento delle
innovazioni (sia tecniche che metodologiche) mostra, nella generalità dei
casi, un differenziale temporale significativo rispetto a quello che si
determina in seno alle strutture organizzative presso le quali tali innovazioni
vengono implementate (il fenomeno prende il nome di organisational lag). In
altre parole, come mostrato nella figura 15, l’organizzazione insegue, con
sensibile ritardo, i cambiamenti tecnologici e ambientali introdotti, e più lento
ancora si rivela il processo di adeguamento delle persone alla nuova realtà
tecnico-organizzativa. Le soluzioni organizzative e gestionali, pertanto,
vanno ricercate con metodo, applicando un approccio di tipo ricorsivo che
consenta il progressivo affinamento della loro applicazione.
Tasso di
cambiame
nto
TECNOLOGIA
ORGANIZZAZIO
NE
Tempo
Figura 15: Il Modello di Kerzner [27]
In quanto disciplina manageriale, la gestione del rischio di progetto
costituisce una delle leve strategiche mediante le quali diventa possibile
conferire razionalità ed efficacia ai comportamenti dell’Impresa. Tuttavia,
proprio in quanto componente non secondaria del piano strategico aziendale,
è indispensabile che la sua introduzione non avvenga come fatto isolato e non
venga, inoltre, recepita come un’ “imposizione dall’alto”, ma che, al
contrario, sia inquadrata, e trovi quindi la sua giustificazione, in un processo
di innovazione di più ampio respiro che prevede il coinvolgimento attivo del
Top Management. Il vertice aziendale deve impegnarsi a fornire il proprio
esplicito appoggio accordando visibilità e promuovendo la diffusione della
71
IL PROJECT RISK MANAGEMENT
nuova filosofia organizzativa con adeguate attività formative rivolte ai diversi
livelli della struttura [44].
Nei processi di trasformazione organizzativa si rivela di fondamentale
importanza la verifica preliminare del livello di congruenza esistente tra la
nuova strategia proposta e il “livello culturale” che caratterizza l’Azienda
nella sua globalità. Per stimare la dimensione del “rischio culturale”, può
dimostrarsi utile il ricorso al modello generale proposto da Schwartz e Davis
che offre un semplice strumento di valutazione facilmente ed efficacemente
utilizzabile nello specifico contesto. I due autori hanno suggerito l’utilizzo di
una matrice a due dimensioni (figura 16) che, con l’impiego di una scala
aggettivale, potrebbe riportare, nelle righe, il rilievo che l’Azienda attribuisce
all’introduzione di una gestione “professionale” dei rischi, mentre, nelle
colonne, potrebbe essere rappresentato il livello di compatibilità che
l’innovazione proposta dimostra nei confronti della “cultura” esistente.
COMPATIBILITA’ CON LA
CULTURA ORGANIZZATIVA
IMPORTANZA PER
STRATEGIA
AZIENDALE
BASSA
MEDIA
ALTA
Rischio trascurabile
BASSA
Rischio contenuto
MEDIA
Rischio consistente
ALTA
Figura 16: Introduzione in azienda di un Sistema di Project Risk
Management: rischio di insuccesso (Modello di Schwartz e Davis) [57]
La valutazione del rischio culturale viene formulata posizionando
l’introduzione di un sistema di Project Risk Management all’interno della
matrice e considerando il particolare quadrante entro il quale la stessa va a
collocarsi:
72
IL PROJECT RISK MANAGEMENT
•
quadranti superiori (rispetto alla diagonale): è la zona caratterizzata da
un livello medio-alto di compatibilità culturale dell’Azienda per la quale,
d’altra parte, il sistema di Project Risk Management non rappresenta un
fattore strategico di particolare rilievo. In questo caso il rischio associato
alla sua introduzione si rivela trascurabile in quanto la struttura si
dimostra aperta all’innovazione, disponibile ai cambiamenti organizzativi
e, pertanto, necessita unicamente di un’azione formativa finalizzata
all’apprendimento tecnico necessario ad acquisire le nuove metodologie;
•
quadranti situati lungo la diagonale: evidenziano contesti differenti che
spaziano da situazioni caratterizzate da un elevato livello di importanza
strategica abbinato ad un livello culturale più che adeguato, a quelle
contraddistinte da un livello culturale di basso profilo associato, però, ad
una scarsa importanza strategica, passando attraverso uno stadio
intermedio nel quale entrambe le variabili assumono valori medi (ad un
livello culturale accettabile corrisponde un’importanza strategica non
troppo rilevante). In questi casi, il rischio di insuccesso può considerarsi
contenuto e quindi l’introduzione di un sistema di Project Risk
Management, purché opportunamente presidiata, presenta buone
probabilità di concludersi in maniera positiva;
•
quadranti inferiori (rispetto alla diagonale): in questo settore della
matrice, ad un’importanza rilevante per la strategia dell’impresa si
accompagna un “clima” culturale decisamente inadeguato. E’ la zona
della matrice di massimo rischio, all’interno della quale il processo di
introduzione di un sistema di Project Risk Management deve
necessariamente essere sostenuto dal vertice aziendale con un’azione
fattiva ed efficace. In assenza di un simile intervento, la grave
incompatibilità rilevata si tradurrebbe nel sicuro fallimento dell’iniziativa
[57].
In ogni Azienda, accanto alle regole istituzionalizzate, come le prescrizioni
organizzative, le procedure in atto, i sistemi di coordinamento e di controllo
73
IL PROJECT RISK MANAGEMENT
ecc., esistono regole non scritte, ma non per questo meno importanti, che
riguardano i valori, gli atteggiamenti, i sistemi di riferimento, lo stile di
pensiero e così via. Quella che viene comunemente definita “cultura
aziendale” è costituita dall’insieme di tutte queste variabili, e di tutte queste
occorre tener conto nel momento in cui si decide l’introduzione di un sistema
di Project Risk Management: la scelta di una sua imposizione “dall’alto”,
effettuata mediante la formulazione di ordinanze e di “proclami” da parte del
vertice aziendale, si rivela quasi sempre perdente proprio perché trascura le
regole non scritte. Per evitare di incorrere in un fallimento o, nella migliore
delle ipotesi, di ottenere un’applicazione del sistema di analisi e gestione dei
rischi di progetto soltanto approssimativa, accettata in quanto imposta, ma
disattesa nella sostanza, è indispensabile procedere alla preventiva e graduale
modifica della “cultura aziendale”, intervenendo, sostanzialmente, lungo tre
linee direttrici:
•
comportamento del management;
•
meccanismi della comunicazione;
•
capacità professionale degli addetti.
Occorrerà operare, pertanto, una serie di interventi formativi rivolti ai diversi
livelli della struttura gerarchica mirati non soltanto a fornire il corredo di
nozioni tecniche necessario ad operare secondo i dettami imposti dalla nuova
metodologia,
ma
finalizzati,
soprattutto,
ad
ottenere
il
massimo
coinvolgimento delle diverse strutture organizzative nel processo di
innovazione che le vede protagoniste. Due sono, sostanzialmente, le
motivazioni che rendono tale azione di coinvolgimento di fondamentale
importanza per la riuscita dell’intera operazione. Innanzitutto le reazioni
poste in essere dagli individui a fronte dei cambiamenti imposti all’ambiente
organizzativo nel quale sono immersi dipendono, in larga misura, dalla loro
possibilità (e capacità) di controllare il cambiamento o, viceversa, di doverlo
soltanto subire: tanto più alto è il livello di partecipazione accordato, tanto
maggiore si dimostrerà il grado di accettazione finale da parte delle persone
74
IL PROJECT RISK MANAGEMENT
interessate. In secondo luogo, una buona parte dell’apprendimento si realizza
proprio durante questa fase di partecipazione, con l’evidente vantaggio di
ottenere una sensibile riduzione del periodo di tempo necessario a rendere
operante il nuovo sistema. E dato l’endemico ritardo (evidenziato dal citato
modello di Kerzner) con il quale le persone si adeguano ai cambiamenti
imposti dall’organizzazione, anche quest’ultimo risultato non è certo da
considerarsi di scarso rilievo.
E’ importante, infatti, che la gestione dei rischi di progetto venga effettuata
secondo regole aziendali istituzionalizzate, tese a definire:
•
quando deve essere svolta;
•
come deve essere svolta.
Per quanto riguarda il primo punto, non è detto che l’analisi debba essere
necessariamente condotta a fronte di tutti i progetti aziendali. Applicando il
più generale tra i principi manageriali, secondo il quale occorre prestare la
massima attenzione al bilanciamento dei costi e dei relativi benefici, tale
attività dovrà essere riservata soltanto a contesti di dimensioni e/o criticità
rilevanti, tali da assorbire, da una parte, e giustificare, dall’altra, gli
inevitabili costi connessi alla sua conduzione. E così pure la determinazione
del livello di dettaglio al quale spingere tale analisi deve comunque limitarsi
alla generazione di informazioni la conoscenza delle quali risulti
economicamente utile in rapporto ai costi generati dal loro ottenimento. A
questo proposito sarebbe auspicabile, quindi, che, a livello aziendale, fossero
stabilite delle regole precise tese a definire, per ciascuna tipologia di
progetto:
1. i limiti dimensionali: al di sopra o al di sotto dei quali, rispettivamente,
procedere o non procedere alla valutazione dei rischi. Gli estremi degli
intervalli dimensionali debbono venire espressi in unità di misura non
opinabili (valore economico complessivo, carico di lavoro stimato, durata
temporale ecc.);
75
IL PROJECT RISK MANAGEMENT
2. il grado di approfondimento: intendendo come tale il livello di dettaglio
(tipologia delle fonti di rischio da considerare, tecniche alle quali
ricorrere ecc.) al quale spingere l’analisi dei rischi relativamente a
ciascun intervallo dimensionale predefinito.
L’attenzione e la diligenza che il Project Manager riserva all’analisi che
conduce condizionano, ovviamente, la qualità del risultato, ma il tempo che
questi deve dedicare a tale attività origina un costo che deve essere
compensato dal beneficio del prodotto finale, e tale costo, oltre che dipendere
dalla particolare tecnica utilizzata, aumenta proporzionalmente alla quantità
e alla precisione delle informazioni collezionate. Il problema può essere
riassunto dalla schematizzazione riportata in figura 17: le due funzioni che vi
compaiono rappresentano, rispettivamente, l’andamento dei costi e dei
benefici marginali in funzione del grado di sofisticazione che può essere
teoricamente raggiunto.
Euro
Beneficio
marginale
Costo
marginal
Livello di
sofisticazion
Livello
Figura 17: Livello di sofisticazione della fase di Quantificazione [44]
La funzione che rappresenta i benefici marginali presenta un andamento
decrescente in quanto il vantaggio aggiuntivo si riduce rapidamente al
crescere del livello di sofisticazione con il quale si conduce l’indagine: la
qualità del risultato dell’analisi, infatti, risente fortemente dell’apporto fornito
dai primi ampliamenti/approfondimenti per poi ridursi progressivamente,
mano a mano che si procede verso livelli di alta sofisticazione i cui costi
76
IL PROJECT RISK MANAGEMENT
risultano, generalmente, più che sproporzionati rispetto ai benefici ottenuti.
Al contrario, il trend della curva che rappresenta i costi marginali sale
rapidamente presentando una crescita di tipo esponenziale: da un certo punto
in poi l’aumento del livello qualitativo può essere ottenuto solo a fronte di
sforzi aggiuntivi che si rivelano troppo onerosi se comparati al concreto
miglioramento del risultato. Il livello ottimale al quale spingere il grado di
sofisticazione delle metodologie e delle tecniche da impiegarsi in fase di
quantificazione dei rischi di progetto è determinato dalla proiezione sull’asse
delle ascisse del punto di intersezione delle due curve che identifica la
condizione di pareggio tra costi e benefici marginali. Il grafico permette di
trarre le logiche conclusioni e suggerisce il criterio da applicare in sede di
determinazione del livello di sofisticazione al quale spingere l’analisi.
Osserviamo, innanzitutto, che ancor prima di affrontare concretamente la fase
di indagine, il Project Manager possiede, probabilmente, una chiara, anche se
approssimativa, percezione almeno dell’ordine di grandezza del danno
potenziale che gli specifici eventi dannosi individuati nel contesto
realizzativo del proprio progetto potrebbero generare. La dimensione della
perdita monetaria sarà essa stessa il fattore capace di indirizzarlo verso
l’applicazione delle tecniche e delle metodologie più convenienti (sotto il
profilo economico) e più efficaci (dal punto di vista della qualità del risultato
raggiunto). Inoltre, non va mai dimenticato il principio basilare che
sovrintende qualsiasi scelta manageriale: il rapporto costo/benefici deve
sempre risultare favorevole, e, pertanto, l’esperienza e, soprattutto, il buon
senso rappresentano i due elementi essenziali sulla base dei quali procedere
alla scelta della modalità operativa più consona al particolare contesto. Aldilà
del grado di sofisticazione da raggiungere, è comunque importante
sottolineare che il ricorso a tecniche e metodologie consolidate e applicate
uniformemente da tutte le strutture coinvolte, rappresenta, in ogni caso, una
condizione assolutamente necessaria affinché gli sforzi profusi si traducano
77
IL PROJECT RISK MANAGEMENT
nell’ottenimento di reali vantaggi sul piano della gestione integrata del
progetto.
Volendo condurre un’analisi più dettagliata delle problematiche che si
sviluppano contestualmente all’applicazione di una corretta gestione dei
rischi si potrebbe dire che gli errori che più frequentemente si è portati a
commettere nella pratica operativa sono:
•
non redigere un piano (equilibrato) di gestione dei rischi: è il primo, e il
più ovvio, degli errori nel quale si tende ad incorrere. Per “equilibrato” si
intende che il piano deve risultare contenuto (in termini di numerosità
degli item individuati) e ragionevolmente sofisticato (sotto il profilo delle
tecniche utilizzate).
•
non identificare una “soglia massima” di rischio: al fine di deciderne
l’effettiva presentazione al potenziale Cliente, in sede di stesura
dell’offerta commerciale occorre tener conto di una serie di parametri che
caratterizzano lo specifico contesto realizzativo (redditività, strategicità,
promozione, fornitura, ecc.): tra questi dovrebbe essere valutato anche il
rischio complessivo del progetto misurato in termini economicofinanziari. Sarebbe opportuno poter disporre, in tale sede, di un valore di
riferimento (definito a livello aziendale) che esprime, relativamente ad
ogni tipologia di progetto, la soglia massima di rischio economico al di
sopra della quale non si prosegue neppure nel tentativo di acquisizione
del contratto.
•
scambiare (o confondere) i rischi con le conseguenze: in fase di
identificazione dei rischi non è raro incappare in questo tipo di errore.
•
non applicare le contromisure previste nel piano: le contromisure
riportate nel piano costituiscono una scelta “consapevole” in quanto
rappresentano il risultato di un’analisi preventiva che, proprio in quanto
tale, è stata condotta senza l’assillo dell’urgenza di intervenire al più
presto. Salvo casi eccezionali, pertanto, debbono essere puntualmente
adottate all’insorgenza dell’evento rischioso, senza cedere alla tentazione
78
IL PROJECT RISK MANAGEMENT
di modificarle all’ultimo istante affidandosi all’estro, alla fantasia, alle
sensazioni o, peggio, alla disposizione d’animo “dell’ultimo momento”.
•
non coinvolgere gli attori principali: è importante stabilire una
comunicazione continua, trasparente e il più possibile completa tra gli
stakeholder di progetto. In tale ambito la reale condivisione dei rischi
progettuali, che, almeno in determinate circostanze, potrebbe veder
coinvolto lo stesso Cliente, si rivela nella maggior parte dei casi
particolarmente fruttuosa ed efficace.
•
non aggiornare il piano: l’attività di aggiornamento del Risk Plan
comporta l’effettuazione di eventuali modifiche agli importi stanziati a
fronte delle future contingency (in tutti quei casi in cui siano stati
recuperati i fondi assegnati a quegli eventi rischiosi i quali, benché
presenti nel Risk Plan del progetto, non si sono tuttavia effettivamente
concretizzati in corso d’opera); l’inserimento degli eventi rischiosi
imprevisti, relativamente ai quali occorre valutare e ufficializzare le
modalità di intervento (l’annotazione degli eventi imprevisti costituisce,
tra l’altro, un valido promemoria per la fase di individuazione dei rischi
di futuri progetti similari) e l’aggiunta di note che riguardano il grado di
efficacia raggiunto dalle contromisure effettivamente adottate a fronte di
eventi che si sono concretizzati in corso d’opera, le motivazioni che non
hanno consentito di porre in atto le azioni di contrasto previste nel Risk
Plan originario e l’evidenza degli eventi rischiosi che, pur essendo stati
previsti, non si sono poi effettivamente realizzati [44].
Project breakdown structure
Per molti progetti complessi è necessario un procedimento ordinato e
sistematico che ne assicuri la definizione in modo che tutti i loro elementi
siano correttamente interrelati, senza che nessuno venga omesso. Un buon
lavoro dà un risultato positivo sotto molti altri aspetti. Il metodo più efficace
79
IL PROJECT RISK MANAGEMENT
per definire così un progetto è la creazione di una “struttura analitica di
progetto” (Project breakdown structure – Pbs), talvolta chiamata anche Work
Breakdown Structure – WBS. La Pbs è una rappresentazione del progetto, in
forma grafica o in forma descrittiva, che suddivide le attività livello per
livello spingendosi al grado di dettaglio necessario per una pianificazione e
un controllo adeguati. L’inadeguatezza della pianificazione è spesso indicata
come la causa del fallimento di un progetto. Essa, a sua volta, si può
ricondurre alla nota avversione dei tecnici (e non solo di loro) per il lavoro di
pianificazione (“devo occuparmi della pianificazione, o di qualcosa di
produttivo?”), alla diffidenza che induce molti a non rivelare i propri piani e
le proprie conoscenze professionali e alle obiettive difficoltà che si
incontrano quando si pianificano progetti complessi. Talvolta la complessità
dei metodi e delle tecniche di pianificazione, o degli strumenti, rende
impraticabile l’elaborazione di piani veramente validi. Nonostante queste
difficoltà, resta il fatto che la pianificazione è estremamente importante per la
riuscita dei progetti. Senza un piano adeguato, infatti, non si possono allocare
le risorse al tempo giusto e per la durata necessaria, come non si possono
assegnare al team di progetto le persone più adatte, impegnandole a tempo
pieno, e non si può realizzare con efficacia il monitoraggio e il controllo del
progetto. La riuscita del progetto resterà quindi in larga misura affidata al
caso. La Pbs deve comprendere tutti gli elementi che formano oggetto di
consegna al cliente (beni di consumo, macchinari, attrezzature, facilities,
servizi, manuali, relazioni, ecc.) nonché i principali compiti funzionali che
debbono essere eseguiti da parte delle singole funzioni per concepire,
progettare, costruire, assemblare, testare e consegnare tali elementi. La spinta
iniziale verso la strutturazione sistematica dei progetti secondo la Pbs è
venuta dai grandi progetti aerospaziali e militari degli USA. Successivamente
però la Pbs s’è affermata in quasi tutti i campi d’applicazione del project
management, per progetti complessi [65]. Il PMI Practice Standard for Work
Breakdown Structures (PMI, 2001) fornisce una guida alla generazione, allo
80
IL PROJECT RISK MANAGEMENT
sviluppo e all’applicazione delle strutture di scomposizione del lavoro. Il
problema con la WBS è quello della brevità dei nomi con i quali si designano
i suoi elementi e che spesso genera confusione, carenza di comunicazione e
malintesi nelle aspettative dei vari stakeholders. L’impiego d’un dizionario,
con descrizioni chiare ed esaurienti, consente di superare questa difficoltà
oltre a migliorare la comunicazione e il controllo del progetto [66]. La
superiorità della Pbs sugli altri sistemi discende dalla sua sistematicità e dalla
sua struttura gerarchica, oltre che dalla capacità di presentare il quadro
completo del progetto, nelle sue grandi linee e nei suoi elementi anche
piccoli. La Pbs scompone il progetto in una serie di sottoprogetti e di oggetti
da consegnare, quindi identifica i compiti che occorre eseguire per realizzare
i singoli sottoprogetti e per produrre e consegnare i singoli oggetti. La
strutturazione del progetto, secondo la Pbs, è ottenuta combinando la
strutturazione del prodotto e quella del processo di sviluppo dei prodotti. Per
prodotto si intende qualunque risultato materiale o immateriale del progetto
(impianti, attrezzature, servizi, organizzazioni, documenti, dati e così via). Il
processo di sviluppo dei prodotti è la serie delle fasi, dei passi, dei compiti e
delle attività che l’organizzazione impiega nella creazione dei vari prodotti
del progetto. C’è da sottolineare che il processo di sviluppo dei prodotti
ordina cronologicamente le fasi e i compiti, la Pbs no. L’ordinamento
cronologico è demandato a una fase successiva di pianificazione, con
l’elaborazione della schedulazione generale del progetto (project master
schedule) e dei suoi particolari. Il diagramma Pbs viene costruito
cominciando dall’elemento di massimo livello (corrispondente al progetto
nella sua interezza), e scomponendolo quindi nei suoi componenti naturali
(sistemi, facilities, oggetti da consegnare, ecc.). Ciascuno di questi
componenti viene a sua volta suddiviso nei suoi componenti costitutivi.
Questa suddivisione livello per livello prosegue riducendo l’entità, la
complessità e il costo di ciascun elemento, fino a quando non si raggiunge il
livello d’identificazione d’un oggetto da consegnare. Questo viene poi
81
IL PROJECT RISK MANAGEMENT
scomposto nei principali compiti che debbono essere eseguiti dalle unità
specialistiche (funzioni). L’obiettivo è d’identificare elementi e compiti
chiaramente gestibili e attribuibili alla responsabilità d’un capo funzione, e
che possano essere pianificati, valutati, budgetati, schedulati e controllati.
Questo procedimento garantisce che il progetto venga definito in ogni sua
parte e che si possano realizzare utili riepiloghi delle informazioni sul
progetto. Molte volte viene commesso l’errore di pensare il diagramma Pbs
come un organigramma, il che può dar luogo a una Pbs confusa, troppo
influenzata dalla struttura specifica dell’azienda. La Pbs non è una struttura
organizzativa, anche se a prima vista può assomigliarvi per il modo in cui è
disegnata. Come si vedrà in seguito, ogni elemento della Pbs deve essere
attribuito alla responsabilità d’uno specifico dirigente. Lo stesso dirigente
può essere responsabile per un certo numero di elementi distribuiti in più
punti della Pbs e la struttura organizzativa dell’impresa, ordinata per
funzioni, certamente avrà una certa influenza sulla Pbs, specie se gli oggetti
da consegnare sono suddivisi in compiti da attribuire alle singole funzioni. Il
processo di creazione della Pbs assicura, di per sé, importanti vantaggi.
Scomponendo il progetto, il project manager, i suoi pianificatori e i capi
funzione interessati sono obbligati a esaminare tutti gli elementi, il che li
aiuta a non trascurare nulla e a chiarire l’ambito e il contesto del lavoro
assegnato a ciascun functional project leader. La Pbs è uno strumento per
visualizzare il progetto, nella sua interezza e nella sua complessità. Grazie ad
essa si percepiscono meglio i collegamenti tra i vari elementi. Se usata
correttamente, la Pbs è uno strumento di comunicazione validissimo. Riesce
ad evolversi e a riflettere i piani correnti, man mano che il progetto si
sviluppa. Riesce anche ad accogliere maggiori dettagli, in vista
dell’esecuzione dei singoli compiti. Proprio per questa sua utilità ed
importanza, la Pbs richiede una procedura di revisione e di controllo della sua
distribuzione. Occorre infatti impedire i cambiamenti non autorizzati e
garantire la tempestiva trasmissione degli aggiornamenti ufficiali a tutti i
82
IL PROJECT RISK MANAGEMENT
manager. La Pbs è, in un certo senso, il complessivo di montaggio del
progetto, sotto l’aspetto del project management [72].
Matrice Compiti/Responsabilità
I compiti sono gli elementi d’identificazione della Pbs e gli oggetti del
controllo (work control packages). Si trovano alla fine della scomposizione
gerarchica delle singole parti del progetto. Solitamente essi emergono a
diversi livelli della Pbs. Per servire agli scopi del controllo, i compiti devono
essere di durata relativamente breve e di costo relativamente piccolo, rispetto
alla durata e al costo dell’intero progetto. La matrice compiti/responsabilità è
uno strumento di pianificazione che mette in relazione i compiti definiti dalla
Pbs con le unità organizzative responsabili, i sub-fornitori e i singoli
interessati. I compiti sono raramente assegnabili in maniera univoca a singole
funzioni, ma il metodo matriciale offre un meccanismo per attribuire la
responsabilità primaria e di supporto nella tipica impresa organizzata per
funzioni. Durante la costruzione della matrice si può verificare se c’è un
eccesso o una carenza di dettaglio nella Pbs. Una volta completata, la matrice
offre un semplice schema per l’ulteriore lavoro di pianificazione e controllo.
Nel processo di pianificazione ogni assegnatario d’un compito primario
dovrebbe dare informazioni circa la schedulazione, i tempi, i costi, la
manodopera e gli aspetti tecnici del suo compito, ivi inclusi gli apporti
richiesti a quanti svolgono ruoli ausiliari. L’utilizzo di codici di compito e
d’unità consente l’identificazione di tutte le voci della matrice. La cornice
logica della matrice e le informazioni tecniche, le schedulazioni e le stime dei
costi che vi sono associate costituiscono la base per l’autorizzazione dei
lavori e per la definizione dei criteri di misurazione per i controlli.
La matrice compiti/responsabilità è citata spesso col nome di LRC (Linear
Responsibility Chart). Cleland e King hanno descritto in modo eccellente la
sua applicazione alle attività di project management [33].
83
IL PROJECT RISK MANAGEMENT
I milestones devono essere individuati e incorporati nei piani e nelle
schedulazioni di progetto, con dettaglio adeguato, perché costituiscono punti
intermedi di controllo e perché sono importanti nella fase di sviluppo del
piano generale del progetto, per valutare lo stato d’avanzamento globale e per
presentare rendiconti all’alta direzione. Molti dei milestones, ma non sempre
tutti, sono anche eventi d’interfaccia. Un evento non è un compito, e neppure
un’attività. Un evento è un accadimento che segna l’inizio o il
completamento di uno o più compiti o attività. Per essere considerato un
evento d’interfaccia, un accadimento deve dar luogo a un cambiamento di
responsabilità o deve essere un punto d’interazione tra due o più elementi
della Pbs. Un milestone identifica una realizzazione significativa del progetto
[3].
Risk Breakdown Structure
La Risk Breakdown Structure fornisce una rappresentazione gerarchica dei
rischi del progetto ordinata per categorie. Queste categorie di rischio
forniscono una struttura che garantisce l’esaustività del processo atto
all’identificazione sistematica dei rischi a un livello di dettaglio sempre
omogeneo e favoriscono l’efficacia e la qualità del processo di
identificazione dei rischi. Un’organizzazione ha la possibilità di utilizzare
una categorizzazione dei rischi più comuni preparata in precedenza. Una
struttura di questo tipo può essere gestita mediante un semplice elenco dei
vari aspetti del progetto. Le categorie possono essere riesaminate anche nel
corso del processo di identificazione dei rischi. E’ comunque buona norma
esaminarle nel corso della fase di identificazione dei rischi prima di
utilizzarle. Qualora si adottino le categorie di rischio basate su progetti
precedenti, potrebbe rivelarsi necessario adattarle, regolarle o estenderle a
situazioni nuove prima di utilizzarle per il progetto corrente. Per eseguire
l’identificazione dei rischi si possono utilizzare discussioni dirette (ad
84
IL PROJECT RISK MANAGEMENT
esempio brainstorming) oppure la compilazione di questionari (ad esempio
metodo Delphi) o, più semplicemente, si può ricorrere a delle checklist o a
qualunque altro metodo che consenta di individuare le minacce più
significative per il progetto. In ogni caso è indispensabile che a questa
identificazione partecipino i principali conoscitori del progetto. Un
atteggiamento diffuso consiste nel credere che l’identificazione dei rischi
debba essere fatto solamente dall’esperto di risk analysis, ma questo è un
errore. Dopo aver identificato tutti i rischi che possono minacciare il progetto
è necessario confrontarli, eliminare quelli sovrabbondanti, aggiungere quelli
dimenticati, scomporre quelli che sono semplici effetti di cause primarie,
accorpare quelli simili inutilmente dettagliati. Il passo finale della stesura
della Risk Breakdown Structure è la raccolta in categorie dei rischi omogenei
[52].
85