In my previous article, I talked about the true costs of building an in-house IT Monitoring tool. Many organizations, of course, will consider several solutions before making an investment decision. The usual options are:
With this dilemma comes the dreaded ask from the budget holder or business owner: "can you write a business case outlining the various choices we should consider?"
Now, as an engineer myself, I can say that in my professional experience there are few things that can send a project to the backburner as fast as a budget holding manager or business owner asking an IT Ops or engineering person to write a business case.
I've witnessed this conversation countless times: when asked for a business case: the IT Ops/Engineering pro's first question is usually "OK, can you send me a template and I'll write it."
Which usually elicits this response from the requester(s): "Oh, we don't actually have a template! Just prepare the Business Case in whatever format you want."
So do we have a Catch-22? Does no business case mean no solution?
Unfortunately, that's often the case. The business case never gets written, or it is poorly written with no "Decision Grade Information" to encourage the budget holder or business owner to approve it.
But it doesn't have to be this way. Business cases are really not difficult to create. With a little forethought, they can be very short and generated in rapid fire time. Let's explore how.
In this article, I'll share some practical hints and tips to show you how to build a business case. We'll be using a business case for IT monitoring tool as an example to continue the theme of our series of articles, but the tips in this article apply to a wide range of business cases.
So let's examine the core requirements of a business case—here's what it needs to do:
My personal preference is to keep things short and sweet, so I'm going to share with you my favorite technique: BCOOP. That stands for writing a Business Case On One Page!
Why? Because every one of us is time poor— especially executives and managers who have to make financial decisions on a wide range of issues every day of every week.
To do this, we need to address the four primary questions outlined above:
Let's start with the problem statement. What is the problem we are trying to solve? In the case of our example, the issue is the lack of an IT monitoring tool. But it's not enough to just say that. What are the pain points caused by this problem? Here's my example:
The lack of an IT monitoring tool is:
For the next seciton of the BCOOP template, we outline the courses of action available to us:
In the third section of our template, we evaluate the ROI of the available solutions.
This is the final step to the template, wherein we make our recomendations, and demonstrate wit decision grade information why we have made this choice. In this example, we're recommending Option 1: Buy a COTS tool, as it is the most cost-effective choice. Here's how I'd qualify that decision:
Recommendation: Option 1 - Buy a COTS tool.
Rationale:
Concluding comment:
The COTS option will both save us money and earn us money, here's how:
Savings: Today, we'll spend $300k over three years with our engineers doing the work of a tool, but with a COTS tool, we can reduce our costs to $107.5k over those three years, for a total savings of $192,500.
ROI: A COTS tool will free up 1.5 FTE engineers for new chargeable work—up to $132,000 per annum! With a COTS solution in place, we can onboard many more customers without worrying about hiring more engineers.
So what's good about the BCOOP template?
Well, for starters, it contains "decision grade information." Business owners and budget holders are concerned with business outcomes—information like return on investment and time to implementation is crucial to them. With the BCOOP method, this information is presented in quantitative terms as well as qualitative.
The BCOOP template also contains all the essential information that decision makers need on one page, so it's quick and easy to read.
For certain organizations, especially Government/Public Sector or large corporations, you may have to conduct a formal RFP process before you can select a solution. That again is another business process that often causes IT Ops/Engineers a lot of pain. In the third and final installment of this series, I will again outline some useful hints and tips to make your RFP process as simple and efficient as possible.
John has worked in the technology industry for almost 30 years. During that time he has seen at first hand technology movements from mainframe to client/server to the Web and more recently to the Cloud. He has been a software engineer, a QA engineer, a Project Manager, an Agile consultant, an IT Services Manager and to his own great surprise currently works in a Sales role. His current passion is helping IT people communicate better with their finance counterparts and business budget holders to get their project tooling and infrastructure needs funded.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites