Can Today’s COO Still Benefit from Hammer and Champy’s Reengineering the Corporation?

Management books often arrive like traveling medicine shows: familiar advice is repackaged as a miracle cure, given a dramatic name, and sold as a revolution. Michael Hammer and James Champy’s Reengineering the Corporation deserves some of that skepticism.

The short answer for today’s COO is still yes, but with limits. More than three decades after the book appeared, its examples and rhetoric feel dated. Its strongest principles remain useful: organize work around customer outcomes, reduce handoffs, give process owners real authority, and redesign a fundamentally broken process instead of automating the mess.

This article summarizes the book’s business process reengineering method, weighs its benefits against its human costs, and asks when radical redesign is a better choice than continuous improvement.

• Be the process that you want to reengineer
• Reorganizing organizations the Hammer and Champy way
• Benefits and backing
• Criticisms and consequences
• What today’s COO can still use

Let’s go break some stuff, carefully.

Be the process that you want to reengineer

In the prologue to the 2001 edition, Hammer and Champy acknowledge that reengineering attracted heavy criticism after its first wave of praise. They argue that the method helped drive economic and industrial gains. That is a much larger causal claim than the evidence in the book can comfortably carry.

The stronger case for reengineering is operational, not macroeconomic. The book asks leaders to stop treating an existing process, department, or output as inevitable. It starts with the customer, the outcome, and the complete flow of work required to produce it.

That shift changes the unit of management. Traditional functional structures optimize each department’s work, but the customer experiences the complete process. A credit decision can be efficient inside every specialist team and still take two weeks. A policy can be perfectly written and still fail because execution happens somewhere else. Reengineering looks across those boundaries and asks why the boundaries exist.

That idea matters even more in a world of cloud systems, distributed teams, automation, and AI. Technology can accelerate a good process, but it can also make a bad process fail faster and at greater scale. Before automating anything, leaders still need to decide whether the underlying work deserves to exist in its current form.

Processes are universal. Everyone uses a process for clearing the table, merging into traffic, approving a purchase, or responding to email. The process may be undocumented or invisible, but it still shapes the outcome.

The practical test is simple: follow one real unit of work from request to outcome. Count the queues, handoffs, approvals, duplicate entries, and moments when nobody owns the next move. That evidence is more useful than an organization chart because it shows how the company actually behaves under normal conditions.

Reengineering is therefore less about dramatic language than disciplined observation. The team has to understand what customers do with the output, which exceptions genuinely require expertise, and which steps survive only because an older system or reporting line made them necessary. Without that work, a radical redesign is just a larger guess.

Process Street is a single Compliance Operations Platform that connects governed documentation with repeatable execution. Docs and Ops capability areas, plus built-in AI, help teams define how work should happen, run it consistently, and retain evidence that the right steps were followed.

“Process understanding […] takes nothing for granted. A reengineering team attempting to understand a process does not accept the existing output as a given. Part of understanding a process is comprehending what the process’ customer does with that output.”
Michael Hammer and James Champy, Reengineering the Corporation

Understanding how the process works, who uses its output, and where value is lost remains the durable foundation of business process reengineering.

If it ain’t broke: Reorganizing organizations the Hammer & Champy way

“Reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed.”, Hammer & Champy, RtC

Sounds good, right? It hits all those punchy notes affirming the identity stories we’ve manufactured about ourselves as rebels and innovators, not just on the cutting edge, but frickin creating it. Fundamental. Radical. Dramatic. So exciting. But what does it actually mean? The definition matters because the revolutionary language can otherwise hide the operating model underneath it. The story begins to the early 20th century. Business organizational models were the new kids on the block, and they were changing the way everything was done. They revolutionized the practice of efficient manufacturing and productivity. Products were manufactured quickly, cheaply, and, most importantly, at a high quality. Technology was advancing in leaps and bounds. And business was very, very good.

The saying goes: if it ain’t broke, don’t fix it, and those early entrepreneurs took that adage to heart. Their models for making cars, trains, planes, and everything else worked and worked well. So they never thought about making changes. Unfortunately, the world around them not only continued to advance and innovate but did so at an ever-increasing pace. Before long, and certainly by the early ‘90s, that pace completely outstripped the organizational frameworks that had enabled it. Enter Dr. Michael Hammer, professor, and James Champy, theorist. The business world, as they perceived it, had become clunky and obsolete. The strategies, structures, and systems used by major corporations were, instead of pushing them forward, holding them back. The world had changed, and they had failed to change with it.

“Ironically, the explanation for why companies perform badly is the identical explanation for why they used to perform so well.”, Hammer & Champy, RtC

For Hammer and Champy, these systems were so fundamentally broken that the only possible solution was to tear down those institutions and rebuild completely anew. In other words, for Hammer and Champy, it was time to reengineer the corporation.

