Why Process Improvements Fail - Lessons from Real-World Cases

Many organisations invest heavily in process improvements, automation, and transformation - yet the results often fall short of expectations. 

Stefani Markov's article breaks down why this happens by analysing four well-known failure cases across healthcare, emergency services, enterprise ERP, and automotive manufacturing. 

What we found is consistent across all sectors: The issue isn’t the tools. It’s the level of thinking. 

From Process Management to Systems Thinking, each failure occurred because the improvement effort was operating at the wrong level: 

 - Local fixes that created new downstream issues 

 - End-to-end designs that weren’t grounded in operational reality 

 - Automation applied to processes that weren’t ready 

 - System failures caused by siloed decision-making and missing accountability 

The lesson is clear: Sustainable improvement requires the right scope, the right depth, and strong feedback loops across the entire system. 

At Metrix, this is exactly the approach we apply - making sure improvements are aligned with how the organisation actually works, not just how the process is drawn. 

Let’s build systems that work - end to end. 

In my earlier articles, I explored the foundational aspects of process improvement: the significance of process maps in truly understanding work and the common pitfalls that cause process documentation to collect dust. These discussions laid the groundwork for recognizing that while mapping and documenting are crucial, they are not sufficient on their own.

Building upon these insights, this article delves deeper into why process improvements often fall short. It examines real-world case studies to illustrate how applying the wrong level of process thinking - be it Process Management, End-to-End Process Management, Business Process Management, or Systems Thinking - can lead to unintended consequences.

By analyzing these examples, I aim to provide a clearer understanding of how to align process improvement efforts with the appropriate level of thinking, ensuring more effective and sustainable outcomes.

Understanding Failure - It’s Rarely Just One Thing

When we talk about “failed” process improvements, it’s tempting to look for a single culprit - the wrong tool, a flawed design, missing training, poor leadership. But in reality, failure is rarely that simple. Most improvement initiatives don’t collapse because of one decision or one mistake. They unravel because of interactions - small misalignments that compound over time, unnoticed until the system stops delivering what it was meant to.

That’s also why defining failure matters. A project doesn’t have to implode to qualify as one. Sometimes the system runs, but it doesn’t improve anything. The process gets faster, but quality drops. Automation works, but exceptions double. Reports show progress, yet teams quietly create workarounds to keep things running.

For me, a process improvement fails when it achieves local success but systemic regression- when one part of the process looks better on paper, but the overall outcome for the business, customers, or employees gets worse.

That’s what makes these stories worth studying. Each case shows how different layers of process thinking - from local optimization to full systems perspective - shape not only how success is measured, but what success even means.

Case Study 1: Local Process Improvement (PM) Gone Wrong

Example: Queensland Health Payroll System (Australia, 2010)

When Queensland Health set out to modernize its payroll and HR systems, the goal was sound: replace outdated tools with a more efficient, automated solution. The new SAP–Workbrain system, delivered by IBM, was expected to streamline payroll for more than 78,000 employees. Instead, it became one of the most infamous examples of a process improvement gone wrong. Within weeks of go-live, thousands of staff received incorrect payments - or no pay at all - and the organization spent years and hundreds of millions addressing the fallout.

Why this is a Process Management failure?

At its core, Process Management (PM) focuses on improving individual processes - typically within one function, such as payroll - to make them faster, more accurate, or more efficient. That’s precisely the mindset applied here. The project team concentrated on automating payroll: digitizing calculations, standardizing inputs, and accelerating approvals.

But in doing so, payroll was treated as a self-contained process, rather than as part of a broader, interconnected system spanning HR, timekeeping, finance, and compliance. This narrow focus meant that dependencies - how HR data feeds payroll, how exceptions are reconciled, and how outputs affect accounting and reporting - were underestimated or overlooked. The result: a local optimization that created system-wide instability.

What made it a PM-level failure

• The improvement effort remained within a single functional silo (Payroll) instead of mapping the full Hire-to-Retire or Record-to-Report chain.

• Success metrics - speed, automation rate, go-live date - focused on local efficiency, not end-to-end accuracy or compliance.

• Downstream impacts such as reconciliation workloads, exception handling, and audit integrity were out of scope.

 Lessons learned

• The project went live despite known defects and incomplete testing - a symptom of defining success by delivery, not by performance.

• No end-to-end simulations were performed, so data inconsistencies between HR and timekeeping systems cascaded into payroll and financial reporting.

• Governance was fragmented: ownership sat with the project team rather than across functional boundaries.

How it could have been avoided

If Queensland Health had expanded its scope from process management to end-to-end process management, the team would have mapped the full chain of interactions - from HR data entry through payroll, reconciliation, and financial reporting - identifying weak points before automating.

Improve first, automate later - and always in the context of the full process chain.

Case 1 showed how local process fixes can create hidden inefficiencies downstream. Case 2 takes the next logical step - moving from isolated improvement to end-to-end integration - but reveals that broader scope alone doesn’t guarantee success when design and user readiness are neglected.

Case Study 2: End-to-End Process (E2E PM) Failure from Local Optimizations

