Once we assess the need for new hardware and believe in that need, unfortunately, our job has just begun. The halcyon days of unlimited approval for hardware purchases have passed. Although this new era of financial responsibility is frankly much better for business as a whole, it forces the IT department to engage in something we are not overly good at: making a business case for what is essentially a voluntary expense.

Hold on now. Voluntary expense? Information is the lifeblood of the modern company. Without computers we cannot move that information, sort it into useable data, and make it available to business decision makers.

Although the above is true, we can already do that. People have access to key functions from IT to simplify their work. Furthermore, they have already come to peace with whatever blockades our systems and policies put in place that they cannot get around. In order to justify new expenses, especially on hardware, we have to offer more than just business as usual. We have to prove, beyond a reasonable doubt, that the hardware purpose addresses an understandable business need.

Stating the business need
Many cases for new hardware fail before they get to the point of presenting facts, research, or even options. They fail not because they are badly written, or because the presenter fails to put in long, painful hours working on them. Rather, they fail because the author fails to clearly state what business need this purchase will address.

Take the example of a forty-page hardware purchase request that once crossed my desk. The author spent a month researching options. He outlined ten separate scenarios, defining them in terms of both technical recommendations and user impact. He worked with the vendors, beating them down to almost unheard of pricing levels. In the end, though, his company chose not to go forward. He forwarded it to me after the fiasco to try to work out what went wrong.

After reading it, I could not figure out what business need he wished to address. So I gave him a quick call. After a quick exchange of pleasantries we got down to business. “Why,” I asked, “did you need this new hardware?”

“It’s crazy,” he replied. “These servers are going to come off of lease in six months. If we don’t get them replaced, our monthly hardware bill will triple, and our support contract will double in price.”

“So, your business need is cost avoidance? You never mention that anywhere in this hardware request. Might want to do that.”

He did not respond for a while. “I guess.” He resubmitted the case with the articulated need and received his hardware.

Simply defining the business need
In the above case, we had the simplest and most common business need we encounter in IT. A situation exists, be it increased support costs over time or a lease expiring, that is going to dramatically increase the cost of maintaining the IT infrastructure. The business needs to avoid this cost, potentially by spending some amount of money up front. In this case, we can articulate the business need as “We need to spend X money to avoid spending Y over Z years.” We call this cost avoidance. If X is greater than Y, of course, you may have trouble creating a believable business case.

A more complex business need reads: “We need to spend X to get F functionality in order to no longer spend Y on this set of activities.” We call this cost reduction. In this case, the cost of Y in terms of raw dollars spent, employees, and time needs to be significantly larger than X. You also need to be able to prove that this new function will actually generate the desired outcome. Too many new systems, implemented to reduce time, actually just end up adding more overhead in addition to their own costs.

An even more complex business need reads: “We need to spend X to get F functionality to create the opportunity for Y profit.” In this case, we’re asking the reader to accept, based on our arguments, that Y profits will occur. These cases generally align well with the companies’ strategic growth goals. Unfortunately, they are also very hard to make because IT rarely has direct impact on profit creation. We see this case most often from sales departments and other customer-facing parts of the organization, often coupled with highly flawed technical thinking.

The most difficult case to make can be phrased: “We need to spend X money to bring F functionality to a section of the company.” This may be true, but it is often difficult to accept. For example, when one company acquires another, there are a number of hardware costs that may be incurred. Although people will pay them if the need is overwhelming enough, this is a cost rather than an improvement.

Making the case
Once we can clearly articulate the business need the new hardware purchase addresses, we can move on to actually building the case itself. The case should include at least the following:

  1. A summary briefly explaining the business need, the recommended solution, and the estimated time line for the deployment project. If it is known, include the potential price (in terms of dollars or hours) for the deployment project as well.
  2. A detailed description of the business need. Take the time to outline all of the contributing factors, including any costs avoided, reduced, or potential profits gained.
  3. A detailed description of the proposed hardware solutions. Aim to present at least three: one that is a minimal response coming in under budget but just barely meeting the criteria (or missing several), one that meets as many of the criteria as possible with the budget, and one no more than 10 percent over the projected budget.
  4. An appendix containing any vendor-specific information. Generally this appendix can be omitted in all but the most technically sophisticated companies.

The goal of this case is to prove that the hardware purchase and its associated costs will in some way either save or make the company money. This approach shows the business decision makers that we are not only financially responsible, but also working with them to achieve the company’s overall objectives.