Ten Pitfalls to Avoid in Process Improvement Initiatives

In my years of process improvement work, I've identified some problems that hinder the achievement of excellence. These are likely not unique to my experience and I want to share them with you, along with some suggestions on how to avoid them.

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. The language of management is money. If they don't see benefit hitting the bottom line, they question the validity and/or value. Toward that end, you need to ensure that independent, active, financial participation is a part of the process, particularly when the project is being scoped and again as the control plan is being put into place (more on this later). Finally, it may be necessary to revitalize the existing process with a new wave, initiative, or focus.

We implemented a pilot Six Sigma program from the middle of our organization. At the end of that first year, top management noticed millions of dollars positively affecting the bottom line -- and wanted to know where it was coming from. As a result, they searched us out, and we gained active, broad support to expand the initiative throughout the business.

Pitfall No. 2: Failure to link project objectives with corporate/business goals

This also can have a number of causes, such as project scoping that is done at the local/functional level without feedback from corporate functions. Or it could be that functional metrics rather than global metrics are used to measure success. In other instances, corporate goals or objectives may not be clear, or even worse are conflicting at different levels/functions within the organization.

To prevent this, projects should be ranked according to corporate/business goals (e.g. cause and effect matrix), not just functional objectives. To do this, business project requirements need to be determined and used to rank all projects.

The last thing you want to do is spend time and resources improving a product that the business plans to eliminate in the near future.

Pitfall No. 3: Optimizing the part at the sub-optimization of the whole

This is closely related to No. 2 where siloed functions, using local objectives, obtain benefit to their area at the detriment of other functions or areas. The root cause is insufficient focus on the overall business objectives. One of the most common cases of this involves procurement. In an effort to get the best pricing, purchasing tends to order in large quantities. While this results in savings in purchasing, it costs the plants in inventory and warehouse space. When looking at the benefits of such a project, the effect on the whole organization should be assessed.

Possible solutions include a focus on ranking projects according to corporate/business goals (mentioned in No. 1). Also, the synchronous management metrics of throughput (defined as dollar value of product sold), operating expense (cost to convert raw materials to finished product), and inventory (including raw material, in-process, and finished product) can be used to assess benefit at the product line level no matter which function the project comes from. The goal is to focus on projects in which all three move in the proper direction at the same time. If a project benefits one at the expense of the other two (e.g. the purchasing example), it should be reconsidered.

Pitfall No. 4: Hidden agendas

The problem here is that the project, and often its solution, is being dictated by someone in authority. The solution is to ensure that the project selection process is well structured, aligned to corporate goals, and projects are selected by the business team at as high a level as possible. I remember a Six Sigma project, focused on increasing capacity, where the hidden agenda was to get capital for a new reactor. Luckily, the Blackbelt being trained followed the Six Sigma roadmap and looked at all aspects of the process. The result was that capacity was increased to the point it flooded downstream units. Bottom line: The new reactor wasn't needed!

Pitfall No.5: Lack of process owner support

A project and/or solution being dictated by someone in authority can have this problem (See No. 4). Other sources of this problem include process owners who do not understand the value of tools/roadmaps. Or if the project objectives do not align clearly with the corporate goals, then the project might not have a high priority in the general scheme of things (See No. 2).

In addition to implementing solutions mentioned in No. 2 and No. 4, it often helps to have the process owner attend training and carry at least one project to successful completion. Some of the best process owner support I have received came from a plant manager who was a Six Sigma-trained Black Belt. He had a clear understanding of the tools, data and resource needs for projects, and benefits of the methodology. In addition, he made a good mentor/coach for those under him.

Pitfall No. 6: Not letting the project determine what project type to use and who the team leader should be

It's happened time and time again. A project leader is selected and instructed to identify a project to do (often to take to training). This is done generally to fulfill a corporate implementation initiative without having a clear initiation process.

The solution is to establish a clear project initiation process up front. The first step is to obtain and rank a hopper (see Project Initiation Process chart). The main objective of each project should determine the tools needed (e.g. Lean, Six Sigma, Go Do, Engineering -- or a combination of these). For example:

1. A Lean project is focused on removing waste and reducing cycle time.
2. A Six Sigma project is focused on reducing common cause variation.
3. A Go Do is something easy and cheap to implement.
4. An Engineering project requires capital expenditure (and should be a last resort).
5. Projects should use the appropriate tools no matter which type it is (e.g. a Six Sigma project might use Value Stream mapping in the Analyze phase)

Once the project and type have been determined, then the most appropriate individual should be assigned as project leader. If that person needs appropriate training, so be it. If that project leader is too busy with more important things, then a re-assessment of what's important to the business needs to be conducted. If the project selection process is properly linked to corporate/business objectives, then this project should have very high priority.

Pitfall No.7: Not involving financial representative in project scoping

Have you ever seen it happen where a project is completed and benefits cannot be captured in the existing cost accounting system? This can happen if the project leader calculates benefits on his own. It is important for financial representation to be an active part of project scoping and validation process. This will ensure that the measures of success are firmly linked to the cost accounting system. Benefit calculations should be determined and a spreadsheet put into place to ensure that, whoever gathers the process data, it can be easily converted into benefit value. An added benefit to this is that often the financial representative can suggest additional savings that the project leader may overlook.

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

No one knows better what happens on the factory floor than those who have their hands on it every day. 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.

My last project involved improving the color of a product in a chemical process. One of the factors involved an operator who was colorblind. There was serious concern that this operator was contributing to the color issues. However, data analysis on the process found that this operator consistently produced better product than his peers. In walking the process with him, it was found that he utilized an analytical test, rather than visual check to ascertain when to stop the reaction. When the procedure was changed to rely solely on the analytical testing, the consistency of the color improved.

Pitfall No. 10: Failure to stabilize the process prior to embarking on improvement

The process needs to be stabilized prior to implementing effective solutions. Failure to do so could result in the improvement being lost in the assignable cause fluctuations that will occur. It is important to spend time early in the improvement process to review the current process and procedures with the employees involved. Look at narrowing the processing ranges wherever possible (suggestion: use control charts to re-set limits), even if the process is very forgiving. Discuss with the operators the different techniques used and settle on a single one for all to use. Write the changes into the Standard Operating Procedures (SOP) and ensure that everyone understands the importance of following them. For processes using control charts, look at assignable cause variation and put mistake-proofing controls in place to prevent these. Focus on making the right thing easy to do and the wrong thing hard to do. If need be, put data collection and sign-off controls in place to ensure all are following the procedure. Identify variables that are difficult to control so they can be included in the data analysis to determine if they are critical in nature.

In one project, there was a vessel that was heated with steam, but had no regulator for the steam or temperature readout on the vessel (i.e. there was no way to control processing through this tank). Major capital modifications would be needed to add the appropriate controls, and it was unlikely that this capital would become available any time in the near future. Data analysis on the process indicated that the longer the reactors were down in this batch process, the worse the quality of the product was. This didn't make sense until it was discussed in detail with operators. It seems that the heel left in the steam-heated vessel was overheating product when the reactors were down. A signoff was added to the procedure to discard the heel if the reactors were down more than 16 hours. Product quality improved dramatically.

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.

One of the highlights in my career came when a production supervisor stormed into my office claming that "if I made the process any easier to operate, the workers wouldn't have anything to do." I wanted to cheer! The process should be easy to operate. We'll find something more value-added for the operators to do.

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. Good Luck!

Paula Riley is the managing member of Riley Process Excellence, a Lean Sigma consulting firm, and director of Improvium US, a consulting firm focusing on the chemical and petrochemical industries. She is a certified ASQ Six Sigma Blackbelt. Riley has over 16 years of experience in process improvement work in specialty chemicals, as well as other work in water/wastewater, waxes, and activated carbon. www.rileypx.com

Interested in information related to this topic? Subscribe to our weekly Continuous Improvement eNewsletter.