No Crystal Ball For I.T.

The CEO of an IT consultancy once recounted to me the blow-by-blow of a difficult conversation he’d had with a client CEO, the head of an auto parts company. It was at the midpoint of a traumatic IT project, an experience all too familiar to many of us in the industry. The remarks of the frustrated client CEO proceeded along the following lines (this paraphrasing omits many colorful “colloquialisms”):

“When I build a new parts plant, I’m told how much it’s going to cost, how long it’s going to take and what it will do when it’s done. Sometimes we have problems, but the people in charge come pretty close to doing what they say they will. Even if they don’t, it’s for a good reason that I can see and understand. Why can’t I buy a new computer system that way? Why can’t I get you IT people to work like that?”

It’s a good question. Why can’t IT people—whether they are developing custom software, installing an off-the-shelf package or upgrading infrastructure—work like that?

As IT executives, you must have heard many variations on this theme. Maybe you’ve trumpeted the theme yourself. Shouldn’t IT involve less art and more science? Shouldn’t it be more like real engineering? Why aren’t IT processes repeatable? Why are they so immature? If a car worked the way a computer system does, goes the oft-forwarded Internet joke, you’d have a major accident three times a day and have to fix the car by switching it off and then back on. Absurd.

So will IT “grow up” someday so that implementations involve the orderly, disciplined and predictable sorts of processes that we achieve in engineering and factory settings? Let me go on record here and now: It won’t happen. At least not in the way these comparisons—between building a parts plant and building a computer system—suggest. It’s not as simple as that, and the idea that it is prevents us from making much-needed progress.

IT is different in important ways from many other familiar domains, and it needs to be managed differently. Until we make adjustments to our management processes and explain them satisfactorily to our customers, we’ll continue on a treadmill of high failure rates and frustrated clients.

You Can’t Always Know What You Want

Ask an experienced manufacturing engineer from the above mentioned auto parts company what he wants a new parts plant to do, and he will likely be able to provide hours of detailed description. He’ll have a tangible, physical sense of the specifics. But ask the same engineer what he wants from a new IT system, and you’ll get a different reaction: You’ll get ideas, but they won’t be as specific or as extensive.

This is not the engineer’s fault. It’s a consequence of the essential characteristics of IT systems. Because IT systems and technologies change rapidly, often even as the systems are implemented, it’s harder for the engineer to stay versed in the possibilities that a new IT system represents. But this isn’t the most serious challenge the engineer faces. Even more formidable is the uncertainty that arises from the engineer’s inability to envision the new system or the new business process that might result from its installation. He knows the existing system well and may have general ideas about directions of improvement. But asking him questions about the specifics of a hypothetical, intangible, future system that may be radically different from the current system—well, it would be surprising if this were not a difficult, even deeply troubled, process.

In classic IT terms, important “requirements” are often not discernible in advance. If this statement sounds wrong to you, try on the alternative—that it’s always possible to discern all the important requirements in advance, regardless of the size and complexity of the system and the rate of technological and business change. When Cisco successfully implemented an ERP system in the early ’90s, no one realized it would also need to add a sales support system, until the sales force began to get a tangible sense of what the ERP system didn’t include. The resulting midcourse adjustment, which greatly expanded project scope, was crucial to success. Go ahead and argue, if you like, the largely theoretical point that Cisco could have foreseen this difficulty. The fact is, unanticipated problems (and opportunities) will arise during a project. Any management approach that assumes otherwise is unrealistic.

Indeed, what makes a system great in the end, usually, is not just that it satisfies requirements that were known in advance. The difference between a great, value-adding IT system and a clunky dog that everyone hates is often in the details that are discovered along the way, as the system is implemented and users begin to have a more tangible sense of how it will work.

Most of the machinery of modern management is directed toward making sure that we build the system right. Our processes for defining requirements, assigning resources, estimating completion timing and managing compliance with milestones are all aimed at building the thing right. All these processes presume that we already know what the right thing is.

