PMBOK-2004

Guida al
Project Management
Body of Knowledge
Terza edizione
(Guida al PMBOK)
un American National Standard

ANSI/PMI 99-001-2004
Guida al
Project Management
Body of Knowledge
Terza edizione
(Guida al PMBOK)
ISBN: 1-930699-71-9 (brossura Italiano)

ISBN: 1-930699-45-X (brossura Inglese)
ISBN: 1-930699-50-6 (CD-ROM Inglese)
Pubblicato da:
Project Management Institute, Inc.

Four Campus Boulevard
Newtown Square, Pennsylvania 19073-3299 USA.
Telefono: +610-356-4600
Fax: +610-356-4647
E-mail: pmihq@pmi.org
Sito Web: www.pmi.org
2004 Project Management Institute, Inc. Tutti i diritti riservati.

PMI, il logo PMI, PMP, il logo PMP, PMBOK, Project Management Journal, PM Network e il logo PMI
Today sono marchi registrati del Project Management Institute, Inc. Per un elenco completo dei marchi PMI,
contattare l'ufficio legale di PMI.
L'ufficio responsabile delle pubblicazioni di PMI sar lieto di ricevere correzioni o commenti sui propri scritti. Per inviare
commenti su errori tipografici, di formattazione o di altro tipo, fare una copia della pagina del libro in questione,
contrassegnare l'errore e inviarla a: Book Editor, PMI Publications, Four Campus Boulevard, Newtown Square, PA 190733299 USA. In alternativa, scrivere all'indirizzo e-mail:booked@pmi.org.
I manuali PMI sono disponibili a prezzi scontati per grandi quantit da utilizzare come iniziative speciali o vendite
promozionali, per programmi di formazione aziendale e per altri programmi formativi. Per ulteriori informazioni,
scrivere a Bookstore Administrator, PMI Publications, Four Campus Boulevard, Newtown Square, PA 19073-3299
USA. In alternativa, scrivere all'indirizzo e-mail: booksonline@pmi.org. Oppure, rivolgersi alla propria libreria di
fiducia.
Stampato negli Stati Uniti d'America. fatto divieto di riprodurre o trasmettere qualsiasi sezione di questo lavoro
sotto qualsiasi forma o mediante qualsiasi mezzo, sia esso elettronico, manuale, per fotocopiatura o registrazione o
mediante sistemi di recupero e memorizzazione dati, senza avere ottenuto la previa autorizzazione scritta da parte
dell'editore.
La carta utilizzata in questo manuale conforme allo standard per la carta stampata emanato dalla National
Information Standards Organization (Z39.481984).
10 9 8 7 6 5 4 3 2 1
NOTA
Le pubblicazioni sugli standard e sulle istruzioni del Project Management Institute, Inc. (PMI), di
cui fa parte il presente documento, vengono sviluppate mediante un processo di elaborazione degli
standard basato sul consenso volontario. Questo processo riunisce i volontari e/o ricerca l'opinione
di persone interessate all'argomento trattato nella presente pubblicazione. Sebbene PMI amministri
il processo e stabilisca quali regole promuovere a garanzia della correttezza nella creazione del
consenso, non redige il documento e non esamina, valuta o verifica in modo autonomo
l'accuratezza e la completezza delle informazioni o la solidit dei criteri contenuti nelle relative
pubblicazioni su standard e direttive.
PMI declina qualsiasi responsabilit per lesioni a persone o beni o per altri danni di qualsivoglia
natura, siano essi particolari, indiretti, conseguenti o compensativi, derivanti direttamente o
indirettamente dalla pubblicazione, dall'applicazione o dalla fiducia accordata a questo documento.
PMI declina qualsiasi responsabilit e non fornisce alcuna garanzia, espressa o implicita, in merito
all'accuratezza o alla completezza delle informazioni pubblicate nel presente documento, e declina
altres qualsiasi responsabilit e non garantisce che tali informazioni rispondano a obiettivi o
esigenze particolari. PMI non fornisce alcuna garanzia in merito alle prestazioni dei singoli
prodotti e servizi dei produttori o fornitori in virt di questo standard o della guida.
PMI pubblica e rende disponibile questo documento senza tuttavia impegnarsi a prestare alcun
servizio professionale o di altra natura per o per conto di qualsiasi persona fisica o giuridica; PMI
non si impegna inoltre a svolgere compiti spettanti a qualsiasi persona fisica o giuridica a favore di
terzi. Chiunque utilizzi questo documento deve affidarsi alla propria capacit di giudizio o, a
seconda dei casi, pu richiedere il parere di un professionista competente per stabilire il grado di
attenzione necessario in determinate circostanze. Le informazioni e gli altri standard
sull'argomento trattato nella presente pubblicazione possono essere resi disponibili anche da altre
fonti, che l'utente pu consultare per disporre di altre opinioni o informazioni non contenute nel
presente documento.
PMI non dispone dell'autorit per implementare, n si impegna ad implementare, la conformit ai
contenuti del presente documento. PMI non certifica, controlla o ispeziona i prodotti, i progetti o le
installazioni a fini del rispetto delle norme di sicurezza e sanitarie. Qualsiasi certificazione o
dichiarazione di conformit a qualsiasi informazione in materia sanitaria o di sicurezza riportata nel
presente documento non potr essere attribuita a PMI ma sar di responsabilit esclusiva dall'ente di
certificazione competente o dalla persona che ha effettuato la dichiarazione.
SOMMARIO
Prefazione alla terza edizione ...........................................................vii
Il contesto del Project Management ...................................................1
Introduzione............................................................................................... 3
1.1 Obiettivo della Guida al PMBOK .................................................... 3
1.2 Che cos un progetto? .................................................................... 5
1.3 Che cos il Project Management? .................................................. 8
1.4 La struttura della Guida al PMBOK ................................................ 9
1.5 Aree di esperienza.......................................................................... 12
1.6 Il contesto del Project Management............................................... 16
Ciclo di vita del progetto e Struttura organizzativa............................. 19
2.1 Il ciclo di vita del progetto ............................................................... 19
2.2 Stakeholder di progetto .................................................................. 24
2.3 Influenza delle strutture organizzative ........................................... 27
Lo standard per il Project Management di un progetto ..................35

Processi di Project Management per un progetto............................... 37
3.1 Processi di Project Management ................................................... 39
3.2 Gruppi di processi di Project Management.................................... 40
3.3 Interazioni tra processi ................................................................... 67
3.4 Mappatura dei processi di Project Management ........................... 69
Aree di conoscenza di Project Management ...................................71

Introduzione............................................................................................. 73
Diagrammi di flusso dei processi............................................................ 73
Principali documenti di progetto.............................................................. 76
Gestione dellintegrazione di progetto ................................................. 77
4.1 Sviluppare il Project Charter........................................................... 81
4.2 Sviluppare la descrizione preliminare dell'ambito del progetto ..... 86
4.3 Sviluppare il piano di Project Management ................................... 88
4.4 Dirigere e gestire l'esecuzione del progetto................................... 91
4.5 Monitorare e controllare il lavoro del progetto ............................... 94
4.6 Controllo integrato delle modifiche................................................. 96
4.7 Chiudere il progetto ...................................................................... 100
Gestione dell'ambito del progetto....................................................... 103
5.1 Pianificazione dell'ambito ............................................................. 107
5.2 Definizione dell'ambito.................................................................. 109
.5.3 Creare la WBS.............................................................................. 112
5.4 Verifica dell'ambito........................................................................ 118
5.5 Controllo dell'ambito ..................................................................... 119
Gestione dei tempi di progetto ............................................................ 123
6.1 Definizione delle attivit................................................................ 127
6.2 Sequenzializzazione delle attivit ................................................ 130
6.3 Stima delle risorse delle attivit.................................................... 135
6.4 Stima della durata delle attivit .................................................... 139
6.5 Sviluppo della schedulazione....................................................... 143
6.6 Controllo della schedulazione ...................................................... 152
Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
Sommario
Gestione dei costi di progetto.............................................................. 157

7.1 Stima dei costi ...............................................................................161
7.2 Allocazione dei costi......................................................................167
7.3 Controllo dei costi..........................................................................171
Gestione della qualit di progetto ....................................................... 179
8.1 Pianificazione della qualit............................................................183
8.2 Effettuare l'assicurazione qualit ..................................................187
8.3 Esecuzione del controllo di qualit ...............................................190
Gestione delle risorse umane di progetto .......................................... 199
9.1 Pianificazione delle risorse umane ...............................................202
9.2 Acquisire il gruppo di progetto ......................................................209
9.3 Sviluppare il gruppo di progetto ....................................................212
9.4 Gestire il gruppo di progetto..........................................................215
Gestione della comunicazione di progetto ......................................... 221
10.1 Pianificazione della comunicazione..............................................225
10.2 Distribuzione delle informazioni ....................................................228
10.3 Reporting delle prestazioni ...........................................................231
10.4 Gestione degli stakeholder ...........................................................235
Gestione dei rischi di progetto ............................................................ 237
11.1 Pianificazione della gestione dei rischi.........................................242
11.2 Identificazione dei rischi ................................................................246
11.3 Analisi qualitativa dei rischi ...........................................................249
11.4 Analisi quantitativa del rischio.......................................................254
11.5 Pianificazione della risposta ai rischi ............................................260
11.6 Monitoraggio e controllo dei rischi ................................................264
Gestione dellapprovvigionamento di progetto ................................. 269
12.1 Pianificare gli acquisti....................................................................274
12.2 Pianificare le forniture ...................................................................281
12.3 Richiesta di risposte dai fornitori...................................................284
12.4 Selezionare i fornitori ....................................................................286
12.5 Amministrazione del contratto ......................................................290
12.6 Chiusura del contratto ...................................................................295
Appendici ......................................................................................... 299

Modifiche alla Terza edizione............................................................... 301
Evoluzione della Guida al Project Management Body of
Knowledge del PMI ...................................................................... 309
Redattori e revisori della Terza edizione della Guida al PMBOK .... 321
Estensioni per le aree applicative........................................................ 329
Altre fonti di informazioni sul Project Management .......................... 333
Riepilogo delle aree di conoscenza del Project Management .......... 337
Glossario e indice............................................................................ 343

Riferimenti bibliografici ........................................................................ 345
Glossario ................................................................................................ 347
Indice ...................................................................................................... 381
ii

ELENCO TABELLE E FIGURE

Figura 1-1. Visione dinsieme delle aree di conoscenza di Project Management
e dei processi di Project Management..................................................................... 11
Figura 1-2. Aree di esperienza di cui necessita il gruppo di Project Management....... 13
Figura 2-1. Costo e livello del personale tipici di un progetto nel corso del ciclo
di vita del progetto....................................................................................................... 21
Figura 2-2. Influenza dei stakeholder nel corso del tempo............................................... 21
Figura 2-3. Tipica sequenza delle fasi in un ciclo di vita del progetto ............................ 23
Figura 2-4. Relazione tra il ciclo di vita del prodotto e del progetto ................................ 24
Figura 2-5. Relazione tra gli stakeholder e il progetto ....................................................... 25
Figura 2-6. Influenza delle strutture organizzative sui progetti ........................................ 28
Figura 2-7. Struttura organizzativa funzionale .................................................................... 29
Figura 2-8. Organizzazione per progetti ............................................................................... 29
Figura 2-9. Organizzazione a matrice debole ...................................................................... 30
Figura 2-10. Organizzazione a matrice equilibrata ............................................................. 30
Figura 2-11. Organizzazione a matrice forte........................................................................ 31
Figura 2-12. Organizzazione composita............................................................................... 31
Figura 3-1. Ciclo Plan-Do-Check-Act ................................................................................ 39
Figura 3-2. Gruppi di processi di Project Management descritti secondo il ciclo
Plan-Do-Check-Act .................................................................................................. 40
Figura 3-3. Legenda del diagramma di flusso..................................................................... 41
Figura 3-4. Riepilogo ad alto livello delle interazioni dei gruppi di processi ................. 42
Figura 3-5. Confini del progetto............................................................................................. 43
Figura 3-6. Gruppo di processi di avvio ............................................................................... 44
Tabella 3-1. Sviluppare il Project Charter: input e output.................................................. 45
Tabella 3-2. Sviluppare la descrizione preliminare dellambito di progetto: input e
output............................................................................................................................. 45
Figura 3-7. Gruppo di processi di pianificazione................................................................ 47
Tabella 3-3. Sviluppare il piano di Project Management: input e output........................ 48
Tabella 3-4. Pianificazione dellambito: input e output...................................................... 48
Tabella 3-5. Definizione dellambito: input e output........................................................... 49
Tabella 3-6. Creare la WBS: input e output.......................................................................... 49
Tabella 3-7. Definire le attivit: input e output..................................................................... 49
Tabella 3-8. Sequenzializzazione delle attivit: input e output ......................................... 50
Tabella 3-9. Stima delle risorse delle attivit: input e output............................................ 50
Tabella 3-10. Stima della durata delle attivit: input e output........................................... 50
Tabella 3-11. Sviluppo della schedulazione: input e output ............................................. 51
Tabella 3-12. Stima dei costi: input e output ....................................................................... 51
Tabella 3-13. Allocazione dei costi: input e output............................................................. 51
Tabella 3-14. Pianificazione della qualit: input e output .................................................. 52
Tabella 3-15. Pianificazione delle risorse umane: input e output .................................... 52
Tabella 3-16. Pianificazione della comunicazione: input e output................................... 52
Tabella 3-17. Pianificazione della gestione dei rischi: input e output ............................. 53
Tabella 3-18. Identificare i rischi: input e output................................................................. 53
Tabella 3-19. Analisi qualitativa del rischio: input e output .............................................. 53
Tabella 3-20. Analisi quantitativa del rischio: input e output............................................ 54

iii
Sommario
Tabella 3-21. Pianificazione della risposta ai rischi: input e output .................................54

Tabella 3-22. Pianificare gli acquisti: input e output...........................................................54
Tabella 3-23. Pianificare le forniture: input e output...........................................................55
Figura 3-8. Gruppo di processi di esecuzione.....................................................................55
Tabella 3-24. Dirigere e gestire lesecuzione del progetto: input e output......................56
Tabella 3-25. Effettuare lassicurazione qualit: input e output........................................56
Tabella 3-26. Acquisire il gruppo di progetto: input e output............................................57
Tabella 3-27. Sviluppare il gruppo di progetto: input e output .........................................57
Tabella 3-28. Distribuzione delle informazioni: input e output..........................................57
Tabella 3-29. Richiesta di risposte dai fornitori: input e output........................................58
Tabella 3-30. Selezionare i fornitori: input e output ............................................................58
Figura 3-9. Gruppo di processi di monitoraggio e controllo.............................................60
Tabella 3-31. Monitorare e controllare il lavoro del progetto: input e output .................61
Tabella 3-32. Controllo integrato delle modifiche: input e output ....................................61
Tabella 3-33. Verifica dellambito: input e output ................................................................62
Tabella 3-34. Controllo dellambito: input e output.............................................................62
Tabella 3-35. Controllo della schedulazione: input e output.............................................62
Tabella 3-36. Controllo dei costi: input e output..................................................................63
Tabella 3-37. Esecuzione del controllo di qualit: input e output.....................................63
Tabella 3-38. Gestire il gruppo di progetto: input e output................................................63
Tabella 3-39. Reporting delle prestazioni: input e output ..................................................64
Tabella 3-40. Gestire gli stakeholder: input e output..........................................................64
Tabella 3-41. Monitoraggio e controllo dei rischi: input e output.....................................65
Tabella 3-42. Amministrazione del contratto: input e output ............................................65
Figura 3-10. Gruppo di processi di chiusura .......................................................................66
Tabella 3-43. Chiudere il progetto: input e output...............................................................67
Tabella 3-44. Chiusura del contratto: input e output ..........................................................67
Figura 3-11. Interazione dei gruppi di processi in un progetto.........................................68
Figura 3-12. Triangolo dei gruppi di processi di Project Management ...........................69
Tabella 3-45. Collegamento dei processi di Project Management ai gruppi
di processi di Project Management e alle aree di conoscenza ............................70
Figura III-1. Legenda dei diagrammi di flusso dei processi...............................................73
Figura III-2. Tre principali documenti di progetto e la loro relazione con i
rispettivi componenti...................................................................................................75
Figura 4-1. Visione dinsieme della gestione dellintegrazione di progetto....................79
Figura 4-2. Diagramma di flusso dei processi di gestione dell'integrazione
di progetto. ....................................................................................................................80
Figura 4-3. Sviluppare il Project Charter: Input, Strumenti e tecniche e Output............82
Figura 4-4. Sviluppare la descrizione preliminare dell'ambito del progetto Input,
Strumenti e tecniche e Output ...................................................................................87
Figura 4-5. Sviluppare il piano di Project Management: Input, Strumenti e
tecniche e Output .........................................................................................................89
Figura 4-6. Dirigere e gestire l'esecuzione del progetto: Input, Strumenti e
Figura 4-7. Monitorare e controllare il lavoro del progetto: Input, Strumenti e
Figura 4-8. Controllo integrato delle modifiche: Input, Strumenti e tecniche
e Output..........................................................................................................................98
Figura 4-9. Chiudere il progetto: Input, Strumenti e tecniche e Output ....................... 100
Figura 5-1. Visione dinsieme della gestione dell'ambito del progetto......................... 105
Figura 5-2. Diagramma di flusso dei processi di gestione dell'ambito del progetto.. 106
Figura 5-3. Pianificazione dell'ambito: Input, Strumenti e tecniche e Output ............. 107
Figura 5-4. Definizione dell'ambito: Input, Strumenti e tecniche e Output .................. 109
Figura 5-5. Creare la WBS: Input, Strumenti e tecniche e Output ................................. 113
Figura 5-6. Esempio di struttura di scomposizione del lavoro con alcune
diramazioni scomposte fino ai Work Package..................................................... 114
iv

Figura 5-7. Esempio di struttura di scomposizione del lavoro organizzata per

fasi ................................................................................................................................ 116
Figura 5-8. Esempio di scomposizione del lavoro per articoli di materiale per
la Difesa....................................................................................................................... 116
Figura 5-9. Verifica dell'ambito: Input, Strumenti e tecniche e Output ......................... 118
Figura 5-10. Controllo dell'ambito: Input, Strumenti e tecniche e Output.................... 120
Figura 6-1. Visione dinsieme della gestione dei tempi di progetto .............................. 125
Figura 6-2. Diagramma di flusso dei processi di gestione dei tempi di progetto ....... 126
Figura 6-3. Definire le attivit: Input, Strumenti e tecniche e Output............................. 127
Figura 6-4. Sequenzializzazione delle attivit: Input, Strumenti e tecniche e
Output.......................................................................................................................... 130
Figura 6-5. Metodo del diagramma di precedenza ........................................................... 131
Figura 6-6: metodo del diagramma a frecce...................................................................... 132
Figura 6-7. Stima delle risorse delle attivit: Input, Strumenti e tecniche e Output.... 136
Figura 6-8. Stima della durata delle attivit: Input, Strumenti e tecniche e Output..... 139
Figura 6-9. Visione d'insieme dello sviluppo della schedulazione: Input,
Strumenti e tecniche e Output................................................................................. 143
Figura 6-10. Schedulazione di progetto: esempi di grafici ............................................. 150
Figura 6-11. Panoramica del controllo della schedulazione: Input, Strumenti
e tecniche e Output ................................................................................................... 152
Figura 7-1. Visione dinsieme della gestione dei costi di progetto................................ 159
Figura 7-2. Diagramma di flusso dei processi di gestione dei costi di progetto......... 160
Figura 7-3. Stima dei costi: Input, Strumenti e tecniche e Output................................. 162
Figura 7-4. Allocazione dei costi: Input, Strumenti e tecniche e Output ...................... 167
Figura 7-5. Flusso di cassa, baseline dei costi e visualizzazione dei
finanziamenti .............................................................................................................. 170
Figura 7-6. Controllo dei costi: Input, Strumenti e tecniche e Output........................... 171
Figura 7-7. Esempio di rapporto sullandamento di progetto in forma di
grafico.......................................................................................................................... 174
Figura 8-1. Visione dinsieme della gestione della qualit di progetto ......................... 182
Figura 8-2. Diagramma di flusso dei processi di gestione della qualit di
progetto .......................................................................................................................183
Figura 8-3. Pianificazione della qualit: Input, Strumenti e tecniche e Output............ 184
Figura 8-4. Effettuare l'assicurazione qualit: Input, Strumenti e tecniche e
Output.......................................................................................................................... 188
Figura 8-5. Esecuzione del controllo di qualit: Input, Strumenti e tecniche e
Output.......................................................................................................................... 191
Figura 8-6. Diagramma di causa-effetto. ............................................................................ 192
Figura 8-7. Esempio di una carta di controllo delle prestazioni di una
schedulazione di progetto........................................................................................ 193
Figura 8-8. Esempio di diagramma di flusso di processo .............................................. 194
Figura 8-9. Diagramma di Pareto......................................................................................... 195
Figura 9-1. Visione dinsieme della gestione delle risorse umane di progetto............ 201
Figura 9-2. Diagramma di flusso dei processi di gestione delle risorse umane di
progetto .......................................................................................................................202
Figura 9-3. Pianificazione delle risorse umane: Input, Strumenti e tecniche e
Output.......................................................................................................................... 203
Figura 9-4. Formati di definizione di ruoli e responsabilit............................................. 205
Figura 9-5. Matrice di assegnazione delle responsabilit (RAM) che utilizza un
formato RACI.............................................................................................................. 206
Figura 9-6. Istogramma delle risorse illustrativo .............................................................. 208
Figura 9-7. Acquisire il gruppo di progetto: Input, Strumenti e tecniche e
Output.......................................................................................................................... 209
Figura 9-8. Sviluppare il gruppo di progetto: Input, Strumenti e tecniche e
Output.......................................................................................................................... 212
Figura 9-9. Gestire il gruppo di progetto: Input, Strumenti e tecniche e
Output.......................................................................................................................... 215

Sommario
Figura 10-1. Visione dinsieme della gestione della comunicazione di progetto........ 222
Figura 10-2. Diagramma di flusso dei processi di gestione della
comunicazione di progetto...................................................................................... 223
Figura 10-3. Comunicazione: modello di base ................................................................. 224
Figura 10-4. Pianificazione della comunicazione: Input, Strumenti e
tecniche e Output ...................................................................................................... 225
Figura 10-5. Distribuzione delle informazioni: Input, Strumenti e tecniche e
Output.......................................................................................................................... 228
Figura 10-6. Reporting delle prestazioni: Input, Strumenti e tecniche e Output......... 231
Figura 10-7. Esempio di report sulle prestazioni a tabella.............................................. 234
Figura 10-8. Gestione degli stakeholder: Input, Strumenti e tecniche e Output......... 235
Figura 11-1. Visione dinsieme della gestione del rischio di progetto.......................... 239
Figura 11-2. Diagramma di flusso dei processi di gestione dei rischi di progetto..... 241
Figura 11-3. Pianificazione della gestione dei rischi: Input, Strumenti e
tecniche e Output ...................................................................................................... 242
Figura 11-4. Esempio di struttura di scomposizione dei rischi (RBS).......................... 244
Figura 11-5. Definizione delle scale di impatto per quattro obiettivi di progetto ........ 245
Figura 11-6. Identificare i rischi: Input, Strumenti e tecniche e Output ........................ 246
Figura 11-7. Analisi qualitativa del rischio: Input, Strumenti e tecniche e
Output.......................................................................................................................... 250
Figura 11-8. Matrice di probabilit e impatto..................................................................... 252
Figura 11-9. Analisi quantitativa del rischio: Input, Strumenti e tecniche e
Output.......................................................................................................................... 254
Figura 11-10. Intervallo delle stime dei costi di progetto nel corso dei
colloqui sui rischi ...................................................................................................... 256
Figura 11-11. Esempi di distribuzioni di probabilit comunemente utilizzate............. 256
Figura 11-12. Diagramma dellalbero delle decisioni....................................................... 258
Figura 11-13. Risultati della simulazione dei rischi del costo........................................ 259
Figura 11-14. Pianificazione della risposta ai rischi: Input, Strumenti e
tecniche e Output .................................................................................................................. 260
Figura 11-15. Monitoraggio e controllo dei rischi: Input, Strumenti e tecniche
e Output................................................................................................................................... 265
Figura 12-1. Visione dinsieme della gestione dellapprovvigionamento di
progetto................................................................................................................................... 272
Figura 12-2. Diagramma di flusso dei processi di gestione dell
approvvigionamento di progetto............................................................................ 273
Figura 12-3. Pianificare gli acquisti: Input, Strumenti e tecniche e Output ................. 274
Figura 12-4. Pianificare le forniture: Input, Strumenti e tecniche e Output ................. 281
Figura 12-5. Richiesta di risposte dai fornitori: Input, Strumenti e tecniche
e Output ...................................................................................................................... 284
Figura 12-6. Selezionare i fornitori: Input, Strumenti e tecniche e Output................... 287
Figura 12-7. Amministrazione del contratto: Input, Strumenti e tecniche
e Output ...................................................................................................................... 291
Figura 12-8. Chiusura del contratto: Input, Strumenti e tecniche e Output................. 296
Tabella 1. Modifiche strutturali ............................................................................................ 301
Tabella 2: Modifiche al capitolo 4........................................................................................ 304
Tabella 6. Modifiche al capitolo 8........................................................................................ 306
Tabella 7. Modifiche al capitolo 9........................................................................................ 306
Tabella 8. Modifiche al capitolo 10...................................................................................... 306
Tabella 9. Modifiche al capitolo 11 (nessuna modifica ai nomi).................................... 307
Tabella 10. Modifiche al capitolo 12.................................................................................... 307
vi

PREFAZIONE ALLA TERZA
EDIZIONE
Il presente documento sostituisce la Guida al Project Management Body of Knowledge

(Guida al PMBOK) Edizione 2000, pubblicata come seconda edizione della Guida al
PMBOK. Nel periodo intercorso dalla pubblicazione ad oggi, il Project Management
Institute (PMI) ha ricevuto migliaia di preziosi suggerimenti, volti a migliorare la Guida
al PMBOK Edizione 2000, che sono stati esaminati e, in molti, casi integrati nella terza
edizione.
Grazie allapporto ricevuto e allampliamento del Project Management Body of
Knowledge, i volontari del PMI hanno redatto una versione aggiornata della Guida al
PMBOK. Il project charter su cui ci si basati per aggiornare la Guida al PMBOK
Edizione 2000 era fondato sui criteri illustrati di seguito.
Modificare i criteri di inclusione del materiale da generalmente accettati per la
maggior parte dei progetti nella maggior parte dei casi a generalmente
riconosciuti come buona pratica per la maggior parte dei progetti, nella maggior
parte dei casi. Per generalmente riconosciute, si intende che le conoscenze e le
pratiche descritte sono applicabili alla maggior parte dei progetti nella maggior
parte dei casi e che esiste un diffuso consenso sul loro valore e sulla loro utilit.
Aggiungere materiale nuovo che rifletta lapprofondimento delle conoscenze e delle
pratiche nel settore del Project Management tramite la documentazione delle
pratiche stesse, degli strumenti, delle tecniche e di altri importanti elementi ormai
generalmente riconosciuti come buone pratiche.
Ampliare la rilevanza e la trattazione dei gruppi di processi di Project Management.
Ampliare la trattazione dellintegrazione e comunicarne con maggiore efficacia
limportanza per il progetto.
Ampliare la trattazione del gruppo di processi di avvio al fine di descrivere pi
accuratamente la parte iniziale del progetto e lavvio di ciascuna fase.
Ampliare i processi di chiusura.
Valutare tutti i processi per assicurarsi che siano collocati correttamente, completi e
chiari.
Esaminare tutti i testi per accertarsi che siano chiari, completi e pertinenti.
Garantire una terminologia uniforme e la corretta collocazione di input, output,
strumenti di progetto e tecniche. Identificare lorigine di tutti gli input e la
destinazione di tutti gli output.
Modificare il testo, ove possibile, al fine di migliorare la traducibilit del documento
e valutare lopportunit di modificare termini e frasi caratterizzati da connotazioni
culturali negative.
Ampliare lindice e il glossario.
Correggere errori riscontrati nel documento precedente.

vii
Il gruppo di progetto per laggiornamento della Guida al PMBOK 2004 ha aderito

al proprio charter nei termini descritti sopra. Per agevolare i professionisti e i lettori in
genere che gi conoscono la Guida al PMBOK Edizione 2000, viene riportato un
elenco delle principali differenze tra le diverse edizioni.
1.
Nella terza edizione, nella maggior parte dei casi in cui viene presentato un nuovo
processo e in altri casi selezionati in cui i nomi dei processi esistenti sono stati
modificati, questi nomi di processo hanno il formato verbo-oggetto per motivi di
chiarezza.
2.
Per quanto riguarda lo stile, si preferito adottare la forma attiva.
3.
stata chiarita la distinzione tra cicli di vita del progetto e cicli di vita di
prodotto.
4.
Il numero di processi passato da 39 a 44. Sono stati aggiunti 7 processi, 2
processi sono stati eliminati e a 13 processi stato assegnato un altro nome; in
sintesi vi stato un incremento di 5 processi.
5.
Tutti i grafici sono stati numerati e dotati di unetichetta che ne indica la natura di
tabella o di figura.
6.
stata precisata la distinzione tra gruppi di processi di Project Management e
aree di conoscenza. Estata ulteriormente sottolineata. limportanza dei gruppi di
processi.
7.
Il capitolo 3 stato ribattezzato Processi di Project Management per un
progetto ed stato spostato dalla sezione I alla nuova sezione II, denominata ora
Lo standard per il Project Management di un progetto. Inoltre il capitolo 3
stato apprezzabilmente modificato al fine di indicare che i gruppi di processi e gli
input ed output del capitolo sono il fondamento dello standard per il Project
Management di un singolo progetto.
8.
I processi di Project Management sono stati collegati al fine di mostrare
lintegrazione dei processi.
9.
Il glossario stato rivisto e ampliato in misura significativa. I termini specifici
sono stati classificati per evitare confusione.
10. Sono stati aggiunti i processi di seguito elencati:
Sviluppare il Project Charter (sezione 4.1)
Sviluppare la versione preliminare della descrizione dellambito del progetto
(sezione 4.2)
Monitorare e controllare il lavoro del progetto (sezione 4.5)
Chiudere il progetto (sezione 4.7)
Creare la WBS, Struttura di scomposizione del lavoro (sezione 5.3)
Stima delle risorse delle attivit (sezione 6.3)
Gestire il gruppo di progetto (sezione 9.4)
11. Tutti gli input, strumenti, tecniche e output dei processi sono stati modificati al
fine di supportare la maggiore integrazione e il collegamento dei processi.
12. I diagrammi di flusso dei processi sono stati inseriti nei capitoli dal 4 al 12 per
fornire un ulteriore supporto allintegrazione dei processi.
13. stata aggiunta unintroduzione alla sezione III per descrivere i diagrammi di
flusso dei processi e fornire una legenda per i simboli.
La sezione Appendice A Modifiche della terza edizione illustra nel dettaglio i
cambiamenti apportati ai diversi capitoli.
La Guida al PMBOK Terza edizione stata presentata sotto forma di bozza di
documento espositiva alla fine del 2003; una parte consistente dei commenti inoltrati dai
revisori sono stati integrati nella versione definitiva.
Dennis Bolles, PMP
Steve Fahrenkrog, PMP
Project manager
PMI Standards Manager
Gruppo di progetto per laggiornamento della Guida al PMBOK
viii

Tradurre letteratura tecnica in lingue diverse da quella originale non compito

facile. infatti assai probabile che a molti termini specifici corrispondano pi
interpretazioni possibili, o che certe espressioni siano cos saldamente radicate nella lingua
originale da non consentire il trasferimento delle conoscenze, del pensiero o delle idee
nell'altra lingua.
Lo stesso vale per le abbreviazioni, che in alcuni casi sono standardizzate, in altri si
sviluppano attraverso l'uso generalizzato nel settore di riferimento e in altri ancora devono
essere inventate di sana pianta. Per evitare questo inconveniente, stato deciso di
utilizzare le abbreviazioni inglesi. In termini di internazionalizzazione, si tratta senza
dubbio di un compromesso accettabile.

ix
Sezione I
Il contesto del Project
Management
Capitolo 1
Introduzione
Capitolo 2
Ciclo di vita del progetto e Struttura

organizzativa
CAPITOLO 1
Introduzione
Il Project Management Body of Knowledge la summa della conoscenza nellambito
della professione del Project Management. Come avviene in altre professioni (ad
esempio in giurisprudenza, medicina e ragioneria), linsieme delle conoscenze
appannaggio dei professionisti e degli accademici che le praticano e le sviluppano. Il
Project Management Body of Knowledge nel suo complesso racchiude pratiche
tradizionalmente consolidate che sono largamente applicate e pratiche innovative che
stanno emergendo nella professione, materiale pubblicato e materiale non ancora
pubblicato. Ne consegue che il Project Management Body of Knowledge in continua
evoluzione.
Questo capitolo definisce diversi termini chiave e fornisce una visione dinsieme
dellintera Guida al Project Management Body of Knowledge (Guida al PMBOK)
nelle principali sezioni elencate di seguito.
1.1 Obiettivo della Guida al PMBOK
1.2 Che cos un progetto?
1.3 Che cos il Project Management?
1.4 La struttura della Guida al PMBOK
1.5 Aree di esperienza
1.6 Il contesto del Project Management
1.1
Obiettivo della Guida al PMBOK

Lobiettivo principale della Guida al PMBOK identificare quel sottoinsieme del
Project Management Body of Knowledge che viene generalmente riconosciuto come
buona pratica. Con il termine identificare si intende fornire una visione dinsieme
anzich una descrizione particolareggiata. Per universalmente riconosciute, si
intende che le conoscenze e le pratiche descritte sono applicabili alla maggior parte
dei progetti nella maggior parte dei casi e che esiste un diffuso consenso sul loro
valore e sulla loro utilit. Per buona pratica si intende che esiste un consenso
generale sul fatto che la corretta applicazione degli skill, degli strumenti e delle
tecniche che le costituiscono siano in grado di incrementare le possibilit di successo
per una vasta gamma di progetti diversi. Buona pratica non significa tuttavia che la
conoscenza descritta debba sempre essere applicata in maniera uniforme a tutti i
progetti; il gruppo di Project Management ha il compito di determinare ci che
idoneo a un progetto specifico.

Capitolo 1 Introduzione
La Guida al PMBOK fornisce e promuove inoltre un lessico comune da

utilizzare quando si parla, si scrive e si applica il Project Management. Un lessico
standardizzato un elemento essenziale di qualsiasi professione.
Il Project Management Institute utilizza questo documento come riferimento
fondamentale, anche se non unico, per tutti i programmi di sviluppo professionale di
cui si occupa, tra cui:
la certificazione di Project Management Professional (PMP);
i percorsi di formazione e addestramento proposti dagli enti di formazione
registrati dal PMI (Registered Education Providers, R.E.P.);
laccreditamento di programmi educativi nel Project Management.
Come riferimento fondamentale, lo standard non si qualifica come esaustivo n
come onnicomprensivo. Lappendice D dedicata alle aree applicative di competenza,
mentre lappendice E fornisce un elenco di ulteriori fonti di informazione in materia di
Project Management.
Lo standard riguarda unicamente progetti singoli e i processi di Project
Management generalmente riconosciuti come buone pratiche. Esistono altri standard
relativi alla maturit del Project Management dal punto di vista organizzativo, alle
competenze del project manager e ad altre tematiche relative a ci che, in tali ambiti,
viene generalmente riconosciuto come buona pratica. Parte del materiale relativo a tali
altri standard impatta sui singoli progetti. Sarebbe quindi opportuno consultare gli altri
standard per reperire informazioni aggiuntive e per approfondire la conoscenza del
contesto pi ampio in cui vengono realizzati i progetti.
Gli standard di Project Management non riguardano lintera gamma dei dettagli
di tutti gli argomenti. N si dovrebbe ritenere che gli argomenti che non vengono
menzionati siano privi di importanza. Esistono diverse ragioni per cui un argomento
non viene inserito in uno standard: potrebbe essere incluso in un altro standard
correlato, potrebbe essere talmente generico da non avere nulla di applicabile in modo
esclusivo al Project Management, oppure perch non c sufficiente consenso.
Lassenza di consenso implica la presenza di variazioni nellambito della professione
che investono il come, il quando, il dove e persino il chi, allinterno della struttura
organizzativa, debba eseguire una data attivit di Project Management. Spetta alla
struttura organizzativa o al gruppo di Project Management decidere in che modo tali
attivit debbano essere prese in esame nel contesto e nelle circostanze del progetto per
cui viene utilizzata la Guida al PMBOK.
1.1.1
Destinatari della Guida al PMBOK

Il presente standard fornisce un riferimento fondamentale a tutti coloro che sono
interessati alla professione del Project Management. Alcuni dei destinatari ideali sono
elencati di seguito.
Dirigenti di grado superiore.
Program Manager e manager di project manager.
project manager e altri membri del gruppo di progetto.
Membri di un Project Management Office.
Clienti e altri stakeholder.
Manager funzionali i cui dipendenti sono inseriti in gruppi di progetto.
Formatori nel campo del Project Management e di materie correlate.
Consulenti e altri specialisti in Project Management o in settori correlati.
Formatori che sviluppano materiale didattico per il Project Management.
Ricercatori che si occupano dellanalisi del Project Management.

1.2
Che cos un progetto?
1.2.1
Caratteristiche di un progetto
Un progetto uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un

servizio o un risultato unici.
.1
Temporaneo
Laggettivo temporaneo implica che ogni progetto ha un inizio e una fine definiti.
La fine si raggiunge quando gli obiettivi del progetto sono stati raggiunti o quando
appare evidente che sar impossibile raggiungerli, o ancora quando il progetto non
pi necessario e viene chiuso. Temporaneo non significa necessariamente di breve
durata: molti progetti si estendono infatti su pi anni. In ogni caso, tuttavia, la durata
di un progetto un valore finito. I progetti non sono impegni continuativi.
Inoltre, il termine temporaneo non si estende normalmente al prodotto, al
servizio o al risultato creati tramite il progetto. Molti progetti vengono intrapresi per
creare risultati duraturi. Ad esempio, il progetto che ha come obiettivo quello di
erigere un monumento nazionale dar origine a un risultato che ci si aspetta duri per
secoli. I progetti possono anche avere spesso effetti, voluti o non voluti, di natura
sociale, economica e ambientale che sopravvivono di gran lunga al progetto stesso.
La natura temporanea dei progetti pu essere applicata anche ad altri aspetti:
.2
lopportunit o finestra di mercato generalmente temporanea; molti progetti

dispongono infatti di un periodo di tempo limitato per produrre un servizio o un
prodotto;
come unit lavorativa, raramente il gruppo di progetto sopravvive al progetto; si
tratta infatti di un gruppo creato con il solo obiettivo di realizzare il progetto lo
realizzer e quindi, verr sciolto e suoi membri saranno riassegnati ad altri
progetti.
Prodotti, servizi o risultati unici

Un progetto crea dei deliverable unici, che sono prodotti, servizi o risultati. I progetti
possono creare:
un prodotto o manufatto che viene prodotto, quantificabile, che costituisce un
prodotto finale o un componente di un prodotto;
la capacit di erogare un servizio, ad esempio una funzione aziendale a sostegno
della produzione o della distribuzione;
un risultato, come degli esiti o dei documenti. Un progetto di ricerca, per
esempio, sviluppa conoscenza che pu essere utilizzata per determinare se una
certa tendenza sia presente o meno o se un nuovo processo porter benefici alla
societ.
Lunicit unimportante caratteristica dei deliverable di progetto. Ad esempio,
sono state costruite molte migliaia di uffici, ma ognuno di essi unico: diverso
titolare, diversa progettazione, diversa posizione geografica, contraenti diversi e cos
via. La presenza di elementi ripetitivi non modifica la fondamentale unicit del lavoro
di progetto.

.3
Elaborazione progressiva
Lelaborazione progressiva una caratteristica dei progetti che accompagna i concetti
di unicit e temporaneit. Per elaborazione progressiva si intende lo sviluppo in
passaggi successivi e la prosecuzione incrementale1. Ad esempio, lambito del
progetto sar genericamente definito in una prima fase del progetto stesso e verr
quindi esplicitato e arricchito di dettagli mano a mano che il gruppo di progetto
svilupper una conoscenza pi approfondita ed esaustiva del prodotto. Lelaborazione
progressiva non dovrebbe essere confusa con il cambiamento non controllato
dellambito (sezione 5.5).
Lelaborazione progressiva delle specifiche di prodotto deve essere attentamente
coordinata con unappropriata definizione dellambito del progetto, specie nel caso in
cui il progetto venga sviluppato su commessa. Se correttamente definito, lambito del
progetto, vale a dire il lavoro da eseguire, deve essere controllato man mano che il
progetto e le specifiche di prodotto vengono progressivamente elaborati. La relazione
tra le specifiche di prodotto e lambito del progetto sar esaminata ulteriormente
nellintroduzione al capitolo 5.
I due esempi seguenti illustrano luso dellelaborazione progressiva in due
diverse aree applicative.
1.2.2
Lo sviluppo di un impianto chimico inizia con lingegneria di processo per

definire le caratteristiche del processo. Tali caratteristiche sono poi utilizzate per
progettare le principali unit di processo. Questo dato alla base della
progettazione che definisce sia la disposizione dettagliata dello stabilimento sia
le caratteristiche meccaniche delle unit di processo e delle unit ausiliarie. Il
risultato complessivo una serie di disegni di progettazione elaborati come
disegni di fabbricazione e di costruzione dei prodotti. Durante la costruzione, se
necessario, si eseguono interpretazioni e adattamenti soggetti ad opportuna
approvazione. Tale ulteriore elaborazione dei deliverable viene trasferita nei
disegni che riportano i dettagli di costruzione, mentre gli adeguamenti operativi
finali si effettuano durante le fasi di collaudo e di riassetto.
Il prodotto di un progetto di sviluppo economico pu essere inizialmente
definito come Migliorare la qualit della vita dei residenti a reddito pi basso
della collettivit X. Mano a mano che il progetto procede, probabile che i
prodotti vengano descritti in modo pi specifico, ad esempio: Fornire laccesso
a cibo e acqua per 500 residenti a reddito basso della collettivit X. La fase
successiva di elaborazione progressiva potrebbe concentrarsi esclusivamente
sullincremento della produzione e della commercializzazione agricola, mentre
la fornitura dacqua corrente potrebbe essere ritenuta una priorit secondaria
destinata ad essere avviata dopo la fase agricola.
Progetti e lavoro operativo a confronto

Le strutture organizzative eseguono lavoro per raggiungere una serie di obiettivi. In
genere, possibile classificare il lavoro come progetto o come funzioni operative,
anche se le due categorie presentano talvolta aree comuni. Progetti e operazioni
condividono molte delle caratteristiche elencate di seguito:
sono eseguiti da persone;
sono vincolati da risorse limitate;
sono soggetti a pianificazione, esecuzione e controllo.
Progetti e funzioni operative si distinguono principalmente per il fatto che queste
ultime vengono eseguite in modo continuativo e hanno natura ripetitiva, mentre i
progetti hanno natura temporanea e unica.

Gli obiettivi dei progetti e delle funzioni operative sono di natura

fondamentalmente diversa. Lo scopo di un progetto raggiungere il proprio obiettivo
e quindi concludersi. Al contrario, lobiettivo di una funzione operativa continuativa
unazione di supporto al business. I progetti sono diversi poich terminano quando gli
specifici obiettivi vengono raggiunti, mentre le funzioni operative assumono nuovi
obiettivi e il lavoro continua.
I progetti vengono intrapresi a tutti i livelli della struttura organizzativa e
possono coinvolgere da una singola persona a migliaia di persone. La loro durata varia
da qualche settimana a parecchi anni. I progetti possono inoltre coinvolgere una o pi
unit organizzative, come joint venture e raggruppamenti dimpresa. Di seguito si
riportano alcuni casi esemplificativi di progetti.
Sviluppo di un nuovo prodotto o servizio.
Modifiche nella struttura, nelle risorse umane o nello stile di gestione di una
struttura organizzativa.
Progettazione di un nuovo veicolo di trasporto.
Sviluppo o acquisizione di un sistema informativo nuovo o modificato.
Costruzione di un edificio o di impianti.
Realizzazione di un impianto idrico per la collettivit.
Gestione di una campagna elettorale per un incarico politico.
Implementazione di una nuova procedura o di un nuovo processo in una
struttura organizzativa.
Risposta a una richiesta di offerta.
1.2.3
Progetti e pianificazione strategica

I progetti costituiscono un metodo per organizzare quelle attivit a cui i normali limiti
operativi aziendali non consentono di dare una risposta adeguata. I progetti vengono
quindi spesso utilizzati come mezzo per lattuazione del piano strategico di una
struttura organizzativa, a prescindere dal fatto che il gruppo di progetto sia alle
dipendenze della struttura organizzativa o sia un fornitore di servizi esterno.
I progetti vengono generalmente autorizzati come conseguenza delle
considerazioni strategiche illustrate di seguito.
Richiesta di mercato (ad esempio, una compagnia petrolifera autorizza un
progetto per la costruzione di una nuova raffineria in risposta alla cronica
carenza di carburante).
Necessit aziendali (ad esempio, una societ di formazione autorizza il progetto
di creazione di un nuovo corso di formazione per incrementare il proprio
reddito).
Richiesta di un cliente (ad esempio, una societ elettrica autorizza un progetto
per la costruzione di una nuova centrale di distribuzione che possa servire un
nuovo insediamento industriale).
Progresso tecnologico (ad esempio, una societ di software autorizza un nuovo
progetto per sviluppare una nuova generazione di videogame che faccia seguito
allintroduzione sul mercato di nuove apparecchiature per videogame da parte di
diverse aziende del settore elettronico).
Adempimento legale (ad esempio, una fabbrica di vernici autorizza un progetto
per stabilire linee guida nel trattamento di un nuovo prodotto tossico).

1.3
Che cos il Project Management?

Il Project Management lapplicazione di conoscenze, skill, strumenti e tecniche alle
attivit di progetto al fine di soddisfarne i requisiti. Il Project Management viene
espletato mediante lapplicazione e lintegrazione dei processi di Project Management
per le attivit di inizio, pianificazione, esecuzione, monitoraggio, controllo e chiusura.
Il project manager la persona incaricata del raggiungimento degli obiettivi di
progetto.
La gestione di progetto include:
identificare i requisiti;
fissare obiettivi chiari e raggiungibili;
individuare il giusto equilibrio tra le esigenze di qualit, ambito, tempo e costi,
che sono in competenza tra di loro;
adattare specifiche di prodotto, piani e approccio alle diverse aree di interesse e
alle diverse aspettative dei vari stakeholder.
Nellambito della gestione dei requisiti di progetto in competizione tra loro, i
project manager parlano spesso di triplo vincolo, vale a dire ambito del progetto,
tempi e costi. Lo sforzo costante per individuare il giusto equilibrio tra questi tre
fattori ha un sensibile impatto sulla qualit del progetto (vedere capitoli da 5 a 7). I
progetti di alta qualit consegnano il prodotto, il servizio o il risultato richiesti
nellambito stabilito, entro il tempo fissato e restando entro i limiti del budget definito.
La relazione tra i tre fattori tale per cui alla variazione anche di uno solo dei tre,
almeno un altro fattore ne risulta influenzato. I project manager si occupano inoltre di
gestire i progetti facendo fronte alle incertezze. Un rischio di progetto costituito da
un evento o da una condizione incerti che, se si verificano, hanno un effetto positivo o
negativo su almeno uno degli obiettivi di progetto.
Il gruppo di Project Management ha la responsabilit professionale nei confronti
dei propri stakeholder, inclusi i clienti, la Performing Organization ed il pubblico. I
membri del PMI adottano un Codice deontologico e i membri che hanno conseguito
la certificazione di Project Management Professional (PMP) adottano un Codice di
etica professionale. I membri del gruppo di progetto che sono anche membri del PMI
e/o PMP sono tenuti ad osservare le versioni attuali di tali codici.
importante notare che molti dei processi nellambito del Project Management
sono iterativi a causa dellesistenza e della necessit dellelaborazione progressiva in
un progetto per lintera durata del suo ciclo di vita. In altri termini, mano a mano che
un gruppo di Project Management approfondisce la conoscenza di un progetto anche
in grado di gestirlo ad un maggiore livello di dettaglio.
Il termine Project Management viene talvolta utilizzato per descrivere un
approccio della struttura organizzativa alla gestione delle funzioni operative. Questo
approccio, pi propriamente definito gestione per progetti, affronta numerosi aspetti
delle funzioni operative sotto forma di progetti per garantire lapplicazione di
consolidate tecniche di Project Management. Sebbene comprendere la natura del
Project Management sia essenziale per una struttura organizzativa che adotti la
gestione per progetti, una trattazione approfondita di tale approccio esula dagli
obiettivi di questo documento.

1.4
La struttura della Guida al PMBOK

La Guida al PMBOK articolata in tre sezioni.
1.4.1
Sezione I: Il contesto del Project Management

La prima sezione, Il contesto del Project Management, fornisce una struttura di base
per la comprensione del Project Management.
Il capitolo 1, Introduzione, definisce i termini chiave e fornisce una visione
dinsieme dellintera Guida al PMBOK.
Il capitolo 2, Ciclo di vita del progetto e Struttura organizzativa, descrive
lambiente in cui si realizzano i progetti. Il gruppo di Project Management deve avere
una conoscenza approfondita di questo contesto pi ampio. La gestione delle attivit
quotidiane del progetto una condizione necessaria, ma non sufficiente, per garantire
la riuscita del progetto.
1.4.2
Sezione II: Lo standard per il Project Management di un progetto

La sezione II, Lo standard per il Project Management di un progetto, specifica tutti i
processi di Project Management adottati dal gruppo di progetto per la gestione del
progetto stesso.
Il capitolo 3, Processi di Project Management per un progetto, descrive i
cinque gruppi di processi di Project Management necessari per qualsiasi progetto e i
processi di Project Management che li compongono. Questo capitolo illustra la natura
multidimensionale del Project Management.
1.4.3
Sezione III: Le aree di conoscenza di Project Management

La sezione 3, Le aree di conoscenza di Project Management, articola i 44 processi di
Project Management del capitolo 3 Gruppi di processi di Project Management nelle
nove aree di conoscenza descritte di seguito. Lintroduzione alla sezione III illustra la
legenda dei diagrammi di flusso dei processi utilizzati in ciascun capitolo sulle aree di
conoscenza e fornisce il materiale introduttivo applicabile a tutte le aree di
conoscenza.
Il capitolo 4, Gestione dellintegrazione di progetto, descrive i processi e le
attivit che integrano elementi diversi del Project Management, i quali vengono
identificati, definiti, combinati, unificati e coordinati nellambito dei gruppi di
processi di Project Management. Comprende i seguenti processi di Project
Management: Sviluppare il Project Charter, Sviluppare la descrizione preliminare
dellambito del progetto, Sviluppare il piano di Project Management, Dirigere e
gestire lesecuzione del progetto, Monitorare e controllare il lavoro del progetto,
Controllo integrato delle modifiche e i processi di chiusura del progetto.
Il capitolo 5, Gestione dellambito del progetto, descrive i processi necessari
ad assicurare che un progetto includa tutto il lavoro richiesto, e soltanto quello, al fine
di completarlo con successo. Comprende i seguenti processi di Project Management:
Pianificazione dellambito, Definizione dellambito, Creare la WBS, Verifica
dellambito e Controllo dellambito.

Il capitolo 6, Gestione dei tempi di progetto, descrive i processi necessari ad

assicurare il completamento di un progetto nei tempi previsti. Comprende i seguenti
processi di Project Management: Definire le attivit, Sequenzializzazione delle
attivit, Stima delle risorse delle attivit, Stima della durata delle attivit, Sviluppo
della schedulazione e Controllo della schedulazione.
Il capitolo 7, Gestione dei costi di progetto, descrive i processi coinvolti nella
pianificazione, nella stima, nella allocazione e nel controllo dei costi affinch il
progetto venga completato nel rispetto del budget approvato. Comprende i seguenti
processi di Project Management: Stima dei costi, Allocazione dei costi e Controllo dei
costi.
Il capitolo 8, Gestione della qualit di progetto, descrive i processi necessari
ad assicurare che un progetto soddisfi gli obiettivi per cui stato intrapreso.
Comprende i seguenti processi di Project Management: Pianificazione della qualit,
Effettuare lassicurazione qualit ed Esecuzione del controllo di qualit.
Il capitolo 9, Gestione delle risorse umane di progetto, descrive i processi che
consentono di organizzare e gestire il gruppo di progetto. Comprende i seguenti
processi di Project Management: Pianificazione delle risorse umane, Acquisire il
gruppo di progetto, Sviluppare il gruppo di progetto e Gestire il gruppo di progetto.
Il capitolo 10, Gestione della comunicazione di progetto, descrive i processi
necessari alla puntuale e appropriata produzione, raccolta, diffusione, archiviazione e
disposizione definitiva delle informazioni relative a un progetto. Comprende i
seguenti processi di Project Management: Pianificazione della comunicazione,
Distribuzione delle informazioni, Reporting delle prestazioni e Gestire gli stakeholder.
Il capitolo 11, Gestione dei rischi di progetto, descrive i processi coinvolti
nella conduzione della gestione dei rischi di un progetto. Comprende i seguenti
processi di Project Management: Pianificazione della gestione dei rischi, Identificare i
rischi, Analisi qualitativa del rischio, Analisi quantitativa del rischio, Pianificazione
della risposta ai rischi e Monitoraggio e controllo dei rischi.
Il capitolo 12, Gestione dellapprovvigionamento di progetto, descrive i
processi che consentono di acquistare o acquisire prodotti, servizi o risultati come
pure i processi di gestione dei contratti. Comprende i seguenti processi di Project
Management: Pianificare gli acquisti, Pianificare le forniture, Richiesta di risposte dai
fornitori, Selezionare i fornitori, Amministrazione del contratto e Chiusura del
contratto.
10

Figura 1-1. Visione dinsieme delle aree di conoscenza di Project Management e dei
processi di Project Management

11
1.5
Aree di esperienza
Gran parte della conoscenza e molti degli strumenti e delle tecniche relativi alla
gestione dei progetti sono ad appannaggio esclusivo del Project Management, come
ad esempio le WBS o strutture di scomposizione del lavoro, lanalisi dei percorsi
critici e il metodo dellEarned Value. La comprensione e lapplicazione di
conoscenze, skill, strumenti e tecniche, riconosciuti generalmente come buone
pratiche, non sono tuttavia di per s sufficienti a garantire un efficace Project
Management. Per un efficace Project Management necessario che il gruppo di
Project Management comprenda e utilizzi la conoscenza e gli skill che fanno capo ad
almeno cinque aree di esperienza:
Project Management Body of Knowledge;
Conoscenza degli standard, dei regolamenti e delle aree applicative;
comprensione del contesto del progetto;
conoscenza e skill in materia di general management;
capacit nei rapporti interpersonali.
La figura 1-2 illustra la relazione tra le cinque aree di esperienza. Bench
appaiano come elementi distinti, in genere presentano aree comuni; nessuno di essi
pu sussistere autonomamente. I gruppi di progetti efficaci li integrano in tutti gli
aspetti dei propri progetti. Non necessario che tutti i membri del gruppo siano esperti
di tutti e cinque i settori. di fatto assai improbabile che un singolo individuo
possegga tutta la conoscenza e gli skill richiesti dal progetto. Ai fini dellefficace
gestione dei progetti tuttavia importante che il gruppo di Project Management
conosca approfonditamente la Guida al PMBOK e abbia dimestichezza con i dati
contenuti nel Project Management Body of Knowledge e con le altre quattro aree
della gestione.
1.5.1
Project Management Body of Knowledge

Il Project Management Body of Knowledge descrive conoscenze che appartengono
solo allambito del Project Management e nozioni condivise con altre discipline di
gestione. La figura 1-2 mostra i settori comuni alle aree di conoscenza di cui necessita
il gruppo di progetto. La Guida al PMBOK quindi un sottoinsieme del pi ampio
Project Management Body of Knowledge.
La conoscenza in materia di Project Management cos come viene descritta nella
Guida al PMBOK articolata come segue:
definizione del ciclo di vita del progetto (capitolo 2);
cinque gruppi di processi di Project Management (capitolo 3);
nove aree di conoscenza (capitoli 4-12).
12

Figura 1-2. Aree di esperienza di cui necessita il gruppo di Project Management.
1.5.2
Conoscenza degli standard, dei regolamenti e delle aree

applicative
Le aree applicative sono categorie di progetti che hanno in comune alcuni elementi
significativi in tali progetti ma che non sono necessari o presenti in tutti i progetti. Le
aree applicative vengono comunemente definite in termini di:
reparti funzionali e discipline collegate, come gestione legale, della produzione
e dellinventario, marketing, logistica e personale;
elementi tecnici, quali lo sviluppo o la progettazione software, e talvolta un tipo
specifico di progettazione, ad esempio la progettazione di sistemi idrici e fognari
o lingegneria edilizia;
specializzazioni di gestione, ad esempio appalti pubblici, sviluppo di collettivit
e sviluppo di nuovi prodotti;
categorie industriali, come industria automobilistica, industria chimica,
agricoltura o servizi finanziari.
Ciascuna area applicativa dispone in genere di una serie di standard e di pratiche
accettati, spesso codificati in regolamenti. LOrganizzazione Internazionale per la
Standardizzazione (ISO) attua una differenziazione tra standard e regolamenti come
illustrato di seguito (Guida ISO/IES 2: 1996)2:

13
Uno standard un documento stabilito tramite consenso diffuso e approvato da

un ente riconosciuto che, ai fini dellutilizzo comune e ripetuto, fornisce norme,
linee guida o caratteristiche in merito alle attivit e ai rispettivi risultati, il cui
scopo il raggiungimento del massimo grado di ordine in un contesto stabilito.
Alcuni esempi di standard sono le dimensioni dei dischi per computer e le
specifiche di prodotto per la stabilit termica dei fluidi idraulici.
Un regolamento un requisito decretato a livello governativo che stabilisce le
caratteristiche di un prodotto, un processo o un servizio, incluse le relative
procedure amministrative, a cui occorre obbligatoriamente conformarsi. Le
norme in materia di edilizia sono un esempio di regolamento.
Larea in cui i concetti di standard e di regolamento si sovrappongono o fonte di
confusione. Ad esempio:
gli standard sono spesso inizialmente delle linee guida che descrivono un
approccio preferenziale e che successivamente, grazie alla loro diffusione,
vengono adottati come se si trattasse di regolamenti.
Lobbligo della conformit pu provenire da livelli organizzativi diversi, come il
caso di quando un ente governativo, la direzione della Performing Organization
o il gruppo di Project Management stabiliscono regole e procedure specifiche.
Per una dissertazione pi dettagliata sulle aree applicative del Project
Management, consultare lAppendice D.
1.5.3
Comprensione del contesto del progetto

Pressoch tutti i progetti vengono pianificati e messi in atto in un determinato contesto
sociale, economico e ambientale, e hanno un impatto pianificato o non pianificato,
positivo o negativo. Compito del gruppo di progetto considerare il progetto in
ognuno dei suoi contesti: culturale, sociale, internazionale, politico e fisicoambientale.
Ambiente socioculturale. Il gruppo deve comprendere a fondo il modo in cui il
progetto ha influenza sulle persone e in cui le persone hanno influenza sul
progetto. Questo pu richiedere la comprensione degli aspetti economici,
demografici, educativi, etici, etnici, religiosi e cos via delle persone sui cui il
progetto incide o che hanno interessi nei confronti del progetto. Il project
manager deve inoltre esaminare la cultura organizzativa e determinare se il
Project Management sia riconosciuto come un ruolo valido, con responsabilit e
autorit per gestire progetti.
Ambiente internazionale e politico. Alcuni membri del gruppo di lavoro
devono disporre di una conoscenza approfondita delle normative e delle
consuetudini internazionali, nazionali, regionali e locali applicabili, e devono
inoltre avere dimestichezza con il clima politico che potrebbe avere un impatto
sul progetto. Tra gli altri fattori internazionali da considerare si contano le
differenze di fuso orario, le festivit nazionali e regionali, i requisiti di viaggio
per gli incontri in presenza e la logistica delle teleconferenze.
Ambiente fisico. Se si prevede che il progetto incida sul relativo ambiente
fisico, alcuni membri del gruppo di lavoro devono avere dimestichezza con
lecologia e con la geografia fisica del luogo che potrebbero incidere sul
progetto o a sua volta subirne linflusso.
14

1.5.4
Conoscenza e skill in materia di general management

Il general management comprende la pianificazione, la struttura organizzativa, la
gestione delle risorse, lesecuzione e il controllo delle funzioni operative di
unimpresa. Comprende inoltre le discipline supplementari elencate di seguito.
Gestione finanziaria e contabilit.
Acquisti e approvvigionamento.
Vendite e marketing.
Contratti e legislazione commerciale.
Produzione e distribuzione.
Logistica e catena distributiva.
Pianificazione strategica, tattica e operativa.
Strutture organizzative, comportamenti delle organizzazioni, amministrazione
del personale, corrispettivi, indennit e piani di carriera.
Procedure sanitarie e di sicurezza.
Tecnologie informatica.
Il general management fornisce le basi per la creazione degli skill di Project
Management ed spesso essenziale per il project manager. In un determinato progetto
possono essere richiesti skill relativi a qualsiasi area del general management. Il
materiale relativo al general management documenta tali skill, la cui applicazione
essenzialmente la stessa nellambito di un progetto.
1.5.5
Capacit interpersonali.
La gestione delle capacit interpersonali si articola negli aspetti elencati di seguito.
Comunicazione efficace: lo scambio di informazioni.
Capacit dinfluenzare la struttura organizzativa: la capacit di portare a
termine ci che si comincia.
Leadership: sviluppo di una vision e delle strategie e motivazione delle persone
affinch realizzino tali vision e strategie.
Motivazione: incentivo alle persone affinch conseguano alti livelli
prestazionali e superino gli ostacoli che impediscono il cambiamento.
Negoziazione e gestione dei conflitti: dialogo con laltra parte per individuare
un terreno comune o raggiungere un accordo.
Risoluzione dei problemi: lunione della definizione dei problemi,
dellidentificazione e dellanalisi delle alternative e lassunzione di decisioni.

15
1.6
Il contesto del Project Management

Il Project Management esiste in un contesto pi ampio che comprende Program
Management, gestione del portfolio e Project Management Office. Esiste spesso una
gerarchia composta da piano strategico, portfolio, programma, progetto e
sottoprogetto; al suo interno un programma, composto di diversi progetti associati,
contribuisce alla realizzazione di un piano strategico.
1.6.1
Programmi e Program Management

Un programma formato da un gruppo di progetti correlati gestiti in modo coordinato
al fine di ottenere benefici e controllo che sarebbero irraggiungibili nel caso di una
loro gestione separata3. I programmi possono comprendere elementi correlati di
lavoro esterni allambito dei progetti distinti che costituiscono il programma. Ad
esempio:
il programma di un nuovo modello di automobile pu essere suddiviso in
progetti per lelaborazione tecnica e gli aggiornamenti di ciascun componente
principale (ad esempio: trasmissione, motore, interni, esterno) mentre la
produzione continuativa avviene sulla catena di montaggio.
Molte aziende nel campo dellelettronica dispongono di program manager che
sono responsabili sia della commercializzazione di singoli prodotti (progetti) sia
del coordinamento di pi fasi di commercializzazione su un periodo di tempo
pi lungo (operazione ricorrente).
I programmi prevedono anche una serie di compiti ripetitivi o ciclici. Ad esempio:
le aziende di servizio pubblico parlano spesso di un programma di costruzione
annuale, vale a dire una serie di progetti fondati su impegni precedenti.
Diverse strutture organizzative senza fine di lucro hanno un programma di
raccolta fondi che consiste in unattivit ricorrente mirata a ottenere un
supporto finanziario che spesso include una serie di progetti distinti, come
unasta o una campagna di sottoscrizione.
Anche la pubblicazione di un quotidiano o di una rivista costituisce un
programma in cui ciascun numero viene gestito come un progetto a s stante.
di fatto un esempio di come le funzioni operative generali si possano
trasformare in gestione per progetti (vedere sezione 1.3).
A differenza del Project Management, il Program Management la gestione
centralizzata e coordinata di un gruppo di progetti allo scopo di raggiungere gli
obiettivi e i benefici strategici del programma.
1.6.2
Portfolio e gestione del portfolio

Un portfolio una raccolta di progetti, di programmi e di altro lavoro raggruppati
insieme per agevolare la gestione efficace del lavoro ai fini del raggiungimento degli
obiettivi aziendali strategici. I progetti o programmi che costituiscono il portfolio
possono non essere interdipendenti o direttamente correlati. Lassegnazione di
finanziamenti e supporto pu avvenire in base a categorie di rischio/ricompensa, a
specifici settori di attivit o a tipi di progetti generici, quali il miglioramento delle
infrastrutture e dei processi interni.
16

Le strutture organizzative gestiscono i propri portfolio sulla base di obiettivi

specifici. Uno degli obiettivi della gestione del portfolio consiste nel massimizzarne il
valore mediante unattenta disamina dei progetti e dei programmi candidati ad esservi
inclusi e tramite la pronta esclusione di quei progetti che non soddisfano gli obiettivi
strategici del portfolio stesso. Altri obiettivi comprendono lindividuazione del giusto
equilibrio del portfolio nel contesto di investimenti incrementali e radicali e ai fini di
un uso efficiente delle risorse. In genere il compito di gestire il portfolio di una
struttura organizzativa appannaggio dei dirigenti e dei gruppi di dirigenti superiori.
1.6.3
Sottoprogetti
I progetti vengono solitamente suddivisi in componenti pi facilmente gestibili
denominati sottoprogetti; ciascun sottoprogetto pu tuttavia essere indicato come
progetto e venire gestito come tale. Tali sottoprogetti vengono spesso affidati in
subappalto a terzi o ad altre unit funzionali della Performing Organization. Tra i
possibili esempi:
sottoprogetti basati sui processi di progetto, tra cui una singola fase nel ciclo di
vita del progetto;
sottoprogetti basati sui requisiti di risorse umane in termini di skill, tra cui
idraulici ed elettricisti richiesti per un progetto edile;
sottoprogetti che riguardano tecnologie specializzate, come il testing
automatizzato di programmi informatici nellambito di un progetto di sviluppo
software.
In progetti di dimensioni particolarmente grandi, i sottoprogetti possono essere
costituiti da una serie di sottoprogetti di dimensioni ancora inferiori.
1.6.4
Project Management Office

Un Project Management Office (PMO) ununit organizzativa che consente di
centralizzare e coordinare la gestione dei progetti sotto il suo raggio dazione. Un
PMO pu anche essere definito Program Management Office, ufficio di progetto
o ufficio di programma. Un PMO sovrintende alla gestione di progetti, programmi o
a una combinazione di entrambi. I progetti supportati o amministrati dal PMO
possono non avere altro tipo di correlazione che quella riguardante il fatto che sono
gestiti insieme. Alcuni PMO si occupano tuttavia di coordinare e gestire progetti
correlati. In numerose strutture organizzative, tali progetti vengono infatti raggruppati
o correlati in base al modo in cui il PMO intende coordinarli e gestirli. Il PMO
focalizza la sua attenzione sulla pianificazione coordinata, sullassegnazione delle
priorit e sullesecuzione di progetti e sottoprogetti collegati agli obiettivi aziendali
complessivi della struttura organizzativa principale o del cliente.
I PMO possono operare come un continuum e la loro attivit spazia dalla
fornitura di funzioni di supporto al Project Management sotto forma di formazione,
software, regole standardizzate e procedure fino alla gestione diretta e alla
responsabilit insita nel raggiungimento degli obiettivi di progetto. Un PMO specifico
pu essere delegato e debitamente autorizzato ad agire in qualit di stakeholder
integrato nel processo e responsabile chiave dellassunzione di decisioni durante la
fase di avvio di ciascun progetto; pu inoltre disporre dellautorit per consigliare
investimenti o pu porre fine ai progetti per garantire luniformit degli obiettivi
aziendali. Il PMO pu inoltre venire coinvolto nella selezione, nella gestione e nella
riassegnazione, se necessario, di personale di progetto condiviso e, ove possibile, di
personale di progetto dedicato.

17
Di seguito vengono elencate, a titolo esemplificativo, alcune delle caratteristiche

essenziali di un PMO.
Condivisione e coordinamento di Risorse su tutti i progetti amministrati dal
PMO.
Identificazione e sviluppo della metodologia, delle migliori pratiche e degli
standard di Project Management.
Chiarificazione e gestione di regole, procedure e modulistica di progetto e di
altra documentazione condivisa.
Gestione centralizzata della configurazione per tutti i progetti amministrati dal
PMO.
Punto di raccolta e gestione centralizzati per i rischi sia condivisi che specifici
per tutti i progetti.
Ufficio centrale per funzioni operative e gestione degli strumenti di progetto,
quali il software di Project Management aziendale.
Coordinamento centrale della gestione della comunicazione su pi progetti.
Una piattaforma di indicazioni rivolte ai project manager.
Monitoraggio centrale di tutte le tempistiche e dei budget dei progetti PMO,
generalmente a livello aziendale.
Coordinamento degli standard complessivi di qualit dei progetti tra il project
manager ed eventuale personale interno o esterno responsabile della qualit od
organizzazioni che si occupano degli standard.
Le differenze tra Project Management e il PMO possono prevedere gli aspetti
descritti di seguito.
I project manager e i PMO perseguono obiettivi diversi e sono pertanto guidati
da esigenze diverse. Tutti i loro sforzi sono tuttavia allineati alle esigenze
strategiche della struttura organizzativa.
Un project manager responsabile della produzione di specifici obiettivi di
progetto nellambito dei vincoli del progetto stesso; un PMO invece una
struttura organizzativa con specifici incarichi caratterizzati da una visione
globale a livello aziendale.
Il project manager focalizzato su una serie di obiettivi specifici di progetto; un
PMO gestisce modifiche di grande portata dellambito del programma e pu
vedere queste come opportunit potenziali per meglio raggiungere gli obiettivi
aziendali.
Il project manager controlla le risorse assegnate al progetto per meglio
soddisfare gli obiettivi del progetto stesso, il PMO ottimizza invece luso delle
risorse condivise della struttura organizzativa su tutti i progetti.
Il project manager gestisce lambito, la schedulazione, il costo e la qualit dei
prodotti dei Work Package; il PMO gestisce il rischio complessivo,
lopportunit complessiva e gli altri rapporti di interdipendenza tra progetti.
Il project manager riporta sui progressi del progetto e su altre informazioni
specifiche dello stesso; il PMO fornisce invece relazioni complessive e una
visione aziendale dei progetti nella sua sfera di competenza.
18

CAPITOLO 2
Ciclo di vita del progetto e Struttura
organizzativa
I progetti e il Project Management vengono svolti in un ambiente pi ampio di quello
del progetto stesso. Il gruppo di Project Management deve avere una conoscenza di
questo contesto pi ampio per essere in grado di selezionare le fasi del ciclo di vita, i
processi, gli strumenti e le tecniche che si adattano maggiormente al progetto. Questo
capitolo illustra alcuni degli aspetti essenziali del contesto del Project Management.
Gli argomenti trattati sono:
2.1 Il ciclo di vita del progetto
2.2 Gli stakeholder di progetto
2.3 Influenza della struttura organizzativa
2.1
Il ciclo di vita del progetto

I project manager o la struttura organizzativa possono suddividere i progetti in fasi per
garantire un pi accurato controllo manageriale, con gli appropriati collegamenti alle
funzioni operative in corso allinterno della Performing Organization. Nel loro
insieme queste fasi sono conosciute con il nome di ciclo di vita del progetto. Molte
strutture organizzative identificano un insieme specifico di cicli di vita da utilizzare
per tutti i propri progetti.
2.1.1
Caratteristiche del ciclo di vita del progetto

Il ciclo di vita del progetto definisce le fasi che collegano linizio e la fine del progetto
stesso. Ad esempio, nel caso in cui una struttura organizzativa abbia identificato
unopportunit alla quale desidera rispondere, essa autorizzer di solito uno studio di
fattibilit per decidere se intraprendere o meno il progetto. Definire il ciclo di vita del
progetto pu aiutare il project manager a chiarire se sia opportuno considerare lo
studio di fattibilit la prima fase del progetto o un progetto distinto e autonomo. Nel
caso in cui lesito di questo sforzo preliminare non sia chiaramente identificabile,
consigliabile considerare tale sforzo come un progetto distinto. Le fasi del ciclo di vita
del progetto non sono la stessa cosa dei gruppi di processi di Project Management
descritti dettagliatamente al capitolo 3.

19
Capitolo 2 Ciclo di vita del progetto e Organizzazione
La transizione da una fase allaltra nellambito del ciclo di vita dello stesso
progetto comporta in genere una forma di trasferimento tecnico o passaggio di
consegne, da cui viene solitamente definita. I deliverable ottenuti da una fase vengono
in genere analizzati per verificarne la completezza e laccuratezza, per essere poi
approvati prima che si proceda con la fase successiva del lavoro. Tuttavia, non del
tutto inusuale che una fase, qualora si ritenga che i possibili rischi siano accettabili,
venga iniziata prima dellapprovazione dei deliverable della fase precedente. Questa
pratica della sovrapposizione di fasi, solitamente svolte in sequenza, un esempio di
applicazione della tecnica di compressione della schedulazione, altrimenti detta fast
tracking.
Non esiste un modo in assoluto migliore per definire il ciclo di vita del progetto.
Alcune strutture organizzative hanno adottato delle regole che consentono di
standardizzare tutti i progetti attraverso un solo ciclo di vita, mentre altre strutture
organizzative preferiscono affidare al gruppo di Project Management la scelta del
ciclo di vita migliore per il progetto assegnato al gruppo. Inoltre, le pratiche
comunemente adottate nel settore specifico conducono generalmente allutilizzo di un
ciclo di vita preferenziale per il settore in questione.
I cicli di vita del progetto definiscono in genere:
quale lavoro tecnico deve essere svolto in ciascuna fase (ad es. in quale fase
deve essere effettuato il lavoro dellarchitetto);
quando devono essere prodotti i deliverable in ciascuna fase e come ciascun
deliverable deve essere analizzato, verificato e convalidato;
chi coinvolto in ciascuna fase (ad es. la progettazione in contemporanea
richiede il coinvolgimento dei responsabili dellimplementazione nella
definizione dei requisiti e nella progettazione);
come controllare e approvare ciascuna fase.
Le descrizioni del ciclo di vita del progetto pu essere sia molto generale che
molto dettagliata. Le descrizioni pi dettagliate dei cicli di vita possono includere
modelli, diagrammi e liste di controllo al fine di dare una forma strutturata e
assicurare il controllo.
La maggior parte dei cicli di vita del progetto presentano caratteristiche comuni:
Le fasi sono in genere sequenziali e vengono comunemente definite da una
forma di trasferimento di informazioni tecniche o da un passaggio di consegne
dei componenti tecnici.
I costi e i livelli del personale coinvolti sono inizialmente bassi, raggiungono il
picco nel corso delle fasi intermedie e diminuiscono rapidamente quando il
progetto si avvia alla conclusione. La figura 2-1 illustra questo andamento.
20

Figura 2-1. Costo e livello del personale tipici di un progetto nel corso del ciclo di vita del
progetto
Il livello di incertezza, e quindi anche il rischio di non riuscire a raggiungere gli

obiettivi, sono maggiori allinizio del progetto. In genere la certezza di
raggiungere il completamento si intensifica progressivamente con
lavanzamento del progetto
Labilit degli stakeholder di influenzare le caratteristiche e il costo finali del
prodotto del progetto massima allinizio e diminuisce progressivamente via via
che il progetto avanza. La figura 2-2 illustra questo fenomeno. Un maggior
contributo a ci lo da il fatto che di solito il costo delle modifiche e della
correzione degli errori aumenta con lavanzamento del progetto.
Figura 2-2. Influenza dei stakeholder nel corso del tempo

21
Sebbene molti cicli di vita dei progetti siano caratterizzati da nomi di fasi simili
con deliverable analoghi, pochi sono completamente identici. Alcuni sono composti
da quattro o cinque fasi, mentre altri ne possono contenere nove o pi. Le singole aree
applicative sono invece caratterizzate da variazioni anche significative. Il ciclo di vita
dello sviluppo di un software di una struttura organizzativa pu essere composto da
una sola fase di progettazione, mentre un altro pu essere composto da fasi separate
per larchitettura e per il disegno di dettaglio. Inoltre i sottoprogetti posso avere cicli
di vita di progetto differenti Ad esempio, uno studio di architetti, scelto per il progetto
di un nuovo complesso di uffici, dapprima impegnato nella fase di definizione del
progetto del committente mentre sta facendo la progettazione; poi impegnato nella
fase di implementazione, mentre sta facendo da supporto alla fase di messa in opera. Il
piano di progettazione dello studio di architetti, tuttavia, sar fatto da un suo insieme
di fasi, dallo sviluppo concettuale alla definizione fino alla messa in opera e alla
chiusura. Gli architetti potrebbero addirittura considerare la progettazione delledificio
e la consulenza per la sua costruzione come progetti separati, ciascuno con un proprio
set di fasi.
2.1.2
Caratteristiche delle fasi di progetto

Il completamento e lapprovazione di uno o pi deliverable caratterizzano una fase di
progetto. Un deliverable un prodotto del lavoro misurabile e verificabile, come le
specifiche di prodotto, il rapporto finale di uno studio di fattibilit, un documento di
progettazione dettagliato o un prototipo funzionante. Alcuni deliverable possono
corrispondere al processo di Project Management, mentre altri costituiscono i prodotti
finali o i componenti dei prodotti finali per i quali era nato il progetto. I deliverable, e
di conseguenza anche le fasi, sono un elemento costitutivo di un processo, in genere
sequenziale, ideato per garantire un adeguato controllo del progetto e per raggiungere
il prodotto o il servizio desiderati, ovvero lobiettivo del progetto.
In qualsiasi specifico progetto, per ragioni di dimensioni, complessit, livello di
rischio e vincoli di flusso di cassa, le fasi possono essere ulteriormente suddivise in
sottofasi. Ogni sottofase, per lesecuzione del monitoraggio e del controllo, associata
a uno o pi deliverable specifici. La maggior parte di questi sono collegati ai
deliverable della fase principale, e le fasi normalmente da questi prendono il nome:
requisiti, progettazione, costruzione, collaudo, avviamento, volume di affari e molti
atri ancora, in base alle esigenze.
Una fase di progetto termina in genere con una revisione del lavoro svolto e dei
deliverable ottenuti per determinarne il livello di accettazione e verificare se
necessario ulteriore lavoro oppure se la fase pu considerarsi conclusa. Spesso viene
condotta unanalisi da parte della direzione per decidere se avviare le attivit della
fase successiva senza chiudere quella ancora in corso, ad esempio quando il project
manager sceglie come linea di condotta il fast tracking. Un altro esempio di questo
fenomeno dato da unazienda del settore informatico che sceglie di adottare un ciclo
di vita iterativo per il quale pi fasi del progetto vengono svolte contemporaneamente.
possibile raccogliere, analizzare, progettare e realizzare i requisiti di un modulo e,
mentre si esegue lanalisi del modulo, possibile avviare in parallelo la raccolta dei
requisiti di un altro modulo.
Analogamente, possibile chiudere una fase senza decidere di iniziarne una
nuova. Una situazione simile si verifica quando il progetto completato o quando si
ritiene che proseguire il progetto sia troppo rischioso.
22

Il completamento formale della fase non include anche lautorizzazione

allavvio della fase successiva. Per un controllo efficace, ogni fase viene formalmente
iniziata al fine di produrre un output, dipendente dalla fase stessa, che specifichi cosa
permesso e previsto nellambito della fase in questione, come illustrato nella
figura 2-3. quindi possibile eseguire unanalisi di fine fase con lesplicito intento di
ottenere lautorizzazione a chiudere la fase in corso e ad avviare quella successiva. A
volte vengono concesse entrambe le autorizzazioni con una sola analisi. Le revisioni
di fine fase sono spesso denominate uscite dalla fase, punti di uscita o punti di rottura.
Figura 2-3. Tipica sequenza delle fasi in un ciclo di vita del progetto
2.1.3
Relazioni tra ciclo di vita del progetto e ciclo di vita di prodotto

Molti progetti sono collegati al lavoro normalmente svolto allinterno della
Performing Organization. Alcune strutture organizzative approvano formalmente i
progetti solo dopo il completamento di uno studio di fattibilit, di un piano
preliminare o di altra forma di analisi equivalente. In questi casi, la pianificazione e
lanalisi preliminare costituiscono progetti separati. Ad esempio, possibile che si
ricorra a fasi aggiuntive per lo sviluppo e il collaudo di un prototipo prima di iniziare
un progetto che riguarda lo sviluppo del prodotto finale. Alcuni tipi di progetti,
soprattutto i progetti per lo sviluppo di servizi interni o di nuovi prodotti, possono
essere avviati anche informalmente, per un lasso di tempo limitato, in modo da
garantire lapprovazione formale delle fasi o delle attivit aggiuntive.
I fattori abilitanti che generano gli stimoli per lo sviluppo di un progetto
vengono generalmente denominate problemi, opportunit o requisiti aziendali.
Leffetto di queste pressioni quello di spingere la direzione ad assegnare una priorit
a questa richiesta, nel rispetto delle esigenze e delle richieste di risorse di altri
potenziali progetti.

23
La definizione di ciclo di vita del progetto consente inoltre di identificare le

azioni transitorie da svolgersi o meno al termine del progetto, allo scopo di collegare il
progetto alle funzioni operative in corso della Performing Organization. Un esempio
di tale situazione si verifica quando si autorizza la produzione di un nuovo prodotto o
quando viene commercializzato un nuovo programma software. necessario fare
attenzione nel distinguere il ciclo di vita del progetto da quello di prodotto. Ad
esempio, un progetto avviato per commercializzare un nuovo computer desktop
soltanto uno degli aspetti del ciclo di vita di prodotto. La figura 2-4 illustra il ciclo di
vita di prodotto a partire dal piano aziendale, proseguendo con lideazione, con il
prodotto stesso, con il normale funzionamento e con la dismissione del prodotto. Il
ciclo di vita del progetto attraversa una serie di fasi che portano alla creazione del
prodotto. I progetti aggiuntivi possono prevedere un aggiornamento delle prestazioni
del prodotto. In alcune aree applicative, come lo sviluppo di un nuovo prodotto o di un
nuovo software, le strutture organizzative considerano il ciclo di vita del progetto
come un elemento costitutivo del ciclo di vita di prodotto.
Figura 2-4. Relazione tra il ciclo di vita del prodotto e del progetto
2.2
Stakeholder di progetto
Gli stakeholder di progetto sono persone o strutture organizzative attivamente
coinvolte nel progetto o i cui interessi possono subire conseguenze dellesecuzione o
dal completamento del progetto. Gli stakeholder possono anche influire sugli obiettivi
e sui risultati del progetto. Il gruppo di Project Management deve identificare gli
stakeholder, determinarne i requisiti e le aspettative e, per quanto possibile, gestire
linfluenza che possono esercitare in merito ai requisiti per garantire la buona riuscita
del progetto. La figure 2-5 illustra la relazione tra stakeholder e gruppo di progetto.
24

Figura 2-5. Relazione tra gli stakeholder e il progetto
Gli stakeholder, quando partecipano a un progetto, hanno vari livelli di

responsabilit e autorit che possono tuttavia cambiare nel corso del ciclo di vita del
progetto. La loro responsabilit e autorit spazia da contributi occasionali ad indagini
o focus group alla completa sponsorizzazione del progetto, che include un supporto
finanziario e politico. Gli stakeholder che ignorano tale responsabilit possono anche
causare danni agli obiettivi del progetto. Analogamente, i project manager che
ignorano gli stakeholder si possono aspettare conseguenze negative sui risultati del
progetto.
A volte lidentificazione degli stakeholder pu risultare difficoltosa. Si potrebbe
sostenere, ad esempio, che anche un operaio alla catena di montaggio, il cui posto di
lavoro dipenda dalla riuscita di un progetto per un nuovo prodotto, sia uno
stakeholder. Linsuccesso nellidentificare uno stakeholder chiave pu causare
problemi seri al progetto. Ad esempio, in un progetto di aggiornamento del software
per lanno 2000 (Y2K), il ritardato riconoscimento del fatto che lufficio legale fosse
uno stakeholder importante ha causato laggiunta ai requisiti del progetto di molti task
di documentazione.
Gli stakeholder possono avere sia un impatto negativo che positivo sul progetto.
Gli stakeholder positivi sono quelli che traggono in genere vantaggi dalla buona
riuscita del progetto, mentre gli stakeholder negativi sono quelli che vedono risultati
negativi dalla buona riuscita del progetto. Ad esempio, i dirigenti aziendali
appartenenti a una comunit, che trarrebbe vantaggio da un progetto di espansione
industriale, sono stakeholder positivi perch vedono nel successo del progetto un
ritorno economico per la propria comunit. Al contrario i gruppi di ambientalisti
possono essere considerati degli stakeholder negativi, se ritengono che il progetto sia
nocivo per lambiente. In presenza di stakeholder positivi, possibile supportarne gli
interessi contribuendo al successo del progetto, ad esempio facendo in modo che il
progetto ottenga tutte le autorizzazioni necessarie per proseguire. Linteresse degli
stakeholder negativi verrebbe invece supportato con un aumento dei vincoli
sullavanzamento del progetto, come la richiesta di ulteriori indagini ambientali.
Spesso il gruppo di progetto non tiene conto a sufficienza degli stakeholder negativi,
tanto da mettere a repentaglio la buona riuscita del proprio progetto.

25
Gli stakeholder principali di un progetto includono:

Project manager: persona responsabile della gestione del progetto.
Cliente/utente: persona o struttura organizzativa che utilizzer il prodotto del
progetto. Possono esistere diversi livelli di clienti. Ad esempio, i clienti di un
nuovo prodotto farmaceutico comprendono i medici che lo prescrivono, i
pazienti che lo assumono e le assicurazioni mediche che ne pagano lacquisto. In
alcune aree applicative, i termini cliente e utente sono sinonimi, mentre in altre
per cliente si intende lentit che effettua lacquisto del prodotto del progetto e
per utente colui che utilizza direttamente tale prodotto.
Performing Organization: azienda i cui dipendenti sono coinvolti pi
direttamente nello svolgimento del lavoro del progetto.
Membri del gruppo di progetto: gruppo incaricato dellesecuzione del lavoro
previsto dal progetto.
Gruppo di Project Management: membri del gruppo di progetto che sono
direttamente coinvolti nelle attivit di Project Management.
Sponsor: persona o gruppo che fornisce le risorse finanziarie, in denaro o in
natura, necessarie al progetto.
Soggetti influenti: persone o gruppi che sono non direttamente collegati con
lacquisto o luso del prodotto del progetto ma che, a causa della posizione
ricoperta nella struttura organizzativa del cliente o nella Performing
Organization, possono influire positivamente o negativamente sul corso del
progetto.
PMO: se presente nella Performing Organization, il PMO pu essere
considerato uno stakeholder se ha una responsabilit diretta o indiretta sullesito
del progetto.
Oltre a questi stakeholder principali, ci sono vari nomi e categorie di stakeholder
di progetto, sia interni che esterni, come proprietari e investitori, fornitori e
appaltatori, membri del gruppo di lavoro e relative famiglie, agenzie governative e
rappresentanti dei media, singoli cittadini, lobby temporanee o permanenti, strutture
organizzative e societ nel loro insieme. Lindividuazione e il raggruppamento degli
stakeholder serve principalmente a identificare le persone e le strutture organizzative
che si considerano tali. I ruoli e le responsabilit degli stakeholder possono
condividere aree comuni, come nel caso in cui unimpresa edile fornisca i fondi per il
finanziamento di uno stabilimento di cui cura la progettazione.
I project manager hanno il compito di gestire le aspettative degli stakeholder,
compito spesso reso difficoltoso a causa dei differenti, e a volte contrastanti, obiettivi
degli stakeholder stessi. Per esempio.
Il responsabile di un reparto che abbia richiesto un nuovo sistema informatico
pu essere interessato a contenerne il costo, mentre larchitetto di sistema
potrebbe desiderare piuttosto un sistema tecnicamente avanzato e la ditta che ha
in appalto la programmazione potrebbe a propria volta avere come obiettivo
prioritario la massimizzazione del profitto.
Per il vicepresidente del reparto di ricerca in unazienda elettronica il successo
di un nuovo prodotto si misura in base al grado di novit della tecnologia
raggiunta, per il vicepresidente del reparto produzione in base al grado di
efficienza del processo produttivo, mentre per il vicepresidente del marketing il
successo dipende dal numero di nuove funzionalit disponibili.
26

2.3
Il titolare di un progetto di sviluppo immobiliare avr come interesse principale

il rispetto dei tempi di consegna, mentre lente pubblico locale competente avr
come obiettivo primario la massimizzazione degli introiti fiscali, un gruppo
ambientalista la riduzione al minimo dellimpatto ambientale e i residenti della
zona, a loro volta, il trasferimento del progetto in un altro luogo.
Influenza delle strutture organizzative

I progetti sono tipicamente parte di una struttura organizzativa che pi grande del
progetto stesso. Le strutture organizzative possono essere, ad esempio, enti giuridici,
agenzie governative, istituti di assistenza sanitaria, organizzazioni internazionali,
associazioni professionali e molto altro ancora. Anche in caso di progetti esterni (joint
venture, societ), essi saranno comunque sottoposti allinfluenza esercitata dalla
struttura organizzativa o dalle organizzazioni che li hanno attivati. La maturit della
struttura organizzativa, per quanto riguarda il suo sistema di Project Management, la
sua cultura, il suo stile, la sua struttura organizzativa e la presenza di un Project
Management Office possono anchessi influire sul progetto. Le sezioni seguenti
descrivono aspetti chiave di queste strutture organizzative, pi grandi del progetto
stesso, che hanno generalmente un impatto su di esso.
2.3.1
Sistemi di strutture organizzative

Le strutture organizzative basate su progetti sono quelle le cui funzioni operative
consistono principalmente in progetti. Esse possono essere raggruppate in due
categorie.
Strutture organizzative che traggono i propri profitti principalmente da progetti
realizzati per conto di terzi a contratto (studi di architetti, studi di ingegneri,
consulenti, imprese appaltatrici del settore edile, imprese specializzate in appalti
pubblici).
Strutture organizzative che hanno adottato la gestione per progetti (vedere
paragrafo 1.3).Queste strutture organizzative tendono ad adottare sistemi di
gestione che facilitano la gestione dei progetti. Ad esempio, la loro gestione
finanziaria spesso concepita specificamente per consentire la gestione di
scritture contabili, rilevazioni e rendicontazione su diversi progetti simultanei.
Le strutture organizzative non basate su progetti mancano spesso di sistemi di
gestione mirati a supportare le esigenze dei progetti in modo efficace ed efficiente.
Tale assenza rende di solito pi difficile la gestione di progetti stessi. In alcuni casi,
queste strutture organizzative dispongono tuttavia di reparti o altre unit di livello
inferiore che agiscono come strutture organizzative basate su progetti e sono dotate di
appositi sistemi di supporto. Il gruppo di Project Management deve essere
consapevole di come la struttura e i sistemi della struttura organizzativa possono
influire sul progetto.
2.3.2
Cultura e stile delle strutture organizzative

Molte strutture organizzative sviluppano una propria cultura, unica e descrivibile. Tali
culture si riflettono in numerosi fattori, che includono in modo non esaustivo i
seguenti.
Valori, norme, convinzioni e aspettative condivisi.
Regole e procedure adottate.
Concezione delle relazioni con lautorit.
Etica del lavoro e orario di lavoro.

27
La cultura delle strutture organizzative ha spesso uninfluenza diretta sui

progetti. Di seguito vengono riportati alcuni esempi.
Un gruppo che propone un approccio inusuale o ad alto rischio potr ricevere
molto pi facilmente lapprovazione da parte di una struttura organizzativa con
un approccio aggressivo o intraprendente.
Un project manager con uno stile che favorisce particolarmente la
partecipazione incontrer verosimilmente problemi in una struttura
organizzativa rigidamente gerarchica, mentre un project manager con uno stile
autoritario avr problemi in una struttura organizzativa che incoraggia la
partecipazione.
2.3.3
Struttura organizzativa
La struttura della Performing Organization vincola spesso la disponibilit di risorse in
uno spettro dal tipo funzionale al tipo progettuale, con una vasta gamma di strutture a
matrice tra i due estremi. La figura 2-6 mostra le caratteristiche fondamentali relative
ai progetti dei principali tipi di strutture organizzative.
Figura 2-6. Influenza delle strutture organizzative sui progetti
La struttura organizzativa funzionale classica, illustrata nella figura 2-7, consiste

in una gerarchia nella quale ogni dipendente ha un chiaro superiore. I membri del
personale sono raggruppati per area di esperienza, come produzione, marketing,
ufficio tecnico e amministrazione al pi alto livello. Lufficio tecnico pu essere
ulteriormente suddiviso in organizzazioni funzionali, come i settori meccanico ed
elettrico, che coadiuvano lattivit commerciale della struttura organizzativa pi
grande,. Le organizzazioni funzionali spesso hanno progetti, ma lambito di questi
progetti in genere limitato alla portata della funzione. Lufficio tecnico, appartenente
a una struttura organizzativa funzionale, esegue il proprio lavoro di progetto in modo
del tutto indipendente dalla produzione o dallufficio marketing. Quando una struttura
organizzativa puramente funzionale intraprende lo sviluppo di un nuovo prodotto, la
fase di disegno, definita generalmente progetto di disegno, include solo personale
dellufficio tecnico. Nel caso sorgano dubbi in materia di produzione, questi vengono
fatti pervenire per via gerarchica al capo reparto, che consulter il capo del reparto
produzione. La risposta viene quindi inoltrata, ridiscendendo la gerarchia, al manager
funzionale dellufficio tecnico.
28

Figura 2-7. Struttura organizzativa funzionale
Figura 2-8. Organizzazione per progetti
Allestremo opposto dello spettro si trova lorganizzazione per progetti, illustrata

nella figura 2-8. In tale organizzazione, i membri del gruppo di progetto sono spesso
allocati nello stesso ufficio. La maggior parte delle risorse impegnata in attivit di
progetto e i project manager godono di grande autonomia e di considerevole autorit.
Le organizzazioni progettuali hanno spesso unit organizzative chiamate reparti, che
dipendono tuttavia direttamente dal project manager o si occupano di fornire servizi di
supporto ai vari progetti.

29
Figura 2-9. Organizzazione a matrice debole
Figura 2-10. Organizzazione a matrice equilibrata
Le organizzazioni a matrice, come illustrato nelle figure dalla 2-9 alla 2-11, sono
un mix tra organizzazioni funzionali e organizzazioni progettuali. Le matrici deboli
conservano molte delle caratteristiche delle organizzazioni funzionali e in esse il ruolo
del project manager si avvicina pi a quello di un coordinatore o di un facilitator
che a quello di un manager. Allo stesso modo, le matrici forti presentano molte delle
caratteristiche delle organizzazioni progettuali e possono avere project manager a
tempo pieno dotati di un considerevole livello di autorit e personale amministrativo
dedicato a tempo pieno al progetto. Lorganizzazione a matrice equilibrata mentre
riconosce la necessit di ricorrere a un project manager, non gli fornisce lautorit
assoluta sul progetto e sul relativo finanziamento (figura 2-6).
30

Figura 2-11. Organizzazione a matrice forte
Figura 2-12. Organizzazione composita
Molte moderne strutture organizzative contengono esempi di tutte queste

strutture, a diversi livelli, come mostrato nella figura 2-12 (Organizzazione
composita). Ad esempio, anche unorganizzazione dalla struttura sostanzialmente
funzionale pu creare uno speciale gruppo per gestire un progetto particolarmente
importante. Tale gruppo avr molte delle caratteristiche di un gruppo di progetto
appartenente a unorganizzazione progettuale. Esso includer personale dedicato a
tempo pieno proveniente da vari reparti funzionali e svilupper procedure proprie,
operando anche al di fuori della struttura gerarchica standard.

31
2.3.4
Ruolo del PMO nelle strutture organizzative

Sono numerose le strutture organizzative che si rendono conto dei vantaggi ottenuti
dallo sviluppo e dallimplementazione di un PMO (sezione 1.6.4). I vantaggi sono
spesso particolarmente evidenti per quelle strutture organizzative che hanno adottato
una struttura organizzativa a matrice, e sono quasi sempre evidenti per le strutture
organizzative caratterizzate da una struttura progettuale, soprattutto nel caso in cui
lorganizzazione principale sia coinvolta nella gestione simultanea di vari progetti e/o
di progetti sequenziali.
Il PMO pu essere adottato in qualsiasi struttura organizzativa, comprese quelle
con organizzazioni funzionali, con maggiore probabilit che accada nelle strutture
presenti nelle colonne pi a destra della figura 2-6.
La funzione del PMO allinterno di unorganizzazione varia dal ricoprire un
ruolo di semplice consulente, che si limita al suggerimento di regole e procedure
specifiche per singoli progetti, fino alla concessione formale di autorit da parte della
direzione. In questultimo caso, il PMO pu a sua volta delegare la propria autorit ai
singoli project manager. Il project manager avr il supporto amministrativo offerto dal
PMO sia mediante personale dedicato sia mediante personale condiviso con altri
progetti. I membri del gruppo di progetto possono essere impegnati esclusivamente
sul progetto oppure pu verificarsi il caso in cui i membri assegnati comprendano
anche personale che collabora ad altri progetti ed a sua volta gestito dal PMO.
I membri del gruppo di progetto fanno riferimento direttamente al project
manager oppure al PMO, qualora siano in condivisione con altri, mentre il project
manager fa riferimento direttamente al PMO. Inoltre, la flessibilit della gestione
centralizzata del PMO pu offrire al project manager maggiori possibilit di
avanzamento allinterno della struttura organizzativa. In strutture organizzative che
sono dotate di PMO, i membri del gruppo di progetto specializzati possono avere
opportunit di carriera alternative nel Project Management.
In presenza di un PMO, la figura 2-8 dovrebbe comprendere una casella
aggiuntiva, denominata PMO, tra il livello del project manager e il livello del direttore
generale. Analogamente, nelle figure 2-11 e 2-12, il manager dei project manager
sarebbe in genere il manager del PMO, mentre in altre strutture organizzative (figure
2-9 e 2-10), il PMO, di solito, non riporta direttamente al direttore generale.
32

2.3.5
Sistema di Project Management

Il sistema di Project Management un insieme di strumenti, tecniche, metodologie,
risorse e procedure utilizzati per gestire un progetto. Pu essere sia formale che
informale e consente al project manager di portare a termine in modo efficace il
proprio progetto. Il sistema un insieme di processi e delle relative funzioni di
controllo che sono consolidati e che vengono raggruppati e uniti e funzionano come
un tuttuno.
Il piano di Project Management descrive come sar usato il sistema di Project
Management. Il contenuto del sistema di Project Management varia in base allarea
applicativa, allinfluenza della struttura organizzativa, alla complessit del progetto e
alla disponibilit di sistemi esistenti. Linfluenza della struttura organizzativa consente
di plasmare il sistema ai fini dellesecuzione dei progetti allinterno della specifica
struttura organizzativa. Il sistema sar aggiustato o adattato al fine di recepire
qualsiasi influenza imposta dalla struttura organizzativa.
Se nella Performing Organization presente un PMO, una delle due funzioni
tipiche che esso svolger sar quella di gestire il sistema di Project Management, per
garantirne la consistenza e la continuit sui vari progetti in fase di esecuzione.

33
Sezione II
Lo standard per il Project
Management di un progetto
Capitolo 3
Processi di Project Management per

un progetto
CAPITOLO 3
Processi di Project Management per un

progetto
Il Project Management lapplicazione di conoscenze, skill, strumenti e tecniche alle
attivit di progetto per soddisfare i requisiti del progetto. Il Project Management viene
espletato per mezzo di processi, utilizzando conoscenze, skill, strumenti e tecniche di
Project Management che ricevono input e generano output.
Affinch un progetto venga portato a termine con successo, il gruppo di progetto
deve:
Selezionare, allinterno dei gruppi di processi di Project Management (detti
anche gruppi di processi), i processi necessari per raggiungere gli obiettivi di
progetto.
Utilizzare un approccio definito per adattare le specifiche e i piani di prodotto ai
requisiti di progetto e di prodotto.
Rispettare i requisiti per soddisfare i bisogni, i desideri e le aspettative degli
stakeholder.
Individuare il giusto equilibrio nel conflitto tra le esigenze di ambito, tempo,
costo, qualit, risorse e rischio per produrre un prodotto di qualit.
Questo standard documenta le informazioni necessarie per avviare, pianificare,
eseguire, monitorare, controllare e chiudere un singolo progetto e identifica i processi
di Project Management ritenuti buone pratiche nella maggior parte dei progetti il pi
delle volte. Tali processi si applicano globalmente a tutte le categorie industriali. Per
buona pratica si intende che esiste un consenso generale sul fatto che lapplicazione di
tali processi di Project Management sia in grado di incrementare le possibilit di
successo per una vasta gamma di progetti.
Questo non significa tuttavia che la conoscenza, gli skill e i processi
descritti debbano sempre essere applicati in maniera uniforme a tutti i
progetti. Il project manager, unitamente al gruppo di progetto, ha il
compito di determinare per ogni specifico progetto quali processi
siano idonei e quale sia il grado di rigore adatto ad ogni processo.

37
Capitolo 3 Processi di Project Management per un progetto
In effetti, i project manager e i componenti dei gruppi di progetto dovrebbero

analizzare ogni singolo processo e i relativi input e output. I project manager e i
componenti dei gruppi di progetto devono utilizzare questo capitolo come una guida
di alto livello per tutti i processi da prendere in considerazione durante la gestione del
progetto. Questo quello che si chiama personalizzazione.
Un processo un insieme di azioni e attivit correlate compiute per ottenere una
determinata serie di prodotti, risultati o servizi. I processi di Project Management
vengono seguiti dal gruppo di progetto e in genere rientrano in una delle categorie
riportate di seguito:
I processi di Project Management comuni alla maggior parte dei progetti il pi
delle volte sono collegati luno allaltro dal fatto che si eseguono per uno scopo
integrato. Lobiettivo quello di avviare, pianificare, eseguire, monitorare,
controllare e chiudere un progetto. I processi creano tra loro interazioni
complesse, non rappresentabili in maniera esaustiva in un documento o con dei
grafici. Tuttavia, la figura 3-4 mostra un esempio di interazioni tra i gruppi di
processi. I processi possono interagire anche per quanto riguarda lambito, il
costo, la schedulazione di progetto e cos via, cio nelle aree di conoscenza
descritte nei capitoli dal 4 al 12.
I processi orientati al prodotto specificano e creano il prodotto del progetto. Essi
sono generalmente definiti dal ciclo di vita del progetto (trattato nella
sezione 2.1) e variano secondo larea applicativa. I processi di Project
Management e i processi orientati al prodotto interagiscono e si sovrappongono
durante lo svolgimento del progetto. Ad esempio, non possibile definire
lambito del progetto senza una conoscenza di base delle modalit di creazione
del prodotto specificato.
Il Project Management unattivit di integrazione che richiede che ogni
processo del progetto e del prodotto sia adeguatamente allineato e collegato agli altri
processi per facilitarne il coordinamento. Le interazioni tra i processi spesso
richiedono mediazioni tra i requisiti e gli obiettivi di progetto. Un progetto esteso e
complesso pu comprendere processi da ripetere pi volte per definire e soddisfare i
requisiti degli stakeholder e raggiungere un accordo sul risultato dei processi. Se nel
corso del processo non si agisce nel modo opportuno, il processo e gli altri processi ad
esso correlati ne saranno influenzati. Ad esempio, una modifica dellambito ha quasi
certamente effetti sul costo di progetto, ma pu non influire sul morale del gruppo o
sulla qualit del prodotto. Le mediazioni tra le diverse prestazioni possono variare a
seconda dei progetti e delle strutture organizzative. Un Project Management efficace
presuppone una gestione attiva di tali interazioni per soddisfare i requisiti dettati da
sponsor, clienti e altri stakeholder.
Questo standard descrive la natura dei processi di Project Management in
termini di integrazione tra i processi, interazione interna e scopi che questi si
propongono di raggiungere. I processi sono riuniti nei cinque diversi gruppi riportati
di seguito, detti gruppi di processi di Project Management:
Gruppo di processi di avvio
Gruppo di processi di pianificazione
Gruppo di processi di esecuzione
Gruppo di processi di monitoraggio e controllo
Gruppo di processi di chiusura
38

Questo capitolo fornisce informazioni riguardo al Project Management di un

singolo progetto, in quanto insieme di processi collegati, e comprende le seguenti
sezioni:
3.1 Processi di Project Management
3.2 Gruppi di processi di Project Management
3.3 Interazioni tra processi
3.4 Mappatura dei processi di Project Management
3.1
Processi di Project Management

I processi di Project Management vengono presentati come elementi distinti con
interfacce ben definite. In realt, si sovrappongono e interagiscono in modi che non
sono descritti dettagliatamente in questo standard. I professionisti pi esperti del
Project Management riconoscono in genere che esistono diversi modi per gestire un
progetto. Le caratteristiche di un progetto vengono definite sotto forma di obiettivi da
raggiungere sulla base di complessit, rischio, dimensioni, tempistica, esperienza del
gruppo di progetto, accesso alle risorse, quantit di dati storici, maturit di Project
Management della struttura organizzativa, settore e area applicativa. I gruppi di
processi necessari e i relativi processi fungono da guida per lapplicazione delle
conoscenze e degli skill di Project Management nel corso del progetto. Inoltre,
lapplicazione dei processi di Project Management a un progetto iterativa e molti
processi vengono ripetuti e rivisti nel corso del progetto. Il project manager e il
gruppo di progetto devono assumersi la responsabilit di scegliere quali processi dei
gruppi di progetto utilizzare, chi deve utilizzarli e quale grado di rigore deve essere
applicato alla loro esecuzione per raggiungere lobiettivo di progetto desiderato.
Il ciclo plan-do-check-act (ideato da Shewhart e modificato da Deming,
nellASQ Handbook, pag. 1314, American Society for Quality, 1999) rappresenta un
concetto fondamentale nellambito dellinterazione tra i processi di Project
Management. Questo ciclo legato dai risultati: il risultato uscente da una parte del
ciclo diventa linput per unaltra. Vedere la figura 3-1.
Figura 3-1. Ciclo Plan-Do-Check-Act

39
Il carattere integrativo dei gruppi di processi molto pi complesso del ciclo

plan-do-check-act (vedere la figura 3-2). Tuttavia, possibile applicare il ciclo alle
interrelazioni che si sviluppano allinterno dei gruppi di processi e tra un gruppo e
laltro. Il gruppo di processi di pianificazione corrisponde alla componente plan del
ciclo plan-do-check-act. Il gruppo di processi di esecuzione corrisponde alla
componente do e il gruppo di processi di monitoraggio e controllo corrisponde alle
componenti check e act. Inoltre, poich la gestione di un progetto costituisce uno
sforzo circoscritto, il gruppo di processi di avvio costituisce linizio dei cicli, mentre il
gruppo di processi di chiusura ne rappresenta la fine. Il carattere integrativo del
Project Management richiede linterazione del gruppo di processi di monitoraggio e
controllo con ogni aspetto degli altri gruppi di processi.
Figura 3-2. Gruppi di processi di Project Management descritti secondo il ciclo

Plan-Do-Check-Act
3.2
Gruppi di processi di Project Management

Questa sezione identifica e descrive i cinque gruppi di processi di Project
Management necessari per qualsiasi progetto. Tali gruppi sono caratterizzati da chiare
relazioni di dipendenza e vengono eseguiti nella stessa sequenza in ogni progetto. Non
dipendono dallarea applicativa o del settore di mercato. I singoli gruppi di processi e i
singoli processi costitutivi vengono spesso ripetuti nel corso del progetto prima che
questo si completi. I processi costitutivi possono sviluppare interazioni sia allinterno
di un gruppo di processi sia tra pi gruppi di processi.
Nella figura 3-3 vengono riportati i simboli utilizzati nei diagrammi di flusso di
processo:
Gruppi di processi.
Processi allinterno dei gruppi di processi.
Asset dei processi organizzativi e fattori ambientali aziendali, rappresentati
come input e output dei gruppi di processi, ma esterni ai processi.
Le frecce o le frecce lineari indicano il flusso di processi o di dati tra i gruppi di
processi o al loro interno.
40

Nota: per rendere pi comprensibili i diagrammi, non sono stati inseriti

tutti i flussi di dati tra i processi e le interazioni dei processi.
Figura 3-3. Legenda del diagramma di flusso
Il diagramma di flusso di processo, rappresentato in figura 3-4, costituisce un

riepilogo generale del flusso e delle interazioni di base tra i gruppi di processi. Un
singolo processo pu determinare e vincolare la modalit di utilizzo degli input per la
produzione degli output di quel particolare gruppo di processi. Un gruppo di processi
include i processi di Project Management costitutivi collegati dai rispettivi input e
output, vale a dire in cui il risultato o leffetto di un processo diventa linput di un
altro. Ad esempio, il gruppo di processi di monitoraggio e controllo monitora e
controlla non solo il lavoro svolto nel corso di un gruppo di processi, ma anche lo
sforzo di progetto complessivo. Il gruppo di processi di monitoraggio e controllo deve
inoltre fornire un feedback che faciliti lattuazione di azioni preventive o correttive per
la realizzazione conforme al piano di Project Management del progetto o per
leventuale modifica di tale piano. probabile che tra i gruppi di processi si
sviluppino molte interazioni aggiuntive. I gruppi di processi sono diversi dalle fasi
di progetto. Quando progetti particolarmente estesi o complessi vengono separati in
fasi o sottoprogetti distinti (ad es. studio di fattibilit, sviluppo dellidea,
progettazione, prototipazione, creazione, collaudo e cos via), tutti i processi dei
gruppi di processi vengono generalmente ripetuti per ogni fase o sottoprogetto.
Di seguito vengono elencati i cinque gruppi di processi.
Gruppo di processi di avvio: definisce e autorizza il progetto o una fase del
progetto.
Gruppo di processi di pianificazione: definisce e perfeziona gli obiettivi e
pianifica lo svolgimento delle azioni necessarie per il raggiungimento degli
obiettivi e dellambito stabliti per il progetto.
Gruppo di processi di esecuzione: integra persone e altre risorse per
lattuazione del piano di Project Management del progetto.
Gruppo di processi di monitoraggio e controllo: misura e monitora
regolarmente lavanzamento per identificare scostamenti dal piano di Project
Management, in modo da consentire eventuali azioni correttive per il
raggiungimento degli obiettivi di progetto.
Gruppo di processi di chiusura: formalizza laccettazione del prodotto, del
servizio o del risultato e consente la chiusura corretta del progetto o di una fase
del progetto.

41
Nota: non vengono mostrati tutti i flussi di dati e le interazioni dei processi tra i gruppi di processi.
Figura 3-4. Riepilogo ad alto livello delle interazioni dei gruppi di processi
42

3.2.1
Gruppo di processi di avvio

Il gruppo di processi di avvio comprende i processi che facilitano lautorizzazione
formale a iniziare un nuovo progetto o una nuova fase di progetto. I processi di avvio
sono di solito esterni allarea di controllo del progetto e vengono svolti dalla struttura
organizzativa o dai processi di gestione di programma o di portfolio (Figura 3-5).
Questo potrebbe rendere pi indefiniti i confini del progetto per quanto riguarda gli
input iniziali. Ad esempio, prima dellinizio delle attivit del gruppo di processi di
avvio, vengono descritti i requisiti e le esigenze di business della struttura
organizzativa. Si potrebbe fare una valutazione di fattibilit del nuovo impegno
attraverso un processo di analisi delle alternative per individuare la pi idonea. Si
produce una descrizione precisa degli obiettivi del progetto se necessario spiegando
perch si ritiene che uno specifico progetto sia la migliore alternativa per soddisfare i
requisiti. La documentazione di tale decisione contiene inoltre una descrizione
sommaria dellambito del progetto, dei deliverable, della durata del progetto e una
previsione delle risorse per lanalisi dellinvestimento da parte della struttura
organizzativa. Documentare i processi di selezione del progetto consente di chiarire il
quadro complessivo del progetto. La relazione tra il progetto e il piano strategico della
struttura organizzativa identifica le responsabilit del management allinterno della
struttura organizzativa. Nei progetti a pi fasi, i processi di avvio vengono eseguiti in
fasi successive per consentire la convalida degli assunti e delle decisioni elaborati nel
corso dei processi originali Sviluppare il Project Charter e Sviluppare la descrizione
preliminare dellambito del progetto.
Figura 3-5. Confini del progetto
Nel corso del processo di avvio vengono ulteriormente specificate la descrizione

iniziale dellambito e le risorse che la struttura organizzativa disposta a investire. Se
non gi stato assegnato, viene selezionato un project manager. Vengono inoltre
documentati gli assunti e i vincoli iniziali. Tali informazioni vengono inserite nel
Project Charter e, una volta che questo stato approvato, il progetto riceve
lautorizzazione ufficiale. Sebbene il gruppo di Project Management possa redigere il
Project Charter, lapprovazione e lassegnazione di fondi vengono gestiti allesterno
dei confini del progetto.

43
Allinterno del gruppo di processi di avvio, progetti particolarmente estesi o

complessi possono essere suddivisi in fasi. La revisione dei processi di avvio allinizio
di ogni fase facilita la focalizzazione sulle esigenze di business che il progetto deve
soddisfare. Vengono verificati i criteri di avvio, compresa la disponibilit delle risorse
necessarie. In seguito, viene deciso se il progetto pu proseguire o se deve essere
posticipato o abbandonato. Nel corso delle successive fasi di progetto, viene fatta
unaltra verifica e un ulteriore sviluppo dellambito del progetto per la fase
specificata. Inoltre, la ripetizione dei processi di avvio ad ogni fase successiva
consente la sospensione del progetto se viene meno lesigenza di business o se si
ritiene che il progetto non ne permetta la soddisfazione.
Il coinvolgimento dei clienti e degli altri stakeholder durante la fase di avvio
aumenta in genere le probabilit che ci siano condivisione del progetto, accettazione
dei deliverable e soddisfazione dei clienti e degli altri stakeholder. Tale accettazione
alla base del successo del progetto. Il gruppo di processi di avvio (Figura 3-6) d
inizio a un progetto o a una fase di progetto e loutput ne definisce lo scopo, stabilisce
gli obiettivi e autorizza il project manager ad avviare il progetto.
Figura 3-6. Gruppo di processi di avvio
44

Il gruppo di processi di avvio include i processi di Project Management descritti

di seguito.
.1
Sviluppare il Project Charter

Questo processo riguarda principalmente lautorizzazione a dare inizio a un progetto
o, nel caso di un progetto multi-fase, a una fase di progetto. Si tratta del processo
necessario per documentare le esigenze di business e il nuovo prodotto, il servizio o
qualsiasi altro risultato che si prefigge la soddisfazione di tali requisiti. Questo
documento costituisce un collegamento tra il progetto e le attivit operative della
struttura organizzativa e autorizza il progetto. I progetti vengono autorizzati
esternamente al progetto da parte della struttura organizzativa oppure da un organismo
di gestione di programma o di portfolio. Nei progetti a pi fasi, questo processo viene
utilizzato per convalidare o perfezionare le decisioni prese nel corso del processo
Sviluppare il Project Charter precedente.
Tabella 3-1. Sviluppare il Project Charter: input e output
.2
Sviluppare la descrizione preliminare dellambito del progetto

Processo di definizione preliminare ad alto livello del progetto utilizzando il Project
Charter e altri input ai processi di avvio. Questo processo riguarda e documenta i
requisiti del progetto e dei deliverable, i requisiti dei prodotti, i confini del progetto, i
metodi di accettazione e il controllo dellambito ad alto livello. Nei progetti multifase, tale processo convalida o perfeziona lambito del progetto per ogni fase.
Tabella 3-2. Sviluppare la descrizione preliminare dellambito di progetto: input e output

45
3.2.2
Gruppo di processi di pianificazione

Il gruppo di Project Management utilizza il gruppo di processi di pianificazione e i
processi e le interazioni che lo compongono per pianificare e gestire un progetto di
successo per la struttura organizzativa. Il gruppo di processi di pianificazione facilita
la raccolta di informazioni da diverse fonti, ognuna con un diverso livello di
completezza e affidabilit. I processi di pianificazione consentono lo sviluppo del
piano di Project Management. Inoltre, tali processi contribuiscono alla identificazione,
definizione e maturazione dellambito e del costo del progetto e alla schedulazione
delle attivit di progetto. Mano a mano che il progetto si arricchisce di informazioni, si
identificano o si risolvono le relazioni di dipendenza, i requisiti, i rischi, le
opportunit, gli assunti e i vincoli. Il carattere multi-dimensionale del Project
Management porta a continui cicli di feedback per ulteriori analisi. Con lincremento
delle informazioni o delle caratteristiche del progetto, possono essere necessarie
azioni mirate. Se durante il ciclo di vita del progetto si verificano cambiamenti
significativi, pu rivelarsi necessario rivisitare uno o pi processi di pianificazione e,
possibilmente, alcuni processi di avvio.
Viene influenzata anche la frequenza di ripetizione dei processi di
pianificazione. Ad esempio, il piano di Project Management, che costituisce un output
del gruppo di processi di pianificazione, sar caratterizzato da unattenzione
particolare per tutti gli aspetti legati allambito, alla tecnologia, ai rischi e ai costi. Gli
aggiornamenti causati dai cambiamenti approvati durante lesecuzione del progetto
possono avere un impatto significativo su alcune parti del piano di Project
Management. Gli aggiornamenti al piano di Project Management portano a una
maggiore precisione per quanto riguarda la schedulazione, i costi e i requisiti delle
risorse, per consentire la completa realizzazione dellambito del progetto. Gli
aggiornamenti possono essere limitati alle attivit e alle questioni associate
allesecuzione di una fase specifica. Questa progressiva specificazione del piano di
Project Management viene di solito definita pianificazione a finestra mobile, per
indicare che la pianificazione un processo iterativo e continuo (vedere figura 3-7).
Durante la pianificazione del progetto, il gruppo di progetto deve coinvolgere
tutti gli stakeholder necessari, in base alla loro influenza sul progetto e sui risultati. Il
coinvolgimento degli stakeholder fondamentale, perch sono depositari di skill e
conoscenze utili allo sviluppo del piano di Project Management e di eventuali altri
piani ausiliari. Il gruppo di progetto ha il compito di creare un ambiente che incoraggi
la partecipazione degli stakeholder.
Poich il processo di feedback e di perfezionamento delle informazioni non pu
continuare indefinitamente, le procedure stabilite dalla struttura organizzativa
stabiliscono il momento in cui interrompere la pianificazione. Tali procedure
dipendono dalla natura del progetto, dai confini stabiliti per il progetto, delle attivit di
monitoraggio e controllo e dellambiente in cui si svolge il progetto.
La natura del progetto condiziona anche altre interazioni tra i processi del
gruppo di processi di pianificazione. Ad esempio, in alcuni progetti i rischi possono
essere pochi o non identificabili fino a quando la pianificazione non quasi finita. A
questo punto, il gruppo potrebbe rendersi conto che gli obiettivi in termini di costo e
schedulazione sono molto ambiziosi e che i rischi del progetto sono di gran lunga
superiori di quanto originariamente preventivato. I risultati delle iterazioni vengono
documentati come aggiornamenti al piano di Project Management.
46

Nota: non vengono mostrate tutte le interazioni dei processi e il flusso di dati tra processi.
Figura 3-7. Gruppo di processi di pianificazione
Il gruppo di processi di pianificazione semplifica la pianificazione del progetto

su pi processi. Il seguente elenco mostra i processi che dovrebbero essere seguiti dal
gruppo di progetto nella pianificazione per decidere se sia necessario svolgerli ed
eventualmente per individuare chi ne sar responsabile. Il gruppo di processi di
pianificazione include i processi di Project Management descritti di seguito.

47
.1
Sviluppare il piano di Project Management

Processo di definizione, preparazione, integrazione e coordinamento di tutti i piani
secondari in un unico piano di Project Management. Il piano di Project Management
diviene la fonte principale di informazioni sulla modalit di pianificazione,
esecuzione, monitoraggio e controllo e infine chiusura del progetto.
Tabella 3-3. Sviluppare il piano di Project Management: input e output
.2
Pianificazione dellambito
Processo di creazione del piano di gestione dellambito del progetto che documenta
come lambito del progetto verr definito, verificato e controllato e come creare e
definire la struttura di scomposizione del lavoro (WBS).
Tabella 3-4. Pianificazione dellambito: input e output
48

.3
Definizione dellambito
Processo di sviluppo della descrizione dellambito del progetto dettagliata da
utilizzare come base per le decisioni future sul progetto.
Tabella 3-5. Definizione dellambito: input e output
.4
Creare la WBS
Processo di suddivisione dei principali deliverable del progetto e del lavoro previsto
dal progetto in componenti pi piccoli e quindi maggiormente gestibili.
Tabella 3-6. Creare la WBS: input e output
.5
Definire le attivit
Processo di identificazione delle attivit specifiche da eseguire per produrre i vari
deliverable del progetto.
Tabella 3-7. Definire le attivit: input e output

49
.6
Sequenzializzazione delle attivit

Processo di identificazione e documentazione delle relazioni di dipendenza tra le
attivit schedulate.
Tabella 3-8. Sequenzializzazione delle attivit: input e output
.7
Stima delle risorse delle attivit

Processo di stima del tipo e della quantit di risorse necessarie a eseguire ciascuna
attivit schedulata.
Tabella 3-9. Stima delle risorse delle attivit: input e output
.8
Stima della durata delle attivit

Processo di stima del numero di periodi lavorativi richiesti per portare a termine le
singole attivit schedulate.
Tabella 3-10. Stima della durata delle attivit: input e output
50

.9
Sviluppo della schedulazione

Processo di analisi delle sequenze e delle durate delle attivit, dei requisiti delle
risorse e dei vincoli della schedulazione per la creazione della schedulazione di
progetto.
Tabella 3-11. Sviluppo della schedulazione: input e output
.10
Stima dei costi

Processo di sviluppo di unapprossimazione del costo delle risorse necessarie al
completamento delle attivit di progetto.
Tabella 3-12. Stima dei costi: input e output
.11
Allocazione dei costi

Processo di aggregazione dei costi stimati per le singole attivit o i Work Package che
consente di stabilire una baseline dei costi.
Tabella 3-13. Allocazione dei costi: input e output

51
.12
Pianificazione della qualit

Processo che consente di identificare quali standard di qualit devono essere applicati
al progetto e di determinare come soddisfarli.
Tabella 3-14. Pianificazione della qualit: input e output
.13
Pianificazione delle risorse umane

Processo di identificazione e documentazione dei ruoli del progetto, delle
responsabilit e dei riporti, nonch di creazione del piano di gestione del personale.
Tabella 3-15. Pianificazione delle risorse umane: input e output
.14
Pianificazione della comunicazione

Processo di determinazione delle esigenze in termini di informazioni e comunicazione
degli stakeholder di progetto.
Tabella 3-16. Pianificazione della comunicazione: input e output
52

.15
Pianificazione della gestione dei rischi

Processo che consente di decidere come affrontare, pianificare ed eseguire le attivit
di gestione del rischio per il progetto.
Tabella 3-17. Pianificazione della gestione dei rischi: input e output
.16
Identificare i rischi
Processo di determinazione di quali rischi possono influire sul progetto e di
documentazione delle loro caratteristiche.
Tabella 3-18. Identificare i rischi: input e output
.17
Analisi qualitativa del rischio

Processo che assegna una priorit ai rischi ai fini di unulteriore analisi od azione
mediante la valutazione e la combinazione della probabilit che si verifichino e del
loro impatto.
Tabella 3-19. Analisi qualitativa del rischio: input e output

53
.18
Analisi quantitativa del rischio

Processo di analisi numerica delleffetto dei rischi identificati sugli obiettivi
complessivi del progetto.
Tabella 3-20. Analisi quantitativa del rischio: input e output
.19
Pianificazione della risposta ai rischi

Processo di sviluppo ddi alternative e azioni che consentono di aumentare le
opportunit e ridurre le minacce agli obiettivi del progetto.
Tabella 3-21. Pianificazione della risposta ai rischi: input e output
.20
Pianificare gli acquisti

Processo che consente di determinare cosa acquistare o acquisire e dove e come
effettuare tali operazioni.
Tabella 3-22. Pianificare gli acquisti: input e output
54

.21
Pianificare le forniture
Processo di documentazione dei requisiti di prodotti, servizi e risultati e di
identificazione dei potenziali fornitori.
Tabella 3-23. Pianificare le forniture: input e output
3.2.3
Gruppo di processi di esecuzione

Il gruppo di processi di esecuzione composto dai processi utilizzati per portare a
termine il lavoro definito nel piano di Project Management per soddisfare i requisiti
del progetto. Il gruppo di progetto deve determinare quali sono i processi necessari per
lo specifico progetto. Questo gruppo di processi prevede il coordinamento delle
persone e delle risorse, oltre allintegrazione e allesecuzione delle attivit del progetto
come stabilito nel piano di Project Management. Questo gruppo di processi si occupa
anche dellambito definito nella descrizione dellambito del progetto e
dellimplementazione delle modifiche approvate (vedere figura 3-8).
Figura 3-8. Gruppo di processi di esecuzione

55
I normali scostamenti nellesecuzione comporteranno una ripianificazione.

Questi scostamenti possono riguardare la durata delle attivit, la produttivit e la
disponibilit delle risorse e i rischi non previsti; potrebbero influire o meno sul piano
di Project Management e potrebbero richiedere unattivit di analisi. Il risultato
dellanalisi pu generare una richiesta di modifica che, se approvata, comporter la
modifica del piano di Project Management ed eventualmente la determinazione di una
nuova baseline. Il budget del progetto viene in massima parte utilizzato per lo
svolgimento dei processi appartenenti al gruppo di processi di esecuzione. Il gruppo di
processi di esecuzione include i processi di Project Management descritti di seguito.
.1
Dirigere e gestire lesecuzione del progetto

Processo che consente di guidare le varie interfacce di tipo tecnico e organizzativo
presenti nel progetto per lesecuzione del lavoro definito nel piano di Project
Management. I deliverable vengono prodotti come output dei processi, che vengono
eseguiti come definito nel piano di Project Management. Le informazioni sullo stato
di completamento dei deliverable e sul lavoro effettivamente portato a termine
vengono raccolte nellambito dellesecuzione del progetto e date in input al processo
di reporting delle prestazioni.
Tabella 3-24. Dirigere e gestire lesecuzione del progetto: input e output
.2
Effettuare lassicurazione qualit

Processo di applicazione di attivit pianificate e sistematiche per il controllo qualit
che consentono di garantire che il progetto utilizzi tutti i processi necessari a
soddisfare i requisiti.
Tabella 3-25. Effettuare lassicurazione qualit: input e output
56

.3
Acquisire il gruppo di progetto

Processo che consente di ottenere le risorse umane necessarie per portare a termine il
progetto.
Tabella 3-26. Acquisire il gruppo di progetto: input e output
.4
Sviluppare il gruppo di progetto

Processo di miglioramento delle competenze e dellinterazione tra i membri del
gruppo di lavoro che consente di incrementare le prestazioni del progetto.
Tabella 3-27. Sviluppare il gruppo di progetto: input e output
.5
Distribuzione delle informazioni

Processo che consente di rendere disponibili in modo tempestivo le informazioni
richieste agli stakeholder di progetto.
Tabella 3-28. Distribuzione delle informazioni: input e output

57
.6
Richiesta di risposte dai fornitori

Processo che consente di ottenere informazioni, preventivi, offerte dappalto, offerte o
proposte.
Tabella 3-29. Richiesta di risposte dai fornitori: input e output
.7
Selezionare i fornitori
Processo di analisi delle offerte, di scelta tra potenziali fornitori e di negoziazione di
un contratto scritto con il fornitore.
Tabella 3-30. Selezionare i fornitori: input e output
58

3.2.4
Gruppo di processi di monitoraggio e controllo

Il gruppo di processi di monitoraggio e controllo consiste nei processi eseguiti per
osservare lesecuzione del progetto in modo da poter identificare tempestivamente i
potenziali problemi e adottare le adeguate misure correttive, ove necessarie, al fine di
controllare lesecuzione del progetto. Il gruppo di progetto deve determinare quali
processi sono necessari per lo specifico progetto assegnato. Il principale vantaggio di
questo gruppo di processi che consente di osservare e misurare regolarmente le
prestazioni del progetto al fine di identificare gli scostamenti dal piano di Project
Management. Il gruppo di processi di monitoraggio e controllo comprende anche il
controllo delle modifiche e il suggerimento di azioni preventive in previsione di
possibili problemi. Questo gruppo contiene, per esempio, i seguenti processi:
Monitorare le attivit di progetto in corso a fronte del piano di Project
Management e della baseline delle prestazioni del progetto.
Influire sui fattori che potrebbero aggirare il controllo integrato delle modifiche
in modo da implementare soltanto le modifiche approvate.
Il continuo monitoraggio fornisce al gruppo di progetto una conoscenza delle
condizioni del progetto ed evidenzia le eventuali aree che richiedono unattenzione
particolare. Il gruppo di processi di monitoraggio e controllo non solo consente di
monitorare e controllare il lavoro svolto allinterno di un gruppo di processi, ma
monitora e controlla anche lo sforzo totale profuso nel progetto. In progetti multi-fase, il
gruppo di processi di monitoraggio e controllo fornisce anche un feedback tra le fasi di
progetto che consente di implementare azioni correttive o preventive per garantire la
conformit del progetto al piano di Project Management. Quando gli scostamenti
mettono a repentaglio gli obiettivi del progetto, si ritorna sui processi di pianificazione
come suggerito dal ciclo plan-do-check-act. Questa revisione potrebbe suggerire degli
aggiornamenti al piano di Project Management. Ad esempio, il mancato completamento
di unattivit alla data di fine pianificata pu richiedere modifiche al piano delle risorse,
il ricorso al lavoro straordinario o compromessi tra budget e obiettivi della
schedulazione. La figura 3-9 illustra alcune interazioni tra processi che sono
fondamentali per questo gruppo di processi.

59
Figura 3-9. Gruppo di processi di monitoraggio e controllo
Il gruppo di processi di monitoraggio e controllo include i processi di Project

Management descritti di seguito.
60

.1
Monitorare e controllare il lavoro del progetto

Processo che consente di raccogliere, misurare e diffondere le informazioni sulle
prestazioni e di valutare le misurazioni e le tendenze per migliorare il processo.
Questo processo include il monitoraggio dei rischi per consentire di identificare
precocemente i rischi, di documentarne lo stato e di garantire che vengano eseguiti dei
piani contro i rischi adatti. Il monitoraggio comprende il reporting sullo stato, le
misurazioni dellavanzamento del progetto ed eventuali previsioni. I report sulle
prestazioni forniscono informazioni sulle prestazioni del progetto in merito ad ambito,
schedulazione, costo, risorse, qualit e rischio.
Tabella 3-31. Monitorare e controllare il lavoro del progetto: input e output
.2
Controllo integrato delle modifiche

Processo che consente di controllare dei fattori che generano modifiche per garantire
che tali modifiche siano vantaggiose, di determinare se si verificata una modifica e
di gestire le modifiche approvate. Il processo viene eseguito per tutta la durata del
progetto, dallavvio alla chiusura.
Tabella 3-32. Controllo integrato delle modifiche: input e output

61
.3
Verifica dellambito
Processo che consente di formalizzare laccettazione dei deliverable di progetto
completati.
Tabella 3-33. Verifica dellambito: input e output
.4
Controllo dellambito
Processo di controllo delle modifiche apportate allambito del progetto.
Tabella 3-34. Controllo dellambito: input e output
.5
Controllo della schedulazione

Processo di controllo delle modifiche apportate alla schedulazione di progetto.
Tabella 3-35. Controllo della schedulazione: input e output
62

.6
Controllo dei costi

Processo che consente di influire sui fattori responsabili degli scostamenti e di
controllare le modifiche al budget del progetto.
Tabella 3-36. Controllo dei costi: input e output
.7
Esecuzione del controllo di qualit

Processo di monitoraggio dei risultati specifici di un progetto per determinare la loro
conformit agli standard di qualit indicati e di individuazione dei metodi per
eliminare le cause di prestazioni non soddisfacenti.
Tabella 3-37. Esecuzione del controllo di qualit: input e output
.8
Gestire il gruppo di progetto

Processo di rilevamento delle prestazioni dei membri del gruppo, di restituzione di
feedback, di risoluzione dei problemi e di coordinamento delle modifiche volto a
migliorare le prestazioni del progetto.
Tabella 3-38. Gestire il gruppo di progetto: input e output

63
.9
Reporting delle prestazioni

Processo di raccolta e distribuzione delle informazioni sulle prestazioni che
comprende rapporti sullo stato del progetto, misurazioni dellavanzamento e
previsioni.
Tabella 3-39. Reporting delle prestazioni: input e output
.10
Gestire gli stakeholder

Processo di gestione delle comunicazioni che consente di soddisfare i requisiti degli
stakeholder di progetto e di risolvere eventuali problemi con loro.
Tabella 3-40. Gestire gli stakeholder: input e output
64

.11
Monitoraggio e controllo dei rischi

Processo di rilevazione dei rischi identificati, monitoraggio dei rischi residui,
identificazione dei rischi nuovi, attuazione dei piani di risposta al rischio e valutazione
dellefficacia di queste operazioni nel corso del ciclo di vita del progetto.
Tabella 3-41. Monitoraggio e controllo dei rischi: input e output
.12
Amministrazione del contratto

Processi di gestione del contratto e delle relazioni tra acquirente e fornitore, di analisi
e documentazione delle prestazioni del fornitore e, se necessario, di gestione delle
relazioni contrattuali con lacquirente esterno al progetto.
Tabella 3-42. Amministrazione del contratto: input e output

65
3.2.5
Gruppo di processi di chiusura

Il gruppo di processi di chiusura comprende i processi utilizzati per terminare
formalmente tutte le attivit di un progetto o di una fase di progetto, per inoltrare ad
altri il prodotto finito o per chiudere un progetto annullato. Questo gruppo di processi,
una volta completato, verifica che i processi definiti siano stati portati a termine in
tutti i gruppi di processi per chiudere formalmente il progetto o la fase di progetto, a
seconda dei casi, e decreta formalmente la conclusione del progetto o della fase di
progetto. Vedere la figura 3-10.
Figura 3-10. Gruppo di processi di chiusura
66

Il gruppo di processi di chiusura include i processi di Project Management

.1
Chiudere il progetto
Processo di completamento di tutte le attivit appartenenti a tutti i gruppi di processi
che consente di chiudere formalmente il progetto o la fase di progetto.
Tabella 3-43. Chiudere il progetto: input e output
.2
Chiusura del contratto

Processo di completamento e di saldo di ciascun contratto, comprese la risoluzione di
eventuali questioni ancora aperte e la chiusura di ciascun contratto previsto nel
progetto o nella fase del progetto.
Tabella 3-44. Chiusura del contratto: input e output
3.3
Interazioni tra processi

I gruppi di processi di Project Management sono collegati mediante i risultati che
producono. Loutput di un processo diviene in genere linput di un altro processo
oppure rappresenta un deliverable del progetto. Il gruppo di processi di pianificazione
fornisce al gruppo di processi di esecuzione un piano di Project Management
documentato e una descrizione dellambito del progetto e, spesso, mano a mano che il
progetto avanza, aggiorna il piano di Project Management. Inoltre, i gruppi di processi
sono raramente eventi discreti o occasionali; spesso sono infatti composti da attivit
sovrapposte che si verificano a vari livelli di intensit per lintero corso del progetto.
La figura 3-11 illustra la modalit di interazione dei gruppi di processi e il livello di
sovrapposizione in momenti diversi del progetto. Se il progetto viene suddiviso in
fasi, i gruppi di processi interagiscono sia allinterno di una singola fase di progetto
che su pi fasi di progetto.

67
Figura 3-11. Interazione dei gruppi di processi in un progetto
Tra i gruppi di processi e i processi che li compongono, gli output dei processi
sono correlati tra loro e influiscono sugli altri gruppi di processi. Ad esempio, la
chiusura di una fase di progettazione richiede laccettazione da parte del cliente del
documento di progettazione. In questo caso, il documento di progettazione definisce
la descrizione del prodotto necessaria al gruppo di processi di esecuzione. Se il
progetto suddiviso in fasi, per portare a termine in modo efficace il progetto, i gruppi
di processi vengono solitamente ripetuti allinterno di ciascuna fase per tutti il ciclo di
vita del progetto. Nella figura 3-12 vengono raffigurati i gruppi di processi e le
relative relazioni.
68

Figura 3-12. Triangolo dei gruppi di processi di Project Management
Tuttavia, cos come non tutti i processi sono necessari in tutti i progetti, allo
stesso modo non tutte le interazioni avranno luogo in tutti i progetti o in tutte le fasi di
progetto. Di seguito vengono riportati alcuni esempi:
I progetti che dipendono da risorse uniche (sviluppo di software commerciale,
biofarmaceutica ecc.) possono definire i ruoli e le responsabilit prima della
definizione dellambito, dal momento che il lavoro effettuabile dipende dalle
risorse disponibili.
Alcuni input di processo sono predefiniti come vincoli. Ad esempio, la direzione
pu imporre una data di completamento, anzich lasciare che questultima venga
determinata dal processo di pianificazione. Se viene imposta una data di
completamento, la schedulazione deve essere effettuata andando a ritroso a
partire da tale data con il pericolo di aumentare il rischio e i costi del progetto e
di comprometterne la qualit o, in alcuni casi estremi, addirittura di cambiarne in
modo sostanziale lambito.
3.4
Mappatura dei processi di Project Management

La tabella 3-45 illustra la mappatura dei 44 processi di Project Management articolati
nei cinque gruppi di processi di Project Management rispetto alle nove aree di
conoscenza di Project Management. Ogni processo di Project Management viene
raffigurato nel gruppo di processi in cui si svolge gran parte dellattivit. Ad
esempio, quando in fase di esecuzione si analizza e si aggiorna un processo che in
genere si svolge in fase di pianificazione, il processo resta comunque quello eseguito
nel processo di pianificazione e non uno nuovo.

69
Tabella 3-45. Collegamento dei processi di Project Management ai gruppi di processi di

Project Management e alle aree di conoscenza
70

Parte III
Aree di conoscenza di Project
Management
Parte III
Introduzione
Capitolo 4
Gestione dellintegrazione di progetto
Capitolo 5
Gestione dell'ambito del progetto
Capitolo 6
Gestione dei tempi di progetto
Capitolo 7
Gestione dei costi di progetto
Capitolo 8
Gestione della qualit di progetto
Capitolo 9
Gestione delle risorse umane di progetto
Capitolo 10
Gestione della comunicazione di progetto
Capitolo 11
Gestione dei rischi di progetto
Capitolo 12
Gestione dellapprovvigionamento di
progetto
PARTE III
Introduzione
Diagrammi di flusso dei processi
In ogni capitolo delle aree di conoscenza (capitoli da 4 a 12) viene fornito un
diagramma di flusso dei processi, che rappresenta in modo riepilogativo gli input e gli
output dei processi che percorrono tutti i processi di un'area di conoscenza specifica.
Sebbene i processi siano qui presentati come componenti discreti con interfacce ben
definite, nella pratica essi possono essere iterativi, sovrapporsi o interagire in modi
diversi da quelli descritti.
Figura III-1. Legenda dei diagrammi di flusso dei processi

73
Parte III - Introduzione
I simboli dei diagrammi di flusso dei processi sono descritti nella figura III-1 e
rappresentano tre tipi di informazioni:
1.
Processi di un'area di conoscenza, la loro interazione con altri processi
nell'area di conoscenza e i relativi output ai processi di integrazione descritti
nel capitolo 4.
2.
Processi esterni all'area di conoscenza i cui output vengono utilizzati come
input nei processi dell'area di conoscenza considerata.
3.
Gli asset dei processi organizzativi e i fattori ambientali aziendali sono
mostrati come input per il primo processo.
Il piano di Project Management, i relativi piani e componenti ausiliari esterni
all'area di conoscenza vengono forniti come input del primo processo
rappresentato nel diagramma e vengono considerati disponibili per ogni
processo successivo nella loro versione pi recente e aggiornata.
Gli asset dei processi organizzativi e i fattori ambientali aziendali vengono
mostrati come input per il primo processo per fornire le informazioni, le politiche e le
procedure esterni al progetto, ma che possono incidere sulla pianificazione e
sull'esecuzione dello stesso. Tali asset e fattori, assieme agli output dei processi
esterni utilizzati come input per un processo dell'area di conoscenza vengono
considerati disponibili per ogni processo successivo nella loro versione pi
recente e aggiornata.
Il diagramma di flusso dei processi non dettagliato e quindi non riporta tutte le
interfacce possibili con i processi esterni. Non mostra inoltre i percorsi alternativi del
flusso di processi o i cicli di retroazione tra processi di un'area di conoscenza specifica
o con processi esterni all'area di conoscenza. La natura iterativa della maggior parte
dei progetti complica ulteriormente la permutazione dei flussi dei processi e dei cicli
di retroazione. Ne consegue che per rendere i diagrammi di flusso semplici da seguire,
non sono stati inclusi nel diagramma i percorsi alternativi o iterativi.
74

Figura III-2. Tre principali documenti di progetto e la loro relazione con i rispettivi
componenti

75
Parte III - Introduzione
Principali documenti di progetto

Nella Guida al PMBOK vengono descritti i tre documenti principali, ognuno dei
quali ha un suo scopo specifico.
Project Charter: autorizza formalmente il progetto.
Descrizione dell'ambito del progetto: stabilisce quale lavoro deve essere

eseguito e quali deliverable devono essere prodotti.
Piano di Project Management: stabilisce la modalit di esecuzione del
lavoro.
La figura III-2 rappresenta questi tre documenti e la loro relazione con i rispettivi
componenti.
Il piano di Project Management composto dai piani e dai documenti generati dai
vari processi, noti come piani e componenti ausiliari del Piano di Project
Management.
76

CAPITOLO 4
Gestione dellintegrazione di progetto

L'area di conoscenza della gestione dell'integrazione di progetto comprende i processi
e le attivit necessari per identificare, definire, combinare, unificare e coordinare i vari
processi e le attivit di Project Management definiti all'interno dei gruppi di processi
di Project Management. Nel contesto del Project Management, l'integrazione
caratterizzata anche da unificazione, rafforzamento, articolazione e attivit integrative
di importanza vitale per il completamento del progetto, per soddisfare in modo
efficace i requisiti dei clienti e degli altri stakeholder e per gestire le aspettative. Il
concetto di integrazione, applicato al settore della gestione di un progetto, implica
decidere dove concentrare le risorse e l'impegno in ogni momento, prevedere le
potenziali questioni, affrontare tali questioni prima che diventino critiche e coordinare
il lavoro per il buon esito del progetto. L'impegno di integrazione prevede anche di
effettuare scelte tra obiettivi e alternative contrastanti fra loro. I processi di Project
Management vengono in genere presentanti come componenti discrete con interfacce
ben definite, mentre in realt si sovrappongono e interagiscono in modi che non
possono essere descritti dettagliatamente nella guida PMBOK.
La necessit di integrazione nel Project Management si rende evidente in
situazioni nelle quali i singoli processi interagiscono. Ad esempio, una stima dei costi
necessaria per un piano di contingency prevede l'integrazione dei processi di
pianificazione, descritti dettagliatamente in Processi di gestione dei costi di progetto,
Processi di gestione dei tempi di progetto e Processi di gestione dei rischi di progetto.
Quando successivamente vengono identificati ulteriori rischi legati a varie alternative
di gestione del personale, necessario riesaminare uno o pi di quei processi.
inoltre necessario integrare i deliverable del progetto con le funzioni operative in
corso della Performing Organization o dell'organizzazione del cliente, oppure con la
pianificazione strategica a lungo termine che prende in considerazione i problemi e le
opportunit future.
I professionisti pi esperti del Project Management sanno perfettamente che non
esiste un solo metodo di gestione di un progetto. Per ottenete le prestazioni del
progetto desiderate, essi applicano conoscenze, skill e processi di Project Management
in ordini e gradi diversi di rigidit. Ciononostante, la sensazione che un determinato
processo non sia necessario non implica necessariamente che questo debba essere
trascurato. Il project manager e il gruppo di progetto devono prendere in
considerazione tutti i processi e devono determinare il livello di implementazione di
ogni processo per ciascun progetto specifico.

77
Capitolo 4 Gestione dellintegrazione di progetto
Per una pi approfondita comprensione della natura integrativa dei progetti e del
Project Management, consigliabile tenere conto delle altre attivit svolte nel corso
del completamento di un progetto. Di seguito vengono riportati alcuni esempi delle
attivit eseguite dal gruppo di Project Management:
Analizzare e comprendere l'ambito. Questo comprende i requisiti del progetto e
del prodotto, i criteri, gli assunti, i vincoli e altri elementi influenti legati al
progetto, nonch la modalit con cui ogni fattore viene gestito e affrontato
all'interno del progetto.
Documentare criteri specifici dei requisiti del prodotto.
Capire come acquisire le informazioni identificate e trasformarle in un piano di
Project Management mediante il gruppo di processi di pianificazione descritto
nella Guida PMBOK.
Preparare la WBS (struttura di scomposizione del lavoro).
Effettuare le operazioni necessarie affinch il progetto venga eseguito in
conformit al piano di Project Management, all'insieme programmato di
processi integrati e all'ambito pianificato.
Misurare e monitorare lo stato del progetto, i processi e i prodotti.
Analizzare i rischi del progetto.
Tra i processi inclusi nei gruppi di processi di Project Management, i
collegamenti vengono spesso reiterati. Il gruppo di processi di pianificazione fornisce
al gruppo di processi di esecuzione un piano di Project Management documentato fin
dalle prime fasi del progetto, favorendo in tal modo eventuali aggiornamenti al piano
di Project Management qualora si verificassero modifiche nel corso del progetto.
L'integrazione riguarda innanzitutto la capacit di unire in modo efficiente tutti i
processi inclusi nei gruppi di processi di Project Management necessari al
raggiungimento degli obiettivi del progetto allinterno delle procedure definite
dall'organizzazione. La figura 4-1 fornisce una visione dinsieme dei principali
processi integrativi di Project Management. La figura 4-2 mostra invece un
diagramma di flusso di tali processi, dei relativi input e output e dei processi dell'area
di conoscenza correlati. I processi integrativi di Project Management includono:
4.1 Sviluppare il Project Charter: sviluppo del Project Charter che costituisce
l'autorizzazione formale al progetto o ad una fase di progetto.
4.2 Sviluppare la descrizione preliminare dell'ambito del progetto: sviluppo
della descrizione preliminare dell'ambito del progetto che fornisce una
presentazione dell'ambito di alto livello.
4.3 Sviluppare il piano di Project Management: documentazione delle azioni
necessarie per definire, preparare, integrare e coordinare tutti i piani ausiliari
inclusi in un piano di Project Management.
4.4 Dirigere e gestire l'esecuzione del progetto: esecuzione del lavoro definito nel
piano di Project Management che consente di raggiungere i requisiti del progetto
stabiliti dalla descrizione dell'ambito del progetto.
4.5 Monitorare e controllare il lavoro del progetto: monitoraggio e controllo dei
processi utilizzati per avviare, pianificare, eseguire e chiudere un progetto in
modo da raggiungere gli obiettivi in termini di prestazioni definiti nel piano di
Project Management.
78

4.6 Controllo integrato delle modifiche: analisi di tutte le richieste di modifica,

approvazione delle modifiche e controllo delle modifiche ai deliverable e agli
asset del processo organizzativo.
4.7 Chiudere il progetto: completamento di tutte le attivit relative all'insieme dei
gruppi di processi di Project Management che consente di chiudere formalmente
il progetto o una fase di progetto.

79
80

Figura 4-1. Visione dinsieme della gestione dellintegrazione di progetto
Figura 4-2. Diagramma di flusso dei processi di gestione dell'integrazione di progetto.

81
4.1
Sviluppare il Project Charter

Il Project Charter il documento che autorizza formalmente il progetto. Esso fornisce
al project manager lautorit necessaria per impiegare le risorse dellorganizzazione ai
fini delle attivit di progetto. Quanto prima possibile nellavvio del progetto, viene
identificato e nominato un project manager. necessario assegnare un project
manager sempre prima dell'inizio della pianificazione, e preferibilmente in fase di
sviluppo del Project Charter.
Il Project Charter viene pubblicato da un iniziatore o sponsor del progetto esterni
all'organizzazione del progetto, e che si trovi ad un livello idoneo per il finanziamento
del progetto. Il Project Charter e l'autorizzazione al progetto vengono in genere
eseguiti esternamente all'organizzazione del progetto da parte di un'azienda,
un'agenzia governativa, una societ, un'organizzazione di programmi o di portfolio, e
come conseguenza di uno o pi dei seguenti fattori:
Richiesta di mercato (ad esempio, una casa di automobili autorizza un progetto
per la costruzione di auto a minor consumo di carburante in risposta alla scarsit
di benzina).
Necessit commerciali (ad esempio, una societ di formazione autorizza il
progetto di creazione di un nuovo corso di formazione per incrementare il
proprio reddito).
Richiesta di un cliente (ad esempio, una societ elettrica autorizza un progetto
per la costruzione di una nuova centrale di distribuzione che possa servire un
nuovo insediamento industriale).
Miglioramento tecnologico (ad esempio, un'azienda del settore elettronico
autorizza un nuovo progetto per lo sviluppo di un laptop pi veloce, pi
economico e di dimensioni ridotte a seguito di ulteriori progressi nella
tecnologia delle memorie e altri componenti elettronici dei computer).
Requisito legale (ad esempio, una fabbrica di vernici autorizza un progetto per
fissare delle direttive sul trattamento di sostanze tossiche).
Esigenza sociale (ad esempio, unorganizzazione non governativa di un paese in
via di sviluppo autorizza un progetto per realizzare un sistema fognario, di bagni
pubblici e di acqua potabile e per diffondere leducazione sanitaria presso le
comunit che registrano un alto tasso di casi di colera).
Gli stimoli descritti possono essere chiamati anche problemi, opportunit o
necessit commerciali. Il tema centrale di tutti questi stimoli riguarda la necessit che
la direzione prenda una decisione su come rispondere e quali progetti autorizzare ed
avviare formalmente. I metodi di selezione dei progetti comportano la misurazione del
valore o del grado di interesse per il titolare o lo sponsor del progetto, ma possono
anche includere altri criteri relativi al processo decisionale aziendale. La selezione dei
progetti riguarda anche la scelta tra modi diversi di eseguire un progetto.
Lavvio formale del progetto collega le attivit del progetto al lavoro in corso
all'interno dell'organizzazione. In alcune organizzazioni, un progetto non dispone di
un Project Charter e di un inizio formali se non dopo il completamento di unanalisi
dei requisiti, di uno studio di fattibilit, di un piano preliminare o di altro tipo di
analisi avviata separatamente. Lo sviluppo del Project Charter principalmente legato
alla documentazione delle necessit aziendali, alla giustificazione del progetto, alla
comprensione aggiornata dei requisiti del cliente e del nuovo prodotto, servizio o
risultato che dovrebbe soddisfare tali requisiti. Il Project Charter, sia direttamente sia
mediante riferimento ad altri documenti, deve fornire le informazioni riportate di
seguito:
82

Requisiti che soddisfano le esigenze, le necessit e le aspettative del cliente,

dello sponsor e di altri stakeholder.
Necessit commerciali, descrizione del progetto di alto livello o requisiti del
prodotto per cui il progetto stato intrapreso.
Obiettivo o giustificazione del progetto.
Project manager assegnato e livello di autorit.
Schedulazione delle milestone di riepilogo.
Influenza degli stakeholder.
Organizzazioni funzionali e relativa partecipazione.
Assunti organizzativi, ambientali ed esterni.
Vincoli organizzativi, ambientali ed esterni.
Business Case che giustifica il progetto, comprendente il rendimento
dell'investimento.
Budget riepilogativo.
Nel corso delle fasi successive di un progetto multi-fase, il processo Sviluppare
il Project Charter convalida le decisioni prese nel corso della fase originale di
autorizzazione del progetto. Se necessario, autorizza anche il passaggio alla fase di
progetto successiva ed aggiorna il Project Charter.
Figura 4-3. Sviluppare il Project Charter: Input, Strumenti e tecniche e Output
4.1.1
Sviluppare il Project Charter: Input
.1
Contratto (se pertinente)

Se il progetto viene svolto per un cliente esterno, un contratto da parte
dell'organizzazione acquirente del cliente costituisce un input.
.2
Capitolato del progetto

Il capitolato (SOW) una descrizione dei prodotti o dei servizi che il progetto deve
fornire. Per i progetti interni, sono l'iniziatore o lo sponsor del progetto a fornire il
capitolato redatto sulla base delle necessit commerciali, dei requisiti del prodotto o
del servizio. In caso di progetti esterni, possibile che il cliente fornisca il capitolato
all'interno della documentazione di gara, ad esempio la richiesta d'offerta o la richiesta
di informazioni, o all'interno del contatto. Il capitolato riporta i fattori descritti di
seguito:

83
.3
Necessit commerciale: la necessit commerciale di un'organizzazione si pu

fondare su esigenze di formazione, richieste di mercato, sviluppi tecnologici,
requisiti legali o standard governativi.
Descrizione delle specifiche di prodotto: documenta i requisiti di prodotto e le
caratteristiche del prodotto o del servizio per la cui creazione stato intrapreso il
progetto. Poich le caratteristiche del prodotto vengono elaborate
progressivamente, i requisiti di prodotto sono in genere scarsamente dettagliati
all'inizio del progetto e lo diventano sempre di pi nel corso dei processi
successivi. Tali requisiti dovrebbero documentare anche la relazione tra i
prodotti o i servizi in fase di creazione, nonch la necessit commerciale o gli
altri stimoli che generano tale necessit. Sebbene il documento che rappresenta i
requisiti del prodotto possa variare nella forma e nella sostanza, dovrebbe essere
comunque abbastanza dettagliato per poter supportare la successiva
pianificazione del progetto.
Piano strategico: tutti i progetti devono supportare gli obiettivi strategici
dell'organizzazione. Il piano strategico della Performing Organization deve
essere considerato un fattore importante nelle decisioni di selezione dei progetti.
Fattori ambientali aziendali

Nella fase di sviluppo del Project Charter, necessario prendere in considerazione
tutti i fattori ambientali aziendali e i sistemi dell'organizzazione che circondano il
progetto e che possono influire sulla sua buona riuscita. Un elenco non esaustivo di
questi fattori, include i seguenti:
Cultura e struttura dell'organizzazione o dell'azienda.
Standard governativi o di settore (ad es. regolamenti di un ente normativo,
standard del prodotto, standard di qualit e standard di fabbricazione).
Infrastrutture (ad es. impianti e attrezzature gi esistenti).
Risorse umane gi disponibili (ad es. skill, discipline e conoscenze quali quelle
dei reparti progettazione, sviluppo, legale, contratti e acquisti).
Amministrazione del personale (ad es. direttive per l'assunzione e il
licenziamento, analisi delle prestazioni dei dipendenti e dati sulla formazione).
Sistema di autorizzazione del lavoro dell'azienda.
Condizioni del mercato.
Limiti di tolleranza al rischio da parte degli stakeholder.
Database commerciali (ad es. dati standard di stima dei costi, informazioni sullo
studio dei rischi del settore e database dei rischi).
Sistemi informativi di Project Management (ad es. una suite di strumenti
automatizzati, come uno strumento software di schedulazione, un sistema di
gestione della configurazione, un sistema di raccolta e distribuzione delle
informazioni oppure interfacce Web ad altri sistemi on-line automatizzati).
84

.4
Asset dei processi organizzativi

Nello sviluppo del Project Charter e della successiva documentazione del progetto, gli
asset utilizzati per favorire il successo del progetto possono essere ricavati dagli asset
dei processi organizzativi. Tutte le organizzazioni coinvolte nel progetto possono
disporre di criteri, procedure, piani o direttive sia formali che informali dei cui effetti
necessario tenere conto. Gli asset dei processi organizzativi rappresentano anche le
nozioni e le conoscenze apprese dall'organizzazione in occasione di progetti
precedenti; ad esempio, le schedulazioni completate, i dati sui rischi e i dati
sull'Earned Value. possibile organizzare gli asset dei processi organizzativi in modi
diversi a seconda del tipo di industria, organizzazione e area applicativa. Gli asset dei
processi organizzativi sono ad esempio raggruppabili nelle due categorie illustrate di
seguito:
Processi e procedure dell'organizzazione per la conduzione del lavoro:
Processi standard dell'organizzazione, come standard, direttive (ad es.
direttive sanitarie e di sicurezza e direttive di Project Management), cicli di
vita standard di prodotti e progetti e direttive e procedure di qualit (ad es.
revisioni dei processi, obiettivi di miglioramento, liste di controllo e
definizioni standard di processi da utilizzare nell'organizzazione).
Direttive standard, istruzioni di lavoro, criteri di valutazione delle proposte
e criteri di misurazione delle prestazioni.
Schemi di documento (ad es. schemi dei rischi, schemi della WBS (struttura
di scomposizione del lavoro) e schemi del reticolo di schedulazione del
progetto).
Direttive e criteri per la personalizzazione dell'insieme dei processi standard
dell'organizzazione che consentono di soddisfare le esigenze specifiche del
progetto.
Requisiti di comunicazione dell'organizzazione (ad es. la specifica
tecnologia di comunicazione a disposizione, i mezzi di comunicazione
consentiti, la conservazione dei dati e i requisiti di protezione).
Direttive o requisiti di chiusura del progetto (ad es. verifiche finali del
progetto, valutazioni del progetto, convalide del prodotto e criteri di
accettazione).
Procedure di controllo finanziario (ad es. registrazione del tempo dedicato,
revisioni delle spese e dei pagamenti necessari, codici di spesa e clausole di
contratto standard).
Procedure di gestione delle questioni e dei difetti che definiscono i controlli
di questioni e difetti, la loro identificazione e risoluzione e il sistema di
tracking delle attivit correttive.
Procedure di controllo delle modifiche, compresi i passaggi mediante i
quali verranno modificati gli standard aziendali ufficiali, i criteri, i piani e le
procedure (o qualsiasi documento del progetto), nonch la modalit di
approvazione e convalida delle modifiche.
Procedure di controllo dei rischi, comprese le categorie di rischio, la
definizione di probabilit e impatto, e la matrice di probabilit e impatto.
Procedure di approvazione ed emissione delle autorizzazioni del lavoro.

85
4.1.2
Knowledge base aziendale sulla struttura di archiviazione e di recupero dei dati:

Database delle misurazioni dei processi utilizzato per raccogliere e rendere
disponibili i dati delle misurazioni in merito a processi e prodotti.
File del progetto (ad es. ambito, costo, schedulazione, baseline della qualit,
baseline di misurazione delle prestazioni, calendari di progetto, reticoli di
schedulazione del progetto, registri dei rischi, azioni di risposta pianificate e
impatto dei rischi definiti).
Dati storici e knowledge base delle lesson learned (ad es. record e
documenti del progetto, tutte le informazioni e la documentazione sulla
chiusura del progetto, informazioni sui risultati delle decisioni prese per la
selezione e sulle prestazioni dei progetti precedenti e informazioni
sull'impegno dimostrato nella gestione dei rischi).
Database di gestione delle questioni e dei difetti contenente lo stato di tali
questioni e difetti, informazioni sul controllo, risoluzione di questioni e
difetti e risultati delle attivit correttive.
Knowledge base di gestione delle configurazioni contenente le versioni e le
baseline di tutti gli standard aziendali ufficiali, delle direttive, delle
procedure e dei documenti del progetto.
Database finanziario contenente informazioni su ore di lavoro, costi
sostenuti, budget ed eccedenze nei costi del progetto.
Sviluppare il Project Charter: Strumenti e tecniche
.1
Metodi di selezione dei progetti

I metodi di selezione dei progetti consentono di determinare quali progetti verranno
selezionati dall'organizzazione. Tali metodi rientrano in genere in una delle due
categorie illustrate di seguito4:
Metodi di misura dei benefici: approcci comparativi, modelli di valutazione
quantitativa, contributo dei benefici o modelli economici.
Modelli matematici che utilizzano algoritmi di programmazione di tipo lineare,
non lineare, dinamico, intero o multiobiettivo.
.2
Metodologia di Project Management

Una metodologia di Project Management definisce un insieme di gruppi di processi di
Project Management, con relativi processi e funzioni di controllo raggruppati e
combinati in un' insieme funzionante. La metodologia di Project Management pu
essere o meno il risultato dell'elaborazione di uno standard di Project Management.
Inoltre pu essere sia un processo maturo formale sia una tecnica informale che
consente al gruppo di Project Management di sviluppare in modo efficace un Project
Charter.
86

.3
Sistema informativo di Project Management

Il sistema informativo di Project Management (PMIS) un insieme standardizzato di
strumenti automatizzati disponibili all'interno dell'organizzazione e integrati in un
unico sistema. Il PMIS consente al gruppo di Project Management di generare un
Project Charter, di facilitare il feedback mentre il documento viene migliorato, di
controllare le modifiche al Project Charter e di pubblicare il documento approvato.
.4
Parere di esperti
Si ricorre spesso al parere di esperti per valutare gli input necessari allo sviluppo del
Project Charter. Durante il processo, il parere e le competenze degli esperti vengono
applicati a qualsiasi dettaglio tecnico e gestionale. Tali competenze possono essere
fornite da qualsiasi persona o gruppo che possegga conoscenze o una formazione
specialistica e pu essere ottenuta, ad esempio, da:
altre unit all'interno dell'organizzazione;
consulenti;
stakeholder, compresi clienti e sponsor;
associazioni tecniche o professionali;
associazioni industriali.
4.1.3
.1
4.2
Sviluppare il Project Charter: Output

Project Charter
Per la descrizione, consultare l'introduzione al paragrafo 4.1.
Sviluppare la descrizione preliminare dell'ambito del

progetto
La descrizione dell'ambito del progetto rappresenta la definizione del progetto, ovvero
cosa deve essere portato a termine. Il processo Sviluppare la descrizione preliminare
dell'ambito del progetto riguarda e documenta le caratteristiche e i limiti del progetto e
dei prodotti e servizi ad esso associati, come anche i metodi di accettazione e di
controllo dell'ambito. La descrizione dell'ambito del progetto comprende gli elementi
riportati di seguito:
Obiettivi del progetto e del prodotto.
Requisiti e caratteristiche del prodotto o del servizio.
Criteri di accettazione del prodotto.
Limiti di progetto.
Requisiti e deliverable del progetto.
Vincoli del progetto.
Assunti del progetto.
Organizzazione iniziale del progetto.
Rischi definiti nella fasi iniziali.
Milestone di schedulazione.
WBS iniziale.
Ordine di grandezza della stima dei costi.
Requisiti di gestione della configurazione del progetto.
Requisiti di approvazione.

87
La descrizione preliminare dell'ambito del progetto viene sviluppata dalle

informazioni fornite dall'iniziatore o dallo sponsor. Il gruppo di Project Management
nel processo Definizione dell'ambito perfeziona ulteriormente la descrizione
preliminare dell'ambito del progetto realizzando la descrizione dell'ambito del
progetto. Il contenuto della descrizione dell'ambito del progetto varia in base all'area
applicativa e alla complessit del progetto e comprende alcuni o tutti i componenti
identificati sopra. In progetti multifase il processo Sviluppare la descrizione
preliminare dell'ambito del progetto applicato alle fasi successive convalida e
perfeziona, qualora necessario, l'ambito del progetto definito per la fase in questione.
Figura 4-4. Sviluppare la descrizione preliminare dell'ambito del progetto Input, Strumenti
e tecniche e Output
4.2.1
Sviluppare la descrizione preliminare dell'ambito del progetto:

Input
.1
Project Charter
Per la descrizione, consultare il paragrafo 4.1.
.2
Capitolato del progetto

Per la descrizione, consultare il paragrafo 4.1.1.2.
.3

.4

4.2.2 Sviluppare la descrizione preliminare dell'ambito del progetto:

Strumenti e tecniche
.1

La metodologia di Project Management definisce un processo che supporta il gruppo
di Project Management nello sviluppo e nel controllo delle modifiche da apportare
alla descrizione preliminare dell'ambito del progetto.
88

.2

Il sistema informativo di Project Management, un sistema automatizzato, consente al
gruppo di Project Management di generare una descrizione preliminare dell'ambito
del progetto, di facilitare il feedback mentre il documento viene migliorato, di
controllare le modifiche alla descrizione dell'ambito del progetto e di pubblicare il
documento approvato.
.3
Parere di esperti
Si ricorre al parere di esperti per qualsiasi dettaglio tecnico e gestionale da includere
nella descrizione preliminare dell'ambito del progetto.
4.2.3 Sviluppare la descrizione preliminare dell'ambito del progetto:

Output
.1
4.3
Descrizione preliminare dell'ambito del progetto

Per la descrizione, consultare l'introduzione al paragrafo 4.2.
Sviluppare il piano di Project Management

Il processo Sviluppare il piano di Project Management comprende le azioni necessarie
per definire, integrare e coordinare tutti i piani ausiliari in un piano di Project
Management. Il contenuto del piano di Project Management varia in base all'area
applicativa e alla complessit del progetto. Questo processo ha come risultato un
piano di Project Management aggiornato e rivisto mediante il processo Controllo
integrato delle modifiche. Il piano di Project Management definisce come eseguire,
monitorare, controllare e quindi chiudere il progetto; documenta inoltre la raccolta di
output dei processi di pianificazione appartenenti al gruppo di processi di
pianificazione e comprende:
I processi di Project Management selezionati dal gruppo di Project Management.
Il livello di implementazione di ciascun processo selezionato.
Le descrizioni degli strumenti e delle tecniche da utilizzare per l'esecuzione di
tali processi.
Come i processi selezionati verranno utilizzati per gestire il progetto specifico,
comprese le relazioni di dipendenza e le interazioni tra quei processi, e i
principali input e output.
Come il lavoro verr eseguito per il raggiungimento degli obiettivi del progetto.
Le modalit di monitoraggio e controllo delle modifiche.
Le modalit di esecuzione della gestione della configurazione.
Le modalit di manutenzione e utilizzo per la salvaguardia dell'integrit delle
baseline di misurazione delle prestazioni.
Le necessit e modalit di comunicazione tra gli stakeholder.
Il ciclo di vita del progetto selezionato e, nel caso di progetti multi-fase, le fasi
associate al progetto.
Le analisi effettuate dalla direzione su contenuto, estensione e scadenze per
facilitare la risoluzione delle questioni aperte e delle decisioni in sospeso.

89
Il piano di Project Management pu essere sia in forma riepilogativa o

dettagliata e pu essere composto da uno o pi piani ausiliari o da altri componenti.
Per ciascun piano o componente ausiliario vengono forniti i dettagli nella misura resa
necessaria dal progetto specifico. Un elenco non esaustivo di questi piani ausiliari
comprende i seguenti:
Piano di gestione dell'ambito del progetto (paragrafo 5.1.3.1);
Piano di gestione della schedulazione (vedere materiale introduttivo del
capitolo 6);
Piano di gestione dei costi (vedere materiale introduttivo del capitolo 7);
Piano di gestione della qualit (paragrafo 8.1.3.1);
Piano di miglioramento dei processi (paragrafo 8.1.3.4);
Piano di gestione dellingaggio del personale (paragrafo 9.1.3.3);
Piano di gestione della comunicazione (paragrafo 10.1.3.1);
Piano di gestione dei rischi (paragrafo 11.1.3.1);
Piano di gestione dellapprovvigionamento (paragrafo 12.1.3.1).
Un elenco non esaustivo di possibili componenti ausiliari, include i seguenti:
Elenco delle milestone (paragrafo 6.1.3.3);
Calendario delle risorse (paragrafo 6.3.3.4);
Baseline della schedulazione (paragrafo 6.5.3.3);
Baseline dei costi (paragrafo 7.2.3.1);
Baseline della qualit (paragrafo 8.1.3.5);
Registro dei rischi (paragrafo 11.2.3.1).
Figura 4-5. Sviluppare il piano di Project Management: Input, Strumenti e tecniche e Output
4.3.1
Sviluppare il piano di Project Management: Input
.1

.2
Processi di Project Management

Per la descrizione, consultare i capitoli da 5 a 12.
90

.3

.4

4.3.2
Sviluppare il piano di Project Management: Strumenti e tecniche
.1

di Project Management nello sviluppo e nel controllo delle modifiche da apportare al
piano di Project Management.
.2

Il sistema informativo di Project Management, un sistema automatizzato, consente al
gruppo di Project Management di generare il piano di Project Management, di
facilitare i feedback durante lo sviluppo del documento, di controllare le modifiche al
piano di Project Management e di pubblicare il documento approvato.
Sistema di gestione della configurazione
Il sistema di gestione della configurazione un sottosistema del sistema
informativo di Project Management complessivo. Il sistema include il processo
di presentazione delle modifiche proposte, il sistema di tracking delle revisioni e
di approvazione di tali modifiche, la definizione dei livelli di approvazione
necessari allautorizzazione delle modifiche e la fornitura di un metodo per la
convalida delle modifiche approvate. Nella maggior parte delle aree applicative,
il sistema di gestione della configurazione comprende il sistema di controllo
delle modifiche. Il sistema di gestione della configurazione rappresenta inoltre la
raccolta di procedure formali documentate che consentono di applicare la
direzione e il controllo tecnici e amministrativi per:
identificare e documentare le caratteristiche fisiche e funzionali di un
prodotto o componente;
controllare qualsiasi modifica a tali caratteristiche;
registrare e segnalare ogni modifica e il relativo stato di implementazione;
coadiuvare la revisione di prodotti o componenti per verificarne la
conformit ai requisiti.
Sistema di controllo delle modifiche
Il sistema di controllo delle modifiche una raccolta di procedure formali
documentate che definiscono come controllare, modificare e approvare i
deliverable e la documentazione del progetto. Il sistema di controllo delle
modifiche un sottosistema del sistema di gestione della configurazione. Ad
esempio, per i sistemi informatici, un sistema di controllo delle modifiche pu
comprendere le specifiche di prodotto (script, codice sorgente, istruzioni DDL
ecc.) per ciascun componente software.
.3
Parere di esperti
Si ricorre al parere di esperti per sviluppare i dettagli tecnici e gestionali da inserire
nel piano di Project Management.

91
4.3.3 Sviluppare il piano di Project Management: Output

.1
4.4
Piano di Project Management

Dirigere e gestire l'esecuzione del progetto

Il processo Dirigere e gestire l'esecuzione del progetto richiede al Project manager e al
gruppo di progetto di eseguire una serie di azioni per la conduzione del piano di
Project Management al fine di portare a termine il lavoro definito nella descrizione
dell'ambito del progetto. Di seguito vengono riportate alcune di queste azioni:
Eseguire attivit per il conseguimento degli obiettivi del progetto.
Dedicare il proprio impegno e investire dei fondi per il raggiungimento degli
obiettivi del progetto.
Acquisire, formare e gestire i membri del gruppo di progetto assegnati al
progetto.
Ottenere preventivi, risposte ad un bando di gara, offerte d'appalto o proposte,
secondo necessit.
Selezionare i fornitori effettuando una scelta tra i potenziali fornitori.
Ottenere, gestire e utilizzare le risorse compresi i materiali, gli strumenti, le
attrezzature e le strutture.
Implementare i metodi e gli standard pianificati.
Creare, controllare, verificare e convalidare i deliverable del progetto.
Gestire i rischi e implementare le attivit di risposta ai rischi.
Gestire i fornitori.
Adattare le modifiche approvate inserendole nell'ambito, nei piani e nei fattori
ambientali del progetto.
Stabilire e gestire i canali di comunicazione del progetto, sia esterni che interni
al gruppo di progetto.
Raccogliere i dati del progetto e segnalare costi, schedulazione, avanzamento
tecnico e della qualit e informazioni sullo stato per semplificare le operazioni
di previsione.
Raccogliere e documentare le lesson learned e implementare le attivit
approvate per il miglioramento del processo.
Il Project manager, unitamente al gruppo di Project Management, guida le
prestazioni delle attivit di progetto pianificate e gestisce le varie interfacce tecniche e
organizzative presenti all'interno del progetto. Sul processo Dirigere e gestire
l'esecuzione del progetto esercita una particolare influenza l'area applicativa del
progetto. I deliverable vengono prodotti come output derivanti da processi eseguiti per
portare a termine il lavoro di progetto pianificato e schedulato nel piano di Project
Management. Le informazioni sullo stato di avanzamento del lavoro in merito allo
stato di completamento dei deliverable e al lavoro portato a termine vengono raccolte
durante l'esecuzione del progetto e vengono inserite come input nel processo
Reporting delle prestazioni. Sebbene i prodotti, i servizi o i risultati del progetto siano
spesso in forma di deliverable tangibili come edifici, strade ecc., possibile che
vengano forniti anche deliverable intangibili, ad esempio formazione.
92

Dirigere e gestire l'esecuzione del progetto richiede anche l'implementazione di:

azioni correttive approvate che consentono di rendere le prestazioni di progetto
previste conformi al piano di Project Management;
azioni preventive approvate per ridurre la probabilit di potenziali conseguenze
negative;
richieste approvate di correzione dei difetti relative ai prodotti rilevati dal
processo di qualit.
Figura 4-6. Dirigere e gestire l'esecuzione del progetto: Input, Strumenti e tecniche e
Output
4.4.1
Dirigere e gestire l'esecuzione del progetto: Input
.1

.2
Azioni correttive approvate

Le azioni correttive approvate sono direttive documentate e autorizzate che
consentono di conformare le prestazioni previste del progetto al piano di Project
Management.
.3
Azioni preventive approvate

Le azioni preventive approvate sono direttive documentate e autorizzate che
consentono di ridurre la probabilit di conseguenze negative associate ai rischi del
progetto.
.4
Richieste di modifica approvate

Le richieste di modifica approvate sono modifiche documentate e autorizzate che
estendono o riducono l'ambito del progetto. Le richieste di modifica approvate
possono anche modificare i criteri, i piani di Project Management, le procedure, i costi
o i budget oppure rivedere le schedulazioni. Le richieste di modifica approvate
vengono schedulate per la successiva implementazione da parte del gruppo di
progetto.
.5
Correzione dei difetti approvata

La correzione dei difetti approvata una richiesta documentata e approvata di
correzione del prodotto a causa di un difetto rilevato nel corso di un'ispezione della
qualit o del processo di verifica.

93
.6
Correzione dei difetti convalidata

Notifica che specifica che gli elementi riparati e riverificati sono stati accettati o
rifiutati.
.7
Procedura di chiusura amministrativa

La procedura di chiusura amministrativa documenta tutte le attivit, le interazioni e i
relativi ruoli e responsabilit necessari all'esecuzione della procedura di chiusura
amministrativa del progetto.
4.4.2
Dirigere e gestire l'esecuzione del progetto: Strumenti e tecniche
.1

La metodologia di Project Management definisce un processo che coadiuva il gruppo
di progetto nell'esecuzione del piano di Project Management.
.2

Il sistema informativo di Project Management un sistema automatizzato utilizzato
dal gruppo di Project Management come supporto nell'esecuzione delle attivit
pianificate previste dal piano di Project Management.
4.4.3
Dirigere e gestire l'esecuzione del progetto: Output
.1
Deliverable
Un deliverable un prodotto, un risultato o la capacit di prestare un servizio, la cui
natura unica e verificabile, che viene identificato nella documentazione di
pianificazione di Project Management e deve essere prodotto e fornito affinch sia
possibile completare il progetto.
.2
Modifiche richieste
In fase di esecuzione del lavoro di progetto vengono spesso identificate le modifiche
richieste per l'espansione o la riduzione dell'ambito del progetto, per la modifica dei
criteri o delle procedure, per la modifica dei costi o del budget del progetto o per la
revisione della schedulazione di progetto. Le richieste di modifica possono essere
dirette o indirette, possono essere avviate a livello esterno o interno e possono
caratterizzarsi come facoltative o obbligatorie dal punto di vista legale o contrattuale.
.3
Richieste di modifica implementate

Richieste di modifica approvate che sono state implementate da parte del gruppo di
Project Management nel corso dell'esecuzione del progetto.
.4
Azioni correttive implementate

Azioni correttive approvate che sono state implementate dal gruppo di Project
Management per adeguare le future prestazioni di progetto previste al piano di Project
Management.
.5
Azioni preventive implementate

Azioni preventive approvate che sono state implementate dal gruppo di Project
Management per la riduzione delle conseguenze dei rischi del progetto.
94

4.5
.6
Correzione dei difetti implementata

In fase di esecuzione del progetto, il gruppo di Project Management ha implementato
le correzioni approvate dei difetti rilevati nel prodotto.
.7
Informazioni sullo stato di avanzamento del lavoro

Le informazioni sullo stato delle attivit di progetto che sono in fase di esecuzione per
portare a termine il lavoro di progetto vengono raccolte con cadenza regolare nel
corso delle svolgimento del piano di Project Management. Un elenco non esaustivo di
questo tipo di informazioni, include:
Informazioni sullavanzamento della schedulazione che mostra le informazioni
sullo stato.
Deliverable completati e non completati.
Attivit schedulate avviate e quelle gi completate.
Livello di conformit agli standard di qualit.
Costi autorizzati e sostenuti.
Stima a finire per le attivit schedulate gi avviate.
Percentuale di completamento fisico delle attivit schedulate in corso.
Lesson learned documentate e inserite nella knowledge base delle lesson
learned.
Dettagli sull'utilizzo delle risorse.
Monitorare e controllare il lavoro del progetto

Il processo Monitorare e controllare il lavoro del progetto consente di monitorare i
processi del progetto associati allavvio, pianificazione, esecuzione e chiusura. Per
controllare le prestazioni del progetto, vengono eseguite delle azioni correttive o
preventive. Il monitoraggio un elemento costitutivo del Project Management
eseguito per tutto il corso del progetto e consente di raccogliere, misurare e diffondere
le informazioni sulle prestazioni e di valutare le misurazioni e le tendenze per favorire
eventuali miglioramenti al processo. Il continuo monitoraggio fornisce al gruppo di
Project Management una conoscenza approfondita delle condizioni del progetto e
identifica le eventuali aree che richiedono un'attenzione particolare. Il processo
Monitorare e controllare il lavoro del progetto riguarda i fattori riportati di seguito.
Confronto tra le prestazioni effettive del progetto e il piano di Project
Management.
Valutazione delle prestazioni per determinare se siano opportune delle azioni
correttive o preventive e quindi suggerimento delle azioni necessarie.
Analisi, rilevamento e monitoraggio dei rischi del progetto per assicurare che i
rischi vengano identificati, che il loro stato venga segnalato e che siano in
esecuzione dei piani di risposta appropriati.
Manutenzione di un bacino di informazioni accurate e tempestive sui prodotti
del progetto e sulla relativa documentazione fino al completamento del progetto.
Fornitura di informazioni necessarie per stilare i report sullo stato, per la
misurazione dell'avanzamento e per le previsioni.
Fornitura di previsioni per aggiornare le attuali informazioni su costi e
schedulazione.
Monitoraggio dell'implementazione delle modifiche approvate nel momento e
nella modalit in cui si verificano.

95
Figura 4-7. Monitorare e controllare il lavoro del progetto: Input, Strumenti e tecniche e
Output
4.5.1
Monitorare e controllare il lavoro del progetto: Input
.1

.2

.3
Richieste di modifica rifiutate

Le richieste di modifica rifiutate comprendono le richieste di modifica, la relativa
documentazione di supporto e ladeguamento dello stato di revisione della modifica
che mostra la disposizione delle richieste di modifica rifiutate.
4.5.2
Monitorare e controllare il lavoro del progetto: Strumenti e

tecniche
.1

La metodologia di Project Management definisce un processo che coadiuva il gruppo
di Project Management nel monitoraggio e nel controllo del lavoro di progetto in fase
di esecuzione in conformit al piano di Project Management.
.2

Il Sistema informativo di Project Management (PMIS) un sistema automatizzato che
consente al gruppo di Project Management di monitorare e controllare l'esecuzione
delle attivit pianificate e schedulate nel piano di Project Management. Il PMIS
consente inoltre di creare delle nuove previsioni in base alle necessit.
.3
Tecnica dell'Earned Value

La tecnica dell'Earned Value misura le prestazioni del progetto nel corso del suo
avanzamento dalla fase di avvio del progetto fino alla chiusura. Il metodo dell'Earned
Value un ulteriore mezzo che consente di prevedere le prestazioni future in base alle
prestazioni passate.
Parere di esperti
Il parere di esperti utilizzato dal gruppo di Project Management di monitorare e
controllare il lavoro del progetto.
96

4.5.3
4.6
Monitorare e controllare il lavoro del progetto: Output
.1
Azioni correttive consigliate

Le azioni correttive sono suggerimenti documentate utili a conformare le future
prestazioni previste per il progetto al piano di Project Management.
.2
Azioni preventive consigliate

Le azioni preventive sono suggerimenti documentati che consentono di ridurre la
probabilit di conseguenze negative associate ai rischi del progetto.
.3
Previsioni
Le previsioni includono le stime o le previsioni delle condizioni e degli eventi che
potrebbero verificarsi nel futuro del progetto, basate sulle informazioni e sulle
conoscenze disponibili al momento della previsione. Le previsioni vengono
aggiornate e quindi ripubblicate in base alle informazioni sullo stato di avanzamento
del lavoro fornite durante l'esecuzione del progetto. Tali informazioni riguardano le
prestazioni passate del progetto che possono influire in futuro sullo stesso; ad
esempio, la stima al completamento e la stima a finire.
.4
Correzione dei difetti consigliata

Alcuni difetti, riscontrati nel corso dell'ispezione di qualit e del processo di verifica,
vengono proposti per essere corretti.
.5
Modifiche richieste
Controllo integrato delle modifiche

Il processo Controllo integrato delle modifiche viene eseguito dall'inizio del progetto
fino al suo completamento. Poich raramente i progetti vengono eseguiti esattamente
in accordo con il piano di Project Management, il controllo delle modifiche si rende
necessario. Il piano di Project Management, la descrizione dell'ambito del progetto e
altri deliverable devono essere aggiornati mediante la gestione attenta e costante delle
modifiche, che pu comportare sia il rifiuto che l'approvazione delle stesse; in caso di
approvazione, le modifiche vengono inserite in una revisione della baseline. Il
processo Controllo integrato delle modifiche comprende le seguenti attivit di
gestione delle modifiche con vari livelli di dettaglio, in base al completamento
dell'esecuzione del progetto:
Identificare se una modifica deve essere implementata o gi stata apportata.
Influire sui fattori che potrebbero aggirare il controllo integrato delle modifiche
in modo da implementare soltanto le modifiche approvate.
Revisione e approvazione delle modifiche richieste.
Gestione delle modifiche approvate nel momento e nella forma in cui si
verificano mediante la regolazione del flusso delle modifiche richieste.
Conservazione dell'integrit delle baseline mediante la pubblicazione delle sole
modifiche approvate per essere incorporate nei prodotti o nei servizi del progetto
e conservazione della relativa configurazione e della documentazione di
pianificazione.
Revisione e approvazione di tutte le azioni correttive e preventive consigliate.

97
Controllo e aggiornamento di ambito, costo, budget, schedulazione e requisiti di

qualit in base alle modifiche approvate, mediante il coordinamento delle
modifiche allinterno di tutto il progetto. Ad esempio, una modifica proposta
alla schedulazione incider spesso su costi, rischi, qualit e risorse umane.
Documentazione dell'impatto complessivo delle modifiche richieste.
Convalida della correzione dei difetti.
Controllo della qualit del progetto rispetto agli standard sulla base dei report di
qualit.
Le modifiche proposte possono richiedere il rinnovo o la revisione delle stime
dei costi, sequenze di attivit schedulate, date di schedulazione, requisiti delle risorse
e analisi delle alternative di risposta ai rischi. Tali modifiche possono richiedere degli
adeguamenti al piano di Project Management, alla descrizione dell'ambito del progetto
o ad altri deliverable del progetto. Il sistema di gestione della configurazione con il
controllo delle modifiche fornisce un processo standardizzato, efficace ed efficiente
per la gestione centralizzata delle modifiche all'interno di un progetto. La gestione
della configurazione con il controllo delle modifiche comprende l'identificazione, la
documentazione e il controllo delle modifiche apportate alla baseline. Il livello di
controllo delle modifiche adottato dipende dall'area applicativa, dalla complessit del
progetto specifico, dai requisiti del contratto, dal contesto e dall'ambiente in cui viene
eseguito il progetto.
L'applicazione a tutto il progetto del sistema di gestione della configurazione,
compresi i processi di controllo delle modifiche, raggiunge tre principali obiettivi:
Stabilisce un metodo di evoluzione che consente di identificare e richiedere in
modo omogeneo le modifiche per le baseline stabilite e per stimare il valore e
l'efficacia di tali modifiche;
Fornisce lopportunit di convalidare e migliorare costantemente il progetto
prendendo in considerazione l'impatto di ciascuna modifica;
fornisce un meccanismo per il gruppo di Project Management per comunicare in
modo uniforme tutte le modifiche agli stakeholder.
Di seguito vengono illustrate alcune attivit di gestione della configurazione
incluse nel controllo integrato delle modifiche.
Identificazione della configurazione: costituisce il fondamento in base al quale
la configurazione dei prodotti viene definita e verificata, i prodotti e i documenti
vengono etichettati, le modifiche vengono gestite e la responsabilit dei risultati
viene mantenuta.
Classificazione dello stato della configurazione: raccolta, memorizzazione e
accesso alle informazioni sulla configurazione necessarie per la gestione
efficace dei prodotti e delle relative informazioni.
Verifica e validazione della configurazione: consente di stabilire se le
prestazioni e i requisiti funzionali definiti nella documentazione di
configurazione siano stati soddisfatti.
98

Ogni modifica richiesta documentata deve essere accettata o rifiutata da una

delle autorit interne al gruppo di Project Management o da un'organizzazione esterna
che rappresenti l'iniziatore, lo sponsor o il cliente. Spesso il processo Controllo
integrato delle modifiche prevede la presenza di un comitato gestione modifiche
(CCB) responsabile dell'approvazione o del rifiuto delle modifiche richieste. I ruoli e
le responsabilit di tali comitati vengono definiti chiaramente nelle procedure di
controllo della configurazione e di controllo delle modifiche e sono approvati dallo
sponsor, dal cliente e dagli altri stakeholder. Molte organizzazioni di grandi
dimensioni predispongono diversi comitati, in una struttura a pi livelli, ripartendo le
responsabilit tra i vari comitati. Se il progetto viene fornito su base contrattuale,
alcune delle modifiche proposte devono essere approvate dal cliente.
Figura 4-8. Controllo integrato delle modifiche: Input, Strumenti e tecniche e Output
4.6.1
Controllo integrato delle modifiche: Input
.1

.2
Modifiche richieste
.3

.4

.5

.6

.7
Deliverable

99
4.6.2
Controllo integrato delle modifiche: Strumenti e tecniche
.1

di Project Management nell'implementazione del Controllo integrato delle modifiche
del progetto.
.2

Il sistema informativo di Project Management un sistema automatizzato che
consente al gruppo di Project Management di implementare il processo Controllo
integrato delle modifiche per il progetto, facilitare il feedback e controllare le
modifiche a tutto il progetto.
.3
Parere di esperti
Il gruppo di Project Management si avvale di quegli stakeholder che rappresentano il
parere di esperti allinterno del comitato gestione modifiche (CCB) per controllare e
approvare tutte le modifiche richieste da apportare a un qualsiasi aspetto del progetto.
4.6.3
Controllo integrato delle modifiche: Output
.1

.2
Richieste di modifica rifiutate

.3
Piano di Project Management (aggiornamenti)

.4
Descrizione dell'ambito del progetto (aggiornamenti)

.5
Azioni correttive approvate

.6
Azioni preventive approvate

.7
Correzione dei difetti approvata

.8

.9
Deliverable
Descritti nel paragrafo 4.4.3.1 e approvati mediante il processo Controllo integrato
delle modifiche (paragrafo 4.6).
100

4.7
Chiudere il progetto
Il processo Chiudere il progetto riguarda la realizzazione della fase di chiusura del
progetto individuata nel piano di Project Management. Nei progetti multi-fase, il
processo Chiudere il progetto chiude la porzione dell'ambito del progetto e delle
attivit associate applicabile a una fase specifica. Il processo comprende anche la
terminazione di tutte le attivit completate allinterno di tutti i gruppi di processi di
Project Management per chiudere formalmente il progetto o una fase di progetto e
quindi trasferire il progetto completato o annullato in base alle necessit. Il processo
Chiudere il progetto stabilisce anche le procedure necessarie a coordinare le attivit
che consentono di verificare e documentare i deliverable del progetto, di coordinare e
interagire per la formalizzazione dell'accettazione di tali deliverable da parte del
cliente o dello sponsor e di analizzare e documentare le ragioni delle azioni intraprese
qualora il progetto venga formalmente terminato prima del completamento. Sono
disponibili due procedure per stabilire le interazioni necessarie ad eseguire la chiusura
delle attivit per tutto il progetto o per una fase di progetto:
Procedura di chiusura amministrativa: questa procedura fornisce i dettagli di
tutte le attivit, le interazioni, e i relativi ruoli e responsabilit dei membri del
gruppo di progetto e degli altri stakeholder coinvolti nell'esecuzione della
procedura di chiusura amministrativa del progetto. L'esecuzione del processo di
chiusura amministrativa prevede anche delle attivit integrate necessarie alla
raccolta dei record di progetto, all'analisi della buona riuscita del progetto, alla
raccolta delle lesson learned e all'archiviazione delle informazioni di progetto
utilizzabili in futuro dall'organizzazione.
Procedura di chiusura del contratto: comprende tutte le attivit e le
interazioni necessarie a risolvere e chiudere qualsiasi accordo contrattuale messo
in atto per il progetto, ma anche a definire le attivit correlate che supportano la
chiusura amministrativa formale del progetto. Tale procedura prevede sia la
verifica del prodotto (tutto il lavoro completato in modo corretto e
soddisfacente) che la chiusura amministrativa (aggiornamento dei record del
contratto per riflettere i risultati definitivi e archiviazione delle informazioni da
utilizzare in futuro). Nei termini e nelle condizioni del contratto possono anche
essere presenti delle specifiche modalit per la chiusura del contratto che devono
essere inserite in questa procedura. La risoluzione anticipata del contratto
rappresenta un caso particolare di chiusura del contratto che pu essere dovuta,
ad esempio, all'impossibilit di consegnare il prodotto, a un superamento del
budget previsto o alla mancanza delle risorse necessarie. Questa procedura
rappresenta un input per il processo di chiusura del contratto.
Figura 4-9. Chiudere il progetto: Input, Strumenti e tecniche e Output

101
4.7.1
Chiudere il progetto: Input
.1

.2
Documentazione del contratto

La documentazione del contratto un input utilizzato per eseguire il processo di
chiusura del contratto e comprende il contratto stesso, nonch le modifiche apportate
al contratto e altra documentazione (come l'approccio tecnico adottato, la descrizione
del prodotto o i criteri o le procedure di accettazione dei deliverable).
.3

.4

.5

.6
Deliverable
Descritti nel paragrafo 4.4.3.1 e approvati mediante il processo Controllo integrato
4.7.2
Chiudere il progetto: Strumenti e tecniche
.1

di Project Management nell'esecuzione delle procedure amministrative e di chiusura
del contratto del progetto.
.2

Il gruppo di Project Management si avvale del sistema informativo di Project
Management per eseguire le procedure amministrative e di chiusura del contratto su
tutto il progetto.
.3
Parere di esperti
Si ricorre al parere di esperti per lo sviluppo e l'esecuzione delle procedure
amministrative e di chiusura del contratto.
4.7.3
.1
Chiudere il progetto: Output

Procedura di chiusura amministrativa
Tale procedura contiene tutte le attivit e i relativi ruoli e responsabilit dei membri
del gruppo di progetto coinvolti nell'esecuzione delle procedure di chiusura
amministrativa. Vengono elaborate e stabilite le procedure di trasferimento dei
prodotti o dei servizi del progetto al reparto produzione e/o alle funzioni operative.
Tale procedura fornisce una metodologia passo-passo per la chiusura amministrativa
dei fattori riportati di seguito:
102

azioni e attivit che definiscono i requisiti di approvazione degli stakeholder per

le modifiche e per tutti i livelli di deliverable;
azioni e attivit necessarie per confermare che il progetto risponda a tutti i
requisiti di sponsor, clienti e altri stakeholder, per verificare che tutti i
deliverable siano stati accettati e approvati e per convalidare la conformit ai
criteri di completamento e di uscita;
azioni e attivit necessarie per soddisfare i criteri di completamento o di uscita
del progetto.
.2
Procedura di chiusura del contratto

Tale procedura viene elaborata per fornire una metodologia passo-passo che riguarda i
termini e le condizioni dei contratti e i criteri richiesti di completamento o di uscita
per la chiusura del contratto. Contiene inoltre tutte le attivit e le relative
responsabilit dei membri del gruppo di progetto, dei clienti e degli altri stakeholder
coinvolti nel processo di chiusura del contratto. Le azioni eseguite formalmente
chiudono tutti i contatti associati al progetto completato.
.3
Prodotto, servizio o risultato finali

Accettazione formale e consegna del prodotto, del servizio o del risultato finale che il
progetto era autorizzato a produrre. L'accettazione comprende la ricezione di una
dichiarazione formale di conformit ai termini del contratto.
.4
Asset dei processi organizzativi (aggiornamenti)

La chiusura prevede lo sviluppo di indice e posizione della documentazione del
progetto mediante il sistema di gestione della configurazione (paragrafo 4.3).
Documentazione di accettazione formale: la conferma formale che sono stati
soddisfatti i requisiti del cliente ed ottenute le desiderate specifiche del prodotto,
del servizio o del risultato del progetto, viene ricevuta da parte dello stesso
cliente o dallo sponsor. Questo documento indica formalmente che il cliente o lo
sponsor hanno ufficialmente accettato i deliverable.
File del progetto: documentazione risultante dalle attivit svolte allinterno del
progetto; ad esempio, il piano di Project Management, l'ambito, il costo, le
baseline di schedulazione e della qualit, i calendari di progetto, i registri dei
rischi, le azioni pianificate di risposta ai rischi e l'impatto dei rischi.
Documenti della chiusura del progetto: documentazione formale che indica il
completamento del progetto e il trasferimento dei deliverable di progetto a terzi,
come un gruppo operativo. Se il progetto stato terminato prima del
completamento, la documentazione formale indica la motivazione alla base della
risoluzione anticipata del progetto e formalizza le procedure per il trasferimento
ad altri dei deliverable finiti e non finiti del progetto cancellato.
Dati storici: i dati storici e le informazioni sulle lesson learned vengono
trasferiti alla knowledge base delle lesson learned per essere utilizzabili in
occasione di progetti futuri.

103
CAPITOLO 5
Gestione dell'ambito del progetto
La gestione dellambito di progetto comprende i processi necessari ad assicurare che il

progetto includa tutto il lavoro richiesto, e soltanto il lavoro richiesto, ai fini del suo
completamento con successo5. Il suo obiettivo primario definire e controllare ci che
incluso nel progetto e ci che non lo . La figura 5-1 mostra una visione d'insieme
dei processi di gestione dell'ambito del progetto, mentre la figura 5-2 illustra un
diagramma di flusso di tali processi e dei relativi input, output e dei processi correlati
alle altre aree di conoscenza.
5.1 Pianificazione dell'ambito: creazione di un piano di gestione dell'ambito del
progetto che documenti come l'ambito del progetto sar definito, verificato e
controllato e come sar creata e definita la struttura di scomposizione del lavoro.
5.2 Definizione dell'ambito: sviluppo di una descrizione dettagliata dell'ambito del
progetto che servir come base per le future decisioni del progetto.
5.3 Creare la WBS: suddivisione dei principali deliverable del progetto, e del
lavoro incluso nel progetto, in componenti pi piccole e quindi maggiormente
gestibili.
5.4 Verifica dell'ambito: accettazione formale dei deliverable di progetto
completati.
5.5 Controllo dell'ambito: controllo delle modifiche apportate all'ambito del
progetto.
I processi descritti interagiscono tra loro e con i processi appartenenti ad altre
aree di conoscenza. Ogni processo pu richiedere limpegno di una o pi persone o
gruppi, secondo i requisiti del singolo progetto. Ciascun processo viene eseguito
almeno una volta per ogni progetto e in una o pi fasi di progetto, se il progetto
suddiviso in fasi. Sebbene i processi siano qui presentati come componenti discrete
con interfacce ben definite, nella pratica essi possono sovrapporsi o interagire in modi
diversi da quelli descritti. Le interazioni tra processi sono trattate in dettaglio nel
capitolo 3.

103
Capitolo 5 Gestione dell'ambito del progetto
Nel contesto del progetto, il termine ambito (scope) si pu riferire a:

Specifiche di prodotto: caratteristiche e funzioni che contraddistinguono un
prodotto, un servizio o un risultato.
Ambito del progetto: lavoro che bisogna fare per consegnare un prodotto, un
servizio o un risultato con le caratteristiche e le funzioni specificate.
Questo capitolo analizza i processi utilizzati per gestire l'ambito del progetto.
Tali processi di gestione dell'ambito del progetto, e gli strumenti e le tecniche ad essi
relativi, variano per area applicativa, vengono generalmente definiti come componenti
del ciclo di vita del progetto (paragrafo 2.1) e sono documentati nel piano di gestione
dell'ambito del progetto. La descrizione dettagliata e approvata dell'ambito del
progetto, la WBS e il dizionario WBS ad essa relativi sono la baseline dell'ambito
relativa al progetto stesso.
Generalmente, un progetto ha per risultato un unico prodotto, che pu tuttavia
contenere componenti secondari, ognuno avente un proprio ambito distinto ma
interdipendente. Ad esempio, un nuovo sistema telefonico includer in genere quattro
componenti secondari: hardware, software, formazione e messa in opera.
Lo stato di completezza di un ambito del progetto viene misurato a fronte del
piano di Project Management (paragrafo 4.3), della descrizione dell'ambito del
progetto, della WBS e del dizionario WBS ad essa relativi; lo stato di completezza
delle specifiche di prodotto viene invece misurato a fronte dei requisiti di prodotto.
opportuno che la gestione dell'ambito del progetto sia adeguatamente integrata nei
processi delle altre aree di conoscenza, affinch il lavoro del progetto abbia come
risultato la consegna del prodotto stabilito dalle specifiche dellambito del prodotto.
104

Figura 5-1. Visione dinsieme della gestione dell'ambito del progetto

105
Figura 5-2. Diagramma di flusso dei processi di gestione dell'ambito del progetto
106

5.1
Pianificazione dell'ambito
La definizione e la gestione dell'ambito del progetto influiscono sulla sua riuscita
complessiva. Ciascun progetto richiede un attento equilibrio tra strumenti, origini dei
dati, metodologie, processi e procedure, nonch tra altri fattori che garantiscono che
l'impegno dedicato alle attivit di ambito sia adeguato alle dimensioni, alla
complessit e all'importanza del progetto. Ad esempio, un progetto critico potrebbe
richiedere attivit di ambito formali, accurate e intensive, mentre un progetto di
routine potrebbe avere requisiti assai inferiori in termini di documentazione e verifica.
Il gruppo di Project Management si occupa di documentare le decisioni sulla gestione
dell'ambito nel contesto del piano di gestione dell'ambito del progetto; quest'ultimo
uno strumento di pianificazione che descrive in che modo il gruppo dovr definire
l'ambito del progetto, elaborarne una dettagliata descrizione, definire ed elaborare la
struttura di scomposizione del lavoro, verificare e controllare l'ambito del progetto.
L'elaborazione del piano di gestione dell'ambito del progetto e il relativo esame
dettagliato cominciano con l'analisi delle informazioni contenute nel Project Charter
(paragrafo 4.1), la descrizione preliminare dell'ambito del progetto (paragrafo 4.2), la
pi recente versione approvata del piano di Project Management (paragrafo 4.3), i dati
storici contenuti negli asset dei processi organizzativi (paragrafo 4.1.1.4) ed eventuali
altri fattori ambientali aziendali pertinenti (paragrafo 4.1.1.3).
Figura 5-3. Pianificazione dell'ambito: Input, Strumenti e tecniche e Output
5.1.1
Pianificazione dell'ambito: Input
.1

I fattori ambientali aziendali comprendono elementi quali la cultura
dellorganizzazione, l'infrastruttura, gli strumenti, le risorse umane, le politiche
relative al personale e le condizioni di mercato che potrebbero incidere sulle modalit
di gestione dell'ambito del progetto.
.2

Gli asset dei processi organizzativi sono regole, procedure e direttive formali e
informali che potrebbero incidere sulle modalit di gestione dell'ambito del progetto.
Gli asset riportati di seguito rivestono un particolare interesse per la pianificazione
dell'ambito del progetto.

107
Regole organizzative che fanno capo alla pianificazione e alla gestione

dell'ambito del progetto.
Procedure organizzative relative alla pianificazione e alla gestione dell'ambito
del progetto.
Dati storici legati a progetti precedenti verosimilmente situati nella Knowledge
base delle lesson learned.
.3
Project Charter
.4

.5

5.1.2
Pianificazione dell'ambito: Strumenti e tecniche
.1
Parere di esperti
Nell'elaborazione del piano di gestione dell'ambito del progetto si fa ricorso al parere
di esperti relativo al modo in cui stato gestito l'ambito in progetti equivalenti.
.2
Schemi di documento, Moduli, Standard

Tra gli schemi di documento si contano quelli relativi alla struttura di scomposizione
del lavoro (modelli di WBS), al piano di gestione dell'ambito e i moduli di controllo
delle modifiche dell'ambito del progetto.
5.1.3
.1
Pianificazione dell'ambito: Output

Piano di gestione dell'ambito del progetto
Il piano di gestione dell'ambito del progetto fornisce indicazioni sul modo in cui
l'ambito del progetto verr definito, documentato, verificato, gestito e controllato dal
gruppo di Project Management. I componenti del piano di gestione dell'ambito del
progetto includono:
Un processo che consenta di preparare una descrizione dettagliata dell'ambito
del progetto sulla base della descrizione preliminare.
Un processo che consenta la creazione della WBS a partire dalla descrizione
dettagliata dell'ambito del progetto e che stabilisca in che modo la WBS verr
aggiornata e approvata.
Un processo che specifichi la modalit per ottenere la verifica e l'accettazione
formale dei deliverable di progetto completati.
Un processo che consenta di controllare in che modo verranno elaborate le
richieste di modifica alla descrizione dettagliata dell'ambito del progetto. Tale
processo direttamente collegato al processo di controllo integrato delle
modifiche (paragrafo 4.6).
Il piano di gestione dell'ambito del progetto contenuto nel piano di Project
Management, o ne un componente secondario. Il piano di gestione dell'ambito del
progetto pu essere informale e sintetico oppure formale e molto dettagliato, in base
alle necessit del progetto.
108

5.2
Definizione dell'ambito
La preparazione di una descrizione dettagliata dell'ambito del progetto critica per la
riuscita del progetto stesso e si fonda sui deliverable principali, gli assunti e i vincoli
documentati durante l'avvio del progetto nel corso della descrizione preliminare
dell'ambito del progetto. Durante la pianificazione, si apprendono ulteriori
informazioni sul progetto ed quindi possibile definire e descrivere l'ambito del
progetto con maggiore specificit. Le esigenze, le necessit e le aspettative degli
stakeholder vengono analizzate e convertite in requisiti. Viene esaminata la
completezza di assunti e vincoli che, se necessario, vengono integrati. Il gruppo di
progetto ed altri stakeholder, che dispongono di informazioni approfondite sulla
descrizione preliminare dell'ambito del progetto, sono in grado di eseguire e preparare
le analisi.
Figura 5-4. Definizione dell'ambito: Input, Strumenti e tecniche e Output
5.2.1
Definizione dell'ambito Input
.1

.2
Project Charter
Se in una Performing Organization non viene utilizzato alcun Project Charter,
comunque necessario acquisire o elaborare informazioni analoghe e utilizzarle per
sviluppare la descrizione dettagliata dell'ambito del progetto.
.3

Se in una Performing Organization non viene utilizzata alcuna descrizione preliminare
dell'ambito del progetto, comunque necessario acquisire o elaborare informazioni
analoghe, comprese le specifiche del prodotto, e utilizzarle per sviluppare la
descrizione dettagliata dell'ambito del progetto.
.4

.5

Le richieste di modifica approvate (paragrafo 4.4) possono comportare modifiche
allambito del progetto, alla qualit del progetto, ai costi stimati o alla schedulazione
di progetto. Le modifiche vengono generalmente identificate e approvate mentre il
lavoro del progetto in corso.

109
5.2.2
Definizione dell'ambito Strumenti e tecniche
.1
Analisi dei prodotti

Ciascuna area applicativa dispone di uno o pi metodi largamente accettati per
tradurre gli obiettivi di progetto in deliverable e requisiti concreti. L'analisi dei
prodotti prevede l'uso di tecniche quali scomposizione dei prodotti, analisi di sistema,
ingegneria di sistema, ingegneria del valore, analisi del valore e analisi funzionale.
.2
Identificazione delle alternative

La tecnica di identificazione delle alternative si utilizza per generare approcci diversi
all'esecuzione del lavoro di progetto. A tale scopo possono essere utilizzate varie
tecniche di general management, tra cui le pi comuni sono il brainstorming e il
pensiero laterale.
.3
Parere di esperti
A ciascuna area applicativa possiede esperti che possono essere impiegati per
sviluppare parti della descrizione dettagliata dell'ambito del progetto.
.4
Analisi degli stakeholder

L'analisi degli stakeholder consente di identificare l'influenza e gli interessi dei vari
stakeholder e ne documenta esigenze, necessit e aspettative. L'analisi prosegue
quindi selezionando, assegnando una priorit e quantificando tali esigenze, necessit e
aspettative al fine della creazione dei requisiti. Le aspettative non quantificabili, quali
la soddisfazione del cliente, hanno carattere soggettivo e la probabilit di un loro
soddisfacimento ad alto rischio. possibile che gli interessi degli stakeholder
subiscano l'influsso positivo o negativo dell'esecuzione o del completamento del
progetto e che siano a loro volta in grado di esercitare la propria influenza sul progetto
e i relativi deliverable.
5.2.3
.1
Definizione dell'ambito Output

Descrizione dell'ambito del progetto
La descrizione dell'ambito del progetto illustra dettagliatamente i deliverable di
progetto e il lavoro necessario per crearli. La descrizione provvede anche a creare una
comune comprensione dell'ambito tra i diversi stakeholder e descrive i principali
obiettivi del progetto stesso. Consente inoltre al gruppo di progetto di eseguire una
pianificazione pi dettagliata, guida il lavoro del gruppo di progetto durante
l'esecuzione e fornisce la baseline per valutare se le richieste di modifiche o di lavoro
ulteriore siano contenute all'interno o all'esterno dei confini del progetto.
Il grado e il livello di dettaglio in base ai quali la descrizione dell'ambito del
progetto definisce quale sia il lavoro da eseguire e quale il lavoro da escludere, pu
determinare l'efficacia del controllo esercitato dal gruppo di Project Management
sull'ambito complessivo del progetto. A sua volta, la gestione dell'ambito del progetto
pu determinare l'efficacia della pianificazione, della gestione, del controllo e
dell'esecuzione del progetto da parte del gruppo di Project Management. La
descrizione dettagliata dell'ambito del progetto comprende le voci descritte di seguito,
sia direttamente che mediante riferimento ad altri documenti:
110

Obiettivi del progetto: Gli obiettivi del progetto comprendono i criteri

misurabili del successo del progetto. I progetti possono avere una vasta gamma
di obiettivi commerciali, di costo, di schedulazione, tecnici e di qualit. Gli
obiettivi del progetto possono comprendere anche obiettivi di costo, di
schedulazione e di qualit. Ciascun obiettivo di progetto dispone di attributi
quali il costo, di unit di misura quali il dollaro USA e di un valore assoluto o
relativo come minore di 1,5 milioni di dollari.
Descrizione delle specifiche di prodotto: Descrive le caratteristiche del
prodotto, del servizio o del risultato per la cui realizzazione stato creato il
progetto. Poich le caratteristiche del prodotto vengono elaborate
progressivamente, esse presenteranno generalmente meno dettagli nella fase
iniziale rispetto alle fasi successive. Anche se le caratteristiche subiscono una
variazione sia formale che sostanziale, la descrizione dell'ambito deve sempre
contenere informazioni sufficientemente dettagliate da consentire in seguito la
pianificazione dell'ambito del progetto.
Requisiti del progetto: Descrive le condizioni o le qualit che i deliverable del
progetto devono soddisfare o possedere per garantire la conformit a un
contratto, a uno standard, a specifiche di prodotto o ad altra documentazione il
cui rispetto formalmente imposto. Le analisi di tutte le esigenze degli
stakeholder, le loro necessit e le loro aspettative vengono tradotte in requisiti
cui viene assegnata una priorit.
Limiti di progetto: Identificano in genere ci che incluso nel progetto.
Dichiara esplicitamente ci che escluso dal progetto, nel caso in cui uno
stakeholder possa basarsi sull'assunto che un determinato prodotto, servizio o
risultato possa essere un componente del progetto.
Deliverable di progetto: I deliverable (paragrafo 4.4.3.1) comprendono tanto
gli output che contengono il prodotto o servizio del progetto, quanto i risultati
collaterali, quali le relazioni e la documentazione del Project Management. A
seconda della descrizione dell'ambito del progetto, i deliverable possono essere
descritti a livello sommario o in modo particolarmente dettagliato.
Criteri di accettazione del prodotto: Definisce il processo e i criteri di
accettazione dei prodotti completati.
Vincoli del progetto: Elenca e descrive i vincoli di progetto specifici associati
all'ambito del progetto che limitano le opzioni a disposizione del gruppo di
lavoro. Sono compresi, ad esempio, un budget predefinito o una data imposta
(milestone di schedulazione) richiesti formalmente dal cliente o dalla
Performing Organization. Nel caso in cui il progetto sia eseguito in dipendenza
di un contratto, i termini del contratto si tradurranno, in genere, in vincoli. I
vincoli elencati nella descrizione dettagliata dell'ambito del progetto sono
solitamente pi numerosi e dettagliati di quelli elencati nel Project Charter.
Assunti del progetto: Elenca e descrive gli specifici assunti del progetto relativi
all'ambito e l'impatto potenziale di tali assunti se dovessero dimostrarsi falsi. I
gruppi di progetto spesso li identificano, li documentano e li convalidano nel
corso del processo di pianificazione. Gli assunti elencati nella descrizione
dettagliata dell'ambito del progetto sono in genere pi numerosi e dettagliati di
quelli elencati nel Project Charter.

111
Organizzazione iniziale del progetto: Identifica i membri del gruppo di

progetto e gli stakeholder. inoltre documentata l'organizzazione del progetto.
Rischi iniziali definiti: Identifica i rischi noti.
Milestone di schedulazione: Il cliente o la Performing Organization possono di
identificare milestone e mettere delle date imposte in tali milestone di
schedulazione. Ci si pu riferire a queste date come vincoli di schedulazione.
Limite di finanziamento: Descrive qualsiasi limitazione a cui soggetto il
finanziamento del progetto, sia nel valore complessivo che riguardo ad un lasso
di tempo specificato.
Stima dei costi: La stima dei costi del progetto confluisce nel costo totale
previsto del progetto e viene generalmente preceduta da una specifica che
fornisce indicazioni di accuratezza, ad esempio concettuale o definitivo.
Requisiti di gestione della configurazione del progetto: Descrive il livello
della gestione della configurazione e del controllo delle modifiche da
implementare sul progetto.
Specifiche del progetto: Identifica i documenti delle specifiche a cui il progetto
si deve attenere.
Requisiti di approvazione: Identifica i requisiti di approvazione che possibile
applicare ad elementi quali obiettivi del progetto, deliverable, documenti e
lavoro.
.2
Richieste di modifica
Durante il processo di definizione dell'ambito possono venire elaborate richieste di
modifica al piano di Project Management e ai relativi piani ausiliari. Le modifiche
vengono elaborate per l'analisi e la disposizione dal processo di controllo integrato
delle modifiche.
.3
Piano di gestione dell'ambito del progetto (aggiornamenti)

Potrebbe essere necessario aggiornare il componente del piano di Project Management
relativo al piano di gestione dell'ambito del progetto affinch comprenda le richieste
di modifica approvate, come risultano dal processo di definizione dell'ambito.
.5.3
Creare la WBS
La WBS una scomposizione gerarchica, orientata ai deliverable, del lavoro che deve
essere eseguito dal gruppo di progetto per realizzare gli obiettivi del progetto stesso e
creare i deliverable richiesti. La WBS organizza e definisce l'ambito complessivo del
progetto. Essa ne suddivide il lavoro in porzioni pi piccole e pi facili da gestire,
dove ogni livello successivo della WBS comporta una definizione pi dettagliata del
lavoro di progetto. possibile effettuare la schedulazione, la stima dei costi, il
monitoraggio e il controllo del lavoro pianificato, contenuto nei componenti della
WBS che si trovano ai livelli pi bassi della gerarchia, chiamati anche Work Package.
La WBS rappresenta il lavoro specificato nella descrizione dell'ambito del
progetto, approvata. I componenti costitutivi della WBS sono daiuto agli stakeholder
nel visualizzare i deliverable (paragrafo 4.4.3.1) del progetto.
112

5
Figura 5-5. Creare la WBS: Input, Strumenti e tecniche e Output
5.3.1
Creare la WBS: Input
.1

.2

.3

.4

5.3.2
.1
Creare la WBS: Strumenti e tecniche

Modelli della struttura di scomposizione del lavoro
Sebbene ciascun progetto sia unico, possibile utilizzare la WBS di un progetto
precedente come modello per progetto un nuovo, in quanto alcuni progetti possono
essere affini a progetti precedenti. Ad esempio, molti progetti allinterno di
unorganizzazione sono caratterizzati da cicli di vita identici o simili e di conseguenza
i deliverable richiesti per ciascuna fase risultano identici o simili. Molte aree
applicative o Performing Organization hanno adottato dei modelli di WBS standard.
Il Project Management Institute Practice Standard for Work Breakdown
Structures fornisce una guida alla generazione, allo sviluppo e all'applicazione delle
strutture di scomposizione del lavoro. Nel manuale sono contenuti numerosi esempi,
specifici per settore, dei modelli delle WBS che possono essere personalizzati per
progetti specifici creati in una determinata area applicativa. Nella figura 5-6 viene
illustrata una parte di un esempio di WBS, con alcune diramazioni della WBS
scomposta fino al livello dei Work Package.

113
Figura 5-6. Esempio di struttura di scomposizione del lavoro con alcune diramazioni
scomposte fino ai Work Package
.2
Scomposizione
La scomposizione una suddivisione dei deliverable del progetto in componenti pi
piccoli e pi facili da gestire fino a che lavoro e deliverable vengono definiti a livello
di Work Package. Il livello dei Work Package rappresenta il gradino pi basso della
gerarchia creata dalla WBS ed il punto che consente una stima pi affidabile dei
costi e della schedulazione previsti dal lavoro. Il livello di dettaglio dei Work Package
varia in base alle dimensioni e alla complessit del progetto.
Non sempre possibile effettuare la scomposizione di un deliverable o un
sottoprogetto che dovrebbero essere eseguiti in un periodo troppo lontano nel tempo.
Il gruppo di Project Management aspetta in genere fino a che i deliverable o il
sottoprogetto siano pi chiari per sviluppare i dettagli della WBS. Tale tecnica viene a
volte denominata pianificazione a finestra mobile.
Deliverable diversi possono essere caratterizzati da livelli di scomposizione
diversi. Per ottenere un impegno di lavoro che sia gestibile (come un Work Package),
il lavoro relativo ad alcuni deliverable deve essere scomposto soltanto al livello
successivo, mentre in altri casi sono necessari ulteriori livelli di scomposizione. Con
l'incremento della scomposizione del lavoro in livelli di dettaglio inferiori, si
incrementa la capacit di pianificare, gestire e controllare il lavoro. Tuttavia, una
scomposizione eccessiva pu portare a un impegno di gestione improduttivo, a un uso
inefficiente delle risorse e a un calo dell'efficienza nell'esecuzione del lavoro. Il
gruppo di progetto deve trovare un punto di equilibrio tra un livello scarso e un livello
eccessivo di dettaglio nella pianificazione della WBS.
114

La scomposizione del lavoro complessivo di progetto comporta in genere le

attivit riportate di seguito:
Identificazione dei deliverable e del relativo lavoro.
Strutturazione e organizzazione della WBS.
Scomposizione dei livelli superiori della WBS in componenti dettagliati a livelli
inferiori.
Sviluppo e assegnazione di codici di identificazione ai componenti della WBS.
Verifica che i livelli di scomposizione del lavoro siano necessari e sufficienti.
L'identificazione dei principali deliverable del progetto e del lavoro necessario
per produrre tali deliverable richiede l'analisi della descrizione dettagliata dell'ambito
del progetto. Tale analisi necessita inoltre lutilizzo del parere di esperti che consenta
di identificare tutto il lavoro incluso nei deliverable di Project Management e nei
deliverable richiesti da contratto.
La strutturazione e l'organizzazione dei deliverable e del lavoro di progetto ad
essi associato in una WBS, che sia conforme ai requisiti di controllo e di gestione
imposti dal gruppo di Project Management, una tecnica analitica che pu essere
eseguita utilizzando un modello di WBS. La struttura che ne risulta pu assumere
diverse forme come:
Utilizzo dei deliverable e dei sottoprogetti principali come primo livello di
scomposizione, come illustrato nella figura 5-6.
Utilizzo dei sottoprogetti illustrati nella figura 5-6, dove i sottoprogetti possono
essere sviluppati da organizzazioni esterne al gruppo di progetto. Ad esempio, in
alcune aree applicative possibile definire e suddividere la WBS di progetto in
pi parti, come una WBS di progetto riepilogativa con pi sottoprogetti al suo
interno, che possono essere dati in subappalto. Il fornitore sviluppa quindi una
WBS di supporto al contratto come elemento costitutivo del lavoro pattuito.
Utilizzo delle fasi del ciclo di vita del progetto come primo livello di
scomposizione, con i deliverable del progetto inseriti al secondo livello, come
mostrato nella figura 5-7.
Utilizzo di approcci diversi all'interno di ciascuna diramazione della WBS, come
mostrato nella figura 5-8, dove il collaudo e la valutazione sono una fase,
l'aeromobile un prodotto e la formazioni un servizio di supporto.
La scomposizione dei componenti della WBS di livello superiore richiede la
suddivisione del lavoro per ciascun deliverable o sottoprogetto nei suoi componenti
fondamentali, dove i componenti della WBS rappresentano dei prodotti, servizi o
risultati verificabili. Ogni componente deve essere definito chiaramente ed
esaustivamente e quindi assegnato a un'unit specifica interna alla Performing
Organization che accetti la responsabilit legata al completamento dei componenti
della WBS. I componenti vengono definiti in base alla modalit effettiva di
esecuzione e controllo del lavoro previsto dal progetto. Ad esempio, il componente
report di stato del Project Management pu prevedere dei report di stato settimanali,
mentre il prodotto da generare pu comprendere numerosi componenti fisici unici pi
l'assemblaggio finale.

115
Nell'ambito della verifica della correttezza della scomposizione necessario

determinare se i componenti della WBS appartenenti ai livelli inferiori siano
effettivamente quelli necessari e sufficienti al completamento dei corrispondenti
deliverable appartenenti a livelli superiori.
Figura 5-7. Esempio di struttura di scomposizione del lavoro organizzata per fasi
Figura 5-8. Esempio di scomposizione del lavoro per articoli di materiale per la Difesa
116

5.3.3
Creare la WBS: Output
.1
Descrizione dell'ambito del progetto (aggiornamenti)

Se dal processo Creare la WBS vengono originate richieste di modifica approvate,
allora la descrizione dell'ambito del progetto viene aggiornata in modo da includerle.
.2
Struttura di scomposizione del lavoro

La WBS corrente il documento principale generato dal processo Creare la WBS. A
ciascun componente della WBS, compresi i Work Package e i punti di controllo
appartenenti a una WBS, viene in genere assegnato un identificativo univoco da un
codice di classificazione. Questi identificativi forniscono una struttura per la somma
gerarchica delle informazioni su costi, schedulazione e risorse.
La WBS non va confusa con altre forme di strutture di scomposizione utilizzate
per presentare informazioni del progetto. Di seguito vengono illustrate le altre
strutture utilizzate in alcune aree applicative o in altre aree di conoscenza:
Struttura di scomposizione dell'organizzazione (OBS): fornisce una
rappresentazione gerarchica dell'organizzazione del progetto disposta in modo
da correlare i Work Package alle unit della Performing Organization.
Distinta base (BOM): rappresenta un elenco organizzato in ordine gerarchico
dei componenti finiti, dei componenti semilavorati e dei componenti fisici
necessari alla creazione del prodotto.
Struttura di scomposizione dei rischi (RBS): fornisce una rappresentazione
gerarchica dei rischi del progetto ordinata per categoria di rischio.
Struttura di scomposizione delle risorse (RBS): fornisce una rappresentazione
gerarchica delle risorse ordinate per tipo da utilizzare nel corso del progetto.
.3
Dizionario della WBS

Il documento generato dal processo Creare la WBS che supporta la WBS viene
chiamato dizionario della WBS ed il documento di accompagnamento della WBS
stessa. Nel dizionario della WBS possibile descrivere in modo dettagliato il
contenuto dei componenti inclusi in una WBS, compresi i Work Package e i punti di
controllo. Per ciascun componente della WBS, il dizionario della WBS riporta un
identificativo dei codici di classificazione, un capitolato, dati sull'organizzazione
responsabile e un elenco delle milestone di schedulazione. Altre informazioni relative
a un componente della WBS comprendono i dati di contatto, i requisiti della qualit e i
riferimenti tecnici che servono per facilitare le prestazioni del lavoro. Altre
informazioni relative al controllo possono invece essere costituite dalla voce di spesa.
Per il Work Package possono invece essere aggiunte informazioni come un elenco
delle attivit schedulate ad esso associate, le risorse necessarie e una stima dei costi.
Ogni componente della WBS dispone di un rimando, ove opportuno, ad altri
componenti della WBS inclusi nel dizionario della WBS stessa.
.4
Baseline dell'ambito
La descrizione dettagliata e approvata dell'ambito del progetto (paragrafo 5.2.3.1), la
WBS e il dizionario della WBS ad essa relativi costituiscono la baseline dell'ambito
del progetto.

117
.5
Piano di gestione dell'ambito del progetto (aggiornamenti)

Se dal processo Creare la WBS vengono originate richieste di modifica approvate, il
piano di gestione dell'ambito del progetto potrebbe necessitare di un aggiornamento in
modo da includere le modifiche approvate.
.6
Le richieste di modifica alla descrizione dell'ambito del progetto e ai suoi componenti
possono essere generate dal processo Creare la WBS e quindi elaborate per l'analisi e
l'approvazione mediante il processo di controllo integrato delle modifiche.
5.4
Verifica dell'ambito
La verifica dell'ambito il processo che consente di ottenere l'accettazione formale da
parte degli stakeholder dell'ambito del progetto completo e dei deliverable associati.
La verifica dell'ambito del progetto prevede l'analisi dei deliverable per controllare
che ciascuno di essi sia stato completato in modo soddisfacente. Se il progetto viene
concluso prima, il processo di verifica dell'ambito del progetto deve stabilire e
documentare il livello e la dimensione del completamento. La verifica dell'ambito
differisce dal controllo qualit per il fatto che la prima riguarda principalmente
l'accettazione dei deliverable, mentre il secondo riguarda soprattutto la conformit ai
requisiti di qualit specificati per i deliverable. Il controllo qualit viene in genere
eseguito prima della verifica dell'ambito; i due processi possono essere tuttavia
eseguiti in parallelo.
Figura 5-9. Verifica dell'ambito: Input, Strumenti e tecniche e Output
5.4.1
Verifica dell'ambito: Input
.1

La descrizione dell'ambito del progetto comprende la descrizione delle specifiche di
prodotto che illustra il prodotto del progetto da analizzare e i criteri di accettazione del
prodotto adottati.
.2

Il dizionario della WBS un componente della definizione dettagliata dell'ambito del
progetto che consente di verificare che i deliverable prodotti e accettati siano inclusi
nell'ambito del progetto approvato.
118

.3

.4
Deliverable
I deliverable sono quelli che sono stati completati sia totalmente che parzialmente e
rappresentano l'output del processo Dirigere e gestire l'esecuzione del progetto
(paragrafo 4.4).
5.4.2
.1
5.4.3
5.5
Verifica dell'ambito: Strumenti e tecniche

Ispezione
L'ispezione prevede attivit quali la misurazione, l'esame e la verifica che consentono
di determinare se il lavoro e i deliverable rispondono ai requisiti e ai criteri di
accettazione del prodotto. Le ispezioni sono anche denominate analisi, analisi del
prodotto, revisioni e analisi passo-passo. In alcune aree applicative, questi termini
hanno significati pi limitati e specifici.
Verifica dell'ambito: Output
.1
Deliverable accettati
Il processo di verifica dell'ambito documenta i deliverable completati che sono stati
anche accettati. I deliverable completati ma non accettati vengono invece documentati
unitamente ai motivi alla base della mancata accettazione. La verifica dell'ambito
comprende la documentazione di supporto ricevuta dal cliente o dallo sponsor che
conferma l'accettazione dei deliverable del progetto da parte degli stakeholder.
.2
Le richieste di modifica possono essere generate dal processo di verifica dell'ambito e
vengono elaborate per la revisione e la disposizione attraverso il processo di controllo
integrato delle modifiche.
.3

Controllo dell'ambito
Il controllo dell'ambito del progetto si occupa di come influire sui fattori che creano le
modifiche all'ambito del progetto e di come controllare l'impatto di tali modifiche. Il
controllo dell'ambito garantisce che tutte le modifiche richieste e le azioni correttive
consigliate siano elaborate attraverso il processo di controllo integrato delle modifiche
del progetto. Il controllo dell'ambito del progetto, integrato con altri processi di
controllo, consente inoltre di gestire le modifiche effettive nel momento stesso in cui
queste si verificano. Ci si riferisce alle modifiche non controllate con l'espressione
cambiamento non controllato dell'ambito del progetto. Le modifiche sono inevitabili
e rendono quindi necessario un processo di controllo delle modifiche.

119
Figura 5-10. Controllo dell'ambito: Input, Strumenti e tecniche e Output
5.5.1
Controllo dell'ambito: Input
.1

La descrizione dell'ambito del progetto, unitamente alla WBS e al dizionario della
WBS ad essa associati (paragrafo 5.3), definisce la baseline dell'ambito del progetto e
le specifiche di prodotto.
.2

.3

.4

.5
Report sulle prestazioni

I report sulle prestazioni forniscono informazioni sulle prestazioni del lavoro di
progetto, come sui deliverable provvisori che sono stati completati.
.6

Una richiesta di modifica approvata (paragrafo 4.4.1.4), che impatta sull'ambito del
progetto, una qualsiasi modifica alla baseline dell'ambito, come definito nella
descrizione approvata dello stesso, alla WBS e al dizionario della WBS approvati.
.7

120

5.5.2
.1
Controllo dell'ambito: Strumenti e tecniche

Sistema di controllo delle modifiche
Il sistema di controllo delle modifiche dell'ambito del progetto, documentato nel piano
di gestione dell'ambito, definisce le procedure da seguire per apportare delle
modifiche all'ambito del progetto e alle specifiche di prodotto. Il sistema comprende la
documentazione, i sistemi di rilevamento e i livelli di approvazione necessari per
autorizzare le modifiche. Il sistema di controllo delle modifiche dell'ambito viene
integrato con qualsiasi sistema informativo completo di Project Management
(paragrafo 4.6.2.2) al fine di controllare l'ambito del progetto. Quando il progetto
viene gestito in ottemperanza a un contratto, il sistema di controllo delle modifiche
deve conformarsi alle disposizioni contrattuali.
.2
Analisi dello scostamento

Le misurazioni delle prestazioni del progetto consentono di valutare la dimensione
dello scostamento. Un aspetto importante nel controllo dell'ambito del progetto la
determinazione della causa dello scostamento rispetto alla baseline dell'ambito
(paragrafo 5.3.3.4) e la decisione su quale azione correttiva sia necessaria.
.3
Ripianificazione
Le richieste di modifica approvate che influiscono sull'ambito del progetto possono
comportare delle modifiche anche alla WBS e al dizionario della WBS, alla
descrizione dell'ambito e al piano di gestione dell'ambito. Le richieste di modifica
approvate possono inoltre essere causa di aggiornamenti ai componenti del piano di
Project Management.
.4
Sistema di gestione della configurazione

Un sistema formale di gestione della configurazione (paragrafo 4.3.2.2) fornisce le
procedure per lo stato dei deliverable e garantisce che le modifiche richieste all'ambito
del progetto e alle specifiche di prodotto siano prese in considerazione e documentate
in modo accurato prima di essere elaborate dal processo di controllo integrato delle
modifiche.
5.5.3
Controllo dell'ambito: Output
.1
Descrizione dell'ambito del progetto (aggiornamento)

Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, la
descrizione dell'ambito del progetto viene rivista e quindi ripubblicata in conformit
alle modifiche approvate. La descrizione aggiornata dell'ambito del progetto diviene
la nuova baseline dell'ambito del progetto per modifiche future.
.2
Struttura di scomposizione del lavoro (aggiornamenti)

Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, la WBS
viene rivista e quindi ripubblicata in conformit alle modifiche approvate.
.3
Dizionario della WBS (aggiornamento)

Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, il
dizionario della WBS viene rivisto e quindi ripubblicato in conformit alle modifiche
approvate.

121
.4
Baseline dell'ambito (aggiornamento)

.5
I risultati del controllo dell'ambito del progetto possono generare delle richieste di
modifica, che vengono elaborate per la revisione e la disposizione in conformit al
processo di controllo integrato delle modifiche del progetto.
.6
Azione correttiva consigliata

Unazione correttiva raccomandata rappresenta un passo consigliato per allineare le
prestazioni future previste per il progetto al piano di Project Management e alla
descrizione dell'ambito del progetto.
.7

Le cause degli scostamenti, la motivazione alla base dell'azione correttiva scelta e altri
tipi di lesson learned, derivanti dal controllo delle modifiche dell'ambito del progetto,
vengono documentati e aggiornati nel database dei dati storici degli asset dei processi
organizzativi.
.8

Se le richieste di modifica approvate influiscono sull'ambito del progetto, allora i
corrispondenti documenti che le compongono, le baseline dei costi e le baseline di
schedulazione del piano di Project Management vengono rivisti e ripubblicati in
conformit alle modifiche approvate.
122

CAPITOLO 6
Gestione dei tempi di progetto
La gestione dei tempi di progetto include i processi necessari ad assicurare il

completamento del progetto nei tempi previsti. La figura 6-1 mostra una visione
d'insieme dei processi di gestione dei tempi di progetto, mentre la figura 6-2 illustra
un diagramma di flusso di tali processi e dei relativi input, output e di altri processi
correlati delle aree di conoscenza. La gestione dei tempi di progetto prevede i processi
riportati di seguito:
6.1 Definizione delle attivit: identificazione delle specifiche attivit pianificate che
devono essere svolte per produrre i vari deliverable di progetto
6.2 Sequenzializzazione delle attivit: identificazione e documentazione delle
relazioni di dipendenza presenti tra le attivit schedulate.
6.3 Stima delle risorse delle attivit: stima del tipo e della quantit di risorse
necessarie ad eseguire ciascuna attivit schedulata.
6.4 Stima della durata delle attivit: stima del numero di periodi lavorativi
necessari al completamento di ogni attivit schedulata.
6.5 Sviluppo della schedulazione: analisi delle sequenze delle attivit, delle durate,
dei requisiti in termini di risorse e dei vincoli di schedulazione che consente di
creare la schedulazione di progetto.
6.6 Controllo della schedulazione: controllo delle modifiche apportate alla
schedulazione di progetto.
Questi processi interagiscono tra loro e con processi appartenenti anche ad altre
gruppi, in base ai requisiti del progetto. Ciascun processo si verifica almeno una volta
per ogni progetto e in una o pi fasi di progetto, se il progetto diviso in fasi. Sebbene
i processi siano qui presentati come componenti discreti con interfacce ben definite,
nella pratica essi possono sovrapporsi e interagire in modi diversi da quelli qui
descritti. Per una descrizione dettagliata delle interazioni tra processi, consultare il
capitolo 3.

123
Capitolo 6 Gestione dei tempi di progetto
In alcuni progetti, soprattutto quelli con ambito limitato, la sequenzializzazione

delle attivit, la stima delle risorse delle attivit, la stima della durata delle attivit e lo
sviluppo della schedulazione sono cos strettamente collegati da essere considerati
come un unico processo che pu essere svolto da una sola persona in un arco di tempo
relativamente limitato. Nel presente manuale, questi processi vengono indicati come
processi distinti perch presentano strumenti e tecniche differenti.
Sebbene non illustrato sotto forma di processo discreto, il lavoro necessario
all'esecuzione dei sei processi di gestione dei tempi di progetto preceduto da una
fase di pianificazione eseguita dal gruppo di Project Management. L'impegno
necessario alla pianificazione rientra nel processo di sviluppo del piano di Project
Management (paragrafo 4.3), destinato alla creazione di un piano di gestione della
schedulazione che imposta il formato e stabilisce i criteri di sviluppo e controllo della
schedulazione di progetto. I processi di gestione dei tempi di progetto e gli strumenti e
le tecniche ad essi associati variano in base all'area applicativa e vengono in genere
definiti come componenti del ciclo di vita del progetto (paragrafo 2.1); vengono
inoltre documentati nel piano di gestione della schedulazione. Il piano di gestione
della schedulazione contenuto nel piano di Project Management (introduzione al
paragrafo 4.3), o ne rappresenta un componente, e pu essere formale o informale,
dettagliato o sintetico, in base alle necessit del singolo progetto.
124

Figura 6-1. Visione dinsieme della gestione dei tempi di progetto

125
Figura 6-2. Diagramma di flusso dei processi di gestione dei tempi di progetto
126

6.1
Definizione delle attivit

La definizione delle attivit schedulate comporta l'identificazione e la documentazione
per l'esecuzione del lavoro pianificato. Il processo di Definizione delle attivit
consente di identificare i deliverable al livello pi basso della struttura di
scomposizione del lavoro (WBS), altrimenti detto Work Package. I Work Package del
progetto sono pianificati (scomposti) in componenti pi piccoli chiamati attivit
schedulate le quali costituiscono la base della stima, della schedulazione,
dell'esecuzione, del monitoraggio e del controllo del lavoro di progetto. In questo
processo implicita la definizione e la pianificazione delle attivit schedulate in modo
da rispettare gli obiettivi del progetto.
Figura 6-3. Definire le attivit: Input, Strumenti e tecniche e Output
6.1.1
Definire le attivit: Input
.1

I fattori ambientali aziendali (paragrafo 4.1.1.3) che possono essere presi in
considerazione comprendono la disponibilit dei sistemi informativi di Project
Management e gli strumenti software di schedulazione.
.2

Gli asset dei processi organizzativi (paragrafo 4.1.1.4) contengono i criteri correnti,
procedure e direttive formali e informali legati alla pianificazione delle attivit e che
sono presi in considerazione per l'elaborazione delle definizioni delle attivit stesse.
La knowledge base delle lesson learned contiene i dati storici relativi agli elenchi delle
attivit utilizzati per progetti simili precedenti che possono essere presi in
considerazione al momento della definizione delle attivit schedulate del progetto.
.3

I deliverable, i vincoli e gli assunti del progetto documentati nella descrizione
dell'ambito del progetto (paragrafo 5.2.3.1) vengono presi in considerazione in modo
esplicito nel corso della definizione delle attivit. I vincoli sono fattori che limitano le
opzioni a disposizione del gruppo di Project Management, come le milestone di
schedulazione caratterizzate da date di completamento richieste dalla direzione o dal
contratto. Gli assunti sono fattori che vengono ritenuti veri per la pianificazione della
schedulazione di progetto, come le ore lavorative settimanali o il periodo dell'anno in
cui verr eseguito il lavoro di realizzazione.

127
.4
Struttura di scomposizione del lavoro (WBS)

La struttura di scomposizione del lavoro (WBS) (paragrafo 5.3.3.2) uno degli input
principali per la definizione delle attivit schedulate.
.5

Il dizionario della WBS (paragrafo 5.3.3.3) uno degli input principali per la
definizione delle attivit schedulate.
.6

Il piano di Project Management contiene il piano di gestione della schedulazione
(materiale introduttivo del capitolo 6), che fornisce la guida allo sviluppo e alla
pianificazione delle attivit schedulate e del piano di gestione dell'ambito del progetto.
6.1.2
Definire le attivit: Strumenti e tecniche
.1
Scomposizione
La tecnica di scomposizione, nella modalit in cui viene applicata alla definizione
delle attivit, comporta la suddivisione dei Work Package del progetto in componenti
pi piccoli e pi facili da gestire, chiamati anche attivit schedulate. Il processo di
Definizione delle attivit consente di delineare gli output finali come attivit
schedulate piuttosto che come deliverable, come avviene nel processo Creare la WBS
(paragrafo 5.3).
possibile generare l'elenco delle attivit, la WBS e il dizionario della WBS sia
in sequenza che contemporaneamente, tenendo per presente che la WBS e il
dizionario della WBS sono la base per lo sviluppo dell'elenco delle attivit finale.
Ogni Work Package appartenente alla WBS viene poi scomposto in attivit schedulate
necessarie a produrre i deliverable dei Work Package. La definizione delle attivit
viene spesso eseguita dai membri del gruppo di progetto responsabili del Work
Package.
.2
Schemi di documento
Un elenco delle attivit standard o una parte di un elenco di attivit derivante da un
progetto precedente spesso adottato come schema di documento (paragrafo 4.1.1.4)
per un nuovo progetto. Le informazioni sugli attributi delle attivit corrispondenti
presenti negli schemi di documento possono anche contenere un elenco di skill delle
risorse e delle ore di impegno necessarie, l'identificazione dei rischi, i deliverable
previsti o altre informazioni descrittive. Gli schemi di documento possono anche
essere usati per identificare le milestone di schedulazione.
.3
Pianificazione a finestra mobile

La WBS e il dizionario della WBS riflettono l'evoluzione dell'ambito del progetto che
diviene sempre pi dettagliato fino al raggiungimento del livello del Work Package.
La pianificazione a finestra mobile una forma di pianificazione a elaborazione
progressiva (paragrafo 1.2.1.3) secondo la quale il lavoro da completare a breve
termine viene pianificato nel dettaglio fino al livello basso della WBS, mentre il
lavoro da svolgere a lunghissimo termine viene pianificato per i componenti della
WBS che si trovano a un livello relativamente alto della WBS. Il lavoro da eseguire
nell'arco di uno o due periodi di verifica a breve termine viene pianificato nel dettaglio
con il progressivo completamento del lavoro nel corso del periodo attuale. Ne
consegue che all'interno del ciclo di vita del progetto le attivit schedulate possono
esistere a diversi livelli di dettaglio. Nel corso dell'iniziale pianificazione strategica,
quando le informazioni non sono ben definite, le attivit possono essere mantenute al
livello delle milestone.
128

.4
Parere di esperti
I membri del gruppo di progetto o gli altri esperti che hanno acquisito una certa
esperienza e competenza nello sviluppo dettagliato delle descrizioni dell'ambito del
progetto, delle WBS e delle schedulazioni di progetto possono fornire le proprie
conoscenze nella definizione delle attivit.
.5
Pianificazione del componente

Quando la definizione dell'ambito del progetto a disposizione non sufficiente a
scomporre un ramo della WBS al livello dei Work Package, possibile utilizzare
l'ultimo componente di tale ramo della WBS per sviluppare una schedulazione di
progetto di alto livello relativa al componente in questione. Il gruppo di progetto
seleziona e utilizza questi componenti della pianificazione per pianificare e schedulare
il lavoro futuro a vari livelli pi elevati all'interno della WBS. Le attivit schedulate
utilizzate per questi componenti della pianificazione possono essere le attivit di
riepilogo non sufficienti a supportare stima, schedulazione, esecuzione, monitoraggio
o controllo dettagliati del lavoro di progetto. Di seguito vengono illustrati due
componenti della pianificazione.
Punto di controllo: possibile posizionare un punto di controllo gestionale in
punti gestionali selezionati (componenti specifici a livelli selezionati) della
struttura di scomposizione del lavoro che siano sopra il livello dei Work
Package. Questi punti di controllo vengono utilizzati come base per la
pianificazione quando non sono stati ancora pianificati i Work Package
associati. Tutto il lavoro eseguito e l'impegno speso all'interno di un punto di
controllo vengono documentati in un piano dei punti di controllo.
Planning Package: un Planning Package un componente della WBS che si
trova al di sotto del punto di controllo, ma al di sopra del Work Package. Questo
componente consente di pianificare il contenuto del lavoro noto che non dispone
di attivit schedulate dettagliate.
6.1.3
.1
Definire le attivit: Output

Elenco delle attivit
L'elenco delle attivit un elenco esaustivo di tutte le attivit schedulate pianificate e
da eseguire nel corso del progetto. L'elenco delle attivit non comprende le attivit
schedulate che non sono necessarie nell'ambito del progetto. Tale elenco comprende
l'identificativo dell'attivit e la descrizione dell'ambito del lavoro per ciascuna attivit
schedulata, con dettagli sufficienti ad assicurare che i membri del gruppo di progetto
comprendano il tipo di lavoro da effettuare. L'ambito del lavoro dell'attivit schedulata
pu essere espresso in termini fisici, come la lunghezza in metri di una conduttura da
installare, la collocazione prevista per la posa del cemento, il numero di disegni, le
righe di codice del programma informatico o i capitoli di un libro. L'elenco delle
attivit viene utilizzato nel modello di schedulazione ed un componente del piano di
Project Management (paragrafo 4.3). Le attivit schedulate sono componenti discreti
della schedulazione di progetto, ma non sono componenti della WBS.

129
6.2
.2
Attributi delle attivit

Gli attributi delle attivit sono un'estensione degli attributi delle attivit presenti
nell'elenco delle attivit e identificano i vari attributi associati a ciascuna attivit
schedulata. Gli attributi delle attivit per ciascuna attivit schedulata comprendono
l'identificativo dell'attivit, il codice attivit, la descrizione dell'attivit, le attivit
predecessore, le attivit successore, le relazioni logiche, lead e lag, i requisiti delle
risorse, le date imposte, i vincoli e gli assunti. Gli attributi delle attivit possono anche
includere la persona responsabile dell'esecuzione del lavoro, l'area geografica o il
luogo in cui deve essere eseguito il lavoro e il tipo di attivit schedulata come livello
di impegno, impegno discreto e impegno distribuito. Tali attributi sono utilizzati per
lo sviluppo della schedulazione di progetto e per la selezione, l'ordinamento e la
classificazione delle attivit schedulate in modi diversi all'interno dei report. Il numero
di attributi varia a seconda dell'area applicativa. Gli attributi delle attivit vengono
utilizzati nel modello di schedulazione.
.3
Elenco delle milestone

L'elenco delle milestone di schedulazione identifica tutte le milestone e indica se la
milestone obbligatoria (stabilita per contratto) oppure facoltativa (basata su requisiti
del progetto o dati storici). L'elenco delle milestone un componente del piano di
Project Management (paragrafo 4.3) e le milestone stesse vengono utilizzate nel
modello di schedulazione.
.4
Richieste di modifiche
Il processo Definizione delle attivit pu generare delle richieste di modifica
(paragrafo 4.4.3.2) che possono influire sulla descrizione dell'ambito del progetto e
sulla struttura di scomposizione del lavoro (WBS). Le richieste di modifica vengono
elaborate per l'analisi e la disposizione mediante il processo di controllo integrato
Sequenzializzazione delle attivit

La sequenzializzazione delle attivit comporta l'identificazione e la documentazione
delle relazioni logiche esistenti tra le attivit schedulate. Le attivit schedulate
possono essere disposte in sequenza logica con adeguate relazioni di precedenza, cos
come le lead e lag a supporto di uno sviluppo successivo di una schedulazione di
progetto realistica ed effettivamente raggiungibile. possibile eseguire la
sequenzializzazione mediante un software di Project Management o tramite tecniche
manuali. Le tecniche manuali e automatizzate possono in ogni caso essere usate in
combinazione.
Figura 6-4. Sequenzializzazione delle attivit: Input, Strumenti e tecniche e Output
130

6.2.1
Sequenzializzazione delle attivit: Input
.1

La descrizione dell'ambito del progetto (paragrafo 5.2.3.1) contiene la descrizione
delle specifiche di prodotto, che a sua volta comprende le caratteristiche del prodotto
che spesso possono influire sulla sequenzializzazione delle attivit, come la
disposizione fisica di uno stabilimento da costruire oppure le interfacce di
sottosistema in un progetto di sviluppo software. Sebbene questi effetti appaiano
spesso evidenti nellelenco delle attivit, la descrizione delle specifiche di prodotto
in generale sottoposta a revisione al fine di essere quanto pi precisa possibile.
.2

.3

.4
Elenco delle milestone

.5
Richiesta di modifica approvata

Figura 6-5. Metodo del diagramma di precedenza

131
6.2.2
.1
Sequenzializzazione delle attivit: Strumenti e tecniche

Metodo del diagramma di precedenza (PDM)
Il PDM un metodo di costruzione di un reticolo di schedulazione del progetto che
utilizza riquadri o rettangoli, denominati nodi, per rappresentare le attivit che
connette con frecce per mostrare le dipendenze. La figura 6-5 mostra un semplice
reticolo di schedulazione del progetto disegnato utilizzando il PDM. Questa tecnica
conosciuta anche come attivit su nodo (AON) e rappresenta il metodo usato da molti
software di Project Management.
Il PDM include i quattro tipi di relazioni di dipendenza o relazioni di precedenza
Fine-inizio: l'avvio dell'attivit successore dipende dal completamento
dell'attivit predecessore.
Fine-fine: il completamento dell'attivit successore dipende dal completamento
Inizio-inizio: l'avvio dell'attivit successore dipende dall'avvio dell'attivit
predecessore.
Inizio-fine: il completamento dell'attivit successore dipende dall'avvio
Nel PDM, la relazione di dipendenza utilizzata con maggiore frequenza fineinizio. Le relazioni inizio-fine vengono invece utilizzate molto raramente.
Figura 6-6: metodo del diagramma a frecce
132

.2
Metodo del diagramma a frecce (ADM)

L'ADM il metodo che consente di costruire un reticolo di schedulazione del progetto
che utilizza le frecce per rappresentare le attivit che collega ai nodi in modo da
illustrarne le dipendenze. La figura 6-6 mostra un semplice diagramma della logica
del reticolo disegnato utilizzando lADM. Questa tecnica anche chiamata attivit su
freccia (AOA) e, sebbene meno diffusa del PDM, viene tuttora adottata
nell'insegnamento della teoria del reticolo della schedulazione e in alcune aree di
applicazione.
L'ADM utilizza soltanto le dipendenze fine-inizio e a volte necessita anche di
relazioni finte, le cosiddette attivit fittizie raffigurate mediante linee tratteggiate,
per definire correttamente tutte le relazioni logiche. Poich le attivit fittizie non sono
attivit schedulate effettive (non dispongono infatti di contenuto di lavoro), viene
assegnata loro una durata nulla ai soli fini dell'analisi del reticolo di schedulazione. Ad
esempio, nella figura 6-6 l'attivit schedulata F dipende dal completamento delle
attivit schedulate A e K, oltre che dal completamento dell'attivit schedulata
H.
.3
Schemi di documento del reticolo di schedulazione

Gli schemi di documento del reticolo di schedulazione del progetto possono essere
usati per facilitare la preparazione dei reticoli delle attivit schedulate di progetto.
Possono includere un progetto intero o solo una sua parte. Le porzioni di un reticolo di
schedulazione del progetto vengono spesso denominate anche sottoreticoli o reticoli
frammentari. Gli schemi di documento dei sottoreticoli sono particolarmente utili
quando un progetto include vari deliverable identici o molto simili, come i piani di un
grattacielo destinato a uffici, i test clinici di un progetto di ricerca farmaceutica, i
moduli del programma di codifica di un progetto di sviluppo software o la fase di
avvio di un progetto di sviluppo edilizio.
.4
Determinazione delle relazioni di dipendenza

Per la definizione della sequenza delle varie attivit vengono utilizzati i tre tipi di
relazioni di dipendenza descritti di seguito.
Relazioni di dipendenza obbligatorie: il gruppo di Project Management
stabilisce quali relazioni di dipendenza sono obbligatorie nel corso del processo
di determinazione della sequenza di attivit. Le relazioni di dipendenza
obbligatorie sono quelle intrinseche alla natura del lavoro che deve essere
svolto. Esse prevedono in genere limiti di natura fisica, come in un progetto
edile per il quale impossibile costruire una sovrastruttura fino a che non
vengono scavate le fondamenta, oppure in un progetto relativo ai componenti
elettronici in cui necessario creare un prototipo prima di poterlo collaudare. Le
relazioni di dipendenza obbligatorie talvolta vengono anche denominate: logica
rigida.

133
.5
Relazioni di dipendenza discrezionali: il gruppo di Project Management

stabilisce quali relazioni di dipendenza sono discrezionali nel corso del processo
di determinazione della sequenza di attivit. Le relazioni di dipendenza
discrezionali vengono documentate in modo esaustivo poich possono causare
valori di Total Float arbitrari e quindi limitare le successive opzioni di
schedulazione. Le relazioni di dipendenza discrezionali vengono talvolta anche
definite come logica preferita, logica preferenziale o logica debole.
Questo tipo di dipendenza viene in genere stabilito in base alla conoscenza delle
pratiche migliori all'interno di una determinata area applicativa o in base ad
alcuni aspetti insoliti del progetto che richiedono una sequenza specifica, anche
se sono disponibili altre sequenze accettabili. Alcune relazioni di dipendenza
discrezionali comprendono sequenze preferite di attivit schedulate derivanti da
esperienze precedenti relative a un progetto di successo che prevedeva un
analogo tipo di lavoro.
Relazioni di dipendenza esterne: il gruppo di Project Management identifica le
relazioni di dipendenza esterne nel corso del processo di determinazione della
sequenza delle attivit. Tali dipendenze prevedono la presenza di una relazione
tra le attivit di progetto e le attivit non incluse nel progetto. Ad esempio,
l'attivit schedulata di test prevista per un progetto di sviluppo software pu
dipendere dalla consegna di componenti hardware da fonti esterne oppure
potrebbe essere necessario attendere i risultati di indagini ambientali svolte dal
governo prima di avviare un progetto di tipo edile. Questo input pu derivare da
dati storici (paragrafo 4.1.1.4) provenienti da progetti precedenti di natura simile
o da contratti o proposte legati ai fornitori (paragrafo 12.4.3.2).
Applicazione di lead e lag

Il gruppo di Project Management determina le relazioni di dipendenza (paragrafo
6.2.2.4) che potrebbero richiedere un lead o un lag per definire in modo accurato la
relazione logica. L'utilizzo di lead e lag e i relativi assunti vengono accuratamente
documentati.
Il lead consente di accelerare l'attivit successore. Ad esempio, un gruppo di
redattori di manuali tecnici pu iniziare a lavorare alla stesura della seconda bozza di
un documento di vaste dimensioni (attivit successore) quindici giorni prima di avere
completato di redigere interamente la prima bozza dell'intero documento (attivit
predecessore). Questo avviene grazie a una relazione fine-inizio caratterizzata da un
periodo di lead di quindici giorni.
Il lag invece gestisce il ritardo in un'attivit successore. Ad esempio, per tenere
conto dei dieci giorni di solidificazione tipici del cemento, potrebbe essere applicato
un lag di dieci giorni a una relazione fine-inizio, con la conseguente impossibilit di
avviare l'attivit successore prima dei dieci giorni richiesti dopo il completamento
134

6.2.3
.1
6.3
Sequenzializzazione delle attivit: Output

Reticolo di schedulazione del progetto
I reticoli di schedulazione del progetto sono visualizzazioni schematiche delle attivit
schedulate del progetto e delle relazioni logiche che le uniscono, altrimenti
denominate relazioni di dipendenza. Le figure 6-5 e 6-6 illustrano due diversi
approcci al disegno di un reticolo di schedulazione del progetto. possibile generare
un reticolo di schedulazione del progetto sia manualmente che mediante il supporto di
un software di Project Management. Il reticolo di schedulazione del progetto pu
comprende i dettagli completi del progetto oppure una o pi attivit di riepilogo. Il
diagramma accompagnato da una descrizione di riepilogo che illustra l'approccio di
base utilizzato per la sequenzializzazione delle attivit. Tale descrizione narrativa
spiega in modo esaustivo qualsiasi sequenza di attivit insolita presente nel reticolo.
.2
Elenco delle attivit (aggiornamenti)

Se dal processo di sequenzializzazione delle attivit vengono generate delle richieste
di modifica approvate (paragrafo 4.4.1.4), l'elenco delle attivit (paragrafo 6.1.3.1)
viene aggiornato in modo da comprendere le modifiche approvate.
.3
Attributi delle attivit (aggiornamenti)

Gli attributi delle attivit (paragrafo 6.1.3.2) vengono aggiornati in modo da
comprendere le relazioni logiche definite e gli eventuali lead e lag associati. Se le
richieste di modifica approvate (paragrafo 4.4.1.4) derivanti dal processo di
sequenzializzazione delle attivit influiscono sull'elenco delle attivit, le voci correlate
incluse negli attributi delle attivit vengono aggiornate in modo da comprendere le
modifiche approvate.
.4
Modifiche richieste
La preparazione delle relazioni logiche del progetto, di lead e di lag pu rivelare la
presenza di situazioni che possono generare una modifica richiesta (paragrafo 4.4.3.2)
da apportare all'elenco delle attivit o agli attributi delle attivit. Per esempio tra questi
casi sono incluse le situazioni dove l'attivit schedulata pu essere suddivisa o
ridefinita in altro modo, dove le relazioni di dipendenza possono essere ridefinite o
dove un lead o un lag viene regolato perch rappresenti adeguatamente le corrette
relazioni logiche nel diagramma. Le modifiche richieste vengono elaborate per
l'analisi e la disposizione mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
Stima delle risorse delle attivit

La stima delle risorse delle attivit schedulate comporta la determinazione di quali
risorse utilizzare (persone, attrezzature o materiali), della quantit di ciascuna risorsa
da impiegare e di quando ogni risorsa sar disponibile per l'esecuzione delle attivit di
progetto. Il processo di stima delle risorse delle attivit strettamente collegato al
processo di stima dei costi (paragrafo 7.1). Di seguito vengono riportati alcuni esempi.
Un gruppo di progetto che si occupa di edilizia deve essere a conoscenza della
normativa locale. Le informazioni in tal senso sono generalmente disponibili
presso i fornitori del luogo. Tuttavia, se la forza lavoro locale non ha esperienza
di tecniche di costruzione insolite o altamente specializzate, il costo aggiuntivo
di un consulente pu essere il modo pi efficace per garantire la conoscenza
della normativa locale

135
Un gruppo che progetta automobili deve conoscere le pi recenti tecniche di

assemblaggio automatizzato. Tale conoscenza necessaria pu essere acquisita
assumendo un consulente, iscrivendo un progettista a un corso di robotica o
coinvolgendo un rappresentante della produzione nel gruppo di progetto
Figura 6-7. Stima delle risorse delle attivit: Input, Strumenti e tecniche e Output
6.3.1
Stima delle risorse delle attivit: Input
.1

Il processo di stima delle risorse delle attivit utilizza le informazioni sulla
disponibilit delle risorse nelle infrastrutture comprese nei fattori ambientali aziendali
(paragrafo 4.1.1.3).
.2

Gli asset dei processi organizzativi (paragrafo 4.1.1.4) forniscono i criteri adottati
dalla Performing Organization per la gestione del personale e per il noleggio o
l'acquisto di forniture e attrezzature prese in considerazione nella fase di stima delle
risorse delle attivit. Se disponibili, vengono esaminati i dati storici relativi ai tipi di
risorse necessarie per un lavoro analogo nel contesto di progetti precedenti.
.3

L'elenco delle attivit (paragrafo 6.1.3.1) identifica le attivit schedulate per le risorse
incluse nella stima.
.4

Gli attributi delle attivit (paragrafo 6.1.3.2) sviluppati nel corso del processo di
Definizione delle attivit forniscono il principale input di dati da utilizzare per la stima
delle risorse necessarie per ciascuna attivit schedulata compresa nell'elenco delle
attivit.
136

.5
Disponibilit delle risorse

Le informazioni in base alle quali le risorse (come personale, attrezzature e materiali)
risultano potenzialmente disponibili (paragrafi 9.2.3.2 e 12.4.3.4) vengono utilizzate
per la stima dei tipi di risorse. Tale conoscenza comprensiva anche delle sedi
geografiche dalle quali provengono le risorse e il periodo in cui queste possono essere
disponibili. Ad esempio, nelle fasi iniziali di un progetto di ingegneria, le risorse
disponibili potrebbero includere numerosi ingegneri di livello junior e senior. Nelle
fasi pi avanzate del progetto le risorse disponibili saranno limitate a quelle persone
che, per avervi lavorato dallinizio, conoscono a fondo il progetto.
.6

Il piano di gestione della schedulazione un componente del piano di Project
Management (paragrafo 4.3) utilizzato nella stima delle risorse delle attivit.
6.3.2
Stima delle risorse delle attivit: Strumenti e tecniche
.1
Parere di esperti
Si ricorre spesso al parere di esperti per la valutazione degli input correlati alle risorse
adottati per il processo in questione. Qualsiasi gruppo o persona con conoscenze
specializzate nella pianificazione e nella stima delle risorse pu fornire tale tipo di
competenze.
.2
Analisi delle alternative

Per molte attivit schedulate sono disponibili pi metodi di esecuzione. Tra questi si
contano l'utilizzo di diversi livelli di capacit o skill delle risorse, macchinari di
dimensioni e tipologia diverse, strumenti diversi (manuali o automatizzati) e decisioni
di tipo make-or-buy assunte in materia di risorse (paragrafo 12.1.3.3).
.3
Dati sulle stime pubblicati

Molte aziende pubblicano a cadenza regolare i valori aggiornati dei tassi di
produzione e il costo unitario delle risorse per una vasta gamma di ambiti della forza
lavoro, materiali e attrezzature in paesi diversi e in localit geografiche diverse
all'interno dei paesi.
.4
Software di Project Management

Il software di Project Management consente di pianificare, organizzare e gestire i
bacini di risorse e di svilupparne la stima. A seconda del grado di sofisticazione del
software, possibile definire le strutture di scomposizione delle risorse, la
disponibilit e i costi delle risorse, nonch il calendario delle risorse.
.5
Stima bottom-up
Se non possibile effettuare una stima dell'attivit schedulata con un livello di
affidabilit ragionevole, il lavoro previsto per l'attivit schedulata viene scomposto
ancora pi nel dettaglio. Viene effettuata la stima per ciascuna risorsa inclusa in ogni
sezione di lavoro pi bassa e dettagliata; tali stime vengono poi raggruppate nella
quantit totale di ciascuna delle risorse richieste per le attivit schedulate. Le attivit
schedulate possono o meno essere collegate da relazioni di dipendenza che
influiscono sull'applicazione e sull'utilizzo delle risorse. Se sono presenti delle
relazioni di dipendenza, questo pattern dell'utilizzo delle risorse si riflette nei requisiti
stimati dell'attivit schedulata e viene quindi documentato.

137
6.3.3
Stima delle risorse delle attivit: Output
.1
Requisiti delle risorse delle attivit

L'output del processo di stima delle risorse delle attivit rappresenta un'identificazione
e una descrizione dei tipi e delle quantit di risorse richiesti per ciascuna attivit
schedulata inclusa in un Work Package. Tali requisiti possono essere poi raggruppati
per determinare le risorse stimate di ciascun Work Package. Il volume dei dettagli e il
livello di specificit delle descrizioni dei requisiti delle risorse possono variare per
area applicativa. La documentazione sui requisiti delle risorse per ciascuna attivit
schedulata pu riportare la base di stima per ciascuna risorsa, unitamente agli assunti
formatisi in fase di determinazione di quali tipi di risorse sono applicate, della loro
disponibilit e della quantit impiegata. Il processo di sviluppo della schedulazione
(paragrafo 6.5) determina quando sono necessarie tali risorse.
.2

I tipi e le quantit di risorse necessarie per ciascuna attivit schedulata vengono
integrati negli attributi delle attivit. Se le richieste di modifica approvate (paragrafo
4.6.3.1) vengono originate dal processo di stima delle risorse delle attivit, l'elenco
delle attivit (paragrafo 6.2.3.2) e gli attributi delle attivit (paragrafo 6.2.3.3)
vengono aggiornati in modo da comprendere le modifiche approvate.
.3
Struttura di scomposizione delle risorse

La struttura di scomposizione delle risorse (RBS) una suddivisione gerarchica delle
risorse identificate per categoria e per tipo.
.4
Calendario delle risorse (aggiornamenti)

Un calendario delle risorse complessivo del progetto documenta i giorni lavorativi e i
giorni non lavorativi che determinano le date in cui una risorsa specifica, sia essa una
persona o del materiale, attiva o a riposo. Il calendario delle risorse del progetto
identifica in genere i periodi di vacanza specifici per risorse e i periodi di disponibilit
delle risorse. Il calendario delle risorse del progetto identifica la quantit di ciascuna
risorsa disponibile nel corso di ogni periodo di disponibilit.
.5
Modifiche richieste
Il processo di stima delle risorse delle attivit pu generare modifiche richieste
(paragrafo 4.4.3.2) per l'aggiunta o l'eliminazione delle attivit schedulate pianificate
presenti nell'elenco delle attivit. Le modifiche richieste vengono elaborate per
l'analisi e la disposizione mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
138

6.4
Stima della durata delle attivit

Il processo di stima della durata delle attivit schedulate utilizza informazioni relative
allambito del lavoro per le attivit schedulate, sui tipi di risorse necessarie, sulle
quantit di risorse stimate e sui calendari delle risorse con relative disponibilit. Gli
input per la stima della durata delle attivit schedulate vengono originati dalla persona
o dalla compagine appartenente al gruppo di progetto che ha pi familiarit con la
natura del contenuto del lavoro della specifica attivit schedulata. La stima della
durata viene elaborata progressivamente, e il processo considera la qualit e la
disponibilit dei dati di input. Ad esempio, con il procedere dellingegnerizzazione e il
disegno del progetto, ulteriori dati dettagliati e precisi vengono resi disponibili, e
laccuratezza della durata delle stime migliora. Pertanto, si assume che la durata della
stima progressivamente pi accurata e di migliore qualit.
Il processo di stima della durata delle attivit richiede che sia stimata la quantit
dell'impegno di lavoro richiesto al completamento dell'attivit schedulata, che sia
stimata la quantit supposta di risorse da dedicare al completamento dell'attivit
schedulata e sia determinato il numero di periodi lavorativi necessari al
completamento dell'attivit schedulata. Per ciascuna stima della durata dell'attivit
sono documentati tutti i dati e le assunzioni che ne supportano la stima.
Stimare il numero di periodi lavorativi necessari al completamento di un'attivit
schedulata pu richiedere di considerare il tempo come requisito legato a un tipo
specifico di lavoro. La maggior parte dei software di Project Management per la
schedulazione gestiscono questa situazione utilizzando un calendario di progetto e
calendari delle risorse per periodi lavorativi alternativi che sono in genere identificati
dalle risorse che richiedono specifici periodi lavorativi. Le attivit schedulate vengono
svolte in conformit al calendario di progetto,e le attivit schedulate a cui vengono
assegnate le risorse vengono svolte in base ai corrispondenti calendari delle risorse.
La durata complessiva del progetto calcolata come output del Processo di
Sviluppo della Schedulazione (Paragrafo 6.5).
Figura 6-8. Stima della durata delle attivit: Input, Strumenti e tecniche e Output

139
6.4.1
Stima della durata delle attivit: Input
.1

Una o pi organizzazioni partecipanti al progetto pu mantenere dei database delle
stime delle durate e altri dati storici di riferimento. Questo tipo di informazioni di
riferimento sono disponibili commercialmente. Questi database tendono ad essere
particolarmente utili quando la durata delle attivit indipendente dal contenuto reale
del lavoro (ad esempio, il tempo di indurimento del cemento, quanto unagenzia
governativa richiede per rispondere a certi tipi di richiesta).
.2

I dati storici (paragrafo 4.1.1.4) sulle probabili durate di numerose categorie di attivit
sono spesso disponibili. Una o pi organizzazioni impegnate nel progetto possono
mantenere dati sui risultati di progetti precedenti che sono sufficientemente dettagliati
da essere di aiuto per la determinazione delle stime di durata. In alcune aree
applicative, i singoli membri del gruppo possono aggiornare queste registrazioni. Gli
asset dei processi organizzativi (paragrafo 4.1.1.4) della Performing Organization
possono avere alcuni asset item che possono essere usati per la Stima della Durata
delle Attivit, ad esempio i calendari di progetto (un calendario dei giorni lavorativi o
dei turni nei quali viene effettuato il lavoro delle attivit schedulate e dei giorni non
lavorativi nei quali le attivit schedulate vengono sospese).
.3

I vincoli e le assunzioni derivanti dall'ambito del progetto (paragrafo 5.2.3.1) devono
essere considerati quando si stima la durata delle attivit schedulate. Un esempio di
assunto potrebbe essere la lunghezza dei periodi di reporting per il progetto che
possono imporre durate massime per le attivit schedulate. Un esempio di vincolo
dato dalla consegna di un documento, revisione e da altre attivit schedulate simili,
classificabili come non-deliverable che sono spesso caratterizzate da frequenza e
durata specificate da contratto o conformi alle politiche dalla Performing
Organization.
.4

.5

.6

I requisiti delle risorse relativi le attivit stimate (paragrafo 6.3.3.1) influiscono sulla
durata dell'attivit schedulata, in quanto le risorse assegnate all'attivit schedulata e la
loro disponibilit influenzano significativamente la durata della maggior parte delle
attivit. Per esempio, se un'attivit schedulata richiede l'intervento simultaneo di due
ingegneri per il completare efficientemente un'attivit di progettazione, ma in realt
una sola persona assegnata al lavoro, l'attivit schedulata generalmente durer
almeno il doppio per essere completata. Ciononostante, non appena sono aggiunte ad
alcune attivit schedulate altre risorse o sono assegnate risorse con skill inferiori, i
progetti possono subire un calo di efficienza; tale inefficienza, a sua volta, potrebbe
poi portare a un incremento della produttivit inferiore allincremento percentuale
delle risorse assegnate.
140

.7
Calendario delle risorse

Il calendario delle risorse complessive (paragrafo 6.3), sviluppato come parte del
processo di Stima delle Risorse delle Attivit, include la disponibilit, capacit e skill
delle risorse umane (paragrafo 9.2) Deve essere anche considerato il tipo, la quantit,
la disponibilit e la capacit, se pertinente, delle risorse sia in termini di attrezzature
sia di materiali (paragrafo 12.4) che possono influire in modo significativo sulla
durata delle attivit schedulate. Ad esempio, se un dipendente di livello senior e uno
di livello junior sono assegnati a tempo pieno, pi probabile che il primo completi
una certa attivit schedulata in minor tempo rispetto al secondo.
.8

Il piano di Project Management contiene il registro dei rischi (paragrafi da 11.2 a
11.6) e la stima dei costi del progetto (paragrafo 7.1).
Registro dei rischi: il registro dei rischi contiene informazioni sui rischi di
progetto identificati, di cui il gruppo di progetto deve tener conto nella fase di
stima della durata delle attivit e delladeguamento di queste in funzione dei
rischi. Il gruppo di progetto considera fino a che punto gli effetti dei rischi sono
inclusi nella stima della durata della baseline per ciascuna attivit schedulata, in
particolare quei rischi con elevata probabilit e elevato impatto.
Stime dei costi delle attivit: le stime dei costi delle attivit di progetto, se sono
state gi completate, possono essere sviluppate con dettagli sufficienti a fornire
le quantit di risorse stimate per ciascuna attivit schedulata inclusa nell'elenco
delle attivit di progetto.
6.4.2
Stima della durata delle attivit: Strumenti e tecniche
.1
Parere di esperti
La durata delle attivit sono spesso difficili da stimare a causa del numero di fattori
che possono influenzarle, come il livello o la produttivit delle risorse. Il parere di
esperti, supportato da informazioni storicizzate, pu essere usato ove possibile. I
membri del gruppo di progetto possono inoltre fornire informazioni sulla stima delle
durate o il limite massimo consigliato per le durate delle attivit derivanti da progetti
simili. Se tali competenze non sono disponibili, le stime delle durate sono meno sicure
e pi rischiose.
.2
Stima per analogia

La stima per analogia delle durate prevede l'utilizzo della durata effettiva di simili
attivit schedulate effettuate in precedenza come base per la stima della durata di una
futura attivit schedulata. Questa stima utilizzata frequentemente per valutare la
durata del progetto quando si dispone di scarse informazioni dettagliate sul progetto
per esempio, come avviene nella fase iniziale. La stima per analogia utilizza i dati
storici (paragrafo 4.1.1.4) e il parere di esperti.
La stima per analogia della durata pi affidabile quando le attivit precedenti
sono simili nella sostanza e non solo nella forma e se i membri del gruppo di progetto
che predispongono le stime posseggono le competenze necessarie.

141
.3
Stima parametrica
La base di stima per la durata delle attivit pu essere quantitativamente determinata
moltiplicando la quantit di lavoro da eseguire per il tasso di produttivit. Ad esempio,
i tassi di produttivit di un progetto architettonico possono essere stimati sulla base del
numero di disegni moltiplicato per le ore lavorative richieste per disegno oppure
l'installazione di cavi in base ai metri di cavo moltiplicati per le ore lavorative
richieste per metro. Le quantit di risorse complessive sono moltiplicate per le ore
lavorative per periodo lavorativo o la capacit di produzione per periodo lavorativo,
quindi si divide il risultato per il numero di risorse assegnate per determinare la durata
dell'attivit in periodi lavorativi.
.4
Stima a tre punti

L'accuratezza della stima della durata delle attivit pu essere incrementata prendendo
in considerazione la quantit di rischio nella stima originale. Le stime a tre punti si
basano sulla determinazione dei tre tipi di stima:
Pi probabile: durata dell'attivit schedulata, date le risorse che probabilmente
verranno assegnate, la loro produttivit, le aspettative realistiche in termini di
disponibilit per l'attivit schedulata, le relazioni di dipendenza da altri
partecipanti e le interruzioni.
Ottimistico: la durata dell'attivit si basa sullo scenario migliore relativamente a
quanto descritto nella stima pi probabile.
Pessimistico: la durata dell'attivit si basa sullo scenario peggiore relativamente
a quanto viene descritto nella stima pi probabile.
Una stima della durata dell'attivit pu essere costruita utilizzando una media
delle tre durate stimate. Questa media fornisce in genere una stima pi accurata della
durata dell'attivit rispetto a una stima pi probabile a valore singolo.
.5
Analisi della riserva

I gruppi di progetto possono scegliere di incorporare tempo aggiuntivo, riferito come
riserve per contingency, riserve di tempo o buffer, nella schedulazione di progetto
complessiva come riconoscimento per il rischio della schedulazione. La riserva per
contingency pu essere una percentuale della durata dell'attivit stimata, un numero
fisso di periodi lavorativi o sviluppata mediante l'analisi quantitativa del rischio della
schedulazione (paragrafo 11.4.2.2.). La riserva per contingency pu essere utilizzata
completamente o in parte, o pu essere ridotta o eliminata non appena si rendono
disponibili informazioni pi precise sul progetto. Tale riserva per contingency
documentata unitamente ad altri dati correlati e assunti.
6.4.3
.1
Stima della durata delle attivit: Output

Stime della durata dell'attivit
Le stime della durata dell'attivit sono valutazioni quantitative di un numero probabile
di periodi lavorativi necessari per completare un'attivit schedulata. Le stime della
durata dell'attivit includono delle indicazioni dell'intervallo dei risultati possibili. Per
esempio:
2 settimane 2 giorni per indicare che lattivit schedulata necessiter di
almeno otto giorni e di non pi di dodici (ipotizzando una settimana lavorativa
di cinque giorni).
15% di probabilit di superare tre settimane per indicare unelevata probabilit 85% - che lattivit schedulata necessiter tre settimane o meno.
142

.2
6.5

Gli attributi delle attivit (paragrafo 6.1.3.2) sono aggiornati per includere la durata
per ogni attivit schedulata, gli assunti fatti durante lo sviluppo delle stime della
durata dell'attivit ed eventuali riserve per contingency.
Sviluppo della schedulazione

Lo sviluppo della schedulazione di progetto, un processo iterativo, determina la data
d'inizio e di fine pianificata per le attivit di progetto. Lo sviluppo della schedulazione
pu richiedere la rianalisi e la revisione delle stime della durata e delle risorse per
creare una schedulazione di progetto approvata che funge come baseline rispetto alla
quale possibile tracciare l'avanzamento. Lo sviluppo della schedulazione prosegue
per l'intero progetto mano a mano che il lavoro avanza, che il piano di Project
Management cambia e che gli eventi di rischio attesi si verificano o si annullano con
l'identificazione di nuovi rischi.
Figura 6-9. Visione d'insieme dello sviluppo della schedulazione: Input, Strumenti e
tecniche e Output
6.5.1
Sviluppo della schedulazione: Input
.1

Gli asset dei processi organizzativi (paragrafo 4.1.1.4) della Performing Organization
possono avere elementi per lo sviluppo della schedulazione, come i calendari di
progetto (un calendario dei giorni e dei turni lavorativi che stabilisce le date in cui
viene effettuato il lavoro delle attivit schedulate e dei giorni non lavorativi in cui le
attivit schedulate sono sospese).
.2

La descrizione dell'ambito del progetto (paragrafo 5.2.3.1) contiene gli assunti e i
vincoli che possono influire sullo sviluppo della schedulazione di progetto. Gli assunti
sono quei fattori documentati relativi alla schedulazione che, ai fini dello sviluppo
della schedulazione, sono considerati come veri, reali o certi. I vincoli sono fattori che
limitano le opzioni disponibili al gruppo di Project Management nell'esecuzione
dell'analisi del reticolo di schedulazione.
Ci sono due categorie principali di vincoli temporali da considerare durante lo
sviluppo della schedulazione:

143
Le date imposte dinizio o di fine delle attivit possono essere utilizzate per
limitare loccorrenza dellinizio o della fine, affinch non sia antecedente una
specifica data o non oltre una specifica data. Anche se nei software di Project
Management sono disponibili numerosi vincoli, quelli che impongono linizio
non prima di e la fine non oltre il sono i pi comunemente usati. I vincoli per
le date comprendono quelle situazioni di date concordate da contratto, finestra di
mercato in un progetto tecnologico, limitazioni atmosferiche per le attivit
allaperto, conformit a obblighi governativi per le normative ambientali e
consegna di materiale da parte di soggetti non rappresentati nella schedulazione
di progetto.
Lo sponsor del progetto, il cliente del progetto o gli altri stakeholder richiedono
spesso eventi o milestone fondamentali che influiscono sul completamento di
alcuni deliverable per una data specificata. Una volta inserite nella
schedulazione, queste date diventano vincolanti e possono essere spostate
soltanto mediante modifiche approvate. Le milestone possono anche essere
utilizzate per indicare le interfacce con attivit esterne al progetto. In genere, tali
attivit non vengono incluse nel database di progetto e linserimento di
milestone con date imposte pu fornire un'adeguata interfaccia di schedulazione.
.3

.4

.5
Reticoli di schedulazione del progetto

.6

.7
Calendario delle risorse

.8
Stime della durata dell'attivit

.9

Il piano di Project Management contiene il piano di gestione della schedulazione, il
piano di gestione dei costi, il piano di gestione dell'ambito del progetto e il piano di
gestione dei rischi. Tali piani guidano lo sviluppo della schedulazione e quei
componenti che supportano il processo di sviluppo della schedulazione. Uno di questi
componenti il registro dei rischi.
Registro dei rischi: il registro dei rischi (paragrafi da 11.1 a 11.5) identifica i
rischi del progetto e i corrispondenti piani di risposta ai rischi necessari a
supportare il processo di sviluppo della schedulazione.
144

6.5.2
.1
Sviluppo della schedulazione: Strumenti e tecniche

Analisi del reticolo di schedulazione
L'analisi del reticolo di schedulazione una tecnica che genera una schedulazione di
progetto. Si avvale di un modello di schedulazione e di varie tecniche analitiche, come
il metodo del percorso critico, il metodo del Critical Chain, l'analisi what-if e il
livellamento delle risorse per calcolare le date di inizio e di fine minime e massime e
le date di inizio e di fine schedulate per le parti non complete delle attivit schedulate
del progetto. Se il reticolo di schedulazione utilizzato nel modello caratterizzato da
anelli del reticolo o estremit aperte del reticolo, tali anelli ed estremit devono essere
eliminate prima che siano applicate tecniche analitiche. Alcuni percorsi del reticolo
possono avere dei punti di convergenza o di divergenza di percorsi che possono essere
identificati ed utilizzati nell'analisi della compressione della schedulazione o in altre
analisi.
.2
Metodo del percorso critico

Il metodo del percorso critico una tecnica di analisi del reticolo di schedulazione
eseguita utilizzando il modello di schedulazione. Il metodo del percorso critico calcola
a livello teorico le date di inizio e di fine minime e le date di inizio e di fine massime
per tutte le attivit schedulate, senza prendere in considerazione eventuali limiti delle
risorse, tramite l'esecuzione dell'analisi del calcolo in avanti e del calcolo a ritroso per
tutti i percorsi del reticolo delle schedulazioni di progetto. Le date di inizio e di fine
minime e massime derivanti dal calcolo non corrispondono necessariamente alla
schedulazione di progetto; esse indicano piuttosto i periodi entro i quali dovrebbe
essere pianificata l'attivit schedulata, data la durata dell'attivit, le relazioni logiche, i
lead, i lag e gli altri vincoli conosciuti.
Le date di inizio e di fine minime e massime calcolate possono e meno
coincidere con i percorsi del reticolo poich il Total Float, che definisce la flessibilit
della schedulazione, pu essere positivo, negativo o zero. In qualsiasi percorso del
reticolo, la flessibilit della schedulazione viene misurata mediante la differenza
positiva tra le date di inizio e di fine minime e viene denominata Total Float. I
percorsi critici sono caratterizzati da un Total Float pari a zero o negativo, mentre le
attivit schedulate su un percorso critico vengono denominate attivit critiche. Gli
adeguamenti alla durata dell'attivit, alle relazioni logiche, ai lead e ai lag o ad altri
vincoli della schedulazione possono essere necessari per produrre dei percorsi del
reticolo con un Total Float pari a zero o positivo. Quando un Total Float del percorso
del reticolo pari a zero o positivo, possibile determinare il Free Float - la quantit di
tempo che un'attivit schedulata pu essere ritardata senza posticipare la data di inizio
minima di eventuali attivit del successore immediato all'interno del percorso del
reticolo.
.3
Compressione della schedulazione

La compressione della schedulazione riduce la schedulazione di progetto senza
modificare l'ambito del progetto, per soddisfare vincoli della schedulazione, date
imposte o altri obiettivi della schedulazione. Le tecniche di compressione della
schedulazione includono:
Compressione dei tempi (Crashing): tecnica di compressione della
schedulazione in cui si analizzano i compromessi tra costi e tempi per
determinare come ottenere la massima compressione al costo incrementale pi
basso. La compressione dei tempi pu non fornire sempre unalternativa
percorribile e spesso produce un incremento dei costi

145
Fast Tracking: tecnica di compressione della schedulazione nella quale fasi o

attivit che normalmente vengono svolte in sequenza sono eseguite in parallelo.
Un esempio di tale tecnica dato dalla costruzione delle fondamenta di un
edificio prima che di tutti i disegni architettonici siano completati. Il Fast
Tracking pu comportare rilavorazione e incremento del rischio. Questo
approccio pu richiedere lesecuzione del lavoro senza informazioni dettagliate
e complete, come i disegni tecnici. Ne derivano dei costi commerciali per il
tempo e un incremento del rischio legato allaccorciamento della schedulazione
di progetto.
.4
Analisi di scenari ipotetici (what-if)

Questa unanalisi che risponde alla domanda cosa accade se si verifica la situazione
rappresentata dallo scenario 'X'? Un'analisi del reticolo di schedulazione eseguita
utilizzando il modello di schedulazione per stimare i diversi scenari, come il ritardare
la consegna di un componente principale, l'estensione delle durate di specifiche
progettazioni o l'introduzione di fattori esterni quali uno sciopero o una modifica al
processo di concessione dei permessi edilizi. Il risultato della analisi dello scenario
what-if pu essere utilizzato per valutare la fattibilit della schedulazione di progetto
in condizioni avverse e nella preparazione di piani di contingency e risposta per
contrastare o contenere limpatto di situazioni inattese. La simulazione comporta il
calcolo di pi durate del progetto con diverse combinazioni di assunti sulle attivit. La
tecnica pi diffusa l'analisi Monte Carlo (paragrafo 11.4.2.2), nella quale la
distribuzione delle possibili durate dell'attivit definita per ogni attivit schedulata e
utilizzata per calcolare una distribuzione dei risultati possibili per il progetto nel suo
complesso.
.5
Livellamento delle risorse

Il livellamento delle risorse una tecnica di analisi del reticolo di schedulazione
applicata a un modello di schedulazione che gi stato analizzato mediante il metodo
del percorso critico. Il livellamento delle risorse usato per indirizzare le attivit
schedulate che devono essere eseguite per rispettare le date di consegna, di indirizzare
le situazioni in cui le risorse necessarie condivise o critiche sono disponibili soltanto
in determinati periodi o in quantit ridotte o di conservare l'utilizzo delle risorse
selezionate a un livello costante per determinati periodi del lavoro di progetto. Questo
approccio di livellamento dell'utilizzo delle risorse pu causare cambiamenti al
percorso critico originale.
146

Il calcolo del metodo del percorso critico (paragrafo 6.5.2.2) produce una
schedulazione di inizio minima e una schedulazione di fine massima preliminare che,
potrebbero richiedere una quantit di risorse superiore, in alcuni periodi, a quella
disponibile o delle modifiche ai livelli di risorse non gestibili. La distribuzione di
risorse insufficienti sulle attivit del percorso critico pu consentire inizialmente di
sviluppare una schedulazione di progetto che rifletta tali vincoli. Il livellamento delle
risorse comporta spesso una durata del progetto maggiore rispetto alla schedulazione
preliminare di progetto. Questa tecnica denominata a volte metodo basato sulle
risorse, soprattutto quando viene implementata mediante il software di Project
Management per l'ottimizzazione della schedulazione. La riallocazione delle risorse
dalle attivit non critiche alle attivit critiche un metodo comune per riportare
quanto pi possibile la durata complessiva del progetto, o il pi vicino possibile, alla
durata originariamente prevista. inoltre possibile prendere in considerazione
l'utilizzo di ore di lavoro straordinario, fine settimana o pi turni lavorativi per le
risorse selezionate usando i calendari delle risorse per ridurre le durate delle attivit
critiche. Gli incrementi nella produttivit delle risorse rappresentano un altro modo
per abbreviare quelle durate che risultano superiori alla schedulazione di progetto
originale. Tecnologie o macchinari diversi, come il riutilizzo del codice, la saldatura
automatica, il tagliatubi elettrico e i processi automatizzati incidono tutti sulla
produttivit delle risorse. Alcuni progetti dispongono di risorse finite e critiche. In tal
caso, la risorsa schedulata a ritroso a partire dalla data di fine del progetto, nota
come procedura di schedulazione a ritroso dell allocazione delle risorse, che pu
risultare in una schedulazione di progetto non ottimale. La tecnica di livellamento
delle risorse produce una schedulazione a risorse limitate, chiamata a volte
schedulazione vincolata dalle risorse, con date dinizio schedulate e date di fine
schedulate.
.6
Metodo del Critical Chain

Il metodo del Critical Chain un'altra tecnica di analisi del reticolo di schedulazione
che modifica la schedulazione di progetto per tenere conto di risorse limitate. Il
Critical Chain unisce l'approccio deterministico e quello probabilistico. Inizialmente,
si crea il reticolo di schedulazione del progetto mediante stime non conservative per la
durata delle attivit all'interno del modello di schedulazione, con le dipendenze
richieste e i vincoli definiti come input. Viene quindi calcolato il percorso critico.
Dopo avere identificato il percorso critico, valorizzata la disponibilit delle risorse e
si determina il risultato della schedulazione a risorse limitate. La schedulazione
ottenuta ha spesso un percorso critico alterato.
Il metodo del Critical Chain aggiunge buffer di durata, rappresentate da attivit
schedulate non lavorative, per mantenere sempre l'attenzione sulle durate dell'attivit.
Dopo avere determinato le attivit di buffer schedulate, le attivit pianificate vengono
schedulate alle date di inizio e fine pi lontane possibile. Ne consegue che invece di
gestire il Total Float dei percorsi del reticolo, il metodo del Critical Chain si concentra
sulla gestione delle durate dell'attivit di buffer e sulle risorse applicate alle attivit
schedulate previste.

147
.7

Il software di Project Management per la schedulazione uno strumento molto diffuso
come supporto allo sviluppo della schedulazione. Altri software sono in grado di
interagire direttamente o indirettamente con il software di Project Management per
soddisfare i requisiti di altre aree di conoscenza, come la stima dei costi per periodi di
tempo (paragrafo 7.1.2.5) e la simulazione della schedulazione nell'analisi quantitativa
del rischio (paragrafo 11.4.2.2). Questi prodotti automatizzano il calcolo matematico
del percorso critico in avanti e a calcolo a ritroso e nel livellamento delle risorse, e
quindi consentono di prendere rapidamente in considerazione varie alternative di
schedulazione. Sono inoltre comunemente utilizzati per la stampa e la visualizzazione
degli output ottenuti dalle schedulazioni sviluppate.
.8
Applicazione dei calendari

I calendari di progetto (paragrafo 4.1.1.4) e i calendari delle risorse (paragrafo 6.3.3.4)
identificano i periodi in cui possibile effettuare il lavoro. I calendari di progetto
influiscono su tutte le attivit. Ad esempio, potrebbe non essere possibile lavorare in
un dato luogo in certi periodi dell'anno a causa delle condizioni atmosferiche. I
calendari delle risorse incidono su risorse o su categorie di risorse specifiche. I
calendari delle risorse rispecchiano il modo in cui alcune risorse effettuano il proprio
lavoro soltanto nel corso delle ore lavorative mentre altre sono attive per tre turni
completi, o se un membro del gruppo di progetto non disponibile perch in vacanza
o iscritto a un programma di formazione o se un contratto di lavoro limita alcuni
dipendenti ad essere attivi in determinati giorni della settimana.
.9
Adeguamento di lead e lag

Poich un uso non adeguato di lead e lag pu falsare la schedulazione di progetto, i
lead e i lag vengono adeguati nel corso dell'analisi del reticolo di schedulazione per
sviluppare una schedulazione di progetto attuabile.
.10
Modello di schedulazione
I dati e le informazioni della schedulazione vengono inseriti nel modello di
schedulazione del progetto. Lo strumento del modello di schedulazione e i dati di
supporto del modello di schedulazione sono utilizzati unitamente a metodi manuali o
al software di Project Management per eseguire l'analisi del reticolo di schedulazione
per generare la schedulazione di progetto.
148

6.5.3
.1
Sviluppo della schedulazione: Output

Schedulazione di progetto
La schedulazione di progetto comprende almeno una data dinizio pianificata e una
data di fine pianificata per ciascuna attivit schedulata. Se la pianificazione delle
risorse viene effettuata in una delle prime fasi, la schedulazione di progetto viene
considerata preliminare fino a quando le assegnazioni delle risorse sono state
confermate e le date dinizio e di fine schedulate sono state fissate. Questo processo
avviene in genere non oltre il completamento del piano di Project Management
(paragrafo 4.3). Una schedulazione obiettivo di progetto sviluppabile anche con date
obiettivo di inizio e date obiettivo di fine definite per ciascuna attivit schedulata. La
schedulazione di progetto pu essere presentata anche in forma riepilogativa, a volte
definita anche schedulazione principale o schedulazione delle milestone, o in forma
dettagliata. Sebbene sia possibile presentarla sotto forma di tabella, pi
comunemente presente in forma grafica, usando uno o pi dei seguenti formati:
Reticoli di schedulazione del progetto: questi diagrammi, dotati di
informazioni sulle date delle attivit, mostrano in genere sia la logica del
reticolo del progetto che le attivit schedulate del percorso critico di progetto.
Questi diagrammi possono essere presentati sia nel formato attivit su nodo,
come mostrato nella figura 6-5, sia nel formato reticolare della schedulazione su
scala temporale, a volte denominato diagramma a barre logico, come mostrato
per la schedulazione dettagliata nella figura 6-10. Questo esempio mostra inoltre
la pianificazione di ciascun Work Package come una serie di attivit schedulate
correlate.
Diagrammi a barre: tali diagrammi, dove le barre rappresentano alle attivit,
mostrano le date di inizio e di fine delle attivit unitamente alle durate attese. I
diagrammi a barre sono di facile lettura e per questo vengono utilizzati
frequentemente nelle presentazioni della direzione. Per il controllo e le
comunicazioni di gestione, la pi generale, pi esauriente attivit sintesi, talvolta
referenziata come attivit sommario, utilizzata tra milestone o attraverso work
package multipli indipendenti, ed illustrata tramite diagrammi a barre. Un
esempio della porzione di schedulazione riepilogativa di figura 6-10 riportato
nel formato strutturato di WBS.
Diagrammi delle milestone: questi diagrammi sono simili ai diagrammi a
barre, ma identificano soltanto l'avvio o il completamento schedulati dei
principali deliverable e delle interfacce esterne pi importanti. Un esempio la
porzione della schedulazione delle milestone figura 6-10.

149
Figura 6-10. Schedulazione di progetto: esempi di grafici
150

La figura 6-10 mostra la schedulazione di un progetto campione in fase di

esecuzione, il cui avanzamento del lavoro viene registrato mediante la data di
aggiornamento, denominata anche data di avanzamento o data corrente. La figura
illustra la data dinizio effettiva, la durata effettiva e la data di fine effettiva delle
attivit schedulate completate, la data dinizio effettiva, la durata residua e la data di
fine attuale delle attivit schedulate con il lavoro in fase di esecuzione e la data
dinizio attuale, la durata originale e la data di fine attuale delle attivit schedulate il
cui lavoro non stato ancora avviato. Per una schedulazione di progetto semplice, la
figura 6-10 mostra una rappresentazione grafica di una schedulazione delle milestone,
una schedulazione di riepilogo e una schedulazione dettagliata. Nella figura 6-10 sono
inoltre mostrate graficamente le relazioni tra i tre diversi livelli di presentazione della
schedulazione.
.2
Dati del modello di schedulazione

I dati di supporto per la schedulazione di progetto comprendono almeno le milestone
di schedulazione, le attivit schedulate, gli attributi delle attivit e la documentazione
di tutti gli assunti e i vincoli identificati. La quantit di dati aggiuntivi varia in base
allarea applicativa. Le informazioni fornite frequentemente come dettagli di supporto
includono almeno:
Requisiti di risorse per periodo, in genere sotto forma di istogramma delle
risorse.
Schedulazioni alternative, come la migliore (best-case) o la peggiore (worstcase) delle ipotesi, senza risorse livellate, con risorse livellate, con o senza le
date imposte.
Riserve per contingency della schedulazione.
Ad esempio, in un progetto di elettronica, i dati del modello di schedulazione
possono comprendere le voci quali istogramma delle risorse umane, proiezioni del
flusso di cassa e schedulazioni di ordini e consegne.
.3
Baseline della schedulazione

Una baseline della schedulazione una versione specifica della schedulazione di
progetto sviluppata a partire dall'analisi del reticolo di schedulazione del modello di
schedulazione. Questa viene poi accettata e approvata dal gruppo di Project
Management come baseline della schedulazione con date di inizio di baseline e date di
fine di baseline.
.4
Requisiti delle risorse (aggiornamenti)

Il livellamento delle risorse pu influire in modo significativo sulle stime preliminari
dei tipi e delle quantit delle risorse necessarie. Se l'analisi del livellamento delle
risorse modifica i requisiti delle risorse di progetto, allora i requisiti delle risorse
vengono aggiornati.
.5

Gli attributi delle attivit (paragrafo 6.2.3.3) sono aggiornati in modo da comprendere
qualsiasi requisito delle risorse rivisto e le altre modifiche approvata (paragrafo
4.4.1.4) generati dal processo di sviluppo della schedulazione.

151
6.6
.6
Calendario di progetto (aggiornamenti)

Un calendario di progetto un calendario dei giorni lavorativi e dei turni che stabilisce
le date in cui viene effettuato il lavoro previsto per le attivit schedulate. Stabilisce
inoltre i giorni non lavorativi che determinano le date in cui le attivit schedulate sono
sospese, come vacanze, fine settimana e ore di riposo da turno. Il calendario di ciascun
progetto pu utilizzare unit temporali diverse come base per la schedulazione del
progetto.
.7
Il processo di sviluppo della schedulazione pu generare delle richieste di modifica
(paragrafo 4.4.3.2) che sono elaborate per la revisione e la disposizione attraverso il
processo di controllo integrato delle modifiche (paragrafo 4.6).
.8

Il piano di Project Management (paragrafo 4.3) viene aggiornato affinch rispecchi
qualsiasi modifica approvata in merito alla modalit di Project Management.
Piano di gestione della schedulazione (aggiornamenti): se le richieste di
modifica approvate (paragrafo 4.4.1.4) derivano dai processi di gestione dei
tempi di progetto, allora il piano di gestione della schedulazione (materiale
introduttivo del capitolo 6) componente del piano di Project Management
potrebbe essere aggiornato (paragrafo 4.3) in modo che comprenda tali
modifiche approvate.
Controllo della schedulazione

Il controllo della schedulazione comprende:
Determinare lo stato attuale della schedulazione di progetto.
Influire sui fattori che creano modifiche della schedulazione.
Determinare se la schedulazione di progetto stata modificata.
Gestire la modifiche effettive nel momento in cui si verificano.
Il controllo della schedulazione fa parte del processo di controllo integrato delle
Figura 6-11. Panoramica del controllo della schedulazione: Input, Strumenti e tecniche e
Output
152

6.6.1
Controllo della schedulazione Input
.1
Piano di gestione della schedulazione

Il piano di Project Management (paragrafo 4.3) contiene il piano di gestione della
schedulazione (materiale introduttivo del capitolo 6) che stabilisce come la
schedulazione di progetto viene gestita e controllata.
.2
Baseline della schedulazione

La schedulazione di progetto (paragrafo 6.5.3.1) utilizzata per il controllo rappresenta
la schedulazione di progetto approvata, denominata anche baseline della
schedulazione (paragrafo 6.5.3.3). La baseline della schedulazione un componente
del piano di Project Management (paragrafo 4.3). Costituisce la base per la
misurazione e il reporting delle prestazioni della schedulazione nell'ambito della
baseline di misurazione delle prestazioni.
.3

I report sulle prestazioni (paragrafo 10.3.3.1) forniscono informazioni sulle
prestazioni della schedulazione, ad es. quali date pianificate sono state rispettate e
quali no. I report sulle prestazioni avvisano anche il gruppo di progetto di eventuali
questioni che possono in futuro causare problemi per le prestazioni della
schedulazione.
.4

Solamente le richieste di modifica approvate (paragrafo 4.4.1.4) che sono state
precedentemente elaborate mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6) sono utilizzate per aggiornare la baseline della schedulazione di
progetto o altri componenti del piano di Project Management. (paragrafo 4.3) .
6.6.2
Controllo della schedulazione: Strumenti e tecniche
.1
Reporting dell'avanzamento
Il reporting dell'avanzamento e lo stato della schedulazione attuale comprendono
informazioni quali le date di inizio e di fine effettive e le durate residue per le attivit
schedulate non completate. Se viene adottata anche una misurazione dell'avanzamento
come l'Earned Value, allora possibile includere anche la percentuale di
completamento delle attivit schedulate in fase di esecuzione. Per facilitare il
reporting periodico dell'avanzamento del progetto, possibile adottare per tutto il
ciclo di vita del progetto uno schema di documento creato per garantire l'uso
omogeneo nei vari componenti organizzativi del progetto. Lo schema di documento
pu essere sia in formato cartaceo che elettronico.
.2
Sistema di controllo delle modifiche della schedulazione

Il sistema di controllo delle modifiche alla schedulazione definisce le procedure da
seguire per modificare la schedulazione di progetto. Esso include i documenti, i
sistemi di tracciamento e i livelli di approvazione necessari per lautorizzazione alle
modifiche. Il sistema di controllo delle modifiche alla schedulazione opera come parte
del processo di controllo integrato delle modifiche (paragrafo 4.6).

153
.3
Misurazione delle prestazioni

Le tecniche di misurazione delle prestazioni forniscono i valori di scostamento dei
tempi (SV) (paragrafo 7.3.2.2) e di indice di efficienza della schedulazione (SPI)
(paragrafo 7.3.2.2) che sono utilizzati per valutare la portata di tutte le variazioni della
schedulazione di progetto verificatesi. Una parte importante del controllo della
schedulazione consiste nel decidere se un eventuale scostamento dalla schedulazione
richiede o meno azioni correttive. Ad esempio, un ritardo rilevante su qualsiasi attivit
schedulata non appartenente al percorso critico pu incidere in misura ridotta sulla
schedulazione di progetto complessiva, mentre un ritardo molto inferiore su un'attivit
critica o quasi critica potrebbe richiedere un intervento immediato.
.4

Il software di Project Management per la schedulazione fornisce la capacit di
individuazione delle date pianificate rispetto alle date effettive e di previsione degli
effetti delle modifiche alla schedulazione di progetto, reali o potenziali, rivelandosi
quindi un valido strumento per il controllo della schedulazione.
.5
Analisi dello scostamento

L'esecuzione dell'analisi dello scostamento dei tempi nel corso del processo di
monitoraggio della schedulazione rappresenta una funzione essenziale del controllo
della schedulazione. Il confronto tra le date della schedulazione obiettivo e le date di
inizio e di fine effettive/previste fornisce informazioni utili per il rilevamento degli
scostamenti dal piano e limplementazione di azioni correttive in caso di ritardi. Lo
scostamento del Total Float costituisce un ulteriore componente essenziale per la
valutazione dellandamento dei tempi di progetto.
.6
Diagrammi a barre del confronto delle schedulazioni

Per facilitare l'analisi dell'avanzamento della schedulazione, consigliabile utilizzare
un diagramma a barre di confronto composto da due barre per ciascuna attivit
schedulata. Una barra rappresenta lo stato effettivo attuale e l'altra lo stato della
baseline della schedulazione di progetto approvata. Questo mostra graficamente dove
la schedulazione avanzata come pianificato o dove si sono verificati dei
rallentamenti.
6.6.3
.1
Controllo della schedulazione: Output

Dati del modello di schedulazione (aggiornamenti)
L'aggiornamento alla schedulazione di progetto dato da qualsiasi modifica alle
informazioni sul modello di schedulazione di progetto utilizzato per la Project
Management. Agli stakeholder interessati sono notificate le modifiche significative
nel momento in cui si verificano.
Nuovi reticoli di schedulazione del progetto sono sviluppati per visualizzare le
durate residue approvate e le modifiche apportate al piano di lavoro. In alcuni casi, i
ritardi della schedulazione di progetto possono essere tanto gravi da rendere
necessario lo sviluppo di una nuova schedulazione obiettivo con date obiettivo di
inizio e di fine riviste; l'obiettivo ottenere dati realistici che consentano di indirizzare
il lavoro e di misurare le prestazioni e l'avanzamento del progetto.
154

.2
Baseline della schedulazione (aggiornamenti)

Le revisioni della schedulazione sono una categoria speciale di aggiornamenti della
schedulazione di progetto. Le revisioni sono cambiamenti che comportano modifiche
alle date di inizio e di fine della schedulazione inserite nella baseline della
schedulazione approvata. Tali modifiche vengono in genere inserite nella risposta alle
richieste di modifica approvate (paragrafo 4.4.1.4) relative alle modifiche da apportare
all'ambito del progetto o alle stime. Lo sviluppo di una baseline della schedulazione
rivista pu verificarsi soltanto come risultato di modifiche approvate. La baseline
originale della schedulazione e il modello di schedulazione vengono salvati prima
della creazione della nuova baseline della schedulazione per evitare la perdita di dati
storici della schedulazione di progetto.
.3
Misurazioni delle prestazioni

I valori calcolati per scostamento dei tempi (SV) e indice di efficienza della
schedulazione (SPI) per i componenti della WBS, in particolare i Work Package e i
punti di controllo, vengono documentati e comunicati (paragrafo 10.3.3.1) agli
stakeholder.
.4
L'analisi dello scostamento dei tempi, unitamente alla revisione dei report di
avanzamento, risultati delle misurazioni delle prestazioni e modifiche apportate al
modello della schedulazione di progetto possono condurre a richieste di modifica
(paragrafo 4.4.3.2) relative alla baseline della schedulazione di progetto. Le modifiche
alla schedulazione di progetto possono o meno richiedere di effettuare adeguamenti ad
altri componenti del piano di Project Management. Le richieste di modifica vengono
elaborate per l'analisi e la disposizione mediante il processo di controllo integrato
.5

Unazione correttiva rappresentata da qualsiasi cosa fatta per conformare le future
prestazioni previste per la schedulazione di progetto alla baseline approvata della
schedulazione di progetto. Le azioni correttive in materia di gestione dei tempi
riguardano spesso laccelerazione dei tempi, che include azioni speciali intraprese al
fine di assicurare che il completamento di unattivit schedulata avvenga nei tempi
previsti o con il minimo ritardo possibile. L'azione correttiva richiede spesso l'analisi
delle cause originarie per identificare la causa dello scostamento. Lanalisi pu
indirizzare attivit schedulate diverse da quelle che hanno effettivamente causato la
deviazione; ne consegue che il ripristino della schedulazione a seguito di scostamento
pu essere pianificato ed eseguito utilizzando le attivit schedulate delineate in un
momento successivo della schedulazione di progetto.
.6

La documentazione delle lesson learned in merito alle cause dello scostamento, la
motivazione alla base delle azioni correttive intraprese e altri tipi di lesson learned
ricavate dal controllo della schedulazione vengono documentati negli asset dei
processi organizzativi (paragrafo 4.1.1.4), in modo da inserirli nel database dei dati
storici del progetto in questione e di altri progetti svolti dalla Performing
Organization.

155
.7
Elenco delle attivit (aggiornamenti)

Descritta nel paragrafo 6.1.3.1.
.8

Descritta nel paragrafo 6.1.3.2.
.9

Il piano di gestione della schedulazione (materiale introduttivo del capitolo 6),
componente del piano di Project Management (paragrafo 4.3), viene aggiornato per
rispecchiare le modifiche approvate derivanti dal processo di controllo della
schedulazione e la modalit di gestione della schedulazione di progetto.
156

CAPITOLO 7
Gestione dei costi di progetto
La gestione dei costi di progetto comprende i processi coinvolti nella pianificazione,
nella stima, nella allocazione e nel controllo dei costi affinch il progetto venga
completato nel rispetto del budget approvato. La figura 7-1 mostra una visione
d'insieme dei tre processi elencati di seguito, mentre la figura 7-2 illustra una
rappresentazione del flusso di tali processi e dei loro input e output, nonch i processi
di altre aree di conoscenza correlate.
7.1 Stima dei costi: sviluppo di unapprossimazione dei costi delle risorse
necessarie per completare le attivit di progetto.
7.2 Allocazione dei costi: aggregazione dei costi stimati delle singole attivit o dei
Work Package per determinare una baseline dei costi.
7.3 Controllo dei costi: influenza sui fattori responsabili degli scostamenti dei costi
e controllo delle modifiche al budget del progetto.
Questi processi interagiscono tra loro e con i processi appartenenti anche ad altre
gruppi, a seconda delle esigenze del singolo progetto. Ciascun processo viene svolto
almeno una volta per ogni progetto e, se il progetto suddiviso in fasi, in una o pi
fasi di progetto. Sebbene i processi siano qui presentati come elementi distinti con
interfacce ben definite, nella pratica essi possono sovrapporsi in parte o interagire in
modi diversi da quelli descritti. Le interazioni tra processi sono trattate in dettaglio nel
capitolo 3.
La gestione dei costi di progetto incentrata sul costo delle risorse necessarie
per completare le attivit schedulate. Tuttavia, la gestione dei costi di progetto deve
tenere conto dell'effetto delle decisioni prese nel progetto sui successivi costi per
l'utilizzo, la manutenzione e il supporto del prodotto, servizio o risultato del progetto.
Ad esempio, ridurre il numero di revisioni della progettazione pu avere leffetto di
ridurre il costo del progetto a discapito di un incremento dei costi operativi del cliente.
Tale visione pi ampia della gestione dei costi di progetto viene spesso definita life
cycle costing. La valutazione del life cycle costing, assieme alle tecniche di ingegneria
del valore, consente di migliorare il processo decisionale e viene utilizzata per ridurre
il costo e il tempo di esecuzione e migliorare la qualit e le prestazioni dei deliverable
del progetto.

157
Capitolo 7 Gestione dei costi di progetto
In molte aree applicative, la previsione e lanalisi dei futuri rendimenti

economici derivanti dal prodotto del progetto sono effettuate al di fuori del progetto
stesso. In altre, come nei progetti per i finanziamenti, questa attivit inclusa
direttamente nella gestione dei costi di progetto. Laddove tali previsioni e analisi sono
incluse, la gestione dei costi di progetto potr includere anche altri processi e
numerose tecniche di general management, come il ritorno sugli investimenti, il flusso
di cassa scontato e l'analisi del periodo di recupero dell'investimento.
La gestione dei costi di progetto tiene conto delle necessit informative degli
stakeholder di progetto. Diversi stakeholder valuteranno i costi di progetto in modi e
in momenti diversi. Per esempio, il costo di un componente acquistato pu essere
valutato quando la decisione di acquisto stata presa, lordine stato elaborato, il
componente stato consegnato ed il costo effettivo stato registrato ai fini contabili.
In alcuni progetti, in particolare quelli con ambito limitato, la stima e
l'allocazione dei costi sono talmente interconnesse da essere considerate come un
unico processo realizzabile da una sola persona in un arco di tempo relativamente
breve. Questi processi vengono qui indicati come processi distinti perch utilizzano
strumenti e tecniche diversi. La possibilit di influire sul costo maggiore nelle fasi
iniziali del progetto ed per questo motivo che fondamentale che lambito venga
definito il pi presto possibile (paragrafo 5.2).
Sebbene qui non compaia come processo specifico, prima di eseguire i tre
processi di gestione dei costi di progetto occorre un impegno di pianificazione da
parte del gruppo di Project Management. L'impegno necessario alla pianificazione
rientra nel processo Sviluppare il piano di Project Management (paragrafo 4.3),
finalizzato alla creazione di un piano di gestione dei costi che imposti la struttura e
stabilisca i criteri di pianificazione, stima, allocazione e controllo dei costi di progetto.
I processi di gestione dei costi e gli strumenti e le tecniche ad essi associati variano in
base all'area applicativa e sono in genere selezionati durante la definizione del ciclo di
vita del progetto (paragrafo 2.1); sono documentati nel piano di gestione dei costi.
Ad esempio, il piano di gestione dei costi pu stabilire:
Livello di precisione: per le stime dei costi delle attivit schedulate si pu
prevedere un arrotondamento dei dati a un valore stabilito (ad es. $100, $1.000),
in base all'ambito delle attivit e alla portata del progetto e si pu includere un
importo per la contingency.
Unit di misura: per ogni risorsa viene definita la relativa unit di misura, ad
esempio ore/uomo, giorni/uomo, settimana, importo forfetario e cos via.
Collegamenti delle procedure organizzative: il componente WBS utilizzato
per la contabilit dei costi di progetto viene detto punto di controllo. Ad ogni
punto di controllo viene assegnato un codice o numero di conto collegato
direttamente al sistema contabile della Performing Organization. Se nel punto di
controllo vengono incluse le stime dei costi per i Planning Package, occorre
specificare anche il metodo per calcolarne l'allocazione dei costi.
Soglie di controllo: in momenti temporali specifici nel corso della durata del
progetto, possono essere fissate le soglie di scostamento dei costi e di altri
indicatori (ad es. giorni/uomo, quantit di prodotto) per definire l'intervallo di
scostamento consentito.
158

Regole dell'Earned Value: di seguito vengono riportati tre esempi. 1) Sono

definite le formule di calcolo del metodo dell'Earned Value per la
determinazione della stima a finire. 2) Sono stabiliti i criteri di credito per
l'Earned Value (ad es. 0-100, 0-50-100 ecc.). 3) Si definisce il livello della
struttura di scomposizione del lavoro al raggiungimento del quale viene eseguita
l'analisi con la tecnica dell'Earned Value.
Formati di reporting: sono definiti i formati dei vari report sui costi.
Descrizioni dei processi: sono documentate le descrizioni di ognuno dei tre
processi di gestione dei costi.
Tutte le informazioni appena citate, assieme ad altre informazioni, sono incluse
nel piano di gestione dei costi, sotto forma di testo all'interno del piano o di appendici.
Il piano di gestione dei costi contenuto nel piano di Project Management
(paragrafo 4.3), o ne rappresenta un allegato, e pu essere formale o informale,
dettagliato o sintetico, in base alle necessit del singolo progetto.
Lattivit di pianificazione della gestione dei costi ha luogo allinizio della
pianificazione del progetto e definisce un quadro di riferimento per ognuno dei
processi di gestione dei costi, affinch il risultato dei processi sia efficiente e
coordinato.
Figura 7-1. Visione dinsieme della gestione dei costi di progetto

159
Figura 7-2. Diagramma di flusso dei processi di gestione dei costi di progetto
160

7.1
Stima dei costi

Stimare i costi delle attivit schedulate comporta lo sviluppo di unapprossimazione
dei costi delle risorse necessarie per completare ogni attivit schedulata.
Nell'approssimazione dei costi, chi effettua la stima considera le possibili cause di
variazione delle stime dei costi, compresi i rischi.
La stima dei costi comprende lidentificazione e la valutazione di diverse
alternative di costo. Ad esempio, nella maggior parte delle aree applicative, opinione
diffusa che un maggior sforzo nella fase di progettazione possa contribuire a ridurre il
costo della fase di esecuzione e delloperativit del prodotto. Il processo di stima dei
costi valuta se i risparmi previsti possono compensare il costo del lavoro
supplementare di progettazione.
Generalmente le stime dei costi sono espresse in valuta (dollari, euro, yen, ecc.)
per facilitare i confronti allinterno dei progetti e tra progetti diversi. In alcuni casi, per
la stima dei costi, vengono usate unit di misura come ore/uomo o giorni/uomo,
insieme alla stima del relativo costo, per facilitare un corretto controllo di gestione.
Le stime dei costi possono beneficiare di affinamenti nel corso del progetto, per
rispecchiare i dati ulteriori che si rendono disponibili. L'accuratezza di una stima di
progetto aumenter con il procedere del progetto lungo il suo ciclo di vita. Ad
esempio, un progetto in fase iniziale pu essere caratterizzato da una stima
approssimativa che va dal -50% al +100%. Con l'avanzare del progetto, grazie alla
raccolta di ulteriori informazioni, le stime potrebbero diventare pi precise,
restringendo l'intervallo tra il -10% e il +15%. In alcune aree applicative esistono linee
guida che stabiliscono quando effettuare questi affinamenti e il livello di accuratezza
previsto.
Le informazioni di input provengono dagli output dei processi del progetto
descritti nei capitoli dal 4 al 6 e dal 9 al 12. Una volta raccolte, tali informazioni
rimarranno disponibili sotto forma di input per ognuno dei tre processi di gestione dei
costi.
I costi delle attivit schedulate vengono stimati per tutte le risorse che saranno
impiegate nel progetto. Tali costi includono, a titolo esemplificativo, manodopera,
materiali, attrezzature, servizi e infrastrutture, oltre a particolari categorie come
l'adeguamento al tasso d'inflazione o il costo delle contingency. La stima dei costi
delle attivit schedulate costituisce una valutazione quantitativa dei costi probabili
delle risorse necessarie per completare le attivit.
Se la Performing Organization non ha al suo interno degli esperti addetti alle
stime dei costi di progetto, il gruppo di progetto ha il compito di fornire le risorse e le
competenze per eseguire le attivit di stima dei costi di progetto.

161
Figura 7-3. Stima dei costi: Input, Strumenti e tecniche e Output
7.1.1
Stima dei costi: Input
.1

Il processo di stima dei costi considera:
Condizioni di mercato: quali prodotti, servizi e risultati sono disponibili sul
mercato, da chi e a quali termini e condizioni (paragrafo 4.1.1.3).
Database commerciali: le informazioni sul tasso di costo delle risorse vengono
spesso ricavate da database commerciali che rilevano le skill e i costi delle
risorse umane e forniscono i costi standard per i materiali e le attrezzature.
Un'altra fonte costituita dai listini prezzi pubblicati dai fornitori.
.2

L'elaborazione del piano di gestione dei costi, la selezione degli strumenti di stima dei
costi e il monitoraggio e il reporting sui metodi da utilizzare tengono conto delle
politiche, delle procedure e delle linee guida formali e informali disponibili per la
stima dei costi (paragrafo 4.1.1).
Politica per la stima dei costi: alcune organizzazioni dispongono di approcci
predefiniti per quanto riguarda la stima dei costi. In questi casi, il progetto si
sviluppa nel rispetto dei limiti dettati da queste politiche.
Schemi di documenti per la stima dei costi: alcune organizzazioni hanno
elaborato schemi di documenti (o una standard proforma) a disposizione del
gruppo di progetto. L'organizzazione pu migliorare costantemente gli schemi di
documenti in base alluso e allutilit dimostrata in progetti precedenti.
Dati storici: le informazioni riguardanti il prodotto o servizio del progetto
ottenute da varie fonti interne all'organizzazione, possono influenzare il costo
del progetto.
File del progetto: una o pi delle organizzazioni impegnate nel progetto
conserveranno dati sulle prestazioni di progetti precedenti dettagliati in modo
sufficiente da essere utilizzati come supporto nella determinazione delle stime
dei costi. In alcune aree applicative questi dati possono essere conservati da
singoli membri del gruppo di lavoro.
162

.3
Conoscenze possedute dal gruppo di progetto: i membri del gruppo di

progetto possono ricordare costi effettivi o stime dei costi di progetti precedenti.
Anche se possono essere utili, queste informazioni sono in genere meno
attendibili delle prestazioni di progetto documentate.
Lesson learned: le lesson learned possono includere le stime dei costi ottenute
da progetti precedenti simili per ambito e dimensione.

La descrizione dell'ambito del progetto (paragrafo 5.2.3.1) documenta le necessit di
business, i motivi, i requisiti e i limiti attuali del progetto. Fornisce informazioni
importanti sui requisiti del progetto utili durante la stima dei costi. La descrizione
dell'ambito del progetto include vincoli, assunti e requisiti. I vincoli sono fattori
specifici che limitano le opzioni di stima dei costi. Uno dei pi comuni vincoli per
molti progetti costituito da un budget limitato. Altri limiti possono essere le date di
consegna obbligatorie, la disponibilit di risorse qualificate e le politiche
organizzative. Gli assunti sono fattori che saranno considerati veri, reali o certi. I
requisiti con implicazioni di ordine contrattuale e legale includono norme sanitarie, di
sicurezza, di protezione, di performance, ambientali, assicurative, sui diritti di
propriet intellettuale, sulle pari opportunit, in materia di licenze e permessi; sono
tutti elementi che vengono presi in considerazione al momento dell'elaborazione delle
stime dei costi.
La descrizione dell'ambito del progetto fornisce inoltre l'elenco dei deliverable e
i criteri di accettazione riguardanti il progetto e i suoi prodotti, servizi e risultati. Al
momento dell'elaborazione della stima dei costi di progetto vengono analizzati tutti
questi fattori. La descrizione delle specifiche di prodotto, contenuta nella descrizione
dell'ambito del progetto, comprende descrizioni dei prodotti e dei servizi e importanti
informazioni riguardo questioni o problemi tecnici che sono presi in considerazione
durante la stima dei costi.
.4

La struttura di scomposizione del lavoro (WBS) del progetto (paragrafo 5.3.3.2)
illustra la relazione tra tutti i componenti del progetto e i deliverable di progetto
.5

Il dizionario della WBS (paragrafo 5.3.3.3) e i relativi capitolati dettagliati contengono
l'identificazione dei deliverable e una descrizione del lavoro in ogni componente WBS
necessario per la produzione di ogni deliverable.
.6

Il piano di Project Management (paragrafo 4.3) fornisce il piano complessivo per
l'esecuzione, il monitoraggio e il controllo del progetto e include piani aggiuntivi che
contengono indicazioni e linee guida per la pianificazione e il controllo della gestione
dei costi. Qualora siano disponibili altri output di pianificazione, questi vengono presi
in considerazione durante la stima dei costi.

163
7.1.2
.1
Piano di gestione della schedulazione: il tipo e la quantit di risorse e il

periodo di tempo in cui queste risorse sono impegnate per completare il lavoro
del progetto costituiscono un elemento fondamentale per la determinazione del
costo di progetto. Le risorse per le attivit schedulate e le relative durate sono
usate come input principali di questo processo. La stima delle risorse delle
attivit (paragrafo 6.3) prevede la determinazione della disponibilit e delle
quantit necessarie di personale, attrezzature e materiale per l'esecuzione delle
attivit schedulate. strettamente correlata alla stima dei costi. La stima della
durata delle attivit (paragrafo 6.4) influenza le stime dei costi nei progetti in cui
il budget comprende un accantonamento per il costo del finanziamento,
comprese le spese per gli interessi, e in cui le risorse sono impiegate per unit di
tempo per la durata dell'attivit schedulata. Le stime di durata delle attivit
schedulate possono influire anche sulle stime dei costi legati a fattori temporali,
come, ad esempio, la manodopera con accordi salariali collettivi a scadenza
regolare o i materiali con variazioni stagionali del costo, o sulle stime dei costi
che comprendono i costi operativi globali sostenuti per il progetto che
dipendono dalla durata del progetto stesso.
Piano di gestione del personale: le caratteristiche e le tariffe del personale
coinvolto nel progetto (paragrafo 9.1.3.3) sono componenti necessari per
l'elaborazione delle stime dei costi della schedulazione.
Registro dei rischi: chi effettua la stima dei costi prende in considerazione le
informazioni relative alle risposte ai rischi (paragrafo 11.2.3.1). I rischi, che
possono essere sia minacce sia opportunit, hanno in genere un impatto sia sulla
schedulazione delle attivit sia sui costi di progetto. In linea di principio, se il
progetto incorre in un rischio negativo, quasi certamente il costo tender ad
aumentare e la schedulazione di progetto subir ritardi.
Stima dei costi: Strumenti e tecniche

Stima per analogia
La stima dei costi per analogia prevede l'utilizzo del costo effettivo di progetti simili
realizzati in precedenza come base per la stima del costo del progetto corrente. Questo
tipo di stima viene di solito utilizzato per valutare i costi quando si dispone di una
quantit limitata di informazioni dettagliate sul progetto (ad es. nelle fasi iniziali). La
stima dei costi per analogia si basa sul parere di esperti.
In genere, questo tipo di stima meno oneroso di altre tecniche, ma anche meno
accurato. Pu essere considerata pi attendibile quando i progetti precedenti sono
simili in sostanza e non solo in apparenza e le persone o i gruppi che preparano le
stime possiedono le necessarie competenze.
164

.2
Determinazione dei costi delle risorse

Per stimare i costi delle attivit schedulate, l'addetto alla determinazione dei costi o il
gruppo che prepara le stime deve essere a conoscenza dei costi unitari di ogni risorsa,
come ad esempio il costo all'ora per il personale e il costo del materiale all'ingrosso
per iarda cubica (1 iarda cubica = 0,764 metri cubi). Un modo per ottenere i costi
unitari farsi fare delle offerte dai fornitori (paragrafo 12.3). Per i prodotti, servizi o
risultati oggetto di un contratto, si possono adottare costi standard con fattori di
adeguamento. Un'altra fonte per ottenere i costi unitari costituita dai database
commerciali e dai listini prezzi pubblicati dai fornitori. Nel caso in cui i costi effettivi
non siano disponibili, essi dovranno essere stimati.
.3
Stima bottom-up
Questa tecnica prevede la stima dettagliata dei costi di singoli Work Package o di
singole attivit schedulate partendo dal livello di dettaglio pi basso. Il costo stimato
in dettaglio viene quindi aggregato a livelli superiori, ai fini del reporting e del
controllo. Il costo e l'accuratezza di una stima dei costi bottom-up dipendono in
genere dalla dimensione e dalla complessit della singola attivit schedulata o Work
Package. In genere, la presenza di attivit con un livello di impegno ridotto garantisce
una maggiore accuratezza nelle stime dei costi delle attivit schedulate.
.4
Stima parametrica
Si tratta di una tecnica che utilizza una relazione statistica tra i dati storici e altre
variabili (ad es. metri quadri nell'edilizia, righe di codice nella programmazione
software, ore di manodopera necessarie) per elaborare una stima dei costi delle risorse
di un'attivit schedulata. Questa tecnica consente di raggiungere livelli elevati di
accuratezza in funzione del grado di sofisticazione e della quantit di risorse e di dati
sui costi contenuti nel modello. Un esempio dato dalla moltiplicazione della quantit
pianificata di lavoro da eseguire per il costo storico unitario.
.5

Il software di Project Management, come ad esempio le applicazioni per la stima dei
costi, i fogli di calcolo e gli strumenti di simulazione e statistica, sono ampiamente
utilizzati come ausilio nel processo di stima dei costi. Tali strumenti semplificano
l'utilizzo di alcune tecniche di stima dei costi e facilitano l'analisi delle diverse
alternative per la stima dei costi.
.6
Analisi dell'offerta del venditore

Altri metodi per la stima dei costi sono l'analisi delle offerte dei venditori e un'analisi
di quanto il progetto dovrebbe costare. Nei casi in cui ci si sia aggiudicati il progetto
attraverso una gara, pu essere necessario un lavoro aggiuntivo di stima dei costi da
parte del gruppo di progetto per esaminare il prezzo dei singoli deliverable e ottenere
un costo che rispetti il costo finale globale del progetto.

165
.7

Nelle stime dei costi delle attivit schedulate si inseriscono spesso come costi anche le
riserve, dette anche accantonamenti per contingency. In questo modo viene generato
un potenziale sovradimensionamento della stima dei costi per l'attivit schedulata. Le
riserve per contingency sono costi stimati da utilizzare a discrezione del project
manager per gestire eventi previsti, ma non certi. Questi eventi sono incognite
conosciute e rientrano nell'ambito del progetto e nelle baseline dei costi.
Una possibilit per gestire le riserve per contingency quella di aggregare in
ununica riserva relativa a un gruppo di attivit correlate, le singole riserve delle varie
attivit schedulate. In questo modo, lattivit schedulata con la riserva pu essere
un'attivit di durata zero posizionata lungo il percorso del reticolo allinterno di quel
particolare gruppo di attivit schedulate e utilizzata per conservare la contingency per
i costi. In questa soluzione la riserva a livello di Work Package viene assegnata ad
un'attivit di durata nulla, che per si estende sull'intero arco del sottoreticolo
rappresentato dal Work Package. Con lavanzare delle attivit schedulate, si pu
perfezionare il calcolo della riserva per contingency, che viene misurata in funzione
del consumo di risorse delle attivit schedulate che non hanno durata nulla. Con
questo sistema gli scostamenti dei costi delle attivit del gruppo sono pi precisi
perch si basano su stime dei costi non pessimistiche.
In alternativa, l'attivit schedulata pu costituire un'attivit buffer nel metodo del
Critical Chain ed essere posizionata di proposito direttamente alla fine del percorso
del reticolo relativo al gruppo di attivit schedulate considerato. Con lavanzare delle
attivit schedulate, si pu perfezionare il calcolo della riserva per contingency, che
viene misurata in base al consumo di risorse delle attivit schedulate non di buffer.
Anche qui, gli scostamenti dei costi delle attivit del gruppo diventano pi precisi
perch si basano su stime dei costi non pessimistiche.
.8
Costo della qualit

Il costo della qualit (paragrafo 8.1.2.4) pu essere utilizzato per la preparazione della
stima dei costi delle attivit schedulate.
7.1.3
.1
Stima dei costi: Output

Stime dei costi delle attivit
La stima dei costi delle attivit la determinazione quantitativa dei costi previsti delle
risorse necessarie per completare l'attivit schedulata e pu essere presentata in forma
sintetica o dettagliata. Viene preparata una stima dei costi relativi a tutte le risorse
prese in considerazione per la stima dei costi dell'attivit. Tali costi includono, a titolo
esemplificativo, manodopera, materiali, infrastrutture, servizi, impianti, tecnologie
informatiche e particolari categorie come l'adeguamento al tasso di inflazione o la
riserva per contingency per i costi.
166

.2
7.2
Dettagli di supporto della stima dei costi delle attivit

La quantit e il tipo di dettagli aggiuntivi a supporto della stima dei costi delle attivit
schedulate variano a seconda dell'area applicativa. A prescindere dal livello di
dettaglio, la documentazione di supporto deve fornire un quadro chiaro, professionale
e completo degli elementi che hanno condotto alla stima dei costi.
I dettagli di supporto delle stime dei costi delle attivit includono:
Descrizione dell'ambito del lavoro del progetto dell'attivit schedulata.
Documentazione della base di stima, ovvero in che modo sono stati ottenuti i
valori di stima.
Documentazione di tutti gli assunti.
Documentazione di tutti i vincoli.
Indicazione dellintervallo possibile delle stime (ad es. $10.000 (-10% / +15%)
per indicare che il costo previsto dellelemento in questione compreso tra
$9.000 e $11.500).
.3
Modifiche richieste
possibile che il processo di stima dei costi generi modifiche richieste (paragrafo
4.4.3.2) che possono influire sul piano di gestione dei costi (materiale introduttivo del
capitolo 7), sui requisiti delle risorse delle attivit (paragrafo 6.3.3.1) e su altri
componenti del piano di Project Management. Le modifiche richieste vengono
elaborate per lanalisi e la decisione mediante il processo di controllo integrato delle
.4
Piano di gestione dei costi (aggiornamenti)

Se il processo di stima dei costi genera richieste di modifica approvate (paragrafo
4.4.1.4), il Piano di gestione dei costi che fa parte del piano di Project Management
(materiale introduttivo del capitolo 7) viene aggiornato qualora tali modifiche
approvate influiscano sulla gestione dei costi.
Allocazione dei costi

Lallocazione dei costi consiste nellaggregazione dei costi stimati delle singole
attivit schedulate o Work Package, al fine di stabilire una baseline totale dei costi che
servir a misurare landamento del progetto. La descrizione dell'ambito del progetto
fornisce un budget riepilogativo. Tuttavia, le stime dei costi delle attivit schedulate o
dei Work Package vengono preparate prima di richiedere il budget dettagliato e di
autorizzare il lavoro.
Figura 7-4. Allocazione dei costi: Input, Strumenti e tecniche e Output

167
7.2.1
Allocazione dei costi: Input
.1

Il Project Charter (paragrafo 4.1.3.1) o il contratto possono contenere limitazioni
periodiche formali all'utilizzo dei fondi del progetto. Questi vincoli economici sono
indicati anche nella descrizione dell'ambito del progetto e possono dipendere da
autorizzazioni annuali di finanziamento da parte dell'organizzazione dell'acquirente o
di altre entit quali le agenzie governative.
.2

La struttura di scomposizione del lavoro (WBS) del progetto (paragrafo 5.3.3.2)
descrive la relazione tra tutti i componenti del progetto e i deliverable di progetto
.3

Il dizionario della WBS (paragrafo 5.3.3.3) e i relativi capitolati dettagliati contengono
l'identificazione dei deliverable e una descrizione del lavoro in ogni componente della
WBS necessario per la produzione di ogni deliverable.
.4
Stime dei costi delle attivit

Le stime dei costi (paragrafo 7.1.3.1) di ogni attivit schedulata contenuta in un Work
Package vengono aggregate per ottenere una stima dei costi per ciascun Work
Package.
.5
Dettagli di supporto della stima dei costi delle attivit

.6
Schedulazione di progetto
La schedulazione di progetto (paragrafo 6.5.3.1) include una data dinizio pianificata e
una data di fine pianificata per le attivit schedulate, le milestone di schedulazione, i
Work Package, i Planning Package e i punti di controllo del progetto. Queste
informazioni vengono utilizzate per l'aggregazione dei costi nei periodi in cui si
prevede che questi saranno sostenuti.
.7
Calendari delle risorse

.8
Contratto
Lo sviluppo del budget utilizza informazioni ricavate dal contratto (paragrafo
12.4.3.2) riguardanti i prodotti, servizi o risultati acquistati e i relativi costi.
.9
Piano di gestione dei costi

Nel corso della definizione dell'allocazione dei costi, vengono presi in considerazione
il componente Piano di gestione dei costi del piano di Project Management e altri
piani aggiuntivi.
168

7.2.2
Allocazione dei costi: Strumenti e tecniche
.1
Aggregazione dei costi

Le stime dei costi delle attivit schedulate vengono aggregate per Work Package in
base alla WBS. Successivamente, le stime dei costi dei Work Package vengono
aggregate per il componente di livello pi elevato della WBS, come i punti di
controllo, e infine per l'intero progetto.
.2

L'analisi della riserva (paragrafo 11.6.2.5) determina le riserve per contingency, come
ad esempio le riserve di gestione, che costituiscono accantonamenti per modifiche
impreviste ma che potenzialmente potrebbero essere richieste. Tali modifiche
potrebbero risultare da rischi identificati nel registro dei rischi.
Le riserve per contingency di gestione sono budget accantonati per modifiche
impreviste che potrebbero essere richieste all'ambito e al costo del progetto. Si tratta di
incognite sconosciute per le quali il Project manager deve ottenere un'approvazione
prima di impegnare o utilizzare le riserve. Le riserve per contingency di gestione non
rientrano nella baseline dei costi del progetto, ma sono incluse nel budget del progetto.
Non vengono distribuite come budget e non rientrano quindi nei calcoli dell'Earned
Value.
.3
Stima parametrica
La tecnica della stima parametrica consiste nellutilizzo di caratteristiche del progetto
(parametri) in un modello matematico per ottenere una previsione totale dei costi di
progetto. I modelli possono essere semplici (ad es. la costruzione di edifici residenziali
costa una certa cifra per metro quadrato di spazio abitabile) o complessi (ad es. un
modello dei costi di sviluppo software che utilizza tredici fattori di aggiustamento
distinti, ognuno dei quali contiene da cinque a sette punti).
Sia il costo che l'accuratezza dei modelli parametrici variano sensibilmente.
pi probabile che siano affidabili quando:
le informazioni storiche utilizzate per lo sviluppo del modello sono accurate;
i parametri utilizzati nel modello sono facilmente quantificabili;
il modello scalabile ed quindi applicabile a progetti di dimensioni estese o
ridotte.
.4
Riconciliazione del limite del finanziamento

Le ampie variazioni nellimpiego periodico di fondi sono di solito un evento
indesiderabile per le funzioni operative dellorganizzazione. Di conseguenza,
l'impiego di fondi per il progetto va riconciliato con i limiti di finanziamento fissati
dal cliente o dalla Performing Organization. La riconciliazione richiede
l'aggiustamento della schedulazione del lavoro per uniformare e regolare le spese; tale
aggiustamento si ottiene inserendo nella schedulazione di progetto dei vincoli di data
imposta per alcuni Work Package, milestone di schedulazione o componenti della
WBS. La rischedulazione pu avere un impatto sull'allocazione delle risorse. Nel caso
in cui i fondi siano stati usati come vincolo nel processo di sviluppo della
schedulazione, il processo viene ripetuto utilizzando i nuovi vincoli di data imposta. Il
prodotto finale di queste iterazioni di pianificazione una baseline dei costi.

169
7.2.3
Allocazione dei costi: Output
.1
Baseline dei costi

La baseline dei costi un budget suddiviso per fasi temporali utilizzato come base di
confronto per la misurazione, il monitoraggio e il controllo dell'andamento
complessivo dei costi del progetto. Viene sviluppata sommando i costi stimati per
periodo ed generalmente rappresentata da una curva a S, come illustra la
figura 7-5. La baseline dei costi un componente del Piano di Project Management.
Molti progetti, in particolare quelli di grandi dimensioni, hanno baseline
multiple per i costi o per le risorse e baseline per i materiali di consumo (ad es. iarde
cubiche di cemento al giorno) per la misurazione dei diversi aspetti dell'andamento del
progetto. Ad esempio, potrebbe rendersi necessario che il Project manager rilevi i
costi interni (manodopera) separatamente da quelli esterni (fornitori e materiali da
costruzione) o dalle ore di manodopera complessive.
.2
Requisiti di finanziamento del progetto

I requisiti di finanziamento, totali e periodici (ad es. annuali o trimestrali), sono
ricavati dalla baseline dei costi e possono essere stabiliti per eccesso, di solito
applicando un margine, in previsione di anticipi sui tempi o aggravio di costi. I
finanziamenti vengono in genere erogati in importi incrementali non continuativi;
nella figura 7-5 vengono rappresentati come una funzione a gradini. I fondi
complessivi richiesti sono la somma di quelli inclusi nella baseline dei costi e
dell'importo della riserva per contingency di gestione. Una parte della riserva per
contingency di gestione pu essere inclusa in maniera incrementale in ogni gradino di
finanziamento o pu essere accantonata quando necessario, in base alle politiche
organizzative.
Sebbene la figura 7-5 mostri l'importo della riserva di gestione al termine del
progetto, in realt, la baseline dei costi e le linee del flusso di cassa aumentano quando
una parte della riserva di gestione viene autorizzata e quando viene spesa. Al termine
del progetto, l'eventuale divario tra i fondi stanziati, la baseline dei costi e gli importi
del flusso di cassa mostra l'importo della riserva di gestione non utilizzato.
Figura 7-5. Flusso di cassa, baseline dei costi e visualizzazione dei finanziamenti
170

7.3
.3
Piano di gestione dei costi (aggiornamenti)

Se il processo di allocazione dei costi genera richieste di modifica approvate
(paragrafo 4.4.1.4), qualora tali modifiche approvate influiscano sulla gestione dei
costi viene aggiornato lelemento Piano di gestione dei costi del Piano di Project
Management.
.4
Modifiche richieste
possibile che il processo di allocazione dei costi generi modifiche richieste
(paragrafo 4.4.3.2) che influiscono sul piano di gestione dei costi o su altri
componenti del piano di Project Management. Le modifiche richieste vengono
elaborate per lanalisi e la decisione mediante il processo di controllo integrato delle
Controllo dei costi

Il controllo dei costi di progetto include:
Influire sui fattori che causano modifiche alla baseline dei costi.
Assicurare che le modifiche richieste siano concordate.
Gestire le modifiche nel momento in cui si verificano.
Accertare che i potenziali costi supplementari non superino i finanziamenti
autorizzati per il progetto su base periodica o complessiva.
Monitorare l'andamento dei costi per rilevare e comprendere eventuali
scostamenti dalla baseline dei costi.
Registrare accuratamente tutte le modifiche appropriate rispetto alla baseline dei
costi.
Evitare che modifiche non corrette, inappropriate o non approvate siano incluse
nei dati sull'utilizzo di risorse o di costi.
Informare gli stakeholder interessati delle modifiche approvate.
Assumere iniziative volte a riportare il superamento dei costi entro limiti
accettabili.
Il controllo dei costi di progetto ha la funzione di individuare le cause degli
scostamenti positivi e negativi ed parte del controllo integrato delle modifiche
(paragrafo 4.6). Ad esempio, risposte inappropriate a scostamenti dei costi possono
causare problemi di qualit o schedulazione o determinare, con il procedere del
progetto, un livello di rischio inaccettabile.
Figura 7-6. Controllo dei costi: Input, Strumenti e tecniche e Output

171
7.3.1
Controllo dei costi: Input
.1
Baseline dei costi

.2
Requisiti di finanziamento del progetto

.3

I report sulle prestazioni (paragrafo 10.3.3.1) forniscono informazioni sull'andamento
dei costi e delle risorse durante il reale svolgersi del lavoro.
.4

Vengono raccolte informazioni sullo stato di avanzamento del lavoro (paragrafo
4.4.3.7) che riguardano lo stato e il costo delle attivit di progetto in esecuzione.
Queste informazioni comprendono, a titolo esemplificativo, gli elementi riportati di
seguito:
Deliverable completati e non completati.
Costi autorizzati e sostenuti.
Stime a finire delle attivit schedulate.
Percentuale di completamento fisico delle attivit schedulate.
.5

Le richieste di modifica approvate (paragrafo 4.4.1.4) dal processo di controllo
integrato delle modifiche (paragrafo 4.6) possono comprendere variazioni alle
clausole di costo del contratto, allambito del progetto, alla baseline dei costi o al
piano di gestione dei costi.
.6

Durante il processo di controllo dei costi, vengono presi in considerazione il piano di
Project Management, il suo componente Piano di gestione dei costi e altri piani
aggiuntivi.
7.3.2
Controllo dei costi: Strumenti e tecniche
.1
Sistema di controllo delle modifiche dei costi

Il sistema di controllo delle modifiche dei costi, documentato nel piano di gestione dei
costi, definisce le procedure tramite cui possibile modificare la baseline dei costi.
Comprende i moduli, la documentazione, il sistema di rilevamento e i livelli di
approvazione necessari per lautorizzazione delle modifiche. Il sistema di controllo
delle modifiche dei costi inserito nel processo di controllo integrato delle modifiche
(paragrafo 4.6).
.2
Analisi della misurazione delle prestazioni

Le tecniche di misurazione delle prestazioni consentono di valutare la portata degli
scostamenti che inevitabilmente si verificheranno. La tecnica dell'Earned Value
(EVT) confronta il valore cumulativo del costo preventivato del lavoro eseguito
valorizzato al costo originario di budget con il costo preventivato del lavoro
schedulato (pianificato) e con il costo effettivo del lavoro eseguito (effettivo). Tale
tecnica particolarmente utile per il controllo dei costi, la gestione delle risorse e la
produzione.
172

Nel controllo dei costi importante determinare la causa e la portata di uno

scostamento e decidere se lo scostamento richiede un'azione correttiva. La tecnica
dell'Earned Value usa la baseline dei costi (paragrafo 7.2.3.1) contenuta nel piano di
Project Management (paragrafo 4.3) per valutare l'avanzamento del progetto e la
portata degli scostamenti che si verificano.
La tecnica dell'Earned Value implica, per ogni attivit schedulata, Work
Package o punto di controllo, la determinazione dei seguenti valori chiave:
Valore pianificato (PV): il costo preventivato del lavoro schedulato per il
completamento di un'attivit o un componente della WBS entro un determinato
punto temporale.
Earned Value (EV): il valore a budget del lavoro effettivamente completato
su un'attivit schedulata o un componente della WBS in un determinato periodo
di tempo.
Costo effettivo (AC): il costo totale sostenuto per svolgere il lavoro di
un'attivit schedulata o di un componente della WBS nel corso di un
determinato periodo di tempo. Il costo effettivo (AC) deve essere calcolato
usando lo stesso criterio usato per stimare il valore pianificato e lEarned Value
(ad esempio, solo le ore di lavoro spese direttamente sullattivit, solo i costi
diretti oppure tutti i costi, compresi quelli indiretti).
Stima a finire (ETC) e Stima al completamento (EAC): vedere sviluppo ETC
ed EAC, descritti nella tecnica sulle previsioni pi avanti in questa sezione.
Il valori PV, EV e AC sono utilizzati in combinazione tra loro per fornire misure
sulle prestazioni per verificare, in un determinato punto temporale, se il lavoro stia
procedendo come pianificato o meno. Le misure pi comunemente utilizzate sono lo
scostamento dei costi (CV) e lo scostamento dei tempi (SV). Lentit degli
scostamenti CV e SV tende a decrescere al completamento del progetto, a causa
delleffetto compensativo svolto dal maggior lavoro prodotto. Nel Piano di gestione
dei costi possono essere stabiliti valori predeterminati relativi alle soglie di
scostamenti accettabili in relazione al grado di completamento del progetto.
Scostamento dei costi (CV): lo scostamento dei costi (CV) uguale allEarned
Value (EV) meno il costo effettivo (AC). Lo scostamento dei costi al termine
del progetto sar la differenza tra il budget al completamento (BAC) e l'effettivo
importo speso.
Formula: CV = EV AC
Scostamento dei tempi (SV): lo scostamento dei tempi (SV) uguale
allEarned Value (EV) meno il valore pianificato (PV). Alla fine, cio quando il
progetto viene completato, lo scostamento dei tempi sar pari a zero, poich
tutto il lavoro pianificato sar stato completato.
Formula: SV = EV PV
Questi due valori, CV e SV, possono essere convertiti in indicatori di
rendimento, rispetto ai costi e alla schedulazione, di qualunque progetto.
Indice di efficienza dei costi (CPI): un valore CPI inferiore a 1,0 indica una
situazione di maggior costo rispetto a quanto stimato. Un valore CPI superiore a
1,0 indica una situazione di minor costo rispetto a quanto stimato. Il valore CPI
uguale al rapporto tra EV e AC. Il valore CPI l'indicatore di efficienza dei
costi pi comunemente utilizzato.
Formula: CPI = EV/AC

173
Indice di efficienza dei costi cumulativo (CPIC): il CPI cumulativo viene

utilizzato molto per fare previsioni sui costi del progetto a completamento. Il
valore CPIC uguale alla somma degli Earned Value periodici (EVC) diviso per
la somma dei singoli costi effettivi (ACC).
Formula: CPIC = EVC/ACC
Indice di efficienza della schedulazione (SPI): il valore SPI si usa, insieme
allo stato della schedulazione (paragrafo 6.6.2.1), per prevedere la data di
completamento e a volte si pu anche abbinare al valore CPI per prevedere le
stime sul completamento del progetto. Il valore SPI uguale al rapporto tra EV
e PV. Formula: SPI = EV/PV
La figura 7-7, utilizza le curve a S per visualizzare i dati dell'EV cumulativo per
un progetto che si trova fuori budget e che in ritardo rispetto al piano di lavoro.
Figura 7-7. Esempio di rapporto sullandamento di progetto in forma di grafico
Nelle sue varie forme, la tecnica dell'Earned Value un metodo comunemente

usato per misurare le prestazioni. Essa integra le misure dell'ambito del progetto, dei
costi (o delle risorse) e di schedulazione per consentire al gruppo di Project
Management di valutare le prestazioni del progetto.
.3
Previsioni
Le previsioni sono le stime, o predizioni, delle condizioni che potrebbero verificarsi
nel futuro del progetto, partendo dalle informazioni e dalle conoscenze disponibili al
momento della previsione. Le previsioni vengono generate, aggiornate e ridistribuite
in base alle informazioni sullo stato di avanzamento del lavoro (paragrafo 4.4.3.7) che
si rendono disponibili con l'evolvere dell'esecuzione e dell'avanzamento del progetto.
Le informazioni sullo stato di avanzamento del lavoro riguardano le prestazioni
precedenti del progetto e qualsiasi informazione che potrebbe influire sul progetto in
futuro, come la stima al completamento e la stima a finire.
174

I parametri della tecnica dell'Earned Value relativi al budget al completamento

(BAC), ai costi effettivi (ACC) alla data corrente e allindicatore di efficienza
cumulativa CPIC servono a calcolare i valori della stima a finire (ETC) e della stima al
completamento (EAC), dove il budget al completamento (BAC) uguale al valore
pianificato (PV) totale al completamento di un'attivit schedulata, un Work Package,
un punto di controllo o altro componente della WBS.
Formula: BAC = PV totale cumulativo al completamento
Le tecniche di previsione aiutano a valutare il costo o la quantit di lavoro
necessari per completare le attivit schedulate, cio la stima al completamento (EAC).
Le tecniche di previsione contribuiscono inoltre a determinare il valore della stima a
finire (ETC), ovvero la stima per il completamento del lavoro residuo relativo ad
un'attivit schedulata, un Work Package o un punto di controllo. Mentre la tecnica
dell'Earned Value per determinare i valori EAC e ETC rapida e automatica, non si
pu dire che sia valida o accurata quanto una previsione manuale del lavoro residuo
effettuata da parte del gruppo di progetto. La tecnica di previsione ETC in cui la
Performing Organization che fornisce la stima a finire illustrata di seguito.
ETC basata su una nuova stima: il valore ETC uguale alla revisione di stima
del lavoro residuo fornita dalla Performing Organization. Questa stima al
completamento pi accurata. Si tratta di una stima a finire, indipendente e noncalcolata, di tutto il lavoro residuo, che tiene conto delle prestazioni o di ci che
le risorse hanno prodotto.
In alternativa, per calcolare il valore ETC usando i dati dell'Earned Value, si
utilizza di solito una delle seguenti due formule:
ETC basata sugli scostamenti atipici: questo approccio viene utilizzato di
preferenza quando gli scostamenti correnti sono considerati atipici e il gruppo di
Project Management prevede che scostamenti simili non siano destinati a
ripetersi in futuro. Il valore ETC uguale al BAC meno l'Earned Value
cumulativo alla data corrente (EVC).
Formula: ETC = (BAC - EVC)
ETC basata sugli scostamenti tipici: questo approccio viene utilizzato di
preferenza quando gli scostamenti correnti rappresentano un trend per quelli
futuri. Il valore ETC uguale al BAC meno l'EVC cumulativo (il PV residuo)
diviso per l'indice di efficienza dei costi cumulativo (CPIC).
Formula: ETC = (BAC - EVC) / CPIC
Una stima al completamento (EAC) una previsione del valore totale pi
probabile basata sulle prestazioni del progetto (paragrafo 4.4) e sulla quantificazione
dei rischi (paragrafo 11.4). EAC il valore totale finale di proiezione o di previsione
per un'attivit schedulata, un componente della WBS o un progetto, relativo al
momento in cui il lavoro definito sar completato. Una delle tecniche di previsione
EAC prevede che sia direttamente la Performing Organization a fornire una stima al
completamento:
EAC con una nuova stima: il valore EAC uguale ai costi effettivi alla data
corrente (ACC) pi un nuovo ETC fornito dalla Performing Organization.
Questo approccio solitamente si utilizza quando le prestazioni precedenti
mostrano che gli assunti su cui erano basate le stime originali erano
sostanzialmente errati o non sono pi rilevanti, perch sono cambiate le
condizioni.
Formula: EAC = ACC + ETC

175
Le due tecniche di previsione pi comuni per calcolare il valore EAC mediante i

dati dell'Earned Value si basano su quanto segue:
EAC usando il budget residuo: EAC uguale al valore ACC pi il budget
richiesto per completare il lavoro residuo, che il budget al completamento
(BAC) meno l'Earned Value (EVC). Questo approccio viene utilizzato di
preferenza quando gli scostamenti correnti sono considerati atipici e il gruppo di
Project Management prevede che scostamenti simili non siano destinati a
ripetersi in futuro.
Formula: EAC = ACC + BAC EVC
EAC mediante CPIC: EAC uguale ai costi effettivi alla data corrente (ACC)
pi il budget richiesto per completare il lavoro rimanente del progetto, che il
BAC meno l'EVC, modificato da un fattore di prestazione (spesso il valore
CPIC). Questo approccio viene utilizzato di preferenza quando gli scostamenti
correnti sono considerati indicativi di quelli futuri.
Formula: EAC = ACC + ((BAC EVC) / CPIC)
Ciascuno degli approcci descritti pu risultare quello giusto per un dato progetto
e pu fornire al gruppo di Project Management un segnale nel caso le previsioni sulla
stima al completamento (EAC) non rientrino nella soglia accettabile.
.4
Revisioni delle prestazioni di progetto

Le revisioni delle prestazioni prevedono un confronto tra le prestazioni dei costi nel
tempo, le attivit schedulate o i Work Package che hanno superato o sotto-utilizzato il
loro budget (valore pianificato), le milestone previste e le milestone raggiunte.
Le revisioni delle prestazioni sono incontri che si tengono per valutare lo stato e
landamento delle attivit schedulate, dei Work Package o dei punti di controllo e
solitamente sono abbinate a una o pi delle tecniche per il reporting delle prestazioni
illustrate di seguito.
Analisi dello scostamento: comporta il confronto tra le prestazioni effettive di
progetto e le prestazioni previste o attese. Gli scostamenti pi frequentemente
analizzati sono quelli relativi a costi e tempi, anche se spesso gli scostamenti
rispetto al piano nelle aree relative all'ambito del progetto, alle risorse, alla
qualit e al rischio risultano essere di importanza pari o superiore.
Analisi delle tendenze: comporta lesame dellandamento delle prestazioni di
progetto nel tempo, al fine di determinare se le prestazioni tendano a migliorare
o a peggiorare.
Tecnica dell'Earned Value: comporta il confronto tra le prestazioni previste e
quelle effettive.
.5

Il software di Project Management, cos come i fogli di calcolo computerizzati,
vengono spesso usati per monitorare il valore pianificato (PV) rispetto al costo
effettivo (AC) e per prevedere gli effetti delle modifiche o degli scostamenti.
.6
Gestione dello scostamento

Il piano di gestione dei costi (paragrafo 7.1.3.4) descrive come verranno gestiti gli
scostamenti dei costi, ad esempio rispondendo in modo diverso a problemi di
maggiore o minore entit. L'entit dello scostamento tende a diminuire man mano che
si completa una parte pi consistente del lavoro. Gli scostamenti tollerati, che a inizio
progetto solitamente sono ampi, potrebbero ridursi man mano che il progetto si
avvicina al completamento.
176

7.3.3
Controllo dei costi: Output
.1
Stime dei costi (aggiornamenti)

Le revisioni delle stime dei costi delle attivit schedulate sono modifiche delle
informazioni sui costi utilizzate per gestire il progetto. Gli stakeholder interessati sono
informati come stabilito. Le revisioni delle stime dei costi possono determinare
modifiche di altri aspetti del piano di Project Management.
.2
Baseline dei costi (aggiornamenti)

Gli aggiornamenti del budget costituiscono modifiche alla baseline dei costi
approvata. Questi valori vengono in genere rivisti solo in seguito a modifiche
approvate all'ambito del progetto. Tuttavia, in alcuni casi, gli scostamenti dei costi
possono essere talmente rilevanti da rendere necessaria una revisione della baseline
dei costi stabilire una base per la misurazione delle prestazioni che sia realistica.
.3
Misurazioni delle prestazioni

I valori CV, SV, CPI e SPI calcolati per i componenti della WBS, in particolare i
Work Package e i punti di controllo, vengono documentati e comunicati (paragrafo
10.3.3.1) agli stakeholder.
.4
Completamento previsto
Viene determinato e comunicato agli stakeholder il valore EAC calcolato oppure
quello stimato dalla Performing Organization (paragrafo 10.3.3.1). Viene inoltre
determinato e comunicato agli stakeholder un valore ETC calcolato oppure stimato
dalla Performing Organization.
.5
Modifiche richieste
possibile che l'analisi dell'andamento del progetto generi una richiesta di modificare
alcuni aspetti del progetto. Le modifiche individuate possono richiedere laumento o
la riduzione del budget. Le modifiche richieste (paragrafo 4.4.3.2.) vengono elaborate
per l'analisi e la decisione mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
.6

Un'azione correttiva rappresentata da qualsiasi operazione effettuata per conformare
al piano di Project Management le prestazioni future previste per il progetto. Le azioni
correttive relative alla gestione dei costi implicano spesso un adeguamento dei budget
delle attivit schedulate, come ad esempio la messa in atto di misure speciali per
riequilibrare gli scostamenti dei costi.
.7

Si documentano le lesson learned per inserirle nei database storici del progetto e della
Performing Organization. La documentazione relativa alle lesson learned include le
cause originarie degli scostamenti, i motivi della scelta di un'azione correttiva e altre
tipologie di lesson learned ricavate dai costi, dalle risorse o dal controllo dei costi di
produzione delle risorse.

177
.8

L'attivit schedulata, il Work Package o le stime dei costi del Planning Package
(materiale introduttivo del capitolo 7), cos come la baseline dei costi (paragrafo
7.2.3.1), il piano di gestione dei costi e i documenti relativi al budget del progetto
sono componenti del piano di Project Management. Tutte le richieste di modifica
approvate (paragrafo 4.4.1.4) che riguardano tali documenti vengono incorporate
come aggiornamenti nei documenti stessi.
178

CAPITOLO 8
Gestione della qualit di progetto
I processi di gestione della qualit di progetto comprendono tutte le attivit della
Performing Organization per definire le politiche di qualit, gli obiettivi e le
responsabilit della gestione della qualit, affinch il progetto soddisfi le esigenze per
le quali stato intrapreso. Il progetto implementa il sistema di gestione della qualit
mediante le politiche, le procedure e i processi di pianificazione della qualit, di
assicurazione qualit e di controllo di qualit, ai quali si affiancano attivit di
miglioramento costante dei processi, a seconda delle esigenze. La figura 8-1 mostra
una visione d'insieme dei processi di gestione della qualit di progetto, mentre la
figura 8-2 illustra un diagramma di flusso di tali processi, dei loro input, output e di
altri processi delle aree di conoscenza correlate. I processi di gestione della qualit di
progetto sono:
8.1 Pianificazione della qualit: identificazione degli standard di qualit rilevanti
per il progetto e determinazione del modo in cui soddisfarli.
8.2 Effettuare l'assicurazione qualit: esecuzione delle attivit pianificate e
sistematiche relative alla qualit per garantire che il progetto utilizzi tutti i
processi necessari a soddisfarne i requisiti.
8.3 Esecuzione del controllo di qualit: monitorare specifici risultati del progetto
per determinarne la conformit ai rispettivi standard di qualit e per individuare
metodi diretti a eliminare le cause di risultati non soddisfacenti.
Questi processi interagiscono tra loro e con i processi delle altre aree di
conoscenza. Ogni processo pu richiedere limpegno di una o pi persone o gruppi,
secondo i requisiti del progetto. Ciascun processo viene svolto almeno una volta per
ogni progetto e in una o pi fasi del progetto, se questo suddiviso in fasi. Sebbene i
processi siano qui presentati come elementi distinti con interfacce ben definite, nella
pratica essi possono parzialmente sovrapporsi o interagire in modi diversi da quelli
descritti. Le interazioni tra processi sono trattate in dettaglio nel capitolo 3.

179
Capitolo 8 Gestione della qualit di progetto
L'approccio alla gestione della qualit descritto in questa sezione stato pensato
per essere compatibile con quello definito dallISO (International Organization for
Standardization). Questo approccio generico dovrebbe essere anche compatibile con
altri approcci proprietari alla gestione della qualit quali quelli consigliati da Deming,
Juran, Crosby ed altri, nonch con altri approcci non proprietari tra cui Total Quality
Management (TQM), Six Sigma, Failure Mode and Effect Analysis, Design Reviews,
Voice of the Customer, Cost of Quality (COQ) e Continuous Improvement.
La gestione della qualit di progetto riguarda sia la gestione del progetto che del
prodotto del progetto. Mentre la gestione della qualit di progetto si applica a tutti i
progetti, a prescindere dalla natura del prodotto, le misurazioni e le tecniche relative
alla qualit del prodotto sono specifiche di un determinato tipo di prodotto realizzato
dal progetto. Ad esempio, la gestione della qualit del software implica approcci e
misurazioni diversi da quelli richiesti dalle centrali nucleari, mentre gli approcci
relativi alla gestione della qualit di progetto sono gli stessi. In entrambi i casi il
mancato raggiungimento dei requisiti di qualit in una delle due dimensioni pu avere
conseguenze negative per alcuni o anche tutti gli stakeholder di progetto. Ad esempio:
Soddisfare i requisiti del cliente costringendo il gruppo di progetto a troppo
lavoro straordinario pu produrre conseguenze negative quali laumento delle
dimissioni dei dipendenti, la generazione di errori altrimenti evitabili o di
esigenze di correzioni ai prodotti.
Raggiungere gli obiettivi di schedulazione di progetto tralasciando le ispezioni
di qualit pianificate pu produrre conseguenze negative se questo non consente
di identificare gli errori.
La qualit il grado di conformit ai requisiti di una serie di caratteristiche
intrinseche (American Society for Quality, 2000)6. Le esigenze implicite e dichiarate
sono gli input per lo sviluppo dei requisiti di progetto. Un elemento essenziale della
gestione della qualit in un contesto di progetto trasformare in requisiti le esigenze,
le necessit e le aspettative degli stakeholder tramite l'analisi degli stakeholder
(paragrafo 5.2.2.4), eseguita nella gestione dell'ambito del progetto.
Qualit e livello non sono sinonimi. Il livello una categoria assegnata a
prodotti o servizi che hanno funzionalit uguali, ma caratteristiche tecniche differenti7.
La bassa qualit sempre un problema; un basso livello pu anche non esserlo. Ad
esempio, un prodotto software pu essere di alta qualit (nessun difetto evidente,
manuale leggibile) e di livello limitato (numero limitato di funzioni) oppure di bassa
qualit (molti difetti, documentazione utente disorganica) e di alto livello (elevato
numero di funzioni). Il project manager e il gruppo di Project Management hanno la
responsabilit di definire e produrre il grado di qualit e livello opportuni.
Precisione e accuratezza non si equivalgono. Per precisione si intende uniformit
nei valori di pi misurazioni ripetute, che presentano valori omogenei poca
dispersione. Per accuratezza si intende la correttezza del valore misurato, cio la sua
vicinanza al valore reale. Misurazioni precise non sono necessariamente accurate. Una
misurazione estremamente accurata non necessariamente precisa. Il gruppo di
Project Management deve determinare quali sono laccuratezza e/o la precisione
richieste.
180

La moderna gestione della qualit rappresenta un'integrazione al Project

Management. Ad esempio, ambedue le discipline riconoscono limportanza dei
seguenti fattori:
Soddisfazione del cliente: comprendere, valutare, definire e gestire le
aspettative affinch i requisiti del cliente vengano rispettati. Ci richiede una
combinazione di conformit ai requisiti (il progetto deve produrre ci si era
affermato di voler produrre) e idoneit alluso (il prodotto o il servizio deve
soddisfare esigenze reali).
Prevenzione anzich ispezione: il costo di prevenzione degli errori
generalmente inferiore al costo della correzione degli errori rilevati
dallispezione.
Responsabilit gestionale: il successo richiede la partecipazione di tutti i
membri del gruppo, ma la responsabilit di fornire le risorse necessarie per
raggiungere il successo della direzione.
Miglioramento continuo: il ciclo "plan-do-check-act" alla base del
miglioramento della qualit (secondo la definizione di Shewhart modificata da
Deming, nell'ASQ Handbook, pag. 1314, American Society for Quality, 1999).
Inoltre, le iniziative di miglioramento della qualit intraprese dalla Performing
Organization, quali TQM e Six Sigma, possono contribuire a migliorare la
qualit della gestione del progetto, sia la qualit del prodotto del progetto. Fra i
modelli di miglioramento dei processi possiamo inserire Malcolm Baldrige,
CMM e CMMISM.
Il costo della qualit si riferisce al costo totale di tutti gli impegni relativi alla
qualit. Le decisioni relative al progetto possono incidere sui costi operativi della
qualit dovuti alle rese dei prodotti, al costo del lavoro in garanzia e al ritiro di
prodotti dal commercio. Tuttavia, a causa della natura temporanea del progetto, gli
investimenti nel miglioramento della qualit del prodotto, e in particolare la
prevenzione e la valutazione dei difetti, vengono spesso sostenuti dall'organizzazione
acquirente e non dal progetto stesso, che potrebbe non avere una durata sufficiente per
raccogliere i frutti maturati.

181
Figura 8-1. Visione dinsieme della gestione della qualit di progetto
182

Figura 8-2. Diagramma di flusso dei processi di gestione della qualit di progetto
8.1
Pianificazione della qualit

Pianificare la qualit consiste nellidentificare gli standard di qualit rilevanti per il
progetto e delle modalit per soddisfarli. uno dei processi essenziali del gruppo di
processi di pianificazione (paragrafo 3.3) e per lo sviluppo del piano di Project
Management (paragrafo 4.3) che dovrebbe essere eseguito contemporaneamente agli
altri processi di pianificazione di progetto. Ad esempio, le modifiche del prodotto
richieste per soddisfare gli standard di qualit identificati possono comportare un
adeguamento dei costi e della schedulazione, oppure la qualit del prodotto desiderata
pu richiedere unanalisi dettagliata dei rischi connessi a un determinato problema.

183
Le tecniche di pianificazione della qualit qui illustrate sono quelle pi

frequentemente utilizzate nei progetti. Esistono molte altre tecniche che possono
essere utili in alcuni progetti o in alcune aree applicative. Uno dei principi
fondamentali della moderna gestione della qualit : la qualit viene pianificata,
progettata e realizzata, non ispezionata.
Figura 8-3. Pianificazione della qualit: Input, Strumenti e tecniche e Output
8.1.1
Pianificazione della qualit: Input
.1

I regolamenti, le regole, gli standard e le direttive degli enti governativi specifici
dell'area applicativa possono influenzare il progetto (paragrafo 4.1.1.3).
.2

Le politiche, le procedure e le direttive organizzative in materia di qualit, i database
storici e le lesson learned ricavate da precedenti progetti specifici dell'area applicativa
possono influenzare il progetto (paragrafo 4.1.1.4).
La politica sulla gestione della qualit cos come viene sostenuta dai vertici
aziendali, indica la direzione uniche la Performing Organization intende seguire in
materia di qualit. La politica sulla gestione della qualit dei prodotti della Performing
Organization pu in genere essere adottata cos com anche nello svolgimento del
progetto. Tuttavia, se la Performing Organization non dispone di una politica formale
di gestione della qualit o se il progetto coinvolge pi organizzazioni (come in una
joint venture), sar il gruppo di Project Management a dover sviluppare una politica di
gestione della qualit specifica per il progetto.
A prescindere dallorigine della politica per la qualit, il gruppo di Project
Management tenuto ad assicurarsi che gli stakeholder del progetto siano a
conoscenza della politica attraverso unappropriata distribuzione delle informazioni
.3

La descrizione dell'ambito del progetto (paragrafo 5.2.3.1) l'input essenziale per la
pianificazione della qualit poich documenta i principali deliverable del progetto, gli
obiettivi del progetto che consentono di definire requisiti (ricavati dalle esigenze, dalle
necessit e dalle aspettative degli stakeholder), le soglie e i criteri di accettazione.
184

Le soglie, definite come valori di costo, di tempo o di risorse utilizzati come

parametri, possono essere una componente della descrizione dell'ambito del progetto.
Se i valori delle soglie vengono superati, il gruppo di Project Management dovr
prendere provvedimenti.
I criteri di accettazione comprendono i requisiti di prestazione e le condizioni
essenziali che necessario soddisfare affinch i deliverable di progetto possano essere
accettati. La definizione dei criteri di accettazione pu incrementare o ridurre in modo
significativo i costi della qualit del progetto. Il fatto che i deliverable soddisfino tutti i
criteri di accettazione implica che tutte le esigenze del cliente sono state soddisfatte.
L'accettazione formale (paragrafo 5.4.3.1) attesta che i criteri di accettazione sono stati
soddisfatti. Nella descrizione delle specifiche di prodotto, contenuta nella descrizione
dell'ambito del progetto (paragrafo 5.2.3.1), spesso si specificano i dettagli delle
questioni tecniche e di altri problemi che possono avere un impatto sulla
pianificazione della qualit.
.4
8.1.2
.1

Pianificazione della qualit: Strumenti e tecniche

Analisi costi-benefici
Nel pianificare la qualit si deve tenere conto dellequilibrio tra costi e benefici. Il
vantaggio principale derivante dal rispetto dei requisiti di qualit la riduzione delle
attivit di correzione del prodotto, che si traduce in una pi elevata produttivit, minori
costi e aumento della soddisfazione degli stakeholder. Il costo principale per il rispetto
dei requisiti di qualit la spesa associata alle attivit di gestione della qualit di
progetto.
.2
Benchmarking
Il benchmarking comporta il confronto tra le pratiche del progetto, effettive o
pianificate, e quelle di altri progetti al fine di produrre idee per il miglioramento e
fornire una base di misurazione delle prestazioni. Gli altri progetti possono essere
allinterno della Performing Organization o esterni e possono riguardare la stessa area
applicativa o aree diverse.
.3
Design of Experiments
Il Design of Experiments (DOE) un metodo statistico che consente di identificare
quali fattori siano in grado di influenzare specifiche variabili di un prodotto o
processo, in fase di elaborazione o in produzione. Il DOE ha inoltre un ruolo
importante nell'ottimizzazione dei prodotti o dei processi. Per esempio,
un'organizzazione potrebbe utilizzare il DOE per ridurre la sensitivit delle prestazioni
del prodotto rispetto a fonti di variazione causate da differenze ambientali o
produttive. L'aspetto pi importante di questa tecnica che fornisce un quadro di
riferimento statistico in cui modificare in modo sistematico tutti i fattori di rilievo
anzich modificare un solo fattore alla volta. L'analisi dei dati sperimentali dovrebbe
fornire informazioni sulle condizioni ottimali per lo sviluppo del prodotto o processo,
mettendo in evidenza i fattori che influenzano i risultati e rivelando la presenza di
interazioni e sinergie tra i fattori. Ad esempio, i progettisti del settore automobilistico
utilizzano questa tecnica per determinare quale combinazione di sospensioni e
pneumatici sia in grado di produrre le migliori caratteristiche di guida del mezzo ad un
costo ragionevole.

185
.4
Costo della qualit (COQ)

I costi della qualit sono i costi totali che si sostengono nel fare investimenti
finalizzati a evitare la non conformit ai requisiti, a valutare la conformit ai requisiti
del prodotto o servizio e per rimediare al il mancato rispetto dei requisiti (correzioni).
I costi di non conformit vengono spesso classificati in interni ed esterni e sono anche
definiti costo della scarsa qualit.
.5
Ulteriori strumenti di pianificazione della qualit

Ci sono anche altri strumenti di pianificazione della qualit che aiutano a meglio
definire la situazione e che favoriscono una pi efficace pianificazione delle attivit di
gestione della qualit. Tra queste attivit troviamo il brainstorming, i diagrammi di
affinit, lanalisi dei campi di forza, le tecniche nominal group, i diagrammi a matrice,
i diagrammi di flusso e le matrici di priorit.
8.1.3
Pianificazione della qualit: Output
.1
Piano di gestione della qualit

Il piano di gestione della qualit descrive la modalit di attuazione delle politiche di
gestione della qualit della Performing Organization da parte del gruppo di Project
Management. Il piano contenuto nel piano di Project Management o ne costituisce
una parte ausiliaria (paragrafo 4.3).
Il piano di gestione della qualit fornisce un input per l'intero Piano di Project
Management e deve descrivere il controllo di qualit (QC), l'assicurazione qualit
(QA) e il miglioramento continuo dei processi del progetto.
Il piano di gestione della qualit pu essere formale o informale, dettagliato o
sintetico, a seconda delle esigenze del progetto. Deve inoltre prevedere, nelle fasi
iniziali del progetto, unattivit finalizzata a garantire la correttezza delle prime
decisioni che si prendono, ad esempio in materia di concezione, progettazione e
collaudo. Questattivit dovrebbe essere eseguita attraverso una revisione tra pari, i
cui partecipanti per non devono essere persone coinvolte nella preparazione del
materiale sottoposto ad esame. Tra i benefici dell'esame va segnalata la riduzione
dello sforamento di costi e di schedulazione dovuti ai rifacimenti.
.2
Metriche di qualit
Una metrica una definizione operativa che descrive, con termini estremamente
specifici, un elemento del prodotto o servizio e il modo in cui questo elemento viene
misurato dal processo di controllo della qualit. Una misurazione un valore. Ad
esempio, non sufficiente affermare che il rispetto delle date di schedulazione
pianificate costituisce una misura della qualit della gestione. Il gruppo di Project
Management deve anche indicare se ciascuna attivit debba iniziare puntualmente o
soltanto terminare come previsto, se debbano essere misurate le singole attivit o solo
determinati deliverable e, in tal caso, quali. Le metriche della qualit vengono
utilizzate nei processi di assicurazione qualit e di controllo di qualit. Alcuni esempi
di metriche di qualit sono la densit dei difetti, il tasso di non conformit, la
disponibilit, affidabilit e ampiezza dei collaudi.
186

.3
Liste di controllo qualit

Una lista di controllo un documento strutturato che riguarda in genere singoli
componenti, utilizzato per verificare che una serie di passaggi necessari sia stata
eseguita completamente. Le liste di controllo possono essere semplici o complesse.
Utilizzano generalmente la forma imperativa (fai questo) o interrogativa ( stato
fatto questo?). Molte organizzazioni dispongono di liste di controllo standardizzate
che consentono loro di garantire l'uniformit delle attivit eseguite frequentemente. In
alcune aree applicative, le liste di controllo sono disponibili anche presso le
associazioni di categoria o i fornitori di servizi. Le liste di controllo si usano nei
processi di controllo qualit.
.4
Piano di miglioramento dei processi

Il piano di miglioramento dei processi un elemento ausiliario del piano di Project
Management (paragrafo 4.3) che descrive in modo dettagliato i passaggi necessari per
analizzare i processi; tali passaggi aiutano a identificare gli sprechi e le attivit senza
valore aggiunto producendo un aumento di valore per il cliente. Di seguito ne
vengono descritti alcuni:
Confini dei processi: consente di descrivere lo scopo, l'inizio e la fine dei
processi, i loro input e output, i dati eventualmente necessari e il responsabile e
gli stakeholder dei processi.
Configurazione dei processi: un diagramma di flusso dei processi che
semplifica l'analisi con le interfacce identificate.
Metriche dei processi: consentono di mantenere il controllo sullo stato dei
processi.
Obiettivi per il miglioramento delle prestazioni: orientano le attivit di
miglioramento dei processi.
Baseline della qualit
La baseline della qualit registra gli obiettivi di qualit del progetto e fa parte della
baseline di misurazione delle prestazioni. Costituisce la base per la misurazione e il
reporting delle prestazioni della qualit.
.5
.6
8.2

Il piano di Project Management viene aggiornato aggiungendovi i piani ausiliari di
gestione qualit e di miglioramento dei processi (paragrafo 4.3). Le richieste di
modifica al piano di Project Management e ai piani ausiliari (aggiunte, modifiche,
eliminazioni) vengono elaborate per l'analisi e la decisione mediante il processo di
controllo integrato delle modifiche (paragrafo 4.6).
Effettuare l'assicurazione qualit

L'assicurazione qualit (QA) consiste nellintraprendere attivit di gestione qualit
pianificate e sistematiche per garantire che il progetto utilizzi tutti i processi necessari
a soddisfare i requisiti.
Generalmente le attivit di assicurazione qualit sono controllate dal reparto di
assicurazione qualit, o da un'organizzazione analoga. Il supporto all'assicurazione
qualit, a prescindere dal nome dell'unit aziendale, pu essere fornito al gruppo di
progetto, alla direzione della Performing Organization, al cliente o allo sponsor, o ad
altri stakeholder non attivamente coinvolti nel lavoro del progetto. L'assicurazione
qualit fornisce anche un supporto per un'altra importante attivit di gestione qualit:
il miglioramento continuo dei processi, che costituisce un mezzo iterativo per il
miglioramento della qualit di tutti i processi.

187
Il miglioramento continuo dei processi riduce gli sprechi e le attivit senza

valore aggiunto e consente in tal modo di incrementare il livello di efficienza ed
efficacia operativa dei processi. Una caratteristica del miglioramento dei processi
l'identificazione e l'esame dei processi organizzativi gestionali. Pu essere applicato
anche ad altri processi all'interno di un'organizzazione, dai microprocessi, quali la
codifica dei moduli di un programma software, ai macroprocessi, quali l'apertura di
nuovi mercati.
Figura 8-4. Effettuare l'assicurazione qualit: Input, Strumenti e tecniche e Output
8.2.1
Effettuare l'assicurazione qualit: Input
.1

Il piano di gestione della qualit descrive le modalit di esecuzione del controllo di
qualit all'interno del progetto (paragrafo 8.1.3.1).
.2
Metriche di qualit
.3
Piano di miglioramento dei processi

.4

Le informazioni sullo stato di avanzamento del lavoro (paragrafo 4.4.3.7), comprese le
misurazioni delle prestazioni tecniche, lo stato dei deliverable di progetto, le azioni
correttive necessarie e i report sulle prestazioni (paragrafo 10.3.3.1) sono input
importanti del controllo qualit e possono essere utilizzanti per le verifiche, le
revisioni della qualit e lanalisi dei processi.
.5

Le richieste di modifica approvate (paragrafo 4.4.1.4) possono riguardare metodi di
lavoro, requisiti del prodotto, requisiti di qualit, ambito e schedulazione. necessario
analizzare gli eventuali effetti delle modifiche approvate sul piano di gestione della
qualit, sulle metriche di qualit o sulle liste di controllo di qualit. Le richieste di
modifica approvate sono un input importante per il controllo di qualit e si usano in
aree quali le verifiche, le revisioni della qualit e lanalisi dei processi. Tutte le
modifiche devono essere documentate formalmente per iscritto; si sconsiglia di
elaborare o implementare qualsiasi modifica discussa verbalmente ma non
documentata.
188

.6
Misurazioni del controllo qualit

Le misurazioni del controllo qualit (paragrafo 8.3.3.1) sono i risultati delle attivit di
controllo qualit re-immesse nel processo di controllo qualit per essere utilizzate
nelle successive valutazioni e nell'analisi degli standard di qualit e dei processi della
Performing Organization.
.7
Richieste di modifica implementate

.8
Azioni correttive implementate

.9
Correzione dei difetti implementata

.10
Azioni preventive implementate

8.2.2
Effettuare l'assicurazione qualit: Strumenti e tecniche
.1
Strumenti e tecniche per la pianificazione della qualit

possibile utilizzare gli strumenti e le tecniche per la pianificazione della qualit
(paragrafo 8.1.2) per le attivit di controllo qualit.
.2
Verifiche della qualit

La verifica della qualit un esame strutturato e indipendente volto a determinare la
conformit delle attivit di progetto alle politiche, ai processi e alle procedure
dell'organizzazione e del progetto. L'obiettivo di una verifica della qualit
identificare politiche, processi e procedure del progetto che risultano essere
inefficienti e inefficaci. Il successivo sforzo di correzione di tali carenze dovrebbe
produrre una riduzione del costo della qualit e un aumento percentuale
dellaccettazione del prodotto o servizio da parte del cliente o dello sponsor all'interno
della Performing Organization. Le verifiche della qualit possono essere programmate
o casuali e possono essere eseguite da personale interno appositamente addestrato o da
terzi esterni alla Performing Organization.
Le verifiche della qualit consentono di confermare l'implementazione delle
richieste di modifica approvate, delle azioni correttive, delle correzioni dei difetti e
delle azioni preventive.
.3
Analisi dei processi

L'analisi dei processi segue i passi indicati nel piano di miglioramento dei processi per
identificare i miglioramenti necessari dal punto di vista organizzativo e tecnico.
L'analisi esamina inoltre i problemi riscontrati, i vincoli rilevati e le attivit senza
valore aggiunto identificate durante lo svolgimento dei processi. Lanalisi dei processi
comprende inoltre l'analisi delle cause originarie, una particolare tecnica finalizzata ad
esaminare un problema o una situazione, determinare le cause che l'hanno generata e
creare delle azioni preventive per problemi analoghi.
.4
Strumenti e tecniche per il controllo di qualit

Per la descrizione, consultare il paragrafo 8.3.2.

189
8.2.3
8.3
Effettuare l'assicurazione qualit: Output
.1
Il miglioramento della qualit implica azioni volte a incrementare l'efficacia e
l'efficienza delle politiche, dei processi e delle procedure della Performing
Organization, che devono garantire benefici ulteriori agli stakeholder di tutti i progetti
.2

Il miglioramento della qualit implica il suggerimento di azioni volte a incrementare
l'efficacia e l'efficienza della Performing Organization. Un'azione correttiva
un'azione consigliata identificata nel corso delle attivit di assicurazione qualit, ad
esempio le verifiche e le analisi dei processi.
.3

Un aggiornamento degli standard di qualit rappresenta la convalida dell'efficacia e
dell'efficienza degli standard di qualit e dei processi della Performing Organization
nel rispettare i requisiti. Questi standard di qualit si utilizzano durante il processo di
Esecuzione del controllo di qualit (paragrafo 8.3).
.4

Il piano di Project Management (paragrafo 4.3) viene aggiornato con le modifiche
apportate al piano di gestione della qualit che derivano a loro volta da variazioni
applicate al processo Esecuzione dell'assicurazione qualit. Tali aggiornamenti
possono comprendere l'integrazione dei processi oggetto del miglioramento continuo
e che sono quindi pronti per ripetere il ciclo, nonch i miglioramenti ai processi che
sono stati identificati e misurati e che possono quindi essere implementati. Le richieste
di modifica al piano di Project Management e ai relativi piani ausiliari (aggiunte,
modifiche, eliminazioni) vengono elaborate tramite l'analisi e la decisione mediante il
processo di controllo integrato delle modifiche (paragrafo 4.6).
Esecuzione del controllo di qualit

L'esecuzione del controllo di qualit prevede il monitoraggio di specifici risultati di un
progetto per determinare la loro rispondenza agli standard di qualit definiti e per
individuare i metodi per eliminare le cause di risultati non soddisfacenti. Questo
processo dovrebbe essere attuato durante tutto il progetto. Gli standard di qualit
riguardano sia i processi del progetto che gli obiettivi del prodotto. I risultati del
progetto comprendono i deliverable e i risultati di Project Management, quali le
prestazioni dei costi e della schedulazione. Il controllo di qualit viene generalmente
eseguito da un reparto denominato controllo qualit o da un'unit aziendale simile.
Nel controllo di qualit si possono intraprendere azioni allo scopo di eliminare le
cause di prestazioni di progetto non soddisfacenti.
Al fine di valutare pi correttamente gli output del controllo qualit, il gruppo di
progetto dovrebbe avere una conoscenza pratica del controllo qualit statistico, in
particolare pre quanto riguarda il campionamento e il calcolo delle probabilit. Altra
competenza utile al gruppo la capacit di saper distinguere tra le coppie di termini
elencate di seguito:
190

Prevenzione (evitare che si presentino errori durante il processo) e ispezione

(evitare che gli errori arrivino al cliente).
Campionamento per attributi (il risultato conforme o non lo ) e
campionamento delle variabili (il risultato valutato su una scala continua che
misura il livello di conformit).
Cause straordinarie (eventi insoliti) e cause comuni (variazione del processo
normale). Le cause comuni vengono definite anche cause casuali.
Tolleranza (il risultato accettabile se rientra nellintervallo di tolleranza
specificato) e limiti di controllo (il processo sotto controllo se i risultati
rientrano allinterno del limiti di controllo).
8
Figura 8-5. Esecuzione del controllo di qualit: Input, Strumenti e tecniche e Output
8.3.1
Esecuzione del controllo di qualit: Input
.1

.2
Metriche di qualit
.3
Liste di controllo della qualit

.4

.5

Le informazioni sullo stato di avanzamento del lavoro (paragrafo 4.4.3.7), comprese le
misurazioni delle prestazioni tecniche, lo stato di completamento dei deliverable di
progetto e l'implementazione delle azioni correttive richieste sono input di rilievo per
il controllo qualit. Devono essere disponibili le informazioni ricavate dal piano di
Project Management sui risultati pianificati o previsti, oltre alle informazioni sui
risultati effettivi e sulle richieste di modifica implementate.

191
.6

Tra le richieste di modifica approvate (paragrafo 4.4.1.4) ci possono essere la
revisione dei metodi di lavoro e la revisione della schedulazione. necessario
verificare l'implementazione tempestiva e corretta delle modifiche approvate.
.7
Deliverable
8.3.2
Esecuzione del controllo di qualit: Strumenti e tecniche

Tra gli strumenti descritti in questa sezione, i primi sette vengono in genere definiti
come i Sette strumenti di base della qualit (Seven Basic Tools of Quality).
.1
Diagramma di causa-effetto
I diagrammi di causa-effetto, detti anche diagrammi di Ishikawa o diagrammi a lisca
di pesce, illustrano il modo in cui vari fattori possono essere collegati a potenziali
problemi o effetti. La figura 8-6 un esempio di un diagramma di causa-effetto.
Figura 8-6. Diagramma di causa-effetto.
.2
Carte di controllo
La funzione di una carta di controllo determinare se un processo sia o meno stabile o
se le sue prestazioni siano prevedibili. Le carte di controllo possono essere utilizzate
come strumenti per la raccolta di dati allo scopo di mostrare quando un processo
soggetto a una variazione per cause straordinarie, che crea una condizione fuori
controllo. Consentono inoltre di illustrare il modo in cui un processo si comporta nel
corso del tempo. Sono rappresentazioni grafiche dell'interazione delle variabili di
processo allinterno di un processo e rispondono alla domanda: Le variabili di
processo rientrano in limiti di accettabilit?. L'esame della distribuzione non casuale
dei punti relativi ai dati in una carta di controllo pu evidenziare valori con una
fluttuazione eccessiva, improvvisi balzi o cambiamenti di direzione del processo o una
graduale tendenza verso un aumento della variazione. Monitorando l'output di un
processo nel corso del tempo, si pu usare una carta di controllo per valutare se
l'applicazione delle modifiche al processo ha prodotto i miglioramenti auspicati.
Quando un processo rientra nei limiti di accettabilit, non necessario sottoporlo ad
alcun adeguamento; quando invece non rientra nei limiti di accettabilit, necessario
fare degli aggiustamenti. Il limite di controllo superiore e quello inferiore sono
generalmente impostati su +/- 3 sigma (dove sigma rappresenta la deviazione
standard).
192

Le carte di controllo si usano per i processi del ciclo di vita sia dei progetti che
dei prodotti. Un esempio dell'utilizzo di una carta di controllo per un progetto consiste
nel determinare se gli scostamenti dei costi o gli scostamenti dei tempi siano al di
fuori dei limiti di accettabilit (ad es. +/- 10%). Un esempio dell'utilizzo di una carta
di controllo per un prodotto consiste invece nel valutare se il numero di difetti rilevati
durante il collaudo sia o meno accettabile rispetto agli standard di qualit
dell'organizzazione.
Le carte di controllo possono essere utilizzate per monitorare qualsiasi tipo di
variabile di output. Sebbene siano pi spesso utilizzate per misurare azioni ripetitive,
come alcune produzioni industriali, le carte di controllo possono anche essere
impiegate per monitorare gli scostamenti di costi e tempi, lampiezza e la frequenza
delle modifiche all'ambito del progetto, gli errori nei documenti di progetto o altri
risultati gestionali al fine di determinare se il processo di Project Management sotto
controllo. La figura 8-7 rappresenta un esempio di carta di controllo per le prestazioni
di una schedulazione di progetto.
Figura 8-7. Esempio di una carta di controllo delle prestazioni di una schedulazione di
progetto
.3
Diagramma di flusso
La creazione di diagrammi di flusso consente di analizzare come si verificano i
problemi. Un diagramma di flusso una rappresentazione grafica di un processo.
Bench esistano numerosi stili, tutti i diagrammi di flusso dei processi mostrano le
attivit, i punti di decisione e l'ordine di elaborazione. I diagrammi di flusso mostrano
inoltre in che modo i diversi elementi di un sistema interagiscono tra loro. La figura 88 un esempio di diagramma di flusso di un processo di revisione della progettazione.
Sviluppare dei diagrammi di flusso pu consentire al gruppo di progetto di prevedere
come e quando possono manifestarsi problemi relativi alla qualit e di sviluppare
soluzioni per affrontarli.

193
Figura 8-8. Esempio di diagramma di flusso di processo
.4
Istogramma
Un istogramma un diagramma a barre che mostra una distribuzione di variabili.
Ogni colonna rappresenta un attributo o una caratteristica di un problema/ situazione.
L'altezza di ciascuna colonna rappresenta la frequenza relativa della caratteristica.
Questo strumento consente di identificare la causa dei problemi di un processo in base
alla forma e all'ampiezza della distribuzione.
194

Figura 8-9. Diagramma di Pareto
.5
Diagramma di Pareto
Il diagramma di Pareto un particolare tipo di istogramma, ordinato in base alla
frequenza degli avvenimenti, che mostra quanti difetti sono stati generati per tipo o
categoria di causa identificata (figura 8-9). La tecnica di Pareto si utilizza
principalmente per identificare e valutare le non conformit.
Nei diagrammi di Pareto, si utilizza l'ordinamento rispetto alla frequenza per
indirizzare l'azione correttiva. Il gruppo di progetto dovrebbe intraprendere per prime
le azioni per risolvere i problemi che stanno causando il maggior numero di difetti. I
diagrammi di Pareto sono concettualmente legati alla legge di Pareto, la quale afferma
che, dato un problema, una minoranza di cause produce la maggioranza degli effetti.
Si tratta del principio detto comunemente legge 80/20, dove il 20% delle cause
produce l80% degli effetti. I diagrammi di Pareto possono anche venire utilizzati per
sintetizzare tutti i tipi di dati per analisi di tipo 80/20.

195
.6
Run Chart
Un Run Chart mostra la cronologia e il pattern di una variazione. rappresentato da
un grafico a linee in cui i dati sono tracciati nell'ordine in cui si verificano gli eventi
associati. I Run Chart mostrano gli andamenti di un processo nel corso del tempo, le
variazioni nel corso del tempo o i cali e i miglioramenti di un processo nel corso del
tempo. L'analisi delle tendenze viene eseguita usando i Run Chart e comporta luso di
tecniche matematiche per prevedere i risultati futuri sulla base dei dati storici.
L'analisi delle tendenze si utilizza spesso a scopo di monitoraggio:
Prestazioni tecniche: quanti errori o difetti sono stati identificati e quanti non
sono stati corretti?
Prestazioni dei costi e della schedulazione: quante attivit per periodo sono
state completate facendo registrare scostamenti significativi?
.7
Diagramma di dispersione
Un diagramma di dispersione mostra il pattern della relazione tra due variabili. Questo
strumento consente al gruppo responsabile della qualit di studiare e identificare la
possibile relazione tra le modifiche osservate in due variabili. Vengono tracciate e
confrontate le variabili dipendenti e le variabili indipendenti. Pi i punti sono vicini a
una linea diagonale, pi sono strettamente correlati.
.8
Campionamento statistico
Il campionamento statistico comporta la scelta di una parte della popolazione di
interesse per lispezione (ad esempio, la selezione casuale di 10 disegni ingegneristici
da una lista di 75). Un buon campionamento spesso pu ridurre il costo del controllo
qualit. Esiste un'ampia letteratura sul campionamento statistico; in alcune aree
applicative, il gruppo di Project Management potrebbe dovere approfondire la
conoscenza di diverse tecniche di campionamento.
.9
Ispezione
Un'ispezione l'esame di un prodotto del lavoro finalizzata a determinare se questo
sia conforme agli standard. Generalmente, tra i risultati di un'ispezione vi sono delle
misurazioni. possibile condurre ispezioni a qualsiasi livello. Ad esempio, possibile
ispezionare i risultati di un'unica attivit, o il prodotto finale del progetto. Le ispezioni
sono anche denominate esami, peer review, audit e analisi passo-passo. In alcune aree
applicative, questi termini hanno significati pi limitati e specifici. Le ispezioni
consentono inoltre di convalidare le correzioni dei difetti.
.10
Esame della correzione dei difetti

L'esame della correzione dei difetti un'azione intrapresa dal reparto di controllo
qualit o da un ente analogo per garantire che i difetti del prodotto siano stati corretti e
che il prodotto sia quindi conforme ai requisiti e alle specifiche.
196

8.3.3
Esecuzione del controllo di qualit: Output
.1
Misurazioni del controllo qualit

Le misurazioni del controllo qualit rappresentano il risultato delle attivit di controllo
qualit e vengono re-immesse nell'assicurazione qualit (paragrafo 8.2) per valutare
nuovamente e analizzare gli standard di qualit e i processi della Performing
Organization.
.2

Gli elementi corretti vengono nuovamente ispezionati e quindi accettati o rifiutati
prima di notificare la decisione presa (paragrafo 4.4). Gli elementi rifiutati potrebbero
richiedere una ulteriore correzione dei difetti.
.3
Baseline della qualit (aggiornamenti)

.4

Le azioni correttive (paragrafo 4.5.3.1) comprendono le azioni intraprese in risposta a
una misurazione del controllo qualit che segnala che il processo di produzione o di
sviluppo eccede i parametri stabiliti.
.5

Le azioni preventive (paragrafo 4.5.3.2) comprendono le azioni intraprese per
anticipare una condizione che potrebbe eccedere i parametri stabiliti in un processo di
produzione o di sviluppo e che potrebbe essere stata segnalata da una misurazione del
controllo qualit.
.6
Se le azioni correttive o preventive consigliate richiedono una modifica al progetto,
necessario avviare una richiesta di modifica (paragrafo 4.4.3.2) secondo quanto
stabilito per il processo di controllo integrato delle modifiche.
.7

Un difetto si riscontra laddove un componente non risponde ai requisiti o alle
specifiche di prodotto e necessita di correzione o di sostituzione. In genere il reparto
di controllo qualit o un altro ente preposto si occupa di rilevare i difetti e di
consigliarne la correzione. Il gruppo di progetto tenuto al massimo impegno
possibile onde ridurre al minimo gli errori che causano la necessit di correzione dei
difetti. possibile utilizzare un registro dei difetti per tener traccia delle correzioni
consigliate. Tale procedura viene spesso implementata nell'ambito di un sistema
automatico di registrazione dei problemi.
.8

Liste di controllo compilate: se utilizzate, le liste di controllo compilate
dovrebbero essere inserite nella documentazione di progetto (paragrafo 4.1.1.4).
Documentazione delle lesson learned: le cause degli scostamenti, la logica che
ha determinato la scelta di determinate azioni correttive e altri tipi di lesson
learned derivate dal controllo qualit devono essere documentate
opportunamente e inserite in un database dei dati storici utilizzabile per il
progetto in corso e da parte della Performing Organization. Le lesson learned
vengono documentate depurante tutto il ciclo di vita del progetto o quantomeno
in fase di chiusura del progetto (paragrafo 4.1.1.4).

197
.9
Deliverable convalidati
Uno degli obiettivi del controllo qualit determinare la correttezza dei deliverable. I
deliverable convalidati sono i risultati dei processi di controllo qualit della fase di
esecuzione.
.10

Il piano di Project Management viene aggiornato al fine di riflettere le modifiche
apportate al piano di gestione della qualit che discendono a loro volta dalle modifiche
apportate durante l'esecuzione del processo di controllo qualit. Le richieste di
modifica al piano di Project Management e ai piani ausiliari (aggiunte, modifiche,
eliminazioni) vengono elaborate per l'analisi e la decisione mediante il processo di
controllo integrato delle modifiche (paragrafo 4.6).
198

CAPITOLO 9
Gestione delle risorse umane di progetto
La gestione delle risorse umane di progetto comprende i processi di organizzazione e
gestione del gruppo di progetto, che costituito da persone a cui sono stati assegnati
ruoli e responsabilit ai fini del completamento del progetto stesso. Sebbene spesso si
parli solo di assegnazione di ruoli e di responsabilit, va detto che i membri del
gruppo dovrebbero essere coinvolti anche in buona parte della pianificazione e dei
processi decisionali del progetto. Il loro coinvolgimento gi dalle prime fasi aggiunge
competenza al processo di pianificazione e rafforza limpegno dedicato al progetto. Il
tipo e il numero dei membri del gruppo di progetto possono variare con lavanzare del
progetto. I membri del gruppo di progetto vengono anche definiti staff del progetto.
Il gruppo di Project Management un sottoinsieme del gruppo di progetto ed
responsabile delle attivit di Project Management come la pianificazione, il controllo
e la chiusura. Questo gruppo viene anche chiamato gruppo centrale, esecutivo o di
leadership. Per i progetti di dimensioni ridotte, le responsabilit in capo al Project
Management possono essere condivise dallintero gruppo o amministrate
esclusivamente dal project manager. Lo sponsor del progetto collabora con il gruppo
di Project Management, fornendo in genere la propria assistenza per questioni come il
finanziamento del progetto, la chiarificazione delle problematiche legate allambito e
lesercizio della propria influenza su altri perch ne benefici il progetto.
La figura 9-1 mostra una visione dinsieme dei processi di gestione delle risorse
umane di progetto, mentre la figura 9-2 illustra un diagramma di flusso di tali processi
e dei relativi input, output e di altri processi correlati, appartenenti a aree di
conoscenza correlate. Di seguito vengono riportate le operazioni incluse nei processi
di gestione delle risorse umane di progetto:
9.1 Pianificazione delle risorse umane: identificazione e documentazione dei ruoli,
delle responsabilit e delle relazioni di reporting del progetto, cos come
creazione del piano di gestione del personale.
9.2 Acquisire il gruppo di progetto: ottenimento delle risorse umane necessarie a
portare a termine il progetto.
9.3 Sviluppare il gruppo di progetto: miglioramento delle competenze e
dellinterazione tra i membri del gruppo per incrementare le prestazioni del
progetto.
9.4 Gestire il gruppo di progetto: rilevamento delle prestazioni dei membri del
gruppo, comunicazione del feedback, risoluzione delle questioni e
coordinamento delle modifiche volto a migliorare le prestazioni del progetto.

199
Capitolo 9 Gestione delle risorse umane di progetto
Questi processi interagiscono sia tra loro sia con processi appartenenti anche ad
altre aree di conoscenza. Ogni processo pu richiedere lo sforzo di una o pi persone
o gruppi, secondo le necessit del progetto. Ciascun processo si verifica almeno una
volta per ogni progetto, ed in una o pi fasi di progetto, se il progetto diviso in fasi.
Sebbene i processi siano qui presentati come elementi distinti con interfacce ben
definite, nella pratica essi possono finire col sovrapporsi parzialmente o con
linteragire in modi diversi da quelli descritti. Le interazioni tra processi sono trattate
in dettaglio nel capitolo 3.
La figura 9-2 illustra i principali modi in cui la gestione delle risorse umane di
progetto interagisce con gli altri processi del progetto. Di seguito vengono riportati
esempi di interazioni che richiedono unulteriore pianificazione:
Dopo la creazione di una struttura di scomposizione del lavoro (WBS) effettuata
dai membri del gruppo di lavoro iniziali, potrebbe rivelarsi necessario integrare
il gruppo di lavoro tramite lacquisizione di altri membri.
Una volta completata lintegrazione di cui sopra, il livello di esperienza dei
membri del gruppo di lavoro pu accrescere o ridurre il rischio di progetto,
rendendo necessaria unulteriore pianificazione dei rischi.
Quando la stima delle durate dellattivit effettuata prima che si conoscano
tutti i membri del gruppo di progetto, i livelli effettivi di competenza dei membri
del gruppo di lavoro acquisiti possono modificare la durata dellattivit e la
schedulazione.
200

Figura 9-1. Visione dinsieme della gestione delle risorse umane di progetto

201
Figura 9-2. Diagramma di flusso dei processi di gestione delle risorse umane di progetto
9.1
Pianificazione delle risorse umane

La pianificazione delle risorse umane determina i ruoli, le responsabilit e le relazioni
di reporting del progetto e crea il piano di gestione del personale. possibile
determinare i ruoli del progetto sia per persone che per gruppi, che possono essere sia
interni che esterni alla struttura organizzativa responsabile del progetto. Il piano di
gestione del personale pu includere anche indicazioni sulla modalit e sui tempi di
acquisizione dei membri del gruppo di progetto, sui criteri per dimetterli dal progetto,
sullidentificazione delle esigenze in termini di formazione, sui piani di
riconoscimento e di assegnazione di premi, sulle considerazioni in materia di
conformit, sulle questioni di sicurezza e sullimpatto del piano di gestione del
personale sulla struttura organizzativa.
202

Figura 9-3. Pianificazione delle risorse umane: Input, Strumenti e tecniche e Output
9.1.1
.1
Pianificazione delle risorse umane: Input

La definizione dei ruoli e delle responsabilit del progetto viene sviluppata dopo aver
capito come saranno coinvolte le organizzazioni esistenti e come discipline tecniche e
persone normalmente interagiscono luna con laltra. Alcuni fattori ambientali
aziendali di rilievo (paragrafo 4.1.1.3) che coinvolgono la cultura e la struttura
dellorganizzazione sono:
Organizzativi: quali organizzazioni o reparti saranno coinvolti nel progetto?
Quali sono gli attuali accordi lavorativi in vigore tra di loro? Quali sono le
relazioni formali e informali instaurate tra di loro?
Tecnici: quali sono le diverse discipline e le specialit che saranno necessarie al
completamento del progetto? Ci sono diversi tipi di linguaggi software, approcci
tecnici o tipologie di attrezzature che devono essere coordinate? Le transazioni
da una fase del ciclo di vita a quella successiva presentano sfide mai affrontate?
Interpersonali: quali tipi di relazioni di reporting formali e informali sono
attualmente presenti tra le persone che sono candidate per il gruppo di progetto?
Quali sono le job description dei candidati? Come sono le loro relazioni
supervisore-subordinato? Come sono le loro relazioni fornitore-cliente? Quali
differenze culturali o linguistiche possono influire sulle relazioni lavorative tra i
membri del gruppo di lavoro? Qual attualmente il livello di fiducia e rispetto
instaurato?
Logistici: quanto sono distanti le persone e le unit che sono coinvolte nel
progetto? Le persone si trovano in edifici diversi, con fusi orari diversi o in paesi
diversi?
Politici: quali sono gli obiettivi individuali ed il programma delle attivita
previste dei potenziali stakeholder di progetto? Quali gruppi e persone sono
dotati di un potere informale in aree importanti per il progetto? Quali sono le
alleanze informali?

203
Oltre ai fattori sopraelencati, i vincoli limitano le opzioni a disposizione del

gruppo di progetto. Esempi di vincoli che possono limitare la flessibilit del processo
di pianificazione delle risorse umane sono:
Struttura organizzativa: unorganizzazione con una struttura di base a matrice
debole significa un ruolo relativamente pi debole per il project manager
(paragrafo 2.3.3).
Accordi salariali collettivi: accordi contrattuali con sindacati o altri gruppi
rappresentativi dei dipendenti possono richiedere ruoli o relazioni di reporting
chiaramente determinati.
Condizioni economiche: i blocchi delle assunzioni, i tagli ai fondi per la
formazione o lassenza di budget per le trasferte sono esempi di condizioni
economiche che possono limitare le opzioni del personale.
.2

Man mano che la metodologia di Project Management matura allinterno di una
struttura organizzativa, per supportare la pianificazione del progetto attuale, vengono
rese disponibili le lesson learned, precedenti di pianificazione delle risorse umane
ricavate dalle esperienze, sotto forma di asset dei processi organizzativi (paragrafo
4.1.1.4). Gli schemi di documento e le liste di controllo riducono i tempi di
pianificazione necessari allinizio di un progetto e la possibilit che siano tralasciate
responsabilit importanti.
Schemi di documento: gli schemi di documento che possono essere utili alla
pianificazione delle risorse umane comprendono gli organigrammi di progetto,
le descrizioni delle mansioni, le valutazioni delle prestazioni di progetto e un
approccio standard alla gestione dei conflitti.
Liste di controllo: le liste di controllo utili alla pianificazione delle risorse
umane comprendono ruoli e responsabilit di progetto usuali, competenze
tipiche, programmi di formazione da prendere in considerazione, regole di base
del gruppo, considerazioni sulla sicurezza, questioni relative alla conformit e
idee per riconoscimenti.
.3

Il piano di Project Management (paragrafo 4.3) comprende i requisiti delle attivit in
termini di risorse, oltre alle descrizioni delle attivit di Project Management tra cui
assicurazione della qualit, gestione dei rischi e approvvigionamento, che consentono
al gruppo di Project Management di identificare tutti i ruoli e le responsabilit
necessari.
Requisiti delle attivit in termini di risorse: la pianificazione delle risorse
umane si avvale dei requisiti delle attivit in termini di risorse(paragrafo 6.3.3.1)
per determinare le necessit del progetto. I requisiti preliminari relativi al
personale e alle competenze necessari per i membri del gruppo di progetto
vengono definiti in modo pi preciso nellambito del processo di pianificazione
delle risorse umane.
204

9.1.2
.1
Pianificazione delle risorse umane: Strumenti e tecniche

Organigramma e descrizioni delle mansioni
Sono disponibili vari formati per la documentazione dei ruoli e delle responsabilit dei
membri del gruppo. La maggior parte dei formati rientra in uno dei tre tipi seguenti
(figura 9-4): gerarchico, a matrice e descrittivo. Inoltre, alcune assegnazioni in merito
al progetto vengono riportate nei piani di progetto ausiliari, come i piani per i rischi, la
qualit e la comunicazione. A prescindere della combinazione di metodi adottata,
lobiettivo consiste nel garantire che ogni Work Package abbia un responsabile
identificato senza ambiguit e che tutti i membri del gruppo di lavoro comprendano a
fondo i propri ruoli e responsabilit.
9
Figura 9-4. Formati di definizione di ruoli e responsabilit
Diagrammi di tipo gerarchico: lorganigramma tradizionale consente di

mostrare le posizioni e le relazioni in un formato grafico dallalto verso il basso.
Le strutture di scomposizione del lavoro (WBS), progettate principalmente per
mostrare come i deliverable di progetto vengano scomposti in Work Package,
diventano anche un valido strumento per evidenziare le aree di responsabilit di
alto livello. La struttura di scomposizione dellorganizzazione (OBS) molto
simile alla WBS, ma invece di essere ordinata in base alla scomposizione dei
deliverable di progetto, strutturata in base ai reparti, alle unit e ai gruppi
esistenti allinterno della struttura organizzativa. Le attivit di progetto o i Work
Package vengono elencati sotto ciascun reparto esistente. In questo modo, un
reparto operativo (come quello responsabile del settore informatico o degli
acquisti) ha la possibilit di visualizzare tutte le responsabilit di progetto
assegnategli direttamente dalla propria porzione della struttura di scomposizione
dellorganizzazione (OBS). La struttura di scomposizione delle risorse (RBS)
un ulteriore diagramma a struttura gerarchica che consente di scomporre il
progetto in base ai tipi di risorse. Ad esempio, una RBS pu raffigurare tutte le
saldatrici e lattrezzatura per saldatura utilizzate nelle diverse aree di una nave,
anche se sono sparse nelle diverse diramazioni della OBS e della WBS. La RBS
di aiuto nel tracciare i costi del progetto e pu essere allineata con i sistemi di
controllo della struttura organizzativa. La RBS contiene le categorie delle
risorse, ad eccezione delle risorse umane.

205
Diagrammi basati sulla matrice: la matrice di assegnazione delle

responsabilit (RAM) usata per illustrare le relazioni tra il lavoro che deve
essere eseguito e i membri del gruppo di progetto. Nei progetti pi grandi, si
possono sviluppare pi RAM e a vari livelli. Ad esempio, un RAM di alto
livello pu definire quale gruppo di progetto o unit siano responsabili di
ciascun componente della WBS, mentre livelli pi bassi di RAM sono usati
allinterno del gruppo per designare ruoli, responsabilit e livelli di autorit per
attivit specifiche. Il formato a matrice, chiamato a volte tabella, consente di
visualizzare tutte le attivit associate a una persona o tutte le persone associate a
unattivit. La matrice che appare nella figura 9-5 un tipo di RAM chiamato
diagramma RACI: i nomi dei ruoli documentati sono infatti Responsible,
Accountable, Consult e Inform. Nella colonna di destra del diagramma
esemplificativo riportato il lavoro da eseguire sotto forma di attivit, ma le
RAM possono mostrare le responsabilit a vari livelli di dettaglio. Le persone
possono poi essere rappresentate sotto forma di persone o gruppi.
Figura 9-5. Matrice di assegnazione delle responsabilit (RAM) che utilizza un formato
RACI
Formati descrittivi: le responsabilit dei membri del gruppo che richiedono

descrizioni dettagliate possono essere specificate nei formati descrittivi. In
genere in forma sintetica, i documenti forniscono informazioni su responsabilit,
autorit, competenze e qualifiche. I documenti sono conosciuti con nomi diversi,
tra cui moduli con la descrizione della mansione e moduli ruolo-responsabilitautorit. Tali moduli descrittivi costituiscono degli ottimi schemi di documento
per progetti futuri, specie nel caso in cui le informazioni vengano aggiornate
continuamente durante il progetto in corso applicando la tecnica delle lesson
learned.
Altre sezioni del piano di Project Management: alcune responsabilit
correlate alla gestione del progetto vengono riportate ed elencate in altre sezioni
del piano di Project Management. Ad esempio, il registro dei rischi riporta i
proprietari dei rischi, il piano di comunicazione elenca i membri del gruppo di
lavoro responsabili delle attivit di comunicazione e il piano di qualit designa
le persone responsabili dellesecuzione dellassicurazione qualit e delle attivit
di controllo della qualit.
206

.2
Networking
Linterazione informale con altre persone in una struttura organizzativa o in un settore
rappresenta un metodo costruttivo per comprendere i fattori politici e interpersonali
che influiscono sullefficacia delle diverse opzioni di gestione del personale. Le
attivit di networking delle risorse umane comprendono corrispondenza proattiva,
pranzi di lavoro, conversazioni informali e conferenze di settore. Sebbene il
networking concentrato rappresenti una valida tecnica allinizio di un progetto, anche
lesecuzione di attivit di networking a cadenza regolare prima dellinizio del progetto
pu rivelarsi molto efficace.
.3
Teoria organizzativa
La teoria organizzativa fornisce informazioni in merito al comportamento di persone,
gruppi e unit organizzative. Lapplicazione di principi consolidati riduce il tempo
necessario alla creazione degli output per la pianificazione delle risorse umane e
accresce le probabilit che la pianificazione sia efficace.
9.1.3
Pianificazione delle risorse umane: Output
.1
Ruoli e responsabilit
Al momento della creazione dellelenco dei ruoli e delle responsabilit necessari per
portare a termine il progetto, necessario prendere in considerazione anche:
Ruolo: etichetta che descrive la porzione di un progetto di cui responsabile
una persona. Alcuni esempi di ruoli di progetto possono essere ingegneri civili,
responsabili del collegamento con il tribunale, analisti aziendali e coordinatori
dei collaudi. Per garantire il successo del progetto, indispensabile chiarire la
natura del ruolo in termini di autorit, responsabilit e limiti.
Autorit: diritto di applicare le risorse al progetto, prendere decisioni e
sottoscrivere le approvazioni. Alcuni esempi di decisioni che richiedono una
chiara autorit includono la selezione di un metodo per il completamento di
unattivit, laccettazione della qualit e la risposta agli scostamenti di progetto.
I membri del gruppo di lavoro sono facilitati nella loro funzione quando i loro
livelli di autorit individuale corrispondono alle rispettive responsabilit.
Responsabilit: lavoro che deve essere eseguito dal membro del gruppo di
progetto per portare a termine le attivit del progetto.
Competenza: skill e capacit necessari a portare a termine le attivit del
progetto. Se i membri del gruppo di progetto non dispongono delle competenze
richieste, le prestazioni possono risultarne compromesse. Quando si identificano
divari di questa natura, vengono avviate delle risposte proattive come
formazione, assunzione, modifiche alla schedulazione o modifica dellambito.
.2
Organigrammi di progetto
Un organigramma di progetto una rappresentazione grafica dei membri del gruppo
di progetto e delle relative relazioni di reporting. Pu essere formale o informale,
dettagliato o sintetico, in base alle esigenze del progetto. Ad esempio, lorganigramma
di progetto per la creazione di un gruppo di risposta ai disastri composto da 3000
persone risulter pi dettagliato di un organigramma di un progetto interno composto
da 20 persone.

207
.3
Piano di gestione del personale

Il piano di gestione del personale, un sottoinsieme del piano di Project Management
(paragrafo 4.3), descrive quando e come dovranno essere rispettati i requisiti relativi
alle risorse. Il piano pu essere formale o informale, dettagliato o sintetico, in base ai
requisiti del progetto. Il piano viene aggiornato continuamente durante il progetto per
orientare le operazioni di acquisizione dei membri del gruppo durante lo svolgimento
del progetto e le azioni di sviluppo. Le informazioni contenute nel piano di gestione
del personale variano in base allarea applicativa e alle dimensioni del progetto;
tuttavia necessario tenere conto di una serie di elementi:
Acquisizione del personale: nel corso della pianificazione dellacquisizione dei
membri del gruppo di progetto, emergono una serie di domande. Ad esempio, le
risorse umane sono interne alla struttura organizzativa oppure sono esterne e
ottenute su base contrattuale? I membri del gruppo devono lavorare da una sede
centrale o possono svolgere le proprie mansioni da sedi lontane? Quali sono i
costi associati a ciascun livello di competenza richiesta per il progetto? In che
misura il reparto di gestione delle risorse umane della struttura organizzativa
in grado di fornire assistenza al gruppo di Project Management?
Tabella di marcia: il piano di gestione del personale descrive gli intervalli di
tempo necessari ai membri del gruppo di progetto, sia a livello individuale che
collettivo, e il periodo di inizio delle attivit di acquisizione come ad esempio
lassunzione. Uno degli strumenti per pianificare le risorse umane
listogramma delle risorse (paragrafo 6.5.3.2), un diagramma a barre che illustra
il numero di ore che saranno necessarie a una persona, un reparto o un intero
gruppo di progetto ogni settimana od ogni mese per lintera durata del progetto.
Il diagramma pu comprendere una linea orizzontale che rappresenta il numero
massimo di ore che una data risorsa mette a disposizione. Per le barre che si
estendono oltre il limite massimo di ore disponibili necessario adottare una
strategia di livellamento delle risorse, come laggiunta di ulteriori risorse o il
prolungamento della schedulazione. La figura 9-6 mostra un esempio di
istogramma delle risorse.
Figura 9-6. Istogramma delle risorse illustrativo
208

9.2
Criteri di dismissione dal progetto: la determinazione del metodo e dei tempi

di dismissione dei membri del gruppo di lavoro rappresenta un vantaggio tanto
per il progetto che per i membri del gruppo di lavoro. Quando i membri del
gruppo vengono dismessi dal progetto nel momento pi favorevole, possibile
annullare i pagamenti per le persone che hanno esaurito le proprie
responsabilit, riducendo cos i costi. La pianificazione di una transizione
graduale a progetti imminenti non pu che migliorare il morale del gruppo.
Esigenze in termini di formazione: se non previsto che i membri del gruppo
che devono essere assegnati dispongano di apposite competenze, possibile
sviluppare un piano di formazione che faccia parte del progetto. Il piano pu
includere inoltre dei sistemi che consentano ai membri del gruppo di lavoro di
ottenere delle certificazioni vantaggiose per il progetto.
Riconoscimenti e premi: criteri chiari per lassegnazione dei premi e un
sistema pianificato per il loro utilizzo promuovono e consolidano i
comportamenti desiderati. Per essere efficaci, i riconoscimenti e i premi devono
essere basati sulle attivit e sulle prestazioni sotto il controllo di una persona. Ad
esempio, se si deve premiare un membro del gruppo per avere rispettato gli
obiettivi di costo, questi deve disporre di un idoneo livello di controllo sulle
decisioni che influiscono sulle spese. Stilare un piano con tempi stabiliti per
lassegnazione dei premi garantisce che il riconoscimento del merito abbia
luogo e non venga tralasciato. Il riconoscimento e lassegnazione dei premi si
verificano nellambito del processo Sviluppare il gruppo di progetto (paragrafo
9.3).
Conformit: il piano di gestione del personale pu comprendere le strategie che
garantiscono la conformit alle normative governative in vigore, ai contratti
sindacali e ad altri criteri stabiliti per le risorse umane.
Sicurezza: possibile aggiungere nel piano di gestione del personale e nel
registro dei rischi i criteri e le procedure che proteggono i membri del gruppo di
lavoro da qualsiasi rischio per la propria sicurezza.
Acquisire il gruppo di progetto

Si tratta di un processo che consente di acquisire le risorse umane necessarie al
completamento del progetto. Il gruppo di Project Management pu disporre o meno
del controllo sui membri del gruppo selezionati per il progetto.
Figura 9-7. Acquisire il gruppo di progetto: Input, Strumenti e tecniche e Output

209
9.2.1
Acquisire il gruppo di progetto: Input
.1

I membri del gruppo di progetto provengono da tutte le fonti disponibili, sia interne
che esterne. Se il gruppo di Project Management in grado di influire od orientare le
assegnazioni del personale, le caratteristiche di cui tenere conto comprendono:
Disponibilit: chi disponibile e quando disponibile?
Capacit: di quali competenze dispongono le persone?
Esperienza: le persone hanno svolto lavori simili o correlati? Con buoni
risultati?
Interessi: le persone desiderano lavorare a questo progetto?
Costo: quanto viene pagato ogni membro del gruppo, in particolare quelli
acquisiti su base contrattuale e quindi esterni alla struttura organizzativa?
.2

Una o pi delle organizzazioni coinvolte nel progetto possono disporre di politiche,
direttive o procedure che regolano lassegnazione del personale (paragrafo 4.1.1.4).
Anche i reparti di gestione delle risorse umane possono collaborare allindividuazione,
allassunzione e allorientamento dei membri del gruppo di progetto.
.3
I ruoli e le responsabilit definiscono posizioni, skill e competenze richiesti dal
progetto (paragrafo 9.1.3.1).
.4
Gli organigrammi di progetto forniscono una visione dinsieme del numero di persone
necessarie per il progetto (paragrafo 9.1.3.2).
.5

Il piano di gestione del personale, insieme alla schedulazione di progetto, identifica i
periodi in cui si richiede la collaborazione di ciascun membro del gruppo di progetto e
altre informazioni importanti per lacquisizione del gruppo di progetto (paragrafo
9.1.3.3).
9.2.2
.1
Acquisire il gruppo di progetto: Strumenti e tecniche

Pre-assegnazione
In alcuni casi, i membri del gruppo di progetto sono gi noti, ovvero vengono preassegnati. Questa situazione si verifica se il progetto nasce da una proposta
competitiva che dipende dallimpiego di determinate persone, se il progetto dipende
dalle competenze di determinate persone o se alcune assegnazioni del personale
vengono definite nel Project Charter.
210

.2
Negoziazione
Per molti progetti, le assegnazioni del personale vengono negoziate. Ad esempio, il
gruppo di gestione di progetto deve avviare una trattativa con:
Manager funzionali per garantire che il progetto possa contare su personale
competente nei tempi richiesti e che i membri del gruppo di progetto siano in
grado di lavorare al progetto fino al compimento delle loro responsabilit.
Altri gruppi di Project Management allinterno della Performing Organization:
per assegnare in modo corretto risorse esigue o specializzate.
La capacit del gruppo di Project Management di influire sugli altri
fondamentale nella negoziazione delle assegnazioni del personale, e lo stesso vale per
la politica delle organizzazioni coinvolte (paragrafo 2.3.3). Ad esempio, nella fase in
cui si determina dove assegnare esecutori di qualit eccezionali ambiti da tutti i gruppi
di progetto, il manager funzionale deve soppesare i vantaggi e la visibilit dei progetti
in competizione.
.3
Acquisizione
Se la Performing Organization non dispone del personale interno necessario al
completamento del progetto, i servizi richiesti possono essere acquisiti da fonti esterne
(paragrafo 12.4.3.1), ad esempio mediante lassunzione di singoli consulenti o il
subappalto del lavoro ad unaltra struttura organizzativa.
.4
Gruppi virtuali
Luso di gruppi virtuali crea nuove possibilit nella fase di acquisizione dei membri
del gruppo di progetto. I gruppi virtuali possono essere definiti come gruppi di
persone che condividono un obiettivo comune e che adempiono al proprio ruolo senza
quasi incontrarsi mai di persona. La disponibilit di mezzi di comunicazione
elettronica, come le-mail e la videoconferenza, ha reso possibile la creazione di questi
gruppi. Il formato rappresentato dal gruppo virtuale consente di:
Formare gruppi di persone provenienti dalla stessa azienda ma residenti in aree
geografiche diverse e lontane.
Aggiungere competenze particolari a un gruppo di progetto, anche se lesperto
non si trova nella stessa area geografica.
Integrare in un gruppo i dipendenti che lavorano da casa.
Formare dei gruppi di persone con turni lavorativi o con orari diversi.
Includere portatori di handicap motori.
Far procedere i progetti che sarebbero stati ignorati a causa dei costi di trasferta.
La pianificazione della comunicazione (paragrafo 10.1) quindi un elemento
fondamentale nellambiente del gruppo virtuale. possibile che sia necessario altro
tempo per impostare aspettative chiare, per sviluppare i protocolli per fare fronte ai
conflitti, per coinvolgere le persone nel processo decisionale e per condividere il
merito dei successi ottenuti.

211
9.2.3
9.3
Acquisire il gruppo di progetto: Output
.1
Assegnazioni del personale di progetto

Lorganico del progetto viene creato con lassegnazione del personale adeguato al
lavoro previsto dal progetto stesso. La documentazione comprende una rubrica del
gruppo di progetto, dei promemoria indirizzati ai membri del gruppo di lavoro e i
nomi inseriti in altre parti del piano di Project Management, come gli organigrammi di
progetto e le schedulazioni.
.2

La disponibilit delle risorse documenta i periodi in cui ciascun membro del gruppo di
progetto pu lavorare al progetto. La preparazione di una schedulazione finale
affidabile (paragrafo 6.5.3.1) dipende dal grado di conoscenza dei conflitti di
schedulazione di ogni persona, compresi i periodi di ferie e gli impegni in altri
progetti.
.3
Piano di gestione del personale (aggiornamenti)

Poich persone specifiche ricoprono ruoli e responsabilit del progetto, potrebbero
rendersi necessarie delle modifiche al piano di gestione del personale (paragrafo
9.1.3.3) dal momento che non sempre le persone rispondono esattamente ai requisiti
pianificati per il personale. Altri motivi per cui si decide di modificare il piano di
gestione del personale comprendono promozioni, pensionamenti, malattie, questioni
relative al rendimento e variazioni del carico di lavoro.
Sviluppare il gruppo di progetto

Sviluppare il gruppo di progetto migliora le competenze e linterazione dei membri
del gruppo di lavoro e contribuisce quindi al miglioramento delle prestazioni del
progetto. Gli obiettivi sono:
Migliorare gli skill dei membri del gruppo per incrementare le loro capacit e
portare quindi a termine le attivit del progetto.
Migliorare il senso di fiducia e la coesione tra i membri del gruppo di lavoro per
incrementare la produttivit mediante un pi intenso lavoro di squadra.
Un lavoro di squadra efficace prevede, ad esempio, lassistenza reciproca in caso
di carichi di lavoro non equilibrati, la scelta delle modalit di comunicazione che pi
si addicono alle preferenze individuali e la condivisione delle informazioni e delle
risorse. Gli sforzi compiuti ai fini dello sviluppo del gruppo generano un maggiore
vantaggio se vengono svolti nelle fasi iniziali, anche se devono durare per lintero
ciclo di vita del progetto.
Figura 9-8. Sviluppare il gruppo di progetto: Input, Strumenti e tecniche e Output
212

9.3.1
Sviluppare il gruppo di progetto: Input
.1

Lo sviluppo del gruppo ha inizio con un elenco dei membri del gruppo di progetto. I
documenti sullassegnazione del personale del progetto (paragrafo 9.2.3.1)
identificano le persone che fanno parte del gruppo.
.2

Il piano di gestione del personale (paragrafo 9.1.3.3) identifica le strategie per la
formazione e i piani per lo sviluppo del gruppo di progetto. Con il procedere del
progetto, al piano vengono aggiunte voci quali premi, feedback, formazione
aggiuntiva e azioni disciplinari, a seguito delle valutazioni continue delle prestazioni
del gruppo (paragrafo 9.3.3.1) e di altre forme di gestione del gruppo di progetto
(paragrafo 9.4.2).
.3

Le informazioni sulla disponibilit delle risorse (paragrafo 9.2.3.2) identificano gli
orari in cui i membri del gruppo di progetto partecipano alle attivit di sviluppo del
gruppo.
9.3.2
Sviluppare il gruppo di progetto: Strumenti e tecniche
.1
Skill in materia di general management

Le capacit interpersonali (paragrafo 1.5.5), a volte denominate anche soft skill
sono particolarmente importanti per lo sviluppo del gruppo. Il gruppo di Project
Management pu ridurre notevolmente i problemi e potenziare la cooperazione tra i
membri del gruppo di progetto se in grado di comprenderne la psicologia,
anticiparne le azioni, riconoscerne le preoccupazioni e seguirne i problemi. Quando si
gestisce un gruppo di progetto, qualit come lempatia, la capacit di esercitare la
propria influenza, la creativit e lagevolazione del gruppo sono punti di forza
estremamente importanti.
.2
Formazione
La formazione include tutte le attivit dedicate al miglioramento delle competenze dei
membri del gruppo di progetto. La formazione pu essere sia formale che informale.
Esempi di metodi di formazione sono lezioni in classe, on-line, basate sul computer,
formazione sul posto di lavoro da parte di un altro membro del gruppo di progetto,
intervento di un mentore o di un coach.
Se i membri del gruppo di progetto non dispongono di skill gestionali o tecnici,
possibile sviluppare tali skill nellambito del lavoro di progetto. Una formazione
pianificata viene effettuata in conformit a quanto riportato nel piano di gestione del
personale. La formazione non pianificata si effettua invece come risultato di
osservazioni, conversazioni e valutazioni delle prestazioni del progetto condotte nel
corso del processo di controllo della gestione del gruppo di progetto.

213
.3
.4
.5
.6
Attivit di costruzione del gruppo

Le attivit di costruzione del gruppo possono variare da una semplice voce allordine
del giorno, a cui si dedicano non pi di cinque minuti in occasione di un incontro
sullanalisi dello stato di avanzamento, ad un incontro fuori sede con lintervento di
professionisti, concepito per migliorare le relazioni interpersonali. possibile che
alcune attivit del gruppo, come lo sviluppo della WBS, che non sono progettate
esplicitamente come attivit di costruzione del gruppo, ne incrementino tuttavia la
coesione, se lattivit di pianificazione strutturata e agevolata in modo efficace.
inoltre importante stimolare la comunicazione e le attivit informali poich sono
estremamente utili per alimentare la fiducia reciproca e per stabilire buoni rapporti di
lavoro. Le strategie di costruzione del gruppo sono particolarmente valide quando i
membri del gruppo tele-lavorano da sedi lontane, senza potersi vedere di persona.
Regole di base
Le regole di base stabiliscono aspettative chiare per quel che riguarda il comportamento
definito accettabile da parte dei membri del gruppo di progetto. Se ci si impegna fin da
subito a rispettare direttive chiare, diminuiscono le possibilit di incomprensioni a
vantaggio della produttivit. Il processo di discussione delle regole di base consente ai
membri del gruppo di lavoro di scoprire i valori ritenuti reciprocamente imprescindibili.
Una volta stabilite le regole, tutti i membri del gruppo di progetto condividono la
responsabilit di osservarle e di farle rispettare.
Co-location
La co-location prevede la collocazione in ununica sede fissa di molti o di tutti i membri
pi attivi del gruppo di progetto in modo da favorire la loro capacit di lavorare in
gruppo. La co-location pu essere sia temporanea, come nelle fasi strategicamente
importanti del progetto, oppure pu estendersi a tutta la durata del progetto. Questo tipo
di strategia prevede la presenza di una sala riunioni, a volte denominata War Room,
dotata di dispositivi di comunicazione elettronici, postazioni per linvio delle
schedulazioni e altri strumenti che favoriscono la comunicazione e consolidano il senso
di appartenenza a una comunit. Se da un lato la co-location considerata una valida
strategia, lutilizzo di gruppi virtuali consente dallaltro di ridurre la frequenza con la
quale i membri del gruppo di lavoro si riuniscono tutti in ununica sede.
Riconoscimenti e premi
Parte del processo di sviluppo del gruppo comporta il riconoscimento dei
comportamenti ritenuti meritevoli e il conferimento di premi a chi li ha tenuti. I piani
originali relativi alle modalit di premiazione delle persone vengono sviluppati nel corso
della pianificazione delle risorse umane (paragrafo 9.1). Le decisioni in merito
allassegnazione di premi vengono prese, formalmente o informalmente, nel corso del
processo di gestione del gruppo di progetto, attraverso la valutazione delle prestazioni
Vengono premiati soltanto i comportamenti ritenuti auspicabili. Ad esempio,
necessario premiare o riconoscere la volont di fare straordinari per poter raggiungere
un obiettivo di schedulazione aggressivo; non deve invece essere premiata la necessit
di lavorare oltre gli orari prestabiliti dettata da una pianificazione inefficiente. I premi di
tipo win-lose (a somma zero) raggiungibili da un numero limitato di membri del
gruppo di progetto, come il riconoscimento al membro del gruppo del mese, possono
ledere la coesione del gruppo. Al contrario, il riconoscimento di un comportamento winwin raggiungibile da tutti, come la consegna puntuale dei report sullo stato di
avanzamento, tendono a incrementare il sostegno reciproco tra i membri del gruppo di
lavoro.
I riconoscimenti e i premi devono tenere conto delle differenze culturali. Ad
esempio, pu risultare difficile sviluppare premi appropriati per il gruppo in una cultura
che favorisce invece lindividualismo.
214

9.3.3
.1
9.4
Sviluppare il gruppo di progetto: Output

Valutazione delle prestazioni del gruppo
Quando si implementano sforzi di sviluppo come la formazione, la costruzione del
gruppo e la co-location, il gruppo di Project Management effettua delle valutazioni
informali o formali dellefficacia del gruppo di progetto. Le strategie e le attivit
efficaci per lo sviluppo del gruppo dovrebbero incrementare le prestazioni del gruppo
stesso, che a loro volta aumentano le possibilit di raggiungere con successo gli
obiettivi del progetto. La valutazione dellefficacia del gruppo comprende una serie di
indicatori:
Miglioramenti degli skill che consentono a una persona di eseguire con
maggiore efficacia le attivit assegnatele.
Miglioramento delle competenze e della psicologia che consentono al gruppo di
garantire un lavoro di squadra pi efficace.
Riduzione del tasso di avvicendamento del personale.
Gestire il gruppo di progetto

Gestire il gruppo di progetto prevede il rilevamento delle prestazioni dei membri del
gruppo di lavoro, la comunicazione del feedback, la risoluzione delle questioni e il
coordinamento delle modifiche per favorire il miglioramento delle prestazioni del
progetto. Il gruppo di Project Management osserva il comportamento del gruppo,
gestisce i conflitti, risolve le questioni e valuta le prestazioni dei membri del gruppo di
lavoro. A seguito della gestione del gruppo di progetto, viene aggiornato il piano di
gestione del personale, si inoltrano le richieste di modifica, vengono risolte le
questioni, vengono forniti gli input per le valutazioni delle prestazioni della struttura
organizzativa e vengono integrate le lesson learned nel database della stessa.
La gestione del gruppo di progetto pu risultare complessa quando i membri del
gruppo di lavoro devono rispondere sia a un manager funzionale che al project
manager allinterno di unorganizzazione a matrice (paragrafo 2.3.3). La gestione
efficace di questa doppia relazione di reporting spesso un fattore critico di successo
per il progetto e rientra generalmente tra le responsabilit del project manager.
Figura 9-9. Gestire il gruppo di progetto: Input, Strumenti e tecniche e Output

215
9.4.1
Gestire il gruppo di progetto: Input
.1

Il gruppo di Project Management deve applicare i criteri, le procedure e i sistemi della
struttura organizzativa per premiare i dipendenti nel corso dello svolgimento del
progetto (paragrafo 4.1.1.4). Nellambito del processo di Project Management, il
gruppo di Project Management dovrebbe poter contare su iniziative quali pranzi
aziendali organizzati appositamente per premiazioni, certificati di riconoscimento,
newsletter, bacheche, siti Web, strutture retributive a incentivi, abbigliamento con il
marchio aziendale e agevolazioni aggiuntive.
.2

Le assegnazioni del personale di progetto (paragrafo 9.2.3.1) forniscono un elenco dei
membri del gruppo di progetto da valutare nel corso del processo di monitoraggio e
controllo.
.3
Per monitorare e valutare le prestazioni (paragrafo 9.1.3.1) viene utilizzato un elenco
dei ruoli e delle responsabilit del personale.
.4
Gli organigrammi di progetto forniscono una rappresentazione grafica delle relazioni
di reporting instaurate tra i membri del gruppo di progetto (paragrafo 9.1.3.2).
.5

Il piano di gestione del personale riporta un elenco dei periodi in cui si prevede che i
membri del gruppo siano impegnati sul progetto, insieme a informazioni quali piani di
formazione, requisiti di certificazione e questioni di conformit (paragrafo 9.1.3.3).
.6
Valutazione delle prestazioni del gruppo

Il gruppo di Project Management effettua continue valutazioni, sia formali che
informali, delle prestazioni del gruppo di progetto (paragrafo 9.3.3.1). Mediante la
valutazione costante del rendimento del gruppo di progetto possibile intraprendere
azioni che consentono di risolvere le questioni, modificare la comunicazione,
affrontare i conflitti e migliorare linterazione allinterno del gruppo.
.7

Nellambito del processo Dirigere e gestire lesecuzione del progetto (paragrafo 4.4),
il gruppo di Project Management osserva in tempo reale le prestazioni dei membri del
gruppo di lavoro. Nella gestione del gruppo, necessario prendere in considerazione
le osservazioni relative ad aree quali la partecipazione agli incontri dei membri del
gruppo, il feedback sulle azioni intraprese e la chiarezza nelle comunicazioni.
.8

I report sulle prestazioni (paragrafo 10.3.3.1) forniscono la documentazione sulle
prestazioni messe a confronto con il piano di Project Management. Esempi di aree
delle prestazioni che possono contribuire alla gestione del gruppo di progetto
comprendono i risultati di controllo della schedulazione, controllo dei costi, controllo
di qualit, verifica dellambito e revisioni degli approvvigionamenti. Le informazioni
contenute nei report sulle prestazioni e nelle previsioni correlate consentono di
determinare i requisiti futuri delle risorse umane, i riconoscimenti e i premi e gli
aggiornamenti al piano di gestione del personale.
216

9.4.2
Gestire il gruppo di progetto: Strumenti e tecniche
.1
Osservazione e conversazione
Losservazione e la conversazione sono validi strumenti per mantenere il contatto con
il lavoro e gli atteggiamenti che caratterizzano i membri del gruppo di progetto. Il
gruppo di Project Management effettua il monitoraggio di indicatori quali
lavanzamento verso i deliverable del progetto, i risultati che sono motivo di orgoglio
per i membri del gruppo di lavoro e le questioni interpersonali.
.2
Valutazioni delle prestazioni del progetto

La necessit di ricorrere a valutazioni delle prestazioni del progetto formali o
informali dipende dalla durata del progetto, dalla sua complessit, dai criteri adottati
dalla struttura organizzativa, dai requisiti contrattuali in merito al lavoro e dalla
quantit e qualit delle normali comunicazioni. I membri del gruppo di progetto
ricevono un feedback dai supervisori del loro lavoro di progetto. Vengono inoltre
raccolte informazioni sulla valutazione anche da persone che interagiscono con i
membri del gruppo di progetto adottando principi di feedback a 360 gradi.
Lespressione a 360 gradi indica che il feedback sulle prestazioni viene fornito a
persone la cui valutazione si basa su pi fonti, compresi i superiori, i colleghi e i
subordinati.
Gli obiettivi su cui focalizzarsi per condurre la valutazione delle prestazioni nel
corso del progetto possono comprendere lulteriore chiarimento dei ruoli e delle
responsabilit, la strutturazione del tempo per garantire che i membri del gruppo di
lavoro ricevano un feedback positivo in un ambiente che potrebbe altrimenti rivelarsi
frenetico, lindividuazione di questioni sconosciute o irrisolte, lo sviluppo di piani di
formazione individuali e la determinazione di obiettivi specifici per periodi futuri.
.3
Gestione dei conflitti

Una gestione efficace dei conflitti comporta lincremento della produttivit e il
miglioramento delle relazioni lavorative. Le ragioni dei conflitti comprendono
linsufficienza delle risorse, le priorit nella schedulazione e gli approcci personali al
lavoro. Le regole di base del gruppo, le norme del gruppo e le pratiche consolidate di
Project Management, come la pianificazione delle comunicazioni e la definizione dei
ruoli, riducono la portata del conflitto. Se gestite accuratamente, le differenze di
opinione possono essere costruttive e condurre a un incremento della creativit e al
miglioramento del processo decisionale. Quando le differenze diventano un fattore
negativo, i membri del gruppo di progetto sono i primi responsabili della risoluzione
dei conflitti interni. Se il conflitto si aggrava, il project manager deve intervenire e
favorire una risoluzione soddisfacente. I conflitti devono essere affrontati gi al loro
insorgere e preferibilmente in sede privata, adottando un approccio diretto ma
collaborativo. Se il conflitto prosegue con toni negativi, necessario adottare
procedure sempre pi formali, fino a ricorrere ad azioni di tipo disciplinare.

217
.4
9.4.3
Registro delle questioni

Se nel corso della gestione del gruppo di progetto insorgono delle questioni, la
presenza di un registro scritto consente di documentare le persone responsabili della
risoluzione di questioni specifiche entro una data fissata come obiettivo. Tale registro
consente inoltre al gruppo di progetto di monitorare le questioni fino alla chiusura. La
risoluzione delle questioni esamina gli ostacoli che possono impedire al gruppo di
raggiungere i propri obiettivi. Tra questi sono presenti fattori come le differenze di
opinione, situazioni su cui occorre fare luce e responsabilit emergenti o impreviste
che devono essere assegnate a un membro del gruppo di progetto.
Gestire il gruppo di progetto: Output
.1
Richieste di modifiche
Le modifiche di personale, a prescindere che siano per scelta o legate a eventi non
governabili, possono influire sullintero piano del progetto. Se le questioni relative al
personale danneggiano il piano del progetto, ad esempio rendono necessaria
unestensione della schedulazione o portano a un superamento del budget, possibile
elaborare una richiesta di modifica attraverso il processo Controllo integrato delle
.2

Le azioni correttive applicate alla gestione delle risorse umane comprendono voci
come modifiche di personale, formazione aggiuntiva e azioni disciplinari. Le
modifiche di personale possono prevedere lo spostamento di persone ad altre
assegnazioni, il trasferimento del lavoro a fornitori esterni e la sostituzione dei
membri del gruppo di lavoro uscenti. Il gruppo di Project Management determina
inoltre come e quando assegnare riconoscimenti o premi in base alle prestazioni del
gruppo.
.3

Nel momento in cui il gruppo di Project Management identifica questioni potenziali o
emergenti legate al personale, possibile sviluppare unazione preventiva per ridurre
la probabilit e/o limpatto dei problemi prima che questi si verifichino. Le azioni
preventive possono includere la formazione incrociata per ridurre i problemi in caso di
assenza dei membri del gruppo di progetto, unulteriore chiarificazione dei ruoli per
garantire il rispetto di tutte le responsabilit e laggiunta di ore lavorative da parte del
personale in previsione del lavoro straordinario che potrebbe rendersi necessario a
breve per rispettare le scadenze del progetto.
.4

Input alle valutazioni delle prestazioni organizzative: il personale del
progetto dovrebbe generalmente essere preparato a fornire gli input per le
valutazioni frequenti delle prestazioni organizzative da effettuarsi su qualsiasi
membro del gruppo di progetto con il quale vi sia stata uninterazione
significativa.
218

.5
Documentazione delle lesson learned: tutte le conoscenze apprese nel corso

del progetto devono essere documentate in modo che entrino a far parte del
database dei dati storici della struttura organizzativa. Le lesson learned presenti
nellarea delle risorse umane comprendono:
Organigrammi di progetto, descrizioni delle mansioni e piani di gestione
del personale che possono essere salvati sotto forma di schemi di
documento.
Regole di base, tecniche di gestione dei conflitti ed eventi di
riconoscimento che sono stati particolarmente utili.
Procedure per i gruppi virtuali, co-location, negoziazione, formazione e
costruzione del gruppo che si sono dimostrate efficaci.
Skill e competenze speciali dei membri del gruppo di lavoro divenuti noti
nel corso del progetto.
Questioni e soluzioni documentate nel registro questioni del progetto.

Le richieste di modifica approvate e le azioni correttive possono richiedere degli
aggiornamenti al piano di gestione del personale nellambito del piano di Project
Management. Esempi di informazioni aggiornate del piano sono i ruoli dei nuovi
membri del gruppo di progetto, i dati sulla formazione ulteriore e le decisioni sui
premi.

219
CAPITOLO 10
Gestione della comunicazione di progetto
La gestione della comunicazione di progetto unarea di conoscenza che utilizza i
processi necessari a garantire tempestivamente e appropriatamente la generazione, la
raccolta, la distribuzione, larchiviazione, il recupero e la disposizione finale delle
informazioni del progetto. I processi di Gestione della comunicazione di progetto
forniscono i collegamenti critici tra persone e informazioni, necessari per il successo
della comunicazione. I project manager possono dedicare una quantit di tempo
eccessiva per comunicare con il gruppo di progetto, gli stakeholder, il cliente e lo
sponsor. Chiunque sia coinvolto nel progetto dovrebbe comprendere come le
comunicazioni incidano sul progetto nel suo complesso. La figura 10-1 mostra una
visione dinsieme dei processi di gestione della comunicazione di progetto, mentre la
figura 10-2 illustra un diagramma di flusso di tali processi e dei loro input, output e di
altri processi delle aree di conoscenza correlate. I processi di gestione della
comunicazione di progetto sono:
10.1 Pianificazione della comunicazione: determinare le esigenze di informazione e
di comunicazione degli stakeholder di progetto.
10.2 Distribuzione delle informazioni: rendere disponibili in modo tempestivo agli
stakeholder di progetto le informazioni richieste.
10.3 Reporting delle prestazioni: raccogliere e distribuire le informazioni sulle
prestazioni. Ci include i rapporti sullavanzamento, le misure di avanzamento e
di previsione.
10.4 Gestione degli stakeholder: gestire le comunicazioni per soddisfare i requisiti e
risolvere eventuali questioni riguardanti gli stakeholder di progetto.
I processi interagiscono tra loro e con i processi appartenenti ad altre aree di
conoscenza. Ogni processo pu richiedere limpegno di una o pi persone o gruppi in
funzione delle esigenze del progetto. Ciascun processo viene svolto almeno una volta
per ogni progetto e in una o pi fasi del progetto, se questo suddiviso in fasi.
Sebbene i processi vengano qui presentati come elementi distinti con interfacce ben
definite, nella pratica essi possono sovrapporsi e interagire in modi diversi da quelli
descritti. Le interazioni tra i processi sono discussi in dettaglio nel capitolo 3.
10

221
Capitolo 10 Gestione delle comunicazioni di progetto
Figura 10-1. Visione dinsieme della gestione della comunicazione di progetto
222

10
Figura 10-2. Diagramma di flusso dei processi di gestione della comunicazione di progetto
Gli skill comunicativi sono correlati, ma non sono tuttavia la stessa cosa, alle
comunicazioni di Project Management. Larte della comunicazione un argomento
molto vasto e implica una sostanziale base di informazioni, tra cui:
Modelli mittente-destinatario: descrivono i circuiti di feedback e gli ostacoli
alla comunicazione.
Scelta dei mezzi di comunicazione: quando comunicare per iscritto o con una
comunicazione orale, quando scrivere un promemoria informale o un report
formale, e quando comunicare di persona o con un messaggio di posta
elettronica. I mezzi scelti per le attivit di comunicazione dipendono dalla
situazione.
Stile di scrittura: utilizzo della forma attiva o di quella passiva, struttura delle
frasi e scelta del lessico.

223
Tecniche di presentazione: linguaggio del corpo e preparazione di supporti

visivi.
Tecniche di gestione delle riunioni: preparazione di unagenda e risoluzione
dei conflitti.
Un modello di base della comunicazione, mostrato nella figura 10-3, dimostra
come le idee o le informazioni vengono inviate e ricevute tra le due parti, definite
come mittente e destinatario. Le componenti principali del modello
comprendono:
Codifica: tradurre i pensieri o le idee in un linguaggio che sia comprensibile
agli altri.
Messaggio: output della codifica.
Mezzo: il metodo utilizzato per trasmettere il messaggio.
Rumore: qualsiasi cosa che interferisca con la trasmissione e la comprensione
del messaggio (ad es. la distanza).
Decodifica: ritradurre il messaggio in pensieri o idee significative.
Una caratteristica insita nel modello mostrato nella figura 10-3 lazione di
riconoscimento del messaggio. Per riconoscimento si intende che il destinatario
segnala la ricezione del messaggio, ma non necessariamente la sua condivisione.
Unaltra azione la risposta al messaggio, che significa che il destinatario ha
decodificato, compreso e sta rispondendo al messaggio.
Figura 10-3. Comunicazione: modello di base
Le componenti nel modello di comunicazione devono essere prese in

considerazione quando si discute di comunicazioni di progetto. Ci sono molte
difficolt nelluso di queste componenti per comunicare in modo efficace con gli
stakeholder di progetto. Si consideri un gruppo di progetto molto tecnico e
multinazionale. Per un membro del gruppo comunicare un concetto tecnico a un altro
membro del gruppo di un altro paese pu richiedere la codifica del messaggio nella
lingua appropriata, linvio del messaggio mediante una serie di tecnologie, e
lassicurazione che il destinatario decodifichi il messaggio. Qualsiasi rumore
introdotto lungo questo cammino pu compromettere il significato originale del
messaggio. Le interruzioni delle comunicazioni possono incidere negativamente sul
progetto.
224

10.1 Pianificazione della comunicazione

Il processo di Pianificazione della comunicazione determina le esigenze di
informazione e comunicazione degli stakeholder; ad esempio, chi necessita di
determinate informazioni, quando sono richieste, come vengono date e da chi. Mentre
tutti i progetti condividono la necessit di comunicare le informazioni di progetto, le
esigenze di informazione e i metodi di distribuzione variano in misura significativa.
Ldentificazione delle esigenze di informazione degli stakeholder e la definizione di
mezzi adatti per far fronte a tali esigenze sono un fattore importante per il successo del
progetto.
In molti progetti, la maggior parte della pianificazione della comunicazione
eseguita nelle primissime fasi di progetto. Ciononostante, i risultati di questo processo
di pianificazione sono esaminati a cadenza regolare nel corso di tutto il progetto e
sono rivisti come richiesto per garantire la continuit della loro applicabilit.
La Pianificazione della comunicazione spesso strettamente collegata a fattori
ambientali aziendali (paragrafo 4.1.1.3) e a influenze organizzative (paragrafo 2.3), in
quanto la struttura organizzativa del progetto influisce notevolmente sui relativi
requisiti di comunicazione di progetto.
10
Figura 10-4. Pianificazione della comunicazione: Input, Strumenti e tecniche e Output
10.1.1 Pianificazione della comunicazione: Input

.1 Fattori ambientali aziendali
Tutti i fattori descritti nel paragrafo 4.1.1.3 sono utilizzati come input di questo
processo.
.2 Asset dei processi organizzativi
Mentre tutti gli asset descritti nel paragrafo 4.1.1.4 vengono utilizzati come input per
questo processo, anche le lesson learned e le informazioni storiche sono
particolarmente rilevanti. Le lesson learned e le informazioni storiche possono fornire
sia decisioni sia risultati basati su precedenti progetti analoghi riguardanti le questioni
di comunicazione.

225
.3 Descrizione dellambito del progetto

La descrizione dellambito del progetto (paragrafo 5.2.3.1) fornisce una base
documentata per le future decisioni di progetto e per confermare una conoscenza
comune dellambito di progetto a tutti gli stakeholder. Lanalisi degli stakeholder
completata come parte del processo di definizione dellambito.
.4 Piano di Project Management
Il piano di Project Management (paragrafo 4.3) contiene informazioni di base sul
progetto, compresi date e vincoli che possono essere rilevanti nella pianificazione
della comunicazione.
Vincoli: i vincoli sono fattori che possono limitare le opzioni a disposizione del
gruppo di Project Management. Esempi di vincoli comprendono i membri del
gruppo di lavoro residenti in aree geografiche diverse, versioni di software di
comunicazione non compatibili o capacit tecniche di comunicazione limitate.
Assunti: assunzioni specifiche che influiscono sulla pianificazione della
comunicazione dipendono dallo specifico progetto.
10.1.2 Pianificazione della comunicazione: Strumenti e tecniche

.1 Analisi dei requisiti della comunicazione
Lanalisi dei requisiti della comunicazione produce la somma delle esigenze di
informazione degli stakeholder di progetto. Questi requisiti sono definiti dalla
combinazione tra il tipo ed il formato delle informazioni necessarie e unanalisi del
valore di tali informazioni. Le risorse di progetto sono impiegate soltanto per
comunicare le informazioni che contribuiscono al successo o per ovviare a un
insuccesso che potrebbe essere causato da una mancanza di comunicazione. Questo
non significa che le cattive notizie non vengano condivise; piuttosto lintento
prevenire di gravare eccessivamente gli stakeholder con delle inezie.
Il project manager dovrebbe considerare il numero dei potenziali canali o
percorsi come un indicatore della complessit delle comunicazioni di un progetto.
Il numero totale dei canali di comunicazione n(n-1)/2, dove n = numero degli
stakeholder. Pertanto un progetto con 10 stakeholder ha 45 canali potenziali di
comunicazione. Una componente chiave della pianificazione delle comunicazioni,
perci, consiste nel determinare e limitare chi pu comunicare con chi e chi riceve
quale informazione. Le informazioni generalmente richieste per determinare i requisiti
delle comunicazioni sono:
Organigrammi.
Relazioni tra organizzazione del progetto e responsabilit degli stakeholder.
Discipline, reparti e specialit coinvolte nel progetto.
Logistica riguardante il numero di persone che saranno coinvolte nel progetto e
in quali sedi.
Esigenze di informazioni interne (ad es. comunicazione tra organizzazioni).
Esigenze di informazioni esterne (ad es. comunicazione con i mass media o con
gli appaltatori).
Informazioni riguardanti gli stakeholder.
226

.2 Tecnologia di comunicazione
Le metodologie utilizzate per trasferire le informazioni tra gli stakeholder di progetto
possono variare significativamente. Ad esempio, un gruppo di Project Management
pu scegliere tra brevi conversazioni per tutta la durata del progetto fino a riunioni
estese, semplici documenti scritti sul materiale (ad es. schedulazioni e database) che
accessibile on-line come metodo di comunicazione.
I fattori tecnologici di comunicazione che possono inflenzare il progetto
includono:
Urgenza legata alla necessit di informazioni: il successo del progetto
dipende dallavere frequentemente a disposizione informazioni aggiornate
mediante tempestiva notifica oppure sono sufficienti dei report pubblicati a
intervalli regolari?
Disponibilit della tecnologia: i sistemi gi in uso sono appropriati o le
esigenze di progetto richiedono un cambiamento?
Personale previsto per il progetto: i sistemi di comunicazione proposti sono
compatibili con lesperienza e le competenze dei partecipanti al progetto oppure
sono necessari addestramento e formazione aggiuntivi?
Lunghezza del progetto: ci sono possibilit che la tecnologia disponibile cambi
prima della fine del progetto?
Ambiente del progetto: il gruppo di lavoro si incontra di persona o collabora in
un ambiente virtuale?
10
10.1.3 Pianificazione della comunicazione: Output

.1 Piano di gestione della comunicazione
Il piano di gestione della comunicazione contenuto nel piano di Project Management
(paragrafo 4.3) oppure ne costituisce una parte ausiliaria. Il piano di gestione della
comunicazione fornisce:
Requisiti di comunicazione degli stakeholder.
Informazioni da comunicare, incluso formato, contenuto e livello di dettaglio.
Persona responsabile per la comunicazione delle informazioni.
Persona o gruppi che riceveranno linformazione.
Metodi o tecnologie utilizzate per la trasmissione delle informazioni, come
promemoria, e-mail e/o comunicati stampa.
Frequenza delle comunicazioni, per esempio settimanale.
Riferimenti temporali - identificazione dei processi di escalation e catena di
gestione (nomi) per lescalation dei problemi che non possono essere risolti dal
personale di livello pi basso.
Metodo di aggiornamento e perfezionamento del piano di gestione della
comunicazione con lavanzare e lo svilupparsi del progetto.
Glossario della terminologia comune.

227
Il piano di gestione della comunicazione pu comprendere le linee guida per le

riunioni sullo stato del progetto, per le riunioni del gruppo di progetto, per le
videoconferenze e la posta elettronica. Il piano di gestione della comunicazione pu
essere formale o informale, dettagliato o sintetico e basato sulle esigenze di progetto.
Il piano di gestione della comunicazione contenuto, o costituisce una parte ausiliaria,
del piano complessivo di Project Management (paragrafo 4.3). Attributi campione di
un piano di gestione della comunicazione possono includere:
Elementi della comunicazione: le informazioni che saranno distribuite agli
stakeholder.
Scopo: la ragione per la distribuzione di quella informazione.
Frequenza: quanto spesso quella informazione verr distribuita.
Date di inizio/fine: lasso di tempo per la distribuzione dellinformazione.
Formato/mezzo: il layout delle informazioni e il metodo di trasmissione.
Responsabilit: il membro del gruppo responsabile della distribuzione delle
informazioni.
La pianificazione della comunicazione comprende spesso la creazione di
deliverable aggiuntivi che, a loro volta, richiedono ulteriore tempo e impegno.
Pertanto, la struttura di scomposizione del lavoro di progetto, la schedulazione di
progetto e il budget del progetto sono aggiornati di conseguenza.
10.2 Distribuzione delle informazioni

La Distribuzione delle informazioni richiede la messa a disposizione in modo
tempestivo delle informazioni agli stakeholder di progetto. La Distribuzione delle
informazioni comprende limplementazione del piano di gestione della
comunicazione, nonch la capacit di risposta a inattese richieste di informazioni.
Figura 10-5. Distribuzione delle informazioni: Input, Strumenti e tecniche e Output
228

10.2.1 Distribuzione delle informazioni: Input

10.2.2 Distribuzione delle informazioni: Strumenti e tecniche

.1 Skill comunicativi
Gli skill comunicativi fanno parte degli skill di general management e sono usati per
lo scambio di informazioni. Gli skill di general management correlati alla
comunicazione includono la garanzia che le persone giuste ricevano le informazioni
corrette nei tempi previsti, come definito nel piano di gestione della comunicazione.
Gli skill di general management comprendono anche labilit di gestione dei requisiti
degli stakeholder.
Come parte del processo di comunicazione, il mittente responsabile della
chiarezza e completezza delle informazioni, in modo tale che il destinatario le possa
ricevere correttamente e confermare che tali informazioni siano adeguatamente
comprese. Il destinatario responsabile di assicurarsi che le informazioni siano
ricevute nella loro interezza e di averle comprese correttamente. La comunicazione ha
molte dimensioni:
Scritta e orale, modalit ascoltatore o parlante.
Interna (allinterno del progetto) ed esterna (cliente, mass media, pubblico).
Formale (report, conferenze illustrative) e informale (promemoria,
conversazioni ad hoc).
Verticale (verso lalto e verso il basso nellorganizzazione) e orizzontale (tra
pari grado).
10
.2 Sistemi di raccolta e recupero delle informazioni

Le informazioni possono essere raccolte e recuperate mediante mezzi diversi, tra cui i
sistemi di archiviazione manuale, i database elettronici, i software di Project
Management e i sistemi che permettono laccesso alla documentazione tecnica, come i
disegni tecnici, le specifiche dei progetti e dei piani di collaudo.
.3 Metodi di distribuzione delle informazioni
La distribuzione delle informazioni la raccolta, la condivisione, e la distribuzione di
informazioni agli stakeholder di progetto in modo tempestivo per tutto il ciclo di vita
del progetto. Le informazioni di progetto possono essere distribuite usando una variet
di metodi, inclusi:
Riunioni di progetto, distribuzione di copie cartacee dei documenti, sistemi di
archiviazione manuale, database elettronici ad accesso condiviso.
Strumenti elettronici di comunicazione e di conferenze, come posta elettronica,
fax, posta vocale, telefono, conferenze video e Web, e pubblicazione sul Web.
Strumenti elettronici di Project Management, come interfacce Web per la
schedulazione e il software di Project Management, software di supporto per
riunioni e uffici virtuali, portali e strumenti collaborativi di gestione del lavoro.

229
.4 Processo delle lesson learned

Una sessione di lesson learned incentrata nellidentificazione dei successi e degli
esiti negativi del progetto e include delle raccomandazioni per migliorare le
prestazioni future dei progetti. Durante il ciclo di vita del progetto, il gruppo di
progetto e gli stakeholder principali individuano le lesson learned relative agli aspetti
tecnici, gestionali e procedurali del progetto. Le lesson learned sono compilate,
formalizzate e archiviate per tutta la durata del progetto.
Largomento centrale delle riunioni sulle lesson learned pu variare. In alcuni
casi, lattenzione posta su processi di sviluppo tecnico o di prodotto, mentre in altri
casi lattenzione posta su processi che hanno coadiuvato od ostacolato le prestazioni
del lavoro. I gruppi possono raccogliere informazioni pi frequentemente se ritengono
che la maggiore quantit di dati valga un ulteriore investimento di tempo e denaro. Le
lesson learned forniscono ai futuri gruppi di progetto informazioni utili per accrescere
lefficacia e lefficienza del Project Management. Inoltre, le sessioni di lesson learned
di fine fase rappresentano un valido supporto alle attivit di creazione del gruppo. I
project manager sono professionalmente obbligati a tenere per tutti i progetti delle
sessioni di lesson learned con gli stakeholder principali sia interni che esterni, in modo
particolare se il progetto ha sortito risultati inferiori alle aspettative. Tra i risultati
specifici delle lesson learned figurano:
Aggiornamento della knowledge base delle lesson learned.
Input al sistema di gestione delle conoscenze
Aggiornamento di criteri, procedure e processi aziendali.
Miglioramento degli skill aziendali.
Miglioramenti complessivi di prodotti e servizi.
Aggiornamenti al piano di gestione dei rischi.
10.2.3 Distribuzione delle informazioni: Output

.1 Asset dei processi organizzativi (aggiornamenti)
Documentazione delle lesson learned: la documentazione comprende le cause
dei problemi, le motivazioni alla base dellazione correttiva scelta e altri tipi di
lesson learned relative alla distribuzione delle informazioni. Le lesson learned
sono documentate di modo da diventare parte dei database storici sia del
progetto e che della Performing Organization.
Archivi di progetto: gli archivi del progetto possono comprendere la
corrispondenza, i promemoria e i documenti che descrivono il progetto. Queste
informazioni dovrebbero, per quanto possibile e opportuno, essere conservate in
modo organizzato. I membri del gruppo di progetto possono registrare gli
archivi in un blocco notes di progetto.
Report di progetto: i report di progetto formali e informali forniscono
informazioni dettagliate sullo stato del progetto, tra cui le lesson learned, la
registrazione dei problemi, i report di chiusura del progetto e gli output derivanti
da altre aree di conoscenza (capitoli 4 - 12).
230

Presentazioni di progetto: il gruppo di progetto fornisce informazioni

formalmente o informalmente ad alcuni o a tutti gli stakeholder di progetto. Le
informazioni sono rilevanti in funzione delle esigenze dei destinatari, e il
metodo di presentazione deve essere adeguato.
Riscontro dagli stakeholder: le informazioni ricevute dagli stakeholder sulle
funzioni operative del progetto possono essere distribuite e utilizzate per
modificare o migliorare le prestazioni future del progetto.
Notifiche agli stakeholder: le informazioni fornite agli stakeholder possono
riguardare questioni risolte, modifiche approvate e lo stato generale del progetto.
.2 Modifiche richieste
Le modifiche al processo di distribuzione delle informazioni dovrebbero innescare
ulteriori modifiche al piano di Project Management e al piano di gestione della
comunicazione. Le modifiche richieste (aggiunte, modifiche, revisioni) al piano di
Project Management e i relativi piani ausiliari sono analizzate e la disposizione viene
gestita mediante il processo di controllo integrato delle modifiche (paragrafo 4.6).
10.3 Reporting delle prestazioni

Il processo di Reporting delle prestazioni comporta la raccolta di tutti i dati della
baseline e la distribuzione agli stakeholder delle informazioni sulle prestazioni. In
genere, le informazioni sulle prestazioni descrivono come le risorse sono utilizzate per
raggiungere gli obiettivi di progetto. Il Reporting delle prestazioni dovrebbe in genere
fornire informazioni su ambito, schedulazione, costo e qualit. Molti progetti
richiedono inoltre informazioni sui rischi e sullapprovvigionamento. I report possono
essere onnicomprensivi o basati sulle eccezioni.
10
Figura 10-6. Reporting delle prestazioni: Input, Strumenti e tecniche e Output

231
10.3.1 Reporting delle prestazioni: Input

.1 Informazioni sull'andamento del lavoro
Le informazioni sull'andamento del lavoro in merito allo stato di completamento dei
deliverable e di cosa stato portato a termine come parte dellesecuzione del progetto,
sono inserite nel processo di reporting delle prestazioni. La raccolta delle informazioni
sull'andamento del lavoro discussa pi dettagliatamente nel processo Dirigere e
gestire lesecuzione del progetto (paragrafo 4.4).
.2 Misurazioni delle prestazioni
Per la descrizione, consultare i paragrafi 6.6.3.3 e 7.3.3.3.
.3 Completamento previsto
.4 Misurazioni del controllo di qualit
Il piano di Project Management fornisce le informazioni sulla baseline (paragrafo 4.3).
Baseline di misurazione delle prestazioni: un piano approvato per il lavoro di
progetto con cui confrontata lesecuzione del progetto e sono misurate le
deviazioni per il controllo di gestione. La baseline di misurazione delle
prestazioni tipicamente integra lambito, la schedulazione e i parametri di costo
di un progetto, ma pu anche includere parametri tecnici e di qualit.
.6 Richieste di modifica approvate
Le richieste di modifica approvate (paragrafo 4.6.3.1) sono modifiche richieste per
estendere o limitare lambito del progetto, per modificare il costo stimato, o per
esaminare le stime di durata dellattivit, che sono state approvate e sono pronte per
limplementazione da parte del gruppo di progetto.
.7 Deliverable
I deliverable (paragrafo 4.4.3.1) sono rappresentati da qualsiasi prodotto unico e
verificabile, risultato o capacit di effettuare un servizio che deve essere realizzato per
portare a termine un processo, una fase o un progetto. Il termine viene spesso usato
pi limitatamente in riferimento a un deliverable esterno che soggetto ad
approvazione da parte dello sponsor del progetto o dal cliente.
10.3.2 Reporting delle prestazioni: Strumenti e tecniche

.1 Strumenti di presentazione delle informazioni
I pacchetti software che comprendono reporting tabellare, presentazioni o funzionalit
grafiche possono essere utilizzati per creare immagini di qualit a livello di
presentazione dei dati di prestazione del progetto.
232

.2 Raccolta e compilazione delle informazioni sulle prestazioni

Le informazioni possono essere raccolte e compilate da una variet di supporti, tra cui
sistemi di archiviazione manuale, database elettronici, software di Project
Management e sistemi che consentono laccesso alla documentazione tecnica, come
disegni tecnici, specifiche di progetto e piani di collaudo, al fine di produrre previsioni
come pure report sulle prestazioni, sullo stato e sullavanzamento.
.3 Riunioni per la revisione dello stato
Le riunioni per la revisione dello stato sono eventi schedulati regolarmente per
scambiare informazioni sul progetto. Nella maggior parte dei progetti, le riunioni per
la revisione dello stato sono tenute a frequenze diverse e a livelli diversi. Ad esempio,
il gruppo di Project Management pu stabilire incontri settimanali a cui partecipano
solo i suoi membri e incontri mensili con il cliente.
.4 Sistemi di reporting dei tempi
I sistemi di reporting dei tempi forniscono il tempo speso per il progetto.
.5 Sistemi di reporting dei costi
I sistemi di reporting dei costi registrano e forniscono i costi sostenuti per il progetto.
10.3.3 Reporting delle prestazioni: Output

.1 Report sulle prestazioni
I report sulle prestazioni organizzano e riepilogano le informazioni raccolte e
presentano i risultati di unanalisi comparata con la baseline di misurazione delle
prestazioni. I report dovrebbero fornire informazioni sullo stato e sullavanzamento, al
livello di dettaglio richiesto dai vari stakeholder, cos come documentato nel piano di
gestione della comunicazione. I formati comuni per i report sulle prestazioni
comprendono i diagrammi a barre, le curve a S, gli istogrammi e le tabelle. I dati
dallanalisi dellEarned Value sono spesso inclusi come componente del reporting
delle prestazioni. Le curve a S, come quelle mostrate nella figura 7-7, possono
mostrare solamente una visualizzazione dei dati relativi allanalisi dellEarned Value,
la figura 10-7 fornisce una visualizzazione a tabella dei dati sullEarned Value.
10

233
Elemento della WBS
Pianificato
Ottenuto
Costo
Budget
Earned Value
Costo
effettivo
Indice delle
prestazioni
Scostamento dei costi
Scostamento dei tempi
Costo
Schedulazione
($)
($)
($)
($)
(%)
($)
(%)
CPI
SPI
(PV)
(EV)
(AC)
(EV - AC)
(CV EV)
(EV - PV)
(SV PV)
(EV AC)
(EV PV)
1.0 Piano pre-pilota
63.000
58.000
62.500
-4.500
-7,8
-5.000
-7,9
0,93
0,92
2.0 Liste di controllo
64.000
48.000
46.800
1.200
2,5
-16.000
-25,0
1,03
0,75
3.0 Curriculum
23.000
20.000
23.500
-3.500
-17,5
-3.000
-13,0
0,85
0,87
4.0 Valutazione a medio

termine
68.000
68.000
72.500
-4.500
-6,6
0,0
0,94
1,00
5.0 Supporto di
implementazione
12.000
10.000
10.000
0,0
-2.000
-16,7
1,00
0,83
7.000
6.200
6.000
200
3,2
-800
-11,4
1,03
0,89
20.000
13.500
18.100
-4.600
-34,1
-6.500
-32,5
.075
0,68
257.000
223.700
239.400
-15.700
-7,0
-33.300
-13,0
0,93
0,87
6.0 Manuale di practice

7.0 Piano di presentazione al
pubblico
Totali
Nota: tutte le stime sono relative al progetto e aggiornate alla data di compilazione della tabella.
* possibile che questi calcoli includano altre unit di misura, quali: ore di lavoro, metri cubi di cemento ecc.
Figura 10-7. Esempio di report sulle prestazioni a tabella
.2 Previsioni
Le previsioni sono aggiornate e quindi ripubblicate in base alle informazioni di
prestazione del lavoro durante lesecuzione del progetto. Queste informazioni
riguardano le prestazioni passate che potrebbero influire sul progetto nel futuro, ad
esempio, la stima al completamento e la stima a finire.
Lanalisi delle prestazioni del progetto genera spesso la richiesta di modifiche
(paragrafo 4.4.3.2) di alcuni aspetti del progetto. Queste modifiche richieste sono
elaborate e decise mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
.4 Azioni correttive consigliate
Le azioni correttive consigliate (paragrafo 4.5.3.1) comprendono le modifiche che
consentono di conformare le prestazioni future previste per il progetto al piano di
Project Management.
La documentazione delle lesson learned comprende le cause dei problemi, le
motivazioni alla base dellazione correttiva scelta e altri tipi di lesson learned relative
al reporting delle prestazioni. Le lesson learned sono documentate in modo da poter
diventare parte dei database dei dati storici sia del progetto e sia della Performing
Organization.
234

10.4 Gestione degli stakeholder

La Gestione degli stakeholder relativa alla gestione delle comunicazioni per
soddisfare i requisiti ed alla risoluzione di problemi con gli stakeholder di progetto. La
gestione attiva degli stakeholder incrementa la possibilit che il progetto non risulti
deviato rispetto al programma prestabilito a causa di problemi non risolti con gli
stakeholder, migliora la capacit delle persone di operare sinergicamente e limita le
interruzioni nel corso dello svolgimento del progetto. Il project manager in genere il
responsabile per la gestione degli stakeholder.
Figura 10-8. Gestione degli stakeholder: Input, Strumenti e tecniche e Output
10
10.4.1 Gestione degli stakeholder: Input

I requisiti e le aspettative espressi dagli stakeholder forniscono una chiave di lettura
degli scopi, degli obiettivi e del livello di comunicazione durante il progetto. Le
esigenze e le aspettative vengono identificate, analizzate e documentate allinterno del
piano di gestione della comunicazione (paragrafo 10.1.3.1), che un piano ausiliario
del piano di Project Management.
Con linsorgere dei problemi inerenti al progetto, il project manager dovrebbe
affrontarli e risolverli collaborando con gli stakeholder appropriati del progetto.
10.4.2 Gestione degli stakeholder: Strumenti e tecniche

.1 Metodi di comunicazione
I metodi di comunicazione identificati per ciascun stakeholder allinterno del piano di
gestione della comunicazione sono utilizzati per la gestione degli stakeholder.
Le riunioni faccia a faccia sono il mezzo pi efficace per comunicare e
risolvere i problemi riguardanti gli stakeholder. Quando le riunioni faccia a faccia non
sono garantite o praticabili (ad es. nei progetti internazionali), conversazioni
telefoniche, posta elettronica e altri strumenti elettronici sono utili per lo scambio di
informazioni e per il dialogo.

235
.2 Registri delle questioni

Il registro delle questioni o registro delle azioni uno strumento che pu essere usato
per documentare e monitorare la risoluzione delle questioni. Le questioni non
assumono normalmente unimportanza tale da divenire dei veri e propri progetti o
attivit; ma sono generalmente trattate per mantenere buone e costruttive le relazioni
lavorative tra i vari stakeholder, compresi i membri del gruppo di lavoro.
Un problema chiarito e verbalizzato in modo tale che possa essere risolto,
assegnato un titolare e viene normalmente stabilita una data obiettivo per la chiusura. I
problemi non risolti possono divenire anche una fonte importante di conflitto e di
ritardo del progetto.
10.4.3 Gestione degli stakeholder: Output

.1 Questioni risolte
Con lidentificazione e la risoluzione dei requisiti degli stakeholder, il registro delle
questioni documenta le tematiche affrontate e chiuse. Gli esempi comprendono:
I clienti concordano un contratto di seconda fase, che termina con una
discussione prolungata sul fatto che le modifiche richieste allambito del
progetto rientrino o meno nellambito dellattuale progetto.
Si aggiunge dellaltro personale al progetto, chiudendo pertanto la questione
relativa alla carenza degli skill richiesti.
Le negoziazioni con i manager funzionali dellorganizzazione in merito alla
carenza di risorse umane si concludono con una soluzione soddisfacente per
entrambe le parti prima di causare dei ritardi al progetto.
Le questioni sollevate dai membri del direttivo in merito alla realizzabilit
finanziaria del progetto sono state affrontate, permettendo lavanzamento del
progetto come pianificato.
Le richieste di modifica approvate (paragrafo 4.6.3.1) comprendono le modifiche allo
stato delle questioni relative agli stakeholder nel piano di gestione del personale; che
sono necessarie per riflettere le modifiche alla modalit con cui avvengono le
comunicazioni con gli stakeholder.
.3 Azioni correttive approvate
Le azioni correttive approvate (paragrafo 4.6.3.5) comprendono le modifiche che
consentono di conformare le prestazioni future attese per il progetto al piano di Project
Management.
La documentazione delle lesson learned comprende le cause delle questioni, le
motivazioni alla base dellazione correttiva scelta e altri tipi di lesson learned relative
alla gestione degli stakeholder. Le lesson learned vengono documentate di modo da
essere inserite nei database dei dati storici del progetto e della Performing
Organization.
.5 Piano di Project Management (aggiornamenti)
Il piano di Project Management viene aggiornato con le modifiche apportate al piano
di comunicazione.
236

CAPITOLO 11
Gestione dei rischi di progetto
La gestione dei rischi di progetto riguarda la conduzione dei processi legati alla
pianificazione della gestione dei rischi, alla loro identificazione e analisi, alla
preparazione delle risposte ai rischi e al loro monitoraggio e controllo nel corso del
progetto. La maggior parte di questi processi aggiornata di pari passo con
lavanzamento del progetto. Gli obiettivi alla base della gestione dei rischi di progetto
consistono nellaumentare la probabilit e limpatto di eventi positivi e nel diminuire
la probabilit e limpatto di eventi dannosi per il progetto. La figura 11-1 mostra una
visione dinsieme dei processi di gestione dei rischi di progetto, mentre la figura 11-2
illustra un diagramma di flusso di tali processi e dei loro input, output e di altri
processi delle aree di conoscenza correlati. La gestione dei rischi di progetto prevede i
seguenti processi:
11.1 Pianificazione della gestione dei rischi: determinare come affrontare,
pianificare ed eseguire le attivit di gestione dei rischi di un progetto.
11.2 Identificazione dei rischi: determinare i rischi che possono influire sul progetto
e documentare le loro caratteristiche.
11.3 Analisi qualitativa dei rischi: assegnare le priorit ai rischi ai fini di
unulteriore analisi od operazione attraverso la valutazione e la combinazione
della probabilit che i rischi si verifichino e al loro impatto.
11.4 Analisi quantitativa dei rischi: analizzare numericamente leffetto dei rischi
identificati sugli obiettivi complessivi del progetto.
11.5 Pianificazione della risposta ai rischi: sviluppare opzioni e azioni volte a
incrementare le opportunit e ridurre le minacce agli obiettivi di progetto.
11.6 Monitoraggio e controllo dei rischi: rilevare i rischi noti, monitorare i rischi
residui, identificare i rischi nuovi, attuare i piani di risposta ai rischi e valutare
lefficacia di queste operazioni nel corso del ciclo di vita del progetto.
Questi processi interagiscono tra loro e con i processi delle altre aree di
conoscenza. Ogni processo pu richiedere limpegno di una o pi persone o gruppi,
secondo i requisiti del progetto. Ciascun processo viene svolto almeno una volta per
ogni progetto e in una o pi fasi del progetto, se questo suddiviso in fasi. Sebbene i
pratica essi possono parzialmente sovrapporsi o interagire in modi diversi da quelli
descritti. Per una descrizione dettagliata delle interazioni tra processi, consultare il
capitolo 3.
11

237
Capitolo 11 Gestione dei rischi di progetto
Il rischio di progetto rappresenta un evento o una condizione incerti che, se si

verificano, influiscono positivamente o negativamente su almeno uno degli obiettivi
di progetto, come tempi, costi, ambito o qualit (ad es. nel caso in cui lobiettivo dei
tempi del progetto preveda la consegna in conformit alla schedulazione concordata o
lobiettivo dei costi del progetto preveda la consegna nel rispetto dei costi prestabiliti
ecc.). Un rischio pu derivare da una o pi cause e, se si verifica, pu provocare anche
pi di un impatto. Ad esempio, una causa potrebbe essere la richiesta di un permesso
ambientale per eseguire il lavoro o la carenza di personale assegnato al progetto. In
questo esempio, levento di rischio pu essere lesigenza di pi tempo espressa
dallagenzia di concessione licenze per lemissione del permesso o linadeguatezza
allattivit del personale di progettazione disponibile e assegnato al progetto. Se si
verifica uno di questi eventi, possibile che si produca un impatto su costi,
schedulazione e prestazione del progetto. Le condizioni di rischio possono anche
includere aspetti dellambiente del progetto o della struttura organizzativa che
possono contribuire ad aumentare il rischio connesso al progetto, come pratiche di
Project Management carenti, mancanza di sistemi di gestione integrati, pi progetti in
corso o la presenza di relazioni di dipendenza da partecipanti esterni che non possono
essere controllati.
238

11
Figura 11-1. Visione dinsieme della gestione del rischio di progetto

239
Il rischio di progetto ha origine nelle situazioni di incertezza che caratterizzano

tutti i progetti. I rischi noti sono quelli che sono stati identificati e analizzati;
possibile predisporre dei piani per affrontare questi rischi utilizzando i processi
descritti in questo capitolo. Al contrario, i rischi sconosciuti non possono essere gestiti
in modo proattivo; ne consegue che il gruppo di progetto pu scegliere un
atteggiamento prudente applicando la distribuzione della contingency generale a
fronte di questo tipo di rischi; questa tecnica applicabile anche ai rischi noti per i
quali non risulta conveniente o consigliabile sviluppare una risposta proattiva.
Le organizzazioni percepiscono la presenza dei rischi nella misura in cui questi
si traducono in minacce per il successo del progetto o in opportunit di incrementare
le possibilit di successo del progetto. I rischi riconoscibili come minacce per il
progetto possono essere accettati se adeguatamente controbilanciati dalla ricompensa
che deriva dal correre il rischio. Ad esempio, la scelta di una schedulazione di tipo
Fast Tracking (paragrafo 6.5.2.3), che potrebbe non essere rispettata, rappresenta un
rischio assunto per raggiungere il completamento prima del previsto. I rischi
riconoscibili come opportunit, come laccelerazione del lavoro raggiungibile
mediante lincremento del personale assegnato al progetto, possono essere assunti a
fronte dei vantaggi per gli obiettivi del progetto.
Le persone e, per estensione, le strutture organizzative mostrano atteggiamenti
nei confronti dei rischi che influiscono sia sullaccuratezza della percezione del
rischio che sulle modalit di risposta. Ove possibile, consigliabile rendere espliciti
tali atteggiamenti. inoltre necessario sviluppare un approccio omogeneo alla
gestione dei rischi, conforme ai requisiti dellorganizzazione; ogni comunicazione e
decisione sui rischi deve essere aperta e veritiera. Le risposte ai rischi riflettono ci
che lorganizzazione percepisce come punto di equilibrio tra lassumere e levitare il
rischio.
Per una buona riuscita, la struttura organizzativa dovrebbe impegnarsi ad
affrontare la gestione dei rischi in modo proattivo ed uniforme per tutto il progetto.
240

11
Figura 11-2. Diagramma di flusso dei processi di gestione dei rischi di progetto

241
11.1 Pianificazione della gestione dei rischi

Una pianificazione attenta e chiara non pu che aumentare le possibilit di successo
degli altri cinque processi di gestione del rischio. La pianificazione della gestione dei
rischi il processo con cui si decide quale tipo di approccio al rischio adottare e come
condurre le attivit di gestione del rischio in un progetto. Il processo di pianificazione
della gestione del rischio garantisce che il livello, il tipo e la visibilit della gestione
dei rischi siano proporzionati al rischio e allimportanza data dallorganizzazione al
progetto in modo da fornire sufficienti risorse e tempo per le attivit di gestione del
rischio e concordare un criterio di base per la valutazione dei rischi. Il processo di
pianificazione della gestione del rischio dovrebbe essere completato nelle prime fasi
di pianificazione del progetto, poich essenziale per la corretta esecuzione degli altri
processi descritti nel presente capitolo.
Figura 11-3. Pianificazione della gestione dei rischi: Input, Strumenti e tecniche e Output
11.1.1 Pianificazione della gestione dei rischi: Input

Lattitudine e i limiti di tolleranza al rischio della struttura organizzativa e delle
persone coinvolte nel progetto influiscono sul piano di Project Management
(paragrafo 4.3). Lapproccio e i limiti di tolleranza possono essere espressi nelle
descrizioni dei criteri o rivelati dalle modalit di esecuzione dei progetti (paragrafo
4.1.1.3).
Le strutture organizzative possono adottare approcci predefiniti alla gestione dei rischi
quali le categorie di rischio, la definizione di concetti e termini comuni, i modelli di
documento standard, i ruoli e le responsabilit e i livelli di autorit del processo
decisionale.
242

11.1.2 Pianificazione della gestione dei rischi: strumenti e tecniche

.1 Incontri sulla pianificazione e analisi
I gruppi di progetto organizzano incontri sulla pianificazione per sviluppare il piano di
gestione dei rischi. I partecipanti alle riunioni sono il project manager, membri
selezionati del gruppo di progetto e degli stakeholder, chiunque allinterno della
struttura organizzativa sia responsabile della pianificazione della gestione del rischio e
dellesecuzione delle attivit, altre persone in base alle necessit.
In queste riunioni vengono definiti i piani fondamentali per la conduzione delle
attivit di gestione dei rischi. Gli elementi del costo dei rischi e le attivit schedulate
vengono elaborati per essere rispettivamente inseriti nel budget del progetto e nella
schedulazione. Vengono inoltre assegnate le responsabilit in relazione ai rischi. I
modelli di documento generici dellorganizzazione riferiti alle categorie di rischio e
alle definizioni di termini quali livelli di rischio, probabilit per tipo di rischio, impatto
per tipo di obiettivo e matrice di probabilit e impatto vengono elaborati su misura per
il progetto specifico. Nel piano di gestione dei rischi contenuto un riepilogo degli
output di tali attivit.
11.1.3 Pianificazione della gestione dei rischi: Output

.1 Piano di gestione dei rischi
Il piano di gestione dei rischi descrive in che modo viene strutturata ed eseguita la
gestione dei rischi nel corso del progetto e diventa un sottoinsieme del piano di
Project Management (paragrafo 4.3). Le informazioni contenute nel piano di gestione
dei rischi sono:
Metodologia: definisce gli approcci, gli strumenti e le fonti di informazione
utilizzati per eseguire la gestione dei rischi nel corso del progetto.
Ruoli e responsabilit: questa sezione definisce il responsabile, il supporto e i
membri del gruppo di gestione dei rischi per ciascun tipo di attivit inclusa nel
piano di gestione dei rischi; assegna inoltre le persone a tali ruoli e chiarisce le
responsabilit.
Budget: assegna le risorse e stima i costi necessari per la gestione dei rischi da
includere nella baseline dei costi del progetto (paragrafo 7.2.3.1).
Tempi: definisce quando e con che frequenza eseguire il processo di gestione
dei rischi durante il ciclo di vita del progetto e stabilisce le attivit di gestione
dei rischi da includere nella schedulazione di progetto (paragrafo 6.5.3.1).
Categorie di rischio: forniscono una struttura che garantisce lesaustivit del
processo atto allidentificazione sistematica dei rischi a un livello di dettaglio
sempre omogeneo e favoriscono lefficacia e la qualit del processo di
identificazione dei rischi. Unorganizzazione ha la possibilit di utilizzare una
categorizzazione dei rischi pi comuni preparata in precedenza. La struttura di
scomposizione dei rischi, RBS, (figura 11-4) uno dei metodi per elaborare una
struttura di questo tipo, che pu comunque essere gestita mediante un semplice
elenco dei vari aspetti del progetto. Le categorie di rischio possono essere
riesaminate anche nel corso del processo Identificare i Rischi. comunque
buona norma esaminare le categorie di rischio nel corso del processo di
pianificazione della rischi prima di utilizzarle per identificare i rischi. Qualora si
adottino le categorie di rischio basate su progetti precedenti, potrebbe rivelarsi
necessario adattarle, regolarle o estenderle a situazioni nuove prima di utilizzarle
per il progetto corrente.
11

243
Definizioni della probabilit e dellimpatto dei rischi: la qualit e la

credibilit del processo di analisi qualitativa del rischio richiedono la definizione
dei diversi livelli di probabilit e impatto dei rischi. Nel corso del processo di
pianificazione della gestione dei rischi, le definizioni generali dei livelli di
probabilit e dei livelli di impatto vengono adattate al singolo progetto per
essere utilizzate nel processo Analisi Qualitativa del Rischio (paragrafo 11.3).
Figura 11-4. Esempio di struttura di scomposizione dei rischi (RBS)
possibile utilizzare una scala relativa che rappresenti i valori della probabilit
da molto improbabile a quasi certo. Unalternativa quella di assegnare dei valori
di probabilit numerici su una scala generica (ad es. 0,1, 0,3, 0,5, 0,7, 0,9). Un
ulteriore approccio alla calibrazione della probabilit comporta lo sviluppo delle
descrizioni dello stato del progetto riguardanti il rischio considerato (ad es. il grado di
maturit dellarchitettura del progetto).
244

In caso di manifestazione effettiva del rischio, la scala di impatto riflette

limportanza dellimpatto, a prescindere dal fatto che questo sia negativo per le
minacce o positivo per le opportunit, su ciascuno degli obiettivi del progetto. Le
scale di impatto sono specifiche dellobiettivo su cui potenzialmente potrebbe
verificarsi limpatto, del tipo e delle dimensioni del progetto, delle strategie e dello
stato finanziario, della sensibilit della struttura organizzativa stessa a impatti
particolari. Le scale relative di impatto sono semplicemente degli elementi descrittivi
ordinati per categoria come molto basso, basso, medio, elevato e molto
elevato che riflettono impatti sempre pi estremi in base a quanto definito dalla
struttura organizzativa. In alternativa, le scale numeriche assegnano dei valori a questi
impatti che possono essere lineari (0,1 - 0,3 - 0,5 - 0,7 - 0,9) o non lineari (0,05 - 0,1 0,2 - 0,4 - 0,8). Le scale non lineari rappresentano il desiderio dellorganizzazione di
evitare le minacce ad elevato impatto di trarre vantaggio dalle opportunit ad elevato
impatto, anche se queste sono caratterizzate da una probabilit molto bassa. Se si
utilizzano delle scale non lineari, necessario comprendere il significato di ogni
valore numerico e delle relazioni reciproche, il sistema utilizzato per ottenerle e
leffetto che possono avere su obiettivi diversi del progetto.
La figura 11-5 riporta un esempio di definizioni di impatti negativi che possono
essere utilizzate per valutare gli impatti del rischio negativi in merito a quattro
obiettivi del progetto. La figura mostra sia lapproccio relativo che quello numerico
(in questo caso non lineare). Lesempio non implica che i termini relativo e numerico
siano equivalenti, ma raggruppa semplicemente due alternative in ununica figura.
Matrice di probabilit e impatto: ai rischi vengono assegnate delle priorit in
base alle loro potenziali implicazioni sul raggiungimento degli obiettivi del
progetto. Lapproccio pi comune per lassegnazione delle priorit ai rischi dato
dallutilizzo di una tabella di consultazione o una matrice di probabilit e impatto
(figura 11-8 e paragrafo 11.3.2.2). in genere responsabilit della struttura
organizzativa impostare le combinazioni di probabilit e impatto specifiche che
portano alla classificazione dellimportanza di un rischio come alta, media o
bassa, unitamente allimportanza corrispondente della pianificazione delle
risposte al rischio (paragrafo 11.5). Tali fattori vengono riesaminati e adeguati al
progetto specifico nel corso del processo di pianificazione della gestione dei
rischi.
11
Figura 11-5. Definizione delle scale di impatto per quattro obiettivi di progetto

245
Riesame dei limiti di tolleranza degli stakeholder: i limiti di tolleranza degli

stakeholder vengono riesaminati nel processo di pianificazione della gestione
dei rischi in base alle esigenze del progetto specifico.
Formati di reporting: descrive il contenuto e il formato del registro dei rischi
(paragrafi 11.2, 11.3, 11.4 e 11.5) e di qualsiasi altro necessario report sui rischi.
Definisce come vengono effettuate la documentazione, lanalisi e la
comunicazione dei risultati ottenuti dal processo di gestione dei rischi.
Tracking: documenta come tutti gli aspetti delle attivit di rischio vengono
registrati per poterne trarre vantaggio nel corso del progetto, per esigenze future
e per le lesson learned. Documenta se e come vengono revisionati i processi di
gestione dei rischi.
11.2 Identificazione dei rischi

Questo processo consente di determinare quali rischi possono influire sul progetto e di
documentarne le caratteristiche. A seconda delle esigenze del caso, i partecipanti alle
attivit di identificazione dei rischi possono contemplare le seguenti figure: project
manager, membri del gruppo di progetto, gruppo di gestione dei rischi (se assegnato),
esperti in materia esterni al gruppo di progetto, clienti, utenti finali, altri project
manager, stakeholder ed esperti nella gestione dei rischi. Sebbene queste persone
siano dei partecipanti fondamentali per il processo Identificazione dei rischi,
necessario che tutto il personale coinvolto nel progetto sia incoraggiato a identificare i
rischi.
Lidentificazione dei rischi un processo di tipo iterativo: con il progressivo
avanzare del ciclo di vita del progetto potrebbero infatti venire rilevati rischi nuovi
(paragrafo 2.1). La frequenza delliterazione e la tipologia di persone coinvolte in
ciascun ciclo variano da caso a caso. Al processo dovrebbe comunque prendere parte
il gruppo di progetto, in modo che possa sviluppare e conservare un senso di titolarit
e responsabilit nei confronti dei rischi e delle corrispondenti azioni di risposta. Gli
stakeholder esterni al gruppo di progetto possono fornire delle informazioni
aggiuntive da un punto di vista diverso da quello del gruppo di progetto. Il processo
Identificazione dei rischi porta in genere al processo Analisi qualitativa del rischio
(paragrafo 11.3). In alternativa, potrebbe condurre direttamente al processo Analisi
quantitativa del rischio (paragrafo 11.4), qualora sia eseguito da un manager dei rischi
con molta esperienza in materia. In alcuni casi, possibile che la mera identificazione
dei rischi suggerisca la relativa risposta; comunque consigliabile registrare tali
fattori per consentirne in futuro lo studio e limplementazione nel corso del processo
di pianificazione della risposta ai rischi (paragrafo 11.5).
Figura 11-6. Identificare i rischi: Input, Strumenti e tecniche e Output
246

11.2.1 Identificazione dei rischi: Input

Le informazioni pubblicate, compresi i database commerciali, gli studi accademici, il
benchmarking o altri studi di settore possono essere un valido strumento
nellidentificazione dei rischi (paragrafo 4.1.1.3).
possibile ricavare informazioni su progetti precedenti dai file elaborati in occasione
di tali progetti, compresi i dati effettivi e le lesson learned (paragrafo 4.1.1.4).
Gli assunti di progetto sono riportati nella descrizione dellambito del progetto
(paragrafo 5.2.3.1). Qualsiasi incertezza negli assunti di progetto deve essere valutata
come potenziale causa di rischi per il progetto.
Gli input principali provenienti dal piano di gestione dei rischi utilizzati per il
processo Identificazione dei rischi sono rappresentati dalle assegnazioni di ruoli e
responsabilit, dalle disposizioni sulle attivit di gestione dei rischi nel budget e nella
schedulazione e dalle categorie di rischio (paragrafo 11.1.3.1) che vengono talvolta
espresse nella struttura di scomposizione dei rischi (figura 11-4).
Il processo Identificazione dei rischi richiede inoltre una comprensione della
schedulazione, del costo e dei piani di gestione della qualit presenti nel piano di
Project Management (paragrafo 4.3). necessario rivedere gli output dei processi di
unarea di conoscenza per poter individuare la presenza di possibili rischi relativi
allintero progetto.
11
11.2.2 Identificazione dei rischi: Strumenti e tecniche

.1 Revisioni della documentazione
possibile effettuare una revisione strutturata della documentazione del progetto,
compresi piani, assunti, file di progetti precedenti e altre informazioni. La qualit dei
piani e lomogeneit tra questi, i requisiti e gli assunti del progetto sono validi
indicatori di rischio per il progetto.
.2 Tecniche di raccolta delle informazioni
Di seguito vengono illustrati alcuni esempi delle tecniche di raccolta delle
informazioni utilizzate nellidentificazione dei rischi.
Brainstorming: lobiettivo del brainstorming consiste nello stilare un elenco
esaustivo dei rischi del progetto. In genere, il gruppo di progetto esegue questa
attivit in collaborazione con un insieme multidisciplinare di esperti non
appartenenti al gruppo. Le idee sul rischio del progetto vengono elaborate sotto
la guida di un mediatore. Le categorie di rischio (paragrafo 11.1), cosi come la
struttura di scomposizione dei rischi, possono essere adottate come quadro di
riferimento. I rischi vengono poi identificati e categorizzati in base al tipo e le
definizioni corrispondenti vengono ulteriormente perfezionate.

247
Tecnica Delphi: la tecnica Delphi un metodo che consente di ottenere il

consenso degli esperti. Gli esperti in materia di rischi del progetto partecipano
alle procedure di questa tecnica in forma anonima. Il moderatore utilizza un
questionario per stimolare la nascita di idee sui rischi rilevanti per il progetto. Le
risposte vengono sintetizzate e quindi riproposte agli esperti per ulteriori
commenti. possibile che si ottenga il consenso ripetendo il processo
pochissime volte. La tecnica Delphi consente di ridurre la parzialit dei dati e
impedisce che qualche partecipante eserciti uninfluenza maggiore degli altri sul
risultato.
Colloqui: lidentificazione dei rischi pu essere favorita mediante colloqui con
partecipanti di comprovata esperienza coinvolti nel progetto , gli stakeholder ed
altri esperti della materia. I colloqui rappresentano una delle principali fonti di
raccolta dei dati per lidentificazione dei rischi.
Identificazione della causa principale: si tratta di unindagine sulle cause
fondamentali dei rischi di un progetto. Consente di perfezionare la definizione
del rischio e di raggruppare i rischi in base alle cause. Se si esamina con
attenzione la causa principale del rischio, possibile elaborare delle risposte
efficaci contro i rischi.
SWOT Analysis (Analisi dei punti di forza, delle debolezze, delle
opportunit e delle minacce): questa tecnica consente di effettuare lanalisi del
progetto in base a ogni punto di vista dei fattori SWOT, ampliando quindi la
gamma di rischi presi in considerazione.
.3 Analisi in base a liste di controllo

Le liste di controllo per lidentificazione dei rischi vengono elaborate in base ai dati
storici e alle conoscenze che sono state acquisite in occasione di analoghi progetti
precedenti o provenienti da altre fonti di informazione. possibile adottare come lista
di controllo dei rischi anche il livello pi basso della struttura di scomposizione dei
rischi. Sebbene una lista di controllo sia rapida e semplice, impossibile elaborarne
una che risulti esaustiva. quindi necessario esaminare con molta attenzione le voci
non incluse nella lista di controllo, che deve essere analizzata nel corso della chiusura
del progetto per essere migliorata in vista del riutilizzo in progetti futuri.
.4 Analisi degli assunti
Ogni progetto viene concepito e sviluppato in base a un insieme di ipotesi, scenari o
assunti. Lanalisi degli assunti uno strumento che consente di indagare sulla validit
degli assunti applicati al progetto. Identifica inoltre i rischi del progetto legati a
imprecisione, incongruenza o incompletezza degli assunti.
.5 Tecniche di generazione dei diagrammi
Di seguito vengono illustrate le tecniche di generazione dei diagrammi sui rischi.
Diagrammi causa-effetto (paragrafo 8.3.2.1): noti anche come diagrammi di
Ishikawa o a lisca di pesce, sono un valido mezzo di identificazione delle cause
dei rischi.
Diagrammi di flusso del sistema o dei processi: mostrano la correlazione tra i
vari elementi di un sistema e il meccanismo di causalit (paragrafo 8.3.2.3).
Diagrammi dinfluenza: rappresentazioni grafiche delle situazioni che
mostrano le influenze causali, lordine temporale degli eventi e altre relazioni tra
variabili e risultati.
248

11.2.3 Identificazione dei rischi: Output

Gli output derivanti dal processo Identificazione dei rischi vengono in genere riportati
in un documento chiamato registro dei rischi.
.1 Registro dei rischi
Gli output principali ottenuti dal processo Identificazione dei rischi sono le voci
inizialmente immesse nel Registro dei rischi, che a sua volta diventa una componente
del piano di Project Management (paragrafo 4.3). Il registro dei rischi contiene anche i
risultati di altri processi di gestione condotti nel progetto. La preparazione del registro
dei rischi ha inizio con il processo Identificazione dei rischi, nel quale vengono
immesse le informazioni riportate di seguito; il registro viene poi reso disponibile
anche per altri processi di Project Management e di gestione dei rischi di progetto.
Elenco dei rischi identificati: vengono descritti i rischi identificati, comprese le
relative cause principali e gli assunti incerti del progetto. I rischi possono
estendersi a quasi tutti gli argomenti; di seguito vengono illustrati alcuni esempi.
Si esamini il caso di alcuni articoli di grandi dimensioni con lead time lunghi
che si trovano su un percorso critico. Esiste il rischio che le controversie nelle
relazioni industriali insorte negli scali marittimi possano ritardare la consegna e,
di conseguenza, anche il completamento della fase di costruzione. Un altro
esempio dato da un piano di Project Management che prevede la presenza di
dieci membri del gruppo di progetto, mentre nella realt ne sono disponibili
soltanto sei. La mancanza di risorse pu influire sul tempo necessario per il
completamento del lavoro con relativo ritardo delle attivit.
Elenco delle potenziali risposte: le potenziali risposte a un rischio possono
essere identificate nel corso del processo Identificazione dei rischi. Queste
risposte, se identificate, possono essere utilizzate come input per il processo di
pianificazione della risposta ai rischi (paragrafo 11.5).
Cause principali di rischio: condizioni o eventi fondamentali che possono dare
origine al rischio identificato.
Categorie di rischio aggiornate: il processo di identificazione dei rischi pu
portare allinserimento di nuove categorie di rischio nellelenco di quelle gi
esistenti. Potrebbe rivelarsi necessario migliorare o correggere la struttura di
scomposizione delle risorse sviluppata nel processo di pianificazione della
gestione dei rischi in base ai risultati ottenuti con il processo Identificazione dei
rischi.
11
11.3 Analisi qualitativa dei rischi

L'analisi qualitativa dei rischi definisce i metodi adottati per assegnare le priorit ai
rischi identificati e che consentono di procedere con altre azioni, ad esempio con
unanalisi quantitativa del rischio (paragrafo 11.4) o una pianificazione della risposta
ai rischi (paragrafo 11.5). Le organizzazioni possono migliorare in modo efficace le
prestazioni del progetto rivolgendo la propria attenzione ai rischi con priorit elevata.
Lanalisi qualitativa del rischio valuta la priorit dei rischi identificati attraverso la
probabilit che si verifichino, il relativo impatto sugli obiettivi di progetto nel caso
delleffettivo verificarsi e altri fattori, come durata e tolleranza al rischio dei vincoli di
progetto per costo, schedulazione, ambito e qualit.
Le definizioni dei livelli di probabilit e impatto e i colloqui con gli esperti
possono contribuire alla correzione degli errori che spesso caratterizzano i dati
utilizzati in questo processo. La criticit in termini di tempo delle azioni correlate ai
rischi pu incrementare limportanza di un rischio. Una valutazione della qualit delle
informazioni a disposizione sui rischi del progetto facilita la comprensione della
valutazione dellimportanza del rischio per il progetto.

249
Lanalisi qualitativa del rischio rappresenta in genere uno strumento rapido ed

economico per stabilire delle priorit per la pianificazione della risposta ai rischi e
getta le basi per lanalisi quantitativa del rischio, qualora sia richiesta. Lanalisi
qualitativa del rischio dovrebbe essere riesaminata nel corso del ciclo di vita del
progetto per essere aggiornata in base alle relative modifiche dei rischi del progetto.
Lanalisi qualitativa del rischio necessita degli output ottenuti dai processi
Pianificazione della gestione dei rischi (paragrafo 11.1) e Identificazione dei rischi
(paragrafo 11.2). Questa analisi pu condurre allanalisi quantitativa del rischio
(paragrafo 11.4) oppure portare direttamente alla pianificazione della risposta ai rischi
(paragrafo 11.5).
Figura 11-7. Analisi qualitativa del rischio: Input, Strumenti e tecniche e Output
11.3.1 Analisi qualitativa dei rischi: Input

I dati sui rischi dei progetti passati e la knowledge base delle lesson learned possono
essere utilizzati nel processo di Analisi qualitativa del rischio.
I progetti comuni o ricorrenti sono in genere caratterizzati da rischi noti. I progetti che
si avvalgono delle pi moderne e avanzate tecnologie e i progetti estremamente
complessi sono caratterizzati da maggiore incertezza. Per la valutazione di questo
fenomeno si consiglia di esaminare la descrizione dellambito del progetto (paragrafo
5.2.3.1).
Gli elementi principali del piano di gestione dei rischi per lanalisi qualitativa del
rischio sono i ruoli e le responsabilit legati alla conduzione della gestione dei rischi, i
budget e le attivit schedulate per la gestione dei rischi, le categorie di rischio, la
definizione di probabilit e impatto, la matrice di probabilit e impatto e lanalisi dei
limiti di tolleranza ai rischi degli stakeholder (compresi i fattori ambientali aziendali
descritti nel paragrafo 4.1.1.3). Tali input vengono in genere adattati al progetto nel
corso del processo di pianificazione della gestione dei rischi. Se non sono disponibili,
possono essere sviluppati nel corso dellanalisi qualitativa del rischio.
Uno degli elementi principali del registro dei rischi per lanalisi qualitativa del rischio
rappresentato dallelenco dei rischi identificati (paragrafo 11.2.3.1).
250

11.3.2 Analisi qualitativa dei rischi: Strumenti e tecniche

.1 Valutazione della probabilit e dellimpatto dei rischi
La valutazione della probabilit dei rischi esamina la possibilit che ciascun rischio si
verifichi. La valutazione dellimpatto dei rischi esamina invece leffetto potenziale su
un obiettivo di progetto quale tempo, costo, ambito o qualit, compresi sia gli effetti
negativi delle minacce sia gli effetti positivi delle possibilit.
Per ogni rischio identificato vengono valutati probabilit e impatto. possibile
determinare i rischi mediante colloqui o riunioni con partecipanti selezionati in base
alla rispettiva esperienza nelle categorie di rischio inserite nellordine del giorno,
compresi i membri del gruppo di progetto e, talvolta, le persone informate esterne al
progetto. Si ricorre inoltre al parere di esperti, poich le informazioni sui rischi
presenti nei database della struttura organizzativa ricavate da progetti precedenti
potrebbero non essere sufficienti. Qualora i partecipanti non avessero molta
esperienza nella valutazione dei rischi, consigliabile inoltre la presenza di un
moderatore esperto per la conduzione della discussione.
La valutazione del livello di probabilit di ogni rischio e del relativo impatto su
ciascun obiettivo di progetto viene effettuata nel corso dei colloqui e delle riunioni.
Vengono registrati anche i dettagli esplicativi, compresi gli assunti che giustificano i
livelli assegnati. Le probabilit e gli impatti dei rischi vengono quindi classificati in
base alle definizioni fornite nel piano di gestione dei rischi (paragrafo 11.1.3.1). A
volte, i rischi con indici di probabilit e impatto palesemente bassi non vengono
classificati, anche se vengono inclusi in una watchlist per essere monitorati in futuro.
11
.2 Matrice di probabilit e impatto

Lassegnazione delle priorit ai rischi facilita le ulteriori analisi quantitative future
(paragrafo 11.4) e le risposte (paragrafo 11.5) in base alla classificazione dei relativi
rischi secondo la valutazione di probabilit e impatto (paragrafo 11.3.2.2). La
valutazione dellimportanza di ciascun rischio e, quindi, delle relative priorit viene in
genere condotta mediante una tabella di consultazione o una matrice di probabilit e
impatto (figura 11-8). Questo tipo di matrice specifica le combinazioni di probabilit e
impatto che portano alla classificazione dei rischi in priorit bassa, media o elevata. A
seconda delle preferenze della struttura organizzativa, possibile utilizzare anche
termini descrittivi o valori numerici.
La struttura organizzativa dovrebbe determinare quali combinazioni di
probabilit e impatto conducono a una classificazione di rischio elevato (condizione
rossa), rischio medio (condizione gialla) e rischio basso (condizione verde). In
una matrice in bianco e nero, queste condizioni possono essere raffigurate con diverse
sfumature di grigio. Nella figura 11-8, larea di colore grigio scuro (con i numeri pi
alti) rappresenta un rischio elevato; larea grigio intermedio (con i numeri pi piccoli)
rappresenta un rischio basso; infine, larea grigio chiaro (con numeri intermedi)
rappresenta un rischio moderato. In genere, lorganizzazione specifica le regole di
classificazione dei rischi prima dellavvio del progetto, per inserirle quindi negli asset
dei processi organizzativi (paragrafi 4.1.1.4). Le regole di classificazione dei rischi
possono essere adattate al progetto nel corso della pianificazione della gestione dei
rischi (paragrafo 11.1).
Spesso viene utilizzata una matrice di probabilit e impatto, come quella
mostrata nella figura 11-8.

251
Figura 11-8. Matrice di probabilit e impatto
Come illustrato nella figura 11-8, una struttura organizzativa pu classificare un

rischio per ogni singolo obiettivo (ad es. costo, tempi e ambito) e sviluppare dei
metodi che consentano di determinare una classificazione complessiva di ciascun
rischio. Infine, le opportunit e le minacce possono essere gestite nella stessa matrice
mediante appropriate definizioni dei diversi livelli di impatto.
Il punteggio attribuito al rischio consente di indirizzare le relative risposte. Ad
esempio, i rischi con impatto negativo sugli obiettivi (minacce) e quelli presenti
nellarea a rischio elevato (grigio scuro) della matrice potrebbero richiedere unazione
prioritaria e strategie di risposta aggressive. Per le minacce nellarea a basso rischio
(grigio intermedio) potrebbe essere necessario adottare azioni di gestione proattive
oltre a inserire le minacce stesse in una watchlist o ad aggiungere una riserva per
contingency.
Analogamente, necessario affrontare prima le opportunit presenti nellarea ad
alto rischio (grigio scuro) che potrebbero essere ottenute nel modo pi semplice e che
offrono il vantaggio maggiore. Le opportunit nellarea a basso rischio (grigio
intermedio) dovrebbero essere monitorate.
.3 Valutazione della qualit dei dati sui rischi
Per poter essere credibile, lanalisi qualitativa del rischio richiede dati accurati e
imparziali. Lanalisi della qualit dei dati sui rischi una tecnica che consente di
valutare il grado di utilit dei dati sui rischi ai fini della gestione degli stessi. Essa
comprende lanalisi del livello di comprensione del rischio, dellaccuratezza, della
qualit e dellintegrit dei dati sui rischi.
Lutilizzo di dati di bassa qualit sui rischi pu ridurre sensibilmente lutilit
dellanalisi qualitativa del rischio per il progetto. Se la qualit dei dati non
accettabile, potrebbe rendersi necessaria unulteriore raccolta dati. La raccolta di
informazioni sui rischi non sempre una procedura semplice e puo comportare un
dispendio di tempo e risorse non previsto dal piano originale.
252

.4 Categorizzazione dei rischi

I rischi del progetto possono essere categorizzati in base alle fonti di rischio (lutilizzo
della RBS), allarea del progetto interessata (utilizzo della WBS) o ad altra categoria
utile (fase di progetto) per determinare le aree del progetto maggiormente esposte agli
effetti dellincertezza. Il raggruppamento dei rischi per causa principale comune
facilita lo sviluppo di risposte efficaci contro i rischi stessi.
.5 Valutazione dellurgenza dei rischi
I rischi che richiedono una risposta a breve termine potrebbero essere ritenuti pi
urgenti di altri. Gli indicatori di priorit sono i tempi di esecuzione della risposta ai
rischi, i sintomi e i segnali di avvertimento e la classificazione dei rischi.
11.3.3 Analisi qualitativa dei rischi: Output

.1 Registro dei rischi (aggiornamenti)
Il registro dei rischi viene avviato nel corso del processo Identificazione dei rischi,
viene aggiornato in base alle informazioni provenienti dallanalisi qualitativa del
rischio e la versione aggiornata viene inserita nel piano di Project Management. Di
seguito vengono illustrati gli aggiornamenti del registro dei rischi derivanti dallanalisi
qualitativa del rischio.
Classificazione relativa o elenco di priorit dei rischi di progetto: la matrice
di probabilit e impatto consente di classificare i rischi in base alla loro
importanza. Il project manager pu adottare un elenco delle priorit per
rivolgere la propria attenzione agli elementi particolarmente significativi per il
progetto, per i quali le risposte possono favorire il miglioramento dei risultati.
possibile elencare i rischi in base alla priorit e separatamente per costo, tempi,
ambito e qualit, poich le organizzazioni potrebbero favorire un obiettivo
rispetto agli altri. necessario inserire anche una descrizione della probabilit e
dellimpatto stimati per i rischi ritenuti rilevanti per il progetto.
Rischi raggruppati per categorie: la categorizzazione dei rischi pu rivelare la
presenza di cause principali comuni o di aree del progetto che richiedono
unattenzione particolare. La scoperta di concentrazioni dei rischi pu
migliorare lefficacia delle risposte agli stessi.
Elenco dei rischi che richiedono una risposta a breve termine: possibile
separare in gruppi diversi i rischi che richiedono una risposta urgente rispetto a
quelli che possono essere affrontati in un secondo momento.
Elenco dei rischi per unulteriore analisi e risposta: alcuni rischi potrebbero
richiedere unulteriore analisi, compresa lanalisi quantitativa del rischio, e
unulteriore azione di risposta.
Watchlist dei rischi di priorit bassa: i rischi che non vengono valutati come
importanti nel corso dellanalisi qualitativa del rischio possono essere aggiunti
in una watchlist ai fini del monitoraggio continuo.
Tendenze nei risultati dellanalisi qualitativa del rischio: con la ripetizione
dellanalisi, potrebbe risultare evidente una tendenza a particolari rischi che
rende pi o meno urgente/importante la risposta ai rischi o lesecuzione di
unanalisi aggiuntiva.
11

253
11.4 Analisi quantitativa dei rischi

L'analisi quantitativa dei rischi viene eseguita in merito ai rischi a cui stata assegnata
una priorit, tramite lanalisi qualitativa del rischio, perch ritenuti potenzialmente e
sostanzialmente influenti sulle richieste concorrenziali del progetto. Lanalisi
quantitativa esamina leffetto di questi eventi di rischio e assegna loro una
classificazione numerica. In caso di incertezza offre anche un approccio quantitativo
per il processo decisionale. Il processo utilizza tecniche quali la simulazione Monte
Carlo e lanalisi dellalbero delle decisioni per effettuare le operazioni riportate di
seguito:
Quantificare i possibili risultati del progetto e le relative probabilit.
Valutare la probabilit di raggiungere determinati obiettivi di progetto.
Identificare i rischi che richiedono la maggiore attenzione quantificandone il
contributo relativo al rischio complessivo del progetto.
Identificare obiettivi di costo, schedulazione o ambito realistici e raggiungibili,
dati i rischi di progetto.
Determinare la migliore decisione di Project Management in presenza di
condizioni o risultati incerti.
Lanalisi quantitativa del rischio viene in genere eseguita dopo lanalisi
qualitativa del rischio, anche se alcuni manager dei rischi con molta esperienza la
eseguono direttamente dopo il processo Identificazione dei rischi. In alcuni casi,
lanalisi quantitativa del rischio non necessaria per sviluppare risposte efficaci ai
rischi. La disponibilit di tempo e budget e la necessit di descrizioni qualitative o
quantitative di rischi e impatti consentono di determinare quali metodi utilizzare per i
diversi progetti. Dopo la pianificazione della risposta ai rischi dovrebbero essere
ripetute lanalisi quantitativa del rischio e una parte del monitoraggio e del controllo
dei rischi, per determinare se il rischio complessivo del progetto diminuito in misura
soddisfacente. Gli andamenti possono inoltre indicare lesigenza di incrementare o
diminuire lazione di gestione dei rischi. Si tratta di un input per il processo di
Pianificazione della risposta ai rischi.
Figura 11-9. Analisi quantitativa del rischio: Input, Strumenti e tecniche e Output
254

11.4.1 Analisi quantitativa dei rischi: Input

Informazioni su progetti simili portati a termine in precedenza, studi di progetti simili
svolti da specialisti del settore rischi e database dei rischi resi disponibili dal settore o
da fonti di propriet dei rispettivi titolari.
Gli elementi di base del piano di gestione dei rischi per lanalisi quantitativa del
rischio sono i ruoli e le responsabilit per la conduzione della gestione dei rischi, i
budget e le attivit schedulate per la gestione dei rischi, le categorie di rischio, la
struttura di scomposizione dei rischi e i limiti di tolleranza ai rischi degli stakeholder.
Gli elementi principali ottenuti dal registro dei rischi per lanalisi quantitativa del
rischio sono lelenco dei rischi identificati, la classificazione relativa o lelenco delle
priorit dei rischi di progetto e i rischi raggruppati per categorie.
Di seguito vengono illustrati gli elementi compresi nel piano di Project Management:
Piano di gestione della schedulazione di progetto: questo piano consente di
configurare il formato e di stabilire i criteri per lo sviluppo e il controllo della
schedulazione di progetto (descritta nel materiale introduttivo del capitolo 6).
Piano di gestione dei costi di progetto: questo piano consente di configurare il
formato e di stabilire i criteri per la pianificazione, la strutturazione, la stima, il
budget e il controllo dei costi di progetto (descritto nel materiale introduttivo del
capitolo 7).
11
11.4.2 Analisi quantitativa dei rischi: Strumenti e tecniche

.1 Tecniche di raccolta e rappresentazione dei dati
Colloqui: la tecnica del colloquio viene utilizzata per quantificare la probabilit
e limpatto dei rischi sugli obiettivi del progetto. Le informazioni richieste
dipendono dal tipo di distribuzioni di probabilit che verr adottato. Ad
esempio, verranno raccolti dati relativi agli scenari ipotetici ottimistici (basso),
pessimistici (elevato) o pi probabili per alcune distribuzioni utilizzate con
maggiore frequenza, mentre per altre distribuzioni si calcoleranno la media e la
deviazione standard. La figura 10-11 mostra alcuni esempi di stima dei costi a
tre valori. La documentazione del fondamento logico alla base della scelta degli
intervalli di rischio un componente fondamentale nei colloqui aventi come
oggetto i rischi, poich in grado di fornire informazioni utili sullaffidabilit e
sulla credibilit dellanalisi.

255
Figura 11-10. Intervallo delle stime dei costi di progetto nel corso dei colloqui sui rischi
Distribuzioni di probabilit: le distribuzioni continue di probabilit

rappresentano le incertezze in termini di valori come le durate delle attivit
schedulate e i costi dei componenti del progetto. Le distribuzioni discrete
consentono invece di rappresentare degli eventi incerti, quali il risultato di una
verifica o un possibile scenario ipotetico nellalbero decisionale. La figura 11-11
mostra due esempi di distribuzioni continue comunemente utilizzate. Tali
distribuzioni asimmetriche raffigurano degli andamenti compatibili con i dati
che vengono in genere elaborati nella fase di analisi dei rischi di progetto. Le
distribuzioni uniformi vengono invece utilizzate nel caso in cui non sia presente
un valore evidente con un grado di probabilit maggiore rispetto agli altri valori
presenti tra i limiti superiore e inferiore, come avviene nelle prime fasi di
ideazione della progettazione.
Figura 11-11. Esempi di distribuzioni di probabilit comunemente utilizzate
256

Parere degli esperti: gli esperti in materia, sia interni che esterni alla struttura
organizzativa, come ingegneri o statistici, convalidano i dati e le tecniche.
.2 Analisi quantitativa del rischio e tecniche di modellazione
Di seguito vengono illustrate le tecniche comunemente utilizzate nellanalisi
quantitativa del rischio:
Analisi di sensitivit: lanalisi di sensitivit consente di determinare quali rischi
hanno il maggiore impatto potenziale sul progetto. Prende in considerazione il
grado di incidenza dellincertezza di ogni elemento del progetto sullobiettivo
esaminato, quando tutti gli altri elementi incerti si mantengono sul valore della
baseline. Una delle raffigurazioni pi diffuse dellanalisi di sensitivit il
grafico a barre, uno strumento particolarmente efficace per confrontare
limportanza relativa delle variabili con un grado elevato di incertezza rispetto a
quelle ritenute pi stabili.
Analisi del valore monetario atteso: lanalisi del valore monetario atteso
(EMV) un concetto statistico che calcola il risultato medio nel caso in cui il
futuro presenti degli scenari che possono o meno verificarsi (ad es. analisi in
presenza di incertezze). LEMV delle opportunit viene in genere espresso sotto
forma di valori positivi, mentre quello dei rischi viene reso con valori negativi.
Per calcolare il valore monetario atteso si moltiplica il valore di ogni possibile
risultato per il tasso di probabilit che si verifichi, quindi si effettua la somma
dei valori ottenuti. Questo tipo di tecnica viene comunemente utilizzato
nellanalisi dellalbero delle decisioni (figura 11-12). Per lesecuzione
dellanalisi del rischio nei costi e nella schedulazione si consigliano sempre le
tecniche di modellazione e simulazione, perch sono pi efficienti e meno
soggette ad un uso improprio rispetto allanalisi del valore monetario atteso.
Analisi dellalbero delle decisioni: la struttura dellanalisi dellalbero delle
decisioni si ottiene mediante un diagramma ad albero delle decisioni
(figura 11-12) che descrive una situazione presa in esame e le implicazioni di
ogni scelta disponibile o scenario possibile. Comprende il costo di ciascuna
scelta disponibile, le probabilit di ogni scenario ipotetico e i guadagni di ogni
percorso logico alternativo. La risoluzione dellalbero delle decisioni fornisce il
valore monetario atteso (o altre misure che rivestono un interesse per la struttura
organizzativa) di ciascuna alternativa, una volta quantificati tutti i guadagni e le
conseguenti decisioni.
11

257
Figura 11-12. Diagramma dellalbero delle decisioni
Modellazione e simulazione: la simulazione di progetto usa un modello che

traduce le incertezze, dettagliatamente specificate, nel loro potenziale impatto
sugli obiettivi di progetto. Le simulazioni vengono in genere eseguite mediante
la tecnica Monte Carlo e prevedono di eseguire pi volte il calcolo (iterato) sul
modello del progetto ; i valori degli input sono randomizzati a partire da una
funzione delle distribuzioni di probabilit (ad es. per il costo degli elementi del
progetto o per la durata delle attivit schedulate) scelta per ciascuna iterazione
dalle distribuzioni di probabilit di ciascuna variabile. Viene quindi calcolata
una distribuzione di probabilit complessiva (ad es. costo totale o data di
completamento).
Per unanalisi dei rischi del costo, possibile utilizzare come modello per la
simulazione la tradizionale struttura di scomposizione del lavoro di progetto
(paragrafo 5.3.3.2) o la struttura di scomposizione dei costi. Per unanalisi dei rischi
della schedulazione, viene applicata la schedulazione del metodo del diagramma di
precedenza (paragrafo 6.2.2.1). La figura 11-13 mostra una simulazione dei rischi del
costo.
258

Figura 11-13. Risultati della simulazione dei rischi del costo
11.4.3 Analisi quantitativa dei rischi: Output
11

Il registro dei rischi viene creato con il processo Identificazione dei rischi (paragrafo
11.2) e modificato nellanalisi qualitativa del rischio (paragrafo 11.3); viene quindi
ulteriormente aggiornato con lanalisi quantitativa del rischio. Esso contenuto nel
piano di Project Management. Gli aggiornamenti comprendono i seguenti componenti
principali:
Analisi probabilistica del progetto: le stime vengono effettuate sulla
schedulazione di progetto e sui risultati dei costi potenziali mediante un elenco
delle possibili date di completamento e dei costi con relativi livelli di
affidabilit. Questo output, in genere espresso sotto forma di una distribuzione
cumulativa, viene utilizzato insieme ai limiti di tolleranza al rischio degli
stakeholder per consentire la quantificazione delle riserve per contingency di
costi e tempi. Tali riserve per contingency sono necessarie a mantenere il rischio
di superamento degli obiettivi del progetto a un livello ritenuto accettabile dalla
struttura organizzativa. Ad esempio, nella figura 11-13, la contingency dei costi
al 75 percentile di 9 USD, o del 22% circa rispetto ai 41 USD calcolati come
somma di tutte le stime pi probabili.
Probabilit di raggiungimento degli obiettivi di costo e tempo: tenuto conto
dei rischi a cui soggetto il progetto, possibile stimare la probabilit di
raggiungere gli obiettivi nel rispetto del piano attuale mediante i risultati
dellanalisi quantitativa del rischio. Ad esempio, nella figura 11-13, la
probabilit di raggiungere la stima dei costi pari a 41 USD (dalla figura 11-10)
allincirca del 12%.

259
Elenco in ordine di priorit dei rischi quantificati: lelenco dei rischi

comprende quelli che rappresentano le minacce o le opportunit maggiori per il
progetto. Sono inclusi i rischi che richiedono la maggiore contingency dei costi
e i rischi che, con maggiore probabilit, possono influire sul percorso critico.
Tendenze nei risultati dellanalisi quantitativa del rischio: con la ripetizione
dellanalisi, possibile individuare una tendenza che porta a conclusioni che
incidono sulle risposte ai rischi.
11.5 Pianificazione della risposta ai rischi

La pianificazione della risposta ai rischi un processo di sviluppo delle alternative e
di determinazione delle azioni che consente di migliorare le opportunit e di ridurre le
minacce agli obiettivi del progetto. Tale fase segue lanalisi qualitativa e quella
quantitativa del rischio. Prevede lidentificazione e lassegnazione di una o pi
persone (il titolare della risposta ai rischi) che si assumano la responsabilit di ogni
risposta ai rischi concordata e finanziata. La pianificazione della risposta ai rischi
esamina i rischi in base alla loro priorit, e inserisce le risorse e le attivit nel budget,
nella schedulazione e nel piano di Project Management in base alle necessit.
Le risposte ai rischi pianificate devono essere adeguate allimportanza del
rischio, convenienti in termini di costo per affrontare le sfide, tempestive, realistiche
nel del contesto del progetto, concordate da tutte le parti coinvolte e di competenza di
una persona responsabile. Spesso si rende necessario selezionare la risposta migliore
ai rischi tra una vasta gamma di alternative.
Il paragrafo Pianificazione della risposta ai rischi illustra gli approcci pi diffusi
nella pianificazione delle risposte ai rischi. Con rischi si intendono sia le minacce
che le opportunit che possono influire sul successo del progetto; per ciascun rischio
vengono poi prese in considerazione le relative risposte.
Figura 11-14. Pianificazione della risposta ai rischi: Input, Strumenti e tecniche e Output
11.5.1 Pianificazione della risposta ai rischi: Input

I componenti del piano di gestione dei rischi sono i ruoli e le responsabilit, le
definizioni dellanalisi dei rischi, le soglie di rischio per rischi bassi, medi ed elevati, i
tempi e il budget necessari per condurre la gestione dei rischi di progetto.
260

Alguns componentes do plano de gerenciamento de riscos que so entradas

importantes para o planejamento de respostas a riscos podem incluir limites de risco
para riscos baixos, moderados e altos para ajudar a entender os riscos para os quais as
respostas so necessrias, designao de pessoal e elaborao de cronogramas e
oramentao para o planejamento de respostas a riscos.
Il registro dei rischi viene prima sviluppato nel processo Identificazione dei rischi e
poi aggiornato con lanalisi qualitativa e quantitativa del rischio. Nello sviluppo delle
risposte ai rischi, possibile che la pianificazione della risposta ai rischi faccia
riferimento ai rischi identificati, alle cause principali dei rischi, agli elenchi delle
risposte potenziali, ai titolari dei rischi, ai sintomi e ai segnali di allarme.
Gli input rilevanti per la pianificazione della risposta ai rischi comprendono la
classificazione relativa o lelenco delle priorit dei rischi di progetto, un elenco dei
rischi che richiedono una risposta a breve termine, un elenco dei rischi da sottoporre a
ulteriore analisi e risposta, le tendenze individuate nei risultati dellanalisi qualitativa
del rischio, le cause principali, i rischi raggruppati per categoria e una watchlist dei
rischi di priorit bassa. Il registro dei rischi viene ulteriormente aggiornato nel corso
dellanalisi quantitativa del rischio.
11.5.2 Pianificazione della risposta ai rischi: Strumenti e tecniche

Sono disponibili numerose strategie di risposta ai rischi. Per ogni rischio necessario
selezionare la strategia o la combinazione di strategie ritenuta pi efficace. Per la
scelta della risposta pi idonea possibile avvalersi degli strumenti di analisi dei
rischi, come lanalisi dellalbero delle decisioni. Successivamente, si elaborano azioni
specifiche mirate allimplementazione della strategia scelta. Possono essere
selezionate strategie principali e di backup. possibile sviluppare un piano di riserva
per limplementazione a cui ricorrere qualora la strategia selezionata si rivelasse poco
efficace o si verificasse un rischio accettato. Spesso viene allocata una riserva per
contingency di tempi e costi. Infine, possibile elaborare i piani di contingency e
identificare le condizioni che possono richiedere la loro messa in pratica.
11
.1 Strategie per rischi negativi o minacce

Sono generalmente disponibili tre strategie per affrontare le minacce o i rischi che
possono avere impatti negativi sugli obiettivi di progetto, qualora si verificassero.
Queste strategie consistono nellevitare, nel trasferire o nel ridurre i rischi:
Evitare: evitare i rischi prevede di cambiare il piano di Project Management per
eliminare la minaccia causata da un rischio sfavorevole, di isolare gli obiettivi di
progetto dallimpatto del rischio o di ridurre la portata dellobiettivo a
repentaglio, ad esempio prolungando la schedulazione o riducendo lambito.
Alcuni rischi che insorgono nelle prime fasi del progetto possono essere evitati
se si chiariscono i requisiti, si raccolgono informazioni dettagliate, si migliorano
le comunicazioni o si acquisisce maggiore esperienza.

261
Trasferire: trasferire i rischi richiede la cessione a terzi dellimpatto negativo di

una minaccia, unitamente alla responsabilit della risposta corrispondente. Cedere
il rischio significa semplicemente assegnare a terzi la responsabilit della sua
gestione; in altri termini, non elimina il rischio. Questa strategia si rivela molto
efficace in caso di esposizione a un rischio di natura finanziaria. Trasferire i rischi
comporta quasi sempre il pagamento di un incentivo a vantaggio della parte che si
assume la responsabilit del rischio in questione. Gli strumenti per il trasferimento
sono svariati e comprendono, a titolo esemplificativo, luso di assicurazioni,
garanzie di esecuzione di contratto, altre garanzie di vario genere, ecc. Per la
cessione della responsabilit di rischi specifici a terzi possibile ricorrere a un
contratto. In molti casi, luso di un contratto a rimborso spese trasferisce il rischio
legato ai costi allacquirente, mentre un contratto a prezzo fisso, se larchitettura
del progetto stabile, trasferisce il rischio al fornitore.
Mitigare: ridurre i rischi comporta una diminuzione della probabilit e/o
dellimpatto di un evento di rischio fino a raggiungere una soglia accettabile.
Adottare unazione preventiva atta a ridurre la probabilit e/o limpatto di un
rischio che si pu verificare nel progetto si rivela spesso molto pi efficace che
tentare di riparare i danni una volta che il rischio si concretizzato. Esempi di
azioni di riduzione sono: adottare processi meno complessi, condurre un numero
maggiore di verifiche o scegliere un fornitore pi affidabile. Una azione
mitigatrice potrebbe richiedere lo sviluppo di un prototipo per ridurre il rischio di
incrementare le dimensioni rispetto a un modello di riferimento per un processo o
prodotto. Laddove non sia possibile ridurre la probabilit, la risposta di riduzione
in grado di affrontare limpatto del rischio concentrandosi sugli aspetti che
derminano la severit del rischio. Ad esempio, linserimento di elementi
ridondanti in un sottosistema pu ridurre limpatto dovuto al guasto del
componente originale.
.2 Strategie per rischi positivi od opportunit
Si consigliano tre tipi di risposta per affrontare i rischi caratterizzati da impatti
potenzialmente positivi sugli obiettivi di progetto. Queste strategie consistono nello
sfruttare, nel condividere o nel migliorare:
Sfruttare: possibile selezionare questa strategia per i rischi con impatti positivi
laddove la struttura organizzativa desidera garantire leffettivo verificarsi
dellopportunit. Il suo obiettivo consiste nel tentare di eliminare le incertezze
associate a un rischio positivo facendo in modo che lopportunit abbia
effettivamente luogo. Sfruttare una risposta immediata comporta lassegnazione al
progetto di risorse con maggiori abilit in grado di ridurre i tempi di
completamento o di fornire una qualit superiore a quella pianificata
originariamente.
Condividere: la condivisione di un rischio positivo comporta la distribuzione
della titolarit a un terzo maggiormente in grado di usufruire al meglio
dellopportunit a vantaggio del progetto. Un esempio di azione di condivisione
costituire associazioni per la condivisione dei rischi, gruppi, aziende a obiettivo o
joint venture, che possono essere fondati con il preciso intento di gestire le
opportunit.
Migliorare: questa strategia modifica le dimensioni di unopportunit
incrementando la probabilit e/o gli impatti positivi, e identificando e sfruttando al
massimo i principali abilitatori dei rischi a impatto positivo. Se si tenta di
facilitare o rafforzare la causa dellopportunit, se si affrontano e supportano in
modo proattivo le condizioni che portano al verificarsi dellopportunit, la
probabilit pu essere aumentata. possibile rivolgere lattenzione ale
potenziali cause dellimpatto cercando di incrementare la suscettibilit del
progetto allopportunit.
262

.3 Strategia sia per minacce sia per opportunit

Accettazione: questa strategia viene adottata perch non sempre possibile eliminare
completamente il rischio dal progetto. La strategia indica che il gruppo di progetto ha
deciso di non modificare il piano di Project Management per affrontare un rischio o
non in grado di individuare unaltra strategia di risposta appropriata. adatta sia per
le minacce che per le opportunit e pu essere passiva o attiva. Laccettazione passiva
non richiede alcuna azione e il gruppo di progetto deve affrontare le minacce o le
opportunit nel momento in cui si verificano. La pi comune strategia di accettazione
attiva consiste nello stabilire una riserva per contingency, compresi i valori di tempo,
denaro o risorse assegnati per gestire le minacce e le opportunit note e talvolta anche
quelle potenziali e sconosciute.
.4 Strategia di risposta contingente
Alcune risposte vengono elaborate per essere utilizzate soltanto in presenza di
determinati eventi. Ad esempio, il gruppo di progetto pu sviluppare un piano di
risposta da eseguire soltanto se si verificano determinate condizioni predefinite nel
caso in cui si ritenga che ci siano segnali sufficienti per procedere con
limplementazione del piano. necessario definire e registrare gli eventi che abilitano
le risposte di contingency, come il mancato rispetto delle milestone intermedie o
lassegnazione di una priorit maggiore a un fornitore.
11.5.3 Pianificazione della risposta ai rischi: Output

Il registro dei rischi viene sviluppato nel processo Identificazione dei rischi e
aggiornato quindi con lanalisi qualitativa e con quella quantitativa del rischio. Nel
processo di pianificazione della risposta ai rischi, vengono scelte le risposte
appropriate, concordate e incluse nel registro dei rischi, che deve essere caratterizzato
da un livello di dettaglio corrispondente allordinamento basato sulla priorit e alla
risposta pianificata. Spesso, i rischi elevati e moderati vengono esaminati nel
dettaglio. I rischi ritenuti di priorit bassa vengono inclusi in una watchlist perch
vengano monitorati a cadenza periodica. A questo punto i componenti del registro dei
rischi sono:
Rischi identificati, relative descrizioni, aree del progetto (ad es. elementi della
WBS) interessate, relative cause (ad es. elementi della RBS) e descrizione di
come i rischi influiscono sugli obiettivi di progetto.
Titolari dei rischi e assegnazione delle responsabilit.
Output derivanti dai processi di analisi qualitativa e quantitativa del rischio,
compresi gli elenchi per priorit dei rischi di progetto e analisi probabilistica del
progetto.
Strategie di risposta concordate.
Azioni specifiche per implementare la strategia di risposta scelta.
Sintomi e segnali di avvertimento dellinsorgenza dei rischi.
Budget e attivit schedulate necessarie a implementare le risposte scelte.
Riserve per contingency di tempo e costo atte a rispondere ai limiti di tolleranza
al rischio degli stakeholder.
11

263
Piani di contingency e trigger che ne richiedono lesecuzione.

Piano di riserva da utilizzare come reazione a un rischio che si verificato e
quando la risposta principale si rivelata inadeguata.
Rischi residui che si prevede rimangano anche dopo lesecuzione delle risposte
pianificate, unitamente ai rischi che sono stati deliberatamente accettati.
Rischi collaterali che si sono verificati come risultato diretto
dellimplementazione di una risposta ai rischi.
Riserve per contingency che vengono calcolate in base allanalisi quantitativa
del progetto e alle soglie di rischio della struttura organizzativa.

Il piano di Project Management viene aggiornato via via che le attivit di risposta
vengono aggiunte, dopo revisione e integrazione nel processo di controllo integrato
delle modifiche (paragrafo 4.6). Questo controllo viene applicato nel corso del
processo Dirigere e gestire lesecuzione del progetto (paragrafo 4.4) per verificare che
le azioni concordate vengano implementate e monitorate nel corso del progetto. Dopo
avere concordato le strategie di risposta, necessario reinviarle agli appropriati
processi delle altre aree di conoscenza, compresi budget e schedulazione del progetto.
.3 Accordi contrattuali legati ai rischi
possibile stringere degli accordi contrattuali, come accordi per la stipulazione di
assicurazioni, per servizi o per altri aspetti, allo scopo di specificare la responsabilit
di ciascuna delle parti in merito a rischi specifici, qualora si verificassero.
11.6 Monitoraggio e controllo dei rischi

Le risposte ai rischi pianificate (paragrafo 11.5), che sono incluse nel piano di Project
Management, vengono eseguite nel corso del ciclo di vita del progetto; ciononostante
le attivit di progetto devono essere continuamente monitorate per verificare la
presenza di rischi nuovi o cambiamenti in quelli gi identificati.
Il monitoraggio e controllo dei rischi (paragrafo 4.4) il processo di
identificazione, analisi e pianificazione di nuovi rischi, di registrazione dei rischi
identificati e di quelli inclusi nella watchlist, di rianalisi dei rischi esistenti, di
monitoraggio delle condizioni dei trigger per i piani di contingency, di monitoraggio
dei rischi residui e di revisione dellesecuzione delle risposte ai rischi nel corso della
valutazione della loro efficacia. Il processo di monitoraggio e controllo dei rischi
applica tecniche, quali lo scostamento e lanalisi delle tendenze, che prevedono
lutilizzo dei dati sulle prestazioni ottenuti dallesecuzione del progetto.
Analogamente agli altri processi di gestione dei rischi, il monitoraggio e controllo dei
rischi un processo che si estende per tutta la vita del progetto e che ha come
obiettivo anche quello di controllare se:
gli assunti del progetto sono ancora validi;
il rischio valutato ha subito delle modifiche rispetto al suo stato originario (con
lausilio dellanalisi delle tendenze);
vengono rispettati i criteri e le procedure corretti di gestione dei rischi;
le riserve per contingency di costi e tempi devono essere modificate in
conformit ai rischi del progetto.
264

Il monitoraggio e controllo dei rischi pu anche prevedere la scelta tra strategie

alternative, lesecuzione di un piano di contingency o di riserva, lesecuzione di azioni
correttive e la modifica del piano di Project Management. Il titolare della risposta ai
rischi deve presentare relazioni periodiche al project manager sullefficacia del piano,
su eventuali effetti imprevisti e sulla correzione in fase di esecuzione resa necessaria
per gestire il rischio in modo adeguato. Il monitoraggio e controllo dei rischi prevede
inoltre laggiornamento degli asset dei processi organizzativi (paragrafo 4.1.1.4),
compresi i database delle lesson learned del progetto e gli schemi di documento per la
gestione dei rischi, al fine di usufruirne nei progetti futuri.
Figura 11-15. Monitoraggio e controllo dei rischi: Input, Strumenti e tecniche e Output
11.6.1 Monitoraggio e controllo dei rischi: Input
11

Questo piano dispone di input essenziali che comprendono lassegnazione delle
persone, compresi i titolari dei rischi, dei tempi e di altre risorse alla gestione dei
rischi di progetto.
Il registro dei rischi contiene gli input essenziali, ivi inclusi i rischi identificati e i
titolari dei rischi, le risposte ai rischi concordate, le azioni di implementazione
specifiche, i sintomi e i segnali di allarme del rischio, i rischi residui e collaterali, una
watchlist dei rischi di priorit bassa e le riserve per contingency di tempi e costi.
Le richieste di modifica approvate (paragrafo 4.6.3.1) possono comprendere
cambiamenti, ad esempio, ai metodi di lavoro, ai termini contrattuali, allambito e alla
schedulazione. Le modifiche approvate possono generare rischi o modifiche ai rischi
identificati; quindi necessario analizzare tali modifiche per verificarne gli effetti sul
registro dei rischi, sul piano di risposta ai rischi o sul piano di gestione dei rischi.
Tutte le modifiche devono essere documentate a livello formale. Non possibile
elaborare o implementare le modifiche discusse verbalmente e non documentate.
.4 Informazioni sullo stato di avanzamento del lavoro
Le informazioni sullo stato di avanzamento del lavoro (paragrafo 4.4.3.7), ivi inclusi
lo stato di completamento dei deliverable di progetto, le azioni correttive e i report
sulle prestazioni, sono input di rilievo per il monitoraggio e controllo dei rischi.

265
.5 Report sulle prestazioni

I report sulle prestazioni (paragrafo 10.3.3.1) forniscono informazioni sulle
prestazioni delle attivit di progetto, ad esempio unanalisi capace di influire sui
processi di gestione dei rischi.
11.6.2 Monitoraggio e controllo dei rischi: Strumenti e tecniche

.1 Rivalutazione dei rischi
Il processo di monitoraggio e controllo dei rischi comporta spesso lidentificazione di
nuovi rischi e la rivalutazione dei rischi mediante luso dei processi descritti nel
presente capitolo e secondo necessit. Le rivalutazioni dei rischi di progetto devono
essere schedulate a cadenza regolare. La gestione dei rischi di progetto deve essere
una voce allordine del giorno delle riunioni sullo stato di avanzamento indette dal
gruppo di progetto. Il numero e il livello di dettaglio adeguati delle ripetizioni
dipendono da come il progetto procede rispetto ai propri obiettivi. Ad esempio, se si
presenta un rischio non previsto nel registro dei rischi o compreso nella watchlist, o se
il suo impatto sugli obiettivi diverso dalle previsioni, la risposta pianificata potrebbe
non essere adeguata. Sar quindi necessario elaborare una pianificazione di risposta
aggiuntiva per tenere il rischio sotto controllo.
.2 Revisioni dei rischi
Durante le revisioni dei rischi si esaminano e documentano lefficacia delle risposte ai
rischi e si affrontano i rischi identificati, le loro cause e lefficacia del processo di
gestione dei rischi.
.3 Scostamento e analisi delle tendenze
Le tendenze nellesecuzione del progetto devono essere riviste mediante i dati sulle
prestazioni. Lanalisi dellEarned Value (paragrafo 7.3.2.4) e altri metodi di analisi
degli scostamenti e delle tendenze del progetto possono essere adottati per il
monitoraggio delle prestazioni complessive del progetto. I risultati ottenuti da queste
analisi potrebbero rivelare una potenziale deviazione, al completamento del progetto,
rispetto agli obiettivi di costo e schedulazione. La deviazione dal piano di baseline
un indicatore del potenziale impatto delle minacce o delle opportunit.
.4 Misurazione della performance tecnica
La misurazione della performance tecnica confronta i risultati di carattere tecnico
ottenuti durante lesecuzione del progetto con la schedulazione dei risultati dello
stesso tipo inserita nel piano di Project Management. La deviazione, come la
dimostrazione di pi o meno funzionalit rispetto a quanto pianificato nella milestone,
consente di prevedere il grado di successo in merito al raggiungimento dellambito del
progetto.
.5 Analisi della riserva
Nel corso dellesecuzione del progetto, si possono verificare dei rischi con impatto
positivo o negativo sulle riserve per contingency di budget e schedulazione (paragrafo
11.5.2.4). Lanalisi della riserva confronta la quantit di riserve per contingency
residue con la quantit di rischi residui in qualsiasi momento nel corso del progetto,
per determinare se la riserva residua pu considerarsi sufficiente.
266

.6 Riunioni sullo stato di avanzamento

La gestione dei rischi di progetto deve essere una voce allordine del giorno delle
riunioni periodiche sullo stato di avanzamento. La trattazione di questa voce pu
richiedere tempi lunghi o molto brevi a seconda dei rischi che sono stati identificati,
della loro priorit e della difficolt della risposta. La gestione dei rischi pi semplice
se ripetuta con maggiore frequenza; inoltre le discussioni frequenti sui rischi rendono
una comunicazione su tale argomento, ma soprattutto sulle minacce, pi semplice e
accurata.
11.6.3 Monitoraggio e controllo dei rischi: Output

Il registro dei rischi contiene gli elementi illustrati di seguito:
Risultati delle rivalutazioni dei rischi, delle revisioni dei rischi e delle analisi
periodiche dei rischi. Questi risultati possono comprendere aggiornamenti alla
probabilit, allimpatto, alla priorit, ai piani di risposta, alla responsabilit e ad
altri elementi del registro dei rischi. I risultati possono anche essere comprensivi
della chiusura dei rischi non pi applicabili.
Risultati effettivi dei rischi del progetto e delle risposte dei rischi che
coadiuvano i project manager nel pianificare il rischio in tutta la struttura
organizzativa e per i progetti futuri. Questi dati completano larchivio della
gestione dei rischi nel progetto, rappresentano un input per il processo Chiudere
il progetto (paragrafo 4.7) e diventano un elemento costitutivo dei documenti
sulla chiusura del progetto.
11
Limplementazione dei piani di contingency o dei workaround porta spesso a una
richiesta di modifica al piano di Project Management al fine di rispondere ai rischi. Le
modifiche richieste vengono preparate e inviate al processo di controllo integrato delle
modifiche (paragrafo 4.6) sotto forma di output ottenuto dal processo di monitoraggio
e controllo dei rischi. Le richieste di modifica approvate vengono poi pubblicate e
diventano gli input per i processi Dirigere e gestire lesecuzione del progetto
(paragrafo 4.4) e di monitoraggio e controllo dei rischi.
.3 Azioni correttive consigliate
Le azioni correttive consigliate comprendono i piani di contingency e i piani di
workaround. Questi ultimi sono le riposte non inserite nel piano originario, ma rese
necessarie per affrontare i rischi emergenti che non sono stati identificati in
precedenza o che sono stati accettati passivamente. I workaround devono essere
adeguatamente documentati e inseriti nei processi Dirigere e gestire lesecuzione del
progetto (paragrafo 4.4) e Monitorare e controllare il lavoro del progetto (paragrafo
4.5). Le azioni correttive consigliate sono gli input al processo di controllo integrato
.4 Azioni preventive consigliate
Le azioni preventive consigliate consentono di conformare il progetto al piano di
Project Management.

267

I sei processi di gestione dei rischi di progetto forniscono informazioni utilizzabili per
progetti futuri; devono quindi essere acquisiti negli asset dei processi organizzativi
(paragrafo 4.1.1.4). I modelli di documento del piano di gestione dei rischi, ivi inclusi
la matrice di probabilit e impatto e il registro dei rischi, possono essere aggiornati al
momento della chiusura del progetto. I rischi vengono documentati e la struttura di
scomposizione dei rischi aggiornata. Le lesson learned derivanti dalle attivit di
gestione dei rischi di progetto possono essere aggiunte alla knowledge base delle
lesson learned della struttura organizzativa. I dati sui costi effettivi e sulle durate delle
attivit di progetto possono essere aggiunti ai database dellorganizzazione. Vengono
inoltre aggiunte le versioni finali del registro dei rischi e del modello dei piani di
gestione dei rischi, le liste di controllo e le strutture di scomposizione delle risorse.
Se le richieste di modifica approvate influiscono sui processi di gestione dei rischi, i
documenti delle componenti corrispondenti vengono rivisti e ripubblicati in
conformit alle modifiche approvate.
268

CAPITOLO 12
Gestione dellapprovvigionamento di
progetto
La gestione dellapprovvigionamento di progetto comprende i processi di acquisizione
di prodotti, servizi o risultati da entit esterne al gruppo di progetto allo scopo di
eseguire il lavoro. Questo capitolo illustra due diverse prospettive di
approvvigionamento. Lorganizzazione pu ricoprire sia il ruolo di acquirente che di
fornitore del prodotto, del servizio o dei risultati oggetti del contratto.
La gestione dellapprovvigionamento di progetto prevede i processi di gestione
del contratto e di controllo delle modifiche che sono necessari per amministrare i
contratti e gli ordini di acquisto emessi da membri autorizzati del gruppo di progetto.
La gestione dellapprovvigionamento di progetto comprende anche le operazioni
di amministrazione di ogni contratto emesso da unorganizzazione esterna
(lacquirente) che sta acquisendo il progetto dalla Performing Organization (il
fornitore) e di amministrazione degli obblighi contrattuali gravanti sul gruppo di
progetto ai sensi del contratto.
La figura 12-1 mostra una visione dinsieme dei processi di gestione
dellapprovvigionamento di progetto, mentre la figura 12-2 illustra un diagramma di
flusso di tali processi e dei relativi input e output e di processi correlati relativi ad altre
aree di conoscenza.
La gestione dellapprovvigionamento di progetto prevede i seguenti processi:
12.1 Pianificare gli acquisti: determinazione degli elementi da acquistare o
acquisire, quando e con quale modalit.
12.2 Pianificare le forniture: documentazione dei requisiti di prodotti, servizi e
risultati oggetto di approvvigionamento e individuazione dei potenziali fornitori.
12.3 Richiesta di risposte dai fornitori: reperimento di informazioni, preventivi,
offerte o proposte in base alle necessit.
12.4 Selezionare i fornitori: valutazione delle offerte, scelta tra i potenziali fornitori
e stipula di un contratto scritto con ciascun fornitore prescelto.
12.5 Amministrazione del contratto: gestione del contratto e delle relazioni tra
acquirente e fornitore, revisione e documentazione delle prestazioni presenti e
passate del fornitore per stabilire eventuali azioni correttive necessarie e gettare
le basi per una collaborazione futura con il fornitore; gestione delle modifiche
relative al contratto e, ove necessario, gestione delle relazioni contrattuali con
lacquirente esterno del progetto.
12.6 Chiusura del contratto: completamento e conclusione di ogni contratto,
compresa la risoluzione di eventuali questioni aperte, e la chiusura di tutti i
contratti relativi al progetto o ad una fase del progetto.
12

269
Capitolo 12 Gestione dellapprovvigionamento di progetto
I processi appena descritti interagiscono tra loro e con i processi appartenenti ad

altre aree di conoscenza. Ogni processo pu richiedere, secondo i requisiti del singolo
progetto, lo sforzo di una o pi persone o gruppi. Ciascun processo si verifica almeno
una volta per ogni progetto e in una o pi fasi di progetto, se presenti. Sebbene i
pratica essi possono sovrapporsi o interagire in modi diversi da quelli descritti. Per
una descrizione dettagliata delle interazioni tra i processi, consultare il capitolo 3.
I processi di gestione dellapprovvigionamento di progetto riguardano i contratti
che sono documenti legali che legano un acquirente e un fornitore. Un contratto un
accordo vincolante per entrambe le parti che obbliga il fornitore a garantire i prodotti,
i servizi o i risultati specificati e obbliga lacquirente a corrispondere un compenso
monetario o di altro valore. Un contratto stabilisce una relazione legale soggetta a
ricorso legale presso un tribunale. Laccordo pu essere semplice o complesso, e
riflette la semplicit o la complessit dei deliverable. Un contratto costituito da
termini e condizioni e pu comprendere altri elementi, quali la proposta del fornitore o
la documentazione di marketing, ed eventualmente altra documentazione di cui
lacquirente si avvale per stabilire che cosa il fornitore deve eseguire o fornire. Il
gruppo di Project Management tenuto a collaborare nelladattare il contratto alle
esigenze specifiche del progetto. In base allarea applicativa, il contratto si pu
chiamare accordo, subappalto od ordine di acquisto. La maggior parte delle
organizzazioni dispone di politiche e procedure documentate che definiscono
chiaramente chi ha la facolt di sottoscrivere e amministrare tali accordi per conto
dellorganizzazione.
Tutti i documenti del progetto sono soggetti a qualche forma di revisione e
approvazione; tuttavia, data la sua natura legalmente vincolante, il contratto viene
sottoposto a un processo di approvazione molto pi ampio. In ogni caso, lobiettivo
principale del processo di revisione e controllo di garantire che le formulazioni del
contratto descrivano i prodotti, i servizi o i risultati in modo da soddisfare le esigenze
identificate per il progetto. In presenza di progetti di vasta portata intrapresi da enti
pubblici, possibile che il processo di revisione comprenda anche una pubblica
revisione dellaccordo.
Il gruppo di Project Management potrebbe ricorrere fin da subito al supporto di
specialisti esperti di contrattualistica, di acquisti e di materie legali. Questo
coinvolgimento pu essere anche imposto dalle politiche dellorganizzazione.
Le varie attivit inserite nel processo di gestione dellapprovvigionamento di
progetto costituiscono il ciclo di vita di un contratto. Se si gestisce il ciclo di vita del
contratto in modo attivo e si presta molta attenzione alla formulazione dei termini e
delle condizioni in esso inclusi, possibile evitare o ridurre alcuni dei rischi
identificabili del progetto. La stipulazione di un contratto per dei prodotti o dei servizi
rappresenta un metodo molto efficace di assegnazione della responsabilit di gestione
o di assunzione dei potenziali rischi.
270

Un progetto complesso pu comportare la gestione contemporanea o in

sequenza di pi contratti o subappalti. In questi casi, il ciclo di vita di ogni contratto
pu terminare nel corso di qualsiasi fase del ciclo di vita del progetto (vedi capitolo 2).
La descrizione della gestione dellapprovvigionamento di progetto viene fatta dal
punto di vista della relazione acquirente-fornitore, la quale si pu articolare su pi
livelli in un qualsiasi progetto e tra le organizzazioni interne ed esterne
allorganizzazione acquirente. In base allarea applicativa, il fornitore pu essere
denominato anche appaltatore, subappaltatore, venditore o fornitore di
servizi. In base alla posizione dellacquirente nel ciclo di acquisizione del progetto,
lacquirente pu essere denominato anche cliente, appaltatore principale,
appaltatore, organizzazione acquirente, agenzia governativa, richiedente di
servizi o compratore. Nel corso del ciclo di vita del contratto il fornitore viene
considerato come offerente, poi come fonte selezionata e infine come fornitore
vincitore dellappalto.
Se lacquisizione non riguarda solo materiali, merce o prodotti comuni, il
fornitore solitamente gestisce il lavoro sotto forma di progetto. In questo caso, si
verificano le seguenti situazioni:
Lacquirente diviene cliente e quindi assume anche il ruolo di principale
stakeholder di progetto per il fornitore.
Il gruppo di Project Management del fornitore si occupa di tutti i processi di
Project Management, non solo di quelli previsti da questa area di conoscenza.
I termini e le condizioni del contratto diventano degli input essenziali per molti
dei processi di gestione del fornitore. Il contratto pu infatti contenere gli input
(ad esempio i deliverable principali, le milestone di rilievo e gli obiettivi di
costo) oppure pu limitare le opzioni a disposizione del gruppo di progetto (ad
esempio nei progetti di design spesso richiesta lapprovazione dallacquirente
sulle decisioni relative al personale).
In questo capitolo si presuppone che lacquirente dei componenti che sono
oggetto del progetto sia interno al gruppo di progetto e che il fornitore sia esterno.
Questa relazione vera sia che la Performing Organization agisca da fornitore di un
progetto per un cliente, sia che la Performing Organization agisca come acquirente da
altri venditori o fornitori di prodotti, servizi, risultati o componenti di un sottoprogetto
utilizzati in un progetto.
Si presuppone inoltre che sia stata concordata, e quindi instaurata, una relazione
contrattuale formale tra lacquirente e il fornitore. Ciononostante, la maggior parte
degli argomenti affrontati in questo capitolo valida anche per gli accordi formali non
contrattuali assunti con altre unit delle organizzazioni cui appartiene il gruppo di
progetto.
12

271
Figura 12-1. Visione dinsieme della gestione dellapprovvigionamento di progetto
272

12
Figura 12-2. Diagramma di flusso dei processi di gestione dellapprovvigionamento di
progetto

273
12.1 Pianificare gli acquisti

Il processo Pianificare gli acquisti identifica quali esigenze di progetto possono essere
meglio soddisfatte mediante lacquisto di prodotti, servizi o risultati allesterno
dellorganizzazione del progetto e quali esigenze di progetto possono invece essere
realizzate dal gruppo di progetto nel corso dellesecuzione del progetto. In questo
processo si valuta se, come, cosa, quanto e quando acquistare.
Quando il progetto ottiene i prodotti, i servizi e i risultati richiesti per
lesecuzione del progetto da un soggetto esterno alla Performing Organization, per
ciascun elemento da acquistare vengono eseguiti i processi che vanno da Pianificare
gli acquisti a Chiusura del contratto.
Il processo Pianificare gli acquisti comporta anche lanalisi dei potenziali
fornitori, in modo particolare se lacquirente desidera esercitare un certo grado di
influenza o di controllo sulle decisioni contrattuali. Particolare importanza dovrebbe
essere data a chi ha la responsabilit di ottenere o mantenere eventuali permessi e
licenze che potrebbero essere richieste dalla legge o da politiche organizzative in
merito allesecuzione del progetto.
La schedulazione del progetto pu influire in misura significativa sul processo
Pianificare gli acquisti. Le decisioni che si prendono quando si sviluppa il piano di
gestione dellapprovvigionamento hanno effetti sulla schedulazione del progetto e
devono essere integrate con lo sviluppo della stessa (paragrafo 6.5), la stima delle
risorse delle attivit (paragrafo 6.3) e alle decisioni di tipo make-or-buy.
Nel processo Pianificare gli acquisti occorre analizzare i rischi legati a ciascuna
decisione make-or-buy e valutare la scelta del tipo di contratto che si intende
utilizzare in unottica di riduzione dei rischi e di loro trasferimento al fornitore.
Figura 12-3. Pianificare gli acquisti: Input, Strumenti e tecniche e Output
274

12.1.1 Pianificare gli acquisti: Input

I fattori ambientali aziendali (paragrafo 4.1.1.3) presi in considerazione comprendono
le condizioni del mercato, la tipologia di prodotti, servizi e risultati disponibili sul
mercato, i possibili fornitori e i termini e le condizioni contrattuali che possibile
ottenere. Se la Performing Organization non dispone di reparti formalmente
responsabili per gli acquisti e i contratti, sar il gruppo di progetto a dover fornire le
risorse e le competenze per eseguire le attivit di approvvigionamento del progetto.
Gli asset dei processi organizzativi (paragrafo 4.1.1.4) forniscono le politiche, le
procedure, le direttive e i sistemi di gestione formali e informali gi esistenti in
azienda di cui occorre tenere conto nello sviluppo del piano di gestione
dellapprovvigionamento e nella selezione del tipo di contratto da adottare. Le
politiche dellorganizzazione pongono spesso dei vincoli alle decisioni di
approvvigionamento. Tali vincoli possono limitare lutilizzo di semplici ordini di
acquisto, richiedere che per tutti gli acquisti superiori a un dato valore si adotti una
forma di contratto pi lunga, imporre la scelta di determinati tipi di contratto, limitare
la possibilit di effettuare delle particolari decisioni make-or-buy e limitare, o
richiedere, fornitori che abbiano determinate caratteristiche o dimensioni.
Le organizzazioni di alcune aree applicative dispongono inoltre di un sistema
prestabilito di fornitori a pi livelli, che vengono selezionati e qualificati per ridurre il
numero di fornitori diretti utilizzati dallorganizzazione e per stabilire una catena di
approvvigionamento estesa.
12

La descrizione dellambito del progetto (paragrafo 5.2.3.1) riporta i limiti, i requisiti, i
vincoli e gli assunti del progetto correlati allambito del progetto. I vincoli sono fattori
specifici che limitano le opzioni di acquirente e fornitore. Uno dei vincoli riscontrati
con maggiore frequenza nei progetti la disponibilit di fondi. Altri esempi possono
essere date di consegna obbligatorie, risorse qualificate disponibili e politiche
organizzative. Gli assunti sono fattori ritenuti veri e possono includere la presunta
disponibilit di pi fornitori o di un fornitore unico. I requisiti che hanno implicazioni
contrattuali e legali possono riguardare questioni di salute, di sicurezza, di prestazione,
ambientali, assicurative, di propriet intellettuale, di pari opportunit di impiego, di
licenze e di permessi.
La descrizione dellambito del progetto fornisce informazioni importanti sulle
esigenze e sulle strategie del progetto analizzate nel corso del processo Pianificare gli
acquisti e contiene lelenco dei deliverable e i criteri di accettazione riguardanti il
progetto e i relativi prodotti, servizi e risultati. Occorre tener conto di tutti quei fattori
che possono dover essere inclusi nella documentazione dellapprovvigionamento e
quindi presentati ai fornitori mediante un contratto.
La parte relativa alla descrizione delle specifiche di prodotto contenuta nella
descrizione dellambito del progetto fornisce informazioni importanti sulle questioni e
sulle problematiche tecniche relative a prodotti, servizi e risultati del progetto prese in
considerazione nel processo Pianificare gli acquisti.

275
La struttura di scomposizione del lavoro (WBS) e il dizionario dei componenti

della WBS presenti nella descrizione dellambito del progetto forniscono un piano
strutturato e dettagliato dellambito del progetto:
.4 WBS
La struttura di scomposizione del lavoro (paragrafo 5.3.3.2) mostra la relazione tra
tutti i componenti del progetto e i deliverable del progetto stesso (paragrafo 4.4).
.5 Dizionario della WBS
Il dizionario della WBS (paragrafo 5.3.3.3) fornisce capitolati dettagliati che
contengono lidentificazione dei deliverable e una descrizione del lavoro contenuto in
ogni componente della WBS e necessario per la produzione di ogni deliverable.
Il piano di Project Management (paragrafo 4.3) fornisce il piano complessivo per la
gestione del progetto e comprende anche i piani ausiliari, quali il piano di gestione
dellambito, il piano di gestione dellapprovvigionamento, il piano di gestione della
qualit e i piani di gestione del contratto, che a loro volta forniscono un orientamento
e una guida per la pianificazione della gestione dellapprovvigionamento. Nel
processo Pianificare gli acquisti, vengono presi in considerazione gli altri output di
pianificazione, in base alla loro disponibilit. Spesso vengono presi in considerazione
anche i seguenti output di pianificazione:
Registro dei rischi (paragrafo 11.2.3.1): contiene le informazioni relative ai
rischi, come ad esempio i rischi identificati, chi responsabile dei rischi e le
risposte ai rischi.
Accordi contrattuali relativi ai rischi (paragrafo 11.5.3.3): questa categoria
comprende gli accordi di stipulazione di assicurazioni, di fornitura di servizi o di
altro tipo, a seconda delle necessit, stilati in modo da chiarire la responsabilit
di ciascuna delle parti nelleventualit che si verifichino specifici rischi.
Requisiti delle risorse delle attivit (paragrafo 6.3.3.1).
Schedulazione di progetto (paragrafo 6.5.3.1).
Stima dei costi delle attivit (paragrafo 7.1.3.1).
Baseline dei costi (paragrafo 7.2.3.1).
12.1.2 Pianificare gli acquisti: Strumenti e tecniche

.1 Analisi make-or-buy
Lanalisi make-or-buy una tecnica di management e una parte del processo
Pianificare gli acquisti che consente di determinare se un particolare prodotto o
servizio pu essere realizzato direttamente dal gruppo di progetto o pu essere
acquistato. Nelle decisioni make-or-buy vengono presi in considerazione gli
eventuali vincoli sul budget del progetto. Se si decide per lacquisto (buy), occorre
poi decidere se acquistare o noleggiare i beni richiesti. Lanalisi include sia i costi
indiretti che quelli diretti. Ad esempio, la parte buy dellanalisi comprende sia i
costi effettivi legati alle spese vive sostenute per lacquisto del prodotto che i costi
indiretti derivanti dalla gestione del processo di acquisto.
276

In unanalisi make-or-buy, la scelta di acquistare riflette sia la prospettiva

dellorganizzazione del gruppo di progetto, sia le esigenze immediate del progetto
stesso. Ad esempio, acquistare unattrezzatura (che sia una gru o un computer)
piuttosto che noleggiarla o prenderla in leasing potrebbe rivelarsi pi o meno
conveniente in unottica prettamente legata al progetto. Tuttavia, se lorganizzazione
del gruppo di progetto ha necessit di un uso frequente dellattrezzatura, la frazione
del costo di acquisto allocata al progetto potrebbe essere inferiore al costo del
noleggio. La distribuzione dei costi pu essere effettuata mediante unanalisi dei
margini.
Anche la strategia a lungo termine dellorganizzazione del gruppo di progetto
una componente dellanalisi make-or-buy. Gli elementi necessari per lesecuzione
del progetto potrebbero non essere disponibili allinterno dellorganizzazione.
Tuttavia, se lorganizzazione ritiene che gli elementi potranno essere richiesti anche in
futuro, pu elaborare i propri piani in previsione della produzione degli elementi
stessi. Queste considerazioni possono portare a una decisione di tipo make a
prescindere dai vincoli e dai requisiti del progetto in corso. In questi caso, i costi
attribuiti al progetto possono essere inferiori rispetto ai costi effettivi, dove la
differenza rappresenta linvestimento operato dallorganizzazione per il futuro.
.2 Parere di esperti
Spesso si ricorre al parere tecnico degli esperti per valutare gli input utilizzati per il
processo e gli output ottenuti. Il parere di esperti del settore acquisti pu anche essere
utile per sviluppare o modificare i criteri da adottare per valutare le offerte o le
proposte presentate dai fornitori. Il parere di esperti in materie legali, come per
esempio un avvocato, pu essere utile per quanto riguarda i termini contrattuali e le
condizioni di approvvigionamento non standard. I pareri e le competenze degli esperti
(comprese le conoscenze di tipo commerciale e tecnico) sono utili sia per curare i
dettagli tecnici di prodotti, servizi o risultati oggetto dellapprovvigionamento, sia per
alcuni aspetti dei processi di gestione dellapprovvigionamento.
12
.3 Tipo di contratto
In funzione del tipo di acquisto, possibile optare per diversi tipi di contratto. Il tipo
di contratto scelto e i termini e le condizioni specifici di tale contratto definiscono il
grado di rischio a cui sono soggetti lacquirente e il fornitore. I contratti rientrano in
genere in una delle categorie descritte di seguito:
Contratto a prezzo prefissato o a importo forfetario: si tratta di un contratto
che prevede un prezzo totale prefissato per un prodotto ben definito. I contratti a
prezzo prefissato possono anche prevedere incentivi per il raggiungimento o il
superamento di determinati obiettivi di progetto, come ad esempio gli obiettivi
di tempo. La forma pi semplice di contratto a prezzo prefissato un ordine di
acquisto per un articolo specificato da consegnare entro la data prestabilita al
prezzo pattuito.

277
Contratto con rimborso spese: si tratta di un contratto che prevede il

pagamento (rimborso) da parte dellacquirente dei costi effettivi sostenuti dal
fornitore, pi un compenso che rappresenta il profitto del fornitore. I costi
vengono in genere classificati come costi diretti o indiretti. I costi diretti sono
rappresentati dalle spese sostenute esclusivamente per il progetto, quali gli
stipendi per il personale a tempo pieno impiegato nel progetto. I costi indiretti,
denominati anche spese generali e di amministrazione, sono i costi che il gruppo
di progetto assegna al progetto come costi legati allo svolgimento delle attivit,
ad esempio gli stipendi per i dirigenti indirettamente coinvolti nel progetto e i
costi per le apparecchiature elettriche utilizzate dallufficio. I costi indiretti
vengono normalmente calcolati come percentuale dei costi diretti. I contratti con
rimborso spese includono in genere delle clausole con incentivi per cui, se il
fornitore soddisfa o supera determinati obiettivi di progetto, ad esempio, di
tempo o di costo totale, riceve dallacquirente un incentivo o un premio. Le tre
categorie pi comuni di contratto con rimborso spese sono CPF, CPFF e CPIF.
a. Contratto a rimborso spese pi quota variabile (CPF) o contratto a
rimborso spese pi percentuale dei costi (CPPC): il fornitore viene
rimborsato delle spese ammissibili sostenute per eseguire il lavoro oggetto
del contratto e riceve in pi un importo calcolato sotto forma di percentuale
dei costi. Il compenso varia al variare del costo effettivo.
b. Contratto a rimborso spese pi quota fissa (CPFF): il fornitore viene
del contratto e riceve in pi un importo fisso calcolato sotto forma di
percentuale dei costi stimati per il progetto. Il compenso fisso non varia al
variare dei costi effettivi, a meno che non cambi lambito del progetto.
c. Contratto a rimborso spese pi incentivo (CPIF): il fornitore viene
del contratto e riceve in pi un importo predeterminato, o incentivo, per il
raggiungimento di determinati obiettivi, stabiliti nel contratto, in termini di
prestazioni. In alcuni contratti CPIF, se i costi finali sono inferiori ai costi
previsti, sia lacquirente sia il fornitore beneficiano dei risparmi nei costi in
base a una formula di condivisione stabilita in precedenza.
Contratto Time and Material (T&M): i contratti T&M sono una tipologia
ibrida di accordo contrattuale che contiene aspetti di un contratto con rimborso
spese e aspetti di un contratto a prezzo prefissato. Come i contratti con rimborso
spese, gli accordi T&M sono aperti: al momento dellassegnazione del contratto,
lacquirente non stabilisce il valore completo dellaccordo e la quantit esatta di
elementi da consegnare. I contratti T&M possono quindi aumentare di valore
come se fossero accordi a rimborso spese. Daltro canto, presentano analogie
anche con gli accordi a prezzo prefissato; ad esempio, se entrambe le parti
concordano sulle tariffe per una specifica categoria di risorse, le tariffe unitarie
vengono predefinite dallacquirente e dal fornitore.
278

La scelta del tipo di contratto da adottare dipende anche dai requisiti che
lacquirente pu imporre al fornitore (ad esempio la versione standard o
personalizzata del prodotto, il reporting delle prestazioni, gli invii dei dati sui costi),
nonch da altre considerazioni di pianificazione, quali il grado di concorrenza del
mercato e il livello di rischio. Inoltre, linclusione di alcuni requisiti potrebbe portare
il fornitore ad incrementare il costo. Unulteriore osservazione legata alleventuale
riacquisto futuro del prodotto o del servizio che il gruppo di progetto sta acquistando.
Laddove tale potenziale sia rilevante, i fornitori potrebbero essere indotti o propensi a
proporre un prezzo inferiore a quello che verrebbe richiesto senza considerare la
potenziale vendita futura. Sebbene questo fenomeno riduca i costi sostenuti dal
progetto, si presentano delle complicazioni legali se lacquirente si impegna ad
effettuare tale acquisto e poi, nella realt, non mantiene i propri impegni.
12.1.3 Pianificare gli acquisti: Output

.1 Piano di gestione dellapprovvigionamento
Il piano di gestione dellapprovvigionamento descrive la modalit con cui vengono
gestiti i processi di approvvigionamento dalla fase di sviluppo della documentazione
relativa allapprovvigionamento fino alla chiusura del contratto. Questo documento
contiene gli elementi seguenti:
Tipi di contratto da utilizzare.
Chi produrr le stime indipendenti e se queste servono come criteri di
valutazione.
Azioni che il gruppo di Project Management pu intraprendere autonomamente,
se la Performing Organization dispone di un ufficio approvvigionamenti,
contrattazione o acquisti.
Documenti di approvvigionamento standardizzati, se necessari.
Gestione di pi fornitori.
Coordinazione dellapprovvigionamento con altri aspetti del progetto, quali la
schedulazione e il reporting delle prestazioni.
Vincoli e assunti che possono influire sugli acquisti pianificati.
Gestione dei tempi di consegna per lacquisto o lacquisizione degli elementi dai
fornitori e coordinamento con lo sviluppo della schedulazione di progetto.
Gestione delle decisioni make-or-buy e loro collegamento ai processi Stima
delle risorse delle attivit e Sviluppo della schedulazione.
Impostazione delle date schedulate in ciascun contratto per i deliverable del
contratto stesso e coordinamento con i processi di sviluppo e controllo della
schedulazione.
Identificazione degli obblighi di esecuzione di contratto o di accordi assicurativi
per ridurre alcune forme di rischio del progetto.
Definizione delle indicazioni da dare ai fornitori per lo sviluppo e la gestione di
una WBS del contratto.
Determinazione della forma e del formato da utilizzare per il capitolato
contrattuale.
Identificazione dei fornitori selezionati a cui ricorrere tra quelli preventivamente
qualificati, se presenti.
Metriche di approvvigionamento da utilizzare per la gestione dei contratti e per
la valutazione dei fornitori.
12

279
Il piano di gestione dellapprovvigionamento pu essere, in base alle esigenze

del progetto, formale o informale, dettagliato o sintetico. Il piano di gestione
dellapprovvigionamento un piano ausiliario del Piano di Project Management
(paragrafo 4.3).
.2 Capitolato contrattuale
Ogni capitolato contrattuale definisce, per gli elementi acquistati, soltanto la porzione
dellambito di progetto coperta dal contratto. Il capitolato (SOW) di ogni contratto
viene sviluppato a partire dalla descrizione dellambito del progetto, dalla struttura di
scomposizione del lavoro di progetto e dal dizionario della WBS. Il capitolato
contrattuale descrive lelemento oggetto dellapprovvigionamento ad un livello di
dettaglio sufficiente da consentire ai potenziali fornitori di determinare se sono in
grado di fornire lelemento in questione. Il livello di dettaglio sufficiente varia in base
alla natura dellelemento, alle esigenze dellacquirente o alla forma di contratto
prevista. Il capitolato contrattuale descrive i prodotti, i servizi o i risultati che devono
essere realizzati dal fornitore. Le informazioni riportate nel capitolato contrattuale
possono essere le specifiche di prodotto, la quantit desiderata, i livelli di qualit, i
dati sulle prestazioni, il periodo di esecuzione, la sede del lavoro e altri requisiti.
Il capitolato contrattuale viene formulato in modo da risultare chiaro, completo e
conciso. Esso contiene una descrizione di eventuali servizi collaterali richiesti, quali il
reporting delle prestazioni o il supporto operativo post-progetto per lelemento
oggetto dellapprovvigionamento. In alcune aree applicative, il capitolato contrattuale
ha requisiti precisi di contenuto e formato. Ogni singolo elemento incluso
nellapprovvigionamento richiede un capitolato contrattuale. Tuttavia, possibile
raggruppare pi prodotti o servizi in un unico articolo da approvvigionare con un solo
capitolato contrattuale.
Questo documento viene rivisto e perfezionato in base alle varie esigenze che
emergono con lavanzare del processo di approvvigionamento fino a che non viene
inserito in un contratto firmato. Ad esempio, un potenziale fornitore pu suggerire un
approccio pi efficiente o un prodotto pi conveniente in termini economici rispetto a
quanto originariamente specificato.
.3 Decisioni make-or-buy
Si tratta delle decisioni documentate di quali prodotti, servizi o risultati del progetto
verranno acquistati e quali verranno realizzati dal gruppo di progetto; ci possono
essere anche decisioni relative alla stipulazione di polizze assicurative o di garanzia di
esecuzione del contratto allo scopo di affrontare alcuni rischi identificati. Il
documento delle decisioni make-or-buy pu essere semplicemente un elenco che
riporti una breve giustificazione della decisione presa. Queste decisioni possono
essere iterative, se le attivit di approvvigionamento successive indicano lesigenza di
un approccio diverso.
Dal processo Pianificare gli acquisti possono derivare modifiche richieste
(paragrafo 4.4) al piano di Project Management, ai relativi piani ausiliari e ad altri
componenti. Le modifiche richieste vengono gestire attraverso il processo di controllo
integrato delle modifiche (paragrafo 4.6).
280

12.2 Pianificare le forniture

Il processo Pianificare le forniture prepara i documenti necessari a supportare i
processi Richiesta di risposte dai fornitori e Selezionare i fornitori.
Figura 12-4. Pianificare le forniture: Input, Strumenti e tecniche e Output
12.2.1 Pianificare le forniture: Input

.1 Piano di gestione dellapprovvigi

Lingua

Benvenuto in Scribd!

PMBOK-2004

Caricato da

Informazioni sul documento

Descrizione:

Data di caricamento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

PMBOK-2004

Caricato da

Descrizione:

Copyright:

Formati disponibili

Titoli correlati

Guida al

un American National Standard

ISBN: 1-930699-71-9 (brossura Italiano)

Project Management Institute, Inc.

2004 Project Management Institute, Inc. Tutti i diritti riservati.

Lo standard per il Project Management di un progetto ..................35

Aree di conoscenza di Project Management ...................................71

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Gestione dei costi di progetto.............................................................. 157

Appendici ......................................................................................... 299

Glossario e indice............................................................................ 343

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

ELENCO TABELLE E FIGURE

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Tabella 3-21. Pianificazione della risposta ai rischi: input e output .................................54

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Figura 5-7. Esempio di struttura di scomposizione del lavoro organizzata per

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

PREFAZIONE ALLA TERZA

Il presente documento sostituisce la Guida al Project Management Body of Knowledge

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Il gruppo di progetto per laggiornamento della Guida al PMBOK 2004 ha aderito

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Tradurre letteratura tecnica in lingue diverse da quella originale non compito

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Ciclo di vita del progetto e Struttura

Obiettivo della Guida al PMBOK

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

La Guida al PMBOK fornisce e promuove inoltre un lessico comune da

Destinatari della Guida al PMBOK

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Che cos un progetto?

Un progetto uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un

lopportunit o finestra di mercato generalmente temporanea; molti progetti

Prodotti, servizi o risultati unici

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Lo sviluppo di un impianto chimico inizia con lingegneria di processo per

Progetti e lavoro operativo a confronto

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Gli obiettivi dei progetti e delle funzioni operative sono di natura

Progetti e pianificazione strategica

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Che cos il Project Management?

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

La struttura della Guida al PMBOK

Sezione I: Il contesto del Project Management

Sezione II: Lo standard per il Project Management di un progetto

Sezione III: Le aree di conoscenza di Project Management

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Il capitolo 6, Gestione dei tempi di progetto, descrive i processi necessari ad

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Project Management Body of Knowledge

Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione

Figura 1-2. Aree di esperienza di cui necessita il gruppo di Project Management.

Conoscenza degli standard, dei regolamenti e delle aree