Inside Assurance Toolkit #07 — Root Cause Analysis Working Paper

Root Cause Analysis Working Paper: Make the Cause Earn Its Place

A root cause conclusion should explain the mechanism behind a problem and survive a challenge from the evidence. Replacing “late dispatch” with “staff were not careful” does not achieve that. It changes the label without showing why the problem occurred.

Inside Assurance Toolkit #07 provides a reusable Excel working paper and a clearly marked fictional example. The paper connects the problem, evidence, symptom, immediate cause, candidate underlying causes, impact and proposed corrective or preventive action.

The case: the cutoff changes, but the dispatch rule does not

Imagine a fictional online retailer that moves its order cutoff later in the day. Some packed orders subsequently miss the intended dispatch wave. The first response is to retrain the packing team.

That response may be premature. A candidate explanation is that the dispatch priority table still reflects the previous cutoff. A competing explanation is that packing capacity becomes insufficient on high-volume days. Both can contribute; the working paper must make that uncertainty visible.

The worked example contains invented learning records, not observations collected from an actual business. Its evidence register illustrates a change log, dispatch timestamps and a shift observation. These suggest tests; they do not establish that either candidate cause is proven.

Separate the layers

Start with a bounded problem: what happened, where, during which period, and against which expectation? Describe the symptom separately from the immediate mechanism. In this example, late departure is the symptom; assignment to the wrong dispatch wave is a possible immediate mechanism.

Then record candidate underlying causes. For each one, link supporting evidence, consider contradictions or alternatives, record the assessment and define the next test. “Hypothesis,” “Supported,” “Not supported” and “Unresolved” are human assessments, not statistical confidence levels.

The workbook's completeness prompt identifies missing descriptions, evidence references or follow-up tests. It does not validate that a referenced evidence ID exists, or determine whether a cause is true. A plausible story can populate every field and still be wrong.

Use the workbook

1. Open the worked example and read the scope and limitations.
2. Complete the reusable RCA sheet with your own problem, scope, impact and analysis owner.
3. Register retrievable evidence references. Explain relevance, reliability limitations and the next verification step.
4. Enter candidate causes, supporting references and contrary evidence or alternative explanations. Where nothing contrary was identified, record what was checked; do not leave an unexplained blank.
5. State which conclusions are supported, which remain open and what could change the assessment.
6. Design actions around the supported mechanism. Identify the owner, agreed timing and how effectiveness will be evaluated.

The starter supports eight evidence records and eight candidate causes. Extend the formatted ranges and formulas before using additional rows.

Test the mechanism before choosing the action

For the dispatch example, trace configuration versions and compare intended versus actual wave assignment. Reconcile the order population before selecting cases. Compare relevant workload and capacity information, rather than assuming the timing change alone caused the delay.

If the rule mismatch is supported, a corrective action might align the priority rule with the revised cutoff through controlled testing and approval. A preventive action could add a downstream configuration impact review to future cutoff changes. If the capacity explanation is supported instead, the action needs to address that mechanism. Retraining may be useful where knowledge is a demonstrated factor; it should not stand in for an unexplained system dependency.

Know when to stop and when to reopen

Repeated “why” questions can help organize an investigation. A fixed number of questions does not prove that the deepest answer is the right one. Stop when the supported causal explanation is useful for an implementable response, while recording remaining uncertainties and contributing factors.

Reopen the analysis when subsequent evidence contradicts the mechanism or the issue recurs despite an implemented action. A recurring problem may indicate that the selected cause was incomplete, the action was not implemented as designed, or the operating context changed.

ASQ's root cause analysis resources provide general professional context. This Excel paper, case and explanations are original Inside Assurance material; they are not an ASQ template or certification assessment.

The practical test is simple: can another reviewer trace the conclusion to evidence, understand the alternatives considered and see why the proposed action addresses the mechanism?

Inside Assurance — Beyond the numbers. Inside the business.