Project Management | Il Project Management & l'arte della Maratona

Previsioni di progetto: come eseguire una simulazione Monte Carlo in un foglio di calcolo

Nel project management moderno, la capacità di prevedere è uno strumento strategico. A differenza delle previsioni meteo, che possiamo solo osservare passivamente, le previsioni di progetto ci informano su variabili che sono ancora sotto il nostro controllo. L’obiettivo non è indovinare quando un progetto finirà, ma capire quali leve possiamo manovrare per guidarlo verso un esito favorevole. Non si tratta di subire il futuro, ma di provare a plasmarlo, aumentando proattivamente le probabilità di successo. Fortunatamente, per ottenere questa chiarezza non sono necessari strumenti complessi: un semplice foglio di calcolo è più che sufficiente per costruire modelli di previsione potenti e realistici.

Questo articolo, basato sui concetti chiave presentati da Alexei Zheglov nel video Secrets of Flow #12 – Jan 28, 2025: Forecast on a Napkin, ti guiderà attraverso i passaggi concettuali per costruire una simulazione Monte Carlo, trasformando l’incertezza da un ostacolo a un vantaggio strategico. Per una spiegazione approfondita e la dimostrazione pratica, consiglio di guardare il video completo.

Prima di esplorare questo metodo, è essenziale comprendere i limiti dell’approccio più comune: la stima basata su un singolo numero.

I limiti di un singolo numero: la previsione del tovagliolo di carta

All’inizio di qualsiasi progetto, è fondamentale disporre di un modello di base per un primo controllo di fattibilità. Questo semplice calcolo, che si può quasi fare a pranzo su un tovagliolo di carta, si basa sull’allineamento di cinque indicatori chiave che devono essere coerenti tra loro. Questo approccio è noto come previsione puntuale perché si basa su un unico set di numeri precisi.

I cinque indicatori chiave sono:

Ambito (Scope): il numero totale di elementi di lavoro (work item) da completare (es. 120 work item).
Tempistica (Timeline): la durata target del progetto (es. 6 mesi).
Tasso di consegna (Delivery Rate/Throughput): il numero di work item che il team deve completare per unità di tempo per rispettare la scadenza (es. 20 work item/mese, calcolato dividendo l’ambito per la tempistica).
Tempo di ciclo (Cycle Time): il tempo medio necessario per completare un singolo work item (es. 0,5 mesi).
Lavoro in corso (Work in Progress – WIP): il numero di work item su cui il team lavora contemporaneamente (es. 10 work item, calcolato moltiplicando il tasso di consegna per il tempo di ciclo).

Il pericolo di questo modello non risiede in un errore di calcolo, ma nella sua fragilità. Basta che uno solo di questi indicatori non sia allineato con la previsione – un tempo di ciclo leggermente più lungo, una quantità di lavoro in corso insostenibile – e l’intero piano, apparentemente logico, non regge.

Il limite principale di questo approccio è la sua illusione di certezza. Presuppone che l’ambito non cambierà, che il tasso di consegna rimarrà costante e che ogni variabile sia nota con esattezza. È irrealistico credere di conoscere una di queste variabili con precisione assoluta. Ogni stima – specialmente quelle che derivano da una divisione, come il tasso di consegna – porta con sé un errore intrinseco. Per ottenere previsioni affidabili, dobbiamo passare a un metodo che non ignori questa realtà, ma la accetti.

Accettare l’incertezza: dalla previsione puntuale a quella probabilistica

Per un project manager, abbandonare le stime puntuali in favore di un range di probabilità non è un’opzione, ma un imperativo strategico. Invece di chiedere “Quando finirà il progetto?“, la domanda più utile diventa: “Qual è la gamma dei possibili risultati e con quale probabilità?“. Questo è il cuore della previsione probabilistica.

Tornando all’analogia del meteo, una previsione utile non dice semplicemente che domani ci saranno -5°C. Dice che la temperatura più probabile è -5°C, ma potrebbe variare tra -3°C e -6°C, mentre una temperatura di +20°C è estremamente improbabile. Questo range, unito alle probabilità, ci permette di prendere decisioni migliori.

La simulazione Monte Carlo è una tecnica che ci permette di fare esattamente questo per i nostri progetti. A livello concettuale, è come lanciare i dadi migliaia di volte per esplorare automaticamente migliaia di scenari. Invece di usare un solo valore per l’ambito e uno per il tasso di consegna, definiamo un range di possibilità per ciascuno. La simulazione combina casualmente questi valori migliaia di volte, generando una mappa completa e realistica dei possibili esiti del progetto.

Costruire una simulazione Monte Carlo: i fondamenti concettuali

La creazione di un modello di simulazione Monte Carlo funzionale ed efficace richiede, come passo fondamentale, la definizione di una funzione matematica che rappresenti con il massimo realismo possibile il fenomeno che si intende simulare. In alcuni casi, come nel nostro esempio, è relativamente semplice. In altri casi, per individuare correttamente questa funzione, si deve partire dall’analisi di dati storici affidabili relativi ai fenomeni specifici che possono variare e dai quali dipende la previsione. Questi dati permettono di ricostruire l’andamento del fenomeno nel tempo e di generare una curva di distribuzione che ne illustri chiaramente il comportamento statistico passato. Successivamente, è necessario condurre una ricerca mirata in letteratura per identificare una funzione matematica che approssimi al meglio quella curva distribuzione. Il momento cruciale della modellazione avviene attraverso il confronto grafico per sovrapposizione tra la curva ottenuta dai dati reali e le possibili curve matematiche teoriche: quella che garantisce la migliore approssimazione viene scelta per essere implementata nel modello, garantendo una rappresentazione corretta durante le simulazioni.

L’accuratezza in questa fase è essenziale per conferire credibilità al modello nei confronti degli stakeholder, poiché permette di spiegare in modo logico perché la simulazione possa essere considerata una valida approssimazione della realtà per formulare previsioni attendibili.

Il valore del modello sta nel ragionamento analitico

Tuttavia il valore autentico del modello non risiede tanto nei valori generati dalla previsione, quanto nel ragionamento analitico che ne ha guidato la costruzione. La fase di modellazione obbliga infatti a scomporre le dinamiche che influenzano l’esito del progetto e individuare i punti critici su cui agire.

La comprensione più profonda emerge quando costruiamo il modello che rappresenta il fenomeno che vogliamo simulare. Per simularne il tempo di ciclo, per esempio, dobbiamo identificare gli input: l’effort effettivo (es. 3-5 giorni), i ritardi dovuti a risorse non immediatamente disponibili (fino a una settimana), la probabilità di incontrare un blocco (es. 50%), l’impatto delle dipendenze esterne. Questo esercizio è esattamente lo stesso lavoro necessario per identificare i punti su cui intervenire per migliorare il processo. Costruire questo modello vi costringe a quantificare le vostre fonti di ritardo. Una volta che avete assegnato un numero a un blocker o a una dipendenza, non avete solo un input per la previsione, ma un obiettivo misurabile per il miglioramento.

Risultato della simulazione Monte Carlo della durata di un progetto: istogramma e curva dei percentili

Costruire una simulazione Monte Carlo: l’applicazione pratica

Vediamo ora, passo dopo passo, come scomporre la logica di una simulazione Monte Carlo in passaggi concreti applicati al nostro progetto, rendendola accessibile a chiunque abbia familiarità con un foglio di calcolo, senza perdersi in formule complesse.

Sostituire la falsa certezza con l’incertezza quantificata

Il primo passo è sostituire le stime puntuali e rigide con range di incertezza basati su ipotesi realistiche. Invece di numeri fissi, lavoriamo con intervalli che riflettono la variabilità del mondo reale.

