Tag: Project Management

Pubblicato il

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:

  1. 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à.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Pubblicato il

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

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

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

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

I progetti: non unicità, ma standardizzazione

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

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

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

Perché Kanban funziona per i progetti?

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

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

Il metodo Kanban nella gestione dei progetti

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

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

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

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

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

Conclusione

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

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

Pubblicato il

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

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

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.