• Understand the reason to bring in the methodology and assess organization’s readiness (Starting Lean Six Sigma)
• Select the right projects and leaders and provide training and coaching (The First Six Sigma Project)
• Pay attention to organization’s management process and leadership behaviors (Revisiting the DMAIC Stage-gate Process)
• Ensure that process management is built as a foundation for improvement (Continuous Improvement Is More Than Projects)
• Avoid over-reliance on weeks-long classroom training to achieve results (Lean Six Sigma Training for Continuous Improvement)

In the last recommendation, I didn’t include an alternative approach because it required more elaboration.

The traditional Lean Six Sigma (LSS) deployment uses classroom training to teach concepts and tools to employees, who become Green Belts (GB) or Black Belt (BB) candidates.  The inexperienced GBs and/or BBs leading improvement projects often struggle to recall what they learned in the class and relate it to the real-world problems.  

What I think works better is project-based learning, in which the employees learn by participating in a job-related project led by an experienced CI professional.   The on-the-job hands-on learning is supplemented by expert coaching and self-paced learning. 

Assuming the organization is new to CI, I propose that it starts with a pilot project led by a CI veteran, who can guide the organization in a learning journey.  The journey will not only teach the team CI methodologies but also help the organization leaders discover many existing gaps, risks, issues, and opportunities, which leads to a better long-term strategy.  This CI leader has multiple roles — the coach to the organization leaders, the leader of the project, and the trainer of CI methodologies to the employees.

The proposed approach achieves multiple goals.

• Enable the organization to achieve optimal outcomes
• Build internal capabilities, including processes and skills
• Help develop a CI strategy and culture for the long term

The approach can include the following.

1. The senior CI sponsor (a top executive) recruits or retains a truly experienced CI leader (either an employee or consultant), with an explicit role of leading the pilot project, assessing organization, and helping develop its deployment strategy
2. The CI leader works with the sponsor to charter a suitable project, including clear expectations of their respective roles
3. The CI leader works with the sponsor and other managers to select project team members
4. The sponsor clearly communicates the role, responsibilities, and decision power of the CI leader to the entire organization
5. The sponsor personally demonstrates his/her commitment and holds the organization accountable
6. The CI leader leads the project and project team, giving just-in-time training as appropriate (Lean, Six Sigma, project management, change management, statistical methods, etc.)
7. The CI leader engages the team in using the CI concepts and tools in the project and demonstrates their value and limitations
8. Project members are given ample materials and opportunities to expand the learning on their own and have open access to coaching by the CI leader
9. The CI leader assesses the organization (e.g. organizational readiness, maturity, culture) and team members (e.g. skills, behavior, performance) throughout the entire project lifecycle
10. The CI leader provides analyses (e.g. SWOT) and recommendations to the sponsor, such as deployment strategy, high value projects, and high potential employees (i.e. future leaders)

This approach will avoid many common pitfalls in LSS training and deployment and take advantage of many opportunities provided by modern technology, such as online and on-demand learning.

The two limiting factors I see are a capable CI leader and a committed sponsor.

What other alternatives would you recommend?

Over 15 years ago, I received my LSS Black Belt (BB) training sponsored by my employer.  It was three weeks of classroom training delivered over three months by external consultants.  It kick-started my Continuous Improvement (CI) journey.  Since then, I have delivered LSS training as an internal trainer or external consultant to many large global organizations.  I also helped organizations in their LSS deployment, led many CI projects, and coached Green Belt (GB) and BB leaders in their projects.

Despite my own positive experience with LSS training, what I have learned over the years is that in most situations the traditional weeks long LSS training is ineffective in driving CI. 

If measured by the number of people trained or certified or the number of methods and tools covered, such training programs are very effective and easily justified for the investment.  

But if we start to measure the improvement of business outcomes, the desired problem-solving skills and behavior of the trained employees, and the positive impact on the CI culture and mindset of the organization, the training is very often ineffective.  Some troubling signs are

