Successful Traffic Signal System Procurement Techniques
A Summary of Effective Processes
Federal Highway Administration
Technical Report Documentation Page
1. Report No. |
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. |
||||||
12. Sponsoring Agency Name and Address Federal Highway Administration Washington, DC |
13. Type of Report and Period Covered |
|||||
14. Sponsoring Agency Code |
||||||
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 |
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) |
20. Security Classif. (of this page) |
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:
- The Maturity Of The Technology. Technologies for traffic signal systems are relatively new and rapidly changing. Sometimes, the technology changes so quickly that what is specified at the beginning of a project may change by the end.
- Design Criteria And Standards. Because the traffic signal technology and associated capabilities are so dynamic, there are few, if any, design or process criteria and standards to guide implementation. It is difficult for traffic engineers to determine what type of traffic signal control timing plans (and supporting software) they need, what type of detection hardware is best, and so on. Some agencies have expressed a desire for FHWA to provide specifications that will help them successfully procure systems. Others have hoped that FHWA might develop approved lists of equipment and software, certifying that it will meet certain requirements.
- The Ability To Innovate. Because the traffic signal system/technology industry is constantly introducing new technologies, new software solutions, and new concepts, imaginations are sparked and innovations are more frequent. It is common for traffic signal system projects to include new software, new components that have never been integrated before, new communications methods, and new institutional processes. Innovative projects require management processes that are adaptable and responsive to changes as the projects evolve.
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:
- Functionally and operationally, how can agencies define their traffic signal system needs?
- How can those needs be translated into a signal specification that can be successfully procured?
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:
- Closed-loop systems
- Centralized, majority-off-the-shelf, systems
- Centralized, new software, or not majority off-the-shelf systems, including control platforms that integrate signals, dynamic message signs, and cameras (although the focus will be on the signal control elements).
- Isolated signal systems, and local-master signal systems
In addition, the agencies collectively represent expertise in operating under various types of signal timing schemes, including:
- Fully actuated
- Time-of-day (TOD)
- Time-based coordination (TBC)
- Traffic responsive
- Traffic adaptive
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:
- The first step is to define your operational needs.
- From that decision, your functional needs can be defined.
- With the funcitonal needs understood, you can either define your technical requirements/specifications; consider a best value procurement; or do both.
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:
- First, define your operational needs.
- Next, based on the operational needs, your functional needs can be defined.
- The functional needs are then translated into a set of system requirements. The system requirements clearly define what the system should do.
- Next, the system technical requirements/specifications can be defined.
- Both the functional and associated technical requirements/specifications should then be ranked from most to least important.
- Next, you can either list all the requirements in a Request for Proposal (RFP) or Invitation for Bid (IFB); consider a Task Order contract; or both. At the same time, you should define your acceptance tests.
- Next, you can identify special considerations for the selection process.
- Last, after selection, contract negotiations can begin.
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.
3.2 Functional and Equipment Needs
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:
- the need for an integrated platform for signals and other ITS systems or devices
- the need for longer component or equipment life
- the need to be able to generate reports
- the need for a particular brand or type of controller
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:
- Operations
- Engineering
- Planning
- Law Enforcement
- Transit
- Field operations and maintenance - the staff that will be installing and operating the field components.
- Telecommunications engineering and equipment experts – especially if you are using fiber optic cable or wireless communications
- Management/decision-makers.
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.
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.
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.
- Define your operational needs (as described in Section 3).
- Define your functional needs (as described in Section 3).
- 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:
- Rely on your peers. For new devices, specifications need not be written entirely from scratch. Ask around – you are probably not the very first agency to implement these devices. Use the specifications others have developed – but make sure you quiz the project engineer on the pros and cons of the specification.
- Rely on vendors. Some agencies have used vendor specifications to develop their own specifications. There are some cautions to be heeded when doing so. First, be careful if you are pulling together a specification that is based on combining features from several different items. You may not be able to purchase an item based on this “hybrid” specification. Also be careful not to over-specify so that only one responder can bid. Lastly, be concerned about the implementing environment. The specifications must work in the field. Consider the temperature extremes, the vibration, moisture and humidity, and the amount of use the item will receive. You can add these items to the specification and ask for a warranty. You may have to pay for the warranty, but this may be money well spent.
- Have vendors review the specifications before you procure. You can send your specifications directly to vendors, or issue a Request For Information (RFI) asking vendors to respond to the draft specification. You should check your state and local law to determine if an RFI is allowed in your jurisdiction. Typically, the RFI process requires that each comment receive a formal response, and that all comments and responses be available to all responders. Your laws and policies may dictate a different processes for RFIs, and you should check with your contracting office to confirm your processes.
- Test vendor samples. In cases where there is a potential for a large purchase, vendors often are willing to supply free test samples to agencies. Be sure to define the test clearly, and document the results including the installation parameters. Allow vendors to change out early failures – you might have received the anomaly in the batch. Be scientific in your test approach so the results are defensible, particularly if you choose to go sole source after testing. Specifications for an open procurement can be developed based on the test results.
- Procure one item each from several vendors. Write your specification as best you can, and issue an Indefinite Quantities Contract (IQC) that allows you to purchase from multiple vendors that meet your specifications. Note in your procurement package that there is no minimum purchase. Buy one item from each vendor, and test them (as noted above). Based on the test results, you can procure additional items from only those vendors that perform well on the tests. You’ll only be stuck with one or two “clinkers”, rather than a complete purchase that is less than desirable. This approach also mitigates somewhat against the problems associated with sole source procurement.
- 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.
- Define your operational needs (as described in Section 3).
- Define your functional needs (as described in Section 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:
- Functional (e.g. capabilities, manual/automated, equations)
- Performance (e.g. response time, capacity, security, safety)
- Interface (e.g. to/from devices, other systems or jurisdictions)
- Inputs (e.g. sources, ranges)
- Outputs (e.g. destination, frequency)
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.
- 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.
- Rank the requirements.
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.
- Clearly list the requirements in the RFP/IFB.
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.
- 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.
- Contract negotiations.
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.
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.
- 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.
- 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.
- If it seems too complicated or difficult, it probably is. If you can’t get help or training, keep it simple. Keep to the basics both operationally and functionally.
- Involve your procurement and contracting staff early on. When procuring new technology, there are many options available beyond the traditional procurement methods for road and bridge construction.
- Having a signal testing lab at your agency or available to you from another agency greatly contributes to success.
- Low bid does not work well for new technologies, or for software development. These items are not readily described in detail. Instead, select based on qualifications, or a combination of qualifications and costs, if a portion of the work can be costed.
- Assign responsibility and risk appropriately when developing a project and a contract. For example, the City of Chicago bundles their closed loop systems with the required telecommunications infrastructure. This allows the contractor to provide the complete system, and avoids any issues with systems installed by others. If you must use an existing telecommunications system, ensure that you set aside resources for potential testing and modifications.