We Analysed Thousands of Hours of 'Waste.' Here's What We Got Wrong. (Spoiler: It was Failure Demand)
- Sam Lawford
- Nov 27, 2025
- 3 min read
Updated: Dec 16, 2025
When I started analysing touch time data for a major UK insurer's claims operation, I thought I knew what I'd find.
Inefficient processes. Slow systems. Undertrained staff. The usual suspects.
However, I discovered we'd been looking at the problem entirely wrong.
And that misunderstanding was costing the business thousands of hours annually.
The Original Hypothesis (That Turned Out to Be Wrong)
Like most operational excellence projects, we started with a simple question:
"How can we make claims processing more efficient?"
The conventional approach would be:
Time-motion studies
Process optimisation
Technology upgrades
Automation
Performance management
We mapped every step. We timed every task. And then we noticed something odd.
Handlers were spending significant amounts of time on work that added zero value to customers.
The Breakthrough: It Wasn't Waste. It Was Failure Demand.
Here's what we discovered:
Some of the time our claims handlers were spending dealing with work only happened because something earlier in the process had failed.
The impact? Significant operational capacity consumed by work that shouldn't exist. This wasn't about working faster. It was about eliminating work that shouldn't be there in the first place.
The Lesson: Question the Work Before You Optimise It
If I could go back and give my past self one piece of advice at the start of this project:
"Before you ask how to do the work faster, ask why the work exists."
Most operational waste isn't visible in time-motion studies.
It's hidden in:
Work created by earlier failures
Reactive processes treating symptoms
Systems optimising components, not the whole
Our 'waste' wasn't inefficiency.
It was failure demand we'd been tolerating for years.
The Uncomfortable Truth
The hardest part of this project wasn't the analysis.
It was getting people to accept that most of the work they'd been doing for years shouldn't have been necessary.
That's uncomfortable.
It feels like blame. (It's not.)
It feels like saying people were doing useless work. (They weren't - they were compensating for system failures.)
But until you face that reality, you're stuck optimising symptoms instead of fixing causes.
The Bigger Implication
How much failure demand exists in your operation?
My guess: More than you think.
Because failure demand is invisible until you look for it.
It disguises itself as "necessary work" and "how things are done."
It hides in:
Call-back lists that shouldn't exist
Follow-up tasks that compensate for incomplete initial work
Checking work that should have been right first time
Reactive customer service fixing problems you created
You can't optimise your way out of failure demand.
You can only eliminate it by fixing what creates it.
How to Find Failure Demand in Your Operations
Step 1: Map Your Touch Patterns Track any work item (claim, ticket, order):
How many touches does it require?
What triggers each touch?
Which touches add customer value?
Red flag: Items requiring multiple touches that should be straightforward
Step 2: Ask "Why Does This Touch Exist?" For each non-value touch:
What failure created this work?
What should have happened earlier?
How do we prevent it at the source?
Red flag: Answers like "That's just how we do it"
Step 3: Categorize Root Causes Group failure demand by type:
Information failures (missing/unclear data)
Process failures (ambiguous steps)
Communication failures (reactive service)
System failures (poor design) Red flag: Same root cause across multiple failures
Step 4: Fix the System, Not the Symptom Don't optimize the failure work. Eliminate it:
Standardize information capture
Clarify process steps
Enable proactive communication
Redesign broken systems
Red flag: Solutions that make work 20% faster vs. 100% eliminated
Want to Find Your Failure Demand?
This type of project can identify substantial operational capacity through systematic identification and elimination of failure demand.
The methodology:
Value demand vs. failure demand classification
Root cause analysis (not symptom treatment)
Systems thinking (optimise the whole, not the parts)
PDCA testing (prove before scaling)
Common signs of failure demand:
Work requiring multiple touches that should be simple
High volume of customer status calls
Rework and call-backs
"That's just how we do it" processes
Sound familiar? Let's talk.
Comments