5-Why Analysis in GMP Investigations
5-Why analysis is one of the simplest root cause analysis tools used in GMP investigations. It can help an investigation team move from the visible event toward the condition that allowed the event to occur.
Its simplicity is also its risk.
A 5-Why can be useful when each answer is supported by evidence and the causal chain remains logical. It becomes weak when the team fills each “why” with assumptions, stops at human error, or forces the analysis to reach a convenient answer.
In the broader investigation and CAPA lifecycle discussed in Pharmaceutical Investigations & CAPA, the purpose of root cause analysis is to support a defensible conclusion that can guide the right correction, CAPA decision, and closure rationale.
What 5-Why Analysis Is
5-Why analysis asks repeated “why” questions to move from an observed problem toward a deeper cause.
Despite the name, the method does not require exactly five whys. Some investigations may need three. Others may need six. The number matters less than the logic.
A strong 5-Why should show:
what happened
why it happened
what evidence supports each step
what condition allowed that event
whether that condition can be corrected, controlled, or monitored
The method works best when it produces a clear, evidence-supported causal chain. It does not work well when each answer simply restates the previous one in different words.
Start Simple, But Do Not Force the Tool
In practice, investigators may not know at the beginning whether the event is simple, multi-causal, repeat-related, or systemic. That is normal.
It is reasonable to begin with 5-Why when the event appears narrow and the team has a factual path to explore. The tool is simple, fast, and not resource-heavy. It can help the team test whether one causal path makes sense.
But the team should not stay with 5-Why if the evidence expands beyond a single path.
Switch or supplement the analysis when:
the chain branches into several possible causes
each answer depends on assumption rather than evidence
conflicting evidence appears
the event has repeat or trend history
the chain cannot explain the timing or detection point
the final answer is a generic label such as “human error”
the CAPA would not clearly address the final cause
In those cases, a broader method may be more appropriate. A Fishbone Diagram (Ishikawa) can help organize multiple cause categories. Fault Tree Analysis can help test logical failure pathways and control breakdowns.
The practical rule is simple:
Use 5-Why to begin testing a causal path. Continue only while each answer is evidence-supported and the claim remains logical. If the claim branches, conflicts with the evidence, or ends in a generic label, expand the analysis instead of forcing the fifth “why”.
How to Choose the Next “Why”
A good next “why” should ask what condition made the previous answer possible.
For example, if the answer is:
The operator missed the entry
The next question should not simply be:
Why did the operator make a mistake?
A stronger question is:
What condition made it possible or likely for the entry to be missed?
That question moves the investigation from blame toward process understanding.
The next “why” may explore:
Process condition: What in the process allowed this to happen?
Control condition: Why did the existing control not prevent, detect, or stop it?
Instruction condition: Was the SOP, batch record, form, method, or checklist clear and usable?
Human-performance condition: Was the task memory-dependent, interruption-prone, confusing, rushed, or poorly supported?
Equipment or system condition: Did equipment, software, alarms, screens, labels, or system restrictions contribute?
Management-system condition: Was there a weakness in change control, training, maintenance, supervision, escalation, or review?
This connects closely to Human Error Reduction Techniques. Human error reduction does not mean ignoring personnel actions. It means asking what work-system condition allowed the action to occur or go undetected.
Where It Is Okay to Stop
A 5-Why chain can stop when it reaches a supported, controllable condition.
The final cause should:
explain the event better than the earlier answers
be supported by documented evidence
identify a condition the organization can control
explain why the event was possible
fit the event timing and detection point
support a practical CAPA or justified no-CAPA decision
avoid simply restating the symptom or person’s action
Weak stopping points include:
operator error
lack of attention
procedure not followed
communication failure
training issue
analyst mistake
equipment issue
These may describe the event or a possible cause category, but they usually need more explanation.
Stronger stopping points are more specific:
batch record layout did not align with execution sequence
verification step occurred too late to detect the error
procedure allowed delayed documentation for a memory-dependent task
similar labels were stored together without adequate differentiation controls
system allowed manual entry outside the expected range
training did not include demonstrated competency for the revised task
The goal is not to make the root cause sound complex. The goal is to make it specific enough to support action.
Weak 5-Why Example
Event: A cleaning log entry was missing.
| Step | Answer |
|---|---|
| Problem | Cleaning log entry was missing |
| Why 1 | Operator forgot to complete it |
| Why 2 | Operator lacked attention |
| Why 3 | Human error occurred |
| Why 4 | Operator did not follow SOP |
| Root cause | Operator error |
This chain is weak because it does not explain why the entry was missed. It moves quickly from the event to the person. It does not evaluate the documentation process, timing, log location, workflow, interruptions, verification, or procedure clarity.
It also does not support a strong CAPA. The likely action would be retraining or reminder, even though the analysis has not shown that training was the causal gap.
This is one of the RCA failure patterns discussed in When Root Cause Analysis Goes Wrong: the investigation appears complete, but the reasoning does not actually explain the event.
Stronger 5-Why Example
Same event: A cleaning log entry was missing.
| Step | Question | Answer | Evidence |
|---|---|---|---|
| Problem | What happened? | Cleaning log entry was missing for Room A after cleaning was performed. | Cleaning log review; cleaning schedule |
| Why 1 | Why was the entry missing? | The entry was not made immediately after cleaning. | Operator interview; timing review |
| Why 2 | Why was the entry not made immediately? | The log was completed after several rooms were cleaned, not at point of use. | SOP review; workflow observation |
| Why 3 | Why was delayed completion allowed? | The procedure allowed end-of-shift documentation for multiple rooms. | Current SOP requirement |
| Why 4 | Why did delayed completion create risk? | Personnel relied on memory to reconstruct which room was cleaned and when. | Interview; sequence review |
| Supported cause | What condition allowed the event? | The documentation process allowed delayed, memory-dependent recording instead of point-of-use completion. | SOP review; workflow evidence |
This version is stronger because the final cause identifies a controllable condition. The issue is not simply that a person forgot. The process allowed documentation to depend on memory after multiple rooms were cleaned.
A stronger CAPA direction may include:
revising the procedure to require point-of-use documentation
relocating or redesigning the log so it is available where the activity occurs
adding a verification point if risk justifies it
checking subsequent records to confirm point-of-use completion
The CAPA should match the supported cause. If the root cause is memory-dependent delayed documentation, retraining alone may not address the condition that allowed the event.
QA Stress Test for the 5-Why Table
A 5-Why table should be able to stand up to QA review.
| QA Review Question | What the 5-Why should show |
|---|---|
| Is the event stated as fact, not conclusion? | The problem row describes what happened, not why it happened. |
| Is each “why” supported by evidence? | Each answer connects to a record, interview, observation, or documented review. |
| Does the chain explain timing? | The cause makes sense based on when the event occurred and when it was detected. |
| Does the chain explain control failure? | The analysis considers why existing controls did not prevent or detect the issue. |
| Does the chain avoid stopping at human error? | Personnel actions are explored further into task, process, procedure, or control conditions. |
| Can CAPA address the final cause? | The final cause points to something the organization can change, control, or justify. |
If the table cannot answer these questions, the 5-Why may need more evidence or a different RCA method.
Common 5-Why Mistakes
A 5-Why can go wrong in predictable ways.
One common mistake is starting with a biased problem statement. For example, “operator failed to follow procedure” already assumes the cause. A better starting point is factual: “Required entry was missing from the cleaning log”.
Another mistake is making each “why” a judgement rather than an evidence-based answer. “Lack of attention”, “carelessness”, and “failure to follow SOP” often do not explain the condition that made the event possible.
A third mistake is forcing the chain to exactly five “whys”. If the supported cause is reached at four, stop. If the chain still does not explain the event after five, continue or change methods.
A fourth mistake is ignoring alternate causes. If the evidence suggests procedure clarity, workflow, verification timing, and training may all be relevant, a single 5-Why chain may be too narrow.
When to Use Another RCA Tool
5-Why is useful, but it is not the right tool for every investigation.
Use or add a broader tool when the event involves several possible cause categories, such as personnel, equipment, material, method, environment, documentation, and controls. A Fishbone Diagram (Ishikawa) is often useful in that situation because it helps organize multiple possibilities before narrowing the conclusion.
Use or add a more logic-based tool when the investigation needs to test combinations of failures, control breakdowns, or different pathways that could lead to the same event. Fault Tree Analysis can be useful when the team needs to understand how different conditions combined to allow the failure.
Changing tools is not a weakness. It is a sign that the investigation is following the evidence.
QA Review Perspective
5-Why analysis is not weak because it is simple. It becomes weak when it becomes a straight line of assumptions.
A strong 5-Why shows traceable reasoning from the event to the supported cause. It explains why the event happened, why the condition existed, and why the final cause is specific enough to support action.
QA reviewers should look for logic, evidence, and control relevance. The best 5-Why analyses are not the longest. They are the ones where each answer is supported, each step follows from the previous one, and the final cause helps the organization decide what should change.
Used well, 5-Why can be a practical RCA tool for GMP investigations. Used mechanically, it can hide weak reasoning behind a familiar format.
Explore more on Investigations & CAPA Excellence
Browse VerethiQ resources on deviation handling, root cause analysis, investigation quality, CAPA design, effectiveness checks, recurrence prevention, and investigation governance.
