Straightforward guidelines for reviewing RFI responses are detailed below. Consider following them if your organisation does not have formal RFI response reviewing and evaluation guidelines.
The objectives of reviewing RFI responses are to:
- identify good potential software solutions and
- create a short list of these vendors / software
- determine additional queries and questions to ask the vendors
- eliminate those vendors / software which clearly do not meet your needs
Reviewing RFI responses is a multi-stage process. Start with initial checks and a quick review. Then move on to more detailed RFI analysis and evaluation. You will need to determine how critical – compliance with the initial checks and review is. For instance, will you reject a RFI response (vendor) that fails one of the initial checks or review criteria?
Initial checks include:
- Is the RFI response in the right format? Eg email document say word or pdf file attachment – which ever you requested.
- Or if you requested paper – are there no more than the maximum number of pages you stipulated?
- Is the RFI response sealed?
- Received on time?
- Sent to the right person / department?
- Is the correct RFI reference number stated?
- Are vendor contact details included eg named contact, phone and email address?
- Sent more information than requested eg supporting documents, sales brochures, demo CD’s?
Review all responses for:
- Completeness. Are there answers to all the questions you asked? Do you have all the information you requested?
- Quality. Is it a considered, detailed and realistic response or is it a rushed, copy and paste job?
- Clarity. Is it clearly written, with no unnecessary jargon or marketing speak? Can you easily understand the RFI response?
- An indication of how keen the vendor is to work with you eg meeting your time scales, offering additional help etc.
RFI analysis and evaluation
The quick initial checks and review of the responses may well identify likely potential solutions. So the emphasis for RFI analysis and evaluation may turn to eliminating vendors which do not meet your needs.
Firstly, create a list of your absolute minimum and/or mandatory requirements. Then check each RFI response against this list. Eliminate all responses that clearly do not meet your minimum and/or mandatory requirements.
If you are left with a relatively large list of potential solutions, repeat the process, but at a slightly more detailed level ie compare the remaining RFI responses against your key essential requirements. Consider using an evaluation matrix, with weighted scoring, similar to this example.
There will inevitably be parts of the responses or answers to questions that you are just not sure. These will require clarification – so collect these up for each RFI response. But before you contact the vendors for resolution, review them. Do the number and type of queries that you are asking change your thoughts on the likelihood of the proposed solution to meet your requirements?
Once you have the responses, add them into your evaluation and rework accordingly. Where possible eliminate more vendors. Depending upon the numbers left (say 7 or 8); rank the potential solutions into two categories:
- The 3 or 4 most likely potential solutions / vendors, to ‘short list’ and pursue further
- The next 3 or 4 solutions, which meet most of your requirements. As ‘runners up’, they may be worth a considering, if the short listed vendors turn out to be not as good as you thought.
However, if you are struggling, a quick comparison chart may be of help. See the Comparison Chart of RFI Responses example, which you can download and amend for your use. It’s a simple summary of the potential software solutions / vendors, based on the RFI evaluations. The emphasis is on where the requirements are / are not met by the software solutions – to assist in creating a short list of the best solutions.
Issues from the RFI
New issues may arise from the RFI process and reviewing RFI responses. You will need to consider and include them within your system selection process as appropriate. For example:
- How have your requirements (business, technology, processes etc) changed as a result of going through the RFI process?
- Have you now seen potential solutions that you had not considered before? In addition, how would you be able to incorporate these?
- How will you include these in your requirements? If there are substantial changes, do your requirements need to be re-approved?
- What additional questions / criteria do you wish to add into your RFP?
- What questions / criteria have been answered in the RFI and can be removed from your RFP?
- Is your project budget still accurate? Does it need amending?
- Is your outline project plan still valid? Can you still select a new system and then implement it by your desired due dates?
Report on your evaluation of the RFI Responses
Prepare a report to pull all your RFI response evaluations together. Consider including:
- A report summary
- The Comparison Chart of RFI Responses
- Recommendations – such as to accept your short listed solutions and move on to the next stage(s) of the selection process
- Summary of each RFI response covering details of the potential software solution eg requirements fit (or not), technology, outline costs, vendor reference customers, vendor profile, vendor contact details
- Carefully and clearly, document your reasons for short listing potential solutions as well as for eliminating potential solutions / vendors. You may need to revisit this later on eg when questioned by the board or auditors.
- An overview of the work you have undertaken to review the RFI responses.
Finalising the review of RFI responses includes:
- Presenting your evaluation report to your board, steering group, user group as relevant
- Obtaining their acceptance of your results and approval to proceed with the short listed vendors
- Informing the short listed vendors
- Informing the unsuccessful vendors – they may not like the news, but knowing is better than not knowing.