The Top 10 SPC Mistakes (Quality Insider)

by Douglas C. Fair

The last 20 years of my professional career have consisted of helping manufacturing organizations understand and deploy statistical methods. I've worked with operators on the shop floor, consulted with Six Sigma specialists, cajoled managers and convinced engineers. I have worked with and witnessed hundreds of statistical process control implementations. Some have been extravagantly successful, virtually transforming plants and corporate cultures. A small number of implementations have been woeful failures, effectively souring entire organizations on the use of statistical methods altogether. Then, there are the SPC deployments that occupy the middle ground between rousing success and flame-out failure. These deployments are usually characterized by an interesting mix of localized support, excitement and success, coupled with an undercurrent of corporate indifference.

In spite of that, statistical methods and the foundations of SPC have changed little since their inception in the early 1900s. Why the amazingly different results using what most quality professionals find to be helpful tools and techniques? Why so, especially considering the body of knowledge and expertise that surrounds SPC today? Although many experts have written about what to do for a successful SPC implementation, few know what not to do. That is, not until the damage is done and SPC failure ripples throughout an entire organization are the mistakes made obvious.

To help ensure that your SPC money is spent wisely and that your system has the highest probability of success, take the right steps that all books discuss, but don't do the following. In a typical David Letterman "Top 10" order, following are the bottom five of the Top 10 mistakes to avoid when using SPC:

10. Train everyone
It's no secret that SPC is a tremendous cost-saving and process-improvement tool. Therefore, the perception is that the more people who know about SPC, the better. Not so. Years ago, I was a consultant and trained many professionals in statistical methods and their use. My customers were good people representing good companies. They had good intentions and they wanted the best for their organizations. Their ideals were no different when it came to SPC knowledge.

However, in their good intentions, they typically required administrative staff, sales people and other support personnel to attend SPC classes. Most of them had rarely, if ever, placed a foot onto the manufacturing shop floor. The result was quizzical looks, excessive doodling and newspapers being read. Invariably, hands were raised and those quizzical looks turned into questions such as, "Why, exactly, am I here?" This isn't exactly the kind of question that an SPC trainer wants to entertain, but it's a great question nonetheless. Quite frankly, most of those administrative and support personnel shouldn't have been in the class in the first place. My response has always been that companies should train the people who are going to be actively involved in the use of SPC—not everyone. So don't train all of your people in SPC. Don't waste your money. Make SPC training available for the people who will be directly involved in improving your processes. And the other ones? Let them read the newspaper over morning coffee, on their own time—not during an expensive training session.

9. Chart everything
Like others, you may have spent thousands of dollars on SPC training. Now that your people have attended classes and passed the tests, what do you do next? With a full dose of enthusiasm, some answer this question by charting everything. From the number of minutes on time cards to the number of days late for purchase requisitions, everything gets placed on a control chart. Unfortunately, people who are new to SPC are sometimes left to their own devices for how their statistical knowledge should be applied.

So what's the answer? Well, when everything is important, then nothing is. My recommendation: Only use SPC where it's needed. Start on the manufacturing shop floor, and don't bother applying statistical methods if there's even a hint of questionable benefit. This is especially important in the beginning stages. If the initial SPC implementation is identified for its convenience, or because it's an area of high production, and therefore better suited to using an X-bar and range-control chart, then forget it. It will be viewed by operations folks, rightly or wrongly, as just another management botch job. In this scenario, there's minimal likelihood of making a splash and proving that SPC is a great tool. Don't forget that you need the support and backing of operators, process engineers and support personnel to help SPC use be accepted and grow. The first area you choose for SPC use shouldn't be problem-free. It probably won't be the most convenient or the easiest place for using control charts.

Instead, search out areas where scrap, rework and other issues need to be resolved. Tap the shoulder of your local Six Sigma expert and find out where process control issues are most prevalent. Talk with quality engineers and support personnel to determine where problems exist and, therefore, can be solved. Believe me, if your first use of SPC isn't successful and SPC doesn't make a splash, you could be in for a very long career. Or maybe a very short one, depending on management's patience. In short, don't apply a wonderful technology such as SPC unless there's a need for it.

8. Segregate control charts from manufacturing
One particularly interesting (though ineffective) implementation involved a local SPC coordinator who used paper charts for the SPC system. Because of his interest in having a centralized area for data viewing, the coordinator found a rarely used conference room with big walls and lots of square footage. During my visit, the coordinator unlocked the door and proudly introduced me to the "SPC room." I was amazed as I walked into a large corporate meeting area whose walls were covered, top to bottom, with control charts. "This is where we keep our SPC data," he proudly announced. Innumerable control charts, neatly arranged, littered the walls. With eyes wide, I blurted, "So, how are these charts used?" His answer: "Well, when the engineers want to look at some data, they come in here." I bit my tongue instead of stating the obvious: besides us and the crickets, no one else was in the room. That and the fact that the room was locked and the lights were off before we entered. Who had the key? He did.

Operators and their machines were located quite a distance from the SPC room. The physical segregation of control charts away from operators and their machines clearly indicated that SPC wasn't being used as a process control tool, not by machine operators at least. In fact, I venture to guess that their SPC "system" wasn't used by anyone except the coordinator. If I were a cynic, I might say the SPC room only proved the coordinator could connect dots on a piece of paper. But I'm not a cynic. The bottom line is that their SPC room wasn't used by anyone. The perception by others in the plant, as they rolled their eyes, was that SPC was a waste of time. Given the scenario, it's hard for me to disagree.

