Project Management | Kanban & l'arte della Maratona

Gestire l’incertezza nei progetti: come il Critical Chain Project Management supporta il metodo Kanban

Chi lavora con il metodo Kanban impara presto a gestire il flusso: visualizza il lavoro, limita il WIP, misura il lead time. Quando il lavoro si fa più complesso – progetti con scadenze fisse, risorse condivise tra più attività e dipendenze articolate – è utile affiancare anche il Critical Chain Project Management (CCPM).

Sviluppato da Eliyahu M. Goldratt, il padre della Teoria dei Vincoli, il CCPM parte da una domanda scomoda: perché, nonostante pianificazioni meticolose e stime prudenti, i progetti finiscono quasi sempre in ritardo? La risposta di Goldratt ribalta alcune delle convinzioni più radicate su come gestiamo il tempo e le risorse – e per chi lavora con Kanban, più di un punto risulterà familiare.

La vera causa dei ritardi: non le attività, ma le risorse

La gestione dei progetti tradizionale, basata sul Metodo del Percorso Critico (CPM), si concentra esclusivamente sulla sequenza di attività più lunga per determinare la durata del progetto. L’innovazione fondamentale del CCPM è identificare, invece, la Catena Critica: la sequenza più lunga che considera sia le dipendenze tra i compiti sia le limitazioni delle risorse.

Questo è un cambio di prospettiva radicale. Il vero collo di bottiglia che determina la durata di un progetto non è quasi mai la lista delle cose da fare, ma una persona, un team o un’attrezzatura specifica condivisa tra più attività.

Per capire la differenza, immaginiamo un progetto semplice. Due attività possono partire in parallelo dopo una fase iniziale comune, ma richiedono entrambe la stessa risorsa critica: l’ingegnere capo. Il Metodo del Percorso Critico non vedrebbe problemi, ma il CCPM riconosce subito che le due attività non possono avvenire contemporaneamente. La vera sequenza più lunga – la Catena Critica – deve quindi includere la scelta di quale attività fare prima, rivelando un vincolo che altrimenti resterebbe invisibile fino al momento dell’esecuzione.

L’illusione della sicurezza: come i margini individuali rallentano tutto

L’idea controintuitiva più potente del CCPM riguarda i margini di sicurezza. Tradizionalmente, ogni membro del team aggiunge un margine di tempo alla stima di ogni singola attività per proteggersi dagli imprevisti. Fred, uno dei personaggi del romanzo Critical Chain di Goldratt, porta dati reali della sua azienda: quasi metà delle attività finisce esattamente alla scadenza, pochissime finiscono prima, e circa un terzo finisce con un 10-20% di ritardo rispetto alla stima originale. La sua conclusione è che il margine di sicurezza individuale non protegge né il singolo step né il progetto nel suo insieme.

Questa tolleranza incoraggia comportamenti controproducenti. La sindrome dello studente – termine coniato da Goldratt – descrive il meccanismo per cui, avendo tempo a disposizione, si procrastina fino all’ultimo: quando si inizia a lavorare, il cuscinetto è già stato consumato, e l’attività finisce comunque in ritardo. A questo si aggiunge la Legge di Parkinson: il lavoro si espande fino a occupare tutto il tempo disponibile.

Il CCPM elimina questi margini individuali nascosti. Le stime delle attività diventano più aggressive, basate sul tempo effettivamente necessario per completarle. La sicurezza rimossa viene aggregata e resa esplicita in “buffer” condivisi che proteggono l’intero progetto:

Project Buffer: posto alla fine della catena critica per proteggere la data di consegna finale dall’incertezza accumulata.
Feeding Buffer: inseriti dove le catene di attività secondarie si collegano alla catena critica, per evitare che i ritardi su percorsi non critici impattino su quello principale.
Resource Buffer: utilizzati per garantire che le risorse critiche siano pronte e disponibili esattamente nel momento in cui sono necessarie.

Questo approccio trasforma l’incertezza da un problema individuale a una responsabilità collettiva.

La figura mostra un esempio di rete CCPM. La catena critica – in giallo – segue il percorso A→C→E→F→H. Due percorsi non critici convergono su di essa: il primo attraverso B e D, che si aggancia in H tramite feeding buffer; il secondo attraverso G e I, che si aggancia in F tramite feeding buffer. Il project buffer finale protegge la data di consegna dall’incertezza accumulata sull’intero progetto.

La psicologia del progetto efficace: il project multitasking come causa sistemica dei ritardi

Il CCPM scoraggia attivamente il multitasking, e non si riferisce solo all’abitudine individuale di saltare da un compito all’altro. La forma più dannosa è quella organizzativa: aprire troppi progetti in contemporanea. È una dinamica comune – ogni progetto sembra urgente al momento dell’approvazione, il portfolio cresce, le stesse risorse critiche vengono distribuite su tutto. Il risultato è che nessun progetto avanza davvero, perché ogni risorsa chiave è costantemente interrotta, richiamata, riassegnata.

