Come Condurre un Retrospettiva Efficace e Applicare le Lezioni Apprese ai Progetti Futuri

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un software. Per favore, perdonate eventuali errori di battitura, il bot non è preciso al 100%.

Galen Low: Ciao a tutti, grazie per l'ascolto. Mi chiamo Galen Low e sono con The Digital Project Manager. Siamo una community di professionisti digitali con la missione di aiutarci a vicenda a sviluppare competenze, acquisire sicurezza e connettersi per aumentare il valore della gestione dei progetti nel mondo digitale. Se vuoi saperne di più, visita thedigitalprojectmanager.com.

Oggi parliamo di retrospettive di progetto: come condurle efficacemente e come garantire che le lezioni apprese si trasformino davvero in miglioramenti per i progetti futuri.

Con me oggi c’è Payson Hall, fondatore e consulente principale di Catalysis Group, che aiuta le organizzazioni a imparare dagli errori di progetto da oltre 30 anni.

Payson, è davvero un piacere averti con noi.

Payson Hall: Ciao, felice di esserci e di conoscere il pubblico.

Galen Low: Sì, in effetti sono contento che tu l’abbia menzionato perché oggi facciamo qualcosa di un po’ diverso. Siamo in diretta con i nostri membri che fanno da pubblico in studio. Prenderemo domande al volo tramite la nostra community su Slack. Con me in studio anche Michael, che raccoglierà alcune di queste domande. Le integreremo nella conversazione: tutto può succedere. Pronti a renderla vivace.

D’accordo, tuffiamoci subito. Vorrei iniziare con una domanda stimolante perché abbiamo parlato a lungo di questo, e tu hai condotto retrospettive di progetto come consulente per decenni su ogni tipo di progetto, inclusi progetti software e grandi integrazioni di sistemi. Voglio chiederti: quando entri come consulente esterno per far emergere tutti i piccoli segreti nascosti di un progetto, i team di progetto ti vedono come un amico o un nemico? È come ricevere una mentorship? O si sente come essere sottoposti a un audit?

Payson Hall: Di solito è uno scambio amichevole. Vorrei fare una distinzione, perché in una parte del mio lavoro, faccio autopsie di progetto. Se un progetto va davvero fuori strada e c’è il sospetto che qualcuno sapesse e non abbia detto nulla, quello è molto più simile a un audit.

In effetti, lavoro con un revisore statale in California e ho fatto audit su progetti IT da miliardi di dollari. In quel caso, spesso l’obiettivo è raccogliere elementi probatori per permettere agli avvocati di agire contro un system integrator. Una retrospettiva più comune e amichevole è invece quando il team dice: "Abbiamo concluso questo progetto. Facciamo venire qualcuno a facilitare uno sguardo al passato." Questa è la retrospettiva: uno sguardo indietro su cosa abbiamo imparato, su cosa abbiamo fatto di ingegnoso, magari senza accorgercene, e cosa in retrospettiva avremmo fatto diversamente. È davvero una sessione di gestione dei rischi, guardando nello specchietto retrovisore: Cosa posso migliorare la prossima volta? Cosa invece era ingegnoso e voglio ripetere.

Galen Low: Mi piace molto questa distinzione, perché penso che chi ascolta magari non la senta molto: ogni retrospettiva sembra un’autopsia, come se si dovessero raccogliere prove o attribuire colpe, anziché ragionare – come dici tu – in modo costruttivo sugli errori.

Payson Hall: Una delle poche regole grandi e importanti sulle retrospettive è che, nonostante ci siano molti modi per gestirle, il project manager non dovrebbe mai gestire la retrospettiva del proprio progetto. Alcune delle cose che non hanno funzionato sono collegate proprio al project manager. Un buon facilitatore evita che il responsabile venga "inchiodato", ma si concentra su cosa è accaduto, quando e cosa si è imparato. Non: "Galen, hai commesso un errore!"

