On 3/25/00 8:30 AM, XXXX@aol.com at XXXX@aol.com wrote:

> Marc,
>
> How do you know you have true root cause in a corrective action process?

Like any investigation, you form a hypothesis and then design tests to prove or disprove it. You know you have the root cause when your experiments tell you so. Now, I say that with some hesitation, as it has been know to happen that an incidental cause is identified and corrected and the problem lessens to a point that it is not significant when compared to the magnitude prior to the fix. Same case in the event of multiple root causes (it happens).

> work in company were people answer 8Ds and corrective actions without
> identifying the real cause of the problem.
> People ask why but not always the
> right whys to reach the reason the problem occurred.

Not unusual. In fact, pretty common.

There is no way to tell someone when to stop asking WHY. There is no way to tell someone what WHYs to ask. There is training and experience. With consideration to Columbo, Perry Mason, Matlock, and all the detectives and cop shows - it should be evident that some folks 'have the gift' of asking the right questions and some quite simply do not. Training works for some folks. Some folks simply do not grasp the concept. Some people simply don't care (typically they believe they have a job to do and 8D investigations are not what they were hired to do).

Determination of root cause is not always straight forward and sometimes, in fact, a fix corrects the problem yet the fix does not address the 'true' root cause.

8D is supposed to be a cross-functional exercise. When this is truly the case often the differing ideas uncover the root cause. However, many times it becomes a matter of someone leading the 8D who has 'mastered' the art. This is the reason for structured investigations with tools such as fishbone diagrams and such.

> What is your answer to this predicament

Training - or pull a system into place where you appoint a 'master' to review and participate in appropriate meetings.

> and do you know of any web information that addresses the...

I don't really know of any specific web sites to recommend but there is an 8D pdf file in the pdf files directory. You might also try an extended web meta search at http://www.dogpile.com

Interesting dilemma. When do you stop? What is the best approach? What resources are dispensible?

I hope this thread draws some interest. I am curious to know what others think on this topic.

Same question, during the why-why analysis, when do we know that we still have a symptom and not a root cause? More often than not, we end up with more answers to the first 'why' than the number of symptoms we see, which is usually just one. Of course, experience will come in handy when choosing the most probable root cause.

My question will be, for inexperienced people, how do we know that we have the root cause?

Originally posted by Marloun:
Same question, during the why-why analysis, when do we know that we still have a symptom and not a root cause? ....
My question will be, for inexperienced people, how do we know that we have the root cause?

Was your corrective action effective in eliminating a reoccurrence? If not, did you treat the root cause or a symptom? Probably a masking symptom.

Asking "Why?" as traditionally written, five times, is not a fast rule. You may ask it twice to determine the true root cause, you may ask it eight times. The individual(s) doing the problem solving must agree that they have uncovered the true root cause and treat that. Experience, with the theory of '5-Whys?' will help to guide the process.

Regards,

Kevin

Kevin/Marc
Forgive me - but shouldn't the 5-Why practice lead a problem investigation to a more "root cause definitive" place to start a What-Where conclusion?

If you have a well defined Why - no matter if 3-5-8 times asked, wouldn't a what- where solution support the WHY conclusion in the first place? At least clarifying that you have in fact determined the true root cause?

Jim,

You make a very good point! Here is the problem. Asking the 'where' and 'when' can be introduced to the process at 3-5-8 'why's.

How do you know when to stop asking 'why' and begin to get in to the 'where' and 'when'? Any ideas? (PDSA)

Regards,

Kevin

Well If I can assume that I'm on the right path here... what I would consider is looking at the first 3 Why answers/conclusions.
1) - (are they in agreement)
2)do they seem reasonable for problem resolution-
3) or do I have 3 completely differnt opposing conclusions?

If the first three responses agree it should be time to move on to a what/where to change issue...

If all three resulting answers are completley at odds then I would think it's time to repeat the Why question a few more times, until a similar viewpoint (or appropriate solution starting point) was understood & agreeded to by all involved.

Then its time to plot the what/where PHYSICAL change - put the change in place and find out if your Why result was correct in the first place...

No-one could be expected to really know if you have asked the WHY "enough times" until a PHYSICAL change of some kind is put in place - View the results of the change - then (and possilby only then) could you be comfortable with the number of times the why question was posed.

With all these "why's", I only got more confused. Jim, can we have some clarifications on the scenario you gave, like a practical example perhaps? Rgds.

Plan-Do-Study-Act

Plan: create a theory of what went wrong. How many 'whys' you ask, either as a group or independently, is up to you. The 5-why technique is meant to drive the thinking beyond the superficial thinking. 3-5-8 or more, it only matters to the extent of how far you drive the thinking process.

An example

Problem: fuse on the press keeps blowing.