Goldratt dimostra questo con un esempio quantitativo: una persona che lavora in multitasking su tre attività da dieci giorni ciascuna, alternandosi ogni cinque giorni, vede il Lead Time di ognuna raddoppiare – e questo senza considerare il tempo perso nei cambi di contesto. Il meccanismo diventa poi sistemico: più progetti aperti allungano i Lead Time, Lead Time più lunghi significano più progetti in corso contemporaneamente, e il ciclo si autoalimenta. Goldratt lo definisce esplicitamente “il principale killer del Lead Time”.

La soluzione proposta è controintuitiva: aprire meno progetti contemporaneamente. Non per fare meno, ma per finire di più – perché le risorse critiche possono finalmente completare un lavoro prima di passare al successivo. Chi conosce il metodo Kanban riconoscerà qui la logica dei WIP limit: ridurre il lavoro in corso non è una limitazione, ma la condizione che rende stabile il flusso.

La figura mostra l’effetto in modo immediato: lavorare sulle attività di tre progetti in parallelo raddoppia il lead time di ciascuno. Lo stesso principio del WIP limit si applica sia alle singole attività, che ai progetti presenti nel portfolio.

Un nuovo modo di misurare: non le scadenze, ma il consumo del buffer

Nel project management tradizionale, la domanda chiave è: “Siamo in linea con la tabella di marcia?”. Nel CCPM diventa: “Quanta parte del nostro buffer abbiamo consumato rispetto ai progressi fatti?”.

Per rispondere, il CCPM introduce il Fever Chart (“grafico della febbre”): un grafico che mette in relazione la percentuale di completamento della catena critica con la percentuale di buffer consumato. Le tre zone (verde, gialla e rossa) funzionano come un termometro. La sua forza è predittiva: trovarsi nella zona gialla non significa che il progetto è in ritardo, ma che il rischio di un futuro ritardo è aumentato. Un approccio familiare a chi usa le metriche di flusso del Kanban, come i CFD: anche lì l’obiettivo è anticipare i problemi, non certificare i ritardi.

Il Fever Chart mette in relazione l’avanzamento del progetto con il consumo del project buffer. La curva bianca mostra l’andamento reale: nel nostro esempio il progetto entra in zona rossa nella prima metà, per poi rientrare in zona gialla verso la fine – uno strumento predittivo che non certifica i ritardi, ma li anticipa in tempo utile per intervenire.

Risultati concreti: cosa dicono i casi reali

Il CCPM non è un esperimento accademico. La NASA lo ha utilizzato per gestire le gallerie del vento al Langley Research Center, riuscendo a mantenere il volume di test nonostante un taglio del 50% del personale. Procter & Gamble Pharmaceuticals lo ha adottato nel 2004 per gestire un aumento del carico di lavoro senza risorse aggiuntive, riducendo i tempi di ciclo nei trial clinici. In letteratura le riduzioni documentate delle durate di progetto vanno dal 20% al 40% rispetto ai metodi tradizionali.

Conclusione

Il CCPM è molto più di una tecnica di pianificazione: è una filosofia manageriale che rende l’incertezza visibile, misurabile e gestibile. La vera sfida non è tecnica ma culturale: rinunciare alla protezione individuale per contribuire a una riserva comune. È un cambio di mentalità che richiede fiducia nel sistema – e nella capacità collettiva di tenere insieme ciò che il lavoro individuale tende a frammentare.

Bibliografia

Eliyahu M. Goldratt, Critical Chain, Gower Publishing, 1997.
Andrew G. Hagemann, Use of the Critical Chain Project Management Technique at NASA Langley Research Center, 20th Digital Avionics Systems Conference (DASC), IEEE, 2001.
Michelle Smith, CCPM: A Sustaining Strategy at Procter & Gamble Pharmaceuticals, Pharmaceutical Processing World, 2004.

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.

Dal caos al flusso: note a margine della presentazione di un libro

Il 7 maggio scorso, con Paolo Cavicchioli e con Leonarda Vanicelli che ha moderato la conversazione, abbiamo presentato Dal caos al flusso alla Cascina Sant’Alberto di Milano. Quello che segue non è un resoconto dell’evento, ma un tentativo di mettere a fuoco alcune idee che la conversazione ha fatto emergere – idee che, in parte, non avevo articolato così chiaramente nemmeno nel libro.

Come nasce un libro che non pensavo nemmeno di scrivere

Il libro non nasce da un piano editoriale. Nasce da un blog: una serie di risposte scritte a problemi reali, con un filo narrativo implicito ma non evidente. Quando mi si è presentata l’occasione di utilizzare i contenuti del blog per guidare un’implementazione end-to-end del metodo Kanban in un contesto aziendale articolato, ho cercato una referenza sistematica da dare alle persone coinvolte. Quello che era un archivio di articoli è diventato un indice, e quell’indice è diventato un manoscritto.

