Software Evaluation

   The format of the questions used in an RFP can make or break any project. For example, if an RFP uses the Yes/No response format it becomes very inefficient since it requires an individual question for each software feature needed to accomplish a specific business function. This forces your RFP to be extremely long, with many questions. This makes comparing and evaluating responses to this type of RFP very difficult and error prone. On the other hand, it is also very difficult to easily and accurately analyze vendor responses to an RFP using open-ended, essay-type questions, primarily because of the inconsistencies found in all the vendor responses.
   So just what are the right formats for a software RFP? One of the most useful formats is the Feature Support Matrix for collecting both Risk Assessment and Functional data regarding large, enterprise-wide software projects. The Feature Support Matrix is discussed below.

THE PROBLEM with YES/NO ANSWERS

# 1 - Feature Support Matrix

   This RFP question format is a very good way of identifying BOTH system feature AVAILABILITY, and the DELIVERY METHOD a vendor must utilize to provide that feature, in a completely quantitative format. This is ideal for collecting data used to determine the suitability (weighted grade point score) of a proposed software system to your needs, AND data needed to assess the RISK of it's implmentation.
   This type of RFP format is an excellent choice for RFIs & RFPs used to acquire enterprise-wide systems such as ERP, ERM, CRM software. The risk assessment is very important here because of the complex nature of the target environment and the amount of custom scripting or programming that is involved.
   To use this format, you should first put the following instructions (highlighted in green) at the beginning of your RFP's System Requirements section (or similar).