Library/Computer Centre Joint Projects

Sue.Steele@lib.monash.edu.au - Outline of a talk presented to Dept. of Librarianship Students 8 May 1995

What is a joint project?

Task-splitting

The breakdown usually follows this pattern:

Benefits of joint projects

Drawbacks of joint projects

Some recent joint projects

CWIS

What is a joint project?

Long history of Library/Computer Centre co-operation

The Library has been involved in "library automation" projects for around 30 years. During this time, there has been a lot of co-operation between the Library and the Computer Centre. The Library's expertise has always been in the areas of applications and database creation/maintenance. Initial projects were home-grown but this gradually changed as more and more applications and services became available. The Computer Centre traditionally provided hardware platforms for Library applications, data communications and operational support. The Library did not own the hardware, and some applications used systems shared with other areas of the University. In recent years, this co-operation has been formalised into joint projects undertaken by the Library and the Computer Centre.

Shared venture with agreed responsibilities

The joint projects undertaken by the Library and Computer Centre are generally large projects, with major benefits for the whole University community. In effect senior Library and Computer Centre staff agree which ventures will become joint projects, then agree on the allocation of staff, resources and dollars to the project. Each area commits to certain areas and levels of responsibility, and in most cases to a project plan or timetable. Many of these projects take several years to complete. The size and diversity of the University complicates any comprehensive project, and implementation across all campuses is often staggered as time and resources permit.

Group or committee to oversee

Generally a committee is set up to oversee the implementation phase of the project. For very large projects such as Sesame2, the committee will include representatives from the whole University. Most committees consist of Library and Computer Centre representatives, both people involved in the implementation, and those with an interest in the outcome. Committees may meet regularly , or on an as-needed basis, depending on the nature (and progress) of the project.

Budget

Costs are closely monitored at each stage of the project. A joint-budget (with moneys contributed from both cost centres) may be set up for very large or expensive projects. Generally both cost centres commit themselves to a certain financial contribution to the project, and agree on which items will be purchased with each contribution. Budgets are re-evaluated annually in long projects, as needs (and costs) frequently change.

Task-splitting

Computer Centre and Library staff have different areas of expertise. This leads to a fairly consistent break-down of tasks in most joint projects.

Computer Centre responsibilities

Library responsibilities

Benefits of joint projects

Pooling of resources and expertise

Librarians and library staff generally do not time (nor often the inclination) to develop a great deal of expertise in areas such as computer operations, data communications, systems programming etc. In many instances the Library lacks the computing resources for the development or pilot stages of a project (perhaps before a hardware purchase is undertaken), and the Computer Centre can often provide access to a suitable resource.

Cost-sharing

In some cases the Library could not afford to fully fund a major project without the co-operation and financial assistance of the Computer Centre. This has benefited the Library greatly.

Can save duplication of resources

Placing some library-related systems in the central machine rooms saves space, money (setting up a machine room and an Uninterupptable Power Supply is very expensive), and staff time (operators are already on duty for much of the time the library requires them). Pooling resources means that some non-library resources can be accommodated for little extra overhead in some cases. In others, it means the library can share an existing resource.

Can save time and money

Pilot projects can sometimes commence immediately because sufficient resources already exist. Joint projects can utilise equipment which may have been released though upgrading of some other Computer Centre resource.

Close working relationship

Library and Computer Centre staff involved in joint projects often develop a close working relationship. This has benefits in that the staff involved understand the constraints each group works within, and means the two groups are familiar with the needs of the other in a wider sense.

Drawbacks of joint projects

Long lead time

The formalised approach involved can cause projects to have a long lead time. Sometimes (as in the case of the purchase of a new integrated system) this is appropriate. In other cases, the project may have been set up very quickly if formal committees etc were not included.

Joint control can be a constraint

Getting all the stakeholders together when a quick decision is needed can prove difficult. This is most noticeably a problem if a project is experiencing setbacks.

Possible conflicting priorities

From time to time, the priority assigned to the project by each area seems to differ. The Library usually assigns a very high priority to joint projects. There is a perception, sometimes, that the Computer Centre assigns a lower priority. This is partly due to the constraints on the people involved; for example they may be involved in other projects.

