"We'll Support It - If You Can Agree:" Universal E-Mail at the University of Pennsylvania

|-------------------------------------|
|  Paper presented at CAUSE92         |
|  December 1-4, 1992, Dallas, Texas  |
|-------------------------------------|



"WE'LL SUPPORT IT--IF YOU CAN AGREE":
UNIVERSAL E-MAIL AT THE UNIVERSITY OF PENNSYLVANIA

Linda May
Director of Planning, Information Systems and Computing
University of Pennsylvania, Philadelphia, Pennsylvania
may@al.relay.upenn.edu

Daniel A. Updegrove
Associate Vice Provost, Information Systems and Computing
University of Pennsylvania, Philadelphia, Pennsylvania
danu@dccs.upenn.edu

Ira Winston
Director of Computing, Engineering and Applied Science
University of Pennsylvania, Philadelphia, Pennsylvania
ira@cis.upenn.edu


ABSTRACT

In highly decentralized universities where substantial computing 
services are provided by the schools, a major challenge for a central 
computing organization is getting the schools to agree on a software and 
hardware portfolio that is both limited and supportable. From the 
schools' point of view, the challenge is to provide the specialized 
services their clients need while pressing for central support that is 
of necessity more generic. From the schools' point of view, in fact, a 
better title for this presentation is "If We Can Agree ...You'll Have to 
Support It." The University of Pennsylvania's journey toward universal 
electronic mail for faculty, students, and staff offers technical, 
political, and organizational insights for decentralized institutions 
and others faced with negotiating agreements across diverse 
constituencies. What started as a task force to explore the feasibility 
of a common e-mail offering for undergraduates became a lightning rod 
and forcing function for other campus-wide issues, including the role of 
the network, the relationship of central computing to the schools, and 
the contrast in perspective between large, technologically sophisticated 
schools and smaller ones.




"We'll Support It If You Can Agree":
Universal E-Mail at the University of Pennsylvania

In decentralized universities where substantial computing services are 
provided by the schools, a major challenge for a central computing 
organization is getting the schools to agree on a software and hardware 
portfolio that is both limited and supportable. From the schools' point 
of view, the challenge is to provide the specialized services their 
clients need while pressing for central support that is of necessity 
more generic. This presentation focuses on negotiating electronic mail 
standards and support in a radically decentralized institution like the 
University of Pennsylvania, where schools and centers control their own 
investments in information technology.

Your institution may not be as decentralized as Penn. With industry 
trends toward distributed computing and with the inability of central 
organizations to meet ever expanding need, however, you may find 
yourselves with increasingly independent local organizations with the 
finances and expertise to go their own way. It's important to look for 
opportunities for synergy.

In negotiating standards at the University of Pennsylvania, we find 
ourselves thinking of Penn's founder, Benjamin Franklin. As usual, 
Franklin sees both sides of the issue:
     Neither a borrower nor a lender be.... points to the value of 
Penn's twelve schools' independence, while

     We must indeed all hang together, or,
     most assuredly, we shall all hang separately....

captures the need for cooperation in the face of technological 
challenges and constrained resources.

In this presentation, we describe the e-mail situation at Penn, the 
bargain we struck, the year-long task force activity, some of the 
outcomes, and, most importantly, the technical, political, and 
organizational lessons we learned.


The Forcing Factor and the Bargain

When the story began a little over a year and a half ago, e-mail was 
well established in some Penn schools and most administrative units. In 
a patchwork of host- and local-area-network-based services, PROFS was 
deployed by Arts and Sciences; All-in-1 by Wharton, the Medical School, 
and central administration; UNIX Mail by Engineering; and QuickMail, 
Pegasus, and several other systems were emerging. Interoperability was a 
problem for everyone and keeping all the gateways working was a real 
effort for the central computing organization, Information Systems and 
Computing (ISC).

At that point, the School of Arts and Sciences announced its intention 
to offer email to all 10,000 undergraduate and graduate students. This 
forcing factor triggered a series of events. The "big three" 
undergraduate schools. Arts and Sciences, Wharton, and EngineeringÑ
decided to seek a common e-mail system, given the high cross-
registration among Penn's four undergraduate schools.

