Refining the Art of Asking Why

Many companies which have successful Lean Manufacturing programs, use a 5 Why approach to technical problem solving. At Shainin, we are also interested in asking why, since understanding the true cause of a problem allows for the most simple and effective solutions to be put into place. Some of our clients have described our approach as “refining the art of asking why”.

A problem we recently worked on which involved a broken latch on an electrical connector illustrates this point. The problem manifested itself as an inoperative electrical component. Asking WHY (1) revealed that the electrical connectors were no longer fully engaged. Asking WHY (2) again revealed that the latch that locks the connectors together was broken. Asking WHY (3) the latch broke was answered with “it was not strong enough”.

So what corrective actions were available? Most engineers with any experience could develop a list of potential improvements to make the locking latch on the connector stronger; change the material to one which is stronger, increase the wall thickness, increase the fillet radius, etc. This is a very typical approach.

But how do we know if we have identified the “best solution”, that is, the cheapest and easiest to implement, with the lowest risk of creating a new problem. The changes mentioned to strengthen the latch are all design changes. Changes to a design which has already been validated involves risk. Is a design change really necessary? Most connectors produced are not failing. Is it possible that a minor process change or perhaps tighter control over a particular parameter will also fix the problem?

There are many unknowns surrounding this problem, thus there is a risk that we have walked past a simpler solution than the ones proposed. While the first 2 answers to WHY are clear, the third one of why the latch broke leaves much to be desired. In fact, the problem is not so much with the answer (the latch was not strong enough) but with the question. When conducting a 5 Why investigation, how we phrase the question will very much determine the type of answer we get and ultimately what course of action we take. We could have asked some of the following questions:
•   Why did the latch break in the exact location that it did?
•   Why did only 1 out every thousand break?
•   Did connectors made in certain mold cavities have a higher failure rate than others?
•   Did connectors tested in certain fixtures have a higher failure rate than others?

The team developed a drop test in order to measure the energy required to replicate the failure mode. After testing connectors from different mold cavities and different test fixtures, they learned that there was a significant difference in the failure rate between parts coming from particular test fixtures. The team used a Component Search strategy and quickly converged on the key dimensional difference between the best and worst test fixtures. Small cracks were being generated in the latch during the electrical check as the connectors were seated into the fixture, and then propagating in the field under vibratory load. The corrective action was a minor change to a critical feature of the test fixture which was interfering with the latch, putting unnecessary stress on it as it was engaged during final testing. No engineering change was necessary.

The key part of this project was asking the right questions. The answers to these new questions revealed previously unknown differences and opportunities. Using Shainin methods, these questions were developed methodically, so that for any technical problem, the appropriate way to ask “Why” will help to uncover the true causes with simple solutions.

5 Why is an effective approach for solving problems where the cause can be discovered through simple observation. Examples include: the wrong parts are being used, a fixture is worn, work instructions are not being followed. For more complex problems where the true cause is hidden, you will need to supplement your 5 Why process. If the result of your investigation does not provide an answer which explains the variation in performance (why is only some of my product failing?), then your solution will not be as targeted as it could be, but instead will involve a design or process change that may be unnecessary.