Pmbok 2004

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

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

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

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

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

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

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

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

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

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

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

ELENCO TABELLE E FIGURE

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

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

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

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

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

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

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

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

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

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

Tradurre letteratura tecnica in lingue diverse da quella originale non compito

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gli obiettivi dei progetti e delle funzioni operative sono di natura

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

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

1.3
Che cos il Project Management?

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

1.4
La struttura della Guida al PMBOK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5.4
Conoscenza e skill in materia di general management

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

15
1.6
Il contesto del Project Management

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

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

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

Le strutture organizzative gestiscono i propri portfolio sulla base di obiettivi

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

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

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

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

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

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

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

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

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

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

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

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

Il completamento formale della fase non include anche lautorizzazione

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

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

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

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

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

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

25
Gli stakeholder principali di un progetto includono:

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

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

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

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

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

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

27
La cultura delle strutture organizzative ha spesso uninfluenza diretta sui

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

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

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

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

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

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

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

31
2.3.4
Ruolo del PMO nelle strutture organizzative

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

2.3.5
Sistema di Project Management

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

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

un progetto
CAPITOLO 3
Processi di Project Management per un

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

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

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

Questo capitolo fornisce informazioni riguardo al Project Management di un

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

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

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

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

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

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

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

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

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

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

3.2.1
Gruppo di processi di avvio

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

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

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

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

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

di seguito.
.1
Sviluppare il Project Charter

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

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

45
3.2.2
Gruppo di processi di pianificazione

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

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

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

47
.1
Sviluppare il piano di Project Management

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

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

49
.6
Sequenzializzazione delle attivit

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

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

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

.9
Sviluppo della schedulazione

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

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

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

51
.12
Pianificazione della qualit

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

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

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

.15
Pianificazione della gestione dei rischi

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

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

53
.18
Analisi quantitativa del rischio

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

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

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

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

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

55
I normali scostamenti nellesecuzione comporteranno una ripianificazione.

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

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

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

.3
Acquisire il gruppo di progetto

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

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

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

57
.6
Richiesta di risposte dai fornitori

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

3.2.4
Gruppo di processi di monitoraggio e controllo

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

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

Management descritti di seguito.
60

.1
Monitorare e controllare il lavoro del progetto

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

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

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

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

.6
Controllo dei costi

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

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

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

63
.9
Reporting delle prestazioni

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

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

.11
Monitoraggio e controllo dei rischi

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

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

65
3.2.5
Gruppo di processi di chiusura

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

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

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

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

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

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

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

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

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

Project Management e alle aree di conoscenza
70

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

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

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

75
Parte III - Introduzione
Principali documenti di progetto

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

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

CAPITOLO 4

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

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

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

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

79
80

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

81
4.1
Sviluppare il Project Charter

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

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

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

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

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

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

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

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

.4
Asset dei processi organizzativi

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

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

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

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

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

.3
Sistema informativo di Project Management

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

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

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

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

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

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

Per la descrizione, consultare il paragrafo 4.1.1.2.
.3

.4

4.2.2 Sviluppare la descrizione preliminare dell'ambito del progetto:

Strumenti e tecniche
.1

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

.2

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

Output
.1
4.3
Descrizione preliminare dell'ambito del progetto

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

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

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

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

.2
Processi di Project Management

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

.3

.4

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

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

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

91
4.3.3 Sviluppare il piano di Project Management: Output

.1
4.4
Piano di Project Management

Dirigere e gestire l'esecuzione del progetto

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

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

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

.2
Azioni correttive approvate

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

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

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

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

93
.6
Correzione dei difetti convalidata

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

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

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

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

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

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

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

4.5
.6
Correzione dei difetti implementata

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

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

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

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

.2

.3
Richieste di modifica rifiutate

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

tecniche
.1

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

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

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

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

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

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

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

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

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

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

Ogni modifica richiesta documentata deve essere accettata o rifiutata da una

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

.2
Modifiche richieste
.3

.4

.5

.6

.7
Deliverable

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

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

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

.2
Richieste di modifica rifiutate

.3
Piano di Project Management (aggiornamenti)

.4
Descrizione dell'ambito del progetto (aggiornamenti)

.5
Azioni correttive approvate

.6
Azioni preventive approvate

.7
Correzione dei difetti approvata

.8

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

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

101
4.7.1
Chiudere il progetto: Input
.1

.2
Documentazione del contratto

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

.4

.5

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

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

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

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

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

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

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

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

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

103
CAPITOLO 5
La gestione dellambito di progetto comprende i processi necessari ad assicurare che il

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

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

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

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

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

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

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

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

107
Regole organizzative che fanno capo alla pianificazione e alla gestione

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

.5

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

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

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

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

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

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

.5

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

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

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

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

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

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

Obiettivi del progetto: Gli obiettivi del progetto comprendono i criteri

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

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

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

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

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

.2

.3

.4

5.3.2
.1
Creare la WBS: Strumenti e tecniche

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

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

La scomposizione del lavoro complessivo di progetto comporta in genere le

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

115
Nell'ambito della verifica della correttezza della scomposizione necessario

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

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

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

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

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

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

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

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

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

.3

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

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

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

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

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

.3

.4

.5
Report sulle prestazioni

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

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

120

5.5.2
.1
Controllo dell'ambito: Strumenti e tecniche

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

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

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

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

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

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

121
.4
Baseline dell'ambito (aggiornamento)

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

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

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

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

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

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

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

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

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

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

6.1
Definizione delle attivit

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

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

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

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

127
.4
Struttura di scomposizione del lavoro (WBS)

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

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

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

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

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

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

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

129
6.2
.2
Attributi delle attivit

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

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

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

6.2.1
Sequenzializzazione delle attivit: Input
.1

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

.3

.4
Elenco delle milestone

.5
Richiesta di modifica approvata

Figura 6-5. Metodo del diagramma di precedenza

131
6.2.2
.1
Sequenzializzazione delle attivit: Strumenti e tecniche

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

.2
Metodo del diagramma a frecce (ADM)

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

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

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

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

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

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

6.2.3
.1
6.3
Sequenzializzazione delle attivit: Output

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

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

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

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

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

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

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

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

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

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

.5
Disponibilit delle risorse

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

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

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

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

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

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

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

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

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

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

6.4
Stima della durata delle attivit

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

139
6.4.1
Stima della durata delle attivit: Input
.1

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

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

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

.5

.6

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

.7
Calendario delle risorse

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

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

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

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

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

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

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

.2
6.5

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

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

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

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

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

.4

.5
Reticoli di schedulazione del progetto

.6

.7
Calendario delle risorse

.8
Stime della durata dell'attivit

.9

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

6.5.2
.1
Sviluppo della schedulazione: Strumenti e tecniche

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

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

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

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

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

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

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

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

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

147
.7

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

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

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

6.5.3
.1
Sviluppo della schedulazione: Output

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

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

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

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

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

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

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

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

151
6.6
.6
Calendario di progetto (aggiornamenti)

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

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

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

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

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

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

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

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

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

153
.3
Misurazione delle prestazioni

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

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

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

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

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

.2
Baseline della schedulazione (aggiornamenti)

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

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

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

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

155
.7
Elenco delle attivit (aggiornamenti)

Descritta nel paragrafo 6.1.3.1.
.8

Descritta nel paragrafo 6.1.3.2.
.9

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

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

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

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

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

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

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

7.1
Stima dei costi

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

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

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

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

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

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

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

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

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

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

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

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

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

.2
Determinazione dei costi delle risorse

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

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

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

165
.7

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

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

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

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

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

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

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

167
7.2.1
Allocazione dei costi: Input
.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3
.3
Piano di gestione dei costi (aggiornamenti)

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

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

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

.2
Requisiti di finanziamento del progetto

.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

177
.8

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

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

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

La moderna gestione della qualit rappresenta un'integrazione al Project

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

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

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

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

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

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

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

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

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

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

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

Pianificazione della qualit: Strumenti e tecniche

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

185
.4
Costo della qualit (COQ)

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

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

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

.3
Liste di controllo qualit

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

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

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

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

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

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

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

.4

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

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

.6
Misurazioni del controllo qualit

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

.8
Azioni correttive implementate

.9
Correzione dei difetti implementata

.10
Azioni preventive implementate

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

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

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

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

Per la descrizione, consultare il paragrafo 8.3.2.

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

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

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

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

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

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

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

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

.4

.5

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

191
.6

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

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

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

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

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

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

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

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

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

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

.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1.2
.1
Pianificazione delle risorse umane: Strumenti e tecniche

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

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

205
Diagrammi basati sulla matrice: la matrice di assegnazione delle

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

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

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

207
.3
Piano di gestione del personale

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

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

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

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

209
9.2.1
Acquisire il gruppo di progetto: Input
.1

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

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

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

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

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

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

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

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

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

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

9.3.1
Sviluppare il gruppo di progetto: Input
.1

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

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

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

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

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

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

9.3.3
.1
9.4
Sviluppare il gruppo di progetto: Output

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

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

215
9.4.1
Gestire il gruppo di progetto: Input
.1

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

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

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

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

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

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

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

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

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

217
.4
9.4.3
Registro delle questioni

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

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

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

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

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

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

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

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

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

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

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

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

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

10.1 Pianificazione della comunicazione

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

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

225
.3 Descrizione dellambito del progetto

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

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

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

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

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

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

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

10.2.1 Distribuzione delle informazioni: Input

10.2.2 Distribuzione delle informazioni: Strumenti e tecniche

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

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

229
.4 Processo delle lesson learned

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

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

Presentazioni di progetto: il gruppo di progetto fornisce informazioni

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

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

231
10.3.1 Reporting delle prestazioni: Input

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

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

.2 Raccolta e compilazione delle informazioni sulle prestazioni

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

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

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

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

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

10.4 Gestione degli stakeholder

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

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

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

235
.2 Registri delle questioni

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

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

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

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

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

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

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

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

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

241
11.1 Pianificazione della gestione dei rischi

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

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

11.1.2 Pianificazione della gestione dei rischi: strumenti e tecniche

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

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

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

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

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

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

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

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

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

11.2.1 Identificazione dei rischi: Input

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

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

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

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

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

11.2.3 Identificazione dei rischi: Output

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

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

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

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

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

11.3.2 Analisi qualitativa dei rischi: Strumenti e tecniche

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

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

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

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

.4 Categorizzazione dei rischi

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

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

253
11.4 Analisi quantitativa dei rischi

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

11.4.1 Analisi quantitativa dei rischi: Input

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

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

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

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

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

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

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

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

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

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

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

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

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

Alguns componentes do plano de gerenciamento de riscos que so entradas

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

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

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

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

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

.3 Strategia sia per minacce sia per opportunit

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

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

263
Piani di contingency e trigger che ne richiedono lesecuzione.

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

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

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

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

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

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

265

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

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

.6 Riunioni sullo stato di avanzamento

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

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

267

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

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

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

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

Un progetto complesso pu comportare la gestione contemporanea o in

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

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

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

273
12.1 Pianificare gli acquisti

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

12.1.1 Pianificare gli acquisti: Input

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

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

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

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

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

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

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

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

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

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

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

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

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

12.2 Pianificare le forniture

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

.2 Capitolato contrattuale
.3 Decisioni make-or-buy
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.
12

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 dellanalisi dei rischi, lassegnazione 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.

281
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 dellapprovvigionamento, 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 lacquisto di articoli commerciali o standard), si utilizzano
termini come offerta, offerta dappalto o preventivo; mentre quando
lattenzione si concentra su altri fattori, quali le competenze tecniche o lapproccio
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
dofferta, richiesta di preventivo, notifica di offerta dappalto, invito alla negoziazione
e risposta iniziale dellappaltatore.
Lacquirente 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 dellacquisto 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
uneventuale soluzione alternativa in una proposta separata.
282

Linvio di una richiesta ai potenziali fornitori per invitarli a inoltrare una