Q: Why did the fuse blow?
A: The press motor overheated.
Q: Why did the motor overheat?
A: The strain on the motor was excessive.
Q: Why was the strain excessive?
A: The material thickness used to make the part was too thick.
Q: Why was the material too thick?
A: The incoming material was over specification
Q: Why was it accepted over specification.
A: Gauge used to accept the material was out of calibration
Q: Why was it out of calibration?
A: We do not have a calibration program.

If we react to the 'problem' with superficial thinking, we end up replacing fuses, never addressing the root cause. We instead address a symptom. If we react to the line of questioning, we create a calibration program (which extends beyond the singular event) and perhaps react to some of the smaller whys as appropriate. Some problems have multiple root causes.

Do: train on and deploy your theory to eliminate the problem.

Study: Did you eliminate the problem? How did your theory work?

Act: Standardize or revise your theory.

As we are all aware, standardizing our practice results in a formalization of a process. We create procedures to address the 'when' and 'where' as Jim pointed out. Many times the process does drive you to gaps in the program or areas of fuzziness.

Just some more for the mix. Back to the group....

Regards,

Kevin

Jim,

You are correct in pointing out that the information supplied about the problem needs to be detailed (as much as is possible). My example is rather simple and could have been shaved down to fewer 'why' questions being asked.

An incorrectly stated problem, or lack of detail, could lead an investigation off track. In my CA training, I stress the importance of giving as much detail as possible. It can only help.

Regards,

Kevin

Kevin I agree, but to furhter the thought process.

Would not the following viewpoint draw us to the same conclusion?.

Q Why did the machine blow a fuse?
A Materials were oversized
Q Why are materials oversized?
A Gages used to verify incomming materials were not calibrated
Q Why were gages not calibrated
A Inadequate or non existant cailbration program

Same conclusion as in your example - less why's asked... the end result remains the same.
Do: Apply the theroy
Study: Was the problem corrected?
Act: Standardize the methods

IF the STUDY result of "Was the problem corrected" in either case proves that the problem was not corrected then and only then could you discover if you had stopped asking why too soon.

If you asked the exact same question, recieved opposing expierience information then more why questions would be needed.

Q Why did the fuse blow?
A1 Bad fuse
A2 old/worn machine
A3 Incomming power surge
A4 Materials too thick

Opposing answers would lead us to conclude that each branch answer would need investigation prior to starting the plan for application stage.

The number of why's to ask is directly dependant on the information received, and we won't know if enough whys were asked until action to apply the theroy has been made.

We just started our 5-why program. I will try to keep you posted. If I recall correctly this is what Chrysler uses. We are new to the ISO game and feel that this is more suited for our ISO maturity level.

Does anyone on the forums have any experience / info to share about Kepner-Tregoe method?
Thanx.
-Atul.

Does anyone on the forums have any experience / info to share about Kepner-Tregoe method? I think I do Atul, but I believe it's got another name here. I'll try to dig up some info about it, and get back to you.

