Why Failing Big is the Biggest Failure of All
When it comes to transformation, it is common to think “go big or go home”. After all, transformation is supposed to be more than mere change.
But what if going big IS what sends us home?
"The only real mistake is the one from which we learn nothing." – Henry Ford
This week I want to explore how our appetite for grand, sweeping changes often leads to spectacular failures – and how we might be better off failing small instead.
Perfect on paper, but does it actually work?
One of the moments that consultants get engaged is when things go wrong so I’ve had the benefit of analysing some projects that are seen to be failing (I’m not saying that consultants don’t generate problems too!).
One memorable example was when I was asked to review a logistics transformation project for an industrial products company. On paper, it was beautiful – a bold vision to revolutionise supply chains with end-to-end automation, promising faster products to market, real-time inventory tracking, and a transformed customer experience. The business case was solid, projecting millions in savings through improved efficiency. The project management was textbook, with detailed timelines and milestones. The investment controls were watertight. What could possibly go wrong?
$40 million and three years later, the answer was: everything.
Not only did the promised benefits fail to materialise, but the new system actually performed worse than the old one. Products went missing because locations weren't labelled correctly. Delivery drivers couldn't understand system instructions, leading to missed deliveries and frustrated customers. Inventory counts became unreliable because the automated tracking system wasn't accounting for real-world variables like damaged goods or partial returns. Customer service representatives, overwhelmed with complaints, found themselves longing for the old manual system.
The most painful part? Watching seasoned workers, who had mastered the previous system over decades, struggle with device interfaces that were supposed to make their jobs easier. These were people who could previously locate any product in their vast warehouse blindfolded, now reduced to fighting with a system that was supposed to be their digital assistant.
But here's the real tragedy: none of these issues were inherently fatal. The project's true failure wasn't in its ambition or even its execution – it was in its approach. By taking an all-or-nothing stance, the team created a perfect storm where problems couldn't be detected until it was too late. Front-line workers didn't see the system until launch training, where they were expected to master complex new processes in a matter of days. The business had changed substantially during the three-year development period – new product lines had been introduced, customer delivery expectations had evolved, and several key stakeholders who championed the original vision had moved on.
And while there were plenty of “test plans” and “launch plans”, there was little real-world validation. The team had conducted technical testing in controlled environments, but hadn't tested their assumptions about how the system would perform under real-world conditions. They hadn't anticipated how a slight delay in scanning could ripple through the entire supply chain, or how a minor UI confusion could lead to major inventory discrepancies.
The Cost of "Go Big or Go Home"
This "big bang" approach to transformation is seductive. It makes for great presentations and impressive pitches. But it's also like betting your life savings on a single hand of poker – thrilling, but rarely wise.
The problems with this approach include:
1. Theory versus reality: What works in PowerPoint doesn't always work in practice. Without real-world testing and feedback, it’s all theory
2. Feedback vacuum: When you wait years to put something in front of actual users, you're flying blind. By the time you discover issues, you've already invested so much that changing course feels impossible
3. Time warp: Business doesn't stand still while you build your perfect solution. Three years is an eternity in today's world – by the time you launch, you might be solving yesterday's problems
The Art of Failing Small
So what's the alternative? Fail more.
Sounds crazy but many failures along a transformation journey will likely improve your overall outcome. Jeff Bezos once said, "If you double the number of experiments you do per year, you're going to double your inventiveness." Similarly in transformation this isn't about avoiding failure – it's about failing faster, cheaper, and smarter.
In delivering large scale business transformation we can learn from practices that are common in Product Management and technology development. These teams have mastered the art of managing complexity and uncertainty through iterative development, continuous feedback, and incremental delivery. They release minimal viable products, gather user feedback religiously, and iterate rapidly based on real-world usage. The results speak for themselves: faster delivery, better user adoption, and more reliable outcomes.
These same principles can transform how we approach business transformation. Imagine if our logistics project had followed this playbook: starting with a minimal viable process in one warehouse, gathering feedback from actual users, and iterating based on real-world experience. Instead of a three-year black box of development, we could have had twelve quarters of learning and adjustment. Each small release would have provided valuable insights about user behaviour, process gaps, and system requirements. This approach isn’t about avoiding failure – it's about building success incrementally, ensuring each step forward is grounded in reality rather than assumptions.
Your Action Plan for Smarter Failing
Ready to start failing better? There are entire fields of practice and methodologies devoted to things like agile and incremental delivery, and I’d encourage the engagement of experts, but here are three core themes I think you can consider today:
1. Pilot everything: Break down your transformation into small, testable pieces. Could that massive logistics system have been piloted in one section first? Could a group of drivers have tested the routing system before the whole supply chain depended on it? Find ways to test crucial components before betting the farm.
2. Put users first: Get your solutions in front of real users early and often. Not just for testing – for actual use. If your front-line workers can't understand the system instructions, better to know that when you're testing with five people than five thousand.
3. Build feedback loops: Create multiple channels for gathering user input and – this is crucial – make sure you can act on this feedback quickly. If you're gathering feedback you can't use for months its of limited use.
The irony of business transformation is that trying to avoid small failures often leads to big ones.
Remember, the goal isn't to fail less – it's to fail better. Make your failures quick, cheap, and educational, and you'll find that success often follows close behind.
Until next Friday, keep failing forward!
Failure Friday is a weekly newsletter exploring the lessons we can learn from business transformation failures. Subscribe or follow me to get weekly insights on avoiding common pitfalls and building more resilient organisations.