Please Note: All Infotivity RFP Templates are designed to totally AVOID the mistakes listed below and also other, less common problems.
Infotivity has been in the Request for Proposal (RFP) industry since 1989, and has worked with quite literally thousands of RFPs since then. Over the years we have documented many RFP problems and the best way to mitigate those problems. The ones listed below are the most harmful in terms of their negative impact on the RESULTS of a software selection project.
The single most FATAL problem to avoid in any RFP is allowing vendors to enter their own "free form" text answer to each RFP question. Allowing vendor "free-form" text answers will, by definition, always lead to significant amounts of wasted time that is measured in days, not hours. In addition, "free form" text answers will always lead to the inability to accurately evaluate the suitability of each vendor RFP response (proposal) to your organization's needs.
Why is this so? The "free form text" type of answer format forces you to MANUALLY EVALUATE and SCORE each answer in EACH vendor RFP response (proposal) before they can be compared! Since each vendor can build their own answer then each answer will be unique. This forces the need for manual review and interpretation, and scoring according to a benchmark of some sort. Think about the implications, they are huge, especially when evaluating large software systems such as ERP, HRIS, CRM, and many others that have large numbers of questions, also known as RFP criteria. This means that if your RFP has 2,500 questions, a.k.a. criteria, then each vendor response you receive will have 2,500 answers, all of which will have to be MANUALLY reviewed and scored. If you have received proposals from 5 different vendors then you will be forced to MANUALLY REVIEW 7,500 answers (5 proposals times 2,500 answers each = 7,500 answers!).
After more than 31 years of Request for Proposal (RFP) preparation I am seeing a troubling practice that causes many unnecessary problems, and even more project delays, grow in popularity. More and more, I see RFPs that use four, five, six, or even more columns to capture vendor responses to each RFP question. This practice is definitely not how to write an effective RFP, and always leads to serious, sometimes fatal, RFP response evaluation problems and project delays.
Absolutely the single most fatal mistake one can make when preparing an RFP is to use separate columns to contain each of many possible vendor response types. This makes "apples-to-apples" comparison of complex vendor RFP responses almost impossible, a very fatal problem when one considers the fact that evaluating/comparing vendor responses requires far more time and effort than writing the RFP ever did! Perhaps almost as bad, calculating a weighted score is made much more difficult and error-prone. (Please Note: All Infotivity RFPs use a unique one column response system designed to prevent these problems.)
The type of RFP layout I am talking about reserves a specific column to hold each type of possible RFP response, and requires vendors to enter their response by marking the appropriate column. An example of this type of problem-prone RFP layout is shown below:
In the above example, the RFP is organized so that columns D, E, F, G, H, and I are labeled to receive each of the following vendor response types:
Vendors are instructed to mark the appropriate column to indicate their answer to each RFP question. For example, to respond with "Yes" the vendor would place an "X" in column D, to respond with "No" the vendor would put an "X" column E, and so on. Each possible vendor response is in a different column of its own, and serious mistakes come up when trying to use this type of RFP layout.
The mistakes are numerous and often fatal. The most serious are:
A more detailed description of each of these mistakes is found below. (Note: Infotivity RFPs use input validation, a one column response system, and other safeguards to prevent these problems.)
In the above sample RFP layout, the tops of columns D - I are labels Y, N, CO, C, RW, and TPP for clarity. Think how confusing things become when these labels go out of sight as you scroll down the screen while reviewing a vendor response! Think how confused the vendors get when trying to respond to the RFP. At best, a lot of time will be wasted to resolve errors, but what if a serious flaw "slips through the cracks" unnoticed in all the confusion?.
The RFP example uses six (6) columns to hold each of six possible vendor responses. That alone makes fast and easy side-by-side comparison of vendor responses impossible and very cumbersome since now six (6) columns must be copied and pasted into six (6) corresponding comparison matrix columns.
In addition, these six columns prevent direct "side-by-side" comparison of vendor responses because the responses are never directly "side-by-side", they are always at least six or more rows apart. For example, imagine you are comparing just 4 different vendor responses, and wish to compare the first and last ones? They are separated by at least 24 columns! Depending on how many characters are used for the RFP criteria and other spacing they could even be on separate pages. An enterprise-wide system can easily have over 3,000 criteria. Comparing that many criteria 24 columns apart, maybe even on separate pages, is painstaking, error-prone work!
To get around this problem some commercial RFP products come with special software designed to compare vendor RFP responses. But why should you have to buy, install, and learn software just to buy software? Even if free, the installing and learning process uses up valuable time!
Using separate columns to hold different response values makes calculating a weighted grade point score extremely difficult, time consuming, and error prone because the formula must all refer back to multiple, different columns to gather the data needed to calculate the score. The formula now need to access different response columns, making it much more complex than what is needed for one. What if a change needs to be made? What if new criteria need to be added and the wrong column is used?
Comparing the weighted grade scores of each vendor proposal is also made very difficult for many of the same reasons a response comparison is made difficult. Referring to our example, the issue of six (6) response columns comes up, and also the issue of spacing. Again, what if a change needs to be made? Simply calculating the score is difficult, let alone the issue of displaying the core in the correct column.
>Again, some commercial RFP products probide the option to buy special software designed to calculate scores for vendor RFP responses and then compare those scores. But why should you have to buy, install, and learn software just to buy software? Even if free, the installing and learning process uses up valuable time!
Return to the TOP of the RFP Mistakes/Ripoff Page.
WHAT USERS SAY...
5,200+ Facilities Worldwide
Memphis Light (MLGW)
Certified SCM Consultant