Why do business cases fail?

Business case scenarios often fail in either of two ways. Either they meet with skepticism or a cold shoulder from management and fail to achieve the immediate objective—obtaining funding, for instance. Or, they fail when the proposal or plan is implemented and the real costs and benefits turn out to be very different from the business case estimates. We believe that both kinds of failure usually result from the same root causes.

The first cause might be called "lack of history." Many organization do not save and use the experience of previous business case exercises to improve current efforts. The problem is that a business case in a complex setting probably requires arbitrary and subjective judgments (when allocating costs, or valuing benefits, for instance); It may require new data and information that do not exist in current budgets, business plans, or financial statements; it will very likely need cost and benefit models tailored to fit the action or acquisition under consideration (to determine what belongs in the analysis and what does not). These requirements can be very hard to meet adequately on a "first pass" business case, even if the best methods and expertise are used without reference to earlier cases.

All these requirements improve when validated and fine tuned over and over again, through cycles of business case analysis and implementation. The data and results will change from business case to business case but the methodology should be consistent and improved continually . This is the single most effective way to improve business case accuracy.

It is also the single most effective way to counter skepticism and improve credibility. A business case may be challenged on many different fronts, but primarily the following two:

• In terms of methodology
  Critics may say ...
  "The choice of cost/benefit items was biased."
  "The scope of coverage was inadequate"
  "Too much credit was given to 'soft' benefits."
  "The data are incorrect, out of date, or incomplete."
  "IRR is a misleading metric for this kind of scenario"
• In terms of analysis
  Critics may say ...
  "The benefit stream needs a longer 'ramp up' or 'learning curve."
  "Not enough weight was given to risk factors"
  "The projected gains are too optimistic"

Clearly, the business case sponsor has an uphill battle if both the methodology and the analysis have to be explained, sold, or defended at the same time. Methodology, at least, should not be an issue if it has been established, explained, improved, and accepted through previous business case exercises.

A second major reason that business cases fail has to do with the special nature of the financial business case, compared to familiar tools like budgets, accounting reports, and business plans. The latter have much better "text book" definitions and are much easier to approach with prescribed templates and content. Many business people fail to understand, however, just how undefined is the term "business case." A request for a business case is similar in some ways to a request for your personal resume: you have a lot of freedom to design the structure and select content; whether or not the result is effective depends on your ability to tell a convincing story with compelling logic and facts. This puts high responsibility and special demands upon the business case developer—a responsibility that is often under-appreciated. Here are some business case characteristics that need but often do not receive careful attention:

• A business case designed to answer the question "What will be the financial consequences if we choose X or do Y?" will probably be built upon incremental cost and benefit changes—financial impacts specifically due to the action or acquisition under consideration. Budgets, accounting reports, and business plans, by contrast, are typically built from total figures for inflow and outflow line items. Incremental values for a business case scenario must therefore be developed with a "base case" or "business as usual" scenario also in view, to provide a basis for comparison.
• Business cases—especially those that deal with IT, communications, and infrastructure changes—usually cut across boundaries: organizational boundaries, management levels, functional distinctions, and budgetary categories (operating vs. capital, for instance). Accordingly, contributions to business case content will have to be drawn selectively from all involved entities.
• Defining the business case subject does not completely determine which cost and benefit line items should be included. Cost and benefit models for this purpose will need to be constructed specifically for the scenario at hand.
• The business case may very well have to deal with non-quantifiable as well as quantifiable cost and benefit impacts. The scenario in view may anticipate important contributions to business goals which cannot be satisfactorily assigned a dollar value.

For more on how to deal with these special business case needs, see the Solution Matrix White Papers available for download from the Solution Matrix Ltd. White papers page. These topics are also covered in detail in The Business Case Guide.

« Should I build an "after tax" or a "before tax" business case?

© Copyright Solution Matrix 2004 - 2007