Reimagining the Business Case for Digital Initiatives

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.

The detailed business case appears to have fallen out of fashion, around the time the idea of failing fast emerged. Few of my customers today have an ROI model as a prerequisite to allocating budget for personalization, for example. To bridge the gap between traditional ROI planning and today’s digital initiatives, I’ve written about how to measure the ROI of personalization. However, creating robust financial models for many customers just doesn’t seem to be that important - certainly not a priority. The ROI is often a curiosity at best. Dan Lyons mentions a sense of shamelessness in startups. In my case I see a sense of experimentation in many approaches to digital investments. Things might work, they might not. Where tech teams lead an initiative, the team doesn’t want to set goals for the business.

So, what’s going on? Similar to Dan Lyons (although not quite as old), I find myself having to adjust to a new way of working. I’m not arguing for a return to the old waterfall approach. Far from it. But I do think, as Dan articulates, in the race to adopt new ways of working, we’ve perhaps lost some of the good things in the old ways. So, I’ve tried to articulate my thoughts on this trend here:

I call this updated approach to writing a business case, a value assessment. This helps distinguish between the two and allows for experimental, agile element. Let’s look at what distinguishes a value assessment from a traditional business case.

With these lessons, I strongly believe value should be built into every digital initiative. Ideally, value assessments would be completed at the start of an initiative and should live with it. But, as above, they can also be completed part-way through and after too. Gartner found that nearly two-thirds of tech buyers would purchase more from existing providers if they saw value from their initial investment being clearly demonstrated.

The value assessment is a tool to help you think about what you’re doing and why -- it is a way of practicing (modeling) before execution. This helps you learn from potential failures before failing. It helps to create a clear robust plan, based on business returns. In the end, it is the value that should drive behaviors.

• Instead of documenting business cases with ROI models of benefits and assumptions in minutiae detail and assuming a minimum 3-5x ROI is required before proceeding
  • Value can still be in the form of a hard benefit -- it can include ROI and/or reduced total cost of ownership (TCO)… but it’s often softer areas of digital evolution that are equally important. These include the unquantified, intangible benefits, such as enhancing performance, presence, customer experience, reducing effort indirectly and/or simply keeping up with fast moving trends.
  • In digital, many initiatives are driven by fear of missing out (FOMO), or being left behind. Sometimes there’s value in taking small steps just to narrow the gap down the line, without necessarily realising hard benefits in the immediate term.
• Given the agile nature of digital investments, the value assessment should consider the entire digital journey rather than fixed time period. We should avoid a single upfront committed business case and instead work on an iterative model. Like agile, we should use small increments, respond to unpredictability through iterative work cadences and empirical feedback. I broadly recommend three stages to the value assessment: an initial high-level pre-implementation, followed by updates during the transformation and a benefits realization once the transformation is well underway.
• The purpose of the value assessment can change. Focus can switch, for example, from:
  • Pre-transformation: An assessment can help support managerial decisions and secure stakeholder commitment, helping decision makers identify what’s at stake. It can help secure the budget, managing total investment costs, with a clear justification for these
  • The assessment can also help during transformation. Many projects fail through lack of governance and control. A good value assessment can maintain overall buy-in and focus on execution.
  • The assessment should always act as a benefits realization baseline – this is essential for continual service improvement (CSI). If you’re not measuring something, how do you really know if you’re maximizing the benefit of that thing?
• A good value assessment, like a good business case, should help align your digital plans with your business strategy and ensure you have the right operating model for execution.
  • The value assessment should help set a goal but also help you realize that goal with sound advice to maximize potential value.
  • A value assessment helps drive digital platform choices, such as, open source, open APIs, cloud, security and governance. You can organize your change program and operations around your value assessment and ensure the people underpinning any digital transformation are all on-board. This will all help drive impact.