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 Cramm'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):
- 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.
- 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.
- 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.
- 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").
- 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.
- Managers don't know enough about the systems that support their areas. Follow Intuit's lead and charge units for "helpless" help desk calls.
- 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
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 Cramm 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, Cramm 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?
Cramm'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.
Michael Krigsman is CEO of Asuret, a software and consulting company dedicated to reducing software implementation failures. He also serves as CEO of Cambridge Publications, which specializes in developing tools and processes for software implementations and related business practice automation projects. Michael contributes to the IT Project Failures blog at ZDNet Asia's sister site, ZDNet.