• 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. 

Following the DMAIC steps, the project team can think rigorously and approach the problem systematically.  Books and training materials include applicable tools for each phase and checklists for tollgate reviews. Organizations often have DMAIC templates that define mandatory and optional deliverables for each phase.  All of these are supposed to help the GBs and BBs to determine the right questions to ask and the right tools to apply along the DMAIC process.

In reality, the templates are not as helpful.  I observe many project leaders either confused with what to do in each DMAIC phase or doing the wrong things.  For example,

• Project teams include a tool or analysis simply because it’s a “required” phase deliverable, even if it doesn’t improve the process or our knowledge. 
• The project leaders are more concerned with presenting visually impressive slides to the management than understanding the process. They re-create a SIPOC or Fishbone diagram on a slide from the flipchart or white board when a snapshot is perfectly legible.
• Project teams go to a great length to document the current state electronically (e.g. in Visio) as a single process (which is futile), rather than spending the time “Go Gemba” to understand the variation.
• The project continues even after the evidence and analysis show that the project baseline or business case is no longer valid.  Instead of using the tollgate to stop or re-scope the project, the team shows various tools and analyses to justify the value of going forward.  They are afraid that terminating the project will reflect negatively on them.
• The project team is sent back to complete a deliverable at the tollgate because it is not satisfactory to the management even when the deliverable is not critical to the next step in the project.  As a result, teams always overprepare for the tollgates in fear of imperfect deliverables.
• Instead of seeing an inadequate measurement system as an opportunity re-scope the project to address it, the team is asked to demonstrate an adequate measurement system before closing the Measure phase.  They are stuck in Measure to perform Improve activities.

Why are these happening?

I discussed in my earlier blogs about some related challenges in “Starting Lean Six Sigma” and “The First Six Sigma Project.”  By understanding how Lean Six Sigma fits in the organization’s objectives, strategy, and capabilities, the leaders can choose the right deployment approach for the organization.  By selecting the right candidates and projects and by providing the right training/coaching to both sponsors and GBs/BBs, the leaders can avoid many common mistakes when the organization is in the low continuous improvement (CI) maturity state.

While the experience of the project leaders is a factor, I attribute the main cause of many Lean Six Sigma deployment issues to the organization, not the individual GBs or BBs.

Beyond the initial stage of the deployment, the organization’s chance to achieve and sustain a CI culture and high return on investment depends on its leaders.  Many Lean Six Sigma challenges simply reflect the existing organizational and leadership issues. Using the DMAIC methodology as a “plug & play” solution by the leaders only exacerbates the underlying problems.

DMAIC templates and tollgate reviews can help guide newly trained GBs and BBs as they practice scientific problem solving.  But when they become prescriptive requirements and project performance criteria dictated by management, it discourages dialogue and organizational learning, which are basic elements in a CI culture.  Judging project progress against a fixed set of DMAIC phase deliverables without understanding the applicability and true contribution in each case only causes confusion and fear.  It reinforces the “fear of failure” mindset in many organizations. 

The DMAIC stages are not linear, but iterative within the project, e.g. if a solution in Improve is insufficient to solve the problem, the team can go back to Analyze.  A DMAIC project should not be run like a “waterfall” project, but an Agile project with rapid learning cycles. With reasonable justification, the team should be allowed to decide to pass the tollgate and continue to the next phase.  Empowering the teams is risky and comes at a cost, but they should be given the opportunities to learn from their mistakes (if it’s not too costly).  Competent coaching will minimize the risk.

Compounded by the fear, poor training, and lack of experience, project efforts are often driven by management expectations at tollgate reviews.  A polished presentation with a complete set of phase deliverables beautifully illustrated with tables and graphs shows team’s accomplishments and satisfies untrained reviewers.  But it often fails at facilitating critical analysis and deep understanding required to address root causes – it sends the wrong message to the organization that the new CI methodology is all about presentation not substance.

If any of the examples sounds familiar or if you are concerned with building a CI culture and capability, one area for improvement might be in your DMAIC stage-gate process. 

A true Six Sigma project attempts to address a new or long-lasting problem that no one knows the real cause or has a clear solution for.   If the cause or solution is known, it is not a Six Sigma project – Just do it.  This uncertainty obviously makes some people less willing to initiate a Six Sigma project and/or can lead to unsuccessful projects.  In many ways, a Six Sigma project is similar to a high-risk R&D project.

