The BPR Strike Force
By Bill Roberts
Steps in a Successful Pilot Project
Designing a pilot project is the best way to launch business process
reengineering. In today's climate, the result has to be flexible and pay
DHL Worldwide Express had a problem. Its customers--mostly manufacturers,
suppliers, retailers and others that use DHL as their shipper--wanted to
give their own customers more control and more interaction with the shipping
process. So about a year ago DHL, based in Redwood City, CA, launched a
pilot project to develop desktop software that would make it easier for
the end users to place and track orders being shipped. To do this, DHL needed
to understand its own business processes, as well as the processes of its
customers and its customers' customers.
Throughout the summer of 1995, the project progressed, according to Alan
Boehme, director of customer access at DHL and the business-side "owner"
of the reengineering project. "We built a prototype for the client
side," he says. "Three months later we had a good working prototype,
brought it out, did some focus groups, let people play with it, got some
feedback and were getting ready to kick off the project."
But during the few months it took to get the prototype done, things changed.
The client prototype was a PC desktop solution based on Intel processors
and Microsoft Windows, with a bank of modems at DHL that would field all
incoming queries from the two tiers of customers. By the time DHL was about
ready to roll it out, the Internet was gaining currency in corporate America
for online commerce of all kinds. DHL began to wonder if it had just reinvented
the dodo bird, but all was not lost. "We put one of our architects
on it, and he came up with an Internet-based solution, still using components
that will be resident on the desktop in the Wintel environment," says
Boehme. "That led us back into process reengineering efforts that needed
to be done throughout the host system to support the business requirements
of getting this tool out there. We're now going toward a partial Internet-based
Welcome to the pilot project of the 1990s. No longer can IS analyze every
little detail, draw up reams of specifications, build prototype upon prototype,
and test and revise until delivering, maybe two years later, a product the
end user might want. Forget those pilot projects; they are no more. "I
haven't even heard the term in ages," says Peter Kovacs, first vice
president for technology at Republic National Bank in New York City. "We
don't do pilots any more. Conceptually there is something called a pilot,
but people want value. Everything has to be done in a short time frame.
Even a 12-month project is measured in daily deliverables."
Accustomed to the old development model, many organizations still put the
cart before the horse. "The mistake I see some people make is starting
off with giant, multimillion-dollar projects, and they really haven't got
their feet wet with the technology," says Michael Prince, CIO of clothing
retailer Burlington Coat Factory Warehouse in Burlington, NH. "The
purpose of a pilot project is to do a safe test and also to create a structured
learning opportunity. You've got to experience the technology yourself to
understand what the issues are." Prince's most recent experience with
pilot projects was an order-entry system and a distribution center management
package, both of which were identified as early wins for an overall migration
off the mainframe to a client/server environment.
In the 1990s, pilot projects are about focusing on end-user needs to produce
a deliverable fast--within 90 or 120 days--that will do maybe 80 percent
of what it's meant to do and is viewed as an early phase in a much broader
business process reengineering (BPR) effort. It is a commonplace in today's
rapidly changing, market-driven business environment that business users
demand software and systems that give them the competitive advantage they
need to attract and retain their customers. To get that advantage, the users
must be involved in the planning; the early phase of the project must be
iterative; it must deliver a result quickly; it must be flexible and proactive
in evaluating changing technologies; and it must actually work.
This last requirement, as old IS hands can tell you, hasn't always been
observed. Now there is no room for noble experiments that fail. Experts
unanimously agree that if a pilot test or pilot phase is not carefully chosen,
planned and implemented to produce a successful result, the organization
may lose forever a chance to proceed further into more costly phases of
badly needed BPR. No matter how big or how small the pilot, business users,
top management and especially chief financial officers all expect anything
IS does to pay off in some way. "You never get a second chance to make
a first opinion," says Nick Galambos, a national partner in charge
of operations improvement consulting for KPMG Peat Marwick, based in Radnor,
PA, and a veteran of many reengineering efforts.
A Quick Strike
Galambos prefers the term quick strike to pilot project. "In
one of our quick strikes, you'd want something done in 20 to 24 weeks,"
he explains. During that time, the project team first must understand the
larger reengineering situation, map out the business process that will be
impacted and make sure it understands all relevant subprocesses. Whatever
the team chooses to do first, it should be a project that will make a difference
for one or more of those processes. The point is to get a success under
your belt so you can move on to larger efforts that potentially can have
enterprise-wide impact. "Once you've completed the pilot you've got
credibility," Galambos says. "As you go through BPR using people,
process and technology to make a major change to the way business is done,
you've already bought yourself some time with your success."
Ron Baker, vice president of enterprise system solutions for Massachusetts
Mutual Life Insurance in Hartford, CT, believes that the concepts of using
a pilot phase and prototyping are critical in BPR, especially when you're
dealing with user interfaces and workflow processes. "The business
community owns their work process. They need to," he says. "It's
what they live with, day in and day out, and it affects them in a personal
way as well as in a business way. Getting their involvement is critical
to successful delivery of these changes. In many cases, you're affecting
a culture, too--a way that we've always done it. The people who are doing
that process are usually the ones who know best how to change it."
Baker's most recent experience was a project in which his company developed
a series of templates to automate a system for producing business correspondence
on demand. That might sound like a small effort, but it underscores one
of Baker's other beliefs. "You need to work with manageable increments
of change--to bite off something of reasonable size that has a focused business
deliverable." In this case, the bigger picture called for spreading
the system throughout the enterprise after designing it and rolling it out
in the customer service sector. Had it stopped with customer service, it
would still have saved time and energy for end users.
Baker also believes that it's important to sell the business benefit of
the project to executives so they actively support the effort. Otherwise,
they may not approve freeing up the time of the business end users to work
on the pilot and lend their involvement, which is necessary for its success.
"It's absolutely critical to have business people involved in the design
and planning of the business process changes as well as the system changes,"
he says. "One way to include them is to build a pilot and have joint
participation between the business community and the technology development
community. That will give you useful and critical insight into whether the
process works, whether it's effective or not, and whether the system that's
going to support the process meets the business requirements and has corporate
usability built into it."
Fooling the Customer
To reiterate, before beginning a pilot project, there are at least four
rules of thumb to apply. The business reengineering project and the pilot
itself should be driven by some business need in the broadest sense; the
particulars should be driven by end users; however, there must be consensus
among all parties to the project--managers, end users and IS staff; and
results must be available in a short time--no more than 90 to 120 days.
The reengineering project of AlliedSignal Aerospace illustrates these points.
It's a division of $5.5 billion AlliedSignal Corp., a maker of aerospace,
automotive and engineered materials such as fibers and laminates. The aerospace
division, based in Torrance, CA, is the largest supplier of wheels, brakes,
controls systems, avionics and similar components to the aerospace industry.
It was once organized as a set of entrepreneurial companies unrelated to
each other. But dealing with such a highly decentralized organization was
onerous for customers. As AlliedSignal Aerospace began to study the problem,
many hurdles became apparent, not the least of which was 26 different order-entry
systems throughout the global division. "The initial driving force--the
business problem--was customers telling us they wanted to deal with another
sort of order system," says Paul Hoedeman, vice president and CIO of
the division. "We wanted to fool people into thinking we were easy
to do business with, but we didn't want to go back and change everything
from the bottom up. We wanted all the order-entry systems to look the same
to the customer."
This was the right way to initiate the reengineering process, which began
about 18 months ago, according to Allen Shaheen, vice president of western
operations for Cambridge Technology Partners (CTP), a consulting firm based
in Cambridge, MA, which was commissioned to help AlliedSignal Aerospace
through the process. "I've seen far too many projects that get enthused
with whiz-bang technology in search of a business problem," he says.
In the jobs CTP undertakes, "We're looking for a succinct statement
of a business problem."
AlliedSignal also was careful to involve end users from the outset to help
identify the problems they face in doing their job and ways to make it easier,
and to clarify priorities. "We got the business people to talk about
what they wanted, and we developed a matrix," Hoedeman recalls. "On
one axis we had the functionality people thought would be nice, on the other
axis the business payoff. We could tell where the biggest payoff was. We
carved out nine areas of functionality."
This illustrates another point: The AlliedSignal team reached consensus
on the goals it was trying to achieve. At this stage, CTP consultants wanted
all the players to put their issues on the table. These could be argued
over, hashed and rehashed. But once goals were agreed upon, the goals themselves
became the referees in future disagreements.
From the matrix, Hoedeman says, they were able to set priorities based on
the business payoffs. He says the biggest and quickest would come from inventory
visibility: the ability from any location in the world, regardless of what
order-entry system was already in place, to see a particular part number
on whatever system it happened to reside. The technology solution to this
focused business problem was a new front end on top of the existing, unchanged
infrastructure. "We needed a quick way of going out and querying what
was out there," Hoedeman says.
The team broke this down further into small deliverables or modules. The
first of these modules were delivered in about three months, which was essential
to showing success and keeping everyone, including executives, happy with
the project. "You've got to deliver something of business value within
a short period of time; otherwise users get bored and the business changes,"
says Shaheen of CTP. "In the current state, people are far more accepting
of getting something sooner that's less perfect than they are waiting two
years for something perfect."
This pragmatic viewpoint frequently is articulated in the 80-20 rule: In
three months, you should be able to deliver 80 percent of the functionality.
The rest can follow over time--or, in some cases, never. Brian Bouren, vice
president of marketing for the Axiom division of CTP, says that it may take
20 percent of the total time to achieve 80 percent of functionality "and
the final 20 percent will take 80 percent of the time." With business
needs changing so fast and so often, 80 percent of the whole may well be
enough, especially when you factor in these costs in time and money.
AlliedSignal has now delivered several modules. Hoedeman no longer thinks
of that first piece as a pilot project. Rather, "it's more organically
part of the whole" BPR effort.
Accomplishing the Mission
Once you understand the core business problems, the real work begins. A
statement of the goals should grow out of the analysis of the business problem.
Then all the key stakeholders should meet and scope out the project together.
This is the time to define key scenarios that drive the business problem
and look into how current technologies and the organization's IT architecture
fall short in addressing them. From here you can begin to devise an implementation
While moving forward, build a real team of end users, business-unit owners
and IS staff who must work together to successfully complete the pilot.
Setting goals and beginning to work on the implementation plan are opportunities
to solidify that team. Devising two or more prototype solutions on paper
can be useful at this stage. This phase helps to crystallize the understanding
of all involved of the problem and the goals. Hidden disagreements may surface
and be used as an opportunity to gain full commitment to the project's goals
by all team members.
With commitment and understanding comes momentum, which will be necessary
in the upcoming tedious activity of going through all the business rules
involved and determining the best end-user design and the best technology
design. The end-user design ensures that all the detailed requirements are
For the technical design, the IS staff takes over and starts translating
all the above planning into user screens and supporting technology. This
should be a highly iterative process. IS or outside consultants design something,
show it to end users, get their input, then redesign accordingly. As disagreements
arise, reexamine the business case and the goals and priorities. In this
way, you're refining and prioritizing along the way.
Once the heavy development phase is under way, an important aspect of the
process is to hold regular (weekly or more frequent) stakeholder meetings
to monitor status and make decisions. At the same time, begin the broad
preparation of the user community--for example, communication, demos and
training. This helps to establish checkpoints at which you present progress
to a broader user community. The end users come back into the picture more
actively when you start to test the system. You'll know you've tested enough
when the users are satisfied that it will meet their business needs. Once
the system is in the users' hands, your pilot project is complete.
Throughout the process, don't forget the basics of good project management.
Bill Puig, senior manager at consultant Ernst & Young's center for technology
enablement in New York City, underscores the importance of such basics as
source code control, change management procedures and database administration.
"I like to see an environment where you aren't allowed to make substantial
change to a system without first completing some form of maintenance request,"
says Puig. "If you don't have these procedures in place, it becomes
rather difficult to know what procedures to make to support the functionality."
A successful pilot project by any name prepares the stage for further strikes
into the heart of unresponsive information systems. It's more than worth
the trouble to do it right from the start.
Bill Roberts is a free-lance writer based in Los Altos,
CA, who covers business, technology and management issues. He can be reached
at email@example.com. Additional reporting
by Alan S. Kay.