The problem with RFPs: Part II | Federated Search BlogFederated Search
28
May

In Part I of this series I wrote about a number of issues with the RFP process that increases the cost of doing business for federated search vendors and raises the cost of procurements for libraries. In this article, I consider ways of mitigating the costs. Much of the information for this series comes from an article written by Carl Grant: Choose wisely: making the library’s money work for the library in the system procurement process.

Grant makes the important point that vendors and libraries must collaborate to bring costs down. If libraries insist on continuing to use the current RFP process then vendors will be forced to use it as well. The first step in this collaboration is for the library to clearly articulate its goals to the vendor and to have both parties consider what needs the vendor can realistically meet. This also requires the vendor to be honest and up-front about what it can reasonably deliver. While Grant’s article is biased in its outlook – libraries are made to look like the bad guy – I’ll state that vendors own some of the responsibility. If vendors were really clear and honest about what they could deliver, on what schedule, and at what cost, then libraries wouldn’t be grilling them so hard.

Grant proposes that national library associations hire consultants to develop a matrix of features. The idea is that libraries would produce RFPs that focused on unique offerings, assuming that the matrix answers all common questions and that it is correct and current for all vendors who use it. I like the idea in principle and I doubt that many vendors would populate the matrix. My experience is that most vendors are very reluctant to provide detailed information about their offerings without carefully controlling the customer’s experience through teleconferences, orchestrated demos, and pilots specifically tailored to customers requirements. I was disappointed at how little response I got to my request to vendors to provide public demo applications.

Also related to bringing vendors together is Grant’s proposal that the federated search industry, guided by national library associations, should produce a common baseline contract form that would be required in the RFP process. I don’t have a sense of whether this would work or not. It would depend on whether vendors see sufficient value in this kind of collaboration and whether they view their national library associations as powerful trade associations.

Beyond what’s in the article, let me list other things that libraries (mostly) and vendors can do to improve the purchasing experience:

  • Libraries should do their homework and understand what is realistic and what is not so that their RFP questions make sense and vendors can answer them. A poorly written RFP might result in the vendor who is the best fit not responding.
  • Libraries should not hide behind procurement departments. I’ve experienced the frustration of trying to get clarification on poorly worded RFP questions only to be told that it would somehow bias the whole process if I were to actually speak to the person who was best suited to answering my question.
  • Libraries may want to consider using RFIs before issuing RFPs. An RFI (request for information) is a document that a library typically broadcasts that does not commit them to purchasing a product. The RFI process is a fact-finding mission; the library documents what it wants and vendors respond with descriptions of how they can meet those needs. RFIs have several advantages to both parties. Vendors can use the RFI as a way to get the library’s attention without the commitment of responding to a full-blown RFP. Vendors can also influence future RFPs by proposing valuable solutions to problems the library may not have considered. Libraries learn what’s possible and what’s not in a less formal process and, libraries can copy and paste important ideas from RFIs to produce their RFPs.
  • Libraries could be more forthcoming with some key facts pertaining to their procurement process. They could tell vendors how many of them have been sent the RFP. They could document what criteria is most important to them and disclose how they will score RFPs. This information would save vendors time responding to RFPs that are poor matches and it would save libraries from wasting their time reading document from vendors who can’t meet their most critical needs.
  • This last item is for the vendors. Provide demonstration systems that libraries can test drive to determine if there’s enough of a match to proceed with further discussions. By not being forthcoming with detailed information about their products, it is difficult for libraries to produce well-informed RFPs.

Do I think that the RFP process is broken? Yes. During my tenure with Deep Web Technologies (this blog’s sponsor) I contributed to a number of RFP responses. I participated in building demos. I held many hands. And, as Grant accurately portrays, I just knew that a number of those RFPs were “wired” for an already selected vendor, and it wasn’t us.

Do I think that the RFP process can improve? Maybe. I’d like to see some heart-to-heart discussions with both customer and vendors where these issues are bluntly raised. But, I think it’s going to take a movement to effect change as fragmented conversations aren’t going to gain traction. And, I think these conversations need to start with the vendors first.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: , ,

This entry was posted on Wednesday, May 28th, 2008 at 7:53 pm and is filed under viewpoints. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or TrackBack URI from your own site.

Leave a reply

Name (*)
Mail (*)
URI
Comment