proposta o unofferta viene effettuato nel modo dettato dalle politiche
dellorganizzazione dellacquirente, 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 unesperienza
precedente documentata di partecipazione a progetti simili). I criteri di valutazione
vengono spesso inseriti nei documenti di approvvigionamento.
Se lelemento oggetto dellapprovvigionamento 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 dellelemento 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 dellesigenza: 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?
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
dellinteresse atti a soddisfare i potenziali requisiti futuri?
Dimensioni e tipologia delle attivit: lazienda del fornitore del tipo o delle
dimensioni specificate? Per esempio, una piccola azienda, unazienda
appartenente allimprenditoria femminile o una piccola azienda fondata per
persone portatrici di handicap, in base a quanto definito dallacquirente o
stabilito dallente pubblico e imposto come condizione di idoneit per
lassegnazione 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 nellambito 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
nellambito del progetto?
12

283
.3 Capitolato contrattuale (aggiornamenti)

Durante lo sviluppo della documentazione dellapprovvigionamento 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 lacquirente.
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 unofferta, 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
284

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 dellofferta o della proposta. Tali conferenze consentono a
tutti i potenziali fornitori di comprendere chiaramente e integralmente loggetto
dellapprovvigionamento (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 lofferta 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 dellorganizzazione. 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
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
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
Linsieme di documenti di approvvigionamento consta di una richiesta formale
preparata dallacquirente e inviata a ciascun fornitore, che sar la base su cui il
fornitore preparer unofferta per i prodotti, i servizi o i risultati richiesti e descritti
nella documentazione di approvvigionamento.

285
.3 Proposte
Le proposte sono documenti redatti dal fornitore che descrivono labilit 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 lapplicazione dei principi
contrattuali applicabili. La proposta del fornitore costituisce unofferta formale e
legalmente valida in risposta a una richiesta effettuata dallacquirente. Dopo linvio
formale della proposta, lacquirente 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 allacquirente 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 lassegnazione 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 dellelenco si chiede quindi di presentare
proposte pi dettagliate ed esaustive da analizzare in profondit.
286

Figura 12-6. Selezionare i fornitori: Input, Strumenti e tecniche e Output
12.4.1 Selezionare i fornitori: Input

Le organizzazioni coinvolte nellapprovvigionamento 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
valutazione possono anche comprendere unanalisi delle collaborazioni precedenti del
fornitore con lorganizzazione acquirente o con terzi.
12
.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 dellinsieme di
informazioni che lorgano 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):

287
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 lassegnazione 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, lorganizzazione che si occupa
dellapprovvigionamento 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 lelemento 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
unofferta riesaminata dal fornitore o una controfferta dellacquirente.
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.
288

.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 unimportante
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 lambito 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
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
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
dellofferta e quando hanno negoziato una bozza del contratto, che sar il contratto
effettivo al momento dellassegnazione.
.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 lacquirente 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.

289
.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
dallacquirente, per elementi come la documentazione, i requisiti di consegna, le
prestazioni, che devono essere rispettati sia dallacquirente 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.
.4 Disponibilit delle risorse
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 dellapprovvigionamento (aggiornamenti)
Il piano di gestione dellapprovvigionamento (paragrafo 12.1.3.1) viene aggiornato
per rispecchiare eventuali richieste di modifica approvate (paragrafo 4.4.1.4) che
influiscono sulla gestione dellapprovvigionamento.
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 dellapprovvigionamento. Le modifiche richieste vengono elaborate per
lanalisi e la decisione mediante il processo di controllo integrato delle modifiche
(paragrafo 4.6).
12.5 Amministrazione del contratto

Sia lacquirente che il fornitore amministrano il contratto rispondendo ad obiettivi
simili. Ciascuna delle parti verifica la conformit propria e quella dellaltra 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 lacquirente 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 dellamministrazione 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 nellamministrazione di qualsiasi contratto. A causa delle considerazioni di
tipo legale, molte organizzazioni considerano lamministrazione del contratto come
una funzione amministrativa distinta dal resto dellorganizzazione del progetto. Anche
quando lamministratore 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.
LAmministrazione del contratto prevede lapplicazione dei processi di Project
Management adeguati alle relazioni contrattuali e lintegrazione degli output ottenuti
da questi processi nella gestione complessiva del progetto. Quando sono coinvolti pi
fornitori e pi prodotti, servizi o risultati solitamente lintegrazione avviene a pi
livelli. Di seguito vengono elencati, a titolo esemplificativo, i processi di Project
Management applicati.
290

Dirigere e gestire lesecuzione 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
ladeguatezza 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.
Lamministrazione 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 allavanzamento 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 dellacquirente 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 lacquirente prende in considerazione la
possibilit di procedere con azioni correttive. Lamministrazione del contratto prevede
la gestione delleventuale 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.
12
Figura 12-7. Amministrazione del contratto: Input, Strumenti e tecniche e Output

291
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.
.6 Informazioni sullo stato di avanzamento del lavoro
Nel corso dellesecuzione 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
lautorizzazione delle modifiche. Il sistema di controllo delle modifiche contrattuali si
deve integrare con il sistema di controllo integrato delle modifiche.
292

.2 Verifica delle prestazioni condotta dallacquirente

Una verifica delle prestazioni dellapprovvigionamento unanalisi strutturata del
grado di avanzamento del lavoro del fornitore e del rispetto delle condizioni
contrattuali per quanto riguarda lambito del progetto, la qualit, i costi e la
schedulazione. Pu prevedere lesame della documentazione preparata dal fornitore,
le ispezioni dellacquirente e le revisioni di qualit condotte durante lesecuzione del
lavoro del fornitore. Lobiettivo di una verifica delle prestazioni identificare i
successi e le carenze nelle prestazioni, lavanzamento del lavoro rispetto al capitolato
contrattuale e le conformit contrattuali, per permettere allacquirente di quantificare
la capacit o lincapacit dimostrata dal fornitore nelleseguire il lavoro.
.3 Ispezioni e revisioni
Le ispezioni e le revisioni (paragrafo 8.2.2.2), richieste dallacquirente e supportate
dal fornitore in base a quanto definito nel contratto, possono essere condotte durante
lesecuzione 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 dellacquirente addetto
allapprovvigionamento.
.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 dellacquirente. Per progetti di grandi dimensioni, che prevedono
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).
12
.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 lacquirente e il fornitore non trovano accordo sul prezzo della modifica o
sullesistenza 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.

293
.8 Tecnologie informatiche
Luso delle tecnologie informatiche e di comunicazione pu migliorare lefficienza e
lefficacia dellamministrazione del contratto poich consente di automatizzare una
parte del sistema di gestione degli archivi, del sistema dei pagamenti,
dellamministrazione 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

.1 Documentazione del contratto
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 dellapprovvigionamento (paragrafo 12.1.3.1). Le modifiche richieste
vengono elaborate ai fini dellanalisi e dellapprovazione mediante il processo di
Le modifiche richieste possono comprendere indicazioni fornite dallacquirente
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 dellaltra parte, occorre
identificarle e documentarle in modo univoco nella corrispondenza del progetto.
Unazione correttiva consigliata unoperazione 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 dallacquirente 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.
294

Documentazione sulla valutazione delle prestazioni del fornitore: questa

documentazione viene preparata dallacquirente. Le valutazioni sulle prestazioni
documentano labilit del fornitore nel proseguire il lavoro previsto dallattuale
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 dellapprovvigionamento: il piano di gestione
dellapprovvigionamento (paragrafo 12.1.3.1) viene aggiornato per rispecchiare
le eventuali richieste di modifica approvate che riguardano la gestione
dellapprovvigionamento.
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 lamministrazione 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
laggiornamento 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
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 uninadempienza 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, lacquirente potrebbe avere il diritto di terminare lintero
contratto o una parte del progetto, per motivi di convenienza, in qualsiasi momento.
Ciononostante, sempre in funzione di quanto stabilito nel contratto, lacquirente
potrebbe dover risarcire il fornitore per eventuali attivit di preparazione e per il
lavoro completato e accettato relativo alla parte conclusa del contratto.
12

295
Figura 12-8. Chiusura del contratto: Input, Strumenti e tecniche e Output
12.6.1 Chiusura del contratto: Input

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

.1 Revisioni dellapprovvigionamento
Una revisione dellapprovvigionamento unanalisi strutturata del processo di
approvvigionamento a partire dal processo Pianificare gli acquisti (paragrafo 12.1)
fino allAmministrazione del contratto (paragrafo 12.5). Lobiettivo della revisione
dellapprovvigionamento identificare i successi e le carenze il cui riconoscimento
pu essere utile nella preparazione o nellamministrazione degli altri contratti di
approvvigionamento del progetto o di altri progetti, allinterno della Performing
Organization.
.2 Sistema di gestione degli archivi
296

12.6.3 Chiusura del contratto: Output

.1 Contratti chiusi
Lacquirente, 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: linsieme 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: lacquirente, in genere attraverso il proprio
amministratore di contratto autorizzato, invia al fornitore una formale notifica
scritta dellaccettazione 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: lanalisi delle lesson learned e i
suggerimenti per il miglioramento dei processi si sviluppano per la
pianificazione e limplementazione di acquisti futuri.
12

297
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
Sezione I
Elementi generali della gestione

di progetti
Capitoli 1, 2 e 3
Sezione II
Sezioni della Terza edizione

Sezione I
Il contesto del Project

Management
Capitoli 1 e 2
Sezione II -
Le aree di conoscenza della

gestione di progetti
Capitoli da 4 a 12
Sezione III
- Allegati
Appendice D - Note
Appendice E - Estensioni relative alle aree di
applicazione
Sezione IV - Glossario e indice analitico
Lo standard per il Project

Management di un progetto
Capitolo 3 - Processi di Project Management
per un progetto
Sezione III - Aree di conoscenza di Project
Management
Capitoli da 4 a 12
Sezione IV - Appendici
Appendice D - Estensioni delle aree applicative
Sezione V -
Riferimenti, glossario e indice
Tabella 1: modifiche strutturali

301
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.
302

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

303
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 Sviluppo del piano di progetto

4.2 Esecuzione del piano di progetto
4.3 Controllo integrato delle modifiche

4.1 Sviluppare il Project Charter
4.2 Sviluppare la descrizione preliminare
dell'ambito del progetto
4.3 Sviluppo del piano di Project Management
4.4 Dirigere e gestire l'esecuzione del progetto
4.5 Monitorare e controllare il lavoro del
progetto
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
5.2 Pianificazione del contenuto
5.3 Definizione del contenuto
5.4 Verifica del contenuto
5.5 Controllo delle modifiche di contenuto

Riscritta e spostata al capitolo 4
5.1 Pianificazione dell'ambito
5.2 Descrizione delle specifiche
5.3 Creare la WBS
5.4 Verifica dell'ambito
5.5 Controllo dell'ambito
304

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). Unaltra 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.2 Ordine di esecuzione delle attivit
6.3 Stima della durata delle attivit
6.4 Sviluppo della schedulazione
6.5 Controllo della schedulazione

6.1 Definizione delle attivit
6.2 Sequenzializzazione delle attivit
6.3 Stima delle risorse delle attivit
6.4 Stima della durata delle attivit
6.5 Sviluppo 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
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
7.2 Stima dei costi
7.3 Allocazione dei costi
7.4 Controllo dei costi

Spostato a Gestione dei tempi di progetto
(capitolo 6)
7.1 Stima dei costi
7.2 Allocazione dei costi
7.3 Controllo dei costi

305
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.2 Assicurazione Qualit
8.3 Controllo Qualit

8.1 Pianificazione della qualit
8.2 Effettuare l'assicurazione 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.2 Acquisizione del personale
9.3 Sviluppo del gruppo di progetto

9.1 Pianificazione delle risorse umane
9.2 Acquisire il 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.3 Rendicontazione dei risultati
10.4 Chiusura amministrativa
10.1 Pianificazione della comunicazione