The brass tacks of business process reengineering

The following eight phases are this article’s synthesis of business process reengineering. Together, they make up a fairly general view of what reengineering entails. There isn’t necessarily a distinct separation between every phase, and each phase could easily involve multiple steps or even multiple processes, which is why they are described as phases in a cycle rather than fixed steps in a single process. It should give some context and tangibility to what we’re talking about. Here’s how it all plays out: Phase 1: Identify the fragmented process: The source of a problem isn’t always immediate, but reengineering the wrong process is very costly, in every way that matters. Phase 2: Determine the reengineering objectives: Set your OKRs and know your intended outcome. Be specific and clear about what you want to achieve. Phase 3: Fully understand the process: Understanding is not analysis. Analysis focuses on what a process does; understanding is about how the process is used (and who’s using it). Phase 4: Develop an action plan: Don’t take it apart unless you know how to put the pieces back together again. Phase 5: Implement the action plan: Make your changes and test the reengineered process. Then test it again. And again. And again. Phase 6: Make the reengineered process operational: This is the hard part. You need your people to actively use the reengineered process instead of the fragmented one. Changing processes is a challenge; changing people is like teaching a cat to swim. It’s doable, but it’s certainly not going to be painless for anyone. Phase 7: Evaluate the process’s performance: Document the results and determine the best course of action. Remember that not all short-term problems need a long-term solution. Phase 8: Continue to improve as needed: Once you’ve determined whether the issue is an issue and will stay that way long-term, you can look for a solution. …which brings us right back around to Phase 1.

The who’s who of reengineering

A successful reengineering project is run by a reengineering team. Hammer and Champy stress the importance of including both process “insiders” (those who know and use the process well) and “outsiders” (those outside the process or department, or even the company) to provide input on the process defragmenting. There are four main roles to the reengineering hierarchy:

1. The Leader: Usually a senior executive with the authority to sway decision-makers, this is the person leading the rallying call for reengineering.
2. Reengineering Czar: While the Leader is responsible for hearts and minds, the Reengineering Czar is in charge of nuts and bolts. They drive the practical side of the project.
3. Reengineering Team: These are the process insiders and outsiders described above who actually figure out how to redesign the process. It’s probably not a good idea to refer to them as “insiders” and “outsiders,” though.
4. (Optional) The Steering Committee: Other senior managers who oversee the reengineering strategy and progress, and work in tandem with the Czar. Usually, decision-makers who have a stake in how it all turns out but don’t have a hands-on role.

Reengineering the Corporation: Benefits and backing

Hammer’s language can be pompous and overblown, but the underlying benefits should be judged separately from the style. In the original interview for this article, then Process Street COO Jay Hanlon connected the book’s argument to servant leadership: decisions, trust, and autonomy should move down the organization toward the people closest to the work.

Done well, business process reengineering can shorten cycle time, reduce handoffs, simplify ownership, improve service, and remove work that never contributed to the customer outcome. None of those outcomes is automatic. Radical redesign also magnifies weak evidence, poor leadership, and bad change management.

The benefits are connected. Fewer handoffs can reduce waiting time, but they can also make ownership clearer and errors easier to trace. Broader roles can improve service because one person sees the complete request, but those roles require better training and decision authority. Removing a control can simplify the process, but only if the evidence shows the control was redundant rather than protective.

The book’s language was deliberately revolutionary. Professor Brad Jackson observed that Hammer and Champy’s work echoed the counterculture movement, urging managers to free themselves from the constraints of inherited structures. That rhetoric made sense in large organizations whose functional silos had hardened into the operating model.

The most useful lesson is not that every system should be broken. It is that some systems are so fragmented that another local fix creates another handoff, exception, or bottleneck. In those cases, leaders need to redesign the flow around the outcome.

IBM Credit Corporation

IBM Credit Corporation remains the book’s clearest case. A financing request took an average of six days and sometimes as long as two weeks, even though the actual work required about 90 minutes. The delay came from handoffs across specialists, with a request moving through several people before a salesperson received a decision.

Senior managers followed one request through the full process and discovered that the work itself was not the constraint. The fragmented design was.

IBM replaced the default specialist relay with one case owner, called a deal structurer, who could handle an ordinary request from start to finish. Experts remained available for genuine exceptions instead of reviewing every deal.

This was not a cosmetic workflow change. IBM changed the role design, the decision path, and the default rule for involving specialists. The new process treated a financing request as one customer outcome rather than a bundle of departmental tasks. That is what separates reengineering from simply digitizing the old routing slip.

The case also explains why BPR can be politically difficult. End-to-end ownership changes who makes decisions, whose expertise is exceptional rather than routine, and how managers measure performance. A process can look obviously better on paper while still threatening the status and identity built around the old design. That human reality belongs in the implementation plan, not in a communication campaign added after decisions are final.

