Enterprise-Wide System Implementations at Multicampus ...
EDUCAUSE Center for Applied Research
Research Bulletin Volume 2005, Issue 4
February 15, 2005
Norma Brenner Holland, Indiana University
Laurie Sullivan, Indiana University
4772 Walnut Street, Suite 206 Boulder, Colorado 80301-2538 www.educause.edu/ecar/
Implementing a major enterprise-wide system is challenging in any environment;
implementing such a system for multiple university campuses in a single environment is
extremely so. In the early 1980s, most institutions had little choice other than developing
these large systems in-house. The available vendor products were not mature enough to
satisfy most institutions’ needs, and they could not scale for large universities. In the
1990s vendor products became more robust and available, and at many institutions they
seemed to be the alternative of choice. Enterprise resource planning (ERP) systems
became increasingly popular. Among the 12 Midwest institutions1 that are members of
the Committee on Institutional Cooperation (CIC), 8 adopted ERP solutions for their
enterprise-wide systems needs. For purposes of this research bulletin, ERP will refer to
enterprise-wide information systems acquired from a vendor.
Implementing a single ERP product for multiple campuses requires strong sponsorship
from institution-wide leaders with the willingness to drive needed change. It has been
stated often that large systems implementations do not falter because of the technology
involved; people and politics are the issue. Multicampus institutions generally have
widely distributed organizational structures, as well as differences in student
populations, faculty policies, and traditional business practices. In such an environment,
ERP implementations can be successful and beneficial for the entire institution and can
promote the establishment of common, streamlined business practices that result in
better services for students, faculty, and staff.
While this research bulletin focuses on ERP implementations at multicampus institutions
and draws from the experiences of Indiana University, California State University, the
University of Minnesota, and Purdue University, lessons learned from these institutions
should offer benefit to all involved in ERP implementation and maintenance.
Highlights of Multicampus ERP
A multicampus institution often has a complex distributed environment, from both an
academic and an administrative perspective. A typical institution of this kind could have
a combination of small and large campuses with distinct academic missions. The
missions drive the policies, practices, services, and organizational structure at each
campus. ERP systems require a certain degree of standardization for policies, practices,
and service delivery. It is the conflict between this standardization and the individualized
campus structures that contributes to the special challenge of implementing ERP in a
The Diverse Nature of Multiple Campuses
Campuses that are part of a large university system generally have diverse student
populations. Some might have “traditional” students: high school graduates moving
through a four-year program. Others might have an older, employed, commuting student
population. In addition, individual campuses and the schools within them typically
develop different business processes throughout the years. They may be using a variety
of systems that are either built by the campus or purchased from a vendor. Campuses
might have different tuition and fee structures, academic year calendars, human
resource (HR) policies, and methods of communicating. These differences result in a
large and diverse constituency that must be involved in ERP implementation.
The Decision for a Common System Throughout
A multicampus institution must have a solid requirement in order to justify a large ERP
system purchase and implementation. At Indiana University (IU) in 1997 a new vice
president for information technology and chief information officer (CIO) was charged by
the president to create an all-campus Information Technology Strategic Plan (ITSP),2 to
be aligned with the current institutional plan. One section of the ITSP described the need
to completely reengineer the institution’s aging enterprise-wide information systems,
some of which had been developed in the 1980s. These systems included a range of
traditional administrative and academic information systems3 serving seven IU
campuses. A new student information system was given top priority, with a new human
resource system classified as a high priority; PeopleSoft was chosen for both systems.
Although a mature systems development staff had developed many all-campus systems,
ERP brought its own unique challenges. Since all campuses were using the same
legacy system supported by the central IT organization, the case for change for all
campuses at the same time was easily made.
Purdue University recently began its ERP selection process to determine the best fit for
a student, human resources, and financial system implementation scheduled to begin in
July 2005. Purdue’s three regional campuses currently have separate and mature
vendor-based student system products. Purdue’s main campus student system is old
and was developed mostly in-house. All Purdue campuses currently use common,
outdated HR and financial systems. The dilemma was whether or not to pursue a
common, integrated system strategy for all campuses or whether to allow for different
systems at different campuses.
The original Purdue “Case for Change” had compared a single-product, integrated
strategy versus a best-of-breed strategy. Consultants suggested that the five-year total
cost of ownership for the best-of-breed solution would be 52 percent higher than the
single-product solution. For that reason, the consultants recommended a single,
integrated ERP product. The subsequent budget proposals were based on a common
system across all campuses. Predictably, this caused anxiety and debate. It made sense
to use a common solution across all campuses for HR and financials, since that was
already the practice. Two of the regional campuses preferred the option of retaining their
existing student systems to provide established services for their users, while the main
campus argued for a common system that would correct perceived problems in
institutional data consolidation for reporting. A single solution would also make simpler a
mandated implementation of a common ID for students and staff across all campuses.
There were also concerns about the costs of integrating disparate products and
maintaining those interfaces through version upgrades. Ultimately, Purdue’s president
decided that all campuses will use a single, common software system solution and not
maintain their current systems. While it was agreed that not all campuses necessarily
needed or wanted a new and possibly different student system, it was in the best
interests of the institution as a whole to integrate its data and processes using a
“Based on our research and benchmarking, we believe that a common system will result
in better and less costly data and process integration,” said Jeff Whitten, associate vice
president of enterprise applications and chief architect of the Purdue application vision.
“At the same time,” he continued, “we are committed to a multicampus implementation
that allows for flexible configurations and business rules between campuses, to meet the
unique customer needs of our regional campuses. And we are equally committed to the
goal that the regional campuses will not lose existing student services that they deem
necessary to remain regionally competitive for their students. Indeed, we would hope to
expand on those services for all campuses, including the main campus. I am especially
pleased that we selected a regional campus administrator as executive director for the
implementation. It sends a message that we are in this together!”
In 1998, the chancellor and presidents of the California State University (CSU)
determined that the 23 campuses and the Chancellor’s Office should manage
themselves against a common set of administrative best practices. In order to
accomplish this management objective, the chancellor mandated the implementation of
a single, common administrative suite of software, including HR, student, and financial
systems, requiring all 23 campuses to migrate to this software. Given this charter,
collaboration among the campuses and the Chancellor’s Office was essential from the
inception of the CSU project. This collaboration is manifested primarily through campus
functional leadership and local implementation combined with centralized Chancellor’s
Office project management.
Hilary Baker, who managed the first five years of the system-wide ERP project at the
CSU, believes that system-wide projects provide additional opportunities over single
campus implementations in collaboration and standardization; and collaboration is
wonderful as long as decisions still get made. She noted, “In the budget-challenged
world that we all live in within higher education, it only makes sense to figure out a
solution once and then reuse that solution with the other campuses. At the CSU, the
enterprise system implementation workload was shared across the 23 different
campuses—one campus became a leader in certain HR functions, another campus
became a leader in certain financial aid functions. This requires that a level of trust is
established with the whole institution rather than just on your own campus, but the
means to accomplish more with the same amount of staff makes the effort worthwhile.”
Funding for multicampus enterprise system implementations may come from a variety of
sources that include state and federal appropriations, reallocation from the campuses
and university administration, student technology fees, and reallocation from the IT
Institutions must consider organizational structure as part of their implementation
strategies. At IU, in 1999 the system-wide president appointed a committee to study
savings possibilities within the administrative units on all campuses. The committee
engaged a consultant firm that recommended organizational change prior to this major
system-wide implementation. In response to this recommendation, the university
established new human resource management system (HRMS) and student information
system (SIS) processes and a new Student Enrollment Services (SES) organization.
The consultants emphasized the importance of organizational change prior to
implementation in order to realize the maximum benefit of investments in new
information systems. Other multicampus institutions in this study also decided early that
a central entity should be responsible for initial and ongoing training, database table
setup and maintenance, and security setup and access.
SES and student service units at each IU campus are currently responsible for the
ongoing activities essential to the continuing functioning of the SIS. As SIS modules are
moved into production, SES assumes responsibility for the back-office operational
functions. SES and student service units at each campus also provide the ongoing
support for policies, processes, and services of IU’s academic mission. SES is designed
to enhance service delivery by the campuses through processes that improve efficiency
and effectiveness of the systems, particularly through the adoption of common business
The Project Team and Consultants
The project team should include a combination of technical staff and functional staff from
all campuses, as well as system-wide representatives. Staff members should be
committed for the duration of the project and should report to a single leader with
subordinate management. When forming the project team, it is also important to identify
the infrastructure staff that will administer the application, install the software application
components, perform application upgrades, and apply fixes. The individuals responsible
for maintaining the vendor software (application administrators) require specialized
knowledge about the application infrastructure, but also need to be skilled in the areas of
system administration, database administration, Web server administration, and
While technical and functional staffs focus attention on the new system, replacements
(backfill) often must be engaged to provide ongoing support for current systems.
Resource allocations for these replacements should be articulated in the project plan.
Plans often include the downsizing of project teams after core implementation is
complete; however, implementation of major upgrades may require teams to be larger
than for ongoing maintenance.
Many institutions contract with consultant firms to assist with ERP implementation, and
they should develop a consulting strategy early in the project. Some institutions may
want an implementation partner while others may want to contract with consultant firms
on a statement-of-work basis. Institutions may also consider a fixed price for a very
specific set of deliverables. It is wise to work through the institutional process to
authorize the consultant firm or firms for the duration of the project.
Projects can be driven from the central IT organization, a functional system-wide office,
or some other suitable structure. In any case, it is advisable to have one point where
complete responsibility for the project lies. A governance structure should be established
early on to work through the inevitable issues that arise. Sponsorship at the campus
officer level is essential, along with steering committees with faculty and administrators
from all campuses. The steering committees can be the official guiding bodies for the
projects, but a subset of the committee members, including those who are executives,
will usually become the actual priority-setting bodies for the projects. The executive
group determines the scope, approved set of customizations across all module areas,
and timing for when customizations will be implemented and also assists with project
staffing needs. Faculty committees on all campuses can provide input on faculty policy
Lack of timely decisions in ERP projects can easily be viewed as problems that then
become the reason to delay or even stop a project. It helps to view each decision as an
opportunity for new ideas, options, and approaches and move through these in an
organized way. At IU a decision making structure was developed to determine who
would make what types of decisions (for example, academic policy, administrative
policy, business procedures). Many decisions having low political sensitivity in these
areas can be made by the project teams. Decisions pertaining to scope, priorities,
budgets, new funding requests, staffing, and timeline issues can best be vetted through
a small executive committee before moving to other forums for review and/or decisions.
Larger governance committees, including faculty groups and upper administration,
review only the more politically sensitive decisions. Vice presidents and chancellors
need only consider decisions that cannot be resolved at a lower level.
To ensure inclusive communication to a large constituency in an organized manner, a
communications team should be established to facilitate regular communications. The
team should include some professional public relations staff as well as functional staff
from all campuses. This group should plan and handle communication to all campuses
regarding user expectations and rollout schedules. Hilary Baker, formerly of the
California State University and now associate vice president and CIO at Pepperdine
University, noted that the communications group should communicate often and
recognize the different audiences—internal to the project, external to the project but
internal to the institution, and external to the institution. She stated, “Although an ERP
project produces lots of written communication, it is also necessary to meet in person
with the different groups that already exist on campus.”
In any large ERP implementation, some early strategic decisions will drive the entire
implementation. The implementation strategy determines how the new system
functionality is released into production; this may include a “big-bang,” module-by-
module, or phased approach. Each has its pros and cons.
Big Bang vs. Phased or Modular Approach
The big-bang implementation means that all new business processes are turned on in
production at once. An advantage of this strategy is that it avoids the need to build short-
term or throw-away interfaces to the legacy system. Another advantage is that once the
new system is in production, the legacy system no longer requires operational support.
However, when all functionality for a system is turned on the same day, user training
schedules must be compressed and help desk support must be fully available on Day
One. There are many potential points of failure when new business systems and
processes are launched all at once.
In a phased or module-by-module implementation, support is focused on the new
business processes for a particular phase, so there are typically fewer business process
and technical fail points. There are several challenges in dealing with a phased
implementation. There may be times when dual data entry is required to keep both
systems in sync, and some users must be testing the new system while others are using
the old system. Additionally, and most importantly, it is very difficult to have enough
experienced staff for both the project and the legacy systems. All campuses at IU
decided on big-bang implementation for the HR system and phased implementation for
Single vs. Multi-Institution Configuration
A key decision for institutions to make when implementing an SIS such as the
PeopleSoft Student Administration product involves whether to configure the system as
one institution or as multiple institutions (campuses). The multi-institution approach
adopted by IU defines each campus as an institution in a single PeopleSoft database,
each having its own set of careers (for example, undergraduate, graduate, law, medical),
programs (for example, degree and nondegree), plans (for example, majors, minors,
certificates), academic calendars, and degrees, as appropriate. This approach allows
each campus to maintain a common structure with distinct data and business processes
while the demographic and biographic information is appropriately maintained and
shared across all institutions. However, IU has identified some situations where
campuses would like to consolidate data from a student perspective—enrollment,
transcript, and academic advisement—while each campus still maintains independent
control over its financial information.
The consolidation of data across multiple institutions historically has been addressed
either by making modifications to the delivered PeopleSoft system or by using the
delivered transfer credit functionality. Universities with multiple campuses will need to
review their specific requirements to guide the configuration and setup for the academic
structure framework. Some questions to ask include:
Does the institution include coursework from all campuses when calculating and
storing cumulative academic statistics (for example, GPA, total hours, academic
level, and so forth), producing transcripts, and advising students?
In financial aid, does the institution carry a single federal ID or one per campus?
Does the institution share applicant information across campuses?
Does the institution need the ability to view service indicators or holds across all
campuses within the university?
For students who enroll at more than one campus or transfer between
campuses, is there a single bill by campus or an integrated bill/account
The benefits of a one-institution configuration can be helpful in areas where a
streamlined or standardized approach can be administered. The benefit of multiple
institutions gives the campuses more flexibility in the way they can configure their
services. This is all part of the academic structure framework, and once it is in place and
modules are put into production, it is extremely difficult to change. This structure in the
software drives major business processes within the student application. Considerable
time was allocated to research, prototype, and make decisions concerning this structure
Use of a Common Portal
It appears that portals are becoming more popular for delivery of Web services in higher
education. IU developed and implemented a portal called OneStart, which is now the
entrance for all new applications. All students registering for fall 2004 classes at IU did
so using PeopleSoft self-service screens accessed through OneStart. In fact, many
students think of OneStart as synonymous with the new SIS. OneStart, in fact, is the
portal for many applications, including the HRMS, the electronic research administration
system, the library information system, Oncourse (the course management system), and
others. In addition, like most portals, OneStart can be personalized by each user to
access any service available over the Web. Multicampus institutions should adopt a
standard approach on whether to use a common portal as the initial entry point for all
Another complicating factor for large implementations involves staying current on
patches, updates, and fixes throughout the implementation cycle. ERP vendors provide
changes to the application and the application infrastructure on a regular basis. Major
releases or upgrades often represent moving to a new tools infrastructure (for example,
client server to Internet architecture) and require a significant effort to perform the
upgrade. Minor releases may include application changes, bug fixes, and regulatory
changes (for example, financial aid and tax updates). Upgrades to the infrastructure or
tools layer affects application components such as Web and application servers, and
typically requires a longer period when the system is not available to the end users.
Release and Database Management
It is difficult to manage the many databases required to support all of the functional and
technical prototyping, configuration, design, development, conversion, and testing
activities for multiple campuses. The numbers of databases needed during the project
implementation vary by institution; however, the phased implementation approach
generally requires a greater number because there are simultaneous activities under
way for each phase of the project. Careful planning and communication is critical in
order to keep current with vendor updates. Stakeholders need to participate in setting
the budgets and timeline for major upgrades. Databases must be kept current on
patches, updates, and fixes throughout the implementation.
Not all functionality is provided in core enterprise-wide software, so institutions may
need to be prepared to install and support products for address verification, admissions
application processing, the Student and Employee Visitor Information System (SEVIS),
room management, document imaging, disbursement management (check writing and
bank interfaces), tax management, and reporting. Each product is typically developed
using a different set of tools and languages on different platforms. Campuses may have
differing requests for how these third-party products are configured.
ERP implementations affect almost all populations on all campuses, from students to
faculty to employees. Campuses often use different business processes for their legacy
systems. The legacy systems were probably not as strict as the new ERP systems. For
example, compliance of financial aid might have been done in a more manual way, not
automatically as is done with an ERP system. The natural resistance to change might be
apparent initially, but as people become more comfortable with the new functionality and
processes, this should lessen. There is no way that one ERP product can work well at all
campuses without significant business process change, and this will be more apparent
in some modules than others. For example, a move of two campuses at IU from a
financial aid direct lending use to a Federal Family Education Loan Programs (FFELP)
model was a large change, one which established a standard way of delivering financial
aid across the campuses.
Susan Van Voorhis of the University of Minnesota noted, “In a multicampus institution,
decisions must be made about transcripts and whether there will be a standard
transcript for all campuses. This means consensus on how coursework will appear and
how headings and formatting are done. Policies on transfer work and resident credit
must be agreed upon by all campuses in order to make this work. Institutional statistics
will need to be defined for multicampus students; who ‘owns’ the student.”
Collaboration is essential in trying to accomplish a large systems implementation for
multiple campuses. This is especially true when using a shared database environment.
Campus personnel must have a good understanding of how the new system works and
how it differs from the processes employed in the system being retired. In some cases,
policies should be changed to accommodate new business processes, and not vice
There is risk in changing multiple processes at one time, and this must be recognized by
all parties. Registration policies differ at each campus and may include different fee
structures for credit hours taken. Policies for drop/add and wait-list can differ.
Registration dates, financial aid schedules, billing due dates, and grading policies may
differ. Unique challenges are presented for those students who enroll at more than one
campus concurrently or at a campus other than their home campus for a time. At some
point, there is no turning back, and campuses must have (hopefully standard)
contingency plans in place in case problems arise.
Ideally, consistent academic policies and business process redesign across
departments, schools, and campuses prior to implementation can be accomplished, but
the benefits need to be clearly defined. Streamlining business processes when possible
makes it easier to implement, maintain, and provide ongoing support for the
multicampus system from both a technical and a functional perspective. Students who
encounter the same business processes from one campus to another will have fewer
problems adapting to the new software as well.
Most institutions begin with the objective that the software will be implemented “vanilla,”
with no or minimal customizations. Customized software is harder to upgrade, especially
when vendors provide frequent updates, patches, and “fixes.”
Multicampus institutions are vulnerable to requests from each individual campus to
make changes to the delivered software. Rules must be established to resolve gaps
between institutional/campus requirements and software functionality, working through
options in a sequential fashion, with software customizations being the last resort.
Following are IU’s rules of engagement for gap resolution:
Implement alternate system feature (workaround)
Change business process
Change academic policy
Change organizational structure
Develop customized application or program
Modify or customize software
When customizations are required, they can be prioritized by the executive committees,
and a fund should be allocated to accommodate the highest priorities. Indeed, West and
Daigle4 cited controlling software modifications as a significant factor in reducing the
total cost of ownership of ERP systems.
During any large-scale implementation, internal auditors should always be involved with
the project. They can advise on problem areas that can be corrected during
implementation. Auditors pay attention to financial and security areas mainly, but are
also helpful in pointing out poorly designed business practices. Including auditors in
project design review meetings will help alleviate the impact on key project resources
when audits take place during the implementation time frame.
Reporting in a multi-institution environment presents some difficult challenges but also
some excellent opportunities to support the growing demand for better information. The
types of queries and reports needed vary by campuses—some reports and data groups
can be made available centrally and others can be written as queries and ad hoc reports
by the campuses themselves.
A reporting environment is a vital part of any large enterprise implementation. In
institutions with many campuses that have their own requirements for reporting, a
strategy is needed for those reports that will be provided centrally and those that must
be done by the individual campus. All institutions should deliver reporting as part of the
initial rollout. For large multi-institution implementations, the need for end users to
acquire new tools for reporting and data extraction, to be trained on the new ERP
concepts and terminology, and to learn to navigate the large number of new reports and
queries can be a daunting endeavor.
Using a central pool of resources to develop the data structures and report objects that
will be used by all campuses for reporting will generate consistency in the interpretation
of data and facilitate the ability to roll up the data to a single summary view for
hierarchical reporting. Once campus training is complete, report writers on each campus
can address local needs.
What It Means to Higher Education
ERP systems by their nature give an integrated view of the systems and underlying
data. Users can access integrated data for reporting and queries and no longer need to
paste together data from disparate sources. At multicampus institutions, benefits of
system-wide implementations offer opportunities for sharing and collaborating to serve
the overall good of the institution. The campuses are thereby exposed to the different
means of doing business at their sister campuses. While the system may be forcing the
campuses to come to agreement on changes in business processes, it does so by
uncovering the best of the business processes throughout the institution.
Although some of problems described here are unique to multicampus institutions, much
of the content is applicable to any enterprise-wide implementation, especially for
institutions with diverse populations and distributed governance. Many lessons learned
from large system-wide implementations are equally valuable to single campus
Campuses need to consider organizational structures and business process
reengineering early in the implementation cycle.
Executive leadership was excellent at Indiana University, the University of
Minnesota, and California State University, and it promises to be so at Purdue
University. This is key to success. Executives from each campus must meet
regularly to review project progress and resolve issues as appropriate.
Training and adequate time to learn complexities of the software is critical for
staff. Problems with implementation often result from lack of adequate training.
Communication is a key component with a large, diverse constituency. It is
critical to keep all stakeholders informed.
Especially with a project being implemented at multiple campuses, a detailed,
realistic, and well-maintained project plan is critical to the success of the
implementation. In addition, an effective project plan can manage scope creep.
With excellent project management, large-scale projects focus on accomplishing
tasks and meeting milestones. As a result, confidence in the project increases.
In both single- and multicampus implementations, success is directly attributable
to teams of dedicated, enthusiastic people who are focused on implementing
Key Questions to Ask
How can higher education institutions achieve significant organizational and
business process change in preparation for a major enterprise-wide system
How can multiple campuses better coordinate business process changes?
Who should be the one person with ultimate responsibility for a major enterprise
implementation—faculty, administrator, IT leader?
How can multiple campuses with differing populations and needs agree on
How can institutions plan for sufficient staff expertise to address all new systems
How can institutions measure success after implementation? What
postimplementation improvements can be made?
Should faculty policy and deep-rooted procedures be accommodated?
Where to Learn More
R. B. Kvavik and R. N. Katz and associates, The Promise and Performance of
Enterprise Systems (Boulder, Colo.: EDUCAUSE Center for Applied Research,
Research Study, Vol. 4, 2002),
R. B. Kvavik, “Requirements for an ROI on ERP and Portal Implementations,”
presentation at CUMREC 2002,
R. Solis, “A Multicampus ERP Implementation Case Study: What Worked and
What Didn’t,” presentation at NERCOMP 2003,
P. King, R. B. Kvavik, and J. Voloudakis, “Enterprise Research Planning in
Higher Education” (Boulder, Colo.: EDUCAUSE Center for Applied Research,
Research Bulletin, Issue 22, 2002),
J. W. Noyes, “The ERP Dilemma: ‘Plain Vanilla’ Versus Customer Satisfaction,”
EDUCAUSE Quarterly, Vol. 26, No. 2, 2003, pp. 54–55,
E. Lightfoot and G. Salaway, “A Different Kind of ERP: Extending and Renewing
Legacy Systems” (Boulder, Colo.: EDUCAUSE Center for Applied Research,
Research Bulletin, No. 5, 2003),
H. J. Baker, D. J. Ernst, and J. Rickard, “Common Management Systems in the
CSU: An ERP to Remember!” presentation at CUMREC 2001,
H. J. Baker and D. J. Ernst, “California Dreamin’: How Planning, People, and
Persistence Make Them Real,” presentation at EDUCAUSE 2002,
D. Voss, “Web Reporting: Closing the Gap Between ERP and the Data,”
presentation at CUMREC 2003,
1. Committee on Institutional Cooperation (CIC) members include the University of Chicago, University of
Illinois, Indiana University, University of Iowa, University of Michigan, Michigan State University,
University of Minnesota, Northwestern University, The Ohio State University, Pennsylvania State
University, Purdue University, and University of Wisconsin–Madison.
2. Indiana University, Information Technology Strategic Plan: Architecture for the 21st Century, May 1998,
3. Indiana University systems included in the reengineering initiative are the Oncourse course management
system, library information system, electronic research administration system, facilities system, human
resource management system, student information system, procurement system, travel system, time
management system, OneStart portal, financial information system enhancements, and data warehouse,
along with a new UNIX environment infrastructure.
4. R. West and S. L. Daigle, “Total Cost of Ownership: A Strategic Tool for ERP Planning and
Implementation” (Boulder, Colo.; EDUCAUSE Center for Applied Research, Research Bulletin, Issue 1,
About the Authors
Norma Brenner Holland (email@example.com) is the Associate Vice President for
University Information Systems and Laurie Sullivan (firstname.lastname@example.org) is Director of
University Information Systems at Indiana University.
Copyright 2005 EDUCAUSE and Norma Brenner Holland and Laurie Sullivan. All rights reserved. This ECAR
research bulletin is proprietary and intended for use only by subscribers. Reproduction, or distribution of ECAR
research bulletins to those not formally affiliated with the subscribing organization, is strictly prohibited unless
prior permission is granted by EDUCAUSE and the author.