When Process Improvements Fail - Then Get Fixed: Lessons from Real-World Cases

Why do so many process improvements fail - and what actually works in fixing them? 

We recently published an analysis that examines four well-known organisational failures through the lens of process maturity. 

Each case shows a different type of breakdown: 

• Local process optimisation that destabilised the wider system 

• E2E redesign that overlooked real-world variability 

• BPM/automation initiatives launched before processes were ready 

• System-level failures caused by siloed decision-making 

More importantly, the article highlights the remediation steps organisations took — and how success required shifting to the correct level of process thinking. 

At Metrix Ltd., we believe that effective transformation starts with choosing the right lens: 

Process → End-to-End → BPM → Systems Thinking. 

And remediation must align to the same level. 

If you’re leading change, finance transformation, or enterprise process initiatives, these lessons offer valuable guidance. 

Introduction: From Maps to Maturity: Why Many Improvements Still Fail (and Get Fixed)

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 recognising that while mapping and documenting are crucial, they are not sufficient on their own.

Building upon those insights, this article delves deeper into why process-improvements often fall short and what organisations did to remediate them. 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 and how remediation must correspond to the right level of thinking.

By analysing 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 and Remediation

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 collapse 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. And crucially, how remediation must be aligned to that same level of thinking.

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

Example: Queensland Health (QH) Payroll System (Australia, 2010)

What happened & Why it failed

When Queensland Health set out to modernise 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, thousands of staff were incorrectly paid - or not paid at all - and the organisation spent years and hundreds of millions addressing the fallout.

From a Process Management (PM) perspective, the project team concentrated on automating payroll: digitising calculations, standardising inputs, and accelerating approvals. That’s precisely a PM-level mindset: improving a single process (payroll) means focusing on that process in isolation.

But the problem: payroll was treated as a self-contained process rather than part of a broader interconnected system spanning HR, time-keeping, finance, compliance. Dependencies were underestimated or overlooked. Result: Local optimisation created system-wide instability.

Remediation Steps Taken

How did QH remediate? Some of the steps included:

• A formal commission of inquiry (“QH Payroll System Commission of Inquiry”) produced a report that identified the defects and made recommendations.

• QH invested in further system correction and manual workarounds: the system required ~1,000 employees to manually process payroll every fortnight even post‐go-live.

• They committed to simplify award structures before further system changes and introduced stronger test regimes and contingency plans.

• Ongoing improvement initiatives: for example, the introduction of the Integrated Workforce Management (IWFM) electronic rostering system across the department to help assure roster‐to‐pay process accuracy.

Lessons Learned & Process-Management Perspective

From the process-management lens (PM):

• Success metrics were too local (e.g., pay run by payroll team) and ignored downstream impacts (exceptions, reconciliation, audit, finance).

• Remediation required stepping outside the immediate process to address interdependencies: HR → timekeeping → payroll → finance.

• The fix emphasised improve first, automate later - recognition that the process was not robust enough for full automation.

• Clearer governance, roles & responsibilities, and test/contingency planning had to be implemented.

• From a process-manager role (like yours in R2R): ensure any process automation is scoped with upstream and downstream owners, and test full chain, not just the process.

Case Study 2: End-to-End Process (E2E PM) Failure - Remediation

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

What happened & Why it failed

In 1992, LAS launched its new Computer-Aided Dispatch (CAD) system - an ambitious project to automate ambulance dispatching and reduce response times. On paper, the goal was admirable; in practice it was disastrous: the system malfunctioned almost immediately. Ambulances were sent to wrong locations, calls delayed or dropped, the system crashed under load.

Unlike the QH case (narrow functional focus), this one attempted end-to-end process redesign: integrating call-taking, dispatching, and resource management. On the surface, that is E2E process management. But in reality the design focused too heavily on technical connectivity rather than the operational reality of how people did their jobs, how exceptions were handled, how variability and loads would behave.

Remediation Steps Taken

After the failure, LAS (and its regulators) took several remediation actions:

• A formal inquiry reported multiple recommendations: development process must allow fully for consultation, quality assurance, testing, training; any new system should be introduced in a step-wise approach.

• The organisation moved away from the “big bang” roll-out to phased implementation of system upgrades.

• Better stakeholder involvement: understanding paramedic behaviour, dispatch staff voice, human factors included in subsequent system design.

• New infrastructure, redundancies and fallback processes: e.g., in a 2017 event the CAD system failed and paper‐based backup was used; the incident triggered executive group formation to review and commission improvements.

• Digital transformation programme (“Digital 999”, ePCR rollout) to modernise gradually and integrate with dispatch systems as part of the learning trajectory.

Lessons Learned & End-to-End Process Perspective

From an E2E PM perspective:

• Mapping the full process chain is essential, but even more essential is mapping how the process behaves in real-world conditions (high load, variability, exceptions) - not only the “ideal flow.”

• Remediation required moving from linking functions to ensuring hand-offs, feedback loops and human/technical interaction points are validated.

