Efficienza e motivazione

Il metodo dei 5 whys: una semplice tecnica per raggiungere la radice di un problema

Spegnere continuamente gli incendi è la rovina di molti project manager. Il metodo dei 5 perché ti permette di interrompere questo processo attraverso un’efficace analisi delle cause. Scopri come arrivare al cuore del problema ed eliminare gli errori alla fonte.

Scrivania minimalista con un documento intitolato

Punti chiave:

  • Che cos’è il metodo dei 5 perché e come identifica le cause profonde
  • Come la filosofia Toyota ha dato forma a questa tecnica di risoluzione dei problemi
  • Come condurre un’analisi strutturata dei 5 perché passo dopo passo
  • Gli errori più comuni nell’analisi delle cause profonde
  • Come i project manager usano i 5 perché per risolvere ritardi e problemi
  • Come la combinazione dei 5 perché con Ishikawa migliora la diagnosi

Cos’è il metodo dei 5 perché e chi lo ha creato? La filosofia di problem solving di Toyota

Il metodo dei 5 whys è un lavoro investigativo sul processo. Chiedere ripetutamente “Perché?” ti permette di separare i sintomi superficiali dalle loro vere cause. Mentre la prima risposta dà spesso la colpa all’errore umano, il vero problema si trova di solito più in profondità: nella tecnologia o nella struttura organizzativa difettosa.

Il creatore del metodo dei 5 perché fu Sakichi Toyoda, visionario e fondatore della Toyota Motor Corporation. Nel sistema produttivo giapponese, questa tecnica è diventata il fondamento della cultura Kaizen, ovvero la filosofia del miglioramento continuo e il suo divulgatore, Taiichi Ohno, l’ha definita come un approccio scientifico che evita di cercare i colpevoli a favore della ricerca di soluzioni reali. Ciò è perfettamente illustrato da una classica lezione della fabbrica Toyota su un improvviso arresto di un robot sulla linea di produzione. Invece di accontentarsi di una diagnosi superficiale secondo cui la macchina si era fermata a causa di un fusibile bruciato, il team ha scavato più a fondo e ha scoperto che il sovraccarico del cuscinetto aveva causato la rottura del fusibile. Ulteriori domande hanno rivelato che il sovraccarico era causato da una lubrificazione insufficiente dovuta a un guasto della pompa dell’olio, che aveva smesso di pompare il fluido perché il suo ingresso era intasato da limatura metallica. Alla fine si è scoperto che la causa principale del problema era la mancanza di un filtro. Se il team si fosse limitato a sostituire il fusibile, il guasto si sarebbe ripetuto regolarmente e solo l’installazione del componente mancante avrebbe eliminato definitivamente il guasto.

 

Prova FlexiProject

Goditi l'accesso completo a FlexiProject per 30 giorni, senza costi e senza spese.

FlexiProject

Come condurre un’analisi dei 5 whys passo dopo passo?

Questa tecnica è particolarmente preziosa quando si utilizza la metodologia Waterfall. In un approccio tradizionale e lineare alla gestione, un errore rilevato in una fase tardiva può generare enormi costi e ritardi. Chiedendo ripetutamente “Perché?”, il team è in grado di diagnosticare con precisione in quale punto del rigido processo si è verificato l’errore. Questo permette di apportare modifiche agli standard prima di passare alla fase successiva, cosa che in un ambiente Waterfall è fondamentale per mantenere l’integrità dell’intero progetto.

Anche se questa tecnica sembra super semplice a prima vista, la sua efficacia dipende dalla disciplina del team e dall’accuratezza dell’analisi. Invece di seguire l’istinto, i leader devono basare il processo su dati concreti e sull’osservazione diretta di ciò che sta realmente accadendo. Per fare una buona analisi causa-effetto, devi seguire questi passaggi:

  • Definizione precisa del problema: la chiave del successo è riunire un team direttamente collegato al problema e descrivere la questione con dati specifici. Evitare le generalizzazioni a favore dei fatti (ad esempio, “il 15% delle spedizioni è in ritardo questa settimana”) permette al team di concentrarsi completamente sulla sfida giusta.
  • Identificare la causa immediata: la prima domanda, “perché?”, serve a identificare la ragione più immediata dell’errore. In questa fase è importante che le risposte si basino su fatti e osservazioni verificabili, escludendo ipotesi soggettive.
  • Esplorazione delle cause principali: ripetendo la domanda più volte (di solito cinque), l’analisi viene approfondita. L’obiettivo del processo è quello di arrivare a una causa che l’organizzazione possa realisticamente influenzare.
  • Verifica della logica (test del “quindi”): la coerenza delle conclusioni tratte viene verificata utilizzando un test di logica inversa. Si tratta di combinare le risposte con la frase “…e quindi”. Se una sequenza come “Non c’è lo standard di lavoro e quindi si è verificato un errore dell’operatore” sembra logica, l’analisi è stata eseguita correttamente.
  • Implementazione delle azioni correttive: la fase finale si concentra sulla progettazione e sull’implementazione di modifiche appositamente studiate per eliminare la causa principale identificata. Per assicurarsi che il processo si concluda con successo, è fondamentale produrre un documento chiaro e preciso. sintesi esecutiva che traduce le decisioni strategiche in passi concreti. Questo comporta l’assegnazione di attività specifiche, la designazione di persone responsabili che guidino ogni iniziativa e la definizione di scadenze vincolanti.

