La gestione dell'integrazione del progetto è fondamentale per il project manager, poiché implica la coordinazione di tutti gli aspetti del progetto per raggiungere gli obiettivi stabiliti. Questo processo include lo sviluppo del project charter, la creazione del piano di project management e il monitoraggio delle performance del progetto, garantendo che tutte le modifiche siano gestite adeguatamente. La corretta integrazione e gestione delle conoscenze aziendali e dei fattori ambientali sono essenziali per il successo del progetto.

1. Area di conoscenza
Gestione dell’integrazione
Bibliografia
1. PMBOK® Guide, 5th edition (www.pmi.org)
2. Edwel_PMP_Exam_Prep_Textbook_Version_4.0 (http://edwel.com/materials/)
3. PMP-Exam-Prep-Manual-Online Free-5_1b (http://preparepm.com/index.html)
4. Rita Mulcahy’s PMP Exam Prep –seventh edition (http://shop.rmcls.com/index.aspx)
mario.gentili@mariogentili.it

2. Area di conoscenza INTEGRAZIONE:
• Trasversale ai 5 gruppi di processi
• Si articola in 6 processi
La gestione dell’integrazione del progetto è il vero lavoro del Project Manager che deve
avere la visione di assieme di tutti i punti di vista del prj (costi, risorse, tempi, ecc…) per
completare il progetto raggiungendone i deliverable come previsto dai diversi piani della
sua schedulazione.

3. Qual è il vero compito e il principale ruolo del PM?
La gestione dell'integrazione del progetto
ovvero, mettere tutte le componenti di un progetto in un insieme coerente
che permetta al progetto di essere realizzato velocemente, con il giusto
impegno delle risorse e con il raggiungimento di tutti gli obiettivi.
Non bisogna focalizzarsi solo sulla realizzazione dei WP: il PM deve «salire in
terrazza» ed avere la visione sistemica del progetto, attraverso il
bilanciamento dei processi di tutte le aree di conoscenza (ambito, tempi,
costi, qualità, risorse, comunicazione, rischi, approvvigionamenti e
stakeholders).
La Gestione dell’integrazione del progetto è talmente importante per il lavoro
di un project manager che si potrebbe dire di essere la ragione dell'esistenza
del project manager di una organizzazione su un progetto.
La gestione dell’integrazione del progetto è trasversale a tutti gli processi che
sono verticali sull’area di competenza specifica.

4. 4.1 Sviluppare il Project Charter (PC) - è il processo di sviluppo del documento che autorizza
formalmente l’esistenza di un progetto, individua il Project Manager e gli conferisce l’autorità
necessaria per utilizzare le risorse per le attività previste dal progetto. Documenta gli obiettivi
iniziali (e ad alto livello) che bisogna realizzare per soddisfare le esigenze degli stakeholder.
4.2 Sviluppare il Piano di Project Management (PMP) – è il processo che consente di
documentare le azioni necessarie per definire, preparare, integrare e coordinare tutti i piani
ausiliari: c’è infatti un piano per ogni area di conoscenza; il loro insieme è il PMP
4.3 Dirigere e gestire il lavoro del progetto - è il processo di esecuzione del lavoro definito nel
PMP e di gestione delle modifiche approvate che consentono di raggiungere gli obiettivi del
progetto.
4.4 Monitorare e controllare il lavoro del progetto - è il processo di rilevamento, revisione e
rendicontazione dell’avanzamento del progetto al fine di conseguire gli obiettivi di prestazione
definiti nel PMP.
4.5 Eseguire il controllo integrato delle modifiche - è il processo di gestione di tutte le richieste
di modifica, di approvazione delle stesse e di applicazione delle modifiche (approvate).
4.6 Chiudere il progetto o una sua fase - è il processo di completamento di tutte le attività
appartenenti a vari gruppi di processi di Project Management per completare a livello formale il
progetto o una sua fase. Ha come output i deliverable del progetto.

5. Project Integration management: un altro punto di vista
4.1 Avvio
4.2
Pianificazione
4.3
Esecuzione
4.4
Monitoraggio
e controllo
4.5 Chiusura
• Scegliere il PM
• Determinare i fattori
ambientali aziendali
(EEF)
• Determinare gli
Organization Process
Asset (OPA)
• Suddividere progetti
grandi in fasi più
gestibili
• Capire il Business Case
(BC)
• Scoprire i requisiti e i
rischi iniziali
• Creare obiettivi
misurabili
• Scegliere come si vuole
pianificare (piani
secondari. Uno per ogni
Area di Conoscenza)
• Individuare il team
• Determinare ruoli e
responsabilità
• Iterare (go-back
iteration)
• Creare il Change Mngt
Plan
• Definire come si
vogliono eseguire e
controllare tutti i piani
secondari del PMP
• Sviluppare un PMP
finale realistico e
misurabile
• Ottenere
l’approvazione formale
del PMP
• Indire la riunione di
kickoff del progetto
• Eseguire i lavori
coerentemente al PMP
• Produrre i prodotti
previsti dai deliverable
• Gestire le CR
• Implementare le sole CR
approvate
• Migliorare in
continuazione
• Seguire i processi tutti i
processi
• Definire le azioni
necessarie per
controllare il prj
• Comparare le
performance del prj con
quelle pianificate
• Individuare le variazioni
al PMP e decidere se
queste necessitano di
eventuali azioni
correttive o CR
• Individuare i fattori che
generano cambiamenti
• Gestire le CR
• Effettuare il controllo
sistemico del prj
• Approvare o rifiutare CR
• Informare gli stakeholder
dei risultati delle CR
• Aggiornare il PMP, i piani
secondari e i documenti
di progetto
• Gestire la configurazione
del prj
• Confermare che il lavoro
è conforme ai requisiti
• Ottenere l’accettazione
finale di quanto prodotto
• Effettuare la chiusura
finanziaria
• «barricare» i prodotti
finali da richieste di
variazioni
• Sollecitare i feedback
circa la CS del prj
• Completare i report finali
di consegna/chiusura
• Indicizzare ed archiviare i
documenti prodotti
• Aggiornare la lesson
learned knowledge base

6. Project Integration management

7. Enterprise Enviromental Factors (EEF) = Fattori ambientali aziendali = cosa ho a disposizione
e quali regole devo rispettare per il mio lavoro:
1. Cultura e organizzazione aziendale
2. Standard. Norme e regole legislative o di settore (ad es. normative di autorità di controllo,
standard dei prodotti, standard di qualità e standard di abilità tecnica);
3. Risorse umane esistenti (profilo, capacità, …)
4. Sistemi di autorizzazione per stabilire chi e come formalmente autorizza il progetto o una
sua fase intermedia
5. Condizioni di mercato
6. Tolleranza al rischio degli stakeholder
7. DB commerciali
8. Project Management Information System (PMIS) = Sistema informativo del Project
Management (ad es. uno strumento automatizzato, quale uno strumento software di
schedulazione, un sistema di gestione della configurazione, un sistema di raccolta e
distribuzione delle informazioni, o interfacce web ad altri sistemi automatizzati on-line). In
genere include:
• Change mngt (gestione delle modifiche, chi può fare cosa e come)
• Configuration system (versioning documentale e di sistema)
• Authorization system (chi autorizza cosa e quando: workflow)
DIZIONARIO

8. Organization Process Assets (OPA) = come si deve fare un lavoro = procedure = std, guide e
istruzioni di lavoro per:
1. Modalità di gestione delle autorizzazioni: media da utilizzare, periodo di conservazione
delle info nei DB, requisiti di sicurezza
2. Procedure di qualità (= gestione dei problemi e dei difetti) che definiscono la tipologia di
controlli necessari per la loro:
• identificazione,
• risoluzione
• tracciatura delle attività
3. Procedure di gestione finanziaria (ad es. reporting sui tempi, codici di contabilità, revisioni
costi e spese e disposizioni contrattualistiche)
4. Procedure di controllo del rischio, incluse le categorie di rischio, la definizione della
probabilità e dell’impatto, la matrice di probabilità e impatto;
5. Template e form
6. Database di misurazione dei processi
7. Database delle lesson learned (Knowledge Management System)
DIZIONARIO

9. Statement Of Work (SOW) = capitolato del progetto = generalmente prodotto dallo sponsor, è
il documento che descrive ad alto livello il prodotto/servizio da realizzare.
Per progetti esterni è detto Procurement SOW e coincide con il disciplinare tecnico.
Contiene:
1. descrizione dettagliata del progetto, delle sue fasi, delle attività che costituiscono ogni
fase, delle tempistiche, degli output di ogni fase, delle date delle sue revisioni e delle sue
milestone
2. elenco dei requisiti e delle caratteristiche del prodotto/servizio da realizzare
3. elenco delle persone, in termini di ruoli (profili necessari alle attività da realizzare) che
prenderanno in carico ogni attività progettuale
4. riferimenti a leggi, normative, standard e criteri di accettazione
5. piano dei pagamenti riferiti alle diverse fasi del progetto secondo il Base Agreement e
legato ad eventuali criteri di accettazione delle diverse fasi
6. requisiti contrattuali come la gestione di eventuali proprietà intellettuali o quella degli
accordi di riservatezza
DIZIONARIO

10. Business Case (BC) = documento in cui vengono giustificati gli investimenti necessari alla
realizzazione del progetto/servizio. Si tratta di uno studio di fattibilità, ovvero di un’analisi dei
fabbisogni. Contiene , tra l’altro:
• i motivi per cui si richiede la realizzazione del progetto,
• l’analisi dei costi/benefici
DIZIONARIO
Perché il progetto si deve realizzare?
Il gioco vale la candela?
I progetti devono essere selezionati solo in base a solide considerazioni di business
attraverso metodi e tecniche consolidate (NFV, PV, IRR, …)
Nei progetti multifase il BC deve essere revisionato periodicamente per verificarne
l’effettiva validità/necessità e la possibilità che questo possa conseguire i benefici
richiesti.

11. Baseline del Piano di Progetto, sono realizzate nel gruppo di processi di
pianificazione. Sono 3 e prendono il nome di Performance Measurement
Baseline:
1- Baseline di ambito ( contesto + WBS + dizionario WBS)
+
2- Baseline tempi
+
3- Baseline Costi
DIZIONARIO
Serve per misurare le prestazioni del progetto:
Dove sto? (realtà)
vs
Dove dovrei essere? (previsione)
Peggior nemico:
RISCHI non identificati o valutati correttamente
Strumenti:
Azioni correttive, preventive e rimozione difetti

12. Piano di gestione delle modifiche (Change Request Plan):
DIZIONARIO
Documento che contiene:
• Le procedure di controllo
• I livelli di autorizzazione
• Comitato di gestione modifiche (ruoli e autorità)
• Strumento per tracciare le modifiche
Le modifiche, prima di essere controllate e tracciate, devono essere prevenute
con la progettazione e la gestione dei rischi
Prima di passare alla fase di approvazione di una modifica bisogna studiarne di
alternative per vedere se esistono soluzioni più favorevoli
Le sole CR approvate dal Comitato di approvazione delle CR, vanno a modificare

13. Il modello della conoscenza DIKW: DATI -> INFORMAZIONI -> CONOSCENZA -> SAGGEZZA
(Data- Information- Knowledge- Wisdom - DIKW schema)
DIZIONARIO
Oggettività
Volume
Completezza
Soggettività
Valore
Struttura

14. è il processo di scrittura del documento che autorizza formalmente l’avvio di un
progetto: non c’è progetto senza PC! Documenta i requisiti iniziali che soddisfano le
esigenze e le aspettative degli stakeholder. Il Project Charter fornisce al PM l’autorità
per assegnare budget e prime risorse alle attività del progetto. Descrive , ad alto
livello, i requisiti di progetto (ambito, tempi, costi, rischi, risorse, …) e inquadra il
progetto all’interno della strategia aziendale. È emesso dallo sponsor e NON dal PM
(a meno che il PM sia incaricato dallo sponsor. IL PC indica il PM di prj che ancora non
esiste quando esiste il PC!).
4.1 Sviluppare il Project Charter - PC
• scopo, obiettivi misurabili (SMART goals Specific,
Measurable, Agreed, Realist, Time-based) e relativi criteri
di successo;
• requisiti di alto livello;
• descrizione del progetto di alto livello;
• rischi di alto livello;
• schedulazione sintetica milestone;
• budget di massima;
• requisiti di approvazione
• riferimenti (PM assegnato, sue responsabilità e suo
livello di autorità);
• nome e autorità dello sponsor o di altre persone che
autorizzano il Project Charter.
Produrre il Project
Charter• SOW
• Accordi (contratto
firmato!)
• BC
Project charter
• EEF
• OPA
• Interviste, riunioni
• Pareri esperti
• Gestione dei conflitti

15. • Project title and description (cos’è il progetto?)
• PM incaricato e livello di autorità (chi è il PM e quale la sua autorità? Nome e cognome chi gli ha
conferito l’autorità?)
• Business Case (perché il prj deve essere fatto? Su quali basi finanziarie e di scenario di mercato si
giustifica?)
• Risorse assegnate (quali e quante risorse sono state preassegnate? Nomi e cognomi e ruolo)
• Stakeholders (chi sono? E quale la loro influenza sul progetto?)
• Requisiti degli Stakeholders (gli obiettivi degli sponsor)
• Descrizione del prodotto e dei deliverable (ad alto livello . Due date importanti: inizio e fine)
• Obiettivi di progetto misurabili ( il prj come si inserisce nella strategia aziendale? Quali obiettivi
strategici permette di raggiungere? Quali indicatori usare per la loro misura?)
• Processi di approvazione (quali sono gli item di progetto che necessitano di approvazione? Chi
approva?)
• Piano dei rischi ad alto livello (quali i rischi? Quali le opportunità? SWOT analysis)
• Firme
4.1 Sviluppare il Project Charter - Esempio

16. 4.1 Sviluppare il Project Charter – Piccolo vs grande prj
La differenza è solo nella dimensione!
Un grande prj ha infatti:
• numero molto grande di stakeholder,
• team di lavoro molto numeroso e variegato,
• sistema di autorizzazione complicato,
• sistema complicato per
• Comunicazione
• Gestione della configurazione
• Gestione delle procedure e dei processi secondo standard di qualità
• Coinvolge approvvigionamenti ed acquisti più complessi.
In ogni caso le attività che distinguono la realizzazione di un PC sono:
1. Identificazione degli stakeholder
2. Riunioni con i key stakeholder, per confermare i requisiti di alto livello, lo scope, i rischi, i
vincoli funzionali e non funzionali
3. Definire il product scope
4. Definire gli obiettivi di progetto, i vincoli e i criteri di successo
5. Documentare i rischi

17. Esistono due classi di metodi:
4.1 Sviluppare il Project Charter: metodi di selezione del progetto
Metodi di misurazione dei benefici
Approccio comparativo
• Murder board (un team di persone che
cercano di ammazzare l’idea. Fanno da bastion
contrario!)
• Peer review (valutazione qualitativa basata
sul giudizio tra pari ruolo )
• Scoring models (analisi delle probabilità di
fallimento dell’idea)
• Modelli economici (determinazione del ROI)
• Present value (attualizzazione
dell’investimento nel tempo)
• Net present value
• Internal return rate
• Payback period (tempo necessario al
pareggio tra costi e ricavi)
• Benefit-cost ratio
Metodi di ottimizzazione delle criticità
Approccio matematico
• Linear programming
• Integer programming
• Dynamic programming
• Multi-objective programming

18. 4.1 Sviluppare il Project Charter: metodi di misurazione costi-benefici
Present value PV = FV / (1 + r)n, dove:
PV= present value, FV= future value, r= tasso di sconto, n= periodo
elimina il fattore tempo, attualizzando il valore futuro al presente, applicando nel periodo il tasso di sconto tra un
anno, qual è il valore attuale di 100 euro al tasso del 5%? PV= 100 / (1+0,05) = 100 / 1,05 = 95, 24 Nel futuro si ha
sempre un deprezzamento. Maggiore è il valore, meglio è.
Net Present value NPV = Somma di tutti i PV dei flussi di cassa (entrate e uscite)
per poi confrontarli
Se per esempio si tratta di scegliere tra il progetto A che dura 10 anni ed ha un NPV di 100 euro e il progetto B che
dura 3 anni ed ha un NPV di 90 euro il progetto da scegliere è A perché ha un NPV maggiore di B. Il fatto che un
progetto duri più o meno dell’altro non ha nessuna importanza perché nel calcolare l’NPV si è già tenuto conto del
tempo attualizzando i flussi di cassa.
Internal Return Rate IRR = resa in % di un progetto. Maggiore è il valore, meglio è.
Payback Period PP = tempo necessario affinché ci sia il pareggio tra i costi e i
ricavi. Minore è il valore, meglio è.
Costo opportunità OC = NPV del progetto scartato
Costi sommersi (Sunt Cost) - SC = costi di somme non + recuperabili
Capitale circolante = liquidità del progetto = cassa + magazzino + crediti a breve
termine
Ammortamento - Depreciation = può essere a rata costante e a rata variabile
(mutui, …)
Rapporto benefici e costi BCR Benefit Cost Ratio = rapporto tra ricavi e costi.
Favorevole se > 1 (perché i benefici sono maggiori)

19. 4.1 Sviluppare il Project Charter: metodi di misurazione costi-benefici
Dati due progetti A e B: A + favorevole a B, indipendentemente dal tempo se:
PV (A) > PV(B),
o
NPV (A) > NPV(B),
o
IRR (A) > IRR (B),
o
BCR (A) > 1 > BCR (B)
Oppure se nel tempo:
PP(A) < PP(B)

20. È il processo di definizione, preparazione e coordinamento di tutti i piani ausiliari (uno per ogni
Area di Conoscenza), nonché di integrazione degli stessi in un piano completo il PMP. Il principale
vantaggio di questo processo è un documento centrale che definisce le basi per l’intero lavoro di
progetto. Deve essere realistico e formalmente approvato (firmato) dagli sponsor (inizialmente, nel
corso del kickoff meeting). Il piano di Project Management aggiornato progressivamente, è
approvato dagli stakeholder nel processo Eseguire il controllo integrato delle modifiche (Sezione
4.5).
4.2 Sviluppare il Piano di progetto (Project Management Plan - PMP)
• Un piano per ognuna delle 10 aree di conoscenza +
• Performance measurement baseline, ovvero:
• scope (WBS e relativo dizionario),
• schedule (Time),
• Cost (cost statement)
• Requirements mngt plan (gestione dei requisiti-WBS)
• Change mngt plan (come gestisco le modifiche al prj: how
& who, approval proc, Change Control Board, tracking). Può
essere parte del PM Information System
• Configuration mngt plan (come gestisco i cambiamenti ai
deliverables e relativi doc). Può essere parte del PM
Information System
• Process improvement plan (riuso e miglioramento di
processi esistenti)
Sviluppare il Piano
di progetto
Project Management Plan
(approved, realistic and formal)
• Project charter
• Output da altri processi
• Pareri di Esperti
• Tecniche facilitazione
(Interviste, riunioni,…)
• EEF
• OPA

21. Fa parte dello sviluppo del PMP la scelta da parte del PM dei processi di project
management che saranno effettivamente utilizzati per il progetto, processi scelti in
base alle esigenze del progetto (non necessariamente tutti i 47 processi saranno
utilizzati, mentre, di contro, sicuramente dovranno essere prese in considerazione
tutte le 10 aree di conoscenza). Il PMP prevede:
• i piani di gestione di tutte delle 10 aree di conoscenza;
• la scope, schedule e cost baseline = performance measurement baseline. Il
lavoro del PM sarà quello di un continuo controllo di queste 3 baseline per
gestirne gli scostamenti. Possono essere modificate solo tramite CR approvate;
• un Piano di gestione dei requisiti. Piano per descrivere come verranno gestiti e
controllati i requisiti del progetto = bisogni e aspettative degli stakeholder;
• un piano di gestione delle modifiche sul progetto (change management plan) =
come e chi può effettuare i cambiamenti e come questi sono tracciati (fa parte
del PMIS);
• un piano di gestione della configurazione (change configuration plan), ovvero la
descrizione per la gestione delle modifiche della documentazione del prj (fa
parte del PMIS);
• un piano di miglioramento dei processi. Questo piano descrive come saranno
migliorati i processi utilizzati per realizzare il prj.
4.2 Sviluppare il Piano di progetto – dettaglio output

22. è la gestione dell’insieme delle attività previste nel PMP che consentono il
raggiungimento dei deliverable di progetto.
Le informazioni sullo stato di avanzamento del lavoro saranno inoltre utilizzate
come input per il gruppo di processi di monitoraggio e controllo.
Nel corso dell’esecuzione possono esserci richieste di modifica (Change Request)
che devono essere tutte approvate da chi di competenza e che possono modificare
il piano di progetto.
La loro natura è di tipo:
• Azioni correttive: finalizzate ad riallineare le prestazioni effettive del progetto con
quelle del Project Management Plan;
• Azione preventive: finalizzate a ridurre la probabilità di subire le conseguenze
negative associate ai rischi del progetto;
• Correzioni di un difetto: finalizzate a riparare o a sostituire componenti difettosi
e/o non conformi.
4.3 Dirigere e gestire i lavori del progetto

23. 4.3 Dirigere e gestire i lavori del progetto
Richieste di modifica da approvare
Eseguire il Piano
di progetto
• Project deliverables
• Work Performance data (indicatori - DIKW)
• PMP aggiornato
• Documenti di progetto aggiornati
Project management Plan
• Interviste, riunioni
• Esperti
• PM information system
Richieste di modifica approvate
• EEF
• OPA
Implementazione di modifica approvate

24. È il processo di rilevamento, revisione e reporting dell’avanzamento del lavoro del
progetto che consente di raggiungere gli obiettivi di prestazione definiti nel PMP. Il
principale vantaggio di questo processo è che consente agli stakeholder di
comprendere lo stato attuale del progetto, i passaggi intrapresi e le previsioni di
budget, schedulazione e ambito.
Insieme delle attività per:
• garantire l’aderenza delle attività di progetto a quanto pianificato;
• valutare le prestazioni per determinare l’eventuale necessità di azioni correttive o
preventive, e successivamente raccomandare le azioni ritenute necessarie;
• identificare nuovi rischi e analizzare, rilevare e monitorare i rischi di progetto
esistenti;
• mantenere un’accurata e tempestiva base informativa riguardo ai prodotti del
progetto e alla documentazione associata, fino al completamento del progetto;
• fornire informazioni per l’aggiornamento al PMP.
4.4 Monitorare e controllare il progetto
Misuring vs PMP
Insieme di attività di misura e confronto
con quanto schedulato nel PMP

25. 4.4 Monitorare e controllare il lavoro di progetto
Richieste di modifica da approvare
(correttive, preventive, correzioni difetti)Monitorare e
controllare il
progetto
• Project Management Plan aggiornato
• Documenti di progetto aggiornati
• Work Performance information (DIKW)
• Tecniche di analisi (regressione, trend,
varianza, simulazioni, …
• Interviste, riunioni
• Esperti
• PM Information System
• Modifiche approvate
Previsioni di schedulazioni:
• temporali
• costi
• Project management Plan
• Work Performance Information
(DIKW)
• EEF
• OPA

26. è il processo di:
1. revisione di tutte le richieste di modifica,
2. valutazione dell’impatto della modifica si tutte le aree di conoscenza,
3. ricerca di soluzioni alternative per minimizzare l’impatto sul PMP,
4. ottenimento dell’approvazione della modifica, che può essere:
4.5 Eseguire il controllo integrato delle modifiche
Un sistema di gestione della configurazione con controllo integrato delle modifiche
fornisce un modo standardizzato, efficace ed efficiente per gestire centralmente le
modifiche approvate e le baseline di un progetto.
Tipo modifica Chi approva
Esterna: Project charter sponsor
Interna: Baseline al PMP Change Control Board
Interna: non impatta il PMP PM
Ma anche:
• comunicazione delle decisioni;
• mantenimento dell’integrità delle baseline integrando solo le modifiche approvate
nel PMP e nei documenti di progetto;
• coordinamento delle modifiche dell’intero progetto;
• documentazione dell’impatto completo delle richieste di modifica.

27. 4.5 Eseguire il controllo integrato delle modifiche
Ogni richiesta di modifica documentata deve essere approvata o rifiutata da un
responsabile, solitamente lo sponsor del progetto o il Project Manager. Il
responsabile sarà identificato nel piano di Project Management o dalle procedure
organizzative. Quando richiesto, il processo Eseguire il controllo integrato delle
modifiche include un Comitato gestione modifiche (CCB), che è un gruppo
formalmente costituito con la responsabilità di revisionare, valutare, approvare,
posticipare o rifiutare le modifiche apportate al progetto e di registrare e
comunicare tali decisioni. Le richieste di modifica approvate possono richiedere
nuove o rivedute stime dei costi, sequenze di attività, date di schedulazione,
requisiti di risorse e l’analisi di alternative di risposta ai rischi. Queste modifiche
possono richiedere adeguamenti al piano di Project Management e ad altri
documenti di progetto. Il livello applicato di controllo delle modifiche dipende
dall’area di applicazione, dalla complessità dello specifico progetto, dai requisiti del
contratto, e dal contesto e dall’ambiente di esecuzione del progetto. Per alcune
richieste di modifica può essere richiesta l’approvazione da parte del cliente o dello
sponsor dopo l’approvazione del CCB, a meno che questi non siano parte dello
stesso CCB.

28. 4.5 Eseguire il controllo integrato delle modifiche
Eseguire il
controllo
integrato del
progetto
Aggiornamento a:
• Change log delle richieste di modifica
(tracciatura attività)
• PMP aggiornato
• Documenti di progetto aggiornati
• Work Performance report (DIKW)
Project management Plan
• Tecniche di analisi (regressione,
trend, varianza, simulazioni, …)
• Interviste, riunioni
• Esperti
• PM information system
• Richieste di modifica da approvare
• WPR
• EEF
• OPA
Richieste di modifica approvate

29. È l’insieme delle attività necessarie per la chiusura amministrativa del progetto o di
una sua fase, incluse le metodologie step-by-step che interessano le attività
necessarie per :
• soddisfare i criteri di completamento o di uscita per la fase o il progetto;
• trasferire i prodotti, servizi o risultati del progetto alla fase successiva o alla
produzione e/o attività operative;
• raccogliere gli archivi relativi al progetto o a una fase, verificare il successo o il
fallimento del progetto, riunire le lesson learned e archiviare le informazioni di
progetto per l’uso futuro da parte dell’organizzazione.
4.6 Chiudere il progetto o una sua fase
Deliverables di progetto o di fase
consegnati
Chiudere il
progetto o una
sua fase • PMP finale
• Documenti di progetto finali
• Change log richieste di modifiche
(tracciatura attività)
• Asset aziendali aggiornati (DB, KMS, …)
• Work wisdom (DIKW)
• Project management Plan
• Tecniche di analisi
• Interviste, riunioni
• Esperti
• PM information system
• Delivarable di progetto o fase accettati
• OPA

30. Avvio
• Strategia
aziendale
• Studio di
fattibilità
• Analisi
costi/benefici
• Business Plan
• Definizione
obiettivi
Progettazione
• Scope
• Tempi
• Costi
• Qualità
• Risorse
• Comunicazione
• Rischi
• Approvvigionam
enti
• Stakeholders
Esecuzione
Rilevazione
• Tempi effettivi
• Costi effettivi
Consolidamento
• Approvazione
dati
• Inserimento dati
Verifica
• Analisi degli
scostamenti
• Analisi cause
• Analisi rischi
Ripianificazione
• Attuazione
correttivi
• Nuove stime a
finire
Controllo
Chiusura
• Esame critico dei
risultati
• Storicizzazione
• Adeguamento
degli standard
TEMPO
T0 - INIZIO T FINE
Project CHARTER Project PLAN DELIVERABLES

31. Applicazione del modello di conoscenza DIKW
Processo Data - D Information - I Knowledge
(report)- K
Wesdom -W
4.6 Chiudere il progetto o una sua
fase
aggiornamento asset (OPA)
Lesson learned
4.5 Eseguire il controllo integrato e
gestione delle comunicazioni
colleziona le informazioni grezzi in
report autoconsistenti di
comunicazione e di diffusione dei
risultati
Rappresentazione
in documenti
autoconsistenti:
• note
informative
• rapporti,
• report,
• …
4.4 Monitorare e controllare il
lavoro di progetto:
colleziona i dati grezzi in
informazioni strutturate e
correlate alle aree di conoscenza
Work Performance
Information (WPI):
• stato completamento
fase,
• previsioni di
completamento,
• …
4.3 Dirigere e gestire i lavori:
preleva dati da
• ambito
• tempi
• costi
• risorse
• qualità
• rischi
• comunicazione,
• Approvvigionamento
• stakeholders
Rilevazione dati
grezzi:
• Date inizio fine
• n. modifiche
• n. difetti
• durate effettive
• costi effettivi,
• …