The recent 2016 State of IT Report from Spiceworks reveals that IT budgets either are not increasing or are barely increasing from what they were in 2015. This has IT execs worried about how they will do more with less, not to mention helping the business drive top-line growth.
2016 is going to be a very important year for ensuring that you have a proper business case built for initiatives critical to achieving IT and business strategic objectives. Most IT executives struggle with this skill. Yet, when it comes to showing management the real benefits of a technology and why it’s a smart investment, IT executives need this skill to build a solid business case.
I define a business case as an analysis describing the business reasons why management decision makers should or shouldn’t select specific investment options. I’ve heard terms like “cost-benefit analysis,” “ROI study,” and others used to describe business cases as well. I want to address business cases in this post, but as a key part of any business case, I’ll touch on ROI. What is your definition of ROI? The abbreviation has so many definitions that if you ask twenty people what it means, you’ll get twenty different answers.
One of the staggering statistics that floats around the industry is that although $5 trillion dollars have been poured into IT investments worldwide, 83% of IT projects miss cost and delivery goals, and 31% are canceled. These types of shortfalls can shift firms’ destiny and reshape their character. A real-world example? Kmart vs. Walmart. A real lack of IT vision and commitment sealed Kmart’s fate in industry leadership, giving Walmart the leadership it still holds today. I’ve seen many business cases with ROI figures that were awesome but turned out to just be a ruse. Some of these plans were full of faulty logic and just plain bad conclusions. Now, this is a double-sided issue. Due to faulty logic, bad conclusions, and wrong calculations, some great projects get rejected. Why? The leading culprit is the business case. Rather than accurately explaining the true business value potential of a project, these IT business cases unintentionally sink projects’ success.
My goal here is to share with you some of the things 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 yet most misunderstood and underutilized resources when it comes to IT project management. I’m sure readers will agree 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. As I pointed out earlier, the number of IT projects that miss cost and delivery goals, along with the percentage of projects canceled, have certainly put a very poor taste in the mouths of executives and generated an environment of mistrust among them. As such, even if a good business case helps to overcome some of the challenges in environments, like those mentioned above, another problem inevitably shows up. How can a person build a business case 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 follow seven steps in developing business cases, and I’m going to share them with you. There are many subdiscussions we can have for each step, but I’ll save those for later posts.
Number one, Scope: Avoid back-end confusion by being clear in your definition of the business case contents and project plan. In this step, identify what resources are needed. This will help you 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.
Number two, Criteria: Determine who your audience is and the factors it will consider (criteria) in making the investment decision. Completing this step will help you avoid missing any key decision criteria. If anything important is missed, it will undermine the validity of your business case, as well as your own validity.
Number three, Align: A simple definition is “keep all your activities and resources heading in the same direction.” Take your decision criteria, confirm them, and then link them to key business goals. One key thing I want to say here is that our best business value occurs when 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 strong cause-and-effect relationships 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’s mind when faced with making decisions on IT investments. We need to ask ourselves this question: “How strong is the cause-and-effect relationship between investing in IT Project A and realizing key business objectives?” Our job as the business case team is to discover and communicate the strongest and truest value alignment possible. Now, there is a deeper conversation here around testing to make sure we have alignment, but I will hold off for another post.
Number four, Calculate: I was told by my mentor that when it’s about money, get it right. I can’t stress this enough, folks. The purpose of 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, “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, such errors will discredit you and reveal carelessness.
Number five, Prove It: All the best work in the world around calculations, scope, criteria, etc. are worthless if no one believes it. I define proof simply as evidence sufficient to convince someone that something is true or believable. Evidence is particularly important in business case development because every executive I’ve gone 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 over the years that it is 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 your explanations logical and rational. I have seen some cases that used reasoning that was ambiguous, illogical, or completely untrue. I have also seen cases in which folks used weak proof: proof that couldn’t stand up to a slight breeze, let alone some good solid management pushback.
Number six, Analyze: This is the step for sitting back and determining what type of information has been created from all that data you have gathered, as well as what recommendation should be made and why. In step six, you have to align values to key management drivers of business success. Recommendations need to be logical, believable, and most importantly, clear. Don’t forget to base your recommendations on both tangible and intangible factors. This step is where the computation of ROI is done. Do your 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).
Finally, number seven, Explain It: I can’t stress enough that the business case “story” you tell has to be easily understood. You need to speak your audience’s language. If you do, you raise the likelihood of acceptance of your business case recommendations, and you can vastly improve your 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 encourage you to prepare well and use the whiteboard to share content if possible.
I want to leave you with this tidbit of information I was told 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 stem from the quality of the guided conversation it stimulates about the shape of the future. I can tell you from firsthand experience in front of the toughest crowds (executively speaking, that is) that conversations move people to action. All the data that you have gathered is merely the backdrop, albeit still very important.