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

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.