La versione disponibile oggi comprende una presentazione di David J. Anderson, che ha visto nel libro un testo scritto a partire dall’esperienza diretta, con spunti pragmatici e attuabili.

Doxee: una fabbrica dell’immateriale

Uno dei casi di studio del libro – e quello centrale della conversazione del 7 maggio – è Doxee, azienda multinazionale con base a Modena che trasforma dati grezzi in documenti dinamici su volumi che Paolo Cavicchioli, suo CEO, ha quantificato in circa 9 miliardi di documenti l’anno. Un numero che, detto così, rischia di scivolare via. Vale la pena fermarcisi un momento: significa che il problema della variabilità, dei picchi di domanda, della sincronizzazione tra reparti con logiche diverse non è un problema marginale. È il problema centrale dell’organizzazione.

Doxee lavora su tre linee: tecnologia proprietaria, prodotti SaaS, e gestione di progetti su commessa. Quest’ultima era storicamente la parte più esposta alle inefficienze sistemiche, con il team di delivery compresso tra una forza commerciale che vende e una tecnologia che evolve, spesso senza che le due cose possano allinearsi con sufficiente anticipo. È in questo contesto che ciò che solo successivamente è stato inquadrato come metodo Kanban ha trovato un terreno non banale su cui misurarsi.

Oggi il team di delivery dialoga con gli altri reparti con pari dignità e gode del “privilegio” di poter affermare con autorevolezza quando qualcosa non è possibile, basandosi su dati oggettivi.

Il problema non era il metodo

Una delle cose che ho raccontato durante la presentazione, e che ribadisco sempre, è che ciò che è stato introdotto in Doxee non lo è stato perché qualcuno aveva letto un libro e voleva provare. È stato introdotto perché il team di delivery stava pagando un costo reale – in ore extra, in turnover, in qualità degradata. Vale anche la pena ricordare che quella implementazione è avvenuta prima che il metodo Kanban venisse codificato formalmente a livello internazionale: era, in senso proprio, un proto-Kanban, una risposta empirica a un problema reale che solo in seguito ha trovato corrispondenza in un metodo. Non è stato calato dall’alto su un’organizzazione. È cresciuto insieme a essa.

E lo strumento decisivo è stato un report all’interno del quale avevo inserito quella che avevo definito, un po’ provocatoriamente, “tolleranza di Marco Re”: una contingency del 15% nella pianificazione, con il mio nome esplicito come referente in caso di critiche. L’idea era semplice: fare da scudo al team mentre si stabilizzava il nuovo regime. Ma l’effetto non era scontato. Funziona solo se chi fa da scudo riesce ad avere credibilità sufficiente da rendere il gesto credibile, e se il team percepisce che lo scudo è reale e non simbolico.

La prevedibilità delle consegne, che nella fase iniziale era molto bassa, ha progressivamente raggiunto valori superiori al 90% dopo la piena implementazione del sistema. Non è un risultato che si ottiene facilmente: richiede disciplina nel limitare il lavoro in corso, l’abitudine di pianificare la capacità in anticipo di settimane, e soprattutto la volontà e il coraggio di dire di no quando la domanda supera la capacità disponibile.

WIP limits, capacità, traffico cognitivo

Tre strumenti hanno fatto la differenza pratica.

Il primo sono stati i limiti al lavoro in corso. Ho usato durante la presentazione l’analogia delle autostrade svizzere, che regolano l’accesso al traffico per evitare gli ingorghi: meno veicoli in ingresso significa velocità più sostenuta per chi è già in carreggiata, maggiore numero di veicoli a destinazione per unità di tempo. Lo stesso principio vale per i team: ridurre il numero di attività in corso aumenta la quantità di attività completate.

Il secondo è stato il capacity planning su orizzonte lungo – fino a dodici mesi – con slot di disponibilità aggiornati regolarmente. La conversazione tra chi vende e chi produce cambia registro quando entrambe le parti guardano lo stesso dato.

Il terzo è stato la strutturazione delle riunioni come momenti di sincronizzazione deliberata, non di escalation improvvisata. Bloccare la pianificazione per periodi di quindici giorni – nessuna nuova priorità inserita senza accordo esplicito e una solida ragione per farlo – ha ridotto il traffico cognitivo asincrono che logora i team più di qualsiasi carico di lavoro.

Un elemento trasversale a tutti e tre è il passaggio dalle stime analitiche al forecast statistico. Invece di cercare di stimare analiticamente ogni attività – esercizio costoso e spesso illusorio nel software – si identificano pattern ricorrenti nel lavoro e si usano distribuzioni storiche per prevedere i tempi. Non è una rinuncia alla precisione: è una forma di precisione più onesta, che riconosce la variabilità invece di ignorarla.

