'IT has no inherent value'

Many IT projects are built on a house of cards, ready to come tumbling down in failure to deliver anything useful back to the organization.
Written by Michael Krigsman, Contributor
‘IT has no inherent value’

The rather catchy title for this post comes from an academic research paper stating that IT offers no value apart from the business benefits it supplies.

Because this value is hard to measure, many folks simply fabricate business benefits to get their project through the approval process. These people build IT projects like a house of cards ready to tumble down in the failure to deliver anything useful back to their organization.

The paper, titled Managing the Realization of Business Benefits from IT Investments, describes how this happens:

Management practice provides some insight as to the origins of this inability to deliver business benefits. When considering return-on-investment (ROI) calculations, organizations are too pre-occupied with manipulating the denominator – reducing spend, and are failing to focus on how deploying IT can create business value and deliver significant benefits to the organization.

The authors suggest that many project proposals inflate the business benefits:

Equally worrying is that the traditional investment appraisal process is seen as a ritual that must be overcome before any project can begin, with many benefits being overstated in order to get projects through the appraisal process.

In effect, the paper suggests that neither stakeholders nor sponsors actually care about the downstream benefits a project brings, adding:

No wonder few companies engage in post implementation reviews: it is already known that many of the benefits identified in the investment proposal are unlikely to be achieved.

Such statements prompt ZDNet colleague, Brian Sommer, to question whether many IT projects are rooted in lies.

Brian offers the following comment:

If you have to lie, mislead or stretch the truth to get an IT project green-lighted, it probably had no business getting funded in the first place. When I look at the backlog of IT projects many firms face, I find it hard to believe that IT executives need to fudge figures to move a project forward unless they are doing so to get a specific project to happen before another.


Everyone associated with IT projects wants to achieve success, glory, and high business value. However, the daily pressures of running an IT shop mean many participants are ill-quipped to push up the periscope and take time to determine the business value of their projects. In addition, there's often a skills deficit, making such analysis impossible inside many IT departments.

The authors offer several questions organizations should ask to help integrate business value planning with IT:

  1. Why do we have to improve?
  2. What improvements are necessary or possible? These have to be agreed by the key stakeholders and become investment objectives.
  3. What benefits will be realized by each stakeholder if the organizational objectives are achieved? How can each benefit be measured?
  4. Who owns each of the benefits and will be accountable for its delivery? The benefit owner will be responsible for the value assigned to the benefit in the business case.
  5. What changes are needed to achieve each benefit? This the key to realizing benefits through identifying explicit links between each benefits and required changes.
  6. Who will be responsible for ensuring each change is made successfully?
  7. How and when can the changes be made? This requires an assessment of the organization’s and specific stakeholder group’s ability and capacity to make the changes.

My take. There's no silver bullet that magically transforms poor business practice into innovation, value creation, and success. The answer lies in an organization's ability to cultivate a culture that prioritizes business value over mechanical project execution. And that, my friends, is the secret to rooting out the IT house of cards from your organization.

[House of cards photo from Alex Clark.]

Editorial standards