VALPARAISO UNIVERSITY

APPROACH DOCUMENT

I. BACKGROUND

The current University information system has evolved over many decades at the direction of many individuals. It is currently a combination of CMDS modules and modules written in-house. The result is a fragmented information system which may serve many of the needs of the University, but which is difficult to modify to accommodate new needs. The present information system contains modules which have software errors in them, creating unnecessary difficulties and frustrations. In addition, the present system was developed prior to the massive introduction of PCs into the administrative areas. These workstations offer opportunities for information processing which were impossible a few years ago. The present information system was not designed to take advantage of these capabilities.

In September 1995 President Alan Harre appointed the Administrative Information Processing Task Force to reexamine the information needs of the University and develop a plan for better meeting these needs for the next ten years. The Task Force membership included broad representation from the Business Office, Institutional Advancement, Admissions, Student Affairs, Financial Aid, School of Law, Graduate Office, Human Resources, Registrar's Office and Electronic Information Services (EIS).

The charge to the Task Force included the following:

  1. To define the strengths of the current information system;
  2. To define the needs not being met by the current information system for all functions of the University dependent on information;
  3. To define the objectives of the new information system;
  4. To evaluate alternatives for meeting the objectives of the new information system;
  5. To develop RFP specifications for vendor solutions;
  6. To receive and evaluate vendor proposals;
  7. To make recommendations to the President.

The work of the Task Force was completed in August 1997 with the selection of Datatel as its vendor and the signing of a contract with Datatel. VU decided to implement the Datatel system, known as Colleague (Benefactor is the name of the Institutional Advancement module), as an integrated vendor solution for replacing the current administrative systems at the University. An integrated solution will ensure that data is properly recorded, not duplicated, and easily understood throughout the user community. While implementing a new system, the University will review current business practices and policies to ensure that all practicable efficiencies are achieved. The new systems will replace the following systems at VU: admissions, financial aid, registration, student accounts, housing, alumni/development, finance and human resources/payroll.

II. PROJECT GOALS

VU Mission Statement

The following Mission Statement guides the University's 1993-1999 Strategic Plan:

Valparaiso University, a private institution of higher learning distinguished by its Lutheran heritage of scholarship, freedom, and faith, provides strong programs of liberal and professional studies well-grounded in the arts and sciences by a faculty dedicated to challenging teaching and care for the individual in a residential setting where its students can develop as whole persons, motivated and prepared to serve both church and society.

VU Strategic Planning Goals/Directional Themes

During the 1990s, three supporting emphases will make extensive contributions to enable the University to realize its most significant aspirations. Valparaiso University will:

Datatel Project Mission

The Datatel project mission is to provide a complete, effective, integrated, easily-accessed, easily-used administrative information system to Valparaiso University by July 1, 1999.

Project Goals

The goals of the Colleague/Benefactor implementation project include:

  1. Improve services to external and internal customers;
  2. Increase faculty, administration, staff access to reliable, consistent, and timely data;
  3. Provide students direct access to appropriate information;
  4. Provide access to timely and comprehensive management information for use in the decision-making process;
  5. Review all processes affected by the Datatel project and improve them as appropriate.

Measurement Of Success

VU will succeed when...

VU will achieve this through...

We will measure the success of this project in three different stages:

III. IMPLEMENTATION APPROACH

Time Line Targets

The following schedule for live implementation of the systems has been established:

Stewardship (Ownership)

Offices will assume primary responsibility for the content of and access to data elements as decided in the implementation process.

Offices will take ownership of their application software. Thus, users of the system, not EIS, will be primarily responsible for establishing codes and setting parameters, activities that determine how the system will function; and for security, backup, and disaster recovery planning for their own workstations. EIS will assist users with these tasks. Its primary responsibilities, however, will be:

  1. To work with users and Datatel to resolve application software problems and satisfy unmet application software needs;
  2. To be a resource to users regarding global issues such as understanding the application software user interface, use of the query language and the integration of modules and systems;
  3. To ensure that the system software is configured and functioning effectively;
  4. To ensure that all hardware is adequately scaled and running efficiently;
  5. To provide security, backup, and disaster recovery planning for servers, central software, and primary data;
  6. To be the focal point for training on the common portions of the system.

Role Descriptions, Responsibilities, And Membership

Steering Committee

The Steering Committee will guide the project. The Steering Committee is composed of the former members of the Administrative Information Processing Task Force, now appointed as a continuing committee known as the Administrative Computing Team (ACT).

Executive Committee

The Executive Committee will function to assign/empower those charged with implementation; reinforce the priority of the implementation project; ensure that necessary resources and support are provided to

teams/offices/departments; resolve problems/conflicts presented by the project leader/team leaders, if unable to resolve at the team or steering committee level; receive periodic updates of project progress; communicate policy, where appropriate; communicate implementation project progress, where appropriate; promote project achievements and results; schedule and enjoy success celebrations. The Executive Committee is composed of the following people:

