Diagramma di Ishikawa
nel Project Management

Il diagramma di Ishikawa (anche detto di causa/effetto o a lisca di pesce), è uno strumento utilissimo nel Lean, Waterfall, Agile Project Management. Questo perché, purtroppo, a prescindere dalla metodologia con cui operiamo, avremo sempre e comunque problemi da risolvere!

Il diagramma è stato ideato in Giappone nel 1943 da Kaoru Ishikawa per individuare il rapporto causa/effetto nel processo produttivo in ambito manifatturiero.

Oggi il metodo è stato ampliato e viene applicato da manager di diversi ambiti, come per esempio marketing, sviluppo software, logistica, ecc.

Quando e perché è utile usare il diagramma di Ishikawa nel Project Management?

Il diagramma trova la sua utilità quando abbiamo necessità di individuare le possibili cause che generano un problema. Non ci fornirà la soluzione, ma nel caso di un problema complesso che può essere originato da molte cause, ci permetterà di restringere il campo.

La sua creazione poi, coinvolge tutto il team. Ogni persona è quindi responsabilizzata e incoraggiata a partecipare attivamente alla risoluzione del problema. Questo fa anche sì che tutti conoscano il processo nel suo insieme e non solo in verticale a seconda della propria sfera di competenze.

Infine, il risultato finale è un grafico molto semplice e per tutti facile da leggere.

A seguire lo vedremo rappresentato con struttura a 6M (originariamente 4, poi estese a 5 con Mother Nature e poi a 6 con Measurement).

Le 6 M a cosa corrispondono?

• Macchine. Macchinari (tra cui anche pc, periferiche, infrastruttura informatica, connessione internet, ecc.), livello di usura, manutenzione.
• Metodi. Metodologia operativa, tempi di lavorazione, gestione progetto.
• Manodopera. Formazione del personale, operatività, capacità organizzativa, esperienza, efficienza.
• Materiali. Materiale utilizzato, durabilità, usura, qualità del materiale. In ambito marketing, qualità di banche dati, di immagini, testi, ecc.
• Misurazione. Sistemi di misurazione della produzione, dei risultati, della qualità, Metriche, KPI.
• Ambiente (Mother nature). Ambiente lavorativo e contesto, ambiente esterno inteso anche come posizione geografica.

Come si usa per il problem solving nel Project Management?

1. Si identifica il problema oggetto di analisi.
2. Tutte le persone coinvolte nel problema partecipano al brainstorming.
3. Ogni partecipante esprime la propria opinione e elenca le possibili cause del problema rispondendo ai 5 perché.
4. Le cause vengono suddivise in base al gruppo di appartenenza (macchine, manodopera, metodi, materiali, ambiente, misura).
5. Se una causa è complessa, si tracciano i sottoinsiemi. Se può essere imputata a più gruppi, la si riporta in ogni gruppo di appartenenza.
6. Attenzionare settori del grafico che hanno poche cause. Questa parte del processo è molto importante, perché spesso accade che si formulino idee sulla base di preconcetti. Ovvero si pensa di sapere già la causa e quindi la soluzione al problema (Bias di conferma). Nel caso in cui ci fossero aree con poche idee, quindi, stimolare il team con i 5 perché.
7. Dopo aver individuato tutte le possibili cause, grazie al Principio di Pareto 80/20 si procede alla loro analisi e alla scelta delle cause più frequenti/probabili. Per poter utilizzare l’80/20 ci occorrerà, per ogni causa, l’incidenza (ovvero il numero di volte che si è verificata).
8. Basterà eliminare il 20% di queste cause, per eliminare l’80% degli effetti.
9. In alternativa al Principio 80/20, i membri del team assegnano un punteggio o peso ad ogni causa. Le 5 cause con peso/punteggio maggiore vengono identificate come quelle più probabili a causare l’effetto. Si andrà quindi ad agire su queste e si monitoreranno i risultati.

Ambito di applicazione

Il Diagramma di Ishikawa può essere applicato a diversi settori. Basterà adattare le 6 M (tutte o alcune di queste), con le aree chiave del nostro prodotto o servizio.

Per esempio, per analizzare il rapporto causa/effetto su una campagna di Digital Marketing, potrebbe essere utile indagare tra le cause anche: Prezzo, Promozione, Prodotto, ecc.

Attenzione però alle sostituzioni che facciamo. Potremmo commettere l’errore riportato al punto 6 (Bias di conferma) e togliere proprio il settore relativo alla vera causa del problema.

Per esempio: togliamo l’Ambiente dal diagramma perché partiamo dalla convinzione che il problema avuto su una campagna Marketing non possa dipendere da questo. Scopriamo poi, che la campagna non ha funzionato perché c’è stata diversità di risposta alla stessa in base al territorio di appartenenza degli utenti.

Il mio consiglio è di togliere un settore dal diagramma solo dopo essersi accertarti che il problema non sia ascrivibile proprio a questo.

Per cui:

Sì a personalizzazioni. A mio parere e in generale, ogni metodo deve essere adattato in base alla situazione, all’azienda che lo applica e alle persone che la compongono.

No agli stravolgimenti fatti senza analisi. Se cambiamo tutto, stiamo applicando un altro metodo. Non è detto che sia meno efficace, ma è altro e potrebbe portarci fuori strada.

“Fate in modo che diventi un’abitudine discutere i problemi basandosi sui dati e rispettando i fatti che essi dimostrano”

Kaoru Ishikawa