Six Sigma or Lean?

By Mike Rigg, P.E., Operations Associates

I may take a lot of heat for this, yet I’ve never been shy about calling it like I see it. Let me ask the question, “If you had to choose, would you prefer to use Six Sigma or Lean as your improvement ‘toolbox’ of choice?” When this question has come up before, I’ve heard non-confrontational replies such as, “Well, both have their purpose,” or perhaps, “For quality improvement, Six Sigma is better and for cost, use Lean.” But which one is REALLY preferred? Before I give you my answer, you should know that I’ve been doing quality consulting since 1988; I’m a certified quality engineer and Six Sigma Black Belt. You might think that would bias my opinion. Yet, the issue to me has little to do with the tools and techniques each method employs. It also has nothing to do with which company has had success using which approach (no lemmings here, please).

Yet it does have everything to do with how people solve problems. Research by Gerald Nadler and William Chandon in their book Smart Questions: Learn to Ask the Right Questions for Powerful Results indicates that the vast majority of people solve problems poorly. They then go on to discuss methods that can improve how the average person solves problems. Interestingly, a few of these principles contradict the traditional problem-solving methodology so many of us have been taught to follow.

For example, one principle, “limited data collection,” argues that we often can collect too much data on the problem, become an expert on the problem (rather than the solution), and thereby lose sight of our purpose. For example, in the DMAIC process, there is considerable time spent defining the problem, measuring the problem, and analyzing the problem. I call this a “reductionist” or “mechanistic” approach for its reliance on data collection and analysis (top process, below, and especially the first three boxes).

Lean on the other hand, offers more of a principle-based “test it, try it” approach. The methodology focuses quickly on creating solutions, testing solutions, and controlling (deploying) the solution. This inherently requires that the problem solvers rely on group knowledge of what might work and what likely won’t work. The group uses a series of small, solutions-focused trials to determine if they are right in their thinking. I call this an “organic” or “humanistic” approach since it relies on group knowledge of possible solutions without first doing a “deep dive” via data analysis on the problem (bottom process below).
I’m convinced that Nadler and Chandon are on the right track, especially when I look back over my career of working with problem solving and engineering teams since the 1980’s. Frequently I saw teams get “all bollixed up” by diving too deep into the data. Not only did this often cloud their view of the solution, but it also added lots of time to the project.

Several years ago, I was speaking with a mechanical engineer who was leaving GE due to a pending marriage and relocation. She indicated that they recently had invited a Japanese Lean Sensei to visit their plant. This Master walked through the plant, pointing out changes that they should make to increase efficiency and reduce cost. I hope you are marveling at this. I did. Here in the heart of Six Sigma-land, an individual was focusing quickly on the possible solutions with very limited data.

More recently, I was meeting with a middle manager at a large manufacturing company, pre-planning a Lean event. I told him that the Lean “Rapid Improvement” Process would take a team from start to finish, including implementing solutions and confirming results, in one week. He said, “I don’t think that’s going to work. We seem not to do anything fast here.” I said, “Yes, I understand that the typical Six Sigma project can take three months, but this will work much faster”. He said, “Three months? Our projects are taking more like nine!” Later, when the Lean team delivered $350,000 in annual overtime and materials savings after a one-week event, he became a believer.

There are secondary benefits to completing Lean events quickly, in weeks versus months. First, the team achieves more rapid cycles of learning. When a team tries new ideas in a week, they get 50 or more learning cycles each year, versus two to four. Second, the small tests of solutions, multiplied across the whole organization, pose less risk, not more, to the business. That’s interesting to me: by using small tests and less data, we just might have less project risk, faster implementations and better investment returns.

I could go on with many other examples and other discussion points. Certainly not all data collection is bad and Lean is not the right methodology in every case (e.g., basic research would be one case where data collection and analysis as a first step is important). This, and other Nadler and Chandon principles, however, should cause us to think about how we solve problems, accomplish projects and otherwise get stuff done in our companies. Lean, especially when modified with Smart Questions, is the far better method to employ as your methodology on many improvement projects.

About the Author: Mike Rigg, P.E. is Cofounder & President of Operations Associates. He has 26 years of experience in:
• Engineering project management
• Business process re-engineering
• Engineering services business management
• Manufacturing consulting
• Industrial & quality engineering
• Operations analysis & improvement
Mike is a certified Project Management Professional, Six Sigma Black Belt, and holds licenses as a registered engineer (industrial). Operations Associates is an award winning consulting firm, serving mid-size to Fortune 500 manufacturers and distributors worldwide since 1993. Operations Associates optimizes processes and systems and delivers smart manufacturing and distribution facilities to:
• Reduce capital investment
• Reduce operating costs
• Improve productivity & throughput
• Reduce inventory
• Improve service and quality levels
• Increase profits
For more information: www.OperationsAssociates.com.