Implementing a Campus Wide Event Scheduling System
At Salve Regina University
Thomas H. Brennan
Salve Regina University
100 Ochre Point Avenue
Newport, RI 02840
401.341.3232
brennant@salve.edu

Abstract

In the fall of 1999, our University of 1,700 students had four independent event scheduling systems, each representative of its own respective area. The areas involved were the Conference Center, the Registrar's office, the Student Activities office, and the Athletics department. Faced with a mounting problem of campus event scheduling conflicts as well as overtaxed support resources, the University embarked on a search for an integrated campus wide event scheduling system.

The report describes the implementation project of a campus wide event scheduling system. The project followed the traditional path for systems implementation of packaged software including, among several other key steps, requirements analysis, vendor package selection, project organization, application software configuration, policies and procedures development, and agreement on scope, phases, and timeframes of implementation. What made this implementation unique for our school was the collaborative effort by the four heretofore independent campus agencies to successfully install a common campus wide system in a timely fashion.

Background

"The World Before…"

Each event scheduling office at the University had its own system for recording events that were held on campus. For example, the Registrar's office, the Student Activities office, the Conference Center, and the Athletics department each had independent procedures and event schedule publications. The Registrar's office would schedule classes and exams by using a module in our student information system (Scanware), which runs on an IBM AS/400, and an Excel spreadsheet generated from a PC; the Student Activities office preferred to use MACs and an outside publisher to generate its schedule of activities; the Conference Center had a word processing document that was upgraded to an Excel spreadsheet on a PC; finally, the Athletic department determined its team schedules with its league conferences and then produced seasonal game schedule flyers for distribution.

Since each scheduling area would generate its own schedule, problems would arise. Several events would appear on some schedules and not on others; there would often be inconsistencies in event times and dates on the different schedules; the schedules would not allow for updates due to publication deadlines; there was a tendency to inadvertently over book events on certain days and under book events on other days; and the supporter parties had to check with different offices to determine resource requirements. Because of the multiple scheduling offices operating in an independent manner, there were numerous miscommunications, misunderstandings, and tendencies for 'last minute' decisions, made in a stressful mode, for conducting events.

A Call for Help

The University had implemented a 'One Card' system for University students and staff in January, 1999; this system was well-received and it was recommended to offer a modified 'Conference Card' system for the 1999 set of summer conferences. The card system vendor (CBORD) informed us that it was introducing a new Conference and Guest Management System (CGMS) that might be of interest to us. In the fall of 1999, a first effort was made to investigate the CGMS system by reviewing some documentation and conducting some reference checks (e.g., Kansas State University).

In the meantime, other seeds of interest were breaking soil. The Registrar's office and the Student Activities office had seen different event scheduling systems at their respective professional conferences and thought that a more collaborative and automated approach would be of benefit. They recommended that a package named Scheduler Plus from CEO be considered. Further, the University was building a new Rodgers Recreation Center (athletic wellness center), the first such center on campus. The center was seen, among many things, as a facility for bringing the University community together by attending a variety of events, such as athletic games, and by engaging in exercise activity. Finally, through an institutional planning process initiated by Therese Antone, RSM, the University's President, one need that surfaced was to create a 'vibrant, learning community' at the school. One of the goals was to do a better job planning for and communicating information about University events.

Requirements Study and Product Reviews

General Requirements

Several items were mentioned by the different scheduling offices as being essential in an event scheduling system. For example, a general requirement of an event scheduling system was that it allow for interdependent scheduling of events using a common data base of campus spaces, times, and resources. Although primarily intended as a resource management facility, it should also have the capability of outputting a variety of schedule reports for the user community. In addition, it should have a facility to generate 'ad hoc' reports and contain a web-accessible component for parties internal and external to the University. Other requirements are listed in the 'Requirements Summary Checklist'.

