# Presentation: 604848

## The Implementation of an ILSat the Library of Congress

- The Implementation of an ILSat the Library of Congress

- Presentation by
- Erik Delfino
- Assistant Implementation Coordinator
- ILS Program Office
- Library of Congress
*Computers in Libraries, March 2000*

**Notes:**
I’ve been asked to give you an overview of the implementation of the integrated library system at the Library of Congress, a project whose first phase ended last year.
I’ll talk about:
	- the scope of the project
	- some of the lessons learned, including
		what worked well
		what we would do differently
	- current status
	- and where we go from here
Implementing the Integrated Library System was the largest single automation project in the Library’s history.
The project had a number of goals.  Chief among them was the replacement of the half dozen standalone legacy systems that have been developed at the library over the last 30 years.  There were also operational goals, such as improving security of collections and inventory control, as well as making all our systems Y2K compliant.  Following a competitive procurement process, in May 1998 we selected the Voyager system from Endeavor Information Systems.

## Scope of the Project

- Convert 17 million+ records
- 12m bib, 5m authority, 100k patrons/vendors/orders
- Create 20 million holding/item records
- Train 3300 staff
- Replace 2000 workstations
- Complete initial work in 18 months

**Notes:**
To give you an idea of the size of the ILS project --
It involved extracting over 17 million records from our old MUMS catalog system, performing some basic data cleanup on those records, and then loading them into Voyager.  This included 12 million bibliographic records, and 5 million name and subject authorities.  
It also included records for over 20,000 patrons, 30,000 vendors, and 55,000 open orders. 
Over 20 million holdings and item records had to be created from scratch as part of the load process.  This was new territory for us, since our old system did not have true holdings information.  Because of this, we won’t have complete holdings in the catalog until we finish our shelflist conversion.  
We also had to train virtually the entire staff  in the new system, 3300 people including more than 800 catalogers, many of whom had not used a graphic user interface before.  
Finally, we had to replace over 2000 workstations with new Pentium computers.  All of this had to be done within an 18 month schedule.

## Major Milestones

- RFP 97-12 (July - Sept. 1997)
- 800+ requirements
- Vendor selection (May 15, 1998)
- Endeavor Information Systems, Inc.
- System in Production
- Cataloging Day 1 - August 16, 1999
- All Modules Online - October 1, 1999

**Notes:**
Here are some of the major project  milestones.

-- A request for proposal (RFP), consisting of over 800 system requirements, was developed by a number of technical teams in early 1997.  The RFP was issued in July, and review of proposals began in September.
-- The review resulted in a contract award to Endeavor Information Systems for the Voyager ILS system on May 15, 1998.
-- The first module we implemented, Cataloging, went “live” on August 16, 1999.  Circulation came up on the same day.  This was followed by the Public Catalog, and then Acquisitions/Serials on October 1.

In a moment we’ll discuss some of the events between the award of the contract in 1998 and “Day 1” in August 1999.

## Timeline

- Preliminary Implementation Planning

- Initial Implementation

- Initial Implementation Complete

- Implement Secondary Priorities

- Conduct Business Process Improvement

- Proposal Evaluation

- Data Cleanup Projects

- Contract Award

- 1997

- 1998

- 1999

- 2000

- Training

- “Fine-tune” the System

- Shelflist Conversion

- Serials Conversion

**Notes:**
Current status -- Where are we now?  
We’ve passed the initial implementation (the second star on this chart).  All the modules - Cataloging, Circulation, Public Catalog, and Acquisitions/Serials are online.  We are doing all our normal production work in the ILS - input and update of bibliographic, holdings, and authorities records, circulation and ILL transactions, issuing purchase orders and paying invoices.
In our role of maintaining the national authority files, we are up to speed on record contribution and distribution with the bibliographic utilities, NACO partners, and our Cataloging Distribution Service customers.
Over the past 6 months we have retired four of our legacy systems - the MUMS cataloging system, Acquire acquisitions system, CCF (circulation and ILL system), and Serials Management.
The projects to enter data into the ILS from our manual shelflist and serials checkin files are currently underway.

## Lessons Learned

- What Worked Well
- “Culture shock”
- What We Would Do Differently

