Low Quality Surveillance RFPs

Published Feb 23, 2012 00:00 AM
PUBLIC - This article does not require an IPVM subscription. Feel free to share.

In our international integrator survey, respondents raised numerous concerns about low quality surveillance RFPs. In this report, we explain and examine their specific concerns.

Overview

Request for Proposals (i.e., RFPs) are a common method of purchase solicitation, favored by government, institutional, and municipal entities looking to buy large or complex systems. When a lot of money is spent on systems, more often than not, RFPs are issued. The goal, at least theoretically, is to find the best possible solution at the lowest available price.

For background, see our series of reviews on RFPs, examining good and bad aspects of them.

Concerns

We frequently hear industry professionals raise concern about the effectiveness and fairness of RFPs, and by extension, the security consultants and specifiers you create those proposals. Indeed, this has been a major element in heated discussions we have had about security consultant conflict of interest and the Axis Corruption Cruise.

The Question

Given the interest in this topic, we asked 100 integrators the following question:

Here are the key findings from the results:

  • 1 in ever 6 integrators said they were not familiar enough with RFPs to comment.
  • Of the 80%+ integrators with experience, a clear majority (54%) voted that they were not very satisfied.

Here's what it looks like graphically among the integrators who were familiar with RFPs:

Analyzing the survey results, 4 common 'negative' themes emerge

  • Cut 'n Paste: The "cut 'n paste" or "boilerplate" methods of writing these packages are not effective.
  • Incompetent: These packages are often written by people who do not fully understand systems being described.
  • Rigged: The final outcome of the process has been previously determined.
  • Slanted: RFPs are written for specific products that only a few vendors can provide.

Cut 'n Paste

The quality of RFP specifications are commonly viewed as poor, due to the re-using the same languge from one specification to the next. Taking a specification 'off the shelf' and then modifying select portions of that document often results in a specification that:

  • is technically impossible to satisfy
  • insufficently reflects what the customer is asking for
  • does not represent current technologies

Many integrators expressed dissatisfaction with this practice.  Here are a selection of their comments:

  • "Sometimes when cut and paste is used to reduce engineering cost, it can be confusing to get to what is really needed."
  • "most are cut and pasted from a mfr spec and are not right for the job"
  • "Most of the tendet docs issued by consultants are a lazy cut and paste with multiple contridictions and little helpful info."
  • "Typically we see canned RFPs with the same cut & paste info only changed in product quantities with very little actual information in regards to actual project objectives."
  • "Most RFP's are written around 20 year old technology taken from a boiler plate spec that's been used 1 million times in the past. Typically they are not project specific and offer nothing in the way of innovation."
  • "Just now i am bidding on an Airforce Base that has VCRs listed in the Scope of Work. no one ever re-writes specs, they only paste into them."

At best, generic specifications are so dilute of detail the do not effectively communicate user needs. At worst, these specifications are a mashup of disparate technologies that are not interoperable.

Incompetent

Integrators expressed frustration at the lack of product knowledge reflected in the specification package.  This lack of knowledge can result in an 'impossible specification' to meet or drive up system costs due to unweildy integration.

  • "RFP usually include numerous contradictions such as must be Lenel access and Honeywell video and must integrate. Or must be HD cameras with a minimum resolution of 480TVL."
  • "Most RFP's I see are a complete mess. 80% of the security consultants I come across are old school analogue guys who have no understanding of IT infrastructure and are afraid of servers and IP cameras. This is the biggest challenge in our industry in my view and one I dont see going away for quite some time."
  • "They are written by consultants who have never installed a camera or reader before. As a result, they ask for things like training DVDs, etc. They never establish criteria for service performance."
  • "Most bids/RFPs that we receive are lacking significant technical detail. We do a very good job of designing a solution to account for anything that the RFP may be lacking." "That said, we often don't win those jobs b/c our price is higher out of the shoot vs. hitting the client up with change orders later."
  • "Often written by consultants who use industry buzz-words to impress their customer but don't know what they are actually talking about."
  • "Usually they are poorly written by people who don't know enough about the product or service they are seeking."
  • "There are too many consultants that dabble in IP video or access control that don't understand the technology. Poorly written documents result in widely spread pricing results and too many loopholes. In the end, a shady contractor bids what he thinks he can get away with and then change orders the Owner for the consultants mistakes."

The RFP process is designed to solicit 'apples-to-apples' proposals, and permit a cost based comparasion. When the specification is poorly written, some responders will 'troubleshoot' discrepancies in the design and submit those costs as part of the bid quotation. Other repondents will choose not to consider solving design problems 'up front', and will wait until the project performance phase to address gaps via 'change order'. In this case, the RFP specification has not satisfied its purpose of clearly defining the proposed project.

The final outcome of the process has been previously determined.

Many integrators suggested that the RFP process is an exercise in semantics, simply a matter of lawful process in closing 'someone else's sale'.  

  • "normally not satisfied because most RFP's we do are for government facilities...lets just say the winner is already decided at the beginning."
  • "We stay away from RFP's as they are very high effort/low margin sales and usually have been pre awarded in a back room deal before the bids are opened."
  • "...unless we have helped write the spec we usually dont bid openbids because they are a waste of time and usually setup for 1-3 larger integrators"
  • "Most are either skewed to a specific vendor or do not provide enough information to prepare a proper response..."
  • "you are basically bidding on something that is flawed from the start or could be biased towards a particular party making it impossible to win."

Integrators can spend significant dollars preparing proposals, and some proposals require bid bonding. The true cost of resonding to an RFP can be significant.  When integrators are asked to engage in a process where the outcome has already been determined, it reinforces the hesistation to participate in these activities. 

RFPs are written for specific products that only a few vendors can provide.

Integrators expressed dissatisfaction with the tendancy of RFPs to 'write-in' specific equipment with no alternatives. This limits competition not only in terms of product, but also from the field of potential integrators.

  • "Unfortunately, more times than not RFP's in this area are very crafty about "specifying" particular products without identifying them by name."  
  • "RFP's are typically RFQ's with the wrong title... and most RFP's that really are proposal requests are not written to solicit competitive equality."
  • "Most of them are prepared for certain product/supplier and almost impossible to propose alternative product. For example: Camera must have MxPEG compression..."
  • "...seems most RFPs are written for very specific equipment or are not well researched."

This complaint is certainly not unique only among businesses responding to surveillance RFPs, and is often cited as a general disadvatange to the method of RFP Procurement.  

The Very Satisfied

A notable niche, 10% (8/84) of respondents, said they had 'very satisfactory' experiences with RFPs. The approach of these respondents was typically to understand and address the opportunity behind the RFP rather than focusing on only complying with the technicalities of the response. They indicate that RFPs prequalify a customer's desire for a new system, and that through the strength of initial response, these integrators are able to form a consultative sales relationship with the solicitors.

 

Conclusion

Often, RFPs intend to 'level the playing field' by specifiying performance parameters, but integrators view the people writing the RFPs often as uninformed, wastefully specific, or otherwise work to accomplish the very opposite result of the unbiased, clean result the process intends to provide.

Some integrators choose not to repsond to RFPs at all, instead opting for 'consultative sales' based on an in-depth study of customer needs. For the customer, this approach often limits competition, but results in a much more fleshed-out proposed design.  Unfortunately, this also discourages fair competition for these opportunties, and these 'public funded' opportunities become vulnerable to collusion.