The Nine
Pitfalls of Organizational Change
The Wall St. Journal has many
times reported on the struggling efforts of companies trying to effectively
change their organization. With such national focus on the needs of
organizations to respond to today’s volatile climate, why all the failure? Based on our experience, there
are several significant causes to an organization's change efforts to stumble
or stagnate. You can use this information to avoid these pitfalls, or recover
from them if you have fallen in.
Need-technique mismatch
This problem occurs so often it
isn’t funny any more. A manager hires a consultant to help implement
buzzword X. After conducting a thorough analysis, the consultant says, “You
don’t need X. You need buzzword Y instead. The manager then replies, “That
may be, but I already told my boss that we are implementing X?” A common
example of this is when an organization hires someone to conduct a skills
training course, but the lack of skill isn’t what is causing the
organization’s problems. Many organizations put in one IT system after
another to solve specific issues, but never realize the lack of integration
among the systems they have is the primary cause of their problems.
More fundamentally, however, is
the mismatch that occurs on a larger scale. Organizations often use
small-scale, incremental techniques such as Six Sigma, when instead they need
to evaluate their reactions to future scenarios of a radically changed
business climate. They may need to divest themselves of a money-losing
division instead of pouring more money into an industry that is dying a slow
death.
Not making systemic changes
Management must realize that to
fully implement change, satisfy its customers, and promote teamwork in the
entire organization, often wrenching systemic changes must be made: Profit
sharing may be introduced; individual performance appraisals may be radically
changed or eliminated; organizational structure may be realigned away from
functions (production, quality, engineering) to a customer-, process- or
geographic-based structure; information may be given to employees formerly
reserved for senior management; and significantly more authority may be given
to line employees.
If management does not align
these systems, the effect will be like Dr. Doolittle's Pushme-Pullyou”
animal (a horse with two heads, each pulling in the opposite direction). Each
system (rewards, structure, information, etc.) is tugging the organization in
a different direction. The result will be much struggle and confusion, but
little success.
Overuse of process teams
Some organizations treat Six
Sigma teams (SSTs) like candy: They want dessert before having dinner.
I know of a 3000-person
organization with over 70 current SSTs) working on a variety of issues. The
organization avoids measuring their success, provides them little technical
support, and still has not addressed "dinner" of the systemic
changes (see next section) needed to support them. This implementation
strategy has a high risk of failure, and organizational change will probably
not become an integral part of their culture.
This problem occurs when,
paradoxically enough, an organization achieves successes with its first teams,
or hears about wild successes of other companies. They then buy a canned
training program, or hire a trainer to setup their programs. Much training
occurs and many SSTs formed. With various degrees of management support, these
SSTs attack a variety of problems. Unfortunately, because of unclear long-term
plans, and the lack of system changes, (see next section) many of these SSTs
fail. As a result, the organizational change effort may stagnate, and once
ardent supporters become disillusioned.
In addition, management often
delegates a problem to a team as a way of avoiding hard management or
personnel decisions. For example, one manager in a software company assembled
a SST because the customer complained of too many bugs in the product. In
addition, the manager needed a reporting system to evaluate the progress of
the bug fixes. The SST quickly realized that this was not a
"process" problem, but a personnel problem: One employee of the
manager just wasn't doing his job. The SST knew this, and the manager knew it.
Unfortunately, the manager was unwilling the confront the problem, and hoped
the SST would find away around it.
Not making decisions up
front
Many organizations need to
design the architecture of their quality effort. If they do not, they risk
pouring time and dollars into an effort that will eventually collapse. Among
the decisions that should be made up-front, before implementing a quality
effort are: the measures of success; the degree of employee involvement; the
depth and breadth of implementation; and the techniques to be used. As someone
once said, If you don't know where you are going, you may not like getting
there.”
Caught between the square
peg and NIH diseases
Many organizations buy canned
implementation efforts that describe for them, step by step, what to do. This
square peg approach is often not appropriate for the round hole of the
organization. This kind of effort can often lead to the overuse of SST's and
the problems with mass training (see the section on training).
On the other hand,
organizations can also become infected with the not invented here (NIH)
disease. They insist in reinventing the wheel when it isn't necessary to do
so. I know one consultant who made a lot of money because of this disease. The
rivalry between two manufacturing plants belonging to the same company was so
fierce that they refused to talk to or learn from each other. This is despite
the fact that they were located only a few miles apart. The consultant made
his money by helping one plan with organizational change, and then driving to
the other plant to do the same thing. The secret to implementation is not to
choose between one disease and the other, but to decide what aspects of
implementation can be bought, and what aspects need unique solutions agreed
upon by management and employees.
Mass training
If you wish employees to use
their training, organizations must train them in skills specific to their
needs just in time to use them. Too many organizations have spent untold
thousands of dollars and hours on training employees on concepts they may
never need. If they do need these concepts, they will need refresher courses
because their training was long ago. Because mass training puts such a burden
on organizational resources, not all members of work teams are trained at
once. As a result, some know what to do but others do not, which causes more
confusion.
The no top management
support excuse
Supervisors and line employees
have often complained that they do not receive management support for their
efforts. I believe all parties are at fault for this problem. Management may
not fully realize what they specifically need to do to support SSTs, and SSTs
choose to 1) work on problems that don't interest management or 2) don't get
the proper authority and specific support from management before they start
their efforts. This no management support is caused by unclear or unknown
expectations.
Labelitis
An interesting problem in
organizational change is hero worship. There are Deming worshippers, Crosby
worshippers and Covey worshippers. These cults of personality often get in the
way because any concept not uttered by one's hero is suspect and probably not
true. Organizations can often get into this labelitis by swallowing a buzzword
and avoiding any concept not labeled as such. One example of this happened
earlier this month: A client said he wasn't interested in becoming a “team-based”
organization because it wasn't “Six Sigma.”
Much the same thing has
happened in Latin America with the word “reengineering”. The word has been
misapplied so much that any mention of it is returned by a look of disgust. To
properly implement organizational change, organizations must look beyond the
label, and ask serious questions about what changes are needed and what they
should do about them.
Not measuring results
No only do organizations not
measure results, they often desperately try to figure out if they were
successful after organizational change has already taken place. This is the
messiest way to determine if change happened, because sometimes 1) the data
should have been gathered before the organizational change happened and can’t
be collected afterwards; 2) politics play their role as those asking if the
change was successful may have hidden agendas seeking to either justify what
has already been done or destroy what is taking shape.