10.3 Reporting delle prestazioni
10.4 Gestire gli stakeholder
306

Modifiche al Capitolo 11: Gestione dei rischi di progetto

Il capitolo 11 stato aggiornato per aumentare lenfasi 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 lintegrazione con
gli altri processi. Nella seguente tabella sono riassunte le modifiche apportate al
capitolo 11:
11.1 Pianificazione della gestione del rischio
11.2 Identificazione del rischio
11.3 Analisi qualitativa del rischio
11.4 Analisi quantitativa del rischio
11.5 Pianificazione della risposta al rischio
11.6 Monitoraggio e controllo del rischio

11.1 Pianificazione della gestione dei rischi
11.2 Identificare i rischi
11.3 Analisi qualitativa del rischio
11.4 Analisi quantitativa del rischio
11.5 Pianificazione della risposta ai rischi
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 allinterno
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:
12.1 Pianificazione dellapprovvigionamento
12.2 Pianificazione dell'invito
12.3 Invito
12.4 Selezione dei fornitori
12.6 Chiusura di contratto
12.1 Pianificare gli acquisti

12.2 Pianificare le forniture
12.3 Richiesta di risposte dai fornitori
12.4 Selezionare i fornitori
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.

307
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 nelledizione 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 alledizione 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.
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. LESA Management Group era composto
dai seguenti membri:
Matthew H. Parry, Chair
David Haeney
William H. Robinson
Eric W. Smythe
David C. Aird
Harvey Kolodney
Douglas J. Ronson
Frederick R. Fisher
Charles E. Oliver
Paul Sims

309
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 dallESA Management Group. John Adams e il suo gruppo della Western
Carolina University si occuparono della questione dellaccreditamento, 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
(durante lo sviluppo)
Joseph R. Beck
Richard Cockfield
Peter C. Georgas
Colin Morris
Pat Patrick
George Vallance
John R. Adams, Chair

(alla pubblicazione)
Peter Bibbes
Peggy Day
Shirl Holingsworth
Joe Muhlberger
David Pym
Larry C. Woolslager
Jim Blethen
William Dixon
William Kane
Philip Nunn
Linn C. Stuckenbruck
Shakir Zuberi
310

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

311
2.
3.
4.
5.
6.
7.
8.
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.
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.
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.
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.
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.
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.
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:
312

9.
10.
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.
Sono state aggiunte delle illustrazioni. Quando si parla di WBS, di reticoli e di
curve a S, unimmagine vale pi di mille parole.
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

0. PMBOK Standards
1. Framework: The Rationale

2. Framework: An Overview
3. Framework: An Integrative Model

4.
A.
B.
C.
D.
E.
F.
Glossary of General Terms

Scope Management
Quality Management
Time Management
Cost Management
Risk Management
Human Resource Management
G. Contract/Procurement Management
H. Communications Management
11.
Numero e nome del 1996

B. Evolution of PMIs A Guide to the
Project Management Body of
Knowledge
1. Introduction (definizioni di base)
2. The Project Context (cicli di vita)
1. Varie parti
2. Varie parti
3. Varie parti
3. Project Management Processes
4. Project Integration Management
IV. Glossary
5. Project Scope Management
8. Project Quality Management
6. Project Time Management
7. Project Cost Management
11. Project Risk Management
9. Project Human Resource
Management
12. Project Procurement Management
10. Project Communications
Management
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 unarea di conoscenza o in pi processi, per cui le categorie non sono
uniche.

313
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
Mark Burgess
Drew Fetters
Eric Jenett
Anthony Rizzotto
Frederick Ayer
Helen Cooke
Brian Fletcher
Deborah OBray
Alan Stretton
Cynthia Berg
Judy Doll
Earl Glenwright
Diane Quinn
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)
Louis J. Cabano (capitolo 5)
Douglas Gordon (capitolo 7)
Edward Ionata (capitolo 10)
Hadley Reynolds (capitolo 2)
W. Stephen Sawle (capitolo 5)
Ahmet Taspinar (capitolo 6)
Keely Brunner (capitolo 7)

David Curling (capitolo 12)
David T. Hulett (capitolo 11)
John M. Nevison (capitolo 9)
Agnes Salvo (capitolo 11)
Leonard Stolba (capitolo 8)
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
Tom Belanger
Paul Bosakowski
Samuel K. Collier
Darlene Crane
John J. Downing
Quentin W. Fleming
Leo Giulianeti
G. Alan Hellawell
Mark E. Hodson
Murray Janzen
William F. Kerrigan
Richard King
Richard E. Little
Christopher Madigan
C. Fred Baker
John A. Bing
Dorothy J. Burton
Karen Condos-Alfonsi
Russ Darnall
Daniel D. Dudek
Rick Fletcher
Martha D. Hammonds
Paul Hinkley
Lew Ireland
Frank Jenes
Harold Kerzner
J. D. Kaay Koch
Lyle W. Lockwood
Michael L. McCauley
F. J. Bud Baker
Brian Bock
Kim Colenso
E. J. Coyle
Maureen Dougherty
Lawrence East
Greg Githens
Abdulrazak Hajibrahim
Wayne L. Hinthorn
Elvin Isgrig
Walter Karpowski
Robert L. Kimmons
Lauri Koskela
Lawrence Mack
Hugh McLaughlin
314

Frank McNeely
Raymond Miller
R. Bruce Morris
John P. Nolan
JoAnn C. Osmer
John G. Phippen
PMI Houston Chapter
Charles J. Pospisil
Christopher Quaife
William S. Ruggles
Darryl M. Selleck
Craig T. Stone
Dick Thiel
Janet Toepfer
Jack Way
Hugh M. Woodward
Dirk Zwart
Pierre Menard
Alan Minson
David J. Mueller
Louise C. Novakowski
Jon V. Palmquist
Hans E. Picard
PMI Manitoba Chapter
Janice Y. Preston
Peter E. Quinn
Ralph B. Sackman
Melvin Silverman
Hiroshi Tanaka
Saul Thomashow
Vijay K. Verma
R. Max Wideman
Robert Youker
Rick Michaels
Colin Morris
Gary Nelson
James OBrien
Matthew Parry
Serge Y. Piotte
PMI New Zealand Chapter
Mark T. Price
Steven F. Ritter
Alice Sapienza
Roy Smith
Robert Templeton
J. Tidhar
Alex Walton
Rebecca Winston
Shakir H. Zuberi
Personale addetto alla produzione

doveroso rivolgere una menzione speciale ai seguenti dipendenti del settore PMI
Communications.
Jeannette M. Cabanis, Editor, Book Division
Linda V. Gillman, Office Administrator
Jonathan Hicks, Systems Administrator
Dewey L. Messer, Managing Editor
Mark S. Parker, Production Coordinator
Melissa Pendergast, Information Services
Coordinator
Michelle Triggs, Graphic Designer
Misty N. Dillard, Administrative Assistant

Bobby R. Hensley, Publications Coordinator
Sandy Jenkins, Associate Editor
Danell Moses, Marketing Promotion Coordinator
Shirley B. Parker, Business/Marketing Manager
James S. Pennypacker, Publisher/Editor-In-Chief
Lisa Woodring, Administrative Assistant

315
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
ledizione 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.
316

12.
Sono stati aggiunti numerosi strumenti e tecniche.

Capitolo 4: Gestione
dellintegrazione di progetto
Metodo dell'Earned Value (EVM)

Azione preventiva
Aggiornamenti dellenunciazione
del contenuto
Piano di progetto
Linea di base corretta
Durate su base quantitativa
Tempo di riserva (Contingency)
Struttura di codifica
Analisi degli scostamenti
Milestone
Strumenti informatici
Stime pubblicate
Metodo del valore assorbito (EVM)
Costo della qualit
Capitolo 5: Gestione del contenuto

di progetto
Capitolo 6: Gestione dei tempi di

progetto
Capitolo 7: Gestione dei costi di

progetto
Capitolo 8: Gestione della qualit
di progetto
Capitolo 10: Gestione delle
comunicazioni di progetto
Rapporti 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
Judith A. Doll, PMP
Cynthia A. Berg, PMP

J. Brian Hobbs, PMP
Sergio Coronado Arrechedera

David Hotchkiss, PMP
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:
Quentin Fleming
David T. Hulett, PhD
Judith A. Doll, PMP

Greg Githens, PMP
Gregory J. Skulmoski
Daniel Dudek, PMP

Earl Glenwright

317
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 Cao (capitolo 11)
Roger Graves (capitolo 11)
David Hulett (capitolo 11)
Janice Preston (capitolo 11)
David Shuster (capitolo 8)
Mike Wakshull (capitolo 11)
Quentin Fleming (capitoli 4 e 12)

