Problem Solving Pitfalls
Just for the reader’s information, I’m going to start a run here for a couple weeks about problem solving. Some of these points I have touched on in other avenues, but these seem to fit as their own mini-series. This isn’t a “How To”, but more of ‘Some of The Stuff They Don’t Tell You’. Pretty much any structured problem solving method will lean heavily on data. The good news is that most companies have a pile of numbers that can be used to identify problems. The bad news is that these numbers often seem to lack some key characteristics that would make them very useful. There are some serious pitfalls to be aware of as you are digging through the data.
One of the usual suspects to look for in terms of using data is the context that it comes from. Does the data have a time or sequential relevance? How can you tell what has changed in the process or the product that may have driven the data? Put another way, what are the known special causes that can be filtered out so that the unknown special and common cause variation remains. The data itself can almost never be taken at face value as a reflection of a stable reality.
A second area to dig in to is how much the data reflects what you are trying to measure about the process. How direct and traceable are the measures to the actual process? Do the numbers have to get combined and factored into something or are they transparent? Is the data a reflection of a leading or lagging indicator? Are they timely or delayed? How much do the financial reports reflect actual dollars vs. some sort of calculated dollar figure? All of these are important to understand to determine where you should be spending your time and how you need to leverage resources.
Once you can harness the data, gather the context it comes from and understand exactly what it tells you, there is another key step…verifying your measurement system. Whether this step occurs in the form of a Gage R&R, a human verification, or whatever your MSA may need to be, it has to be done. You have to know that the data you are getting is a reflection of what is attempting to be measured.
More times than I’d like to recall I’ve been a part of activities where one or more of these steps were skipped. While you hate to say that any activity where you learn something is a waste of time, there has been a lot of time wasted in chasing problems that weren’t really there or trying to improve performance on a less important process. That ‘waste’ could very easily have been avoided by investing the upfront time to study what was really there. Maybe my errors can help save you the effort of going down the wrong path in the future.