Web Analytics Made Easy -
top of page

Writing an Effective RFP for Security Systems


Like this article?

Visit our Security Tips page for more than 75 additional articles on a variety of topics related to physical security

Follow us on Twitter to be notified when new Security Tips are published

  • Twitter

Security and facilities managers commonly issue a "Request-for-Proposal" (RFP) when purchasing an electronic security system such as a video surveillance system, access control system, or intrusion alarm system. For larger projects, an independent security consultant or engineer may be hired to create formal design documents and draft a specification, but for smaller projects, the security or facilities manager is often left on his or her own to prepare the RFP.

Within this article, we provide some ideas that will help you to write an effective security systems RFP and help you to avoid some common mistakes made by beginning RFP writers.

#1. - Do Your Homework First

Before writing the RFP, carefully define what problems you are trying to solve and how the type of system that you wish to purchase will help you to accomplish this. If there are multiple people in your organization that have input on the purchasing decision, try to reach internal consensus on what will be done and how it will be purchased.

Do some research to educate yourself on the types of systems that you are considering buying and to gain an understanding of common product features and options. Meet with security system vendors to have them explain their system offerings and to provide product demonstrations. Be honest about your intentions; explain that you are doing preliminary research before writing an RFP, and that at this stage you are only seeking to educate yourself on what's available. (Don't waste the vendors time by asking them to prepare a formal proposal if you are only doing preliminary research.)