A very short explanation (It's very good when processes go astray):

1. What is the difference between what you want and what you get? Define it very carefully.

2. When was the problem first noticed?

3. Where was it noticed (physically)?

4. Examine any changes to the process since detection. People *will* tell you that nothing has been altered but in the end there *will* always be something, (often seemingly insignificant).

5. Are any of these changes the likley cause for the change in process output? If so: try correcting them and see what happens.

6. Did the problem go away? If not: Try again.

/Claes

Kepner- Tregoe is an international training firm. The (PSDM) Problem Solving and Decision Making is a 3 day workshop,when completed 2 college credits are earned. Four disciplines are learned: situation appraisal,problem analysis,decesion analysis and potential problem/opportunity analysis. You can reach them at toll free 866-290-6699 or www.kepner-tregoe.com

I am trying to implement some of these techniques to my software dev processes, so I was looking for available alternatives.

From where I am located, it does not seem possible for me to take that course :(. I did try to find some info from the website you mentioned, but it was rather cryptic.

-Atul.

Plan-Do-Study-Act

Plan: create a theory of what went wrong. How many 'whys' you ask, either as a group or independently, is up to you. The 5-why technique is meant to drive the thinking beyond the superficial thinking. 3-5-8 or more, it only matters to the extent of how far you drive the thinking process.

An example

Problem: fuse on the press keeps blowing.

Q: Why did the fuse blow?
A: The press motor overheated.
Q: Why did the motor overheat?
A: The strain on the motor was excessive.
Q: Why was the strain excessive?
A: The material thickness used to make the part was too thick.
Q: Why was the material too thick?
A: The incoming material was over specification
Q: Why was it accepted over specification.
A: Gauge used to accept the material was out of calibration
Q: Why was it out of calibration?
A: We do not have a calibration program.

If we react to the 'problem' with superficial thinking, we end up replacing fuses, never addressing the root cause. We instead address a symptom. If we react to the line of questioning, we create a calibration program (which extends beyond the singular event) and perhaps react to some of the smaller whys as appropriate. Some problems have multiple root causes.

Do: train on and deploy your theory to eliminate the problem.

Study: Did you eliminate the problem? How did your theory work?

Act: Standardize or revise your theory.

As we are all aware, standardizing our practice results in a formalization of a process. We create procedures to address the 'when' and 'where' as Jim pointed out. Many times the process does drive you to gaps in the program or areas of fuzziness.

Just some more for the mix. Back to the group....

Regards,

Kevin
I was attending a presentation made by one of our client recently. In that presentation, they were mentioning of use of KT Analysis for vendor selecton and evaluation. Can anyone throw some light on this, please

I was attending a presentation made by one of our client recently. In that presentation, they were mentioning of use of KT Analysis for vendor selecton and evaluation. Can anyone throw some light on this, pleaseWelcome to The Cove varun! :bigwave: You raise a good question. What is your industry please?

Welcome to The Cove varun! :bigwave: You raise a good question. What is your industry please?
Hi Jennifer
I am into large scale Petrochemical Projects.

Arun

Well it's unusual but my search has come up dry. How about it everyone?

Arun, I will try to keep this question visible but please be patient as it is a holiday weekend for us, lasting up to four days for some. I, like most of us am at home and I will check in occasionally.

You're looking for Kepner-Tregoe Analysis. If you Google "Kepner-Tregoe Analysis" you will get plenty of hits.

Al,
I did google a lot. What I understood is this tool is a kind of decision statement analysis, having both an action and a result component. But I am not very clear how the same is used in a vendor selection or evaluation exercise. If any of the forum members have experience in the same, please let me know.

Arun

Does anyone have experience with this for vendors?

Kepner-Tregoe approach to decision analysis. Steps


Prepare a decision statement having both an action and a result component.
Establish strategic requirements (Musts), operational objectives (Wants), and restraints (Limits)
Rank objectives and assign relative weights.
Generate alternatives.
Assign a relative score for each alternative on an objective-by-objective basis.
Calculate a weighted score for each alternative and identify the top two or three.
List adverse consequences for each top alternative and evaluate probability (high, medium, low) and severity (high, medium, low).
Make a final, single choice between top alternatives.Arun, what specifically do you not understand about applying it to vendor selection?

Also See Delphi 5Whys trainning Course

http://elsmar.com/Forums/showthread.php?t=17313

:bigwave:

Hi,

I am working with a Beverage Manufacturing/Bottling Organization and we are in the process of having key staff trained on KT principles. The reason for this was that a number of our problem solving instances failed due to very fundamental issues - such as the problem itself being identified inaccurately, not being able to filetr out red herrings and so on.

If anyonle else has any experience with KT that would be great to know.

:)

The causes are in the system. Top management is responsible for the system. Does it then follow that true root causes are somewhat embarrassing to top management?

If this is the case, the leader saying "it is my fault" can help enormously in removing the fear that may otherwise keep some problem solving teams in the comparatively safe world of dealing with symptoms instead of root causes.

Also, some root causes are outside the scope of the system. In which case mitigation may, for practical reasons, trump root cause removal.

Dear John,

I agree most Root Causes, especially in systemic failures, would go all the way back to Top Management, but I would also like to add that, in some instances the top management are just not aware/knowledgeable of their own lackings/gaps. Indeed, in one case we had the root cause point to the MR team (initially) but then go further back to point towards the Quality dept for not appraising/educating the MR team.

Technical root causes are slightly easier to handle I guess!:)

I would spend time training people on how to write a good problem statement. Too often the nonconformance is documented like a narrative in a novel that makes it very confusing to really understand what the problem is. Without a good problem statement, its very likely that you will conduct a thorough investigation on the wrong problem, so no matter how much training you provide on 5 whys, you will never get to the real root cause. I knew a company that received a customer complaint because the color of a part was wrong. After a thorough investigation, it was concluded that the root cause was there weren't any color standards, so the corrective action was to purchase pantone charts. They contacted their customer to let them know what their CA was to reassure them that this would never happen again, the customer was very upset and stated that the color received was black when the color should have been red. My point is, had the person writing the nonconformance description captured a good problem statement that included what the customer received and what the customer should have received, the investigation would have had a better chance at revealing the real root cause.

I find it interesting that reading through everyone’s response there really is no reference to the AIAG Guidebook for Effective Problem Solving CQI-10. I have found this to be a good approach to problem solving and root cause analysis only because it speaks to changing the culture in an organization first - make everyone a problem solver not just a problem identifier.

It's and interesting read...

On root cause - I usually go down the road of listing out my whys and trying to drill down but I also ask this question: "If I eliminate this cause will the problem ever happen again?"

This helps me narrow down to the root cause that will have an impact on the corrective actions.

i would like to share this file with you>>> it helps me alot

i think many of you know it