Risk Management: Un'analisi del processo di gestione dei rischi dei progetti software

3 
PRESENTAZIONE DELL’ELABORATO 
Lo scopo di questo elaborato è un’analisi del Project Risk Management (PRM), in un 
quadro di riferimento metodologico di Risk Management,  con un particolare focus sul processo 
di gestione dei rischi nell’ambito dei progetti di sviluppo software. 
I progetti che si riferiscono allo sviluppo del software sono intrinsecamente attività ad alto 
rischio poiché hanno l’obiettivo di rispondere a problemi complessi con delle soluzioni 
innovative entro vincoli di pianificazione, budget, risorse e tecnologie. 
Il rischio, che la qualità di un prodotto software sia scadente o che si superino i tempi e 
costi di sviluppo, è elevato, come emerge dai dati riportati dallo Standish Group nel Chaos 
Report (Standish Group, 2009) dove si riporta che circa tre progetti software su cinque falliscono 
e/o non rispettano gli obiettivi prefissati di budget o di pianificazione. Una efficace gestione di 
tali rischi è attualmente percepita come una delle aree più importanti della gestione di progetti 
(Fairley, 2008) 
Il PRM, processo sistematico di identificazione, analisi e risposta ai rischi di progetto, è un 
insieme di conoscenze finalizzate a stimare e gestire l’incertezza e il rischio dei progetti 
connesso alla possibile evoluzione di eventi futuri. Il PRM è un processo fondamentale in tutti i 
settori che prevedono una gestione per progetti (cantieristico, consulenza, sviluppo software, 
automobilistico, edile, civile, etc.). Le caratteristiche del progetto, quali dimensione, complessità, 
durata, location e il grado di novità influenzano in modo determinante i fattori di rischio. Lo 
scopo del PRM è, quindi, massimizzare sia la probabilità e le conseguenze degli eventi positivi, 
che ridurre le probabilità e le conseguenze degli eventi avversi al progetto.  
In questo elaborato, l’analisi del processo di gestione dei rischi dei progetti software è 
attuata attraverso una revisione sia della letteratura di riferimento che delle best practices più 
diffuse nel mondo professionale, ottenendo una visione sistematica ed integrata dell’argomento. 
Si parte dall’esame della gestione dei rischi di un generico progetto secondo lo standard ISO 
31000:2009 e conseguente modello proposto dal PMI nel PMBOK® (Project Management 
Institute (PMI), 2013). Dopo un’analisi delle peculiarità dei progetti software e dei principali 
modelli di processo software, si valutano le motivazioni che hanno, poi, portato gli accademici e 
i professionisti del settore ICT a definire e specializzare i processi di gestione rischi per i progetti 
software dei quali si esamina la natura e origine dei principali rischi. 
A conclusione dell’attività di “censimento” dei rischi più diffusi e/o comuni riguardanti lo 
sviluppo del software, è proposta, sulla base delle diverse top ten software risk presenti in 
letteratura, una rielaborazione di una lista strutturata di rischi utilizzabile da un Project Manager 
nella fase di identificazione dei rischi.  
Infine, sono esaminate le tecniche e i metodi utilizzati nelle varie fasi del processo di 
gestione dei rischi evidenziando gli scopi e le condizioni di applicabilità e, con un’indagine 
effettuata nella rete Internet, è identificato un insieme di tools software commerciali e non a 
supporto delle varie fasi del processo di gestione dei rischi.
7 
1 INTRODUZIONE 
I progetti che si riferiscono allo sviluppo del software sono intrinsecamente attività ad alto 
rischio poiché hanno l’obiettivo di rispondere a problemi complessi con delle soluzioni 
innovative entro vincoli di pianificazione, budget, risorse e tecnologie. 
Il rischio, che la qualità di un prodotto software sia scadente o che si superino i tempi e 
costi di sviluppo, è elevato, come emerge dai dati riportati dallo Standish Group nel Chaos 
Report (Standish Group, 2009) dove si riporta che circa tre progetti software su cinque falliscono 
e/o non rispettano gli obiettivi prefissati di budget o di pianificazione. 
Una efficace gestione di tali rischi è attualmente percepita come una delle aree più 
importanti della gestione di progetti (Fairley, 2008). Dato che gli attuali processi software 
lasciano ancora spazi di miglioramento, si punta a massimizzare la qualità e l’efficacia dei 
processi, riducendo al minimo i rischi di produzione del software. 
La vera sfida per l’attuale sviluppo del software è, pertanto, una efficace gestione dei rischi 
che migliori il rapporto successo/fallimento dei progetti software. Ciò richiede un profondo 
cambiamento di atteggiamento del team di progetto nel modo in cui il progetto stesso debba 
essere condotto. L'ambito di applicazione del progetto deve essere, inoltre, necessariamente 
ampliato sia per tenere conto di alternative modalità di sviluppo del progetto sia per analizzare i 
diversi fattori che potrebbero influenzare gli eventi futuri. 
Un progetto costituisce, sempre, una opportunità per ottenere un successo e creare nuovo 
valore per il cliente. Nessun progetto è privo di rischi. Un progetto senza la gestione dei rischi 
riconosce l’esistenza del rischio solo quando il rischio stesso si materializza come un problema 
reale (ad esempio, quando si supera il budget o non si rispetta la scadenza). Di solito, allora il 
team di progetto reagisce e si sforza nel minimizzare il danno causato dal problema. Come 
regola, questa è molto costosa ed consuma anche tempo. La mancanza di una comunicazione 
aperta, attitudine alla lungimiranza, coinvolgimento del team nella gestione del progetto 
software, comprensione dei requisiti dei clienti, conoscenza dei problemi specifici del contesto 
della produzione del software, espongono il progetto al grosso rischio di fallimento (Brown, 
1996). 
In particolare, i progetti software, sono sempre più sottoposti a “stress” dovuti ai 
cambiamenti per il veloce “invecchiamento” dei requisiti e dei relativi prodotti, necessaria 
conoscenza di tecniche innovative, rischi imprevedibili e non definiti, tempi sempre più limitati, 
risorse limitate, caratteristiche di multi-progetto/multi cliente, coordinamento trasversale di team 
funzionali, siti di produzione del software su differenti posizioni geografiche. 
Con questo elaborato, riconoscendo il ruolo sempre crescente della gestione dei rischi nella 
produzione del software, si effettua un’analisi del processo di gestione dei rischi nei progetti 
software. Si parte con una panoramica sulle caratteristiche di un progetto, obiettivi e processi di 
Risk Management e, dopo un esame dei vari modelli di sviluppo software, si arriva all’analisi 
delle diverse fasi del processo di gestione dei rischi con un approfondimento delle tecniche 
utilizzate per identificare, valutare e trattare i rischi dei progetti software.
8 
In particolare, dopo aver illustrato il contesto del Project Management (Capitolo 2) con le 
sue caratteristiche e i diversi approcci presenti in letteratura e/o in campo professionale, si 
esamina il ciclo di vita di un generico progetto evidenziandone le peculiarità nei suoi aspetti 
processivi ed organizzativi (Capitolo 3). Successivamente, sono analizzati gli standard di 
riferimento del Risk Management e le sue principali aree tematiche di applicazione (Capitolo 4), 
per passare, subito dopo, ad un necessario approfondimento dei principali modelli di processo 
del software (Capitolo 5) con relativi criteri di selezione adeguati alla tipologia del progetto 
software. E’ affrontato lo studio ed analisi del processo di gestione dei rischi (Capitolo 6) 
esaminando, innanzitutto, l’origine dei rischi di un progetto software e i criteri per definire se un 
progetto possa essere considerato di “successo”. Infine, con un esame della letteratura e delle 
best pratices più diffuse nel mondo professionale, sono esaminate le tecniche e i metodi utilizzati 
(Capitolo 7) nelle varie fasi del processo di gestione dei rischi evidenziando gli scopi e le 
condizioni di applicabilità. Inoltre, dopo un’indagine effettuata nella rete Internet, è indicato un 
insiem di software commerciali e non a supporto delle varie fasi del processo di gestione dei 
rischi di un progetto software.
9 
2 IL CONTESTO DEL PROJECT MANAGEMENT 
2.1 Le Caratteristiche del Progetto 
Le definizioni di Progetto che possono essere trovate in letteratura sono molteplici. Le più 
comuni e condivise sono: 
“Uno sforzo temporaneo intrapreso per creare un prodotto o un servizio unico” (PMI- 
Project Management Institute) 
“Uno sforzo complesso, di regola, di durata inferiore ai tre anni, comportante compiti 
interrelati eseguiti da varie organizzazioni, con obiettivi, schedulazioni e budget ben definiti” 
(Russel, 2004). 
“Un progetto è un’unica serie di attività volte a produrre un risultato definito, con una 
precisa data di inizio e di fine, ed una precisa allocazione di risorse” (Harvard Business School). 
“Un insieme di attività tra loro correlate e interdipendenti, volte al raggiungimento di un 
obiettivo preciso, con un limite di tempo determinato, un budget di risorse stabilite, che vengono 
avviate alla ricerca di un aumento di valore per l’azienda o per il soddisfacimento delle esigenze 
del cliente” (SDA Bocconi). 
Secondo la definizione data dal PMI (Project Management Institute) nel PMBOK®, un 
progetto “ è uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un 
risultato unici” (Project Management Institute (PMI), 2004). Il PMI Project Management 
Institute, è la più importante associazione “not-for-profit Professional” a livello mondiale 
fondata nel 1969 Philadelphia, USA, è il riferimento principale per lo sviluppo e certificazione 
ed oggi conta 420.000 iscritti tra Membership e Certificati con una crescita annuale del 10-15% 
con 250 Chapters in 70 Paesi e 30 Specific Interest Groups. La Project Management Body of 
Knowledge (PMBOK) è una guida, pubblicata dal Project Management Institute (PMI), che ha lo 
scopo di documentare e standardizzare le pratiche comunemente accettate di Project 
Management. 
Nella definizione data dal PMI, l’aggettivo “temporaneo” implica che ogni progetto ha un 
inizio e una fine definiti. La fine si raggiunge quando gli obiettivi del progetto sono stati 
raggiunti o quando appare evidente che sarà impossibile raggiungerli, o ancora quando il 
progetto non è più necessario e viene chiuso. L’unicità consiste nel fatto che il prodotto o il 
servizio differiscono in qualche modo da quanto già realizzato e la presenza di elementi ripetitivi 
non cambia la fondamentale unicità del prodotto / servizio realizzato(design, contesto, 
contractors) in quanto un progetto crea dei deliverable unici, che possono essere prodotti, servizi 
o risultati. 
Ogni progetto unico nel suo genere, con un proprio ciclo di vita di cui si parlerà in seguito 
è fortemente dipendente dal settore di riferimento, e risponde alle seguenti caratteristiche 
fondamentali:  
 deve raggiungere obiettivi ben definiti di durata, costo (budget) e risultato finale 