Ambito del progetto: invece di assumere che il progetto avrà esattamente 120 work item, riconosciamo che l’ambito può crescere (cosiddetto ‘scope creep‘). Definiamo un range di possibile aumento, ad esempio, tra lo 0% e il 50%.
Tasso di consegna (Throughput): invece di presumere un tasso costante di 20 item/mese, consideriamo che la produttività del team possa fluttuare. Definiamo un range di variabilità, ad esempio, +/- 10% rispetto al valore di riferimento.

Simulare un singolo futuro possibile

Una volta definiti i range, il foglio di calcolo esegue una singola “iterazione” del futuro. In pratica, per una riga del foglio di calcolo, il sistema:

Sceglie un valore casuale all’interno del range di crescita dell’ambito (es. un’espansione del 15%).
Sceglie un valore casuale all’interno del range di variabilità del throughput (es. un tasso di 18.5 item/mese).
Calcola una possibile durata del progetto basata su questi valori specifici e casuali.

Questa singola riga rappresenta uno delle migliaia di possibili futuri per il nostro progetto.

Generare la mappa completa dei risultati

La vera potenza del metodo si manifesta a questo punto. Il foglio di calcolo permette di ripetere quasi istantaneamente il processo descritto nel punto precedente per migliaia di righe. In pochi secondi, si genera un’enorme raccolta di possibili durate del progetto, ognuna basata su una combinazione leggermente diversa delle nostre ipotesi iniziali. Questa massa di dati è la materia prima per una previsione veramente informativa. Il passo successivo è interpretarla in modo strategico.

Interpretare i risultati: il significato dell’istogramma

Il risultato di una simulazione Monte Carlo non è un singolo numero, ma una distribuzione di probabilità. Lo strumento migliore per visualizzarla è un istogramma (come in figura). In questo grafico, l’asse orizzontale mostra le possibili durate del progetto (in mesi), mentre l’altezza di ciascuna barra indica la frequenza di quel risultato nelle simulazioni, rappresentando di fatto la sua probabilità.

Analizzando il grafico, emerge un’evidenza fondamentale: la stima puntuale iniziale di 6 mesi si colloca quasi sempre nella parte più ottimistica della distribuzione, a sinistra, dove le barre sono più basse. Questo dimostra visivamente quanto sia rischioso fare affidamento su di essa.

Per comunicare gli impegni in modo professionale, usiamo i percentili (come in figura). Il percentile è il valore al di sotto del quale cade una certa percentuale di risultati della simulazione. Ad esempio se il risultato di una simulazione si trova all’85° percentile, significa che l’85% delle simulazioni ha dato un risultato inferiore o uguale, mentre il 15% ha dato un risultato superiore. Un impegno all’85° percentile non è un numero arbitrario, ma un pragmatico punto di negoziazione con gli stakeholder e successiva gestione del progetto. Questa previsione rappresenta uno scenario “pessimistico ma ancora accettabile”. Se questa data soddisfa i criteri di business, si è in presenza di un progetto praticabile. L’accordo si basa sulla tolleranza degli stakeholder per il risultato pessimistico.

Una volta che l’accordo è raggiunto, l’utilizzo della simulazione cambia. L’obiettivo non è più solo eseguire, ma pilotare attivamente il progetto verso i risultati più ottimistici (la parte sinistra dell’istogramma). Questo si ottiene gestendo le variabili del modello: controllando lo scope creep e stabilizzando il tasso di consegna. La previsione si trasforma da predizione passiva a fondamento di una strategia di gestione attiva.

Oltre la previsione: usare i dati per migliorare la gestione

Il punto più importante è che la previsione e il miglioramento sono due facce della stessa medaglia. Un buon modello di previsione non serve solo a predire il futuro, ma anche, e soprattutto, a identificare le leve che possiamo manovrare per cambiarlo in meglio.

Attraverso l’analisi di sensitività, che consente di osservare come varia il risultato finale al mutare dei parametri, è possibile sviluppare riflessioni strategiche su come migliorare concretamente le probabilità che un progetto vada in porto con successo.

Il modello di simulazione mostra chiaramente l’impatto delle nostre azioni. Possiamo vedere come gli sforzi per controllare l’aumento dell’ambito spostino l’intera distribuzione verso sinistra. Allo stesso modo, le iniziative per mantenere un tasso di consegna stabile riducono la dispersione dei risultati, rendendo il progetto meno rischioso.

Conclusione: prendi il controllo delle tue previsioni

Abbandonare le stime basate su un singolo numero a favore di un approccio probabilistico non significa arrendersi all’incertezza, ma padroneggiarla. Questo metodo trasforma la previsione da un atto di speranza a un potente strumento di gestione strategica.

I messaggi chiave sono tre:

Sfida la tirannia del singolo numero. Adotta le previsioni probabilistiche per gestire l’incertezza, non per ignorarla.
Democratizza la previsione. Usa un semplice foglio di calcolo per mappare l’intera gamma dei possibili futuri, rendendo visibile il rischio e l’opportunità.
Agisci, non limitarti a prevedere. Usa il modello come una leva strategica per pilotare il progetto verso il successo, intervenendo sulle variabili che puoi controllare.

Sperimenta questo approccio. Inizia a costruire i tuoi modelli semplici e scoprirai un nuovo livello di controllo e prevedibilità, aumentando drasticamente le probabilità di successo per i tuoi progetti.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Oltre il Gantt: il Rolling Forecast per introdurre Kanban e una pianificazione dinamica orientata al flusso

Nella mia consulenza operativa, una sfida che mi trovo spesso ad affrontare non è tanto l’implementazione tecnica del sistema Kanban, quanto la resistenza ad abbandonare vecchie consuetudini rassicuranti. Una situazione tipica si verifica con il bisogno psicologico di una pianificazione temporale visibile. Sebbene la logica della “coda pura”, tipica dei sistemi Kanban, si dimostri più efficace nel ridurre gli sprechi e ottimizzare il flusso, esiste una significativa barriera culturale legata alla percezione di instabilità dovuta all’assenza di un calendario dei lavori.

Nelle organizzazioni meno strutturate, la mancanza di una collocazione cronologica delle attività viene spesso percepita come una pericolosa e inaccettabile perdita dell’unica, seppure effimera, fonte di controllo. Il passaggio da una logica “push” basata sulle date a una logica “pull” basata sulla capacità produttiva e sulla gestione del flusso genera una destabilizzazione che può paralizzare le decisioni e bloccare l’evoluzione del sistema. Ho quindi trovato utile identificare uno strumento di mediazione che offra la rassicurazione di un piano temporale, senza sacrificare l’efficacia della gestione del flusso.

Il limite del modello Kanban percepito nelle organizzazioni tradizionali

Nei team fortemente abituati alla linearità dei diagrammi di Gantt, il Kanban puro tende a essere percepito come eccessivamente astratto. Una gestione basata esclusivamente sulla coda, priva di un orizzonte temporale definito, genera una sensazione di vuoto informativo che, a cascata, alimenta l’insicurezza decisionale. In assenza di una risposta chiara alla domanda “quando?”, il team avverte una carenza di visibilità prospettica che ostacola il coordinamento sia operativo sia strategico.

In questo contesto, il concetto di Rolling Forecast emerge dalla mia esperienza come la soluzione ibrida ideale. Non si tratta di un ritorno alla rigidità del piano, bensì dello sviluppo di un sistema capace di tradurre la coda di lavorazione nel linguaggio temporale richiesto dall’organizzazione. È lo strumento che colma il divario tra l’operatività del team e le aspettative di controllo della direzione.

Una coda organizzata su cadenze temporali

Il Rolling Forecast permette di superare i limiti del piano statico, abilitando un’architettura di gestione del flusso che integra la flessibilità della coda con la struttura del calendario. Possiamo definirlo come una “coda con cadenze”, dove la cadenza rappresenta il punto di sincronizzazione tra il flusso interno e le aspettative esterne.

Tecnicamente, il sistema si può articolare su tre segmenti operativi che mappano le lavorazioni su un orizzonte temporale scorrevole:

Periodo fissato: lavorazioni confermate e immodificabili nel brevissimo termine, dove l’esecuzione è imminente.
Periodo semifisso: lavorazioni pianificate con un margine di flessibilità, soggette a raffinamento prima di entrare nella fase operativa.
Periodo variabile: orizzonte temporale destinato alla pianificazione strategica, dove l’inserimento di nuove lavorazioni è ancora fluido.

Questa struttura consente di rispettare pienamente i principi della gestione del flusso di lavoro, pur offrendo la possibilità di collocare ogni attività in modo approssimativo su un calendario, garantendo così una visione d’insieme più tradizionale.

Analisi di un caso applicativo e sistema di aggiornamento

La validità di questo approccio non è solo teorica, ma trova conferma in evidenze empiriche. Nel caso di studio Doxee, che potete leggere sul portale Kanban+ di Kanban University, ho mostrato come il Rolling Forecast ha permesso di mettere sotto controllo un sovraccarico sistemico che inizialmente rendeva la gestione dei progetti software inconsistente e imprevedibile.

Pur mantenendo l’aspetto di una pianificazione temporale tradizionale, il sistema di Doxee ha iniziato a operare internamente seguendo rigorosamente le dinamiche di flusso tipiche dei sistemi Kanban, stabilizzandosi inizialmente ed evolvendo poi progressivamente verso una sempre maggiore efficienza ed efficacia.

La stabilità di tale sistema derivava dalla regolarità della sua manutenzione, basata sul meccanismo che io allora chiamavo “spostamento del carrello”:

Aggiornamento ogni 15 giorni: una routine bisettimanale che assicurava il riallineamento costante tra previsione e realtà, in base all’effettiva capacità produttiva.
Riclassificazione dei periodi: ad ogni ciclo, il “carrello” avanzava. Il periodo precedentemente classificato come semifisso diventava fissato e le relative attività venivano confermate e rese immutabili in vista della loro lavorazione, mentre 15 giorni del periodo variabile diventavano un periodo semifisso.
Rassicurazione metodologica: questa routine trasformava la gestione della coda in una sequenza ordinata di impegni, preservando le caratteristiche di una pianificazione e generando fiducia in tutti gli stakeholder.

Il Rolling Forecast: riferimenti teorici ed esperienza operativa

Il concetto di Rolling Forecast e di pianificazione continua trae i suoi fondamenti nella sperimentazione operativa che ne è stata fatta a partire dagli anni ’70 e ’80 del secolo scorso, per superare i limiti dei sistemi di pianificazione e controllo basati sul budget annuale come strumento centrale per la gestione delle grandi organizzazioni. La crescente complessità dei mercati e la necessità di rispondere rapidamente ai cambiamenti avevano mostrato sempre di più i limiti dei budget rigidi, aprendo la strada a strumenti di previsione più flessibili e orientati al cliente, come, appunto, i Rolling Forecast.

Il contributo principale nella letteratura manageriale è stato dato da Jeremy Hope e Robin Fraser con la pubblicazione nel 2003 del libro Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, in cui descrivono i principi chiave dell’approccio:

previsioni aggiornate periodicamente, orientate al futuro
separazione tra forecast, target e sistemi di incentivazione
uso delle previsioni come strumento decisionale e non solo di controllo
maggiore autonomia e responsabilizzazione delle unità operative

Questi principi costituiscono la base teorica riconosciuta del Rolling Forecast, mostrando come esso possa supportare organizzazioni complesse nella gestione dinamica dei risultati e delle risorse.

La mia conoscenza concreta del Rolling Forecast deriva direttamente dall’esperienza maturata, a partire già dalla seconda metà degli anni ’90, da una manager di una società appartenente a un grande gruppo industriale multinazionale, che me ne aveva condiviso il funzionamento pratico applicato alla pianificazione della produzione di beni di largo consumo.

Nei primi anni duemila ho avuto modo quindi di adattare e applicare personalmente lo stesso sistema in Doxee per la pianificazione operativa dello sviluppo di progetti software. L’esperienza maturata in quegli anni ha confermato l’efficacia del Rolling Forecast come strumento di supporto decisionale in contesti dinamici, migliorando sia la capacità di risposta sia la qualità delle decisioni.

Valutazione della maturità organizzativa e pressioni esterne

L’adozione del Rolling Forecast è una scelta strategica dettata dalla maturità dei processi aziendali. In realtà poco strutturate o in fase di transizione, il calendario agisce come un linguaggio familiare che facilita l’adozione di logiche più avanzate senza traumi organizzativi.

Inoltre, il Rolling Forecast funge da interfaccia di comunicazione essenziale verso l’ambiente esterno. Quando i clienti esercitano forti pressioni per ottenere date di consegna certe, l’organizzazione non può limitarsi a mostrare una coda di lavorazione. Il calendario diventa lo strumento di interfaccia che permette di gestire internamente il flusso in modo dinamico, fornendo esternamente le risposte temporali necessarie per mantenere la fiducia del cliente.

Conclusione: equilibrio tra controllo e flessibilità

L’obiettivo finale di un intervento operativo non è l’applicazione pedissequa di un metodo teorico, bensì la costruzione di un sistema di gestione ordinato e sostenibile, capace di rispettare la realtà psicologica dell’organizzazione.

In questo contesto, il Rolling Forecast rappresenta spesso, almeno nelle fasi iniziali, il punto di equilibrio ottimale tra l’esigenza di controllo del management e la flessibilità richiesta dai moderni flussi di lavoro.

La vera forza del sistema non risiede nella precisione delle date, ma nella regolarità della cadenza di aggiornamento. È questa costanza che genera rassicurazione e trasparenza, trasformando il calendario da semplice strumento di pianificazione a pilastro della fiducia aziendale. Implementare un Rolling Forecast significa, in ultima analisi, costruire un ponte solido tra la vecchia cultura del calendario e la nascente gestione del flusso.

Bibliografia

Jeremy Hope, Robin Fraser, Beyond Budgeting… Breaking Through the Barrier to the Third Wave, Management Accounting (CIMA), 1997
Jeremy Hope, Robin Fraser, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003
Marco Re, A Kanban-like system successfully implemented at Doxee in 2010-2012, portale Kanban+ della Kanban University, 2023

Al PMexpo torna il workshop: dal caos al flusso – sbloccare il potenziale del tuo team con Kanban

Sei pronto a trasformare il modo in cui il tuo team lavora?

Al prossimo PMexpo che si terrà a Roma venerdì 14 novembre (informazioni e iscrizioni cliccando qui) presenteremo di nuovo in un workshop il gioco di simulazione Featureban (informazioni cliccando qui).

Se non hai potuto partecipare alle sessioni passate, potrai unirti a noi per un evento speciale dove imparerai come utilizzare Kanban per passare dal caos al flusso. Scopri come sbloccare il potenziale del tuo team e ottimizzare la produttività. Non perdere questa opportunità unica!

Partecipando alla nostra simulazione potrai sperimentare concretamente come funziona il metodo Kanban in un’azienda, capirai come lavorare con il metodo Kanban, vedrai quali difficoltà possono verificarsi e capirai come risolvere i problemi.

I partecipanti potranno vedere in azione le pratiche generali Kanban: visualizza, limita il work in progress (WIP), gestisci il flusso, esplicita le policy, implementa cicli di feedback, migliora collaborando ed evolvi sperimentando.

La partecipazione a questo evento dà diritto CDP e a PDU ways of working per il mantenimento della certificazione PMI.

Ti aspettiamo!

Sempre in occasione del PMexpo sarà anche presentato in anteprima allo stand di E-quality Italia il mio libro Dal caos al flusso: La trasformazione organizzativa con il metodo Kanban, dedicato ai principi e alle pratiche per guidare il cambiamento nelle organizzazioni .

Vieni a scoprirlo!

L’efficienza non nasce dalla saturazione: il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica

