Día: 15 de noviembre de 2026

Tear drop, Ishikawa or indented list: a guide to choosing a format for a 5 Whys analysis

#PI_DECIDE #misconceptions

[Una versión en castellano está disponible aquí.]

In the post on what usually goes wrong in a 5 Whys diagram I explained why I prefer the tear drop format to the Ishikawa diagram, with an animation that rebuilt the process from a case of flash on an injection moulding line.

I have extended that analysis with three animations of the same case and an interactive guide that works as the entry point to everything else. The guide starts with three questions (where the group will work, how it usually gets started and what you need at the end) and gives back a recommendation. Below that there is a map with twelve criteria where each format is marked according to whether it helps, depends on the case or gets in the way, and clicking a row opens a longer comment.

The animations are the tear drop, the Ishikawa and the indented list. The tear drop one ends by showing the Mermaid code, which is a quick way of turning sticky notes into plain text without losing the relationships. For anyone who prefers to see it all at once there is also a summary table with the same criteria.

Even though I prefer the tear drop diagram, it has its own traps. Since there are no categories reminding you of other areas, it encourages tunnel vision (the first branches get explored in depth and the drop looks finished even if a whole branch is missing), and it shares blank page syndrome with the list. That is where the Ishikawa’s 6Ms do help, although I still use them as a checklist to get started or to review at the end, not as the structure of the diagram.

Another point worth noting is whether a single sticky note can have two arrows going to different branches. In the Ishikawa there is no option but to write the note twice, and in the list you have to repeat the line or leave a reference like “see line 8”, which then has to be kept up to date. In a tear drop diagram you just add another relationship.

The list has more going for it than it seems. For remote work with people who aren’t at ease on digital whiteboards (more common than we tend to assume) it is probably the safest option, and moving a whole branch is just cut, paste and Tab. What it loses is the overall view: with twenty lines you can no longer see which branch has stopped short.

References:

Marin-Garcia, J. A. (2026, [month day]). From first draft to root cause: What usually goes wrong in a 5 Whys diagram [Blog post]. Blog de Juan A. Marin-Garcia. https://jamg.blogs.upv.es/4585/

Marin-Garcia, J. A., Garcia-Sabater, J. J., Garcia-Sabater, J. P., & Maheut, J. (2020). Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), 49–68. https://doi.org/10.4995/wpom.v11i2.14776

Visitas: 3

Gota, Ishikawa o lista indentada: una guía para elegir formato en un análisis de 5 porqués

#PI_DECIDE #misconceptions

An English version is available here.

En la entrada sobre qué suele fallar en un diagrama de 5 porqués explicaba por qué prefiero el formato en gota (“tear drop”) al Ishikawa, con una animación que reconstruía el proceso a partir de un caso de rebaba en una línea de inyección. 

He ampliado ese análisis con tres animaciones del mismo caso y una guía interactiva que sirve como punto de entrada a todo lo demás. La guía empieza con tres preguntas (dónde va a trabajar el grupo, cómo suele arrancar y qué necesitas al terminar) y devuelve una recomendación. Debajo hay un mapa con doce criterios en el que cada formato aparece marcado según ayude, dependa del caso o estorbe, y al pulsar cada fila se abre un comentario más desarrollado. 

Las animaciones son la de la gota, la del Ishikawa y la de la lista indentada. La de la gota termina enseñando el código Mermaid que es una forma rápida de convertir los posits en texto plano sin perder las relaciones. Para quien prefiera verlo todo de golpe hay también una tabla resumen con los mismos criterios.

A pesar de que prefiero el diagrama de gota, éste también tiene sus trampas. Como no hay categorías que recuerden otros frentes, favorece la visión de túnel (se profundiza en las primeras ramas y la gota parece terminada aunque falte una entera), y comparte con la lista el síndrome de la página en blanco. Ahí las 6M del Ishikawa sí ayudan, aunque yo las sigo usando como lista de comprobación para arrancar o para repasar al final, no como estructura del diagrama. 

Otro aspecto a remarcar es si un mismo posit puede tener dos flechas hacia ramas distintas. En el Ishikawa no queda más remedio que escribir la nota dos veces, y en la lista hay que repetir la línea o dejar una referencia del tipo “ver línea 8” que luego hay que mantener al día. En un diagrama de gota añades una relación y ya está.

La lista tiene más a favor de lo que parece. Para trabajar en remoto con gente que no se maneja bien en pizarras digitales (que es más habitual de lo que solemos suponer) probablemente es la opción más segura, y mover una rama entera es cortar, pegar y tabular. Lo que pierde es la vista de conjunto: con veinte líneas ya no se ve qué rama se ha quedado corta.

Referencias:

Marin-Garcia, J. A. (2026, 29 de septiembre). Del primer borrador a la causa raíz: qué suele fallar en un diagrama de 5 porqués [Entrada de blog]. Blog de Juan A. Marin-Garcia. https://jamg.blogs.upv.es/4582/

Marin-Garcia, J. A., Garcia-Sabater, J. J., Garcia-Sabater, J. P., & Maheut, J. (2020). Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), 49–68. https://doi.org/10.4995/wpom.v11i2.14776

Visitas: 10