CASE STUDY III-8 Purchasing and Implementing a Student Management System at Jefferson County School System

The Jefferson County School System (JCSS) educates about 10,000 students in fourteen elementary schools, two middle schools, and two high schools. It serves a diverse community consisting of a county seat of 80,000 with a substantial industrial base and a major state university, and the surrounding rural area.

Central High School and Roosevelt High School, located on the eastern edge of town, are spirited athletic rivals whose attendance districts split the county into approximately equal areas, with each district including about 1,450 city and rural patrons. The two middle schools each have about 750 pupils in the seventh and eighth grades and also serve diversified areas. The elementary schools are located throughout the county and range in size from rural schools with about 250 students up to almost 700 students for the largest city school.

History of Administrative Computing in JCSS

Administrative computing at JCSS began in the early 1970s when computing resources at the university were leased to do scheduling and grade reporting and to keep student enrollment data. In 1976 the school corporation purchased a DEC PDP 11/34 computer, and the student management applications were converted from the university computer. During the next few years, financial applications were added and more student management applications were developed. Over the years there have been many changes to the JCSS technical architecture. They now have four Dell servers operating under UNIX, and PCs in all JCSS locations are connected to the system via a high-speed TCP/IP network.

All JCSS applications, both financial and student management, were custom developed by the longtime director of data processing, David Meyer, and the two programmers on his staff. The users of these systems were satisfied with them, and when they wanted changes and improvements, Meyer and his programmers would make them. There was no end-user capability—if anyone needed a special report, a program to produce it was written by one of the programmers.

Three years ago the long-time JCSS superintendent of schools retired, and Dr. Harvey Greene was hired as his replacement. Dr. Greene had been the superintendent of a smaller school system and had attended a conference where a speaker convinced him that software had become a commodity and that it no longer made sense for a school system to develop and maintain its own software.

After a few months to get his feet on the ground, Dr. Greene established a small task force of administrators to evaluate the JCSS data processing systems and to recommend directions for the future. Not surprisingly, this task force recommended that:

The JCSS systems should be replaced with purchased software packages with maintenance agreements.

The new systems should utilize an integrated database and report-generation software so that people could share data from various applications.

Because JCSS would no longer be doing custom development, the programming staff of the data processing department could be eliminated.

David Meyer was not included on the task force, and Director of Data Processing Meyer was quite upset with the decision to gut his staff without even consulting him. When these recommendations were accepted by Dr. Greene and the school board, he chose to resign from his position as DP Director. He was replaced by Carol Andrews, who had 13 years of experience as an applications programmer, systems programmer, and systems analyst with a nearby federal government installation.

Purchasing the New System

After spending several months getting acclimated to the JCSS and her new job, Andrews set about the task of selecting a vendor to provide the hardware and software to replace the current administrative computing applications at JCSS. In late November a computer selection committee was appointed to evaluate available systems and recommend a vendor to the JCSS School Board. This 14-member committee included representatives of most of the major users of the system—assistant principals who did scheduling and were responsible for student records, deans who were responsible for attendance and student discipline, counselors, teachers, the personnel director, and the chief accountant. It also included representatives of the different levels of schools in the system and from each of the larger school locations.

 By late March Andrews and the committee had prepared a 71-page request for proposal (RFP) that was sent to 23 possible vendors, asking that proposals be submitted by May 4. The RFP stated that “The proposals will be evaluated on functional requirements, support services, and a 5-year life cycle cost.” The table of contents of the RFP is included as Exhibit 1. Appendices A through E listed in the contents were in the form of fill-in-the-blank questionnaires that defined the information that JCSS desired from the vendors.

The RFP was sent to vendors that would contract to accept responsibility for all the software and support and training services required to install and maintain the new system. Appendix C of the RFP described the JCSS hardware and communications architecture and specified that any required changes to the existing environment must be described and the associated costs presented. The desired requirements for the application software were described in Appendix D in the form of characteristics that could be checked off as included or not.

Although members of the selection committee made suggestions, Andrews determined most of the requirements for the application systems by examining what the existing systems did and talking with people throughout the JCSS. The application specifications for the attendance accounting and student scheduling systems from Appendix D are included as Exhibit 2.

  Selection of the Vendor

Seven proposals were submitted in response to the RFP. Andrews was able to winnow them down easily to three serious contenders that were evaluated in detail. Each of the three finalists was invited to demonstrate its system to the selection committee. The vendors were not told in detail what to show, but they were asked to demonstrate the operation of several of the major systems. The three vendors brought in their own computers for the demonstration, and all of the demonstrations were quite satisfactory to the committee.

The committee originally intended to visit a school that used each vendor’s system, but because of time and money constraints they were only able to visit two sites—one Data Systems, Inc., installation and one Scholastic Systems Corporation installation. Andrews and Dr. Paul Faris, Assistant Principal at Roosevelt High, spent one day at each of these locations observing their systems in action and talking with users. In addition, members of the committee made telephone calls to their counterparts at other schools that used each vendor’s systems without unearthing any major problems or concerns. Everyone seemed quite positive about all three vendors and their products.