provenienti dal cliente;
10 
 ha associato dei rischi specifici; 
 può durare poche settimane o svariati anni ed avere ha una sequenza di attività 
interconnesse; 
 ha dei vincoli di qualità da rispettare; 
 può coinvolgere poche o molte persone di una o più organizzazioni/funzioni  
 ed ha termine quando gli obiettivi sono raggiunti non necessariamente in modo positivo. 
2.2 Il Project Management 
Il concetto di Project Management è antichissimo. Tutte le più note e importanti 
realizzazioni ingegneristiche ed edilizie (dall‘Antico Egitto, alla Cina, all‘Impero Romano) 
hanno necessitato per la loro realizzazione di efficaci forme di organizzazione. Tuttavia, il 
passaggio dalle forme primitive di organizzazione progettuale alle più avanzate metodologie di 
Project Management è stato reso possibile solo nel XX secolo, con l‘introduzione di nuove 
tecniche di programmazione, sviluppate nell‘ambito dei progetti militari e spaziali del Ministero 
della Difesa USA, della National Areonautics and Space Administration (NASA) e dell‘intero 
settore aeronautico americano 
Il Project Management consta di un insieme di tecniche e strumenti di gestione sviluppati 
dalla seconda guerra mondiale negli Stati Uniti d’America e poi sperimentate dagli anni 
cinquanta per progetti militari e per la realizzazione di opere infrastrutturali. Questo sistema 
utilizza e applica conoscenze di tipo ingegneristico per la semplificazione di attività lavorative 
particolarmente complesse che richiedono la contemporanea partecipazione di professionalità, 
conoscenze e tecnologie anche fortemente diversificate.  
Il Project Management Institute (PMI), istituzione di riferimento a livello mondiale nella 
definizione di standard di gestione dei progetti definisce come Project Management “ 
L’applicazione di conoscenze, abilità, strumenti e tecniche alle attività di progetto per 
soddisfarne i requisiti“ (Project Management Institute (PMI), 2004) mentre con un approccio di 
cultura manageriale R. Archibald in (Russel, 2004) lo definisce come sistema gestionale 
orientato ai risultati ovvero come una “gestione sistemica di un’impresa complessa, unica e di 
durata determinata, rivolta al raggiungimento di un obiettivo chiaro e predefinito mediante un 
processo continuo di controllo di risorse differenziate e con vincoli interdipendenti di costi 
tempi-qualità “. 
Il Project Management è, in sintesi, un sistema di gestione dei risultati (Miscia, 1994) 
basata su tre elementi fondamentali: 
 esplicitazione di responsabilità; 
 adozione di sistemi di pianificazione e controllo; 
 istituzione di un team di progetto. 
Il Project Management è in effetti una metodologia di conduzione dei progetti che richiede 
un mix di competenze interfunzionali prevalentemente di tipo gestionale ed organizzativo. Il 
metodo del Project Management è lo stesso in tutti i settori o aree applicative, per quanto