Scaling up IT: Weighing the Options, Maintaining the Balance

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