Questo non è costruttivo. Porta le persone sulla difensiva. Quindi è meglio portare qualcuno dall’esterno, o, se credi in una persona interna che sia un bravo facilitatore e non coinvolta nel progetto, va bene. È importante che sia neutrale, così non si finisce con troppo "sangue sul pavimento" quando si conclude.

Galen Low: Vero. E trovo interessante anche questa prospettiva: molti aprono una retrospettiva per capire come gestirla da soli.

E so che spesso è la realtà di molti team, quindi parleremo anche di consigli pratici che hai acquisito. Ma il tuo suggerimento è fondamentale: se possibile, scegli sempre qualcun altro come facilitatore, per evitare che la retrospettiva diventi una caccia al colpevole. Non deve esserci sangue sparso ovunque a fine incontro.

Payson Hall: E qualcuno che porti presupposti diversi. Pensaci: durante un progetto, hai sviluppato convinzioni sulle cause delle difficoltà. Potresti aver ragione o torto. Qualcuno da fuori, senza quei pregiudizi, saprà ascoltare informazioni diverse.

Galen Low: Amo questa prospettiva esterna, specie su progetti lunghi dove la vicinanza impedisce di vedere la foresta per gli alberi.

Andiamo alle basi: puoi spiegare dal tuo punto di vista cos’è una retrospettiva di progetto e perché vale la pena farla?

Payson Hall: Ottima domanda. Una retrospettiva, come parola, significa guardare indietro. L’idea è che arriviamo a un momento significativo del progetto o alla sua fine e ci fermiamo: cosa abbiamo imparato in questa fase? Quali lezioni vogliamo applicare al prossimo segmento o progetto?

Cosa abbiamo fatto per caso in modo furbo? Oppure: cosa avremmo cambiato se avessimo potuto? È proprio fermarsi, guardare con il giusto contesto agli eventi del progetto. Come hai detto tu, allargare lo sguardo per capire cosa conta davvero. Alcune cose sono cigni neri, eventi imprevisti – come il Covid – e magari non ci prepareremo mai a una pandemia nei prossimi progetti, ma se ti ha colpito, qualcosa da imparare c’è sempre.

Oppure, magari avevi bisogno di 12 portatili e ne hai ordinati 14 per sicurezza. Uno era difettoso e, grazie alla scorta, hai evitato un ritardo. Ecco una grande lezione appresa: richiedere la possibilità di restituire quelli in più se non aperti. Magari sono mille euro ben spesi che salvano tre settimane di fermo. Chi lavora su hardware negli ultimi anni conosce bene queste dinamiche con le catene di fornitura in crisi.

Galen Low: Sì, ottimo esempio. E fondamentale ricordare che le retrospettive non servono solo ad analizzare gli errori: è un buon momento anche per fissare ciò che ha funzionato davvero.

A volte si pensa solo alle cose negative, ma anche le soluzioni brillanti, come quando hai prenotato una sala extra ed è saltata la principale – questi sono trucchi da includere nei processi futuri. E alla fine, metterlo anche nel contratto: se ordino un portatile extra, posso restituirlo se è sigillato.

Un altro punto importante: hai detto che la retrospettiva si può fare sia a fine progetto che in momenti significativi durante il percorso. Non è solo uno sguardo amaro sulla fine, ma c’è spazio per guardare dentro mentre si lavora. Vorrei tornarci tra poco.

Payson Hall: Questo è uno degli aspetti più interessanti degli approcci agili: prevedono una retrospettiva a fine sprint. Su grandi progetti le ho viste periodiche a ogni milestone, ma l’Agile ha cristallizzato il concetto di retrospettiva episodica.

Facendole più spesso diventano più leggere. Il team padroneggia il processo e si agilizza. È stata un’innovazione notevole dell’Agile: retrospettiva a ogni sprint.

Galen Low: Mi piace il cambio di paradigma: possiamo fare questo esercizio più regolarmente, in modo più snello. Faccio l’avvocato del diavolo: molte organizzazioni dicono di voler imparare dagli errori, ma quando si tratta di investire su questo guardare indietro, spesso dicono "abbiamo già imparato lavorando, non serve altro, andiamo oltre!". Qual è il valore concreto di una vera retrospettiva?

