SAFE: un metodo per comprendere, ridurre ed accettare i rischi di progetto

Transcript

1 SAFE: un metodo per comprendere, ridurre ed accettare i rischi di progetto Roberto Meli Abstract Il presente lavoro descrive gli elementi fondamentali di un metodo di gestione del rischio di progetto che integra diversi approcci di pubblico dominio come il PRM body of knowledge del Project Management Institute, il CTC del Software Engineering Institute, il modello delle strategie Euromethod nonché quelli descritti da McFarlan, Archibald ed altri ancora. Benché originato nel campo delle Tecnologie dell Informazione e della Comunicazione il metodo SAFE è facilmente estensibile ad altri domini applicativi. Esso spinge il Project Manager ad assumere una consapevolezza il più possibile completa delle singole e significative cause di rischio per uno specifico progetto attraverso l esame di check list di tipo generale e di tipo particolare nonché attraverso l uso di tecniche ed interazioni creative di gruppo. Alla fase di definizione del rischio segue, poi, una fase di progettazione ed esecuzione di interventi mirati al fine di ridurre la probabilità di accadimento degli eventi dannosi o l entità dei danni attesi. Il punto di arrivo è, comunque, costituito dalla consapevolezza che ogni impresa profittevole è associata ad un qualche livello di rischio e che la managerialità si avvicina oggi sempre di più alla imprenditorialità, cioè proprio alla capacità di assumere in modo volontario e consapevole i rischi che non possono essere eliminati. 1. 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. 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 vogliamo minimizzare le perdite attese per ogni specifico sforzo 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. Il presente documento descrive il metodo SAFE (Safe Activities For Enhancement), frutto dell integrazione di diversi approcci concettuali e pratici al tema della gestione del rischio progettuale tra cui il PRM body of knowledge del Project Management Institute, il CTC del pag.1

2 Software Engineering Institute, il modello delle strategie Euromethod nonché gli strumenti proposti da McFarlan ed Archibald. Il metodo porta il Project Manager ad assumere una consapevolezza il più possibile completa delle singole e significative cause di rischio per uno specifico progetto attraverso l esame di checklist di tipo generale e di tipo particolare nonché attraverso l uso di tecniche e di interazioni creative di gruppo. Il punto di partenza di questo lavoro è una chiara definizione di termini come problema, obiettivo e rischio: concetti spesso assunti come primitivi, cioè non bisognosi di ulteriori approfondimenti, ma che in realtà sono frequentemente male interpretati. La loro esplicitazione suggerisce modalità per comprendere meglio il rischio associato a specifiche situazioni e per poterlo affrontare con maggiori speranze di successo. Successivamente viene presentato e descritto il Risk Management come un processo organizzativo ripetitivo da svolgersi in alcuni momenti canonici ed ogni qualvolta sia necessario, all interno del Ciclo di Vita del progetto. Segue, infine, una descrizione delle varie Attività previste con l indicazione degli input, output, tecniche, strumenti di lavoro e skill suggeriti. 2. Problema, Obiettivo e Rischio Perchè nasce un progetto? Al di là delle motivazioni specifiche di ogni singola iniziativa si può intravedere una serie più generale di risposte come la seguente: per risolvere un problema esistente per evitare un problema futuro per creare nuove opportunità In due su tre delle precedenti motivazioni compare la parola problema ed in effetti un progetto può essere assimilato ad un processo molto articolato e strutturato di problem solving. Occorre allora approfondire il significato di questo concetto molto usato e pertanto spesso ritenuto primitivo cioè intuitivo e non ulteriormente precisabile. A pensarci bene un problema potrebbe essere immaginato come uno stato delle cose non gradito (e perciò da rimuovere o risolvere). Esso può riguardare indifferentemente il presente oppure il futuro. Ma perchè stato delle cose? Perchè esso può consistere nella configurazione di una serie di variabili di ogni genere come quelle economiche, organizzative, produttive, sociali, legislative. E perchè non gradito? Perchè se fosse gradito non rappresenterebbe un problema! Non avremmo cioè interesse a individuare le cause di una certa situazione per tentare di rimuoverle od annullarne gli effetti considerati negativi ed indesiderati. Il punto di partenza di ogni progetto, dunque, dovrebbe essere la riflessione sulle circostanze considerate negative dalle parti coinvolte e sulle loro cause dirette o indirette prima ancora che sulle modalità per risolvere tali situazioni. Come analizzare un problema per impostarne la più adeguata soluzione? Si dovrebbe: 1. cercare di delimitare il contesto di cui occuparsi (i confini dell area problematica) 2. individuare i soggetti interessati 3. formulare una descrizione dei vari aspetti del problema (dei sotto-problemi) 4. identificare i legami tra i sotto-problemi 5. determinare un reticolo di cause-effetti (problem network structure) Appare ovvio, infatti, che senza un opportuna identificazione delle vere cause di una situazione problematica non è neppure possibile iniziare ad avviare la soluzione della stessa a meno di non essere molto fortunati. Per un approfondimento sulle tecniche di problem setting e problem solving si rimanda all abbondante letteratura in merito. Possiamo qui ricordare che un errore molto comunemente commesso nel trattare problemi è quello di spendere poche energie nella definizione del problema stesso - in quanto stato delle cose indesiderato corredato del suo reticolo di cause-effetti - e nel passare troppo rapidamente alla identificazione di azioni da svolgere. Si corre così il rischio di rappresentare il problema come la mancanza della prima soluzione che ci viene in mente. Spesso dunque ci pag.2

