I came across an article a few days ago discussing some of the key reasons why Lean initiatives are unsuccessful. Anyone on a Lean journey has probably encountered one or more of these problems at some point. I wanted to share four of the pitfalls discussed in the article that I see most commonly in my work in process improvement. The article includes the author’s thoughts and suggestions on ways to avoid these pitfalls.
This is an excerpt from Paula Riley’s article, Ten Pitfalls to Avoid in Process Improvement Initiatives.
Pitfall No. 1: Lack of upper-level management support for process improvement initiatives
This can have a number of causes, including lack of understanding of the potential value, a poor implementation process, insufficient sustain controls, inadequate validation process, or loss of focus on the bottom line.
There are a number of things that can/should be done to minimize this. For example, you can schedule an orientation session with upper management. Or better yet, encourage them to become trained and run a project. Routine project reviews should include participation, not only from the process owner, but also from those over him/her. Ensure that improvement initiatives always maintain their focus on the business’ bottom line.
Pitfall No. 8: Team make-up not including all relevant functions
This problem has a variety of causes, including resource constraints, siloed functions, and the failure to recognize the value of other functions in obtaining an all-encompassing view of the process. As a result, a narrow view of process results in narrow improvement plan and minimal results — or none at all.
The key is to ensure that all functions affected by the process are involved in the project. That being said, team size can be an issue. An ideal size is from six to 10 members. Any less may cause one to wonder if all appropriate functions are included. Any more can cause the team to be difficult to manage and result in a loss of focus. Therefore, where appropriate, some resources can be supporting team members, rather than full-time team members. This will allow them to be brought in to the improvement process when they are needed, but keep the team size manageable and allow them to focus on their other duties when not needed. Whether a full time team member, or supporting team member, all should be copied with minutes and other team documentation.
Pitfall No. 9: Not walking the process and involving the operators
Every project should start in the work area where improvement is expected. As improvements are implemented, additional visits to the area are in order to ensure that employees in the area understand and benefit from the improvements. At the end of the project another visit is needed to ensure that the control plan is fully implemented and effective.
Bonus: Ineffective control plan
Unless something is put into place to prevent returning to “the way it has always been done,” the process will slide back to what it was. The tendency is to put in more instructions, signoffs, control charts, etc., in an attempt to control the process. But this is not the way to go. The new process must be easier to run than the old. It must make the operator’s job simpler, better, faster. It must make going back to the old way undesirable or hard to do and the new way pleasant and a joy. This requires careful thought and ingenuity from the team, and close involvement and feedback from the workers in the process. But please don’t jump to an engineering solution involving capital. There are other, cheaper, ways to accomplish this — you just have to dig them out.
Looking at these various pitfalls, it seems that they are often inter-related and linked. As a result, like a set of dominos, one problem leads to another, leads to another, often exponentially. If you need to improve your process improvement process, make it a project. Get a team of the right people together, charter the project, and use the tools to make improvements. Look at potential (or existing) problems as opportunities for improvement — and go after them.
Great article the only problem is the captains of industry will never take time to read it.
The captains believe instituting a quality program will solve all problems. Its rolled out like a cult implemented like a religion and is marketed rather than executed. Quality program then becomes the product rather than the tool. Execs believe they can now detach and manage by scorecards and charts!
For example attendance for Gemba walks become mandatory, why? Not to ensure problem solving rather to meet a 95% participation goal. Once again it becomes the product rather than the tool. Organizations executives who are not actively involved and depend solely on charts will only sabotage their continuous improvement efforts.
Again great article!