Requests for proposal (RFP) and IR

Last Updated: 1st May 2013

I am looking for a list of functions and features buyers may use in their request for proposal (RFP) to help them acquire an enterprise search/IR platform. Any experience to share about this topic? Any reference that can help analyze this problem in depth?

Thanks in advance.


3 comments for “Requests for proposal (RFP) and IR

  1. 30 April, 2013 at 07:40

    Suggestions from Enterprise Search Engine Professionals (LinkedIn group)

    Ed Dale • Use the RFP to define your needs.
    I see these as falling into a few categories.
    There is the pure operational aspect of search – number of queries per second, number of documents in the index, freshness needs on the index, network load, etcetera.
    There is the content processing aspect of search – as content comes into the index, what operations do you want to apply to the content? Metadata to be identified, entity to be extracted, security to be applied, and so on.
    There is the query processing aspect of search – synonym, thesaurus, query cooking, and so on.
    Relevancy adjustments you expect to be able to perform – field weighting, format weighting, source weighting, user profile etcetera.
    UI features you expect the search to support – query suggestions, spell suggestions, type ahead, refiners, filters, sort options, etc

    Your goal in writing the RFP is to give the vendor a complete picture of your needs, and an opportunity to explain how they can meet those needs. There will be some needs they cannot meet. You need to determine how important each need is, and which vendor most meets your most important needs at a cost you can afford.

    Keith Wheeler • One of the things I try to caution folks about is this “function/feature” list. I see RFP’s all the time that look like nothing more than a laundry list of “do you have xyz feature” and the feature many times is nothing the business, users or applications will ever have a need.
    My preference is to see a set of use cases in the RFP. This tells me the customer understand what it is they need. What problems, needs are you trying to fulfill? What is it that your users need to do to accomplish business goals, satisfy your customers, reduce costs.
    Using Office products such Microsoft Office for example, it has thousands and thousands of features, but 95% of the users of Office only use a handful of them and most of time the choice of Office over another competitor has little to nothing to do with the list of features.

    Olivier Jobin • I would add to Keith’s point that before going into an RFP, it might be worth actually engaging with 2 or 3 vendors so that they could help you define your needs first. Like he said, very often RFPs are just a combinaison of features built by IT, without much understanding of the business’ needs. Despite the fact vendors will want to sell their solution at the end of the day, they usually have much more expertise than an organization’s IT department, and most are very willing to share time with prospects so that said can broaden their understanding of what’s possible to do while better understanding their own requirements in the process. “You don’t know what you don’t know” actually makes a lot of sense when it comes to Enterprise Search, because some organizations will only see it as an improved search box for one of very few systems (which is in itself extremely limited in terms of value that can be obtained by indexing technologies), and RFPs will be built in this fashion. Understanding how other similar organizations might be leveraging Enterprise Search before developing the RFP provides tremendous value to companies willing to invest some time there first.

    John F. Delaney • I agree with what Keith had to say in his post. Often times we sit across the table from prospects that have no starting point, use case examples of the problems they are trying to solve. A list of feature/functions is not the starting point and often can lead to more confusion and time consumption working yourself backward.
    The 80/20 rule. In most cases of life eighty percent of the benefits typically derive from twenty percent of the functionality. The same could be said about most enterprise search technologies, organizations struggle with the cost spiral that can be apparent with greater sophistication. The basic tradeoff is this- greater sophistication should make the search process more efficient, but the sophistication should not cost more than the benefits it delivers.

    Pervaiz Khan • I would like to add to comments above that many Search Engines fail in implementation when it comes to Enterprise Search. So best is to ask for developing POC(proof of concept) with some reasonable indexing to see whether the solution will be able to serve the company user base or not. Data secuirty is another challenge for enterprise data if source data has secuirty implemented ask wether the solution will be able to handle it or not.

    Chris Whissen • If what you really want is just a list of features and functions you could always hop on to any vendor’s website and find the list of features they think people want.

    However, I have to agree with the others here that you’ll get a much more meaningful response if you let vendors know you goals and not a list of things you think will accomplish your goals. I’ve had many customers come in with a feature list that we didn’t meet word for word, but after talking with them they’ve realized we could do what they wanted. Usually our method was more efficient and/or effective than the features they’d listed, which makes sense considering your search vendors live and breathe search and should have learned a few things along the way.

    As Olivier said, a good search vendor is going to take the time to work with you – even if it’s just to help you figure out the questions you need to ask. Obviously they want your sale, so their input might be slanted towards their product. I know I try to be unbiased when helping customers, but I know my product best so there will always be some unintentional bias. For that reason, I’d contact a few to get a more rounded picture.

    Ken Stoltz • As others have said, start with your internal users and determine a set of use cases from the various departments/user groups. Find out what their pain points are, and features they are interested in seeing.

    Vendors will want to know:

    * What kind of sources that you want to index

    * What kind of data they contain

    * What kind of security requirements you will have

    * How much data that you have

    * What are your requirements for up-time

    * What kind of metrics that you want to capture and report on

    * Systems that may need to be integrated with

    * System administration requirements

    Some examples of features to consider and build some use cases around: Faceted Navigation, Geospatial Search, Saved Queries & Alerts, Administration Tools and UIs. Notice that these are fairly practical features that lend themselves well to easily understood use cases.

    Last thought: Give some details on the use cases. For instance, if you have reporting requirements, give some information about the frequency of reports, types of reports you need (business user, administrator, both), visualization capabilities, etc. You’d be surprised how many RFPs have a single sentence for a requirement, which leads to responses that are incredibly generic.

    Charlie Hull • Very often we’re asked to consult with companies before they reach the RFP stage – as others have mentioned they don’t always know what is possible with search or the options available in the market.

    Marina Santini • I see Charlie… But do you usually suggest to these companies? What are the basic parameters in your experience?
    Charlie Hull • A few years ago we’d usually suggest they consider an open source solution – note that this wouldn’t necessarily mean we’d end up with any work at the end of it as they could choose to implement it in-house – the double-edged sword of open source! Nowadays clients are far more aware that open source solutions exist and often get us in to help them decide between the various options available. In terms of parameters these are much the same as others have suggested above: one thing we do insist on is a real, representative set of source data, example queries and the sort of results they expect (which isn’t always easy to produce).

  2. 30 April, 2013 at 08:19

    Suggestions from Information Access and Search Professionals (LinkedIn group)
    Discussion link:

    Martin White • Most of my book Enterprise Search is about the development of a specification for an enterprise search application. In the book I do make the point that just listing out functionality is not a good way to specify search, and that the focus should be on what you want the application (commercial or open-source) to deliver.

    Could I also suggest that you attend the Findwise Findability day in Stockholm on 30 May and network with the delegates.

    Stephen E. Arnold • Some questions. What do you mean “enterprise search”? Are you looking for brute force retrieval from the good old days? Are you seeking a system which does Big Data findability? Do you want business intelligence outputs? There are differences which make an off-the-shelf list like the one-size-fits-all gym pants. Stephen E Arnold, April 29, 2013

    Marina Santini • Thanks a lot, Martin, for your pointers. Hope I can attend the Findability day here in Stockholm!

    Marina Santini • Stephen, my first step is to identify a nitty-gritty big data findability system to investigate how satisfying this can be. The next step is to spell out specific needs.


  3. 1 May, 2013 at 17:27

    From ACM SIGIR LinkedIn Group

    Will (Willy) Martin • For once, could we get a list and not a discursive? It will be easier for all of us to contribute to a final product we could actually share.

    Marina, for starters the “Enterprise” side:

    1. Deployment. Should work the same across dev/QA/Staging/Production. All changes should be driven by deployment configuration;

    2. Exceptions are not error messages. No exception should ever make it to the UI level. Exceptions are costly to build and reveal inner workings of code (security).

    3. Runtime reconfiguration of logging levels.

    4. Systems Engineering should sign off on any availability numbers.


Leave a Reply

Your email address will not be published. Required fields are marked *