3 comportiamo come se avessimo delle soluzioni belle e pronte in cerca dei loro problemi. Inutile forse dire che in questo caso il vero problema prima o poi rispunta fuori più urgente e pericoloso di prima. Quando, per esempio, in azienda le cose non vanno bene economicamente la prima azione che viene in mente di fare è quella di ridurre i costi e dunque si pensa che il problema sia quello di avere i costi troppo alti. Talvolta, invece, la circostanza considerata negativa dagli azionisti non è relativa ai soli costi ma ai margini operativi (ricavi-costi) che sono troppo bassi e dunque una soluzione possibile a tale situazione problematica può essere quella di ampliare i ricavi oltre che ridurre i costi. Se un progetto è legato essenzialmente alla risoluzione di un problema, come possiamo definirne il suo successo? Certamente pochi avrebbero dubbi nell affermare che questo sia rappresentato dal raggiungimento degli obiettivi posti. Ma cos è un obiettivo allora? Anche questo è una idea spesso assunta come primitiva e mai analizzata in modo più attento ed approfondito. A ben pensare ci troviamo a descrivere un concetto complementare a quello di problema, infatti un obiettivo può essere definito come uno stato delle cose gradito ed atteso. Stato delle cose per i motivi già detti; gradito perchè se non fosse tale non metteremmo in piedi un apparato costoso ed impegnativo per realizzarlo ed infine atteso perchè non solo ci piace ma vogliamo arrivarci davvero e dunque operiamo al fine di perseguirlo. Obiettivo è ciò a cui vogliamo giungere in un modo o nell altro; esso è esprimibile in termini di risultato e generalmente (non sempre) è ciò che rimane quando il progetto è terminato. Esempi di obiettivi possono essere: miglioramento dell efficienza nel processo di vendita del 30% in un anno; copertura radioelettrica di un territorio provinciale entro la fine del trimestre ed ad un costo non superiore a x lire; riduzione dei tempi di attesa del pubblico del 20% nei primi 3 mesi di esercizio. Gli obiettivi in quanto risultati - dovrebbero essere descritti più in termini di essere o avere che di fare. L errore più frequente che viene commesso al riguardo, invece, è quello di considerare come obiettivi le azioni che servono per produrre i risultati. Quando avviamo un indagine di mercato, l obiettivo del progetto è acquisire la conoscenza delle aspettative o dei comportamenti di un segmento di clientela, non quello di fare l indagine, cioè di espletare le attività di definizione, raccolta ed analisi delle interviste. Quello che accade frequentemente nei progetti reali, dunque, è di confondere mezzi con fini; strumenti con risultati o per lo meno di lasciare implicito il legame tra di essi. Spesso non sono chiare le deleghe organizzative legate ai risultati da raggiungere perchè la conoscenza sui fini viene mantenuta ai piani alti dell organizzazione mentre viene commissionato solo lo sviluppo degli strumenti. Il problema è che poi non c è nessuno che si occupa di perseguire la coerenza tra gli strumenti ed i fini di livello più elevato. Il rischio che si corre, allora, è di creare degli ottimi mezzi tecnici che però nessuno usa e che non producono i risultati organizzativi desiderati in modo implicito dal management. Se un obiettivo è uno stato delle cose gradito ed atteso, è lecito chiedersi da chi sia gradito ed atteso. In effetti sappiamo che 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. pag.3

