IT projects have earned a reputation over the past 30 years of being expensive, time-consuming and prone to fail. Countless research studies have documented that this conventional wisdom is correct.
Revolutionizing IT: The Art of Using Information Technology Effectively
By David Andrews and Kenneth Johnson
John Wiley & Sons Inc., September 2002
272 pages, $29.95
It is always good to begin with the basics: "IT projects have earned a reputation over the past 30 years of being expensive, time-consuming and prone to fail. Countless research studies have documented that this conventional wisdom is correct. Half or more IT projects do fail."
You can quibble with the definition of failure. Indeed, the authors—long-time, large-company IT veterans turned consultants—concede that those studies define failure in part by missed schedules and the delivery of less benefit than expected, as well as the abandonment of projects before they're successfully implemented. But no one will argue with IT's reputation for not coming in on time or on budget: It almost never happens. No lesser light than Larry Bossidy, former chairman and CEO of Honeywell International, said that IT has a terrible track record when it comes to execution (CIO Insight, June 2002).
In painstaking detail, the authors set out to determine why this is the case. And they come up with a list of the usual suspects:
• The mandate given to IT project teams is vague and often contradictory.
• People with the necessary skills and knowledge are unavailable.
• The nature of the problems being worked on changes before a solution can be put into place.
• Senior management input is hard to come by until it is too late.
But instead of addressing each evil and suggesting wholesale organizational changes that are unlikely to be adopted, the authors attack the problem from the point of view of what's actually within IT's control. They begin their logical approach by noting: "IT projects create value through business process improvements." So you need to ask at the very beginning: "Exactly how will this project change the ways the organization functions, what benefits will the change bring, and are other options available to achieve the same benefit?"
The point of this exercise is to answer a simple question about every potential project: Is it necessary? If it isn't, the CIO's time should be spent arguing against ever beginning it. If the project is necessary, then IT needs to control the project by ensuring that the time available to do the project determines its scope, instead of allowing the scope to determine the time frame. Similarly, instead of announcing a sweeping mandate—"Let's create the paperless office," for example—it is incumbent on CIOs to battle for breaking complex problems into incremental improvements that can be accomplished with as little pain as possible: "Let's see if we can get accounting to close its books faster."
This is not a project management book; such books deal with tactics. This is a strategy book—what you should think about before implementing a project. And one of the overarching things you should think about is that organizations are unlikely to change to fit IT's needs. Instead of lamenting that fact, embrace it.
An old golf joke: A hacker keeps mishitting everything, so he goes to the local golf pro pleading for help. "I hit every shot to the left," he tells the pro. "How can I fix the problem?"
The pro smiles and says: "Aim right."
There is a lot to be said for that kind of approach to IT.
Reviewed by Paul B. Brown, the author of 13 business books, including the international bestseller Customers for Life. Doubleday has just published an updated version of the book, which was written with Carl Sewell.
This article was originally published on 10-02-2002