Clearly define the undesirable outcome
- Describe the undesired outcome.
- For example: “satellite failed to deploy,” “employee broke his arm,” or “XYZ project schedule significantly slipped.”
Identify facts surrounding the undesired outcome.
- When did the undesired outcome occur?
- Where did it occur?
- What conditions were present prior to its occurrence?
- What controls or barriers could have prevented its occurrence but did not?
- What are all the potential causes?
- What actions can prevent recurrence?
- What amelioration occurred?
- Did it prevent further damage or injury?
In order to gather data, you can also use one of the following data collection and display tools:
o Data Collection Forms
o Tally (or check) sheets
o Run Charts
o Scatter Diagrams
o Concentration Diagrams
o Workflow Diagrams
o Pareto Diagrams
Create a timeline (sequence diagram)
- Illustrate the sequence of events in chronological order horizontally across the page.
- Depict relationships between conditions, events, and exceeded or failed barriers/controls.
If amelioration occurred (e.g., put out the fire, cared for the injured), this should be included in the evaluation to ensure that it did not contribute to the undesired outcome.
Example: In the case of a death, the investigation should ensure that the death was the result of the mishap and not a delay in medical care or inappropriate medical care at the scene.
Create an event and causal factor tree
A visual representation of the causes that led to the failure or mishap.
- Place the undesired outcome at the top of the tree.
- Add all events, conditions, and exceeded/failed barriers that occurred immediately before the undesired outcome and might have caused it.
Brainstorm to ensure that all possible causes are included, NOT just those that you are sure are involved.
Be sure to consider people, hardware, software, policy, procedures, and the environment.
If you have solid data indicating that one of the possible causes is not applicable, it can be eliminated from the tree.
Caution: Do not be too eager to eliminate early on. If there is a possibility that it is a causal factor, leave it and eliminate it later when more information is available.
You may use a fault tree to determine all potential causes and to decompose the failure down to the “basic event” (e.g., system component level).
Most problems, even the most complex or serious, can be handled by asking "why" five times. Without asking why more than once, there is a danger that the root cause that has been identified is a contributor to the failure under investigation, but not the true underlying root cause. This could lead to misdirected corrective actions and a recurrence of the failure. Taiichi Ohno considers repeatedly asking why to be the scientific approach on which the Toyota production system is based. Repeatedly asking why prevents focusing on obvious symptoms while ignoring the true root cause.
- After you have identified all the possible causes, ask yourself “WHY” each may have occurred.
- Be sure to keep your questions focused on the original issue. For example “Why was the condition present?”; “Why did the event occur?”; “Why was the barrier exceeded?” or “Why did the barrier fail?”
- Continue to ask “why” until you have reached:
- Root cause(s) - including all organizational factors that exert control over the design, fabrication, development, maintenance, operation, and disposal of the system.
- A problem that is not correctable by NASA or NASA contractor.
- Insufficient data to continue.
- The resultant tree of questions and answers should lead to a comprehensive picture of POTENTIAL causes for the undesired outcome.
- Check your logic with a detailed review of each potential cause.
- Verify it is a contributor or cause.
- If the action, deficiency, or decision in question were corrected, eliminated or avoided, would the undesired outcome be prevented or avoided? If no, then eliminate it from the tree.
- The remaining items on the tree are the causes (or probable causes). necessary to produce the undesired outcome.
- Proximate causes are those immediately before the undesired outcome.
- Intermediate causes are those between the proximate and root causes.
- Root causes are organizational factors or systemic problems located at the bottom of the tree
- Some people choose to leave contributing factors on the tree to show all factors that influenced the event. If this is done, illustrate them differently (e.g., dotted line boxes and arrows) so that it is clear that they are not causes.
- Example involving Satellites:
What if the root cause is still unknown?
- If the root cause is still hidden from view, it is time to retrace the steps taken, starting way back with the Problem Statement.
- Something may be "missing;" ask:
o Is the task clear?
o Has the process been properly defined?
o Does the team have the necessary skills, knowledge and experience to tackle the job?
Parting thoughts regarding finding the root cause:
- Rarely will all tools and techniques be needed to uncover a root cause. Experience is the best judge to determine the best order to use the various tools and techniques available to search and question processes for the root cause to a specific problem.
- When the root cause is found, always ask the "root cause question:
"Does this cause (or causes) explain all that we know about what the problem is, as well as all we know about what the problem isn't?"
- If answer is a resounding "YES," the root cause has most likely been found and hearty congratulations are in order.
For further reading, refer to the IAQG section on Root Cause Analysis and Problem Solving.