.jpg)
Gone are the days where enterprise technology purchases are straightforward. Not only are there numerous vendors for any given software category, but often combinations of solutions from each category can provide the necessary functionality. No purchase is single threaded; mix in competing priorities across departments, technical validation, limited budgets, and it becomes quite the uphill climb to just purchase a software solution. And, we haven’t even touched on implementation! However, there’s an oft-overlooked deliverable that can help cut through all of the noise and put your project on the fast track to success: a comprehensive business case. Simple in theory, yet difficult to build in reality. In this first of three posts on the value of taking a spec-first approach, we’ll cover why business cases are necessary and what key components are essential for a rock-solid business case.
Step 1: Define Pain Points
In order to map the journey to our destination, we start by defining the current state. What kind of pain is caused through existing technologies or processes? Without pain (and oftentimes today, without significant pain), it is difficult to sway leadership on why change is necessary. Throughout our time in the software and consulting worlds, we’ve find that pain can be summarized in two main categories: organizational pain and workforce pain. Organizational pain is often what impacts financial performance through symptoms like margin erosion, inhibited revenue growth, or increased regulatory burden. Typically, progressing on these metrics are what a company’s leadership cares about most. The other category is workforce pain, which are the barriers or obstacles experienced in executing day-to-day assignments. This can be manifested through unnecessarily repetitive tasks, an inability to get to value-added activities, or tedious data explorations in order to respond to reporting requests. While addressing these items themselves may not be the most compelling argument to leadership, when they result in linear headcount expansion or high turnover, there are certainly financial metrics that can be associated with solving them.
Step 2: Illustrate the Benefits
Once the pain has been identified and articulated, a second core component of a solid business case is illustrating the benefits that can be achieved once the pain is fixed. This area is the make-or-break section of a business case. Many organizations have defined thresholds around the ROI required to proceed with a given project. Thankfully, many software companies now have teams dedicated to assist in crafting these financial metrics and qualitative stories. Similar to our two categories of pain, there are typically two categories of quantifiable value: Revenue increases and operational margin reduction. For organizational pain, how can the operational margin be impacted by the proposed software solution? Will the solution alleviate regulatory or compliance pains? What about revenue? How can revenue be generated more quickly and efficiently? For workforce pain, how can the solution free up time for teams to complete more value-added activities? And how would those value-added activities impact time-to-market or on-time in-full customer deliveries? With all of these value drivers, what are the quantifiable metrics that can be leveraged to track success? Clear articulation of the above will create the bedrock of a solid business case.
Step 3: Describe Future State
The third component of a thorough business case is describing the art of the possible - what the future or aspirational state will be after the software has gone live. This may be a bit more qualitative compared to the first and second components, but this is where the art of storytelling comes into play. To kickstart the creative juices we ask: What goals or activities have seemed impossible until now because of the gaps in process and/or technology? Are there seemingly lofty revenue growth goals that would be more attainable if your team had more time?
Be Proactive, Not Reactive
From our experience in consulting, we’ve noticed that robust analytics and reporting is often rarely possible due to disparate data stored in disconnected documents and systems. A related goal is around driving proactivity rather than reactivity. Frequently, a lack of cohesive data is the underlying cause behind reactive operations. Another aspiration for many organizations is increased cross-functional collaboration, which is often inhibited by siloed systems. A common result of these siloed systems are disconnected teams, which can drive a lot of the workforce pain described above. Utilizing a common tool across teams that promotes collaboration not only addresses many of the causes behind the pain, but can also drive improved financial performance.Now that we’ve covered the “why” of a business case and a high level of the ideal contents, we can get a bit more tactical. Stay tuned for part 2 of this blog series as we dive into The Four Key Steps to Building Your Business Case.Learn more about the value of taking a spec-first approach: VIEW PRESENTATION.
