Agile Project Management per la gestione di progetti nell ... · POLITECNICO DI MILANO Facoltà di...

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

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

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

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.

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.

https://it.wikipedia.org/wiki/Ingegneria_gestionale

https://it.wikipedia.org/wiki/Economia_aziendale

https://it.wikipedia.org/wiki/Progetto

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.

https://it.wikipedia.org/wiki/Offerta

https://it.wikipedia.org/wiki/Bene_(economia)

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 .

https://en.wikipedia.org/wiki/Georgia_Institute_of_Technology

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.

https://it.wikipedia.org/wiki/Metodo

https://it.wikipedia.org/wiki/Project_management

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.

http://it.prince2.wiki/index.php?title=Avvio_di_un_progetto&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Direzione_di_un_progetto&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Inizio_di_un_progetto&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Controllo_di_una_fase&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Gestione_della_consegna_del_prodotto&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Gestione_dei_limiti_di_fase&action=edit&redlink=1

http://it.prince2.wiki/index.php?title=Chiusura_di_un_progetto&action=edit&redlink=1

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;

http://it.prince2.wiki/index.php?title=Inizio_di_un_progetto&action=edit&redlink=1

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);

http://it.prince2.wiki/index.php?title=Controllo_di_una_fase&action=edit&redlink=1

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.

http://it.prince2.wiki/index.php?title=Gestione_della_consegna_del_prodotto&action=edit&redlink=1

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;


http://it.prince2.wiki/index.php?title=Chiusura_di_un_progetto&action=edit&redlink=1

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.

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

https://it.wikipedia.org/wiki/Iterazione

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.

https://it.wikipedia.org/wiki/Lingua_inglese

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.

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.

http://www.iso.org/iso/home/standards.htm

https://www.pmi.org/

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.

http://ipma.it/ipma_/

http://www.somos.com/

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:

http://www.scrum.org/storage/scrumguides/Scrum%25

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.

https://www.atlassian.com/

http://www.mokabyte.it/

https://www.velir.com/

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‟.

http://www.agilemodeling.com/

Agile Project Management per la gestione di progetti nell ... · POLITECNICO DI MILANO Facoltà di...

Documents

Transcript of Agile Project Management per la gestione di progetti nell ... · POLITECNICO DI MILANO Facoltà di...