**Notes:**
With that information as background, I’d now like to take a few moments to review some of the lessons we learned so far from the ILS project.  The Library is unique in a lot of ways, so I’m not sure how much of our experience is directly applicable to other organizations.  Many things that worked well seem like “common sense” practices.  Not that there weren’t some bumps along the way, but we were fortunate, in that as automation projects go, ours went pretty. smoothly. 
I’ll mention some of the things we think worked pretty well, especially in the areas of managing the project and staffing, some of the “organizational culture” issues that came to the fore; then we’ll look at some of the things we would have done differently.

## Lessons Learned:What Worked Well

- Management Issues
- Top Management Support
- LC Management
- Staffing
- Funding
- Contracting
- Automation support
- Congressional Oversight committees

**Notes:**
Dr. Barbara Tillett, our director, has repeatedly emphasized that the single most important factor in the success of the project was the solid support we received from management.  In our case, this meant two groups:  LC’s own top management, and the congressional committees that oversee the operation and funding of the Library.
The Librarian of Congress, the Deputy Librarian, other top managers understood how critical it was to our mission, and were fully behind the project.  This meant support for freeing up the staff who would work on the system, making the ILS the library’s #1 priority during implementation, securing the funding to acquire the system, and -- equally important -- the support of our computer departments
We were also fortunate to secure the support of the our congressional committees.  In many ways they act for us as the “board of directors” does for other libraries.  They had a number of concerns they wanted to make sure we addressed; so we worked with GAO (General Acct. Office) on developing the management tools used to track the project. When the time came they also understood the importance of the project and supported the Library’s funding requested to acquire the system.  As a result, Congress gave us the full amount we requested, a thing almost unheard of in the federal government.

## Lessons Learned:What Worked Well

- Management Issues (cont’d)
- Contracting
- Market review
- Request for Proposal (800+ requirements)
- Onsite Capability Demonstrations
- Technical Evaluation Teams
- Selecting a Proven System

**Notes:**
The Library tried to follow the “best practices” that other libraries have used for managing an automation project.  This included our beginning by reviewing the systems available in the marketplace, both to assess what was currently possible with an ILS, and to ensure that our requirements were not so restrictive or obscure that no system would be able to meet them.
With our Contracts office, we issued a request for proposal, put together by a number of technical teams, outlining our requirements.  These included those that were mandatory, highly desirable, and desirable.  These 3 levels were the basis of a scheme for scoring proposals based on points for each requirement met.  After the written proposals were submitted, offerors were invited to conduct demonstrations of their systems onsite at the Library.  These live demos gave the evaluation teams a chance to compare the statements in the written proposals with what the systems could actually do live, and was an invaluable aid to the teams in making their recommendations.
When it came time to make a selection, a major requirement was a system that was already in production and had enough installations to prove its viability.  The Library did not want to be a beta or development site for a new system, and given recent developments at some other large libraries, we are very glad we made that decision.

## Lessons Learned:What Worked Well

- Other issues
- Communication (with staff and public)
- Orientations & briefings
- Listserv
- Web sites
- Newsletters
- External stakeholders (Utilities, NACO, etc.)
- ILS Staff Help Desk

**Notes:**
Barbara and the other ILS managers were adamant that we in the ILS office do all we could to both get staff input on the implementation of the system, and to keep staff informed as the project progressed.
We held a series of orientations and briefings both before and during the implementation process.  As you can imagine, replacing a system that had been in use for almost 30 years caused a certain amount of anxiety among staff.  Many of the pre-implementation briefings addressed how the system would affect workflow, impact on production rates, training issues for staff, performance evaluations, etc. 
In addition to in-person briefings, we used electronic communications wherever we could.  This included a special staff ILS news listserv, a staff web site, which included system status information, workflow and system documentation, electronic forms, etc, and a public web site, giving the background and status of the project.  
We had a series of articles in the various staff newsletters, and issued press releases so that external stakeholders (like OCLC, RLG, libraries in the cooperative cataloging program) would be aware of the impacts of the ILS on their systems.
Finally, we set up and continue to maintain a dedicated staff ILS Help Desk, separate from our general automation help service, staffed with ILS onsite experts to answer questions and monitor system response throughout the workday.

## Lessons Learned:What Worked Well

