Finding the Cause

A finding names a symptom. Acting on the symptom produces nothing, and the log contains enough to locate the cause if you look in the right direction.

The direction

Upstream, always.

A rejected approval was caused at submission.

A correction loop was caused by whatever created the error.

A delay at one step is frequently caused by what the previous step failed to provide.

Start at the symptom and walk backwards through the trace, which is the whole method.

The comparison

Split cases into those with the problem and those without.

Compare their earlier steps. What did the failing cases do differently before the failure.

Compare their attributes. Customer type, value, channel, product, requester.

Compare their resources, at team level.

Compare their timing: hour, day, period.

One of these usually separates the two groups cleanly, and that is the candidate cause.

Testing the candidate

Does it precede the problem in time? Necessary and easy to check.

Does it explain the volume? A cause present in five percent of cases cannot explain a problem in thirty.

Are there counter-examples? Cases with the candidate and no problem, which weaken it.

Does the operation recognise it? The strongest test available and the fastest.

The alternatives to rule out

Before concluding, list what else could produce the same pattern.

A confounded attribute: the channel that fails also differs in customer type.

A data defect that affects one segment.

Volume, where the problem simply rises with throughput.

A change in the period, such as a system release or a policy change.

Test the ones you can, and state the ones you cannot.

Where the log runs out

The log will tell you which cases fail and what they had in common.

It will not tell you why that commonality causes failure.

Ask. The people handling those cases usually know immediately, and the answer is frequently something nobody thought to record.

Then the finding is complete: a measured pattern plus an explanation from the people in it.

Reporting it

Symptom, with its cost.

Candidate cause, with the evidence.

Alternatives considered and why rejected.

The explanation from the operation.

The proposed change, and what would be measured afterwards.

One page. A root cause presented without the alternatives will be dismissed by the first person who thinks of one, and there is always one.

The upstream comparison table

The specific procedure, on one page.

Two columns: cases with the problem, cases without.

Rows: each earlier activity present, each attribute value, each resource team, each timing bucket.

Fill in the proportion for both columns.

Rows where the proportions differ sharply are candidates.

Rank by the size of the difference, then test each against volume: a candidate present in five percent of cases cannot explain a problem in thirty.

Asking the operation the closing question

The log identifies the pattern; only people supply the mechanism.

Show them the pattern: these cases share this attribute and they fail.

Ask why that would cause it.

The answer is usually immediate and frequently something nobody thought to record.

Where they disagree with the pattern, check the data before arguing, because they are right more often.

Record their explanation as part of the finding, because a measured pattern without a mechanism will not be acted on.

Getting past the first explanation

The log identifies where; the reason requires going further.

Segment the affected cases and look for what they share: customer type, product, channel, originating team, time of arrival.

Trace ten cases end to end, by hand, reading the actual records.

Ask the people who handled them.

Look upstream. A delay at approval is frequently caused by incomplete information supplied three steps earlier.

Distinguish the trigger from the condition: the missing document is the trigger, the form that permits submission without it is the condition, and only the second is fixable.