Benjamin Franklin

Does Six Sigma = Continuous Improvement?

Created on 2018-01-06 20:30

Published on 2018-01-06 22:17

When we started our Six Sigma program in 2000, it was all about solving tactical problems to improve quality and ultimately save money. We selected our best people and spent lots of money to train them in sophisticated problem-solving tools, software, and methodologies. I took the training and then led a group of 15 Black Belts and 1 Master Black Belt charged with improving the engineering department of 1,500 people. Unfortunately, our biggest problem was a lack of clear problems. We certainly had no clue where to find the biggest opportunities. The bottom of the iceberg was completely unknown. Read "True" Key Performance Indicators vs metrics for more on this

Hard vs Soft Savings

Our President was sold on Six Sigma by the promise of 100’s of millions of dollars in additional profit. By improving quality, we would eliminate waste and increase profits and shareholder value.  Our leadership wanted to ensure this, so financial approvals were required at the beginning, middle and end of each project to prove the financial results were hitting our bottom line. The controllers were nervous about this and needed clear rules to make these decisions, so we created detailed definitions to identify Hard vs Soft Savings. Basically, Hard savings had to show elimination of a waste that existed today, not in the future. Labor savings had to result in people leaving the company, or being re-assigned to other duties. Avoiding future costs or reducing resource needs in fractions of people were considered Soft Savings. In the beginning, Soft Savings were valued and accounted for, but eventually, they were considered less valuable and we stopped reporting them altogether.

In operations, this was relatively simple to apply. Your production machine is producing 5% bad parts before the improvement project and 3% afterwards. You can count the savings like counting coins. This might be simple, but it discourages a focus on future waste. In fact, if you prevent a $1M waste, it will be viewed as Soft Savings and no one cares. If you wait for the waste to happen on the shop floor, then you get credit for Hard Savings. It created perverse situations, where Black Belts would work on today’s small issues and ignore (or even encourage) tomorrow’s issues. This ensured a steady supply of Hard Savings.

Normally, plants cannot change product designs and have limited ability to make large process changes without re-validation, which can be costly and time-consuming. It’s much easier to focus on defect creation/resolution, but this narrows the scope of opportunities and soon they are working on lots of small projects of low value.  

In Engineering, this led to some interesting situations, where defects occurred in data, not parts. Defects could often be hidden or appear later in a less visible way. For example, a drawing defect should result in an Engineering Change, but EC’s may include defect repairs and other design improvements. A drawing defect may not appear until later in production. It’s not always clear if the drawing or the production process is at fault, and if we assign blame for every problem, then it becomes difficult to work together to solve problems. 

Also, in Engineering, the biggest savings will occur on future projects and products. If we improve our product development process, it has little impact on projects already in progress, but the next wave of projects will get the full effect. If we develop a better product that produces less waste, then it’s considered Soft Savings because we avoided a future cost. 

In Engineering, most of the spend and therefore the biggest savings opportunities were in Labor. Engineering work consisted of a portfolio of projects that added value to the organization in terms of new or improved products or services. Most often, the flow of projects was limited by the number of engineers. If we had more engineers (or used them more efficiently), then we could provide more value to the company. However, if we apply Hard Savings rules to Six Sigma projects, then we will reduce headcount and the stream of projects. This created general resistance to Hard Savings in engineering. This contributed to the view that Six Sigma could not be applied to transactional functions.

Imagine you are playing your favorite sport, but the rules say the referees now must pay a penalty every time a team scores. There would be endless instant replay reviews while players, coaches, and fans forget why they came. My financial controller was responsible for approving my Six Sigma teams' Hard Savings. We had a very big project with an agreed Hard Savings of $1million. At the half-way financial review, the project was unchanged, but the controller was nervous about the cut to his budget, so he decided only half of the savings were Hard. The coach (me) appealed this decision, but lost. At the final review, the project was unchanged, but the controller decided it was now all Soft Savings, and Hard Savings was $0. You can bet I appealed this like any coach outraged by a bad call. It didn't matter. The project was a 'failure'.

