Making a Business Case That Sells: Where CIOs Go Wrong

By Marc J. Schiller  |  Posted 09-21-2011 Print Email
It’s Q4 and you're fighting for your 2012 tech budget. To help you win your business battles, we turn our attention to the centerpiece of internal project sales success: The business case. But as usual, we have a twist on the way it’s done.

It's Q4 and you're fighting for your 2012 tech budget. To help you win your business battles, we're featuring a series on the most effective and advanced methods for selling your IT/business projects. Last week we met the Madison Avenue Presentation Technique. This week, we turn our attention to the centerpiece of internal project sales success: The business case. But as usual, we have a twist on the way it's done.

What's wrong with most business case presentations?

Basically, they don't sell. They have lots of facts and figures and information but they don't really sell.

Why's that? Because the vast majority of business cases are missing two critical ingredients:

  1. an outcomes-based vision, and

  2. the promise of real-life change.

I'll explain what these are in a minute but first a quick review of the building blocks of a business case to make sure we are on the same page.

The typical business case presentation

If you take a look at a typical business case presentation, you're likely to find it structured into three big parts:


Part I - Project Overview. I've often heard this part referred to as The Irritating Part because it is usually an overly detailed review of the project given the audience and purpose of the presentation. By the time you are presenting the business case for the project, the audience better have a pretty good idea what it's about and require no more than a one-page refresher.


Part II - Indirect Benefits.This is often called The Mushy and Fluffy Part. You know what I mean. It's the general statements about benefits that the project/system will bring, such as the "improvements in productivity for our people," "improved insight into our customers" or "the benefits of applying 'best practices." These may all be true, but executives tend to discount these benefits heavily when considering whether or not to fund a project.

Part III - Direct Benefits. This comes in two flavors:

  1. Revenue Generation - Affectionately referred to as The Dreaming of IT, this is the part of the business case where the IT team makes the case that the system will directly generate improvements in revenue production. This is most commonly found when the specific project is focused on supporting revenue-generating activities. Making this case believable is tough in most companies--the sales and marketing groups often shoot it down saying something like, "the system is only a tool," and emphasizing that it's the people that count. After all, it's their bonus dollars on the line. (There are of course a few notable exceptions, such as ecommerce and CRM projects.)


  2. Cost Savings - This is The Meat of the business case and where the executive team spends most of its time. This part of the business case presents: (a) the current costs that will be reduced due to the project, and (b) the future costs that will be avoided as the result of implementing the project/system. Cost reduction and cost avoidance. Ahhh...Nice highly financial and tangible items.

So, what's the problem?

Well, when the executive team finally reaches the meaty part, that's when they really dig in. Until then, they have only heard the mushy general stuff. And, rather than being argumentative about generalities they wait for The Meat.

Once they have some real numbers, decision-makers kick into challenge mode. Typically they challenge the assumptions for achieving cost savings and question the basis for cost avoidance. Pretty soon you can feel the skepticism in the air and everyone is focusing on whether or not your projections are realistic or attainable given the nature of the business. In short, the business case isn't selling.

It's not that the typical business case is wrong. The problem is that the typical business case doesn't go far enough.



 

Submit a Comment

Loading Comments...