Before You Start an RFP, Know What You Want

Lewis Carroll wrote, “If you don't know where you are going, any road will get you there.” That statement is also true of a request for proposal.

You should start the process by knowing what you want, then clearly defining and describing it. This approach will be helpful to both you and the competing vendors. An RFP with a poorly defined feature set and unclear selection criteria will create a lot of confusion for vendors and additional work for you.

Identify Requirements for Your Proposal

Before creating our recent RFP for Chromebooks, we started the process by obtaining one of every Chromebook we were told was worth considering. We then dropped each of them multiple times from desktop height onto a hard tile floor. We removed from consideration those Chromebooks that could not survive the falls undamaged.

Then we tried to pick the keyboard keys from the remaining models. We used the specifications of the two remaining Chromebooks to create the feature set for what we wanted in the RFP.

Vendors will want to know your feature set. For Chromebooks, the feature set may include the make, model, RAM, processor and other features common to the selected devices. It is also acceptable to use a make and model of a device in the RFP. For E-Rate–funded RFPs, if you use a make and model of a device, you must include the words “or equivalent.”

For complex proposals, the RFP will request that competing vendors indicate where in the document to find the features asked for in the feature set. This extra detail will reduce the time necessary during selection to assess whether the proposal meets the required features.

Outline the Proposal Selection Process

In addition to the feature set, you should also create a detailed “selection criteria” prior to publishing the RFP. The selection criteria should be included in the request. We included our criteria as an appendix in the document. It contains the following sections:

Proposal reject. If the proposal does not meet the basic criteria outlined in the RFP, it will be rejected without further consideration. Basic criteria may include:

• Does the proposal match the format asked for in the RFP?
• Does the solution in the proposal match the feature set?
• Did the vendor attend the mandatory reading of the RFP?

Only proposals that meet all of the outlined criteria will move to the next stage of assessment.

Cost. This section accounts for 50 percent of our scoring in service-centered RFPs, like an infrastructure upgrade, and 60 percent of scoring in commodity-centered RFPs, like Chromebooks. Our spreadsheet cost formula looks like this: “=((MIN($B$11:$Z$11)/B11)500*)”, *where 500 points are given for this section. Read the formula as “(lowest cost of all bids/this bid) points for this section."

Supportability and cost to transition. This section may include criteria like:

• Is the vendor available locally for support?
• Does the vendor have adequate and properly certified support staff?
• Will the proposed solution integrate well with current infrastructure?
• Are current staff prepared and properly trained to implement the solution? We often give this section 20 percent of the total score.

Customer references, vendor capabilities. This section may contain criteria like:

• Has the vendor done similar work with your district previously?
• Does the vendor have references from other customers?
• Has the vendor shown evidence of performing a similar size job?

Again, this may account for 20 percent of the total score.

Additional services and features. This section may apply points for value-added services or features above what was asked for in the RFP. It may be best to wait until the proposals have been received to create details for this section, because vendors may offer creative solutions that were not considered when the RFP was created. This section may get 10 percent of the total score.

Evaluate the Proposals

There should be multiple people evaluating the proposals, including a member of your district’s financial or business department. A larger, more diverse team will lessen the impact of one person giving unrealistic scores to a single proposal, which could sway the end result.

The actual selection team may look like this:

• Director of technology, CIO or team leader
• Lead technician
• Building technician
• District business manager

Having fewer technical members on the selection team will necessitate deep explanations of the selection criteria. This is a good thing, because being too close to an issue can cloud the team’s vision and make it hard to see obvious shortcomings in a process or product.

Nonvoting technicians should be available to explain technical issues. Allowing technical staff to look through and analyze the differences between all proposals before the selection team meets will expedite the process. Another round of questions may go back to the competing vendors to clarify points in the proposals.

If you are experienced with spreadsheets, a Google spreadsheet works well for multiple team members to input their evaluations. Consult another colleague who’s adept with spreadsheets to ensure that all formulas are correct. Nobody wants to be embarrassed by discovering an incorrect formula during a board meeting.

Choose a Winning Proposal

If your district policies call for the vendor with the lowest price, you can stop at the second selection criteria. If your district allows you to choose the best solution, your selection criteria should provide you with what we describe as “the highest-scoring responsible bidder.” The criteria also will provide you with solid documentation in case your winner is challenged by another vendor or your board of education.

Finally, notify all competing vendors. In addition to being polite, it is good for the vendors to know why they won or did not win. Next time, all vendors will be better prepared to provide you with what you want at the best price. After all, isn’t that what we are all after?

Read more about the RFP process here.