• It took 12 months or more to complete the first GB project.
• The GB could not recall some basic topics only a few weeks after the training.
• BB candidates have to create flash cards to prepare for their certification exams.
• GBs or BBs are no longer engaged in CI after obtaining their certifications.
• Certified BBs fail to exhibit or apply knowledge of some fundamental concepts, such as process stability, in their daily work.
• The trained employees do not perform or behave differently from those untrained in the CI methodology

I can see two main factors contributing to this poor outcome.

First, the training program only teaches the general methods and tools and does not improve skills.

Previously, I discussed training and coaching considerations in LSS deployment in The First Six Sigma Project and recommended customized training in Making Employee Training Effective.

Most LSS training programs developed by universities, professional organizations, and commercial vendors are designed for efficiency and profitability. The generic programs do not connect the content to the client organization’s problems and operational reality.  Few external trainers have the subject matter or industry knowledge to tailor the training to each client’s need.  Even if they are able to customize, few clients are willing to pay the substantial premium.

Corporate internal programs are not much better in terms of sufficiently relevant materials that relate to each employee’s job.  Employees do not start learning real problem-solving skills until they encounter problems in their projects, by which time they already forgot most of what was taught in the training. 

Second, the organization overly relies on training to improve business performance.

Two common fallacies can lead to this “improvement training trap.”

1. Employees have to be trained in the methods and tools or they won’t be able to learn themselves.
2. Once the employees are formally trained, they will solve all the problems on their own.

Can classroom training help accelerate learning? Absolutely.  Is it necessary or sufficient to develop the skills, mindset, and behavior for CI?  No.

These programs train methods and tools, whereas what the organizations really need is leadership development and behavior modification.  

Management has to understand that employees’ knowledge in CI methodologies is only a small but essential driver in business improvement.  When employees are not engaged in effective CI activities, it is not necessarily due to lack of knowledge – something else is likely limiting.  The root cause is rarely lack of training, and the solution is not more or even better training.  

It is management’s job to critically analyze all aspects of the organization, e.g. processes, structure, policies, resources, people, and culture, to identify the barriers to CI.  When they do, they will likely find out that LSS training is not the solution to their problem.

The questions about “what is Lean” and “what is Six Sigma” inevitably come up when you train and coach people in CI methodologies.  Without delving into the principles, my answer goes something like this:

• Lean is about delivering value to the customer, fast and with minimum waste.
• Six Sigma is about understanding and reducing variation.

None of them is satisfactory.  But practically these messages are effective in stressing the necessary concepts they need to develop, i.e. value and variation — a prerequisite for CI.  These answers are certainly insufficient and not meant to be.  It’s hard to understand the true meaning of life or happiness when we are 5 years old.  Likewise, it takes a lifetime of experience to understand the true meaning and principles of CI and apply them well.

While the concept of value versus waste is intuitive, most people don’t interpret their daily observations in terms of variation.  Because of the (over-)emphasis of statistical tools in Six Sigma by many consultants, many organizations prefer Lean to Six Sigma (see my earlier blog “How is your Lean developing” for potential pitfalls in replying on simple Lean tools).  The lack of appreciation of the concept of variation will eventually constrain the organization’s ability to improve.

There are many applications of the concept of variation in understanding and improving a process.  Most applications don’t require sophisticated knowledge in statistics or probability theory.  One example is management of supply and demand.

Let’s say that you plan your resources and capacity to meet a target demand level.  The demand can be from internal or external customers, and can be for products, services, materials, or projects. For simplicity, let’s assume that it’s a fixed capacity without any variation, e.g. no unplanned downtime or sick leaves.  

If you plan enough resources for the total or average demand but the demand varies greatly (upper left of the figure), you will meet the demand exactly only occasionally. Most of the time, you will either not have enough capacity (creating backlogs or bottlenecks) and miss some opportunities or have too much capacity and lose the unused resources forever.

