SiliciumHex FieldKit

Problem Solving & Quality · Root Causes

Change Analysis

List every difference between the problem case and a comparable good case, then every change around the date it started. Causes hide in changes.

  • Time45 min
  • FormatSmall group
  • StageRoot Causes

Change Analysis: what it is and why it works

Change analysis compares the problem situation with a similar situation that has no problem and lists every difference between them: equipment, materials, people, methods, settings and environment. It then lists every change that occurred around the date the problem started, such as maintenance, a new supplier, a recipe or software update, staffing or weather. Each difference and change is tested against two questions: could it produce the observed effect, and does it also explain why the comparison case is unaffected? The surviving candidates are ranked and the most likely one is verified first.

The logic is simple: a process that ran well for years and then suddenly did not has changed somewhere. Searching changes is far more efficient than brainstorming every possible cause, and records such as change logs, purchase history, work orders and software versions often name the cause before anyone has a theory. The method naturally continues Is / Is-Not, turning its distinctions into specific changes, and draws on the event timeline, which shows what changed just before an incident. It is less useful for chronic problems with no clear start date, where stratification or designed experiments serve better. Any candidate it produces still needs on/off cause verification before a fix is launched.

What you need

  • A clear problem description with a start date
  • A comparable good case: another line, period, site or product
  • Change records: MOC, work orders, software versions, recipes
  • Purchasing and receiving records for materials and spares
  • Staffing, shift and schedule changes

What you get

  • A side-by-side list of differences between the problem case and the good case
  • A dated list of changes around the start of the problem
  • A ranked list of candidate causes that explain both sides
  • A verification plan for the top candidates

When to use it

When a process ran well for years and suddenly did not.

How to do it, step by step

  1. Describe the problem situation and a comparable situation without the problem, side by side.
  2. List every difference between them: equipment, materials, people, methods, settings, environment.
  3. List every change that occurred around the start date: maintenance, supplier, recipe, software, staffing, weather.
  4. For each difference or change, ask whether it could produce the observed effect — and explain the IS NOT side too.
  5. Rank the surviving candidates and verify the most likely first.

Worked example: Powder-coat adhesion failures on one line

Illustrative scenario — figures are realistic but not from a real company.

A metal-finishing shop powder-coats steel brackets for HVAC equipment. For years, cross-hatch adhesion tests passed routinely. Since mid-September, about 12% of parts from line A fail, while line B, coating similar parts with the same powder, has no failures.

  1. Comparison cases: line A since mid-September versus line B over the same period, and versus line A before September.
  2. Differences between the lines: line A uses a five-stage washer with iron phosphate pretreatment, line B a zirconium-based pretreatment. The powder, the cure profile and the steel supplier are the same.
  3. Changes on line A around the start date: the stage-3 heater was replaced on September 8; the final rinse was connected to a new water supply on September 12; a new second-shift lead started the same month.
  4. Testing the candidates: the new lead could not explain failures on both shifts; the heater mattered only if bath temperature was wrong, and logs showed it in range. The rinse-water change fit both sides: it affected only line A and started in the right week.
  5. Verification: final-rinse conductivity records before and after September 12 were compared, and parts were run with the old and new rinse supply.

Result. Final-rinse conductivity had risen from under 50 to about 400 µS/cm, because the new supply was untreated plant water instead of deionized water. Reconnecting the deionized supply and adding a conductivity alarm brought adhesion failures to zero the following month. The maintenance and purchase records had pointed to the change long before a brainstorm would have reached it.

Open it in the FieldKit Problem Solving app → Get the Problem Solving template pack — join the waitlist

Common pitfalls and how to avoid them

  • Choosing a poor comparison case.Pick a case as similar as possible, such as a twin line or the same product in an earlier period, so differences are few and meaningful.
  • Listing only formal, documented changes.Include informal ones as well: new staff, workarounds, weather, supplier lot changes and software updates that bypassed MOC.
  • Keeping candidates that explain only one side.Each candidate must explain why the problem appears where it does and not in the comparison case.
  • Stopping at the first plausible change.Rank all surviving candidates and verify them; two changes close to the same date are common.

Frequently asked questions

What is change analysis in root cause analysis?

Change analysis is a technique that looks for the cause of a problem among the differences between the problem situation and a comparable good situation, and among the changes that occurred around the time the problem started. It rests on a simple principle: a stable process that suddenly goes wrong has been changed in some way, whether or not the change was recorded.

How is change analysis related to Is / Is-Not?

Is / Is-Not identifies what is distinctive about the what, where, when and extent of a problem, compared with where it could be but is not. Change analysis takes those distinctions and asks what changed in or around them. Kepner–Tregoe problem analysis uses the two in sequence: specify the problem, then look for distinctions and changes to generate testable causes.

What if nothing seems to have changed?

Something almost always did, but some changes are never recorded: wear, gradual drift, supplier lot variation, seasonal conditions, or changes in people and habits. Extend the search to slow changes and to inputs you do not control. If the problem has existed from the start, change analysis is the wrong tool; use stratification, a fishbone diagram or designed experiments instead.

Origin

Change analysis — Kepner–Tregoe problem analysis (1965); also used in MORT accident investigation.

Related methods

More in “Root Causes”

List the possible causes, dig down the chains and prove the real one before acting.