> **TL;DR**: When you already 'know' the root cause, your brain will find data to confirm it and ignore data that contradicts it — the best 8D investigators hunt for disconfirming evidence, not supporting evidence.
Have you noticed a really interesting pattern? On day one of an 8D, everyone already knows what the root cause is. Then everything from D2 to D4 is just a ritual — not to find the truth, but to build a case for the conclusion that was already decided. This isn't analysis. This is shooting the arrow first and drawing the target around where it landed. We just package it professionally — fishbone diagram, 5-Why, statistical tools — but underneath it's all about legitimizing a predetermined position.
I did this too when I was younger. It embarrasses me now. The customer said "it must be a material issue," so I dove into the incoming inspection reports. After digging through three months of data, I finally found one batch where a parameter was off by 0.1%. I grabbed it like a treasure and declared in D4: "Material batch anomaly caused the failure." Customer was satisfied, supplier got penalized, case closed. Everyone happy. But over a year later I accidentally discovered that parameter shift had zero causal relationship with the failure mode. The 0.1% deviation was well within spec. And that batch ran through an entire year without a second incident. The real cause was probably a worn-out bearing in the equipment that had been degrading for years, creating intermittent vibration spikes at certain temperature ranges. But nobody checked. The customer didn't ask, I didn't think to look, and everyone agreed "supplier paid the penalty, problem solved." I delivered the answer the customer wanted to see, not the real answer. I still feel like I owe that supplier an apology.
Here's the classic scene: one morning the line suddenly has a massive yield drop. The engineering manager slams the table and announces "I told you that new supplier was no good." Now everyone has a clear mission — find evidence that proves the supplier is the problem. The QE goes through incoming inspection reports, IQC re-samples the batch, purchasing is called into a meeting. The whole room has this energy of "we cracked the case." You even find a report showing one dimension was slightly out of tolerance — even though the deviation didn't affect assembly at all, at least you have something to write about. You craft a compelling D4, draw a beautiful fishbone, execute a textbook 5-Why. The customer gives you a thumbs up and says your team is very professional. But the truth? I spent two weeks observing on the floor and found the injection molder's temperature control module was failing intermittently — the temperature would drop twelve degrees every shift change, then recover, right in the window when those parts were being molded. But nobody wanted to investigate the machine because that means shutting down production, writing a maintenance request, getting a CAPEX approved, losing three days of output. Blaming the supplier was the path of least resistance — lowest cost, shortest process, easiest for the customer to accept. So everyone quietly chose the "safe answer." Nobody objected, because the person who objects is the one who has to find the real root cause. This is confirmation bias at its most textbook — you don't want the truth, you want an explanation that can be accepted and closed quickly. After this pattern repeats a hundred times, it becomes the company's "standard operating procedure." Nobody thinks it's a problem anymore.
Here's what's really scary. After this "shoot first, draw later" model runs for a few years, the entire quality management system slowly turns into a self-fulfilling prophecy. Your detection system only finds problems in the direction you're already looking — because that's the only direction you ever look, and your detection tools are only set up in that direction. The real systemic defects — the ones hiding deep in the process, in aging equipment, in management blind spots — escape again and again. Because nobody looks for them, they simply "don't exist" in your 8D database. But not existing doesn't mean they're not happening. It just means you're pretending they're not. A root cause analysis process that never questions itself isn't a problem-solving system. It's a precision illusion machine — it doesn't produce solutions, it produces legitimacy for your biases.
What if there was a system that, before you write down "root cause might be X," forces you to list evidence both FOR and AGAINST X side by side? What if it could tell you, based on full data: "You mentioned this parameter shifted by 0.1%, but in the last twelve months it only happened once and there's no correlation with the failure time window. However, the bearing wear curve on this machine has been approaching the maintenance threshold. Want to check that side first?" It doesn't make the decision for you. It just stress-tests your logic before you commit to a conclusion. You say the root cause is this? Then explain why the data doesn't support you. If you can't explain it, maybe hold off on that conclusion. 8D Wiki (8d.wiki) believes something very simple: the most dangerous bias in quality management isn't that you don't know — it's that you think you know too soon. Its purpose isn't to save you time. It's to slow you down. Before you lock in that beautiful D4, ask yourself one more time: did I find this conclusion, or did I just selectively see the world I wanted to see?
The truth is almost never the most "convenient" answer. It's the uncomfortable one. What's the most "shoot first, draw later" 8D you've ever done? What turned out to be the real root cause that you missed? Sometimes admitting you were looking in the wrong direction takes more courage than finding the right answer in the first place.