If it is too costly to miss the opportunities, some organizations are forced to raise the capacity (upper right of the figure). Many optimize the resources to strike a balance between lost capacity and missed opportunities.  What I have observed is that organizations go back and forth between maximizing opportunities and reducing waste.  One improvement project is sponsored (by one function) to reduce the risk of the missed opportunities with a solution that shows a high return-on-investment in the added resources.  As a result, the excess capacity is common, leading to another project (probably by another function) to reduce waste and maximize resource utilization.  The next demand surge will lead to another round of improvement projects.

Many people don’t realize that the real long-term improvement has to address the issue of demand variation.  For example, if we understand the sources of demand variation and therefore develop solutions to limit it, both missed opportunities and lost capacity will be reduced (bottom half of the figure).  A much lower capacity is needed to satisfy the same overall but less variable demand.

Capacity variation has similar effects. 

What is more interesting is that most processes are made of a series of interdependent supply-demand stages, each of which propagates or accumulates the effect of variation.  We can use this understanding of variation to explain many phenomena in our lives, e.g. process bottlenecks, traffic jams, project delays, supply overage, excess inventory, etc.  The Theory of Constraints popularized by Eliyahu Goldratt in his book The Goal is also based on the same ideas of process interdependence and variation.

No matter what CI methodologies you use, I hope you agree that understanding and reducing variation is always a key to improvement. 

Based on my observation, the answer is mostly not much. 

The primary reason is that most people are never taught statistics properly.   Terms like null hypothesis and p-value just don’t make intuitive sense, and statistical concepts are rarely presented in the context of scientific problem solving. 

In the era of Big Data, machine learning, and artificial intelligence, one would expect improved statistical thinking and skills in science and industry.  However, the teaching and practice of statistical theory and methods remain poor – probably no better than when W. E. Deming wrote his 1975 article “On Probability As a Basis For Action.” 

I have witnessed many incorrect practices in teaching and application of statistical concepts and tools.  There are mistakes unknowingly made by users inadequately trained in statistical methods, for example, failing to meet the assumptions of a method or not considering the impact of the sample size (or statistical power).  The lack of technical knowledge can be improved by continued learning of the theory.

The bigger problem I see is that statistical tools are used for the wrong purpose or the wrong question by people who are supposed to know what they are doing — the professionals.  To the less sophisticated viewers, the statistical procedures used by those professionals look proper or even impressive.  To most viewers, if the method, logic, or conclusion doesn’t make sense, it must be due to their lack of understanding.  

An example of using statistics for the wrong purpose is p-hacking – a common practice to manipulate the experiment or analysis to make the p-value the desired value, and therefore, support the conclusion.

Not all bad practices are as easily detectable as p-hacking.  They often use statistical concepts and tools for the wrong question.  One category of such examples is failing to differentiate enumerative and analytic problems, a concept that Deming wrote extensively in his work, including the article mentioned above.  I also touched on this in my blog Understanding Process Capability.

In my opinion, the underlying issue using statistics to answer the wrong questions is the gap between subject matter experts who try to solve problems but lack adequate understanding of probability theory, and statisticians who understand the theory but do not have experience solving real-world scientific or business problems.   

Here is an example. A well-known statistical software company provides a “decision making with data” training.  Their example of using a hypothesis test is to evaluate if a process is on target after some improvement.  They make the null hypothesis as the process mean equal to the desired target.  

The instructors explain that “the null hypothesis is the default decision” and “the null is true unless our data tell us otherwise.” Why would anyone collect data and perform statistical analysis if they already believe that the process is on target?  If you are statistically savvy, you will recognize that you can reject any hypothesis by collecting a large enough sample. In this case, you will eventually conclude that the process is not on target.

The instructors further explain “It might seem counterintuitive, but you conduct this analysis to test that the process is not on target. That is, you are testing that the changes are not sufficient to bring the process to target.” It is counterintuitive because the decision maker’s natural question after the improvement is “does the process hit the target” not “does the process not hit the target?”