Project Manager

Mike Yohe, Executive Director of Electronic Information Services

The project manager leads the implementation effort and is responsible for ensuring that the project progresses according to the implementation plan. The project manager works closely with Datatel employees, the president, the steering committee, the implementation teams, and the EIS team to prioritize and schedule tasks, to anticipate and mitigate conflicts, and to ensure timely progress toward full implementation.

EIS Project Manager

Bill Doshan, Associate Director of Management Information Systems, EIS

The EIS project manager is responsible for data conversion, hardware, and technical issues.

Steering Committee Chair

Ann Trost, University Registrar

The Steering Committee chair is responsible for communication between teams and to VU staff and for facilitation of the steering committee (ACT).

Team Leaders

The team leaders serve as the team facilitator and as a liaison to and member of the Core Module Implementation Team. Each team leader will seek out expertise as identified by the team.

Team Responsibilities

Teams are responsible for interfacing and converting their area of responsibility to the new system.

Each team is empowered to make decisions that affect their area of responsibility without prior approval of the steering committee. Decisions that affect more than one team must be made with the involvement of all affected teams. Decisions that affect more than one system must be made with the involvement of all affected Systems Teams. Any exception that impacts University policy or would extend the project time line must be reviewed by the steering committee.

Each team is empowered to resolve its own conflicts subject to the communication protocol described below. Conflicts that cannot be readily resolved must be addressed by the Steering Committee members.

Teams are responsible for developing and entering the codes associated with their modules.

The initial team memberships consist of the following members of the ACT and are to be supplemented as the team sees fit. Team leaders will be chosen by the teams.

Core Module Implementation Team

Finance Module Implementation Team

Susan Scroggins, Leader

(General Ledger, Purchasing, Accounts Payable, Physical Plant, Inventory, Budget Management, Fixed Assets)

Benefactor (OIA) Module Implementation Team

John Bowker, Leader

(Individuals and Organizations, Campaign Management, Gift and Pledge Processing, Major Prospects, Correspondence Control, Activities and Events)

Human Resources/Payroll Module Implementation Team

Stephanie Coyle, Leader

(Personnel, Payroll, Position Control)

Student Systems Module Implementation Team

David Fevig, Leader

(Admissions, Financial Aid, Records and Registration, Accounts Receivable, Cash Receipts, Faculty Information, Curriculum Management, Campus organizations, Degree Audit, Residential Life, Activities & Events, Correspondence Management)

The EIS Role

EIS is in a support role and not one of ownership of the application software. The following list is representative of areas that EIS will play a central role in providing technical leadership:

EIS Implementation Team

Centralized vs. Decentralized

An integrated system combines the best of both centralized and decentralized approaches. A single, centralized database is the key to an integrated set of systems. This centralized database will provide one location for information as well as processing rules which specify the way VU defines and uses data. Data will be entered only once, from a number of decentralized origins (e.g., Admissions, Financial Aid, Registrar), and thereafter will be shared with many users across campus. All authorized users will have access to the same information and reporting tools, thereby eliminating duplication, confusion, and frustration.

Offices responsible for data input in the current systems (e.g., Admissions, Financial Aid, Registrar) will continue to have ownership under the new system, and some additional units may also assume data "ownership" rights and responsibilities. For all of these units, the single most important owner responsibility is and will be quality control. Shared access and use of central information resources requires reliance on the accuracy and integrity of data in the system database.

The use of Colleague/Benefactor and related systems will be the only official repository for all data collected and stored relating to the administrative business of the University.

Conversion

Conversion is the process of changing from the old administrative systems to the Colleague/Benefactor system. The implementation teams must plan the seamless move to new systems without any interruption in existing services. The conversion to Colleague/Benefactor will be complex and includes a number of factors. Each module team is charged with the responsibility to:

  1. Decide what data is to be converted to Colleague/Benefactor and on what schedule.
  2. Consider the key dates in the University's calendar. The calendar is complex and the affected departments have different key dates (e.g., fiscal year boundaries, registration dates, etc.).
  3. Identify all data sources. The present systems have been in place for a long time. This means that there are multiple data sources to be converted, i.e., current data and historical data. Further, coding schemes and conventions for data have changed over time requiring more verification, clean-up and conversion. Data analysis needs to be performed to test the accuracy of the data.
  4. Determine which data elements should be retained and establish a long-term data retention policy to guide conversion efforts.
  5. Plan for technical testing and for user testing including assessment and acceptance.
  6. Develop contingency plans for storing existing data in case problems are discovered later in the conversion.

