Project Management: l’importanza del lesson learned

Lo scopo fondamentale dell’allenamento è ripetere gesti e pratiche per poterli apprendere. Insomma, impari la lezione che poi in gara cerchi di mettere in pratica. Tuttavia, gli esercizi da seguire non li inventi tu o il tuo allenatore. Con tutta probabilità essi derivano dall’esperienza che qualcuno ha fatto prima di te, verificando che quel determinato allenamento svolto in un certo modo aveva uno specifico beneficio.

L’importanza di riusare la conoscenza pregressa, propria o altrui, per evitare di reinventare ogni volta la ruota non è mai abbastanza sottolineata. La stessa conoscenza scientifica progredisce in questo modo. Isaac Newton, nel 1675 disse “If I have seen further it is by standing on the shoulders of giants”.

Questo è vero a maggior ragione nelle discipline empiriche, come il Project Management, dove l’adozione di specifiche pratiche o tecniche viene sperimentata da qualcuno e poi trasmessa per “tradizione professionale” o attraverso la pubblicazione di documentazione, articoli e paper.

Il caso del canale di Panama

Il progetto del canale di Panama ebbe vita travagliata. All’inizio del XX secolo, un passaggio di uomini e merci dall’Atlantico al Pacifico senza dover circumnavigare il Sud America e doppiare il temibile Capo Horn era ormai una necessità.

Inizialmente affidato alla Francia, che aveva gestito la realizzazione del Canale di Suez, il progetto si arenò per una concomitanza di scelte tecniche azzardate (un canale unico invece che segmentato in diversi tratti separati da chiuse, soluzione questa pressoché obbligata per l’orografia del territorio, completamente diversa dal deserto di Suez) e di superficialità manageriale, come la sottovalutazione delle condizioni climatiche e di profilassi dei lavoratori, falcidiati da malaria e febbre gialla.

Successivamente il progetto fu ripreso dagli Stati Uniti che adottarono scelte che in seguito divennero di ispirazione per generazioni di Project Manager. La nuova gestione:

• Nominò un Project Manager con forti competenze tecniche in ambito costruzioni.
• Modificò la soluzione tecnica riprogettando il canale su più segmenti separati da chiuse per gestire al meglio le differenze di quota e le asperità nei circa 80 km dello stretto.
• Affrontò i rischi connessi alle condizioni dei lavoratori investendo in misure di sanità preventiva (es. controllo degli insetti vettori di trasmissione di malattie).
• Si assicuro che i lavoratori fossero ben nutriti ed equipaggiati.
• Introdusse meccanismi di premi e incentivi per I lavoratori per tenere alti morale e motivazione.
• Adottò una pianificazione rigorosa e accurata di tutti gli aspetti riguardanti non solo itempi, ma anche l’allocazione di risorse e la logistica di uomini e mezzi su un territorio difficile.

Ciò consenti, alla fine, di inaugurare il canale nel 1914, con 2 anni di anticipo rispetto alla data prevista del 2016, situazione piuttosto rara soprattutto per progetti infrastrutturali di tali dimensioni e complessità. Al di là della specifica soluzione tecnica del canale segmentato, specifica per Panama ma ad esempio non necessaria a suo tempo per Suez, tutte le altre scelte (Project Manager, gestione dei rischi, pianificazione attenta e rigorosa) rappresentarono altrettante “lesson learned” per i progetti degli anni a venire e ancora oggi sono principi assolutamente validi.

Conoscenza in riuso

La formazione e il riuso della conoscenza di progetto è perciò un aspetto cruciale, non solo per trarre profitto dall’esperienza altrui, ma anche e soprattuto dalla propria. Quando porti avanti un progetto fai continuamente delle scelte, su come organizzare le attività, su quante risorse impiegare e in che modo, su quali processi di lavoro adottare per guadagnare efficienza, etc.

Sono scelte fatte da qualcun altro prima di te in situazioni analoghe e che tu stesso hai già fatto in passato in progetti simili. E le scelte che fai oggi ti torneranno utili in futuro, quando si riproporrà un contesto dello stesso tipo. Lo stesso principio vale ovviamente anche per le cose da non fare, per le scelte da non ripetere perché si sono mostrate improduttive o addirittura dannose.

Tutte le metodologie, framework e modelli di project management riconoscono l’importanza del riuso di conoscenza ed esperienza pregressa nei progetti.

Il PMBOK del PMI raccomanda di formalizzare le “lesson learned” di progetto in un opportuno database per usi futuri. PRINCE2 individua 7 principi di base non negoziabili per la gestione di progetto, tra i quali “learn from experience”. Metodi agili come SCRUM prevedono al termine di ogni iterazione di lavoro un momento (Retrospective Meeting) di valutazione di quanto fatto e di individuazione di possibili azioni da mettere a fattor comune e da ripetere in seguito.

Gli esercizi che ti propongo oggi sono indirizzati alla raccolta organizzata di conoscenza e “lesson learned” da riutilizzare nei tuoi progetti futuri.

Imparare la “lezione”: warm up

