How to Write Effective RFPs -- Focus on the Business Requirements
by David Kay

A request for proposal (RFP) or request for information (RFI) is an essential component of a structured technology selection process. Effective RFPs help buyers move from a typically unmanageable number of vendors to a short list of potential partners who are worth the time to evaluate in more depth.

Unfortunately, many RFPs don’t do their job well. Writing RFPs consumes enormous project team and management time and, if not done well, often lead to vendor proposals that are unclear, undifferentiated, and not focused on the real issues.

Vendors don’t like this any more than buyers. Vendors also invest significant resources in RFP responses. They often “bet” thousands of dollars worth of scarce labor, including time from senior technical resources. They want their responses to stand out from the competition and position them as a partner in delivering value—not only to win the deal, but to gain leverage at the negotiating table.

Why are the responses unsatisfying? The problem is often with the RFPs themselves. In fact, project teams often work too hard on RFPs while focusing on the wrong things. RFPs that include laundry lists of technology features are crossing the line into the vendor’s territory. The right division of labor is for the buyer to state business requirements clearly, and for the vendor to explain how the technology can be used to meet those requirements.

To be effective, RFPs need to:

• Specify the business requirements -- While there are common themes through our industry, no two service and support organizations use exactly the same processes, technology infrastructure, or metrics. Technology initiatives have different objectives based on the unique pains and needs of each organization at a particular point in time. If vendors don’t know the core business requirements—the way their buyers will be judged—they can’t respond effectively as a partner.
  
• Identify who is serious -- Effective RFPs are hard to respond to, but not nearly as hard as delivering the goods once the contract has been signed. Generic cut-and-paste text that doesn’t respond in detail to the buyer’s requirements is a red flag about the vendor’s willingness to be a partner.
  
• Separate the absolute requirements from the nice-to-haves -- RFPs should be ambitious about laying out the business value the buyer wants or expects to receive. Requests that aren’t made are seldom granted. At the same time, they should be clear about the minimum requirements to move forward with the project. Satisfying minimum requirements is no guarantee of being short-listed, but vendors should know the essentials so they can choose not to bid on projects that just aren’t a good fit.
  
• Insist on proof -- As managers, we’re taught to interview candidates by asking for specific examples of how they accomplished goals in the past. As buyers, we should do the same thing to technology vendors. It might be acceptable to test novel solutions for one or two unique, non-critical requirements, but RFPs should require responses to refer to specific, deployed solutions whenever possible. In addition to grounding responses in reality, this paves the way for great reference check questions and demo requirements for short-listed vendors.
  
• Differentiate among vendors -- When responding to RFPs, vendors will naturally put the best light on their products and offerings. This means that RFP questions that obviously have one right answer—for example, “does your solution offer effective natural language search?” will get that one right answer from everyone. Vendors rarely lie outright, but they are extremely adroit at interpreting any vagueness in questions to their advantage. Effective RFPs let each vendor tell its own story.

Let’s take a look at a section from an actual RFP to see how it matches up against these criteria. (The text has been slightly edited to protect the issuer.) It’s unfortunately typical of the feature checklists buyers often issue.

• Does the search engine include the following basic capabilities:
  
  • Keyword search
    
  • Part of a keyword
    
  • Exact word search
    
  • Boolean search
    
  • Full text (i.e., but no rule-base)
    
  • Decision tree (i.e., but no rule-base)
    
  • Bubble search (i.e., a relevancy search for most recently asked questions pertaining to similar subjects)
    
    
• Does the search engine include the following advanced capabilities:
  
  • Natural language processing
    
  • Artificial intelligence
    
  • Associative search
    
  • General decision tree
    
  • General inference engine
    
  • CASE-based
    
  • Adaptive learning
    
  • Index filtering
    
  • Neural net
    
  • Fuzzy logic
    
  • Full text or semantic network