- Staffing
- Full-time core staff (ILS Program Office; 15)
- Staff module experts
- Staff input and involvement (teams, policy & steering groups, trainers)
- Team Structure
- Functional, policy, technical
- 80 teams, 500+ staff

**Notes:**
To manage the project, we have a full time staff of about 15 people in the ILS Program Office.  All but one of these people were detailed from other units in the Library.  Their responsibilities including overall management of the project, budgeting, scheduling, records management, testing, and coordinating the work of the implementation teams.  We are currently working on how these functions will be handled long-term at the Library.
Due to the size and complexity of our operations, it was decided that we could not simply use the vanilla, “out of the box” configuration of the system, and that we would not rely solely on the system expertise of our vendor; so a number of staff “module experts” learned as much as they could about  their part of the system, so that we could configure and fine tune it to meet our requirements.  These people have learned the modules to a level of detail beyond what most libraries need.
The bulk of the work was performed by the more than 500 staff volunteers, organized into more than 80 implementation teams.   They came from all over the library - cataloging,  acquisitions, special formats, reference, systems - and worked on every aspect of the project. We tried very hard to make sure each team included representatives of the stakeholders affected by the team’s work.  Teams averaged between 10 and 20 members.  As mentioned earlier, staff members also served as trainers on all parts of the system.
The next slide gives an overall view of the teams.

## Slide 10

**Notes:**

On the left are the functional area teams - things like bibliographic control, public catalog, and circulation.  Each area was a assigned a coordinator in the ILS Program Office, and each had a steering group to oversee the work of the individual teams.
In the middle are the policy groups, which cover issues that cross functional boundaries, like security, training, indexing, and reports.
A lot of overlap was built into the makeup of the teams, to ensure cross-fertilization among the units of the library.  For instance, the chairs of the functional teams were the primary members of the policy groups. 
On the far right are the technical teams, which oversaw the replacement of over 2000 staff and public workstations. 
Some of these teams disbanded after the initial implementation was completed, and some will continue meeting to address ongoing issues

## Lessons Learned:What Worked Well

- Training & Support
- Initial implementation
- Train-the-trainer model (100)
- 3300 staff members trained
- Ongoing
- Onsite experts for local support (150)
- ILS Help Desk
- “Skillbuilders” and other followup classes

**Notes:**
More than 3300 Library staff members were trained in one or more modules of the ILS, beginning in April 1999 and running though September.
We accomplished this by training an initial group of 100 LC staff members who, in turn, provided training to others. The trainers represented a broad spectrum of LC staff - rank and file catalogers, managers, reference librarians, and systems people.  
Once staff received training, they are supported by a network of “onsite experts”, staff members who received additional training in the various modules, and who serve as the first line in user support.  Questions or problems that the onsite experts can’t resolve are referred to the ILS Staff Help Desk, which is staffed by module experts, many of whom served as trainers.  The “stumper” questions from the Help Desk  are referred to the ILS Office.
Now that the initial “push” is over, we plan to continue training all staff, using the train-the-trainer model, as new system features come out and workflows are developed.  One example is a series of “skillbuilders” - short courses on special topics like advanced searching skills and the MARC format for non-catalogers.

## Lessons Learned:“Culture shock”

- Dealing with integration of systems & data
- Local vs. organizational decisions/processes
- Learning to live with a commercial product
- Not the only kids on the block
- Can’t have a completely customized system
- Revisiting our multiple roles
- “Local library” vs. “national library”

**Notes:**
There are a number of things the Library learned, or re-learned, about its organizational culture during the course of the project. 
For instance, system integration via the ILS did not always guarantee operational integration.  We are still trying to balance the special needs of individual units with the overall goals of the Library.  As an example:  the relationship between our acquisitions and cataloging functions. We are struggling with creating the initial bibliographic and holdings info about items we are acquiring.  Due to some early startup problems, where this work is done has shifted back and forth in the last few months between the Acq and Cat units.  The problem is that we don’t yet have the procedures or structures flexible enough to reallocate staff resources to respond to these changes in workflow.
For 30 years, we have been used to having our online systems custom developed by inhouse technical experts, who finely tailored the systems to support the workflow of our staff.  In moving to a commercial system, we had to give up some of those custom features in order to get other other desperately needed functions (like holdings and item records)..  We are still learning how to deal with being only one of our vendor’s hundreds of customers, rather than the sole customer of our computer department. 
In setting up the system, we often had to wrestle with the sometimes conflicting needs of LC as a “local library” with its own patrons, vs. LC as a source of national level cataloging records and standards.  One example:for many years we have cataloged large print books as part of our cooperative cataloging program, even though we don’t add the books to our collections, and we distribute the records for the use of other libraries.  Having these records in our old system frequently caused confusion for researchers working onsite at LC.  During implementation we had many debates - mostly between Cat and  Ref units, about what to do with these records.  We decided that we still needed to create and distribute them - a national task - but to suppress them from the catalog - for local users.

