Project-End Report e Lessons Learned in PM²: chiudere con evidenze e conoscenza riutilizzabile
Trentesimo articolo della serie “Imparare PM² attraverso un progetto”
Un progetto non è realmente chiuso quando l’ultima funzionalità è in produzione o quando il team smette di lavorarci. La chiusura richiede una lettura esplicita di ciò che è stato consegnato, di ciò che resta aperto, delle decisioni prese e di ciò che l’organizzazione può imparare.
In PM², il Project-End Report documenta l’esito del progetto; le Lessons Learned trasformano esperienza, errori e pratiche efficaci in apprendimento utile per progetti futuri. Sono artefatti distinti, ma entrambi servono a chiudere con responsabilità e non perdere valore.
Closing: il contesto dei due artefatti
Alla fine di Executing, il gate RfC — Ready for Closing autorizza l’ingresso in Closing. In questa fase si svolgono review finale, transizione, chiusura amministrativa e raccolta dell’apprendimento. Solo dopo queste attività il progetto può essere dichiarato concluso.
flowchart LR
A[Deliverable completati e accettati] --> B[RfC]
B --> C[Review finale e Lessons Learned]
C --> D[Project-End Report]
D --> E[Handover, azioni residue e chiusura amministrativa]
E --> F[Project Ended]
Il Project-End Report non è un passaggio decorativo verso Project Ended: è una sintesi verificabile che consente alla governance di capire cosa è successo, quali impegni proseguono e se la chiusura è corretta.
A cosa serve il Project-End Report
Il Project-End Report risponde a domande che, dopo la dispersione del team, diventano difficili o impossibili da ricostruire:
| Domanda | Perché conta |
|---|---|
| Quali deliverable sono stati consegnati e accettati? | Conferma l’esito rispetto allo scope. |
| Quali obiettivi sono stati raggiunti e con quali scostamenti? | Rende trasparente la performance del progetto. |
| Quali costi, tempi, rischi e issue hanno inciso? | Spiega differenze fra baseline, forecast ed esito. |
| Cosa rimane aperto e chi ne è owner? | Evita che azioni post-progetto restino senza responsabilità. |
| Come avviene handover e supporto? | Collega il progetto all’operatività. |
| Quali lesson devono essere riutilizzate? | Conserva conoscenza per il futuro. |
Non è un esercizio per dimostrare che tutto è andato bene. Un report credibile documenta anche ritardi, scope differito, costi maggiori e problemi, collegandoli a fatti, decisioni e impatti.
Struttura pratica del report
Il livello di dettaglio dipende da dimensione, rischio e obblighi del progetto. Una struttura solida comprende:
| Sezione | Contenuto |
|---|---|
| Executive summary | Obiettivo, esito generale, risultati principali e punti da portare alla governance. |
| Deliverable e acceptance | Cosa è stato consegnato, accettato, differito o escluso; eventuali deroghe. |
| Performance | Confronto fra baseline, principali forecast e risultato per scope, tempi, costi/effort e qualità. |
| Benefici e business implementation | Stato dell’adozione, misure disponibili, owner dei benefici e azioni post-progetto. |
| Rischi, issue, change e decisioni | Elementi che hanno avuto impatto e come sono stati gestiti. |
| Transition e handover | Supporto, documentazione, proprietà operativa, contratti e condizioni residue. |
| Azioni residue | Owner, scadenze, criterio di completamento e canale di monitoraggio. |
| Lessons Learned | Riferimento alle lesson raccolte e alle azioni di miglioramento. |
L’errore è trasformarlo in una copia di tutti i log. Il report sintetizza il significato degli eventi e rimanda alle evidenze dettagliate quando necessario.
Lessons Learned: non solo “cosa è andato storto”
Una lesson utile non è una frase generica come “comunicare meglio” o “testare prima”. Deve collegare contesto, evidenza, effetto e pratica futura.
| Elemento | Esempio |
|---|---|
| Contesto | Integrazione con provider di notifiche in un rilascio mobile. |
| Osservazione / evidenza | I test end-to-end sono stati fatti solo a ridosso del go-live. |
| Effetto | Un difetto Android ha ridotto il margine e generato fallback urgente. |
| Lesson | Per dipendenze esterne critiche, eseguire test end-to-end su dispositivi rappresentativi entro una milestone definita. |
| Azione riutilizzabile | Aggiungere la verifica al template del Work Plan e assegnare un owner. |
La lesson non deve cercare colpevoli. Cerca di migliorare il sistema di lavoro: informazioni disponibili, processo, ruoli, strumenti, decisioni, competenze e condizioni organizzative.
Raccogliere lesson durante il progetto
Aspettare la riunione finale fa perdere dettagli e favorisce ricordi selettivi. PM² considera le Lessons Learned un’attività che può raccogliere evidenze lungo tutto il ciclo di vita, per poi consolidarle in Closing.
| Momento | Domanda utile |
|---|---|
| Dopo un gate o una milestone | Che cosa ha permesso o ostacolato il passaggio? |
| Dopo un issue rilevante | Quale segnale o controllo avrebbe potuto anticiparlo? |
| Dopo un rilascio o un test | Che cosa ha funzionato e cosa va standardizzato? |
| Durante Closing | Quali pattern, non singoli episodi, meritano un’azione futura? |
Un Lessons Log leggero, aggiornato durante il progetto, rende la review finale più concreta e meno dipendente dalla memoria.
La review finale: fatti prima delle opinioni
La Project-End Review Meeting dovrebbe coinvolgere le persone che hanno una prospettiva utile: business, soluzione, utenti chiave, PM e, dove appropriato, supporto o fornitori.
La discussione funziona meglio se parte da evidenze:
- deliverable e criteri di acceptance;
- milestone e scostamenti;
- trend di rischi, issue e change;
- misure di qualità e adozione;
- feedback di utenti e stakeholder;
- confronto con obiettivi e benefici attesi.
Poi si passa alle cause e alle azioni. “Abbiamo avuto problemi di comunicazione” è troppo generico; “le decisioni del PO non avevano una scadenza e hanno bloccato tre attività sul percorso critico” è una diagnosi su cui si può agire.
Il caso Annotatio: chiudere Prenotazioni Smart
Alla chiusura di Prenotazioni Smart, il Project-End Report può riportare:
| Area | Esito |
|---|---|
| Deliverable | Prenotazione, cancellazione e lista d’attesa accettate; dashboard rinviata alla release successiva con change approvata. |
| Tempi | Go-live il 7 luglio invece del 30 giugno, a causa dell’issue Android e della disponibilità tardiva per acceptance. |
| Costi / effort | +10% effort, entro la tolleranza approvata; nessun costo esterno aggiuntivo. |
| Qualità | Flusso principale e concorrenza testati; fallback email attivato temporaneamente. |
| Transition | Supporto operativo assegnato, guida disponibile, hypercare di due settimane completato. |
| Benefici | Dopo due settimane, 85% delle prenotazioni gestite in Annotatio; misurazione no-show prosegue con owner BM. |
| Azioni residue | Correggere le push Android entro la prossima release; realizzare dashboard CSV/occupazione come change pianificata. |
Due Lesson possibili:
| Osservazione | Lesson e azione |
|---|---|
| Test push effettuati troppo tardi. | Inserire test end-to-end su dispositivi reali prima della milestone di readiness; owner tecnico. |
| Disponibilità del gestore per acceptance confermata tardi. | Inserire la finestra di acceptance come dipendenza vincolante nel Work Plan già in Planning; owner PM/BM. |
Questo report non dice “il progetto è stato un successo” o “un fallimento” in astratto. Mostra risultati, scostamenti, decisioni e responsabilità residue in modo che la governance possa chiudere consapevolmente.
Azioni post-progetto: chiudere non significa abbandonare
Alcune azioni possono continuare dopo la chiusura: misurazione benefici, evoluzioni non incluse, correzioni accettate con deroga, audit, rinnovi contrattuali o follow-up di adozione.
Per ogni azione post-progetto, il report dovrebbe indicare:
| Elemento | Domanda |
|---|---|
| Owner | Chi ne risponde dopo che il team di progetto è sciolto? |
| Scadenza | Entro quando deve essere completata o riesaminata? |
| Risorse / budget | Da quale operatività o iniziativa saranno sostenuti? |
| Monitoraggio | In quale forum o strumento verrà seguita? |
| Criterio di completamento | Come si dimostra che l’azione è conclusa? |
Senza questi elementi, “lo faremo dopo” trasferisce semplicemente un rischio non governato fuori dal progetto.
Da non confondere
| Affermazione | Correzione |
|---|---|
| “Il Project-End Report è una formalità amministrativa.” | Documenta esito, scostamenti, handover, azioni residue e responsabilità di chiusura. |
| “Le lesson servono a elencare gli errori.” | Servono a trasformare osservazioni in pratiche o azioni riutilizzabili. |
| “Si raccolgono lesson solo alla fine.” | Vanno raccolte durante il progetto e consolidate in Closing. |
| “Un’azione post-progetto può restare nel report senza owner.” | Senza owner, scadenza e monitoraggio non è gestita. |
Tre domande per fissarlo
- Quale confronto fra baseline e risultato finale deve essere trasparente nel Project-End Report?
- Quale evidenza trasforma un episodio in una lesson riutilizzabile?
- Chi possiede le azioni e i benefici quando il progetto è ufficialmente chiuso?
Flashcard
D: A cosa serve il Project-End Report?
R: A sintetizzare esito, deliverable, performance, handover, azioni residue, benefici e apprendimento necessari per chiudere correttamente il progetto.
D: Che cosa rende utile una lesson learned?
R: Contesto, evidenza, effetto, pratica futura concreta e, se necessario, azione/owner per riutilizzarla.
D: Perché le lesson vanno raccolte durante il progetto?
R: Per non perdere dettagli e per correggere pratiche già nel progetto in corso, non solo nei futuri.
Domanda in stile esame
Durante la chiusura, il PM archivia i log e scrive: “Il progetto è terminato con qualche ritardo; occorre comunicare meglio in futuro.” Non indica deliverable differiti, owner del supporto o azioni residue.
Qual è la correzione principale?
Risposta: il Project-End Report deve documentare l’esito rispetto a scope, tempi, costi, qualità e handover, assegnando le azioni residue. Le Lessons Learned devono essere specifiche e azionabili, ad esempio collegando ritardi a cause osservabili e a una pratica futura con owner.
Fonte
Project-End Review Meeting, Lessons Learned, Project-End Report e Administrative Closure sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.
Con questo articolo si completa il percorso sugli artefatti essenziali PM². Il passo successivo più utile è una raccolta finale di mappe mentali, quiz e casi integrati per consolidare la preparazione alla certificazione.