How can we manage Six Sigma projects more effectively?

Assuming that the project is the right one for the organization and receives adequate resources and support, consider the following to reduce project delays and pitfalls.  (If the assumptions are not true, see my earlier post “The First Six Sigma Project” for discussion on some common Six Sigma deployment issues first.)

Train Project Management (PM) Skills

Many newly trained Black Belts (BBs) and Green Belts (GBs) lack sufficient project management skills.  Few received formal PM training, and their previous jobs did not require them to lead cross-functional teams.  A minimum of 2 days of PM fundamentals should be provided as a part of Six Sigma training or a separate program.  If the total training budget or days are limited, some more advanced or less frequently used Six Sigma contents (such as statistical tools) should be removed to accommodate the PM need. 

Having the basic PM knowledge is necessary for project success.  Particularly important, the BB/GB should be clear of their role as a project manager relative to the others in the organization.  The PM skills and experience will benefit the organization beyond the Six Sigma projects.  (See my earlier post “Project Managers are Managers” for suggestions for new project managers.) 

Apply Multi-generational Project Planning

Many project issues are a result of an overly large scope.  A Six Sigma project is already high risk without trying to solve too many problems at the same time.  Both the sponsors and BB/GBs tend to be overambitious and include multiple related metrics in the goal, which leads to diluted efforts and project delays.  If the project lasts more than 5-6 months, it is likely the original business case, assumptions, or metrics will no longer be true before they complete the solution due to external circumstances.  Often projects get cancelled before the benefits are achieved.

Instead, it is better to follow multi-generational project planning and break the goal into a series of smaller ones.  For example, two six-month projects sequentially are better than one 12-month project using the same resources.  Ideally, we follow the Pareto principle to achieve 80% of the goal in the first project and then the remaining in the second one.  In many cases, the second project becomes unnecessary because the business environment has changed by the time we finish the first.  This approach is similar to the Lean and Agile principles used in product development to manage uncertainty.

Use DMAIC Tollgates Properly

Most Six Sigma projects follow the DMAIC methodology, that has a tollgate for each of the Define, Measure, Analyze, Improve, and Control phases.  Many organizations have a list of required and recommended deliverables for each phase and check them at the tollgate review.  Unfortunately, many sponsors and even coaches do not understand why and when a deliverable is required for a particular phase; their insistence on completing the deliverable before the tollgate can cause confusion and project delays. 

Too often organizations make the mistake of using a tollgate to evaluate if the BB/GB has done a good job following the DMAIC methodology.  The primary purpose of a tollgate should be to help the sponsor make the right and timely decisions, such as stopping the project or providing resources.  The tollgates should not be the only times when such decisions are made; many inexperienced project managers make the mistake of delaying decisions until the tollgates.  Organizations can avoid such mistakes by setting the right expectations upfront for the tollgates and decision process for all projects.

In summary, to manage the inherent risks in Six Sigma projects, the sponsor and the BB/GB have to be proactive and methodical in planning and execution.   DMAIC should be rigorous, not rigid.   

This is one reason that Measurement System Analysis (MSA) is included in all Six Sigma training.  Because Six Sigma is a data-driven business improvement methodology, data is used in every step of the problem-solving process, commonly following the Define-Measure-Analyze-Improve-Control (or DMAIC) framework.  The goal of MSA is to ensure that the measurement system is adequate for the intended purpose.   For example, a typical MSA evaluates the accuracy and precision of the data. 

In science and engineering, much more comprehensive and rigorous studies of a measurement system are performed for specific purposes.  For example, the US Food and Drug Administration (FDA) publishes a guidance document: Analytical Procedures and Methods Validation for Drugs and Biologics, which states

“Data must be available to establish that the analytical procedures used in testing meet proper standards of accuracy, sensitivity, specificity, and reproducibility and are suitable for their intended purpose.”

While the basic principles and methods have been available for decades, most organizations lack the expertise to apply them properly.  In spite of good intentions to improve data quality, many make the mistake of sending newly trained Six Sigma Green Belts (GB’s) or Black Belts (BB’s) to conduct MSA and fix measurement system problems.  The typical Six Sigma training material in MSA (even at the BB level) is severely insufficient if the trainees are not already proficient in science, statistical methods, and business management.  Most GB’s and BB’s are ill-prepared to address data quality issues.

Here are just a few examples of improper use of MSA associated with Six Sigma projects.

