10. Closing Process Group
Indice
Obiettivo del Closing Process Group
Definizione
Il Closing Process Group raccoglie le attivita necessarie per chiudere il progetto in modo definito, ordinato e formalmente accettato dal committente.
In pratica: la chiusura non consiste solo nel “finire il lavoro”. Serve verificare che il deliverable sia accettato, installato, documentato e che il progetto lasci traccia utile per il futuro.
Il modulo insiste su un punto centrale: una chiusura efficace dipende da procedure gia definite prima, soprattutto nella fase di planning. Se i criteri di accettazione sono chiari, il momento finale puo seguire un processo ordinato.
Note
La chiusura del progetto e un processo di routine solo dopo che il committente ha approvato il deliverable, eventualmente tramite collaudo.
Tools, Template e Processi
Definizione
Gli strumenti di chiusura sono i supporti operativi che permettono di completare il progetto senza ambiguita e con evidenze documentate.
Per ottenere una chiusura ordinata sono utili:
- Strategie di implementazione: stabiliscono come portare in esercizio il deliverable.
- Procedure di collaudo: certificano il rispetto dei criteri stabiliti.
- Documentazione di progetto: conserva informazioni tecniche, gestionali e storiche.
- Audit post-implementazione: verifica risultati, metodo e lezioni apprese.
- Rapporto finale di progetto: sintetizza esito, performance, approccio e raccomandazioni.
Esempio pratico: prima del go live di un deliverable, servono criteri di accettazione, strategia di installazione, documentazione aggiornata e report finale firmato.
Chiudere il Progetto
Definizione
Chiudere il progetto significa completare formalmente le attivita finali dopo l’approvazione del committente e l’eventuale collaudo.
I passi indicati dalle slide sono:
- Ottenere l’accettazione formale del deliverable.
- Assicurarsi che tutti i deliverable siano stati installati.
- Assicurarsi che tutta la documentazione necessaria sia disponibile.
- Ottenere la firma del committente sul report finale.
- Condurre l’audit post-implementazione.
- Celebrare la fine del progetto, auspicabilmente con successo.
In pratica: non basta aver completato il deliverable. Bisogna ottenere l’accettazione formale, verificare installazione e documentazione, completare audit e report finale.
Tip
La chiusura e piu semplice quando i criteri di successo e accettazione sono stati definiti prima, non quando il progetto e ormai finito.
Procedure di Accettazione
Definizione
Una procedura di accettazione stabilisce come il committente verifica e approva formalmente il deliverable prodotto dal progetto.
Una procedura chiara evita fraintendimenti e riduce il rischio di scoprire problemi solo alla chiusura. I criteri di accettazione devono essere definiti con il committente durante la fase di planning.
Durante l’esecuzione, il team deve controllare che il deliverable possa soddisfare questi criteri. Il collaudo serve proprio a certificare il rispetto di quanto stabilito.
Punto Critico
Se i criteri di accettazione non sono chiari, la chiusura puo trasformarsi in un momento conflittuale: il team pensa di aver finito, ma il committente potrebbe non essere soddisfatto.
Esempio pratico: il collaudo serve a certificare che il deliverable rispetti i criteri di accettazione stabiliti con il committente.
Installare la Soluzione
Definizione
Installare la soluzione significa portare il deliverable accettato nell’ambiente in cui potra essere usato, fino al go live.
Le slide presentano quattro approcci di installazione. La scelta dell’approccio influenza il rischio, la gradualita e il modo in cui si passa dalla vecchia soluzione alla nuova.
Phased Approach
Il Phased Approach decompone il deliverable in parti sviluppate e consegnate in sequenza.
In pratica: invece di consegnare tutto insieme, si procede per fasi. Ogni parte viene completata e consegnata prima di passare alla successiva.
By Business Unit Approach
Il By Business Unit Approach installa il deliverable in una business unit alla volta. Una variante simile prevede l’installazione progressiva per aree geografiche.
In pratica: la nuova soluzione viene introdotta in una parte dell’organizzazione, poi estesa progressivamente alle altre.
Cut-Over Approach
Il Cut-Over Approach prevede la sostituzione immediata del vecchio deliverable con il nuovo.
Attenzione
Questo approccio richiede che l’ambiente di test sia identico all’ambiente di produzione.
In pratica: e il passaggio netto. Da un certo momento in poi si smette di usare la vecchia soluzione e si usa solo quella nuova.
Parallel Approach
Il Parallel Approach installa il nuovo deliverable mentre la vecchia soluzione resta operativa. Le due soluzioni funzionano simultaneamente fino alla verifica del corretto funzionamento della nuova.
In pratica: si riduce il rischio mantenendo una forma di continuita. La vecchia soluzione rimane disponibile finche la nuova non dimostra di funzionare correttamente.
Documentare il Progetto
Definizione
Documentare il progetto significa raccogliere e mantenere le informazioni necessarie per comprendere, modificare, riusare e valutare il lavoro svolto.
Le slide sottolineano che documentare e una delle attivita piu difficili e faticose da completare, ma anche una delle piu utili.
La documentazione serve per:
- Apportare modifiche future al deliverable.
- Permettere il riuso di alcune parti.
- Fornire dati storici per stimare tempi, costi e rischi nei progetti futuri.
- Supportare il training di nuovi project manager.
- Supportare il training e la crescita professionale del team.
- Fornire input per la valutazione delle performance dei membri del team da parte del functional manager.
Note
La documentazione e una sorgente di dati storici per stimare tempi, costi e rischi nei progetti futuri.
Project Notebook
Definizione
Il Project Notebook e la raccolta ordinata dei documenti principali prodotti e usati durante il progetto.
Secondo le slide, puo comprendere:
- POS.
- RBS, comprese tutte le revisioni.
- Proposta.
- Schedule del progetto, sia originale sia corretta.
- Appunti e verbali di tutti i project team meeting.
- Copia di tutti gli status report.
- Documentazione relativa al design.
- Eventuali prototipi o sample realizzati.
- Copia di tutti gli avvisi di modifiche.
- Copia di tutte le comunicazioni scritte.
- Report delle questioni rimaste in sospeso.
- Rapporto finale.
- Documenti di accettazione del committente.
- Rapporto dell’audit post-implementazione.
Tip
Il Project Notebook deve iniziare dal primo giorno di progetto, non alla fine. Ricostruire tutto a posteriori e piu difficile e meno affidabile.
Post-Implementation Audit
Definizione
Il Post-Implementation Audit e la verifica successiva all’implementazione che valuta risultati, soddisfazione del committente, rispetto dei vincoli e qualita della metodologia di gestione.
L’audit serve a capire se il progetto ha davvero prodotto il valore atteso e se il modo in cui e stato gestito puo insegnare qualcosa per i progetti futuri.
Domande Guida dell’Audit
Le slide propongono alcune domande chiave:
- Gli obiettivi del progetto sono stati raggiunti?
- Il deliverable fa quello che il team aveva previsto?
- Il deliverable fa quello che il committente si aspettava?
- Il progetto e stato completato rispettando tempo, budget e specifiche?
- Il committente e soddisfatto del risultato?
- Il business value previsto si e concretizzato?
- I criteri di successo sono stati rispettati?
- Che lezione e stata imparata rispetto alla metodologia di gestione scelta?
- Come ha seguito la metodologia il team?
In pratica: l’audit non guarda solo al prodotto finale, ma anche al processo con cui ci si e arrivati.
Perche l’Audit non Viene Svolto
Ostacoli Ricorrenti
L’audit post-implementazione puo essere trascurato per ragioni organizzative, economiche o di priorita.
Le ragioni indicate sono:
- I manager non vogliono sapere cosa e avvenuto durante il progetto.
- I manager non vogliono pagare il costo dell’audit.
- L’audit non e percepito come attivita ad alta priorita.
- C’e molto altro lavoro da fare su altri progetti.
Esempio pratico: se c’e molto altro lavoro da fare su altri progetti, l’audit puo non essere percepito come attivita ad alta priorita.
Final Project Report
Definizione
Il Final Project Report e il documento finale che sintetizza risultati, performance, gestione, tecniche utilizzate, valutazione dell’approccio e raccomandazioni.
Secondo le slide, il rapporto finale include:
- Executive Summary.
- Livello di successo e performance complessive del progetto.
- Organizzazione e amministrazione del progetto.
- Tecniche impiegate per raggiungere il risultato.
- Pregi e difetti dell’approccio utilizzato, sia dal punto di vista architetturale sia di gestione del progetto.
- Raccomandazioni.
- Appendici.
Le appendici possono includere:
- POS.
- WBS.
- Schedulazione delle risorse.
- Richieste di cambiamenti.
- Deliverable finali.
- Altro materiale rilevante.
Note
Il report finale e anche il punto in cui la chiusura diventa formale: il committente firma il documento e il progetto lascia una traccia strutturata.
Celebrare la Fine del Progetto
Definizione
Celebrare la fine del progetto significa riconoscere formalmente la conclusione del lavoro e il contributo delle persone coinvolte.
Nelle slide questo passaggio chiude il processo di closing. Non aggiunge un nuovo deliverable, ma segnala che il progetto e terminato e che il team puo riconoscere il risultato raggiunto.
In pratica: dopo accettazione, installazione, documentazione, audit e report finale, la celebrazione segna la conclusione del progetto.
Prossimi Argomenti
Con questo modulo si chiude il percorso sui process group del project management.
Per collegare la chiusura del progetto al lavoro pratico, riprendere le linee guida e i documenti di progetto disponibili nella cartella del corso, in particolare Slide e informazioni del corso.