Parte V — Closing Process Group · Capitolo 17

Closing: chiusura, collaudo e report finale

~40 min di lettura4 widget interattivi4 tavole

In questo capitolo

  1. Strumenti, template e processi per chiudere
  2. Chiudere il progetto: i passi
  3. Le procedure di accettazione del committente
  4. Installare la soluzione: quattro approcci
  5. Documentare il progetto: il Project Notebook
  6. L'audit post-implementazione
  7. Scrivere il Final Project Report
  8. Celebrare la fine del progetto
  9. Verifica le tue conoscenze

1. Strumenti, template e processi per chiudere

Per ottenere che la chiusura del progetto sia «un processo ben definito e ordinato» il corso elenca cinque strumenti, template e processi:

Il collegamento con il capitolo 16

Il Closing non parte da zero: si entra in questa fase solo quando i criteri di accettazione sono soddisfatti (capitolo 16, sezione 11). Qui si impara a rendere quel passaggio un processo ordinato e documentato.

2. Chiudere il progetto: i passi

«Dopo aver ottenuto l'approvazione del committente, a fronte di un eventuale collaudo, la chiusura di un progetto è un processo di routine» che prevede sei passi:

  1. ottenere l'accettazione formale del deliverable;
  2. assicurarsi che tutti i deliverable siano stati installati;
  3. assicurarsi che tutta la documentazione necessaria sia disponibile;
  4. ottenere la firma del committente sul report finale;
  5. condurre l'audit post-implementazione;
  6. celebrare la fine (con successo... si spera) del progetto.
Chiudere il progetto: sei passi di routine 1 · Accettazione formale del deliverable 2 · Deliverable tutti installati 3 · Documentazione necessaria disponibile 4 · Firma del committente sul report finale 5 · Audit post- implementazione 6 · Celebrare la fine del progetto La celebrazione chiude il ciclo: è l'ultimo passo, «con successo... si spera». La freccia scende dal passo 5 al passo 6.
Tavola 17.1 — I sei passi della chiusura: dall'accettazione formale del deliverable alla celebrazione finale.

3. Le procedure di accettazione del committente

Perché è necessaria una procedura di accettazione da parte del committente? Il corso dà cinque risposte:

Per l'esame — il filo dei capitoli 7 e 16

I criteri di accettazione nascono nel planning (con il committente), vengono verificati nel monitoring (capitolo 16) e certificati qui dal collaudo. È lo stesso principio del POS e dei success criteria del capitolo 7: prima si definisce insieme, poi si misura insieme.

4. Installare la soluzione: quattro approcci

Una volta accettato il deliverable si può procedere all'installazione per effettuare il «go live». Il corso presenta quattro approcci:

Quattro approcci per il «go live» Phased parti in sequenza By Business Unit una BU alla volta Cut-Over sostituzione immediata vecchio nuovo Parallel affiancamento vecchio nuovo Il cut-over richiede che l'ambiente di test sia identico a quello di produzione; il parallel mantiene il vecchio operativo finché il nuovo non è verificato.
Tavola 17.2 — I quattro approcci di installazione: phased, by business unit, cut-over e parallel. Il cut-over è l'unico che richiede un ambiente di test identico alla produzione.

Quale approccio di installazione?

Quattro situazioni. Per ciascuna scegli l'approccio indicato dal corso, poi verifica.

5. Documentare il progetto: il Project Notebook

«Documentare il progetto è una delle attività più difficili e "faticose" da completare» — ma il corso dà cinque valide ragioni per farlo:

Il contenuto del Project Notebook

Il corso raccoglie tutto nella metafora del Project Notebook, che «bisogna iniziare dal primo giorno di progetto». Il suo contenuto è la memoria completa del progetto:

Che cosa finisce nel Project Notebook?

Dieci voci. Scegli Sì se il corso la elenca tra i contenuti del Project Notebook, No altrimenti; poi verifica.

6. L'audit post-implementazione

