How to judge responses to your association's RFP

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

What do you do when all the responses to your RFP look good, or it seems like you’re comparing apples and oranges? How do you decide which one to choose? How do the judges on Chopped do it? We don’t have the inside scoop on cooking competition shows, but we’ve helped hundreds of clients select the best solution and vendor for them.

Develop selection criteria and weighting.

Let’s back up a bit. Before sending out an RFP, develop the criteria you will use to make a selection. You can certainly adjust this if you discover new criteria while reviewing responses, but the more you can eliminate bias from your decision and agree upon what’s most important, the more likely you’ll choose a solution that truly meets your needs. This also comes in handy when leadership later asks on what basis your choice was made.

Selecting a new vendor or system? Download our RFI and RFP Cheat Sheet to start your new selection process on the right foot


Examples of selection criteria could include:

  • System objectives/desired functionality
  • Experience (especially with similar associations)
  • Financial viability
  • Staffing, including the breakdown of staff (e.g., developers, PMs, etc.)
  • Understanding of the project
  • Integration experience/capabilities
  • Corporate philosophy and methodology
  • Support after launch
  • Training
  • References
  • Vendor reputation
  • Price

Establish a weight for each criterion; for example, price might have a 10% or a 50% weighting. Think about how you’ll evaluate subjective criteria such as responsiveness, likability, and personal interaction. How much weight do they get compared to other criteria? The total of all criteria should equal 100 (no matter what your high school coach said, you cannot give 110 percent!) and should provide a useful basis for group discussion regarding vendor selection.

Review and score the proposals.

As proposals come in, let each vendor know that you received theirs. This is a good time to remind them of the next steps you will take. 

Before scoring, review the proposals to see if any have incomplete or ambiguous information. Follow up with vendors on missing information and any points needing clarification. Ask additional questions if it will help. 

Take note of the vendors who didn’t completely provide the requested information. Their error may be an unfortunate once-in-a-blue-moon oversight or it may be a sign of things to come. Don’t judge yet, but keep this in mind as you move forward. 

You’ll find that a solid proposal is actually a good learning opportunity and will help you better evaluate other proposals. Ask vendors to address any inconsistencies within their submitted proposals.

Determine the breadth of your review process. Typically each member of the core project team evaluates and scores the proposals on their own. Then the team meets to discuss, compare, and agree on a consensus score. If your organization requires a broader exposure to proposals, the review team may expand (which could further complicate matters); that said, a well-balanced core project team has representation from all key areas of the association.

While scoring proposals, keep these questions in mind:

  • How well does the proposal speak to your needs, challenges, and goals?
  • How much attention did the vendor give the proposal? Is it boilerplate or sloppy? For example, is another association’s name on it? Seriously, it happens.
  • Do they “get” associations? Do they have experience working with associations like yours? Will they understand the culture and politics involved?
  • Do they talk about how their strengths will help them address your needs or do they mention competitors’ weaknesses (“talking smack”)?

Price is important; but your system, technical, and support objectives are most important. If there’s a large range in price, talk to the low and high bids to find out why they came in at that number. Remember to treat each proposal with confidentiality and respect.

If the timeline presented is very different from yours, find out why. Maybe yours isn’t realistic. Speaking of timelines, let the vendors know if you’re running behind schedule; this is just another example of the importance of properly setting and managing expectations through good communication, which is essential to any technology project.

Spend time with the finalists.

At this point, you should only be considering proposals from 3-5 vendors because you narrowed down the field of prospects before sending out your RFP. Take time to speak to each of the finalists still in the running. Yes, it’s time consuming, but it’s a critical step. No matter how complete the proposal, it can’t tell the whole story. There are limitations to the written word. 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.

Ask each vendor the same questions so the process and outcome remain fair for all. You’re interviewing these vendors for a very important job – to help your organization advance its mission. Treat them, and the experience, with the necessary respect and rigor.

If you haven’t had demonstrations yet, arrange for scripted demonstrations that focus on your needs, not any new and shiny objects the vendors may wish to show.

After you make a selection, let each vendor know the outcome. You don’t want to leave them hanging and wondering if they should make a call to follow up. Keep in mind that the deal is not sealed until the contract is signed, so use tact when notifying unsuccessful competitors; you never know when you might need to go to “Plan B.” It also helps to provide constructive feedback when possible, so that vendors can bring their best game to the next selection in which they are involved.

The selection process is just one phase in the project cycle, yet it’s a very critical phase. If you don’t select a solution and vendor that meet your requirements, your new technology won’t meet expectations and needs. 


Should you issue an RFI or an RFP?  Before you cast a wide net for software vendors and solutions, use our  checklist to determine which approach—a request for information or a request  for proposals—is more fitting. Download the Cheat Sheet

Flickr photo by Mitch Groff

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?