But, of course, we don’t in IT. In IT, we are almost always figuring out what the right thing is while we are building it. This is a direct consequence of the nature of the final product—changeable and rapidly changing, intangible and difficult to foresee, presenting problems and opportunities that can be discovered only as the product nears actual use. The problem in IT is not just building the system right but also building the right system. And the latter problem is harder than the first. Building an already well-understood product is a matter of complying with a plan. Figuring out what that right thing is—well, that’s a matter of problem-finding, diagnosis, creative problem-solving and experimentation, all in real-time. Cisco knew the project would require midcourse decisions and changes, and that this would involve far more than just following directions.

Because IT products have special characteristics, we won’t get it right the first time. We can’t. Enforcing a “get it right the first time” ethos will primarily cause people to hide the important problems discovered on the front lines. Instead, these problems will be encountered when they become so severe that they cannot remain hidden. This is where the most spectacular project failures come from. Even if you avoid spectacular failure, you may succeed only in implementing the system you initially thought you wanted rather than one that you’ve since discovered would be much better.

So where does this leave us? And more important, what can be done about this?

Managing a New Kind of Work

There’s a company called Despair.com that sells parodies of those inspirational posters that line walls at many companies. You know the posters I mean (a beautiful photograph of, say, a mountain climber, with an inspirational word such as “Achievement”). One of my favorite Despair parodies shows a close-up of a boxer taking a brutal punch, with a message that says, “Agony: Not all pain is gain.”

I refer participants in my executive classes to this poster because I think it conveys a message: When requirements are uncertain, some expenditure of time and money buys you only learning, not progress toward milestones. If you’re not sure about what will ultimately work, you have to learn which combination of features, ideas and resources will succeed simply by doing.

Like the boxer taking a punch, we may find this learning painful. But the pain is not an indictment of the process (unless it happens so late that there is little you can do about it). Pain in an uncertain process is inevitable, and if there’s going to be pain, you want it to happen sooner rather than later. To paraphrase from product design company IDEO: You want to fail early and often to succeed sooner.

If we adopt this philosophy, the changes we need to make in how we manage IT projects fall into two broad categories: financing and project management.

Financing:

You can’t finance an IT project the way you do a parts plant. Buying a plant or a piece of equipment that you understand well is not the right model. A better model comes from venture capitalists (VCs). Wisdom from that industry suggests that you need to budget for uncertain activities (such as IT projects or new business ventures) incrementally. If an entrepreneur wants $10 million, the VC says, “How about $300,000 to get you started, then come back and talk to me when that runs out. Bring something to show me, and we’ll discuss further investment then.” By allocating funds this way, a VC preserves the right to invest further or abandon, and controls risk. If all goes well, the next investment might be $800,000, the one after that $3 million. The eventual total may even add up to more than the initial $10 million, but it will entail much less risk than a single, up-front investment.

Project management:

This part will seem more familiar to IT managers. To match the structure of incremental investment, projects need to be structured iteratively, divided into discrete chunks (preferably prototypes with increasing amounts of functionality) that can be showcased in discussions about additional investment. This doesn’t necessarily mean working systems at every stage. When Cisco implemented its ERP system, using what it called “rapid iterative prototyping,” it created detailed paper accounts of how the system would work early in the project, before the system could be up and running. Because these paper prototypes were very detailed, the company experienced pain sooner rather than later. Cisco took its punches early and learned enough from them to bring the project home successfully.

How to Avoid a Knockout Punch

My recent conversations with CIOs tell me that people are coming around to this approach, even if we lack vocabulary and frameworks to make this way of working seem as rigorous as traditional project approaches. But it is rigorous, or can be, and customers can learn to like working this way. They get a more tangible sense of what will be delivered sooner, and get more input into the project.

That doesn’t mean embracing a new way of working will be easy. There are institutional problems and traditional expectations that get in the way. But the alternative to moving in this direction is to continue perpetuating the fiction that every dollar will provide progress toward the finish line. (It is in the process of doing so in which we will learn where the finish line is.) Managers who won’t allocate a cent to learning, who insist that IT ought to “know what they are doing”—they’ll learn, but in the most expensive way possible. They might even experience a knockout punch.

Rob Austin is a professor at Harvard Business School and chair of the school’s CIO Executive Education program. He’s coauthor of Artful Making: What Managers Need to Know About How Artists Work. You can reach him at raustin@hbs.edu. Please send your comments to Executive Editor Alison Bass at abass@cio.com.