Summary

Relationship to other components

As shown in the figure below, each project in the project sequence can be defined as a subset of the components comprising the regional ITS architecture- components that address just the services, stakeholders, inventory, etc. associated with each project. The sequencing aspect of project is defined by the timeframe in which the project will be implemented.

Regional ITS Architecture Components – Projects

Approach

The approach to project sequencing is the same whether you are updating and existing architecture or developing a new architecture.

Updating the Project Sequencing

The regional ITS architecture is "implemented" with many individual ITS projects that occur over the defined timeframe for the regional ITS architecture. A key aspect of an architecture update is to define a revised set of ITS projects that are planned for implementation in the region. A part of that definition will be the sequence, or ordering, of ITS projects that will contribute to the integrated regional transportation system depicted in the regional ITS architecture is defined.

One of the significant differences between ITS projects and conventional transportation projects is the degree to which information, facilities, and infrastructure might be shared between ITS projects. For example, a 511 Traveler Information System project may use information that is collected by previous instrumentation projects that collect traffic data and a CAD integration project that provides current traffic incident information. The regional ITS architecture allows the stakeholders to identify these ITS project relationships or "dependencies". Project dependencies can be used to identify project elements that must be implemented before other projects can begin. By taking these dependencies into account, an efficient sequence can be developed so that projects incrementally build on each other, saving money and time as the region invests in future ITS projects.

Both the traditional planning process and the approach to updating a regional ITS architecture have the same goal: to use a local knowledge, consensus process to determine the best sequence of projects to create a transportation network that best meets the needs of the people of the region.

The activities involved in updating a regional project sequence are virtually identical to those needed to create the project sequence initially, so for this component the discussion of the activities has been combined into a single thread.

Collect ITS Project Information

Projects are identified in planning documents like ITS deployment, strategic, or master plans that identify short, medium and long-term projects for a region. The TIP/STIP may include ITS related projects. At a higher level, long range plans may identify regional initiatives or priorities related to ITS. The first step in the update of ITS project sequencing process should usually be to review these plans, identify the ITS projects that are already prioritized as short, medium and long term, and then use this to begin to update the projects from the previous architecture development or update.

Beginning the ITS project update or development effort with any projecting sequence already included in applicable transportation plans is the best way to make sure that the completed project sequencing product will be relevant to planners and factored into future transportation plans. This two-way relationship between the regional ITS architecture products and the applicable regional planning documents is important to mainstreaming the regional ITS architecture into the transportation planning process. The relationship between the regional ITS architecture and the transportation planning process is described in more detail Architecture Use in Transportation Planning

.

The second input for project sequencing should be from key stakeholders in the region. As part of the interview step in the architecture update approach, review the existing set of projects from the architecture with the stakeholders and add, remove, or update projects as needed. One key to this discussion with the stakeholders is to consider projects with a longer timeframe, since many of the staff that are typically interviewed are more attuned to a short-term horizon.

In the case of developing a regional ITS architecture for the first time, data collection from the stakeholders (via interviews or meetings) should create a list of projects that are planned by the stakeholders. The same observation applies as in the previous paragraph- when discussing projects with stakeholders try to uncover some of their longer range plans that might be expressed as projects with longer timeframes.

Define ITS Projects

Each region (or potentially each stakeholder) should make a decision regarding the level of detail to be used for describing the projects. Many projects in regional architectures relate to deployment of field devices along specific roadways. Should the project name and description include details of the location (e.g. Third Ave) and number of devices (e.g. deploy 14 CCTV), or should it be defined as a more general "deploy new surveillance devices"?  There is no "correct" answer to which level of detail is right for a particular region. In general, the level of detail contained in the TIP/STIP is likely the appropriate level to choose as it allows easy mapping of architecture projects to TIP/STIP projects.

For projects in the longer term, it may not be possible to identify specifics of the project but rather define the project in more general terms such as "ramp metering installations", "transit and traffic management information sharing", and "evacuation management system". These categories or even larger groups of projects can be defined as regional initiatives which can be included in long range plans as discussed in the section on Architecture Use in Transportation Planning.

In addition to defining projects at differing levels of detail, it is important to realize that it may take a series of projects to deploy a complex ITS system or initiative (e.g. Smart City Initiatives). As another example, ITS components such as surveillance cameras, message signs, signals, and ramp meters are not typically deployed across a region in a single project but in phases by roadway corridors. Since nearer term projects must feed into programming and budgeting processes, the phases of such projects could be identified in the project sequencing.

An architecture and the projects defined in it are not be fiscally constrained as in a TIP/STIP. An architecture is a plan for the future that would provide the ITS services desired for the region. The plan can be deployed as funding becomes available. It is important to consider projects beyond those currently funded as funding availability varies due to policy changes and other issues.

One of the key uses of a regional ITS architecture is to support ITS project development. This is described in the section Architecture Use for ITS Project Development. One of the first steps in using the architecture is to identify the portions of the regional ITS architecture that are implemented by the project. Because of this requirement, the regional ITS architecture needs to describe how the project maps to the architecture. One of the best ways to do this is to develop a project ITS architecture in RAD-IT for each project in a regional ITS architecture.

The project ITS architecture developed within the regional ITS architecture RAD-IT file should include key components of the regional ITS architecture including

1.     Stakeholders