T-shape e contaminazione disciplinare

Paolo Cavicchioli ha portato all’evento una riflessione che merita di essere riportata, perché tocca un tema più ampio della gestione di progetto. La sua esperienza in Doxee con i cosiddetti profili T-shape – persone con una competenza verticale profonda e una capacità orizzontale di collaborare con discipline diverse dalla propria – lo ha convinto che la contaminazione tra culture diverse non è un esercizio di inclusività aziendale, ma un vantaggio competitivo concreto.

L’esempio che ha citato è quello di un laureato in storia, diventato un elemento chiave del team tecnico proprio per la capacità di costruire metafore comprensibili, di semplificare senza banalizzare, di tenere presente la prospettiva dell’utente finale in un contesto dominato da logiche ingegneristiche. Lo stesso ragionamento vale per la gestione di team internazionali: le differenze culturali tra contesti lavorativi italiani, tedeschi e austriaci non si governano ignorandole, ma riconoscendone le logiche e trovando un terreno comune su cui il flusso possa continuare a scorrere.

Nel tempo, Doxee è diventata anche un luogo dove i giovani talenti crescono, sviluppano competenze, e in alcuni casi maturano abbastanza da avviare percorsi imprenditoriali autonomi. È un indicatore di salute organizzativa che non compare in nessun report, ma che dice qualcosa di preciso sulla qualità dell’ambiente di lavoro che si è costruito.

Una nota finale sul miglioramento continuo

C’è un rischio che ho imparato a riconoscere nel tempo e che nel libro chiamo “plateau della presunta eccellenza”: la tendenza delle organizzazioni a fermarsi non appena i risultati diventano accettabili. I miglioramenti iniziali sono spesso rapidi e visibili, il che può essere paradossalmente un problema, perché crea l’illusione che il sistema sia “a posto”.

Il caso Doxee lo conferma: il miglioramento continuo non è uno stato che si raggiunge. È un’abitudine, e come tutte le abitudini, si coltiva con costanza o si perde per inerzia. La differenza tra le organizzazioni che sostengono i risultati nel tempo e quelle che dopo un po’ regrediscono non sta nella qualità degli strumenti adottati, ma nella capacità di continuare a fare domande scomode anche quando le cose vanno bene. È più facile interrogarsi sui propri processi in una fase di crisi che in una fase di successo. Eppure è proprio nel successo che si creano le condizioni per la crisi successiva, se si smette di interrogarsi.

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.

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

CONWIP vs. Drum-Buffer-Rope (DBR): scegliere lo strumento giusto in base alla maturità organizzativa

Durante il recente PMexpo ho riproposto il workshop Dal caos al flusso – sbloccare il potenziale del tuo team con Kanban. Gestire un laboratorio pratico sulla gestione del flusso con Kanban, con circa 40 partecipanti e un’ora e mezza di tempo a disposizione, è una sfida ma anche un’ottima opportunità per far toccare con mano a un pubblico ampio le dinamiche del flusso di lavoro. Abbiamo potuto verificare in modo empirico quanto sia immediato migliorare la produttività applicando la pratica di limitare il lavoro in corso: i partecipanti hanno osservato un incremento di produttività del 50%.

Sempre al PMexpo, in un interessante keynote speech della mattinata dal titolo molto simile – Le Regole del Flusso: dal caos alla gestione efficace negli ambienti multi-progetto – Efrat Goldratt-Ashlag e Gianluca Davico hanno mostrato come la Teoria dei Vincoli (TOC) possa essere applicata per riportare ordine, efficacia e risultati concreti negli ambienti multi-progetto.

Nel metodo Kanban si fa uso di entrambi gli approcci, e questo mi ha portato a una riflessione che voglio approfondire nel seguito dell’articolo: limitare il numero complessivo degli elementi di lavoro presenti nel sistema di flusso – ciò che più avanti definirò come CONWIP – rappresenta la soluzione per far evolvere, nelle prime fasi, le organizzazioni meno strutturate. La Teoria dei Vincoli (TOC), con il suo modello Drum-Buffer-Rope (DBR) – di cui ho già parlato in un precedente articolo – consente invece di gestire sistemi di flusso più maturi e complessi, permettendo di sfruttare in modo sempre più efficace i vincoli man mano che l’organizzazione cresce in capacità e consapevolezza.

Oltre la semplice scelta di uno strumento di pull

Sia il CONWIP (Constant Work-In-Progress) che il Drum-Buffer-Rope (DBR) sono potenti meccanismi di sistema pull (a chiamata), progettati per gestire il flusso di lavoro e migliorare le performance. Tuttavia, il loro utilizzo non è intercambiabile. Sebbene entrambi mirino a creare un flusso più stabile e prevedibile, operano a livelli di complessità e maturità organizzativa diversi. Applicare lo strumento sbagliato al contesto sbagliato può portare a frustrazione e insuccesso; al contrario, allineare la pratica al livello di maturità dell’organizzazione è un passo fondamentale verso un cambiamento evolutivo di successo. Prima di decidere quando utilizzarli, è imperativo comprendere cosa sono e per quale problema fondamentale sono stati progettati.

