.jpg)
In our first blog post of The Value of Taking a Spec-First Approach series, we covered why a compelling business case is important and what key components are typically included. Building on those topics in Part 2, we are going to take a look at the four key steps in crafting a rock-solid business case.
Step 1: Define the Scope
The first step is determining the scope of the project. As with most things in life, understanding the boundaries of an undertaking is crucial to get a full accounting of time and effort needed to complete it. When it comes to enterprise-level software projects, there are three primary areas to dig into when defining the scope: processes, departments, and technologies.
Processes will likely be the first component uncovered during scope definition. People at the execution level of a process will often be the first to raise their hands when the activities are causing problems. The pain caused by these activities will be felt by people either at the organizational level, the workforce level, or both when something is exceptionally onerous to complete day in and day out.
In our experience, robust process mapping is an indispensable exercise to identify the steps, people, and pain points in how something gets done.
From this, the next piece is often uncovered: departments involved.
With increasing complexity in nearly every facet of life today, it should come as no surprise that an increasing number of departments are involved in each and every process. Though a new product introduction may seem simple, by the time a product is even approved for manufacturing, R&D, Quality, Packaging, Finance, Procurement, and Operations teams may have all offered their input in some way, shape, or form. By identifying who is involved and when, a map can be built to visualize whose “buy-in” is needed.
Additionally, there is a list of people of which to ask about the third item: technologies.
Technologies can often be one of the most difficult pieces of this puzzle to assemble. Not only do many systems span large swaths of an organization, but often there is low visibility into systems used outside of one’s department. Add in strong preferences or allegiances to software ecosystems, and it can often be difficult to even begin a conversation about swapping existing technology out. However, identifying the gaps in an organization’s technology footprint can often be a huge opportunity to promote new systems. Often, if there is a system being replaced, there is an existing cost that can be leveraged when justifying new spend on new technology.
Step 2: Identify Key Stakeholders
The second step when building a compelling business case is identifying the right people. Thankfully, a lot of this work will have been done already during the process mapping exercise. However, you should consider taking it down a level and get a better understanding of the different functions within each department.
From our experience, there are three overarching categories of people when evaluating a software project: direct users, indirect users, and executives.
Direct users are going to be the power users of the system. Their input is crucial when understanding the exact pain points that will be solved and designing the functionality. They will be charged with adding and manipulating data within the system. Often, information gathered from these groups will serve as the backbone of the business case, as it is their pains and gaps that are being addressed with a particular project.
A second group of people are the indirect users. These will be people that may have a tangential relationship to the direct users, but will consume data that is created or manipulated in the system. For example, finance and procurement are often two functions that benefit from data inside a specification management system, but either don’t have a license for it or are added as read-only users. Indirect users can provide invaluable feedback when understanding any necessary integrations between the software being evaluated and the existing tech stack.
A final group are the executives. While many times they are given licenses to use a piece of software, they will often care the most about the reporting and dashboarding capabilities and how effectively the data can be rolled up to see its impact on the business as a whole. Though reporting and dashboarding alone will rarely be the criteria by which a project proceeds, it can certainly be a consideration where one doesn’t.
Step 3: Articulate Value for Each Stakeholder
Once the right people have been identified, a third step is asking the right questions. Without adequately understanding the needs of each group, it will be impossible for a business case to give a full accounting of the benefits to be delivered. How this information is gathered can vary from situation to situation, but in our experience, these three areas are crucial in understanding how each team will be affected by a software project: pain points, time savings, and aspirational goals.
When it comes to pain points, it’s important to determine where pain is caused by process vs. technology. Technological pain can often be addressed through implementation of a new system - provided the technology causing the pain is either going to be replaced or be fed by a new data source.
Process pain can often be more difficult to address. Many organizations can be married to a given process because “that’s the way we’ve always done it”. Yet, that is rarely the best path forward. Finding a mix of ‘out of the box’ functionality and existing process will not only make administration of the software easier, but it will help drive better adoption once the software is live.
While time savings for the sake of saving time is often a futile pursuit, especially in the eyes of executives. However, the most important question around time is ‘what isn’t being accomplished today that can’t because of the current process & technology landscape’? Typically, it’s a symptom of reactivity instead of proactivity, which can take the form of uncompleted optimization projects, prolonged NPD/NPI cycles, among numerous other uncompleted projects. Being able to paint an accurate, plausible picture of what these time savings can drive can serve as a lynchpin for a robust business case.
Lastly, aspirational goals can round out a thorough business case. This may be one of the most difficult areas to quantify, but even using qualitative details can be impactful. This can certainly roll in details of what time savings will enable, but even beyond that, perhaps integrating data can cut down on procurement spend errors. Maybe it will drive faster NPD/NPI cycles, or even enable lower manufacturing scrap rates. You will have a sense of what isn’t getting done today, but including it will be a key component in the final step of building your business case.
Step 4: Message Through Storytelling
The fourth and final step to building your business case is summing the three previous pieces into a compelling narrative. Humans are drawn to stories, and taking this qualitative and quantitative data and distilling it into story that combines comparing and contrasting present vs. future state and a financial summary of the proposed impact of the new solution will give the detail needed for executives to understand why a new process and technology are needed to address the issues identified.
Finally, benchmarking the current state will allow for improvement metrics to be quickly and easily created, enabling a before vs. after story to be quickly crafted and updated as time goes on.As you can see, the path to a robust business case is not for the faint of heart. Thorough definition, discovery, and execution are all needed to make a clear and compelling case to leadership for why change is necessary.
To recap, the four steps to building your business case are: define your scope, identify the right people, ask the right questions, and tell the story. Follow these and you will not only get your leadership’s attention, but also have a great chance of getting your project approved.
In the third and final installment of our series The Value of Taking a Spec-First Approach, we will take a look at which areas typically see measurable business value when organizations adopt a spec-first approach, and provide some real-world examples of value gained with Specification Data Management solutions.
Learn more about the value of taking a spec-first approach: VIEW PRESENTATION.
