What’s Missing from Your Business Cases?

You may have seen the TV commercial for a credit card company with the tag line “What’s missing from your wallet?” Well, with all due respect, I’d like to tweak that line to ask “What’s missing from your business cases?”

My wife Elizabeth and I gave a tutorial on business cases at the most recent Building Business Capability conference in Florida. One segment near the beginning dealt with defects in current business cases. While discussing the topic participants gave the following list of things that were missing from their business cases.

Here is the list along with my comments on what to do about each one. The list is in the order in which we recorded them.

Business Value

The missing ingredient in this item is a common defect in many business cases today. Namely, they tend to be project justifications more than a true business case. To quote from one of my favorite books on the subject, a business case is “a document written for executive decision makers, assessing the present and future business value and risks related to a current … investment opportunity.”[i] Your business case must articulate the benefits to the organization of why it should undertake a proposed change. Otherwise it is not a business case.

The word “value” is popular today in project circles and we are fond of talking and writing about the word. Project or program value essentially means the business benefits we can expect. Organizations prefer tangible benefits in a business case, such as increased sales, greater market share, and decreased or avoided costs. But intangible benefits are also valuable, including higher customer satisfaction, increased search engine ranking position, and improved employee morale measurements.

Evaluation of Benefits

In addition to simply ignoring business value, omitting a plan to measure and evaluate benefits from an initiative is a major oversight. The SARIE framework includes the Evaluation component, which spells out a plan for measuring and evaluating the benefits of a proposal. Of course there is no guarantee that the benefits will actually be measured or evaluated – the affected business unit must see to that. But, a plan for doing so at least increases the odds of it getting done.

Problem Definitions

Oh, don’t get me started on this one! I’ve lost count of how many business cases without clear problem definitions I‘ve seen. In our business case training, we stress the importance of defining a problem before doing any other work. (The SARIE approach to business cases uses the term Situation to encompass both problem-type and opportunity-type business cases.[ii])

A specific and thorough problem definition lays the groundwork for the scope of a business case. It provides the beginnings of the rationale of why a change is needed. It provides a basis for getting disparate stakeholders to agree on “what problem we are trying to solve” with a project or program.

Accuracy of Data & Lack of Numerical Data/Analysis

(Two separate but related defects) Ah, data. As a former political leader once said (and I paraphrase), “facts are inconvenient things.” Some business cases simply ignore facts and data completely while making their case. Others tend to rely on rough estimates for articulating benefits and/or focusing on costs of a solution instead of presenting data to support the scope of the problem being addressed. Instead we recommend:

• Use data to delve into a problem to define its depth and breadth (i.e., scope).
  We advise doing this in the Analysis stage of the SARIE process.
• Work with stakeholders to determine data relevant to the situation,
  not just data to justify a ready-made solution.
• Use some rigor when projecting benefits, and include the methods for
  determining them in the business case.
• Use standard cost-benefit formulae to articulate the cost-benefit analysis.
  Our training recommends methods such as Payback Period and Net Present
  Value. If you prepare business cases you should at least know how to obtain
  the inputs to the various calculations.

Business Cases of Projects not Tied to Portfolio.

If I remember correctly, this defect was about the failure to tie business cases to the portfolio of projects and programs. What I took the defect to be is that people do not relate business cases enough to the strategic goals of the organization, which portfolios are meant to oversee.

Our advice is to keep business objectives in mind and include those when creating your Situation or Problem statements. Also, when evaluating alternate solutions to a problem (see below), use criteria of importance to the portfolio committee. Third, make sure the benefits articulated in the Recommendation section of your business case tie back to organization goals and objectives. This helps avoid the phenomenon so prevalent in organizations of launching projects because someone has money in the budget.

Variability of Possible Outcomes

I believe the person who brought this up was thinking about alternatives and that is certainly an important component of what we call bulletproof business cases. Typically there are multiple ways of solving a given problem, including many times the alternative of doing nothing. Be sure to include your recommendation as well as a few key alternatives and explain why they are not as viable as the one you recommend.

The process for determining the order is worthy of a blog itself. For brevity’s sake let me just say that you need key and clear criteria against which to evaluate each alternative. Rank-ordering alternatives against the criteria is a common way to evaluate and present them.

Please weigh in and share what is missing from business cases in the organizations in which you have worked.

[i] Making Technology Investments Profitable: ROI Road Map from Business Case to Value Realization, 2nd ed. ã2011 by Jack M. Keen.