Bucking the Trend: Developing a Centralized, On-Line Student Information System in a Heterogeneous Multi-Campus Environment |-------------------------------------| | Paper presented at CAUSE92 | | December 1-4, 1992, Dallas, Texas | |-------------------------------------| BUCKING THE TREND: DEVELOPING A CENTRALIZED, ON-LINE STUDENT INFORMATION SYSTEM IN A HETEROGENEOUS MULTI-CAMPUS ENVIRONMENT Nicholas C. Laudato Charles A. Heins Dennis J. DeSantis University of Pittsburgh Pittsburgh, Pennsylvania 15260 ABSTRACT The University of Pittsburgh has developed and implemented a comprehensive, centralized, on-line student information system. The system replaces formerly autonomous systems at the University's five campuses and nineteen schools, and interfaces with local systems designed to meet unique user needs. This paper reviews the development and implementation of the system, with particular emphasis on the special circumstances faced in delivering centralized administrative services at the University's regional campuses. It focuses on the ingredients contributing to the success of the system, including attaining senior management support, involving users, reviewing and revising policies and procedures, establishing an applications development model, setting development priorities, establishing human and data communications networks, creating software training and testing environments, and delivering production services. ------------------------------------------------------------------------ BACKGROUND The University of Pittsburgh is an independent, nonsectarian, coeducational, public research university. It is a state-related member of the Commonwealth of Pennsylvania System of Higher Education. Located in Oakland, Pittsburgh's cultural and medical center, the main campus is within an hour's commute for 2.3 million people in the metropolitan Pittsburgh area. Its 132 acres include more than 90 academic, research, supportive, and dormitory buildings. One of these, the 42-story Cathedral of Learning, is among the tallest academic buildings in the world. The University of Pittsburgh, founded in 1787, has grown to become the comprehensive educational complex in the tri-state area bordering Western Pennsylvania. It attracts national and international programs and students. In addition to the main campus in Pittsburgh, the University operates four regional campuses. The Johnstown, Greensburg, and Bradford campuses offer four-year baccalaureate programs, and the Titusville campus offers lower-division programs and two-year degrees. Among its five campuses, the University offers over 390 degree programs, and for fiscal year 1992, conferred 6,728 undergraduate, graduate, and professional degrees. The following table shows enrollment for Fall Term, 1991, at each of the campuses. Campus Distance Faculty/Staff Enrollment Percentage (from (full- and (headcount) (of heaadcount) Pittsburgh) part-time) Bradford 170 miles 173 1,241 4% Greensburg 35 miles 150 1,454 4% Johnstown 80 miles 377 3,243 9% Pittsburgh 10,228 27,973 82% Titusville 125 miles 75 425 1% Total 11,003 34,336 Statistics are based on the 1992 University Fact Book STUDENT SYSTEMS BEFORE THE PROJECT The University has recently completed a project to centralize formerly autonomous student information systems at all five campuses. The project began in earnest in 1986, with phased implementation occurring from 1989 through 1991. The development process required close cooperation and coordination among senior administration, mid-level management, faculty and staff, and a significant commitment of time and financial resources. The project had a far reaching impact on the formation of policies and procedures throughout the University and dramatically improved the quality of student services. Because different local student information systems had evolved at each of the University's five campuses, coordination between these systems was extremely difficult and very limited. Administrators who needed to analyze information across the entire University were forced to rely on printed summary reports generated from these local systems, which often did not contain comparable data elements. It was impossible to reconcile the summary information with the detailed source data. The five campuses operated their own student systems at varying levels of automation and sophistication. The Pittsburgh Campus system was the most complex, serving professional, graduate and undergraduate programs offered by 15 schools. This system was implemented on different platforms at centralized, school, and departmental levels. The centralized component, supported by Computing and Information Services (CIS), had been implemented on two antiquated platforms, a DEC-10 and IBM OS/MFT system. These batch systems provided centralized student billing for the entire Pittsburgh campus, but some academic units had their own local recruitment, admissions, registration, and transcript systems. At the Regional Campuses, administrative computing systems were supported by local, autonomous computer centers. Their systems ranged from home-grown microcomputer-based programs through sophisticated, integrated systems. The Bradford campus had implemented a comprehensive, integrated, on-line system on a local VAX 8350 using Series Z software from Information Associates. The Greensburg campus used a combination of manual systems and software developed using the 1022 data management system on the University's administrative DEC-10. They also used components of CMDS's TEAMS on-line student information system on a local IBM System/34 that they inherited from the Bradford Campus. The Johnstown campus developed a student information system to run on their local Novell network using DataFlex. This system was supplemented by software developed on the DEC-10, and by recruitment and admissions software on a local Macintosh-based network. The Johnstown campus also utilized the state's PHEAA system for packaging and managing financial aid. The Titusville campus relied mostly on a microcomputer- based system developed locally using FoxPro. DEVELOPMENT AND IMPLEMENTATION Detailed planning for the proposed on-line student information system began with the establishment of a planning team charged with recommending a solution to replace the batch systems at the Pittsburgh campus. The planning team was headed by the Vice Chancellor for Planning and Budget, and included administrators from various operating offices at the Pittsburgh and Regional Campuses, as well as Computing and Information Services. The team defined the required functional capabilities of the systems and the general requirements for system reliability, hardware, software, and telecommunications. These requirements were reviewed and approved by staff with operational responsibilities, and were included in a Request for Quotation. After analyzing the costs of developing a student system in-house, and reviewing responses to the RFQ, the University decided to purchase an integrated system and modify it to address the specific needs articulated by the University community. The Integrated Student Information System (ISIS) system was purchased from SCT Corporation, because its basic architecture and breadth of applications most closely approximated the general needs that had been outlined. With the acquisition of ISIS, it was also necessary to acquire new hardware (an IBM plug-compatible mainframe), an operating system (MVS), telecommunications monitor (CICS), database management system (Cincom's SUPRA), and other software to support a production processing environment. These changes also required an extensive recruitment and training effort for both development and user personnel. Because operational processes were quite different at the various campuses and academic units, a project development team, consisting of staff from CIS and users from major administrative areas, was given on- line access to the baseline software and directed to determine what specific changes needed to be made. To ensure that scarce development resources would be used effectively, this activity was deliberate and time consuming. However, because of the tight development schedule and poor condition of existing systems, it had to be completed expeditiously in order for the project to be fully implemented as quickly as possible. While analyzing baseline ISIS functionality, the development team realized that there were few written University-wide policies to guide their operational design decisions. Therefore, a University-wide committee was established, under the direction of the Provost, to address student and course-related policy issues and to specify relevant data definitions. Among the 47 policy issues addressed were policies defining the repeating of courses, standard course meeting times, tuition assessment, grading, and transcript format. An example of the committee's deliberations was the issue of establishing one versus multiple course inventories. Before the ISIS project, Mathematics 101 may have been defined differently by as many as six academic units, creating many serious problems, including the evaluation of transcripts for internal transfers. The ISIS project provided the opportunity to define a new policy creating a single course inventory across the University. Simultaneously, a Data Element Dictionary was developed for all administrative systems at the University. This dictionary housed all data element definitions contained in administrative applications as well as their format, values, and relationships. This activity was a critical prerequisite to the task of building system tables for the application software. After completing estimates of the effort required to program the planned modifications, a development and implementation schedule was detailed and presented to users and the senior administration for final approval. The major modules of the overall system were carefully analyzed and a final phased implementation schedule for all campuses was prepared. There were over 3,000 tasks on the final implementation schedule. In order to manage the development and implementation of these proposed modifications, the Executive Vice Chancellor for Administration appointed a Project Coordinators Group. The group was chaired by the Director of Administrative Information Systems, who was also the overall project director, and included directors of major administrative areas. The group set priorities, evaluated development costs, and recommended alternatives to the Executive Vice Chancellor for Administration. All non-essential changes were identified for post-implementation review. Because of the excessive number of modifications necessary to develop the financial aid component to meet University specifications, the Project Coordinators investigated the possibility of interfacing existing third-party software. After considerable analysis, the coordinators selected the Student Aid Management System (SAMS), from Sigma Systems, Inc., and proceeded with plans to interface and integrate it with ISIS. Other systems that needed to be interfaced with ISIS included the Financial, ID Card, Library Automation, Data Element Dictionary, Alumni Development, and Human Resource Systems. A significant development activity involved the conversion of ISIS and SAMS to the SUPRA database management system, optimizing their performance, and developing dynamic system interfaces between the two. Additional development work was also necessary to convert data from the then-current student systems into ISIS and SAMS. The Project Coordinators planned and closely monitored the conversion and verification of student demographic information, academic transcripts, course information, accounts receivable balances, and student aid history. The conversion of transcript data made it possible to generate a complete transcript on-line for any student actively enrolled at the University. Modules were phased into production beginning with the course inventory module in 1989, and ending with the graduation component of the academic history module in the spring of 1991. In all, 64 new screens were developed in addition to the 105 that were either adopted or adapted from the baseline systems. Each of these screens represents several programs for add, change, delete, and query transactions. Application Vendor Baseline Additional Screens Screens Integrated Student Information System General Utilities SCT Corporation 8 4 Recruitment SCT Corporation N/A 3 Admissions SCT Corporation 7 6 Course Inventory SCT Corporation 3 1 Course Schedule SCT Corporation 5 5 Registration SCT Corporation 7 3 Housing SCT Corporation 1 2 Accounts Receivable SCT Corporation 14 8 Academic History SCT Corporation 13 6 Academic History Conversion Internally Developed N/A 6 Special Applications Internally Developed N/A 7 Student Aid Management System (SAMS) Sigma Systems, Inc. 47 N/A Automated Loan Processing System (ALPS) Internally Developed N/A 6 Degree Audit System (DAS) Internally Developed N/A 7 KEYS TO SUCCESSFUL PROJECT IMPLEMENTATION The successful development and implementation of an on-line student information system in the University's heterogeneous multi-campus environment was a major accomplishment. The key ingredients in achieving this success included the retention of active senior administrative support, the management and control of the development process, the close involvement of users, the efforts at communicating and coordinating project activities, and the expansion of centralized computing services. ---Attain Support of Senior Administration A critical factor in the success of the project was the continued active involvement by the senior administration. There would inevitably be times when it would be necessary to break a dead lock regarding policy issues, when unanticipated additional funding would be necessary, and when schedule slippage would occur. Decisions regarding such issues would have to come from the senior administration. The Executive Vice Chancellor for Administration met with the Project Coordinators on a biweekly basis to review the status of the project and make timely decisions on all important issues. A second area of administrative support involved the identification and resolution of policy issues that needed to be addressed in order to implement the software. Because student systems at each campus and some academic units operated autonomously, varied policies and practices had evolved before ISIS. In order to control the costs associated with modifying the software to accommodate these diverse policies, as well as to establish consistent services across the University, the Provost appointed an Academic Policy Committee composed of deans and administrators. This committee identified and resolved policy issues that laid the groundwork for the successful implementation of ISIS. The third area of administrative support focused on the one-time costs incurred in developing and implementing the project. This support encompassed all components of project implementation, including the extension of the University network to administrative offices, the purchase and support of terminals and local printers, funding to develop training materials and conduct training sessions, and funding to hire temporary staff for data conversion activities. In addition to providing the needed resources, this centralized support clearly demonstrated to the institution that the senior administration was committed to the successful implementation of the project. --Manage and Control the Development Process An important factor in the management of the project was the creation of the Project Coordinator group. Chaired by the Director of Administrative Information Systems, the group consisted of directors of major administrative areas who met on a weekly basis to resolve functional, technical, and political issues. They closely monitored development progress, analyzed and adjusted development plans and resources, approved functional specifications, and approved new and revised forms and procedures. A second factor in the successful management of the project was the set of procedures put into place to control the development and implementation process. Standards had to be developed and followed in order to ensure that the project deliverables were properly prepared and could be maintained and supported after cutover. These included standards for programming and JCL, user-approved documentation, a methodology for maintaining current documentation, and standards for estimating software changes and monitoring those estimates. As the first major project of its kind at the University, a systems development methodology was created to meet the needs of both CIS and the users. This methodology, outlined below, was subsequently adopted as the standard for CIS. --Information Flow Diagrams: Similar to work flow diagrams, these diagrams depict how the system should work operationally. Once approved by the Project Coordinator group, they serve as a "road map" for the development of functional specifications. --Functional Specifications: Developed by module, (i.e., recruitment and admissions, registration, etc.) these specifications include screen layouts, descriptions of screen processing and functionality, report layouts, error message checking, data element definitions, and general assumptions relative to module functionality. Each specification serves as a basis of understanding between the users and CIS, and is reviewed by users and formally approved by the Project Coordinators. --Program Specifications: Based upon approved functional specifications, program specifications includes all items necessary to fully describe the program requirements. These specifications normally are reviewed with the user, via a program "walk-through," before proceeding with coding. --Unit and Module Testing: After coding is completed, new software is installed in a special environment dedicated exclusively to acceptance testing. Users then test each set of software, focusing on test case performance, module test performance, error message logic, and stress and destructive testing. The intent is to minimize production surprises, and to measure coding against pre- defined functional specifications. --Formal Approval: The final step in the systems development methodology involves obtaining formal user approval of the software as a prerequisite to implementation. In support of this methodology, it was critical that separate application environments be maintained for separate functions. These were implemented on the mainframe in separate CICS regions, each containing a separate database and different versions of the software. In the initial months of the project, an environment containing the baseline (non-modified) version of the software enabled users to familiarize themselves with the basic functionality of the system. A separate development environment was created to allow CIS to code and unit test new and revised software. An acceptance testing environment was created where users could experiment with newly created software and closely monitor its performance and accuracy before it was implemented. A training environment was created to enable CIS to train and prepare the University community for initial implementation. Finally, the production environment contained fully tested software and real data. A final factor in controlling the development process was the concept of "change control." The change control process was a procedure initiated to address suggested changes to the functionality of the software after the functional specification had been approved and programming had begun. The Project Coordinators reviewed all change control documents and approved them only after fully evaluating their impact on the project budget and schedule. This process was critical in a situation where resources were limited and there was no room for slippage in a tight development schedule. --Involve Users One of the primary underlying philosophies of the project implementation effort was to ensure that users be involved from the very beginning of the project through implementation. In addition to functional knowledge, users within the University community possessed a wide range of technical talent. This project capitalized on this situation by assigning technically oriented users to the development team. Such involvement captured the users' operational expertise and understanding of system requirements, thereby dramatically increasing the probability of success. This philosophy became the cornerstone for a team approach to project development, entailing direct user involvement and final responsibility for overall review and approvals. Users were significantly involved with Computing and Information Services in all aspects of project management. They helped to evaluate and select software, to analyze and recommend policy revisions, and to recommend implementation schedules and priorities. Most importantly, they co-authored the functional specifications that defined what the system would do. Another significant area of user involvement was in the design, development, and execution of software testing plans. After CIS developed program specifications, users participated in walk- throughs to ensure that the system would be developed as intended. Users also tested, evaluated and approved all new and revised software, before it migrated into the production environment. Of particular importance was the use of "destructive testing" strategies, whereby the users intentionally tried to crash the software and corrupt the database. User involvement played a critical part in the success of the project. It built a sense of ownership among users, fostered an overall positive team attitude, developed mutual trust and confidence, and encouraged a high level of commitment. The development methodology required significant user involvement and was highly instrumental in helping to strengthen these intangibles. --Communicate and Coordinate Two important keys to the successful implementation of ISIS were the efforts at project coordination and the establishment of an open, varied, and effective system of communication. To help coordinate project activities between the Project Coordinators and the users, the role of Master User was defined. The Master User served as liaison between a specific area of responsibility and the ISIS project management. The Master Users were selected from user offices and charged with the responsibility to disseminate information to users in their areas, to coordinate requests for user access to the production system, to administer screen access (transaction security) within their functional areas, and to request system table updates. At the Regional Campuses, the role of Master User took on even greater importance. At each campus, this role was assigned to the person who was responsible for local administrative computing, typically the local computer center director. These Regional Campus Master Users were charged with implementing all components of ISIS at their individual campuses. In addition to the standard duties of Master User, they coordinated equipment installation, set up training sessions, managed printers and printer queues for their campus, and fielded local production problem calls, interfacing with CIS regarding their solution. One of their most important responsibilities was to review functional specifications with users on their campuses, to suggest modifications and to approve the specifications. These activities were supported by a newly created position within CIS that was dedicated to coordinating all Regional Campus activities. As the project progressed, communication and coordination between the campuses became more and more important. The Regional Campus Master Users held regular face-to-face meetings at the Pittsburgh campus, and were often represented at the weekly project coordination meetings. To facilitate communication between the campuses, the Associate Provost hosted several meetings dealing with policy and priority issues. Also, comparable functional units (such as all Registrars) from each campus met several times annually at one of the campuses to discuss procedural issues and upcoming software modifications. Wherever possible, technology was used to facilitate communication. For example, the Regional Campus Master Users held weekly telephone or video conference calls to participate in planning and problem solving activities with CIS managers and analysts. All members of the project team used electronic and voice mail on a regular basis to facilitate communication. Electronic mail was also used to announce software changes and to gather appropriate approvals for moving changes into the production environment. The Regional Campus Master Users also shared information and programs of mutual interest in commonly accessible disk space on the mainframe processors. This space was used to store parameter card documentation, meeting agendas and minutes, problem reports, shared examples of JCL and report writer coding. A final critical aspect of communication was the effort to educate the University community regarding the project. To prepare for implementation, the Project Coordinators conducted orientation sessions and open forums for the general University community. These sessions were aimed at familiarizing faculty and staff with the operational implications of the policy and procedural changes associated with project implementation. Training activities throughout the University were coordinated by a newly created position within CIS. In conjunction with the development team, this trainer developed user documentation and training materials for the on-line screens and batch reports, set up training data in a dedicated training environment, and conducted group training sessions. Users also participated directly by developing quick reference guides to on-line screens. --Expand Centralized Computing Services Special efforts were required to create and support an effective computing environment that would facilitate the success of the project. A critical prerequisite for the centralized system was the creation of a University-wide data communications network. The network infrastructure was created as part of the Campus of the Future Project, a joint venture between the University and several major corporations that addressed the academic, administrative, library automation, video, and telecommunications goals of the campus. Among other things, this project resulted in the cabling of all five campuses with a fiber-optic backbone, along with thinwire and twisted pair station wiring. The Regional Campuses were connected to the network via T1 communications lines. This University-wide network, called PittNet, provided the ability to connect all computing devices, including mainframes, minicomputers, microcomputers, and terminals, at all campuses. As part of the ISIS project, CIS provided a low-cost color microcomputer, terminal emulation software, and a network communication port to each user who required access to the student system. Historically, CIS had not been charged with providing administrative computing services to the Regional Campuses. The development of this centralized student system required CIS to make several significant changes to its internal operating policies and procedures in order to successfully extend its services to remote users. For example, at the Pittsburgh campus, procedures required the submission of a multi-part paper form, along with a parameter card form, to request a batch update or report job. To address the problems inherent with implementing such procedures via the U. S. Mail system, an alternative system was developed for the Regional Campuses. The Regional Campus Master Users submitted e-mail requests to run jobs, updated the batch parameter cards on-line, and could print the job output at their campus the next morning. They also used e-mail to request system table updates, modify batch schedules, set up weekly production runs, request transaction security access, and request ad hoc mailing label jobs. Printing on-site at the regional campuses proved to be one of the most difficult tasks associated with the project. Most ISIS reports were modified to be printed on laser printers using a technique of overlaying an electronic form with data. This provided flexibility in that output could be printed on plain paper, obviating the need to stock expensive forms. Laser forms also allowed for the ability to change form layouts on shorter notice and at substantial cost savings. Forms design software allowed for the generation of forms for both the central high- speed Xerox laser printers that serve the Pittsburgh campus, and for tabletop laser printers located in user offices at all campuses. Although the multi-campus student information system was the first major on-line transaction oriented system installed at the University, the Project Coordinators knew from the beginning that this system would require special planning for support after initial implementation. With over 1,000 users, it would be necessary to have a structured support system in place to respond to trouble calls quickly and to answer all questions regarding proper operation of the system in a professional manner. The project plan included tasks for defining such a support environment, including automated support systems for monitoring problem calls. A trouble line was implemented and staffed by individuals dedicated to taking all initial telephone calls and recording the problem into an automated system. The system then reported all pertinent information to the individual having support responsibility for the problem. That individual then typically called the user office reporting the problem within ten minutes after receipt of the problem, and advised as to a likely time for resolution. Management reports were produced daily to monitor all problems, identifying any continuous problem areas that may need a more in-depth analysis. This problem reporting and monitoring system, although rather simple in structure, was an essential component of a central on-line system. RETROSPECTIVE AND VISION FOR THE FUTURE The development and implementation of this comprehensive multi-campus system was a major success. The project involved a complete transition of technology, an infusion of new technical employees, and a very stringent implementation plan. These factors, combined with the uncertainties of a first-of-its-kind development effort at the University, suggested that major difficulties would be inevitable. As these difficulties were encountered, the project received the necessary senior level support and user commitment to resolve them in a timely fashion. In addition, CIS development personnel played a very important role in ensuring system reliability, performance, and integration. In the final analysis, it became evident that the human aspects of a project of this magnitude are equally or more important than the technical aspects. The success of the project can be attributed to several key factors. The senior administration provided on-going financial and political support, and active project oversight. The Project Coordinator group played a leading role in the successful development and implementation of the project by keeping activities focused and adjusting to events in a timely fashion. This role continues, in the post-implementation environment, with the oversight of on-going support services and the evaluation of proposed enhancements and modifications. The approach to project development placed a good deal of emphasis on the team concept with full participation and responsibilities from user offices. This involvement built a sense of ownership among users, and fostered an overall positive team attitude, developed mutual trust and confidence, and encouraged a high level of commitment. A varied and effective communication system kept users current with development activities, and kept CIS responsive to user needs. The establishment of strong project coordination for the Regional Campuses (a mid project change) also turned out to be an extremely important and accurate decision in efforts to implement the system at all campuses at the same time. The project development methodology required significant user involvement and was highly instrumental in ensuring the quality of the software and its responsiveness to user needs. The strategy of selective phased implementation was also important because it provided for demonstrated success and the opportunity to learn as the development team proceeded toward the implementation of critical and high visibility modules such as student aid, student receivables and the dynamic integration of these two modules. Also, the expansion of centralized support services provided assurance that the system would be appropriately supported. A trouble line and method of responding to system operational issues was extremely helpful, as was the decision to dedicate personnel to the on-going support of the system in both CIS and the user offices. Where Do We Go From Here? One important capability that has not yet been implemented is the establishment of an effective ad hoc management reporting environment. Many of these needs are currently satisfied through downloading data to local computing environments and can be satisfied more efficiently through a more powerful information reporting tool with a more sophisticated data base environment. One of the "down-sides" of this major project effort was the inability to simultaneously address similar needs in other administrative areas, particularly Financial and Human Resources systems. However, the lessons learned, and the successes of this project have significantly strengthened confidence in centralized systems and the ability to deal with a number of major projects that are perched on the horizon. While we have begun to develop a strategy addressing client/server applications for ad hoc query and reporting support, we are convinced that the centralized transaction processing model, coupled with a system of distributed support services, is most efficient for high volume transaction systems.