Design-Build - A Better RFP Process?

Almost everybody in the security industry has a horror story of a "low bid" system installation that has gone terribly wrong. Many city, county and state government entities are avoiding those pitfalls with a "design-build RFP" approach to procuring video surveillance and access control systems. In this note, we examine the reasons why, take a look inside the design-build process, its potential and pitfalls.

Why Design-Build?

A couple of key drivers exist:

• Not Commodities: Complex video surveillance and access control systems are not commodities that purchasing departments should buy like photocopiers or paper goods. Generally, low bids lead to low quality systems and headaches for those that have to use, manage, and maintain them. With design-build, price is not the sole determining factor for award.
  
• IT's Role: IT departments play an integral part with IP-based security systems, many times furnishing the network infrastructure as well as managing the day to day network support of the system. They want to review and approve the system and hardware components, make sure they have the ability to support them, and identify any potential network interference and hardware issues before they can happen.
  
• Security managers play a more active role and feel they can determine their objectives and needs with a minimum amount of input from (or without) an engineer or consultant.
• The traditional bid process can be a lengthy ordeal. Many times a system installation cannot wait due to an existing system being down, a recent crime that made the news, an upcoming special event, or budget/grant funds that must be encumbered quickly before they are lost.
• Designing Up Front: Traditional bid projects usually requires hiring an a consulting engineer to complete detailed design drawings and specifications for the system, which can be a considerable expense of time and money, regardless if the project is awarded or not.  If the engineer is not well-versed in these systems, the integrator will end up having to redesign them. With design-build the engineer has a different role, generally to assist with budgeting, prepare generic project drawings as needed, provide a system description and a basic specification of the system and components.

Developing the Design-Build RFP

The process starts by assembling a team from within the organization that includes a representative from each department that will be involved with procuring, using, managing and maintaining the system. A city team usually includes project management,  attorney's office, purchasing, IT, security/police, facilities and maintenance. On larger projects, this team usually includes a consulting engineer in a different role than a bid project with responsibilities to develop a project budget, produce generic project drawings as needed, assist with developing design objectives and produce performance-based specifications. The consulting engineer also plays an important role in the proposal review process, but generally does not have a vote in the selection process.  

The team defines the objectives of the RFP, project schedule, the contractor's responsibilities, the responsibilities each department has in the project's implementation, and response scoring criteria are determined. The purchasing department includes this into a standard boilerplate design-build RFP template. The RFP is usually broken down into separate pricing and technical sections. Usually, the pricing and technical sections of the proposal are weighted differently (ex. 60/40), but the team can determine how they wish to categorize, weight and judge the responses and the criteria are included in the RFP. Here is a good example of a design-build RFP from the City of Tampa, FL.

The Tech Details of a Design-Build RFP

The technical details specified in a design-build RFP can vary but differ from traditional RFPs in the following key ways:

• Rather than having a consulting engineer doing a full system design as with a typical bid, a design-build RFP will outline the system objectives, operational characteristics, and desired outcomes and leave the bulk of the design responsibility up to the responder.
  
• Drawings, if provided, are not permit or installation ready drawings, usually consisting of floor plans to show the desired camera and equipment rack locations or to indicate which doors are to receive access control and where control panels should be located.
• Specifications, if provided, are generally less-detailed than in traditional bid documents, focusing more on operational characteristics and perhaps giving example model numbers or a list of acceptable manufacturers.

Responding to a Design-Build RFP

Responding to design-build RFPs is much more involved than a standard bid project which is usually a price sheet and a couple of legal forms. Most of the time, what constitutes a typical bid response makes up only part of the pricing section of a design-build proposal. A typical design-build RFP response for a large project is a major undertaking, requiring submitting multiple copies of a binder full of information in tabbed sections as outlined in the RFP. 

One key element of the RFP response is the technical narrative, this is where the respondent technically describes their approach to the project, offers their recommendations for hardware and software, and explains in detail how the system in will function and operate.  This is where the technical committee will focus their attention.  The technical people are the gate-keepers, nobody gets past them without approval, but they usually aren't the final decision makers. 

