Home » Lean Six Sigma Articles » Lean Six Sigma Tar Pits

Lean Six Sigma Tar Pits

Last week I facilitated a team that had been in existence for six months. All they had to show for their time was a flowchart of a process that was mainly rework. I'd been calling every few days for weeks nagging the team for data about how the process performs. I got part of the data the night before the meeting and the rest of the data by lunch. But after a morning of trying to sort through the issues surrounding the process, the team had fallen into "storming" about the whole process. They were frustrated and so was I.

Pitfall #1: Starting a team when you have no data (line graph and pareto chart minimum) that indicates you have a problem that can be solved using Six Sigma. Without data to guide you, you don't know who should be on the team, so you end up with different groups trying to solve different problems.
Solution: Set the team up for success. 1) Work with data you already have; don't start a team to collect a bunch of new data. 2) Refine your problem before you let a group of people get in a room to analyze root causes. You can guarantee a team's success by laser focusing the problem to be solved.

Pitfall #2: Questionable data. To throw a team off its tracks, some member who doesn't like the implications of the data will state in a congruent voice that the data is clearly wrong. If you let it, this will derail the team into further data analysis. I know from experience that all data is imperfect. It has been systematically distorted to make the key players look good and manipulate the reward system, but it is the "systematic" distortion that allows you to use the data anyway.
Solution: Recognize that this member is operating on gut feel, not data. Simply ask: "Okay, do you have better data? (They don't.) Then how do you know the data's invalid? (I just know.) How do you know? (Instinct, gut feel.) Well, unless you have better data that proves this is invalid, we're going to continue using this data. You're welcome to go get your data, but meanwhile, we're moving forward." If the person is unwilling to continue, you can excuse them from the team because they will continue to sabotage the progress.

Pitfall #3: Whalebone diagrams. When searching for root causes, if your fishbone diagram turns into a "whalebone" diagram that covers several walls, then your original problem statement was too big.
Solution: Go back to your pareto chart. Take the biggest bar down a level to get more specific. Then go back to root cause analysis.

Pitfall #4: Boiling the ocean. Teams have an unflinching urge to fix big problems. If you've done a good job of laser focusing your problem, you'll have a specific type of defect in a specific area to focus on. If you let the team expand its focus, you'll end up whalebone diagramming and have to go back to a specific problem.
Solution: Get the team to agree to solve just this one issue, because its solution will probably improve several other elements of the overall problem. Assure them that you'll come back to the other pieces of the problem, but first you have to nail this one down.

There are many other pitfalls, but these are some of the biggest ones I've encountered.