0
UNIVERSITA’ DI PISA
Dipartimento di Economia e Management
Corso di Laurea Magistrale in Strategia, Management e Controllo
IL PROCESSO DI PROJECT RISK MANAGEMENT E L’IMPORTANZA
DI TOOL EFFICACI DI SUPPORTO – IL CASO LEONARDO
Relatore:
Chiar.mo Prof. Marco Giannini
Tesi di Laurea Magistrale Federico Ammannati Matricola 491680
1
Indice
PREFAZIONE ... 3
1. IL SISTEMA DEL RISK MANAGEMENT ... 6
1.1 Cenni generali sul Risk Management ... 6
1.2 Il processo di Project Risk Management – generalità ... 9
1.3 Il processo di Project Management ... 20
1.3.1. Attori del processo e schemi organizzativi applicabili ... 24
1.4 Gli Integrated Project Team ... 28
1.5 Gli applicativi software a supporto del Project Risk Management .. 34
2. IL CASO LEONARDO ... 39
2.1 Introduzione ... 39
2.2 Presentazione del gruppo Leonardo ... 40
2.3 Evoluzione Organizzativa del gruppo Leonardo ... 45
2.4 L’organizzazione della unità operativa Project Risk Management nel gruppo Leonardo ... 50
2.5 Framework normativo del gruppo Leonardo in ambito Risk Management ... 53
2.6 Il processo di Project Risk Management del gruppo Leonardo ... 55
2.6.1 Classificazione del progetto ... 57
2.6.2 Identificazione dei Rischi ... 60
2.6.3 Valutazione dei Rischi ... 63
2.6.4 Trattamento dei rischi o risposta al rischio ... 66
2.6.5 Gestione delle contingency ... 68
2.6.6 Monitoraggio e Revisione dei rischi ... 71
2.6.7 Reporting ... 73
2.6.8 Archivio dei rischi ... 76
3: TERRA IL TOOL PROPRIETARIO LEONARDO A SUPPORTO DELLE DECISIONI IN AMBITO PROJECT RISK MANAGEMENT ... 78
2
3.2 Genesi del tool TERRA... 79
3.3 Analisi delle principali caratteristiche del tool TERRA ... 82
3.3.1. Generalità su TERRA ... 83
3.3.2 TERRA caratteristiche chiave ... 84
3.3.3 Integrazione dei dati di progetto ... 86
3.3.4 Condivisione delle informazioni ... 87
3.3.5 Profilatura delle utenze ... 88
3.3.6 Supporto al processo durante il ciclo di vita del progetto ... 90
3.3.7 Gestione dei Risk Register ... 91
3.3.8 Utilizzo di algoritmi statistici ... 93
3.3.9 Storicizzazione schede rischio ... 94
3.3.10 Gestione delle fasi di vita del rischio ... 95
3.3.11 Movimentazione delle contingency ... 96
3.3.12 Storicizzazione del Risk Register ... 98
3.3.13 Reporting ... 99
3.3.14 Segregazione del dato ... 101
4 CONCLUSIONI ... 102
3
PREFAZIONE
Questo lavoro, dopo aver analizzato i principi basilari del Risk Management
nella sua accezione di base, si propone di approfondire il processo di
Project Risk Management visto attraverso gli schemi indicati delle best
practices internazionali maggiormente diffuse ed applicabili ad aziende che
operano su grandi progetti.
Il presente lavoro, pertanto, si propone di esaminare ed approfondire il
processo di Project Risk Management e come lo stesso si integri nel più
ampio processo di gestione dei progetti (Project Management) facendo
anche riferimento agli schemi organizzativi tipici delle aziende che operano
con quest’ultimi, per poi descrivere ed evidenziare l’importanza di dotarsi
di strumenti informativi efficaci per poter assolvere alle principali esigenze
di carattere gestionale, di analisi, di reporting e di gestione delle
contingency associate ai rischi di progetto.
L’analisi si è focalizzata sulle competenze ed esperienze di una delle più
importanti aziende italiane operante nel settore della Difesa ed Aerospazio:
Leonardo S.p.A. (in seguito denominata Leonardo).
La stesura di questo lavoro conclusivo degli studi magistrali, ha natura non
compilativa, infatti le modalità con cui il sottoscritto ha potuto approfondire
l’argomento si sono estrinsecate attraverso un’attività formativa a La
Spezia e attraverso apposite interviste al personale specializzato
4
Con la disponibilità ed il supporto del personale della Unità Operativa
Project Risk Management di Leonardo, è stato possibile analizzare come
il processo di Project Risk Management sia stato modellato su una realtà
aziendale molto variegata che, peraltro, in tempi recentissimi ha subito una
importante riorganizzazione a livello di strutture e processi.
Di fondamentale importanza, per la stesura di questo lavoro, è stato il
supporto datomi da due manager di Leonardo, l’ing. Sante Torino e il dott.
Paolo Paladini: il primo è il responsabile del processo di Project Risk
Management di Leonardo, vanta una grande esperienza in ambito Risk
Management, ha conseguito le certificazioni internazionali PMI-RMP ed
IPMA, è autore di vari articoli sul Project Management e su Project Risk
Management presentati in vari congressi internazionali; il dott. Paolo
Paladini è invece la persona che, nel gruppo Leonardo, ha maggiormente
contribuito alla evoluzione del tool TERRA e che ha il compito di farlo
ulteriormente evolvere in chiave futura. Anche il dott. Paladini ha
conseguito la certificazione internazionale PMI-RMP, persona esperta di
Project Management ed è responsabile, oltre che dello sviluppo del tool,
anche dell’analisi ed il reporting di gruppo.
L’azienda, basandosi sulle migliori pratiche internazionali, ha scelto di
implementare sul proprio processo di Risk Management uno strumento
informatico “su misura” sviluppato internamente sulla base delle
5
L’analisi e l’attività svolta, in questo contesto lavorativo, ha cercato proprio
6
1.
IL SISTEMA DEL RISK MANAGEMENT
1.1 Cenni generali sul Risk Management
Nell’attuale concezione dell’azienda moderna, le attività di gestione dei
rischi sono percepite come imprescindibili nelle attività del Management in
stretta relazione sia con la Corporate Governance (per l’esigenza del
Vertice Aziendale di ricevere tutte le informazioni necessarie per
un’efficace gestione del rischio), sia con il Sistema di Controllo Interno (per
l’esigenza di garantire un corretto presidio dei rischi a cui è esposta l’attività
aziendale).
In letteratura non vi è unanimità sul significato da attribuire al concetto di
“rischio”. Di fronte alle innumerevoli definizioni che di volta in volta vengono
attribuite al termine “rischio” è possibile individuarne una fornita da Ward
nel 2008 secondo cui il rischio è “la manifestazione di una condizione
incerta che, quando si verifica, genera un effetto positivo o negativo su un
obiettivo” (economico, finanziario, temporale, qualitativo).
Tutte le aziende, nel contesto attuale, devono continuamente affrontare
eventi incerti e la sfida del management è quella di determinare il quantum
dell’incertezza che sia accettabile per poter comunque “creare valore”.
L’incertezza assume una duplice valenza, infatti può rappresentare sia un
rischio, che un’opportunità e quindi può potenzialmente ridurre o
accrescere il valore dell’azienda. Un evento può avere un impatto negativo,
7
“rischi” che possono ostacolare la creazione di valore o erodere quello
esistente. Eventi con un impatto positivo possono compensare impatti
negativi o possono costituire “opportunità”. Le opportunità sono possibilità
che un evento si verifichi e influisca positivamente per il conseguimento
degli obiettivi, contribuendo così alla creazione di valore oppure
preservando quello esistente.
Il Risk Management ha il compito di identificare, prevenire, contenere o
ridurre gli impatti negativi e massimizzare le opportunità ed i risultati positivi
nell’interesse degli stakeholder.
Il Risk Management deve essere visto come un processo in itinere che
origina dalle “valutazioni strategiche dell’azienda” in merito alla fattibilità
del progetto e che deve continuare per tutto il ciclo di vita del progetto
stesso. L’applicazione di questa logica favorisce la creazione di Valore per
l’Azienda tramite la massimizzazione dei profitti e la minimizzazione delle
perdite, promuove l’immagine e la sicurezza all’esterno (clienti, fornitori e
stakeholder vari) ed all’interno dell’azienda (dipendenti ed azionisti).
Per poter implementare un sistema di Risk Management è importante, se
non indispensabile, che all’interno dell’Azienda sia utilizzato un linguaggio
comune che permetta di apprezzare il sistema dei rischi aziendali nel suo
insieme, il tutto affiancato da una chiara politica di gestione dei rischi e da
una altrettanto chiara attribuzione di responsabilità.
Metodologie, tecniche e sistemi di supporto per l’identificazione, la
8
adeguati piani di gestione che affrontino i rischi a livello aggregato. E’
inoltre di fondamentale importanza l’integrazione del processo di gestione
dei rischi all’interno dei sistemi di definizione degli obiettivi, di elaborazione
9
1.2 Il processo di Project Risk Management – generalità
Per descrivere velocemente il processo di gestione dei rischi di progetto,
possiamo utilizzare la Guida al Project Management Body of Knowledge
(Guida PMBOK ®) pubblicato dal Project Management Institute (PMI) che
nella sua Sesta Edizione fornisce le linee guida per la gestione dei singoli
progetti e definisce i concetti legati al Project Management (figura 1). Lo
standard indicato dal PMI non è l’unico esistente, in dottrina ci sono molti
altri riferimenti a cui ispirarsi, ma si può ritenere questa guida come best
practices generalmente accettata.
La Guida PMBOK ® identifica le “buone prassi” che, se osservate, possono
incrementare le probabilità di successo su una ampia gamma di progetti,
10
Il Project Risk Management è individuato come ottava area di conoscenza
del Project Management e viene definita come “la conduzione dei processi
legati alla pianificazione della gestione dei rischi, alla loro identificazione e
analisi, alla preparazione delle risposte ai rischi e al loro monitoraggio e
controllo nel corso del progetto”. La guida individua anche quale sia lo
scopo specifico dell’analisi del rischio, ovvero indica che tale analisi deve
essere condotta al fine di “aumentare la probabilità e l’impatto di eventi
positivi e nel diminuire la probabilità e l’impatto di eventi dannosi per il
progetto”.
Secondo la Guida PMBOK ® (figura 2) la gestione dei rischi di progetto si
scompone in sei sotto-processi distinti che interagiscono tra loro in primis,
ma che comunque si integrano con gli altri processi tipici delle aree di
conoscenza del Project Management.
11
Si rende necessario quindi;
1) “pianificare la gestione dei rischi” andando a definire le modalità di
esecuzione delle attività di gestione dei rischi di progetto. Il piano di
gestione dei rischi è fondamentale per comunicare ed ottenere l’accordo
ed il sostegno da parte di tutti gli stakeholder al fine di garantire che il
processo di gestione dei rischi sia supportato ed eseguito in modo efficace
nel corso della vita del progetto. Questo piano definisce la metodologia, i
ruoli e le responsabilità, il budget, la tempistica, le categorie di rischio, le
definizioni di probabilità ed impatto del rischio, la matrice di probabilità ed
impatto, la tolleranza al rischio per gli stakeholder, il reporting.
2) La fase successiva è quella riferita alla “identificazione dei rischi”. Il
processo infatti, si pone lo scopo di identificare i potenziali eventi di rischio
e/o di opportunità atti a influenzare il conseguimento dei risultati aziendali,
con riferimento sia ai fattori esterni (ad esempio, l’evoluzione economica,
tecnologica, competitiva, regolatoria, socio-politica e ambientale) sia ai
fattori interni alla società (ad esempio, processi, risorse, tecnologie,
infrastrutture). Il processo prevede inoltre la documentazione delle
caratteristiche dei rischi.
L’identificazione dei rischi è una fase molto costosa perché richiede il
tempo e l’impegno di diverse persone che devono dedicare l’attività
lavorativa per identificare tutte le possibili fonti di rischio che l’azienda
12
Esistono diverse tecniche a supporto dell’identificazione dei rischi le quali
non necessariamente sono alternative una all’altra, ma possono essere
utilizzate anche simultaneamente.
Le più diffuse sono:
• Analisi dell’esperienza passata: questa tecnica risulta essere fondamentale per riconoscere le principali classi di rischi aziendali. Si basa
sull’esperienza personale dei soggetti presenti in azienda e sulla presenza
di archivi storici finalizzati a registrare gli eventi più utili a tale scopo. In
questo senso le check-list rappresentano un elenco di categorie di rischi il
cui obiettivo è proprio quello di agevolarne l’individuazione all’interno di un
determinato contesto imprenditoriale. Le check-list sono dei promemoria di
possibili rischi, compilati sulla base di esperienze pregresse
nell’organizzazione produttiva o da esperti del settore in cui si colloca lo
specifico prodotto/servizio. Tale strumento risulta essere poco costoso ma
alquanto inadeguato nell’individuare rischi che non sono riportati
nell’elenco formulato.
• Le Interviste vengono realizzate singolarmente con un campione significativo di soggetti che possono contribuire a tale scopo; normalmente
l’intervistatore si avvale di un questionario predisposto a tale fine. Questa
tecnica è utile per l’identificazione di rischi operativi e potenziali di natura
13 • Il Brainstorming ed il Workshop sono tecniche di gruppo il cui scopo è generare idee per la risoluzione di determinati problemi. Sono molto utili
per identificare rischi particolarmente complessi e loro eventuali
correlazioni.
Per garantire un’efficace gestione dei rischi di progetto è necessario che
gli stessi siano identificati il più presto possibile ovvero sin dalle fasi iniziali
di offerta e dalle prime fasi del ciclo di vita del progetto ( essendo
l’incertezza maggiore nelle fasi iniziali), per poi subire evoluzioni
successive nel corso dell’esecuzione del processo. Tuttavia è necessario
ripetere l’attività di identificazione iterativamente lungo il ciclo di vita del
progetto su base periodica, anche al fine di includere ulteriori rischi non
noti inizialmente (rischi emergenti). L’identificazione va ripetuta in
particolare nel passaggio dalla fase d’offerta alla fase contrattuale ed
all’approssimarsi di momenti chiave o cambiamenti significativi del progetto
(ad es. atti aggiuntivi al contratto in essere).
3) Una volta terminata questa fase potremo passare ad “eseguire l’analisi
qualitativa dei rischi”, e quindi l’assegnazione delle priorità ai rischi tramite
la valutazione e la combinazione della probabilità di accadimento del
rischio e del relativo impatto. Questo processo consente al Project
Manager di concentrarsi sui rischi ad alta priorità. Eseguire l’analisi
qualitativa dei rischi è in genere un mezzo rapido ed economicamente
14
Le tecniche qualitative utilizzano parole o scale descrittive per
rappresentare effetti economici e probabilità di realizzazione dell’evento
rischioso. La tecnica probabilità-impatto tra queste è lo strumento più
diffuso e potente per stimare i rischi come combinazione di probabilità di
accadimento e severità delle conseguenze.
Per determinare la probabilità ed impatto del rischio vengono utilizzate
delle tabelle da cui possiamo derivare gli indici di probabilità (Ip) che
rappresentano il risultato di un’operazione di confronto tra il rischio
identificato e una serie di situazioni di diversa incertezza in cui ci si può
trovare e l’indice di impatto (Ii) che viene invece valutato su costi, tempi e
performance, attraverso il confronto del rischio identificato con le situazioni
di diversa gravità indicate.
Una volta determinati gli indici di Probabilità e di Impatto è possibile
determinare l’indice RPI (Risk Priority Index) o Fattore di Rischio da
assegnare al rischio specifico.
Il Risk Priority Index (RPI) viene utilizzato per ordinare i rischi secondo una
priorità di importanza/urgenza ai fini della successiva definizione delle
azioni di trattamento.
4) Eseguire l’analisi quantitativa dei rischi è invece il processo di analisi
numerica dell’effetto dei rischi identificati sugli obiettivi complessivi del
15
numeriche che sono in grado di supportare efficacemente il processo
decisionale.
Un rischio viene quantitativamente definito attraverso due elementi distinti:
• Una percentuale che rappresenta la stima delle probabilità che il rischio si verifichi;
• Una valutazione quantitativa dell’effetto del rischio in termini di stima dei maggiori costi dell’attività, a cui il rischio è associato, e dagli eventuali
ritardi sulle milestones di progetto su cui il rischio ha impatto.
Il costo del rischio è rappresentato quindi da una distribuzione di probabilità
che si articola in un intervallo di possibili valori economici, tenendo conto
del fatto che il costo generato dagli effetti di un rischio, nel momento in cui
accade, può realisticamente manifestarsi con una molteplicità di valori
comunque riconducibili ad un intervallo.
Esistono varie metodologie applicabili a questa fase, in genere sono
utilizzate:
• Analisi di sensibilità che aiutano a determinare quali rischi hanno il maggiore impatto potenziale sul progetto;
• Analisi del Valore Monetario Atteso (EMV);
• Simulazioni Monte Carlo.
5) Dopo aver quantificato il rischio occorre “pianificare le risposte” al fine di
16
gli obiettivi del progetto individuando azioni mirate. In genere sono
applicabili varie strategie che devono essere valutate sulla base della
maggiore o minore probabilità di rivelarsi efficaci.
Le strategie applicabili alle minacce (figura3) consistono in evitare,
trasferire, mitigare o accettare il rischio; le strategie applicabili alle
opportunità invece prevedono di sfruttare, potenziare, condividere o
accettare il rischio.
In particolare: la strategia “mitigazione” prevede azioni preventive rispetto
al verificarsi del rischio tali da rimuoverne le cause, ridurne la probabilità di
accadimento e/o gli effetti. Possono essere classificate ex ante in azioni di
prevenzione se hanno effetto sull’indice di probabilità, o di protezione se
hanno effetto sull’indice di impatto. Recovery/correttive costituite da azioni
correttive da attuare quando il rischio si è verificato, al fine di ridurne
17
“Evitare il rischio” è una strategia in base alla quale si agisce per eliminare
la minaccia o proteggere il progetto dall’eventuale impatto.
“Trasferimento": azioni atte a trasferire a terzi (clienti, fornitori ecc.)
l’impatto di una minaccia insieme alla responsabilità della risposta.
“Accettazione”: nel caso in cui non vi sia modo di incidere sul rischio e
nessuna azione specifica possa essere portata avanti.
Le risposte pianificate ai rischi devono essere appropriate all’importanza
del rischio, essere economicamente vantaggiose e concordate con tutte le
parti coinvolte sul progetto.
6) Occorre infine “monitorare e controllare i rischi”; quest’ultima fase è molto
importante in quanto si procede a controllare i rischi individuati, ad
aggiungerne di nuovi se questi sono sorti in corso d’opera e a valutare
l’efficacia dei piani di risposta precedentemente implementati.
Il rischio di progetto, come abbiamo già visto nel paragrafo iniziale, ha le
sue origini nell’incertezza presente in tutti i progetti. I rischi noti sono quelli
che sono stati identificati ed analizzati e per i quali sono state pianificate
opportune azioni di mitigazione. Possono inoltre esistere rischi che, per
quanto noti, non possono essere gestiti proattivamente e che quindi
necessitano di una riserva loro assegnata. Esistono infine rischi ignoti che,
18
Le organizzazioni e gli stakeholder sono disposti ad accettare vari livelli di
rischio a seconda della loro attitudine, in genere l’atteggiamento verso il
rischio è definito dai seguenti elementi:
• Propensione al rischio (il livello di incertezza ritenuto accettabile in previsione di una ricompensa);
• Tolleranza al rischio (il grado, quantità o dimensione del rischio che un individuo o una organizzazione può tollerare);
• Soglia di rischio (misura del livello di incertezza o di impatto al quale uno stakeholder può avere un interesse specifico. Al di sotto di tale soglia,
l’organizzazione accetterà il rischio. Al di sopra l’organizzazione non lo
tollererà);
Questi elementi devono sempre essere chiari, infatti il progetto potrà
essere accettato se i rischi rientrano nelle tolleranze e se sono in equilibrio
con i ritorni che si possono ottenere una volta che i rischi sono stati assunti.
Per ottenere i risultati attesi è necessario che il processo di Project Risk
Management sia condotto in modo proattivo e sistematico nel corso di tutta
la vita del progetto.
In genere il rischio del progetto sarà più elevato nel momento in cui sarà
avviato. Tale affermazione sarà più vera nel caso di un progetto dal
contenuto innovativo, in cui le attività che si presentano con carattere di
novità superano quelle che invece si presentano con carattere di ripetitività.
19
e saranno necessarie revisioni periodiche al fine di monitorare i rischi
identificati e di intercettare e gestire nuove e non previste minacce. Un
atteggiamento attento e proattivo alla gestione del rischio minimizza la
20
1.3 Il processo di Project Management
In questo capitolo viene analizzato come il processo di Project Risk
Management sia intrinsecamente collegato al processo generale di Project
Management. Probabilmente la mera elencazione delle varie fasi in cui
viene eseguito il processo di Project Risk Management non rende
evidente, specie ai non addetti ai lavori, quali e quante relazioni si vanno a
creare con tutta la struttura aziendale.
Il Project Risk Management, in sintesi, si colloca in un crocevia di processi,
culture, obiettivi diversi e sempre in divenire. Per affrontare correttamente
questo processo servono quindi conoscenze ed abilità trasversali
supportate efficacemente da un sistema di gestione capace di intercettare
le varie sfumature che ogni volta il progetto porta con sé.
Il Project Management, come del resto il Project Risk Management, si
applica ai progetti.
Archibald nel suo lavoro sul Project Management afferma che: “Progetto si
definisce, di regola, uno sforzo complesso di durata solitamente inferiore a
tre anni, comportante compiti interrelati eseguiti da varie organizzazioni
con obiettivi, schedulazioni e budget ben definiti”.
In questa definizione si possono osservare due elementi, la “temporaneità”
dell’iniziativa e “l’unicità” del risultato. L’elemento temporale chiarisce che
un progetto ha un inizio ed una fine definiti. La fine si raggiunge quando
21
applicabile a tutti i progetti). L’elemento della “unicità” del risultato, invece,
si associa al fatto che sebbene in genere siano utilizzabili processi ripetitivi
e procedure già esistenti, le incertezze e le differenze nei prodotti o nei
servizi realizzati richiedono, ogni volta, pianificazioni specifiche rispetto a
quanto svolto di routine.
Un progetto può essere rappresentato da un triangolo i cui lati sono
identificati in tempo, costo e ambito. Questi elementi costituiscono i tre
vincoli principali a cui il Project Manager deve sottostare.
• Il tempo indica i termini entro i quali il progetto deve essere completato.
• Il budget indica il costo che non deve essere superato.
• L’ambito descrive il lavoro richiesto per il completamento del progetto. Il Project Manager può agire su queste variabili modificandole una in
funzione
dell’altra. Così, per rispettare i tempi in caso di difficoltà, potrà aumentare
il budget o modificare l’ambito del progetto (ad esempio ridimensionando il
risultato prefissato). Se invece vorrà rispettare ambito e budget dovrà
essere più flessibile sui tempi.
Per descrivere il processo di Project Management si utilizzano le definizioni
indicate nella Guida PMBOK ®. Questo processo, più ampio di quello di
Project Risk Management, illustrato nella figura 4 si esegue tramite la
corretta applicazione ed integrazione di ben 47 processi di Project
22
genere caratterizzano il ciclo di vita gestionale di un progetto (ciclo di avvio
– pianificazione – esecuzione –monitoraggio – controllo e chiusura).
Durante la fase di avvio, le principali attività riguardano l’implementazione
del project charter, del registro degli stakeholder e di molti altri documenti
che contribuiscono alla fase di pianificazione tramite il piano di Project
Management. Attraverso questo strumento vengono raccolte le regole
gestionali e i processi di Project Management che saranno implementati e
viene posta l’attenzione sui piani di progetto, la cui ufficializzazione risiede
nella baseline di progetto (Project Baseline).
Le fasi successive si identificano nell’esecuzione (Executing) e nel
monitoraggio (Monitoring and controlling) durante le quali vengono
23
quindi alla misurazione delle performance misurando gli stati di
avanzamento tramite l’analisi dell’Earned Value.
Infine, verranno redatti i documenti per la chiusura del progetto (Closing)
con particolare attenzione alle lesson learned, ovvero le lezioni apprese
24
1.3.1. Attori del processo e schemi organizzativi applicabili
Nei paragrafi precedenti sono state citate alcune figure e/o strutture
aziendali tipiche del processo di Project Management e di Project Risk
Management. Il Project Manager è una di queste. In estrema sintesi lo
potremmo descrivere come la persona responsabile della valutazione,
pianificazione, gestione e controllo di un progetto; non è un manager
funzionale in quanto non è focalizzato su un’area funzionale, in genere
svolge il proprio ruolo attraverso il gruppo di progetto e altri stakeholder.
Il Project Manager deve possedere doti tecniche per poter organizzare il
progetto, ma deve avere anche equilibrio, valori etici, capacità relazionali,
leadership per guidare adeguatamente il gruppo di progetto.
Il gruppo di progetto (Project Team) è un gruppo di persone, appartenenti
ad enti diversi, che partecipano allo svolgimento del progetto.
Il Project Management Office (PMO) è l’ufficio cui l’azienda o
l’organizzazione demanda lo sviluppo della cultura di progetto, la
formazione e il coordinamento dell’attività di Project Management.
I compiti del PMO spaziano dal coordinamento dei progetti alla gestione
dell’infrastruttura di Project Management al coaching e all’assistenza nella
gestione dei progetti.
Sia il Project Manager che il Project Team sono variamente influenzati dalla
25
maturità del processo di Project Management saranno presenti in azienda
organizzazioni, tool e sistemi diversi.
Nel caso in cui il progetto coinvolgesse anche soggetti esterni, come per
esempio in una joint venture, il progetto sarebbe influenzato da un numero
ancora maggiore di variabili.
La cultura dell’organizzazione è un fattore ambientale capace di
influenzare la capacità di un progetto di raggiungere gli obiettivi prefissati.
Immaginiamo di doverci confrontare nell’ambito di un progetto
internazionale; in tale caso la cultura diventa un fattore veramente critico
dovendo gestire diverse organizzazioni, sedi e persone nel mondo. In
genere la struttura organizzativa incide sulla disponibilità delle risorse e
sulle modalità di gestione del progetto. I modelli organizzativi utilizzati dalle
aziende sono i più vari, il modello classico è quello di una organizzazione
funzionale che rappresenta la tipologia di organizzazione più diffusa, ad
esempio, nelle PMI. Questa struttura è estremamente efficiente nella
gestione delle attività caratteristiche e ripetitive, offre una catena di
comando e controllo verticale che favorisce la specializzazione e quindi le
economie di scala di apprendimento. Per contro non facilita gli scambi
orizzontali e il lavoro di gruppi interdisciplinari (i più tipici nei progetti). In
queste strutture organizzative l’autorità del Project Manager è minima, non
ci sono risorse a lui assegnate, il budget del progetto viene gestito dai vari
26
In atre realtà troviamo invece delle organizzazioni a matrice che sono una
via di mezzo, per così dire, fra le organizzazioni funzionali classiche e
quelle per progetti. Il personale assegnato ad un progetto viene coordinato
da un Project Manager che solitamente fa parte dello staff dell’azienda. La
matrice si dice debole, bilanciata o forte a seconda dell’indipendenza e del
peso del Project Manager.
A mano a mano che si passa da un modello a matrice debole ad un modello
a matrice forte vediamo crescere il ruolo del Project Manager, la quantità
di risorse dedicate da bassa può arrivare ad essere elevata, il budget del
progetto non è più gestito dai manager funzionali ma è attribuito al Project
Manager, il ruolo stesso del Project Manager da Part-time passa a tempo
pieno (figura 6).
Troviamo poi strutture organizzate per progetto, in questi casi siamo
all’opposto rispetto alle organizzazioni di tipo funzionale; per ogni progetto
viene costituito un team dedicato, guidato dal Project Manager che è
responsabile dei risultati. Il Project Manager in queste organizzazioni gode
di un elevato livello di indipendenza ed autorità, gestisce un gruppo stabile
di persone che lavorano a tempo pieno sul progetto, dispone
completamente del budget necessario e si dedica a tempo pieno al
27
Ciascuna struttura organizzativa ha vantaggi e svantaggi. Talvolta nella
stessa azienda troviamo progetti gestiti a matrice ed altri per progetto; tutto
dipende dalla cultura aziendale, dal mercato di riferimento, dal livello di
28
1.4 Gli Integrated Project Team
Questo schema è tipico di molte aziende caratterizzate da processi
complessi ed orientate fortemente a progetti che operano in un ambito
internazionale molto competitivo, dove la soddisfazione del cliente
rappresenta un elemento centrale per il raggiungimento degli obiettivi
aziendali.
Parleremo quindi, in termini generali, degli Integrated Project Team e delle
competenze che devono essere presenti perché questo tipo di
organizzazione possa funzionare correttamente.
La gestione dei progetti tramite Team di progetto integrato è un modello
gestionale divenuto popolare negli Stati Uniti negli ultimi anni sia nel settore
privato che in quello pubblico; è stato adottato in particolare dalle aziende
del settore Aerospazio e Difesa che sono caratterizzate dalla presenza di
progetti complessi che meglio di altri possono capitalizzarne i vantaggi.
Un Team è un piccolo numero di persone con competenze complementari
che si impegnano per uno scopo comune, obiettivi di rendimento e un
approccio per il quale si ritengono reciprocamente responsabili.
Gli Integrated Project Teams sono costituiti per realizzare un team
multidisciplinare che, sotto la guida di un IPT Leader, è responsabile del
raggiungimento degli obiettivi del/i Progetto/i assegnato/i. La costituzione
29
garantisce un’adeguata attenzione verso il raggiungimento degli specifici
obiettivi aziendali nel rispetto dei tempi pianificati e dei costi preventivati.
Gli IPT necessitano di una loro formalizzazione da parte della direzione
aziendale anche perché è necessario definire le relazioni ed i ruoli dei
membri del Team con le funzioni specialistiche aziendali. Un impegno
gestionale scritto è una condizione indispensabile per far funzionare
correttamente un’organizzazione in quanto le attribuzioni del Team in
termini di autorità e di autonomia devono coesistere con le procedure
aziendali formalmente stabilite e presenti all’interno della organizzazione
aziendale.
I Team di progetto devono poter individuare chi lavorerà al progetto, non
potranno avere una autorità assoluta sull’assunzione o sulla rimozione dei
membri del Team, ma devono poter avere una certa influenza sulle
questioni relative al personale in base alle prestazioni dei singoli. In questi
casi si ricorre ad una valutazione congiunta tra il responsabile dell’IPT ed
il responsabile della funzione per bilanciare le esigenze del team rispetto
alle funzioni.
Gli IPT devono essere responsabilizzati sia dal management che dalle
funzioni specialistiche affinché possano prendere le decisioni tecniche in
modo indipendente e senza interferenze da parte delle funzioni dirette. Se
ogni decisione tecnica dovesse passare attraverso i capi funzionali per
30
di progetto sarebbe enormemente limitata ed il ciclo di sviluppo non
sarebbe abbreviato.
L’IPT ha lo scopo di creare un ambiente in cui tutti gli Stakeholder interni
all’azienda lavorano in partnership per il successo del progetto e
concordano sul modo di lavorare per massimizzarne l’efficienza e
l’efficacia.
Per poter funzionare correttamente l’IPT deve veder realizzate alcune
condizioni:
• deve essere chiaramente individuato un singolo elemento di responsabilità e di “accountability” per tutti gli output richiesti (IPT
leader);
• IPT deve comprendere rappresentanti di tutte le necessarie discipline funzionali e gli stakeholder; questi lavorano insieme e,
dove possibile, operano nello stesso ambiente (sono co- locati);
• le risorse, ove possibile, devono essere assegnate funzionalmente all’IPT in modo stabile e permanente, per dare la migliore
combinazione delle competenze disponibili attraverso tutte le fasi del
ciclo di vita del progetto;
• le risorse devono essere dimensionate secondo la grandezza e la complessità del Progetto;
31 • IPT deve operare con spirito di squadra ed i suoi componenti devono
condividere finalità ed obiettivi comuni;
• IPT deve avere chiaramente definite le responsabilità e la accountability ed i suoi componenti devono possedere elevati livelli
autorizzativi ed il più ampio livello di delega possibile,
compatibilmente con quanto previsto dal Business Management
System aziendale;
• gli IPT devono essere dotati di livelli di responsabilità e rappresentatività adeguati all’importanza strategica ed al volume di
business del progetto/contratto gestito.
Ogni IPT è incaricato di individuare, presso il Cliente e gli Stakeholder, le
figure di riferimento per il successo del progetto che possono essere sia
interne che esterne all’azienda, in funzione degli accordi commerciali in
essere e dalla complessità del progetto da realizzare. Gli Stakeholder
hanno sia una dimensione interna (il senior management responsabile del
successo dell’IPT e coloro che operano a supporto dell’IPT leader) sia una
dimensione esterna (clienti e fornitori)
Definire una “Visione” condivisa e i conseguenti fattori di successo è
cruciale per costituire un’identità comune e una chiarezza d’intenti
trasversalmente a tutto l’IPT. I fattori di successo dovrebbero essere
32
conseguentemente documentati e comunicati sia a tutti i componenti
iniziali dell’IPT, sia a tutti i nuovi componenti, che, nel tempo, entrano a far
parte del team.
Le informazioni relative all’andamento del progetto all’interno e all’esterno
dell’IPT sono gestite attraverso un numero di riunioni e riesami. Tutti i
membri di un IPT, indipendentemente da dove siano localizzati,
dovrebbero potersi incontrare fisicamente almeno una volta al mese,
questo è necessario per condividere lo stato di avanzamento delle attività
di progetto e mantenere la corretta gestione dei costi, dei tempi e delle
prestazioni dei prodotti da fornire ai clienti.
I vantaggi dell'utilizzo di team di sviluppo di progetti integrati sono notevoli.
Probabilmente il vantaggio più importante è la riduzione del tempo
necessario per portare un nuovo prodotto dall'idea iniziale al prodotto finale
finito, disponibile al pubblico. Accorciare il ciclo di sviluppo offre a
un'azienda un vantaggio rispetto ai suoi concorrenti. Ciò si traduce anche
in un risparmio di costi complessivo per lo sviluppo del nuovo prodotto.
I sostenitori dei team di progetto sono pronti a sottolineare i vantaggi del
loro utilizzo; raramente però menzionano le minacce che invece è bene
aver sempre presenti.
L'appartenenza a un team di progetto richiede la collaborazione di ciascun
33
è quella di integrare i requisiti di tutte le funzioni specialistiche man mano
che il design si evolve dall'inizio alla fine del processo.
Tuttavia, non tutte le persone hanno la capacità di lavorare in un’ottica di
squadra. Alcuni individui sono solitari per loro natura, alcune persone
semplicemente non riescono a lavorare in modo produttivo con gli altri.
Pertanto, nella fase iniziale, i tassi di turnover nell'uso dei team sono
spesso alti poiché i membri devono imparare a lavorare insieme in modo
coerente.
Per dirigere i team durante le prime fasi del progetto viene normalmente
utilizzato personale tecnico. A volte però alcuni di questi team leader,
esperti in materia tecnica, non sono ancora pronti per gli incarichi di
gestione e devono essere sostituiti.
L'uso dei team spesso richiede che i Project Manager vengano coinvolti in
attività estranee alle loro competenze come il reclutamento e
l'addestramento del personale, le revisioni delle prestazioni dei dipendenti,
la rimozione e la sostituzione dei membri del team.
Infine, i team di progetto, se utilizzati per un periodo prolungato, potrebbero
ridurre l'esperienza tecnica e la base di conoscenze dell'organizzazione
madre. In questo senso le organizzazioni “funzionali” offrono la possibilità
di sviluppare basi di competenza tecnica maggiormente durature nel lungo
34
1.5 Gli applicativi software a supporto del Project Risk Management
Avendo inquadrato nei paragrafi precedenti il processo di Project Risk
Management come uno dei nove processi di Project Management e dopo
aver preso atto di quali e quante relazioni si instaurano durante l’attività
operativa di conduzione di un progetto, verrà analizzato il tema relativo
all’importanza di disporre di un sistema informativo efficace a supporto del
processo di Project Risk Management e quali caratteristiche chiave
dovrebbero essere presenti per garantire e supportare efficacemente il
processo.
Volendo fare un elenco delle caratteristiche chiave di un tool di Risk
Management, sebbene questo possa non essere esaustivo, potremmo
elencare i seguenti elementi determinati dalla letteratura e dalle best
practice internazionali.
• Condivisione delle informazioni. Come abbiamo visto l’attività di conduzione del progetto coinvolge, a secondo della struttura organizzativa,
varie e diverse funzioni aziendali: gli IPT con tutti i rappresentanti delle
unità specialistiche, gli enti di Amministrazione Finanza e Controllo,
Acqusiti, Supply Chain ecc.; tutti questi attori devono poter comunicare
velocemente ed efficacemente specie se si trovano ad operare in siti
diversi. Quindi un importante obiettivo del sistema informatico sarà quello
di poter raggiungere il maggior numero di utenti in modo semplice e
35
rilevante per la difesa della proprietà intellettuale aziendale e per la
necessità di difendere i dati riservati del cliente.
• Il Reporting del sistema dovrà poter dirigere le informazioni in modo mirato alle persone che sono operativamente coinvolte sul progetto. Informazioni
di dettaglio saranno necessarie a livello operativo. Passando da attività
semplici ad attività più complesse la tipologia di informazione dovrà trovare
adeguate forme in modo da poter essere resa disponibile agli utilizzatori
ad un livello più alto.
• Supportare la metodologia e le metriche che l’azienda si è data attraverso le procedure e l’organizzazione. La diffusione di un linguaggio
comune all’interno dell’azienda attraverso tool, procedure ed
organizzazioni standard è di fondamentale importanza affinché il progetto
possa essere eseguito con successo.
• Integrazione dei dati di progetto. Evidentemente non è possibile pensare che il processo di Project Risk Management possa essere eseguito tramite
dei semplici fogli Excel gestiti in autonomia dai vari gruppi di progetto.
Solitamente in azienda sono utilizzati strumenti in grado di gestire la
pianificazione operativa in termini di tempi e milestone (es. MS Project e
Primavera), i costi, la fatturazione e gli incassi ecc.. Ognuno di questi
strumenti dovrà interfacciarsi con il tool per poter raccogliere le
36 • Gestione dei Risk Register. Un tool di supporto efficace per il Risk Management deve poter gestire il risk register di progetto permettendone
il continuo aggiornamento come richiesto dalle best practices
internazionali.
• Utilizzo di algoritmi statistici. A supporto della fase di valutazione quantitativa ed in quella di analisi e reporting il tool dovrebbe poter gestire
algoritmi di tipo statistico per costruire il profilo di rischio economico
dell’intero progetto. Lo strumento statistico (es. analisi Monte Carlo)
consente di determinare la distribuzione di probabilità dei costi legati al
verificarsi o meno dei rischi di progetto e mediante la rappresentazione
della curva cumulata di tali probabilità, permette di individuare il grado di
copertura corrispondente ad ogni valore del monte contingency
complessivamente allocato.
• Storicizzazione schede rischio. Mantenere traccia della storia della singola scheda rischio deve essere una caratteristica importante di un tool,
attraverso questa caratteristica è possibile seguire la singola scheda
rischio nel ciclo di vita del progetto.
• Gestione delle fasi di vita del rischio. Ogni rischio nel corso dello svolgersi del progetto, subisce vari cambiamenti di stato. Il sistema deve
poter indicare i rischi che non sono ancora occorsi, quelli che si stanno
37
applicare specifiche azioni di gestione per limitare gli effetti del rischio sul
progetto.
• Movimentazione delle contingency. La contingency è un valore dinamico che va adattato all’evolversi del profilo di rischio economico del
progetto. Un sistema efficace di Risk Management deve prevedere
strumenti atti a monitorarne l’andamento nel tempo.
• Storicizzazione del Risk Register. Dato che il risk register è uno di documenti di progetto più importanti, un tool efficace deve permette la
storicizzazione delle diverse versioni corrispondenti ai diversi stadi di
evoluzione di progetto partendo dalla baseline fino alla revisione ennesima,
per poterle eventualmente mettere a confronto e capire come il progetto si
sta svolgendo.
• Supporto al processo durante il ciclo di vita del progetto, In una ottica di Life Cycle Management il tool deve poter essere un supporto efficace
sia in fase di offerta che nella fase esecutiva del progetto. Anche in accordo
con le best practices il processo di Project Risk Management è iterativo e
quindi lo strumento informatico deve essere in grado di soddisfare ogni
esigenza di rivalutazione dei rischi di progetto.
• Segregazione del dato. Il processo di Project Risk Management richiede l’utilizzo di una mole notevole di dati e di informazioni. Il tool informatico
38
opportune autorizzazioni che possano consentire solo alle persone
deputate l’accesso in scrittura e lettura ai dati.
• Profilatura delle utenze, Il sistema informatico deve poter distinguere ed individuare le utenze in base al ruolo che ognuno riveste all’interno del
progetto e all’interno del processo; ad esempio devono essere attribuiti
profili diversi a coloro che possono inserire o leggere dati rispetto a chi i
dati può autorizzarli o respingerli. Le utenze che in sistema informativo
deve gestire possono essere quelle dei partecipanti dell’IPT di progetto
39
2. IL CASO LEONARDO
2.1 Introduzione
In questo capitolo, sulla base di quanto descritto precedentemente
riguardo alle fasi del processo di Project Risk Management ed alle
caratteristiche distintive di un tool efficace, verrà analizzato come il gruppo
Leonardo abbia deciso di implementare tali elementi, soffermando l’analisi
sulle peculiarità che lo caratterizzano.
I successivi paragrafi hanno la finalità di evidenziare, in questo lavoro,
come il gruppo Leonardo abbia costruito un sistema su misura al proprio
processo di Project Risk Management facendone un caso distintivo rispetto
40
2.2 Presentazione del gruppo Leonardo
Leonardo, uno dei maggiori operatori mondiali nell’industria
dell’Aerospazio, Difesa e Sicurezza, è una realtà industriale integrata che
opera nei settori ad alta tecnologia (figura 7). Operando al fianco di Governi
e Istituzioni, cittadini e comunità, Forze Armate e Agenzie di Intelligence
Leonardo progetta e realizza un’ampia gamma di prodotti, sistemi, servizi
e soluzioni integrate che coprono le esigenze di difesa, protezione e
sicurezza in ogni possibile scenario d’intervento: terra, mare, cielo, spazio
e cyberspazio.
Dal 1 Gennaio 2016 Finmeccanica (poi Leonardo) non è più una holding a
capo di un gruppo di imprese ma è diventata un’azienda unica (che ha
incorporato per fusione le controllate OTO Melara e WASS e ha assorbito
41
ES) organizzata in 7 divisioni: Elicotteri, Velivoli, Aerostrutture, Sistemi
Avionici e Spaziali, Elettronica per la Difesa Terrestre e Navale, Sistemi di
Difesa, Sistemi per la Sicurezza e le Informazioni.
Il 28 aprile 2016 l’Assemblea degli Azionisti ha approvato la nuova
denominazione sociale di Finmeccanica. Da allora in avanti sarà Leonardo,
dopo sessantotto anni di storia, il marchio che ha identificato dal
dopoguerra ai nostri giorni l’industria ad alta tecnologia nel nostro Paese
rinnovandosi nel segno modernissimo dell’opera di Leonardo da Vinci,
innovatore ante litteram e simbolo universale d’ingegno e creatività
applicati a ogni campo d’indagine.
Il cambio di nome rappresenta la logica conclusione di un percorso di
rinnovamento profondo che ha preso avvio con la trasformazione il 1^
gennaio 2016 - da holding finanziaria a One Company, società industriale
unica, integrata e concentrata nei settori chiave dell’aerospazio, difesa e
sicurezza.
Leonardo raccoglie così il testimone di un percorso industriale importante,
iniziato ancor prima della stessa Finmeccanica, con l’obiettivo di
rappresentare nel mondo la nuova immagine di azienda globale e
all’avanguardia tecnologica.
La decisione di cambiare il nome all’Azienda nasce dalla volontà di sancire
la forza e la qualità del cambiamento in atto e di assumersi la responsabilità
42
raccontare al mondo la portata di un grande processo di trasformazione
che si è concretizzato con il battesimo operativo della nuova One
Company. Grazie a questa trasformazione l’Azienda non si identifica più in
una finanziaria (Finmeccanica - Società Finanziaria Meccanica) ma in
un'azienda operativa impegnata nella realizzazione di prodotti e servizi
tecnologicamente avanzati. Se il nome Finmeccanica non rispecchia più
l’identità, il nome Leonardo, invece, rappresenta il punto di sintesi dei valori
profondi che sono alla base dell’impegno quotidiano e che ne sostengono
le strategie.
In Leonardo si riscontra una storia importante di successi, un laboratorio
permanente per mettere alla prova competenze, passione e talento,
un’attitudine a guardare più lontano per immaginare soluzioni nuove, un
impulso costante alla ricerca e alla sperimentazione.
Leonardo svolge inoltre la funzione di Capogruppo e di Corporate Centre
per le controllate e le joint venture Leonardo DRS, Telespazio, Thales
43
Leonardo è una Società italiana quotata in borsa che esercita attività di
direzione e coordinamento sia sul suo business in Italia sia sulle aziende
estere da lei controllate (così come prescritto dal Codice Civile italiano)
attraverso Direttive interne, Policy e Procedure.
In qualità di leader nazionale nel settore della difesa, Leonardo ha avviato
negli ultimi anni una serie di iniziative industriali e strategiche volte ad
ottenere (quando consentito dalle regole di esportazione) un maggior
allineamento tra le sue aziende rispetto a una quantità di aspetti critici; tra
questi il coordinamento delle attività di Ricerca e Sviluppo, un sistema di
Famiglie Professionali volte a supportare la condivisione di best practices,
45
2.3 Evoluzione Organizzativa del gruppo Leonardo
Il modello di business di Leonardo (ex Finmeccanica) è sempre stato
caratterizzato da una forte presenza delle aziende sui mercati esteri.
L’esigenza di confrontarsi con partner e concorrenti molto strutturati ed
importanti ha reso necessario, per la società, dotarsi delle migliori pratiche
di gestione del business. Già dai primi anni 2000 erano presenti nelle
aziende dell’ex gruppo Finmeccanica processi, procedure, tool che
avevano lo scopo di gestire il processo di business secondo le migliori
pratiche. A questo proposito è importante citare alcuni progetti che hanno
dato al gruppo principi e logiche di business allineate a quelle delle aziende
internazionali più evolute.
A metà degli anni ’90 il gruppo Finmeccanica introdusse, quale sistema di
gestione integrato, il software SAP R3. L’introduzione di questo strumento
nelle aziende del gruppo portò con sé un cambiamento culturale,
organizzativo ed operativo fortissimo. Le aziende dovettero rifondare da
capo i processi contabili, gestionali ed operativi; i modelli organizzativi
gerarchici tipici del tempo lasciarono il campo ad organizzazioni a matrice
sempre più focalizzate sui business piuttosto che sulle funzioni operative.
Nel 1998 la ex Finmeccanica avviò la sperimentazione di un modello
innovativo fondato sui capisaldi della creazione del valore (Progetto
46
gruppo. L’adozione del modello comportò un’intensa attività di formazione
che coinvolse oltre 1600 dipendenti.
L’introduzione dei concetti di una prima organica disciplina in materia di
gestione dei rischi di progetto (Linee Guida di Gruppo sulla Gestione dei
Rischi), iniziarono a diffondersi nel Gruppo nel corso dell’anno 1999. Sono
infatti del tempo le prime procedure sulla gestione del rischio di progetto
all’interno delle varie società di Finmeccanica.
Nel corso dell’anno 2003 partì invece un altro importantissimo progetto che
aveva lo scopo di introdurre le moderne pratiche di gestione dei programmi
pluriennali. Prese infatti il via il progetto denominato “Life Cycle
Management & Project Control”; con questa metodologia si volle dotare il
Gruppo di una comune disciplina gestionale, incentrata sui principali
processi caratteristici dell’intero percorso di sviluppo dei progetti, dalla fase
iniziale della preventivazione a quella terminale dell’intero ciclo di vita.
Ancora in periodi successivi (2005), a valle di un maggior presidio del ciclo
di vita del prodotto, divenne sempre più importante avere un processo
strutturato di monitoraggio degli eventi più importanti del cammino critico
dei progetti. Prese quindi forma il processo di “Phase Review” che,
ricomprendendo le più significative milestone di controllo, permetteva una
valutazione complessiva e approfondita del reale stato di avanzamento
47
Negli anni successivi si è assistito ad un processo di miglioramento
continuo dei modelli di governo delle aziende e dei business collegati, le
evoluzioni tecnologiche sempre più veloci e gli scenari internazionali
sempre in continuo movimento hanno reso necessario adattare volta per
volta la struttura del Gruppo alla evoluzione del contesto esterno.
A ottobre del 2014 la Società, nel contesto della riorganizzazione delle
strutture centrali, ha istituito l’Unità Organizzativa Risk Management
affidandole, fra l’altro, la responsabilità del presidio delle attività relative alla
gestione dei rischi operativi e finanziari correlati ai progetti.
Il Corporate Center comprende le strutture centrali per il governo societario
(Funzioni di Supporto), che assicurano l’indirizzo ed il controllo del Gruppo
nonché l’erogazione di servizi comuni/condivisi. Tali Funzioni operano
secondo modelli di funzionamento opportunamente differenziati:
• Funzioni totalmente “centralizzate” (Relazioni Esterne, Comunicazione e Rapporti istituzionali, Relazioni con gli Investitori e SRI, Group Internal
Audit);
• Funzioni con presìdi operativi a livello di Divisione/Settore, che riportano gerarchicamente alle corrispondenti strutture centrali e funzionalmente al
Capo Divisione/Direttore di Settore (Legale, Affari Societari e Compliance,
Amministrazione, Finanza e Controllo, ICT, Security);
• Funzioni “decentrate” a livello di Divisione/Settore, con coordinamento funzionale delle corrispondenti strutture centrali (Risorse Umane e
48
Organizzazione, Analisi Competitiva e Strategie, Risk Management,
Programmi di Finanziamento Nazionale e Comunitario).
Le Divisioni sono dotate di capacità autonoma per sviluppare e gestire il
rispettivo portafoglio di business a presidio di uno specifico mercato di
riferimento con tutte le leve/risorse necessarie. Alle Divisioni sono stati
conferiti tutti i necessari poteri per garantire la gestione integrale del
relativo perimetro di attività ed è inoltre affidato il coordinamento operativo
delle controllate/partecipazioni correlate alla gestione del rispettivo
business.
Il nuovo assetto organizzativo in linea con quanto già posto in essere da
altri grandi gruppi internazionali dell’Aerospazio, Difesa e Sicurezza
(“ADS”), realizza una governance integrata e coesa con benefici in termini
di produttività, economie di scala e aumento della competitività che
semplifica la catena di controllo, con conseguente incremento
dell’efficacia, della flessibilità e della reattività operativa.
L’implementazione operativa del nuovo assetto organizzativo (figura 10) si
fonda su un processo di integrazione che mira anche ad aggiornare il
disegno e l’architettura dei controlli, evitando ridondanze e puntando
50
2.4 L’organizzazione della unità operativa Project Risk Management nel gruppo Leonardo
La Unità Organizzativa Risk Management (“RMA”) dal mese di ottobre
2014 opera alle dirette dipendenze dell’Amministratore Delegato, questa
scelta organizzativa ha costituito un elemento di novità rispetto alle
precedenti gestioni.
Il nuovo assetto organizzativo di Leonardo (figura 11) prevede la presenza
di unità di Risk Management a riporto diretto del Capo Divisione/Capo
Azienda, con riporto funzionale alla corrispondente struttura centrale.
Ancora oggi la dipendenza funzionale dalla Capogruppo è molto forte e
rappresenta un forte segnale in termini di sponsorship e committment. In
questa fase di cambiamento i Risk Manager hanno un ruolo centrale, infatti
oltre ad essere persone esperte, sono parte integrante di una community
di persone che oltre a diffondere nelle divisioni la metodologia, condividono
le “best practices” e “raccolgono le “lesson learned” in modo da formare un
unico team che parla un unico linguaggio utilizzando uno stesso strumento
51
Tra i principali compiti della unità operativa di Project Risk Management
troviamo quello di presidiare il processo, la metodologia e gli strumenti
operativi. In questo ambito è importante evidenziare la centralità del tool
TERRA che è lo strumento informatico a supporto del processo di Risk
Management e che viene utilizzato anche ai fini della reportistica
centralizzata. Tra gli elementi caratterizzanti il Project Risk Management
troviamo un aspetto molto particolare che potremmo definire “lavorare con
le Divisioni” che si esplica in un supporto continuo ai Risk Manager, ai
Project Manager e ai membri degli IPT di Divisione anche tramite attività di
affiancamento durante il lavoro quotidiano.
Capita con frequenza che taluni componenti della funzione di Risk
Management di Corporate, con la loro vista indipendente in quanto non
52
lavoro del team durante la fase di identificazione e valutazione dei rischi
53
2.5 Framework normativo del gruppo Leonardo in ambito Risk Management
Il corpo procedurale di Leonardo relativo al Project Risk Management è
sostanzialmente composto da n.2 documenti principali in lingua italiana ed
inglese:
• una Procedura che definisce i principi generali, i ruoli, le responsabilità, le modalità operative e i controlli interni relativamente al processo di Project
Risk Management (PRM) di Leonardo;
• il Manuale di Project Risk Management che definisce il processo di Gestione dei Rischi di progetto di Leonardo indicando gli elementi che ne
caratterizzano le fasi salienti e la metodologia da seguire.
I due documenti sono strettamente interrelati. Il primo descrive
sinteticamente il processo, il secondo lo va a specificare in modo
dettagliato indicando metodologie e metriche allo scopo di per facilitarne la
comprensione.
La procedura si ispira alle best practices internazionali e pone l’accento sul
ruolo centrale del Project Manager supportato dal Risk Manager e
sull’archivio dei rischi che rappresenta un data base storico che trova,
anche in questo caso, supporto nello strumento informatico unico adottato
54
passate in termini di identificazione, anticipazione, mitigazione e di governo
dei rischi in modo da poterle riutilizzare in futuro.
La procedura inoltre evidenzia l’importanza del tool TERRA quale unico
strumento per il supporto del processo di Risk Management a livello di tutta
la One Company.
Il Manuale pone invece l’attenzione sulla gestione del processo
sottolineando il fatto che i rischi debbano essere collegati agli obiettivi di
progetto e che questo debba accadere fin dalle sue fasi iniziali e quindi già
dalla fase di offerta. Il manuale fa inoltre riferimento a indicatori di rischio
chiari, semplici, univocamente comprensibili e sintetici che devono essere
in grado di rappresentare l’evoluzione del rischio di progetto, le azioni in
corso e quelle che potranno essere implementate per abbattere
55
2.6 Il processo di Project Risk Management del gruppo Leonardo
Dopo aver descritto nel primo capitolo il processo generale di Project Risk
Management secondo la Guida PMBOK ®, si analizza la modalità con cui
Leonardo, in linea con le best practices internazionali, abbia implementato
e sviluppato il proprio processo di Project Risk Management.
L’obiettivo di questo capitolo è quello di concentrarsi maggiormente sulle
specificità di Leonardo, cercando di far emergere i punti chiave presenti
nelle varie fasi del processo.
Il processo di Project Risk Management del gruppo Leonardo è un
processo iterativo che prende avvio fin dall’inizio della fase di offerta ed
opera per tutto il ciclo di vita del progetto. Si articola nei sotto-processi
illustrati e brevemente descritti, in termini di macro-attività e flusso logico,
56
La gestione del rischio globale di progetto e la conseguente gestione
operativa dei rischi si basa su un'analisi sistematica delle condizioni
contrattuali, delle attività di progettazione, delle tecnologie produttive
necessarie, delle specifiche di prodotto/processo in esame, delle
performance della supply chain, delle attività/forniture post-vendita e
dell’evoluzione delle marginalità di riferimento di ciascuna attività.
A tale analisi devono partecipare tutte le strutture aziendali coinvolte nella
fase di
preventivazione e/o gestione contrattuale, attraverso figure di riferimento
57
2.6.1 Classificazione del progetto
Una delle fasi peculiari del processo di Leonardo è proprio la fase di
classificazione del progetto che consente di stabilirne la rilevanza rispetto
al business. In questa fase i progetti vengono analizzati tramite un
algoritmo di calcolo ed inseriti in tre diverse classi di rischio A, B, C.; questa
attività trova la sua ragion d’essere nella complessità del business di
Leonardo.
La classificazione del progetto è utile perché fornisce un criterio unico per
la caratterizzazione della rischiosità dei progetti appartenenti ai differenti
business di Leonardo, inoltre fornisce un importante supporto per andare
ad individuare le attività a maggior rischio su cui concentrare l’effort.
La classificazione del progetto in classi di rischio avviene in fase di
elaborazione dell’offerta e successivamente in fase di negoziazione e
conclusione del contratto. Questo processo va ripetuto durante il suo ciclo
di vita, con cadenza almeno annuale (in corrispondenza della chiusura del
bilancio di esercizio).
A seconda della classe di appartenenza ogni rischio subirà specifiche
azioni di trattamento, in particolare:
• Progetti di classe A (alto rischio) e B (medio rischio), per i quali il processo di Risk Management viene applicato integralmente;
58 • Progetti di classe C (basso rischio), per i quali il Program/Project Manager/IPT Leader e il Risk Manager, previa opportuna valutazione
congiunta, possono stabilire di adottare modalità semplificate.
La classe di rischio si ottiene attraverso la valutazione ponderata degli
indici di impatto economico (misura dell’incidenza in termini di ricavo annuo
previsto del progetto in esame rispetto al ricavo medio annuo della Linea
di Business), strategico (valutazione qualitativa del grado di rilevanza
strategica del progetto) e di rischio specifico (misura del rischio specifico a
cui è esposto il progetto).
Le regole per quantificare ciascun indice sono indicate nel Manuale.
L’attribuzione della classe di rischio viene quindi definita in base al risultato
della somma del valore di ogni indice ponderato con i relativi pesi.
TERRA supporta questa fase tramite specifiche tabelle che possono
essere periodicamente aggiornate e storicizzate.
La classe di rischio potrebbe cambiare durante il ciclo di vita del progetto
e può quindi essere tracciata insieme agli altri dati del Risk Register. La
metrica che sottintende alla determinazione della classe di rischio è
unitaria in modo da avere un riferimento univoco a livello di One Company.
L’attività di classificazione è una delle caratteristiche distintive del processo
di Project Risk Management di Leonardo, svolgere questa attività è
importante in quanto sono presenti vari business con caratteristiche