Il Project Management non è come la fisica, dove puoi fare quelli che Einstein chiavama “Gedankenexperiment” ossia esperimenti puramente mentali, come immaginare di essere a cavallo di un raggio di luce per dedurre la relatività di spazio e tempo.

Il Project Management parte sempre dal confronto empirico con la realtà. Lo schema seguente esemplifica il ciclo della conoscenza legata al Project Management, la sua successiva codifica e formalizzazione e l’utilizzo finale da parte tua, dopo che l’hai appresa ad un corso di formazione, leggendo un libro o lavorando assieme ad un collega più esperto.

Qualcuno prova a “fare le cose in un certo modo”, attraverso una specifica tecnica o pratica, e verifica che ciò porti dei vantaggi misurabili. Può trattarsi di un esperimento effettuato direttamente “sul campo” oppure di un paper frutto di uno studio basato comnuque su dati empirici.

Questa “lesson learned” viene utilizzata da altri project manager che, per “trasmissione professionale”, cominciano ad adottarla fino a quando si raggiunge una massa critica di progetti o di professionisti che concordano sull’utilizzo dello specifico metodo/strumento, che poi viene eventualmente preso in considerazione o inglobato da modelli e framework di settore (es. PMBOK, PRINCE2, …). In qualche caso la pratica è ritenuta utile in modo così diffuso da ispirare o essere inserita all’interno di standard internazionali (es. ISO).

Il contenuto di modelli, framework e standard derivante dalle “lesson learned” di partenza alimenta infine le fonti aperte e chiuse sia in rete che tradizionali (libri, corsi di formazione, etc.) per essere fruito da chiunque voglia usarlo per impostare e indirizzare i propri progetti professionali e personali.

In pratica, tutto il Project Management come disciplina si basa sulle lesson learned e la capitalizzazione dell’esperienza.

Esercizi

Passiamo adesso al programma di allenamento vero e proprio. Di seguito gli esercizi di Lesson Learned Management che dovresti sempre eseguire sul tuo progetto. Utilizzare una specifica applicazione software può esserti d’aiuto ma, come abbiamo visto più volte in passato, gli strumenti sono inutili se non padroneggi tecniche e metodi alla base del loro utilizzo. Perciò puoi cavarvela egregiamente anche con un semplice foglio elettronico o addirittura con carta e penna.

Esercizio 1: identificazione delle lesson learned

Devi tracciare le “lesson learned” alimentando un lessons log che ti consentirà di utilizzarle nel progetto corrente e/o di trasmetterle a progetti futuri. Per definizione, le “lesson learned” sono criteri, scelte o azioni ricorrenti in funzione del tipo di situazione e di contesto. Ad esempio, in un progetto di sviluppo software, anche se il contratto prevede un’analisi dei requisiti da produrre con uno specifico formalismo (es. UML, Unified Modeling Language), l’utilizzo di prototipi di interfaccia consente di velocizzare grandemente l’attività, esemplificando in modo visuale le ipotesi che poi, una volta approvate dall’utente, possono essere formalizzate con calma nella documentazione di progetto.

In termini pratici, il lessons log è una tabella che puoi modellare all’interno del tuo foglio elettronico preferito con queste 15 colonne di partenza:

1. numero progressivo (identificativo della lesson),
2. tipologia (es. legata al progetto, ad aspetti organizativi, entrambe le cose,…)
3. codice della lesson (mnemonico),
4. breve descrizione (es. utilizzo prototipo visuale per velocizzare l’approvazione dei requisiti),
5. evento o processo di business collegato (es. approvazione dei requisiti)
6. effetto (es. impatto finanziario positivo/negativo)
7. indicazione dell’ambito (progettazione, esecuzione, acquisto, etc.) o attività relativa,
8. causa/trigger
9. presenza di elementi che consentano di rilevare in anticipo la necessità di utilizzo della lesson
10. raccomandazioni
11. se la lesson deriva dall’identificazione e/o gestione di un rischio (minaccia o opportunità)
12. data di registrazione
13. soggetto che ha rilevato la lesson
14. priorità espressa secondo la metrica in uso nel progetto (es. alta, media, bassa,…)
15. note (eventuali altre informazioni).

Come devi eseguire questo esercizio?

L’esercizio può essere eseguito in qualsiasi momento del progetto sia utile farlo. Nella fasi iniziali vengono raccolte le lesson learned da progetti precedenti, ritenute rilevanti per quello in esame e utilizzate per produrre i piani di lavoro. Sono particolarmente utili le “lezioni” relative ai rischi, per verificare come rischi simili siano stati affrontati e con quale esito in progetti analoghi.

Va poi sottolineato che, benché le lesson learned possano essere identificate e censite durante tutto il progetto, “imparare dalle lezioni” significa avviare specifiche azioni di miglioramento, altrimenti rimane tutto solo sulla carta. Queste azioni, se applicabili al progetto corrente saranno incorporate nella pianificazione dei vari aspetti. Se rilevanti solo per progetti futuri, per specifici vincoli o scadenze termporali ormai maturate, verranno comunque registrate almeno in fase di chiusura del progetto.

