Business Process Reengineering: What It Is and Why It Got a Bad Name

The most quoted fact about business process reengineering, that most projects fail, was never a research finding. Business process reengineering (BPR) is the radical redesign of a whole business process, from the first request to the final result, starting from a blank sheet instead of the steps you have now. Michael Hammer named the idea in a 1990 Harvard Business Review article that told managers to stop automating old work and obliterate it instead.¹ The failure figure began as what Hammer and James Champy called an “unscientific estimate” of 50 to 70 percent in their 1993 book.² Within five years the word also stood for layoffs. The idea underneath still works when you know where it fits: ask why a process exists before you make it faster.

What is business process reengineering?

Business process reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in measures such as cost, quality, service and speed. That is the definition Hammer and Champy gave in Reengineering the Corporation, and it puts the whole process, not one department’s part of it, at the center.³

Hammer’s argument was about computers. Companies had spent heavily on information technology and got disappointing results, he wrote, because they used it to speed up old ways of working and left the processes themselves intact. His phrase for this was paving the cow paths.¹ Most processes rest on rules nobody wrote down, such as “forms must be filled in completely and in order”, and those rules come from assumptions about technology and people that may no longer hold. Reengineering asks which of them still make sense.

He offered principles rather than a recipe: organize work around outcomes instead of tasks, capture information once and at the source, and put decisions where the work is done.¹ Thomas Davenport and James Short published a similar idea, “business process redesign”, in Sloan Management Review that same summer, and Davenport later stressed that companies such as Ford and Mutual Benefit Life had done the work before anyone gave it a name.⁴

Reengineering is one branch of what process improvement covers: changing recurring work on purpose. Asking how to do a step faster is improvement; asking why the step exists at all is reengineering.

An example: how Ford rebuilt the way it paid suppliers

The best-known example of business process reengineering is Ford’s accounts payable department in North America, described in Hammer’s 1990 article. More than 500 people worked there in the early 1980s, and Ford’s first plan, new computers plus tidier procedures, aimed to cut that by about 20 percent. Then Ford looked at Mazda, whose accounts payable department had 5 people in total. Even allowing for Mazda’s smaller size, Ford reckoned its own department was five times larger than it should be.¹ The clerks spent most of their time on mismatches between three documents: the purchase order, the receiving record and the supplier’s invoice.

The fix was not faster matching. Ford dropped an unwritten rule, “we pay when we receive the invoice”, and replaced it with “we pay when we receive the goods”. Purchasing entered each order into a shared database; when goods arrived, the receiving clerk checked them against it, and the computer matched the records and prepared the payment. Suppliers were asked to stop sending invoices. Where the new process was in place, Hammer reported, headcount fell by 75 percent instead of the 20 percent first planned.¹

Two cautions come with the story. It is told by reengineering’s leading promoter, with no independent check. And Davenport, who directed a research program with Hammer in the late 1980s, says the accounts payable staff Ford no longer needed were reassigned within the company, not laid off.⁴ The method is to find the rule that creates the work, then ask whether the process still needs it.

The steps of business process reengineering

One of the most detailed public checklists for a reengineering project is the US General Accounting Office’s 1997 assessment guide, written so auditors could judge federal agencies’ projects. Its nine assessment questions boil down to six steps that apply in any organization:⁵

1. Restate the purpose: check the organization’s mission and goals, and what customers need from the process.
2. Measure the problem: record how the process performs now, benchmark it against leading organizations and set improvement goals.
3. Decide whether to reengineer at all: weigh whether a clean-slate redesign is worth its cost and risk, or whether smaller improvements will do.
4. Map the process and design alternatives: find the costs and causes of breakdowns, then design new versions from scratch.
5. Test before committing: build a business case and try the new design in simulations or limited pilots.
6. Implement and check: follow an implementation plan that manages the change for staff, then measure whether the new process gets the results it promised.

For step 4, a value stream map of the process is one way to draw the current flow. Do not skip step 3. The GAO guide states plainly that reengineering is not a cure-all, and that there are times when smaller improvements are the better choice.⁵ Before mapping anything, write down why a full redesign beats fixing the steps you have.

The “70 percent fail” claim, traced back

The claim that 70 percent of reengineering projects fail has a traceable source, and it is not a study. In their 1993 book, Hammer and Champy offered an estimate they themselves called unscientific: that as many as 50 to 70 percent of organizations attempting reengineering did not achieve the dramatic results they intended. In The Reengineering Revolution (1995), Hammer complained that the observation had been distorted into a rule and wrote that reengineering has no inherent success or failure rate. By 2000 a Harvard Business Review article by Michael Beer and Nitin Nohria opened with the line that about 70 percent of all change initiatives fail, with no source given.²

In 2011 Mark Hughes of Brighton Business School reviewed five published sources of the 70 percent figure for organizational change and found no valid and reliable empirical evidence behind any of them.⁶ The nearest thing to data from the 1990s is a 1994 report by CSC Index, which judged about two-thirds of 99 completed reengineering projects mediocre, marginal or failures, according to Davenport.⁴ CSC Index was itself a reengineering consultancy, led at the time by Champy.⁷

Myth

Research shows that 70 percent of reengineering projects fail.

Fact

The figure began as an estimate its authors called unscientific. A 2011 review found no valid evidence for a 70 percent failure rate.

The deeper problem is what “fail” means. Hammer and Champy’s estimate counted a project as a failure if it missed the dramatic results it set out to reach, so a project that aimed for a tenfold gain and achieved a large one would still count. When anyone quotes you a failure rate, ask what counted as failure and who measured it.

Why reengineering became a byword for layoffs

