Develop a Concept of Operations to define the system that will be built.
Lessons from the ICM Implementation Guide.
Made Public Date


United States

Integrated Corridor Management: Implementation Guide and Lessons Learned


The Integrated Corridor Management: Implementation Guide and Lessons Learned document is intended for use by adopters of integrated corridor management (ICM) approaches and strategies to address congestion and travel time reliability issues within specific travel corridors. It introduces the topic of ICM and identifies the type of information system, known as the integrated corridor management system (ICMS), used to support transportation network managers and operators in applying ICM.

The U.S. DOT partnered with eight transportation agencies in large metropolitan areas, referred to as "Pioneer Sites," to research effective means of implementing ICM approaches in their major travel corridors. The guide discusses lessons learned that arose during the U.S. Department of Transportation’s (U.S. DOT’s) research initiative.

Lessons Learned

Development of the ConOps is key to defining the system that will be built. The ConOps will document what the ICMS must do and at what level it is expected to perform. The ConOps provides the vehicle for all project stakeholders to have input to and stay informed about the system definition. The ConOps also provides guidance to the system development team. The Stakeholders and system developers should be able to reference the ConOps to help them understand the system, including what the system must do, what constraints the system will have placed on it, what system performance must be achieved, what operational modes the system will include, and how users will interact with the system.

The following lessons apply to developing a ConOps for an ICM program.

  • Normalize acronyms and terminology. When working with multiple agencies, it was found that terminology and acronyms can differ in definition. It is advisable to develop an acronym and terminology list that includes common definitions.
  • Provide consistency in naming conventions. When working with multiple agencies, it was found that naming conventions can differ (e.g., operator names, data element names, agency names, etc.). It is advisable to keep a list of naming conventions and how the inconsistencies will be managed.
  • Identify external systems. Make sure all appropriate external systems are included. Poll a large group to make sure they have the opportunity to have input into what external systems should be included in the ICMS.
  • Be prepared to change the operations and management of existing transportation systems. ICM will likely change the operations and management of transportation systems. Stakeholders should be prepared and position themselves to change how they will operate and manage their individual systems in an ICM environment.
  • Share data. Determine what data is available and the quality of the data in the external systems and initiate agreements on how to share the data.
  • Assess data types and formats. Stakeholders need to assess the data types and formats that are stored in the various external systems and look at how to make that data work for the intended ICMS purposes.
  • Update user needs as required. Refine needs as warranted. Sometimes requirements will drive changes in the needs. These updates should be a priority as they may have serious impacts on the system definition.
  • Do not create compound user needs. User needs may have to be broken up if too many capabilities are described in the need. A need should express only one major desired capability. Make sure that the systems engineering process defines a common need format or grammar.
  • Specify system constraints. Be careful about the use of constraints, for example when defining inter-jurisdictional agreements, be cautious of specifying what has not currently been agreed to, and do not forget to identify rules, regulations and laws that the system must follow.
  • Create, monitor, and update system security access. Keep a table that identifies operators and permission levels, update that table as the project proceeds and changes are identified.
  • Use caution and confirm terminology/metrics. The use of sensitive metrics such as fatality rates may be restricted by some agencies. Make sure that terms and metrics are approved for use.
System Engineering Elements