4 Ad esempio se il budget concordato è di 100 milioni spenderne 110 o 90 potrebbe ancora rientrare nel margine di tolleranza accettato da tutti. Se ora immaginiamo di collocare ogni obiettivo su un diverso asse cartesiano di misura allora la 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 il riuscire a far rientrare i risultati consuntivi nel volume appena definito. La figura 1 rappresenta una semplificazione del concetto su uno spazio disegnato a tre dimensioni. I portatori d interesse sul progetto sono coloro che risultano legittimati ad esprimere interessi sui risultati o sul processo lavorativo del progetto stesso. Essi sono generalmente: committenti del progetto, destinatari del risultato, partecipanti nello sviluppo, regolatori esterni. A questi soggetti umani fornitori di requisiti devono aggiungersi i fattori inanimati che esprimono vincoli e condizioni sul progetto. Esempi di fattori inanimati sono la necessità di progettare un sistema in modo compatibile con altri sistemi esistenti o futuri, il rispetto delle norme ISO 9000 etc. Questi requisiti tecnici impliciti dovranno essere assunti in modo esplicito da un qualche soggetto animato (generalmente il Project Manager) affinchè possano essere trattati in modo adeguato dal progetto. Dopo quanto visto appare chiaro come il rischio di un progetto possa essere definito come la probabilità di non riuscire a perseguire uno o più degli obiettivi esplicitati e concordati per esso. Il rischio principale, dunque, è la possibilità che i vari pezzi che compongono il puzzle degli obiettivi non siano adatti per stare insieme l uno con l altro cioè non siano compatibili tra loro: cosa che rappresenterebbe l insuccesso generale del progetto. Questo è un rischio, come si è già scritto, che si corre tutte le volte in cui si negozia separatamente sui vari aspetti caratteristici (requisiti funzionali, tempi, costi, skill, personale etc.) su tavoli diversi e con soggetti diversi. Vi è infatti la possibilità di raggiungere sì un accordo sui vari obiettivi parziali ma che questi siano incompatibili tra loro. In altre parole la zona di successo per il progetto in questione non coincide già in partenza con una zona di fattibilità. Le cause di rischiosità possono essere 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, 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. L ambiente si manifesta al progetto in termini di opportunità ma anche di minacce per la sua stessa sopravvivenza. Sono molteplici, infatti, gli elementi che possono provocare problemi a volte drammatici per la sua riuscita. Si è scritto di problema e rischio: ma quale differenza esiste tra i due concetti? Un problema è descrivibile come uno stato delle cose non gradito che può riguardare il presente o il futuro mentre un rischio, ad una prima approssimazione, può essere pensato come la pag.4

5 probabilità che ha un problema di manifestarsi. In termini poco rigorosi ma suggestivi un rischio può essere considerato un problema che non si è ancora presentato ma potrebbe farlo. Il concetto di probabilità è intrinseco ed essenziale al concetto di rischio. Per analizzare i rischi in modo efficace occorre, dunque, interpretare i segnali deboli che provengono dall interno del progetto o dall ambiente circostante e che possono essere indicatori tempestivi del manifestarsi del problema associato. Vi è un proverbio diffuso tra i camionisti di molti paesi che recita: dietro ogni pallone che rotola c è un bimbo che corre! Il momento buono per frenare l automezzo è quello in cui si vede comparire il pallone e non quando appare anche il ragazzo che lo insegue! Spesso quando il segnale di rischio diventa forte e ben visibile è troppo tardi per evitare che si manifesti il problema associato. 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 ci 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 causato da un certo problema moltiplicato la sua probabilità di accadimento. In tale modo possiamo focalizzare le energie gestionali nel controllo di cose che siano davvero rilevanti per il progetto e non dei semplici fastidi. 3. La gestione del rischio come processo organizzativo 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. Si potrà in questo modo evitare, alla frase questo progetto ha un rischio elevato, di sentirsi rispondere: perché non siete capaci di farlo!. 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 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. 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. Come ogni processo, la Gestione del Rischio (Risk Management) può essere espressa come un insieme di attività ognuna caratterizzata da specifici elementi di input e di output, così come da strumenti, tecniche e skill opportuni. I seguenti capitoli utilizzeranno lo schema citato e forniranno una descrizione estesa di alcuni aspetti importanti. pag.5

