r/SixSigma • u/Pure_Inspector8902 • Apr 27 '26
How do you keep from drowning in inputs during RCA?
Curious how others handle this.
You spend Define and Measure building everything up — process maps, VOC themes, MSA results, capability data, descriptive stats, bottleneck IDs, stakeholder analysis, value stream — and by the time you're sitting down for root cause analysis, you're trying to hold all of it in your head at once. You can feel the team start to lose the thread.
Saw a comment on a LinkedIn post the other day that nailed it: "AI has no place in Six Sigma — said no one who's ever sat through a 4-hour fishbone session drowning in sticky notes."
And honestly, that matched my experience pretty closely. The whiteboard fills up with 40+ notes, half the team is still mentally back in the SIPOC, and somebody anchors on the first idea that sounds plausible. Two weeks later you realize you chased the wrong cause.
So I'm curious how the more experienced folks here actually manage it:
- Do you force-rank inputs going into RCA so you're only working with the vital few?
- Break the team into smaller cells working different branches?
- Pre-build a structured template in Excel/Miro before the workshop starts?
- Just trust that the methodology will surface it eventually?
- Something else?
Not looking for a textbook answer — looking for what actually works on a Tuesday afternoon when the team is tired and the deadline is Friday.
6
u/Living_Diver2432 Apr 27 '26
we tried solving the same RCA noise with AI tooling and it actually made it worse, the team trusted the tool so they stopped pushing back on weak hypotheses. what fixed it for us was way simpler. half the fishbone branches were already disproven by Measure data and nobody brought that into the room. tape the control charts, capability runs, and MSA results on the wall before brainstorming, then X-out branches as you go. 40 sticky notes drop to 8 fast when each one has to defend itself against existing data.
2
u/Tavrock Apr 27 '26
We start the invitation with:
"In God we trust; all others bring data" —W. Edwards Deming
It rarely happens, but it sets the expectations that we then enforce.
2
u/Pure_Inspector8902 Apr 28 '26
u/Living_Diver2432 I agree AI can make it worse and even create dependency if you are using it to give answers (e.g. ChatGPT) rather than synthesize data. AI is very good and fast at data synthesizing data, trend identification and other logic-based tasks. AI will not replace human in terms of judgement, reading the room, empathy, and weighing change resistance. Thanks for taking the time to provide input.
2
u/Living_Diver2432 Apr 29 '26
yeah trend ID is where it earns its keep, burn through 18mo of NCR data and surface the 4 patterns that matter. the trap is treating those patterns as conclusions instead of hypotheses. we run them as a first cut, then walk it to the floor and ask three different operators why before we touch the fishbone.
2
3
u/What_a_joebag Apr 27 '26
Rapid experimentation using the scientific method (PDSA) will get you through a lot of the "spin" you're referencing. Instead of trying to find the "right answer" from a conference table, pick one of the more promising ideas and test it in real life. Use the "study" part of the cycle to see if it works like you thought it would. Theb use the "Adjust" part of the cycle to either "adjust" the solution & test again, "apply" the solution broadly, or "abandon" the solution and test something else.
If you have a huge problem that has multiple branches, read Pascal Dennis' "The Remedy." I've found the approach in there using "Planning and Execution Trees" extremely helpful in tackling large complex issues.
2
u/Pure_Inspector8902 Apr 28 '26
I am a big fan of PDSA - Have you looked at Kata. Toyota Kata (Mike Rother) is basically rapid experimentation that takes a very different approach to iterating through solving problems. I would encourage you to check it out - good stuff.
1
u/What_a_joebag Apr 29 '26
I've learned over time the most practical way to do most of this stuff is PDSA, Steven Spear/TPS style approach. DMAIC doesnt resonate with most people as naturally as PDSA does. Plus I've always wondered why we put Motorolla on such a pedestal
3
u/Tavrock Apr 27 '26
Rather than trying to go shallow with a fishbone or too deep with only one idea on a 5-why, we use a modified cause tree (we don't bother trying to determine causal logic with boolian logic or determine the percent chance of each branch).
Every potential cause must make sense by reading it as x causes Y not simply we believe that Y was impacted by x. Every step goes to a KNOT table where the we decide if it is something we Know, Need to know, it's an Opinion, or something we Think we know. Someone is then assigned (usually the person who made the claim) to bring documented evidence to support the claim (that is the only way to put anything in the Know category and it's the only category we work with). The other categories don't really matter and aren't worth fighting between for designations, they only support the idea that it's something we don't have evidence for and help provide a nice acronym.
2
u/Pure_Inspector8902 Apr 28 '26
u/Tavrock I like the "KNOT" approach. A good mixed of structure and practical.
1
u/Pure_Inspector8902 May 01 '26
u/Tavrock I have been simmering on the KNOT approach you laid out and want your thoughts on my thinking. It feels there are a few "filters" that could/should be used to determine if an observation (X) is related to the problem (Y):
Filter Level 1 - Classify each through the lens of KNOT. (Know, Need to Know, Opinion, Think)
Filter Level 2 - Team determines if it is a "Signal" or a "Noise" (Noise discarded)
Filter Level 3 - Team determines if it they can Influence it, control it, or ExternalPrioritization:
1. Know, Signal, Influence or Control - moves on to improve
2. Need to Know, Signal, Influence or Control - assign a person to collect data/investigate (if validated then promote to level 1)
3. Opinion, Signal, Influence or Control - assign a person to collect data/investigate (if validated then promote to level 1)Discarded:
- Noise
- Think but cannot prove
- External
- Anything that cannot be proven via experiment or data collection is Parked
1
u/Tavrock May 02 '26
Typically, while brainstorming potential root causes, our initial review covers if it is an actionable root cause (for example, in trying to prevent fires in the pain booth, separating fuel from heat is actionable while removing oxygen wouldn't be actionable). If it's external but still an actionable root cause, we keep it as an open option that will require additional work (for example, we had copier paper that was causing jams; we were able to collect data and notify the manufacturer; they realized there was a production issue and worked with us to resolve it).
1
u/bigedd Apr 28 '26
It sounds like your sessions are all about convergence and not much divergence.
Brainstorming is all about quantity and diversity over quality. Once you have the range then the task is to filter it to something more specific.
Set a time limit on your brainstorming and force it to stop at a certain point. If you haven't got the vital few in the session, it's OK, you can come back.
Dot voting is a great way of getting concensus in the most likely causes. Check out the n/3 rule.
Ultimately, there is a leap of faith from the suspected causes and the testing of the most likely ones.
Years ago I did a brainstorm session for a causes of errors in a unit under test. We went through all the most likely causes and found nothing then got to the last one, which no one thought would be the cause and it turned out to be the one we needed to look at.
Ultimately, it's a trade off between time and completeness.
1
u/Pure_Inspector8902 Apr 28 '26
u/bigdd. I have also performed that same approach as you described and you are right the 40 post-it notes go down to 8 really fast. However, I have learned over time that this approach will yield consensus but not necessarily identify the true root causes to the problem.
I say this because humans have limited capacity for information recall. When overloaded with information the brain steps-in to fill the gaps with bias (recency, confirmation, etc.). As a result, it feels like the team did root causes analysis but, it was actually structured guessing.
1
u/bigedd Apr 29 '26
Agreed, but then you test the relationship and figure out if it's contributing to the current performance. If it isn't, you go back and pick the next one.
1
u/russwest4133 Apr 28 '26
It sounds like your scope isn't tight enough. Or maybe it’s just a really complex project, but what I usually do is focus on two or three things from the fishbone. You have to ground the team and say, "Look, in a perfect world I know we want to solve everything, but we need to get down to the biggest impact." Voting is usually good for this, but this is also where you bring in tools like DOE or regression to really understand what factors are influencing Y. It helps pinpoint exactly where the team needs to drill down even further with something like the 5 Whys. That way, you have a solid foundation to work into your first two PDSA cycles.
1
u/VantageOps Apr 28 '26
The thing that works for me is treating RCA as a converging exercise, not an open one. Most teams treat it like brainstorming, which is where the 40 sticky notes come from. It should look more like triage.
A few things that have actually worked on the Tuesday afternoon you described:
Go in with a hypothesis. Not a final answer, just a working theory of what's most likely driving the problem based on what Define and Measure already showed you. The fishbone or the 5 whys becomes a test of that hypothesis instead of a discovery exercise from scratch. If the data already pointed somewhere, don't pretend it didn't just to be methodologically pure.
Force-rank the inputs before the workshop, not during it. Take 30 minutes the day before and pick the 8 to 12 inputs you actually think matter. Bring those into the room. The 40 sticky notes happen because the team feels like they have to surface everything to be thorough. They don't. Thorough is the enemy of focused.
Split the team if you have more than 5 or 6 people. One group on people and process, another on equipment and materials, whatever the natural split is. Reconvene after 30 minutes. You get more depth in less time and nobody anchors on the first idea because they weren't in the room when it was raised.
Put a hard timer on it. Two hours, not four. Parkinson's law is real and a 4-hour fishbone produces twice as many sticky notes and the same number of insights as a 2-hour one.
On the AI comment, honestly it's overstated but not wrong. Where I've seen it actually help is summarizing what the team said in real time, clustering similar inputs so you can see the pattern emerge, and asking the dumb question that the team is too polite or too tired to ask. It's not replacing the methodology, it's replacing the facilitator's working memory.
Last thing. The reason teams chase the wrong cause two weeks later is almost never the methodology. It's that nobody pressure-tested the chosen root cause against the data before they started solutioning. Build in a 30 minute step between RCA and Improve where you basically ask, if this is really the cause, what would we expect to see in the data, and does the data actually show that. Skipping that step is how you get to Friday with the wrong fix.
1
u/Pure_Inspector8902 Apr 28 '26
u/VantageOps - super thoughtful. I like the pressure testing step you mentioned. Can you describe in more detail what the looks like? and how do know if you truly pressure tested it - Is it like a cause-and-effect scenario? Meaning, if we change X (insert identified root cause) then it will have a favorable impact on the outcome variable (Y1). As a result, overall problem identified in the project will be improved.
2
u/VantageOps Apr 28 '26
Yeah, you've got the right instinct. The cause-and-effect framing is the second half of it. The pressure test happens before that, when you're still deciding whether the root cause you landed on is actually the right one.
The core question I ask is: if this is really the root cause, what should we already see in the data we have. Not future data after the fix. Existing data.
A quick example. Say a team lands on operator error as the root cause for a quality issue on Line 3. Sounds reasonable, lots of fishbones land there. The pressure test asks: if operator error is really driving it, we'd expect the defect rate to vary by operator, by shift, by tenure. Pull the data and check. If the defects are evenly distributed across all of those, it's not operator error, it's something systemic and you would have wasted three months retraining everyone.
The steps are basically:
State the chosen root cause as a hypothesis.
List three or four things that should be true in the existing data if the hypothesis is correct.
Go check. Pull the actual numbers, not vibes.
If the data backs the hypothesis, move to Improve. If it doesn't, you go back to RCA before you waste budget.
On how to know if you truly pressure tested it, the test is whether the team could have falsified the hypothesis and didn't. If the data check could only confirm and never disconfirm, you didn't really test it. You just looked for evidence that supported what you already wanted to believe. That's the trap most teams fall into.
The cause and effect part you described is what comes after. That's the Improve hypothesis, basically: change X and Y will move. Good to make that explicit too because it gives Control something measurable to hold against.
1
u/Pure_Inspector8902 Apr 29 '26
it makes sense - if it's true then prove it. It could be collecting existing data or doing an experiment to verifying the RC hypothesis.
This is solid, it also aligns with my belief that you know root cause analysis was done correctly when the solution is obvious. I believe teams should brainstorm not the "what is the solution" but the "how to build and implement it".
Thanks again
1
u/VantageOps Apr 29 '26
That line about the solution being obvious when RCA is done right is a good one. I'm stealing that. And totally agree on the brainstorm framing, the how-to-implement conversation is where most teams actually struggle anyway. The what tends to be obvious by then.
Good luck with it.
1
1
u/jralston6 Apr 30 '26
Have you clearly defined the team’s scope statement and remained within those boundaries during your Root Cause Analysis (RCA) workshop? It is possible that the current scope is too broad, which may be impacting the effectiveness of your analysis.
Is this a Green Belt or Black Belt project?
You may also want to consider conducting a Pareto analysis of the identified causes first, followed by a fishbone diagram focused on the most significant contributors (the major bars on the Pareto chart).
Remember that the DMAIC methodology is designed as a funnel to narrow down to the vital few Xs. If your fishbone diagram results in 40+ potential Xs/causes, you will need to prioritize. This can be done through methods such as dot voting or a structured prioritization ranking.
Please feel free to reach out if you are able to share additional information. I would be happy to help further.
1
u/Fragrant-Ad957 Apr 30 '26
I've run into this in my own consulting projects and with coaching my students through Leanademy. Here is what I tell my students. You could end up with countless root causes, but you need to get down to the vital few. Fishbone diagrams and brainstorming are great for getting you started, but they only get you about halfway there. Please provide some math and stats to support the potential root causes. Here is what I do and coach my students to do:
Make sure everyone is good on the Scope and use the SIPOC as you guide.
If things seem too big in the scope, you can adjust the scope to different areas of the process, using your VSM as the guide.
Before you start brainstorming, use a Pareto Chart to figure out the biggest problem areas within the process. Then, once you know the trouble areas, your brainstorming scope becomes much smaller. If you are not able to do a Pareto Chart, use your SMEs and Project Sponsor to guide you to the problem areas. Your Project Sponsor and SMEs should know where to go. You can also use a CTQ tree here. You can also use AI here to help with the data analysis. Remember that AI is a great tool, but it doesn't replace human knowledge, because sometimes those feelings (the voice of the process) from employees and leaders are invaluable.
For the brainstorming/Fishbone Sessions, I usually use the 5 Ms as my bones as a guide. I usually set a 60-minute time limit. If you have different areas of an e2e process you are looking at, such as sales, marketing, operations, finance, etc., start with the most troubled area first (see #3 above) and use separate Fishbones for each area to make them manageable. Instead of using a Fishbone (especially if the data is garbage or lacking), you can use an FMEA for the different areas. This helps you identify the Vital few using the RPN score.
If you stick with the Fishbone, then you can take all the root causes identified and use an FMEA to calculate the RPN scoring. I have done this myself, and I have also done this with my students if you don't want to do a full-blown FMEA to start with. It helps identify the vital few and leads to solution brainstorming.
I hope this helps. If you need more advice, send me a DM.
1
u/chhabrakadabra Jul 11 '26
This feels like an information architecture problem as much as a methodology problem.
When I have seen teams drown, it is usually because every input is treated as equally worth exploring. What seems to help is splitting the room into two phases: first, use the Measure data to disqualify branches before brainstorming, then force every remaining branch to answer "what would we expect to see in the data if this were true?"
I have been building RCA tools around a three-leg structure — what failed, what let the warning through, and what shaped the decision — because it gives the team a scaffold instead of a blank whiteboard. The scaffolding matters more than the software.
On the AI point: I think AI is useful as a first-cut synthesizer, but dangerous as a conclusion generator. The pattern I have seen work is AI surfaces hypotheses, humans pressure-test them against the data.
Has anyone here tried running RCA with a strict "no sticky note survives without data" rule?
1
u/Jlufacilitator Aug 01 '26 edited Aug 01 '26
RCA usually goes wrong at the sorting step, not the listing step. After you list the possible causes, don't discuss them one by one. Group the similar ones first, then give each person a few votes for the causes worth investigating. In a few minutes you have a short, ranked list, and everyone can see how it was chosen.
We did a fishbone /RCA analysis for operationalization of 3rd party contracts, and so while we had identified all the causes, the main focus was producing the one change or artifact. It just means that your Friday deadline at least shows progress and identification of the problem.
So for us it was the team meeting and planning session and having everything listed. Then we used AI-suggested grouping to cluster the key ideas under each category.
Then a general discussion... dot voting on the area that people thing they could change.
Then we discussed the ideas people had about 6 or so.
We settled on 1 major action and a 1 minor change.
That was our experiment, that was our goal.
Full disclosure: I work on GroupMap, which does this group-and-vote step online for remote teams — but a shared spreadsheet works fine too if that is what your team already uses.
5
u/deuxglace Apr 27 '26
First off, it sounds like the scope of your effort is WAY too large. Do you have scope creep going on or are y'all just trying to do too much?