What are the key items and details that an end-user should be looking for in a security systems RFP?
Pearson: As an end-user, the key items and details to some extent depend on the type of RFP being generated. The RFP could be for materials, labor or both; however, most end-users writing an RFP are interested in a turnkey (both material and labor) RFP. Usually the end-user would be using the RFP to get pricing as well as some additional information from the vendor. The end-user should provide the following types of information to the vendors as part of the RFP:
Any laws or guidelines that must be followed;
Expectations such as time tables, time of day when work can be performed, special access issues, project walk through, etc.;
Warranty, quality of work, etc.;
The method of communication desired by the end-user for doing business with the vendor. (The AIA has a document A305 that can be used to collect this type of information);
Permits required for the project; and
Ongoing maintenance costs that might be incurred.
Carter: The best RFPs are the ones where the architect, engineer and CIO have all given their input into how to converge the building’s systems. If you consult experts on all your systems while developing the RFP, you’ll get a cohesive design and a complete systems approach with many benefits to the end-user. My advice is to engage your security integrator while your architect and engineer are designing the building — before they define final building systems, complete drawings and select the contractor. Doing it that way will translate to fewer changes to the project during construction, better use of materials, lower labor costs, better integration, improved delivery time and fewer headaches.
Ahrens: A clear defined scope that identifies the following:
Introduction to the project, the functionality desired, trade references (U.L, etc) and the end-result of the engagement. Contract requirements, insurance/bonding, references, submittal requirements and line-item pricing;
Technical criteria, such as the space required on a hard-drive, redundancy, frame rate and storage; and
Warranty, training, installation requirements and as-built documentation to indicate the installed state of the equipment.
Aggleton: The RFP should be formatted to match the latest CEI numbering scheme and section layout so that candidate contractors can navigate easily and accurately. The document starts with a general description of the project to orient the bidder and permit them to make a quick bidding decision based on size, content, complexity, geography and schedule. Preliminary RFP sections should include descriptions of existing conditions, standards to be met, related work, support service requirements (e.g., commissioning, testing, training, warranty and maintenance) and proposal requirements.
What key items and details are not generally included in a security systems RFP but should be?
Carter: Today’s physical security systems can utilize the building’s IP infrastructure and can be integrated with voice, data, public address, climate controls and other technology. That being said, many RFPs continue to look at these as individual systems while not leveraging the benefits of a cohesive design/build approach. There are significant initial and lifecycle cost savings in the coordination of these systems. Providing a coordinated design/build package covering all of these systems would reduce issues during construction, provide better performance during occupancy and save end-users money in the long run.
Aggleton: The RFP should be very clear on the delineation of work included in the contract and work by others that requires coordination; for example, door hardware being installed under the general contract but being connected and put into operation by the security contractor. Often missing from an RFP are clear criteria for what constitutes system acceptance, the requirements for submission of verified as-built drawings before system acceptance and the qualifying date for the start of warranty services.
Pearson: There are a few items that are missing in most RFPs, such as providing full detail of the project and how the RFP fits into the overall plan. For example, an end-user may have to request additional funding when the cost exceeds the planned estimated cost. The end-user’s management may need to approve or modify the project based on some information that is gained during the RFP process. The end-user should request the vendor provide any inclusions and exclusions they would suggest and what value they add. The end-user needs to know which items the vendor keeps in inventory.
Ahrens: It varies, however, the items I most commonly find delinquent is the as-built documentation and training requirements for the systems being installed. Grounding, electrical isolation and protection for exterior equipment are also items that are not generally included.
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.
