Issues & Opinions: Myths About Reengineering

Reengineering:
Business Change of
Mythic Proportions?
By: Thomas H. Davenport
Ernst & Young
Center For Business Innovation
1 Walnut Street
Boston, Massachusetts 02108

U .
S.A.
Donna B. Stoddard
Harvard Business School
Soldiers Fleld
Boston, Massachusetts 02163

U .
S.A .

dstoddard@hbs.harvard.edu

Abstract
Reengineering is a powerful change approach
that can bring about radical improvements in
business processes. However, the popular
management literature has created more myth
than
practical
methodology
regarding
reengineer ing. It has relied more heavily on
hype than on research, common sense, or
lessons of the past. In this paper, we attempt
to "demythologize" some key aspects of
reeingineering by describ ing what we have
observed in our research and practice. Seven
reengineering myths are iden tified, discussed,
and dispelled. By separating rhetoric from
reality, we hope to help others to have
reasonable expectations for success with their
reengineering initiatives.

Business process reengineering has been

touted as the magical elixir that will empower
managers to free themselves from existing
constraints, to "think out of the box" and to
achieve significant benefits. Hundreds of
organizations around the world have begun
reengineering projects. They are inspired to
duplicate the legendary exploits of Ford's
accounts payable department, IBM Credit
Corporation, and Mutual Benefit Life.
Unfortunately, the popular management
literature, by relying too much on hype and too
little on research, common sense, and the
lessons of the past, has created more myth
than practical methodology. Reengineering
has become larger than life. Expectations
frequent ly go unfulfilled, and frustrations that
"we must be doing it the wrong way"
contribute to the failure of many promising
reengineering efforts.
The concept of business process redesign, in
novation, or reengineering has been with us for
about four years, and today is one of the most
popular concepts in business (Davenport and
Short, 1990; Hammer, 1990). It is widely
misunderstood and has been equated to
downsizing, client/server computing, quality,
activity-based costing, and several other
manage ment nostrums of the past several
years. One astute manager has even defined
reengineering as, "any project you want to get
funded." As a result of this imprecision, many
managers
are
pursuing
reengineering
because of its positive press, without truly
understanding what reengineering is. Further,
many have come to re ly on some common
and potentially harmful myths to guide them to
successful completion of their projects.
While the final word on reengineering is
certain ly not in, our remarks are based on
interviews and conversations with more than
200 companies, as well as rigorous research
on 35 reengineering in itiatives (Jarvenpaa and
Stoddard, 1993). As a result of this research
and broad observation, we have identified
seven reengineering myths. These myths
have rhetorical power, and as such, are
powerful tools for the evangelism that has
gripped
proponents
of
reengineering.
Nonetheless, they are fundamentally false. The
myths explored are the following:
1. The Myth of Reengineering's Novelty
2. The Myth of the Clean Slate

MIS Quarterly/June 1994

121

lssun & Opinions: Myths About Reenglneerlng

3.
4.
5.
6.

The Myth of IS Leadership

The Myth of Reengineering vs. Quality
The Myth of Top-Down Design
The
Myth
of
Reengineering
as
Transformation
7. The Myth of Reengineering's Permanence

is more recent than Taylor, but It Is older

than reengineering; witness the value chain
concept (Porter, 1985) or te idea of
design for manufacturing ..

The
Myth
of
Reenglneerlng's Novelty

Radical change In business processes is also

not a particularly novel idea. Both Joseph
Juran and
W. Edwards Deming, known primarily as ad
vocates of more incremental process change,
an ticipated and advocated such change
(Gabor, 1990; Juran, 1964). Furthermore,
several authors preceded reengineering with
the notion of radical improvements in process
cycle time (Bower and Hout, 1988; Stalk and
Hout, 1990).

A quote from management authority Peter