## Lessons Learned:What we’d do differently

- Better prepare staff for “shakedown” period following startup
- System tuning
- Contingency plans
- “Fire drills”

**Notes:**
I’d like to talk briefly about some of the things we would do differently if we had it to do over again.
Because our schedule was so short, most of our energies were spent on  getting all the pieces in place to complete the  initial implementation on schedule. We developed workflows to be used in the new system on “Day 1”, based on what we had learned about the system.  We tried to put in mechanisms, such as the listserv and Help Desk mentioned earlier, to support the staff as they began using the system.  
But we now feel we should have done more to prepare the staff psychologically for some of the inevitable infelicities that can affect a new system during its initial six to twelve month “shakedown” period. We had said repeatedly in various forums that we expected it would take time for staff to become accustomed to the system, for productivity to climb back to pre-ILS levels, and to work out any start up problems.  Some of those problems turned out to be more serious than expected, and staff were not fully prepared for their impact (most of these related to fine tuning our server to handle our large database and a full complement of staff performing input, update, and searching).  The teams had identified risks and developed contingency plans as part of their implementation work, but we had never really tested them.  
Looking back, it would have been smart to conduct some “fire drills” for various situations to give staff a chance to practice their contingency plans.  As it was, we didn’t have a polished set of procedures for staff to follow when we had problems with the system.

## Lessons Learned:What we’d do differently

- Better communication
- to and from staff
- among teams
- More “integration” training

**Notes:**

Even with all the communication efforts we made, we feel we could and should have done even more - more post-implementation briefings for staff, other ways to notify them of system status and problems (eg: onscreen popup messages), etc.  Also, once we were in production, some of the communication between the implementation teams was lost, as some teams were disbanded and most people wanted to get back to their “regular” work routines.  
As I mentioned earlier, the “pre-integration”, “separate systems”  mindset is still very much alive in parts of the Library, and this has led to some decisions made for good reasons in the local unit, but which may have negative ramifications for other units further down the processing stream.  We are working now to reinforce the integration concept, and looking back we would have liked to have had time to do more training and education on this issue.

## What’s Next

- Acceptance testing
- NLS/BPH database
- Begin BPI process
- Workflow review
- New software releases
- v2000 in fall
- Display of CJK vernacular
- Authorities in the OPAC (late 2000)

**Notes:**
Here are some of the major projects coming up this year:
Acceptance testing - beginning in April we will conduct the testing needed to formally accept the production system fulfillment of the contract.  This will involve executing a number of scripts that test functionality in all parts of the system, as well as monitoring system performance and response time.
The database of materials of the National Library Service for the Blind and Physically Handicapped will be loaded into Voyager later this year as a separate database in the LC ILS.
We are beginning the business process improvement (BPI) process this spring, the first step being to develop methodologies for reviewing our workflows.
There will be at least one major Voyager software upgrades this year: Version 2000, which we hope to implement this fall, has a major rewrite of the Acquisitions module, and will include major changes to the Web OPAC.
Included in version 2000 will be the display of Chinese Japanese and Korean vernacular characters in the Web OPAC (from data stored in the 880 of the MARC bib. records.).
The Web OPAC currently displays headings and references from authorities records in the database, but not the full MARC record.  We’re looking forward to having full authorities records available via the public catalog by the end of the calendar year.

## Questions & Contacts	

- Public LC ILS Web site
- http://lcweb.loc.gov/ils
- LC Online Catalog
- http://catalog.loc.gov
- LC ILS Program Office
- ils@loc.gov
- ILS RFP
- ftp://ftp.loc.gov/pub/ils/RFP97-12.WP5