Example: London Ambulance Service Computer-Aided Dispatch (LASCAD), 1992

In 1992, the London Ambulance Service launched its new Computer-Aided Dispatch (CAD) system - an ambitious project meant to automate ambulance dispatching and reduce response times. On paper, the goal was admirable: use technology to streamline call handling and resource allocation. In practice, it led to one of the most publicized operational failures in UK public service history.

Almost immediately after go-live, the system malfunctioned. Ambulances were sent to the wrong locations, calls were delayed or dropped, and the system repeatedly crashed under real-world load. Some patients waited hours for help, and tragically, several deaths were linked to the disruption.

Why this represents an End-to-End Process Management failure

Unlike the Queensland Health case - where the issue stemmed from isolated process optimization - the LASCAD project failed despite trying to automate across multiple steps in the service chain. On the surface, it appeared to adopt an end-to-end mindset: integrating call-taking, dispatching, and resource management. However, the design focused too heavily on technical coordination, not on process reality.

End-to-End Process Management (E2E PM) aims to connect all functional steps in a value chain - in this case, from emergency call receipt to patient handover. But for it to succeed, it must account for real-world variability: ambulance location accuracy, crew availability, traffic conditions, communication limits, and human judgment. The LASCAD system modeled the workflow, but not the work.

 Where E2E PM went wrong

• Process design did not reflect operational complexity. Dispatch logic was optimized around ideal scenarios, ignoring uncertainty and human factors.

• Insufficient end-to-end simulation. System testing occurred in isolation, without stress-testing full operational conditions or load.

• Stakeholder engagement was limited. Dispatchers and field staff - those most familiar with real constraints - were not fully involved in design or testing.

• Governance gaps. Oversight was technical rather than process-driven, focusing on IT readiness instead of service reliability.

Lessons learned

LASCAD demonstrates that end-to-end process management is not just about linking steps in sequence. It’s about ensuring that each link functions under real-world pressure and that every handoff between people, systems, and departments is validated through testing and feedback loops.

How it could have been avoided

A true E2E approach would have:

• Mapped the actual emergency response chain, including communication delays, manual overrides, and escalation paths.

• Involved dispatchers, drivers, and operations leads early in process modeling and testing.

• Validated the system under real-world loads and unpredictable conditions.

In essence, the LASCAD failure wasn’t due to the absence of end-to-end thinking - but to a shallow version of it. The system connected steps but not realities, proving that even end-to-end design fails when it ignores how processes actually behave in practice.

If the Queensland Health case showed what happens when a process scope is too narrow, the London Ambulance Service example illustrates the opposite - when the scope is broad, but not deep enough.

In the first, payroll was treated as a standalone process, disconnected from the wider system it depended on. In the second, the entire chain - from emergency call to dispatch - was technically linked, yet the real-world interactions between people, systems, and variability were overlooked.

Both failures highlight a key lesson: expanding scope alone doesn’t guarantee success. End-to-end process management requires not just mapping the flow, but truly understanding how each part behaves in practice - under pressure, across boundaries, and through exceptions.

The failure of Case 2 stemmed from poor integration and unrealistic execution across functions. Case 3 shows a more mature attempt - formalizing governance and introducing automation under a BPM framework. Yet it highlights a new trap: when automation outpaces process readiness, structure itself becomes the bottleneck.

Case Study 3: BPM / Automation When the Process Isn’t Ready

Example: Waste Management's SAP ERP Implementation

When Waste Management, a company grown through hundreds of acquisitions, attempted to modernize its fragmented financial and operational systems, the goal was to achieve significant annual savings by implementing a single, standardized, "out-of-the-box" Enterprise Resource Planning (ERP) system from SAP. Instead of integrating its diverse business units and their processes, the project became a notorious example of technology-led change colliding with operational immaturity. The system was deemed a "complete and utter failure," resulting in a $500 million lawsuit, significant operational losses and restating financial statements for the years 2000-2005 due to accounting irregularities.

Why was this a BPM/Automation failure?

At its core, Enterprise Automation (ERP/BPM) is designed to enforce standardized, best-practice processes across an organization. That's precisely what WM needed, but the project team focused disproportionately on the technology's promise rather than the foundational process work.

• In seeking a quick-fix, "off-the-shelf" solution, WM implicitly tried to automate hundreds of disparate, regional processes that had never been standardized or cleaned up.

• The project lacked the necessary Business Process Re-engineering (BPR) phase to standardize and simplify the core processes (like Order-to-Cash) before loading them into the system.

• WM failed to provide "sufficient, knowledgeable, decision-empowered users and managers" to define standardized requirements, allowing the project to proceed with a weak, un-aligned process foundation.

 What made it a BPM failure?

• Process Immaturity: The organization's processes were an amalgamation of hundreds of different systems and ways of working from acquired entities. The chaos of these non-standardized processes was directly automated, leading to catastrophic system errors.

• Focus on the Technology/Vendor: The project centered on selecting and implementing the SAP product rather than defining the single, unified way WM intended to run its business (the target-state process model).

• Neglected Due Diligence: The company relied heavily on the vendor's claims about software readiness without rigorously verifying that the system could handle their complex, yet unstandardized, processes.

 Lessons learned (from the Failure)