Hammer and Champy’s account reports that redesigned turnaround fell to about four hours and the operation handled 100 times its former deal volume. The enduring lesson is not the exact number. It is the mechanism: end-to-end ownership removed the queueing and coordination cost created by repeated handoffs.

Reengineering the Corporation: Criticisms & consequences

The concept of reengineering has one crucial, monumental, and undeniable flaw: The people expected to drive the process of reengineering, middle management, generally won’t have a job at the end of the process. Obviously, this gives them little motivation to support and facilitate a successful reengineering project. For middle managers, this creates a paradox:

• They support reengineering, which threatens their existence within the organization.
• They oppose reengineering, which eliminates survival within the organization post-reengineering.

As a result, even if the reengineering effort itself is successful in achieving its initial purpose, there are often long-term costs and consequences that bring that success into question. In his chapter on reengineering, Brad Jackson provides an excellent first-hand account of this exact situation playing out:

The Faculty of Continuing Education, University of Calgary

For three years, the Faculty of Continuing Education had been operating under a financial deficit. By anyone’s measure, this was a problem. Jackson, along with a number of his colleagues, were intrigued by the concept of reengineering. It seemed to offer the promise of solving their financial problems and breaking down institutional barriers they felt were holding them back.

“The sense of excitement, risk, and adventure that accompanies reengineering is a tempting combination for individuals like myself, who tend to be frustrated with inaction and want to make something happen immediately within their organization.”, Prof. Brad Jackson, Management Gurus and Management Fashions

In the case of Jackson’s department, the financial difficulties were solved by reengineering how the faculty worked. Immediately following the project, the faculty actually generated revenue and is widely recognized as operating more efficiently and effectively than prior to reengineering. This improvement came with a hefty price, however. The extent of hostility and fractured relationships between faculty members was so extensive that even more than four years later, those relationships hadn’t been repaired. Overall morale during the reengineering project plummeted and those driving the change found their own reputations following suit. Through reengineering, the Faculty of Continuing Education solved their financial problem and created a people problem.

Can today’s COO still benefit from Reengineering the Corporation?

Yes, but the benefit comes from the principle, not the full playbook. The book’s revolutionary language can tempt leaders to mistake disruption for progress. A COO should still understand business process reengineering because some operating systems are too broken for another incremental fix.

The decision turns on the condition of the process. If the process produces the right outcome and needs refinement, use continuous improvement. If the process is organized around outdated assumptions, fragmented ownership, or work the customer does not value, reengineering may be the safer choice.

A redesign decision should be evidence-based. Look for persistent customer delay, repeated rework, controls that exist only to reconcile other controls, and specialists spending most of their time moving information rather than applying expertise. Also test feasibility: leadership authority, system constraints, regulatory obligations, and the team’s capacity to absorb change all shape whether a radical redesign can succeed.

Business process reengineering and continuous improvement are not the same method. Continuous improvement changes a working process in small, measured steps. Reengineering questions the process’s purpose and may replace its design entirely. Strong operators need both disciplines and a clear threshold for choosing between them.

Consider a workflow that refers to Policy A after the company has moved to Policy B. If one task needs updating, change the task, test the workflow, and continue improving it. If Policy A shaped every approval, role, system integration, and control in the process, a clean redesign may cost less than preserving a structure that no longer fits the work.

The same principle applies to automation and AI. Automating a broken handoff does not create end-to-end ownership. It only accelerates the handoff. Before adding another system, leaders should map the current process, identify the customer outcome, and decide which steps still earn their place.

The book’s most relevant leadership lesson is trust. People closest to the work usually understand its exceptions, dependencies, and failure modes better than an executive steering committee. Give them authority to challenge the inherited process and evidence to test the new one.

That does not mean abandoning governance. A strong redesign makes ownership, approvals, evidence, and exception handling more explicit. The goal is not fewer controls at any cost. It is a process where every control serves the outcome and every owner can explain why the control exists.

The University of Calgary example is the warning beside the IBM case. Financial performance improved, but relationships and morale suffered for years. A process can meet its technical objective and still damage the organization expected to run it. The COO’s job is to judge both outcomes and to stop a redesign from treating people as disposable components of the process map.

“The process-centered organization is characterized by responsibility, autonomy, risk, and uncertainty. It may not be a gentle environment, but it is a very human one. Gone are the artificial rigidities of the conventional corporation. In its place is a world full of messiness, challenges, and disappointments, that characterize the real world of real human beings.”
Michael Hammer, Beyond Reengineering

That is the part of Reengineering the Corporation worth keeping: redesign the work when the structure blocks the outcome, then govern the new process so the improvement survives daily execution.

The post Can Today’s COO Still Benefit from Hammer and Champy’s Reengineering the Corporation? first appeared on Process Street | Compliance Operations Platform.