🎯 Quick Answer

What: Cause and effect analysis is the step that comes before root cause analysis. You list every plausible cause of a problem, systematically, before narrowing to the ones worth investigating. The fishbone diagram is the standard way to structure that list.

Why it matters: Every downstream step, the data you pull, the tests you run, the fix you fund, can only ever choose from the causes somebody wrote down. A cause that never makes the list cannot be investigated, ruled out, or found.

How to apply: Sweep the process by category rather than from memory: methods, machines, materials, manpower, measurement, and the environment it runs in. Write causes, not fixes. Keep the unlikely ones. Then classify what you have into constant by design, noise you plan around, and worth investigating.

The payoff: A short list you can defend, because it came out of a long one. You spend your analysis effort on candidates that were chosen, not on the ones that happened to be mentioned first.

Most cause analysis fails in the first ten minutes, before anyone has looked at a single piece of evidence.

It fails quietly. A team sits down to work out why something keeps going wrong. Someone offers a likely cause. Someone else agrees. And within a few minutes the conversation has stopped being about what could be causing this and become about how to prove the thing that was said first. The list of possible causes never got made. It got skipped, because one plausible answer arrived early and felt like enough.

I have sat in that meeting in three industries that have never once compared notes, and it looks identical every time. Nobody is careless. The room is full of people who know the work. What is missing is not effort or expertise. It is a few unhurried minutes spent listing things that might be true, before anyone starts arguing about what is.

The list is the analysis

Here is the uncomfortable part. Everything that happens after the list is constrained by the list.

The data you go and pull is chosen to test a cause on it. The experiment you design is designed against a cause on it. The money you eventually spend is spent on a cause on it. A cause that never got written down is not competing with the others and losing. It is not in the race at all. It simply stays in the process, quietly doing what it does, while an increasingly sophisticated analysis is run on the wrong candidates.

This is why a team can do everything downstream correctly and still not solve the problem. Rigor applied to a short list is still a guess. It is just a well documented one.

Why cause lists come out short

Five habits shorten a list, and all five feel like good practice at the time.

We list from memory instead of from the process. Memory returns what happened recently and what happened loudly. It does not return the quiet condition that has been true for two years.

We write fixes instead of causes. "Add a second check" sounds like an answer, but it is a solution standing in for a cause nobody has named. The cause underneath it might be that nothing in the process catches a particular error, which is a very different thing to investigate.

We drop the unlikely ones. Unlikely is a judgment made before the evidence, by the same people who are already anchored on the first explanation. Crossing a cause off because it does not feel right is exactly how the real one hides.

We only list what we can measure. Causes with data behind them are easier to discuss, so they dominate. The handoff between two teams that no report spans, the decision made verbally every Tuesday, the step only one person knows how to do properly: nothing measures them, so nothing implicates them.

We mark everything as worth investigating. This is the opposite failure and it arrives at the same place. If every cause is a suspect, nothing has been filtered, and the team is back to picking by instinct.

The sweep that fixes it

The fishbone diagram, sometimes called an Ishikawa or cause and effect diagram, exists to make the list wide on purpose. The problem statement goes at the head. Six bones come off the spine, and each one is a category you are obliged to consider whether or not anyone in the room thought of it:

The structure is not decoration. Its whole value is that it makes the silence visible. When a bone has one lonely twig on it, the team has not proven that category is fine. It has proven nobody has thought about it yet.

Then, and only then, narrow

A wide list is not the deliverable. A defensible short list is.

Once the causes are down, classify each one. Some are constant by design: they are the way the process is meant to run and should be held steady rather than changed. Some are genuine variation you cannot remove and plan around instead. The rest are the ones worth testing, and those are the ones that carry forward into a Pareto, a root cause chain, or a hypothesis test where evidence decides.

The discipline in this step is restraint. If most of the list gets marked worth investigating, the classification has done nothing. Marking some causes as constant or as noise is what gives the remaining ones their meaning.

And when you do retire a cause, retire it honestly. Ruling a cause out is a decision that deserves the same standard as ruling one in. If you cannot say what evidence retired it, it is not retired. It is just unpopular, and it will still be sitting on the original list with a line through it weeks later, when everything likely has been fixed and the problem is quietly still there.

I write more field notes like this, and share the tools I build, in my newsletter.

Frequently asked questions

What is the difference between a fishbone diagram and root cause analysis?

A fishbone is the breadth step and root cause analysis is the depth step. The fishbone lists every plausible cause across six categories so nothing is missed; root cause analysis, often run as a five whys, takes a prioritized cause from that list and traces it down to something you can change.

How many causes should a fishbone have?

There is no target number, but a fishbone with only three or four causes almost always means the sweep was skipped rather than that the process is simple. A realistic one for a real operational problem often runs to fifteen or twenty candidates before classification.

What are the six M's in a fishbone diagram?

Methods, machines, materials, manpower, measurement, and Mother Nature (the environment). Some teams use a shorter or industry-specific set, and that is fine. The point of the categories is coverage, so use whichever set forces your team to consider ground it would otherwise skip.

Should we put solutions on the fishbone?

No. Every entry should be a condition that exists in the process today, phrased so that somebody could go and verify it. If an entry starts with a verb like "add," "implement," or "train," it is a fix, and the cause it is standing in for still needs to be named.

How do we decide which causes to investigate?

Classify each cause as constant by design, as noise you plan around, or as worth investigating, then test only the last group. Resist marking most of the list as worth investigating, because a list where everything is a suspect has not been filtered at all.