Henry G. (Hank) Vaughan
Recollections, 1971 - 1977
Background: Let me start this interview with a different perspective than discussing administrative computing, per se. That was only a part of my responsibilities at Cornell. My job was actually much broader than just overseeing the use of computers for administrative purposes.
In the late 60s Cornell quietly hired McKinsey and Co. to make an analysis of how the University might begin to better manage itself, although "management" was (and is) a bad word in research universities like Cornell. One of the consultant's recommendations was that Cornell should create a vice-presidential level position to oversee the definition and development of an appropriate Management Information System [MIS]. Cornell apparently decided that it would be too controversial and expensive to exactly follow the consultant's recommendation. Instead, they decided to create a lesser "Director" position, reporting to the Vice President for Administration, and began conducting a national search for applicants with relevant experience. Subsequently I was told that I had been one of about 400 people who had responded to blind ads that appeared in both the NY Times and the Washington Post during the spring of 1970.
The Cornell Hiring Process:
About six months later, and after two visits to campus involving interviews
with sixty-one different people, I was hired into the new position called
"Director of Management Systems and Analysis". The University's direction to
me was to take control of the existing administrative computing resources (and
an existing separate Institutional Research Department), to define and start
to develop a management information system, and to serve as an internal
consultant to the University's Executive Staff.
The creation of this new central administration department with the word "management" in its title, and the fact that it was created out of parts of several existing University departments, was a cause of concern to some. Because all of the job applicants were being considered based upon their relevant industrial expertise, Cornell also had to pay an industrial-level salary to attract qualified candidates.
When I was selected, some were also concerned that I was not an "academic" yet would be one of the youngest Directors ever hired at Cornell, a place where administrative promotions traditionally were based upon academic credentials and /or seniority. Thus, the previous Director of Institutional Research left the University just before I arrived, and the Manager of Administrative Computing soon afterwards. As I was recently told by one of these individuals: "Henry, you came in with a target on your back!"
I almost didn't take the job. During the intervening six months after Cornell responded to my resume, I made two trips to campus, including one where I was asked to bring my wife to campus to meet then-President Corson. I finally expressed my frustration to my future boss, VP Sam Lawrence, about the speed of decision-making at Cornell and suggested that they should either make an offer, or we should both quit wasting our time. A job offer came shortly afterwards, which I accepted after some reflection. Because I had both an engineering degree and a MBA from Cornell, I thought it would be an interesting opportunity to apply the various things I had learned over the years, and an opportunity to help improve the management of my alma mater.
Hindsight showed my intuition had been correct. Compared to my past experiences in the military and the aerospace industry, Cornell did make decisions at glacial speed, and these decisions often were influenced by academic politics. This became one of my major frustrations during the next seven years at Cornell.
My Initial Assessment:
I began work in late December 1970, but my family remained in the Washington
(DC) area until the completion of the school year. This was actually quite
beneficial since it gave me a lot of time to study paperwork and to meet with
many different people to ascertain the "state of things".
Within a few months I was able to do some reorganizing and to make some appropriate policy decisions in order to overcome the "status quo", and to get administrative computing activities moving in new directions. Along the way I inevitably ruffled some feathers, particularly of faculty who had opposed the creation of my position, and who were concerned that they didn't want any "management" at Cornell, nor any significant changes, nor for the University administration to be too visible.
My specific prior experience had been in research and development management, long range planning activities, and in managing computer software development projects. Based upon those experiences, my investigations of the situation at Cornell led me to the conclusions that activities were inadequately funded, and that the quality of University's "systems" ranged from 'good' to 'discouraging'. For example, when I looked in detail at the administrative computing activities, I found something like 500 or 600 separate unique programs being used. Many of these were very old programs now being run using a 1401 simulator running on the mainframe computer, and many of these programs had not been changed significantly in 15 or 20 years.
By industry standards, the place was being held together with Band-Aids. There actually was a significant amount of computing resources being spent on trying to keep old things running, but very little being authorized, or spent, on developing more modern solutions. Obviously a major part of my personal attention would be needed in defining the overall goals we were working towards, and to define smaller do-able projects that could be done within current budgets and still help us achieve our goal.
Internal Consulting Responsibilities:
Meanwhile, I had this important other part of my job, not directly
associated with computing, which was to be an internal management consultant to
the Executive Staff. In particular, there was an immediate concern to learn
more about how the University made "management" decisions, and to determine
where short-term improvements could be made to help alleviate perceived
financial problems. I thus had the charter, and obligation, to use the
University's existing computing resources to try to ferret out this relevant
information.
As an example, then Provost Bob Plane made the comment that he had the feeling that Cornell was going to hell financially but he had no way of substantiating this -- and was it true? This was in the days prior to spreadsheet programs like 'Lotus 1-2-3' or 'Excel' (or even the first spreadsheet program named 'VisiCalc'). Using a big piece of paper and a calculator, I developed a big manual spreadsheet on my dining room table based upon an analysis of the data trends in the last ten years of the University's financial reports. After examining items like the University's book acquisition costs for each of the last 10 years, I estimated a compound growth rate for this expense category. Using this cumbersome process, I could project forward a particular component of the University's future financial revenue and expenses, based upon recent experiences.
This analysis confirmed Provost Plane's earlier concerns. After the reasonableness of the component projections were confirmed by the appropriate departments, I later would assist members of the Executive Staff in doing "what if" simulations to estimate the future effects of various possible policy decisions. As my ex-wife said, my office was sort of the CIA within the University since these behind-the-scenes studies helped the Executive Staff make the determination of how much money would be left for faculty salary increases vs. how big a tuition increase was necessary to fund these plans.
Obviously these were sensitive discussions so we attempted to work as inconspicuously as possible. These initial simulation activities were quite simplistic by today's standards, but they provided needed insights into many complex subjects that had not been previously investigated in a systematic way. Besides helping the Executive Staff in the short-term, these non-computing activities were indispensable in helping to define the real "management information" needed to run a modern university.
Exectuive Staff Use of Computing Results:
As indicated above, the initial financial planning models were a paper-based
manual tabulation. Subsequently we converted this to a batch-programming task
running on the University's mainframe computer. To reduce the time delays
between identifying possible decisions, preparing punch cards, and waiting for
the printed reports that predicted their financial effects, an even faster
solution was needed. To this end I personally developed a more sophisticated
version of the model written in the "APL" interactive programming language.
We then purchased a small portable computer terminal (with integral thermal paper printer and a 300 baud acoustic coupler) that looked like a typewriter. Using this device and the Provost's telephone handset, we would actually meet right in the Provost's office and experiment with different "what if scenarios." This provided immeasurable assistance to the Executive Staff in doing their job, but it also helped them understand the need to provide funding for more MIS efforts in the future.
Another industry computer-based tool that I was familiar with was Informatics' "Mark IV" software. This was a batch-mode program used to compare the contents of selected data fields located on one or more data tapes. Once Cornell approved my request to buy a copy of this program, we used it extensively to examine data tapes and other computer files in the University's possession.
For example, every time a high school student took the SAT tests and designated that Cornell should receive his or her test scores, the Educational Testing Service [ETS] would send Cornell a 9-track data tape containing every test score known about that student. The University had saved these tapes for many years in its computer tape archives. While the Admissions Office always claimed that the applicant pool was very strong and that only the best students were ever admitted to the University, we wished to do some independent and more detailed investigations. We were not looking at individual student data, of course, but instead used this wealth of computerized data to get a macro picture and to more precisely examine trends.
Academic politics was a major problem that always required discretion. For example, any analysis of improving "management" at an academic institution sooner or later necessitates looking at the issue of faculty productivity. There's no good way of measuring it - there never has been and probably never will - but you can make some crude approximations. Again our concern was not to study the problem at the individual level, but rather to look at higher levels of data aggregation. We did some analyses of the number of credit hours produced by every academic department vs. the faculty salaries and other costs associated with that department. These results were then compared over several years and between comparable departments like 'Government' vs. 'History', or 'Physics' vs. 'Chemistry'. Clearly we did this quietly and the information was never exposed in the student newspaper due to our secretiveness. Yes, along the way, we ferreted out interesting information like the Physics Department was discovered to have something like 44 tenured faculty members, but only 6 self-declared undergraduate physics majors.
Another interesting study was looking at the whole question of when would the senior faculty be retiring? We discovered some major problems in several departments in the Ag School, where many senior faculty were of the same approximate age. Without corrective action, this meant that there was little opportunity to hire additional faculty for many years in these departments, then once retirement age was reached, the University would have to replace most of the faculty at one time.
Comparing data tapes was not a very glamorous task, but this use of computer technology enabled us to more precisely examine several years of data in a consistent manner, and without burdening (or informing) the relevant office usually involved with the data. Other studies such as determining where the University's employees lived, by job category, enabled us to highlight problems in hiring procedures and to alert the Executive Staff to potential problems that might affect the scheduling of employee work shifts and the University's snow-closing policies.
The object was never to fix blame, nor to identify individuals, but rather to get some sense of where the University's problems were located, where things needed to be tuned, and where things were best left alone. Although we consumed some computer resources examining old computer tapes, I had been given the charter and financial resources and the direction to do this type of activity, and the results enabled the grateful Executive Staff to be better informed when making decisions.
Over time, the usefulness of information that we could glean from a particular administrative area's data processing files, vs. the perceived needs for information about that area, helped determine the priority for overhauling the software used by an area. Each area such as Student Records, Payroll, Finance, Library, and Public Affairs [Development] had insatiable demands for both better and newer information systems, and to keep information flowing from its current systems. It was a juggling act where it was impossible to please everyone, but I did have the benefit of being the person most responsible for approving each administrative department's data processing budgets.
Other Data Analysis Activities:
In addition to the incidents described above, the Institutional Research staff
coordinated the University's response to several hundred different requests for
information received from other educational institutions and governmental
agencies throughout the year. Specific university departments like the
Admissions Office could and often did prepare the answers for most parts of the
responses. Other inquiries required extensive analysis and inter-departmental
coordination by my staff before we prepared and released the university's
official response.
One particularly memorable activity was helping the Executive Staff respond to a request by the U.S. Department of Education to "prove" that the University didn't discriminate, as alleged by a complainant, in the hiring and promotion of female and minority faculty members. After numerous meetings and a computer analysis of our computerized personnel records, the University was able to reply that although there might appear to be instances of discrimination, the allegation could not be proven within the statistical probability errors appropriate to the number of recent doctoral graduates available in those fields. The government reluctantly acknowledged the validity of our argument and submitted detailed analysis, and agreed to close its investigation. This freed the Executive Staff from a major distraction, and gave the University the time and impetus to conduct its own thorough review of every recent faculty promotion and of the adequacy of its existing procedures.
At the request of the Weiss Committee, a special committee appointed by the University Board of Trustees to investigate improving the efficiency of the University's operations, my staff also was given the responsibility and authority to created a confidential management analysis report called the "Cornell Indicators". The distribution of this multi-page monthly document was tightly controlled and copies were mailed in sealed envelopes only to members of the Executive Staff, Academic Deans, and the Executive Committee of the Board of Trustees. [Comparable executives at selected similar institutions apparently heard about this effort from their Cornell colleagues, and after each case was individually approval by the President, a few copies went to other institutions like Stanford on a monthly basis.]
In this report the staff prepared critical and highly confidential analyses of many different areas of the University's operations. Areas studied included an analysis of the success of the undergraduate admissions process (by college), and an analysis of the student grade distributions actually being given by the faculty in each of the colleges. Other efforts were an analysis of Cornell's average faculty salaries (by academic rank for each of the colleges), and an analysis of the performance of the University's endowment investments vs. those results achieved by comparable industry averages, other well-endowed institutions, and by leading large mutual funds. In general these reports were well received, except by those responsible for supervising the areas whose performance was identified to need improvement.
(Rudan indicated that these reports later were discontinued. Soon after his arrival, President Rhodes decided that he didn't want to deal with the occasional controversies caused by having such critical second opinions, and was concerned about leaks to the media even though their circulation was very limited.)
Computing Organization Conflicts:
Over time there were inevitable hostilities that developed between your
organization [the Office of Computing Services, or OCS] and mine -- because we
had different objectives. Your organization [OCS] was chartered to operate a
computer utility analogous to a power company that produced the electricity for
the entire city - both academic and administrative users of computing. In
contrast, my organization [MSA] was expected to use computing tools (and other
techniques) to allow administrative tasks to be efficiently completed on a
regular basis, and to extract more and better information from such routine
activities.
Stated in another way: OCS preferred to continue to smoothly process punch card transactions for administrative departments like it had always done, vs. MSA wanted to develop new and better techniques to help identify problems inherent to running the University. Thus, our organizations differed on our objectives and on the appropriate plans for the future. Unfortunately, many faculty members and administrative managers, including our mutual boss, VP Lawrence, didn't fully understand the implications of these different strategies on the future of the University's operations.
An example of these major philosophical differences is that I attempted, with little success, to get "teleprocessing" implemented in administrative computing. Although the use of such desk-based remote data terminals would have helped improve the efficiency of the Universityıs operations, the higher initial cost of implementing this user-based technology was hard to justify vs. the University's traditional batch-mode data processing strongly favored by the OCS.
When the University was in the market to upgrade its mainframe computer in the mid-seventies, I also tried to get the University to fund separate and slightly smaller administrative and academic mainframe computers so that each could be specialized to a different type of computing, but budget concerns prevailed. It wasn't until many years after I had left the University, and the era of the microcomputer had been reluctantly accepted by OCS, that Cornell administrative departments finally realized the benefits of having user-based decentralized computing.
(Rudan noted that his organization, OCS, was also responsible for supporting academic computing which produced yet another tension and juggling act to keep both academics and administrators reasonably happy.)
New Directions in Integrated Systems:
In the administrative computing area, one of the first situations that I
inherited was the decision to build a new combined and integrated Payroll and
Personnel [Human Resources] system. This decision was made in the winter of
1970, almost a full year before I came, because Cornell was required to come
into compliance with the provisions of the federal Fair Labor Standards Act
[FLSA]. American industries had complied with this law for many years, but the
courts decided that universities also had to comply with this law. The key
problem to Cornell was that this law required that unless an employee met a
certain federal definition of being a "supervisor", then the employee had to be
paid overtime pay for all non-standard hours worked during a seven day period,
and supporting records had to be maintained.
Implementing this law was very difficult for the University since it had different rules and systems for the endowed and statutory divisions, and historically had not required employees to keep time cards. I remember hearing a senior faculty member rant and rave in a faculty meeting saying that he would never permit his secretary to fill out a time card. The long-time Director of Personnel simply told the group that then the secretary wouldn't get paid anymore! This first implementation of an integrated modern data processing system provided many examples about how Cornell was not organizationally prepared to get into this new era of standardization of procedures.
Prior to my arrival at Cornell, some relevant Research & Development (R&D) work had been going on and some of the final software program coding tasks for the project had actually begun. One of my first tasks, and a typical step based upon my prior experience in the aerospace industry, was to schedule and conduct a major Project Review of the area. In such a scenario, management sits down in a conference room for a multi-hour meeting with the cognizant project manager and his or her team of professionals and asks them what they are doing and why, and about their future plans for completing the project. The staff is expected to be able to identify known and potential problems and to state their plans for overcoming these obstacles.
After some initial uncertainty, because of the staff's unfamiliarity with such a review process, things went quite well. I asked many questions about their technology selections and whether they would make changes if they had a choice. One major issue that quickly became apparent was that the staff felt that they were racing the clock to complete the project, but had uncertainty as to whether they were using the right technology. They had done some experimenting with using a new technique called "database management systems" [now called "data warehousing"]. They were hesitant to implement this technique for this project, however, because this type of technology had never been used before at Cornell, and the project was so visible and had such a tight schedule.
Fortunately I personally had a significant amount of prior experience in this particular area, including managing projects and developing such things. I therefore felt that this was the correct way to go technically, but knew that it was a rather controversial decision at the time. As we examined the possibility more, the staff felt they preferred this new approach and were capable of implementing the technology. Changing the project to use that technique, however, would create a delay of several months in implementation of this complicated and politically sensitive application.
I agreed to champion such a change, so within my first few months in the job I went to my boss and said if I had the authority to do so, I would redirect the project slightly to use this new technology -- but that this decision would mean an implementation delay of several months. Of course, this was a big shock to many people. After some discussions, it came down to the realization that this was precisely the kind of thing that they had hired me to do, so I was given carte blanche to implement the needed changes. While this did cause a slight delay, the result was a modern data processing system that proved capable of supporting the University for almost 30 years because the underlying technology could be readily modified to handle ongoing changes in university policies.
(Rudan noted that the system was partially rewritten in the 1980s when Adabas replaced the similar IMS database technology originally used. The primary cause for the demise of the revised system was the lack of enough data elements in the data dictionaries to implement proposed cafeteria-style benefits and store other desired employee information. Interestingly, with the PeopleSoft system implemented in 1998 the exempt staff are now paid twice a month instead of every 2 weeks, reversing the decision made for the 1971 system! Also it is worth noting that systems still around from the 1970s were later updated to be Y2K compliant and Cornell had no problems crossing into the new millennium!)
Implementing Cornell's first modern management information system component was a challenging experience. Essentially we had to do a cold-turkey implementation - there was no way to do it otherwise. This also was the first time that the University had a combined payroll system for the endowed and statutory divisions, and it was a massive system that supported paying 26 thousand individuals annually. During the final data conversion, just prior to running the first payroll, the new system detected several individuals who had simultaneous full-time jobs at Cornell, one in each division. These individuals were fraudulently "double dipping", but had never been caught because the previous systems were separate.
Another implementation surprise was the number of simultaneous tasks a person was formally assigned. The programmers made an educated guess that any individual would have no more than ten such simultaneous appointments. When the first payroll began processing real data, the programs would fail because the staff had underestimated the number of simultaneous appointments. The value was increased to twenty, then forty, then sixty. Eventually it was determined that one glass blower in the Chemistry Department held something like 72 simultaneous appointments because his time was charged to many different research projects.
Deriving Helpful Management Information:
An interesting benefit of implementing the new system happened a few months
later. The University was faced with a unionization attempt by some food
service workers. This was the first time this threat had come up at Cornell
in many years, and the administration wanted to prepare itself for the pending
negotiations by determining the size of the potential bargaining unit and to
identify its potential members.
One of the data fields in the newly implanted payroll / personnel system was a "job skill code" assigned to every employee. I suggested that we use our arsenal of analysis tools to examine the system's database and to see what it could tell us. The union believed that there were something like 70 potential employees to be included in such a bargaining unit, but our initial analysis suggested that there might be about 120 such employees. The Director of Personnel, and others, said our data must be wrong because it didn't fit with their instincts. The Personnel Department was then given our computer-produced list of names by location and assigned to check it out. Although they did find, as expected, many improperly assigned codes in the database, they also did discover that there were indeed individuals that could be included but that had not been anticipated. A full-time food service worker was discovered in the Library, for example, who made coffee for the staff. That person's record had actually been encoded correctly even though the potential union didn't even know this person existed because they were not assigned to the Dining Department. Another such person identified was a dishwasher operator located in the Chemistry Department whose full-time job was to wash glassware using a commercial dishwasher.
Using computer technology, we were better able to understand the complexities of Cornell, and to help the Executive Staff deal with a crisis situation. This single event helped management better understand the possibilities of improving decision-making by having better data available - and it pointed out the necessity of constantly ensuring that our systems contained correct data.
Administrative Planning & Control Board:
(Do you recall anything about this organization?) When I arrived at Cornell I
was given the budgets for all of the administrative computing activities,
instead of having these costs buried within each separate user organization's
budget. As I recall, that board was in existence prior to my arrival, and was
made up of the representatives from each administrative area using computing.
They met several times a year to argue over who should get what portion of the
available money. After my arrival I chaired these meetings, but it soon became
evident that they were counter-productive, and I assumed its responsibilities
as part of my normal job. Later a 'University Computing Board' was created to
oversee all of the University's computing activities, and I was designated as
the member representing administrative users.
The 'Judy Campbell' Report:
(Do you recall the Judy Campbell report?) Not per se, but it may have been a
summary she prepared of the options available for a student records system.
I should spend a few minutes, however, discussing her hiring as my Associate Director. Having come from aerospace industry and federal funding, I was used to an environment where gender or racial discrimination was not tolerated. You were either competent, or you weren't.
Several years after my arrival, and after having been hospitalized with angina (in lieu of a heart attack), the decision was made that I should focus my personal attention on my strength, which was strategic planning. I was then authorized to hire an Associate Director to focus on the day-to-day activities of the department. One of the applicants was Judy Campbell. [As an aside, it's worth noting that when she initially relocated to Upstate New York several years earlier, she had visited the Cornell Personnel Office. They insisted that she take a typing test because she was a female, but she refused to do so. Judy was already an experienced computer professional with IBM and would not condone such gender discrimination.]
Years later when Judy heard about the new position in my department she contacted me directly, bypassing the usual method of responding to an opening via the Personnel Department -- because of the typing test incident described above. At the time she contacted me, Judy was a Project Manager with IBM-Owego. It soon was apparent that she was the best-qualified applicant, so I hired her. I didn't think about checking with others in the administration about my choice, but I guess I ruffled a few feathers when my choice was announced because she was female, and she was Jewish! This was very unusual in the old days at Cornell, and Judy became the first female professional to occasionally attend meetings with the Executive Staff. [Judy later left Cornell when her husband accepted a job in Rochester, and I think she's currently a Vice President for Technology at Xerox.]
Remembrances of Other Staff:
(Do you remember other particular staff members from those days?) There was
Jerry Tucker who was head of the administrative computing portion that was
moved into my new organization. Jerry was an old style, almost Germanic type
of manager, who really didn't tolerate opinions different from his own. He had
been an internal applicant for my job and left soon after my arrival when it
became apparent that I intended to do things differently.
There also was Bill Tetlow, the former Director of Institutional Research. Bill was a classmate of mine who recently told me at a reunion that he left just before my arrival out of frustration with the ways things occurred at Cornell. His organization had reported to VP Tom Mackesey, but Bill heard about the impending reorganization on the radio before either he or his boss had been informed.
After Jerry Tucker's departure, I considered various internal candidates to oversee the daily activities of the administrative computing programming staff. Because I had done project reviews of all of the various functional areas by that time, I ended up selecting and promoting Ed Hollenbeck who had been a project leader in the Library area. The position was a good fit for Ed's talents, and Ed remained at Cornell in that position for many years.
Another interesting example of the situation I ran into upon my arrival was a fellow named John Joubert. John was a warm and interesting person whose primary experience had been as a B-47 bomber pilot before he retired from the U.S. Air Force. He was hired several years earlier by Tucker and was assigned as the Project Manager for the Public Affairs area. When I held my project review of this area, it became blatantly obvious that John couldn't answer any technical questions, but that he had several staff members under his supervision who were competent females with college degrees, which he didn't have, and who were doing all the work. John was in over his head, and I later had to suggest that he consider employment opportunities elsewhere. Months later John left Cornell and had a successful career as manager of the local Tompkins County Airport, which was a job more suited to his experience and interest.
Dolly and Libby were two others that I particularly remember, and who were friends that lived together. Dolly Sewell got promoted to Joubert's job after John left. Libby Gruppuso was originally assigned to the Payroll/Personnel project and eventually grew into supervising that effort, then assumed Ed Hollenbeck's position many years later after Ed left the University. Lynne Personius was another competent female that joined the organization, before she later transferred several years later to the Registrar's Office to coordinate their data processing efforts.
I was instrumental in hiring many of those people or in redirecting their efforts. One of the rewards I have had since leaving Cornell was to run into these people in the community and to receive a warm greeting. Recently at my 40th college reunion, for example, I ran into Al Seliga (one of the junior staff during my tenure at Cornell). He just wanted to say hello and tell me that he thought I was one of the best managers they ever had at Cornell. Obviously it's a good feeling to have your previous staff say things like that years later.
Another interesting person was Tom Dimock. Coming from the aerospace industry where you hired and rewarded competence, I remember approving the hiring of this young kid, who was best described as a "hippie" in those days. But he was a very capable young programmer -- equivalent of a young Internet hacker today --so we kept him in a corner working on R&D projects like some of the first telecomputing experiments and similar efforts. Hiring Tom raised many eyebrows because he was "different", but Tom had the right kind of skills and the eagerness to pursue these things and apparently has remained a good asset to Cornell for the past twenty-some years.
A lot of these individuals eventually worked their way up through various management positions and had a significant continuing influence on computing at Cornell. Some others I approved hiring were Mark Mara and Rick Jones. There also was Paul Wetterau, a program specification analyst who was the first person we hired with experience at another university (Lehigh).
When we were able to hire new people, I insisted that we attempt to bring in people who had either data processing skills associated with designing and implementing management information systems, or who were eager and trainable. In most cases we were successful, even though our budget limitations restricted the choices of expertise that we could afford to hire.
Office Space & Locations:
When I came to Cornell, the administrative computing organization was co-located
out at Langmuir Labs next to the airport, with the mainframe computer. I also
inherited the Institutional Research organization located on campus in the
basement of Day Hall. Because Bill Tetlow had recently left, my initial office
location became his old location in Day Hall.
Clearly I had the problem of an organization split into two parts separated geographically by several miles. We constantly tried to get Cornell to recognize this dilemma and to solve the problem, but on-campus administrative space was at a premium. In about 1972 or 1973, VP Tom Mackesey was persuaded, prior to his retirement, to give us the majority of the second floor of Rand Hall as a way of getting our administrative computing programmers and analysts located on campus. Rand Hall was a place within walking distance of our customers in Day Hall, and we did a low cost conversion of that space to include office cubicles and a remote batch job entry terminal.
Several years later, the Undergraduate Admissions Office moved out of Day Hall and into an old fraternity on Wait Avenue. That move freed up some space in Day Hall, and we were able to renovate some the basement areas and finally move together for the first time.
(Rudan noted that at about that same time, the OCS Production staff was moved back into the Day Hall basement with the old 1401 computer room becoming the space for the remote job entry terminal and other equipment.)
Make or Buy Solutions:
The University was hesitant for many reasons, to invest more money into
administrative computing activities. There also was the political problem that
the University was a series of princedoms, or loosely affiliated organizations
ruled by strong-willed individuals. As a result, you had people in separate
areas such as the Public Affairs, Payroll, or whatever that wanted to control
their own destinies. Each area would fight to protect their current assets
and systems, and were constantly lobbying the Executive Staff (and their
faculty friends) to be allowed to build and maintain their own information
systems. I obviously had to resist much of these pressures if we were to be
able to build an integrated management information system, but I also knew that
with careful planning some of this could be tolerated. I had seen my previous
employer, TRW, have a corporate legal staff that was centralized in California
but then also had a corporate lawyer assigned to the Washington office that
reported to both the manager of the Washington office and to the corporate
legal staff in California. I knew these arrangements could be workable, but
their success also depended upon the cooperation and personalities involved.
After we successfully completed the implementation of an integrated campus-wide Payroll / Personnel system, and of a centralized student billing system, finding a better solution for the remaining areas of student records became a high priority. The problem, however, was that when Byron McCalmon, one of the outspoken young people in that area, was promoted to Registrar, he wanted to do things his way and to hire an outside company's solution and to bypass my office.
Let me backtrack first, however, and discuss an earlier problem and its resolution that had affected everyone's thinking. When I came and we began studying some student billing problems, I discovered that the University had over 50 different organizations that were sending bills to and collecting money from students or their parents. For example, if you didn't return towels at Teagle Hall, the Athletics Department would bill you; or if you didn't pay your overdue book fines, you'd get a bill from the Library. Each of these departments maintained their own billing procedures, most of which were manual, and each attempted to collect their own receivables. This caused a lot of duplication of efforts in various university departments, and also caused confusion to the bill recipients because these bills arrived at different times, and varying rules were used to coerce payments of these charges.
Because it was reasonably apparent to any outsider that these activities could easily be handled by most off-the-shelf standard commercial accounts receivable billing systems, I insisted that we study several. We then recommended purchasing one for something like five thousand dollars. This new "Bursar Billing System", as it became known, was the first time that Cornell ever, to my knowledge, acquired a commercially developed software package to run an administrative process of the University.
Because of the politics involved, plus the new concept being introduced of having a debt owed to the university rather than to a department, it was decided to seek approval of the University Trustees before implementing such drastically changed policies. Under the new arrangement, each of these departments would transfer their qualified bill to the existing Bursar's Office who had already been collecting tuition, and that office would then pay the participating department instantly. The Bursar's Office would then be responsible for billing the student's parent and for collecting the money. There also were interesting policy questions about permitting parents to defer paying part of their tuition bill, and should students be issued credit cards for use at University facilities ranging from the Athletics Department to Dining.
It turned out that one of the senior Trustees was a Vice-President of J. C. Penney (the department store chain), so a description of the problem and our proposed solution was sent to their appropriate staff for review and comment. They decided that it was a good idea and based upon the strength of their recommendations, the Trustees even approved the concept of issuing student credit cards so that students could learn how to deal with credit cards. So, to the surprise of many, the Trustees gave a ringing endorsement of adopting a modern centralized billing system and gave permission for parents to pay tuition over time -- with interest payments, of course.
After the chosen commercial billing system was quickly and effortlessly implemented, the concept of buying solutions developed elsewhere became widely considered. Knowing this, the new Registrar began doing his own investigations of student records systems being used elsewhere that had been developed by commercial firms. He did this investigation without our initial knowledge, and in an effort to build his own empire. He also thought that his new "friends" were more competent than my staff and whom he believed was too busy to really understand his department's needs. By the time we became involved, the Registrar already had selected a favorite company, SCT, and we were asked to review and to endorse his plan.
We talked to other institutions where SCT had worked, and talked in depth with SCT's management and technical people. Unfortunately, what I saw was that this company's underlying technology was "a house of cards", and they had been selling their solution to other institutions through good "used car salesmanship" (for lack of better words). Behind the scenes, however, we repeatedly found significant problems whenever and wherever their "system" had been implemented. I therefore resisted the selection of SCT and took a pretty firm position that this was not a competent organization on which to bet the University's future.
This stance ruffled a few feathers and the politics got emotional on all sides. Based upon the insistence of the Registrar and his academic friends, the University did go with SCT, and it became a fiasco. Eventually their contract was terminated, and many years later the guy who was head of the company (Fred Gross) even was indicted and sent to jail for stock fraud activities. I still have vivid memories of holding a negotiating session with this guy in my dining room one evening, along with Ralph Barnard from the University Counsel's office. Although my opinions were proven right when the University had to terminate the SCT contract, these wasted efforts were visible on campus and were often cited later by the faculty who were concerned about excessive administrative costs.
"Hard" vs. "Soft" Money for Computing:
Another area worth discussing is the concept of "soft money". This is a
difficult-to-explain factor that has often colored people's perceptions of the
cost of doing computing at Cornell. This phenomenon came about because of the
need to bill the federal government at standardized rates that were identical
to the rates paid by other users of OCS, the university's centralized
"computing utility". These rates were determined by taking the estimated OCS
operating costs and dividing the bill by the number of estimated hours (and
units) of usage. These derived rates were then reviewed and approved by the
resident government auditors for use in billing the various government research
activities being performed at the University. Every computing user had to pay
the same rates, however, so the administration issued us something comparable
to meal plan tickets that we could use only to eat at this OCS computing
cafeteria.
From the perspective of the administrative (and non-research academic users), this was not "real" money. Administrative users might be spending a million dollars per year on computing at OCS, but it was money the University would be spending anyway to cover OCS's budget. It was not fungible money and you couldn't hire staff with it, nor spend the money elsewhere, so there was no incentive to attempt to reduce these numbers. Unfortunately these often-misunderstood numbers were quoted as an example of the high costs of doing administrative computing.
This was very frustrating to those of us outside of OCS because we couldn't control these rates, were not permitted to buy computing power elsewhere, nor to acquire a separate specialized administrative mainframe computer, or 'mini' (or later 'micro') computers for use within the university's administrative offices. As I recall the numbers, Public Affairs was spending something like $250,000 a year at OCS in those days to churn out alumni pledge cards and this kind of stuff. By today's standards those costs look fairly exorbitant because you can store and process many of those same records on a powerful desktop computer costing about $3000. But costs were higher in those days, of course -- because computing resources were more expensive back then and in addition, the processes then in use required considerably more manual labor and printed (and punched) paper output.
Another interesting problem that occurred during my tenure at Cornell was the development of a specialized data processing system within and unique to the needs of the University's Dining Department. Because this department was one of the few University departments that had to operate under reported profit and loss accountability rules, they operated quite independently of other university activities and with little oversight as long as they were profitable and their customers weren't complaining publicly.
The manager of Dining, Art Jaeger, quietly hired some student programmers to develop and implement a data processing system to help him better manage the costs of purchasing and preparing food in the university's dining facilities. He apparently also had the intent of creating a private company based upon these activities, and of personally earning more money for himself and others through those efforts. There were no university rules that governed this kind of behavior at that time. [The company that was formed, CBORD, eventually became quite successful in refining and marketing a food management system that had been initially developed using university funds. Jaeger left both the University and that company several years after CBORD's founding, and CBORD was then taken over by John Alexander, one of the student programmers originally involved, but who was now no longer associated with the University.]
By the time the situation came to the attention of senior management, Jaeger's company had been formed and his boss had given verbal permission for this new company to get all of the intellectual rights to those efforts in exchange for providing the University with a free copy of the software. The University Counsel's office and I were asked to define an appropriate contract to be signed.
Based upon both of our prior experiences in industry, the assigned Associate Counsel and I (as well as some others) objected rather strenuously. But because the University had no written policies covering ownership of intellectual policy by either academics or administrators, the University did proceed to give away thousands of dollars of potential royalty income. While Cornell subsequently clarified many details in this murky area, uncertainties remain today in some areas. For example, who owns faculty lecture notes, the broadcast rights to faculty lectures, etc?
Reining in Administrative Costs:
Finally, I ought to go back and discuss the circumstances that led up to my
departure from Cornell.
I talked earlier about the financial simulation models we had developed. Using these, we could look at and predict what would happen financially to the University under different policies. After numerous iterations, our basic conclusion was that the University could survive any set of reasonable policy decisions, as long as revenues and expenses were "indexed" to the Consumer Price Index (i.e.- changed almost automatically in direct relation to a commonly used measure of the actual inflation rate).
In contrast, Stanford University made the decision to aggressively raise student tuition rates at 2 or 3% more than the overall consumer inflation rate. This gave Stanford lots of badly needed additional money that they could use to develop management information systems, hire more faculty, and build new facilities.
Meanwhile, all of our modeling simulations showed that any University President either had to raise student tuition, hold down operating costs, or increase the number of students. Those were the only real choices available. For what he perceived to be many good reasons, Cornell President Dale Corson specifically made the decision to not increase the size of the Cornell student body, nor to increase student tuition at any more than the inflation rate. Although we could (and did) predict the effects of these policies, those were the President's decisions.
Our simulations also showed that if you didn't increase the number of students, or raise tuition faster than the inflation rate, and that if the President couldn't prevent expenses from escalating faster than the inflation rate, then there would be a financial disaster. Unfortunately, this became the scenario at Cornell, and the university began to develop severe financial problems over the next few years. The faculty then became concerned when there were inadequate funds to give them the pay raises they felt they deserved, and so many faculty began publicly complaining about the "runaway" costs of the administration.
Eventually President Corson bowed to these complaints and appointed a faculty-dominated "kangaroo court" (the MacNeil Taskforce) to investigate the perceived waste. The inevitable resulting report, based upon a lot of mis-understanding and half examination of the facts, resulted in "exposes" and pressures on the President to severely cut administrative costs. There were many people like Peter Stein (an infamous Physics professor who later became Dean of the Faculty for several years), who made the remark in one of the Inquisition meetings discussing administrative computing: "We faculty haven't changed our teaching methods for 20 years, I don't understand why the administration wants to change the way they do things?" This was a telling description of the emotions of the times and the general differences in outlook between the faculty and the administration.
As the political pressures for more administrative cutbacks increased, my "Management Systems" area became one of the focuses because data was uncovered showing that this organization was new in 1970, but now had 30 employees. Even though it was pointed out that the organization really only had grown about 20% in size over the intervening six years (because it had started with resources transferred from other entities), the outspoken faculty critics chose to neglect these facts.
Sam Lawrence, the VP for Administration then made the decision to emasculate my organization, without objection from the President. By doing this and other cutbacks in the administration they appeased the faculty, but then merely transferred many of the resources back into the budgets of other more defensible organizations like the Registrar and Personnel Offices. I was ordered to reduce my staff by about 50%.
In this downsizing, I did my best to preserve those employees who were the most technically competent. After transfers and voluntary resignations, I still had the unpleasant task of having to layoff 5 or 6 people. Several minorities were selected for layoff, because of their relative lack of experience and being more recent hires. These potential layoffs included a black African-American male and an oriental female. Those specific decisions were appealed through the Affirmative Action Program and we had to go through formal hearings. All of my decisions were eventually upheld and many people, including the black male involved, later acknowledged that I had made the right decisions. But the decisions and appeals didn't make the administration less visible on campus.
In order to better protect his own vulnerability for poor decision-making, VP for Administration (Lawrence), with the concurrence of his new boss, the Executive VP for Administration (Herbster), decided to make me a scapegoat, and I subsequently was informed that my position was being eliminated. Several members of the Executive Staff attempted to get this decision reversed, but the decision was allowed to stand. Later both Lawrence and Herbster left the University under similar circumstances. This "McCarthyism" series of events, may have even contributed to President Corson's decision to step down after the Trustees became concerned about the resulting unrest on campus.
My Visions & Legacy:
Faced with the need to find employment within about four months, I updated my
resume. Although I received some interesting offers that required moving from
Ithaca, I finally decided to take a major risk and start a drastically new type
of business in the Ithaca area where my family was content. During my tenure
at Cornell, I had seen an interesting phenomenon when we had used that small
portable terminal in the Provost's office doing simulations - even senior
management people enjoyed using desktop computing technology.
In May 1977, I announced that I was going to leave Cornell to follow my own vision for the future directions of computing: I would start an Ithaca-based business to sell and service these new small desktop computing devices called microcomputers. Most people thought I was crazy at the time, but over the subsequent years the business became very successful and rewarded me financially much better than if I had remained at Cornell.
It also was personally rewarding over the next two decades to remain in town and have many former colleagues acknowledge the soundness of my previously stated visions for the future at Cornell. This was particularly true in two areas: my long-range projections for the university's tuition charges and average faculty salaries (both of which had been widely criticized by some outspoken faculty critics), and on my strong insistence that it was necessary to provide administrative users with the tools that permitted them to interactively access computing power while working in their own offices.
I also feel that I contributed to my alma mater by creating Cornellıs first professional management information systems organization. A legacy where talented individuals were hired, trained, and promoted in an environment in which they could openly discuss technical options without fear of reprisal.
Perhaps I also indirectly contributed to the improvement of "management" at Cornell and many other major universities. Individuals that my staff and I had worked with closely during my days at Cornell later moved on to bigger and better positions in higher education. Cornell's Provost Bob Plane later become President of Clarkson University (and Wells College), Plane's successor as Provost (Dave Knapp) later became the President of the University of Massachusetts, and a young assistant professor (Don Randel) in the Department of Music eventually served as the Provost of Cornell before departing last month to become the President of the University of Chicago.
Future Directions for Technology at Cornell:
One last subject worth discussing is the issue of how Cornell dealt with changes
suggested by evolving technology. A particularly interesting and perpetual
question during both of our tenures at Cornell was that of centralized vs.
decentralized computing. In many ways, this issue boils down to the current
and projected economics of communications power vs. computing power.
Initially, Cornell had centralized computing because the technology didn't exist to support decentralized access or linkages between computers. Later technology changed, but the centralists always won the argument because the costs per transaction decreased with larger computers. Hence, it was always cheaper to have the biggest possible computer installed in one place to support everyone and Cornell always seemed to have budget restrictions. The primary $flaw with the centralization argument, of course, is that it ignores the real additional costs in staff time that are incurred by the other organizations to access this computing power. It also ignored the modern mantra of emphasizing customer service.
When mini-computers became available, some outspoken faculty members who received funding from government research grant funds began solving this accessibility problem by acquiring their own mini-computers and support staff. The University Computing Board (UCB) was established at this time in an attempt to better coordinate this evolving direction of computing. But the University had a large investment in its existing infrastructure, and citing the mantra of centralized cost-savings, OCS was able to resist decentralization attempts by others that didn't have access to their own outside funding. This was the computing environment I dealt with during my career at Cornell.
If funding had been provided to OCS, and if it had had the political willingness to do so, a gradual switch to a more decentralized computing environment might have been accomplished. Instead, Cornell computing users, both administrative and academic, became increasingly frustrated by their perceptions of OCS's resistance to change.
By the early eighties, the economics had changed so dramatically that anyone could purchase a desktop computer for about $3000 that was more powerful than the mainframe acquired by Cornell in the mid-seventies for several million dollars. Frustrated computing users at Cornell then began using their department's office supply budgets to purchase these inexpensive computers directly from outside vendors like my local company.
Technology changes constantly, and even though Cornell eventually embraced a decentralized computing philosophy, it may have to react again. Communications costs have decreased significantly in the last few years because of the widespread adoption of fiber optic cables and the deregulation of the communications industry. After it finally recognized the reality of these trends, Cornell was a pioneer in establishing a campus-wide fiber optic cabling system to link its decentralized computer users and telephones.
Now the amount of communications across the campus, and between the campus and the outside world has escalated dramatically due to these reduced costs, and the advent of the Internet World-Wide-Web. Although the costs of decentralized hardware remain very low, the overall economics are rapidly shifting back towards favoring a more centralized computing philosophy. This is happening because of the need to have extremely powerful mainframe-like servers that can handle the volume of communications flowing over the Internet -- and the inherent need for reliability and automatic backup and recovery procedures that are not easily handled on a decentralized basis. Cornell is again coming to a computing crossroads.
Based on my experience during the past thirty years, I believe that the only effective solution is for Cornell computing to constantly evolve with the changes dictated by the marketplace. This means that the university must be willing to constantly fund some experimentation with the latest technological achievements. In cooperation with its customers, the centralized computing organization must also then become an "early implementer" of appropriate new computing and communications technologies. If it fails to do so, rigid organizational barriers and policies will be re-built and deter the evolution of computing at Cornell in a manner that best meets the ever-changing needs of users, both administrative and academic.
[Recorded by John Rudan on 7/13/2000, and later edited by Henry Vaughan]