The Fad That Forgot People

by Thomas H. Davenport

Reengineering didn't start out as a code word for mindless bloodshed. It wasn't supposed to be the last gasp of Industrial Age management. I know because I was there from the beginning. I was one of the "creators."

Of course, the real creators of reengineering weren't consultants or academics. They were real people with real problems to fix. Inside companies like Ford, Hewlett-Packard, and Mutual Benefit Life, managers were experimenting with new uses of information technology to link processes that cut across functional boundaries. But they didn't call their work reengineering; they didn't have elaborate "change models"; they certainly didn't see a movement in the making. All that came later.

The other thing to remember about the start of reengineering is that the phrase "massive layoffs" was never part of the early vocabulary. Ford certainly got credit for reducing headcount in its accounts payable department by 75% -- one of the earliest examples of the new technology meeting business practices. But those workers were reassigned within the company. When I wrote about "business process redesign" in 1990, I explicitly said that using it for cost reduction alone was not a sensible goal. And consultants Michael Hammer and James Champy, the two names most closely associated with reengineering, have insisted all along that layoffs shouldn't be the point. But the fact is, once out of the bottle, the reengineering genie quickly turned ugly.

So ugly that today, to most businesspeople in the United States, reengineering has become a word that stands for restructuring, layoffs, and too-often failed change programs. At a recent Boston forum, in fact, Michael Hammer gathered a group of business journalists to explore why reengineering had become such a tainted term.

The rock that reengineering has foundered on is simple: people. Reengineering treated the people inside companies as if they were just so many bits and bytes, interchangable parts to be reengineered. But no one wants to "be reengineered." No one wants to hear dictums like, "Carry the wounded but shoot the stragglers"--language that makes workers feel like prisoners of war, not their company's most important assets. No one wants to see 25-year-old MBAs in their first year of consulting making $80,000 per year with $30,000 signing bonuses, being billed out at six times their salaries, putting the company's veterans through their paces like they're just another group of idiots who "can't think out of the box."

The 1994 CSC Index "State of Reengineering Report" had the answer: 50% of the companies that participated in the study reported that the most difficult part of reengineering is dealing with fear and anxiety in their organizations; 73% of the companies said that they were using reengineering to eliminate, on average, 21% of the jobs; and, of 99 completed reengineering initiatives, 67% were judged as producing mediocre, marginal, or failed results.

Now, in the United States at least, the reengineering fever has broken. Consulting firms that relied too heavily on reengineering and grew too fast are desperately retrenching. Companies that embraced it as the silver bullet are now looking for ways to rebuild the organization's torn social fabric. But before we dismiss it as just a fad, it's worth taking one last look -- or perhaps one first honest look. Was reengineering always such a destructive management concept? How did a good idea go off the tracks so badly? And once the overblown claims have passed, what of value will remain?

Out of the Soup

It was the late 1980s in Boston and reengineering was in the air. At the Index Group (now CSC Index), where I was director of research, we circulated working papers on ways to improve management processes. Other consulting firms were writing internal reports on how to link computing and business change. The Boston Consulting Group had already launched "time-based competition," which used systems analysis and process mapping to speed up a company's overall performance. Michael Hammer, who had been at MIT and maintained a loose aYliation with Index, was arguing that technologists needed to try harder to change basic work processes.

Out of this primal soup emerged reengineering. The concept worked because it unwittingly brought together three components, none of which was new, but none of which had previously been connected. It began with technology: the real value of computing was not simply in doing work more efficiently, but in changing how work was done as well. To that was added the notion of "business processes," borrowed from the then-hot quality movement. The last piece of the puzzle was the idea of a clean-sheet-of-paper change program, an appealing prospect to large industrial companies seeking to escape the straitjacket of the past. Big companies with big problems were eager for Big Change.

These insights required some field work with companies and some model-building by academics and consultants. The field work came through a multiclient research program that Index and Hammer operated called PRISM -- Partnership for Research in Information Systems Management. I was the program director, and in 1988 we interviewed 100 companies on the ways information technology could improve cross-functional processes. Later, some of the companies that became stars of reengineering made presentations at the first public forum on reengineering -- although none of the companies called what they did "reengineering."

Then the model-making kicked in. A piece I wrote with MIT's James Short on "business process redesign" appeared in the Sloan Management Review in the Summer 1990 issue under the title, "The New Industrial Engineering: Information Technology and Business Process Redesign." A few weeks later, Hammer published "Reengineering Work: Don't Automate, Obliterate" in the Harvard Business Review. Process Innovation, my reengineering book, came out in November 1992. In April 1993 Hammer and Champy published Reengineering the Corporation.

Reengineering had its textbook and its bible.

The Reengineering Industrial Complex

How did a modest insight become the world's leading management fad? How did reengineering go from a decent idea in 1989 to a $51 billion industry in 1995? Chalk it up to the rise of the Reengineering Industrial Complex. Just as the concept of reengineering wove together three previously unrelated strands, its application brought together an iron triangle of powerful interest groups: top managers at big companies, big-time management consultants, and big-league information technology vendors.

Think back to the early 1990s. LBOs had come crashing down and business leaders were left casting about for a new direction. In retrospect, the pendulum swing seems obvious: from the go-go 1980s to the cost-cutting 1990s, from huge leveraged buyouts to massive internal workouts, from financial restructuring to business process reengineering.

As the reengineering tide rose, companies began to rewrite their histories. Ford had dramatically improved its accounts payable process; IBM Credit its financing quotation process; Mutual Benefit Life its new policy issue process. Not one was originally done under the banner of reengineering. All three were repackaged as reengineering success stories.

