 |
Home: Read
Darwin: December
2000
BY LEW
MCCREARY
Despite
repeatedly being given up for dead, the IS group will now take
its medicine, shed those extra pounds, and enjoy a new and
better life.
Had you not
by now become fatally jaded by years of
corporate politics, by the twists and turns of your own
careers, the daily injuries and too-small
triumphs of carefully nurtured ambitions—in short, if
you still had a soul and a leftover ounce of compassion—you
just might pity your company's CIO.
For in the course
of little more than 15 years, the CIO has gone from beanied
geek to mysterious backroom mechanic to disrespected executive
wanna-be to habitual scapegoat to brave fixer of tangled
technology messes to visionary-without-portfolio to momentary
hero and back again to habitual scapegoat—sometimes in no
particular order. Most recently, CIOs are seen as the chief
architects and administrators of bloated, entrenched,
underperforming bureaucracies that just about everyone wants
to gut and replace with some form of outside service
provider—many of whom are now lined up, bearing résumés,
promises and references, salivating to talk to any senior
nontechnology executive with the authority to sign a
big-honking contract (BHC).
There are lots of
reasons—good and bad—why this is so. But the end point is the
same: Every incumbent CIO now needs to summon up the courage
to completely rethink the organizational principles that, to
date, have governed the delivery of information technology
services to the enterprise. And every nontechnology business
leader needs to take constructive and compassionate steps to
make sure this rethink happens very soon—if it hasn't happened
already. Because history has conspired to render more or less
obsolete the usual approaches to building a healthy,
functional capability.
So, Just
Die, Already!?!
The story of the CIO's bumpy
ride has been written many times. The death of the CIO
position has been both predicted and devoutly wished for by
many constituents, including analysts, consultants, the press,
other executives—even some notable CIOs. The most benign of
the predictions views the CIO role as a transitional one,
necessary only until technology becomes so pervasive and
straightforward that it requires neither expert interpretation
nor dedicated management. However, in the interim between
grotesque complexity and dial-tone simplicity, CIOs need to
light the way for the bewildered majority of the executive
ranks.
Conversely, the most malignant ill-wishers have
habitually derided the IS function as slow, inflexible,
unresponsive, ill-versed in business realities and so bound by
arcane processes that its output inevitably misses the
mark—costs too much, takes too long to achieve and meets too
few (or, worse, the wrong) business requirements.
As
with any broad caricature, some of these views are true
enough—lots of CIOs probably deserved the low esteem in which
they came to be held. But many more have simply done exactly
what was asked of them: They built an infrastructure,
assembled a knowledgeable staff to run it and populated it
with business data and applications. They tried as best they
could to manage users' expectations and to choose wisely from
an overabundance of allegedly worthy technology projects
proposed by their most important customers: the CEO and the
various other functional chiefs (at least one of whom was
likely to be their boss and, thus, able to exert extra
leverage in getting his needs met first).
But the
information technology function has reached a watershed where
it is appropriate to question whether the goal of building a
full-service in-house technology capability any longer has
much value for most business organizations. Technology mutates
so rapidly that it is unrealistic to think that any single
enterprise—short of the small percentage of gargantuan
ones—can afford to stay ahead of the change curve. And even
the gargantuans must wonder whether there aren't more
productive ways to devote their capital than by painstakingly
inventing capabilities internally that could be leased,
rented, borrowed or bartered from expert outside providers.
The old reluctance to trust outsiders with important
business processes still exists, but it has been sanded away
by years of experience with outsourcing arrangements that, on
the whole, have not been nearly as problem-plagued as the
hand-wringers once predicted. Despite some much-publicized
bloodshed and litigation between outsourcers and unhappy
clients, a relationship-management competency has been
nurtured in many businesses. Both sides of these deals have
gotten better at doing them profitably and economically, with
reasonable contractual safeguards in place.
It's So Hard To Find Good Help
There's a reason why outsourcing flourishes.
Sometimes it is simply the only option when the choice is
either getting something of potential strategic value done
with technology or putting it off indefinitely. When it comes
to talent, kids, it's a jungle out there. Any business that
stubbornly insists on hiring scarce technology talent will
find itself in a life-or-death slamdown with technology
vendors that simply cannot afford to lose. The vendors will
pay higher salaries, and offer better benefits and perks,
cooler challenges and wider exposure to hot emerging
technologies. And they'll put the princely technologist at the
center of a business whose only product is technology. That
lure is hard to resist, and technology companies have an
unfair advantage in the hiring wars.
What the
nontechnology company has to offer is...what? The hair-shirted
joys of toiling for little recognition in the bowels of a
function whose very existence is the butt of endless ridicule
and historical animosity? A place where everyone else is the
star of the show? Where the IS geeks get smaller cubes, older
equipment and the right to dress badly every day—not just on
Fridays?
So, let's review: a double root canal? Or a
day in the sun at the water park?
Add to the built-in
hiring disadvantage the sorry statistic that the demand for
technology workers continues to grow at a rate exponentially
higher than the supply. Despite the brief flicker of cachet
that the dotcom insurgency has given to "geek chic," a lot of
the world's best and brightest remain unattracted to the
apparently dour computer sciences. The academic world has
largely succeeded in narcotizing potential interest in the
study of technology—never mind the obvious truth that
technology is the humble lead out of which business gold is
now being alchemized.
Finally, many businesses spent
the past several years distracted by the looming menace of the
Y2K bug. Wisely or not, they assembled squads of IT fixers who
possessed all of the right skills for patching date-challenged
legacy Cobol code but few of the right skills for, say,
building an e-commerce platform around such emerging standards
as extensible markup language. Now these retrograde businesses
face the prospect of broadly reskilling their staffs at a time
when their executive peers are beating down the doors
demanding, oh, a supply chain portal (or two) and perhaps a
Web-based customer relationship management application replete
with sophisticated personalization technology—and legions of
other technology enhancements.
Are All
Executives Spoiled Brats?
Here's what a CIO
might say: "You people want it all, don't you!"
Admit
it. You've gradually bought into the magic-box view of
technology: the greedy, covetous
I've-got-an-itch-and-I'm-gonna-scratch-it view that all it
takes is simply wanting it. Well, just because you can think
something up doesn't mean IS—or anyone else—can actually build
it. (These phantasmagorical assignments are called
"water-cooler projects," named for the place where most are
handed out. Many CIOs apply the time-tested "multiple ask"
metric for deciding how seriously to take them. Says one,
"Unless someone asks me three times, I just ignore it.")
Not only do you want it all, you also want it now. And
anything that has genuine breakthrough competitive potential
should get to take the express train to fruition. But what you
want inevitably goes into the queue that holds everyone else's
dreams and wishes—some of them just as promising as yours. It
is an enterprise-level challenge, then, to sort through all of
these project requests and bring the most exciting ones to the
top. But it has to be said that part of the problem is that IS
has never learned how to say no, even when no was exactly the
right thing to say. Consequently, once they've said yes too
many times (probably because they wanted to seem more
responsive than their reputation would suggest), they get
badly overextended. The six-month development backlog
lengthens to eight, then 12, then 18 months. And the natives
get restless. The cycle of disrepute becomes that much more
entrenched.
You know for a fact what happens when you
don't say no.... You end up delivering something that takes
too long, doesn't really work and costs too much because you
have to do it at least twice more just to get it the way it
should have been in the first place. So, eventually, you learn
to say no. But nobody goes around saying how irrelevant and
unresponsive, say, marketing is the way they do about the IS
group. The executive vice president of marketing probably gets
credit for setting clear limits and managing priorities
adroitly. But IS, mired in its tarnished reputation, can
easily fall prey to the notion that no is simply not an
option.
In truth, in the relatively brief history of
enterprise information technology, CIOs have learned that the
penalty for saying no is that the users often go ahead and do
the project anyway, either bringing in an outside consultant
or hiring an IT specialist of their own (and calling that
person a "project manager" or something equally unrevealing).
Eager executives can usually find a vendor or consultant who
will extravagantly promise to bake whatever pie in the sky the
executive has dreamed up. Then, once the ink is dry on the
BHC, the disheartening caveats and compromises emerge like
layers of an onion (bringing many tears). The legacy of this
trend is a trail of shattered dreams: systems that don't
really work, that ultimately don't fit into the official IT
architecture, and that can't be maintained, updated or
integrated with other systems. The only revenge IS departments
can exact is to pretend they don't even know these unofficial
systems exist, doing nothing to make them more than minimally
useful in the overall enterprise scheme.
I'm Mutating As Fast As I Can...
The
evolution of technology itself and the evolution of the CIO
role—and, more broadly, the enterprise IT function—have not
always been amicably intertwined. CIOs have struggled to ride
dozens of simultaneously cresting waves. Technology has been
veering away from the CIO's span of tight control for nearly
20 years, since the birth of the personal computer and the
ability to link PCs in local and wide area networks. The broad
distribution of computing power and information resources has
meant that the IT function needed to mutate from exercising
sole authority over, and ownership of, every scrap of data to
performing the service of both enabling wider, easier
information access and inventing more and more business
applications inspired by that access. Succeeding at the first
mission inevitably meant triggering cascading demand for the
second mission. This exposed technology people to an
increasing burden of having to interact with and understand
the needs of nontechnologists across the business—not
necessarily the easiest task for a group thought to have
lower-than-average social needs and communication skills.
Simultaneously, nontechnology executives have gained
greater familiarity and comfort with technology. The
deceptively intuitive Internet has accelerated the growth of a
view that technology is actually pretty darn easy. Naturally,
this galls the people who painstakingly cobbled together the
complex infrastructure that sustains enterprise websites, data
flows and application functionality. A website that remains
disconnected from these underlying systems and resources will
never be a very useful enterprise asset, either for customers,
suppliers or employees. And achieving the necessary
| CIO Leadership Scorecard |
How
to tell whether your CIO is inventing the technology
future, not clinging to the technology past
 Read
