Joe's Jottings
Jottings Number 58, by Joe Podolsky:
From: JOE_PODOLSKY@HP-PaloAlto-om4.om.hp.com
Date: Wed, 10 Jul 96 16:05:48 -0700
Subject: The Reality of Business Reengineering
One of the real frustrations of business reengineering is that
it is consulting intensive. That makes it expensive, but more
to the point to this discussion, consultants tend to talk in
anecdotes at best and hyperbole at worst. Data rich, objective
analyses are drowned out by the thunder of Mike Hammer's cute
Yogi Berra quotes.
So, I was happy to read an article in the Spring 1996 issue of
_California Management Review_ by Donna B. Stoddard, a professor
at Babson College, and Sirkka L. Jarvenpaa, a professor at the
University of Texas objectively examining a "successful"
reengineering project. Along with Michael Littlejohn of Pacific
Bell, they wrote the article entitled, "The Reality of Business
Reengineering: Pacific Bell's Centrex Provisioning Process."
This Pacific Bell project is the first completed of 12 projects
being studied in 8 different organizations. While the results
of the other projects are still pending, the two professors feel
comfortable with publishing the Pacific Bell findings. "Because
of the representative nature of the project, the Pacific Bell
Centrex reengineering initiative allows us to begin to refine
the concepts and theory of reengineering."
The authors make clear that this project is considered a success
by all concerned, even though the total implementation time took
almost twice the 18 months originally planned. "Each of the
(seven) regions that implemented a variation of the new Centrex
design realized cost reductions of 30 - 50 %, errors were
reduced by 20 % or more, service was delivered when the
customers wanted it 99 % of the time, and customer satisfaction
ratings were 90 % or higher." (The "before" numbers on service
delivery and customer satisfaction were not shown in the
article.)
The project sponsors and managers had, however, several critical
assumptions that were dashed by reality. Here is what Pacific
Bell learned:
1. Assumption: Reengineering results in radical change.
Reality: Reengineering design may be radical, but
implementation is incremental.
Pacific Bell assumed that the process "outcomes" would be
dramatically improved, "...achieving quantum leaps in
performance..." The "accomplishments of the implemented
processes were quite a bit more modest."
Likewise, the original assumption was that the changes could be
made quickly. "When the Centrex redesign team started,
management assumed full implementation of the new design by
1993." In reality, "At the end of 1993, five regions had (only)
pilots underway and the other two regions were (only) planning
to start pilots in 1994." Barriers encountered were labor
issues, time for regions to understand and accept the new
design, training issues, and lead time for the new IT-based
applications.
2. Assumption: Reengineering assumes clean slate change.
Reality: The design may assume clean slate change, but the
actual implementation is limited by those constraints that
management cannot or will not remove.
Real world constraints included reluctance to change the
organization structures, difficulty in implementing new job
definitions (in part because of resistance from local union
groups), lack of IT support to modify legacy systems, and
(ironically for a telephone company) lack of the communication
technology needed to support the virtual teams that were part of
the design.
3. Assumption: Reengineering focuses on end-to-end processes:
Reality: Reengineering design may focus on end-to-end
processes, but implementation often focuses (only) on the
perceived most broken pieces.
During actual implementation, each region sought the "low
hanging fruit." These first efforts were different in each
region, resulting in different new processes in each region,
thereby minimizing enterprise-wide leverage and requiring
(expensive) regional-specific support. "Each of the 5 pilot
regions modified the design in light of some unique
characteristic of the region or some management constraint."
4. Assumption: Reengineering is top-down directed.
Reality: The design may be top-down directed, but the
implementation must be owned from the bottom up.
"Whereas top-down goals and objectives created the motivation
for reengineering, bottom-up acceptance of the design drove
implementation success...The actual implementation of Centrex
reengineering was a business unit decision, not a corporate
initiative...The void of a corporate... mandate resulted in each
region developing its own 'case for action' before proceeding
with implementation."
5. Assumption: Reengineering is information-technology enabled.
Reality: The design may be IT enabled, but the
implementation can be initiated without much of the assumed IT
capability.
"Since the lead-time to develop the advanced-IT applications and
to interface them to the 10-12 legacy systems were long and
costly, human systems and structures were developed...that were
not dependent on the most advanced IT capabilities assumed by
the original design." In fact, "Pacific Bell was able to gather
(new) systems requirements in light of the experiences with the
new work roles and (manual) procedures."
The lessons from this Pacific Bell project are, to me at least,
very clear:
1. Design may be grand and sweeping, but plan and prepare for
the reality of incremental and locally specific implementation.
2. Given that the implementation is going to be gradual, it
makes sense for the designers to make use of this reality and
use a spiral life cycle approach to both the process and IT
design. Build - pilot - learn - rebuild is the way to go.
3. Process reengineering, no matter how sweeping, is, at its
root, a people process. IT can and must help, but even the IT
issues must be viewed from the effect the systems have on the
sociology of the workplace.
How do your experiences match with this Pacific Bell case study?
What other lessons have you learned that should be added to
these three?
Regards,
Joe