Empowering Users as Members of the Computer Center Team Copyright 1993 CAUSE From _CAUSE/EFFECT_ Volume 16, Number 2, Summer 1993. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear,and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission.For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu EMPOWERING USERS AS MEMBERS OF THE COMPUTER CENTER TEAM by Joy Reed Hughes ABSTRACT: Potsdam College of the State University of New York was faced with the challenge of changing outdated administrative computing systems containing redundant and inaccurate data that could not be accessed by modern desktop query tools. The College opted to engage the user community to perform much of the work involved in converting to new commercial software accessing a relational database. The empowerment of these users was the critical variable that enabled the project to succeed when lack of resources prevented hiring additional computer center staff for the conversion. Potsdam College is a State University of New York (SUNY) college of under 5,000 students. A few years ago its computer center was struggling with outdated administrative computing systems that consisted of thousands of programs that had been patched to the point where it was almost impossible to follow the program logic, and dozens of flat files containing data that were often redundant, inaccurate, and unable to be accessed by modern desktop-based query tools. SUNY negotiated an agreement with Systems & Computer Technology Corporation to provide packaged administrative computing software (Banner(TM)) to SUNY colleges. The University also offered to provide funds for the colleges to replace their Burroughs mainframes with VAX minicomputers to run the software. Banner, built on an Oracle database, was considered to have the potential to provide for distributed data, true client-server computing, and report generation utilizing SQL- compatible query languages. Potsdam decided to participate in the SUNY initiative to change hardware platforms, convert the data to an Oracle database, and install the packaged software. The College purchased the admissions and recruitment modules, the student system, the financial aid module, the finance module, and the alumni module. The student system included housing, meal plans, and event scheduling, as well as the traditional student functions of registration, grades, academic history, and degree audit. This article describes how the College engaged the future users of the new systems in their implementation. Not only did the user involvement enable an understaffed computer center to accomplish the conversion, but in the process users were empowered through their understanding and knowledge of the new systems. Empowering users The first action taken to involve users in the project was to set up a 25-member steering committee in June of 1990 comprising mainly the heads of the various departments that would be using Banner. It also included a high-level representative from the office of academic affairs, departmental data coordinators, the director of administrative computing, and four programmers. The committee was chaired by a faculty member serving as acting head of computer services (see Table 1). ************************************************************************ Table of Steering Committee Members by Department Admissions: Director; Data Coordinator Residence Life: Director; Associate Director Institutional Research: Director Records Office: Registrar; Associate Registrar Business Office: Bursar; College Accountant Institutional Advancement: Coordinator of Prospect Research; Data Coordinator Academic Transfer Services: Director Graduate and Lifelong Learning: Director; Data Coordinator Financial Aid: Director Academic Services: Assistant Vice President College Auxiliary Services: Controller Meal Plans: Coordinator Physical Plant: Senior Staff Assistant Administrative Computing: Director; four programmers Computer Services: Acting Director Assistant to the Vice President for Academic Affairs ************************************************************************ The steering committee established timelines, set policies, and attempted to move the project along. Perhaps due to the large size of the committee or to its lack of leadership, or to the small size of the computing staff charged with actually doing the work, the project did not make the expected progress. Seven months after the steering committee had been formed, the only real accomplishment was that many of the computer programs running on the Burroughs had been converted to run on the VAX. The computing staff was frustrated and beginning to lose faith that they would ever get Banner up and running. Tasks that needed to be accomplished The acting director of computer services decided to return to the faculty full-time, so the director of administrative computing was put in charge of the project. He and the programming staff outlined the tasks that needed to be accomplished. Retraining of the programmers was, and had been since the start of the project, a high priority due to the entirely new hardware and software environments. The programmers also needed to become familiar with the many thousands of Oracle tables embedded in the packaged software, learn how the various processes worked and interacted, and create programs in a new programming language in order to convert data and to produce replacements for hundreds of critical (and complex) College reports. All of these tasks required programming experience and skills. However, there were other tasks that, while equally important to the success of the project, did not appear to require years of programming experience. These included setting up validation files for each structured data field, developing data entry standards, developing data maintenance policies, creating policies for converting data residing in files on the old system, defining the rules that would control the many processes in the new software, negotiating common and consistent procedures across user departments, and training faculty and staff to use the new system. While tasks like these may not require programming experience, they did require that the people doing them be thoroughly trained in the new system and be knowledgeable about College policies and procedures. The administrative computing department at that time consisted of three applications programmers, one systems programmer, a director, an operator, and an office manager. In addition to maintaining the homegrown systems that were to be replaced with the packaged software, the staff supported the campus DOS users, managed a test-scoring facility, supported payroll and personnel systems provided by the central SUNY office, and maintained a variety of other special purpose systems. The work that needed to be done to convert to Banner seemed overwhelming, particularly since the old system would have to be maintained throughout the process, as would systems and services that were not part of the conversion project Users asked to serve on module teams To supplement the programming staff and get the project moving, the director of administrative computing proposed to the steering committee that selected users be asked to serve on module teams to assist the programming staff by performing those tasks that did not require extensive programming experience. The steering committee agreed, and it also agreed that training fees for users should be funded out of the project budget and that user travel expenses should be funded out of the budgets of the individual user departments. As a result of the agreement to fund training, users were able to accompany the programmers to all training, even technical training such as Oracle, SQL, and SQR. The participation of users in technical training empowered them to be equal partners in discussions with the programming staff. Another policy agreed to by the steering committee that significantly influenced the quality of user involvement was the stated expectation that interdepartmental disputes would be referred to the steering committee to resolve rather than become a discussion item at the vice- presidential level. This expectation empowered the steering committee and motivated the module teams to negotiate compromises. A typical module team consisted of representatives from the offices that would be using that module and the computer programmer responsible for implementing the module. Usually the director of the major user office would be a member, as would the most computer-literate person in that office. The administrative computing director made the initial appointments to the team and selected as leader someone who had the skills required to manage meetings and negotiate solutions to contentious issues. The team, though, had the authority to invite others to join them as the need for their help became apparent. The catalog/course schedule module team, as one example, consisted of the registrar, the director of transfer articulation, the bursar, the assistant vice president for academic affairs, and the director of institutional research--all people with high levels of concern about the integrity of course records. The registrar served as team leader. The admissions team, while it included the admissions director and the registrar, also included members of the clerical staff in the admissions office and in the graduate office because they were not only very knowledgeable about office procedures, but also among the most computer- literate people in their departments. User training intensive The members of the module teams received training in developing validation tables and in establishing Oracle rules. Some of this training was provided by the vendor at off-campus locations. For some team members, it was the first time the College had ever funded their participation in activities that involved hotel and restaurant expenses. At one point in the project, a home department had run out of travel money and it appeared that the clerical staff person representing that department would not be able to attend a critical training session. Administrative computing arranged for a state car and for the user to room with one of the programmers. The investment in user training throughout the project sent the message that team members' contributions were essential and valued. The programming staff also provided training and support to the users as they developed new skills. A training lab was set up in the computer center adjacent to the programmers' offices, and users were encouraged to schedule weekly times in the lab. (At times, departmental directors had to be gently reminded of the need to allow their people to spend time in the lab.) De facto data administration The module team members developed the rules and the validation tables. They also made decisions as to what data should be converted, how redundancies and inconsistencies should be resolved, and in which tables and in which format the data should be stored. To accomplish these goals, they had to discuss how their different offices processed data, and they had to negotiate the changes that were needed in order to take advantage of the functionality of the new system. Since each office would no longer have its own files, but rather share an integrated database, much discussion had to take place about resolving contradictions and inconsistencies among different offices. They sought advice, where appropriate, from other members of the campus community. (The catalog/course schedule team, for example, used the opportunity provided by the project to have the faculty update all course descriptions and characteristics.) At times, the module team would get stuck on a technical detail. Sometimes they would not be able to figure out how a particular process worked or the implications of the various choices the user was being asked to make during the running of that process. Because team members knew their module so well, it was usually the case that if they did not know how something worked, neither did the programmer. These types of questions would be written up to be asked of the vendor consultant during his periodic visits to the campus. Often, the majority of the time the consultant spent on campus was spent with user team members rather than with the programming staff, another difference between this and the usual conversion project. One team had responsibility for the basic demographic record of each person in the database. The team membership included representatives from the alumni office, the admissions office, institutional research, residence life, and the records office. Due to the ownership that the different offices felt about their data files, the team had to make many political decisions that affected data integrity: who could change names and addresses and under what circumstances, what address types were needed, what data entry standards should be followed, which office's data should be favored in the conversion, etc. It sought advice as to how other schools dealt with issues and it asked for suggestions for compromises that might help get the team past an occasional impasse. The team leader had been chosen because she had the skills needed to negotiate compromise and was willing to ask for assistance when needed. So this group, which so easily could have been factionalized and made impotent, instead accomplished all of its goals. User involvement time-consuming, but supported The demands on the team members were quite heavy, and they continually had to balance their commitments in their home department with their commitments to the project. They were often out of their offices at team meetings or in the computer lab or at off-site training. Rumor has it that one department held a mock wake for the director because the staff figured the director must have died since no one saw her anymore. In some cases where a clerical person was the department's team representative, the department's director would question whether it was really necessary for the person to be spending so much time in the computer center. Usually we talked the problems through or developed strategies to help the people not directly involved in the project understand how important the project was to the future of the College. The president and the vice president for academic affairs helped by publicly praising the project and by emphasizing the importance to the College of the functionality of the new system. They each invited the head of the information services division to make presentations to their staffs so that vice presidents, deans, and directors would understand the importance of the project and the contributions that the team members were making. Implementation and testing The steering committee had set implementation dates of November 1991 for the first pre-registration in the new system and January 1992 for full implementation of the admissions module. Each team was responsible for testing the processes and reports that were being developed for its module. Administrative computing began to be concerned that the testing was not sufficiently comprehensive nor was it integrated across teams. The steering committee was asked to establish a test and quality control committee and to push back the date for the first pre-registration to March 1992. The test and quality control committee was established in August 1991. It developed testing procedures that followed the student record from the time it came in via the admissions module, through housing and meal plan assignments, course registration, grading, end-of-term processing, graduation, and resumption of studies as a graduate student. The committee developed test data sets and defined quality standards. As a result of this work, many flaws were identified and corrected. The admissions module was brought up smoothly in January 1992, one year after the first module team was formed. The first preregistraton in the new system, held in March 1992, was also an unqualified success. Training the campus community There still remained the problem of training the hundreds of people who used the old system to obtain information about students, courses, grades, and so forth. The old system was very easy to use, even though its functionality was limited and its information sometimes inaccurate. The new system, however, because it is function-key driven and requires the user to navigate through SQL forms, is much more difficult for the casual user. The institutional research office (IRO) staff agreed to take responsibility to develop training materials, design keyboard templates, and conduct training sessions for the faculty and staff who needed to query the database. The IRO also agreed to field test query software and to train users how to generate reports. In preparation for its project tasks, the IRO conducted a survey of the campus community to determine what information and reports were needed from the central database. The information obtained from the survey was used in the design of the training materials, the user report menu, and the report customization parameters. The IRO staff was eager to assist the project for two reasons: first, they expected a payoff in reduced requests from users for data and reports; second, the IRO, like computer services, is part of the information services division (ISD) at Potsdam. The IRO staff is evaluated according to how effective it is in facilitating the attainment of ISD goals. A successful Banner conversion was a high priority ISD goal. One tradeoff of the IRO's involvement in the project was that surveys from outside agencies were prioritized and those of low priority just did not get done. In almost every user office involved in the Banner project, this prioritization and elimination of lower- priority tasks was occurring. Critical success factors In looking back to see why the implementation was so successful, we can identify the following critical success factors: (1) the computer programmers laid out the tasks that needed to be accomplished and this helped to focus each team's energies; (2) the College made a heavy investment in user training; (3) each team was led by a user with strong group management skills; (4) a computer programmer attended the meetings and provided technical support to the group; (5) the computer programmers enjoyed developing the technical skills of users, they committed time to it, and they bragged about the accomplishments of "their" users; (6) as talented people were identified in user offices, they were given leading roles, no matter what their official job titles; (7) every once in a while, we paused to celebrate our successes--with picnics, congratulatory cakes, or funny certificates; and (8) when tempers flared, we took time to reflect on how far we had come and to create new strategies to reduce tensions and build solidarity. Things we wish we'd done differently Among the changes we would make if we had to start over--and thus advice we would offer others who would like to involve users as partners in a systems conversion--are the following: * We would form the module teams at the start of the project. We lost valuable time during the first seven months of the project as the programmers tried to do all the work themselves. * We would involve more users of the old system who were not from the offices doing the heavy transaction processing, for example, department secretaries, counselors, and so forth. These users could have provided insight as to what features of the old system needed to be replicated in the new system. (We were convinced, mistakenly, that everybody hated the old system. We found out once we implemented the new system that many casual users preferred the simplicity of the old system.) * We would have more faculty involvement. During the project, the College installed a new network and provided 80 percent of the faculty with desktop computers, mostly Macintoshes, connected to the new network. Many of the Mac users were appalled by the difference between the user-friendly Mac interface and the cumbersome, non-intuitive interface to the new administrative system. If we had had faculty on our user teams, the development of easier-to-use interfaces would have received a higher priority. * We would attempt to build relationships with colleges that had been using the system for some time. The system is so powerful and has so much functionality that often we could not grasp the implications of the various system configuration options. Almost all of our outside-the- campus time was spent with the other SUNY colleges that had purchased the system. Since each of the SUNY schools was a new user, we had no opportunity to learn from more experienced users. Outcomes One outcome of the project is that, as clerical staff developed new skills and took on new responsibilities, the College had to find ways within the existing civil service rules to reward them. For several of the clerical staff, this has meant new titles and salary increases. Several members of the professional staff have also seen their titles and responsibilities change. Most of the changes required skillful and often tedious negotiations with the various College departments and state agencies involved, and not all of the changes requested were approved. The College demonstrated, however, by its willingness to engage in these negotiations and fund the salary increases, its commitment to rewarding people who contribute to its success. Empowering users to serve as equal members of the project team changed the culture of the computer center to one that expects users to be involved in setting standards and priorities and that expects interdepartmental discussion and negotiation of system changes. Examples of continued user involvement include: (1) The test and quality control committee continues to set documentation standards and testing rules. It supervises the testing of all major system enhancements. (2) The institutional research office continues to play a major training role for users of the system. Additional training and support is provided by the former associate registrar. She became so interested in the new system and developed such computer skills that she transferred into administrative computing and now helps College departments to analyze their workflows and to utilize the new system to improve productivity. (3) A student data coordinating committee, comprising representatives from the records office, admissions, financial aid, bursar's office, and the computer center, meets periodically to discuss interdepartmental issues. It rules on proposed changes in system options. (4) A programming prioritization committee--comprising representatives from each major administrative user group, two faculty, and one academic secretary--has been established. It evaluates and prioritizes requests for system enhancements. In the beginning, necessity drove us to invite users to work with us to implement the new system. The small size of our administrative computing staff just would not allow us to do the job on our own. Now that we have experienced the extraordinary effect that such involvement has had on project quality and user satisfaction, we realize that we were fortunate to have been compelled to enlist and empower users as members of our project team. Even if we are given additional programming staff in the future, we will continue to enlist user involvement at every stage of our projects. ********************************************************************** Joy Reed Hughes is Associate Vice President for Information Services and Director of Institutional Research at Potsdam College, a SUNY arts and sciences college. Information Services at Potsdam includes the libraries, institutional research, computer services, media services, and telecommunications. Dr. Hughes holds a master's degree in mathematics from Rutgers, a master's degree in computer science from the New Jersey Institute of Technology, and a Ph.D. in information systems from the Union Institute. **********************************************************************