Definizione e concetti chiave

Per confrontare efficacemente CONWIP e DBR, è essenziale prima comprendere la loro definizione fondamentale e il loro scopo primario all’interno di un sistema di gestione del flusso di lavoro. Sebbene entrambi limitino il lavoro in corso, il loro focus e il meccanismo di controllo sono radicalmente diversi e rispondono a problemi distinti.

CONWIP: stabilire un limite a livello di sistema

Il sistema CONWIP (Constant Work-In-Progress), descritto nella pratica LW 2.1 del KMM, stabilisce un limite al numero totale di elementi di lavoro all’interno dell’intero sistema, indipendentemente dal loro stato specifico. Questo crea un sistema pull di base in cui un nuovo elemento di lavoro può entrare nel flusso solo quando un altro è stato completato e consegnato.

Il KMM lo descrive come un proto-kanban system, sottolineando che mantiene un controllo meno granulare sui singoli stati del flusso di lavoro rispetto a un sistema Kanban più maturo. Tuttavia, la sua forza risiede nella semplicità e nell’efficacia nel ridurre il sovraccarico dell’intero sistema, fornendo al team un primo, potente strumento per gestire il flusso end-to-end e alleviare la pressione generale.

DBR (Drum-Buffer-Rope): ottimizzare sfruttando un collo di bottiglia

Il Drum-Buffer-Rope (DBR), descritto nella pratica IE 5.4 del KMM, è un sistema pull molto più sofisticato, nato come meccanismo di implementazione pratica della Teoria dei Vincoli (TOC). È progettato specificamente per ottimizzare un sistema attorno al suo collo di bottiglia. Il suo meccanismo fondamentale è quello di regolare l’intero sistema in base al ritmo del suo vincolo principale.

Il meccanismo si basa su tre componenti:

Drum (Tamburo): il ritmo di lavoro del collo di bottiglia, che determina la velocità massima dell’intero sistema.
Buffer (Cuscinetto): una scorta di lavoro posizionata strategicamente subito prima del collo di bottiglia per garantirne il pieno sfruttamento e proteggerlo da interruzioni a monte.
Rope (Corda): il segnale che “chiama” nuovo lavoro nel sistema, permettendone l’ingresso solo al ritmo con cui il “Drum” completa il lavoro.

Lo scopo del DBR è di eseguire i passi chiave della TOC: “sfruttare” il vincolo e “subordinare” tutte le altre attività nel flusso di lavoro per proteggerne la capacità, massimizzando così il throughput complessivo.

Questi due approcci, come vedremo, trovano la loro collocazione ideale in fasi molto diverse del percorso evolutivo di un’organizzazione.

Il ruolo decisivo della maturità organizzativa

La scelta tra CONWIP e DBR non è una questione di preferenza tecnica, ma una decisione strategica dettata dal livello di evoluzione e comprensione che un’organizzazione ha dei propri processi. Il loro posizionamento distinto all’interno del Kanban Maturity Model (KMM) evidenzia come l’adozione di determinate pratiche debba essere allineata al livello di maturità raggiunto, per evitare di introdurre una complessità che l’organizzazione non è ancora pronta a gestire.

CONWIP: uno strumento per la maturità di livello 2 (ML2)

Un’organizzazione a livello di maturità 2 (ML2) è descritta nel KMM come “Customer-Driven”. In questa fase, il flusso di lavoro è emergente e, sebbene i processi siano consistenti, i risultati non lo sono ancora, portando a una situazione caratterizzata dall’espressione “mai due volte lo stesso risultato”. La sfida principale è alleviare un sovraccarico sistemico e indifferenziato, dove il vincolo principale non è ancora noto o è in continuo rapido mutamento.

In questo contesto, il CONWIP emerge come pratica di consolidamento ideale. È uno strumento appropriato perché l’organizzazione non è ancora in grado di attuare un’ottimizzazione sistematica. Come nota il KMM, a ML2 “l’organizzazione si affida a manager eroici per accelerare le richieste importanti dei clienti“. I clienti imparano a fidarsi di specifici manager, non ancora dell’organizzazione o dei suoi sistemi. Un meccanismo di controllo semplice e a livello di sistema come il CONWIP è perfetto per:

Introdurre un sistema pull di base senza richiedere una mappatura granulare.
Fornire un sollievo immediato dal sovraccarico generale.
Aiutare l’organizzazione a iniziare a gestire il flusso end-to-end, un passo cruciale per evolvere oltre il focus sui singoli team tipico invece di ML1.

