A Part Keeps Failing and Everyone Has a Different Theory. How Do I Run a Root Cause Analysis That Actually Sticks?

The same bracket cracked again. Or the same fixture keeps drifting out of position, or the same customer complaint showed up for the third time this quarter. Maintenance blames the operator, the operator blames the material, purchasing blames the supplier, and the supervisor just wants it gone by Friday. Everybody has a theory, and nobody has written anything down. That is exactly when a short, structured root cause analysis earns its keep.

A part keeps failing and everyone has a different theory. How do I run a root cause analysis that actually sticks?

Freeze the facts first, pick one method that fits the problem, test each candidate cause against those facts, and only then write a corrective action with an owner and a check date. Most root cause efforts fail because they skip straight to the fix. Someone with authority picks the most likely story, a change goes in, and three weeks later the failure comes back with a new excuse attached.

The order matters more than the paperwork. Facts, then method, then cause, then action, then verification. If a meeting jumps a step, send it back.

How do I write the problem statement before anyone guesses a cause?

Describe what failed, where, when, how often, and how you know, then list what is not failing under similar conditions. That second half is the part people skip. An Is/Is-Not comparison asks simple questions. Which part numbers fail, and which similar ones do not? Which shift, machine, lot, or customer shows the problem, and which ones never do? When did it start, and what was true before that date?

Those contrasts do a lot of the thinking for you. If the cracked bracket only shows up from one machine, a raw material theory gets weaker. If it started the week a new supplier lot arrived, an operator theory gets weaker. Avoid cause words in it. "Bracket cracks at the mounting hole after assembly" is a problem statement. "Operator overtightens bracket" is a guess wearing a problem statement costume.

Should I use 5 Whys or a fishbone diagram for my problem?

Use 5 Whys when the failure follows one fairly linear chain, and use a fishbone diagram when several factors could be contributing and you need to sort them before testing.

• 5 Whys works well for a single event with a traceable sequence. Ask why the failure happened, then ask why that answer happened, and keep going until you reach something you can actually change in a process, a standard, or a check. Five is a guide, not a rule. Stop when the next "why" leaves your control.
• Fishbone diagram (also called an Ishikawa diagram) works when the team is throwing out many possible causes at once. Put the problem statement at the head and sort ideas into categories such as methods, machines, materials, measurement, people, and environment. The goal is to capture every candidate so you can test them, not to vote on a winner.
• Is/Is-Not sits underneath both. It is the fact base you check every candidate cause against.

A common trap with 5 Whys is a chain that ends at a person: "because Sam forgot." That is rarely a root cause. Ask one more question. Why was it possible to forget? Was there no checklist, no fixture stop, no torque spec on the traveler? Process answers are the ones you can fix permanently.

Want the complete system? A method picker, a 5 Whys template, a fishbone diagram template, an Is/Is-Not worksheet, a CAPA Lite form and log, a fictional shop worked example, and a no macro Excel workbook are all in the Root Cause Analysis Toolkit (5 Whys + Fishbone + CAPA Lite). → Get the Root Cause Analysis Toolkit ($32)

How do I know which candidate cause is the real one?

Check every candidate against your Is/Is-Not facts, and treat a cause as confirmed only when it explains both where the problem shows up and where it does not. If a theory explains the failures but also predicts failures you are not seeing, it is incomplete. Cross it out or mark it for a test.

Where you can, test before you commit. Swap the suspect lot, run the same job on the other machine, or measure the dimension you think is drifting. Write the result next to the candidate. A cause with evidence beside it is far easier to defend in the next meeting than a cause with a job title beside it.

How do I make sure the fix actually worked?

Write the corrective action with an owner, a due date, and a specific effectiveness check, then go back on that date and look. This is the CAPA step, short for corrective and preventive action. In a small shop it does not need to be complicated. It needs to exist on paper and get reviewed.

• Corrective: what you changed to stop this failure from recurring.
• Preventive: where else the same weakness could bite, such as sister part numbers, other machines, or other shifts.
• Effectiveness check: the evidence you will look for and the date you will look for it.

Keep a simple log so open actions do not quietly die. If the fix changes a drawing, a work instruction, a supplier, or a spec, route it through a proper change request so everyone works from the same revision. The Change Control Pack ($29) covers that request form, log, and impact sheet if your shop does not have one yet.

What if the root cause is a part I can no longer buy?

If the analysis lands on a worn, obsolete, or poorly fitting part with no drawing and no supplier, the corrective action may be to capture its geometry and make a replacement. DC Additive Pros offers 3D scanning, reverse engineering, and parts printing for that situation, so you can request a quote with the part details and your intended use. Record the replacement in your CAPA log like any other change, and keep the effectiveness check.

Want the full toolkit for running a root cause analysis on paper?

If you want printable sheets and an editable workbook that walk your team from problem statement to verified corrective action, get the Root Cause Analysis Toolkit (5 Whys + Fishbone + CAPA Lite). It is an instant digital download from DC Additive Pros with US Letter PDFs and a no macro XLSX workbook. Problem solving and documentation tools only. Not incident investigation procedure, legal advice, or certification advice. Customize it with your quality system owner before use.

→ Get the Root Cause Analysis Toolkit ($32)

Frequently asked questions

What is the first step in a root cause analysis?
Write a factual problem statement before anyone names a cause: what failed, where, when, how often, and what is not failing under similar conditions. An Is/Is-Not worksheet keeps that step honest.

Should I use 5 Whys or a fishbone diagram?
Use 5 Whys for a single, fairly linear failure with one clear chain of events. Use a fishbone diagram when several factors could be involved and the team needs to sort possible causes by category before testing them.

What does CAPA mean in a small shop?
CAPA stands for corrective and preventive action. In plain terms, it is a written record of what you changed, who owns it, when it is due, and how you will check that the problem actually stopped.

Is the Root Cause Analysis Toolkit a certification or compliance product?
No. It is a set of printable and editable problem solving templates. It is not incident investigation procedure, legal advice, or ISO, FDA, or OSHA certification advice. Customize it with your quality system owner before use.