What is Failure Demand?
by Bill Heitzeg
All companies that use or support software of any kind will, at times, see that software fails. The demand on your company’s resources to handle this failure is sometimes called failure demand.
For example, when a customer has a problem using your software and they call you to solve it, that’s failure demand. If it turns out that the phone call results in your support person discovering your software has a bug, the time to discover that bug, by both you and, if you’re being fair, your customer, is failure demand.
When your developers have to stop everything they are doing to fix the bug, that’s failure demand. And of course the time to redeploy the patch and the communications associated with this patch are all failure demand. Rigorously looking for, exposing, discussing, tracking and eliminating failure demand can have an extremely positive effect on any IT organization.
Mary Poppendieck writes extensively about this in her articles and books, giving excellent guidance to organizations that are looking to attack this problem. In her latest book, Leading Lean Software Development, Mary describes failure demand as waste: “Waste is anything that depletes resources of time, effort, space, or money without adding customer value.”
To learn more, pick up one of the Mary’s books, spend some time at Poppendieck.com or find out about our upcoming “Mary Poppendieck comes to Ann Arbor” event.
If it was a bug, then the system failed at detecting and/or repairing it BEFORE the customer.
Usually this is not “waste” in the above sense - some measure of time and effort was NOT put into the product earlier - too little for testing, code reviews, QC, so instead the resource is consumed AFTER the release instead of before. Typically the resources are diverted - lets tidy the icons instead of seeing if there is a memory leak.
You can deliver a 50% functional facade of a system to a customer, and as long as the customer doesn’t cross into the non-functional half, it will appear the same as a 100% functional system. But how much are you going to put into the 2, 3, or higher sigma features that few customers are ever going to try?
Code it in haskell? I don’t think so.