The BPR Strike Force

By Bill Roberts



[Sidebar]: Steps in a Successful Pilot Project
[Sidebar]: General Guidelines

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 off quickly.

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 solution."

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 plan.

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 present.

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 wcrober@aol.com. Additional reporting by Alan S. Kay.