The committee had a difficult time deciding between the three finalists. Each of the vendors proposed software packages in all the areas that JCSS had asked for, but none of these systems did exactly what they wanted in exactly the way the current systems did things. The committee finally chose Data Systems, Inc., (DSI) because the members felt they could work well with the DSI people, and they felt that the DSI proposal was best on balance, as indicated in Exhibit 3, which they presented to the JCSS School Board. This table rates six factors on a scale from 1 to 5, with a total rating for each of the finalist vendors at the bottom. DSI was rated highest in “Application Software” because its system was a Web-based system, and the committee felt that this was the technology of the future. DSI had recently converted the functionality of its legacy systems to the Web-based architecture and had only installed it at three school systems, so the committee was aware that it might have more bugs than if the system had been in use for several years. The “cost of ownership” includes the purchase price of the software, installation, training, and five years of maintenance and support. The “bid exceptions” rating refers to how well the proposed software fits the JCSS specifications and thus a high rating indicates that little modification of the software would be needed.

The JCSS School Board awarded the contract to DSI in June. It included the following systems: financial, payroll/personnel, fixed assets, warehouse inventory, registration, scheduling, grades/transcripts, attendance, book bills, office assistant, electronic mail, and special education. These systems utilize a standard relational database management system that includes a query language that generates ad hoc reports.

DSI agreed to make specific changes in the software packages where the committee had indicated that the packages did not meet the JCSS specifications. The contract also provided that DSI would devote up to 100 hours of programming time to making other modifications (not yet specified) in its software. Any additional changes requested by JCSS would be billed at $100 per programmer hour. JCSS also purchased DSI’s standard software maintenance contract.

Implementation of the Systems

With the help of DSI people, the software for the new systems was loaded on the JCSS servers in December. Although they had some problems with the financial systems, they successfully converted most of them from the old systems to the new DSI systems. However, they had major problems in installing and using the student management systems.

Andrews planned to follow the cycle of the academic year when implementing the student systems. First, they would transfer all the student demographic information from the present system to the new system’s database. Then they would complete the students’ fall class schedules by the end of the spring semester, as they had been doing with the old system, so that the students’ schedules would be on the new system and ready to go in the fall. During the summer they would pick up the attendance accounting on the new system so it would be ready for the fall. Then they would implement grade reporting so it would be ready for use at the end of the first six-week grading period in the fall. Finally, they would convert the student transcript information from the old system so that fall semester grades could be transferred to the transcripts at the end of the semester.

They successfully transferred the student demographic information from the old system to the new in February. Then they started to work on student scheduling. Things did not go well. The training provided by DSI for the scheduling officers was a disaster. Then, after entering the student class requests and the available faculty data, they started the first scheduling run. After it had run all day without completing the schedules, they decided that there was something definitely wrong. Andrews never completely resolved this problem with DSI’s experts. DSI claimed that it was caused by the way the scheduling officer set up the scheduling system—the various parameters that the system uses. Andrews was still convinced that there was some sort of bug in the scheduling program.

DSI did make some minor modifications to the program, and they sent some people out to consult with Andrews and her staff on how to set up the schedule, but they were unable to get the schedules done by the end of the spring semester as planned. This caused severe problems because the assistant principals in charge of scheduling were not on the payroll during the summer. Fortunately, Paul Faris, the scheduling officer at Roosevelt, was working summer school, and with his assistance they were just able to get all the schedules done two weeks before school started.

Preparation for the fall was also hindered by the fact that neither the school secretaries, who entered much of the data for the attendance module, nor the counselors, who had to work with the scheduling of new students in the system and changes to schedules of continuing students, were on the payroll during the summer. The administration would not spend the money to pay these people to come in during the summer for training on the system, so all training was delayed until the week before school started, when everyone reported back to work. The training was rushed, and again DSI did a poor job with it.

When school started in the fall, the system was a total disaster. The people who were working with the system did not understand it or know what they were doing with it. When the counselors tried to schedule a new student into his classes, the system might take 20 minutes to produce his new schedule. Needless to say, there were long lines of students waiting in the halls, and the students, their parents, the counselors, teachers, and administrators were upset and terribly frustrated.

Also, the attendance officers did not know what they were doing and could not make the system work for the first few weeks of the semester. Things were so bad that at the end of the first grading period Andrews decided that, although the grade reporting system was working correctly, it was not feasible to have the teachers enter their grades directly into the system as had been planned. Instead, she hired several outside clerical people to enter the grades from forms the teachers filled out. After some well-executed training, the teachers successfully entered their grades at the end of the semester.

By the end of the fall semester most of those working with the student systems had learned enough to make them work adequately, and a few of them were beginning to recognize that the new systems had some significant advantages over the old ones. They did get the second semester underway without major problems, and in early February of the next year they were getting ready to bring up the transcript system and start the scheduling process for the fall.