How to Run a Small-Business Root-Cause Review

The team has fixed the same missing-input problem three times. A root-cause review investigates the conditions behind a recurring outcome before choosing another fix. It should distinguish what the evidence shows from explanations that still need checking.

Two people standing beside a wall-mounted whiteboard with a short task list.

Photo by Sable Flow on Unsplash.

Start with a specific event

Describe what happened, where, when and against which expected result. Bring representative cases and the people who understand the work. “Communication is poor” is a conclusion too broad to test. “Delivery started without the approved brief in four reviewed cases” gives the conversation a boundary.

Trace the conditions

Ask what allowed the event to happen and what evidence supports each answer. A sequence of “why” questions can help, but do not force a single chain when several factors interact. Look at inputs, instructions, tools, capacity, handoffs and authority.

Record the investigation

  • Observed event and consequences.

  • Evidence and missing information.

  • Contributing conditions and alternative explanations.

  • Proposed change and expected mechanism.

  • Trial owner, measure and review date.

An illustrative review

A late report initially appears to be a scheduling error. Reviewing cases reveals that required data arrives after the production slot and no role owns renegotiating the date. The trial adds an earlier readiness check and an explicit decision route when the input is late.

Seek a contrasting case as well. If another report received late data but still met the agreed outcome, investigate what differed: scope, capacity, preparation or an earlier decision. That comparison may expose a missing part of the explanation. A useful review asks what evidence would weaken its current theory, not only what supports it.

Related guidance: practical process-mapping guide.

Avoid treating the first plausible explanation as a proven root cause. Test the proposed change and retain unresolved uncertainty in the record. If the result does not improve, revise the explanation rather than defending the original meeting conclusion. Hili Consulting can help structure the investigation around observable work and a manageable next experiment.

Previous
Previous

Where Should You Put a Quality Check in a Repetitive Workflow?

Next
Next

How to Track Rework Without Blaming the Team