ITS - Intelligent Transportation Systems Report ITS Home Page

Successful Traffic Signal System Procurement Techniques

A Summary of Effective Processes


Federal Highway Administration


Technical Report Documentation Page

1.     Report No.
FHWA-OP-02-032

2.      Government Accession No.

3.      Recipient's Catalog No.

4.     Title and Subtitle

Successful Traffic Signal System Procurement Techniques

5.      Report Date

January 31, 2002

6.      Performing Organization Code

FHWA

7.     Author(s)

Erin Bard Ehlinger, P.E., PB Farradyne

8.      Performing Organization Report No.

9.     Performing Organization Name and Address

PB Farradyne

999 Third Avenue Suite 2200

Seattle, WA  98104

10.    Work Unit No. (TRAIS)

11.    Contract or Grant No.
Contract No. DTFH61-96-C-00048

12.    Sponsoring Agency Name and Address

Federal Highway Administration

Washington, DC

13.    Type of Report and Period Covered
Final Report

14.    Sponsoring Agency Code
FHWA

15.    Supplementary Notes

16.    Abstract

This short report outlines processes that are supportive of successful traffic signal system procurements. The processes are based on interviews of nine agencies across the US that have extensive experience in traffic signal system procurement. It addresses equipment as well as software and system procurements.

17.    Key Words
Traffic Signal Systems, Procurement Techniques, Controllers, Equipment, Software

18.       Distribution Statement

No restrictions. This document is available to the public through the National Technical Information Service Springfield, VA 22161

19.    Security Classif. (of this report)
Unclassified

20.    Security Classif. (of this page)
Unclassified

21.    No. of pages

22.    Price

Form DOTF 1700.7 (8-72)      Reproduction of completed page authorized


TABLE OF CONTENTS


1. Background and Purpose

2. Methodology and Inputs

2.1 Suggested Procurement Processes

2.1.1 A Process For Procuring Equipment/Hardware

2.1.2 A Process For Procuring Software and Systems

3. Needs Identification

3.1 Operational Needs

3.2 Functional and Equipment Needs

4. Communicating Needs In The Procurement

4.1 Procuring Hardware

4.1.1 A Process For Successfully Procuring Hardware

4.2 Procuring Software and Systems

4.2.1 A Process For Successfully Procuring Software and Systems

5. Other Keys to Success


Appendices

Appendix A:   Utah Department of Transportation RFP for Best Value Procurement of ITS Equipment (Controllers, Cameras, et. al.)



1.   BACKGROUND AND PURPOSE

Traffic signal systems are benefiting from the micro-computing and technology explosion of the past several decades. These new systems are more adaptable, more reliable, and often cheaper (in real dollars) than traffic signal systems of the past.  However, these new technologies, and new capabilities enabled by them, introduce difficulties in procurement. There are several reasons why modern traffic signal procurements are more difficult. The key differences relate to the following factors:

Text Box: What is a “successful procurement”? For the purposes of this report, a successful procurement is defined as one where the delivered product functionally and operationally meets an agency needs. This report does not directly focus on schedule or cost, except as they relate to the ability to procure systems that meet an agency’s needs. This technical memo outlines a suggested procurement methodology that can support agencies in defining their signal system needs and communicating those needs in a procurement. Specifically, it answers the following questions:





2.   METHODOLOGY AND INPUTS

This report is based on two key inputs. First and foremost, it is based on the input of staff at nine agencies responsible for traffic signals across the country. Table 1 provides the key contacts at these agencies, and notes the number of traffic signals in their systems. One of the criteria in selecting agencies to be interviewed was diversity in location, size of systems and type of control used. These agencies also have long histories of traffic signal implementation.

Table 1 – Interview Subjects

No.

Location

Interview Subject

Number of Signals

1

City of Dallas, TX

Beth Ramirez

1300

2

City of Portland, OR

Bill Kloos

965

3

City of Bellevue, WA

Dirk Mitchell

152

4

Hennepin County, MN

Jerry Smrcka

650

5

City of Chicago, IL

Chris Krueger

3000

6

City of Mesquite, TX

Rick Barry

87

7

City of Columbus, OH

Steve Jewel

910

8

City of San Leandro, CA

Ray Davis

58

9

City of Philadelphia, PA

Charles Denny

1000

The selected agencies reflect a cross-section of procurement and operating experience. Among them, the investigation was able to touch on experience with the following types of traffic signal control systems:

In addition, the agencies collectively represent expertise in operating under various types of signal timing schemes, including:

The second input to the recommendations are methods outlined in two National Highway Institute (NHI) courses: Intelligent Transportation System (ITS) Software Acquisition, and ITS Procurement. Both courses address traffic signal systems and are based on lessons learned from practitioners across the US.

2.1 Procurement Processes

Based on the interviews and the NHI course inputs, this report presents two suggested procurement processes that will contribute to successful procurements – one for equipment and one for systems and software. The figures, below, provide an overview of the suggested processes. The remainder of the report describes the steps in each process.

2.1.1  A Process For Procuring Hardware/Equipment

The flow chart, below, indicates that the procurement process for hardware or equipment is as follows:


Chart of sections 3 and 4 of this report


Each step is defined in detail in sections 3 and 4 of this report.


2.1.2 A Process For Procuring Software and Systems

The flow chart in the figure, below, indicates that the process for software and systems procurement is as follows:

A chart

Each step is defined in detail in sections 3 and 4 of this report.


3. NEEDS IDENTIFICATION

This section addresses methods to identify on-street operational (i.e. signal timing) and functional (i.e. equipment and system features) needs.

3.1 Operational Needs

All of the agencies interviewed noted that the best means to identify operational needs is based on an understanding of their own transportation network, combined with a depth of understanding of the capabilities of various timing schemes, including those already in place. This means spending time in the field, and driving around the area at different times of day, and on different days of the week throughout the year. Observing traffic from a control center using video cameras is also helpful.

Some agencies use consultants to make periodic reviews of phasing, timing schemes and overall signal timing plans. These agencies have the expertise to perform the work in-house, but are stretched too thin to do it. All agencies rely on consultants or their own staff to develop and model timing plans before they are implemented.

Another key input to understanding operational needs is public input. Two agencies noted that they use their public complaint logging system as a resource.

Using these types inputs, about one-half of the agencies contacted have already implemented or are considering adaptive control to improve traffic flow. Identifying corridors where traffic adaptive control would be helpful has been based on various approaches. The City of Chicago elected to participate in an FHWA-sponsored test implementation of traffic adaptive control. Their hands-on experience helps them identify candidate arterials for adaptive control.

One clear message was received in the interviews. The agency staff noted the importance of learning as much as they could from attending meetings, conventions, and seminars sponsored by local or national Institute of Transportation Engineers (ITE) and the Intelligent Transportation Society of America (ITSA). By visiting with their peers, vendors, consultants – as many resources as possible – they feel more confident in identifying operational needs.

And…

Be sure that your have the resources and technical capabilities to implement a new operational scheme. On the resources side, ensure that you have made every attempt to get the most out of your current system/timing/coordination scheme before changing. Keep the detection in good working order, check/update the timing regularly. As the City of Bellevue put it:

 “You must be able to apply resources to properly operate a signal system. A new timing scheme will not help you if you aren’t operating your current one. Get the most out of what you have first! Once you have reached the edge of it’s capability, then you know you need more. “

In terms of technical capabilities, ensure that you have the operational, engineering and field staff to implement new timing schemes. As technology introduces new capabilities, new skills are needed to match those capabilities. If you think you may be going beyond your skill set, work to get training, increase your capabilities, or decide to wait until you are better prepared.

Text Box: Summary Points – Operational Needs Identification § You must have an intimate understanding of how your own transportation network operates, 24 hours per day, 7 days a week. As one of those interviewed for this project noted: “If you just don’t know what timing plan/coordination plan is needed – you are probably right!” § Use public input. § If you don’t have the staff time, use consultants to help identify what is needed. § Use all the resources you can get a hold of. Go to ITE, ITSA, talk to peers, visit peer agencies, ask consultants, university staff – any resource you can access. §

3.2 Functional and Equipment Needs

Text Box: Functional and Equipment Needs Contrasted With Functional Requirements or Specifications At this point, it is important to clarify that we are outlining processes that help identify top-level needs, as opposed to detailed functional requirements and/or specifications. Developing detailed functional requirements and/or specifications is addressed under Section IV –Communicating Needs In The Procurement. This section addresses identification of functional needs and the equipment needed to meet an agency’s operational requirements. Functional and equipment needs go beyond timing plans and coordination schemes to address the details of how software and equipment provide the operations. They also address the full range of functions that define the business of traffic signal operations including maintenance functions, maintainability, reports, reliability, and other functions. Some examples of functional and equipment needs include:

All of the agencies interviewed agreed that the best way to identify functional and equipment needs is to bring together all of the “right people” and simply hash it out in a working session. Each agency, depending on their in-house capabilities, systems and resources has various means of ensuring that the “right people” are involved.

First, who are the “right people”? They must include staff knowledgeable in:

To help prepare for the needs working session, the agencies contacted for this report noted that it is important to review the latest in vendor products. Many products introduce new capabilities that address problems that  could not be addressed before. As one interviewee put it: “You don’t know you need what you don’t know exists.”

During these working sessions, specific equipment needs are identified based on your functional needs and operational goals. For example, identifying a need for central control software is typically based on meeting operational goals. In addition, reducing staff travel time to trouble spots is also a key input to selecting central control software.  All of the agencies relied on vendor demonstrations, on visiting vendor booths at trade shows (ITE and ITSA), and on visiting peer agencies to determine the type of software they needed.

Telecommunications needs are also covered in working sessions. Many agencies in the US are moving from copper to fiber optic communications systems. Most have noted that they need fiber optic to support video transmissions, or that the introduction of National Transportation Communications for ITS Protocol (NTCIP) compliant controllers increases telecommunications overhead so much that fiber optic is the only means to ensure adequate telecommunications bandwidth.  Three of the agencies interviewed stressed the importance of including maintenance staff on these conversations. Maintaining fiber optic cable and equipment is much different from copper. Staff must be trained in fiber optic technologies to ensure that the system is successful. In addition, fiber optic cable maintenance requires special equipment not typically found at most traffic maintenance shops.


Text Box: Summary Points – Functional and Equipment Needs Identification § Bring together all the “right people” and have a working meeting. Include operations, engineering, telecommunications, and field technicians. Use outside contractors to fill gaps in the required resources. § Bring the “right people” together more than once a year § Once again, use all the resources you can. Go to ITE, ITSA, talk to peers, visit peer agencies, ask consultants, and university staff – any resource you can access. § Review the latest in vendor products, keep on top of new developments.


4. COMMUNICATING NEEDS IN THE PROCUREMENT

This section defines methods to help procure products that meet clearly defined needs. The processes outlined below differ depending on whether the item being procured is a good (such as a piece of equipment or off-the-shelf software), a service (such as software development, or system integration) or a combination of the two (such as provision of central control system hardware and software). For clarity, the information is divided into two sections. The first addresses procurement of hardware or other fixed goods. The second addresses services or combinations of goods and services, which are characterized here as software and systems.

4.1 Procuring Hardware

Based on the interviews, two key issues were identified related to procuring hardware. First, there are difficulties procuring new technologies. (A technology is considered new in this report if an agency has not previously used it.) The second issue relates to sole source procurements. Several agencies responded by saying that the best way to ensure that you get what you want is to sole source. At the same time, they recognized that there are several downsides to sole source procurements.

New technologies are difficult to procure because there are no in-house specifications to rely on (other than the vendor-developed specifications), no agency experience implementing and operating the item, and no in-service experience to provide input to specification development. Because of these gaps in information and resources, a new approach is required to procurement.

The agencies interviewed provided insight into the pros and cons of sole source procurements. Many traffic signal systems are proprietary, and require that hardware be supplied by a single manufacturer. Typically, sole-source procurements result in marginally higher prices per unit. The agencies we spoke with did not mind paying the slightly higher price, as long as the vendor provided good service. In some cases, the sole source vendor did not provide good service, or the service level changed for the worse over the term of the contract. In these cases, the agencies wanted to be able to readily change to another product to maintain an acceptable service level.

Text Box: ”The key is to have a good relationship with the vendor /contractor where you are able to call them at any time and get answers. You need to be able to establish trust.” Agencies were also concerned about creating conditions that reduced the amount of competition in the market place. This concern related both to the level of price competitiveness and service competitiveness that can be maintained.

A few agencies noted that they prefer sole source for certain items because they can be assured that they get what they want. These agencies typically tested out equipment in the field before selecting a preferred product.



4.1.1 A Process For Successfully Procuring Hardware

Given the considerations outlined above, a process that eases procurement of new technologies and helps address the sole source question is suggested.

  1. Define your operational needs (as described in Section 3).
  2. Define your functional needs (as described in Section 3).