How does this stack up against our requirements for an effective RFP? Well, it doesn’t specify the business requirements—as a matter of fact, the RFP from which this was extracted spent just one short paragraph on who would use the system and why. It doesn’t weed out vendors who aren’t willing to invest; this can be answered with a very short set of yeses and nos (mostly the former, one can safely bet). It doesn’t say what features are absolutely required—and, since many of these search approaches are mutually contradictory; it’s fair to say that no vendors can honestly respond “yes” to all of them. It doesn’t ask for how these features have been used elsewhere—there’s no demand to “show, don’t tell.” And finally, it would be almost impossible to tell vendors apart based on their answers.

That isn’t to say that search requirements aren’t important, in the knowledge base segment, they’re absolutely critical. So how could this section be rewritten to meet the requirements for an effective RFP?

Search. We’ve provided detail about our support analysts and our self-service users in earlier sections of this RFP. As you know, the current keyword search system deployed for these users is seen as ineffective. Support analysts rarely use search, preferring to keep private files of frequently-referenced documents; end-user self-service satisfaction is low, based on recent surveys; use has been constant or declining, and 55% of sessions include no document click-throughs. Please explain:

• How your search is optimized for support analysts. What features or practices drive adoption? What features make it more effective than keyword search? Please illustrate with real-world experiences upgrading a support center from a keyword search to your product. What happened to operational metrics? What happened to knowledge reuse? Why?
  
• How your search is effective for end-users. What features enhance results relevance? How are people who are not skilled in searching helped through the process of finding what they need? What happens if people have too many results, or no results? Please include demo screens of public web sites running your software that illustrate these features, and provide measured success rates for these sites.
  
• How does your search learn or improve over time? Describe either automated or assisted approaches to continuous improvement.

This covers all the ground in the earlier laundry list, but does so without telling the vendor what technical approach they need to take. It also points them in the direction of what’s important to the buyer -- business pain and requirements. It requires a thoughtful response that links to the business needs. Appropriately, no particular search technology is absolutely required, although other things—IT compatibility issues or CRM system integration—may be. It requires detailed reference points. And finally, the answers that different vendors will provide will be as diverse as their own products and approaches, making it easier to understand who will make the best partner.

How does a team write an effective RFP?

• Be absolutely clear about the initiative’s business requirements -- Businesses don’t buy technology for technology’s sake: or, at least, they shouldn’t. They buy technology to drive business results. Clearly articulate and gain stakeholder buy-in to these results, then put them all in the RFP.
  
• Tell vendors about your users -- Technology exists to serve users, not the other way around. Solutions that are ideal for one user community might be completely inappropriate for others. But vendors can’t shape their solution unless you tell them about the proposed users of the system, what they’re like, and what issues they have.
  
• Be disciplined about injecting technology requirements -- Technology can be fun; we probably wouldn’t be in this business if we didn’t think so. But what vendors really need help with is your business and its needs. Be careful not to inject “hows” into the RFP.
  Note that this isn’t an abdication of responsibility for technology; you still need to evaluate the reasonableness, feasibility, and appropriateness of technical approaches, and the plausibility of claimed results. Nor are all technical requirements off-limits. If the software needs to run under Linux or your IT department won’t let it in the door, say so. But, when possible, confine technical requirements to issues like: reliability, compatibility, maintainability, scalability, security, performance, and so on.
  
• Be prepared to check references – When you get to the point that you’re asking for proof, be prepared to follow-up with customers of the most promising vendors. Do these customers attribute the 30% decrease in call handle time to the vendor’s system, or to the certification program they introduced at the same time?
  
• Use the “just say yes” test -- Could a sales engineer respond to your proposal quickly by saying “yes?” Then rework the questions to make them really take a stand about what their solution will do for you.
  
• Keep an open mind when evaluating responses -- Somewhere, right now, some smart people are figuring out a better way to solve support problems with technology. Find them, give them an RFP that lets them tell you about their ideas, then evaluate them based on your business requirements, not your assumptions about what you were going to buy.

Use these tips for writing and working through the RFP process and you’ll have greater success – and ease -- finding those technology vendors that can really help you manage your organization.

David Kay is principal of DB Kay & Associates, a consulting firm specializing in applying knowledge, self-service, and collaborative technologies to improve customer service and support. DB Kay offers vendor selection and RFP development programs.

How do you handle price increases to your support maintenance?
› View Answer