Payson Hall: Ottima domanda. Nell’ambito del miglioramento dei processi, serve che il costo dell’apprendimento non superi il suo valore. Esempio reale: ho condotto da poco una retrospettiva con un team di 12 persone su un progetto di 18 mesi. Progetto interno, 12 persone, risultato raggiunto, lieve ritardo accettato, nessun avvocato coinvolto.

La domanda era: abbiamo terminato, cosa abbiamo imparato? Come possiamo fare diversamente? Ogni membro ha speso 4–6 ore tra preparazione e riunione. Io come facilitatore ho impiegato circa 12 ore. Il project manager tra 8 e 12 ore a fornire dati. In totale, la retrospettiva ha richiesto circa due settimane persona.

Se fai il conto su 12 persone e un PM per 18 mesi, sono circa mille settimane persona. Quindi lo 0,2% del tempo investito per uno sguardo indietro. Bastano anche piccoli risparmi, o idee che risparmiano due settimane in futuro, per avere un ritorno positivo. Il valore arriva da raccomandazioni strutturali per il PMO o anche solo dall’apprendimento organico – la prossima volta il team lo applicherà spontaneamente.

Non ho mai visto una retrospettiva senza almeno un ritorno dalle lezioni, raccomandazioni e suggerimenti. Vale sempre il tempo investito.

Galen Low: Giusto. Parliamo di grandi progetti, ma se è un progetto piccolo, tipo quattro settimane? Due settimane di retrospettiva sarebbero eccessive. In questi casi, cosa suggerisci?

Payson Hall: Ci sono errori che anch’io ho fatto all’inizio. Non vuoi mai invitare in retrospettiva persone estranee al team. Per una discussione schietta su cosa ha funzionato, è meglio l’intimità del gruppo. Aggragare persone di progetti diversi non funziona; piuttosto, dopo varie micro-retrospettive, il PMO può confrontare i risultati a livello manageriale.

Per progetti brevi, si può essere informali: un’ora insieme basta, più un po’ di preparazione. Serve solo capire il contesto ed estrarre semplici lezioni.

Galen Low: Già, metodo Agile prevede retrospettiva a ogni sprint – anche semplici e informali. Non serve aspettare la fine per tutto.

Payson Hall: Esatto. Se hai un team di otto, metterli in una stanza per un’ora sono 8 ore. Più un po’ di preparazione, ce la puoi fare in 12 ore totali anche con riassunto di una pagina.

Galen Low: E c’è il costo opportunità: se dedichi un’ora e impari qualcosa che fa risparmiare mezzo milione alla prossima occasione, l’investimento è subito ripagato.

Hai citato progetti interni. Molti che ci ascoltano lavorano in agenzie: il committente non paga per la retrospettiva, e il management la rifiuta perché non è fatturabile. Mi è capitato un CEO entrato e mandato via tutti dalla stanza perché "tempo perso". Come si può convincere la leadership ad investire nel learning di una retrospettiva?

Payson Hall: Voglio essere diplomatico, ma se lavorassi in un’azienda dove si dice che non c’è nulla da imparare dal progetto appena finito, preparerei il curriculum. Scherzi a parte, da consulente in IBM, raramente il cliente paga per la retrospettiva; è l’organizzazione stessa che investe in ottimizzazione e soddisfazione cliente.

Pensa alle tariffe giornaliere: basta risparmiare qualche ora e hai già recuperato. Gli amministrativi non costano quanto la tariffa al cliente, ma se raccogli sei persone per un’ora e si risparmiano quattro giorni la volta successiva, la retrospettiva si è già pagata. Se l’azienda aveva emergenze, capisco il CEO. Ma in generale, in consulenza è un investimento ovvio. Puoi anche iniziare in piccolo: riunione informale durante un pranzo. Quando ero giovane presso Price Waterhouse, i soci facevano colazione con noi staff alle 7 del mattino. Pensavamo fosse un incentivo; loro ci avevano fatti venire due ore prima per una riunione.