• Starting Six Sigma projects to improve operational metrics (such as cycle time and productivity) without a general assessment of the associated measurement systems.  If the business metrics are used routinely in decision making by the management, it should not be a GB’s job to question the quality of these data in their projects.  It is management’s responsibility to ensure the data are collected and analyzed properly before trying to improve any metric.
• A GB is expected to conduct an MSA on a data source before a business reason or goal is specified.  Is it the accuracy or precision that is of most concern and why? How accurate or precise do we want to be?  MSA is not a check-box exercise and consumes organization’s time and money.  The key question is “is the data or measurement system good enough for the specific purpose or question?”
• Asking a GB to conduct an MSA in the Measure phase and expecting him/her to fix any inadequacy as a part of a Six Sigma project.  In most cases, changing the measurement system is a project by itself.  It is out of scope of the Six Sigma project.  Unless the system is so poor that it invalidates the project, the GB should pass the result from the MSA to someone responsible for the system and move on with his/her project.
• A BB tries to conduct a Gage Repeatability & Reproducibility (R&R) study on production data when a full analytical method validation is required.  A typical Gage R&R only includes a few operators to study measurement variation, whereas in many processes there are far more sources of variation in the system, which requires a much more comprehensive study.  This happens when the BB lacks domain expertise and advanced training in statistical methods.

To avoid such common mistakes, organizations should consider the following simple steps.

1. Identify critical data and assign their respective owners
2. Understand how the data are used, by whom, and for what purpose
3. Decide the approach to validate the measurement systems and identify gaps
4. Develop and execute plans to improve the systems
5. Use data to drive continuous improvement, e.g. using Six Sigma projects

Data brings us opportunities.  Is your organization ready?

• Making little progress because of no time or resources
• Stuck in the Define phase two months after the project start
• Confused by the tools and their applicability in the project
• Overwhelmed by the number of deliverables for each phase
• Taking a long time to obtain data to establish the baseline

This happens in a manufacturing setting where metrics, data, and business cases are readily available.  In a non-production environment, things can be murkier.

For years I was on the teams deploying Lean Six Sigma in two global organizations and have supported many others as a trainer, coach, and consultant.  Although a GB Six Sigma project should be done in 3 to 6 months, it is not uncommon to see most of the GBs unable to finish their first projects six months after the training.  A significant portion do not complete their projects even after 12 months.

Although the reasons for such struggles vary among organizations, some mistakes occur with high frequency.  Most of the mistakes can be explained by the organization’s low Six Sigma maturity and lack of adequate resources.  One can start understanding this problem by asking the three questions I posted last year in Starting Lean Six Sigma.

1. What is the reason to bring in the methodology?
2. What are the specific and measurable goals to justify the investment?
3. What is the organization’s experience in managing change?

These questions help organizations set the right deployment strategy and avoid disappointment due to misinformed expectations.  With the right strategy in place, there are still critical execution details to consider when starting out.

Selection of the GB candidate to lead the project

This decision is the most crucial factor of project success.  Does the person have the technical capability, leadership skills, and most importantly, the personal drive to lead the project?  If this is your first or second wave of Six Sigma projects, choose absolutely only the most promising, capable leaders for Green Belt or Black Belt training.   If not, they are unlikely to succeed in a low maturity Six Sigma environment.

Selection of the Six Sigma project

While most organizations choose projects from their business portfolios that have significant business impact, many fail to consider other key factors.  One factor is suitability as a DMAIC project or the first Six Sigma project for an inexperienced leader.  One example is an implementation project that should be “Just do it.”  Another involves a poorly understood process, which leads to convoluted objectives and/or an impossibly large scope.  

Training and coaching of project sponsors

The project sponsors own the projects and have the most influence on the GB.  They approve the project charters, review deliverables at the DMAIC toll gates, and make resources and other critical decisions.  Few GBs have the luck of having a sponsor who is well versed in the Six Sigma methodology.   Not providing sponsor training prior to project and candidate selection is a common but avoidable mistake.  A one-day training and some ongoing coaching of the sponsors is sufficient in most cases.

Training and coaching of GBs

Most organizations deploying Six Sigma provide some form of training and coaching, which is essential to GB’s learning and project success.  Generic Six Sigma training may be less costly upfront, but GBs will have a harder time applying the methodology correctly and require much more intensive coaching.  In my classes, GBs learn much more effectively if the content and format are specific to the industry or customized to their jobs.  In addition, companies often underestimate the amount of coaching required and overestimate the impact the coaches can have.   This is only exacerbated by poor project and candidate selection, lack of sponsor training, and ineffective training of the methodology.