• Automation Magnifies Chaos: Automating a broken or non-standardized process does not fix it; it simply creates large-scale, automated chaos.

• BPR Precedes ERP: Standardization, cleanup, and alignment of processes must be completed and validated before the automation phase begins.

• Process Ownership is Critical: The business, not the IT project team or the vendor, must own and define the target process model.

Case 3 showed how even structured governance and automation can fail when the process itself isn’t ready - highlighting the limits of BPM when used without sufficient contextual awareness.

Case 4 takes this one step further. It illustrates that beyond process readiness lies system readiness - the ability of the entire organization to see interdependencies, share accountability, and manage information holistically.

Where BPM focuses on improving and automating defined processes, Systems Thinking asks a broader question: how do all those processes interact, and who ensures their alignment? The GM ignition switch crisis demonstrates what happens when each function performs well in isolation, but no one owns the system as a whole.

By Case 3, process improvement had evolved to enterprise-level governance and measurement. Case 4 pushes further, exploring what happens when even well-structured BPM systems ignore the larger organizational ecosystem. Here, the absence of system-level accountability and feedback loops exposes the ultimate challenge - seeing the whole system, not just its managed parts.

Case Study 4: Systems Thinking Breakdown & the Need for Holistic View

Example: The Failure of Systems Thinking at General Motors (GM) (Ignition Switch Crisis)

When General Motors discovered a fault in its ignition switch, the initial issue seemed minor - a low-cost component that could slip from “Run” to “Accessory” when the key was lightly bumped or pulled by a heavy keychain. This action cut power to the engine, resulting in loss of power steering/brakes and, critically, preventing the airbags from deploying in a crash. Over the next decade (c. 2001–2014), this defect was linked to at least 124 deaths, as millions of vehicles were recalled and GM faced one of the most serious safety scandals in automotive history.

Why it Fits Systems Thinking Breakdown

The problem was not just a faulty part, but GM’s inability to connect the dots across engineering, legal, and safety functions. Each department treated its information - stalling complaints, lawsuits, and airbag failures - as isolated data, with no one linking them into a unified systemic risk. The result: fragmented decision-making, delayed action, and the breakdown of feedback loops that should have escalated the risk early.

At its core, Systems Thinking focuses on understanding interconnections across an organization - how different parts influence one another. In this case:

• Engineering viewed the ignition switch as a minor “customer convenience” issue, not a safety defect.

• Legal and safety teams worked separately, failing to aggregate evidence of a common cause.

• The organization lacked a single system-level accountability point for safety-critical data.

• Cultural resistance to “bad news” and focus on cost control reinforced fragmented decision-making.

Lessons Learned

• Create System-Level Accountability: Implement cross-functional teams and processes that ensure safety-critical information is aggregated and reviewed by a single, high-level authority with a holistic view of the entire vehicle system.

• Mandate Integrity Over Cost: Redesign incentives to reward "truth-telling" and penalize the suppression or misclassification of safety defects (moving from a cost-driven to a quality-driven ethic).

• Enforce Transparency: Prevent the use of technical evasions, such as silently changing a component without updating the official part number. Transparency must be enforced across the organization and supply chain. (The action of the lead engineer in changing the physical switch component but failing to update the part number was a deliberate subversion of the system's feedback and traceability mechanism. This act broke the internal audit trail that should have alerted GM and regulators to the design change and the defect in earlier models.)

How it could have been avoided

If GM had adopted a holistic systems-thinking approach, it would have recognized how a small mechanical defect could cascade into a full safety system failure. Integrating engineering, safety, legal, and compliance data - and fostering a culture that values openness over cost - could have prevented years of delay and loss of life.

Key insight: Design, manage, and learn with the whole system in mind - not just its parts.

The analysis of real-world process failures highlights a common pattern: mistakes often arise from limited perspectives and superficial fixes. For project management (PM) in Queensland Health, isolation and local optimization led to narrow solutions, corrected by expanding the scope end-to-end (E2E). In the LASCAD E2E PM case, shallow linking without grounding in operational reality caused disconnects, addressed by deepening scope to align with actual operations. ERP-driven BPM failures stemmed from attempting to automate chaotic processes, remedied by improving processes before automation. Finally, systemic failures in GM arose from silos, cultural issues, and unclear accountability, which require a shift toward a holistic system view and integrity. Across cases, the lessons emphasize understanding reality, integrating perspectives, and sequencing improvements strategically.

Conclusion - From Process Thinking to Systems Thinking

Across these four cases, a pattern emerges. Each represents a different stage of process maturity - and a distinct type of failure:

Each level brings greater scope and coordination - but also greater risk if misunderstood.

Real process maturity doesn’t come from adopting the newest framework or technology. It comes from choosing the right level of thinking for the problem at hand, and from maintaining feedback loops that connect improvement efforts to real outcomes.

In short:

• Think broader than the process.

• Test deeper than the design.

• Learn faster than the failure.

Because every “failed” process improvement is, ultimately, a lesson in how systems really work.

Ready? Let's talk.