Racconta ai manager quando una retrospettiva produce un’idea che ha salvato settimane al progetto successivo. Così li convinci del valore.

Galen Low: Parti in piccolo e raccogli prove: ogni lezione concreta crea valore dimostrabile.

Sovente i decision maker non hanno prove che la retrospettiva generi valore: c’è un progetto in corso e tutti preferiscono le ore fatturabili. Finché non si vede il risultato, la resistenza resta alta.

Payson Hall: Producendo un output (documento o presentazione) puoi mostrare i risultati – anche in versione "sanitizzata" per i vertici. Spesso sono gli stessi manager a causare problemi, ma con dati oggettivi puoi indirizzare comunicazione e comportamento in meglio.

Galen Low: Mi piace questa differenziazione strategica nella comunicazione, magari chi gestisce riceve solo la versione con le lezioni principali.

Payson Hall: Non amo la metafora del "bucato sporco". La persona intelligente assume che tutti abbiano fatto del loro meglio con le informazioni disponibili. Si deve evitare di cercare capri espiatori. Serve un approccio costruttivo: cosa possiamo fare per migliorare la prossima volta?

Galen Low: Concordo. Parliamo del processo: come si struttura una tua retrospettiva tipica su un progetto annuale importante?

Payson Hall: Innanzitutto un incontro uno a uno con il project manager per instaurare fiducia, specie se la mia presenza è stata imposta dall’alto. Spiego il mio metodo: il PM vedrà tutto in anteprima e avrà modo di integrare, correggere, argomentare. Tolgo così pressione e tendenza a nascondere informazioni.

Cerco tutta la documentazione di definizione agli inizi: project charter, cambiamenti di scopo, risk log, status report. Voglio ricostruire il percorso: cos’era previsto, come si è evoluto nel tempo? Tutti i progetti cambiano; le versioni di software si aggiornano, strumenti nuovi si aggiungono.

Esempio: in un progetto annuale, un aggiornamento software esterno ritarda di un mese? La responsabilità non è vostra: la lezione è programmare tempistiche cuscinetto nei futuri progetti simili.

Raccolgo timeline, status report e anomalie: cambio milestone, segnalazioni nei report – tutto in una cronologia da verificare con il PM. Poi chiedo al team di dedicare 60–90 minuti di preparazione: individuare eventi notevoli (matrimoni, figli, aggiornamenti di team), soluzioni furbe (portarsi una telo cerato che ha salvato dal maltempo, ad esempio), imprevisti (malattie, fermo software, risorse chiave indisponibili).

Creo una timeline su un muro: eventi principali, milestones, episodi buffi o impegnativi aiutano anche a fissare la memoria. Si inizia con le ricorrenze “neutre” poi si passa a successi inaspettati, difficoltà, ritardi. A volte il solo ricostruire questo porta a "aha moments", come il cambio di stakeholder che sconvolge la squadra per mesi perché non si è fatta abbastanza onboarding sulla nuova figura (passaggio non banale!).

La timeline visiva stimola il racconto e le riflessioni. A seguire, si fa gestione dei rischi retrospettiva in tre domande: Come potevamo rilevare prima opportunità/rischi/problemi? Cosa potevamo fare per ridurre la probabilità dei problemi o aumentare quella delle buone opportunità? E come ridurre l’impatto delle negatività/esaltare i benefici?

Il risultato è una bozza della relazione finale: cosa si voleva fare, cosa si è ottenuto, costi, tempistiche, meriti, criticità e raccomandazioni pratiche per il futuro (tutto comunque molto sintetico; l’ideale è una pagina o una presentazione snella).

Galen Low: Parliamo di profondità: mentre si ricostruisce la timeline c’è chi arriva con 15-20 punti. Li discutete tutti o soltanto ne prendete atto e poi si approfondiscono in un secondo momento?

Payson Hall: Serve equilibrio: abbastanza tempo per favorire gli "aha moment" ma senza perdere il filo, altrimenti si cade nel dettaglio eccessivo. Se un tema è produttivo, tre-cinque minuti vanno bene, poi si prende nota e si delega un approfondimento offline coi diretti interessati.

