I sat across the table from Mike Colyer in a small lunch café on the Isle of White in the U.K. near a composite aircraft manufacturing site in the early 2000s. At close to retirement age, Mike wears an unassuming blue sweater, collared shirt, slacks, and highly unfashionable safety shoes. There is an almost deliberate action to take up less space in the world, to be unintrusive. To everybody around us, he is the most British and polite of people. 

Beneath the humble exterior, however, the intellectual brilliance shines through—the eyes sparkle, the voice is packed with energy, every comment and observation carriers a lifetime of experience. The former managing director of our vast European automotive business and someone mentored in the Toyota Production System (TPS), he has been seconded to the Aerospace division to accelerate TPS implementation and is present to assess our Lean program. 

The conversation is also brutally painful. Mike observes, “The problem with you bright, fast-track graduates is that you know nothing useful.” He continues to rattle-off the reasons as to why I cannot be successful in driving my continuous improvement agenda. While my sandwich lost its flavor long ago, I’m remaining for the meeting and listening intently. Finally, I pose one of the more significant questions of my early career: “What if we develop a pilot here?” This gains traction and over next six months, as we set about defining a toolbox with which to implement TPS, I would gain a very different view of quality problem solving compared to what I had previously learned.

After a few weeks, I was in an office explaining my thoughts on a planned deployment of a problem-solving toolbox, including the usual fare of brainstorming a fishbone diagram, building process maps, and Five Whys taught to me earlier by a lean deployment consultant. Mike rolled his eyes and stated, “Brainstorming might be good for marketing or creating cartoons, but it is not for root cause analysis.” Such—often provocative—maxims were not rare from Mike. He continued “Go to Gemba and for system failures, use Five Whys, but don’t use it for process variation. There you should think simply and remember—there are only three types of variation.”

Mike’s statement on variation was rooted in the work of Keki R. Bhote, author of the exhaustive, “World Class Quality: Using Design of Experiments to Make It Happen.” Bhote talks about the hunt for the Red X—the source of the variation. While Bhote’s book is a deep dive through the practical application of design of experiments, early focus is given to eliminating and honing in on variables to simplify investigation.

Bhote articulates three types of variation in a process: batch-to-batch, within a batch, and time-to-time. It is stunningly simple. In a sea of DMIAC (define, measure, analyze, improve, and control), Ishikawa diagrams, full factorial arrays, brainstorming, and hopelessly off-track Five Whys, Mike would show me how applying these three conditions in an investigation can rapidly narrow scope and pull process engineers to uncover the sources of variation. 

One example of its application stands-out in my mind. Several years later while running a plant, the power of “going to Gemba” and this simple approach to finding the source of variation helped solve a head-scratcher of a problem. We had produced several batches of non-conforming plastic product. The product was simple, the inspection method had a solid gage R&R with clear instructions, and the operators were experienced. There was no apparent source of the non-conformance. This was impacting deliveries and was costly.

It was time to go to Gemba, gather data, and test the three sources of variation to narrow our scope. We knew the variation was batch to batch; only one of three operators was producing the non-conformance. The variation was also time-to-time; the same operator was producing good and bad batches, but only on certain days. There wasn’t variation within the batch; if they were non-conforming, it was the entire batch.

With this insight, the team eliminated or deprioritized a large number of causal factors. The fact two shifts produced good parts indicated it was unlikely the variation was originating within the CNC machine or the gage was bad. In addition, the failure mode also eliminated the material as the cause. Further, operator competency as a source of the issue could also be isolated and excluded through discussion and observation of the task being performed. 

The team pivoted to the time-to-time nature of the variation to understand what was different at the times the bad batches were produced. Eventually, the operator identified that on the days the bad batches were produced, he ran fewer machines because first shift had not finished their setups. This is where we discovered the one variable that was being performed differently. Since fewer machines were being run, the operator was not cleaning parts for inspection and then leaving them to dry in the air condition shop while attending to other machines. This insight provided the engineers with a specific area of investigation, resulting in them finding the Red X. 

When the operator was less busy (i.e., running fewer machines) and cleaned his own parts, the time between cleaning and verification was shorter. As a result, the parts were still warm from the cleaning solution. This allowed the plastic feature to accept the gage, and the operator adjusted the machine accordingly. Once the parts cooled and were moved to final inspection, the material had stiffened and would no longer accept the gage. We knew we had our source of variation; the engineers could switch the failure on and off and test just by warming up parts. 

It’s unlikely anyone would have guessed the problem was the part being warmer than normal as a result of the shorter amount of time between cleaning and checking. Data analysis would be unlikely to spot such events, but the rigor to structure questions, eliminate variables, and determine what could and could not be the source of the variation based on the three simple rules led to a swift and complete investigation. Further, with a true understanding of the variation source, the team was able to open a root cause analysis (RCA) into the system gap that allowed for the condition not to be considered. 

Many QMS solutions roll out a well-intentioned suite of tools for problem solving, sometimes mandating an approach to analysis. However, these anchor tools are not always fit for the purpose of isolating variation and, as engineers, we need to recognize that. This was highlighted to me a year ago when I was discussing a deep technical challenge on a manufactured product. 

The engineer was in clear design of experiments territory, where this application of the logic “batch-to-batch, within a batch, and time-to-time” was going to quickly narrow the scope of the investigation. I asked what approach was being employed and the engineer showed me a Five Why. I countered with the question, “Why are we looking at a Five Why here? The response was, “Our QMS says to complete the Five Why for RCA.” However, technical problem solving and system failure problem solving are not the same thing. Root cause is a phrase that is used but does not always provide the correct focus. To find the source of variation, hunt the “Red X.” Then perform the Five Whys to understand why the system allows the failure; however, first solve the technical problem.

Mike was a tough mentor. There were days when he drove me to distraction with his unrelenting approach, but he gifted me a toolbox I use to this day. (I still keep a copy of Bhote’s book on my desk.) Sometimes, smarter engineering doesn’t require a bigger, more complex toolbox. That fact is especially relevant as we look to artificial intelligence to help us solve problems. Sometimes, the solution can be generated from applying systematic rigor and logic. Or, as Mike would say in his maxims, “If you can’t think simply, simply think!”

MORE FROM THIS AUTHOR: How CDMO+ Drives Orthopedic Product Quality and Speed to Market

Rich Warren is the chief commercial officer (CCO) at Resolve Surgical Technologies, an orthopedic CDMO+. In this role, he is responsible for the commercial strategy, new product engineering, and regulatory. Before joining Resolve Surgical Technologies, Warren served as the CCO for Medical Manufacturing Technologies Inc. (MMT). There, he led strategic sales and marketing activities and oversaw the TotalCare forward stocking program, which set the benchmark for aftermarket service and support. Previously, Warren spent 15 years at the LISI Group of companies in commercial and general management roles, where he delivered strong, meaningful growth in its medical and aerospace business units. In addition to his time at LISI, Warren also held various roles at GKN and has a master’s degree in mechanical engineering.