By Jim Maholic, Business Value Services, Oracle
Whether you are planning to upgrade a departmental solution, move one or two solutions from on premises to the cloud, or embark on a full-scale digital transformation, your executives will likely expect you to explain how the company will benefit from investing in this initiative. This explanation is commonly called a business case.
Admittedly, some new projects can launch without a business case. And a business case alone does not guarantee funding approval. But a bad business case will always compromise credibility. Without credibility, your justification for the proposed project is weakened, possibly even damaged. By “bad,” I mean a case that is poorly organized, poorly written and does not reach the proper conclusions — one that looks as though it was thrown together. So, if you are going to create a business case for a strategic technology project, it is important that you do it well.
A business case is about business. It’s not called a technology case. If it were, you could simply extol the cool, technical virtues of your proposal and funding would be granted. Business is about money — making more than we spend and spending effectively so that we either do more with what we already have or spend much less for the same productive output.
One of the big challenges for project managers is thoroughly identifying all of the benefits of a proposed project and ascribing credible, tangible, financial value to those benefits. And just to be clear, those tangible benefits must be quantified and fall into one of these four categories: increase revenue, cut costs, optimize assets or mitigate real (not imagined) risks. These four criteria are critical to a successful business case. All other benefits are of lesser value. (More about identifying benefits later in this series.)
As a baseline, nearly every project manager can sit down and estimate the cost of a project. For example, a software project will have several common cost components, each of which we can compute. There is the cost of the software (or subscription services), the cost of requisite implementation services, the cost of training the users how to effectively use the software, and the cost of annual support. In the on-premises world, this might have included hardware upgrades necessary to run the new software; however, the cloud doesn’t require you to buy hardware, so it’s a cost that you can easily cross off your list.
Once you have made your estimates, you will have a firm grip on the cost of the project. Let’s say that your proposed project will cost $750,000. It is critical to present an incentive to spend that $750,000. To create that incentive, you must identify tangible, financial benefits that the organization will realize if it successfully implements this project. This is where many business cases fall flat.
Most business cases are quite good at computing the costs and at narrating various benefits, but they often fall short on providing crisp, credible financial benefit numbers that stand up to scrutiny. Your challenge is that you must write your business case in such a way that it is an effective selling tool in your absence. The business case must be able to sell itself, without requiring your presence to narrate every bullet point. Part of that selling effectiveness is derived from having the benefits expressed in financial terms, not just in narrative terms.
Consider this: if, on the benefit side of the ledger, you only come up with good narrative benefits (e.g. employee productivity will be improved, customer satisfaction will be improved, we’re replacing a “burning platform”, etc.) your business case will appear to have little tangible value (or return) against a list of very tangible costs (investments). This makes your ROI uninspiring and your business case will likely fail to gain approval. The challenge is to identify, calculate and communicate benefits — especially the value of benefits — in a way that is credible, measurable, and supportable.
First-time business case developers often operate with several common but flawed assumptions. First, there is the assumption is that your business case approvers (whom we’ll simply call approvers) are fully aware of the situation and fully aware of the problems and the headaches and the disruptions that this problem is creating. First-timers tend to assume that the approvers understand the alternative solutions and why one alternative is better than any others. Rookies also tend to assume that the approvers have a strong sense of urgency to act.
Each of these assumptions might be correct about the people who are on the front line of a problem and who feel its effects every day. But these front-line people may not be the ones who will be approving the funding for your project. You must assume that at least one key approver is not fully apprised of the issues or the potential impact. It is also reasonable to assume that among your approvers, at least one will favor a different use of the limited company funds; this individual will likely seek to minimize the benefits that you ascribe to your project, as they will believe that denying you funding will bolster their chances of having their pet project funded (petty, yes, but sadly real). You have a number of known and unknown obstacles to overcome in your quest to convince the approvers to adopt your recommendation and fund your project. I’ll touch on many of these obstacles in upcoming articles.
Developing and presenting a business case for moving ERP to the cloud should not be intimidating. You simply must approach the development of a business case with discipline and ample planning. This series of articles will give you an overview of the creation of a successful business case.
This post is the first in a series of articles adapted from my award-winning and Amazon Top 10 book, Business Cases that Mean Business. The next article in the series will address the three specific questions that your business case must answer to gain executive approval and funding.