6 4. Struttura generale del metodo SAFE Come indica la figura 2, la prima attività nella Gestione del Rischio è quella della Identificazione del Rischio (Risk Activity n 1 RA1), nella quale tutte le principali fonti di rischio vengono individuate, elencate ed entrano a far parte del database per la gestione del rischio (Risk Management Database - RMD) che conterrà tutte le informazioni rilevanti per l applicazione di questo metodo. Ad essa segue la Quantificazione del Rischio (RA2) che permetterà di ottenere la visione più oggettiva possibile delle percezioni istintive sulla rischiosità del progetto. Al termine di queste due attività potrà essere prodotta la bozza di una relazione sulla natura ed il livello di rischio a cui il progetto è esposto (Risk Assessment Report - RAR). Dopo la fase di diagnosi (RA1+RA2) si passa poi alla Identificazione del rischio Quantificazione del rischio Progettazione interventi Esecuzione interventi Verifica efficacia interventi Figura 2 Risk Management Database Risk Assessment Report Risk Management Plan Strumenti di Pianificazione e Controllo Progetto Risk Management Evaluation Report individuazione di strategie generali e particolari per ridurre i fattori di rischio sia nella loro probabilità di accadimento che nella entità dei loro possibili effetti. Questo sarà possibile attraverso la Progettazione degli interventi (RA3) di gestione del rischio che permetterà la formulazione di un Risk Management Plan (RMP) contenente sia le indicazioni generali per la corretta impostazione del progetto sia una sezione in cui per ogni fattore di rischio viene individuata una serie di azioni di: prevenzione, sorveglianza e contrasto. 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 e documentato nel Risk Assessment Report. Esso 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 progettazione degli interventi di gestione seguirà l attività di Esecuzione degli interventi (RA4) 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. L ultima attività prevista dal metodo proposto è quella di Verifica dell efficacia degli interventi (RA5) messi in atto. Essa è necessaria al fine di confermare o contestare la validità pag.6

7 del RMP in modo da prevedere eventuali nuovi interventi di prevenzione, 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 (RMER) 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 (RA1 e RA2) sia la fase progettuale (RA3). Nel metodo SAFE illustrato sono utilizzati strumenti come la mappa cognitiva del territorio, l analisi del campo di forze, l analisi reticolare causa-effetto, il diagramma e la matrice di contesto, il metodo Delphi o Shang, l indice di autodeterminazione, l indice di efficacia nella rimozione del rischio, le tecniche di analisi pesata ed altro ancora. 5. Identificazione del rischio (RA1) L obiettivo di questa attività è quello di portare all attenzione esplicita delle parti coinvolte nel progetto un insieme il più possibile completo di elementi di criticità che costituiscono la base per la valutazione del rischio generale e per la predisposizione delle opportune risposte di governo. Tabella Input 5.2. Tecniche e Strumenti 5.3. Output Informazioni sul progetto: Descrizione del problema Descrizione del contesto Obiettivi del progetto Requisiti del progetto Vincoli e condizioni Soggetti coinvolti Descrizione della soluzione Risorse assegnate Piano generale di lavoro Informazioni storiche (Risk Management Database) 5.4. Skill necessari Creatività Capacità analitiche Capacità descrittive Capacità comunicative interpersonali Esperienza del contesto applicativo Conoscenza delle tecniche specifiche Approccio CTC Analisi reticolare causa-effetto effetto-causa Mappa cognitiva del territorio Diagramma di contesto Checklist Interviste Brain storming Risk Management Database Risk Assessment Report 5.5. Descrizione generale Come già scritto, questa attività dovrebbe essere eseguita la prima volta durante lo Studio di Fattibilità del progetto ma successivamente ogni qual volta le condizioni di rischio cambiano in natura o entità. 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. pag.7

8 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 è dominio di studio 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 scolastica 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). Per formulare descrittivamente ogni singolo elemento di criticità si può adottare un approccio denominato CTC [1] cioè Condizione-Transizione-Conseguenza. La Condizione specifica una situazione il cui manifestarsi può portare, attraverso una Transizione a cui è associabile un grado di probabilità di accadimento, ad una Conseguenza indesiderata. In un approccio del genere la formulazione di un elemento di rischiosità può essere la seguente: se si verifica la situazione A allora c è la probabilità x% che si determini la situazione indesiderata B. Ad esempio: se la competenza tecnica del gruppo sulla tecnologia da usare è bassa allora c è una probabilità alta che il risultato sia poco affidabile e robusto. Se troviamo un modo di assegnare valori di probabilità alle condizioni ed alle transizioni nonché punteggi all impatto delle conseguenze, avremo la possibilità di valutare i rischi del progetto. Nella individuazione dei singoli elementi critici potremo guardare in avanti ( forward chaining ) - partendo dalla elencazione delle situazioni che si possono presentare con una certa 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. In entrambi i casi si può ricorrere all utilizzo di strumenti come la Mappa Cognitiva del Territorio, il Diagramma di Contesto e le checklist di classificazione degli elementi critici dei progetti 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 nel progetto 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) Diagramma di contesto Il diagramma di contesto (Fig. 3) è 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. Esso è descritto in [2] ma viene qui usato in modo sensibilmente diverso. 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. pag.8

