In today’s business, time is money. Speed can determine the success or failure of a product, program, or even a company. I have been involved in many business process improvement projects aimed at reducing cycle time, e.g. the time to register novel pharmaceuticals in emerging markets or the time to fully execute contracts required for a clinical development program.
The Challenge
A typical improvement project following an established framework, such as Lean Six Sigma, may look like this:
- Engage the stakeholders and draft up the project charter, including setting a performance target
- Map out the current state, possibly using Value Stream Mapping, to establish a cycle time baseline
- Perform root cause analysis to identify critical factors that influence the cycle time
- Develop solutions and implementation plans to achieve the improvement goal
- 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 result1. 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 outcome2.
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?
- Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
- For more discussion on integrating project and process management in non-manufacturing processes, see my publication with Thomas Bertels at Valeocon Management Consulting.