2.     Inventory

3.     Services

4.     Information Flows

In addition, it is useful if the project ITS architecture also includes other components of the regional ITS architecture that are relevant to the project including:

1.     Roles and Responsibilities

2.     User Needs

3.     Functional Requirements

4.     ITS Standards

5.     Agreements

Project information included in the architecture could include additional information that might make the regional ITS architecture more usable by the stakeholders. This information could include the following:

o    Cost:  Rough cost estimates for each planned project are an input to a realistic project sequence that takes financial constraints into account. Cost estimates should include both non-recurring (capital costs) and recurring (operations and maintenance) costs. Where possible, regions should use their own cost data as a basis. Cost basis information and assumptions should be documented to facilitate adjustment as additional data becomes available.

o    Benefits:  The anticipated benefits for the planned projects can also be used as an input to project sequencing. An estimate of benefits normalized by anticipated costs is a common figure of merit that can be used to identify ITS Projects that are the best candidates for early implementation. Both qualitative and quantitative safety and efficiency benefits may be estimated based on previous experience either within the region or in other regions that have implemented similar projects.

Documentation and tools are available to support analysis of benefits and costs to support ITS project sequencing. The USDOT JPO has an ITS Benefits Database and Unit Cost Database website that can be found at http://www.benefitcost.its.dot.gov/. In addition to the databases, the website contains several documents highlighting ITS benefits.

Define Project Sequence

In addition to defining the projects as described above, some effort should be undertaken to consider any sequencing or dependencies within the projects. The discussion below provides considerations relating to project dependencies and project sequencing.

With each ITS project defined in terms of the regional ITS architecture, the relationships between projects can be more easily identified:

-         Where ITS projects share an information flow, there is an "information dependency" between the project that generates the information and the project that receives the information.

-         Where ITS projects implement related functions on the same ITS element, there may be a "functional dependency" between the two projects. For example, certain core functions (e.g., surveillance) must be implemented before more advanced functions (e.g., incident verification).

In addition to the dependencies identified in the regional ITS architecture, ITS projects are also dependent on many other factors including the data or policy decisions that support the projects. For example, transit applications may be held up by the development of a bus stop inventory. A regional traveler information system may be held up by the lack of a regional base map. A regional fare system may be held up by a lack of consensus on regional fare policies. These types of dependencies should also be recognized and factored into the project sequence.

A project sequence defines the order in which ITS projects should be implemented. A good sequence is based on a combination of transportation planning factors that are used to prioritize projects and the project dependencies that show how successive ITS projects can build on one another. The most common "sequence" that regions use for their projects is a simple description of whether the projects are short term (often defined as "less than 5 years"), medium term ("5-10 years"), and long term ("greater than 10-years"). Any form of sequencing can be used by a region, this is just a commonly used format.

Review Project Sequence with Stakeholders

Once a project sequence has been defined or updated, it is important to review this with the stakeholders and gather comments on the detailed project information. Typically stakeholders provide a high level description of projects and it is left to the developers to define more precisely in terms of service packages, elements, and information flows how these projects are addressed by the architecture. Reviewing these details with the stakeholders will create a view of the project that matches their expectation and will often uncover additional project definition details that were lacking in the initial definition. Once the project sequencing is defined, outputs summarizing the project information can be put on architecture website or in documents.

As a sequence of projects is developed, also consider opportunities for including ITS projects in traditional transportation construction and maintenance projects that are planned for the region. Frequently, ITS elements can be efficiently included in traditional transportation projects; these potential efficiencies should be considered and reflected in the ITS project sequencing. For example, dependencies between the traditional transportation project and the ITS projects can be identified and the sequence can be aligned so that the ITS project is deployed at the same time as the associated construction and maintenance project. While efficiencies can be realized by synchronizing ITS projects with traditional transportation projects, it may be desirable to keep the capital improvements and ITS improvements contractually distinct so that separate funding can be used and/or that the lower cost, but possibly higher risk, ITS improvements can be more closely monitored and managed.

When project ITS architectures are developed in RAD-IT, as described above, these can be imported into the SET-IT tool in order to develop a more detailed project ITS architecture and systems engineering documentation to support ITS project development. See the SET-IT tool page on the ARC-IT website for more information.

Developing a New Project Sequence

See "Updating the Project Sequencing". The process and approach is the same whether it is part of an architecture update or a new architecture development.

RAD-IT

In RAD-IT, ITS Projects are initially described on the Start Tab as shown below (which shows a set of projects for the sample database that is automatically downloaded when the tool is obtained). Note this sample database has 4 projects defined within this architecture and the first one is selected.

Start Tab from RAD-IT for Project Architectures

For a project architecture defined in RAD-IT, the same components can be defined as for the regional ITS architecture. In general, for each of the tabs in RAD-IT the starting set of information is that contained in the regional ITS architecture for that tab and the developer can select the subset of the information (from the regional ITS architecture) that is relevant to the project.

Examples

The following example of project sequencing come from the Chicago Metropolitan Agency for Planning (CMAP)'s Northeastern Illinois Regional ITS Architecture v.3.0 website. The first figure below show an excerpt from the Projects Tab of the website and the second figure shows a portion of the detail webpage for the first project in the list.

Example of Project Listing in a Regional Architecture

Project Information Detail from Regional Architecture Example