The Ideal Procurement Process : The Vendor's Perspective

Chris Kirby, former GIS Director of Marketing
Anita Wagner, Senior Software Specialist

As a library manager, you may participate in 4 or 5 procurements of library automation systems in your career; the typical vendor sees more than 150 Requests for Proposals (RFPs) every year. Culled from Gaylord Information Systems' 25+ years experience in the library automation industry, the following suggestions are compiled to help libraries expedite and streamline the procurement process. This information may be useful at any step in the process. We hope our experience is valuable to you.

Planning Ahead

Libraries often go through a lengthy and complex procurement process to obtain a library automation system. The typical process can take 18-24 months. Knowing this, you can start your process far enough in advance to avoid a crisis situation with your present system, such as escalating maintenance costs, unreliable equipment, or hopelessly dated software. When these potential issues begin to loom in your future, it is a good time to start planning.

Ten Sure Time-Savers

As you begin your library automation system procurement process, you can save time, in both the short- and long-term, and often money, if you:

Obtain early involvement of all stakeholders. When libraries decide to seek a new automation system, they typically form a committee. Libraries are well-advised to include representation from all affected parts of the organization—administrators, front-line reference librarians, circulation staff, computer center management, etc. Every part of the organization brings a different perspective. Early involvement usually means faster acceptance and more thorough implementation. Stakeholders outside the library, including Board members, Friends of the Library, state-level consultants, academic departments, municipal agencies or corporate sponsors may also need to be involved at some level.
Identify the primary reasons for seeking a new system. The reality is that the perfect system, addressing all of the needs of all of the stakeholders, does not exist. In evaluating and selecting a system, compromises will need to be made. Use the drafting of the Request for Proposal (RFP) or Request for Information (RFI) to identify the primary reasons for your seeking a new system. State them clearly and early in the document. Often, you can identify your priorities by determining the requirements you are not willing to sacrifice. If you do not have a clear focus, vendors will not understand what you are trying to accomplish, and you will receive proposals that fail to address your needs.
Set a calendar of activities and adhere to it. Early on, determine the availability of key staff, taking into account vacations, holidays and scheduled events. Work with vendors in advance to arrange demonstrations so that they can make their key personnel available to you. This will help you set a sequence to the events, particularly those that are dependent on one another. At the same time, don’t schedule too tightly. Be realistic about the ability of your evaluation committee to review proposals and to keep systems straight in their minds, especially if they must attend demonstrations scheduled close together.
Agree to a regular meeting schedule. At minimum, create a calendar of meeting dates, and distribute it to all parties involved. This will gain commitment for staff's being available and for making decisions in a timely manner. One consortium’s evaluation team agreed that they would meet every Thursday and not schedule anything that would conflict. All evaluators need to be involved in all aspects of the selection—reviewing proposals, seeing demonstrations, etc. Partial participation can delay and invalidate the results.
Be clear about your evaluation criteria. Determine the criteria and method for evaluating proposals. Settling this early provides some framework for the format of your RFP/RFI. After the document is issued, don’t change your mind about the criteria unless you are prepared to issue a complete revision. Piece-meal amendments can compromise the whole project.
Visit libraries which have new systems. To gain valuable background information for your RFP/RFI, visit other libraries that have recently been through the system procurement process. Interview the staff about what worked, what didn’t and what they would do differently if they could do it over.
Determine your contracting and legal requirements. Library automation systems are not purchased every year. Some governing bodies change procedures and may not inform the library. Work with your governing body to review -- and, if necessary, modify -- contract language that may be required. For example, a contract used for purchasing supplies will not work for licensing software. Find out if you need to sign a contract in a certain timeframe to ensure full funding. Determine whether there are legal requirements for the handling of documents. Outline your approval process, including the times when signatures are needed. This aspect of planning could save many weeks in later contract negotiations.
Make the RFP/RFI document available in electronic format. This will help vendors expedite their response by not having to scan or re-type the document. Use a common word-processing program, such as Microsoft Word, and make the document available on diskette, or online for downloading.
Allow vendors to submit questions for clarification. Vendors will want to question you to ensure that they are understanding your needs and technical environment. Some RFP/RFIs, for example, contain terminology that reflects an old system, rather than current technology. Allowing questions up-front from vendors reduces the library’s risk of being misunderstood or of the vendor's providing misinformation.
Do not schedule a bidders’ conference unless it is a legal requirement. Bidders’ conferences rarely have any value for either side. Most vendors will have to send someone from out-of-town and pay for airfare, meals, hotel, etc. These expenses needlessly raise the cost of doing business.

