2. Problem definition and scoping

Root cause analysis rarely fails because the statistical tooling is too weak. It fails because the problem was never defined precisely enough to be solved. A team that begins with "the line keeps stopping" or "yield dropped last month" has no shared object of study, no measurable success criterion, and no way to know when the investigation is finished. This chapter treats problem definition as an engineering deliverable in its own right: a bounded, falsifiable statement of what failed, where, when, and under what conditions — expressed as questions that data can actually answer.

From Symptom to Failure Event

A symptom is what an operator or customer notices: noise, a rejected part, a temperature alarm. A failure event is a specific, countable occurrence of a defined functional loss, tied to a unit, a time, and a location. The transformation from symptom to failure event is the first act of scoping, and it is almost always where ambiguity hides.

Consider a surface-mount assembly line reporting "intermittent solder defects." That phrase cannot be analyzed. Rewritten as a failure event, it becomes: a solder joint on a 0402 resistor exhibiting insufficient fillet volume, detected at the automated optical inspection (AOI) station, on board serial numbers from lot L-2231, produced between 06:00 and 14:00 on 12 March. Now the event has an object (solder joint), a defect definition (insufficient fillet volume against IPC-A-610 criteria), a detection point (AOI), and a population (lot L-2231, time window). Each of these becomes a variable in the analysis.

Three attributes must be fixed before any data collection begins:

• Functional definition of failure. What function was lost, and against which specification? "Insufficient fillet volume" is measurable; "bad joint" is not.
• Unit of analysis. Is the unit a board, a joint, a panel, a machine-hour, or a customer shipment? Mixing units mid-analysis is a common source of contradictory conclusions.
• Detection method and threshold. The same physical defect may be counted differently by AOI, X-ray, and visual inspection. The detection method defines the measurement system, and the measurement system defines the data.

Defining the Boundary

Boundaries are the constraints that make a problem tractable. An unbounded problem ("improve quality") has infinite causes; a bounded problem has a finite candidate set. Boundaries are drawn along four dimensions, and each must be stated explicitly, including the justification for exclusion.

The causal boundary deserves special attention. Holding a factor fixed removes it from the candidate cause set, which is a powerful simplification — but only if the assumption is defensible. If paste lot is fixed because all boards in the window used lot P-77, that is a legitimate constraint. If it is fixed because "paste is never the problem," that is an untested assumption masquerading as a boundary, and it can silently exclude the true cause.

Formulating Answerable Root Cause Questions

A well-formed root cause question specifies the response variable, the candidate factors, and the comparison that would distinguish them. Vague questions produce vague investigations. The table below contrasts weak and strong formulations for the same event.

Each strong question names a measurable response (fillet volume), a factor or comparison (setpoint, correlation, changeover), and a population (lot L-2231). It can be answered with data, and — critically — it can be answered wrong, which is what makes it scientific.

Structuring the Scoping Work

The diagram below shows how a raw symptom is progressively constrained into a set of answerable questions. Each stage narrows the candidate cause space; the final questions map directly onto data collection and statistical tests.

Practical Scoping in Practice

In a real investigation, scoping is iterative. A first pass produces a draft problem statement; data collection reveals that a boundary was drawn incorrectly; the statement is revised. The goal is not to get the boundary right on the first attempt but to make every boundary explicit so that revisions are deliberate rather than accidental.

A useful discipline is to write the problem statement as a single sentence with four slots: For [population], [response variable] measured by [method] differs from [reference] under [factor or condition]. Filling these slots forces the analyst to commit to a unit, a metric, a detection method, and a comparison. If any slot cannot be filled, the problem is not yet scoped.

For the SMT example, the completed sentence reads: For 0402 resistor joints in lot L-2231 (rev C boards, 12 March, 06:00–14:00), mean fillet volume measured by AOI differs from the lot baseline under reflow zone 4 setpoints of 235 °C versus 245 °C. This sentence is the contract between the problem definition phase and the data collection phase. Every subsequent measurement, every statistical test, and every conclusion must trace back to it.

The next phase — data collection and measurement system validation — depends entirely on the boundaries and questions established here. A boundary drawn too tightly excludes the true cause; a boundary drawn too loosely drowns the analysis in noise. The engineering judgment lies in finding the boundary that is narrow enough to be tractable and wide enough to contain the mechanism.