Considerations when responding to an RFI or RFP (a view from the receiving end)

Having been on the receiving end of Request for Information (RFI) and Request for Proposal (RFP) responses, from an evaluation perspective there are ways respondents can make it easier for the evaluation panel to assess what it is being proposed and ultimately have greater success on getting through to the next round. These considerations are from my experiences with Software package selection and with Delivery partner selection, but should be applicable to many other selections.

1. First impressions count.

Even before the RFI/RFP response is opened, an evaluator can be swayed by the presentation of the response and the level of engagement getting there.
Key considerations:

• Ask questions during the response period to validate any areas lacking clarity, but don’t go overboard.
• Make sure you meet the response times.
• Use good quality paper and colour (if required to present a  paper copy).
• Binding can make a document look classier.
• If the response requests that all questions and communication go through a particular person or channel, then abide by this. 

2. Make it easy for an evaluator to find information they are looking for.

When performing an evaluation I will assess the RFI/RFP response against an evaluation template where I score the responses from each vendor. In order to ensure that I am being fair in terms of the evaluation, I assess each line item of the template across all RFI/RFP responses at the same time, as opposed to scoring each vendor separately and then moving on to the next.
Key considerations:

• If there is a RFI/RFP response template provided, use it.
• Have a table of contents on Page 2 (or thereabouts) of the document, and ensure there are page numbers throughout.
• Have your logo on the front page of your response. This makes it easier when the reviewer is looking through documents from multiple vendors.
• Be very clear about what is and isn’t included in any pricing. Even if you have the information in a scope section, it is worth highlighting the key inclusions, exclusions and assumptions in the pricing section too so that if an evaluator is looking at each solution in parallel you are not seen to be overly expensive or hiding something.
• Don’t have information split across multiple documents, unless explicitly requested to. 

 

3. Consider what an evaluator is likely to be assessing the solution against.

Whilst there are a number of questions asked in an RFI/RFP, there may be other things that an evaluator is wanting to see demonstrated in the response. If the response is silent about something, then the evaluator may rate this lower than it should be.
Key considerations:

• Show an understanding of the requirements.
• Explain how the proposed solution meets the requirements. Diagrams are good.
• Show an understanding of the business / industry sector.
• Use case studies that are in the same region / country where possible.
• Cover the methodology that is proposed to deliver the solution (if appropriate). This should however not read as if it is a shopping list of methodologies straight from a text book.
• Explain your level of flexibility to adapt the methodology and/or solution to better fit the organisation.
• Demonstrate thought leadership and best practice guidance. This may be by providing alternative solutions or explaining standards or processes that will be adopted.
• Explain different pricing model options you are open to; Fixed, Time and Materials, Monthly, Pay per use, ...
• With a software package selection, explain what is possible with configuration, what will entail customisation / development, and if so how this will impact any upgrades.
• Explain additional opportunities your solution provides.
• Cover whatever else you think is of interest to the evaluation panel.