lib-MOCS-KMC364-20140103102106 27 PERSONNEL ASPECTS OF LIBRARY AUTOMATION David C. WEBER: Director of Libraries, Stanford University, Stanford, California Personnel of an automation project is discussed in terms of talents needed in the design team, their qualifications and organization, the attitudes to be fostered, and the communication and documentation that is important for effective teamwork. Discussion is based on Stanford University's ex- perience with Protect BALLOTS and includes comments on some specific problems which have personnel importance and may be faced in major design efforts. No operation is any better than its rersonnel. The selection, encourage- ment, motivation and advancement o the individuals who operate libraries or library automation programs are the critical elements in the success of automation. The following observations are based upon experience at Stanford Uni- versity over the past eight years in applying data processing to libraries, and particularly in the large scale on-line experience of Project BALLOTS (an acronym standing for Bibliographic Automation of Large Library Operations using a Time Sharing System) supported by the U. S. Office of Education Bureau of Research during the past three years. The first par! of the paper treats of five key personnel aspects: the automation team, thetr qualifications, their organization, the climate for effort, and docu- mentation. 28 Journal of Library Automation Vol. 4/1 March, 1971 THE TEAM Experts are required for the design of any computer system or system based on other sophisticated equipment and they must emphatically form a "team" to be effective. The group may include a statistician and/or financial expert, a systems analyst, a systems designer, a systems program- mer, a computer applications programmer, and a librarian. There may be several persons of each type, or one person may assume more than one responsibility. A few universities have librarians who have received train- ing in systems analysis or in programming. The computer related profes- sions are, however, demanding in themselves, and especially so when the programming language may change with each generation of computers. It is therefore usual for the head librarian to work with experts located in a systems office, an administrative dataJrocessing center, or a computation center. Except for the librarians, few · any of the experts may be on the library payroll, although in a very large project all may be financed from one or two accounts in the library. The team must cover the variety of functions encompassed in a formal system development process. These functions are enumerated in detail in Stanford's project documentation ( 1), but a brief summary of typical functions performed by the team may indicate its diversity. There is the analysis of existing library operations, conceptual design of what is desired under an automated system, form and other output design, review of pub- lished literature and on-site analysis of selected efforts of a related nature; determination of machine configuration to support the system design, study of machine efficiency, and reliability of main frame plus peripheral equipment; choice of programming language, checkout and debugging of programs; cost effectiveness study, study of present manpower conversion, analysis of space requirements and equipment changes; staff training pro- grams with manuals or computer aided instruction, system documentation and publicity; systems programming and applications programming, and project management. The total effort is collaborative; the system is de- signed by and with the users of it (i.e., library staff), not for them, and a tremendous contribution of local staff time is essential to success. In many instances an institution will have some, but not all, of these resources and capabilities in adequate amount. If amount is insufficient, the project director must determine how, through consultants or change of project course, a needed talent can be obtained or bypassed. The conse- quences of each mix of talent and change of strategy need assessment at frequent intervals; reassessment must be done with the full participation of the most senior library officers, including the Director of Libraries, as well as certain other key university officers. At Stanford, the group has for three years comprised diverse talent and worked reasonably well as a team. The Library has recently delegated to the Director of the Computation Center the immediate project management of BALLOTS and SPIRES ( 2) (Stanford Public Information Retrieval Personnel Aspects of Automation/ WEBER 29 System). Thus the current combined staff of twenty-three, which should reach a peak of twenty-five during 1971, reports to the BALLOTS-SPIRES Project Director. He in turn reports both to the Director of the Computa- tion Center in a direct relationship and, under his second hat as Chief of the Library Automation Department, to the Assistant Director of Libraries for Bibliographic Operations in a dotted-line relationship. See Table 1 for Stanford's diversity of staff. Table 1. Staff of Project BALLOTS-1970 Title or Age Degree Years of Years on Classification Experience Project Project Director 36 BS, CE 15 1 Special Assistant 40 BS 12 2 Senior System Programmer 37 BA 8 1 System Programmer 36 BS 14 3 Manager Technical Development 29 BS 5 2 System Services Manager 30 BA 8 2 Librarian 11/System Analyst 28 BA, MLS 3 3 Librarian/System Analyst 27 BA, MLS 2 <1 Project Documentation 35 BA, MLS 3 1 Editor Assistant 26 MA 3 <1 System Analyst 27 BA, MA 5 1 Junior System Analyst 25 BA 2 2 Programmer Trainee 26 1 1 Programmer 30 AA 7 3 Programmer 26 BA 4 1 Programmer 32 BS 11 <1 Programmer 28 BS 7 <1 Research Assistant 27 BS, MS, PhD 4 3 Research Assistant 28 BA, LLB 8 2 Research Assistant 22 BA 3 2 Research Assistant 24 BA 4 2 Senior Secretary 27 8 1 Secretary 19 1 1 In development of library automation or of any sophisticated data processing system, it is essential to utilize librarians and other system users to the utmost in constructing the design. There is evidence that an effective program of library automation results from on-campus development: that is, using a local staff with librarians working on a daily basis with system ~alysts, programmers, and information scientists. Librarians most defin- Itely should not try to do it all themselves; that would be sheer folly and w~uld reveal a lamentable lack of appreciation of the highly complex sktlls of the other professionals working in the information sciences. L 30 Journal of Library Automation Vol. 4/1 March, 1971 Team Qualifications A qualified and enthusiastic team with strong backing from the library administration is the most important single element in a library's automa- tion eHorts. This requires that the library administrator have a grasp of the intricacies, although he himself will probably not understand all details involved in the system design. It also requires consideration of the desire for advancement of those in computer refated professions and the various characteristics of their career/attems, including training, experience, job market, salary potentials, an mobility. The team will need to be selected with care and joint eHort by computer staH and library staH management. People are needed who can teach and learn from one another. They must be tolerant, and interested in problems and details, for they will be changing traditional systems, altering people's work habits, and probably shaking their self-confidence. Security comes from knowing the facts and being able to work on the new system-to be in part responsible for one's own future. Team harmony of eHort can be promoted by the so-called "bridge professional", or what the sociologists call a "marginal professional", meaning one who is able to assist those in one profession to converse and work eHectively with those in another. At Stanford the librarian/analysts and the project editor have been eHective in such a capacity. Those in the computer related professions, along with all on the library staH, need a sense of purpose, a sense of achievement, and recognition of their contributions by superiors as well as peers. The automation team needs a competent, experienced, technically knowledgeable, and tactful captain. He must manage with an appreciation for communication, a knack for touching base with various groups having interests in the eHort, the judgment to assign reasonable tasks, and the realism to set and achieve feasible time schedules-all within budget limi- tations. If the leader is less than this paragon, others in the organization must provide these qualities, all of which are required. For at least another decade it is likely that the expert analyst andjro- grammer will receive as high a salary as a librarian division hea or assistant department chief, and a highly qualified systems designer may well earn more than any chief and perhaps as much as the assistant director of libraries. The scale is not irrational or unjust; it merely recognizes the scarcity of particular talents and their importance to major library automa- tion programs. Designing an on-line library system requires a person of proven competence in on-line systems. A salary oHer shaved here may well lead to regret. Experience in Project BALLOTS points up problems with the selection of personnel who are not library trained. Some persons may be excellent in theoretical development but poor as managers, or some may play a "campus politics" game in order to move into senior positions in the computation center. Computer specialists have diHerent career goals than do librarians, and rarely see the library as a permanent career commitment Personnel Aspects of Automation/WEBER 31 by which to promote library automation; rather their commitment is toward automation and computer applications, not a particular section of the university. A project manager also needs to take great care that research does not become an end in itself, a particular tendency of graduate students doing system development. Implementation must be the goal of library automation; automated operations must be sound, efficient, dependable, and economical. Some of the special needs and working conditions for personnel in an automated program are outlined by Allen B. Veaner (3). Team Organization The organizational unit of an automation program may be first an office, then later a division when the group is farger and the function more permanent. The staff of a major project should have a departmental status equal to that of the acquisition or cataloging department. These latter two departments may be combined with an automation department under an assistant or associate director for technical processing. However, it is a rare individual who can give adequate attention to both the complexities of a major traditional library function and the direction of a major research and development program. Thus the initial organizational pattern may be one of separate but equal status, and at some point in time the units may be combined under one administrator. See Figure 1 for Stanford's new organization adopted after three years of eHort, as it entered the production- engineered phase. Units may best be combined when a research and development project begins to take on a significant amount of operational work. The reason is that the person in charge of the system development may need to oversee its implementation in order to assure that standards are followed for data preparation, coding, and the details of forms; and that feedback of experience for system improvement is secured. This combination of units should not be achieved when the rroject is still in the development stage, but it should also not wait unti operations are well under way. Some anticipation is desirable. In the medium-scale program such com- bination of units may be possible after a year of operation, or the con- tinuing production may be assumed by a traditional department and the systems office left free for further experimentation and development work. Production is normally the responsibility of traditional departments and ~om the day of implementation; the automation department responsibility IS for instructing in system use, debugging of programs, and fine tuning of the system. In a large project striving toward an integrated system for all technical processes and public services, the transfer of responsibilities to traditional departments may come in no less than three years and perhaps as many as five years from the origin of the project because of c_onstant developments in software and hardware, developments which library users cannot control but to which they must be responsive. An ~ DIRECTOR, STANFORD : UNIVERSITY LIBRARJES e the .r.LOTS : : BALLOTS: PRIN:CIPAL INVESTIGATOR and Assistant Director of Libraries for Bibliographic Operations I LIBRARY SYSTEMS I DESIGN COM!HTTEE I I I I SYSTEM SERVICES MANAGER 4-LIBRARY SYSTE~lS 2-SYSTEM PROGRAMMERS ANALYSTS (incl. 2 librarians) Age = 27 years Degrees = 1t (a)Exper = 3 years (b)Proj = 2 years Age = 37 years Degrees = 1 Exper = 11 years )?roj = 2 years (a) Professional experience in EDP systems (b) Time with the BALLOTS/SPIRES Project DIRECTOR, STANFORD VICE PRESIDENT COMPUTATION CENTER FOR RESEARCH PROJECT DIRECTOR SPIRES: PRINCIPAL INVESTIGATOR SPIRES/BALLOTS - and Professor of the and Chief of the Library's Department of Communication Automation Department 6-APPLICATIONS + 4-GRADUATE PROGRAMMERS SruDENTS (full time) (part time ) - 26 years 2 Age = 31 years Degrees = 1 Exper = 71- years - Proj = l year 4 years 2 years PROJECT DOCUMENTATION 2-EDITORS Age = 30 years Degrees = 2 Exper = 3 years Proj = 1 year Fig. 1. BALLOTS/SPIRES Organization-1970. ~ 'c' ~ ~ ..... .Q.. t-t 5:- j ~ c ~ ;; c· ;$ ~ ~ -~ ~ i ..... ~ ..... Personnel Aspects of Automation/WEBER 33 automation division or systems office would remain to take care of the refinements, maintenance, and development of further applications which are a result of the open-ended nature of a major automation program. THE CLIMATE FOR EFFORT If the librarian is to work effectively with all of the previously mentioned experts, he must become more than superficially familiar with the equip- ment and with the software which instructs it. The librarian who carries the responsibility for major mechanized data processing programs will probably have taken at least half a dozen courses in various aspects of data processing in order to be able to state reasonable requirements, to compre- hend economic and technical limitations, discuss file organization problems with the systems designer, and be sufficiently informed to help explain the new system to the library staff that will operate or make use of it. This type of specialized training will also be necessary for other team members who will work with different parts of the system. A number of librarians will need to take several short courses selected for their early relevance to the work at hand. Staff may take courses offered in the uni- versity computer science department, by the computation center, or by a local computer firm. Various clerical personnel will need briefing ses- sions, and it will be necessary to train some typists to serve as skilled terminal operators. Indeed, training will be needed on a continuing basis as more staff use the system; manuals are important unless self-instruction is built in. These efforts are desirable because the employee needs assurance that his talents will not be outdated and he be laid off as a consequence; rather that he will be retrained to the new system, shown that its function is not totally different from the previous one, and shown that it can actually serve him and lead to enhanced satisfaction and improved salary in his library employment. Computer based systems are far more likely to upgrade librarianship than to make it obsolete. They will enhance the profession by eliminating its routine drudgery, and thus more sharply identify its really professional nature. Don R. Swanson has commented on this point: "Those librarians who have some kind of irrational antipathy toward mechanization per se (not just toward some engineers who have in- appropriately oversold mechanization) I regard with some suspicion because I think they do not have sufficient respect for their profession. They may be afraid that librarianship is going to be exposed as being intellectually vacuous, which I don't think is so. Even in a completely mechanized library there would still be need for skilled reference librar- ians, bibliographers, catalogers, acquisitions specialists, administrators, and others. Those librarians in the future who regard mechanization, not with suspicion, but as a subject to be mastered will be those who will plan our future libraries and who will plan the things that machines are going to do. There will be no doubt of their professional status." ( 4) 34 Journal of Library Automation Vol. 4/1 March, 1971 Persons who have inhibitions about machine based systems will not be effective members of the design and development group. Those receptive to the change will benefit by having their job horizons enlarged and their prospects for improved salary and personnel classification enhanced. They will also share in the enthusiasm inspired by a bold new enterprise. This is not to say that all library staff members will enjoy the exacting refine- ments of a machine system, just as not everyone has talent to be a first-rate cataloger. It is not suited to everyone, and therefore the nature and purpose of the system must be clearly explained or demonstrated to anyone interested in such an assignment lest he accept it and then become disen- chanted with the work. The importance cannot be overstated of telling the entire library staff what is being done in regard to automation-and why. Disquieting rumors will abound in the absence of full and candid communication. Staff meet- ings should be held to review progress and outline next steps. Staff bulletins should publish summaries of the program and reports on its current status, information that can also be useful for faculty and staff outside the library. It must not be forgotten that the card catalog, the manual circulation system, and common order forms are familiar to all students and faculty. Most students will have seen these in their high school or public libraries, yet few will have seen a sophisticated machine system, and will often be skeptical about its efficiency and dependability. Faculty members may well wonder whether it is worth the cost. The effort to explain a program concisely but clearly to the library staff, students, faculty, and other university staff can be highly rewarding in understanding, and in moral and financial support. Columbia University's experience with library automation has led them to state that .. though the hardware and software programs associated with computer technology are formidable, they are not the only (and possibly not even the most impor- tant) problems in an automation effort. Two areas often overlooked or grossly underestimated are: 1 ) Creating an environment hospitable to change [and] especially important in this area is staff training and organi- zation. 2) Describing and analyzing existing manual procedures sufficiently before attempting to design automated systems." (5) DOCUMENTATION The documentation of any new system is of singular importance. There is an oral tradition in most libraries; techniques of filing or searching are passed on by the supervisor, although libraries use staff manuals to formalize some of the techniques. However, in a system where absolute exactitude is demanded and where costs of system development are high, methodical recording of principles and procedures is obviously necessary. Especially vital are details of design and programming, for purposes of debugging, maintenance, and transfer to others. Personnel Aspects of Automation/WEBER 35 CRITICAL PERSONNEL ISSUES In an important statement from Massachusetts Institute of Technology's Project MAC in 1968, Professor F. J. Corbat6 outlines fifteen critical issues ranging from technical to managerial that affect the complexity and diffi- culty of constructing computer systems to serve multiple users ( 6). Seven of the fifteen have substantial personnel aspects; experience with Project BALLOTS provides the basis for the following comments on them. 1) "The first danger signal is when the designers of the system won't document. They don't want to be bothered trying to write out in words what they intend to do." Stanford's experience might not put this as a first critical issue, yet it is evident that without adequate and clear documenta- tion the advancement of any research or development project is jeopardized. One expert, an invaluable member of the BALLOTS team, has full respon- sibility for this very important task. The position requires adequate clerical support; there are one-and-a-half assistants on the BALLOTS team. 2) "The second danger signal is when designers won't or can't implement. What is referred to here is the lofty designer who sketches out on a blackboard one day his great ideas and then turns the job over to coders to finish many months later." Stanford has experienced some of the seduc- tiveness of design innovations, especially on the part of graduate student research assistants. (Yet these assistants have done excellent work and it is wished they were all full time on the project. ) Without constant review and the use of PERT charts or other scheduling, shying away from imple- mentation can be a real hazard. There will be dark days when the design team cannot surmount some intractable but crucial obstacle, and tne project manager and staH librarians working with the team must be sympathetic, encouraging and patient. 3) "The next danger signal is when the design needs more than ten people. This doesn't mean that all the support people . . . must add up to no more than ten. But when the crucial kernel of the design team is more than ten people, a larger scale project is coming into being. This is the point where communication problems begin to develop." Stanford has flirted with that particular danger point. With acquisition and catalog- ing staff included, the BALLOTS design group is over ten and there is a communication problem, but one due not so much to size as to different backgrounds, vocabulary and scheduling of effort. The need for communi- cation has been intensified because the Main Library is over half a mile from the Computation Center. It has required monthly staff meetings at early stages of design, and late stages of development, and at other times weekly staff meetings of the design group with the librarians who are ~etting the design criteria. Failure of constant and accurate communication m a research and development effort is a threat to its effective progress. 4) "If a project cannot be finished or made use of in one year, there is potential trouble, because the chances of underestimation are strong (and ) a personnel turnover of roughly 20% per year must be assumed." Stanford's 36 Journal of Library Automation Vol. 4/1 March, 1971 experience would bear this out. There was some time and cost under- estimation. Turnover during 1969-70 was 17%; the year before it was 50%. Obviously documentation then becomes a more critical element in progress, and turnover may lead the librarian to feel that it is sometimes one step backwards for every two steps forward. Turnover may be minimized by generous salary increases, not only once a year but perhaps at other times also when merit deserves reward and as responsibilities increase. In con- trast to customary operations, an automation design effort is constantly changing in nature and emphasis; this fact requires flexibility in personnel management and frequently deserves immediate response in salary and classification administration. To keep a qualified research team in an area of specialization in demand, one must pay the price. Let there be no misunderstanding, a good system of library automation cannot be finished in one year-nor in three; and it is costly. 5) "Another danger signal is when a system is not a line-of-sight system. This means that all of the terminals, consoles, or what-have-you are not in the same room within shouting distance of the operator." Any on-line system like BALLOTS cannot be line-of-sight. Terminals are brought to the users, not users to the terminals. Since an on-line system requires total file recovery through use of log tapes, a facility not available on the prototype system, Stanford has experienced problems when the machine goes down; it takes time to rerun a program or mount a different disk pack; a file was once wiped out; and there are many other users of the central facility, which puts a premium on scheduling, advance notice, backup, and the like. If a design team is not housed in adjacent space, it will take more personnel or time than in a line-of-sight arrangement to achieve the same accomplishment. BALLOTS systems analysts were in the Main Library througbout the early design phases and the systems designers were near the Computation Center. Lack of line-of-sight was a sufficiently severe problem that all of the BALLOTS staff were collocated near the Computa- tion Center last winter as the production engineered phase began. 6) "A somewhat related danger signal is when there are over ten system maintainers. Here I am talking about an on-line system that is actually being maintained on-line." At Stanford no more than one person has worked at one time on the program maintenance of Stanford's four-year- old computer produced Undergraduate Library book catalog. There have been some complexities due to staff changes, changes in the operating system, and an off-campus contract for reprogramming to third-generation equipment, but the problems have not resulted because of the scale of the project. BALLOTS, on the other hand, is twenty to fifty times as large a system, and it is expected that two or three programmers will be needed to maintain the systems software and a similar number to maintain and make minor revisions to the applications software. 7) "The last danger signal is when the system requires the ability to permit combinations of sharing, privacy and control." At Stanford, assign- Personnel Aspects of Automation/ WEBER 37 ment of authority for file access has become a problem-who is permitted to update an acquisition record or authorize payment? The requirement for security also enters in any system which has salary data or other per- sonnel information in files. A whole order of complexity is added. As in many of the above problems, complexity is accentuated when one is developing an on-line interactive system which serves multiple users. Security must be designed to the file level and, later, to the record or even data element level. Security requires control of access to file, of writing in a file, and of updating data through three types of checks: access allowable from a given terminal, from the file password, or from an individual password. Such problems do not exist in off-line systems. CONCLUSION For successful automation of library operations, it is of fundamental importance to choose a task that is appropriate in timing, magnitude of effort, funding, and personnel. The BALLOTS experience demonstrates that one must devote great thought, care, and analysis to choosing the right automation project at the right time, and base it on having well qualified people to direct and accomplish the task. Given suitable conditions it will be a most exciting and fruitful endeavor. The system that works well is a thing of beauty, and people make it so. REFERENCES 1. Stanford University, SPIRES/BALLOTS Project: Project Control Note- book, May 1970. Section 1.4 "System Development Process." 2. Parker, Edwin B.: SPIRES (Stanford Physics Information Retrieval System) 1969-70 Annual Report to the National Science Foundation. (Stanford University: Institute for Communication Research, June 1970). 3. Veaner, Allen B.: "Major Decision Points in Library Automation," College & Research Libraries, 31 (September 1970), 299-312. 4. Swanson, Don R.: "Design Requirements for a Future Library." In Markuson, Barbara Evans, ed.: Libraries and Automation. (Washing- ton: Library of Congress, 1964), p. 21. 5. Columbia University Libraries : Progress Report [to the National Science Foundation on Library Automation] for Jan. 1968-Dec. 1969 (NSF-GN-694). p. 14. 6. Corbat6, Fernando J.: Sensitive Issues in the Design of Multi-Use Systems (Waltham, Massachusetts: Honeywell EDP Technology Cen- ter, Technical Symposium on Advances in Software Technology, Feb- ruary 1968). 17 pp. Project MAC Internal Memo. MAC-M-383.