Talk with your peers at other organizations to see what types of systems that they are using and how well they have worked. Visit online security forums and/or subscription-based surveillance product research services (such as IPVM) to get product reviews and to participate in discussions concerning product capabilities and system design. If possible, attend seminars or security trade shows (such as ASIS's GSX or ISC West) to gain a better understanding of the range of product options that are available.

#2. - Determine How You Will Specify What You Want To Buy

Once you have figured out what you want to buy, you need to determine how you will specify it within the RFP. This part of RFP preparation is known as "specification writing" and is a complex subject that even design professionals such as architects and engineers struggle with. 

There are numerous methods of writing specifications, but a complete description of all of these methods could fill a textbook and is beyond the scope of this article.

To make things simple, we will describe three basic ways to write a specification when preparing a security system RFP. Professional specification writers will probably take issue with the semantics and oversimplification in the narrative that follows, but it should provide basic guidance to the security or facilities manager when writing a security RFP.

The first method of specifying is what we call the "Proprietary Method". Using this method, the buyer describes specifically what he wants to buy and specifically how he wants it installed. This method typically includes a detailed product description, including manufacturer name and model number. An example of this type of specification would be as follows:

"Contractor shall provide two (2) Acme Model #1123 Electronic Sirens in the warehouse area. One siren shall be installed on the north warehouse wall, one siren shall be installed on the south warehouse wall. Both sirens shall be mounted in the center of the wall at a height of 12'."

The advantage of the Proprietary Method is that it gives the buyer complete control over what is being purchased and how it will be installed. When evaluating proposals, it is easy to compare results because each proposer is bidding "apples-to-apples". The disadvantage of this method is that it places complete responsibility for system performance upon the buyer. You must do your own homework to make sure that what you specify will do the job. Also, proprietary specifications may tend to limit competition which may in turn result in increased costs.

The second method of specifying is what we call the "Descriptive Method". Using this method, the exact characteristics of the equipment are described in detail, but manufacturer's names and model numbers are not used. Details on how the equipment is to be installed are also provided. An example of this type of specification would be as follows:

"Contractor shall provide two (2) electronic sirens in the warehouse area. Siren shall be 6" trumpet style paging speaker rated at 15 watts with integral amplifier and siren tone generator. Siren shall operate at 12 VDC and provide both yelp and steady tones. Siren cone shall be constructed of ABS plastic. One siren shall be installed on the north warehouse wall, one siren shall be installed on the south warehouse wall. Both sirens shall be mounted in the center of the wall at a height of 12'."

The advantage of the Descriptive Method is that it gives the buyer some control over the types of products being purchased, but gives the proposer flexibility in choosing products. This often results in increased competition and lower costs. The disadvantage of this method is that it requires the preparation of a detailed specification for each system component. This can be time consuming and beyond the technical capabilities of many buyers. It is also somewhat more difficult to compare proposals "apples-to-apples" when each proposer is proposing a different combination of equipment.

The third method of specifying is what we call the "Performance Method". Using this method, the buyer describes the desired end result, but leaves it to the proposer to determine how this result will be accomplished. An example of this type of specification would be as follows:

"Contractor shall provide electronic sirens that can be heard clearly throughout the entire warehouse area. Sirens shall be capable of producing two distinct siren tones. Minimum sound level produced by sirens shall be not less than 65 dBA throughout the warehouse when measured with a sound level meter."

The advantage of the Performance Method is that it gives the proposer total freedom in system design and product selection. This can result in creative solutions to your problems and very competitive prices. This method also places responsibility on the contractor rather than the buyer for achieving the desired result. The disadvantage of this method is that it can make proposal evaluation very difficult; each proposer may be offering a completely different solution and price and it can be challenging for a non-technical person to make an intelligent comparison between proposals. It can also be very time consuming to write a good performance specification - expectations must be clearly and completely spelled out and terminology carefully defined so that there is no confusion.

There are many, many variations on the three methods of specifying that we have described above. For example, one may use the Proprietary Method, but list more than one manufacturer and model number; or use the Descriptive Method, and list multiple manufacturers and products that can meet the descriptive requirements.

Most private businesses can use any method of specifying method that they choose. Most government entities are restricted on the types of specification methods that they can use, and often cannot use the Proprietary Method except under very special circumstances.

3. - Avoid Common Specifying Mistakes

There are several common mistakes made by inexperienced specification writers. These mistakes include:

Specifying a Product that Doesn't Exist

When conducting product research, buyers sometime evaluate the products of several different manufacturers, and then select the best features of each. They then write a specification that includes all of these features in a single product. The problem is, no single manufacturer's product can do everything that is being asked for, so the product being requested in the specification can't be provided by the contractor.

Mixing Methods of Specifying

The general rule is, the more specifically you tell a contractor how to do his job, the less responsible he is for final outcome of the project. You, not the contractor, become responsible for the integrity of the design. 

For example, if you specify an exact quantity of a specific model of electronic siren, you cannot then turn around and complain when the sirens aren't loud enough. If the contractor installs the specified product at the specified locations, you cannot hold him responsible if the results you obtain fail to meet your expectations.

This mistake often occurs when buyer writes a specification using the Proprietary Method, but then adds a few lines of requirements using the Performance Method. An example of such a specification would be as follows:

"Contractor shall provide two (2) Acme Model #1123 Electronic Sirens in the warehouse area. One siren shall be installed on the north warehouse wall, one siren shall be installed on the south warehouse wall. Both sirens shall be mounted in the center of the wall at a height of 12'. Minimum sound level produced by sirens shall be not less than 65 dBA throughout the warehouse when measured with a sound level meter."

This type of specification places the bidder in a quandary - does he bid the project using the quantities and products specified by the buyer, or does he bid the project in order to meet the sound level requirement? 

This "tails I win and heads you lose" type of specification writing creates project uncertainty and is responsible for many change orders and contract disputes.

While skilled specification writers can sometimes get away with mixing specification methods, the beginning specification writer should generally pick one method of specifying each project and stick with it.

Careless Use of the Phrase "Or Equal"

Many buyers start out with a specification written using the Proprietary Method, perhaps using a manufacturer supplied specification as a template. They then decide that, to keep things competitive, that they should also allow the products of other manufacturers to be considered. To achieve this, they simply add the words "Or Equal" at various places with the specification document.

The problem with this approach is that rarely are security or surveillance products ever truly "equal". Specifications written for one manufacturer's product can often never be directly applied to the product of another manufacturer. This is particularly true for things like video management systems (VMS) and security management systems (SMS), where system architecture, application design, and terminology can vary greatly between manufacturers. Trying to enforce the requirements of a specification written for a product different from the one actually being supplied can be a nightmare.

While skilled specification writers can sometime make judicious use of the words "Or Equal", the beginning specification writer is urged to avoid this technique completely. If you wish to allow the products of multiple manufacturers to be considered, you are far better off writing a specification using either the Descriptive Method or the Performance Method.

Inserting Non-Essential Requirements in Specifications

The specifications should only contain requirements that give you the desired end-product and that are essential for the success of your project. Novice specification writers often insert non-essential language into the specifications because they think that "more is better" or because they think that the use of this language makes the spec look more "professional". In many cases, this language is lifted directly off of a product data sheet provided by one or more equipment manufacturers. Some examples of this type of language are:

"Product shall comply with ANSI 301.1, NFPA 101, and UL 692" 

(Do you really know what these standards mean and why they are important to your project?)

"Controller board shall be 3.25" wide x 6.5" high"

(Unless there is a specific space limitation, why do the size of the boards matter?)

"Equipment cabinets shall have a light blue, acrylic paint finish"

(Does the color of the cabinets installed in the electrical room really matter?)

"Manufacturer shall have been in business for not less than ten years." (Can you justify the ten year requirement? Why would a manufacturer that had only been in business 9 1/2 years not be qualified?)

Requirements such as the ones listed above tend to limit competition and restrict product choices. Manufacturers often deliberately insert such requirements into their factory specifications in an attempt to block the use of a competitor's product. For this reason, good specification writers tend to avoid the use of factory specifications, and if they do use them, careful edit out requirements that are non-essential and that restrict competition.

4. - Define Realistic Schedule For Project Delivery

The expected schedule for project completion should be clearly spelled out in the RFP. Be sure to allow time for contract negotiation, equipment purchase and delivery and contractor mobilization in addition to the time required for the actual installation. Setting too ambitious of a schedule can increase costs and sometimes discourage qualified contractors from submitting a proposal on your project.

5. - Accurately Describe Working Conditions

The RFP should clearly spell out the working conditions that the contractor will be expected to comply with while he is working at your facility. These include things such as:

  • Working hours

  • Security and safety requirements

  • Availability of parking

  • Loading./unloading procedures

  • Availability of storage for tools and equipment on-site

To avoid problems, you must clearly define working conditions in advance. These can have an impact on costs and must be understood by the contractor before he prepares his proposal. It is unfair to the contractor to make him comply with working conditions that he did not know about when bidding the project. For example, telling a contractor that his technicians can only work on the premises after regular business hours, or telling him that he must park his service trucks a mile from the job site is not something he should find out about only after the project has begun.

6. - Define Expectations for Support Services

Support services such as training, system programming and configuration, and warranty service are not free and cost the contractor money to provide. Unless your requirements are carefully spelled out in the RFP, it is likely that each contractor will be proposing a different level of support.

For example, each contractors idea of what constitutes "training" may be different. One contractor may be planning on hiring a professional trainer from the manufacturer to conduct formal classroom training, another contractor may be only planning on having one of his technicians spend a few hours with you briefly explaining the system.

Unless requirements for training and other support services are clearly spelled out in the RFP, this can be a major cause of discrepancies in bid prices, and a major source of controversy when the contractor delivers less than what is expected.

7. - Get Real With "Boilerplate" Requirements

Most organizations have some form of standard terms and conditions that they typically attach to RFPs and other contract documents. 

Usually, these same terms and conditions are used to purchase anything from a box of paperclips to a tractor-trailer rig and they contain many requirements that may not be applicable to the typical security or surveillance project.

Before incorporating standard terms are conditions into your RFP, carefully review them to determine if they make sense for your specific project. In particular, look at things such as insurance requirements to make sure that they are reasonable and appropriate considering the size of your project. Asking a contractor to have $5,000,000 in liability insurance for a $25,000 video surveillance system project probably doesn't make sense and can drive away all but the very largest of contractors. This can limit competition and increase bid costs.

8. - Describe The Desired Proposal Format

The desired outcome of RFP process is to receive proposals from security contractors who are qualified to work on your project. The proposals must contain enough information to allow you to properly analyze them. To make them easier to review, proposals should be formatted in a similar manner and provide the same degree of detail.

To make sure that the proposals you receive are relatively consistent, clearly specify the types of information that must be submitted with each proposal and how it should be organized. The typical security or surveillance systems proposal should contain at least the following information:

  • Background information on the proposer's company, including qualifications and experience with similar projects.

  • Narrative that demonstrates contractor's basic understanding of project requirements

  • Itemized list of products and services to be provided including breakdown of material and labor costs.

  • List of optional products and services offered or recommended.

  • List of exceptions taken to specifications and areas of non-compliance with requirements of RFP.

  • Detailed project schedule.

  • Resumes of key team members who will be working on the project.

  • Project references.

  • Proof of ability to comply with licensing and insurance requirements.

  • Product data sheets.

9. - Describe the Procurement Process

To make the project go smoothly, your procurement process should be clearly understood by potential proposers from the very start. It is recommended that a detailed set of instructions be included in each RFP. These instructions should contain at least the following information:

  • Date and time that the proposal is due.

  • Date and time of pre-proposal conference and/or job walk-through.

  • Name of person in your organization to contact with questions concerning technical or administrative requirements of RFP.

  • Availability of floor plan and site drawings.

  • Procedures for requesting additional tours of the site (if offered).

  • Process for requesting formal clarifications of requirements of RFP.

  • Process for requesting the use of substitute products (if allowed).

  • Cut-off date for questions and the issuance of final addendum.

  • Proposal evaluation criteria and selection process.

  • Expected date for interviews with finalists. (if needed)

  • Expected date of contract award and notice to proceed.

If you have any questions concerning the preparation of security systems RFPs, or need help in writing your RFP or evaluating proposals, please contact us.

bottom of page