Roundtable Discussion: RFPs

Some of the nation’s top security experts weigh in on strategies to create a successful Request For Proposal


What are some of the red flags/errors that you are seeing in typical security systems RFPs?

Aggleton: If an RFP is too open, it is more difficult to compare competitive bids, and the “leveling” process will require multiple iterations. In addition, lack of specificity can lead to excessive change orders, budget increases, schedule delays and animosity between client and contractor.
Ahrens: The big errors relate to IP products and services. In some instances, I see that RFPs are calling out shared computer network connections. This is a big mistake. Network cabling should only be coordinated and not provided typically. There are big issues with network infrastructure, which improperly installed, could cause a great deal of damage as the result of a security systems installation. Other red flags include: Using blanket statements to cover specific, expensive and highly technical items. A RFP that uses a blanket statement such as “provide a TCP/IP network” has a lot of room for error — what is that network, and how is the cable installed? Another example: “Provide an interface from the access control system to the HR database” — there is a lot of room for guesswork and assumptions. Including products or services not required could indicate that the RFP was not technically peer reviewed.

Pearson: On the end-user side of the RFP, there are several areas that can be red flags to the vendors. For example, writing very tight and expensive-to-implement specifications when that level of effort does not add any value; proposing due dates that are unrealistic; poor specifications on a performance-based section of an RFP; and writing a specification around a specific product and using requirements that are not important to the overall system performance are all red flags to the vendors. Sometimes an end-user will use an old boilerplate for some of the specifications that are out of date, which causes confusion for the vendors.

Carter: Many RFPs do not coordinate systems while continuing to utilize traditional approaches to the delivery of security systems. Specifying the security systems (intrusion, access, CCTV, etc.) as individual systems does not take full advantage of the ability of those systems to communicate and support the others. Additionally, the lack of coordination with other building systems does not allow for the realization of all available cost savings. We also see many RFPs that mix performance and product specifications. Utilizing a design/build approach and involving the security integrator during the design development process will provide the most practical and effective solution for both the product and performance requirements of the end-user.

What does an RFP tell you about a potential customer/vendor partner?

Carter: The RFP identifies which stakeholders have been involved in the design process and have had input in the RFP. It will also show whether cohesive design and coordination around all of the building’s systems, such as controls, security, fire, voice, IT and data has been identified. A university recently involved the design/build security integrator to coordinate more than 20 disparate systems within the campus. This coordinated approach permitted the development of a single control center, reduced costs for the installation, enhanced abilities to provide system changes during utilization and an enhanced performance model for the end-users. This state-of-the-art application provided a unique teaming relationship with the customer and vendor that created value for each party.

Pearson:
A close review of the vendor’s scope of work may show that it was not thought through or critical steps are missing. Typos or misspelled words may indicate lack of experience or a lack of focus on the details. Even with pre-qualifying vendors, the information provided should differentiate those that the end-user wants to work with who are knowledgeable and those that are not. For example, one vendor could indicate in their RFP that they will provide a full-time project manager as part of their proposal. This would be an important value-added feature, and if the other vendors did not offer this capability or were misleading about the project manager being full-time at the end-user’s location during the project. The overall quality of the vendor’s RFP response gives some insight as to the quality of the responding company. The vendor should provide details on exactly how it will complete the project, who they are, what value they add to the project, and provide suggestions and project cost.

How important are security benchmarks and metrics in the RFP process?

Aggleton: Benchmarks provide a target for an industry-accepted level of quality and performance, but in some areas, such levels should be considered minimums and the bar should be set higher. Metrics are important in specifying performance criteria but comparison of such data from different manufacturers is often difficult or impossible due to lack of measurement standards.

Carter: With technology changing rapidly, the successful implementation of today’s security systems hinges on being able to benchmark systems design and evaluate the metrics in similar facilities. Using the security integrator in the design development process allows for the implementation of those benchmarks, and introduces best-in-class approaches to security integration and the application of multiple systems for long-term application for the facility users.

Pearson: They are very important to ensure that all parties (end-user and vendor) understand what is important and how progress is measured while minimizing confusion of either party. Benchmarks and metrics typically are developed from the past mistakes of the end-user. For example, monthly or weekly meetings may be required to measure progress. In this case, the meeting schedule would be defined as part of the RFP. The inevitable “change order” will come after the project starts. A process should be defined in the RFP that details how the change orders will be handled and the basis for which payment will be made. If the end-user is not knowledgeable about the best benchmarks and metrics to use in the RFP, a qualified professional should be hired before the RFP generates a contract.

Editor’s Note: These integrators will meet again to further discuss RFPs as part of a follow-up podcast. Be sure to check out SecurityInfoWatch.com in February.