Preventing recurrence in future designs

Once the root cause of a particularly troublesome problem has been identified, the problem-solving team will usually enter a euphoric stage, anticipating the end of the exercise. The problem-solving team may have corrective actions defined and validated. All necessary equipment may be on order, and all necessary process sheets are in the process of modification. All that remains is implementation of the corrective actions, and the team can get back to work.

This is where the eight-discipline (8D) process is at its weakest. The seventh discipline, called “prevent recurrence,” is often treated as a means of control to prevent future escapes of the original failure. So in this position in the report, one might see “implemented inspection.” When the real purpose of the discipline is understood, a team may address the discipline as “updated lessons learned database” or “revise best practices system.” Occasionally, one may see a team that actually went beyond the “5th Why” barrier to determine non-obvious root causes.

Engineering design, especially multileveled discipline electronic devices, (hardware, software and mechanical engineering) require extensive research to define a proactive recurrence elimination action plan. To understand how to prevent recurrence, a team should ask, “If the whole design process started over, what would an organization want to do differently?” For instance, if capacitors were cracking due to board stresses imparted during production, what steps should have occurred to eliminate the possibility that cracking would have ever occurred? Or if a transistor failed due to thermal overstress, where did the design process fail and what should have occurred to prevent this design failure?

Many times, the above problem examples would have solutions that are altogether too focused, correcting only the immediate issues at hand. Typically, engineers are subject to basic psychological boundaries. Because of this problem, solutions will most often take the most simplistic forms that are easiest for the responsible party to implement. Additionally, it will usually be framed by what the responsible party can control and cannot control. For example, a production test engineer cannot influence far beyond test engineering. Similarly, software engineering influences software very well, but has limited influence beyond that function. The majority of the time, a simple solution is easy and cost effective. However, many times a simple solution doesn't address the systematic issues that resulted in the original problem.

To completely prevent recurrence, additional steps should be taken. Ask some tough questions concerning the corrective actions and understand their limitations. For example, What is the action really fixing? Will the action only fix this particular issue? Will recurrence really be prevented in other future programs? Define what thought process went into designing the existing product and understanding what steps the organization must take to eliminate or modify it. Additionally, define what method the organization will use to educate as to what occurred and how it will be prevented from occurring again in future designs.

Once a permanent corrective action is in place, understand where its influence ends. Then, look to place additional actions to broaden influences to prevent recurrence. If a final test specification called out incomplete information resulting in improper tests and failure escapes, the prevent recurrence should be an institutional control that results in proper and complete testing. Test engineering would not solely be responsible for this. Finally, consider if the organization prevents good transfer of information and consider that a supplemental cause.

Good problem solving results in problem avoiding. Organizations that take additional steps to understand problem solutions and what they actually prevent will find that usually the problem seen is just a symptom of the real issue.