How to conduct a Five Whys root cause analysis | Hacker News Reader

How to conduct a Five Whys root cause analysis

startuplessonslearned.blogspot.com

45 pointskungfudoi12 comments

I wonder how to conduct such why meetings without demoralizing people? I can imagine people being more worried about being mentioned in those meetings than they worry about customer satisfaction. Of course one could always hide the problem beneath 'you have to build the right corporate culture'.

Also, what size does a problem need to have to result in such a meeting? Every argument with your colleagues? Every customer related problem? Every technical problem?

"In fact, at IMVU, we did exactly that. We started with a simple wiki page with a few bullet points of things that new engineers had tripped over recently."

This happens in our corporation as well, although in a much more informal way. It goes more like this: There's an annoyance, let's solve it. As the article says, the investments are gradual and there's not much time required to fix the little problems. One at a time.

"Also, what size does a problem need to have to result in such a meeting? Every argument with your colleagues? Every customer related problem? Every technical problem?"

Disclaimer: I work at IMVU, but I am not the article's author This is a problem you have to solve for your own context. I suggest starting with only the biggest problems, and seeing how the process works for you. You'll see the people who are in those meetings getting accolades for their follow-up work, and you'll find that as the root cause analysis gets up to why #3, the participants are solving problems they didn't cause. Both of these will help to build the right corporate culture, as you mention. Then, if it seems appropriate, it will be easier to apply 5Ys to less serious problems, because their value will be well-known to the team.

Being mentioned in a 5Y here never bothered anyone. Because you know you have to come up with a fix for all five levels, everyone too preoccupied thinking up solutions to begrudge anyone.

It is worrisome the first time you're implicated in a highly visible or expensive problem.

We address this partially in on-boarding where we are very clear that our version of this process exists, that we take it very seriously, that we post-mortem every significant issue, but that throughout the process, we are only interested in solving, minimizing, or preventing future problems, not in hand-wringing or otherwise crying over milk already spilt.

Then after that introduction, the chances are great that before it's your turn to be the cause of a big issue, that you've seen the process work several times, seen that experienced, well-regarded senior staffers also make mistakes and they just face up to the process with transparency and without fear and that nothing bad comes of it for them, and that the company gets better by developing a sort of immune response to chronic or substantial issues.

Is that another way of saying "you have to build the right corporate culture"? Perhaps, but it at least gives some of the recipe we followed in this specific case.

This is a really long article, but it makes a really strong point. The more you ask 'Why', the more you get to the root cause of a problem and not only stop that problem from re-occuring, but prevent a lot of other negative outcomes as well.

It also demonstrates that whiteboard meetings need not be a waste of time, particularly if you have an analysis framework to focus your time and effort.

I'm an engineer at IMVU, the company mentioned, since the inception of the 5Y strategy.

I've lost count of the number of cool technologies and tweaks we've built as a result of 5Ys. For example, occasionally one of our engineers will decide to build his own website, and use simpletest to unit test his PHP because that's what we have at work.

That engineer invariably complains about how bad out-of-the-box simpletest is compared to the house model we've cooked up. I've heard "It doesn't even have X!" many, many times. More than half the assertions in our php testing framework are custom-made, all the web gets and posts assert on the response code automagically, etc. And that's not even counting how much support we've ended up building into it for our other technologies - automatic detection for failures in memcache, SQL, and what-have-you. Or the other testing frameworks we've rigged to run within it, like YUI test and selenium. All because of 5Ys, and that's a minority of the good 5Ys have done for us.

They think a tool named SIMPLEtest should have all the bells-and-whistles of EVERYTHINGbutTHEkitchenSINKtest?

actually, most of these changes make the framework a lot simpler.

It's pretty sad that people have to have something so simple spelled out for them and given a catchy motto like "The Five Whys".

Even sadder that it would be hailed as some revolutionary problem-solving technique.

Yes and no. There's some utility to having a dogma with a well-defined name. If you wanted to introduce each of these practices separately, you would have to explain each one and get people to buy into each one. Each one is a potential point for argument and derailment. It's convenient to have a handle that refers to the whole kit.

In practice, you'll have to introduce the techniques incrementally, but having an over-arching name can help people see these as part of a unified plan.

I can attest to how easy it is for even a small company to completely disregard any sort of mechanism for learning from mistakes over time. It goes against the grain of human nature to bring up problems in a useful way in a lot of cases I think.

It's a little like Ahmdahl's Law. Sure, it's really basic and kind of obvious, but it's still worth thinking about from time to time, and it's nice to be able to call it out by giving it its own name.

If you are starting your sentence with "But that's just...", you fall prey to the assumption that hindsight is 20/20.

The first thing I learned in my Ph.D. program is that the most important discoveries are the ones that seem the most obvious in retrospect.

Reply on news.ycombinator.com