I’ve talked through how you make logical arguments for undertaking technologies or transformation projects. One aspect I haven’t talked about is making a business case for a technology project. I’ve spoken on the topic at conferences, but I’ve never actually written my thoughts down in the form of a blog post. What better excuse than continuing my vDM30in30 to capture my thoughts on creating a business case for a technology project.
It’s not about the technology
One of the things you have to get straight about any proposed technology project is that it’s not about the technology. When you are putting together a business case, the executive team doesn’t weight the same things you care about from an operations perspective. Let’s take one of my favorite areas – networking.
A common scenario is wanting to upgrade the network core. The hardware is still under warranty and packets still move. However, the current solution may not have the technical capability of modern data center networks.
It’s intuitive for network engineers to know that investment is needed in the infrastructure. The executives controlling the purse strings don’t have the background to understand. Simply saying an investment is needed because the equipment is old isn’t a strong enough of an argument.
Competition for investments
Engineers must remember that they are competing with other parts of the business for investment. In a mature project management organization, several proposed projects may go before a project committee. There’s normally a pool of money for projects. The project committee will compare the business cases of several projects to determine what projects receive funding. Take a manufacturing company for example. Your data center network upgrade may compete against new forklifts. If the only criterion is age then how does the project committee compare old forklifts against old data center switches?
It’s critical that you understand how projects get funded in your environment. You may or may not have a formal business case proposal process. It’s important to understand the factors that are critical to those approving projects. You have to give someone who doesn’t know the difference between a Fiber SFP versus copper SFP basic criteria to judge your request against the request from an area they fully understand such as air conditioning in the Alabama plant.
Business case criteria
From a high-level there are three basic criteria in each business case –
– Risk Reduction
The easy question is about money. How much money will the project make or save the organization? The answer may not be that easy. Different organizations measure financial impact differently. There are considerations around capital expenses vs. operational expenses. Some companies measures net present value as consideration, and others may not use ROI as a measurement at all. The important thing is to understand how the money question is measured in your organization and work with someone within your organization knowledgeable about creating the financial argument for your project.
Not all projects are approved strictly on the finances of the project. Some projects are funded based on risk or regulatory requirements. For our network example, the mix of mission critical apps may have shifted. The current network design is outdated based on the business impact of various applications. An updated new business impact analysis (BIA) may exist and, as a result, the network design may now expose the business to higher risk. If a BIA doesn’t exist, getting help creating a BIA may be all you need to get your project funded.
Regulatory drivers are just the cost of doing business in certain industries. A new law may now require inspection of all network traffic. Your current design doesn’t allow for meeting the regulatory requirements. I’ve seen many IT managers us an external audit as a driver to force investment. Once an auditor highlights a finding, you’ll be surprised how loose the purse strings become.
There are other factors as well. A new practice is to separate security into an independent category of risk. In the end, it’s just important to know what’s important and aligning the business case for your technology project to that criteria. Which brings me to my last point, there’s a reason organizational goals are pushed down from senior leadership into your annual goals. It’s safe to say that any project you propose should be filling in a check box in your organization’s shared annual goals.
I hope this helps understanding how projects get evaluated and approved.