Come funziona Kanban: il Delivery Manager e la responsabilità in un sistema Kanban

Nel metodo Kanban non sono indicati specificamente dei ruoli, con tre eccezioni: una di queste è il ruolo di Service Delivery Manager (SDM). Come mai un metodo che non prevede ruoli, ne indica alcuni? Non è questa una contraddizione? In realtà no, perché tali ruoli sono dei cosiddetti ‘ruoli emergenti’, si possono empiricamente osservare nelle aziende che applicano il metodo.

Inoltre il contenuto che viene dato a tali ruoli è coerente con la filosofia del metodo. Ovvero gestire un flusso di lavoro, o meglio ancora un sistema di lavoro. E lasciare che le persone si organizzino intorno ad esso. Il ruolo di Service Delivery Manager emerge perché sviluppando ed evolvendo un sistema Kanban viene a delinearsi l’esigenza di una ‘accountability’ sul flusso di lavoro.

L’esigenza di una accountability

Va ricordato che il termine ‘accountability’ in inglese ha un significato più forte rispetto alla semplice ‘responsibility’, termini entrambi normalmente tradotti in italiano con ‘responsabilità’. In italiano il termine ‘accountability’ non ha un vero corrispondente perché ha un significato più stringente. Esprime la responsabilità personale ultima, necessariamente in capo a un singolo, che ha il dovere di giustificare le proprie azioni e decisioni e rispondere del proprio operato. Contiene anche con un’implicita valenza di “responsabilità morale a operare bene” e in caso contrario a “pagare di persona” (account = conto, rendiconto).

Se un’organizzazione implementa un sistema Kanban è necessario che ci sia un presidio chiaro che si curi di farlo funzionare in modo adeguato e coerente. E allora emerge l’esigenza di assegnare un’accountability chiara a un Service Delivery Manager.

Ho già parlato in un case study di una mia esperienza di alcuni anni fa. In quell’occasione, grazie alla felice intuizione del CEO, mio diretto responsabile, mi sono ritrovato nel ruolo di Delivery Manager. Da lì ho avuto la possibilità, ma anche la responsabilità, di implementare un sistema Kanban. In quel caso l’emergere del ruolo ha facilitato l’emergere del sistema e viceversa.

Il focus di tale ruolo deve restare comunque sulla gestione del flusso di lavoro e del sistema e non sulla gestione delle persone. Quali sono quindi le responsabilità, o meglio le accountability, del Service Delivery Manager?

L’immagine (fonte Kanban University) mostra il focus del Service Delivery Manager sulla gestione del flusso di lavoro

Le responsabilità del Service Delivery Manager in un sistema Kanban

Le funzioni tipiche del Service Delivery Manager sono le seguenti:

  • Gestire il flusso di lavoro, cioè l’evasione delle richieste di lavoro dei clienti.
  • Facilitare il Delivery Planning Meeting.
  • Gestire la Service Delivery Review.
  • Guidare l’identificazione, l’analisi e la risoluzione degli impedimenti nel flusso di lavoro, come ad esempio blocchi, rilavorazioni e elementi di lavoro da troppo tempo in lavorazione.
  • Supervisionare la gestione delle dipendenze e le cause assegnabili per i ritardi nell’erogazione dei servizi che non hanno soddisfatto le aspettative del cliente o gli SLA.

