Feb 092010

The shift in power from the CIO/CTO to the CFO for technology project justification is a fact of life that all of us in the technology industry are familiar with. We no longer have to sell the techies on the value of new IT projects, we have to sell to the financial part of the organization: the business. It seems a common belief that cost-justifying technology projects is difficult, if not impossible, especially if those projects represent infrastructure upgrades rather than improvements to business processes.

Too often in technology we get caught up in the “gadget culture.” Most of us who have gravitated to IT have done so because deep down we are technophiles. In today’s world, the techies rarely hold the purse strings (at least to the big projects) and to get an organization to buy into a new technology project, we have to persuade those stakeholders that the project is worthwhile.

People don’t just buy cars because they cost less; sometimes they buy them because they are red or because they like the company that makes them. So many other factors go into convincing the unconvinced that a project is “worth doing.” For that reason, I focus less on the term “ROI study” and more on the term “business case.” A good business case will inspire an organization to pursue a goal, and while a financial case may ultimately be necessary to realize that goal, the inspiration to move in a given direction can indeed occur before that case is developed. A good business case helps an organization achieve consensus. As such, a successful business case needs to be written from the audience perspective, not the writer’s. In the case of technology projects, that means the business case dwells less on the virtues of the proposed technology and more on the business value it represents.

A good business case always begins with the discovery of benefits. A benefit is some quantifiable statement of potential economic (i.e., monetary) value. Each different type of cost reduction or revenue increase should be counted as a separate benefit of the solution. Benefits generally fall into one of three major categories. These benefit areas are, in order of importance:

  1. Reduced costs
  2. Increased productivity
  3. Increased revenue

Reduced costs and increased productivity are both types of cost reduction, but they are calculated and evaluated by stakeholders very differently.

Benefits that result in reduced costs are often known as “hard-dollar” savings; they represent benefits that reduce the amount of money that needs to be spent by the organization. Hard-dollar savings are generally the most compelling type of benefits to present in a business case.

Increased productivity is another type of cost-reduction benefit, but not usually as compelling as the hard-dollar cost benefits discussed so far. Productivity increases are often categorized as “soft-dollar” benefits; soft in the sense that they may or may not be realized as actual savings. In most cases, productivity increases don’t translate directly into such cost savings (although sometimes they can).

The third and final category of benefits represents opportunities for increasing revenue for an organization. Unlike cost-reduction benefits, increased revenue benefits are generally considered the least credible of potential benefits. In my experience, cost savings benefits sell a business case, not revenue increases.


Dave Higgins

Dave Higgins is a Senior Consultant with Cutter Consortium's Data Insight & Social BI practice. He has been a strategic management consultant since the late 1980s and an evangelist for high-quality software systems development methods since 1975.


  2 Responses to “Making the Case: Discovering the Business Value in a Potential IT Infrastructure Project”

  1. avatar

    I agree that good business cases are the key to providing the information necessary to make reasoned and rational investment decisions. With one rather major caveat, I also agree that “In the case of technology projects, that means the business case dwells less on the virtues of the proposed technology and more on the business value it represents.”

    The caveat is that I argue there is no such thing as a technology project. Rather, all projects are business projects that may or may not involve technology. Adopting this philosophy goes miles in fostering the focus on business value you propose in your post.

    When I advocate this principle, I am inevitably challenged with the following, “What about IT infrastructure projects?”, (as included in the title of your post). I use the following scenario to respond:

    IT is operating and maintaining hardware components that are about to become manufacturer discontinued. The vendor has notified IT and given them their “drop-dead” date for support. (Let’s set aside the fact that IT should have seen this coming and solved it before this circumstance arose.) Almost every IT organization I know would either fund the required hardware migration with “IT dollars/budget” or attempt to get the business to fund the “IT infrastructure upgrade.” Instead, the following should occur:

    IT, understanding the correlation between the antiquated hardware and the services said technology provides to the business, identifies all affected Service Level Agreements (SLAs). IT then conducts the analysis to enable the following conversation with each of the affected business units/users:
    “Here is your current SLA and associated service cost. If you don’t invest in upgrade X, here is a timeline describing the degradation of your service, or, here is how much your service cost will increase over time to maintain your current SLA.”

    IT would then present the alternative to the inevitable service degradation or increase in service cost:
    “Here is the cost of the new technology (implementation as well as full lifecycle) and the resulting new SLA(s). “

    Now the ball is in the business’ court and they have a business decision in regard to whether or not they should invest in new technology. They simply need to determine the business value of staying on the antiquated technology infrastructure or investing in the upgrade to maintain and in some cases improve their SLA. This is a business decision, ergo business project.

    So why doesn’t this type of conversation take place? Because very few IT organizations have the capability to put these technology discussions into business terms. They lack the systematic processes in place to collect, integrate, analyze and disseminate the data required to make these business decisions. And though you provide a good list of potential benefits, the upgrade may not reduce costs, increase productivity or increase revenue. What it will likely do is prevent or reduce future costs (either the increased resource costs or the costs associated with service degradation).

    The above scenario requires a sound IT Governance framework and the associated IT business processes most enterprises lack. This inadequacy makes it very unlikely the IT organization can describe technology investments in business terms that include an accurate determination of business value.

    Steve Romero, IT Governance Evangelist

  2. Well-written article but there is nothing really new here. All IT projects must justify their benefits to the organization to obtain funding, regardless of the associated technology (mainframe/web/cloud/whatever). Technology pursuits that are not directly tied to business benefits are a waste of time and money for all involved. IT organizations that lack the capability to put technology discussions into business terms should be replaced since they are a hazard to the health of the organization.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>