how to evaluate IT business cases

Picture credit: mint imperial

Picture credit: mint imperial

The credit crunch is making it harder to get funds for technology investments so here is my own IT business case evaluation tool to help you make sure that your business case really has strong enough legs to stand up, before you pitch.

As an interim director I have had to review hundreds of business cases, often under serious time pressure and financial constraints, which led me to create a simple business case evaluation tool that has helped me greatly over the years and I think that you will find it useful.

Here are the ten business case criteria that I use to evaluate an IT business case:

  • Reduce costs
  • Maximise revenues
  • Standardise process
  • Enhance productivity
  • Improve workflow and communications
  • Sustain repeatable service levels
  • Improve risk control mechanisms
  • Implement new business strategies
  • Facilitate organic and acquisition-driven growth
  • Gain competitive advantage by exploiting new technology.

By scoring (and/ or getting others to score) a business case out of ten for each criteria, I derive not only a useful overall percentage score – but also [and most importantly] a profile that retains sufficient granularity of purpose, which can be mapped against broader strategic priorities.

This is how I get a better feel for the individual merits of an investment proposal – as well as a measure of its relative importance in the business change portfolio. And, of course, I have found that the business case presentation is enhanced by the inclusion of the profile scorecard.

Please contact me if you would you like a workshop based on these principles:


  • Pingback: Tweets that mention how to evaluate IT business cases | Fighting the Trillion Dollar Bonfire -- Topsy.com

  • http://www.dabcc.com/michaelkeen Michael Keen

    Colin, great piece on how the business case is reviewed. I spend a lot of time helping clients put these together and there are seven steps to my process below. You can read the whole article at DABCC.com (http://www.dabcc.com/article.aspx?id=10233) I’d be very interested in collaborating on an article around business cases and their importance if you’re interested.

    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.

  • Pingback: Synesthesia

  • Phil Baron

    Colin

    What happens when the business case is emergent as the business is improved in a iterative style through a more agile and systems based approach i.e. you develop more knowledge and understanding over time rather than best guess to build a business case that says the right things. I have learnt that the business case should be emergent and flexible to adapt to the change rather than a static (moment in time) piece of work that usually ends up on the scrap heap with no one person held accountable when it fails.

    Just a different perspective as I have been involved with lots of business cases/specifications/requirement documents etc that say a lot but don’t achieve a lot!! Maybe the business case is old hat and should be done away with. I have been involved in using a much more agile/iterative/in the work approach and it works a treat with IT – fantastic results that would not have been predicted in a business case.