Information resources management discussion

the
Adventures
of anIT Leader

Robert D. Austin
Richard L. Nolan
Shannon ODonnell
Harvard Business Review Press
Boston, Massachusetts
the
Adventures
of anIT Leader
Copyright 2016 Harvard Business School Publishing
All rights reserved
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
No part of this publication may be reproduced, stored in or introduced into a retrieval system, or
transmitted, in any form, or by any means (electronic, mechanical, photo-copying, recording, or
otherwise), without the prior permission of the publisher. Requests for permission should be directed to
[email protected], or mailed to Permissions, Harvard Business School Publishing,
60 Harvard Way, Boston, Massachusetts 02163.
The web addresses referenced in this book were live and correct at the time of the books publication but
may be subject to change.
Library of Congress Cataloging-in-Publication Data
Names: Austin, Robert D. (Robert Daniel), 1962- author. | Nolan, Richard L., author. | ODonnell,
Shannon, author.
Title: The adventures of an IT leader / Robert D. Austin, Richard L. Nolan, Shannon ODonnell.
Description: Boston, Massachusetts : Harvard Business Review Press, [2016] |
Updated with a new preface by the authors. | Includes bibliographical references.
Identifi ers: LCCN 2016000377 (print) | LCCN 2016008595 (ebook) | ISBN 9781633691667 (alk. paper) |
ISBN 9781633691674 ()
Subjects: LCSH: Information technologyManagement. | Strategic planningData processing. |
Management information systems. | Information resources management.
Classifi cation: LCC HD30.2 .A936 2016 (print) | LCC HD30.2 (ebook) | DDC 004.068/4dc23
LC record available at http://lccn.loc.gov/2016000377
The paper used in this publication meets the requirements of the American National Standard for
Permanence of Paper for Publications and Documents in Libraries and Archives Z39.48-1992.
eISBN: 9781633691674
HBR Press Quantity Sales Discounts
Harvard Business Review Press titles are available at signifi cant quantity discounts when purchased
in bulk for client gifts, sales promotions, and premiums. Special editions, including books with corporate logos, customized covers, and letters from the company or CEO printed in the front matter, as
well as excerpts of existing books, can also be created in large quantities for special needs.
For details and discount information for both print and ebook formats,
contact [email protected] , tel. 800-988-0886, or www.hbr.org/bulksales .
A hero ventures forth from the world of common day into a region
of supernatural wonder: fabulous forces are there encountered and a decisive
victory is won: the hero comes back from this mysterious adventure
with the power to bestow boons on his fellow man.
Joseph Campbell, The Hero with a Thousand Faces

CO N T E N T S
Preface ix
Introduction 1
Part One: The Hero Called to Action
1. The New CIO 7
2. CIO Challenges 25
3. CIO Leadership 41
Part Two: The Road of Trials
4. The Cost of IT 57
5. The Value of IT 71
6. Project Management 89
7. The Runaway Project 107
8. IT Priorities 123
9. IT and the Board of Directors 141
Part Three: The Heros Ordeal
10. Crisis 155
11. Damage 171
12. Communication 187
Part Four: The Hero Breaks Through
13. Emerging Technology 207
14. Vendor Partnering 219
15. Managing Talent 235
16. Standardization 253
17. Innovation 263
Part Five: Master of Two Worlds
18. Managing Risk 277
19. Looking Forward 287
Epilogue 297
Notes 307
Ways of Using This Book 311
Glossary of Acronyms and Terms 315
Index 317
Acknowledgments 323
About the Authors 327
Contents
viii
ix
Preface
Since its publication in 2009, The Adventures of an IT Leader has been
widely embraced, both by managers as a business book and by professors and students as a text used in university classes. At last report,
more than 440 universities in more than 35 countries have adopted the
book or some part of it in their IT management curriculum, and it has
been translated into Japanese and Russian. We have been pleased with
reviews of the book from media like the Wall Street Journal and from
reader reviews on Amazon. It has played well in the corporate arena
too: excerpts were published online by www.cio.com, and IT executives
have weighed in to acknowledge its relevance to practice. An ongoing
theme in many of the reviews suggests that the story itself is engaging;
readers report having trouble putting the book down and that they
stay awake long into the night to see what will happen.
So why a new edition? In recent years, especially the last few, we have
received an increasing number of e-mails from people telling us they
like the book, but that certain details, especially specifi c technologies,
have aged badly.
As we all know, technology moves fast, and there is an unfortunate
tendency (especially among students) to notice the obsolete details and
conclude that the management lessons must be equally out-of-date.
This is far from true, of course, as pretty much everyone who has written to us has said: the vast majority of the management lessons in the
book remain as relevant as ever. Nevertheless, reader perceptions matter. So most of these e-mails closed with a request something like this:
Please create a new edition with updated details.
Preface
x
That is exactly what we have done. Not only have we worked our
way through the book to make updates, we have also tried to avoid using technical acronyms du jour and other details that might age badly.
We believe this approach will ensure that the book remains relevant
for many more years. Even more important, such an update is entirely
consistent with a central theme of the book, stated in the opening
chapter: The need for shrewd IT management does not vanish when
overhyped technologies do.
In creating the new edition, we have carefully integrated some new
material, too. Most notably, what used to be chapter 16 on standardization and innovation, has been split into two chapters, one on standardization (the new chapter 16) and another on innovation (the new
chapter 17). Chapter 16 now addresses the challenges raised when people expect personal devices, such as smartphones, to interact with corporate systems. And the new chapter 17 explains how technology can
be used to enhance an organizations innovative capabilities. As new
business models and processes for value creation enabled by information technology continuously emerge, we thought it important to dedicate more of our attention to the subject of innovation.
In a similar vein, although off-premises IT management was very
much a part of the original book, we felt that some unspoken presumptions about outsourcing had shifted in discussions of the cloud; this
caused us to make subtle changes throughout the book, but especially
in chapter 14, on vendor partnering. We emphasize, however, that the
management ideas on this topic in the original book were quite robust,
so these changes are more shifts in tone and language than substance.
Finally, we updated many exhibits and deleted a few.
The result is an updated and improved book that retains the features people liked about the original and continues to, as we like to say,
relentlessly focus on IT as a management subject. The substance of
the story has not changed. Our hero, Jim Barton, still makes classic errors, still learns from his mistakesor occasionally doesntand still
strives to overcome his own limitations by building a strong IT management team. And, as before, he emerges transformed, a humbled but
better IT leader.
Preface
xi
A Note about Our Extended Narrative Approach
As pleased as weve been with the books popular reception, weve been
equally pleased by the interest within the academic community for the
special pedagogical approach we used, which we call the extended
narrative approach.
Its development was something of a journey, and one that had an
unlikely beginning. In 2005, two of us, Richard (Dick) and Robert
(Rob), were co-chairing Harvard Business Schools executive program
for chief information offi cers (CIOs). The topics and content for The
Adventures of an IT Leader originally derived from our design for that
program.
Its probably safe to say that this executive program, Delivering Information Services, held a venerated position in the IT industry. Dick
cofounded the program in 1971 with HBS professors Neil Churchill,
F. Warren McFarlan, and Jim McKenney. As a fi eld, IT management is
arguably barely fi fty years old, but this program had been around for
most of that time. Some companies sent many people to the program
over the years, often right before they promoted those people into the
CIO position. The alumni were a distinguished group, very prominent
throughout the IT fi eld. A number of them went on to become CEOs
of their companies.
Thematically, the course tended to surprise people. Participants arrived expecting to talk about issues that they read about in the IT trade
publications, but we focused instead on the business of IT, the part
that would remain the same even as the acronyms and technologies
changed with lightning speed.
We took the same approach to developing The Adventures of an IT
Leader . As case teachers, we wanted to integrate short stories, to engage
participants with the thematic content. But we had a hard time getting
this to work in the traditional business book format, so we decided on
a different tack. We started to write a long-form story, a book-length
case, about a fi ctitious character and corporationa new CIO learning on the job. It would be fi ctitious in the sense of those Law and
Order TV shows, addressing events that were fi ctionalized, but actually
Preface
xii
ripped from the headlinesthat is, drawn from our fi eld case research on situations that had really happened in the world of IT.
This new path provided us with an initial jolt of renewed vigor.
But then we hit another wall. This time, it was for a different reason:
putting together the story of Jim Barton, our hapless CIO, required
us to apply writing competencies akin to those of novelists as well as
of business professors. We might have reverted to our standard book
approach if our writing team had not been joined at that point by
Shannon ODonnell.
Shannon had come to Harvard Business School by an unusual path.
Previously, she had been a director and dramaturg at the Peoples Light
and Theatre, a highly regarded professional theater company near Philadelphia. In one directing experience, Shannon had made use of the
heros journey also known as the monomyth, an archetypal pattern
within stories fi rst described by Joseph Campbell in his 1949 book, The
Hero with a Thousand Faces . Campbell points out that many of the
worlds most important and impactful narratives share the same basic
plot structure: a reluctant hero is called to action, refuses the call at
fi rst, then goes on a journey, along which he experiences a series of
trials and temptations, then faces a major challenge, only to emerge
transformed in the end.
Shannon helped us use the structure of the monomyth to inspire
plot and character development and propel the action forward. The
project fl owed smoothly to completion. Over a period of a couple of
years, we prototyped and refi ned the material in undergraduate, graduate, and executive program classes. Our publisher, Harvard Business
Review Press, got into the spirit of the project by hiring a great designer, Asaf Hanuka, who created graphic novelinspired illustrations.
When the book was published in 2009, we held our collective breath,
not sure what to expect about how it would be received.
We were happily surprised.
Since the books publication, weve studied and documented the approach to teaching using the book and deployed surveys to examine
how well this extended narrative approach works in terms of both
engagement and learning outcomes.
Preface
xiii
The results of this research were published in the top management
education journal Academy of Management Learning and Education ,
in an article called The Technology Managers Journey: An Extended
Narrative Approach to Educating Technical Leaders.1 In this sense, the
approach has gained not just popularity, but also academic legitimacy.
We also continued to experiment with the extended narrative approach, eventually writing a sequel to The Adventures of an IT Leader ,
called Harder Than I Thought: Adventures of a Twenty-First Century
Leader , in which our hero, Jim Barton, tries his hand at being a CEO.2
We extracted video dramatizations from this book, using professional actors, and created a massively open online course (MOOC)
based on the approach (see www.coursera.org/learn/leadership-21stcentury). At the time of this writing, it was not yet clear how this new
phase in our experimentation would turn out, but early indications are
positive: strong student evaluations, high levels of online participation,
and at least one education award for us, as faculty.
As always, we look forward to learning more from your experiences
as readers, teachers, and learners. Please let us know what you think.
We hope you will enjoy this new version of the book and fi nd it at least
as useful as the old version.
Robert Austin
Richard Nolan
Shannon ODonnell

1
Introduction
The Adventures of an IT Leader invites readers to walk in the shoes of a
new CIO, Jim Barton, as he spends a diffi cult year learning IT leadership at the IVK Corporation, sidestepping the pitfalls that make the
CIO job the most volatile, high-turnover job in business. Although this
book is based on the authors years of fi rsthand experience with diverse companies and managers, the IVK Corporation and its staff are
fi ctional.
As the story begins, the midsize growth company is attempting a
turnaround following a period of slowing business performance. The
stock price has fallen substantially as investors have adjusted their expectations of IVKs growth. An aggressive new CEO, Carl Williams,
takes over and assigns a new management team. In the process, CIO
Bill Davies is fi red and Jim Barton, former head of Loan Operations
and a talented general manager, is appointed CIO. Barton has no background in ITnone at all. The story follows Barton as he fi gures out
what effective IT management is all about and deals with the issues and
challenges of the job. The fi nancial and other information about IVK
in chapter 1 provides a cogent snapshot of the companys situation as
the story begins.
The Main Characters
In order of appearance . . .
Jim Barton: The new CIO of IVK. A talented and ambitious general
manager, Barton knows little about IT. He sets out to learn quickly
Introduction
2
and to lead the IT department toward renewed growth, stability,
and strategic partnership within the companybut not without
facing serious challenges.
Carl Williams: This bold turnaround CEO is high on ambition and
short on patience.
Maggie Landis: A savvy management consultant and Bartons
girlfriend, she often provides Barton with valuable insight,
references, and perspectives.
The kid: Wise beyond his years, this twenty-something tech
nerd, whom Barton mysteriously meets only at Vinnies Bistro,
proves a useful sounding board and source of surprisingly good
advice.
Bill Davies: Former CIO at IVK, Davies was fi red in part because he
struggled with management-level communication. He tells Barton
that he wont last one year in the job of CIO.
Bernie Ruben: As the director of the Technical Services Group and
longtime IVK employee, Ruben is nearing retirement and thus
mostly immune to concerns about risk to his career. He frequently
provides Barton with the candid advice, knowledge, and context he
needs to make key decisions.
Raj Juvvani: As director of Customer Support Systems, Juvvani is part
of Bartons core IT team.
Tyra Gordon: As director of Loan Operations and New Application
Development Systems, Tyra worked closely with Barton when he
was head of Loan Operations and takes the lead on several new IT
projects under his management.
Paul Fenton: As director of Infrastructure and Operations, Fenton
manages a large and important domain, including IT security, and
is part of Bartons core IT team.
Gary Geisler: As director of Planning and Control, Geisler works
closely with Barton on IT financials.
John Cho: IVKs outspoken resident security genius, Cho has a distinct
fashion sense and provocative musical talent.
Jenny: Bartons ever-dependable executive assistant.
Several additional characters populate the story but are described in
context.
Introduction
3

part one
The Hero
Called to
Action

7
chapter one
The New CIO
Friday, March 23, 11:52 AM . . .
Jim Barton sat motionless in a blue leather chair, one of several positioned around an elegant glass table at one end of the CEOs corner
offi ce. At the other end of the room, Carl Williams stood looking out
a window. The silence lengthened. Finally, Williams turned to look at
Barton. Speechless was not a word most people could imagine applying to Jim Barton. His energy and outspokenness as head of the Loan
Operations department had made him one of IVKs most dynamic executives, a key player and a likely CEO somedayof a different company, if not this one.
But the news Williams had delivered moments before had left
Barton dumbfounded.
A few minutes earlier, Barton had rushed to Williamss offi ce, summoned for his turn with the new chief. All morning, the leadership team
members had marched, one at a time, down that hallway, each on a
journey to discover his or her fate. As the executive assistant greeted him
courteously and waved him in, Barton allowed himself some optimism.
Most likely, he thought, he was about to receive a promotion. Hed done
a good job, been a big contributor as the company had grown to its present
size. Something like Chief Operating Offi cer would fi t him nicely.
On the other hand, to hear that he was being asked to leave would not
have enormously surprised him. He hadnt done anything to warrant
The Hero Called to Action
8
such treatment, but unexpected things happen when companies are in
crisis. The logic behind executive appointments, retirements, resignations, and fi rings was rarely transparent. Sometimes, Barton thought,
there was little logic to it at all.
The timing of his meeting gave Barton reason for hope. According
to word going around, fi rings, resignations, and forced retirements had
been handled in the fi rst meetings of the day. Since midmorning, hed
heard mostly about reassignments. Executives called in to the earlymorning meetings had departed as soon as theyd fi nished, but for a
while now, the people emerging from meetings with the CEO had been
going back to their desks. It was late enough in the dayhe might just
be in line for that plum job.
But his mood darkened when Williams, standing by the window, not
looking at Barton, began to speak. The CEOs words struck Barton with
near-physical force.
Jim, I dont think youre going to like this very much.
Bartons mind raced. Why would he wait this late in the day to fi re m e?
What have I m issed or m isunderstood? He pulled himself together well
enough to answer, Just tell me, Carl. Were all grownups here.
Williams chuckled. Its not what you think. Were not asking you to
leave or anything like that. But when you hear what I have to offer, your
fi rst inclination may be to think along those lines yourself. Though I
sincerely hope not.
To Barton, Williamss gestures, standing across the room, staring out
the windowthe entire sceneappeared overly dramatic. Although
the view from the thirty-fourth fl oor was enticing, Williams wasnt
admiring the panorama, he was avoiding eye contact. Barton glanced
around, seeking additional clues to what might be going on. The offi ce,
he noticed, had been completely transformed, all signs of the previous
occupant obliterated. That was too bad. Barton had gotten along well
with Kyle Crawford, the former CEO. There had been rocky moments,
but suddenly, looking back, those didnt seem too awful.
As you know, Williams continued, the board is determined to
get things on track. They want us back on our earlier, steeper growth
trajectory. They believe, and I agree, that the controversy that has
dogged us for the last eight months has been a damaging distraction.
The New CIO
9
When they brought me in from outside, they asked me to take a look at
the company and to formulate a recovery plan.
As you probably suspected, the board asked me to reconstruct the
leadership team, to clear away the rot that might remain from the way
some things were done in the pastto recommend the composition
of a team that could rise to the challenges we are facing in the coming
months. Id like you to be on that team.
R elief . It didnt sound like a demotion. Williams continued.
It has been a diffi cult process. I havent told anyone else this, but
the fi rst time I went to the board with my proposed team, they balked.
They asked for additional changes. I had originally proposed a very different role for you than the one youve ended up in.
A n unusual assignm ent. I can live with that. Spirits lifting, Barton
made a constructive noise: Im willing to do whatever will help, he
offered. You know me, Carl. Im a team player.
Im delighted that you are taking that attitude, said Williams, who
smiled but maintained his place at the window.
You see, after a considerable amount of shuffl ing and reshuffl ing,
and having discussed this with the board extensively, weve . . . Here
Williams drew in a deep breath, Well, weve decided that you should
be our new chief information offi cer.
This was the news that had knocked the air out of Jim Barton, reducing him to this unfamiliar wordless state. After allowing Barton
a moment, Williams fi nally turned from the window. Barton felt his
bosss gaze burn into him. Finally, Barton managed to babble: CIO?
You want me to be the CIO?
Davies has been overwhelmed in that role. Youve been one of his
most outspoken critics.
I know, but . . . Ive got no background in information technology.
By all accounts, you have a lot of ideas on how IT should be run.
Many people think theyre pretty good ideas. I think youve said a few
things along those lines to me, even in my short time here. Unlike
Davies, youll report directly to me.
Not yet able to unpack a tangle of additional objections crammed
together in a ball at the top of his mind, Barton simply repeated himself: But Ive got no background in IT.
The Hero Called to Action
10
And Davies has a lot. That clearly didnt work, so weve decided to
try something else. Williams moved to the table and sat down. The
CEO leaned forward, locking eyes with Barton. Youre a good manager, one of our best. You may not know much about IT, but we think
youll fi gure it out.
Ill fi gure it out?
Yes. He nodded and leaned back in his chair. Its very important,
you know.
I know its important. Ive been saying that myself.
A lot of people have heard you, loud and clear. The members of the
board of directors agree. Were not a small fi rm anymore. Havent been
for a while. Increasingly, were more of a fi nancial services factory. But
we dont come close to running the company that way yet. Thats got to
change. And a huge part of the change will be IT.
Barton could hardly object. Williams was paraphrasing arguments
that Barton had made many times. When hed made these arguments,
though, hed never imagined that it might become his job to act on
them. The sobering thought that he might need to fi gure out how to
implement his own recommendations helped him recover.
Whats going on with Davies? asked Barton.
Gone, said Williams. This morning.
So there would not even be a transition period. Just as well. Barton
had never gotten along with Davies. Davies didnt like Barton, and who
could blame him? Barton had been very critical of IT. He wasnt proud
of it, but hed even occasionally stooped to making fun of Daviess
weird taste in neckties.
Carl, said Barton, I just dont think Im the right choice. Its not
the place I can add the most value. Can I ask you to reconsider?
Williams stood, strode to his desk, ready to move on to his next
meeting. Its done, he said. I know its a shock, but I think this is
a fundamentally sound choice. Think about it. If you can manage a
modicum of objectivity, I think youll see that its a good idea. As unexpected as this may seem, its not a punishment. IT is a problem area.
You are a highly regarded fi xer. Its going to be hard, but if you succeed,
it will be very good for this business.
I just cant see it at the moment, said Barton.
The New CIO
11
Give it time, said Williams, impatience creeping into his voice,
but not too much time. I sincerely hope you wont do anything stupid,
like walking out. Let me know what you decide.
The meeting was over. Williams still had many others to talk to before his day was fi nished.
Barton stood and walked slowly toward the door, but turned back as
he approached it.
Thanks, Carl, he said, automatically.
Williams looked up, trying to determine whether Barton intended
sarcasm, deciding that he did not. You are most welcome, he said.
Then he looked down at a sheaf of papers on his desk to remind himself who was next on the days meeting schedule.
Friday, March 23, 2:41 PM . . .
A small crowd was forming outside Bartons offi ce. All day, eager IVK
employees had been working on a whiteboard in the back of a storage room to create a chart showing the new management team for the
company, as well as they could discern it. It was detective work, following clues to possible scenarios and likely conclusions. All of it would be
announced soon enough, of courseprobably as soon as Monday
but curious souls could not wait that long. Besides, it was fun, in a fatalistic sort of way, this sleuthing for facts that might have implications
for all, their jobs and careers. Certainly, it was more fun than fretting or
doing their desk jobs.
Much was known. Some executives had told people of their new assignments. Others roles had been determined by mysterious, undisclosed means. Still others had been escorted from the building and
were presumed gone for good.
Jim Barton remained the biggest puzzle. He hadnt been let go, but
had said nothing to anyone about what Williams had offered him, and
he was an obvious fi t in none of the remaining slots. When inquisitiveness overwhelmed them, people gravitated to the corridor outside
Bartons offi ce. The bold ones squinted through glass and half-closed
blinds to try to see what he was doing.
The Hero Called to Action
12
Barton was oblivious to their attention, lost in a thick fog, oscillating
between anger and excitement, as unsure as he had ever been about anything. One minute hed decided to resign, the next he was jotting notes for
improvements to IT processes. Hed skipped lunch, a bad idea, he realized
now. At 1:35 pm, hed begun searching the web. His eyes were locked on
his screen. From within his sphere of intense concentration, he could not
have seen people peering in at him even if hed looked right at them.
The fi rst thing he had typed was IT Management. His search had
produced 2,510 m illion web pages on that subject. He clicked on the
fi rst of these; what looked like a table of contents for a magazine appeared. He scanned it. Outsourcing IT. That seemed like a legitimate
management issue. The next few items, reviews of new devices, not so
much. Then came stories about companies that had succeeded with
things that had tech-sounding names. Acronyms littered the pages.
Most of what he saw didnt look like management at all. This was one
of Bartons pet peeves. He used to say it to Davies all the time: IT management has to be about m anagem ent . Talk to me about m anagem ent .
Profi t. Risk. Return. Process. People. Dont tech-jargon me.
Barton stood up, moved to his whiteboard, and erased everything
on it. Then, at the top, in big letters he wrote, IT management is about
management. He underlined the second management and looked
around unsuccessfully for a pen of a different color that he could use to
emphasize the word even more.
IT management is about management
For a while, he just stared at what he had written. Then he rolled his
eyes and slapped the pen back onto the whiteboard tray. That helped
a lot, he said sarcastically.
He moved back to his chair and started surfi ng from link to link, not
pausing to read most pages. In the blur of passing words and graphics,
a sentence caught his eye, prompting him to stop: More than any other group within a company, IT is positioned to understand the business
end-to-end, across departmental boundaries; no other department
interacts with as many different parts of the business as IT. What a
The New CIO
13
bunch of crap , he thought. As hed seen again and again, IT people did not
understand the business. That was one of his big problems with them. But
as he read the sentence again, as he thought about it carefully, he realized
it didnt say, IT understands the business better than any other group.
It said IT is positioned to see better into more corners of the company. IT
people have an advantage in gaining a deep understanding of the business.
Doesnt mean they do a good job in seizing that advantage. The potential,
though, interested Barton. He had never before thought of it that way.
He continued to surf. Pages and more pages fi lled with gibberish. He
stopped on a page with a pair of diagrams. The fi rst claimed to portray
the usual state of affairs in IT management situations. It showed business knowledge (smarts in the diagram) and technical knowledge
having no overlap, but needing to be pushed together:
Business
smarts
Tech
smarts
The text that accompanied this diagram suggested that one of the top
responsibilities of the IT managerone of the most useful things that
he or she could dowould be to take actions that pushed the two
circles closer together. If this effort was successful, the result would be
a changed diagram:
Value
Business
smarts
Tech
smarts
H m m , thought Barton. O verly sim plistic, m ay be, but consistent with
m y understanding of the situation and the problem . He wasnt sure what
actions might push the two circles togetherhed think more about
that. Education, training, came to mind, but there had to be more to
it than just that. This way of thinking about the problem suggested, at
least implicitly, that communication issues were a big deal. That, too,
The Hero Called to Action
14
fi t with Bartons IT-related experiences. If business people and technology people shared more knowledge, more understanding, theyd end
up better able to communicate with each other, which should result in
getting work done more smoothly. The discussion that accompanied
the diagram also suggestedhelpfully, he thoughtthat people able
to operate in that area of overlap where Value was created were a resource to be hired, retained, and cherished. You could count how many
people you had who were like that, whether they were business-savvy
types in the IT department or tech-savvy people from business units.
And you could try to increase their numbers.
Again, Barton surfed. Not far from the circle diagrams, he found a
picture that he liked even more: 1
Expert
IT leaders Executives
The capability gap
Sk ill level
Novice
Technology:
IT strategy and operations
General management:
Business strategy and operations
D is cip line
T he I T lead er/ general m anager cap ability gap
Something about this diagram better captured the anxiety he felt as he
considered accepting the CIO job. He believed he resided at the top of the
Executives hill in the picture, near the peak of understanding the companys general management, business strategy, and operations issues.
Moving across to acquire understanding of IT strategy and operations
would, according to this depiction, involve crossing a dangerous chasm.
If he accepted the position, hed need to come up with a way of building
a bridge between the two hills, or crossing from the top of one hill to the
top of the other. He had no interest in spending a lot of time down in the
valley between them. But that wasnt the only source of his anxiety. The
idea of tiptoeing across a rickety bridge between these two summits held
little appeal. It would be all too easy to fall through a gap and plummet
to his (careers) demise. Even thinking of hanging out there in the middle
of such a bridge called forth in Barton an acrophobic surge of adrenalin.
The New CIO
15
The words to an old Elton John song, Rocket Man, fl oated through his
mind: it would be lonely for Barton out in that space.
The text that accompanied this diagram argued that the valley could
be spanned from either direction. A career technical employee could acquire enough understanding of the business to be an effective IT leader.
Or a career business employee could acquire enough understanding of
technology. It even suggested that it might be a bit easier and more viable for the career business leader to work the problem from that side.
The rationale: technical knowledge, as much as you needed to know as
an IT manager, was relatively explicit and learnable, whereas a lot of
the understanding that made managers effective was tacitmastery of
relationships, understanding of political factors, and so on. This argument also rang true. It was in those softer, tacit areas that Davies had
repeatedly had problems. Half the time, the guy couldnt even dress
himself to be taken seriously in a business group. No one wouldve even
thought of taking him to a meeting with customers, although he had
suggested exactly that on numerous occasions.
Barton returned to searching and typed CIO. This time only
(only!) 88 million entries resulted. He began clicking through them.
IT magazines were the biggest hitters among the fi rst ten entries. After
working his way through a few more pages of entries, glancing quickly
at some, he came across a presentation called The Ups and Downs of
IT Leadership and clicked on it. It looked like a presentation prepared
by a professor from a school Barton had never heard of. Some of the
content was confusing, but the gist of it was clear.
The presentation, based on an analysis of three-plus decades of
history, described the IT leaders job as a roller-coaster ride. The
fortunes and prestige of ITand its leadershad swung wildly during
this time, high then low and back again. And it likely would continue
to do so.
The evidence? Expansion of the commercial internet in the late 1990s
had dramatically elevated the status of IT workers, as established fi rms
tried eagerly, even desperately, to join what looked like a revolution in
process. But the NASDAQ peaked in March 2000, then began a relentless
descent. What had been playing out as revenge of the nerds gave way to
revenge of the cost accountants. Dot-com explosion turned to dot ver-
The Hero Called to Action
16
tigo. 2
IT work went from awesome to uncool. Technologists whom top
managers had invited to participate in business strategy discussions were
sent back to the IT basement. The downtrend bottomed out around 2002
or 2003, when the status of the IT function started back on an upswing.
Things had gotten pretty good again for IT. Then the fi nancial crisis of
2008 hitand IT was back in the basement. Then came another recovery.
By 2015, the exuberant mood in the tech industry was starting to remind
people with enough experience and long memories of the late 1990s.
And so it went, full circle, with ups and downs in between. Y es ,
thought Barton, roller- coaster ride about sum m ed it up .
During up cycles, technologists tended to be seen as keepers of the
magic that enabled important progress. Business leaders turned to IT
leaders for ideas about how to impact the companys top line or re-craft
business models. Some companies elevated IT departments on their
org charts. IT departments landed bigger budgets, and IT employees
served as crucial consultants to their business-area partners.
In a down cycle, though, all this would change. IT projects launched
during good years to chase rising demand became sources of unacceptable cost, servicing demand that had now vanished. Because IT
investment tended to occur in chunks, projects often could not be
easily switched off in mid-execution. Under pressure, projects stumbled; costs ran over budgets; benefi ts undershot expectations. IT project failure was nothing new, but as technology lost its luster, such
failures earned renewed scrutiny. Projects were canceled, declared
total losses, budgets were slashed. Strategies that had seemed so important a few years earlier were suddenly deemed unrealistic. Executives formerly eager to discuss bold IT-enabled futures were no longer
in the mood. The harsh realities that descended on IT managers put
them into basic survival mode and made them more worried about
their next meal, so to speak, than grand visions. The presentation
amusingly labeled this mode for IT leaders: hunt, kill, eat . Cost savings
became the mantra du jour. Subject to tightening budgetary control,
the IT organization became reactive, with few new applications being
developed. The roller coaster that had once carried IT managers high
hurled them earthward.
The New CIO
17
The implication: IT leaders needed to possess a special kind of
ambidexterityto be effective in good times and bad, on the up cycle
and on the down.
The idea that IT could be a potential source of growth for a fi rm
excited Barton. He wasnt quite sure what to do with the idea, but he
wasnt ready to set it aside either, even in the middle of what probably
ought to be considered a down cycle for IVK. He remembered Davies
arguing that superior technical features that could be effectively demonstrated to clients could be a factor in closing deals. Thats why hed
wanted in on meetings with customers. The image of Davies and his
weird neckties sitting down with customers had obscured serious consideration of this argument.
Searching a bit more, thinking about wrapping things up and taking
his decision home for the weekend, Barton stumbled across another
sentiment that he appreciated. It proposed that IT managers try a
thought experiment:
I m agine y our day – to- day work. H ow m uch would be lef t to do in a
day if a m oratorium were declared on discussions about specifi c
technologies? I n how y ou think about I T m anagem ent, how m uch
would there be principles, philosophies, practices that could be
said to be independent of the underly ing technologies?
It was essential, this article said, that IT managers understand
and demonstrate to others that the need for shrewd IT management
does not vanish when over-hyped technologies do. If the fi eld of IT
management was to mature, to deserve a place in the pantheon of
management ideas, it must have substance beyond the specifi c objects
of its attention. The article fi nished with a fl ourish:
T he core of I T m anagem ent the m anagem ent content is not
transitory . J ust as the f undam entals of , say , fi nance or m arketing,
rem ain relatively stable at their core, so are the f undam entals of I T
m anagem ent.
If this was true, Barton thought, then there was hope for him in the
CIO job.
The Hero Called to Action
18
He shut down his computer and stood, reaching for the coat on the
rack behind his chair. Finally, looking toward the door, he noticed the
sizeable group of people gathered outside.
What is it? he asked, as he emerged with coat on and bag slung
over his shoulder. No one said anything. He looked from one to another of their sheepish expressions. Then he singled out someone who
worked for himor who had worked for himin Loan Operations.
Jackie, whats going on?
Jackie gathered her courage: Weve been trying to fi gure out where
you fi t in the new management team. Weve fi gured out pretty much
everyone else, but youre a puzzle. And, she quickly added, of course,
those of us who work for you hope youll continue to be our boss.
Barton laughed. Im afraid youre out of luck.
Perplexed faces told him that no one had the slightest idea what he
meant by that. He looked around, gathered his own nerve, and tried
on a phrase that had never before passed his lips: Im the new CIO.
Several people in the group gasped. Barton did not wait for further
reactions. He headed for the elevator, leaving stunned silence in his wake.
The New CIO
19
REFLECTION
Why would Carl Williams ask a non-technical manager to assume the CIO position? Is it a good idea?
If you were Jim Barton, would you take the job?
What do the IVK Corporation exhibits, featured below, tell you about the current
state of the company? Given this information, what does IVK need from a new
management team under CEO Carl Williams?
IVK Corporation Organization Chart
Human
Resources
Financial
Management
Corporate
Planning
Information
Technology
Board
CEO
Legal
Capital
Markets
Business
Development
Customer
Service
Collections Loan
Operations
The Hero Called to Action
20
IVK Corporation Statistics for the Fiscal Year
2.2+ million customer inquiries
530,000+ applications processed
180,000 loans funded
Market Share of IVK Corporation Versus the Two
Leading Competitors
Competitor A : 36%
Competitor B: 15%
IVK: 16%
Other: 33%
The New CIO
21
Financial StatementsConsolidated Balance Sheet
J une 3 0
Y ear X 1
A s s ets
Cash and other short-term investments $ 152,551,539 $ 17,175,191
Total cash and cash eq uivalents $ 152,551,539 $ 17,175,191
Service receivables:
ef yrosivdA se 389,587,01461,538,43
slaudiseR 564,716,34873,597,701
efgnissecorP se 537,935,2653,253,6
148,982,898 56,943,183
lbaviecer rehtO se 439,834 338,551
empiuqe dna ytreporP tn 744,552,6441,633,51
Less accumulated depreciation and amortiz ation 4 ,227,745 1 ,877,339
P roperty and eq uipment, net 11,108,399 4,378,108
G oodwill (P eople s VK oitisiuqca )n 96,743,3794,922,3 7
essa tnerruc rehto dna diaperP st 472,130,32 436,874
essarehtO st 099,008,1 0
essa latoT st 46,874,28$135,341,143$ 6
continued
The Hero Called to Action
22
Financial Statements (continued)
J une 3 0
Y ear X Y ear X 1
Liabilities and s tock hold ers ‘ eq uity
Liabilities:
A ccounts payable and accrued expenses $ 26,343,374 $ 13,333,047
ilibail xat derrefed teN yt 789,563,41521,341,14
N otes payable and capital lease obligations 9,723,003 283,864
elbayapsetoN 023,473,6358,332,6
itilibail latoT se 12,753,43$ 553,344,38$ 8
Commitments and contingencies
Stockholders eq uity:
P referred stock, par value $ 0.01 per share;
20,000,000
Shares authoriz ed at J une 30, Y ear X ; no shares
authoriz ed
A t J une 30, Y ear X 1 ; no shares issued or outstanding
1X raeY ,03 enuJ ro X raeY ,03 enuJ tA 0 0
Common stock, par value $ 0.01 per share;
100,000,000
Shares authoriz ed; 63,543,662 and 56,731,054
shares issued and outstanding at J une 30,
ylevitcepser ,1X raeY dna X raeY 087,936 459,135
tipac ni-diap lanoitiddA la 353,962,31991,275,381
ninraedeniateR sg 121,023,43791,884,37
iuqesredlohkcotslatoT yt 824,121,84671,007,752
Total liabilities and stockholders eq uity 341,143,531 82,478,646
The New CIO
23
Financial StatementsConsolidated Income
Statement
Y ears end ed J une 3 0
Y ear X Y ear X 1 Y ear X 2
Service revenue:
ef yrosivdA se 22,167,41$896,643,96$ 767,491,98$ 6
slaudiseR 399,438,11501,720,16318,498,47
A dministrative and other fees 4,113,746 2,814,617 474,888
P rocessing fees 65,456,570 39,566,486 14,191,953
Total service revenue $ 233,659,896 $ 172,754,906 $ 41,263,060
Operating expenses:
Compensation and benefits 54,879,252 26,805,902 11,488,553
G eneral and administrative 65,695,724 31,062,928 10,651,614
expenses
Total operating expenses 120,574,976 57,868,830 22,140,167
Income from operations 113,084,920 114,886,076 19,122,893
Other expense:
nepxe tseretnI es 394,428,1503,365,1293,717
ocni tseretnI em 022,19389,611498,418
ocni rehtO em 214,2 744,031002,2
Total other expense, net 9 9,914 1,444,122 1,602,826
Income before income tax
nepxe es 760,025,71459,144,311438,481,311
Income tax expense 43,539,727 42,214,388 5,106,933
ocni teN em 431,314,21665,722,17701,546,96
N et income per share, basic $ 1.18 $ 1.33 $ 0.24
N et income per share, diluted $ 1.10 $ 1.26 $ 0.23
Weighted-average shares 59,047,914 53,699,115 52,632,000
outstanding, basic
Weighted-average shares 63,543,662 56,731,054 54,574,266
outstanding, diluted
Stock price (at year-end) $ 30.74 $ 60.22 $ 25.10
Market value (stock price shares, $ 1,953 $ 3,416 $ 1,370
in millions)
The Hero Called to Action
24
Stock Price for IVK Corporation
$0.00
$10.00
$20.00
$30.00
$40.00
$50.00
$60.00
$70.00
$80.00
Apr X 2
Jun X 2
Aug X 1
Oct X 1
Dec X 1
Feb X 1
Apr X 1
Jun X 1
Aug X
Oct X
Dec X
Feb X
Apr X
Jun X
Aug X + 1
Oct X + 1
Dec X + 1
Feb X + 1
Apr X + 1
25
chapter two
CIO Challenges
Friday, March 23, 9:48 PM . . .
By late in the evening, a sense of foreboding had settled over Barton.
He wandered from one room to another in his upscale condo, stopping
to fl ip through news videos, sound muted, without perceiving the images that fl ashed on screen. Several times he tried to call Maggie, the
woman hed been dating for the past two years. Barton was frustrated
that, on top of the days events, he was stuck home alone on a Friday
night because Maggie, a management consultant, was on temporary
assignment in another city. She was probably with clients, but it was
odd that she was not answering. Given his overall state of mind, Barton
was inclined to assume the worst.
He thought about going for a run, but he preferred mornings for
that. Going online, he discovered that his nephew, a technology, music,
and video game enthusiast, had recommended some music. Jack often
sent Barton interesting things, like links to music or funny videos. Barton and his nephew shared a special relationship, though they didnt
see each other very often (Jack lived in the suburbs, which might as
well have been in another country as often as Barton made it out there
from the city).
Delighted with the distraction, he accessed the music, an album by
a band called Black Box Recorder. Barton hoped for something that
would lift his spirits, but he could see immediately from the song titles
The Hero Called to Action
26
that he was out of luck: Girl Singing in the Wreckage and Its Only
the End of the World didnt sound upbeat. Barton cued the new tunes
and channeled the music to his high-end sound system, cranking up
the volume. Toward the end of the album, the lead singer offered some
breathy advice that struck Barton as fi tting: Well you can bite the bullet,
breathe in, breathe out , the singer whispered, against a stark backdrop
of percussion and guitar, Or be a victim all your life . It made Barton
laugh. Seizing the energy in this burst of levity, he decided to get out
of the condo for a while, take a walk, fi nd something to lift his spirits.
Grabbing a coat, he left without turning off the music.
Forty or so minutes later, hitched up to the bar at Vinnies Bistro,
he found himself in a serious conversation with a kid who, Barton assumed from his looks and the way he talked, did some kind of techrelated work for a local business or university. The guy was in his late
twenties, Barton guessed, just a decade or so younger than Barton himself, but total kid and total nerd in the way he interacted. In the time it
took to drain a beer, Barton had told his sad tale of career misfortune.
The kid had advice. He kept repeating a phrase that Barton couldnt
quite follow:
Y ouve got to know what you dont know.
Huh? responded Barton.
What you dont know. Y ouve got to know it.
How can I know it if I dont know it?
No, I dont mean you should know the things that you dont know.
I mean that you should know the things you know, and know what you
dont know.
Barton shook his head, perplexed. How are those things different?
The things you know and the things you dont know? Because you
know one and you dont know the other.
Y eah, but you think I should know them both. I see how to know
the ones I know but its that know-things-you-dont-know bit Im tripping over.
Let me start over, the kid said. In taking on a new assignment, such
as the one youve been given, you have to . . . you have to realize that
there are some categories of things that you know, and some things that
you dont. And you have to know what is in which category.
CIO Challenges
27
Oh, I see. I think. I dont have to actually know things I dont know,
I just have to know what they are and realize that theyre in the dontknow category.
The kid drained the last of a mug of root beer and slammed it down
hard on the bar. Thats it!
Despite himself, Barton felt proud. He took a sip of his second beer,
which the bartender had just delivered.
So, what about it? the kid asked.
Huh? said Barton.
What about it? Do you think you . . . you realize what categories of
things you know and what categories of things you dont know?
Barton thought about this. Y es, he said. I defi nitely dont know the
techie stuff. I defi nitely do know the management stuff.
Hmmm, the kid said.
What? asked Barton.
Y ou sure about that?
About what? Im sure I dont know the techie stuff.
The kid raised his eyebrows, a gesture that suggested wisdom Barton
thought he could not possibly possess. So what about the management stuff, as you put it?
Barton was indignant. Of course I know that stuff. Im the best
manager theyve got. Thats why theyve chosen me for this job.
Okay, said the kid. He motioned to the bartender, ordering another soft drink. The bartender shouted down to Barton, Y ou want
another too? Barton shook his head. He was fi xated on the kid and
what he was saying.
Y ou dont seem convinced.
Are you?
Y es.
Hey, fi ne. Whatever.
But you dont believe me. Even though you dont know me and
have never seen me manage anything, observed Barton.
Its not that, said the kid, receiving a new, frosty mug from the bartender and taking a sip. Its nothing to do with you personally.
What is it then?
The kid shrugged. Im a technical guywhat do I know?
The Hero Called to Action
28
Im not asking you what you know; Im asking you what you think.
Its just, he said, now turning to Barton with a slightly vindictive
tone, that Ive worked for a lot of people who think theyre good managers, and what they dont know is that they dont know a rainforest
from a desert. So, nothing personal. I just think most people who think
they know the management stuff probably dont really. Y ou might be
an exception. He shrugged again.
Barton thought about this. It sounded like the kind of thing one
should keep in mind when taking on a new job. The boundary between
technical and management stuff might not be clear-cut. Fair enough,
he said to the kid.
The kid seemed surprised. Y ou might be an okay manager after all,
he said.
So if you were me, Barton asked, what would you do on Monday?
What would you do on your very fi rst day?
Easy, the kid responded. Start trying to fi gure out who on your
team is really good. Y ou dont know the techie stuff, as you put it, so
it wont be easy for you to tell who in the department is really good
and who isnt all that good. Lots of managers never really know that.
And, to pick up on our earlier conversation, they dont know that they
dont know it. Which makes them do stupid things, like reward dolts
and underappreciate genius. Put people on the wrong projects. Insist
on objectives that make no sense. Everyone realizes it when managers
dont know what they dont know. Its a state of blissful management
ignorance. Theres defi nitely a talent in itdont get me wrong. Some
people get paid quite a lot of money not to know a rainforest from a
desert. They succeed mostly by managing the appearance of success
rather than actual success.
Just then, Bartons ringtone sounded. It was Maggie.
Hi Jim. Looks like I missed several calls, she said. Everything
okay?
Not really, he answered, but nothing dire or life-threatening. If
youve got some time, Ill tell you about it.
Ive got time now, she said. We had a team meeting that went
late or Id have called you back sooner. Where are you? Shed heard
background noise.
CIO Challenges
29
Im at Vinnies.
Uh-huh. And how many beers have you had?
There was no use feigning innocence; she could tell that he hadnt
been drinking coffee. A couple, he admitted.
How about, she said, if we talk while you walk home?
This was fi ne with Barton. He was eager to tell her about the days
events. He and Maggie chatted while he paid the bar tab, then he turned
to go, nodding to the kid. A few steps toward the door, he suddenly
stopped and turned around.
Hey, kid. Want a job?
The kid laughed. Not right now. But ask me again in a few weeks.
Maybe then. And you can tell me how its going.
Fair enough. Barton exited the bar, returning to his call and pouring out his sad tale to Maggie while she made satisfyingly sympathetic
noises at the other end.
Sunday, March 25, 8:15 AM . . .
Barton sat on cold pavement, legs outstretched, reaching for his toes,
prepping for a long run around the park. He needed it. Hed slept in
and skipped running on Saturday. Off his daily ritual, hed felt unsettled all afternoon, as he hit the dry cleaner and drug store and stopped
in a grocery to grab some ready-to-cook dinner. Hed spent Saturday
night watching comedies and listening to the music that Jack had recommended, then gone to bed early.
The relatively mindless Saturday pursuits had left him with plenty of
capacity to think about his fi rst day as CIO on Monday. The obvious
fi rst thing to do would be a meeting of his direct reports. Hed have sent
out notice of the meeting on the weekend, but he realized that he wasnt
even sure who the direct reports to the CIO were. Sending the notice on
Monday morning wouldnt be too much of a problem; they would all
be expecting it.
At the meeting, Barton intended to propose a day or two of offsite meetings sometime in the next two or three weeks; he would ask
his managers to present the current status of the activities within their
The Hero Called to Action
30
areas, the challenges that needed to be met in the coming months, and
opportunities to create value for the company. Using the current situation as a basis, he then wanted them to work together to construct a
future vision for the role of IT in the business. Before too long, theyd
need to hold an all-hands department meeting, the fi rst for Barton as
their new leader; they could begin to plan that also.
That would be the morning. In the afternoon, he wanted to spend
some time with the Planning and Control guy. Gary Geisler was keeper
of the fi nancial information that pertained to IT budgets and expenditures. Barton expected to fi eld questions from the CEOs offi ce about
how much IVK spent on IT. Right now, he didnt even know the right
categories for analyzing IT spending (but he knew he didnt know,
right? ).
As Barton began to jog down a path, he suddenly had a disturbing
thought. Sometimes, he recalled, Bill Davies jogged around here. Barton had occasionally encountered him on this very route. Davies surely
knew by now who his chosen successor was, but Barton was unsure
how Davies might react to the news. There was more than a little irony
in the fact that his most vocal critic had been stuck with his job. Davies
might relish that. But it couldnt feel very good to get fi red; Barton had
never experienced that, didnt care to.
A few minutes later, two paths converged and, to Bartons horror,
he found himself running almost side by side with Davies, who didnt
seem to notice at fi rst. If Barton stopped suddenly, he would have
drawn attention to himself. Worse than that, it might have given Davies
the impression that Barton was intimidated or embarrassed, and he
was deeply averse to communicating either sentiment. Instead, he felt
inclined to reach out to Davies. Not to apologize exactly, although that
might have been appropriate, especially for some of the wisecracks hed
made about Daviess benevolent dictator leadership style and quirky
wardrobe. But maybe to say no hard feelings, to convey some respect
for the work the other man had done. And maybejust maybe, Barton
realizedto create the option of consulting Davies about things in the
future. This was not something he would be inclined to do at fi rst, but
there might come a time when it would be useful. Barton did not believe in burning bridges.
CIO Challenges
31
So when Davies slowed down and stopped to rest and stretch, Barton did also.
Hi, Bill, said Barton.
Hello, Jim, responded Davies.
Nice day.
A bit cold for March.
A pause grew uncomfortable. Barton broke it: I guess you heard . . .
I did. Said too quickly, to cut off whatever else Barton was about
to say.
Barton waited to give Davies time to say more, but he stayed quiet.
Barton opted for brevity to fi ll this new silence: Ironic, huh?
I laughed for about half an hour when I heard.
Said in a monotone. Barton looked closely, trying to discern whether
the remark was a friendly joke or a hostile dig. The guys social skills
had never been great, so Barton fi gured this might just be awkwardness. He might not mean anything by it. Maybe it was just poorly calibrated candor.
Barton made a peace offering: Hey, I just want you to knowwe
had some disagreements.
We sure did.
Again, Barton could not read the sentiment behind the words. He
continued: I was out of line at times, and I feel bad about that. Davies
shrugged. Barton pressed ahead: I guess I just want to say No hard
feelings, not on my part.
Confusingly, Davies began to laugh. Soft at fi rst, his laughter quickly
gained volume. Barton looked around to see if anyone else was nearby,
embarrassed for Davies, a little worried what he might do next. Just
when Barton was beginning to wonder if the guy might be coming
unhinged, the laughter stopped. Davies turned to Barton, looked him
right in the eye and said: What you dont realize, Jim, is that youll be
gone soon too. That company is a madhouse. Nobody could succeed
running IT in that place. Y ou wont last a year.
Barton started to answer, but Davies wasnt fi nished: Dont feel bad
for me, he added. I start a new job on Monday. I even got a raise. And
youre going to need all that feeling-bad capacity for yourself when you
get tossed out on your butt.
The Hero Called to Action
32
Without waiting for a response from Barton, Davies sprinted away,
making it clear that he didnt want to be followed.
Barton couldnt have followed him anyway.
The offer of the CIO job had provoked many strong reactions in
Barton. Hed felt put-upon. Hed patted himself on the back for being
a good guy, willing to take one for the team. Hed supposed himself
the most fl exible member of the senior management team, imagined
how grateful his CEO and management peers must be, seeing him act
in such a selfl ess manner. He knew that the job would be hard and had
considered that he might even fail at it. But until this momentuntil
Davies had said what hed just saidJim Barton had not once considered the possibility that the company might unceremoniously boot
him if they didnt like what he did with the IT department. Y et how
could they? It would be like spitting in the face of a hero.
But as Barton contemplated Daviess words, he knew they contained
truth. In business, memories were short. Nine months from now, no
one would remember what a great guy hed been to take the job. Theyd
just know it was his job, and if they thought he was doing it badly, theyd
feel no more loyalty toward Barton than he had felt toward Davies. A
lot couldand wouldchange in a short time.
So if he was going to take this jobif Jim Barton was going to become the CIO of IVKhe would need to expect to be judged on his
performance, regardless of the defi cit of experience in the area that was
his starting point. It was obvious, reallythe kind of point he might
have made to Davies in a past discussion. Hed been deluded to think
otherwise, and the sudden shoe on the other foot reversal shook him
to his core.
Sighing deeply, he set off down the path in the direction Davies had
not taken.
Sunday, March 25, 3:15 PM . . .
By early afternoon, Barton had gotten over Daviess challenging assertion and reverted to a more helpful mode of thinking about concrete
fi rst steps in his new job. One obvious idea would be to meet with CIOs
CIO Challenges
33
of other companies who might be willing to share with him how they
thought about their jobs. But he wasnt sure how to go about this. Hed
never been a CIO and did not have a network of CIO associates. Maggie was his ace in the hole, however. She worked closely with many IT
managers and knew many CIOs. It would be a matter of telling her the
CIOs or the companies hed like to approach.
He wasnt sure what to tell her, however. Competitors wouldnt do.
They couldnt be counted on to be forthcoming, and there might even
be legal issues. On the other hand, hed have to be careful about whether the way very different kinds of companies used IT would be relevant to IVK. To some extent, of course, which companies he met with
would be determined by the willingness and availability of the people
he approached.
After a few minutes of thinking about this, Barton called Maggie.
Hey there, she said. I was just about to call you. How are you feeling
today about the fast-moving events in your life?
Barton laughed. A little whiplashed, but okay, I guess. How about
youyou spend a lot of time with CIOs alreadysure you want to be
involved with one?
Y ou mean, will I still love you if you turn into an IT nerd? Im not
sure. But I think I can handle it.
Gee, I sure hope so, said Barton trying on a fake nerd voice, realizing he was no good at it, then reverting to normal tones: Seriously,
though, I am getting more practical about it, thinking about how to do
it. If I do it.
That sounds like a good thing.
I think so. I was wondering if it might make sense for me to meet
with other CIOs, people who might know a lot about how to do this
job. But I dont actually know anybody helpful
Ah, but youre thinking maybe I do?
Y ep.
Y et again, you want me for my knowledge.
Among other things.
Well, she sighed playfully, okay. But itll cost you. Want me to set
up some lunches?
That sounds about right.
The Hero Called to Action
34
Its a terrifi c idea. But what you get out of it, Jim, Ill tell you right
now, is going to be highly variable.
Okay, Maggs. Whys that?
Because to get to the level of discussion that will be really helpful,
youre going to have to get to know these people. Surface-level stuff
will help some, but to get into the next level of discussion, youll have
to have a relationship. So I think you should meet with some of them
not just once, but periodically. The most valuable guidance will come
in time, not right away.
Makes sense. How about if we set up some fi rst meetings, then we
can fi gure out who seems promising for repeat engagements?
Y eah. Im thinking local metro area, but youd probably be willing
to fl y an hour or two for the right lunch date, right?
Absolutely.
Any thoughts, she asked, on which companies, which CIOs?
I dont really know any CIOs, Barton answered. And Im not sure
how to think about which companies.
How soon would you like to start?
Not sure about that either. Im tempted to say as soon as possible,
but maybe you think theres some level of expertise I should acquire
before I start this process?
No, I dont think thats the issue, unless that would make you more
comfortable. Tell you whatwhy dont you think about it some more
and send me what you come up with? Tell me how you want to choose
companies or CIOs, when you want to start, how often you want to meet,
any other details important to you. Ill probably vary from your guidance
where I think its a good idea, but this would give me a base to start from.
Thanks, Maggs. Ill do that as soon as I can, next couple of days.
Id do it today, but Id like to get a bit of a read from some of my new
management team.
Doesnt sound like youre thinking about this assignment hypothetically anymore. Decided to take the job?
Lets just say that I havent decided to leave, so I guess maybe thats
the same thing as deciding to accept.
Y ou okay with me setting up some meetings with other industry
folks, not necessarily CIOs?
CIO Challenges
35
I think so. Who do you have in mind?
Some analysts, the ones who have a clue, and maybe some key people who work for IT vendors or service fi rms, people who I know are
smart. Maybe some industry movers and shakers, people who are involved as investors or who have other reasons to want to keep track of
where they think things are headed in the IT industry.
Wow. Thatd be great. I might fi nd it particularly helpful to talk to
people who have a business view into IT.
Have you thought about whether there are other strategic
lunch engagements you should seek out? How about meeting with
customers?
I know all our customers pretty well. I was head of Loan Ops until
about forty-eight hours ago, you know.
But you dont know them as the IVK CIO. Y ou might be surprised
by what you dont know that they might tell you if you present yourself
as the new CIO and ask questions about how well IVK is meeting their
business needs with IT.
Thats a good idea, said Barton, though privately he was less than
fully convinced. If his customers had been having trouble with IT, hed
have known about it.
By the way, Jim, I saw a presentation the other day about how IT
management is changing. I took some notes to send to a couple of my
staff. I can send them to you, if you like.*
Ill look forward to seeing them. Thanks, Maggs, said Barton.
Anyone else you want to meet with?
With all these ideas youre coming up with, Im going to have to
prioritize a bit. Cant meet with them all right away.
Y ou give it some thought, Ill give it some thought. Well formulate
a plan.
Right. Lets fi gure out what to do.
Then do it.
Right. Barton shifted gears, So, how are things there? That handsome banking client behaving himself?
* See Maggies notes on The IT Manager as a Business Leader at the end of this
chapter.
The Hero Called to Action
36
Jim, Jim, Jim, Maggie said, feigning disappointment, an exasperated headshake conveyed in the rhythm of her words: Is that your way
of saying that you miss me?
REFLECTION
How do you interpret the kids advice: Youve got to know what you dont
know?
Why do you think Davies got fired? How likely is it that Barton will be fired
within the year?
What kinds of questions should Barton be asking of CIOs, analysts, investors,
customers, and other IT movers and shakers? How should he prioritize and organize these meetings?
CIO Challenges
37
Maggies Notes on The IT Manager as a Business
Leader
Barriers That Prevent IT Managers from Becoming Business Leaders
According to surveys of top IT managers, the barriers that keep IT
leaders from becoming true business leaders are, in rank order:
IT managers lack business skills and competencies
Business leaders failure to understand importance of IT or
misperceptions of the IT management role as the organizations information plumber
ITs distance from customers and the customer experience
IT managers lack time to spend on strategic issues
IT managers too often left out of enterprise digitization discussions in other parts of the company
ITs poor collaboration with lines of business
Lack of support for and attention to IT from the CEO/board
Insuffi cient authority or responsibility given to the IT
organization
The vast majority of top IT managers said they sought a more
strategic role, a greater role in making or shaping strategy.
Global Shifts Aff ecting the IT Management Role
Majority of companies have become more focused on using IT to
increase market share, moving beyond past emphasis on cost
cutting
Proliferation of options for sourcing IT services off premises
The Hero Called to Action
38
Digitization aff ecting all areas of the enterprise, in the form of
social media, internet connectivity in products, business analytics,
and accelerating development cycles
CEOs expect IT managers to manage people, fi nances, and materials, not just technology
CEOs expect IT to contribute to a fi rms strategy fl exibility; they
must be able to absorb change
In too many fi rms, IT managers dont see far beyond operational
focus; in many fi rms with progressive IT capabilities, an enlightened CFO, COO, or CEO is the real driver, not the CIO
IT leaders are being called on to take a broader role in corporate
leadership
Mature, global communications and transportation networks
have enlarged the competitive stage; pretty much anyone can
now reach into your back yard and go after your companys
customers
Some Key Factors in Future IT Manager Success
Enhancing and maintaining relationships with other business
leaders
Ability to develop an organization of talented technologists who
understand the business
Ability to educate CEO and peer executives on new possibilities
enabled by digital technologies and on key business trade-off s
implicit in technology choices
Ability to clearly express a compelling vision for the digitized
future of the enterprise
Imperatives
Speak the language of business inside IT and especially with business partners
CIO Challenges
39
Keep a strong connection with the CEO and business peers
Stay fully abreast of the emerging possibilities that digitization
presents across the enterprise and be prepared to off er views
about priorities and trade-off s
Dont lose sight of effi ciency; be a relentless cost reducer, but
know thats not enough
Understand impacts of IT on the revenue and cost sides of the income statement
Invest in agility of systems and IT architecture
Establish a robust governance framework; manage the project
portfolio to maximize return
Skillfully manage sourcing and partners
Manage talent; build a smart organization
Enable innovation; enable change; be competitively relevant
Safeguard the information assets of the organization; maintain
robust infrastructure and assure business continuity
Source: This exhibit was originally loosely based on an article by S. Sadagopan, Meet the New
CIO, Opinion , November 19, 2007. It is also inspired by the results of surveys of CIOs conducted
by IBM over a number of years; see, for example, http://www-03.ibm.com/press/us/en/pressrelease/43417.ws.

41
chapter three
CIO Leadership
Monday, March 26, 10:43 AM . . .
I think its a question of whether the fi ve of us working alone will be
able to accomplish what you have in mind, said Bernie Ruben, director
of the IT departments Technical Services Group. The others around
the table controlled their movements and facial expressions, but Barton
could tell that they agreed. Ruben, at least twenty years Bartons senior,
near enough to retirement to feel safe or simply old enough not to care,
was the bravest of his direct reports. Rubens voice contained no fear as
he spoke, which differentiated him from the others in the conference
room: Raj Juvvani, director of Customer Support Systems, Tyra
Gordon, director of Loan Operations and New Application Development Systems, and Paul Fenton, director of Infrastructure and
Operations; all younger, with more to lose.*
The meeting had not gone according to Bartons plan. First thing
that morning, hed asked Jenny, his assistant, to fi nd an IT department
organization chart. With that in his possession, hed ascertained who
reported to him and summoned them to a 10 am meeting. He chose
to assemble only his operating managers, so he didnt invite Gary
Geisler, a more junior manager with whom he planned to meet later in
the week.
*See IT Organization Chart at the end of this chapter.
The Hero Called to Action
42
Once they had all assembled, exchanged greetings, and submitted
brief status reports, Barton had fl oated his idea of an off-site management meeting to set direction for the department. Before the meeting,
Barton would have been hard-pressed to imagine any reasonable objections to his plan. Hed expected quick acceptance followed by a session of planning for the event.
But hed been wrong. No more than three or four minutes into his
explanation of what he had in mind, Fenton had interjected a question:
You want just the fi ve of us at this off-site?
Thats what I was thinking, said Barton. Fenton and Gordon exchanged knowing looks. Barton had not understood the question; he
tried for clarifi cation: Why not just the fi ve of us?
Fenton shifted uncomfortably. He glanced in the direction of the
others and saw that no help would be forthcoming.
Its just that well only be able to go so far in certain discussions
without other people involved, said Fenton. For example, if we want
to talk about security, Id want to involve John Cho.
John Cho? said Barton.
The others nodded as one. Ruben spoke up: Cho. You know him.
Wild hair, purple streaks. Boots. Black tee shirts adorned with human
skulls. Piercings.
That guy, said Barton, nodding. Been in meetings with him. Not
sure Ive been formally introduced.
Hes whats standing between this company, said Ruben, and the
armies of hackers whod love to loot a fi nancial services fi rm.
Are we sure Cho is on our side? Barton intended this as a joke, but
it fell fl at.
Fenton, speaking up for his employee, said: Oh, John is defi nitely a
white hat.
A white hat?
They all nodded, again in sync. Ruben smiled, said, Although he
wouldnt be caught dead actually wearing one.
Everyone laughed, which shattered the tension in the room. It was
the effect Barton had been going for when hed tried his joke. Ruben
had realized it, done Barton a favor.
CIO Leadership
43
What if we wanted to talk about security at a management or policy
level? Would we need John Cho then?
Johns really a nice guy, despite his attire . . .
Its not that, Barton interjected. Im not trying to avoid having
John Cho in the meeting. I just think it makes sense as a starting point
to have the fi ve of us reach consensus on some things before we expand
the circle.
It really depends on what you want to talk about, said Ruben.
Id hoped we might talk about how things are going, challenges we
see in the present and future, risks, and our vision of how we think IT
ought to contribute to the success of the company. I also want to fi gure
out where IT is being prevented from doing its best work by impediments in the way the rest of the company works. IT is more important
now than it ever has been.
Barton stopped talking to avoid making a speech. He looked around
the room, saw more deer-in-the-headlight looks. Thats when Ruben
made his whether the fi ve of us working alone will be able to . . . remark. It seemed to Barton that they were all making this situation
much more diffi cult than it needed to be. He knew nothing about IT;
these folks had been doing it their entire careers. Shouldnt they have
enough expertise to hold a high-level planning meeting without involving their tech nerds? Shouldnt Fenton know a thing or two about
security by now? Barton wondered if he was getting insight into the
weak performance of the IT organization over the years. Maybe his
managers were not very good. At the very least, they seemed to have
fallen into some bad habits, such as unhealthy reliance on people whom
they surely couldnt supervise properly if they didnt understand the
details of the work well enough.
Barton recalled a defi nition of supervision that hed liked well
enough to memorize, although he couldnt remember now where hed
fi rst heard it: A supervisors job is to encourage employees to engage in appropriate actions, habits, and behaviors, and to direct changes in those
actions, habits, and behaviors when business conditions shift in ways that
necessitate such changes. How could these people do this if they couldnt
even hold a management conversation without consulting technical
The Hero Called to Action
44
specialists? Did they, Barton wondered, have any idea what was going
on in their own organizations?
What do you think the fi ve of us alone could accomplish? asked
Barton.
Eventually they settled on a tentative plan that met Bartons objectives of making his direct reports responsible for the activities within
their own groups, but at the same time tapped external expertise where
his managers thought they would need it. They would hold their meeting off-site but nearby. They would begin a discussion with just the fi ve
of them, then pull in three more key people from each area with whom
to continue the discussion. Barton insisted that they fi nish the meeting
with just the core fi ve.
Thus ended the fi rst gathering of the management team under Jim
Barton, the new CIO of IVK, at 11:24 am.
Barton let the group disperse, then set off in the direction of Rubens
offi ce. He found Ruben listening to his voice mail. He waved Barton
into his offi ce, but fi nished listening to the current message before
turning to Barton.
Have a seat, said Ruben, motioning to a chair stacked with paper.
Barton moved the paper to an edge of Rubens untidy desk and sat
down. What can I do for you? Ruben asked, fl ashing an accommodating, apparently sincere smile.
You seem to be the one in this group willing to stand up to me, said
Barton, so I was hoping you could help me understand a few things.
Ill do my best.
Barton thought for a minute, at fi rst trying to formulate his words
carefully to avoid the possibility of causing offense, then fi nally jettisoning that idea and deciding to shoot straight: I guess I dont see
why the IT department heads need to have their sidekicks present before they can have a productive discussion. Ive done this lots of times
in other organizations, and Ive never run into this objection before.
Ruben seemed to gather his thoughts before answering. Well, he
said, possibly we are simply wrong or dont understand what you have
in mind. But possiblyjust possiblyIT is different.
Barton snorted. Everybody thinks theyre special. Is IT really different or do IT managers just think its different?
CIO Leadership
45
I dont know, answered Ruben. But maybe I can suggest some of
the reasons why IT might be special if , in fact, it is.
Love to hear it, said Barton, sitting back in the chair and folding his
hands on his lap to signal open-mindedness.
Youve been heading up Loan Operations for the past few years,
Ruben said. I suspect that makes you the most expert person in the
building about the intricate details of Loan Operations.
Barton nodded.
I suspect, continued Ruben, that you can do the job of anyone in
Loan Operations as well, if not better than, they can do it. Or if not, you
could probably get back to doing it that well within just a few minutes
or hours of starting to do it again.
I suspect, Barton echoed wryly, youre right about that.
Well, said Ruben, none of us in IT can say that. Technology moves
fast. Our people, many of them, are specialists. I was once a programmer, but the kind of programming I did bears little resemblance to
what our programmers do now. I get the gist of it, but the details left
me in the dust a long time ago.
Moreover, some of our people are quite a bit more talented in their
specialty than any of us managers ever were. These are people who, in
terms of absolute intellectual horsepower, are probably a good bit
smarter than you or me, but who have little or no interest in doing the
jobs you and I do. They like the deep details, and they work with them
expertly in a way that we, as managers, cant see into very well. So we
have to depend on them to tell us whats going on in the details. Our
ability to independently verify what they tell us is rather limited. We
can tell the big things, like Are we done? or Does it work? at least to
some degree, but most of the things that go on from day to day are not
those big things. The interim stuff is a lot harder to observe and evaluate. These are the simple facts of our daily reality.
This would all be merely interesting if it werent for the additional
fact that in IT, the details often matter. There are all kinds of business
issues fl oating around within IT, but they are generally wound around
and in between technical issues. As managers, we have to tease them
apart so we can make the kinds of trade-offs we need to makelike
Should we spend more money to reduce our risk of exposure to
The Hero Called to Action
46
hackers by a certain amount?knowing full well that we can spend an
infi nite amount and never completely eliminate that risk. To put dimensions on this trade-off and others like it, we need to see into the
details better than any of us still can. It would be nice to think we can all
keep up with the technical stuff, and a few remarkable individuals
probably can manage it, but most of us mere mortals cant. So we depend on sidekicks to help us tease apart business and technical issues,
and to put dimensions on trade-offs. Make sense?
Barton nodded thoughtfully, but said nothing.
Even with the sidekicks, its really hard, Ruben added.
Barton wasnt completely buying this explanation, but he didnt say
so. Any chance, asked Barton, you could give me a little primer on
who does what around here? Obviously, I dont understand what goes
on in the IT organizationdown inside it, I mean. I realize John Cho is
an important guy here, but everyone seems to have a sidekick. Im
guessing youve got some in your own organization.
Yes, in the database group, most notably Gita Puri. Shes a whiz,
though probably not quite as hard to replace as Cho.
So, okay, lets see. Let me try to do a high-level walk through of the
department, see where these people might live. Starting with my area: I
have three groups that perform mostly staff functions. One group is all
about process improvement, identifying new IT approaches, important
new technologies, and so forth. Think of this as a sort of internal consulting group. Very smart people, a couple with sky-high potential, but
no one with such mission-critical smarts that theyd provoke a crisis if
they left the company.
The database group is a different matter. They make sure we have
robust database designs underlying all of our systems; theyre also helping us develop new, very promising business analytics capabilities, potentially game-changing stuff. Their expertise is rare, and its not just a
matter of understanding the technology. Theres a talent to it thats relevant whether the databases in question are inside our walls or out
there with a service provider. Gita is our reigning expert, easily the key
person in my department. Shed be very tough to lose. Part of what
makes people like Gita valuable, too, is their knowledge of the database
CIO Leadership
47
technologies already in place and the history of decisions that
determined why things are designed as they are.
Finally, I have a group that focuses on infrastructure and vendor offerings, making sure that as new vendor products and services appear
a new computer or portable device, a new service offering proposed as
a replacement for an old onethey all work within our existing architecture. This group works with vendors to make sure we have the information we need to install and support new equipment, software
versions, or service interfaces, and they pressure vendors not to drop
support of old technologies we still need too quickly. You could think
of this as our vendor management group. Thats what they do mostly.
No irreplaceable assets, although there are a lot of established relationships between our people and vendor personnel that would take time
to rebuild.
Take Rajs area next. As you know, they primarily support customer
service systemsreally important stuff because of the way it immediately cripples us if the systems go down. We cant process new applications or deal effectively with customer calls without those systems. His
is primarily a business applications systems group, focused on the corresponding customer serviceoriented business units. Unlike my area,
say, which has the luxury of taking a longer and overall business view,
his area is very closely tied to day-to-day business concerns. He has
about three application developers, super coders or architects, although
none of them quite as good as Ivan Korsky, the best in Tyras group.
Nevertheless, theyd probably be very diffi cult to replace; any one of
them leaving would have serious consequences to our ability to deliver
on promises to business partners and customers. Im probably a bit out
of date on Rajs area, so you should consult with him to be sure Ive got
this right.
Tyras area you know, because it faces off to Loan Ops, the same way
Rajs faces off to Customer Service. Hers is the biggest application
group in the company, bigger than Rajs because it has become where
we develop platforms for institutional clientsnot just Loan Operations but a lot of related web-based services that clients really care
about. You know all about this, though, because you managed the
The Hero Called to Action
48
business side not so long ago. Ivan Korsky is her heaviest hitter, but Id
bet she has another fi ve or so it would really hurt to lose.
Finally, we have Fentons area, the Infrastructure Management gang,
also pretty large. Pauls group is, in a way, an odd mix of very technically
talented folks and relatively low-tech folks with a lot of familiarity with
existing ways of doing things but not deep skills. The very high-tech
people are the ones like Cho, or the very technical network engineers.
Top-fl ight talent, seriously hard to replace. More and more important as
we gradually come to depend on more services from out in the cloud. At
the other end of the spectrum are the people who keep an eye on our
oldest systems to make sure they work. These are systems important to
our business that we havent gotten around to updating for one reason
or another, that still require manual interventionmoving resources
around, starting jobs and making sure they complete successfully, that
kind of thing.
Fenton also has the facilities people, the ones who make sure we
dont run out of power or communications bandwidth. Thats mostly
technical real estate work for our onsite systems, making sure we have
fl oor space, climate control, connectivity, power, physical security, and
so on. Id say Fenton has maybe fi ve employees with deep dark technical talent. The risk of them leaving is a bit less critical because hes
pretty technical himself. Of all of us managers, hes the one who retains
the most technical know-how that is still relevant. Hes stunningly
competent in what he does, so much so that we borderline abuse him
by making him work too hard. But as youll notice, hes probably, of the
four of us, the least managerial in his orientation. Took him a while
when he fi rst landed the job to become a good manager, but I think hes
got it down pretty well now.
Ruben stopped. Thats pretty much it, he said. Does that help?
Barton nodded. It helps. All those key people happy here at IVK?
Like their jobs? Their bosses?
Ruben looked at Barton quizzically, as if trying to discern what he
was really asking. Then the older man shrugged and ventured what
seemed to Barton an overly cautious remark: Theyre all different;
some of them grumble their fair share, but I doubt anyones on the
verge of leaving, if thats what youre concerned about.
CIO Leadership
49
Thats what Im concerned about, Barton acknowledged. How
about Cho? he asked, picking as a for instance the person who came
most easily to mind.
Rubens expression fl ashed surprise before returning to normal.
John? His talent for grumbling rivals his technical talent, but I dont
think hell leave us any time soon. Ask Fenton. But I think weve proven
more willing to accommodate Mr. Chos unusual working hours than
another company might be.
Barton smiled. He suspected Ruben knew more than he was telling;
he made a mental note but decided not to press. I really need to think
about all this.
Indeed, said Ruben. I would guess you have quite a bit to think
about.
Barton smiled, added a diplomatic chuckle that wasnt very heartfelt
and probably didnt seem so. He stood and moved to the door. Thanks,
Bernie, he said, transitioning to an entirely genuine sentiment.
No problem. Come back any time, well talk more.
Im pretty sure, said Barton, that I will.
Monday, March 26, 12:12 PM . . .
Back in his offi ce, Barton contemplated the statement on the whiteboard: IT management is about management . Beneath this lone statement, he began constructing a list, adding a fi rst entry: Skill and talent
mgmt/key skills, key contributors. He had no idea what a solution in
this area might look like, but after the mornings meeting and the discussion with Ruben, he believed this was an important sub-topic of IT
management. He wasnt sure yet whether the problems Ruben had
describedknowing who your key people are and being able to supervise them and know what they are doingwere separate and needed
different solutions, or whether they were part of the same issue. At this
point, the new item on the whiteboard was a placeholder. Hed have to
hope clarity would emerge in this area.
Before putting the pen down, he considered writing something
about his encounter with the kid at Vinnies Bistro on Friday night, and
The Hero Called to Action
50
maybe something from his subsequent encounter with Davies. But he
didnt think those things were part of a system of management he
might come up with. They were more like challenges, things to remember. Up in the corner of the whiteboard, Barton wrote: KWYDK, his
own private code for Know what you dont know. Then, at the bottom right corner of the whiteboard he wrote Daviess challenge:
YWLOY. You wont last one year. Good things to keep in mind, but
not for others to understand.
KWYDK
YWLOY
IT management is about management
Skill and talent mgmt/key skills, key contributors
Wednesday, March 28, 7:35 AM . . .
Stuck in traffi c and running late for a 7:30 am meeting with his executive assistant, Barton fi ddled with his Audis sound system. The traffi c
started to move just as he landed on a station carrying a business story.
Interestingly, it was about a CIO whod had a major problem at a large
hospital. 1 Barton listened attentively, but hed come in at the middle
and wasnt sure he understood what had happened. The story digressed
into a mini-biography of the CIO that made Barton feel incredibly inadequate. The guy was amazing. A critical-care physician who still took
his turn in the ER; PhD from MIT in bioinformatics; former entrepreneur who had started, grown, and sold a company (while completing
medical school); and former student of a Nobel Prizewinning economist. He was also the author of four books on computer programming
and had written the fi rst version of many of the hospitals software applications himself. Barton marveled, I bet he doesnt need three technical
experts with him to talk about IT management issues.
Breaking free from the crawling traffi c, Barton guided his car into
the IVK garage, which promptly interfered with his radio reception.
Between crackles, he gathered that the hospitals computer network
CIO Leadership
51
had been down for some days and required heroic intervention by a
network equipment company. The CIO had earned kudos for the
transparency with which he dealt with the crisis and, in an interview,
highlighted his lack of networking expertise as the reason hed failed to
foresee the problem. He listed the areas of his expertisea formidable
listbut then pointed to a hole in his command of networking
technology.
About that time, the radio completely lost the station.
Barton emerged from his car and walked toward the elevators, making a decision as he did so. Right after work, hed head to a bookstore,
buy some books on IT subjects. There was no way he could become an
expert like the guy on the radio, but he could do some reading, surprise
some people, ask questions he already knew the answers to, just to see
how people would interact with him.
He stepped into the elevator and pushed the Up button to begin
his day.
Wednesday, March 28, 11:43 PM . . .
Barton sat on the fl oor beneath the halogen glow of a crane-necked
lamp, amid piles of books opened and strewn randomly. Two dirty
plates and several takeout cartons lay discarded at the periphery of the
circle of light. He held one book on his lap, his eyes fi xed at midpage.
But it had been a while since hed actually read anything.
Hed left work early to visit a nearby bookstore. Hed wandered
through the vast technology section, picking up books, reading their
back and front material, leafi ng through them, choosing many of them,
and setting aside a pile for purchase. Books on network protocols,
router confi guration, and fi rewall design. Programming in various languages and developer environments, database design and management, operating systems. Project management, systems development
methodologies, and frameworks, and technical team management.
After charging more than $1,200 to his credit card and recruiting
two bookstore employees to help him get his purchases to the car, hed
set out for home with a plan to judge for himself the theory favored by
The Hero Called to Action
52
his direct reportsthat you cant know enough about technology to
manage without a crew of nerd sidekicks. Hed picked up Indian food
on his way home and called Maggie to warn her against contacting him
later that night.
Hed intended to be busy.
A few minutes later, he was on the fl oor of his condo, forking food
into his mouth and studying the basics of network addressing. When
he began, the bright light of afternoon was streaming through the
windows.
The hours passed. All of a sudden, Barton realized that his lamp
alone burned amid the darkness, but he didnt mind. It would help him
concentrate.
In retrospect, the fi rst signs that his plan was ill-fated had appeared
during the conversation with Maggie. He had expected her to be incredibly impressed, but she had been reticent.
Really, Jim? she said, after he read her a couple of the titles on top
of the pile in the passenger seat.
You betcha, he said.
Well, she said. Dont spend too much time on it. I think a general
idea of what all that is all about will suffi ce.
Dont try to protect me, babe, joked Barton, Im up for it.
Okay, she said. But she didnt sound convinced.
By 9:00 that night, though, his mind was swimming. There were so
many different layers. And each layer was complicated as hell. Most of
them had nothing to do with delivering direct functionality to system
users. Hed had no idea so much complexity resided below the fl oorboards of IT systems. By 10:30, no dots had even begun to connect:
hed learned a lot but he couldnt see any way that most of it would help
him manage, except by accident.
Maggie called him just before midnight.
Hows it going? she asked, but he could tell from the sound of her
voice that she knew. Shed known how this whole thing would go from
the moment hed told her of his plan.
I think Im going to need to think a lot more about my assumptions, he said.
CIO Leadership
53
Which ones?
The big ones. I think I might need to rethink my ideas about how
management works. Who can know what. I thought I knew what I
didnt know. I had no idea.
How does that make you feel?
Horrible. Its a huge job, Maggs. I dont know if I can do it.
If it helps any, I think youre reaching the right conclusions. And
youve gotten there a lot faster than most. Some managers never get
there.
Whatever you say.
Im right about this.
Yes, Maggie.
Get some sleep.
Yes, Maggie.
Im coming home this weekend. Ill make it all better.
Barton had forgotten that. Not everything was horrible, then. Yes,
Maggie, he said, smiling.
REFLECTION
Do you agree that IT management might be different from management of
other functions?
What did Barton learn from his trip to the bookstore and late night of studying?
What depth of IT understanding must a CIO leader have to be effective?
The Hero Called to Action
54
IT Organization Chart
Ellen Ripley
Network
Operations
Team Leader
Tyra Gordon
Director of Loan
Operations and
New Application
Development
Systems
Bernard
Ruben
Director of
Technical
Services
Group
Jim Barton
CIO
Paul Fenton
Director of
Infrastructure
and Operations
Rebecca
Calder
Loan Operation
Systems
John Cho
Security
Gary Geisler
Director of
Planning and
Control
TBD
Infrastructure
Jorge Huerta
Customer
Service
Systems
Raj Juvvani
Director of
Customer
Support
Systems
part two
The Road of
Trials

57
chapter four
The Cost of IT
Thursday, March 29, 1:30 PM . . .
When Barton had been in his new position as CIO for four days, a
message arrived from the CEO to announce a series of leadership team
meetings. Theyd begin with a one-hour kickoff meeting and continue
indefi nitely with meetings of two-plus hours every Tuesday and Thursday afternoon. The stated subject of the meetings: Review of costs and
business operations, formulation of a plan to recover IVK growth trajectory.
Different departments, the message explained, would take the lead in
each meeting. IT had been assigned Tuesday, April 17. This gave
Barton some time to get his act together. Hed need, the message told
him, answers to a few key questions: How much are we spending in
your area? and How does the spending fuel growth or contribute to
the bottom line (and how are we measuring this)? Barton had expected
the messageand these questions. It was exactly how he would have
begun if he were the new CEO.
In anticipation of just these questions, Barton had planned to spend
the afternoon with Gary Geisler, the IT departments fi nancial guru.
Despite his modest rank (the most junior manager level at IVK),
Geislers importance was clear from the location of his offi ce. Other
managers at his level worked in cubicles in the open offi ce area, but
Geisler had a private offi ce right next to the CIOs (empty since
The Road of Trials
58
Daviess departureBarton had not moved into that space yet, and
wasnt sure that he would). Geisler reported directly to the CIO; unlike
the other CIO direct reports, however, no one reported to Geisler.
Barton didnt know Geisler well, but had been present in meetings
when Davies had turned to the fi nancial wizard for explanations. Barton read the guy as a bit of a know-it-all; everything he said seemed to
be accompanied by a silent of course, as though no one should or
possibly could contradict him. Barton didnt relish the thought of
dealing with him, but he was looking forward to diving into the numbers, to get a management handle on how things were going in the IT
department.
Right on schedule, Geisler stepped into Bartons offi ce and scanned
the unfamiliar space for an appropriate seat. Gesturing to the chair opposite his desk, Barton started their conversation simply: So, Mr.
Geisler. How much are we spending on IT?
Bartons question was the last simple thing to happen in the meeting. What do you mean by we? challenged Geisler.
Barton laughed, then realized that Geisler was not joking. He tried
again: How much does IVK spend on IT?
Ah, said Geisler, that we. It depends on how you count.
Why, said Barton, impatience rising, does it depend on how you
count? Its a simple question.
Well, as you know, the IT department formally controls none of the
budget that gets spent on IT. The business units get budget allocated to
them for IT expenditures, then we charge them for our services, using
an internal pricing system.
In some cases, they are also free to use their IT budget to obtain
services from external providers, although there have been limits placed
on that in the past, to make sure that we offset all of the fi xed costs associated with IT salaries and infrastructure. Basically, as long as our IT
staff remains fully billed out to business units, the business units can
also choose to go outside for services.
In addition, there are IT-like services, such as the service and
support for mobile devices provided by external companies that the
individual departments have procured on their own, some using nonIT budget. Your predecessor, Bill Davies, thought he ought to have
The Cost of IT
59
some infl uence over those services, but he wasnt sure how to go about
reining in the business units. IVK has no standard. Each unit has a preferred mobile technology, and some units have multiple technologies
even within the unit. Theyve been dealing directly with the vendor. Of
course, the fact that the services are not provided by IT and dont use IT
budget doesnt stop the business units from seeking support from
IT when theres a problem with these devices.
Okay, said Barton, processing this rapid-fi re explanation. He was
thinking about Loan Operations, realizing that his former group was
one of those that had multiple mobile technologies, each from a different vendor. That hadnt seemed like a big deal when he was in charge of
Loan Ops. Hed given it little or no thought. But now, from his perspective as CIO, it seemed crazy. He would be held responsible for maintaining mobile services to the business units, just as he had held Davies
responsible for it. On the current path, as more people relied on mobile
devices, the IT group would have less and less control over the quality
of service to those devices. An outage at a service provider could shut
down mobile services as easilyeven more easilythan a problem internal to IVK. And no matter what the cause of the outage, ITand its
new leaderwould be on the hook for it. Crazy , Barton mused, again,
to himself. Why had Davies allowed this situation to persist? Because to
change it, hed have had to confront guys like me, when I was in Loan Ops ,
he thought, answering his own question.
Anyway, I assume youd ultimately like to include all of that IT
spending from non-IT budgets when you ask for a total spent on IT,
said Geisler, returning to the original question. We can always break
things out into categories if thats helpful.
Barton nodded. He would, later, want things in categories, but he
was still trying to understand the basics: So give me a number, any one
of those numbers, said Barton. What ballpark are we talking about?
Geisler removed a sheet of paper from the fi le folder hed been
clutching and handed it to Barton.* Without the money being spent
on IT services thats not from the IT budgetin other words, not including those mobile services and the like that arent acquired using IT
*See Projected IT Budget Fiscal Year X at the end of this chapter.
The Road of Trials
60
budgetthats the number I have here at handwe spent just over $29
million on IT last year on a cash fl ow basis, about $18.5 million on an
accrual basis.
Barton did a quick mental calculation. About 8 percent of sales.
Yes, although historically we have run lower than that. As you know,
weve had trouble lately with revenue growth leveling off. The former
rapid growth rate was causing us to spend more on IT each year to provide new services and the same old services to more and more customers. But we were always playing catch-up. Our spending lagged demand
for services, and we were scrambling to add service capacity.
When the growth rate leveled off, continued Geisler, IT spending
on a catch-up trajectory couldnt level off as fast. Davies was working
on ways of slowing down spending whenwell, you know what happened to him. Its not going to be easy to bring costs back down. The
percentage will probably go up before it goes down. Were not caught
up in terms of modernization of the IT infrastructure. Others are more
expert on this than I am, but I think we are in the middle of some major
projects that wont be easy to throttle back.
Historically, Id say weve run closer to 5 to 6 percent of sales on IT
spending. Which, by the way, Davies thought wasnt enough to keep IT
assets from degrading over time, in terms of general robustness.
Hmm, said Barton. So the IT department has no budget of its
own?
Thats right. We are essentially a service provider to the business
units. Some hours we directly bill to them via the chargeback system;
others, like expenditures on shared infrastructure, we charge out as
general overhead, also within the chargeback system. We ultimately
charge all of our costs back to the business units.
Barton remembered being puzzled by a largish item called IT and
telecom services on his Loan Ops monthly budget reports. Hed paid
little attention to it because his actions didnt seem to infl uence it. It
went up a bit when he started major projects, but mostly it seemed not
to change over time.
The overhead component is pretty big, right? Barton asked. I
dont recall having a lot of control over the amount I was charged for IT
services when I was in Loan Operations.
The Cost of IT
61
Thats right. It varies by department, but Id say most departments
overhead chargebacks are between 70 and 80 percent of their total
amount. I can fi nd out the exact number for Loan Operations if you
like . . . He began leafi ng through the pages of an imposingly thick
black binder.
No, never mind, said Barton. Tell me more about the chargeback
system. How does it work?
The direct billing part is just straight billing for hours
I get that
but the overhead calculation is pretty complicated. Its a
formula.
Where did the formula come from?
It came to IVK with CFO Mark Lundy, who isnt here anymore . . .
Yes, I remember him, Barton said. Lundy had come to IVK from the
fi nancing division of an established manufacturing company. He hadnt
stayed with IVK long. The theory in hiring him, Barton recalled, had
been something about IVK needing someone who could bring more
systems and controls to the company. But Lundy never had been a good
fi t; the fast-growing companys immune system had rejected him.
In the original version of the chargeback system, continued Geisler,
we just added up all of the overhead costs and allocated them to departments equally, based on the number of telephones in use in that
department. In that system, the only way you could, as a business unit
manager, reduce the biggest portion of your IT chargeback was to take
a telephone away from someone.
Telephones?
Yes, it was an imperfect system to say the least. But that was the way
they had done it at Lundys old company.
But we dont do it that way anymore.
No. Weve gotten much more sophisticated in recent years. The formula now includes things like number of e-mail accounts, number of
accounts on various other systems, average number of concurrent users
per business unit logged on to various systems at any point in time during the workday, number of new records generated in various databases
per day, and so on. Its a much closer approximation to charging back
the real cost of resource used.
The Road of Trials
62
Barton felt a little dizzy. He considered asking Geisler to walk him
through the details of the formula, but decided against it. Where did
the new formula come from? he asked. He was imagining some sort of
a committee commissioned to come up with such a formula, itself an
awkward compromise between business units. It would have been brutal, not a committee Barton would ever want to serve on, nor had he
ever heard of such committee at IVK. But, as it turned out, a committee
was not the source of the new formula. Geisler explained the formulas
origins with a broad smile and a single word:
Me.
You?
Yes. Ive been working on it and adjusting it every year for the last
several. I feel that its really getting good now.
Barton shook his head. Anybody else involved in determining this
formula?
Geisler became uncomfortable. Uh, no.
Anybody else know and understand the formula?
Geisler thought, then answered: Probably not, actually. Of course,
Ive designed the formula to represent economic reality, within the limitations of our ability to measure usage of IT services.
Barton made a snap decision not to fi ght the battle of where the formula came from right now. It didnt seem to be on anybody elses radar,
and it probably made more sense as Geislers invention than it would
have if it had been the result of committee work.
Im going to need a one-page summary, said Barton, that gives me
the total cost number, including IT spending from non-IT budgets,
broken out into major categories, and that explains in terms as simple
as possible how those costs are being charged back to the business units.
The formula, in other words. If he could get his peers to understand
the formulaif he could understand it himselfthen maybe later he
could get them involved in checking and changing it. Sound doable?
asked Barton.
Yes, it does. When will you need it?
When can you have it? responded Barton.
The Cost of IT
63
Thursday, March 29, 4:25 PM . . .
Barton stared at his whiteboard, trying to fi gure out what he ought to
include there about IT costs. Hed spent all afternoon either talking
with Geisler or studying his cost numbers, but there were still huge
gaps in what Barton understood.
He rose from his chair, walked to the whiteboard and wrote three
things in a rough triangle: IT costs, IT services and chargeback. He
drew an arrow from IT costs to IT services then wrote mapping?
above the arrow. Then he drew an arrow from IT services to chargeback and another from chargeback to IT costs.
KWYDK
YWLOY
IT management is about management
Skill and talent mgmt/key skills, key contributors
mapping?
IT costs
chargeback IT services
He assumed that if his department could make that mapping accurate and explicit enoughso that costs could be assigned clearly to services, and departments could be charged for the services they used in a
way that made sense to themthis would be a good thing. But the earlier session with Geisler had demonstrated just how complex the mapping could be. Recalling Geislers explanation of the Byzantine structure
of the evolved chargeback system still made Bartons head swim.
A mapping too complex for managers to understand would be a
poor input into decision making. Really, it would be a useless, needless
complexity to manage. But Barton had no idea whether it had to be
that way, or whether there might be a way of abstracting usefully to
provide a business description of the mapping that was neither misleading nor too complex. Barton knew he suffered from huge gaps in
The Road of Trials
64
his own understanding of what the IT budget paid for. He could read
the names of projects in the budget documents provided by Geisler, but
he didnt, he now realized, understand what the projects were acting on
or adding to. He had no sense of the accumulated IT assets of IVKthe
systems, software, databases, hardware, and whatever else.
Barton wrote a large ? in the middle of the triangle hed just drawn,
then for the second time that day wandered down the hall to talk with
Bernie Ruben.
Me again, said Barton.
Sure, sure, come in, said Ruben. Barton sat down and explained his
problem.
Well, said Ruben, let me see if I can help some. Let me tell you a
story about the evolution of IT applications and infrastructure at IVK.
To some extent, this is a general description. Most companies evolve
their IT assets in a way much like this.
Ruben rose, moved to his own whiteboard, erased a big part of it,
and began to draw a picture.*
When we were a small company, back in the early days, we put together IT systems when we needed them for specifi c business reasons,
without much of a sense of an overall systems portfolio or underlying
infrastructure. We didnt have much going on in IT relative to today, so
that was just fi ne for that time and for that scale of operations. Most of
our IT spending was on applications related to creating specifi c IT
functionality in support of the business. The ability to originate a loan,
to input loan request information, to process a loan decision, that kind
of thing.
This company was lucky to have been founded at a time when webbased technology was becoming important. Because of that we dont
have huge investments, as many other companies do, in older technology. Nevertheless, a few of our important operational systems do run
on old, legacy technologies. In a few places, weve taken an if it aint
broke, dont fi x it approach, though eventually well need to update
things, to support real-time analytics. We used a lot of e-mail from the
*See Rubens Explanation of the Evolution of IVKs Applications Portfolio and
Infrastructure at the end of this chapter.
The Cost of IT
65
beginning, and quickly jumped on using e-mail as a way of moving
information, which gave us, even in the early days, a sort of workfl ow
system for moving fi les around.
Then, said Barton, trying to move the story forward faster, we
started to grow.
Oh, yes, said Ruben, did we ever. We grew, as you know and remember, quickly. As our IT operations gained scale, it made sense to invest in
infrastructurecommon services that everyone could use. A robust
database technology, security systems common to all our applications,
and a big chunk in the middle to manage interactions between different
systems. We brought payroll in-house and acquired solid and robust
systems for managing our call center operations. As we did all this, the
distribution of IT spend shifted. We spent more on infrastructure, which
meant less, as a percentage, on new responses to business needs, new
applicationsthe only thing wed spent on in the beginning.
That doesnt seem like an entirely good thing, said Barton.
Ruben paused. How do you mean?
Well, it looks like spending more money on maintaining, less on
new ways of providing services to the business. The trend looks ominous. Does it mean eventually well spend all our money just on keeping our current functionality running and robust? Are we losing
capacity over time to add new ways of competing using IT?
Excellent point. To some extent, this shift of percent spend from
applications to infrastructure is inevitable as we mature our approach
to managing the increasing complexity of our systems, as we accumulate IT assets that need to be cared for. But you rightly point out that at
some point, our management attention should shift to trying to spend
less, as a percentage, on maintaining and more on adding new functionality and services.
Whats the right long-term percent spend for each? asked Barton.
I dont think theres any right answer to that, said Ruben. I guess
in the long run youd like to spend as little as possible on maintaining
and as much as possible on new ways of providing services and using
IT to compete. But realistically, Id say its going to be tough. It costs a
lot to run a large operation, just to keep it up. And Im reluctant to get
into too much self-fl agellation over a spend that goes mostly to
The Road of Trials
66
infrastructure. It seems like just another club you could hand business
managers that they could use to beat us with.
I appreciate your candor, and I see your point. Even as the business
manager lingering within me longs to grab that club and use it to beat
someone up.
Ruben laughed out loud. But it changes things when youre likely
on the receiving end of the beating, doesnt it?
It does indeed. So now weve got this very interesting question of
how to divide IT spend over these two categories in the future. But I
still dont have a good sense of what well be spending on. Where are we
heading with our IT assets?
Ruben fi nished his picture with a future diagram. Id say we are
moving from supporting a hierarchical, traditional organizational
structure to an increasingly networked organization that includes partners, such as customers and vendors. Technology-wise, we are moving
more toward service-oriented architectures with more services provided from off premises, by vendor partners; more real-time operations; and database structures to support data analysis capabilities, so
that we can mine for customer trends and other important patterns
and hopefully make better business predictions and decisions based on
data.
Those sound like major changes.
They are. To a large extent, it means investing in infrastructure
that, if we get it right, will improve our ability to create new functionality and services that support business objectives. It might eventually
allow us to shift some infrastructure spend to applications, and to get
more functionality out of applications for less spendalso to deliver
new functionality faster, which might be even more important. The
challenge will be that some of this is about getting into position to be
better, so it will sometimes be diffi cult to draw a direct line between
investment and a specifi c improved business outcome. That makes it
harder to explain investments to our business colleagues: Positioning
ourselves for a better, more fl exible future is a bit nebulous as a justifi –
cation for spending scarce resources.
The Cost of IT
67
They ought to see benefi t in better data analysis capabilities. I did,
when I was heading Loan Ops. This is a data analysis sort of business,
analyzing loan risk, that kind of thing.
Youre right, many do understand that. But well still need to get the
technology right. Business analytical capabilities are one of those areas
where hype has probably outpaced reality. There are plenty of great
things possible, but well have to be careful, and smart, with our investments. And all of usincluding our business partnerswill need to be
smart enough to see and make effective use of the results of analysis.
You mean they wont do our jobs for us, these computers?
Afraid not, said Ruben, grinning. Despite all the sci-fi , robotscoming-for-our-jobs stuff, I suspect it will be awhile before IT systems
in companies eliminate the need for good managers.
Good news for us, I guess, said Barton.
I guess, repeated Ruben.
Barton wasnt sure he could map costs to the picture Ruben had
drawn, but he had undoubtedly picked up valuable new insight from
their discussion. It was growing late. Tomorrow would be another day
in his young CIO career.
REFLECTION
Are IT applications an asset or an expense?
What is the main purpose of allocating IT costs to user departments?
What is an appropriate percentage of the IT budget to spend on maintenance?
As a percentage of sales, how much should a company spend on IT?
The Road of Trials
68
Projected IT Budget Fiscal Year X
latipaC X YF
Capital budget purchases
empoleveD tn 000,231$
ikrowten/erutcurtsarfnI gn 008,972$
erawdraH 004,006,1$
erawtfoS 000,659$
totbuS la 002,869,2$
Disaster recovery/ business continuity/ second site costs
troppus PI dna hctiws enohpeleT 005,841,1$
snecil noitacilppA se 054,184$
olonhcet noitatskroW yg 708,899$
erawdrah-sllawerfi/gnituor/gnikrowteN 005,826,1$
Servers (fax, Web, e-mail, database, application process, office
nemeganam )t 000,325$
Other IT infrastructure expenditures (i.e., UP S, racks, spec.
).cte ,gnilbac 008,066$
totbuS la 750,144,5$
Future P roposed Initiatives
Security, compliance, customer service software $ 889,760
Security, compliance, customer service eq uipment $ 500,000
empiuqe tcejorp gne-eR tn 000,573$
erawtfos tcejorp gne-eR 008,8$
empiuqe erutcurtsarfni nommoC tn 000,053,2$
erawtfos erutcurtsarfni nommoC 000,538,1$
oitallatsni dna erawtfos( scitylana ssenisuB )n 000,24$
Budgeting and systems for Finance (software and installation) $ 220,000
nempiuqe( tcejorP PLQ )t 009,292$
Q LP P roject (software and development services) $ 1,470,000
totbuS la 064,389,7$
X YF ,tsoc latipac TI elbazitroma latoT 717,293,61$
The Cost of IT
69
sesnepxE X YF
N etwork operations
snoitarepo dna krowteN 000,782$
troppus lanretnI 000,084$
ireenignE gn 008,366$
iruces krowteN yt 000,495$
iruces noitamrofnI yt 000,052$
erutcurtsarfni dna ygolonhcetevitartsinimdA 000,546$
snoitcejorp dna gninnalP 005,6$
erutcurtsarfni dna ygolonhceT 005,21$
smetsysgnireenignE 000,206$
ikrowtengnireenignE gn 000,765$
smroftalpgnireenignE 002,2$
totbuS la 000,011,4$
A pplications and development
itartsinimdA ev 000,484$
snoitacilppA 004,359$
AQ dna sisylana ssenisuB 005,606$
empoleveD tn 000,218$
smetsys noitatneserP 003,795$
emeganam esabataD tn 000,458$
eetnaraug dna gnidneL 006,637$
PRE dna ecivres remotsuC 000,363$
sisylana smetsyS 000,811$
emeganam tcejorP tn 000,942$
ised erutcetihcrA ng 000,437$
smetsys erawelddiM 005,203,1$
sinimdA ecnailpmoc dna tnemnorivneevitart 006,7$
ecnailpmoc evitartsinimda dna tnempoleveD 005,363$
emeganam tnemnorivnE tn 000,023$
ecnarussa ytilauQ 000,87$
smetsys ecfifo-kcaB 000,321$
totbuS la 004,207,8$
)sisab wofl hsac( esnepxe TI latot dnarG 711,502,92$
aey suoiverp dna X raeY morf noitazitromA sr 478,217,5$
)sisab laurcca( esnepxe TI latot dnarG 472,525,81$
Total project IT expenses FY X $ 12,812,400
The Road of Trials
70
Rubens Explanation of the Evolution of IVKs
Applications Portfolio and Infrastructure
1960
Accumulated IT investment/assets
Network
era
Micro
era
Data
processing
era
Future
Batch loan operations
N on-internet e-mail for
loan origination and
customer service
Call center
Outsourced payroll
IVK future
Batch loan operations
Legacy and duplicate copies
for customers
Website and internet e-mail
for loan origination and
customer service
Call center customer service
Vendor-managed payroll
and HR
Robust database
Real-time loan operations
Service-based loan
origination and customer
service
Call center customer service
Cloud-based payroll and HR
A / P = ? %
of IT invest
Infrastructure =
? % IT invest
Service-based
architecture
Data analytics
Real-time operations
A / P = 40%
of IT invest
Infrastructure =
60% IT invest
IVK now
A / P = 90%
of IT invest
IVK founding
Infrastructure =
10% IT invest
71
chapter five
The Value of IT
Thursday, April 5, 9:30 AM . . .
Barton studied the one-page summary that Geisler had sent him the
night before. It was the third version hed seen; this one was looking
good. He was feeling increasingly confi dent in his ability to answer
questions about the cost of IT. But a big hole remained in his thinking
around the question of how much value IVK obtained from IT. In the
early meetings of the leadership team, business units were providing
either growth or profi tability numbers for their specifi c areas to answer
their own value questions. IT differed from these areas, though, because it was not a profi t center, at least not within IVK. Unlike, say,
Loan Operations, IT didnt bring in revenues from external sources, so
it could not point to growth in revenues or profi tability in terms of revenues less costs. His obligation, it seemed to Barton, was to have something to say about how IT created value for its internal customers, the
business units. But he wasnt sure how to come up with that. He was
even less sure how to measure that kind of benefi t. Geisler didnt offer
much help; hed never been asked this question before.
In requesting work from IT, to justify IT projects, business units routinely projected benefi ts from each project, but no one ever checked
after the fact to see that those benefi ts had been realized. One option
for coming up with a value number would be to simply go back through
the portfolio of approved and completed projects and add up the dollar
The Road of Trials
72
value of the benefi ts claimed in their proposals. Barton wanted to have
that number, but he wasnt sure it would be credible with his executive
peers. Business units tended to claim that huge savings would result
from anything they wanted to do in order to get the project approved,
but everyone knew this was a game. Besides that, some business units
might claim these savings as their own. If IT claimed them too, that
would be double counting. If a business unit proposed an IT-enabled
change and the change did result in savings, how should credit for those
savings be allocated between the business unit and IT? Often the savings would have been impossible without IT, but it would be a hard sell
to allocate all, or even some portion, of the value to IT.
Barton took a chance that Maggie might be available to discuss this
and gave her a call. She answered and, as expected, had interesting
thoughts on the matter.
She pointed him fi rst to a classic historical example of a company
using IT to provide big value. In the mid 2000s, Zara, a clothing retailer
based in Spain, had spent only 0.5 percent of its revenues on IT and
employed a similar percentage of its staff in the IT department. 1 But
the way Zara used ITto allow it to read demand signals for certain
products at the point of sale and then to fulfi ll new orders for hot items
less than three weeks latercreated a capability that its competitors
could not match in those days. The capability led directly to higher
profi ts, because hot items were stocked faster for customers to buy, and
fewer unpopular itemswhich only ended up being sold later at a
steep discountwere produced.
Maggie also suggested he read a controversial Harvard Business Review article IT Doesnt Matter. She hesitated to call it a classic, she
said, because she thought its conclusions were fl awed. But it did raise
interesting issues. The author, Nicholas Carr, had used historical analogies to suggest that IT had become such a commodity that investments
in IT could not be counted on to provide capabilities that were not also
accessible to competitors. 2
Doesnt the Zara example directly contradict that? asked Barton.
Yes, said Maggie, I think it does. So do a lot of other examples. Its
quite common to see companies in the same industry, with similar levels of investment in IT, getting vastly different amounts of value out of
The Value of IT
73
their investments. Thats what I think Carr gets wrong. When hes been
pressed on that point, he usually concedes it, but says its not the IT
thats causing the competitive differentiation, but the way IT is used
and the success with which it is adapted within the company culture.
So, yeahduhbut when is IT ever acquired without people having to
fi gure out how best to use and introduce it? I guess you could say that
Carrs arguments apply to, say, word-processing softwareI dont
know any company that achieves sustainable advantage over its rivals
via its word-processing capabilitybut a lot of IT is not like that. And
thats hardly big news. The problem with that article has always been,
really, that its either wrong or old news. It made a big splash because a
lot of CEOs didnt read past the title.
But these kinds of debates do make it clear that value from IT can
arise from its ability to confer on a fi rm some capability that separates
it from its rivals.
Yes, thats the way to think about it, said Maggie.
She also pointed him to a series of research articles by an MIT professor, Erik Brynjolfsson, which seemed to prove that fi rms achieved value
from IT in a variety of different ways. 3 Maggie suggested that Harvard
Business Review probably should have gone to Brynjolfsson, a careful
thinker whod been studying the question of IT value for years, rather
than Carr, if they wanted the real scoop on whether IT mattered.
Brynjolfssons research seems to say that fi rms that have invested
heavily in IT deploy new business processes more quickly. If all the
fi rms in a particular industry have similarly invested, then this would
suggest that the value IT provides might be fl eetingone fi rm deploys
a new process idea, then the others are able to quickly copy it. This
shows up in their data as a lot of sales turbulence in industries with
high IT investment, as fi rms implement new process ideas quickly and
others quickly copy the ideas. But the study also shows that fi rms that
have invested a lot in IT have increased market share a good bit, and
that these dynamics affect fi rms primarily in industries with a generally
high level of IT investment.
The punch line seems to be that IT does matter; industries with a lot
of IT behave very differently, competitively speaking, than industries
with less IT. IT investments allow some fi rms to consolidate market
The Road of Trials
74
share and assume a more dominant position in an industry. But the
benefi ts from specifi c IT investment in high-IT-investment industries
can be fl eeting, as the services they provide more rapidly become commodities thanks to past investment in IT. Overall, the competitive trend
for successful IT investors in IT-intensive industries is upward, even
though there is greater volatilitywider swings, in the short run, above
and below the trend. Brynjolfssons also showed that companies that
get more value from IT tend to adopt a certain set of complementary
management practices. 4
How does this help me when I think about IVK?
Maybe not a lot directly. But in general you can think about how
quickly your competitors have been able to match your IT-enabled new
capabilities, the ones that translate into growth and profi t. The most
value would come from investments in IT that give you an edge that
your competitors cant copy. Sorry, Jim, Ive got to run. Weve got a
meeting starting here in a few minutes.
No problem. Youve helped a lot. You defi nitely earned your fee, Ms.
Landis. I guess Im taking you somewhere fancy tonight.
If Id known I was on the clock, Id have talked slower, joked Maggie. We still havent gotten you to an answer yet, though, have we?
No, he conceded. But were making progress.
Friday, April 6, 4:20 PM . . .
As the weekend rapidly approached, Bartons musings about IT value
fi nally sent him down the hall to consult once again with resident philosopher Bernie Ruben.
Not catching you as youre leaving early for a big weekend, I hope,
said Barton.
Not at all. Come in, said Ruben. As usual, all the seats in the room
were covered with piles of paper. By now Barton knew the drill; he simply moved a stack of paper to the fl oor and sat.
Wont take long, I think, said Barton.
Whats on your mind? asked Ruben.
Barton explained, giving him an overview of the progress of his
thoughts on the issue of IT value.
The Value of IT
75
Carl is going to want to know our answer to this question, said
Barton, and hes going to want to hear our ideas about how to measure
IT value.
Ruben didnt answer right away. He put his feet up on the desk and
stared at the ceiling.
Its a hard question, he allowed. I dont really have an answer, but I
do have some thoughts.
Shoot, said Barton. Im just looking for a nudge in a productive
direction.
There are several things that complicate the matter, said Ruben.
Sometimes when we invest in an IT project, we do it without any expectation that it will give us an edge over the competition. Sometimes
we do it because we have to if we want to stay in business. Maybe new
legislation requires it. Or maybe if we dont do it, our competitors will
obtain an unreasonable edge on us. Sometimes we invest in IT just because our competitors are doing it, to avoid what you might call strategic jeopardy, a situation where they gain an important advantage on
us. We dont get an edge from IT expenditures in this category, but its a
necessary cost in our business. In a way, youd say this is very valuable
because we might not have a business at all without it. But because everybody also has it, we cant say it provides competitive advantage.
A very important point, said Barton, which I can certainly present
as a plausible argument. Though, in a way, it dodges the question of
measurable value.
Ruben nodded. It doesnt seem right to say that theres zero value
from those expenditures. But by some arguments, these investments
are likely to provide zero competitive advantage.
Barton described the IT Doesnt Matter argument briefl y, as well
as the Zara case. Ruben was already familiar with both.
Yes, Carr would say we get no competitive advantage from commodity IT areas. Hed recommend that we supply IT services in this
category at minimum cost. Actually, Im giving him too much credit.
He says all of IT should be run this way. His argument is that you cant
get any competitive edge from commodity IT, so just do what you
must at minimum cost and risk.
What about the Zara example? said Barton. Suppose we can point
to sustainable advantage from IT?
The Road of Trials
76
I suppose then we could compare what our competitors are able to
do with what we canor maybe how much of it we would be able to do
without the IT, hypothetically, with what we are able to do with it.
So maybe, suggested Barton, fl oating an idea hed been mulling
over, we ask the business units what allows them to win deals or what
helps them become more profi table or gain market share. A survey, or
interviews maybe. Then we can look at the role IT plays in that.
Youve still got the problem of teasing apart what IT can claim and
what the business unit will want to claim of that value. But there ought
to be no doubt that IT has played an important role in those instances.
Its even more complicated than that. Sometimes our investments
demonstrate clear value: ROI, cost savings, ormore rarelyincreased
sales. But other times we invest just to position ourselves for higher
ROI investments in the future. If we calculated the ROI from our initial
ERP* implementation, for exampleif we did it honestly, I mean
wed fi nd that the damn thing didnt really pay for itself, at least not by
itself. But it eventually allowed us to build systems on top of it that really earned big returns. In that case, if youd tried to calculate ROI too
early, before those other systems built on top of it were fi nished, youd
have considered it a lousy investment. Eventually, though, many of
these investments resulted in huge successes and returns.
And, said Barton, if were going to be consistent with our past
logic, it also depends on whether our competitors have also invested in
ERP systems, and whether theyve successfully built the same kind of
systems on top of their ERP systems. If they have, then weve gotten no
competitive edge from any of it. But of course if we didnt invest, we
might well have risked strategic jeopardy.
I agree with that in principle, said Ruben, but in fact I dont think
our competitors have equaled the capabilities we get from those investments. We have an edge, and our competitors either havent or cant
match it. Not all of it, anyway. Not yet.
*ERP (enterprise resource planning)a popular integrated set of software applications
automating order-entry through manufacturing, shipment, billing, and receiving
payment transferred into cash.
The Value of IT
77
So if we hired consultants, or asked our business units what we are
better at than our competitors and maybe how fast they are catching up
or falling behind, that would help us get some rough idea of value,
some of which might be attributable to IT.
Ruben nodded. Reminds me of a categorization scheme that might
be useful. You can usefully distinguish, not just in IT but in other areas
too, between investments that are merely Qualifi ers and investments
that help you Compete. Call it Competes versus Qualifi ers. A Qualifi er investment keeps you in business. You have to qualify to run in
the race, but Qualifi ers only buy you a place at the starting line. A
Compete investment gives you a potential edge over other companies
in your industry. Competes help you win the race. We could go
through our portfolio of active systems and ask which are primarily in
each of these categories. Itd be interesting to know how much of the
IT budget we spend on Qualifi ers versus how much we spend on
Competes. 5
And we could try to affect the distribution of expenditures across
those categories over time, said Barton. What do you think the distribution is now? Seat-of-the-pants estimate, percentage-wise, how do
you think it breaks out?
Ruben laughed. We might be horrifi ed. If the way we are thinking is
correct, systems that have been in the Compete category move into the
Qualifi er category as competitors manage to copy us. So, over time, the
Compete category gets smaller, the Qualifi er category larger. Unless, I
suppose, we add new Competes faster than the old ones become
Qualifi ers.
But as Competes become Qualifi ers, we ought to change our philosophy of how to manage them. We ought to shift into cost minimization mode. If we can reduce costs for running Qualifi ers, then even if
their numbers increase, we might be able to reduce our total spend on
them.
Thats a rosy vision, said Ruben, but it sounds hard to do. Reminds me too of another, related, categorization scheme: McFarlans
Strategic Grid. 6 Ruben stood, walked to his whiteboard and drew a
2 2 grid.
The Road of Trials
78
Factory
High
L wo iH hg
Strategic
Turnaround
Strategic impactApplications
development portfolio
Strategic
dependence
Existing
operating
systems Support
As I remember it, said Ruben, the vertical axis is about how operationally dependent a company is on IT. McFarlan called this Strategic
Dependence. The horizontal is about how much competitive differentiation the company obtains from IT. McFarlan called that Strategic
Impact. If you are in the bottom left corner, you dont depend much
on IT operationally and you dont get much advantage from it, strategically. Systems have to go down for a while before you are badly hurt,
and you dont get much edge over your competitors from these systems, though they might be essential to have in your industry. If you are
in the upper right quadrant, you are very operationally dependent and
you get a lot of competitive advantage. Were defi nitely operationally
dependent. If the major systems in Rajs area failed, youd be getting
calls within thirty seconds. Competitive advantage from IT shows up
on the horizontal axis. Rather than just separating systems in our portfolio into Compete and Qualifi er categories, maybe we should also see
how they fall out into these quadrants, and how we should think differently about them in terms of cost and value.
I like the idea of taking a run through our portfolio of existing systems with these kinds of categories in mind. Any chance youd be willing to take the lead on this? Ill get Geisler to help. Also, Im meeting
with some consultants next week, mostly on some organizational development stuff, but I think they might have people who can help us
with this IT value question. Id like you in on the OD stuff anyway. We
need to hold an all-hands IT meeting; Id like a chance to introduce
myself to the department now that Im the new boss, and I want people
to have a chance to ask questions, offer feedback. Id like you involved
in the planning.
The Value of IT
79
Thatd be very interesting. All of it. Should I ask Jenny about day
and time of the meeting?
Thatd be great. I cant remember.
Ill do that and get with Geisler to prepare for the value discussion.
First thing Monday morning.
On hearing this, Barton remembered that it was late Friday afternoon. As usual, his date with Maggie would begin quite late in the evening, but Ruben might be keeping to an earlier schedule. Barton stood.
Thanks, Bernie.
Always glad to help, Jim.
Friday, April 6, 5:12 PM . . .
Barton returned to his offi ce encouraged by the insights Bernies grid
had given him, but still feeling unsettled. The route to determining
value from IT investments seemed so elusive. Each path he followed in
his thoughts moved him deeper into a tangled forest of issues. He
needed a new perspective, a view from above the trees. Maybe from a
different, higher vantage he could see a way forward.
If IVK is the forest , thought Barton, perhaps I should start with the
value of IVK. Then at least I can establish an upper bound of the value of
IT and begin a more constructive conversation .
Although he knew it to be a controversial measure, one estimate of a
companys value is the price at which investors are willing to buy its common stock. He went online and obtained IVKs closing stock price for the
day: $30.72. He then grabbed last years annual report, turned to the balance sheet page, and found that there were about 63.5 million IVK common shares held by investors. A simple multiplication of share price and
shares outstanding gave IVK an estimated market value of about
$1.95 billion. Barton wrote these numbers along the bottom of his whiteboard. He placed a ? after IT value to remind him of the question:
How much did IT contribute to this $1.95 billion market value?
The fl ip side of this question was also important: How much did IT
diminish this market value? If well-managed IT contributed to a companys market value, poorly managed IT might just as well hurt market
The Road of Trials
80
value. Barton remembered celebrating the moment in August, year
before last, when IVKs stock price passed $75, giving IVK a market
value of almost $4.8 billion. Just one and a half years later, after investors reassessed the companys value following a disappointing fi nancial
result, IVK had lost more than half of its market value. What role did IT
play in that loss?
He added a +/ next to the question mark. To capture more of the
value issue, he added C vs. Q as a reminder of Rubens Competes
versus Qualifi ers model and, from their previous conversation, he
drew the 40 percent new applications on top of the 60 percent infrastructure that refl ected the current distribution of IT spending at IVK.
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4
$75.12 $30.72
4.77B 1.95B

Barton still hadnt found a way through the forest, but he felt better
going into the weekend with some thoughts concretely illustrated on
his whiteboard. Perhaps the next week would yield insight. He was,
after all, still rather new to all this.
The Value of IT
81
Tuesday, April 10, 11:54 AM . . .
Returning from a meeting, Barton immediately noticed the two thin
fi le folders that had appeared in his inbox.
These just arrived from the CEOs offi ce, said his assistant. Barton
nodded, took them, and went into his offi ce.
After his debacle with $1,200 worth of computer books, Barton had
begun to wonder how Davies operated. How much of that stuff did he
get? How much of a tech expert had he been, and how did he use that
expertise as a manager? What did his employees think of him? How did
they interact with him? Did they consider him an expert? It would be
useful to know these things, because whatever Davies had done had
gotten him fi red.
After contemplating his experience with self-education, Barton had
launched his own personal project called Understand What Got Davies Fired. Hed written it in parentheses on his whiteboard, in coded
block letters (UWGDF), just as he had written KWYDK and
YWLOY.
To begin the project, hed called Carl Williamss assistant and asked
whether there was anything in the fi les inherited from Kyle Crawford,
the previous CEO, about IT. He explained it in terms of trying to maintain continuity of the IT function, but he was really hoping he might
get some personnel evaluation fi les on Davies. A long shotpersonnel
fi les were usually protectedbut worth it if he did get something that
helped him understand how Crawford saw Davies and judged his
performance.
As he glanced quickly through the two fi les, he realized that he had
hit the jackpot with one of them. It contained a confi dential report to
Crawford from consultantstheir assessment of the job Davies was
doing as CIO.* It said a lot that Crawford had relied on expert outsiders
for this assessment. But the report itself said even more.
The report characterized IT leadership in terms of three levels of
maturity, from Type 1 to 3, Type 3 being most mature. According to
this report, Type 1 leadership was about functional requirements and
*See Excerpts from the IT Leadership Consulting Report at the end of this chapter.
The Road of Trials
82
individual systems; the focus was operational. Type 2 was less about
managing individual projects and systems, more about managing
portfolios of projects and infrastructures, as well as playing a senior
team leadership role; Type 2 leaders left the details of managing operational functions and individual systems to others, though they remained accountable for it all working. Type 3 evolved into a job of
managing strategy and resources, leaving the details of management of
portfolios and infrastructure to others.
The consultants rated Davies a Type 1 manager, struggling with
transition to Type 2. They recommended sticking with Davies to see if
he could make the transition to the next level, and then to the next
levelType 3. They warned that it would not be easy simply to replace
him; it would take a long time for a new person to become effective
as CIO.
Barton thought he might come up to speed a bit faster than their
projection; he was not new to the company, just new to IT. But the
warning sobered him. What Type manager was he? As the new CEO,
Carl Williams gave no evidence that he was asking that question or
even thinking in those terms. On the other hand, Williams and the
board had been involved in the new CIO selection. Maybe he, Barton,
had been selected as a direct result of the board thinking about these
different types of managers. The report noted that Davies seemed to be
respected by his IT staff, but had a big problem interacting with peers
and those to whom he reported. He had a tendency, according to the
consultants, to pull back into the confi nes of his familiar IT world when
faced with diffi culty, especially confl ict with an executive from the business side. The consultants hoped he could overcome this tendency with
suffi cient executive coaching and counseling help.
Barton thought to himself, while reading the report, that it would
make a lot of sense to make contact with Davies, to buy him lunch. If
nothing else, the need for thoroughness in his UWGDF project dictated
as much.
The Value of IT
83
REFLECTION
How do IT investments create value or enable value creation?
How might we get a quantitative handle on the level of value provided by IT?
What light does the consultants report shed on the matter of Daviess firing and
the subsequent choice of Barton as CIO? What (if anything) does it add to the IT
value discussion?
The Road of Trials
84
Excerpts from the IT Leadership Consulting Report
IVK Corporation
CIO Assessment
William Davies, CIO
IT Leadership
Requirements for eff ective IT leadership change as the economics and
scope of IT continue to change. As shown in fi gure 1, IT has evolved
through three eras since it fi rst appeared in companies during the 1960s.
Micro
era
Network
era
Data
processing
era
Organizational learning
1960 1980 1995 2010
Figure 1
The three eras of IT growth
Each era is characterized by a dominant IT technology and an organizational learning curve that runs over multiple years. The fi rst era, the
data processing (DP) era, was characterized by mainframe computers
used primarily for automating transactions. The second era, the micro
era, shifted the dominant IT technology from mainframes to microcomputers, or PCs. Mainframes were still used, but were gradually replaced
by microcomputers or arrangements of servers and clients.
The Value of IT
85
What has been termed Moores Law, which roughly describes the
economics of computers, continues to result in new capabilities for information technology. In its simplest form, Moores Law states that the
cost performance of computers doubles every eighteen months or so.
Another way of stating Moores Law is that for the same computer performance, the cost halves every eighteen months.
The practical eff ect of Moores Law is that applications of new technologies not economically feasible just a few years earlier become economically feasible. Accordingly, an important requirement for IT
leadership is for the IT team to stay on top of emerging new technologies and the changing economics of the new technologies. In addition,
an important IT leadership tenet is to build IT capability in a fl exible
manner to enable the incorporation of important new technologies as
they become economically feasible. While this tenet is now quite obvious, it was not during the early IT eras. Consequently, many companies
incorporated early technologies in an infl exible way and are now experiencing what has become known as the legacy systems problem. IVK
is experiencing the legacy systems problem in an indirect way with its
third-party package for loan origination.
Companies are now embracing the network era, in which the dominant technology has shifted from stand-alone centralized computers
loosely networked with PCs to integrated networks of literally millions of
computers operating over interconnected networks (including the
public internet). The network era is truly a sea change in the management
of IT. Before the network era, companies had to build expensive networks,
like American Airlines Sabre systems, to electronically connect with customers and employees. Through the internet, companies can easily and
economically connect with their customers and partners using a publicly
available infrastructure. As a result, IT in the fi rm can support both effi –
cient transaction processing and direct customer interactions in real time.
The network era presents an incredible set of potential opportunities, but the opportunities come with signifi cant exposure to risks, exemplifi ed by the threat to IT service levels from security threats
advanced by a global army of skilled hackers that have been unleashed
on the internet over the past few years.
The Road of Trials
86
IT Eras: Management Challenges and Opportunities
IVK has taken advantage of network era technologies and the internet to
serve customers. Indeed, IVK has taken advantage of this capability to
gain a strategic advantage. However, IVKs packaged software, developed
some time ago, is based on older processing and sourcing approaches
rather than more up-to-date real-time and service-based approaches. An
important IT problem for IVK is the reconciliation of its older back-offi ce
technology with its newer front-offi ce-real-time technology.
IVK has a strategic advantage with its front-offi ce systems, but is facing a key issue with re-architecting its back-offi ce systems in order to
sustain its current competitive advantage.
IVK IT Leadership: Transitioning from Type 1 to Type 2
Driven by changes in technology and economics, IT leadership continues to change through the years. Eff ective IT leadership depends on the
specifi cs of a company and its situation: its size, strategy, growth rate,
competitors, and industry. Three levels of increasingly sophisticated IT
leadership can be identifi ed, as shown in fi gure 2. Business/size/complexity
Time
Type 1 IT leadership
Control-oriented
Be nevolent dictator
Functional applications
C an-do
Type 2 IT leadership
Enterprise-oriented
Senior management team focus
A pplications portfolio
Infrastructure building
Security/ control
Type 3 IT leadership
CIO
Strategy focus
Information resources
Figure 2
Evolution of IT leadership in the firm related to IVK Corporation
The Value of IT
87
IVKs IT leadership is Type 1, the least sophisticated level, evolving
into Type 2. A Type 1 IT leadership capability is one in which IT has built
functional transaction-processing capabilities, enabling the company
to realize an overall effi ciency in operational business processes. IVKs
Type 1 IT capability has resulted in the achievement of a great deal of
loan origination along with the associated back-offi ce processing.
Responding to the growing transaction volume, however, has
stretched back-offi ce systems. Rather than dealing with the novel requirements of diff erent clients by using confi guration changes, whole
systems have been replicated and then customized for individual customers, creating immense complexity and a need to manage parallel
systems. This approach helped solve short-term problems in delivering
functionality to clients, but it has become a maintenance nightmare.
Changes to core loan processing now have to be made as many times
as IVK has major clients, with careful consideration to the special, customized features of each client system. Changes that work well for one
client can potentially cause problems if identically applied to another
client system. The ability of IT staff to manage this complexity is reaching its limit. Accordingly, there is an urgent need to re-architect the IT
infrastructure to accommodate the business growth expected in the
next several years.
IVK has begun to evolve to Type 2 IT leadership; this means moving
from managing individual functional applications to applications portfolio/infrastructure management.
The existing IVK applications portfolio is dominated by operational
systems. Poorly integrated spreadsheet applications are too often used
for operational purposes, making data fl ows and transaction fl ows exceedingly cumbersome. The IVK IT infrastructure has bubbled up from
the bottom and lacks architectural coherence and security protections.
IVK needs to address the need to implement Type 2 applications
portfolio management along with the development of an IT architecture for the supporting infrastructure. To sustain competitive advantage
through its use of IT, IVK also should be designing its application portfolio strategy and IT architecture with an eye toward Type 3 IT management as shown in fi gure 3.
The Road of Trials
88
Pa yroll
Loan origination
Check cutting
Loan status
Ac counts receivable
Ac counts payable
Fixed assets
eBusiness
A nalytics
Information
resources
Componentiz ation
layers
Type 1:
Applications
Type 3:
Web services
Type 2:
Applications
portfolio
IT infrastructure
Figure 3
IT value management
Recommendation Concerning Current CIO
Good CIOs are hard to fi nd. Even if you can fi nd one, it may take as much
as a year for a CIO new to the company to learn the company environment and become an eff ective leader. Your current CIO, who came up
through the ranks of IT managers, is struggling to transition to Type 2
leadership. In our judgment, he may be able to complete the transition
successfully. If IVK continues to grow, the issue will arise again when
there is a need to transition to Type 3 IT leadership. If the transition to
Type 2 is uncertain for the current CIO, the transition to Type 3 will be
even more so. However, given (1) the diffi culty of fi nding good CIOs, (2)
the time it will take to bring a new CIO up to speed at IVK, and (3) the
urgency of the need to update the IVK back offi ce, we recommend:
Retain the current CIO for at least another six months to a year,
time enough to see if he will be able to transition to Type 2
leadership.
Assist in this transition by providing executive leadership counseling for the CIO.
Reassess in six months to see how this transition is going.
89
chapter six
Project Management
Wednesday, April 11, 2:35 PM . . .
Bartons headache worsened. Leaning back in his seat, hands folded
in his lap, hed ceased trying to get into the conversation. What had
begun as a project status review had deteriorated into open confl ict.
The combatants represented the companys two major IT subgroups,
Loan Operations Systems and Customer Support Systems. At fi rst,
the meeting had been orderly and polite; each person took turns
walking through his or her list of projects in progress, explaining the
reasons for red, yellow, or green status indicators beside each
project. The lists showed a lot of green, some yellow, and a small
amount of red. Oddly, Barton noticed, both departments seemed to
have exactly the same proportion of green, yellow, and red status
projects.
The trouble had started when Rebecca Calder, a brilliant young fast
tracker from Loan Operations Systems, had commented that one of
her yellows might better be classifi ed as a green. Jorge Huerta, an experienced senior analyst from Customer Support Systems, seemed annoyed by the remark and made a point of saying the same thing about
one of his own yellows. In the course of the ensuing argument, it became apparent to Barton that many of the green and yellow projects
on both lists were behind their original schedule and over their original budgets. Although he found it educational to listen for a while,
The Road of Trials
90
eventually Barton raised his hand and shifted forward, which both
Calder and Huerta correctly interpreted as a signal to shut up. Then
he asked a question: Why is it that we are behind schedule and over
budget on so many of these projects?
Huerta was quickest to respond: Its because we lack discipline in
the project management process. Body language told Barton that Calder disagreed, as she had with pretty much everything else Huerta had
said for the past ten minutes. Barton glanced in the direction of Calders squirming, but raised a fi nger to keep her from interrupting. Barton turned back to Huerta: Explain.
Its simple, really, said Huerta. We dont plan enough, and we
dont establish project scope suffi ciently in advance. We dont do a good
enough job of obtaining a general agreement on what we are trying to
accomplish with a project. Because of this, success is a moving target.
We suffer again and again from scope creep. Because theres a failure to
establish the clear requirements of business users at the beginning of a
project, often project managers fi nd themselves under pressure to deliver in excess of what was originally agreed. The scope of the original
plan can start to move and continue to move. If the project manager
isnt alert, the requirements will constantly change. The project spends
long periods of time on delivering nothing, continually reviewing and
altering direction. 1
This sounded like a reasonable answer to Barton. But he pressed
Huerta: And your suggested solution to this problem?
More planning, said Huerta, and more discipline in decision
making. We spend more time up front in formal planning activities,
working with users to understand their needs and to help them understand what is possible in what we are planning to do. If we do this well,
well be able to strike a fi rm agreement in advance on what the project
will accomplish, which will provide a basis for a disciplined process
for achieving those objectives. If its not part of what were trying to
accomplish, we dont do it, no matter whos asking for it. There may
be some things outside the scope that have to be added, but we can do
that deliberately too. If were going to expand the scope, we should take
offi cial notice that were doing that and adjust our estimates of the time
and resources it will take to complete the project too.
Project Management
91
Barton was impressed. In just a few words, Huerta had presented a
diagnosis and a prescription for cure, both of which sounded plausible.
But Calder was still squirming in her seat. Barton turned to her.
Rebecca, you dont buy this logic?
No, sir, I do not.
Why not?
She sighed. Jorge has just presented to you the solution that weve
been trying to implement since the beginning of time; it never works.
Why not?
Because the diagnosis is fl awed. He thinks we should spend more
time and effort making sure we understand the requirements up front.
I dont think the users requirements even exist in advance, and they are
certainly not knowable in advance
Ooooh, now were getting metaphysical, ridiculed Huerta. Barton
didnt like his tone.
I didnt let Rebecca interrupt you, Barton said to Huerta, so let her
fi nish. Huerta shut up. Go on, Barton said.
Well, the diffi culty is that we discover many of the important requirements only as we begin to try to create the system. Communicating intangible ideas is very diffi cult. Only as they start to interact with
the system do users begin to see more concretely what is possible and
come to better understand the questions we are asking them. Only as
our discussions begin to refer to actual system features do we really
understand what they are saying they need. Users necessarily change
their minds about what they want as they come to understand more
clearly what is possible. An approach that denies or even discourages
such changes by claiming that it is more disciplined to stick to the
formal plan is just denying reality.
Huerta couldnt help himself: So we just launch off on a project, expecting to gather our requirements as we go . . . Barton turned sharply,
and his words trailed off.
No, said Calder, we dont just launch off! We spend some time in
advance trying to fi gure out what we can of what the system needs to
do, but at some point we need to start building the system so that we
can discover the things well never discover if all we do is think about,
talk about, and plan a hypothetical system. Jorge implies, along with
The Road of Trials
92
a lot of other management gurus, that if we are just more careful and
thorough, if we just spent enough disciplined time in the requirementgathering phase, we could get pretty close to understanding what we
need, and from there it would just be a matter of executing to plan.
Their prescribed solution is more planningmore time spent studying and not doing anything. I dont buy it. Lets admit that even if we
think really thoroughly about things in advance, we still wont anticipate important problems . . .
Thats what contingency planning is for, interjected Huerta, quickly.
Contingency plans are for problems you can anticipate, Calder
retorted. A big chunk of the problems with most projects are things
you cant anticipate. If we buy into the philosophy of project management that considers unanticipated problems to be a result of fl awed
planning, we doom ourselves to repeat our failures. Every time you
have a scope creep issue, you blame something you should have done
on an earlier phase of the project. Never mind that the thing you supposedly should have done better earlier was impossible.
Its not impossible! Huerta practically shouted. Barton did not
stop him this time. A couple of years ago, we were developing a user
interface with a notebook metaphor. On the screen, it looked like a
notebook page, and there were tabs at the edges so you could fl ip to a
different page. We had made an arbitrary decision to place the spine
of the notebook at the side, and that was built into the design of the
underlying software infrastructurethe object classes, if you want
the technical term. When we showed it to users, they said, Looks
great, but can you put the spine of the notebook at the top rather
than on the side? And we did it! We spent weeks making a change
because we had not captured that detail in advance. We could easily,
with a truly disciplined process, have picked up this requirement in
advance. Or, alternatively, a good process would have labeled this
change for what it is: scope creep. We would have said back to the
users, No, were not going to do that, it doesnt matter that much.
And wed have been right. They would have gotten accustomed to
the spine at the left rather than the top after less than an hour using the system. A disciplined process helps us avoid these kinds of
problems.
Project Management
93
Not a fair example, said Calder. Barton settled back to listen and
rest his eyes. His head was pounding. Not all examples are like that.
Last year, I was working on a project where we had peak load problems. We would have had a tremendously diffi cult time imagining in
advance that the load requirements would be so high; nobody foresaw
the business events that caused such high peaks in load on the system.
That could have been anticipated, with the right process . . .
Yeah, well maybe it could. In an ideal world without taxes, crime,
or war. Maybe. But how confi dent are you that you can anticipate every
problem, or even every important problem, on the large complex systems we work on all the time? You cant do it. Youd have to be prescient
or superhuman to anticipate all of the possible emergent issues. The
idea that a coherent and complete set of customer requirements can be
captured in advance is pure fi ction, at least in most cases. And it makes
no sense to give advice that, in effect, says, We need you to be more
superhuman.
What makes no sense, said Huerta, is to encourage people to just
race off at the start of a project, like a bunch of IT cowboys, justifying
their actions on the grounds that you cant anticipate all the important
problems anyway, so we might as well race ahead so that we can begin
making messes.
Calder did not respond immediately. This pause to think and change
the tempo of the argument impressed Barton. Her argument had begun
to impress him as well. There was a welcome moment of silence before
she replied, quietly, Actually, thats exactly how I see it. We should get
on with making the messes so that we can deal with them sooner rather
than later. You will inevitably have messes. Better to have them sooner
rather than postpone them. Early messes on a project may not always be
pleasant; they may look like management messes. But better early mess
than late-breaking disaster. Fail faster to succeed sooner. Fail forward.
Barton stirred. Is that it? he asked Calder. Is that your proposed
solution? Fail forward?
Calders face expressed disappointment. She thought Barton was
siding with Huerta.
No, sir, she said. Id recommend that we structure our projects to
begin creating prototypes very early and to generate a rapid succession
The Road of Trials
94
of prototypes. We should do some gathering of requirements before we
get started, but in doing that we need to employ the 80-20 rule. At some
fairly early point, you need to break away from the planning and start
trying things, or else you are just delaying the discovery of problems
youll never anticipate through mere contemplation.
Thats all well and good, said Huerta, for things you can create
prototypes for. But for some things you cant.
True, acknowledged Calder, you cant literally create a succession
of quickly evolving prototypes if you are implementing, say, a large
off-the-shelf vendor package. If it takes nine months just to install and
confi gure it, its hard to see how you can run a two-week prototype. But
you can do some things that approximate prototyping. Like detailed
walkthroughs of how the purchased system handles certain processes.
You just need some sort of procedure that gets you into prototyping
details, even if you cant literally produce a prototype. You can simulate
a prototype on paper, sometimesa paper prototype. Call it a conference room pilot test.
That starts to sound a lot like a document of some kind. A lot like
the documents I might propose in what I call a disciplined project
management process.
Maybe. But most project management documents dont prompt
the sort of active attention to detail and discussion that you get out
of a paper prototyping process. Maybe thats what they were once
intended to do, but I dont think they do that anymore.
Be careful, said Barton, the two of you just nearly agreed on something. Huerta and Calder laughed warily.
If I can summarize? Huerta asked.
Sure, said Barton.
I think we need to stop perpetuating the myth that IT projects are
somehow special. People manage building construction projects all the
time and manage to anticipate the requirements well enough that they
dont have the kinds of problems we have in ITif they are well managed, anyway. IT needs to grow up. Rebecca says we cant, because were
special. Well, that may make sense when you are just out of school, fresh
from hanging out with ivory-tower types. But its just not good enough
when we are making decisions about major capital investments.

Project Management
95
Calder responded: Jorge thinks Im living in an ivory tower when
I say an IT project is different from a construction project. Saying it
makes me less than a hardheaded, macho business guy. But I think
hes the one living in a dream world by maintaining on principle, and
despite evidence to the contrary, that we ought to be able to defi ne customer requirements clearly in advance, even though we never do.
A silence settled over the room. Barton broke it: It sounds to me like
we need some new thinking on project management around here. Well
get to that. However, I dont think that weve achieved todays original
objective of reviewing the status of active projects. So I need each of
you to go back to your departments and adjust these lists so that the
reds, yellows, and greens are accurate and honest. I dont want to see
a negotiated settlement where both of you have the same proportion
of reds, yellows, and greens. Judging from what Ive heard today, Im
under the distinct impression that some items labeled green ought to
be labeled yellow or even red. When we reconvene this meeting in a few
days, I want to hear accounts that have a strong connection to reality.
Understand?
Calder and Huerta nodded.
Good. Now lets get out of here. I have a terrible headache.
Thursday, April 12, 5:49 PM . . .
Done with meetings for the day, Barton opened the bottom drawer of
his desk and removed a musty textbook. The meeting with Calder and
Huerta had prompted him to go in search of it the night before. It had
taken him a couple of hours to fi nd it on the back of the self-storage
unit where he kept a lot of old junk; by the time he did hed lacked the
energy to open it.
Titled Project Management , the book was from a course hed taken
in college. For the fi rst time in more than two decades, he opened it
and began reading, skimming the table of contents, jumping around as
chapter titles caught his interest.
He read about Gantt charts, PERT analysis, and CPM. In essence,
these were planning methods. They broke down projects into discrete
The Road of Trials
96
tasks with stated durations (and, in later chapters, possible variancesa
task might be fi ve days, plus or minus two days), keeping track of which
tasks had to be completed before others could begin. The project tasks
could then be graphed out with dependencies between them explicit.
The longest duration line of dependencies could then be identifi ed as
the critical path; that is, the path along which any delay meant an
overall project delay. Tasks on the critical path deserved extra scrutiny
during the management of the project, since they were so important
to keeping the overall project on schedule. The book also spent many
pages on planning the allocation of resources, such as key people or
equipment. By using the methods described in those pages, you could
be sure not to make plans that required a single person to be in two
places or doing two jobs at once. Useful stuff. Much of it, Barton was
sure, had been incorporated by now into project management software
packages; he suspected that computer software now did some of the
calculations that took up so many pages in the book.
In the end, the book seemed more about how to plan projects than
how to manage them. It provided some advice about actual in-progress
managing, but most of that was pretty straightforward. Be sure you
dont forget this. You must do that. The sort of exhortation that dodges
questions about why people in real life do forget things they shouldnt
or dont do things that they must.
Barton put the book aside and went online. Searching project management and IT-related keywords, he came across some information about
the Software Engineering Institutes Capability Maturity Model Integration, which apparently included an approach to project management. 2
It
also seemed to provide some advice about how to keep a project on track.
But, like the textbook, it too seemed to emphasize planning.
Barton had nothing against planning. He was a huge fan of planning.
But he suspected that Calder was right that, no matter how much you
planned, some unexpected things would still happen on something as
complex as a big IT project. It nagged at Barton that most of the advice
he was reading seemed to focus mostly on preparing for the expected,
not managing the unexpected. Calders critique rang true: the authors
assumption seemed to be that if you experienced something unexpected,
then you hadnt planned well enough. Thorough planning would help
Project Management
97
you identify a problem that you might not have anticipated without
doing such thorough planningthat was obvious. But it was just as
obvious that you couldnt count on anticipating every problem! So project management, Barton reasoned, had to contain some advice about
how to manage the unexpected. Or maybe that was a crazy idea? How
can you manage something of which you have no previous perception?
A bit more searching led him to an article called Agile Project Management: Principles and Tools by a consultant, Jim Highsmith. 3 Barton grew interested as he read the following:*
APM practices thrive in projects that are exploratory in nature, ones
that push the envelope of schedule, risk, and rewards. As such, these
projects dont conform to the traditional plan-build mode of
operation, but progress by exploring and adapting. The speculate
phase generates a hypothesis about the future, not a detailed
deterministic plan. Agile project teams expect the plan to be
wrong; they expect changesoften very large ones. Therefore, the
monitor and adapt phase names what happens when variations are
found. Traditional project managers talk about corrective action,
which implies that the plan was correct, and the actual results, if
different, must be in error.
Barton didnt completely understand everything he read in the article, but he liked the way in which the author made real-world assumptions about the need to deal with the unexpected.
Standing up from his desk, Barton went to the whiteboard and wrote
headings for two columns. The fi rst: Managing Problems You Can
Anticipate. The second: Managing Problems You Cant Anticipate.
He wasnt sure what specifi c management measures should be listed
under each, but fi lling in those blanks was the task at hand, he thought.
He wrote planning techniques and methods under the fi rst heading.
By that he meant Gantt charts, PERT, CPM, and resource scheduling
methods. Under the second heading, he wrote exploring, adapting,
course-correcting techniques and methods. Then he put down the pen
and sat back down to contemplate what he had written.
*See Excerpt from Agile Project Management at the end of this chapter.
The Road of Trials
98
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4
$75.12 $30.72
4.77B 1.95B

Mang. Problems: CAN anticipate
planning techniques & methods
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
He had no idea, he realized, what exploring, adapting, coursecorrecting techniques and methods were. Highsmith had some suggestions, but Barton lacked the expertise to know whether they were
any good. Nevertheless, the direction seemed promising.
Reaching back into the bottom drawer that had contained the old
textbook, Barton removed a fi le folder marked Project Status Review
in Daviess handwriting. Davies had jotted notes in the margins and
changed some numbers. You could see the handwritten changes; then
in later versions of the document, the jotted-in numbers became
offi cial. It appeared that Davies was in the habit of doubling, roughly,
the estimates made by his own people for how long it would take to
complete a project. Hed take an IT internal estimate, then mark it up
by 25 to 100 percent. The amount of the markup appeared to be related
to entries in a column labeled Estimate Confi dence. If the estimate
confi dence was High, the markup would be smallusually. If the
Project Management
99
estimate confi dence was listed as Low, Davies marked up the estimate
by a lot. The rule wasnt exact. Barton guessed that Davies knew who
had generated each estimate and confi dence entry, and was adjusting based on his own knowledge of the reliability of the estimators
estimate and the estimate confi dence.
Barton understood the temptation to mark up the estimates. This
was a big part of the way Davies had managed the unexpected. He added enough slack into every estimate so that he had a reasonable chance
of bringing projects in on schedule, even if the unexpected happened.
But Barton could also see a problem with the approach. As he looked
through the other project status documents before him, it was clear
that few (if any) projects fi nished ahead of the marked-up estimates.
In other words, project teams pretty much always took all the time
predicted in the marked-up estimates. Barton guessed that there were
numerous reasons for this. Sometimes the unexpected did happen and
The Road of Trials
100
the marked-up estimate was more realistic. When nothing unexpected
impacted a project and it was running ahead of schedule, resources
were likely diverted from it to projects in greater trouble. Then there
was Parkinsons Law, the truth of which Barton fi rmly believed:
Work expands so as to fi ll the time available for its completion. 4
One thing Barton liked: the estimate confi dence seemed like a useful thing to capture. In essence, it expressed the likelihood of an unexpected problem arising on a project. A low estimate confi dence
said Were pretty sure well have problems we havent anticipated on
this project, while a high estimate confi dence said Were pretty sure
we wont have unanticipated problems. This information, refl ected
Barton, might be used to help decide between what Highsmith called
traditional and agile project management approaches.
Barton searched the web some more, exploring the subject of project estimation. There was a ton of material out there on the subject, but
most of it was about estimating the cost or duration of software development projects. The usual method, as best he could discern, called for
somehow gauging the size of a development project in terms of lines
of code or something called function points, and then using different
methods and adjustments to derive from the project size its cost and
duration. 5
The biggest problem with all of it from Bartons perspective:
very few of the projects in the IVK portfolio were software development
projects. None of them, really. Some of them contained components that
required software development. But that was not the major part of the
project. Usually, any development in an IVK project had to do with fi tting a purchased package or externally provided service to existing IVK
systems, creating the interfaces between systems, that sort of thing. For
the kind of projects IVK usually had to do, there was no obvious way to
estimate size, so there was no place to start with the estimating models.
And anyway, the estimates developed by these models had huge ranges of
errorplus or minus 50 percent or more; how useful was that? It was too
bad, really, but the science had not caught up with management practice.
Does it ever? Barton asked no one in particular. He looked at his
watch. It was time to call it a day. Replacing the fi le folder and book
in his desk drawer, he packed up and headed for home, still thinking
about methods for managing the unexpected.
Project Management
101
Friday, April 13, 8:49 PM . . .
Barton walked into Vinnies Bistro. Immediately he noticed the kid
seated at the bar, sipping a root beer and eating a burger.
Hows it going? said Barton, taking a seat beside him.
Well, well, said the kid, the great manager returns! How goes the
new job?
Barton ordered his own burger and soda before answering. Pretty
well, I think. Starting to get my bearings. Still trying to be sure I know
what I dont know.
Good man, said the kid. Whats the hot issue this week?
Not sure theres just one. But if I had to pick, it would be project
management.
Hmm, said the kid. Thats a tough one.
Is it?
A classic area where managers dont know what they dont know.
Some of them dont really care that they dont know what they ought
to, I think.
What makes you think that?
I look young, but Im a survivor of many death march projects.
Way too many.
Death march projects?
Yeah. Term comes from a book by Ed Yourdon. 6
Or at least hes the
one that made it really famous. A death march is a project with a bad
plan that managers are determined to stick to. The primary management
tool is yelling a lot and making people work longer and longer hours.
Managers leading a death march dont want to hear about unexpected
problems, and workers understand that. So everybody just sweeps problems under the rug; its the de facto management policy. People on the
front lines, the smart ones anyway, take steps to make sure theyre not
standing too close when the whole thing collapses under its own weight.
They all keep their heads down and mind their own business. Lots of
burnout, morale stinks. Catastrophe in the end, usually. Death march.
Does that really happen so often?
The kid didnt even answer, but Barton could read the expression on
his face.
The Road of Trials
102
So, asked Barton, whats the alternative to death march
management?
Im not sure the alternative has been perfected yet, which is one
reason therere still so many death marches. Its the fallback approach.
The fundamental problem is that its the guys on the front lines who
see a problem fi rst. If its primarily those guys youre holding accountable for schedule, then they have an incentive to avoid realistic assessment or communication of those problems. Often theyre just overly
optimistic. You know, Yeah, thats a problem, but I think we can adjust
quickly and solve it by doing this or that. Only this and that have little
chance of saving the day.
In managing an IT project, the kid continued, the boss has the
diffi cult task of getting the workers to behave in a fundamentally irrational way. You need the frontline guys to be willing to bring bad news
to the boss, because he or she often cant detect the bad news alone. So
the best project management policies are those that promote open fl ow
of information up and down the project hierarchy. On death march
projects, theres almost no information moving upwardno reliable
info, anyway. Everybody understands what theyre not supposed to tell
their managers.
So what are the policies that promote better fl ow of information
upward?
Hey, youre the manager. Speaking from my experience, the managers Im most likely to talk honestly with, the ones I provide with early
warning of unexpected problems, are those I talk to a lot and like, who
seem to want to understand what Im doing and ask me about it. Im a
bit too talkative anyway, when approachedas you might have noticed.
Get me talking, and Ill blurt out all kinds of things that I should have
thought about before I said them. A lot of people like me are like that,
I think. Its a dysfunctional learned behavior for us to censor what we
tell our managers.
What do you think of the agile approach?
Iteration is good. If you structure it right, each iteration prompts an
important conversation, you get early warning on most problems. And
iteration lets you see opportunities to create value you didnt see at fi rst,
value that isnt in the plan.
Project Management
103
If you start too soon, you might go down some dead-end paths,
though.
Sure. Get over it. It costs you some of your project budget to learn
what you need to do to succeed. If you insist that every hour or cent
moves you in a direct line closer to the next milestone, sooner or
later youll be on a death march. Sometimes you have to back up to
get around an obstacle. Plus, I believe in working code, above all else.
I think youll fi nd that most people like me do. Working code beats
half-baked or unexecuted plans any day of the week. Iteration gets
you to trying to implement quicker. Yes, that can be ineffi cient sometimes, when you start in the wrong direction and a bit more planning
would have worked better, but it can also save you time by showing
you that an assumption you made in planning wasnt even close to
correct.
The kid had fi nished his meal and was paying the bill. Got to go. Big
night of gaming scheduled.
Barton nodded and fi nished chewing a couple of fries: So, you ready
to come to work for me yet?
Not yet, said the kid. But lets talk again next time.
The kid left. Barton motioned to the waiter. He needed more ketchup.
REFLECTION
Which side would you take in the debate between Huerta and Calder?
Does it make sense to jump directly into project coding and early prototypes in
order to discover messes (unanticipated issues) earlythat is, to fail fast to
succeed sooner? Can this advice be implemented in a practical way?
How can you manage, or prepare to manage, what you cannot anticipate and
do not expect? What do you think of the approach that Davies seems to have
used (as revealed in the documents discovered by Barton) to manage uncertainty in IT projects?
The Road of Trials
104
Excerpt from Agile Project Management
Agile project management (APM) complements traditional project
management (TPM) in many ways. a
Project managers should understand the basics of setting up project organizations, budgeting, critical
path scheduling, and myriad other established project management
practices. However, project managers should also know when and how
to apply agile practices. There are three broad situations in which APM
should be considered over TPM:
High explorationfactor projects
Projects in which customer responsiveness is paramount
Organizations with innovative cultures
The APM Lifecycle Framework
The lifecycle framework includes fi ve phases:
Envisiondetermine the product vision, who is going to do the
work, and how the team will work together.
Speculatedevelop a feature-based release, milestone, and iteration plan.
Iteratively deliver featuresdeliver tested features in short time
frames.
Monitor and adaptreview the delivered results, the current
business environment, and the teams performanceand adapt
as necessary.
Closeconclude the project, wrap up loose ends, and celebrate.
The names of the phases are diff erent from traditional ones to refl ect
the focal points of agile project management. Envision, for example,
indicates the critical nature of a clear product vision in a project.
APM practices thrive in projects that are exploratory in nature, ones
that push the envelope of schedule, risk, and rewards. As such, these
projects dont conform to the traditional plan-build mode of operation,
but progress by exploring and adapting. The speculate phase generates
Project Management
105
a hypothesis about the future, not a detailed deterministic plan. Agile
project teams expect the plan to be wrong; they expect changes
often very large ones. Therefore, the monitor and adapt phase names
what happens when v ariations are found. Traditional project managers
talk about corrective action, which implies that the plan was correct,
and the actual results, if diff erent, must be in error.
TPM approaches allow for a variety of development lifecycles, although in practice, they are heavily biased toward sequential, waterfall
lifecycles. APM takes exactly the opposite approach; it is decidedly
short-cycle, iterative, and feature-driven. Agile teams deliver in short
iterationsweeks for software projects, longer periods for industrial
products. For industrial products, teams get as close to actual features
as possible, using simulations or models to give the customer something tangible to review.
Nine Principles of APM
The core components of APM are the tools and principles. Principles
guide actions; they breathe purpose and dynamics into tools. Without
principles, team members wont understand how to use the tools, nor
how to adapt them when needed. Conversely, principles without tools
are lofty phrases devoid of concrete meaning. The nine principles of
APM are:
Deliver something useful.
Cultivate committed stakeholders.
Employ a leadership-collaboration management style.
Build competent, collaborative teams.
Enable team decision making.
Use iterative, feature-driven delivery.
Encourage adaptability.
Champion technical excellence.
Accelerate throughput.
The Road of Trials
106
APM Tools
Tools implement, or instantiate, principles. Developing a product vision
box helps a team focus and delivers something useful to their customers. A project data sheet helps a team grapple with the scope boundaries of a project. Estimating a projects exploration factor helps a team
quantify, to some extent anyway, the uncertainty surrounding a project.
Feature cards provide a tactile, low-ceremony, easy-to-use tool for project planning. Daily team integration meetings are a critical piece in creating collaborative teams, as is a collaborative decision-making tool.
These and other tools help teams implement APM.
Conclusions
Some people may think APM isnt all that diff erent from TPM. Some
may already practice their own version of APM. Some may think it heretical. I think APM diff ers from TPM in several signifi cant ways.
First and foremost, APM is principles based and tools instantiated.
The nine principles of APM are the drivers; they help us interpret how to
use tools. Second, APM focuses on delivery, not compliance activities.
Because of this, customers and products, rather than stakeholders and
activities, become the focal points. Third, when we focus on customer
needs and problems and then build products to solve those needs and
problems, we recognize that exploration, innovation, and adaptability
are key to success.
These values defi ne agile project management. APM may use some
of the tools of TPM, or vice versa, but the fundamental philosophies differ. For more and more of todays projectsthose that have high exploration factors, require active customer responsiveness, or take place in
organizations with innovative culturesAPM should be strongly
considered.
a. From Jim Highsmith, Agile Project Management: Principles and Tools (Arlington, MA: Cutter
Consortium, March 9, 2004). Reprinted by permission.
107
chapter seven
The Runaway Project
Wednesday, April 18, 10:12 AM . . .
The coffee tastes particularly good this morning , Barton thought, as he
settled in behind his desk to catch up on things hed been neglecting.
Monday and Tuesday had been a blur, getting ready for the IT review in
the senior leadership meeting on Tuesday afternoon. Barton, aided by
Geisler and his other direct reports, especially Ruben, had been scrambling to make sure all the i s were dotted and the t s crossed before
Barton went into the big meeting.
All the hard work had paid off. The IT group, using a framework
based on Compete and Qualify categories, had wowed Carl Williams.
All the other groups in the departmental reviews conducted thus far
had used simple metrics, such as revenue or profi tability growth, for
demonstrating the value of their work. With some exceptions, it was
hard to show that specifi c activities of a department had caused growth
in sales or profi tability, so most had rushed past the value question to
analysis of costs, which had occupied most of the meeting discussions.
But if customer-facing departments had trouble showing causality
between their activities and favorable fi nancial results for the company,
the diffi culties of the IT department were even more profound. IT was
mostly not customer facing. Customers used online services provided
and supported by IT. But IT sold nothing to IVKs customers directly
and rarely interacted with them. Almost everything the IT department
The Road of Trials
108
did was in support of other departments, or part of what those
departments offered to customers. So, with very few exceptions, drawing a line between something the IT department did and increases in
sales or profi tswell, that was very diffi cult indeed. Even if Barton had
been inclined to do it, hed be in danger of claiming credit for benefi ts
that other departments had already said were the result of their own
activities. Consequently, hed risk having such claims challenged by
department heads in the meeting.
This had led Barton and his team to fl esh out the Compete and
Qualifi er (CQ) framework and estimate in various areas the gaps between IVK capabilities and competitors capabilities as a result of IT
functionality. Each IT-enabled capability they identifi ed was categorized as either a Compete, meaning that IVK intended to move ahead
of its competitors using that capability, or a Qualifi er, meaning that
IVK did not expect a competitive edge from the capability but nevertheless needed it to do business. For Compete advantages, the IT team
had also estimated the sustainability of the advantage: not only how
many months ahead of competitors they were, but also whether IVK
was extending or losing its lead in that area. Of course, this methodology inevitably identifi ed areas where IVK trailed competitors. It was a
tribute to Davies and past IT management that relatively few of those
impacted customers. Partly, Barton suspected, this was because powerful managers outside IT demanded that customer needs be met fi rst,
and Davies, not a very strong proponent of alternative views, generally gave in. Nevertheless, the facts presented an opportunity for a congratulatory word or two about Bartons predecessor. No one had seized
that opportunity in the senior leadership team meeting, but Barton
commented to that effect within his own team, congratulating them on
their past good work.
By the end of the IT review, Williams had ordered each of the other
departments to apply the CQ analysis in their own areas and to return
to a future meeting to revisit the value side of their own departments
activities. Barton concealed his pleasure at this outcome, because the
other members of the leadership team took the CEOs instructions as
a reprimand. Another dynamic surprised him as the meeting broke
up: he picked up a vibe emanating from the others that bordered on
The Runaway Project
109
resentment, a Why dont you IT guys go back to the basement where
you belong? sentiment. They were dead wrong about this, and surely
they knew it. Solid analysis was solid analysis, whichever department it
came from. Wasnt this the reason theyd encouraged him to take the IT
job in the fi rst place? To bring the quality of management that had been
practiced in the business areas into the IT department?
It was, Barton refl ected, his fi rst big win as the new CIO, accomplished less than a month after taking the job. Maybe this job wouldnt
be as hard as hed feared.
Williams had also asked Barton to prepare an update to the board of
directors sometime in June. The CEOs enthusiasm for the CQ framework had prompted this request; Williams wanted Barton to use the
framework as part of the update. But a report to the board would also
need to include an assessment of the current state of IT and recommendations about what to do about what was perceived as the IT
mess. June was still pretty far out on his planning horizon, but Barton
would begin to discuss it with Ruben and Geisler.
The only sour note in the IT review had centered on the infrastructure replacement (IR) project, which stood out as the single largest
item in the IT budget. Barton knew what it was, but had not prepped
on it as much as he should have. Others on the leadership team noted
that the project had consumed more than $3 million already, and no
one could think of any business benefi t that had yet materialized from
it. When asked why and what was going on, Barton did not have a good
answer, but promised to investigate. Williams requested an update in a
meeting scheduled for two weeks later.
Is that enough time? Williams had asked.
Ill make it enough, said Barton. As a turnaround CEO, Williams
did not have a reputation for patience. Barton suspected that Williams
considered two weeks roughly equivalent to eternity. But Barton resisted the urge to offer to do it more quickly, since he had no idea what
investigating would involve. And in the area of IT, he understood already, things often turned out to be more complicated than he would
at fi rst expect.
So it was to the IR project that Barton fi rst turned his attention
as he sipped coffee and cleared his desk of some minor matters that
The Road of Trials
110
Wednesday morning. It was too bad that hed not prepared suffi ciently
for the questions about this project from his colleagues. But on the
other hand, perhaps it presented an opportunity for another triumph.
Friday, April 20, 1:34 PM . . .
Barton leaned back in the chair and propped one leg across the other
knee as he listened to Tyra Gordon. Her Loan Operations and New
Application Development Systems area comprised the largest IT portfolio in the organization, although Raj Juvvanis Customer Support
Systems portfolio had grown in recent years to a size that nearly rivaled
that of Loan Operations. Many of Gordons systems did back-end processing, the heart and soul of the enterprise, but these had less direct
customer impact than Juvvanis systemsunless they didnt work, in
which case the entire IVK business would screech to a halt.
Barton had asked Gordon to set some time aside for the two of them
to review status on the IR project. Though the project touched all areas
of systems in the business, its biggest impacts would be on the backoffi ce systems that were under Gordons care. For this reason, Gordon
was the IT departments point person on the project, although she was
not the project leader. In compliance with the advice of consultants in
the not-so-recent past, a business (not IT) manager led the IR project.
Jay Palmer, a senior manager who reported to IVKs top sales executive, was its offi cial leader, though Barton had a hard time imagining
him taking a very active role. Palmer was a sales guy by training, a deal
maker, very good at what he had worked his way up doing. He was a
conscientious person, but not detail-oriented. Barton suspected dysfunction; it was unclear how Palmer would lead a huge IT project.
Bartons concern had led him to Gordons offi ce, where moments
earlier hed entered and asked, simply, So whats the story on the IR
project?
Well, said Gordon, its had its diffi culties, but I wouldnt say its
way off the rails.
Thats good, said Barton. I got asked about it in the leadership
team IT review the other day, and I didnt know as much about it as
The Runaway Project
111
I wanted to. Can you give me the short version of the background on
the project?
Sure, responded Gordon. She stood and moved to a fi le cabinet.
Searching, she quickly located a folder, which she opened on her
desk as she sat back down.
Here, she said, handing a single page to Barton. This is the consultants summary report that launched the project. As you can see, the
recommendation that led to it is fi rst on the list.
Barton read a section labeled Obsolete Systems Issue:
Begin a project to replace middle and back-end systems. Form a crossfunctional team composed of equal parts business and IT staff, led by
a senior manager on the business side, who should have hands-on
responsibility for this project. Put your best people on this project. Do
not pull them off for short-term urgent reasons. Cost Estimate: 3% of
current revenues. Recommended timing: VERY SOON.
Hmm, Barton said. Three percent of revenuesthats some
serious cash. Is this it? He waved the single page in the air.
No, said Gordon, thats just the summary. Should be some more
detail . . . here. She handed him several more sheets of paper, stapled
together and opened to an early page.
Barton read this page and the page and a half that followed it in silence.*
At the same time, Gordon refreshed her memory from an extra copy.
Hard to argue, observed Barton, with the logic behind the need
for the project. Gordon nodded in agreement. When was this done?
Lets see. Gordon paused to remember. Its been about a year and
a half now, said Gordon. We jumped right on it after the assessment.
Project leader, as Im sure you know, is Jay Palmer.
Hows that been going?
You mean Jays leadership?
Yes.
Fine.
Barton said nothing, waited for Gordon to elaborate. Gordon saw
that she was not going to get away with a one-word response.
*See Excerpt from Consultants Report at the end of this chapter.
The Road of Trials
112
He was really energized at fi rst, put a team together and did a lot of
good work with a process consultant, current state versus desired state
analysis, that sort of thing. Pretty detailed. But at that level of detail,
the size of the project is overwhelming. They fi nished their fi rst cut in
about three months, as I recall. The consultants handed them a huge
document, then nobody quite knew what to do next. Jay was instrumental in landing the BtJ deal about then, andhow can I say this?
he became motivated to think more broadly about his goals in life.
You mean he made a truckload of money on the deal and became
less motivated in his day-to-day activities.
Yes, thats what I mean. Plus, I do think it really was diffi cult to
know what to do next. All that detail documented, what do you do
with it? The team did take a next step. They hired NetiFects, the systems
integration fi rm we are still working with on the project.
The fi rm were still paying every month.
The same.
Thats what brought it up in the meeting. Weve spent quite a lot
and no one could name any concrete benefi ts from the work.
Thats a reasonably accurate assessment. There have been issues.
Barton sensed reluctance, a political issue lurking behind Gordons
general statement.
Tell me more, said Barton, and dont leave out your own opinions of what has happened. This last bit he added with more sternness
than was perhaps called for. But he didnt want the offi cial version; he
wanted the lowdown.
Gordon sighed, then nodded. The project leadership team, Palmer
and the other members, are mostly not IT people, in keeping with the
recommendations of the consultants. This worked well in the early
stages. But when it came to evaluating the consultants, we hadand
this is my opiniona problem. NetiFects was very smooth, gave a great
presentation. I was there. They made a big deal about their resources
offshore, how they would work on our project across continents and
time zones. I raised an objection. To me, it seemed likely that we would
rely to a considerable extent on packaged software and externally provisioned services for the new back-end infrastructure. Heck, some
people these days would argue we should do all, or most of it, outside
The Runaway Project
113
IVK, in the cloud. Not sure well go that far, but I still saw a disconnect.
Offshore contractors are likely to be useful for a lot of custom development, but I wasnt then and still am not sure how much of that we
should do in this project. Some, of course, but the bulk of the work is
likely to be getting packages and services confi gured, installed or connected, and running. Were not going to rewrite our own loan origination systems. So it seemed to me they were making too much out of the
offshore developers thing.
But that appealed to the IR project team.
It did. WeIThad a couple of people on the team, good people,
and I went to most of the meetings, but Im not all that confi dent that
we asked as many hard questions as we should have.
Its been over a year since we started paying them. What do you
think of their work?
Theres a bigger issue. They didnt make a lot of it at vendor
selection time, but it turns out that a lot of NetiFects expertise is in
Unix-based technologies. Historically, we have had heavy reliance on
Microsoft technologies. These are competing technology platforms.
No sooner did we hire NetiFects than they put on a full-court press
trying to get us to switch to the Unix platform for our next-generation
back offi ce.
Any merit in the idea?
Some. Theyre good technologies, solid. The problem is that our
entire base of experience is in a different set of technologies, which are
also pretty good. If were going to switch to a new technology base and
retrain everyone as that would require, Id like to have a better reason
than Its more convenient for our consultants.
Is that the only reason theyre recommending it?
The main reason, I think, though theyd never admit it. For them,
its a very practical issue. They have tons of resources with their kind
of expertise, not so many with our kind. Even if they have the ability to
deliver on this very challenging project, they may not be able to do it in
technologies they dont know well. They know this is going to be hard,
so theyre trying to gear the playing fi eld to their strengths, to reduce
their risk of failure.
Reasonable enough. We dont want them to fail either.
The Road of Trials
114
Yes, but we might have been better off choosing an equally qualifi ed
vendor who had a lot of experts in our technology base. Again, the
non-IT composition of the project team came into play here. I think
they didnt realize what a big deal it was; they believed the vendor reps,
who were inclined to downplay the problem.
They believed the vendor, not their own IT department?
You bet. It almost always goes down that way. A classic problem.
The vendor wants to win the contract, so they tell the business people
what they want to hear. The internal IT guys raise concerns, become
the naysayers; This wont work for that reason, that wont work for this
reason. The business guys interpret the naysaying as lack of expertise
within the company, or us feeling rivalry with the vendor, because they
want to believe what the vendor is saying. Of course the vendor changes
tune as soon as the contract is signed. The problem from the vendor
perspective shifts then from winning the project to managing the overblown expectations created by claims they made while trying to win
the deal. Choosing between a vendor and your own IT department, you
business guys never choose us.
Actually, Barton reminded her, Im now an IT guy.
Oh, I know. Just venting a bit.
Barton smiled. So what has NetiFects been doing?
A few things. Theyre walking the project team through a packaged software and external service offering selection process. Not surprisingly, they have a bias in favor of packages and services based on
their favored technologies, not the ones were most comfortable with.
Theyve also been writing a lot of interface code, which we will need
to link systems built with their technologies to our legacy systems that
wont be replaced. Much of which would not be needed at all if we
stuck with the technology platforms weve used historically.
Sounds like were going sideways.
Basically, agreed Gordon.
We pay them a fat retainer every month, plus a lot of extra billable
items. The invoices come through my offi ce for a signature.
Its not only their fault, to be fair, Gordon allowed. We have a substantial degree of analysis paralysis going on. This kind of project is just
too big. You get all psyched up to tackle it, then you start to look at it in
The Runaway Project
115
earnest and it just looks impossible. For a few months now the project
team has been running hard up to the project and bouncing off of it.
Couldnt it be split up into smaller chunks?
Thats probably the right thing to do, but fi guring out what the
chunks should be is really hard work. Youre replacing an infrastructure thats an immense tangle. There are no obvious places to cut the
infrastructure apart so that you can work on just a subpart. There are
places that look like logical places to cut, but when you look closer you
see that there are all sorts of vital nerves and blood vessels running
through that juncture. Cutting it apart without killing the patient is
hard to do.
Should the IT department be in charge of this project?
Gordon shook her head. I dont know. Its been a joy to watch the
non-IT members of the IR project team taking responsibility for business process decisions that are all too often left, inappropriately, to the
IT department. But the lack of technical expertise in the majority of the
team members has landed us some serious problems.
Barton realized that this was about as far as he could push Gordon.
He didnt want to give her the idea that he blamed her for problems
with the IR project. She had been admirably free from defensiveness
during the conversation; Barton wanted to preserve that aspect of their
rapport. He shifted to a few other subjects, then was gone from her
offi ce before 2 pm.
Tuesday, April 24, 1:43 PM . . .
Barton was annoyed. He sat across a conference room table from Carlton Leopold, the NetiFects manager for the IVK account. To one side of
Leopold sat Ash Srinivasa, the technical lead on the IR project. Barton
kept trying to talk to Srinivasa, but Leopold kept answering. It was
pretty clear that, by previous arrangement, Srinivasa was keeping his
mouth shut, which was exactly what Barton did not want.
Barton was trying to get them to admit the project was going sideways, because once that was out on the table they had a chance at
formulating a recovery plan. He could see in Srinivasas eyes that he
The Road of Trials
116
agreed. Barton had also asked some questions about the technology
platform, and whether it was such a good idea that IVK switch to an
entirely new (to IVK) set of technologies. Srinivasa appeared eager to
answer these questions too, but Leopold refused to admit that things
were going badly, and the conversation never, in Bartons view, moved
in a productive direction.
I think we are on track, Leopold said. If youd like we can schedule
a time for a full presentation of our progress. Would some afternoon
this week work on your schedule? Wed probably need two to three
hours to do the job properly.
Since the day Barton had been appointed CIO, NetiFects
specifi cally, Leopoldhad been trying to get a three-hour block of time
on his calendar. Barton had no intention of acceding to this request, as
he was certain the plan was to hit him with a full-blown marketing
pitch. NetiFects, or Leopold anyway, had clearly decided that their best
chance of impressing the new CIO was to set out their case in full. Barton wondered too if theyd decided they could snow the new guy since,
as everybody knew, he wasnt a techie. In the comfortable context of
their slide presentations, Leopold would be able to dazzle Barton with
technological bullshit. Or, anyway, that would be the idea.
Listening to Leopold go on and on, Barton admitted to himself that
he just didnt like the guy. He reminded Barton of the worst kind of bizdev con artist, the big talker, the kind it took you many precious hours
to fi gure out was clueless.
Finally, Barton gave up. He recalled, suddenly, another meeting he
was late for and excused himself, promising to set up a three-hour
appointment if Leopold would only call his assistant. The fi rst thing
Barton did upon leaving the meeting was walk to Jennys desk and tell
her that under no circumstances should she schedule a meeting with
Leopold.
He did it just in time. Before Barton left her desk, Leopold had called
to schedule the meeting. Jenny deftly dodged the request, saying shed
need to speak with Barton and that Leopold should call back in a few
days. As much as he disliked the guy, Barton had to hand it to Leopold;
he was certainly prepared. He had located Jennys number and called
her before hed even left the IVK conference room.
The Runaway Project
117
Friday, April 27, 10:32 AM . . .
Im thinking of fi ring NetiFects, said Barton.
Bernie Ruben, who had been about to head out the door, froze in his
tracks and dropped back down into his chair. Barton had wandered into
Rubens offi ce without warning, caught him just as he was due at a meeting
of his group. The two had been making arrangements for Barton to return
later when Ruben asked for a preview of the subject of the conversation.
Maybe wed better talk now, said Ruben.
Okay.
Whats the rationale? asked Ruben.
The project is going nowhere. It needs a shakeup. They seem to me
to be mostly collecting their fees and working on things we wouldnt
need if we had a vendor with different technology expertise. Barton
sat down too.
All true, acknowledged Ruben. But youd have to pay a ransom to
get free of the project. Im sure theres a termination fee.
I fi gure theyll try to get us to pay another million or so. I might refuse.
Hardball.
If they try to get tough back, Ill claim they havent delivered value.
Maybe some of their other clients would be interested in what I mean
by that.
Ruben nodded. Are you sure fi ring NetiFects is your decision to
make? On Thursday, Barton had spent some time with Jay Palmer and
fl oated the idea. Palmer had seemed relieved that someone else might
be willing to take the initiative on the project. He clearly had no deep
affection for NetiFects, at least none that got in the way of his relief.
Undoubtedly , thought Barton, hes met Leopold .
Palmer wont make a fuss. Hell be happy to get out of the line of fi re.
Youd be stepping into the line of fi re in his place.
Barton nodded.
Just as well that someone take over from Palmer, though, said
Ruben. Hes moved on to other things. His heads not really in it.
He told me yesterday hes thinking of taking some time off to do a
long executive program at a business school. Said hed already talked to
Carl about it.
The Road of Trials
118
Figures, said Ruben. He hasnt been fully with us since the BtJ deal.
I think, said Barton, that IT should now take over the IR project.
Risky, said Ruben, Its a big project. Complicated. Good chance of
failureor perceived failureno matter how well its managed.
Barton nodded again.
Itll set the timetable back. Youll have to go back to partner selection. Members of the current project team will see it as disregard for
the work theyve already done. But it is decisive action. Might have the
shakeup effect youre looking for. Who in IT?
I was thinking you or Tyra should take charge of it.
Tyra would be ideal, said Ruben.
Barton grinned. Under IT guidance, with business involvement, we
can make sure the hard work of dividing the project into smaller projects gets done. Im not criticizing the work already completed, not by
our people anyway, just acknowledging the diffi culty of the task and the
need for a careful approach. But I have no intention of signing off on
a huge dollar amount. Were going to do this thing in smaller pieces.
That is hard work, said Ruben. And you know, you might fi nd you
dont like the alternatives to NetiFects a lot better. They all come with
baggage and complications. The references we collected on NetiFects
were very good. Their tech lead, Ash Srinivasa, is very, very good.
Barton felt doubt seeping into his psyche, then banished it. The
bottom line for me is that weve paid them over $3 million and weve
got little to show for it yet.
Theyd say this was partly our fault, countered Ruben. Id probably
agree.
Nevertheless, its their problem as our partner. And what were
doing now isnt working. Barton stood. Im going to let you get to
your meeting.
Do you need anything from me as you consider this decision?
asked Ruben.
You just gave it to me. I wanted to bounce this off of you, get your
reaction.
Youve got it.
Thanks, said Barton. “Especially for the honest pushback. I hope
youll keep doing that.
The Runaway Project
119
Its in my nature, said Ruben.
Barton grinned. So Ive noticed.
Tuesday, May 1, 2:16 PM . . .
Ive decided, Barton said, providing his update on the IR project to
Carl Williams and the rest of the leadership team, to fi re our systems
consultants. Williams looked surprised but vaguely pleased, Barton
thought. Most of the others around the table were not surprised.
Palmer had already mentioned it to a couple of them, and the news had
traveled. Barton didnt mind. It wasnt his intention to surprise them.
He explained that there might be some cost to extracting IVK from
the relationship with NetiFects and that the timetable for the project
would need to be revisited. Williams didnt object. But, said Barton,
we will not be paying even one more hefty retainer, and Ill put a stop
to billable work right away. There will be no more $3 million and no
results to show for it.
Williams smiled. The others nodded in agreement. That guy is a
damn good manager , Barton thought their expressions seemed to say.
Whats next on the agenda? Williams asked.
REFLECTION
What root causes led to the need for a major infrastructure replacement project?
What makes such projects so difficult?
Do you agree with Bartons decision to terminate the agreement with NetiFects?
Can projects like the IR project be avoided?
What are the advantages of all-at-once versus piece-by-piece projects? Which
would you prefer?
The Road of Trials
120
Excerpt from Consultants Report
The immediate need to begin redesigning middle and back-end
systems was apparent in many ways during our assessment. Many business and IT staff members stated their conviction that this must be
done soon. Some of the reasons to initiate this project include:
1. The large and increasing number of kludges in the current middle and back-end systems necessary to support diversifi cation of
product types and client services creates increasing risks of service outages as the complexity of these duct tape and bailing
wire schemes grows.
2. Integration between middle and back-end systems is not suffi –
cient; in particular, fi nancial systems are not well integrated with
loan systems, which results in inadequate fi nancial controls and
vulnerability to internal security threats.
3. Data structures and lack of real-time functionality in middle and
back-end systems inadequately support fl exible pricing, reporting, and the need for management metrics (e.g., queue management in credit decisions, marketing analysis by product). The
problem will grow worse as the companys need for such reports
and metrics grows.
4. These middle and back-end systems are inferior in important
ways to those of competitors; an absence of imaging capability is
one important shortcoming of systems relative to competitors.
Such shortcomings seem inconsistent with IVKs strategy, which
proposes outcompeting rivals by having superior capabilities that
result from the companys focus on particular market segments.
This project is not something that can be delegated to the IT department. The projects impact on the business will be such that business
people must take a lead role. We suggest that you take four to six key
business people representing the major business areas at IVK, team
them with an equal number of senior IT staff , and make this project their
primary responsibility. These should be people you cant imagine taking
out of their current roles in the organization. You will need to rely on
The Runaway Project
121
others within the business areas to step up into important business
roles. Resist the urge to return these people to their non-project-related
roles to deal with short-term crises. External consultants will probably
also be needed as members of your team, to provide expertise and additional resources during implementation.
Within this team, make sure responsibilities for project tasks are
shared. Business staff should share responsibility for technical tasks, and
technical staff should do the same for business tasks. Assign some business tasks to IT staff members and some technical tasks to business staff
members. By the end of this project, the business people will have received a formidable technical education, and the IT people will similarly
have a much deeper appreciation of business issues. If other such projects we have seen are any guide, this project will be an important professional development experience for project team members; the
understanding of the business and its IT systems that staff members will
gain on this project will continue to be valuable to the company for
many years.
We attach to this report a Harvard Business School case on a major
systems replacement project at Cisco Systems, which was done at a
time when that company was growing very rapidly. a
Many of the actions Cisco took to assure the success of its project should be adopted
by IVK. Specifi cally, success factors at Cisco included:
Assigning best people to the project (If theyre easy to give up,
theyre the wrong people.)
Business people involved, not just IT
Top management attention and commitment (successful project
completion was one of the CEOs top seven objectives for the
year; all executive bonuses depended on successful project
completion)
Iterative, adaptive approach that recognized the importance of
developing prototypes or else manually walking through how
the system would work in great detail, to discover problems that
could not be foreseen any other way, and to make midcourse
adjustments
The Road of Trials
122
Minimizing the changes to purchased packages where possible
Speedy implementation (the project was not career diverting for
business staff )
Strong vendor relationships
Project steering committee that also included senior executive
members from vendors; excellent high-level business contacts
between Cisco and vendor executives
This project will be diffi cult, and you will need to plan to make
changes and adjustments throughout its life span. It probably cannot
be completed before your peak volume period next year, so you will
have to simultaneously take actions to limp through another highgrowth year before this new infrastructure is in place. We believe the
time to begin this project is now; it will be diffi cult now, but it might be
impossible later. You may get through one more year with the current
systems, but we do not think you will make it through two more years.
a. Robert D. Austin, Richard L. Nolan, and Mark Cotteleer, Cisco Systems, Inc.: Implementing ERP,
Harvard Business School Case no. 699-022 (Boston: Harvard Business School Publishing, 2002).
123
chapter eight
IT Priorities
Wednesday, May 2, 1:30 PM . . .
Once again, Barton found himself meeting with Gary Geisler. The most
recent leadership team meeting had included a discussion of the companys approach to allocating resources and maximizing return. Each
department, the team had decided, would assess its current approach
to resource allocation and propose improvements to increase return on
investment. In IT, this meant understanding and improving processes
for fi guring out which projects deserved investmentwhich required
that Barton again dive into the numbers with Geisler.
But Barton had something else on his mind as the meeting began.
Hed just come from lunch with Paul Fenton, whose large and important Infrastructure and Operations domain included IT security.
Fenton had mentioned a concern that the notorious John Cho had
expressed. Hed launched into the problem as if Barton knew about
this issue already, but Barton didnt remember discussing it.
I hate to bring this back up, Fenton said, but Cho is pretty concerned about it. Hes seen some unusual activity on the intrusion
detection logs. I dont want to be unduly alarmist. John thinks its most
likely nothing important.
Cant he tell for sure?
Fenton sighed, shook his head. Its not that easy. Youre looking
at huge streams of transaction data and trying to notice systematic
The Road of Trials
124
irregularities. Most things that you see, that set off intrusion detection
alarms, turn out to be false alarmsperfectly normal, explainable activity that we are seeing for the fi rst time in the immense complexity of
packet fl aws around the network. A misconfi gured router, or one that
has a slight but functionally inconsequential problem arising from the
manufacturers design, can generate what might look like odd traffi c
patterns until you understand it. And theres a lot more of that kind of
thing going on than we have time to explain. You get a feel for it, what
to worry about. Chos the guy on this; hes got the radar.
So he doesnt think something bad is happening? Or he does ?
He thinks its unlikely, but possible.
If its happening, whats happening?
An intrusion, maybe. Someone wandering around in our data thats
supposed to be secure. Possibly customer data.
That would be bad, said Barton. What can we do?
Fenton seemed hesitant. Thats why I said I hated to bring it up
again. We can close those security holes Cho is most worried about
with an upgrade project.
Why dont we close all the security holes?
Fenton smiled patiently. Its not possible to be sure that you have
no security weaknesses. Or, rather, it would require an infi nite amount
of expenditure. So we target the high-likelihood or high-consequence
holes fi rst, and work our way down the list.
Sounds reasonable. So lets do this one.
Thats just it, said Fenton, weve tried to get it funded twice now,
without success. Cho and I were talking this morning and thought
maybe you should decide whether you want to take action on it. As the
new CIO. Davies never could make much headway.
Why not?
Fenton looked uncomfortable. Im not sure, he said. Barton
thought he was leaving something unsaid. Maybe he didnt want to say
anything bad about Davies.
Who would know?
Geisler probably has the most complete picture.
Returning his thoughts to the present meeting with Geisler, Barton
started their conversation with Fentons security issue.
IT Priorities
125
What can we do about this, Gary? Barton asked Geisler. If Cho
and Fenton are worried, Id like to get this project done.
Now Geisler looked uncomfortable. What was going on? Nevertheless, Geisler had a suggestion.
We could go to the slush fund for it, he said.
Slush fund? asked Barton, not smiling.
Geisler stumbled forward: We have a few slush funds. For when we
cant get an important project approved. Accounting lets us bill back
operating expenses, but when it comes to incremental, project-based
stuff that we need to do within IT, we have to fi gure out a way to sneak
that into the overhead chargeback. Its not a lot of money. We like to
keep it in reserve for crises, but there might be enough to make some
progress on Chos project.
Why cant we get our projects through the same decision processes
we use for business unit projects?
We can, sometimes, but we have trouble getting some projects approved. Especially the deeply technical ones that dont provide direct
customer benefi ts. Chos project is a preventive maintenance thing, as
I understand it. No direct benefi t, just prevention of future, hypothetical harm. It was in the proposed project list; it just didnt get funding.
That sounds nuts, offered Barton. Didnt they understand what
was at stake?
Geisler looked down at his binder, tabbed it open to a particular
section then traced down the page with his forefi nger. Okay, here we
go. Network consolidation. Back a couple of years, when we merged
with Peoples, we kind of just glued their network to ours. They used
a different technology, and we could get the two to interoperate, but
maintaining bothas I understand itexposes us to additional risks.
We put this project through the general project-approval process for
two years in a row, and each time it got killed.
So somebody thought doing this was not as important as the things
that we did fund? asked Barton. He often attended the last round of
those prioritization meetings, and he recalled being impatient with the
number of projects that seemed to be about technology for technologys sake. Thats one interpretation, said Geisler. But I think Davies,
and especially John Choyou know John, right?
The Road of Trials
126
Purple hair, skull T-shirts, security guy, yes.
Rightwell, John thinks theres a security hole in the technology
that Peoples was using, so hes worried about it. But its more a professional opinion than a specifi c threat that were able to anticipate right
now. So the project aimed at plugging this hole keeps losing out when
we take it through the usual process.
Thats nonsense, said Barton. If theres a security risk, we ought
to be able to get it funded. Did Davies present it? I might have been at
the meeting.
Barton thought Geisler grew pale: Davies presented it. He laid out
the argument as John prepared it, but it was technical and didnt go
over very well. Security is a pretty technical area.
Did he make it clear that not doing the project put the company at
risk?
Geisler was defi nitely looking piqued. He squirmed: Yes, we thought
hed said that. Those of us who were there from IT.
We shouldnt have to use slush funds or play budget games to get a security risk addressed, opined Barton. In the future, Id like to take these
kinds of projects right into the process, state the case justifying them
clearly and forcefully, and face down anybody who refuses to see reality.
Geisler nodded weakly.
So what happened to this project? asked Barton.
Which time?
I dont care, said Barton, yielding to anger. The last time.
Well . . . The project had vocal and infl uential detractors. Another
project with a favorable and more certain customer impact got funded
instead. Thats what it came down to.
Who argued against this project? It just seems like common sense
to me.
Geisler said nothing. Barton waited, stern-faced.
Well, Geisler said, indignation slipping into his voice, as I remember it . . . you were the biggest critic of this project. One of your Loan
Operations projects was funded instead.
Barton contemplated this. He had no specifi c memory of the meeting, but he had often complained about the way IT presented its project proposals.
IT Priorities
127
What did I say? Barton asked.
You werent happy with the technical nature of the explanation.
You said they should come back when they could speak English. As I
recall it, the phrase you used to start the discussion of the project, right
after theyd presented their case was Habla ingls? It got a big laugh,
and we all knew then the project was toast.
Barton remembered. He and other business unit managers had
laughed about that line for days. Davies had fl ushed bright red and said
very little else in the meeting after that. Now Geislers recounting of
the events on that day made Bartons own face warm. It was an unaccustomed feeling for someone usually confi dent of being right about
most things. Embarrassment rarely penetrated Bartons self-assurance.
Geisler sat silently, carefully directing his line of sight into a corner
of the room.
Well, said Barton, recovering weakly, that was unfair of me.
Cho thought so. He almost left the company.
Oh, Barton said. I didnt know.
Geisler didnt answer but raised his eyebrows as if to say No kidding. Barton suddenly realized just how diplomatic Fenton had been
in their conversation about Chos security concerns.
Im guessing, said Barton, that Im probably not John Chos favorite person.
Geisler snorted: You could say that.
The choice of new CIO at IVK would not have been good news to
Cho. Barton would need to follow up on this. The company needed
John Cho. Yet another reason why this upgrade project would have to
be approved this time around.
Anyway, Barton said, pulling himself together, regaining command, we may need to change some of the ways were doing things
around here. Maybe we need to get better at presenting our cases to
justify IT projects.
Maybe, admitted Geisler.
Two objectives, said Barton, resolutely. First, I want to fi nd a way
to fund thisan above-board way, not involving slush funds. Second,
I want us to review the process we use to decide how to allocate out
IT budget dollars, how we decide what priorities to fund. And, as this
The Road of Trials
128
situation demonstrates, we need to improve the process. I want your
recommendations. Ill send out an e-mail to my direct reports too, asking for their thoughts.
Geisler was assiduously taking notes. Barton thought about asking
him to prepare a short write-up on what had gone wrong with this
particular infrastructure upgrade project, to use as a basis for getting
recommendations back from his IT managers. They would, Barton
suspected, provide richer advice in reaction to this case than to the
idea in the abstract. And the example offered Barton the opportunity
to demonstrate leadership. Hed admit that hed been wrong when hed
killed the project as head of Loan Operations.
It was a great idea, except for one thing: This was about security.
If something security-related ever happened, it might not be a great
idea to have evidence of dysfunctional past processes lying around, just
waiting to be discovered by plaintiffs lawyers in shareholder lawsuits.
Given the problems of the past few months involving the last CEO at
IVK, shareholder lawsuits were no longer an entirely distant issue. For
now, discussion of this particular security project would have to remain mostly spoken, not written down.
Friday, May 4, 7:35 PM . . .
Barton took another bite of his salade aux foies de volailles and sipped the
full-bodied, slightly bitter California red that the waiter had recommended.
The combination of fl avors added to his general sense of well-being.
Maggie, sitting across from him, was savoring a portobello mushroom
appetizer. Having her in town for the weekend put Barton in a positive
frame of mind, and the food and drink were fabulous, but it was not just
these things that pleased him. The week had gone well. Hed been CIO for
over a month, and the wheels had not yet fallen off. Also, he thought hed
reached an important decision. He broke one of his long-standing agreements with Maggienot to talk about work on Friday nightbecause he
wanted to get her thoughts on a decision he was near making.
Ive decided to ask Carl for control of the entire IT budget. Right
now, IT controls none of the budget; its all at the discretion of the
IT Priorities
129
business units. This has been causing problems. Weve neglected
important infrastructure investments. Ive got a business background.
I can see things from both sides of the fence. Ill make IT investment
decisions in full collaboration with the business units, but I want control. I want the fi nal say. Maggies pause before answering told him that
she had noted the breach of their no-talking-about-work policy. But
she could see that it was important to him.
Will the others go along?
I think I can convince Carl, and if he buys in, so will the other
members of the leadership team.
Will they really buy in, or will they just shut up because Carl agrees?
Some of both. But if I have control of the budget, I can fi x some
of the problems with the priority setting, and I can keep the IT staff
from getting jerked around when priorities change for bad reasons.
Right now, some of my guys get their priorities rearranged pretty much
weekly, if not more often. They cant get anything done. Its just thrashing. One week Project A is urgent, the next week its Project G. It needs
a steady hand.
Maggie considered it. You might be right. Do you see this as a permanent arrangement or a transitional one?
Barton hadnt really thought about that. Hed conceived the idea of
taking over the IT budget as a way of fi xing the immediate problems
with prioritization, like the problem Fenton and Cho had surfaced.
Barton wanted to protect the integrity of the process from the infl uence of the kind of problem that he had caused when hed been head of
Loan Operations. He had to admit, too, that he wanted to demonstrate,
mainly to John Cho but also to others, a willingness to reverse himself,
to do the right thing. Barton explained all this to Maggie.
So this is personal. Youre righting past wrongs.
Im not sure thats the main thing. Im pretty worried about the
security risk Cho has identifi ed. But yes, I suppose so. In my opinion,
my past actions in this matter hurt the company, and Id like to remedy
that. Besides that, I was a jerk. Im just sorry Davies isnt around anymore to hear my apology.
There are defi nite downsides to the action youre proposing. Have
you thought those through?
The Road of Trials
130
Barton smiled. I think I have, but thats why Im talking to you
about it. What dont you like about the idea, Maggie?
Just then the waiter arrived with their main courses. Barton polished off his salad and set the plate to one side so that the waiter could
place before him an elegant variation on the traditional steak au poivre .
Maggie had chosen roasted hen, which also looked really good. Barton
stuck with his red wine, but Maggie chose a new white to go with her
dish. By the time all was settled, Barton couldnt remember what hed
asked Maggie. Fortunately for him, she had not forgotten.
Theres not one best way, she began, between initial bites, at fi rst
confusing Barton, who did not realize she was back on the subject of IT
priorities, but what you are proposing runs counter to advice I sometimes give. I can think of objections on a number of levels, but the fi rst
has to do with what I like to call the one-neck-in-the-noose problem.
Barton laughed, almost choking. Whats that you call it?
Maggie didnt laugh. One neck in the noose, she repeated. Heres
the argument: To do a good job in IT, you need help from people in
the business units. Theyre the ones who know best how they want to
do things, how processes should work, what risks and reward tradeoffs theyre willing to make. Ideally, youd like them to work conscientiously until theyve understood all the alternatives, all the pluses and
minusesthen you could all come to agreement about what positions
youre taking, which risks youve agreed to accept, and which ones
youve decided to mitigate. In the example of your John Cho problem,
this hasnt happened. Ironically, in this case you were the one, in your
role as head of Loan Operations, who didnt do the conscientious work
to understand the trade-offs. But it could have been anyone. Organizations and managers are imperfect, and IT trade-off decisions can
be very hard to understand. So getting everybody to understand and
agree is usually an aspirationan idealnot always realizable in practical reality.
So far, said Barton, youre making the case in favor of my decision to take over control of the IT budget. I can conscientiously represent the business and IT point of view.
Except for one thing. If you get people to understand the trade-offs
and participate in decisions, then something goes wrongsay a risk
IT Priorities
131
you all decided to live with generates some serious consequences
then you are all in it together. You all decided. You took your chances,
placed your bets, and you lost. That hurts, but it hurts you all together.
Everyone had his or her neck in the noose and everyone can feel it
tightening.
You take over the IT budget, though, and youre effectively letting them take their necks out. Youre the one who makes the trade-off
decisions. When something goes wrong, youll be the one who feels the
noose tightening. You alone. They may feel something, but their reaction to their own pain will probably be to turn around and tighten the
noose around your neck.
Barton considered this. Maggie was right, he thought, and it annoyed
him. Up to a point. But if the alternative is not realizable, he asked, is
it a real alternative?
She shrugged. Maybe not. Ive seen it work fairly well and, more
often, very badly. Probably depends on your assessment of whats
possible within IVK.
So what would the alternative look like? Can you tell me what
youve seen other places?
Have your guywhats his name, Geisler? look up Volkswagen
of America for you. Hell fi nd it if he searches for Volkswagen America IT priorities. 1 But last I heard they didnt have everything working
right either. As I remember it, they put this very careful and logical
prioritization approach in place, and then everyone complained about
the investment decisions that resulted.
So, what, they set up some sort of a committee-based process?
Yes, thats basically it. IT facilitates the process, but the business
units decide the priorities. Its a consensus process. Even if you dont
love the outcome, you agree to stand by the results. All necks in the
noose.
Business units control all of IT spending?
Actually, no. I think in the Volkswagen system, IT retained some
portion of budget on their own discretion.
That in itself would help matters.
So maybe thats a less radical fi x to the current problem. The simplest summary I know of how this ought to work, in theory, is by a
The Road of Trials
132
bunch of business school professors. They argue that priority-setting
processes ought to have three basic characteristics.
First, the process ought to be owned by the business units, not the
IT department. Each business unit contributes a representative who
has decision-making authority. That at least starts to solve the necksin-the-noose problem. It keeps the IT department and the CIO from
being held solely responsible for outcomes that IT cant fully bring
about or prevent from happening. It matters a lot to the behavior of
managers in business units if they know their own necks are in the
noose. You take a very different attitude toward solving problems when
your neck is in there too.
Second, the process ought to exhibit extreme transparency of process and exaggerated visibility of decision consequences . The people in
the business units ought to be able to look into the process and see
clearly how it works, how decisions are arrived at. By implication,
I guess, they need to think it looks like a process that makes sense. It
probably means it has to be a reasonably simple process, and there cant
be any steps where it disappears mysteriously into the IT department.
No black boxes. The related idea, exaggerated visibility of decision consequences, means that you go out of your way to make it clear when
decisions have been made and what decisions have been made, and
the resource implications of those decisions. If youve agreed to move
Susanne to Project G from Project A, maybe you move a Post-it note
on a wall from one box to another. Things like that make it impossible
for anyone to credibly claim that they were not aware of a trade-off
decision. People cant selectively, conveniently, or politically remember
only what helps their own projects. You know the problem: I dont
remember agreeing that we would not work on Project A . . . and so on.
The ideal here would be to put all your current-state resource allocations up on a giant wall chart that everyone can understand. Everyone
can see all the time what everyone has agreed to. There it is, just look,
right on the wall. Of course, this gets a little complicated in larger companies with multiple locations.
Thirdand this is really just a way of addressing the primary issue
youve been raising, of meeting it head-onthe participants in the
process agree and are reminded to maintain some degree of continuity
IT Priorities
133
and within-project focus , to prevent thrashing. Every time the group is
tempted to shift people or money resources around to deal with the crisis du jour, they formally weigh the losses that will result from switching and from taking the resource off the project you are deciding to
give less precedence to.
Maggie fell silent and Barton let the silence remain. Now he was actually angry. She was talking sense, he knew that, but it unsettled his confi dence in a decision hed pretty much already made. And it all sounded
so . . . idealized. A bunch of business school professors, ivory-tower types.
Geez. And Maggie, as crazy about her as he was, well, she was a consultant . Not the same thing as a line manager in a real company. Not at all.
Barton took another bite of his steak and changed the subject. He
didnt want his inner seething to ruin the rest of their evening. There
was good reason for the policy that ruled out talking shop on Friday
nights, which they both inevitably realized every time they violated it.
Tuesday, May 8, 10:05 AM . . .
Geisler stuck his head in the doorway of Bartons offi ce and said,
Found something on the Volkswagen of America system for managing
priorities.
Barton waved him into the room. Give me the short version.
Its pretty interesting, said Geisler. An annual three-step process,
involves reps from all the business units in big workshops over a period
of a couple of months. The overall objective is to align IT spending
with the companys strategy.
Does it work?
Unclear. It seems really logical and reasonable, but there are lots of
complaints about it, mostly from people whose projects havent been
funded. Worth looking at in detail, though, as a possible model to play
around with.
Do you think their experiences are a good analogy to ours? Should
we model ourselves on an auto company?
Good question. They arent really an auto company, more a carimporting sales and marketing company. They dont do manufacturing;
The Road of Trials
134
they leave that to the parent company. But they do have some unique
things going on. A lot of outsourcing of IT in their history, a lot of new
programs, a severely constrained IT budget.
Their process is an annual one?
Yes, seems to be. Must include some sort of ongoing element to
address when priorities shift during the year, but we dont have much
info on that.
Does it help them align IT activity and investment with strategy?
I think it might. One of the most interesting things about it is the
categories they use for projects. They categorize projects a few ways. In
terms of how they justify the investment, for example, they use three
categories. One is what wed call mandatory, meaning we have to do
it because of legislation or something. Though they seem to make use
of this category for infrastructure upgrades the CIO thinks are really
important, things like our John Cho issue.
So the CIO has some discretionary budget.
In effect. The business units decide most priorities, but theres defi –
nitely a category of projects, a pool of funds, that the CIO controls.
Labeled mandatory, maybe not quite accurately.
Maybe thats the deal they strike with the devil to get some discretionary budget for the IT department. Maybe inaccurate, but maybe
also very practical.
Here, again, was the alternative that Maggie had suggested. Rather
than ask them for total control of the IT budget, he could just ask for
total control of a portion of it and leave the rest to the current, though
likely to be modifi ed, process.
Geisler was speaking again: Their other categories, one of them is
just ROIprojects that have high ROI. But they also have a category
they call option-creating investment, which I fi nd pretty interesting.
OCI projects are those that dont necessarily have high ROI, because
some of the benefi ts are too speculative or too much in the future.
But OCI investments create possibilities for future benefi cial projects.
Having this category seems to imply that if you just use mandatory and
ROI, you wont fund big-picture vision projects.
I think thats true, said Barton. Most good executives would agree, in
my opinion. You want to know the ROI. You want to see the calculation.
IT Priorities
135
But its not the only factor in how you should decide what to invest in.
Its the way we want to do business is a pretty good reason sometimes.
Yeah. Well, youll like some other stuff I found too, then, continued Geisler. I also encountered a lot of material on a related problem
in product development, about what they call aggregate project planning.* Wed call it something more like application portfolio management. Same thing, though. Turns out that its pretty well accepted in
product development circles that if you use only ROI types of project
justifi cation to decide where to invest, youll end up mostly doing incremental extensions to existing products, never going for breakthroughs
or investments in new categories. One thing I read described how a
review of the project portfolio at one company, whose stated strategy
was to always be the product technology leader, revealed that it had not
invested in a project with potential to lead in product technology in
over three years. Its investments in product development had drifted
out of sync with its intended strategy. I thought that seemed pretty
similar to what IT gets accused of all the time.
Barton nodded. So the Volkswagen of America process takes a look
at what they are spending in each category and asks a high-level question: Is this well aligned with our stated strategy?
Well, its not as explicit as that in the account I read, but it would
allow them to do that.
That would give you a check on whether your process, working
through the details, has somehow, for some reason, drifted off course.
A nice feature.
Youve got some stuff for me to read?
Geisler handed over a thin sheaf of papers. I tried to limit it to just
the best stuff.
Thanks. Lets talk more about this later, after Ive had a chance to
digest it. Im thinking about proposing some changes soon. Well have
to hammer those out.
As Geisler exited, Barton reached for his pen and went to the whiteboard. He made a note: IT spending should be aligned with IVK
*See Excerpts from Materials on Prioritization of R&D (Not IT) Projects at the end of
this chapter.
The Road of Trials
136
strategy. He followed this statement with Geislers priority categories:
Mandatory (i.e., security), ROI (incremental), and OCI (breakthrough).
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1
$75.12 $30.72 31.90
4.77B 1.95B 2.03B
+
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Barton paced around his offi ce a few times, then sat. He grabbed a
blank notepad on his desk and sketched out what he now thought were
three alternative proposals he could make to the leadership team.
1. He could propose that he take over the entire IT budget. Williams
would go for this, he thought. Barton was well positioned to
represent the interests of both the business and the IT department. Also, having declared Barton the fi xer, Williams would be
inclined to give him plenty of rope to do the fi xing. But that rope
could also, as Maggie had suggested, become a noose with only
his neck in it.
IT Priorities
137
2. He could propose that before any of the prioritizing or IT
resource allocation take place that he get a percentage of the IT
budgetexactly what percentage could be discussedto keep
under his discretion. This might avoid some of the problems
Maggie described, but it struck Barton as sort of an incremental
solution, a more timid move.
3. He could try to fi x the current committee-based system. This
would be in keeping with the theoretical ideal that Maggie had
described. But it also described fairly well the dysfunctional
arrangement that was the status quo. If the second option was
timid, this one bordered on doing nothing. Barton worried that
there was insuffi cient splash in this option to motivate any real
changes.
There was a leadership team meeting that afternoon, and on Thursday, two days later. Barton wondered when he should bring this up.
Thursday, May 10, 1:45 PM . . .
Im not so sure I like this idea, said Niels Hansen, the new head of
Loan Operations. Barton had just made his case: he wanted complete
control of the IT budget. Despite Maggies concerns, despite the risks,
which he fully acknowledged, he wanted to move fast. The pivotal
issue, the thing that decided it for Barton: the urgency of the network
consolidation project. Security was nothing to mess around with.
With control of the budget, he could begin Chos upgrade
immediately.
As he explained to his peers and Carl Williams, this would be only
temporaryto get some things done quickly. Later, hed propose a
better and more inclusive framework for investment decisions and
bring it back to them for discussion. But at the moment, he was asking
for total control. Some of his peers didnt like it, but Barton was watching Williams, who was buying it. Barton would get what he wanted, for
better or worse . . .
The Road of Trials
138
REFLECTION
What processes need to be in place to effectively establish IT project priorities?
Is assigning control of IT budgets to user departments an effective mechanism
to establish IT priorities? Who should control the IT budget?
Given his disagreement with Maggie and his peers, do you think Barton is wise
to ask for IT budget control? What consequences (positive or negative) do you
foresee?
IT Priorities
139
Excerpts from Materials on Prioritization of R&D (Not
IT) Projects
Step 1: Strategic Goals & Objectives
The R&D portfoliocreation process must start with a clear
articulation of the companys overall strategy:
What customer/market segments?
What distinctive advantage are you seeking in your products or
services?
The strategy should also inform you about the overall
investments in R&D:
R&D investment is set as a percentage of sales
Amount varies by industry and by market goals of fi rm
Step 2: Classifi cation of Project Types
There are diff erent types of projects, for example:
Major breakthrough
New product or service line
Refi nement/enhancement of an existing product or service
Classifi cation allows you to think about your project opportunities in a strategic manner
Step 3: Create an Aggregate Project Plan
Using your strategy as a guide, determine the percentage of
resources to allocate across project types:
Breakthroughs: %
Platforms: %
Derivatives: %
The Road of Trials
140
Given your total R&D budget, estimate the maximum number of
projects you can undertake within each category:
Need to have a handle on resource requirements for each type
of project
Step 4: Commit to Specifi c Projects
Compare project proposals within categoriesnot across:
Platform ideas compete with other platforms
Derivative project ideas compete with other derivatives
Use diff erent criteria across categories:
Derivative: ROI or NPV
Platform: impact on future options in the market
Breakthrough: longer term capabilities/options
Senior managements job is to actively manage the process:
Shape the menu of choices, dont just passively select whats
presented
Source: These notes are adapted from teaching case fi les in the Technology and Operations
Management department at Harvard Business School and from the original material in
Revolutionizing Product Development: Quantum Leaps in Speed, Effi ciency, and Quality , by
Stephen C. Wheelwright and Kim B. Clark (New York: The Free Press, 1992).
141
chapter nine
IT and the Board of
Directors
Tuesday, June 12, 10:53 AM . . .
Im not sure about the order weve got these in, said Raj Juvvani.
Maybe we should list Underinvestment in IT fi rst. That way we hit
them with the biggest, most important thing at the outset.
I disagree, said Tyra Gordon. Thatd be like starting by accusing
them of causing IT diffi cultiesits their fault because we havent spent
enough.
It kind of is their fault we havent spent enough on IT, countered
Juvvani.
Yes, conceded Gordon, but that doesnt mean we should start
there. Itd be like shoving a tin cup under their noses in our fi rst moments with them.
Juvvani considered this. Maybe youre right, he said.
Barton had convened his direct reports to fi nalize the presentation
to the board of directors scheduled for Thursday afternoon. Every
member of this group had been involved in creating the presentation. Barton was pleased by how his team had come together. Theyd
achieved the quality of interaction to which Barton had aspired in that
fi rst off-site meeting in March, the one that theyd all so fi ercely resisted
The Road of Trials
142
attending without their various technical sidekicks. Now with just the
fi ve of themBarton, Gordon, Fenton, Juvvani, and Ruben, plus Gary
Geislerit all seemed completely natural.
They had designed a presentation in fi ve sections:*
1. History of IT at IVKInformal management
2. Moving to more disciplined management
3. Results already attained
4. Strengths and weaknesses
5. Opportunities and risks
Barton would review the slides with Carl Williams after lunch, so
they were down to fi nal touches. Williams would probably make suggestions that would send them scrambling, but Barton wasnt worried.
Theyd handle it. The whole thing was coming together. Hed be very
surprised if Williams spotted any egregious shortcomings.
Bartons thinking had moved on, from the detailed content of presentation slides to the big picture, the overriding themes he wanted to
emphasize during the presentation and subsequent discussion with
board members. He had four issues in mind.
First, he wanted to make it clear that management of the department
in the past had been too informal. This problem was common throughout the company, a consequence of rapid growth from a small fi rm to a
large fi rm, a side effect of success in the marketplace. The entrepreneurial
inclinations of the current set of fi rm managers, their tendencies to act as
if the fi rm were much smaller, offered benefi ts: agility, can-do attitudes,
and willingness to innovate, for example. But informality was also a
source of risk. Big companies needed more coordination, more management systems, andespeciallymore controls than small companies.
This was particularly true in IT. Barton had begun instituting procedures,
systems, and controls that would reduce risk without sacrifi cing agility
or innovativeness. Some of these changes were simple, things no one had
gotten around to in the past; based on his knowledge of Loan Operations
*See Slides for the Board of Directors Presentation at the end of this chapter.
IT and the Board of Directors
143
and using his new vantage as CIO, for example, Barton had instituted
better integrated procedures between loan origination and fi nance, to
make sure checks and fund transfers could not be initiated without
proper approvals. Building those controls into IT systems, by better integrating the systems that supported each activity, would take more time,
but Barton had launched an effort looking into that and other opportunities to better enforce fi nancial procedures. Hed also ordered the implementation of an array of new metrics, each of which gave managers fresh
insights into IVK operations and performance.
Second, Barton needed to convey that the IT infrastructure had not
received the attention and investment it required. Since the companys
revenues had leveled off in recent months and Williams had come on
board as a turnaround CEO, it was inevitable that everyone would be
asked to tighten belts a few notches. Barton wanted to express willingness to do what was right for the company, but also to point out that
IT had some very important projects under way that could not stop on
a dime without wasting the already considerable investment in them.
Furthermore, it had become clear to Barton that an even bigger project
was loomingthe back-end infrastructure replacementso investment would need to continue. Without new investments, the company
would eventually face unacceptable levels of risk. He wanted to be sure
the board understood that trade-off.
Which led to the third major theme: governance. 1 Barton wanted
the board and the senior management team of the company more
deeply involved in decision making about IT matters, especially where
there were opportunity and cost, or risk-reduction and cost, trade-offs.
He wanted the responsibility for such trade-offs to be borne jointly by
the business units and the IT department, not just left to the techies.
To accomplish this, Barton thought, the attitude of joint responsibility
had to come from the very highest levels. Hed be asking the board to
take greater responsibility and become more involved in IT decisions.
Finally, Barton wanted to emphasize a strategic partnership role for
the IT area within IVK. He had become aware that many of his senior
management colleagues would be most delighted if they never had to
deal with ITif IT would stay in the basement where it belonged.
Barton himself remembered feeling that way when he was head of Loan
The Road of Trials
144
Operations, but this didnt keep him from being a little surprised that
his peers seemed to continue to think this way even after he obviously
a business guytook over in IT. Most managers wanted IT to listen to
ideas from the business units, then go make them happen. Barton imagined a more involved role for ITcoming up with ideas, helping close
sales. He wanted IT to contribute to revenue growth. IT could, he believed, be part of how the company recovered its aggressive growth trajectory. In initial conversations with some of his peers, they had resisted
the idea. The sales organization in particular hated the idea of having IT
participate in client meetings. Given such resistance, this role for IT also
needed the active and visible support of the board of directors.
It was a lot to accomplish in one thirty-minute presentation. Barton
knew getting these themes across would likely be a long-term effort, especially the last one. He had been disappointed to see, when the agenda
for the board meeting had been distributed, that his presentation came
at the end. If the meeting was running long, as was likely, he might have
even less than thirty minutes to get his points across, so he wanted to be
prepared for that possibility too.
I think this is getting pretty good, said Ruben. He turned and
spoke directly to Barton. Do you want to keep refi ning, or should we
get back together tomorrow, after youve spoken to Carl?
Or this afternoon, said Juvvani. The others all nodded. Barton
smiled. Yes, lets call it quits for the moment. Ill let you know what Carl
says, and well get back on this tomorrow. Keep your calendars fl exible.
The feeling of confi dence in the room was palpable. The members
of his team were proud of their presentation. They were proud of what
it said, of the plans it expressed. Confi dence was a feeling Barton had
not encountered in his direct reports when hed fi rst taken over as CIO.
Now that had changed, and he liked it.
Thursday, June 14, 4:47 PM . . .
This is outstanding, just outstanding, said Francesco Carraro, an IVK
board member. Barton had just completed his presentationa compressed version, because they had indeed been short of time at the end
IT and the Board of Directors
145
of the meeting. He looked around the room and saw signs of agreement.
Sally Lee, sitting next to Carraro, was beaming and nodding. The two
of them, both outside directors, tended to have a lot to say in board
meetings. Lees reputation, in particular, was enormously infl uential.
But Carraro, as it turned out, was the most IT-savvy board member.
Barton had been surprised by the extent of his past experience in IT.
Carraro had served as a CIO once, and had been a COO responsible for
IT in another company. When both of these people were nodding after
your IT presentation, things were going well indeed. Williams, at the
far end of the conference table, wore an expression that Barton could
not quite read. But there was no time to dwell on that; the questions
and suggestions came rapid-fi re.
Carraro went fi rst: I have some examples of controls, procedures,
and metrics that Id like to send to you, he said. From the looks of
what youve shown us here, theyll probably not add much. Its clear
to me that you plan to go far beyond my old organization, but maybe
there will be something helpful in there.
Sounds great, said Barton. Please send them to me?
As soon as I get back to the offi ce, said Carraro. Barton caught a
glimpse of an oddly strained look from Williams. Lets also exchange
some thoughts on how you can accomplish some of your governance
objectives and get your area more focused on innovation.
Terrifi c, said Barton, now defi nitely picking up a disconcerted vibe
from Williams, but seeing no other appropriate response to Carraros
offer.
Carraro turned to the rest of the board: I suggest we set up a committee at the board level that would focus on IT governance. Itll help
with a lot of the objectives weve heard this afternoon. Itll also help us
control the risk associated with the current state of the companys IT
infrastructure. Boards can potentially face huge liabilities from lack of
involvement in IT. In the future, I dont know much about IT, will be
no better a defense against criticism of a board of directors than I dont
know much about accounting.
Can you say more, Lee asked Barton, about the risks related to IT?
Barton nodded, Ill try. Its hard to be very specifi c, because the risks
are largely a function of the evolved complexity of the infrastructure.
The Road of Trials
146
You cant make any system as complex as an IT infrastructure
completely bulletproof, not without infi nite investment. The problem
is not any single factor you can easily point to, its the emergent result
of countless incremental and individually harmless decisions. A decision to take a shortcut in how a program accesses a database, to make
response time better after the customer service department hits a new
peak processing week. A decision to leave until later standardization
on a particular networking technology, to glue two network segments
together into a workable kludge, rather than to do the design work, buy
some new equipment, and make it right. We get away with these things
all the time, but over time they add up to risk.
Carraro was nodding: Some of these things look like housekeeping
items. Investments to reduce the complexity dont get made because
they are hard to justify in terms of customer benefi ts.
IT risk, Barton added, is mostly invisible to managersand board
membersuntil the you-know-what really hits the fan.
Which is why we need to be more involved, why we need a committee for IT oversight, said Carraro.
Barton could see, from his vantage at the front of the room, that
board members who had just moments earlier followed Carraro
eagerly, now seemed less certain. Probably they were imagining being
asked to serve on a board-level IT Oversight committee. Probably
they were having a reaction to that suggestion not unlike Bartons reaction to being chosen as the new CIO. Theyd have to get over it, Barton
thought, just as he had. But it might, he knew, take them a while. And
Carraro, Barton could see, had overplayed his hand.
Lets put it on the agenda for a future meeting, proposed Williams.
Board members other than Carraro leapt aboard this lifeboat, nodding
emphatically, glancing at watches. Weve just about run out of time
here, and many people have other places they need to be.
Barton nodded and began collecting his things. Overall, the presentation had been a spectacular success . Im on a roll , he thought to
himself. Cant wait to tell my team .
The meeting began to break up, fragmenting into separate
conversations. Some people left right away, rushing off to the airport
or other engagements. Carraro stopped to shake Bartons hand before
IT and the Board of Directors
147
he departed. In the course of a brief chat, Carraro proposed that the
two of them should have lunch sometime, an idea Barton quite liked.
They parted company after agreeing to exchange messages on several
more subjects. Barton had not counted on having such a strong ally on
the board, but he could see only good in it.
Moments later, as Barton turned to leave the room, Carl Williams
stepped away from a conversation he was in to whisper: Great job.
Stop by my offi ce before you leave today, I want to talk briefl y. Barton nodded, and Williams ducked back into the conversation hed been
involved in before. Hmmm , thought Barton. Guess well fi nd out what
was bothering him during the meeting.
Williams had provided almost no feedback on the presentation
slides in his meeting with Barton on Tuesday afternoon. But now he
was clearly stirred up about something. Barton would fi nd out what it
was soon enough.
Thursday, June 14, 5:38 PM . . .
Barton stuck his head through the doorway to Williamss offi ce. You
wanted to see me, Carl?
Williams looked up from something hed been reading. Yes, Jim,
come in. Williams stayed in his command chair, behind the enormous
desk, and motioned Barton into a chair opposite. This was unusual.
Williams had always used the table in the room for past conversations
with Barton. Moving to the table said, Lets talk as equals. Remaining
behind the desk said, Im the boss, and you work for me. Barton tried
not to think too much into this choice, but it was hard not to notice
the departure from a past norm. Maybe Carl was simply tired. A board
meeting could be stressful.
You did a great job in there, said Williams.
Thanks, Carl. I had a lot of help getting ready, of course.
Understood. Youre happy with your team, then?
Yes, theyre very good, actually. I had anticipated needing to replace
one or two of my direct reports, maybe reorg the department. But that
hasnt seemed necessary. Not yet, anyway. We have some holes and
The Road of Trials
148
problems further down in the department, but with your help and a
few key hires, well deal with those eventually.
Thats great, said Williams, not seeming to have even heard, transitioning to what was really on his mind: I want to talk about how we
manage Carraro.
Manage him? said Barton.
Yes, hes very enthusiastic, but we need to make sure he understands
that the CIO job is yours. I dont want him to complicate things for
you.
I appreciate that, Carl. I hope we can make him a supporter and ally
more than someone who is inclined to interfere.
Williams nodded but frowned. Barton realized that he was not
understanding something going on here, something important to
the CEO.
Well, to make sure he doesnt insert himself too profoundly, Id like
you to include me in any correspondence or conversations between the
two of you. Im sure youd be inclined to do this anyway, but I wanted
to make certain. Ive turned around several fi rms, as you know, and my
experiences have made me understand how important it is to keep a
handle on relationships with the board.
Ahhh , Barton thought. Of course. Hes worried about being left out of
the loop. Hes worried that Carraro and I seemed to hit it off too well . The
odd looks in the meeting, they were about control of communication
with the board. The presentation had gone so well that Williams was
feeling threatened.
As Barton thought it through, the pieces fell into place. In the meetings to reshuffl e the management team, Barton had been discussed as
a possible COO. Now he was doing spectacularly well with a diffi cult
assignment as CIO. This made him a potential rival to Williams. Barton
felt that he had been dense not to see this coming.
Carl, Ill make absolutely sure you stay briefed on every communication I have with any board member. If Carraro sends me something
and doesnt copy you, Ill send you a copy. And if I have lunch with
himhe invited me after the meeting todayIll brief you on it right
away.
He invited you to lunch? asked Williams. But he seemed reassured.
IT and the Board of Directors
149
Yes, but who knows if it will even happen.
How about if we set it up through my offi ce?
Thatd be ideal, agreed Barton.
Well strategize together before, about what we want to accomplish.
And we can debrief after.
Sounds perfect, Carl.
Great. Thanks Jim. Like I said, great job out there today.
Thanks. Barton stood and exited, contemplating this new complexity in his management situation. Hed been so focused on the IT
department that he had missed this important dynamic with Williams.
Going forward, hed make a point of thinking much more about his
relationship with the CEO. It was fl attering to realize that Williams considered him a rival at some level, but there was also immense danger in
this factdanger that would need Bartons attention.
REFLECTION
Why do you think the IT presentation at the board meeting was scheduled as
the last agenda item and given only thirty minutes?
What are the board of directors responsibilities with respect to IT oversight?
Why do you think they seemed eager to delay forming the IT Oversight
committee until the next meeting?
What should Barton do about managing Carraro? Managing Williams?
How is Barton doing after almost three months as IVKs CIO? What is your
assessment of his performance?
The Road of Trials
150
Slides for the Board of Directors Presentation
Historical BackgroundIT at IVK
Informal and ad hocfew plans, policies, procedures, controls,
or metrics
No formal IT planning or priority-setting process
Ad hoc systems for tracking progress against plans
Invent-as-you-go policies, even in areas such as information security
(no high-level framework or review, no senior management involvement)
No mandatory operating procedures
Few operational metrics or standardized reporting
Underinvestment in IT
Industry benchmark of 9% of revenue spent on IT
IVK has spent less, sometimes much less (although current spend is
roughly consistent with benchmark)
Cumulative effect of underinvestment: pieced-together systems
IT underserving clients and business needs
IT has been internally focused with no external client interaction
Projects not delivered, promises not kept, delays have had customer
impacts
Historical projects on-time-delivery rate: 3540%
Moving to More Disciplined Management
World-class management systems and practices
Developing an IT planning process for aligning with and enabling business strategy
Revisiting IT governance practices, priority setting, and project portfolio
management
Implementing metrics for managerial transparency
Linking IT to competitive advantage
Leveraging Internet on several initiatives; many more opportunities
Developing a platform for mining our extensive data for customer benefit
Greater reliance on vendor platforms rather than in-house application
development to reduce time-to-market
Assuring IT performance
Building new infrastructure to ensure reliability and disaster recovery
Implementing capacity-planning discipline to forecast and lead demand,
thus supporting business growth
Implementing a technology vendormanagement process to assure that
we are getting value from vendor partners
Organizing and resourcing IT for success
Conducted staff review to identify staff capability, organizational needs,
and deficits
Considering reorganization to maximize ITs business responsiveness
and impact
Instituting procedures, better controls

IT and the Board of Directors
151
Results Already Attained
Defined an IT strategy and implemented major elements
Developed a formal IT strategy
Implemented a new project-prioritization process
Fired a nonperforming IT vendor
Delivered business results and earned client credibility
Improved project on time delivery (80+% in last three months)
Took concrete steps to improve communication and credibility with
business units
Gained control and mitigated immediate risks
Defined and implemented 25 controls, 50 tests, and 4 major operational
reviews
Achieved regulatory compliance in accordance with applicable legislation
Performed a penetration review with outside security experts and took
several steps to mitigate security risks
Conducting formal IT risk assessment, starting late this month
Strengths of the Current IT Organization
Alignment with organizational growth
Playing catch-up but able to hold our own
Will be hard to maintain without investments to follow through on current projects
Partnership with key clients
IT systems help lock in clients and provide differentiating benefits to
customers
In some cases, IT systems capabilities have produced additional revenue streams from clients (clients willing to pay for better IT systems
capability)
Much more potential to leverage IT for growth and additional revenues
Improved delivery, reliability, security
Project on-time delivery much improved (need to assure these results
are for real)
Availability monitored by system, average is 99+% (addressing issues
with a few laggards)
Peace of mind from security review with external experts

The Road of Trials
152
Weaknesses of the Current IT Organization
IVK underresourced in key areas
Network management
Information security
Project management
Key systems groaning under the strain of their own evolved
complexity
Need to reengineer entire back-end infrastructure
Key to further security risk reduction, operational complexity reduction,
long-term reliability, IT agility
Need many care and feeding investments with little or no direct customer impact (sometimes you have to replace the brake pads and the oil
in your car)
Opportunities
Continue to align IT with board and senior management
objectives
Enable strategy, business agility
Identify new ways of connecting with and retaining customers
IT capability as a deal closer in acquiring new business
Identify and/or execute acquisitions, partnerships, etc.
Streamline IT governance
Institute concise decision-making body
Make decisions quickly
Improve cycle time of project delivery
Plan and execute rapidly across all functions
Consolidate control of all technology
Reduce risk and cost
Improve reliability
Risks
Information security risk to reputation and competitive position
We have established formal policies, executed penetration tests, closed
known holes in our defenses
However, some risk remains
Can never be completely safe (without spending an infinite amount of
money)
Most serious risks arise from antiquated, evolved infrastructurecannot
be replaced/reengineered quickly
Unforeseen disasters
Natural disaster or human-precipitated catastrophe (e.g., 9/11)
Building out back-up plans to maintain operations without primary
business sites
Back-up and disaster recovery infrastructure in place, but need to make
a business decision about how much disruption the business can take
to practice disaster readiness and response

part three
The Heros
Ordeal

155
chapter ten
Crisis
Thursday, June 28, 9:24 AM . . .
Barton was enjoying an unusually slow morning, fi nishing an elegant
breakfast at the Hilton Midtown in Manhattan. He had come to New
Y ork for an early afternoon meeting with Wall Street analysts. That
Williams had chosen him for the meeting was a sign of just how well
things had been going lately for IVKand for Jim Barton, CIO. In
the past three weeks, IVKs stock price had begun to rise, lifting spirits throughout the company. Optimism percolated through the offi ces
and hallways. At the same time, Barton had been scoring victory after
victory. A recent all-hands IT department meeting had gone extremely
well; hed fi elded a few tough questions, but people seemed pleased with
his answers and the departments overall direction. Even John Cho had
nodded in response to some of Bartons remarks. His resolute actions
had also gained him the confi dence of the companys senior leadership.
In meetings of that group, Bartons views now swayed Williams more
readily than anyone elses. And why not? Here was a guy who knew the
IVK business inside and out and had apparently mastered the mysterious world of IT in just three months.
Sending Bartonformer Loan Operations VP, now chief IT guy
to New Y ork on the crest of a wave of recovery, Williams had explained,
sent exactly the right message. Under a new CEO, IVK had woken up to
The Heros Ordeal
156
a realization of its current size and the consequent need for a new style
of management. The company would mature into a grownup fi nancial
services fi rm. What had been a freewheeling, improvisational approach
to management would become more professional. Without sacrifi cing
organizational agility, the company would institute more disciplined
systems and controls. IT was, of course, key to achieving this. An expression Williams and Barton had begun to use in conversation to describe where they were headed captured their joint vision of the future:
a lean service factory. It was only natural that Barton would explain
all this to Wall Street.
Hed been sipping coffee, going over his notes, making some lastminute adjustments to the presentation for the meeting, when the call
came. A quick glance told him who the caller was: Bernie Ruben. Barton guessed that the call might be last-minute advice about how to
tweak the analyst presentation.
He was wrong.
Hi Bernie, whats up?
Hi Jim. Im afraid weve got a problem, and we felt we should get to
you with an update.
Is it something I need to change in the presentation?
Nothing like that. Were experiencing an outage this morning, for
about the last forty minutes. Customer Service is down. None of the
call center systems are working, and the website is locked up.
Oh, damn. I assume were executing recovery procedures?
Such as they are.
This confused Barton. Hed heard, time and time again, about the
call lists and emergency procedures that assured business continuity in
a crisis. What do you mean, Such as they are?
Sorry. Thats my cynicism coming through. The fact is, those procedures are somewhat out-of-date. I dont think we realized quite how
out-of-date until thirty minutes ago.
This made Barton angry. I wish youd fl ashed that cynicism a little
sooner. Ive been taking everyones word on this. I thought we were
prepared for an outage.
Ruben, hearing the tone of Bartons voice, pulled back. Were not
completely unprepared, just not as prepared as wed like to be. Weve got
Crisis
157
great people on it. But the truth is that outages happen, and they dont
always happen in a predictable way. Often, we have to wing it a bit.
And why are you calling to tell me? Rubens area had no operational
responsibilities, thus would be involved in an outage only peripherally.
Barton imagined his team voting on who the bearer of bad news would be.
Because everybody else is kind of busy, frankly, Ruben answered.
Fenton and Cho are right in the middle of this. Ripley is at the data
center, rebooting things. Juvvani and his team are trying to fi gure out
whats wrong with the Customer Service systems.
Cho? Do we think this might be some kind of security event?
I was coming to that. Ruben paused, as if to steel himself, before
continuing. It was very unlike Bernie, that pause, and it communicated
the gravity of the circumstances more than the words that followed it.
A bolt of panic stirred the eggs Benedict digesting in Bartons stomach.
Were receiving a continuous fl ow of e-mails at our Customer Service
address, continued Ruben, about three per second, each with no text
in the body of the message and a one-word subject line: Gotcha.
Gotcha?
Y es. Its like Gotcha, gotcha, gotcha, gotcha.
What the hell does that mean? Barton channeled his frustration
into an exasperated hand movement, which promptly toppled his coffee cup. Hot liquid fl owed from the table onto his lap.
We dont know, said Ruben. It could be a coincidence that Customer Service systems are down at the same time that we are receiving
these e-mails, but . . .
But it doesnt sound coincidental, does it? Barton stood, motioning to a waiter to indicate the spill and request his check.
No, conceded Ruben. This is the concern.
Bernie, I need more information, Barton said. I dont want to take
people off their urgent duties, but at some point in the next hour or so
I need a full update. Williams will get wind of this soon . . .
He has already . . .
. . . and I need to know what to tell him.
Ill pull a group together, and well call you. How about 10:3 0?
Barton looked at his watch. It was 9 :3 7 am. Make it 10:15. Theres no telling when Williams will call me. Ill hold off calling him until I hear more.
The Heros Ordeal
158
Im on it, said Ruben.
Barton ended the call. The waiter, rushing over to control the spill,
also perceived Bartons urgency. He hurried the check to Barton, who
quickly signed it and dashed out of the restaurant.
As Barton awaited the elevator that would take him to his fl oor,
another call came in, this one from Graham Wells, IVKs VP of Legal
Affairs and General Counsel.
Jim, we have got to reduce our legal exposure here. His voice was
an octave higher than usual.
What do you mean, Graham?
We have to take dramatic action, signal that we have done everything we can.
We are doing everything we can, Graham. The elevator arrived and
Barton got on it. He pushed the button for fl oor 3 9 . Two children got
on too, with a woman apparently their mother. To Bartons horror, the
two small boys pushed seven or eight buttons between the ground fl oor
and fl oor 3 9 before the woman could stop them. Barton immediately
stepped out of the elevator, waited for the door to close, then pushed
the up arrow again. All this time, Graham was speaking, not entirely
coherently. Barton tuned into him again:
Can we shut off power to the computer systems? Or cut the wires
that go to the Internet?
We could, Graham, but I doubt that would be smart.
Smart does not matter. What matters is what we can say in a
deposition.
The elevator arrived, but Barton moved away from it to sit in a nearby chair.
A deposition? What the hell are you talking about, Graham?
If this is a security incident, he continued, we may be looking
at legal implications. Customer lawsuits, shareholder lawsuits, government penalties, you name it.
Because our website is down? Its an outage, Graham, it happens.
Barton said. But even as he said this, his remaining optimism evaporated, consumed in the heat of Wellss fear.
If this is hackersif hackers are stealing customer datathis is
going to be bad .
Crisis
159
Thats a huge leap. We dont know that yet, Graham
That is why we need to take drastic action. Listen, I just got off the
phone with Carl. The last words he said to me were, Call Barton, make
sure he understands the legal ramifi cations. That is what I am trying
to do. And my offi cial legal opinion is that we should shut down every
computer in the place until we know what is happening. Can we turn
off power to the entire company? I will now call Carl back and let him
know that you and I have spoken.
Barton was shaken. Thanks, Graham, was all he could manage. An
elevator arrived and Barton dashed across the lobby to catch it.
Moments later he was back in his hotel room. His leg hurt where the
coffee had burned it. It was a little after 10 am, not quite fi fteen minutes
until hed get an update on the situation back at IVK. And he had no
idea what to do. There were a dozen people he badly wanted to call, but
all of them would be busy, and a call would only distract them. For a
moment, he considered a call to Maggie, then decided he didnt have
time before 10:15. He shed the ruined pants and ran cold water over the
coffee stain. For the analyst meeting, hed have to wear the pants hed
worn yesterday.
At precisely 10:06 am, another call came in. It was from Carl
Williams. Barton took a deep breath and answered it.
Jim Barton.
Damn it, Jim! Whats going on?
Were trying to fi gure that out, Carl, Barton said. He was trying
hard to meet Williamss anxiety, which he knew Graham Wells would
have stoked, with calm confi dence. Ive got a call with my team in . . .
he glanced at his watch . . . eight minutes to get the latest.
I just heard from Wells. He said you were nonresponsive.
Nonresponsive?
Look, never mind. Graham seems to have lost his mind. What do
we know?
Well, call center systems are down.
No kidding, those guys are just hanging out down there, chatting,
drinking coffee. Costing us money.
The website is not functioning. And were receiving suspicious
e-mails. There are many possible explanations for the fi rst two problems,
The Heros Ordeal
160
some of them not very sinister, but the e-mails add a troubling aspect
to the problem.
Makes it seem like someone might be doing this to us?
Thats the worry. Its speculation at this point, though.
How can they? Dont we have a fi rewall?
We do. But theres no such thing as impenetrable defenses.
I dont want to hear Williams controlled himself. I want an
update as soon as you get a better idea, sometime in the next thirty
minutes.
Okay, right after my call in . . . looking at his watch again, . . . six
minutes. Barton heard commotion in the background. Somebody was
talking to Williams.
Fine, said Williams. Ive got to go. Grahams calling again.
Barton broke the connection. He felt good about how that had gone.
Unexpectedly, the interaction with the CEO had restored his confi –
dence. The CEO had, in a backhanded way, expressed confi dence in
him. Now he just needed some good news from his team.
At exactly 10:13 am, Bartons ringtone sounded again. He assumed it
was the call hed been expecting from his people, but when he looked,
he saw that it was Williams again.
Oh, boy . Barton had no idea why Williams would call back so soon,
especially knowing that Barton was likely in a meeting, but he had a
feeling that it would not be good news or helpful advice.
Jim Barton.
Hi, Jim, its Carl. Ive got Graham on the line. Weve got another
problem.
What is it? Ive got an update coming in two minutes . . .
I know, thats why were calling now. Were not sure you should
participate in the update.
Huh? Why not? Had they decided to replace him in the middle of
a crisis?
Jim, youve got a meeting with analysts this afternoon.
Y es, I know, but thats not until after lunch.
Wells spoke then, explaining. Jim, we have got disclosure issues if
you talk to analysts in the aftermath of an event like this. Right now,
you dont know what has happened. Y ou dont know for sure, for
Crisis
161
example, that this event is security-related. Or that is what you told
Carl, anyway.
Thats right, said Barton, not appreciating the implication that
hed been less than truthful with Williams.
So, continued Wells, we need to think about what we want you to
know going into the analyst meeting. It might be best, if it is a security
issue, that you dont know that yet when you talk to analysts.
Carl, what kind of crazy, convoluted logic is this?
Its a legitimate concern, said Williams. This may turn out to be
nothing serious, or it might be very serious. We need to think about the
representations youll be able to make this afternoon without getting
yourself and the rest of us in trouble. Y oure going to be on the hot seat.
It might be best to have you go into it innocent of whats happening
right now, or at least as innocent as we can make you.
So you want me to just relax, enjoy the city, maybe take in a show?
Is there anyone you can delegate crisis response to?
Another call was coming in on Bartons phone. It was 10:15 am.
There was no time to think through what Williams and Wells were saying, but it felt wrong. Every fi ber of Bartons being pushed back against
what they were suggesting.
The call from my team is coming in right now, said Barton.
Do not answer it, said Wells.
Dont answer a call from my team in a crisis? Barton was aghast.
Do not answer it, repeated Wells.
Carl, this is wrong, Barton exclaimed. This is my area of the company, my problem, and I need to be responsible for it. We can fi gure out
how to manage the analyst meeting later. I can do that. I can handle it.
Right now, my job is to fi x this. Let me do my job.
Graham? said Williams.
I advise against it.
Williams was silent. The digital alarm clock near the hotel bed
clicked over to 10:16 . Bartons phone beeped persistently as his team
continued to try to reach him.
Fine, Williams said fi nally. Answer your call.
Thanks, Carl, said Barton. He was about to switch over, but
Williams wasnt fi nished.
The Heros Ordeal
162
Make no mistake, said Williams, suddenly much angrier, your butt
is on the line here, Barton. Im not a bit happy about this happening, not
now, not at this time. He was venting. Y our timing could not be worse.
Understood, Barton answered. For the second time that morning,
he was shaken. Williams had said, Your timing could not be worse. As
if Barton had caused the outage. He gathered his wits and switched to
the other call. Jim Barton.
Hi Jim, its Bernie. Weve got you on speaker. Also present are Paul
and Tyra. John Cho is down at his workstation, but hes with us on the
line, as is Ellen Ripley, whos over at the data center. Raj is with his guys
working on Customer Service systems, so hes not with us; we can call
him if we need to, though.
Great. What do we know?
Paul Fenton spoke up. There are several things going on. Y ou know
about the e-mails, I think.
Y es.
The website is locked up because of what appears to be a rather sophisticated denial of service attack. Theyre fl ooding our website with
transactions, overloading it with useless traffi c. DoS attacks are not
unusualthey happen all the time. We have defenses in place to defeat
ordinary DoS attacks. But this one is coming from many locations and is
attacking with a pattern of traffi c designed to defeat our countermeasures.
We are working on that and think we will be able to neutralize the threat
in the next few minutes. The website should be operational after that.
The thing that has us most puzzled is the Customer Service systems shutdown. We dont know whats causing it. Ellen tried rebooting
everything that has anything to do with those systems, but it hasnt
helped. Transactions against the database are returning an error code.
That could mean theres something wrong with a transaction thats
got everything jammed up behind it. Or it could mean the database is
corrupted.
Barton interrupted: Do either of those possibilities indicate that an
intrusion has occurred?
No. If its a problem transaction, that is most likely an internal software problem. If its database corruption, someone could have caused
it, but it could also have happened without any malicious involvement.
Crisis
163
John, what do you think? Barton braced himself for the possibility
of anger in Chos response.
Reuben spoke for Cho: John thinks its malicious, but thats his
predisposition. He thinks someone has exploited the security hole hes
been worried about. Cho, though supposedly on the line, did not elaborate.
The security hole, said Barton, that weve proposed addressing
with a fast-track upgrade project. The project Barton had shot down
while he was head of Loan Operations.
Thats correct.
So what do we do?
Fenton appealed to Ripley, his network operations team leader:
Ellen?
We can probably deal with the database corruption issue by going
to a backup. But it might happen again. And well lose some data from
yesterday afternoon if we revert to a backup. Well have to reenter that
data. Also, going to a backup may not solve our problems if an intruders behind them. If a hackers left malicious routines on our computers, they are likely also present among backup fi les. The problem might
just recur.
Cant we tell if there are fi les on our computers that shouldnt be
there?
We should be able to, a new, deeply annoyed voice broke in, but
we cant. Barton recognized it: John Cho.
Explain.
There was a silence, then Cho started again. Were supposed to keep
careful records of all fi les introduced into production. But we havent.
Why not? Barton asked.
Because sometimes people in the applications groups rush changes
in without going through the proper procedures
There are good business reasons to do that sometimes, interrupted
Tyra Gordon. And its not like others are not on board when we do it.
Everybody knows what we are doing when we do that.
I never agree to it, said Cho.
It must be nice, Gordon said, never to have to operate under
pressure from a customer . . .
The Heros Ordeal
164
Thats a load of crap, said Cho, I advise you to come down here
and try this kind of pressure . . .
Hey! Fenton shouted. People! Lets stay on point here.
So, concluded Barton, somebody in Tyras group put in a change
without following procedures?
Rajs group, actually, said Gordon, its his systems having
problems.
But the rush-a-change-into-production thing is not unique to Rajs
group, said Fenton. Its been a sore point for years. We have careful procedures, but when a big customer screams for a change, procedures sometimes get circumvented. Outside IT, change control procedures tend to
be viewed as a form of bureaucracy. Business unit managers sometimes
force through quick changes that circumvent change control.
Like, for instance, interjected Cho, the VP of Loan Operations.
Barton had a vague memory of browbeating Davies into such a quick
change in the not-too-distant past. I deserved that , thought Barton, deciding to let Chos not-so-subtle barb pass.
I get it, Barton said.
Fenton continued: As Tyra rightly says, we all know it goes on, and
we all acquiesce. In the minds of many on the business side, this is justifi ed if it makes a customer happy. Its a business trade-off, in effect.
The bottom line is that we dont know if bad guys are involved,
Barton concluded.
Thats right, said Fenton.
Barton heard a commotion in the background, some quiet talking.
Fenton came back on the line: The DoS attack is under control and the
website is back up.
Well, I suppose we can call that some kind of progress. Is there any
other way we can tell if bad guys are involved?
Maybe, said Fenton. It depends on how careful they were, if they
were there at all. Johns working on it.
No smoking gun yet, said Cho, now speaking in more measured
tones. If its bad guys, theyre very good.
There was more commotion in the background, a call coming in.
Fenton answered it. Barton couldnt quite make out what was being
said, but Fenton came back after less than a minute.
Crisis
165
Rajs people have fi gured out what the problem is. Well have
Customer Service back up and running in about ten minutes.
Barton felt relief that he knew was not yet justifi ed. Great. Whats
the problem?
Apparently a database fi le had been somehow renamed, and another substituted in its place. All they have to do is rename the fi les back
to how they were before, and we should be fi ne.
Files renamed. Can that just happen?
I dont know, said Fenton.
Not likely, said Cho.
Lets be careful here, said Gordon. Theres danger in overreacting
as well as underreacting.
Okay, said Barton. Ive got to update Williams. I want us to meet
again in sixty minutes, say, at 11:15 am. I need two groups, working on
two different tasks. Paul, you, John, Raj, EllenI need your best sense
of whether theres been an intrusion and what we need to do about it,
whether were sure or not sure. Bernie, you and Tyra and whoever else
you think might help who isnt working on whats happened here, I
want you to develop some advice for me on how to handle the analyst
meeting, which is at 2 pm. Okay?
Can you cancel the meeting? asked Ruben. Say youve come down
with food poisoning?
Might seem suspicious, especially if word of whats going on here
has leaked out. What if someone preparing for the meeting this afternoon has been having trouble accessing our website this morning? Or
what if some bored call center employee has called a friend or posted
something about having nothing to do on social media? But everythings on the table. If you think canceling the meeting is a good option, explain why and how. Okay?
Will do, said Ruben Anything else? All lines were silent; no one
said anything. Signing off, then. Barton disconnected.
Barton immediately called Williams with an update. The CEO listened, but said little. Barton ended the call and ordered coffee from
room service. He pulled on yesterdays pants. Then he sat down to put
together his own ideas about what he might say at the analyst meeting
under various scenarios. His leg hurt a lot, but his head hurt even more.
The Heros Ordeal
166
Thursday, June 28, 11:21 AM . . .
Paul Fenton had just fi nished his update. Juvvani, Gordon, Cho, and
Ripley were also on the line. The meeting to recommend an approach
to the analyst meeting had been moved back fi fteen minutes, to give
Gordon and Rubens group time to send Barton some presentation
slides. Gordon was sitting in on this meeting to make sure she had the
latest information on what had happened.
The facts so far: There was still no smoking gun that indicated an
intrusion, although Cho was convinced that was the explanation. If it
had been intruders, they had been deep enough into the IVK production computers to rename database fi les, which meant they could have
also stolen customer data or altered it subtly, undetectably. Loan applications asked for credit card numbers to be used in credit checks,
but, fortunately, IVK did not retain that information. Unfortunately,
the company did retain Social Security numbers and other information
useful to identity thieves.
I think we need to disclose that something has happened, said Cho.
I think were legally obliged to, in fact.
We should get legal advice on that, said Fenton. Barton thought of
Wellss incoherent state when last they spoke. Fenton continued: My
interpretation of our obligation is that we have to disclose if we know
weve lost customer data.
Actually, said Cho, its if we suspect we have.
Juvvani weighed in. So what does that mean? Y ou suspect we have,
John. Maybe I dont.
So you think that fi le just renamed itself? Cho asked.
Gordon came to Juvvanis defense: We dont know what people do
on the night shift. We dont know a hundred other things. Just because
we cant think of another innocent explanation doesnt mean there isnt
one. How often before have we seen something happen that we think
cant happen, only to discover some complex, idiosyncratic explanation?
Y eah, said Cho, but renaming database fi lesthats pretty specifi c. How would that happen innocently?
Like I said Gordon began, then stopped.
Crisis
167
Might it be an inside job? asked Fenton. Could someone with
approved access have done it? Is this somebodys idea of a joke that got
out of hand?
I dont know, said Cho. And Ive been going over the logs pretty
carefully. I dont think were going to know. I have to admit, it seems
implausible to me that someone could have done this without leaving
any sort of a trail. But renaming a database fi le . . . thats just not the sort
of thing that happens by accident.
So, said Barton, what youre telling me is that we are not going to
know whether this is a security event by this afternoon. That we may
never know.
Never is a long time . . . said Fenton.
Thats what Im saying, said Cho. Unless we stumble onto something that tells us. Im going to keep looking, but Ive looked in most of
the obvious places already.
What do we recommend doing in the aftermath of this event?
asked Barton. Williams is going to want to know what were planning
to do to avoid a repeat of this scenario.
Well, said Cho, obviously, we accelerate the security project weve
got in motion. Maybe add some more to itIve got a wish list of stuff.
Maybe Williams will sign off on what we really need now. And, of
course, weve got to begin following our procedures better. Maybe in
the aftermath of this problem, people will understand better why we
force procedures on them. Ellens got a recommendation, too, that I
totally agree with.
Ellen? said Barton.
Ripley sighed, then launched into an explanation. Theres an additional concern. We can take the actions John is proposing, and that
will close a lot of the possible holes in our security that we know
about. But ifand as weve been saying, its a big if bad guys have
been inside our production systems, what weve experienced so far
might not be the full extent of nastiness they have planned for us.
We cant tell what should be on our systems and what shouldnt be.
So there might still be some bad code on our machines. Closing the
holes in our security doesnt help with anything bad thats already on
the inside.
The Heros Ordeal
168
Okay, said Barton. This sounded like bad news, but so far hed
heard no recommendation. And so that means we should . . . ?
Ripley sighed again. I think we need to shut down our production
systems for a period of time, say three or four days, wipe the production servers clean, and rebuild the production confi guration from
development fi les. Its unlikely, though not impossible, that the bad
guysagain, if there are any bad guysreached into our developers
machines. We should be able to put our production systems back together with only what should be there, and then we can keep tight control on them thereafter by following our change control procedures
better.
By shutting down our production systems, Barton asked, you really mean shutting down the companys operations for that long?
Mostly, conceded Ripley. We could take calls and do some things
manually. But theres no doubt it would be a big deal.
Cho spoke: We dust off and nuke the entire site from orbit. Its the
only way to be sure.
Can we, asked Barton, set up parallel systems built from development fi les, then switch over to those before we take down our production systems? Wouldnt that help us avoid a shutdown?
Y es, answered Ripley, sounding impressed by his question, thats
an interesting option. We could do that. It would be expensive, because
wed have to buy or otherwise acquire additional space and equipment.
And it would take time. Which is the biggest problem with that idea.
If the bad guys have more diffi culties planned for us, thats time
defi nitely days, maybe a week or morein which their plans can
execute. Waiting might mean we have more problems.
Just so Ive got this clear, said Barton, Y ou want me to go to Williams and tell him we need to shut down production computers as
soon as possible, and keep them down for, what, three to four days?
Thats about what it would take, said Fenton. Barton realized that
his team had discussed it already and agreed on this plan of action.
Y ou realize that this is not our decision, said Barton. Its Carls
decision. And Ive got to tell you, I dont think hes going to like it.
Nobody outside IT is going to like it.
No one said anything.
Crisis
169
Any ideas, Barton asked, about how we frame this shutdown from
a PR standpoint? What we say to our customers and the public about
why were shutting down for four days?
Still no one said anything. It was Bartons turn to sigh. Okay, he
said. Let me think about it.
He ended the call and opened the presentation that Ruben had just
sent him, a plan for how to handle the analyst meeting.
He looked at his watch. It was already 11:4 4 am. The meeting was in
a little more than two hours, and he still had to get downtown.
REFLECTION
How should Barton handle the meeting with the analysts? What questions
should he be prepared to answer and how should he answer them?
How vulnerable is your company (or a company that you know) to a denial of
service (DoS) attack or intrusion? What should be done about such
vulnerabilities?
Why cant perfect IT system security be achieved? If security can never be
perfect, how should you manage against malicious threats?

171
chapter eleven
Damage
Friday, June 29, 9:12 AM . . .
Youre recommending that we shut down the entire business for how
many days? Carl Williams did not conceal his incredulity.
Not the entire business, said Barton, just parts of it, for three or
four days total, which, if we did it on a weekend, interrupts business
only a couple of days. And Im not yet saying we should do it. Its one
of several options already identifi ed. Barton wondered if hed been
too forthcoming in laying out for Williams everything known about
the event so far. Wrong way to brief the C E O , thought Barton, or this
C E O , any way . He made a mental note. He hadnt had much time to
think through the fi ner points of how hed present to Williams, who
had yanked him out of a meeting with his IT team.
One of several options, repeated Williams.
Yes.
The one that most of your staff prefers.
Barton squirmed. Thats right. At the moment.
Barton recalled the last time hed been this uncomfortable in this
chair: the day Williams had sprung the new CIO job on him. Barton
now wondered if his boss might be about to take that job back. Barton
wasnt far from just handing it over. He hadnt slept very well the night
before.
The Heros Ordeal
172
As in that earlier meeting, the CEO now stared out the window,
refusing to sit. Barton, on the other hand, was captive in a chair that
suddenly reminded him of an interrogation seat. He wanted desperately to get back downstairs; he needed more time with his team, to
help them come up with a full slate of options. At that moment, Barton
could see the attraction in spending most of his time downstairs. As he
looked at Williams, he was pretty sure the CEO would be happy never
to have to talk about IT again. Probably, Barton realized, Williams had
slept badly also.
Carl, Barton said, seizing the initiative and succumbing to an
irresistible urge to get on with doing something, anything, let me get
back to you in a couple of hours with all the options. We still have more
work to do before we can make a real recommendation.
I thought you just made one, said Williams.
Moments before, Barton had said that shutting down the business
was not yet a recommendation. Now the CEO had, Barton assumed,
moved on to venting frustration. It would be a bad idea to respond in
kind. Instead, Barton opted for calm: No, Carl, what I just gave you
was an update. I let you know some of the options weve been discussing. I especially wanted you to know about the least palatable option
weve considered. I thought letting you know of that possibility now
was preferable to surprising you with it later.
Williams turned toward Barton and nodded. Barton could see that
he had scored points with these words, though not nearly enough to
make up for the points he had lost in the last twenty-four hours.
Nice job on the analyst meeting, by the way, Williams said. There
was no discernible impact on the stock price yesterday afternoon. Well
see when the market opens in a few minutes, but my guess is that you
navigated that minefi eld successfully.
M ore points scored , Barton thought. I think so too, he said.
Gordons team had suggested playing it cool at that meeting, not
even bringing up the attack unless someone else did. If it came up at
all, Barton was to acknowledge it, note that denial of service attacks
are extremely common, and that the companys security measures had
handled the attack after a short delay.
Damage
173
During the meeting, Williams and Graham Wells called in and
listened, not letting any of the analysts know they were present.
At one point during the meeting, also at his teams suggestion,
Barton had laid the groundwork for future security measures, including a possible company shutdown, by reemphasizing the fi rms commitment to security. We think were in pretty good shape, Barton had
told analysts, but, as the new guy, I cant rule out taking some very signifi cant additional stepsincluding steps that might, say, shut us down
for three or four days, for a maintenance outageto reach a higher
standard of service for our customers.
Williams would go for that? asked one of the analysts.
Yes, said Barton, I believe that he would, if I recommend it. Although, he added, we dont have reason at the moment to think that
would be necessary. I just dont want you folks to be surprised if we
decide to do something like that.
Barton had added that last part mostly for the benefi t of the lurking
Williams, who at that time had not heard about any options involving
a company shutdown. But it was an effective moment in the meeting.
It conveyed to analysts that the CEO entrusted much to his new CIO.
Barton couldnt help wondering whether this was a past, more than
present, situation.
Hed stuck to a general line of argument throughout the meeting:
Were in good shape already, but we want to be even better. The question he had dreadedDo you have any reason to believe todays event
was anything more than a run-of-the-mill DoS attack?never came.
Nothing about the attack came up. Barton spent most of his time sticking to a script hed prepared before the attack.
Emerging from the meeting, Barton went directly to LaGuardia Airport and was back at his desk by early evening. But there wasnt much
he could do to help. Cho and a couple of other security people continued to examine intrusion detection logs, but theyd found nothing
yet. Fenton, Gordon, Juvvani, and Ruben had stayed around, awaiting
Bartons return, but only Fenton and Juvvani could really help with
the technical details. Everyone wanted to be supportive, but at some
point too many managers just got in the way. Barton chose Gordon
The Heros Ordeal
174
and Ruben to lead a complete review of the business continuity and
emergency response measures, the ones that theyd discovered were
out of date. Then he sent them home for the evening. Fenton and
Juvvani sent most of their people, those not from or useful to the security group, home; the two of them and Barton were gone half an hour
later, with a plan to begin early the next morning. By then, they hoped,
there would be more information about what had happened. It made
little sense to charge ahead with the really big decisions until they had
better information.
Barton was back at his desk by 6:30 am. Cho still had nothing. He
and a small group had been working all night. When Gordon, Fenton,
Juvvani, and Ruben arrived, all by 7:15, theyd begun talking through
a list of issues.
First, they needed to identify the remedial security measures they
wanted to implement to reduce the risk of future attacks. Along
with knowing what the security measures were, Barton wanted to
know what they would cost. Chos upgrade project would be accelerated, of course, but Barton wanted them to figure out what else
they could do to avoid a repeat of the events of the day before. As
long as they were going to ask for more money, might as well ask for
enough.
Second, they needed to decide what should be done to make the
company secure against additional mischief from the attack that had
just happened. They had no smoking gun to tell them that there had
been intruders, but neither could anyone think of a way a database fi le
could be renamed by accident. And then there was the matter of the
Gotcha e-mails. It could have been a coincidence that those came
in at the same time that the database problem occurred. It could be a
coincidence that they arrived at the same time as the DoS attack. But
that seemed unlikely to Barton. Others had different opinions, especially about whether the renamed database fi le was part of the attack.
Gordon was far from alone in observing, Just because we cant think
of how it happened, doesnt mean somebody did it. In my IT career,
Ive seen a lot of weird stuff happen that seemed impossible at fi rst, but
Damage
175
that nevertheless proved to be quite possible under certain not-easy-toimagine conditions.
Third, they needed to fi gure out what to recommend to Williams and
the rest of the leadership team about what, if anything, they needed to
disclose outside the company, and to whom. The risk of under reacting
by not disclosing something they should, which might then come back
to haunt them, had to be balanced against the risk of over reacting
confessing too much, especially without hard evidence of intrusion.
Without accurate information on what had happened, there was no
way to know what over- or under- reaction even meant. Barton and
his team were left arguing conjectures. What was most likely? What was
second most likely? No one could agree, and Barton had no knowledge
base on which to form his own ideas.
This last issue was, to Barton, the real nightmare, the one with which
Williams would have the greatest diffi culties. If IVK managers decided
they needed to announce to the world that information on their customers had been stolen, who knew what might happen? This was the
issue most likely to get people fi red, the issue most likely to spell an ugly
end for IVK.
As he sat in that unpleasant morning meeting with Williams, in that
unpleasant chairas he wrapped himself in the sanctity of a policy
of alway s letting his boss know of the least palatable options and
possibilitiesBarton realized that he was actually breaking his longstanding personal rule by not bringing up the disclosure issue. It was in
his interests to do so. The longer he went without raising it, the harder
it would be to discuss. Wells was probably harping on the issue already
in his own conversations with Williams.
Barton left the meeting without mentioning anything about disclosure. Before he returned to the meeting with his team, Barton
stopped in his offi ce to write on his whiteboard: Always tell your
boss the bad news fi rst; tell him as soon as the possibility is known;
dont put it off until you know it for sure. Then he addedand
underlinedBut SYH2DP. Y eah , he thought, som etim es y ou have
to duck a punch .
The Heros Ordeal
176
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1 7/6
$75.12 $30.72 31.90 30.88
4.77B 1.95B 2.03B 1.96B
+
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Communication
Always tell your boss bad news first; tell him as
soon as the possibility is known; dont put it off
until you know it for sure.
But SYH2DP
Friday, June 29, 3:47 PM . . .
By Friday afternoon, options were shaping up. Cho still hadnt found
much. Some odd network traffi c he couldnt explain (but there was
always some of that . . . ). A few logins from offsite by sysadmins who
couldnt remember doing it but said they might have. Nothing Cho
considered conclusive. Fenton, with Bartons permission, sent Cho
home to sleep. The guy had been awake for nearly forty hours. But he
planned to come back in later that night.
Gordon and Ruben would work on future event avoidance on a
less urgent timeframe, but the other two issues, recovery from the attack of the day before and what to disclose, had to be dealt with now. 1
Concerning the attack, three options were shaping up:
1. Do nothing. Assume that the past mischief was the worst that
the bad guys had intendedif in fact there had been bad guys.
Damage
177
This option best fi t scenarios in which there had never been intruders, or in which the intruders had been mere tricksters, not
really malicious.
2. Shut down the company, except for operations that could run
manually, as soon as possible and rebuild critical production
systems from development fi les. This was the playing it as safe
as possible option, but it had an unfortunate side effect: the
shutdown of most of the companys operations would last long
enough and be noticeable enough from outside IVK that it would
need to be explained. And there were risks. The IT team assumed
they could rebuild from development fi les, but the documentation on how to do that had not been kept up-to-date. They would
eventually get it done, but it might take longer than estimated.
Also, because data would have to be restored from backups, this
option did not address possible data corruption issues; if bad guys
had subtly adjusted the data in some way, they might have done it
in the past, in which case the problem would be present in backup
fi les toothis would be undetectable. And if customer data had
already been stolen and copied to somewhere outside the fi rewall,
this option would, of course, do nothing to address that.
3. Build a mirror site from development fi les and shut down the
original product systems; rebuild original production systems
only after the mirror site is up and running. It would cost
money and take time, probably a couple of weeks, to assemble
the necessary facilities and equipment. More bad things could
happen while all this was coming together. But this option would
not require shutting down the business or explaining why IVK
was shutting down the business; and it would, if they were lucky,
fi x some of the problems that might have been left behind by bad
guys if there had been any bad guys.
Bartons team had a defi nite preference for playing it safe; they liked
option 2. That had been Chos recommendation as well, before hed
headed home to get some rest.
The disclosure issue was, as expected, more complicated. Some
argued for coming totally clean concerning the possibility of an
The Heros Ordeal
178
intrusion. Their line of argument went something like this: We werent
adequately prepared for this attack, so we dont know what happened.
Since we dont know what happened, we need to avoid making convenient assumptions about what we would know if we had been more
adequately prepared. The evidence is strong enough to dictate telling
the world that we suspect our customer data could have been stolen. Barton couldnt quite imagine recommending this to Williams,
however.
The most popular position called for contacting customers whose
records had been accessed on the day of the attack and perhaps some
number of days beforethis could be gathered from logsand warning those customers that their information might have been compromised. There was little agreement on how many days before the attack
they should start. It was possible, of course, that the intruders had been
inside the fi rewall for weeks, months, or even yearsif, Barton kept reminding himself, there had been intruders at all. Gordon was a broken
record on this point: We have no evidence of an intrusion, she kept
saying. If IVK contacted customers in this way, it would undoubtedly
fi nd its way into the press. But it would not be nearly as dramatic as a
big public announcement, and the company might get lucky and the
story would end up on the back pages, especially if something distracting was going on in the news. There was even talk about waiting for
such an event to hit the papers before contacting customers.
A few argued for no disclosure at all. Like the do nothing to deal
with the attack strategy, this was a wishing for the best approach.
But it could work out. And if it did, it would be preferable to the other
courses of action. If the unknown circumstances were such that this
was the best approach, then the other options would all be foolhardy
overreactions. One could imagine a scenario in which there had been
no intruders, but IVK, playing it safe, effectively committed corporate
suicide by announcing that customer data might have been stolen. Doing that in no intruder circumstances would rank high among the
all-time dumbest business decisions. But there was no way, of course,
to know that there were no intruders.
Bartons direct reports, after much tired and occasionally heated
discussion, settled on the immediate rebuild option, explaining it as
Damage
179
the sort of maintenance that Barton had warned about at the analyst
meeting, and a limited disclosure to customers only, at a time not too
far in the future when the news situation was favorable to IVK. Barton
thanked them and sent them all home. Fenton and Cho would, Barton
knew, be back later, and he suspected Gordon and Ruben had plans to
come in on Saturday morning. But the decision on what to recommend
was now Bartons. His team had done all they could.
Sometime after 4:30 pm, Barton called Williams to say that he was
ready to discuss options. Williams informed him that the entire senior
leadership team of IVK would convene at 8 am on Saturday morning to
decide what to do. We could do it this afternoon, said Williams, but
I think you should sleep on it. So you can be really certain of what you
recommend. You didnt have to listen carefully to hear the threat in the
CEOs words.
Before he left for home, Barton called Maggie. She was out of town
again, which really stunk. Hed managed a call to her from LaGuardia
the day before, so she knew roughly what was going on. But he badly
needed to talk through the options with her.
Now wait a minute, she said, when he explained what seemed to be
the choice of his IT team. Youve got to be practical here. Whats Carl
going to be okay hearing?
I dont know, Maggie, said Barton. But there are legal issues that
come into play around disclosure.
Yes, but disclosure now puts IVK in deep trouble with certainty . N ot
disclosing might result in big problems, but thats less than certain.
Some of the problems might involve lawsuits, even jail time, for all
I know. Do you know, could we get in criminal trouble for anything
here?
Im not a lawyer, said Maggie, but I think its unlikely youll end
up in jail.
I could get fi red.
Thats certainly imaginable.
Barton groaned. What do you recommend, Maggs?
Moderation. A reasonable middle option. Youre very tired right
now, Jim. Get some sleep, okay? Dont make an extreme choice when
youre out of sorts. You might just survive this.
The Heros Ordeal
180
I hope so, said Barton.
I hope so too, sweetie, said Maggie, her voice thick with as much
empathy as could be conveyed across a voice over IP link.
Friday, June 29, 8:28 PM . . .
Barton was ordering his second beer when the kid appeared. As the
bartender cleared away the half-eaten remains of a sandwich, the kid
settled in beside Barton and ordered a root beer.
You dont look so good, said the kid.
Is it that obvious? Barton asked.
Whats up?
Barton couldnt share the details, of course. He got across that there
had been a major problem and that the CEO was upset enough to call
an 8 am Saturday meeting. Barton managed to imply that there might
even be legal concerns involved.
Its not all my fault, said Barton, but its a pretty big screwup. He
fell silent. The kid said nothing; he seemed to be thinking hard.
So, IVK, right? asked the kid. Barton nodded. Thats Carl Williams,
right?
Thats right, Barton said, surprised that the kid knew the identity of the IVK CEO. Barton didnt remember mentioning Williams by
name before. Maybe he had, though.
Knowing Williams, said the kid, Id say you should recommend
nothing that might endanger his turnaround of the company. Keep up
appearances. Thatll be his inclination.
What do you? Barton stammered.
What do I know? the kid interrupted. Nothing, really. What
youve told me.
You know Williams?
No. The kid paused to take a sip. This is your moment, man. Dont
listen to me. Trust your gut.
Barton wasnt sure what else to say. He and the kid talked for a few
minutes about baseball, then the kid fi nished his soda and stood up.
Got to pick up my date, said the kid. No gaming tonight. Strictly
Damage
181
in-person interactivity, hopefully friendly. He tossed a few dollars onto
the bar. Be sure to come by next week. I want an update.
Sure, said Barton. I wont offer you a job this time. I might not be
able to deliver it.
The kid laughed, slapped Barton on the back, and departed. Barton
fi nished his beer, walked home, and fell into bed exhausted, remembering to set his alarm for early the next morning.
Saturday, June 30, 8:56 AM . . .
So, this is a recommendation, said Williams.
This is a recommendation, said Barton.
You think we should shut the company downexcuse memajor
parts of the company, not the whole thingso that we can be sure we dont
have any further problems as a result of this attack. I f there was an attack.
There was an attack, we just dont know if the database problem
was part of it.
And we explain the outage as a service upgrade.
Which it is.
And then we contact customers whose data records have been accessed in the past week, and let them know that they should be especially vigilant about identify theft, because there is a small chance that
we might have lost some of their private identify info, Social Security
numbers and the like.
Social Security numbers, name and address, date of birth, Barton
confi rmed.
And you think we should wait a few days to begin contacting customers, try to coordinate these contacts with a busy news day, and maybe spread them out a bit over time so that the number of people were
contacting will be diffi cult to pin down.
The last part, how we contact customers, is a suggestion, not part
of the recommendation.
They were assembled in the boardroom. Williams stood, as usual.
Leadership team members sat silently around the table. From Bartons
right, it was Eva Dillard, VP Corporate Planning; Ed McLaughlin, VP
The Heros Ordeal
182
Financial Management; Maria Navarro, VP HR; Ben Lao, Director of
Collections; Momoko Sato, ; Graham Wells, VP Legal Affairs and General Counsel; Omar Willis, VP Business Development; Ehsan Nisar, VP Customer Service; and Niels Hansen, Bartons
successor as head of Loan Operations.
None of the others said anything. Barton was the only one whod
spoken since the meeting began, other than Williams.
Graham? Williams turned to the companys chief lawyer.
I like the idea of playing it safe by shutting down the computer
systems to make sure we have done everything we can. And I think we
can probably get away with a careful customer contact strategy; we are
simply gauging our actions to the urgency of our good-faith assessment of the situation.
Other thoughts? Williams looked around the room. The others
stirred, nodding and murmuring agreement with Barton and Wells.
There might be opportunity in this, said Willis. We could play up
how much we care about customer security in some of our marketing,
cite the shutdown as an example.
That sounds a bit like tempting fate, said Hansen. A few others
chuckled nervously.
Depending on the number of customers were talking about, said
Nisar, perhaps we should call them, not write to them. Maybe those of
us in this room should make some calls.
Nods of agreement around the table. Williams was listening, but he
wasnt nodding, laughing, or speaking. A silence stretched out across
the room. Williams dispelled it.
So you all think, said Williams, that this sounds like a good way
to go?
Again, there were murmurs of agreement.
What if, Williams asked, a reporter or analyst puts two and two
together, the maintenance outage and the warnings were sending to
customers, then wants to know about the attack?
How would a reporter or analyst know about the attack? asked
Hansen.
I dont know, said Williams. Maybe a rumor. Our employees
know about it. Think none of them has mentioned it to a friend? No
Damage
183
one answered. Williams continued: Im not going to let anyone coast
on this decision. Let me see handswho thinks we should adopt the
plan that Jim Barton has recommended?
Haltingly, exchanging uncertain glances, the executives raised hands
into the air, in the end indicating unanimous agreement.
Williams surveyed the room, eyes circumnavigating the table as if
counting. Then he turned away, moved to the window. For a long time
he stood, looking out. The others lowered their hands. S uch a fl air f or
dram a, this guy , mused Barton. A ll the long pauses and stalking around.
Williams turned back: I dont agree, he said quietly, almost inaudibly. A moment passed. Then he took a deep breath, suddenly infl ating,
threatening to explodewhich he proceeded to do:
I WAS HIRED, he said, now shouting, to turn this company
around. Thats just what Im going to do. We will NOT shut the company down. And we will NOT say to anyone that we think, maybe, possibly we might haveperhaps, perchance, conceivablylost customer
data. That would be not knowing what we are doing. It would be unprofessional. It would be incompetent. It does not rise to my standard
of performance. Carl Williams doesnt run companies that way.
He paused to inhale again, then focused his attention on Barton. The
room grew very still. T his is it , Barton thought, I m history .
UnexpectedlymiraculouslyGraham Wells chose just that moment to speak up: I cannot go along with you on this, Carl. This is
a very dangerous course you are proposing. At least I think you are
proposing it. In my professional opinion, we need to play it safe here.
Youre not the CEO, Williams said, turning on Wells. Its my
decision.
That may be, said Wells, but it is my career that you are putting at
stake, and those of all the rest of us. My professional ethics too. In good
conscience, I cannot go along with this. I feel we must come forward
with some sort of disclosure, no matter what the consequences. We
must do the right thing here.
Williams settled into the empty chair at the head of the table. He
propped both elbows on the table and positioned his chin atop joined
hands. Calmly, he said: So thats what you think, is it?
Yes, said Wells, it is.
The Heros Ordeal
184
I agree, ventured Hansen. We need to choose a strategy that allows
us all to move on to our next job, even if this one doesnt work out.
Move on to your next job, repeated Williams, again calmly, still
staring at Wells. It was unsettling how calm he had become.
Yes, Hansen said.
Now Williams looked at Hansen, who was nodding, nodding, seemingly forgetting to stop nodding, then at the others who were not nodding, who were carefully not moving at all. Williams said: Well, I say
no. Were not moving on, were not giving up on this company. Im
going to turn this company around. Its what I came here to do. Its
what I will do.
I cannot go along with this, said Wells.
Ive got a real problem with it too, said Hansen.
Anybody else? Williams asked. No one said anything. Williams
stood, went again to the window, waited. He waited for a long time.
Then he turned.
Very well, he said quietly, the two of you are fi red. Before you tell
anyone what you think has happened inside IVK, I suggest you consult
your employment and nondisclosure agreements. I think youll discover that if you, as a former employee, cause damage to this company with
remarks that are not provably accurate, then we will have legal recourse.
You are, as of about twenty seconds ago, former employees. So Id recommend that you be careful. Because I willthis is a promisecause
you diffi culties if you have the poor judgment to violate any aspect of
these agreements. You will have trouble moving on to your next job.
Let me say this even more clearly: When I fi nish with you, youll be
lucky if you can afford a doublewide trailer in a low-rent trailer park.
Now get out, both of you.
Carl, maybe we should take a moment, let things settle down a
bit . . . Maria Navarro, the HR chief, began. She stopped when Williams
shot a borderline deranged expression in her direction.
Williams returned to the window. Wells and Hansen looked at each
other, then stood and left the room. For nearly fi ve minutes, no one
moved or made a sound.
Suddenly, Williams turned, swelled to what seemed like twice his normal height, raised his right arm horizontal, index fi nger outstretched,
Damage
185
and pointed directly at Barton. And YOU! He was shouting, but he
stopped. His head rolled on his neck: once, twice, three times, as if he
were about to cough up something, some obstruction keeping him
from breathing. Then air and sound came rushing out:
YOU! he repeated, Will need to take over Loan Operations
again until I fi gure out who to turn it over to. Do NOTand I mean,
DO NOTlet Loan Operations distract you from your duties in IT.
And DO NOT let this ever happen again. Do you understand?
Yes, Carl, Barton whispered.
This meeting is adjourned, said Williams.
As the remnants of the leadership team fi led from the room, Williams made a call. Barton heard him say, Hi Charlie, regret bothering
you at home, but weve got a situation here. Were going to need you to
put together a legal team to help us with a little emergency. Wells is out
of the picture . . .
Trudging down the hallway outside the corner offi ce, Barton passed
beyond earshot of the conference room, his peers alongside him. He
felt compelled to say something: Im really sorry about all this.
No one responded. Barton turned and headed to his offi ce.
REFLECTION
Which option for securing IVK in the aftermath of the security incident would
you choose?
What would you disclose?
Did CEO Williams make the best decision for IVK? Why didnt Williams fire
Barton?

187
chapter twelve
Communication
Tuesday, July 3, 10:33 AM . . .
Barton had forgotten that Wednesday would be a holiday until Raj
Juvvani showed up at his offi ce, apologetic because he had long-scheduled
plans, a wedding that would take him out of town for the rest of the
week. The poor guy seemed genuinely fearful as he confessed to having
a problemthat was the word he used for it. He seemed to expect a
harsh reaction to his news. This shouldnt have surprised Barton. Word
of the tumultuous meeting on Saturday morning, the fi ring of Wells
and Hansen, had spread through the company like wildfi re. Barton
had overheard emotional voices in the hallways asking why Hansen,
popular with his employees, had been fi red while Barton remained. He
could see their point. Barton knew Hansen well, had mentored him.
Wells had never been much more than a bureaucratic annoyance, but
Hansen was a real loss.
Williams would appoint someone to take over for Hansen within
the week. The CEO had said so in an unusually long e-mail hed composed to Barton on Monday. The e-mail had begun by proposing Linda
Trilling to take over from Hansen and asking Bartons opinion. It was
a good choice, the one Barton would have recommended, and he told
Williams that in an immediate reply.
The rest of the note was a list of references to articles the CEO had
read over the weekend, most of them from the web, but some of them
: E
The Heros Ordeal
188
from print magazines. All were about IT management. Collectively,
they were a diverse set, in age and subject. Alongside some, Williams
had recorded a few cryptic comments: This guy has some interesting
ideas, or Not so sure about this one; what do you think? Williams
seemed highest on a blog by a guy Barton had never heard of. When he
followed the link, he discovered that the author had gained fame from
controversy. Barton read, trying to understand why the CEO had been
so fond of the guys writing. After a while, Barton began to get it. But
the more he got it, the more disheartened he became.
The writers formula was the business equivalent of the shock pundit strategy so popular on TV news channels: Say something outrageous, something your target constituency wants to hear, then sit back
and bask in the howls of protest from people who know better (no
publicity is bad publicity). Then do it again.
Throughout the blog, Barton found one controversial statement
after another, most just the sort of thing that would play to a general
managers darkest suspicions about those mysterious nerds in the basement doing IT. Barton still had what he considered minimal technical
knowledge, but the little bit that he knew told him that this guy didnt
have his facts straight. Williams, like most business managers, could
not see that, though. Indeed, Barton was still close enough to his past
as a business manager and IT skeptic to be occasionally drawn in by
the writers seduction. At one point, reading, Barton caught himself
whispering Oh yeah!
Usually Williams dictated letters and e-mails, then his assistant
added openings, closings, formatsimbuing such documents with a
formal tone. But Williams himself had clearly typed the e-mail Barton
received on Monday. It lacked the usual niceties and contained typos,
punctuation problems, and other evidence of keyboard awkwardness.
The whole thing was odd; Barton was unsure what to make of it.
Eventually, as he considered the e-mail yet some more, what it all
meant dawned on him: colossal absence of confi dence in the CIO and
IT function. The CEO had concluded, after the events of the past week,
that Barton was in over his head. The fact that Williams had composed
the e-mail himself probably indicated how exposed he felt; the only
course of action he could think of in his desperate situation was to
Communication
189
become a CIO helper himself. He didnt trust anyone else to do it.
There could be no mistaking it: this e-mail signifi ed a dramatic fall
from grace for Jim Barton.
Which created a new set of problems. He could expect to get more
advice from Williams. From now on he would need to do more than
inform Williams of what was happening in IT and recommend plans
of action. Hed also have to explain and justify not following the CEOs
advice, which would continue to be of highly variable quality. Williams
was taking an interest in ITthat was a good thingbut the guy didnt
know what he was doingthat was a bad thing.
After spending another forty-fi ve minutes following links suggested by Williams, Barton rose and wandered down the hall to Bernie
Rubens offi ce.
Theyve lost a lot of confi dence in us, said Barton, after telling
Ruben about the e-mail, the blog, and what it all meant in his reckoning. Barton knew Ruben heard the subtext of his statement: Williams
has lost confi dence in me.
What do you think we should do about it? Ruben asked.
Im not sure. The meeting on Saturday was really something. Ive
never seen a CEO get quite so . . . visceral .
From what Ive heard, Wells and Hansen threatened to mutiny.
Sounds like thats the one thing this CEO wont tolerate.
Guess so. Not sure how I emerged unscathed.
Y oure not unscathed.
Relatively. Not scathed enough.
Y oure feeling guilty. Understandable, if not entirely justifi ed.
Thanks, Bernie. My sense, said Barton, getting back to business, is
that we need to think systematically about this, just as we would any
other kind of problem.
Meaning?
We need a step-by-step plan for regaining the confi dence of the
business managers and CEO.
Sounds like a long-term project.
We have to improve things. But we also have to communicate what were doing to Williams and others in a way that builds
confi dence.
The Heros Ordeal
190
The plan Tyra and I have been working on is almost ready for initial
discussion. Its not rocket science, but its very thorough.
Y es, Ive seen it in draft, and I like it. Ruben had sent him a copy
the day before. The plan was about fi rewall upgrades, fi le fi ngerprinting, better intrusion detection, purchase of additional processing and storage capacity to allow more logging, additional third-party
security audits, procedures to makes sure emergency manuals were
up-to-date, training, rehearsal of emergency procedures on a regular
basis, and renewed emphasis on change control. The goal was never
again to be in a situation in which they didnt know what to do in an
emergency or couldnt tell what should be running on production
computers.
Williams will sign pretty much anything security-related at this
point, said Barton, so lets dont lowball anything. Hes expecting a
big number.
Ruben nodded. A big number should help with the confi dence issue. Though he probably wont like spending the money.
As the new guy, hes got some slack to spend money, write some
things off. The money is the least of our worries.
What do you have in mind? Ruben asked. Briefi ngs?
Frequency of communication is one question, Barton acknowledged. We could go away and fi x a lot of things, then come back to
Williams when we can claim a lot of progress. Thats one approach.
Alternatively, I can request much more frequent and incremental updates. Maybe once a week, a regular agenda item at the leadership team
meeting, and an additional meeting every week with Williams. Something like that.
Think Williams would meet that often on IT? He doesnt seem like
that much of an IT guy.
Oh, hed hate it, Barton agreed. But we could, if we think its the
right thing to do, insist. Right now, he wants us to just handle it. Hes
chosen this hope for the best strategy in reaction to the attack, so he
really doesnt want to be reminded of what might still happen.
Maybe we should just leave him alone for a while, let him settle down.
Maybe.
Communication
191
Hes agreed to Plan B, right? If were not going to shut down, we
should at least build a mirror site and switch over to that.
Barton nodded. As long as it doesnt involve a shutdown or any
form of public disclosure, hes okay with it.
What do you think about his approach?
Barton shrugged. Its not the one I recommended. If things go
south, Ill be dragged down with him. Williams and I are in the same
boat. Well sink or swim together.
Oddly, that makes you his closest ally, doesnt it?
Not one he thinks of very highly. Barton stood. Tell you what.
Why dont you and Tyra think a bit about communication strategy,
this question about frequency, anything else you think is important.
Also, Id like recommendations about how we should reach out to the
extended business team. Williams is easy in terms of how: Ill brief him
personally. But weve also got an issue with the rest of the business
team. I wont be able to personally brief all of them.
A newsletter? A weekly message?
Barton shrugged. Dont know. Thats what Id like you to think
about for me.
Sounds good.
Barton turned to go. Ruben spoke: Jim?
Barton turned back: Y es.
I think youre going to climb back out of this.
Thanks for the vote of confi dence.
Deep down, I think Williams knows it too.
Hope hes right. Hope you both are. Thanks, Bernie.
Anytime.
Barton departed, moving quickly back down the hallway to see
what new problems awaited him. Before he settled in behind his desk,
he went to the whiteboard, to record the insight hed realized in the
conversation with Ruben. He wrote: Effectively communicating ITrelated business issues to business managers requires SY STEMATIC
EFFORT, just like everything else you try to accomplish in business;
spend suffi cient time on it. He wasnt sure he understood what he
meant by systematic effort. That would come, hopefully.
The Heros Ordeal
192
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1 7/6
$75.12 $30.72 31.90 30.88
4.77B 1.95B 2.03B 1.96B
+
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Communication
Always tell your boss bad news first; tell him as
soon as the possibility is known; dont put it off
until you know it for sure.
But SYH2DP
Effectively communicating IT-related business
issues to business managers requires SYSTEMATIC
EFFORT, just like everything else you try to accomplish
in business; spend sufficient time on it.
Saturday, July 7, 6:13 PM . . .
Maggie sipped the drink Barton had prepared for her. She was in town
for a change, thanks to the midweek holiday, so Barton was in a good
moodalso for a change. There hadnt been much to be happy about
lately, so it was nice to have an excuse. The two of them were hanging
out, relaxing, doing nothing; they had 8 pm dinner reservations at a
restaurant that had recently received a Michelin star, but that was
nearby, and it wasnt time to leave yet.
Barton plopped an olive into his own drink and moved across the
room to adjust the equalization on his stereo. They were listening to
one of Bartons iTunes playlists, a shuffl ed mix of selections from the
Arctic Monkeys, Broken Social Scene, Choir of Y oung Believers, the
Decemberists, Dum Dum Girls, Jack White, Linkin Park, Nirvana, PJ
Communication
193
Harvey, REM, Regina Spektor, Zero 7, Y o La Tengo, and others. An old
favorite, Nietzsche by the Dandy Warhols came on, and Barton found
it necessary to crank up the volume. That which does not kill me makes
me stronger, right? Barton thought to himself. On the other hand, maybe
Im misreading. Maybe this is what its like to die slowly . . .
When the vocals kicked in, he turned it back down and settled in on
the couch across from Maggie. Once again, despite their rule against
talking shop at times like this, the events of the past week had launched
that rule out the window.
Think I should contact Francesco Carraro?
Carraro? Whos he?
IVK board member. Enthusiast for IT. Remember?
Right. And you want to contact him . . . why?
He left the door open.
To what end? For what purpose? Why would you contact him?
I thought Williams might want me to go to the board with him to
give an update on this attack. The thought crossed my mind that the
only reason I have a job still is to absorb fi re from the board when we
update them about it. But he doesnt seem to be in a hurry to update
them. Its consistent with his overall strategy for handling the event:
wish for the best, pretend it never happened. But if hes not planning to
update them, this raises an even more disturbing possibility.
That hes keeping you around to blame the whole thing on you if
the ship goes down?
Exactly! The old I didnt know a thing, and Im not an IT guy, so
how could I? defense.
Y ou sound a little paranoid, Jim, teased Maggie.
Just because youre paranoid doesnt mean theyre not out to get you.
Maggie paused, bit into an olive, then spun a scenario: So you bypass Carl and update the board yourself, through Carraro. Carraro goes
to the board, the board confronts Carl, Carl confronts you. The two
of you end up in a credibility contest. Secret lunches ensue, favors are
called in. The board comes to realize that a lot of their own credibility
is invested in Williams. Once they do, things end badlyfor the both
of you, but especially for you. Hmmm . . . No, Jim. I dont think you
should contact Carraro. Unless Carl says to.
The Heros Ordeal
194
Barton sank back against the couch. That wont happen. Not the
way things are going.
Maggie slid over next to him. Maybe you need to be plotting an
exit? Y our situation is a bit dicey, to say the least.
Y eah, Im totally screwed.
Y es, you are. Totally screwed.
Barton smiled. Thats what I love about you, babe. Brutal honesty.
Thats why clients pay me the big bucks. Its a pretty neat trick. I tell
them theyre totally messed up, more or less completely hopeless, and they
thank me and pay me handsomely. Its the best part of being a consultant.
Thats how enlightened executives behave. Some others I could
mention pretend nothings wrong and fi re people for saying otherwise.
Its a problem.
Y es, it is.
But look at the bright side.
The bright side?
At least hes not threatened by you anymore.
Barton laughed and changed the subject: Any thoughts on how we
ought to rebuild confi dence in our IT capabilities?
Y our communication plan?
That.
Well, its occurred to me that you might fi nd stakeholder analysis to
be of use in formulating your plan. Have you used it before?
No. I think Ive seen someone give a presentation about it. But its
been awhile. Remind me.
Y ou were talking about something systematic, this is defi nitely
systematic. Y ou identify stakeholdersthe people who can infl uence
the decision outcomes you care about. Y ou map stakeholders into categories, like Allies and Blockers, then you formulate independent
strategies to deal with each categoryor even each stakeholder, if the
persons infl uence warrants that. Theres a good deal more to it than
this, but the basic idea is pretty simple.
Sounds helpful.
I can send you something to read on it.* Y ou can take a look, decide
for yourself if its likely to be useful. If you decide yes, I can probably
* See Stakeholder Analysis at the end of this chapter.
Communication
195
connect you with some consultants who can help you carry out the
analysis.
How often do you think we should communicate with Williams
and the rest of the leadership team?
Hes thinking bad thoughts about you at the moment. When youre
not around, his imagination builds those up in absence of evidence
to the contrary. Id say that means getting in front of him soon and
as often as hell put up with. Y ou cant rebuild a relationship without
interacting with the person.
Regular item on the leadership team staff meeting agenda?
Absolutely.
Additional one-on-one meeting with Williams once a week?
Or more often, if events warrant. Im pretty sure you wont make
things worse in your personal interactions with him. Y oure basically
pretty competent, Jim. And reasonably pleasant to be with.
Im glad you think so, Maggie.
Sunday, July 8, 11:55 PM . . .
Bartons breathing slowed and his eyelids drooped. He had planned to
get to bed early, to start the week fresh. Hed orchestrated his entire
afternoon with the goal of sleep in mind: taken a longer-than-usual
run, drawn a steaming-hot bath, cued up a sounds of nature album
hed received as a gag gift on his audio systemeven choked down
some of Maggies bitter herbal tea. But a million thoughts had swirled
in his mind, placing three fi tful hours of torment between bedtime and
this moment when, fi nally, he grew still.
Monday, July 9, 4:12 AM . . .
Barton jerked upright in bed, reacting to a burning sensation on his
thigh, which faded as he opened his eyes. Moonlight streamed into the
room through slatted blinds. Images of a dream came fl ashing back.
He was in his offi ce, talking with a smartly dressed headhunter
about becoming the new SVP and CIO for a large investment bank. In
reality, Barton had been contacted frequently by headhunters, but he
The Heros Ordeal
196
had never encouraged them, nor had he ever heard from a headhunter
recruiting for a CIO position. He remembered spilling hot coffee in his
lap when the headhunter mentioned the compensationit more than
doubled his existing IVK package.
If Maggie was right, and he was totally screwed, maybe this dream
was a sign. Maybe I should start looking for a new job? Barton fell back
into the sheets for two fi tful hours of sleeplessness before his alarm
rang to offi cially start the morning.
Thursday, July 12, 12:16 PM . . .
Starting to get a sense for what its really like to be the CIO at IVK,
I hear.
Bill Davies had a smile on his face that Barton wanted to wipe off.
He felt a strong urge to ridicule the guys tie (brightly colored with
a cartoon theme). But Davies deserved to gloat a bit. He and Barton
were having lunch at a local hotel, neutral ground roughly equidistant
between IVK and the site of Bill Davies new CIO job. Barton had requested the meeting. Hed long intended to get in touch with Davies, to
try to learn why he had not been effective as the IVK CIO.
Barton had not followed through on these intentions. Now, as much
as it hurt his pride, he would ask Davies for advice.
Davies had already gotten a pretty thorough account of recent events
through his informal network. As they talked through things, Barton
was surprised by how much peoplehis employees in the IT department, it seemed logical to assumehad shared with Davies, even
though he no longer worked for IVK. The level of information actually
violated employment agreements, but there was probably nothing to
be done about it. Nothing that wouldnt cause more problems than it
would be worth, anyway.
Barton controlled his annoyance and worked on maximizing the
value of the conversation.
Y es, I know a bit more about what its like to walk in your shoes
now, Bill. And I apologize again for the diffi culties we had when you
were at IVK.
Communication
197
Davies was not done with vengeance: Is it true that the attack
exploited a hole that would have been plugged if you hadnt killed our
upgrade project when you were in Loan Operations? Barton decided
not to concede full satisfaction to Davies on this point.
We dont know. Were not sure anyone came in through any holes.
We have no evidence of it.
Davies chuckled. Y ou have to admit, if thats what happened theres
a certain amount of irony in it.
Y es, there is, said Barton, if thats what happened. And in any case, it
was a bad idea, shooting down your project. Y ou were right, I was wrong.
Davies softened. But you still work there. Y ou must be doing something right.
Barton shrugged. Not sure about that. But I do still work there, so I
was hoping to get your advice on a few things.
Barton thought Davies seemed mildly incredulous. But he became
cooperative: Sure. If I can help, Id be happy to.
Very big of you , thought Barton, but he didnt say that. Any ideas on
how to rebuild confi dence in the IT group?
Davies thought for a moment. Y eah, sure. Get Cho on it, and Fenton,
push that upgrade through fast, do everything else you can think of to
upgrade security. When youve got most of it in place, lots to show, present to Carl and the other members of the leadership team. And, most
important, make sure nothing else happens in the interim.
So you would go away, do a lot of work, then come back and tell
what youve done.
What else could you do?
Well, Ive been thinking about meeting every few days with Carl, to
make sure he knows what were doing and feels that he has input into
it, or at least opportunity for input.
Not the way Id play it. I doubt he wants to see that much of you right
now. My guess is that hes pretty upset. Y ou could do it that way, but I dont
really see the difference, content-wise, and the continuous explaining and
complaining youd have to endure would be pretty horrible. Horrible for
both of you. I dont think you ought to take problems to the CEO, just
solutions. Explain the problems when you know how to solve them.
Hmmm.
The Heros Ordeal
198
Im a fan of the Doctrine of Completed Staff Work. Do you know it?
The basic idea is that you take completed solutions to your boss, not questions about what you should do. Y ou only go to the CEO when you understand everything and are confi dent of your solution. Y ou dont go looking
for input. Especially in an area like IT. Hard for you, torture for him.
The Doctrine of Completed Staff Work.
Ill send you a copy.*
Thanks. For a guy whod had such a hard time at IVK, Davies had
a lot of ideas. Lets order some lunch, Bill. Im buying.
Y ou dont have to do that . . .
I insist. Y oure providing the advice, Im buying the lunch.
If you insist, Davies said, looking pleased, Barton thought.
Friday, July 13, 8:54 PM . . .
Barton settled in at Vinnies. The kid was already there, fi nishing a
burger and watching a baseball game on the screen above the bar.
I missed you last week, said the kid, taking advantage of a
commercial break.
Sorry about that, said Barton. The holiday and all, you know?
And it was kind of a rough week.
Meeting on Saturday morning go well?
No, I wouldnt say so. Williams kind of lost it. Fired two people.
But not you.
No, not me.
Interesting.
I think hes keeping me around to take the blame if there are more
unfavorable developments.
Or maybe he genuinely needs you.
Barton shrugged. I dont know. But I think Im just going to play it
straight ahead. Do my job. Do as much as I can to address the weaknesses that our little problem exposed. Do as much as I can to rebuild
confi dence in my team and my own judgment. Its going to be slow, but
were going to press ahead, be as thorough and systematic as possible.
* See The Doctrine of Completed Staff Work at the end of this chapter.
Communication
199
Sounds like a good plan.
Not sure my troubles are over, though. I dont really approve of the
course of action Williams chose. He overruled my recommendation.
That hurt your feelings?
Nothing like that. I just dont think the choice he made is wise. And
Im worried that it puts me at risk too.
Time to depart?
Ive thought of that, believe me. I just dont want to go that route
right now.
Still got things to do, eh? Feeling the urge to bring things to a better
situation?
Maybe thats it. Whatever it is, now doesnt feel like time to move
on. If Im going to go, Williams will have to fi re me.
Im impressed.
Ha! Thats just because I cant tell you the details of how badly I
messed up.
Maybe not, but I think I get the idea.
The kid shifted focus back to the game. The home team was down
four runs in the bottom of the seventh inning, but they had loaded the
bases with nobody out, a situation that required total fan attention.
Barton was happy to put his own situation aside for a while and add his
cheers to the home teams cause.
REFLECTION
Conventional wisdom suggests that its important to manage your boss. As a
CIO, what is the best approach to managing your boss? How should Barton
handle the bad advice coming from Williams?
How should Barton communicate with people outside the IT department to
rebuild his organizations credibility?
In an environment of internet access and real-time information, how effective
is the Doctrine of Completed Staff Work?
The Heros Ordeal
200
Stakeholder Analysis
As the structure of the business fi rm has evolved away from the hierarchical, vertically integrated form associated with the industrial sector of
the economy toward more complex forms in which power is decentralized, and integration among organizational entities is less clear-cut than
before, the new organizational forms are more political, in an operational sense, than bureaucratic, and are marked by stakeholder groups
that form temporary coalitions to infl uence patterns of behavior. a
Within such political structures, organizational change is eff ected by
mobilizing key stakeholders to support specifi c projects and plans.
Stakeholders possess the infl uence or position to promote desired
changes. Some stakeholders also provide critical resourcestime,
money, and staff . Others possess substantive input and expertise.
Stakeholder analysis can be particularly useful to a CIO who is pursuing an initiative to transform a companys IT infrastructure from a
bottom-up evolutionary architecture to a secure, stable, scalable IT
network architecture. Unless each key stakeholder (individual and
group) is identifi ed and its stakes with respect to a new IT architecture mapped out and understood, it will be very diffi cult for the CIO
leader to realize his/her short- and long-range plans and goals. b
Stakeholder analysis is therefore a useful technique for injecting
some degree of certainty and control into what is most often a highly
political, even controversial, process. Furthermore, given the numerous choices of direction a CIO leader has in pursuing an architecture
program (i.e., systemwide or niche), a CIO is apt to pursue the most
suitable course of actionthat which leads most effi ciently to the
desired endsif he or she fi rst assesses the diff erent stakeholder
groups aff ected by the program to determine where sources of
support and/or resistance lie.
From a practical point of view, stakeholder analysis can assist the CIO
leader to:
1. Identify the universe of stakeholders. This includes stakeholders
at the corporate level (president, CEO, COO, so forth), at the
line-of-business level (group VPs, technical staff , users), and from
outside the organization (consultants, advisers). Analyze these
Communication
201
groups in terms of how critical they are to a project, and then
assess their motivation to support or resist the process.
2. Assess stakeholder importance and infl uence . Stakeholders do
not have equal impact on the architecture process. Some control
critical resources necessary to a project and have potential to be
Allies; others have the power to facilitate, transform, or block
implementation at diff erent stages of the process, and have
potential to be Network Members.
3. Determine stakeholder interests and motivations . Stake-
holders with mutual interests (whether personal, political, or business) are classifi ed as Allies and Network Members. Stakeholders
with confl icting interests are classifi ed as Blockers or Slowers.
The architecture stakeholder map emerges from this analysis:
Architects
action
D egree of com m on interes t
w ith architect
Res ources
D egree of interd ep end ence
w ith architecture p roces s
Sources of architect’ s need s
Political s up p ort
High
Low
Allies
Use as
power base
Blockers
Isolate them
and negotiate
Slowers
Negotiate
Network
members
Build strong
political network
Mutual Conflicting
Mutual Conflicting
Allies share the architects interests and vision. They sponsor and/
or provide project resources, including funds, manpower, and
time. They provide the power base.
Network members share common interests, but are less directly
involved in the architecture process on an ongoing basis. They are
a political resource for mobilizing otherwise recalcitrant groups.
The Heros Ordeal
202
Blockers are stakeholders who are logically and strategically
important to the architecture process, but whose confl icting
interests make them less-than-enthusiastic supporters. They
require negotiation.
Slowers are stakeholders whose indirect cooperation is needed,
but who do not overtly support the process; they may put up
indirect or subversive resistance. Slowers also require negotiation.
a. This analysis is adapted from Richard L. Nolan and Deborah M. Kolb, Architecture Leadership
and Stakeholders, Stage-by-Stage 7, no. 4, JulyAugust 1987 (Lexington, MA: Nolan, Norton &
Co., 1987), 19.
b. Architecture serves up blueprints for the technology infrastructureapplications, data, and
communicationsthat are manifestations of the overall business strategy. At the same time,
architecture is as much about organizational structure, culture, and practice as it is about
technology.
Communication
203
The Doctrine of Completed Staff Work
Completed staff work is the study of a problem, and presentation of a
solution, by a staff member in such form that all that remains to be done
on the part of the commander is to indicate approval or disapproval of
the completed action. a
The words completed action are emphasized
because the more diffi cult the problem is, the more the tendency is to
present the problem to the commander in a piecemeal fashion.
It is your duty as a staff member to work out the details. You should
not consult your commander in the determination of those details, no
matter how perplexing they may be. You may and should consult other
staff members. The product, whether it involves the pronouncement of
a new policy or aff ects an established one, when presented to the commander for approval or disapproval, must be worked out in a fi nished
form.
The impulse, which often comes to the inexperienced staff member,
to ask the commander what to do, recurs more often when the problem is diffi cult. It is accompanied by a feeling of mental frustration. It is
easy to ask the commander what to do, and it appears too easy for the
commander to answer. Resist the impulse. You will succumb to it only if
you do not know your job.
It is your job to advise your commander what she or he ought to do,
not to ask what you ought to do. The commander needs answers, not
questions. Your job is to study, write, restudy, and rewrite until you have
evolved a single proposed actionthe best one of all you have considered. Your commander merely approves or disapproves.
Do not worry your commander with long explanations and memos.
Writing a memo to your commander does not constitute completed
staff work. But writing a memo for your commander to send to someone else does. Your views should be placed before the commander in
fi nished form so that the commander can make them his or her views
simply by signing the document. In most instances, completed staff
work results in a single document prepared for the signature of the
commander without accompanying comment. If the proper result is
reached, the commander will usually recognize it at once. If the
commander wants comment or explanation, she or he will ask for it.
The Heros Ordeal
204
The theory of completed staff work does not preclude a rough draft,
but the rough draft must not be a half-baked idea. It must be complete
in every respect except that it lacks the requisite number of copies and
need not be neat. But a rough draft must not be an excuse for shifting
to the commander the burden of formulating the action.
The completed staff work theory may result in more work for the staff
member but it results in more freedom for the commander. This is as it
should be. Further, it accomplishes two things:
1. The commander is protected from half-baked ideas, voluminous
memos, and immature oral presentations.
2. The staff member who has a real idea to sell is enabled more
readily to fi nd a market.
When you have fi nished your completed staff work the fi nal test is
this: If you were the commander, would you be willing to sign the paper
you have prepared and stake your professional reputation on its being
right? If the answer is no, take it back and work it over, because it is not
yet completed staff work.
a. This generally applied military doctrine was circulated through U.S. Army General MacArthurs
headquarters during World War II.
part four
The Hero
Breaks
Through

207
chapter thirteen
Emerging Technology
Wednesday, August 8, 9:38 AM . . .
Jim Barton slammed his offi ce door and slapped a notepad down hard
onto the desk.
Why, he asked of no one in particular, does every interaction with
those guys have to be like a trip to the dentist?
The leadership team meeting had just broken up. It had been longer
than usual; there was a lot to work through. Much of it had to do with
IT. Most of that had amounted to listening to people complain.
The meeting hadnt even begun when Williams told Barton that
theyd have to reschedule a short meeting on their calendars for
Friday morning. The plan was for a fi fteen-minute updatejust fi fteen
minutesbut Williams, as it turned out, would be off-site during this
time. This was the third meeting in a row that Williams had canceled.
Is it the fact that were meeting on Friday? Would a different day be
better? Barton had asked. No, responded Williams. Fridays fi ne,
just not this Friday. Whats on our agenda this morning?
Barton had been trying to update his peers and Williams frequently
on upgrades and security measures, as Maggie had recommended. But
Barton had to admit that Davies was right about one thing: Williams
really didnt like to talk about IT.
The meetings were sheer torture. Barton had trouble explaining
things to Williams. Security was a pretty technical area, after all, and
The Hero Breaks Through
208
Barton was not a technical guy. But the alternativebringing Cho and
maybe Fenton to the meetings with himworked against Bartons other purpose, to rebuild the relationship between himself and the others. Having one or two hovering sidekicks to whom he kept turning
would make him seem unprepared and toosomething. Too Davieslike, maybe. Williams already had trouble hearing what Barton was
telling him; often an explanation of something IT-related ended with
Williams saying, No, I dont quite understand, but Im okay with you
deciding. Lets move on. At one particularly horrifying juncture, an
exasperated Williams had exclaimed to Barton, Speak English, man!
Not Habla ingl s? exactlythat notorious question Jim Barton had
once used to goad a hapless Daviesbut too near it for Bartons comfort. More than once, Barton had taken out the document Davies had
sent him, about completed staff work, to look for something useful,
something to make the meetings with Williams less painful.
Barton wanted to think that at some level Williams appreciated what
he was doing. But he wasnt sure. Since the security event in June, people seemed less willing to assume that Barton and the IT group were
doing things for good reasons. They were more inclined to secondguess, or label ideas dumb without taking the time to understand
them. A version of this problem had fi lled most of the time in todays
leadership team meeting. Someone had raised a question about why
the start of an IT project had been delayed several months. The answer,
Barton thought, was obvious: security upgrades needed to take priority. Surely everyone could agree to do the most urgent things fi rst? In
fact, everyone had agreed. But the fi rst question provoked a lengthy
round of questioning about the way other IT projects had been reprioritized. Barton and his staff had reshuffl ed priorities, but Barton
had made a point of communicating the proposed reordering to all
his peers so they could provide feedback or object. If anyone had seen
a problem, Barton would have happily addressed it. But no comments
had come back, none at all, and the IT department had gone ahead
with reprioritization. Since Barton had taken over control of the IT
budget in May, it was his decision, offi cially. But hed intended to make
the decisions in collaboration with the others. Now no one was acting
very collaborative.
Emerging Technology
209
As Maggie had put it back in May, it was Bartons neck alone in
the noose, and now the others seemed inclined to yank on the rope. In the
aftermath of the June event, no one deferred to Barton because of his former status as a big-shot business manager. Instead, it was yank, yank, yank.
Maybe, Barton said aloud, as he settled into his desk chair, its
time to go back to a committee structure for priority setting. Maybe
Davies had it right in the fi rst place. Davies had insisted on a committee with representatives from each of the business areas to decide
IT priorities. It operated very slowly and, worse than that, it allowed
business units to set aside concerns related to technical risks. The event
in June had been directly traceable to this very problem. But Barton
could not, of course, point that out because he had been the business
guy who had pushed his own project through, displacing the security
project that would have prevented the intrusion. I f there had been an
intrusion there was still no evidence of it and nothing more had happened. The hope for the best policy that Williams had chosen against
so many recommendations seemed to be working out. Y et another
way, Barton muttered, that Ive been wrong lately.
He looked up at his whiteboard, wondering what principle he should
add. Something about keeping his neck out of the noose, perhaps. But
he didnt want to give up control of the budget. That would just take
them back to the bad old days. Somehow, there had to be a reasonable
course that was none of the above. He made a mental note to discuss it
with his IT managers.
For the moment, though, he needed to turn his attention to the
fi nal item that had come up in the meeting. One of his colleagues had
asked, out of the blue, What is our social media strategy? Barton
had been somewhat prepared for this question because Bernie Ruben
had forwarded him a document a couple of days earlier arguing that
IVK should be more systematic in its thinking about this topic. Some
kid in Rubens organization was very hot on the business potential for
IVK of a bunch of new social connection technologies. Barton had
not dug into the issues yet, but he had been able to respond in the meeting saying, Y es, well, Ive just received a report from one of my staff on
that subject; there could be implications for us in some of the emerging
technologies in that category. I havent had time to look over the report
The Hero Breaks Through
210
carefully though, so let me get back to you on it at our next meeting. No
thanks to his own resourcefulness, Barton had looked reasonably good
at this juncture in the meeting, because hed seemed semi- prepared.
Now, Barton settled at his desk, located Rubens document and
opened it . . . G ot to get a better handle on this bef ore the M onday staf f
m eeting . . . Barton initiated a call to Ruben . . . Barton began to read
about a variety of emerging tech platforms that allowed people to connect socially within the organization and beyond . . . He wanted to talk
to Ruben and the report author before Monday . . . S ocial networking, a
way to im prove collaboration inside the fi rm . . . the call went to Rubens
voice mail, so Barton left a message asking him to call back . . . A way to
reach out to custom ers, new and old, through nontraditional channels . . .
Barton considered contacting the reports author directly . . . I t seem ed
like a broad category , pretty m uch any thing that connected people through
new channels, and, especially , brought custom ers closer . . . He decided
not to call the author . . . technologies that m ade the boundaries of the
com pany , the dif f erence between inside and outside, m ore blurry . . .
STOP, said Barton, to himself. Stop. Do one thing at a time. Since
the attack, about fi ve weeks now, Barton had been trapped in a cycle of
reacting, chasing one thing after another, fi ghting one fi re after another.
His attention was fragmented most of the time. This made it impossible for him to get any momentum, to formulate coherent plans. He
knew he had to halt this cycle. He just wasnt sure how.
L et s see , Barton thought, if I can begin to get things back together.
R ight now. I will read. I will do one thing at a tim e. I will act, not react.
He shut his eyes, then slowly opened them, beginning to read the
report, careful not to let his mind jump to anything else. With his frame
of mind thus changed, he began to fi nd the subject interesting. Eventually, he found his way to a section toward the end that listed some of
the IVK people who were participating in what the reports author kept
calling a social media revolution. Some items in the list were active
links to what looked like informal discussions online. Barton clicked on
one and found himself reading about one guys experiences working in
the customer support center at IVK.
Who can access this? Barton wondered. He thought he remembered
reading that these posts were all publicly accessible.
Emerging Technology
211
Clicking back to the report, he confi rmed this: everything listed was
accessible to anyone connected to the public internet. He returned to
the post by the Customer Service guy, scrolled down the page a bit, and
found, to his dismay, a description of a day in June when all the systems
at IVK went down for a while. It was the day of Bartons analyst meeting in New Y ork. The author even speculated, jokingly, about the cause
of the outage; his lighthearted list included viruses and maybe even
Russian or Chinese hackers.
Y ouve got to be kidding! Barton cried out before he stood and
went storming down the hall in search of answers.
Tuesday, August 14, 11:35 AM . . .
It seems to me, said Ruben, that we might need multiple policies
here. Hed clearly been giving serious thought to these issues, which
came as very good news to Barton.
We need one policy for the specifi c issue of social media posts
and other communications about what goes on inside IVK that
might casually leak outside and create complications for us. Probably this is partly about what we tell people they are allowed to say
publicly, and partly about creating a capacity in IVK to react to inevitable leakage.
We might need another policy to defi ne what constitutes helpful
and legitimate use of such approaches inside IVK. People are used to
the idea that company resources should be used for company business,
but these technologies blur the distinction between company and personal business. If sharing cheesecake recipes with someone from another part of the company leads to more productive interactions with
that colleague on an important business project, might that be something we might want to encourage?
We might also need more serious thinking on how to identify
emerging technologies that may be relevant to us in some way, so they
dont blindside us. The public post you found about our June incident
doesnt seem to have blown into a big issue, luckily, but its a bit alarming that this came up on us without us seeing it coming.
The Hero Breaks Through
212
Barton could only agree. But he sat quietly, listening, hoping for a
wide-ranging conversation amongst his team. He didnt want to shortcircuit that by wading in too soon.
Tyra Gordon responded to Ruben: And theres the specifi c issue of
what to do regarding this particular post about the June outage. Do we
try, now, to get it taken down?
It hasnt caused us any diffi culties so far, said Raj Juvvani. Id say
leave it alone. Trying to take it down might just draw attention to it.
Its not clear, said Ruben, that anyone could take it down. Its
cached on the internet. Someones got a copy.
Plus, Juvvani said, some of my guys know the person who posted
this. If we tried to get him to take it down, they think he might post
something about that. Hes a prickly guy, a potential loose cannon. If
we get him feeling righteous, that could make things worse.
Eyes turned toward Barton, looking for a reaction. He said nothing.
Three questions, then, Ruben continued. One: What, if anything,
should we do about this specifi c post about our June outage?
Nothing, said Juvvani. We should do nothing.
Ruben nodded and continued: Two: What should be our general
policy about communications on social media or anywhere else that
describe activities within the company?
Not an easy call, said Juvvani. People totally understand that they
dont go leaking proprietary info, say. But the complication here, with
this example, is that the info seems to the poster to be innocent and, well,
inconsequential. He thought he was posting about being bored at work.
Tons of implications here, agreed Gordon, Employee privacy,
protecting our proprietary info, not coming across to our employees as
overcontrolling jerks, and much more.
Ruben, still nodding, pressed on: Three: What should be our process
for spotting emerging technologies and analyzing them to get an early
heads-up on how they might have relevance to us, for better or worse?
Barton fi nally spoke: My fi rst inclination would be to put in place
a pretty restrictive policy on communicating company activity to the
outside. Weve got to control this.
Without coming across as over controlling jerks, repeated Gordon.
Have you discussed this with Williams? she asked.
Emerging Technology
213
Barton shook his head. I can barely get him to m eet with m e , thought
Barton. He said: I dont really know how to bring this up. If he knew
that there was a description on the web, accessible to anyone, of the
outage we experienced on June 28, hed probably fi re all of us. Its exactly the kind of disclosure he vowed we would not make.
Fenton spoke up: Just having a restrictive policy on these things
doesnt mean we can ignore the implications of new technologies. Its
not just come up with a rule and were done. I mean, we canmaybe,
if were willing to use a lot of monitoringprevent people from doing
unauthorized stuff at work. But even this isnt clear-cut, in that many
of us just dont make any distinction between our work and personal
devices. For all practical purposes, and often in reality, they are one and
the same. We can tell them they cant talk about work outside of work,
certainly not in social media. But its getting harder and harder to separate work time and personal time. Whether we like it or not, every single
employee now carries, at all times, at least one portable, personal, digital
data capture device. Its capable of taking photos and capturing video.
It can transmit any of these, along with personal commentary, in an
instant, out into the public cloud beyond our walls. Once its out there,
as Bernie says, its in the cloud. We cant easily recover it or get it taken
down. The problem, as I see it, is that the walls of our company are
permeable. Were living in an era of unprecedented transparency. How
should we change how we do business in an era of super-transparency? 1
The others considered this in silence.
Do any of you remember, asked Juvvani, breaking the quiet, that
N ew Y ork T im es article about how one stupid tweet blew up Justine
something-or-others life? 2
The others shook their heads.
She tweeted something dumb, hastily composed, right before an eleven-hour fl ight, and by the time she landed, she had lost her job. The tweet
went viral, made her seem like a racist. As the T im es points out, racist was
not the only way to interpret her badly worded tweet. But people framed
it with their own comments and interpretations. What they say you meant
might not be what you meant, but that might not matter. How do you
avoid that? How do you deal with it if it happens? Remember that guy who
posted a song on Y ouTube about how some airline destroyed his guitar? 3
The Hero Breaks Through
214
Again, the others had not.
Guess we know how Raj spends his free time, Gordon grinned.
Its relevant, Juvvani protested, also smiling. This guys song got
really famous. It was a pretty good song. Refl ected very badly on the
company, and they didnt respond for weeks.
It occurs to me, said Ruben, that the number and variety of digital
capture devices are proliferating also. The other day, one of my guys
was showing me a pen he uses to take notes in meetings. Apparently it
audio records and captures his notes at the same time. Later, he can go
back and listen to exactly what was being said when he took a certain
note, for clarifi cation. I didnt think too much about it at the time, but
I think he also said the data gets transmitted over the network to his
computer. Maybe to his personal storage area on the web.
Holy crap, said Barton. So an audio track from our meetings
might be instantly transmitted out to the internet?
Ill check to be sure, said Ruben, but I think thats what he said.
Should have registered more seriously with me at the time.
Raj, can you collect some more examples like the ones you mentioned? said Barton. Id like to use them as a basis for raising this issue
with Williams, to get some feedback from him on it. Get him behind
putting out a policy on this. For the time being, Im not going to tell
him about the existing post about June 28, and Im not going to talk
about Bernies guys recording pen. No examples from inside IVK, not
yet. So dont talk about this stuff outside this room. Bernie, dont approach your guy with the pen. Maybe when we send out our new policy,
these guys, both of them, will realize theyre out of compliance and take
corrective action themselves, without us having to single anyone out.
That makes sense, said Ruben, much better than an effort targeted at specifi c individuals.
Barton was nodding. Now, Bernie, we need you and your team to
come up with a fi rst draft of the policy. Also take the lead in making sure
these things dont blindside us again. I want a process, a way of getting
an early warning of emerging technologies coming and understanding
what they might mean for us.
Jim, Bernie, hang on a second, interjected Juvvani. When you take
these issues to Williams, I just want us to be sure that these kinds of
Emerging Technology
215
technologies dont come out looking like the enemy. Theres serious business potential in this area. I think some of our people in marketing are
already playing around with some of it, and I know our competitors are
tapping into these technologies. Ive got a team on my Customer Support
staff right now thats using a discussion forum to get our key partners
involved in new service developments; Ive got more ideas Id like to discuss when the dust settles. In the meantime, we dont want to rush into
restrictive policies that kill creativity. Were already playing catch-up.
Raj is right, added Fenton. There are serious pros as well as cons
here. I was just reading in this book, T he B roadband E xplosion , about
these two internet guys, Licklider and Taylor. 4 Back in the 19 6 0s, they
predicted all sorts of creative communication possibilities on the net
stuff like real-time collaboration, online communities, peer-to-peer
APIs. Were well into the twenty-fi rst century, and were just starting to
realize the potential of these technologies.
For inside the company as well, added Juvvani. I read something
recently about a company that wanted to make itself more innovative by
creating new weak ties inside the fi rm. 5 They hoped to create interest
groups and communities around a range of topics inside the fi rm, to get
people talking who dont usually have work reasons to talk. So, to borrow
Bernies earlier example, you might discover that you share a passion for
cheesecake recipes with someone in sales. Y ou get to know each other
by sharing recipes, and one day this results in some really productive
cross-fertilization of ideas that is business related, when you strike up a
conversation for a business reason with this person you already know.
That was the idea. Communities about cheesecake, communities about
dog breeding, tourism, whatever, create more connections between people at work. Not strong ties, which are for specifi c work reasons, but
weak tiesmore informal, accidental ties. Cross-fertilization across the
informal social links is more likely to result in new and diverse ideas
than interaction across the formal links we use on the job every day. The
ending of this story that I read was unhappy, though. The companys
policies against non-business use of business resources kept the communities from ever gaining momentum. People werent sure they were
supposed to talk about cheesecake on company networks, so they didnt.
And, in the end, it didnt work. Never really had a chance to. 6
The Hero Breaks Through
216
Okay, agreed Barton, Clearly, were going to need to discuss this
some more, but Ill see what I can get into my conversation with Williams. Ill need to keep it brief. Hes not going to want to hear about a
lot of hypothetical, futuristic stuff.
Ive got an argument that may work with Williams, added Ruben.
IT is like a high-tech businesshigh-tech businesses spend about 10
percent of their revenue on keeping up with new technologies, processes, products. IVK needs to keep up too, by scanning new technologies,
allocating resources for that purpose.
Write that down, will you Bernie? Raj, get me a project report on
the discussion forum thing, maybe a few other concrete ideas your
team has for adding business value, and back it up with whatever information you have on what our competitors are trying. Ill put that
alongside your more risk-oriented examples. Barton stood. Any of
the rest of you have something to add, get your ideas to Bernie. Okay?
Everyone indicated agreement.
Lets get out of here, said Barton. Im ready for lunch.
Thursday, August 16, 4:02 AM . . .
Barton sat straight up in bed, startled awake. Through the fog of sudden consciousness, images from his nightmare came forward: he was
standing before all of IVK senior leadership and the board of directors.
A red-faced Williams singled him out with a long fi nger of ridicule and
roared: Y OU! Where did you get that awful tie? Raucous laughter
erupted from his colleagues. Barton looked down to see that he was
indeed wearing an enormous, holiday-inspired tie . . . and nothing else!
He fell back onto his pillow, emitting a groan of despair: Im turning into Davies!
Friday, August 17, 3:23 PM . . .
Despite himself, Barton remained annoyed by the recently discovered
information leak, and by the idea that now he had social media technologies to try to keep up with on top of everything else. Hed have preferred to
simply strike it from his list of concerns. But he took a deep breath and
Emerging Technology
217
reminded himself that this was just another example of having to know
what y ou don t know . He could, no doubt, add a whole slew of potentially
important new technologies to his ever growing dont know list.
He took a fresh look at Ruben and Juvvanis reports. These guys were in
the know, or getting there, and Juvvani in particular appeared savvy and
eager to pursue the new possibilities. Barton gazed up at his whiteboard,
at the priorities scheme. Maybe social technology was something for the
option-creating investments list, one of these breakthrough possibilities,
with future value that was hard to perceive up front. 7
He forced himself
up to his whiteboard and added: Harness the power of new technologies
(dont sweep under the rug). But how to identify the most important?
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1 7/6 8/3 9/7
$75.12 $30.72 31.90 30.88 32.02 38.07
4.77B 1.95B 2.03B 1.96B 2.03B 2.42B
+ + +
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Harness the power of new
technologies (dont sweep under
the rug)
Communication
Always tell your boss bad news first; tell him as
soon as the possibility is known; dont put it off
until you know it for sure.
But SYH2DP
Effectively communicating IT-related business
issues to business managers requires SYSTEMATIC
EFFORT, just like everything else you try to accomplish
in business; spend sufficient time on it.
The Hero Breaks Through
218
Suddenly, Barton thought of his nephew Jackmaybe hed know
something about this stuff. He was always sending Barton the wildest
stuff. The chance Jack would be a source of information about all this
was a good enough excuse for Barton to call his nephew and ask for
some gaming time this weekend. A few hours of mindless time laying
waste to bad guys in the latest online game sounded just about right.
REFLECTION
Given near-universal web access, ubiquitious personal net-connected portable
devices, and the widespread use of social technologies, can companies still keep
their information secret? As a manager, what should you assume people
outside the company know?
How would you respond to Bernie Rubens three questions about how IVK
should respond to emerging technologies?
What advice would you offer to Barton to help him break the cycle of constant
firefighting? Is Barton becoming like Davies? Is this inevitable?
As IT increasingly penetrates into our daily lives, do you think younger
employees might think about and do work differently than earlier generations?
If so, what kinds of difficulties or opportunities might arise from this difference?
219
chapter fourteen
Vendor Partnering
Thursday, September 27, 10:55 AM . . .
I tell you, thats simply not going to work! The speaker pounded his
fi st on the table. Others in the room let loose a collective sigh. Frustration fi lled the air like an unpleasant smell.
Barton sat at the back of the conference room, listening. He struggled to control an urge to wade in with his opinion. Two camps had
formed, and they disagreed bitterly. Twice before, in the span of a week,
hed sat through unproductive meetings on this or related topics. The
group leading the effort to replace IVKs increasingly decrepit backoffi ce systems, the IR team, had been basically stuck for months now.
Someone, or something, needed to break the pattern of dysfunction.
But not Jim Barton. He was the one person in the company who
could not do it, who had to stay out of it. Hed dealt a major setback to
the effort when hed canceled the NetiFects contract in May. It had been
one of his earliest actions, arguably the most decisive. But, also, Barton
knew, the most second-guessed. Barton still believed it had been the
right move, but his role in slowing the project down made him both
desperate to see the group regain forward momentum and certain that
he could not again intervene without creating even greater problems.
When Barton had jettisoned NetiFects, the IVK cross-disciplinary,
business-led group that had been working on back-offi ce systems replacement had seemed to take it well. Theyd had their own
The Hero Breaks Through
220
frustrations with NetiFects. Many of them felt satisfaction when Barton
summarily dismissed smooth-talking Carlton Leopold. But hard feelings toward Barton lingered among members of the group, born of
the fact that Barton had made the decision to fi re NetiFects without
consulting them. His unilateral decision to add IT people to the groups
membership, justifi ed by an assertion that the group needed more
technical experts to ensure adequate evaluation of the merits of solutions proposed by vendors, added insult to injury. Everyone knew that
technical evaluation was important. But the group felt that Barton had
gone too far and exerted too much infl uence.
They had agreed, in response to Bartons urging, that they would
avoid the paralysis that had set in last time as a result of the sheer size of
the project, by starting with an off-the-shelf solution. They would not
develop a custom system out of small components and services, using a
consultant for new software development, which was where the previous plan was going. Instead, theyd start with a big, central piece and
use consultants to help install it, interface other standard packages and
services into it, and perhaps customize parts of it. This agreement, however, formed a foundation for three newand major disagreements.
The fi rst centered on selection of the off-the-shelf solution. The
group had narrowed an initial list of more than twenty candidates
down to three fi nalists. Much of this work had been straightforward.
Choice of a solution meant choice of the vendor that would become
a long-term IVK partner, and many companies that submitted initial
proposals were, for one reason or another, unsuitable partners (too
small, too close to a major competitor). Others had obviously inferior
offerings. The handful that remained after an early cut had to be evaluated more carefully.
That summer, the group had issued a request for proposal. This
RFP asked vendors to self-assess the degree of fi t between their solution and the specifi cation that IVK had developed when the emphasis
had been on working with NetiFects to create a customized system.
The IVK team then set out to verify the degree of fi t claimed by the
top seven vendors. They visited vendor sites, watched demonstrations
of solutions in action, discussed experiences with reference customers,
and attended a fi nal presentation by each vendor. Every member of the
Vendor Partnering
221
team had also, in theory, carefully reviewed each of the multivolume
proposals submitted by vendors. Upon receiving the proposals, some
on the team had joked that the contestants seemed to think they would
be chosen based on the weight of proposal binders. The documents
made substantial and diffi cult reading. Gradually, however, the group
ruled out candidates from the list of seven until just three remained,
each with signifi cant appeal to a subgroup within the IR team.*
HiOSoft had historically operated primarily as a software company
focused on a product line for customers in many more businesses than
fi nancial services. Over the years, it had gradually evolved in the direction of hosted services delivered over the network. HiOSofts proposal
fi t IVKs requirements reasonably well, but it was arguably the least
suitable solution without signifi cant customization. Also, because the
company had not been a services fi rm historically, its implementation
plan relied a great deal on partners; the IVK team agreed that HiOSoft
probably ranked third in maturity of service offerings. But its solution
had one compelling strength: a very open architecture, which would
arguably make any customization IVK needed to do in the future easier. Products and services from other vendors could be plugged into it.
Still, though the proposed solution fared well in terms of fl exibility, it
measured up less well in terms of robustness. The company had been
late to the market for industrial-strength, high-reliability solutions, so
there were questions marks in this area that disconcerted some. Other
(mostly IT) people believed there was no real reason you shouldnt be
able to engineer a very robust system based on the HiOSoft proposal.
On the IVK IR team, HiOSoft and its solution had support among the
smallest minority, much of it from people who had favored the initial
NetiFects component-based approach; it also enjoyed disproportionate support from technical members of the IR team.
VerxaWeb had been labeled by its detractors the sentimental favorite. And it was truepeople liked VerxaWeb. Its products and
services specialized in the fi nancial services industry. VerxaWeb spoke
IVKs language, and the two organizations fi t well together culturally.
Its solution fi t well with IVKs specifi cation. But some on the IVK team
*See Vendor Assessment Matrices at the end of this chapter.
The Hero Breaks Through
222
felt that the considerably smaller and less fi nancially successful vendor
tried too hard. They worried about long-term viability of this potential
partner. VerxaWeb, some worried, might be a partner that IVK would
too soon outgrow.
No one had such worries about ServoLith, by far the largest and
most successful company in the group of fi nalists. Its solution focused
less on fi nancial services, but fi t well with the specifi cation. The concern with ServoLith: whether the vendors size and success would make
IVK, a relatively small company among ServoLith clients, a lowpriority customer. Past dealings had also soured a lot of people on this
vendor. Words used to describe ServoLith included arrogant, overpriced, and unresponsive. During the vendor presentations, some
had felt vindicated in their harsh assessments when ServoLith failed to
produce a technical expert as promised, instead substituting someone
more junior. ServoLith representatives said that the expert had been
detained because of a personal matter. But the explanation that came
through the grapevine, from someone who knew someone who knew
someone in the ServoLith organization, contradicted that assertion.
Supposedly, clients at a major companymuch bigger than IVKhad
summoned the technical expert to their site on the day hed been promised to IVK; the big clients demands had won out against the request
from a prospective, smallish client. To some, this was a red fl ag; it might
very well be a behavior destined to be repeated if IVK chose to work
with ServoLith. Nevertheless, the choice of ServoLith, the industry
leader, would be defensible to analysts, shareholders, and executives,
no matter how you looked at it. Because this vendor had so many large
clients, there were few doubts about the scalability or robustness of its
products. Questions centered mostly on whether it would be a suffi –
ciently attentive partner.
To Barton, HiOSoft appeared to be losing out as increasingly strident voices gathered around the other two vendors. Advocates of
ServoLith accused proponents of VerxaWeb of ignoring hard facts in
favor of mysterious intangibles. VerxaWeb advocates accused proponents of ServoLith of taking too little account of people factors and
past experience with that vendor. Barton thought positions appeared
to be hardening, and he saw no indications that the group would break
Vendor Partnering
223
through to consensus anytime soon. If hed dared enter the debate, he
would have urged that they focus less on deciding and more on coming
up with an agreed method for making a decision theyd all consider
reasonable and by which theyd all be willing to abide. But he didnt
dare enter, at least not yet.
The second major topic of debate had to do with the proposed
contract structure that would defi ne the relationship with whichever
vendor might eventually be chosen. In this discussion, the divide had
formed around what Barton thought of as hard-line and the softcooperation philosophies.
Hard-liners advocated service-level agreements (SLAs) with, as they
put it, real teeth. If the vendor failed to deliver services as contracted
on the schedule laid out in the SLA, then the vendor would pay signifi cant and painful penalties to IVK. Those who favored this approach
believed it would assure maximum effort from the vendor and strong
alignment of the interests of the two parties. This group was also more
likely to be interested in front-loading the vendor contract in IVKs
favor, so that benefi ts would be realized by the vendor only after the
partnership had been in place for a while and the benefi ts of the partnership to IVK had become obvious. In this sort of scheme, IVK would
pay discounted prices to the vendor at fi rst, and payments would become more lucrative for the vendor as the initiative progressed.
The soft cooperators argued for a more collaborative and less adversarial contractual approach. They believed the SLA should be in place
to eliminate ambiguity in defi nitions of vendor performance, but
they did not see the point in severe penalties that might, at least in the
case of VerxaWeb, actually harm the vendor partner (there was signifi –
cant overlap between the people of this opinion and those who favored
VerxaWeb). This contingent also opposed an adversarial approach to
the payment schedule for the vendor, and instead proposed setting up
a contract based on fairness and profi tability for both parties.
The debate about contract structure interacted with the debate
about choice of vendor. In particular, some observed that IVKs ability to dictate contract terms would be considerably diminished if they
chose ServoLith. That large company, which could, in the fi nal analysis,
easily afford to lose IVKs business, would be less fl exible on contract
The Hero Breaks Through
224
terms and much else. Probably IVK would have to work with ServoLith
on relatively standard terms that the vendor would disproportionately
dictate. Standard ServoLith contracts would be designed, no doubt, to
avoid any serious teeth that might impact the vendor. In contrast, IVK
would have a great deal of contract negotiation leverage with VerxaWeb, whose managers seemed especially hungry for the IVK deal; IVK
would be able to put big teeth in the deal, but teeth too big might chew
hard into VerxaWeb. The coalition of vendors specifi ed in the proposal
from HiOSoft offered fl exibility in contracting, but also complexity
that might be hard to manage. In the HiOSoft proposal, there would be
many SLAs, each with a different partner.
The third major disagreement centered on what the group had labeled the service delivery model. The three vendors had proposed quite
different ways to meet the requirements in the IVK specifi cation, and
very different structures of ownership.
ServoLith, for example, had proposed what it called a total cloud
solution, in which the vendor would own all the equipment and software, which would run on its site, and provide services to IVKs business and clients over network connections. IVK would pay for these
services in a monthly fee, the way they bought power and paid rent.
Some members of the group positively loved this idea; they argued that
IVK should not be in the business of running data centers or developing basic software systems. They allowed that IVK might want to run
its own software in certain areas key to maintaining competitive advantage, but moving nonessential services to a vendor would make it
easier, they believed, to focus on the IT services that provided competitive advantage. For most of what ServoLith proposed to do, IVK would
never be as expert as the vendor, which had vast experience with many
other clients and many more specialized resources than IVK could ever
bring to bear.
Those who disliked the software as a service model proposed by
ServoLith tended to point to what they saw as the loss of control inherent in the model. ServoLith would keep IVK data inside its facilities
and equipment and control IVKs access to it. If the vendor proved unresponsive, the result could cripple IVK. Some, notably John Cho, worried about the security implications of what he called this rush to the
Vendor Partnering
225
cloud. In addition, part of the ServoLith strategy of operating this way
appeared to be based on its intention to share solutions and computing
resources across clients, to realize greater effi ciencies and scale economies, from which it promised to produce long-term cost savings that it
would share with its customers. This could mean, in theory, however,
that IVK system performance levels could interact with the load on the
systems of other companies that ServoLith hosted alongside IVKs. Or
even, some fretted, that IVK-specifi c functionality might end up being
marketed by ServoLith to IVK competitors; after all, the whole point of
ServoLiths service delivery model was to share learning and effi ciencies across clients. The vendor worked hard to put a positive spin on
this, but that wasnt the only way to think about it.
VerxaWeb proposed a solution with very different features. Its representatives went to great pains to reassure IVK managers that they
would remain in charge of their own systems and operations. VerxaWeb proposed installing IVK systems on IVK equipment running in
IVK data centers (or space IVK had rented from a third party). VerxaWebs proposal included an option to provide operations staff who
would manage IVK systems and equipment inside IVK walls, but it was
just an option, and it was as far as its proposal went in that direction.
The proposal did not, of course, rule out any future outsourcing, but
it represented on the whole a more modest service delivery proposal
than what had been offered by ServoLith, and one that was also priced
more moderately. VerxaWeb insisted it could deliver cloud effi ciencies but without taking IVK systems or data away from IVK (some on
the IVK IT team doubted this). And VerxaWeb explicitly assured IVK
that it would not remarket solutions to IVK competitors. This vendor
promised, in fact, not to work for any of IVKs top competitors.
HighOSoft left the question of service architecture completely open.
Its proposal had assumed that IVK would be contracting separately
with other partners, and the service architecture would be determined
by how IVK decided to set up these partnerships. Whatever IVK wanted
to do about partnership and contract arrangements would be okay
with HiOSoft; it was mainly looking to sell a software package. The only
aspect of the solution on which this vendor was infl exible: the broad
technical specifi cations of the service architecture at the center of the
The Hero Breaks Through
226
proposal, which set up a standard framework that all the components
of the solution would plug into. This approach provided IVK with
maximum fl exibilityplug in whatever you want, do whatever you
want on premises or in the cloudbut it also meant maximum relationship overhead for IVK. It risked forcing many decisions back onto
IVK and causing the same kind of paralysis that had been the norm in
the NetiFects era. Unlike the solution proposed by the other two fi nalists, this one did not explicitly offer one throat to choke in its support
arrangements. In other words, if something went wrong in the ServoLith model, thered be only one party to call: ServoLith. The VerxaWeb
proposal had a similar feature, and this potential partner would likely
feel the grip of IVKs metaphorical fi ngers much more pressingly than
would ServoLith. HiOSoft would not object to IVK setting up a single
point of contact for service, a single throat to choke, as part of its web of
involved partners, but this arrangement wasnt inherent in its proposal.
Barton was not at all confi dent that he knew the solution to all these
problems, but he grew increasingly impatient with the debate. He worried, too, that none of the vendors might be able to do a really good job on
such a big infrastructure replacement, at least not on schedule and budget.
There were plenty of horror stories about such major projects, complete
with legal battles between partners over whose fault the failure might be.
As the latest acrimonious meeting ended, Barton thought far too
much remained up in the air. It felt to him like a form of torture, following a discussion headed nowhere without being able to intervene.
But it was torture of his own making, the result of his own decisions,
which had seemed right at the time but now cast a long dark shadow.
Perhaps he had acted too hastily. Perhaps. But what was done was done.
Barton believed he now needed to do something really hard but really
essentialtrust the team to work through its own difficulties.
Monday, October 1, 11:00 AM . . .
As Barton stepped into Maria Navarros offi ce for their scheduled meeting, he felt himself relax. Maria had that wonderful ability to seem like
anyones confi dante. Probably that was a major reason for her success
Vendor Partnering
227
as an HR executive. Certainly it worked with Barton, even though he
knew he should be wary. The HR VP was also involved in fi rings, demotions, and other adverse outcomes. She was, Barton knew, very tough
under that warm exterior. But she and Barton had known each other
for a long time and had worked together often, so he tended to feel at
ease with her.
Hows it going, Jim? she asked, as she motioned him into a chair.
He shut the offi ce door before he complied. Its getting better,
Barton said.
Williams has been pretty hard on you, I imagine.
Its been tough with Carl for a few months, but Im pressing on. Its
getting better, he repeated, not altogether convincingly.
How about with your peers?
I think were building back some credibility.
Navarro, in that maddening way of HR managers, was noncommittal. She looked sympathetic, but offered no corroboration that would
stake her to a position on how Barton was doing. Then she changed the
subject, which was just as well.
Youve got a hiring issue you wanted to talk about?
Yes, said Barton. You remember the NetiFects situation?
You terminated their contract, as I recall, said Navarro.
I did. A decision with aftershocks. Among the issues weve had to
deal with in the aftermath: we lost access to some of their very good
people. One of them, Ash Srinivasa, is now signaling to us his availability and desire to work for IVK. Wed like to hire him.
Whats the situation with NetiFects? Is that resolved?
No. Theyre still maintaining that we owe them several hundred
thousand dollars. Im arguing that they failed to perform. It wont
come to anything. Theyll keep billing us, well keep refusing to pay.
But it wont go further.
Unless theres an issue around hiring one of their key people.
Exactly. Sometimes hiring from a vendor is no big deal. Some vendors expect a certain amount of that. Others make you agree not to do
it. NetiFects is the latter kind, although we no longer have a contract
with them.
What kind of contract doeswhats his name?
The Hero Breaks Through
228
Srinivasa.
What kind of contract does he have?
I think theres something in it saying he cant go to work for a client
for some period of time without NetiFects offi cial permission.
Probably not enforceable. But possible basis for a skirmish. How
good is this guy?
Very. Worth a skirmish, probably.
I think we go for it, then. Theyre likely to try to intimidate him.
Theyll go at him, not us. Or they might just let the whole thing slide.
But let me ask you another question, Navarro said. Barton nodded,
and she continued: Why do we need someone this good?
You can never have enough good people, said Barton, wincing inwardly as he said it, at how much that sounded like reciting an HR
platitude at the HR director.
But arent we headed toward more outsourcing in the future?
Probably.
How many very good people will we need in that future? Wont we
just need smart contract managers?
Its a good question, conceded Barton. But we need some real
expertise in-house even when we outsource, so that we can manage
the partnership effectively. Thats what went wrong with the NetiFects
relationship. We didnt have people on it who could supervise their
work, and they were taking advantage of that.
But will we even be able to retain people like this Srinivasa in the
long run? Will he be interested in a job thats mostly contract management? Will he be as good at that?
Also good questions. My guess is well always have some need
for really good technical specialists, but Im not sure how we stay
attractive to them if we outsource more of our IT. We need to think
about a future when well acquire more IT capabilities as services
and manage more vendor contracts. What does vendor management
look like in the long run? What kinds of people will allow us to do it
effectively? Well need to work our way into answers for questions
like these, by trying different things, seeing how they work. Meanwhile, I think we could use this guy. My people think hed really be
able to help us.
Vendor Partnering
229
Navarro nodded again. Lets move forward with it then. Just let me
know if you need any more help from me.
Barton stood. I will.
Take care of yourself, Jim. She winked at him. Barton felt his defenses falling, then made a deliberate effort to pull them back up. And
use some of that vacation time youre accruing, she called after him, as
he started down the hall.
Ill do that. Thanks, Maria.
Vacation? Geez, its already October! thought Barton. He hadnt meant
to wait so long without going somewhere with Maggie. When hed
canceled their summer vacationtwo weeks in Italyhe was amazed
she hadnt dumped him. But he just couldnt see leaving IVK at such
a critical time. Who knew what kind of revolt might have arisen in his
absence? In a particularly memorable nightmare, Barton had returned
from Europe to fi nd Davies reinstated as CIO, sitting in his chair.
In the fi rst few months theyd dated, Barton and Maggie had mastered the romantic getaway: skiing in Aspen, cruising to Cabo; even
an impromptu weekend in Paris. Theyd always compensated for their
awkward schedules, the time apart necessitated by two high-powered
careers, by taking relatively short but really fabulous trips when they
could get away. Now they were long overdue for one of these. Hadnt
Maggie just said something about scuba diving in Bermuda? Maybe he
could make something happen before the month was over. The matter defi nitely needed tending, Barton thought. Just the possibility of a
vacation lightened his step as he headed back to his offi ce to do some
research.
Thursday, October 4, 4:37 PM . . .
Barton knocked softly at the edge of Bernie Rubens open door. Ruben
motioned him in and Barton took up his usual position, moving a pile
of papers to clear a place to sit, also as usual.
Whats up, Jim? asked Ruben.
Oh, the usual, said Barton. Something Ive been mulling over that
I want to bounce around with you.
The Hero Breaks Through
230
Bounce away, said Ruben. He leaned back in his chair, put his
hands behind his head, and fi xed his attention on Barton.
I had a conversation with Maria, in HR, the other day, Barton
explained. She was asking questions about our intention to hire
Srinivasa.
Oh, said Ruben. I thought she was on board with that.
She is, Barton responded. But she asked whether we think well
be able to keep him in the long run, given that we think were headed
toward more service-oriented approaches. Whether, in the long run,
hell be interested and good at a job thats mainly about contract and
partner relationship management.
Those are good questions, said Ruben. I guess Id say weve got
enough short-term fi sh to fry to make it worth hiring Srinivasa, even if
we cant retain him long term.
Yes, said Barton, thats basically where I come out on that, and
weve started the process. But thats not the only thing that got me
thinking.
Oh, said Ruben. He waited for the rest of the story. Barton
continued.
The day after I chatted with Maria, I read an article admittedly,
about a completely different company in a completely different
industrythat fi red up some new questions concerning our long-term
approach to working with partners. Im not even sure this is relevant.
Thats why I came to you. For a sanity check. The company Im talking
about is Boeing.
Barton paused, waiting for a reaction from Ruben.
That is a pretty different company and industry, he agreed. But
that doesnt mean we cant learn something from them. Theyve taken
a pretty ambitious approach to global sourcing and vendor partnering,
from what Ive seen.
Exactly, said Barton. Theyve explicitly sought out heavyweight
partners with expertise they dont have, and theyve been willing to
go anywhere in the world for that expertise. Theyre drawing from a
global talent pool.
Theyre doing a lot of things outside the fi rm that they have historically done inside it. Theyve reconceptualized their idea about what
Vendor Partnering
231
they do. Now they think of themselves as the experts in how everything
integrates into a best-in-the-world system, but not necessarily in all
areas of vital deep expertise. Big culture change for them. It would be,
right? Some of it is about sourcing, but its more than that. They call it
creating a network of strategic partners and moving from vertically
integrated to virtually integrated. IT is the key enabler of virtual integration, of course. They talk, too, about a shift from owner control processes to partner coordination processes, which raises issuesjust for
example, of how best to build trust and design contracts with partners
that engender shared risk-taking, shared motivation and commitment,
and incentives to share knowledge across organizational boundaries. 1
These are pretty big thoughts, said Barton. And after sitting
through quite a few debates recently in IR team meetings, which are
mostly about VerxaWeb versus ServoLith, and hearing Marias questions about the long-run approach well take to retaining talent,
well . . . it all has me wondering if were doing this right.
He stopped, to give Ruben an opening to comment.
Well, Ruben offered, just talking off the top of my head, I have to
admit I have trouble imagining what the equivalent of such an ambitious approach for our business would look like.
Barton nodded. The differences are signifi cant.
Were not so much about physical products, were a fi nancial services fi rm, observed Ruben. We trade in fi nancial and customer
information.
Its not clear, though, that our data is any more sensitive than what
Boeing shares with its partners, said Barton.
No. But our industry might not be as mature when it comes to
partnering. And the role we play in our industry is not really equivalent
to the role Boeing plays in theirs.
Yeah, Barton agreed, Im not proposing anything specifi c here,
other than that we ought to think about this. Im afraid were getting mired in muck, fi ghting it out over the small stuff, when maybe
we ought to be stepping back and thinking more big picture, more
long term. What does the future of our business look like if we completely reimagined it around a much more partner-based, virtual, and
globalized concept?
The Hero Breaks Through
232
Ruben didnt answer, just shook his head.
Barton laughed. Too big a question for this late on a Thursday
afternoon.
And its not as if we havent already been a bit overwhelmed by the
scale of the IR project, noted Ruben.
Hah! said Barton. You are certainly right about that. He stood.
Whatever we do, we cant bring this up in an IR project team meeting!
Ruben laughed.
Night, Bernie, said Barton.
Good night, boss, said Ruben.
REFLECTION
Should acquisition of infrastructure replacement services be an arms-length
transaction or a close partnership transaction?
Which vendor, contract structure, and service delivery model should IVK
choose?
How important is control to a company like IVK when outsourcing IT? How
should control be maintained?
How should IVK hire to support contract management? Will very good technical
employees be needed in a future characterized by high levels of IT outsourcing?
What does the future of a loan-based financial services business look like,
completely reimagined around a much more partner-based, virtual, and
globalized concept? Is IVK being ambitious enough?
Vendor Partnering
233
Vendor Assessment Matrices
Percentage of t
Functional criteria HiOSoft VerxaWeb ServoLith
itacilppacinortcelE no 001001 69
irocstiderC gn 28 89 89
issecorpnoisiceD gn 57 99 79
emeganamwoflkroW tn 87 49 68
ecafretniecivresremotsuC 00179 79
ecafretnismetsyslaicnaniF 001 00189
Client management functions 87 94 89
emesrubsiD tn 001001001
itarepotsuborrofngiseD no 49 39 99
ilibalacS yt 49 00119
htO re 88 98 59
Rating
Q airetircevitatilau VtfoSOiH erxaWeb ServoLith
Long-term relationship potential M H M
Research and development capability M MH H
Understanding of IVK culture and challenges M H M
ilibaivlaicnaniF yt M M H
erutcetihcrafossennepO H M M
oC ts M LM H
Technical support capabilities and plan M M M
Dependence on subcontractors in proposed
itulos no H M L
Compatibility with existing IVK infrastructure
).cte,SMBD( H HM M
Compatibility with existing IVK applications H M M
Confidence in project management capability ML M MH
ilibixefltcartnoC yt H H L
Likely attentiveness to IVK concerns M H M
lpdnaytilibapacgniniarT na M H M
Financial service industry experience M MH M
tcaftrofmoc,selbignatnI ro M H M
itisoptekraM no redaeLdrihTdnoceS

235
chapter fifteen
Managing Talent
Thursday, November 8, 10:13 AM . . .
Barton had just begun to dig into his workfl ow backlog when Tyra
Gordon knocked gently on the frame of his open door.
Hi, Tyra, said Barton.
Got a minute? she asked.
More than that, if you need it. Come in.
Gordon entered the offi ce and made a point of shutting the door
before settling into a chair.
Whats up? Barton asked.
Well . . . Gordon looked hesitant. Id like your advice. Ive encountered a situation that Im not sure how to handle. If you tell me to go
fi gure it out, that its my job, Id consider it reasonable. But Id value
hearing your thoughts.
Ill do my best to give them to you straight, said Barton, becoming
more curious by the second.
Okay. Well. Y ou remember Ivan Korsky?
Sure, I know Ivan. Hes one of your top guys, right?
Exactly. Hes what you might call a uniquely talented member of
our staff. He has a very uncommon combination of skills. Hes a top
software developer who has at least a ten-times productivity advantage
over the next-best person we have when hes writing code.
Ten times?
The Hero Breaks Through
236
Easily. Its pretty common in this kind of job to see signifi cant
disparities in ability. Its not like other kinds of work, where the guy
who does it best might be one and a half times faster or better than
the next person. In IT, especially in an area like software development,
some people work a lot faster and a lot better than others.
Which surely has implications for how we recruit, supervise, and
manage.
Defi nitely. But Ivan is not just a brilliant coder; hes also a brilliant
architect. He has the ability to envision and design complete solutions
that work and scale. Give him a pen and a whiteboard, sit a bunch of
developers down in front of him, and you can sit back and marvel at
what comes to pass.
Sounds incredibly important.
Its amazing that weve been able to retain him. Several major software companies have tried to hire him. But he has family in this area
and doesnt want to move. Theres a constant threat that some start-up
might nab him, but were benefi ting from the relative absence of tech
companies in our area.
Do we have a way of formally designating people with this level of
talent in our HR management process? We might want to discuss this
with Maria Navarro.
If we lost Ivan, it would defi nitely set us back months, maybe years.
Hes not quite irreplaceable; its been my experience that even when you
lose your most important resources, someone eventually steps up to do
a pretty good job. But we need to admit that Ivans replacement would
be unlikely to have his unique combination of talents. His replacement
would probably surprise us with strong performance, but still wouldnt
bring to the table what Ivan does.
Who else do we have in this category?
Y oud need to ask the other managers to be sure, but we defi nitely
have others. Raj has one or two, probably not quite like Ivan, but very
important to what weve got going on. Bernie has a couple of database specialists who would be very hard to replace, and Paul has Cho,
of course, and some others too, networking specialists. We probably
have a tendency to overestimate how many such resources we have. Its
Managing Talent
237
hard to think of doing without anyone who is currently making a big
difference. But things happen, and we do manage.
Maybe, said Barton, we ought to ask peoplemanagers at your
levelto designate a certain number of people in their organizations
who are Priority 1 resources, or something like that. People we cant
stand to lose. Might be useful in our management conversations. Think
we ought to work with HR on something like that?
Maybe. Depends on how it would work, how useful it would be.
My half-baked thought, said Barton.
A good one, said Gordon, but there might be a lot more thinking
to do on how to make such a system most useful. Would we have Priority 2 resources? Priority 3 ? Should we do some sort of skills inventory,
so that we know what each person is capable of? Should it be linked to
training? All this sounds good in principle, but it could mislead us into
thinking we have the talent thing worked out when we dont. I mean,
Ivan has had a lot of training, but what sets him apart is not how many
classes hes taken, its what hes inherently capable of.
So, back to your original topic, whats up with Ivan? Is someone
trying to hire him away?
I havent even fi nished telling you how good he is. In addition to
being a terrifi c coder and architect, hes also a great communicator. Not
only can he come up with great designs, he can communicate to others
about them. Including managers. This may not sound like a big deal
when placed side by side with coding and architecture, but it might be
the biggest deal of all. Its defi nitely the least common talent. Especially
the communicating to managers part of it. We managers can be a bit
thick when it comes to technical stuff, and its absolutely invaluable to
have someone who can make an obscure technical point that entails,
say, a cost-risk trade-off, clear to the likes of me or Raj.
Fenton can still go technical with the best of them in his area. But
while Raj and I were pretty good technically in our time, its been a
while. The world of technology has changed vastly since we did anything even roughly equivalent to what our people are now doing.
Barton nodded. Its even worse for me. I never did any of that stuff.
I can imagine. Though you seem to be holding your own, Jim.
The Hero Breaks Through
238
Barton waved a hand dismissively. If so, its because I listened well
when you explained things to me when I was head of Loan Operations.
Y ou certainly did.
So take me back to Ivan.
Ah, yes. So I spent about half an hour with him this morning. Ive
got him assigned full-time on the Alpha3 project, which Im sure you
remember.
I not only remember it, its high on my list of things to keep tabs on.
I was on a call about it with one of our customers this morning. They
are very eager to get the Alpha3 functionality in place. As you know,
some of our competitors have also promised similar functionality. Its
important enough to customers that they are threatening to move their
business if we cant get the project done in a timely fashion. They believe theyre going to lose customers if they cant offer that functionality
once their own competitors have it.
I know, I know, said Gordon. Its the most important project
were working on at the moment. The most important anyone in IVK
is working on. And from what I understand, and from what youve just
been saying, the deadline is not negotiablewe have to hit that deadline or there will be very serious consequences for the company.
Especially, said Barton, given the delicate state of the companys
recent stock performance. Things have been going better, but the jury
is still out. Missing the deadline might just confi rm the beliefs of those
who think we have stumbled after our period of rapid growth. A lot of
people out there, analysts especially, are looking for signs that weve got
our second wind, or, alternatively, that were not going to get a second
wind. If we dont, some say well be bought by one of our competitors
at a discount. It wont be only Alpha3 that determines this. But things
like hitting big project deadlines will signal to the markets whether
weve proven our ability to move back to the front of the pack. It makes
absolute sense that you have Ivan, your best guy, working on it.
Thats just it, said Gordon. Ive assigned him to work on the project full time. But he hasnt been doing it.
Bartons forehead wrinkled. He didnt quite get what Gordon was saying: Y ou mean he keeps getting pulled off into other things? Firefi ghting?
Barton was imagining his business peers making calls to specific developers
Managing Talent
239
inside Gordons and Juvvanis organizations, bullying them into doing
things that werent on the offi cial priority list. As Barton imagined this, his
temper rose. If thats it, he said, I can make some calls right now.
We do get some of those problems, but the guys typically bring
those right to me, and I handle them, said Gordon. Thats not the
problem in this case.
I dont get it, then.
Well . . . Gordon seemed reluctant to say what she was thinking.
What is it, Tyra? Weve worked together for a long time. Whatever
it is, you can tell me.
I feel like a kid telling on my little brother, and that I ought to just
handle this without bothering you.
Y ou said you wanted my advice.
The truth is, Im not sure what to do. The truth is, also, that Im
embarrassed. I think this represents a failure of my own management
of my own group. I should have known about this.
If youre trying to whip up my curiosity, youve certainly done it,
said Barton. He smiled reassuringly, convinced now that he needed to
be involved in this issue that had so disconcerted his trusted manager.
She paused, sighed deeply, then plunged forward. Ivans actually
been working something entirely unrelated. Unrelated to anything at
IVK. His own pet project. As best I can tell, hes been working on it
more than half the time.
What kind of pet project?
We put up with a lot of things from some of our best people, said
Gordon, now turning protective. We have to. Its part of how we retain really good people. Its important that we are progressive in the
way we treat our people. I dont know if you know this, but John Cho
is part of a jazz band. Theyve made records. Sometimes we give him a
few days off to record a new album. He goes to New Y ork. And we let
him come in to work late all the time after hes done late-night gigs in
clubs. If we didnt, hed choose to work elsewhere, and he could. He
could walk out any day and have another job an hour later.
John Cho is in a jazz band? Wow. Id heard that his unconventional
work schedule had to do with membership in a band. But I would have
guessed punk rock, said Barton.
The Hero Breaks Through
240
He plays saxophone, I think, said Gordon.
Weve gotten off the subject of Ivan. Barton repeated his question:
What kind of pet project?
Ivans been involved in a political movement aimed at getting rid
of software patents. He doesnt believe in them. Its sort of a radical
open source group. They believe code should be freely available to others, in an ideal world. And they resent efforts by tech companies, and
especially opportunistic intellectual property salvage fi rms, to collect
patents that might be the basis for an infringement claim. Ivan has a
point, reallya lot of those patents are a problem.
Y es, but what kind of pet project? Barton was hoping this didnt
involve some sort of leakage of IVK proprietary information to someone outside the company. Depending on what it was, that might cost
Gordon and Barton their jobs. Williams had a short fuse these days.
He calls it a random patent application generator, explained Gordon. The idea is that it will generate and automatically submit applications to the US Patent Offi ce that look real and take up time and
resources, but that are ultimately nonsense. By barraging Patent Offi ce
systems with a rapid-fi re assault, they hope to totally confound the patent authorities and bring the whole system to its knees. In a way, its a
version of a denial of service attack, in that it uses up all the resources
of the organization on worthless business. But Ivan and his associates
would also be delighted, I think, if a randomly generated application
resulted in a patent approval. That would have a lot of PR value to
them.
Fascinating, but I still dont see what it has to do with us. Has he
pulled IVK into his battle?
Y ou mean has he leaked some of our proprietary code, something
like that? Oh, no. Its the time. Hes spent more than half his time over
the past couple of months working on this while weve been under serious deadline pressure on the Alpha3 project. I dont think hes been
developing or testing his own private code on our machines, but hes
probably been using some IVK resources. Hes remotely accessing his
machines at home from our site.
I see. So he has involved us in this, in a way, said Barton. He felt
some relief that things had not proved as bad as hed feared. But he
Managing Talent
241
could see why Gordon considered this a problem. What do you think
we should do?
Thats what Im not sure of, said Gordon.
What did you say to him this morning? asked Barton. Y ou said
you spent time with him.
Y es, said Gordon, but I was so startled by it all that I couldnt
really fashion a reasonable response on the spot. When we got onto
the subject, by accidentI dont even remember how it came uphe
was delighted to share it all with me. For half an hour he walked me
through the entire project, explained his enthusiasm for it, why he considers it of tremendous importance to humankindthats exactly how
he put it, by the way, said it was of utmost importance to the future of
humankind that this issue be dealt with. He didnt say it, but an implication, of course, is that its more important than the Alpha3 project
deadline.
Think we should fi re him? Barton asked.
We cant, said Gordon. Not if we want to have any chance of hitting the Alpha3 project deadlines. We simply cant do it without him.
Want to wait until we hit the deadline and then fi re him?
That would seem mercenary of us, dont you think?
It would certainly make him an example.
Might also anger other people. What would John Cho think about
it, for instance?
Maybe theres nothing we can do about it. Maybe hes more valuable to us working on our stuff part time than any replacement would
be full time. Of course we need to make sure he doesnt actually launch
any of these attacks on the patent offi ce from our computers.
Theres no doubt that hes very, very valuable to us, but I also have
a problem with just letting it go. Thats not the deal we have with him.
We employ him full time. We pay him for full-time work. But he hasnt
been giving us full time.
How do you think he views this apparent violation of his employment contract with us?
I think he considers it beyond plausibility that we would not share
his concern about the problems in the patent system. I think he honestly expects us to also rank his pet project higher in priority than the
The Hero Breaks Through
242
Alpha3 project deadline. From what he said this morning, I read
between the lines that he likes working for IVK because he thinks we
are a good cause.
Im guessing that we pay better than his pet project, too, said Barton. Think you could just sit him down and have a heart-to-heart with
him about this? Try to get his priorities a bit more aligned with ours?
Y eah, thats probably what I should do. Certainly I need to be clear
about what he can and cant do with the companys resources. But its
likely to be a diffi cult conversation.
Think I should do it?
No, I think that would make it too much like grade school punishment, getting sent to the principals offi ce.
Barton nodded. Tyra, I dont have much advice on this. We cant
afford to lose the guy, clearly. Others must know hes not putting all his
time into Alpha3 .
Oh, sure. I should have known.
Oh, yeah, and I should have too, said Barton with a reassuring
smile. Gordon nodded her head, still looking upset.
Well fi gure this out, Tyra, said Barton. We probably ought to
bring up this issue in the managers meeting next week; I want to talk
about how we handle these kinds of situations, in case it should happen again. Probably it happens more often than we realize. Also, this
conversation has got me thinking we should have a much broader conversation about managing talent inside the IT organization.
Thanks, Jim. Gordon stood.
Think about whether you need some additional resources to make
up for the time lost to Ivans pet project. We could divert some people
from Rajs group, maybe. Weve got to hit that deadline.
Gordon shook her head. I think its too late to get someone else
in there, but we can think about it. Wed lose time getting a new person
up to speed, and you cant really substitute anyone else for Ivan. Thats
why this is such a big deal. We need all of his attention devoted to making this deadline. She paused. Im really sorry about this, Jim.
Sounds to me, said Barton, like this is more a matter of realizing
and adjusting to the changing nature of management in the twentyfi rst century than anything to feel sorry about.
Managing Talent
243
Thanks for saying so. She turned and opened the door. Barton
knew shed keep feeling responsible. It was part of what made her a
good manager. And they would have to fi gure out how to make the
adjustments necessary to hit that deadline. After Gordon left, Bartons
eyes wandered to the whiteboard, where early in his tenure as CIO hed
written Skill and talent management/ key skills, key contributors. He
remembered the kid at Vinnies Bistro suggesting an assessment of key
skills and contributors as the very fi rst thing Barton should do as a new
CIO. But somehow the issue had slipped through the cracks. Time to
resurface it , thought Barton. Should have done it already .
Thursday, November 8, 12:32 PM . . .
Thats a tough one, said Bernie Ruben between the last two bites of
what had been an enormous BLT. Barton had barely touched his own
turkey sandwich. Hed been explaining the situation that Gordon had
brought to him earlier in the day, and the talking had left him with little
time for eating. Now he took a bite and listened to Ruben, who wiped
his mouth and began to offer his thoughts.
Tyra undoubtedly feels that this is a failure in her supervisory
responsibilities, although I sincerely hope you dont see it that way.
Barton shook his head, chewing.
Its a problem. A big one. We depend on them to tell us what is
really going on, where the problems really are. And so many of the
things we might do to get a better view of what they are doing, an independent view, can potentially backfi re, disrupt the communication
from them that we really depend on. Developers like Ivan dont like it
when you peek over their shoulders too much, especially when theyve
been doing their best to explain everything to you. It feels to them like
you are checking up on what theyre saying. Which is, of course, what
you are doing. And you can imagine what might happen if someone
like Ivan brought the same indignation to his relationship with Tyra
Gordon that he brings to his crusade against software patents.
I dont suppose theres any hope for a technology solution?
Monitoring systems, to tell us what people are up to? Barton asked.
The Hero Breaks Through
244
If you ask me, no. Others might disagree. Y ou can buy software that
installs on everyones device that tells you what applications people are
using all the time. Whether they are accessing sports sites on the web,
or worse. Y ou can get as Big Brother with it as you want. Y ou can use
such systems to infer how much time people are spending on the jobs
youve assigned to them.
Whether theyre coding, say, Barton tried.
Y es, continued Ruben, coding, messaging, surfi ng, or not working
on a device at all.
Y ou could probably get sophisticated in how you used that sort of
software, observed Barton.
Y es, but not nearly as sophisticated as folks like Ivan could get. We
dont really know what it looks like when folks like Ivan work at their
peak. Maybe hes most valuable to us when he sits staring into space
20 percent of the time. Or maybe thats how hes most valuable to us
this week, and next week its a different story.
Imagine a situation like this: We document what everybody does,
the time spent performing each kind of work to the nearest minute.
People like Ivan, operating at a very high level, contribute, lets imagine,
twenty-fi ve hours per week in actual coding. Maybe this gets them unfavorably singled out. At the same time, some other employees, who are
not performing nearly as well as Ivan, are coding forty or fi fty hours a
week, in part because it takes them so much longer to do the same jobs.
But using such a measure makes these folks look like heroes. Obvious
morale problems result.
The ultimate problem, I think, is that what we want to buy from
people is not really their time. We want to buy their smarts, their resourcefulness, their good business judgment, their ideas about new ways
of doing things, something like that. Those things dont result from an
eight-hour day; those things are hard to measure. But what we can readily measure is their time, so we default to that. The disparity between
what we want from people and what we can readily measure makes it
really important that we, as managers, interpret what we see well.
Barton stopped in mid-bite, interrupted by a sudden thought. Y ou
know, he said, thats what still makes me most uncomfortable in this
job. I walk through the IT department, I see people doing all kinds of
Managing Talent
245
things. Working at their desks, standing in the hall with coffee cups,
talking. Sitting together in conference rooms, drawing on whiteboards
and fl ip charts. Problem is, I dont know what any of it means.
Hah! Ruben laughed. As if any of us do. But at least we can know
what we dont know.
There was that phrase again , Barton refl ected.
Do you think, asked Barton, that weve got the right IT organization to maximize the value of our talent? I could imagine other ways
of organizing. Right now we are effectively organized with two application groups facing the business units they support, and two general
services groups. We could go either more toward centralized support
models, by pulling all application developers together, say, or more to
decentralized models, by distributing technical talent in your group or
Fentons into the applications areas.
Its a question, conceded Ruben, that we should revisit periodically. Theres been a movement in the industry toward shared services
models, which consolidate and centralize services as an alternative to
embedding them in specifi c segments of the business. If we did this, we
might put Ivan, the other key people in Tyras area, and the key people
in Rajs area into a central applications group with super capabilities.
They would then work on whatever projects were most important to
the company, not just the ones most important to the particular business unit to which they happen to face off. Alpha3 would have not just
Ivan and whoever else Tyras got working on that one, but also maybe
some of Rajs best talent. Shared service models might also eventually
better facilitate outsourcing, if thats where we are heading. In creating
a development capability in a shared services group, we are also potentially creating a place to plug in specialized external resources. The
processes and procedures we need to create a general shared services
capability are similar to the processes and procedures wed need to deploy vendor capabilities in those areas. This logic probably also applies
to areas like security. Maybe a fi nancial services company cant, in the
long run, retain enough talent to keep IT solid in an area like security.
Maybe ultimately well all have to outsource security, or we wont have
enough talent in that crucial area. Then the question becomes: what
else is that true for?
The Hero Breaks Through
246
I wonder which would be best for development of our talent, Barton
pondered. Is it better to put a group of superstars together, let them push
each other and learn from each other? Or is it better to surround superstars with less-able employees who can learn a lot from the masters?
We know only what we have tried, shrugged Ruben. which is a
result of historical tendencieshow the organization grew in response
to specifi c business needsas much as anything else.
Id like to begin a discussion about this in next weeks managers
meeting, Barton said. Have you put together the agenda for that yet?
Barton relied on Ruben to set the agenda for the weekly meeting with
Bartons direct reports.
I have, said Ruben, but we have room for this. Ill add it.
The two men grew silent as Barton fi nished his sandwich. When the
conversation resumed, Barton changed the subject: So, any big plans
for the weekend? Ruben began telling about a dog show that he and
his wife liked to attend every year. The two of them were amateur dog
breeders, specializing in pugs. As he spoke, Ruben became quite animated. Barton enjoyed hearing about it, but he enjoyed even more
Rubens enthusiasm in talking about it.
After lunch, as Barton walked back to his offi ce, his thoughts turned
to questions of how he could acquire the expertise to know who his
best-in-show employees might be: a surprisingly diffi cult question,
he now realized.
Thursday, November 8, 6:18 PM . . .
Barton capped the marker, laid it down, and reviewed his whiteboard
additions. Beneath his very early bullet point about Skill and Talent
Management, he had listed four new items, refl ecting conversations
with Navarro, Gordon, and Ruben. Looking it over, he was unsure what
it added up to. What would Ivan Korsky or John Cho think if they read
this? Barton imagined Cho warming up for a gig, blasting out an elaborate riff on his sax. Something still seemed incongruous to Barton
about Cho holding a sax rather than a guitar. Maybe I should check out
his band some time.
Managing Talent
247
But not tonight. At the moment, nothing appealed more than his
leather couch and some mindless entertainment. And with that image
vivid in his mind, he was out the door.
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
VENDOR MGMT: Talent needed to monitor contract?
Beware lone genius
Know whos best-in-show/models to maximize value?
Buy SMARTS, not hours (careful how you interpret
what you see)
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1 7/6 8/3 9/7 10/5 11/2 12/7
$75.12 $30.72 31.90 30.88 32.02 38.07 37.94 40.21 38.39
4.77B 1.95B 2.03B 1.96B 2.03B 2.42B 2.41B 2.55B 2.44B
+ + + +
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Harness the power of new
technologies (dont sweep
under the rug)
Communication
Always tell your boss bad news first; tell him as
soon as the possibility is known; dont put it off
until you know it for sure.
But SYH2DP
Effectively communicating IT-related business
issues to business managers requires SYSTEMATIC
EFFORT, just like everything else you try to accomplish
in business; spend sufficient time on it.
Friday, November 30, 10:37 PM . . .
These guys are really good , thought Barton. At least as far as I can tell
with my non-expert ears .
1
After a stop in Vinnies Bistro for dinner, he had headed over to a
local jazz club to catch the featured act, the John Cho Q uartet. Barton
found a back table in a dark corner, then settled himself to listen. He
The Hero Breaks Through
248
wished that Maggie could be there. It felt a bit pathetic, being alone, as
usual, on another Friday night. But the music soared, lifting his spirits.
The quartet included, besides Cho on sax, a drummer, upright bass,
and piano. The solos were dazzlingeach of the musicians was really
talentedbut the ensemble playing just blew him away. Barton studied the collaboration, what seemed to make it work, and formed some
thoughts.
During a break, Cho, who had noticed Barton partway through a set,
stopped by his table to say hello. The two had never had conversations
outside offi cial channelsand their work relationship had been, well,
rather strainedso they were both awkward at fi rst. Barton invited
Cho to sit, if he had time; he thought Cho seemed generally pleased to
have his bosss boss come check out a gig. Barton hoped hed become
at least a little cooler in Chos estimation. Always a good thing , Barton
thought, as cool is not something I have in natural abundance .
Barton tried out on Cho some of what he thought he could see
in how the ensemble collaborated. Y ou each have pretty specialized
roles, he said. Y ou, the saxophone, carry the tune a lot . . .
The melody, yeah, confi rmed Cho, nodding.
The drum and bass players set the rhythm, help you all keep things
together . . .
Y eah, they set the groove, keep it going . . . said Cho.
The piano seems quite versatile, sometimes a melody instrument, sometimes more like the bass, accompanying, keeping the
fl ow going . . .
Y eah, totally. Nice observations, said Cho. We defi nitely have specialized roles, and knowing that we each just have to manage our own
role is part of the way we can work so well together.
Y ou seem to take turns with solos, said Barton.
Thats right, pretty much, said Cho, Thats another way we simplify
interactions to help us work better together. We decide, pretty much in
real time, like with a nod or a hand movement, who is going to solo
next. When were really going good, sometimes we dont literally take
turns, in, like, a mechanistic way, but instead we start to have a sort of
nonverbal conversation, weaving in and out of solo or comping roles.
But having that basic idea of soloing versus comping totally helps.
Managing Talent
249
And of course you are all technically amazing players, said Barton.
Cho nodded: Technique is the dancers freedom. Martha Graham,
great dance choreographer, said that. Technique is the jazz musicians
freedom too. In our conversation, like within our fl ow, we have a lot
of problems to solve in real time: where to go next, keeping it together,
building on each others ideas. And we see lots of cool opportunitiesto
try something new, to get rid of an old musical clich were prone to, or
at least to twist and turn the context so that old clich s sound fresh and
new. Our ability to solve the problems and seize the opportunities in
real time depends on our technical mastery. But technical mastery is not
enough by itself; its, like, a prerequisite to going beyond it, into true artistry. Plus, the best players combine technique with simplifi cationwith
experience, you tend to play less but accomplish more.
How is it, asked Barton, that you were able to play that request in
the last set so well?
Y ou liked that? said Cho. Man, that was a tough one. It was not
something wed practiced together. But we all have, like, a similar philosophy as jazz players. We like to take chances, do something that puts
us out in new territory. Do that together, but in a way where we might
not all take risks all the time. We played it, had a few rough spots; if the
soloist goes out on a limb, the other players tend to become more predictable to support the soloist. Probably not audible to most people.
I heard no rough spots.
That doesnt surprise me, but we totally had someplaces where
we made incompatible choices and had to climb back down from those.
The bass player had a bit of trouble remembering the piece! He fi gured
it out eventually, but he did it while we were playing.
No kidding. Y ou would think something that big would be audible,
even to my ears.
I dont know, Cho shrugged. Sometimes I think thats when
jazz is at its best, you know. When youre solving a new problem that
drives you into a totally new way of playing. Thats when its really
fresh, and thats when it is what it is. Thats jazz at its best, man. The
rough spots are part of it. Y ou relate to a form, but you try to stretch
its boundaries.
Sounds pretty scary.
The Hero Breaks Through
250
Cho shrugged again. Scary. Exciting. Two nights ago, we started
playing one song, and I just spaced. I could not get going. The bass
player went into a solo to buy me some time, because he could tell I
was having trouble, and when he came out of it, somehow I started off
in the wrong key. Now hes a great bass player, but he couldnt close the
gap between what I was doing and what he was doing, and I couldnt
either, so I just totally stopped playing! The keyboards player went
into a different ballad, and we all went with that instead. It was a train
wreck, really, and I think some people in the audience could tell, but it
wasnt totally terrible. Then later, I started playing a ballad in the middle of something else we were doing and the drummer couldnt fi gure
out what I was doing right away. Eventually she locked in, but it took
her a few minutes. Its hard to know how well you are playing when
you are in the middle of it. When I was younger, I would judge myself
more while I was playing. But experience and listening to recordings
has taught me that my ability to judge my performance while I am performing is pretty much worthless. Its better just to be in the moment
and to trust your own abilities.
Sounds like you all know certain tunes.
Thats part of how we collaborate so well. We have a common language and a lot of shared references. We call them standards. Weve all
studied a bunch of the same recordings, and memorizing solos is both a
way to build your own voice and create a pool of ideas we can later tap
into to develop ideaslike Sonny Rollinss sax solo on one of his originals, St. Thomas, or Miles Daviss solo on So What from Kind of Blue .
We know the chord progressions. We know rhythms, grooves, from different recordings. So, with a thirty-second conversation, we can orient
ourselveseven a group thats never played together, if theyre good.
A certain groove from one recording, a chord progression from another,
a Latin version of an old standard, then we improvise around the known
parts of it. We lay down certain parameters, and by quickly establishing
certain absolute guidelines for the bandtempo, key, groovewe have
more mental capacity available to be creative and to focus on the musical contextwhich, by the way, is different every time we play. Its really
like a conversation. The most important element we bring to the table is
our ability to listen to each other and make sure our input is relevant to
Managing Talent
251
the context. Chopsor technique, if you willthats really meaningless
if not used musically. Make any sense? Im getting a little out there . . .
Barton was nodding. I think I get it. Part of it, anyway. Im trying to
think whether it helps me understand anything about how to manage
you brilliant technical guys, in our other lives, at IVK.
A deep question, said Cho, But I think theres something there. Its
not, like, a perfect analogy, but theres no doubt I bring something from
my sax playing to the work I do at IVK.
Just then, the drummer came back out on stage and motioned to
Cho. Gotta go, Cho said. Thanks a ton for coming.
Thanks a ton for playing such fabulous music, said Barton. And
for taking the time to explain things to me. This wont be the last time
I come to hear you play.
Cho smiled, then headed back up to the stage. Barton took a sip of his
drink. He wondered briefl y about the size of this quartet. Does this kind of
collaboration scale? If not, what does that mean for how we should organize
our top talent? Important questions, Barton thought, but now was not
the time to answer them. Now was the time to listen to excellent jazz.
REFLECTION
What should Barton and Gordon do about the Ivan Korsky problem?
How might IT managers best measure and compare the output of diverse
employees? Do you think this measurement should impact the kind of deal
(contract) that IVK makes with talented employees such as Korsky?
What other kinds of challenges are involved when acquiring, training, and
managing IT talent?
What kind of restructuring or tuning does an IT organization require over
time? How should you decide whether to centralize talent in a shared organization or decentralize it into distributed groups?
What might Barton learn from Chos explanation of how a jazz ensemble works?

253
chapter sixteen
Standardization
Tuesday, December 11, 2:18 PM . . .
It was infrastructure standardization policy day at IVK. Barton sat
listening to proposals by Bernie Rubens staff for how the IT department should act against the proliferating complexity of IVKs IT environment, the overabundance of software, hardware, and services in
different versions and brands. Business managers at IVK had grown
accustomed to making their own decisions about what business systems, tools, and services to acquire. When they saw something they liked
and decided they wanted it, they often bought it if they had budget for
it. Sometimes they bought without any input from the IT department,
then turned around and expected IT to install and support whatever
it was. This happened all the time with mobile devices, for instance.
Some departments liked one variety, others liked another. All did as
they pleased. Consequently, the IT staff found itself supporting services
on four different vendor platforms, and frequently getting blamed for
problems that had nothing to do with IVK, problems actually caused
by service providers.
But mobile devices were the least of the IT departments concerns
about infrastructure diversity. Most of these devices were not missioncritical. When they failed, a lot of wailing and gnashing of teeth ensued, but the company continued to operate. The relics of past battles
between different IT department factions were bigger problems.
The Hero Breaks Through
254
IVK had historically been a mostly Microsoft shop, but open source
and more Unix-based platforms had made inroads. In more recent
years, over-the-network services had also entered the mix. Wherever
this had happened, bridging applications had to be developed, which
then had to be maintained and modifi ed whenever the application on
either side of the bridge changed. People forgot to include changes to
bridging application in project plans, which meant extra work not in
the schedule in the best case, malfunctioning systems in the worst case.
Often, these problems were easy fi xes for IT support staff, but the total overhead increased as more of these fi xes became necessary. It had
happened again and again, whenever enthusiasts for various unfamiliar technologies gained critical mass within IT.
Sometimes a vendor drove the adoption of nonstandard software
or equipment. This had been on the verge of happening when Barton
fi red NetiFects. The vendor had a signifi cant investment in one of the
software development paradigms that was a rival to Microsofts. Most
of the know-how NetiFects could bring fi t poorly with the IVK legacy
infrastructure. The IR group, at the time not very deep in IT talent, had
weighted this factor insuffi ciently in the decision to hire the company
in the fi rst place. NetiFects had contributed to the problem by downplaying the extent of its orientation toward this alternative paradigm
until after the vendor had a signed contract in hand. Then Netifects
had promptly begun lobbying for a major course change in infrastructure standards at IVK. It had argued for this change on the relative
merits of the two alternative paradigms, but Netifects true reasons had
much less to do with IVKs best interests than its own.
NetiFects did not succeed in changing infrastructure standards at
IVKBarton had fi red them before they got the chance. But over the
years a number of vendors had successfully executed similar strategies,
though not on the scale NetiFects had attempted. Usually these one-off
technologies came into IVK when a business unit worked for a while
with an external consulting group. The marketing department, for example, had worked with such a consultant for some time and had several systems based on technologies far outside the IVK mainstream to
show for it. These new technologies defi nitely had a better congruence
Standardization
255
with the more intuitive way that marketing worked, than they had
with, say, the more structured way accounting worked.
The problem often arose whenever the business units decided they
just had to have a technology, whether promoted by consultants or not,
that happened to run on or with different platforms or services than
those the IT department could comfortably support. In recent years,
the proliferation of apps for mobile devices had made this problem
immensely worse. Apps were so easy to download onto mobile devices,
and many IVK business areas had become devoted to specifi c apps,
relying on them in their day-to-day work. Good apps multiplied like
rabbits, and no one thought to consult with IT before downloading
one. They would, of course, consult IT when they decided they wanted
an app to interface to something in IVKs legacy systems. But business
managers had little appreciation for the infrastructure management issues inherent in such requests. They cared little about the aspects of
systems that operated below the fl oorboards. They cared, naturally
enough, only for business functionality, not what DBMS or networking software (for example) an application worked with best. Usually, in
such cases, the IT department faithfully purchased any required underlying technology and learned how to support new customer requests.
But costs had mounted, and threatened to skyrocket.
Complexity also. Business units disliked costs associated with nonvalue-adding components of systems, and so did Barton and the rest of
the IT department. But the risks to business operations that arose from
ever-increasing infrastructure complexity worried Barton and his IT
managers even more. The group had discussed some ideas developed
by Charles Perrow concerning normal accidents or system accidents
that resulted from the unanticipated interaction of multiple failures in
complex systems. 1 These became more likely and more diffi cult to deal
with as the complexity and coupling of a system increased. Many IT
solutions were tightly coupled, because people usually appreciated the
benefi ts of integrationfunctional couplingbetween systems. Realtime operations required tight coupling, for example, and IVK had a
standing objective of achieving more real-time responsive operations.
That had been one of the major drivers behind the IR project.
The Hero Breaks Through
256
But if coupling was essential to the benefi cial operation of many IVK
systems, complexity was not. IVK could, if its managers had the will, do
something about the complexity of its systems, especially those belowthe-fl oorboards aspects that business units cared nothing about. All it
took was a willingness to invest in the occasional infrastructure simplifi cation project.
In additionwell, it sounded oxymoronic, but the variety in the
companys infrastructure also worked against the IT departments ability to be fl exible . Company-mandated infrastructure standards sounded
infl exible to business managers, who wanted to maintain their freedom
to acquire nonstandard solutions they thought they needed, but the
complexity that arose from lack of standardization meant ever-greater
diffi culty in making changes to company systems. As complexity increased, IVK systems became more like a large ocean liner, pretty good
at carrying its passengers in one direction, but harder and harder to
turn to new headings. Gradual reductions in business agilityalways
step by incremental step, never dramatic enough to become the subject
of deliberate business decisionscould eventually leave IVK in a vulnerable position, unable to counter a move by a competitor.
The current focus on standardization and reducing infrastructure
complexity, and possibly outsourcing more of it, had arisen from a
reawakened discussion with the business units, and with Carl Williams, about the reasonable distribution of IT expenditures. Recent
calculations suggested that IVK spent nearly two-thirds of its IT
budget on just keeping things running, and the rest on new systems,
mostly the security upgrades that followed the June hacker attack
and the IR project. The forecast called for a slight improvement in
this ratio in the next year or two as the IR project picked up momentum, but things would be much worse after that. Within four
years, on current trends, IVK would spend more than 80 percent of
its IT budget on maintaining existing systems. No one, on the business or IT side, could say what the right ratio might be between
maintaining existing functionality and investing in new functionality, but pretty much everyone agreed that 80-20 was too high. One
way to work that ratio down, in the long run, was to re-architecture
and simplify infrastructure.
Standardization
257
The problem, then, was how to accomplish this. Barton listened
as Rubens staff identifi ed three alternative approaches. The fi rst was
what detractors called the do nothing option, although the actual
name given this proposal was voluntary compliance. It called on the
business units to voluntarily take into account concerns about the infrastructure required to run a system or tool they wanted to acquire.
This approach would have the advantage of requiring business managers to educate themselves about the diffi culties that confronted IVKs
IT staff.
The problem, in the estimation of its critics: the business units would
never comply. Nothing would happen. The policy would be ineffectual.
Business units wanted this approach because it preserved their right to
vary from standards for a good enough reason.
The second proposal, strict enforcement, sat at the other end of
the spectrum. IT would decide standards and have absolute authority
to enforce them, meaning they would veto services or apps, including
those that might get someone in, say, marketing, very excited. This
option also included immediate investments to move off noncompliant platformsto get rid of some things that people in the business
units already used and liked. Proponents of this approach raised good
questions: Did it really make sense for IVK to support four different mobile technologies? Did it really matter so much to the business whether they used the long sleek one or the curved wide one?
Business managers tended to see this option as a big step backward,
however. IT staff, not surprisingly, were the major advocates; they
pointed out that some highly regarded tech companies operated this
way, and that it hadnt kept them from being very successful. Listening
to the opponents of this option, however, youd think that the demise
of the company was imminent if the plan was adopted. They called it
the tail wagging the dog, and IT driving business strategy rather
than vice versa.
A number of people thought this approach was simply impractical in a world where mobile platforms and their apps proliferated so
abundantly and, in many situations, with good business reasons. IT
staffers who supported this approach tried to argue for its fl exibility by
pointing out that IVK could still, under this policy, vary from standards
The Hero Breaks Through
258
for good enough reasons. But the IT group would decide what good
enough meant, and this rapidly became a nonstarter in terms of gaining broad support for this approach.
The third option, gradual migration, was fashioned as a middle
way, and became the fallback choice. It involved classifying known technology platforms into three groups: emerging, declining, and standard.
Emerging technologies would have to be relatively new and be promising candidates to become future standards (thus compatibility with
installed legacy technologies would have to be taken into account).
Declining technologies would be the opposite, neither particularly
promising nor a good fi t with existing infrastructure. And standard
would designate technologies that IVK could best support. Investments
in standard platforms would require no justifi cation beyond the usual
business case. Investments in emerging platforms would be generally
allowed, but their timing (why now?) would need to be explicitly justifi ed. Declining technologies would require CEO approval before being
purchased.
This third option abstracted from the discussion of specifi c systems,
though not so far that business units stopped worrying about threats
to their favorite nonstandard systems. The idea was that this option
would deliver a more standard infrastructure over time. It would provide some fl exibility that wasnt present in option 2, and more impetus
to change than option 1. But some option 3 skeptics considered it a
ridiculous compromise.
One put it this way: Come on guys, this is crazy. If we were a $100
billion company with two hundred thousand employees, that would
be different. But were not. We should bite the bullet, get this done. As
designed, Im not even sure this scheme gets us to standardized infrastructure, and if it does itll take years. Years of additional cost and risk.
Years of more arguing about which platforms should or should not be
categorized as declining. This isnt a solution, its a way of putting off
tough decisions.
Another different, but equally skeptical, voice asked whether IVK
would really succeed in categorizing every app that business unit employees downloaded onto their mobile devices: Not going to happen.
Its a standardization approach for an era before mobile devices.
Standardization
259
Wednesday, December 12, 3:19 PM . . .
Barton leaned back in his chair and scanned the room, as if searching
for some path of retreat. But he could not escape the documents spread
over his desk, no matter how badly he wished to. One day after sitting
through IT infrastructure standardization proposals, the associated
issues had become much more concrete.
Hed returned from a meeting to fi nd several items in his in-basket,
and a few messages in his inbox. It hadnt looked like much, just a fi –
nal batch of things to sign and replies hed try to push through before
heading home for the evening. But as he examined these documents, it
dawned on him that each one told part of a single complicated story.
The fi rst was a non-standard service request (NSSR), generated
by a call to the IT help desk. Help desk reps generated NSSRs when a
caller requested assistance with a technology not on the offi cially supported list. The NSSR triggered a process within the IT group aimed
at deciding whether to provide support, one-time or ongoing, for the
non-standard technology. In practice, however, the process was mostly
about how to provide the support, because most requests were granted.
Use of unapproved technologies within IVK was discouragedin fact,
it was offi cially prohibited. But taking a hard line on this issue was not
realistic. Demanding business unit staff and a proliferating range of
cool and useful new technologies made it hard to say no. Also, IT employees tended to be some of the worst offenders, which made it hard
to get on a high horse about it. And, anyway, the IT organization had
decided it preferred to know when people were using non-standard
technologies rather than having them sneak around installing them in
secret. In the vast majority of cases, then, unoffi cial technologies got
informally supported. This worked as long as there werent too many.
Ordinarily, an NSSR would not cross Bartons desk, but this one had
been routed to him by Raj Juvvani, with a Post-it note stuck to it on
which hed written: Get a load of thiswhat do we do with it? Barton
didnt understand. On fi rst glance, it looked like a request for help with
an iPhone, which should have been much too trivial a request to be
routed to Juvvani or Barton. True, the iPhone had never been offi cially
sanctioned for use within IVK, so it was reasonable that an NSSR had
The Hero Breaks Through
260
been generated. But there were iPhones everywhere in IVK. For some
time, the IT group had been informally supporting them because many
people not only wanted them, but persisted in using them.
Examining the NSSR more carefully, Barton realized that it wasnt
for a single iPhone, but for a lot of iPhones. Reading more, he saw
that it was not just about iPhones, it was also a request for support
for a variety of other mobile devices. And it seemed that the requester
wasnt just any old user, but head of the Sales organization. None of this
helped Barton make more sense of the situation, however.
Until he examined a second set of documents. These recounted what
had, it appeared, become a heated dispute between a midlevel manager
in Sales and a member of the IT procurement staff in Bernie Rubens organization. The sales manager had asked that a recently placed order for
new computers for the entire department be canceled. In place of the computers, the manager was requesting an equal number of mobile devices,
each different according to the preference of its intended user. Sales had, it
seemed, decided to run all aspects of its business on mobile devices. The IT
procurement rep had explained that change on this scale would need higher-level approvals, and that many applications the sales team used every
day might not even run on the different mobile devices. At this point, the
sales manager had helpfully provided the name and number of a consulting fi rm theyd been working with for a couple of months, planning the
transition of all sales support functionality to mobile devices. The consultants had assured the sales department that everything would work just fi ne.
The third document Barton picked up was a few pages from John
Cho, assessing the security of many of the mobile devices commonly
used and informally supported within IVK, including many on the list
from the sales department. Cho raised what he called critical security
concerns about many of the devices.
Finally, Barton turned to a message from Carl Williams. In it, Williams
instructed Barton to explore whether IVK could do without expensive
computers entirely and move instead to mobile devices. Word of the sales
departments idea had gotten back to Williams, who had been visited by
the consultants the sales department had been working with. Now he
was enthusiastically supporting their proposals. The consultants had left
Williams three new mobile devices as demos, and in the last line of the
Standardization
261
message, he asked Barton to send someone down to his offi ce to pick
these up so that the IT department could install IVK software on them.
Barton sighed. Where to begin?
IVKs infrastructure had not been originally designed for a world
full of mobile devices and apps. It was reasonable that people in the
business areas wanted to use them, but assuring their compatibility
with IVK systems was not in any currently budgeted project plan. Barton still didnt consider himself a tech expert, but he was willing to
bet that something the sales department considered essential would be
hard to get running on mobile devices, especially when each member
of the sales department could choose their own favorite.
And then there were Chos security concerns.
And support cost issues.
And added complexity and its associated risks.
And yet, could Barton really defend saying no to the wonderland of
functionality that had arrived with the widespread adoption of smart
mobile devices?
There was already a de facto set of practices at IVK with respect to
all this. Current policy amounted to an accumulation of case-by-case
decisions, each probably reasonable on its own. But Barton had a deep
sense that IVKs thinking about how to manage all of these decisions
was not yet nearly mature enough.
Barton gathered his things and stood. This problem would have to
wait until tomorrow. You could really do only so much in a single day.
REFLECTION
Can the IT trend toward ever-more maintenance be stemmed?
What should be the ideal ratio of maintenance to new applications?
Is there a trade-off between standardization and flexibility? How are the two
related in most companies?
What should Barton do about Sales request to replace computers with mobile devices?

263
chapter seventeen
Innovation
Thursday, December 13, 9:06 AM . . .
Barton pondered an e-mail hed just received from the CEO, asking
him to identify specifi c ways his department could contribute to IVKs
top-line growth. The e-mail had gone out to all departments. The topic was not new, but the focus on it was. Barton had been hoping for
more attention in this area, as he thought there were many ways that
IT might accelerate sales. Hed attempted to bounce the idea around
with his direct reports a couple of times, but he found that they were so
focused on the cost side of the income statementcost and headcount
reductions, effi ciency enhancementsthat they literally had trouble
thinking about ITs potential to contribute on the revenue side of the
income statement. Barton thought theyd come around.
Maggie had recently, quite coincidentally, been talking these issues
up with Barton. She had impressed upon him a number of ways that IT
might increase an organizations capacity for innovation.
You can think of innovation, she said, in terms of two kinds of
activity, neither of which have companies been especially good at, historically. This is an old idea, from a guy named Don Campbell. 1 He was
talking about creativity in individual people, but I think the same idea
applies to an even greater extent in organizations.
Theyd been curled up on the couch at Bartons apartment, watching
a fi lm together. The fi lm had completely shaken their expectations, been
The Hero Breaks Through
264
radically different from any other fi lm either of them had seen before
so much so that it amazed them that it had even gotten produced by such
a big-name studio. This got them talking about how such creativity becomes possible despite the many obstacles that can hinder it. Inevitably,
and despite their efforts to avoid it, they related their refl ections on the
fi lm to creativity and innovation in the context of their work.
Campbell called the two kinds of activity blind variation and selective retention, explained Maggie. Fancy terminology, but a simple concept, inspired by Darwins theory of evolution. Blind variation,
means random changes to past ideas to create new ideas, new variants.
In many organizational settings, the new variants arent exactly random, but the idea is the same. The fi rst stage of activity in innovation
is to come up with something original, something different from what
youve done before.
But having come up with new ideas, youre not done. In the second
stage, selective retention, you have to decide which new variants look
valuable to you. Which ones you should keep and build on, and which
ones you should set aside or abandon. Practically speaking, you cant
chase every idea. You have to choose. Selective retention means making
those kinds of choices.
Barton nodded. And your point is that organizations are usually
bad at both stages. We come up with ideas too much like our old comforting ideas.
Ideas that have worked for you in the past, added Maggie. Its
understandable.
But we tend not to create enough variety. Were stuck in habits
weve learned in the past.
Right. And something similar happens in selective retention. Were
looking at our new ideas and trying to decide which ones are most
valuable, potentially.
But the ones we see value in are the ones most like what weve considered valuable in the past, chimed in Barton, which would make it
hard for us to see a breakthrough, something radically different from
our past experience.
The history of business is full of examples of this, said Maggie.
People who came up with very valuable new things, but failed to
Innovation
265
identify them as very valuable. Xerox PARC in the early 1970s provides
some of the most famous examples. Folks there invented or further
developed a whole bunch of technologies that have had huge impacts.
Technologies associated with staggering market capitalizations today.
Ethernet. Graphical User Interfaces. Many more. But mostly these ideas got commercialized by other companies. Bob Metcalfe, one of the
four guys on the Ethernet patent, left Xerox to form another company
so he could commercialize networking technologies. Apple eventually
ran with many of the user interface ideas that Xerox pioneered on the
Alto computer, so these new ideas arrived commercially in the Mac.
Maggie tucked her feet up under her on the couch and leaned in
with a grin. So heres a quiz: of all the marvelous technologies Xerox
invented or advanced at PARC, which one did it most successfully
commercialize?
Barton thought about it, came up with nothing.
Dont know, he said. Which one?
The laser printer! said Maggie, letting out a laugh. Which is interesting, because if you think about it, among all the technology that
PARC came up with, what is more like a Xerox copier than a laser printer? It ran with the new idea most like the old ideas from the business
Xerox was already in! 2 Clearly good enough for Xerox, but it missed
the wildly big opportunities of the Macintosh, graphical user interfaces, and much that eventually made Apple the most valuable corporation in the world. 3
Okay, Barton said, Were bad at coming up with new ideas that
are suffi ciently different. And were predisposed to see value in ideas
that are comfortingly like ideas weve had in the past. How can IT help
with that?
Let me answer with a demonstration, said Maggie. Is that your
computer over there on the desk? She pointed across the room.
One of them, Barton answered. You want it?
Yes, get it for me, were going to do some innovating.
Barton started to get up from the couch, but Maggie held his arm.
Wait a minute, she said. Let me tell you what I have in mind for
your computer before you volunteer it.
Okay, said Barton, sitting back down.
The Hero Breaks Through
266
I propose that we use your computer to generate some random
variation. Specifi cally, I propose that you throw it, as hard as possible,
against a wall, and see if we invent anything by doing that.
Barton chuckled. Well end up destroying my computer.
Sounds like a bad idea, then, throwing your computer against the
wall, right?
It does sound a little wacky as an approach to innovation.
And yet, said Maggie, it is a pretty natural expression of Campbells idea of blind, or random, variation. What happens to your computer when it hits the wall wont be a planned thing. It will break you
away from the habits of the past, the things you can think of to try that
are too much like what youve done before.
I suppose, but . . .
Accidents, Maggie continued, have a rather distinguished place in
the history of discovery and invention. Penicillin, rubber, photography,
anesthesia, dynamite, Tefl on, cornfl akes, and a surprising number of other new and valuable things have arisen when somebody goofed, or broke
something. The philosopher-physicist Ernst Mach insisted that the most
important discoveries and inventions arise by accident. 4
Because accidents get you out of that old-habits rut and produce outcomes that are
truly newoutcomes that you would not have thought to try to create.
Okay, Barton conceded. But how does IT come into this story?
Getting there, babe, said Maggie. I cut you off a moment ago,
when I was advocating throwing your computer against the wall. I believe I cut you off in the midst of saying but . . . . Tell me more about
that but.
Well, said Barton. I was thinking, of course, that youre much
more likely to destroy my computer and gain nothing from it than you
are to invent anything.
Exactly! crowed Maggie excitedly. Accidents, random occurrences,
variations from things that have happened in the past . . . theyre more
likely to have negative consequences than positive ones. What makes
innovation so hard is that we have to pluck positive benefi t ideas from
a sea of much more common ideas that cause problems. Businesses
spend a lot of time and effort trying to avoid the unexpected. Because
the unexpected can be expensive. Wasteful. Mistakes cost money.
Innovation
267
But by avoiding the unexpectedly bad, said Barton, we also avoid
the unexpectedly good.
Because the former is much more common, and therefore more
salient and worrying.
Barton nodded. So I repeat: Where does IT enter this story?
Maggie smiled. It would be very likely costly if we hurled your
computer against the wall, right?
Yes, said Barton.
And we probablyvery, very likelywould not invent anything by
doing so.
Right.
In fact, wed probably have to throw a hundred or a thousand
computers against the wall before we saw anything positive come of it.
If not more.
Because positive variants occur so much less frequently than negative variants.
Agreed, said Barton.
But what if, Maggie posed, we could throw 100,000 simulated
computers against a simulated wall. How costly would that be? How
damaging?
Ahh, Barton said, nodding. Not very. Once youd purchased the
equipment for simulation, smashing another simulated computer
costs practically nothing. Same with an automobile, or a commercial
jet, I guess.
Thats the key insight, said Maggie. In a wide range of aspects of
any business, IT has the potential to run experiments that would be
too costly to attempt in the real world. Simulation and cheap, rapid
iteration is the fundamental activity of innovation. Try this. Try that.
Try some random thing. See unexpected outcomes. See unexpectedly
valuable outcomes.
So simulation, said Barton. Is that it?
No. Theres a whole range of things. You need to be able to try
things cheaply and rapidly. But you also need to be able to evaluate
outcomes, also cheaply and rapidly. It does you no good to do stage
one well if you cant also do stage two well. Automated testing of rapidly generated outcomes is one way we can use IT to do stage two well.
The Hero Breaks Through
268
Weve gotten really good at this in software testing, for example. Also,
sometimes we need people to be able to look at outcomes, interpret
results. Thats where ITs ability to help us visualize the implications of
outcomes helps. Visualization can help us decide quickly and rapidly
which variants look promising, so that we can keep experimenting. 5
What about crowdsourcing? asked Barton.
Now youre getting the hang of this, Maggie said. Crowdsourcing,
which IT facilitates, helps with both stages. You get a wider variety of
ideas when you consult the crowd. And the crowd also has a wider variety of backgrounds and experiences that might make them able to see
value that insiders cant see. The research on crowdsourcing suggests
that traditional approaches are more reliable in generating ideas that
are pretty valuable, but that the crowd is more likely to generate ideas
that are really, really valuablethat is, breakthroughs. 6
Barton nodded. Yes, IT ought to be all over this stuff.
Thats my big message these days, said Maggie. But the truth is,
most of the exciting applications of IT to enhance innovative capabilities are not happening in IT departments. Theyre happening in R&D,
in marketing, and elsewhere. Somehow CIOslike Jim Bartonneed
to get back into the middle of this.
Yeah, Barton allowed. Yet another thing I need to get on top of
that I dont know the fi rst thing about.
Oh, I dont know, Maggie said. You picked up on this pretty quickly.
Barton returned from his reverie to fi nd himself still in his offi ce.
Eager to get going on what he and Maggie had discussed, he stood and
strolled out toward Jennys desk. Hed ask her to schedule a meeting
with his direct reports and next-level-down managers for the following
week. It was probably optimistic to think he could assemble that group
so quickly, but he wanted it to be soon.
Friday, December 14, 9:08 PM . . .
As usual on a Friday night, Barton was having a drink with the kid at
Vinnies Bistro. One of these days Im going to ask him what his name is ,
Barton thought. The kid was holding forth as only a mega nerd could,
Innovation
269
and there would be no interrupting him. Barton had launched the kid
on this path with a claim that he, Barton, thought he was starting to
know some things. Things he had known he hadnt known at one time.
The kid didnt like that kind of talk. Getting a little cocky, are we? had
been his response.
Then, to Bartons growing amusement, he had launched into some
sort of fable. Barton listened, but understood little of what the kid was
going on about.
Once there was a great leader in a province of China, the kid began.
Was there something in his drink? Barton wondered. The kid continued: The leader was retired and had aged considerably. Hed saved the
city at one point in the past, so he was greatly revered, even though he
had long since given up being a leader. Now he was known as a wise,
kindhearted, and eccentric old dude.
Ah, Old Dude , repeated Barton. Thats an ancient Chinese
honorifi c, right? As in Most Honorable and Revered Old Dude.
The kid ignored this ribbing and plunged ahead: Because of his glorious past, the new leaders of the city proposed a festival in the great
mans honor. As part of the festival, there would be a sculpture contest.
Sculptors would be asked to create likenesses of the great man. Two
prizes would be awarded, one based on a popular vote of the citys inhabitants, the other based on the judgments of a panel of sculpture
experts. Winning entries would be installed in a place of honor in the
center of the city.
Sculptures were submitted from far and wide. Some were huge
full-sized statues, others were short stout busts, still others were small
and detailed relief sculptures. The festival came, the contests were held,
and the two winners were chosen. But when it came time to award the
prizes, the guest of honor could not be found.
A quick search of the city determined that the eccentric old gentleman was not there, that he had likely wandered out through the city
gates into the countryside, for reasons no one could fathom. He was
known to occasionally follow butterfl ies out through the gates, and
most assumed something like that explained his absence. The leaders
of the city organized search parties, but very quickly they realized that
they had a problem: No one outside the city knew what the great man
The Hero Breaks Through
270
looked like. If they could not usefully ask country farmers if they had
seen the man, the search would be diffi cult.
These diffi culties perplexed them all until a small child came forward. The little girl pointed out that, thanks to the sculpture contest,
the city was fi lled with likenesses of the great man. Searchers needed
only to take a likeness with them to show to people in the countryside
and say Have you seen this man? to recover him safely.
Now the two winning sculptures were everyones fi rst thought,
but on second thought these were much too large. Both were heavy
enough to break the back of a horse. Most useful to the search were not
the award winners, then, but smaller pieces, especially a series of relief
sculptures, each the size of a persons hand, which showed the great
man in various poses. Each contained a likeness useful for identifi cation purposes.
The search parties divided up the small sculptures, set out to fi nd
the great man, and returned with him within an hour. The festival
could then be fi nished, the prizes awarded. To celebrate a successful
festival, the revelers partied long into the night.
The kid paused, took a drink. Barton waited. Then waited some
more.
And? said Barton.
Thats it, said the kid. Thats the end of the story.
Barton frowned. Is it supposed to mean something to me? Whats
your point?
The kid looked disappointed. So which sculpture of the great man
was the best?
Barton shrugged. The award-winning one?
Which award-winning one?
I dont know. The popular one.
But that one was of no use at all in fi nding the great man.
You didnt say useful. You said best.
I didnt say what I meant by best. You assumed.
Okay, well if you meant useful, then the small relief sculptures.
No, you said the award winners were best. Why?
Well, they must have been the most realistic. The searchers at fi rst
wanted to use them. Would have if they hadnt been so heavy.
Innovation
271
Ah-ha! the kid said. Most realistic . Now you have fallen into my
trap. Are any of these sculptures realistic? Arent they all just pieces of
rock? Surely none of them come close to really being the great man.
Okay, fi ne, Barton said. So of course none of them are real. Thats
not what I meant by realistic. I guess it depends what you are looking
for in a sculpture. Something to use to fi nd the old guy, or something
you think is artistically pleasing.
Right! said the kid.
Im still not following, said Barton. What does this have to do
with anything?
Ill spell it out, said the kid. All these sculptures are representations of the great man, simplifi cations. By necessity.
Of course.
Well, you said you think you know some things. What you mean
is, youve constructed simplifi ed representations of how those things
work. But dont confuse yourself by thinking your simplifi ed mental
constructions are realistic , or worse yet, true . Theyre no more real than
those statues of the great man. You have to judge them by some criteria
other than realism. Nothing useful is real. If its complicated enough
to be realistic, its too complicated to be useful. Thats why we build
models. Representations. When we say we know things, we just mean
we have mental models of those things that we like. Often we like them
because theyve been useful. But lets not confuse having a useful model
with actual knowing.
What difference does it make?
All the difference in the world, said the kid. A model you like for
one thinga representation that is great by one criterionmight turn
worthless, or even harmful, when the criterion or the task at hand
changes. The award-winning statues were not very useful when the
task changed to fi nding the old guy. If the searchers had stubbornly
persisted in their affection for the award-winning statues, theyd have
found the great man much more slowly and probably injured a few
horses in the process. Managers have a problem like this when they fall
in love with a particular model of how something works. When they
become convinced that a mental model they have of how something
works is the right one. When they decide that they know something.
The Hero Breaks Through
272
None of us really knows much of anything, when you get right down
to it. We like some mental models just because we fi nd them pleasing
in some way. We like others because theyve been useful in the past. But
when we become too wedded to a model, we lose our ability to deal
with new situations.
So what I think I know could be something useful now, but might
not be if conditions change.
Precisely. Its best to get over the feeling that you know things. First
off, you know things at a point in time. Secondly, what you have is
a toolbox full of personal theories. You keep those favorite theories
models, tools, whatever you want to call them, for a variety of reasons.
All Im really saying is, you need to be aware of why youre keeping
them in your kit. And you need to always remind yourself that they
are there not because theyre right, or realistic, or true, or anything like
that, but because theyve been pleasing or helpful in a defi ned set of
circumstances. Sort them, store them, and label them in accordance
with the circumstances in which they are valuable.
You wouldnt use a hammer for a job that needs a wrench. The best
managers, in my opinion, take this sort of toolkit approach to what
they do. Bad ones try to use a hammer, or a wrench, or whatever they
regard as the one true tool, for everything.
Wow, allowed Barton. You learn all this hanging out here at
Vinnies?
Of course not. Some of it I picked up from my online gaming.
I do online gaming with my nephew sometimes, said Barton.
Guess I should do it more often.
You should, said the kid. You defi nitely should. Contrary to popular opinion, it makes you smarter.
Barton grew silent. His remarks had been facetious, but the kids
story did really have him thinking. If he took the idea seriously, he really knew nothing about being a CIO. But then, neither did anyone else.
Maybe that put him on more equal footing with the others. Or maybe
his knowing he didnt know things put him on better footing. Maybe
that had been the point of that phrase all along.
Innovation
273
REFLECTION
How much emphasis should the IVK IT group put on top-line benefits from IT
systems, as opposed to traditional cost savings benefits?
What role should IT leaders such as the CIO play in discussions of the use of IT to
enhance innovative capabilities? Why are IT leaders not as involved in these
discussions as you might think they would be?
What do you think of the kids toolkit approach to management? How could you
apply his ideas?

part five
Master of Two
Worlds

277
chapter eighteen
Managing Risk
Wednesday, February 20, 11:10 AM . . .
Barton was in Carl Williamss offi ce, taking a momentary break from
his meeting with the CEO, astounded at the conversation theyd been
having. Williams had wandered off to refresh his coffee but promised to
come right back. The two men had been talking since 10 am. No oneon-one meeting with the CEO in Bartons recent memory had lasted
this long, and Williams appeared eager to continue. The relationship
between the two had improved since the fi rst of the year, for reasons
Barton didnt completely understand.
True, things looked better for IVK than they had for a while. The
stock price had risen past $50, much better than when Williams had
taken over, though not yet nearly as good as the historical peak. Improved stock performance had earned them all nice holiday bonuses,
and of course the CEOs bonus would have been especially nice. But
Barton doubted that a bonus, however good, could account for Williamss renewed interest in discussing IT. Barton almost wondered if
it might be the result of a New Years resolution, or something like it.
Whatever the reason, Barton loved it. He and the CEO were having a real conversation about topicssecurity and availabilitythat
Barton had expected to be diffi cult. The time had come to decide exactly what to spend on some major upgrades. The IT managers had
decided to put business continuity and high-availability upgrades into
Master of Two Worlds
278
the proposal with the security upgrades, network consolidation, and
other infrastructure simplifi cation initiatives, since all involved costversus-risk trade-offs. Only the CEO could decide how much risk it
was reasonable to bear, but Barton had been unsure hed get the help
from Williams that he needed in order to make the decisions.
At the end of Mondays leadership team meeting, as others stood
up to depart, Barton told Williams that he strongly felt the two of
them should schedule a lengthy session to talk through options for
risk management and reduction. Barton had prepared an elevator
pitch to deliver this message in the shortest amount of time, in the
most accessible possible way, though hed held out little hope that
the strategy would work. But the CEO had surprised Barton by clearing Wednesday morningtwo days later!in response to Bartons
impassioned plea.
Some improvements had been made right after the June DoS attack,
mostly emergency actions to secure against obvious threats. The big
problem with proposals to fi x the remaining security and availability
problems was that they ranged very widely in cost. IVK could pay a
little more for some additional security, availability, and business continuity improvements. Or they could pay a lot more for even more additional protection. Yet however much they spent, IVK could never be
sure of complete protection against all risks. IT could prove that risks
existed, by fi nding them and pointing them out, but it couldnt prove
that none remained. Not seeing any was not at all equivalent to there
not being anyso 100 percent protection was a pipe dream. The question on which Barton needed guidance then: How much protection
should they purchase? They needed a framework to use in thinking
about this. Barton had some ideas, but really everything depended on
what seemed reasonable to the CEO.
Early on in the conversation, things had taken an unusual and, it
now seemed, fortuitous turn. About ten minutes into the meeting,
as Barton explained that things could still go wrong no matter how
abundantly and skillfully they deployed prevention measures, Williams
started talking about poker.
Sure, I get it, he said. Even when youve got a strong hand, things
can go against you.
Managing Risk
279
He proceeded to tell a story about playing In-Between, a poker
variation in which you needed to draw a card in between two that youd
already drawn. Williams was holding a two and an ace (the lowest and
highest cards in this game), so he could lose only by drawing another
two or another ace. Anything else would be in between and hed win.
He held two of the eight instances of two or ace, so only six remained
in the deck. That meant, Williams explained, his probability of drawing a winning card was as high as it could possibly be. In this particular
game, there was no better hand than the one he held.
Reasonably enough, hed bet big, drawing in a couple of others who
also put in a lot of money. Patting himself on the back for spectacular execution, already anticipating the feeling of triumph as he leaned
across the table to rake in the pot with both hands, Williams had drawn
his next card and turned it face up: a two.
A highly improbable outcome, but not impossible. And a loser. Craziest thing was, Williams explained enthusiastically, the same thing
happened again later that night. Again I was holding an ace and a two.
Again I bet big. Again people thought I was bluffi ng. And again I drew
a two. It was an important experience for me. The decision I made, to
bet big holding a two and an ace, was entirely sound. Both times. But
the particular outcome stunk. Happens in business too. Sometimes you
make the sound choice, and still lose. Luck has something to do with
it, always.
And sometimes , Barton thought but did not say, you make a bad decision and get a good outcome , still stewing over the chance Williams had
taken in not disclosing the possible security breach in June. Remarkably, at that moment, Williams expressed exactly the same idea:
The fl ip side is also true. Sometimes you make a questionable decision and things turn out okay. Like they did for us after the hacker
attack last summer. Occasionally you win by counting on luck. Shaky
decision, good outcome. It happens. Sometimes you have to go for it.
What do you mean us? Barton mused. It was you who steamrollered
over my advice and made that shaky decision . Nevertheless, it surprised
Barton that Williams was so thoughtful about what he had done. Barton had considered Williamss decision not to disclose what had happened a purely emotional, spur-of-the-moment thing. Now he realized
Master of Two Worlds
280
that Williams had been thinking about it with quite a bit more nuance
and subtlety. Counting on being lucky, with eyes wide open. A bad decision, even Williams admittedbut the way you had to play it sometimes, he clearly believed.
But not too often, I guess, Barton said, surprising himself with his
candor.
Williams laughed. Exactly right! Do that too often, youll lose your
shirt, in poker or real life. But now and again, on rare occasions . . .
He grinned at Barton widely, making him a confi dant. Barton couldnt
help grinning back.
Then, to Bartons great delight, the poker game analogy grew into
a much larger frame for the conversation about risk that hed wanted
to haveindeed, needed to havewith the CEO. In fact, Williamss
next few observations expanded it into a much bigger frame than any
Barton had in mind.
The fi rst thing you have to do in poker and in business, said the
CEO, now holding forth eagerly, is decide what kind of player you
are. You can minimize risk, minimize losses, by playing a very conservative strategy, betting big only when you have good cards, bluffi ng
occasionally to keep the others off balance. Problem is, you never win
big that way. People start to read you, realize when youre betting they
ought to fold. But you dont take risks, so you rarely lose big either. Its
a pretty good strategy. If I were running one of our big competitors,
thats the way I might play it. But IVK is not an incumbent. We cant
play it that way.
Barton inserted his own analogy, not poker-based but, he thought,
appropriate: Reminds me of the risk escalator analogy. Williams
showed no signs of recognition, but looked interested. Barton continued: IVK and its competitors are like people trying to walk up a down
escalator. You have to keep moving, just to stay in place. Stop and you
move backward. Some competitors are in front of others, but the order can always change. Theres a switch that any of you can adjust that
controls the speed of not just your own escalator, but all the escalators.
If you can get ahead by being a better climber and then speed up the
escalators, you make things very hard on your competitors. Its the risks
a company takes that speed up the stairs for everyone. 1
Managing Risk
281
Williams nodded. I like it. We stumbled a while back and drifted
backward. But not being an incumbent, we still have to take risks, have
to speed up the escalator. Its why we do all the things were attempting
in client management, the things our competitors have been obliged to
follow. Problem is, while taking these risks, we got a little sloppy, got a
bit uncoordinated, stumbled, and slid back. That doesnt change the
fact that the kind of player we are in the poker game is one that has to
take risks, not a leader who can sit back and minimize losses.
Barton could scarcely believe how well these remarks by Williams
set up what they needed to talk about. So, Carl, that is a great context
for the decisions we need to make about security and availability upgrades. As you say, were playing a riskier game. We do more sharing
and transfer of data between our own systems and our partners. We invest in new systemsespecially web-based systems that clients see and
usemore aggressively. Every time we make such an investment to try
to speed up the escalator for our competitors, theres a question about
how bulletproof we ought to make our operations against accidents
and saboteurs. There are all kinds of gradations. Theres also project
risk that arises when unexpected complications make it diffi cult for us
to deliver functionality as planned and expected.
So if we continue with the poker analogy, said Williams, you have
to think about a few factors when you decide whether to bet, whether
to take a chance. What is the risk of the downside? Big or small? And if
you experience the downside, how costly will it be? Will you lose a lot
or a little?
Thats exactly analogous, said Barton. Our highest priorities are
risks that are likely and can generate big costs.
Wed need to see big benefi ts possible before we took on those
risks, said Williams.
Thats right, said Barton. And we might be willing to make additional investments to mitigate some of the risk, with the expectation
that the return will be great.
So thats a reasonably easy case to decide, said Williams.
I agree, said Barton. But its your decision how much to invest in
additional risk mitigation. The more you invest, the less dramatic your
return, even assuming the probabilistic risk is not realized.
Master of Two Worlds
282
Its like deciding to take a risk but also buying insurance. How
much coverage do you want?
Exactly, said Barton. So I have a list of these for you, examples of
big risks were taking in replacing systems, with questions about how
much insurance to buy to offset uncertainty. Not an actual insurance
policy, but technologies we can implement or steps we can take, at a
cost, to reduce the probability or the consequence of an unlucky outcome.
What about other categories of risk? Low probabilities and high
costs, or high probabilities and low costs, or low of both? Its a twoby-two.
Barton stood, moved to a whiteboard and drew a 22 table. 2
Tolerable Intolerable
Downside risk
Cost of
protection
High
Low
Bear the risk Capitalize costs
of risk mitigation
Lowest priority Mitigate ASAP
He explained: Most of the action, as you can see, is on the right.
Weve already handled everything we can see in the lower right, the
intolerable-risk, low-cost-to-mitigate cell. The hard ones in the upper
right. For things in this category, we can decide not to do the things
that generate those risksthat would mean, typically, reconsidering some element of our business strategy, whether something weve
said we want to do is worth the riskor we can decide it makes good
sense to take the risk and invest in mitigating itbuying insurance,
in effect.
Whats a tolerable risk? Williams asked, looking at the left side of
the table.
Good question, said Barton. Generally, its one with not much potential cost, but it would be worth reviewing the ones weve put in that
category, to make sure that what we think is tolerable and what you
think is tolerable are the same thing.
Williams nodded in agreement. But I see what you mean about the
upper right. The dicey area.
Managing Risk
283
Yes. Ive got a list of things I want us to walk through, one by one,
to see if they seem like the insurance you want to buy. But before we do
that, there are two more things I want to point out.
Barton paused, and Williams responded with a nod.
First, said Barton, its important to realize one of the implications
of the left-hand side of this chart, especially the upper left. If we bear
some risks, it means we will have some problems. On the availability
side, it means sometimes things wont work, not because anyone has
done anything wrong, but because weve decided to bear a risk and the
cards came out wrong for us in that particular instance. On the security
side, it means the number of hacker incidents we can expect every year
is greater than zero.
Hmm, said Williams. But if weve categorized things correctly,
those hacker attacks will do little damage.
Thats right. But it doesnt mean they wont be alarming. Same with
the risks we decide to bear from an availability standpoint. The classic
example of a place we might choose to bear some risk is by not investing in making sure our mobile devices receive messaging no matter
what. It would cost a lot to make mobile message delivery very reliable, and Im not sure its worth it. But theres no doubt that people
will howland loudwhen the service breaks down. I want you and
other managers to understand that this will happen sometimes because
we have, all of us, agreed that it does not make sense to invest in making that service bulletproof. An outage of this kind doesnt necessarily
mean IT has gotten something wrong, just that weve decided to live
with some risk in that area.
Sounds right to me, said Williams. I agree that we dont want to
spend too much on bulletproofi ng nonessential services. People can get
what they need another way, or even do without for a while.
Great, said Barton, sitting back down. Itd be great if you could
say something to that effect in a leadership team meeting the fi rst time
we hear a lot of grumbling about a nonessential service outage.
Williams nodded. I get it, he said.
So heres where the second issue arises. We need to decide whether
we want to adopt a general policy concerning levels of security and availability we think are appropriate. Do we want everything to be at least a
Master of Two Worlds
284
certain amount safe? And then we can protect especially valuable things
even more? Do we want to have levels of safety, call them level 1, level 2,
and so on up to level 5, and everything in the same level is equally safe?
Or would it be better to decide the security level required for each data
item and make things safe at the data item level in differing degrees?
Im not sure I appreciate the difference.
Doing it at the data level will allow us to decide how much we want
to protect each service or data item. There will be more overhead in
doing all this deciding, but it will also prevent us from overprotecting
some assets and underprotecting others, as we might do in protecting large groups of assets to the same degree. If we categorize, well
undoubtedly protect some things too much, others too little. But if we
protect at the data and service level, we have to understand that we can
no longer simply give people access to a category and trust them to behave. For data items that are extremely valuable, well track everything
that happens to them. This means a lot of monitoring of employee
activities. Anyone who deals with our most sensitive data assets or our
most critical services well essentially spy on, keeping track of everything they do. Some people may not like that. And therell be some
initial investment we need to make in shifting to this philosophy.
And the alternative is . . .
Classic authentication and authorization. We categorize assets and
services, then anyone with suffi cient access rights can get to them. If
they have the access rights, we dont monitor at the data asset level. Of
course we still have some monitoring in place, intrusion detection, that
sort of thing. But our protection is more categorical.
And more trusting.
Right. So theres a cultural sensitivity here.
We are a fi nancial services fi rm.
We are indeed.
Williams sat forward at the table. Lets go through your list of possible upgrades. By the time Ive reviewed that, Im sure Ill have some
more ideas about these general questions of philosophy.
Very good, said Barton, again marveling at the CEOs continued
engagement in this issue. Barton handed Williams a thin binder and
they dived into discussion of specifi c project proposals.
Managing Risk
285
The remainder of the meeting continued in this highly productive
mode. Williams radiated enthusiasm throughout. At one point he hit
Barton with a real stunner, a remark made in passing without further
elaboration: You know, Barton, you do good work. It wouldnt surprise me a bit if you turned out to be the next CEO of this company.
I wont be here forever, you know. Im a turnaround CEO. When things
are turned, I leave. Someones got to take over.
Barton had no idea how much stock to place in this remark. Maybe
Williams had said similar things to other senior managers. Right after
he said it, he continued the risk conversation, as if hed made a passing
comment on the weather. Hed said, You might be the next CEO, in
the roughly same manner than someone might say Weathers turning
a bit warmer, eh? Barton had no choice but to stick to the philosophy
hed adopted since the June diffi culties: Keep your head down, keep
doing your work in the way you think best. There was no sense in getting carried away by the CEOs casual thoughts. A lot could happen, he
knew that, had seen that. A lot would. All Barton could do was his job,
trying to make the IT department, and IVK, as ready as possible for
whatever might happen.
REFLECTION
How should a company decide which IT risks are worth taking? How do you
decide how much to spend to mitigate the risks youve opted to take?
Why should a CIO pursue senior management participation and oversight when
managing IT risk?
Would Barton make a good next CEO for IVK? In what ways might he differ from
past leadership?

287
chapter nineteen
Looking Forward
Monday, March 24, 11:16 AM . . .
Jim Barton sat motionless in his chair, trying to make sense of the short
conversation hed just had with Robert Goldman, chairman and CEO
of the Earlington Financial Group. Barton could scarcely believe hed
been talking with Goldman himself. Leader of a collection of fi nancial
companies in a variety of businesses, Goldman had a fabulous reputation. He was known particularly for his integrity; some speculated that
he might someday be tapped to head the US Treasury Department. He
was known for being likeable, a great person to work for and with. His
companies were often on Best Places to Work lists. Hed been one of
Bartons personal heroes for a while.
The day had begun without a clue as to the extraordinary events in
store for Barton. At about 9:20 am he had received what seemed to be
a typical call from a headhunter. Barton got them fairly often, but few
of the jobs interested him, and those that did never panned out. This
woman on the other end of the line started with what sounded like the
usual pitch; Barton had been about to cut her off so he could get back
to work when she cut to the chase.
I think youre going to want to hear what Ive got to say, Jim, she
said. This isnt the usual kind of call. My client is prepared to make a
job offer to you today.
That got Bartons attention. The headhunter was cagey about who
the client was, but described the company in enough detail to allow
Master of Two Worlds
288
B arton to narrow it down to three or four fi rms. From the sound of it,
they were somewhat bigger than IVK, in a related industry, and rather
more successfulor at any rate, less recently troubled. As the conversation continued, Barton realized that the headhunter was trying to arrange a conversation between one of her clients executives and Barton
for later that day. Deep down, he was still pretty pessimistic that this was
anything worth spending time on, but he agreed to take an 11 am call.
Great, she said. The call will be with Robert Goldman, of Earlington Financial.
Barton laughed. No way, he said.
Yes, I can assure you its true.
As soon as he was off the call, Barton surfed around a bit on various
company websites, to see if he could discover a connection between
Earlington and IVK. After about twenty minutes he found that Francesco Carraro, the IVK board member whoso many months ago
had taken such an interest in Bartons presentation on the role of IT,
was also on the board of directors of a fi nancial software company.
Another member of that board was none other than Robert Goldman.
Maybe this is for real , Barton mused.
The call at 11:00 had removed all doubts. Goldman himself called,
and he hadnt just called to talk. Less than fi ve minutes into the call,
Goldman offered Barton the COO position at one of his major companies, one with a superb track record. The company was bigger than
IVK. The job would be a step up, a career advancement of real magnitude. And they were offering a surprisingly large amount of money.
Were going to need to hire a CIO as well, said Goldman, Wed like
to get you in place so that you can hire him or her. It is our understanding that you know a thing or two about that job.
Its hard-won knowledge, said Barton, but Im not sure how good it is.
Goldman chuckled. Im sure its very good, and hard-won, he said.
Just think about it. Ill give you a call back in a day or two?
Theyre moving fast , thought Barton.
Whats the next step if I say Im interested? Barton asked.
No next step, Jim. If you say yes, the job is yours.
The last time Barton remembered being speechless, it had been
roughly a year earlier. Come to think of it , Barton thought, exactly a
year. Or, rather, a year and a day.
Looking Forward
289
Jim? said Goldman. You still there?
I did it , Bartons thoughts continued. I lasted a year . Oddly, it was the
fi rst time hed thought of the anniversary.
Jim? repeated Goldman.
Oh, Im sorry, Bob. Yes, of course. I will give it a lot of thought. Had
he just called Robert Goldman Bob?
How about Wednesday, then? By then perhaps youll have more
questions youd like to ask. Barton had been so dumbfounded by the
offer that hed been unable to think of more than two or three questions. Hed felt unprepared, but Goldman hadnt seemed to mind.
Once off the call, Barton tried to decide what to do next. He had an 11:30
meeting with his direct reports in the conference room down the hall, but
it wasnt quite time for that yet. His eyes came to rest on the whiteboard.
KWYDK
(UWGDF)
YWLOY
C vs. Q
IT management is about management
Skill and talent mgmt/key skills, key contributors
VENDOR MGMT: Talent needed to monitor contract?
Beware lone genius
Know whos best-in-show/models to maximize value?
Buy SMARTS, not hours (careful how you interpret
what you see)
40%
A/P
60%
Infrastruct.
mapping?
?
IT costs
chargeback IT services
IT VALUE? +/
Prev. 4/6 5/4 6/1 7/6 8/3 9/7 10/5 11/2 12/7 1/4 2/1 3/7 4/4
$75.12 $30.72 31.90 30.88 32.02 38.07 37.94 40.21 38.39 44.19 49.72 51.08 58.22
4.77B 1.95B 2.03B 1.96B 2.03B 2.42B 2.41B 2.55B 2.44B 2.81B 3.16B 3.24B 3.70B
+ + + + + + + +
Mang. Problems: CAN anticipate
planning techniques & methods
IT spending should be aligned
w/ IVK strategy
Mandatory (i.e., security)
ROI (incremental)
OCI (breakthrough)
Mang. Problems: CANT anticipate
exploring, adapting, course-
correcting techniques & methods
Harness the power of new
technologies (dont sweep
under the rug)
Communication
Always tell your boss bad news first; tell him as
soon as the possibility is known; dont put it off
until you know it for sure.
But SYH2DP
Effectively communicating IT-related business
issues to business managers requires SYSTEMATIC
EFFORT, just like everything else you try to accomplish
in business; spend sufficient time on it.
Explore use of IT for innovation
Idea generation and selection
Visualization
Crowd-sourcing
Etc. . . .
Master of Two Worlds
290
Hed last added thoughts on ITs possible role in innovation,
following his conversation with Maggie a few months ago. YWLOY,
his code for Davies warning that he wouldnt last one year in this job,
leapt out at him. As of today, Barton could say that he had, in fact,
lasted. With great pleasure, he brandished an eraser and wiped that
corner clean.
All-in-all, the whiteboard was a lot more crowded than it had been.
The cryptic notations that covered it were, as hed told Goldman,
earned through tough experience. But Barton still wasnt sure they
amounted to much. Hed set out a year before to create a management
framework he could apply to IT. He felt good about what the whiteboard summarized, but hed need a lot more distance before he could
be sure its contents were really worth something. Maybe this new position would provide him with that distance.
Hed have to take the new job, of course. Things at IVK had improved
a lot in the past few months. He and the IT department had crawled a
long way back from that horrible day at the end of June when hed had
to worry about being fi red for the fi rst time in his career. But this offer
would install him in a position like the one hed originally expected and
wanted in IVK, under Williams. Only it would be with a bigger company.
And not under Williams, but under someone hed always admired. The
hacker attack, if thats what it had been, had not produced additional
consequences. It looked as though Williams had been right to insist that
they disclose nothing. The stock price had recovered a good bit of its
former value. Things were looking up. But thinking about the whole
thing still gave Barton a sick feeling. He would be happy to get beyond
worries of becoming a scapegoat. Carl Williams was already getting accolades from many quarters for his turnaround of IVK. Barton had
come to respect the CEO as well, especially after hearing his explanation
of the philosophy behind the risk hed taken with the possible security
breech in June. And, of course, there was that bombshell remark that
Williams had unleashed in passing that Barton might well be the next
IVK CEO. Hard to know how seriously to take that. Barton couldnt
quite get past the sense that he had seen the real Williams on that fateful
Saturday morning in June. And he wasnt sure he really liked the man.
Looking Forward
291
On the other hand, he would hate to leave his team. They had done
a lot of good work together. There was so much still to be completed.
How would he ever be able to tell them?
Barton was about to call Maggie, to get her reaction, when a glance
at his watch reminded him of his 11:30 meeting. He grabbed a notepad
and hustled down the hall. He couldnt recall the purpose of the meeting, and it hadnt been entered in his calendar. It wasnt in the room
where his team usually met. For some reason, someone had booked the
biggest conference room in the building. Perhaps a project team had
needed the room they usually used for these meetings.
When Barton turned the corner into the room, he was startled
to see that it was packed with people. The room exploded with applause. It looked like, more or less, the entire IT department. There
in front were Ruben, Gordon, Juvvani, and Fenton. A bit further
back, he saw John Cho in his signature black skull T-shirt, smiling
broadly, clapping earnestly. Not far from him were Ellen Ripley and
Gary Geisler. On the conference room table, he saw a huge cake.
The writing on it said Congratulations, Jim, on your one-year anniversary!
The ovation went on and on. Barton had received many accolades and frequent acknowledgments of achievement during his
life, beginning with success in sports in school, continuing with
academic achievement in college, and carrying on into his career.
People had often showed appreciation for Jim Bartons work. But
no acknowledgment, he realized, had ever meant more to him than
this one. These people had undoubtedly been skeptical of him as a
CIO choice; to a person, they had surely experienced deep anxieties
about what kind of boss he would be. But somehow he had earned
their respect.
And it felt great.
Finally, the applause subsided and the room became still. They were
all waiting now, wanting to hear what he would say. He took a deep
breath, intending to comply with their wishes.
But for the third time in one year, one day, and thirty minutes, Jim
Barton was speechless.
Master of Two Worlds
292
Monday, March 24, 7:55 PM . . .
Barton rarely ventured out socially on a weekday, but on this Monday
he decided to go have a drink. Hed wanted to celebrate with Maggie
she was in town, but tied up in a client meeting running late. Theyd
made plans to meet up at Vinnies when she fi nished. Hed gone early to
talk with the kid, if he was there. Barton had gotten the impression that
the kid ate at Vinnies most nights.
Just before 8:00, about halfway through Bartons beer, in wandered
the kid.
Hey, I dont usually see you on a weekday. Dont tell me you got
fi red?
Not exactly, Barton smiled. Im meeting Maggie here. Were going
out for dinner. Hey, Ill introduce you to her.
I feel like I know her already.
Barton laughed.
The kid continued: So, youre looking . . . something. Whats wrong?
Nothings wrong.
Whats happened then? Something has.
What, we have a few drinks together and you think you can
read me?
Youre right, the kid conceded. Sorry for presuming. So what
happened?
You know all those times Ive offered you a job?
Sure. I began to think you might even be serious after a while.
You bet I was. But now, well, Im afraid youve missed your chance.
What do you mean? Come on, quit toying with me.
What I mean is that I might not be with IVK much longer.
Aaaaah . . . the kid said in a low voice.
I got a call today from the chairman of Earlington Financial. They
want me as their new COO.
You mean they want you to come in to talk with some board members and executives.
No. I mean he offered me the job. Dont tell anybody.
The kid whistled softly. That Goldman, he said. I had no idea that
he was so shifty.
Looking Forward
293
You know Goldman?
The kid ordered a root beer and turned to Barton. He frowned and
started to say something, then stopped, as if deciding what he should
say. Then his face changed, and Barton could tell that he had decided,
whatever it was.
Yes, I know Bob pretty well.
You know Bob Goldman? The kid looked a little hurt. Barton added quickly, I meanI didnt mean to be insulting. But youve never
given me any reason to think you might know anyone like Bob Goldman. All your geek jokes, I mean. What, you related to him or something?
No, said the kid. He paused for effect before adding: He and I are
on a couple of boards together.
Youre on a couple of boards with Bob Goldman?
Now, now, you just did it again.
Barton winced. Im sorry.
Yes, continued the kid. He and I have even talked about you a time
or two. That shifty dude, I should have guessed he was up to something.
I had a hard time fi guring out how he knew you. Probably, now that
I think about it, through Carraro. Hes on the IVK board, right? Now
theres a guy who cant putt to save his life. You play golf?
Barton shook his head. Who the heck are you?
We never have discussed that, have we? The kid laughed. Im Jonathan Luce.
The Jonathan Luce? The one who founded Dazzle, the computer
graphics company? The computer graphics company purchased by Microsoft for billions?
Actually, we were fi rst purchased by MediaSpark in a stock deal,
then Microsoft bought MediaSpark.
Why didnt you tell me?
Luce shrugged. You never asked.
All this time Ive been treating you like some kind of kid. Barton
buried his face in his hands.
Hey, said Luce, dont worry. You were essentially correct. I am a
nerd, and Im twenty-nine. I just happen to do some investing, venture
capital, and philanthropic work, and Im on some boards.
Master of Two Worlds
294
Barton could only sigh. It had been a day of surprises. Whos been
toying with whom? Barton said.
Maybe I should have told you, conceded Luce. Listen, he continued, I dont want to complicate your life or anything, but you know
that job youve been offering me?
Huh? Yes. How embarrassing . . . me offering you a job.
Well, Ive been giving very serious thought to returning the favor.
Looks like Goldmans got the jump on mesneaky buggerbut Ive
got another proposition for you to consider.
Barton looked at him suspiciously: What?
Im on the board of directors of a pretty good-sized, international
bank. Its got to be ten times the size of IVK, at least. We need a really
good CIO. What do you think? Want to be that guy?
Barton shook his head, to clear it. Im not a CIO. You know that.
Ive told you pretty much everything Ive done wrong in the past year.
I think you are a CIO, if you want to be. Im not coming up with
this out of the blue. Weve talked about it at board meetings. You had
emerged as our number-one candidate. Im improvising a little here by
springing it on you like this, but Im sure the others wont mind when
they hear what Goldman has been up to. It was only a matter of time
before we would have contacted you.
But I dont know anything about IT. Doesnt anybody ever listen
to me?
Oh, come on. I said you have to know what you dont know, but you
cant cling to not knowing.
I should add that one to my whiteboard.
Huh?
Nothing, said Barton. Im just blown away, thats all.
Ill stop pressing. When does Goldman want an answer?
He wants to talk again Wednesday morning.
Wow, thats soon. Do me a favordont give him a fi rm answer
until I can get back to you with an offer. I guarantee you it will be a
strong package. This is a much bigger company were talking about.
More staff, more resources, more responsibility. And I guarantee you
that being CIO wont take you off the CEO track.
Barton remained silent, thinking.
Looking Forward
295
Well? repeated the kid.
Okay, said Barton, but it would be good if you could get the offer
to me as soon as possible, preferably before the call with Goldman. I
dont want to keep Robert Goldman waiting. Hes always been a hero
to me, ever since I read a case about him in business school. Id like to
stay on good terms with him. Theres no way Ill do anything like jerking him around.
Thats why we all want you, Jim. You make doing the right thing a
habit. And you make it work. Its been quite a day for you, hasnt it?
You could say that.
How long have you been CIO at IVK now? A year at least, right?
A year and a day, actually.
Its been quite a year.
It sure has, said Barton. It surely, most certainly has.
Just then Maggie walked through the door and caught Jims eye
with a wave. She smiled at the kid with recognition. Jonathan! she
exclaimed, crossing to the bar with her hand outstretched. It seems I
run into you everywhere these days. So, do you know Jim?
REFLECTION
Why would Goldman and Luce now be competing to hire Barton based on his
years experience as CIO and previous experience as a business manager?
Which job offer should Barton accept?
How important is CIO leadership to the viability and success of twenty-firstcentury companies?
How should senior managers and the board of directors work together to
effectively manage the assets and capabilities of a firm?

297
Epilogue
We wrote the IVK story to be representative, in essence if not in detail,
of the experiences of many companies as they struggle to manage rapidly emerging IT-based challenges and capabilities. Jim Bartons odyssey represents, albeit in compressed form, the journey of IT managers
as they strive to lead their companies efforts in this area. It is exceedingly important, we believe, that managers, regardless of their degree of
technical training, be more introspective about these kinds of issues,
stories, experiences, and adventures.
ITespecially with its role so greatly enlarged since the arrival of the
internethas changed not only how we work and conduct business,
but also how we (and our customers) play, how we consume, and how
we educate our next generations of managers and citizens. And yet the
IT phenomenon, so evident in the expenditures of every organization,
has not yet achieved management attention equal to other areas, such
as fi nance, marketing, operations, and human resources. In too many
companies, IT remains a black box that business managers rarely try
to see inside. When business managers do engage in IT discussions, often they bring little expertise to bear. Many dont feel apologetic about
their lack of knowledge in this area. But the time is coming when Im
not an IT person will be no more adequate as a managers defense in
the aftermath of a major corporate problem than Jeff Skillings now
notorious Im not an accountantthat CEOs effort to explain his
failure to foresee or prevent Enrons spectacular implosion.
One reason for the startling lack of expertise in IT management: the
absence of systematic frameworks that are useful in actual practice. To
Epilogue
298
some extent, this is the result of the relative youth of the fi eld. IT traces
its roots back only fi fty or so years. Accounting, to take just one example, can trace a similar time line back many centuries. Furthermore, the
technologies that underlie IT management, which continuously evolve
the possibilities and constraints with which managers work, change
very rapidly. The assumption many often make, implicitly at least, is
that the content of IT management is too transient to yield to the treatment that other fi elds have received. This is, we believe, nonsense. IT
management as a subject to be understood, even mastered, contains
fundamental elements independent of the underlying technologies. Indeed, as we have worked on this second edition of the book, we have
noted that, while some acronyms and technology- oriented discussions
have aged since the publication of the fi rst edition in 2009, the managerial discussions remain as relevant as ever (and required little updating).
That said, we do acknowledge that mastering IT management is
hard, that attempts at mastery are hindered by some characteristics
of the fi eld that, if not unique to IT, are particularly strongly present.
Foremost among these is the fact that it remains diffi cult to tease apart
management and technical issues within IT management. Indeed, the
daily tasks of managing in the area of IT consist largely of a series of
problems of understanding entangled technical and managerial issues, separating them conceptually, and then communicating them
to people who should be involved in particular kinds of management
decisions. A big part of the diffi culty is the absence of categories, and
frameworks built up from those categories, that can serve as lenses to
see into the experiences of IT management and that can function as
checklists or guidelines for management action. Where such categories
and frameworks do exist, they are often presented and communicated
in abstract ways that dont seem useful in practice.
This is yet another consequence, we believe, of the intertwined technical and managerial nature of IT management. When you have to work
hard to tease apart the technical and managerial, and proceed to categorize the managerial and build the categories into frameworks, the frameworks you arrive at can seem pretty far removed from the situations
that instigated them. Ironically, although you need to separate technical
from managerial to manage IT effectively, you also need to preserve a
Epilogue
299
strong link between the abstractions and the contexts that motivated
their derivation; otherwise, the frameworks wont mean anything to
most people. This is the problem with most textbook treatments of IT
management: they are mostly composed of abstractions distilled from
practice, but too distant from their practical contexts to seem relevant.
Our dual beliefs in both the importance of frameworks and the need
to retain the practical contexts of IT management that give the frameworks meaning led us to the unusual approach that is the IVK story.
The approach is based on the premise that knowledge cant be told
at least not fully. Partly because of the conceptual distance between IT
practice and the abstract content of IT frameworks, and partly because
of the relative youth of the fi eld, the principles of IT management must
be derived from experience (real or simulated). They must be discovered within their contexts, discerned as important, stretched to reveal
their limitations, analyzed for their inner structure, and theorized into
tools in each managers personal kit, to the point where they can serve
as a guide to practical decision making.
To this end, we have amalgamated our experiences as IT managers,
board members, consultants, teachers and researchers into a realitybased narrative designed to allow the reader to walk in the shoes of a
capable business manager learning to lead the IT function during a oneyear crash course. The year necessarily amounts to something of a trial
by fi re. During this one-year period, Jim Bartonand by extension, the
readeris asked to identify key IT management issues, discover underlying principles, participate in debates, make decisions, and experience
the consequences of decisions. As in real life, we do not get to rerun the
experiment, to see what would have happened if we had made a different choice, or if a different roll of the dice had come up. Thus, we do not
end the chapters of this story by revealing the right answers. There are
no right answers. But there can be, nevertheless, sound processes, wellconsidered decisions, carefully constructed justifi cations for actions,
and improved outcomes on average. There may be no right answers,
but that does not mean that all answers are equally defensible.
Having acknowledged the immature state of the IT management fi eld and the diffi culties of arriving at defi nitive management
formulationsnot that defi nitive formulations are abundant in any
Epilogue
300
fi eld of management, IT or otherwe must also acknowledge that our
approach in the IVK story entails a certain lack of closure. We acknowledge as well that this lack of closure could be an obstacle to discovery
of the frameworks that are the ultimate aim of this exercise in management learning. Which brings us to the purpose of this epilogue: we
intend it to provide a baseline summary of the IT management knowledge that can be learned through the experience of the story. We wont
provide answers here, but we will suggest categoriesspecifi c areas
in which a capable IT manager might develop systematic approaches
based on situations facing IVK and, by extension, other companies.
You might choose to translate Bartons experience into a different set of
categories than those we propose. You look at the issues facing IVK through
your own experiences. If you are an IT manager, you can talk about IVK
and its people and issues, and use that as a more comfortable way of talking about the analogous issues in your own company. Often, it is easier to
have a conversation about another company rather than your own company and colleagues, no matter how transparent the analogy might be. We
hope the tale of IVK Corporation will be a trigger for useful discussions
relevant to your own situation. But theres no doubt that were asking you
to do some work here, to distill the relevance to your situation for yourself.
Seven Categories for Developing IT Management Systems
We list below seven candidate areas for IT management systems, and
show some of the issues that need to be dealt with systematically in each.
In keeping with our overall approach, we do not provide the solutions
at the back of the book that many developing managers long for. Youll
need to come up with those from your own experiences, perhaps while
refl ecting on the IVK story, as they relate to your own company.
1. Communication system (some would say the most important of
all IT management systems):
How the IT leader interacts with boss and peers, including
frequency and style of interaction, degree of collaboration
versus completed work recommendation
Epilogue
301
How to achieve joint accountability for issues that cannot be
decided by IT alone
How to achieve adequate transparency, so that non-technical
managers cannot defensibly claim not to know or understand
something they should jointly be accountable for
How to talk about below the fl oorboards IT issues with
business managers (necessary for cost/risk decisions)
How to participate with other senior managers in visioning,
strategy making, promoting, and understanding of future
(technology-enabled) possibilities
Stakeholder analysis and other systematic means of persuasion
Communication with the board of directors to involve them
in IT issues to an appropriate degree
Communication with a community outside the company
(other CIOs, for example)
2. People management system (arguably, the other most
important IT management system):
Hiring, nurturing, and retaining great talent
Supervision in the presence of profound disparities in
specialized knowledge between managers and their employees
Keeping the lines of communication open with employees you
cant conventionally supervise (because often you cant tell
what they are doing)
Coaching, counseling, and directing the focus of highly
talented but variously motivated employees
Keeping account of talent levels of individuals and their skills
and training; knowing what your people can and cannot do
3. Cost and value of IT accounting systems:
Understanding costs, providing cost transparency, directing
costs, and allocating budgets in a way that involves the right
Epilogue
302
people in decisions and gives them the right incentives for
making the decision best for the company (not their own
department or themselves)
How IT creates value (Competes versus Qualifi ers) and how
value can be attributed to the activities and systems that create
it; where to invest to maximize return from IT
The reasonable distribution of investments over time between
compete and qualify activities, and between infrastructure and
new applications
Which projects to invest in and how to prioritize projects in a
portfolio for highest overall return
4. Project management/implementation system:
How to manage problems you can anticipate
How to manage problems you cant anticipate
Managing project scope (when it should be allowed to expand
and when it should not)
The appropriate shape of projects (iterative prototypes or
step-by-step) in different circumstances
How to budget when allowing for the presence of uncertainty
in project timing and cost
How to budget when allowing for the need to learn during the
course of a project
5. Partner management system:
Achieving accountability and synchronicity of motivation
between a partner and your company
Selecting partners (RFP, selection process)
Contractual arrangements with partners, especially those with
which you have long-term relationships (SLAs)
Epilogue
303
Relative merits of service delivery model alternatives (traditional,
software as a service, etc.); what can be migrated outside the
companys walls, and what should not be; how to fi nd the right
balance between controlling urges and movement to the cloud
Level of expertise that must remain inside your company to
manage partners effectively (do you need rocket scientists or
just capable contract managers?)
6. Infrastructure management system:
How much to invest in maintaining versus new capabilities
How to achieve standardization and complexity reduction,
especially when these do not provide direct and obvious
business benefi ts
Protection of information assets from malicious attackers
(cost/risk trade-offs)
Level of investment in redundancy; availability (cost/risk
trade-offs)
Crisis management
7. Scanning for and analyzing emerging technologies:
Identifi cation of emerging threats and opportunities
Integrating emerging technological factors into strategies and plans
The uses of IT to enhance a companys innovative capabilities
As weve said, you might categorize differently. You might think
weve left things out. Youre probably right, for your company at least.
The IT Manager as a Business Leader
Every day infl uential managers in business make seemingly good
business decisions, acting as if they know something about IT, even
though they dont. The cumulative results undermine the capabilities
Epilogue
304
of entire companies and place remaining IT capabilities at risk of attack
or failure. In recent years, hackers (many no longer amateurs) have had
a surprisingly easy time preying on IT networks, stealing hundreds of
millions of records containing customers personal information, creating a rapidly growing illicit industry in identity theft and other forms
of fraud. IT projects continue to fail spectacularly in large numbers,
and in disconcerting manners, moving from on course to catastrophe
seemingly overnight. Mistakes and accidents shut down transportation, logistics, and factories. These events should set off a loud alarm in
the mind of every CEO, board member, and senior manager.
The threat from undermanaged IT is more diffi cult to head off than
many other business disasters. The IT threat involves complex and
poorly understood technology and its management. IT in most companies has largely been left to the technologists. In most cases, its only
the things that go badly wrongIT network or major transaction system outagesthat race to the top and have commanded the attention
of the CEO and the senior management team. The senior managers
have generally responded in a typical industrial economy manner: Fix
it, and dont let this happen again. Root causes are rarely identifi ed,
debated, or effectively acted on. The next time bomb begins ticking: the
beginnings of an even more severe IT outage form amid the wreckage
and well-intentioned recovery actions from the one before.
Too often, as in IVK, the senior management team talks itself into
believing that the problem will just go away. And, with the scrambling
of a good IT department, the problem might be avoided during a particular CEOs watch. But the problem does not just go away.
At one level, the IVK story seems rather mundane. IT management
issues such as the inner workings of an IT chargeout system, the prioritization of projects, the choice of an IT partner, and turnover of IT
resources appear as the background noisethat is, the unglamorous
block-and-tackle work in a gee-whiz high-tech business. The technology may seem more interesting than the day-to-day challenges of
IT management. Wed agree with this assessment. The heart of IT management effectiveness, although essential to the ongoing success of any
enterprise, is not all that sexy. Nevertheless, it has been conclusively
demonstrated in actual practice that the lack of effective IT management
Epilogue
305
decision making on the mundane issues will lead to spectacular and seriously negative consequences. Sound management that leads to effective IT decision making, on the other hand, will have seriously positive
consequences. We wish you more of the latter than the former. But that
will be largely up to you.
Good luck.

307
N OT E S
PREFACE
1. Robert D. Austin, Richard L. Nolan, and Shannon ODonnell, The Technology
Managers Journey: An Extended Narrative Approach to Educating Technical Leaders,
Academy of Management Learning and Education 8, no. 3 (September 2009).
2. Robert D. Austin, Richard L. Nolan, and Shannon ODonnell, Harder Than I
Thought: Adventures of a Twenty-First Century Leader (Boston: Harvard Business Review
Press, 2013).
CHAPTER ONE
1. This picture is the work of entrepreneur and business consultant Michael Enright.
See the Hamilton Technology Advisors website, http://www.htadvisors.com .
2. See Richard L. Nolan, Dot Vertigo: Doing Business in a Permeable World (New York:
John Wiley & Sons, 2001).
CHAPTER THREE
1. See F. Warren McFarlan and Robert D. Austin, CareGroup, Harvard Business
School Case no. 303-097 (Boston: Harvard Business School Publishing, 2003).
CHAPTER FIVE
1. See Andrew McAfee, Anders Sjoman, and Vincent Dessain, Zara: IT for Fast Fashion, Harvard Business School Case no. 604-081 (Boston: Harvard Business School Publishing, 2004); or Kasra Ferdows, Michael A. Lewis, and Jos A. D Machuca, Rapid Fire
Fulfi llment, Harvard Business Review , November 2004.
2. Nicholas G. Carr, IT Doesnt Matter, Harvard Business Review , May 2003.
3. See, for example, Andrew McAfee and Erik Brynjolfsson, Dog Eat Dog, MIT
Sloan Management Review , published in the Wall Street Journal , http://www.wsj.com
/articles/SB117735476945179344 ; for a more complete listing of Brynjolfsson’s work in
this area, see also, http://ebusiness.mit.edu/erik/ITandBusinessvalue.html .
4. Erik Brynjolfsson, The IT Productivity Gap, Optimize , July 2003.
Notes
308
5. This framework has been used for years within the Technology and Operations
Management area at the Harvard Business School, in discussion and in teaching. Its exact
origins are uncertain.
6. Richard Nolan and F. Warren McFarlan, Information Technology and the Board
of Directors, Harvard Business Review , October 2005. For a description of the strategic
grid, see Lynda M. Applegate, Robert D. Austin, and Deborah Soule, Corporate Information Strategy and Management: Text and Cases , 8th edition (Boston: McGraw-Hill, 2009).
CHAPTER SIX
1. The Information Security Glossary website, http://www.yourwindow.to/
information-security/gl_scopecreep.htm .
2. See http://cmmiinstitute.com .
3. Jim Highsmith, Agile Project Management: Principles and Tools (Arlington, MA:
Cutter Consortium, March 9, 2004), www.cutter.com . Reprinted by permission; see also
Highsmiths book on this subject: Agile Project Management: Creating Innovative Products
(Boston: Addison-Wesley, 2004).
4. Cyril Northcote Parkinson, Parkinsons Law, or The Pursuit of Progress (London:
John Murray, 1958); for discussion of this issue in software development, see T. AbdelHamid and S. Madnick, The Impact of Schedule Estimation on Software Project Behavior, IEEE Software 3, no. 4 (1986): 7075; and R. Austin, The Effects of Time Pressure on
Quality in Software Development: An Agency Model, Information Systems Research 12,
no. 2 (June 2001): 195207.
5. On this kind of estimation, see, Barry W. Boehm, Software Engineering Economics
(Upper Saddle River, NJ: Prentice Hall, 1981); on function points, see A. J. Albrecht, and
J. E. Gaffney Jr, Software Function, Source Lines of Code, and Development Effort
Prediction: A Software Science Validation, IEEE Transactions on Software Engineering 9,
no. 6, (1983): 639648.
6. Ed Yourdon, Death March: The Complete Software Developers Guide to Surviving
Mission Impossible Projects (Upper Saddle River, NJ: Prentice Hall PTR, 1999).
CHAPTER EIGHT
1. Robert D. Austin, Warren Ritchie, and Greggory Garrett, Volkswagen of America:
Managing IT Priorities, Harvard Business School Case no. 606-003 (Boston: Harvard
Business School Publishing, 2006).
CHAPTER NINE
1. For additional reading on board IT governance, see Richard L. Nolan and F. Warren
McFarlan, Information Technology and the Board of Directors, Harvard Business
Review , October 2005, 96106.
CHAPTER ELEVEN
1. For more information on managing risk and the processes a general manager
should spearhead to lessen the likelihood that assets will be compromised, see Robert D.
Austin and Christopher A. R. Darby, The Myth of Secure Computing, Harvard Business
Review , June 2003.
Notes
309
CHAPTER THIRTEEN
1. For more on this discussion, see Robert D. Austin and David M. Upton, Leading
in the Age of Super-Transparency, MIT Sloan Management Review 57, no. 2 (2016).
2. How One Stupid Tweet Blew Up Justine Saccos Life, New York Times Magazine ,
February 15, 2015, http://www.nytimes..html?_r=0 .
3. United Breaks Guitars, https://youtu.be/5YGc4zOqozo .
4. Robert D. Austin and Stephen P. Bradley, The Broadband Explosion, and Jeremy
Allaire and Robert D. Austin, Broadband and Collaboration, in The Broadband Explosion: Leading Thinkers on the Promise of a Truly Interactive World , Robert D. Austin
and Stephen P. Bradley, eds. (Boston: Harvard Business School Press, 2005); see, for
example, J. C. R. Licklider and Robert W. Taylor, The Computer as a Communication
Device, Science and Technology (April 1968): 2131.
5. For the classic theoretical treatment on this topic, see Mark S. Granovetter, The
Strength of Weak Ties, American Journal of Sociology 78, no. 6 (May 1973): 13601380.
6. The example cited here is documented in Philip Dahlstrm and Rune Berendtsen,
Enterprise Collaboration: Pursuing Enterprise 2.0 in Large, Conservative Organizations, masters thesis, Copenhagen Business School, July 2010.
7. Robert D. Austin, Warren Ritchie, Greggory Garrett, Volkswagen of America:
Managing IT Priorities, Harvard Business School Case no. 606-003 (Boston: Harvard
Business School Publishing, 2006). Option-creating investments are discussed in more
detail in chapter 8.
CHAPTER FOURTEEN
1. Richard L. Nolan, Executive Team Leadership in the Global Economic and Competitive
Environment (Routledge Studies in Leadership Research) (Oxford, UK: Routledge, 2014).
CHAPTER FIFTEEN
1. Some of the ideas in this section come from interactions with Carl Strmer, who
conceptualized the JazzCode (see JazzCode with Carl Strmer, http://www.jazzcode.
com ); and from our research interview with the legendary jazz bass player Cameron
Brown, December 12, 2007.
CHAPTER SIXTEEN
1. For an introduction to these ideas, see William Langewiesche, The Lessons of
ValuJet 592, Atlantic Monthly , March 1998; see also Charles Perrow, Normal Accidents:
Living with High-Risk Technologies (Princeton, NJ: Princeton University Press, 1999).
CHAPTER SEVENTEEN
1. D. T. Campbell, Blind variation and selective retention in creative thought as in
other knowledge processes, Psychological Review 67 (1960): 380400.
2. Robert D. Austin, Lee Devin, and Erin Sullivan, Accidents Lead to Innovations. So,
How Do You Create More Accidents? The Wall Street Journal , July 7, 2008, http://www.wsj
.com/articles/SB121441267966303881.
Notes
310
3. For an overview of this era at Xerox PARC, see Michael A. Hiltzik, Dealers of
Lightning: Xerox PARC and the Dawn of the Computer Age (New York: HarperBusiness, 2000).
4. Ernst Mach, On the Part Played by Accident in Invention and Discovery, Monist 6
(1896): 161175.
5. Robert D. Austin, Lee Devin, and Erin E. Sullivan, Accidental Innovation:
Supporting Valuable Unpredictability in Creative Process, Organization Science 23, no. 5
(SeptemberOctober 2012): 15051522.
6. Lars B. Jeppesen and Karim R. Lakhani, Marginality and Problem-Solving
Effectiveness in Broadcast Search, Organization Science 21, no. 5 (2010): 10161033.
CHAPTER EIGHTEEN
1. This analogy is from Bob Charette, a risk management expert at the Cutter
Consortium. For a more detailed description, see Tom Demarco and Timothy Lister,
Waltzing with Bears: Managing Risk on Software Projects (New York: Dorset House, 2003),
12; or access Charettes extensive writings on the subject of risk management on the
Cutter website at www.cutter.com .
2. This matrix is reproduced with permission of the author, Dan Geer, from his presentation at Harvard Business School on July 25, 2007; a similar matrix is discussed in
Daniel E. Geer, The Evolution of Security: What Can Nature Tell Us About How Best to
Manage Our Risks? ACM Queue 5, no. 3 (April 2007): 3035.
311
WAY S O F U S I N G T H I S B O O K
The Adventures of an IT Leader is written for IT managers, potential IT
managers, those working closely with IT managers, those managers who
want to understand how to use their IT department to greater effect, and
those who are simply curious. While the book is useful and (we hope) interesting to an individual reader, weve also designed it to be the focus of
discussion. We suggest reading and discussing the book with a peer or convening a group of readers at a brown-bag lunch or other similar session
to discuss the chapters one by one. Questions for refl ection or discussion
are offered at the end of each chapter. There is no particular problem with
reading ahead, although reading ahead will not reveal right answers. At IVK,
as in life, there are no right answers, but rather a set of decisionsmade at
a certain time, by a certain set of actors, with the information availablethat
results in specifi c consequences from which to profi t or learn or recover.
Jim Bartons story unfolds in nineteen chapters. Experienced cumulatively, the story gains dramatic momentum, and later chapters provide opportunities to revisit key issues in more depth as readers gain
deeper understanding and familiarity with the characters, the company,
and IVKs management situation. However, chapters can also be read
independently or in smaller batches as suits the needs of particular
readers. Here are some options:
Option A: Chapters 119 can be read and discussed in nineteen
sessions, or fewer if certain chapters are paired together.
Suggested pairings:
Chapter 2: CIO Challenges, and chapter 3: CIO Leadership
Ways of Using This Book
312
Chapter 4: The Cost of IT, and chapter 5: The Value of IT
Chapter 11: Damage, and chapter 12: Communication
Chapter 14: Vendor Partnering, and chapter 15: Managing
Talent; or chapter 15: Managing Talent, and chapter 17:
Innovation
Chapter 18:Managing Risk, and chapter 19: Looking Forward
If all of these pairings are used, the nineteen chapters can be discussed in fourteen sessions.
Option B: A sixteen-chapter series could be discussed, in which case
we recommend skipping chapters 14, 16, and 17. Other chapters
could be omitted, depending on your particular interests. Again,
using the pairings suggested above could result in twelve sessions
with this option.
Option C : A fourteen-chapter series could be discussed, in which
case we recommend skipping chapters 1317 or 1418. Pairing
would bring this option to a less densely arranged twelve
sessions.
Option D: Specifi c issues could be explored in shorter sequences.
For example:
An introduction to the CIO function could be achieved using
chapters 13, adding chapters 45 to explore the cost and
value of IT.
The issue of security, risk management, and crisis management could be discussed using chapters 1012 and chapter 18.
Topics such as project management (chapters 68), priority
management (chapter 8), vendor partnering (chapters 7 and
14), IT and the board of directors (chapter 9), emerging
technology (chapter 13), and managing talent (chapter 15)
could be discussed independently.
Ways of Using This Book
313
To help with whatever reading program you choose, weve provided
a list of acronyms and terms (see Glossary of Acronyms and Terms).
This material has been used successfully in classrooms at the Harvard
Business School Delivering Information Services Executive Program,
the University of Washington Foster School of Business (executive and
undergraduate level), and the Copenhagen Business School (graduate
level). It has been translated into Japanese and Russian editions for
wider use. If you are interested in using this book in a classroom setting, teaching notes and guides are available. Please contact Harvard
Business Review Press for more information.

315
G LO S S A R Y O F A C R O N Y M S A N D T E R M S
A/P Applications portfolio
APM Agile project management; also applications
portfolio management
APP Aggregate project planning
CEO Chief executive offi cer
CFO Chief fi nancial offi cer
CIO Chief information offi cer
CPM Critical path method
COO Chief operating offi cer
CQ Competes [ versus] Q ualifi ers
DBMS Database management system
DoS Denial of service
DP era Data processing era
ERP Enterprise resource planning
IR or IRP Infrastructure replacement project (as used in this
book)
IT Information technology
KWYDK Know what you dont know (as used in this book)
NSSR Non-standard service request
Glossary
316
OCI Option creating investment (as used in this book)
PC Personal computer
PERT Project Evaluation and Review Technique
RFP Request for proposal
ROI Return on investment
Sabre Semi-automated business research environment
SLA Service level agreement
SYH2DP Sometimes you have to duck a punch (as used in
this book)
Sysadmin System administrator
TPM Traditional project management
Unix A multi-user, multitasking operating system
UWGDF Understand what got Davies fi red (as used in this
book)
YWLOY Y ou wont last one year (as used in this book)
317
accountability, 130131, 209, 301
priority setting and, 130131
adaptation, 104
aggregate project planning, 135
Agile Project Management: Principles
and Tools (Highsmith), 97, 98,
104106
alignment, 134, 135136
allies, 201
applications portfolio, 6566, 70
managing, 82, 135
strategic value of, 7778
architecture, 200202
vendors and, 224226
Architecture Leadership and
Stakeholders (Nolan and Kolb),
200202
assessment matrices, 221223, 233
Austin, Robert D., 122
authentication, 284
authorization, 284
back-offi ce systems, 87
blind variation, 265267
blockers, 202
boards of directors, 141152
communication with, 193194
Boeing, 230231
Bradley, Stephen P., 215216
The Broadband Explosion (Austin and
Bradley), 215216
Brynjolfsson, Erik, 73
budgets, 30, 5862, 6869
alignment with strategy, 134, 135136
control of, 128132, 136137, 138
business knowledge, 1314
business leaders, 35, 3739, 303305
business units
budget control by, 128132,
136137, 138
infrastructure complexity and,
255256
IT spending by, 5860
mapping costs to, 6364
overhead chargebacks by, 6062
Campbell, Don, 263266
capability gap, 1415
career planning, 285, 287295
Carr, Nicholas, 7273
CEOs
CIO relationships with, 148149
communicating with, 190191, 195,
197199, 203204
crisis management and, 160162, 166
in damage control, 171172
Doctrine of Completed Staff Work
and, 198199, 203204
in risk management, 275285
CIOs
assessing previous, 8182
boards of directors and, 141142
as business leaders, 35, 3739,
303305
I N D E X
Index
318
CIOs (continued)
business vs. technical knowledge
and, 119
career planning for, 285, 287295
CEO relationships with, 148149
challenges facing, 2539
consultant report on, 8588
cost management and, 5770
crisis management, 51, 107122,
155169
direct reports and, 2930
job insecurity of, 3032
knowing key players and, 4449
knowing what you dont know,
2628, 50, 53
as leaders, 4154
loss of confi dence in, 187189,
197, 208
networking with other, 3235
prioritization and, 123140
project management, 89106
talent management and, 235251
time to effectiveness of, 88
Cisco Systems, 121122
Clark, Kim B., 139140
closing projects, 104
cloud technology, 224225
collaboration, 249251
communication, 187204
about security breaches, 160161,
166, 175179, 183184
about technology, 207208
with boards of directors, 141152,
193194
business leadership and, 3839
with CEOs, 160162, 171173, 175,
197198
Doctrine of Completed Staff Work on,
198199, 203204
emerging technologies in, 207218
frequency of, 190191, 195
policies on, 209216
social media, 209216
with stakeholders, 194195, 200202
systems for, 300301
Compete investments, 7778, 107108
competitive advantage of IT, 7374, 77
competitive differentiation, 73
complexity, 5253, 255256
conference room pilot tests, 94
consultants
on IT leadership, 81, 8488
systems, 109122
costs, 17, 5770
budgets and expenditures, 30, 128132
business leadership vs. cutting, 37
distribution of IT, 255258
external providers and, 5859
of infrastructure, 6467, 107122
investment ups and downs and, 1617
management systems for, 301302
mapping, 6364
of non-value-adding components,
255256
presenting the case for, 127132
priority setting and, 123140
qualifi er vs. compete, 77
coupling of systems, 255256
crisis management, 155169
CEOs and, 160162, 166
damage control in, 171185
disclosure in, 160161, 166, 175179,
183184
legal aspects of, 159, 166167, 179, 180
loss of confi dence in, 187189
recovery procedures, 115116, 152,
156157, 176177, 304
runaway projects, 107122
transparency in, 51, 160161
crowdsourcing, 268
customer requirements, defining, 8995
customer service systems, 47
damage control, 171185
data analysis, 66, 67
database groups, 4647
data processing era of IT, 84
death march projects, 101102
decision making, 279280, 304305.
See also priority setting; risk
management
development lifecycles, 105
disclosure, 160161, 166, 175179,
183184, 279280. See also risk
management
Index
319
Doctrine of Completed Staff Work,
198199, 203204
dot-com bubble and crash, 16
emerging technologies, 207218,
224225, 303
employees
capability gap and, 1415
direct reports, 2930
Doctrine of Completed Staff Work
and, 198199, 203204
generational differences in, 218,
238242
knowing key players, 4449
knowing who is good, 28
managing, 235251, 301
monitoring, 241244, 284
specialization among, 4549
enterprise resource planning (ERP)
software, 76
expectations
from investment, 1617
expertise
external, 4244
talent management and, 235251
vendors and in-house, 228231
exploration factor, 106
facilities, 48
failing forward, 9394
fi nancial crisis of 2008, 16
fi nancial statements, 2124
fl exibility, 256
focus, in priority setting, 132133
governance, 143, 145
gradual migration, 258
growth, IT as source of, 17, 263274
Highsmith, Jim, 97, 98, 104106
implementation systems, 302
In-Between, 279, 281
information technology
budget control and, 128132
business unit relationships with, 5859
competitive advantage from, 7374
complexity in, 5253
cost of, 5770
difference of, 4449
emerging technology, 207218
governance of, 143, 145
as growth source, 17, 263273
impact of, 297
investment in, 1617
leadership consulting report, 81, 8488
priority setting in, 123140
relationship with business units, 5862
setting direction for, 4244
specialization in, 4549
strategic partnerships with, 143144
value of, 7188
vendor partnerships in, 219234
infrastructure, 47, 48
communicating about, 143
costs of, 6467, 255258
gradual migration of, 258
legacy technologies in, 6465
management of, 82
management systems, 303
modernization of, 60
replacement project, 107122,
163, 219234
stakeholder analysis and, 200202
standardization of, 253262
strict compliance with, 257258
unapproved technologies with,
259260
vendor partnerships for, 219234
voluntary compliance with, 257
See also security
innovation, 263273
blind variation and selective retention
in, 265267
crowdsourcing, 268
models vs. knowing and, 269272
simulations/prototypes and, 267268
investment
alignment with strategy, 134, 135136
boards and, 143
Compete vs. Qualifi er, 77, 107108
Index
320
investment (continued)
ups and downs of IT, 1617
value creation from, 7188
IT Doesnt Matter (Carr), 7273
iteration, 102103, 104
IT management
agile, 9799, 102103, 104106
assessing previous, 8182
boards of directors and, 141152
as business leader, 35, 3739,
303305
business vs. technical knowledge in,
1314
capability gap in, 1415
changing nature of, 242243
communication in, 187204
contexts of, 298299
cost management and, 5770
of crises, 51
death march, 101102
frameworks for, 297298
importance of details in, 4546
innovation and, 263273
knowing key players in, 4449
knowing what you dont know, 2629,
50, 53, 217
lack of expertise in, 297298
levels of, 8182, 8687
management content in, 18
networking with other managers and,
3235
priority setting in, 123140
of projects, 89106
reactive vs. proactive, 210
of risk, 4546, 123140, 145146,
277285
systems for, 300303
of talent, 235251
technical knowledge in, 4449,
5153
technology changes and, 1718
ups and downs in, 1518
knowing what you dont know
(KWYDK), 2629, 50, 53, 217
knowledge, models and, 269272
Kolb, Deborah M., 200202
leadership, 4154
business, 35, 3739
consulting report on, 81, 8488
levels of, 8182, 8687
team meetings, 57
legacy systems, 6465, 85
luck, 279280
market share, 20, 37
market value, 7980
McFarlan, F. Warren, 7778
McFarlans Strategic Grid, 7778
media management, 182183
Meet the New CIO (Sadagopan),
3739
metrics
for employee management,
244246, 251
risk management, 213215
value measurement, 7172, 7579
micro era of IT, 84
mobile devices, 59, 253254, 258,
259261
models, knowing vs., 269272
monitoring, 104, 241244, 284
Moores Law, 85
network era of IT, 8485
networking, 3235
network members, 201
Nolan, Richard, 7778, 200202
non-standard service requests, 259260
one-neck-in-the-noose problem,
130131, 209
open-source platforms, 113, 254
organization charts, 19, 41, 54
outages, 59
overhead chargebacks, 6062
owner control processes, 231
Parkinson, Cyril Northcote, 100
Parkinsons Law, 100
partner coordination processes, 231
Index
321
partnerships, 219234
choosing partners for, 221223
contract structures, 223224
performance evaluation, 8182
Perrow, Charles, 255
planning
aggregate project, 135
CIO career, 285, 287295
project management and, 8995,
9596
priority setting, 123140, 208
alignment in, 134, 135136
continuity and focus in, 132133
talent management and, 238244
transparency in, 132
at Volkswagen, 131135
process improvement, 46, 73
product vision boxes, 106
project management, 1718, 89106
agile, 9799, 102106
customer requirement defi nition in,
8995
death march projects and, 101102
failure rates and, 304
needs analysis in, 9192
planning and, 9093, 135
prototypes in, 9394
runaway projects and, 107122
scope creep and, 90
systems for, 302303
time estimation in, 98100
the unexpected and, 9192, 9697
prototyping, 9394, 102103, 267268
Qualifi er investments, 77, 107108
recovery procedures, 115116, 152,
156157, 176177, 304
research and development prioritization,
139140
resource management, 82, 241242. See
also costs
return on investment, 134135
Revolutionizing Product Development
(Wheelwright and Clark), 139140
risk escalator analogy, 280281
risk management, 4546, 277285
boards and, 145146
emerging technology and, 211215
informal management and, 142
priority setting and, 123140
Sadagopan, S., 3739
schedules, estimating, 98100
scope creep, 9093
security, 4243, 4546
crisis management and, 155169
damage control and, 171185
disclosure about breaches of, 160161,
166, 175179, 183184, 279280
legal aspects of, 159, 166167, 179, 180
loss of confi dence in, 187189,
197, 208
outsourcing, 245246
priority setting and, 123130
risk management and, 281285
standardization and, 260261
vendor partnerships and, 224225
See also risk management
selective retention, 265267
service delivery models, 224226
service-level agreements, 223224
service-oriented architecture, 66
simulations, 267268
slowers, 202
social media, 209216
software as a service model, 224225
speculation, 104
stakeholder analysis, 194195, 200202
standardization, 253262
stock price, 7980
strategic dependence, 7778
strategic impact, 7778
strategic partnerships, 143144
strategy management, 82, 257258
priority setting and, 134, 135136
risk management and, 280281
strict enforcement, 257258
supervision
defi nition of, 4344
knowing key players and, 4449
sustainability, 108
systems, IT management, 300303
Index
322
talent management, 235251, 301
teams
integration meetings for, 106
technical knowledge, 1314, 15
technology
emerging, 207218, 224225, 303
identifying/evaluating emerging,
211212
infrastructure replacement, 107122
internal expertise on, 4449, 5153
legacy, 6465
monitoring systems, 243244
pace of change in, 4549
personal vs. business, 213215
standardization of, 253262
time estimates, 98100
transaction volume, 87
transparency
about security breaches, 160161, 166,
175179, 183184
in crisis management, 51, 160161
emerging technologies and, 208218
in priority setting, 132
trust, 284
unexpected, managing the, 9192, 9697
Unix, 113, 254
value creation, 7188
business vs. technical knowledge in,
1314
demonstrating, 107109
management systems for, 301302
market value and, 7980
measuring, 7579
priority setting and, 134135
sustainable, 108
talent management and, 245246
vendors, 47, 5859
assessing, 221223, 233
infrastructure replacement and,
113120
in-house expertise vs., 228229,
230231
vs. in-house IT, 113115
partnerships with, 219234
service delivery models, 224226
talent management and, 245246
vision, in project management,
104, 106
Volkswagen of America, 131135
voluntary compliance, 257
Wheelwright, Stephen C., 139140
Xerox PARC, 265
Yourdon, Ed, 101
Zara, 7273, 75
323
AC K N O W L E D G M E N T S
We owe thanks to a great many people who helped us conceive and
execute this project. Deans Jay Light and Nitin Nohria and the Division of Research at Harvard Business School (HBS); presidents Finn
Junge-Jensen, Johan Roos, and Per Holten-Andersen of Copenhagen
Business School (CBS); Dean Jim Jiambalvo and Associate Dean
Tom Lee of the Foster School of Business at the University of Washington (UW); and the Philip M. Condit endowed chair at UW all provided fi nancial support for this project, and we are certainly grateful
for that.
A number of people provided valuable written feedback on earlier
drafts. Ryan Nelson and his colleagues Peter Gray, Glenn Browne, and
Stefano Grazioli on the IT faculty at the McIntire School of Commerce
at the University of Virginia, and Janis Gogan, who coordinates the
course on strategic information management at Bentley College, went
far beyond the call of any duty, conducting careful reviews and providing very detailed comments that resulted in rather substantive changes. Thoughts provided by F. Warren McFarlan, our colleague at HBS;
Bruce Rogow, who runs the IT Odyssey and Private Executive Counsel;
Dan Hill, former CIO of Exelon (now retired); Jonathan Wareham and
Xavier Busquets, both of ESADE in Barcelona (Jonathan is now the
dean of the faculty and research there); Lee Devin, our frequent coauthor at Swarthmore College; and Cynthia Beath, professor emeritus at
the University of Texas at Austin, were also very helpful. Carl Strmer,
a man of many talents and interestsentrepreneur, consultant, jazz
Acknowledgments
324
musician, and author of the JazzCodehelped us immeasurably with
the jazz scene in chapter 15; Alan Murray, SVP at Apperian and a computer security expert, provided valuable help with chapters 10 and 11;
and Francisco de Asis Martinez-Jerez, of the University of Notre Dame,
helped us with the fi nancial statements for IVK. Jason Franklin, while
working as a dramaturg at Peoples Light and Theatre, conducted extensive research on Joseph Campbells monomyth, or heros journey,
that informed the creative development of this story. We are grateful
as well to several anonymous reviewers whose written comments we
encountered along the way.
Many more people provided us with guidance in a variety of settings. Dick Nolans students at the University of Washington in the fall
of 2007 read the earliest version of the manuscript and responded with
great enthusiasm and many helpful comments. Rob Austins students
at Copenhagen Business School in the spring of 2008 were equally
enthusiastic and also prompted many adjustments, as did participants
at the Seattle Innovation Symposium in June of 2008 (Mike Eisenberg,
Bob Mason, and Gianmario Motta deserve particular recognition), executives at a major corporation who attended an executive education
program at UW in April of 2008, and the 250 or so senior IT managers
who attended Delivering Information Services, an executive education program at HBS from 2008 through 2011. In the years following,
other students have also provided valuable feedback, especially at CBS.
Numerous others deserve mention. Fellow pedagogues who offered
suggestions and thoughts about teaching IT management: Eric
Clemons, Wharton; Mark Cotteleer, Marquette; David Croson, Southern methodist University; Eph McLean, University of Georgia; and Ed
Pritchard, Portland State. Dan Geer, known as the dean of computer
security deep thinkers, allowed us to reproduce some of his materials
from a presentation, and Sean Nolan, veteran Microsoft executive and
Distinguished Engineer and now Chief Technology Offi cer at Adaptive
Biotechnologies, provided perspective on data center attacks. Michael
Enright, an entrepreneur and chief technology offi cer at WorldWinner,
allowed us to use one of his terrifi c diagrams.
Acknowledgments
325
Still others provided support of many kinds while we were working
on this: Gary Pisano, Technology and Operations Management area
head at HBS; Eva Zeuthen Bentsen, Pierre Guillet de Monthoux,
and Lotte Jensen, heads of the department of Management, Politics,
and Philosophy at CBS; Jan Damsgaard, head of the department of IT
Management at CBS; Daniel Hjorth, research director and colleague
at CBS; Ole Fogh Kirkeby and Mette Mnsted, both colleagues at
CBS; and Henrik Hermansen, colleague and master problem solver at
CBS. Subodha Kumar, now professor of information and operations management at Texas A&M Universitys Mays Business
School, assisted in teaching early versions of the manuscript. Niels
Bjrn- Andersen and Jacob Nrberg provided invaluable advice and
assistance that helped us offer the course at CBS. We are also grateful
for the support of Pam McCoy, Ed Kromer, L. A. Smith, and Jocelyn
Milici from the Marketing and Communications Department at the
Foster School of Business.
Several people are notable because of their multifaceted and unfl agging support: Karen Coburn, CEO of the Cutter Consortium, allowed
us to reproduce her copyrighted material and has been supportive in
more ways than we can count. Abbie Lundberg, longtime editor-inchief of CIO magazine, and Brian Watson, longtime editor of CIO
Insight , have been enthusiastic supporters and have provided valuable
important thoughts at key moments.
At HBS, the talented Evgenia Eliseeva deserves mention. At Harvard
Business Review Press, we are thankful for the exceptional work of
editors Kathleen Carr and Erica Truxler and a whole slate of people:
Heide Abelli, Liz Baldwin, Marcy Barnes-Henrie, Todd Berman,
Erin Brown, Sarah Green Carmichael, Mike DeRocco, Julie Devoll,
Stephani Finks, Jeff Kehoe, Dave Lievens, Audra Longert, Carolyn
Monaco, Jacque Murphy, Keith Pfeffer, Christine Turnier-Vallecillo,
Leslie Zheutlin, and our excellent copyeditor, Monica Jainschigg.
Special thanks to artist Asaf Hanuka, composer Christopher Colucci,
and HBS Creative Director Tom Ryder for adding their skills to the
project.
Acknowledgments
326
Of course we must also thank our families, who endure the consequences of our scurrying to make deadlines and our long video calls
across many time zones on sometimes awkward schedules, but who
nevertheless provide their unqualifi ed support.
Robert D. Austin
Copenhagen, Denmark
Richard L. Nolan
Boston, Massachusetts
Shannon ODonnell
Copenhagen, Denmark
327
A B O U T T H E AU T H O R S
Robert D. Austin is a professor of innovation and information
technology at Ivey Business School. He has also been a professor at
Harvard Business School, where he chaired the schools executive program for chief information offi cers, and Copenhagen Business School.
Before becoming a professor, he was an IT manager at two major international corporations. He has written more than one hundred published papers, articles, cases, and notes, as well as several books, some of
which have received international awards. He is active on editorial and
advisory boards for numerous academic organizations and companies.
Richard L. Nolan is the William Barclay Harding emeritus professor at Harvard Business School and emeritus professor at the Foster
School of Business at the University of Washington in Seattle, where he
held the Boeing CEO Philip M. Condit chaired professorship and
chaired the University of Washington Boeing Executive Development
Course. During a fourteen-year interim period in his career at the
Harvard Business School, he cofounded and chaired Nolan, Norton, &
Co., a pioneering strategic IT consulting fi rm, which was later merged
with KPMG. He has been a part of the IT industry for over forty years
as a professor, researcher, consultant, and practicing executive, as well
an active board member.
Shannon ODonnell (now Shannon Hessel) is an assistant professor of art, leadership, and entrepreneurship and director of The Studio
at Copenhagen Business School. Her research focuses on collaborative
About the Authors
328
creativity, innovation management, and the role of design and
arts-based practices in business value creation. She has also coauthored,
with Robert Austin and Richard Nolan, articles related to the special
pedagogical approach developed for this book, several Harvard Business School teaching cases, and Harder Than I Thought: Adventures of a
Twenty-First Century Leader (Harvard Business Review Press, 2013).
She has been a research associate at the University of Washington Foster
School of Business and at Harvard Business School, and was formerly
Resident Director and Dramaturg at Peoples Light and Theatre.

---

Get Professional Assignment Help Cheaply

Are you busy and do not have time to handle your assignment? Are you scared that your paper will not make the grade? Do you have responsibilities that may hinder you from turning in your assignment on time? Are you tired and can barely handle your assignment? Are your grades inconsistent?

Whichever your reason is, it is valid! You can get professional academic help from our service at affordable rates. We have a team of professional academic writers who can handle all your assignments.

Why Choose Our Academic Writing Service?

• Plagiarism free papers
• Timely delivery
• Any deadline
• Skilled, Experienced Native English Writers
• Subject-relevant academic writer
• Adherence to paper instructions
• Ability to tackle bulk assignments
• Reasonable prices
• 24/7 Customer Support
• Get superb grades consistently

Online Academic Help With Different Subjects

Literature

Students barely have time to read. We got you! Have your literature essay or book review written without having the hassle of reading the book. You can get your literature paper custom-written for you by our literature specialists.

Finance

Do you struggle with finance? No need to torture yourself if finance is not your cup of tea. You can order your finance paper from our academic writing service and get 100% original work from competent finance experts.

Computer science

Computer science is a tough subject. Fortunately, our computer science experts are up to the match. No need to stress and have sleepless nights. Our academic writers will tackle all your computer science assignments and deliver them on time. Let us handle all your python, java, ruby, JavaScript, php , C+ assignments!

Psychology

While psychology may be an interesting subject, you may lack sufficient time to handle your assignments. Don’t despair; by using our academic writing service, you can be assured of perfect grades. Moreover, your grades will be consistent.

Engineering

Engineering is quite a demanding subject. Students face a lot of pressure and barely have enough time to do what they love to do. Our academic writing service got you covered! Our engineering specialists follow the paper instructions and ensure timely delivery of the paper.

Nursing

In the nursing course, you may have difficulties with literature reviews, annotated bibliographies, critical essays, and other assignments. Our nursing assignment writers will offer you professional nursing paper help at low prices.

Sociology

Truth be told, sociology papers can be quite exhausting. Our academic writing service relieves you of fatigue, pressure, and stress. You can relax and have peace of mind as our academic writers handle your sociology assignment.

Business

We take pride in having some of the best business writers in the industry. Our business writers have a lot of experience in the field. They are reliable, and you can be assured of a high-grade paper. They are able to handle business papers of any subject, length, deadline, and difficulty!

Statistics

We boast of having some of the most experienced statistics experts in the industry. Our statistics experts have diverse skills, expertise, and knowledge to handle any kind of assignment. They have access to all kinds of software to get your assignment done.

Law

Writing a law essay may prove to be an insurmountable obstacle, especially when you need to know the peculiarities of the legislative framework. Take advantage of our top-notch law specialists and get superb grades and 100% satisfaction.

What discipline/subjects do you deal in?

We have highlighted some of the most popular subjects we handle above. Those are just a tip of the iceberg. We deal in all academic disciplines since our writers are as diverse. They have been drawn from across all disciplines, and orders are assigned to those writers believed to be the best in the field. In a nutshell, there is no task we cannot handle; all you need to do is place your order with us. As long as your instructions are clear, just trust we shall deliver irrespective of the discipline.

Are your writers competent enough to handle my paper?

Our essay writers are graduates with bachelor's, masters, Ph.D., and doctorate degrees in various subjects. The minimum requirement to be an essay writer with our essay writing service is to have a college degree. All our academic writers have a minimum of two years of academic writing. We have a stringent recruitment process to ensure that we get only the most competent essay writers in the industry. We also ensure that the writers are handsomely compensated for their value. The majority of our writers are native English speakers. As such, the fluency of language and grammar is impeccable.

What if I don’t like the paper?

There is a very low likelihood that you won’t like the paper.

Reasons being:

• When assigning your order, we match the paper’s discipline with the writer’s field/specialization. Since all our writers are graduates, we match the paper’s subject with the field the writer studied. For instance, if it’s a nursing paper, only a nursing graduate and writer will handle it. Furthermore, all our writers have academic writing experience and top-notch research skills.
• We have a quality assurance that reviews the paper before it gets to you. As such, we ensure that you get a paper that meets the required standard and will most definitely make the grade.

In the event that you don’t like your paper:

• The writer will revise the paper up to your pleasing. You have unlimited revisions. You simply need to highlight what specifically you don’t like about the paper, and the writer will make the amendments. The paper will be revised until you are satisfied. Revisions are free of charge
• We will have a different writer write the paper from scratch.
• Last resort, if the above does not work, we will refund your money.

Will the professor find out I didn’t write the paper myself?

Not at all. All papers are written from scratch. There is no way your tutor or instructor will realize that you did not write the paper yourself. In fact, we recommend using our assignment help services for consistent results.

What if the paper is plagiarized?

We check all papers for plagiarism before we submit them. We use powerful plagiarism checking software such as SafeAssign, LopesWrite, and Turnitin. We also upload the plagiarism report so that you can review it. We understand that plagiarism is academic suicide. We would not take the risk of submitting plagiarized work and jeopardize your academic journey. Furthermore, we do not sell or use prewritten papers, and each paper is written from scratch.

When will I get my paper?

You determine when you get the paper by setting the deadline when placing the order. All papers are delivered within the deadline. We are well aware that we operate in a time-sensitive industry. As such, we have laid out strategies to ensure that the client receives the paper on time and they never miss the deadline. We understand that papers that are submitted late have some points deducted. We do not want you to miss any points due to late submission. We work on beating deadlines by huge margins in order to ensure that you have ample time to review the paper before you submit it.

Will anyone find out that I used your services?

We have a privacy and confidentiality policy that guides our work. We NEVER share any customer information with third parties. Noone will ever know that you used our assignment help services. It’s only between you and us. We are bound by our policies to protect the customer’s identity and information. All your information, such as your names, phone number, email, order information, and so on, are protected. We have robust security systems that ensure that your data is protected. Hacking our systems is close to impossible, and it has never happened.

How our Assignment Help Service Works

1. Place an order

You fill all the paper instructions in the order form. Make sure you include all the helpful materials so that our academic writers can deliver the perfect paper. It will also help to eliminate unnecessary revisions.

2. Pay for the order

Proceed to pay for the paper so that it can be assigned to one of our expert academic writers. The paper subject is matched with the writer’s area of specialization.

3. Track the progress

You communicate with the writer and know about the progress of the paper. The client can ask the writer for drafts of the paper. The client can upload extra material and include additional instructions from the lecturer. Receive a paper.

4. Download the paper

The paper is sent to your email and uploaded to your personal account. You also get a plagiarism report attached to your paper.

GET A PERFECT SCORE!!!

---