Ti consiglio di far diventare questa abitudine un vero e proprio obbligo, una condizione necessaria per formalizzare il termine delle attività. E’ impossibile che un progetto non abbia lezioni da tramandare a futura memoria, anche solo per confermare che le scelte fatte hanno funzionato nel contesto in esame.

Le colonne proposte sono indicative. Come al solito, dovrai adattare (tailoring) metadati di descrizione e formato al tuo specifico contesto progettuale, eventualmente integrando con altre informazioni.

Esercizio 2: retrospective meeting

Nei progetti gestiti con modalità agili le attività sono organizzate in iterazioni di lavoro di durata costante. Puoi vedere ciascuna iterazione come un “mini progetto” che ha lo scopo di realizzare e rilasciare un insieme limitato di funzionalità del prodotto/servizio che il progetto deve costruire. Il Retrospective Meeting è un incontro che vede protagonista il Team di progetto, che si riunisce per valutare l’iterazione di lavoro appena conclusa, cosa sia andato bene, cosa sia andato male e cosa sia migliorabile nelle successive iterazioni.

Da un punto di vista operativo, puoi strutturare un Retrospective Meeting in 5 step:

1. Set the stage: in questa fase il Team prende confidenza cercando di focalizzarsi su cosa sia avvenuto durante il periodo oggetto di revisione critica. E’ importante che ciascuno si senta a proprio agio in modo da essere poi onesto e trasparente. Si tratta di una fase di “riscaldamento” il cui scopo è stimolare le persone a parlare tranquillamente per stemperare la possibile tensione (si tratta pur sempre di un momento di verifica, anche se congiunta).

2. Gather data: in questa fase si scende in maggior dettaglio su cosa abbia funzionato e cosa no. Una tecnica consiste nel disegnare su una lavagna una barca con un grande motore e una grande ancora ben evidenziati. Poi chiedi ai membri del tuo Team di usare dei post-it per annotare cosa abbia “spinto” il progetto, attaccandoli dalla parte del motore, e altri post-it per annotare cosa abbia “frenato” il progetto, attaccandoli dalla parte dell’ancora. A questo punto puoi discutere con il Team su come minimizzare gli elementi freno e dare più spinta alla barca.

3. Generate insights: questa fase segue in modo naturale quella precedente, identificando pattern e duplicati all’interno del processo a partire dai dati raccolti. Se, ad esempio, ci sono 3 membri del tuo team che ritengono sarebbe opportuno apportare una modifica o miglioria di un qualche tipo, questo è più significativo che se la stessa posizione fosse sostenuta da una sola persona.

4. Decide what to do: analizzare come siano andate le cose e cosa si sarebbe potuto fare non serve a molto se non ti dai un piano d’azione concreto. Per aiutare a definire le cose da mattere in pratica un minuto dopo che la riunione si sia conclusa, puoi usare uno schema come quello della figura seguente, dove le azioni sono classificate in 4 gruppi: quello che devi cominciare a fare, quello che devi smettere di fare, quello che dovresti fare di più e quello che dovresti fare di meno.

5. Close the retrospecive: è importante che tutti siano motivati a mettere in pratica l’action plan individuato nella precedente fase 4. Per questo è utile chiudere con “elementi emozionali” che rinforzino la motivazione delle persone ad agire. Ad esempio, per ogni azione (da fare, non fare, fare di più o fare di meno) nell’iterazione successiva puoi chiedere al Team di descriverla con un disegno e una frase umoristica. E’ un modo per incoraggiare il Team togliendo pressione e ribadendo a cuor leggero cosa dovrà essere fatto.

Come devi eseguire questo esercizio?

L’esercizio deve essere eseguito al termine di una specifica fase di lavoro, che in un progetto gestito con modalità agile coincide con la fine di una iterazione, mentre in un progetto gestiito in modo tradizionale può corrispondere ad uno specifico raggruppamento di attività il cui scopo era produrre uno specifico deliverable o porzione di esso.

Defaticamento e stretching

Tutti impariamo dall’esperienza, o dovremmo farlo. Come Project Manager non fai eccezione. Raccogliere dati e informazioni relativi all’esito, positivo o negativo, di scelte e azioni effettuate per tramandarli a futura memoria ti mette in condizioni di ripondere alle situazioni con maggiore prontezza ed efficacia o, se sei in fase di pianificazione, di prevedere scenari e circostanze.

Nessun progetto è uguale all’altro al 100% ma nemmeno diverso al 100%. Puoi sempre contare sul fatto che qualcuno prima di te, o tu stesso se non dovessi ricordartelo, ha gestito una situazione simile.

Registrare le lesson learned ti consente di alimentare una base di dati che nel tempo, progetto dopo progetto, diventerà sempre più ricca, consentendoti di non partire ogni volta da zero ma dal 5% o dal 10% e o dal 30% di cose già fatte e riutilizzabili. Oltre al risparmio di tempo e denaro avrai maggiore affidabilità per il fatto di effettuare scelte e azioni che si sono già rivelate utili e proficue.

In definitiva, se non impari la lezione non migliori, nei progetti come in tutto il resto. Come dice Scottie Pippen, presente nella lista dei 50 giocatori di basket NBA più forti di tutti i tempi “Everything was a lesson learned and a step forward for me”.