Software

Seven (nasty) truths about IT spending

Michael Krigsman discusses a recent Harvard Business Review article that explores the harsh realities associated with out-of-control IT costs. He says the author suggests a certain Draconian inflexibility that just doesn't make sense.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

An article in the March issue of Harvard Business Review, written by former CIO Susan Cramm, discusses harsh realities associated with out-of-control IT costs. Although cost containment is integral to reducing failed IT projects, the article suggests a certain Draconian inflexibility that just doesn't make sense.

The article includes a sidebar called "The Seven Truths," reflecting Susan's position that, "companies overspend on IT because they are unwilling to say no to frontline managers." Here are the seven truths (reformatted from original):

  1. Enhancements often don't deliver results commensurate with their costs. Establish a fixed budget for IT enhancements for each function or division, in line with the goals they are expected to achieve. Do not extend funds. When they run out, they run out.
  2. Projects are often too big and take too long, partly because unnecessary functionality is built into applications. Require leaders to commit to delivering measurable value for application functions before granting them project approval and before allowing them to maintain funding at each stage. Tie executive compensation to realization of value.
  3. Previously purchased applications and infrastructure technology are often underutilized. Use what you have before investing in new technology. Require IT to counterbalance the added cost of new infrastructure investments with sensible reductions in the cost of maintaining the basics.
  4. Project failure rates are too high. Minimize the duration of project stages. (Limiting scope makes projects less risky and more likely to succeed. That, in turn, increases buy-in for subsequent stages.) Establish "kill switch" rules for projects (for example, "Kill project if initial budget has been modified twice and beta deployment still has not occurred").
  5. Tech teams do not have sufficient incentive to achieve high quality, and quality is often not measured. Make sure development and applications support teams are accountable for the operational costs associated with defects, including emergency change requests and help desk calls.
  6. Managers don't know enough about the systems that support their areas. Follow Intuit's lead and charge units for "helpless" help desk calls.
  7. IT is too risk averse. "No one ever got fired for buying IBM or Microsoft." Require IT to examine the costs and benefits of extending refresh cycles, delaying upgrades, discontinuing maintenance agreements, and using open source platforms and applications.

The project failures analysis

The very existence of this IT Failures blog testifies that many organizations lack sufficient discipline and control around IT spending and execution. However, relying on Draconian guiding principles that ignore realities on the ground is no solution.

For example, in point one Susan recommends blindly killing projects when funds run out. While that sounds nice, some successful projects run over budget for legitimate reasons, often because unexpected opportunities to add value show up as work proceeds. Former CIO and project portfolio management analyst, Lewis Cardin, believes some project course corrections are valuable and he warns us against falling prey to "first number syndrome."

On point four, discussing failure rates, Susan suggests establishing a rule-based kill switch. I agree with this to an extent, but again, her perspective is overly mechanical. For example, should an organization automatically terminate a critical strategic initiative because the IT execution component is flawed?

Susan's HBR article is on the right track, but I'd prefer to see her advice tempered with greater nuance and flexibility. These complex issues have no simple answers, but rigidity is definitely not the right path forward.

[Via David Consulting Group blog.]

Editor's Picks

Free Newsletters, In your Inbox