System Requirements:	Acceptance
General:
1.- Allows Multi User Data Entry to Common Database
2.- Allows Natural Areas of ‘Eminent Domain’
3.- Efficiently Communicates Shared Resource Requests
4.-  Provides Smooth Procedures between Requestor – Requestee
5.- Keeps Track of Allocation of Shared Resources (Rooms, etc.)
6.- Automatically Adjusts Available Inventory
7.- Provides Queueing Capability for Shared Resource Requests
8.- Provides Easy Procedures for Blocking Rooms, Dates, Times
9.- Efficiently Broadcasts Event Schedule to User Community
10.- Provides Efficient Procedures for User Interface
11.- Provides Easy Query Capabilities for Users
12.- Provides ‘Real Time’ Updates to Event Schedules
13.- Retains History of Event and Required Resources
14.- Retains Previously Used Seating Plans for Event
15.- Accommodates Recurring Events
16.- Allows Different Rate Structures for Event Services / Groups
17.- Provides Informative, Flexible, and Efficient Billing Procedure
18.- Tracks Costs for Different Event Activities
19.- Accommodates Multiple Contracts / Multiple Events
20.- Provides Subconference Capability tied to Event
21.- Provides Special Activity Capability tied to Event
22.- Accommodates Setup/Breakdown Requirements for Event
23.- Accommodates Variety of Seating Plans and Room Attributes
24.- Accommodates Contract Reporting, Tracking, and Billing
25.- Accommodates Special User Defined Codes and Parameters
26.- Accommodates Special Comments or Notes for Event
27.- Provides Standard Set of Meaningful Reports to Users
28.- Provides Procedures for Using Report Data in Spreadsheets
29.- Provides Training (Remote, On-Site), Manuals, etc.
Technical:
1.- Provides Proven Reporting Tool (e.g., Crystal Reports 7.0)
2.- Provides Proven Database System (e.g., SQL/Server 6.5, 7.0)
3.- Provides Robust Security Administration
4.- Operates under Windows / NT 4.0 Server
5.- Operates under Windows 95/98/NT Client Systems
6.- Runs Effectively with Netscape Navigator or IE
7.- Compatible with Microsoft Tools (e.g., Excel, Project, etc.)
8.- Accommodates Mobile User Login Capability around Campus
9.- Offers Acceptable Screen Response Time
10.- Vendor Offers Responsive Remote Support Capability
11.- Provides Clear Delineation of Network/DB/Apps Security
12.- Provides Flexible Import / Export Procedures
13.- System Can Operate over Campus Data Network
14.- System Can Operate on Pentium Processor Computers
15.- Vendor Provides Comprehensive Installation Support

Product Reviews and Reference Checks

The product investigation team included members from different areas on campus involved with event scheduling. There were representatives from the Conference Center, the Registrar's office, the Student Activities office, the Athletics department, the Dining office and the Information Technologies office. To augment the stature of the project, the VP of Administration accepted the role of the senior administrative "champion" of the project. The initial product that was investigated, CGMS, did not fare well in our reference checks. At the time of our investigation, this product seemed to focus more on the guest management perspective rather than the conference management perspective. A second product, Scheduler Plus, seemed to have all of the functional features desired, except it appeared to be a better fit for the needs of a single scheduling office rather than a multi-user campus wide scheduling environment.

The third product investigated, Resource 25, was actually recommended through a reference check of the second product. Resource 25 supported a multi-user scheduling environment using a supported data base system (SQL/Server), with a proven report generation tool (Crystal Reports) and with web-accessible capabilities.

Concentrated Effort to Review Leading Product Candidate

One difficulty in analyzing the Resource 25 product was its lack of sales support in the New England area. Further, it had no procedure for distributing sample applications on a CD. Finally, the company (Universal Algorithms, Inc.) is located in Portland, Oregon and since we are in Newport, Rhode Island, it was not convenient for us to visit the sales office for a product demo. As an alternative, however, the vendor suggested that we conduct remote product demonstrations of Resource 25 using Microsoft's Net Meeting; this technology allowed us to connect their sales office with our University campus in a convenient manner. As a result, we conducted four or five in-depth discussions of the product over the Internet through Net Meeting and a telephone connection.

After signing a non-disclosure agreement, the vendor offered us the review of its product documentation (hard copy and online) and web-based demonstration session. These items were reviewed by members of the product investigation team both from an application and a technical perspective. The product investigation team developed a common set of questions to ask of different reference parties. It was encouraging to find that Resource 25 had already been selected by a number of schools in New England (Wellesley College, Bentley College, Bridgewater State College, Middlebury College). Many references did caution us, however, that the implementation process could be very time consuming, particularly if more than one scheduling office area were involved in the project.

Bolstered by the positive feedback we had received, more serious activity was conducted. The Resource 25 users at one prominent Massachusetts school, Wellesley College, invited us to visit their campus and to discuss their experience with both the implementation and use of the Resource 25 system. Although Wellesley initially focused on special events and conferences, there were enough similarities with the environment and procedures that the visit was very beneficial. After reviewing demonstrations of the Resource 25 system with vendor data, it became imperative to view the system using data that our users could recognize. To this end, a sample set of Salve Regina data consisting of campus spaces, resources, requirements, and events was sent to the vendor who prepared a demonstration session for us using the indigenous data. A final Net Meeting demonstration was conducted using the selected Salve Regina data that allowed us to 'test drive' the system on a more meaningful manner.

After the final Net Meeting demonstration in May 2000, the product investigation team unanimously voted to recommend the purchase of the Resource 25 system for implementation at Salve Regina. The overall investigation process covered seven months from the initial product review to the final recommendation.

Project Implementation

Project Organization