L'infografica illustra l'analisi dei 5 perché di un progetto in ritardo, mostrando cinque domande sequenziali

Errori comuni quando si chiede “perché?” durante l’analisi delle cause profonde

Anche un metodo così intuitivo può portare a conclusioni errate se il team cade nelle tipiche trappole cognitive e organizzative durante l’analisi. Ecco gli errori più comuni:

  • Cercare qualcuno da incolpare: concentrarsi sulla persona (“il dipendente ha commesso un errore”) invece che sulla mancanza di standard, formazione o processi di salvaguardia.
  • Domande guida: fare domande accusatorie (ad esempio, “Perché non ti sei assicurato di nuovo di questo?”), che impediscono un’analisi onesta.
  • Terminare troppo in fretta: fermarsi a una risposta superficiale (ad esempio, “la macchina si è rotta”) senza indagare sulle cause tecniche o organizzative.
  • Basarsi su ipotesi: mancata verifica dei fatti.
  • Risposte troppo generiche: frasi come “perché non c’è abbastanza tempo”, che non indicano un elemento specifico del processo da migliorare.

5 whys nella pratica del project manager – analisi dei ritardi e dei problemi ricorrenti dei progetti

Nel lavoro di un project manager, il metodo dei 5 perché fornisce un supporto inestimabile nell’analisi rapida di incidenti, ritardi di sprint o sforamenti di budget. La padronanza della gestione delle attività nei progetti – come pianificare, delegare e monitorare i progressi– è una base essenziale, ma è la tecnica dei “5 perché” che ti permette di capire perché questi piani a volte falliscono. L’applicazione corretta di questo strumento ti permette di evitare costose correzioni e di eliminare gli errori ricorrenti che ostacolano il progresso una volta per tutte.

La potenza di questo strumento è illustrata al meglio dall’esempio di un progetto di costruzione di un sito web che ha subito un ritardo di sei settimane. Alla ricerca delle cause, si può notare che la scadenza è stata posticipata perché la fase di progettazione del mock-up ha richiesto molto più tempo di quanto originariamente previsto. Ciò è dovuto al fatto che il cliente ha ripetutamente richiesto modifiche significative al concept durante il lavoro. Scavando più a fondo, si scopre che la causa principale del problema è stata la mancanza di requisiti dettagliati e dell’ambito del progetto fin dall’inizio. Questa situazione si è verificata perché il programma non prevedeva un workshop di scoperta con i principali responsabili delle decisioni, il che significava che il documento iniziale più importante, la carta del progetto, non conteneva un ambito definito con precisione. L’analisi finale porta alla causa principale: il processo di gara standard dell’azienda non prevede una fase obbligatoria di chiarimento dei requisiti prima della firma del contratto. Grazie a questa scoperta, il project manager può intraprendere un’azione correttiva specifica ed efficace. Invece di limitarsi a spegnere gli incendi nell’ordine corrente, introduce un workshop di scoperta nel normale processo di vendita e implementa regole chiare di gestione delle modifiche.

Combinare i 5 whys con altri metodi (ad esempio, il Diagramma di Ishikawa)

Sebbene il metodo dei 5 perché sia estremamente efficace, se usato isolatamente può talvolta limitare il team a un unico percorso di analisi casuale. Per mitigare questo rischio e garantire un approccio completo, è essenziale trattare questa tecnica come una pietra miliare della gestione flessibile dei progetti: strategie chiave per progetti di successo. Combinando i 5 perché con un diagramma di Ishikawa – spesso indicato come diagramma a lisca di pesce – i manager possono ottenere un quadro diagnostico molto più solido. In questo modo, il diagramma di Ishikawa fornisce la necessaria “ampiezza”, classificando le potenziali cause come le persone, i processi, la tecnologia o i macchinari, mentre il metodo dei 5 perché fornisce la “profondità” necessaria per raggiungere la fonte di un problema.

In pratica, questa sinergia funziona come una mappa mentale, permettendo ai team di visualizzare le connessioni tra le diverse aree operative senza trascurare i punti critici. Facendo prima un brainstorming della struttura di Ishikawa e poi applicando i 5 perché ai suoi rami più significativi, i team evitano di accontentarsi di ipotesi di superficie. Questa metodologia si allinea perfettamente agli Standard A3 e al ciclo PDCA (Plan-Do-Check-Act). In definitiva, questa strategia integrata permette di pianificare azioni correttive che migliorano in modo realistico e permanente gli indicatori KPI e le procedure organizzative in generale.

Dominik Wrzosek
Dominik Wrzosek
General Manager at FlexiProject

Dominik è un esperto di project management e laureato al Politecnico di Varsavia. Guida lo sviluppo del sistema FlexiProject, traducendo le esigenze aziendali in soluzioni pratiche a supporto dei team di progetto. Ha esperienza nell’implementazione di FlexiProject in organizzazioni di diverse dimensioni, combinando competenze tecniche con un approccio orientato al business per una pianificazione e realizzazione efficace dei progetti.