David Hillson (capitolo 11)
Sam Lane (capitolo 11)
Stephen Reed (capitolo 11)
Ed Smith (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.
Frank Allen, PMP
MaryGrace Allenchey, PMP
Ichizo Aoki
Ronald Auffrdou, PMP
Frederick L. Ayer, PMP
A. C. Fred Baker, PMP
Berndt Bellman
Nigel Blampied, PE, PMP
Patrick Brown, PMP
Bruce C. Chadbourne, PMP
Raymond C. Clark, PE
David Coates, PMP
Edmund H. Conrow, PMP
John Cornman, PMP
Kevin Daly, PMP
Thomas Diethelm, PMP
Frank D. Einhorn, PMP
Christian Frankenberg, PMP
Jean-Luc Frere, PMP
Chikako Futamura, PMP
Brian L. Garrison, PMP
Peter Bryan Goldsbury
Yassir Afaneh
Jon D. Allen, PMP
Robert A. Andrejko, PMP
Paul C. Aspinwall
Edward Averill, PMP
William W. Bahnmaier, PMP
Carole J. Bass, PMP
Sally Bernstein, PMP
John Blatta
Chris Cartwright, PMP
Michael T. Clark, PMP
Elizabeth Clarke
Kim Colenso, PMP
Kenneth G. Cooper
Richard F. Cowan, PMP
Mario Damiani, PMP
David M. Drevinsky, PMP
Edward Fern, PMP
Scott D. Freauf, PMP
Ichiro Fujita, PMP
Serge Garon, PEng, PMP
Eric Glover
Michael Goodman, PMP
318

Jean Gouix, PMP

Franz X. Hake
Chris Herbert, PMP
J. Brian Hobbs, PMP
Robin Hornby
Charles L. Hunt
George Jackelen
Elden F. Jones II, PMP, CMII
Lewis Kana, PMP
Ronald L. Kempf, PMP
Kurt V. Kloecker
Blase Kwok, PMP
Philip A. Lindeman
Lyle W. Lockwood, PMP
Arif Mahmood, PMP
Stephen S. Mattingly
Peter McCarthy
Krik D. McManus
Mary F. Miekoski, PMP
Gordon R. Miller, PMP
Jim Morris, PMP
William A. Moylan, PMP
Wolfgang Obermeier
Masato Ohori, PMP
Edward Oliver
Francisco Perez-Polo, PMP
Crispin (Kik) Piney, PMP
David L. Prater, PMP
Samuel L. Raisch, PMP
G. Ramachandran, PMP
Bernice L. Rocque, PMP
Fernando Romero Peailillo
Linda Rust, PMP
James N. Salapatas, PMP
Bradford N. Scales
John R. Schuyler, PMP
Shoukat Sheikh, MBA, PMP
Larry Sieck
Melvin Silverman, PhD, PE
Keith Skilling, PE, PMP
Kenneth F. Smith, PMP
Paul J. Solomon
Christopher Wessley Sours, PMP
Joyce Statz, PMP
Thangavel Subbu
Ahmet N. Taspinar, PMP
Alan D. Uren, PMP
S. Rao Vallabhaneni
Ana Isabel Vazquez Urbina
Stephen E. Wall, PMP
Tammo T. Wilkens, PE, PMP
Alexander Grassi Sr., PMP

Peter Heffron
Dr. David Hillson, PMP, FAPM
Marion Diane Holbrook
Bill Hubbard
Thomas P. Hurley, PMP
Angyan P. Jagathnarayanan
Sada Joshi, PMP
Subramaniam Kandaswamy, PhD, PMP
Robert Dohn Kissinger, PhD, PMP
Jan Kristrom
Lawrence P. Leach
Gbor Lipi
J. W. Lowthian, PMP
James Martin (a nome di INCOSE)
Glen Maxfield
Rob McCormack, PMP
David Michaud
Oscar A. Mignone
Roy E. Morgan, PMP
Bert Mosterd, PMP
John D. Nelson, PMP
Cathy Oest, PMP
Kazuhiko Okubo, PE, PMP
Jerry Partridge, PMP
James M. Phillips, PMP
George Pitagorsky, PMP
Bradford S. Price, PMP
Naga Rajan
Bill Righter, PMP
Wolfgang Theodore Roesch
Jon Rude
Fabian Sagristani, PMP
Seymour Samuels
H. Peter Schiller
Maria Scott, PMP
Kazuo Shimizu, PMP
(a nome di PMI Tokyo, Japan Chapter)
Loren J. Simer Jr.

Greg Skulmoski
Barry Smythe, PMP
Joe Soto Sr., PMP
Charlene Spoede, PMP
Emmett Stine, PMP
Jim Szpakowski
John A. Thoren Jr., PMP
Juan Luis Valero, PMP
William Simon Vaughan Robinson
Ricardo Viana Vargas, PMP
William W. Wassel, PMP
Robert Williford, PMP

319
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
Alan Stretton
William R. Duncan
R. Max Wideman
Matthew H. Parry
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
320

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

321
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 OBrien, 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 SubTeam Leader, le seguenti persone hanno contribuito fornendo input o concetti
sostanziali:
Sumner Alpert, PMP, CMC
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
322

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.
Adrian Abramovici, PMP
Mark Allyn, PMP
Lionel Andrew, MBA, ISP
Prabu V. Ayyagari, PhD, PMP
Pamela M. Baker, PMP
James S. Bennett, PMP
Howland Blackiston
Charles W. Bosler, Jr.
Carolyn Boyles, MBA, PMP
Alex S. Brown, PMP
Stephen C. Burgan, PMP
Dean J. Calabrese, PMP
Giuseppe A. Caruso, PMP
Clare Chan
Gene Chiappetta, PMP
Mark T. Chism, PMP
Robert L. Cutler, PMP
Mario Damiani, PMP
Robert de Jong, PMP
John M. Dery, PMP
Jerry Dimos, PMP
Capt. Nick Doralp, PMP
Peter Duignan, PMP
Suhas Dutta, PMP
Gary S. Elliott, M.S., M.D.
Morten Fangel, PhD
Eve Featherman
Flynn M. Fernandes, PMP, MSPM
David Foley, MBA
Gary W. Fortune, PMP
Ichiro Fujita, PMP
Donald G. Gardner, PMP
Jose A. George, Btech, PGDM
Leo A.Giulianetti, PMP
Donna Golden
Dr. Margarida Goncalves
Neal S. Gray, PMP
Patrick D. Guest, PMP
Navneet Gupta, PMP
J. Ray Harwood, PMP
Ralph Hernandez
Bobby Tsan Fai Ho, PMP, CISM
Keith D. Hornbacher, MBA
Clinton int Veld
Don R. James, PMP
Wei Jing
Muhamed Abdomerovic, PMP

Jamie K. Allen, PMP
Scott C. Anderson, PMP
Russell Archibald, PMP
Ernest Baker, PMP
Kevin E. Bast, PMP
Ionut C. Bibac
Ray Blake, PMP
Rollin O. Bowen, Jr.
Wayne R. Brantley, PMP, MS Ed
Timothy S. Brown
Anne Cagle, PMP
Neil R. Caldwell
Bill Chadick, PMP
Porfirio Chen Chang, MBA, PMP
Tomio Chiba, PMP
Andy Crowe, PMP
Darren Dalcher, PhD, MAPM
Pranab Das, PMP
Connie Delisle
Barbara De Vries, PMP
James A. Doanes
Magnus Karl Drengwitz, PMP
Lloyd R. Duke, Jr., PMP
Bradford R. Eichhorn, PMP
Gregory William Fabian, PMP
Martin Christopher Fears, PMP
AnnaMaria Felici
John C. Buck Field, MBA, PMP
Kirby Fortenberry, PMP
John M. Foster, PMP, MBA
Denis Freeland
John S. Galliano
Stainslaw Gasik
Dan Georgopulos
Christopher A. Goetz, PMP
Neil P. Goldman, PMP
John C. Goodpasture, PMP
Robert J. Gries, PE, PMP
Jinendra Gunathilaka, PE
Aaron S. Hall, PMP
Ali Hassan, PMP
Pat Hillcoat, PMP
Gopi V. Hombal
Kenneth Alan Hudacsko, PMP
Adesh Jain, PMP, MPD
Noel C. Jensen, PMP
Bruce Johnson, PMP

323
Granville H. Jones, Sr., MBA, PMP

Tom Kerr, PMP
Asadullah Khan, PMP
Mihail Kitanovski
Takahiko Kuki, PMP, PE
Avis Kunz
John S. Layman, PMP
Elizabeth Ann Long, PMP
Pier Paolo Lo Valvo, PMP
Sajith K. Madapatu, PMP
Enrique Martinez
David L. McPeters, PMP
Godfrey I. Meertens, PMP
Gordon R. Miller, PMP, CCP
Andrew H. Moore, MBA, PMP
Mhlabaniseni Moses Mitmunye
K.S. Keshava Murthy
AnathaKrishnan S. Nallepally, PMP
Vijayalakshimi Neela, MCA, PMP
Brian D. Nelson, PMP
Jeffery L. Ottesen, PE
Laura Dorival Paglione
Jerry L. Partridge, PMP
Eric Patel
Manohar Powar, PMP
Ge Qun
Prem Ranganath, PMP
Ulka Rathi
Vijay Sai Reddy, PMP, CSQA
Steven Ricks, PMP
Dee Rizor
Michael C. Roach
Cheryl N. Rogers, PMP
Ed Rosenstein, PMP
Joseph A. Roushdi
Paul S. Royer, PMP
Frank Ryle, PMP
Srinivasa R. Sajja, PMP
Markus Scheibel, PMP, Dipl.-Ing.
Amy Schneider, PMP
Andrea R. Scott
Tufan Sevim, PMP
Mundaje S. Shetty, PMP
Rali Shital
Larry Sieck
Richard L. Sinatra, PMP, PhD
Edward Smith
Richard Spector, PMP
Donglin Su
Karen Z. Sullivan, PMP
David E. Taylor, PMP
Sai K. Thallam, MBA, PMP
Massimo Torre, PhD, PMP
Kevin B. Jones, BMath, PMP

Ajmal Afzal Khan
Lucy Kim, PMP, PE
Jennifer Eileen Kraft
Polisetty V.S. Kumar, Mtech, PMP
Antonio Carlos Laranjo da Silva
Erik D. Lindquist, PMP, PE
Raul S. Lopez, PE, PMP
Karen Griffin MacNeil, PMP
Vijaya Kumar Mani, PMP
Victor J. Matheron, PMP
Ed Mechler, PMP
Richard Meertens, MBA, PMP
Liu Min
Colin Morris, PE, PMP
Charles L. Munch, PMP
Jo Musto, PMP
NB Narayanan
Beatrice Nelson, PMP
Isabella Nizza, PMP
David M. Olson, MBA (ITM)
Michael T. Ozeranic
Glen R. Palmer
George Pasieka, PMP
Sreenivasa Rao Potti, MCA, PMP
Patrick J. Quairoli
Vara Prasad Raju Kunada
Raju Rao, PMP
Tony Raymond
J. Logan C. Rice
Thad B. Ring, PMP
Susan Rizzi
Alexandre G. Rodrigues, PhD
Scott A. Rose, PMP
Samuel S. Roth, PMP
Gurdev Roy, PMP
James J. Rutushni, PMP
Anjali Sabharwal, PMP
Nashaat A. Salman, PMP
John Schmitt, PMP
Randa Schollmeyer, PMP
Benjamin R. Sellers, PMP, CPCM
Sanjay Shah, PMP
Kazuo Shimizu, PMP
Ganga Siebertz
Melvin Silverman, PhD, PE
Raghavendra Singh
Patricia Smith
Allison St. Jean
Sambasivam S., PMP, CSQA
Karen Tate, PMP, MBA
James E. Teer, Jr.
Surendra Tipparaju, ME
Rogerio Carlos Traballi
324

Rufis A. Turpin, CQA, CSQE

M. Raj Ullagaraj, PhD
JR Vanden Eynde, PMP
Thomas G. Van Scoyoc, PMP
Ricardo Viana Vargas, MSc, PMP
Craig Veteto, PMP, CPIM
Eduardo Newton Vieira, PMP
Cornelius (Kees) Vonk, PMP
Thomas M. Walsh, PMP
Kevin R. Wegryn, PMP, CPM
Gwen Whitman, PMP
Alan K. Williams, Sr., PMP
Stephen D. Wise
Thomas Wuttke, PMP, CPM
Angela F. Young, PMP
Eire E. Zimmermann, PMP
C.6
Marion J. Tyler, PMP

Eric Uyttewaal, PMP
Gerrit van Otterdijk, BSc. Mgt Science
Paula X. Varas, PMP
Mark M. Vertin, PE, PMP
Roberto Viale, PMP
Desmond Joseph Vize, PMP
J. Wendell Wagner, PMP
Patrick Weaver, PMP, FAICD
Timothy E. Welker, PMP
Tammo T. Wilkens, PE, PMP
Charles M. Williamson, MBA, PMP
Robert Wood
Uma S. Yalamanchili, PMP
Kathy Zandbergen
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
Mohammed Abdulla Al-Kuwari, Eur Ing,
Ceng
Frank Angari
Alfred Baker
Jefferson Bastreghi
Mamoun A. Besaiso, CE
Nigel Blampied, PE, PMP
Stephen Bonk
David Bradford, PMP
Gary D. Brawley, P.Eng., PMP
Bruce Chadbourne
Aaron Coffman, PMP, CQM
Edmund H. Conrow, PhD, PMP
Michael Corish
John Cornman, PMP, MBA
Mario Damiani
Allan E. Dean
Juan De La Cruz
Ravi Kumar Dikshit, PMP
Daniel Dudek
Robert L. Emerson, PMP
Keith Farndale, PEng, PMP
Quentin W. Fleming
Ichiro Fujita, PMP
Jackelen George
David R. Haas, PMP, FLMI
Delbert K. Hardy, PMP
Bob Hillier, PMP
Danny N. Hinton, PMP
J. Brian Hobbs, PhD, PMP
Martin Hopkinson, BSc, APMP
Grant Jefferson
Yassir Afaneh
Hussain Ali Al-Ansari, Eur Ing, CEng
William W. Bahnmaier, PMP
B. D. Barnes
Mohammed Safi Batley, MIM
Sally Bernstein, PMP
J. David Blaine, PMP, CSQE
Dennis Bolles, PMP
Gregory M. Bowen, CSDP
James (Jim) P. Branden, MBA, PMP
Edgard P. Cerqueira Neto, PhD, PMP
Tomio Chiba, PMP
Kim D. Colenso, PMP, CSQE
Helen S. Cooke, PMP
John E. Cormier, PMP
Aloysio da Silva
Arindam Das
Alfredo del Cano, PE, PhD
M. Pilar De La Cruz
John Downing
Judith Edwards, PhD, PMP
Alison Evanish
Linda Fitzgerald
Paul H. Gil, MCP, PMP
Mike Griffiths, PMP
Robert W. Harding, RA
Rick Hiett
Guy N. Hindley, MAPM, MILT
Ho Lee Cheong, PhD, MIMech E
Piet Holbrouck, MSc
Darrel G. Hubbard, PE
Howard J. Kalinsky, PMP, MPM

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

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 ManagerTranslations
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

327
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 dellambiente 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.
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.

329
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.
330

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 unaltra 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
emesse dal PMI e sono soggette ad un accordo tra le organizzazioni. In assenza
di unorganizzazione sponsor, il PMI Standards Program pu decidere di
proseguire in modo autonomo.
Per tutto il processo di sviluppo e gestione dellestensione, 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.

331
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 limpegno 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.
332

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

333
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
334

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; lobiettivo 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
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.

335
APPENDICE F
Riepilogo delle aree di conoscenza del
Project Management
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
lautorizzazione 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
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 allinsieme dei
gruppi di processi di Project Management che consente di chiudere formalmente
il progetto stesso.

337
Appendice F Riepilogo delle aree di conoscenza del Project Management

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

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

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 unapprossimazione 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.
338


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.

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 lavanzare 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
gruppo, comunicazione dei riscontri, risoluzione delle questioni e
coordinamento delle modifiche volto a migliorare le prestazioni del progetto.

339
Appendice F Riepilogo delle aree di conoscenza del Project Management

La gestione delle comunicazioni di progetto comprende i processi necessari a
garantire, tempestivamente e appropriatamente, la generazione, la raccolta, la
distribuzione, larchiviazione, il recupero e la disposizione finale delle informazioni
del progetto. I processi di gestione della comunicazione di progetto forniscono i
collegamenti critici tra persone e informazioni, necessari per il successo della
comunicazione. I project manager possono dedicare una quantit di tempo eccessiva
per comunicare con il gruppo di progetto, gli stakeholder, il cliente e lo sponsor.
Chiunque sia coinvolto nel progetto dovrebbe comprendere come le comunicazioni
incidano sul progetto nel suo complesso. 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 sullavanzamento, 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.

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
unulteriore 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.
340

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 unorganizzazione 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
lacquirente 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.

341
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 dellintegrazione di progetto

4
yign, M. Gven. 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


345
Riferimenti bibliografici
Capitolo 8. Gestione della qualit di progetto

6
American Society for Quality, 2000.

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

346

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
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
dellintegrazione di progetto e alla gestione dellapprovvigionamento 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

347
Glossario
2.
ACRONIMI COMUNI
AC
ACWP
AD
ADM
AE
AF
AOA
AON
AS
BAC
BCWP
BCWS
BOM
CA
CAP
CCB
COQ
CPF
CPFF
CPI
CPIF
CPM
CPPC
CV
CWBS
DD
DU
DUR
EAC
EF
EMV
ES
ETC
EV
EVM
EVT
FF
FF
FFP
FMEA
FPIF
FS
IFB
LF
Actual Cost / Costo effettivo

Actual Cost of Work Performed / Costo effettivo del lavoro eseguito
Activity Description / Descrizione dellattivit
Arrow Diagramming Method / Metodo del diagramma a frecce
Apportioned Effort / Impegno distribuito
Actual Finish Date / Data di fine effettiva
Activity-On-Arrow / Attivit su freccia
Activity-On-Node / Attivit su nodo
Actual Start Date / Data dinizio effettiva
Budget At Completion / Budget al completamento
Budgeted Cost of Work Performed / Costo preventivato del lavoro
eseguito
Budgeted Cots of Work Scheduled / Costo preventivato del lavoro
programmato
Bill Of Materials / Distinta base
Control Account / Punto di controllo
Control Account Plan / Piano dei punti di controllo
Change Control Board / Comitato gestione modifiche
Cost of Quality / Costo della qualit
Cost-Plus-Fee / Contratto a rimborso spese pi quota variabile
Cost Plus Fixed Fee / Contratto a rimborso spese pi quota fissa
Cost Performance Index / Indice di efficienza dei costi
Cost Plus Incentive Fee / Contratto a rimborso spese pi incentivo
Critical Path Method / Metodo del percorso critico
Cost-Plus-Percentage of Cost / Contratto a rimborso spese pi
percentuale sui costi
Cost Variance / Scostamento dei costi
Contract Work Breakdown Structure / WBS del contratto
Data Date / Data di aggiornamento
Duration / Durata
Duration / Durata
Estimate At Completion / Stima al completamento
Early Finish Date / Data di fine minima
Expected Monetary Value / Valore monetario atteso
Early Start Date / Data di inizio minima
Estimate to Complete / Stima a finire
Earned Value / Earned Value
Earned Value Management / Metodo dell'Earned Value
Earned Value Technique / Tecnica dell'Earned Value
Finish-to-Finish / Fine-fine
Free Float / Free Float
Firm Fixed Price / Contratto a prezzo fisso
Failure Mode and Effect Analysis / Failure Mode and Effect Analysis
Fixed Price Incentive Fee / Contratto a prezzo prefissato con incentivo
Finish-To-Start / Fine-inizio
Invitation For Bid / Bando di gara
Late Finish Date / Data di fine massima
348
Una Guida al Project Management Body of Knowledge (Guida al PMBOK ) Terza edizione
LOE
LS
OBS
OD
PC
PCT
PDM
PF
PM
PM
PMBOK
PMIS
PMO
PMO
PMP
PS
PSWBS
PV
QA
QC
RAM
RBS
RBS
RD
RFP
RFQ
SF
SF
SOW
SPI
SS
SS
SV
SWOT
TC
TF
TF
T&M
TQM
TS
VE
WBS
Level Of Effort / Livello di impegno

Late Start Date / Data di inizio massima
Organizational Breakdown Structure / Struttura di scomposizione
dell'organizzazione
Original Duration / Durata originale
Percent Complete / Percentuale di completamento
Percent Complete / Percentuale di completamento
Precedence Diagramming Method / Metodo del diagramma di
precedenza
Planned Finish Date / Data di fine pianificata
Project Management / Project Management
Project Manager / Project manager
Project Management Body of Knowledge / Project Management Body of
Knowledge
Project Management Information System / Sistema informativo di Project
Management
Program Management Office / Program Management Office
Project Management Office / Project Management Office
Project Management Professional / Project Management Professional
Planned Start Date / Data dinizio pianificata
Project Summary Work Breakdown Structure / WBS di riepilogo del
progetto
Planned Value / Valore pianificato
Quality Assurance / Assicurazione qualit
Quality Control / Controllo qualit
Responsibility Assignment Matrix / Matrice assegnazione responsabilit
Resource Breakdown Structure / Struttura di scomposizione delle risorse
Risk Breakdown Structure / Struttura di scomposizione dei rischi
Remaining Duration / Durata residua
Request For Proposal / Richiesta d'offerta
Request For Quotation / Richiesta di preventivo
Scheduled Finish date / Data di fine pianificata
Start-to-Finish / Inizio-fine
Statement Of Work / Capitolato
Schedule Performance Index / Indice di efficienza della schedulazione
Scheduled Start date / Data di inizio schedulata
Start-to-Start / Inizio-inizio
Schedule Variance / Scostamento dei tempi
Strengths, Weaknesses, Opportunities, and Threats / Punti di forza,
debolezze, opportunit e minacce
Target Completion Date / Data obiettivo di completamento
Target Finish date / Data obiettivo di fine
Total Float / Total Float
Time and Material / Time and Material
Total Quality Management / Gestione qualit totale
Target Start Date / Data obiettivo di inizio
Value Engineering / Ingegneria del valore
Work Breakdown Structure / WBS (Struttura di scomposizione del
lavoro)
Glossario

349
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).
350
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 unaltra 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
dellalbero 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 dellalbero delle decisioni / Decision Tree Analysis [tecnica]. Lalbero delle decisioni un
diagramma che descrive una decisione in esame e le implicazioni della scelta delle varie alternative
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

