Empowering Users As Members Of The Computer Center Team

|-------------------------------------|
|  Paper presented at CAUSE92         |
|  December 1-4, 1992, Dallas, Texas  |
|-------------------------------------|


EMPOWERING USERS AS MEMBERS OF THE COMPUTER CENTER TEAM


Joy R. Hughes
Associate Vice President for Information Services
Potsdam College of the State University of New York
Potsdam, New York



ABSTRACT

Many colleges are faced with the problem of outdated administrative 
computing systems that consist of: 1) thousands of programs that have 
been patched to the point where it is almost impossible to follow the 
program logic in order to revise it to meet changing needs; and 2) 
dozens of flat files containing data that are redundant, inaccurate, and 
unable to be accessed by modern desktop based query tools. The 
extraordinary work that it would take to replace these programs with 
packaged software accessing a relational database makes the situation 
seem hopeless, particularly given the fiscal constraints and staff 
cutbacks that are endemic to higher education. 

One college utilized the user community to perform much of the work 
involved in converting to a new system. The empowerment of these users 
was the critical variable which enabled the project to succeed despite 
the lack of resources to hire additional computer center staff. 


______________________________________________________________________

I. Background:

     Potsdam College is a State University of New York (SUNY) college of 
about 5000 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 a software vendor to provide 
packaged administrative computing software to SUNY colleges. The 
vendor's software solution featured an Oracle database. It had 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. 

     The computer center then outlined the tasks that needed to be 
accomplished. These included:

* retrain the systems programmer to work in a VAX environment;

* retrain the PL/1 programmers to write in C and to utilize SQL and SQR  
  to generate reports;

* train a programmer to become the Oracle database administrator;

* set up validation files for each structured data field (e.g. 
  specifying allowable room types, address types, student types);

* set up the rules that control the processes (e.g., billing rules, room 
  assignment rules, mappings of majors to degrees, etc.);

* develop data dictionaries;

* develop data entry standards (e.g. upper case vs. lower case, 
  abbreviations);

* develop data maintenance policies (e.g. identifying who can change an 
  address);

* negotiate common and consistent procedures across user departments;

* clean up the old data, resolving inconsistencies and redundancies, and 
  decide in which tables and fields to store the data in the new system;

* write conversion programs;

* modify the new system in order to meet SUNY requirements;

* test new processes and rules; 

* troubleshoot and fix bugs with the new system;

* create reports to replace some of the over 1000 reports generated by 
  the old system each semester;

* evaluate report generation methodologies to determine which might be 
  appropriate for users to learn;

* define, set up, and test "views" of the data so that users will be 
  able to generate their own reports;

* teach users how to generate reports;

* develop documentation;

* develop training plans and materials; 

* continue to maintain the old system during the learning and 
  implementation stages of the new system; and

* modify and test new releases distributed during the implementation 
  stage of the new system.


     The work that needed to be done to convert to the new system seemed 
overwhelming. The administrative computing staff at Potsdam College 
consisted of three applications programmers, one systems programmer, a 
director, an operator, and an office manager. 

     In order to leverage the efforts of the programming staff, selected 
users were asked to become part of the computer center team. This paper 
describes the ways in which users contributed to the project, what 
worked, and what we would do differently if we were initiating the 
project today.


II. Empowering Users:

     The first action taken to involve users in the project was to set 
up a steering committee consisting of a high-level representative from 
the office of the Vice President for Academic Affairs and the directors 
of each office that would be using the new software for transaction 
processing. Members of the computer center staff served as resource 
people. The initial responsibilities of the steering committee were 
similar to those of the typical steering committee for a conversion 
project. It established timelines, for example, and it set overall 
policies. But this committee also promoted behavioral norms that 
significantly influenced the quality of user involvement.

     One such norm was the stated expectation that inter-departmental 
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 
departments to negotiate compromises. 

     Another norm promoted by the steering committee was that 
programmers would not go to training unaccompanied by a user.  Often in 
a conversion project, users are invited only to the training sessions 
that focus on their particular module. In this project, users were 
invited to all training, even technical training such as Oracle, SQL, 
and SQR. The steering committee set aside a portion of the project 
budget to pay the training fees, and the individual user departments 
paid the travel expenses. The participation of users in technical 
training empowered them to be equal partners in discussions with the 
computer center staff. 

     While the steering committee did help to move the project along by 