To RFP or Not to RFP

Government agencies invented the RFP as a way to determine the lowest bid for products. Libraries, particularly those which were required to accept the lowest bid, quickly adopted the RFP process to itemize the specifications desired in a system. Libraries continue to justify the RFP process as a way to do needs assessments, as a way to involve staff, as a tool for negotiating a contract with a vendor, and as the means to appear fair when seeking products and services from competing vendors.

Few would dispute that RFPs are costly in terms of time and money for all parties involved. It is refreshing to observe that some advocates for "ending the RFP madness"1 are emerging. They argue that the RFP process is becoming outmoded with today’s quickly moving technology advances. By the time a library decides to seek a new automation system and selects a vendor, 18 to 24 months may have gone by. By then, often the technology specified in the RFP may already be outdated. As one author quips, "The RFP is a gas-guzzler when fuel efficiency is needed."2

Despite the serious problems inherent in the library automation system RFP process, RFPs are unlikely to be abandoned soon. Libraries should consider the RFP as only part of the process of investigating and evaluating systems for their use. The needs assessment, discussions with other libraries and general information about available systems should be equally considered.

Two ways to streamline the RFP document, and, by extension, the responses, are:

Provide clear instructions for the response format. To see if your instructions pass the clarity test, show them to a colleague who knows nothing about the project. If he or she understands it, you’ve probably been clear.

Set limits on length. Provide guidelines or a precise page quantity for the size of each section in the RFP and in the vendor’s response. For example, perhaps you will allow two pages for requirements for each function, such as cataloging or serials check-in. Determine how many open-ended questions you will allow. Generally, a 50-page RFP will generate about twice as many pages in the response, plus diagrams, supporting documentation, sample reports, etc. If you want fewer pages to review, consider why you are asking the questions you are asking and what you expect in response.

Typically, an RFP should contain the following elements:

Background on the library and the computing environment, the needs assessment results, and the committee member names and titles.

Schedule of key dates – including when the response is due, when the decision will be made, when funds are available and when implementation is expected to begin.

Contact names and information sources for the RFP and for the contract.

Instructions for formatting the response, stating what the vendor may or may not include in the response.

Specific requirements, grouped by library function or other commonality.

Technical requirements, such as operating system or network environment.

List of documents required as attachments, such as sample reports, standard contract language.

Most vendors can respond only to a fraction of the RFPs, RFIs and similar documents that are submitted to them by the library community. They simply aren’t staffed to answer them all, particularly since there is no predictability as to the timing of the requests. The response time should be no less than six weeks, eight weeks or longer is preferable. It is very likely that the vendor will have three to five other RFPs that are due about the same time. The choices as to which ones are answered are difficult to make. Help the vendors by making sure they have all the information they need to give you their best response.

Now, about those Vendor Demonstrations…

Ideally, you should plan for two or more demonstrations by the system vendors. At the beginning of the process, you may want to see several vendors to get a feel for the range of options in the marketplace. This can be done most easily at major conferences. Then, as part of the final evaluation, all competing vendors should be invited to provide demonstrations for all staff, for the evaluation committee or for some combination of key people.

Determine what format you want the demonstrations to follow.

Scripted demonstrations that are too specific may not let the vendors present key features of their software that may be of significant interest to the library.

More flexible demonstration formats would have each vendor include key activities, yet in the context of the system being shown. For example, the library could require that the vendor show a patron record and a typical pattern of circulation activities (check-out, pay fines, place reserve). This kind of broad script lets the vendor demonstrate the ease-of-use of the software, how the functions interact, and any special features that might be of interest to the library.

