Every organization eventually faces the same question from two directions. Before something goes wrong, the question is: what could go wrong, and what would it cost? After something goes wrong, the question changes: what actually happened, and why? Forward-Tracing Risk Analysis is MKA’s answer to the first question. Root Cause Analysis is the discipline that answers the second.
They are not competing tools. They are the same discipline of rigorous inquiry pointed in opposite directions — one anticipates failure before it happens, the other traces failure back to where it started once it has. A mature organization needs both, and neither substitutes for the other.
What Root Cause Analysis Actually Does
Root Cause Analysis is a systematic method for working backward from a symptom to its source. Something has already gone wrong — a manufacturing deviation, a clinical hold, a failed submission, an attrition spike — and RCA exists to trace that visible problem back through the chain of events that produced it.
The logic is the same one a physician uses with a patient. The symptom is rarely the disease. High employee attrition is not the problem — it is the visible output of a problem, and the actual cause might be several steps removed: unreasonable deadlines, which were themselves driven by a raw material shipping delay upstream. RCA’s job is not to treat the symptom. It is to find the actual point of failure and fix that, so the same symptom does not recur through the same mechanism.
This is why RCA is required by regulators and treated as foundational to quality system integrity in life sciences: it is the tool that converts a single failure into a permanent process improvement, rather than a one-time fix that leaves the underlying vulnerability intact.
The RCA Process
A disciplined RCA moves through the same sequence regardless of technique:
- Data collection — logs, process documentation, process maps, and interviews with the people closest to the failure.
- Sequence tracing — reconstructing the actual chain of events, not the assumed one.
- Root cause identification — looking past the immediate, proximate cause to the deeper condition that made the failure possible.
- Solution development and monitoring — implementing the fix and tracking whether it actually prevents recurrence, not just whether it feels resolved.
- Documentation and knowledge sharing — capturing what was learned so the same failure mode is recognized faster next time, by a different team, in a different part of the organization.
The techniques below are different ways of executing steps two and three. The process around them does not change.
Choosing the Right Technique
No single RCA method fits every problem. The right choice depends on the complexity of the system, the type of failure, and how much structure the investigation needs.
| Technique | What It Does | Best Used When | Limitation |
| 5 Whys | Asks “why” repeatedly (typically five times) to drill through surface causes to the underlying one | The problem is straightforward and a fast, low-overhead investigation is enough | Can oversimplify complex, multi-cause failures; output depends heavily on who’s in the room |
| Fishbone (Ishikawa) Diagram | Visually maps potential causes across categories — methods, machines, people, measurements, materials, environment | The failure could stem from several different systems and you need a structured way to brainstorm broadly | Can become unwieldy on complex problems; doesn’t guarantee every real cause gets surfaced |
| Fault Tree Analysis (FTA) | Starts from the failure and works backward through a decision-tree logic diagram | The system is complex and safety-critical — aerospace, nuclear, high-risk manufacturing | Requires real expertise to build and interpret correctly; time-intensive |
| Pareto Analysis | Identifies the small number of causes (roughly 20%) responsible for most of the impact (roughly 80%) | You need to prioritize where to focus limited investigation or remediation resources | Assumes a specific distribution; can miss lower-frequency but still-critical causes |
| Barrier Analysis | Identifies which safeguards — physical, procedural, human — failed, were missing, or were bypassed | Investigating safety-critical incidents where a control should have prevented the outcome | Tends to focus on the failed barrier itself rather than the systemic issue behind it |
| Change Analysis | Compares the failure state against a comparable situation where the problem did not occur, to isolate what’s different | A clear “before” baseline exists — a process, equipment, or material change preceded the failure | Requires a genuinely comparable reference case, which isn’t always available |
| Root Cause Confirmation | Tests whether removing or altering the suspected cause actually eliminates or reduces the problem | As a validation step alongside any of the above methods, before committing to a fix | Difficult to apply cleanly when the failure is intermittent or rare |
A separate, more structured technique — Failure Mode and Effects Analysis (FMEA) — deserves its own treatment rather than a table row here, since it’s proactive rather than investigative: it evaluates a process before failure to identify where it’s most likely to break. See Understanding FMEA in Product Development for the full framework.
In practice, most real investigations combine two or three of these techniques rather than relying on one. The choice depends on the nature of the problem, the complexity of the system, and the expertise of the team conducting the analysis.
RCA vs. FTR: The Essential Distinction
Both tools belong in a mature organization’s risk management approach. The distinction is not which one is better — it is that they operate in opposite directions, address different questions, and deliver value at different moments in a program’s life.
RCA is backward-looking. It investigates past failures. Its trigger is a failure event, and its output is corrective and preventive action. It is required by regulators and essential for quality system integrity. Its value is delivered after something goes wrong.
FTR is forward-looking. It anticipates future exposures. Its trigger is a program being planned. Its output is risk-informed decisions — assumptions tested before capital is committed, vulnerabilities identified while course correction is still inexpensive. Its value is delivered before damage is done.
Neither replaces the other. An organization that relies only on RCA is accepting that it must absorb the cost of failure before its analytical rigor activates. An organization that relies only on FTR has no formal mechanism for learning from what actually goes wrong despite the best front-end planning. The two disciplines close the loop on each other — see Forward-Tracing Risk Analysis: Seeing Risk Before It Arrives for the front-end counterpart to everything above.
The MKA Perspective
| MKA STRATEGIC IMPLICATION Root Cause Analysis and Forward-Tracing Risk Analysis are two sides of the same discipline — one interrogates what could go wrong before it happens, the other traces what did go wrong once it has. Together they form a complete picture of how a mature organization manages risk across the full life of a program. |
Root Cause Analysis is one of the most disciplined tools in life sciences and operations management — but its value depends entirely on choosing the right technique for the problem and following through past the point of comfort, into the actual systemic cause rather than the first plausible-sounding answer.
We use RCA as one of several tools in a broader risk mitigation practice, alongside forward-looking disciplines like FTR.
MKA Insights brings root cause analysis and broader risk mitigation frameworks to life sciences and healthcare organizations. To discuss how this applies to your program, contact us.