Il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica. È una lezione che ho imparato sul campo, molto prima di scoprirne la base teorica anni dopo, studiando la Legge di Little.
Un flusso di lavoro è davvero efficiente solo quando opera al 60-70% della sua capacità potenziale. Tentare di spingerlo verso il 100% significa inevitabilmente portarlo al collasso: il sistema si imballa, rallenta, si blocca.

Questa verità mi è diventata chiara durante un’esperienza tanto concreta quanto frustrante, quando ero responsabile di più progetti di sviluppo software.

L’enigma di Stefano e la capacità fantasma

Il problema emerse all’inizio di un nuovo progetto. Qualche giorno dopo il kick-off chiesi al project manager come stessero procedendo i lavori.
Mi rispose che, in realtà, il progetto non era ancora partito.

Il motivo? Uno solo: Stefano (nome di fantasia) non era disponibile. Era impegnato in attività di manutenzione.
Chiesi quando sarebbe stato disponibile e mi risposero “domani”. Ma anche il giorno dopo la situazione era identica: Stefano era ancora bloccato sulla manutenzione.

A quel punto mi dissi: “Aspetta un attimo. Com’è possibile che Stefano non sia disponibile? Doveva esserlo.”

Decisi di approfondire. Andai a parlare con il suo responsabile e gli chiesi: “Scusami, quanto tempo passa Stefano a fare manutenzione?” Mi rispose sinceramente: “Non lo so con precisione. Parecchio, ma non saprei quantificare.”

Sapevo che tutto il lavoro veniva registrato nei timesheet, quindi proposi di verificare i dati. Dopo un po’ di insistenza, riuscimmo a recuperare i registri dei mesi precedenti. Il risultato fu inequivocabile: Stefano dedicava circa un terzo del suo tempo alla manutenzione in produzione.

La ricalibrazione della capacità e il rischio della turbolenza

Con quei numeri in mano, mi presentai al Project Management Office (PMO). Dissi loro: “Pianifichiamo il lavoro di Stefano come se fosse disponibile al 100%, ma non lo è. In realtà possiamo contare su di lui solo per il 70% del tempo.”

Mi chiesero se fossi certo del dato. Risposi di sì: avevamo prove misurabili.

Ma il problema non era solo quello. Oltre alla disponibilità media, bisognava considerare la turbolenza: picchi, imprevisti, variazioni.
Non bastava pianificare sulla base del 70% di disponibilità, serviva margine. Dopo una discussione, concordammo di ridurre ulteriormente il carico effettivo al 60-65%.
Solo entro quella soglia si poteva sperare che la disponibilità fosse affidabile.

La battaglia per lo slack e la scommessa con l’amministratore delegato

Dopo quella ricalibrazione, mi convinsi che serviva anche dello slack: una tolleranza per assorbire variazioni e imprevisti.
All’epoca pianificavamo ancora con i diagrammi di Gantt; non conoscevo ancora il metodo Kanban né avevo letto il libro Kanban: Successful Evolutionary Change for Your Technology Business di David Anderson.

Proposi al PMO di introdurre margini di slack, ma la risposta fu immediata: “Impossibile. L’amministratore delegato ci licenzierebbe.”

Non arretrai. Dissi: “Preferisco dimettermi piuttosto che continuare a pianificare così.”

Dopo un acceso confronto, trovammo un compromesso: “Scrivete pure che la decisione è mia. Se qualcuno deve essere cacciato, sarò io.”

Riuscii a convincerli. Preparammo un diagramma di Gantt in cui ogni barra aveva la sua tolleranza, con la nota: ‘Tolleranza di Marco Re’.

Quando il piano arrivò sulla sua scrivania, l’amministratore delegato mi chiamò: “Marco, che cos’è questa storia? Vieni a spiegarmela.”

Gli esposi l’approccio. Non era convinto e allora lo sfidai: “Lasciami applicare il metodo fino a Natale. Se il 6 gennaio tutto sarà andato liscio, bene. In caso contrario, torniamo indietro e potrai anche rimuovermi dall’incarico.”

Quel periodo era cruciale: per il tipo di mercato in cui operava l’azienda, arrivava sempre la grande ondata di cambiamenti di fine anno che gettava i team di sviluppo nel caos.

Accettò.

La validazione definitiva

Implementammo la pianificazione con carico effettivo al 60-65% e margini di slack.
Arrivò il 6 gennaio e, per la prima volta, l’azienda attraversò il passaggio d’anno senza scossoni.

Aspettavo quel giorno e andai a trovare l’amministratore delegato, questa volta di mia iniziativa: “Hai visto? Così abbiamo gestito tutto in modo fluido!”

Quell’esperienza fu la prova definitiva: non è la saturazione che genera efficienza, ma la capacità di limitare empiricamente il lavoro in corso (WIP limit, nel linguaggio Kanban) e di mantenere margine operativo.
Sul campo ho imparato che pianificare al 60-70% — nel nostro caso 60-65% — è la vera chiave per costruire flussi di lavoro resilienti, sostenibili ed efficienti.

Perché funziona

Un sistema completamente saturo è fragile: ogni imprevisto diventa una crisi.
Un sistema con spazio di manovra, invece, è resiliente: assorbe variazioni, reagisce agli urti e continua a funzionare in modo fluido.

La vera efficienza non è riempire tutto il tempo disponibile, ma garantire continuità, prevedibilità e serenità operativa.

Il metodo Kanban e l’H-Factor: coltivare il fattore umano nell’era dei progetti digitali

La nostra vita, sia personale che professionale, è costantemente intessuta di progetti, dal piccolo traguardo quotidiano alla grande impresa che segna una svolta. Al centro di ogni progetto, indipendentemente dalla sua scala o dalla crescente pervasività di tecnologie emergenti come l’intelligenza artificiale e la realtà virtuale, c’è e ci sarà sempre il “Fattore Umano”. In questa nuova era, caratterizzata da complessità e rapidi cambiamenti, la capacità e le competenze delle persone assumono un valore ancora maggiore. Donne e uomini di talento sono chiamati a fare la differenza, contribuendo in modo decisivo al successo dei progetti.

Come possiamo, dunque, valorizzare al meglio questo insostituibile “Fattore Umano” e supportarne la crescita in un contesto sempre più digitale e orientato ai progetti?
Se ne parla domani, venerdì 13 giugno, a Bari al PMI Forum.

In questo articolo voglio evidenziare come il metodo Kanban si riveli una leva strategica e operativa potentissima proprio per lo sviluppo umano e professionale, grazie al suo solido impianto valoriale e al suo approccio evolutivo.

Kanban: non solo strumenti, ma valori per le persone

Il metodo Kanban è basato su principi e valori che vanno oltre la mera ottimizzazione dei processi. È un approccio che pone l’attenzione sulle persone e incoraggia la collaborazione. I valori culturali, in particolare come definiti nel Kanban Maturity Model (KMM), non sono concetti astratti, ma principi guida che plasmano il comportamento e la cultura organizzativa, fondamentali per l’evoluzione.

I valori del metodo Kanban hanno un impatto diretto sulla crescita e sulla valorizzazione del “Fattore Umano”. Alcuni di questi li ho esplorati più a fondo nei miei ultimi articoli:

Rispetto (Respect): rispettare le persone nel metodo Kanban significa riconoscere le loro competenze, condizioni e responsabilità. Implica creare un ambiente che permetta loro di esprimere il proprio potenziale, fornendo formazione, risorse, strumenti, tempo, spazio e regole chiare. Le persone hanno bisogno di conoscere il loro scopo, come contribuire e quali risultati sono attesi, per sviluppare autonomia, padronanza e un forte senso di significato nel lavoro. Questo valore si traduce anche nella gestione del carico di lavoro, riducendo il sovraccarico (Muri) e l’irregolarità (Mura) nel flusso, pratiche che migliorano la concentrazione, riducono lo stress e aumentano la qualità della vita lavorativa. L’approccio evolutivo di Kanban, che evita cambiamenti traumatici e parte da ciò che esiste, è anch’esso una manifestazione del rispetto per le persone e la loro identità.
Achievement (Raggiungimento dei risultati): la consapevolezza di raggiungere risultati è fondamentale per la realizzazione personale. Kanban valorizza i piccoli successi e i passi avanti compiuti, contribuendo a rafforzare la resilienza. La visualizzazione del lavoro completato su una Kanban board individuale può diventare una ‘bacheca dei trofei’, un riconoscimento personale che motiva. Nelle organizzazioni più mature, l’achievement evolve da valore privato a valore sociale e riconosciuto, attraverso indicatori visivi, celebrazioni, riconoscimento formale e narrativa organizzativa. Questo valore è un elemento culturale fondamentale per far progredire l’organizzazione.
Trasparenza (Transparency): la trasparenza è un valore fondamentale e una pratica abilitante nel metodo Kanban. Attraverso la visualizzazione del lavoro, delle policy, dei rischi e delle aspettative, Kanban garantisce una comprensione condivisa, facilitando il processo decisionale, la collaborazione e la condivisione della conoscenza. Rende visibile ciò che sarebbe altrimenti invisibile. Policy esplicite migliorano la fiducia nell’organizzazione, creando condizioni per la responsabilizzazione. La trasparenza sui dati e sulle performance permette decisioni basate su fatti concreti, non su percezioni soggettive. Soprattutto, la trasparenza in Kanban favorisce lo sviluppo dell’empatia. Vedere il flusso, i blocchi, le tensioni, i rischi non solo fa comprendere, ma fa anche “sentire” le dinamiche del sistema, creando una consapevolezza condivisa. Sebbene la trasparenza possa incontrare resistenze legate al controllo delle informazioni, condividere il maggior numero possibile di informazioni è essenziale per rafforzare l’affidabilità organizzativa.
Collaborazione (Collaboration): Kanban promuove attivamente la collaborazione. È un valore culturale esplicito essenziale per l’evoluzione organizzativa. Dalle board individuali aggregate che mostrano il lavoro di più persone, facilitando l’aiuto reciproco, si passa alla cooperazione tra team per offrire un servizio al cliente. La visualizzazione, i cicli di feedback (cadenze), le policy esplicite, l’orientamento ai servizi e la cultura Kaizen (miglioramento continuo) sono tutte pratiche che alimentano la collaborazione. Gestire il lavoro, non le persone, sposta il focus e incoraggia i team a collaborare per far progredire il flusso.
Leadership e Responsabilità (Leadership and Accountability): Kanban incoraggia atti di leadership a tutti i livelli, non solo ai vertici gerarchici. La leadership è vista come un atto, un’azione, che si manifesta nella capacità di ispirare gli altri all’azione attraverso esempio, parole e riflessione. Questo è intrinsecamente legato alla responsabilità: chiunque agisca per migliorare o risolvere un problema si assume una responsabilità. La leadership è necessaria a tutti i livelli per il miglioramento continuo. La responsabilità dei leader è quella di catalizzare discussioni e spingere all’azione per affrontare le sfide. Una mancanza di leadership è spesso dovuta a una mancanza di responsabilità. Kanban promuove una cultura di accountability, dove gli individui sono responsabili delle proprie azioni e dei risultati collettivi. Leader e individui sono incoraggiati ad assumersi la responsabilità in prima persona, agendo con affidabilità e accettando rischi (“skin in the game“). Anche i ruoli formali di leadership, come i manager, hanno la responsabilità di guidare il miglioramento continuo del flusso.
Scopo (Purpose): La definizione e condivisione di uno scopo chiaro e condiviso è uno strumento concreto ed efficace per responsabilizzare e alimentare la leadership a tutti i livelli. Fornisce il “senso” necessario affinché le persone si sentano abilitate ad agire da leader e a migliorare attivamente il sistema. Lo scopo guida il comportamento, orienta le decisioni e responsabilizza. È la base per atti di leadership distribuita e un antidoto alla mentalità vittimistica.

Kanban: una leva strategica e operativa per i progetti e la crescita umana

Se i modelli di Project Management tradizionali vedono i progetti come unici e irripetibili, un’analisi Kanban rivela che la maggior parte delle attività progettuali aziendali è in realtà standardizzabile e ripetibile, riconducibile a schemi produttivi come la produzione in linea o a lotti. Proprio perché molte attività non sono uniche, Kanban si rivela efficace per ottimizzare il flusso di lavoro. Il Kanban Project, Programme e Portfolio Management (KPPM) estende l’applicazione di Kanban alla gestione di progetti complessi, basandosi su pensiero sistemico, gestione del flusso e una cultura collaborativa orientata allo scopo.

In questo contesto progettuale, dove tecnologia e processi avanzano rapidamente, Kanban non solo offre strumenti operativi per migliorare l’efficienza, ridurre i tempi di consegna e minimizzare gli sprechi, ma diventa una leva strategica per valorizzare e far crescere il “Fattore Umano”:

Permette di applicare concretamente i concetti teorici nella realtà quotidiana.
Aiuta a visualizzare i processi, a gestire e dare priorità al lavoro, e a vedere le fasi con chiarezza, superando difficoltà comuni.
Contribuisce a rendere visibili i flussi di valore, individuare inefficienze e migliorare la capacità di risposta.
Grazie al suo approccio evolutivo e incrementale, permette di iniziare dal basso, osservando il lavoro reale dei team e applicando gradualmente i principi e i framework come riferimento e Kanban come strumento quotidiano di evoluzione organizzativa.
Evita rotture traumatiche che minaccerebbero l’identità delle persone.
Fornisce i meccanismi di feedback (cadenze) essenziali per coordinare e migliorare continuamente il modo di lavorare, fungendo da vero meccanismo di trazione per un sistema Kanban. Questi momenti di riflessione sono cruciali per tradurre l’insoddisfazione in azione, catalizzata dalla leadership.
Combatte la sindrome del “plateau della presunta eccellenza”, che si verifica quando le organizzazioni si fermano dopo i successi iniziali legati soprattutto al benessere del team, non affrontando barriere più profonde di natura culturale e sociologica. Il KMM fornisce una roadmap per superare questo stallo e sbloccare benefici più significativi, richiedendo consapevolezza e la disponibilità ad affrontare queste barriere.

Conclusione

In un mondo di progetti sempre più permeato dalla tecnologia, le capacità umane di leadership, responsabilità, collaborazione, empatia e orientamento allo scopo, supportate da una trasparenza basata sui dati e da un rispetto per l’individuo e il suo lavoro, diventano gli elementi distintivi che permettono al talento di fare la differenza. Kanban, fornendo un framework operativo che incarna questi valori e promuove un cambiamento evolutivo, diventa uno strumento potente per coltivare l’”H-Factor”, garantendo che le persone non siano relegate a meri esecutori in sistemi gestiti dalla tecnologia, ma rimangano al centro, guidando l’innovazione e il successo dei progetti.

Attraverso Kanban, il “Fattore Umano” è abilitato a prosperare, non solo gestendo i progetti in un’era digitale, ma guidandoli con intelligenza, empatia e scopo.

Ottimizzare la gestione dei progetti con il metodo Kanban: dalla percezione di unicità alla standardizzazione dei flussi di lavoro

Quando si parla di gestione dei progetti, spesso si tende a considerarli come entità uniche e irripetibili. Del resto i modelli di riferimento internazionali di project management ci portano in quella direzione. Solo per citare alcune definizioni:

il PMBoK definisce il progetto come “a temporary endeavour undertaken to create a unique product, service or result” (un’iniziativa temporanea per creare un prodotto, servizio o risultato unico);
la norma ISO 21502 similmente lo definisce come “a temporary endeavour to achieve one or more defined objectives” (un’iniziativa temporanea per raggiungere uno o più obiettivi definiti). La stessa norma afferma poi che “sebbene molti progetti abbiano caratteristiche simili, ogni progetto è unico”;
secondo PRINCE2 un progetto è “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case” (un’organizzazione temporanea che è creata con lo scopo di rilasciare uno o più prodotti di business secondo con un business case concordato). Lo stesso PRINCE2 afferma che “ciascun progetto è unico”.

Tuttavia, un’analisi più approfondita dei contesti reali rivela che nella maggior parte dei casi i progetti aziendali sono una collezione di elementi standardizzabili, ripetibili e organizzabili secondo schemi ben definiti. In questo quadro, il metodo Kanban si rivela un approccio estremamente efficace per migliorare la gestione e l’efficienza dei progetti.

I progetti: non unicità, ma standardizzazione

Analizzando le attività all’interno di un progetto, si scopre che esse sono per lo più riconducibili a schemi produttivi ben noti in ambito industriale, che si possono applicare anche ai servizi:

Produzione a commessa (Job-Shop): un’attività che viene svolta una sola volta, senza opportunità di apprendimento progressivo. Questo, e solo questo, schema produttivo corrisponde alla definizione di progetto data dai modelli di riferimento internazionali.
Produzione a lotti (Batch Production): un processo che permette un limitato margine di apprendimento tra le fasi.
Produzione in linea (Line Production): un processo più strutturato e ottimizzabile con il tempo.
Produzione continua (Continuous Production): un sistema altamente efficiente che permette un apprendimento costante e ottimizzazione continua.

Mentre l’obiettivo finale di un progetto potrebbe essere unico (Job-Shop), la maggior parte delle attività che lo compongono rientra nelle categorie di produzione in linea o a lotti, se non addirittura continua. Attività come costruzione, sviluppo, mobilitazione, acquisti, contabilità e reportistica seguono molto spesso schemi standardizzati e ripetitivi.

Perché Kanban funziona per i progetti?

Dal momento che la maggior parte delle attività di un progetto non è quindi veramente unica, ma segue schemi ricorrenti, il metodo Kanban aiuta a ottimizzare il flusso di lavoro. Identificare le attività ripetitive e trattarle con un approccio di produzione in linea o a lotti permette di:

Migliorare l’efficienza operativa.
Ridurre il tempo di consegna.
Minimizzare sprechi e inefficienze.
Rendere più prevedibile la gestione delle risorse.
Facilitare il miglioramento continuo attraverso l’apprendimento iterativo.

Il metodo Kanban nella gestione dei progetti

David J. Anderson ha creato il metodo Kanban originariamente per la gestione dello sviluppo software e ne ha successivamente esteso l’utilizzo alla gestione di qualunque servizio basato sulla conoscenza e ai progetti, enfatizzando l’importanza di visualizzare il lavoro, limitare il work in progress (WIP) e migliorare continuamente i flussi di lavoro. Per quanto riguarda i progetti, ne ho parlato in un articolo che potete rileggere cliccando qui.

Il Kanban Maturity Model (KMM) di David J. Anderson e Teodora Bozheva ha definito poi l’impiego del metodo Kanban per la gestione e lo sviluppo dell’azienda di servizi nel suo complesso. Più recentemente, un’evoluzione significativa di questo approccio è rappresentata dal Kanban Project, Programme e Portfolio Management (KPPM) di Teodora Bozheva, che amplia l’applicazione del metodo Kanban oltre la gestione dei singoli progetti, includendo programmi e portafogli aziendali. Il KPPM si basa su tre elementi fondamentali:

Pensiero Sistemico (Systems Thinking): considerare l’organizzazione come un sistema di parti interconnesse, comprendendo che i risultati dipendono dalle interazioni tra queste parti.
Gestione del Flusso (Flow Thinking): ottimizzare il flusso di lavoro identificando e affrontando i colli di bottiglia, migliorando la velocità e la qualità delle consegne.
Cultura Collaborativa e Orientata allo Scopo (Purpose-driven): promuovere una cultura aziendale basata sulla collaborazione e focalizzata sugli obiettivi comuni, facilitando il miglioramento continuo.

Implementando il KPPM, le organizzazioni possono affrontare le sfide croniche nella gestione di progetti, programmi e portafogli, integrando pratiche che migliorano la prevedibilità, l’affidabilità e la trasparenza dei flussi di lavoro. Questo approccio non sostituisce i metodi di gestione tradizionali, ma li integra, offrendo strumenti per affrontare le complessità moderne con maggiore efficacia. Ho approfondito il KPPM in un articolo che potete rileggere cliccando qui.

Per quanto riguarda la mia esperienza diretta, della quale parlo in altri articoli che potete leggere qui, aziende che hanno implementato con successo sistemi Kanban per migliorare la gestione dei progetti hanno visto un significativo incremento dell’efficienza operativa, trasformando positivamente la gestione dei progetti e migliorando sia la produttività che la soddisfazione del cliente.

Conclusione

L’idea che i progetti siano entità uniche e irripetibili porta a inefficienze e ritardi nella loro esecuzione. In realtà, la maggior parte delle attività che li compongono seguono pattern standardizzabili, rendendo possibile l’applicazione del metodo Kanban per ottimizzarne la gestione. Riconoscere questa realtà permette ai project manager e alle aziende di adottare strategie più efficienti, migliorando la qualità e i tempi di consegna senza sacrificare la flessibilità necessaria per gestire le vere poche eccezioni.

In definitiva, un progetto aziendale ben gestito non è frutto solo dell’abilità del project manager o dell’applicazione di qualche metodo di project management, quanto soprattutto dell’applicazione di principi di produzione strutturati e flussi di lavoro standardizzati e ben collaudati.

Migliora il tuo project management con Kanban: Churchill ci insegna a scrivere le policy

Una delle pratiche generali del metodo Kanban è ‘Esplicita le Policy’ (Make Policies Explicit), che da un punto di vista pratico significa definire, scrivere e rendere chiare a tutti le regole di funzionamento del proprio sistema Kanban. Nella mia esperienza di coach osservo che questo è un aspetto spesso poco considerato, mentre invece è di un’importanza cruciale.

In questo articolo vi riporto e commento un famoso dispaccio declassificato di Winston Churchill, primo ministro britannico durante la seconda guerra mondiale, che ci insegna come si scrivono le policy. E ci insegna anche a cosa servono le policy.

A cosa servono le policy

Le policy definiscono come si svolge il lavoro in ogni fase del processo, come viene visualizzato il lavoro, come vengono prese le decisioni e quali sono gli interlocutori con cui relazionarsi, sia all’interno dell’organizzazione di servizi che con i clienti. Rendere esplicite le policy è essenziale per rendere il flusso di lavoro stabile e affidabile.

Il dispaccio di Churchill definisce una policy che spiega in modo chiaro e per punti le modalità secondo cui devono essere scritti i report perché siano efficaci. Lo stesso vale per le policy dei sistemi Kanban, sono istruzioni operative che devono descrivere cosa fare perché il flusso di lavoro funzioni efficacemente.

Peraltro chi si occupa di progetti e project management non può non notare il richiamo del dispaccio ad evitare di produrre carta e burocrazia inutile e limitarsi all’essenziale. Anche questo è un insegnamento che ritroviamo nel metodo Kanban. Per esempio la pianificazione dei progetti con Kanban permette di elaborare una previsione affidabile dei tempi e costi di progetto in modo rapido, economico ed efficace, senza inutili appesantimenti.

Come si scrivono le policy

Le policy devono quindi essere scritte in linguaggio semplice e comprensibile a tutti, sono istruzioni operative, non devono impressionare qualcuno ma essere applicate sistematicamente in modo tale da aiutare la stabilizzazione del flusso di lavoro.