Galen Low: Qui entra in gioco la capacità di facilitazione! Anche chi non la esercita direttamente dovrebbe capirla. Non si risolvono tutti i problemi là dentro; si trattano le priorità, il resto va gestito altrove.

Payson Hall: Esatto. Un facilitatore esterno o anche solo esterno al progetto aiuta nell’umiltà e distacco. Anche io da ingegnere sarei tentato di approfondire, ma non sarebbe produttivo. Serve qualcuno che riporti sempre l’attenzione agli obiettivi.

Galen Low: È proprio una prima bozza di report che potrai anche condividere con altri team futuri o con te stesso tra qualche mese senza cadere nel tecnicismo fine a se stesso. Si tratta di priorità.

Hai anche detto che la retrospettiva è gestione dei rischi a posteriori: pochi la collegano. In realtà puoi anche vedere la retrospettiva come messaggio nella bottiglia alle future generazioni di team.

Payson Hall: Proprio così. È fondamentale tenere la discussione sui "cosa" e non sui "chi". Lavoro principale di chi facilita è evitare i colpevoli – bisogna partire dall’assunto che tutti fanno del loro meglio. Solo così si impara davvero.

Racconto: avevo invitato me stesso a una retrospettiva (che errore!). Un membro del team ha rifiutato di partecipare perché temeva di essere colpevolizzato. Il facilitatore effettivamente gestiva male il processo, chiedendo di continuo chi avesse sbagliato. Ma il team si è rifiutato di "scaricare" le colpe, mantenendo la discussione sugli eventi e sulle lezioni. Ho scoperto che c’era una situazione personale delicata (alcolismo) che il team ha protetto senza colpevolizzare nessuno. Massimo rispetto per loro: non puoi sempre contare su gente così stoica e compassionevole. La regola resta: niente turisti, facilitatore esperto e focus su processi e non persone. E se manca una skill, non è colpa dell’individuo, ma di chi pianifica: si segnala che servono competenze migliori, senza puntare il dito.

Galen Low: È tutto nel modo in cui si imposta la retrospettiva. Molti mi chiedono: "Come creo sicurezza psicologica in sessione?". Parte del lavoro va fatto prima, costruendo fiducia e spiegando che ci si concentrerà su cosa e non chi.

Se però in sessione qualcuno inizia ad attaccare?

Payson Hall: Prima volta lo avverti gentilmente: "Qui non si cerca il responsabile, lavoriamo sui fatti". Seconda volta, magari lo prendi da parte. Non è produttivo cercare colpevoli: correggere il passato non è più possibile, ora serve imparare per il futuro.

Galen Low: E se dalle raccomandazioni emerge tra le righe di chi fosse la responsabilità, come si evita che il management legga tra le righe "è colpa di Brett"?

Payson Hall: Questioni personali non finiscono nel report; spettano al PM. Invece, problemi reali di risorse o errori di stima si segnalano come "occorre rafforzare questo aspetto", proponendo approfondimenti o cambiamenti di processo. Il report deve essere diplomatico: il mio obbligo è dire la verità ma in modo costruttivo e non incendiario.

Galen Low: Dopo incontri, timeline condivisa e discussione, il report esce fuori. Ma tanti dicono: la nostra retrospettiva produrrà solo un documento che nessuno leggerà e le cose non cambieranno. Come fai sì che le raccomandazioni producano davvero cambiamenti?

Payson Hall: Il rischio è alto se scrivi una relazione da 30 pagine! Bisogna essere sintetici e selezionare le priorità: scegli due-tre punti chiave da proporre ai vertici. Il resto resta al team come patrimonio informale.

Esiste la leggenda della banca dati delle lezioni apprese a disposizione di tutta l’azienda: mai vista funzionare! La memoria informale e soprattutto la selezione di poche azioni concrete che si ripetono e si consolidano sono la vera spinta al cambiamento.