Text Box: Why Must I Define My Operational and Functional Needs? The two tasks above may seem trivial for items such as traffic signal controllers. After all, the operational and functional needs addressed by controllers are obvious. However, consider the introduction of the first NTCIP-compliant traffic signal controller at your agency. In addition to the operational and functional needs already addressed by your existing equipment, you must identify the operational and functional needs being addresses by implementing NTCIP. Simply stating you want NTCIP compliance, or saying that it is required by FHWA is inadequate to address procurement needs. Operationally, you need to ask yourself:do you want the capability to communicate with more diverse types of controllers, perhaps at intersections owned by another agency? Functionally, the NTCIP protocols address only a “base” level of functionality, and controllers will be interchangeable at this base level of functionality. Vendors are free to add functionality, but are also free to do so in a proprietary protocol. NTCIP specifically allows this by settings aside room in the protocol for “optional” functions. The functionality your agency has defined for controllers may exceed the base. You determine if any of the optional functionality provided by vendors is required to achieve the operations your agency needs. You must, then, specify the needed optional functionality in your NTCIP-compliant specification in your procurement.

  1. Define your technical requirements/specifications.

Once the operational and functional needs are clearly understood, they must be translated into specifications. It is critical to ensure that your specification outlines the complete environment in which the item will be operating. Note features of the communications systems, the operating software, the other components that will be connected and other key features. These should be derived from the operational and functional needs.

There are several approaches to developing specifications that meet your needs. The following provides some successful approaches:

  1. Consider a “best value” procurement.

A best value procurement allows you to combine features and price in your selection. Your specification may outline a minimum requirement. Responders should note how they exceed the specification. Based on the combination of price and features, make the selection.

Example Equipment Procurement

Appendix B contains an example RFP from the Utah DOT to procure NTCIP-compliant hardware, including signal controllers. This was a best value procurement, and has been highly successful. The procurement is provided as a good example of how to structure a best value, multiple vendor equipment procurement.


4.2 Procuring Software and Systems

Software and systems procurement poses similar issues as equipment and hardware procurements. However, the additional complexity of software and systems procurements presents additional concerns with respect to managing the procurement. Interviewees had attempted and looked for means to manage complex software and systems projects without over specifying the work. Overspecification of systems and software projects can lead to problems of inflexibility, inability to respond to introduction of new technologies, and constraining the software developer’s approach. The following process is based on the most successful systems and software procurements, and provides guidance on using the procurement process to help manage the complexity inherent to systems and software projects.

4.2.1 A Process For Successfully Procuring Software and Systems

The following process relates to the purchase of central control software and systems that require software or system development. In an abbreviated form, the process is also useful for procuring off-the-shelf systems, such as closed-loop systems. 

  1. Define your operational needs (as described in Section 3).
  2. Define your functional needs (as described in Section 3).
  3. Translate these needs to a set of system requirements.

At this point, begin adding detail to the operational and functional needs by defining functional requirements. There are five types of requirements:

Questions to consider include: Do you want remote dial-up operation? Alarms? What type? How should the user interface be configured? Do you want a GIS-based interface? A map? A line drawing? An aerial photo? You may need assistance in answering these questions.

The agencies interviewed for this report all agreed that the more detail you provide the better, especially when building rather than buying a system. This step takes considerable effort, but pays off. You may not find a system that meets all of your requirements, but you will have a base from which to start negotiations.

  1. Define your technical requirements.

Technical requirements outline required technical approaches to the solution. They include the type of computer or processor to be used, the computer language required, and the detailed components specifications. Only define the technical requirements that are absolutely needed for success. Note minimum requirements, and allow for technical flexibility in the responder’s bid. Many agencies have required that new off-the-shelf systems be implemented in such a way that their old equipment will be able to work in the new environment. These agencies were hoping to save money, and thought it would be too expensive to replace their existing equipment. In reality, it is often more expensive to hang onto old equipment that does not readily integrate with the new. Allow vendors to provide cost estimates to integrating the old items, as well as for replacing the old items and integrating new equipment.

  1. Rank the requirements.

Text Box: Build Versus Buy At this point, if you have been considering developing a new system, or procuring an integrated central software system, you should take a look at the ranked requirements. Can you get all or most of your “must haves” from off-the-shelf systems? If so, you should strongly consider going off-the-shelf. Do you really need to operate all your devices in an integrated environment, or could you operate each device using its iown software and a Windows-based operating system? Once you have developed your requirements in detail, rank them from “must have” to “highly desirable” to “don’t really need, but would be nice”. The items in the “don’t really need” category can sometimes be identified easily, because they often do not map to an operational or functional need. The ranked requirements can be used to assess vendor/contractor responses, and are very useful if using a “best value” approach to selection.










  1. Clearly list the requirements in the RFP/IFB.