9 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 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, la propensione all acquisto con carta di credito da parte dei consumatori. 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 l Autorità per la Privacy, l Amministratore Delegato, 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. Esse vengono usate solo per stimolare la fantasia nel cercare possibili elementi di criticità attraverso una lista di verifica. 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. Esempi di elementi (fattori e soggetti) attinenti le diverse classi sono i seguenti: società: scolarizzazione di un area geografica, vandalismo del territorio considerato, sensibilizzazione ecologica della popolazione, il direttore di una scuola, i clienti. politica: il sindaco di un comune, la corruzione ambientale, i rapporti col sindacato, l orientamento federalista. leggi/norme: la normativa antitrust, la legge sulla sicurezza, la legge sulla privacy, lo standard ISO 9000, il Parlamento Europeo. economia: il reddito medio pro capite di un territorio, il budget di progetto, un sistema esperto di emissione automatica ordini di acquisto. tecnologia: il linguaggio di programmazione da usare, le macchine utensili disponibili, la cablatura di una città, le capacità di risposta di una macchina, il Fornitore di Hardware. logistica: le infrastrutture di trasporto, le stanze dove lavorare, la cablatura di un palazzo, l accessibilità di un terreno, i Servizi di Supporto Tecnico. geografia: la conformazione orografica del territorio, la sismicità della zona, il livello di piovosità. strategie: dell azienda, della concorrenza, del Governo, della Comunità Europea, Il Garante dell Editoria. pag.9

10 organizzazione: i rapporti con l utente, le risorse a disposizione, le procedure da seguire. competenze : tecniche, gestionali, di relazione, comunicative. 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à. Ribadiamo: in questo caso si può intervenire con successo sull elemento critico stesso modificandolo. Un esempio di fattore controllabile potrebbe essere la competenza su una certa tecnologia: se non c è o viene a mancare potrebbe essere acquisita o con reclutamento di personale adatto o con formazione e addestramento specifico. 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. Un esempio di elemento da considerare è l evento terremoto: non si può fare nulla per impedirne l accadimento ma si possono prendere delle precauzioni e mettere in atto dei piani di emergenza che annullino il rischio d insuccesso del progetto a seguito di un terremoto. 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. Un esempio di elemento dell area dell influenza può essere il budget progettuale: potremmo trovarci nella situazione di richiedere e riuscire ad ottenere una sua revisione per il tramite dell intervento del Top Management da noi opportunamente sensibilizzato. 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. pag.10

11 Uso di checklist Esistono due riferimenti importanti per la stesura di checklist utili ai fini della identificazione dei rischi elementari di progetto. Il primo è costituito dalle Tabelle Tassonomiche di rischio pubblicate dal Software Engineering Institute [3] mentre il secondo è costituito dal Modello delle Strategie di Euromehtod [4], un metodo elaborato a livello europeo per gestire con successo le relazioni Cliente-Fornitore nel campo del software. Per l approfondimento di tali approcci rimandiamo alla bibliografia citata. 6. Quantificazione del rischio (RA2) L obiettivo di questa attività è quello di dare una base il più possibile misurabile alla valutazione del rischio generale di progetto. Tabella Input 6.2. Tecniche e Strumenti 6.3. Output Informazioni sul progetto Descrizione del problema Descrizione del contesto Obiettivi del progetto Requisiti del progetto Vincoli e condizioni Soggetti coinvolti Descrizione della soluzione Risorse assegnate Piano generale di lavoro Tolleranze di rischio accettate dai portatori d interesse Informazioni storiche Risk Management Database Risk Assessment Report (Risk Management Plan) 6.4. Skill necessari Capacità previsionali Capacità analitiche Capacità comunicative Capacità descrittive Esperienza del contesto applicativo Conoscenza delle tecniche specifiche Matrice di rischio Calcolo delle probabilità Metodo Delphi / Shang Regole empiriche / euristiche Tecniche di simulazione Tecniche di stima dei costi Tecniche di analisi economica Riunioni di lavoro Indice di autodeterminazione Rischio incondizionato Rischio residuo Indice di efficacia nella rimozione del rischio Risk Assessment Report Risk Management Database 6.5. Descrizione generale Trattando il rischio da un punto di vista quantitativo occorre evidenziare come la sua valorizzazione non sia assoluta ma dipenda da due fattori fondamentali: il tempo e le contromisure adottate. La prima dipendenza è legata al fatto che al semplice passare del tempo gli elementi di rischiosità tendono a mutare sia in termini di probabilità di accadimento sia in termini di danno arrecabile al progetto. Per il secondo aspetto, invece, occorre osservare che l entità del rischio dipende fortemente anche dalle strategie che vengono messe in atto per controllarlo. E quindi possibile esprimere una valutazione degli elementi critici precedente ed una successiva rispetto all adozione di un piano di azione specifico per la riduzione del rischio (risultato della RA3). Possiamo aspettarci, poi, che la valutazione iniziale sia significativamente superiore a quella successiva proprio in virtù dell efficacia del piano di azione individuato. Potremo chiamare il primo Rischio Incondizionato, perchè pag.11