Esempio: avere una "war room" dedicata fa risparmiare settimane nella ricerca di sale disponibili. Se si suggerisce più volte, alla lunga anche chi decide se ne accorge. Quindi: poche raccomandazioni chiare ai vertici e un sacco di apprendimento organico tra i membri del team.

Galen Low: Ottimo distinguere la comunicazione strategica e il valore della condivisione informale tra pari: il sapere si diffonde anche così, come semi tra i team futuri.

Payson Hall: Esatto. E alla fine, durante la pianificazione, tornando sulle retrospettive recenti, i rischi sono più freschi e le storie vissute in prima persona hanno più impatto. In più, si rafforza la comunicazione interna grazie al racconto diretto.

Galen Low: Sì, la memoria sta nelle storie e nei racconti che portiamo da progetto a progetto.

C’è un bel ponte tematico: una domanda del pubblico riguarda la "prespective" o "pre-mortem". Vale la pena fare sia retrospettive sia analisi dei rischi in anticipo? Nel ciclo Agile, la retrospettiva diventa anche pianificazione dei rischi per lo sprint successivo?

Payson Hall: Di solito si fondono insieme. In Agile, la retrospettiva evidenzia problemi e miglioramenti che vengono direttamente ribaltati come azioni da implementare subito nello sprint successivo. Le due attività sono quasi la stessa cosa e così si rafforza la cultura del miglioramento continuo.

Galen Low: Esatto, perché guardi avanti, ottimizzi il futuro partendo da lezioni fresche. Un’altra domanda: alle volte i problemi non dipendono da decisioni interne del team, ma da fattori ambientali o esterni, come la perdita di risorse chiave. Come si segnala senza colpevolizzare e magari influenzare il cambiamento anche fuori dal progetto?

Payson Hall: Uso una formula neutra: "il progetto ha subito difficoltà per ricollocamento di risorse verso iniziative a maggior priorità". Come raccomandazione, suggerisco di aumentare la flessibilità dello staff o di avvisare tempestivamente il PM quando si riassegnano risorse, così da pianificare sostituzioni. Così si indica la criticità senza accusare nessuno.

Galen Low: Bella l’idea dei "finding". Ultima domanda: quali sono i temi principali su cui concentrarsi in retrospettiva? Si tende a spaziare su mille argomenti ma il tempo è limitato.

Payson Hall: Dipende, ma l’essenziale è: avevamo una definizione chiara di ciò che si doveva consegnare, condivisa fra stakeholder, sponsor, clienti? E se mutava, avevamo un processo chiaro di gestione del cambiamento? Spesso le cause vere dei problemi stanno qui più che in errori di pianificazione o stima.

Galen Low: Ottimo, sono tutti collegati. Mi piace la logica di cercare sempre il maggior valore per i portatori d’interesse. Grazie infinite, Payson, per questa chiacchierata. Un onore averti ospite. Dove possiamo trovare altro su ciò che fai in Catalysis Group?

Payson Hall: Visitate catalysisgroup.com: trovate informazioni su corsi e consulenza. Nella sezione risorse, potete scaricare articoli sulla gestione dei rischi, utilissimi anche per le retrospettive.

Galen Low: Confermo che Payson è uno scrittore di talento: ogni suo articolo diverte e arricchisce. Se pensate che retrospettive o gestione dei rischi siano noiose, cambierete idea! Link nelle note a piè di pagina.

Cari ascoltatori, spero abbiate tratto tanto da questa puntata. Alcune domande rimaste fuori le riporteremo in community. Payson è anche disponibile via email per eventuali altre curiosità.

Payson Hall: Sì, scrivetemi pure: risponderò volentieri!

Galen Low: E a voi ascoltatori: se volete partecipare alla conversazione con oltre mille professionisti di project management, unitevi al nostro collettivo! Scoprite come su thedigitalprojectmanager.com/membership. E se vi è piaciuta la puntata, iscrivetevi e seguiteci su thedigitalprojectmanager.com.

Alla prossima e grazie per l’ascolto.