Drucker adorning the cover of the best-selling
book about reengineering (Hammer and
Cham py, 1993) proclaims, "Reengineering is
newl " If reengineering is truly new,
managers may be forced to disregard much
that they have already learned about
business change. This myth of newness can
be tested by examining each of the
components of reengineering.
There are five primary concepts that make up
reengineering:
1. A clean slate approach to organizational
design and change.
2. An orientation to broad, cross-functional
business processes, or how work is done.
3. The need for, and possibility of, radical
change in process performance.
4. Information technology as an enabler of
change in how work Is done.
5. Changes in organizational and human ar
rangements that accompany change In
technology.
Let's consider the novelty of each. Starting from
a "clean slate" Is central to reenglneering
rhetoric, If somewhat mythical Itself (see
below). But It cannot be called new. Making
change through a fresh start as an alternative to
modifica tion of the status quo is common
sense.
Business processes have been with us at least
since the mld-1940s, when they became the
focus of continuous Improvement efforts.
Process analysis really goes back to Frederick
Taylor, who first advocated the systematic study
of work pro cedures (Taylor, 1911). However,
reenglneerlng
proponents
advocate
the
redesign of broad, cross-functional business
processes. This Idea

122 MIS QuartBrly/JunB 1994

There is a long history to both technical and

human/organizational "enablers" of change in
processes. The idea that computers and com
munications could change the way work was
done, and were only valuable if they did so, has
been argued almost from the beginning of the
systems analysis role in the 1950s and '60s.
And the awareness that technological changes
should be accompanied by changes In
organizational structure, policies, and human
resource manage ment approaches has been
well known since the socio-technical school at
the Taavistock Institute in the 1950s (Chems,
1976).
So what is new about reengineering? It is
that familiar concepts are combined in a new
syn thesis. These key components have
never been together before, not in quality nor
socio-technical design nor systems analysis
nor anything else. Unfortunately, as we will
show, most popular writers on reenglneerlng
have ignored its historical roots; therefore,
some important ideas have been forgotten.
Since reengineerlng is a combination of
known elements, traditional management
wisdom should apply. As a syn thesis of
several approaches, reengineering Is a very
ambitious approach to change. But, while it
may contribute to the popularity of a concept
to suggest that It Is new, to ignore
historical
antecedents
strengthens
the
arguments of those who view reengineerlng as
a fad.

The Myth of the Clean Slate

"Don't automate, obliterate!" (Hammer, 1990).
The suggestion Is for firms to throw away all
ex isting processes, activities, systems, people,
etc. By throwing away these troublesome
assets and building a new environment from
scratch, firms

Issues & Opinions: Myths About Reengineering

would find solutions that were expected to be

less expensive and more effective than if they
worked "within the box."
In practice, clean slate change is rarely
found. A "blank sheet of paper" used in
design usually requires a "blank check" for
implementation. "Thinking out of the box" can
lead to "spending out of the box." Most firms
are not willing to com mit the resources-both
money and time-to im plement from a clean
slate. One firm we studied, for example,
developed a very innovative new process
design for its order management pro cess.
Management discovered that to implement the
"clean slate" process would require portable
workstations for all salespeople, a packet
radio network, replacements for legacy
systems, new skills, and many new people.
The total estimated cost to build and operate
this process over seven years was $1 billion.
Although the return on this investment was
conservatively estimated to be very high,
managers believed the firm could not afford
the investment.
One approach to clean slate implementation
is to implement the new designs by opening
a new location. However, such "greenfield"
sites can be expensive. An insurance
company opened a new office where the
employees, the culture, the information
systems, and the real estate were to reflect
the values and priorities associated with the
clean slate design. It took the organization 24
months to open the new office, and even
then, the systems they needed were not
available. Employees who had to be kept
busy when the project was delayed spent 12
months in training rather than the planned
three months. When the office opened,
management found that custo mers liked the
new approach to service but the financial
viability of the clean slate design could not be
demonstrated.
So what do firms do when they cannot afford
clean slate change? First, they make a
distinc tion between clean slate design and
clean slate implementation. Clean slate
design-creating a detailed vision for a
process without concrn for the existing
environment- ls not particularly ex pensive.
Many firms have found that it is useful to
have a "best-of-all-processes" world to which
they can move, even if the movement is
piece meal over several years. As one

