Learn the 5 Why Root Cause Analysis Process
Unknown-Unknowns Can De-Rail a Program. At times during a high tech development program, unknown-unknowns can occur that impact the program’s ability to meet cost, schedule, or performance objectives. Early warnings that something is amiss are often discerned from the alerts provided by unacceptable in-process drops in either the program’s cost performance index(CPI) or its schedule performance index(SPI). (These indices are discussed in detail in the Program Management Tutorial.) Engineers must learn the 5 Why Root Cause Analysis Process (discussed further herein) to ascertain the fundamental cause(s) of an issue resulting in a failing to assure that fixes are not just band-aids.
Get to the Root Cause for a Real Fix & Not a Band-aid
Determining the root cause of the issue causing the CPI/SPI drop in a timely fashion is essential so that corrective / preventive actions can be implemented. This is necessary to preclude further occurrences of the issues and further erosion of these important indices. After a set back, it is key to develop & implement recovery plans to get the program back on track. Therefore, getting to the real cause or causes and not just the symptoms of the problem is crucial to assure that the fixes implemented are not just ‘band-aids’ but are truly adequate to prevent reoccurrences. Therefore, it is important for engineers and managers to learn root cause analysis & the 5 why process. It is a management process that is key to program success.
5 Why? – An Effective Causal Analysis Process
Root cause analysis & the ‘5-Why?’ process is a very effective and simplistic practice to apply and learn root cause analysis. It facilitates the ability to get to the real cause(s) of an issue easily.
Why this practice is called the ‘5-Why?’ process
The basis of root cause analysis & the 5 why process is embedded in the following scenario: If the question is asked why an issue is occurring or has occurred, usually the 1st answer to why an issue is occurring is generally just a symptom of the issue and not the ‘root cause’. For example: ‘Why is there blood on your shirt?’ ‘I cut my hand’ is a symptom and basing it on a fix such as ‘putting on a ‘band-aid’ will not prevent getting cut again. Asking Why? a 2nd time i.e. asking why the 1st answer is occurring gets closer but is usually a symptom as well. ‘Why did you get cut?’ ‘The tool I used had a sharp edge that cut me’ is also a symptom. Asking Why? 3-5 times more as to why each of the previous answers are occurring gets to the root cause or primary causes with a much higher probability. Implementing corrective / preventive actions at this level will tend to fix the systemic issues which are at the core of the problem. So continuing with the example, ‘Why did it cut you?’ ‘I used it for the 1sttime and did not get trained yet’. This is clearly a more primary cause. ‘I also forgot to wear gloves.’ is another primary cause and ‘The tool I used wasn’t the correct one for the job.’ is also a primary cause. Fixing these causes will have a meaningful effect on preventing cuts. Learning root cause analysis & the 5 why process will in effect be learning a powerful yet simple root cause analysis technique.
Why Asking More than 5 times is Counterproductive
Note: Asking ‘Why?’ too many times can get meaningless results in terms of implementing corrective / preventive actions. For example, ultimately if you ask ‘Why?’ enough times you’ll get the result that the ‘Big Bang’ is the root cause of all the previous answers. Asking about 5 times has been found to be reasonable and effective in applying root cause analysis & the 5 why process.
Categorizing The Issues
A key part of root cause analysis & the 5 why process involves categorizing the issues. Categorizing enables the analysis, and from the example about getting cut, we see that there are 4 categories of causality issues:
- ‘People’ issues (staff may lack the needed training or expertise to do the job)
- In this case the person doing the job was not experienced or trained
- ‘Tools’ issues (tools may be unreliable, defective, or difficult to use)
- In this case tools were not marked to assure the correct one was selected
- ‘Input / Requirements’ issues (input or requirements may be incomplete, ambiguous, or incorrect)
- In this case the job needing a tool did not specify the required tool needed
- ‘Methods / Process’ issues (methods may be incomplete, ambiguous, wrong, or not followed)
- In this case there were no ‘how-to-use’ procedures in place
State the Problem Accurately & Determine the Systemic Issues
Before the root cause analysis & 5 why process can begin, a clear and accurate ‘Statement of the Problem’ must be established. Moreover, data regarding the problem must be obtained and analyzed to determine the systemic issues impacting the problem. Once the stated problem is agreed to, the ‘5 Why?’ causal analysis can begin.
Fishbone Diagram / Bulletized Template
Diagramming the ‘5-Why?’ causal analysis procedure using a ‘Fishbone / Ishikawa’ diagram (shown in the high tech management guide) (The diagram looking like a fishbone was developed by Haoru Ishikawa in 1968.) helps in visualizing the process.
An alternative template (bulletized not fish bone) is advantageous in that it uses the ‘5-Why?’ method directly for each category without the need to diagram it. (also shown in the high tech management guide). Using the ‘5-Why?’ categorizing and issues drill-down approach yields several primary causes (the lowest indented answers to each of the “Why’s” for each issue. Implementing corrective / preventive actions at this level will tend to resolve the systemic issues which are at the core of the problem to preclude repetition as opposed to just ‘band-aiding’ the symptoms.
Process Summary
- Develop a Statement of the Problem
- Obtain and analyze data to determine the systemic issues impacting the undesirable outcomes
- Partition the assessment in to 4 principal causal categories:
- Methods / Process (methods may be incomplete, ambiguous, wrong, or not followed)Tools (tools may be unreliable, defective, or difficult to use)
- Tools (tools may be unreliable, defective, or difficult to use)
- People (staff may lack the needed training or expertise to do the job)
- Input / Requirements (input or requirements may be incomplete, ambiguous, or incorrect)
- Identify the principal cause(s) using a cause-and-effect (Fishbone / Ishikawa) diagram or use the ‘5-Why?’ method directly using a bulletized template without the need to diagram it