So, how should SPC have been used? The foremost point of this Top 10 item is that SPC tools should be used by machine operators and therefore should be easily accessible by them. This precludes control chart placement anywhere but within close proximity to operators and the machines they run. A computer on their work bench or paper charts attached to their machine would suffice.

If considered carefully, the useful life of a control chart is measured in minutes. Therefore, control charts that are physically removed from the shop floor are virtually useless to operators. I can't state this strongly enough: Shop floor operators are the essential ingredient in any successful SPC deployment. Without operators' direct involvement with easily accessible SPC tools, your SPC dollars will likely go to waste.

7. "Pinching" the SPC coordinator
Some call them "SPC leads" or "SPC coordinators." Either way, these positions are sometimes "pinched" between their job description and the competing agendum of other organizations. Take Bob, for example. Bob was hired as an SPC shop floor leader. His job was to work on the shop floor specifically to implement SPC and oversee its success. In the beginning, Bob found his SPC coordinator position challenging and interesting. But it wasn't long before he started uncovering some bad news. It seemed as though the company didn't want process control and other quality-related issues on the shop floor. Bob had actually uncovered quality issues that had been ignored or swept under the proverbial rug for years.

Bob began to get SPC implemented, but not without resistance from production managers. They didn't want operators to take up valuable work time putting dots on a chart. Production managers often made derisive comments such as, "SPC stands for 'slows production considerably.'" It didn't take long for Bob to realize that he was going up against a culture that valued production over product quality. Then, when Bob showed interest in purchasing SPC software to make shop floor SPC use easier, the IT/IS staff suddenly had other, more urgent priorities.

Likewise, engineering and maintenance managers gave him the cold shoulder. They didn't want Bob's bad news of equipment problems, maintenance issues and band-aids to reach upper management's ears. Bob's important work was antithetical to the "get it out the door" production philosophy. Bob was caught between his job responsibilities and the interests of other corporate disciplines. Eventually, Bob's challenging job devolved into bitter frustration. Unable to reconcile the fact that his intentions were good and that no one really wanted him around, Bob quit.

Bob's unfortunate circumstance was partly the result of a lack of mid-level functional coordination coupled with a lack of solid leadership at the top. The not-so-uncommon belief that Bob's SPC implementation was in direct conflict with the plant's production-focused marching orders doomed this important SPC work.

6. Use SPC because it's a "good thing to do."
Don't get me wrong, SPC really is a good thing to do. Heck, I've built my career around the use of statistical methods in manufacturing facilities around the globe. And I get all warm inside when a client calls and excitedly says, "I can't believe what we've learned and how much we've improved! I can't believe how much money we've saved!" Those discussions are always gratifying and they make all of us feel good. However, if the reason for implementing SPC is because it's inherently good, then the motive lacks substance. The "because it's good" justification will sink any SPC ship. Why? Because it isn't a compelling business reason for using statistical methods. A successful use of SPC must begin with a clear strategic intent—a purpose for SPC use. The most successful SPC systems I have encountered are those that began with a strong leader who said something like, "I've had it with our quality problems. We're going to turn this plant around." In other words, a business rationale for driving quality throughout a company is what results in successful SPC implementations.

The perfect example is Chris Morrell. Chris is a plant manager with a large folding-carton manufacturer with plants throughout the world. He was tasked with taking the corporation's worst plant with the lowest quality levels and turning it around. Why? Because their biggest customers told them they had a choice: Improve product quality or lose your contracts. Millions of dollars were at stake. Several of their customers had officially put them under their microscope, threatening to remove all of their business. If that happened, the plant would be shut down, jobs would be lost and reputations ruined.

Chris came in and immediately installed an SPC system throughout the plant. Within a few months, defect levels dropped to just a handful in a million, costs dramatically improved and productivity rebounded. The results were nothing short of stunning. In less than a year, Chris' plant became the leader, surpassing the quality levels of all other plants in the corporation. The customers threatening to pull work subsequently gave the plant their highest vendor quality ratings—a rarity in their industry—and awarded them new contracts. Just a couple of months into the SPC implementation stage, one of those customers sent a letter stating, "We're not sure what you're doing, but please keep doing it."

The "it" was the transformative use of SPC. When asked what his secret was, Morrell humbly replied, "We just used SPC in the way it was meant to be used. SPC was the primary reason for the incredible turnaround of this plant." They went from worst to first in less than a year, because of a compelling, motivating rationale for using SPC in the first place. Since then, Morrell has transformed the quality levels in two more plants in their corporation by using SPC with vigor, motivation and a business reason for doing so.

So, what's the point?—that there are many, many ways to encourage the failure of an SPC implementation. From pinching SPC coordinators to the frivolous use of training dollars, there are lots of mistakes to avoid. This column touched on just the bottom five of my admittedly biased list. The second half, the top five mistakes to avoid for bungling your SPC system can be found in the next installment.

About the author
Douglas C. Fair is vice president of statistical applications at InfinityQS International.Fair is the co-author of two books on statistical methods: Innovative Control Charting, Practical SPC Solutions for Today's Manufacturing Environment (ASQ Quality Press, 1998) and Principles and Methods for Quality Management in Health Care (Aspen Publishing, 2000). Fair is a member of the American Society for Quality. Siemens Diesel Systems Technology (SDST, Richland County, SC), a joint venture between Siemens Automotive Corp. and NLP Inc., a subsidiary of International Truck and Engine Corp., needed a statistical process control (SPC) software solution to manage the quality of its diesel fuel injectors. The fuel injectors are used in the Power Stroke diesel engine built by International for Ford Motor Co.'s Super Duty trucks, Econoline vans and Excursion sport utility vehicles.