manager noted, "You can design assuming a clean slate, but you
must Implement assuming the existing state."

His
firm
breaks
implementation
into
several
proj
ects,
beginning with those
that offer the most im
mediate benefit. Just
as
product
developers focus on
"design
for
manufacturability,"
process
developers
must consider the
implementabilty
of
process designs.
Alternatively,
designers could start
with a "dirty slate."
Designs could take
into account the op
portunities
for
enabling the new
process
(new
technology,
skills,
organizational
structures) as well as
the constraints that
disable it. With both
design elements in
mind,
the
design
team could construct
the best possible
process given the
enablers and the
constraints. Whereas
this is a less exciting
and more difficult
design
method,
designing with a "dirty
slate" will normally
yield
a
more
implementable
process.

The Myth of IS Leadership

Our research shows that IS organizations
often introduce reengineering in their
organizations. A systems planning or data
modeling project fre quently provides the
genesis
for
reengineering
as
the
organization becomes aware that a plan ning
process focusing primarily on systems may
not deliver the business solutions it needs.
When asked why reengineerlng had become
a major agenda item, the CIO of a major
insurance com pany responded:
In the late 1980s, I began to look at
how technology was !Inked to our overall
corporate strategy. Itried to assess how new
appllcatlons Impacted the enterprise; my
Intuition was that we were Investing a lot
but not getting the desired productivity. As
Ibegan to focus on what we were doing, It
was clear that, generally, we did not
change the processes that were being
automated. Rather, we took sophisticated
ap plications and layered them onto an
old organization. I began to envision a
need to reenglneer. Further, I recognized
that In all of our years of focus on the
technology, It was as If we had been
looking through the wrong end of the
telescope. IS personnel needed to focus on
processes, not technology (Jarvenpaa and
Stoddard 1993, p. 2).

However, there comes a point when IS must

relin
quish its leadership role. Most
managers with

MIS Quarterly/June 1994

123

Issues & Opinions: Myths About Reengineering

reengineering experience whom we have inter

viewed stress the importance of a partnership
between IS and the managers associated with
the business process being redesigned. Many
emphasized the desirability of a non-IS
business sponsor with responsibility for the
entire process and a champion or project
leader (also usually non-IS) who works with a
cross-functional team that includes IS.
Whereas IS may be a key enabler of the new
approach
to work, other organizational
changes, including changes to structure,
training, role definition, and culture, must
ensue to facilitate a new process. In short,
there is much about reengineering that can
never be under the control of the IS function.
Perhaps the most important ongoing IS role is
to avoid being an inhibitor or disabler to
reengineering, either because of the lead time
to develop new systems or because of
difficulties in modifying existing ones. In the
insurance com pany described earlier, after
24 months was devoted to developing a pilot
information system to support the "greenfield"
office, it was discovered that the new system
could not be scaled up. In another company,
the "clean slate" design assumed that
advanced
IT-based systems, such as
groupware, expert systems, and a single
system image, would provide seamless
access to legacy systems. The lead time to
bringthese new capabilities in-house was long,
however, and the pilot design had to be
modified to include structures and human
systems that were not dependent on the ad
vanced IT capabilities assumed in the original
clean slate design. In this case and many
others, information systems were the biggest
barrier to rapid and radical change.
The myth that IS should lead reengineering
often
leads to IS managers starting
reengineering proj ects only to discover that
the required changes to implement the
redesigned process are com pletely outside
of their sphere of control. IS is clearly an
enabler of reengineering. In fact new
organizational roles associated with the rede
signed process often cannot be implemented
un til employees can access new sources or
domains of information. However, our
experience suggests that IS partnership with
business
managers,
rather
than
IS
leadership of reengineering, is generally a
key to successful reengineering.

