#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: 0