Have you ever drafted a continuous improvement plan and implemented it, only to feel later on that you may have made it more complex than it had to be? It’s not uncommon. And chances are you might have been right.
Whenever I think about this, I think back to many years ago when W. Edwards Deming started to teach us that variability was bad. Nowadays, it’s an automatic response: “Yes, variability is bad.” Before Deming’s lesson, there was a time when I would introduce continuous improvement concepts to groups of people – and most would say that variability was good. I would ask for examples of “good variability,” which would quickly bring the group to the epiphany that variability is actually bad. We’ve come a long way in terms of understanding variability. I will share more thoughts on variety (generally good) and variability (generally bad) in my next post.
But on to complexity. Today, I think we’re at a similar place with our understanding of complexity. How many times has your continuous improvement solution wound up being more complex than the original problem? The Seven Wastes and poka yoke tackle complexity from a building-block aspect, in that when applied to the problem at hand, we should theoretically be removing steps, reducing time, and simplifying processes. I think the real problem comes when we fail to fully apply these tools directly to our lean solutions, rather than just our initial examination of the process.
This is especially prevalent in improvement activities that involve defect prevention and quality assurance. If a clear poka-yoke isn’t evident, we tend to build in additional inspection steps, complexity and waste that may solve the defect problem, but nonetheless adds even more complexity to the process. Additionally, when teams place a focus on sustaining improvements, there is sometimes a tremendous amount of complexity added to the back-end of the process to ensure that it sustains. Generally this is in the form of inspections and audits. When we add up all of this good-intentioned complexity, our solutions are in danger of overburdening the organization, creating a lack of flexibility and nimbleness.
It’s a delicate balance, but sometimes we err on the side of adding complexity when faced with these situations. I suggest an additional pushback when you are ready to implement a lean solution. One final check to see if there’s a way you can simplify it even more. It’s true that by the time the CI plan is ready to launch, the teams who made it are often ready to rejoice in their imminent successes and don’t have the energy for one more look. But sometimes, one more look can make all the difference in the long run.
Have you seen a rise in complexity/bureaucracy in your organization, even as you’re making progress in your continuous improvement activities? Do you think it’s partially due to the back-end sustainment complexity of your CI activities?
