I once attended a talk in which a muddled speaker told us we should FAIL as fast as possible. After a slightly awkward moment and some fast back-peddling, the speaker corrected their message to say we shouldn’t be afraid of failure but if failing, then fail fast, learn from the mistakes and move on.
Dan Lyons references the fail-fast ethos in his book “Disrupted: My Misadventure in the Start-Up Bubble.” When looking at the things digital startups do well, he notes a sense of shamelessness - but not in a bad way. Startups often launch things that fade away or quickly move in a different direction. They’re not embarrassed. They are OK with failing, as long as they’re growing.
Although the fail-fast mentality helps promote taking risks and thinking differently, a potential downside to being too comfortable with failure is experimentation without clear business objectives and end goals. Rather than innovation, the result is wasted time and money. So, what's the right balance?
I started my career working on multimillion dollar enterprise IT system implementations. My first project was implementing the world’s largest global SAP project at the time. The first step in these transformations was always the business case, which included a comprehensive ROI model. A concrete ROI was the trigger that set off a meticulous transformation planning process, including people change management, business process reengineering, functional designs, technical designs and so on. We followed a waterfall approach, meaning each stage was signed off before starting the next. Any mistakes were potentially highly embarrassing. We would spend months poring over plans, costs and benefit models before lifting a technical finger.
While organized, the old-school approach was far from perfect. Large-scale IT projects often overran on budget and timeline. Benefits were often over-egged and costs underestimated. Many IT projects failed big and they failed slowly -- sometimes over years. Of the hundreds of ROI models I’ve worked on, rarely did an enterprise fully execute a subsequent benefits realization against the original business case. Arguably, the ROI models were shelfware as soon as the project started. Despite this, the business case process was still an essential stage-gate.
The need for this style of business case applies less and less in today’s digital landscape. Instead, we see a faster pace of digital and agile methodology’s influence. Agile process entails small, incremental, iterative work cadences with empirical feedback.
This helps cross-functional teams make progress, while responding to unpredictability. Agile teams evolve solutions through collaboration, allowing teams to fail small and fast, and quickly move on. This is in complete contrast to my earlier career, when starting a project without a scrutinized and ratified, not to mention fully documented, ROI model and plan would be unthinkable, never mind practically impossible. The ROI model was the vehicle to free up budget, get stakeholder commitment and mobilize resources.