What Should Be Included in a Business Case?

Many of the enterprise clients we work with require a business case from their teams prior to funding any initiative. The rationale being (I assume) that if you force the team to think through the business viability of their idea it will produce more successful, well thought out products and services. At the same time (I continue to assume), it will reduce the number of “whims” and “you know what would be cool?” type of projects that so often see the light of day without any real justification. At face value, this seems logical and a good use of a team’s time. In reality though, the information often required in these business cases forces the team to predict their success years into the future without demanding any evidence for these predictions. If we were to completely redesign what a business case should include to make prioritization and decision-making more reliable, what would that look like?

Propose To Solve Problems

Most business cases I’ve seen start with the solution. “We’re going to build X!” Cool. Why? It would be far more effective to describe the problem you’ve uncovered in the world that you’d like to solve. Furthermore your team should dig into:

• How do we know it’s a problem?
• How many people have this problem?
• Why do we (the company) care about solving this problem??
• Is this a problem worth solving and why??

This line of questioning forces the team to figure out if this is something that affects a large swathe of users in a way that meaningfully impacts their experience with our products. Then, it asks the team to connect how that negative customer impact affects the company and to what extent. While many problems exist, not all are worth solving. Why should we focus on this one?

Define Success in Terms of Behavior Change

Since most business cases start with the solution, they also define success in terms of deploying that solution. “We will ship X into these 5 markets by the end of next year.” Again, cool. Why those markets? Why 5? How do we know we should even ship X in the first place??

Since we’ve hopefully defined the problem we’re solving at this point, we can now add success criteria to our business case that speak to the behavior change we’d like to see if we solve the problem. “Today we see at least 50% of new users abandon the onboarding process before completing a single transaction. If we solve the problem we want to reduce that to less than 1%.” That is far more compelling to a decision-maker, especially when coupled with the financial impact of that behavior change, then “we built something and put it in market.”?

Next, add to your business case:

• What will people be doing differently if we solve the problem??
• What financial impact would that have on the company??

Be Clear About the Riskiest Assumptions

Business cases are often written in definitive language. This is by design to instill confidence in the reader (aka decision-maker) that whatever is in the case is the most accurate information. The reality couldn’t be further from the truth. Perhaps the current state of the product and market are cold hard facts, but anything that looks into the future is pure speculation. It’s an assumption and assumptions are risky. That doesn’t mean that these predictions are necessarily 100% wrong but they will be wrong, to some extent. Let’s be honest about that.?

By defining your level of confidence in each of your assumptions and backing up those assertions with evidence you give the decision-maker a clear sense of where this business case may fail. This is good! We need to be honest that the market may shift in the next 5 years or that the strategic partners we’ve lined up aren’t the most stable companies.?

For your business case:

• Identify the riskiest assumptions in your pitch and how confident you are in each
• Describe why each assumption is risky and how it might fail
• Share any efforts that have gone into de-risking any of those assumptions

Consider using a risks dashboard . This is a tool that was created during my time at Neo in New York City by Nicole Rufuku and Amanda Lasnik. It’s a visualization of the elements in the above list. You can see an example of it at the top of this post.

Design Tests to De-Risk the Business Case

One of the best parts of using a risks dashboard is the questions that immediately follow: “What are we doing to learn more about [this risk]?” your stakeholders will ask. You’ve just been handed a gift. This is where you list the experiments you’d like to run to add more evidence into your business case. In an ideal world you would have already run some early research and experimentation to build the business case. Either way, this is where you can list how you might learn more about whether this is a worthwhile investment for the company.?

Specifically, you can add:

• The smallest experiment you can come up with for each of the untested assumptions in your risks dashboard
• Thresholds for success that would justify your team continuing to pursue this work
• Subsequent experiments you might run if the evidence you collect initially is positive

This part of your business case shows your decision-makers that you’re not just going to spend all of your funding in one direction in the hope that this idea will work. Instead, you’re going to methodically work through each of the risks, only deploying more capital when you’ve collected enough evidence to justify it.?

And the Rest of It…

Those of you who have written dozens of business cases are probably yelling at the screen right now noting how I’ve left out potential future revenue, profit margin, cost of developing the product, marketing, advertising, et al. I do think you can put these things in your business case. Realistically, your stakeholders would likely reject your pitch without this material. However, I would suggest that this section go under a big, red banner that says “THIS IS PURE SPECULATION” or something perhaps a bit more business friendly. Why? Because that’s the truth. At the beginning of an initiative we don’t have a clear sense of what it will take to build something. We can “t-shirt size” it and come up with small, medium, large assessments but until we know whether this is the way to solve our problem and how sophisticated our solution needs to be all of this is high risk speculation (hence the banner). As long as this section contains “if/then” statements in it a lot, it makes sense to add it at the end of the business case:

• If we can get 100 new enterprise customers in the next 2 years then we expect revenue to grow by x%
• If we can deploy it using our existing infrastructure then we expect development costs to stay under $Y
• If the competition’s “next big thing” fails to capture a majority of the market then we should see a Z% increase in product adoption

This is how I would approach writing a business case. I’m not an expert in this tool but every single business case I’ve seen has lacked these key factors that make it far more realistic and, frankly, honest.?

What am I missing? What should we add to our business cases to make them better? What should we remove? I’d love to get your thoughts.?

P.S. – As I was writing this article it seemed to me that maybe the Business Model Canvas should serve as an early draft for all business cases. It essentially asks teams to come up with all of these assumptions and then go test them. What do you think?