How to get your IT project funded: Build a Solid Business Case: Step 4, Calculate Part 1

This is a rather lengthy section with a lot of specific tasks. I'm going to split this one into parts as well.

This is a rather lengthy section with a lot of specific tasks.  I'm going to split this one into parts as well.  Here are the tasks for this step:

My mentor at HP had the perfect saying; "when it's about money, get it right".  That is so true when it comes to developing and building a business case.  

Two of the most common reactions I see to some business cases are "I don't understand it" and "I don't believe it."  Here are some of the common reasons that decision makers reject calculations within business cases that I have seen and experienced as part of a business development team:

  1. computation errors:  believe it or not, I've actually seen the whole business case development team get completed discredited because their arithmetic wasn't correct.  They multiplied 200 x 20 and had 400 instead of 4000.  It was that simple of a mistake that the decision makers saw the team as careless.
  2. formulas' assumptions invalid:  formulas make assumptions your decision makers will not accept.
  3. metric disbelief:  regardless of what your business case team believes, the decision team considers stated metrics as inappropriate for the investment decision being faced.  (Ex. business case states that "employee turnover" is currently 15%.  The decision team believes that the "15 percent" metric is invalid.
  4. terminology confusion:  words have different meanings for different companies.  In an example of one customer of mine, they call virtual machines, "virtual worlds".
  5. explanation omission:  no definitions are supplied for potentially misunderstood terms.
  6. calculation obscurity:  the exact mathematical computations are nowhere in sight.

This step actually has three tasks associated with it.  The first is something that was created long before I started in doing this type of consulting.  I used these at HP, it's called a "payoff card".  It's a one page, structure document and a core tool to my calculations.  It's designed to collect and communicate succinctly the essence of what senior decision makers need to know regarding the value-based implications of a single decision criteria.  The payoff card has three components:

    1.  The explanation:  this describes what this payoff area is, why it is important as a decision criteria, now the solution being evaluated                   supports this payoff area topic, and what evidence and rationale exist to support key value assertions and calculations.

    2.  The calculation:  this displays all computations used to compute the tangible value of the Payoff card topic area.

    3.  The value ladder:  This is something that I showed you in the last step, but this shows how this particular Payoff card topic is aligned to
         other Payoff card topics.

Here is my take on payoff cards.  They have three uses:  (1) to review the eligibility of its information for use in a business case being developed, (2) to document specific factors unique to the ROI analysis being created and (3) to communicate these factors to decision makers and others who need to know. 

The payoff card provides advantages to you such as:

  1. Clarifies data needed, thus helping to assure crucial information in not inadvertently omitted.
  2. Encourages succinct explanations, thereby forcing sharpness of thinking and thus enhancing business case appeal and comprehension by busy decision makers.
  3. Provides flexibility, thus accelerating revisions, changes, and reuses.
  4. Speeds comprehension, thus increasing understanding.

Next I'll cover how to construct explanations.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.