More
 | integration
is an exceptionally difficult process—and, as noted in our
related story (see "CIO Leadership Scorecard," right),
probably not one that ought to be outsourced.
What's
really required to assure technology success? One of this
magazine's founding precepts is that technology is too
important to the destiny of your business to be abandoned
unilaterally at the feet of a single functional leader.
Governance of the IT process in every organization needs to be
shared by CIOs and other senior executive leaders alike. Among
the unintended consequences of the rise of the CIO role was
that it created a convenient vessel for blame and an excuse
for others to step back or remain aloof from technology
decision making. This has been harmful to the health of the
overall technology activity. While CIOs need to be ultimately
responsible (and CEOs always want someone they can fire), the
other executive leaders must step up to their own
accountability as well.
A good start might be to begin
a frank but tactful conversation about the redesign of the IS
group. Chances are, if your CIO is one who scores well on the
"Leadership Scorecard," he or she will welcome that
conversation and brief you on the extent of progress to date.
But remember that converting an entire culture from one that
is used to technology services being delivered internally to
one that depends on outsourcing is arduous for everyone—not
just the technologists. It will take time and considerable
patience. 
You couldn't pay Editor in Chief Lew McCreary
enough to be your CIO. But don't let that stop you. Make him
an offer at mccreary@darwinmag.com.
http://www.darwinmag.com/read/120100/leap.html
|
