Ten Pitfalls to Avoid in Process Improvement Initiatives

Many manufacturers face common problems that hinder their ability to achieve
excellence. Consider these suggestions to improve your efforts at process improvement.

By Paula Riley, managing member, Riley Process Excellence

June 17, 2008 -- 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 Project Initiation Process
obtain and rank a hopper (see Project Initiation
Process chart). The main objective of each project 1. Identify the opportunity.
should determine the tools needed (e.g. Lean, Six 2. Rank opportunity hopper.
Sigma, Go Do, Engineering -- or a combination of 3. Identify project type.
these). For example: 4. Assign project leader.
5. Determine whether
1. A Lean project is focused on removing training is needed.
waste and reducing cycle time. 6. If no training is needed,
2. A Six Sigma project is focused on then begin the project. If
reducing common cause variation. training is needed, then
3. A Go Do is something easy and cheap to arrange for training before
implement. beginning the project.
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!