How to Build a Winning Business Case

David Bishop, Senior Member IEEE

david@agile-worx.com

 

Over the years, I’ve developed several business cases. These cases have taken a number of different forms, depending on the undertaking at hand. However, I’ve found that a good business case needs to have certain elements to be successful. To my surprise, I’ve also found that many people have different ideas of what a business case entails, and its purpose. Occasionally, I’ve had debates with colleagues and clients over this very issue.

 

What follows is a two-part series on business case development, starting with defining the concept and the elements of what makes a winning business case. The second part of the series will put these concepts into action with a real-life example from one of my clients, the topic being arguably one of the most difficult cases to make: the adoption of technical standards.

 

What is a business case? Really?

 

Dictionary.com defines a business case as a justification for a proposed project or undertaking on the basis of its expected commercial benefit. Now that sounds very succinct doesn’t it? I’m going to list the commercial benefits of my project or undertaking to motivate my stakeholders to take action on it. But is it really as simple as that? People’s ideas of how to justify the commercial viability of an idea, undertaking, or project can vary widely, and often with mixed results.

 

When turning in a business case draft to one of my clients recently, he asked, “Where’s the other side of the story?”

 

I looked at him incredulously. “What do you mean?”

 

He went on to say that he wanted to know the outcome of both options. What would happen if we took on the initiative, and what would happen if we didn’t?

 

They were worthwhile questions to be sure, but it wasn’t a business case. What he really wanted was something else entirely. A business case is not an objective research study, or a fact-finding mission, although it can include elements of both.

 

Here’s my definition: A business case is an argument, supported by facts or data, that persuades stakeholders to take action on or offer support for your project or undertaking. Writing a business case means you are taking a clear position on something, either for or against it, and you are going to support that position in a way that informs and persuades. When it is time to build a business case, it’s not a time to be wishy-washy or indecisive. You must know where you want to go and how to get there. A decision needs to be made, and if you’re not ready to make one, then you don’t need a business case. This begs the next question.

 

When is a business case needed?

 

Simply put, a business case is needed when you have an undertaking or project you want to initiate, and you require the support or assistance of others (typically stakeholders or executive management) to make it happen. The undertaking in question should fit the needs of the business in some way, or provide commercial benefit of some kind. Perhaps it solves a procedural problem within the company, saves money, creates efficiencies, or maybe it’s a new idea for a product or service. Overall, it must benefit the business, and you must have the information necessary to prove it.

 

If you aren’t sure about your idea, or don’t believe you have enough supporting data, then you aren’t ready to write a business case. Perhaps more research is warranted. More importantly, if you don’t need anyone else’s help to make it happen, then a business case is only an academic exercise.

 

What should the format of a business case be?

 

So you’ve decided that you need a business case but don’t know how to construct one. Although technically speaking, it could take many forms, the best business cases include a presentation that is short and to the point. It should be succinct enough for executives to comprehend quickly, but with enough background data to deflect any potential objections that may arise. Your business case should include the following elements, in the order presented below:

 

1. Define the Problem: Outline the problem, challenge, or opportunity at hand. This could be only a slide or two, but it should clearly communicate a significant issue or opportunity that directly impacts your audience.

 

2. Propose the Solution: Summarize the solution, or action you want the group to take. You will go into details as the presentation unfolds, but you want your audience to know up front exactly what it is you are trying to accomplish. Do you want to purchase a tool? Create a new department? Adopt a specific technology? Whatever it is, do not keep your audience in suspense. Make your ultimate goal clear.

 

3. Research the Concept: Whatever your goal, it is important to initially illustrate the viability of the concept itself. Is it a good idea? If so, provide some general research or support proving it to be. Your stakeholders may have heard of the concept, but could have the wrong idea based on misinformation. This misinformation can torpedo your business case before it even begins. Immediately set the record straight and clear up any misconceptions so stakeholders will remain engaged throughout the presentation.

 

4. Support with Case Studies: Although we all like to convince ourselves that we are trailblazers when it comes to technology, more often than not, stakeholders will want to know if other companies have already done the same thing and their results.

 

A good set of case studies can speak volumes. Have other companies done this? How have they done it? Are they like us? If not, how are they different? What were their results?

 

The more case studies that you can find supporting your objective, the more likely stakeholders will take action. Having several successful and relevant case studies will tell your executives that they may be behind the competition! Having few or none makes the business case appear too risky. Being the first may appeal to some, but in many cases it is best to be somewhere in between. Relevancy is the key here. It is important to use case studies that are as close as possible to your own company and situation.

 

5. Detail the Solution: In the section above we summarized what we wanted to do, but in this section we will talk about the “how.” How many people will be needed? What resources are required? What are the options to implementation? What are the organizational changes needed? Are there any technology or tool acquisition costs? What is your staffing model? What special skillsets are required, and do we have them or need to acquire them?

 

