Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise-Wide System Implementations at Multicampus ...


Published on

  • Be the first to comment

  • Be the first to like this

Enterprise-Wide System Implementations at Multicampus ...

  1. 1. EDUCAUSE Center for Applied Research Research Bulletin Volume 2005, Issue 4 February 15, 2005 Enterprise-Wide System Implementations at Multicampus Institutions Norma Brenner Holland, Indiana University Laurie Sullivan, Indiana University 4772 Walnut Street, Suite 206 Boulder, Colorado 80301-2538
  2. 2. Overview 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 Implementations 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 multicampus environment. 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 2
  3. 3. 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 3
  4. 4. 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 common system. “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 organization. 4
  5. 5. Organizational Considerations 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 practices. 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 application development. 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 5
  6. 6. 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. Governance 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 needs. Decision Making 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. Communication 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.” 6
  7. 7. Implementation Strategies 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 the SIS. 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 7
  8. 8. 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 summary? 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 at IU. 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 enterprise-wide services. Technology Challenges 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 8
  9. 9. 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. Third-Party Vendors 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. Business Reengineering 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.” 9
  10. 10. 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 versa. 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. Customizations 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 10
  11. 11. Daigle4 cited controlling software modifications as a significant factor in reducing the total cost of ownership of ERP systems. Auditing 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 Environment 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 11
  12. 12. institutions with diverse populations and distributed governance. Many lessons learned from large system-wide implementations are equally valuable to single campus implementations: 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 new functions. Key Questions to Ask How can higher education institutions achieve significant organizational and business process change in preparation for a major enterprise-wide system implementation? 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 minimizing customizations? How can institutions plan for sufficient staff expertise to address all new systems and processes? How can institutions measure success after implementation? What postimplementation improvements can be made? Should faculty policy and deep-rooted procedures be accommodated? 12
  13. 13. 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, <>. Endnotes 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. 13
  14. 14. 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, 2004), <>. About the Authors Norma Brenner Holland ( is the Associate Vice President for University Information Systems and Laurie Sullivan ( 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. 14