351
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 dellimpatto, 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 dellelaborazione
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.
352
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 luso 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
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

353
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.
354
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 dellorganizzazione 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
dellorganizzazione. 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.
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

355
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 lacquirente 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 lacquirente 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-PlusPercentage 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
356
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 dellaccordo non stato
definito al momento dellaggiudicazione. 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
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

357
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 allinizio 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
dellanalisi 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 dinizio / 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 dinizio attuale / Current Start Date. Stima attuale del momento cui un'attivit schedulata verr
avviata e che riflette l'avanzamento del lavoro. Vedere anche data dinizio schedulata e data di
inizio di baseline.
Data dinizio effettiva (AS) / Actual Start Date (AS). Il momento in cui ha effettivamente avuto
inizio il lavoro previsto per un'attivit schedulata.
Data dinizio pianificata (PS) / Planned Start Date (PS). Vedere data dinizio schedulata.
Data dinizio schedulata (SS) / Scheduled Start Date (SS). Il momento in cui previsto che inizi il
lavoro di un'attivit schedulata. La data dinizio schedulata rientra generalmente nellambito 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 leffettivo 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
358
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, lattivit 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 unattivit 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 lavanzamento 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 nellintervallo 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 unattivit 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
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 lavanzamento 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 lanalisi 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

359
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
dellattivit 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 dinfluenza / Influence Diagram [strumento]. Rappresentazione grafica delle situazioni
che mostra le influenze casuali, lordine 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.
360
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
dinizio 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).
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

361
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 dellattivit, 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
362
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 sullandamento
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 unattivit 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 dellapprovvigionamento di progetto / Project Procurement Management [area di
conoscenza]. Vedere appendice F.
Gestione dellintegrazione di progetto / Project Integration Management [area di conoscenza].
Vedere appendice F.
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 lattuazione di un programma di miglioramento della qualit
nellambito di unorganizzazione.
Glossario

363
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 allimpegno 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
364
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, lattivit successore
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 unaccelerazione dell'attivit
successore. Ad esempio, in una relazione di dipendenza fine-inizio con un lead di 10 giorni,
lattivit 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
desecuzione 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

365
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 dinizio e di fine) sono determinate
dallandamento 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. Linsieme 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 limpatto 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
366
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 dinizio
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 allinterno del progetto. I valori di misurazione ottenuti fanno parte delle
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

367
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 lassegnazione 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 unattivit 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
368
caratterizzata da un vincolo di schedulazione dovuto a una data imposta del tipo non-pi-tardidi. 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
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

369
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 dellapprovvigionamento / 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.
370
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
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

371
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). Lapplicazione 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 linsieme delle conoscenze relative alla
professione del Project Management. Come avviene in altre professioni (ad esempio, in
giurisprudenza, medicina e ragioneria), linsieme delle conoscenze appannaggio dei
professionisti e degli accademici che le praticano e le sviluppano. Il Project Management Body of
Knowledge 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.
372
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. Nelluso 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 dallesterno o dallinterno e possono essere
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

373
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 dellattuazione di una
risposta al rischio.
Rischio residuo / Residual Risk. Rischio che rimane dopo lattuazione 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 dinizio 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.
374
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.
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

375
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.
376
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 laccuratezza 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.
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

377
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 nellottica 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.
378
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.
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

