Please provide feedback. This method has worked for me.

THANKS for posting, and WELCOME to the COVE! This is a great start!

One comment, if I may: At the beginning the article sounds as if it is going to be a general discussion of a problem solving technique, and then it goes to a specific case. In the second bullet the "seven causes" are mentioned, which caused me some confusion, especially since the "5 Whys" also appeared. I began wondering if there was a technique, "seven causes", that I had never heard of.

Its early yet, so maybe I am a little slow this morning...

Hi Chris, welcome to The Cove! :bigwave:

That's a very nice paper! And like Craig said, what a great way to start out here. :applause:

I also have feedback. I found this on the second page, Do not forget that the measurement system itself may be flawed. If in doubt, conduct an MSA at each step of the process where scrap is identified. ...but I don't know what MSA means. Maybe I just need coffee, but I would do better with a glossary of terms.

I'd also like to know why seven causes, and not five or three. I agree you might want to go into the theory a bit more, if only just a short paragraph for each, before starting into the case study. Then you could describe the difference between noise and controlled variation, and at what point the reader would know that controlled variation has been achieved. Who is your audience? Experienced QA people or line operators learning how to reduce defects in teams? The answer to that would help you select your language to shape the message, and decide how much depth to take each of the four subjects to. I hope this makes sense!

But do I think this is a good paper to help understand how the basic quality tools work together. We can always use such papers, QA seems like voodoo to so many people.

I also have feedback. I found this on the second page, ...but I don't know what MSA means. Maybe I just need coffee, but I would do better with a glossary of terms.


MSA = Measurement System Analysis. BTW, the fact that you know this now doesn't mean that you don't need coffee. :tg:

Please provide feedback. This method has worked for me.

Welcome to the Cove, Chris. :bigwave:

I'm not a big Six Sigma fan, and your paper embodies much of the cause of my disdain. Note that this is not personal--it's an observation on the methods and not on the messenger. We all appreciate contributions like this, especially from new visitors.

My experience is that claims of efficacy of SS projects almost always include unsupported assertions. You say in the paper,
Sixty to eighty percent reductions in scrap are possible using the PF/CE/CNX/SOP methodology. While you might have data to support the assertion, it begs a few questions: Why only 60 to 80%? How did you arrive at these figure? Why not 92%, or 16%?

The other assumption tacit in the statement is that some other, less complicated process might not work as well. Experience shows otherwise, at least in my case. While there might be occasional seemingly intractable scrap problems that will benefit from in-depth analysis, most don't require all of what you're proposing. Every SS implementation I've personally seen involves overcomplication of relatively simple problems because SS practioners feel bound to unnecessary analytical tools. The first rule of any sort of analysis is to always apply Occam's razor which, in its simplest form, says "don't mulitiply entities unnecessarily," or even simpler, "The simplest solution to a problem is also usually the best solution."

Instead of heading out to the production floor burdened with tools you probably won't need, but feel obligated to use anyway, you should take a pragmatic view of each problem and try to solve it in the simplest way possible. For example, if what is perceived to be excessive scrap is being produced in a given operation, it's usually a simple matter to:
Identify and classify defect types;
Identify potential causes of them and,
Identify and test potential solutions.Along the way, it might be discovered that there are measurement/evaluation issues and some things that are being scrapped don't need to be. You might also find a simple and obvious solution that somehow hadn't been identified before. In other words, if you start a big, complex process when a big complex process isn't necessary, you're creating waste in the name of reducing it. Note that one way to avoid a lot of problems in production is to have an efficacious FMEA process in place, and to validate process capability as early as possible.

In short, look for the simplest solutions that work, and don't get out the big guns until everything else has failed. Don't start complex improvement projects until you're sure that complexity is unavoidable, and never use any sort of analytical tools if the problem can be solved without them.

MSA = Measurement System Analysis. BTW, the fact that you know this now doesn't mean that you don't need coffee. :tg:Thanks Jim, it came to me after a little while, but I decided to use it as a chance to make a point of asking who is the audience. If it is engineers, they'll probably know hat an MSA is and how it would fit into that step. As I thought about it further I had to wonder: why make an offhand mention of that rather involved process in a paper about simple quality management tools? Hey, I'll be stubborn but the mantra is to explain acronyms or avoid them.

That would be the extent of my feedback's value. Yours was much more value-packed, in my view. :D

Thanks to all, so far, for the feedack. I appreciate the comments.
Jim, I agree with the keep it simple method. I have spent many years working on the shop floor. Seeing engineers flounder and flop around trying to solve oth simple and difficult problems. What I am stating, though, is that this method works - every time! It may seem complicated or over done but the method is as simple or complex as the problem. 60 to 80% is the average improvement seen with this method in my experience. Again, the method works every time - always. It points out that variation is the cause of most of our issues/problems.

Thanks to all, so far, for the feedack. I appreciate the comments.
Jim, I agree with the keep it simple method. I have spent many years working on the shop floor. Seeing engineers flounder and flop around trying to solve oth simple and difficult problems. What I am stating, though, is that this method works - every time! It may seem complicated or over done but the method is as simple or complex as the problem. 60 to 80% is the average improvement seen with this method in my experience. Again, the method works every time - always. It points out that variation is the cause of most of our issues/problems.

I'm glad it works for you, and again, I'm glad you shared it. As a compendium of possible resources it could be very helpful. I've also spent many years in the midst of the machines and frankly I can't recall a single instance where all (or even most) of the steps you detail were necessary. In a little while I have to go to the post office, which is about a mile away from my house. I can walk there and walk backwards all the way (which works every time--always) or I can choose a simpler method of locomotion which will achieve the same result. The fact that a given method or strategy works consistently is not compelling evidence of it being the best method.

Occasionally we'll get an SS neophyte here who, for example, believes that as part of his current project he must do MSA in a situation where MSA probably isn't going to be necessary or even helpful in achieving the goal. The problem with SS methodology in general is that it almost always over-complicates things. The SS tools take on a life of their own with the usual result being the tail wagging the dog. This is not to say that some ideas and concepts in SS aren't helpful (although most are derivative of concepts we already know); it's that there's a prevailing notion that in order to justify the colorful belt, the tools must be used, even if the would-be problem solver doesn't understand them. The result is creation of waste in the name of eliminating it.