In short, the stakeholders want to know exactly what is being asked of them. Draw on points learned from your case studies and previous company projects to build out your solution. Be open to new ideas when covering this section of the case. Stakeholders often have a few. For example, they may know of some upcoming organizational changes that could impact your staffing model, or there may be a suggestion in the works similar to yours that would be enhanced if they are combined. Whatever the new ideas may be, consider them seriously and carefully. By doing so, you will increase your chances of approval.

 

6. Provide Analysis: This is arguably the most important part of the business case, and often, the most contentious. You will need to provide an analysis, complete with numbers and graphs, which describe the cost effectiveness of your proposal. The most commonly used tool is the Cost-Benefit Analysis (CBA), which as its name implies, compares the benefits of an undertaking with its costs. Hopefully, with the former outweighing the latter. It is important to understand that this is not the only type of analysis available to you.

 

A CBA is typically designed for a short-term view, generally one to three years. This timeline is sufficient for most projects. For some situations, such as adoption of technology, standards, or processes that are strategic, the true benefits are not realized for several years, or the benefits may aggregate in small increments over time. In some cases, acquiring a significant amount of technology may have a large upfront cost, taking many years to offset. The next article in this series will illustrate how to handle this situation using a recent example.

 

7. Decision Point: Summarize the business case with the key points from the presentation, and end with a call to action. You want the group to make a decision and now is the time!

 

Now that the key components of the business case have been outlined, what follows are some characteristics I have found to be common among the more successful cases.

 

Characteristics of a winning business case

 

• Take a top down approach. Begin simply with a problem summary and solution followed by an unfolding of the details. Do not overwhelm stakeholders with too much initial information. Take a teaching approach, as the business case provides a lot of information to digest in a short period of time. As someone who has performed all of the due diligence including research and analysis, remember that you are the expert in the room.

 

• Stay relevant and focused. Be careful not to stray too far away from what you want to accomplish. When discussing technology, it is sometimes very easy to get off topic. Be sure that you keep the presentation, and any discussion with the stakeholders, on point. Again, take a teaching approach here is a good idea.

 

• Provide options. When developing the detailed solution, it is a good idea to provide at least two or three options. This is what I call a “low, medium, and high” implementation. Giving stakeholders options shows that you have done your homework. It also increases success by making it more likely a decision will be made. On a more aesthetic note, executives often don’t like to feel like they’re being told what to do. Providing options gives them control not only on the final decision — which they of course already have — but also on the selection of the solution itself. Asking for help is also a good technique for obtaining engagement and buy-in.

 

• Be thorough. This may come without saying, but it is where many business cases fail. A complete analysis combined with references and documented case studies is hard to beat, and makes it very difficult for stakeholders to say no.

 

• Do the numbers. A cost-benefit or other analysis including numbers and visual representations (graphs) is crucial.

 

• Ask for a decision. As with job interviews, it’s a good idea to ask for an immediate decision, even if it’s quite likely not to happen. If a decision is not forthcoming, ask why. What are the objections? Are there any unforeseen hurdles? If a decision does not happen, be sure to document next steps.

 

• Be prepared to address common misconceptions. While performing the research and analysis for the business case, be sure to look into the negatives as well as the positives, and be prepared to address them. A miss here could end it.

 

• Be mindful of your audience.   Are the stakeholders executive management or product managers? Make the business case shorter and concise. Are they from the technology organization? Details with a special focus on common technical issues would be best.

 

 

How do I know if it was successful?

 

Your first answer to this question may be, “wouldn’t it be obvious?” Well, yes and no. You may get thru the presentation with no or few objections; have lots of nodding heads, with everyone seemingly in agreement. However, if a clear decision and path forward is not obtained, then it wasn’t really successful. Remember, you aren’t just making a presentation to give people something to think about, you need them to make a decision!

 

If you press the issue and the response is “we will think about it” then ask them what was missing. Get them to voice their concerns so you can address them right away. You may find that you do have to go back to the drawing board and refine, but at least you’ll have a plan to come back at a later date to revisit the proposition. Making a case means a need to win, to gain acceptance and action, and if you haven’t clearly achieved this goal then it is not a total success.

 

Now that you have a clear idea of what a business case is, how to know if you need one, and how to write a persuasive one, the next step is to show some real-life examples. In the next installment of this series, I’ll take you thru the process of “making the case” in what could be one of the most challenging contexts: adoption of standards.

 

Whether you need to adopt IEEE, ANSI, IEC, ISO or other standards, building a case for doing so can be challenging because the benefits are often hard to quantify and don’t happen quickly over time. In my example, I’ll show you how I developed a winning business case in this most difficult of contexts by taking you thru the process of adopting the IEC Common Information Model (CIM) standard at a major power utility.