The reason I suppose for choosing such a counterintuitive null hypothesis here is that it’s convenient to formulate the null hypothesis by setting the process mean to a known value and then calculate the probability of observing the data collected (i.e. sample) from this hypothetical process.  

What’s really needed in this problem is not statistical methods, but scientific methods of knowledge acquisition. We have to help decision makers understand the right questions. 

The right question in this example is not “does the process hit the target?” which is another example of process improvement goal setting based on desirability, not a specific opportunity. [See my blog Achieving Improvement for more discussion.]  

The right question should be “do the observations fall where we expect them to be, based on our knowledge of the change made?”  This “where” is the range of values estimated based on our understanding of the change BEFORE we collect the data, which is part of the Plan of the Plan-Do-Study-Act or Plan-Do-Check-Act (PDSA or PDCA) cycle of scientific knowledge acquisition and continuous improvement.   

If we cannot estimate this range with its associated probability density, then we don’t know enough of our change and its impact on the process.  In other words, we are just messing around without using a scientific method.  No application of statistical tools can help – they are just window dressing.

With the right question asked, a hypothesis test is unnecessary, and there is no false hope that the process will hit the desired target.  We will improve our knowledge based on how well the observations match our expected or predicted range (i.e. Study/Check).   We will continue to improve based on specific opportunities generated with our new knowledge.

What is your experience in scientific problem solving?

Understandably, many CI projects are chartered because there is a need to improve business performance.  But if the opportunity or path to improvement is not clear, the project has a high risk of failure¹.  Even if the goal was somehow achieved, it likely took far more time and effort than necessary, as evidenced by many 6-12 month long Green Belt (GB) projects. 

While CI professionals are often trained to not assume a solution or even a root cause in Lean Six Sigma projects, the approach to the problem should be well defined for the specific problem.  DMAIC or similar one-size-fits-all frameworks are too generic to be helpful.  Because most project leaders do not have enough experience to identify the right opportunity for a CI project and follow a proven path to improvement, it is essential that the organization implements an effective system to differentiate opportunities into categories suited for distinct approaches.  For example, the categories can include

• Routine improvement by the operators
• Kaizen events
• Lean Six Sigma or DMAIC projects  
• Technical projects that require Subject Matter Experts (SMEs)
• Management

The system will vary by the organization.  In a manufacturing or transactional environment where CI methodologies are applied, I recommend process management as a basic component of the system.  Specifically, process management should include, but is not limited to

• Process mapping to understand how things are being done
• Standardization to implement the best knowledge currently available
• Standard Operating Procedures (SOPs) up to date
• Employees trained and qualified to perform the jobs
• All preventative maintenance followed
• Measurement system analysis to ensure reliable data
• Statistical Process Control (SPC) to monitor and stabilize processes

These foundational activities are prerequisites for any process to perform at its optimal level that is achievable by design.  If these activities are not consistently followed, even an initially high-performing process will deteriorate. 

Any organization striving to improve their processes should start by incorporating these activities into the responsibilities of various roles.  Following these activities will regularly uncover many improvement opportunities, most of which can be accomplished by those who are closest to the process. If needed, Quality and CI professionals can train and coach others proper methods and tools. 

Ideally, process management should be implemented before initiating CI projects in the area.  Routine improvement as a result of process management eliminates countless potential root causes for poor process performance, reducing the need for project-based improvement effort.  Any CI projects, if needed, will have a clearer focus, less encumbered by confounding factors.

When organizations fail to build process management in their operations, CI projects are often initiated as a reaction to emergent problems, which are likely due to years of neglect.  They hope, with the aid of some magic methodology and heroic efforts, that the projects alone will solve the problems.  What they encounter, however, are numerous causes that compound the problem, making a “perfect” situation for inexperienced project leaders in a low CI maturity organization.

Thus projects are a tool of continuous improvement.  They are not a substitute for it.²

