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