Scaling up IT:
Weighing the Options, Maintaining the Balance
by José-Marie Griffiths
The
process of scaling up information technology (IT) has many similarities
with the process of climbing a mountain. The process of planning and
carrying out a successful mountain-climbing expedition thus provides
an excellent way of thinking about the processes we are using -- and
the challenges we are facing -- at our respective institutions as we
seek to scale and integrate technology services into the institutional
culture and context.
Three years ago
I moved from the University of Tennessee to the University of Michigan.
The many dimensions of the context and culture of these two institutions
were very different (see figure 1). I have thoroughly enjoyed this transition.
I have also discovered that many of the processes I used to determine
organizational priorities -- strengths and weaknesses, needs and resources,
constraints and potentials -- at Tennessee are the same processes I
am using now at Michigan, though the processes have been modified for
and applied to a very different culture and context. The environments
are quite different, but the processes I am using to "scale the mountain"
are quite similar.
Integrating
IT within the Culture and Context of an Institution
The task of scaling
up IT, integrating it within the culture and context of an institution,
has many of the same aspects and demands of the task of leading a mountain-climbing
expedition. We must begin with those we serve, those for whom we must
provide efficient tools for the journey ahead. At institutions, we must
provide technology tools to help those we serve to reach their teaching-learning,
research, and administrative goals. Although each of our campuses has
unique characteristics -- and certainly each has its share of unique
individuals as well -- there are some similarities with which we all
can identify.
Changes in
Our User Population
One similarity
is that the user population has changed in several ways. First of all,
our users are more plentiful, with increasingly diverse interests. At
the University of Michigan, in the last five years,
- the number of
users of the campus core technology services has increased from under
20,000 to over 100,000,
- we have increased
our dial-in modem pool by more than 700 new modems, and the time that
each of our modems is in use has stayed constant,
- the traffic on
our campus network backbone (average sustained daily utilization of
megabits per second) has increased from 9 Mbps to 60 Mbps, and
- we have increased
the number of telephone lines on campus by over 10,000 new lines.
Second, in the
past our users all wanted to do basically the same kinds of things --
or at least we were able to limit what they could do. Now it's a challenge
to keep up with their diverse and expanding interests. Faculty members
and students often are members of communities far beyond the boundaries
of campus. As a result, they frequently encounter very esoteric or unusual
technology applications or resources that are being used at another
institution and that are just right for the work in their own discipline,
and they immediately want to have that capability added to their campus.
From class lists in the registrar's office to choreography in the dance
department, from the digital library papyrology project in archeology
to the Sunrunner Solar Car in engineering, we are expected to support
a myriad of diverse technologies.
Third, the technical
sophistication of our users and the intensity of their use have increased.
At the University of Michigan in the last five years, for example, the
percentage of students using a computer daily or weekly to read e-mail
has increased from 17 percent to 92 percent, and the number of times
per year a computer in our campus computing sites is used has increased
from 1.59 million times to 2.33 million times. In the last two years,
the number of incoming freshmen who had Internet connectivity at home
before coming to the university has increased from 15 percent to over
75 percent.
So we have many
more people who are using technology more often and for whom we need
to provide new technologies that will help them meet their various goals.
And therein lies yet another problem: they are not all headed for the
same destination! One of our first challenges is to understand what
our users see as their goals and to what extent we can and cannot assist
them in reaching those goals.
The one thing we
can be fairly sure of is that we, as leaders, are the only ones who
have the goal of getting our entire institution where it needs to be.
To be quite honest, each individual is far more focused on his or her
own needs, accomplishments, and goals. Only to the extent that we promote,
encourage, and demand that the needs of the entire institution be taken
into consideration when making resource allocations and decisions will
our community understand the broader goals.
The Leader
as Cheerleader?
This pushes us
to an examination of another similarity: the role that we all, as leaders,
must assume. One of the metaphors of leadership that I strongly reject
is that of the leader as cheerleader. Especially when we are headed
into unknown territory, when we know that the challenges will be great
and the resources limited, all the enthusiasm in the world is not going
to be enough to get our institutions and our users where they need to
be. We have a responsibility to be skilled and knowledgeable; to constantly
study the challenges, consult the experts, and assemble the best teams
we can possibly find; to continually train diligently; to meet our commitments;
and to dig deeply into our own energy, initiative, and creativity to
truly lead. This is not the role of a cheerleader.
One of my staff
members, Sandy, told me of a time when she was hiking the Grand Canyon.
It had been raining for days, and when the group was less than a third
of the way across the floor of the canyon, they were suddenly alerted
to a serious flash-flood warning. Groups who had the money and the communications
ability were able to radio for and hire helicopters to lift them out
of the canyon, but other groups were left to get out of the canyon by
themselves as rapidly as they could. Sandy's group proceeded to do a
three-day hike in about eight hours. As they were climbing the final
face of the canyon to get to the top, they came across a woman, sitting
despondently at the side of the trail, who suggested they take whatever
they might want from her backpack. She had been abandoned by her team
when she had developed such blisters on her feet that she could no longer
walk. Her team had decided that under these threatening circumstances,
it was every person for herself, and since this woman could no longer
walk, she had resigned herself to the fact that she would die there
by the side of the trail.
Sandy's team was
appalled by this state of affairs, and even though they were in significant
danger themselves, they immediately decided to add her to their team
and do whatever they could to get everyone to safety. They noticed that
this woman was completely ill-prepared for such a trek through the Grand
Canyon. For example, she was wearing canvas sneakers, which had basically
fallen apart, instead of hiking boots, accounting for the deplorable
state of her now-raw feet. Her backpack was incredibly heavy, filled
with things she did not need and could not use -- including a five-pound
box of chocolates and heavy ropes that her expedition leader had put
in her backpack to be used by the entire team, the team that had abandoned
her some time ago. Sandy was horrified that this woman's expedition
leader had allowed her to set forth on the trek so poorly and inappropriately
prepared. Even worse, she had been abandoned when things got difficult.
Leadership is much
more than cheerleading. It includes making sure that those for whom
we are responsible have the training and the resources they need to
get where they want to be.
Decisions of
the Expedition Leader
Some of our greatest
challenges as expedition leaders come in deciding what -- and who --
gets to go to the top and what -- and who -- has to settle for staying
behind or for going only part of the way up. If this were not enough
of a challenge, we often discover that something or someone is requiring
us to take to the top something that we know is too heavy, old, and
lacking in functionality to be worth lugging up. The following story
illustrates my point.
A programmer-analyst
becomes a Year 2000 specialist. He makes enough money to go to a cryogenics
lab, where he asks to be suspended until July 15, 2000. He believes
that by then all the Y2K problems will be over and he will be able
to continue with his life.
When he wakes
up from his suspension he looks up to see himself surrounded by dozens
of people. A doctor tells him that something went wrong and apologizes
that he was not woken up in 2000 but in 9999. The doctor also tells
him that the president of Earth wants to speak to him. On a large
video screen is the image of the president, somebody who looks remarkably
like Bill Gates. The president tells him that there have been many
advancements since he was frozen: colonies on other worlds, faster-than-light
travel, etc. The programmer asks, "So why did you wake me up, and
why is everyone paying so much attention to me?"
The president
replies, "Well, the year is 9999, and the year 10,000 is just around
the corner, and your files say you know COBOL . . ."
A big piece of
leading this expedition is figuring out what items and what people we
need at every stage of the climb -- and recognizing that we will be
taking with us some things and some people we would just as soon leave
behind. Our available pack space and our expedition size are thus limited
in ways beyond our control.
Infrastructure
One of the first
issues to be addressed is one that most of our trekkers will care the
least about -- infrastructure. The infrastructure should be practically
invisible or at least totally taken for granted. The stronger our infrastructure,
the greater will be the risks we can take. Yet if it is not robust and
reliable, it can defeat the entire expedition.
The 1996 ill-fated
Mount Everest expedition, chronicled in Jon Krakauer's book Into
Thin Air, resulted in the deaths of six people. The failure of this
expedition was due in large part to a lack of infrastructure.
An unprecedented
number of teams were attempting summit climbs of Everest in 1996 (similar
to what we are now facing on our campuses: an increasing number of our
users who want to use technology to "scale the mountain"). The team
leaders of the various groups got together and agreed that, especially
given the number of novice climbers in the groups, one team needed to
go up the mountain first and string ropes that the rest of the climbers
could then use.
However, the team
responsible for setting up this infrastructure did not keep to the planned
schedule. As a result, when Krakauer's team started up the summit, they
had to wait for the infrastructure to be completed. This meant that
they attempted their final climb much later in the day than they should
have, and disaster ensued.
It's been said,
"Luck is what happens when preparation meets opportunity." For IT, we
must make sure that our infrastructure is in place and is robust before
we start trying to move climbers up the face of the mountain.
Alignment
Another issue that
I have been increasingly addressing at the University of Michigan is
alignment: both the internal alignment -- the "federating," if you will
-- of the university's shared IT needs and the external alignment of
our corporate IT partners to meet those needs.
I believe that
our models of partnership, the teams that we must form to get us to
the top of the mountain, must change dramatically. I call this moving
from "handout" to "handshake" to "hands-on." The initial model of partnership
consisted of little more than handouts, gifts given to the recipients
to use as they saw fit. Over time, some relationships developed that
were more akin to handshakes, initial partnership agreements with some
level of commitment on either side for a certain limited involvement.
However, today neither of these models is adequate to meet institutional
needs that are long-term, complex, global, and ever changing. We must
have the hands-on, committed, long-term involvement of our partners
in order to reach our IT summits.
Team
A third key decision
area for which leaders are responsible relates to the preparation, assignment,
and support of every member of the team. Again, mountain-climbing stories
are filled with accounts of failed expeditions as a result of inadequately
provisioned or secured base camps.
It is especially
important to determine which staff are needed in which positions --
and where expertise is lacking. Many staff members will not want to
go all the way up the mountain. They would much prefer to stay at a
level and location where they are competent and comfortable, doing work
they enjoy. Rabindranath Tagore, a Bengali Nobel Prize-winning writer,
once said, "The sparrow is sorry for the peacock at the burden of his
tail." We must not assume that everyone on the team wants to scale the
mountain. Those who remain at the base camp are as essential to the
success of the expedition as are those who climb to the summit.
Organizational
Priorities
At the University
of Michigan, I have the privilege of also being a professor in the School
of Information, and so periodically I get to spend time teaching in
the classroom as well as being an administrator. I once heard a story
about a time-management expert who had been invited to speak to a group
of business students. To drive home a point, he used what I consider
a great illustration on the issue of priorities.
As this guest speaker
stood in front of a group of high-powered overachievers, he announced,
"Time for a quiz." He pulled out a one-gallon, wide-mouthed mason jar
and set it on the table in front of him. Then he produced about a dozen
fist-sized rocks and carefully placed them, one at a time, into the
jar. When the jar was filled to the top and no more rocks would fit
inside, he asked, "Is this jar full?" Everyone in the class answered,
"Yes."
He said, "Really?"
He reached under the table and pulled out a bucket of gravel. He dumped
some of the gravel into the jar and then shook the jar, such that the
pieces of gravel fell down into the spaces between the big rocks. He
asked the group once more, "Is this jar full?" The class was now on
to him, and one of the students answered, "Probably not." "Good!" he
replied, reaching under the table and bringing out a bucket of sand.
He dumped the sand into the jar and shook the jar, and the sand filled
in the remaining spaces between the rocks and the gravel.
Again he asked
the class, "Is this jar full?" "No!" the class responded. "Good," he
said and grabbed a pitcher of water and poured the water into the jar
until it was filled to the brim. Then he looked up at the class and
asked, "What is the point of this illustration?" One eager beaver raised
his hand and said, "The point is, no matter how full your schedule is,
if you try really hard, you can always fit more things into it!"
"No," said the
speaker, "that is not the point. The truth this illustration teaches
us is: If you don't put the big rocks in first, you'll never get them
in at all."
When we are scaling
up IT on our campuses, we need to decide what the big rocks are and
make sure we put those in first. And we need to recognize that it is
often the guy with the sand or the water who shows up first and demands
our attention and action. We have to hold him off until we get the big
rocks in.
Multidimensional
Scaling
Often it is a significant
challenge to figure out what the big rocks are. What are the essential
things that we must have in our backpack and along on the expedition
to get to the top? I have consistently found a process of multidimensional
scaling to be helpful in making these decisions and in clarifying institutional
priorities.
The dimensions
an organization wants to examine can be many and varied. At the University
of Michigan, we chose to look at two: the benefit of the service and
the ease with which we could provide it, including both its cost-effectiveness
and the level of effort needed to provide it. We determined that there
were a number of criteria by which we needed to judge what we would
bring along in our packs and what we would be better off leaving behind.
We placed these in a grid (see figure 2), gave the forms to project
teams, and asked them to rate our various activities.
We asked the teams
to first address the issue of benefit. We had them do so by rating the
importance of the activity to our target audiences and then the importance
of the activity to what we had determined to be our organizational emphases.
The discussions that had to be conducted in these teams -- and with
our users -- to determine some of these ratings began to point out many
of the issues I have already mentioned: the users who saw the mountain
differently than did their colleagues or our IT organization; the things
that we have to carry in the backpack, even though none of our users
or our own teams like them, simply because they provide an essential
service for which we do not yet have a replacement; and so on. The primary
difficulty of these various "ratings" and perceptions is that different
individuals will be convinced of the value of different solutions based
on these assumptions.
We next took the
ratings these teams generated and mapped them onto a two-by-two matrix
(see figure 3). The ratings were entered clockwise, with those items
in the upper-right quadrant showing the highest ratings for both ease
of implementation and benefit and so on around the matrix.
And yes, we did
have some teams that, on their first pass, ended up with all of the
ratings in the upper-right quadrant. Sometimes that was appropriate,
and sometimes it wasn't. An easy way to deal with this problem is to
change the scale and see what still ends up in the upper-right quadrant.
Those are the things we must focus on if we are going to scale the mountain.
We found it very
helpful to require our project teams to do a SWOT (strengths, weaknesses,
opportunities, and threats) analysis, to write out what they saw as
the strengths and weaknesses of what we presently provide and how we
provide it and where they see the opportunities and threats to what
we are doing (see figure 4). This analysis helped leaders understand
- what we can
and cannot delegate,
- where we do and
do not need to be involved,
- what we can and
cannot change.
Sorting Out
Myth and Reality
Anyone who spends
any time reading the IT trade press knows that it is quite a challenge
for a CIO to sort out myth and reality. It is very easy to get distracted
hunting the Yeti instead of scaling the mountain. We must decide what
of the unknown is worth pursuing and what is not, which of the opportunities
and threats identified by our staff, our users, and our partners are
worth examining and which are not.
Ogden Nash wrote:
I've never
seen an abominable snowman I'm hoping not to see one, I'm also hoping,
if I do, That it will be a wee one.
Dependencies
An increasingly
challenging area, especially for those of us on campuses that were ahead
of the times twenty years ago, is dependencies. With our wonderful new
distributed systems, we also now face the challenge of the interdependence
of our systems and our users' systems.
Not too long ago,
the head of the Federal Aviation Administration (FAA) was on the news,
responding to the "F" grade that the FAA had received from the congressional
committee reviewing federal agencies' success in addressing Year 2000
issues. The FAA leader pointed out that one of the greatest challenges
the administration faced was not upgrading the 280 million lines of
code that the FAA is responsible for but ensuring that its changes are
compatible with those being made by all of the airplane, weather, and
other systems on which it depends. It was the process of managing the
dependencies that was crippling the FAA's efforts to address the real
problems.
In the zero-sum
game that we all play at budget time, and when we are desperately trying
to figure out what we can eliminate to reallocate resources to help
our users scale the mountain, it is very easy to start cutting and hope
for the best. We do so at our own peril, however. A careful review of
dependencies -- and it is often our front-line staff who can provide
the best assessment of this -- can prevent us from cutting the lifeline
that is helping us all make our way up the mountain.
Planning
for the Unplanned
It is critical
that we continually plan for the unplanned. Again, in the 1996 ill-fated
Mount Everest expedition, the team members had not carefully planned
for, nor were they being observant of, the unusual May weather that
made the final climb unexpectedly even more difficult.
In our own realms,
we need to be constantly aware of the following:
- Environmental
changes: for example, changes in institutional leadership or in funding
flow
- Technological
developments: for example, new hardware and software, and IT vendor
changes
- Maintenance issues
that drain resources: for example, the "frostbyte" we have all gotten
because of missing digits
Attitude
and Expectation Management
Finally, we must
be constantly aware of attitudes and expectations. I am always cautious
when someone tells me that doing something will be either easy or impossible.
I have learned to dig deeper, to understand more, and to make sure that
I share the speaker's assessment before I make a decision.
Many of us are
dealing with the attitude that technology is going to cost less or decrease
institutional costs or the attitude that since we'll never have enough
money, why try? We must constantly monitor and respond to all of these
attitudes.
Change: The
Constant
In closing, I'd
like to relate a story that I believe to be apocryphal but that illustrates
one of the most important considerations we must keep in mind as we
work to "scale the mountain" with IT at our respective institutions.
The following is
supposedly the transcript of a radio conversation between a U.S. Air
Force transport plane and Canadian authorities in the Yukon.
The U.S. Air
Force pilots saw something on their radar screen and lights in the
distance and sent out the following message: "Please divert your course
15 degrees to the North to avoid collision."
The Canadian
authorities who received the message responded: "Recommend you
divert your course 15 degrees to the South to avoid
collision. "
The U.S. plane
responded: "This is the captain of a United States Air Force plane.
I say again, divert your course."
The Canadian
radioman replied: "No, I say again, divert your course."
The U.S. plane
responded: "This is a United States Air Force C-5 Galaxy heavy-cargo
transport plane. Our aircraft is as long as a football field and as
high as a six-story building. Divert your course now!"
The Canadian
authorities replied: "We're sitting in our office on a mountain. Your
call."
We must be ready
to change course, be willing to understand that we may have misread
the signals, and be able to go in a different direction from the one
we initially planned.
So, do we ever
actually reach the summit?
Well, it has been
said that great accomplishments are rarely isolated mountain peaks;
they are the summits of ranges. There is always another mountain range,
and if we do our job well, there will always be more people wanting
to go up a mountain, and they will want us to lead them.
I do believe that
IT leaders are facing challenges that none of us have ever experienced
before. The rate of change in IT and in higher education is faster than
ever before, and the changes affect more people and more functions in
our institutions. However, scaling the mountains of change can be immensely
invigorating and interesting, as well as intellectually stimulating
and, yes, fun. I look forward to hearing the news of the peaks that
will be scaled by all of us in the next few years.
Note: This article
is based on a presentation made at the "Seminars on Academic Computing"
conference, August 12, 1998.
Dr. Jose-Marie
Griffiths is Chief Information Officer at the University of Michigan,
Executive Director of the university's centralized technology organization,
the Information Technology Division, and a professor in the School of
Information. Her Web site address is: http://www.cio.umich.edu/.