124 MIS Quarterly/June 1994

The Myth of Reengineering

vs. Quality
A popular management nostrum prior to
reengineering was quality or continuous
process improvement. Reengineering has
been viewed as competitive with quality-not
only qualitatively different from, but better
than, quality. Hammer and Champy (1993),
note that:
Marginal improvements, as a rule, further com
plicate the current process, making it more dif
ficult to figure out how things really work. Even
worse making additional investments of time or
capital into an existing process only discourage
(sic) management from dumping that process
down the road. Most perniciously, taking in
cremental steps further reinforces a culture of
incrementalism, creating a company with no
valor or courage (p. 205).

Are the improvements, incremental steps, and

in vestments of time or capital into an
existing process-steps synonymous with
quality undesirable? Most of the firms we
have studied don't think so. They believe that
no single ap proach to organizational
change,
including
reengineering,
is
appropriate for all cir cumstances. Many
companies have a portfolio of approaches to
operational change including reengineering,
continuous improvement, in
cremental
approaches, and restructuring tech niques.
Some combine multiple approaches in one
initiative-for example, using reengineering for
a long-run solution and short-term process im
provements in the current process to deliver
quick
benefit.
More
specifically,
a
communica tions company designed a single
best process for order fulfillment, but the
different regional business units implemented
it on a piecemeal basis, adopting first those
aspects of the design that addressed their
most P essing problems.
In the future, we expect that firms will routinely
assemble
a
customized
approach
to
operational change. They will assess their
need for change and the current environment,
and then combine tools from the various
traditional approaches, e.g., root cause
analysis from quality, process value analysis
from focused improvement ap proaches, and
IT enablement from reengineer ing. In the
meantime, reengineering advocates will reap
little advantage by disparaging other, quite
valid approaches to organizational change.

Issues & Opinions: Myths About Reengineering

The Myth of Top-Down

