Il concetto di lesson learned è un punto chiave nella gestione di un qualsiasi progetto, qualunque sia il tipo di organizzazione coinvolta.

Le organizzazioni, con le loro attività, generano nuove esperienze e nuove conoscenze che vanno a costituire parte della loro proprietà intellettuale. Ciò è vero, in particolare, nel corso del ciclo di vita dei progetti stante l’unicità del risultato che li caratterizza. Memorizzare le esperienze, sintetizzarle e metterle a frutto a vantaggio di future iniziative è dunque un’importante attività del Project Management, sebbene non di rado venga trascurata. L’obiettivo delle lessons learned è proprio quello di creare una sintesi di quanto accaduto per agevolare la gestione dei progetti futuri.

Lessons Learned e aree di indagine

Le lessons learned possono riguardare ogni area di gestione del progetto, dalla gestione dei tempi a quella degli stakeholder.

Possiamo classificarle in diverse aree, fra le quali:

• Processi e Metodi: si verifica e si tiene memoria dell’efficacia dei metodi e dei processi utilizzati o, nel caso di scostamenti, delle cause identificate e delle azioni correttive applicate.
• Ruoli: si verifica l’efficacia dei ruoli assegnati alle persone e della loro esecuzione nel corso del progetto. In questa verifica è importante comprendere se le persone erano informate delle loro mansioni e delle aspettative che l’organizzazione aveva nei loro confronti.
• Incertezze e Rischi: in questa fase della raccolta delle lessons learned si elencano le circostanze impreviste che si siano manifestate o modalità di verifica differenti dalle previsioni di rischi identificati. Anche in questo caso si verifica l’efficacia delle azioni pianificate, delle azioni correttive impostate rispetto a rischi imprevisti, i costi del verificarsi dell’evento e le sue conseguenze sulla pianificazione oltre a quelli derivanti dalle nuove decisioni prese.
• Stakeholder: aspetto assai delicato nella gestione di progetti complessi. Stakeholder sono tutte le persone o i gruppi di persone influenzati, in un senso o nell’altro, dal progetto. Il primo aspetto da investigare è se siano stati identificati in modo corretto e se siano state comprese le loro aspettative, come queste siano state gestite e la conseguente efficacia delle azioni attuate.

Come e quando si raccolgono le informazioni sulle lessons learned.

Dati e informazioni si raccolgono nel corso dell’intero ciclo di vita del progetto e si archiviano in attesa di essere elaborate. Se il progetto è breve il motivo può sfuggire: risulta infatti ovvio attendere il suo termine per raccogliere ed elaborare le informazioni in una singola sessione di lavoro. Se si lascia trascorrere troppo tempo, tuttavia, la memoria di quanto accaduto tende ad affievolirsi, dettagli ed informazioni importanti finiscono per essere dimenticati o distorti da altre esperienze, impedendo una corretta interpretazione e ostacolando una sintesi corretta.

Il fattore tempo per le lessons learned è quindi assai importante: le informazioni debbono essere raccolte in modo rapido e sistematico, man mano che il progetto procede e deve essere eseguita in modo formale o informale, a seconda della natura del progetto e della cultura dell’organizzazione che lo esegue.

Un esempio di gestione informale può essere il diario delle operazioni redatto ogni settimana dal responsabile di progetto, come note in un applicativo online.

La tecnologia mette a disposizione un numero crescente di strumenti che facilitano la raccolta di dati e informazioni: sensori, registrazioni audio, immagini, filmati, simulazioni, output di analisi di varia natura possono essere rilevati con strumenti di uso comune (per esempio gli smartphone di cui ognuno dispone) ed essere archiviati in formato elettronico. In questo modo possono essere consultati con facilità al momento della sintesi, rendendo tale procedura assai efficace.

Il Processo

La raccolta e la sintesi delle lessons learned si consegue con un processo strutturato, non necessariamente complicato o che richieda molto tempo. Per garantire l’efficacia delle lessons learned il processo deve essere parte delle riunioni di avanzamento periodico.

Dovrà quindi essere specificato in che modo descrivere la lesson learned, come raccogliere e archiviare i dati, come eseguire la sintesi, come finanziare eventuali azioni correttive e, infine, come e chi dovrà eseguire la sintesi.

Disporre di un metodo condiviso garantisce il risultato finale e riduce il possibile disorientamento delle persone all’atto della revisione critica. 

Un esempio di raccolta dati formale, che fa riferimento alla tecnologia testé citata, è una procedura di inserimento guidata, che debba essere completata ogni settimana per le quattro categorie evidenziate in precedenza (Processi e Metodi, Ruoli, Incertezze e Rischi, Stakeholder): il sistema di survey guida il project manager a identificare e a elencare problemi e punti di miglioramento archiviando l’informazione in una base dati che verrà consultata al momento della discussione finale.

Output

Le lessons learned elaborate debbono essere inserite in un documento formale (registro delle lessons learned).

La struttura di questo documento e il formato dei dati dipendono dall’organizzazione, dal tipo di progetti che essa esegue e dagli standard che adotta per i report e le comunicazioni. Un’azienda che gestisce progetti informatici, ad esempio, ha una forte attenzione rispetto alle richieste di modifica e alla loro gestione. Nel documento di output le voci saranno classificate in base a:

1. Titolo della richiesta
2. Data
3. In scope/out of scope
4. Area del Prodotto (UI, Database Design, Performance, ecc.)
5. Responsabile
6. Soluzione
7. Efficacia della soluzione