1. See my blog Six Sigma Project Management for suggestions to reduce project risks.

2. I borrowed a statement by Peter Drucker when he discussed merger & acquisition — “Thus financial transactions are a tool of business policy.  They are not a substitute for it.” 

What makes a goal achievable?  In my work as a Continuous Improvement (CI) coach and consultant, I have seen some common practices setting a numerical goal using, for example

1. A target set by management, e.g. a productivity standard for the site
2. Customer requirements, e.g. a minimum process capability
3. Some benchmark value from a similar process
4. A number with sufficient business benefit, e.g. 10% improvement

At the first glance, these methods seem reasonable.  In practice, they are problematic for two reasons.

First, the goals are based on what is desirable, not sound understanding of the opportunity using data.  How do we know if a desirable goal is achievable?   In many organizations, a numerical goal is “set in stone” when the project starts; failing to achieve the goal can have potential career repercussions.  While management tends to aim for aggressive targets, the project leaders are more concerned with the risk of failing to achieve them.  They prefer a more “realistic” target that can be met or even exceeded and negotiate with the sponsors to make the desirable target a “stretch” goal.  In the end, no one knows what the real improvement opportunity is.

Secondly, the practices create a mindset and behavior inconducive to the CI culture.  I have seen too many organizations’ Lean, Six Sigma, or other CI initiatives focus only on training and project execution.  They fail to build CI into their daily decisions, operations, and organization’s culture.  Quality improvement cannot be accomplished by projects alone – numerous incremental improvement opportunities exist in routine activities outside any project.  Projects, by their nature, are of a limited duration and are merely one mechanism or component of continuous improvement. Most improvement does not require a project.  Depending on projects to improve a process is a misunderstanding of CI, reinforces reactive (firefighting) behavior, and sends a wrong message to the organization that improvement is achieved through projects, and even worse, by specialists.

Creating a project with only a desired target leads to high uncertainty in project scope, resources, and timelines – a lot of waste. 

To be effective, a CI project should have a specific opportunity identified based on systematic analysis of the process.  Furthermore, the opportunity is realized through a project only if it requires additional and/or specialized resources; otherwise, the improvement should be carried out within routine activities by the responsible people in collaboration. 

What kind of systematic analysis should we perform to identify the opportunities?

One powerful analysis is related to process stability.  It requires our understanding of the nature and sources of variation in a process or system.  In a stable process, there is only common cause variation – its performance is predictable.  If a process is not stable, there exists special cause variation — its performance is not predictable.  Depending on process stability, the opportunity for improvement and the approach are distinct. 

The first question I ask about the goal of any improvement project is “Is the current performance unexpected?”  In other words, is the process performing as predicted?  No project should start without answering this question satisfactorily in terms of process stability.  Most often the answer is something like “We don’t really know but we want something better.”  If you don’t know where you are, how do you get to where you want to be?  This is a typical symptom of a project driven by the desirability rather than a specific opportunity based on analysis.  If the process stability was examined, most likely the first step toward improvement would be to understand and reduce process variation, which does not need a project.

For people familiar with Deming’s 14 Points for Management, I have said nothing new.  I merely touched point 11 “Eliminate management by numbers, numerical goals.”  His original words¹ are illustrative.

“If you have a stable system, then there is no use to specify a goal.  You will get whatever the system will deliver.  A goal beyond the capability of the system will not be reached.”

“If you have not a stable system, then there is again no point in setting a goal.  There is no way to know what the system will produce: it has no capability.”

A goal statement that sounds SMART does not make a project smart.  A project devoid of true improvement opportunity achieves nothing but waste.  But if we follow the path shown by Deming, opportunities abound and improvement continues. 

1. Deming, W. Edwards. Out of the Crisis : Quality, Productivity, and Competitive Position. Cambridge, Mass.: Massachusetts Institute of Technology, Center for Advanced Engineering Study, 1986.