After the funding for the application was approved and provided, it became important to establish a solid organization for the implementation of the system. Due to the campus wide perspective of the implementation, it was anticipated that several event scheduling policies would have to be established and several event scheduling procedures would have to be redefined. This result warranted broader senior administrative participation in the implementation. Thus, a steering committee was established along with the required project team.

The steering committee, which meets on a monthly basis, consists of the VP of Administration (who oversees the Conference Center), the VP of Finance and Business Affairs (who oversees the Information Technologies office), the VP of Student Life (who oversees the Student Activities office and the Athletics department), the Registrar (who oversees the Registrar's office), and the director of IT (who serves as the project coordinator). The project team, which meets on a weekly basis, consists of the Conference Center coordinator and support person, the director of Student Activities, the director of Athletic facilities, the assistant registrar, the dining service manager, a senior programmer analyst assigned to the project and the director of Information Technologies.

Project Plan

It was important to describe the key benefits of implementing a campus wide event scheduling system to members of the University community. The primary benefit was to establish a recognized communication tool for all University parties regarding the occurrence of events on campus. It was also important to reduce any confusion in the naming of events, to reduce any conflicts on the dates of important events, to eliminate any redundancy in efforts, and to operate more efficiently from a space allocation and resource utilization perspective. Based on the experiences that we had heard from other schools that had implemented such a system, it was suggested that the system be implemented in phases with predetermined scopes. The summer orientation and conference season of 2001 was targeted as the goal to have the system fully implemented. In the meantime, key milestones were set on system installation, data base population, and prototype events.

Initial training was seen as a critical activity. The Resource 25 system provides a framework of components that have to be understood, defined and utilized. There is a particular set of rules that have to be followed in a certain order in developing the system. This result requires specific training that is typically conducted on a limited basis in Portland, Oregon. Because of the personalized nature of the training, the vendor set a limit of only twelve persons to a workshop and a maximum of three persons from the same institution. Our initial group that was sent to training in mid-August 2000 included the Conference Center coordinator, the assistant registrar and the senior programmer analyst. This group returned to the University with a better understanding of the system. Resultantly, they set about to build the space master list with all of its attributes and features, the list of contacts and the list of organizations. Soon after they returned, an initial event type hierarchy was established for the system.

Important Decisions

An event scheduling system is a key communication tool for the University community regarding campus events. This result suggests that specific parties who play key roles in event scheduling need to be identified, such as the requestor, the scheduler, and the supporter. The requestor is the one who naturally requests that an event be conducted; this party needs to be aware of head count, resource requirements, and dates among other items. The scheduler accepts the responsibility of serving as the key communicator of the event, particularly to campus parties; this person utilizes the Resource 25 system to determine appropriate uses of campus spaces, sees if there are any conflicting events occurring around the same time, and ensures that all support parties are made aware of the request for resources. The supporter provides a specific resource service for the event such as dining, table and chair setup, audio visual equipment and security concerns. These roles had to be identified and acknowledged in order for the system to run efficiently.

Other important decisions involve the event type hierarchy and the manner of scheduling. Events are classified by different type in the Resource 25 system. For example, types include class, exam, game, practice, meeting, etc. The event type hierarchy, however, is permanently defined. Further, it is very difficult if not impossible to undo a particular event type once defined. The key decision at the outset, therefore, was to establish an event type hierarchy that was comprehensive and representative, yet not too detailed. In addition, a very challenging decision for a multi-user campus wide event scheduling system, is whether to schedule events by type of event, space (facility), or customer (requestor). This decision is central to the role of the scheduler. Its result affects procedures for requestors to follow. We opted to follow the event type procedure as

Event Scheduling Communication Model

Requestor / Scheduler Relationship Model

much as possible; this allowed us to rely on particular scheduling office expertise in fully planning for an event.

Finally the determination of project phases and scope required an important decision. With the ultimate goal of achieving full implementation of the Resource 25 system on campus by the summer season, 2001, it was important to establish recognizable phases of implementation. It was felt that, in the first phase of implementation, the system should cause a minimal amount of disruption in the request and support of events. Thus, for the most part, campus requestors of events would go to their accustomed scheduling office for this service. On the supporter side, a new 'Salve Regina University Calendar of Events' report would be developed and distributed to key support parties on a weekly basis; this report contained a substantial amount of event information similar to yet beyond what was previously distributed. The web accessible components would be introduced in a later phase.

Testing and Acceptance

Because of the rigidity of the Resource 25 system with regard to the event type hierarchy and certain master list entries, it was decided that once an initial framework was agreed to, a copy of the system would be made and preserved for future production use. In the meantime, the various scheduling offices could practice on the test system where decisions and actions could be more easily tolerated. This action occurred in November 2000.

For testing, two levels of prototypes from each scheduling area were targeted. The first level would be a typical simple event such as a game, a class, a presentation, etc. The second level would require additional resources, extend over a couple of days and consist of various sub events; some examples included a small conference, a series of games and a set of department exams.

Because only three project team members were given formal training, it was necessary to provide additional training in using the Resource 25 system to several more persons. Rather than send a larger group of persons to Oregon, an arrangement was made with the vendor to conduct the training on site at our University. In this way, we could have up to 10 persons involved in the three day of training; this activity occurred in December, 2000.

As a result of the two levels of prototypes that had been completed and the on-site training that confirmed several decisions and procedures previously made, the project team recommended that the event scheduling system be targeted for phase one production use in January, 2001. This recommendation was made to the project steering committee later in December; the project steering committee approved the recommendation.

Production Use of Campus Wide Event Scheduling System

Phase I

Because the University had independent event scheduling procedures before the implementation of the Resource 25 system, it was suggested that some of these procedures stay in effect, in a parallel mode, for a minimum length of time. One scheduling office, the Conference Center, had the biggest challenge because previously, there were several parties in their office who could update the Excel spreadsheet event schedule whereas with the Resource 25 system, more extensive user training was required. Further, the Conference Center coordinator was only available for limited duty during this transition. Thus, other team members had to provide additional time and effort in order for the system to be used properly.

The Registrar's office scheduling function primarily occurs in the student information system (Scanware). The challenge in this area was not so much in training as it was in developing an efficient system interface between the student information system (Scanware) and the event scheduling system (Resource 25). An extensive effort involving detailed customization proved successful in populating the Resource 25 system with spring semester class schedules; the VCAL file format was used in creating the transaction file for the interface.

A distinction was made early in the implementation process between a person who is responsible for campus space such as a building, and a person who is responsible for an event that occurs in a campus space; the former party is called a 'space owner' and the latter is called an 'event scheduler'. When the event does not have any resource requirements other than space, the space owner could arrange for the event and then notify the appropriate scheduling office; if the event does have additional resource requirements, however, the request should go immediately to the scheduling office that will oversee all of the planning for the event. These roles are slowly evolving into the appropriate form.

Two challenges that we have experienced thus far involve resource management and communications. A limitation of the current release of the Resource 25 system is that it assumes an infinite capacity of resources. This result allows the means for a scheduler to record the need for a particular resource, such as a laptop or a projection unit, without acknowledging the availability of the resource; the burden is placed on the supporter party to determine the availability and offer an alternative means to satisfy the requirement. Different schedulers are at different comfort levels in using the system. It is important, however, to communicate with each other with regard to event space utilization, concurrency of events and resource availability.

Further, there is the issue of properly informing the University community at large of the new event scheduling system. Three formats of information on the new event scheduling system were considered in order to effectively communicate with the University community. The first format is through articles in the campus newspaper, the Navigator; thus far, there has been a general announcement of the Resource 25 system in the newspaper, and more recently, a feature article and picture. The second format of information is by creating an event planning pamphlet that can be distributed around campus and available in each of the scheduling offices; this item, which has been designed by a member of the project team, contains a brief description of the procedure for requesting an event as well as an event planning form. Finally, the third format is a more detailed reference manual for the different scheduling offices; this item, which is currently being prepared, would be useful for the different scheduling offices in better planning for the scheduling of an event. It would contain space guidelines that should be considered in assigning space for an event as well as key definitions, concepts and procedures.

Phase II

In preparing for phase II of production system use, there are a few items that need to be addressed. First, there is the item of space ownership jurisdiction. An agreement, initiated at the senior administration level, is needed in order to determine when campus space can be utilized in particular buildings by certain requesting parties; there are at least six such areas on campus that are under review. Further, as a means to document the event request, a web-based event planning form of similar format to the event planning flyer is being considered as well. This item would be useful for parties internal and external to the University.

Finally, there is the need to provide web access to the calendar of University events from both an internal and external perspective. The Resource 25 system has the capability of providing supporter parties with a web accessible 'to do' list of requirements for various events scheduled on campus. It can also provide a utility for extracting event information for certain event types and dates. In addition, for external parties visiting our web site and wanting to know more about various events on campus, a customized web accessible event list is being considered.

Summary

In retrospect, the success of the campus wide event scheduling system at Salve Regina University thus far can be attributed to many factors. The sponsorship of our senior administration, particularly the VP of Administration, has been a significant factor; this involves the financial resources as well as the commitment of staff time for the project. The dedication, cooperation and fortitude of the project team were of critical importance. The representation of the different scheduling offices in the needs analysis, product reviews and selection, and software testing allowed the system implementation to possess a deeper level of ownership and thus commitment to the tasks at hand. Finally, the availability and understanding of operational support resources, when most needed, were very beneficial.