Il registro delle lessons learned costituisce un asset che l’organizzazione mantiene aggiornato a supporto delle sue attività future.

Fattori di insuccesso e rifiuto

È stato già citato, come fattore chiave per la raccolta dei dati il tempo, che si combina anche con la scarsità di risorse delle organizzazioni nelle quali, se l’utilità delle lessons learned non è ben compresa, le funzioni tenderanno a richiamare le loro risorse da un progetto che considerano terminato.

Un altro fattore importante è il comportamento delle persone che hanno, talvolta, la tendenza a rimuovere le circostanze negative o a dare eccessivo risalto a quelle positive. Un ulteriore aspetto da considerare è la cultura di condivisione della conoscenza presente nell’organizzazione: la conoscenza è una fonte di potere referente e conferisce uno stato sociale a chi la detiene. E questi non è detto che voglia condividerla di buon grado.

Le lessons learned, infine, coinvolgono il senso di responsabilità e la capacità di condividere i propri errori in modo aperto: se le persone si sentono sotto accusa tenderanno a minimizzare l’effetto dei loro errori o a nasconderli e la raccolta delle lessons learned sarà considerata come un insieme di prove da utilizzare contro di loro.

Questi aspetti del comportamento generano resistenza al cambiamento che lo strumento impone all’organizzazione: se la cultura e il clima aziendale non sono appropriati, inserire le lessons learned può essere uno spreco di denaro e di energia. L’adozione di nuovi strumenti deve essere effettuata nella piena consapevolezza delle implicazioni organizzative:citando Kurt Lewin “prima si rimuove l’ostacolo al cambiamento e poi si cambia”.

Una nota sui metodi agili

Nello Scrum, un diffuso metodo agile, si effettuano periodiche retrospettive, al termine delle iterazioni. Nella retrospettiva si esamina e si tiene traccia di quanto avvenuto, di ciò che ha favorito il successo delle attività e di cosa lo abbia ostacolato. È interessante notare come nello scrum il parametro che determina la chiusura di un’iterazione sia il tempo (o il budget assegnato): al tempo pianificato l’iterazione viene conclusa anche se gli obiettivi non siano stati raggiunti, circostanza questa che rende la retrospettiva indispensabile.

Lessons Learned e Conoscenza

Le esperienze dicono che le lessons learned generano conoscenza tacita, ovvero il 90% circa della conoscenza di cui un’organizzazione dispone.

La differenza fra conoscenza tacita ed esplicita è che quest’ultima è codificabile e si può trasmettere in forma verbale o scritta, mentre la prima si trasmette con l’esempio e con l’imitazione. A volte, in mezzo a questi due estremi, viene inserita anche una terza forma di conoscenza che è la conoscenza implicita.

Un esempio

Alpha è un’azienda manufatturiera di medie dimensioni, che progetta e commercializza macchine automatiche per il confezionamento di schede per computer, con progetti che vanno dai tre ai diciotto mesi e con un prezzo che varia dai 150.000 ai 2 milioni di euro.

A seguito di una richiesta della direzione, il management dell’ufficio tecnico quello delle funzioni produzione, acquisti e qualità, decidono di raccogliere le lessons learned a partire dai difetti segnalati, dal numero di anomalie che le macchine evidenziano nei primi 60 giorni di funzionamento e dal numero di richieste di modifica ricevute nei primi 120 giorni dopo la consegna. Si decide, inoltre, su iniziativa del rappresentante dei Project Manager di elencare gli imprevisti di carattere amministrativo, le malattie, le assenze di altro tipo, i conflitti interni e con il cliente. 

Difetti e richieste vengono classificati rispetto al modulo funzionale dove siano verificati e ne viene indicato il numero di occorrenze. Questo permette di identificare un insieme di dati da confrontare con quelli di altri progetti e di elaborare una statistica, oltre a identificare le aree di maggiore attenzione per gli investimenti in ricerca e sviluppo.

In fase di esame dei dati della macchina KXW 2019 ha rilevato 11 difetti nel modulo di taglio, 7 difetti nel modulo di taping e 4 nel modulo di pulizia. Questi dati sono disallineati rispetto alla statistica in particolare per il modulo di taglio che evidenzia circa il 50% di anomalie in più rispetto alla media. L’origine del difetto viene identificata nell’uso di un nuovo componente che è stato inserito per aumentare la performance complessiva ma non è stato montato in modo corretto.

La conclusione del processo di analisi identifica un difetto sia nella procedura di montaggio che nei criteri di selezione del componente. La procedura aggiornata viene distribuita ad altri progetti che utilizzano lo stesso componente (identificabili mediante una ricerca nella base dati PDM di cui l’azienda dispone).

Conclusioni

Le lessons learned sono uno strumento di gestione e di preservazione delle conoscenze e delle esperienze che le organizzazioni generano nel corso delle loro attività. Archiviate in un registro, vengono consultate a vantaggio di progetti e di iniziative future. Sono spesso trascurate sia per mancanza di tempo, sia per la cultura di condivisione della conoscenza oltre che per la cultura dell’errore, tutti aspetti presenti nell’organizzazione che possono generare resistenza al cambiamento. La gestione delle lessons learned deve essere quindi sistematica e i dati e le informazioni devono essere generati durante l’intero ciclo di vita del progetto, attraverso un processo strutturato.