LIS Notes: Selection process for a large integrated library system. (Release 1.4).

RFI

Request for Information. A brief description of a library's requirements for an integrated system, sent to many potential vendors, with a request for descriptions of products which might be suitable. Glossy product brochures and demo disks probably accompany the vendors' letters or response.

RFP

Request for Proposal. A formal and very detailed definition of a library's requirements for an integrated system, sent to a smaller number of likely vendors, requesting detailed automation proposals, and bids. The RFP answers become part of subsequent contracts. Manuals and examples of reports generated, etc. usually accompany the completed proposals. 

Demos

Based on the RFPs, 2-3 vendors are asked to demonstrate their systems on campus. The sales people may bring along sales support staff to assist.

Letter of Intent

The Library usually issues a letter announcing its agreement to enter into contract negotiations with the selected vendor for the purchase of a system. Simultaneously, the vendor probably issues a press release announcing that it has reached an agreement to enter contract discussions with the library. This helps both the library and the vendors by reducing unnecessary communication. It also helps investors.

Contract

A legal agreement between the vendor and the library for the purchase, installation, testing, training, etc. and outlining the payment schedules and the responsibilities of both parties for performing various parts of the work. The vendor's RFP responses, and the Library's RFP questions, will have legal force if the contract is ever disputed.

Milestones

When the vendor completes various stages of the installation, the library must pay certain amounts. The library may hold up the payments by refusing to "sign off" on the work done by the vendor. Some contracts include performance bonds - if the vendor fails, it loses the performance bond.

Conversions and test database loads

Representative records from the patron and MARC databases used in the old system (if any) are test loaded into the new one. The vendor may charge for this service. Some existing transaction records might also be loaded. Training can take place using the test database. The best communicators in various departments should be selected to attend training.

Functional Acceptance Tests

Newly trained Library staff hammer away at the system, identify problems, and when satisfied, "sign off". They are thereby stating that the system performs up to spec. A milestone payment may become due.

"Live"

With the full databases loaded, the system "goes live", perhaps in a few branches first. A milestone payment may become due.

Final Acceptance

The Library "signs off" on the system. A milestone payment will almost certainly become due.

Hardware and Software Support

Now that the system is live, the provisions of the hardware and software maintenance agreements in the contract come into force. The sales representative likely passes the site off to a project manager, or customer support representative, who will serve as the site's contact thence forward. The Library should appoint one person, optimally, the systems librarian, to act as liaison.

Project Managers

Library staff member and Vendor staff member who are responsible for the implementation and serve as primary go-betweens.

Glossy

A primary marketing tool which is designed to attract attention to the product, but which is sketchy in detail.

Functions and Features Document

A secondary marketing tool outlining the work the system can perform (functions) and the bells and whistles (features) which make it stand out.

Feature (1)

An outstanding or innovative aspect of the software.

Feature (2)

(Sometimes also "undocumented feature"). A characteristic of the software which is technically correct, but which does not accomplish the desired result.

Bug

A fault in the software.

Dog and Pony Show

A sales demonstration or conference presentation designed to show off the functions and features of a system.

Boiler Plate

A canned response to an RFP question, such as a word processing document, which can be modified slightly for different clients without having to be rewritten from scratch.

Checklist RFP

A request for proposals  listing each desired function and feature, and having columns marked "currently implemented", "future release", "N/A", "not planned", etc. Quicker for the vendor and the selection committee, but can be misleading if either party forgets to include something.

Targeted RFP

A request for proposal which asks vendors if they can emulate the functions and features of a known vendor.  Could well be a thinly disguised attempt to lend credibility to a skewed selection process. Most vendors will know, and will probably not respond.

Customer Support

Trouble desk or similar staff, including perhaps a customer support engineer or "field engineer", who look after clients once contracts are signed.

Sales Support

Programmers, engineers, or librarians who support the vendor's sales force before and during the contract negotiation phases.

Release Number

A number given to a major change in the software. For instance, "Release 1.0" might be the first major software issue.

Version or Revision Number

A number designating a revision, with bug fixes, to a major software release. For instance, "Release 1.2" might be Release 1.0 with fixes.

Alpha Test

The first trial implementation of a new system - often in-house, with vendor staff and invited clients testing the system.

Beta Test

A trial implementation of a "pre release" of a new system "on site" at selected client sites. Often libraries are given discounts to beta test software - on the understanding that it may not work. Their suggestions will be incorporated into the released version.

GIGO

Garbage In - Garbage Out. A programmer's maxim which implies that no matter how good the software is, the data structures and the data themselves determine the results. If you do not capture good data, you can't get good output, etc.

Best Test of a System

The best test of a system is live operation with real data and under real conditions. No matter how much you test, something always crops up in live operation which neither the vendor nor the client has anticipated. That's why "final acceptance" should come a few months after you "go live".

User Group

A formal or informal group of representatives from sites using a particular vendor or product. Collectively, they can lobby the vendor to incorporate new functions and features into subsquent releases of the software, or to fix long standing bugs.

Migration path

Even while buying a particular system, the library should consider how to handle migration to another system or to improved hardware or new releases of the current one. Perhaps the library may askfor the source code to be held in escrow in case the vendor goes bankrupt. During the 5-7 years of a system's life, a lot of things can change. The vendor may obsolete the current system, and attempt to migrate its customers to another one. The Library may want to plan for eventual migration to another vendor.