Some recent joint projects

Sesame2

Sesame2 is the University's integrated library system providing the online catalogue, circulation, acquisitions, reserve bookroom and serials control at present. This was a major undertaking and provided the blueprint for further joint projects, although no other project was quite this formalised. In this case, there was a formally constituted University-wide committee to oversee the project, as well as a formal joint budget. The project went through the usual tendering process for large systems purchases, with Library and Computer Centre staff visiting various installations in the US in the final stages of selection.

The Computer Centre is responsible for hardware, networking and system software, the Library is responsible for application software and the various database files. Once the system was operational, the "project" phase was effectively over and the committee disbanded itself. The responsibilities continue, though, and the Library staff responsible for the system are in almost daily contact with Computer Centre staff. There is also a Progress Review Committee, consisting of Library, Computer Centre and System Supplier staff, which meets briefly every 6 to 8 weeks, to discuss problems, upgrade requirements etc.

CD ROM Network

The CD ROM Network is another large-scale project. It involves setting up CD ROM servers, and a network of PCs in every branch library. Initially the Clayton Campus libraries were networked in this way, then Caulfield and Frankston. Finally, the Gippsland Campus library is still in the process of networking CD ROMS. Their project is more complex as it also involves provision for off-campus stuednts.

There is a committee consisting of Library and Computer Centre staff involved in the implementation and ongoing management of the network, and some reference staff who are stakeholders as well. What seemed on paper like a straightforward task has proven much more difficult and complex.

At the moment the file servers live in the Computer Centre on each campus, but this is under review. Maintenance and updating is done by Library staff. The CD ROM networks have undergone several changes during the 3 or so years they have been in operation, and have required far more staff time than originally projected.

Examination papers/Imaging project

Neither Library nor Computer Centre had any expertise in imaging when this project commenced, so the approach was slightly different. A budget was agreed on, and a consultant was employed to undertake the initial development of the system to provide online access to (including for-fee printing) past examination papers. At the end of the project the consultant was to hand-over to a Library staff member who had been trained during the course of the project.

Examination papers were chosen for the pilot phase for two reasons. The University owns the copyright so there are no problems in this area. There was a need to provide better access to examination papers than the "let the students photocopy them from a bound book" approach. The consultant has handed over the project and left the University and the Library is embarking on an expansion of the project to incorporate an "Electronic Reserve Bookroom". The Electronic Reserve project will provide access to recommended reading materials to students at the Berwick Campus in the first instance, and eventually to students at all campuses.

CWIS

Background

During 1992 the Library resolved to become more involved with AARNet and Internet. One aspect of this developed into an AARNet/Internet training program, and led to the creation of the Network Librarian position. Another aspect led to a committment on the part of the Library, to develop a Campus Wide Information Service (CWIS) based around the Internet Gopher. By the end of 1992, the Library and the Computer Centre had agreed on a process to implement a CWIS during 1993.

The Library felt that it had the information-management skills necessary to produce a workable and informative CWIS. This could not be done in isolation as many areas of the University are responsible for information generation and dissemination. Thus, the Library and the Computer Centre invited the groups it considered prime-movers and/or stakeholders to form a group to oversee the development of the CWIS.

Project Committee

Late in 1992, senior Library and Computer Centre staff invited a number of interested parties to meet to work in the implementation of a CWIS. A committee consisting of Library and Computer Centre representatives, the University's Publications Officer, a lecturer from Civil Engineering and a Master's student from the Dept. of Robotics and Digital Technology was formed.

Formally, the committee only met twice, when some guidelines were agreed upon, and it was decided to hire a consultant to speed up the initial implementation process. Informally a number of the committee members were extremely active in the initial stages of the CWIS development, and the Publications group has continued to be an active, and regular, contributor.

Responsibilities

