Pmi Pmbok - A Guide To The Project Management Body of Knowledge (3rd Edition, 2004) Ita PDF

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 19073-
3299 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.48—1984).
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 dell’integrazione 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 i
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 dell’approvvigionamento 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 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
ELENCO TABELLE E FIGURE
Figura 1-1. Visione d’insieme 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 dell’ambito 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 dell’ambito: input e output...................................................... 48
Tabella 3-5. Definizione dell’ambito: 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
®
2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 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 l’esecuzione del progetto: input e output......................56
Tabella 3-25. Effettuare l’assicurazione 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 dell’ambito: input e output ................................................................62
Tabella 3-34. Controllo dell’ambito: 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 d’insieme della gestione dell’integrazione 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 d’insieme 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 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
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 d’insieme 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 d’insieme 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 sull’andamento di progetto in forma di
grafico.......................................................................................................................... 174
Figura 8-1. Visione d’insieme 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 d’insieme 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
®
2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA v
Sommario
Figura 10-1. Visione d’insieme 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 d’insieme 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 dell’albero 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 d’insieme della gestione dell’approvvigionamento 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 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
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 all’apporto ricevuto e all’ampliamento 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 l’approfondimento 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 dell’integrazione e comunicarne con maggiore efficacia
l’importanza per il progetto.
• Ampliare la trattazione del gruppo di processi di avvio al fine di descrivere più
accuratamente la parte iniziale del progetto e l’avvio 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 l’origine 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 l’opportunità di modificare termini e frasi caratterizzati da connotazioni
culturali negative.
• Ampliare l’indice e il glossario.
• Correggere errori riscontrati nel documento precedente.
®
2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA vii
Il gruppo di progetto per l’aggiornamento 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 un’etichetta 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. E’stata ulteriormente sottolineata. l’importanza 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
l’integrazione 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 dell’ambito 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 all’integrazione dei processi.
13. È stata aggiunta un’introduzione 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 l’aggiornamento della Guida al PMBOK®
®
viii 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
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.
®
2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA ix
Sezione I
Il contesto del Project
Management
Capitolo 1 Introduzione
Capitolo 2 Ciclo di vita del progetto e Struttura

organizzativa
1
CAPITOLO 1
Introduzione
Il Project Management Body of Knowledge è la summa della conoscenza nell’ambito
della professione del Project Management. Come avviene in altre professioni (ad
esempio in giurisprudenza, medicina e ragioneria), l’insieme 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 d’insieme
dell’intera 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®
L’obiettivo 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 d’insieme
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.
®
2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 3
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.);
• l’accreditamento di programmi educativi nel Project Management.
Come riferimento fondamentale, lo standard non si qualifica come esaustivo né
come onnicomprensivo. L’appendice D è dedicata alle aree applicative di competenza,
mentre l’appendice 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 l’intera 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.
L’assenza di consenso implica la presenza di variazioni nell’ambito della professione
che investono il come, il quando, il dove e persino il chi, all’interno 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 dell’analisi del Project Management.
®
4 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
1.2 Che cos’è un progetto? 1
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
L’aggettivo “temporaneo” implica che ogni progetto ha un inizio e una fine definiti.
La fine si raggiunge quando gli obiettivi del progetto sono stati raggiunti o quando
appare evidente che sarà impossibile raggiungerli, o ancora quando il progetto non è
più necessario e viene chiuso. 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:
• l’opportunità 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.
.2 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à.
L’unicità è un’importante 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
L’elaborazione 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, l’ambito 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. L’elaborazione
progressiva non dovrebbe essere confusa con il cambiamento non controllato
dell’ambito (sezione 5.5).
L’elaborazione progressiva delle specifiche di prodotto deve essere attentamente
coordinata con un’appropriata definizione dell’ambito del progetto, specie nel caso in
cui il progetto venga sviluppato su commessa. Se correttamente definito, l’ambito 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 l’ambito del progetto sarà esaminata ulteriormente
nell’introduzione al capitolo 5.
I due esempi seguenti illustrano l’uso dell’elaborazione progressiva in due
diverse aree applicative.
• Lo sviluppo di un impianto chimico inizia con l’ingegneria 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 l’accesso
a cibo e acqua per 500 residenti a reddito basso della collettività X.” La fase
successiva di elaborazione progressiva potrebbe concentrarsi esclusivamente
sull’incremento della produzione e della commercializzazione agricola, mentre
la fornitura d’acqua corrente potrebbe essere ritenuta una priorità secondaria
destinata ad essere avviata dopo la fase agricola.
1.2.2 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, l’obiettivo di una funzione operativa continuativa è
1
un’azione 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 d’impresa. 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 l’attuazione 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
all’introduzione 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 è l’applicazione di conoscenze, skill, strumenti e tecniche alle
attività di progetto al fine di soddisfarne i requisiti. Il Project Management viene
espletato mediante l’applicazione e l’integrazione 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.
Nell’ambito 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
nell’ambito 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 nell’ambito del Project Management
sono iterativi a causa dell’esistenza e della necessità dell’elaborazione progressiva in
un progetto per l’intera 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 l’applicazione 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® 1
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
d’insieme dell’intera Guida al PMBOK®.
Il capitolo 2, Ciclo di vita del progetto e Struttura organizzativa, descrive
l’ambiente 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. L’introduzione 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 dell’integrazione di progetto, descrive i processi e le
attività che integrano elementi diversi del Project Management, i quali vengono
identificati, definiti, combinati, unificati e coordinati nell’ambito dei gruppi di
processi di Project Management. Comprende i seguenti processi di Project
Management: Sviluppare il Project Charter, Sviluppare la descrizione preliminare
dell’ambito del progetto, Sviluppare il piano di Project Management, Dirigere e
gestire l’esecuzione del progetto, Monitorare e controllare il lavoro del progetto,
Controllo integrato delle modifiche e i processi di chiusura del progetto.
Il capitolo 5, Gestione dell’ambito 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 dell’ambito, Definizione dell’ambito, Creare la WBS, Verifica
dell’ambito e Controllo dell’ambito.
®
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 l’assicurazione 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 dell’approvvigionamento 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.
®
1
Figura 1-1. Visione d’insieme delle aree di conoscenza di Project Management e dei
processi di Project Management
®
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, l’analisi dei percorsi
critici e il metodo dell’Earned Value. La comprensione e l’applicazione 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 dell’efficace
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 all’ambito 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).
®
1
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 dell’inventario, 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 l’ingegneria 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. L’Organizzazione Internazionale per la
Standardizzazione (ISO) attua una differenziazione tra standard e regolamenti come
illustrato di seguito (Guida ISO/IES 2: 1996)2:
®
• Uno standard è un “documento stabilito tramite consenso diffuso e approvato da

un ente riconosciuto che, ai fini dell’utilizzo 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.
L’area 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.
• L’obbligo 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 l’Appendice 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 fisico-
ambientale.
• 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
l’ecologia e con la geografia fisica del luogo che potrebbero incidere sul
progetto o a sua volta subirne l’influsso.
®
1.5.4 Conoscenza e skill in materia di general management 1
Il general management comprende la pianificazione, la struttura organizzativa, la
gestione delle risorse, l’esecuzione e il controllo delle funzioni operative di
un’impresa. 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 nell’ambito 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à d’influenzare 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 l’altra parte per individuare
un terreno comune o raggiungere un accordo.
• Risoluzione dei problemi: l’unione della definizione dei problemi,
dell’identificazione e dell’analisi delle alternative e l’assunzione di decisioni.
®
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 all’ambito dei progetti distinti che costituiscono il programma. Ad
esempio:
• il programma di un nuovo modello di automobile può essere suddiviso in
progetti per l’elaborazione 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 dell’elettronica 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 un’attività ricorrente mirata a ottenere un
supporto finanziario che spesso include una serie di progetti distinti, come
un’asta 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. L’assegnazione 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.
®
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 un’attenta disamina dei progetti e dei programmi candidati ad esservi
1
inclusi e tramite la pronta esclusione di quei progetti che non soddisfano gli obiettivi
strategici del portfolio stesso. Altri obiettivi comprendono l’individuazione 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 nell’ambito 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) è un’unità organizzativa che consente di
centralizzare e coordinare la gestione dei progetti sotto il suo raggio d’azione. 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, sull’assegnazione delle
priorità e sull’esecuzione 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 dell’assunzione di decisioni durante la
fase di avvio di ciascun progetto; può inoltre disporre dell’autorità per consigliare
investimenti o può porre fine ai progetti per garantire l’uniformità 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.
®
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 nell’ambito 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 dell’ambito 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 l’uso delle
risorse condivise della struttura organizzativa su tutti i progetti.
• Il project manager gestisce l’ambito, la schedulazione, il costo e la qualità dei
prodotti dei Work Package; il PMO gestisce il rischio complessivo,
l’opportunità 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.
®
2
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 all’interno 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 l’inizio e la fine del progetto
stesso. Ad esempio, nel caso in cui una struttura organizzativa abbia identificato
un’opportunità 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 l’esito 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.
®
Capitolo 2 − Ciclo di vita del progetto e Organizzazione
La transizione da una fase all’altra nell’ambito 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 l’accuratezza, 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 dell’approvazione 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 all’utilizzo 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 dell’architetto);
• 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 dell’implementazione 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.
®
2
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 all’inizio del progetto. In genere la certezza di
raggiungere il completamento si intensifica progressivamente con
l’avanzamento del progetto
• L’abilità degli stakeholder di influenzare le caratteristiche e il costo finali del
prodotto del progetto è massima all’inizio 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 l’avanzamento del progetto.
Figura 2-2. Influenza dei stakeholder nel corso del tempo
®
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 l’architettura 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 dell’edificio
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 l’approvazione 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 l’obiettivo 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 l’esecuzione 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 un’analisi 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 un’azienda 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 l’analisi 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.
®
Il completamento formale della fase non include anche l’autorizzazione
all’avvio 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 nell’ambito della fase in questione, come illustrato nella
figura 2-3. È quindi possibile eseguire un’analisi di fine fase con l’esplicito intento di
2
ottenere l’autorizzazione 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 all’interno 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
l’analisi 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 l’approvazione 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.
L’effetto 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.
®
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 l’ideazione, 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 dell’esecuzione 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
l’influenza 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.
®
2
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 l’identificazione 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. L’insuccesso nell’identificare uno stakeholder chiave può causare
problemi seri al progetto. Ad esempio, in un progetto di aggiornamento del software
per l’anno 2000 (Y2K), il ritardato riconoscimento del fatto che l’ufficio legale fosse
uno stakeholder importante ha causato l’aggiunta 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 l’ambiente. 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. L’interesse degli
stakeholder negativi verrebbe invece supportato con un aumento dei vincoli
sull’avanzamento 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.
®
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 l’acquisto. In
alcune aree applicative, i termini cliente e utente sono sinonimi, mentre in altre
per cliente si intende l’entità che effettua l’acquisto 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 dell’esecuzione 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
l’acquisto o l’uso 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 sull’esito
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. L’individuazione 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 un’impresa 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 l’architetto 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 un’azienda 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.
®
• Il titolare di un progetto di sviluppo immobiliare avrà come interesse principale
il rispetto dei tempi di consegna, mentre l’ente pubblico locale competente avrà
come obiettivo primario la massimizzazione degli introiti fiscali, un gruppo
ambientalista la riduzione al minimo dell’impatto ambientale e i residenti della
zona, a loro volta, il trasferimento del progetto in un altro luogo.
2
2.3 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 all’influenza 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 anch’essi 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 l’autorità.
• Etica del lavoro e orario di lavoro.
®
La cultura delle strutture organizzative ha spesso un’influenza 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 l’approvazione 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. L’ufficio tecnico può essere
ulteriormente suddiviso in organizzazioni funzionali, come i settori meccanico ed
elettrico, che coadiuvano l’attività commerciale della struttura organizzativa più
grande,. Le organizzazioni funzionali spesso hanno progetti, ma l’ambito di questi
progetti è in genere limitato alla portata della funzione. L’ufficio tecnico, appartenente
a una struttura organizzativa funzionale, esegue il proprio lavoro di progetto in modo
del tutto indipendente dalla produzione o dall’ufficio 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
dell’ufficio 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 dell’ufficio tecnico.
®
2
Figura 2-7. Struttura organizzativa funzionale
Figura 2-8. Organizzazione per progetti

All’estremo opposto dello spettro si trova l’organizzazione 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.
®
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. L’organizzazione a matrice equilibrata mentre
riconosce la necessità di ricorrere a un project manager, non gli fornisce l’autorità
assoluta sul progetto e sul relativo finanziamento (figura 2-6).
®
2
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 un’organizzazione 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 un’organizzazione 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.
®
2.3.4 Ruolo del PMO nelle strutture organizzative

Sono numerose le strutture organizzative che si rendono conto dei vantaggi ottenuti
dallo sviluppo e dall’implementazione 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
l’organizzazione 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 all’interno di un’organizzazione 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 quest’ultimo 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 all’interno 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.
®
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 2
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 tutt’uno.
Il piano di Project Management descrive come sarà usato il sistema di Project
Management. Il contenuto del sistema di Project Management varia in base all’area
applicativa, all’influenza della struttura organizzativa, alla complessità del progetto e
alla disponibilità di sistemi esistenti. L’influenza della struttura organizzativa consente
di plasmare il sistema ai fini dell’esecuzione dei progetti all’interno 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.
®
Sezione II
Lo standard per il Project
Management di un progetto
Capitolo 3 Processi di Project Management per

un progetto
CAPITOLO 3 3
Processi di Project Management per un

progetto
Il Project Management è l’applicazione 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, all’interno 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 l’applicazione 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.
®
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 l’uno all’altro dal fatto che si eseguono per uno scopo
integrato. L’obiettivo è 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 l’ambito, 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 l’area 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
l’ambito del progetto senza una conoscenza di base delle modalità di creazione
del prodotto specificato.
Il Project Management è un’attività 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 dell’ambito 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
®
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
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 l’applicazione delle
conoscenze e degli skill di Project Management nel corso del progetto. Inoltre,
l’applicazione 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 l’obiettivo di progetto desiderato.
Il ciclo “plan-do-check-act” (ideato da Shewhart e modificato da Deming,
nell’ASQ Handbook, pag. 13–14, American Society for Quality, 1999) rappresenta un
concetto fondamentale nell’ambito dell’interazione tra i processi di Project
Management. Questo ciclo è legato dai risultati: il risultato uscente da una parte del
ciclo diventa l’input per un’altra. Vedere la figura 3-1.
Figura 3-1. Ciclo “Plan-Do-Check-Act”
®
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 all’interno dei gruppi di processi e tra un gruppo e
l’altro. 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 l’inizio dei cicli, mentre il
gruppo di processi di chiusura ne rappresenta la fine. Il carattere integrativo del
Project Management richiede l’interazione 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 dall’area 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 all’interno
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 all’interno 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.
®
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 l’effetto di un processo diventa l’input 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 l’attuazione di azioni preventive o correttive per
la realizzazione conforme al piano di Project Management del progetto o per
l’eventuale 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 dell’idea,
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 dell’ambito stabliti per il progetto.
• Gruppo di processi di esecuzione: integra persone e altre risorse per
l’attuazione del piano di Project Management del progetto.
• Gruppo di processi di monitoraggio e controllo: misura e monitora
regolarmente l’avanzamento 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 l’accettazione del prodotto, del
servizio o del risultato e consente la chiusura corretta del progetto o di una fase
del progetto.
®
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
®
3.2.1 Gruppo di processi di avvio
Il gruppo di processi di avvio comprende i processi che facilitano l’autorizzazione
formale a iniziare un nuovo progetto o una nuova fase di progetto. I processi di avvio
sono di solito esterni all’area 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 3
input iniziali. Ad esempio, prima dell’inizio 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 dell’ambito del progetto, dei deliverable, della durata del progetto e una
previsione delle risorse per l’analisi dell’investimento 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 all’interno 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 dell’ambito del progetto.
Figura 3-5. Confini del progetto

Nel corso del processo di avvio vengono ulteriormente specificate la descrizione
iniziale dell’ambito 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
l’autorizzazione ufficiale. Sebbene il gruppo di Project Management possa redigere il
Project Charter, l’approvazione e l’assegnazione di fondi vengono gestiti all’esterno
dei confini del progetto.
®
All’interno del gruppo di processi di avvio, progetti particolarmente estesi o

complessi possono essere suddivisi in fasi. La revisione dei processi di avvio all’inizio
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
un’altra verifica e un ulteriore sviluppo dell’ambito 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 l’esigenza 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 l’output ne definisce lo scopo, stabilisce
gli obiettivi e autorizza il project manager ad avviare il progetto.
Figura 3-6. Gruppo di processi di avvio
®
Il gruppo di processi di avvio include i processi di Project Management descritti
di seguito.
.1 Sviluppare il Project Charter
Questo processo riguarda principalmente l’autorizzazione 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
3
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 dell’ambito 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 dell’ambito ad alto livello. Nei progetti multi-
fase, tale processo convalida o perfeziona l’ambito del progetto per ogni fase.
Tabella 3-2. Sviluppare la descrizione preliminare dell’ambito di progetto: input e output
®
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 dell’ambito 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 l’incremento
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 un’attenzione
particolare per tutti gli aspetti legati all’ambito, alla tecnologia, ai rischi e ai costi. Gli
aggiornamenti causati dai cambiamenti approvati durante l’esecuzione 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 dell’ambito del progetto. Gli
aggiornamenti possono essere limitati alle attività e alle questioni associate
all’esecuzione 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 dell’ambiente 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.
®
3
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.
®
.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 dell’ambito
Processo di creazione del piano di gestione dell’ambito del progetto che documenta
come l’ambito del progetto verrà definito, verificato e controllato e come creare e
definire la struttura di scomposizione del lavoro (WBS).
Tabella 3-4. Pianificazione dell’ambito: input e output
®
.3 Definizione dell’ambito
Processo di sviluppo della descrizione dell’ambito del progetto dettagliata da
utilizzare come base per le decisioni future sul progetto.
Tabella 3-5. Definizione dell’ambito: 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
®
.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
®
.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 un’approssimazione 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
®
.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
®
.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 un’ulteriore 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
®
.18 Analisi quantitativa del rischio

Processo di analisi numerica dell’effetto 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
®
.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 all’integrazione e all’esecuzione delle attività del progetto
come stabilito nel piano di Project Management. Questo gruppo di processi si occupa
anche dell’ambito definito nella descrizione dell’ambito del progetto e
dell’implementazione delle modifiche approvate (vedere figura 3-8).
Figura 3-8. Gruppo di processi di esecuzione
®
I normali scostamenti nell’esecuzione 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 un’attività di analisi. Il risultato
dell’analisi 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 l’esecuzione del progetto
Processo che consente di guidare le varie interfacce di tipo tecnico e organizzativo
presenti nel progetto per l’esecuzione 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 nell’ambito dell’esecuzione del progetto e date in input al processo
di reporting delle prestazioni.
Tabella 3-24. Dirigere e gestire l’esecuzione del progetto: input e output
.2 Effettuare l’assicurazione 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 l’assicurazione qualità: input e output
®
.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 dell’interazione 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
®
.6 Richiesta di risposte dai fornitori

Processo che consente di ottenere informazioni, preventivi, offerte d’appalto, 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
®
3.2.4 Gruppo di processi di monitoraggio e controllo
Il gruppo di processi di monitoraggio e controllo consiste nei processi eseguiti per
osservare l’esecuzione del progetto in modo da poter identificare tempestivamente i
potenziali problemi e adottare le adeguate misure correttive, ove necessarie, al fine di
controllare l’esecuzione 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
3
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 un’attenzione
particolare. Il gruppo di processi di monitoraggio e controllo non solo consente di
monitorare e controllare il lavoro svolto all’interno 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 un’attività 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.
®
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.
®
.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 dell’avanzamento del progetto ed eventuali previsioni. I report sulle
3
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, dall’avvio alla chiusura.
Tabella 3-32. Controllo integrato delle modifiche: input e output
®
.3 Verifica dell’ambito
Processo che consente di formalizzare l’accettazione dei deliverable di progetto
completati.
Tabella 3-33. Verifica dell’ambito: input e output
.4 Controllo dell’ambito
Processo di controllo delle modifiche apportate all’ambito del progetto.
Tabella 3-34. Controllo dell’ambito: 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
®
.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
®
.9 Reporting delle prestazioni

Processo di raccolta e distribuzione delle informazioni sulle prestazioni che
comprende rapporti sullo stato del progetto, misurazioni dell’avanzamento 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
®
.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
dell’efficacia 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 l’acquirente esterno al progetto.
Tabella 3-42. Amministrazione del contratto: input e output
®
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
®
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.
3
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. L’output di un processo diviene in genere l’input 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 dell’ambito 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 l’intero 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 all’interno di una singola fase di progetto
che su più fasi di progetto.
®
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 l’accettazione 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 all’interno 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.
®
3
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 dell’ambito, 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 quest’ultima 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 l’ambito.
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 dell’attività. 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.
®
Tabella 3-45. Collegamento dei processi di Project Management ai gruppi di processi di

Project Management e alle aree di conoscenza
®
Parte III
Aree di conoscenza di Project
Management
Parte III Introduzione
Capitolo 4 Gestione dell’integrazione 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 dell’approvvigionamento 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
®
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.
®
Figura III-2. Tre principali documenti di progetto e la loro relazione con i rispettivi
componenti
®
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.
®
CAPITOLO 4
4
Gestione dell’integrazione 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.
®
Capitolo 4 − Gestione dell’integrazione 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 all’interno delle procedure definite
dall'organizzazione. La figura 4-1 fornisce una visione d’insieme 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.
®
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.
®
®
Figura 4-1. Visione d’insieme della gestione dell’integrazione di progetto
Figura 4-2. Diagramma di flusso dei processi di gestione dell'integrazione di progetto.
®
4.1 Sviluppare il Project Charter

Il Project Charter è il documento che autorizza formalmente il progetto. Esso fornisce
al project manager l’autorità necessaria per impiegare le risorse dell’organizzazione ai
fini delle attività di progetto. Quanto prima possibile nell’avvio 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, un’organizzazione 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 l’educazione 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.
L’avvio 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 un’analisi
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:
®
• 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.
4
• 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:
®
• 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.
.3 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).
®
.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
4
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.
®
• 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.
4.1.2 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.
®
.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
4
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 Sviluppare il Project Charter: Output

.1 Project Charter
Per la descrizione, consultare l'introduzione al paragrafo 4.1.
4.2 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.
®
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.

Strumenti e tecniche
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.
®
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.
Si ricorre al parere di esperti per qualsiasi dettaglio tecnico e gestionale da includere
4
nella descrizione preliminare dell'ambito del progetto.

Output
.1 Descrizione preliminare dell'ambito del progetto
Per la descrizione, consultare l'introduzione al paragrafo 4.2.
4.3 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.
®
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 dell’ingaggio 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 dell’approvvigionamento (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

.2 Processi di Project Management
Per la descrizione, consultare i capitoli da 5 a 12.
®
4.3.2 Sviluppare il piano di Project Management: Strumenti e tecniche

4
di Project Management nello sviluppo e nel controllo delle modifiche da apportare al
piano di Project Management.
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 all’autorizzazione 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.
Si ricorre al parere di esperti per sviluppare i dettagli tecnici e gestionali da inserire
nel piano di Project Management.
®
4.3.3 Sviluppare il piano di Project Management: Output

.1 Piano di Project Management
4.4 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.
®
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à.
4
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

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

La metodologia di Project Management definisce un processo che coadiuva il gruppo
di progetto nell'esecuzione del piano di Project Management.
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.
®
.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:
4
• Informazioni sull’avanzamento 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.
4.5 Monitorare e controllare il lavoro del progetto

Il processo Monitorare e controllare il lavoro del progetto consente di monitorare i
processi del progetto associati all’avvio, 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.
®
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

.3 Richieste di modifica rifiutate
Le richieste di modifica rifiutate comprendono le richieste di modifica, la relativa
documentazione di supporto e l’adeguamento 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
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.
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.
4 Parere di esperti
Il parere di esperti è utilizzato dal gruppo di Project Management di monitorare e
controllare il lavoro del progetto.
®
4.5.3 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.
4
.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.
4.6 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.
®
• Controllo e aggiornamento di ambito, costo, budget, schedulazione e requisiti di

qualità in base alle modifiche approvate, mediante il coordinamento delle
modifiche all’interno 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 l’opportunità 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.
®
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 4
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

.7 Deliverable
®
4.6.2 Controllo integrato delle modifiche: Strumenti e tecniche

di Project Management nell'implementazione del Controllo integrato delle modifiche
del progetto.
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.
Il gruppo di Project Management si avvale di quegli stakeholder che rappresentano il
parere di esperti all’interno 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

.2 Richieste di modifica rifiutate
.3 Piano di Project Management (aggiornamenti)
.4 Descrizione dell'ambito del progetto (aggiornamenti)
.6 Azioni preventive approvate
.7 Correzione dei difetti approvata
.9 Deliverable
Descritti nel paragrafo 4.4.3.1 e approvati mediante il processo Controllo integrato
delle modifiche (paragrafo 4.6).
®
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 all’interno 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
4
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
®
4.7.1 Chiudere il progetto: Input

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

di Project Management nell'esecuzione delle procedure amministrative e di chiusura
del contratto del progetto.
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.
Si ricorre al parere di esperti per lo sviluppo e l'esecuzione delle procedure
amministrative e di chiusura del contratto.
4.7.3 Chiudere il progetto: Output

.1 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:
®
• 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. 4
.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 all’interno 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.
®
CAPITOLO 5
5
Gestione dell'ambito del progetto
La gestione dell’ambito 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 l’impegno 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.
®
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 dell’ambito del prodotto.
®
5
Figura 5-1. Visione d’insieme della gestione dell'ambito del progetto
®
Figura 5-2. Diagramma di flusso dei processi di gestione dell'ambito del progetto
®
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 è 5
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

I fattori ambientali aziendali comprendono elementi quali la cultura
dell’organizzazione, 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.
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.
®
• 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
5.1.2 Pianificazione dell'ambito: Strumenti e tecniche

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 Pianificazione dell'ambito: Output

.1 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.
®
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 5
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

.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.
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.
Le richieste di modifica approvate (paragrafo 4.4) possono comportare modifiche
all’ambito 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.
®
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.
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 Definizione dell'ambito Output

.1 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:
®
• 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
5
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.
®
• 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 d’aiuto agli stakeholder
nel visualizzare i deliverable (paragrafo 4.4.3.1) del progetto.
®
5
Figura 5-5. Creare la WBS: Input, Strumenti e tecniche e Output
5.3.1 Creare la WBS: Input

5.3.2 Creare la WBS: Strumenti e tecniche

.1 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 all’interno di
un’organizzazione 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.
®
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.
®
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
5
del progetto. Tale analisi necessita inoltre l’utilizzo 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.
®
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
®
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
5
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.
®
.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.
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

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.
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.
®
.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 Verifica dell'ambito: Strumenti e tecniche

.1 Ispezione 5
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.
5.4.3 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.
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.
5.5 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.
®
Figura 5-10. Controllo dell'ambito: Input, Strumenti e tecniche e Output
5.5.1 Controllo dell'ambito: Input

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.
.5 Report sulle prestazioni
I report sulle prestazioni forniscono informazioni sulle prestazioni del lavoro di
progetto, come sui deliverable provvisori che sono stati completati.
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.
®
5.5.2 Controllo dell'ambito: Strumenti e tecniche
.1 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
5
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.
®
.4 Baseline dell'ambito (aggiornamento)

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
Un’azione 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.
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.
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.
®
CAPITOLO 6
Gestione dei tempi di progetto 6

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.
®
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.
®
6
Figura 6-1. Visione d’insieme della gestione dei tempi di progetto
®
Figura 6-2. Diagramma di flusso dei processi di gestione dei tempi di progetto
®
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

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.
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.
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.
®
.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.
Il dizionario della WBS (paragrafo 5.3.3.3) è uno degli input principali per la
definizione delle attività schedulate.
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.
®
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 6
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 Definire le attività: Output

.1 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.
®
.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
6.2 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
®
6.2.1 Sequenzializzazione delle attività: Input
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 nell’elenco delle attività, la descrizione delle specifiche di prodotto è
in generale sottoposta a revisione al fine di essere quanto più precisa possibile.
Per la descrizione, consultare il paragrafo 6.1.3.1. 6
.4 Elenco delle milestone
.5 Richiesta di modifica approvata
Figura 6-5. Metodo del diagramma di precedenza
®
6.2.2 Sequenzializzazione delle attività: Strumenti e tecniche

.1 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 è fine-
inizio. Le relazioni inizio-fine vengono invece utilizzate molto raramente.
Figura 6-6: metodo del diagramma a frecce
®
.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 l’ADM. 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
6
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”.
®
• 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).
.5 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
®
6.2.3 Sequenzializzazione delle attività: Output
.1 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.
6
.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.
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).
6.3 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
®
• 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

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).
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.
L'elenco delle attività (paragrafo 6.1.3.1) identifica le attività schedulate per le risorse
incluse nella stima.
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à.
®
.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 dall’inizio, conoscono a fondo il progetto.
Il piano di gestione della schedulazione è un componente del piano di Project
Management (paragrafo 4.3) utilizzato nella stima delle risorse delle attività. 6
6.3.2 Stima delle risorse delle attività: Strumenti e tecniche
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.
®
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.
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à.
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).
®
6.4 Stima della durata delle attività
Il processo di stima della durata delle attività schedulate utilizza informazioni relative
all’ambito 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 dell’ingegnerizzazione e il
disegno del progetto, ulteriori dati dettagliati e precisi vengono resi disponibili, e
l’accuratezza della durata delle stime migliora. Pertanto, si assume che la durata della
stima è progressivamente più accurata e di migliore qualità. 6
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
®
6.4.1 Stima della durata delle attività: Input

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 un’agenzia
governativa richiede per rispondere a certi tipi di richiesta).
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).
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.
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 all’incremento percentuale
delle risorse assegnate.
®
.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.
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). 6
• 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 dell’adeguamento 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

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.
®
.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 Stima della durata delle attività: Output

.1 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 l’attività 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 un’elevata probabilità -
85% - che l’attività schedulata necessiterà tre settimane o meno.
®
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.
6.5 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
6
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

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).
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:
®
• Le date imposte d’inizio o di fine delle attività possono essere utilizzate per
limitare l’occorrenza dell’inizio 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 l’”inizio
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à
all’aperto, 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 l’inserimento di
milestone con date imposte può fornire un'adeguata interfaccia di schedulazione.
.5 Reticoli di schedulazione del progetto
.7 Calendario delle risorse
.8 Stime della durata dell'attività
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.
®
6.5.2 Sviluppo della schedulazione: Strumenti e tecniche
.1 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
6
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 un’alternativa
percorribile e spesso produce un incremento dei costi
®
• 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 l’esecuzione 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 all’accorciamento della schedulazione
di progetto.
.4 Analisi di scenari ipotetici (“what-if”)
Questa è un’analisi 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 l’impatto 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.
®
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 6
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 d’inizio 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.
®

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.
®
6.5.3 Sviluppo della schedulazione: Output
.1 Schedulazione di progetto
La schedulazione di progetto comprende almeno una data d’inizio 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 d’inizio 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
6
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.
®
Figura 6-10. Schedulazione di progetto: esempi di grafici
®
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 d’inizio effettiva, la durata effettiva e la data di fine effettiva delle
attività schedulate completate, la data d’inizio effettiva, la durata residua e la data di
fine attuale delle attività schedulate con il lavoro in fase di esecuzione e la data
d’inizio 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
6
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
all’area 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 (“worst-
case”) 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.
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.
®
.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.
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).
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.
6.6 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
®
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 6
baseline di misurazione delle prestazioni.
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.
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 l’autorizzazione alle
modifiche. Il sistema di controllo delle modifiche alla schedulazione opera come parte
del processo di controllo integrato delle modifiche (paragrafo 4.6).
®
.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.
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 l’implementazione di azioni correttive in caso di ritardi. Lo
scostamento del Total Float costituisce un ulteriore componente essenziale per la
valutazione dell’andamento 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 Controllo della schedulazione: Output

.1 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.
®
.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 6
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.
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
Un’azione 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 l’accelerazione dei tempi, che include azioni speciali intraprese al
fine di assicurare che il completamento di un’attività 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. L’analisi 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.
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.
®
.7 Elenco delle attività (aggiornamenti)

Descritta nel paragrafo 6.1.3.1.
Descritta nel paragrafo 6.1.3.2.
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.
®
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 7
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 un’approssimazione 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 l’effetto 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.
®
Capitolo 7 − Gestione dei costi di progetto
In molte aree applicative, la previsione e l’analisi 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, l’ordine è 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 l’ambito 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.
®
• 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.
L’attività di pianificazione della gestione dei costi ha luogo all’inizio della 7
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 d’insieme della gestione dei costi di progetto
®
Figura 7-2. Diagramma di flusso dei processi di gestione dei costi di progetto
®
7.1 Stima dei costi
Stimare i costi delle attività schedulate comporta lo sviluppo di un’approssimazione
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 l’identificazione 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 dell’operatività 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 all’interno 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,
7
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.
®
Figura 7-3. Stima dei costi: Input, Strumenti e tecniche e Output
7.1.1 Stima dei costi: Input

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.
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 all’uso e all’utilità 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.
®
• 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 7
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.
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
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.
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.
®
• 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.
7.1.2 Stima dei costi: Strumenti e tecniche

.1 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.
®
.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 7
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.
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.
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.
®

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
un’unica riserva relativa a un gruppo di attività correlate, le singole riserve delle varie
attività schedulate. In questo modo, l’attività schedulata con la riserva può essere
un'attività di durata zero posizionata lungo il percorso del reticolo all’interno 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 l’avanzare 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 l’avanzare 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 Stima dei costi: Output

.1 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.
®
.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 dell’intervallo possibile delle stime (ad es. $10.000 (-10% / +15%)
per indicare che il costo previsto dell’elemento in questione è compreso tra
$9.000 e $11.500). 7
È 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 l’analisi 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.
7.2 Allocazione dei costi

L’allocazione dei costi consiste nell’aggregazione dei costi stimati delle singole
attività schedulate o Work Package, al fine di stabilire una baseline totale dei costi che
servirà a misurare l’andamento 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
®
7.2.1 Allocazione dei costi: Input

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.
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
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 d’inizio 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.
®
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.
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
7
“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.
La tecnica della stima parametrica consiste nell’utilizzo 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 nell’impiego periodico di fondi sono di solito un evento
indesiderabile per le funzioni operative dell’organizzazione. 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.
®
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
®
.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 l’elemento Piano di gestione dei costi del Piano di Project
Management.
È 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 l’analisi e la decisione mediante il processo di controllo integrato delle
7.3 Controllo dei costi

Il controllo dei costi di progetto include: 7
• 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
®
7.3.1 Controllo dei costi: Input

.1 Baseline dei costi
.2 Requisiti di finanziamento del progetto
I report sulle prestazioni (paragrafo 10.3.3.1) forniscono informazioni sull'andamento
dei costi e delle risorse durante il reale svolgersi del lavoro.
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.
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, all’ambito del progetto, alla baseline dei costi o al
piano di gestione dei costi.
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 l’autorizzazione 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.
®
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
7
determinato periodo di tempo. Il costo effettivo (AC) deve essere calcolato
usando lo stesso criterio usato per stimare il valore pianificato e l’Earned Value
(ad esempio, solo le ore di lavoro spese direttamente sull’attività, 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). L’entità degli
scostamenti CV e SV tende a decrescere al completamento del progetto, a causa
dell’effetto 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 all’Earned
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
all’Earned 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
®
• 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 sull’andamento 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.
®
I parametri della tecnica dell'Earned Value relativi al budget al completamento
(BAC), ai costi effettivi (ACC) alla data corrente e all’indicatore 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 7
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 non-
calcolata, 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
®
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
l’andamento 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 l’esame dell’andamento 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.
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.
®
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.
7
.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.
È possibile che l'analisi dell'andamento del progetto generi una richiesta di modificare
alcuni aspetti del progetto. Le modifiche individuate possono richiedere l’aumento 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).
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.
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.
®

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.
®
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à 8
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 l’impegno 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.
®
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 dall’ISO (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 l’aumento 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 l’accuratezza e/o la precisione
richieste.
®
La moderna gestione della qualità rappresenta un'integrazione al Project
Management. Ad esempio, ambedue le discipline riconoscono l’importanza 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à all’uso (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
dall’ispezione.
• 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. 13–14, American Society for Quality, 1999). 8
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.
®
Figura 8-1. Visione d’insieme della gestione della qualità di progetto
®
8
Figura 8-2. Diagramma di flusso dei processi di gestione della qualità di progetto
8.1 Pianificazione della qualità

Pianificare la qualità consiste nell’identificare 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 un’analisi dettagliata dei rischi connessi a un determinato problema.
®
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

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).
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 dall’origine della politica per la qualità, il gruppo di Project
Management è tenuto ad assicurarsi che gli stakeholder del progetto siano a
conoscenza della politica attraverso un’appropriata distribuzione delle informazioni
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.
®
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à.
8
8.1.2 Pianificazione della qualità: Strumenti e tecniche
.1 Analisi costi-benefici
Nel pianificare la qualità si deve tenere conto dell’equilibrio 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
all’interno 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.
®
.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à, l’analisi 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, un’attività finalizzata a garantire la correttezza delle prime
decisioni che si prendono, ad esempio in materia di concezione, progettazione e
collaudo. Quest’attività 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.
®
.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
8
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.
.5 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à.
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).
8.2 Effettuare l'assicurazione qualità

L'assicurazione qualità (QA) consiste nell’intraprendere 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.
®
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

Il piano di gestione della qualità descrive le modalità di esecuzione del controllo di
qualità all'interno del progetto (paragrafo 8.1.3.1).
.3 Piano di miglioramento dei processi
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 l’analisi dei processi.
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 l’analisi dei processi. Tutte le
modifiche devono essere documentate formalmente per iscritto; si sconsiglia di
elaborare o implementare qualsiasi modifica discussa verbalmente ma non
documentata.
®
.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
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
dell’accettazione 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. L’analisi 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.
®
8.2.3 Effettuare l'assicurazione qualità: Output

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
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.
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).
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).
8.3 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:
®
• 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 nell’intervallo di tolleranza
specificato) e limiti di controllo (il processo è sotto controllo se i risultati
rientrano all’interno del limiti di controllo).
Figura 8-5. Esecuzione del controllo di qualità: Input, Strumenti e tecniche e Output
8.3.1 Esecuzione del controllo di qualità: Input

.3 Liste di controllo della qualità
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.
®

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 all’interno 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).
®
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, l’ampiezza 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 8-
8 è 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.
®
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.
®
8
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 l’80% degli effetti. I diagrammi di Pareto possono anche venire utilizzati per
sintetizzare tutti i tipi di dati per analisi di tipo 80/20.
®
.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 l’uso 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 l’ispezione (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.
®
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.
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)
Le azioni correttive (paragrafo 4.5.3.1) comprendono le azioni intraprese in risposta a 8
una misurazione del controllo qualità che segnala che il processo di produzione o di
sviluppo eccede i parametri stabiliti.
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à.
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.
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.
• 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).
®
.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.
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
®
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 9
competenza al processo di pianificazione e rafforza l’impegno dedicato al progetto. Il
tipo e il numero dei membri del gruppo di progetto possono variare con l’avanzare 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 dall’intero 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 all’ambito e
l’esercizio della propria influenza su altri perché ne benefici il progetto.
La figura 9-1 mostra una visione d’insieme 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
dell’interazione 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.
®
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
l’interagire 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 un’ulteriore 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 l’acquisizione di altri membri.
• Una volta completata l’integrazione di cui sopra, il livello di esperienza dei
membri del gruppo di lavoro può accrescere o ridurre il rischio di progetto,
rendendo necessaria un’ulteriore pianificazione dei rischi.
• Quando la stima delle durate dell’attività è 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 dell’attività e la
schedulazione.
®
9
Figura 9-1. Visione d’insieme della gestione delle risorse umane di progetto
®
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,
sull’identificazione 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 sull’impatto del piano di gestione del
personale sulla struttura organizzativa.
®
Figura 9-3. Pianificazione delle risorse umane: Input, Strumenti e tecniche e Output
9.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 l’una con l’altra. Alcuni fattori ambientali 9
aziendali di rilievo (paragrafo 4.1.1.3) che coinvolgono la cultura e la struttura
dell’organizzazione 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?
®
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: un’organizzazione 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 l’assenza di budget per le trasferte sono esempi di condizioni
economiche che possono limitare le opzioni del personale.
Man mano che la metodologia di Project Management matura all’interno 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 all’inizio 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.
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 nell’ambito del processo di pianificazione
delle risorse umane.
®
9.1.2 Pianificazione delle risorse umane: Strumenti e tecniche
.1 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,
l’obiettivo 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à.
Figura 9-4. Formati di definizione di ruoli e responsabilità

• Diagrammi di tipo gerarchico: l’organigramma tradizionale consente di
mostrare le posizioni e le relazioni in un formato grafico dall’alto 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 dell’organizzazione (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 all’interno 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
dell’organizzazione (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 l’attrezzatura 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.
®
• 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
all’interno 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
un’attività. 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-responsabilità-
autorità. 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 dell’esecuzione dell’assicurazione qualità e delle attività
di controllo della qualità.
®
.2 Networking
L’interazione 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 sull’efficacia 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 all’inizio di un progetto, anche
l’esecuzione di attività di networking a cadenza regolare prima dell’inizio del progetto
può rivelarsi molto efficace.
.3 Teoria organizzativa
La teoria organizzativa fornisce informazioni in merito al comportamento di persone,
gruppi e unità organizzative. L’applicazione 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 dell’elenco dei ruoli e delle responsabilità necessari per
9
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
un’attività, l’accettazione 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 dell’ambito.
.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, l’organigramma
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.
®
.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 all’area applicativa e alle dimensioni del progetto; è
tuttavia necessario tenere conto di una serie di elementi:
• Acquisizione del personale: nel corso della pianificazione dell’acquisizione 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
l’assunzione. Uno degli strumenti per pianificare le risorse umane è
l’istogramma 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 l’intera 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 l’aggiunta 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
®
• 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 l’assegnazione 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
l’assegnazione dei premi garantisce che il riconoscimento del merito abbia
9
luogo e non venga tralasciato. Il riconoscimento e l’assegnazione dei premi si
verificano nell’ambito 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.
9.2 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
®
9.2.1 Acquisire il gruppo di progetto: Input

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?
Una o più delle organizzazioni coinvolte nel progetto possono disporre di politiche,
direttive o procedure che regolano l’assegnazione del personale (paragrafo 4.1.1.4).
Anche i reparti di gestione delle risorse umane possono collaborare all’individuazione,
all’assunzione e all’orientamento dei membri del gruppo di progetto.
I ruoli e le responsabilità definiscono posizioni, skill e competenze richiesti dal
progetto (paragrafo 9.1.3.1).
Gli organigrammi di progetto forniscono una visione d’insieme del numero di persone
necessarie per il progetto (paragrafo 9.1.3.2).
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 l’acquisizione del gruppo di progetto (paragrafo
9.1.3.3).
9.2.2 Acquisire il gruppo di progetto: Strumenti e tecniche

.1 Pre-assegnazione
In alcuni casi, i membri del gruppo di progetto sono già noti, ovvero vengono pre-
assegnati. Questa situazione si verifica se il progetto nasce da una proposta
competitiva che dipende dall’impiego di determinate persone, se il progetto dipende
dalle competenze di determinate persone o se alcune assegnazioni del personale
vengono definite nel Project Charter.
®
.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 all’interno 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 l’assunzione di singoli consulenti o il 9
subappalto del lavoro ad un’altra struttura organizzativa.
.4 Gruppi virtuali
L’uso 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 l’e-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 l’esperto
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 nell’ambiente 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.
®
9.2.3 Acquisire il gruppo di progetto: Output

.1 Assegnazioni del personale di progetto
L’organico del progetto viene creato con l’assegnazione 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.
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.
9.3 Sviluppare il gruppo di progetto

Sviluppare il gruppo di progetto migliora le competenze e l’interazione 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, l’assistenza 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 l’intero
ciclo di vita del progetto.
Figura 9-8. Sviluppare il gruppo di progetto: Input, Strumenti e tecniche e Output
®
9.3.1 Sviluppare il gruppo di progetto: Input
Lo sviluppo del gruppo ha inizio con un elenco dei membri del gruppo di progetto. I
documenti sull’assegnazione del personale del progetto (paragrafo 9.2.3.1)
identificano le persone che fanno parte del gruppo.
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).
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
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 l’empatia, la capacità di esercitare la
propria influenza, la creatività e l’agevolazione 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 nell’ambito 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.
®
.3 Attività di costruzione del gruppo

Le attività di costruzione del gruppo possono variare da una semplice voce all’ordine
del giorno, a cui si dedicano non più di cinque minuti in occasione di un incontro
sull’analisi dello stato di avanzamento, ad un incontro fuori sede con l’intervento 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 l’attività 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.
.4 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.
.5 Co-location
La co-location prevede la collocazione in un’unica 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 l’invio 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, l’utilizzo di gruppi virtuali consente dall’altro di ridurre la frequenza con la
quale i membri del gruppo di lavoro si riuniscono tutti in un’unica sede.
.6 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
all’assegnazione 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 win-
win 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 l’individualismo.
®
9.3.3 Sviluppare il gruppo di progetto: Output
.1 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 dell’efficacia 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 dell’efficacia 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.
9.4 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
9
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 all’interno di un’organizzazione 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
®
9.4.1 Gestire il gruppo di progetto: Input

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). Nell’ambito 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.
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.
Per monitorare e valutare le prestazioni (paragrafo 9.1.3.1) viene utilizzato un elenco
dei ruoli e delle responsabilità del personale.
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).
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 l’interazione all’interno del gruppo.
Nell’ambito del processo Dirigere e gestire l’esecuzione 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.
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 dell’ambito 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.
®
9.4.2 Gestire il gruppo di progetto: Strumenti e tecniche
.1 Osservazione e conversazione
L’osservazione 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
l’avanzamento 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.
L’espressione “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.
9
Gli obiettivi su cui focalizzarsi per condurre la valutazione delle prestazioni nel
corso del progetto possono comprendere l’ulteriore 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, l’individuazione 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 l’incremento della produttività e il
miglioramento delle relazioni lavorative. Le ragioni dei conflitti comprendono
l’insufficienza 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.
®
.4 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.
9.4.3 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 sull’intero piano del progetto. Se le questioni relative al
personale danneggiano il piano del progetto, ad esempio rendono necessaria
un’estensione della schedulazione o portano a un superamento del budget, è possibile
elaborare una richiesta di modifica attraverso il processo Controllo integrato delle
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.
Nel momento in cui il gruppo di Project Management identifica questioni potenziali o
emergenti legate al personale, è possibile sviluppare un’azione preventiva per ridurre
la probabilità e/o l’impatto 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, un’ulteriore chiarificazione dei ruoli per
garantire il rispetto di tutte le responsabilità e l’aggiunta di ore lavorative da parte del
personale in previsione del lavoro straordinario che potrebbe rendersi necessario a
breve per rispettare le scadenze del progetto.
• 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 un’interazione
significativa.
®
• 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
nell’area 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 nell’ambito del piano di Project
Management. Esempi di informazioni aggiornate del piano sono i ruoli dei nuovi
9
membri del gruppo di progetto, i dati sulla formazione ulteriore e le decisioni sui
premi.
®
CAPITOLO 10
Gestione della comunicazione di progetto

La gestione della comunicazione di progetto è un’area di conoscenza che utilizza i
processi necessari a garantire tempestivamente e appropriatamente la generazione, la
raccolta, la distribuzione, l’archiviazione, 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
10
visione d’insieme 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 sull’avanzamento, 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 l’impegno 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.
®
Capitolo 10 − Gestione delle comunicazioni di progetto
Figura 10-1. Visione d’insieme della gestione della comunicazione di progetto
®
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. L’arte 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.
®
• Tecniche di presentazione: linguaggio del corpo e preparazione di supporti

visivi.
• Tecniche di gestione delle riunioni: preparazione di un’agenda 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 è l’azione di
riconoscimento del messaggio. Per riconoscimento si intende che il destinatario
segnala la ricezione del messaggio, ma non necessariamente la sua condivisione.
Un’altra 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à nell’uso 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, l’invio del messaggio mediante una serie di tecnologie, e
l’assicurazione 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.
®
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.
L’dentificazione 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

Tutti i fattori descritti nel paragrafo 4.1.1.3 sono utilizzati come input di questo
processo.
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.
®
.3 Descrizione dell’ambito del progetto

La descrizione dell’ambito del progetto (paragrafo 5.2.3.1) fornisce una base
documentata per le future decisioni di progetto e per confermare una conoscenza
comune dell’ambito di progetto a tutti gli stakeholder. L’analisi degli stakeholder è
completata come parte del processo di definizione dell’ambito.
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
L’analisi 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 un‘analisi 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 l’intento è
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.
®
.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 dall’avere 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 l’esperienza 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 l’informazione.
• 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 l’escalation 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 l’avanzare e lo svilupparsi del progetto.
• Glossario della terminologia comune.
®
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 dell’informazione.
• 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 l’implementazione 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
®
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 l’abilità 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.
10
• Interna (all’interno del progetto) ed esterna (cliente, mass media, pubblico).
• Formale (report, conferenze illustrative) e informale (promemoria,
conversazioni ad hoc).
• Verticale (verso l’alto e verso il basso nell‘organizzazione) e orizzontale (tra
pari grado).
.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 l’accesso 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.
®
.4 Processo delle lesson learned

Una sessione di lesson learned è incentrata nell’identificazione 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.
L’argomento centrale delle riunioni sulle lesson learned può variare. In alcuni
casi, l’attenzione è posta su processi di sviluppo tecnico o di prodotto, mentre in altri
casi l’attenzione è 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
l’efficacia e l’efficienza 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

• Documentazione delle lesson learned: la documentazione comprende le cause
dei problemi, le motivazioni alla base dell’azione 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).
®
• 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.
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 10
fornire informazioni su ambito, schedulazione, costo e qualità. Molti progetti
richiedono inoltre informazioni sui rischi e sull’approvvigionamento. I report possono
essere onnicomprensivi o basati sulle eccezioni.
Figura 10-6. Reporting delle prestazioni: Input, Strumenti e tecniche e Output
®
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 dell’esecuzione 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 l’esecuzione 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 l’esecuzione del progetto e sono misurate le
deviazioni per il controllo di gestione. La baseline di misurazione delle
prestazioni tipicamente integra l’ambito, la schedulazione e i parametri di costo
di un progetto, ma può anche includere parametri tecnici e di qualità.
Le richieste di modifica approvate (paragrafo 4.6.3.1) sono modifiche richieste per
estendere o limitare l’ambito del progetto, per modificare il costo stimato, o per
esaminare le stime di durata dell’attività, che sono state approvate e sono pronte per
l’implementazione 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.
®
.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 l’accesso 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 sull’avanzamento.
.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

10
I report sulle prestazioni organizzano e riepilogano le informazioni raccolte e
presentano i risultati di un’analisi comparata con la baseline di misurazione delle
prestazioni. I report dovrebbero fornire informazioni sullo stato e sull’avanzamento, 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
dall’analisi dell’Earned 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 all’analisi dell’Earned Value,
la figura 10-7 fornisce una visualizzazione a tabella dei dati sull’Earned Value.
®
Pianificato Ottenuto Costo Indice delle

prestazioni
Elemento della WBS Budget Earned Value Costo Scostamento dei costi Scostamento dei tempi Costo Schedula-
effettivo zione
($) ($) ($) ($) (%) ($) (%) 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 68.000 68.000 72.500 -4.500 -6,6 0 0,0 0,94 1,00
termine
5.0 Supporto di 12.000 10.000 10.000 0 0,0 -2.000 -16,7 1,00 0,83
implementazione
6.0 Manuale di practice 7.000 6.200 6.000 200 3,2 -800 -11,4 1,03 0,89
7.0 Piano di presentazione al 20.000 13.500 18.100 -4.600 -34,1 -6.500 -32,5 .075 0,68
pubblico
Totali 257.000 223.700 239.400 -15.700 -7,0 -33.300 -13,0 0,93 0,87
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 l’esecuzione 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.
L’analisi 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).
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 dell’azione 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.
®
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 all’interno del
piano di gestione della comunicazione (paragrafo 10.1.3.1), che è un piano ausiliario
del piano di Project Management.
Con l’insorgere 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 all’interno 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.
®
.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 un’importanza 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 l’identificazione 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 all’ambito del
progetto rientrino o meno nell’ambito dell’attuale progetto.
• Si aggiunge dell’altro personale al progetto, chiudendo pertanto la questione
relativa alla carenza degli skill richiesti.
• Le negoziazioni con i manager funzionali dell‘organizzazione 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 l’avanzamento 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.
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 dell‘azione 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.
Il piano di Project Management viene aggiornato con le modifiche apportate al piano
di comunicazione.
®
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
l’avanzamento del progetto. Gli obiettivi alla base della gestione dei rischi di progetto
consistono nell’aumentare la probabilità e l’impatto di eventi positivi e nel diminuire
la probabilità e l’impatto di eventi dannosi per il progetto. La figura 11-1 mostra una
visione d’insieme 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
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
un’ulteriore 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 l’effetto 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
l’efficacia 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 l’impegno 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.
®
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 l’obiettivo dei
tempi del progetto preveda la consegna in conformità alla schedulazione concordata o
l’obiettivo 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, l’evento di rischio può essere l’esigenza di più tempo espressa
dall’agenzia di concessione licenze per l’emissione del permesso o l’inadeguatezza
all’attività 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 dell’ambiente 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.
®
11
Figura 11-1. Visione d’insieme della gestione del rischio di progetto
®
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 l’accelerazione del lavoro raggiungibile
mediante l’incremento 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 sull’accuratezza 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 dell’organizzazione; ogni comunicazione e
decisione sui rischi deve essere aperta e veritiera. Le risposte ai rischi riflettono ciò
che l’organizzazione percepisce come punto di equilibrio tra l’assumere e l’evitare 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.
®
11
Figura 11-2. Diagramma di flusso dei processi di gestione dei rischi di progetto
®
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 all’importanza data dall’organizzazione 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

L’attitudine 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). L’approccio 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.
®
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 all’interno della
struttura organizzativa sia responsabile della pianificazione della gestione del rischio e
dell’esecuzione 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 dell’organizzazione 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 11
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 l’esaustività del
processo atto all’identificazione sistematica dei rischi a un livello di dettaglio
sempre omogeneo e favoriscono l’efficacia e la qualità del processo di
identificazione dei rischi. Un’organizzazione 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.
®
• Definizioni della probabilità e dell’impatto 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”. Un’alternativa è 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à dell’architettura del progetto).
®
In caso di manifestazione effettiva del rischio, la scala di impatto riflette
l’importanza dell’impatto, 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 dell’obiettivo su cui potenzialmente potrebbe
verificarsi l’impatto, 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 dell’organizzazione 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
l’effetto 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 l’approccio relativo che quello numerico
(in questo caso non lineare). L’esempio non implica che i termini relativo e numerico
siano equivalenti, ma raggruppa semplicemente due alternative in un’unica figura.
• Matrice di probabilità e impatto: ai rischi vengono assegnate delle priorità in
base alle loro potenziali implicazioni sul raggiungimento degli obiettivi del
progetto. L’approccio più comune per l’assegnazione delle priorità ai rischi è dato
dall’utilizzo 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
11
organizzativa impostare le combinazioni di probabilità e impatto specifiche che
portano alla classificazione dell’importanza di un rischio come “alta”, “media” o
“bassa”, unitamente all’importanza 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.
Figura 11-5. Definizione delle scale di impatto per quattro obiettivi di progetto
®
• 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, l’analisi 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.
L’identificazione 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 dell’iterazione 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 l’implementazione 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
®
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
nell’identificazione 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 dell’ambito 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
11
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
un’area di conoscenza per poter individuare la presenza di possibili rischi relativi
all’intero progetto.
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 l’omogeneità 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 nell’identificazione dei rischi.
• Brainstorming: l’obiettivo 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.
®
• 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 un’influenza maggiore degli altri sul
risultato.
• Colloqui: l’identificazione 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 l’identificazione dei rischi.
• Identificazione della causa principale: si tratta di un’indagine 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 l’analisi 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 l’identificazione 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. L’analisi 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 d’influenza: rappresentazioni grafiche delle situazioni che
mostrano le influenze causali, l’ordine temporale degli eventi e altre relazioni tra
variabili e risultati.
®
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 11
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 all’inserimento di nuove categorie di rischio nell’elenco 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.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
un’analisi 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.
L’analisi qualitativa del rischio valuta la priorità dei rischi identificati attraverso la
probabilità che si verifichino, il relativo impatto sugli obiettivi di progetto nel caso
dell’effettivo 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 l’importanza di un rischio. Una valutazione della qualità delle
informazioni a disposizione sui rischi del progetto facilita la comprensione della
valutazione dell’importanza del rischio per il progetto.
®
L’analisi 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 l’analisi quantitativa del rischio, qualora sia richiesta. L’analisi
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.
L’analisi 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 all’analisi 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 dell’ambito del progetto (paragrafo
5.2.3.1).
Gli elementi principali del piano di gestione dei rischi per l’analisi 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 l’analisi 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 dell’analisi qualitativa del rischio.
Uno degli elementi principali del registro dei rischi per l’analisi qualitativa del rischio
è rappresentato dall’elenco dei rischi identificati (paragrafo 11.2.3.1).
®
11.3.2 Analisi qualitativa dei rischi: Strumenti e tecniche
.1 Valutazione della probabilità e dell’impatto dei rischi
La valutazione della probabilità dei rischi esamina la possibilità che ciascun rischio si
verifichi. La valutazione dell’impatto dei rischi esamina invece l’effetto 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 nell’ordine 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
L’assegnazione 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 dell’importanza 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, l’area di colore grigio scuro (con i numeri più
alti) rappresenta un rischio elevato; l’area grigio intermedio (con i numeri più piccoli)
rappresenta un rischio basso; infine, l’area grigio chiaro (con numeri intermedi)
rappresenta un rischio moderato. In genere, l’organizzazione specifica le regole di
classificazione dei rischi prima dell’avvio 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.
®
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
nell’area a rischio elevato (grigio scuro) della matrice potrebbero richiedere un’azione
prioritaria e strategie di risposta aggressive. Per le minacce nell’area 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 nell’area ad
alto rischio (grigio scuro) che potrebbero essere ottenute nel modo più semplice e che
offrono il vantaggio maggiore. Le opportunità nell’area a basso rischio (grigio
intermedio) dovrebbero essere monitorate.
.3 Valutazione della qualità dei dati sui rischi
Per poter essere credibile, l’analisi qualitativa del rischio richiede dati accurati e
imparziali. L’analisi 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 l’analisi del livello di comprensione del rischio, dell’accuratezza, della
qualità e dell’integrità dei dati sui rischi.
L’utilizzo di dati di bassa qualità sui rischi può ridurre sensibilmente l’utilità
dell’analisi qualitativa del rischio per il progetto. Se la qualità dei dati non è
accettabile, potrebbe rendersi necessaria un’ulteriore 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.
®
.4 Categorizzazione dei rischi
I rischi del progetto possono essere categorizzati in base alle fonti di rischio (l’utilizzo
della RBS), all’area del progetto interessata (utilizzo della WBS) o ad altra categoria
utile (fase di progetto) per determinare le aree del progetto maggiormente esposte agli
effetti dell’incertezza. Il raggruppamento dei rischi per causa principale comune
facilita lo sviluppo di risposte efficaci contro i rischi stessi.
.5 Valutazione dell’urgenza 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 dall’analisi 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 dall’analisi
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
11
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
dell’impatto 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
un’attenzione particolare. La scoperta di concentrazioni dei rischi può
migliorare l’efficacia 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 un’ulteriore analisi e risposta: alcuni rischi potrebbero
richiedere un’ulteriore analisi, compresa l’analisi quantitativa del rischio, e
un’ulteriore azione di risposta.
• Watchlist dei rischi di priorità bassa: i rischi che non vengono valutati come
importanti nel corso dell’analisi qualitativa del rischio possono essere aggiunti
in una watchlist ai fini del monitoraggio continuo.
• Tendenze nei risultati dell’analisi qualitativa del rischio: con la ripetizione
dell’analisi, potrebbe risultare evidente una tendenza a particolari rischi che
rende più o meno urgente/importante la risposta ai rischi o l’esecuzione di
un’analisi aggiuntiva.
®
11.4 Analisi quantitativa dei rischi

L'analisi quantitativa dei rischi viene eseguita in merito ai rischi a cui è stata assegnata
una priorità, tramite l’analisi qualitativa del rischio, perché ritenuti potenzialmente e
sostanzialmente influenti sulle richieste concorrenziali del progetto. L’analisi
quantitativa esamina l’effetto 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 l’analisi dell’albero 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.
L’analisi quantitativa del rischio viene in genere eseguita dopo l’analisi
qualitativa del rischio, anche se alcuni manager dei rischi con molta esperienza la
eseguono direttamente dopo il processo Identificazione dei rischi. In alcuni casi,
l’analisi 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 l’analisi 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 l’esigenza di incrementare o
diminuire l’azione 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
®
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 l’analisi 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 l’analisi quantitativa del
rischio sono l’elenco dei rischi identificati, la classificazione relativa o l’elenco 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
11
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.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 l’impatto 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 sull’affidabilità e
sulla credibilità dell’analisi.
®
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 nell’albero 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
®
• 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 nell’analisi
quantitativa del rischio:
• Analisi di sensitività: l’analisi di sensitività consente di determinare quali rischi
hanno il maggiore impatto potenziale sul progetto. Prende in considerazione il
grado di incidenza dell’incertezza di ogni elemento del progetto sull’obiettivo
esaminato, quando tutti gli altri elementi incerti si mantengono sul valore della
baseline. Una delle raffigurazioni più diffuse dell’analisi di sensitività è il
grafico a barre, uno strumento particolarmente efficace per confrontare
l’importanza relativa delle variabili con un grado elevato di incertezza rispetto a
quelle ritenute più stabili.
• Analisi del valore monetario atteso: l’analisi 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). L’EMV 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
nell’analisi dell’albero delle decisioni (figura 11-12). Per l’esecuzione
dell’analisi del rischio nei costi e nella schedulazione si consigliano sempre le 11
tecniche di modellazione e simulazione, perché sono più efficienti e meno
soggette ad un uso improprio rispetto all’analisi del valore monetario atteso.
• Analisi dell’albero delle decisioni: la struttura dell’analisi dell’albero 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 dell’albero 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.
®
Figura 11-12. Diagramma dell’albero 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 un’analisi 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 un’analisi 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.
®
Figura 11-13. Risultati della simulazione dei rischi del costo
11
11.4.3 Analisi quantitativa dei rischi: Output
Il registro dei rischi viene creato con il processo Identificazione dei rischi (paragrafo
11.2) e modificato nell’analisi qualitativa del rischio (paragrafo 11.3); viene quindi
ulteriormente aggiornato con l’analisi 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
dell’analisi 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) è
all’incirca del 12%.
®
• Elenco in ordine di priorità dei rischi quantificati: l’elenco 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 dell’analisi quantitativa del rischio: con la ripetizione
dell’analisi, è 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 l’analisi qualitativa e quella
quantitativa del rischio. Prevede l’identificazione e l’assegnazione 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 all’importanza 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 dell’analisi 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.
®
Alguns componentes do plano de gerenciamento de riscos que são 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 são necessárias, designação de pessoal e elaboração de cronogramas e
orçamentação para o planejamento de respostas a riscos.
Il registro dei rischi viene prima sviluppato nel processo Identificazione dei rischi e
poi aggiornato con l’analisi 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 l’elenco 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 dell’analisi 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
dell’analisi 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
11
rischi, come l’analisi dell’albero delle decisioni. Successivamente, si elaborano azioni
specifiche mirate all’implementazione della strategia scelta. Possono essere
selezionate strategie principali e di backup. È possibile sviluppare un piano di riserva
per l’implementazione 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.
.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 nell’evitare, 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 dall’impatto del rischio o di ridurre la portata dell’obiettivo a
repentaglio, ad esempio prolungando la schedulazione o riducendo l’ambito.
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.
®
• Trasferire: trasferire i rischi richiede la cessione a terzi dell’impatto 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, l’uso 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, l’uso di un contratto a rimborso spese trasferisce il rischio
legato ai costi all’acquirente, mentre un contratto a prezzo fisso, se l’architettura
del progetto è stabile, trasferisce il rischio al fornitore.
• Mitigare: ridurre i rischi comporta una diminuzione della probabilità e/o
dell’impatto di un evento di rischio fino a raggiungere una soglia accettabile.
Adottare un’azione preventiva atta a ridurre la probabilità e/o l’impatto 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 l’impatto del rischio concentrandosi sugli aspetti che
derminano la severità del rischio. Ad esempio, l’inserimento di elementi
ridondanti in un sottosistema può ridurre l’impatto 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 l’effettivo verificarsi
dell’opportunità. Il suo obiettivo consiste nel tentare di eliminare le incertezze
associate a un rischio positivo facendo in modo che l’opportunità abbia
effettivamente luogo. Sfruttare una risposta immediata comporta l’assegnazione 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
dell’opportunità 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 un’opportunità
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 dell’opportunità, se si affrontano e supportano in
modo proattivo le condizioni che portano al verificarsi dell’opportunità, la
probabilità può essere aumentata. È possibile rivolgere l’attenzione ale
potenziali cause dell’impatto cercando di incrementare la suscettibilità del
progetto all’opportunità.
®
.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 un’altra strategia di risposta appropriata. È adatta sia per
le minacce che per le opportunità e può essere passiva o attiva. L’accettazione 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
l’implementazione del piano. È necessario definire e registrare gli eventi che abilitano
le risposte di contingency, come il mancato rispetto delle milestone intermedie o
l’assegnazione di una priorità maggiore a un fornitore.
11.5.3 Pianificazione della risposta ai rischi: Output

.1 Registro dei rischi (aggiornamenti) 11
Il registro dei rischi viene sviluppato nel processo Identificazione dei rischi e
aggiornato quindi con l’analisi 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 all’ordinamento 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 dell’insorgenza 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.
®
• Piani di contingency e trigger che ne richiedono l’esecuzione.

• 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 l’esecuzione delle risposte
pianificate, unitamente ai rischi che sono stati deliberatamente accettati.
• Rischi collaterali che si sono verificati come risultato diretto
dell’implementazione di una risposta ai rischi.
• Riserve per contingency che vengono calcolate in base all’analisi 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 l’esecuzione 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 dell’esecuzione 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 l’analisi delle tendenze, che prevedono
l’utilizzo dei dati sulle prestazioni ottenuti dall’esecuzione 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
l’ausilio dell’analisi 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.
®
Il monitoraggio e controllo dei rischi può anche prevedere la scelta tra strategie
alternative, l’esecuzione di un piano di contingency o di riserva, l’esecuzione di azioni
correttive e la modifica del piano di Project Management. Il titolare della risposta ai
rischi deve presentare relazioni periodiche al project manager sull’efficacia 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 l’aggiornamento 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 l’assegnazione 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, all’ambito 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.
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.
®

I report sulle prestazioni (paragrafo 10.3.3.1) forniscono informazioni sulle
prestazioni delle attività di progetto, ad esempio un’analisi 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 l’identificazione di
nuovi rischi e la rivalutazione dei rischi mediante l’uso 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 all’ordine 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 l’efficacia delle risposte ai
rischi e si affrontano i rischi identificati, le loro cause e l’efficacia del processo di
gestione dei rischi.
.3 Scostamento e analisi delle tendenze
Le tendenze nell’esecuzione del progetto devono essere riviste mediante i dati sulle
prestazioni. L’analisi dell’Earned 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 l’esecuzione 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 dell’ambito del
progetto.
Nel corso dell’esecuzione 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). L’analisi 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.
®
.6 Riunioni sullo stato di avanzamento
La gestione dei rischi di progetto deve essere una voce all’ordine 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à, all’impatto, 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 l’archivio 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
L’implementazione 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 l’esecuzione del progetto
(paragrafo 4.4) e di monitoraggio e controllo dei rischi.
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 l’esecuzione 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
Le azioni preventive consigliate consentono di conformare il progetto al piano di
Project Management.
®

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 dell’organizzazione. 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.
®
CAPITOLO 12
Gestione dell’approvvigionamento di
progetto
La gestione dell’approvvigionamento 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. L’organizzazione può ricoprire sia il ruolo di acquirente che di
fornitore del prodotto, del servizio o dei risultati oggetti del contratto.
La gestione dell’approvvigionamento 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 dell’approvvigionamento di progetto comprende anche le operazioni
di amministrazione di ogni contratto emesso da un’organizzazione esterna
(l’acquirente) che sta acquisendo il progetto dalla Performing Organization (il
12
fornitore) e di amministrazione degli obblighi contrattuali gravanti sul gruppo di
progetto ai sensi del contratto.
La figura 12-1 mostra una visione d’insieme dei processi di gestione
dell’approvvigionamento 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 dell’approvvigionamento 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
l’acquirente 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.
®
Capitolo 12 − Gestione dell’approvvigionamento 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 dell’approvvigionamento 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 l’acquirente a corrispondere un compenso
monetario o di altro valore. Un contratto stabilisce una relazione legale soggetta a
ricorso legale presso un tribunale. L’accordo 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
l’acquirente si avvale per stabilire che cosa il fornitore deve eseguire o fornire. Il
gruppo di Project Management è tenuto a collaborare nell’adattare il contratto alle
esigenze specifiche del progetto. In base all’area 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
dell’organizzazione.
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, l’obiettivo
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 dell’accordo.
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 dell’organizzazione.
Le varie attività inserite nel processo di gestione dell’approvvigionamento 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.
®
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 dell’approvvigionamento 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
all’organizzazione acquirente. In base all’area applicativa, il fornitore può essere
denominato anche “appaltatore”, “subappaltatore”, “venditore” o “fornitore di
servizi”. In base alla posizione dell’acquirente nel ciclo di acquisizione del progetto,
l’acquirente 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 dell’appalto.
Se l’acquisizione 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:
• L’acquirente 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 l’approvazione dall’acquirente
12
sulle decisioni relative al personale).
In questo capitolo si presuppone che l’acquirente 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 l’acquirente 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.
®
Figura 12-1. Visione d’insieme della gestione dell’approvvigionamento di progetto
®
12
Figura 12-2. Diagramma di flusso dei processi di gestione dell’approvvigionamento di
progetto
®
12.1 Pianificare gli acquisti

Il processo Pianificare gli acquisti identifica quali esigenze di progetto possono essere
meglio soddisfatte mediante l’acquisto di prodotti, servizi o risultati all’esterno
dell’organizzazione del progetto e quali esigenze di progetto possono invece essere
realizzate dal gruppo di progetto nel corso dell’esecuzione 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
l’esecuzione 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 l’analisi dei potenziali
fornitori, in modo particolare se l’acquirente 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 all’esecuzione 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 dell’approvvigionamento 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 un’ottica di riduzione dei rischi e di loro trasferimento al fornitore.
Figura 12-3. Pianificare gli acquisti: Input, Strumenti e tecniche e Output
®
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
dell’approvvigionamento e nella selezione del tipo di contratto da adottare. Le
politiche dell’organizzazione pongono spesso dei vincoli alle decisioni di
approvvigionamento. Tali vincoli possono limitare l’utilizzo 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 dall’organizzazione e per stabilire una catena di
approvvigionamento estesa.
12
La descrizione dell’ambito del progetto (paragrafo 5.2.3.1) riporta i limiti, i requisiti, i
vincoli e gli assunti del progetto correlati all’ambito 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 dell’ambito del progetto fornisce informazioni importanti sulle
esigenze e sulle strategie del progetto analizzate nel corso del processo Pianificare gli
acquisti e contiene l’elenco 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 dell’approvvigionamento e
quindi presentati ai fornitori mediante un contratto.
La parte relativa alla descrizione delle specifiche di prodotto contenuta nella
descrizione dell’ambito 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.
®
La struttura di scomposizione del lavoro (WBS) e il dizionario dei componenti

della WBS presenti nella descrizione dell’ambito del progetto forniscono un piano
strutturato e dettagliato dell’ambito 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).
Il dizionario della WBS (paragrafo 5.3.3.3) fornisce capitolati dettagliati che
contengono l’identificazione 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
dell’ambito, il piano di gestione dell’approvvigionamento, 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 dell’approvvigionamento. 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 nell’eventualità 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”
L’analisi “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 l’acquisto (“buy”), occorre
poi decidere se acquistare o noleggiare i beni richiesti. L’analisi include sia i costi
indiretti che quelli diretti. Ad esempio, la parte “buy” dell’analisi comprende sia i
costi effettivi legati alle spese vive sostenute per l’acquisto del prodotto che i costi
indiretti derivanti dalla gestione del processo di acquisto.
®
In un’analisi “make-or-buy”, la scelta di acquistare riflette sia la prospettiva
dell’organizzazione del gruppo di progetto, sia le esigenze immediate del progetto
stesso. Ad esempio, acquistare un’attrezzatura (che sia una gru o un computer)
piuttosto che noleggiarla o prenderla in leasing potrebbe rivelarsi più o meno
conveniente in un’ottica prettamente legata al progetto. Tuttavia, se l’organizzazione
del gruppo di progetto ha necessità di un uso frequente dell’attrezzatura, la frazione
del costo di acquisto allocata al progetto potrebbe essere inferiore al costo del
noleggio. La distribuzione dei costi può essere effettuata mediante un’analisi dei
margini.
Anche la strategia a lungo termine dell’organizzazione del gruppo di progetto è
una componente dell’analisi “make-or-buy”. Gli elementi necessari per l’esecuzione
del progetto potrebbero non essere disponibili all’interno dell’organizzazione.
Tuttavia, se l’organizzazione 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 l’investimento operato dall’organizzazione per il futuro.
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
12
dettagli tecnici di prodotti, servizi o risultati oggetto dell’approvvigionamento, sia per
alcuni aspetti dei processi di gestione dell’approvvigionamento.
.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 l’acquirente 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.
®
• Contratto con rimborso spese: si tratta di un contratto che prevede il

pagamento (rimborso) da parte dell’acquirente 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 dall’ufficio. 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 dall’acquirente 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 l’ambito 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 l’acquirente 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 dell’assegnazione del contratto,
l’acquirente non stabilisce il valore completo dell’accordo e la quantità esatta di
elementi da consegnare. I contratti T&M possono quindi aumentare di valore
come se fossero accordi a rimborso spese. D’altro 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 dall’acquirente e dal fornitore.
®
La scelta del tipo di contratto da adottare dipende anche dai requisiti che
l’acquirente 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, l’inclusione di alcuni requisiti potrebbe portare
il fornitore ad incrementare il costo. Un’ulteriore osservazione è legata all’eventuale
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 l’acquirente 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 dell’approvvigionamento
Il piano di gestione dell’approvvigionamento descrive la modalità con cui vengono
gestiti i processi di approvvigionamento dalla fase di sviluppo della documentazione
relativa all’approvvigionamento 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. 12
• Documenti di approvvigionamento standardizzati, se necessari.
• Gestione di più fornitori.
• Coordinazione dell’approvvigionamento 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 l’acquisto o l’acquisizione 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.
®
Il piano di gestione dell’approvvigionamento può essere, in base alle esigenze

del progetto, formale o informale, dettagliato o sintetico. Il piano di gestione
dell’approvvigionamento è 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
dell’ambito di progetto coperta dal contratto. Il capitolato (SOW) di ogni contratto
viene sviluppato a partire dalla descrizione dell’ambito del progetto, dalla struttura di
scomposizione del lavoro di progetto e dal dizionario della WBS. Il capitolato
contrattuale descrive l’elemento oggetto dell’approvvigionamento ad un livello di
dettaglio sufficiente da consentire ai potenziali fornitori di determinare se sono in
grado di fornire l’elemento in questione. Il livello di dettaglio sufficiente varia in base
alla natura dell’elemento, alle esigenze dell’acquirente 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 l’elemento
oggetto dell’approvvigionamento. In alcune aree applicative, il capitolato contrattuale
ha requisiti precisi di contenuto e formato. Ogni singolo elemento incluso
nell’approvvigionamento 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 l’avanzare 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 l’esigenza 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).
®
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

.2 Capitolato contrattuale
.3 Decisioni “make-or-buy” 12
Le decisioni “make-or-buy” (paragrafo 12.1) vengono documentate in un elenco
pubblicato di elementi da acquistare o acquisire e di elementi che devono essere
realizzati dal gruppo di progetto.
Il piano di Project Management (paragrafo 4.3) fornisce altri documenti sugli output
della pianificazione, che potrebbero avere subito delle modifiche e che devono quindi
essere esaminati nuovamente durante lo sviluppo della documentazione di
approvvigionamento. In particolare, lo sviluppo della documentazione di
approvvigionamento è strettamente collegato alle date di consegna stabilite dalla
schedulazione di progetto (paragrafo 6.5).
• Registro dei rischi: contiene le informazioni sui rischi generate dai processi di
gestione dei rischi, tra cui i rischi identificati, le cause principali dei rischi, i
responsabili dei rischi, i risultati dell’analisi dei rischi, l’assegnazione di priorità
ai rischi, la categorizzazione dei rischi e le risposte ai rischi.
• Accordi contrattuali relativi ai rischi (paragrafo 11.5.3.3): comprende gli
accordi per la stipulazione di assicurazioni, per la fornitura di servizi o altri
elementi, in base alle necessità, pattuiti per definire la responsabilità delle parti
per quanto riguarda rischi specifici, qualora si verificassero.
®
• 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.2.2 Pianificare le forniture: Strumenti e tecniche

.1 Moduli standard
I moduli standard comprendono i contratti standard, le descrizioni standard degli
elementi oggetto dell’approvvigionamento, gli accordi di non divulgazione, le liste di
controllo con i criteri per la valutazione delle offerte o le versioni standardizzate di
tutte le parti dei documenti di offerta richiesti. Nelle organizzazioni che gestiscono
molti approvvigionamenti spesso questi documenti sono standardizzati. Le
organizzazioni acquirenti e fornitrici che svolgono transazioni aventi per oggetto la
proprietà intellettuale dovrebbero approvare e sottoscrivere degli accordi di non
divulgazione prima di rivelare alla controparte eventuali informazioni di proprietà
intellettuale relative al progetto.
12.2.3 Pianificare le forniture: Output

.1 Documenti di approvvigionamento
I documenti di approvvigionamento consentono di richiedere delle proposte da parte
dei potenziali fornitori. Quando la decisione sulla scelta del fornitore si basa sul
prezzo (ad esempio per l’acquisto di articoli commerciali o standard), si utilizzano
termini come “offerta”, “offerta d’appalto” o “preventivo”; mentre quando
l’attenzione si concentra su altri fattori, quali le competenze tecniche o l’approccio
tecnico, si parla solitamente di “proposta”. Tuttavia, i termini vengono spesso
utilizzati in modo intercambiabile e occorre stare attenti a non fare assunti
ingiustificati sulle possibili implicazioni legate al termine adoperato. Nomi frequenti
per i diversi tipi di documenti di approvvigionamento sono: bando di gara, richiesta
d’offerta, richiesta di preventivo, notifica di offerta d’appalto, invito alla negoziazione
e risposta iniziale dell’appaltatore.
L’acquirente organizza i documenti di approvvigionamento in modo da favorire
una risposta rapida e completa da ciascun potenziale fornitore e in modo da facilitare
la valutazione delle offerte. I documenti comprendono una descrizione della forma di
risposta richiesta, il capitolato contrattuale ed eventuali indicazioni sulle disposizioni
contrattuali richieste (ad esempio, una copia di un modello del contratto, le clausole di
non divulgazione). In caso di appalti pubblici, una parte o tutto il contenuto e la
strutturazione dei documenti di approvvigionamento può essere definito dai
regolamenti vigenti.
La complessità e il livello di dettaglio dei documenti di approvvigionamento
deve essere congruente con il valore dell’acquisto pianificato e con i rischi ad esso
associati. I documenti di approvvigionamento devono essere abbastanza rigorosi da
garantire risposte omogenee e confrontabili, ma al contempo devono essere
sufficientemente flessibili da essere aperti ai suggerimenti da parte del fornitore di
metodi migliori per soddisfare i requisiti. A tal fine, è possibile invitare i fornitori a
presentare una proposta che risponda interamente alla richiesta di offerta e a fornire
un’eventuale soluzione alternativa in una proposta separata.
®
L’invio di una richiesta ai potenziali fornitori per invitarli a inoltrare una
proposta o un’offerta viene effettuato nel modo dettato dalle politiche
dell’organizzazione dell’acquirente, che possono prevedere la pubblicazione della
richiesta in quotidiani, riviste, pubblici registri o su Internet.
.2 Criteri di valutazione
I criteri di valutazione vengono elaborati e sviluppati con la finalità di classificare le
proposte o assegnare loro un punteggio. I criteri possono essere oggettivi (“Il project
manager proposto deve avere la certificazione Project Management Professional,
PMP®”) o soggettivi (“Il project manager proposto deve avere un’esperienza
precedente documentata di partecipazione a progetti simili”). I criteri di valutazione
vengono spesso inseriti nei documenti di approvvigionamento.
Se l’elemento oggetto dell’approvvigionamento è già disponibile da una serie di
fornitori ritenuti accettabili, questi criteri possono essere limitati al prezzo di acquisto
che, in questo caso, è composto sia dal prezzo dell’elemento che dalle spese collaterali
come la consegna.
Per supportare la valutazione di un prodotto o servizio più complesso, è
possibile identificare e documentare altri criteri di selezione, tra cui, per esempio:
• Comprensione dell’esigenza: fino a che punto la proposta del fornitore
risponde al capitolato contrattuale?
• Costo complessivo o del ciclo di vita: il fornitore selezionato offre il costo
totale più basso (costo di acquisto più costo di esercizio)?
• Capacità tecniche: il fornitore ha, o è presumibile che riesca ad acquisire, gli
skill e le conoscenze tecniche necessari?
• Approccio gestionale: il fornitore ha, o è presumibile che riesca a sviluppare,
processi e procedure di gestione che garantiscano il successo del progetto?
12
• Approccio tecnico: le metodologie, le tecniche, le soluzioni e i servizi proposti
dal fornitore soddisfano i requisiti della documentazione di approvvigionamento
o sono in grado di fornire risultati migliori rispetto a quelli previsti?
• Capacità finanziaria: il fornitore ha, o è presumibile che riesca ad ottenere, le
risorse finanziarie necessarie?
• Capacità produttiva e interesse: il fornitore è dotato della capacità e
dell’interesse atti a soddisfare i potenziali requisiti futuri?
• Dimensioni e tipologia delle attività: l’azienda del fornitore è del tipo o delle
dimensioni specificate? Per esempio, è una piccola azienda, un’azienda
appartenente all’imprenditoria femminile o una piccola azienda fondata per
persone portatrici di handicap, in base a quanto definito dall’acquirente o
stabilito dall’ente pubblico e imposto come condizione di idoneità per
l’assegnazione del contratto.
• Referenze: il fornitore è in grado di fornire delle referenze di clienti precedenti
come prova della propria esperienza lavorativa e della conformità ai requisiti
contrattuali?
• Diritti di proprietà intellettuale: il fornitore rivendica i diritti di proprietà
intellettuale per i processi o i servizi che intende utilizzare o per i prodotti che
deve realizzare nell’ambito del progetto?
• Diritti di proprietà: il fornitore rivendica i diritti di proprietà in merito ai
processi o ai servizi che intende utilizzare o ai prodotti che deve realizzare
nell’ambito del progetto?
®
.3 Capitolato contrattuale (aggiornamenti)

Durante lo sviluppo della documentazione dell’approvvigionamento si possono
identificare modifiche da apportare a uno o più capitolati contrattuali (paragrafo
12.1.3.2).
12.3 Richiesta di risposte dai fornitori

Il processo Richiesta di risposte dai fornitori consente di ricevere delle risposte, come
offerte e proposte, dai potenziali fornitori su come si possono soddisfare i requisiti del
progetto. Solitamente, la maggior parte dello sforzo in questo processo è a carico dei
fornitori e non incide direttamente a livello di costo sul progetto per l’acquirente.
Figura 12-5. Richiesta di risposte dai fornitori: Input, Strumenti e tecniche e Output
12.3.1 Richiesta di risposte dai fornitori: Input

Come asset dei processi organizzativi, alcune organizzazioni conservano degli elenchi
o degli archivi contenenti informazioni su fornitori potenziali e precedentemente
qualificati, ai quali è possibile richiedere un’offerta, una proposta o il preventivo per
un lavoro. Questi elenchi generalmente contengono informazioni su precedenti
esperienze significative e altre caratteristiche dei potenziali fornitori. Alcune
organizzazioni conservano un elenco dei fornitori preferiti che contiene soltanto i dati
sui fornitori che sono già stati selezionati in base a una determinata metodologia di
qualifica.
.3 Documenti di approvvigionamento
®
12.3.2 Richiesta di risposte dai fornitori: Strumenti e tecniche
.1 Conferenze degli offerenti
Le conferenze degli offerenti (anche denominate conferenze di appaltatori, conferenze
di fornitori e conferenze pre-offerta) sono riunioni tenute con i potenziali fornitori
prima della preparazione dell’offerta o della proposta. Tali conferenze consentono a
tutti i potenziali fornitori di comprendere chiaramente e integralmente l’oggetto
dell’approvvigionamento (ad esempio i requisiti tecnici o i requisiti contrattuali). Le
risposte alle domande che emergono possono essere incorporate nei documenti di
approvvigionamento sotto forma di rettifiche. Per poter produrre l’offerta migliore,
durante questa prima interazione tra le parti, a tutti i potenziali fornitori vengono
assegnate pari opportunità.
.2 Inserzioni
Gli elenchi dei potenziali fornitori già disponibili si possono estendere facendo
pubblicare delle inserzioni in pubblicazioni ad ampia divulgazione come i quotidiani o
in pubblicazioni di settore come le riviste specializzate. In alcune giurisdizioni la
pubblicazione di inserzioni per determinati oggetti di approvvigionamento è
obbligatoria. Nella maggior parte delle giurisdizioni i bandi di gara di enti pubblici
devono essere necessariamente pubblicati sulla stampa.
.3 Sviluppare un elenco di fornitori qualificati
Se gli elenchi e le informazioni necessari sono già disponibili, gli elenchi dei fornitori
qualificati si possono creare partendo da quelli interni dell’organizzazione. A
prescindere dal fatto che tali dati siano già presenti, il gruppo di progetto può anche
definire fonti proprie. Le informazioni di carattere generale sono facilmente reperibili 12
attraverso Internet, dagli elenchi pubblicati, dalle associazioni locali specializzate, dai
cataloghi commerciali e da altre fonti analoghe. Le informazioni sui fornitori specifici
possono richiedere uno sforzo maggiore, come le visite in sede o lo scambio di
informazioni con i clienti precedenti. Per stabilire se alcuni o tutti i fornitori potenziali
sono interessati ad essere nominati come fornitori potenziali qualificati, si possono
inviare loro i documenti di approvvigionamento (paragrafo 12.2.3.1).
12.3.3 Richiesta di risposte dai fornitori: Output

.1 Elenco di fornitori qualificati
Si definiscono qualificati quei fornitori a cui viene richiesto di inviare una proposta o
un preventivo.
.2 Insieme di documenti di approvvigionamento
L’insieme di documenti di approvvigionamento consta di una richiesta formale
preparata dall’acquirente e inviata a ciascun fornitore, che sarà la base su cui il
fornitore preparerà un’offerta per i prodotti, i servizi o i risultati richiesti e descritti
nella documentazione di approvvigionamento.
®
.3 Proposte
Le proposte sono documenti redatti dal fornitore che descrivono l’abilità e la volontà
dello stesso di fornire i prodotti, i servizi o i risultati richiesti e descritti nella
documentazione di approvvigionamento. Le proposte vengono stilate come richiesto
nei documenti di approvvigionamento e riflettono l’applicazione dei principi
contrattuali applicabili. La proposta del fornitore costituisce un’offerta formale e
legalmente valida in risposta a una richiesta effettuata dall’acquirente. Dopo l’invio
formale della proposta, l’acquirente chiede talvolta al fornitore di completare le
proprie proposte mediante una presentazione orale. Questo passaggio consente di
fornire ulteriori informazioni in merito al personale proposto dal fornitore e alla
proposta gestionale e tecnica; i dati aggiuntivi servono all’acquirente per la
valutazione della proposta del fornitore.
12.4 Selezionare i fornitori

Nel processo Selezionare i fornitori si ricevono le offerte o le proposte e si applicano
gli opportuni criteri di valutazione per selezionare uno o più fornitori ritenuti
qualificati e accettabili. Nel processo decisionale di selezione dei fornitori si prendono
in considerazione numerosi fattori, tra cui:
• Il prezzo e il costo possono essere il principale elemento determinante per un
elemento standard; ciononostante, il prezzo più basso proposto non sempre
rappresenta il costo più basso se poi il fornitore non è in grado di consegnare
tempestivamente i prodotti, i servizi o i risultati.
• Le proposte vengono spesso suddivise in sezioni tecniche (approccio) e
commerciali (prezzo), che vengono valutate separatamente. Talvolta nelle
proposte devono essere inserite, e quindi valutate, anche sezioni relative alla
gestione del progetto.
• Per i prodotti, i servizi e i risultati più critici potrebbero essere richieste più fonti
in modo da ridurre i rischi potenzialmente associati a questioni quali i tempi di
consegna e i requisiti di qualità. In questi casi occorre prendere in
considerazione il costo potenzialmente maggiore associato alla presenza di più
fornitori, tra cui il rischio di perdere eventuali sconti sulla quantità, nonché i
problemi legati alle sostituzioni e alla manutenzione.
Per la selezione dei fornitori, gli strumenti e le tecniche descritti in questa
sezione si possono usare separatamente o in abbinamento. Ad esempio, può essere
adottato un sistema di ponderazione per:
• Selezionare un singolo fornitore a cui verrà richiesto di sottoscrivere un
contratto standard.
• Stabilire una sequenza per la negoziazione in cui tutte le proposte sono
classificate tramite l’assegnazione di punteggi.
Se si stanno acquistando elementi di una certa importanza il processo
complessivo di richiesta e valutazione delle risposte dei fornitori può essere ripetuto.
In questo caso, la proposta preliminare è la base su cui si elabora un breve elenco di
fornitori qualificati. Solo ai fornitori dell’elenco si chiede quindi di presentare
proposte più dettagliate ed esaustive da analizzare in profondità.
®
Figura 12-6. Selezionare i fornitori: Input, Strumenti e tecniche e Output
12.4.1 Selezionare i fornitori: Input

Le organizzazioni coinvolte nell’approvvigionamento del progetto in genere hanno
politiche formali che guidano nella valutazione delle proposte.
.3 Criteri di valutazione
I criteri di valutazione (paragrafo 12.2.3.2) possono comprendere esempi di prodotti,
servizi o risultati realizzati in precedenza dal fornitore, che sono un efficace sistema di
valutazione delle capacità del fornitore e della qualità dei suoi prodotti. I criteri di 12
valutazione possono anche comprendere un’analisi delle collaborazioni precedenti del
fornitore con l’organizzazione acquirente o con terzi.
.4 Insieme di documenti di approvvigionamento
.5 Proposte
Le proposte dei fornitori preparate in risposta a un insieme di documenti di
approvvigionamento (paragrafo 12.3.3.3) costituiscono la base dell’insieme di
informazioni che l’organo responsabile della valutazione utilizzerà per selezionare
uno o più offerenti (fornitori).
.6 Elenco di fornitori qualificati
Il piano di Project Management costituisce il piano complessivo di gestione del
progetto e comprende i piani ausiliari e altri componenti. Nel corso del processo
Selezionare i fornitori, se sono disponibili, si possono utilizzare anche i seguenti
documenti:
• Registro dei rischi (paragrafo 11.5.1.2);
• Accordi contrattuali relativi ai rischi (paragrafo 11.5.3.3):
®
12.4.2 Selezionare i fornitori: Strumenti e tecniche

.1 Sistema di ponderazione
Il sistema di ponderazione è un metodo che consente di quantificare i dati qualitativi
per ridurre al minimo gli effetti dei pregiudizi personali sulla selezione dei fornitori.
La maggior parte di questi sistemi prevede l’assegnazione di un peso numerico a
ciascun criterio di valutazione, la classificazione dei potenziali fornitori rispetto ad
ogni criterio, la moltiplicazione del peso per la classificazione e la somma dei prodotti
risultanti per calcolare un punteggio complessivo.
.2 Stime indipendenti
Per molti elementi da acquistare, l’organizzazione che si occupa
dell’approvvigionamento può decidere di preparare o far preparare delle stime
indipendenti da utilizzare come verifica sui prezzi proposti. Questo tipo di stima viene
denominato anche stima di quanto “dovrebbe costare” l’elemento in questione. La
presenza di prezzi che si discostano molto dalle stime indipendenti può indicare che il
capitolato contrattuale non era adeguato, che il potenziale fornitore non ha compreso
correttamente il capitolato contrattuale o non ha risposto in modo completo oppure
che sono mutate le condizioni del mercato.
.3 Sistema di preselezione
Il sistema di preselezione comporta la determinazione del livello minimo per uno o
più criteri di valutazione e può avvalersi di un sistema di ponderazione e di stime
indipendenti. Ad esempio, un potenziale fornitore deve proporre un project manager
che abbia determinate qualifiche prima che venga preso in considerazione il resto
della sua proposta. I sistemi di preselezione si usano per stilare una classifica
ponderata, dal migliore al peggiore, dei fornitori che hanno presentato una proposta.
.4 Negoziazione del contratto
La negoziazione del contratto consente di chiarire la struttura e i requisiti del contratto
per raggiungere un accordo reciproco prima di passare alla sua stipulazione. Le
formulazioni finali del contratto riflettono tutti gli accordi raggiunti. I temi trattati
nella negoziazione di solito sono: responsabilità e autorità, termini e leggi di
riferimento, approcci di gestione tecnica e commerciale, diritti di proprietà,
finanziamenti, soluzioni tecniche, schedulazione complessiva, pagamenti e prezzi. La
negoziazione di un contratto termina con un documento, il contratto appunto, che può
essere firmato da una delle parti o da entrambe. Il contratto definitivo può essere
un’offerta riesaminata dal fornitore o una controfferta dell’acquirente.
In caso di elementi molto complessi, la negoziazione contrattuale può essere un
processo a sé con input (ad esempio, un elenco di questioni aperte) e output propri (ad
esempio, decisioni documentate). In caso di elementi semplici, i termini e le
condizioni del contratto possono essere fissi e non negoziabili e il fornitore può
semplicemente accettarli.
Il project manager potrebbe non essere il negoziatore principale del contratto. In
questo caso, insieme agli altri membri del gruppo di Project Management, può essere
presente in fase di negoziazione per fornire, se necessario, eventuali chiarimenti sui
requisiti di natura tecnica, di qualità e di gestione del progetto.
®
.5 Sistemi di classificazione dei fornitori
Molte organizzazioni sviluppano dei sistemi di classificazione dei fornitori utilizzando
informazioni come le prestazioni precedenti del fornitore, le valutazioni sulla qualità,
sui tempi di consegna e sul rispetto delle clausole contrattuali. La documentazione
sulla valutazione delle prestazioni di un fornitore generata durante il processo
Amministrazione del contratto per forniture precedenti, costituisce un’importante
fonte di informazioni. Per selezionare i fornitori si utilizzano questi sistemi di
classificazione assieme al sistema di preselezione delle proposte.
Per la valutazione delle proposte dei fornitori ci si avvale anche del parere di esperti.
La valutazione delle proposte viene effettuata da un gruppo di revisione
multidisciplinare esperto in tutte le aree coperte dai documenti di approvvigionamento
e dal contratto proposto. Le competenze possono essere in varie discipline funzionali,
tra cui l’ambito contrattuale, legale, finanziario, contabile, tecnico, progettuale, di
ricerca, di sviluppo, di vendita e di produzione.
.7 Tecniche di valutazione delle proposte
Esistono numerose tecniche per classificare e assegnare un punteggio alle proposte,
ma tutte si avvalgono in qualche modo del parere di esperti e di criteri di valutazione
(paragrafo 12.2.3.2); questi ultimi possono basarsi su componenti sia oggettivi che
soggettivi. Quando si utilizzano per una valutazione formalizzata delle proposte, i
criteri di valutazione vengono in genere ponderati gli uni rispetto agli altri. La
valutazione delle proposte utilizza gli input provenienti da più revisori nominati nel
corso del processo Selezionare i fornitori, poi vengono risolte le differenze
significative di punteggio e, alla fine, sulla base del punteggio ponderato assegnato a
ciascuna proposta, si può elaborare una valutazione globale e fare un confronto tra
12
tutte le proposte. Queste tecniche di valutazione delle proposte possono anche
avvalersi di un sistema di preselezione e utilizzare dati provenienti da un sistema di
classificazione dei fornitori.
12.4.3 Selezionare i fornitori: Output

.1 Fornitori selezionati
I fornitori si definiscono “selezionati” quando sono stati giudicati appartenenti a un
intervallo competitivo in base ai risultati ottenuti dalla valutazione della proposta o
dell’offerta e quando hanno negoziato una bozza del contratto, che sarà il contratto
effettivo al momento dell’assegnazione.
.2 Contratto
A ciascun fornitore selezionato viene aggiudicato il contratto. Il contratto può essere
sia un documento complesso, sia un semplice ordine di acquisto. A prescindere dalla
complessità del documento, il contratto è un accordo legalmente vincolante per
entrambe le parti che obbliga il fornitore a garantire i prodotti, i servizi o i risultati
specificati e obbliga l’acquirente a pagare il fornitore. Un contratto stabilisce una
relazione legale che è soggetta a ricorso legale presso un tribunale. I componenti
principali di un documento contrattuale in genere comprendono, a titolo
esemplificativo: indice, capitolato, schedulazione, periodo di esecuzione, ruoli e
responsabilità, prezzi e modalità di pagamento, adeguamenti di inflazione, criteri di
accettazione, garanzie, assistenza ai prodotti, limitazioni di responsabilità, compensi,
cauzioni, penali, incentivi, assicurazione, garanzie di esecuzione, approvazione di
subappaltatori, gestione delle richieste di modifica e un meccanismo di risoluzione del
contratto e di eventuali dispute.
®
.3 Piano di gestione del contratto

Per gli acquisti di dimensioni significative, viene predisposto anche un piano di
amministrazione del contratto sulla base delle clausole specificate nel contratto
dall’acquirente, per elementi come la documentazione, i requisiti di consegna, le
prestazioni, che devono essere rispettati sia dall’acquirente che dal fornitore. Il piano
descrive le attività di amministrazione del contratto per tutto il periodo di validità
dello stesso. Ogni piano di gestione del contratto costituisce una parte ausiliaria del
piano di Project Management.
Vengono documentate la quantità e la disponibilità delle risorse e le date prestabilite
di attività e di riposo di ciascuna risorsa specifica.
.5 Piano di gestione dell’approvvigionamento (aggiornamenti)
Il piano di gestione dell’approvvigionamento (paragrafo 12.1.3.1) viene aggiornato
per rispecchiare eventuali richieste di modifica approvate (paragrafo 4.4.1.4) che
influiscono sulla gestione dell’approvvigionamento.
Dal processo Selezionare i fornitori possono derivare delle richieste di modifiche da
apportare al piano di Project Management, ai relativi piani ausiliari e ad altri
componenti, come la schedulazione di progetto (paragrafo 6.5.3.1) e il piano di
gestione dell’approvvigionamento. Le modifiche richieste vengono elaborate per
l’analisi e la decisione mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
12.5 Amministrazione del contratto

Sia l’acquirente che il fornitore amministrano il contratto rispondendo ad obiettivi
simili. Ciascuna delle parti verifica la conformità propria e quella dell’altra parte ai
rispettivi obblighi contrattuali tutelando al tempo stesso i propri diritti legali. Il
processo Amministrazione del contratto verifica che le prestazioni del fornitore
rispondano ai requisiti contrattuali e che l’acquirente si comporti in conformità ai
termini stabiliti dal contratto. In caso di progetti di grandi dimensioni con più fornitori
di prodotti, servizi e risultati, un elemento fondamentale dell’amministrazione del
contratto è la gestione delle interfacce tra i vari fornitori.
La natura legale del rapporto contrattuale rende necessario che il gruppo di
Project Management sia pienamente consapevole delle implicazioni legali delle azioni
intraprese nell’amministrazione di qualsiasi contratto. A causa delle considerazioni di
tipo legale, molte organizzazioni considerano l’amministrazione del contratto come
una funzione amministrativa distinta dal resto dell’organizzazione del progetto. Anche
quando l’amministratore del contratto è un membro del gruppo di progetto, questi è
tipicamente tenuto a fare riferimento a un supervisore appartenente a un altro reparto.
Questa situazione si verifica per lo più quando la Performing Organization è anche il
fornitore del progetto per un cliente esterno.
L’Amministrazione del contratto prevede l’applicazione dei processi di Project
Management adeguati alle relazioni contrattuali e l’integrazione degli output ottenuti
da questi processi nella gestione complessiva del progetto. Quando sono coinvolti più
fornitori e più prodotti, servizi o risultati solitamente l’integrazione avviene a più
livelli. Di seguito vengono elencati, a titolo esemplificativo, i processi di Project
Management applicati.
®
• Dirigere e gestire l’esecuzione del progetto (paragrafo 4.4) per autorizzare il
lavoro del fornitore al momento giusto.
• Reporting delle prestazioni (paragrafo 10.3) per monitorare il costo, la
schedulazione e le prestazioni tecniche del fornitore.
• Esecuzione del controllo di qualità (paragrafo 8.3) per ispezionare e verificare
l’adeguatezza del prodotto del fornitore.
• Controllo integrato delle modifiche (paragrafo 4.6) per garantire che le
modifiche siano approvate correttamente e che tutte le parti interessate siano
informate di tali modifiche.
• Monitoraggio e controllo dei rischi (paragrafo 11.6) per garantire la riduzione
dei rischi.
L’amministrazione del contratto ha anche una componente di gestione
finanziaria che prevede il controllo dei pagamenti effettuati a favore del fornitore.
Tale controllo garantisce che i termini del pagamento definiti ai sensi del contratto
siano rispettati e che il corrispettivo del fornitore sia legato all’avanzamento del
lavoro, in base a quanto stabilito nel contratto.
Nel processo di Amministrazione del contratto, si esaminano e si documentano
le prestazioni attuali e precedenti del fornitore sulla base del contratto e delle azioni
correttive stabilite. Inoltre, la documentazione delle prestazioni rappresenta una base
utile per le relazioni future con il fornitore. La valutazione delle prestazioni del
fornitore da parte dell’acquirente viene innanzitutto eseguita per confermare la
competenza o la mancanza di competenze del fornitore, rispetto allo svolgimento di
lavori simili, sul progetto in corso o su altri progetti. Valutazioni simili vengono
inoltre svolte quando si rende necessario ratificare che un fornitore non sta rispettando
i propri obblighi contrattuali e quando l’acquirente prende in considerazione la
possibilità di procedere con azioni correttive. L’amministrazione del contratto prevede
12
la gestione dell’eventuale chiusura anticipata (paragrafo 12.6) del lavoro previsto dal
contratto (per motivi di convenienza di una delle parti o per inadempienza) in
conformità alla clausola di risoluzione inclusa nel contratto.
I contratti possono essere rettificati in qualsiasi momento prima della chiusura
mediante mutuo consenso, in conformità ai termini di controllo delle modifiche
previsti dal contratto. Tali rettifiche potrebbero non essere sempre ugualmente
vantaggiose per fornitore e acquirente.
Figura 12-7. Amministrazione del contratto: Input, Strumenti e tecniche e Output
®
12.5.1 Amministrazione del contratto: Input

.1 Contratto
.3 Fornitori selezionati
La documentazione sulle prestazioni del fornitore comprende:
• la documentazione tecnica sviluppata dal fornitore e altre informazioni sui
deliverable fornite come richiesto dai termini del contratto;
• i report sulle prestazioni del fornitore (paragrafo 10.3.3.1).
Le richieste di modifica approvate possono comprendere le modifiche ai termini e alle
condizioni del contratto, tra cui il capitolato contrattuale, i prezzi e la descrizione dei
prodotti, dei servizi o dei risultati da fornire. Tutte le modifiche vengono formalmente
documentate per iscritto e approvate prima di essere implementate. Le modifiche
discusse verbalmente ma non documentate non devono essere elaborate o
implementate.
Nel corso dell’esecuzione del progetto si raccolgono informazioni sullo stato di
avanzamento del lavoro (paragrafo 4.4.3.7), tra cui indicazioni su come vengono
soddisfatti gli standard di qualità, sui costi sostenuti o impegnati, sulle fatture dei
fornitori ecc. I report sulle prestazioni del fornitore indicano quali deliverable sono
stati completati e quali sono ancora da terminare. A cadenza regolare, il fornitore è
inoltre tenuto a inviare le fatture, denominate talvolta “note” o “richieste di
pagamento”, per richiedere il pagamento del lavoro svolto. Il contratto definisce i
requisiti di fatturazione e la necessaria documentazione di supporto.
12.5.2 Amministrazione del contratto: Strumenti e tecniche

.1 Sistema di controllo delle modifiche contrattuali
Il sistema di controllo delle modifiche contrattuali definisce il processo per applicare
variazioni al contratto e comprende i documenti, i sistemi di rilevamento, le procedure
per la risoluzione di eventuali dispute e i livelli di approvazione necessari per
l’autorizzazione delle modifiche. Il sistema di controllo delle modifiche contrattuali si
deve integrare con il sistema di controllo integrato delle modifiche.
®
.2 Verifica delle prestazioni condotta dall’acquirente
Una verifica delle prestazioni dell’approvvigionamento è un’analisi strutturata del
grado di avanzamento del lavoro del fornitore e del rispetto delle condizioni
contrattuali per quanto riguarda l’ambito del progetto, la qualità, i costi e la
schedulazione. Può prevedere l’esame della documentazione preparata dal fornitore,
le ispezioni dell’acquirente e le revisioni di qualità condotte durante l’esecuzione del
lavoro del fornitore. L’obiettivo di una verifica delle prestazioni è identificare i
successi e le carenze nelle prestazioni, l’avanzamento del lavoro rispetto al capitolato
contrattuale e le conformità contrattuali, per permettere all’acquirente di quantificare
la capacità o l’incapacità dimostrata dal fornitore nell’eseguire il lavoro.
.3 Ispezioni e revisioni
Le ispezioni e le revisioni (paragrafo 8.2.2.2), richieste dall’acquirente e supportate
dal fornitore in base a quanto definito nel contratto, possono essere condotte durante
l’esecuzione del progetto per identificare eventuali punti deboli nei processi di lavoro
o nei deliverable realizzati dal fornitore. Se autorizzati dal contratto, ai gruppi di
ispezione e di revisione può partecipare il personale dell’acquirente addetto
all’approvvigionamento.
.4 Reporting delle prestazioni
Il reporting delle prestazioni fornisce alla direzione informazioni sul livello di
efficacia con cui il fornitore sta raggiungendo gli obiettivi contrattuali. Il reporting
delle prestazioni del contratto si integra con il reporting delle prestazioni del progetto
.5 Sistema di pagamento
I pagamenti effettuati a favore del fornitore vengono solitamente gestiti dalla
contabilità fornitori dell’acquirente. Per progetti di grandi dimensioni, che prevedono
12
approvvigionamenti numerosi o complessi, il progetto può sviluppare un sistema di
pagamento proprio. In entrambi i casi, il sistema di pagamento comprende le
necessarie revisioni e approvazioni da parte del gruppo di Project Management; i
pagamenti vengono effettuati in conformità ai termini contrattuali (paragrafo
12.4.3.2).
.6 Amministrazione dei reclami
Le modifiche sulle quali vi è una contestazione e le modifiche che non sono
riconosciute come tali dal cliente sono le modifiche richieste (paragrafo 4.4.3.2) per le
quali l’acquirente e il fornitore non trovano accordo sul prezzo della modifica o
sull’esistenza stessa di una modifica. Le modifiche contestate sono anche denominate
“reclami”, “dispute” o “ricorsi”. I reclami vengono documentati, elaborati, monitorati
e gestiti per tutto il ciclo di vita del contratto, generalmente in conformità ai termini
del contratto. Se le parti non sono in grado di risolvere un reclamo, si potrebbe dover
ricorrere alle procedure di risoluzione delle dispute stabilite nel contratto. Queste
clausole contrattuali possono prevedere un arbitraggio o un contenzioso e possono
essere invocate prima o dopo la chiusura del contratto.
.7 Sistema di gestione degli archivi
Il sistema di gestione degli archivi è un insieme specifico di processi, di relative
funzioni di controllo e di strumenti di automazione raggruppati e combinati in un
unico elemento che fa parte del Sistema informativo di Project Management
(paragrafo 4.2.2.2). Il sistema di gestione degli archivi viene utilizzato dal project
manager per gestire la documentazione e gli archivi del contratto; consente infatti di
mantenere un indice dei documenti contrattuali e della corrispondenza e di recuperare
ed archiviare in modo semplice tale documentazione.
®
.8 Tecnologie informatiche
L’uso delle tecnologie informatiche e di comunicazione può migliorare l’efficienza e
l’efficacia dell’amministrazione del contratto poiché consente di automatizzare una
parte del sistema di gestione degli archivi, del sistema dei pagamenti,
dell’amministrazione dei reclami o del reporting delle prestazioni e permette lo
scambio elettronico di dati tra acquirente e fornitore.
12.5.3 Amministrazione del contratto: Output

La documentazione del contratto comprende, a titolo esemplificativo, il contratto
(paragrafo 12.4.3.2) e tutte le schedulazioni di supporto, le richieste di modifica al
contratto non approvate e quelle approvate. Fanno parte della documentazione del
contratto anche qualsiasi documentazione tecnica elaborata dal fornitore e altre
informazioni sullo stato di avanzamento del lavoro, come i deliverable, i report sulle
prestazioni del fornitore, le garanzie, i documenti finanziari, ivi incluse le fatture e i
registri dei pagamenti, e i risultati delle ispezioni relative al contratto.
Dal processo Amministrazione del contratto possono derivare delle modifiche
richieste da apportare al piano di Project Management e ai piani ausiliari, e ad altri
componenti, come la schedulazione di progetto (paragrafo 6.5.3.1) e il piano di
gestione dell’approvvigionamento (paragrafo 12.1.3.1). Le modifiche richieste
vengono elaborate ai fini dell’analisi e dell’approvazione mediante il processo di
Le modifiche richieste possono comprendere indicazioni fornite dall’acquirente
o azioni intraprese dal fornitore, che la controparte non accetta di considerare
modifiche al contratto. Poiché le modifiche di questo tipo possono essere contestate da
una delle parti e quindi generare un reclamo nei confronti dell’altra parte, occorre
identificarle e documentarle in modo univoco nella corrispondenza del progetto.
Un’azione correttiva consigliata è un’operazione che deve essere eseguita affinché il
fornitore si adegui ai termini del contratto.
• Corrispondenza: i termini e le condizioni del contratto richiedono spesso la
produzione di documentazione scritta per alcuni aspetti delle comunicazioni tra
acquirente e fornitore, come, ad esempio, per le segnalazioni di prestazioni non
soddisfacenti e le richieste di chiarimenti o di modifica al contratto. La
corrispondenza comprende anche i risultati delle revisioni e delle ispezioni
svolte dall’acquirente che indicano i punti deboli che il fornitore è tenuto a
correggere. Oltre a quanto specificato nel contratto per la documentazione, una
traccia scritta completa ed accurata di tutte le comunicazioni scritte e orali che
riguardano il contratto e di tutte le azioni intraprese e le decisioni prese sono
tenute dai contraenti.
• Piani e richieste di pagamento: presuppone che il progetto utilizzi un sistema
di pagamento esterno. Se il progetto dispone di un proprio sistema interno,
questo output è rappresentato semplicemente dai pagamenti.
®
• Documentazione sulla valutazione delle prestazioni del fornitore: questa
documentazione viene preparata dall’acquirente. Le valutazioni sulle prestazioni
documentano l’abilità del fornitore nel proseguire il lavoro previsto dall’attuale
contratto, oppure indicano se è opportuno assegnare al fornitore del lavoro su
progetti futuri o assegnano un punteggio alle prestazioni del fornitore nel lavoro
sul progetto in corso. Questi documenti costituiscono la base per una risoluzione
anticipata del contratto del fornitore o decidere come gestire le penalità, i
compensi o gli incentivi del contratto. I risultati ottenuti da queste valutazioni si
possono inserire negli elenchi dei fornitori qualificati (paragrafo 12.3.3.1).
• Piano di gestione dell’approvvigionamento: il piano di gestione
dell’approvvigionamento (paragrafo 12.1.3.1) viene aggiornato per rispecchiare
le eventuali richieste di modifica approvate che riguardano la gestione
dell’approvvigionamento.
• Piano di gestione del contratto: i piani di gestione del contratto (paragrafo
12.4.3.3) devono essere aggiornati per rispecchiare eventuali richieste di
modifica approvate che influenzano l’amministrazione del contratto.
12.6 Chiusura del contratto
Il processo Chiusura del contratto supporta il processo Chiudere il progetto (paragrafo
4.7), poiché prevede la verifica del livello di accettabilità di tutto il lavoro e dei
deliverable. La Chiusura del contratto comporta anche attività amministrative, come
l’aggiornamento degli archivi con i risultati finali allo scopo di poter utilizzare le
informazioni in futuro. La Chiusura del contratto riguarda qualsiasi contratto relativo
al progetto o a una fase di progetto. Nei progetti a più fasi, i termini contrattuali
possono essere validi soltanto per una determinata fase del progetto. In questi casi, il
12
processo Chiusura del contratto serve a chiudere i contratti validi per quella fase. I
reclami non risolti possono essere oggetto di controversia anche dopo la chiusura del
contratto. I termini e le condizioni del contratto possono contemplare specifiche
procedure di chiusura del contratto.
La risoluzione anticipata del contratto è un caso particolare di chiusura e può
essere il risultato di un mutuo accordo tra le parti o di un’inadempienza di una delle
parti. I diritti e le responsabilità delle parti in caso di risoluzione anticipata sono
regolamentati in una clausola di risoluzione contenuta nel contratto. In base a quanto
stabilito nel contratto, l’acquirente potrebbe avere il diritto di terminare l’intero
contratto o una parte del progetto, per motivi di convenienza, in qualsiasi momento.
Ciononostante, sempre in funzione di quanto stabilito nel contratto, l’acquirente
potrebbe dover risarcire il fornitore per eventuali attività di preparazione e per il
lavoro completato e accettato relativo alla parte conclusa del contratto.
®
Figura 12-8. Chiusura del contratto: Input, Strumenti e tecniche e Output
12.6.1 Chiusura del contratto: Input

.4 Procedura di chiusura del contratto
12.6.2 Chiusura del contratto: Strumenti e tecniche

.1 Revisioni dell’approvvigionamento
Una revisione dell’approvvigionamento è un’analisi strutturata del processo di
approvvigionamento a partire dal processo Pianificare gli acquisti (paragrafo 12.1)
fino all’Amministrazione del contratto (paragrafo 12.5). L’obiettivo della revisione
dell’approvvigionamento è identificare i successi e le carenze il cui riconoscimento
può essere utile nella preparazione o nell’amministrazione degli altri contratti di
approvvigionamento del progetto o di altri progetti, all’interno della Performing
Organization.
.2 Sistema di gestione degli archivi
®
12.6.3 Chiusura del contratto: Output
.1 Contratti chiusi
L’acquirente, in genere attraverso il proprio amministratore di contratto autorizzato,
fornisce al fornitore una formale notifica scritta relativa al completamento del
contratto. I requisiti di chiusura formale del contratto vengono in genere definiti nei
termini del contratto e compaiono anche nel piano di gestione del contratto, sempre
che sia stato redatto.
• Archivio del contratto: l’insieme completo e ordinato della documentazione
contrattuale, che comprende il contratto chiuso, viene preparato per essere
inserito negli archivi finali di progetto (paragrafo 4.7.3.4).
• Accettazione dei deliverable: l’acquirente, in genere attraverso il proprio
amministratore di contratto autorizzato, invia al fornitore una formale notifica
scritta dell’accettazione o del rifiuto dei deliverable. I requisiti di accettazione
formale dei deliverable e le modalità di gestione dei deliverable non conformi
sono in genere definiti nel contratto.
• Documentazione delle lesson learned: l’analisi delle lesson learned e i
suggerimenti per il miglioramento dei processi si sviluppano per la
pianificazione e l’implementazione di acquisti futuri.
12
®
Sezione IV
Appendici
Appendice A Modifiche alla terza edizione
Appendice B Evoluzione della Guida al Project

Management Body of Knowledge
di PMI
Appendice C Collaboratori e revisori della

Guida al PMBOK® – Terza edizione
Appendice D Estensioni delle aree applicative
Appendice E Ulteriori fonti di informazione sul

Project Management
Appendice F Riepilogo delle aree di conoscenza

di Project Management
APPENDICE A
Modifiche alla Terza edizione

Scopo di questa appendice è quello di descrivere in dettaglio le modifiche effettuate
all'edizione 2000 della Guida al Project Management Body of Knowledge (Guida al
PMBOK®) per creare la Terza edizione della Guida al PMBOK®.
Modifiche strutturali
Una delle modifiche più importanti apportate riguarda la struttura della Guida al
PMBOK®. La Terza edizione è infatti strutturata in modo da evidenziare l'importanza
dei gruppi di processi descritti in tabella 1, che contiene un confronto tra le modifiche.
Il capitolo 3 è stato rinominato “Processi di Project Management per un progetto” ed è
stato spostato dalla sezione I alla nuova sezione II, che ora si chiama “Lo standard per
il Project Management di un progetto.” Inoltre il capitolo 3 è stato molto cambiato in
modo da far risaltare l'importanza dei processi e degli input ed output descritti nel
capitolo, in quanto fondamenti dello standard per il Project Management di un singolo
progetto.
Sezioni dell'edizione 2000 Sezioni della Terza edizione
A
Sezione I - Elementi generali della gestione Sezione I - Il contesto del Project
di progetti Management
Capitoli 1, 2 e 3 Capitoli 1 e 2
Sezione II - Lo standard per il Project
Management di un progetto
Capitolo 3 - Processi di Project Management
per un progetto
Sezione II - Le aree di conoscenza della Sezione III - Aree di conoscenza di Project
gestione di progetti Management
Capitoli da 4 a 12 Capitoli da 4 a 12
Sezione III - Allegati Sezione IV - Appendici
Appendice D - Note Appendice D - Estensioni delle aree applicative
Appendice E - Estensioni relative alle aree di
applicazione
Sezione IV - Glossario e indice analitico Sezione V - Riferimenti, glossario e indice
Tabella 1: modifiche strutturali
®
Appendice A – Modifiche alla Terza edizione
Modifiche ai nomi dei processi

Nella Terza edizione sono stati aggiunti sette processi, tredici sono stati rinominati e
due eliminati; in totale quindi ci sono cinque processi in più.
I nomi dei processi nei vari capitoli dell'edizione 2000 della Guida al PMBOK®
hanno formati e stili diversi. Stili di nomi non uniformi possono creare confusione sia
a chi si avvicina per la prima volta al Project Management sia alle persone esperte. Per
esempio, i processi dell'area di conoscenza del contenuto sono Avvio, Pianificazione
del contenuto, Definizione del contenuto, Verifica del contenuto e Controllo delle
modifiche di contenuto. In alcuni casi si tratta di voci attive, in altri di participi
presenti. Questa differenza di stili ha l'effetto di non consentire al lettore di
determinare immediatamente se un termine riguarda un'attività (un processo) o un
deliverable (un prodotto del lavoro o manufatto). Il gruppo di progetto ha proposto di
cambiare nel formato verbo-oggetto tutti i nomi dei processi della terza edizione della
Guida al PMBOK®. Tuttavia, il PMI ha espresso la preoccupazione che si sarebbe
trattato di un cambiamento troppo sostanziale e ha quindi autorizzato per la Terza
edizione solo una modifica incrementale che interessa esclusivamente i nuovi processi
e pochi altri processi esistenti, per motivi che verranno spiegati nel corso di questa
appendice.
Eliminazione dei termini "Processo ausiliario" e "Processo

fondamentale"
Non vengono più utilizzati i termini “Processo ausiliario" e “Processo fondamentale".
Questi termini sono stati eliminati per garantire che tutti i processi di Project
Management nei rispettivi gruppi abbiano lo stesso grado di importanza. Tali processi
continuano a essere raggruppati all'interno dei gruppi di processi di Project
Management, come riportato in fig. 3-5 Gruppo di processi di avvio, fig. 3-6 Gruppo
di processi di pianificazione, fig. 3-7 Gruppo di processi di esecuzione, fig. 3-8
Gruppo di processi di monitoraggio e controllo e fig. 3-9 Gruppo di processi di
chiusura. I 44 processi di Project Management sono collegati sia ai gruppi di processi
di Project Management che alle aree di conoscenza, come illustrato nella tabella 3-45.
Stili di scrittura
Il team di progetto ha creato una guida stilistica che ha poi utilizzato per scrivere e
revisionare il testo. In tutto il documento è stata data molta importanza all'utilizzo del
linguaggio corrente e alla coerenza di contenuti, onde evitare che venissero usati stili
di scrittura differenti.
Nella traduzione italiana è stata interamente rivista la terminologia

rispetto alla traduzione originale dell'edizione 2000 della Guida al
PMBOK® . Una delle conseguenze è che alcuni nomi dei processi e delle
aree di conoscenza che nella versione inglese sono rimasti invariati,
nella versione italiana sono stati cambiati (con sinonimo o con i termini
inglesi originali) con l'obiettivo di fornire una traduzione il più possibile
vicina alla terminologia di Project Management corrente in Italia.
®
Modifiche al Capitolo 1: Introduzione
Le modifiche al capitolo 1 chiariscono e migliorano l'organizzazione all'interno del
capitolo stesso. Questo capitolo chiarisce le differenze tra un progetto e le attività
operative. Le modifiche forniscono definizioni standard di programma e di Program
Management, di portfolio e di gestione portfolio, e comprendono una descrizione più
dettagliata delle diverse varianti di Project Management Office (PMO). Le altre
modifiche contenute in questo capitolo sono:
• gli skill in materia di general management sono stati spostati nel capitolo 1;
• è stata aggiunta una sezione relativa alle varie aree di specializzazione
necessarie al gruppo di progetto.
Modifiche al Capitolo 2: Ciclo di vita del progetto e Organizzazione

Le modifiche al capitolo 2 chiariscono la distinzione tra cicli di vita dei progetti e
cicli di vita dei prodotti, spiegando inoltre le fasi di progetto. Viene fornita una
definizione di stakeholder rispetto al gruppo di progetto. Sono definiti il ruolo e le
responsabilità di un PMO nell'organizzazione e viene introdotto il concetto di un
sistema di Project Management.
Modifiche al Capitolo 3: Processi di Project Management per un

progetto
Il capitolo 3 è stato completamente riscritto e ampliato in modo da mettere meglio a
fuoco i gruppi di processi di Project Management e i processi all'interno delle aree di
conoscenza. Per chiarezza, il capitolo 3 è stato rinominato “Processi di Project
Management per un progetto” ed è stato spostato alla nuova sezione II, denominata
ora “Lo standard per il Project Management di un progetto.” Il capitolo 3 è stato
ampiamente aggiornato perché possa rappresentare uno standard per la gestione di un
singolo progetto e ora indica chiaramente i cinque gruppi di processi di Project
Management necessari, nonché i processi che li costituiscono. Al gruppo di processi
A
di avvio e al gruppo di processi di chiusura è stata data più importanza rispetto alle
edizioni precedenti. Il gruppo di processi di controllo è stato ampliato in modo da
contenere anche il monitoraggio ed è stato quindi rinominato “Gruppo di processi di
monitoraggio e controllo”. È stato aggiunto del materiale che chiarisce meglio la
differenza tra gruppi di processi di Project Management e fasi di progetto, perché a
volte queste due nozioni sono state erroneamente scambiate per la stessa cosa.
Modifiche al Capitolo 4: Gestione dell’integrazione di progetto

Il capitolo 4 è stato completamente riscritto ed è incentrato sull'integrazione dei
processi e delle attività di Project Management. Il capitolo descrive l'integrazione dei
processi dal punto di vista dei gruppi di processi di Project Management, e fornisce
una descrizione approfondita dell’integrazione sia tra i gruppi di processi di Project
Management che tra tutti i processi di Project Management. Nel capitolo sono stati
inclusi quattro nuovi processi e due sono stati rinominati.
®
• Il processo Sviluppare il Project Charter autorizza formalmente un progetto.

• Il processo Sviluppare la descrizione preliminare dell'ambito del progetto
fornisce una definizione ad alto livello dell'ambito.
• Il processo Sviluppare il piano di Project Management documenta le azioni
necessarie per la definizione, preparazione, integrazione e coordinazione di tutti
i piani sussidiari in un unico piano di Project Management.
• Il processo Dirigere e gestire l'esecuzione del progetto esegue il lavoro definito
nel piano di Project Management per raggiungere gli obiettivi del progetto.
• Il processo Monitorare e controllare il lavoro del progetto definisce i processi
per monitorare e controllare le attività di progetto necessarie per avviare,
pianificare, eseguire e chiudere un progetto.
• Il processo Chiudere il progetto completa tutte le attività di tutti i gruppi di
processi per poter chiudere formalmente il progetto.
Nella seguente tabella sono riassunte le modifiche apportate al capitolo 4:
4.1 Sviluppare il Project Charter
4.2 Sviluppare la descrizione preliminare
dell'ambito del progetto
4.1 Sviluppo del piano di progetto 4.3 Sviluppo del piano di Project Management
4.2 Esecuzione del piano di progetto 4.4 Dirigere e gestire l'esecuzione del progetto
4.5 Monitorare e controllare il lavoro del
progetto
4.3 Controllo integrato delle modifiche 4.6 Controllo integrato delle modifiche
4.7 Chiudere il progetto
Tabella 2: modifiche al capitolo 4
Modifiche al Capitolo 5: Gestione dell'ambito del progetto

Il capitolo 5 è stato modificato per chiarire quale ruolo abbia il piano di gestione
dell'ambito del progetto nello sviluppo della descrizione dell'ambito del progetto. Il
capitolo approfondisce l'argomento e chiarisce l'importanza di una WBS (Struttura di
scomposizione del lavoro) e contiene una nuova sezione dedicata alla creazione della
WBS. La sezione Avvio è stata riscritta completamente e spostata al capitolo 4. Nella
seguente tabella sono riassunte le modifiche apportate al capitolo 5:
5.1 Inizio ufficiale Riscritta e spostata al capitolo 4
5.2 Pianificazione del contenuto 5.1 Pianificazione dell'ambito
5.3 Definizione del contenuto 5.2 Descrizione delle specifiche
5.3 Creare la WBS
5.4 Verifica del contenuto 5.4 Verifica dell'ambito
5.5 Controllo delle modifiche di contenuto 5.5 Controllo dell'ambito
®
Modifiche al Capitolo 6: Gestione dei tempi di progetto
Nel capitolo 6 è stata inserita la sezione Pianificazione delle risorse, rinominata Stima
delle risorse delle attività. Sono state tolte varie figure (ad es.: PERT), mentre altre
sono state riadattate per chiarire meglio l'utilizzo e il significato degli strumenti (es:
diagramma a barre o di Gantt, diagramma delle milestone). Un’altra figura è stata poi
aggiunta per mostrare la differenza tra una schedulazione delle milestone, una
schedulazione di riepilogo e una schedulazione dettagliata. L'introduzione del capitolo
descrive la necessità di un piano di gestione della schedulazione, un componente
ausiliario del piano di Project Management. Sono state aggiunte delle sottosezioni che
forniscono informazioni relative alle stime dei costi del progetto, al livellamento delle
risorse e al reporting dell'avanzamento, per illustrare come questi processi influenzino
la schedulazione del progetto. Nella seguente tabella sono riassunte le modifiche
apportate al capitolo 6:
6.1 Definizione delle attività 6.1 Definizione delle attività
6.2 Ordine di esecuzione delle attività 6.2 Sequenzializzazione delle attività
6.3 Stima delle risorse delle attività
6.3 Stima della durata delle attività 6.4 Stima della durata delle attività
6.4 Sviluppo della schedulazione 6.5 Sviluppo della schedulazione
6.5 Controllo della schedulazione 6.6 Controllo della schedulazione
Modifiche al Capitolo 7: Gestione dei costi di progetto

I processi del capitolo 7 sono stati ampliati per integrare il budget di progetto
direttamente con la WBS e per coprire il controllo dei costi. Inoltre sono state eseguite
delle sostanziali modifiche a input, strumenti e tecniche. L'introduzione del capitolo A
riferisce della necessità di un piano di gestione dei costi, un componente ausiliario del
piano di Project Management. Il processo Pianificazione delle risorse è stato spostato
nel capitolo 6 e rinominato Stima delle risorse delle attività. Questo capitolo contiene
la maggioranza delle informazioni sul metodo dell'Earned Value. Nella seguente
tabella sono riassunte le modifiche apportate al capitolo 7:
7.1 Pianificazione delle risorse Spostato a Gestione dei tempi di progetto
(capitolo 6)
7.2 Stima dei costi 7.1 Stima dei costi
7.3 Allocazione dei costi 7.2 Allocazione dei costi
7.4 Controllo dei costi 7.3 Controllo dei costi
®
Modifiche al Capitolo 8: Gestione della qualità di progetto

Nel capitolo 8 i nomi di due processi di Project Management sono stati rivisti per
illustrare meglio le attività di quei processi. È stata data enfasi all'integrazione delle
attività di qualità con il processo di monitoraggio e controllo complessivo, secondo
quanto definito nel capitolo 4. Nella seguente tabella sono riassunte le modifiche
apportate al capitolo 8:
8.1 Pianificazione della qualità 8.1 Pianificazione della qualità
8.2 Assicurazione Qualità 8.2 Effettuare l'assicurazione qualità
8.3 Controllo Qualità 8.3 Esecuzione del controllo di qualità
Modifiche al Capitolo 9: Gestione delle risorse umane di progetto

Il capitolo 9 definisce alcuni aspetti della pianificazione delle risorse umane e del
piano di gestione del personale. Gestire il gruppo di progetto è stato aggiunto come
processo di monitoraggio e controllo. Sono state inoltre aggiunte alcune spiegazioni
chiave, tra cui organigrammi e descrizioni delle mansioni. Le figure di questo capitolo
ora illustrano le tecniche di Project Management più attuali, quali i gruppi virtuali, le
regole di base e i registri delle questioni. Nella seguente tabella sono riassunte le
modifiche apportate al capitolo 9:
9.1 Pianificazione organizzativa 9.1 Pianificazione delle risorse umane
9.2 Acquisizione del personale 9.2 Acquisire il gruppo di progetto
9.3 Sviluppo del gruppo di progetto 9.3 Sviluppare il gruppo di progetto
9.4 Gestire il gruppo di progetto
Modifiche al Capitolo 10: Gestione della comunicazione di progetto

Il capitolo 10 è stato aggiornato con l'aggiunta del processo Gestire gli stakeholder. Il
processo Gestire gli stakeholder gestisce le comunicazioni in modo da soddisfare le
esigenze e risolvere i problemi degli stakeholder di progetto. Nella seguente tabella
sono riassunte le modifiche apportate al capitolo 10:
10.1 Pianificazione delle comunicazioni 10.1 Pianificazione della comunicazione
10.2 Distribuzione delle informazioni 10.2 Distribuzione delle informazioni
10.3 Rendicontazione dei risultati 10.3 Reporting delle prestazioni
10.4 Chiusura amministrativa 10.4 Gestire gli stakeholder
®
Modifiche al Capitolo 11: Gestione dei rischi di progetto
Il capitolo 11 è stato aggiornato per aumentare l’enfasi sulle opportunità (rispetto alle
minacce). Nel capitolo sono state aggiunte diverse opzioni in base alla complessità del
progetto, sono state approfondite le attività di pianificazione della gestione dei rischi,
è stato inserito il registro dei rischi e, in generale, è stata aumentata l’integrazione con
gli altri processi. Nella seguente tabella sono riassunte le modifiche apportate al
capitolo 11:
11.1 Pianificazione della gestione del rischio 11.1 Pianificazione della gestione dei rischi
11.2 Identificazione del rischio 11.2 Identificare i rischi
11.3 Analisi qualitativa del rischio 11.3 Analisi qualitativa del rischio
11.4 Analisi quantitativa del rischio 11.4 Analisi quantitativa del rischio
11.5 Pianificazione della risposta al rischio 11.5 Pianificazione della risposta ai rischi
11.6 Monitoraggio e controllo del rischio 11.6 Monitoraggio e controllo dei rischi
Tabella 9: modifiche al capitolo 11 (nessuna modifica ai nomi)
Modifiche al Capitolo 12: Gestione dell'approvvigionamento di progetto

Il capitolo 12 è stato aggiornato per includere un uso coerente dei termini
“Acquirente” e “Fornitore”. Ora il capitolo chiarisce la differenza tra il gruppo di
progetto inteso come acquirente di prodotti e servizi e il fornitore di prodotti e servizi.
Contiene un processo sulla valutazione delle prestazioni del fornitore all’interno
dell'amministrazione del contratto e non riporta più le parole “procurare”, “invitare” e
“sollecitare” perché in varie zone del mondo questi termini hanno una connotazione
negativa. Nella seguente tabella sono riassunte le modifiche apportate al capitolo 12:
Sezioni dell'edizione 2000 Sezioni della Terza edizione A
12.1 Pianificazione dell’approvvigionamento 12.1 Pianificare gli acquisti
12.2 Pianificazione dell'invito 12.2 Pianificare le forniture
12.3 Invito 12.3 Richiesta di risposte dai fornitori
12.4 Selezione dei fornitori 12.4 Selezionare i fornitori
12.5 Amministrazione del contratto 12.5 Amministrazione del contratto
12.6 Chiusura di contratto 12.6 Chiusura del contratto
Glossario
Il glossario è stato ampliato e aggiornato in modo da:
• includere quei termini della Guida al PMBOK® che richiedevano una
spiegazione ai fini di una corretta comprensione dei contenuti del documento;
• chiarire il significato e migliorare la qualità e correttezza di tutte le traduzioni;
• eliminare i termini non utilizzati nella Terza edizione della Guida al PMBOK®.
®
APPENDICE B
Evoluzione della Guida al Project

Management Body of Knowledge del PMI
Nota del traduttore:
La Guida al Project Management Body of Knowledge del PMI è stata tradotta in
italiano per la prima volta nell’edizione 2000. Nei paragrafi che seguono, quando i
nomi dei processi si riferiscono alle edizioni precedenti a quella del 2000 compaiono
in inglese, mentre quando si riferiscono alle edizioni successive sono tradotti. Nel
paragrafo relativo all’edizione 2000 sono stati usati i nomi dei processi della prima
edizione italiana, anche se poi in questa edizione alcuni nomi sono stati rivisti
B.1 Sviluppo iniziale

Il PMI (Project Management Institute) è stato fondato nel 1969 in base alla premessa che
esistevano numerose pratiche comuni di gestione progetti in aree applicative molto
diverse, come il settore edile e il settore farmaceutico. Ai tempi dei seminari e del
simposio tenuti da PMI nel 1976 a Montreal, si iniziò a discutere ampiamente dell'idea di
documentare come standard queste pratiche comuni. Questo, a sua volta, fece in modo
che il Project Management venisse riconosciuto come una professione a sé stante. B
Tuttavia, fu soltanto nel 1981 che il Board of Directors del PMI approvò un
progetto per lo sviluppo delle procedure e dei concetti necessari a supportare la
professione del Project Management. La proposta di progetto copriva tre aree
principali:
• le caratteristiche distintive di un professionista abilitato (etica);
• il contenuto e la struttura del corpo di conoscenze della professione (standard);
• il riconoscimento dei risultati professionali raggiunti (accreditamento).
Il gruppo di progetto divenne quindi noto come Ethics, Standards, and
Accreditation (ESA) Management Group. L’ESA Management Group era composto
dai seguenti membri:
Matthew H. Parry, Chair David C. Aird Frederick R. Fisher
David Haeney Harvey Kolodney Charles E. Oliver
William H. Robinson Douglas J. Ronson Paul Sims
Eric W. Smythe
®
Appendice B − Evoluzione della Guida al Project Management Body of Knowledge di PMI
Il gruppo era supportato da oltre venticinque volontari che appartenevano a diversi

chapter locali. La dichiarazione “Ethics” fu elaborata e inviata da una commissione di
Washington, DC, presieduta da Lew Ireland. La dichiarazione “Time Management” fu
redatta durante numerose riunioni di un gruppo del Southern Ontario, comprendente
Dave MacDonald, Dave Norman, Bob Spence, Bob Hall e Matt Parry. La dichiarazione
“Cost Management” fu il risultato di molte riunioni tenute all'interno dell'ufficio costi di
Stelco, sotto la direzione di Dave Haeney e Larry Harrison. Altre dichiarazioni furono
sviluppate dall’ESA Management Group. John Adams e il suo gruppo della Western
Carolina University si occuparono della questione dell’accreditamento, e stilarono delle
direttive in merito, che poi confluirono nel programma di certificazione Project
Management Professional (PMP®), sotto la guida di Dean Martin.
I risultati ottenuti dal progetto ESA furono pubblicati in una relazione speciale
sul Project Management Journal nell'agosto del 1983. La relazione comprendeva le
seguenti sezioni:
• Code of Ethics, il codice etico, più una procedura di applicazione del codice.
• Baseline degli standard composta da sei aree di conoscenza principali: Scope
Management, Cost Management, Time Management, Quality Management,
Human Resources Management, e Communications Management.
• Direttive sia per l'accreditamento (riconoscimento della qualità dei programmi
forniti da organizzazioni formative) che per la certificazione (riconoscimento
delle qualifiche professionali degli individui).
Questa relazione è stata successivamente utilizzata come base per i primi
programmi di accreditamento e certificazione del PMI. Nel 1983 è stato accreditato il
primo master in Project Management alla Western Carolina University, mentre le
prime certificazioni PMP sono state assegnate nel 1984.
B.2 Aggiornamento del 1986-87

La pubblicazione della relazione ESA sulla baseline suscitò una discussione vivace
all'interno del PMI in merito all'adeguatezza degli standard. Nel 1984, il Board of
Directors del PMI approvò un secondo progetto sugli standard “per acquisire le
conoscenze applicate al Project Management… all'interno della struttura ESA
esistente”. Furono nominate sei commissioni, ognuna delle quali responsabile di una
delle sei aree di conoscenza identificate. In aggiunta, si organizzò un workshop
nell'ambito dei seminari e del simposio annuali tenuti da PMI nel 1985.
Come risultato di tale impegno, il Board of Directors del PMI approvò in linea
di principio un documento rivisto che fu pubblicato per eventuali commenti
nell'agosto del 1986 sul Project Management Journal. Qui di seguito sono riportati i
principali collaboratori a quella nuova versione.
R. Max Wideman, Chair John R. Adams, Chair
(durante lo sviluppo) (alla pubblicazione)
Joseph R. Beck Peter Bibbes Jim Blethen
Richard Cockfield Peggy Day William Dixon
Peter C. Georgas Shirl Holingsworth William Kane
Colin Morris Joe Muhlberger Philip Nunn
Pat Patrick David Pym Linn C. Stuckenbruck
George Vallance Larry C. Woolslager Shakir Zuberi
®
Oltre ad avere ampliato e riorganizzato il materiale originale, il documento
rivisto conteneva tre nuove sezioni:
• La sezione “Project Management Framework” fu aggiunta per descrivere le
relazioni tra il progetto e il suo ambiente esterno e tra il Project Management e il
general management.
• Risk Management fu inserita come area di conoscenza separata per fornire una
trattazione più approfondita dell'argomento.
• Contract/Procurement Management fu inserita come area di conoscenza separata
per fornire una trattazione più approfondita dell'argomento.
In seguito, il materiale fu sottoposto a una serie di modifiche e correzioni
editoriali, fino all'approvazione da parte del Board of Directors del PMI avvenuta nel
marzo 1987. Il manoscritto finale fu pubblicato nell'agosto del 1987 sotto forma di un
documento distinto intitolato “Project Management Body of Knowledge”.
B.3 Aggiornamento del 1996

La discussione sulla forma, il contenuto e la struttura corretti da dare al documento
degli standard principali del PMI non cessò neanche dopo la pubblicazione della
versione del 1987. Nell'agosto del 1991, il Director of Standards del PMI, Alan
Stretton, diede inizio a un progetto per aggiornare il documento con i commenti
ricevuti dai vari membri. Il documento rivisto fu sviluppato nel corso di numerosi
anni, passando attraverso una serie di bozze di lavoro che furono fatte circolare su
ampia scala e numerosi workshop organizzati in occasione dei seminari e simposi
PMI tenuti a Dallas, Pittsburgh e San Diego.
Nell'agosto del 1994, il PMI Standards Committee pubblicò una bozza
conclusiva del documento che fu distribuita per eventuali commenti a tutti i 10.000
membri del PMI e ad oltre venti altre associazioni professionali e tecniche.
La pubblicazione di “A Guide to the Project Management Body of Knowledge
(PMBOK® Guide)” avvenuta nel 1996 siglò il completamento del progetto avviato nel
1991. I collaboratori e i revisori di questa versione sono elencati più avanti. Viene
fornito anche un riepilogo delle differenze tra il documento del 1987 e quello del
B
1996, inserito nella prefazione dell'edizione del 1996.
Questo ultimo documento sostituì l'originario “Project Management Body of
Knowledge (PMBOK®)” pubblicato nel 1987. A sostegno degli utenti del documento
del 1996, probabilmente già abituati alla versione precedente, qui di seguito vengono
riepilogate le principali differenze tra i due.
1. È stato cambiato il titolo per sottolineare che questo documento non è il
Project Management Body of Knowledge, cioè il corpo di conoscenze del
Project Management. Il documento del 1987 definì il Project Management
Body of Knowledge come “tutti gli argomenti, le aree di interesse e i processi
intellettuali che sono coinvolti nell'applicazione ai progetti di sani principi
gestionali.” È evidente che un solo documento non potrà mai contenere
l'intero corpo di conoscenze del Project Management.
®
2. La sezione “Framework” è stata completamente riscritta. La nuova sezione è

composta dai seguenti tre capitoli:
• “Introduction”: stabilisce l'obiettivo del documento e definisce in modo
approfondito i termini “project” e “Project Management”.
• “The Project Management Context”: copre il contesto nel quale i progetti
vanno applicati, come il ciclo di vita del progetto, le prospettive degli
stakeholder, le influenze esterne e gli skill principali in materia di general
management.
• “Project Management Processes”: descrive le correlazioni tra i vari elementi
del Project Management.
3. È stata elaborata una definizione rivista di progetto, poiché si era reso
necessario disporre di una definizione che fosse sia inclusiva (“non dovrebbe
essere possibile identificare alcuna attività ritenuta un progetto che non
risponda ai criteri della definizione”) sia esclusiva (“non dovrebbe essere
possibile descrivere alcuna attività che risponda alla definizione e non sia
comunemente ritenuta un progetto”). Sono state riviste numerose definizioni
di progetto fornite dalla letteratura esistente e nessuna di queste sembrava
completamente soddisfacente. La nuova definizione si basa sulle
caratteristiche uniche di un progetto: un progetto è un impegno temporaneo
intrapreso allo scopo di creare un prodotto o un servizio unici.
4. È stata elaborata una visione rivista del ciclo di vita del progetto. Il
documento del 1987 definiva le fasi di progetto come delle suddivisioni del
ciclo di vita del progetto. Questa relazione è stata riorganizzata e il ciclo di
vita del progetto è stato definito come raccolta di fasi il cui numero e i cui
nomi dipendono dalle esigenze di controllo della Performing Organization.
5. Sono stati cambiati i nomi delle sezioni principali, come il passaggio da
“Function” a “Knowledge Area”. Il termine “funzione” infatti è stato spesso
confuso con un elemento dell'organizzazione funzionale. La modifica del
nome dovrebbe eliminare qualsiasi incomprensione.
6. È stata formalmente riconosciuta l'esistenza di una nona area di conoscenza.
Per un certo lasso di tempo si è concordato nel ritenere che il Project
Management fosse un processo integrativo. Il capitolo 4, “Project Integration
Management “, riconosce l'importanza di questo argomento.
7. È stata aggiunta la parola “project” al titolo di ciascuna area di conoscenza.
Sebbene questa aggiunta possa suonare ridondante, consente di chiarire
l'ambito del documento. Ad esempio, “Project Human Resource
Management” riguarda solo gli aspetti della gestione delle risorse umane che
sono specifici o quasi specifici del contesto di progetto.
8. Le aree di conoscenza sono state descritte in base ai processi che le
compongono. La ricerca di un metodo omogeneo di rappresentazione ha
portato alla totale riorganizzazione del documento del 1987, che è stato
suddiviso in 37 processi di Project Management. Ogni processo è stato
descritto in termini di input, output e strumenti e tecniche. Gli input e gli
output sono documenti (ad es. uno “scope statement”) o voci documentabili
(ad es. relazioni di dipendenza tra attività). Gli strumenti e le tecniche sono i
meccanismi applicati agli input per creare gli output. In aggiunta alla sua
semplicità di base, questo approccio offre una serie di altri vantaggi:
®
• Enfatizza le interazioni tra le varie aree di conoscenza. Gli output derivanti da
un processo vengono utilizzati come input per un altro processo.
• La struttura è flessibile e solida. È possibile apportare delle modifiche alle
conoscenze e alle pratiche semplicemente aggiungendo un nuovo processo,
ristrutturando la sequenza dei processi, suddividendo i processi o
aggiungendo del materiale descrittivo all'interno di un processo.
• I processi sono il cuore anche di altri standard. Ad esempio, gli standard ISO
(la serie ISO 9000) si basano sull'identificazione dei processi aziendali.
9. Sono state aggiunte delle illustrazioni. Quando si parla di WBS, di reticoli e di
curve a S, un’immagine vale più di mille parole.
10. Il documento è stato riorganizzato in modo sostanziale. La seguente tabella
fornisce un confronto tra le intestazioni principali del documento del 1987 e le
intestazioni corrispondenti e/o le fonti di contenuto della versione del 1996.
Numero e nome del 1987 Numero e nome del 1996
0. PMBOK® Standards B. Evolution of PMI’s A Guide to the
Project Management Body of
Knowledge
1. Framework: The Rationale 1. Introduction (definizioni di base)
2. The Project Context (cicli di vita)
2. Framework: An Overview 1. Varie parti
2. Varie parti
3. Varie parti
3. Framework: An Integrative Model 3. Project Management Processes
4. Project Integration Management
4. Glossary of General Terms IV. Glossary
A. Scope Management 5. Project Scope Management
B. Quality Management 8. Project Quality Management
C.
D.
Time Management
Cost Management
6. Project Time Management
7. Project Cost Management
B
E. Risk Management 11. Project Risk Management
F. Human Resource Management 9. Project Human Resource
Management
G. Contract/Procurement Management 12. Project Procurement Management
H. Communications Management 10. Project Communications
Management
11. È stato rimosso il termine “classificare” dall'elenco degli obiettivi. Sia il
documento del 1996 che la versione del 1987 forniscono una struttura per
l'organizzazione della conoscenza di Project Management, ma nessuna delle
due si è rivelata particolarmente efficace come strumento di classificazione.
Innanzitutto, gli argomenti inclusi non sono esaustivi, non comprendono
infatti pratiche innovative o insolite. Inoltre, molti elementi sono rilevanti in
più di un’area di conoscenza o in più processi, per cui le categorie non sono
uniche.
®
Le persone riportate di seguito, elencate anche nell'appendice C del documento

del 1996, hanno contribuito in modi diversi alle varie bozze che hanno portato al
documento del 1996. Il PMI è grato a tali persone per il supporto che hanno fornito.
Standards Committee
Le persone riportate di seguito hanno fatto parte della PMI Standards Committee
durante lo sviluppo dell'aggiornamento del 1996 al documento PMBOK®.
William R. Duncan Frederick Ayer Cynthia Berg
Mark Burgess Helen Cooke Judy Doll
Drew Fetters Brian Fletcher Earl Glenwright
Eric Jenett Deborah O’Bray Diane Quinn
Anthony Rizzotto Alan Stretton Douglas E. Tryloff
Collaboratori
In aggiunta ai membri della Standards Committee, le seguenti persone hanno fornito
testi originali o concetti chiave per una o più sezioni dei capitoli indicati.
John Adams (capitolo 3) Keely Brunner (capitolo 7)
Louis J. Cabano (capitolo 5) David Curling (capitolo 12)
Douglas Gordon (capitolo 7) David T. Hulett (capitolo 11)
Edward Ionata (capitolo 10) John M. Nevison (capitolo 9)
Hadley Reynolds (capitolo 2) Agnes Salvo (capitolo 11)
W. Stephen Sawle (capitolo 5) Leonard Stolba (capitolo 8)
Ahmet Taspinar (capitolo 6) Francis M. Webster Jr. (capitolo 1)
Revisori
Oltre alla Standards Committee e ai collaboratori, le persone e le organizzazioni riportate
di seguito hanno contribuito fornendo dei commenti a varie versioni del documento del
1996.
Edward L. Averill C. “Fred” Baker F. J. “Bud” Baker
Tom Belanger John A. Bing Brian Bock
Paul Bosakowski Dorothy J. Burton Kim Colenso
Samuel K. Collier Karen Condos-Alfonsi E. J. Coyle
Darlene Crane Russ Darnall Maureen Dougherty
John J. Downing Daniel D. Dudek Lawrence East
Quentin W. Fleming Rick Fletcher Greg Githens
Leo Giulianeti Martha D. Hammonds Abdulrazak Hajibrahim
G. Alan Hellawell Paul Hinkley Wayne L. Hinthorn
Mark E. Hodson Lew Ireland Elvin Isgrig
Murray Janzen Frank Jenes Walter Karpowski
William F. Kerrigan Harold Kerzner Robert L. Kimmons
Richard King J. D. “Kaay” Koch Lauri Koskela
Richard E. Little Lyle W. Lockwood Lawrence Mack
Christopher Madigan Michael L. McCauley Hugh McLaughlin
®
Frank McNeely Pierre Menard Rick Michaels
Raymond Miller Alan Minson Colin Morris
R. Bruce Morris David J. Mueller Gary Nelson
John P. Nolan Louise C. Novakowski James O’Brien
JoAnn C. Osmer Jon V. Palmquist Matthew Parry
John G. Phippen Hans E. Picard Serge Y. Piotte
PMI Houston Chapter PMI Manitoba Chapter PMI New Zealand Chapter
Charles J. Pospisil Janice Y. Preston Mark T. Price
Christopher Quaife Peter E. Quinn Steven F. Ritter
William S. Ruggles Ralph B. Sackman Alice Sapienza
Darryl M. Selleck Melvin Silverman Roy Smith
Craig T. Stone Hiroshi Tanaka Robert Templeton
Dick Thiel Saul Thomashow J. Tidhar
Janet Toepfer Vijay K. Verma Alex Walton
Jack Way R. Max Wideman Rebecca Winston
Hugh M. Woodward Robert Youker Shakir H. Zuberi
Dirk Zwart
Personale addetto alla produzione

È doveroso rivolgere una menzione speciale ai seguenti dipendenti del settore PMI
Communications.
Jeannette M. Cabanis, Editor, Book Division Misty N. Dillard, Administrative Assistant
Linda V. Gillman, Office Administrator Bobby R. Hensley, Publications Coordinator
Jonathan Hicks, Systems Administrator Sandy Jenkins, Associate Editor
Dewey L. Messer, Managing Editor Danell Moses, Marketing Promotion Coordinator
Mark S. Parker, Production Coordinator Shirley B. Parker, Business/Marketing Manager
Melissa Pendergast, Information Services
Coordinator
James S. Pennypacker, Publisher/Editor-In-Chief B
Michelle Triggs, Graphic Designer Lisa Woodring, Administrative Assistant
®
B.4 Aggiornamento del 2000

Questo documento sostituisce la “A Guide to the Project Management Body of
Knowledge (PMBOK® Guide)” del Project Management Institute (PMI®) pubblicata
nel 1996.
Di seguito viene illustrato l'ambito del progetto usando come punto di partenza
l’edizione del 1996.
• Aggiungere del materiale nuovo, che rifletta la crescita delle conoscenze e delle
pratiche nel campo del Project Management riunendo pratiche, strumenti,
tecniche e altri elementi di rilievo che sono comunemente accettati. Per
“accettati” si intende applicabili alla maggior parte dei progetti nella maggior
parte delle situazioni e caratterizzati da un ampio consenso sul loro valore e
sulla loro utilità.
• Aggiungere chiarimenti al testo e alle figure per rendere il testo di più facile
consultazione per i lettori.
• Correggere gli errori riscontrati nel documento precedente.
Di seguito vengono illustrate le modifiche principali.principali:
1. In tutto il documento, è stato chiarito il fatto che i progetti rispondono a dei
requisiti, che emergono da necessità, desideri o aspettative.
2. In tutto il documento, sono stati rafforzati i collegamenti alla strategia
dell'organizzazione.
3. Nella sezione 1.2.3 è stata data maggiore enfasi all'elaborazione progressiva.
4. Nella sezione 2.3.4 è stato riconosciuto il ruolo del Project Office.
5. Nella sezione 2.5.4 sono stati aggiunti dei riferimenti al Project Management
relativi alle economie in via di sviluppo e agli impatti a livello sociale,
economico e ambientale.
6. È stato descritto più approfonditamente il metodo dell'Earned Value nel
capitolo 4 (Gestione dell'integrazione di progetto), nel capitolo 7 (Gestione
dei costi di progetto) e nel capitolo 10 (Gestione della comunicazione di
progetto).
7. Il capitolo 11 (Gestione dei rischi di progetto) è stato completamente riscritto.
Ora il capitolo contiene sei processi, invece dei quattro precedenti. I sei
processi sono 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.
8. Il processo Verifica dell'ambito è stato spostato da processo di esecuzione a
processo di controllo.
9. Il nome del processo 4.3 è stato cambiato da Overall Change Control
(controllo globale delle modifiche) a Controllo integrato delle modifiche per
sottolineare l'importanza del controllo delle modifiche per tutta la durata del
progetto.
10. Nella figura 3-9 è stato aggiunto un diagramma che riproduce i 39 processi di
Project Management a fronte dei cinque gruppi di processi di Project
Management e delle nove aree di conoscenza di Project Management.
11. È stata standardizzata la terminologia per tutto il documento, passando da
“venditore” a “fornitore.”
®
12. Sono stati aggiunti numerosi strumenti e tecniche.
Capitolo 4: Gestione Metodo dell'Earned Value (EVM)
dell’integrazione di progetto Azione preventiva
Capitolo 5: Gestione del contenuto Aggiornamenti dell’enunciazione
di progetto del contenuto
Piano di progetto
Linea di base corretta
Capitolo 6: Gestione dei tempi di Durate su base quantitativa
progetto Tempo di riserva (Contingency)
Struttura di codifica
Analisi degli scostamenti
Milestone
Attributi delle attività
Strumenti informatici
Capitolo 7: Gestione dei costi di Stime pubblicate
progetto Metodo del valore assorbito (EVM)
Capitolo 8: Gestione della qualità Costo della qualità
di progetto
Capitolo 10: Gestione delle Rapporti di progetto
comunicazioni di progetto Presentazioni di progetto
Chiusura di progetto
PMI Project Management Standards Program Member Advisory Group

Le persone elencate di seguito hanno fatto parte del PMI Standards Program Member
Advisory Group durante lo sviluppo di questa sezione della Guida al Project
Management Body of Knowledge (Guida al PMBOK®):
George Belev Cynthia A. Berg, PMP Sergio Coronado Arrechedera
Judith A. Doll, PMP J. Brian Hobbs, PMP David Hotchkiss, PMP
B
Gruppo di progetto responsabile degli aggiornamenti alla Guida al
PMBOK®
Le persone elencate di seguito hanno fatto parte del gruppo di progetto dell'edizione
2000 della Guida al PMBOK®, sotto la guida di Cynthia A. Berg, PMP, come project
manager:
Cynthia A. Berg, PMP Judith A. Doll, PMP Daniel Dudek, PMP
Quentin Fleming Greg Githens, PMP Earl Glenwright
David T. Hulett, PhD Gregory J. Skulmoski
®
Collaboratori
In aggiunta ai partecipanti al PMI Standards Program Member Advisory Group e al
gruppo di progetto responsabile della Guida al PMBOK®, le persone elencate di
seguito hanno fornito testi originali o concetti chiave per una o più sezioni incluse nei
capitoli indicati. Inoltre, il PMI Risk Management Specific Interest Group ha guidato
la riscrittura del capitolo 11, Gestione dei rischi di progetto.
Alfredo del Caño (capitolo 11) Quentin Fleming (capitoli 4 e 12)
Roger Graves (capitolo 11) David Hillson (capitolo 11)
David Hulett (capitolo 11) Sam Lane (capitolo 11)
Janice Preston (capitolo 11) Stephen Reed (capitolo 11)
David Shuster (capitolo 8) Ed Smith (capitolo 11)
Mike Wakshull (capitolo 11) Robert Youker (numerosi capitoli)
Revisori
In aggiunta al PMI Standards Program Member Advisory Group, al gruppo di
progetto responsabile della Guida al PMBOK® e ai collaboratori, le persone elencate
di seguito hanno fornito commenti alla bozza conclusiva del presente documento:
Muhamed Abdomerovic, PMP, D. Eng. Yassir Afaneh
Frank Allen, PMP Jon D. Allen, PMP
MaryGrace Allenchey, PMP Robert A. Andrejko, PMP
Ichizo Aoki Paul C. Aspinwall
Ronald Auffrédou, PMP Edward Averill, PMP
Frederick L. Ayer, PMP William W. Bahnmaier, PMP
A. C. “Fred” Baker, PMP Carole J. Bass, PMP
Berndt Bellman Sally Bernstein, PMP
Nigel Blampied, PE, PMP John Blatta
Patrick Brown, PMP Chris Cartwright, PMP
Bruce C. Chadbourne, PMP Michael T. Clark, PMP
Raymond C. Clark, PE Elizabeth Clarke
David Coates, PMP Kim Colenso, PMP
Edmund H. Conrow, PMP Kenneth G. Cooper
John Cornman, PMP Richard F. Cowan, PMP
Kevin Daly, PMP Mario Damiani, PMP
Thomas Diethelm, PMP David M. Drevinsky, PMP
Frank D. Einhorn, PMP Edward Fern, PMP
Christian Frankenberg, PMP Scott D. Freauf, PMP
Jean-Luc Frere, PMP Ichiro Fujita, PMP
Chikako Futamura, PMP Serge Garon, PEng, PMP
Brian L. Garrison, PMP Eric Glover
Peter Bryan Goldsbury Michael Goodman, PMP
®
Jean Gouix, PMP Alexander Grassi Sr., PMP
Franz X. Hake Peter Heffron
Chris Herbert, PMP Dr. David Hillson, PMP, FAPM
J. Brian Hobbs, PMP Marion Diane Holbrook
Robin Hornby Bill Hubbard
Charles L. Hunt Thomas P. Hurley, PMP
George Jackelen Angyan P. Jagathnarayanan
Elden F. Jones II, PMP, CMII Sada Joshi, PMP
Lewis Kana, PMP Subramaniam Kandaswamy, PhD, PMP
Ronald L. Kempf, PMP Robert Dohn Kissinger, PhD, PMP
Kurt V. Kloecker Jan Kristrom
Blase Kwok, PMP Lawrence P. Leach
Philip A. Lindeman Gábor Lipi
Lyle W. Lockwood, PMP J. W. Lowthian, PMP
Arif Mahmood, PMP James Martin (a nome di INCOSE)
Stephen S. Mattingly Glen Maxfield
Peter McCarthy Rob McCormack, PMP
Krik D. McManus David Michaud
Mary F. Miekoski, PMP Oscar A. Mignone
Gordon R. Miller, PMP Roy E. Morgan, PMP
Jim Morris, PMP Bert Mosterd, PMP
William A. Moylan, PMP John D. Nelson, PMP
Wolfgang Obermeier Cathy Oest, PMP
Masato Ohori, PMP Kazuhiko Okubo, PE, PMP
Edward Oliver Jerry Partridge, PMP
Francisco Perez-Polo, PMP James M. Phillips, PMP
Crispin (Kik) Piney, PMP George Pitagorsky, PMP
David L. Prater, PMP Bradford S. Price, PMP
Samuel L. Raisch, PMP Naga Rajan
G. Ramachandran, PMP Bill Righter, PMP
Bernice L. Rocque, PMP Wolfgang Theodore Roesch
Fernando Romero Peñailillo
Linda Rust, PMP
Jon Rude
Fabian Sagristani, PMP
B
James N. Salapatas, PMP Seymour Samuels
Bradford N. Scales H. Peter Schiller
John R. Schuyler, PMP Maria Scott, PMP
Shoukat Sheikh, MBA, PMP Kazuo Shimizu, PMP
Larry Sieck (a nome di PMI Tokyo, Japan Chapter)
Melvin Silverman, PhD, PE Loren J. Simer Jr.
Keith Skilling, PE, PMP Greg Skulmoski
Kenneth F. Smith, PMP Barry Smythe, PMP
Paul J. Solomon Joe Soto Sr., PMP
Christopher Wessley Sours, PMP Charlene Spoede, PMP
Joyce Statz, PMP Emmett Stine, PMP
Thangavel Subbu Jim Szpakowski
Ahmet N. Taspinar, PMP John A. Thoren Jr., PMP
Alan D. Uren, PMP Juan Luis Valero, PMP
S. Rao Vallabhaneni William Simon Vaughan Robinson
Ana Isabel Vazquez Urbina Ricardo Viana Vargas, PMP
Stephen E. Wall, PMP William W. Wassel, PMP
Tammo T. Wilkens, PE, PMP Robert Williford, PMP
®
Contributi ai documenti precedenti

Parti dell'edizione del 1996 e dei documenti precedenti sono presenti anche
nell'edizione del 2000. Il PMI desidera riconoscere alle persone volontarie elencate di
seguito il loro contributo sostanziale all'edizione 2000.
John R. Adams William R. Duncan Matthew H. Parry
Alan Stretton R. Max Wideman
Personale addetto alla produzione

È doveroso rivolgere una menzione speciale ai seguenti dipendenti del PMI:
Steven L. Fahrenkrog, Standards Manager
Lisa Fisher, Assistant Editor
Lewis M. Gedansky, Research Manager
Linda V. Gillman, Advertising Coordinator/PMBOK® Guide Copyright
Permissions Coordinator
Eva T. Goldman, Technical Research & Standards Associate
Paul Grace, Certification Manager
Sandy Jenkins, Managing Editor
Toni D. Knott, Book Editor
John McHugh, Interim Publisher
Dewey L. Messer, Design and Production Manager
Mark S. Parker, Production Coordinator
Shirley B. Parker, Business/Book Publishing Manager
Michelle Triggs Owen, Graphic Designer
Iesha D. Turner-Brown, Standards Administrator
®
APPENDICE C
Redattori e revisori della Terza edizione della

Guida al PMBOK®
La prima volta in cui i volontari del PMI hanno tentato di codificare il corpo di
conoscenze del Project Management fu con la stesura della relazione “Special Report on
Ethics, Standards, and Accreditation” pubblicata nel 1983. Da quel momento, altri
volontari hanno dato il loro contributo per aggiornare e migliorare il documento
originale, fino a fare confluire i loro sforzi in quello che oggi è di fatto considerato lo
standard nel campo del Project Management, la Guida al Project Management Body of
Knowledge (Guida al PMBOK). Questa appendice elenca, in ordine alfabetico nelle
varie sezioni, le persone che hanno contribuito allo sviluppo e alla creazione della Terza
edizione della Guida al PMBOK. Un semplice elenco, o anche più elenchi, non
sarebbero sufficienti per descrivere a dovere tutti i contributi di chi ha collaborato allo
sviluppo della Terza edizione della Guida al PMBOK. Nell'Appendice B sono descritti
i contributi specifici di molte fra le persone citate di seguito, si consiglia di consultarla
per ulteriori informazioni sui singoli contributi al progetto.
Il Project Management Institute ringrazia tutte queste persone per il loro
sostegno e riconosce il loro contributo alla professione del Project Management. C
C.1 PMBOK® Guide 2004 Update Project Leadership Team
Le persone elencate di seguito hanno contribuito fornendo testi o concetti e hanno
svolto la funzione di leader nel Project Leadership Team (PLT):
Dennis Bolles, PMP, Project Manager
Darrel G. Hubbard, PE, Deputy Project Manager
J. David Blaine, PMP (Quality Control Coordinator)
Theodore R. Boccuzzi, PMP (Document Research Team Leader)
Elden Jones, PMP (Configuration Management Coordinator)
Dorothy Kangas, PMP (Product Overview Team Leader)
Carol Steuer, PMP (Framework Team Leader)
Geree Streun, PMP (Process Groups Team Leader)
Lee Towe, PMP (Special Appointment)
®
Appendice C − Redattori e revisori della Terza edizione della Guida al PMBOK®
C.2 PMBOK® Guide 2004 Update Project Core Team

Assieme al Project Leadership Team, le seguenti persone hanno contribuito fornendo
testi o concetti e hanno svolto il ruolo di co-leader all'interno del Project Core Team
(PCT):
Nigel Blampied, PE, PMP (Framework Team Co-Leader)
J. David Blaine, PMP (Product Overview Team Co-Leader)
Andrea Giulio Demaria, PMP (Document Research Team Co-Leader)
Greg Githens, PMP (Framework Team Co-Leader)
Dana J. Goulston, PMP (Framework Team Co-Leader)
David T. Hulett, PhD (Knowledge Areas Team Co-Leader)
Elden Jones, MSPM, PMP (Process Groups Team Co-Leader)
Carol Rauh, PhD, PMP (Knowledge Areas Team Co-Leader)
Michael J. Schollmeyer, PMP (Product Overview Team Co-Leader)
C.3 PMBOK® Guide 2004 Update Project Sub-Teams

Le seguenti persone hanno contribuito fornendo testi o concetti e hanno svolto il ruolo
di leader dei Project Sub-Team (PST):
W. Clifton Baldwin, PMP (Index and Input Guidance Leader)
Barbara Borgmann, PMP (Knowledge Areas Chapter 8 Leader)
Kim D. Colenso, PMP, CSQE (Glossary Leader)
Earl Glenwright, PE, VEA (Knowledge Areas Chapter 7 Leader)
Darrel G. Hubbard, PE (Knowledge Areas Chapter 12 Leader)
David T. Hulett, PhD, PMP (Knowledge Areas Chapter 11 Leader)
Jim O’Brien, PMP (Knowledge Areas Chapter 6 Leader)
Brian Salk, M.A. Ed., PMP (Knowledge Areas Chapter 5 Leader)
Geree Streun, PMP (Knowledge Areas Chapters 3 and 4 Leader)
John A. Thoren, Jr., PMP, PhD (Knowledge Areas Chapter 10 Leader)
Lee Towe, PMP, MBA (Knowledge Areas Chapter 9 Leader)
C.4 Contributi significativi

Assieme ai membri del Project Leadership Team, del Project Core Team e ai Sub-
Team Leader, le seguenti persone hanno contribuito fornendo input o concetti
sostanziali:
Sumner Alpert, PMP, CMC
Cynthia A. Berg, PMP
Bradford Eichhorn, PMP
Steve Grey, PhD, PMP
David Hillson, PhD, PMP
Yan Bello Mendez, PMP
Crispin “Kik” Piney, BSc, PMP
Massimo Torre, PhD, PMP
Cornelis (Kees) Vonk, PMP
Linda Westfall, PE, CSQE
®
C.5 PMBOK® Guide 2004 Update Project Team Members
Assieme alle persone già citate, i seguenti membri del PMBOK® Guide 2004 Update
Project Team hanno fornito input e raccomandazioni alle versioni preliminari della
Terza edizione della Guida al PMBOK® o hanno inviato suggerimenti di modifiche
(ECRs):
Abdallah Abi-Aad, PMP, P.Eng. Muhamed Abdomerovic, PMP
Adrian Abramovici, PMP Jamie K. Allen, PMP
Mark Allyn, PMP Scott C. Anderson, PMP
Lionel Andrew, MBA, ISP Russell Archibald, PMP
Prabu V. Ayyagari, PhD, PMP Ernest Baker, PMP
Pamela M. Baker, PMP Kevin E. Bast, PMP
James S. Bennett, PMP Ionut C. Bibac
Howland Blackiston Ray Blake, PMP
Charles W. Bosler, Jr. Rollin O. Bowen, Jr.
Carolyn Boyles, MBA, PMP Wayne R. Brantley, PMP, MS Ed
Alex S. Brown, PMP Timothy S. Brown
Stephen C. Burgan, PMP Anne Cagle, PMP
Dean J. Calabrese, PMP Neil R. Caldwell
Giuseppe A. Caruso, PMP Bill Chadick, PMP
Clare Chan Porfirio Chen Chang, MBA, PMP
Gene Chiappetta, PMP Tomio Chiba, PMP
Mark T. Chism, PMP Andy Crowe, PMP
Robert L. Cutler, PMP Darren Dalcher, PhD, MAPM
Mario Damiani, PMP Pranab Das, PMP
Robert de Jong, PMP Connie Delisle
John M. Dery, PMP Barbara De Vries, PMP
Jerry Dimos, PMP James A. Doanes
Capt. Nick Doralp, PMP Magnus Karl Drengwitz, PMP
Peter Duignan, PMP Lloyd R. Duke, Jr., PMP
Suhas Dutta, PMP Bradford R. Eichhorn, PMP
Gary S. Elliott, M.S., M.D. Gregory William Fabian, PMP
Morten Fangel, PhD
Eve Featherman
Martin Christopher Fears, PMP
AnnaMaria Felici C
Flynn M. Fernandes, PMP, MSPM John C. “Buck” Field, MBA, PMP
David Foley, MBA Kirby Fortenberry, PMP
Gary W. Fortune, PMP John M. Foster, PMP, MBA
Scott D. Freauf, PMP Denis Freeland
Ichiro Fujita, PMP John S. Galliano
Donald G. Gardner, PMP Stainslaw Gasik
Jose A. George, Btech, PGDM Dan Georgopulos
Leo A.Giulianetti, PMP Christopher A. Goetz, PMP
Donna Golden Neil P. Goldman, PMP
Dr. Margarida Goncalves John C. Goodpasture, PMP
Neal S. Gray, PMP Robert J. Gries, PE, PMP
Patrick D. Guest, PMP Jinendra Gunathilaka, PE
Navneet Gupta, PMP Aaron S. Hall, PMP
J. Ray Harwood, PMP Ali Hassan, PMP
Ralph Hernandez Pat Hillcoat, PMP
Bobby Tsan Fai Ho, PMP, CISM Gopi V. Hombal
Keith D. Hornbacher, MBA Kenneth Alan Hudacsko, PMP
Clinton in’t Veld Adesh Jain, PMP, MPD
Don R. James, PMP Noel C. Jensen, PMP
Wei Jing Bruce Johnson, PMP
®
Granville H. Jones, Sr., MBA, PMP Kevin B. Jones, BMath, PMP

Tom Kerr, PMP Ajmal Afzal Khan
Asadullah Khan, PMP Lucy Kim, PMP, PE
Mihail Kitanovski Jennifer Eileen Kraft
Takahiko Kuki, PMP, PE Polisetty V.S. Kumar, Mtech, PMP
Avis Kunz Antonio Carlos Laranjo da Silva
John S. Layman, PMP Erik D. Lindquist, PMP, PE
Elizabeth Ann Long, PMP Raul S. Lopez, PE, PMP
Pier Paolo Lo Valvo, PMP Karen Griffin MacNeil, PMP
Sajith K. Madapatu, PMP Vijaya Kumar Mani, PMP
Enrique Martinez Victor J. Matheron, PMP
David L. McPeters, PMP Ed Mechler, PMP
Godfrey I. Meertens, PMP Richard Meertens, MBA, PMP
Gordon R. Miller, PMP, CCP Liu Min
Andrew H. Moore, MBA, PMP Colin Morris, PE, PMP
Mhlabaniseni Moses Mitmunye Charles L. Munch, PMP
K.S. Keshava Murthy Jo Musto, PMP
AnathaKrishnan S. Nallepally, PMP NB Narayanan
Vijayalakshimi Neela, MCA, PMP Beatrice Nelson, PMP
Brian D. Nelson, PMP Isabella Nizza, PMP
Kazuhiko Okubo, PE, PMP David M. Olson, MBA (ITM)
Jeffery L. Ottesen, PE Michael T. Ozeranic
Laura Dorival Paglione Glen R. Palmer
Jerry L. Partridge, PMP George Pasieka, PMP
Eric Patel Sreenivasa Rao Potti, MCA, PMP
Manohar Powar, PMP Patrick J. Quairoli
Ge Qun Vara Prasad Raju Kunada
Prem Ranganath, PMP Raju Rao, PMP
Ulka Rathi Tony Raymond
Vijay Sai Reddy, PMP, CSQA J. Logan C. Rice
Steven Ricks, PMP Thad B. Ring, PMP
Dee Rizor Susan Rizzi
Michael C. Roach Alexandre G. Rodrigues, PhD
Cheryl N. Rogers, PMP Scott A. Rose, PMP
Ed Rosenstein, PMP Samuel S. Roth, PMP
Joseph A. Roushdi Gurdev Roy, PMP
Paul S. Royer, PMP James J. Rutushni, PMP
Frank Ryle, PMP Anjali Sabharwal, PMP
Srinivasa R. Sajja, PMP Nashaat A. Salman, PMP
Markus Scheibel, PMP, Dipl.-Ing. John Schmitt, PMP
Amy Schneider, PMP Randa Schollmeyer, PMP
Andrea R. Scott Benjamin R. Sellers, PMP, CPCM
Tufan Sevim, PMP Sanjay Shah, PMP
Mundaje S. Shetty, PMP Kazuo Shimizu, PMP
Rali Shital Ganga Siebertz
Larry Sieck Melvin Silverman, PhD, PE
Richard L. Sinatra, PMP, PhD Raghavendra Singh
Edward Smith Patricia Smith
Richard Spector, PMP Allison St. Jean
Donglin Su Sambasivam S., PMP, CSQA
Karen Z. Sullivan, PMP Karen Tate, PMP, MBA
David E. Taylor, PMP James E. Teer, Jr.
Sai K. Thallam, MBA, PMP Surendra Tipparaju, ME
Massimo Torre, PhD, PMP Rogerio Carlos Traballi
®
Rufis A. Turpin, CQA, CSQE Marion J. Tyler, PMP
M. Raj Ullagaraj, PhD Eric Uyttewaal, PMP
JR Vanden Eynde, PMP Gerrit van Otterdijk, BSc. Mgt Science
Thomas G. Van Scoyoc, PMP Paula X. Varas, PMP
Ricardo Viana Vargas, MSc, PMP Mark M. Vertin, PE, PMP
Craig Veteto, PMP, CPIM Roberto Viale, PMP
Eduardo Newton Vieira, PMP Desmond Joseph Vize, PMP
Cornelius (Kees) Vonk, PMP J. Wendell Wagner, PMP
Thomas M. Walsh, PMP Patrick Weaver, PMP, FAICD
Kevin R. Wegryn, PMP, CPM Timothy E. Welker, PMP
Gwen Whitman, PMP Tammo T. Wilkens, PE, PMP
Alan K. Williams, Sr., PMP Charles M. Williamson, MBA, PMP
Stephen D. Wise Robert Wood
Thomas Wuttke, PMP, CPM Uma S. Yalamanchili, PMP
Angela F. Young, PMP Kathy Zandbergen
Eire E. Zimmermann, PMP
C.6 Redattori e revisori della bozza finale

Assieme ai membri del gruppo di lavoro, le seguenti persone hanno fornito
raccomandazioni su come migliorare la bozza finale della Terza edizione della Guida
al PMBOK®:
Fred Abrams Yassir Afaneh
Mohammed Abdulla Al-Kuwari, Eur Ing, Hussain Ali Al-Ansari, Eur Ing, CEng
Ceng
Frank Angari William W. Bahnmaier, PMP
Alfred Baker B. D. Barnes
Jefferson Bastreghi Mohammed Safi Batley, MIM
Cynthia A. Berg, PMP Sally Bernstein, PMP
Mamoun A. Besaiso, CE J. David Blaine, PMP, CSQE
Nigel Blampied, PE, PMP Dennis Bolles, PMP
Stephen Bonk Gregory M. Bowen, CSDP
David Bradford, PMP
Gary D. Brawley, P.Eng., PMP
James (Jim) P. Branden, MBA, PMP
Edgard P. Cerqueira Neto, PhD, PMP C
Bruce Chadbourne Tomio Chiba, PMP
Aaron Coffman, PMP, CQM Kim D. Colenso, PMP, CSQE
Edmund H. Conrow, PhD, PMP Helen S. Cooke, PMP
Michael Corish John E. Cormier, PMP
John Cornman, PMP, MBA Aloysio da Silva
Mario Damiani Arindam Das
Allan E. Dean Alfredo del Cano, PE, PhD
Juan De La Cruz M. Pilar De La Cruz
Ravi Kumar Dikshit, PMP John Downing
Daniel Dudek Judith Edwards, PhD, PMP
Robert L. Emerson, PMP Alison Evanish
Keith Farndale, PEng, PMP Linda Fitzgerald
Quentin W. Fleming Scott D. Freauf, PMP
Ichiro Fujita, PMP Paul H. Gil, MCP, PMP
Jackelen George Mike Griffiths, PMP
David R. Haas, PMP, FLMI Robert W. Harding, RA
Delbert K. Hardy, PMP Rick Hiett
Bob Hillier, PMP Guy N. Hindley, MAPM, MILT
Danny N. Hinton, PMP Ho Lee Cheong, PhD, MIMech E
J. Brian Hobbs, PhD, PMP Piet Holbrouck, MSc
Martin Hopkinson, BSc, APMP Darrel G. Hubbard, PE
Grant Jefferson Howard J. Kalinsky, PMP, MPM
®
Constance Katsanis Roger Kent

Takahiko Kuki, PMP, PE Lawrence (Larry) P. Leach, PMP
Craig Letavec Ben Linders
Pier Paolo Lo Valvo, PMP Mary K. Lofsness
Enrique Lopez-Mingueza, PMP Mark Marlin, PMP
Stephen S. Mattingly Christopher J. Maughan, CEng, PMP
Giuseppe Mauri Yves Mboda, PMP
Santosh Kumar Mishra, PMP, CSQA Colin Morris, P.Eng., PMP
Saradhi Motamarri, MTech, PMP Rita Mulcahy, PMP
Jeffrey S. Nielsen, PMP Kazuhiko Okubo, PE, PMP
Peter Ostrom, PhD, PMP Ravindranath P S
Ravindranath Palahalli Jon Palmquist
Nick Palumbo, PMP Anil Peer, P.Eng., PMP
Francisco Perez-Polo Paul W. Phister, Jr., PhD, PE
Crispin (Kik) Piney, BSc, PMP Polisetty V.S. Kumar, Mtech, PMP
Gurdev Randhawa Raju Rao, PMP
Steven F. Ritter, PMP Hans (Ron) Ronhovde, PMP
David W. Ross, PMP Robbi Ryan
Kyoichi Sato Suzanne Lee Schmidt, PMP
Benjamin R. Sellers, PMP, CPCM Tufan Sevim, PMP
Kazuo Shimizu, PMP Melvin Silverman
Fernando Demattio de O. Simoes, PMP John E. Singley, PhD, PMP
Cynthia Snyder, PMP, MBA Antonio Soares
Paul Solomon, PMP Michael Stefanovic, P.Eng., PMP
Juergen Sturany George Sukumar, MSChe, OE
Luis Eduardo Torres Calzada, PMP, MBA Dalton L. Valeriano-Alves, M.E.
Gary Van Eck Judy Van Meter
J.R. Vanden Eynde, PMP Ricardo Vargas
Aloysio Vianna, Jr. Dave Violette, MPM, PMP
Thomas M. Walsh, PMP William W. Wassel, PE, PMP
Patrick Weaver, PMP, FAICD Kevin R. Wegryn, PMP, CPM
Linda Westfall, PE, CSQE Allan Wong
Clement C.L. Yeung, PMP John Zachar, BSc, APMP
Cristine Zerpa Paul Zilmer
C.7 PMI Project Management Standards Program Member

Advisory Group
Durante lo sviluppo della Terza edizione della Guida al PMBOK® i membri del PMI
Standards Program Member Advisory Group erano le seguenti persone:
Julia M. Bednar, PMP Sergio R. Coronado
J. Brian Hobbs, PMP Carol Holliday, PMP
Thomas Kurihara Asbjorn Rolstadas, PhD
Bobbye Underwood, PMP Dave Violette, MPM, PMP
®
C.8 Addetti alla produzione
Una menzione speciale è dovuta ai seguenti dipendenti del PMI:
Steven L. Fahrenkrog, PMP, Manager, Standards
Kristin L. Wright, Standards Program Administrator
Shari M. Daniel, PMP, Project Manager—Translations
Dan Goldfischer, Editor-in-Chief
Patti Harter, Project Manager
David Parker, Manager, Publications
Natasha Pollard, Translation Verification Committee Coordinator
Richard E. Schwartz, Product Editor
Barbara Walsh, Publications Planner
C.9 Comitato di verifica delle traduzioni

Luciano Garagna, PMP, Chair
Antonio Bassi, PMP
Riccardo Biemmi
Mario Damiani, PMP
Al DeLucia, PMP
AnnaMaria Felici
Marco Ferrari
Enrico Masciadra, PMP
Isabella Nizza, PMP
Alessandro Pigna, PMP
Agostino Schito, PMP
®
APPENDICE D
Estensioni per le aree applicative

D.1 Necessità di estensioni per le aree applicative
Le estensioni per le aree applicative sono necessarie quando esistono conoscenze e
pratiche generalmente accettate per una data categoria di progetti di una determinata
area applicativa che non sono generalmente accettate nei diversi tipi di progetti della
maggior parte delle aree applicative. Le estensioni per le aree applicative riflettono:
• Gli aspetti unici o insoliti dell’ambiente di progetto di cui il gruppo di Project
Management deve essere consapevole per gestire il progetto in modo efficiente
ed efficace.
• Conoscenze e pratiche comuni che, se adottate, migliorano l'efficienza e
l'efficacia del progetto (ad es. WBS standard).
Le conoscenze e le pratiche specifiche per l'area applicativa emergono come
conseguenza di molti fattori tra cui le differenze nelle norme culturali, nella
terminologia tecnica, nell'impatto sociale o nel ciclo di vita del progetto. Ecco alcuni
esempi:
• Nel campo edilizio, in cui virtualmente qualsiasi lavoro viene svolto a contratto,
esistono conoscenze e pratiche comuni legate all'approvvigionamento che non
sono applicabili a tutte le categorie di progetti.
• Nel campo delle scienze biologiche, esistono conoscenze e pratiche condivise
che sono determinate da norme e che non sono applicabili a tutte le categorie di
progetti.
D
• Nel campo degli appalti pubblici, esistono conoscenze e pratiche comuni
determinate dai regolamenti degli appalti pubblici che non sono applicabili a
tutte le categorie di progetti.
• Nel campo della consulenza, esistono conoscenze e pratiche comuni dovute alle
responsabilità di vendita e di marketing del project manager che non sono
applicabili a tutte le categorie di progetti.
®
Appendice D – Estensioni per le aree applicative
Le estensioni per le aree applicative sono:

• informazioni da leggere in aggiunta e non in sostituzione al materiale principale
della Guida al PMBOK® (capitoli da 1 a 12);
• strutturate in modo simile alla Guida al PMBOK®, con un'identificazione e una
descrizione dei processi di Project Management specifici dell'area applicativa;
• aggiunte uniche al materiale principale, il cui contenuto può servire a:
♦ identificare processi nuovi o modificati;
♦ suddividere i processi esistenti;
♦ descrivere sequenze o interazioni di processi differenti;
♦ aumentare gli elementi o modificare le definizioni comuni dei processi;
♦ definire input, strumenti e tecniche e/o output speciali per i processi
esistenti.
Le estensioni per le aree applicative non sono invece:
• “manuali operativi” o “guide pratiche” (tali documenti potrebbero essere
pubblicati come standard PMI ma non sono considerate estensioni per le aree
applicative);
• documenti che descrivono ad un livello più dettagliato quanto già indicato nella
Guida al PMBOK®; tali dettagli potrebbero essere inclusi in manuali o guide
pubblicati come standard PMI ma non sono considerati estensioni per le aree
applicative.
D.2 Criteri per lo sviluppo delle estensioni per le aree
applicative
Le estensioni saranno sviluppate in presenza di questi criteri:
• Esiste un corpo di conoscenze sostanziali che è orientato al progetto ma anche
unico o quasi unico per l'area applicativa specifica.
• Esiste un componente del PMI (ad es. un PMI Specific Interest Group, un
College o un Chapter) o un'organizzazione esterna identificabile che intende
impegnare, ed è in grado di farlo, le risorse necessarie per sottoscrivere e
sostenere il PMI Standards Program nello sviluppo e la gestione di uno standard
PMI specifico. In alternativa, le estensioni possono essere sviluppate dal PMI
stesso.
• L'estensione proposta è in grado di superare il processo rigoroso per la
definizione degli standard di Project Management del PMI allo stesso livello di
qualsiasi altro standard PMI.
®
D.3 Pubblicazione e formato delle estensioni per le aree
applicative
Le estensioni per le aree applicative sono sviluppate e/o pubblicate dal PMI oppure
sono sviluppate e/o pubblicate da un componente del PMI o da un'organizzazione
esterna in base ad accordo formale con il PMI.
• In termini di stile e contenuto, le estensioni sono conformi alla Guida al
PMBOK®. Vengono utilizzati gli stessi numeri di paragrafo e sottoparagrafo del
materiale oggetto di estensione.
• Le sezioni e i paragrafi della Guida al PMBOK® che non vengono estesi non
sono ripetuti nelle estensioni stesse.
• Le estensioni contengono una spiegazione del fondamento logico e una
giustificazione della necessità di estensione e del relativo materiale.
• Le estensioni sono ben delimitate, cioè specificano chiaramente gli obiettivi che
non intendono raggiungere.
D.4 Processo per lo sviluppo e la gestione delle estensioni

per le aree applicative
Se vengono approvate in accordo con il processo di definizione degli standard del
PMI, le estensioni per le aree applicative diventano a tutti gli effetti standard PMI. Le
estensioni vengono sviluppate e aggiornate seguendo il processo descritto di seguito.
• Un'estensione deve essere sponsorizzata dal PMI, da un componente del PMI
formalmente istituito (ad es. un PMI Specific Interest Group, un College o un
Chapter) o da un’altra organizzazione esterna al PMI che sia stata approvata dal
PMI Standards Program Member Advisory Group e dal PMI Standards
Manager. Si predilige tuttavia la sponsorizzazione congiunta con il PMI. Tutte le
approvazioni devono essere accordi formali scritti tra il PMI e l'entità sponsor.
Tali accordi devono comprendere, tra l'altro, l'accordo tra le parti in materia di
diritti di proprietà intellettuale e di diritti di pubblicazione per l'estensione.
• Nell'ambito del programma degli standard PMI, deve essere stato approvato un
progetto per lo sviluppo, la pubblicazione e/o la gestione dell'estensione. Le
autorizzazioni ad avviare, sviluppare e gestire un'estensione devono essere D
emesse dal PMI e sono soggette ad un accordo tra le organizzazioni. In assenza
di un’organizzazione sponsor, il PMI Standards Program può decidere di
proseguire in modo autonomo.
• Per tutto il processo di sviluppo e gestione dell’estensione, il gruppo di
sponsorizzazione deve tenere informati il PMI Standards Program Member
Advisory Group e il PMI Standards Manager eventualmente richiedendo loro
consulenza e supporto. Questi ultimi dovranno fornire la loro approvazione
all'organizzazione sponsor per l'estensione proposta e verificare l'estensione
mano a mano che viene sviluppata, al fine di individuare eventuali conflitti o
sovrapposizioni con altri progetti simili in corso.
®
Appendice D – Estensioni per le aree applicative
• Il gruppo di sponsorizzazione prepara una proposta per lo sviluppo

dell'estensione. La proposta deve essere corredata da una giustificazione del
progetto tramite una matrice che indichi i processi specifici per l'area applicativa
e le sezioni della Guida al PMBOK® coinvolte. La proposta deve contenere
anche l’impegno da parte di un numero sufficiente di redattori e revisori
qualificati, l'identificazione delle necessità di finanziamento (compresi
riproduzione, spese postali, costi telefonici, desktop publishing, ecc.), l'impegno
a rispettare le procedure del PMI per lo sviluppo e la gestione dell'estensione
degli standard PMI e infine il piano e la schedulazione per lo sviluppo e la
gestione dell'estensione.
• Una volta accettata la proposta, il gruppo di progetto prepara un project charter
per l'approvazione da parte del gruppo di sponsor e del PMI Standards Program
Team. Nel charter sono definite le fonti di finanziamento e gli eventuali
finanziamenti richiesti al PMI. Il charter deve comprendere inoltre un requisito
di revisione periodica dell'estensione con report al PMI Standards Program
Team e una cosiddetta “sunset clause” (clausola di temporaneità) in cui si
specifica quando e a che condizioni l'estensione verrà rimossa dal suo stato di
standard PMI attivo.
• La proposta viene inviata al PMI Standards Manager in accordo con il processo
di definizione degli standard del PMI. Il PMI Standards Manager stabilisce se la
proposta ha buone probabilità di sfociare in un documento accettabile come
standard PMI e determina se sono state identificate risorse e fonti di supporto
adeguate. Per contribuire a tale decisione, il PMI Standards Manager raccoglierà
commenti da parte del PMI Standards Program Member Advisory Group e, se
necessario, da un gruppo di esperti non coinvolti nell'estensione.
• Il PMI Standards Manager, con il supporto del PMI Standards Program Member
Advisory Group, provvede a monitorare e supportare lo sviluppo del progetto
approvato.
• L'organizzazione sponsor sviluppa l'estensione così come approvata nel project
charter, occupandosi anche del coordinamento con il PMI Standards Program
Member Advisory Group per supporto, revisione e commenti.
• Se l'estensione è stata completata con piena soddisfazione dell'organizzazione
sponsor, viene inviata al PMI Standards Manager che gestisce l'approvazione
definitiva e i processi di pubblicazione in base al processo di definizione degli
standard del PMI. Con l'invio definitivo l'organizzazione sponsor elenca e si
impegna a sostenere con i propri sforzi i successivi processi di gestione
dell'estensione.
• Successivamente all'approvazione dell'estensione come standard PMI,
l'organizzazione sponsor implementerà il processo di gestione dell'estensione
come da piano approvato.
®
APPENDICE E
Altre fonti di informazioni sul Project

Management
Il Project Management è un campo dinamico e in evoluzione in cui vengono
pubblicati libri e articoli con regolarità. Le entità elencate di seguito offrono una
gamma di prodotti e servizi che possono essere utili a chi è interessato al Project
Management.
E.1 Organizzazioni professionali e tecniche

Questo documento è stato sviluppato e pubblicato dal Project Management Institute
(PMI). Per contattare il PMI:
Project Management Institute
Four Campus Boulevard
Newtown Square, PA 19073-3299 USA
Telefono: +1-610-356-4600
Fax: +1-610-356-4647
E-mail: pmihq@pmi.org
Internet: http://www.pmi.org
Al momento il PMI ha stipulato accordi di collaborazione con le seguenti
organizzazioni:
Association for the Advancement of Cost Engineering (AACE International)
Telefono: +1-304-296-8444 Fax: +1-304-291-5728
http://www.aacei.org/
Asociacion Espanola de Ingenieria de Proyectos (AEIPRO)
E
Telefono: +3476-976-761-910 Fax: +347-6976-761861
www.aeipro.org
Australian Institute of Project Management (AIPM)
Telefono: +61-2-9252-7277 Fax: +61-2-9252-7077
www.aipm.com.au
Construction & Economy Research Institute of Korea (CERIK)
Telefono: +822-3441-0801 Fax: +822-544-6234
www.cerik.re.kr
Defense Systems Management College Alumni Association (DSMCAA)
Telefono: +1-703-960-6802 Fax: +1-703-960-6807
Engineering Advancement Association of Japan (ENAA)
Telefono: +81-4-5682-8071 Fax: +81-4-5682-8710
www.enaa.or.jp
®
Appendice E − Fonti supplementari di informazione sul Project Management
Institute of Project Management (IPM-Ireland)

Telefono: +353-1-661-4677 Fax: +353-1-661-3588
International Project Management Association (IPMA)
Telefono: +44-1594-531-007 Fax: +44-1594-531-008
Korean Institute of Project Management & Technology (PROMAT)
Telefono: +822-523-16446 Fax: +822-523-1680
www.promat.or.kr
National Contract Management Association (NCMA)
Telefono: +703-448-9231 Fax: +703-448-0939
The NORDNET National Associations
(Danimarca, Finlandia, Islanda, Norvegia e Svezia)
Fax: +468-719-9316
Project Management Associates (PMA-India)
Telefono: +91-11-852-6673 Fax: +91-11-646-4481
www.pma.india.org
Project Management Association of Slovakia (SPPR)
Telefono: +421-805-599-1806 Fax: +421-805-599-1-818
Project Management South Africa
Telefono:+2711-706-6813 Fax: +2711-706-6813
www.pmisa.co.za
Projekt Management Austria
Telefono: +43-1-319-29-210 Fax: +43-1-319-29-21-29
www.p-m-a.at
Russian Project Management Association (SOVNET)
Telefono: +7-095-215-37-18 Fax: +7-095-215-37-18
www.sovnet.ru
Slovenian Project Management Association (ZPM)
Telefono: +61-1767-134 Fax: +61-217-341
www.ipma.ch
Ukrainian Project Management Association (UPMA)
Telefono: +38-044-459-3464 oppure +38-044-241-5400
www.upma.kiev.ua
Inoltre, ci sono numerose altre organizzazioni in ambiti correlati che possono fornire
ulteriori informazioni sul Project Management. Per esempio:
Academy of Management
American Management Association International
American Society for Quality Control
Construction Industry Institute
Construction Management Association of America (CMAA)
Institute of Electrical and Electronics Engineers (IEEE)
Institute of Industrial Engineers (IIE)
International Council on Systems Engineering (INCOSE)
National Association for Purchasing Management
National Contract Management Association
®
Society for Human Resource Management
American Society of Civil Engineers
Informazioni aggiornate per contattare queste ed altre organizzazioni
professionali e tecniche sono reperibili su Internet.
E.2 Case editrici commerciali

Il PMI è il principale editore di libri sul Project Management. Tuttavia, ci sono molte
case editrici commerciali che pubblicano libri sul Project Management e su argomenti
correlati, tra le quali ricordiamo:
Addison-Wesley
AMACOM
Gower Press
John Wiley & Sons
Marcel Dekker
McGraw-Hill
Prentice-Hall
Probus
Van Nostrand Reinhold
La maggior parte dei libri sul Project Management di queste case editrici si
possono ordinare attraverso il PMI. Molti dei libri pubblicati da queste case editrici
contengono bibliografie approfondite o elenchi di letture suggerite.
E.3 Fornitori di prodotti e servizi

Le società che vendono software, formazione, consulenza e altri prodotti e servizi per le
professioni del Project Management forniscono spesso monografie o ristampe.
Il programma PMI Registered Education Provider (R.E.P.) nasce per aiutare lo
sviluppo professionale continuo dei membri del PMI, di chi desidera certificarsi come
Project Management Professional (PMP®) e di altri stakeholder del Project
Management; l’obiettivo è creare un legame tra stakeholder e coordinatori della
formazione da una parte e organizzazioni e prodotti formativi qualificati dall'altra. Per
un elenco dei R.E.P. e delle relative offerte formative consultare la pagina
http://www.pmi.org/education/rep.
E.4 Istituzioni educative E

Molte università, college e junior college offrono programmi di formazione continua
per il Project Management e le discipline correlate. Molte di queste istituzioni offrono
anche programmi di laurea di primo e secondo livello.
®
APPENDICE F
Riepilogo delle aree di conoscenza del

Project Management
Gestione dell’integrazione di progetto
La 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 all'interno dei gruppi di processi di Project Management. Nel
contesto del Project Management, l'integrazione è caratterizzata anche da
unificazione, rafforzamento, articolazione ed attività integrative di importanza vitale
per il completamento del progetto, per soddisfare in modo efficace i requisiti dei
clienti e degli altri stakeholder e gestire le aspettative. I processi di gestione
dell'integrazione di progetto comprendono:
• Sviluppare il Project Charter: sviluppo del project charter che costituisce
l’autorizzazione formale al progetto.
• 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.
• Sviluppare il piano di Project Management: documentazione delle azioni
necessarie per definire, preparare, integrare e coordinare di tutti i piani ausiliari
inclusi in un piano di Project Management.
• Dirigere e gestire l'esecuzione del progetto: esecuzione del lavoro definito in un
piano di Project Management che consente di raggiungere i requisiti del progetto
stabiliti dalla descrizione dell'ambito del progetto.
• 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
F
Project Management.
• Controllo integrato delle modifiche: analisi di tutte le richieste di modifica,
approvazione delle modifiche e controllo delle modifiche ai deliverable e agli
asset dei processi organizzativi.
• 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 stesso.
®
Appendice F − Riepilogo delle aree di conoscenza del Project Management
Gestione dell'ambito del progetto

La gestione del contenuto di progetto comprende i processi necessari ad assicurare che
un progetto includa tutto il lavoro richiesto, e soltanto il lavoro richiesto ai fini del suo
completamento con successo. Il suo obiettivo primario è definire e controllare ciò che
è incluso nel progetto e ciò che non lo è. I processi di gestione dell'ambito del progetto
comprendono:
• 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.
• Definizione dell'ambito: sviluppo di una descrizione dettagliata dell'ambito del
progetto che servirà come base per le future decisioni del progetto.
• Creare la WBS: suddivisione dei principali deliverable del progetto, e del lavoro
incluso nel progetto, in componenti più piccole e quindi maggiormente gestibili.
• Verifica dell'ambito: accettazione formale dei deliverable di progetto completati.
• Controllo dell'ambito: controllo delle modifiche apportate all'ambito del
progetto.
Gestione dei tempi di progetto
La gestione dei tempi di progetto include i processi necessari ad assicurare il
completamento del progetto nei tempi previsti. I processi di gestione dei tempi di
progetto comprendono:
• Definizione delle attività: identificazione delle specifiche attività pianificate che
devono essere svolte per produrre i vari deliverable di progetto
• Sequenzializzazione delle attività: identifica e documenta le relazioni di
dipendenza presenti tra le attività schedulate.
• Stima delle risorse delle attività: stima del tipo e della quantità di risorse
necessarie ad eseguire ciascuna attività schedulata.
• Stima della durata delle attività: stima del numero di periodi lavorativi necessari
al completamento di ogni attività schedulata.
• 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.
• Controllo della schedulazione: controllo delle modifiche apportate alla
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. I processi di gestione dei costi di
• Stima dei costi: sviluppo di un’approssimazione dei costi delle risorse necessarie
per completare le attività di progetto.
• Allocazione dei costi: aggregazione dei costi stimati delle singole attività o dei
Work Package per determinare una baseline dei costi.
• Controllo dei costi: influenza sui fattori responsabili degli scostamenti dei costi
e controllo delle modifiche al budget del progetto.
®
Gestione della qualità di progetto
La gestione della qualità di progetto comprende 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 e le procedure ai quali si affiancano attività di miglioramento costante dei
processi, a seconda delle esigenze. I processi di gestione della qualità di progetto
comprendono:
• Pianificazione della qualità: identificazione degli standard di qualità rilevanti per
il progetto e determinazione dei modi in cui soddisfarli.
• Esecuzione dell'assicurazione della qualità: esecuzione delle attività pianificate e
sistematiche relative alla qualità per garantire che il progetto utilizzi tutti i
processi necessari a soddisfarne i requisiti.
• 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.
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 l'impegno dedicato al progetto. Il
tipo e il numero di membri del gruppo di progetto possono variare con l’avanzare del
progetto. I membri del gruppo di progetto vengono anche definiti “staff del progetto”.
I processi di gestione delle risorse umane di progetto comprendono:
• 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.
• Acquisire il gruppo di progetto: ottenimento delle risorse umane necessarie a
portare a termine il progetto.
• Sviluppare il gruppo di progetto: miglioramento delle competenze e
dell'interazione tra i membri del gruppo per incrementare le prestazioni del
progetto.
• Gestire il gruppo di progetto: rilevamento delle prestazioni dei membri del F
gruppo, comunicazione dei riscontri, risoluzione delle questioni e
coordinamento delle modifiche volto a migliorare le prestazioni del progetto.
®
Appendice F − Riepilogo delle aree di conoscenza del Project Management
Gestione della comunicazione di progetto

La gestione delle comunicazioni di progetto comprende i processi necessari a
garantire, tempestivamente e appropriatamente, la generazione, la raccolta, la
distribuzione, l’archiviazione, 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. I processi di gestione della comunicazione di
• Pianificazione della comunicazione: determinare le esigenze di informazione e
di comunicazione degli stakeholder di progetto.
• Distribuzione delle informazioni: rendere disponibili in modo tempestivo agli
stakeholder di progetto le informazioni richieste.
• Reporting delle prestazioni: raccogliere e distribuire le informazioni sulle
prestazioni. Ciò include, i rapporti sull’avanzamento, le misure di avanzamento
e di previsione.
• Gestione degli stakeholder: gestire le comunicazioni per soddisfare i requisiti e
risolvere eventuali questioni riguardanti gli stakeholder di progetto.
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. Gli obiettivi alla base della gestione dei rischi di progetto consistono
nell'aumentare la probabilità e l'impatto di eventi positivi e nel diminuire la probabilità
e l'impatto di eventi dannosi per il progetto. I processi di gestione dei rischi di progetto
comprendono:
• Pianificazione della gestione dei rischi: determinare come affrontare, pianificare
ed eseguire le attività di gestione dei rischi di un progetto.
• Identificazione dei rischi: determinare i rischi che possono influire sul progetto e
documentare le loro caratteristiche.
• Analisi qualitativa del rischio: assegnare le priorità ai rischi ai fini di
un’ulteriore analisi od operazione attraverso la valutazione e la combinazione
della probabilità che i rischi si verifichino e del loro impatto.
• Analisi quantitativa del rischio: analizzare numericamente l'effetto dei rischi
identificati sugli obiettivi complessivi del progetto.
• Pianificazione della risposta ai rischi: sviluppare opzioni e azioni volte a
incrementare le opportunità e ridurre le minacce agli obiettivi di progetto.
• 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
l'efficacia di queste operazioni nel corso del ciclo di vita del progetto.
®
Gestione dell'approvvigionamento di progetto
La gestione dell'approvvigionamento 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. L'organizzazione può ricoprire sia il ruolo di acquirente che di
fornitore del prodotto, del servizio o dei risultati oggetti del contratto.
La gestione dell'approvvigionamento 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 dell'approvvigionamento di progetto comprende anche le operazioni di
amministrazione di ogni contratto emesso da un’organizzazione esterna (l'acquirente)
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. I processi di gestione dell'approvvigionamento di progetto comprendono:
• Pianificare gli acquisti: determinazione degli elementi da acquistare o acquisire,
quando e con quale modalità.
• Pianificare le forniture: documentazione dei requisiti di prodotti, servizi e
risultati oggetto di approvvigionamento e individuazione dei potenziali fornitori.
• Richiesta delle risposte dai fornitori: reperimento di informazioni, preventivi,
offerte o proposte in base alle necessità.
• Selezionare i fornitori: valutazione delle offerte, scelta tra i potenziali fornitori e
stipula di un contratto scritto con ciascun fornitore prescelto.
• 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
l’acquirente esterno del progetto.
• Chiusura del contratto: completamento e conclusione di ogni contratto,
compresa la risoluzione di eventuali questioni aperte, e la chiusura di tutti i
contratti.
®
Sezione V
Glossario e indice
Riferimenti bibliografici
Glossario
Indice
RIFERIMENTI BIBLIOGRAFICI
Capitolo 1. Introduzione
1
The American Heritage Dictionary of the English Language, 3rd ed. Boston:
Houghton Mifflin Company, 1992.
2
International Organization for Standardization/International Electrotechnical
Commission (ISO/IEC) Guide 2. Geneva: ISO Press, 1996.
3
Turner, J. Rodney. The Handbook of Project-Based Management. New York:
McGraw-Hill, 1992.
Capitolo 2. Ciclo di vita del progetto e Organizzazione

Nessun riferimento bibliografico disponibile per questo capitolo.
Capitolo 3. Processo di Project Management di un progetto

Capitolo 4. Gestione dell’integrazione di progetto

4
Ïyigün, M. Güven. A Decision Support System for R&D Project Selection and
Resource Allocation Under Uncertainty. Project Management Journal 24, no. 4
(1993).
Capitolo 5. Gestione dell'ambito del progetto

5
Turner, J. Rodney. The Handbook of Project-Based Management. New York:
McGraw-Hill, 1992.
Capitolo 6. Gestione dei tempi di progetto

Capitolo 7 - Gestione dei costi di progetto

®
Riferimenti bibliografici
Capitolo 8. Gestione della qualità di progetto

6
American Society for Quality, 2000.
7
International Organization for Standardization. ISO 8402. Quality Management and
Quality Assurance. Geneva: ISO Press, 1994.
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 dell'approvvigionamento di progetto

®
GLOSSARIO
1. Inclusioni ed esclusioni
Il presente glossario comprende termini definibili come:
• specifici o quasi specifici del linguaggio utilizzato nell'ambito del Project
Management (ad esempio, Descrizione dell'ambito del progetto, Work Package,
WBS e Metodo del percorso critico);
• non specifici del linguaggio utilizzato nell'ambito del Project Management, ma
utilizzati in questo settore in modo diverso o con un significato più specifico
rispetto all'uso quotidiano (ad esempio, Data di inizio minima, Attività
schedulata).
In generale, questo glossario non contiene:
• termini specifici di una determinata area applicativa (ad esempio, Prospetto del
progetto, inteso come il documento legale specifico del settore dello sviluppo
delle proprietà immobiliari);
• termini il cui utilizzo nell'ambito del Project Management non differisce in
modo sostanziale dal rispettivo significato nell'uso quotidiano (ad esempio,
giorno di calendario, ritardo);
• termini composti il cui significato è deducibile dal significato congiunto delle
parti;
• varianti il cui significato può essere facilmente dedotto dal termine di base (ad
esempio, Rapporto sulle eccezioni è incluso, mentre "rapporti sulle eccezioni"
non lo è).
Come risultato delle inclusioni ed esclusioni di cui sopra, questo glossario
comprende:
• una preponderanza di termini associati alla gestione dell'ambito del progetto,
alla gestione dei tempi di progetto e alla gestione dei rischi di progetto; molti di
questi termini sono infatti specifici o quasi specifici del settore del Project
Management;
• molti termini derivati dalla gestione della qualità di progetto; questi termini sono Glossario
infatti usati in senso molto più ristretto rispetto al loro uso quotidiano;
• solo alcuni termini associati alla gestione delle risorse umane di progetto e alla
gestione della comunicazione di progetto, in quanto la maggior parte dei termini
usati in queste aree non differiscono in modo sostanziale dal loro uso
quotidiano;
• solo alcuni termini associati alla gestione dei costi di progetto, alla gestione
dell’integrazione di progetto e alla gestione dell’approvvigionamento di
progetto, in quanto la maggior parte dei termini utilizzati in queste aree ha infatti
un significato più ristretto e specifico nella propria area applicativa.
®
Glossario
2. ACRONIMI COMUNI
AC Actual Cost / Costo effettivo
ACWP Actual Cost of Work Performed / Costo effettivo del lavoro eseguito
AD Activity Description / Descrizione dell’attività
ADM Arrow Diagramming Method / Metodo del diagramma a frecce
AE Apportioned Effort / Impegno distribuito
AF Actual Finish Date / Data di fine effettiva
AOA Activity-On-Arrow / Attività su freccia
AON Activity-On-Node / Attività su nodo
AS Actual Start Date / Data d’inizio effettiva
BAC Budget At Completion / Budget al completamento
BCWP Budgeted Cost of Work Performed / Costo preventivato del lavoro
eseguito
BCWS Budgeted Cots of Work Scheduled / Costo preventivato del lavoro
programmato
BOM Bill Of Materials / Distinta base
CA Control Account / Punto di controllo
CAP Control Account Plan / Piano dei punti di controllo
CCB Change Control Board / Comitato gestione modifiche
COQ Cost of Quality / Costo della qualità
CPF Cost-Plus-Fee / Contratto a rimborso spese più quota variabile
CPFF Cost Plus Fixed Fee / Contratto a rimborso spese più quota fissa
CPI Cost Performance Index / Indice di efficienza dei costi
CPIF Cost Plus Incentive Fee / Contratto a rimborso spese più incentivo
CPM Critical Path Method / Metodo del percorso critico
CPPC Cost-Plus-Percentage of Cost / Contratto a rimborso spese più
percentuale sui costi
CV Cost Variance / Scostamento dei costi
CWBS Contract Work Breakdown Structure / WBS del contratto
DD Data Date / Data di aggiornamento
DU Duration / Durata
DUR Duration / Durata
EAC Estimate At Completion / Stima al completamento
EF Early Finish Date / Data di fine minima
EMV Expected Monetary Value / Valore monetario atteso
ES Early Start Date / Data di inizio minima
ETC Estimate to Complete / Stima a finire
EV Earned Value / Earned Value
EVM Earned Value Management / Metodo dell'Earned Value
EVT Earned Value Technique / Tecnica dell'Earned Value
FF Finish-to-Finish / Fine-fine
FF Free Float / Free Float
FFP Firm Fixed Price / Contratto a prezzo fisso
FMEA Failure Mode and Effect Analysis / Failure Mode and Effect Analysis
FPIF Fixed Price Incentive Fee / Contratto a prezzo prefissato con incentivo
FS Finish-To-Start / Fine-inizio
IFB Invitation For Bid / Bando di gara
LF Late Finish Date / Data di fine massima
®
Una Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione
LOE Level Of Effort / Livello di impegno
LS Late Start Date / Data di inizio massima
OBS Organizational Breakdown Structure / Struttura di scomposizione
dell'organizzazione
OD Original Duration / Durata originale
PC Percent Complete / Percentuale di completamento
PCT Percent Complete / Percentuale di completamento
PDM Precedence Diagramming Method / Metodo del diagramma di
precedenza
PF Planned Finish Date / Data di fine pianificata
PM Project Management / Project Management
PM Project Manager / Project manager
PMBOK® Project Management Body of Knowledge / Project Management Body of
Knowledge
PMIS Project Management Information System / Sistema informativo di Project
Management
PMO Program Management Office / Program Management Office
PMO Project Management Office / Project Management Office
PMP® Project Management Professional / Project Management Professional
PS Planned Start Date / Data d’inizio pianificata
PSWBS Project Summary Work Breakdown Structure / WBS di riepilogo del
progetto
PV Planned Value / Valore pianificato
QA Quality Assurance / Assicurazione qualità
QC Quality Control / Controllo qualità
RAM Responsibility Assignment Matrix / Matrice assegnazione responsabilità
RBS Resource Breakdown Structure / Struttura di scomposizione delle risorse
RBS Risk Breakdown Structure / Struttura di scomposizione dei rischi
RD Remaining Duration / Durata residua
RFP Request For Proposal / Richiesta d'offerta
RFQ Request For Quotation / Richiesta di preventivo
SF Scheduled Finish date / Data di fine pianificata
SF Start-to-Finish / Inizio-fine
SOW Statement Of Work / Capitolato
SPI Schedule Performance Index / Indice di efficienza della schedulazione
SS Scheduled Start date / Data di inizio schedulata
SS Start-to-Start / Inizio-inizio
SV Schedule Variance / Scostamento dei tempi
Glossario
SWOT Strengths, Weaknesses, Opportunities, and Threats / Punti di forza,
debolezze, opportunità e minacce
TC Target Completion Date / Data obiettivo di completamento
TF Target Finish date / Data obiettivo di fine
TF Total Float / Total Float
T&M Time and Material / Time and Material
TQM Total Quality Management / Gestione qualità totale
TS Target Start Date / Data obiettivo di inizio
VE Value Engineering / Ingegneria del valore
WBS Work Breakdown Structure / WBS (Struttura di scomposizione del
lavoro)
®
Glossario
3. DEFINIZIONI
La voci incluse in questo glossario, in un dizionario potrebbero avere definizioni più
ampie e talvolta diverse.
Per le definizioni riportate in questo glossario sono state adottate le convenzioni
descritte di seguito.
• I termini utilizzati per definire un altro termine, ma che possiedono anche una
definizione propria, sono riportati in corsivo.
♦ Se una voce di glossario è presente più volte in una determinata definizione,
questa viene riportata in corsivo soltanto la prima volta.
♦ In alcuni casi, una sola voce di glossario è composta da più parole (ad es.
Pianificazione della risposta ai rischi)
♦ In molti casi, all'interno di una determinata definizione sono presenti più
voci di glossario una di seguito all'altra. Ad esempio, la stringa stima della
durata è composta da due voci di glossario, ovvero “stima” e “durata”.
♦ - Alcune definizioni contengono anche una stringa di parole
consecutive riportate in corsivo (non separate da virgola) che rappresentano
più voci di glossario una di seguito all'altra, di cui almeno una è costituita
da più termini. Ad esempio, la voce data di fine massima del metodo del
percorso critico è composta da due voci incluse nel glossario, ovvero “Data
di fine massima” e “ Metodo del percorso critico”. In questi casi, dopo
l'ultima parola in corsivo viene inserito un asterisco (*) che indica la
presenza di più voci di glossario una di seguito all'altra.
• Nel glossario, non sono state riportate le definizioni dei sinonimi; il lettore viene
indirizzato al termine più comunemente usato (ad es. vedere termine più usato).
• I termini associati ad altri termini, ma che non sono loro sinonimi, contengono
un rimando alla fine della definizione (ad es. vedere anche termine associato).
®
Accantonamento per contingency / Contingency Allowance. Vedere riserva.
Accettare / Accept. Atto mediante il quale si riceve o si riconosce formalmente qualcosa e si concorda
di ritenerlo vero, integro, idoneo o completo.
Accettare i rischi / Risk Acceptance [tecnica]. Tecnica di pianificazione della risposta ai rischi* che
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 un’altra strategia di risposta appropriata.
Accettazione / Acceptance. Vedere accettare.
Acquirente / Buyer. Acquirente dei prodotti, servizi o risultati per un'organizzazione.
Acquisizione del gruppo di progetto / Acquire Project Team [processo]. Processo in cui si
reperiscono le risorse umane necessarie per portare a termine il progetto.
Affidabilità / Reliability. Probabilità che un prodotto svolga le proprie funzioni in determinate
condizioni per un determinato lasso di tempo.
Allocazione dei costi / Cost Budgeting [processo]. Processo di aggregazione dei costi stimati delle
singole attività o dei Work Package per determinare una baseline dei costi.
Ambito / Scope. Somma dei prodotti, servizi e risultati che costituiscono un progetto. Vedere anche
ambito del progetto e specifiche di prodotto.
Ambito del progetto / Project Scope. Lavoro da svolgere per fornire un prodotto, un servizio o un
risultato con le caratteristiche e le funzioni specificate.
Amministrazione del contratto / Contract Administration [processo]. Processo di gestione del
contratto e della relazione tra acquirente e fornitore, di analisi e documentazione della qualità delle
prestazioni del fornitore per determinare eventuali azioni correttive e stabilire una base per le
relazioni future con il fornitore, di gestione delle modifiche relative al contratto e, se necessario, di
gestione delle relazioni contrattuali con un acquirente esterno al progetto.
Analisi degli assunti / Assumptions Analysis [tecnica]. Tecnica che esamina l'accuratezza degli
assunti e identifica i rischi del progetto dovuti alla mancanza di precisione, coerenza o
completezza degli assunti.
Analisi del reticolo / Network Analysis. Vedere analisi del reticolo di schedulazione.
Analisi del reticolo di schedulazione / Schedule Network Analysis [tecnica]. Tecnica di
identificazione delle date di inizio minime e massime* e delle date di fine minime e massime* per
le parti non completate delle attività schedulate del progetto. Vedere anche metodo del percorso
critico, metodo del Critical Chain, analisi what-if e livellamento delle risorse.
Analisi del valore monetario atteso (EMV) / Expected Monetary Value (EMV) Analysis. Tecnica
statistica di calcolo del risultato medio utilizzata quando le previsioni future comprendono
situazioni che potrebbero verificarsi o meno. Questa tecnica si utilizza solitamente nell'analisi
dell’albero delle decisioni. Per l'analisi dei rischi di costo e di schedulazione invece, si consiglia
sempre la creazione di modelli e la simulazione, perché sono più efficaci e meno soggetti ad
applicazioni improprie rispetto all'analisi del valore monetario atteso.
Analisi dell’albero delle decisioni / Decision Tree Analysis [tecnica]. L’albero delle decisioni è un
diagramma che descrive una decisione in esame e le implicazioni della scelta delle varie alternative Glossario
disponibili. Viene utilizzato quando le prospettive future o i risultati delle azioni sono incerti.
Unisce le probabilità, i costi o i benefici di ciascun percorso logico di eventi e di decisioni future e
utilizza l'analisi del valore monetario atteso per consentire all'organizzazione di identificare i
valori relativi delle possibili azioni alternative. Vedere anche analisi del valore monetario atteso.
Analisi della riserva / Reserve Analysis [tecnica]. Tecnica analitica per determinare le caratteristiche
e le relazioni essenziali tra i componenti del piano di Project Management allo scopo di creare una
riserva per la durata della schedulazione, il budget, il costo stimato o i fondi di un progetto.
Analisi della schedulazione / Schedule Analysis. Vedere analisi del reticolo di schedulazione.
Analisi delle cause originarie / Root Cause Analysis [tecnica]. Tecnica analitica utilizzata per
determinare la ragione essenziale alla base di uno scostamento, un difetto o un rischio. Una causa
originaria può essere alla radice di più di uno scostamento, difetto o rischio.
®
Glossario
Analisi delle tendenze / Trend Analysis [tecnica]. Tecnica analitica che fa uso di modelli matematici
per fare previsioni in base a risultati storici. Tale metodo consente di determinare lo scostamento
dalla baseline di un parametro di budget, costo, schedulazione o ambito utilizzando dati di periodi
di verifica dell'avanzamento del lavoro precedenti e facendo previsioni sull'entità dello
scostamento del parametro dalla baseline in un dato momento futuro del progetto, assumendo che
non avvengano modifiche nell'esecuzione del progetto.
Analisi dello scostamento / Variance Analysis [tecnica]. Metodo nel quale si suddivide lo
scostamento totale, che comprende variabili di ambito, costo e schedulazione, negli scostamenti dei
singoli componenti, per associarli ai fattori che modificano le variabili di ambito, costo e
schedulazione.
Analisi di sensitività / Sensitivity Analysis. Analisi quantitativa del rischio e tecnica di modellazione
utilizzate per la determinazione dei rischi con un maggiore impatto potenziale sul progetto. Prende
in considerazione il grado di incidenza dell'incertezza di ogni elemento del progetto sull'obiettivo
esaminato quando tutti gli altri elementi incerti si mantengono sul valore della baseline. La
visualizzazione tipica dei risultati è rappresentata da un grafico a barre.
Analisi Monte Carlo / Monte Carlo Analysis. Tecnica che calcola, in modo reiterato, il costo del
progetto o la schedulazione di progetto utilizzando in input dei valori selezionati in modo casuale
da distribuzioni probabilistiche di costi e di durate possibili, per calcolare una distribuzione
possibile di costi totali e date di completamento del progetto.
Analisi qualitativa del rischio / Qualitative Risk Analysis [processo]. Processo che assegna ai rischi
una priorità, mediante la valutazione e la combinazione della loro probabilità e dell’impatto, per
poi decidere se condurre ulteriori analisi o azioni.
Analisi quantitativa del rischio / Quantitative Risk Analysis [processo]. Processo di analisi
numerica dell'effetto dei rischi identificati sugli obiettivi complessivi del progetto.
Anello del reticolo / Network Loop. Percorso del reticolo della schedulazione che passa due volte
dallo stesso nodo. Non è possibile analizzare gli anelli di reticolo utilizzando le tradizionali
tecniche di analisi del reticolo di schedulazione come il metodo del percorso critico.
Approvare / Approve. Atto mediante il quale si conferma, sancisce, rettifica o accetta qualcosa in
modo formale.
Approvazione / Approval. Vedere approvare.
Area applicativa / Application Area. Categoria di progetti caratterizzati da componenti comuni
estremamente importanti per questi progetti, ma non necessari o presenti in tutti i progetti. Le aree
applicative vengono definite in funzione del prodotto (ossia per tecnologie o metodi di produzione
simili), del tipo di cliente (ossia interno o esterno, pubblico o privato) o del settore industriale (vale
a dire servizi pubblici, industria automobilistica, industria aerospaziale, settore informatico). È
possibile che si verifichino delle sovrapposizioni tra le aree applicative.
Area di conoscenza di Project Management / Project Management Knowledge Area. Area
identificata del Project Management definita dai rispettivi requisiti di conoscenza e descritta in
termini di processi, pratiche, input, output, strumenti e tecniche componenti.
Area di conoscenza, Project Management / Knowledge Area, Project Management. Vedere Area
di conoscenza di Project Management.
Asset dei processi organizzativi / Organizational Process Assets [output/input]. Alcuni o tutti gli
asset collegati ai processi, provenienti da alcune o da tutte le organizzazioni coinvolte nel progetto,
che vengono o che possono essere utilizzati per influire sulla buona riuscita del progetto. Tali asset
includono piani, criteri, procedure e direttive sia formali che informali, nonché le knowledge base
delle organizzazioni come le lesson learned e i dati storici.
Assunti / Assumptions [output/input]. Gli assunti sono fattori che per questioni di pianificazione
vengono ritenuti veri, reali o certi anche se non si dispone di prove o dimostrazioni. Gli assunti
influiscono su tutti gli aspetti della pianificazione di progetto e fanno parte dell’elaborazione
progressiva del progetto. I gruppi di progetto spesso identificano, documentano e convalidano gli
assunti nel corso del processo di pianificazione. Gli assunti generalmente implicano un certo
livello di rischio.
®
Attività / Activity. Un componente del lavoro eseguito nel corso di un progetto. Vedere anche attività
schedulata.
Attività critica / Critical Activity. Qualsiasi attività schedulata su un percorso critico in una
schedulazione di progetto, comunemente determinata mediante l’uso del metodo del percorso
critico. Sebbene nel linguaggio comune alcune attività vengano definite “critiche” senza che si
trovino sul percorso critico, questa ultima accezione del termine viene raramente impiegata nel
contesto dei progetti.
Attività di riepilogo / Summary Activity. Gruppo di attività schedulate collegate tra loro, riunite in
una determinata forma di sintesi e visualizzate/presentate come un'unica attività. Vedere anche
sottoprogetto e sottoreticolo.
Attività fittizia / Dummy Activity. Attività schedulata di durata nulla utilizzata per mostrare una
relazione logica nel metodo del diagramma a frecce. Le attività fittizie, utilizzate quando le
relazioni logiche non possono essere descritte interamente e correttamente con le normali frecce di
attività schedulate, vengono rappresentate graficamente tramite una freccia tratteggiata.
Attività predecessore / Predecessor Activity. Attività schedulata che determina quando può iniziare o
terminare l'attività successore logica.
Attività quasi critica / Near-Critical Activity. Attività schedulata caratterizzata da un Total Float
basso. Il concetto di "quasi critico" è egualmente valido per un'attività schedulata o un percorso
del reticolo della schedulazione. Il limite sotto il quale il Total Float è considerato quasi critico
dipende dal parere di esperti e varia da progetto a progetto.
Attività schedulata / Schedule Activity. Un componente schedulato discreto del lavoro eseguito nel
corso di un progetto. Un'attività schedulata ha generalmente una durata, un costo e dei requisiti di
risorse stimati. Le attività schedulate vengono associate ad altre attività schedulate o milestone di
schedulazione attraverso relazioni logiche e derivano dai Work Package.
Attività sommario / Hammock Activity. Vedere attività di riepilogo.
Attività su freccia (AOA) / Activity-on-Arrow (AOA). Vedere metodo del diagramma a frecce.
Attività su nodo (AON) / Activity-on-Node (AON). Vedere metodo del diagramma di precedenza.
Attività successore / Successor Activity. Attività schedulata che segue un'attività predecessore, come
indicato dalla relazione logica che le unisce.
Attributi delle attività / Activity Attributes [output/input]. Più attributi associati a ciascuna attività
schedulata che possono essere riportati nell'elenco delle attività. Tali attributi includono codici
attività, attività predecessore, attività successore, relazione logica, lead e lag, requisiti delle
risorse, scadenze imposte, vincoli e assunti.
Autorità / Authority. Il diritto di utilizzare le risorse del progetto*, impiegare i fondi, prendere
decisioni o dare approvazioni.
Autorizzazione del lavoro / Work Authorization [tecnica]. Permesso e direttiva, solitamente redatti
per iscritto, per iniziare il lavoro relativo ad un'attività schedulata specifica, a un Work Package o
ad un punto di controllo. Si tratta di un metodo per sancire il lavoro di progetto al fine di garantire
che il lavoro venga effettuato dall'organizzazione specificata, al momento giusto e secondo la Glossario
giusta sequenza.
Avvio del progetto / Project Initiation. Avvio di un processo che può comportare l'autorizzazione a
un nuovo progetto e la definizione del relativo ambito.
Azienda/ Enterprise. Azienda, impresa, ditta, associazione, ente giuridico o agenzia governativa.
Azione correttiva / Corrective Action. Istruzione documentata per l'esecuzione del lavoro del
progetto diretta ad allineare le prestazioni future previste per il lavoro del progetto con il piano di
Project Management.
Azione preventiva / Preventive Action. Istruzione documentata per l'esecuzione di un'attività
finalizzata a ridurre le possibilità di subire le conseguenze negative associate ai rischi del
progetto*.
®
Glossario
Bando di gara (IFB) / Invitation for Bid (IFB). Generalmente questo termine equivale a richiesta
d'offerta. Tuttavia, in alcune aree applicative, può avere un significato più limitato o specifico.
Baseline / Baseline. Piano temporale approvato (di un progetto, un componente della WBS, un Work
Package o un'attività schedulata), con o senza le modifiche di ambito del progetto, di costo, di
schedulazione e le modifiche tecniche approvate. In genere, il termine fa riferimento alla baseline
attuale, ma potrebbe anche riferirsi a quella originale o ad altre baseline ed è normalmente seguito
da una specificazione (ad es. baseline dei costi, baseline della schedulazione, baseline di
misurazione delle prestazioni, baseline tecnica). Vedere anche baseline di misurazione delle
prestazioni.
Baseline dei costi / Cost Baseline. Vedere baseline.
Baseline dell'ambito / Scope Baseline. Vedere baseline.
Baseline di misurazione delle prestazioni / Performance Measurement Baseline. Piano approvato
per il lavoro del progetto con cui viene confrontata l'esecuzione del progetto stesso e vengono
misurati gli scostamenti per il controllo di gestione. La baseline di misurazione delle prestazioni
consente in genere di integrare i parametri di ambito, schedulazione e costo di un progetto, ma può
anche includere parametri tecnici e di qualità.
Beni / Goods. Prodotti, merci, mercanzia.
Brainstorming / Brainstorming [tecnica]. Tecnica generale di raccolta dati e di creatività che
consente di identificare i rischi, le idee o le soluzioni alle questioni ricorrendo a membri del gruppo
di lavoro o a esperti del settore. Generalmente, una seduta di brainstorming viene strutturata in
modo che le idee di ciascun partecipante siano registrate per essere successivamente analizzate.
Budget / Budget. Stima approvata per il progetto, per qualsiasi componente della WBS o attività
schedulata. Vedere anche stima.
Budget al completamento (BAC) / Budget at Completion (BAC). Somma di tutti i valori del budget
stabiliti per il lavoro da eseguire nell'ambito di un progetto, di un componente della WBS o di
un'attività schedulata. Il valore pianificato (PV) totale del progetto.
Buffer / Buffer. Vedere riserva.
Calcolo a ritroso / Backward Pass. Calcolo delle date di fine massime e delle date di inizio massime
per le porzioni non completate delle attività schedulate. Si determina andando a ritroso attraverso
la logica del reticolo della schedulazione a partire dalla data di fine del progetto. La data di fine
può essere stata calcolata nel calcolo in avanti oppure può essere definita dal cliente o dallo
sponsor. Vedere anche analisi del reticolo di schedulazione.
Calcolo in avanti / Forward Pass. Calcolo della data di inizio minima e della data di fine minima per
le parti non completate di tutte le attività del reticolo. Vedere anche analisi del reticolo di
schedulazione e calcolo a ritroso.
Calendario delle risorse / Resource Calendar. Calendario dei giorni feriali e festivi in base al quale
vengono determinate le date in cui ogni specifica risorsa è attiva o inattiva. In genere mostra le
ferie e i periodi di disponibilità delle risorse. Vedere anche calendario di progetto.
Calendario di progetto / Project Calendar. Calendario composto dai giorni lavorativi o dai turni che
stabiliscono le date in cui le attività schedulate devono essere svolte e dai giorni non lavorativi che
determinano le date in cui le attività schedulate sono inattive. In genere definisce i giorni di
vacanza, i fine settimana e gli orari dei turni. Vedere anche calendario delle risorse.
Cambiamento non controllato dell'ambito / Scope Creep. Aggiunta di caratteristiche e funzioni
(ambito del progetto) senza considerare gli effetti su tempi, costi e risorse o senza l'approvazione
del cliente.
Capitolato (SOW) / Statement of Work (SOW). Descrizione narrativa di prodotti, servizi o risultati
che devono essere forniti.
Capitolato contrattuale (SOW) / Contract Statement of Work (SOW) [output/input]. Descrizione
in forma narrativa di prodotti, servizi o risultati che devono essere forniti ai sensi del contratto.
®
Carta di controllo / Control Chart [strumento]. Visualizzazione grafica dei dati di processo nel corso
del tempo confrontati con i limiti di controllo stabiliti e dotata di una linea centrale che consente di
individuare una tendenza dei valori tracciati rispetto a ciascun limite di controllo.
Categoria di rischio / Risk Category. Gruppo di potenziali cause di rischio. Le cause di rischio
possono essere suddivise in categorie quali ad es. i rischi tecnici, esterni, organizzativi, ambientali
o di Project Management. Una categoria può a sua volta comprendere sottocategorie come
maturità tecnica, tempo atmosferico o stime aggressive. Vedere anche struttura di scomposizione
dei rischi.
Causa comune / Common Cause. Fonte di variazione intrinseca al sistema e prevedibile. In una carta
di controllo, questa causa fa parte della variabilità casuale dei processi (ad es. la variazione da un
processo che potrebbe essere considerata normale o non anomala) e viene indicata da una serie
casuale di punti all'interno dei limiti di controllo. Denominata anche causa accidentale. Diverso da
causa speciale.
Causa straordinaria / Special Cause. Fonte di cambiamento estranea al sistema, non prevedibile e
saltuaria. Può essere imputata a un difetto del sistema. In una carta di controllo, viene indicata da
punti oltre i limiti di controllo o da sequenze non casuali di punti all'interno dei limiti di controllo.
Denominata anche causa specifica. Diverso da causa comune.
Cauzione / Retainage. Parte del pagamento di un contratto tenuta in sospeso fino al completamento
del contratto per assicurare il pieno rispetto dei termini contrattuali.
Charter / Charter. Vedere Project Charter.
Chiudere il progetto / Close Project [processo]. Processo di completamento di tutte le attività
appartenenti ai gruppi di processi del progetto per chiudere a livello formale il progetto o la fase.
Chiusura del contratto / Contract Closure [processo]. Processo di completamento e di saldo del
contratto, compresa la risoluzione di eventuali questioni aperte, e di chiusura di ciascun contratto.
Ciclo di vita / Life Cycle. Vedere ciclo di vita del progetto.
Ciclo di vita del progetto / Project Life Cycle. Raccolta di fasi di progetto, generalmente in sequenza,
il cui nome e numero sono determinati dalle esigenze di controllo dell’organizzazione o delle
organizzazioni coinvolte nel progetto. È possibile documentare un ciclo di vita mediante una
metodologia.
Ciclo di vita di prodotto / Product Life Cycle. Insieme di fasi di prodotto* generalmente in sequenza
e non sovrapposte il cui nome e numero dipendono dalle esigenze di produzione e di controllo
dell’organizzazione. L'ultima fase del ciclo di vita del prodotto è in genere rappresentata dal
deterioramento o dell'estinzione del prodotto stesso. Generalmente, il ciclo di vita del progetto può
essere contenuto in uno o più cicli di vita di prodotto.
Cliente / Customer. La persona o l'organizzazione che utilizzerà il prodotto, il servizio o il risultato
del progetto. Vedere anche utente.
Codice attività / Activity Code. Uno o più valori numerici o alfabetici che consentono di identificare
le caratteristiche del lavoro o di suddividere in categorie le attività schedulate per poter filtrare e
ordinare le attività incluse nei rapporti.
Glossario
Codice di classificazione / Code of Accounts [strumento]. Qualsiasi sistema numerico utilizzato per
identificare in modo univoco ciascun componente della WBS. Diverso da piano dei conti.
Co-location / Co-location [tecnica]. Strategia di collocamento organizzativo per la quale i membri del
gruppo di progetto vengono fisicamente posti nei pressi l'uno dell'altro per migliorare la
comunicazione, i rapporti professionali e la produttività.
Comitato gestione modifiche (CCB) / Change Control Board (CCB). Gruppo di stakeholder,
formalmente costituito, avente la responsabilità di revisionare, valutare, approvare, ritardare o
rifiutare le modifiche sul progetto, i cui consigli e decisioni vengono registrati.
Componente / Component. Un componente, un elemento di un insieme completo.
Componente della WBS / Work Breakdown Structure Component. Voce della WBS che può
trovarsi a qualsiasi livello.
®
Glossario
Compressione dei tempi / Crashing [tecnica]. Un tipo specifico di tecnica di compressione della
schedulazione del progetto eseguita mediante la diminuzione della durata della schedulazione di
progetto* dopo l'analisi di un certo numero di alternative allo scopo di determinare come ottenere
la massima compressione della durata della schedulazione al minor costo aggiuntivo. I sistemi
adottati più comunemente per la compressione dei tempi di una schedulazione prevedono la
riduzione delle durate delle attività schedulate e l'aumento delle risorse assegnate alle attività
schedulate. Vedere compressione della schedulazione e vedere anche Fast Tracking.
Compressione della schedulazione / Schedule Compression [tecnica]. Riduzione della durata della
schedulazione di progetto senza ridurre l'ambito del progetto. Vedere anche compressione dei
tempi e Fast Tracking.
Comunicazione / Communication. Processo attraverso il quale avviene lo scambio di informazioni
tra persone che utilizzano un sistema comune di simboli, segni o comportamenti.
Conoscenza / Knowledge. Conoscenza approfondita acquisita mediante esperienza, istruzione,
osservazione o indagine che consente di comprendere un processo, una pratica, una tecnica o
l'utilizzo di uno strumento.
Contingency / Contingency. Vedere riserva.
Contratto / Contract [output/input]. Un contratto è un accordo vincolante per entrambe le parti che
obbliga il fornitore a fornire il prodotto, il servizio o il risultato e obbliga l'acquirente a pagare per
il bene o servizio ricevuto.
Contratto a prezzo fisso (FFP) / Firm Fixed-Price (FFP) Contract. Tipo di contratto a prezzo fisso
in cui l’acquirente paga al fornitore un importo prestabilito (definito dal contratto)
indipendentemente dai costi sostenuti dal fornitore.
Contratto a prezzo prefissato con incentivo (FPIF) / Fixed-Price-Incentive-Fee (FPIF) Contract.
Tipo di contratto in cui l’acquirente paga al fornitore un importo prestabilito (definito dal
contratto) e il fornitore può ricevere una somma ulteriore se soddisfa determinati criteri di
prestazione.
Contratto a prezzo prefissato o a importo forfettario / Fixed-Price or Lump-Sum Contract. Tipo
di contratto che prevede un prezzo totale prefissato per un prodotto definito. I contratti a prezzo
prefissato possono anche prevedere incentivi per il raggiungimento o il superamento di determinati
obiettivi di progetto, come gli obiettivi di tempo. La forma più semplice di un contratto a prezzo
prefissato è un ordine di acquisto.
Contratto a rimborso spese più incentivo (CPIF) / Cost-Plus-Incentive-Fee (CPIF) Contract. Tipo
di contratto con rimborso spese nel quale l'acquirente rimborsa al fornitore le spese ammissibili (le
spese ammissibili vengono definite nel contratto) e il fornitore percepisce un profitto solo se
soddisfa determinati criteri di prestazione.
Contratto a rimborso spese più percentuale sui costi (CPPC) / Cost-Plus-
Percentage of Cost (CPPC). Vedere contratto a rimborso spese più quota variabile.
Contratto a rimborso spese più quota fissa (CPFF) / Cost-Plus-Fixed-Fee (CPFF) Contract. Tipo
di contratto con rimborso spese nel quale l'acquirente rimborsa al fornitore le spese ammissibili (le
spese ammissibili vengono definite nel contratto) più un importo fisso di profitto (compenso).
Contratto a rimborso spese più quota variabile (CPF) / Cost-Plus-Fee (CPF). Tipo di contratto con
rimborso spese nel quale l'acquirente rimborsa le spese ammissibili sostenute dal fornitore per
l'esecuzione del lavoro previsto dal contratto e il fornitore riceve un compenso variabile calcolato
come percentuale concordata dei costi. Il compenso varia in base al costo effettivo.
Contratto con rimborso spese / Cost-Reimbursable Contract. Tipo di contratto che prevede il
pagamento (rimborso) da parte dell'acquirente 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, come gli stipendi per il personale a tempo pieno impiegato per il progetto. I costi
indiretti, denominati anche spese generali e di amministrazione, sono i costi assegnati al progetto
dalla Performing Organization come costo legato allo svolgimento delle attività, ad es. gli stipendi
per i dirigenti indirettamente coinvolti nel progetto e i costi per le apparecchiature elettriche
®
utilizzate dall'ufficio. 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 es. obiettivi di tempo o di costo
totale, il fornitore riceve dall'acquirente un incentivo o un premio.
Contratto Time and Material (T&M) / Time and Material (T&M) Contract. Tipo di contratto che
rappresenta un accordo ibrido contenente aspetti di un contratto con rimborso spese e di uno a
prezzo prefissato. I contratti Time and Material, cioè per durata e materiali, sono simili agli accordi
con rimborso spese nel senso che sono aperti, poiché il valore completo dell’accordo non è stato
definito al momento dell’aggiudicazione. Questi contratti possono quindi aumentare di valore
come se fossero accordi a rimborso di costo. Tuttavia, assomigliano anche agli accordi a prezzo
prefissato. Ad esempio, le tariffe unitarie vengono predefinite dall'acquirente e dal fornitore, se
entrambe le parti riconoscono le tariffe degli ingegneri "senior".
Controllare /Controlling. Vedere controllo.
Controllo / Control [tecnica]. Confronto tra le prestazioni effettive e le prestazioni pianificate, analisi
degli scostamenti, valutazione delle tendenze per favorire un miglioramento dei processi,
valutazione delle possibili alternative e segnalazione dell'azione correttiva appropriata.
Controllo dei costi / Cost Control [processo]. Processo che consente di influire sui fattori
responsabili degli scostamenti e di controllare le modifiche al budget del progetto.
Controllo della schedulazione / Schedule Control [processo]. Processo di controllo delle modifiche
alla schedulazione di progetto.
Controllo dell'ambito / Scope Control [processo]. Processo di controllo dei cambiamenti all'ambito
del progetto.
Controllo delle modifiche / Change Control. Identificazione, documentazione, approvazione, rifiuto
o controllo delle modifiche alle baseline del progetto*.
Controllo integrato delle modifiche / Integrated Change Control [processo]. Processo di revisione
di tutte le richieste di modifica, di approvazione e di controllo delle modifiche apportate ai
deliverable e agli asset dei processi organizzativi.
Convalida / Validation [tecnica]. Tecnica di valutazione di un componente o di un prodotto durante o
al termine di una fase o di un progetto per accertare che soddisfi i requisiti specificati. Diverso da
verifica.
Convergenza di percorsi / Path Convergence. La convergenza si verifica quando percorsi del
reticolo di schedulazione paralleli si fondono o si uniscono nello stesso nodo all'interno del
reticolo di schedulazione del progetto. La convergenza di percorsi è caratterizzata da un'attività
schedulata con più di una attività predecessore.
Correzione dei difetti / Defect Repair. Identificazione documentata a livello formale di un difetto
registrato in un componente del progetto con la richiesta di riparare il difetto o di sostituire
completamente il componente.
Corrispettivo / Compensation. Qualcosa che viene dato o ricevuto, un pagamento o un compenso, in
genere si tratta di una somma in denaro o di merce in natura per prodotti, servizi o risultati forniti o
Glossario
ricevuti.
Costo / Cost. Il valore monetario o il prezzo di un'attività o componente del progetto* che include il
valore monetario delle risorse necessarie per eseguire e completare l'attività, o il componente, o
per produrre il componente. Un costo può essere dato da una combinazione di elementi di costo,
quali la spesa per la manodopera diretta e altri costi diretti, la spesa per la manodopera indiretta e
altri costi indiretti e il prezzo d'acquisto. (Ciononostante, nel metodo dell'Earned Value, il costo
rappresenta talvolta soltanto le ore di manodopera senza la relativa conversione in valore
monetario.) Vedere anche costo effettivo e stima.
Costo della qualità / Cost of Quality (COQ) [tecnica]. Determinazione dei costi sostenuti per
assicurare la qualità. I costi di prevenzione e di valutazione (costo della conformità) comprendono
le spese sostenute per la pianificazione della qualità, il controllo qualità (QC) e l'assicurazione
qualità necessari a garantire la conformità ai requisiti (ad es. formazione, sistemi QC ecc.). I costi
®
Glossario
per inadempienza (mancata conformità) comprendono le spese sostenute per la rilavorazione dei
prodotti, dei componenti o dei processi non conformi, i costi del lavoro in garanzia, degli scarti e
della perdita di reputazione.
Costo effettivo (AC) / Actual Cost (AC). I costi totali effettivamente sostenuti e registrati per svolgere
un lavoro in un determinato periodo di tempo per un'attività schedulata o un componente della
WBS. Il costo effettivo può essere dato esclusivamente dalle ore richieste per la manodopera, dai
costi diretti o da una somma di tutti i costi compresi quelli indiretti. Definito anche come costo
effettivo del lavoro eseguito (ACWP). Vedere anche metodo dell'Earned Value e tecnica
dell'Earned Value.
Costo effettivo del lavoro eseguito (ACWP) / Actual Cost of Work Performed (ACWP). Vedere
costo effettivo (AC).
Costo preventivato del lavoro eseguito (BCWP) / Budgeted Cost of Work Performed (BCWP).
Vedere Earned Value (EV)
Costo preventivato del lavoro schedulato (BCWS) / Budgeted Cost of Work Scheduled (BCWS).
Vedere valore pianificato (PV)
Creare la WBS / Create WBS (Work Breakdown Structure) [processo]. Processo di suddivisione
dei principali deliverable del progetto e del lavoro incluso nel progetto in componenti più piccoli e
quindi maggiormente gestibili.
Criteri / Criteria. Gli standard, le regole o i test sui quali si basa un giudizio o una decisione o
mediante i quali è possibile valutare un prodotto, servizio, risultato o processo.
Criteri di accettazione / Acceptance Criteria. I criteri, tra cui i requisiti di prestazione e le
condizioni fondamentali, a cui occorre conformarsi per accettare i deliverable di progetto.
Curva a S / S-Curve. Visualizzazione grafica del totale di costi, ore di manodopera, percentuale di
lavoro o altre quantità tracciate in un quadro temporale. Il nome deriva dalla forma a “S” della
curva (più piatta all’inizio e alla fine, più pronunciata nella parte centrale) prodotta su un progetto
che parte lentamente, accelera e poi termina progressivamente. È anche un termine usato per la
distribuzione cumulativa delle probabilità che è il risultato di una simulazione, uno strumento
dell’analisi quantitativa del rischio.
Dalla parte del cliente / Voice of the Customer. Tecnica di programmazione utilizzata per realizzare
prodotti, servizi e risultati che soddisfino pienamente le esigenze dei clienti traducendo tali
esigenze nei requisiti tecnici idonei per ogni fase dello sviluppo del prodotto.
Data / Date. Un termine che rappresenta il giorno, il mese e l'anno di calendario e, in alcuni casi, l'ora
del giorno.
Data corrente / Time-Now Date. Vedere data di aggiornamento.
Data d’inizio / Start Date. Momento in cui ha inizio un'attività schedulata, di solito classificata come:
effettiva, pianificata, stimata, schedulata, minima, massima, obiettivo, baseline o attuale.
Data d’inizio attuale / Current Start Date. Stima attuale del momento cui un'attività schedulata verrà
avviata e che riflette l'avanzamento del lavoro. Vedere anche data d’inizio schedulata e data di
inizio di baseline.
Data d’inizio effettiva (AS) / Actual Start Date (AS). Il momento in cui ha effettivamente avuto
inizio il lavoro previsto per un'attività schedulata.
Data d’inizio pianificata (PS) / Planned Start Date (PS). Vedere data d’inizio schedulata.
Data d’inizio schedulata (SS) / Scheduled Start Date (SS). Il momento in cui è previsto che inizi il
lavoro di un'attività schedulata. La data d’inizio schedulata rientra generalmente nell’ambito delle
date comprese tra la data di inizio minima e la data di inizio massima. Questo valore può
rispecchiare il livellamento delle risorse in caso di scarsità di risorse. Detta anche data d'inizio
pianificata.
Data di aggiornamento (DD) / Data Date (DD). Data fino alla quale il sistema di reporting di un
progetto ha fornito l’effettivo stato di avanzamento e i risultati. In alcuni sistemi di reporting, le
informazioni sullo stato relative alla data di aggiornamento vengono incluse nello storico, mentre
®
in altri sistemi le stesse informazioni vengono inserite nella sezione sui dati futuri. Denominata
anche data di avanzamento e data corrente.
Data di avanzamento / As-of Date. Vedere data di aggiornamento.
Data di fine / Finish Date. Punto temporale associato al completamento di un'attività schedulata.
Generalmente viene abbinata a una delle seguenti specificazioni: effettiva, pianificata, stimata,
minima, massima, di baseline, obiettivo o attuale.
Data di fine attuale / Current Finish Date. Stima attuale del momento cui un'attività schedulata verrà
portata a termine e che riflette l'avanzamento del lavoro. Vedere anche data di fine schedulata e
data di fine di baseline.
Data di fine di baseline / Baseline Finish Date. Data di fine di un'attività schedulata presente nella
baseline della schedulazione approvata. Vedere anche data di fine schedulata.
Data di fine effettiva (AF) / Actual Finish Date (AF). Il momento in cui è effettivamente terminato il
lavoro previsto per un'attività schedulata. (Nota: in alcune aree applicative, l’attività viene
considerata “conclusa” quando il lavoro è “sostanzialmente terminato”.)
Data di fine massima (LF) / Late Finish Date (LF). Nel metodo del percorso critico, il punto
temporale più ritardato possibile in cui un’attività schedulata può essere completata in base alla
logica del reticolo della schedulazione, alla data di completamento del progetto e ad eventuali
vincoli assegnati alle attività schedulate senza violare tali vincoli o ritardare la data di
completamento del progetto. Le date di fine massime vengono determinate nel corso del calcolo a
ritroso del reticolo della schedulazione di progetto.
Data di fine minima (EF) / Early Finish Date (EF). Nel metodo del percorso critico, rappresenta il
momento più prossimo possibile nel quale possono terminare le parti non completate di un'attività
schedulata (o del progetto), in base alla logica del reticolo della schedulazione, alla data di
aggiornamento e ad eventuali vincoli della schedulazione. Le date di fine minime possono variare
con l’avanzamento del progetto e in base alle modifiche apportate al piano di Project Management.
Data di fine pianificata (PF) / Planned Finish Date (PF). Vedere data di fine schedulata.
Data di fine schedulata (SF) / Scheduled Finish Date (SF). Il momento in cui è previsto che termini
il lavoro di un'attività schedulata. La data di fine schedulata rientra generalmente nell’intervallo di
date compreso tra la data di fine minima e la data di fine massima. Questo valore può rispecchiare
il livellamento delle risorse in caso di scarsità di risorse. Detta anche data di fine pianificata.
Data di inizio di baseline / Baseline Start Date. Data d'inizio di un'attività schedulata presente nella
baseline della schedulazione approvata. Vedere anche data d'inizio schedulata.
Data di inizio massima (LS) / Late Start Date (LS). Nel metodo del percorso critico, il punto
temporale più ritardato possibile in cui un’attività schedulata può iniziare in base alla logica del
reticolo della schedulazione, alla data di completamento del progetto e ad eventuali vincoli
assegnati alle attività schedulate senza violare tali vincoli o ritardare la data di completamento del
progetto. Le date di inizio massime vengono determinate nel corso del calcolo a ritroso del
reticolo della schedulazione di progetto.
Data di inizio minima (ES) / Early Start Date (ES). Nel metodo del percorso critico, rappresenta il
Glossario
momento più prossimo possibile nel quale possono avere inizio le parti non completate di
un'attività schedulata (o del progetto), in base alla logica del reticolo della schedulazione, alla data
di aggiornamento e ad eventuali vincoli della schedulazione. Le date di inizio minime possono
variare con l’avanzamento del progetto e in base alle modifiche apportate al piano di Project
Management.
Data imposta / Imposed Date. Data fissata e imposta su un'attività schedulata o una milestone di
schedulazione in genere sotto forma di una data del tipo “iniziare non prima di” e “terminare non
oltre il”.
Data obiettivo di completamento (TC) / Target Completion Date (TC). Data imposta che limita o
modifica l’analisi del reticolo di schedulazione.
Data obiettivo di fine (TF) / Target Finish Date (TF). Data in cui è programmata (stabilita) la fine
del lavoro di un'attività schedulata.
®
Glossario
Data obiettivo di inizio (TS) / Target Start Date (TS). Data in cui è programmato (stabilito) l'inizio
del lavoro di un'attività schedulata.
Database dei rischi / Risk Database. Strumento di raccolta, aggiornamento e analisi dei dati utilizzati
nei processi di gestione del rischio.
Dati storici / Historical Information. Documenti e dati relativi a progetti precedenti compresi file di
progetto, archivi, corrispondenza, contratti chiusi e progetti chiusi.
Definire le attività / Activity Definition [processo]. Il processo di identificazione delle attività
schedulate da eseguire per produrre i deliverable previsti dal progetto.
Definizione dell'ambito / Scope Definition [processo]. Processo di sviluppo di una descrizione
dettagliata dell'ambito del progetto come base per le decisioni future sul progetto.
Deliverable / Deliverable [output/input]. Qualsiasi prodotto, risultato o capacità di fornire un servizio
univoco e verificabile che deve essere realizzato per portare a termine un processo, una fase o un
progetto. Il termine viene spesso usato nell'accezione più circoscritta in relazione a un deliverable
esterno, cioè soggetto ad approvazione da parte dello sponsor o del cliente del progetto. Vedere
anche prodotto, servizio e risultato.
Descrizione della mansione / Position Description [strumento]. Spiegazione dei ruoli e delle
responsabilità di un membro del gruppo di progetto.
Descrizione dell'ambito del progetto / Project Scope Statement [output/input]. Descrizione
dell'ambito del progetto, che comprende i principali deliverable, gli obiettivi del progetto, gli
assunti del progetto, i vincoli del progetto e il capitolato; la descrizione costituisce una base
documentata per le decisioni future da prendere nel corso del progetto e per convalidare e
sviluppare una comprensione comune sull'ambito del progetto tra gli stakeholder. Rappresenta la
definizione dell'ambito del progetto, ovvero ciò che deve essere realizzato.
Descrizione dell'attività (AD) / Activity Description (AD). Breve frase o etichetta prevista per
ciascuna attività schedulata utilizzata in combinazione con un identificativo dell'attività per
differenziare l'attività schedulata del progetto dalle altre attività schedulate. La descrizione
dell’attività generalmente fa riferimento all'ambito del lavoro previsto dall'attività stessa.
Descrizione delle specifiche di prodotto / Product Scope Description. Descrizione documentata in
forma narrativa delle specifiche di prodotto.
Diagramma a barre / Bar Chart [strumento]. Visualizzazione grafica delle informazioni relative alla
schedulazione. Nel tipico diagramma a barre, le attività schedulate o i componenti della WBS sono
elencati a sinistra in verticale, le date in alto in orizzontale e le durate delle attività sono
rappresentate da barre orizzontali posizionate in base alla data. È chiamato anche diagramma di
Gantt.
Diagramma d’influenza / Influence Diagram [strumento]. Rappresentazione grafica delle situazioni
che mostra le influenze casuali, l’ordine temporale degli eventi e altre relazioni tra variabili e
risultati.
Diagramma di Gantt / Gantt Chart. Vedere diagramma a barre.
Diagramma di Pareto / Pareto Chart [strumento]. Istogramma ordinato in base alla frequenza che
indica quanti risultati sono dovuti a ciascuna causa identificata.
Diagramma logico / Logic Diagram. Vedere reticolo di schedulazione del progetto.
Diagramma reticolare della schedulazione su scala temporale / Time-Scaled Schedule Network
Diagram [strumento]. Qualsiasi reticolo di schedulazione del progetto in cui la posizione e la
lunghezza dell'attività schedulata ne rappresentano la durata. È essenzialmente un diagramma a
barre che include la logica del reticolo della schedulazione.
Diagrammi di flusso / Flowcharting [tecnica]. Rappresentazione sotto forma di diagramma degli
input, delle azioni di processo e degli output di uno o più processi interni a un sistema.
Difetto / Defect. Un'imperfezione o una mancanza in un componente del progetto tale da renderlo non
idoneo ai requisiti o alle specifiche di prodotto e da richiederne la riparazione o la sostituzione.
®
Dirigere e gestire l'esecuzione del progetto / Direct and Manage Project Execution [processo].
Processo di esecuzione del lavoro definito nel piano di Project Management che consente di
realizzare i requisiti del progetto specificati nella descrizione dell'ambito del progetto.
Disciplina / Discipline. Settore lavorativo che richiede conoscenze specifiche e che dispone di un
insieme di regole che disciplinano la condotta lavorativa (ad es. ingegneria meccanica,
programmazione informatica, stima dei costi, ecc.).
Distinta base (BOM) / Bill of Materials (BOM). Distinta formale e documentata dei materiali sotto
forma di tabulazione organizzata in ordine gerarchico dei gruppi, dei gruppi secondari e dei
componenti fisici necessari alla creazione del prodotto.
Distribuzione delle informazioni / Information Distribution [processo]. Processo che consente di
rendere disponibili in modo tempestivo le informazioni richieste agli stakeholder di progetto.
Divergenza di percorsi / Path Divergence. La divergenza si verifica quando percorsi del reticolo di
schedulazione paralleli si estendono o vengono generati dallo stesso nodo all'interno del reticolo di
schedulazione del progetto. La divergenza di percorsi è caratterizzata da un'attività schedulata con
più di una attività successore.
Dizionario della WBS / Work Breakdown Structure Dictionary [output/input]. Documento che
descrive ogni componente della WBS. Per ogni componente della WBS, il dizionario comprende
una breve definizione dell'ambito o il capitolato, i deliverable definiti, un elenco delle attività
associate e delle milestone. Inoltre ci possono essere le seguenti informazioni: Performing
Organization, date di inizio e di fine, risorse richieste, stima dei costi, centro di costo,
informazioni sul contratto, requisiti di qualità e riferimenti tecnici per facilitare l'esecuzione del
lavoro.
Documenti di approvvigionamento / Procurement Documents [output/input]. Documenti utilizzati
nelle attività di offerta e proposta, compresi il bando di gara, l'invito alla negoziazione, la richiesta
di informazioni, la richiesta di preventivo, la richiesta d'offerta dell'acquirente e le risposte del
fornitore.
Documento / Document. Un mezzo e le informazioni in esso contenute caratterizzati solitamente da
una certa stabilità e che possono essere letti da una persona o da una macchina. Esempi: piani di
Project Management, specifiche di prodotto, procedure, studi e manuali.
Durata (DU o DUR) / Duration (DU or DUR). Numero totale di periodi lavorativi (esclusi vacanze e
altri periodi di inattività) necessari al completamento di un'attività schedulata o di un componente
della WBS. Di solito è espressa in giorni o settimane di lavoro. Talvolta viene erroneamente
equiparata al tempo trascorso. Diverso da impegno. Vedere anche durata originale, durata residua
e durata effettiva.
Durata dell'attività / Activity Duration. Tempo espresso in unità temporali che intercorre tra l'inizio
e la fine di un'attività schedulata. Vedere anche durata effettiva, durata originale e durata residua.
Durata effettiva / Actual Duration. Tempo espresso in unità temporali che intercorre tra la data
d’inizio effettiva dell'attività schedulata e la data di aggiornamento della schedulazione di progetto
(se l'attività schedulata è in corso) oppure la data di fine effettiva (se l'attività schedulata è stata
completata). Glossario
Durata originale (OD) / Original Duration (OD). Durata dell'attività originariamente assegnata a
un'attività schedulata e non aggiornata con il procedere dell'attività stessa. In genere utilizzata per
il confronto con la durata effettiva e la durata residua quando si registra l'avanzamento della
schedulazione.
Durata residua (RD) / Remaining Duration (RD). Lasso di tempo, espresso in unità temporali, tra la
data di aggiornamento della schedulazione di progetto e la data di fine di un'attività schedulata
che abbia una data d'inizio effettiva. Rappresenta il tempo necessario per completare un'attività
schedulata il cui il lavoro è in corso.
Earned Value (EV) / Earned Value (EV). Valore del lavoro terminato espresso in termini di budget
approvato e assegnato a tale lavoro per un'attività schedulata o un componente della WBS. Definito
anche come costo preventivato del lavoro eseguito (BCWP).
®
Glossario
Effettuare l'assicurazione qualità (QA) / Perform Quality Assurance (QA) [processo]. Processo di
applicazione di attività pianificate e sistematiche per il controllo qualità (ad es. audit di revisione o
valutazione collegiale) che consentono di garantire che il progetto utilizzi tutti i processi necessari
a soddisfare i requisiti.
Elaborazione progressiva / Progressive Elaboration [tecnica]. Continuo miglioramento e
approfondimento di un piano mano a mano che, con l'avanzamento del progetto, diventano
disponibili informazioni maggiori e più specifiche e stime più accurate; questa tecnica consente di
produrre piani più accurati e completi grazie alla reiterazione del processo di pianificazione.
Elemento di lavoro / Work Item. Termine non più in uso. Vedere attività e attività schedulata.
Elenco delle attività / Activity List [output/input]. Tabulazione documentata delle attività schedulate
contenente la descrizione dell’attività, l'identificativo dell'attività e una descrizione relativamente
dettagliata dell'ambito del lavoro che consente ai membri del gruppo di progetto di comprendere il
lavoro da eseguire.
Esecuzione / Executing. Vedere eseguire.
Esecuzione / Execution. Vedere eseguire.
Esecuzione del controllo qualità (QC) / Perform Quality Control (QA) [processo]. Processo di
monitoraggio dei risultati specifici di un progetto* che consente di determinare la loro conformità
ai rispettivi standard di qualità e di individuare dei metodi per eliminare le cause di prestazioni non
soddisfacenti.
Eseguire / Execute. Amministrazione, gestione, esecuzione e conclusione del lavoro del progetto
finalizzate alla fornitura dei deliverable e delle informazioni sullo stato di avanzamento del lavoro.
Estremità aperta del reticolo / Network Open End. Attività schedulata priva di attività predecessore
o di attività successore che crea una frattura involontaria nel percorso del reticolo della
schedulazione. Le estremità aperte dei reticoli sono generalmente causate dall'assenza di relazioni
logiche.
Evento / Event. Qualcosa che accade, un avvenimento o un risultato.
Evitare i rischi / Risk Avoidance [tecnica]. Tecnica di pianificazione della risposta ai rischi* usata
quando si presenta una minaccia per la quale si attuano modifiche al piano di Project Management
allo scopo di eliminare il rischio o proteggere gli obiettivi del progetto dal suo impatto. In genere,
evitare i rischi prevede il ridimensionamento degli obiettivi di durata, costo, ambito o qualità.
Failure Mode and Effect Analysis (FMEA) / Failure Mode and Effect Analysis (FMEA) [tecnica].
Procedura analitica che consente di analizzare tutte le potenziali modalità di avaria di ciascun
componente di un prodotto per determinarne gli effetti sull'affidabilità del componente stesso e per
verificarne gli effetti sull'affidabilità del sistema o del prodotto e sulla funzione richiesta del
componente. Le modalità di avaria possono essere analizzate da sole o in abbinamento tra loro.
Oppure si tratta dell'esame di un prodotto (a livello di sistema e/o a livelli inferiori) per identificare
tutte le modalità in cui può verificarsi un'avaria. Per ogni potenziale avaria, si stima il suo effetto
su tutto il sistema e le relative conseguenze. Inoltre, viene effettuata un'analisi dell'azione
pianificata per ridurre al minimo la probabilità di avaria e dei relativi effetti.
Fase / Phase. Vedere fase di progetto.
Fase di progetto / Project Phase. Raccolta di attività di progetto* collegate tra loro logicamente e
generalmente culminanti nel completamento di un importante deliverable. Le fasi di progetto
(altrimenti dette fasi) vengono solitamente completate in sequenza, ma in alcune situazioni
particolari di progetto possono anche sovrapporsi. Le fasi possono essere suddivise in sottofasi e
quindi in componenti. Se il progetto o parti del progetto vengono suddivisi in fasi, tale gerarchia è
contenuta nella WBS. Una fase di progetto è un componente di un ciclo di vita del progetto. La fase
di progetto non è un gruppo di processi di Project Management*.
Fast Tracking / Fast Tracking [tecnica]. Tecnica specifica di compressione della schedulazione del
progetto che consente di modificare la logica del reticolo per sovrapporre le fasi che verrebbero in
genere svolte in sequenza, come la fase di progettazione e quella di costruzione, o per eseguire in
®
parallelo le attività schedulate. Vedere compressione della schedulazione e vedere anche
compressione dei tempi.
Fattori ambientali aziendali / Enterprise Environmental Factors [output/input]. Uno o tutti i fattori
ambientali esterni e i fattori ambientali interni all'organizzazione che influiscono sull’andamento
del progetto. Questi fattori provengono da una o da tutte le aziende coinvolte nel progetto e
comprendono cultura e struttura aziendale, infrastrutture, risorse esistenti, database commerciali,
condizioni di mercato e software di Project Management.
Fine-fine (FF) / Finish-to-Finish (FF). Relazione logica per la quale il completamento del lavoro
previsto per l'attività successore non può terminare prima del completamento del lavoro
dell'attività predecessore. Vedere anche relazione logica.
Fine-inizio (FS) / Finish-to-Start (FS). Relazione logica per la quale l'inizio del lavoro previsto per
l'attività successore dipende dal completamento del lavoro dell'attività predecessore. Vedere anche
relazione logica.
Float / Float. Denominato anche slack. Vedere Total Float e vedere anche Free Float.
Fondi / Funds. Disponibilità monetaria o risorse economiche immediatamente disponibili.
Fornitore / Seller. Chi fornisce prodotti, servizi o risultati a un'organizzazione.
Freccia / Arrow. Rappresentazione grafica di un'attività schedulata presente nel metodo del
diagramma a frecce o relazione logica tra le attività schedulate presenti nel metodo del diagramma
di precedenza.
Free Float (FF) / Free Float (FF). Quantità di possibile ritardo di un’attività schedulata senza
posticipare la data di inizio minima delle attività schedulate immediatamente successive. Vedere
anche Total Float.
Funzioni operative / Operations. Funzione organizzativa che si occupa dell'esecuzione continuativa
delle attività finalizzate a creare uno stesso prodotto o a fornire un servizio reiterato. Alcuni
esempi sono: funzioni operative di produzione, di fabbricazione e contabili.
Gestione dei costi di progetto / Project Cost Management [area di conoscenza]. Vedere
appendice F.
Gestione dei rischi di progetto / Project Risk Management [area di conoscenza]. Vedere
appendice F.
Gestione dei tempi di progetto / Project Time Management [area di conoscenza]. Vedere appendice
F.
Gestione del portfolio / Portfolio Management [tecnica]. Gestione centralizzata di uno o più
portfolio che prevede l'identificazione, l'assegnazione di priorità, l'autorizzazione, la gestione e il
controllo dei progetti, dei programmi e degli altri lavori correlati per raggiungere specifici obiettivi
aziendali strategici.
Gestione dell’approvvigionamento di progetto / Project Procurement Management [area di
conoscenza]. Vedere appendice F.
Gestione dell’integrazione di progetto / Project Integration Management [area di conoscenza].
Vedere appendice F. Glossario
Gestione della comunicazione di progetto / Project Communications Management [area di
Gestione della qualità di progetto / Project Quality Management [area di conoscenza]. Vedere
appendice F.
Gestione dell'ambito del progetto / Project Scope Management [area di conoscenza]. Vedere
appendice G.
Gestione delle risorse umane di progetto / Project Human Resource Management [area di
Gestione Qualità Totale (TQM) / Total Quality Management (TQM) [tecnica]. Soluzione
comunemente adottata per l’attuazione di un programma di miglioramento della qualità
nell’ambito di un’organizzazione.
®
Glossario
Gestire gli stakeholder / Manage Stakeholders [processo]. Processo di gestione delle comunicazioni
che consente di soddisfare i requisiti degli stakeholder di progetto e di risolvere eventuali questioni
con gli stessi.
Gestire il gruppo di progetto / Manage Project Team [processo]. Processo di rilevamento delle
prestazioni dei membri del gruppo, di restituzione di feedback, di risoluzione dei problemi e di
coordinamento delle modifiche che consente di migliorare le prestazioni del progetto.
Gruppi di processi di progetto / Project Process Groups. I cinque gruppi di processi necessari per
qualsiasi progetto, caratterizzati da chiare relazioni di dipendenza e che devono essere svolti nella
stessa sequenza per tutti i progetti, a prescindere dall'area applicativa o dalle specifiche del ciclo di
vita del progetto adottate. I gruppi di processi sono avvio, pianificazione, esecuzione,
monitoraggio e controllo, e chiusura.
Gruppo di processi / Process Group. Vedere gruppi di processi di Project Management.
Gruppo di processi di Project Management / Project Management Process Group.
Raggruppamento logico dei processi di Project Management descritto nella Guida al PMBOK®. I
gruppi di processi di Project Management comprendono i processi di avvio, processi di
pianificazione, processi di esecuzione, processi di monitoraggio e controllo e processi di chiusura.
Complessivamente, questi cinque gruppi sono necessari per qualsiasi progetto, sono caratterizzati
da chiare relazioni di dipendenza interne e devono essere svolti seguendo la stessa sequenza in
ciascun progetto, a prescindere dall'area applicativa o dalle specifiche del ciclo di vita del progetto
adottato. I gruppi di processi di Project Management non sono le fasi di progetto.
Gruppo di progetto / Project Team. Tutti i membri del gruppo di progetto, compreso il gruppo di
Project Management, il project manager e, per alcuni progetti, lo sponsor del progetto.
Gruppo di Project Management / Project Management Team. Membri del gruppo di progetto
direttamente coinvolti nelle attività di Project Management. In alcuni progetti minori, il gruppo di
Project Management può comprendere anche tutti i membri del gruppo di progetto.
Gruppo virtuale / Virtual Team. Gruppo di persone con un obiettivo comune che svolgono il loro
ruolo non incontrandosi mai di persona o vedendosi raramente. Per facilitare la comunicazione tra i
membri del gruppo di lavoro, vengono utilizzate diverse tecnologie. I gruppi virtuali possono
essere costituiti da persone separate da grandi distanze.
Identificare i rischi / Risk Identification [processo]. Processo di determinazione dei rischi che
possono influire sul progetto e di definizione delle relative caratteristiche.
Identificativo dell'attività / Activity Identifier. Breve identificativo univoco di tipo numerico o
alfabetico assegnato a ciascuna attività schedulata che consente di distinguere quella attività di
progetto* dalle altre attività. In genere, questo identificativo è univoco nell'ambito di un reticolo di
schedulazione del progetto.
Impegno / Effort. Il numero di unità lavorative necessarie al completamento di un'attività schedulata o
di un componente della WBS, generalmente espresso come ore/uomo, giorni/uomo,
settimane/uomo. Diverso da durata.
Impegno discreto / Discrete Effort. Impegno applicato al lavoro di progetto associabile direttamente
con il completamento di componenti della WBS e deliverable specifici; questo valore può essere
pianificato e misurato direttamente. Diverso da impegno distribuito.
Impegno distribuito (AE) / Apportioned Effort (AE). Impegno relativo ad attività di progetto che
non può essere facilmente scomponibile in una serie di impegni discreti per quella attività, ma che
risulta direttamente proporzionale all’impegno relativo ad altre attività di progetto di tipo discreto.
Diverso da impegno discreto.
Indice di efficienza dei costi (CPI) / Cost Performance Index (CPI). Unità di misura dell'efficienza
economica di un progetto. Rappresenta il rapporto tra l'Earned Value (EV) e i costi effettivi (AC).
CPI = EV diviso per AC. Un valore maggiore o uguale a uno segnala la presenza di una condizione
favorevole, mentre un valore minore di uno è indice di una situazione sfavorevole.
Indice di efficienza della schedulazione (SPI) / Schedule Performance Index (SPI). Unità di misura
dell'efficienza della schedulazione di un progetto. Rappresenta il rapporto tra l'Earned Value (EV)
e il valore pianificato (PV). SPI = EV diviso per PV. Un SPI maggiore o uguale a uno segnala la
®
presenza di una condizione favorevole, mentre un valore minore di uno è indice di una situazione
sfavorevole. Vedere anche metodo dell'Earned Value.
Informazioni sullo stato di avanzamento del lavoro / Work Performance Information
[output/input]. Informazioni e dati relativi allo stato delle attività di schedulazione del progetto che
vengono eseguite per realizzare il lavoro del progetto, raccolte nei processi dirigere e gestire
l'esecuzione del progetto*. Le informazioni comprendono: stato dei deliverable; stato di
implementazione per richieste di modifica, azioni correttive, azioni preventive e correzione dei
difetti; stime a finire previste; percentuali dichiarate di lavoro fisicamente completato; valori
ottenuti dalle misurazioni delle prestazioni tecniche; date di inizio e fine delle attività schedulate.
Ingegneria del valore (VE) / Value Engineering (VE). Approccio creativo utilizzato per ottimizzare i
costi del ciclo di vita del progetto, risparmiare tempo, aumentare i profitti, migliorare la qualità,
espandere la quota di mercato, risolvere problemi e/o utilizzare le risorse in modo più efficace.
Iniziatore / Initiator. Persona od organizzazione che dispone sia della facoltà che dell'autorità per
dare inizio a un progetto.
Inizio-fine (SF) / Start-to-Finish (SF). Relazione logica in cui il completamento dell'attività
successore schedulata è direttamente collegato all'inizio dell'attività predecessore schedulata.
Vedere anche relazione logica.
Inizio-inizio (SS) / Start-to-Start (SS). Relazione logica in cui l'inizio del lavoro dell'attività
successore schedulata è direttamente collegato all'inizio del lavoro dell'attività predecessore
schedulata. Vedere anche relazione logica.
Input / Input [input di processi]. Voce, sia interna che esterna al progetto, richiesta da un processo
prima di potere proseguire. Potrebbe essere un output di un processo predecessore.
Integrale / Integral. Necessario alla completezza, requisito, elemento costitutivo, composto come
unità in abbinamento a un altro componente.
Integrato / Integrated. Componenti correlati, interconnessi, concatenati o innestati miscelati e uniti
per creare un'unica unità funzionante.
Ispezione / Inspection [tecnica]. Esame o valutazione quantitativa che consente di verificare la
conformità di un'attività, un componente, un prodotto, un risultato o un servizio ai requisiti
specificati.
Istogramma delle risorse / Resource Histogram. Diagramma a barre che mostra la quantità di
tempo che una risorsa è chiamata a lavorare in un determinato arco temporale. Ai fini del
confronto, è possibile visualizzare la disponibilità della risorsa sotto forma di barra di istogramma.
Barre differenti mostrano il reale impiego delle risorse durante il progetto rispetto a quanto
preventivato.
Knowledge base delle lesson learned / Lessons Learned Knowledge Base. Archivio dei dati storici e
delle lesson learned sia sui risultati delle decisioni prese nell'ambito della selezione di progetti
precedenti sia sulle prestazioni dei progetti precedenti.
Lag / Lag [tecnica]. Modifica di una relazione logica che comporta un ritardo nell'attività successore.
Ad esempio, in una relazione di dipendenza fine-inizio con un lag di 10 giorni, l’attività successore
Glossario
non può iniziare prima di 10 giorni dopo la fine dell'attività predecessore. Vedere anche lead.
Lavoro / Work. Impegno fisico o mentale prolungato, esercizio o applicazione di skill per superare
ostacoli e raggiungere un obiettivo.
Lavoro di progetto / Project Work. Vedere lavoro.
Lead / Lead [tecnica]. Modifica di una relazione logica che consente un’accelerazione dell'attività
successore. Ad esempio, in una relazione di dipendenza fine-inizio con un lead di 10 giorni,
l’attività successore può iniziare 10 giorni prima del completamento dell'attività predecessore.
Vedere anche lag. Un lead negativo corrisponde a un lag positivo.
Lesson learned / Lessons Learned [output/input]. Le conoscenze acquisite durante il processo
d’esecuzione di un progetto. Le lesson learned apprese possono essere identificate in qualsiasi
momento. Considerate anche come un archivio del progetto da aggiungere alla knowledge base
delle lesson learned.
®
Glossario
Limiti di controllo / Control Limits. Area composta da tre deviazioni standard su ciascun lato della
linea centrale, o della media, in una distribuzione normale dei dati tracciati su una carta di
controllo che rispecchia la variazione prevista per i dati. Vedere anche limiti di tolleranza delle
specifiche.
Limiti di tolleranza delle specifiche / Specification Limits. L'area, su ciascun lato della linea centrale
o della media di dati tracciati su una carta di controllo che rispecchia i requisiti del cliente per un
prodotto o servizio. Tale area può essere maggiore o minore di quella definita per i limiti di
controllo. Vedere anche limiti di controllo.
Lista di controllo / Checklist [output/input]. Elenco di voci raggruppate per essere confrontate o per
garantire che le azioni ad esse associate siano gestite in modo adeguato e non vengano tralasciate.
Un esempio può essere un elenco di voci da controllare che viene creato durante la pianificazione
della qualità e utilizzato durante il controllo qualità.
Livellamento / Leveling. Vedere livellamento delle risorse.
Livellamento delle risorse / Resource Leveling [tecnica]. Qualsiasi forma di analisi del reticolo di
schedulazione in cui le decisioni sui tempi (date d’inizio e di fine) sono determinate
dall’andamento dei vincoli delle risorse (ad es. limitata disponibilità di risorse o modifiche di
difficile gestione nei livelli di disponibilità delle risorse).
Livello / Grade. Categoria od ordine usati per distinguere voci che hanno lo stesso uso funzionale (ad
es. “martello”) ma non gli stessi requisiti di qualità (ad es. martelli differenti potrebbero dover
tollerare diverse quantità di forza).
Livello di impegno (LOE) / Level of Effort (LOE). Attività di supporto (ad es. gestione della
relazione tra fornitore e cliente, analisi dei costi del progetto, Project Management, ecc.) che non si
prestano facilmente ad una misurazione di completamento discreto. Queste attività sono
generalmente caratterizzate da un tasso costante di avanzamento del lavoro in un dato periodo di
tempo, che viene determinato in base alle attività supportate.
Logica / Logic. Vedere logica del reticolo.
Logica del reticolo / Network Logic. L’insieme delle relazioni di dipendenza delle attività schedulate
che compongono il reticolo di schedulazione del progetto.
Manager funzionale / Functional Manager. Persona con autorità gestionale responsabile di un'unità
organizzativa appartenente a un'organizzazione funzionale. Il manager di un gruppo che
effettivamente realizza un prodotto o svolge un servizio. A volte denominato anche responsabile di
linea.
Materiale / Materiel. Insieme di mezzi utilizzati da un'organizzazione in qualsiasi compito, ad es.
attrezzature, apparati, strumenti, macchinari, dispositivi, materiale e forniture.
Matrice assegnazione responsabilità (RAM) / Responsibility Assignment Matrix (RAM)
[strumento]. Struttura che collega la struttura di scomposizione dell'organizzazione di progetto alla
struttura di scomposizione del lavoro per contribuire ad assicurare che ciascun componente
dell'ambito del lavoro del progetto sia assegnato a un responsabile.
Matrice di probabilità e impatto / Probability and Impact Matrix [strumento]. Metodo comune che
consente di determinare se un rischio è basso, medio o alto mediante l'unione delle due dimensioni:
la probabilità che si verifichi e l’impatto sugli obiettivi qualora si verificasse.
Membri del gruppo di lavoro / Team Members. Vedere membri del gruppo di progetto.
Membri del gruppo di progetto / Project Team Members. Persone che rispondono direttamente o
indirettamente al project manager e che, come parte dei propri compiti, sono responsabili
dell'esecuzione del lavoro di progetto.
Metodo del Critical Chain / Critical Chain Method [tecnica]. Tecnica di analisi del reticolo di
schedulazione* che modifica la schedulazione del progetto per tenere conto delle risorse limitate. Il
metodo del Critical Chain unisce gli approcci di tipo deterministico e probabilistico all'analisi del
reticolo di schedulazione.
Metodo del diagramma a frecce (ADM) / Arrow Diagramming Method (ADM) [tecnica]. Tecnica
di generazione dei diagrammi reticolari della schedulazione nella quale le attività schedulate
®
vengono rappresentate sotto forma di frecce. La coda della freccia rappresenta l'inizio dell'attività
schedulata, la testa rappresenta la fine. (La lunghezza della freccia non è indicativa della durata
prevista per l'attività schedulata.) Le attività schedulate si uniscono in punti detti nodi (in genere
disegnati sotto forma di piccoli cerchi) per illustrare la sequenza con la quale si prevede di eseguire
le attività schedulate. Vedere anche metodo del diagramma di precedenza.
Metodo del diagramma di precedenza (PDM) / Precedence Diagramming Method (PDM)
[tecnica]. Tecnica di generazione dei diagrammi reticolari della schedulazione in cui le attività
schedulate vengono rappresentate sotto forma di caselle (o nodi). Le attività schedulate vengono
graficamente collegate da una o più relazioni logiche per mostrare la sequenza secondo la quale
devono essere eseguite.
Metodo del percorso critico (CPM) / Critical Path Method (CPM) [tecnica]. Tecnica di analisi del
reticolo di schedulazione* che consente di determinare l'estensione della flessibilità della
schedulazione (quantità di Float) nei vari percorsi logici del reticolo della schedulazione di
progetto e di stabilire il valore minimo per la durata totale del progetto. Le date d'inizio e di fine
minime* vengono calcolate mediante un calcolo in avanti, utilizzando una data d’inizio
specificata. Le date d'inizio e di fine massime* vengono determinate mediante un calcolo a ritroso,
a partire da una data di completamento specifica e che a volte corrisponde alla data di fine minima
del progetto stabilita nel calcolo in avanti.
Metodo dell'Earned Value / Earned Value Management (EVM). Metodologia che consente
l'integrazione di ambito, schedulazione e risorse, utilizzata per la misurazione oggettiva delle
prestazioni e dell'avanzamento del progetto. Per misurare le prestazioni, viene stabilito il costo
preventivato del lavoro eseguito (Earned Value) che viene quindi confrontato con il costo effettivo
del lavoro eseguito (costo effettivo). Per misurare l'avanzamento, vengono invece confrontati
l'Earned Value e il valore pianificato.
Metodologia / Methodology. Sistema di pratiche, tecniche, procedure e regole adottato da coloro che
si occupano di una determinata disciplina.
Milestone / Milestone. Un momento o un evento significativo in un progetto. Vedere anche milestone
di schedulazione.
Milestone di schedulazione / Schedule Milestone. Evento significativo nella schedulazione di
progetto, ad es. un evento che condiziona il lavoro futuro o segna il completamento di un
deliverable di primaria importanza. Una milestone di schedulazione ha durata zero. Detta anche
attività cardine. Vedere anche milestone.
Minaccia / Threat. Condizione o situazione sfavorevole al progetto, insieme di circostanze o eventi
negativi, rischio che può avere un impatto negativo su un obiettivo del progetto o costituire
possibilità di cambiamenti negativi. Diverso da opportunità.
Misurazione delle prestazioni tecniche / Technical Performance Measurement [tecnica]. Tecnica
per la misurazione delle prestazioni che confronta i risultati tecnici raggiunti durante l'esecuzione
del progetto con la schedulazione nel piano di Project Management dei risultati tecnici pianificati.
Per la misurazione della qualità possono essere impiegati parametri tecnici significativi del
prodotto realizzato all’interno del progetto. I valori di misurazione ottenuti fanno parte delle
Glossario
informazioni sullo stato di avanzamento del lavoro.
Modello di schedulazione / Schedule Model [strumento]. Modello utilizzato in abbinamento a metodi
manuali o software di Project Management per eseguire un'analisi del reticolo di schedulazione e
generare la schedulazione di progetto usata per l'esecuzione di un progetto. Vedere anche
Modifica dell'ambito / Scope Change. Qualsiasi modifica all'ambito del progetto. Una modifica
dell'ambito richiede quasi sempre un adattamento dei costi o della schedulazione di progetto.
Modifica richiesta / Requested Change [output/input]. Modifica richiesta formalmente documentata
e presentata per l'approvazione al processo di controllo integrato delle modifiche. Diverso da
richiesta di modifica approvata.
Monitoraggio / Monitoring. Vedere monitorare.
®
Glossario
Monitoraggio e controllo dei rischi / Risk Monitoring and Control [processo]. Processo di
rilevazione dei rischi identificati, monitoraggio dei rischi residui, identificazione dei rischi nuovi,
attuazione dei piani di risposta al rischio e valutazione dell'efficacia di queste operazioni nel corso
del ciclo di vita del progetto.
Monitorare / Monitor. Raccogliere dati sulle prestazioni del progetto rispetto a un piano, produrre
misurazioni delle prestazioni, creare report e diffondere le informazioni sulle prestazioni.
Monitorare e controllare il lavoro del progetto / Monitor and Control Project Work [processo].
Processo di monitoraggio e controllo dei processi necessari per avviare, pianificare, eseguire e
chiudere un progetto che consente di raggiungere gli obiettivi di prestazione definiti nel piano di
Project Management e nella descrizione dell'ambito del progetto.
Networking / Networking [tecnica]. Sviluppo di relazioni con persone che possono assistere nel
raggiungimento degli obiettivi e delle responsabilità.
Nodo / Node. Uno dei punti che definiscono un reticolo della schedulazione; un punto di congiunzione
unito ad alcune o a tutte le altre linee delle relazioni di dipendenza. Vedere anche metodo del
diagramma a frecce e metodo del diagramma di precedenza.
Obiettivo / Objective. Qualcosa a cui è indirizzato il lavoro, una posizione strategica da guadagnare,
uno scopo da raggiungere, un risultato da ottenere, un prodotto da creare o un servizio da fornire.
Opportunità / Opportunity. Condizione o situazione favorevole al progetto, insieme positivo di
circostanze, insieme positivo di eventi, un rischio che avrà conseguenze positive sugli obiettivi del
progetto oppure una possibilità di apportare modifiche positive. Diverso da minaccia.
Organigramma / Organization Chart [strumento]. Metodo utilizzato per descrivere le interrelazioni
tra un gruppo di persone che collaborano per il raggiungimento di un obiettivo comune.
Organigramma di progetto / Project Organization Chart [output/input]. Documento che raffigura
graficamente i membri del gruppo di progetto e le relative relazioni reciproche nell'ambito di un
progetto specifico.
Organizzazione / Organization. Gruppo di persone organizzato per raggiungere un obiettivo o per
eseguire un certo tipo di lavoro nell'ambito dell'azienda.
Organizzazione a matrice / Matrix Organization. Qualsiasi struttura organizzativa in cui il project
manager condivide le responsabilità con i manager funzionali per l’assegnazione delle priorità e la
direzione del lavoro delle persone assegnate a un progetto.
Organizzazione funzionale / Functional Organization. Organizzazione gerarchica nella quale ogni
dipendente ha un solo superiore, il personale è diviso per aree di specializzazione ed è gestito da
una persona con le competenze adeguate.
Organizzazione per progetti / Projectized Organization. Qualsiasi struttura organizzativa in cui il
project manager dispone della completa autorità per l'assegnazione delle priorità, l'utilizzo delle
risorse e la direzione del lavoro delle persone assegnate a un progetto.
Output / Output [output di processo]. Prodotto, risultato o servizio generato da un processo. Può
rappresentare l'input per un processo successore.
Parere di esperti / Expert Judgment [tecnica]. Parere fornito in base alle conoscenze acquisite in
un'area applicativa, un'area di conoscenza, una disciplina, un settore ecc., a seconda dell'attività
da eseguire. Tali conoscenze possono essere fornite da un gruppo di persone o da un singolo
individuo che abbiano un'istruzione, delle conoscenze, delle skill, un'esperienza, una formazione
specialistiche del settore e vengono rese disponibili da fonti diverse tra cui: altre unità interne alla
Performing Organization, consulenti, stakeholder (compresi i clienti), associazioni tecniche o
professionali e associazioni industriali.
Percentuale di completamento (PC o PCT) / Percent Complete (PC o PCT). Stima, espressa in
percentuale, della quantità di lavoro completata su un’attività o su un componente della WBS.
Percorso critico / Critical Path [output/input]. In genere, ma non sempre, indica la sequenza delle
attività schedulate che determina la durata del progetto. Normalmente è il percorso più lungo del
progetto. Ciononostante, un percorso critico può terminare anche, ad esempio, su una milestone di
schedulazione che si trova nella parte centrale della schedulazione del progetto e che è
®
caratterizzata da un vincolo di schedulazione dovuto a una data imposta del tipo “non-più-tardi-
di”. Vedere anche metodo del percorso critico.
Percorso del reticolo / Network Path. Qualsiasi serie continua di attività schedulate collegate da
relazioni logiche ed appartenenti a un reticolo di schedulazione del progetto.
Performing Organization / Performing Organization. Azienda il cui personale è direttamente
coinvolto nello svolgimento del lavoro del progetto.
Pianificare gli acquisti / Plan Purchases and Acquisitions [processo]. Processo che consente di
determinare cosa acquistare o acquisire e dove e come effettuare tali operazioni.
Pianificare le forniture / Plan Contracting [processo]. Processo di documentazione dei requisiti di
prodotti, servizi e risultati e di identificazione dei potenziali fornitori.
Pianificazione a finestra mobile / Rolling Wave Planning [tecnica]. Forma di pianificazione ad
elaborazione progressiva in cui il lavoro da eseguire a breve termine viene programmato nel
dettaglio a un livello basso della WBS, mentre il lavoro a lungo termine viene programmato a un
livello relativamente alto della WBS. La pianificazione dettagliata del lavoro da eseguire nei
periodi più prossimi viene completata mano a mano che si completa il lavoro del periodo in corso.
Pianificazione della comunicazione / Communications Planning [processo]. Processo che consente
di determinare le esigenze degli stakeholder di progetto in materia di informazione e
comunicazione. Include la definizione di chi sono gli stakeholder e del loro livello di interesse e di
influenza sul progetto, la definizione del tipo di informazioni da scambiare con specifici
stakeholder, dei tempi entro i quali è necessario fornirle e delle relative modalità di diffusione.
Pianificazione della gestione dei rischi / Risk Management Planning [processo]. Processo
decisionale che determina come affrontare, pianificare e eseguire le attività di gestione del rischio
in un progetto.
Pianificazione della qualità / Quality Planning [processo]. Processo che consente di determinare
quali standard di qualità devono essere applicati al progetto e come possono essere soddisfatti.
Pianificazione della risposta ai rischi / Risk Response Planning [processo]. Processo di sviluppo di
alternative e azioni volte ad aumentare le opportunità e ridurre le minacce relative agli obiettivi del
progetto.
Pianificazione dell'ambito / Scope Planning [processo]. Processo di creazione di un piano di
gestione dell'ambito del progetto.
Pianificazione delle risorse / Resource Planning. Vedere stima delle risorse delle attività.
Pianificazione delle risorse umane / Human Resource Planning [processo]. Processo di
identificazione e documentazione dei ruoli del progetto, delle responsabilità e dei riporti nonché
della creazione del piano di gestione delle risorse.
Piano dei conti / Chart of Accounts [strumento]. Qualsiasi sistema numerico utilizzato per monitorare
i costi del progetto* per categoria (ad es. manodopera, forniture, materiali e attrezzature). Il piano
dei conti di progetto si basa in genere sul piano dei conti aziendale della Performing Organization.
Diverso da codice di classificazione.
Piano dei punti di controllo (CAP) / Control Account Plan (CAP) [strumento]. Piano di tutto il Glossario
lavoro e dell'impegno da eseguire in un punto di controllo. Ciascun CAP dispone di un capitolato,
una schedulazione e un budget sulle associato alle fasi temporali. Precedentemente denominato
piano riepilogativo dei costi.
Piano di gestione dei costi / Cost Management Plan [output/input]. Documento che delinea il
formato e che stabilisce le attività e i criteri per la pianificazione, la strutturazione e il controllo dei
costi del progetto. Il piano di gestione dei costi può essere formale o informale, dettagliato o
sintetico in base alle esigenze espresse dagli stakeholder di progetto. Il piano è contenuto nel piano
di Project Management oppure ne costituisce una parte ausiliaria.
Piano di gestione dei rischi / Risk Management Plan [output/input]. Documento che descrive la
metodologia di gestione dei rischi di progetto e la sua applicazione nel contesto del progetto. È
contenuto nel piano di Project Management oppure ne costituisce una parte ausiliaria. Il piano di
gestione dei rischi può essere informale e sintetico o formale e molto dettagliato, in base alle
®
Glossario
esigenze del progetto. Le informazioni del piano di gestione dei rischi variano secondo l'area
applicativa e la dimensione del progetto. Il piano di gestione dei rischi differisce dal registro dei
rischi che contiene l'elenco dei rischi di progetto, i risultati dell'analisi dei rischi e le risposte ai
rischi.
Piano di gestione del contratto / Contract Management Plan [output/input]. Documento che
descrive come verrà amministrato uno specifico contratto e che può includere elementi quali la
documentazione da consegnare e i requisiti di prestazioni. Il piano di gestione del contratto può
essere formale o informale, dettagliato o sintetico in base ai requisiti stabiliti nel contratto. Ogni
piano di gestione del contratto costituisce una parte ausiliaria del piano di Project Management.
Piano di gestione del personale / Staffing Management Plan [processo]. Documento che descrive
quando e come verranno soddisfatti i requisiti per le risorse umane. È contenuto nel piano di
Project Management oppure ne costituisce una parte ausiliaria. Il piano di gestione del personale
può essere informale e sintetico o formale e dettagliato, in base alle esigenze del progetto. Le
informazioni del piano di gestione del personale variano in base all'area applicativa e alla
dimensione del progetto.
Piano di gestione dell’approvvigionamento / Procurement Management Plan [output/input].
Documento che descrive come vengono gestiti i processi di approvvigionamento dalla fase di
sviluppo della documentazione relativa all'approvvigionamento fino alla chiusura del contratto.
Piano di gestione della comunicazione / Communication Management Plan [output/input].
Documento che descrive i seguenti aspetti: le necessità e le aspettative in merito alla
comunicazione del progetto; la modalità e il formato mediante i quali verranno comunicate le
informazioni; dove e quando avranno luogo le varie comunicazioni e la persona responsabile della
diffusione di ogni tipo di comunicazione. Il piano di gestione della comunicazione può essere
formale o informale, dettagliato o sintetico in base alle esigenze espresse dagli stakeholder di
progetto. Il piano è contenuto nel piano di Project Management oppure ne costituisce una parte
ausiliaria.
Piano di gestione della qualità / Quality Management Plan [output/input]. Il piano di gestione della
qualità descrive la modalità di attuazione delle politiche di 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. Il piano di gestione della qualità può essere formale o
informale, dettagliato o sintetico in base ai requisiti del progetto.
Piano di gestione della schedulazione / Schedule Management Plan [output/input]. Documento che
stabilisce i criteri e le attività per lo sviluppo e il controllo della schedulazione di progetto. È
contenuto nel piano di Project Management oppure ne costituisce una parte ausiliaria. Il piano di
gestione della schedulazione può essere formale o informale, dettagliato o sintetico in base alle
esigenze del progetto.
Piano di gestione dell'ambito del progetto / Project Scope Management Plan [output/input].
Documento che descrive la modalità di definizione, sviluppo e verifica dell'ambito del progetto e la
modalità di creazione e definizione della WBS; il documento fornisce inoltre una guida su come il
gruppo di Project Management gestirà e controllerà l'ambito del progetto. È contenuto nel piano di
Project Management oppure ne costituisce una parte ausiliaria. Il piano di gestione dell'ambito del
progetto può essere informale e sintetico oppure formale e molto dettagliato, in base alle necessità
del progetto.
Piano di Project Management / Project Management Plan [output/input]. Documento formale e
approvato che definisce le modalità di esecuzione, monitoraggio e controllo del progetto. Può
essere in forma riepilogativa o dettagliata e può essere composto da uno o più piani di gestione
ausiliari o da altri documenti di pianificazione.
Planning Package / Planning Package. Componente della WBS che si trova sotto un punto di
controllo di cui si conosce il lavoro da svolgere ma senza un dettaglio di schedulazione. Vedere
anche punto di controllo.
Portfolio / Portfolio. Insieme di progetti o programmi e altri lavori che vengono raggruppati per
facilitare la gestione efficace del lavoro e allo scopo di raggiungere gli obiettivi aziendali strategici.
®
I progetti o i programmi del portfolio possono non essere necessariamente interdipendenti o
direttamente collegati.
Pratica / Practice. Tipo specifico di attività professionale o gestionale che contribuisce all'esecuzione
di un processo e che può adottare una o più tecniche o strumenti.
Previsioni / Forecasts. Stime o previsioni delle condizioni e degli eventi che potrebbero verificarsi nel
futuro del progetto in base alle informazioni e alle conoscenze disponibili al momento della
previsione. Le previsioni vengono aggiornate e quindi ripubblicate a seguito delle informazioni
sullo stato di avanzamento del lavoro fornite durante l'esecuzione del progetto. Tali informazioni si
fondano sulle prestazioni precedenti del progetto e su quelle future attese, e tengono conto di
informazioni che potrebbero influire sul progetto in futuro, come la stima al completamento e la
stima a finire.
Procedura / Procedure. Serie di passi eseguiti in un determinato ordine per raggiungere un obiettivo.
Procedura documentata / Documented Procedure. Descrizione scritta di tipo formale della modalità
di esecuzione di un'attività, un processo, una tecnica o una metodologia.
Processi di avvio / Initiating Processes [gruppo di processi]. Processi eseguiti per autorizzare e
definire l'ambito di una nuova fase o un nuovo progetto o che possono determinare la
continuazione del lavoro relativo a un progetto sospeso. La maggior parte dei processi di avvio
vengono svolti al di fuori dell'area di controllo del progetto come parte dei processi di gestione
dell'organizzazione, del programma o del portfolio; questi ultimi forniscono l'input per il gruppo di
processi di avvio del progetto.
Processi di chiusura / Closing Processes [gruppo di processi]. Processi eseguiti per concludere a
livello formale tutte le attività incluse nel progetto o in una fase e per trasferire il prodotto
completato a terzi oppure per chiudere un progetto annullato.
Processi di esecuzione / Executing Processes [gruppo di processi]. Processi effettuati per portare a
termine il lavoro definito nel piano di Project Management che consente di raggiungere gli
obiettivi del progetto specificati nella descrizione dell'ambito del progetto.
Processi di monitoraggio e controllo / Monitoring and Controlling Processes [gruppo di processi].
Processi effettuati per misurare e monitorare l'esecuzione del progetto* che consentono di adottare
azioni correttive quando è necessario per il controllo dell'esecuzione della fase o del progetto.
Processi di pianificazione / Planning Processes [gruppo di processi]. Processi eseguiti per definire e
maturare l'ambito del progetto, sviluppare il piano di Project Management e identificare e
schedulare le attività di progetto* che si devono svolgere per il progetto.
Processo / Process. Insieme di azioni e attività reciprocamente collegate eseguite per ottenere un
insieme specificato di prodotti, risultati o servizi.
Processo di Project Management / Project Management Process. Uno dei 44 processi esclusivi del
Project Management e descritti nella Guida al PMBOK®.
Processo di un'area di conoscenza / Knowledge Area Process. Processo di Project Management
all'interno di un'area di conoscenza.
Prodotto / Product. Manufatto che è stato realizzato, che è quantificabile e che può essere un prodotto Glossario
finito in sé o semplicemente un componente. Altri termini utilizzati per i prodotti sono materiali e
beni. Diverso da risultato e servizio. Vedere anche deliverable.
Progetto / Project. Iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato
con caratteristiche di unicità.
Program Management / Program Management. Gestione centralizzata e coordinata di un
programma per il raggiungimento di obiettivi e benefici strategici.
Program Management Office (PMO) / Program Management Office (PMO). Gestione
centralizzata di un determinato programma o di più programmi che consente di ottenere benefici
aziendali mediante la condivisione di risorse, metodologie, strumenti e tecniche e grazie alla
relativa attenzione sui temi di PM di alto livello. Vedere anche Project Management Office.
Programma / Program. Gruppo di progetti correlati gestiti in modo coordinato al fine di ottenere
benefici e un controllo non possibili nella gestione individuale dei singoli progetti. I programmi
®
Glossario
possono contenere elementi di lavoro correlati ma esterni all'ambito dei singoli progetti
appartenenti al programma.
Project Charter / Project Charter [output/input]. Documento emesso dall'iniziatore o dallo sponsor
del progetto che autorizza formalmente l'esistenza di un progetto e attribuisce al project manager
l'autorità necessaria per adottare le risorse organizzative per le attività previste dal progetto.
Project Management (PM) / Project Management (PM). L’applicazione di conoscenze, skill,
strumenti e tecniche alle attività di progetto* per soddisfarne i requisiti.
Project Management Body of Knowledge (PMBOK®) / Project Management Body of Knowledge
(PMBOK®). Termine comprensivo che descrive l’insieme delle conoscenze relative alla
professione del Project Management. Come avviene in altre professioni (ad esempio, in
giurisprudenza, medicina e ragioneria), l’insieme delle conoscenze è appannaggio dei
professionisti e degli accademici che le praticano e le sviluppano. Il Project Management Body of
Knowledge completo comprende le comprovate pratiche tradizionali ampiamente utilizzate e le
pratiche che stanno emergendo nel settore. L'insieme delle conoscenze comprende sia materiale
pubblicato che non pubblicato. Il PMBOK è in continua evoluzione.
Project Management Office (PMO) / Project Management Office (PMO). Entità o funzione
organizzativa a cui sono assegnate varie responsabilità correlate alla gestione centralizzata e
coordinata dei progetti di cui sono responsabili. Le responsabilità di un PMO vanno dalla fornitura
di funzioni di supporto di Project Management all'essere responsabile della gestione diretta di un
progetto. Vedere anche Program Management Office.
Project Management Professional (PMP®) / Project Management Professional (PMP®). Persona
certificata come PMP® da parte del Project Management Institute (PMI®).
Project manager (PM) / Project manager (PM). Persona incaricata dalla Performing Organization al
raggiungimento degli obiettivi del progetto*.
Punto di controllo (CA) / Control Account (CA) [strumento]. Punto di controllo della gestione nel
quale si verificano l'integrazione di ambito, budget, costo effettivo e schedulazione e in cui avviene
la misurazione delle prestazioni. I punti di controllo vengono collocati in punti selezionati
(componenti specifici a livelli selezionati) della WBS. Tutti i punti di controllo includono uno o più
Work Package, ma ciascun Work Package può essere associato a un solo punto di controllo. Ogni
punto di controllo è associato a uno specifico singolo componente organizzativo appartenente alla
struttura di scomposizione dell'organizzazione (OBS). Precedentemente denominato piano
riepilogativo dei costi. Vedere anche Work Package.
Qualità / Quality. Grado di soddisfazione dei requisiti da parte di determinate caratteristiche.
Questione / Issue. Argomento oggetto di discussione o controversia, oppure punto o questione non
ancora risolti o fonte di disaccordo a causa dei diversi punti di vista.
Rapporto sulle eccezioni / Exception Report. Documento che comprende soltanto le principali
variazioni dal piano (anziché tutte).
Reclamo / Claim. Una richiesta, rivendicazione o affermazione di diritti effettuata da un fornitore nei
confronti di un acquirente o viceversa, in merito al compenso, al corrispettivo o al pagamento in
conformità ai termini di un contratto legalmente vincolante, ad es. per una modifica contestata.
Registro / Log. Documento utilizzato per registrare e descrivere o denotare determinati elementi nel
corso dell'esecuzione di un processo o di un'attività. Utilizzato generalmente in abbinamento a una
specificazione, ad es. dei problemi, delle questioni, di controllo qualità, delle azioni o dei difetti.
Registro dei rischi / Risk Register [output/input]. Documento contenente i risultati dell'analisi
qualitativa del rischio, dell'analisi quantitativa del rischio e della pianificazione della risposta ai
rischi. Il registro dei rischi elenca in dettaglio tutti i rischi identificati insieme a descrizione,
categoria, causa, probabilità che si verifichino, impatto sugli obiettivi, risposte proposte,
responsabili e stato attuale. È contenuto nel piano di Project Management.
Regolamento / Regulation. Requisiti dettati da un'autorità governativa. Tali requisiti determinano le
caratteristiche del prodotto, del processo o del servizio, rispettando le disposizioni amministrative
applicabili, in conformità alle direttive governative.
®
Regole di base / Ground Rules [strumento]. Elenco di tutti i comportamenti accettabili e non
accettabili adottati dal gruppo di progetto per migliorare le relazioni professionali, l'efficacia e la
comunicazione.
Relazione di dipendenza / Dependency. Vedere relazione logica.
Relazione di precedenza / Precedence Relationship. Termine usato nel metodo del diagramma di
precedenza per una relazione logica. Nell’uso corrente, tuttavia, i termini relazione di precedenza,
relazione logica e relazione di dipendenza sono ampiamente usati in modo intercambiabile, a
prescindere dal metodo del diagramma adottato.
Relazione logica / Logical Relationship. Relazione di dipendenza tra due attività schedulate di
progetto o tra un'attività schedulata di progetto e una milestone di schedulazione. Vedere anche
relazione di precedenza. I quattro possibili tipi di relazioni logiche sono: fine-inizio, fine-fine,
inizio-inizio e inizio-fine.
Report sulle prestazioni / Performance Reports [output/input]. Documenti e presentazioni che
forniscono informazioni sullo stato di avanzamento del lavoro in modo organizzato e riepilogativo,
parametri e calcoli del metodo dell'Earned Value e analisi dell'avanzamento e dello stato del lavoro
del progetto. I formati comuni per i report sulle prestazioni comprendono diagrammi a barre,
curve a S, istogrammi, tabelle e reticoli di schedulazione del progetto che mostrano lo stato attuale
della schedulazione.
Reporting delle prestazioni / Performance Reporting [processo]. Processo di raccolta e
distribuzione delle informazioni sulle prestazioni, tra cui report sullo stato, misurazione
dell'avanzamento e previsioni.
Requisito / Requirement. Condizione o capacità che deve essere soddisfatta o posseduta da un
sistema, prodotto, servizio, risultato o componente perché questo possa essere conforme alle
caratteristiche richieste da un contratto, uno standard, delle specifiche di prodotto o da altri
documenti formali. I requisiti comprendono le necessità, le esigenze e le aspettative quantificate e
documentate dello sponsor, del cliente e di altri stakeholder.
Reticolo / Network. Vedere reticolo di schedulazione del progetto.
Reticolo di schedulazione del progetto / Project Schedule Network Diagram [output/input]. Una
visualizzazione schematica delle relazioni logiche tra le attività schedulate di progetto. Deve
essere sempre tracciato da sinistra verso destra per riflettere la cronologia del lavoro di progetto.
Revisione della progettazione / Design Review [tecnica]. Tecnica utilizzata per la valutazione di una
progettazione proposta e che garantisce che la progettazione del sistema o del prodotto risponda
alle esigenze del cliente o che sia valida, realizzabile e gestibile nel tempo.
Richiesta di informazioni / Request for Information. Tipologia di documento relativo
all'approvvigionamento per mezzo del quale l'acquirente richiede a un potenziale fornitore di
fornire varie informazioni relative a un prodotto, un servizio o alle capacità di un fornitore.
Richiesta di modifica / Change Request. Richieste di ampliamento o riduzione dell'ambito del
progetto, di modifica dei criteri, dei processi, delle pianificazioni e delle procedure, di modifica
dei costi o dei budget oppure di revisione delle schedulazioni. Le richieste di modifica possono
essere dirette o indirette, possono provenire dall’esterno o dall’interno e possono essere Glossario
obbligatorie o facoltative dal punto di vista legale o contrattuale. Vengono elaborate soltanto le
modifiche richieste mediante documentazione formale e vengono applicate soltanto le richieste di
modifica approvate.
Richiesta di modifica approvata / Approved Change Request [output/input]. Richiesta di modifica
elaborata attraverso il processo di controllo integrato delle modifiche e quindi approvata. Diverso
da modifica richiesta.
Richiesta di preventivo (RFQ) / Request for Quotation (RFQ). Tipologia di documento relativo
all'approvvigionamento usato per richiedere preventivi di prezzi ai potenziali fornitori di prodotti o
servizi comuni o standard. A volte utilizzato in sostituzione della richiesta d'offerta. In alcune aree
applicative questo termine può avere un significato più ristretto o più specifico.
Richiesta di risposte dai fornitori / Request Seller Responses [processo]. Processo per l'ottenimento
di informazioni, preventivi, offerte d'appalto, offerte o proposte, secondo le necessità.
®
Glossario
Richiesta d'offerta (RFP) / Request for Proposal (RFP). Tipologia di documento relativo
all'approvvigionamento usato per richiedere proposte ai potenziali fornitori di prodotti o servizi. In
alcune aree applicative, questo termine può avere un significato più ristretto o più specifico.
Ridurre i rischi / Risk Mitigation [tecnica]. Tecnica di pianificazione della risposta ai rischi*
associata alle minacce che si propone di portare la probabilità che si verifichi un rischio o il suo
impatto al di sotto di una soglia accettabile.
Rifacimento / Rework. Azione intrapresa per adeguare un componente difettoso o non conforme ai
requisiti o alle specifiche di prodotto.
Rischio / Risk. Evento o condizione incerti che, se si dovessero verificare, avrebbero un effetto
positivo o negativo sugli obiettivi di progetto. Vedere anche categoria di rischio e struttura di
scomposizione dei rischi.
Rischio collaterale / Secondary Risk. Rischio che deriva come risultato diretto dell’attuazione di una
risposta al rischio.
Rischio residuo / Residual Risk. Rischio che rimane dopo l’attuazione delle risposte al rischio.
Riserva / Reserve. Clausola nel piano di Project Management finalizzata alla riduzione dei rischi
relativi a costi e/o tempi. È spesso seguita da una specificazione (es.: riserva di gestione, riserva
per contingency) per fornire ulteriori dettagli sui tipi di rischi da ridurre. Il significato esatto del
termine seguito da una specificazione varia per area applicativa.
Riserva per contingency / Contingency Reserve [output/input]. Quantità di fondi, budget o tempo
oltre alle stime previste necessaria per ridurre a un livello accettabile per l'organizzazione il rischio
di sforamenti per gli obiettivi di progetto.
Risorsa / Resource. Risorse umane qualificate (in settori specifici a livello individuale o come
gruppo), attrezzature, servizi, forniture, merce, materiale, budget o fondi.
Risultato / Result. Output derivante dall'esecuzione di processi e attività di Project Management. I
risultati comprendono gli effetti (ad es. sistemi integrati, processi rivisti, organizzazioni riordinate,
prove, personale qualificato ecc.) e i documenti (ad es. criteri, piani, studi, procedure, specifiche di
prodotto, report ecc.). Diverso da prodotto e servizio. Vedere anche deliverable.
Rubrica del gruppo di progetto / Project Team Directory. Elenco documentato dei membri del
gruppo di progetto, dei loro ruoli nel progetto e delle informazioni utili per la comunicazione.
Ruolo / Role. Funzione specifica che deve essere eseguita da un membro del gruppo di progetto (ad es.
prove, archiviazioni, ispezioni, programmazione).
Schedulazione / Schedule. Vedere schedulazione di progetto e vedere anche modello di
schedulazione.
Schedulazione a risorse limitate / Resource-Limited Schedule. Schedulazione di progetto le cui
attività schedulate e le date d’inizio e di fine schedulate riflettono la disponibilità delle risorse
prevista. Una schedulazione a risorse limitate non prevede date d'inizio e di fine anticipate o
ritardate. Il Total Float della schedulazione a risorse limitate viene determinato attraverso il
calcolo della differenza tra la data di fine massima del metodo del percorso critico* e la data di
fine schedulata a risorse limitate. Detta anche schedulazione vincolata dalle risorse. Vedere anche
livellamento delle risorse.
Schedulazione delle milestone / Milestone Schedule [strumento]. Schedulazione a livello
riepilogativo che identifica le principali milestone di schedulazione. Vedere anche schedulazione
principale.
Schedulazione di progetto / Project Schedule [output/input]. Date pianificate per l'esecuzione delle
attività schedulate e date pianificate per il raggiungimento delle milestone di schedulazione.
Schedulazione obiettivo / Target Schedule. Schedulazione adottata a scopo di confronto durante
l'analisi del reticolo di schedulazione, che può differire dalla schedulazione della baseline. Vedere
anche baseline.
Schedulazione principale / Master Schedule [strumento]. Una schedulazione di progetto a livello
riepilogativo che identifica i principali deliverable, i componenti della WBS e le milestone di
schedulazione. Vedere anche schedulazione delle milestone.
®
Schedulazione vincolata dalle risorse / Resource-Constrained Schedule. Vedere schedulazione a
risorse limitate.
Schema di documento / Template. Documento parzialmente completato in un formato predefinito che
fornisce una struttura per la raccolta, l'organizzazione e la presentazione di informazioni e dati. Gli
schemi di documenti si basano spesso su documenti creati nel corso di progetti precedenti:
riducono l'impegno necessario per eseguire il lavoro e aumentano l'omogeneità dei risultati.
Scomporre / Decompose. Vedere scomposizione.
Scomposizione / Decomposition [tecnica]. Tecnica di pianificazione che suddivide l'ambito del
progetto in componenti più piccoli e maggiormente gestibili, fino a che il lavoro associato alla
realizzazione dell'ambito del progetto e alla fornitura dei deliverable è definito con un livello di
dettaglio sufficiente da supportare l'esecuzione, il monitoraggio e il controllo del lavoro.
Scostamento / Variance. Deviazione, allontanamento o divergenza quantificabile da una baseline nota
o da un valore atteso.
Scostamento dei costi (CV) / Cost Variance (CV). Misurazione della prestazione economica di un
progetto. Si calcola come la differenza algebrica tra Earned Value (EV) e costo effettivo (AC). CV
= EV meno AC. Un valore positivo è indice di una condizione favorevole, mentre un valore
negativo è indice di una condizione sfavorevole.
Scostamento dei tempi (SV) / Schedule Variance (SV). Unità di misura della prestazione della
schedulazione di un progetto. È la differenza algebrica tra l'Earned Value (EV) e il valore
pianificato (PV). SV = EV meno PV. Vedere anche metodo dell'Earned Value.
Selezionare i fornitori / Select Sellers [processo]. Processo di analisi delle offerte, di scelta tra
potenziali fornitori e di negoziazione di un contratto scritto con il fornitore.
Sequenzializzazione delle attività / Activity Sequencing [processo]. Processo che consente di
identificare e documentare le relazioni di dipendenza tra le attività schedulate.
Servizio / Service. Lavoro utile che però non genera un prodotto o un risultato tangibile, quale, ad
esempio, l'esecuzione di una funzione aziendale a supporto della produzione o della distribuzione.
Diverso da prodotto e risultato. Vedere anche deliverable.
Simulazione / Simulation. Una simulazione usa un modello di progetto che traduce le incertezze,
dettagliatamente specificate, nel loro impatto potenziale sugli obiettivi definiti a livello di progetto
globale. Le simulazioni di progetto utilizzano modelli creati a computer e stime di rischio,
solitamente espresse come distribuzione delle probabilità dei costi o delle durate possibili a livello
di lavoro dettagliato, e vengono solitamente eseguite usando l'analisi Monte Carlo.
Sistema / System. Insieme integrato di componenti interagenti e interdipendenti in modo costante
creato per raggiungere un determinato obiettivo, regolato da relazioni definite e durevoli tra i
componenti stessi e caratterizzato da una produzione e un funzionamento migliori di quelli dati
dalla somma dei suoi singoli componenti. I sistemi possono essere basati su un processo fisico o su
un processo di gestione, o più di frequente su una combinazione dei due. I sistemi di Project
Management sono composti da processi, tecniche, metodologie e strumenti di Project Management
coordinati dal gruppo di Project Management.
Glossario
Sistema di autorizzazione del lavoro / Work Authorization System [strumento]. Sottosistema del
sistema di Project Management generale. Si tratta di una raccolta di procedure formali
documentate che definiscono le modalità di autorizzazione (assegnazione) del lavoro di progetto al
fine di garantire che il lavoro venga effettuato dall'organizzazione specificata al momento giusto e
secondo la giusta sequenza. Comprende i passi, i documenti, il sistema di tracking e i livelli di
approvazione definiti necessari per rilasciare le autorizzazioni al lavoro.
Sistema di controllo delle modifiche / Change Control System [strumento]. Raccolta di procedure
formali documentate che definiscono le modalità di controllo, modifica e approvazione dei
deliverable e della documentazione del progetto. Nella maggior parte delle aree applicative, il
sistema di controllo delle modifiche è un sottoinsieme del sistema di gestione della configurazione.
Sistema di gestione della configurazione / Configuration Management System [strumento].
Sottosistema del sistema di Project Management complessivo. Si tratta di una raccolta di
®
Glossario
procedure formali documentate utilizzate per impartire istruzioni tecniche e amministrative per:
identificare e documentare le caratteristiche funzionali e fisiche di un prodotto, risultato, servizio o
componente; controllare le modifiche apportate a tali caratteristiche; registrare e segnalare ogni
modifica e il relativo stato di implementazione e coadiuvare la revisione di prodotti, risultati o
componenti per verificarne la conformità ai requisiti. Il sistema include la documentazione, i
sistemi di tracciamento e la definizione dei livelli di approvazione necessari per autorizzare e
controllare le modifiche. Nella maggior parte delle aree applicative, il sistema di gestione della
configurazione comprende anche il sistema di controllo delle modifiche.
Sistema di Project Management / Project Management System [strumento]. Insieme di processi,
strumenti, tecniche, metodologie, risorse e procedure che consente di gestire un progetto. Il
sistema è documentato nel piano di Project Management e il suo contenuto varia in base all'area
applicativa, all'influenza delle organizzazioni, alla complessità del progetto e alla disponibilità di
sistemi esistenti. Un sistema di Project Management, che può essere sia formale che informale,
consente al project manager di condurre in modo efficace il progetto fino al suo completamento.
Un sistema di Project Management è un insieme di processi e delle relative funzioni di
monitoraggio e controllo, raggruppati e uniti in un'unica unità funzionale.
Sistema informativo di Project Management (PMIS) / Project Management Information System
(PMIS) [strumento]. Sistema informativo composto da strumenti e tecniche utilizzato per
raccogliere, integrare e diffondere gli output dei processi di Project Management. Consente inoltre
di supportare tutti gli aspetti del progetto dall'avvio alla chiusura e può comprendere sia sistemi
manuali che automatici.
Skill / Skill. Capacità di mettere in pratica la conoscenza, competenza sviluppata e/o capacità di
eseguire un'attività efficacemente e prontamente.
Slack / Slack. Vedere Total Float e Free Float.
Software di Project Management / Project Management Software [strumento]. Classe di
applicazioni software appositamente progettate per coadiuvare il gruppo di Project Management
nella pianificazione, nel monitoraggio e nel controllo del progetto, comprese le operazioni di: stima
dei costi, schedulazione, comunicazione, collaborazione, gestione della configurazione, controllo
dei documenti, gestione degli archivi e analisi dei rischi.
Soggetto influente / Influencer. Persone o gruppi che non sono direttamente correlati all'acquisizione
o all'utilizzo del prodotto del progetto ma che, in virtù della loro posizione all'interno
dell'organizzazione del cliente*, hanno la facoltà di influenzare, positivamente o negativamente, il
corso del progetto.
Soglia / Threshold. Valore di costo, durata, qualità, risorse o valore tecnico utilizzato come
parametro, che può essere inserito nelle specifiche di prodotto. Il superamento della soglia
comporta l'attivazione di un'operazione, ad es. la creazione di un rapporto sulle eccezioni.
Sottofase / Subphase. Suddivisione di una fase.
Sottoprogetto / Subproject. Suddivisione di un progetto globale grazie alla quale il progetto viene
ripartito in componenti o in parti meglio gestibili. I sottoprogetti vengono di solito rappresentati
nella WBS. Un sottoprogetto può essere considerato un progetto e gestito come tale e può essere
acquisito da un fornitore. Può anche essere considerato un sottoreticolo in un reticolo di
schedulazione del progetto.
Sottoreticolo / Subnetwork. Suddivisione (frammento) di un reticolo di schedulazione del progetto,
che in genere rappresenta un sottoprogetto o un Work Package. Viene di solito utilizzato per
illustrare o esaminare alcune condizioni potenziali o proposte della schedulazione, ad es.
cambiamenti nella logica preferenziale della schedulazione o nell'ambito del progetto.
Specifiche / Specification. Documento che descrive in maniera completa, precisa e verificabile i
requisiti, la progettazione, il funzionamento o altre caratteristiche di un sistema, componente,
prodotto, risultato o servizio e, sovente, anche le procedure per determinare se tali disposizioni
vengono soddisfatte. Alcuni esempi sono: specifiche funzionali, specifiche di progettazione,
specifiche di prodotto e specifiche dei test.
®
Specifiche di prodotto / Product Scope. Caratteristiche e funzioni che contraddistinguono un
prodotto, un servizio o un risultato.
Sponsor / Sponsor. Persona o gruppo che fornisce le risorse finanziarie per il progetto in denaro o in
natura.
Sponsor del progetto / Project Sponsor. Vedere sponsor.
Stakeholder / Stakeholder. Persone e organizzazioni (clienti, sponsor, Performing Organization e
pubblico) direttamente coinvolti nel progetto o i cui interessi possono essere influenzati in modo
positivo o negativo dall'esecuzione o dal completamento del progetto. Gli stakeholder possono
anche influire sul progetto e i relativi deliverable.
Stakeholder di progetto / Project Stakeholder. Vedere stakeholder.
Standard / Standard. Documento redatto per consenso e approvato da un organismo riconosciuto che
contiene regole, direttive generali o caratteristiche per uso comune e ripetuto da utilizzare per le
attività o i loro risultati e finalizzato al conseguimento del miglior grado di ordine in un certo
contesto.
Stima / Estimate [output/input]. Valutazione numerica di una possibile quantità o di un risultato.
Comunemente adottata per i costi, le risorse, l'impegno e le durate del progetto e ulteriormente
specificata mediante modificatori (ad es. preliminare, concettuale, di fattibilità, dell'ordine di
grandezza, definitiva). Dovrebbe sempre contenere qualche indicazione sull'accuratezza (ad es.
±x %).
Stima a finire (ETC) / Estimate to Complete (ETC) [output/input]. Costo previsto per il
completamento di tutto il lavoro residuo di un'attività schedulata, un componente della WBS o del
progetto. Vedere anche tecnica dell'Earned Value e stima al completamento.
Stima a tre valori / Three-Point Estimate [tecnica]. Tecnica analitica che fa uso di tre stime di costo
e di durata per rappresentare lo scenario ottimistico, più probabile e pessimistico. Tale tecnica
viene utilizzata per migliorare l’accuratezza delle stime del costo e della durata quando l'attività o
il componente di costo in questione sono incerti.
Stima al completamento (EAC) / Estimate at Completion (EAC) [output/input]. Costo totale
previsto per un'attività schedulata, un componente della WBS o il progetto una volta portato a
termine l'ambito del lavoro. EAC è uguale al costo effettivo (AC) più la stima a finire (ETC) di
tutto il lavoro residuo. EAC = AC più ETC. Il valore di EAC può essere calcolato basandosi sulle
prestazioni fino alla data attuale oppure può essere stimato dal gruppo di progetto in base ad altri
fattori; in questo caso, si parla generalmente di ultima revisione di stima. Vedere anche tecnica
dell'Earned Value e stima a finire.
Stima bottom-up / Bottom-up Estimating [tecnica]. Metodo di stima di un componente del lavoro. Il
lavoro viene scomposto in elementi più dettagliati. Viene fatta una stima di ciò che è necessario
fare per soddisfare i requisiti di tutti i componenti dei livelli più bassi e più dettagliati che
costituiscono il lavoro; le stime vengono quindi raggruppate in una quantità totale che rappresenta
il componente del lavoro nella sua interezza. L'accuratezza della stima bottom-up dipende dalle
dimensioni e dalla complessità del lavoro definito ai livelli più bassi. In genere, una scomposizione
più dettagliata del lavoro garantisce una maggiore accuratezza delle stime. Glossario
Stima dei costi / Cost Estimating [processo]. Processo che consente di sviluppare un'approssimazione
del costo delle risorse necessarie al completamento delle attività di progetto*.
Stima della durata delle attività / Activity Duration Estimating [processo]. Processo di stima del
numero di periodi lavorativi richiesti per portare a termine le singole attività schedulate.
Stima delle risorse delle attività / Activity Resource Estimating [processo]. Processo che consente
di stimare i tipi e le quantità di risorse necessarie ad eseguire ciascuna attività schedulata.
Stima di congruità del costo / Should-Cost Estimate. Stima del costo di un prodotto o servizio
utilizzata per fornire una valutazione della ragionevolezza del costo proposto da un potenziale
fornitore.
Stima parametrica / Parametric Estimating [tecnica]. Tecnica di stima che utilizza una relazione
statistica tra i dati storici e altre variabili (ad es. metri quadri nell'edilizia, righe di codice nella
®
Glossario
programmazione software) per ottenere una stima dei parametri delle attività quali ambito, costi,
budget e durata. Questa tecnica garantisce elevati livelli di accuratezza in funzione del livello di
sofisticazione e dei dati contenuti nel modello. Un esempio di stima parametrica dei costi è quando
si moltiplica la quantità pianificata del lavoro da eseguire per il costo storico unitario, in modo da
ottenere una stima del costo di tale lavoro.
Stima per analogia / Analogous Estimating [tecnica]. Tecnica di stima che adotta i valori dei
parametri, come ambito, costo, budget e durata, o misure di scala, come dimensioni, peso e
complessità, provenienti da un'attività simile svolta in precedenza, per stimare lo stesso parametro
o misurare un'attività futura. Questa tecnica viene frequentemente utilizzata per stimare un
parametro quando sul progetto sono disponibili poche informazioni dettagliate (ad es. nelle fasi
iniziali). La stima per analogia è una forma di parere di esperti. La stima per analogia è resa più
affidabile se le attività precedenti sono simili nella sostanza e non solo nella forma e se i membri
del gruppo di progetto che elaborano le stime dispongono delle competenze necessarie.
Strumento / Tool. Un oggetto concreto, come uno schema di documento o un'applicazione software,
utilizzato per eseguire un'attività che genera un prodotto o un risultato.
Struttura di scomposizione dei rischi (RBS) / Risk Breakdown Structure (RBS) [strumento].
Rappresentazione gerarchica dei rischi di progetto* individuati organizzati in base alla categoria e
sottocategoria di rischio che mette in evidenza le varie aree e cause di rischio potenziale. La
struttura di scomposizione dei rischi viene di solito adattata a specifici tipi di progetto.
Struttura di scomposizione delle risorse (RBS) / Resource Breakdown Structure (RBS). Struttura
gerarchica delle risorse ordinata per categoria e tipo di risorsa utilizzata nelle schedulazioni di
livellamento delle risorse e nello sviluppo di schedulazioni a risorse limitate; è possibile utilizzarla
anche per l'identificazione e l'analisi dell'assegnazione delle risorse umane del progetto.
Struttura di scomposizione dell'organizzazione (OBS) / Organizational Breakdown Structure
(OBS) [strumento]. Rappresentazione gerarchica dell'organizzazione del progetto disposta in modo
da correlare i Work Package alle unità della Performing Organization. A volte la dicitura OBS
viene sostituita dalla forma estesa Organization Breakdown Structure di cui condivide il
significato.
Successore / Successor. Vedere attività successore.
Sviluppare il gruppo di progetto / Develop Project Team [processo]. Processo di miglioramento
delle competenze e di interazione tra i membri del gruppo di lavoro che consente di incrementare
le prestazioni del progetto.
Sviluppare il piano di Project Management / Develop Project Management Plan [processo].
Processo che consente di documentare le azioni necessarie per definire, preparare, integrare e
coordinare tutti i piani secondari inclusi in un piano di Project Management.
Sviluppare il Project Charter / Develop Project Charter [processo]. Processo di sviluppo del
Project Charter che fornisce ufficialmente l'autorizzazione a un progetto.
Sviluppare la descrizione dell'ambito del progetto (preliminare) / Develop Project Scope
Statement (Preliminary) [processo]. Processo di sviluppo della descrizione dell'ambito del
progetto che fornisce una definizione dell'ambito di alto livello.
Sviluppo della schedulazione / Schedule Development [processo]. Processo di analisi delle sequenze
e delle durate delle attività schedulate, dei requisiti delle risorse e dei vincoli della schedulazione
per la creazione della schedulazione di progetto.
SWOT (Analisi dei punti di forza, delle debolezze, delle opportunità e delle minacce) / Strengths,
Weaknesses, Opportunities, and Threats (SWOT) Analysis. Tecnica di raccolta delle
informazioni che esamina il progetto nell’ottica dei punti di forza, delle debolezze, delle
opportunità e delle minacce per allargare la prospettiva di analisi dei rischi presi in considerazione.
Task / Task. Termine utilizzato per indicare il lavoro, il cui significato e la cui collocazione all'interno
di un piano strutturato per il lavoro di progetto varia in base all'area applicativa, al settore e alla
marca di software di Project Management.
®
Tecnica / Technique. Procedura sistematica e definita utilizzata da una risorsa umana per eseguire
un'attività che genera un prodotto o un risultato o eroga un servizio e che può far uso di uno o più
strumenti.
Tecnica dell'Earned Value (ETV) / Earned Value Technique (EVT) [tecnica]. Tecnica specifica per
la misurazione delle prestazioni del lavoro per un componente della WBS, un punto di controllo o
un progetto. Denominata anche metodo delle regole di assorbimento e dei crediti.
Tecnica Delphi / Delphi Technique [tecnica]. Tecnica di raccolta delle informazioni che consente di
ottenere il consenso di esperti su un argomento specifico. Gli esperti dell'argomento applicano
questa tecnica in modo anonimo. Un mediatore utilizza un questionario per stimolare
l'elaborazione di idee sui punti importanti del progetto in merito all'argomento in questione. Le
risposte vengono riepilogate 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 un influsso maggiore degli altri
sul risultato.
Total Float (TF) / Total Float (TF). Lasso di tempo totale di cui si può ritardare un'attività schedulata
rispetto alla data di inizio minima senza rinviare la data di fine progetto o infrangere un vincolo
della schedulazione. Viene calcolato attraverso il metodo del percorso critico e la determinazione
della differenza tra le date di fine minime e le date di fine massime. Vedere anche Free Float.
Trasferire i rischi / Risk Transference [tecnica]. Tecnica di pianificazione della risposta ai rischi*
che trasferisce a terzi l'impatto di una minaccia e la responsabilità della risposta.
Trigger / Triggers. Indicano la presenza o l'imminente verificarsi di un rischio. I trigger possono
essere scoperti nel corso del processo per identificare i rischi e osservati nel processo di
monitoraggio e controllo dei rischi. Vengono talvolta definiti sintomi di rischio o segnali
d'allarme.
Triplo vincolo / Triple Constraint. Schema per la valutazione delle richieste concorrenti. Il triplo
vincolo viene di solito rappresentato sotto forma di un triangolo, in cui uno dei lati o uno degli
angoli simboleggia uno dei parametri gestiti dal gruppo di progetto.
Ultima revisione di stima / Latest Revised Estimate. Vedere stima al completamento.
Unità temporale / Calendar Unit. La più piccola unità di tempo utilizzata nella schedulazione di
progetto. Le unità temporali sono generalmente espresse in ore, giorni o settimane, ma possono
anche essere impostate su trimestri, mesi, turni o minuti.
Utente / User. La persona o l'organizzazione che utilizzerà il prodotto o il servizio del progetto. Vedere
anche cliente.
Valore pianificato (PV) / Planned Value (PV). Budget autorizzato e assegnato al lavoro schedulato
da eseguire nell'ambito di un'attività schedulata o di un componente della WBS. Definito anche
come costo preventivato del lavoro schedulato (BCWS).
Verifica / Verification [tecnica]. Tecnica di valutazione di un componente o di un prodotto al termine
di una fase o di un progetto per accertare o confermare che esso soddisfi le condizioni imposte.
Diverso da convalida.
Glossario
Verifica dell'ambito / Scope Verification [processo]. Processo di accettazione formale dei
deliverable del progetto completati.
Vincolo / Constraint [input]. Stato, qualità o senso di essere costretti ad agire o non agire in un dato
modo. Una restrizione o una limitazione, sia interna che esterna al progetto, che influisce sulle
prestazioni del progetto o di un processo. Ad esempio, un vincolo di schedulazione è una
limitazione o una restrizione imposta alla schedulazione di progetto che influisce sui tempi di
pianificazione di un'attività schedulata e che in genere si esprime sotto forma di date imposte fisse.
Un vincolo sui costi rappresenta una limitazione o una restrizione imposta sul budget del progetto,
ad es. i fondi resi disponibili nel corso del tempo. Un vincolo sulle risorse di progetto rappresenta
una limitazione o una restrizione imposta sull'utilizzo delle risorse, ad es. su quali siano le skill e le
discipline disponibili e sulla quantità di una data risorsa utilizzabile in uno specifico lasso di
tempo.
®
Glossario
War Room / War Room. Stanza utilizzata per le riunioni e la pianificazione del progetto, in cui
spesso vengono esposti i diagrammi dei costi, lo stato di schedulazione e altri dati rilevanti del
progetto.
WBS (Struttura di scomposizione del lavoro) / Work Breakdown Structure (WBS) [output/input].
Scomposizione gerarchica orientata verso i deliverable del lavoro che deve essere eseguito dal
gruppo di progetto per realizzare gli obiettivi del progetto e creare i deliverable richiesti. Organizza
e definisce l'ambito complessivo del progetto. Ogni livello discendente rappresenta una definizione
sempre più dettagliata del lavoro del progetto. La WBS viene scomposta in Work Package.
L'orientamento verso i deliverable fa in modo che siano inclusi sia i deliverable interni che quelli
esterni. Vedere anche Work Package, punto di controllo, WBS del contratto e WBS di riepilogo del
progetto.
WBS del contratto (CWBS) / Contract Work Breakdown Structure (CWBS) [output/input].
Porzione della WBS del progetto sviluppata e gestita da un fornitore per produrre un sottoprogetto
o un componente del progetto.
WBS di riepilogo del progetto (PSWBS) / Project Summary Work Breakdown Structure
(PSWBS) [strumento]. Struttura di scomposizione del lavoro del progetto che in alcuni rami è
sviluppata solo a livello di sottoprogetto. Il dettaglio dei singoli sottoprogetti si trova nelle varie
WBS di contratto sviluppate con i fornitori.
Work Package / Work Package. Deliverable o componente di lavoro del progetto al livello più basso
di ogni ramo della WBS. Il Work Package comprende le attività schedulate e le milestone di
schedulazione necessarie per completare il deliverable del Work Package o il componente di
lavoro del progetto. Vedere anche punto di controllo.
Workaround / Workaround [tecnica]. Risposta a un rischio negativo che si è verificato. Si distingue
dal piano delle contingency perché questa risposta non è pianificata in anticipo rispetto al
verificarsi dell’evento di rischio.
®
INDICE
analisi qualitativa del rischio, 10, 53, 237, 244,

A 246, 249, 250, 251, 253, 254, 259, 260, 263,
AC Vedere costo effettivo (AC) 370
accantonamento per contingency Vedere riserva analisi quantitativa del rischio, 10, 54, 237, 246,
accettare i rischi, 372 249, 250, 253, 254, 255, 257, 259, 260, 261,
accettare, 350 263, 370
accettazione, 102, 185, 263, 350 anello del reticolo, 364
acquirente, 271, 282, 293, 353 AOA Vedere attività su freccia (AOA)
acquisire il gruppo di progetto, 10, 57, 199, 209, AON Vedere attività su nodo (AON)
210, 212, 350 approvare, 86, 112, 352
ACWP Vedere costo effettivo del lavoro eseguito approvazione Vedere approvare
(ACWP) area applicativa, 13, 351
AD Vedere descrizione dell'attività (AD) area di conoscenza di Project Management, 9, 11,
ADM Vedere metodo del diagramma a frecce 69, 362, 368
(ADM), area di conoscenza, Project Management Vedere
AE Vedere impegno distribuito (AE) area di conoscenza di Project Management
AF Vedere data di fine effettiva (AF) AS Vedere data d’inizio effettiva (AS)
affidabilità, 370 asset dei processi organizzativi, 40, 84, 87, 90, 101,
allocazione dei costi, 10, 51, 157, 167, 168, 169, 102, 107, 109, 113, 122, 127, 136, 140, 143,
170, 171, 356 155, 162, 177, 184, 190, 191, 204, 210, 216,
ambito del progetto, 9, 43, 45, 78, 86, 87, 88, 89, 218, 225, 230, 234, 235, 236, 242, 247, 250,
99, 103, 105, 106, 108, 109, 110, 112, 113, 255, 268, 275, 284, 287, 294, 297, 365
117, 118, 119, 120, 121, 127, 131, 140, 143, assicurazione qualità (QA), 186, 187, 188, 189,
163, 168, 180, 184, 226, 242, 247, 250, 255, 197, 349
275, 347, 369 assunti, 127, 143, 163, 226, 248, 275, 352
ambito, 9, 48, 49, 62, 87, 103, 107, 108, 109, 110, attività critica, 357
112, 117, 118, 119, 120, 121, 122, 226, 374 attività di riepilogo, 376
amministrazione del contratto, 10, 65, 269, 289, attività fittizia, 359
290, 291, 292, 294, 296, 355 attività predecessore, 366
analisi degli assunti, 248, 352 attività quasi critica, 364
analisi dei punti di forza, delle debolezze, delle attività schedulata, 373
opportunità e delle minacce (SWOT), 248, 349, attività sommario, 361
375 attività su freccia (AOA), 133, 348, 351
analisi del reticolo di schedulazione, 145, 373 attività su nodo (AON), 132, 348, 351
analisi del reticolo, 364 attività successore, 376
analisi del valore monetario atteso (EMV), 257, attività, 10, 49, 50, 123, 127, 128, 129, 130, 131,
Indice
348, 360 132, 135, 136, 137, 138, 139, 140, 141, 142,
analisi della riserva, 142, 166, 169, 266, 371 143, 144, 151, 156, 164, 166, 167, 168, 204,
analisi della schedulazione Vedere analisi del 274, 276, 279, 282, 348, 350, 351
reticolo di schedulazione attributi delle attività, 130, 131, 135, 136, 138,
analisi dell'albero delle decisioni, 358 140, 143, 144, 151, 156, 350
analisi delle cause originarie, 373 auccessore Vedere attività successore
analisi delle tendenze, 266, 377 autorità, 207, 352
analisi dello scostamento, 121, 154, 378 autorizzazione del lavoro, 378
analisi di sensitività, 374 avvio del progetto, 368
analisi Monte Carlo, 146, 364 azienda, 40, 83, 87, 90, 101, 107, 127, 136, 140,
162, 184, 203, 210, 225, 242, 247, 275, 359
®
Indice
azione correttiva, 92, 93, 96, 98, 99, 119, 122, conoscenza, 3, 9, 12, 13, 15, 38, 70, 77, 78, 103,
155, 177, 189, 190, 197, 218, 234, 236, 267, 104, 117, 123, 148, 157, 179, 199, 200, 221,
294, 356 230, 237, 247, 264, 269, 270, 271, 349, 362,
azione preventiva, 92, 93, 96, 98, 99, 189, 197, 367, 368, 369, 370
218, 267, 366 contingency Vedere riserva
contratto a prezzo fermo e fisso (FFP), 348, 361
B contratto a prezzo fisso più incentivo (FPIF), 349,
BAC Vedere budget al completamento (BAC) 361
bando di gara (IFB), 349, 362 contratto a prezzo prefissato o a importo
baseline dei costi Vedere baseline forfettario, 361
baseline dell'ambito Vedere baseline contratto a rimborso spese più incentivo (CPIF),
baseline di misurazione delle prestazioni, 365 278, 348, 356
baseline, 151, 153, 155, 170, 172, 177, 187, 197, contratto a rimborso spese più percentuale dei
352, 356 costi (CPPC). Vedere contratto a rimborso
BCWP Vedere costo preventivato del lavoro eseguito spese più quota variabile
(BCWP) contratto a rimborso spese più quota fissa (CPFF),
BCWS Vedere costo preventivato del lavoro 278, 348, 356
programmato (BCWS) contratto a rimborso spese più quota variabile
beni, 361 (CPF), 278, 348, 356
BOM Vedere distinta base (BOM) contratto con rimborso spese, 356
brainstorming, 247, 353 contratto Time and Material (T&M), 377
budget al completamento (BAC), 173, 175, 176, 348, contratto, 10, 65, 67, 82, 100, 101, 102, 168, 269,
353 274, 277, 280, 281, 284, 288, 289, 290, 291,
budget, 177, 234, 263, 348, 353 292, 293, 294, 295, 296, 297, 348, 355
buffer, 353 controllare Vedere controllo
controllo dei costi, 10, 63, 157, 171, 172, 177, 356
C controllo della schedulazione, 10, 62, 123, 152,
CA Vedere punto di controllo (CA) 153, 154, 156, 373
calcolo a ritroso, 352 controllo dell'ambito, 9, 62, 103, 119, 120, 121,
calcolo in avanti, 361 374
calendario delle risorse, 138, 141, 144, 168, 371 controllo delle modifiche, 90, 96, 121, 153, 172,
calendario di progetto, 152, 367 292, 348, 353
cambiamento non controllato dell'ambito, 374 controllo di qualità (QC), 186, 190, 191, 197,
CAP Vedere piano dei punti di controllo (CAP) 198, 349, 356
capitolato (SOW), 375 controllo integrato delle modifiche, 9, 61, 79, 88,
capitolato contrattuale (SOW), 355 96, 98, 99, 101, 112, 119, 121, 122, 130, 135,
carta di controllo, 192, 193, 355 138, 152, 153, 155, 167, 171, 172, 177, 187,
categoria di rischio, 372 190, 197, 198, 218, 231, 234, 264, 267, 280,
causa comune, 354 290, 291, 294, 362
causa straordinaria, 375 controllo, 10, 63, 90, 94, 129, 158, 179, 189, 190,
cauzione, 372 191, 192, 193, 197, 232, 264, 265, 267, 291,
CCB Vedere comitato gestione modifiche (CCB) 348, 349, 355
charter Vedere Project Charter convalida, 377
chiudere il progetto, 9, 67, 79, 100, 101, 267, 295, convergenza di percorsi, 365
354 COQ Vedere costo della qualità (COQ)
chiusura del contratto, 10, 67, 102, 269, 274, 295, correzione dei difetti, 92, 93, 94, 96, 98, 99, 189,
296, 297, 355 196, 197, 358
ciclo di vita del progetto, 9, 19, 21, 23, 24, 368 corrispettivo, 354
ciclo di vita di prodotto, 23, 367 costo della qualità (COQ), 180, 186, 348, 356
ciclo di vita Vedere ciclo di vita del progetto costo effettivo (AC), 173, 176, 234, 348, 351, 356,
cliente, 26, 181, 357 357, 360,
codice attività, 350 costo effettivo del lavoro eseguito (ACWP), 348,
codice di classificazione, 354 351
co-location, 214, 354 costo preventivato del lavoro eseguito (BCWP),
comitato gestione modifiche (CCB), 348, 353 348, 353, 359
componente della WBS, 378 costo preventivato del lavoro programmato
componente, 129, 354 (BCWS), 348, 353, 366
compressione dei tempi (Crashing), 145, 357
compressione della schedulazione, 145, 373
comunicazione, 89, 224, 228, 354
®
costo, 10, 20, 21, 51, 63, 89, 112, 135, 141, 157, descrizione della mansione, 205, 366
158, 161, 162, 164, 165, 166, 167, 168, 169, descrizione dell'ambito del progetto, 9, 43, 45, 78,
170, 171, 172, 173, 176, 177, 180, 185, 186, 86, 87, 88, 89, 99, 108, 109, 110, 113, 117,
196, 210, 233, 234, 256, 259, 276, 278, 282, 118, 120, 121, 127, 131, 140, 143, 163, 168,
348, 355, 356, 357 184, 226, 242, 247, 250, 255, 275, 369
CPF Vedere contratto a rimborso spese più quota descrizione dell'attività (AD), 348, 351
variabile (CPF) descrizione delle specifiche di prodotto, 367
CPFF Vedere contratto a rimborso spese più quota diagramma a barre, 154, 352
fissa (CPFF) diagramma di flusso, 193, 361
CPI Vedere indice di efficienza dei costi (CPI) diagramma di Gantt Vedere diagramma a barre
CPIF Vedere contratto a rimborso spese più diagramma di Pareto, 195, 365
incentivo (CPIF) diagramma d'influenza, 362
CPM Vedere metodo del percorso critico (CPM) diagramma logico Vedere reticolo di schedulazione
CPPC Vedere contratto a rimborso spese più del progetto
percentuale dei costi (CPPC) diagramma reticolare della schedulazione su scala
creare la WBS (struttura di scomposizione del temporale, 377
lavoro), 357 difetto, 92, 93, 94, 96, 98, 99, 189, 196, 197, 358
criteri di accettazione, 350 dirigere e gestire l'esecuzione del progetto, 9, 56,
criteri, 283, 287, 357 78, 91, 92, 93, 119, 216, 232, 264, 267, 291,
curva a S, 374 358
CV Vedere scostamento dei costi (CV) disciplina, 359
CWBS Vedere WBS del contratto (CWBS) distinta base (BOM), 117, 348, 353
distribuzione delle informazioni, 10, 57, 221, 228,
D 229, 230, 231, 362
dalla parte del cliente, 180, 378 divergenza di percorsi, 365
data corrente Vedere data di aggiornamento dizionario della WBS, 378
data d’inizio attuale, 357 documenti di approvvigionamento, 282, 284, 367
data d’inizio effettiva (AS), 351 documento, 78, 285, 287, 359, 360
data d’inizio pianificata (PS) Vedere data d’inizio DU Vedere durata (DU)
schedulata DUR Vedere durata (DUR)
data d’inizio schedulata (SS), 366, 374 durata (DU o DUR), 348, 359
data d’inizio, 375 durata dell'attività, 10, 50, 123, 139, 140, 141,
data di aggiornamento (DD), 348, 357 142, 144, 164, 351
data di avanzamento Vedere data di durata effettiva, 351
aggiornamento durata originale (OD), 365
data di fine attuale, 357 durata residua (RD), 370
data di fine di baseline, 352
data di fine effettiva (AF), 348, 351 E
data di fine massima (LF), 349, 362 EAC Vedere stima al completamento (EAC)
data di fine minima (EF), 348, 359 Earned Value (EV), 173, 174, 176, 234, 348, 353,
data di fine pianificata (PF) Vedere data di fine 356, 357, 359, 373, 374
schedulata EF Vedere data di fine minima (EF)
data di fine schedulata (SF), 349, 366, 374 effettuare l'assicurazione qualità (QA), 365
data di fine, 361 elaborazione progressiva, 6, 367
data di inizio di baseline, 352 elemento di lavoro Vedere attività e attività
data di inizio massima (LS), 363 schedulata
data di inizio minima (ES), 348, 359 elenco delle attività, 129, 131, 135, 136, 140, 144,
data imposta, 362 156, 351
data obiettivo di completamento (TC), 376 EMV Vedere valore monetario atteso (EMV)
data obiettivo di fine (TF), 376 ES Vedere data di inizio minima (ES) Indice
data obiettivo di inizio (TS), 376 esecuzione del controllo di qualità (QC), 365
data, 144, 348, 358 esecuzione Vedere eseguire
database dei rischi, 372 esecuzione. Vedere eseguire
dati storici, 102, 362 eseguire, 38, 40, 41, 55, 56, 67, 68, 78, 92, 291,
DD Vedere data di aggiornamento (DD) 360
definizione dell'ambito, 9, 49, 87, 103, 109, 110, estremità aperta del reticolo, 364
112, 226, 374 ETC Vedere stima a finire (ETC)
definizione delle attività, 10, 49, 123, 127, 128, EV Vedere Earned Value (EV)
129, 130, 351 evento, 360
deliverable, 297, 358 evitare i rischi, 372
®
Indice
EVM Vedere metodo dell'Earned Value (EVM) gruppo di processi Vedere gruppo di processi di
EVT Vedere tecnica dell'Earned Value (EVT) Project Management
gruppo di progetto, 370
F gruppo di Project Management, 13, 369
Failure Mode and Effect Analysis (FMEA), 348, gruppo virtuale, 211, 378
360
fase di progetto, 22, 23, 116, 366, 369 H
fase Vedere fase di progetto
I
Fast Tracking, 360
fattori ambientali aziendali, 40, 83, 87, 90, 101, identificare i rischi, 10, 53, 237, 243, 246, 247,
107, 127, 136, 140, 162, 184, 203, 210, 225, 249, 250, 253, 254, 259, 261, 263, 372
242, 247, 275, 359 identificativo dell'attività, 351
FF Vedere fine-fine (FF) IFB Vedere bando di gara (IFB)
FF Vedere Free Float (FF) impegno discreto, 359
FFP Vedere contratto a prezzo fermo e fisso (FFP) impegno distribuito (AE), 348, 352
fine-fine (FF), 348, 361 impegno, 348, 349, 352, 359
fine-inizio (FS), 349, 361 indice di efficienza dei costi (CPI), 173, 174, 177,
Float Vedere Total Float e Free Float 234, 348, 356
FMEA Vedere Failure Mode and Effect Analysis indice di efficienza della schedulazione (SPI), 154,
(FMEA) 373
fondi, 361 informazioni sullo stato di avanzamento del
fornitore, 271, 278, 287, 289, 291, 292, 295, 374 lavoro, 94, 95, 98, 101, 120, 172, 188, 191,
FPIF Vedere contratto a prezzo fisso più incentivo 216, 232, 265, 292, 379
(FPIF) ingegneria del valore (VE), 378
Free Float (FF), 348, 361 iniziatore, 362
FS Vedere fine-inizio (FS) inizio-fine (SF), 375
funzioni operative, 364 inizio-inizio (SS), 375
input, 218, 230, 350, 351, 352, 353, 354, 355, 356,
G 357, 358, 359, 360, 362, 363, 365, 366, 367,
gestione dei costi di progetto, 10, 77, 157, 158, 368, 369, 370, 371, 372, 373, 378, 379
159, 160, 347, 367 integrale, 362
gestione dei rischi di progetto, 10, 77, 237, 239, integrato, 9, 61, 79, 88, 96, 98, 99, 101, 112, 119,
241, 249, 260, 266, 268, 347, 369 121, 122, 130, 135, 138, 152, 153, 155, 167,
gestione dei tempi di progetto, 10, 77, 123, 124, 171, 172, 177, 187, 190, 197, 198, 218, 231,
125, 126, 152, 347, 370 234, 264, 267, 280, 290, 291, 294, 362
gestione del portfolio, 16, 366 ispezione, 119, 196, 362
gestione della comunicazione di progetto, 10, 221, istogramma delle risorse, 208, 371
222, 223, 347, 367
K
gestione della qualità di progetto, 10, 179, 180,
182, 183, 185, 347, 369 knowledge base delle lesson learned, 363
gestione dell'ambito del progetto, 9, 103, 105, 106,
L
108, 109, 112, 113, 118, 119, 120, 180, 347,
369 lag, 362
gestione dell'approvvigionamento di progetto, 10, lavoro di progetto Vedere lavoro
269, 270, 271, 272, 273, 347, 369 lavoro, 6, 27, 82, 87, 91, 94, 95, 98, 101, 113, 114,
gestione delle risorse umane di progetto, 10, 199, 116, 117, 120, 121, 128, 163, 168, 172, 188,
200, 201, 202, 347, 368 191, 205, 216, 232, 265, 276, 280, 281, 284,
gestione dell'integrazione di progetto, 9, 77, 79, 292, 348, 349, 350, 359, 370, 378, 379
80, 347, 368 lead, 363
gestione qualità totale (TQM), 180, 181, 350, 377 lesson learned, 230, 363
gestire gli stakeholder, 10, 64, 221, 235, 236, 363 LF Vedere data di fine massima (LF)
gestire il gruppo di progetto, 10, 63, 199, 215, limiti di controllo, 355
216, 217, 218, 363 limiti di tolleranza delle specifiche, 375
gruppi di processi di progetto, 369 lista di controllo, 248, 353
gruppo di processi di Project Management, 9, 12, livellamento delle risorse, 146, 371
19, 23, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, livellamento Vedere livellamento delle risorse
47, 55, 56, 59, 60, 66, 67, 68, 69, 70, 77, 78, livello di impegno (LOE), 349, 363
85, 88, 100, 183, 354, 360, 362, 364, 366, 367, livello, 180, 361
368 LOE Vedere livello di impegno (LOE)
logica del reticolo, 364
®
logica Vedere logica del reticolo P
LS Vedere data di inizio massima (LS)
PC Vedere percentuale di completamento
M PCT Vedere percentuale di completamento
PDM Vedere metodo del diagramma di
manager funzionale, 361
precedenza
materiale, 116, 363
percentuale di completamento (PC o PCT), 349,
matrice assegnazione responsabilità (RAM), 206,
365
349, 371
percorso critico, 145, 348, 357
matrice di probabilità e impatto, 245, 251, 252,
percorso del reticolo, 364
367
Performing Organization, 366
membri del gruppo di lavoro Vedere membri del
PF Vedere data di fine pianificata (PF)
gruppo di progetto
pianificare gli acquisti, 10, 54, 269, 274, 275, 276,
membri del gruppo di progetto, 370
279, 296, 366
metodo del Critical Chain, 147, 357
pianificare le forniture, 10, 55, 269, 281, 282, 366
metodo del diagramma a frecce (ADM), 133, 352
pianificazione a finestra mobile, 128, 373
metodo del diagramma di precedenza (PDM), 132,
pianificazione della comunicazione, 10, 52, 211,
133, 258, 349 366
221, 225, 226, 227, 354
metodo del percorso critico (CPM), 357
pianificazione della gestione dei rischi, 10, 53,
metodo dell'Earned Value (EVM), 348, 359
237, 242, 243, 244, 245, 246, 249, 250, 251,
metodologia, 85, 87, 90, 93, 95, 99, 101, 243, 363
261, 372
milestone di schedulazione, 373
pianificazione della qualità, 10, 52, 179, 183, 184,
milestone, 89, 130, 131, 149, 151, 364
185, 186, 189, 370
minaccia, 377
pianificazione della risposta ai rischi, 10, 54, 237,
misurazione della performance tecnica, 266, 376
246, 249, 250, 254, 260, 261, 263, 373
modello di schedulazione, 10, 51, 62, 86, 89, 94,
pianificazione dell'ambito, 9, 48, 103, 107, 108,
112, 123, 130, 133, 137, 138, 139, 143, 144,
374
145, 148, 149, 151, 152, 153, 154, 155, 156,
pianificazione delle risorse umane, 10, 52, 199,
158, 164, 169, 173, 174, 178, 234, 274, 279,
202, 203, 204, 205, 207, 214, 362
349, 352, 366, 373, 374
pianificazione delle risorse. Vedere stima delle
modifica dell'ambito, 374
risorse delle attività, 204, 371
monitoraggio e controllo dei rischi, 10, 65, 237,
piano dei conti, 353
254, 264, 265, 266, 267, 291, 372
piano dei punti di controllo (CAP), 348, 355
monitoraggio Vedere monitorare
piano di gestione dei costi, 167, 168, 171, 356
monitorare e controllare il lavoro del progetto, 9,
piano di gestione dei rischi, 10, 53, 237, 242, 243,
61, 78, 94, 95, 96, 267, 364
244, 245, 246, 247, 249, 250, 251, 255, 260,
monitorare, 9, 38, 40, 41, 59, 60, 61, 78, 94, 95,
261, 265, 372
96, 171, 264, 265, 267, 364
piano di gestione del contratto, 290, 292, 296, 355
N piano di gestione del personale, 208, 210, 212,
213, 216, 375
networking, 207, 364
piano di gestione della comunicazione, 354
nodo, 348, 364
piano di gestione della qualità, 186, 188, 191, 370
O piano di gestione della schedulazione, 152, 153,
373
obiettivo, 364
piano di gestione dell'ambito del progetto, 108,
OBS Vedere struttura di scomposizione
109, 112, 113, 118, 119, 120, 369
dell'organizzazione (OBS)
piano di gestione dell'approvvigionamento, 279,
OD Vedere durata originale
281, 284, 287, 290, 296, 367
opportunità, 364
piano di Project Management, 91, 92, 95, 98, 99,
organigramma di progetto, 207, 210, 216, 369
101, 108, 122, 128, 137, 141, 144, 152, 156, Indice
organigramma, 205, 365
163, 172, 178, 185, 187, 190, 198, 204, 219,
organizzazione a matrice, 30, 31, 363
226, 232, 236, 242, 247, 255, 264, 268, 276,
organizzazione funzionale, 29, 361
281, 287, 295, 368
organizzazione per progetti, 29, 370
Planning Package, 129, 366
organizzazione, 9, 13, 19, 31, 32, 84, 180, 197,
PM Vedere Project Management (PM)
205, 226, 365
PM Vedere project manager (PM)
output, 350, 351, 352, 353, 354, 355, 356, 357,
PMBOK® Vedere Project Management Body of
358, 359, 360, 363, 365, 366, 367, 368, 369,
Knowledge (PMBOK®)
370, 371, 372, 373, 378, 379
PMIS Vedere sistema informativo di Project
Management (PMIS)
®
Indice
PMO Vedere Program Management Office PSWBS Vedere WBS di riepilogo del progetto
(PMO) (PSWBS)
PMO Vedere Project Management Office (PMO) punto di controllo (CA), 158, 348, 355
PMP® Vedere Project Management Professional PV Vedere valore pianificato (PV)
(PMP)
Portfolio, 16, 366 Q
pratica, 113, 234, 366 QA Vedere assicurazione qualità (QA)
previsioni, 96, 174, 234, 361 QC Vedere controllo di qualità (QC)
procedura documentata, 359 qualità, 10, 39, 52, 56, 63, 89, 118, 166, 179, 180,
procedura, 93, 101, 102, 296, 367 181, 183, 184, 185, 186, 187, 188, 189, 190,
processi di avvio, 362 191, 192, 197, 232, 252, 291, 348, 349, 350,
processi di chiusura, 354 370
processi di esecuzione, 360 questione, 84, 85, 218, 236, 362
processi di monitoraggio e controllo, 59, 364
processi di pianificazione, 366 R
processo di Project Management, 9, 11, 12, 19, 37, RAM Vedere matrice assegnazione responsabilità
38, 39, 40, 67, 69, 70, 77, 78, 79, 85, 89, 100, (RAM)
367, 368 rapporto sulle eccezioni, 360
processo di un'area di conoscenza, 362 RBS Vedere struttura di scomposizione dei rischi
processo, 23, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, (RBS)
47, 55, 56, 59, 60, 66, 67, 68, 69, 78, 85, 88, RBS Vedere struttura di scomposizione delle
89, 103, 106, 123, 126, 157, 159, 160, 179, risorse (RBS)
181, 183, 187, 188, 189, 194, 197, 200, 202, RD Vedere durata residua (RD)
221, 223, 230, 237, 241, 270, 273, 350, 351, reclamo, 354
354, 355, 356, 357, 358, 360, 362, 363, 364, registro dei rischi, 141, 144, 249, 250, 253, 255,
365, 366, 367, 370, 371, 372, 373, 374, 375 259, 261, 263, 265, 267, 372
prodotto, 23, 24, 38, 83, 86, 102, 104, 110, 111, registro, 218, 363
367 regolamento, 370
progetto, 3, 4, 5, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18, regole di base, 214, 361
19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 37, 38, relazione di dipendenza Vedere relazione logica
39, 40, 43, 45, 46, 67, 68, 69, 70, 77, 78, 79, 80, relazione di precedenza, 366
81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, relazione logica, 133, 358, 363
94, 95, 97, 98, 99, 100, 101, 102, 103, 104, 105, report sulle prestazioni, 120, 153, 172, 216, 233,
106, 108, 109, 110, 111, 112, 113, 117, 118, 266, 292, 366
119, 120, 121, 122, 123, 124, 125, 126, 127, reporting delle prestazioni, 10, 64, 221, 231, 232,
128, 129, 131, 135, 137, 140, 141, 142, 143, 233, 291, 293, 365
144, 148, 149, 150, 152, 154, 155, 156, 157, requisito, 371
158, 159, 160, 162, 163, 164, 165, 168, 170, reticolo di schedulazione del progetto, 135, 144,
171, 172, 176, 178, 179, 180, 181, 182, 183, 369
184, 185, 187, 190, 193, 198, 199, 200, 201, reticolo, 133, 364
202, 204, 207, 210, 212, 213, 216, 217, 218, revisione della progettazione, 180, 358
219, 221, 222, 223, 226, 229, 230, 231, 232, RFP Vedere richiesta d'offerta (RFP)
236, 237, 238, 239, 240, 241, 242, 243, 245, RFQ Vedere richiesta di preventivo (RFQ)
247, 248, 249, 250, 251, 255, 256, 260, 264, richiesta di informazioni, 367, 370
266, 267, 268, 269, 270, 271, 272, 273, 275, richiesta di modifica approvata, 92, 99, 109, 113,
276, 281, 282, 283, 287, 291, 295, 347, 349, 120, 131, 153, 172, 188, 192, 232, 236, 265,
352, 362, 367, 368, 369, 370, 375 292, 352
Program Management Office (PMO), 367 richiesta di modifica, 93, 95, 99, 189, 353
Program Management, 16, 349, 367 richiesta di modifica, 93, 96, 98, 112, 118, 119,
programma, 4, 16, 349, 367 122, 130, 135, 138, 152, 155, 167, 171, 177,
Project Charter, 43, 45, 86, 87, 108, 109, 353, 367 190, 197, 218, 231, 234, 267, 280, 290, 294,
Project Management (PM), 349, 368 371
Project Management Body of Knowledge richiesta di preventivo (RFQ), 371
(PMBOK®), 3, 4, 9, 12, 77, 78, 349, 368 richiesta di risposte dai fornitori, 10, 58, 269, 281,
Project Management Office (PMO), 17, 18, 26, 284, 285, 371
32, 33, 349, 368 richiesta d'offerta (RFP), 370
Project Management Professional (PMP®), 4, 8, ridurre i rischi, 372
283, 349, 368 rifacimento, 372
project manager (PM), 349, 369 rischio collaterale, 374
PS Vedere data d’inizio pianificata (PS), 349 rischio residuo, 371
®
rischio, 10, 53, 54, 65, 84, 89, 117, 141, 144, 164, soggetto influente, 362
237, 238, 240, 242, 243, 244, 245, 246, 247, soglia, 377
248, 249, 250, 251, 252, 253, 254, 255, 256, sottofase, 376
259, 260, 261, 262, 263, 264, 265, 266, 267, sottoprogetto, 376
276, 281, 287, 291, 349, 372, 373 sottoreticolo, 133, 376
riserva per contingency, 355 SOW Vedere capitolato (SOW), 82, 280, 349
riserva, 142, 166, 169, 263, 264, 266, 355, 371 specifiche di prodotto, 367
risorsa, 89, 94, 117, 137, 138, 140, 141, 144, 146, specifiche di prodotto, 375
147, 148, 151, 162, 165, 168, 199, 204, 208, SPI Vedere indice di efficienza della
212, 213, 290, 349, 371 schedulazione (SPI), 155, 174, 177, 234, 349,
risultato, 102, 372 373
rubrica del gruppo di progetto, 370 sponsor del progetto. Vedere sponsor
ruolo, 32, 207, 373 sponsor, 26, 375, 370
SS Vedere data d’inizio schedulata (SS)
S SS Vedere inizio-inizio (SS)
schedulazione a risorse limitate, 371 stakeholder di progetto. Vedere stakeholder
schedulazione a risorse vincolate Vedere stakeholder, 19, 24, 26, 82, 83, 109, 110, 111, 180,
schedulazione a risorse limitate, 371 226, 227, 231, 235, 370, 375
schedulazione delle milestone, 151, 364 standard, 9, 113, 282, 375
schedulazione di progetto, 10, 51, 62, 86, 89, 94, stima a finire (ETC), 173, 175, 177, 348, 360
112, 123, 130, 133, 135, 137, 138, 139, 143, stima a tre valori, 142, 377
144, 145, 148, 149, 150, 151, 152, 153, 154, stima al completamento (EAC), 173, 175, 176,
155, 156, 158, 164, 168, 169, 173, 174, 178, 177, 348, 360, 363
193, 234, 274, 279, 349, 352, 366, 369, 373, stima bottom-up, 137, 165, 353
374 Stima dei costi, 10, 51, 135, 157, 161, 162, 164,
schedulazione obiettivo, 376 166, 167, 356
schedulazione principale, 363 stima della durata delle attività, 10, 50, 123, 139,
schedulazione Vedere schedulazione di progetto e 140, 141, 142, 164, 351
modello di schedulazione stima delle risorse delle attività, 10, 50, 123, 135,
schema di documento, 376 136, 137, 138, 141, 164, 274, 279, 351
scomporre Vedere scomposizione stima di congruità del costo, 374
scomposizione, 114, 115, 128, 358 stima parametrica, 142, 165, 169, 365
scostamento dei costi (CV), 173, 177, 234, 348, stima per analogia, 141, 164, 351
357 stima, 167, 168, 173, 348, 360
scostamento dei tempi (SV), 154, 155, 173,177, strumento, 352, 353, 354, 355, 361, 362, 363, 364,
234, 349, 374 365, 366, 367, 368, 369, 370, 371, 372, 373,
scostamento, 121, 154, 158, 176, 234, 266, 348, 377, 378
349, 378 struttura di scomposizione dei rischi (RBS), 117,
selezionare i fornitori, 10, 58, 269, 281, 286, 287, 138, 205, 243, 244, 247, 248, 249, 253, 255,
288, 289, 290, 374 263, 268, 349, 372
sequenzializzazione delle attività, 10, 50, 123, struttura di scomposizione del lavoro (WBS) , 9,
130, 131, 132, 135, 351 49, 86, 103, 104, 108, 112, 113, 114, 115, 116,
servizio, 102, 374 117, 118, 120, 121, 127, 128, 129, 130, 149,
SF Vedere data di fine schedulata (SF), 349 155, 158, 159, 163, 168, 169, 173, 175, 177,
SF Vedere inizio-fine (SF), 349 205, 206, 214, 234, 253, 258, 263, 276, 280,
simulazione, 146, 259, 375 350, 366, 370, 378
sistema di autorizzazione del lavoro, 378 struttura di scomposizione delle risorse (RBS),
sistema di controllo delle modifiche, 90, 121, 153, 117, 138, 205, 243, 247, 248, 249, 253, 255,
172, 292, 353 263, 268, 349, 371
sistema di gestione della configurazione, 90, 121, struttura di scomposizione dell'organizzazione Indice
354 (OBS) , 117, 205, 349, 355, 365
sistema di Project Management, 33, 369 SV Vedere scostamento dei tempi (SV)
sistema informativo di Project Management sviluppare il gruppo di progetto, 10, 57, 199, 209,
(PMIS), 86, 95, 349, 368 212, 213, 215, 358
sistema, 86, 88, 90, 93, 95, 99, 101, 248, 288, 293, sviluppare il piano di Project Management, 9, 48,
296, 349, 376 78, 88, 89, 90, 91, 124, 158, 358
skill, 375 sviluppare il Project Charter, 9, 43, 45, 78, 81, 82,
Slack Vedere Total Float e Free Float, 375 85, 86, 358
software di Project Management, 137, 148, 154, sviluppare la descrizione dell'ambito del progetto
165, 176, 368 (preliminare), 358
®
Indice
sviluppo della schedulazione, 10, 51, 123, 138,

139, 143, 144, 145, 149, 151, 152, 169, 274, U
279, 373 ultima revisione di stima Vedere stima al
SWOT Vedere analisi dei punti di forza, delle completamento
debolezze, delle opportunità e delle minacce unità temporale, 353
(SWOT) utente, 377
T V
T&M Vedere Time and Material (T&M) valore pianificato (PV) , 173, 174, 175, 176, 234,
TC Vedere data obiettivo di completamento (TC) 349, 353, 366, 373, 374
tecnica dell'Earned Value (EVT), 172, 348, 359 VE Vedere ingegneria del valore (VE), 350
tecnica Delphi, 358 verifica dell'ambito, 9, 62, 103, 118, 119, 374
tecnica, 95, 348, 351, 352, 353, 354, 355, 356, verifica, 97, 378
357, 358, 359, 360, 361, 362, 363, 364, 365, vincolo, 354
366, 367, 371, 372, 373, 376, 377, 378, 379
TF Vedere data obiettivo di fine (TF) W
TF Vedere Total Float (TF) War Room, 378
Total Float (TF), 377 WBS del contratto (CWBS), 348, 355
TQM Vedere gestione qualità totale (TQM) WBS di riepilogo del progetto (PSWBS), 370
trasferire i rischi, 373 WBS Vedere struttura di scomposizione del lavoro
triggers, 377 (WBS)
triplo vincolo, 377 Work Package, 114, 379
TS Vedere data obiettivo di inizio (TS) workaround, 379
®
Come colmare il divario tra la strategia aziendale e i
risultati ottenuti? È una questione di resa e della garanzia
di essere in grado di farlo…
A prescindere che siate un dirigente anziano o un project manager, è vostro compito supportare la
crescita della vostra organizzazione e incrementarne il valore a favore degli stakeholder. Il Project
Management è quella esclusiva competenza organizzativa che consente di gestire le modifiche e di
orientare il vantaggio competitivo, ottenendo dei risultati conformi alla strategia aziendale. La Guida
al Project Management Body of Knowledge (Guida al PMBOK®), terza edizione, fornisce tutte le
indicazioni necessarie per ottenere questo obiettivo.
Nel 1983, i volontari del Project Management Institute (PMI®) si sono riuniti per riassumere l'insieme
di conoscenze in ambito di Project Management, ovvero il Project Management Body of Knowledge.
Oggi, la Guida al PMBOK® si è imposta come standard internazionale di fatto della professione del
Project Management e rappresenta uno dei documenti migliori e più versatili disponibili per i
principali settori. La Guida al PMBOK® contiene le pratiche di baseline fondamentali che orientano i
risultati di qualsiasi organizzazione, sia essa locale, nazionale o internazionale.
Attualmente, vengono consultate più di un milione di copie della Guida al PMBOK®. La Guida al
PMBOK® - Terza edizione è stata aggiornata in modo da riflettere le conoscenze e le pratiche
attualmente in uso nel settore.
Una delle modifiche più importanti che caratterizzano questa edizione riguarda il passaggio da
“largamente accettato nella maggior parte dei progetti e la maggior parte delle volte” a “largamente
riconosciuto come una pratica efficace per la maggior parte dei progetti e la maggior parte delle
volte.” Molti capitoli sono stati aggiornati, riscritti o ampliati in modo da riflettere le informazioni più
recenti e rilevanti disponibili oggi per i project manager.
La Guida al PMBOK® - Terza edizione comprende anche un indice e un glossario estesi che
rispecchiano le modifiche che si sono verificate nel settore del Project Management nel corso degli
ultimi quattro anni.
La Guida al PMBOK® - Terza edizione riflette la collaborazione e le conoscenze dei leader del
Project Management che generano i risultati aziendali. Il Project Management di successo è un
vantaggio costante nella natura dinamica delle organizzazioni odierne. Le aziende, le società non-
profit e gli enti governativi di tutto il mondo stanno adottando l'approccio del Project Management
per raggiungere obiettivi aziendali strategici. Poiché il riconoscimento del valore del Project
Management è in continua crescita, la Guida al PMBOK® diventerà uno strumento sempre più
indispensabile per i professionisti di tutte le organizzazioni, in tutti i settori e in tutte le aree del
mondo.

Pmi Pmbok - A Guide To The Project Management Body of Knowledge (3rd Edition, 2004) Ita PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Pmi Pmbok - A Guide To The Project Management Body of Knowledge (3rd Edition, 2004) Ita PDF

Caricato da

Copyright:

Formati disponibili

Guida al

un American National Standard

Pubblicato da: Project Management Institute, Inc.

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

Prefazione alla terza edizione ...........................................................vii

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

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

Dennis Bolles, PMP Steve Fahrenkrog, PMP

Capitolo 2 Ciclo di vita del progetto e Struttura

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

1.1.1 Destinatari della Guida al PMBOK®

1.2.2 Progetti e lavoro operativo a confronto

1.2.3 Progetti e pianificazione strategica

1.3 Che cos’è il Project Management?

1.4.1 Sezione I: Il contesto del Project Management

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

1.4.3 Sezione III: Le aree di conoscenza di Project Management

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

1.5 Aree di esperienza

1.5.1 Project Management Body of Knowledge

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

• Uno standard è un “documento stabilito tramite consenso diffuso e approvato da

1.5.3 Comprensione del contesto del progetto

1.5.5 Capacità interpersonali.

1.6 Il contesto del Project Management

1.6.1 Programmi e Program Management

1.6.2 Portfolio e gestione del portfolio

1.6.4 Project Management Office

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

Ciclo di vita del progetto e Struttura

2.1 Il ciclo di vita del progetto

2.1.1 Caratteristiche del ciclo di vita del progetto

Figura 2-2. Influenza dei stakeholder nel corso del tempo

2.1.2 Caratteristiche delle fasi di progetto

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

2.2 Stakeholder di progetto

Figura 2-5. Relazione tra gli stakeholder e il progetto

Gli stakeholder principali di un progetto includono:

2.3.1 Sistemi di strutture organizzative

2.3.2 Cultura e stile delle strutture organizzative

La cultura delle strutture organizzative ha spesso un’influenza diretta sui

2.3.3 Struttura organizzativa

Figura 2-6. Influenza delle strutture organizzative sui progetti

Figura 2-7. Struttura organizzativa funzionale

Figura 2-8. Organizzazione per progetti

Figura 2-9. Organizzazione a matrice debole

Figura 2-10. Organizzazione a matrice equilibrata

Figura 2-11. Organizzazione a matrice forte

Figura 2-12. Organizzazione composita

2.3.4 Ruolo del PMO nelle strutture organizzative

Capitolo 3 Processi di Project Management per

Processi di Project Management per un

In effetti, i project manager e i componenti dei gruppi di progetto dovrebbero

3.1 Processi di Project Management

Figura 3-1. Ciclo “Plan-Do-Check-Act”

Figura 3-2. Gruppi di processi di Project Management descritti secondo il ciclo

3.2 Gruppi di processi di Project Management

Figura 3-3. Legenda del diagramma di flusso

Figura 3-5. Confini del progetto

All’interno del gruppo di processi di avvio, progetti particolarmente estesi o

Figura 3-6. Gruppo di processi di avvio

Tabella 3-1. Sviluppare il Project Charter: input e output