To

From

Thank you

Sorry

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."