Design
Reengineering was originally viewed as a form
of work design that had to be completely top
down. Because the process being addressed
is usually broad, the thinking goes, only a
small group of high-level process designers
can analyze its entire breadth. One of us
wrote previously, for example, that, "Because
large firms' structures do not reflect their
cross functional processes, only those in
positions overlooking multiple functions may be
able to see opportunities for innovation"
(Davenport, 1993,
p. 12). Again, there is some truth to this myth;
innovative designs for broad processes are
unlikely to come from anyone whose head is
buried deep in the bowels of the existing
process. High-level design, including the
overall flow of the process and its subprocesses, performance ob jectives, and
inputs/outputs, must be done by a small
design team that studies the process in its
entirety and considers relevant enablers and
benchmarks in its design. Even in such design
teams, however, all members need not be high
in the organizational hierarchy themselves.
More important, the design of the more detailed
process activities and flows can be done by
those who do the work. In fact, we have
observed several post-reengineering work
execution teams that paid little attention to the
prescribed process design, at least partly
because they had no hand in its creation. Most
people do not want their jobs fully designed by
someone else. What made us believe that a
small group of smart people at headquarters
could design work in detail for others, who
would then slavishly adhere to that design?
Not since Frederick Taylor has the design of
work been so separated from its execu tion.
Further, as Drucker (1991) states, "Now, while
still far from being widely practiced, it is at
least generally accepted in theory that the
workers' knowledge of their job is the starting
point for improving productivity, quality, and
per formance" (p. 70).
Part of the problem with reengineering as it
is classically understood is that it ignores
much of what we have previously learned
about the value of participative work design, at
least for the details of a business process.
The concept has ap peared in the sociotechnical ("minimum critical

specifications"), work redesign, and continuous

improvement
literatures
(Hackman
and
Oldman, 1980; Imai, 1986; Pava, 1983). While
participative design has its shortcomings
(e.g., a more cumbersome change process,
the need to tolerate variations in detailed work
processes),
the
greater
likelihood
of
ownership of the work design is usually worth
the trouble.

The Myth of Reeingineering

as Transformation
Another common myth is that reengineering is
an approach that organizations can use to
total ly reinvent themselves. Some view
reengineer
ing
as
synonymous
with
organization transformation (Hammer and
Champy, 1993).
Organizational transformation (OT) is defined
as, "Profound, fundamental changes in thought
and actions, which create an irreversible
discontinuity in the experience of a system"
(Adams, 1984, p. 278). OT is generally the
result of the emergence of radically new belief
systems. OT necessarily involves reframing,
which is a discontinuous change in the
organization's or group's shared meaning or
culture. It also involves broad change not only
in work processes, but also in other
dimensions of organization, such as organiza
tional structure, strategy, and business
capabilities. Some writers are beginning to
discuss the concept of the horizontal organiza
tion in which reengineering is institutionalized
and business processes are the primary focus
of organizational structure (Byrne, 1993; Ostroff
and Smith, 1992; Stewart, 1992). We have not
ob served this type of organization in actual
prac tice. Some firms are beginning to create
hybrid structures, adding a process dimension
to their existing functional structures.
Reengineering is a process that can contribute
to transformation, but it is not synonymous with
transformation. Our observations suggest that
those
organizations
that
approach
reengineering with the intent of business
transformation typical ly start by defining the
seven or more core pro cesses of the
business.
The
zealous
ones
start
reengineering projects for each identified pro
cess. We know of no cases of success with
this broad-brush approach. The primary
reason for failure is that the organizations tried
to change all processes at once, and often at a
time when

MIS Quarterly/June 1994

125

Issues & Opinions: Myths About Reengineerlng

markets,
products,
and
organizational
structures were also changing dramatically.
Managers were simply unable to devote
sufficient management attention to all these
Initiatives. This was the early experience of
IBM and Xerox In reengineering, though they
later focused their efforts on a small number of
key processes (Davenport, 1993). The most
successful organizations identify which pro
cesses need most attention and attempt to
make changes In those first, while preparing
the rest of the organization for changes that
may subse quently occur.
In summary, while some emerging literature
does attempt to place reengineerlng in a
broader con text of transformation in how firms
go to market (Davidson, 1993; Venkatraman,
1994), we believe reengineering is not
synonymous
with
total
organization
transformation.
It
Involves
at
best
transformation of a few work processes at any
given time, and there is much more within
organizations that can be transformed.

The Myth of Reelnglneering's

Permanence
Some advocates of reengineering argue that it
is here to stay. But like all popular management
notions, reengineering will have a life cycle
(Pascale, 1990). Our guess is that it peaked
in early 1994 in the United States, and is still
in creasing in popularity elsewhere in the
world. In evitably, reengineering books will
disappear from the best-seller lists, and new
management en thusiasms will emerge. At the
same time, given the great need for business
change enabled by information technology and
organizational in novations, the need for
reengineering shall un doubtedly remain.
We see three options for reengineering's future.
One is that another synthesis of ideas will
emerge that includes the precepts of
reengineering, along with others (see the
"myth of reengineering's novelty" above). The
second alternative is that reengineering will
be absorbed into existing change methods,
e.g., strategic planning or in formation system
development. There is already evidence that
this is occurring; strategic planners discuss
reengineering at planning forum con ferences
and in the pages of Planning Review (see, for
example, Ramcharandas, 1994), and several
providers of system development

methodologies are beginning to include tech

niques for reenglneering processes before
building systems.
The third option Is for reengineering to be com
bined with quality and other process-oriented
Im provement approaches into an integrated
process management approach. This is the
out come we prefer; under such an
environment firms would be able to combine
the best of multi ple operational analysis
methods. It is likely that all three of these
options for the future will be realized in some
combination.

Conclusion
Reengineering
Is a powerful change
phenomenon and an approach that has enabl
ed organizations to realize radical process im
provements. In this paper, we have attempted
to demythologize some Ideas about
reengineering by describing what we have
observed in our research and practice. Knowing
how reengineer ing usually works in actual
practice will help to prevent miscommunication,
frustration, and over ly ambitious change
programs.
Reengineering has Its
roots in IT
management. However, it has become one of
the most widely discussed and practiced
management phenomena of the 1990s. As
we encourage organizations to engage in
reengineering, we must remember that
successful reengineering is not an IS initiative.
Rather, it is a business in itiative that will
have broad consequences as we rethink and
restructure our businesses to satisfy the
needs
of our customers and
other
constituents.
Reengineering is important and more than
just another management fad. We have
seen a number of successful reengineering
initiatives (the exact number depends on
exactly how suc cess is defined) as well as
many failures. By at tempting to clarify what it
is and what it isn't, we hope to enable others
to have reasonable-and therefore more
attainable-expectations for suc cess with
their reengineering initiatives.

References
Adams, J.D. Transforming Work, Miles River
Press, Alexandria, VA, 1984.

126 MIS Quarterly/June 1994

. j *: 'J
'

Issues & Opinions: Myths About Reengineering

Bower, J. and Hout, T. "Fast Cycle Capability

for Competitive Power," Harvard Business
Review (66:6), November-December 1988,
pp. 110-118.
Byrne, J.A. "The Horizontal Organization,"
Business Week, December 20, 1993,
pp. 76-81.
Cherns, A. "The Principles of Sociotechnical
Design," Human Relations (29), 1976,
pp. 783-792.
Davenport, T.H. Process Innovation, Harvard
Business School Press, Boston, MA, 1993.
Davenport, T.H. and Short, J.E. The New In
dustrial Engineering: Information Technology
and Business Process Redesign, Sloan
Management Review (31:4), Summer 1990,
pp. 11-27.
Davidson, W.H. "Beyond Re-engineering: The
Three Phases of Business Transformation,"
IBM Systems Journal (32:1), 1993, pp. 65-79.
Drucker, P.F. "The New ProductMty Challenge,"
Harvard Business Review (69:6), November
December 1991, pp. 69-79.
Gabor, A. The Man Who Discovered Quality,
Times Books, New York, NY, 1990.
Hackman, J.R. and Oldham, G.R. Work
Redesign, Addison-Wesley, Reading, MA,
1980, pp. 231-235.
Hammer, M. "Reeingineering Work: Don't
Automate, Obliterate," Harvard Business
Review (68:4), July-August 1990, pp. 104-112.
Hammer, M. and Champy, J. Reeingineering
the Corporation, Harper Business, New York,
NY,
1993.

Imai, M. Kaizen, McGraw-Hill, New York, NY,

1986, pp. 94-124.
Jarvenpaa, S. and Stoddard, D.B. "Business
Pro cess Reengineering: Tactics for
Managing Radical Change," working paper,
Harvard Business School, Boston, MA,
1993.
Juran, J. Managerial Breakthrough: A New
Con cept of the Manager's Job, McGraw-Hill,
New York, NY, 1964.
Ostroff, F. and Smith, D.K. "The Horizontal
Organization," McKinsey Quarterly (1), 1992,
pp. 148-168.
Pascale, R. Managing on the Edge, Simon and
Schuster, New York, NY, 1990.
Pava C. Managing New Office Technology, The
Free Press, New York, NY, 1983.
Porter, M. Competitive Advantage, The Free
Press, New York, NY 1985.
Ramcharandas,
E.
"Xerox
Creates
a
Continuous Learning Environment for
Business
Transfor
mation,"
Planning
Review, March-April 1994, pp. 34-38.
Stalk, G. and Hout, T. Competing Against Time,
The Free Press, New York, NY, 1990.
Stewart, T.A. "The Search for the Organization
of Tomorrow," Fortune, May 18, 1992,
pp. 92-98.
Taylor, F.W. Principles of Scientific Management,
Harper & Row, New York, NY, 1911.
Venkatraman,
N.
"IT-Enabled
Business
Transfor mation: From Automation to
Business Scope
Redefinition,"
Sloan
Management Review (35:2), Winter 1994,
pp. 74-88.

MIS Quarterly/June 1994

127

Issues & Opinions: Myths About Reengineering

reengineering experience whom we have inter

viewed stress the importance of a
partnership between IS and the managers
associated with the business process being
redesigned. Many emphasized the desirability
of a non-IS business
sponsor with
responsibility for the entire process and a
champion or project leader (also usually
non-IS) who works with a cross-functional
team that includes IS. Whereas IS may be
a key enabler of the new approach to work,
other organizational changes, including
changes to structure, training, role definition,
and culture, must ensue to facilitate a new
process. In short, there is much about
reengineering that can never be under the
control of the IS function.
Perhaps the most important ongoing IS role
is to avoid being an inhibitor or disabler to
reengineering, either because of the lead
time to develop new systems or because of
difficulties in modifying existing ones. In the
insurance com pany described earlier, after
24 months was devoted to developing a pilot
information
system
to
support
the
"greenfield" office, it was discovered that
the new system could not be scaled up. In
another company, the "clean slate" design
assumed that advanced IT-based systems,
such as groupware, expert systems, and a
single system image, would provide
seamless access to legacy systems. The
lead time to bring these new capabilities inhouse was long, however, and the pilot
design had to be modified to include
structures and human systems that were
not dependent on the ad vanced IT
capabilities assumed in the original clean
slate design. In this case and many others,
information systems were the biggest barrier
to rapid and radical change.
The myth that IS should lead reengineering
often leads to IS managers starting
reengineering proj ects only to discover that
the required changes to implement the
redesigned process are com pletely outside
of their sphere of control. IS is clearly an
enabler of reengineering. In fact new
organizational roles associated with the
rede signed process often cannot be
implemented un til employees can access
new sources or domains of information.
However, our experience suggests that IS
partnership with business managers, rather
than IS leadership of reengineering, is
generally a key to successful reengineering.

124 MIS Quarterly/June 1994

The Myth of Reengineering

vs. Quality
A popular management nostrum prior to
reengineering was quality or continuous
process improvement. Reengineering has
been viewed as competitive with quality-not
only qualitatively different from, but better
than. quality. Hammer and Champy (1993),
note that:
Marginal improvements, as a rule, further
com plicate the current process, making it
more dif ficult to figure out how things really
work. Even worse making additional
investments of time or capital into an existing
process only discourage [sic] management
from dumping that process down the road.
Most perniciously, taking in cremental steps
further
reinforces
a
culture
of
incrementalism, creating a company with no
valor or courage (p. 205).

Are the improvements, incremental steps, and

in vestments of time or capital into an
existing process-steps synonymous with
quality undesirable? Most of the firms we
have studied don't think so. They believe
that no single ap proach to organizational
change, including reengineering, is
appropriate for all cir cumstances. Many
companies have a portfolio of approaches to
operational change includins reengineering,
continuous improvement, in cremental
approaches, and restructuring tech niques.
Some combine multiple approaches ir one
initiative-for example, using reengineerin1 for a
long-run solution and short-term process irr
provements in the current process to delivE
quick benefit. More specifically, a communici
tions company designed a single best proce
for order fulfillment, but the different region
business units implemented it on a pieceme
basis, adopting first those aspects of the
desi! that addressed their most pressing
problemi
In the future, we expect that firms will
routin assemble a customized approach to
operatio1 change. They will assess their
need for char and the current environment,
and then comb tools from the various
traditional approach e.g., root cause
analysis from quality, proc value analysis
from focused improvement proaches, and
IT enablement from reengin ing. In the
meantime, reengineering advoc: will reap
little advantage by disparaging ot quite valid
approaches to organizational cha

---