One possible reason for the lack of committe meetings is the relatively cheap (and expedient) way the CWIS was set up. The only costs involved have been staff time (a "spare" machine was contributed by the Computer Centre) and the initial cost of hiring a consultant for 3 days. Computer Centre staff maintain the hardware and software (freeware downloaded via Internet), and the Library is responsible for the menu structure and overall database.

The Computer Centre is responsible for client software maintenance on shared systems and file servers, although Library staff have provided advice regarding suitable clients and configurations from time to time. The Library is responsible for general Internet training to Academic staff and postgraduate students, and has incorporated CWIS training as part of this. In addition, the Library has acted as a point of reference for University departments and individuals who wish to make information available through the CWIS, and has converted important information sources (such as Faculty Handbooks).

Starting up

In early May 1993 a consultant from ANU spent 3 days at Monash. During that time, the initial version of the CWIS (a gopher server) was mounted. A group of enthusiasts spent an afternoon deciding on a top-level menu structure after the software had been installed. Some existing documents were converted to ascii and loaded (mostly these were library-related, with the exception of Etcetera which was uploaded by Publications from the beginning), links to other useful resources were added and by the middle of the third day, the CWIS was ready to demonstrate to library staff.

By the middle of the second week of operation, when more information had been converted, and many links added, it was clear that the initial menu structure was not suitable. It was too specific at the top level. I developed two alternative menu structures and asked for feedback on which would be better. After an underwhelming two responses, I selected the one that 3 people (one of whom was me) felt most comfortable with. The structure has been virtually the same ever since. Note: this level of response is relatively common, I believe. One is more likely to get negative feedback. Positive feedback is quite rare, and constructive suggestions seem to be even less common.

Publicity at this point was through our AARNet training sessions and mostly word-of-mouth. The Computer Centre placed suitable client software on its systems, as did many other departments. There was an official launch in August 1993.

Operations

We try to be as flexible as possible in the ways we develop and maintain information on the CWIS. We have always encouraged university-affiliated groups, departments and factulties to contribute. Unfortunately the gopher server was not really hospitable to distributed maintenance in the wame way that World Wide Web has proved to be. Only 3 or 4 departments within Monash set up their own servers, and the plain text format was not attractive enough to many people, I think. I wrote a brief document outlining how people could get their information into a suitable text format, and the ways we could mount the information onto the server. We encouraged people to send us pre-formatted information on disk or via email. In the case of the Publications office, they had an account on the server and maintained their own data. We also accepted Word and Wordperfect documents if we felt that the information was important enough for us to convert. For really important things such as Faculty Handbooks, we accepted the data as a series of large files, and wrote scripts to produce acceptable-sized files and appropriate menu entries. We also mounted a small number of internet-related documents locally, such as the Yanoff list. We have kept this list small to ensure easy maintenance.

We used the CWIS as the basis of our AARNet/Internet training from November 1993. In early 1994 we ran a CWIS demonstration for "information providers" to encourage the CWIS as a place to mount information. This resulted in several areas providing us with information, eg Sports and Rec and the Student Union.

In June 1994 we commenced the Monash Home Page on world wide web, initially in conjunction with the gopher server, and later almost replacing it, although parts of the gopher are still maintained. Those parts which are not contain notices to that effect with pointers to the appropriate URL.

The effect was almost immediate, even before the www server was official, which took several months. We began to receive regular requests from people to mount their information, or to help them get going.

Growth

This is difficult to measure in the case of the www server, because it is also a proxy server for the firewalled student network at the moment. At the end of 1993, the gopher server averaged about 1200 accesses a day. It now averages over 3000 a day. This has continued to grow slowly, even though we have the www server. The total number of accesses to the www server is something over 50,000 a day - but this figure is distorted because of the images and the proxying.

Certainly the amount of information Monash provides is growing steadily, with very little effort on our part in terms of publicity. The amount of use of the server increased dramatically when Netscape was made available in student labs. We need to load some statistical-analysis software. We also need to do something about the serious overloading of www.monash now that the proxy use is so great. t appears that one machine is not sufficient. Because www is more popular than gopher, and because of the ease of mounting information (and creating servers) we spend more time advising others how to load their information, and less time mounting other people's data (well mostly this is true).