L'audit post-implementazione risponde a domande sulla riuscita complessiva del progetto:

Il corso elenca anche le ragioni per cui l'audit non viene svolta:

Perché l'audit non viene svolta?

Sei affermazioni. Scegli Sì se il corso la elenca tra le ragioni per cui l'audit post-implementazione non viene svolta, No altrimenti; poi verifica.

7. Scrivere il Final Project Report

Il Final Project Report è il documento che il committente firma come ultimo atto della chiusura. Il corso ne definisce la struttura — cliccate su ogni riga per la spiegazione:

Nota del redattore

Le appendici sono la spina dorsale del report: POS, WBS, schedulazione delle risorse, richieste di cambiamenti e deliverable finali. È lo stesso materiale del Project Notebook, riorganizzato per chi deve decidere e firmare.

8. Celebrare la fine del progetto

L'ultimo passo della chiusura è celebrare la fine del progetto. Il corso la mette esplicitamente nella sequenza di routine della chiusura: non è un extra, è parte del processo — chiudere bene un progetto significa anche riconoscere il lavoro svolto dal team.

Il filo rosso del corso

Con la celebrazione si chiude il ciclo dei process group: scoping (capitoli 6–7), planning (8–11), launching (12–15), monitoring & controlling (16) e closing (questo capitolo). Nel capitolo 19 torneremo su tutto il percorso con il caso di studio PDQ e le linee guida dell'elaborato d'esame.

Verifica le tue conoscenze

Quali sono i sei passi della chiusura di un progetto?

Ottenere l'accettazione formale del deliverable; assicurarsi che tutti i deliverable siano installati; assicurarsi che la documentazione necessaria sia disponibile; ottenere la firma del committente sul report finale; condurre l'audit post-implementazione; celebrare la fine del progetto.

Perché è necessaria una procedura di accettazione del committente?

Evita fraintendimenti e problemi scoperti alla chiusura; i criteri di accettazione si definiscono con il committente nel planning; in esecuzione il team verifica che il deliverable li soddisfi; il collaudo certifica il rispetto dei criteri; se i criteri sono soddisfatti, il committente non può che essere contento.

Quali sono i quattro approcci di installazione della soluzione?

Phased (parti sviluppate e consegnate in sequenza); By Business Unit (una business unit alla volta, o per aree geografiche); Cut-Over (immediata sostituzione, richiede ambiente di test identico alla produzione); Parallel (il nuovo affianca il vecchio finché non è verificato).

Perché conviene documentare il progetto?

Riferimento per modifiche future e riuso; sorgente di dati storici per le stime dei progetti futuri; training di nuovi PM; crescita professionale del team; input per la valutazione delle performance da parte del functional manager.

Quando va iniziato il Project Notebook?

Dal primo giorno di progetto (NOTA delle slide): raccoglie POS, RBS con revisioni, proposta, schedule originale e correzioni, verbali dei meeting, status reports, design, prototipi, avvisi di modifiche, comunicazioni scritte, questioni in sospeso, report finale, accettazioni e audit.

Quali domande affronta l'audit post-implementazione?

Se gli obiettivi sono stati raggiunti (deliverable come previsto dal team e come atteso dal committente); se il progetto ha rispettato tempo, budget e specifiche; se il committente è soddisfatto; se il business value si è concretizzato e i criteri di successo sono stati rispettati; che lezione è stata imparata sulla metodologia scelta e su come l'ha seguita il team.

Quali sono le ragioni per cui l'audit non viene svolta?

I manager non vogliono sapere cosa è avvenuto; non vogliono pagare il costo dell'audit; l'audit non è percepita come prioritaria; c'è molto altro lavoro da fare su altri progetti.

Qual è la struttura del Final Project Report?

Executive Summary; livello di successo e performance complessive; organizzazione e amministrazione del progetto; tecniche impiegate; pregi e difetti dell'approccio; raccomandazioni; appendici (POS, WBS, schedulazione delle risorse, richieste di cambiamenti, deliverable finali, altro).