Missed Opportunities

Incremental improvements can be counted as Hard Savings, but they are usually small. The biggest opportunities to improve plant run-rate is with a new product or process. Imagine trying to engage the plant in improving the design for a new product. Their Black Belts are too busy with today’s problems to prevent tomorrow’s problems. We wait for the new product to cause problems, blame Engineering, then fix the problem as best we can, then claim Hard Savings. The overall scrap rate stayed the same year-over-year AND we achieved the goal for Hard Savings?? 

The scoring method in place would never show the missed opportunity to make the new product much higher quality. Hard Savings goals were getting in the way of improving in the long-term.

Problem-solving vs Best Practices

When you get a new hammer, all problems become nails. We can wait for problems to occur, so it’s ‘real’, then react with problem-solving tools to fix them. This can be satisfying and provide benefits. But are we improving continuously? Six Sigma alone does not address this. It does a good job of solving problems and keeping them from occurring for the short term, but it does not help us to prevent costly problems, nor does it create long-term improvement on by itself. 

We can shortcut the whole problem-solving step if we seek out best performers and their best practices. They already solved the problem and proved the solutions work!

Continuous Improvement

In 2006, we started a more strategic process called Best Business Practices (i.e. Continuous Improvement) that drove more engineering savings and improvements than we ever imagined. And it all started with carefully defining and implementing true Key Performance Indicators. This allowed us to set benchmarks, identify opportunities, and measure continuous improvement. 

In “True” Key Performance Indicators vs metrics, I showed how Continuous Improvement works so much better when we can clearly see our starting point, our progress, and the remaining opportunity. Using true KPIs over the long term enables a Continuous Improvement process to start AND continue over time. The diagram below shows how the process starts and ends with KPIs (aka BBP Metrics). True KPIs enable Gap Analysis where we compare best-in-class performers with our overall average. Benchmarking events are held to share best practices. Continuous Improvement projects track the implementation through management reviews and the executive change process. The benchmark is reset every year and the process starts over again.

The chart below shows how the same KPI can show continuous improvement that occured with several cycles of the process above. This chart is impossible if the metrics change constantly.


I love Six Sigma and have used the tools for almost 2 decades. However, in my experience, a Six Sigma program alone can be skewed toward short-term financial gains and not improve performance over the long term. We need a clear view of performance and best practices in order to continuously improve.

Please connect with me if you'd like more information at:

Go to the top of the page to Share, Comment, or Like if you found this interesting.

The series continues...

This is part of a series of articles about applying continuous improvement processes to measure and improve the performance of product development projects. Here is the complete list in recommended reading order.

  1. Are you still "negotiating" your project budgets? is a true story about a journey from budget hell to using EQUs to accurately estimate costs of engineering projects.
  2. Engineering Productivity Measures shows how engineering EQUs can be measured and applied to a wide variety of products, globally.
  3. Show me the Money! shares how to leverage engineering EQUs to benchmark performance and set targets to close gaps over time with significant savings.
  4. A fast, accurate way to create project budgets on a large scale, demonstrates a powerful web-based software tool to calculate EQUs and program budgets in just a few minutes.
  5. Applying Continuous Improvement to Product Development explores reasons why more organizations should take this path, but may need help to get started.
  6. Seeing productivity in 3D shows how EQUs can be used to unpack the value of experience, true cost-savings from off-shoring work, and how to better balance resources on a global basis.
  7. "True" Key Performance Indicators vs metrics shows how the right metrics can enable a long-term Continuous Improvement process.
  8. Does Six Sigma = Continuous Improvement? explores how Six Sigma contributes to Continuous Improvement, but does not guarantee it, and may actually harm it if done improperly.
  9. Connecting the Dots shows how to create reliable roadmaps with multiple impacts from multiple initiatives on a complex process used by multiple groups

Copyright 2018 Richard Crayne