DBR: una pratica avanzata per la maturità di livello 5 (ML5)

Un’organizzazione a livello di maturità 5 (ML5) è descritta come “Market Leader”. A questo livello, l’organizzazione è caratterizzata da una “ricerca incessante della perfezione” e da un’ottimizzazione continua dell’efficienza e delle performance economiche. Possiede un’agilità derivante da un design organizzativo orientato ai servizi ed è in grado di riconfigurarsi prontamente per offrire nuovi servizi. Ha una profonda comprensione quantitativa del proprio sistema stabile e dei propri processi.

Il DBR è una pratica di consolidamento ML5 proprio perché la sua implementazione richiede questo livello di maturità. L’organizzazione ha la capacità di identificare un vincolo unico, sufficientemente persistente e definito che limita le performance dell’intero sistema. Il DBR non è solo una soluzione a un collo di bottiglia; è uno strumento strategico utilizzato da un’organizzazione altamente adattabile per:

Sfruttare un vincolo identificato con precisione per massimizzare il throughput.
Subordinare disciplinatamente tutte le altre attività a quell’unico vincolo.
Allineare l’intero sistema a un obiettivo di ottimizzazione economica, consolidando la propria leadership di mercato.

La scelta, quindi, non dipende solo da quando nel percorso di maturità, ma anche dal perché, ovvero dalla natura del problema che l’organizzazione sta affrontando.

Circostanze d’uso e problemi risolti

Oltre al livello di maturità, le circostanze specifiche e il problema che si sta cercando di risolvere sono determinanti per la scelta corretta dello strumento. CONWIP e DBR sono progettati per affrontare sfide fondamentalmente diverse: la prima mira alla stabilizzazione, la seconda allo sfruttamento.

Quando usare CONWIP: stabilizzare il sistema per gestire il sovraccarico indefinito

Il CONWIP è la scelta ideale quando il problema principale è un sovraccarico generale e non differenziato del sistema, piuttosto che un singolo punto di blocco chiaramente identificato.

Scenario tipico:

Un’organizzazione sta passando da un focus sui team (ML1) a un focus sul servizio (ML2).
Il flusso di lavoro end-to-end è ancora in fase di definizione (“emergente”).
La sensazione prevalente è che “tutto è una priorità” e le persone sono costantemente sovraccariche, ma non è chiaro quale sia il vero vincolo.

In queste circostanze, l’obiettivo primario non è ottimizzare, ma stabilizzare. CONWIP introduce un segnale di pull a livello di sistema che costringe l’organizzazione a finire il lavoro prima di iniziarne di nuovo. Questo riduce il multitasking e permette di creare le condizioni di base per comprendere il sistema e iniziare a misurare un lead time più significativo.

Quando usare DBR: sfruttare un collo di bottiglia definito

Il DBR è appropriato quando l’organizzazione ha raggiunto una comprensione del proprio processo, al punto da aver identificato un collo di bottiglia chiaro e persistente che limita le performance dell’intero sistema.

Scenario tipico:

L’organizzazione ha già un flusso di lavoro stabile e prevedibile (ML3/ML4).
L’analisi quantitativa dei dati di flusso (es. diagrammi di flusso cumulativo) mostra un accumulo costante di lavoro in una fase specifica.
L’obiettivo è aumentare il throughput complessivo agendo in modo mirato su quel singolo vincolo.

In questo scenario, l’obiettivo è sfruttare il vincolo noto per massimizzare il throughput totale. Il DBR fornisce il meccanismo per garantire che il collo di bottiglia non sia mai inattivo (grazie al buffer) e che il resto del sistema non lo sovraccarichi (grazie alla corda), ottimizzando così l’intero sistema attorno al suo punto di leva più efficace. Se il vincolo si sposta, il sistema DBR viene ricalibrato per sfruttare il nuovo vincolo e mantenere il flusso nelle migliori condizioni di performance. Un sistema così equilibrato e ottimizzato può poi essere “elevato” per aumentarne la capacità produttiva.

Conclusione: maturità e contesto guidano la scelta

La scelta tra CONWIP e DBR deve essere una decisione informata, guidata da una valutazione onesta della maturità organizzativa e della natura del problema specifico che si intende risolvere. Il CONWIP è uno strumento di stabilizzazione per un’organizzazione ML2 che affronta un sovraccarico sistemico e indifferenziato. Il DBR è uno strumento di sfruttamento per un’organizzazione ML5 che ha identificato un vincolo definito e possiede la disciplina per ottimizzare l’intero sistema attorno ad esso.

Tentare di implementare il DBR in un’organizzazione a bassa maturità, senza una chiara comprensione del flusso e dei suoi vincoli, è una soluzione rischiosa. Allo stesso modo, limitarsi al CONWIP quando si è raggiunto un maggiore livello di maturità e si ha un chiaro collo di bottiglia, significa lasciare sul tavolo significative opportunità di miglioramento. L’applicazione dello strumento giusto al momento giusto non è solo un principio fondamentale del cambiamento evolutivo, ma un passo cruciale verso il raggiungimento di una maggiore agilità, resilienza e performance aziendale.

