agile project management per la gestione di progetti nell ... · politecnico di milano facoltà di...
Post on 17-Feb-2019
221 Views
Preview:
TRANSCRIPT
POLITECNICO DI MILANO
Facoltà di Architettura Urbanistica e Ingegneria delle Costruzioni
Corso di Laurea Magistrale in Ingegneria dei Sistemi Edilizi
Agile Project Management per la gestione di
progetti nell’industria delle costruzioni
Relatore: Prof. Arch. Alberto Pavan
Tesi di Laurea di:
Veronica Zuccarella – Matr. 858361
Anno Accademico 2016/2017
Ai miei genitori, a mia sorella, a Marco
i
Indice dei capitoli
Indice delle Figure .............................................................................................................................................. v
Indice delle Tabelle ........................................................................................................................................... vii
Sommario .......................................................................................................................................................... ix
Abstract ............................................................................................................................................................. xi
1. Introduzione .............................................................................................................................................. 1
2. Il Project Management .............................................................................................................................. 3
2.1 Sviluppo del Project Management nel tempo ................................................................................... 3
2.1.1 I grandi progetti dell’antichità ................................................................................................... 3
2.1.2 La società industrializzata del primo ‘900 ................................................................................. 5
2.1.3 La Seconda Guerra Mondiale e il secondo dopoguerra ............................................................ 6
2.1.4 Il moderno Project Management .............................................................................................. 7
2.1.5 Le sfide del XXI secolo ................................................................................................................ 9
2.2 Caratteristiche dell’industria delle costruzioni ................................................................................ 11
2.2.1 Le categorie dei settori nell’industria delle costruzioni .......................................................... 11
2.2.2 Il mercato delle costruzioni in Italia ........................................................................................ 14
2.2.3 Processo di produzione nell’industria delle costruzioni e delle manifatture .......................... 21
2.3 Principi di Project Management ...................................................................................................... 26
2.3.1 Definizione di progetto ............................................................................................................ 26
2.3.2 Il ruolo del Project Manager .................................................................................................... 27
2.3.3 Ambito e campi di applicazione ............................................................................................... 29
3. Metodologie, linee guida e standard di qualita’ di project management ............................................. 31
3.1 Definizione standard e metodologie ............................................................................................... 32
3.2 Project Management Institute (PMI) -Project Management Book Of Knowledge (PMBOK) .......... 34
3.2.1 Struttura del PMBOK ............................................................................................................... 35
ii
3.2.2 Gruppi di processi del PMBOK ................................................................................................. 37
3.2.3 Aree di conoscenza del PMBOK ............................................................................................... 40
3.3 International Project Management Association (IPMA) - Competence Baseline (ICB) ................... 49
3.3.1 Le certificazioni in Project Management IPMA ....................................................................... 49
3.3.2 Struttura del Competence Baseline (ICB) ................................................................................ 51
3.3.3 Competenze tecniche .............................................................................................................. 53
3.3.4 Competenze comportamentali ................................................................................................ 55
3.3.5 Competenze contestuali .......................................................................................................... 56
3.4 Project in controlled Environment – PRINCE2 ................................................................................. 57
3.4.1 I Principi di PRINCE2 ................................................................................................................ 58
3.4.2 Le Tematiche di PRINCE2 ......................................................................................................... 60
3.4.3 I Processi di PRINCE2 ............................................................................................................... 61
3.4.4 Il ciclo di vita di un progetto .................................................................................................... 67
3.5 Gli Standard del Project Management ............................................................................................ 70
3.5.1 ISO 10006:2003 –Linee guida per la gestione della qualità di progetti ................................... 70
3.5.2 ISO 21500:2012 – Guida al Project Management ................................................................... 73
3.6 Analisi comparativa tra principali metodologie, metodi e standard ............................................... 77
3.6.1 Confronto tra i documenti ....................................................................................................... 77
3.6.2 Vantaggi e svantaggi delle metodologie .................................................................................. 90
4. Agile Project Management ...................................................................................................................... 95
4.1 Sviluppo di Agile Project Management nel tempo .......................................................................... 96
4.2 Principi e caratteristiche del Agile Project Management ................................................................ 98
4.2.1 Manifesto Agile ........................................................................................................................ 98
4.2.2 Fasi di un Progetto Agile ........................................................................................................ 100
4.3 La metodologia Scrum ................................................................................................................... 104
4.3.1 Il ciclo di vita Scrum ............................................................................................................... 105
iii
4.3.2 Gli attori del processo: il Team Scrum ................................................................................... 107
4.3.3 Gli eventi di Scrum ................................................................................................................. 108
4.3.4 Gli artefatti di Scrum.............................................................................................................. 111
4.4 La metodologia Kanban ................................................................................................................. 115
4.4.1 Kanban cards ......................................................................................................................... 115
4.5 Confronto tra metodologie Agile e tradizionali ............................................................................. 122
4.5.1 Ciclo di vita dello sviluppo ..................................................................................................... 123
4.5.2 Approccio al cambiamento .................................................................................................... 123
4.5.3 Il triangolo dei vincoli di progetto ......................................................................................... 125
4.5.4 Partecipazione del cliente ..................................................................................................... 126
4.5.5 Il team di lavoro ..................................................................................................................... 126
4.5.6 Comunicazione ...................................................................................................................... 127
4.5.7 Documentazione .................................................................................................................... 128
5. Agile Project Management nelle costruzioni ........................................................................................ 129
5.1 Applicabilità di Agile Project Management alle costruzioni .......................................................... 130
5.2 Agile Project Management nelle fasi di design e pre-design ........................................................ 133
5.2.1 Coinvolgimento del Cliente ................................................................................................... 133
5.2.2 Comunicazione e collaborazione del team di progetto ......................................................... 134
5.2.3 I meetings .............................................................................................................................. 135
5.3 Agile Project management nella fase di esecuzione: la programmazione mista .......................... 137
5.3.1 La programmazione tradizionale: il diagramma di Gantt ...................................................... 137
5.3.2 Un approccio integrato: tecniche tradizionali e Agile ........................................................... 139
6. Conclusioni ............................................................................................................................................ 147
7. Bibliografia ............................................................................................................................................. 151
iv
v
Indice delle Figure
Figura 1 - Crescita del settore delle costruzioni funzione del valore aggiunto (15) ........................................ 15
Figura 2 - Andamento dell’industria delle costruzioni in funzione della produttività del lavoro (15) ........... 16
Figura 3 - Andamento dell'occupazione e delle unità di lavoro (15) ............................................................... 17
Figura 4 - Andamento degli investimenti nei diversi comparti dell'industria delle costruzioni: abitazioni (in
alto), costruzioni non residenziali private (a sinistra) e opere pubbliche (a destra) (17) ............................... 18
Figura 5 - Andamento del numero di Imprese e addetti nel settore delle costruzioni (17) ............................ 20
Figura 6 - Confronto tra processo di produzione nell'industria delle costruzioni e delle manifatture ........... 21
Figura 7 - Confronto tra i beni prodotti nell'industria del mondo delle costruzioni e delle manifatture ...... 23
Figura 8- Fasi del ciclo di vita di un progetto (19) ........................................................................................... 27
Figura 9- Vincoli di progetto: tempo, costo, qualità, relazione con il cliente (7) ............................................ 28
Figura 10- Struttura del PMBOK 2012 (32) ...................................................................................................... 36
Figura 11- Gruppi di processi di Project Management (33) ............................................................................ 37
Figura 12- Livelli di certificazione IPMA (35) ................................................................................................... 50
Figura 13- Occhio delle competenze (36) ........................................................................................................ 51
Figura 14- Elementi di Competenza Tecnica dell’ICB e process steps (32) ..................................................... 54
Figura 15- Elementi di Competenza Comportamentali dell’ICB e process steps (32) ..................................... 55
Figura 16- Elementi di Competenza Contestuali dell’ICB e process steps (32) ............................................... 56
Figura 17- La struttura del PRINCE2 (38) ......................................................................................................... 58
Figura 18- Relazione tra processi, attività e azioni raccomandate (37) .......................................................... 61
Figura 19- I processi di PRINCE2 nel ciclo di vita del progetto ........................................................................ 67
Figura 20- Struttura della ISO 21500:2012 (32) ............................................................................................... 74
Figura 21- Tipi di elementi di input e/o output dei processi (22) .................................................................... 82
Figura 22 - Miglioramenti nelle realtà aziendale che hanno implementato metodologie Agile (47) ............. 95
Figura 23 - I 22 principi di Agile Project Management (47) ............................................................................. 98
vi
Figura 24- Esempio di Project Board, costituito da tre colonne, rispettivamente destinate ad attività "da fare",
"iniziate" e "concluse". .................................................................................................................................. 102
Figura 25 - Utilizzo delle diverse metodologie Agile sul mercato (47) .......................................................... 104
Figura 26 - Riassunto dei principi di Scrum: Team Scrum, Meeting, Documentazione (58) ......................... 105
Figura 27- Ciclo di vita di Scrum (59) ............................................................................................................. 106
Figura 28 - Ciclo di Scrum: meeting, documenti e attori coinvolti nel processo (47) ................................... 111
Figura 29 - Velocity chart. In blu è rappresentato il lavoro che il Team ipotizza di poter fare durante lo Sprint,
il verde rappresenta il reale lavoro prodotto durante lo Sprint (64) ............................................................ 113
Figura 30 - Esempio di Burndown Chart (59) ................................................................................................ 114
Figura 31 - Costruzione del Kanban board: suddivisione, dettaglio, limite WIP (67) .................................... 117
Figura 32 - Simulazione di gestione di un tipico processo di lavorazione; le frecce rosse indicano la sequenza
dei passaggi descritti ..................................................................................................................................... 118
Figura 33 - Utilizzo degli avatar nelle Kanban board e posizionamento sulle attività .................................. 119
Figura 34 - Kanban board con "corsia di emergenza" e attività contrassegnata con cartellino rosso ad indicarne
la priorità ....................................................................................................................................................... 120
Figura 35 - Scomposizione del flusso di lavoro nel caso di attività che devono necessariamente essere svolte
in parallelo ..................................................................................................................................................... 121
Figura 36- Costi per il processo di sviluppo Agile e tradizionale (70) ............................................................ 124
Figura 37- Triangolo dei vincoli di progetto: confronto tra approccio tradizionale ed Agile (71) ................. 125
Figura 38- Sforzo necessario per la produzione di documentazione di progetto, metodologia Agile e
tradizionale (74)............................................................................................................................................. 128
Figura 39- Esempio di diagramma di Gantt (58) ............................................................................................ 137
Figura 40- Tipologie di legame tra le attività del cronoprogramma (58) ...................................................... 138
Figura 41- Schema di una possibile soluzione per integrare le Metodologie Scrum e Kanban all’interno di una
programmazione tradizionale per un progetto dell’industria delle costruzioni. .......................................... 140
Figura 42- Scomposizione della macro-attività "Fondazioni" in cicli brevi e iterativi come previsto nella
metodologia Scrum ....................................................................................................................................... 142
Figura 43- Gli eventi Scrum durante un singolo Sprint: obiettivi e strumenti utilizzati ................................ 144
vii
Indice delle Tabelle
Tabella 1- Percentuale delle costruzioni negli Stati Uniti, scomposte per categoria di settore: residenziale,
commerciale, industriale e infrastrutture. Dati forniti dal United States Census Bureau e aggiornati a
Dicembre 2016 ................................................................................................................................................ 13
Tabella 2- Percentuale di costruzioni pubbliche e private negli Stati Uniti. Dati forniti dal United States Census
Bureau e aggiornati a Dicembre 2016 ............................................................................................................. 13
Tabella 3- Investimenti nel settore delle costruzioni in Italia, scomposti per comparti: residenziale nuovo,
residenziale recupero, non residenziale privato, non residenziale pubblico. Dati forniti da ANCE e aggiornati
a Gennaio 2017 ................................................................................................................................................ 14
Tabella 4- Investimenti nell’industria delle costruzioni in Italia. Elaborazione di dati stimati da ANCE. ........ 18
Tabella 5- I SIG (Specific Interest Group) dedicati a specifici settori applicativi in seno al PMI (19) .............. 30
Tabella 6- Numero dei processi del progetto considerati nelle cinque edizioni del PMBOK Guide (31) ........ 35
Tabella 7- Mappa dei Gruppi di Processi di Project Management e delle Aree di Conoscenza (33) .............. 41
Tabella 8- Elementi di conoscenza dei tre campi di competenza tecnica, comportamentale e contestuale. 52
Tabella 9- Processi di progetto nelle edizioni di PRINCE2 del 2005 e 2009 (31) ............................................. 57
Tabella 10- Mappa dei Gruppi di Processi di Project Management e dei Gruppi Tematici (41) ..................... 76
Tabella 11- Confronto di "concetti e definizioni" tra PMBOK e ISO 21500 ..................................................... 81
Tabella 12- Sintesi dell'analisi di "congruenza interna" dei processi (22) ....................................................... 82
Tabella 13- Confronto tra i Gruppi di Processo in PMBOK e ISO 21500 (44) .................................................. 84
Tabella 14- Confronto tra i Gruppi di Processo in PRINCE2 e ISO 21500 (24) ................................................. 84
Tabella 15- - Confronto tra Aree di Conoscenza, Gruppi Tematici e Processi in PMBOK e ISO 21500 (43) .... 86
Tabella 16- Confronto tra Aree di Conoscenza, Gruppi Tematici e Temi in PMBOK, ISO 21500 e PRINCE2 ... 87
Tabella 17- Parallelo tra Aree Tematiche in ISO 21500 ed Elementi di Competenza Tecnica (sinistra) e
Contestuale (destra) (22). ................................................................................................................................ 89
Tabella 18 - Confronto Agile Manufacturing e Agile IT (77) .......................................................................... 131
viii
ix
Sommario
Le principali metodologie e linee guida ed i più importanti standard in materia di Project Management sono
PMBOK, ICB, PRINCE2, ISO 10006:2003 e ISO 21500:2012, largamente diffusi sul mercato ed impiegati in
numerosi Paesi come riferimento per la gestione di progetti. Agli approcci tradizionali, rigidi, strumentali e
orientati al processo, si contrappongono le metodologie di Agile Project Management, leggere e flessibili, il
cui punto di forza è la capacità di adattarsi al cambiamento. Tra le metodologie Agile più diffuse, Scrum
prevede la scomposizione del processo in cicli brevi e iterativi e la partecipazione del Team Scrum ad una
serie di incontri strutturati, Kanban è uno strumento di facile lettura che consente un controllo costante dello
stato di avanzamento dei lavori.
Il mercato delle costruzioni, sempre più dinamico, competitivo e caratterizzato da progetti complessi,
richiede la ricerca di soluzioni di gestione che rispondano alle complessità del mercato e che siano flessibili
al cambiamento. In questo lavoro di tesi si è valutata l’applicabilità di Agile Project Management in un
processo costruttivo e si è elaborata una proposta di pianificazione integrata da impiegare nella fase
esecutiva, che abbini i vantaggi della pianificazione tradizionale a lungo termine a quelli delle metodologie
agili Scrum e Kanban.
Agile Project Management, utilizzato con successo nell’industria del software, potrebbe essere utilizzato per
la gestione di progetti costruttivi: in fase di progettazione, la strutturazione dei meeting secondo l’approccio
Scrum può aumentare il livello di successo dei progetti; in fase esecutiva, si suggerisce una approccio
integrato alla pianificazione che preveda la gestione dell’intera opera attraverso una programmazione
tradizionale ed il controllo delle macro-attività di cui si compone per mezzo delle metodologie Scrum e
Kanban.
Parole chiave: Agile Project Management, costruzioni, pianificazione integrata
x
xi
Abstract
The main methodologies, guidelines, and the most important standards in Project Management are PMBOK,
ICB, PRINCE2, ISO 10006:2003 e ISO 21500:2012 widely used on the market, and in numerous Countries as a
reference for Project Management. The traditional, rigid, instrumental and process-oriented approaches
contrast the light and flexible Agile Project Management methodologies, the strength of which is the ability
to adapt to change. Among the most popular Agile methodologies, Scrum provides for the breakdown of the
process in short and iterative cycles and the participation of Team Scrum in a series of structured encounters,
while Kanban is an easy-to-read tool that allows constant monitoring of the works' status.
The even more dynamic and competitive construction market, characterized by complex projects, requires
the search for management solutions that respond to market complexities and are flexible to change. In this
dissertation work, the applicability of Agile Project Management was assessed in a constructive process and
an integrated planning proposal was developed to be used at the execution stage, combining the advantages
of traditional long-term planning with those of the Agile methodologies, Scrum and Kanban.
Agile Project Management, successfully used for Project Management in the software industry, could be used
for construction projects: in the design phase, structuring of meetings according to Scrum can increase the
level of project success; in the execution phase, an integrated approach to planning is suggested, which
involves the management of the entire works through traditional programming and the control of its macro-
activities through the use of the Scrum and Kanban methodologies.
Key words: Agile Project Management, construction, integrated planning.
xii
1
1. Introduzione
L’industria delle costruzioni in Europa risulta essere fortemente frammentata, con una predominanza di
piccole e medie imprese che, in un ambiente fortemente competitivo e dinamico, si trovano ad affrontare
importanti sfide tra cui quelle di sopravvivere in un ambiente volatile e in continuo cambiamento e di sapersi
adattare velocemente alle mutevoli condizioni di mercato.
Nell’ultimo decennio, l’impiego delle metodologie tradizionali di Project Management per la gestione dei
progetti dell’industria delle costruzioni si è rivelato spesso inefficace nel garantire il successo, in termini di
tempi, costi e qualità, di una grande percentuale di progetti, indipendentemente dalla loro complessità. In
settori diversi rispetto a quello delle costruzioni, ad esempio nell’industria del software e in quella
manifatturiera, questa evidenza ha generato una spinta verso il cambiamento nonché l’adozione e la
diffusione di Agile Project Management, insieme di nuove tecniche e metodologie per lo sviluppo,
l’amministrazione e la gestione dei progetti e dei team dedicati al loro sviluppo.
Negli ultimi anni, la ricerca in ambito di Project Management sta iniziando ad interessarsi all’applicabilità
delle metodologie Agile, già ampiamente diffuse nell’industria del software, all’industria delle costruzioni,
viste le similitudini tra quest’ultima e l’ambiente di produzione IT ed i vantaggi che l’impiego delle nuove
metodologie potrebbe aggiungere alle tradizionali tecniche di gestione.
L’obiettivo di questo lavoro di Tesi è quello di valutare l’applicabilità di Agile Project Management all’industria
delle costruzioni e di ipotizzare un modello di pianificazione integrata di un progetto costruttivo, in cui si
combinino i vantaggi della programmazione a lungo termine propri degli approcci tradizionali e la flessibilità
caratteristica dei metodi Agile.
Il lavoro di Tesi qui presentato si compone di 5 Capitoli di cui, di seguito, si riporta una descrizione.
Nel Capitolo 2 è introdotto il tema del Project Management: nella prima parte si presenterà l’evoluzione
storica del Project Management nel tempo, con un accento sulle tecniche sviluppate; nella seconda parte si
identificheranno gli aspetti principali del mercato delle costruzioni, descrivendo le categorie di settore e le
loro singolarità, presentando un’analisi sull’andamento del mercato negli ultimi vent’anni e confrontando il
sistema produttivo del mondo delle costruzioni e quello dell’industria manifatturiera; nella terza e ultima
parte si riporteranno alcune nozioni riguardanti la definizione e le caratteristiche di un progetto, il ruolo del
Project Manager e i compiti di cui è responsabile; gli ambiti e i campi di applicazione del Project Management.
2
Nel Capitolo 3 saranno presentati e confrontati i principali standard e le più diffuse metodologie in materia
di Project Management, in particolare:
• Il PMBOK Guide: il “Project Management Book Of Knowledge” (PMBOK), scritto dal “Project
Management Institute”, è il modello di Project Management più diffuso al mondo;
• PRINCE2: il modello, sviluppato dall’agenzia “Central Computer and Telecommunication Agency” si
basa su processi, tematiche e principi a supporto del Project Manager;
• Competence Baseline (ICB): le linee guida proposte dall’ “International Project Management
Association” riportano e descrivono le diverse tipologie competenze proprie di un Project Manager;
• ISO 10006:2003, “Quality management systems – Guidelines for quality management in projects”;
• ISO 21500:2012, “Guidance on Project Management”.
Nel Capitolo 4 sarà presentato Agile Project Management: nella prima parte se ne illustrerà lo sviluppo nel
tempo e si riporteranno i principi fondamentali di Agile Project Management, comuni a tutte le metodologie
agili e formalizzati in quattro punti all’interno del manifesto Agile; nella seconda parte si presenterà una
panoramica dei due principali framework Agile; nella terza e ultima parte si confronteranno le metodologie
tradizionali con quelle Agile, identificandone le principali differenze. Le metodologie analizzate più nel
dettaglio nella seconda parte del capitolo sono:
• Scrum: saranno presentate le caratteristiche principali della metodologia Scrum e in particolare il
ciclo di vita Scrum, il Team Scrum, ovvero gli attori del processo, gli Eventi Scrum cioè le diverse
tipologie di meeting, e gli artefatti Scrum, ovvero i documenti prodotti durante il ciclo del processo;
• Kanban: oltre a presentare i vantaggi del framework, si riporteranno i passi più importanti da seguire
per costruire una lavagna Kanban, con la quale gestire il processo di produzione in maniera ottimale.
Nel Capitolo 5 si affronterà il tema di Agile Project Management nell’industria delle costruzioni: nella prima
parte si valuterà l’applicabilità delle metodologie Agile ad un processo di costruzione, riscontrando un
parallelo tra il modello di produzione in campo edilizio e quello dell’industria del software; nella seconda
parte si analizzeranno le aree principali in cui l’impiego di Agile potrebbe portare dei miglioramenti al
progetto nelle fasi di pre-design e design; nell’ultimo paragrafo si analizzerà una proposta di programmazione
mista, in cui i benefici della programmazione a lungo termine, propria delle tecniche di gestione tradizionale,
vengono combinati ai vantaggi offerti dall’utilizzo delle più diffuse metodologie Agile, quali Scrum e Kanban.
Nel Capitolo 6 si riporteranno le considerazioni conclusive, evidenziando sia i punti di forza che i limiti
dell’applicabilità del modello proposto per la programmazione mista ad un progetto delle costruzioni.
3
2. Il Project Management
In ingegneria gestionale ed economia aziendale, con l'espressione Project Management si intende l'insieme
delle attività volte ad analizzare, progettare, pianificare e realizzare gli obiettivi di un progetto, gestendolo in
tutte le sue caratteristiche durante ogni sua fase evolutiva, nel rispetto di precisi vincoli, in termini di tempi,
costi, risorse, scopi, qualità.
Nel presente capitolo si intendono approfondire le tematiche principali in ambito di Project Management,
partendo da una ricostruzione storica del suo sviluppo nel tempo, passando a caratterizzare l’industria delle
costruzioni nella quale viene ampiamente impiegato e concludendo con un accenno ai più importanti principi
di Project Management.
2.1 Sviluppo del Project Management nel tempo
L’attività di pianificazione, che costituisce uno dei cardini principali del Project Management, può considerarsi
un’abitudine connaturata in ogni individuo, spesso adottata in modo inconsapevole. Ciascuno di noi è infatti
allenato a pianificare le proprie azioni quotidianamente; si pensi, ad esempio, a tutte le attività che ognuno
di noi è abituato a svolgere ogni giorno, al risveglio: igiene personale, scelta dell’abbigliamento, prima
colazione. Ognuna delle macro-attività da completare è a sua volta riconducibile ad una serie di micro-attività
che ciascuno di noi espleta nella sequenza che permette di minimizzare il tempo necessario a completare il
loro insieme e, quindi, la singola macro-attività (1). Non soltanto l’attività di pianificazione può considerarsi
un’abitudine connaturata in ogni individuo, ma il ricorso alla sua applicazione ha accompagnato l’uomo fin
dall’antichità.
In questo paragrafo si presenterà la naturale evoluzione che il Project Management ha avuto nel tempo e si
ripercorreranno le caratteristiche della gestione dei progetti e delle tecniche, dall’antichità ad oggi.
2.1.1 I grandi progetti dell’antichità
I primi esempi di Project Management risalgono a migliaia di anni fa e riguardano, ad esempio, la
realizzazione delle piramidi in Egitto, del Colosseo, degli acquedotti dell’Impero Romano e della muraglia
cinese.
4
Alla costruzione delle piramidi d’Egitto, realizzate intorno al 2500 a.C., parteciparono, secondo Erodoto, circa
100.000 uomini che, durante le alluvioni del Nilo, si dedicavano alla costruzione delle piramidi non potendo
lavorare i campi. I progettisti e costruttori delle piramidi erano dotati di una grandissima capacità
organizzativa per la gestione della numerosissima manodopera. I principali problemi tecnici per l’epoca
riguardavano la scelta e il trasporto del materiale e la messa in opera dei blocchi, le cui dimensioni variavano
da 2 a 30 tonnellate (2).
Alcuni studi molto recenti, riguardanti le soluzioni organizzative adottate in Egitto per la costruzione delle
piramidi, sono riusciti ad evidenziare degli aspetti che presentano connessioni con le visioni attuali della
gestione dei progetti. Una prima analogia è relativa alla caratterizzazione del progetto che, in entrambi i casi,
è vincolato ad un obiettivo specifico, ad un tempo e a delle risorse predefinite da impiegare. Altre analogie
tra i progetti dell’Antico Egitto e quelli attuali sono da ricercarsi nella struttura organizzativa interna, nella
managerialità mostrata da coloro che guidavano la costruzione, nell’unità di intenti, nella complessità del
sistema di relazioni, nella ricerca dell’armonia e dell’integrazione con l’ambiente. Le analogie emerse,
dunque, inducono a pensare che le tipologie di problema che ci si trova ad affrontare quando si è responsabili
della gestione di un progetto oggigiorno sono molto simili a quelle che si presentavano in passato (3).
Oltre ad essere grandi costruttori di strade, i Romani si distinsero per le grandi opere di Ingegneria Idraulica,
diffuse in tutto il territorio dell’Impero, sia in Europa che in Africa Settentrionale e Medio Oriente. I Romani
diedero vita ai primi grandi cantieri mobili della storia, sia per le realizzazioni di strade che per le opere
idrauliche. Nel caso degli acquedotti, tra gli ostacoli più difficili da superare vi erano quelli legati alla
manutenzione e alla gestione amministrativa; le difficoltà in questo campo portarono i Romani ad
apprendere molti dei principi che oggi sono la base dell’ingegneria economica (4).
Un altro importante esempio di gestione di progetti nel passato è quello della costruzione delle cattedrali
gotiche realizzate durante gli ultimi anni del Medio Evo. L’organizzazione della costruzione era estremamente
complessa e vi collaboravano diverse categorie di artigiani e maestri d’arte con differenti qualifiche, relativi
apprendisti e un gran numero di manovali non qualificati. A capo del progetto era posto un architetto, le cui
funzioni erano quelle di progettare la cattedrale, coordinare e dirigere le fasi di costruzione, stipulare
contratti con maestri d’arte e artigiani. L’architetto medioevale, responsabile non solo della costruzione, ma
anche dei tempi, dell’approvvigionamento delle risorse e del loro efficace ed efficiente utilizzo, era una figura
integrata, con competenze dell’architetto e, in parte, dell’imprenditore e del Project Manager (4). Nel
progetto delle grandi cattedrali gotiche, i vincoli principali erano di tipo tecnologico; non c’erano invece
vincoli né in termini di risorse, umane e materiali, né di tempo, portando il progetto a concludersi spesso
oltre il secolo (2).
5
2.1.2 La società industrializzata del primo ‘900
Nonostante le analogie tra processi odierni e passati, però, in assenza di tecniche di programmazione non
era possibile rispettare simultaneamente tempi, costi e qualità del progetto. Il passaggio tra le più primitive
forme di Project Management e quelle odierne, più mature e complesse, avviene in seguito all’introduzione
e alla successiva evoluzione delle metodologie e delle tecniche di programmazione.
Nella società industriale del novecento, l’affermarsi di nuovi ritmi produttivi rese necessaria l’adozione di
metodi razionali semplici per la programmazione del lavoro, basati sull’individuazione di una sequenza di
attività elementari e sulla durata prevista nel tempo per ciascuna di esse. All’inizio del secolo XX lo
statunitense H.L. Gantt, lavorando a fianco di F. W. Taylor, elaborò una semplice tecnica di programmazione
del processo produttivo industriale mediante un diagramma a barre temporali, il diagramma di Gantt: ogni
singola attività è identificata con una barra di lunghezza variabile in funzione della durata ed è relazionata
con una scala del tempo, indicata sull’asse orizzontale, che ne definisce inizio, fine e durata.
Il diagramma di Gantt permette la rappresentazione grafica di un calendario di attività, utile al fine di
pianificare, coordinare e tracciare specifiche attività in un progetto dando una chiara illustrazione dello stato
d'avanzamento del progetto rappresentato. Uno degli aspetti non tenuti in considerazione in questo tipo di
diagrammazione è l'interdipendenza delle attività; solo negli anni ’90 furono introdotte nel diagramma le
linee di collegamento, definite link, che consentono di rappresentare con maggior precisione le dipendenze
esistenti tra le attività di progetto.
Alla fine degli anni ’30 del secolo scorso, nell’industria di beni di largo consumo nacquero le prime forme di
Product Management; l’idea è quella che un unico manager coordini tutte le diverse aree funzionali di
un’azienda (ricerca e sviluppo, produzione, marketing...) relative ad un singolo prodotto. L’analogia con il
Project Manager, nell’accezione odierna del significato, risiede nella capacità del Product Manager di gestire
un tipo di organizzazione basato sull’integrazione interdisciplinare (5).
Nel 1931, lo scienziato polacco K. Adamiecki mise a punto una metodologia per la programmazione dei tempi
di lavoro, in una forma chiamata Harmonygraph, descritta da un diagramma a barre “ruotato”, ossia con la
scala del tempo indicata dall’asse verticale e quella delle attività da un asse orizzontale. Queste prime
elaborazioni evidenziavano la durata prevista delle attività elementari, dando la possibilità di programmare
nel tempo l’intera sequenza del lavoro (6).
6
2.1.3 La Seconda Guerra Mondiale e il secondo dopoguerra
Nel corso della Seconda Guerra Mondiale videro la luce i primi progetti strutturati secondo la moderna
concezione del Project Management. Durante la Guerra Fredda per vincere era necessario competere per la
corsa agli armamenti, costruendo rapidamente armi di distruzione di massa. Fu dunque chiaro che, per la
gestione di progetti quali il bombardiere B52, il missile balistico intercontinentale Minuteman e il
sottomarino Polaris, fosse necessario un unico Project Manager che avesse la responsabilità completa
relativamente a tutte le fasi del progetto. Prima di allora, durante gli anni ’40, veniva utilizzato il concetto di
management over the fence per gestire i progetti. Ogni Project Manager seguiva uno specifico progetto per
poi gettare la palla “oltre lo steccato”, delegando ad un altro qualsiasi responsabilità sul progetto. Con un
management di questo tipo, il cliente non aveva uno specifico punto di riferimenti ed i responsabili a cui
richiedere informazioni erano tanto più difficili da identificare quanto più il progetto aumentava di
dimensioni e complessità (7).
Il progetto Manhattan, lanciato dal Governo degli Stati Uniti d’America, con l’obiettivo di realizzare armi
nucleari in anticipo rispetto al governo nazista, raccolse i maggiori esperti europei ed americani nel campo
della fisica teorica e sperimentale e si concluse con la prima esplosione nucleare avvenuta nel poligono di Los
Alamos. Il progetto fu coordinato da R. Oppenheimer che, con notevoli doti organizzative, seppe coordinare
in maniera ottimale le attività del progetto, gestendo in maniera particolarmente efficace gli aspetti relativi
all’organizzazione delle risorse umane. In questa occasione la figura del Project Manager fu determinante,
non solo come responsabile e coordinatore dei lavori, ma anche come gestore dei conflitti all’interno del
gruppo (8).
Negli anni ’50, l’avvio dei grandi programmi di sviluppo e la contemporanea diffusione del Digital Computer
prepararono il campo all’evoluzione della metodologia del Project Management, così come oggi concepito.
Gli anni del dopoguerra furono quindi caratterizzati dall’introduzione di una serie di tecniche e metodologie
che contribuirono a migliorare la gestione dei progetti.
L’effettivo controllo dei tempi del progetto si rese possibile grazie all’introduzione, nel 1957, del CPM (Critical
Path Method), sviluppato da M-Walker per la Du Pont, importante multinazionale operante nel settore
chimico, in collaborazione con il Rand Institute (8). La tecnica del CPM prevedeva la rappresentazione delle
diverse attività del processo, evidenziandone le interdipendenze e i ritardi ammissibili (float). Il CPM
permette di determinare quali siano le attività "critiche" e quelle che permettono un possibile slittamento,
ovvero quelle che possono essere ritardate senza rendere il progetto più lungo. Negli anni dal ’58 al ’60
l’applicazione sperimentale di questa metodologia ebbe come risultato la notevole riduzione dei tempi di
7
grandi progetti di impianti di generazione elettrica: del 42% e poi del 32% rispetto alla media
precedentemente calcolata (6).
Il metodo CPM, nella sua iniziale strutturazione, però, comportava degli importanti limiti: da un lato la
rigidezza delle relazioni temporali delle attività, esclusivamente di tipo fine-inizio, imponeva che le attività
dipendenti non potessero iniziare se non dopo il completamento delle precedenti, dall’altro le durate delle
attività del processo erano intese come invariabili, senza margine di incertezza. L’anno successivo, nel 1958,
vennero sviluppate due tecniche che, implementando il CPM, ne superavano i limiti principali. È interessante
notare che i pionieri del CPM e delle altre due tecniche, MPM e PERT, non conobbero l’esistenza dei reciproci
lavori fino al 1959, anno in cui iniziò a diffondersi una letteratura sull’argomento.
La tecnica del MPM (Metra Potential Method), sviluppata nel 1958 dal ricercatore francese Bernard Roy per
la costruzione della prima centrale nucleare francese, consente di trattare con maggiore flessibilità
l’interdipendenza delle operazioni, attraverso l’introduzione di altre tre tipologie di legami tra le attività.
La tecnica del PERT (Program Evaluation and Review Technique), sviluppata nel 1958 dalla Booz, Allen &
Hemilton per l’Ufficio Progetti Speciali della Marina degli Stati Uniti con l’obiettivo di ridurre i tempi ed i costi
per la progettazione e la costruzione dei sottomarini nucleari armati con i missili Polaris, tiene conto
dell’incertezza della durata delle operazioni. Tale incertezza, trattata con il metodo probabilistico di
Montecarlo, è in grado di indicare in anticipo il grado di criticità che le varie operazioni possono assumere
(9). L’applicazione della tecnica del PERT permise la riduzione dei tempi di esecuzione del progetto Polaris di
oltre il 40%: il lancio del missile fu possibile dopo appena tre anni dall’inizio dei lavori, mentre in base alle
previsioni, calcolate sulla base di precedenti esperienze, sarebbero stati necessari almeno cinque anni (6).
Alla fine degli anni ’50 e agli inizi degli anni ’60 i settori aerospaziali e della difesa utilizzavano il Project
Management in quasi tutti i progetti, spingendo i loro fornitori a fare lo stesso. Ad eccezione delle società
aerospaziali, della difesa e delle costruzioni, la maggior parte delle società degli anni ’60 conservava un modo
informale di gestione dei progetti, riducendo l’autorità del Project Manager.
2.1.4 Il moderno Project Management
Tra la metà e la fine degli anni ’60 un sempre maggior numero di dirigenti cominciò a cercare nuove tecniche
di Project Management e strutture organizzative che potessero essere adattate rapidamente ad un ambiente
in mutamento. Il Project Management stava crescendo, ma ad una velocità relativamente lenta. La lenta
velocità di crescita e l’accettazione del Project Management erano correlate al fatto che le limitazioni del
Project Management erano evidenti, anche se i vantaggi non erano completamente riconoscibili (7). Tra i
8
principali problemi riscontrati, in quegli anni, nell’adozione del nuovo sistema di Project Management si
rilevano: la difficoltà da parte dell’organizzazione di realizzare un forte cambiamento culturale interno; la
poco accettata ridistribuzione dell’autorità tra più livelli di management; la perdita di parte della
programmazione a lungo termine se concentrati sui requisiti dei progetti temporanei; la mancata
specializzazione dei professionisti, spesso spostati da un progetto all’altro (10).
Tra gli anni ’60 e ’70, negli Stati uniti si cominciava a diffondere la concezione, valida ancora oggi, secondo la
quale il Project Management è un approccio organizzativo globale, un valido strumento per la gestione
dell’intero processo produttivo in generale e, nel caso particolare, di quello edilizio (6). L’interesse che in
quegli anni si manifestava nei confronti del Project Management portò alla fondazione, nel 1969,
dell’organizzazione professionale chiamata Project Management Institute (PMI), il cui obiettivo è ancora oggi
quello di diffondere attraverso conferenze, seminari, pubblicazioni e periodici, le esperienze di gestione di
progetti in diversi settori e di organizzare corsi di formazione rivolti a professionisti.
Durante gli anni ’70 e ’80 un numero sempre crescente di società partiva dal Project Management informale
e provvedeva alla ristrutturazione per rendere ufficiale il processo di Project Management, principalmente
perché la dimensione e la complessità delle attività erano cresciute a tal punto da diventare ingestibili con le
tradizionali modalità di gestione (7). Negli stessi anni si assistette da un lato allo sviluppo di nuove
metodologie integrate di pianificazione e controllo dei progetti in termini di tempo e costo (Cost Schedule
Control System) e qualità (Quality Assurance), dall'altro ad un approfondimento delle diverse opzioni
organizzative per la gestione dei progetti (strutture a matrice, a task force ecc.).
Negli anni ’90 le società avevano cominciato a comprendere che l’implementazione del Project Management
doveva considerarsi una necessità e non una possibile scelta. Si pose una forte attenzione sia sul re-
engineering dei processi aziendali, che permise di migliorare la competitività e di sviluppare delle applicazioni
telematiche nella trasmissione ed elaborazione delle informazioni, sia sull'analisi e la gestione dei rischi di
progetto in quanto modalità per ottenere un più efficace controllo dei tradizionali parametri di performance
dei progetti in termini di tempi, costi e caratteristiche tecniche del prodotto finale.
Nell'arco dell'ultimo decennio, sono stati condotti vari tentativi per formalizzare e standardizzare gli aspetti
professionali del Project Management in termini di competenze, capacità e attitudini necessarie per operare
nell'ambito dei progetti, in modo da arrivare alla formulazione dei criteri per la certificazione professionale
degli specialisti di Project Management. Oltre alle tecniche di programmazione e controllo dei tempi e dei
costi, sono state elaborate tecniche più sofisticate, che permettono la gestione di altri aspetti del progetto e
che sfruttano integralmente le potenzialità dei sistemi informatici.
9
L’Earned Value Method è un noto strumento utilizzato nel Project Management per il controllo del progetto,
applicabile a qualsiasi tipologia di progetto grazie alla sua ampia flessibilità. È utilizzato per determinare lo
stato del progetto, in termini di costi e durate, nonché l’efficienza esecutiva rispetto a quanto preventivato.
Se applicato correttamente, questo metodo consente di identificate qualsiasi deviazione del progetto
rispetto a quanto preventivato, dando la possibilità di assumere per tempo azioni correttive per quelle più
critiche per il progetto (11).
La WBS (Work Breakdown Structure), permette la schematizzazione in blocchi sintetici delle attività del
progetto. Integrata alla CBS (Cost Breakdown Structure) e alla OBS (Organization Breakdown Structure)
permette di identificare velocemente i costi relativi alle singole attività e di associare ai livelli nei quali il
progetto è suddiviso i corrispondenti compiti del personale.
Il Graphical Evaluation and Review Technique (GERT) permette di stimare sia l’incertezza della durata delle
attività sia quella del cammino critico e dei relativi costi di progetto.
2.1.5 Le sfide del XXI secolo
Le sfide del XXI secolo riguardanti il Project Management sono legate all’interdisciplinarità del progetto e alle
relative necessità di integrazione. Uno degli aspetti che è sempre più importante tenere in considerazione
riguarda la gestione dell’informazione e dei dati; i nuovi strumenti informatici e le nuove tecnologie
permettono oggi di raccogliere, archiviare e trasmettere una quantità di informazioni prima impensabile ed
è ormai fondamentale trovare tecniche e strumenti capaci di gestire questo grande flusso di dati. Di seguito
sono riportati alcuni degli argomenti che rappresentano una sfida per il Project Management nei prossimi
anni (4):
• gestione dei dati: il volume di dati che interessano tutte le fasi di gestione del processo è molto
ampio ed è fondamentale strutturare un adeguato sistema di basi di dati, condivise e gestite in
maniera integrata ancorché a diversi livelli;
• ciclo di vita: estensione delle tecniche di gestione del progetto oltre le fasi di costruzione dell’edificio,
ovvero loro adozione nelle fasi di manutenzione e dismissione;
• certificazione: maggiore integrazione tra i modelli certificazioni proposti dalle associazioni
internazionali;
• controllo di progetto: sostituzione delle tecniche di controllo tradizionali, che considerano i costi
standard, con tecniche, quali l’Earned Value Method, che considera i costi effettivi, in tempo reale;
10
• gestione del contratto: integrazione fra gestione del progetto e gestione del contratto, applicazione
di metodo quantitativi alla gestione contrattuale e alla gestione del contenzioso;
• ambiente e sicurezza: miglioramento dell’integrazione con l’ingegneria ambientale, ingegneria della
sicurezza e altre discipline correlate;
• organizzazione: applicazione di metodi quantitativi all’organizzazione di progetto, migliore
definizione dei rapporti tra i ruoli, gestione delle organizzazioni a rete, motivazione, pianificazione e
programmazione del personale.
11
2.2 Caratteristiche dell’industria delle costruzioni
In Italia, l’industria delle costruzioni rappresenta una delle filiere economiche più importanti, sia per il
contributo al PIL sia per il numero di occupati. Nonostante abbia risentito molto più di altre settore ai
problemi successivi alla crisi finanziaria, il settore delle costruzioni continua a rivestire una grande importanza
nel panorama economico del Paese.
L’industria delle costruzioni è organizzata in modo particolarmente complesso e risulta essere fortemente
frammentata, con una predominanza di piccole e medie imprese (12). Le piccole e medie imprese (SME),
composte generalmente da un organico inferiore alle 10 persone, sono spesso considerate la spina dorsale
dell’economica Italiana e dell’Unione Europea; si stima infatti che in Europa siano presenti 4,3 milioni di
imprese legate all’industria delle costruzioni e che il 99,3% di esse sia composto da piccole e medie imprese.
Nonostante svolgano un ruolo fondamentale per l’economia nazionale, le piccole e medie imprese sono
meno competitive in confronto alle imprese di maggiori dimensioni, non riuscendo a cogliere molte
opportunità di mercato a causa di una mancanza di competenze tecniche e di fondi di investimento e di una
limitata capacità organizzativa.
Le piccole e medie imprese in Europa incontrano quattro principali barriere allo sviluppo: problemi di accesso
alle risorse finanziarie, scarsità di personale qualificato, mancanza della domanda del mercato, alti costi delle
risorse umane. Oggi le imprese di costruzione in generale, e le piccole e medie imprese in particolare, stanno
sopravvivendo in un ambiente drasticamente competitivo e si trovano ad affrontare importanti sfide;
nonostante le loro dimensioni, le piccole e medie imprese hanno dimostrato alle più grandi organizzazioni la
loro capacità di sopravvivere e di adattarsi in un ambiente volatile e in continuo cambiamento come quello
delle costruzioni.
Nel presente capitolo si identificheranno gli aspetti principali del mercato delle costruzioni, facendo un’analisi
completa sui comparti in esso compresi, sull’influenza economica e sulle sue peculiarità: saranno descritte le
categorie di settore e le loro singolarità; sarà presentata un’analisi sull’andamento del mercato negli ultimi
vent’anni, in termini di produttività, investimenti ed occupazione; infine, si effettuerà un confronto tra il
sistema produttivo del mondo delle costruzioni e quello dell’industria manifatturiera, ponendo in evidenza
le peculiarità che distinguono un edificio o una qualsiasi costruzione dalla manifattura.
2.2.1 Le categorie dei settori nell’industria delle costruzioni
La maggior parte delle figure coinvolte nel mondo delle costruzioni concentrano investimenti e competenze
tecniche in specifici settori dell’industria delle costruzioni. Le differenze tra i settori riguardano
12
principalmente l’origine del finanziamento per la realizzazione dell’opera, la tipologia di committente, i
metodi costruttivi adottati e il modo in cui interagiscono progettisti, impresa costruttrice e committenti.
I settori dell’industria delle costruzioni sono solitamente scomposti nelle seguenti categorie: edifici
residenziali, commerciali, industriali, infrastrutture e rete stradale (13).
Il settore degli edifici residenziali si concentra sulla realizzazione di edifici abitati dall’uomo, quali abitazioni
individuali, piccoli condomini, sistemi residenziali più complessi. Gli edifici appartenenti a questa categoria
hanno in comune gli aspetti salienti relativi alla loro costruzione: sono progettati da studi di progettazione
composti soprattutto da architetti, vedono generalmente l’impiego di basse tecnologie, sono commissionate
e finanziate da proprietari che, nella maggior parte dei casi, usufruiscono direttamente del bene.
Il settore degli edifici commerciali comprende sia edifici privati, tra cui edifici per uffici, negozi, mercati, centri
commerciali, sia edifici istituzionali e rivolti alla comunità, quali ospedali, teatri, istituti scolastici. Gli edifici
appartenenti a questa categoria sono solitamente progettati da studi integrati di architetti e ingegneri,
essendo le tecnologie impiegate e la complessità progettuale più elevata rispetto agli edifici residenziali.
Gli edifici riconducibili al settore industriale, quali, ad esempio, raffinerie petrolifere, impianti per processi
chimici, acciaierie, sono particolarmente complessi e, per questo, richiedono l’intervento di progettisti e
imprese costruttrici altamente specializzate per la realizzazione di quella specifica tipologia di impianto
industriale. Negli Stati Uniti e in molti Stati europei, la realizzazione di impianti industriali è finanziata da
investitori privati; in altre parti del mondo, invece, i finanziamenti possono provenire da enti pubblici.
I progetti appartenenti al settore delle infrastrutture e della rete stradale, finanziati da enti pubblici e volti
alla realizzazione di ponti, tunnel, strutture marittime, oleodotti, gasdotti e metanodotti, sono invece
progettati da ingegneri civili e realizzati da imprese costruttrici specializzate in progetti complessi.
Con riferimento ai dati forniti dal United States Census Bureau, in Tabella 1, Tabella 2, Tabella 3 è presentata
una panoramica riguardante le percentuali di edifici pubblici e privati presenti negli Stati Uniti, con un
dettaglio sulla percentuale di edifici, divisi per categoria di settore.
13
Tabella 1- Percentuale delle costruzioni negli Stati Uniti, scomposte per categoria di settore: residenziale, commerciale, industriale e
infrastrutture. Dati forniti dal United States Census Bureau e aggiornati a Dicembre 2016
Tabella 2- Percentuale di costruzioni pubbliche e private negli Stati Uniti. Dati forniti dal United States Census Bureau e aggiornati a
Dicembre 2016
40%
29%
6%
25%
Spese per costruzioni per categoria
Residenziale Commerciale Industriale Infrastrutture
76%
24%
Costruzioni pubbliche e private
PRIVATO PUBBLICO
Spese per edifici per categoria di settore (milioni di dollari)
RESIDENZIALE 473.279
COMMERCIALE 348.845
Strutture ricettive 27.316
Uffici 75.796
Commerciali 78.715
Sanità 41.899
Educazione 90.638
Religione 3.421
Sicurezza Pubblica 8.269
Divertimento e svago 22.791
INDUSTRIALE 68.745
Industria manifatturiera 68.745
INFRASTRUTTURE 290.653
Trasporti 42.115
Comunicazione 21.666
Energia 93.545
Sistema stradale 94.530
Smaltimento rifiuti e acque nere 19.321
Fornitura d'acqua 11.640
Salvaguardia e sviluppo 7.836
Spese per edifici pubblici e privati
(milioni di dollari)
TOTALE 1,181,523
PRIVATO 896,992
Residenziale 466,938
Non residenziale 430,053
PUBBLICO 284,531
Stato e Locale 260,356
Federale 24,175
14
Tabella 3- Investimenti nel settore delle costruzioni in Italia, scomposti per comparti: residenziale nuovo, residenziale recupero, non
residenziale privato, non residenziale pubblico. Dati forniti da ANCE e aggiornati a Gennaio 2017
2.2.2 Il mercato delle costruzioni in Italia
Il settore delle costruzioni contribuisce da sempre in maniera determinante all’andamento, seppur modesto,
dell’economia nazionale. Questo paragrafo ha come obiettivo quello di individuare il valore dell’industria
delle costruzioni e l’influenza che questa ha avuto negli anni sull’economia italiana.
Nella prima parte del paragrafo, si analizzerà il mercato delle costruzioni fino agli anni immediatamente
successivi alla crisi economica, studiandone l’andamento a partire da: valore aggiunto, produttività del lavoro
e unità di lavoro. Si è fatto riferimento ai report redatti da ISFOL (Istituto per lo Sviluppo della Formazione
professionale dei Lavoratori), ente nazionale di ricerca sottoposto alla vigilanza del Ministero del Lavoro e
delle politiche sociali che, tra i vari compiti, svolge e promuove attività di studio, ricerca, sperimentazione,
documentazione, informazione e valutazione.
Nella seconda parte del paragrafo, si concentrerà l’attenzione sulla ripresa, seppur lenta, del mercato delle
costruzioni negli ultimi anni. A tal fine sono state utilizzate le elaborazioni dei dati Istat dell’ANCE
(Associazione Nazionale Costruttori Edili), costituita nel 1946, tra i cui obiettivi emerge quello di promuovere
e realizzare iniziative mirate ad ampliare il mercato delle costruzioni.
16%
37%27%
20%
Spese nelle costruzioni per comparto
Residenziale nuovo Residenziale recupero
Commerciale - Industriale Opere pubbliche
Investimenti costruzioni per comparto (milioni di euro)
RESIDENZIALE 66.767
Nuove 20.302
Manutenzione straordinaria 46.465
NON RESIDENZIALE 58.887
Private 34.291
Pubbliche 24.314
15
Da un lato si analizzerà il totale mercato delle costruzioni, valutandone investimenti, produttività e
occupazione, dall’altro si procederà con un’analisi più specifica per i diversi comparti. L’intera produzione
edilizia viene suddivisa in tre comparti di attività:
• edilizia residenziale;
• edilizia non residenziale;
• opere pubbliche.
È inoltre fatta un’ulteriore segmentazione tra interventi di nuova costruzione e interventi di recupero e
manutenzione dell’esistente, tenendo conto dell’importante trasformazione che ha interessato il settore
delle costruzioni a partire dagli anni ’90 e del fatto che il divario tra nuove realizzazioni e interventi di
recupero, manutenzione e riqualificazione del patrimonio esistente sia sempre più sottile (14).
2.2.2.1 Il mercato delle costruzioni dagli anni ’90 al 2011
Per poter rappresentare la crescita del settore dell’industria delle costruzioni dagli anni ’90 fino a quelli
immediatamente successivi si è valutata, in primo luogo, l’attività dell’industria delle costruzioni attraverso
il valore aggiunto, definito come la differenza tra il valore della produzione di un’impresa e il valore dei beni
intermedi utilizzati. La somma dei valori aggiunti per le imprese operanti in un determinato comparto
produttivo rappresenta il valore aggiunto al settore (15). In Figura 1 è rappresentata la crescita del settore
delle costruzioni, analizzando il valore aggiunto.
Figura 1 - Crescita del settore delle costruzioni funzione del valore aggiunto (15)
16
Come rappresentato in Figura 1, nella prima parte degli anni novanta l’andamento dell’attività nel settore
delle costruzioni è stato quasi stagnante, con un’intensa flessione nel biennio 1993-94, quando l’aggravarsi
delle condizioni finanziarie italiane disincentivò gli investimenti nel settore. Dopo qualche anno di stabilità,
nel periodo tra il 2001 ed il 2005 l’attività nel settore delle costruzioni è aumentata ad un tasso medio annuo
del 3%. La crescita è proseguita fino al 2007 per poi interrompersi con il manifestarsi dei primi segnali della
crisi finanziaria e con lo scoppio della bolla immobiliare. Dal 2008 al 2012 si è verificata una forte caduta degli
investimenti nel mercato delle costruzioni, con conseguente diminuzione dell’attività edilizia del 16.4% (15).
Un’altra variabile da considerare per poter cogliere le tendenze del mercato è la produttività del lavoro, che
corrisponde al valore aggiunto su unità di lavoro. Incrementi di produttività permettono di raggiungere
determinati livelli produttivi con minor fabbisogno di lavoro; in altre parole, la produttività aumenta se
l’occupazione cresce a ritmi inferiori a quella del prodotto (15). In Figura 2 è rappresentato l’andamento del
mercato delle costruzioni in funzione della produttività del lavoro.
Figura 2 - Andamento dell’industria delle costruzioni in funzione della produttività del lavoro (15)
La Figura 2 mostra che intorno gli anni novanta, durante i quali l’attività nel settore delle costruzioni è stata
quasi stagnante, la produttività era debole, con un tasso di variazione annuo nullo tra il 1996 ed il 2000. La
produttività si è ridotta, tra il 2001 ed il 2005, ad un tasso medio annuo dello 0.3%, in primo luogo a causa
dell’utilizzo poco efficiente delle risorse del settore, in secondo luogo per la regolarizzazione degli immigrati
impiegati nelle costruzioni, che ha portato a statistiche che consideravano una manodopera già presente in
precedenza. La crisi economica ha comportato un calo ulteriore della produttività del settore, che nel periodo
2006-2011 si è ridotta mediamente del 2.1% all’anno, con una contrazione soprattutto nel 2009 (15).
17
In ultimo, in Figura 3 è messo a confronto l’andamento dell’occupazione con quello degli equivalenti a tempo
pieno, ovvero le unità di lavoro. L’unità di lavoro rappresenta la quantità di lavoro prestata da un impiegato
a tempo pieno ed è utilizzata come unità di misura del volume di lavoro impiegato per la produzione di beni
e servizi (15).
Figura 3 - Andamento dell'occupazione e delle unità di lavoro (15)
L’intenso sviluppo del settore delle costruzioni si è tradotto in crescita occupazionale; nel periodo tra il 2001
ed il 2005 le unità di lavoro sono aumentate ad un tasso medio annuo pari al 3.3%. La crescita si è interrotta
nella seconda metà degli anni duemila; il tasso annuo di variazione è stato pari, in media, a -0.4%. La domanda
del fattore lavoro si è ridotta solo a partire dal 2009, con una contrazione complessiva al 2011 del 6%.
2.2.2.2 Il mercato delle costruzioni dal 2012 ad oggi
La ripresa economica italiana continua ad essere fragile e di intensità contenuta. Dopo una flessione tra il
2012 e il 2014, a partire dal 2015 l’economia italiana continua lentamente a crescere; secondo l’Istat, il 2017
sarà caratterizzato da una crescita del PIL (prodotto interno lordo) dello 0.9% rispetto all’anno precedente.
Nel periodo tra il 2008 e il 2015 il settore delle costruzioni ha perso il 34.8% degli investimenti. La Tabella 4
mostra che, in quegli anni, per la nuova edilizia abitativa la flessione raggiunse il 61.1%, l’edilizia non
residenziale privata segnò una riduzione del 35.0% e le opere pubbliche registrarono una caduta del 48.7%.
Solo il comparto della riqualificazione degli immobili residenziali mostrò una tenuta dei livelli produttivi, pari
a +19.4% (16).
18
Con riferimento al mercato delle costruzioni attuale, il quadro si presenta ancora incerto e non sembrano
sussistere le condizioni per una reale ripartenza. La stima formulata dall’Ance per il 2016, riproposta in
Tabella 4, è di un lieve aumento degli investimenti nell’industria delle costruzioni, pari allo 0.3%, a conferma
di una leggera crescita dei livelli produttivi (17).
INVESTIMENTI IN COSTRUZIONI IN ITALIA
2016 2008 2013 2014 2015 2016 2017
Milioni di Euro Variazione %
COSTRUZIONI 128510 -34,8 -7,5 -5,2 -1 0,3 0,8
Abitazioni 68042 -27,6 -3,3 -4,1 -1,9 0,1 0,6
Nuove 21388 -61,1 -12,4 -14 -6,8 -3,4 -1,4
Manutenzione straordinaria 46654 19,4 2,9 1,5 0,5 1,7 1,4
Non residenziali 60468 -41,4 -11,7 -6,3 0,1 0,6 1
Private 35954 -35 -13,4 -7,1 -1,2 0,8 0,3
Pubbliche 24514 -48,7 -9,3 -5,1 1,9 0,4 1,9
Tabella 4- Investimenti nell’industria delle costruzioni in Italia. Elaborazione di dati stimati da ANCE.
Può essere interessante valutare in maniera più approfondita gli investimenti per comparti dell’industria
delle costruzioni. La Figura 4 mostra l’andamento degli investimenti per edifici per abitazioni, costruzioni non
residenziali private e opere pubbliche.
Figura 4 - Andamento degli investimenti nei diversi comparti dell'industria delle costruzioni: abitazioni (in alto), costruzioni non
residenziali private (a sinistra) e opere pubbliche (a destra) (17)
19
La Figura 4 mostra l’andamento negativo degli investimenti negli ultimi dieci anni per la nuova edilizia
residenziale; l’Ance stima un andamento negativo, pari al -3.4% rispetto all’anno precedente. L’andamento
sembra trovare riscontro anche nei dati Istat sui permessi di costruire, in riduzione ormai da quasi un
decennio. L’Ance stima che nel 2015 le abitazioni concesse siano scese a 47500, con una flessione
complessiva, rispetto al picco del 2005 (305706 unità), pari all’84.5%; il livello delle abitazioni concesse nel
2015 risulta il più basso dal 1935, escludendo gli anni del secondo conflitto mondiale (17).
Gli investimenti in riqualificazione del patrimonio abitativo confermano la dinamica positiva degli anni
precedenti, giungendo a rappresentare il 37% del valore degli investimenti in costruzioni; rispetto al 2015 si
stima una crescita dell’1.7% per gli investimenti in tale comparto anche grazie agli incentivi fiscali per le
ristrutturazioni edilizie e per l’efficientamento energetico previsti dalla Legge di Stabilità per il 2016 e
confermati, nella recente Legge di Bilancio 2017, per tutto l’anno corrente (17).
La Figura 4 mostra che, rispetto all’andamento negativo degli ultimi anni, nel 2016 gli investimenti privati in
costruzioni non residenziali segnano un aumento dello 0.8% (17). L’andamento positivo tiene conto del
migliorato contesto economico del Paese, del dato positivo dei permessi di costruire per l’edilizia non
residenziale e del buon andamento dei mutui erogati per investimenti non residenziali nel biennio 2014-2015
dopo i forti cali degli anni precedenti; tra il 2007 e il 2013, infatti, i nuovi mutui per investimenti nel settore
non residenziale erano diminuiti del 73.5%, passando da 21 miliardi ad appena 5.6 miliardi di euro (16).
La situazione degli investimenti in costruzioni non residenziali pubbliche è rappresentata in Figura 4; si stima
nel 2016 un aumento dello 0.4% in quantità rispetto all’anno precedente (17). La nota di aggiornamento del
DEF (Documento di Economia e Finanza), deliberata il 27 Settembre 2016 e presentata dal Presidente del
Consiglio dei Ministri e dal Ministro dell’Economia e delle Finanze, stima per l’anno 2016 un aumento della
spesa della Pubblica Amministrazione per investimenti fissi lordi pari allo 0.9%, lasciando al 2017 l’incremento
più consistente del 3.6%. L’andamento dei bandi di gara per lavori pubblici evidenzia un ridimensionamento
nel 2016, con diminuzioni generalizzate, ad eccezione delle fasce di importo 25-50 milioni di euro che
presentano un aumento del 18.4% e delle gare fino a 150mila euro, in aumento del 23%; per le altre fasce di
importo si verifica una flessione con punte del -38.5% per la fascia 1-5 milioni di euro.
Con riferimento ai dati occupazionali, le costruzioni continuano ad essere oggi l’unico settore di attività
economica a segno negativo. Il bilancio complessivo dei posti di lavoro persi nelle costruzioni dall’inizio della
crisi continua ad aumentare: dal quarto trimestre 2008 al terzo trimestre 2016 le costruzioni hanno perso
quasi 600.000 posti di lavoro, con una flessione in termini percentuali del 30%.
20
Anche in termini di imprese il bilancio è molto negativo: tra il tra il 2008 ed il 2014, sono uscite dal settore
delle costruzioni oltre 100.000 imprese, con una flessione del 16%. In particolare: le imprese con un numero
di addetti compresi tra 2 e 9 si sono ridotte di oltre un quarto (-26.9%); le medie imprese, con al massimo 49
addetti, sono diminuite del 40%; le imprese più grandi con più di 50 impiegati sono scomparse dal mercato
per circa un terzo (-31%). In Figura 5 è riportata la panoramica dei dati occupazionali e relativi alle aziende.
Figura 5 - Andamento del numero di Imprese e addetti nel settore delle costruzioni (17)
Secondo l’Osservatorio Congiunturale sull’Industria delle Costruzioni, pubblicato da ANCE a Gennaio 2017, il
settore delle costruzioni potrebbe essere protagonista di una ripresa durante il 2017, con un aumento dello
0.8% degli investimenti nel mercato. Si prevede una crescita del 1.9% rispetto al 2016 per gli investimenti in
opere pubbliche, un aumento del 1.4% per gli investimenti di manutenzione straordinaria sulle abitazioni
esistenti ed un incremento dello 0.3% per gli investimenti in costruzioni non residenziali private. Nonostante
questi scenari positivi, si prevedono segni negativi per gli investimenti in nuove abitazioni, sebbene con indici
più contenuti rispetto agli anni precedenti (17).
L’analisi tiene conto dell’impatto sui livelli produttivi delle misure contenute nella Legge di Bilancio 2017 e
della proroga delle detrazioni IRPEF/IRES delle spese sostenute per interventi di messa in sicurezza statica di
edifici a destinazione d’uso produttiva situati in zone ad alta pericolosità sismica. Per raggiungere gli obiettivi
di ripresa del settore appare necessaria la corretta attuazione delle misure previste per garantire l’attivazione
degli investimenti ed evitare rallentamenti (17).
21
2.2.3 Processo di produzione nell’industria delle costruzioni e delle manifatture
Per comprendere come il Project Management possa essere un efficace strumento per la gestione di processi
è fondamentale conoscere le peculiarità del processo produttivo nell’industria delle costruzioni e ciò che lo
contraddistingue da quello del settore manifatturiero. Nonostante l’industria delle costruzioni e quella delle
manifatture siano accomunate da numerosi fattori, esistono infatti delle importanti differenze che
contraddistinguono e diversificano i due processi produttivi.
Nella Figura 6 è riportato uno schema delle principali disuguaglianze tra il processo di produzione edilizio e
quello manifatturiero.
Figura 6 - Confronto tra processo di produzione nell'industria delle costruzioni e delle manifatture
La progettazione del prodotto del processo costruttivo è quasi sempre esterna, essendo spesso affidata a
team di progettazione che non corrispondono all’impresa di costruzione ma che con essa interagiscono. Al
contrario, le industrie manifatturiere hanno quasi sempre al loro interno un ufficio tecnico, responsabile della
progettazione e customizzazione dei prodotti, e un reparto di ricerca e sviluppo per la progettazione di nuovi
prodotti e la ricerca di nuove soluzioni.
Un’ulteriore differenza tra le due tipologie di industria si individua nella figura del committente. Nel mondo
delle costruzioni, il committente può coincidere con l’impresa costruttrice ma è più spesso una terza parte,
esterna sia al team di progettazione che all’impresa costruttrice. Nell’industria manifatturiera, invece, il
committente è sempre interno, essendo la stessa società o azienda a commissionare la produzione del bene.
22
La produzione del bene immobile è una produzione su commessa, strettamente vincolata alle richieste e ai
desideri del committente. Il prodotto finale sarà quindi prototipico, personalizzato in base alle specifiche
esigenze e necessità dell’utente, e diverso da tutti gli altri progetti realizzati. Viceversa, nel mondo delle
manifatture la produzione è di tipo seriale, caratterizzata dalla realizzazione attraverso catene di montaggio
di grandi quantità di prodotti standardizzati.
L’unicità del processo e la prototipicità del prodotto delle costruzioni fanno sì che nei processi costruttivi non
vengano sfruttate a pieno le lezioni apprese dai processi precedentemente conclusi. Nel mondo delle
costruzioni ogni processo produttivo è unico e non esattamente ripetibile, poiché caratterizzato da vincoli di
tempi, costi e qualità ogni volta diversi e legati alla produzione di un bene specifico e distinto dagli altri.
Nell’industria manifatturiera, al contrario, i processi conclusi e le lezioni da essi apprese sono un importante
punto di partenza per quelli successivi e consentono un miglioramento della qualità del prodotto finale.
Uno dei fattori che differenzia l’industria manifatturiera da quella delle costruzioni è la qualità di tecnologia
impiegata nel processo produttivo. Nonostante il mercato offra soluzioni tecnologiche sempre più avanzate,
che consentirebbero, se impiegate, la realizzazione di edifici molto più performanti, nel panorama delle
costruzioni sono prevalentemente impiegate tecnologie tradizionali, povere e non molto sofisticate. Al
contrario, per rispondere alle evoluzioni del mercato e alle trasformazioni della domanda, le industrie
manifatturiere utilizzano sistemi tecnologici sempre più innovativi, che portano alla realizzazione di prodotti
di alta qualità e fortemente competitivi.
La diversa tipologia di tecnologie impiegate nel settore delle costruzioni e in quello manifatturiero comporta
la necessità di impiego di risorse umane con competenze differenti. Nell’industria delle costruzioni le risorse
umane coinvolte nel processo sono qualificate nel settore e, in alcuni casi, di tipo generico. Le competenze
delle maestranze si stanno riducendo molto rispetto al passato, soprattutto a causa dell’introduzione di
personale a bassa retribuzione che non presenta competenze sufficienti per svolgere opportunamente il
proprio lavoro (18). Nel mondo delle manifatture, invece, si fa ricorso a personale qualificato, con un alto
livello di istruzione ed opportunamente preparato per l’impiego di tecnologie all’avanguardia.
Il mondo delle costruzioni non richiede particolari requisiti d’accesso o grandi possibilità di investimento;
chiunque abbia giusta motivazione, competenze tecniche e sufficiente denaro iniziale può intraprendere un
percorso lavorativo all’interno del mondo dell’edilizia (13). Al contrario, l’industria manifatturiera è
caratterizzata da rigorose barriere d’ingresso, che spesso ostacolando l’accesso ai mercati e favoriscono
l’insorgere di monopoli, con accentramento nelle mani di un solo venditore dell'offerta di un dato bene o
prodotto.
23
Un’ulteriore differenza tra il settore delle costruzioni e quello manifatturiero riguarda il fattore di rischio.
Quest’ultimo è molto più alto nel settore delle costruzioni che in qualsiasi altro settore industriale perché i
fattori esterni, quali ad esempio l’andamento del mercato immobiliare, gli investimenti governativi e
l’andamento economico generale, influenzano notevolmente la domanda. Un’altra ragione risiede nel fatto
che le sedi produttive dei beni immobili sono all’aperto e, proprio per questo, i fattori climatici e ambientali
influenzano fortemente il livello di produttività, creando notevoli rischi a cose e persone e portando, in alcuni
casi, alla chiusura dei cantieri (13).
Un’ultima singolarità della produzione edilizia, che la differenzia da quella manifatturiera, risiede nella forte
suddivisione dei compiti e delle fasi del processo a fronte di una scarsissima interazione tra i soggetti
interessati. Nello stesso processo costruttivo, infatti, intervengono in maniera distinta il committente, il
progettista, il costruttore e l’utente, con una difficile attività di coordinamento tra le parti. Questo modus
operandi limita la concretezza della fase di ideazione, portando solo raramente all’ingegnerizzazione del
prodotto, e limita il rinnovamento della produzione, non lasciando spazio all’innovazione. Al contrario, nella
produzione manifatturiera, il controllo del processo è in capo all’azienda produttrice che, in quanto soggetto
centrale della filiera, coordina sia la produzione che la progettazione del prodotto (14).
La principale conseguenza derivante dalle diverse caratteristiche della produzione nell’industria delle
manifatture e delle costruzioni risiede nei differenti tipologie di bene che da queste derivano: il bene
prodotto nel mercato delle costruzioni è un bene immobile, prototipico e durevole; il bene prodotto
dall’industria manifatturiera è un bene di consumo, in serie e poco durevole.
Nella Figura 7 è riportato uno schema delle principali differenze tra i beni prodotti nell’industria delle
costruzioni e manifatturiera.
Figura 7 - Confronto tra i beni prodotti nell'industria del mondo delle costruzioni e delle manifatture
24
Gli edifici e le costruzioni di altra natura sono bene immobili per natura, poiché non possono essere spostati
normalmente da un luogo all’altro senza che ne venga alterata la struttura e la destinazione. Nel mondo delle
costruzioni, la sede produttiva, ovvero il cantiere edile, è localizzato nel luogo esatto in cui è previsto che
sorga il bene immobile; la temporalità della sede produttiva è vincolata al ciclo di produzione del bene e la
conformazione del cantiere è funzione di un gran numero di variabili. Ogni cantiere, infatti, dipende dalle
mutevoli condizioni dei siti, dalla disponibilità di spazio, dai servizi che la sede della costruzione ha a
disposizione e anche da spazi di manovra, accessi, condizioni del terreno, allacciamenti e disponibilità di spazi
per approvvigionamento e stoccaggio di materiali e semilavorati (14).
La condizione di produzione dell’industria delle costruzioni è opposta all’attuale sistema di produzione,
altamente globalizzato, caratteristico invece del settore manifatturiero. In questo caso il bene, definito “di
consumo” poiché impiegato direttamente per soddisfare un bisogno dell’utilizzatore, viene prodotto nel
luogo in cui risulta più conveniente fabbricarlo, in ragione del minor costo dei fattori di produzione. Ogni sede
produttiva manifatturiera, o capannone industriale, la cui temporalità dipende da strategie industriali e da
accordi con i Governi locali, è progettata per razionalizzare al massimo i propri spazi in funzione delle
lavorazioni che in esse devono essere svolte; la conformazione della sede produttiva è funzione della
produzione, per cui la dimensione degli stabilimenti produttivi viene ampliata o ridotta a seconda delle
richieste di produzione.
Un aspetto che distingue il bene dell’industria delle costruzioni dal prodotto manifatturiero è la diversa
durabilità. La vita utile di un immobile è molto lunga e varia a seconda della tipologia di costruzioni e della
sua destinazione d’uso: mediamente per un edificio residenziale si considera una vita utile pari a 100 anni,
mentre si considera che edifici commerciali e industriali restino “in servizio” per 70 e 50 anni rispettivamente.
Per gli edifici sono inevitabili interventi di post-produzione per manutenzione e sostituzione delle parti dalla
vita utile di molto inferiore a quella del bene complessivo; per queste parti è prevista una manutenzione a
guasto, che prevede un intervento di riparazione, sostituzione o revisione, solo a guasto avvenuto.
Al contrario, il prodotto manifatturiero e le sue componenti hanno una vita utile tra loro paragonabile, in
genere pari a 3-5 anni. La produzione manifatturiera punta sempre di più all’immissione sul mercato di beni
dalla vita utile molto breve, per i quali risulti più conveniente una sostituzione piuttosto che una riparazione
(14).
In funzione della tipologia di produzione i beni prodotti dall’industria delle costruzioni e manifatturiera
possono essere rispettivamente definiti prototipici e seriali. La produzione su commessa del mondo
dell’edilizia, vincolata alle esigenze della committenza, produce infatti bene sempre diversi tra loro; il
carattere di unicità dell’elemento finito, sempre diverso, porta a legare le economie interne, ovvero gli sconti
25
sulle forniture in funzione della quantità, non alla singola commessa ma alla capacità di acquisto complessivo
dell’impresa. Al contrario, la produzione seriale impiegata nel campo delle manifatture restituisce prodotti
standardizzati e sempre uguali; in questo caso è garantito un risparmio per i produttori del bene, potendo
questi fare pressione verso i rivenditori in ragione dei loro copiosi ordini di forniture (14).
Un’ultima differenza tra le costruzioni e le manifatture è da ricercarsi nel modo in cui i costi fissi vengono
allocati sui prodotti. I costi fissi, propri di un approccio economico, sono sostenuti dall’impresa
indipendentemente dalla quantità di prodotto realizzato e sono quindi sempre costanti rispetto alle quantità
prodotte; corrispondono, ad esempio, all’affitto per la sede dell’azienda e agli stipendi di operai e impiegati
(14). Per loro natura, i costi fissi assumono un’incidenza inversamente proporzionale in ragione del numero
di unità prodotte, diminuendo percentualmente all’aumentare della quantità prodotta. Nell’industria delle
costruzioni, quindi, i costi fissi sono tutti imputabile all’unico bene prodotto; nell’industria manifatturiera, al
contrario, l’entità dei costi fissi viene ripartita su tutti i prodotti realizzati, dimostrando il vantaggio della
produzione seriale e su larga scala in termine di riduzione di costi.
26
2.3 Principi di Project Management
Il Project Management è un sistema gestionale orientato ai risultati. Può essere definito come “gestione
complessa di un’impresa unica e di durata determinata, rivolta al raggiungimento di un obiettivo chiaro e
predefinito mediante un processo continuo di pianificazione e controllo di risorse differenziate e con vincoli
interdipendenti di costi-tempi-qualità” (19).
Il termine “progetto” è qui inteso nell’accezione anglosassone del termine, intendendo qualcosa di completo
da portare a termine. È importante non confondere la parola progetto con il significato italiano del termine,
in inglese tradotto come “design”. Con il termine di “progetto” si intende non solo l’attività di progettazione
dell’opera, ovvero il design, ma anche l’insieme di tutte le attività che conducono alla realizzazione
dell’opera: la concezione originaria, lo studio di fattibilità, la progettazione integrata, la costruzione, la messa
in opera e la successiva gestione e manutenzione (9).
2.3.1 Definizione di progetto
Un progetto può essere definito come “un’impresa complessa, unica e di durata determinata rivolta al
raggiungimento di un obiettivo chiaro e predefinito” (19). Nonostante l’attività di Project Management possa
riferirsi a progetti di varia natura, è possibile identificare alcune caratteristiche comuni a tutte le tipologie di
progetto, di seguito riassunte.
“I progetti sono degli sforzi complessi che hanno inizio e fine e non sono ripetitivi” (19). Un progetto è quindi
un’iniziativa originale e non la mera ripetizione di iniziative precedenti ed ha come finalità quella di produrre
risultati specifici. L’unicità del progetto deriva non solo dalle sue stesse caratteristiche tipologico-funzionali,
strutturali ed architettoniche, ma anche dalle modalità di assegnazione e dalla struttura di committenza;
queste variabili rendono necessariamente multiforme la gestione manageriale, nonostante restino validi i
principi organizzativi, gli strumenti operativi e la forma mentis che guida il processo (6).
“Un progetto è il processo di creazione di determinati risultati” (19). Un progetto può essere considerato
come l’intero processo volto, ad esempio, alla realizzazione di un singolo prodotto, di un nuovo stabilimento
industriale o di un nuovo sistema.
“Il progetto ha una vita finita” (19). La vita del progetto ha un inizio ed una fine ed è caratterizzata da una
serie di fasi, solo di rado nettamente separate le une dalle altre, più spesso complementari e contemporanee.
27
Come mostrato in Figura 8, ogni fase si conclude con output ben definiti che, a loro volta, forniscono gli input
per la fase successiva. Al termine di ogni fase progettuale corrispondono momenti di valutazione e decisione:
in alcuni casi si decide se autorizza il passaggio alla fase successiva, in altri si dispone la ripetizione di una fase
precedente.
Figura 8- Fasi del ciclo di vita di un progetto (19)
Il momento al termine del quale viene solitamente data l’approvazione e vengono stanziate risorse
finanziarie significative è quello corrispondente alla fase di definizione; se approvato al termine della fase di
definizione, il progetto ha ragionevoli garanzie di superare anche tutte le fasi rimanenti. In quasi tutti i settori,
però, la maggior parte delle idee che entrano nella fase di definizione progettuale non vengono però
effettivamente realizzate uscendone come progetti compiuti.
2.3.2 Il ruolo del Project Manager
I progetti, così come i programmi, ossia un insieme di progetti correlati tra loro al fine di raggiungere insieme
uno o più obiettivi strategici, ed i portafogli di progetto, ovvero l’insieme di progetti e programmi che
un’organizzazione gestisce in un periodo di tempo correlato al piano strategico aziendale, hanno una
notevole importanza in tutte le organizzazioni, sia nelle industrie private che nella pubblica amministrazione.
I progetti sono infatti gli elementi attraverso cui le imprese ottengono la maggior parte dei loro profitti,
mentre la capacità di realizzazione di progetti da parte della pubblica amministrazione comporta importanti
sviluppi e miglioramenti nella scuola, nella sanità, nei trasporti e in molti altri settori di interesse comunitario.
Vista l’importanza rivestita dai progetti in campo pubblico e privato e considerata la loro crescente
complessità, risulta sempre più importante l’assunzione di una figura professionale che sia responsabile del
successo dei progetti, nel rispetto dei tempi, costi e qualità previsti.
28
Il ruolo del Project Manager è quindi quello di gestire e controllare le risorse disponibili affinché una
determinata attività sia svolta entro i vincoli di progetto, cioè nel rispetto di tempi, costi e prestazioni
prestabilite. Nel caso di progetti su commissione, ai vincoli di progetto si aggiunge il vincolo di una buona
relazione con il cliente, fondamentale per consolidare e sviluppare la fiducia del proprio operato nel mercato
(7). In Figura 9 sono rappresentati tutti i vincoli di progetto appena discussi.
Figura 9- Vincoli di progetto: tempo, costo, qualità, relazione con il cliente (7)
In quanto direttore del progetto e responsabile del raggiungimento dei suoi stessi obiettivi, il Project
Manager dirige il progetto per tutto lo sviluppo del suo ciclo di vita, intervenendo nella definizione della
programmazione degli obiettivi, nella fase esecuzione e controllo e durante tutte le successive iterazioni fino
alla chiusura del progetto. Sarebbe quindi opportuno che il Project Management venisse nominato già nelle
primissime fasi del progetto, in modo che possa essere presente dall’inizio alla fine del suo sviluppo. In
edilizia, però, capita spesso che il Project Manager si trovi ad operare con parti del progetto architettonico
già eseguite o a progettazione già ultimata, nel momento in cui risulta necessario iniziare le attività di appalto
e assegnazione lavori (2).
Il Project Manager è il responsabile della gestione delle relazioni con gli stakeholders, quali clienti, fornitori,
azionisti, collaboratori, residenti di aree limitrofe, istituzioni statali relative all’amministrazione locale. Il suo
compito è quello di riuscire a mediare tra gli obiettivi dei singoli senza però perdere di vista l’obiettivo
primario ovvero la realizzazione dell’opera. Il Project Manager diventa arbitro, giusto ed ascoltato, dello
sviluppo del progetto, avendo come obiettivo non quello di tutelare un interesse specifico, ma quello di
ricercare un equilibrio tra le richieste di tutti gli attori, facendo il possibile per soddisfarle.
Il Project Manager, come un direttore d’orchestra o un allenatore di una squadra di calcio, ha il compito di
creare un gruppo di lavoro motivato ed affiatato, in cui tutti siano nella condizione di poter svolgere al meglio
il proprio ruolo. A tal fine, deve condividere gli obiettivi da raggiungere con la squadra di lavoro, coordinando
le risorse umane, fornendo loro la motivazione necessaria, seguendone il lavoro e dando loro feed-back su
quanto svolto.
29
Le competenze specifiche del Project Manager sono riconducibili all’area tecnico-specialistica del settore,
all’area gestionale per la conoscenza aziendale e degli strumenti di Project Management, e all’area
relazionale, per il lavoro di team ed i rapporti interpersonali, per i problemi legati alla leadership, alla delega
e alla negoziazione. Nello svolgimento del suo compito, il Project Manager deve dimostrare di saper (2):
• comunicare: durante il progetto, il Project Manager dovrà da un lato gestire la comunicazione con il
team di progetto, comunicando alla squadra cosa fare per raggiungere gli obiettivi e ascoltando i
diversi collaboratori, dall’altro gestire le comunicazioni esterne, scrivendo relazioni, rapporti e
mantenendo i contatti attraverso la posta elettronica;
• motivare: il Project Manager deve saper motivare le persone che lavorano insieme a lui, creando il
giusto spirito di squadra, riconoscendo la paternità del lavoro svolto dai singoli, facendo crescere le
individualità di valore all’interno del team e trasmettendo al gruppo di lavoro l’idea che gli interessi
dei singoli, inevitabilmente diversi, possono essere raggiunti solo attraverso il raggiungimento
dell’obiettivo finale;
• delegare: nonostante sia spesso difficile per un leader, dotato di elevata autostima ed abituato ad
avere tutto sotto controllo, la cessione di una responsabilità o di un potere ad un’persona è un’azione
inevitabile da parte del Project Manager che potrà concentrarsi sui suoi compiti diretti;
• negoziare: la negoziazione consiste nel colloquiare con una controparte al fine di raggiungere una
soluzione reciprocamente soddisfacente in merito alla problematica analizzata e, seppur sia spesso
legata alle attitudini personali del singolo, può essere appresa, conoscendone i punti che ne
caratterizzano il percorso;
• governare: tra i principali compiti del Project Manager vi è quello di saper governare, gestire e
motivare le risorse umane coinvolte nel progetto ma, affinché ciò avvenga efficacemente, è
necessario che la squadra sia consapevole dell’importanza che il direttore di progetto ricopre.
2.3.3 Ambito e campi di applicazione
Le tecniche di Project Management sono prevalentemente usate per gestire progetti più o meno complessi,
per la realizzazione, ad esempio, di grandi opere civili ed industriali, stabilimenti “chiavi in mano”, grandi
sistemi urbanistici, servizi, installazione di macchinari, sistemi di trasporto (9); la sfera di azione del Project
Management si è estesa negli anni anche ad altri ambiti, di grande rilevanza economica in particolare nei
settori aerospaziale, agricolo, bancario, delle telecomunicazioni, informatico e del risparmio energetico.
Seppur tradizionalmente utilizzato nel campo dell’ingegneria civile e industriale e per la difesa, il Project
Management sta estendendosi anche alle aziende che lavorano su produzioni di serie e a quelle dei servizi,
30
trovando sempre più spazio in contesti caratterizzati da un alto tasso di innovazione, incertezza dei risultati
e grande complessità tecnica e organizzativa (2). Le aziende operano infatti in un mercato in continua e rapida
crescita ed evoluzione, caratterizzato da sempre più determinanti innovazioni tecnologiche, rapidi
cambiamenti nelle esigenze dei consumatori ed elevato tasso di competitività.
Se da un lato l’internazionalizzazione di molte industrie e del mercato impone alle aziende di sviluppare la
capacità di gestire grossi e difficili progetti attraverso l’adozione di figure il cui obiettivo è quello di portarlo
con successo a compimento, dall’altro il mercato sempre più competitivo comporta la necessità di
cambiamento nelle aziende (20). La figura del Project Manager è infatti chiamata ad intervenire per gestire:
• progetti di cambiamento strategico, per proporre, ad esempio, nuove o diverse soluzioni di prodotto
sul mercato;
• progetti di cambiamento organizzativo, nel caso in cui un’azienda voglia intraprendere un
cambiamento in termini di organizzazione della struttura organizzativa interna;
• progetti di innovazione tecnologica, nei casi in cui l’impresa voglia inserire al suo interno nuovi
sistemi tecnologici o informatici.
La grande varietà dei campi di applicazione è illustrata dai molti gruppi d’interesse (SIG, specific interest
groups) in seno al PMI (Project Management Institute). La Tabella 5 mostra tutti i possibili ambiti di
applicazione delle tecniche di Project Management.
Tabella 5- I SIG (Specific Interest Group) dedicati a specifici settori applicativi in seno al PMI (19)
Le metodologie e le tecniche di Project Management sono fondamentalmente le stesse in tutti i settori
applicativi, per quanto siano diversi i risultati e gli obiettivi che consentano di raggiungere. I principi del
Project Management hanno infatti validità universale, risultando appropriati a tutti i settori applicativi,
seppur con significative varianti tra i diversi settori ed i diversi contesti culturali nei quali i progetti vengono
sviluppati, per quanto riguarda la pianificazione e l’esecuzione (19).
31
3. Metodologie, linee guida e standard di qualita’ di project
management
Nei successivi paragrafi saranno presentati e messi a confronto i principali standard e le più diffuse
metodologie che hanno contribuito ad arricchire l’ambito della gestione dei progetti; la scelta è ricaduta sui
modelli considerati i più importanti come conseguenza della loro ampia diffusione sul mercato.
I principali standard, metodologie e linee guida proposti negli anni, su cui si è deciso di concentrare
l’attenzione in questo lavoro di tesi, sono:
• Il PMBOK Guide: il “Project Management Book Of Knowledge” (PMBOK), scritto dal “Project
Management Institute”, è il modello di Project Management più diffuso al mondo. Il libro, pubblicato
nel 1996, rappresenta uno dei principali contributi alla gestione dei progetti; i suoi principi, tecniche
e strumenti sono stati ripresi ed inseriti in diversi altri modelli.
• PRINCE2: il modello, sviluppato nel 1989 dall’agenzia “Central Computer and Telecommunication
Agency” si basa su processi, tematiche e principi a supporto del Project Manager.
• Competence Baseline (ICB): le linee guida proposte dall’ “International Project Management
Association” riportano e descrivono le diverse tipologie competenze proprie di un Project Manager.
In aggiunta, saranno analizzati gli standard proposti dall’ “International Organization for Standardization”
(ISO) in materia di Project Management, tra cui:
• ISO 10006:2003, “Quality management systems – Guidelines for quality management in projects”
• ISO 21500:2012, “Guidance on Project Management”
Verso la fine degli anni Novanta varie Istituzioni riconosciute a livello internazionale hanno definito una serie
di regole e pratiche per valutare la qualità di un progetto e dei prodotti realizzati. Queste regole e best
practice prendono il nome di “standard”. Gli standard vengono utilizzati nella gestione di un progetto per
dare al cliente una certificazione, garantita a livello internazionale, della qualità del prodotto realizzato.
32
3.1 Definizione standard e metodologie
Si è soliti usare, quando si discute di Project Management o in altri contesti, i termini “metodo”,
“metodologia”, “standard”, dando a questi termini un significato simile. Seppur questo errore possa essere
trascurato nel linguaggio parlato, poiché le tre parole hanno finito per assumere in pratica quasi lo stesso
significato, risulta necessario specificare le sottili differenze di significato quando si discute di discipline più
specialistiche. Nel campo dei professionisti, infatti è fondamentale sia avere un comune e riconosciuto
glossario che evitare incomprensioni lessicali o di contenuti. Una prima differenza di significato è da ricercarsi
tra le parole “metodo” e “metodologia”.
Il termine “metodo” deriva dalle due parole del greco antico, “meta” e “odos”; la prima può significare in
questo contesto “attraverso”, la seconda significa invece “strada”. Pertanto può aver senso attribuire alla
parola metodo il significato di insieme di regole o procedimento attraverso il quale giungere ad una meta,
raggiungere un obiettivo (nel caso del Project Manager, la fine del progetto).
Il termine “metodologia” combina le due parole greche appena analizzate ad una terza, “logos”, che significa
“discorso” oppure “filosofia”. In sostanza, la parola metodologia rappresenta la ricerca e le filosofie di
pensiero necessarie per la costruzione e la definizione di quei principi che costituiscono la base di un metodo.
Una volta chiara la definizione e il significato delle due parole, possiamo utilizzarle nella loro giusta accezione
in ambito di Project Management: dapprima una metodologia dovrebbe dare l’essenza, il significato, i principi
e i fondamenti alla materia, in un secondo momento i metodi dovrebbero rispondere alla necessità di
utilizzare e mettere in pratica, su casi applicativi reali e concreti, i concetti fondamentali della gestione dei
progetti alla base della metodologia di riferimento (21).
I testi di riferimento analizzati in questo lavoro di Tesi possono quindi distinguersi tra metodi e metodologie:
il Competence Baseline (ICB), il Project Management Book Of Knowledge (PMBOK) e le norma ISO 1006:2003
e 21500:2012 posso essere definiti riferimenti metodologici; al contrario PRINCE2 nasce e si presenta come
un documento di metodo, nonostante il manuale di riferimento abbia un’introduzione metodologica (22).
Oltre all’erronea abitudine di utilizzare i termini metodo e metodologia per intendere lo stesso concetto, è
anche spesso confuso il significato dei termini “standard” e “metodo”, attribuendogli un’accezione errata.
Uno standard è un documento che fornisce ed indica i requisiti, le specifiche, le linee guida o le caratteristiche
che possono essere usate per assicurarsi che i materiali, i prodotti, i processi e i servizi siano adeguati al loro
scopo (23). In altre parole, uno standard può essere definito come un insieme di regole e pratiche che,
utilizzate nella gestione di un progetto, danno al cliente una certificazione della qualità del prodotto
realizzato. Possono essere identificate due principali tipologie di standard:
33
• gli standard de jure sono quelli ufficialmente accreditati e approvati da un organo di normazione
riconosciuto, dopo essere stati analizzati e valutati da un gruppo di esperti, senza che però diventi
obbligatoria la loro applicazione;
• gli standard de facto sono normalmente considerati standard, e quindi applicati con consuetudine,
a causa della loro ampia diffusione sul mercato, pur non avendo mai ottenuto l’accreditamento
ufficiale da parte di organi di normazione riconosciuti.
Tra gli standard analizzati in questo lavoro di tesi, il Project Management Body of Knowledge (PMBOK) e la
norma ISO 21500 sono degli standard de jure; al contrario IPMA Competence Baseline e PRINCE2 (Project in
Controlled Environments) possono considerarsi standard de facto.
Esiste quindi una differenza concettuale importante tra uno standard, un metodo ed una metodologia:
• uno standard può essere definito come un insieme di processi e regole considerate buona prassi
ovvero uno schema di riferimento del Project Management che spiega “cosa fare”, specificando cosa
deve essere fatto e da chi, ma non come le attività debbano essere realizzare (24);
• un metodo, formulato per un uso pratico, è un set di processi che possono essere usati in ogni tipo
di progetto per il raggiungimento di determinati obiettivi e fornisce indicazioni non solamente sulle
(25) attività che devono essere svolte e sui relativi responsabili, ma anche sulle tecniche pratiche da
impiegare per la loro realizzazione (24);
• una metodologia è il complesso dei fondamenti teorici su cui un metodo è costruito ovvero, più in
generale, lo studio del metodo su cui si fonda la disciplina del Project Management.
Una metodologia o un metodo possono essere adottati come standard ma uno standard non può diventare
un metodo o una metodologia. Infatti il Project Management Body of Knowledge (PMBOK), già identificato
come uno standard de jure, può essere considerato come la base per le metodologie di Project Management
ma non può diventare una metodologia; al contrario PRINCE2 è un metodo in materia di Project
Management, riconosciuto come standard de facto per il Project Management, non solo nel Regno Unito ma
in più di 150 Paesi nel mondo (24,26,27) .
Ciò che accomuna i quattro documenti oggetto di questo confronto è la loro area di applicazione: il loro
obiettivo è quello di fornire regole e linee guida per una corretta ed efficiente applicazione del Project
Management, inteso come “gestione complessa di un’impresa unica e di durata determinata, rivolta al
raggiungimento di un obiettivo chiaro e predefinito mediante un processo continuo di pianificazione e
controllo di risorse differenziate e con vincoli interdipendenti di costi-tempi-qualità”(19).
34
3.2 Project Management Institute (PMI) -Project Management Book Of Knowledge
(PMBOK)
Il Project Management Institute (PMI) è oggi l’associazione di Project Management maggiormente diffusa nel
mondo. Il PMI fu fondato nel 1969 come organizzazione no-profit da Ned Engman, James Snyder, Susan
Gallagher, Eric Jenett e J. Gordon Davis presso il Georgia Institute of Technology (25). Nello stesso anno, ad
Atlanta (Giorgia, USA), ebbe luogo il primo PMI Seminars & Symposium, evento che da allora si ripete tutti
gli anni.
Il PMI conta attualmente più di 450.000 associati in 204 Nazioni, più di 280 associazioni locali sussidiarie (i
cosiddetti “Local Chapters”) e oltre 1 milione di persone certificate, provenienti da vari settori (quali
aerospaziale, automotive, Business Management, costruzioni, ingegneria, servizi finanziari, Information
Technology, farmaceutico, sanitario e telecomunicazioni) (28).
A partire dagli anni ’80, il PMI concentra le proprie energie per la realizzazione di un documento che raccolga
gli standard e le procedure nel Project Management. Nel 1996 viene prodotta e pubblicata la prima edizione
del Project Management Body ofKnowledge (PMBOK Guide), diventata poi uno Standard ANSI (ANSI/PMI 99-
001-2008) (29).
Il “Project Management Body of Knowledge” (PMBOK) si è notevolmente evoluto rispetto alla sua prima
versione ed è attualmente alla sua quinta edizione. Inizialmente sviluppato per l’industria delle costruzioni,
è oggi largamente adottato anche in altri settori, ad esempio in quello informatico, ed è considerato il più
generico e tradizionale framework per il Project Management (30).
Il PMBOK è una metodologia ad ampio spettro in grado di fornire le informazioni necessarie per la gestione
di diverse tipologie di progetti. Secondo il PMBOK, il Project Management si basa su processi, suddivisi in 5
gruppi di processo, e fa riferimento a varie arie funzionali.
Nel tempo il PMBOK è stato ampliato e aggiornato, rendendolo sempre uno strumento attuale ed efficace.
Mettendo a confronto le cinque edizioni del documento emerge che l’approccio al Project Management ha
subito negli anni notevoli cambiamenti, in termini di numero di processi e di loro definizioni .
35
Tabella 6- Numero dei processi del progetto considerati nelle cinque edizioni del PMBOK Guide (31)
Nella Tabella 6 sono riassunte le modifiche, in termini di numero di processi, che le diverse versioni hanno
subito nel tempo. Nella quinta edizione, quella attualmente in uso e pubblicata nel 2012, il PMBOK propone
47 processi, 10 aree di conoscenza e 5 processi di gestione.
Di seguito si descriverà la struttura del PMBOK e si concentrerà l’attenzione sui gruppi di processi, le aree di
conoscenza e i relativi processi, descritti all’interno dell’ultima versione del PMBOK.
3.2.1 Struttura del PMBOK
Come mostrato in Figura 10, ci sono tre diversi livelli di elementi, contrassegnati con diverse gradazioni di
grigio, ognuno suddiviso in due sottocategorie. Scomponendo la struttura in livelli, dal basso verso l’alto, si
individuano (32):
• Livello n°1 (grigio scuso) – Gruppi di processi: nell’immagine sono rappresentati i cinque gruppi di
processi, che rappresentano la sequenza logica dell’intera attività di Project Management; il gruppo
di processo di “monitoraggio e controllo” è trasversale a tutti gli altri.
• Livello n°2(grigio chiaro) – Processi: i processi sono specifici elementi che, se opportunamente
implementati ed integrati, consentono il reale conseguimento del Project Management; ogni
processo è caratterizzato dai propri input, strumenti, tecniche e output. L’immagine mette in
evidenza anche i processi relativi all’area di conoscenza “Gestione dell’integrazione del Progetto”.
• Livello n°3 (grigio intermedio) – Aree di Conoscenza: ogni processo fa riferimento ad una specifica
area di conoscenza, che indica l’obiettivo comune a tutti i processi che ne fanno parte; nell’immagine
è evidente come l’area di conoscenza “Gestione dell’Integrazione del Progetto” gestisca
l’interdipendenza tra tutte le altre.
36
Figura 10- Struttura del PMBOK 2012 (32)
37
3.2.2 Gruppi di processi del PMBOK
Un processo è un insieme di azioni e attività tra loro connesse, eseguite per la realizzazione di uno specifico
prodotto, servizio o risultato. I processi di un progetto possono essere suddivisi in due categorie principali:
• processi di Project Management: hanno l’obiettivo di descrivere e organizzare il lavoro del progetto;
• processi orientati al prodotto: hanno l’obiettivo di specificare e creare il progetto di un prodotto.
Il PMBOK descrive esclusivamente i processi di Project Management e li suddivide in cinque categorie,
definite gruppi di processo di Project Management o, più semplicemente, gruppi di processo:
• Inizio;
• Pianificazione;
• Esecuzione;
• Monitoraggio e Controllo;
• Chiusura.
Si fa presente che il gruppo di processo di Monitoraggio e Controllo si considera come un gruppo di processo
“di fondo” per gli altri quattro gruppi e che i gruppi di processo non rappresentano le fasi del progetto, ma
possono essere impiegati in ogni singola fase.
La Figura 11 schematizza i gruppi di processo considerati nel PMBOK e sottolinea come il gruppo di processo
di Monitoraggio e Controllo sottenda gli altri quattro.
Figura 11- Gruppi di processi di Project Management (33)
38
3.2.2.1 Inizio
Il Gruppo di Processo di Inizio si compone di tutti quei processi realizzati con il fine di definire un nuovo
progetto o una nuova fase di un progetto esistente. Nel gruppo di processo di inizio avvengono
l’autorizzazione del progetto, la definizione degli obiettivi, dell’ambito del progetto e delle principali
milestone, la valutazione delle risorse finanziarie iniziali. Obiettivi e ambito rappresentano dei punti di
riferimento durante tutto lo sviluppo del processo e saranno utilizzati come riferimento per valutarne il grado
di successo. Durante la fase di inizio, si identificano tutti gli agenti, interni ed esterni, coinvolti direttamente
e indirettamente nel progetto; è sempre in questa fase che si identifica chi avrà il ruolo di Project Manager.
Vengono inoltre redatti: il Project Charter (Capitolato di Progetto), ovvero un documento redatto dal Project
Manager contenente obiettivi, ambito, ruoli, costi e rischi; i Business Case, documenti di progetto nei quali
vengono riportate le stime di distribuzione temporale prevista dei costi e dei ricavi.
Risulta fondamentale coinvolgere tutti gli stakeholders del progetto già nella fase di inizio; questo tipo di
approccio migliora nettamente il gradimento del progetto e quindi il soddisfacimento del committente e di
tutti gli interessati.
3.2.2.2 Pianificazione
Il Gruppo di Processo di Pianificazione si compone di tutti quei processi realizzati per stabilire la portata totale
del lavoro, per definire ed affinare gli obiettivi e sviluppare la linea d’azione richiesta per raggiungere gli
obiettivi stessi. Il Gruppo di Processo di Pianificazione si concentra dunque sullo sviluppo dello schema
lavorativo per il raggiungimento degli obiettivi sulla base dei vincoli evidenziati nel processo precedente.
La pianificazione è un processo chiave del PMBOK e le principali attività svolte sono: analisi quantitativa e
qualitativa dei rischi, identificazione e gestione dei rischi della pianificazione, pianificazione delle
comunicazioni, gestione delle risorse umane, gestione della qualità, stima dei costi, sviluppo del piano di
progetto, definizione delle attività, della loro durata e sequenza, definizione dell’ambito e formulazione della
Work Breakdown Structure.
Il principale obiettivo di questo Gruppo di Processi consiste quindi nel tracciare la strategia, le linee guide e
il percorso per completare con successo il progetto o la fase.
39
3.2.2.3 Esecuzione
Il Gruppo di Progetto di Esecuzione è composto da tutti quei processi realizzati per completare le lavorazioni
previste in fase di pianificazione, rispettando le specifiche del progetto. Questo Gruppo di Processo implica il
coordinamento delle risorse umane e materiali, l’integrazione e la realizzazione delle attività del progetto
così come pianificato. Tra le principali attività del Gruppo di Processo di Esecuzione si ricordano: il
procurement, la gestione delle aspettative degli stakeholders, la distribuzione delle informazioni, lo sviluppo
e la gestione del team, Quality Assurance e la direzione dell’esecuzione del progetto.
Durante l’esecuzione, in funzione dei risultati ottenuti, è possibile che sia necessaria un’attualizzazione della
pianificazione e una revisione del piano iniziale. Le variazioni, e quindi la necessità di ripianificazione, possono
essere provocate da variazioni della durata prevista per le attività, cambi della disponibilità e della
produttività delle risorse e dal verificarsi di rischi non previsti. Il verificarsi di uno o di alcune di queste
condizioni potrebbe rendere necessaria un’analisi dettagliata e lo sviluppo di una risposta adeguata in termini
di ripianificazione.
3.2.2.4 Monitoraggio e controllo
Il Gruppo di Processo di Monitoraggio e Controllo non deve essere inteso come temporalmente successivo a
quelli di Inizio, Pianificazione ed Esecuzione, ma come contemporaneo agli altri, dall’inizio alla chiusura.
Il Gruppo di Processo di Monitoraggio e Controllo si compone di tutti quei processi richiesti per identificare,
analizzare e dirigere il progresso e le performance del progetto, per identificare le aree in cui si chiedere una
modifica del piano iniziale. Le performance del progetto vengono misurate ed analizzate ad intervalli regolari,
al fine di identificare eventuali variazioni rispetto al piano originario. Il Project Manager, valutando il
progresso del progetto attraverso tecniche specifiche, misura, controlla e monitora continuamente tutte le
attività del progetto.
Le principali attività del Gruppo di Processo di Monitoraggio e Controllo sono:
• controllo dei cambiamenti e assunzione di azioni correttive che correggano o prevengano il verificarsi
di problemi;
• monitoraggio delle attività del progetto e delle loro performance, confronto del loro stato di
avanzamento rispetto a quanto preventivato in fase di pianificazione;
• influire sui fattori che potrebbero eludere il controllo integrato dei cambi, in modo che si
implementino unicamente cambi approvati.
40
Questo controllo continuo permette al gruppo di progetto di acquisire una conoscenza approfondita sul
progetto e sul suo avanzamento, consentendo di identificare le aree sulle quali concentrare maggiormente
l’attenzione.
3.2.2.5 Chiusura
Il Gruppo di Processo di Chiusura si compone di tutti quei processi realizzati con l’obiettivo di concludere le
attività necessarie al formale completamento del progetto. La conclusione del Gruppo di Processo
rappresenta la verifica che tutti i processi appartenenti agli altri quattro Gruppi di Processo siano stati
completati e consente di chiudere formalmente il progetto o una fase dello stesso.
Il Gruppo di Processo di Chiusura è caratterizzato dal completamento di tutte le attività del progetto e dalla
sua accettazione formale da parte di tutti gli stakeholders coinvolti. Sono previste attività di documentazione
delle attività svolte che riportino anche una valutazione del progetto.
3.2.3 Aree di conoscenza del PMBOK
I 47 processi di Project Management identificati nella Guida del PMBOK si raggruppano a loro volta in dieci
Aree di Conoscenza differenti. Un’Area di Conoscenza rappresenta un insieme di concetti, termini e attività
che si riferiscono necessarie per assolvere ad un insieme di specifiche finalità.
Di seguito saranno brevemente descritte tutte le Aree di Conoscenza indicate all’interno del PMBOK e
riportate nella Tabella 7:
• Gestione dell’Integrazione di Progetto;
• Gestione dell’Ambito di Progetto;
• Gestione dei Tempi di Progetto;
• Gestione dei Costi di Progetto;
• Gestione della Qualità di Progetto;
• Gestione delle Risorse umane di Progetto;
• Gestione della Comunicazione di Progetto;
• Gestione dei Rischi di Progetto;
• Gestione dell’Approvvigionamento di Progetto;
• Gestione degli Stakeholders di Progetto.
41
Tabella 7- Mappa dei Gruppi di Processi di Project Management e delle Aree di Conoscenza (33)
42
3.2.3.1 Gestione dell’Integrazione di Progetto
Questo Ambito di Conoscenza raggruppa tutti i processi necessari ad assicurare che i vari aspetti del progetto
vengano coordinati tra loro in modo appropriato. Prevede l’unificazione, il consolidamento, la comunicazione
e l’incorporamento delle azioni essenziali per completare il progetto in modo controllato, in modo che siano
soddisfatte le aspettative degli stakeholders e siano rispettati i requisiti.
La Gestione dell’Integrazione di Progetto comprende i seguenti processi:
• sviluppo del Project Charter: formulazione della documentazione necessaria ad autorizzare
formalmente il progetto e conferire autorità al Project Manager;
• sviluppo del Piano di Project Management: definizione, preparazione e cordinazione di tutti i piani
secondari e realizzazione di un piano integrato per la direzione del progetto;
• direzione e gestione del lavoro di progetto: gestione del lavoro, implementazione dei cambi
approvati con l’obiettivo di raggiungere gli obiettivi del progetto;
• monitoraggio e controllo del lavoro di progetto: revisione e controllo dell’avanzamento del progetto
rispetto a quanto definito nel Piano di Project Management;
• controllo integrato delle modifiche: analisi di tutte le richieste di cambio e loro approvazione e
gestione;
• chiusura del progetto o di una fase: completamento di tutte le attività, finalizzato al completamento
e alla chiusura del progetto o di una fase.
3.2.3.2 Gestione dell’Ambito di Progetto
Questo Ambito di Conoscenza comprende tutti i processi necessari per assicurare che il progetto includa tutti
e solo i lavori richiesti per completare il progetto con successo. Gestire l’Ambito di Progetto consiste
principalmente nel definire e nel controllare cosa si include e cosa non si include nel progetto.
La Gestione dell’Ambito di Progetto comprende i seguenti processi:
• pianificazione dello gestione dell’ambito: creazione di un piano di gestione dell’ambito che
documenti come si procede alla definizione, validazione e controllo dell’ambito di progetto;
• raccolta dei requisiti: processo di determinazione, documentazione e gestione delle necessità e dei
requisiti specificati dagli stakeholders che soddisfino gli obiettivi del progetto;
• definizione dell’ambito: sviluppo di una relazione dettagliata del progetto o del prodotto;
43
• creazione della Work Breakdown Structure: scomposizione del progetto attraverso un diagramma
ad albero che semplifichi la lettura del progetto attraverso la sua separazione in attività e di queste
in deliverables;
• validazione dell’ambito: formalizzazione dell’accettazione dei deliverables del progetto completati;
• controllo dell’ambito: monitoraggio dello stato di ambito del progetto o del prodotto e gestione dei
cambi rispetto all’ambito previsto inizialmente.
3.2.3.3 Gestione dei Tempi di Progetto
Questo Ambito di Conoscenza comprende tutti i processi necessari per il completamento del progetto in
termini di tempo.
La Gestione dei Tempi di Progetto prevede lo scheduling delle attività e il loro monitoraggio in termini di
sviluppo temporale. I Project Managers dovrebbero specificare la sequenzialità delle attività definendo e
documentando le relazioni che intercorrono tra loro; è inoltre consigliato che vengano esplicitate le risorse
necessarie per realizzazione e il completamento di ogni attività, la loro durata e il percorso critico, che
evidenzia le attività che, se ritardate, porterebbero ad uno slittamento temporale di tutto il progetto.
La Gestione dei Tempi di Progetto comprende i seguenti processi:
• pianificazione della gestione dei tempi: processo attraverso cui si stabiliscono i procedimenti e la
documentazione per pianificare, sviluppare, gestire, eseguire e controllare il cronoprogramma del
progetto;
• definizione delle attività: processo di indentificazione e documentazione delle azioni che è
necessario eseguire per produrre i deliverables di progetto;
• sequenzializzazione delle attività: processo di identificazione e documentazione delle relazioni
esistenti tra le attività del progetto;
• stima delle risorse dedicate alle attività: processo di stima del tipo e della quantità di materiali,
risorse umane e attrezzature necessarie per l’esecuzione di ciascuna delle attività;
• stima delle durate delle attività: processo di stima della quantità di lavoro necessario per il
completamento di ogni attività in base alle risorse ad esse dedicate;
• sviluppo del cronoprogramma: processo di analisi di sequenza delle attività, durate, risorse
necessarie e restrizioni del cronoprogramma, con l’obiettivo di creare un modello di
programmazione del progetto;
44
• controllo del cronoprogramma: processo di monitoraggio dello stato delle attività del progetto, con
l’obiettivo di attualizzare lo stato di avanzamento del progetto e gestire i cambi rispetto a quanto
pianificato per raggiungere il risultato.
3.2.3.4 Gestione del Costo di Progetto
La Gestione del Costo di Progetto include i processi relativi alla pianificazione, estimazione, pianificazione
delle spese, finanziamenti, gestione e controllo dei costi, in modo che il progetto si completi all’interno del
budget approvato.
La Gestione del Costo di Progetto si riferisce alla pianifiazione, alla stima e al controllo dei costi del progetto
per garantirne il completamento rispettando il budget. La stima dei costi prevede la definizione dei costi delle
risorse necessarie per completare l’intero progetto. L’obiettivo è definire le risorse finanziarie necessarie e,
quindi, il budget di progetto che, una volta fissato, funge da parametro per giudicare le deviazioni e le
variazioni al progetto.
La Gestione del Costo di Progetto comprende i seguenti processi:
• pianificazione della gestione dei costi: processo che stabilisce i procedimenti e la documentazione
necessari per pianificare, gestire, impiegare e controllare i costi del progetto;
• stima dei costi: processo che consiste nello sviluppo di un’approssimazione delle risorse finanziarie
che si ritengono necessarie per il completamento delle attività del progetto;
• determinazione del budget: processo che consiste nel sommare i costi stimati delle singole attività
o delle lavorazioni per stabilire una linea guida di costo autorizzata;
• controllo dei costi: processo di monitoraggio dello stato del progetto per attualizzare i costi e gestire
i possibili cambi alla linea base dei costi.
3.2.3.5 Gestione della Qualità del Progetto
La Gestione della Qualità del Progetto include i processi e le attività dell’organizzazione esecutiva che
stabiliscono la qualità, gli obiettivi e le responsabilità in termini di qualità, in modo che il progetto soddisfi le
necessità per le quali è stato commissionato. La Gestione della Qualità comprende quindi le attività svolte da
un’organizzazione per determinare i responsabili della qualità, gli obiettivi e le politiche che garantiranno la
soddisfazione del cliente. Nell’assicurare la qualità, i Project Manager si focalizzano nell’applicazione di
sistematici e pianificati processi che assicurano che tutte le attività del progetto rispettino degli standard.
45
La Gestione della Qualità di Progetto comprende i seguenti processi:
• pianificazione della gestione delle risorse umane: processo di identificazione dei requisiti e degli
standard di qualità per il progetto e i suoi deliverables;
• esecuzione dell’assicurazione qualità: processo che consiste nel revisionare i requisiti di qualità e i
risultati delle misurazioni di controllo di qualità, per assicurarsi che si utilizzino le norme di qualità e
le procedure adeguate;
• controllo della qualità: processo nel quale si monitora e si registrano i risultati dell’esecuzione delle
attività di controllo di qualità, al fine di stimare le prestazioni e suggerire eventuali cambi necessari.
3.2.3.6 Gestione delle Risorse Umane di Progetto
La Gestione delle Risorse Umane di Progetto include tutti i processi finalizzati a organizzare, gestire e guidare
il gruppo di progetto, ai cui membri vengono assegnati ruoli e responsabilità per poter completare il progetto.
Nonostante si assegnino ai componenti del gruppo ruoli e responsabilità specifiche, si dovrebbe tendere a
preferire una partecipazione attiva di tutti i membri in fase decisionale per migliorare il risultati progettuali.
I membri del gruppo di progetto hanno solitamente competenze tecniche diverse, possono essere assunti a
tempo pieno o solo part-time e possono seguire tutto il progetto come solo una parte specifica del suo
sviluppo.
La Gestione delle Risorse Umane di Progetto comprende i seguenti processi:
• pianificazione della gestione delle risorse umane: processo che consiste nell’identificazione e
documentazione dei ruoli all’interno del progetto, delle responsabilità, delle abilità richieste, delle
modalità e delle forme di comunicazione con l’obiettivo finale di redarre un piano di gestione del
personale;
• costituzione del gruppo di progetto: conferma delle disponibilità delle risorse umane e creazione del
gruppo di lavoro necessario per completare le attività del progetto;
• sviluppo del gruppo di progetto: processo di miglioramento delle competenze tecniche, delle
interazioni tra i membri del gruppo di lavoro e, in generale, dell’ambiente lavorativo;
• gestione del gruppo di progetto: processo di rilevamento del lavoro del gruppo e dei singoli
componenti, risoluzione di problemi e gestione dei cambi al fine di ottimizzare l’impegno e le
prestazioni all’interno del progetto.
46
3.2.3.7 Gestione della Comunicazione di Progetto
La Gestione della Comunicazione di Progetto include tutti i processi richiesti per assicurare che la
pianificazione, raccolta, creazione, distribuzione, archiviazione, recupero, gestione, controllo, monitoraggio
e disposizione finale delle comunicazioni di un progetto siano opportuni e adeguati. I Project Managers
investono molte energie nelle comunicazioni con i membri del gruppo di lavoro e con tutti gli stakeholders di
progetto, siano essi interni o esterni alla stessa organizzazione. È fondamentale quindi impostare una
comunicazione efficace al fine di creare un legame tra tutti gli stakeholders che, spesso, hanno background
culturali differenti, diversi livelli di esperienza e distinti interessi. Una comunicazione frequente è necessaria
in un progetto, perché permette di fornire le informazioni necessarie agli stakeholders, riduce le resistenze
ai cambiamenti, incoraggia l’innovazione e creatività, e stabilisce l’autorità per assicurare efficienza nelle
risorse allocate.
La Gestione della Comunicazione di Progetto comprende i seguenti processi:
• pianificazione della gestione delle comunicazioni: il processo di sviluppo di un piano di
comunicazione del progetto con gli stakeholders sulla base delle loro necessità e esigenze;
• gestione delle comunicazioni: il processo di creare, raccogliere, distribuire e archiviare le disposizioni
finali delle informazioni del progetto in accordo con il piano di gestione delle comunicazioni;
• controllo delle comunicazioni: processo di monitoraggio e controllo delle comunicazioni durante
tutto il ciclo di vita dell’edificio, per assicurare che siano soddisfatte le necessità di informazioni di
tutti gli stakeholders.
3.2.3.8 Gestione dei Rischi di Progetto
La gestione dei rischi, altrimenti detta Risk Management, è uno dei compiti fondamentali del Project Manager
ed è imprescindibile per la buona riuscita di un progetto. Il rischio di un progetto è un evento o una condizione
incerta che, verificandosi, produce effetti positivi o negativi sugli obiettivi del progetto, in relazione allo stato
di avanzamento, al cronoprogramma, ai costi e alla qualità delle lavorazione e dei deliverables. I rischi hanno
origine nell’incertezza insita in tutti i progetti e possono essere gestiti in maniera attiva, dopo opportuna
identificazione e analisi del rischio stesso, della sua probabilità di accadimento e del suo impatto sul progetto.
Nei progetti, la gestione dei rischi non corrisponde all’eliminazione del rischio ma consiste nel loro studio e
nella loro identificazione preventiva, con l’obiettivo di individuare quali attività o fasi siano più critiche, quali
siano quelle in cui investire più energia e attenzione e per le quali è richiesto un intervento tempestivo.
47
La Gestione dei Rischi di Progetto comprende i seguenti processi:
• pianificazione della gestione dei rischi: processo di definire come realizzare le attività delle gestione
dei rischi di un progetto;
• identificazione dei rischi: processo di determinare, attraverso un’operazione di denominazione e
descrizione, i rischi che possono interessare il progetto;
• esecuzione analisi qualitativa dei rischi: stabilire l’ordine di priorità dei rischi in funzione, valutando
e combinando la probabilità di accadimento e l’impatto dei rischi identificati;
• esecuzione analisi quantitativa dei rischi: processo di analisi numerica dell’effetto dei rischi sugli
obiettivi del progetto;
• pianificazione della risposta ai rischi: processo in cui si sviluppano opzioni e azioni per migliorare le
opportunità e ridurre le minacce agli obiettivi del progetto;
• controllo dei rischi: implementazione dei piani di risposta ai rischi, controllo dei rischi identificati,
monitoraggio dei rischi residui, identificazione di nuovi rischi e valutazione dei risultati del processo
di gestione.
3.2.3.9 Gestione degli Approvvigionamenti di Progetto
La Gestione dell’Approvvigionamento di Progetto include i processi necessari all’acquisizione di servizi e
prodotti esterni al team del progetto. Prevede la pianificazione delle acquisizioni definendo le modalità di
ordine e le tempistiche di consegna. I responsabili dell’approvvigionamento all’interno del gruppo di lavoro
creano un documento riportante i potenziali venditori, specificando servizi e prodotti offerti; definito il parco
fornitori, il Project Manager ha il compito di scegliere quale sia la scelta migliore e di gestire e controllare gli
approvvigionamenti di progetto.
La Gestione dell’Approvvigionamento di Progetto comprende i seguenti processi:
• pianificazione della gestione degli approvvigionamenti: specifica delle decisioni in materia di
approvvigianamento e identificazione dei potenziali venditori;
• gestione degli approvvigionamenti: richiesta di informazioni e preventivi ai venditori, scelta della
migliore soluzione tra quelle valutate, stipulazione del contratto;
• controllo degli approvigionamenti: gestione dei processi di acquisizione, monitoraggio
dell’esecuzione del contratto, realizzazione cambi e correzioni se necessario;
• chiusura degli approvvigionamenti: completamento di ogni fase dell’approvvigionamento.
48
3.2.3.10 Gestione degli Stakeholders di Progetto
La Gestione degli Stakeholders di Progetto include tutti i processi necessari per identificare le persone, i
gruppi o le organizzazioni che possano essere coinvolte o influenzare direttamente o indirettamente il
progetto; l’obiettivo è quello di analizzare le loro aspettative e richieste, per sviluppare delle strategie di
gestione che facilitino e stimolino la loro partecipazione alle decisioni sul progetto. A tal fine è necessario un
flusso di comunicazione continuo per poter rispondere alle loro reali esigenze e necessità ed aumentare il
grado di soddisfacimento di tutti gli interessati al progetto.
• identificazione degli stakeholders: identificazione di tutte le persone e dei gruppi di persone,
coinvolti direttamente nel progetto o interessati da un risultato o da un’attività, e analisi del loro
grado di coinvolgimento e dei loro interessi;
• pianificazione della gestione degli stakeholders: sviluppo di strategie adeguate per raggiungere la
partecipazione ed il coinvolgimento di tutti gli stakeholders durante tutto il ciclo di vita del progetto;
• gestione del coinvolgimento degli stakeholders: comunicazione e lavoro sinergico con gli
stakeholders per soddisfare le loro esigenze e coinvolgerli in modo adeguato nel progetto;
• controllo del coinvolgimento degli stakeholders: monitoraggio delle relazioni tra gli stakeholders e
modifiche strategiche, qualora necessario, per migliorare il loro coinvolgimento.
49
3.3 International Project Management Association (IPMA) - Competence Baseline (ICB)
L’International Project Management Association (IPMA) è la prima associazione in materia di Project
Management. Nata nel 1965 è oggi un’organizzazione internazionale presente in oltre 60 Paesi, in ognuno
dei quali è rappresentata da una Member Association. Il nome originario dell’associazione era INTERNET,
cambiato in IPMA nei primi anni ’70.
Dalla sua fondazione, l’IPMA si è estesa progressivamente, vantando attualmente oltre 120.000 membri in
Europa, Russia, Africa, Asia, Nord e Sud America. Presenti in tutti i continenti, le associazioni IPMA hanno
costituito un network globale in grado di intraprendere numerose iniziative volte sia alla distribuzione e
condivisione di idee e best practice inerenti la gestione dei programmi e progetti sia a rilasciare ai Project
Manager di tutto il mondo Certificazioni professionali.
In Italia, la sezione di Project Management dell’ANIMP (Associazione Nazionale Impiantistica Industriale)
fondata nel Luglio 2986 si è evoluta, a partire dal 1 Giugno 2007, nella “Italian Project Management Academy”
e, successivamente, in IPMA Italy (34). IPMA Italy si rivolge ai settori privati e pubblici, industriali e dei servizi
con l’obiettivo di potenziare le capacità imprenditoriali italiane e di diffondere la cultura del Project
Management, necessaria per la corretta gestione di qualsiasi tipologie di progetto, anche attraverso un
rigoroso processo di certificazione professionale.
3.3.1 Le certificazioni in Project Management IPMA
Il Certification Body italiano ha sviluppato, in ossequio alle procedure IPMA internazionali, due documenti
specifici: “Manuale della Certificazione dei Project Manager” e “Manuale delle Competenze di Project
Management”.
Per certificare le competenze dei Project Manager, IPMA ha introdotto un Sistema di Certificazioni che, oltre
ad essere accreditato dall'International Project Management Association, rispetta le normativa europea (EN
ISO/IEC 17024) ed italiana (UNI CEI EN ISO/IEC 17024 – luglio 2004) che definiscono i requisiti che gli
organismi di certificazione devono costantemente rispettare.
Il Sistema di Certificazione di IPMA Italy, illustrato in Figura 12, si basa sul modello IPMA Four Level
Certification (4-L-C) per valutare le competenze nelle attività di Project Management relative a quattro
categorie professionali (35):
50
• Livello A – Project Director: responsabile di un portafoglio progetti o di programmi ad elevata
complessità;
• Livello B – Senior Project Manager: responsabile di progetti ad elevata complessità;
• Livello C – Project Manager: responsabile di progetti non complessi;
• Livello D – Project Management Associate: attesta conoscenze nel campo del Project Management.
Figura 12- Livelli di certificazione IPMA (35)
Il Sistema di Certificazioni IPMA non certifica soltanto le conoscenze nel Project Management, come risultato
di apprendimento tramite corsi di formazione specifici, ma le competenze che tengono conto dell’esperienza
acquisita ed anche delle attitudini personali dimostrate nello sviluppo professionale. Nel mondo del Project
Management, la Certificazione IPMA è considerata “Experience Based” proprio perché attesta le competenze
intese come combinazione di “Conoscenze, esperienze e attitudini personali”. Per ognuno dei quattro livelli,
è richiesto uno specifico numero di anni di esperienza lavorativa; alcuni autori ritengono questo un punto un
po’ controverso, poichè l’insieme delle competenze richieste non sempre è proporzionale al numero di anni
di esperienza e, a volte, professionisti con meno esperienza lavorativa hanno invece competenze maggiori di
altri con più anni di lavoro alle spalle (30).
L’adozione del Sistema di Certificazioni IPMA risulta vantaggioso sia per le organizzazioni che ne fanno uso,
sia per i professionisti che operano in ambito di Project Management.
Su un piano personale, il Project Manager certificato IPMA vede il proprio profilo professionale arricchito da
un riconoscimento di un organismo accreditato internazionalmente, con conseguente apprezzamento dei
vari stakeholders con i quali interagisce durante la sua esperienza lavorativa.
Dal punto di vista delle aziende, le certificazioni attestano al mercato quanto le stesse organizzazioni siano in
grado di affrontare e gestire i progetti in modo efficace e strutturato, grazie alla qualificazione dei propri
dipendenti. Inoltre, grazie alla standardizzazione delle certificazioni professionali IPMA, riconosciute
internazionalmente, le organizzazioni sono in grado di migliorare i processi di selezione, formazione e
strutturazione dei team di Project Management.
51
3.3.2 Struttura del Competence Baseline (ICB)
L’IPMA Competence Baseline (ICB) è stato sviluppato per la prima volta dall’International Project
Management Association (IPMA) nel 1998; alla seconda edizione del Febbraio 1999, è seguita la terza ed
ultima edizione, la ICB3 pubblicata nel Marzo 2006, notevolmente ampliata e perfezionata.
Il documento è diviso in due parti principali: nella prima parte vengono presentati e descritti i concetti chiave
in materia di Project Management e sono presentati i quattro livelli di certificazione IPMA, evidenziandone i
benefici per le aziende e i professionisti; nella seconda parte prende corpo il vero “Manuale delle
Competenze del Project Manager”.
Il metodo proposto dall’ICB scompone il Project Management in 46 elementi di conoscenza (competence
elements), raggruppati in tre aree di conoscenza principali che, combinate, compongono l’insieme chiamato
“Occhio delle competenze”, rappresentato in Figura 13. Oltre a rappresentare l’integrazione di tutte le
diverse competenze da applicare al Project Management nella pratica professionale, l’occhio simboleggia la
lucidità nell’approccio, la chiarezza nell’impostazione e nella gestione dei progetti, la visione d’insieme che
un Project Manager deve avere nel proprio bagaglio professionale.
Figura 13- Occhio delle competenze (36)
La metodologia individua tre principali campi, che contengono tutti gli elementi di conoscenza:
• Competenze tecniche: 20 elementi di competenza che riguardano la conoscenza tecnica in materia
di Project Management sulla quale i professionisti lavorano.
• Competenze comportamentali: 15 elementi di competenza che enfatizzano le relazioni tra i membri
del gruppo e quelle tra i gruppi che lavorano su progetti, programmi o portafogli di progetti;
• Competenze contestuali: 11 elementi di competenza che riguardano le relazioni tra il gruppo di
progetto e i fattori esterni, come contesto e l’organizzazione.
52
La Tabella 8 riporta tutti i 46 elementi di conoscenza per i tre campi di competenza tecnica, comportamentale
e contestuale, così come riportato dal Competence Baseline (ICB).
COMPETENZE TECNICHE COMPETENZE
COMPORTAMENTALI
COMPETENZE CONTESTUALI
Successo del Project
Management
Leadership Orientamento al Progetto
Parti Interessate Coinvolgimento e
Motivazione
Orientamento al Programma Progetti
Requisiti ed Obiettivi del
Progetto
Autocontrollo Orientamento al Portafoglio Progetti
Rischi ed Opportunità Ascendente Sviluppo del Progetto, Programma,
Portafoglio Progetti
Qualità Approccio Sereno Organizzazione Permanente
Organizzazione di Progetto Apertura Business
Lavoro di Gruppo Creatività Sistemi, Prodotti e Tecnologie
Risoluzione dei Problemi Orientamento ai Risultati Gestione del Personale
Struttura di Progetto Efficienza Salute, Sicurezza ed Ambiente
Scopo e Risultati Consultazione Finanza
Programmazione Temporale e
Fasi del Progetto
Negoziazione Aspetti Legali
Risorse Conflitti e crisi
Costi e Finanza Affidabilità
Approvvigionamenti e Contratti Apprezzamento dei Valori
Varianti Etica
Controllo e Rapporti di Progetto
Informazione e
Documentazione
Comunicazione
Avviamento del Progetto
Chiusura del Progetto
Tabella 8- Elementi di conoscenza dei tre campi di competenza tecnica, comportamentale e contestuale.
53
L’obiettivo del Competence Baseline (ICB) non è quello di fornire specifici metodi e strumenti ma quello di
definire tutte le competenze che il Project Manager dovrebbe possedere per la gestione completa di un
progetto, lasciando a questi il compito di scegliere la metodologia e gli strumenti più appropriati in funzione
della tipologia e delle caratteristiche del progetto.
Gli elementi di competenza proposti dall’IPMA sottolineano i due importanti aspetti che vincolano la figura
del Project Manager: le “hard skills”, intese come l’insieme di conoscenze tecniche, di strumenti e
metodologie che permettono al Project Management di svolgere correttamente il lavoro assegnato; le “soft
skills” ovvero l’insieme delle capacità personali-relazionali proprie dell’individuo che hanno a che fare con il
suo comportamento.
Dallo studio del documento emerge quanto complessa sia la figura del Project Manager che, per la natura
del suo un ruolo, è chiamato ad attingere a piene mani a queste abilità, posizionandosi centralmente
nell’organizzazione del progetto e rivestendo una funzione di guida, di risolutore di problemi, di smistatore
di informazioni, di decision maker e, non per ultimo, di trainer psicologico e motivatore per il suo team di
progetto.
3.3.3 Competenze tecniche
Le Competenze Tecniche descrivono le metodologie e gli approcci fondamentali per l’impostazione e per la
gestione dei progetti. Come mostrato nell’Occhio delle Competenze, le competenze tecniche sono il gruppo
più ampio tra tutte le competenze di Project Management.
Complessivamente sono 20 elementi che coprono:
• l’intero progetto, il programma o il portafoglio progetti per soddisfare i requisiti fissati dalle parti
interessate;
• l’organizzazione del lavoro del progetto, del programma o del portafoglio progetti;
• la realizzazione degli obiettivi fissati per il progetto;
• l’avanzamento attraverso tutte le fasi del progetto, gli stadi che attraversa un programma e tutti i
periodi in cui si articola un portafoglio progetti.
Nella Figura 14 sono riportati tutti i 20 elementi appartenenti alle Competenze tecniche, con il dettaglio sui
possibili process step da adottare per applicazioni in progetti reali.
54
Figura 14- Elementi di Competenza Tecnica dell’ICB e process steps (32)
55
3.3.4 Competenze comportamentali
Le Competenze Comportamentali trattano i temi relativi alle capacità personali e di relazione con tutti gli
attori coinvolti nel Progetto. Si articolano in 15 elementi che riguardano:
• il ruolo del Project Manager;
• elementi di competenza relativi ai rapporti del Project Manager all’interno e all’esterno del progetto;
• elementi di competenza più comunemente utilizzati, riferiti all’intero progetto ed alle parti coinvolte;
• gli elementi correlati con l’economia, la società, la cultura, la storia.
Nella Figura 15 sono riportati tutti i 15 elementi appartenenti alle Competenze comportamentali, con il
dettaglio sui possibili process step da adottare per applicazioni in progetti reali.
Figura 15- Elementi di Competenza Comportamentali dell’ICB e process steps (32)
56
3.3.5 Competenze contestuali
Le Competenze Contestuali descrivono gli elementi di competenza relativi al contesto in cui si svolge il
progetto e coprono la competenza del Project Manager nel gestire le relazioni con l’organizzazione
permanente e l’abilità di operare in un’organizzazione orientata ai progetti. Tali competenze sono suddivise
in 11 elementi e sono riconducibili a:
• ruolo del Project Manager all’interno dell’organizzazione permanente della società;
• interrelazioni fra Project Manager ed enti che gestiscono il business della società.
Nella Figura 16 sono riportati tutti gli 11 elementi appartenenti alle Competenze contestuale, con il dettaglio
sui possibili process step da adottare per applicazioni in progetti reali.
Figura 16- Elementi di Competenza Contestuali dell’ICB e process steps (32)
57
3.4 Project in controlled Environment – PRINCE2
PRojects IN Controlled Environments (PRINCE) è un metodo di Project Management, sviluppato nel 1989
dall'agenzia denominata “Central Computer and Telecommunications Agency” (CCTA rinominata OGC Office
of Government Commerce) in seguito alle sostanziali modifiche della precedente metodologia per la gestione
di progetti creata da Simptact Systems Ltd, denominato PROMPTII, utilizzato come standard nel Regno Unito
dall’anno della sua creazione nel 1975.
Il metodo PRINCE fu Inizialmente sviluppato per la gestione di processi in ambito IT per poi essere esteso e
trovare validità, nella nuova edizione denominata PRINCE2 lanciata nel 1996, in ogni tipologia di progetto.
PRINCE2 è diventato sempre più popolare ed è oggi riconosciuto come standard “de facto” per il Project
Management in Regno Unito, Australia e molti Paesi Europei, ovvero in più di 50 Paesi (37).
Dall’anno di pubblicazione, nel 1996, il metodo PRINCE2 ha subito successive modifiche ed implementazioni
nel 2002, 2005 e nel 2009, anno di diffusione dell’ultima versione. Se tra le edizioni del 2002 e 2005 non sono
riscontrabili grandi cambiamenti ma solo un migliore approfondimento di alcune aree, la versione del 2009
è stata rivista, nella forma e nei contenuti, affinchè avesse un approccio più pragmatico e più conciso. A
questo scopo, nell’edizione del 2009 viene ridotto il numero di pagine dalle 456 dell’edizione del 2006 a 325
e viene ridotto anche il numero dei processi, che decresce da 8 a 9, come mostrato in Tabella 9. Un’ulteriore
differenza tra le ultime due edizioni riguarda la terminologia utilizzata: se nel PRINCE2 del 2005 si fa
riferimento ai “Components”, nel 2009 questi vengono rinominati in “Themes” ovvero in “Tematiche”.
Tabella 9- Processi di progetto nelle edizioni di PRINCE2 del 2005 e 2009 (31)
Il metodo PRINCE2 supporta il Project Manager attraverso tre elementi tra di loro integrati ed inseriti
all’interno dell’ambiente del progetto: principi, tematiche e processi. Questi ultimi, rappresentati in Figura
17, saranno presentati nel dettaglio nelle pagine seguenti.
58
Figura 17- La struttura del PRINCE2 (38)
3.4.1 I Principi di PRINCE2
La metodologia PRINCE2 si basa su una serie di principi che, oltre ad essere la base del metodo stesso, sono
essenziali per guidare i Project Managers nel completamento del progetto con successo. I principi sono
contraddistinti dalle seguenti caratteristiche:
• universali: i principi possono essere universalmente applicati, in qualsiasi tipo di progetto, ed
essendo PRINCE2 basato su tali principi, anche il metodo di Project Management può essere ritenuto
universalmente valido e quindi applicabile ad ogni progetto indipendentemente dalla sua scala, dalla
tipologia, dal sistema organizzativo, dal contesto geografico o culturale;
• utilizzati nella pratica: questi principi sono stati utilizzati per molti anni nella gestione dei progetti e,
per questo, sono oggi considerati best practices in Project Management e applicabili direttamente ai
progetti senza che il Project Manager reinventi un metodo specifico;
• autorizzati dal team: i principi sono stati accettati dai team di progetto che hanno potuto attraverso
di questi gestire i propri progetti.
I principi su cui si basa il metodo PRINCE2 sono fortemente correlati alle lezioni apprese da progetti
precedenti, indipendentemente dal loro esito finale, positivo o negativo. I principi forniscono la base del
metodo PRINCE2 che può essere impiegato solo nei progetti che aderiscono ai principi stessi.
59
I 7 principi previsti nel metodo PRINCE2 sono:
• giustificazione commerciale continua: per ogni progetto deve sussistere un motivo giustificato per
il suo avvio, che resti valido per tutta la durata del progetto; la giustificazione commerciale deve
essere documentata attraverso il Business Case, in modo che il progetto ed il suo avanzamento siano
sempre allineati con il prodotto che si desidera ottenere e quindi con la realizzazione degli obiettivi
e dei benefici previsti;
• apprendimento dall’esperienza: l’apprendimento dall’esperienza influenza il metodo in fase di
avvio, poichè in questa fase è molto importante trarre lezioni utili da progetti già conclusi, in fase di
svolgimento del progetto, essendo le lezioni apprese utili per migliorare sia i progetti futuri sia le fasi
successive, e in fase di chiusura del progetto, poichè la raccolta di tutte le lezioni apprese a
conclusione di progetto è fondamentale per la loro applicazione in progetti successivi;
• ruoli e responsabilità predefiniti: il team di progetto deve avere una struttura predefinita, in cui
siano ben chiari ruoli e responsabilità all’interno del progetto, concordati dalla stessa organizzazione
in modo che trovino risposta gli interessi di azienda, utente finale e fornitori coinvolti;
• gestione per fasi: il metodo prevede la pianificazione, il monitoraggio ed il controllo fase per fase, la
creazione di un Piano di progetto, che fornisca informazioni sullo status del progetto nell’ottica di
lungo periodo, e di un Piano di Fase dettagliato relativo alla fase in corso, che invece permette il
controllo del progetto sul breve periodo;
• gestione per eccezione: dopo aver stabilito nel progetto le tolleranze riguardo a tempi, costi, qualità,
ambito, rischi e benefici, viene creato un sistema di controllo affinchè, nel caso si superi il limite di
tolleranza stabilito, si possa scalare il problema all’attenzione del livello di management successivo
in modo da decidere come procedere;
• focalizzazione sui prodotti: la caratteristica di questa metodologia è che ci si focalizza sui prodotti,
vale a dire sui risultati che ci si propone di raggiungere con il progetto, e non sulle attività, che
vengono quindi stabilite in un secondo momento, quando tutti i dettagli dei prodotti che si andranno
a realizzare saranno chiari a tutti gli stakeholders;
• adattamento all’ambiente del progetto specifico: il metodo deve poter essere adattato
all’ambiente di progetto secondo la sua complessità, l’importanza, la capacità, il rischio e
caratteristiche legate all’ambiente e alle sue peculiarità geografiche e culturali.
60
3.4.2 Le Tematiche di PRINCE2
Le tematiche sono aspetti della gestione dei progetti che devono essere continuamente considerate durante
la sua esecuzione; sono attività compiute all’inizio del progetto che bisogna continuamente aggiornate.
Le 7 tematiche previste nel metodo PRINCE2 sono:
• progresso: l’analisi del progresso, alla base di ogni decisione del team di progetto, tratta la verifica
dell’avanzamento di progetto rispetto al piano, la verifica di fattibilità di quanto si pensa di eseguire
e il controllo di eventuali deviazioni non pianificate rispetto ai requisiti e agli obiettivi iniziali di tempi,
costi e qualità;
• rischi: il rischio è un evento che, verificandosi, ha un impatto positivo (opportunità) o negativo
(minaccia) sugli obiettivi del progetto e, proprio per questo, è necessario applicare delle procedure
di individuazione, valutazione dei rischi e controllo dei fattori di incertezza, per migliorare le
possibilità di successo del progetto;
• cambiamenti: poichè i cambiamenti hanno molto spesso un impatto diretto sul piano di progetto
originale (in termini di qualità, tempi e costi), è fondamentale che vengano apportunamente gestiti
attraverso l’identificazione, la valutazione e il controllo;
• piani: la pianificazione, che supporta il Project Manager nello sviluppo dei piani di consegna, in
termini di deliverable intermedi e di prodotto finale, prevede la formulazione di un piano che descrive
approfonditamente come, quando e da chi un insieme di obiettivi (in termini di tempistiche, costi,
qualità, benefici attesi) verrà raggiunto;
• qualità: essendo il metodo PRINCE2 orientato al prodotto, è necessario stabilire e definire subito il
livello di qualità atteso per ciascun prodotto e quali standard saranno applicati per il raggiungimento
dei livelli di qualità durante il corso del progetto stesso;
• organizzazione: essendo il progetto un’organizzazione temporanea, la definizione di una struttura
organizzativa che comprenda ruoli e responsabilità è fondamentale per la buona riuscita di un
progetto, così come è importante che l’organizzazione sia riconosciuta dai vari membri del team;
• Business Case: il documento del Business Case è fondamentale in tutte le fasi del progetto perché,
raccogliendo l’idea che sta alla base del prodotto, le ragioni strategiche e commerciali, i rischi e i
benefici che comporta, fornisce informazioni necessarie a tutti gli stakeholders per prendere
decisioni rilevanti durante tutto lo sviluppo del progetto.
61
3.4.3 I Processi di PRINCE2
Un processo è una sequenza strutturata di attività necessarie per il raggiungimento di un obiettivo ben
definito; tutte le attività necessarie per completare un progetto sono quindi raggruppate in processi specifici.
Come mostrato in Figura 18, PRINCE2 prevede 7 processi che guidano il Project Management team, ciascuno
dei quali fornisce un determinato numero di attività che a loro volta comprendono un set di azioni
raccomandate, pensate per il raggiungimento di specifici risultati.
Figura 18- Relazione tra processi, attività e azioni raccomandate (37)
Di seguito saranno analizzati i 7 processi proposti dal metodo PRINCE2, descrivendone brevemente le
attività correlate:
• Avvio di un progetto (SU - Starting Up a Project);
• Direzione di un progetto (DP - Directing a Project);
• Inizio di un progetto (IP - Initiating a Project);
• Controllo di una fase (CS - Controlling a Stage);
• Gestione della consegna del prodotto (MP - Managing Product Delivery);
• Gestione dei limiti di fase (SB - Managing a Stage Boundary);
• Chiusura di un progetto (CP- Closing a Project).
3.4.3.1 Avvio di un progetto (SU) – Starting Up a Project
Il processo di avvio, noto come processo di Pre-Progetto, è il primo a dove essere eseguito all’interno di un
progetto; durante il processo vengono stabilite le ragioni per le quali eseguire il progetto, si definiscono le
responsabilità all’interno del team di progetto e si pongono le basi per la fase di pianificazione, definita da
PRINCE2 come Fase di Inizio.
62
Il processo di avvio di un progetto è costituito dalle seguenti attività:
• scelta del Project Manager e del Comitato di Progetto: per assicurare l’esito positivo del progetto
viene nominato l’Executive (presidente del Comitato di Progetto), che rappresenta gli interessi di
tutti gli stakeholders, e il Project Manager, che gestisce il progetto nel suo sviluppo per conto
dell’Executive;
• acquisizione lezioni passate: analisi e raccolta, anche attraverso workshop e incontri diretti, di tutte
le lezioni apprese in altri progetti, riguardanti punti di forza e debolezza dei progetti, procedure,
tecniche e strumenti usati, distribuzione di ruoli e responsabilità;
• progetto e nomina del team di Project Management: la composizione del team di progetto è
fondamentale per la sua realizzazione e deve riflettere gli interessi di tutte le parti coinvolte, inclusi
gli investitori, gli utilizzatori e i fornitori. È essenziale che tutti i membri del team di progetto
conoscano il modo in cui sono state suddivide le responsabilità e la linea di comunicazione;
• Preparazione del profilo del Business Case: il Business Case si focalizza sulle ragioni che portano alla
realizzazione del progetto, piuttosto che sul prodotto e sulle modalità con cui sarà prodotto;
• Definizione dell’approccio al progetto: prima di procedere alla pianificazione di come il prodotto
debba essere realizzato, è necessario stabilire l’approccio al progetto all’interno del documento del
Project Brief;
• Pianificazione della Fase di Inizio: viene sviluppato il piano della fase iniziale del progetto, in modo
che sia mirato e strutturato.
3.4.3.2 Direzione di un progetto (DP) – Directing a Project
Il processo di direzione di un progetto è di responsabilità del Comitato di Progetto (Project Board). Attraverso
il principio di “gestione per eccezione”, questo processo indica i passi che devono essere seguiti dal Comitato
di Progetto, nel corso del progetto stesso, ovvero dalla fase di pre-progetto alla chiusura.
Il processo di direzione di un progetto è costituito dalle seguenti attività:
• autorizzare l’inizio: il Comitato di Progetto verifica, approva la richiesta per l’inizio della
progettazione proveniente dalla fase di avvio;
• autorizzare il progetto: il Comitato di Progetto autorizza l’esecuzione del progetto;
• autorizzare una fase o un Piano per le Eccezioni: il Comitato di Progetto autorizza ogni fase ed ogni
piano per le eccezioni;
63
• fornire indicazioni ad hoc: i membri del Comitato di progetto possono offire, anche singolarmente,
un supporto informale o rispondere a delle specifiche richieste durante tutto lo sviluppo del
progetto;
• autorizzare la chiusura del progetto: l’autorizzazione della chiusura del progetto è l’ultima attività
svolta dal Project Board, che controlla che gli obiettivi del progetto siano stati raggiunti, verifica che
non ci siano state perdite economiche, avvisa l’alta dirigenza della chiusura del progetto, propone un
piano di controllo per verificare il raggiungimento dei benefici attesi dal progetto.
3.4.3.3 Inizio di un progetto (IP) - Initiating a Project
Il processo dell’inizio di un progetto ha l’obiettivo di definire i requisiti che il prodotto finale deve possedere,
il livello di qualità richiesta, le tempistiche ed i costi di realizzazione, i possibili rischi e la quantità di risorse
umane e materiali da impiegare.
Questo processo raccoglie le informazioni necessarie a giustificare l’inizio vero e proprio del progetto,
stabilisce una valida base di gestione del progetto stesso e ne crea un piano dettagliato. Durante questo
processo viene redatto il Documento di Inizio del Progetto (Project Initiation Document), ovvero la linea base
rispetto alla quale misurarne il grado di avanzamento e il successo del progetto stesso.
Il processo di inizio di un progetto è costituito dalle seguenti attività:
• definizione strategia per la gestione dei rischi: la strategia di Risk Management prevede la
definizione dei suoi obiettivi, di procedure, strumenti e tecniche che saranno adottate, dei ruoli e
delle responsabilità, delle tolleranze dei rischi e dei requisiti della documentazione;
• definizione strategia per la gestione della configurazione: la strategia di Configuration Management
ha lo scopo di permettere la gestione ed il controllo degli oggetti (documentali e non) di sistemi
complessi; il livello di controllo del progetto, e quindi il livello e il grado di scomposizione dello stesso,
varierà a seconda della tipologia di progetto;
• definizione strategia per la gestione della qualità: lo sviluppo e l’adozione di una strategia di Quality
Management garantisce che siano rispettati le richieste di qualità del prodotto da parte degli
stakeholders;
• definizione strategia per la gestione delle comunicazioni: la strategia di gestione della
comunicazione, interna ed esterna al team di progetto, deve contenere informazioni su come il team
è tenuto ad inviare informazioni e sulle modalità con cui verranno inviate loro comunicazioni;
64
• strutturazione dei controlli del progetto: vengono stabiliti i punti e i livelli di controllo che il Project
Manager richiede al lavoro svolto dal Team Manager, in funzione della scala, dei rischi, della
complessità e dell’importanza del progetto stesso;
• creazione del Business Plan: è fondamentale la redazione di un Business Plan che identifichi lo
sviluppo temporale del progetto e le risorse richieste per realizzarlo;
• rifinitura del Business Case: il Business Case redatto durante il processo di avvio deve essere
opportunamento aggiornato, in modo da considerare i dati di tempi e costi stimati nel Business Plan;
• preparazione della documentazione di inizio progetto: documenti che raccolgono tutte le
informazioni e i documenti sviluppati durante la fase di inizio e utilizzati per ottenere l’autorizzazione
a proseguire il progetto.
3.4.3.4 Controllo di una fase (CS) - Controlling a Stage
Il processo di controllo di una fase è quello a cui un Project Manager riserva generalmente più energie. Il
Project Manager ha infatti il compito di definire e assegnare il lavoro che deve essere svolto, supervisionare
il lavoro del team, gestire cambi ed imprevisti, informare il Comitato di Progetto del progresso del progetto,
aggiornare e comunicare costantemente con tutti gli stakeholders, intraprendere opportune azioni
correttive.
Il processo di controllo di un progetto è costituito dalle seguenti attività:
• autorizzare un pacchetto di lavoro (Work Package): seppur sia importante lasciare autonomia al
team di progetto, è necessario che le attività inizino e si sviluppino con il consenso del Project
Manager che ha quindi il compito di assegnare il lavoro da svolgere ad un team o ad un singolo, in
funzione del Piano di Fase (Stage Plan);
• revisionare lo stato di un pacchetto di lavoro: si raccolgono le informazioni sullo stato di
avanzamento delle attività (avanzamento fisico delle attività, quantità di risorse impegnate e indice
di qualità) con la frequenza definita all’interno del Piano di Fase per la specifica attività;
• ricevere un pacchetto di lavoro completato: si registrano il completamento e la consegna di un
Pacchetto di Lavoro (WP – Work Package) completato;
• revisionare lo stato della fase: l’obiettivo di questa attività è quello di mantenere un’accurata visione
del reale avanzamento del progetto attraverso il confronto ed il controllo tra ciò che si era
preventivato per il progetto (in termini di costi, tempi e quantità), ciò che sta subendo realmente il
progetto e ciò che potrebbe succedere (problemi e rischi);
65
• produrre il report delle eccezioni (Highlight Report): il Project Manager deve realizzare un
documento che riassuma lo stato delle fasi e del progetto e renderlo disponibile a tutti gli
stakeholders;
• registrare ed esaminare problemi e rischi: si identifica, registra e classifica ogni nuova problematica
ed ogni nuovo rischio che interessa il progetto durante il suo sviluppo;
• stabilire la priorità di problemi e rischi: stabilita la priorità di problemi e rischi all’interno del
progetto, in funzione della loro probabilità di accadimento e del possibile effetto sul progetto, il
Project Manager deve informare il Comitato di Progetto del comportamento che ci si aspetta dal
progetto durante il suo sviluppo;
• intraprendere azioni correttive: all’interno delle tolleranze (in termini di tempo, costi e qualità)
assegnate dal Comitato di Progetto, il Project Manager intraprende le opportune azioni correttive
per far fronte a problemi e rischi all’interno del progetto.
3.4.3.5 Gestione della consegna del prodotto (MP) - Managing Product Delivery
Il processo di gestione della consegna del prodotto offre un meccanismo controllato che fa sì che il Project
Manager e gli specialisti coinvolti nel processo possano concordare i dettagli del lavoro richiesto. Il lavoro
concordato tra il Project Manager e il Team Manager, incluse le date definite come obiettivo, i requisiti di
qualità e di rapporto, è chiamato Pacchetto di Lavoro. Durante il processo di gestione della consegna del
prodotto, i team di specialisti, responsabili dell’esecuzione dei pacchetti di lavoro e rappresentati dai
rispettivi Team Manager, si rapportano con il Project Manager rispetto al lavoro che si è previsto di eseguire,
comunicandone lo stato di avanzamento.
Il processo di gestione della consegna del prodotto è costituito dalle seguenti attività:
• accettare un pacchetto di Lavoro: prima che un pacchetto di lavoro sia assegnato al team di
specialisti, è necessario che ci sia un accordo tra Project Manager e Team Manager riguardo a cosa
deve essere consegnato, ai requisiti del prodotto, alle procedure da utilizzare;
• eseguire un Pacchetto di Lavoro: gestisce lo sviluppo, la fornitura dei prodotti e dei servizi relativi a
un pacchetto di lavoro, in modo che vengano rispettati i requisiti tecnici, i processi e le procedure
stabilite inizialmente per il pacchetto di lavoro;
• consegnare un pacchetto di Lavoro: una volta completato un pacchetto di lavoro, il suo
completamento deve essere notificato al Project Manager.
66
3.4.3.6 Gestione dei limiti di fase (SB) - Managing a Stage Boundary
Il processo di Gestione dei Limiti di Fase ha due obiettivi principali: il primo consiste nel rilievo delle
prestazioni della fase che sta per chiudersi, il secondo è la pianificazione della fase successiva. Questo
processo, dunque, consente al Comitato di Progetto di verificare le performance della fase completata
rispetto a quanto pianificato e, in funzione del risultato, di approvare o meno il passaggio alla fase successiva.
I documenti che il Project Manager formula e indirizza al Comitato di Progetto sono il Rapporto di Fine Fase
ed il Piano della Fase Successiva.
Il processo di gestione dei limiti di fase è costituito dalle seguenti attività:
• pianificare una nuova fase: preparazione di un piano per lo svolgimento della nuova fase,
considerando le attività prodotte in prossimità della fine dell’attività in corso o in via di conclusione;
• aggiornare il Piano di Progetto: aggiornamento del piano di progetto con riferimento sia all’attuale
progresso, in termini di costi e tempi, della fase che si sta per concludere, sia alla durata e ai costi
presunti per l’attività che sta per iniziare;
• aggiornare il Business Case: al verificarsi di eventi che hanno un impatto sul Business Case, si
provvede al suo aggiornamento e conseguente verifica di validità;
• produrre il Rapporto di Fine Fase: a ridosso della fine della fase, il Project Manager ha il compito di
redarre un rapporto sui risultati della fase in via di conclusione, in modo da restituire una visione
chiara sul progresso della fase stessa;
• produrre il Piano delle Eccezioni: il Comitato di Progetto può richiedere al Project Manager, in
risposta al Rapporto delle Eccezioni ed a seguito dell’eccezione presentatasi, un Piano delle Eccezioni.
3.4.3.7 Chiusura di un progetto (CP) - Closing a Project
Il processo di Chiusura di un Progetto comprende tutte le attività necessarie per la chiusura ufficiale del
progetto. Il Project Manager, dopo aver redatto tutta la documentazione necessaria tra cui il Rapporto di
Fine Progetto e il Rapporto delle Lezioni Appresa, richiede al Comitato di Progetto di poter chiudere il
progetto, sia nel caso della sua naturale fine sia nel caso in cui si sia resa necessaria una chiusura prematura.
Il processo di chiusura di un progetto è costituito dalle seguenti attività:
• preparare la chiusura pianificata: nel caso in cui la fine del progetto sia naturale e programmata, il
Project Manager ha il compito di verificare, prima della chiusura ufficiale del progetto, che tutti i
risultati attesi dal progetto, in termini di tempi, costi e qualità, siano stati raggiunti con successo;
67
• preparare la chiusura anticipata: nei casi in cui il Comitato di Progetto ordini al Project Manager la
chiusura anticipata del progetto, questo deve assicurarsi che il lavoro in via di sviluppo non venga
abbandonato ma che si recuperino i prodotti completi o in via di completamento che possano essere
utilizzati per lo sviluppo di altri progetti;
• consegnare i prodotti: prima della chiusura del progetto, è necessario che i prodotti del progetto
passino ad un ambiente operativo e di manutenzione e che siano consegnati al consumatore;
• valutare il progetto: poichè le organizzazioni di successo sono quelle che imparano dalle proprie
esperienze precedenti, risulta fondamentale valutare i risultati del progetto rispetto agli obiettivi,
sviluppare statistiche sulle prestazioni del progetto e registrare le lezioni apprese nel corso del
progetto, affinchè siano la base per successivi progetti;
• raccomandare la chiusura del progetto: dopo aver ricevuto conferma da parte del Project Manager
della possibilità di chiudere il progetto, una raccomandazione di chiusura ufficiale del progetto deve
essere prodotta dal Comitato di Progetto.
3.4.4 Il ciclo di vita di un progetto
Il Comitato di Progetto stabilisce la direzione da intraprendere e prende decisioni chiave durante tutto il ciclo
di vita del progetto. Il metodo PRINCE2 individua sette processi, già descritti in precedenza, ognuno correllato
ad un insieme di attività necessarie per dirigere (directing), gestire (managing) e portare a termine
(delivering) un progetto con successo. La Figura 19 mostra come ogni processo sia usato durante il ciclo di
vita del progetto.
Figura 19- I processi di PRINCE2 nel ciclo di vita del progetto
Di seguito una panoramica veloce sul ciclo di vita di un progetto, che tratta l’interazione dei vari processi
attraverso le varie fasi di gestione fino alla fine del progetto stesso.
68
3.4.4.1 Fase Pre-Progetto
Il periodo temporale che precede l’inizio vero e proprio di un progetto, noto come fase Pre-Progetto è
caratterizzato dalla nascita di idee ed esigenze che possono essere il risultato di nuovi obiettivi aziendali,
delle pressioni di un mercato sempre più competitivo o di modifiche legislative. Le idee e i fabbisogni che
scaturiscono da questi fattori sono gli inneschi che porteranno alla nascita e allo sviluppo del progetto. Il
primo passo solitamente intrapreso è la creazione di un documento di “Mandato di Progetto”, che può essere
un documento formale o informale.
Durante la fase di Pre-Progetto, è necessario completare un preciso elenco di attività, tutte incluse nel
processo di Avvio di un Progetto (Starting Up a Project – SU), descritto precedentemente. Lo scopo principale
del processo di Avvio di un Progetto è quello di verificare la validità del progetto, evitando che progetti poco
utili e fattibili siano iniziati. L’esecuzione di tutte le attività del processo di Avvio di un Progetto si conclude
con la produzione del Project Brief e del Piano di Fase per la fase di Inizio del progetto, revisionati dal
Comitato di Progetto che, in base al loro contenuto, decide se autorizzare le fasi successive e, quindi, l’inizio
del progetto.
3.4.4.2 Fase di Inizio
Una volta deciso di dare il via al progetto, si procede con la Fase di Inizio che prevede la realizzazione di tutte
le attività che fanno parte del processo di Inizio del Progetto (Initiating a Project – IP). Risulta quindi
necessario procedere con una pianificazione dettagliata del progetto; è necessario ottenere i finanziamenti
per iniziare il progetto ed eseguire controlli accurati per garantire che si trovi risposta alle richieste degli
investitori e di chi contribuisce economicamente al progetto. Si dovrà procedere alla creazione di un Business
Case completo e dettagliato e di un Piano di Controllo dei Benefici che descriverà come e chi verificherà
l’effettivo raggiungimento dei benefici previsti.
Inoltre, durante la fase di Inizio, si eseguiranno le attività appartenenti al processo di Gestione dei limiti di
fase (Managing a Stage Boundary – SB) per pianificare nel dettaglio la fase successiva.
La fase di Inizio si conclude con la produzione della Documentazione di Inizio di Progetto (PID), che sarà
revisionata dal Comitato di Progetto il quale deciderà se autorizzare o meno il progetto. La Documentazione
di Inizio di Progetto funge da linea guida rispetto alla quale si definiranno avanzamento e performance del
progetto.
69
3.4.4.3 Fasi successive alla fase di inizio
Il Project Manager, delegato dal Comitato di Progetto, ha la responsabilità quotidiana per la gestione del
progetto, fase per fase. Le attività che il Project Manager svolge durante il suo lavoro sono numerose e di
varia natura e sono tutte riconducibile al processo di Controllo di una Fase (Controlling a Stage – CS); in
particolare il Project Manager:
• assegna ai Team Manager il lavoro da eseguire;
• verifica che tutti i deliverables abbiano superato i controlli o test di qualità e che, quindi, soddisfino
i criteri di accettazione preventivamente fissati;
• verifica l’avanzamento e il progresso della singola fase rispetto al piano originario e che le previsioni
o forecasts ricadano all’interno degli intervalli delle tolleranze di fase e progetto, preventivamente
definiti.
Durante il Processo di Gestione della Consegna del Prodotto (Managing Product Delivery – MP), i Team
Managers o membri del gruppo di lavoro sviluppano Pacchetti di Lavoro (Work Packages) e aggiornano
regolarmente il Project Manager del progresso del progetto attraverso un Report di Verifica o di Checkpoint.
Durante il Processo di Gestione dei Limiti di Fase (Managing a Stage Boundary – SB), in prossimità della
conclusione di ogni fase, il Project Manager richiede le informazioni necessarie per pianificare il passaggio
alla fase successiva e dovrà formulare ed indirizzare al Comitato di Progetto il Business Case aggiornato, il
Report di Fine Fase e il Piano della Fase Successiva. Il Comitato di Progetto utilizza le informazioni e la
documentazione presentata dal Project Manager per valutare se approvare o meno il passaggio alla fase
successiva.
3.4.4.4 Fase di consegna finale
Vista la natura temporanea del progetto, durante la fase finale, dopo l’approvazione al Project Manager di
tutti i prodotti del progetto, si passa allo smantellamento del progetto e alla sua consegna. Il compito del
Comitato di Progetto è quello di verificare che chi riceverà i prodotti sia messo in condizione di poterli
utilizzare e gestire e che l’utente finale sia opportunamente supportato dopo la chiusura del progetto stesso.
Il processo di Chiusura di un Progetto (Closing a Project – CP) viene eseguito sempre nell’ultima parte
dell’ultima fase del ciclo di vita del progetto e comprende una serie di attività da seguire, tra cui:
• valutare il progetto, comparandolo rispetto al piano originale;
• scrivere il Rapporto di Fine Progetto e il Report delle Lezioni Apprese;
• pianificare il controllo dei benefici post-progetto.
70
3.5 Gli Standard del Project Management
Le norme tecniche o standard sono documenti, contenenti specifiche tecniche o linee guida, redatte da
appositi enti di standardizzazione grazie al contributo di professionisti di tutto il mondo e approvate da un
organismo regionale, nazionale, sovranazionale o internazionale di normazione riconosciuto. Le norme
tecniche non hanno caratteristiche di obbligatorietà; spesso vengono considerate come riferimento da
ordinamenti legislativi e amministrativi diventando vincolanti ma solitamente tendono ad autoaffermarsi, sia
per l’autorità dell’istituto normativo che le emana sia perché di particolare interesse nel mercato.
Gli standard in ambito di Project Management sono riconosciuti dai diversi enti impegnati in questo campo
al fine di promuovere una gestione ottimale di progetti, programmi e portafogli di progetti, attraverso
pratiche condivise ed applicate in modo coerente. Gli standard garantiscono che i progetti vengano sviluppati
e portati a termine rispettando dei requisiti minimi posti dal mercato e stabiliscono criteri sulla qualità dei
prodotti del progetto, sul processo, sulla gestione delle risorse e su molteplici altri aspetti.
Di seguito verranno approfonditi i principali standard, applicabili ai modelli di Project Management per
garantire la qualità del prodotto realizzato. Le norme tecniche presentate sono state sviluppate
dall’Organizzazione Internazionale per la Normazione (ISO - International Organization for Standardization),
la più importante organizzazione che si occupa di definire, su scala mondiale, le norme tecniche relative a
processi in ambito aziendale. Fondata nel 1947 a Ginevra, oggi l’ISO conta organismi nazionali membri in 163
Paesi del mondo (23). In Italia, l'organismo che armonizza e diffonde le norme ISO è l'UNI, l'Ente Nazionale
Italiano di Unificazione, che si occupa anche di partecipare all’attività normativa ISO internazionale.
3.5.1 ISO 10006:2003 –Linee guida per la gestione della qualità di progetti
La norma ISO 10006 è entrata in vigore nella sua prima edizione nel 1997, per poi essere revisionata e
pubblicata nel Giugno 2003. La versione italiana UNI ISO 10006, in vigore da Gennaio 2005, ha il nome di
“Sistemi di gestione per la qualità - Linee guida per la gestione della qualità nei progetti”.
La norma ISO 10006:2003 è attualmente l’unica norma vigente della famiglia di norme ISO 9000 che parli
esplicitamente del Project Management. Lo scopo dichiarato della norma è quello di fornire una guida
relativa all’applicazione della gestione per la qualità nei progetti, indipendentemente dalla loro dimensione,
complessità, durata e obiettivi. Lo standard ISO 10006 può quindi essere applicato a progetti di lunghezza,
grandezza e complessità variabile per raggiungere alti livelli di qualità nei processi, gestendo i bisogni di tutti
gli stakeholders del progetto e incorporando le policy di qualità organizzative nella gestione del progetto (39).
71
Nel definire il proprio campo d’applicazione, la norma ISO 10006 specifica che essa “non costituisce da sola
una guida per la gestione del progetto” (40), ma fornisce consigli per la qualità nei processi di gestione del
progetto; in tal senso la norma ha un carattere di guida e non può essere utilizzata per scopi di certificazione.
La norma ISO 10006:2003 si basa sul “Modello di sistema di gestione per la qualità basato sui processi”
descritto nella norma UNI ISO 9000:2005 e si articola secondo il seguente indice:
• introduzione alla normativa e definizioni della terminologia utilizzata;
• sistemi di gestione per la qualità nei progetti;
• responsabilità della direzione;
• gestione delle risorse;
• realizzazione del prodotto;
• misurazione, analisi e miglioramento.
Nel quarto capitolo, relativo ai “sistemi di gestione per la qualità nei progetti”, lo standard fornisce le
indicazioni per la gestione della qualità nei progetti stessi sulla base di otto Principi di Gestione, descritti nella
norma UNI ISO 9000:2005.
La pianificazione della creazione, implementazione e manutenzione di un sistema di gestione della qualità
basato sull’applicazione degli otto Principi di Gestione, può essere definito come un processo strategico. Nel
capitolo relativo alla “responsabilità della direzione” viene descritto come applicare praticamente gli otto
Principi di Gestione sulla pianificazione eseguita nei processi strategici:
• focus sul cliente: il successo del progetto dipende fortemente da quanto le aspettative e le richieste
dei clienti vengano soddisfatte e, a tal fine, le organizzazioni hanno il compito di analizzare e
comprendere a pieno i requisiti dei clienti e i loro bisogno attuali e futuri;
• leadership: tra i compiti del Project Manager all’interno dell’organizzazione vi è quello di mantenere
la coesione del gruppo di lavoro, indirizzando gli sforzi dei componenti verso l’obiettivo comune;
• coinvolgimento delle persone: poiché le persone che partecipano alla realizzazione di un progetto
utilizzano le loro abilità per portare benefici all’azienda, è necessario motivarle e stimolarle oltre che
fornire loro strumenti, tecniche e metodi per permettere il monitoraggio ed il controllo dei processi;
• approccio al processo: i risultati desiderati vengono raggiunti con maggiore efficienza se le attività e
le risorse necessarie per realizzarle sono gestite attraverso dei processi, che possono essere nuoiv
oppure già stati testati in progetti precedenti;
• approccio sistematico alla gestione: identificare, gestire e monitorare in modo sistematico le
interdipendenze tra i processi contribuisce al raggiungimento degli obiettivi attesi;
72
• miglioramento continuo: qualunque siano gli obiettivi di un progetto, l’organizzazione ed i team di
progetto hanno il compito di ricercare continuamente il modo di migliorare l’efficacia e l’efficienza
dei processi dei quali sono responsabili, anche documentando opportunamente le informazioni
ottenute durante il progetto in modo che possano essere utilizzate in progetti successivi;
• approccio al decision making: le decisioni efficaci si basano sull’analisi di dati ed informazioni,
riguardanti, ad esempio, il successo e le prestazioni del progetto;
• benefici reciproci tra fornitori: l’organizzazione e i suoi fornitori sono interdipendenti e, per questo,
dovrebbero concorrere a obiettivi comuni e condividere i rischi del progetto.
Nei capitoli successivi al quarto, sono presentati e descritti i processi del progetto, necessari alla gestione del
progetto e alla realizzazione dei prodotti del progetto stesso. Di seguito saranno presentati gli undici Gruppi
di Processi, che raccolgono tutti i processi di progetto:
• processi strategici: insieme di processi che stabiliscono gli orientamenti generali del progetto quali:
l’applicazione dei principi di gestione per la qualità, l’orientamento al cliente, il coinvolgimento del
personale, il miglioramento continuo e i rapporti di beneficio con i fornitori;
• processi legati alle risorse: insieme di processi che riguardano gli aspetti quantitativi delle risorse
necessarie e la loro pianificazione temporale, i vincoli fisici, legali e amministrativi esistenti tra loro
e, infine, l’attenzione dinamica all’utilizzo delle risorse nel tempo;
• processi legati alle risorse umane: insieme di processi che riguardando la gestione e lo sviluppo del
gruppo di lavoro, affinché questo sia sempre composto da persone motivate e capaci di dare un
contributo effettivo ed efficace al progetto;
• processi di interdipendenza: il gruppo di processi di interdipendenza, basato sul presupposto che le
azioni in un’area particolare di un progetto influenzino le altre, comprende la gestione del
cambiamento, la gestione della chiusura e dell’inizio dei progetti;
• processi relativi allo scopo: il gruppo di processi relativi allo scopo si focalizza sulle esigenze ed
aspettative degli stakeholders e si propone di definire l’obiettivo e i requisiti del progetto;
• processi relativi al tempo: i processi legati al tempo hanno l’obiettivo di determinare la durata delle
attività del progetto, pianificare e controllare le dipendenze tra le stesse;
• processi relativi al costo: processi finalizzati alla previsione, gestione e controllo dei costi, attraverso
sistemi di pianificazione delle spese, per garantire il completamento del progetto nel rispetto del
budget;
• processi relativi alla comunicazione: il gruppo di processo relativo alla comunicazione è costituito da
processi volti a controllare la comunicazione esterna all’organizzazione, definire gli opportuni flussi
informativi e assicurare idonea privacy alla gestione delle informazioni;
73
• processi relativi alla gestione dei rischi: i processi legati alla gestione dei rischi, che descrivono le
incertezze del progetto che possono influenzare positivamente (opportunità) o negativamente
(minacce) i processi e il risultato finale, hanno l’obiettivo di ridurre i possibili eventi negativi e
massimizzare le opportunità di miglioramento;
• processi relativi agli acquisti: i processi relativi agli acquisti appartenenti a questo gruppo riguardano
il controllo del contratto, la valutazione dei fornitori e la gestione dei requisiti;
• processi legati al miglioramento: i processi legati al miglioramento riguardano l’analisi dei dati
raccolti da progetti precedenti e l’applicazione di azioni o metodi correttivi o preventivi con
l’obiettivo di migliorare in maniera continua sia i progetti in via di sviluppo che quelli futuri.
La norma tecnica ISO 10006:2003 definisce ed analizza i processi e i principi da applicare per completare un
progetto con successo; funge inoltre da guida per le organizzazioni nella fase di chiusura dei progetti, in
particolare per la valutazione del progetto stesso al fine di migliorare progetti successivi.
3.5.2 ISO 21500:2012 – Guida al Project Management
La norma ISO 21500:2012 "Guidance on Project Management” è l’ultimo standard elaborato
dall’International Organization for Standardization (ISO) in materia di Project Management e gestione di
progetto; l'edizione italiana della norma è stata pubblicata per la prima volta il 9 maggio 2013 e prende il
nome di “Guida al Project Management”.
Le principali ragioni che hanno mosso l’International Standards Organization (ISO) a elaborare questo nuovo
standard sono da ricercarsi nella proliferazione di diversi standard in tutto il mondo, caratterizzati da
vocabolari e processi non comuni che impediscono il loro utilizzo come riferimento unico per la comunità
globale di Project Management. L’obiettivo principale della norma tecnica è quello di fornire una piattaforma
comune che possa essere un punto di riferimento per tutti i professionisti di Project Management, facilitare
il trasferimento delle conoscenze e armonizzare i principi, il vocabolario e i processi negli standard esistenti
e futuri (30).
La norma ISO 21500:2012 è uno standard che integra i punti di forza di altri standard sviluppati in materia di
Project Management, tra cui l’ICB formulato dall’IPMA, del quale riprende il concetto delle competenze del
Project Manager, e il PMBOK proposto dal PMI, del quale riprende molti concetti, seppur con delle leggere
modifiche. Nella Figura 20 si riporta lo schema della struttura completa della ISO 21500:2012.
74
Figura 20- Struttura della ISO 21500:2012 (32)
75
La norma ISO 21500:2012, come il PMBOK, suddivide il ciclo di vita del progetto in cinque Gruppi di Processi
(Process Groups), denominati in modo diverso rispetto a quanto proposto nel PMBOK. I cinque gruppi di
processo descritti nella ISO 21500:2012 sono:
• inizio: processi finalizzati a iniziare una fase o un progetto, definire gli obiettivi di una fase o di un
progetto ed autorizzare il Project Management a procedere con i lavori;
• pianificazione: processi finalizzati allo sviluppo di un piano dettagliato che funga da linea guida
rispetto alla quale misurare e gestire l’avanzamento e le performance del progetto;
• implementazione: processi utilizzati per portare a termine le attività di Project Management e
supportare la realizzazione dei deliverables del progetto in accordo con il piano;
• controllo: processi finalizzati a monitorare, misurare e controllare le performance del progetto
rispetto al piano e, quindi, ad intraprendere le opportune azioni correttive per raggiungere gli
obiettivi prefissati;
• chiusura: processi utilizzati per stabilire formalmente la fine di un progetto o di una fase e per
trasmettere le lezioni apprese durante il progetto per migliorare quelli futuri.
Le Aree di Conoscenza dell’ultima edizione del PMBOK corrispondono, nel numero e nel nome, ai Gruppi
Tematici (Subject Groups) della norma ISO 21500:2012, che sono:
• integrazione: processi necessari a identificare, definire, combinare, unificare, controllare e terminare
le varie attività e i processi relativi al progetto;
• stakeholders: processi necessari per identificare e gestire gli investitori, i clienti e gli altri
stakeholders;
• ambito: processi finalizzati all’identificazione e definizione del lavoro e dei deliverables necessari per
il raggiungimento degli obiettivi del progetto;
• risorse: processi necessari per identificare e procurare le risorse necessarie al progetto ovvero le
risorse umane, i servizi, le attrezzature, i materiali, le infrastrutture e gli strumenti;
• tempo: processi finalizzati alla programmazione delle attività di progetto e al monitoraggio del loro
stato di avanzamento nel corso del progetto;
• costi: processi necessari per lo sviluppo del bilancio e per il monitoraggio dei costi rispetto a quanto
preventivato per le singole attività e il progetto;
• rischi: l’area di gestione dei rischi si focalizza sull’identificazione, valutazione, contenimento e
gestione dei rischi.
• qualità: processi richiesti per pianificare, garantire e controllare la qualità;
76
• approvvigionamento: processi richiesti per pianificare e procurare prodotti, servizi, risultati e per
gestire le relazioni tra i fornitori;
• comunicazione: processi richiesti per pianificare, gestire e diffondere informazioni rilevanti per il
progetto all’interno del gruppo di progetto e tra tutti gli stakeholders.
Il numero dei Processi all’interno della norma ISO 21500:2012 è inferiore rispetto a quello dei Processi
presenti all’interno del PMBOK; la norma tecnica propone un totale di 39 Processi rispetto ai 47 presentati
all’interno del PMBOK.
La Tabella 10 riporta tutti i Processi che la norma tecnica propone per ogni Gruppo di Processi e per ogni
Gruppo Tematico.
Tabella 10- Mappa dei Gruppi di Processi di Project Management e dei Gruppi Tematici (41)
Lo scopo primario della norma ISO 21500:2012 è quello di fornire un linguaggio globale e comune per la
pratica della gestione dei progetti. La norma tecnica può essere utilizzata da organizzazioni di varia grandezza
per la realizzazione di qualsiasi tipologia di progetto; il suo intento è quello di offrire una guida ai
professionisti e non di essere usata per scopi di certificazione.
77
3.6 Analisi comparativa tra principali metodologie, metodi e standard
Dopo aver esaminato le principali metodologie e i più importanti metodi e standard in ambito di Project
Management, specificandone la struttura, l’approccio, i punti di forza e di debolezza e le caratteristiche
salienti, in questo paragrafo, sulla base della letteratura esistente e attraverso la lettura diretta dei
documenti, si è eseguito un confronto tra loro, analizzandone similitudi, differenze, caratteristiche positive e
negative.
3.6.1 Confronto tra i documenti
Nel presente paragrafo sarà presentato un dettagliato confronto tra i più importanti documenti in materia di
Project Management. In particolare si confronteranno separatamente: le strutture dei documenti ed i diversi
approcci alla gestione dei processi; le differenze nelle definizioni e nella nomenclatura utilizzate evidenziando
le possibili corrispondenze; le tecniche e gli strumenti eventualmente descritti; le corrispondenze tra i vari
documenti in termini di Gruppi di processo, Aree di Conoscenza, Processi e Competenze del Project Manager.
3.6.1.1 Struttura e approccio
Nel PMBOK il ciclo di vita del progetto è suddiviso in 47 Processi, facenti parte di uno dei 5 Gruppi di Processi
e pertinenti ad una delle 10 Area di Conoscenza. In particolare, il Gruppo di Processo “Monitoraggio e
Controllo” e le Aree di Conoscenza “Gestione dell’integrazione del Progetto” sono trasversali a tutti gli altri
elementi, monitorano l’intero ciclo di vita del progetto e integrano la totalità delle informazioni provenienti
dai livelli inferiori. I processi sono caratterizzati da:
• input e output: possono essere attività, decisioni, prodotti o documenti;
• strumenti e tecniche: metodi, procedure o strumenti utili per concludere un progetto.
Input, output, tecniche e strumenti sono da intendere come flessibili e non obbligatori; possono infatti essere
integrati, parzialmente rimossi o modificati seguendo l’esperienza del Project Manager e le caratteristiche
del progetto. Ne risulta un Project Manager con una maggiore libertà nel prendere le decisioni, essendo lui
l’unico responsabile per l’intera gestione del progetto. La struttura del PMBOK è orientata al prodotto
(product based).
Il PMBOK ha un accurato approccio teorico, che segue uno schema molto preciso, si sviluppa in maniera
molto fluida, chiara e con un buon numero di spiegazioni. L’approccio teorico è ben supportato da diversi
diagrammi, schemi e tabelle, che aiutano nel mostrare gli aspetti più importanti dell’argomento. Essendo un
78
approccio teorico, però, non ci sono riferimenti a reali esperienze, per i quali mancano quasi completamente
esempi e spiegazioni. Il PMBOK è stato tradotto in molte lingue ma conserva un approccio un po’ rigido, non
adattandosi alle realtà nazionali e mantenendo la stessa forma e gli stessi contenuti anche nelle versioni
tradotte.
Nel documento dell’ICB, gli elementi di competenza del Project Management si suddividono in: 20
competenze tecniche, 15 competenze comportamentali, 11 competenze contestuali. Ogni elemento di
competenza è caratterizzato da:
• possibili passi di processo (process step);
• elenco degli argomenti trattati (addressed topic);
• principali relazioni;
• schemi di comportamento (solo per gli elementi di competenza comportamentale).
Il documento dell’ICB ha un approccio a volte poco chiaro, ricco di spiegazioni ma un po’ vago senza
spiegazioni approfondite, questo sia per la natura non metodica dello schema del documento, sia per la
mancanza di tabelle, diagrammi, esempi e commenti che ne facilitino la comprensione e la lettura. L’unico
riferimento ad esperienze della vita reale è contenuto nel ventaglio delle “competenze comportamentali”
dove, attraverso lo schema di comportamento “behavioral pattern”, sono riportati pratici esempi di
comportamenti da seguire e da non seguire.
IPMA presta attenzione alle differenze culturali tra i suoi National Member; quando infatti l’ICB viene
adottato da un membro nazionale diventa la loro National Competence Baseline (NCB) che però consente
adattamenti e cambi per venire incontro agli standard locali. (30)
La struttura della ISO 21500 è fortemente ispirata a quella del PMBOK e riprende il concetto delle
competenze del Project Manager proposte dall’ICB. Nella ISO 21500, il ciclo di vita del progetto è suddiviso
in 39 Processi, ognuno dei quali parte di uno dei 5 Gruppi di Processi e pertinente ad uno dei 10 Gruppi
Tematici. I Processi sono tra loro connessi da input e output, che possono essere attività, decisioni, prodotti
o documenti.
Lo standard ISO 21500 è completamente teorico, ma molto più essenziale rispetto agli altri, essendo una
norma e non un manuale. Nonostante sia conciso, se ne riconosce un approccio metodico e meticoloso; sono
presenti alcuni diagrammi ma non sono riportati né esempi né domande o dubbi. I riferimenti all’esperienza
reale sono completamente mancanti, per la natura stessa di una norma, che si propone di riportare i concetti
principali in maniera teorica e concisa.
79
Nel PRINCE2 il ciclo di vita del progetto è suddiviso in Processi, ognuno dei quali caratterizzato da diverse
Attività. Il progetto è caratterizzato da:
• 6 variabili, che devono essere costantemente gestite durante il ciclo di vita del progetto;
• 7 principi, che rappresentano le buone caratteristiche del progetto;
• 7 temi, che sono punti ai quali ci si deve continuamente indirizzare durante il ciclo di vita del progetto;
ogni tema, a seconda della propria natura, è caratterizzato da contenuti e struttura appropriati, dalle
figure responsabili e da uno specifico approccio;
• 7 processi, pertinenti ad uno specifico livello dell’organizzazione del progetto, sono caratterizzati da:
scopi e obiettivi, attività, input e output, principali temi correlati, figure responsabili.
In PRINCE2, la figura del Project Manager è intesa come quella di chi conosce tutto a proposito del progetto;
a differenza degli altri documenti però, il PRINCE2 evidenzia che la responsabilità complessiva è nelle mani
nel Comitato di Progetto (Project Board).
Il PRINCE2 ha uno schema logico e schematico, nonostante si presenti più complesso rispetto agli altri. Lo
standard è ricco di descrizioni, molto approfondite ma non eccessivamente lunghe, e di tabelle, diagrammi e
liste che aiutano a focalizzarsi sui punti principali.
La presentazione è rafforzata da un buon numero di domande, utili a capire meglio gli obiettivi di ogni
paragrafo, e da esempi concreti, accompagnati da documenti contenenti dati reali. In particolare, nella parte
di descrizione di ogni Tema o Processo, è previsto un paragrafo intitolato “Cosa succede nel mondo reale?”
(What happens in the real word?”) che mostra le situazioni e i problemi più ricorrenti nella realtà.
Sebbene PRINCE2 sia un documento prescrittivo, può essere adattato in base alla dimensione del progetto
(42).
3.6.1.2 Definizioni e nomenclatura
Tutti i documenti analizzati fanno chiarezza, generalmente nella prima parte del loro sviluppo, sul significato
dei termini utilizzati, con l’obiettivo di creare un linguaggio comune ed evitare fraintendimenti nei lettori. I
documenti identificano e definiscono, in maniera chiara ed efficace, i principali concetti e le più importanti
definizioni che costituiscono la struttura del Project Management; tra questi: il progetto e le sue
caratteristiche, il Project Management e i suoi strumenti, la gestione di programmi e portafogli di progetti.
Una prima differenza è data dalla diversa definizione di progetto fornita dal PMBOK e dall’ICB. In particolare,
il primo documento definisce un progetto come “uno sforzo temporale che si porta a termine per creare un
80
prodotto, servizio o risultato unico” (33), il secondo come “un’operazione, con forti vincoli di tempi e di costi,
che ha lo scopo di realizzare un insieme di risultati (deliverables), al fine di raggiungere gli obiettivi del
progetto, rispettando i requisiti fissati e gli standard di qualità richiesti” (36). Si evince come il documento
dell’ICB si concentri ed enfatizzi il concetto di qualità del prodotto finale. Un’accezione di progetto simile al
PMBOK è invece offerta dal metodo PRINCE2 che definisce un progetto come “un’organizzazione
temporanea creata con lo scopo di portare a termine uno o più prodotti in accordo con il Business Case
concordato” (37).
Si riscontrano anche alcune differenze sulla definizione dei ruoli all’interno dei diversi documenti. PRINCE2,
ad esempio, è molto più prescrittivo sulla definizione del Comitato di Progetto (Project Board) rispetto al
PMBOK e alla norma ISO 21500; nella norma ISO 21500, inoltre, non saranno mai definiti i ruoli del Team
Manager o del Team Member perché fuori dagli obiettivi dello standard (24). I documenti di PMBOK,
PRINCE2, ICB e ISO 21500 condividono, quasi completamente, le definizioni del ruolo del Project Manager e
le attività a lui riservate. Il metodo PRINCE2 specifica che il ruolo del Project Manager è quello di “realizzare
gli obiettivi del progetto all’interno degli obiettivi fissati di tempo, costo, qualità, scopo, benefici e rischi”
(37); in maniera molto simile il PMBOK dice che il ruolo del Project Manager è quello di “lavorare in sinergia
con il Program o Portfolio Manager per raggiungere gli obiettivi del progetto ed assicurare che il piano di
progetto sia allineato con il piano di programma” (33). Al contrario degli altri documenti, l’ICB si focalizza
principalmente sulla valutazione della capacità e delle competenze del Project Manager, ritenendo questi
fattori fondamentali per il successo del progetto, più dell’applicazione dei processi (42). Sempre in
riferimento alle competenze del Project Manager, si evidenzia un’altra differenza tra PMBOK e standard ISO
21500: il primo descrive le competenze in maniera approfondita, il secondo discute esclusivamente il
progetto del gruppo di lavoro e del personale (Project team and personnel).
In tutti i documenti analizzati, sono specificate le relazioni che intercorrono tra Project, Programme e
Portfolio Management. Il PMBOK concepisce questi concetti come la base dell’Organizational Project
Management (OPM) e, quindi, introduce l’argomento del Project Management Office (PMO), al quale né la
ISO 21500 né gli altri manuali di riferimento dedicano attenzione (43).
In termini di ciclo di vita di un progetto, PRINCE2, PMBOK e norma ISO21500 hanno lo stesso concetto di Fase
e sottolineano tutti che, in corrispondenza del punto di inizio di ogni fase si riscontra la necessità di prendere
specifiche decisioni. La norma ISO 21500, però, non fornisce indicazioni su best practice da utilizzare per
affrontare la fase decisionale, essendo fuori dal suo scopo tutte le responsabilità non direttamente imputabili
al Project Manager ma ad altre autorità (42).
81
Un’ulteriore definizione riportata in maniera diversa nel PMBOK e nell’ISO 21500 riguarda gli stakeholders
di progetto. Il PMBOK definisce uno stakeholder come “una persona o un’organizzazione che è attivamente
coinvolta nel progetto, o i cui interessi possono essere positivamente o negativamente influenzati
dall’esecuzione o completamento del progetto”. PRINCE2, sicuramente più specifico, individua tre categorie
di stakeholders: Business Sponsors, responsabili dei finanziamenti al progetto; utenti (users), che utilizzano
effettivamente il prodotto una volta completato; fornitori (suppliers), che forniscono competenze e risorse
al progetto e fondamentalmente producono il prodotto.
La Tabella 11 rappresenta le principali differenze e similitudini tra PMBOK e ISO 21500, riguardanti i concetti
e le definizioni analizzate nei due documenti.
Tabella 11- Confronto di "concetti e definizioni" tra PMBOK e ISO 21500
3.6.1.3 Input e output
Sia il PMBOK che la norma ISO 21500, comprendono circa 70-80 elementi di informazione di input e output
relativi ai processi. Le tipologie di input e output sono riportate in Figura 21; ciascun elemento può (22):
• provenire o essere generato all’esterno dei processi di Project Management, quindi entrare in uno o
più di questi come input esterno (elementi Nie);
• essere generato come output da uno o più processi ed essere internamente utilizzato da almeno un
processo (Ni);
• essere generato come output da almeno un processo, non essere internamente riutilizzato da alcun
processo, essere fornito solo verso l’esterno del sistema di Project Management (Noe).
82
Figura 21- Tipi di elementi di input e/o output dei processi (22)
Un metodo presentato in occasione di una conferenza PMI, svoltasi presso la Libera Università Internazionale
degli Studi Sociali Guido Carli (LUISS) di Roma, propone l’analisi della “congruenza interna” fra gli input-
output per verificare se o quale parte degli output, generati all’interno dei processi, vengano riutilizzati come
input di altri processi, oppure se gli elementi vengano acquisiti o prodotti solo da o per l’ambiente esterno.
Dal confronto comparativo fra PMBOK e standard ISO 21500, i cui dati sono riassunti in Tabella 1, si potrebbe
dedurre che il PMBOK sia in generale più internamente congruente della norma ISO; le ragioni sono da
ricondursi presumibilmente ad una sua maggiore maturità, che avrebbe portato nel tempo una migliore
selezione ed aggregazione degli input-output, con riferimento sia agli elementi interni che a quelli
d’interfaccia con l’ambiente esterno (22).
Tabella 12- Sintesi dell'analisi di "congruenza interna" dei processi (22)
Le competenze tecniche, comportamentali e contestuali proposte dall’ICB sono tra loro correlate, come
accade per i processi proposti dal PMBOK. Come appena visto, gli output provenienti da un processo nel
PMBOK possono essere utilizzati come input per un processo successivo; allo stesso modo, le informazioni
provenienti da una delle tre competenze descritte nell’ICB possono contribuire, come input, a un diverso tipo
di competenza.
La norma ISO 21500 e il PMBOK si limitano a definire un certo insieme di processi con i rispettivi input e
output principali, senza però entrare nella struttura delle singole attività; al contrario il PRINCE2 definisce
una specifica architettura di attività, con i relativi gate di controllo e i momenti decisionali (22).
83
3.6.1.4 Strumenti e tecniche
Il documento del PMBOK definisce gli elementi di “Tecniche e Strumenti”, che per ogni processo
raccomandano i “mezzi”, ovvero le tecniche e gli strumenti, necessari o più opportuni per la realizzazione dei
processi stessi. Le tecniche e gli strumenti riproposte nel PMBOK sono di diversa natura, assumendo sia la
forma di metodi o metodologie generali che quella di tecniche particolari, specifiche per diverse aree di
conoscenza o per i singoli processi. Oltre ad essere di natura ampia e variegata, le voci relative a tecniche e
strumenti nel PMBOK rappresentano un certo grado di disomogeneità, assumendo una forma più specifica
per alcuni processi e più generali per altri (22).
Se nel PMBOK le tecniche e gli strumenti costituiscono una parte centrale, sono invece assenti nel PRINCE2.
Infatti, se per ogni competenza presentata nel PMBOK è proposta una relativa sezione con tecniche e
strumenti che fornisce specifiche e dettagliate informazioni per la tecnica specifica, PRINCE2 afferma
solamente che bisognerebbe scegliere per un progetto le tecniche più indicate, senza fornire
approfondimenti a riguardo (42).
Gli elementi di “Tecniche e Strumenti” non sono presenti all’interno della norma ISO 21500 (44). Nella norma
ISO 21500 sono inoltre assenti i riferimenti ad alcune tecniche e approcci, presenti in PRINCE2; i principali
sono: gestione del ciclo di vita del progetto (in particolare al limite tra le fasi), Business Case, gestione delle
eccezioni (24).
3.6.1.5 Gruppi di processo
Il PMBOK e la norma ISO 21500 presentano entrambi 5 Gruppi di Processo di Project Management, ognuno
dei quali è presentato dettagliatamente nei documenti, anche attraversi possibili applicazioni dei processi
stessi. Le differenze tra i Gruppi di Processo sono davvero minime e riguardano esclusivamente una diversa
denominazione del terzo e quarto Gruppi di Processo.
84
La Tabella 13 mette in evidenza le corrispondenze e le leggere differenze tra i Gruppi di Processo nel PMBOK
e nella ISO 21500.
Tabella 13- Confronto tra i Gruppi di Processo in PMBOK e ISO 21500 (44)
I Gruppi di Processo trovano adeguata corrispondenza anche nei processi dello standard PRINCE2, come
rappresentato in Tabella 14. Esiste però una differenza sostanziale tra la struttura dell’attuale norma ISO
21500, che riprende in gran parte quella del PMBOK, e quella del PRINCE2. Nel PRINCE2, la fase di un progetto
è chiaramente definita all’interno dei processi, così che l’“Inizio di un Progetto” e la “Chiusura di un Progetto”
sono sviluppate diversamente dall’“Inizio di una fase” e “Chiusura di una fase”; al contrario, la ISO 21500 e il
PMBOK trattano un progetto e una fase del progetto in maniera identica. Nel PMBOK e nella ISO 21500,
inoltre, non vengono indicate le procedure per iniziare una nuova fase all’interno di un progetto; nel PRINCE2,
le stesse informazioni sono da ricercarsi del processo di “Direzione di un Progetto” e “Gestione dei limiti di
fase” (24).
Tabella 14- Confronto tra i Gruppi di Processo in PRINCE2 e ISO 21500 (24)
85
3.6.1.6 Aree di conoscenza e Processi
Le Aree di Conoscenza presentate nel PMBOK corrispondono ai Gruppi Tematici nella norma ISO 21500 e, in
entrambi gli standard, il loro numero è pari a 10. Nelle ultime versioni dei due documenti, i Gruppi Tematici
e le Aree di Conoscenza corrispondono quasi completamente, sia nel contenuto, sia nella nomenclatura.
Un’eccezione è data dall’Area di Conoscenza delle “Gestione delle Risorse umane” del PMBOK, che trova
corrispondenza nel Gruppo Tematico “Risorse” della ISO 21500. Il tema “Risorse” è quindi apparentemente
più sviluppato nella ISO 21500, che copre tutte le tipologie di risorse, umane e materiali (44).
La differenza principale tra il PMBOK e la norma ISO 21500 riguarda il numero dei processi inclusi nelle Aree
di Conoscenza e nei Gruppi Tematici, rispettivamente pari a 47 e 39, osservando a prima vista una
semplificazione della norma ISO 21500 rispetto al documento del PMI.
Altre differenze tra PMBOK e norma ISO 21500 riguardano i processi che nel riferimento ISO sono mancanti
rispetto al PMBOK; in particolare, non si trovano in modo esplicito nella ISO 21500 i seguenti processi invece
presenti nel PMBOK:
• “pianificare la gestione degli stakeholders” (Plan Stakeholders Management), presente nell’ Area di
Conoscenza “Stakeholders” nel PMBOK;
• “validare l’ambito” (Validate Scope) e “raccogliere i requisiti” (Collect Requirements), presenti
nell’Area di Conoscenza di “Ambito” nel PMBOK;
• “chiudere gli approvvigionamenti” (Close Procurement), presenti nell’Area di Conoscenza di
“Approvvigionamento nel PMBOK.
Tra i processi mancanti, alcuni trovano però corrispondenza con voci di output presenti nella stessa norma,
sotto la più generica dizione di “Piani di Progetto” o “Piani complementari”. In particolare, tra quelli elencati,
solo il processo “chiudere gli approvvigionamenti” è formalmente assente nell’ISO 21500, gli altri trovano
comunque una corrispondenza come output (22).
Un’altra differenza riguarda il processo di “Rispondere ai Rischi” (treat risks), appartenente al Gruppo
Tematico di “Rischio” nella ISO 21500. Se nella norma ISO questo processo è assegnato al Gruppo di Processo
di Esecuzione, nel PMBOK il processo di analoghe finalità si ritrova posizionato nel Gruppo di Processo di
Pianificazione.
Nella norma ISO 21500 è invece presente un processo, “Raccogliere le lezioni apprese”, che non trova una
esplicita corrispondenza nel PMBOK, nonostante sia ampiamente citato all’interno dello stesso.
86
La Tabella 15 riporta le differenze principali tra Aree di Conoscenza di PMBOK, Gruppi Tematici della ISO
21500 e relativi Processi.
Tabella 15- - Confronto tra Aree di Conoscenza, Gruppi Tematici e Processi in PMBOK e ISO 21500 (43)
Le Aree di Conoscenza del PMBOK possono essere equiparate ai Temi presentati all’interno del documento
del PRINCE2, così come i 47 Processi del PMBOK trovano corrispondenza con le 40 Attività di PRINCE2.
Nonostante le molte corrispondenze tra Aree di Conoscenze, Gruppi Tematici e Temi, è possibile identificare
tra loro delle differenze, più o meno rilevanti.
Una prima differenza tra PMBOK e PRINCE2 riguarda l’Area di Conoscenza delle “Gestione delle Risorse
umane” del PMBOK. Se quest’ultimo dedica un’intera Area di Conoscenza all’argomento delle risorse umane,
fornendo informazioni dettagliate su come sviluppare un piano per le risorse umane e su come acquisire,
87
sviluppare e gestire un gruppo di progetto, PRINCE2 affronta il tema delle “Risorse umane” in maniera meno
approfondita, non fornendo informazioni specifiche riguardo alle risorse umane e alla loro gestione (42).
Il tema delle “Comunicazione” è un ulteriore punto diversamente trattato nel PRINCE2 e nei documenti di
PMBOK e ISO 21500. Nello standard internazionale e nel documento del PMI, l’Area di Conoscenza o il Gruppo
Tematico della “Comunicazione” si riferisce alla comunicazione all’interno del gruppo di progetto. In PRINCE2
il tema della comunicazione è proposto nel Tema del “Progresso” e la comunicazione presentata è quella tra
gli stakeholders esterni al gruppo di progetto (24).
Un’ulteriore differenza tra i contenuti dei documenti, riguarda il Gruppo Tematico degli “Stakeholders”. Se,
infatti, il PMBOK e PRINCE2 dedicano un’intera Area di Conoscenza e Gruppo Tematico all’argomento, non è
possibile trovare una esplicita corrispondenza tra i Temi del PRINCE2; in quest’ultimo documento,
l’argomento della gestione degli stakeholders può essere però ricondotto all’Attività “Lavorare con gli
Stakeholders” (Working with the Stakeholders), collegata al Tema dell’Organizzazione.
L’unica Area di Conoscenza del PMBOK che nel PRINCE2 non è spiegata è quella dell’“Approvvigionamento”.
Mentre non ci sono menzioni dell’approvvigionamento in tutto il manuale del PRINCE2, il PMBOK stabilisce
che “l’Area di Conoscenza di “Approvvigionamento” include tutti i processi necessari a comprare o acquisire
prodotti, servizi o risultati, richiesti all’esterno del team di progetto” (33).
Nella Tabella 16 si riporta un riassunto del confronto tra le Aree di Conoscenza del PMBOK, i Gruppi Tematici
della norma ISO 21500 e i Temi del PRINCE2.
ISO 21500 PMBOK PRINCE2
Aree di Conoscenza Gruppi Tematici
Temi
Integrazione Gestione dell'Integrazione di Progetto Cambiamenti
Ambito Gestione dell'Ambito di Progetto Business Case
Tempo Gestione dei Tempi di Progetto Piani
Business Case
Costo Gestione dei Costi di Progetto Business Case
Qualità Gestione della Qualità di Progetto Qualità
Risorse Gestione delle Risorse Umane di Progetto Organizzazione
Comunicazione Gestione della Comunicazione di Progetto Progresso
Rischio Gestione dei Rischi di Progetto Rischio
Approvvigionamento Gestione dell'Approvvigionamento di Progetto
Stakeholders Gestione degli Stakeholders di Progetto
Tabella 16- Confronto tra Aree di Conoscenza, Gruppi Tematici e Temi in PMBOK, ISO 21500 e PRINCE2
88
3.6.1.7 Competenze tecniche, comportamentali e contestuali
Il riferimento di competenze di Project Management dell’IPMA, noto come ICB, definisce 46 elementi di
competenze, suddivisi in competenze tecniche, comportamentali e contestuali. Ogni elemento di
competenza è costituito da una “scheda” di concetti sulla disciplina, basata su un proprio template composto
dalle seguenti parti:
• definizione dell’elemento e descrizione dei relativi concetti;
• possibili passi di processo (process step);
• elenco degli argomenti trattati (addressed topic);
• principali relazioni;
• schemi di comportamento (solo per gli elementi di competenza comportamentale).
Per la comparazione tra il documento ICB, la norma ISO 21500 e il PMBOK, si è cercato di inquadrare, per
quanto possibile, l’elemento di competenza dell’ICB con la corrispondente voce di Area Tematica o di
Conoscenza, rispettivamente relative alla ISO 21500 e al PMBOK. Questa comparazione non può essere, come
nel caso del confronto tra PMBOK e ISO 21500, di tipo “uno ad uno”, per la natura stessa dell’ICB, che risulta
molto più libero degli standard con cui si intende effettuare il confronto (22).
La Tabella 17 rappresenta un prospetto comparativo tra gli elementi di competenza tecnica e contestuale ICB
e le Aree Tematiche della ISO 21500.
Confrontando, nei limiti del possibile, gli elementi di competenza tecnica ICB con le Aree Tematiche della
norma ISO 21500, si evince che gli elementi di competenza tecnica dell’ICB, pur non rispecchiando la struttura
a matrice della ISO 21500, costituiscono una tabella monodimensionale in cui si riconoscono le 10 Aree
Tematiche della ISO 21500 e 3 dei 5 Gruppi di Processo (Avvio, Controllo e Reporting, Chiusura). Si nota
inoltre come ad una stessa Area Tematica ISO 21500 possono corrispondere più elementi di competenza ICB;
ciò avviene in particolare per le Aree Tematiche di Integrazione, Ambito, Risorse e Comunicazione.
Nel modello ICB figurano voci, quali “Successo di Project Management” e “Risoluzione dei problemi”, di
carattere più generale e metodologico. Queste voci non trovano un parallelo diretto nella ISO 21500, proprio
a rimarcare il carattere di cultura generale che si è voluto dare alle pratiche in oggetto nel manuale ICB
dell’IPMA; vengono quindi incluse nell’Area Tematica di Integrazione, la più generale e trasversale proposta
dalla norma ISO 21500 (22).
La comparazione tra gli elementi di competenza contestuale e comportamentale ICB e le Aree Tematiche ISO
21500 è più difficile da eseguire e porta ad un minor numero di connessioni tra i due documenti.
Confrontando le competenze contestuali con le Aree Tematiche dell’ISO 21500, si evince che solo le Aree
89
Tematiche di Integrazione e Risorse trovano reale corrispondenza con gli elementi di competenza contestuale
ICB; all’Area Tematica di Integrazione vengono corrisposte elementi riguardanti, ad esempio, il carattere della
stessa organizzazione permanente, a quella delle Risorse si associano gli elementi appartenenti l’area più
generale delle risorse umane e di carattere contestuale.
Nella Tabella 17 si riporta un riassunto del confronto tra le Aree Tematiche in ISO 21500 ed Elementi di
Competenza Tecnica e Contestuale proposti dall’ICB.
Tabella 17- Parallelo tra Aree Tematiche in ISO 21500 ed Elementi di Competenza Tecnica (sinistra) e Contestuale (destra) (22).
In seconda analisi, è possibile effettuare un confronto tra il documento ICB e il PMBOK; come per il confronto
tra il primo e la norma ISO 21500, però, non è possibile effettuare un confronto “uno ad uno” ma si
ricercheranno delle semplici similitudini tra elementi ICB e contenuti nel PMBOK.
Gli elementi di competenze tecniche nell’ICB trovano adeguata corrispondenza all’interno del PMBOK (42):
• il Gruppo di Processo di Inizio del PMBOK corrisponde alla competenza tecnica “Avviamento del
Progetto” (Start-Up) dell’ICB;
• il Gruppo di Processo di Pianificazione del PMBOK corrisponde alla competenza tecnica “Requisiti ed
obiettivi del progetto” (Project Requirements and Objectives) dell’ICB;
• il Gruppo di Processo di Esecuzione del PMBOK corrisponde alla competenza tecnica “Risoluzione dei
Problemi” (Problem Resolution) dell’ICB;
• qualità, lavoro di gruppo, approvvigionamento, monitoraggio e controllo, distribuzione delle
informazioni e chiusura sono tutti presentati in entrambi i documenti.
90
Un'ulteriore analisi può riguardare il confronto tra gli elementi di competenza comportamentale dell’ICB,
spesso definiti “soft skills” e le corrispondenze all’interno del PMBOK. Il particolare si rileva che nel
documento ICB si definiscono 15 voci di competenze comportamentali, mentre nel PMBOK si riportano 8
“capacità interpersonali”, tre delle quali in comune con il primo documento. Le voci formalmente uguali nei
due documenti sono (22):
• Leadership: la capacità di dirigere e motivare gli altri nel ruolo e nei compiti assegnati, allo scopo di
conseguire gli obiettivi del progetto, infondendo una vision comune all’interno del team; lo stile di
leadership deve adattarsi e modularsi con la maturità degli individui e degli ambienti di lavoro.
• Motivazione: la capacità di creare le condizioni e l’ambiente di progetto tali da spingere gli individui
ad operare al massimo delle proprie capacità; tra i fattori motivanti si rilevano la caratteristica di
ispirare entusiasmo, coinvolgimento e iniziativa.
• Negoziazione: la capacità di superare e risolvere i disaccordi tra le parti, in modo da arrivare ad una
soluzione soddisfacente per tutti, attraverso accordi e compromessi; nella negoziazione si
riconoscono capacità di dimostrare trasparenza ed equilibrio e sapersi immedesimare negli altri.
Gli elementi di competenze contestuali nell’ICB trovano invece bassa corrispondenza all’interno del PMBOK.
Dal confronto tra i documenti di ICB e PMBOK si evince che, mentre il primo si focalizza sulle competenze
comportamentali che rappresentano le relazioni personali in un team, il PMBOK si concentra sulle
competenze tecniche invece che su quelle personali (45).
3.6.2 Vantaggi e svantaggi delle metodologie
Gli standard e le metodologie presentate nel dettaglio e tra loro comparate nei precedenti paragrafi sono
largamente utilizzate ed impiegate per la gestione di progetti di diversa natura. La scelta del documento da
adottare è vincolata al grado di maturità dell’organizzazione, alla tipologia di progetti condotti, agli obiettivi
che si intendono raggiungere e ai vantaggi e agli svantaggi che potrebbero derivare dall’utilizzo di un
determinato modello di Project Management.
Con l’obiettivo di capire meglio i contesti in cui sia meglio applicare i singoli standard e le metodologie, in
questo paragrafo si presenta un’analisi sui punti di forza e di debolezza di ognuno dei documenti
precedentemente analizzati.
91
3.6.2.1 PMBOK
Il PMBOK è uno degli strumenti più utilizzati nel mondo riguardo alla gestione di progetti e la sua larga
diffusione, dovuta ai contenuti ampi e approfonditi che propone, ha fatto sì che diventasse anche la base per
lo sviluppo di altre metodologie di Project Management.
Il PMBOK si è così ampiamente affermato all’interno del panorama del Project Management grazie ai
vantaggi che porta nella pratica quotidiana del Project Manager. Come già visto durante il confronto con gli
altri documenti, la struttura del PMBOK presenta alcuni punti di forza:
• la struttura del metodo è chiara e precisa, con punti di partenza e arrivo definiti e processi ed attività
intermedie caratterizzate da input, strumenti, tecniche e output tra loro relazionati;
• ogni singolo processo è approfondito con attenzione e la sua comprensione è facilitata dall’utilizzo
di tabelle, schemi e diagrammi ben organizzati;
• presenza di un’analisi dettagliata delle diverse tipologie di organizzazione aziendale.
Nelle organizzazioni di piccole dimensioni oppure con ancora poca esperienza di Project Management può
sembrare apparentemente più semplice e veloce partire dall’utilizzo di una metodologia già preconfezionata,
piuttosto che da una complessa ed adattabile come quella proposta dal PMBOK. In realtà l’utilizzo del PMBOK
rispetto alle più rigide metodologie “preconfezionate” può portare ai seguenti vantaggi:
• ogni organizzazione può ritagliare le best practices contenute nel PMBOK in funzione dello specifico
settore di mercato in cui opera;
• l’organizzazione può adottare la terminologia ed i processi più adatti al livello di maturità raggiunto
nell’applicare il Project Management all’interno dell’azienda;
• la metodologia può essere migliorata, implementata ed estesa nel tempo, facendo sì che si adatti ai
cambiamenti interni all’organizzazione che si rendono necessari nel tempo;
• le best practices non riguardano solo i processi di Project Management ma anche i ruoli coinvolti
nella gestione dei progetti e questo consente di avere uno schema di riferimento rispetto al quale
costruire il modello organizzativo più adatto alla gestione del singolo progetto;
• la costruzione della metodologia porta sia a standardizzare le proprie prassi interne rendendole più
efficaci ed efficienti, sia a potenziare la formazione di tutto il personale coinvolto nei progetti.
Il documento del PMBOK presenta anche dei punti di debolezza (32):
• assenza della suddivisione delle competenze tecniche, comportamentali e contestuali come nell’ICB;
• assenza di una sezione dedicata all’esame di preparazione per le certificazioni e “Gestione della
qualità affrontata in soli tre processi.
92
3.6.2.2 ICB
Il documento ICB proposto dall’IPMA propone al suo interno, non specifici metodi e strumenti di Project
Management, ma il dettaglio di tutte le competenze tecniche, comportamentali e contestuali che il Project
Manager dovrebbe possedere per la gestione completa di un progetto. I principali aspetti positivi del
documento ICB sono:
• chiara e definita suddivisione delle competenze del Project Manager, articolare in competenze
tecniche, comportamentali e contestuali;
• attenzione prevalente alle competenze contestuali e comportamentali (soft skills), accompagnate da
una descrizione completa e approfondita;
• integrazione dei paragrafi relativi alle competenze comportamentali con gli “schemi di
comportamento”, tabelle in cui vengono confrontati i comportamenti positivi e negativi da tenere
nelle reali esperienze lavorative;
• adattabilità, attraverso nuovi e diversi elementi di competenze, alle necessità delle singole realtà
nazionale e alle differenze culturali.
Nell’ICB però, le descrizioni risultano spesso poco chiare e confuse e non si dedica alle competenze tecniche
la stessa attenzione rivolta a quelle comportamentali e contestuali.
3.6.2.3 ISO 21500:2012
La struttura della ISO 21500:2012 è fortemente influenzata dal PMBOK e riprendere gli elementi di
competenza riportanti all’interno dell’ICB proposto dall’IPMA. L’obiettivo dello standard è quello di fornire
un punto di riferimento per la gestione dei progetti, attraverso un documento sintetico e conciso.
Tra gli aspetti negativi relativi alla ISO 21500 si possono identificare sia la forma estremamente concisa del
documento, che quindi non approfondisce opportunamente alcuni aspetti e ne trascura completamente altri,
sia l’assenza di schemi, tabelle, grafici ed esempi, che potrebbero migliorare la comprensione dei concetti. I
punti di forza della norma ISO 21500, riprendono in parte quanto già detto per PMBOK e ICB:
• la struttura del metodo è chiaro e precisa, con punti di partenza e arrivo definiti e processi ed attività
intermedie caratterizzate da input, strumenti, tecniche e output tra loro relazionati;
• chiara e definita suddivisione delle competenze del Project Manager, articolata in competenze
tecniche, comportamentali e contestuali;
• presenza, all’inizio di ogni paragrafo, dei termini e delle definizioni utilizzate, in modo da facilitare la
lettura e la comprensione dei contenuti del documento.
93
3.6.2.4 PRINCE2
Il PRINCE2 utilizza un approccio strutturato al Project Management fortemente orientato al prodotto
ed è in grado di adattarsi ad ogni tipologia di azienda. La metodologia è stata infatti definita per garantire
scalabilità, flessibilità e adattabilità per la gestione dei progetti di diversa natura.
La struttura stessa del PRINCE2 presenta alcuni punti di forza, tra i quali:
• la struttura del metodo si basa sui processi, tra loro relazionati attraverso input e output, sui temi e
sui principi, che devono essere considerati attraverso tutto il ciclo di vita del progetto;
• esiste una definizione precisa delle fasi di progetto e sono chiaramente identificati i responsabili per
la realizzazione di ogni singola azione e la redazione dei diversi documenti;
• l’esposizione delle metodologie è supportata dall’utilizzo di esempi, riferimenti ad esperienze reali e
strumenti quali tabelle, schemi e diagrammi;
• presenza di template, ovvero di documenti pro-forma, completi e definiti, utili per la realizzazione
dei vari documenti e deliverables gestionali di progetto;
• definizione di un documento che segue l’intero ciclo di vita del progetto: il Project Plan.
Anche i contenuti presentati all’interno del PRINCE2 presentano delle caratteristiche che rendono
vantaggioso l’utilizzo del documento per la gestione di progetti. Tra questi vantaggi si riportano (46):
• focus sulla gestione dei cambiamenti e sul miglioramento continuo;
• rispetto dei requisiti, anche in termini di qualità del prodotto, grazie al coinvolgimento del cliente e
di tutti gli stakeholders del progetto;
• continua gestione della qualità e dei rischi lungo tutto il ciclo di vita del progetto;
• controllo e gestione delle risorse e delle deviazioni.
Dall’analisi del PRINCE2 con gli altri documenti di riferimento per il Project Management, si evince che, oltre
ai vantaggi sopra citati, PRINCE2 presenta dei limiti, tra cui:
• assenza della suddivisione delle competenze tecniche, comportamentali, contestuali di Project
Management, come proposto dall’ICB;
• assenza di un’analisi dedicata all’approvvigionamento dei materiali;
• presenza di numerose ripetizioni nel corso dell’esposizione.
94
95
4. Agile Project Management
In un mercato sempre più dinamico è indispensabile, per poter restare competitivi, possedere la capacità di
evolversi ed adattarsi velocemente ai cambiamenti. Nell’ultimo decennio, le metodologie tradizionali di
Project Management si sono rivelate spesso inefficaci nel garantire il successo, in termini di tempi, costi e
qualità, di una grande percentuale di progetti indipendentemente dalla loro effettiva complessità. Questa
evidenza ha generato una spinta verso il cambiamento, necessario per promuovere, all’interno dell’azienda,
l’adozione e la diffusione di nuove tecniche e metodologie per lo sviluppo, l’amministrazione e la gestione
dei progetti e dei team impegnati nella loro realizzazione. Queste metodologie, basate su un approccio Agile,
hanno come fine comune quello di incrementare la produttività e l’efficienza del gruppo di lavoro, mediante
l’introduzione di un forte cambio di paradigma nella gestione delle risorse di progetto, nella struttura
organizzativa, nei piani strategici e, soprattutto, nella cultura aziendale.
Agile Project Management si inserisce nello scenario fortemente dinamico dell’attuale contesto di mercato,
garantendo reattività e prontezza di risposta al cambiamento. Al contrario degli approcci tradizionali, che
definiscono lo scope e procedono con la stima di tempi e costi necessari per arrivare al risultato, l’approccio
Agile mantiene fissi tempi e costi, adattando lo scope e dando priorità alle caratteristiche del prodotto.
Negli ultimi anni, molte aziende hanno trasformato Agile in un’opportunità di crescita, ottenendo benefici
rilevanti. Si stima che alla fine del 2016 il 75-80 % delle organizzazioni stesse usando soluzioni Agile e che la
percentuale di progetti gestiti con approccio Agile di maggior successo rispetto a quelli gestiti con
metodologie tradizionali, ad oggi pari al 200%, sia destinata a raddoppiare nel 2018 (47). Nella Figura 22 si
riportano i principali miglioramenti riscontrati dalle aziende che hanno implementato metodologie Agile nella
gestione aziendale e del team di sviluppo o di progetto.
Figura 22 - Miglioramenti nelle realtà aziendale che hanno implementato metodologie Agile (47)
96
4.1 Sviluppo di Agile Project Management nel tempo
Lo sviluppo di metodologie iterative e incrementali venne introdotto, per la prima volta, nel 1930 da Shewart
ma fu approfondito solo intorno agli anni ’80.
Tra il 1970 e il 1980, il settore manifatturiero incontrò numerose difficoltà nel gestire le operazioni di
produzione attraverso l’impiego di sistemi di gestione tradizionali; si raggiunsero livelli di successo più o meno
soddisfacenti attraverso l’utilizzo di una pianificazione formale di produzione e materiali, di programmazione
e controllo della linea di produzione, e di sistemi quali la “Pianificazione dei fabbisogni di materiali”
(Manufacturing Resource Planning - MRP) e la “Pianificazione delle risorse d’impresa (Enterprise Resource
Planning - ERP) (48).
Intorno agli anni ’80 si assistette ad un profondo cambiamento di tutti i settori industriali e produttivi, dovuto
all’alto livello di incertezza dei mercati, al diffondersi delle nuove tecnologie, ai cambiamenti richiesti in
termini di caratteristiche e funzionalità dei prodotti. In questo contesto, i consumatori spinsero le aziende
verso maggiore flessibilità, tempi di esecuzioni più brevi e maggiore varietà di prodotti e servizi. Per
rispondere alle richieste del mercato, le imprese svilupparono nuovi modelli manifatturieri che
considerassero le principali richieste e necessità dei consumatori.
Nel 1982, Il Giappone si affidò all’americano W. Edwards Deming per introdurre degli strumenti atti ad
assicurare un progressivo miglioramento della qualità dei prodotti offerti. Deming o Deming Cycle (ciclo di
PDCA, acronimo di Plan–Do–Check–Act, in italiano "Pianificare - Fare - Verificare - Agire") è un metodo di
gestione iterativo in quattro fasi, ad ognuna delle quali corrispondono precise attività; il metodo è utilizzato
in attività per il controllo e il miglioramento continuo dei processi e dei prodotti ed è tuttora impiegato per
lo sviluppo dei prodotti in Toyota (49).
Negli anni ’90 si assistette ad un contemporaneo aumento del numero di progetti sviluppati e ad una
riduzione dei partecipanti coinvolti all’interno di ciascun progetto. Nonostante questo andamento, i Project
Managers continuarono ad utilizzare i metodi tradizionali di gestione, essendo a conoscenza esclusivamente
di nuovi metodi che cercavano di svolgere i compiti in parallelo, al fine di diminuire il tempo di esecuzione,
senza però portare benefici nei casi in cui fosse necessario svolgere i compiti in serie.
L’industria del software rispose alle nuove tendenze in maniera diversa rispetto al mondo manifatturiero,
partendo dal considerare i metodi di gestione tradizionali, allora utilizzati, troppo lenti e statici ovvero
strumenti che, invece di facilitare e aiutare, ostacolavano il lavoro da svolgere. Per questo motivo, gli
sviluppatori di software iniziarono a ricercare metodi che fossero di supporto e che consentissero, al tempo
97
stesso, di sviluppare sistemi IT con ottime qualità in modo efficace. Da questa ricerca iniziarono a prendere
forma le metodologie Agile (50).
Durante gli anni ’90 furono sviluppati molti diversi sistemi che oggi fanno parte delle tecniche proprie di Agile
Project Management; il più popolare tra questi fu creato nel 1995 ed è oggi chiamato “Scrum”. Prima di
Febbraio 2001 non vi era un nome con il quale identificare tutti i nuovi metodi flessibili, fino ad allora chiamati
“leggeri”. Durante un incontro svoltosi a Snowbird, una piccola località sciistica in Utah (USA), diciassette
sviluppatori di metodi “leggeri” compresero che fosse necessario attribuire un nome e dei principi comuni ai
diversi metodi; al termine dell’incontro si concluse che il termine “Agile” fosse quello più appropriato a
descriverli tutti. I principi comuni ai diversi metodi, analizzati e concordati durante l’incontro, furono raccolti
nel “Manifesto Agile”.
Da quel momento, moltissime metodologie Agile si sono diffuse sul mercato del software ed il loro utilizzo
sta interessando anche molti altri settori, che hanno raggiunto alti livelli di successo nei propri progetti
sfruttando la flessibilità e l’adattabilità al cambiamento di Agile Project Management.
98
4.2 Principi e caratteristiche del Agile Project Management
“L’Agile Project Management è il lavoro di energizzare, arricchire e mettere gruppi di progetto in condizione
di rilasciare valore per il business in modo rapido e affidabile, coinvolgendo i clienti e adattandosi in maniera
continua ai loro bisogni e ai contesti in evoluzione” (51).
I principi fondamentali dell’approccio Agile sono stati formalizzati nel manifesto Agile e rappresentano i punti
in comune tra le molte metodologie Agile sviluppate negli ultimi anni. In questo paragrafo saranno sviluppati
ed analizzati nel dettaglio tutti i principi comuni alle metodologie e riferiti ad Agile Project Management.
La Figura 23schematizza brevemente alcuni dei principi fondamentali di Agile, successivamente sviluppati:
l’attenzione al consumatore e al soddisfare i requisiti, l’approccio flessibile e positivo ai cambiamenti, le
iterazioni e le frequenti consegne al cliente, la collaborazione quotidiana tra i membri del team, l’attenzione
al lavoro di squadra e alla comunicazione, l’auto-organizzazione del team, il miglioramento continuo e la
misura del progresso basata sulle caratteristiche del prodotto.
Figura 23 - I 22 principi di Agile Project Management (47)
4.2.1 Manifesto Agile
Il Manifesto Agile identifica i quattro principi principali su cui si strutturano tutti i metodi agili (52):
1. individui e iterazioni piuttosto che processi e strumenti;
2. software funzionante piuttosto che documentazione esaustiva;
3. collaborazione col committente piuttosto che negoziazione del contratto;
4. rispondere al cambiamento piuttosto che seguire un piano prestabilito.
99
Per evitare malintesi sui contenuti del manifesto, alcuni sviluppatori di metodi agile hanno chiarito che, fermo
restando il valore delle voci a destra, si considerano più importanti le voci a sinistra. Ognuno dei principi del
manifesto è di seguito descritto.
• Individui e interazioni piuttosto che processi e strumenti: il primo principio del manifesto Agile
specifica che il gruppo di lavoro ha la responsabilità di applicare il miglior processo per ogni specifico
progetto e non deve esclusivamente seguire il piano attraverso processi e strumenti standardizzati,
come accade nel caso di progetti sempre uguali e con le stesse caratteristiche. Essendo i progetti
unici e sempre diversi, il gruppo di lavoro è obbligato a modificare i processi e, a volte, a deviare
rispetto ai piani, scegliendo l’insieme di strumenti più adatto.
• Software funzionante piuttosto che documentazione esaustiva: il secondo principio del manifesto
Agile è riferito all’industria del software ma il concetto può essere esteso a qualsiasi tipo di progetto,
sostituendo “software funzionante” con “progetti utili” (50). Essere agili significa alleggerire i
processi: se è vero che una documentazione formale e approfondita del sistema può descriverlo in
ogni aspetto, permettendo ad un nuovo membro del team la completa familiarizzazione con lo
stesso, è altrettanto vero che la grande mole di documentazione può essere un ostacolo in situazioni
critiche, in cui anche pochi giorni di ritardo possono fare la differenza.
In termini pratici, durante il progetto si punta a raggiungere piccoli utili risultati piuttosto che fissare
degli obiettivi per ottenere il risultato dell’intero progetto. Il processo è quindi diviso in cicli brevi,
all’inizio dei quali si esamina ciò che è stato prodotto nel ciclo precedente e quali siano gli obiettivi
per il ciclo successivo; al termine di ogni ciclo si esamina ciò che è stato sviluppato e si decide se il
progetto possa ritenersi concluso, se sia necessario intraprendere un altro ciclo oppure se sia più
opportuno cancellarlo.
• Collaborazione col committente piuttosto che negoziazione del contratto: si è già più volte
menzionata l’importanza delle relazioni e della comunicazione con gli stakeholders di progetto per il
conseguimento del successo del progetto. Secondo i metodi Agile, i clienti devono partecipare
attivamente, comunicando faccia a faccia e fornendo feedback continui (53). Al termine di ciascun
ciclo che costituisce il processo, il cliente può e deve discutere e decidere cosa dovrebbe essere
continuato e cosa invece necessita di cambiamento.
Se da un lato la continua collaborazione con il cliente può portare a percentuali di successo maggiori,
dall’altro il cliente, o gli stakeholders, possono continuare a richiedere modifiche andando ad
impattare negativamente sulla durata del progetto (54).
• Rispondere al cambiamento piuttosto che seguire un piano prestabilito: i metodi di gestione Agile
si basano sull’idea che cercare di predire il futuro di un progetto equivalga a spendere energie
100
inutilmente. Appurato che il progetto devierà inevitabilmente dalla pianificazione iniziale, a causa di
numerosi fattori, l’approccio agile prevede di abbracciare il cambiamento durante il processo invece
di investire tempo per cercare di pianificare ogni singolo dettaglio.
Il manifesto Agile e i principi in esso descritti non danno nessuna specifica sul tipo di metodologia Agile da
utilizzare; il loro obiettivo è quello di fornire una guida che aiuti le persone ad avvicinarsi all’approccio Agile
e a comprenderne le caratteristiche (55).
4.2.2 Fasi di un Progetto Agile
I progetti Agile si sviluppano in quattro fasi: studio di fattibilità, pianificazione, implementazione, consegna e
chiusura. Queste diverse fasi possono caratterizzare anche i progetti non Agile ma ciò che differenzia questi
ultimi da un progetto tradizionale è il modo in cui le diverse fasi vengono eseguite. Di seguito se ne presenta
una descrizione più approfondita (50).
4.2.2.1 Studio di fattibilità
Lo studio di fattibilità in un progetto Agile dovrebbe comprendere tre importanti step.
Il primo step consiste nell’effettuare una meticolosa analisi degli stakeholders di progetto, al fine di mappare
quali persone in quale organizzazione abbiano la capacità di rispondere a diversi generi di domande. Questa
analisi deve essere prodotta velocemente e con risultati visibili e, per questo, ci si focalizza più sulla
comunicazione che sul produrre documentazione.
Il secondo step è quello di produrre un documento dell’idea. Il documento dovrebbe includere la visione del
progetto, l’insieme delle operazioni che è necessario svolgere con la relativa modalità di esecuzione, lo scopo
del progetto, la specifica del tempo necessario al completamento ed il budget. L’elaborato dovrebbe essere
il più breve e conciso possibile, semplice da comprendere, non troppo elaborato per evitare incomprensioni
e corredato da materiale grafico. Non essendo spiegati tutti i piccoli dettagli all’interno del progetto, la
comunicazione risulta nettamente più chiara e lascia aperte diverse possibili strade da percorrere per
raggiungere la visione del progetto; se la spiegazione del progetto fosse infatti troppo dettagliata, si
chiuderebbe la porta ad eventuali valutazioni su ulteriori possibili soluzioni.
Il terzo step dell’analisi di fattibilità prevede di sviluppare un piano di comunicazione. Uno dei principi del
manifesto Agile è quello di dare priorità alla comunicazione piuttosto che alla documentazione ma per
rendere questo principio davvero efficace si dovrebbero stabilire le regole base della comunicazione già nelle
101
prime fasi del progetto. La gestione Agile promuove incontri fisici, che permettano ai membri di interfacciarsi
faccia a faccia, limitando così i casi di incomprensioni e fraintendimenti. Gli incontri devono essere effettuati
regolarmente e con continuità, in modo che tutti sappiano dell’impegno, a cadenza settimanale ad esempio,
evitando di prendere impegni e di non partecipare. È comunque molto importante che le persone coinvolte
negli incontri non siano forzate a farlo e ne condividano gli scopi; in caso contrario gli stessi incontri fisici,
fortemente promossi da Agile, risulterebbero inefficaci. L’importanza di un piano di comunicazione è
conseguenza anche del sovraccarico di informazioni di cui molti progetti soffrono, condizione che rende
fondamentale stabilire, già dai primi momenti, quali persone necessitino di quali informazioni, in modo da
poterne gestire il flusso ed evitare confusione.
4.2.2.2 Pianificazione
La grande differenza tra la pianificazione con metodologie Agile e tradizionali è rappresentata dall’arco
temporale che coinvolge il processo di pianificazione. I modelli tradizionali intendono il successo del progetto
tanto maggiore quanto più alto è il livello di dettaglio della pianificazione del progetto. Al contrario, le
metodologie Agile considerano impossibile prevedere il futuro e, per questo, impostano la programmazione
su diversi livelli con un livello di dettaglio via via crescente:
• Idea (Vision): il documento dell’idea, già descritto nello studio di fattibilità, deve contenere l’idea del
progetto, cosa deve essere fatto e in che modo; la descrizione dei contenuti deve essere semplice
affinchè tutti gli attori coinvolti nel progetto sappiano quali siano le caratteristiche del progetto che
stanno affrontando e gli obiettivi da raggiungere.
• Piano d’azione (Road map): la sua funzione è quella di visualizzare quali siano i risultati parziali
richiesti per portare a successo il progetto e in quale ordine sia necessario raggiungerli. I due
strumenti solitamente utilizzati a tale scopo sono: la Product Brackdown Structure (PBS), che
scompone il progetto per obiettivi da raggiungere e conseguire, e i Logical Network, che esprimono
l’ordine con cui i risultati parziali devono essere realizzati.
• Piano di consegna (Delivery plan): il livello introduce i limiti di tempo esatti e le date specifiche.
L’attenzione non ricade sulla pianificazione dell’intero progetto ma su quella di parti specifiche che
si ritiene possano generare valore per il progetto. Se comparato con i metodi tradizionali, le singole
parti descritte corrispondono alle diverse milestone del progetto.
• Piano del ciclo (Cycle plan): l’intero progetto è suddiviso in cicli brevi, al termine dei quali il gruppo
di lavoro dovrebbe aver prodotto dei risultati utili. Affinché ciò avvenga, la durata di ogni ciclo deve
102
essere compresa tra un minimo di una settimana ed un massimo di sei settimane; i fondatori di
Scrum, Ken Schwaber e Jeff Sutherland, dicono che la durata ideale dovrebbe essere di 30 giorni (56).
• Piano giornaliero (Daily plan): il suo obiettivo è quello di programmare le attività che devono essere
svolte nell’imminente periodo, definendo anche le persone responsabili della loro esecuzione.
Il Piano giornaliero, il Piano del ciclo e il Piano di consegna dovrebbero essere continuamente aggiornati
durante lo sviluppo del progetto. L’idea e il Piano d’azione sono invece creati all’inizio del progetto e non
devono subire nessuna revisione durante il suo sviluppo. Tutti i piani, ad eccezione del Piano giornaliero,
sono redatti durante la fase iniziale del progetto.
4.2.2.3 Implementazione
I progetti Agile, come quelli tradizionali, presentano un processo che definisce come eseguire il lavoro e una
serie di strumenti che supportano il processo. Uno dei più importanti strumenti nei progetti Agile è il Project
Board, il cui obiettivo è quello di visualizzare come progredisce il progetto. Le diverse attività vengono
posizionate in una delle tre colonne: “da fare”, “iniziato”, “finito”.
All’inizio di ogni ciclo tutte le attività sono poste nella prima colonna; successivamente, ogni membro del
gruppo sposta, una volta iniziata, la prioritaria attività di cui è responsabile nella seconda colonna. L’utilizzo
dello strumento può essere implementato aggiungendo, per esempio, dei post-it rossi in corrispondenza
delle attività che riscontrano dei problemi, che spieghino il motivo per il quale non si sia ancora conclusa.
Un’altra soluzione è quella di includere una quarta colonna, tra la seconda e la terza, chiamata “da testare”,
nella quale includere tutte le attività che sono state completate ma che necessitano di revisione o test da
parte di una persona più competente.
La Figura 24 rappresenta una Project Board, con le tre colonne: to do (da fare), doing (iniziato), done (finito).
Figura 24- Esempio di Project Board, costituito da tre colonne, rispettivamente destinate ad attività "da fare", "iniziate" e "concluse".
103
La fase di implementazione del progetto comprende anche degli incontri, che contraddistinguono i metodi
Agile dalle metodologie tradizionali. I diversi tipi di incontri e le figure che in essi intervengono sono proprie
del metodo Agile Scrum e saranno presentate nel dettaglio nel Paragrafo 4.3.
4.2.2.4 Consegna e chiusura
La fase di consegna e chiusura dei progetti Agile non differisce molto rispetto a quella dei progetti gestiti con
metodi tradizionali. Ciò che però distingue le due tipologie di progetto è che durante lo sviluppo di un
progetto Agile sono costantemente prodotti, revisionati ed approvati i risultati parziali, cosa che potrebbe
rendere più semplice la consegna del progetto vista la maggiore preparazione e consapevolezza del ricevente.
104
4.3 La metodologia Scrum
Per implementare l’Agile Project Management sono state introdotte numerose metodologie. La Figura 25
mostra il tasso di utilizzo delle diverse metodologie Agile, verificato attraverso un questionario e illustrato
nell’ultimo “Annual State of Agile Report” di VersionOne.
Figura 25 - Utilizzo delle diverse metodologie Agile sul mercato (47)
Nel presente paragrafo si analizzerà più nel dettaglio la metodologia Scrum, che risulta essere quella più
largamente diffusa sul mercato grazie alla sua semplicità e flessibilità.
Nel 1986, Hirotaka Takeuchi e Ikujiro Nonaka descrivono, per la prima volta la metodologia Scrum, un nuovo
approccio olistico che avrebbe aumentato la flessibilità e la velocità nello sviluppo dei nuovi prodotti in
commercio. I due autori definiscono quella di Scrum come una “strategia flessibile e olistica allo sviluppo di
un prodotto, dove il team di sviluppo lavora come un’unica entità per raggiungere un obiettivo comune, in
opposizione all’approccio sequenziale delle metodologie tradizionali” (57).
Il termine “Scrum” è utilizzato solitamente nel gioco del Rugby per descrivere la fase di un incontro in cui
l'arbitro ordina la ripresa del gioco tra due gruppi ordinati di giocatori contrapposti, uno per
squadra. Hirotaka Takeuchi e Ikujiro Nonaka paragonano un team di sviluppo ad una squadra di rugby perché
l’ambiente di sviluppo, caratterizzato da requisiti che cambiano ed evolvono continuamente, può essere
paragonato al disordine che si origina in un campo da rugby quando si crea una mischia. Quindi, come i
105
componenti della squadra di rugby cercano di vincere la partita provando ad andare compatti nella stessa
direzione, così il team di sviluppo deve muoversi unito per raggiungere insieme gli obiettivi.
Di seguito saranno presentate le caratteristiche principali della metodologia Scrum, analizzandone le figure
coinvolte, la documentazione prodotta e il modo in cui gli attori interagiscono durante i diveri tipi di meeting.
Nella Figura 26 sono riassunte le caratteristiche peculiari della metodologia Scrum, nel seguito approfondite:
il ciclo di vita Scrum; il Team Scrum, ovvero gli attori del processo; gli Eventi Scrum cioè le diverse tipologie
di meeting; gli artefatti Scrum, ovvero i documenti prodotti durante il ciclo del processo.
Figura 26 - Riassunto dei principi di Scrum: Team Scrum, Meeting, Documentazione (58)
4.3.1 Il ciclo di vita Scrum
Scrum suddivide l’intero processo di sviluppo in tre fasi principali: la fase di Pre-game, la fase di Development
e infine quella di Post-game (54).
Nella fase del Pre-game vengono raccolte le richieste del cliente nel documento del Product Backlog, un
artefatto di Scrum che raccoglie tutti i requisiti noti del progetto. Ai requisiti, stabiliti dal cliente e dal Team
di sviluppatori, è associata una priorità e una stima di sviluppo. Il Product Backlog è in continua evoluzione e
subisce un aggiornamento ogni volta che vengono identificati dei dettagli aggiuntivi o quando le priorità di
sviluppo dei componenti della lista vengono modificate. Nella fase del Pre-game vengono inoltre definiti il
Team Scum, le risorse necessarie durante lo sviluppo e, infine, standard, convenzioni, architettura e
tecnologia su cui si baserà il prodotto realizzato.
106
La fase del Development, conosciuta anche come fase di Game, rappresenta la fase principale dell’intero
processo. Questa fase è costituita da una successione di Sprint, cicli iterativi durante i quali le funzionalità
vengono implementate valutando e aggiustando costantemente le diverse variabili di progetto, con lo scopo
di raggiungere la flessibilità necessaria a rispondere ai cambiamenti imprevisti.
All’inizio di ogni ciclo, durante la riunione del Team Scrum si produce lo Sprint Backlog, documento che
raccoglie le funzionalità del Product Backlog che dovranno essere realizzate nello Sprint. Essendo ogni Sprint
di una durata fissa, compresa tra una e quattro settimane, gli elementi inseriti nello Sprint Backlog dovranno
essere scelti in base alla loro priorità e alle stime di sviluppo stabilite in precedenza.
Ogni giorno è prevista una brevissima riunione, chiamata Daily Scrum Meeting, in cui gli sviluppatori si
aggiornano sullo stato del progetto. Se durante la fase di Development emergessero nuovi requisiti, espressi
dal cliente o causati da particolari scelte di progettazione, sarebbe necessario aggiornare il Product Backlog
e rivedere le priorità e le stime di sviluppo; i nuovi elementi inseriti potranno venire considerati solo nel
successivo Sprint.
Al termine di ogni Sprint, si ottiene un incremento funzionante del prodotto finale. Se i punti contenuti nello
Sprint Backlog non dovessero essere tutti conclusi, si dovrebbe procedere al loro inserimento nello Sprint
successivo. La fase di Development termina quando nel Product Backlog non vi sono più elementi da
implementare.
La fase di Post-game rappresenta la fase finale del processo. Una volta completati tutti i requisiti del cliente,
si effettuano gli ultimi test e, una volta superati, l’applicazione viene rilasciata al cliente assieme alla relativa
documentazione.
Nella Figura 27 è raffigurato il ciclo di vita dello Scrum così come appena descritto.
Figura 27- Ciclo di vita di Scrum (59)
107
4.3.2 Gli attori del processo: il Team Scrum
Il Team Scrum è formato dal Product Owner, Il Team di sviluppo (Development Team) e da uno Scrum Master.
I Team Scrum sono auto-organizzati e, quindi, scelgono autonomamente come meglio compiere il lavoro
organizzandosi e coordinandosi al proprio interno; hanno inoltre tutte le competenze tecniche necessarie
per realizzare il lavoro senza dover dipendere da nessuno al di fuori del team. Il modello di team in Scrum è
progettato per ottimizzare la flessibilità, la creatività e la produttività. I Team Scrum rilasciano i prodotti in
modo iterativo e incrementale, cosa che rende sempre disponibile una versione potenzialmente utile del
prodotto funzionante.
In uno dei primi articoli scritti con l’obiettivo di approfondire il framework Scrum, Schewaber e Beedle
introducono l’insieme di ruoli assegnati ai diversi partecipanti allo sviluppo del progetto, con lo scopo di
definirne le diverse responsabilità (60).
• Scrum Master: è la persona, individuabile anche all’interno del team, con il compito di assicurarsi
che il team di sviluppo aderisca ai valori, alle pratiche e alle regole di Scrum. In pratica, aiuta il team
a strutturarsi nel modo previsto da Scrum, inducendo all’auto-organizzazione e al pensare in termini
agili e dinamici. Si occupa inoltre di rimuovere qualsiasi tipo di impedimento che ostacoli la buona
riuscita del progetto, mettendo il team nelle condizioni di essere quanto più produttivo possibile.
• Product Owner: è il responsabile del progetto e rappresenta il punto di vista del cliente. I suoi compiti
sono quelli di controllare che le attività vengano svolte correttamente e di gestisce le priorità delle
attività del team, prendendo le decisioni strategiche relativamente al Product Backlog.
• Team di sviluppo: è il gruppo di persone che ha il compito di implementare e realizzare il prodotto
ed ha sia l’autorità di prendere un gran numero di decisioni, sia quella di richiedere che alcuni
impedimenti vengano rimossi. Il gruppo di sviluppo di Scrum possiede due principali caratteristiche
che lo distinguono dai team tradizionali.
In primo luogo, Scrum propone l’auto-organizzazione del team di sviluppo; i membri possono
prendere decisioni e le responsabilità in capo ad ognuno aumentano l’impegno generale per merito
del diffuso sentimento di appartenenza al progetto (61).
In secondo luogo, per poter gestire il team in modalità Scrum, il numero di membri deve essere
compreso tra cinque e nove persone; nel caso di più componenti viene suggerito di creare team
multipli. Esistono casi in cui Scrum è stato applicato a team di sviluppo di centinaia di persone ma in
questi casi è stato applicato lo “Scrum of Scrum Meeting” (62), suddividendo il gruppo principali in
gruppi con al massimo dieci componenti.
108
4.3.3 Gli eventi di Scrum
Lo Sprint è un'unità di base dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro
settimane.
Prima dell’inizio di ogni Sprint, viene fissata una riunione di pianificazione in cui vengono identificati gli
obiettivi e stimati i tempi. Durante questo incontro, il Product Owner comunica al team quali siano i punti
prioritari tra quelli presenti nel documento del Product Backlog, ovvero quelli che vorrebbe fossero
completati durante lo Sprint. Il team determina quanti dei punti prioritari pensa di poter completare durante
lo Sprint successivo e registra il dato nel documento dello Sprint Backlog (60). Durante uno Sprint gli obiettivi
devono restare invariati ed eventuali modifiche, che in ogni caso riguarderanno lo Sprint successivo, devono
essere rimandate alla successiva riunione di pianificazione.
Al termine di ogni Sprint, il team di sviluppo consegna una versione potenzialmente completa e funzionante
del prodotto, contenente gli avanzamenti specificati nella riunione di pianificazione dello Sprint appena
concluso.
Gli eventi previsti, ovvero i meeting tra gli attori del processo, sono utilizzati in Scrum per creare regolarità e
ridurre al minimo la necessità di riunioni non definite dalla metodologia. Gli eventi di Scrum hanno tutti una
durata di tempo massima prestabilita e questo assicura che una quantità appropriata di tempo sia dedicata
alla pianificazione, senza sprechi di tempo (56). Gli eventi in Scrum sono progettati per consentire
trasparenza critica ed ispezione e sono quindi occasioni formale per ispezionare e adattare qualcosa.
Gli eventi principali contenuti all’interno dello Sprint sono: Sprint Planning Meeting, Daily Scrum Meeting,
Sprint Review Meeting e Sprint Retrospective Meeting. Di seguito si propone una descrizione di ognuno degli
eventi citati (56).
4.3.3.1 Sprint Planning Meeting
Lo Sprint Planning Meeting è la riunione fissata all’inizio di ogni ciclo di Sprint. Si tratta di un incontro della
durata di otto ore per uno Sprint di un mese; per Sprint più brevi, l'evento è proporzionalmente più rapido e
dura, ad esempio, quattro ore per uno Sprint di due settimane.
L’evento dello Sprint Planning Meeting si compone di due fasi. Durante la prima fase, a cui partecipa tutto il
Team Scrum, vengono decisi gli obiettivi e le funzionalità del prossimo Sprint; nella seconda fase, a cui
partecipano lo Scrum Master e il Team di sviluppo, vengono stabiliti i dettagli tecnici su come verrà
implementato l’incremento durante il successivo Sprint.
109
In conclusione lo Sprint Planning Meeting prevede lo svolgimento dei seguenti punti:
• selezionare il lavoro da fare durante lo Sprint;
• preparare con tutta la squadra lo Sprint Backlog che dettagli il tempo necessario per fare quel lavoro;
• identificare la maggior parte del lavoro che è probabile sia realizzato durante l'attuale Sprint.
4.3.3.2 Daily Scrum Meeting
Ogni giorno, durante lo Sprint, si tiene il Daily Scrum Meeting, a cui partecipano lo Scrum Master e i
componenti dei Team di Sviluppo. L’incontro dovrebbe avvenire ogni giorno nello stesso luogo alla stessa
ora, in modo che tutti i partecipanti sappiano dell’impegno e possano parteciparvi. Durante l’incontro
quotidiano si discute di:
• cosa è stato fatto in più rispetto alla riunione precedente;
• cosa si pensa di fare prima della riunione successiva;
• eventuali ostacoli o impedimenti riscontrati.
Gli eventuali impedimenti durante l’incontro vengono documentati dallo Scrum Master, che farà in modo di
risolverli al di fuori dell’incontro.
La durata dei Daily Scrum Meeting è solitamente di 15 minuti al massimo e le persone che intervengono sono
solitamente quelle con ruoli principali. Chi vi partecipa lo fa in piedi, evitando di prendere posto ad un tavolo,
il che obbliga i partecipanti a concentrare la discussione sulle questioni più importanti e sul lavoro da
svolgere, piuttosto che distrarsi ed isolarsi come accade nelle riunioni "tradizionali".
Il Daily Scrum Meeting rappresenta un incontro chiave d'ispezione e adattamento poiché migliora le
comunicazioni, identifica e rimuove gli ostacoli allo sviluppo, evidenzia e promuove il rapido processo
decisionale e migliora il livello di conoscenza del progetto da parte del Team di Sviluppo.
4.3.3.3 Sprint Review Meeting
Alla fine dello Sprint si tiene lo Sprint Review Meeting, a cui partecipano il Team di Sviluppo e gli stakeholders.
L’incontro ha l’obiettivo di ispezionare l'incremento, di adattare, se necessario, il Product Backlog e di definire
le successive attività da svolgere. Lo Sprint Review Meeting è un incontro informale e la presentazione
dell'incremento ha lo scopo di suscitare commenti e promuovere la collaborazione tra il Team di Sviluppo e
gli stakeholders.
110
La durata dell’incontro è al massimo di quattro ore per uno Sprint di un mese; per Sprint più brevi la durata
diminuisce proporzionalmente e, ad esempio, è pari a due ore per uno Sprint di due settimane.
In conclusione, durante lo Sprint Review Meeting vengono affrontati i seguenti punti:
• il Product Owner identifica ciò che è stato portato a termine e ciò che ancora non è completo;
• il Team di Sviluppo discute su cosa sia andato bene durante lo Sprint, su quali problemi si siano
riscontrati e su come siano stati risolti;
• Il Team di Sviluppo mostra il lavoro concluso e risponde alle domande sull'incremento;
• Il Product Owner discute il Product Backlog allo stato attuale, identificando la possibile data di
completamento in base alla misura del progresso fino a quel momento raggiunto;
• l'intero Team Scrum collabora su cosa fare nello Sprint successivo.
4.3.3.4 Sprint Retrospective Meeting
Dopo lo Sprint Review Meeting e prima del successivo Sprint Planning Meeting, il Team Scrum si riunisce per
lo Sprint Retrospective Meeting, durante il quale il Team Scrum ha l’occasione di ispezionare sé stesso e di
creare un piano di miglioramento per lo Sprint successivo. Lo scopo dello Sprint Retrospective Meeting è di:
• esaminare criticamente l’andamento dell'ultimo Sprint, in termini di relazioni, processi e strumenti;
• identificare e ordinare gli elementi di maggior successo e il potenziale di miglioramento;
• creare un piano per attuare miglioramenti al modo di lavorare del Team Scrum.
L’obiettivo principale dello Sprint Retrospective Meeting è quello di fornire un’occasione all’intero Team
Scrum di focalizzarsi sull’ispezione, sull’auto-analisi e sulle possibilità di miglioramento, al fine di migliorare
il lavoro dello Sprint successivo. La durata della riunione è di tre ore, per Sprint della durata mensile; in modo
proporzionale è allocato meno tempo per Sprint più brevi.
111
4.3.4 Gli artefatti di Scrum
Gli artefatti di Scrum rappresentano la documentazione necessaria per massimizzare la trasparenza delle
informazioni necessarie al Team Scrum per l’implementazione.
Nella Figura 28 è rappresentata una schematizzazione del processo di Scrum, che mette in evidenza la
sequenza dei meeting, la documentazione prodotta e i momenti in cui i diversi membri del Team Scrum si
trovano ad essere coinvolti. Di seguito saranno analizzati più nel dettaglio e descritti i due documenti più
importanti in Scrum: il Product Backlog e lo Spring Backlog.
Figura 28 - Ciclo di Scrum: meeting, documenti e attori coinvolti nel processo (47)
4.3.4.1 Product Backlog
Il product backlog è il documento che contiene la lista ordinata dei requisiti relativi ad un prodotto. I requisiti
vengono tradotti attraverso i Product Backlog Item (PBI), ai quali il Product Owner associa un valore di priorità
in base a rischio, valore di business e tempistiche di consegna.
Le funzionalità aggiunte al Product Backlog sono comunemente scritte utilizzando il formato delle "user-
story". Una story definisce in maniera non dettagliata una funzionalità che un software deve avere e che dà
valore al prodotto finale consegnato al cliente. Una story permette di descrivere ed evidenziare l’importanza
112
e l’impatto che una funzionalità avrà nel business, aiuta a far capire al cliente l’utilità della stessa funzione e
la sua priorità, fino a portare, in alcuni casi, alla rinuncia della sua realizzazione.
Il Product Backlog contiene delle stime approssimative sia del valore di business che dello sforzo necessario
a svilupparle. La metodologia che si adotta per il calcolo di quanti “story points” assegnare ad una story
prevede i seguenti passaggi (63):
• si seleziona una scala di valori con cui valutare le story (gli obiettivi);
• si prende come campione una story che viene ritenuta di media difficoltà e le si assegna il valore
medio della scala di valori scelta;
• si analizza ogni altra story, la si confronta con quella di riferimento e le si assegna un punteggio in
story points.
Il Product Backlog e la definizione del valore di business associato a ciascuna voce è responsabilità del Product
Owner; lo sforzo stimato per completare ciascun voce, valutato mediante l’attribuzione di story-points alle
user-story, è invece determinato dal Team di sviluppo.
In conclusione, il Product Backlog rappresenta “cosa” deve essere fatto, organizzato in base all'ordine relativo
in cui dovrà essere realizzato. Il documento non è mai completo e subisce modifiche durante lo sviluppo del
progetto; il Product Owner è il responsabile ultimo della sua gestione e delle priorità da dare alle story nel
Product Backlog per il Team di sviluppo.
4.3.4.2 Sprint Backlog
Lo Sprint Backlog è la lista del lavoro che il Team di sviluppo deve portare avanti nel corso dello Sprint. La
lista viene generata selezionando, a partire dall’apice della lista e seguendo quindi i criteri di priorità, la
quantità di story che il Team di sviluppo ritiene di poter realizzare durante lo Sprint.
Nel momento in cui si selezionano le story per il nuovo Sprint, il Team di sviluppo dovrebbe tener conto della
velocità media ottenuta durante gli Sprint precedenti, definita anche velocità di sviluppo; il valore
dell’indicatore si ottiene sommando gli story points di tutte le story portate a termine nel corso
dell’iterazione. Conseguenza di questo indicatore è che, durante lo Sprint Planning Meeting, si prenderanno
in considerazione le attività, tra quelle a più alta priorità, la cui somma degli story points è inferiore o uguale
al valore di velocità individuato; le stesse attività saranno poi inserite all’interno dello Sprint Backlog (63).
113
Figura 29 - Velocity chart. In blu è rappresentato il lavoro che il Team ipotizza di poter fare durante lo Sprint, il verde rappresenta il
reale lavoro prodotto durante lo Sprint (64)
All’interno del documento, le story sono suddivise dal Team di sviluppo in attività (task); questo livello di
dettaglio consente al Team di sviluppo di comprendere meglio cosa fare e di farsi carico di un'attività della
lista. I compiti e le attività da svolgere non vengono mai imposte o assegnate ai vari membri del team, ma
sono i singoli membri che, durante il Daily Scrum Meeting, si prendono la responsabilità dello svolgimento di
una task; questo approccio promuove l'auto-organizzazione e la responsabilizzazione degli sviluppatori.
Lo Sprint Backlog è di proprietà del Team di sviluppo e tutte le stime in esso contenute sono effettuate dal
team stesso. Per visualizzare i cambiamenti di stato, e quindi l’avanzamento, delle task nello Sprint corrente,
spesso il Team di sviluppo fa ricorso alle task board, sviluppate su tre colonne: to do (da fare), doing (iniziato),
done (finito).
4.3.4.3 Burndown Chart
Un Burndown Chart è uno strumento utilizzato per valutare l’andamento del lavoro svolto e da svolgere e
per migliorare le stime future per la produzione di nuovi incrementi. Consiste in un diagramma cartesiano in
cui sono indicati sull'asse X i giorni dello Sprint e sull'asse Y i giorni di effort.
Una volta stabilità la velocità di sviluppo del lavoro del Team di sviluppo, i Burndown Chart consentono di
monitorare l'andamento dello Sprint. La costruzione del grafico si basa sui seguenti passi:
• si traccia, giorno per giorno, la linea ideale di effort erogabile in base alla velocità di sviluppo stabilita;
• si traccia, sempre giorno per giorno, la linea dei giorni che mancano alla consegna dello Sprint;
114
• si verifica quale sia la posizione della linea dei giorni che mancano alla consegna rispetto alla linea
ideale di effort. Qualora la linea dei giorni che mancano alla consegna si collocasse al di sopra di
quella ideale di effort, il progetto sarebbe in ritardo e sarebbero necessarie analisi ulteriori per
adottare adeguate azioni correttive.
In ottica di trasparenza, il grafico deve essere visibile da chiunque, ma è opportuno indicare in maniera chiara
la situazione di eventuale ritardo o anticipo del progetto anche per coloro i quali non siano in grado di leggere
i dati del grafico.
Nella seguente Figura 30 è riportato un esempio di Burndown Chart: la linea blu rappresenta la stima del
lavoro ancora da completare, la linea rossa evidenzia l’effettivo lavoro mancante. Rispetto a quanto detto, si
evince che tra il terzo e il settimo giorno circa il progetto è in ritardo rispetto a quanto previsto; al contrario,
nei primi tre giorni e negli ultimi tre si verifica una situazione di anticipo.
Figura 30 - Esempio di Burndown Chart (59)
115
4.4 La metodologia Kanban
Il termine Kanban, che Giapponese significa “Insegna”, è un altro framework che consente di applicare i
principi di Agile Project Management. Nella letteratura riguardante il tema Kanban, alcuni moderni autori
differenziano i termini “kanban” e “Kanban”: il primo, scritto in lettere minuscole, si riferisce all’uso di
cartellini come segnalatori visuali per la realizzazione di sistemi “pull”; il secondo, scritto con la prima lettera
maiuscola, è un framework che guarda al sistema produttivo, individua i “colli di bottiglia” ovvero i punti
critici e favorisce il potenziamento dei dipendenti e il miglioramento continuo. (65).
La metodologia Kanban, introdotta da Toyota negli anni ’50, si basa su una logica organizzativa di tipo “pull”,
secondo cui occorre produrre solo ciò che è stato già venduto o che si prevede di vendere in tempi brevi, che
si contrappone al metodo di produzione “push”, tipico della catena di montaggio della Ford, che punta a
produrre prodotti finiti per il magazzino in attesa di essere venduti. Al contrario dei sistemi di produzione
“push”, che puntavano sulla produzione di massa, la metodologia Kanban si propone di analizzare i fabbisogni
dei consumatori e di soddisfarli attraverso la produzione di un bene nelle corrette quantità.
La metodologia Kanban si inserisce in un tipo di produzione Just in Time (JIT), espressione inglese che significa
"appena in tempo". Il Just in Time è una filosofia di programmazione della produzione che si basa sul principio
fondamentale per cui gli approvvigionamenti avvengono nel momento in cui l’azienda ne ha bisogno; questo
approccio consente di avere la quantità minima indispensabile di materie prime appena in tempo per
produrre un determinato prodotto, limitando al massimo le scorte in magazzino.
4.4.1 Kanban cards
L’idea originale dei sistemi Kanban era quella di attaccare dei cartellini fisici, detti kanban, ad ogni pezzo di
lavoro svolto nella fabbrica e limitare la quantità di kanban disponibili in funzione della capacità produttiva.
In questo modo, ogni nuovo ordine sopraggiunto quando non vi erano più kanban disponibili veniva salvato
in buffer fino al rilascio di altre risorse. Quando la domanda risultava maggiore rispetto alla capacità
produttiva, i buffer iniziavano a crescere, rendendo necessaria una riorganizzazione del sistema produttivo
affinché questo reagisse alla domanda crescente. (66)
I sistemi Kanban danno la possibilità di avere un quadro generale della produzione raccogliendo tutte le
kanban card disponibili e posizionandole, sotto forma di post-it, cartoncini di colore diverso o scritte di
diverso colore, su una lavagna che rappresenta il processo di produzione.
Di seguito sono riportati i passi più importanti da seguire per costruire una lavagna Kanban e con essa gestire
il processo di produzione in maniera ottimale.
116
4.4.1.1 Progetto della Kanban board
Il primo passo per la realizzazione di una lavagna Kanban consiste nel raccogliere su un pannello tutti i
cartellini, o kanban, corrispondenti alle attività che si vogliono gestire.
Per poter comprendere meglio lo stato attuale del lavoro all’interno dell’organizzazione è utile mappare il
processo di lavorazione, posizionando i cartellini relativi alle attività in tre colonne distinte:
• To Do (da fare): contiene i compiti e le attività da iniziare;
• In Progress (in lavorazione): sono inseriti i compiti contestualmente in elaborazione;
• Done (fatto): comprende i compiti eseguiti o conclusi.
Il passo successivo consiste nel dettagliare maggiormente il processo, suddividendo la fase di lavorazione (in
progress); solitamente si introducono le colonne relative agli step normalmente compiuti da un team di
sviluppo software: analisi, sviluppo, test e deploy (run).
Ogni fase di lavorazione può poi essere ulteriormente suddivisa in modo da introdurre, per le varie fasi, delle
aree di “parcheggio” per le task (i cosiddetti buffer). Per ognuna delle fasi si introducono quindi due colonne:
dopo aver completato il proprio lavoro ogni membro del team colloca il cartellino corrispondente nella
seconda colonna (done), quella delle attività completate, in attesa che venga preso in lavorazione (doing)
nella fase successiva.
Infine, sulle varie fasi del ciclo di lavorazione possono essere introdotti dei limiti al numero di attività che si
possono svolgere contemporaneamente in parallelo ovvero introducendo il limite WIP (Work in Progress).
Limitare il flusso delle attività svolte permette di stabilizzare un flusso di lavorazione, impendendo che si
creino accumuli (“colli di bottiglia”) in alcuni punti del ciclo di lavorazione e che altri siano completamente
scariche; il sovraccarico e lo sbilanciamento del flusso sono infatti due fenomeni da evitare, poiché riducono
di molto le performance del sistema di produzione.
La Figura 31 rappresenta la forma del Kanban board dettagliato nel modo appena descritto. La fase di
lavorazione è suddivisa nelle quattro colonne centrali, che identificano gli step compiuti dal team di sviluppo;
ogni fase di lavorazione, alla quale è associato un limite WIP, è a sua volta suddivisa in altre due colonne,
nelle quali posizionare le singole attività in svolgimento o in buffer.
117
Figura 31 - Costruzione del Kanban board: suddivisione, dettaglio, limite WIP (67)
4.4.1.2 Simulazione di processo
La Figura 32 rappresenta i diversi passi da svolgere per la gestione di un tipico processo di lavorazione
attraverso le Kanban board. Di seguito saranno brevemente descritti i diversi step:
• Step 1: la situazione iniziale è quella di partenza, in cui tutte le attività da svolgere sono posizionate
nella colonna “To Do” perché ancora non iniziate e prese in carico.
• Step 2: il primo passo è quello di mettere in lavorazione due attività nella prima fase di analisi.
Essendo il limite WIP pari a 2, l’operazione può essere compiuta.
• Step 3: dopo aver completato l’analisi di una delle due attività, questa andrà posizionata nella
colonna “done” delle cose fatte, pronta per essere presa in lavorazione (“doing”) nella fase di
sviluppo. Avendo spostato l’attività nella colonna “done”, si libera un limite WIP sulla colonna “doing”
dell’analisi e sarà quindi possibile mettere in lavorazione in analisi una nuova attività.
• Step 4: l’attività salvata in buffer viene presa in carico e posizionata nella colonna “doing” della
lavorazione in sviluppo. Come visto nello step precedente, l’attività di cui è stata completata l’analisi
viene posizionata nella colonna “done”, in attesa che venga presa in carico per la lavorazione in
sviluppo; avendo spostato l’attività nella colonna “done”, si libera un limite WIP sulla colonna “doing”
dell’analisi e sarà quindi possibile mettere in lavorazione in analisi una nuova attività.
• Step successivi: il processo continua nella stessa logica e i vari task si spostano in orizzontale verso
destra dando vita ad un vero e proprio flusso di lavorazione. Le attività completate verranno
118
posizionate nella colonna “done”, pronte ad essere prese in carico nella fase successiva; l’aggiunta di
nuove attività nella colonna “doing” di ogni singola fase è vincolata al limite WIP imposto, in modo
che, una volta raggiunto il limite in ogni colonna, il sistema tenda a saturarsi impedendo ulteriori
inserimenti in lavorazione.
Figura 32 - Simulazione di gestione di un tipico processo di lavorazione; le frecce rosse indicano la sequenza dei passaggi descritti
119
4.4.1.3 Avatar del team
Un modo efficace per migliorare il controllo del flusso di lavorazione è quello di utilizzare delle icone
rappresentanti i vari membri del team da apporre sui cartellini delle diverse attività. Le icone possono essere
delle foto, dei disegni astratti o delle figure di fantasia e sono solitamente posizionate in un apposito spazio
creato sulla lavagna.
Quando un membro del team prende in carico un’attività, preleva il proprio avatar e lo appone sul cartellino;
quando un’attività è terminata, e con essa anche il relativo lavoro del membro del team, l’avatar viene
riposizionato nell’apposito spazio della lavagna, in modo che sia riutilizzabile per altri compiti.
L'uso degli avatar permette di verificare in modo semplice ed immediato l'impegno dei membri del team sulle
varie attività e di coordinarne lo spostamento quando si presentano attività critiche che richiedono un rapido
intervento (in gergo swarming). In un team è necessario bilanciare in modo uniforme il lavoro tra i membri e
limitare il più possibile il numero di attività che ogni persone svolge in parallelo; in questo senso,
l'introduzione di un limite sul numero di avatar a disposizione per ogni membro del team riduce la naturale
tendenza che si ha di fare più cose contemporaneamente.
La Figura 33 mostra l’utilizzo degli avatar nei Kanban board: a sinistra si mette in evidenza l’area dedicata agli
avatar, in cui riposizionarli una volta terminata un’attività affinché possano essere riutilizzati; a destra gli
avatar sono posizionati nelle attività che i rispettivi membri del team hanno preso in carico.
Figura 33 - Utilizzo degli avatar nelle Kanban board e posizionamento sulle attività
La situazione ottimale sarebbe quella di avere dei team cross funzionali, ossia composti da persone capaci di
svolgere tutte le attività previste dal processo. In questo caso, le persone del team possono spostarsi fra le
attività posizionate nelle varie fasi, avendo le capacità di eseguirle, lavorando in coppia per velocizzarne la
lavorazione.
120
4.4.1.4 Emergenze e difetti
L’ordine con cui le diverse attività sono messe in lavorazione segue l’ordinamento che viene dato ai cartellini
nella colonna “To Do”, ordinata in funzione della priorità definita dal cliente.
Nonostante Kanban segua solitamente un ordine di priorità, può accadere che sia necessario gestire delle
emergenze improvvise che sovvertono l’ordine iniziale delle attività. In questi casi la metodologia prevede di
disegnare sulla Kanban board una “corsia di emergenza” (expedite lane), colorandola diversamente o
disegnando icone particolari come l’ambulanza o i camion dei pompieri, sulla quale far “viaggiare” le
emergenze, intendendole come attività che devono avere priorità rispetto a tutte le altre e
contrassegnandole con cartellini rossi o arancioni. Nei casi di emergenza, se necessario, i membri del team
interrompono il proprio lavoro per dedicarsi completamente alla lavorazione del cartellino e, dove possibile,
lavorano in coppia in modo da velocizzare il completamento del lavoro.
Nella Figura 34 è riportato un esempio di Kanban board adattata per la gestione delle emergenze, con la
“corsia di emergenza” e il cartellino dell’emergenza colorati in rosso.
Figura 34 - Kanban board con "corsia di emergenza" e attività contrassegnata con cartellino rosso ad indicarne la priorità
In alcuni casi, può accadere che, durante la lavorazione, il team si imbatta in un difetto del software o del
prodotto che sta sviluppando. Il difetto può essere gestito inserendolo come attività nel Product Backlog,
nella colonna delle altre cose da fare, eventualmente posizionandolo in cima all’elenco qualora si volesse
dare precedenza a questa task rispetto alle altre attività. Qualora la gravità e l’importanza del difetto fossero
tali da richiedere un immediato intervento a discapito dello sviluppo delle altre attività, basterebbe inserire
il difetto nella “corsia di emergenza” in modo che acquisisca priorità assoluta rispetto al resto.
121
4.4.1.5 Suddivisione del flusso di lavoro: scatter marge
Le varie colonne della Kanban board corrispondono ad una scomposizione verticale e sequenziale delle
attività del processo ed ogni colonna rappresenta una diversa fase del processo di lavorazione; per essere
completata, ogni attività deve passare per tutte le colonne della Kanban board.
Nei casi in cui una fase sia costituita da attività che devono necessariamente essere eseguite in parallelo, il
processo non può essere scomposto verticalmente. Si pensi per esempio ad un processo di lavorazione di un
componente che preveda lo sviluppo di quattro parti separate prima di potersi ritenere completo; in questo
caso lo sviluppo dovrebbe essere diviso in quattro linee di lavoro mentre il test potrebbe essere eseguito sul
componente solo dopo che tutte le varie parti siano state sviluppate e integrate.
Per poter gestire le attività in parallelo, la Kanban board viene modificata introducendo delle corsie
orizzontali solo nella colonna relativa alla fase interessata. La Figura 35 rappresenta un tipico caso di
scomposizione orizzontale di una fase in cui la colonna di sviluppo è stata scomposta in quattro parti, come
risposta all’esempio precedente. Come visibile a sinistra, in questa configurazione ogni cartellino arrivato
nella colonna di sviluppo verrà scomposto in quattro sotto-cartellini; a destra viene evidenziato come i sotto-
cartellini siano ricongiunti in un unico cartellino una volta terminato lo sviluppo. Solo dopo aver riunito i
sotto-cartellini in un’unica card, l’attività può ritenersi completa nella fase di sviluppo ed essere posizionata
nella colonna “done”, pronta per poter essere presa in carico nella fase successiva di test.
Figura 35 - Scomposizione del flusso di lavoro nel caso di attività che devono necessariamente essere svolte in parallelo
122
4.5 Confronto tra metodologie Agile e tradizionali
Gli approcci tradizionali al Project Management (Traditional Project Management – TPM), ampiamente
descritti nei documenti analizzati nel Capitolo 3, sono definiti “pesanti” e si contrappongono ai nuovi sistemi
“leggeri” proposti negli ultimi anni e raccolti nelle metodologie di Agile Project Management (APM).
Tra le varie metodologie tradizionali, la più famosa è quella del “modello a cascata” che struttura il processo
di realizzazione del prodotto in una sequenza lineare di fasi, ciascuna delle quali produce un preciso output
che viene utilizzato come input per la fase successiva (da cui la metafora della cascata); le fasi previste sono:
analisi dei requisiti, progetto, sviluppo, collaudo e manutenzione. Inizialmente molto utilizzato nell’industria
del software è stato oggi sostituito con modelli più dinamici e flessibili.
La rigidezza di questo sistema di gestione del processo è da ricercarsi in vari aspetti che caratterizzano i
metodi tradizionali. In primo luogo, le metodologie tradizionali prevedono una successione strutturata tra
diverse fasi, ognuna costituita da un insieme di attività che devono essere eseguite prima che inizi la fase
successiva. In secondo luogo, questo tipo di approccio prevede che vengano definiti e documentati tutti i
requisiti che caratterizzano il prodotto già nelle prime fasi del processo, quando in realtà le informazioni a
disposizione sono molto poche. Infine, la rigidezza dell’approccio tradizionale è da collegare ad una
pianificazione eseguita nel dettaglio e a lungo termine, con il difficile obiettivo di raggiungere il successo del
progetto.
A questo approccio rigido e orientato al processo (process oriented) si contrappongono le metodologie di
Agile Project Management che invece fa della capacità di adattamento al cambiamento un punto di forza,
dimostrandosi leggero e flessibile.
Secondo vari studi, quasi il 70% di tutti i progetti software falliscono, non raggiungendo gli obiettivi prefissati
in termini di tempo, costi e qualità. L’adozione delle pratiche Agile comporta, invece, un aumento del tasso
di successo dei progetti e la conseguente accettazione da parte dell’utente, una migliore gestione del rischio
e un prodotto di maggiore qualità, modellato sui requisiti reali proposti dal cliente.
Le metodologie Agile sono indicate per progetti con un alto livello di complessità ed incertezza, nei quali sono
inevitabili cambiamenti rispetto a quanto inizialmente programmato; si applicano in progetti per i quali non
è possibile definire con certezza, già nelle prime fasi, un insieme di requisiti da associare al prodotto finale
ma, al contrario, questi si trovano a cambiare nel corso dello sviluppo, come gli obiettivi.
Dopo aver analizzato nei paragrafi precedenti i principi di Agile Project Management e delle metodologie che
utilizzato l’approccio Agile, in questo paragrafo sarà effettuato un confronto più dettagliato tra Agile Project
Management e il Project Management tradizionale, evidenziandone differenze e similitudini.
123
4.5.1 Ciclo di vita dello sviluppo
Una prima differenza, relativa al ciclo di vita dello sviluppo, tra modelli tradizionali ed Agile riguarda l’attività
di programmazione.
La pianificazione in Agile è fatta su livelli differenti e viene condotta su piccole parti di processo, non sul suo
intero sviluppo; per garantire la consegna del prodotto nell’arco di tempo prefissato, le porzioni di processo
che vengono ad essere pianificate devono essere quanto più brevi possibile. La pianificazione non dovrebbe
essere troppo dettagliata, poiché inevitabilmente verrà con il tempo rivista ed adeguata, ma deve prevedere
il giusto livello di informazioni per fare in modo che non ci siano incomprensioni o errori (68).
Quando si utilizzano le metodologie Agile, il processo si sviluppa attraverso una serie di cicli brevi, chiamati
Sprint, ognuno dei quali di una durata variabile da una a quattro settimane. All’inizio di ogni ciclo, durante
un primo incontro, viene determinata la scala di priorità dei requisiti da soddisfare durante il ciclo successivo;
l’ordine in cui le attività verranno svolte viene determinato in funzione del valore associato a ciascuna di esse.
Alla fine di ogni ciclo, è fissato un incontro nel quale si discutono gli obiettivi raggiunti nel ciclo completato e
quelli mancanti. Questo approccio “incrementale” dà sia la possibilità al gruppo di lavoro di rispondere
velocemente ai cambiamenti e di sviluppare solo ciò che è effettivamente richiesto, sia la capacità di ridurre
i rischi identificando i problemi in anticipo e coltivando un rapporto di collaborazione con il cliente.
Rispetto ai modelli agili, i metodi tradizionali prevedono una lunga pianificazione, predefinite fasi del
processo, molta documentazione e un lungo processo di design. Ogni fase consiste in un insieme di attività
che devono essere eseguite prima che inizi la fase successiva. Le attività si completano una dopo l’altra, in
una sequenza prestabilita, cosa che rende necessario che una gran parte del progetto venga pianificato in
anticipo. Infine, se nell’approccio Agile la programmazione in Sprint consente di implementare le sole
funzioni ad alta priorità, consegnando un prodotto con requisiti utili ad ogni Sprint, il ciclo di vita tradizionale
prevede la consegna del prodotto solo dopo un intero ciclo di sviluppo.
4.5.2 Approccio al cambiamento
Una delle differenze più importanti tra le metodologie tradizionali e Agile risiede nell’approccio che queste
hanno nei confronti dei cambiamenti e delle modifiche durante lo sviluppo del progetto.
Le metodologie tradizionali tentano di minimizzare i cambi nel corso del progetto, realizzando in anticipo una
rigorosa raccolta dei requisiti; l’obiettivo di questo approccio è quello di raggiungere alti livelli di qualità
attraverso una pianificazione rigida e controllata. Al contrario, i metodi Agile danno per scontato che i
cambiamenti durante lo sviluppo di un processo non solo sono inevitabili ma anche necessari, poiché
124
consentono di raggiungere l’innovazione attraverso l’iniziativa dei singoli (69). Mentre le metodologie di
Project Management tradizionale focalizzano molte energie sul cercare di prevenire i cambi negli obiettivi
del progetto, gli approcci Agile abbracciano il cambiamento, il cui controllo è una pratica naturale e
quotidiana per i membri del team di lavoro, e lo considerano uno strumento per apportare valore al prodotto.
Le metodologie tradizionali investono molta attenzione nella fase di pianificazione e controllo, cercando di
limitare quanto più possibile i cambiamenti anche per ragioni economiche. L’incertezza dei tempi e dei costi
complessivi, infatti, diminuisce man mano che il progetto procede, per cui apportare cambi rispetto a quanto
previsto ha un costo tanto maggiore quanto più vicini si è alla fine del progetto.
Le metodologie Agile, invece, suddividono il ciclo di sviluppo in intervalli temporali più brevi, Sprint o cicli
brevi; ne deriva che apportare modifiche ad ogni singolo modulo comporta costi molto minori di quelli che si
dovrebbero sostenere se, dopo una lunga fase di progettazione e sviluppo di un intero sistema, si dovesse
provare ad apportare dei cambiamenti al progetto. In Agile, gli stakeholders hanno il diritto di aggiungere dei
nuovi requisiti al prodotto e di cambiare l’ordine di priorità dei requisiti da realizzare; questa flessibilità al
cambiamento assicura che il consumatore sia soddisfatto e che il prodotto rappresenti quello che realmente
il cliente vuole in quel momento, non ciò che si aspettava all’inizio del progetto.
Nella Figura 36 è rappresentato il costo che i cambiamenti comportano, sia in uno sviluppo Agile di un
progetto sia seguendo un approccio tradizionale; si evidenzia come l’approccio Agile, in verde, riesca a
mantenere costi di cambiamento inferiori rispetto ad un approccio standard.
Figura 36- Costi per il processo di sviluppo Agile e tradizionale (70)
125
4.5.3 Il triangolo dei vincoli di progetto
Un'altra importante caratteristica che distingue gli approcci tradizionali da quelli Agile è legata al modo in cui
questi gestiscono i tre vincoli di progetto: costi, tempi e obiettivi (48).
Negli approcci tradizionali gli obiettivi del progetto sono fissati già all’inizio del suo sviluppo e sono dettagliati
nel programma; in funzione di questi vengono assegnate le opportune risorse e stimati i tempi necessari per
raggiungerli. L’approccio Agile, al contrario, parte dal presupposto che gli obiettivi di progetto sono destinati
a cambiare inevitabilmente durante il suo sviluppo per cui sono i parametri di tempi e costi a dover restare
fissi; lo scopo del progetto è cioè visto come un parametro dinamico che si evolve durante lo sviluppo del
progetto, adeguandosi alle richieste del cliente.
La Figura 37 rappresenta una schematizzazione di come le due diverse tipologie di approccio interpretano ed
approccino i tre vincoli di progetto: sulla sinistra, gli approcci tradizionali fissano uno scopo e, rispetto ad
esso, stimano costi e tempi; sulla destra, gli approcci agile fissano tempi e costi visti i cambiamenti che gli
obiettivi saranno inevitabilmente costretti a subire durante lo sviluppo del progetto.
Figura 37- Triangolo dei vincoli di progetto: confronto tra approccio tradizionale ed Agile (71)
Nelle metodologie Agile la qualità è pianificata all’inizio del progetto ed è costantemente considerata durante
il suo sviluppo. La suddivisione del ciclo di vita in Sprint e il costante coinvolgimento del cliente fanno sì che i
prodotti possano essere continuamente testati durante il progetto, cosa che ha sicuramente un impatto
positivo sulla qualità finale del prodotto.
126
4.5.4 Partecipazione del cliente
Secondo i metodi Agile, i clienti devono partecipare attivamente, comunicando faccia a faccia e fornendo
feedback continui (53). I clienti dovrebbero infatti partecipare il più possibile allo sviluppo del team,
impostando l’elenco di priorità, indicando nuovi requisiti del prodotto e offrendo il proprio riscontro
sull’operato del gruppo.
Il livello di coinvolgimento del cliente varia a seconda della metodologia Agile utilizzata: in alcuni casi il
coinvolgimento del cliente è totale e questi partecipata persino alle riunioni settimanali dei programmatori;
in altri casi, il cliente è coinvolto solo parzialmente o indirettamente, ad esempio esclusivamente nella prima
fase di progettazione oppure nella fase di test della versione del prodotto rilasciata.
Nonostante le differenze proprie delle diverse metodologie, il coinvolgimento del cliente nel processo è visto
come un elemento positivo e necessario per raggiungere la qualità sperata del prodotto finale. Nei processi
gestiti con metodi tradizionali, invece, non è previsto che gli obiettivi ed i requisiti del prodotto cambino
durante lo sviluppo del progetto per cui il coinvolgimento del cliente è previsto solo in fase iniziale, quando
si stabiliscono e si fissano gli obiettivi da raggiungere. Negli approcci tradizionali, quindi, il continuo
intervento del cliente sarebbe visto come negativo, potendo questi richiedere continue modifiche
impattando negativamente sulla durata del progetto.
4.5.5 Il team di lavoro
Il team Agile è solitamente piccolo, preferibilmente composto da un minimo di cinque ad un massimo di nove
persone; nel caso di gruppi più numerosi è preferibile suddividere il gruppo principale in gruppi più piccoli,
formando team multipli (60). La ragione per la quale si preferisce ricorrere a piccoli gruppi di lavoro è che in
questa configurazione il team raggiunge una maggiore efficienza e non ha problemi di comunicazione interna.
Le performance del team e il successo del progetto sono, secondo l’approccio Agile, vincolate al fatto che il
gruppo di lavoro sia fisicamente insieme nello stesso posto durante lo sviluppo del progetto, in modo che
possa comunicare e applicare le lezioni apprese dagli altri. Nei progetti gestiti con metodi tradizionali, al
contrario, il più delle volte accade che esistano diversi team che seguono le diverse fasi del ciclo di vita del
progetto, dalla progettazione alla consegna del progetto.
Una peculiarità del gruppo Agile, che lo distingue da un gruppo di lavoro tradizionale, è l’auto-organizzazione
del team; ai membri non viene specificatamente indicato come procedere nello sviluppo del prodotto ma
viene data la responsabilità di prendere decisioni. Questo tipo di schema comporta che non vi sia un leader
all’interno del gruppo che decida quali attività i membri del team debbano svolgere o come risolvere i
127
problemi; tutte le responsabilità sono invece a capo dei singoli membri del team. È fondamentale
nell’approccio Agile che si crei una forte identità di squadra, che comporti la celebrazione delle vittorie del
gruppo piuttosto di quelle di singolo; applicando le competenze tecniche acquisite in diversi campi, i membri
del team potranno raggiungere gli obiettivi comuni e imparare gli uni dagli altri (48).
Rispetto all’approccio tradizionale, secondo il quale il Project Manager è il responsabile, tra le altre cose,
della gestione del progetto e del gruppo di lavoro, le metodologie Agile propongono una nuova figura del
Project Manager. In questa nuova visione il Project Manager è un allenatore, i cui compiti principali sono
quelli di supportare il team, occuparsi i dei conflitti ed eliminare gli ostacoli e i problemi che impediscono al
team di lavorare al meglio delle proprie capacità (68).
4.5.6 Comunicazione
Uno dei principi del manifesto Agile è quello di dare priorità alla comunicazione piuttosto che alla
documentazione ma per rendere questo principio davvero efficace è necessario sviluppare un piano di
comunicazione, che faciliti la regolamentazione del flusso di informazioni, già nelle prime fasi del progetto,
ovvero nella fase dello studio di fattibilità.
Rispetto al tipo di comunicazione verticale, caratteristico dell’approccio tradizionale al Project Management,
la comunicazione Agile si sviluppa in direzione orizzontale, non è gerarchica e burocratica e incoraggia i
rapporti alla pari e gli incontri faccia a faccia (72). Rispetto ai metodi tradizionali, in cui le linee guida vengono
riportate dall’alto al basso della piramide dei ruoli, nel processo Agile la comunicazione è più semplice ed
immediata, cosa che garantisce maggiore trasparenza, miglioramento continuo e avvicinamento del cliente
al Project Management (73). La trasparenza nella comunicazione è fondamentale e permette a tutti gli attori
di comprendere esattamente come si sta evolvendo il progetto.
La comunicazione deve essere visiva ed efficace per cui l’approccio Agile prevede da un lato l’utilizzo di
strumenti grafici per una comunicazione visuale, dall’altro la necessità di incontri a diversa scadenza nella
quale trasmettere le informazioni di progetto a diversi livelli di dettaglio. Le diverse metodologie Agile
utilizzano strumenti diversi per migliorare la comunicazione; tra questi sono già stati descritti il Kanban Board
e il Burndown Chart.
128
4.5.7 Documentazione
Durante lo sviluppo di un progetto gestito con approcci tradizionali viene prodotta una grande mole di
documentazione, sia prima e durante lo svolgimento, che dopo la consegna del prodotto finale.
La metodologia Agile, che, si ricorda, nasce nell’industria del software, si contrappone al modello
tradizionale, prediligendo il prodotto e le sue caratteristiche piuttosto che la documentazione ad esso
inerente, molto dispendiosa in termini di tempo e risorse impiegate.
Nella Figura 38 è rappresentato lo sforzo impiegato per la produzione di documentazione di supporto al
progetto, in un approccio tradizionale e Agile.
Figura 38- Sforzo necessario per la produzione di documentazione di progetto, metodologia Agile e tradizionale (74)
129
5. Agile Project Management nelle costruzioni
Agile Project Management ha trovato grande diffusione in particolare nell’industria di sviluppo del software
e rappresenta un valido strumento per garantire il successo dei progetti, portando al tempo stesso ad un
aumento del livello di soddisfacimento da parte del cliente o utente finale.
Negli ultimi anni, la ricerca in ambito di Project Management sta iniziando ad interessarsi all’applicabilità
delle nuove metodologie agili all’industria delle costruzioni, viste le similitudini tra quest’ultima e l’ambiente
di produzione IT e i vantaggi che potrebbero aggiungere alle tradizionali tecniche di gestione. Partendo
dall’analisi della letteratura esistente sul tema, molto vaga e ancora molto da sviluppare, in questo capitolo
si valuterà in che modo Agile Project Management può essere applicato al processo delle costruzioni,
evidenziando i vantaggi e le criticità derivanti dalla sua adozione.
Nel primo paragrafo si indaga l’applicabilità di Agile Project Management all’industria delle costruzioni; si
evidenzierà che le rigide tecniche di gestione tradizionali mal si adattano ad un ambiente dinamico,
competitivo e turbolento come quello dell’attuale mercato delle costruzioni, che invece richiede un
approccio più flessibile, simile a quello Agile. Da un confronto tra Agile Manufacturing e Agile IT si evidenzierà
come le differenze tra i due paradigmi portino a valutare come applicabile alle costruzioni quello solitamente
impiegato nell’industria del software.
Nel secondo paragrafo si analizzeranno le aree principali in cui l’impiego di Agile potrebbe portare dei
miglioramenti al progetto nelle fasi di pre-design e design. Tra le soluzioni analizzate per migliorare il livello
di successo di un progetto troviamo: il maggior coinvolgimento del cliente nel processo, una maggiore
comunicazione orizzontale all’interno del team di lavoro, una maggiore collaborazione all’interno del gruppo
di lavoro e l’adozione di un sistema di incontri periodici, più o meno frequenti, propri dell’approccio Agile.
Nell’ultimo paragrafo si avanzerà una proposta di programmazione mista, in cui i benefici della
programmazione a lungo termine, propria delle tecniche di gestione tradizionale, vengono combinati ai
vantaggi offerti dall’utilizzo dalle principali metodologie Agile, quali Scrum e Kanban.
130
5.1 Applicabilità di Agile Project Management alle costruzioni
Il “Santo Graal” per la ricerca in ambito di Project Management è la ricerca dei fattori che determinino il
successo di un progetto (75).
Una ricerca americana, basato su centinaia di casi studi relativi all’industria delle costruzioni e non solo,
mostra che circa il 70 e il 90% di tutti i progetti è caratterizzato da insuccesso; l’esito negativo è dovuto, ad
esempio, alla mancanza di supporto da parte degli investitori, stakeholders e senior Project Managers che
eludono il formale processo decisionale, al verificarsi di rischi precedentemente sottovalutati o trascurati, a
membri del team di lavoro che non seguono fedelmente quanto programmato o sono insufficientemente
competenti (75). Secondo altri studi, che indagano sui fattori di fallimento dei progetti, ulteriori ragioni che
portano all’insuccesso sono: il cambiamento dell’ambito ovvero allo scope of work, il non compimento dei
requisiti richiesti, il non soddisfacimento delle aspettative del cliente e la confusione sul suo ruolo all’interno
del progetto, l’assenza di una buona pianificazione o un eccessivo ottimismo nella programmazione, le
mancanze nel considerare i cambiamenti dei requisiti e dei principi durante il progetto (75).
Le risposte al fallimento dei progetti sono da ricercarsi nei metodi di Project Management utilizzati per la loro
gestione. In presenza di un problema, infatti, i Project Managers rispondono solitamente irrigidendo la
struttura del progetto, nonostante alcuni autori facciano notare (75) che l’utilizzo di strumenti rigidi ha un
effetto negativo sul successo e che nei progetti che hanno ben chiaro l’obiettivo finale sia sufficiente
l’impiego di pochi strumenti, anche più flessibili.
Gli approcci tradizionali al Project Management, più rigidi e strumentali, continuano a trovare applicabilità,
oggi come in passato, per progetti relativamente semplici, per i quali la pianificazione è fatta sulla base di
variabili prevedibili ed è sufficiente, da parte del Project Manager, seguire precisamente il piano per
completare il progetto. Il mercato dell’industria delle costruzioni è però profondamente cambiato negli ultimi
anni, passando dalla produzione di edifici con caratteristiche tanto simili da rendere semplice la riproduzione
quasi in serie dei progetti, a progetti di recupero, manutenzione e gestione del patrimonio edilizio esistente,
per i quali aumenta notevolmente il grado di complessità. Prima del 2010, ad esempio, il 70% delle case in
Germania era costruito ai margini delle città, dove è relativamente semplice edificare; dal 2011, però, il 70%
delle costruzioni si insedia nel complesso tessuto urbano esistente, obbligando i Project Managers ad
interfacciarsi, ad esempio, con le esigenze di diversi stakeholders e con problemi logistici di cantiere (76). Il
mercato delle costruzioni si sta muovendo verso una nuova modalità di produzione, volta alla realizzazione
di edifici unici e personalizzati in base alle esigenze del cliente.
In un contesto così cambiato, le tradizionali tecniche di Project Management non trovano più semplice
applicabilità, portando in molti casi al fallimento dei progetti; risulta invece necessario l’impiego di soluzioni
131
più flessibili che meglio rispondano alle complessità del nuovo mercato e, in questo senso, Agile Project
Management sembra adattarsi meglio al nuovo ambiente dinamico e turbolento.
Le metodologie Agile hanno trovato ampio sviluppo e diffusione sia nell’industria manifatturiera (Agile
Manufacturing) sia in quella di sviluppo software (Agile IT). Come mostrato in Tabella 18, i due paradigmi
propri dei diversi tipi di industria possiedono delle differenze ma hanno lo stesso principio di base, ovvero
che la statica e tradizionale pianificazione, nella quale tutti i requisiti devono essere determinati in anticipo,
non trova opportuno riscontro in un ambiente dinamico caratterizzato da incertezza e cambiamento.
Tabella 18 - Confronto Agile Manufacturing e Agile IT (77)
Agile Manufacturing si focalizza su problematiche di strategia imprenditoriale ed è quindi più appropriato
per fondare nuove strategie aziendali per penetrare in nuovi segmenti di mercato. Agile IT fornisce nuove
soluzioni di gestione che, attraverso una pianificazione iterativa, portano ad un alto livello di soddisfazione
del cliente e al successo dei progetti; l’obiettivo di Agile IT è quello di sviluppare nuove pratiche di gestione
che sappiano far fronte a progetti iterativi (soluzioni definite ma obiettivi non definiti) e incrementali
(soluzioni non definite ma obiettivi fissati) (77).
Dal confronto tra questi due paradigmi Agile, emerge che quello che potrebbe essere applicato all’industria
delle costruzioni è l’Agile IT e le ragioni principali sono le seguenti:
132
• La ricerca di metodi e tecniche: l’alto livello di complessità dei processi delle costruzioni ha portato
alla necessità di individuare nuove pratiche di gestione che migliorino le performance e il livello di
successo dei progetti. Se Agile Manufacturing è più appropriato per formulare strategie
imprenditoriali, Agile IT formula e sviluppa dei metodi e delle tecniche specifiche, che rispondono nel
modo giusto alle esigenze attuali dell’industria delle costruzioni;
• Le similitudini tra industria delle costruzioni e IT. Nel Paragrafo 2.2.3 si sono analizzate le principali
differenze tra il bene prodotto dall’industria delle costruzioni e quello realizzato dall’industria
manifatturiera: il bene edile è un bene immobile, durevole e prototipico; la manifattura è al contrario
un bene di consumo, poco durevole e prodotto in serie. Se però tra l’industria delle costruzioni e
quella manifatturiera e tra i relativi beni prodotti esistono delle grandi differenze, il prodotto
dell’industria del software, come quello delle costruzioni, è un bene prototipico, funzione cioè dei
requisiti richiesti dal cliente. I successi maturati grazie all’impiego di Agile IT nell’industria del
software e le similitudini con l’ambiente delle costruzioni, lasciano pensare che Agile IT possa trovare
facilmente riscontro anche nell’industria delle costruzioni.
Nella gestione di un progetto delle costruzioni le metodologie Agile sono uno strumento efficace per il
successo dei progetti e garantiscono la flessibilità necessaria in un ambiente dinamico, turbolento e
competitivo come quello tipico dell’industria delle costruzioni. La loro applicabilità è funzione delle
caratteristiche del progetto e può prevedere il simultaneo impiego di tecniche e soluzioni di Project
Management tradizionale.
La vera sfida è quella di saper individuare il giusto modello di Project Management per ogni specifico
progetto. Quando il progetto è assolutamente unico e dimostra un alto livello di complessità, in parte
prodotta dalla presenza di una gran numero di agenti coinvolti e dall’alta possibilità di conflitti, il Project
Manager dovrebbe implementare un modello di gestione più flessibile, evitando metodi troppo gerarchici e
burocratici. Al contrario, nel caso di progetti relativamente semplici, in cui tutte le parti coinvolte sono in
accordo tra loro, una strutturazione più rigida potrebbe funzionare abbastanza bene.
Ogni progetto, semplice o complesso che sia, è contraddistinto da diverse fasi, ognuna con scopi e
caratteristiche differenti. Nel Paragrafo 5.2 si vedrà come nelle fasi iniziali, quelle di pre-design e design, le
metodologie Agile trovino molto spazio, in particolare per implementare il coinvolgimento del cliente, la
comunicazione e la collaborazione all’interno del gruppo, portando a maggiori livelli di successo; nel
Paragrafo 5.3 si evidenzierà come nella fase di esecuzione l’approccio Agile deve essere necessariamente
accompagnato da metodi tradizionali e si potrebbe prevedere, ad esempio, un tipo di programmazione mista
Agile-Tradizionale.
133
5.2 Agile Project Management nelle fasi di design e pre-design
Il Manifesto Agile identifica i quattro principi fondamentali su cui si basano tutti le diverse teorie agili (52):
• individui e iterazioni piuttosto che processi e strumenti;
• software funzionante piuttosto che documentazione esaustiva;
• collaborazione col committente piuttosto che negoziazione del contratto;
• rispondere al cambiamento piuttosto che seguire un piano prestabilito.
Dopo aver valutato le ragioni dell’applicabilità di Agile Project Management alla gestione di un processo tipico
dell’industria delle costruzioni, si valuta in che modo è possibile applicare concretamente i principi
fondamentali delle teorie Agile, contenuti nel manifesto.
Di seguito si presenta nel dettaglio l’analisi condotta sulle possibili aree in cui implementare Agile e sui
concreti cambiamenti da apportare per garantire il rispetto dei principi proposti dal manifesto Agile.
5.2.1 Coinvolgimento del Cliente
Uno dei principali vantaggi che si otterrebbero dall’assunzione dell’Agile Project Management nel processo
costruttivo riguarda il coinvolgimento del cliente.
Nella fase di pre-design vengono definiti i requisiti che il cliente reputa più o meno fondamentali per il
progetto e, nella fase di design, le idee formulate nella fase precedente vengono sviluppate e trasformate in
soluzioni reali. Uno degli obiettivi principali di entrambe le fasi è quindi quello di soddisfare le esigenze del
cliente, e sia il suo coinvolgimento continuo nel progetto che la possibilità di apportarne cambiamenti nelle
fasi iniziali di ideazione e progettazione non possono che portare a risultati migliori in termini di
apprezzamento da parte dello cliente stesso.
Questo tipo di approccio, in cui il cliente è continuamente coinvolto e del quale è richiesta costantemente
l’opinione, trasforma la figura del cliente, portandolo da un lato ad essere consapevole di tutto ciò che
riguarda il progetto, dall’altro a dover assumersi maggiori responsabilità rispetto a quelle che affronta oggi.
Applicando Agile nelle fasi di pre-design e design, il cliente dovrebbe essere costantemente coinvolto nel
progetto ed avrebbe il dovere di verificare che i requisiti riprodotti nel documento del Product Backlog siano
aggiornati e priorizzati; in questo modo il cliente avrebbe la possibilità di modificare costantemente i requisiti
del progetto, affinché questo si avvicini il più possibile alla propria visione finale.
134
Tra le criticità rilevate nell’aumentare il coinvolgimento del cliente nel processo si rilevano: le peculiarità della
fase esecutiva, che poco si adatta ai cambiamenti; la necessità di un profondo cambiamento del cliente e del
suo approccio al progetto.
In primo luogo, infatti, alcuni studi e ricerche condotte su diverse imprese di costruzioni svedesi (50) hanno
dimostrato come, nonostante le organizzazioni reputino fondamentale l’interazione continua con il cliente
durante le prime fasi di realizzazione del progetto, si continui a vedere il forte e continuo coinvolgimento del
cliente nella fase di esecuzione come un importante ostacolo allo svolgimento dei lavori. Se da un lato il
confronto con il cliente ne aumenta le responsabilità e la consapevolezza sullo stato dei lavori, dall’altro ci si
trova spesso a interfacciarsi con clienti privi di competenze tecniche e senza una visione concreta di ciò che
desiderano portare avanti. Nella delicata fase esecutiva, in cui i cambiamenti e le variazioni rispetto a quanto
programmato comportano aumenti di tempi e quindi di costi, risulta più difficile da parte dell’organizzazione
accogliere con favore gli interventi e gli input del cliente (68,72).
In secondo luogo, l’applicazione di Agile Project Management al mondo delle costruzioni comporta un reale
cambiamento da parte delle figure coinvolte, in questo caso specifico del cliente, a cui sarà richiesta una reale
e costante partecipazione ai meeting, più o meno frequenti, e ai momenti decisionali e al quale sarà
demandata la totale responsabilità sulla verifica dei requisiti che si stanno perseguendo e della relativa
priorità di esecuzione.
5.2.2 Comunicazione e collaborazione del team di progetto
Tra le aree sui cui Agile Project Management focalizza la propria attenzione ritroviamo l’area della
comunicazione e della collaborazione tra i membri del team di progetto.
È stato già ampiamente discusso di come la tipica struttura organizzativa delle società di costruzione porti ad
un tipo di comunicazione gerarchica e verticale tra le varie parti coinvolte; al contrario l’approccio tipico di
Agile Project Management è quello di una comunicazione orizzontale tra i diversi membri del gruppo.
Nelle aziende appartenenti all’industria delle costruzioni caratterizzate da una struttura organizzativa
fortemente gerarchica e verticale, infatti, la comunicazione tra le aree del Project Management è
prevalentemente di tipo verticale; è invece trascurata la comunicazione orizzontale interdisciplinare tra le
diverse aree funzionali che lavorano al progetto. Un passo per migliorare la comunicazione orizzontale
all’interno dell’impresa potrebbe essere quello di creare dei gruppi di lavoro piccoli, composti da membri che
si conoscano personalmente, che lavorino fisicamente nello stesso posto o che abbiano modo di interfacciarsi
costantemente online.
135
Una buona modalità comunicativa deve necessariamente essere accompagnata da un’opportuna
pianificazione della comunicazione. Se nei progetti di dimensioni minori la comunicazione avviene
abbastanza naturalmente senza necessità di grandi pianificazioni, per i progetti più complessi ed ampi è
fondamentale redigere un piano di comunicazione già nelle prime fasi del progetto, in modo che eventuali
membri aggiuntisi al gruppo in un secondo momento possano essere informati su quanto fatto in precedenza
e acquisire velocemente padronanza del progetto.
Oltre al tema della comunicazione, la teoria Agile approfondisce quello della collaborazione all’interno dei
team di progetto, che risulta essere fondamentale sia per migliorare l’efficienza del progetto in termini di
tempo, costi e qualità, sia per ridurre il numero di cambi nelle ultime fasi del progetto. I tre punti principali
che, dall’analisi critica della letteratura e del contesto del progetto delle costruzioni, sono stati identificati
come fondamentali per aumentare l’efficienza della collaborazione del gruppo di lavoro sono:
• Fiducia: riporre fiducia nei membri del gruppo di lavoro e credere nelle loro potenzialità è
fondamentale poiché stimola il lavoro dei singoli e la capacità di ogni componente del gruppo di
organizzarsi autonomamente;
• Capacità di autogestione: la capacità del gruppo di autogestirsi permette al Project Manager di
concentrarsi sui compiti più importanti e critici, portando ad una migliore qualità del prodotto finale;
• Focus sugli obiettivi: ogni membro del gruppo dovrebbe condividere la sua visione riguardo al
progetto, in termini di cosa realizzare, come produrlo e perché. Avere uno scopo comune è
fondamentale per evitare che si perda tempo su obiettivi sbagliati, per ridurre il rischio di disaccordi
tra le parti e per lavorare in modo più efficiente. Un comune focus sugli obiettivi può essere
conseguito attraverso frequenti incontri e buona comunicazione, in modo da rimarcare
costantemente all’interno del team quali siano gli obiettivi da perseguire.
5.2.3 I meetings
Secondo un’indagine condotta tra i Project Manager di tre grandi progetti di edifici e infrastrutture (72),
tradizionalmente gli incontri durante la fase di design sono strutturati in quattro livelli contraddistinti dalle
lettere A,B,C,D: l’incontro di tipo A avviene tra i membri del Project Board, l’incontro di tipo B è quello con il
cliente e riguarda principalmente temi economici, l’incontro C coinvolge i membri del Design Management e
l’incontro D è quello tra i membri del team di progettazione; gli incontri A e B vengono fissati una volta al
mese, gli incontri C e D due volte al mese.
136
La strutturazione degli incontri ABCD è da un lato molto rigida e poco flessibile e dall’altro molto gerarchica;
ad essa si contrappone la struttura dei meeting Agile, nella quale tutti gli attori hanno uguale importanza e
potere (61).
Tra le principali caratteristiche della programmazione Agile vi è la scomposizione del processo in cicli brevi
iterativi (Sprint), ognuno con durata variabile da una a quattro settimane, a seconda della tipologia di
progetto. All’inizio di ogni Sprint, vengono organizzati degli incontri (Sprint Planning Meeting), nei quali viene
stabilito cosa sarà realizzato e portato a termine durante lo Sprint, e quotidianamente si terranno delle
riunioni più informali e veloci (Daily sCRUM Meeting) nei quali i membri del team di progetto saranno
informati sullo stato di avanzamento dei lavori.
Da un’indagine condotta tra i Project Manager di alcuni progetti della Grontmij AB in Svezia (50), da un lato
emerge la necessità di aumentare il numero di incontri, sia nelle fasi di pre-design e design sia in quella di
esecuzione, per garantire un maggiore controllo del progetto e l’aggiornamento continuo dei membri del
team, dall’altro si manifestano due importanti limiti nell’adozione della tipologia di incontri proposti dalla
teoria Agile.
Una prima difficoltà è correlata all’importanza data da Agile all’effettiva partecipazione agli incontri da parte
di tutti gli interessati che hanno, tra i vari compiti, quello di presenziare agli incontri e di aggiornarsi sullo
stato di avanzamento dei lavori. Nel mondo delle costruzioni, però, molto spesso c’è chi segue più progetti
in contemporanea e la presenza fisica agli incontri quotidiani di ogni singolo progetto seguito può essere
particolarmente difficile da garantire.
Una seconda criticità risiede nell’idea di molti secondo la quale gli incontri rappresenterebbero una perdita
di tempo perché mal organizzati e perché presieduti da persone non direttamente coinvolte nel progetto.
Questo aspetto può però facilmente essere risolto sia semplificando il processo in cicli brevi, diminuendo così
il numero degli argomenti da affrontare, sia adottando il tipico approccio strutturato agli incontri di Agile, in
cui nulla viene lasciato al caso ma segue un ordine preciso e prestabilito.
Adottare l’approccio Agile nella gestione dei meeting e dei momenti di incontro durante un progetto di
costruzione è fondamentale perché da un lato aumenta la consapevolezza dei singoli membri del gruppo sul
progetto e su ciò che gli altri stanno seguendo, rendendo più semplice l’individuazione delle diverse
responsabilità e quindi il flusso di informazioni, dall’altro facilita il controllo dei rischi e dei problemi che
potrebbero presentarsi nelle fasi successive.
137
5.3 Agile Project management nella fase di esecuzione: la programmazione mista
Partendo dall’idea di una scomposizione del processo in cicli brevi e iterativi, si propone di seguito un
approccio integrato, che prevede una programmazione mista che sfrutti i vantaggi e la metodicità della
tradizionale programmazione a lungo termine attraverso il diagramma di Gantt e la flessibilità ai cambiamenti
propri degli strumenti utilizzati dalle metodologie Agile, quali i framework Scrum e Kanban.
5.3.1 La programmazione tradizionale: il diagramma di Gantt
Nella gestione tradizionale di un progetto è riservata particolare importanza all’attività di programmazione,
essendo questa la base per lo sviluppo di tutte le parti del progetto stesso. L’attività di programmazione inizia
con la suddivisione dell’intero lavoro in attività elementari, procedura che permette di gestire il progetto più
semplicemente e consente maggiore accuratezza delle previsioni.
Il lavoro di programmazione, ovvero l’analisi del progetto e la previsione della durata e dei mezzi necessari
alla realizzazione delle singole attività, è solitamente sintetizzato per mezzo di una forma grafica facilmente
interpretabile e, più in generale, attraverso il diagramma di Gantt, rappresentato in Figura 39.
Figura 39- Esempio di diagramma di Gantt (58)
Il diagramma di Gantt è un calendario continuo a sviluppo orizzontale nel tempo, con elencate sull’asse delle
ordinate le attività da svolgere contrassegnate da un codice identificativo e scomposte nei sottolivelli.
Solitamente, per rendere più semplice la lettura del diagramma e per comodità di gestione, il Project
Manager effettua una programmazione generale dell’intervento con indicate le macro-attività e demanda
138
alle imprese sub-appaltatrici la realizzazione di cronoprogrammi specifici per le macro-attività di cui sono
responsabili.
Ad ogni attività corrisponde una barra (bar chart) di lunghezza proporzionale alla durata, i cui estremi
corrispondono alla data in cui è previsto cadano gli eventi di inizio e fine, valutati tenendo presente i legami
con le altre attività; le attività si snodano, quindi, secondo un ordine logico e secondo uno sviluppo
temporale. Nel diagramma vengono solitamente evidenziati: il Total Float, ovvero il tempo del quale è
possibile ritardare un’attività senza che questa renda il progetto più lungo; il cammino critico, composto dalle
attività critiche che, se ritardate, comportano un ritardo di tutte le attività successive ad esse legate e, quindi,
della consegna finale del progetto; la durate delle attività, stimata dal personale di progetto sulla base
dell’entità di lavoro richiesto e contando sull’esperienza di progetti passati; i legami che legano tra loro le
diverse attività.
Nella Figura 40 sono rappresentate le diverse tipologie di legame che, nella realtà esecutiva dei progetti, sono
utilizzate per collegare le attività. Con la lettera P si intende l’attività “prevalente predecessoria”, ovvero
quella da cui dipende la successoria; con la lettera S si intende l’attività “dipendente successoria”, cioè quella
subordinata alla principale. Le principali tipologie di legami sono:
• legame FS (finish-start): prevede che un’attività non possa iniziare se non dopo il completamento
dell’attività prevalente;
• legame SF (start-finish): prevede che un’attività dipendente non possa finire se non dopo l’inizio della
prevalente;
• legame SS (start-start): l’attività dipendente non può iniziare se non dopo l’inizio della prevalente;
• legame FF (finish-finish): l’attività dipendente non può concludersi prima del completamento della
prevalente.
Figura 40- Tipologie di legame tra le attività del cronoprogramma (58)
139
Solitamente, le macro-attività del cronoprogramma generale del progetto possono essere tra loro collegate
da uno tra i diversi vincoli appena presentati; al contrario le attività necessarie per la realizzazione delle
singole macro-attività sono tra loro collegate da semplici legami di tipo inizio-fine.
La rappresentazione grafica della programmazione attraverso il diagramma di Gantt permette di:
• stimare la durata complessiva del progetto e le risorse, economiche e materiali, impiegate durante
la sua esecuzione;
• visualizzare la densità delle attività che concorrono al progetto nei diversi periodi e, quindi, calcolare
e controllare il carico di lavoro delle singole squadre o risorse impiegate in ciascuna attività del
progetto.
L’attività di programmazione viene eseguita sia in fase preventiva e previsionale (fase di pianificazione), sia
durante lo sviluppo del progetto (fase di controllo) per misurare gli scostamenti rispetto a quanto
preventivato inizialmente riguardo ad attività realizzate, durata, risorse effettivamente impiegate e costi
effettivi. La programmazione deve quindi essere periodicamente ripetuta durante lo sviluppo del progetto,
per rispondere alle diverse variabili che molto spesso intervengono.
5.3.2 Un approccio integrato: tecniche tradizionali e Agile
La programmazione a lungo termine proposta dalle tecniche di gestione tradizionali ha sì il vantaggio di
restituire un’idea globale dell’andamento del progetto, ma anche il limite di riuscire ad identificare gli
scostamenti, in termini di tempi, costi e quantità prodotte, con tempistiche che molto spesso non
permettono di agire in tempo, con conseguenti ritardi del progetto e aumento dei costi.
I limiti della programmazione a lungo termine potrebbero essere superati sfruttando, durante la gestione di
un progetto di costruzione, metodologie e strumenti Agile, quali il framework Scrum e Kanban. Nella Figura
41 è rappresentato uno schema che illustra una possibile integrazione di Scrum a Kanban all’interno di una
pianificazione tradizionale. Nel seguito se ne riporta una descrizione.
140
Figura 41- Schema di una possibile soluzione per integrare le Metodologie Scrum e Kanban all’interno di una programmazione
tradizionale per un progetto dell’industria delle costruzioni.
141
La soluzione di integrazione proposta prevede che il Project Manager (che si identifica nella figura del
Responsabile Unico del Procedimento, con il compito di seguire la realizzazione dell’opera in ogni fase, dalla
progettazione, all’esecuzione), formuli una pianificazione completa dell’intero processo in modo tradizionale,
ovvero attraverso un opportuno diagramma di Gantt. Il cronoprogramma dovrà riportare preferibilmente
solo le macro-attività, per rendere più facile la lettura del documento; il compito di eseguire la
programmazione per le singole macro-attività sarà demandato alle impresa appaltatrice, contrattata dal
Committente o identificata dal Project Manager nel caso di edilizia privata e scelta in seguito a gara d’appalto
nel caso di lavori pubblici.
Se per la pianificazione generale del processo, scomposto in macro-attività, è previsto l’utilizzo di una
metodologia tradizionale, per la programmazione e lo sviluppo di ogni singola macro-attività si adotterà un
approccio Agile e si applicherà la metodologia Scrum, suddividendo la macro-attività in cicli brevi e iterativi,
di lunghezza diversa a seconda della loro durata.
Nel caso di applicazione ad un progetto delle costruzioni, le figure del Team Scrum saranno:
• Product Owner: ruolo ricoperto dal Project Manager, ovvero dal Responsabile Unico del
Procedimento che, esattamente come il Product Owner, è responsabile di controllare che le attività
vengano svolte correttamente e che vengano rispettate le tempistiche imposte dalla
programmazione generale;
• Scrum Master: ruolo ricoperto dal Direttore Tecnico di Cantiere (che può coincidere con la figura del
capocantiere nel caso di piccoli progetti o esserne un diretto superiore) che, come lo Scrum Master,
è il punto di riferimento per il Team di lavoro. Una differenza fondamentale tra le due figure riguarda
il diverso livello di responsabilità: essendo i Team di Sviluppo Scrum auto-organizzati al loro interno,
in un tradizionale processo Scrum lo Scrum Master ha sì il compito di garantire che il lavoro si svolga
secondo i piani, ma non la responsabilità su come le parti vengano realizzate; al contrario il Direttore
Tecnico di Cantiere ha poteri decisionali sia in materia di programmazione operativa sia di condotta
esecutiva dei lavori.
• Team di sviluppo: rappresentato dalle maestranze ovvero dall’insieme dei lavoratori che consente
la realizzazione materiale dell’oggetto edilizio; nel mondo dell’edilizia si fa riferimento al termine
“squadra” come ad un gruppo di maestranze con diverse qualifiche e competenze. Due principali
differenze tra il Team di sviluppo Scrum e quello tradizionale riguardano la possibilità del gruppo
Scrum di auto-organizzarsi e di prendere decisioni sul lavoro da svolgere ed il numero di persone
coinvolte, che nel processo Scrum deve essere compreso tra cinque e nove persone.
142
• Direttore dei lavori: figura non prevista nel Team Scrum, è però indispensabile in un processo delle
costruzioni perché responsabile della corretta esecuzione dei lavori. E’ una figura professionale
nominata dal committente per tutelare i propri interessi nei confronti dell’impresa costruttrice e dei
terzi. Il direttore dei lavori emana ordini di servizio, controlla la fedele esecuzione, verifica la qualità
dei materiali impiegati, compila gli stati d'avanzamento e tiene i rapporti economici con l'impresa.
Secondo l’approccio integrato proposto, dopo aver identificato l’impresa sub-appaltatrice la macro-attività
deve essere scomposta in cicli brevi e iterativi (Sprint), della durata variabile da una a quattro settimane in
base alla tipologia di progetto e alla durata complessiva della macro-attività stessa.
Nella Figura 42 si riporta un esempio di scomposizione di una macro-attività in più cicli brevi e iterativi. La
scomposizione consente un controllo più frequente dello stato di avanzamento del progetto e consente
quindi di adottare opportune misure correttive in tempi più brevi rispetto a quanto accade in un processo
pianificato in modo tradizionale.
Figura 42- Scomposizione della macro-attività "Fondazioni" in cicli brevi e iterativi come previsto nella metodologia Scrum
143
Prima dell’inizio del primo Sprint, il Direttore Tecnico di Cantiere (Scum Master), seguendo le scadenze fissate
dal Project Manager (Product Owner) e soggetto al controllo del Direttore dei Lavori, formula il Product
Backlog, documento nel quale sono elencate tutte le attività previste per il completamente della macro-
attività; ad ogni attività è associato un valore di priorità in base al rischio e alle tempistiche di consegna. Sulla
base del Product Backlog e potendo contare sulla propria esperienza, il Direttore Tecnico di Cantiere
costruisce un diagramma di Gantt generale per lo svolgimento della macro-attività, che consideri la
suddivisione della stessa in un certo numero di Sprint.
All’inizio di ogni Sprint, si tiene un incontro denominato Sprint Planning Meeting a cui partecipano il Direttore
Tecnico di Cantiere e le squadre di lavoro. La durata dell’evento è proporzionale alla durata della Sprint e
dura circa due ore per uno Sprint di una settimana. Durante l’incontro viene formulato lo Sprint Backlog, nel
quale si identificano le attività da eseguire durante lo Sprint in corso, nel rispetto delle priorità già previste
nel Product Backlog, e si definiscono i dettagli tecnici su come queste verranno realizzate. Il Direttore Tecnico
di Cantiere formula quindi un cronoprogramma specifico per lo Sprint in corso, con le attività previste nello
Sprint Backlog.
Alla fine di ogni Sprint si tengono due diversi incontri:
• Sprint Review Meeting: incontro a cui partecipano il Project Manager, il Direttore dei Lavori, il
Direttore Tecnico di Cantiere e le squadre di lavoro. L’obiettivo del meeting è quello di valutare lo
stato di avanzamento dei lavori. La presenza del Project Manager a questo incontro è fondamentale
perché durante la riunione viene informato dell’andamento del progetto e di eventuali ritardi o
anticipi rispetto a quanto programmato. Un utile strumento da utilizzare soprattutto durante questo
incontro è il Burndown Chart, diagramma nel quale è chiaramente indicato l’andamento che si era
previsto di seguire rispetto e quello che si è seguito realmente durante lo Sprint appena concluso.
• Spring Retrospective Meeting: incontro a cui partecipano solo il Direttore Tecnico di Cantiere e le
squadre di lavoro; rappresenta un’occasione di auto-analisi finalizzata al miglioramento del gruppo
durante lo Sprint successivo.
Un modo efficace per migliorare il controllo giornaliero dello stato di avanzamento del progetto,
monitorando costantemente lo stato delle attività, è quello di introdurre dei brevi incontri giornalieri,
proposti nella metodologia Scrum con il nome di Daily Scrum Meeting. Gli incontri, ai cui partecipano il
Direttore Tecnico di Cantiere e le squadre di lavoro, sono un occasione per il Direttore dei Lavori per dare
eventualmente indicazioni sul lavoro da svolgere. L’incontro ha le seguenti caratteristiche:
• incontro quotidiano sempre alla stessa ora e della durata di 15 minuti al massimo, senza necessità di
prendere posto intorno ad un tavolo per mantenere alto il livello di attenzione;
144
• partecipazione di tutti i membri delle squadre di lavoro ma intervento esclusivo dei componenti con
un ruolo principale;
• discussione su cosa è stato fatto in più rispetto al giorno precedente, su cosa si intende fare prima
dell’incontro del giorno successivo e su eventuali ostacoli o impedimenti riscontrati.
L’introduzione della pratica di brevi incontri giornalieri, ben gestiti e strutturali secondo il metodo Agile,
migliorebbe le comunicazioni all’interno del gruppo, consentirebbe di identificare subito ritardi nei lavori ed
eventuali ostacoli allo sviluppo del progetto e di applicare azioni correttive immediate, garantirebbe una
maggiore conoscenza del progetto da parte di tutti i componenti del team di lavoro.
Nella Figura 43 sono riassunti i principali incontri previsti per ogni Sprint e per ognuno di questi sono messi
in evidenza gli obiettivi e gli eventuali strumenti utilizzati.
Figura 43- Gli eventi Scrum durante un singolo Sprint: obiettivi e strumenti utilizzati
Un pratico strumento per monitorare lo stato del lavoro durante un processo, adottabile anche per il
controllo dello stato delle lavorazioni di un processo costruttivo, è la lavagna Kanban, sulla quale posizionare
tutti i cartellini, ovvero i kanban, corrispondenti alle attività in programma. Per poter comprendere meglio lo
stato attuale del lavoro all’interno dell’organizzazione è utile mappare il processo di lavorazione,
posizionando i cartellini relativi alle attività in tre colonne distinte:
• To Do (da fare): contiene i compiti e le attività da iniziare;
• In Progress (in lavorazione): sono inseriti i compiti contestualmente in elaborazione;
• Done (fatto): raccoglie i compiti eseguiti o conclusi.
145
Come visto nel Paragrafo 4.4.1, implementazioni della più semplice lavagna Kanban potrebbero prevedere:
• la suddivisione della fase di lavorazione (in progress) in ulteriori colonne che identifichino la
percentuale di avanzamento fisico dell’attività (appena iniziata, completa al 50%, quasi terminata);
• l’utilizzo di icone rappresentanti i vari membri del team, da apporre sui cartellini delle diverse attività,
con l’obiettivo di migliorare il controllo del flusso di lavorazione e di individuare più facilmente le
responsabilità ed i compiti all’interno del team di lavoro;
• l’aggiunta di una “corsia di emergenza” (expedite lane), distinguibile attraverso l’impiego di un colore
diverso o di appropriata simbologia, nella quale posizionare le attività che devono avere una priorità
di esecuzione rispetto a tutte le altre;
• la scomposizione orizzontale del flusso di lavoro (scatter marge), nel caso di attività che devono
essere necessariamente eseguite in parallelo;
• l’introduzione del limite WIP (Work in Progress) pari al numero massimo di attività che si possono
svolgere contemporaneamente in parallelo, col fine di impedire il sovraccarico e lo sbilanciamento
del flusso di lavorazione.
Questo pratico strumento da un lato permette di aumentare il senso di responsabilità dei membri delle
squadre di lavoro che hanno così modo di vedere come il loro eventuale ritardo potrebbe intaccare il lavoro
degli altri membri, dall’altro consente di avere una chiarissima visualizzazione del processo di lavoro, ovvero
di sapere subito quali sono le attività che ancora devono essere intraprese, quelle che sono in elaborazione
e che devono essere portate a termine, e quelle già concluse. La chiarezza di questo schema lo rende
facilmente comprensibile anche ai meno esperti e, per questo, la lavagna Kanban potrebbe essere un
prezioso strumento da utilizzare durante gli incontri giornalieri tra i membri del team del progetto per
aggiornare tutti sullo stato di avanzamento, su ciò che è stato concluso e su quali i passi successivi da seguire.
Un secondo strumento particolarmente utile per valutare l’andamento del lavoro svolto e da svolgere e per
migliorare le stime future per la produzione di nuovi incrementi è il Burndown Chart, un diagramma
cartesiano in cui sono indicati, sull'asse X, i giorni dello Sprint e sull'asse Y, le ore di lavoro che resta da
svolgere (effort). Durante ogni giorno dello Sprint si tracciano due linee di colori diversi: la prima rappresenta
la stima del lavoro che rimane da completare, calcolato sulla base della velocità di sviluppo del gruppo; la
seconda rappresenta l’effettivo lavoro ancora da concludere, in funzione del reale andamento dei lavori in
cantiere. Attraverso la rappresentazione grafica del Burndown Chart è chiaramente messa in evidenza la
situazione di eventuale ritardo o anticipo del progetto rispetto a quanto previsto ed è quindi possibile da un
lato monitorare lo stato del progetto giorno per giorno, dall’altro avere un’idea del progresso del singolo
Sprint se lo strumento viene utilizzano come riferimento durante lo Sprint Review Meeting.
146
147
6. Conclusioni
In questo lavoro di tesi si è valutata l’applicabilità di Agile Project Management all’industria delle costruzioni
e si è costruito un modello di pianificazione integrata per un progetto costruttivo, in cui si combinano i
vantaggi della programmazione a lungo termine propri dei metodi tradizionali e la flessibilità dei metodi Agile.
Si è visto che gli approcci tradizionali al Project Management, più rigidi e strumentali, trovano applicabilità
soprattutto per progetti relativamente semplici, per i quali seguire la pianificazione è sufficiente per
completare il progetto. L’attuale mercato delle costruzioni, dinamico, competitivo e turbolento, però,
richiede l’impiego di soluzioni che, da un lato, rispondano meglio alle complessità del mercato, dall’altro,
abbiano un approccio più flessibile al cambiamento. In questo contesto, le metodologie di Agile Project
Management, leggere e flessibili, rappresentano una valida alternativa ai metodi tradizionali, vista la loro
grande capacità di adattamento alle modifiche; le metodologie Agile sono indicate per progetti con un alto
livello di complessità ed incertezza, come quelli dell’industria delle costruzioni, nei quali sono inevitabili
cambiamenti rispetto a quanto inizialmente programmato.
L’applicabilità di Agile Project Management nel settore edile è giustificata da un lato dalle peculiarità del
mercato delle costruzioni e dalla crescente complessità dei progetti, dall’alto dalla forte similitudine tra il
prodotto edile, prototipico, immobile e durevole, ed il bene dell’industria del software, nella quale già da
molti anni sono state adottate le tecniche di Agile Project Management per la gestione dei progetti con ottimi
risultati in termini di successo e gradimento da parte del cliente.
Agile Project Management può trovare impiego sia nella fase di progettazione che in quella esecutiva ed
essere un ottimo strumento se combinato agli approcci di gestione tradizionali. In questo lavoro di tesi è
stato elaborato un modello di pianificazione integrata specifico per la fase esecutiva, che combina i punti di
forza della programmazione tradizionale e quelli delle metodologie Scrum e Kanban; da un lato la
programmazione a lungo termine ha il vantaggio di restituire un’idea globale dell’andamento del progetto e
di permettere la gestione del gran numero di macro-attività necessarie per il suo completamento, dall’altro
le tecniche Agile consentono sia un controllo più frequente degli scostamenti, dando la possibilità di
intervenire tempestivamente, sia l’aggiornamento continuo dei membri del team sullo stato dei lavori,
aumentandone il coinvolgimento ed il senso di responsabilità.
148
Il modello di pianificazione integrata proposto prevede i seguenti passi:
• il Project Manager realizza una pianificazione completa dell’intera opera attraverso un tradizionale
cronoprogramma, nel quale sono indicate le macro-attività da realizzare;
• si procede con il subappalto ad imprese terze della realizzazione delle singole macro-attività;
• il Direttore Tecnico di Cantiere realizza, nel rispetto delle tempistiche fissate dal Project Manager e
sotto la supervisione del Direttore dei Lavori, un cronoprogramma generale dei lavori per il
completamento della macro-attività, assimilabile al documento del Product Backlog di Scrum che
indica l’ordine di priorità di esecuzione e le durate;
• le singole macro-attività vengono scomposte in cicli brevi ed iterativi (Sprint) gestiti secondo la
metodologia Scrum, la cui lunghezza varia a seconda della durata della macro-attività a cui si
riferiscono;
• prima dell’inizio di ogni ciclo, il Direttore Tecnico di Cantiere e le squadre di lavoro partecipano allo
Sprint Planning Meeting, durante il quale si definiscono le attività da realizzare durante lo Sprint, in
funzione dell’ordine di priorità già stabilito, e si discutono i dettagli tecnici di esecuzione;
• all’inizio di ogni giorno dello Sprint, il Direttore Tecnico di Cantiere e le squadre di lavoro partecipano
al Daily Scrum Meeting, un breve incontro nel quale si illustra, attraverso la lavagna Kanban, ciò che
è stato completato, le lavorazioni ancora in corso e ciò che si intende eseguire durante la giornata;
l’incontro rappresenta anche un occasione per il Direttore dei Lavori per interfacciarsi con il team e
dare eventuali indicazioni sui compiti da svolgere;
• alla fine di ogni ciclo si tengono due incontri: tutto il Team Scrum partecipa allo Spring Review
Meeting, durante il quale si presenta lo stato di avanzamento della macro-attività attraverso il
Burndown Chart; il Direttore Tecnico di Cantiere e le squadre di lavoro partecipano allo Spring
Retrospective Meeting, durante il quale si indagano possibilità di miglioramento per il lavoro del
team nello Sprint successivo.
Il principale vantaggio che si ottiene dall’impiego della metodologia Scrum per la gestione delle macro-attività
è il maggior controllo dello stato di avanzamento dei lavori. La suddivisione in cicli brevi e iterativi consente
la misura del progresso, in termini di costi, quantità prodotte e risorse impiegate, sia quotidianamente,
durante i Daily Scrum Meeting, che alla fine di ogni Sprint, durante lo Sprint Review Meeting; l’aggiornamento
continuo sullo stato dei lavori permette al Project Manager dell’opera di intervenire repentinamente con
opportune azioni correttive in caso di scostamenti rispetto a quanto preventivato.
149
L’applicabilità della metodologia Agile per la gestione dei progetti dell’industria delle costruzioni ha però
alcuni limiti, frutto delle differenze tra la produzione nel mondo delle costruzioni e quella dell’industria del
software, per la quale le metodologie agili sono state sviluppate e implementate nel tempo.
In primo luogo, la pianificazione in Agile viene sempre condotta su piccole parti di processo e non sul suo
intero sviluppo ed è poco specifica, perché costantemente rivista ed adeguata. In un processo costruttivo,
caratterizzato da un grande numero di attività che si completano l’una dopo l’altra, è però sempre necessaria
una programmazione in anticipo di gran parte del progetto. Si ritiene quindi di difficile realizzazione la
gestione di un progetto costruttivo esclusivamente attraverso metodologie Agile e si suggerisce l’utilizzo di
un approccio integrato, come quello proposto, in cui si combinino una pianificazione tradizionale dell’intera
opera e la gestione in Agile delle singole macro-attività.
In secondo luogo, le metodologie tradizionali e Agile hanno un diverso approccio nei confronti dei
cambiamenti e delle modifiche da parte del cliente durante lo sviluppo del progetto. Da un lato, le
metodologie tradizionali si concentrano molto sulle fasi di pianificazione e controllo, cercando di limitare
quanto più possibile i cambiamenti in corso d’opera per ragioni tecniche ed economiche; dall’altro i metodi
Agile ricercano l’attiva partecipazione del cliente e accettano positivamente le modifiche che questi richiede
durante lo sviluppo. In particolare nella fase esecutiva di un progetto delle costruzioni, il coinvolgimento del
cliente e le sue richieste di modifica rischierebbero di compromettere l’esito positivo del progetto e lo
renderebbero difficile da gestire; nell’industria delle costruzioni, quindi, si richiede al cliente chiarezza e
decisione nella definizione dei requisiti già nelle prime fasi del processo e non si prevede che questi possa
richiedere continuamente aggiornamenti al programma e proporre dei cambiamenti in corso d’opera.
Inoltre, si ritiene che siano difficili da riprodurre le caratteristiche del team Agile nel contesto delle
costruzioni. La principale peculiarità del gruppo Agile è l’auto-organizzazione del team; ai membri non viene
specificatamente indicato come procedere nello sviluppo del prodotto ma viene data loro la responsabilità
di prendere decisioni ed il Project Manager ha il compito di supportare il team, occuparsi dei conflitti ed
eliminare gli ostacoli ed i problemi che impediscono al team di lavorare al meglio. In un contesto come quello
delle costruzioni, in cui vi è una netta distribuzione delle responsabilità tra gli attori del processo, è invece
fondamentale prevedere delle figure che abbiano la responsabilità dell’esecuzione dell’opera ed è quindi
impossibile demandare ai singoli membri del gruppo la responsabilità di quanto da loro realizzato, come
invece avviene nei processi gestiti con metodologie Agile.
Infine, i numerosi meeting previsti da Agile possono risultare di difficile applicazione nel campo delle
costruzioni soprattutto in fase esecutiva, durante la quale il numero delle attività da sviluppare è notevole e
i vincoli di tempo possono essere stringenti; per evitare che gli incontri siano percepiti come una perdita di
150
tempo da parte dei partecipanti, da un lato si dovrebbe scegliere opportunamente la lunghezza dello Sprint,
in modo da limitare la quantità di argomenti da trattare durante gli incontri, dall’altro si dovrebbe prevedere
un approccio strutturato in cui nulla venga lasciato al caso. Adottare l’approccio Agile nella gestione dei
meeting e utilizzare lo strumento delle Kanban board da un lato aumenta la consapevolezza dei singoli
membri del gruppo sul progetto e su ciò che gli altri stanno seguendo, facilitando l’individuazione delle
diverse responsabilità e quindi il flusso di informazioni, dall’altro facilita il controllo dei rischi e dei problemi
che potrebbero presentarsi nelle fasi successive.
In conclusione, nel mercato delle costruzioni, dinamico, competitivo e caratterizzato da progetti sempre più
complessi, è opportuno ricercare forme di gestione più flessibili al cambiamento. Agile Project Management,
utilizzato con successo per la gestione dei progetti nell’industria del software, potrebbe essere impiegato
anche per la gestione di progetti costruttivi, viste le similitudini tra il bene edile ed il prodotto IT. L’impiego
dei metodi di gestione Agile si adatta bene durante la fase esecutiva, seppur con qualche limitazione; si
suggerisce una pianificazione integrata che preveda la gestione dell’intera opera attraverso una
programmazione tradizionale ed il controllo delle macro-attività di cui si compone, scomposte in cicli brevi e
iterativi, per mezzo delle metodologie Agile più diffuse, Scrum e Kanban.
Un possibile sviluppo futuro di questo lavoro di tesi potrebbe essere quello di applicare il modello di
programmazione integrata qui presentato ad un caso studio reale, verificandone i limiti ed il reale utilizzo e
valutando i vantaggi derivanti dalla maggiore capacità di controllo dello stato dei lavori.
151
7. Bibliografia
(1) Nepi A. Le origini storiche del project management. Project Manager (IL) 2013.
(2) Allodi D. Project Management per l’architettura. Definizione degli obiettivi, programmazione, esecuzione,
controllo, attori e dinamiche.FrancoAngeli, Milano 2008.
(3) Baldini M, Miola A, Neri PA. Lavorare per progetti. Project Management e processi progettuali. :
FrancoAngeli; 1993.
(4) Di Castri G. Project management per l'edilizia: ingegneria economica: applicazioni e sviluppo.: Flaccovio;
2009.
(5) Lucarelli MT. Corso di Project Management e Processo Edilizio. 2007.
(6) Grigoriadis D. Project management e progettazione architettonica: gestione e controllo del progetto: dalla
ideazione alla costruzione. : Dei; 2009.
(7) Kerzner H. Project management: pianificazione, scheduling e controllo dei progetti. : Hoepli; 2014.
(8) Gaio L. Project management: elementi teorici e applicazioni. Metodi ed evidenze empiriche per il turismo:
Metodi ed evidenze empiriche per il turismo. : FrancoAngeli; 2010.
(9) Amato R, Chiappi R. Tecniche di project management. Pianificazione e controllo dei progetti. :
FrancoAngeli; 2006.
(10) Killian WP. Project management-Future organizational concepts. Marquette Business Review 1971;2:90-
107.
(11) Czernigowska A. Earned value method as a tool for project control. Budownictwo i Architektura
2008;3:15-32.
(12) Kazi AS. Knowledge management in the construction industry: A socio-technical perspective. : IGI Global;
2005.
(13) Gould FE, Joyce NE. Construction project management. : Prentice Hall; 2009.
(14) Gottfried A, Di Giuda GM. Ergotecnica edile. : Società Editrice Esculapio; 2011.
152
(15) ISFOL, Istituto per lo sviluppo della formazione professionale dei lavoratori. Costruzioni; le previsioni al
2016: valore aggiunto, produttività ed occupazione. 2013.
(16) AITEC, Associazione Italiana Tecnico Economica Cemento. Relazione Annuale 2015. 2015.
(17) ANCE, Associazione Nazionale Costruttori Edili. Osservatorio congiunturale sull’industria delle
costruzioni. 2017.
(18) Pisani MA. Consolidamento delle strutture – Guida ai criteri, ai materiali e alle tecniche più utilizzati. :
Hoepli; 2016.
(19) Archibald RD. Project management. La gestione di progetti e programmi complessi: La gestione di
progetti e programmi complessi. : FrancoAngeli; 2014.
(20) Amato R, Basile G, Chiappi R. Il Project Management nell'organizzazione aziendale. : Alemanni; 1989.
(21) Guida PL. Metodo o metodologia? Project Manager (IL) 2013.
(22) Guida PL. Il Project Management. Secondo la Norma UNI ISO 21500: Secondo la Norma UNI ISO 21500.
: FrancoAngeli; 2015.
(23) Available at: http://www.iso.org/iso/home/standards.htm. Accessed Giugno, 2017.
(24) Buttrick Robert. PRINCE2 and the National and International Standards. 2012.
(25) Michele S. The Software Project Manager's Bridge to Agility. : Pearson Education India; 2008.
(26) Catalin D. Analysis of the main international standards and guidelines about project risk management.
Revista Economica 2012(2):100-104.
(27) Ilieş L, Crişan E, Mureşan IN. Best practices in project management. Review of International Comparative
Management 2010;11(1):43-51.
(28) Available at: https://www.pmi.org/. Accessed Giugno, 2017.
(29) Ravaglia R. Project Management: evoluzione e prospettive. U&C rivista digitale 2010 Marzo 2010:27-46.
153
(30) Project management frameworks: comparative analysis. IPMA 2010 World Congress, Istanbul, Turkey;
2010.
(31) Drob C, Zichil V. Overview regarding the main guidelines, standards and methodologies used in project
management. Journal of Engineering Studies and Research 2013;19(3):26.
(32) Gargantini C. Relevance of project management standards and their main characteristics. Comparison
among four project management standards and development of a method that combines the most useful
features. 2016.
(33) PMI PMI. PMBOK Guide: A guide to the project management body of knowledge. 5th ed.; 2012.
(34) IPMA, International Project Management Association. Guida alla certificazione in Project Management.
2017.
(35) Available at: http://ipma.it/ipma_/. Accessed Giugno, 2017
(36) International Project Management Association, Caupin G. IPMA competence baseline: ICB; Version 3.0.
: Internat. Project Management Association; 2006.
(37) Office of Government Commerce. Managing successful projects with PRINCE2. : The Stationery Office;
2009.
(38) Available at: http://www.somos.com/. Accessed Giugno, 2017
(39) Portny SE. Project management for dummies. : John Wiley & Sons; 2010.
(40) ISO I. 10006: 2003: Quality Management systems-Guidelines for quality management in projects.
Ontario: International Organization for Standardization (ISO) 2003.
(41) Stellingwerf R, Zandhuis A. ISO 21500 Guidance on project management–A Pocket Guide. : Van Haren;
2013.
(42) Ghosh S, Forrest D, DiNetta T, Wolfe B, Lambert DC. Enhance PMBOK® by Comparing it with P2M, ICB,
PRINCE2, APM and Scrum Project Management Standards. PM World Today 2012;14(1):1-77.
(43) Tavan F, Hosseini M. Comparison and analysis of PMBOK 2013 and ISO 21500. Journal of Project
Management 2016;1(1):27-34.
154
(44) Rehacek P. Standards ISO 21500 and PMBOK Guide for Project Management. International Journal of
Engineering Science and Innovative Technology 2014;3(1):288-295.
(45) Eberle A, Meyer H, Rosen D. A comparison of PMI and IPMA approaches. Analysis to support the project
management standard and certification system selection 2011.
(46) Webber W. IT Project Management essentials. 2009.
(47) VersioOne. 11th Annual State of Agile Report, 2010.
(48) Latella R. Balancing traditional and agile project management in construction small and micro
enterprises. 2010.
(49) Liker J. The Toyota Way (2004), 14 Management Principles from the World’s Greatest Manufacturer.
McGrall-Hill Professional 2004.
(50) Yllén Johansson M. Agile project management in the construction industry: An inquiry of the
oppurtunities in construction projects. 2012.
(51) Augustine S. Managing agile projects. : Prentice Hall PTR; 2005.
(52) Beck K, Beedle M, Van Bennekum A, Cockburn A, Cunningham W, Fowler M, et al. Manifesto for agile
software development. 2001.
(53) Moniruzzaman A, Hossain DSA. Comparative study on agile software development methodologies. arXiv
preprint arXiv:1307.3356 2013.
(54) De Filippis M. Project management e gestione dello sviluppo software nelle PMI: proposta e applicazione
di un approccio integrato. 2015.
(55) Hunt J. Agile software construction. : Springer; 2006.
(56) Schwaber K, Sutherland J. The Scrum guide-the definitive guide to Scrum: The rules of the game, July
2011. Available on-line at: http://www.Scrum.org/storage/Scrumguides/Scrum% 20Guide 2016.
(57) Takeuchi H, Nonaka I. 16 The new new product development game. Japanese Business: Part 1, Classics
Part 2, Japanese management Vol.2: Part 1, Manufacturing and production Part 2, Automotive industry Vol.3:
155
Part 1, Banking and finance Part 2, Corporate strategy and inter-organizational relationships Vol.4:
1998;64(1):321.
(58) Alberto P. Corso di Project Management. 2016.
(59) Donè A. Diffusione delle metodologie di Agile Software Development. Risultati di una survey. 2013.
(60) Schwaber K, Beedle M. Agile software development with Scrum. : Prentice Hall Upper Saddle River; 2002.
(61) Cervone HF. Understanding agile project management methods using Scrum. OCLC Systems & Services:
International digital library perspectives 2011;27(1):18-22.
(62) Alliance S. Advice on conducting the Scrum of Scrums meeting 2011.
(63) Giannì R. Ottimizzazione del processo di sviluppo software attraverso l’adozione di una metodologia
agile: un caso di applicazione nel settore del financial engineeringPolitecnico di Milano; 2011.
(64) https://www.atlassian.com. Accessed Giugno, 2017
(65) Anderson DJ. Kanban: successful evolutionary change for your technology business. : Blue Hole Press;
2010.
(66) Medinilla Á. Agile management: Leadership in an agile environment. : Springer Science & Business
Media; 2012.
(67) http://www.mokabyte.it. Accessed Giugno, 2017
(68) Bahceci D, Karrbom T. Agile perspectives in construction projects–How to improve efficiency in the
design phase. 2014.
(69) Cockburn A, Highsmith J. Agile software development, the people factor. Computer 2001;34(11):131-
133.
(70) https://www.velir.com. Accessed Giugno, 2017
(71) Is agile project management applicable to construction? Proceedings of the 14th Annual Conference of
the International Group for Lean Construction; 2006.
156
(72) Axel Ekström, Emma Pettersson. Agile project management in the design stage–Construction projects
possibilities to apply agile methodsKTH Royal Institute of Technology in Stockholm; 2016.
(73) Denning S. Why Agile can be a game changer for managing continuous innovation in many industries.
Strategy & Leadership 2013;41(2):5-11.
(74) http://www.agilemodeling.com. Accessed Giugno, 2017
(75) Everts P, Pries F, Nijhuis S. Towards agile projectmanagement and social innovation in the construction
industry. Management and Innovation for a Sustainable Built Environment 2011.
(76) Pries F, Doree A, Van Der Veen B, Vrijhoef R. The role of leaders' paradigm in construction industry
change. Constr Manage Econ 2004;22(1):7-10.
(77) Re-conceptualizing Lean in Construction Environments–„the case for “AgiLean” Project Management‟.
top related