Quality Whack-a-mole

Organizations spend too much time and too many resources playing the “quality-whack-a-mole” game. If you don’t know what I mean, think of the arcade game (or Chucky-Cheese if you are unlucky enough to have to take your kids there) where you are given a very large hammer and told to hit the mole. As soon as you hit one, an identical one pops up in another hole. Your attention gets fragmented trying to kill the one in front of you while anticipating where the next one is coming up. In the quality-whack-a-mole game, companies fix what they think is the root cause of the problem, to have a slightly different problem pop-up soon after.

Over the last 20 years, I have had the opportunity to help companies with a wide variety of quality, product development, and production problems. Recently, I reviewed my portfolio of projects and was floored by the similarities across all of my clients: companies that produce 100 per year or 10 million, make spray cans or targeting devices for missiles, or are highly regulated by the FDA or are commodity producers. I have solved the same essential problems over and over. Each client has its own unique characteristics requiring a slightly different solution, but the fundamentals of what drove the failures are very similar. To put in academic words, the first principles are all the same. In addition, the problems are never due to a single failure in the product development process, quality plan, manufacturing system, or supply chain. Rather a multitude of events, cultures, processes, and pressures combine to open a gap that allows the failure to escape to the customer.

The clients I work with are highly intelligent with excellent technical skills. They design and produce fantastic products using highly sophisticated manufacturing techniques. They know and use the tools in the acronym soup of Six Sigma, FMEA, 5 Whys, SPC, statistical analysis, and many more. They rise to the challenge when a quality failure occurs and apply the tools and methods correctly. Yet, once one “mole” is back in its hole, another one never fails to pop up.

In looking back, I find all of my clients make one or more of the following assumptions that prevent them from really preventing the problems.

• We solved the technical root cause so we are done. As engineers, it is very tempting to end when we find the technical cause of the problem. Design, process, and additional quality controls are imposed to prevent that specific problem from occurring again. However, the teams do not ask the hard question of why that failure managed to get through. They don’t fix the underlying issues which continue to create opportunities for new technical problems.
• The quality data is too noisy to tell us anything. Companies often have huge databases of quality measures, test results, warranty data, and customer feedback. The data is often noisy and difficult to interpret. While the data is able to provide gross trends and high-level metrics, teams often throw up their hands when they tried to dive into the details. There is a lot of value in the data; you just need to understand how to use it effectively.
• We need to find a single smoking gun quickly. In the face of a quality emergency, teams are under incredible pressure to find a solution. After a short brainstorming session, organizations like to find a single smoking gun. However, it is often a combination of effects that creates a problem. Getting rid of one of the root causes will improve quality enough to reduce complaints to an acceptable level. However, the other unaddressed root causes still lurk under the surface and will pop their heads back up when something else goes wrong.
• Each problem is different. Rarely do companies look back and try to find similarities between major quality failures. On the surface, the technical causes might be very different but the underlying conditions of each failure may have a lot of commonalities.

What I do is not rocket science. I don’t have a secret toolset or software package. Through a combination of interviews, technical analysis, observations of the factory, data analysis, a handful of basic tools, and my own internal database of cases from many other industries, I am able to find the multiple real root causes and help companies not only mitigate the current failure but develop the infrastructure to prevent the same mistakes from happening again.

First, I walk the product development and manufacturing lines to figure out where the multiple core root causes are likely to be lurking. I review with the design team the timeline and activities from the initial design process through the crisis. In addition, I literally walk the factory floor from incoming materials through shipment to customer support and product repair. I try to understand what is inherent in the organization, its technology, and processes that are allowing the same failures to escape repeatedly. Here is a sampling of questions I ask along the way.

• How well were the specifications defined? If there is inconsistency or lack of clarity in the design specification document, it can explain the confusion about quality requirements downstream. For example, if the usage conditions are not clearly defined in the specification then the testing is unlikely to find potential problems.
• How defined are product development, supplier management, and quality policies, and are they followed? The clarity and completeness of processes documentation and, more importantly, how quickly can anyone put their hand on it is an early indicator of how disciplined an organization is about its processes.
• Are there cultural blind spots? What does the organization value or brag about? The stories and myths about strengths can often create excuses for lack of discipline.
• How much change is the company trying to achieve? Organizations are often too optimistic about the technical leaps they can take in a single design iteration. Organizations assume their suppliers can teach them about new technologies or manufacturing processes, and they do not need to build internal expertise.
• How much design change occurred during the pilot process? Struggling to get the product to work in the pilot process and making many design changes close to launch is highly correlated with problems in the field.
• How much reliance on inspection and testing to catch issues? Many companies keep adding testing and measurement to try to fix a problem. Often the tests or measurements are ineffective or there are just too many: the organization can’t focus on what is critical. The additional measurements take resources and drive scrap and rework without adding value.
• What does the factory look like? Basic cleanliness, organization, right levels inventory are all indicators that the processes within the factory are under control. I have a few basic tests which include the date test (what is the oldest material I can find in rework, outgoing, or WIP) for inventory and the date test on the quality posters (when was the material last updated and can anyone find it).
• What is in the trash can? Looking in the scrap pile can be very educational. The reasons for a lost product, the sheer volume of material, and the date codes can provide insight into the underlying manufacturing process stability as well as hidden causes of poor quality.
• How much does the company rely on Six Sigma to solve all quality problems? When organizations start the conversations with “we spent X Million on a Six Sigma program to solve our quality problems” I know I have a long road ahead. Companies believe that they can spend away quality problems using a small separate team; however, quality problems are created and solved by the entire organization. The discipline during all stages of product development and manufacturing is critical. It is shortsighted to assume that a few black belts can independently turn quality around.
• How clean is the warranty data and can it be used to predict rather than confirm quality problems? Warranty data is a great source of information about the current quality of products in the field but it is rarely well used.

The next time your organization is facing a recurring quality problem, try to ask some of the above questions to find out why the problems are allowed to happen and escape. Fixing one or more of these can significantly reduce the chance of another problem cropping up.

This post was originally published in LinkedIn