Treat the symptoms, not the cause?

Here is a situation encountered on a recent project. I have abstracted the key-points here.

The project started as a textbook DMAIC engagement with all the elements you would expect to find including impact on customer, strategic problem, clearly measurable benefits and well-defined goals.

The project was too tackle rework created at a certain process step producing a 5% defect rate. Although the defect rate was known, the number being fixed was not. Rapidly cracked-open the rework process and came up with a fix rate of 50%. So simple goals:

  • Reduce the defect rate from 5% to X%
  • Improve the rework from 50% to Y%

Attention moved onto the root-causes for the defects and as the analysis continued it became clear that the customer was unintentionally creating the defects and there were many many reasons why the customer could create the defect.

As an analogue it’s a bit like treating people with back pain. In a week any number of people can suffer and there could be any number of root-causes. It’s the treatment of the symptoms that becomes important with any number of root-causes to address.

Handpicked Content:   The Grapes of W.O.W.

So the project came a crunch point, what to do.

  • Could launch a DfSS project and rebuild the process from the ground-up with the goal of avoiding the defect situation in the first place. Not likely, way too big a project.
  • Could relentlessly quantify and address each and every root-cause. Decided against this, as I like getting rapid results. It would cost a lot of time & money and most factors are out of my control anyway. (Although am pushing forward a few highly targeted improvements here.)

I decided to focus on the rework process. It consists of three main steps and at each point the defect can be corrected. I am setting-up a DOE trial that will change these and other factors to find the optimum setting for fixing defects. Hence I am treating the symptoms not the cause. It feels wrong, but it happens!


Comments 4

  1. M Jacobson

    I have had a similar experience in which the fix would have stopped production and cost more than the budget could have handled.
    We used the DMAIC tool and identified the key X but the fix was too costly and we where uncertain if it could ever be resolved to the needs of the process.
    The team and I presented the findings to management and gave them two options. Adjust the process so it could accept the variation in the raw material or adjust the raw material to eliminate the problem. We had excellent engagement from the supplier but even with that the process of changing a material of an aircraft part takes time and a lot of money.
    Management made the decision to change the process. The new method took more time than the original process but scrap was virtually eliminated and rework was reduced by 50%. According to the data I had when my contract was completed.

    In the end we saved money compared to living with the scrap/re-work and understood the drivers for the problem.

  2. Mike Carnell

    I am not sure why this should feel wrong. There are always constraints around fixing problems that may take choices that seem so clear cut in a classroom environment but when you drop them in a business situation then can easily take a different route. That is a call you, your team, your Process Owner and your leadership team need to work through. That is why we don’t have Black Belt Rambo projects where it all rests on you/the BB.

    There are a couple things that have disappeared from the idea of problem solving as defined by the Six Sigma methodology. First and possibly irrelevant to this discussion is failure analysis – maybe a later discussion. The second is containment. If you are seeing a 5% failure rate internally there is a pretty good chance your customer is getting some as well. The first issue that needs to be addressed is containing that internally and stop the escapes. If you do that through more effective rework and you protect your customer then you have accomplished something. That removes the emotional charge from the customer. The problem is an internal issue at that point – unfortunately if it goes to the group of usual suspects for resolution that are in the daily fire fight it disappears. As a BB project it stays alive and can get some root cause resolution.

    Sounds like you are going where you need to go. As Truman said (approximately) "I’ll make a decision. If it is wrong I’ll make another one."

    Just my opinion.

  3. Mike Carnell


    I would love to get more detail if you are allowed.

    Thank you.

  4. Robin Barnwell

    M Jacobson, yes another good example of making a practical decision. Could have pushed the issues onto the supplier but in your case it made sense to change the process.

    Mike, thanks for the points, it came down to being way too expensive to stop the defects than to fix them when they occurred. I’ll cover in a bit more detail off-line if that’s OK with you?


Leave a Reply