Trace a supported process cause without blaming a person
A useful root-cause definition separates three things: the symptom you observed, a condition that helped it happen, and the cause supported by evidence. For a community craft workshop, that might mean two people receive confirmations for the same seat; phone and online bookings are being handled in separate records; and a delayed update leaves a seat available online after it has been reserved by phone. The last statement is a cause only if the records support that mechanism. This is a practical way to write up a small process problem, not a claim that every analysis must use one fixed set of labels.
What does “root cause” mean in a small project?
The American Society for Quality (ASQ) defines a root cause as a factor that caused a nonconformance and should be addressed through corrective action. It describes root-cause analysis as a way to uncover why a problem occurred, and notes that event-and-causal-factor analysis uses evidence and a timeline to identify causal and contributing factors. Those ideas support a simple working definition: a root cause is an evidence-supported part of a process that explains how the stated problem occurred and that a practical change can address. ASQ’s root-cause analysis guidance
“Root” can suggest there is only one cause. In real process problems, several factors may work together. ASQ itself refers to causal and contributing factors, so a careful write-up can identify more than one cause where the evidence supports it. Avoid choosing a convenient explanation simply because it is the first one someone suggests.
How are a symptom, a contributing condition, and a cause different?
These labels help make a short problem statement clearer. They are a writing aid, not a substitute for investigating what happened.
A condition may contribute without explaining the whole mechanism. For example, a busy workshop may coincide with a delayed update, but “it was busy” alone does not explain why a second confirmation was possible. The cause statement should connect the process to the outcome, and it should be supported by something checkable: timestamps, booking records, or a walk-through of the reservation steps. If that evidence is missing, call the explanation a possible cause until it is checked.
A short sequence of questions to find a supported cause
Start with the event rather than a judgment about a person. ASQ recommends methodically establishing a timeline and analyzing causes and effects; the following questions apply that approach to a small booking problem. ASQ’s overview of root-cause analysis
This resembles a “five whys” inquiry, but five is not a required number. Stop when you have a specific, checkable process explanation that accounts for the event and can guide a test of a fix. If a question produces speculation rather than evidence, mark the uncertainty and find a record or observe the process before treating the answer as established.
Write the finding without overstating it
A concise write-up can use this pattern:
> Symptom: [Observable result.] Contributing condition: [Circumstance that made it more likely.] Cause supported by evidence: [Process mechanism, plus the evidence that supports it.]
Applied to the illustrative scenario above:
The example is hypothetical; its evidence is part of the illustration, not a report about a real workshop. In an actual investigation, replace the assumed sequence with records you have checked. If you cannot yet establish that a phone booking preceded the second confirmation or that the online list still showed the seat as open, write “possible cause” and specify what you need to verify.
Choose a reversible fix and check whether it addresses the mechanism
For a low-risk trial, the workshop could use one shared availability ledger for every booking channel. Staff would record a reservation and mark the seat unavailable before confirming it, whether the request arrived by phone or online. This targets the proposed mechanism—two channels confirming from different or stale views—without requiring a permanent system change.
Try the procedure for a limited set of upcoming sessions, with a clear start and end point. Compare each confirmation against the shared ledger and ask the staff handling bookings whether they could follow the sequence consistently. If duplicate confirmations continue, or the ledger is not reliably updated before confirmation, the trial has not established that this change controls the cause. Review the steps and evidence again; do not assume that repeating the same fix will solve a different mechanism.
A good definition therefore does more than name a problem. It lets another person see what was observed, what condition may have contributed, what process explanation the evidence supports, and how a small, reversible change could test that explanation.
Sources and scope
Original double-booking example follows evidence to a reversible process test. The listed sources support the stated facts; examples and exercises are original editorial applications.