But from the beginning, this reengineering revisionism had its problems. Taco Bell used a change in its food preparation process to lower its prices and increase peak restaurant sales capacity. After reclassifying this project as a reengineering success, Taco Bell executives launched another project, this time relying on two (two!) outside consulting firms using the newly formulated reengineering tool kit. The project bombed. Nevertheless, inside companies, reengineering was gaining acceptance as much as a way for managers to get their projects approved and financed as for the real eYciencies it could deliver.

As fast as managers repackaged their projects, consulting firms repackaged their expertise. Continuous improvement, systems analysis, industrial engineering, cycle time reduction -- they all became versions of reengineering. A feeding frenzy was under way. Major consulting firms could routinely bill clients at $1 million per month, and keep their strategists, operations experts, and system developers busy for years.

For their part, executives had to show financial benefits -- especially at those consulting rates. The fastest way to show financial results was to reduce headcount. Reengineering became synonymous with cutbacks. At Apple Computer and Pacific Bell, for example, press releases in 1993 described major layoffs as a product of reengineering. It didn't matter that the actual linkage was doubtful. Headcount reduction gave reengineering a strategic rationale and a financial justification.

The third winner in the reengineering sweepstakes was the computing industry. Before the advent of reengineering, American business already bought $1 trillion of hardware, software, and communications products each decade. Reengineering justified all that spending -- and promised to increase it. In addition, many of these vendors had gone through reengineering themselves; they could offer consulting services on top of their technology. A nifty double dip.

The stars were in alignment and reengineering exploded. Suddenly everything was reengineering and everyone could do it.

A modest idea had become a monster.

Reality Bites

Around 1994 reality began to intrude. With so many claims being made for reengineering and so many companies calling every change program a reengineering project, there were bound to be train wrecks. One West Coast pharmaceutical company went through two major consulting firms before canceling its whole reengineering effort. A large telecommunications company laid oV a massive number of people -- calling it reengineering -- but alienated many of the organization's brightest people by its almost purposeful insensitivity.

Even some of the success stories went awry. Take, for example, Capital Holding's (now Providian) Direct Response Group, a company that was held up as a model in Reengineering the Corporation.

DRG is best known as the insurance company that used to run late-night television ads featuring Art Linkletter and Roger Staubach. In the late 1980s, the company launched a broad-scale reengineering effort, involving simultaneous change in organizational structure, business processes, information systems, and corporate culture. The story in Hammer and Champy's book, as told by Pamela Godwin, then DRG's senior vice president, reads like this: "All together we have about ten separate reengineering projects under way right now, and they and the people operating them constitute what I call Company B. Company B is the new company that we're designing and building. Company A is the existing company. The interesting thing is that the people in Company A aren't waiting for their turn to get into the new stuff... .Change breeds change, and we're finding that people want to jump on board because they see what's happening in Company B as the wave of the future."

That was in 1992. In 1995, as it turns out, Company B was not the wave of the future. In 1993, DRG's parent deposed Norm Phelps, the division president, and installed Shailesh Mehta. He dismantled the process-oriented organization, stopped the cultural change effort, and shut down the team-based prototype operation, saying that he believed in "individual accountability." One year later Pamela Godwin left the company. She and Phelps had tried to create a human-oriented version of reengineering -- but simply ran out of time despite being profitable.

Reflecting on the reengineering movement, she says, "Reengineering regressed into the old industrial engineering and that regressed into the big scare. People think they're going to be reduced to rubble by reengineering. Organizations forget to remind them that they have skills they can apply to a changed work environment and they can learn new ones."

Other featured companies fared just as poorly or even worse. Mutual Benefit Life is basically out of business. Hallmark, which sought to shorten its new product development cycle from a painfully slow two years, still can take a full year to create a single new greeting card. And despite reengineering, the company still clings to its bureaucratic "Okay Committee," and continues to watch its market share slip.

In late 1995, reengineering isn't dead; it is effectively over. Growth markets for reengineering today are outside the United States, in Latin America, southern Europe, and Australia -- where they haven't "caught up" to U.S. management yet.

Salvage from the Ruins

As is always the case with any fad, there was a kernel of truth to reengineering. Over time, that truth got lost. But that doesn't make it any less true.

The most profound lesson of business process reengineering was never reengineering, but business processes. Processes are how we work. Any company that ignores its business processes or fails to improve them risks its future. That said, companies can use many different approaches to process improvement without ever embarking on a high-risk reengineering project.

For technologists, the lesson from reengineering is a reminder of an old truth: information technology is only useful if it helps people do their work better and differently. Companies are still throwing money at technology -- instead of working with the people in the organization to infuse technology.

Finally, reengineering's enduring lesson is that the bigger the hype the greater the chances of failure. Before reengineering became The Reengineering Revolution, innovators were experimenting with a variety of change practices. With the exaggerated promises and heightened expectations came faddishness and failure. The lesson: companies should underpromise and overdeliver. The time to trumpet change programs is after results are safely in the can.

When the Next Big Thing in management hits, try to remember the lessons of reengineering. Don't drop all your ongoing approaches to change in favor of the handsome newcomer. Don't listen to the new approach's most charismatic advocates, but only to the most reasoned. Talk softly about what you're doing and carry a big ruler to measure real results.

And start with a question: "Would I like this management approach applied to me and my job?" If the answer is yes, do it to yourself first. You'll set a great example.

Thomas H. Davenport (tdav@notes.bus.utexas.edu) is the Curtis Mathes Fellowship professor and director, Information Management Program, at the Graduate School of Business, University of Texas at Austin.