"The formulation of the problem is often more essential than its solution, which may be merely a matter of mathematical or experimental skill."
― Albert Einstein
Sometimes I'm a little late to the game. As much as I love movies, I often don't see the most popular releases until years after they've hit the theaters. Case in point, I have yet to see Avatar, The Exorcist, or any of those Star Wars prequels -- all of which are in the top ten list of highest grossing films of all time. The same is true for books and yet I am a voracious reader. So, it's not too surprising to me that I am only now learning about an idea that was developed well over 60 years ago.
Taiichi Ohno was a pioneer in automation and automobile production during his decades' long career at Toyota. Considered the father of the Toyota Production System, he was instrumental in turning a tiny, regional company that specialized in inexpensive cars, into a global powerhouse. In the 1950s, he devised a system for problem solving that he called "The Five Whys." Instead of jumping on the first potential solution, he urged his colleagues to dig for the root cause of a problem.
One of Mr. Ohno's most famous examples involved a welding robot that had stopped in the middle of its operation. He approached solving the problem as follows:
If a technician stopped looking for potential solutions after the first or second deduction, the robot might start working again, but would soon shut down as the bearings locked up and the new fuse blew. This would most likely lead to other delays, and production rates would quickly fall.
Of course, a single problem may have multiple root causes. However, that does not negate the "Five Whys" practice. Rather, it simply means that there may be times when it needs to be applied multiple times with different sets of questions.
It's also possible that in some circumstances the "Five Whys" is overkill, and the problem could be solved in fewer iterations. The rule of thumb is that the root cause is reached when one of the whys returns a broken process or alterable behavior.
Lastly, answers such as "not enough manpower" and "insufficient time" are never considered valid conclusions. The "Five Whys" methodology states that "Processes fail, people do not."
As I think about the "Five Whys" and my life in communications, I realize that its uses are numerous, and the methodology can be applied to nearly every aspect of one's business -- this includes both technical and experiential problems.
For instance, searching for root failure causes is just as important for poor customer satisfaction scores as it is for distorted voice calls. Although the first may lead to a change in the questions a customer is asked inside an IVR (Integration Voice Response) system and the second to replacing a crimped LAN cable, each problem can, and should, be tackled in a very similar manner.
As with anything in our industry, the complexity of the whys can become extremely technical very quickly as the questions and nature of the answers progress. For instance, you might start with the problem statement, "Customers are complaining about bad calls," and end up with an answer of "there are incorrectly formatted RTCP packets." This necessitates different degrees of knowledge and perhaps different people at the various levels of problem solving. The first or second why might be derived and answered by the customer care team, the third and fourth by the IT department, and the fifth by a software developer.
The "Five Whys" does not dictate who asks and answers, only that the questions be asked and answered.
I decided to apply this to a real-life problem that I recently experienced. Although I did not apply the "Five Whys" at the time (I told you I just learned about them), I did so after the fact and was very pleased with the outcome.
Although this may have sounded contrived, the problem was real and the actual root cause was found on the fifth why.
My life can be extremely chaotic, and problems often come at me hand over fist. I can clearly see how asking why, why, why, why, and why can be both a time saver and lead to longer lasting solutions. The longer a problem stays solved, the more work I can get done (and the more time I have for articles such as this one). So, although you might not necessarily think that's a win/win for you, it certainly is for me and I could use a few of those every so often.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.