RFP Response Suggestions

Here are some suggestions for integrators to consider when preparing a design-build RFP response.

• Pay particular attention to the rating or scoring criteria in the proposal. Sometimes sections like experience can count as much as the price or technical approach. Here's an example from the Tampa RFP:

• Include an "Executive Summary" of less than one page at the front of the technical narrative section for the non-technical committee members to get an overview. The technical folks know how to find page 2.
  
• Go into specific details in the technical narrative. The IT and technical people want details, especially when it comes to the network, and it's security. Here's an example of good and bad responses that were included in the Tampa RFP showing the level of detail they expect:

Proposal Review and Award

Each agency has strict law and rules on how RFPs are issued and how the responses are processed. They can vary greatly, but here is an example of how some of them work. Just after the response deadline, a quick public opening takes place where the proposals are unboxed and a list of responders is generated, no pricing or other details are revealed or discussed. After this public opening, the purchasing department and city attorney will review each response to verify that it contains all of the required information and legal qualifications are met as listed in the RFP. If a proposal does not include the required information, it can be labeled as unresponsive and be rejected.

The proposal binders are then sent to two different committees, a technical committee and a selection committee. Many times, the pricing will be removed from the binders prior to distribution to the technical committee so it does not influence the review. The technical committee, usually consisting of the consulting engineer and IT staff, will review the technical merits of each proposal as compared to the RFP requirements and label each as "Does not Meet", "Equivalent" or "Exceeds".  The technical committee will present their findings to the selection committee, in a public meeting if required by law.  

The selection committee generally focuses on the non-technical parts of the proposal such as the responder's experience, references, insurance/bonding, D&B ratings [link no longer available], company financials and system cost. Financial and experience reviews can be key factors on large projects, to ensure that a company can complete the project. The selection committee meets to score the reviews based on the criteria in the RFP, tabulate the scores and ranks the responses.  This meeting often takes place weeks after the RFP response due date. Here is an example of a winning RFP response for a project in the City of Hagerstown, MD.

Many times the committee does not declare a winner at this review and scoring meeting. Often times, they will "short-list" the three highest-ranked proposals and schedule a presentation and interview meeting where the responder has a period to formally present their proposal and present a product demonstration if requested and the committee has a period to interview the responder and ask questions. Most design-build RFP's include this short-list option. After the interview process, the committee will make their selection from the short-listed responders.

Why Competent Integrators Prefer Design-Build

Most competent integrators prefer the design-build approach as it allows them to compete with a more focused holistic approach and not just on price. They are typically not low bidders and shy away from most bid projects. Design-build also allows them to select equipment that they are familiar or certified on as well as using design approaches that they specialize in. The design-build format favors them as the responses are detailed, technical and require a significant amount of man-hours to complete, which is a luxury most smaller companies do not have.

Risks of Design-Build

When done properly, the risks in design-build are lower than with than traditional bid projects. However, there are bad RFP's that get released frequently that have problems such as:

• Not properly defining the RFP requirements: If it's a million dollar project, the owner should put requirements in the RFP so that only companies that have experience level are considered. If the specification is generic (for a DVR and 30 cameras), they could get bid responses with home-built recorders and cameras from an unheard of manufacturer from companies are not even in the security market. 
  
• Poor technical review: If the consulting engineer and technical review committee are not familiar or competent with networking, IP video surveillance or access control systems, the proposals cannot be reviewed properly which can lead to a poor system installation or additional costs.
• Poor company review: If references, project experience or company financials are not thoroughly vetted for larger projects in the review process, it may lead to a contractor experiencing financial difficulties or defaulting on the installation.
• Picking a winner: As with any judging process, the results can be subjective. A good design-build RFP will often return half a dozen or more proposals. With non-technical selectors, a good score can come down to appearance and layout rather than the content. A proposal can be technically competent, but a lackluster presentation in other areas can lead to lower scores.
  
• Salesmanship: Although the RFP process precludes a lot of salesmanship, if short-list interviews are required, it can come down to who gave the sharpest presentation and responded best to the Q&A.