In addition, the following factors will also be considered:

  1. The implementation of each Colleague/Benefactor module will be staggered. Interim system interfaces will have to be devised and maintained by the EIS staff and Datatel consultants, so that current systems can exchange information with Colleague/Benefactor as they are implemented.
  2. Because the conversion includes movement from multiple systems into one system, there will be instances where decisions will have to be made about precedence. For example, a student's name and address may appear in the Student Record, Development, and Admissions data base and any of these may be the most current or accurate. A plan to automate the precedence decision or to make the decision manually will be created. The Core Module Team is responsible for resolving issues of precedence.

Training

The successful implementation of Colleague/Benefactor is defined by its acceptance and effective use by the University's staff and faculty. Included in this definition is the requirement that the system be implemented on time and in a manner that achieves greater efficiencies of operation and higher service levels for the campus community.

Training is essential to achieving these goals and fulfilling the project's goals. Accordingly, training will take several forms, each appropriate to the tasks to be performed.

The Colleague/Benefactor system is an essential tool provided to the University's staff and faculty to allow the effective, efficient, and accurate performance of important duties and responsibilities. Even though the use of this software and the training for its use are not specified in position descriptions, attendance at, and active participation in training, is a requirement of all who are to use the systems and are assigned to training. The level of active participation in training will be evaluated by the department head.

Security

All users will be able to view the data that is required by the user's job functions. Clearance to modify the data will be restricted according to the definitions of data ownership. All users of Colleague/Benefactor, including student employees, will be required to sign a University confidentiality statement. Ideally, this would be part of an employees' orientation.

All information about students, current and former, maintained by Valparaiso University is governed by the Family Educational Rights and Privacy Acts (FERPA) of 1974. FERPA requires that VU have the student's written permission to release any information from their records except certain types of "directory information."

Faculty and staff personnel records are also protected under law. Human Resources has the responsibility for these records.

IV. COMMUNICATION PLAN

Information Flow

The Executive Committee, Steering Committee, and the implementation teams will document discussions and decisions using a template for minutes (which will be posted on our Web site) to inform everyone involved in the effort about issues and progress.

The Project Manager will keep the President and the President's Council members informed regarding implementation progress and issues. He will inform implementation team members of the Council's concerns that need to be addressed.

The Project Manager will collaborate to publish regular reports and articles concerning the system's features, process improvement decisions, and implementation matters for circulation throughout the university. It will be the responsibility of each member of the VU community to read this information and keep abreast of the implementation process as it progresses.

All formal VU communication with Datatel will go through the Project Manager.

Decision Making Process

Each implementation team has the delegated authority to make the most effective decisions for each area(s) of responsibility without prior approval of the Steering Committee. As members of the team represent cross-functional units, decisions which affect more than one area must be made with the full consultation of the members. By the same token, decisions which affect more than one system must be made with the involvement of affected module teams. In such instances, the chair of the implementation team must communicate the decision points to the chair of the other implementation teams and ensure collaborative decisions.

Conflict Resolution Process

Each team is empowered to resolve its own conflicts. If the implementation teams cannot reach a consensus on certain issues, those issues must be forwarded by the chair of the team to the Steering Committee or to the Core Module Team. In the event that these two groups cannot reach a consensus on those issues, the chair of the Steering Committee will bring the issues to the Executive Committee.

V. GUIDELINES FOR THE PROJECT

Legacy Software Support

To facilitate the implementation of Colleague/Benefactor, there will be a moratorium beginning immediately on discretionary enhancements or modifications to the existing systems. All requests for modifications to these systems must be approved by the Executive Director of EIS and will be contemplated only in the case of serious software errors ("bugs"), normal maintenance, or where necessary to remain compliant with external requirements (e.g., the IRS).

Customizing the Software

The Colleague/Benefactor system will be implemented in its "vanilla" form. Where current practices are not supported by the new system, processes will be reviewed and revised, using the features available in the new system to deliver the same or improved services in an alternate way. As discussed previously in this document, process redesign and improvement will be an important component of this implementation. No custom programming changes will be made to the software without the express written approval of the Executive Committee, and no custom programming changes will be made during the first year of use unless there is no alternative.

Programming changes are defined here as functional changes to the software and do not include defining decision tables, developing new reports, creating new forms, or adding data elements, all of which will be required during the implementation process.

Reporting

Colleague/Benefactor will provide for the creation of several types of reports. Standard and ad hoc report generation facilities will be available to all users via an English-based query language tool, and key personnel will receive instruction through various training programs. More complex, analytical reporting requirements can also be accommodated through the training of VU technical staff by Datatel. An executive information system will be developed for purposes of tracking and monitoring key performance indicators and strategic planning.

The generation of statistics and reports to help monitor performance and manage processes will be facilitated as necessary during project implementation. Though efforts will be made to accommodate reasonable report requests from units across campus, it will not be possible to provide discretionary data report programming services during the implementation process.