U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

4.9  Procurement Options



This chapter describes various procurement options, types, and techniques available for the acquisition of Intelligent Transportation Systems [ITS] and some examples of how they can be used.

The following are options that can be used for obtaining services to develop ITS projects. Agencies with an internal pool of technical resources may elect to develop the entire system in-house. Most agencies will use a combination of in-house, system managers, Systems engineering technical assistance, and oversight for ITS projects and then procure under a separate contract, the development and integration services.

In-house Development

System's owners who elect to use the internal resources and capabilities of the organization to perform the development activities should use the processes described in this Guidebook. Internal agreements should be written and signed between the system's owner and development teams as though they were procured from the outside. In addition, there should be an independent review [by another division, agency, or independent consultant] of the products and activities. Even though the development is done internally, an independent review team is recommended in order to provide a sanity check on the development. This will build confidence in the project and help identify and manage project risks.

Contracted Services

The following is a brief description of two basic classifications of procurement common for building transportation capital projects:

  • Engineering and Design Services: In traditional infrastructure construction, this type of procurement is used for the planning and development of the Plans Specifications & Cost Estimate [PS&E]. The contractor selection [for this type of procurement] is based on qualifications.
  • Construction services: In traditional infrastructure projects, construction follows PS&E. It is the installation phase of the project. Construction contractor selection is based on the bid price.

In this Guidebook, reference is made to Consultant, System Manager, Systems Engineering Technical Assistance, System Integrator, and Independent Verification & Validation [IV&V]. These contracted services are used to carryout various aspects of ITS project development. It is recommended that the Engineering & Design Services procurement option be used to contract for these services. This allows the agency to select the appropriate team based on their qualifications, not on the lowest price.

Construction services [low bid process] should continue to be used for routine ITS field elements [poles, cabinets, pull-boxes, and installation.], building the TMC, or standard items such as Model 170 or 2070 controllers with standard modules. The Construction services option is NOT recommended for the other system development services noted above. That includes specialized hardware and software procurement or development and integration.

Some key procurement issues and techniques related to ITS developments

The following is a brief description of the primary types of contracts used in ITS procurements, plus relevant issues and techniques associated with each.

Fixed Price: System's owner contracts a single price for all products and services to implement the project. This is sometimes referred to as low bid or lump sum.

Fixed Price is usually associated with the low bid used with Construction procurements. This type of contract transfers the project risks to the contractor. When there is a cost overrun, the contractor absorbs this overrun. If they perform better than planned, the contractor's profit is higher. In ITS developments, the System's owner who uses a fixed price contract needs to know exactly what is expected and clearly specifies it to the contractor. Standard performance specifications must be in place and special provisions documented for the work to be contracted. If not, the contractor can interpret the vague scope of work in their favor to meet profit goals [e.g. reduced documentation, testing, proprietary solution].

Since all risks are absorbed by the contractor, a fixed price bid will be higher to reflect this uncertainty.

Cost-reimbursement [Cost plus]: System's owner reimburses the contractor for labor, material, overhead, administration costs, plus a fixed fee.

Cost-reimbursement type contracts are used where there is a high level of project risk and uncertainty. With this type of contract the risks reside primarily with the system's owner. The contractor gets reimbursed for all of his costs. Additional work performed due to changes or rework, entitle the contractor to get paid for this additional effort. The overall budget is managed by the system's owner. This type of contract is recommended for the system definition of hardware & software development where there is the risk of stakeholder changes to the system.

A variation on this type of contract, which has been used in the past for ITS projects, is a combination of a cost-reimbursable [cost-plus] with a cost cap on the total project. The contractor cannot exceed this and is responsible to manage to it [contractor has the project risks]. This is essentially a fixed price contract. ITS projects are not well defined in the early stages of system definition; there are many unknowns and risks of stakeholder changes. In these cases this variation on the Cost-reimbursement [Cost plus] option is not recommended.

Time and Materials [T&M] type of contract: System's owner pays an hourly rate which includes all profit and overhead. The materials are billed separately.

This type of contract is similar to the Cost-reimbursement [Cost plus] type of contract. Except, the contractor rolls all labor, overhead, and fees into an hourly rate. The system's owner only sees this rate. Materials are paid separately.

This type of contract is recommended when the risk of stakeholder changes to the system is high or stakeholder involvement requires an unknown number of meetings, reviews, and iterations on definition & design.

Task ordering: This is a technique for managing a project that has a number of tasks but the detailed scope of each is not well specified upfront. This can also apply where the system's owner has multiple contractors and consultants under a single contract. This technique allows a great deal of flexibility to the system's owner for systems development. The following are examples of how task ordering can be used for ITS developments.

  • Each phase of the project can be executed with a sequence of task orders. For example, the task would be for the development of a concept of operations, or the development of the system requirements. At the end of the task the system's owner may elect to issue another task to carry the work forward or use a different consultant or contractor.
  • Another example is the development of alternate designs from multiple development teams. Each design is evaluated when complete. The best design or combination is selected for implementation. For example, the National ITS Architecture development was accomplished using four [4] independent teams working concurrently. At the end of this phase, the best aspect of each was integrated together into a single architecture that we use today.
  • For projects where there is an overlap between a consultant phase and the development team's phase of work, a task order can be used to bring a development team into the project early. The system's owner would get support during the earlier phase activities without being committed to the development team for the next phase of work.


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000