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.
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.
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.
In questo webinar del gennaio 2021, David J Anderson, autore del metodo Kanban, sottolinea come un mito della comunità Agile sia stato clamorosamente sfatato dalla pandemia: non è vero che rendere i team stabili e co-locati fa automaticamente aumentare la collaborazione e la produttività. Nei fatti, abbiamo sperimentato tutti come lavorando in smart-working dal tavolo della cucina di casa siamo più produttivi e la collaborazione con i colleghi non ha subito cambiamenti nella maggior parte dei casi semplicemente perché non c’era nemmeno in ufficio.
La collaborazione in alcune situazioni può essere aiutata dal trovarsi a lavorare nello stesso luogo fisico, ma in generale si costruisce dandosi soprattutto scopo e obiettivi comuni e perseguendoli con costanza, a prescindere dalla stabilità del team e dalla collocazione geografica.
OpenArt AI generated image
Anderson suggerisce quindi un modello per il futuro, che riprende la filosofia del Metodo Kanban: la capacità delle singole persone di pensarsi come una piccola organizzazione orientata ai servizi che lavora in un network coordinato di servizi che costituiscono la più ampia organizzazione aziendale; allo stesso tempo la capacità delle aziende di sviluppare quella che viene definita ‘produttività relazionale’, ovvero imparare a collaborare davvero nel lavoro reale per dare risultati di valore ai propri clienti.
Qui sotto trovate il link al webinar originale su YouTube.
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.
OpenArt AI generated image
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.
Il metodo Kanban ha avuto, fin dalle sue origini, i progetti nel proprio perimetro di applicazione. Nato per gestire i flussi di lavoro dei team IT, il metodo Kanban è stato da subito applicato anche per gestire il lavoro degli stessi team IT quando questi sono impegnati in un progetto.
A partire dagli informatici, la comunità dei project manager si è quindi sempre più interessata al metodo Kanban. Ho già citato in un precedente articolo l’intervento di David J Anderson, creatore del metodo Kanban, al PMI Poland Chapter Congress 2013. Successivamente il metodo Kanban è stato via via menzionato in varie pubblicazioni di project management. Il manuale PRINCE2 Agile del 2015 fa riferimento esplicitamente al metodo Kanban tra le tecniche di product delivery (dedicandogli un capitolo ben fatto) la guida al PMBoK 6th Ed. del 2017 lo cita brevemente (un paragrafo) tra le tecniche di schedulazione, la guida al PMBoK 7th Ed. del 2021 lo cita più diffusamente rispetto alla precedente seppure in modo poco organico.
Teodora Bozheva, co-autrice insieme a David J Anderson del Kanban Maturity Model (KMM) ha ribaltato questa visione residuale e pubblicato nel 2023 una guida specifica dal titolo KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility: il metodo Kanban non più visto all’interno di un progetto come semplice modalità di gestione operativa del delivery, ma più propriamente come leva strategica per supportare una migliore gestione non solo dei progetti aziendali, ma anche dei programmi e del porfolio aziendale di programmi e progetti.
OpenArt AI generated image
Riassumo qui di seguito i concetti principali che stanno alla base del Kanban Project, Programme e Portfolio Management, tratti dal libro.
Il pensiero fondativo del Kanban Project, Programme e Portfolio Management (KPPM)
Il KPPM adotta un approccio scientifico e orientato al problem-solving per la gestione del lavoro di progetto e affronta le sfide reali delle organizzazioni di progetto. Il KPPM si basa su tre elementi fondamentali:
Systems thinking (pensiero sistemico)
Flow thinking (pensiero sulla gestione dei flussi)
Sviluppo di una cultura collaborativa e purpose-driven
Le conoscenze alla base di questi concetti esistono da decenni anche se sono poco conosciuti e applicati nelle aziende di servizi. Il pensiero sistemico in Kanban si basa sulle opere di W. Edwards Deming, Russell Ackoff, Peter M. Senge, Donella Meadows e altri. Il pensiero sulla gestione dei flussi fa riferimento alla Teoria dei Vincoli (TOC) di Eliyahu Goldratt, a Principles of Product Development Flow di Donald Reinertsen, al Toyota Procution System e al Lean Thinking. L’applicazione di questi concetti all’interno del metodo Kanban hanno portato allo sviluppo del Kanban Maturity Model (KMM) che definisce un insieme di valori culturali e pratiche che aiutano a migliorare i risultati di un’organizzazione in modo evolutivo.
Il KPPM amplia e adatta alle organizzazioni di progetto il Kanban Maturity Model (KMM). Il KPPM non è un nuovo metodo di gestione dei progetti. Descrive pratiche che affrontano le sfide croniche della gestione dei progetti, programmi e portfolio e che integrano le conoscenze e i metodi esistenti in materia di project management. Il modello può essere applicato anche in combinazione con metodi Agili, quale ad esempio Scrum.
Systems thinking (pensiero sistemico)
Il Systems Thinking è un modo di vedere un’organizzazione come un sistema di parti interconnesse e di comprendere i suoi comportamenti e risultati come prodotto delle interazioni tra le parti.
I risultati che un’azienda ottiene dipendono dalle azioni congiunte delle sue unità aziendali. Risposte adeguate a circostanze sfidanti possono generare un vantaggio aziendale. Decisioni inadeguate su una buona opportunità potrebbero sprecarla.
Il miglioramento dei risultati di un’organizzazione richiede la focalizzazione su obiettivi comuni, comunicazione e sincronizzazione puntuale, rapidità decisionale e capacità di adattamento. Senza la comprensione dello scopo, le azioni di miglioramento diventano prive di significato e comportano uno spreco di tempo, energia e investimenti. Allo stesso modo, senza la comprensione di come le interazioni tra le unità dell’organizzazione influiscono sui risultati, non è possibile identificare la causa principale dei problemi attuali e proporre un trattamento adeguato che la risolva.
Il Systems Thinking aiuta a prendere decisioni informate che risolvono i problemi dell’organizzazione a partire dalle cause principali e migliorano i risultati complessivi. I manager iniziano a prendere decisioni informate basate sulla comprensione dell’azienda come sistema e sui dati.
Flow thinking (pensiero sulla gestione dei flussi)
La gestione del lavoro con i sistemi kanban consiste nel creare un flusso di lavoro stabile e controllato attraverso un sistema a capacità finita.
Deve esserci una giusta corrispondenza tra i flussi di lavoro, i materiali (o le forniture), le operation, la comunicazione con i clienti e i fornitori per sviluppare e consegnare con successo i risultati dei progetti. Una kanban board deve visualizzare chiaramente lo stato del lavoro in corso (WIP – Work in Progress) e di quello in attesa di essere iniziato. Sia i sistemi sovraccarichi che quelli sottoutilizzati producono risultati non ottimali. In condizioni di forte pressione e stress, gli individui perdono tempo nel multitasking e commettono errori. La loro capacità di consegna e la qualità del prodotto e del servizio peggiorano. I progetti cominciano a ritardare, aumentano i costi e peggiorano la soddisfazione dei clienti e degli stakeholder.
Per migliorare i risultati complessivi dei progetti, le organizzazioni devono utilizzare la loro capacità in modo opportuno. Dare priorità e selezionare un numero sufficiente di progetti da far passare attraverso il sistema garantisce una gestione ben focalizzata e un alto morale dello staff. Per lo stesso motivo, i problemi che bloccano il flusso di lavoro del progetto a causa di informazioni mancanti, attese o rilavorazioni, devono essere risolti il prima possibile.
Creare e sostenere un flusso di lavoro stabile coinvolge tutte le persone dell’organizzazione e richiede la cooperazione con clienti e fornitori. Allo stesso tempo, la creazione di un flusso è vantaggiosa per tutti i livelli dell’organizzazione. A livello operativo, le persone godono di un lavoro focalizzato e di un carico adeguato. I project manager sfruttano i dati di flusso per migliorare la prevedibilità e rispettare con sicurezza le scadenze importanti. I responsabili aziendali apprezzano l’aumento della produttività e dei risultati ottenuti, nonché la maggiore capacità dell’organizzazione di stabilire le priorità e di adattarsi ai cambiamenti del contesto aziendale.
La soluzione è quindi migliorare il flusso dei progetti attraverso una gestione accurata della capacità disponibile piuttosto che espandendo il sistema. Migliorare attraverso processi efficienti è molto più conveniente che cercare nuove persone e investire in strutture e attrezzature.
Sviluppo di una cultura collaborativa e purpose-driven
La cultura è una questione di valori condivisi e di modi di pensare, decidere e comportarsi. I valori e gli obiettivi comuni consentono l’introduzione di pratiche e norme appropriate. La giusta combinazione di principi e pratiche pertinenti porta al raggiungimento di risultati migliori.
Le pratiche semplici che migliorano l’adattabilità delle persone rafforzano le loro abitudini e la motivazione a continuare a migliorare. La padronanza di nuovi modi di lavorare incoraggia nuovi comportamenti. Le pratiche KPPM impegnano le persone a promuovere una cultura di collaborazione, focalizzazione su un obiettivo comune, apprendimento continuo e adattamento.
Panoramica del Kanban Project, Programme e Portfolio Management (KPPM)
Il KPPM comprende un insieme di Principi, Pratiche e Valori culturali che aiutano le organizzazioni a e a prosperare in un ambiente di business mutevole e incerto.
Principi del KPPM
I principi del KPPM definiscono le basi del pensiero, del comportamento e dell’azione in una organizzazione adattiva.
Visibilità Pensare in maniera olistica e visualizzare il lavoro, le informazioni sullo stato del lavoro e altri dati necessari per prendere le decisioni a tutti i livelli dell’organizzazione.
Focus Focalizzare le azioni sulle richieste del cliente e sul purpose del business.
Flusso del valore continuo e bilanciato Creare un flusso continuo e bilanciato di risultati per gestire efficacemente anche il bilanciamento tra richieste del cliente, priorità, rischi e la capacità del sistema di produrre valore.
Feedback rapidi Implementare cicli di feedback rapidi sia all’interno dell’organizzazione, che con clienti, fornitori e mercato, per mantenere sincronizzato il sistema aziendale di creazione del valore.
Cultura collaborativa e purpose-driven Coltivare una cultura della trasparenza, della collaborazione, del pensiero orientato ai risultati e dell’adattamento continuo.
Struttura del KPPM
Il KPPM estende il Kanban Maturity Model (KMM) con ulteriori idee che sono state adattate dalla Teoria dei Vincoli (TOC) e da Lean, e adatta le pratiche del KMM per rispondere alle esigenze delle organizzazioni di progetto.
Livelli evolutivi
Il KPPM è suddiviso su quattro livelli evolutivi:
EL1 Team-Focused I team sono autonomi ma non sincronizzati.
EL2 Customer-Driven I team sono sincronizzati in un flusso end-to-end di progetto.
EL3 Oucome-Driven Tutti gli obiettivi del delivery system vengono continuamente raggiunti attraverso un flusso bilanciato e sostenibile
EL4 High Performing Risultati aziendali di rilievo grazie alla cultura dell’eccellenza e del miglioramento continuo
Pratiche
Le organizzazioni di progetto devono pianificare il lavoro, monitorare l’esecuzione di progetti, programmi e portfolio (incluso quello strategico), apprendere e adattarsi ai cambiamenti e misurare i propri risultati.
A supporto di queste attività il KPPM definisce quattro gruppi di pratiche:
Plan 9 pratiche basate sulle pratiche generali Kanban Visualizza e Gestisci il Flusso
Communicate and align 45 pratiche basate sulle pratiche generali Kanban Visualizza, Implementa Cicli di Feedback ed Esplicita le Policy
Monitor and adjust 24 pratiche basate sulle pratiche generali Kanban Visualizza, Gestisci il Flusso ed Esplicita le Policy
Learn and adapt 9 pratiche basate sulla pratica generale Kanban Migliora Collaborando, Evolvi Sperimentando
Valori culturali
I valori culturali promossi dal KPPM, suddivisi per livello evolutivo, sono:
EL1 Team-Focused
Transparenza
Collaborazione
Prendere iniziativa
EL2 Customer-Driven
Coordinamento tra team di specialisti e fornitori
Atti di leadership
Rispetto
Fiducia
Cambiamento evolutivo
EL3 Oucome-Driven
Fitness for Purpose
Leadership a tutti i livelli
Accordo e comprensione comune
Unità e allineamento
Bilanciamento
Servizio al cliente
Risultati e conquiste di breve termine
Apprendimento sperimentale
EL4 High Performing
Capacità di anticipare piuttosto che di reagire
Capacità di migliorare continuamente
Equità
Sviluppo della leadeship
Conclusione
Lo sviluppo dell’agilità organizzativa, anche nella gestione di progetti, programmi e portfolio, è un percorso da far progredire nel tempo. Gradualmente coinvolge tutto il personale dell’azienda nella revisione e adattamento dei processi organizzativi e delle policy, in modo tale che l’azienda possa adattarsi e avere successo nell’attuale ambiente di business mutevole. Il metodo Kanban e il KPPM possono supportare efficacemente questo percorso.
Prossimamente pubblicherò su questo blog alcuni brevi casi pratici esemplificativi di applicazione del KPPM a progetti aziendali ai quali ho patecipato.
Bibliografia: Teodora Bozheva | KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility David J Anderson – Teodora Bozheva | Kanban Maturity Model (2nd Edition) | Kanban University Press
Riporto in questo articolo uno stralcio del testo (la traduzione è mia) di quanto detto da David J Anderson, creatore del metodo Kanban, in una breve intervista al termine del PMI Poland Chapter Congress 2013 (trovate il link al video originale più sotto). Il video è di dieci anni fa ma il messaggio è sempre attuale e davvero importante per chi svolge il ruolo di project manager: il project manager è un risk manager e non un pompiere.
OpenArt AI generated image
Il project manager come risk manager
“David, potresti dirmi che cosa i partecipanti dovrebbero ricordare dopo il tuo intervento?”
“Credo che il principale messaggio del mio intervento sia stato che i project manager passano troppo tempo su attività prettamente amministrative, attività di segreteria per organizzare riunioni, programmare il lavoro di persone, coordinare, raccogliere informazioni, diffondere le informazioni, comunicare, mentre quando non fanno questo la loro attività è spengere gli incendi e hanno l’immagine di sé del tipo: “Sono un eroe, sono il pompiere e non funzionerebbe nulla senza la mia presenza”. Mi piacerebbe invece che si reinventassero come Risk Manager per le loro aziende e quello che abbiamo fatto con i sistemi Kanban è stato rendere il service delivery e le organizzazioni di knowledge worker (c.d. ‘lavoratori della conoscenza’, ovvero attivi in professioni intellettuali, quale ad esempio l’informatica – n.d.t.) molto più prevedibili, affidabili, attendibili e degne di fiducia.
Quindi, se il project manager può fidarsi si tutto quello che succede e (il progetto – n.d.t.) ha trasparenza e visibilità, molto del lavoro di segreteria si riduce e i fuochi non bruciano più. E però spesso i project manager si fermano a questo punto: “e adesso cosa faccio?! Tutto il mio lavoro è reso inutile da questa cosa del Kanban!” E invece io vorrei che passasse il messaggio che ci sono molte, ma molte più opportunità di portare davvero valore aggiunto alle loro organizzazioni se gestiscono meglio i rischi”.
Questa è la storia di un’azienda tecnologica italiana che per la gestione dei propri progetti ha applicato PRINCE2 a partire da un approccio waterfall e successivamente, per migliorarne l’efficacia, ha sviluppato un’applicazione originale dei principi e del modo di lavorare lean. Perché lean e Kanban possono migliorare l’applicazione di PRINCE2.
Vista in retrospettiva dal punto di vista del Kanban Maturity Model (KMM – Modello di Maturità Kanban), questa è la storia di un percorso evolutivo verso l’agilità organizzativa che si è sviluppato nell’arco di un decennio da Team-Focused (livello di maturità 1) a Risk-Hedged (livello di maturità 4) e oltre, con la maggior parte dei principi e delle pratiche del Metodo Kanban che oggi si possono rintracciare in tutta l’organizzazione.
Questa è la storia di una prova provata che il metodo Kanban funziona!
Il sistema di Rolling Forecast applicato inizialmente per gestire la schedulazione
Il Case Study analizza come si è giunti ai seguenti miglioramenti del delivery e del project management di Doxee, a fronte di un carico di lavoro che nel 2023 è dieci volte superiore a quello del 2012:
ogni attività di lavoro è sotto controllo
la prevedibilità complessiva del delivery ha raggiunto un grado di confidenza e un livello di servizio superiore al 90%
gli extra costi di progetto imputabili ai team si sono azzerati
tutte le richieste di cambiamento al progetto provenienti dai clienti sono identificate e gestite tempestivamente