379
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 dellevento di rischio.
380
INDICE
A
AC Vedere costo effettivo (AC)
accantonamento per contingency Vedere riserva
accettare i rischi, 372
accettare, 350
accettazione, 102, 185, 263, 350
acquirente, 271, 282, 293, 353
acquisire il gruppo di progetto, 10, 57, 199, 209,
210, 212, 350
ACWP Vedere costo effettivo del lavoro eseguito
(ACWP)
AD Vedere descrizione dell'attivit (AD)
ADM Vedere metodo del diagramma a frecce
(ADM),
AE Vedere impegno distribuito (AE)
AF Vedere data di fine effettiva (AF)
affidabilit, 370
allocazione dei costi, 10, 51, 157, 167, 168, 169,
170, 171, 356
ambito del progetto, 9, 43, 45, 78, 86, 87, 88, 89,
99, 103, 105, 106, 108, 109, 110, 112, 113,
117, 118, 119, 120, 121, 127, 131, 140, 143,
163, 168, 180, 184, 226, 242, 247, 250, 255,
275, 347, 369
ambito, 9, 48, 49, 62, 87, 103, 107, 108, 109, 110,
112, 117, 118, 119, 120, 121, 122, 226, 374
amministrazione del contratto, 10, 65, 269, 289,
290, 291, 292, 294, 296, 355
analisi degli assunti, 248, 352
analisi dei punti di forza, delle debolezze, delle
opportunit e delle minacce (SWOT), 248, 349,
375
analisi del reticolo di schedulazione, 145, 373
analisi del reticolo, 364
analisi del valore monetario atteso (EMV), 257,
348, 360
analisi della riserva, 142, 166, 169, 266, 371
analisi della schedulazione Vedere analisi del
reticolo di schedulazione
analisi dell'albero delle decisioni, 358
analisi delle cause originarie, 373
analisi delle tendenze, 266, 377
analisi dello scostamento, 121, 154, 378
analisi di sensitivit, 374
analisi Monte Carlo, 146, 364
analisi qualitativa del rischio, 10, 53, 237, 244,

246, 249, 250, 251, 253, 254, 259, 260, 263,
370
analisi quantitativa del rischio, 10, 54, 237, 246,
249, 250, 253, 254, 255, 257, 259, 260, 261,
263, 370
anello del reticolo, 364
AOA Vedere attivit su freccia (AOA)
AON Vedere attivit su nodo (AON)
approvare, 86, 112, 352
approvazione Vedere approvare
area applicativa, 13, 351
area di conoscenza di Project Management, 9, 11,
69, 362, 368
area di conoscenza, Project Management Vedere
area di conoscenza di Project Management
AS Vedere data dinizio effettiva (AS)
asset dei processi organizzativi, 40, 84, 87, 90, 101,
102, 107, 109, 113, 122, 127, 136, 140, 143,
155, 162, 177, 184, 190, 191, 204, 210, 216,
218, 225, 230, 234, 235, 236, 242, 247, 250,
255, 268, 275, 284, 287, 294, 297, 365
assicurazione qualit (QA), 186, 187, 188, 189,
197, 349
assunti, 127, 143, 163, 226, 248, 275, 352
attivit critica, 357
attivit di riepilogo, 376
attivit fittizia, 359
attivit predecessore, 366
attivit quasi critica, 364
attivit schedulata, 373
attivit sommario, 361
attivit su freccia (AOA), 133, 348, 351
attivit su nodo (AON), 132, 348, 351
attivit successore, 376
attivit, 10, 49, 50, 123, 127, 128, 129, 130, 131,
132, 135, 136, 137, 138, 139, 140, 141, 142,
143, 144, 151, 156, 164, 166, 167, 168, 204,
274, 276, 279, 282, 348, 350, 351
attributi delle attivit, 130, 131, 135, 136, 138,
140, 143, 144, 151, 156, 350
auccessore Vedere attivit successore
autorit, 207, 352
autorizzazione del lavoro, 378
avvio del progetto, 368
azienda, 40, 83, 87, 90, 101, 107, 127, 136, 140,
162, 184, 203, 210, 225, 242, 247, 275, 359
Indice
381
Indice
azione correttiva, 92, 93, 96, 98, 99, 119, 122,

155, 177, 189, 190, 197, 218, 234, 236, 267,
294, 356
azione preventiva, 92, 93, 96, 98, 99, 189, 197,
218, 267, 366
B
BAC Vedere budget al completamento (BAC)
bando di gara (IFB), 349, 362
baseline dei costi Vedere baseline
baseline dell'ambito Vedere baseline
baseline di misurazione delle prestazioni, 365
baseline, 151, 153, 155, 170, 172, 177, 187, 197,
352, 356
BCWP Vedere costo preventivato del lavoro eseguito
(BCWP)
BCWS Vedere costo preventivato del lavoro
programmato (BCWS)
beni, 361
BOM Vedere distinta base (BOM)
brainstorming, 247, 353
budget al completamento (BAC), 173, 175, 176, 348,
353
budget, 177, 234, 263, 348, 353
buffer, 353
C
CA Vedere punto di controllo (CA)
calcolo a ritroso, 352
calcolo in avanti, 361
calendario delle risorse, 138, 141, 144, 168, 371
calendario di progetto, 152, 367
cambiamento non controllato dell'ambito, 374
CAP Vedere piano dei punti di controllo (CAP)
capitolato (SOW), 375
capitolato contrattuale (SOW), 355
carta di controllo, 192, 193, 355
categoria di rischio, 372
causa comune, 354
causa straordinaria, 375
cauzione, 372
CCB Vedere comitato gestione modifiche (CCB)
charter Vedere Project Charter
chiudere il progetto, 9, 67, 79, 100, 101, 267, 295,
354
chiusura del contratto, 10, 67, 102, 269, 274, 295,
296, 297, 355
ciclo di vita del progetto, 9, 19, 21, 23, 24, 368
ciclo di vita di prodotto, 23, 367
ciclo di vita Vedere ciclo di vita del progetto
cliente, 26, 181, 357
codice attivit, 350
codice di classificazione, 354
co-location, 214, 354
comitato gestione modifiche (CCB), 348, 353
componente della WBS, 378
componente, 129, 354
compressione dei tempi (Crashing), 145, 357
compressione della schedulazione, 145, 373
comunicazione, 89, 224, 228, 354
conoscenza, 3, 9, 12, 13, 15, 38, 70, 77, 78, 103,

104, 117, 123, 148, 157, 179, 199, 200, 221,
230, 237, 247, 264, 269, 270, 271, 349, 362,
367, 368, 369, 370
contingency Vedere riserva
contratto a prezzo fermo e fisso (FFP), 348, 361
contratto a prezzo fisso pi incentivo (FPIF), 349,
361
contratto a prezzo prefissato o a importo
forfettario, 361
contratto a rimborso spese pi incentivo (CPIF),
278, 348, 356
contratto a rimborso spese pi percentuale dei
costi (CPPC). Vedere contratto a rimborso
spese pi quota variabile
contratto a rimborso spese pi quota fissa (CPFF),
278, 348, 356
contratto a rimborso spese pi quota variabile
(CPF), 278, 348, 356
contratto con rimborso spese, 356
contratto Time and Material (T&M), 377
contratto, 10, 65, 67, 82, 100, 101, 102, 168, 269,
274, 277, 280, 281, 284, 288, 289, 290, 291,
292, 293, 294, 295, 296, 297, 348, 355
controllare Vedere controllo
controllo dei costi, 10, 63, 157, 171, 172, 177, 356
controllo della schedulazione, 10, 62, 123, 152,
153, 154, 156, 373
controllo dell'ambito, 9, 62, 103, 119, 120, 121,
374
controllo delle modifiche, 90, 96, 121, 153, 172,
292, 348, 353
controllo di qualit (QC), 186, 190, 191, 197,
198, 349, 356
controllo integrato delle modifiche, 9, 61, 79, 88,
96, 98, 99, 101, 112, 119, 121, 122, 130, 135,
138, 152, 153, 155, 167, 171, 172, 177, 187,
190, 197, 198, 218, 231, 234, 264, 267, 280,
290, 291, 294, 362
controllo, 10, 63, 90, 94, 129, 158, 179, 189, 190,
191, 192, 193, 197, 232, 264, 265, 267, 291,
348, 349, 355
convalida, 377
convergenza di percorsi, 365
COQ Vedere costo della qualit (COQ)
correzione dei difetti, 92, 93, 94, 96, 98, 99, 189,
196, 197, 358
corrispettivo, 354
costo della qualit (COQ), 180, 186, 348, 356
costo effettivo (AC), 173, 176, 234, 348, 351, 356,
357, 360,
costo effettivo del lavoro eseguito (ACWP), 348,
351
costo preventivato del lavoro eseguito (BCWP),
348, 353, 359
costo preventivato del lavoro programmato
(BCWS), 348, 353, 366
378
costo, 10, 20, 21, 51, 63, 89, 112, 135, 141, 157,
158, 161, 162, 164, 165, 166, 167, 168, 169,
170, 171, 172, 173, 176, 177, 180, 185, 186,
196, 210, 233, 234, 256, 259, 276, 278, 282,
348, 355, 356, 357
CPF Vedere contratto a rimborso spese pi quota
variabile (CPF)
CPFF Vedere contratto a rimborso spese pi quota
fissa (CPFF)
CPI Vedere indice di efficienza dei costi (CPI)
CPIF Vedere contratto a rimborso spese pi
incentivo (CPIF)
CPM Vedere metodo del percorso critico (CPM)
CPPC Vedere contratto a rimborso spese pi
percentuale dei costi (CPPC)
creare la WBS (struttura di scomposizione del
lavoro), 357
criteri di accettazione, 350
criteri, 283, 287, 357
curva a S, 374
CV Vedere scostamento dei costi (CV)
CWBS Vedere WBS del contratto (CWBS)
D
dalla parte del cliente, 180, 378
data corrente Vedere data di aggiornamento
data dinizio attuale, 357
data dinizio effettiva (AS), 351
data dinizio pianificata (PS) Vedere data dinizio
schedulata
data dinizio schedulata (SS), 366, 374
data dinizio, 375
data di aggiornamento (DD), 348, 357
data di avanzamento Vedere data di
aggiornamento
data di fine attuale, 357
data di fine di baseline, 352
data di fine effettiva (AF), 348, 351
data di fine massima (LF), 349, 362
data di fine minima (EF), 348, 359
data di fine pianificata (PF) Vedere data di fine
schedulata
data di fine schedulata (SF), 349, 366, 374
data di fine, 361
data di inizio di baseline, 352
data di inizio massima (LS), 363
data di inizio minima (ES), 348, 359
data imposta, 362
data obiettivo di completamento (TC), 376
data obiettivo di fine (TF), 376
data obiettivo di inizio (TS), 376
data, 144, 348, 358
database dei rischi, 372
dati storici, 102, 362
DD Vedere data di aggiornamento (DD)
definizione dell'ambito, 9, 49, 87, 103, 109, 110,
112, 226, 374
definizione delle attivit, 10, 49, 123, 127, 128,
129, 130, 351
deliverable, 297, 358
descrizione della mansione, 205, 366

descrizione dell'ambito del progetto, 9, 43, 45, 78,
86, 87, 88, 89, 99, 108, 109, 110, 113, 117,
118, 120, 121, 127, 131, 140, 143, 163, 168,
184, 226, 242, 247, 250, 255, 275, 369
descrizione dell'attivit (AD), 348, 351
descrizione delle specifiche di prodotto, 367
diagramma a barre, 154, 352
diagramma di flusso, 193, 361
diagramma di Gantt Vedere diagramma a barre
diagramma di Pareto, 195, 365
diagramma d'influenza, 362
diagramma logico Vedere reticolo di schedulazione
del progetto
diagramma reticolare della schedulazione su scala
temporale, 377
difetto, 92, 93, 94, 96, 98, 99, 189, 196, 197, 358
dirigere e gestire l'esecuzione del progetto, 9, 56,
78, 91, 92, 93, 119, 216, 232, 264, 267, 291,
358
disciplina, 359
distinta base (BOM), 117, 348, 353
distribuzione delle informazioni, 10, 57, 221, 228,
229, 230, 231, 362
divergenza di percorsi, 365
dizionario della WBS, 378
documenti di approvvigionamento, 282, 284, 367
documento, 78, 285, 287, 359, 360
DU Vedere durata (DU)
DUR Vedere durata (DUR)
durata (DU o DUR), 348, 359
durata dell'attivit, 10, 50, 123, 139, 140, 141,
142, 144, 164, 351
durata effettiva, 351
durata originale (OD), 365
durata residua (RD), 370
E
EAC Vedere stima al completamento (EAC)
Earned Value (EV), 173, 174, 176, 234, 348, 353,
356, 357, 359, 373, 374
EF Vedere data di fine minima (EF)
effettuare l'assicurazione qualit (QA), 365
elaborazione progressiva, 6, 367
elemento di lavoro Vedere attivit e attivit
schedulata
elenco delle attivit, 129, 131, 135, 136, 140, 144,
156, 351
EMV Vedere valore monetario atteso (EMV)
ES Vedere data di inizio minima (ES)
esecuzione del controllo di qualit (QC), 365
esecuzione Vedere eseguire
esecuzione. Vedere eseguire
eseguire, 38, 40, 41, 55, 56, 67, 68, 78, 92, 291,
360
estremit aperta del reticolo, 364
ETC Vedere stima a finire (ETC)
EV Vedere Earned Value (EV)
evento, 360
evitare i rischi, 372
Indice
379
Indice
EVM Vedere metodo dell'Earned Value (EVM)