Più nello specifico il Service Delivery Manager deve assicurarsi che il sistema Kanban funzioni correttamente. Cioè deve assicurarsi che le seguenti tipiche attività di gestione del flusso siano svolte da tutto il team per mantenere il flusso di lavoro stabile e prevedibile:

  • Visualizzare il lavoro: utilizzare uno strumento, fisico o digitale, per rappresentare visivamente il flusso di lavoro, per mantenere sotto controllo lo stato di ogni elemento di lavoro, darne visibilità a tutta l’azienda.
  • Definire le policy di lavoro e in particolare limitare il lavoro in corso (WIP): per gestire il flusso in modo efficace, è importante limitare il numero degli elementi di lavoro che possono essere “in corso” contemporaneamente. Questo impedisce al team di disperdere le energie su troppi fronti e di generare inefficienze. Fare in modo che le policy siano concordate e visibili a tutte le persone coinvolte.
  • Monitorare i tempi di ciclo (Lead Time e Cycle Time): il Lead Time indica il tempo totale che intercorre dall’inizio alla fine di un’attività (il tempo visto dal cliente), mentre il Cycle Time misura il tempo che impiega il team per completare il lavoro da quando si impegna a svolgerlo. Monitorare questi parametri è essenziale per mettere a punto livelli servizio e pianificazione realistici e individuare le aree in cui il flusso è rallentato e dove si può intervenire per migliorare.
  • Individuare i colli di bottiglia e le cause di blocco del flusso: analizzando costantemente i dati sul flusso, si potranno identificare i colli di bottiglia, cioè i punti del processo dove il lavoro si accumula e rallenta. Potrebbe trattarsi di una fase specifica del processo o di una risorsa che non è disponibile al momento giusto.
  • Intervenire per migliorare: una volta identificati i problemi, il team deve agire per risolverli. Ad esempio, se il collo di bottiglia è in fase di revisione del lavoro, potrebbe essere necessario assegnare più risorse o rivedere le modalità di gestione delle revisioni stesse.
  • Implementare incontri di feedback con una cadenza appropriata: incoraggiare la collaborazione, l’apprendimento e i miglioramenti. Analizzare i dati e lasciarsi guidare dai dati.

Conclusione

In conclusione il Service Delivery Manager nel metodo Kanban può svolgere una funzione cruciale nel garantire il corretto flusso di lavoro, supportando il miglioramento continuo, aiutando il team a ottimizzare i processi e a rispettare gli SLA. Inoltre, può contribuire a massimizzare il valore del servizio erogato al cliente, assicurando un’erogazione puntuale e di qualità.

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.

Prince2 e responsabilità nei progetti

In questo ultimo anno ho avuto modo di riflettere parecchio sul concetto di responsabilità nei progetti, e su come questo venga pensato e attuato in contesti socio-culturali diversi. L’occasione di riflessione me la ha data ancora una volta la struttura della metodologia di project management che applico e anche insegno, Prince2.

Ben tre dei sette principi che sono a fondamento di Prince2 sono direttamente a supporto di un sostanziale meccanismo di “accountability”, per usare il termine inglese che ha un significato più forte rispetto alla semplice “responsibility”, termini entrambi normalmente tradotti in italiano con “responsabilità”. Ma il termine inglese accountability in italiano non ha un vero corrispondente perché ha un significato più stringente, esprime la responsabilità personale ultima, necessariamente in capo a un singolo, che ha il dovere di giustificare le proprie azioni e decisioni e rispondere del proprio operato, anche con una forte implicita valenza di “responsabilità morale a operare bene” e in caso contrario a “pagare di persona” (account = conto, rendiconto).

Se vogliamo davvero capire Prince2 e applicarlo in modo efficace dobbiamo, secondo me, pensare la responsabilità in termini di accountability come appena descritta. I principi Prince2 di “Giustificazione commerciale continua“, “Ruoli e responsabilità definiti” e “Gestione per eccezione” fanno riferimento a questo concetto.

Visto da una prospettiva italiana si fa un po’ fatica a immaginarsi un sistema di gestione dei progetti in cui esista una delega vera accompagnata da un’autonomia decisionale dei vari livelli gestionali, un ‘supremo’ del progetto (che Prince2 chiama Executive) che deve decidere costantemente se il progetto ha e continua ad avere un senso, nel caso non lo abbia più intervenire ‘senza pietà’ per risparmiare risorse e, in ogni caso, rispondere del progetto in prima persona. Del resto Prince2 è nato in Gran Bretagna, nella pubblica amministrazione (anche questo noi italiani facciamo fatica a immaginarlo!), quando era primo ministro una tale signora Thatcher. In Italia, al contrario, solo a enunciare certi concetti si incontra un misto tra rassegnazione allo status quo e resistenza al cambiamento.

Eppure rimango dell’idea che l’adattamento di Prince2 all’ambiente di progetto specifico, in Italia, richieda  un’adeguata comprensione del salto culturale che questo implica e una buona dose di adesione al principio anglosassone di “accountability”: nella mia esperienza l’impiego di Prince2 è stato tanto più efficace quanto più i committenti del progetto hanno accettato e metabolizzato tale passaggio culturale.