Another great article, Don. Knowing whether a process is stable or not should be at the top of everyone's criteria list for improvement project selection. Those that are not stable can't be fixed until they are (and may not need to be worked on once they are). For those that are in the threshold state, projects aimed at fundamentally changing the process to get on target (and then reduce variation) are appropriate. The problem that I consistently see is that there are too few people practicing any semblance of SPC to know what state they are in, so they throw projects at every squeaky wheel that comes along.
The other day I had a well-meaning young engineer at a medical device company ask me what he could do to find the right distribution so he could estimate Ppk for a product qualification run. I asked whether the run had been stable; had there been evidence of a state of statistical control?
"No," he replied, "we just made a batch of 30 prototypes. There were a lot of outliers. I ran a curve-fitting program and found that the data were a good fit for one Johnson Transformation and a 3-parameter Weibull, but another run wouldn't fit any curve at all. Our process is to find the distribution that fits, and then run a non-normal capability study using that distribution."
I told him that there were so many things wrong with that statement that I wasn't sure where to start, then pointed out (again) that, without a state of statistical control, he has no distribution, and no business estimating capability. I told him several other things, and he pushed back, saying that he has no choice; this is the process he's given, and he has to live with it. I suggested that if that is the case, he might try running prototypes one at a time until the pile passes his curve-fitting software's threshold for a fit, or gets a pile he can transform. Then get a job with another manager, if possible.