Root Cause Analysis Methodology Framework

Background:
This is a framework to be used to assist you in getting to the root cause of a problem quickly and methodically. A problem is defined as: A deviation of the ACTUAL from the STANDARD, SPECIFICATION or NORM. and The cause of the deviation is UNKNOWN or UNPROVEN.

Step 1 :

Problem Identification

This step assists the problem solver to stay on track and to focus on the real problem. It also assists in narrowing down the search for specific and relevant information about the problem. METHOD: When documenting the problem identification, ask: What is the object / thing / machine that you are having trouble with? What is wrong with it? OR What is the defect or fault? NOTES: Be as specific as possible. Ensure that the problem identification contains only one object or thing, unless the objects or things are identical or have identical defects or faults. Ensure that the problem identification contains only one defect or fault. Check how the defect or fault was proven.

Step 2 :

Problem Description

Describing the FACTUAL DATA of the problem, serves to describe the problem in all its essential detail. Describing what the COULD BE - BUT IS NOT data of the problem, serves to zero in on the problem because it sharpens and clarifies the FACTUAL DATA. It also provides a basis for comparison and testing of possible causes. METHOD: The problem is described in four dimensions: IDENTITY or WHAT LOCATION or WHERE TIMING or WHEN IMPACT or SIZE Make sure the FACTUAL DATA is the most specific information available. Make sure that the COULD BE - BUT IS NOT data is as close as possible to the FACTUAL DATA. NOTES: Keep on asking; CAN WE BE MORE SPECIFIC? Dig for FACTUAL DATA information. Identify time patterns i.e. Continuous, Periodic & Sporadic.

Step 3 :

Possible Causes

Identifying possible causes may lead us to the true cause very quickly. METHOD: Author : Johan (Lompies) Lombard File path & name : 97726194.doc Last revised : 2008-08-07 Page : 1 of 3

Root Cause Analysis Methodology Framework

List all the possible causes without trying to discuss it or argue about them. In order to get these listed as quickly as possible you must: Use your gut feel (instinct), logic, past experience or educated guesses? Examine the following by asking, HOW COULD ANY OF THESE HAVE CAUSED THE PROBLEM? o Men o Machines o Methods o Materials o Money o Environment NOTES: Phrase a logic statement of how the problem could have been caused. Just list and number them all do not discuss the probability / validity!

Step 4 :

Test Possible Causes

When many possible causes exist for a problem, our natural reaction is either to fix every possible cause OR to support a particular possible cause. This WILL lead to wasted time, effort & money! We MUST TEST TO DESTROY ALL possible causes generated. Only that ONE, maybe two, possible causes that cannot be destroyed by our destructive testing, will deserve further investigation. METHOD: For each possible cause ask: If this cause is really the true cause, how does it explain both ALL the factual AND ALL the could be data of the problem description? Rate the possible causes which survived the destructive testing in order of most probable to least probable, by comparing them to each other. NOTES: Be destructive and critical when you test. Remember that the cause must explain all the data! If the possible cause does not explain the information on the description, forget it, it is a born loser! Sometimes however the possible cause may not explain the description information completely BUT you can make a reasonable AND logical assumption to explain the full description, then write your assumption as follows: A.1 Only if Number the assumptions made. The more assumptions you make, the less likely that this will be the true cause of the problem! During this phase it may happen that you detect information which expand the factual and or could be data. If this happen add these to the factual / could be data and test the possible causes you have already tried to destroy, again. During this step you might need to use the process of elimination to prove the cause. THESE MUST BE DOCUMENTED RANKED FROM

Step 5: Verify most Probable Cause

So far we have proved the most probable cause in theory against our specification. Before you can decide on any action to overcome the problem you must also (if possible) prove in practice that the most probable cause is in fact the true cause.! METHOD:

Author : Johan (Lompies) Lombard File path & name : 97726194.doc

Last revised : 2008-08-07 Page : 2 of 3

Root Cause Analysis Methodology Framework

If you had to made assumption you must check ALL the assumptions you made in practice to verify that each assumption is in fact true. Physically check if your most probable cause is the true cause. Finally you must verify that the problem remains solved after you have fixed the cause.

During this step you might need to use the process of elimination to prove the most probable cause is in fact the real cause. During the process of elimination the following is important: Document ALL actions to be taken to prove the real cause or narrow down on possible causes. Rank all these actions, from which action will narrow down possibilities the most to which action will narrow down the possibilities the least. Methodically implement each action BUT NEVER more than one at a time. NOTES: Use the quickest, easiest, safest & simplest method to do the checking. Do not disrupt a whole process to do this unless the process is down! Although this is an important step it is sometime impossible to verify. In such cases this step may be skipped.

Step 6: Pro-active Fix

Fixing the current problem is only part of the process of solving problems. Other similar objects may have the same problem requiring the same fix or the same problem may re-occur at a later stage. Unless we take action now to deal with these situations we will only have to deal with them later in crisis mode. METHOD: Before implementing a fix and after our most probable cause has been verified, we MUST ask: Are there identical things / objects/ products that need the same fix? What other damage has the cause done here? What other damage can this cause create? What caused the cause? NOTES: If necessary update/create processes / procedures / standards / rules, etc.

Author : Johan (Lompies) Lombard File path & name : 97726194.doc

Last revised : 2008-08-07 Page : 3 of 3