Text Box: Requirements Must Be Clear The City of Chicago noted that their most successful procurements have been for closed loop signal systems. They attribute their success to clearly stated requirements. You may choose to reveal your rankings or not in the RFP or Invitation for Bid (IFB). You should also consider asking vendors to note in their bid which of your requirements are in their base package, and which are not. Ask them to price the features to be developed, or to note that they cannot develop them at a reasonable price. Consider procuring based on best value, not low bid. You can procure the system that provides the most features at the best cost.




  1. Additional considerations in the selection process.

Always check references. Also, consider paying a visit to a location where the system(s) being considered is installed. Many agencies perform these visits before the RFP to help them understand what is available. Visiting as part of the selection process will help you confirm the claims made by responders. You should have a checklist of items you are reviewing at each site you visit, to ensure a fair competition.

  1. Contract negotiations.

Text Box: Don’t Negotiate Away Your Contingency Budget. Be sure to have set aside budget to address contingencies. When was the last time a project went exactly as planned? We always encounter unknowns. Be prepared to address them with your budget.

You should try to ensure that you and your selected contractor agree on the requirements during contract negotiations. Spend time during negotiations discussing the requirements, adding clarifications if needed. Everyone interprets the written word slightly differently, and this can lead to problems. To help you during this process, you may want to walk through the vendor demo with the vendor Note in the RFP that this process will be part of negotiations.








Text Box: Procuring Traffic Signal Control Systems Using a Task Order Contract at the City of Portland, OR In their current system replacement project, which will integrate multiple jurisdiction’s’ signals, the City has followed the following process: 1. First, they developed a regional Advisory Committee comprised of all traffic signal operating agencies in the Portland area. 2. The first task was to develop a list of functional requirements. 3. A series of vendor/product demonstrations followed. 4. The functional requirements are being reviewed, based on what was learned from the demonstrations. 5. An RFP for a systems manager contract, which will allow the City and contractor to work together to modify/enhance the requirements, will be issued. If your requirements are extensive, and there needs to be a great deal of clarification, or, if you must do some up-front work before you can clarify your requirements, consider restructuring your procurement approach to allow you and the contractor to work together as a team to develop and clarify requirements. The task order contract approach, described below, can help.


















  1. Consider A Task Order Contract.

Task order contracts allow you to break the work into small pieces, managing each small piece individually. This approach provides a great deal of flexibility on projects that include complicated, technically difficult, or risky work. Under a task order contract, you and the contractor agree to the overall scope of services, method(s) of payment and other basic items up front. However, work cannot proceed until an individual task scope of work is written, costed, scheduled and agreed on by both parties. Write as many and as large a task as can be clearly defined.

One example of using a Task Order approach would apply to a closed loop system that is majority off-the-shelf, but is being modified to enable several special functions not included in the base system. You may choose to implement the base system under a Fixed Price task order. The special functions can be pursued as individual tasks. The tasks can be priced as fixed price, or based on cost reimbursement, depending on the nature of the work. For the new special features, begin with highest ranked one. Do them one by one, task by task, until the contract maximum is reached.

  1.  Define Your Acceptance tests.

It is important to include clearly defined acceptance testing procedures and acceptance criteria as part of the contract. In addition, several agencies cautioned to make sure to test each component of a system (or module or software) as the system is being built. Many had stories of trying to track down the source of a test failure when testing was done only once at the end of the contract. Acceptance tests mark the end of individual tasks. Staff from the City of Dallas noted that these procedures and criteria might change after the contract is signed, but that can be negotiated later on. If the acceptance tests are not included in the contract, you may not get them.

Summary – Systems and Software

Treat procurement as a continual process – not simply a fixed point. This means that you will not likely be able to completely communicate all of your requirements in such a way that your selected vendor will understand them the way you do. Allow time to clarify and work together during selection and after. The process outlined in this paper is designed to allow you to do just that. As one interviewee said:

“You may think that when you said you wanted red, that red was very clear. So the vendor gave you something you think is purple, but the vendor says is red. Make sure you agree on what RED is before it is too late.“

Example System Requirements

Appendix B contains an example of a requirements document developed by the City of Bellevue for their most recent procurement of an upgrade to their existing central control software system. Although the RFP seems detailed, they still believe they should and could have added more detail.


5.   OTHER KEYS TO SUCCESS

The agency staff that participated in the interview process had much to say on the topic of traffic signal system procurements. The following reflects some of their advice, and reinforces the processes suggested in this report.