PERSONAL COMPUTING PIONEER Alan Kay once said, "The best way to predict the future is to invent it." But CIOs face a distinctly different challenge: They scan the inventions of the day and decide which have the potential to shape their businesses' future and which will never meet the inventors' expectations.
Looking back at the computer industry over the past 30 years, it's easy to see which technologies have fundamentally changed the way we do business, such as the personal computer and the Web. It's also easy to see which technologies never lived up to their promise, such as computer-aided software engineering (CASE) and artificial intelligence (AI). Yet it is still difficult for CIOs to forecast which core technologies -- or even which vendors and products -- will fall into the former category and which will fall into the latter.
Why? One reason may simply be vendor hype, combined with a technology press that blows hot, then cold, over the latest buzzwords and gizmos. Today's headlines rave about PDAs and outsourced applications; yesterday's raved about network computers and massive ERP installations. Who knows what technologies will be blessed and cursed tomorrow? Another reason may be that CIOs themselves can get too easily seduced by new technology that doesn't live up to its promise in the time frame they expect; conversely, they may not be able to foresee a technology's impact further down the road. "We CIOs overestimate progress in the short term and underestimate progress in the long term," says Jerry Gregoire, former CIO of Dell Computer Corp. in Round Rock, Texas.
Gregoire includees himself in this description. Though he's hesitant to admit it, when the first color PC monitors came out, his first thought was, "What in the world do we need color for?" Then there's the time about 10 years ago, while he was CIO at Pepsi, that he backed an aggressive plan to add voice recognition capability to delivery truck drivers' onboard computers so that the drivers could have safe, hands- free computer access while they were on the road. Voice recognition on PCs was not quite ready for prime time, but Gregoire was sure that it would be soon enough. "When we started the project, I was thinking, 'They're going to get these problems solved and we're going to be ready,'" Gregoire says. He learned the unfortunate lesson of what can happen when the completion of a project hinges on an immature technology: When Pepsi was ready to roll, voice recognition wasn't. "It was such a cool idea," Gregoire says, with a reflective tone in his voice. "We spent a lot of money on it, but we never solved it."
Ten years ago, Gregoire says, he could have never imagined that by 1999, voice recognition on PCs would have made as little progress as it has. And 10 years ago, no CIO would have predicted that the Internet -- then largely the domain of students and scientists -- would one day make big-company CEOs worry about getting "Amazoned" by dot- com competition. Even inventors themselves sometimes have difficulty predicting the most important long-term business and social impact of their inventions. Thomas Edison believed that the phonograph's most important contribution would be to revolutionize business dictation. The technology was, in fact, used for dictation, but as we all know now, it had a revolutionary impact on the music and entertainment industries.
Even though iron-clad predictions may not be possible -- or desirable -- to make, CIOs can draw insights from the past and present to help them face the ever-increasing onslaught of new technologies and new business pressures in the future. This story will take a look at some of those lessons and at some of the technologies CIOs are betting on in the future.
Taming Technology, Then and Now
Thirty years ago, the CIO title didn't exist. But those executives who were responsible for a company's IS operations could not have imagined the increased technological firepower -- and increased flexibility -- available to CIOs today. In some ways, technological advances over the past 30 years have made the CIO's job easier. Take the exponential increases in computing power available at ever-lower prices. Paul M. Lemerise, CIO and COO of Web startup Wineshopper.com in San Francisco, recalls his biggest worry during his days as a vice president of MIS for Stride Rite Corp. some 20 years ago: figuring out how much mainframe capacity he was going to need over the next two years. "Every two years the life cycle of one [IBM] series would come to an end," Lemerise says. "You were trying to stay current with the technology because you wanted to get the biggest bang for the dollar and plan your capacity moves so that you had enough left for what the [business side] wanted to do next."
Woe to the IS leader who made a mistake in capacity planning and had to go before the board and ask for more money. But in the old days, Lemerise says, long-term planning was nearly impossible since there weren't any good system tools -- he couldn't tell how much capacity an application needed until he loaded it. Flash forward 20 years to Wineshopper.com, and Lemerise has none of those worries: Wineshopper.com's hardware engineers have overengineered its Web site and use several different tools to stress- test it. If demand spikes (as is often the case on the Web) and the site needs extra capacityy, all it takes is a phone call to the facility that hosts Wineshopper.com's production site. Twelve hours later -- only four hours of which are needed to obtain the hardware itself -- another two-CPU server is up and running. Wineshopper.com owns the capacity once it's turned on, so it's not exactly capacity-on-demand, Lemerise says. But it is a huge improvement over the way things were early in his career. "It's a whole different world," he says.
Yet that world brings a different set of challenges, chief among them the speed with which vendors roll out new products. "There's so much new technology introduced, sometimes every three months," Lemerise says. "If you're not on top of it, you can make a business decision that can lock you into a technology that's older." Plus, CIOs also now must deal with a much more fragmented vendor landscape. James M. Logan, CIO of Metropolitan Life Insurance Co. in New York City, recalls that decades ago, companies like MetLife would have two strategic technology partners: AT&T Corp. and IBM Corp. "Today, you're dealing with 10, 15 or 20 firms on a strategic basis," Logan says. "It requires an awful lot of time and attention...sitting down and talking to them about what their business is about."
Choosing Relationships and Risks
To keep up the care and feeding of strategic relationships, Logan diffuses the responsibility for those relationships across his IS organization -- people responsible for application development maintain relationships with the application development vendors and stay on top of those new technologies. Lemerise, at his minimally staffed startup, doesn't have that luxury. He relies on advice from colleagues to find the vendors he needs; once he gets recommendations from his colleagues, he invites two vendors in for presentations (there's never enough time to meet with three) and makes his decision within a day. If he let himself, Lemerise says, he could second-guess every technology decision he makes. Instead, he has resigned himself to the fact that he will never have all the information he needs to make the best decision. "I'm going to make the best decision I can with what I have at the time," he says.
There are ways that CIOs can hedge their technology bets and decrease their risks. Pilot projects are one way to determine whether a technology has"" potential; at Maytag Corp., Edward Wojciechowski, corporate vice president of IT, is piloting Linux, while at Applied Industrial Technologies Inc. in Cleveland, Vice President of IS James Hopper's e-commerce developers have been early experimenters with extensible markup language (XML), which lets developers write custom tags to identify objects and is seen as a linchpin technology for e-commerce in the future. But some CIOs may opt to wait a little longer to deploy cutting-edge technology. Back in September, when Gregoire was still CIO at Dell, business was growing so quickly that he felt he couldn't risk any downtime. Dell was a beta site for Windows 2000, but Gregoire didn't rush to deploy the new OS in Dell's most mission-critical applications. "In the end, there's a lot less value in being on the bleeding edge and a lot more value in uptime and reliability," Gregoire says.
One way to decide when and how to deploy a given technology is to take a business strategic approach, according to Geoffrey Moore, chairman and founder of The Chasm Group in San Mateo, Calif., and author of The Gorilla Game: An Investor's Guide to Picking Winners in High Technology (HarperCollins Publishers Inc., 1998). That approach calls for the CIO to distinguish between technologies that will give his or her company a competitive edge, which Moore calls core technologies, and technologies that are not as strategically importaant, which he calls context technologies. Core technologies should be handled in-house with in-house IS talent; context technologies should be outsourced. "IT resources are so scarce, for you to spend an ounce of internal resources on something that doesn't contribute to your core strategy is increasingly, going forward, a flat-out mistake," says Moore.
Moore is quick to point out that a given technology might be core at one company and context at another. Making the distinction between core and context technologies can actually help CIOs decide whether to risk being an early adopter or to hang back and wait. With core technologies, Moore advises CIOs to be early-to-middle adopters, that is, to be willing to take risks on state-of-the-art technology even before a clear winner, or "gorilla," emerges because their companies can get the biggest potential payoff by being ahead of the curve in an area that is key to their competitive advantage. They should be late adopters of context technologies and stick with the gorillas because it doesn't make sense to take big risks with a technology that won't deliver a big competitive advantage.
Adapting to a Changing Role
Moore's advice to CIOs underscores a change in the role of CIO from that of pure technologist to that of business strategist. For some CIOs, adapting to that change and being able to use technology to bring about organizational change will be the biggest challenge they face over the coming years. "That's 50 times harder than just playing with the technology," says John Keast, CIO of PG&E Corp. in San Francisco.
The change from technologist to strategist -- and the increasing pressure to demonstrate IT value that goes hand in hand with that shift -- has implications for the way CIOs deploy technology too. Gone are the days of multiyear application development and implementations, some CIOs say: Such projects take too long to demonstrate their business value. Keith Powell, CIO of Nortel Networks Corp. in Brampton, Ontario, says he learned his lesson about the pitfalls of poky implementations from his experience rolling out an ERP package from Baan. "It took us about 18 months before we really started to get anything that you could translate into business impact," Powell says. "You had everybody champing at the bit to get the benefit of the new system." The project took longer than he expected because of the time spent customizing the product to interface with legacy systems and to meet the needs of existing business processes. Next time, Powell says, he would not undertake this kind of packaged software implementation without a commitment from all the players that they would "do whatever we need to do to fit with it."
For an e-commerce effort, the need for speed is even greater; if a new feature takes too long to deliver, there's a risk that the business needs may have changed or that the underlying technology will be tired by the time it is rolled out. That's why Powell has put Nortel's e-commerce efforts on a schedule of three-month, or "Web year," deliverables. "We talk about Web years and hours and days to implement things, as opposed to talking in months and years," Powell says. "Sometimes you have to take some risks in implementation...as opposed to getting it all nailed down perfectly and then moving forward."