Presentazione del libro “Dal caos al flusso” al PMexpo

In occasione del PMexpo, avremo il piacere di presentare in anteprima il mio libro Dal caos al flusso: La trasformazione organizzativa con il metodo Kanban.

Ho raccolto in questo volume una selezione di articoli pubblicati nel tempo, organizzati in modo logico e per argomenti, al fine di facilitarne la lettura e la comprensione.
L’opera intende offrire un approccio pragmatico e operativo al Metodo Kanban, con particolare attenzione all’applicazione concreta dei principi nei contesti organizzativi reali. La pubblicazione è arricchita dalla presentazione di David J. Anderson, ideatore del Metodo Kanban e autore del libro bestseller Kanban: Successful Evolutionary Change for Your Technology Business.

Contenuti e obiettivi del volume

Dal caos al flusso si propone come una guida pratica alla trasformazione organizzativa, con particolare riferimento ai contesti caratterizzati da incertezza e variabilità. Tra i principali temi trattati:

Guidare il cambiamento evolutivo
Il Metodo Kanban promuove un cambiamento incrementale e rispettoso dell’esistente, che parte da ciò che l’organizzazione già fa e valorizza ruoli e responsabilità, riducendo al minimo la resistenza interna.
Controllare il rischio operativo attraverso il flusso
Il concetto di Flow (flusso) è al centro dell’approccio Kanban.
Un flusso stabile e prevedibile costituisce il principale meccanismo di controllo del rischio operativo e consente una consegna di valore sostenibile nel tempo.
Gestire progetti, programmi e portfolio
Il libro introduce i fondamenti del Kanban Project, Programme e Portfolio Management (KPPM), un modello che integra pensiero sistemico, gestione dei flussi e cultura collaborativa orientata allo scopo.
Introdurre pratiche e strumenti operativi
Vengono inoltre presentate le modalità di applicazione dell’approccio STATIK (Systems Thinking Approach to Introducing Kanban) per la progettazione di sistemi Kanban su misura.
Fare leva sui ruoli emergenti
Sono approfonditi anche i ruoli emergenti di Flow Manager e Delivery Manager, figure chiave per garantire la performance del flusso e la responsabilità operativa all’interno dell’organizzazione.

Il Project Manager ridisegnato: da “pompiere” a “risk manager”

Uno dei messaggi del libro riguarda la necessità di una profonda evoluzione del ruolo del Project Manager. Per affrontare la complessità crescente dei contesti organizzativi, il Project Manager deve trasformarsi da figura reattiva — il “pompiere” che interviene a emergenza avviata — a risk manager, in grado di agire in modo proattivo per prevenire criticità e migliorare la prevedibilità dei risultati.

L’adozione di sistemi Kanban consente di rendere le organizzazioni basate sulla conoscenza più stabili, affidabili e orientate al valore, favorendo una gestione strutturata del rischio operativo.

Invito alla lettura

Dal caos al flusso nasce dall’esperienza diretta maturata sul campo e rappresenta un invito alla riflessione e all’azione per tutte le organizzazioni che intendono intraprendere un percorso verso una maggiore agilità e prevedibilità.

Invitiamo i professionisti presenti al PMexpo a visitare lo stand di E-quality Italia per approfondire i contenuti del volume. Chi lo desidera potrà acquistare direttamente allo stand la propria copia di Dal caos al flusso a un prezzo scontato speciale.
Un’occasione per avviare un percorso concreto di trasformazione dal caos al flusso.

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!

Il segreto dell’efficienza di flusso: perché un sistema lavora meglio al 65% del carico massimo teorico

Nell’articolo precedente ho condiviso un’esperienza personale che mi ha confermato, sul campo, come un flusso di lavoro sia davvero efficiente solo quando funziona al 60-70% della sua capacità potenziale. Cercare di spingerlo fino al 100% significa, inevitabilmente, condurlo al collasso: il sistema si satura, rallenta e finisce per bloccarsi.

La spiegazione di questo fenomeno, apparentemente controintuitivo, risiede nella solida base scientifica di un caso particolare della Teoria delle Code, comunemente noto come Legge di Little. Prende il nome da John D. C. Little, professore alla MIT Sloan School of Management, che la ha formulata.

La teoria delle code applicata ai flussi di lavoro

Possiamo visualizzare il nostro sistema come un “tubo di flusso” che eroga un servizio, i cui clienti sono le richieste di lavoro, che chiameremo work item (rappresentati nell’immagine come post-it).

Per analizzare questo sistema, utilizziamo tre concetti chiave:

Lambda (λ): la frequenza con cui arrivano i work item; ovvero, quanto viene caricato il sistema.
Mu (μ): la capacità produttiva del sistema; ovvero, il numero medio di work item serviti dal sistema per unità di tempo.
Work In Progress (Ls o WIP): il numero medio di work item in corso di lavorazione all’interno del sistema.

Nell’ipotesi che la frequenza di carico (λ) e la capacità produttiva (μ) siano costanti, entra in gioco la Legge di Little. Il modello semplificato che andiamo ad applicare si basa anche sulle seguenti ipotesi :

la coda segue una logica FIFO (first-in-first-out, il primo work item in coda è il primo servito)
i work item sono serviti su un unico canale, i tempi di servizio sono indipendenti gli uni dagli altri, seguendo una distribuzione tale per cui “μ” work item per unità di tempo possono essere serviti in media
i tempi di servizio sono indipendenti dal numero degli arrivi

La Legge di Little stabilisce che il WIP (Ls) è uguale alla frequenza di carico (λ) moltiplicata per il Tempo di Ciclo (Ws). Il Tempo di Ciclo è il tempo medio di permanenza di ciascun work item all’interno del sistema.

La Teoria delle Code ci fornisce anche la formula per calcolare il Tempo di Ciclo (Ws) del sistema, nell’ipotesi che la capacità produttiva (μ) sia maggiore della frequenza di carico (λ):

Quando il carico eccessivo blocca il flusso

Per comprendere l’importanza di mantenere non troppo elevato il carico, analizziamo cosa succede a un sistema che ha una capacità produttiva (μ) di 10 work item per ogni giornata lavorativa di 8 ore:

Carico giornaliero (λ)	Tasso di carico	Tempo di Ciclo medio (Ws)	Work In Progress (Ls)	Effetto sul sistema
5 work item	50%	1 ora e 36 minuti	1 work item	Sistema scarico
6 work item	60%	2 ore	1,5 work item	Sistema quasi carico
7 work item	70%	2 ore e 40 minuti	2,3 work item	Ancora accettabile
8 work item	80%	4 ore, quasi raddoppia	4 work item	Limite di stallo
9 work item	90%	8 ore	9 work item	Sistema quasi bloccato
10 work item	100%	Impossibile calcolare	Impossibile calcolare	Sistema in stallo completo

Come si può notare, l’aumento del carico non produce un incremento lineare della produttività, ma una vera e propria impennata del Tempo di Ciclo e del WIP.

Se passiamo da 6 a 8 work item al giorno, il Tempo di Ciclo raddoppia, così come il Work in Progress, che schizza a 4 work item in media. Quando il carico raggiunge 9 work item, il Tempo di Ciclo raddoppia ancora, costringendoci ad aspettare essenzialmente un giorno intero per vedere evaso un singolo work item. Al 100% del carico, le formule indicano un Tempo di Ciclo infinito, ovvero che il sistema si blocca.

Il punto di equilibrio: il 65% circa del carico massimo

In pratica, affinché il sistema mantenga un flusso efficiente, il numero di work item con cui andrebbe caricato è tra 6 e 7. Un calcolo più raffinato ci dimostra che l’ottimale è all’incirca il 65% del carico massimo.

Questo significa che il nostro sistema raggiunge la sua massima efficienza quando lo carichiamo non più del 65% della sua capacità.

Il ruolo delle micro-interazioni

A questo punto potremmo porci una domanda legittima: perché un carico apparentemente basso — circa due terzi della capacità massima — garantisce la massima efficienza?

Questo accade perché, anche se spesso non ce ne accorgiamo, nei sistemi di flusso avvengono costantemente una miriade di micro-interazioni tra tutte le parti che li compongono. Queste interazioni, impercettibili prese singolarmente, nel loro insieme finiscono per rallentare in modo significativo il sistema.

Un esempio emblematico di questo fenomeno sono le code a tratti in autostrada. Quando il traffico raggiunge la saturazione, le auto iniziano a rallentare e fermarsi senza una causa apparente. Questa continua alternanza di frenate e ripartenze nasce da una moltitudine di micro-interazioni tra i veicoli, che, sommandosi, finiscono per bloccare l’intero sistema.

Lo stesso principio vale anche per i nostri flussi di lavoro. È proprio per questo che limitare il lavoro in corso (limit WIP) rappresenta una delle pratiche fondamentali del metodo Kanban.

Conclusione

Per garantire che un flusso di lavoro possa raggiungere la sua massima efficienza in modo sostenibile nel tempo, è di vitale importanza assicurarsi che non sia caricato troppo oltre la soglia del 65% della sua capacità. Ridurre il carico di lavoro non è segno di sottoutilizzo, ma la chiave per accelerare il flusso, ridurre drasticamente il Tempo di Ciclo e aumentare la produttività.

Bibliografia

Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

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.