Il dispaccio di Churchill è scritto nelle stesse modalità che descrive, in modo tale da essere esso stesso un esempio di come si scrivono i report. Per questo mi pare che sia un ottimo esempio di guida pragmatica, attuabile e basata su evidenze, come ci insegna a fare anche il metodo Kanban.

Spesso riscontro invece nelle aziende una preoccupazione per la forma con cui vengono scritte le policy. In una certa misura è comprensibile, ma non deve portare a perdere di vista la sostanza, come invece succede troppo spesso. La prerogativa dei sistemi Kanban non è quella di essere formalmente ineccepibili, quanto quella di funzionare in modo affidabile ed evolvere nel tempo.

A chi servono le policy

Le policy servono a chi opera sul flusso di lavoro per sapere come deve comportarsi nelle varie situazioni. Il team è chiamato a definire le policy che permetteranno di lavorare meglio e poi a rispettarle o a modificarle se non sono funzionali. In questo senso più che la scrittura delle policy è importante la loro applicazione. Se sapremo portare i flussi di lavoro ad essere stabili, sapremo poi anche evolverli, altrimenti no. Troppe volte vedo policy, anche pensate bene, che poi restano all’atto pratico lettera morta.

Di nuovo ci è di ispirazione il dispaccio di Churchill, che nell’ultimo paragrafo riassume il senso profondo del metodo Kanban: “la disciplina di esporre i punti concreti in modo conciso si rivelerà un aiuto per una maggiore chiarezza di pensiero”. E conseguentemente di azione.

Migliora il tuo Project Management con Kanban: gestire ed evolvere un’organizzazione che eroga servizi

Il metodo Kanban è uno strumento efficace per stabilizzare e poi evolvere in modo efficace ogni organizzazione che eroga servizi. Ho già raccontato in un precedente articolo come sia possibile utilizzare Kanban per misurare ed equilibrare i carichi di lavoro tra flussi di lavoro diversi. Questo è reso possibile dal fatto che i flussi vengono analizzati come se fossero indipendenti uno dall’altro, ciascuno di loro viene gestito e stabilizzato fino a farlo diventare affidabile e robusto a prescindere da ciò che accade nel resto del sistema. Infine si cerca di equilibrare in modo empirico e sperimentale la rete dei flussi collegati insieme, sempre però evitando la centralizzazione del controllo, che porterebbe il sistema complessivo a essere fragile. Al contrario una rete di sistemi Kanban è resiliente perché l’eventuale degradarsi di una parte ha sempre un impatto limitato sul resto del sistema.

L’applicazione di Kanban ai servizi

La funzione IT di Grow, l’azienda citata nel precedente articolo, che ricordo utilizza processi e ruoli basati sul framework ITILv3, ha la possibilità di equilibrare i carichi perché nell’arco di qualche anno ha fatto evolvere costantemente la propria struttura basandosi sulla logica sopra descritta. Nell’immagine si può vedere come il nucleo del sistema si basi oggi su tre sistemi Kanban, interconnessi ma indipendenti. Il primo è l’IT Portfolio, il flusso di lavoro che permette in modo trasparente di orchestrare tutti gli altri servizi e di destinare le risorse dove necessario. Il secondo è il Service Desk, flusso che gestisce il supporto agli utenti (richieste di servizio e incidenti). Il terzo è l’IT Workflow, flusso che elabora tutti gli elementi di lavoro relativi ai processi ITIL necessari far funzionare i servizi IT erogati dal sistema complessivo.

Le altre funzioni aziendali di Grow, che sono i ‘clienti’ della funzione IT, e che a loro volta sono in parte gestite con sistemi Kanban – come per esempio l’HR – interagiscono con il Service Desk per quanto riguarda l’operatività corrente e con l’IT Portfolio per richiedere tutti i miglioramenti ai servizi utilizzati. L’IT Portfolio indirizza i miglioramenti di piccola entità (Change Request – CR) all’IT Workflow, che li processa. Invece i miglioramenti di maggiore entità (Progetti) vengono indirizzati a un sistema Kanban specifico per la gestione dei progetti.

L’applicazione di Kanban ai progetti

La funzione IT di Grow ha un sistema di project management che si basa su PRINCE2 e AgilePM e anche nel caso dei progetti ha fatto evolvere il proprio project management grazie ai sistemi Kanban sviluppati al proprio interno. Il sistema Kanban del Progetto orchestra in modo trasparente il progetto stesso e indirizza lo sviluppo dei componenti ai vari team, che nel caso della nostra funzione IT sono per lo più dei fornitori esterni.

I fornitori esterni nella quasi totalità dei casi non utilizzano un sistema Kanban, ma come detto la loro eventuale instabilità impatta in modo limitato i sistemi Kanban interni che mantengono autonomamente la propria stabilità. Dai fornitori esterni possono anche ritornare delle richieste all’IT Workflow, per esempio per i test dei sistemi informatici che sono sviluppati dal progetto, oppure per i cambi di configurazione dei servizi modificati dal progetto.

Il sistema Kanban di Progetto, infine, non vede l’IT Portfolio solo come ‘committente’, ma interagisce anche con esso per richiedere eventuali CR fuori dal proprio ambito.

Mantenere il sistema bilanciato

E’ necessario sottolineare di nuovo l’importanza che hanno avuto e che hanno nel sistema dell’IT di Grow lo sviluppo, la gestione e la stabilizzazione di ciascuno dei flussi e dei sistemi Kanban in modo indipendente ma interconnesso. In questo modo l’IT di Grow riesce mantenere affidabili e robusti i flussi a prescindere dal funzionamento del resto del sistema e allo stesso tempo disporre di un sistema complessivo sostanzialmente prevedibile e resiliente.

Il metodo Kanban mette a disposizione numerosi strumenti e un metodo di sviluppo evolutivo consolidato per arrivare a questo risultato, senza sostituire i metodi di service management e project management già in uso, ma semplicemente aiutando ad utilizzarli meglio e a potenziarli, come avvenuto in Grow.

Migliora il tuo Project Management con Kanban: risolvere problemi concreti di gestione dei progetti

Ieri a Roma abbiamo partecipato come sponsor al VII Forum Nazionale di Project Management organizzato congiuntamente dai tre Chapter italiani del PMI, dove abbiamo avuto tanti interessanti incontri con i partecipanti e conversazioni su problemi concreti di gestione dei progetti.

Tema ricorrente è come alleviare il sovraccarico dei team e come riuscire a mantenere le promesse di tempistica fatte al cliente.

Prevedere in modo affidabile tempi e costi riduce i rischi di progetto

Il metodo Kanban permette di stabilizzare e rendere prevedibili i flussi di lavoro dei team coinvolti nei progetti, migliorando in modo significativo l’affidabilità e la correttezza delle previsioni relative a tempi e costi di progetto. Ottenere una prevedibilità di tempi e costi con una confidenza statistica misurata e dimostrabile superiore al 90% significa avere ridotto sensibilmente i rischi di progetto, sia in termini di promesse al cliente che di sovraccarico del team.

Il project manager che usa Kanban migliora l’efficacia del proprio lavoro perché si orienta sempre di più alla prevenzione dei problemi piuttosto che alla loro risoluzione, diventa sempre di più un risk manager.

gioco dimostrativo dell’effetto benefico prodotto dall’introduzione di un collo di bottiglia a monte di un flusso

Stabilizzare il flusso di lavoro aumenta la prevedibilità di tempi e costi

Chi ci ha incontrato ieri al nostro stand ha potuto toccare con mano, attraverso un piccolo gioco dimostrativo (nella foto) preso in prestito da Eli Goldratt e dalla teoria dei vincoli, l’effetto benefico, ancorché controintuitivo, dell’introduzione di un collo di bottiglia all’inizio del flusso di lavoro. Così facendo il flusso di lavoro si stabilizza, diminuiscono Work in Progress (WIP) e Lead Time, si riduce l’entropia all’interno del Team, si pongono le basi solide per aumentare la prevedibilità di tempi e costi per poi successivamente aumentare anche il Throughput.

