The recipe for creating a successful RFP

Tobin Conley | 07.31.14
Topics: Project Management, Software Requirements & Selection

Alfred had never put together a request for proposals (RFP) but he was confident he knew what to do. (After all, he was a good baker! Wait, what does that have to do with it?) Before developing an RFP, he would first do some market research and then send out a request for information (RFI).


He knew better than to blast out an RFP to dozens of vendors. And, he preferred to avoid the nightmare of having to review and compare an excessive number of proposals. Instead, he started with an RFI to narrow the field of candidates to a qualified – and manageable – number. 

After assessing the responses to his RFI, he deduced that 4 firms had the experience, expertise, and approach to customer support that his association needed. In the RFP he sent to the 4 firms, Alfred made an effort to clearly communicate as much as he could about the project so they had the information they needed to prepare an accurate proposal. Because his association had gone through a comprehensive requirements analysis process, the requirements documentation for the project spelled out exactly what they needed. 

His RFP called for 9 ingredients:

  1. RFP selection criteria. Tell the firm why they were chosen to receive the RFP so they have a sense of the criteria you’ve used up to this point. Like a first or second date, you don’t need to reveal all your secrets, but you should let them in on why you’re interested in a third date. What are you looking for in an ideal partner?
  2. Organization description. Provide the basics about your organization: staff and membership size, membership, mission, current technology environment, and any other factors that you think vendors need to know.
  3. Project goals. Explain the strategic context. What problems are you trying to solve with this new technology? Don’t leave out any pertinent history, but don’t write a novel, either.
  4. Project scope. Define the deliverables and requirements as best as you can. Use everything you learned during requirements gathering to craft a clear, concise, and accurate project scope (with the acknowledgement that it might change during the evolution of the project).
  5. Budget range. Vendors want to propose solutions that meet your budgetary expectations. You might only have a general idea of how much you want to spend or how much a particular solution might cost. But you don’t want to hear about a Jaguar if you have a Kia budget! So, at a minimum, you can set the right tone.
  6. Project timeframe. What is the ideal timeframe? Are there any hard deadlines (e.g., were promises made to the board, or are you looking to launch at your annual meeting? [We hope not!]) Any calendar conflicts that will consume your staff’s time? Any dependencies vendor’s should consider?
  7. Requirements documentation. Your requirements could be formatted as a checklist or table according to what’s mandatory, preferred, or optional. This initial triage provides vendors some indication of what is most important to your organization and a framework for telling you how well their offerings can meet your required features and functionality.
  8. Vendor methodology. Find out how the vendor typically manages client relationships and communication. Who will be part of the vendor team? What are their expectations for association staff? What is their approach to development and project management? To get a real response, and not a boilerplate proposal, ask them to provide examples of how their methodology would apply to your situation.
  9. The rules of engagement. Be frank, so vendors can return the favor. What is your decision-making process? How long will it take? Explain the logistics of the selection process so the vendor understands your expectations for phone calls, discussions, and demonstrations. Include the terms of the process (e.g., your right to extend the selection process timeline if need be) to minimize association liabilities.

Cook’s notes:

  • Provide a reasonable deadline for submitting proposals. Vendors will need time to have internal discussions about the proposal and to develop a helpful response.
  • Don’t be tempted to say “no phone calls.” Your team and your prospective vendor partner need the opportunity to evaluate the critical components of a relationship – personal interaction, chemistry, and communication – before any decision is made. Discussions will help you separate the firms that “get you” from those that don’t. Give vendors the opportunity to provide a unique response based on your needs, not their offerings. These conversations may also help you to better define your project scope.

Creating a solid RFP and subsequently engaging in meaningful interaction with prospective partners helps ensure that you receive proposals that will meet your organization’s needs. It should also help you and your team gain valuable insight into your requirements and how the ensuing system selection and implementation processes will proceed, thus increasing your overall chances of success. And you can celebrate with something you cook up yourself! (Or just order in.)

Flickr photo by liz west

Subscribe to receive new DelCor blogs!



Peek into your org's IT Maturity with our self-assessment


Find our best events, white papers, and more.


In a fix, intrigued, or can't find what you're looking for?