Most process improvement is, and should be, incremental — a small adjustment here, a slightly better step there, compounding gradually into meaningful gains over time. Occasionally, though, a process is broken in a way that incremental fixes simply can’t reach — not because any single step is badly designed, but because the entire process is built on assumptions that no longer hold. In those situations, the more effective response isn’t gradual improvement. It’s a genuine, ground-up redesign.
What Makes Reengineering Different From Ordinary Improvement
Ordinary process improvement asks: how can we do the current process a bit better? Reengineering asks a more fundamental, more uncomfortable question: why are we doing this process at all, and if we were designing it fresh today, with no attachment to how it’s currently done, would we build it this way?
This distinction matters because the two approaches produce genuinely different outcomes. Incremental improvement, by design, tends to produce incremental gains — meaningful, but modest. Reengineering, when it’s genuinely warranted and well executed, can produce substantial, step-change improvement, precisely because it isn’t constrained by the assumptions embedded in the existing process.
The Defining Features of Genuine Reengineering
It questions fundamentals, not just methods. Reengineering doesn’t ask how to execute the current approach more efficiently — it asks whether the current approach, and the assumptions underneath it, still make sense at all.
It aims for radical, not incremental, change. The goal isn’t a modest improvement to what already exists — it’s uprooting the existing process and rebuilding it from the ground up, in a form that actually fits current needs rather than historical ones.
It targets substantial, not marginal, results. Reengineering is warranted when the gap between current performance and what’s genuinely needed is large — not a case for a process that’s basically working but could be slightly better.
It focuses on processes, not organisational structure. Reengineering examines and rebuilds how work actually flows, rather than reorganising reporting lines or job titles — the process itself, not the org chart, is the unit of analysis.
It typically depends on genuinely rethinking how technology is used, not simply automating an existing, flawed process to make it marginally faster.
It works forward from opportunity, not backward from crisis alone. Genuine reengineering looks for improvement opportunities proactively, rather than waiting until a problem becomes severe enough to force a reaction.
When Reengineering Is Actually Warranted
Reengineering tends to be genuinely justified in three broad situations. Organisations in real, visible decline — facing high operating costs, declining quality, and an inability to compete effectively — where the existing process is clearly part of the problem, not just a minor inefficiency within an otherwise sound structure. Organisations on a trajectory toward decline — where the warning signs are visible even though the crisis hasn’t fully arrived: shrinking market share, gradually rising costs, declining margins — and where the existing process, left unchanged, is likely to make the eventual crisis worse rather than avert it. And, somewhat counterintuitively, organisations at the height of their success — with no acute problems at all, but strong reason to believe that a fundamentally rebuilt process could extend and protect their advantage, rather than simply defending the current position until competitors eventually catch up.
What Reengineering Is Meant to Achieve
Done well, reengineering aims at genuine, substantial change in performance — not superficial polish, but a fundamentally different way of working that changes the underlying cost structure, speed, and quality of what an organisation delivers. It aims to sharpen focus on what customers actually need, redesigning the process specifically around meeting that need rather than around internal convenience or historical habit. It aims for genuine speed, giving decision-makers the information they need to move quickly rather than waiting on a process built for a slower era. And it aims for reduced cost, specifically by eliminating steps that don’t add genuine value, rather than trimming uniformly across a process that may still contain a great deal of waste.
Why Reengineering Is Genuinely Difficult
It’s worth being honest that reengineering carries real risk and real difficulty, which is part of why it should be reserved for situations that genuinely warrant it rather than applied as a default response to any performance problem. It typically requires significant investment in new systems and genuine retraining, not just a policy change. It disrupts established ways of working, which reliably generates resistance, sometimes severe, from people whose roles and routines the redesign affects directly. And it carries real execution risk — a fundamentally redesigned process that isn’t implemented well can leave an organisation worse off than the flawed process it replaced, at least for a difficult transition period.
A Practical Scenario
A department has spent several years making small, incremental improvements to its customer request process, and each individual improvement has genuinely helped — but overall performance still lags well behind what customers now expect, and behind competitors who’ve adopted a fundamentally different approach. Reviewing this honestly, the department head recognises that the underlying process itself, built around an assumption of manual, sequential handoffs between several different specialists, is the actual constraint — not any single step within it.
Rather than pursuing another round of incremental tweaks, the team undertakes a genuine redesign: rebuilding the process around a single point of contact supported by better shared information access, eliminating several handoffs entirely rather than just speeding each one up. The transition is genuinely disruptive for a few months, requiring real retraining and some resistance to work through — but the resulting process delivers a substantial, step-change improvement that years of incremental tweaking to the old structure had never been able to reach.
Common Mistakes
Applying reengineering to a process that only needs incremental improvement. The disruption and cost of genuine reengineering isn’t warranted for a process that’s basically sound but could be modestly better.
Automating a flawed process rather than genuinely redesigning it. Simply speeding up a broken process with technology tends to produce a faster version of the same underlying problems, not a genuine solution.
Underestimating the resistance a genuine redesign will generate. Reengineering disrupts established routines directly, and failing to plan for the resulting resistance is a common cause of failed implementation.
Reorganising structure instead of redesigning the actual process. Changing reporting lines or job titles without rebuilding how work actually flows misses the substance of what reengineering is meant to achieve.
Action Steps
- Identify a process in your organisation where years of incremental improvement have failed to close a persistent, substantial performance gap.
- Ask, honestly, whether the process would be built the same way if you were designing it fresh today, with no attachment to how it’s currently done.
- Before committing to a full redesign, confirm the situation genuinely warrants it — visible decline, a trajectory toward decline, or a strong opportunity to extend an existing advantage.
- If you do pursue a redesign, plan explicitly for the resistance and disruption it will generate, rather than assuming it will be readily accepted.
- Focus any redesign on the actual flow of work, not just the reporting structure or job titles surrounding it.
Key Takeaways
- Reengineering questions the fundamental assumptions behind a process, not just how well its current steps are executed.
- It’s warranted for organisations in decline, heading toward decline, or seeking to extend a strong position — not for processes that are basically sound.
- Genuine reengineering targets substantial, step-change improvement, distinct from the more modest gains incremental improvement typically produces.
- It focuses on redesigning the actual flow of work, not reorganising structure or simply automating an existing, flawed process.
- Reengineering carries real risk and real resistance, which is part of why it should be reserved for situations that genuinely require it.
Conclusion
Most process problems respond well to ordinary, incremental improvement, and that’s usually the right first response. But when a persistent, substantial performance gap survives repeated incremental fixes, the underlying issue is often the process’s fundamental design, not its execution — and no amount of incremental polish will close a gap that a fundamentally different approach is actually needed to address. Recognising which situation you’re actually in, and having the willingness to rebuild rather than merely adjust when it’s genuinely warranted, is what separates organisations that eventually break through a persistent constraint from those that keep polishing a process that was never going to get them where they need to go.
Frequently Asked Questions
How is business process reengineering different from ordinary process improvement?
Ordinary improvement asks how to execute an existing process better; reengineering questions the process’s fundamental assumptions and rebuilds it from the ground up, aiming for substantial rather than incremental gains.
Is reengineering only appropriate for organisations in crisis?
No — it can also be appropriate for organisations at the height of their success, seeking to extend and protect their position, though it’s most commonly associated with organisations facing genuine or approaching decline.
What’s the biggest risk of pursuing a full process redesign?
Significant disruption and resistance during implementation, along with real execution risk — a poorly implemented redesign can leave an organisation worse off, at least temporarily, than the flawed process it replaced.
Does reengineering always require new technology?
It typically involves genuinely rethinking how technology is used, though the core of reengineering is redesigning the process itself, not simply automating an existing one.
How can an organisation tell if a process needs incremental improvement or full reengineering?
Consider whether repeated incremental improvements have already been tried and have failed to close a substantial, persistent performance gap — if so, the process’s fundamental design, not its execution, may be the actual constraint.
Should reengineering focus on organisational structure or on the process itself?
On the process itself — how work actually flows — rather than on reporting lines or job titles, which is a common point of confusion that limits how effective a redesign actually is.