• Governance across functional boundaries (call taking, dispatch, paramedics) and involvement of frontline staff is key to identification of weak points.

• Step-wise deployment and contingency/back-up processes must be built into remediation.

• For a process manager in an R2R context: when you do “End-to-End” improvements (e.g., Hire-to-Retire, Record-to-Report), ensure you involve not only the sequence of steps but variation modes (exceptions, rework loops) and test full chain under realistic conditions.

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

Example: Waste Management, Inc. (WM) SAP ERP Implementation (US, 2007-2008) - BPM Failure and Remediation Attempts

What happened & why it failed

When Waste Management attempted to modernise its fragmented financial and operational systems (after many acquisitions) via a single standardised ERP (SAP), the goal was to achieve significant annual savings and standardisation. Instead, the project became a notorious example of technology-led change colliding with operational immaturity. The system was deemed non-functional; WM sued SAP for more than US$100 million alleging the software didn’t meet their business requirements.

From a BPM/automation perspective: the attempt was to standardise and automate – a higher level of process thinking – yet the foundational processes were too chaotic, fragmented, and unaligned to support the automation. In effect: automation outpaced process readiness.

Remediation Steps Taken

Although not as publicly detailed in remediation as other cases, some steps include:

• Recognition of need to define clear business process models and develop knowledgeable, decision-empowered users and managers. The complaint noted that WM “failed to timely and accurately define its business requirements” and lacked informed personnel.

• Withdrawal/settlement of the failed project, allowing WM to reassess its approach. The case forced reflection on readiness: whether processes were standardised, data clean, master-data governance in place.

• For future programmes (industry-wide) the case drove home the need for Pre-BPR (business process re-engineering) before ERP load: standardise, simplify, align before you load into a system.

• Use of governance to oversee process readiness, not only system deployment.

Lessons Learned & BPM Perspective

From the BPM and automation lens:

• You cannot automate broken processes. If your process foundation is chaotic, automation amplifies the chaos.

• Remediation must start with process-standardisation, clarity of business rules, robust master data, clear decision-rights, before loading an ERP.

• For your R2R process manager role: when you evaluate automation of the Record-to-Report, ensure you have mapped and cleaned your journal entries, reconciliations, master data, process exceptions, and ensure stakeholders are aligned and ready.

• Governance must shift from “we are doing project X” to “we are managing the process outcome end-to-end”, with business ownership, not just IT.

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

Example: General Motors (GM) Ignition Switch Crisis

What happened & Why it failed

GM discovered a fault in its ignition switch (that could slip from “Run” to “Accessory”, cutting power to engine, steering/brakes, and disabling the airbags) across millions of vehicles. Over the decade 2001-2014 this defect was linked to at least 124 deaths.

Why systems thinking failure? The issue wasn’t just a faulty component - it was GM’s inability to connect engineering, legal, safety, compliance, and customer feedback into a unified system‐level view. Each department treated its data as a silo. The defect became a systemic failure because no one owned the “vehicle system” end‐to‐end.

Remediation Steps Taken

GM’s remediation steps included:

• Creation of a new global vehicle safety organisation focused on executing “zero-defect safety systems for vehicles and customers.”

• A reorganised structure: vehicle engineering teams restructured for greater transparency, urgency and accountability.

• Creation of a “Speak Up For Safety” programme that gives employees and suppliers an opportunity to report or suggest potential safety-related items.

• Regulatory resolution: GM resolved its SEC investigation via an administrative order, and committed to stronger internal controls.

• Increased data analytics and field-investigation capabilities to surface emerging issues early.

Lessons Learned & Systems Thinking Perspective

From the Systems Thinking lens:

• Success is not just about individual processes or even end-to-end process flows; it is about the interactions between all parts of the system and ownership at the system-level.

• Remediation required building holistic responsibility (vehicle as system, not component), transparent feedback loops, cross‐functional accountability, and culture change.

• For process managers in R2R: you must ensure your process improvements do not just stop at the finance process, but link to operations, risk management, compliance, audit, and all the interdependencies — the “system” is bigger than your process.

• Governance must ensure that anomalies, excursions, exceptions are surfaced, aggregated and escalated beyond functional silos.

Summary of Failure Modes, Root-Cause Mistakes, and Corrective Actions Across Four Real-World Cases

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 - and each corresponds to a different level of process thinking and remediation.

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 back to real outcomes.

To summarise:

• Think broader than the process.

• Test deeper than the design.

• Learn faster than the failure. Because every “failed” process improvement is ultimately a lesson not just in what went wrong, but how the organisation fixed it (or tried to).

In short: Process management is necessary, but not sufficient. End-to-End is better, but still incomplete unless you embed governance, variability, human factors. BPM and automation raise the stakes — and require foundation work. Systems Thinking is the maturity frontier — but it only works when you build the process + end-to-end + automation foundations first, then link the system. 

As a process manager your job is to ensure the scope, objectives, and thinking level match the maturity of the process and organisation. And when remediation is needed, make sure the fix aligns to the same level of thinking.

Ready? Let's talk.