La tipica obiezione è che questi concetti sono applicabili alla produzione di serie, il progetto è qualcosa di diverso. Vero, ma solo in parte, vent’anni di applicazione del metodo Kanban in tutto il mondo hanno dimostrato che all’interno dei progetti la stragrande maggioranza dei fenomeni sono prevedibili, molto di più di quanto non si creda comunemente. Occorre però analizzare a fondo le dinamiche, imparare a conoscerle e a misurarle.

Casi di studio, formazione e coaching

Per approfondire le applicazioni pratiche potete leggere i casi di studio che abbiamo pubblicato raccontando la nostra esperienza. Li trovate nel nostro blog.

Per comprendere più a fondo il metodo, anche attraverso giochi di simulazione, e imparare come costruire e migliorare il vostro sistema Kanban potete partecipare a uno dei nostri corsi accreditati dalla Kanban University. Trovate tutte le informazioni nella pagina dei corsi.

Se desiderate l’aiuto di un esperto che vi supporti in azienda ad applicare il metodo Kanban, un coach accreditato presso Kanban University potrà fornirvi tutta l’assistenza necessaria. Trovate tutte le informazioni nella pagina del coaching STATIK.

Per continuare o iniziare a parlarne insieme, potete contattarci cliccando su questo link.

Vi aspettiamo!

Migliora il tuo Project Management con Kanban: pianificare un progetto con Kanban

Recentemente ho avuto modo di pianificare un progetto con il metodo Kanban e di apprezzare una volta di più la rapidità con cui le pratiche Kanban permettono di elaborare una previsione affidabile dei tempi e costi di progetto. Ho già introdotto in un precedente articolo i concetti fondamentali relativi al KPPM – Project, Programme e Portfolio Management. Qui racconto un breve esempio applicativo che fa uso di alcune tra le pratiche suggerite.

Il progetto

Il progetto informatico da pianificare è consistito nel refactoring e sostituzione di una soluzione software per la gestione di un workflow aziendale che era diventata obsoleta e inadeguata. Il flusso di lavoro in questione ha una lunga storia ed è stato via via nel tempo ottimizzato. Non ci si aspettava nel progetto particolari sorprese da un flusso sostanzialmente consolidato.

Il team di progetto ha visto il coinvolgimento della responsabile dell’area di business interessata, oltre che della project manager (la responsabile IT), della sua assistente, il sottoscritto come Kanban coach e due team di sviluppatori appartenenti a due aziende fornitrici diverse, ben conosciuti e con entrambi i quali esiste da anni un solido rapporto di collaborazione. I due team di sviluppatori hanno caratteristiche e performance differenti e la responsabile IT ha effettuato nel tempo delle misurazioni che ci hanno permesso di conoscere con una certa accuratezza il tipo di distribuzione di probabilità dei loro Lead Time. Per il tipo di sviluppo da effettuare potevamo in questo caso considerare i Lead Time di entrambi i team di tipo gaussiano (Thin-Tailed), quindi abbiamo potuto utilizzare nelle previsioni il Lead Time medio e applicare la Legge di Little.

Preliminarmente abbiamo effettuato un’analisi del lavoro da svolgere e creato un backlog di progetto composto da circa 40 requisiti di alto livello in forma di User Story.

La pianificazione

Non entrerò nei dettagli tecnici dei concetti probabilistici e matematici sottostanti, mi limiterò a una panoramica del metodo applicato. Per pianificare il progetto con il metodo Kanban abbiamo proceduto come segue.

Modello probabilistico per calcolare il numero di User Story di dettaglio

Innanzitutto ci siamo creati un modello per fare delle ipotesi probabilistiche su quale avrebbe potuto essere il numero di User Story di dettaglio a partire da quelli che erano i requisiti di alto livello. Il modello probabilistico ci ha suggerito che un numero di circa 10 User Story di dettaglio per ciascun requisito era una misura ragionevole, per cui abbiamo previsto circa 400 User Story di dettaglio da sviluppare.

Fattore di correzione per tenere conto della ‘dark matter’

Abbiamo successivamente corretto il numero di User Story previste in funzione di quella che in Kanban chiamiamo ‘dark matter’, ovvero tutta quella parte di requisito che emerge man mano che il progetto procede. Non si tratta di nuovi requisiti, chiedendo al committente del progetto risponderà che quei requisiti non sono nuovi, sono sempre stati lì anche se non erano emersi in modo chiaro. Per questo è meglio introdurre un fattore di correzione opportuno per tenerne conto. Nel nostro caso, data la natura del progetto di refactoring del software, con poche sorprese, abbiamo ritenuto che un fattore di correzione del 40% fosse adeguato per tenere conto in modo corretto della ‘dark matter’. In totale la previsione è diventata quindi di 560 User Story.

Calcolo del throghput e del WIP a partire dalla deadline di progetto

Considerando che tipicamente, in un progetto che fa uso di un flusso di lavoro Kanban, è solo la parte temporalmente centrale quella in cui è possibile considerare il flusso di lavoro stabile e costante, abbiamo applicato la Legge di Little al 90% circa del lavoro da realizzare, pari a circa 500 User Story, da svolgersi nel 60% circa del tempo totale di progetto.

Ripartendo le User Story sui due team di sviluppo e conoscendo la deadline di progetto richiesta dalla responsabile dell’area di business, abbiamo calcolato il throghput richiesto, ovvero il numero di User Story che i team devono sviluppare per unità di tempo. Applicando la Legge di Little a ciascun team, in funzione del Lead Time medio su base storica e del throghput richiesto abbiamo quindi calcolato il WIP (Work in Progress) medio per entrambi i team.

Correzione del bias cognitivo sul concetto di media

Il modello prevede poi un ulteriore fattore di correzione del 10% per tenere conto del fatto che i valori medi usati per il calcolo sono un’approssimazione della mediana (ossia il cinquantesimo percentile statistico), che sarebbe il valore corretto da considerare. Noi esseri umani siamo soggetti a un bias cognitivo che ci fa considerare ‘valore medio’ quello che in realtà è il valore mediano. Quando diciamo che “mediamente facciamo una certa attività in un certo tempo” intendiamo che una volta su due ci mettiamo di più e una volta su due ci mettiamo di meno, ma questo appunto è il concetto statistico di mediana, non di media.

Definizione dei tempi e costi di progetto

Abbiamo infine richiesto ai fornitori di mettere a disposizione un numero di sviluppatori adeguato al WIP di lavoro calcolato. In base al calcolo effettuato i fornitori hanno organizzato ciascuno il proprio team e ci hanno fornito un preventivo dei costi per la realizzazione del progetto nei tempi previsti.

Al netto dei tempi necessari per l’elaborazione dell’offerta da parte dei fornitori, la previsione dei tempi e costi di progetto ha richiesto in tutto solo qualche ora.

Il monitoraggio

La previsione così definita ha permesso anche alcuni monitoraggi in corso di progetto molto semplici ma efficaci:

il fattore utilizzato per calcolare il numero di User Story per ciascun requisito ha consentito un controllo rapido e costante della stabilità del backlog. Quando un team registrava un valore significativamente diverso da quello previsto, faceva immediatamente escalation al project manager;
ci si aspettava che il Lead Time medio di ciascun team fosse sostanzialmente stabile. Quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager;
infine ci si aspettava che il throghput di ciascun team restasse attestato al valore medio previsto. Anche in questo caso, quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager.

Conclusione

E’ chiaro, come nell’esempio applicativo qui descritto, che per pianificare e monitorare un progetto con Kanban sia necessaria la presenza di un flusso di lavoro stabile del quale si conoscano i Lead Time medi. C’è del lavoro da fare a monte del progetto, sempre con Kanban, per misurare e, nel caso, rendere stabile e prevedibile il flusso di lavoro dei team.