Lean Six Sigma can transform an organization.  But it takes time, commitment, and the right approach.  The challenges we often see are not necessarily inherent in the methodology and can be overcome by the right deployment strategy and method.

The Challenge

A typical improvement project following an established framework, such as Lean Six Sigma, may look like this:

1. Engage the stakeholders and draft up the project charter, including setting a performance target
2. Map out the current state, possibly using Value Stream Mapping, to establish a cycle time baseline
3. Perform root cause analysis to identify critical factors that influence the cycle time
4. Develop solutions and implementation plans to achieve the improvement goal
5. Implement the solutions and control plan for continual improvement

However, many teams struggle in non-manufacturing environments as soon as they start analyzing the process:

The process is poorly defined and highly variable.  Everyone seems doing things their own ways, and every item seems to require special handling.  Cycle time is not clearly defined or consistently measured.  Data are not always available or comparable among items processed.   It is not uncommon to see data spanning a 10x range in value.  So how do we establish a cycle time baseline given the poorly defined, highly variable process and sparse data?  For a Six Sigma team, how can the performance baseline be measured in terms of defects?  Neither an average cycle time nor process capability (percentage of defects) is a reliable measure of the current state.  But without it, how can we quantify the improvement later?

The struggle continues even after the process has been standardized and solutions have been implemented.   Now the question is “how long does it take to show that the process is better and is delivering the desired business outcome?”  Given a typical business process that spans weeks if not months, it takes months or years to collect enough data to confirm the improvement, if any.  In the meantime, the internal customers or stakeholders of the process are not confident that after all the work they are getting any real benefits.  Each is asking “Sure the overall process may be better on average. But is it helping me achieve my goal?”  No wonder few whole-heartedly support process improvement initiatives.

A Different Approach

Based on my observation, one of the most common mistakes in business process improvement is the implicit assumption that the observed outcome is a result of process variation.   But in most cases, the biggest source of variation is not the process.

Defining a business process baseline using an outcome measure, such as cycle time, is futile.  

Such measures include both process variation and differences in customer or business requirements.  As customer and business requirements change, the process outcomes change wildly.  This variation has little to do with the process itself.  Not recognizing the two sources of variation (process vs. requirements) from the onset of a process improvement project often results in a misguided hope for improvement and a huge waste of time and resources.

In a business process because each outcome is unique, it is best to manage the associated activities as in a project, not in a process.  Formally defined, a project is a temporary endeavor undertaken to create a unique product, service, or result¹.  In contrast, a process is expected to produce the same outcome with minimum variation.   

When there is high variability in a business process, it’s best to first understand how much of the variation comes from customer or business requirements before attempting to establish a process baseline.  In many cases, the answer is obvious.  For example, the time required to register a pharmaceutical product in different countries varies significantly based on the country’s regulatory requirements.  Similarly, the time to negotiate and fully execute a contract varies depending on the specific business requirements and contracting parties.

If the customer or business requirements result in large variation in the outcome measure, e.g. cycle time, it is best to establish something similar to a project baseline, i.e. expected cycle time, for each unique set of requirements.  For example, the expected time to register a product is set at one value for China and a different one for the US.  Our insight will come from the analysis of planned vs. actual values.  Any deviation can then be attributed to 1) our ability to predict the expected value based on existing knowledge and/or 2) our ability to execute according plans.  The best practices in project management (planning and execution, respectively) can naturally be applied to improve the outcome².  

So next time when you are asked to lead a business improvement project, ask this question first:

Did we expect the outcome to be at that level when we started?

1. Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
2. For more discussion on integrating project and process management in non-manufacturing processes, see my publication with Thomas Bertels at Valeocon Management Consulting.

However, turning the opportunities into fruitful results can be a bumpy journey. I expect organizations to encounter greater difficulty than implementing Six Sigma, a data-driven business improvement methodology.

Since the 1980’s, many organizations have implemented Six Sigma (often along with other methodologies) to improve their performance. Some were able to transform the entire organization’s culture and capabilities to achieve sustained improvement, while many were only able to achieve isolated and/or temporary gains. There is no question that change leadership and organizational change management capability played a critical role. Implementing data analytics is no exception.