Reengineering came to mean job cuts because companies used the label to announce them. Davenport, who helped create the idea, wrote in 1995 that executives paying high consulting fees had to show financial benefits quickly, and that cutting headcount was the fastest way, so reengineering became synonymous with cutbacks. In the same CSC Index report, nearly three-quarters of the companies studied said they were using reengineering to eliminate jobs, about a fifth of them on average.⁴

Sometimes the label came before the work. Pacific Bell and Apple Computer both announced layoffs and credited reengineering, though Davenport and his co-authors, who were doing research at Pacific Bell, say its project was not far enough along for anyone to know how many people it would free up. Hammer’s own rhetoric did not help: he once said that in reengineering “we carry the wounded and shoot the stragglers”.⁸

He later admitted the mistake. In a 1996 interview with The Wall Street Journal he said:

I was reflecting my engineering background and was insufficiently appreciative of the human dimension.

Champy and Davenport made similar public apologies around the same time.⁷ Hammer also told Time magazine that the term had been “hijacked, misappropriated and misunderstood”, and that reengineering should ideally raise production and create more jobs.⁹

1. 1990Hammer, and Davenport and Short, publish the first articles
2. 1993Reengineering the Corporation becomes a bestseller
3. 1994CSC Index reports many disappointing projects and plans for job cuts
4. 1995-96Davenport, Champy and Hammer publicly admit they forgot about people
5. 2011A review finds no valid evidence for the 70 percent failure figure

The GAO guide draws the practical conclusion: putting a new process into practice is usually the phase most likely to fail, and the hardest part is the human side of the change rather than the technical one.⁵ If a redesign will remove work, decide early and say openly what happens to the people whose work disappears.

Why so many reengineering projects disappointed

The few studies of reengineering outcomes suggest that how a project was run may count for as much as the redesign itself. The clearest example comes from US hospitals in the mid-1990s.

The study

Limited evidence

Did reengineering cut hospital costs? A 1996-97 survey of US hospital chiefs

Stephen Walston, Lawton Burns and John Kimberly used a 1996-97 national survey of hospital chief executives, sponsored by the American Hospital Association (an industry body) and the Leonard Davis Institute, and compared each hospital’s change in costs relative to its local market. Reengineering on its own was not linked to a better cost position, and the authors suggest that without integrating and coordinating efforts it may damage that position. Steering committees, project teams, a written-down change process and executive involvement were linked to better results.¹⁰

The study relied on executives’ own reports of what they had changed and covered one industry in one country, so it links the extra structure to better results without proving one produced the other. A 2011 firm-level study by Kemal Altinkemer and colleagues, using company data from 1987 to 2008, adds a point about timing: return on assets dropped in the year a project started and then improved, on average. Firm-wide projects had a worse first year than projects focused on one function, with no clear sign that they paid off better later.¹¹

Davenport, Prusak and Wilson name two causes from practice. Hammer and Champy implied that a whole company could be reengineered in as little as a year, which badly understated the time and cost, and many firms tried to change processes, systems, structure and strategy all at once.⁸ Managers should plan for performance to get worse before it gets better, and keep the scope to one process you can manage.

How BPR differs from continuous improvement

Business process reengineering and continuous improvement differ in where they start and how big a change they make. Reengineering starts from a blank sheet and seeks a large, one-time gain across a whole process. Continuous improvement is an ongoing effort that changes the existing process in steps, usually small ones.¹²

Hammer himself wrote that reengineering cannot be done in small and cautious steps.¹ Continuous improvement trades that one big bet for many small ones, which is why it fits a process that mostly works.

1. Continuous improvement: many small changes to the process you already have; each step is modest
2. Reengineering: a dip while the redesigned process beds in, then a bigger jump if it works, or a fall if it does not

The two can work in sequence: a redesign sets up a new process, and steady improvement afterwards keeps it working as conditions change. If you are unsure which one you need, fix the worst step first; when the gain is small because the design itself creates the work, that is the signal to start again from a blank sheet.

When a clean-slate redesign is still the right call

A clean-slate redesign makes sense when a process is fundamentally inefficient or outdated, so that improving its parts cannot fix the whole. The GAO guide puts the other side just as clearly: smaller improvements are the better choice when a process is basically sound, or when the organization is not ready for dramatic change.⁵ Davenport and his co-authors, critics of the 1990s excesses, still conclude that it is sometimes better to throw a broken process away and start again.⁸

An illustrative case: a mid-sized distributor handles customer returns through sales, the warehouse, quality control and finance, each with its own form, and refunds take weeks. Speeding up each handoff would help a little. A clean-slate question goes further: what does the customer need? A decision on the day the item arrives. One redesign gives a single returns coordinator each case from arrival to refund, with the details entered once at the loading dock, which is Hammer’s “organize around outcomes” principle at small scale.¹ The team tests it on one product line for a month, compares days to refund with the old process, and tells the clerks in advance that the matching work they lose becomes coordinator work.

Seven checks before you tear up a process

• Name the end-to-end process and the result its customer needs
• Show that fixing individual steps cannot reach the goal
• Find the unwritten rules the current process obeys
• Pilot the new design on a small slice first
• Budget for performance to dip before it improves
• Decide and announce what happens to people whose work changes
• Plan how the new process will keep improving after launch

The bottom line

Business process reengineering is a sound idea that was oversold: its core question is why a process exists, before how to speed it up. Its reputation suffered because firms used the word to cover layoffs and tried to change everything at once, and no reliable study shows that most projects fail. Use a clean-slate redesign when a process is broken at its root, pilot it small, and plan for the people as carefully as for the steps.