12 legato all impatto che avrebbero i vari elementi se fossero lasciati liberi di agire incontrastati, ed il secondo Rischio Residuo. La Matrice di Rischio (Fig. 4) è la trasposizione lineare del Diagramma di Contesto circolare introdotto precedentemente. 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 La Matrice di Rischio di una certa classe). All interno degli incroci tra Elemento un elemento di una classe e la capacità di riferimento critico Controllo Influenza Considerazione corrispondente potremo 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 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13 (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 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). Per aumentare il livello di oggettività della votazione è possibile ricorrere a metodi iterativi di gruppo come il metodo Delphi o la sua variante Shang che permettono di utilizzare in modo molto efficace il cosiddetto giudizio degli esperti. 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 : SDI=100*(X+Y/2)/(X+Y+Z) 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 a b e o Totali X Y Z Figura 4 c f l m d g h i n pag.12

13 trasformativi del contesto, cioè azioni estroverse. Il motivo per cui al valore X si somma anche metà del valore Y deriva dal fatto che abbiamo presupposto una probabilità del 50% di successo nella nostra 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 (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 sotto-indici di autodeterminazione per classi di elementi (Fig. 5) in modo da avere una visione parziale delle aree di maggior auto- od eterodeterminazione. I diversi indici potranno essere rappresentati su un diagramma polare come quello in figura per avere un idea immediata delle aree di scopertura e di copertura del controllo. Venendo, invece, alla determinazione del rischio generale possiamo affermare che una sua analisi rigorosamente matematica risulta inappropriata a questo ambito in quanto sono troppe le variabili soggettive in gioco. Possiamo però elaborare alcune regole empiriche per determinare il livello di rischio complessivo a partire dai singoli elementi critici di base e dai loro voti. Una volta che i voti della matrice siano stati espressi sulla base della scala da 1 a 10 e ricordando che 10 rappresenta l impatto massimo sul progetto, cioè il suo fallimento, potremo considerare le seguenti regole empiriche: totale dei voti della matrice tra 1 e 50: rischio basso; totale dei voti della matrice tra 51 e 100: rischio medio; totale dei voti della matrice maggiore di 100: rischio elevato; i seguenti casi particolari, però, annullano le precedenti regole: presenza di uno o più voti pari a 10: certezza di fallimento; presenza di più di un voto pari a 9: rischio elevatissimo; presenza di un solo voto pari a 9 e di più di 5 voti tra 6 e 8: rischio elevatissimo; assenza di voti pari a 9 e presenza di almeno 3 voti tra 7 ed 8: rischio elevato; E opportuno ricordare che la valutazione del rischio e di conseguenza l uso degli strumenti introdotti è 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 pag.13

14 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 eterodeterminato, dopo un opportuno intervento del Top Management potrebbe aumentare il suo grado di potenza e divenire autodeterminato. Naturalmente ci aspettiamo che la valutazione del rischio di progetto sia influenzata dall attuazione del piano di azione RMP e che quindi si possa parlare, come già scritto, di una valutazione di rischio precedente ed una successiva all implementazione del piano stesso. Potrà 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 definiamo, dunque, l Indice di Efficacia del Piano di Gestione del Rischio (Risk Management Plan Effectiveness Index) come il valore: RMPEI=100*(1-(Rischio dopo/rischio prima)) allora tanto maggiore sarà l RMPEI tanto migliore sarà la nostra capacità di rispondere agli elementi di criticità. Un valore pari a 30, ad esempio, significherà che il nostro grado di efficacia nella riduzione del rischio è del 30% cioè stimiamo di riuscire a ridurre del 30% il Rischio Incondizionato lasciando un Rischio Residuo pari al 70% del Rischio Incondizionato. Ad un analisi quantitativa come quella proposta si può affiancare un analisi economica in termini monetari se siamo in grado di stimare le possibili perdite derivanti dall accadimento di eventi rischiosi in modo da poterle confrontare successivamente con i costi di governo del rischio derivanti dall implementazione del piano di gestione relativo (RMP). L analisi può essere condotta con le consuete tecniche di valutazione costi/benefici sulla base dei valori attesi delle perdite (perdita possibile * probabilità di perdita). A sostegno della quantificazione dei rischi, infine, si possono utilizzare tecniche di simulazione come il metodo Montecarlo, i business games ed i modelli per la determinazione di costi e tempi (PERT, GERT, CPM etc.). A questo proposito è interessante l approccio proposto in [5]. pag.14

15 7. Progettazione degli interventi L obiettivo di questa attività è quello di fornire la pianificazione di un insieme coerente e sostenibile di attività e responsabilità per il governo del rischio nonchè l individuazione delle modalità di misura associate al controllo dei risultati. Tabella Input 7.2. Tecniche e Strumenti 7.3. Output Informazioni sul progetto Descrizione del problema Descrizione del contesto Obiettivi del progetto Requisiti del progetto Vincoli e condizioni Soggetti coinvolti Descrizione della soluzione Risorse assegnate Piano generale di lavoro Risk Management Database Risk Assessment Report (Risk Management Plan) 7.4. Skill necessari Capacità creative Capacità comunicative Esperienza del contesto applicativo Conoscenza delle tecniche specifiche Checklist Regole empiriche / euristiche Tecniche di stima Tecniche di analisi economica Alberi di decisione Tecniche di scelta pesata Strumenti di pianificazione Matrici di responsabilità Riunioni di lavoro Risk Management Plan Dati per la pianificazione generale di progetto Riserve economiche Assetti contrattuali Sensori di rischio Indicatori Oggettivamente Verificabili (IOV) 7.5. Descrizione generale Al termine di questa Attività si disporrà di una preziosa lista di azioni e delle relative responsabilità organizzative che permetteranno di minimizzare l impatto che i singoli elementi di rischio possono avere sulla riuscita generale del progetto agendo sia sulla probabilità di accadimento che sull entità del danno previsto per essi. Il Modello delle Strategie Euromethod [4] fornisce indicazioni sulle possibili modalità di gestione di un progetto in base alla valorizzazione di alcuni fattori di rischio che sono classificati in termini di complessità ed incertezza, secondo lo schema seguente, e che fanno riferimento sia al contesto applicativo del progetto e all impatto del sistema sull organizzazione (rischi organizzativi) che al sistema informativo automatizzato previsto (rischi tecnici). Fattori di rischio ascrivibili alla complessità Complessità gestionale Dimensioni del progetto Fattori di rischio ascrivibili all incertezza Incertezza dei requisiti Innovazione tecnologica Il modello prevede di derivare un insieme di indicazioni, in base alla classificazione degli elementi precedenti, in termini di: segmentazione del progetto (soluzione unica, incrementale, evolutiva) definizione dei punti di decisione da prevedere nel corso del progetto modalità di controllo del progetto (formalità bassa, media, alta) pag.15

16 Oltre ad indicazioni generali sull impostazione del progetto stimolate dall applicazione di un modello come quello precedente, è possibile derivare dall analisi del diagramma di contesto delle azioni specifiche per ogni elemento di criticità ivi individuato. Le azioni conseguenti potranno essere di tre tipi: di prevenzione, di sorveglianza e di contrasto. La prevenzione tende ad evitare che un certo elemento critico si manifesti nella sua problematicità. La sorveglianza serve a rilevare che un certo elemento critico si sta avvicinando alla zona di pericolosità o si è verificato e che è necessario correre ai ripari. Il contrasto esprime la reazione alla problematicità concretizzatasi e tende ad annullare gli effetti negativi del problema stesso. La prevenzione agisce soprattutto sulla probabilità dell elemento di rischio cercando di ridurla mentre il contrasto agisce soprattutto sugli effetti del danno cercando di minimizzarli o rimuoverli. Nel caso di un progetto eterodeterminato le azioni saranno prevalentemente rivolte all interno mentre nel caso di un progetto autodeterminato esse saranno rivolte all esterno. Per sorvegliare accuratamente un progetto occorre progettare e mettere in azione un insieme di sensori adeguati ai fenomeni da monitorare. Questi sensori possono essere sistemi socio-tecnici di vario tipo da quelli più meccanici a quelli più umani. Ad essi, però, occorrerà sempre associare un insieme di Indicatori Oggettivamente Verificabili (Objectively Verifiable Indicators - OVI) [6] che daranno la misura dello stato dell elemento di rischio. Per creare un OVI occorrerà individuare: Metriche Strumenti di misura Fonti di origine delle misure Procedure di raccolta Modalità di verifica dei dati Se il piano di azione viene ben pensato, messo in opera e seguito fedelmente rappresenterà una forma di assicurazione contro gli infortuni di progetto che potrà essere complementata dalla stipula di vere e proprie polizze assicurative che siano in grado di coprire rischi altrimenti ingestibili. Naturalmente occorrerà che il piano di azione RMP sia sostenibile da parte dell organizzazione nel senso che il suo costo sia rapportabile in modo positivo al danno derivante dal suo mancato impiego. Per fare questo occorrerà stimare in modo opportuno costi di gestione e perdite possibili utilizzando anche qui tecniche di analisi economica e finanziaria adeguate. Al fine di facilitare il processo di selezione delle possibili opzioni distinte di risoluzione di una criticità si potranno usare le tecniche di scelta pesata con l assegnazione di pesi sui vari fattori di qualità e voti sulle opzioni di scelta. pag.16

17 8. Esecuzione degli interventi L obiettivo di questa attività è di mettere in pratica le azioni che sono state progettate al fine di governare il rischio ed in particolare quelle di prevenzione, sorveglianza e contrasto. Saranno rilevate tutte le misure necessarie a valutare l efficacia e l economicità del piano di gestione del rischio RMP. Tabella Input 8.2. Tecniche e Strumenti 8.3. Output Risk Management Database Risk Assessment Report Risk Management Plan Pianificazione generale di progetto Riserve economiche Assetti contrattuali Sensori di rischio Indicatori Oggettivamente Verificabili (IOV) 8.4. Skill necessari Capacità di ascolto Capacità gestionali Conoscenza delle tecniche specifiche Tecniche di negoziazione Tecniche di misura Azioni specifiche Prevenzione Sorveglianza Contrasto Contratti Misure sugli Indicatori Oggettivamente Verificabili (IOV) 9. Verifica dell efficacia degli interventi L obiettivo di questa attività è di valutare l efficacia e l efficienza dimostrata sul campo dal piano di gestione del rischio RMP al fine di confermarne la validità o di innescare una fase di revisione del sistema di gestione del rischio. Da questa attività si potrà procedere ad una nuova fase diagnostica (RA1 e RA2) oppure alla definizione di nuove e più efficaci azioni di governo (RA3). E previsto il rilascio di un rapporto di valutazione per la Direzione e gli attori interessati. Tabella Input 9.2. Tecniche e Strumenti 9.3. Output Risk Management Database Risk Assessment Report Risk Management Plan Eventi realmente accaduti Misure sugli Indicatori Oggettivamente Verificabili (IOV) 9.4. Skill necessari Capacità analitiche Capacità descrittive Conoscenza delle tecniche specifiche Checklist Risk Management Evaluation Report pag.17

18 10. Conclusioni Il rischio è una variabile gestionale importante per la riuscita di un progetto. E, quindi, necessario affrontarlo in modo metodico e con la giusta assegnazione di risorse umane, economiche e temporali. Non è sicuramente possibile ne conveniente eliminare tutti i fattori di rischio che sono in grado di produrre danni ad un progetto. Un accurata analisi tecnicoeconomica potrà aiutare a determinare il giusto equilibrio tra rischi da eliminare e costi di intervento. Le procedure di gestione del rischio possono fare la loro comparsa a pieno titolo tra quelle previste per la realizzazione di un Sistema di Qualità conforme alle norme ISO Il presente lavoro ha descritto un metodo denominato SAFE (Safe Activities For Enhancement) per la gestione completa di tutti gli aspetti legati al governo del rischio. A partire da questo modello di processo è possibile ritagliare, apportando le opportune personalizzazioni, le proprie procedure organizzative che risulteranno compatibili con gli approcci Euromethod e quelli sviluppati al Software Engineering Institute. Il modello SAFE è stato elaborato nel corso di due anni nell ambito di interventi di consulenza e formazione sul Project Management dove ha dato prova di efficacia. Nel futuro la elaborazione concettuale continuerà sul fronte della estensione del metodo, della descrizione di opportune cheklist e della compatibilità con le tecniche di gestione più affermate. 11. Referenze [1] Gluch, David P., A construct for describing software development risks, Technical Report CMU/SEI-94-TR-14, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 1994 [2] Archibald, R.D., Project Management: La gestione di progetti e programmi complessi, Franco Angeli, Milano, 1994 [3] Carr, M.J., Konda, S.L., Monarch, I., Ulrich, F.C., Walker, C.F., Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 1993 [4] Eurogroup consortium, Euromethod: Strategy Model, Version 0, 1994 [5] Haimes, Y.Y., Chittister, C., An acquisition Pocess for the Management of Risks of Cost Overrun and Time Delay Associated with Software Development, Technical Report SEI-93-TR-028, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, 1993 [6] Commission of the European Communities, Project Cycle Management Manual, Netherlands, Feb, 1993 [7] Davis, G.B., Strategies for Information Requirements Determination IBM Systems Journal, Vol.21, No 1, 1982 [8] McFarlan, W., Portfolio Approach to Information Systems, Journal of Systems Management, Jan [9] Boehm, B., Software Risk Management: Principles and Practices, IEEE Software, Jan pag.18