In my blog Setting SMART Goals, I made the point that having a measurable goal in an improvement project is not enough — we have to know how it is measured and interpreted to make it useful.
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
- A target set by management, e.g. a productivity standard for the site
- Customer requirements, e.g. a minimum process capability
- Some benchmark value from a similar process
- 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 words1 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.
2 comments
Comments are closed.