Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.

How to Build a Successful Business Case for an IT Project

William Freedman, Business News Daily Contributing Writer

Maybe you work for an IT company but, just as likely, you work in the IT department of a company that sells some other goods or services. So you, as an IT provider, will always be at a competitive disadvantage to getting your projects green-lit.

Here's why you'll lose out to the line-of-business bosses: They will be able to project how much money the company is going to make based on their project, which is a lot sexier than how much your project is going to save. Here are some ideas to help level that playing field by showing what your IT projects are worth.

What's Your Current State Cost?

You'd be surprised how many companies -- big and mature enough to know better -- have no earthly clue how much they're spending on IT. While most of their information costs might reside in a shared services organization, each division might have its own shadow IT department. Some rogue individuals within these divisions might have sole access to enough computing horsepower to send a rocket to Mars, keep it in the kneeholes of their desks, and expensed it like a box of paper clips.

So right away, let's just admit that this top-line number is unknown and unknowable. Fortunately for you, it's also irrelevant. So how do you determine what is relevant?

What's relevant is what's likely to change. If your goal is to swap out your Unix-on-RISC servers for Linux-on-x86 blades, you have to ask: Where is this going to save the company money or, conversely, cost the company money?

Server depreciation? Check. Server maintenance? Check. Direct labor? Maybe -- depends on your assumptions about whether one system administrator can manage more Linux images than Unix. Application development or database administration? Probably not. Storage? No, if you're comfortable with the disk platform you have and no amount of server swapping is going to effect it.

You need to focus on the right layers and the right domains. Otherwise, you'll drive yourself crazy gathering data you don't need to make your case.

One more thing: You'll be making assumptions going out for, typically, three to five years. Things don't stay the same, costs least of all. You need to take guesses about such cost drivers as:

  • Workload capacity growth
  • Software inflation
  • Hardware price performance
  • Labor inflation
  • Process improvement

These are typically expressed as percentages, as in "Software will cost five percent more each year." Some change might be specific to a certain year: "Capacity will have to grow 40 percent in Year 1 as the current merger is finalized, then 15 percent per year subsequently."

Whenever you make assumptions, it's a good idea not to own them. Throughout the process of crafting a business case, it's always a good idea to check back regularly with the project executive to get buy-in. And, as you get closer to the end and your projections aren't what the boss had hoped for, stand ready to change those assumptions -- at the exec's whim, not your own.

Determining Target State Costs

Your target state is a technological discussion, not a financial one. You can't model anything financially until you've modeled it technically. But once your team has decided on the high-level design, you can make some projections about why it would be cheaper to run the target state than the as-is.

Here are the key metrics that you can leverage to quantify the savings:

Key Metrics

Hardware: Annual depreciation or lease cost per device; annual cost for third-party maintenance (maintenance might be $0 while the box is under warranty, but it balloons after that, and explodes when the box goes off OEM support).

Software: Resource units -- these might be per image, per instance, per user, per CPU, per core or whatever other algorithm the software publisher makes up; if it's an enterprise license, then no matter what you do you won't save a dime on that package.

Labor: The cost to manage a device; take the fully loaded cost of employing the individual fulltime, then divide by the number of devices she is responsible for managing.

Facilities: Rackprint; a rack takes up almost 30 square feet including walkway and environmental space, so figure out how much it costs to lease or depreciate one square foot of raised floor space and multiply by 30. Also, take a look at the devices' specs and discover how many watts they burn, then assume that they do it 8,760 hours/year (that is, all of them). Find out how much the data center is paying per kilowatt-hour, and you almost have your power cost. Then figure -- conservatively -- that for every dollar you're paying for running a machine, you're paying another 50 cents to cool it.

Network: The trickiest and, unless it's specifically a new network implementation you're looking to justify, it might not be worth the bother, unless you can prove that your proposed target state will eliminate a network operations center that has a known annual cost to run.

Services: Anything outside the enterprise's dedicated data center. The contracts and invoices on these are generally very specific and, if the target state is going to increase the load on these, the financial effects are stipulated in those documents.

One caveat: If you're including the capital cost of buying new stuff in your transition costs, you must exclude depreciation and amortization from both your current- and target-state calculations. They're the same thing, and you mustn't double-count.

When modeling a target state, you have to honestly recognize the risk that accompanies the anticipated reward. These risks are hard to quantify, but equally hard to ignore.

Don’t be too concerned about capturing these in your spreadsheet model. Still, you need to include at least some bullet points in your presentation describing the risks of going forward and the risks of doing nothing.

How Much Does It Cost To Get From A To B?

There are two big costs to any project:

  1. Things;
  2. People.

Things come with price tags. Talk to your vendors about indicative pricing that you can use for budget and planning purposes, understanding that these don't represent a bid. (They're final bid prices will be lower -- trust us.) Just put together the shopping list, multiply quantity by price and you're there.

People are harder to price. To even begin this exercise, you need at least a high-level project plan. Don't worry about stop-starts and dependencies and all that other alchemy. Confine yourself to answering these four questions:

  1. What roles does this transition require?
  2. How many people in each role?
  3. How many weeks will we need them for?
  4. How much would we pay them per week?

It's also a good idea to know what proportion of the work will be done in-house and how much you'll need to call in for consulting, architecture, project management and general staff augmentation. That's because the Pros from Dover are going to cost you more than your badged employees. You'll also have to feed them, put them up in hotels, buy their plane tickets and rent their cars – so figure a 15 percent uplift to whatever you end up paying for out-of-town help.

Don't forget to talk to the experts in the Network and Test departments. They're constantly inventing new tasks that need to be added to any project, or so it seems. Suffice to say, you probably haven't thought of everything on your own. Also, understand that there's often more than one way to undertake a project. You might be called on to model various options.

Lastly, be aware that there may be offsets to transition costs, like monetizing the resale value of old equipment. There might also be one-off charges, such as penalties for abrogating a lease agreement. Usually – not always – this is chump change. Even so, it's best to capture it in your business case to demonstrate that you've been diligent and considered these outliers.

Image Credit: Gorodenkoff/Shutterstock