The "big three" approached the central computing organization to 
discuss, at a minimum, impact on the central modem pool and to explore 
possibilities for working together. One thing led to another, the 
schools put some pressure on central computing (a more accurate title 
for this presentation might be "If We Can Agree, You'll Have to Support 
It" ) and the Vice Provost for Information Systems and Computing struck 
a deal. He offered basic support from the central networking and end-
user support groups if the schools could agree on a common e-mail 
solution. The schools would continue to finance, operate, and administer 
their e-mail systems.


Vehicles, Strategies, and Outcomes

On that optimistic note, a campus-wide task force was launched. The 
fourth undergraduate schoolÑNursing, which did not offer e-mail at the 
time was drawn into the discussion. Task force scope and membership 
quickly expanded beyond the initial goal of a common e-mail solution for 
undergraduates. Electronic bulletin board service (NetNews), the task 
force decided, would greatly enhance the academic potential of e-mail. 
Task Force membership expanded to include all of Penn's graduate and 
professional schools, some of whom observed for a few meetings and 
decided that e-mail was not a priority this year for their school.

With Arts and Sciences already committed to offering e-mail to its 
10,000 students, the objective of the task force was not to decide 
whether common e-mail is feasible, but to figure out how to minimize 
costs and make it work. The group investigated first- and second-order 
impacts of campus-wide e-mail in a place as large as the University of 
Pennsylvania, with 21,000 students and 20,000 faculty and staff. Three 
challenges dominated the weekly discussions and more frequent e-mail 
exchanges:
  * Identify a low-cost, supportable e-mail standard to replace the 
    numerous systems proliferating at Penn
  * Articulate school and central support services to handle a 100% 
    increase in the number of e-mail users on campus.
  * Avoid overcrowding in student computer labs, many of which are at 
    capacity during peak times in the semester.

Strategy and agreements. 
The task force adopted a two-level strategyÑa clientserver Post Office 
Protocol (POP) approach over the long term and for those who already 
have the necessary IP connectionsÑwith the UNIX host-based ELM system as 
an interim solution. E-mail is most valuable when a critical mass of 
people have it. ELM would serve the large group that currently lacks IP 
connections. POPÑwith its friendly desktop client interfacesÑwould be 
available to those who could take advantage of it.

Two public domain e-mail software products, ELM and Eudora (POP for 
IPconnected Macintoshes) were endorsed. A DOS version of Eudora is 
expected to be released soon. Some schools will operate their own ELM 
and Eudora servers, while others will buy "retail" services from the 
central computing organization.[1]

Once basic direction was set, the task force split into working groupsÑa 
POP group, an ELM group, and a small schools group. The ELM group met 
its goal of deploying a common version of ELM within six months. They 
selected standard ELM (for feature richness), the PICO editor (for ease 
of use), and default settings that would create a consistent interface 
and allow one set of documentation to serve campus-wide. Support staff 
from several schools worked together to develop reference cards and 
video training and the central publications group developed a users' 
guide. The central networking group modified ELM and Eudora to access 
Penn's online electronic mail directory. Issues of modem capacity and 
modifications to the online directory database were referred to the 
parent task force.[2]

     ___________________________
       [l] Details of the e-mail service offerings are available in   
     Daniel Updegrove's article, "E-Mail at Penn," PennPrintout, Volume 
     9:2, October, 1992, published by the Office of Information Systems 
     and Computing, University of Pennsylvania.

       [2] A useful discussion group on technical and other aspects of 
     electronic mail is the list serve cw-email(@tecmtyvm.bitnet or cw-
     email@tecmtyvm.mty.itesm.mx.
     ___________________________

The small schools group investigated options for providing e-mail in 
small schools and came up with decisions ranging from "wait and see" to 
putting up 100 ELM accounts on a first-come-first-served basis. E-mail, 
however, turned out not to be the real point of the small schools group:

     To me what's important about the group is not mail. Mail is an 
     example of somethingÑhow do you handle support when you have such a 
     small budget and almost no staff?
                         ÑMember of small schools group

The small schools joined the task force in the first place to 
investigate e-mail and see how pervasive it was going to be. If every 
other student on campus were going to have e-mail, the small schools 
would have to find a way to provide it also. Above all, the small 
schools were looking for political leverage with their own deans, 
strategies to convince their deans to devote resources to computing 
initiatives like e-mail. Central computing began treating the small 
schools group as a customer focus group. Here were people with very 
small budgets, very few staff members, no critical mass, and deans who 
were not entirely convinced of the value of computing. We asked all 
kinds of questions. The group gave patient, thoughtful feedback, which 
we tried to repay with information and introductions to people who were 
useful to know. The members treated the group as a place to share 
expertise, resources, and strategies for doing more with less; a place 
to get information, make their voices heard, and make contacts. We ended 
up with a friendly, active interest group that will continue by explicit 
choice after the other e-mail working groups have disbanded.


Lessons Learned

We learned lessons about e-mail, the process, and each other.

+++ E-mail a vehicle 
We learned that electronic messaging may not be the main benefit of a 
campus-wide e-mail initiative. E-mail is a vehicle to take fuller 
advantage of the network. Once you have a network connection for e-mail, 
you have access to the vast riches of the Internet.

+++ Offer an early carrot. 
We believe the Vice Provost's early offer, 'We'll support it, if you can 
agree," was crucial. The task force had a clear goal; the carrot was 
there for all to see.

+++ Allow the bargain to evolve. 
The Vice Provost's offer turned out to be naive; we didn't agree on a 
single e-mail system, and support was shared across the University. The 
task force allowed the bargain to evolve, however, as the situation 
evolved.

+++ It takes an issue to pull people in. 
The small schools say they would probably not have joined a generic 
small schools interest group, although they are more than happy to 
continue as one. It took an issue to bring them together.

+++ Match group structure to life cycle of problem. 
In hindsight, we see that we mapped the structure of the group to the 
life cycle of the problem. The main group explored and focused the 
problem and then let go, turning the problem over to the working groups 
at just about the right time not too soon, not too late. The working 
groups kept in touch via e-mail. Any member could receive agendas and 
minutes of any other group and participate in online discussions.

+++ Get past the purists. 
Management turnover in the central user-support organization put central 
hotline support commitments in question until a new director could be 
hired. While some members of the ELM working group wanted 
to wait for full hotline support before deploying ELM, the group decided 
to focus instead on training materials that would reduce the need for 
hotline support.

The ELM working group also included a contingent that did not want to 
settle for a terminal-to-host e-mail system such as ELM, preferring to 
waitÑeven if it meant waiting two or three years- for Penn's 
infrastructure to support client-server email. We worked hard to 
convince these people of the value of ELM as an interim solution.

+++ Put up something "good enough to build interest." 
Our strategy was to deploy a reasonably user-friendly interim system 
like ELM in order to build interest in e-mail itself. We hoped that a 
more e-mail-literate community would push for the infrastructure 
investments that would make client-server e-mail possible in the future.

+++ Make it clear decisions will be made. 
We made a point of discussing an issue for several meetings and then 
announcing, for example, "At the next meeting we will make a final 
decision on which editor to use. Please bring the right people to make 
that decision." It seemed to work. The right people came to the 
meetings, decisions were made fairly smoothly, and people did not come 
back later saying they were not consulted.

+++ Use "They're going to do it anyway" productively. 
Several times when consensus seemed to break down we reminded the group 
that Arts and Sciences was going to deploy ELM for its 10,000 students 
no matter what the group decided to do. Arts and Sciences therefore 
served an energizing, forcing function to make the community act and 
keep it united throughout the project.

+++ We're all in the lobbying business. 
Three of the large schools banded together to pressure the fourthÑArts 
and SciencesÑto select an e-mail solution that would work for everyone. 
The small schools used the task force to pressure their deans to devote 
more resources to computing. The large schools used the group to 
pressure central computing to provide support. And the schools were not 
the only ones to pressure central computing. The chair of the task 
force, a member of central computing, used the group to pressure his own 
organization, whose management does not always agree where to devote 
energy and resources.

+++ Train more than one facilitator. 
Several members of the ELM group had recently attended a facilitator 
training course together. When meetings seemed to go astray, they would 
look at each other and try out techniques they had learned.

+++ A post-mortem is worth the effort. 
Doing a CAUSE paper forced us to evaluate what went right and what went 
wrongÑwell worth the effort. We also assigned ourselves the task of 
analyzing three important current efforts to see if we really had 
learned lessons from the e-mail task force.


Wrap-up

Almost twice as many Penn faculty and students will soon have e-mail. We 
didn't agree on one e-mail system, but we agreed on a manageable, 
supportable few. We found a middle ground between expedient and state-
of-the-art solutions. Most importantly, we built partnerships, tested 
strategies for division of labor across the University, opened channels 
of communication, and laid the groundwork for political coalitions. We 
think we've been faithful to Ben Franklin's dual messages of 
independence and collaboration, honoring the schools' need for 
flexibility and independence while finding a way to work together for 
the good of the whole.