EVT Vedere tecnica dell'Earned Value (EVT)
F
Failure Mode and Effect Analysis (FMEA), 348,
360
fase di progetto, 22, 23, 116, 366, 369
fase Vedere fase di progetto
Fast Tracking, 360
fattori ambientali aziendali, 40, 83, 87, 90, 101,
107, 127, 136, 140, 162, 184, 203, 210, 225,
242, 247, 275, 359
FF Vedere fine-fine (FF)
FF Vedere Free Float (FF)
FFP Vedere contratto a prezzo fermo e fisso (FFP)
fine-fine (FF), 348, 361
fine-inizio (FS), 349, 361
Float Vedere Total Float e Free Float
FMEA Vedere Failure Mode and Effect Analysis
(FMEA)
fondi, 361
fornitore, 271, 278, 287, 289, 291, 292, 295, 374
FPIF Vedere contratto a prezzo fisso pi incentivo
(FPIF)
Free Float (FF), 348, 361
FS Vedere fine-inizio (FS)
funzioni operative, 364
G
gestione dei costi di progetto, 10, 77, 157, 158,
159, 160, 347, 367
gestione dei rischi di progetto, 10, 77, 237, 239,
241, 249, 260, 266, 268, 347, 369
gestione dei tempi di progetto, 10, 77, 123, 124,
125, 126, 152, 347, 370
gestione del portfolio, 16, 366
gestione della comunicazione di progetto, 10, 221,
222, 223, 347, 367
gestione della qualit di progetto, 10, 179, 180,
182, 183, 185, 347, 369
gestione dell'ambito del progetto, 9, 103, 105, 106,
108, 109, 112, 113, 118, 119, 120, 180, 347,
369
gestione dell'approvvigionamento di progetto, 10,
269, 270, 271, 272, 273, 347, 369
gestione delle risorse umane di progetto, 10, 199,
200, 201, 202, 347, 368
gestione dell'integrazione di progetto, 9, 77, 79,
80, 347, 368
gestione qualit totale (TQM), 180, 181, 350, 377
gestire gli stakeholder, 10, 64, 221, 235, 236, 363
gestire il gruppo di progetto, 10, 63, 199, 215,
216, 217, 218, 363
gruppi di processi di progetto, 369
gruppo di processi di Project Management, 9, 12,
19, 23, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,
47, 55, 56, 59, 60, 66, 67, 68, 69, 70, 77, 78,
85, 88, 100, 183, 354, 360, 362, 364, 366, 367,
368
gruppo di processi Vedere gruppo di processi di

Project Management
gruppo di progetto, 370
gruppo di Project Management, 13, 369
gruppo virtuale, 211, 378
H
I
identificare i rischi, 10, 53, 237, 243, 246, 247,
249, 250, 253, 254, 259, 261, 263, 372
identificativo dell'attivit, 351
IFB Vedere bando di gara (IFB)
impegno discreto, 359
impegno distribuito (AE), 348, 352
impegno, 348, 349, 352, 359
indice di efficienza dei costi (CPI), 173, 174, 177,
234, 348, 356
indice di efficienza della schedulazione (SPI), 154,
373
informazioni sullo stato di avanzamento del
lavoro, 94, 95, 98, 101, 120, 172, 188, 191,
216, 232, 265, 292, 379
ingegneria del valore (VE), 378
iniziatore, 362
inizio-fine (SF), 375
inizio-inizio (SS), 375
input, 218, 230, 350, 351, 352, 353, 354, 355, 356,
357, 358, 359, 360, 362, 363, 365, 366, 367,
368, 369, 370, 371, 372, 373, 378, 379
integrale, 362
integrato, 9, 61, 79, 88, 96, 98, 99, 101, 112, 119,
121, 122, 130, 135, 138, 152, 153, 155, 167,
171, 172, 177, 187, 190, 197, 198, 218, 231,
234, 264, 267, 280, 290, 291, 294, 362
ispezione, 119, 196, 362
istogramma delle risorse, 208, 371
K
knowledge base delle lesson learned, 363
L
lag, 362
lavoro di progetto Vedere lavoro
lavoro, 6, 27, 82, 87, 91, 94, 95, 98, 101, 113, 114,
116, 117, 120, 121, 128, 163, 168, 172, 188,
191, 205, 216, 232, 265, 276, 280, 281, 284,
292, 348, 349, 350, 359, 370, 378, 379
lead, 363
lesson learned, 230, 363
LF Vedere data di fine massima (LF)
limiti di controllo, 355
limiti di tolleranza delle specifiche, 375
lista di controllo, 248, 353
livellamento delle risorse, 146, 371
livellamento Vedere livellamento delle risorse
livello di impegno (LOE), 349, 363
livello, 180, 361
LOE Vedere livello di impegno (LOE)
logica del reticolo, 364
380
logica Vedere logica del reticolo

LS Vedere data di inizio massima (LS)
M
manager funzionale, 361
materiale, 116, 363
matrice assegnazione responsabilit (RAM), 206,
349, 371
matrice di probabilit e impatto, 245, 251, 252,
367
membri del gruppo di lavoro Vedere membri del
gruppo di progetto
membri del gruppo di progetto, 370
metodo del Critical Chain, 147, 357
metodo del diagramma a frecce (ADM), 133, 352
metodo del diagramma di precedenza (PDM), 132,
133, 258, 349 366
metodo del percorso critico (CPM), 357
metodo dell'Earned Value (EVM), 348, 359
metodologia, 85, 87, 90, 93, 95, 99, 101, 243, 363
milestone di schedulazione, 373
milestone, 89, 130, 131, 149, 151, 364
minaccia, 377
misurazione della performance tecnica, 266, 376
modello di schedulazione, 10, 51, 62, 86, 89, 94,
112, 123, 130, 133, 137, 138, 139, 143, 144,
145, 148, 149, 151, 152, 153, 154, 155, 156,
158, 164, 169, 173, 174, 178, 234, 274, 279,
349, 352, 366, 373, 374
modifica dell'ambito, 374
monitoraggio e controllo dei rischi, 10, 65, 237,
254, 264, 265, 266, 267, 291, 372
monitoraggio Vedere monitorare
monitorare e controllare il lavoro del progetto, 9,
61, 78, 94, 95, 96, 267, 364
monitorare, 9, 38, 40, 41, 59, 60, 61, 78, 94, 95,
96, 171, 264, 265, 267, 364
N
networking, 207, 364
nodo, 348, 364
O
obiettivo, 364
OBS Vedere struttura di scomposizione
dell'organizzazione (OBS)
OD Vedere durata originale
opportunit, 364
organigramma di progetto, 207, 210, 216, 369
organigramma, 205, 365
organizzazione a matrice, 30, 31, 363
organizzazione funzionale, 29, 361
organizzazione per progetti, 29, 370
organizzazione, 9, 13, 19, 31, 32, 84, 180, 197,
205, 226, 365
output, 350, 351, 352, 353, 354, 355, 356, 357,
358, 359, 360, 363, 365, 366, 367, 368, 369,
370, 371, 372, 373, 378, 379
P
PC Vedere percentuale di completamento
PCT Vedere percentuale di completamento
PDM Vedere metodo del diagramma di
precedenza
percentuale di completamento (PC o PCT), 349,
365
percorso critico, 145, 348, 357
percorso del reticolo, 364
Performing Organization, 366
PF Vedere data di fine pianificata (PF)
pianificare gli acquisti, 10, 54, 269, 274, 275, 276,
279, 296, 366
pianificare le forniture, 10, 55, 269, 281, 282, 366
pianificazione a finestra mobile, 128, 373
pianificazione della comunicazione, 10, 52, 211,
221, 225, 226, 227, 354
pianificazione della gestione dei rischi, 10, 53,
237, 242, 243, 244, 245, 246, 249, 250, 251,
261, 372
pianificazione della qualit, 10, 52, 179, 183, 184,
185, 186, 189, 370
pianificazione della risposta ai rischi, 10, 54, 237,
246, 249, 250, 254, 260, 261, 263, 373
pianificazione dell'ambito, 9, 48, 103, 107, 108,
374
pianificazione delle risorse umane, 10, 52, 199,
202, 203, 204, 205, 207, 214, 362
pianificazione delle risorse. Vedere stima delle
risorse delle attivit, 204, 371
piano dei conti, 353
piano dei punti di controllo (CAP), 348, 355
piano di gestione dei costi, 167, 168, 171, 356
piano di gestione dei rischi, 10, 53, 237, 242, 243,
244, 245, 246, 247, 249, 250, 251, 255, 260,
261, 265, 372
piano di gestione del contratto, 290, 292, 296, 355
piano di gestione del personale, 208, 210, 212,
213, 216, 375
piano di gestione della comunicazione, 354
piano di gestione della qualit, 186, 188, 191, 370
piano di gestione della schedulazione, 152, 153,
373
piano di gestione dell'ambito del progetto, 108,
109, 112, 113, 118, 119, 120, 369
piano di gestione dell'approvvigionamento, 279,
281, 284, 287, 290, 296, 367
piano di Project Management, 91, 92, 95, 98, 99,
101, 108, 122, 128, 137, 141, 144, 152, 156,
163, 172, 178, 185, 187, 190, 198, 204, 219,
226, 232, 236, 242, 247, 255, 264, 268, 276,
281, 287, 295, 368
Planning Package, 129, 366
PM Vedere Project Management (PM)
PM Vedere project manager (PM)
PMBOK Vedere Project Management Body of
Knowledge (PMBOK)
PMIS Vedere sistema informativo di Project
Management (PMIS)
Indice
381
Indice
PMO Vedere Program Management Office

(PMO)
PMO Vedere Project Management Office (PMO)
PMP Vedere Project Management Professional
(PMP)
Portfolio, 16, 366
pratica, 113, 234, 366
previsioni, 96, 174, 234, 361
procedura documentata, 359
procedura, 93, 101, 102, 296, 367
processi di avvio, 362
processi di chiusura, 354
processi di esecuzione, 360
processi di monitoraggio e controllo, 59, 364
processi di pianificazione, 366
processo di Project Management, 9, 11, 12, 19, 37,
38, 39, 40, 67, 69, 70, 77, 78, 79, 85, 89, 100,
367, 368
processo di un'area di conoscenza, 362
processo, 23, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,
47, 55, 56, 59, 60, 66, 67, 68, 69, 78, 85, 88,
89, 103, 106, 123, 126, 157, 159, 160, 179,
181, 183, 187, 188, 189, 194, 197, 200, 202,
221, 223, 230, 237, 241, 270, 273, 350, 351,
354, 355, 356, 357, 358, 360, 362, 363, 364,
365, 366, 367, 370, 371, 372, 373, 374, 375
prodotto, 23, 24, 38, 83, 86, 102, 104, 110, 111,
367
progetto, 3, 4, 5, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 32, 33, 37, 38,
39, 40, 43, 45, 46, 67, 68, 69, 70, 77, 78, 79, 80,
81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93,
94, 95, 97, 98, 99, 100, 101, 102, 103, 104, 105,
106, 108, 109, 110, 111, 112, 113, 117, 118,
119, 120, 121, 122, 123, 124, 125, 126, 127,
128, 129, 131, 135, 137, 140, 141, 142, 143,
144, 148, 149, 150, 152, 154, 155, 156, 157,
158, 159, 160, 162, 163, 164, 165, 168, 170,
171, 172, 176, 178, 179, 180, 181, 182, 183,
184, 185, 187, 190, 193, 198, 199, 200, 201,
202, 204, 207, 210, 212, 213, 216, 217, 218,
219, 221, 222, 223, 226, 229, 230, 231, 232,
236, 237, 238, 239, 240, 241, 242, 243, 245,
247, 248, 249, 250, 251, 255, 256, 260, 264,
266, 267, 268, 269, 270, 271, 272, 273, 275,
276, 281, 282, 283, 287, 291, 295, 347, 349,
352, 362, 367, 368, 369, 370, 375
Program Management Office (PMO), 367
Program Management, 16, 349, 367
programma, 4, 16, 349, 367
Project Charter, 43, 45, 86, 87, 108, 109, 353, 367
Project Management (PM), 349, 368
Project Management Body of Knowledge
(PMBOK), 3, 4, 9, 12, 77, 78, 349, 368
Project Management Office (PMO), 17, 18, 26,
32, 33, 349, 368
Project Management Professional (PMP), 4, 8,
283, 349, 368
project manager (PM), 349, 369
PS Vedere data dinizio pianificata (PS), 349
PSWBS Vedere WBS di riepilogo del progetto