In addition, Six Sigma and Big Data analytics share some unique challenges, one of which is the requirement for data and the expertise in extracting insight from the data. I have seen countless Six Sigma projects fail to deliver the promise because of poor data availability or quality and/or lack of skilled resources. Unable to achieve quick and significant improvement, some organizations have given up on Six Sigma and shifted more effort to Lean or Agile. But the underlying causes of deficiencies in data and analytics capabilities are not addressed and will inevitably impede implementation of data analytics initiatives.

Therefore, organizations considering investing in data analytics should seriously assess these two risk areas.

Poor data quality
I use “quality” here loosely to mean two things, usefulness and absence of defects.

Not all data are equally useful and can help us develop insight or solve problems. What data should be captured, stored, and processed? Data that is readily available may not be useful to the problem we try to solve, whereas potentially useful data can be costly to collect. Who can help decide and prioritize what data to collect?

It is a known fact but may be surprising to some people that data scientists spend more time cleaning up data than analyzing it. Useful data rarely come in a complete, accurate, and consistent format. A Forbes article reports that data scientists spend about 80% of their time on collecting, cleaning, and organizing data. I concur that data cleaning is the most time-consuming and least enjoyable task. No business wants their scarce and highly paid resources to spend the majority of the time on non-value added activities. What can they do about it?

Lack of resources with analytics and subject matter expertise
To solve business problems, analytics experts need computer science and statistical skills but also general operations and business knowledge. Ideally, they also have subject matter expertise. But such talent is the exception rather than the norm. The iterative process of collecting, cleaning, modeling, and interpreting data requires close collaboration among analytics, subject matter experts, and management. My observation has been that most subject matter experts are not familiar with even the basic concepts of computer science and statistics, the backbone of analytics. Simply hiring a few Black Belts never worked for Six Sigma; acquiring data scientists is not enough if the rest of the organization is ill prepared. A Center of Excellence model tends to centralize the analytics expertise and delay broad engagement and ownership across the organization.

These areas are but two important considerations as leaders develop a comprehensive approach to mitigate risks in analytics programs. Leaders should follow a strategy development process and resist one-off efforts, such as technology installation or talent acquisition. By evaluating all aspects of the current operating model with respect to their vision of digital capabilities for the future organization, they can develop a cohesive plan for a smoother ride to the destination.

For more than a decade, I have led, supported, and observed Lean Six Sigma deployments in many organizations in life sciences. As a result of varying degrees of success, some people praise the transformative power of Lean Six Sigma, whereas others view it as an outdated management fad. While these perspectives are understandable, it is not helpful to organizations searching for the right path to business improvement.

Lean Six Sigma, or more generally, Operational Excellence, is a management methodology or a set of principles and tools. By itself, it is not sufficient to achieve desired outcomes. It requires know-how. Failure to achieve intended goals often has more to do with how we use it.

“Using the right tools for the job” sounds obvious. But when it comes to sophisticated tools and complicated jobs, it’s not. That’s when we ask professionals, e.g. a doctor or lawyer, who will help diagnose the problem and evaluate options to enable us to make an educated decision.

Similarly, before we jump on the Lean Six Sigma bandwagon, ask these questions:

1. What is the reason to bring in the methodology?

Do we want to solve a problem we have today, or develop a new and sustained organizational capability or culture? Lean Six Sigma is very effective in delivering quick wins, e.g. reducing waste and resolving some quality issues. Building a quality culture, agility, and continuous improvement capability is an entirely different game. In my opinion, both objectives are valid but they require very different implementation methods.

2. What are the specific and measurable goals to justify the investment?

Depending on the goal, the financial investment and organizational commitment required vary greatly. The more we can specify and quantify the goals, the more we can plan for the right resources and set the right expectations. We often underestimate or are unaware of the investment required to create the desired organizational change. It is not surprising that when the results do not come quickly, many are disappointed and give up.

3. What is the organization’s experience in managing change?

If the goal includes developing a new capability or culture, it is imperative to assess the organization’s readiness for change. Operational Excellence requires a different mindset and behavior that many organizations do not have. If the organization lacks the experience or resources to manage change, there is a high probability that the change initiative will fail. In this case, it would be better to take a stepwise approach to allow the organization to develop change capability gradually as it improves the business.

There are obviously more questions to consider before and during the deployment. Answering these three questions from the start will help leaders clarify and communicate their vision, gain support, and prevent some common pitfalls in Lean Six Sigma implementation.