The more tightly scripted the demonstration, the longer it takes the vendor to prepare. The vendors may not be ready in the timeframe allocated by the library. The demonstration itself may take longer than usual because each vendor’s workflow will be different. The vendors scheduled later will have an unfair advantage in more preparation time.

As a courtesy to the presenters and the attendees, demonstrations should not be longer than 9 a.m. to 4 p.m. Any longer time period will be tiring to all involved. Allow for a couple of short breaks and a lunch period for the presenter.

Consultants--Myths and Realities

There are some valid reasons to hire a consultant:

Some governing bodies may require outside expertise.

A disinterested party may help to bring together the diverse viewpoints of the evaluation team.

As a time-saver, the library may wish to delegate (and is willing to pay for) certain tasks to be complete by a third party.

There are prevailing myths about what a consultant can accomplish for you:

Myth: A consultant will save you money. The reality is that vendors do not give discounts or special deals based on whether or not a consultant is involved. In some cases, consultants may make the overall bottom line more expensive, if you add in their fees over the life of the procurement process. Vendors treat each library as unique, regardless of the consultant or lack of one. Just because you hire the same consultant as Library XYZ does not mean you need the same system or will make similar decisions.

Myth: A consultant will save you effort. The reality is that services provided by consultants vary widely. Some consultants work on the library’s entire technology plan, others just on the system procurement. Be specific about your needs and realistic in your expectations. Some libraries issue an RFP for consulting services to ensure that they get what they want and only that for which they are willing to pay.

Myth: A consultant will shield the library from untrustworthy vendors. The reality is that the vendor community is no more or less trustworthy than the rest of the library industry. Many vendors are librarians by training and have been on the library side of the fence, involved themselves with system procurement. Some consultants used to be vendors and vice versa.

Myth: A consultant will protect the library from a bad decision. With or without a consultant, the library is making its own decision
and will have to live with the results.

Given all that’s been said, is there an ideal procurement process? If there is, these steps would certainly be a good place to start:

Hold initial discussion and planning, which incorporate:

Conducting a needs assessment.

Identifying funding sources.

Involving stakeholders.

See demonstrations of as many vendors as possible at conferences.

Visit other libraries which have new automation systems.

Write the RFP (plan on 2 or 3 drafts).

Develop a schedule for the responses/evaluation/decision phase:

Allow 6-8 weeks for the vendors to respond, depending on the complexity of the document.

Allow at least one week per response for evaluation of all committee members.

Allow time for additional information to be exchanged before the final decision.

Add another week or two if the schedule spans major holidays or ALA conferences.

Invite vendors in to do demos before finalizing the specifications. Be sure that what you are asking for is available, real and demonstrable.

Send out RFP to a select list of vendors.

Receive responses.

Evaluate responses.

Pick a "short list" of two vendors, and notify all vendors of the selections.

Schedule demonstrations, by the finalists, of the software to be installed at
your library.

Each vendor should be given at least 2 weeks notice to schedule the presentation, especially if the presence of vendor staff with particular expertise (e.g. networking) is required.

For a "software only" demonstration, allow one or two days. For a demonstration and a discussion of technical issues, allow two days.

Select vendor and send award notification. The notification is important because it will be the trigger for the vendor to set up contract negotiations, begin assigning staff to the implementation, plan for equipment orders, etc. Notify the losers, too. They are waiting to hear from you and deserve this consideration.

Negotiate contract.

Sign contract.

Announce the decision, in cooperation with the vendor.

And, finally, given the rapid pace of technology advances, start planning for future automation needs the day after the system you’ve just procured is installed.

Bibliography

1. Williams, Joan Frye. The RFI, RFP, RFQ and Contract Process. Integrate Online Library Catalogs Westport CT: Meckler Publishing, 1991, p. 1-15.

2. Dwyer Wanniger, Patricia. (1990). "The Sound and Fury of RFP". Library Journal, 115, 87-89.

Reprinted with permission by Gaylord Information Systems.

Reviews || Vendors || About ILSR || Contacts || Home

Contact webmaster@ilsr.com with questions or comments regarding this site.