I define a "business case" as an analysis describing the business reasons "why" or "why not" management decision makers should select specific investment options.  Some of the other terms I've heard to describe business cases are, "cost-benefit' analysis, ROI study, etc.  I want to address business cases in this post, but as a key part of any business case I'll touch on ROI.  So what is your definition of ROI?  Most people who use the term ROI have so many definitions that if you ask 20 people, you'll get 20 different answers.

One of the staggering statistics that I read a while ago by the Standish Group was that of the $5 trillion dollars worldwide that have been poured into IT investments, 83% of IT projects missed cost and delivery goals, and 31% were canceled. Shocking? You bet.  These types of shortfalls can shift the destiny and reshape the character of firms.  A real-world example?  K-Mart vs. WalMart.  A real lack of IT vision and commitment sealed K-Mart's fate in industry leadership, giving WalMart the leadership they still hold today.  I've seen many business cases with ROI figures that were awesome, but it was all a ruse.  Some of these plans were full of faulty logic and just plain bad conclusions.  Now this is a double-sided issue.  Because of faulty logic, bad conclusions and wrong calculations, some great projects get rejected.  Why?  the leading culprit is the business case.  Rather than being the accurate explanation of the true business value potential of a project, the business case unintentionally sunk the project's success.

So my goal here is to share with you some of the things that I look for and do when helping clients develop good solid business cases for IT projects.  The reason I get involved is that the business case is one of the most important, but yet most misunderstood and underutilized resources when it comes to IT project management.  I'm sure you will all agree with me that the true goal of a business case is to help management decide the true business value of a potential investment right?  Good.  Now I have spent quality time inside some very big companies, so I know that when it comes to IT investment choices it's a hostile environment full of misunderstandings, confusion, politics, and emotion.  Now as I pointed out earlier the number of IT projects that missed cost and delivery goals along with the percentage of projects cancelled has certainly put a very poor taste and generated an environment of mistrust among executives. So even if building a good business case is a way to help overcome some of the challenges in environments like above, another problem shows up.  How can a business case be built that both executives and the team can trust.

One word, "Structure".  By taking some time and putting some structure into business case development we can do wonders for producing quality business case documents.  I have followed seven steps in developing business cases and I'm going to share them with you.  There are many sub-discussions we can have for each step, but I'll save those for additional posts if that's ok with you all, otherwise, I should just write a book.  I'm going to give you just the high-level for each and if you want to know more just email me.

1. "Scope".  This is where we will avoid back-end confusion if we are clear in our definition of the business case contents and project plan.  In this step we will identify what resources are needed.  It will help us avoid time-wasting detours that pop up in every project and it will accurately set management expectations.  A business case is far too important analytically and too highly visible politically to contain avoidable mistakes.  But guess what?  this is where I have seen a lot of folks create those needless errors.
2. "Criteria".  This step is where we will determine who our audience is and the factors they will use (criteria) to make the investment decision.  By doing this step we are going to hopefully avoid missing any key decision criteria.  If anything important is missed it will undermine the validity of our business case and us.
3. "Align".  A simple definition here is, keep all your activities and resources heading in the same direction.  Here is where we are going to take our decision criteria, confirm it, and then link it to key business goals.  One key thing I want to say here is that our best business value occurs if we directly support our enterprise needs.  As a rule, I have always kept this thought in the back of my head.  An enterprise will consistently succeed only when all of its parts are in a strong cause-and-effect relationship with one another.  There is a great story about Starbucks here, but I'll share that later.  I can guarantee you that "alignment" is at the front of every executive mind when they are faced with making decisions on IT investments.  We need to ask ourselves this question; How strong is the cause-and-effect between investing in IT Project A and realizing key business objectives?  This is our job as the business case team to discover and communicate the strongest possible, truest value alignment we can.  Now there is a deeper conversation here around testing to make sure we have alignment, but I will hold off for another post.
4. "Calculate".  I was told by my mentor that when it's about money, get it right.  I can stress this enough folks.  The purpose in this step is to compute the realistic 'hard-money' costs and benefits.  Why?  Money impacts have a major influence on investment decisions.  I have seen many times that a client has built, what they thought, was a great business case only to be told in an executive level meeting that "I don't understand it" or "I don't believe it."  Why?  After reviewing these business cases I found some very basic arithmetic errors.  No matter how small, this will discredit you and show carelessness. 
5. "Prove it".  All the best work in the world around calculations, scope, criteria, etc are worthless if no one believes them.  I define proof as simple as this, evidence sufficient to convince someone that something is true or believable.  Our evidence is really important in business case development because every executive I've come up to is skeptical when it comes to approving IT investment requests.  We need to use the most compelling evidence we can find to make our calculations and claims believable.  I have seen through my years that it's reasons, not arithmetic that ultimately make a business case a success.  You have to play the role of an attorney or a detective here.  Keep our explanations logical and rational.  I have seen some cases that used reasoning that was ambiguous, illogical, or completely untrue.  I have also seen where folks used weak proof.  Proof that couldn't stand up to a slight breeze let alone some good solid management push back.
6. "Analyze".  Here is where we sit back and determine what type of information has been created from all that data we have gathered and what recommendation should be made and why.  Here is where we have to align the values to key management drivers of business success.  Our recommendations need to be logical, believable, and most importantly, clear.  We can't forget to also base our recommendations on both tangible and intangible factors.  In this step is really where the computation of ROI is done.  Here is where we will "do our math" and calculate the overall financial results using IRR (Internal Rate of Return), NPV (Net Present Value), ROI (Return on Investment), and payback period (or whatever is requested by the executive decision makers).
7. "Explain it".  I can't stress enough that the business case "story" we are about to tell has to be easily understood.  We need to speak the audience's language.  If we do, we raise the likelihood of acceptance of our business case recommendations, and we can really improve our audience's ability to share the message with others.  I like to use stories that illustrate key points if I can.  I'm not a big PowerPoint fan, so I would encourage you to prepare well and use the whiteboard to share the content if possible.

I want to leave you with this little tidbit of information.  I was told this by my mentors and heroes during the early days of my career.  At its core, the worth of your business case is not in its mass of numbers.  Your business case's value will always be from the quality of the guided "conversation" it stimulates about the shape of the future.  I can tell you from first hand experience in some of the toughest crowds (executively speaking that is) that I have ever been in front of, conversations move people to action.  All this data that we gathered is merely the back drop, albeit it is still very very important.

Article Comments

posted by Michael Keen - 03/27/2009

RE: Building the Business Case -

Michael

Yes you are correct.  Due to the reports I read and the other news about companies tightening up their belts and reducing expenditures every dollar counts.  I felt it was appropriate to refresh the importance of solid business case development fundamentals.

Thank you for following along with the old ones and I will be picking up soon where I left off.

Cheers
Michael 

» reply