providing it with structure, legitimacy and resources, it soon became 
clear that the committee was too large and too heterogeneous to be of 
much assistance in the day-to-day implementation work of the computer 
center staff.  To resolve this problem, module subcommittees were 
formed.

     A typical module subcommittee 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 course/catalog module subcommittee, for 
example, consisted of the registrar, the associate registrar, the 
director of transfer articulation, the director of academic services, 
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 chair. 

     The members of the module subcommittee received training in 
developing validation tables and in establishing Oracle rules.  Some of 
this training was provided by the vendor and some by the computer center 
staff. The members discussed how their different offices processed data 
and negotiated the changes that needed to be made 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. Fortunately, 
each of the module chairpersons had the skills required to manage 
meetings that often addressed highly political topics. 

     The subcommittee members developed the rules and the validation 
tables. They sought advice, where appropriate, from other members of the 
campus community. (The course/catalog subcommittee, for example, used 
the opportunity provided by the conversion project to have the faculty 
and deans review all course descriptions and characteristics.) The 
subcommittee made the 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. 

     At times, the subcommittee would get stuck on a technical detail. 
Sometimes the group would not be able to figure out how a particular 
process worked or the implications of the various choices that the user 
was being asked to make during the running of that process. Because the 
subcommittee 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 the periodic visits the consultant made to 
the campus. Often, the majority of the time the consultant spent on 
campus was spent with users rather than with the computer center staff, 
another difference between this and the usual conversion project. 

     One subcommittee had responsibility for the basic demographic 
record of each person in the database. The subcommittee 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, 
this subcommittee 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 subcommittee past some impasse. Fortunately, the chair of the 
subcommittee 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. 

     Each subcommittee was responsible for testing the processes and 
reports that were being developed for its module. Midway through the 
project, the computer center began to be concerned that the testing was 
not sufficiently comprehensive nor was it integrated across committees. 
The steering committee was asked to establish a testing and quality 
control committee. This new committee took responsibility to develop 
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. Each 
committee member was responsible for creating test records and defining 
quality standards. The work of the test and quality control committee is 
credited with the unqualified success of the first registration in the 
new system.

     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 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 institutional research (IR) office also agreed to field 
test query software and to train users how to generate reports. In 
preparation for these tasks, the IR office 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.


III. 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 center laid out the tasks that needed to be accomplished 
   and this helped to focus each committee's energies;

2) the College made a heavy investment in user training;

3) each committee was chaired by a user with strong group management 
   skills;

4) one or more computer center staff 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 got frayed, we took time to reflect on how far we had 
   come and to create new strategies to reduce tensions and to build 
   solidarity.


IV. Things We Wish We'd Done Differently:

     Among the changes we would make if we had to start over, are:

* We would have gotten moving much sooner so that we would have had more 
time to create and test new reports and to train users thoroughly.

* We would have involved more users of the old system who were not from 
the offices doing the heavy transaction processing - such as department 
secretaries, counselors, etc. 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 people 
preferred the simplicity of the old system.)

* We would have had more faculty involvement. During the project, the 
College installed a new network and provided 80% of the faculty with 
desktop computers, mostly MAC's, hooked 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 subcommittees, the 
development of easier-to-use interfaces would have received a higher 
priority.

* We would have attempted 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. 


V. The Future:

     Empowering users to serve as equal members of the project team made 
the project a success despite the small size of the computer center 
staff. It also changed the culture of the computer center to one that 
expects users to be involved in setting standards and priorities and 
expects inter-departmental 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 major system 
enhancements and rules on proposed changes in system options.

2) The institutional research office continues to play the major 
training role for users of the system. It is responsible for updating 
the training manual and for training users on system enhancements. 

3) A student data coordinating committee, comprised of representatives 
from the records office, admissions, financial aid, bursar's office, and 
the computer center, meets weekly to discuss interdepartmental issues. 

4) A proposal to establish a programming prioritization committee, 
comprised of representatives from each major user group, was approved. 
The committee will establish programming priorities once the 
implementation has been completed. 

The continuation of user involvement beyond the end of the project was 
not expected nor planned for. It is an unintended but beneficial side 
effect of the project that is likely to have substantial impact on the 
quality of computer services for many years to come.