Il Margine Sta Calando e Non Avete Sei Mesi per Scoprire Perché

Eseguite uno sprint di sei settimane che diagnostica la causa radice da inizio a fine e testa una soluzione direttamente nell'operazione, con un checkpoint di go/no-go alla settimana due così una direzione sbagliata viene individuata presto invece che scoperta alla fine di un impegno di sei settimane. La velocità viene dal lavorare nell'operazione stessa invece che in una struttura di progetto separata che deve riportare risultati prima che qualcosa possa cambiare.

Iniziate con un'analisi del processo da inizio a fine e interviste con chi svolge il lavoro, sanno quasi sempre dove si rompe, anche se nessuno glielo ha mai chiesto formalmente. L'erosione del margine raramente è un mistero per chi è più vicino al processo; è di solito un mistero per la direzione proprio perché l'informazione non viaggia verso l'alto attraverso i livelli di reporting che altrimenti la porterebbero alla luce.

Percorrete il processo fase per fase, prestando particolare attenzione alle consegne tra dipartimenti, dove la proprietà spesso scompare e nessuno è pienamente responsabile di ciò che accade in quel vuoto. La maggior parte dei problemi di performance che sembrano complessi da lontano si concentrano in uno o due punti di consegna specifici una volta che il processo viene davvero mappato passo per passo invece di essere revisionato dipartimento per dipartimento in isolamento.

Un ciclo diagnosi-soluzione-esecuzione-ancoraggio delimitato nel tempo, con un checkpoint di go/no-go alla seconda settimana e una soluzione o business case definiti alla fine, strutturato così il team sa nelle prime due settimane se la direzione scelta funziona. Le quattro fasi vengono eseguite in sequenza ma restano rigorosamente delimitate nel tempo, evitando che lo sprint si espanda silenziosamente verso il tipo di progetto di mesi che è specificamente progettato per evitare.

I processi standardizzabili e le consegne rotte possono essere risolti completamente; i problemi di architettura dei sistemi o design organizzativo tipicamente producono un piano solido e un business case invece di una soluzione finita, poiché questi cambiamenti di solito richiedono investimenti e scadenze che una finestra di sei settimane non può consegnare responsabilmente. Sapere in quale categoria rientra un problema prima di iniziare è ciò che permette allo sprint di promettere un risultato specifico e onesto invece di uno aperto.

Delimitate il problema a ciò che uno sprint di sei settimane può davvero produrre, e dite fin dall'inizio quale dei due risultati si applica, una soluzione funzionante o un business case completamente costato, invece di lasciare che l'ambito del progetto si espanda verso qualcosa di più lungo e aperto una volta partito. La maggior parte dei problemi operativi non ha davvero bisogno di sei mesi di analisi per essere capita; ha bisogno di sei settimane di lavoro concentrato, dentro l'operazione.

Mappate il processo da inizio a fine tra dipartimenti, il punto di consegna spesso rivela il vero problema, non ogni dipartimento separatamente, poiché il racconto di ciascuno è spesso accurato per la propria parte del processo pur perdendo ciò che accade nel vuoto tra loro. Nessun dipartimento ha torto; entrambi descrivono semplicemente la parte dell'elefante che possono davvero vedere.

Sì, risolvete prima il problema operativo urgente con uno sprint; il lavoro di strategia aiuta solo una volta che c'è margine per guardare oltre questo trimestre, e un team di direzione che sta spegnendo un incendio operativo attivo raramente ha la capacità di impegnarsi davvero su questioni strategiche a lungo termine. Sequenziare lo sprint prima del lavoro di strategia spesso porta alla luce realtà operative che dovrebbero davvero informare la strategia che segue.

Risolvete prima il collo di bottiglia del processo e i fallimenti di consegna, spesso il vero limite, non l'organico, poiché molti problemi di produttività che sembrano carenza di personale sono in realtà un processo che gioca contro chi cerca di eseguirlo. Aggiungere organico a un processo rotto di solito produce solo più output che passa attraverso lo stesso collo di bottiglia, senza davvero risolvere il vincolo sottostante.

Percorrete l'intera catena passo per passo, incluso ogni consegna, invece di revisionare i dipartimenti isolatamente, poiché il collo di bottiglia ha una probabilità sproporzionatamente alta di trovarsi proprio nel punto in cui la responsabilità passa da un team all'altro. Una revisione dipartimento per dipartimento di solito trova che ognuno performa ragionevolmente bene ai propri termini, proprio per questo spesso perde il vero vincolo.

Per problemi troppo strutturali per sei settimane, lo sprint stesso produce come risultato il business case completamente elaborato, con sforzo, risorse, rischio e una data di inizio definita, invece di lasciare quel lavoro a qualcun altro dopo con meno conoscenza diretta del problema. Così le sei settimane producono comunque qualcosa di immediatamente utilizzabile, anche se la soluzione sottostante richiede più tempo per essere implementata.

Terminate con un piano di ancoraggio che nomina un responsabile, un metodo di misurazione, e una risposta se la performance retrocede, poiché un miglioramento che si sostiene solo finché c'è attenzione esterna su di esso non è davvero un miglioramento, è uno stato temporaneo. Il piano di ancoraggio è ciò che trasforma una soluzione di sei settimane in un cambiamento duraturo, invece di un risultato che silenziosamente si inverte qualche mese dopo che l'attenzione di tutti si è spostata.

Sessioni brevi e intensive che testano immediatamente la fattibilità delle direzioni di soluzione, con esperimenti su piccola scala prima del rollout completo, invece di una lunga fase di analisi seguita da un unico grande rollout senza possibilità di correggere la rotta. Testare le direzioni su piccola scala prima significa che un approccio difettoso viene individuato mentre è ancora economico cambiarlo, invece che dopo essere stato dispiegato in tutta l'operazione.

Diagnosticate prima la vera causa radice, inseguire sintomi su più fronti contemporaneamente spesso risale a una o due cause reali, il che significa che la lunga lista di cose che sembrano rotte spesso ha dietro una lista molto più corta di problemi reali. Risolvere la causa radice di solito risolve diversi sintomi apparentemente separati contemporaneamente, un uso molto migliore della capacità limitata rispetto a trattare ogni sintomo come un problema indipendente.

Definite il metodo di misurazione come parte del piano di ancoraggio alla fine dello sprint, legato all'enunciato originale del problema, così il successo viene giudicato rispetto a ciò che era specificamente rotto e non a una sensazione generale che le cose vadano meglio. Un metodo di misurazione deciso in anticipo, prima di implementare la soluzione, elimina anche la tentazione di scegliere retrospettivamente la metrica che risulta più favorevole.