(PSWBS)
punto di controllo (CA), 158, 348, 355
PV Vedere valore pianificato (PV)
Q
QA Vedere assicurazione qualit (QA)
QC Vedere controllo di qualit (QC)
qualit, 10, 39, 52, 56, 63, 89, 118, 166, 179, 180,
181, 183, 184, 185, 186, 187, 188, 189, 190,
191, 192, 197, 232, 252, 291, 348, 349, 350,
370
questione, 84, 85, 218, 236, 362
R
RAM Vedere matrice assegnazione responsabilit
(RAM)
rapporto sulle eccezioni, 360
RBS Vedere struttura di scomposizione dei rischi
(RBS)
RBS Vedere struttura di scomposizione delle
risorse (RBS)
RD Vedere durata residua (RD)
reclamo, 354
registro dei rischi, 141, 144, 249, 250, 253, 255,
259, 261, 263, 265, 267, 372
registro, 218, 363
regolamento, 370
regole di base, 214, 361
relazione di dipendenza Vedere relazione logica
relazione di precedenza, 366
relazione logica, 133, 358, 363
report sulle prestazioni, 120, 153, 172, 216, 233,
266, 292, 366
reporting delle prestazioni, 10, 64, 221, 231, 232,
233, 291, 293, 365
requisito, 371
reticolo di schedulazione del progetto, 135, 144,
369
reticolo, 133, 364
revisione della progettazione, 180, 358
RFP Vedere richiesta d'offerta (RFP)
RFQ Vedere richiesta di preventivo (RFQ)
richiesta di informazioni, 367, 370
richiesta di modifica approvata, 92, 99, 109, 113,
120, 131, 153, 172, 188, 192, 232, 236, 265,
292, 352
richiesta di modifica, 93, 95, 99, 189, 353
richiesta di modifica, 93, 96, 98, 112, 118, 119,
122, 130, 135, 138, 152, 155, 167, 171, 177,
190, 197, 218, 231, 234, 267, 280, 290, 294,
371
richiesta di preventivo (RFQ), 371
richiesta di risposte dai fornitori, 10, 58, 269, 281,
284, 285, 371
richiesta d'offerta (RFP), 370
ridurre i rischi, 372
rifacimento, 372
rischio collaterale, 374
rischio residuo, 371
382
rischio, 10, 53, 54, 65, 84, 89, 117, 141, 144, 164,
237, 238, 240, 242, 243, 244, 245, 246, 247,
248, 249, 250, 251, 252, 253, 254, 255, 256,
259, 260, 261, 262, 263, 264, 265, 266, 267,
276, 281, 287, 291, 349, 372, 373
riserva per contingency, 355
riserva, 142, 166, 169, 263, 264, 266, 355, 371
risorsa, 89, 94, 117, 137, 138, 140, 141, 144, 146,
147, 148, 151, 162, 165, 168, 199, 204, 208,
212, 213, 290, 349, 371
risultato, 102, 372
rubrica del gruppo di progetto, 370
ruolo, 32, 207, 373
S
schedulazione a risorse limitate, 371
schedulazione a risorse vincolate Vedere
schedulazione a risorse limitate, 371
schedulazione delle milestone, 151, 364
schedulazione di progetto, 10, 51, 62, 86, 89, 94,
112, 123, 130, 133, 135, 137, 138, 139, 143,
144, 145, 148, 149, 150, 151, 152, 153, 154,
155, 156, 158, 164, 168, 169, 173, 174, 178,
193, 234, 274, 279, 349, 352, 366, 369, 373,
374
schedulazione obiettivo, 376
schedulazione principale, 363
schedulazione Vedere schedulazione di progetto e
modello di schedulazione
schema di documento, 376
scomporre Vedere scomposizione
scomposizione, 114, 115, 128, 358
scostamento dei costi (CV), 173, 177, 234, 348,
357
scostamento dei tempi (SV), 154, 155, 173,177,
234, 349, 374
scostamento, 121, 154, 158, 176, 234, 266, 348,
349, 378
selezionare i fornitori, 10, 58, 269, 281, 286, 287,
288, 289, 290, 374
sequenzializzazione delle attivit, 10, 50, 123,
130, 131, 132, 135, 351
servizio, 102, 374
SF Vedere data di fine schedulata (SF), 349
SF Vedere inizio-fine (SF), 349
simulazione, 146, 259, 375
sistema di autorizzazione del lavoro, 378
sistema di controllo delle modifiche, 90, 121, 153,
172, 292, 353
sistema di gestione della configurazione, 90, 121,
354
sistema di Project Management, 33, 369
sistema informativo di Project Management
(PMIS), 86, 95, 349, 368
sistema, 86, 88, 90, 93, 95, 99, 101, 248, 288, 293,
296, 349, 376
skill, 375
Slack Vedere Total Float e Free Float, 375
software di Project Management, 137, 148, 154,
165, 176, 368
soggetto influente, 362

soglia, 377
sottofase, 376
sottoprogetto, 376
sottoreticolo, 133, 376
SOW Vedere capitolato (SOW), 82, 280, 349
specifiche di prodotto, 367
specifiche di prodotto, 375
SPI Vedere indice di efficienza della
schedulazione (SPI), 155, 174, 177, 234, 349,
373
sponsor del progetto. Vedere sponsor
sponsor, 26, 375, 370
SS Vedere data dinizio schedulata (SS)
SS Vedere inizio-inizio (SS)
stakeholder di progetto. Vedere stakeholder
stakeholder, 19, 24, 26, 82, 83, 109, 110, 111, 180,
226, 227, 231, 235, 370, 375
standard, 9, 113, 282, 375
stima a finire (ETC), 173, 175, 177, 348, 360
stima a tre valori, 142, 377
stima al completamento (EAC), 173, 175, 176,
177, 348, 360, 363
stima bottom-up, 137, 165, 353
Stima dei costi, 10, 51, 135, 157, 161, 162, 164,
166, 167, 356
stima della durata delle attivit, 10, 50, 123, 139,
140, 141, 142, 164, 351
stima delle risorse delle attivit, 10, 50, 123, 135,
136, 137, 138, 141, 164, 274, 279, 351
stima di congruit del costo, 374
stima parametrica, 142, 165, 169, 365
stima per analogia, 141, 164, 351
stima, 167, 168, 173, 348, 360
strumento, 352, 353, 354, 355, 361, 362, 363, 364,
365, 366, 367, 368, 369, 370, 371, 372, 373,
377, 378
struttura di scomposizione dei rischi (RBS), 117,
138, 205, 243, 244, 247, 248, 249, 253, 255,
263, 268, 349, 372
struttura di scomposizione del lavoro (WBS) , 9,
49, 86, 103, 104, 108, 112, 113, 114, 115, 116,
117, 118, 120, 121, 127, 128, 129, 130, 149,
155, 158, 159, 163, 168, 169, 173, 175, 177,
205, 206, 214, 234, 253, 258, 263, 276, 280,
350, 366, 370, 378
struttura di scomposizione delle risorse (RBS),
117, 138, 205, 243, 247, 248, 249, 253, 255,
263, 268, 349, 371
struttura di scomposizione dell'organizzazione
(OBS) , 117, 205, 349, 355, 365
SV Vedere scostamento dei tempi (SV)
sviluppare il gruppo di progetto, 10, 57, 199, 209,
212, 213, 215, 358
sviluppare il piano di Project Management, 9, 48,
78, 88, 89, 90, 91, 124, 158, 358
sviluppare il Project Charter, 9, 43, 45, 78, 81, 82,
85, 86, 358
sviluppare la descrizione dell'ambito del progetto
(preliminare), 358
Indice
383
Indice
sviluppo della schedulazione, 10, 51, 123, 138,

139, 143, 144, 145, 149, 151, 152, 169, 274,
279, 373
SWOT Vedere analisi dei punti di forza, delle
debolezze, delle opportunit e delle minacce
(SWOT)
U
ultima revisione di stima Vedere stima al
completamento
unit temporale, 353
utente, 377
T&M Vedere Time and Material (T&M)

TC Vedere data obiettivo di completamento (TC)
tecnica dell'Earned Value (EVT), 172, 348, 359
tecnica Delphi, 358
tecnica, 95, 348, 351, 352, 353, 354, 355, 356,
357, 358, 359, 360, 361, 362, 363, 364, 365,
366, 367, 371, 372, 373, 376, 377, 378, 379
TF Vedere data obiettivo di fine (TF)
TF Vedere Total Float (TF)
Total Float (TF), 377
TQM Vedere gestione qualit totale (TQM)
trasferire i rischi, 373
triggers, 377
triplo vincolo, 377
TS Vedere data obiettivo di inizio (TS)
valore pianificato (PV) , 173, 174, 175, 176, 234,

349, 353, 366, 373, 374
VE Vedere ingegneria del valore (VE), 350
verifica dell'ambito, 9, 62, 103, 118, 119, 374
verifica, 97, 378
vincolo, 354
W
War Room, 378
WBS del contratto (CWBS), 348, 355
WBS di riepilogo del progetto (PSWBS), 370
WBS Vedere struttura di scomposizione del lavoro
(WBS)
Work Package, 114, 379
workaround, 379
384
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 nonprofit 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.

Pmbok 2004

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

Pmbok 2004

Caricato da

Copyright:

Formati disponibili

Guida al

un American National Standard

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

Project Management Institute, Inc.

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

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

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

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

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

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

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

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

ELENCO TABELLE E FIGURE

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

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

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

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

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

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

PREFAZIONE ALLA TERZA

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

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

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

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

Tradurre letteratura tecnica in lingue diverse da quella originale non compito

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

Ciclo di vita del progetto e Struttura

Obiettivo della Guida al PMBOK

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

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

Destinatari della Guida al PMBOK

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

Che cos un progetto?

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

lopportunit o finestra di mercato generalmente temporanea; molti progetti

Prodotti, servizi o risultati unici

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

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

Progetti e lavoro operativo a confronto

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

Gli obiettivi dei progetti e delle funzioni operative sono di natura

Progetti e pianificazione strategica

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

Che cos il Project Management?

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

La struttura della Guida al PMBOK

Sezione I: Il contesto del Project Management

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

Sezione III: Le aree di conoscenza di Project Management

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

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

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

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

Project Management Body of Knowledge

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

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

Conoscenza degli standard, dei regolamenti e delle aree

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

Uno standard un documento stabilito tramite consenso diffuso e approvato da

Comprensione del contesto del progetto

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

Conoscenza e skill in materia di general management

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