United States Department of Transportation - Federal Highway Administration FHWA HomeFeedback

Regional ITS Architecture Guidance Document

TOC      Previous Page      Next Page

3 Get Started

Step 1: Get Started includes Identify Need, Define Scope, Identify Stakeholders, and Identify Champions tasks.

This section describes the first step in the regional ITS architecture development process — "Get Started".

The regional ITS architecture effort begins with a focus on the institutions and people involved. Based on the scope of the region, the relevant stakeholders are identified and a plan to engage them is developed, one or more champions are identified, the team that will be involved in architecture development is organized, and the overall development effort is planned with particular focus on outreach and consensus building.

In this section, the four "Get Started" process tasks are described in more detail. Each task description begins with a one page summary that is followed by additional detail on the process, relevant resources and tools, a general description of the associated outputs, and example outputs where they are available. Each task description also includes tips and cautionary advice that reflect lessons that have been learned in development of regional ITS architectures over the past several years.

3.1 Identify Need

STEP #1: GET STARTED - Identify Need
These tasks may be performed in parallel.
  • Identify Need
  • Define Scope
  • Identify Stakeholders
  • Identify Champion(s)
  • Assess need for regional ITS architecture
  • Define regional ITS architecture boundaries
Key Activities
Assess Need and Ability
  • Determine if ITS technologies are being implemented.
  • Determine if ITS projects are planned for the region.
  • Evaluate system integration opportunities in the region
  • If a regional ITS architecture is needed, assess in-house skills and determine if additional assistance is required.
  • Build awareness in the region of the benefits of a regional ITS architecture through outreach and education and garner support for its development.
Build Consensus
  • Build consensus in the region on the decision to develop a regional ITS architecture
  • Emphasize the benefits, rather than the rule/policy requirements
Sources of Information
  • Transportation Improvement Program (TIP)
  • The Long Range Transportation Plan ("the Plan")
  • ITS Strategic Plans and other ITS Plans
  • ITS Outreach and Educational Resources
Results from Process
  • Decision to initiate a regional ITS architecture development effort.

In this step, the decision to develop a regional ITS architecture is made. Through this decision process, the development and maintenance of a regional ITS architecture is established as a shared objective by the transportation planning and operating agencies in the region.

Rule/PolicyRequirements for developing a regional ITS architecture are identified by FHWA Rule 940.9 and FTA National ITS Architecture Policy Section 5.

3.1.1 Process

A regional ITS architecture is required by the FHWA Rule/FTA Policy for regions that have deployed, or will be deploying, ITS projects. An examination of the deployed ITS systems, the plans for future ITS deployments, and system integration opportunities in the region will establish if the rule/policy applies and a regional ITS architecture is required. While the rule/policy establishes a clear "requirement" for a regional ITS architecture for many regions, the real "need" for a regional ITS architecture is based more on its utility in ITS project planning and implementation.

The most important reason to develop a regional ITS architecture is that it can help the region to efficiently plan for and implement more effective ITS systems. Thus, the ultimate objective is not to develop a regional ITS architecture that complies with a federal rule or policy, but to develop a regional ITS architecture that can really be used by the region to guide ITS implementation. A regional ITS architecture that includes all the products specified by the rule/policy but is never used by the region is not of real benefit to the region or US DOT. To meet the requirements of the rule/policy, the regional ITS architecture must be used to measure conformance of ITS projects on an on-going basis and be maintained as regional ITS requirements evolve.

The decision to proceed then should actually be based on a clear understanding and commitment by planning agencies, operating agencies, and key decision makers in the region that a regional ITS architecture is needed and will be put to good use. This implies that a decision to proceed should be accompanied by significant outreach and education on the benefits of ITS and system integration and the important role that a regional ITS architecture can play in developing these integrated systems.

3.1.2 Resources and Tools

ResourcesThere are many good resources available that can support the outreach and education effort that may be required to realize the benefits of a regional ITS architecture. USDOT has published an "ITS Resource Guide" that lists over 300 documents, web sites, training courses, software tools, and points of contact covering all aspects of ITS, including the National ITS Architecture and regional ITS architectures. An online version of this guide is available at http://www.its.dot.gov/guide.htm.

3.2 Define Scope

STEP #1:  GET STARTED - Define Scope
These tasks may be performed in parallel.
  • Identify Need
  • Define Scope
  • Identify Stakeholders
  • Identify Champion(s)
  • Define the general scope of the regional ITS architecture.
Key Activities
Define the Regional ITS Architecture Scope
  • Review geographic boundaries of key stakeholders, major ITS projects and special "air quality conformity" issues. Consider the Metropolitan Planning Area boundary in metropolitan areas.
  • Provide boundary information to the stakeholders for consideration
  • Collect information on surrounding regional ITS architectures and consider how this regional ITS architecture will fit with others in the area.
  • Define a timeframe for what will be included in the regional ITS architecture (e.g., five, ten, or twenty year planning horizon).
  • Determine the basic scope of the services that will be covered. For example, determine if the regional ITS architecture should define commercial vehicle related services.
  • Include security objective(s) in scope if desired by stakeholders
Build Consensus
  • Actively solicit feedback on preliminary regional ITS architecture boundary, timeframe, and service scope decisions.
  • Agree on preliminary scope in order to begin the process. Remember, the scope can be refined as you proceed.
Sources of Information
  • Geographic boundaries for key regional transportation projects and/or services that utilize ITS.
  • Stakeholder(s) agency "operational or service area" boundaries.
  • Transportation Improvement Program (TIP)
  • The Long Range Transportation Plan ("the Plan")
  • Geographic boundaries of surrounding Regional Architectures.
  • Scope of overlapping regional ITS architectures
Results from Process
  • A description of the region including geographic boundaries, timeframe, and service scope.

The process of developing a regional ITS architecture begins with a definition of the region. The fundamental scope for the regional ITS architecture is established with the definition produced in this step.

3.2.1 Process

The general scope of a regional ITS architecture can be defined in three ways:

  1. Geographic Area: Define the geographic area covered by the architecture. What cities, counties, states, corridors, or other special areas does it include?
  2. Timeframe: Define the planning timeframe that the regional ITS architecture will address. Should the architecture encompass systems and services that are implemented over the next five, ten, or twenty years?
  3. Service Scope: Specify the general categories of services that are included. For example, should the architecture cover commercial vehicle services?

TipDon't invest too much time trying to define the region perfectly the first time. Remember that developing a regional ITS architecture is an iterative process, and the definition of the region can be adjusted as the regional ITS architecture begins to take shape. The stakeholders should make a first cut at defining the region and then update the geographic area, timeframe, and service scope as new stakeholders are identified, new integration opportunities are considered, and the ultimate uses for the regional ITS architecture are discussed in more detail.

Geographic Area

Ideally, the geographic scope of a region should be established so that it encompasses all systems that should be integrated together. In practice, it is sometimes difficult to determine where to draw the line so that the regional ITS architecture is inclusive without expanding to the point that the effort becomes unmanageable and consensus is difficult to achieve. While this is frequently called a "geographic" area, it is usually a political map that is being partitioned, defining a region along existing institutional boundaries.

Rule/PolicyThe rule/policy states that metropolitan areas must consider the metropolitan planning area (MPA) as a minimum size for a region. The MPA is a good place to start since this boundary normally encompasses most integration opportunities and it coincides with the geographic region used for transportation planning. If the MPA is not the right boundary for a metropolitan regional ITS architecture, than a different geographic area can be specified, with rationale.

Service boundaries and special conformity boundaries should also be taken into consideration when determining the regional boundary:

Service Boundaries: Regional transportation agencies and other stakeholders each have geographic areas that they serve (e.g., transit services, toll authorities, etc.). These service boundaries should be considered when defining the geographic boundary for the regional ITS architecture. In metropolitan areas, these service boundaries may go outside the metropolitan planning area and influence the regional ITS architecture boundary.

Special Conformity Boundaries: In regions where there are special conformity issues like Air Quality, special conformity boundaries may also be considered. For example, ITS projects that are implemented to meet air quality goals within an air quality conformance boundary may require integration with other projects in the region. This suggests that the air quality conformance boundary may also be considered in establishing the geographic area covered by the regional ITS architecture.

Also consider the scope of other regional ITS architectures when defining the boundary. Where there are adjoining or overlapping regional ITS architectures, coordinate with the other region(s) to reach agreement on how common systems or interfaces will be represented in the two (or more) regional ITS architectures. For example, many states have created statewide ITS architectures that must be taken into account by the metropolitan area architecture(s) in those states. A few agencies have also created their own agency architectures that focus on internal agency interfaces, creating additional levels of architecture definition that should be taken into account in establishing architecture scope.

CautionSpecial care is required when regional ITS architectures do overlap. Caution should be used whenever the same ITS element or interface is included in more than one regional ITS architecture. Unless automated methods like a relational database or Turbo Architecture are used, it is almost certain that some difference or ambiguity will arise in the two (or more) representations of the same architecture definition. Whenever possible, it is a good idea to define the ITS element or interface in one architecture and reference the one "authoritative" definition in all other regional ITS architectures.


The regional ITS architecture should look far enough into the future so that it serves its primary purpose of guiding the efficient integration of ITS systems over time. While there is no required minimum, the most appropriate timeframe can be established based on how the regional ITS architecture will be used. Making the timeframe too short reduces the value of the regional ITS architecture as a planning tool. Making the timeframe too long increases the effort involved since very long range forecasts are difficult to make and subject to reevaluation and change.

TipA rough 5-, 10-, or 20-year approximation of the timeframe is enough to begin the process. The initial timeframe can then be reevaluated and changed as the regional ITS architecture takes shape.

As the regional ITS architecture is defined, the timeframe is normally a secondary consideration when determining whether to include a particular ITS element or interface. It is usually best to include the interfaces that are clearly supported by the stakeholders, even if these consensus interfaces push the envelope of the timeframe that was initially selected. In other words, the timeframe should be adjusted as necessary to match the vision of the stakeholders. It shouldn't be used to precisely constrain the stakeholders to near-term options since it is difficult to anticipate exactly when a well-supported idea will be implemented. Viable integration opportunities should be included in the regional ITS architecture and then reevaluated periodically as the regional ITS architecture is maintained over time.

Service Scope

While specific identification of ITS services occurs later in the process, general decisions can be made immediately based on the scope of other regional ITS architectures. For example, if a statewide ITS architecture is defining commercial vehicle services, the 511 traveler information system, and the electronic toll collection system for the state, then any other regional ITS architectures in the state may decide to reference the statewide architecture for these services.

CautionAvoid defining the same ITS services in multiple regional ITS architectures. The redundancy will cause difficulty in maintaining regional ITS architectures so that they are always consistent and complicate architecture use in the region.

Security Considerations

SecurityA high-level security policy statement may be included in the formative scope of the regional ITS architecture that will guide architecture development in subsequent steps. Establishing the basic need for security at the outset is particularly important where regional ITS architectures rely on participation and support from public safety, emergency management, and other organizations where security is critical. Different organizations will be willing to accept different levels of risk; the security policy statement is an initial shared statement that can encourage organizations to participate in the regional ITS architecture development and subsequent integration projects.

3.2.2 Region Definition Output

The definition of a region will specify the geographic area of coverage, typically using a map and a supporting textual description. The timeframe and service scope of the regional ITS architecture can also be defined to more completely document the scope of the region.

3.2.3 Region Definition Examples

Many different types of "regions " have been defined in the regional ITS architectures that have been developed to date. Architectures have been developed for all of the following types of geographic areas:

The last category is defined by a particular service or group of services. Service regions include tourist areas like the Greater Yellowstone region and international border areas like Western New York and Southern Ontario (the "Buffalo-Niagara Bi-National Regional ITS Architecture"). The service region may have a specific scope of ITS Services; for example, a larger regional ITS architecture that focuses on traveler information.

Two examples illustrate some of the types of regions that can be defined. The first example region was defined by the Delaware Valley Regional Planning Commission (DVRPC), which is the Metropolitan Planning Organization for the nine-county Philadelphia region. The region is essentially the nine-county MPO region expanded to include interfaces to ITS systems outside the region. The region is shown in the map in Figure 1.

The geographic coverage of the Delaware Valley Regional Architecture encompasses the 9-county area around Philadelphia.

Figure 2: Regional ITS Architecture scope for the Delaware Valley RPC

The second example, illustrated in Figure 2, shows the approximate geographic scope of three regional ITS architectures under development in the central valley in Northern California and adjacent mountain regions. The Sacramento Regional ITS Architecture covers the Sacramento metropolitan area and surrounding cities including all of Sacramento County, portions of Yolo County and portions of Placer County. The Tahoe Gateway Counties ITS Strategic Deployment Plan includes Nevada County, Sierra County, Placer County and El Dorado County. The Tahoe Basin ITS Strategic Plan incorporates parts of two states (California and Nevada) and five counties (Carson City, Douglas, El Dorado, Placer and Washoe) and the town of Truckee, located in Nevada County. The boundaries of these architectures overlap, requiring a commitment and open lines of communication between the three projects.

3.3 Identify Stakeholders

STEP #1:  GET STARTED - Identify Stakeholders
These tasks may be performed in parallel.
  • Identify Need
  • Define Scope
  • Identify Stakeholders
  • Identify Champion(s)
  • Identify and engage stakeholders that own or operate ITS systems and other agencies that have an interest in regional transportation issues (e.g., MPOs, etc)
  • Build broad-based support for the regional ITS architecture.
Key Activities
Outreach to Stakeholders
  • Prepare educational materials that provide examples of successful ITS projects and benefits of ITS and ITS architecture. These materials will help you demonstrate benefits to stakeholders and gain support for the regional ITS architecture.
  • Use ITS working groups already in place to engage potential stakeholders. Facilitate initial meetings among core stakeholders involved in surface transportation and regional planning.
  • Look outside immediate peers to identify new stakeholders.
  • Identify additional stakeholders from referrals by stakeholders already participating in the process.
Build Consensus
  • Schedule ongoing meetings and/or provide a consistent mechanism for communication to/from agencies responsible for the overall transportation program.
  • Address issues as they arise by using the consensus building process to make decisions about projects, ITS regional goals, etc.
Sources of Information
  • ITS educational and outreach resources
  • Existing working group rosters, various participant lists
  • Key stakeholder representatives from local transportation departments (cities, counties, states), public safety agencies, private companies, ...
Results from Process
  • Identification of participating agencies and other stakeholders

Approximate geographic overlap between the Sacramento Regional ITS Architecture, the Tahoe Gateway Regional ITS Architecture, and the Tahoe Basin Regional ITS Architecture.

Figure 3 : Adjacent/Overlapping Regions

The success of the regional ITS architecture depends on participation by a diverse set of stakeholders. In this step, the stakeholders in the regional surface transportation system are identified and the process of encouraging their participation in the regional ITS architecture development process is initiated.

Rule/PolicyIdentification of participating agencies and stakeholders is one of the required components of a regional ITS architecture as identified in FHWA Rule 940.9(d)2 and FTA National ITS Architecture Policy Section 5.d.2.


3.3.1 Stakeholder Identification Process

Regions will vary dramatically in the degree to which the surface transportation system stakeholders are aware of ITS. In regions that have already implemented substantial ITS systems, the stakeholders have already been working together on many of the issues that will be addressed during regional ITS architecture development. As a result, these regions usually have existing ITS committees that will be a natural forum to kick-off the regional ITS architecture development.

Other regions will require more significant education and outreach efforts about ITS in general and the merits of a regional ITS architecture in particular to assemble and motivate enough stakeholders. When preparing education and outreach material to introduce stakeholders to the regional ITS architecture, it is a good idea to use local project examples that may already be familiar. If local examples are not available, a variety of excellent material is available from USDOT and other sources.

Educating the right people is important – frequently the education and outreach efforts will target the management levels in an organization where decisions can be made to commit valuable personnel resources to support the architecture development effort. Without management support, it will be difficult or impossible for those with a working knowledge of ITS in the region to participate effectively in the regional ITS architecture effort.

TipIt is often best to start with a core stakeholder group and then add participants to the core group over time. The core stakeholders group would itself be a diverse group with representation from each major agency and from both planners and system operators. This core group provides continuity to the development effort and an important set of contacts for the champion(s) and architecture developer(s). Including too many stakeholders at the start can hinder regional ITS architecture development progress and discourage people with limited vested interest in the process. Although the architecture effort should be very inclusive, a region may have better initial success if they are able to build consensus among the stakeholders that plan/own/operate ITS systems first before adding others into the decision making process.

Figure 3 shows a conceptual view of how stakeholders are added over time to the core stakeholder group. The core group is used to kick-off the effort. The number of active, participating stakeholders increases as the architecture development effort begins to generate more detailed and varied products that require broad review and support. The number of active stakeholders may then begin to taper off as reviews are completed, comments are incorporated, and "completed " regional ITS architecture products are published. This same strategy of engagement can be used, but probably on a smaller scale, for periodic maintenance activities that follow.

Two graphs that show that a core stakeholder group is augmented with additional stakeholders over time.  Stakeholder participation peaks and then falls off as the regional ITS architecture work is completed and reviewed.  The total number of stakeholders that have been involved continues to increase over time.

Figure 4 : Stakeholder Identification and Involvement Over Time

While the number of active stakeholders begins to taper as the workload is reduced, the graph on the right shows that the total number of stakeholders will continue to increase over time, as different specialties and agencies participate in different parts of the architecture and different steps in the process.  The perspective of the graph on the right is that once you are a stakeholder, you are always a stakeholder, although you may not actively participate beyond a specific milestone in the process.   Over time, all relevant stakeholders in the region are engaged, just not all at once at the beginning of the architecture development effort.

If it is decided to initially limit the number of participants to a core group as depicted in Figure 3, set a timeframe to add others so that the architecture reflects the broader interests of the region.   Table 1 in section 0 provides a list of potential stakeholders to consider. 

As additional stakeholders are added to the process, it may be a good idea to retain a core group that meets regularly and have a broader group that is included at selected milestones in the regional ITS architecture development.  It is critical that all stakeholders participate enough in the process that they understand the architecture and feel some ownership of the process and the regional ITS architecture that is developed.  It is important to continually encourage and validate participation of stakeholders in the development process. 

TipIt is also important to focus stakeholder participation appropriately. For example, both planners and system operators will participate in the process, but with substantially different focus. System operators may be more interested in the operational concepts, functional requirements, and interface definitions, while the planners may have more substantial input while identifying transportation needs and services and project sequencing. Other individuals with specialized knowledge will be needed to assist in development of the list of agreements and list of required ITS standards. As the "stakeholder roster " is developed, consider the various areas of expertise that are required and use your stakeholder resources selectively. Different stakeholders should be engaged in different parts of the process, consistent with their expertise and interests.

Encouraging broad participation from many agencies, companies, and special interests in the region will occasionally bring people into the process who aren't really stakeholders in the regional transportation system. If the representative doesn't have, or plan to have, a system that should be integrated within the architecture timeframe or an interest in the surface transportation system as a whole (e.g., planners, the tourist industry, other special interests), then the representative is probably NOT really a stakeholder, will have little to contribute, and may ultimately grow frustrated with the process. It is best to understand the role of each potential new stakeholder in the surface transportation system at the outset and determine how they may contribute before significant time is invested. The objective is to be inclusive without wasting the time of those who do not have a vested interest.

TipRecognize and respect that everyone's time is limited. Draw participants into the process without bogging them down. Some useful techniques to encourage people with demanding schedules to participate are to make sure everyone gets plenty of time to review documents, and schedule short meetings with teleconferencing options. This will help retain participants that may otherwise give up on the architecture effort due to other commitments.

3.3.2 Tools and Resources

ResourcesMany good education and outreach resources are available to support efforts to encourage stakeholder participation in ITS-related efforts. USDOT has published an "ITS Resource Guide " that lists over 300 documents, web sites, training courses, software tools, and points of contact covering all aspects of ITS, including ITS architecture. An online version of this guide is available at http://www.its.dot.gov/guide.htm.

National ITS ArchitectureApplicable National ITS Architecture resources include a training course and technical information that has been used to assist in identification of stakeholders in the past. The National ITS Architecture training course is provided by the National Highway Institute (Course # 137013, http://www.nhi.fhwa.dot.gov/). The subsystems and terminators defined in the physical architecture provide a good categorization of the various systems and stakeholders that can be considered in developing a list of stakeholders for the regional ITS architecture development. To access an on-line version of the Architecture, visit http://www.its.dot.gov/arch/index.htm.

TurboStakeholder lists may be entered directly into Turbo Architecture. Each stakeholder includes a name and a description and a variety of other information. Turbo can generate a stakeholder report and export stakeholder information to support the stakeholder output described in section 0.

The list of stakeholders identified in Table 1 includes the range of stakeholders that have participated in regional ITS architecture development efforts around the country. The table makes a good checklist of possible stakeholders that may be involved in your regional ITS architecture.

Table 1: Candidate Stakeholders

Transportation Agencies
  • State Departments of Transportation (DOT)
  • Local Agencies (City & County)
  • Department of Transportation
  • Department of Public Works
  • Federal Highway Administration (FHWA)
  • State Motor Carrier Agencies
  • Toll/Turnpike Authorities
  • Bridge/Tunnel Authorities
  • Port Authorities
  • Department of Airport or Airport Authority
Transit Agencies/Other Transit Providers
  • Local Transit (City/County/Regional)
  • Federal Transit Administration
  • Paratransit Providers (e.g., Private Providers, Health/Human Services Agencies)
  • Rail Services (e.g., AMTRAK)
  • Intercity Transportation Services (e.g., Greyhound)
Planning Organizations
  • Metropolitan Planning Organizations (MPOs)
  • Council of Governments (COGs)
  • Regional Transportation Planning Agency (RTPA)
Public Safety Agencies
  • Law Enforcement
  • State Police and/or Highway Patrol
  • County Sheriff Department
  • City/Local Police Departments
  • Fire Departments
  • County/City/Local
  • Emergency Medical Services
  • Hazardous Materials (HazMat) Teams
  • 911 Services
Other Agency Departments
  • Information Technology (IT)
  • Planning
  • Telecommunications
  • Legal/Contracts
Activity Centers
  • Event Centers (e.g. sports, concerts, festivals, ski resorts, casinos, etc.)
  • National Park & US Forest Services
  • Major Employers
  • Airport Operators
Fleet Operators
  • Commercial Vehicle Operators (CVO)
  • Long-Haul Trucking Firms
  • Local Delivery Services
  • Courier Fleets (e.g., US Postal Services, Federal Express, UPS, etc.)
  • Taxi Companies
  • Commuters, residents, bicyclists/pedestrians
  • Tourists/Visitors
  • Transit Riders, others
Private Sector
  • Traffic Reporting Services
  • Local TV & Radio Stations
  • Travel Demand Management Industry
  • Telecommunications Industry
  • Automotive Industry
  • Private Towing/Recovery Business
  • Mining, Timber or Local Industry Interest
Other Agencies
  • Tourism Boards/Visitors Associations
  • School Districts
  • Local Business Leagues/Associations
  • Local Chambers of Commerce
  • National Weather Services (NWS)
  • Air & Water Quality Coalitions
  • Bureau of Land Management (BLM)
  • Academia Interests, local Universities
  • National and Statewide ITS Associations (e.g. ITS America, ITE ITS members, etc.)
  • Military

3.3.3 Stakeholder Identification Output

This output identifies stakeholders who participated in the development of the regional ITS architecture by:

The purpose of this output is to record the stakeholder participation in the development of the regional ITS architecture and document the consensus process that was used in the regional ITS architecture development.

The actual documentation can take many forms, but a straightforward approach is to build a simple table or database with fields identifying the agency, company or interest group, transportation area, and possibly key participant contact information. This table can then be sorted by agency, company or interest group to check if each agency, company or interest group has adequate representation in the regional ITS architecture consensus development process.

3.3.4 Stakeholder Identification Example

Table 2 is a basic list of stakeholders that was prepared for an ITS architecture for the Franklin Tennessee Traffic Operations Center (TOC). It identifies each stakeholder agency that is related to the TOC and the systems that relate to each stakeholder agency. This is the complete stakeholder list for this small regional ITS architecture. The list of stakeholders will be considerably larger than this for most metropolitan regions.

Table 2: Franklin, TN TOC Stakeholders

Stakeholder Name Responsible for these systems in the Architecture
City of Franklin Engineering Department Storm Water Management System
Franklin TOC_Personnel
Franklin TOC_Roadside Equipment
Franklin Parking Management System
Franklin TOC
Franklin Police Department Emergency Vehicles
Franklin Police Dispatch_Personnel
Weather Service
Franklin Police Dispatch
Tennessee DOT Nashville Regional Transportation Management Center
Franklin Transit Franklin Transit System
Transit Vehicles
TMA Group Franklin TMA Kiosks
City of Franklin Streets Department Construction and Maintenance
Community Access Television Media
City of Franklin Event Promoters
Franklin Website
City of Murfreesboro Murfreesboro TOC
Traveling Public User Personal Computing Devices
Williamson County Williamson County Emergency Management System
Nashville MPO Regional Planning System

3.4 Identify Champion(s)

STEP #1:  GET STARTED - Identify Champion(s)
These tasks may be performed in parallel.
  • Identify Need
  • Define Scope
  • Identify Stakeholders
  • Identify Champion(s)
  • Identify one or more key persons to lead the regional ITS architecture development.
  • Obtain broad-based buy in and support from stakeholders.
Key Activities
Looking for Champion(s)
  • Champions for the region are probably already visible because they are proactive in the field of ITS, visionary about the future of ITS, and frequently already manage ITS projects.
  • Champion must be a stakeholder, so they have a vested interest in the outcome.
  • More than one champion can be identified from different agencies or stakeholder groups:
  • Transportation agencies (Traffic, transit, toll authorities, etc.) that support ITS because it meets their operational needs.
  • Public safety agencies who can bring in other public safety stakeholders.
Champion Skills
  • Understanding of the subject (regional ITS architecture including familiarity with the National ITS Architecture),
  • Knowledge of local ITS systems and projects,
  • Vision for interconnectivity, partnership, and regional integration,
  • Consensus builder (facilitator), and
  • Executive level access to resources to gain support for various regional efforts.
Building Consensus
  • Initiate a scheduled meeting time and place to work on the Regional Architecture, set agendas for meetings and allow opportunity for each stakeholder to provide input to the process.
Sources of Information
  • Not Applicable.
Results from Process
  • Strong leadership that has broad-based regional stakeholder support and an effective problem resolution mechanism for ITS projects.

In this step, the champion(s) that will lead the regional ITS architecture development effort are identified. The champion(s) drive the process that must occur in order to develop a regional ITS architecture and build consensus at each step of the development. Without strong leadership, consistent meetings and a plan for completion of tasks, many of the participants will quickly become busy with other daily responsibilities.

3.4.1 Process of Identifying Champions

Many regions have already developed a team of ITS stakeholders that meet on a regular basis. Chances are that the champion(s) have already been identified by the fact that they are leading the regional efforts through an ITS Task Force, Technical Advisory Committee or the fact that they are already leading a major ITS project in the region. Adding regional ITS architecture consensus building to whatever "hat " these people are already wearing will be a natural transition. The process of identifying a champion or champion(s), and developing a task force to put the regional ITS architecture together should be woven into the existing regional planning process for ITS if one is already underway.

Champions are usually not voted-in; they are selected "on the job " in the course of working together. In many regions, a single champion will be identified. If there are several people who rise to the occasion, several champions can be identified that take turns leading the meetings or agree upon some shared responsibilities that will keep everyone engaged. A champion's skills include:

The skill level that is needed in each area will vary depending on the technical and institutional maturity of the region. A more technically mature region may have many people with existing knowledge of the National ITS Architecture, but require increased skills in consensus building to pull various interests together. In institutionally mature areas that are growing in ITS technology, it may be a strong vision that guides the process. All of the identified skills are important for a strong successful champion along with the knowledge of when to use them.

No one individual is likely to possess all the knowledge and skills required to develop a regional ITS architecture. To be successful, the champion(s) must draw on the knowledge and skills of a diverse set of stakeholders. The champion is primarily a facilitator and manager and is not normally the one that actually defines the architecture – the stakeholders are.

A Champion must be a Stakeholder. It would be very difficult, if not impossible, for someone who did not have a vested interest in the outcome to be the champion for a regional ITS architecture development effort. A stakeholder who is already recognized in the region will best be able to take ownership and invest the time necessary to manage the regional ITS architecture development. FHWA, FTA, consultants, vendors and others are great participants, consultants may even do a lot of the detailed analysis and legwork in a regional ITS architecture effort, but for regional long-term benefit, they should not be champions.

TipIdentifying more than one Champion from varying backgrounds and disciplines (e.g., public safety, transit, state DOT, city and/or county traffic engineering) can be a benefit. A small group of people with diverse backgrounds and contacts can strengthen the regional ITS architecture product by improving stakeholder participation, encouraging agency buy-in, and facilitating access to the information and resources necessary to support architecture development. Where several champions are identified, they may form a steering committee (which could also include representation from others such as FHWA/FTA) that manages by consensus or advises and supports a leader who actually manages the development and maintenance effort.

Section 0 introduced the idea of a core stakeholder group that would be involved throughout the architecture development effort. This group might be the small group of "champions " described in the previous paragraph, or it could be a larger group. No one model will encompass all regional ITS architecture development efforts. Each region must decide how they wish to organize their efforts. The key is that there is a group of stakeholders who plays a key role throughout the architecture development effort.

CautionChampions will probably come and go over the evolution of developing and maintaining the regional ITS architecture, and certainly will change over the life of regional ITS system implementation and expansion. The task of the Champion, like other leadership responsibilities, takes significant time. Dividing the work among a few champions will limit the turnover and ease the transition when one person leaves. It is important that good meeting minutes and records of action items are kept so that new champions will have some guidance regarding when, where, and why decisions were made.

3.4.2 Examples

Champions are identified based on the people involved, the priorities of the participating agencies, and a range of other factors that are unique to each region. Because the factors involved are so specific to a region, it is unlikely that information on past champions will influence the selection of future champions in other regions. Nevertheless, it is interesting to look at the agency affiliation and titles of champions that have been identified. Table 3 shows some of the champions that have supported regional ITS architecture efforts in recent years. The table shows that a significant majority of champions have worked for either the state DOT or MPO.

Table 3: Regional ITS Architecture Champions

Region Champion
Albany, NY Assistant Regional Traffic Engineer – NYSDOT
Atlanta, GA Senior Planner – Atlanta Regional Commission
Austin, TX Traffic Engineer – TXDOT Austin
Chicago, IL ITS Program Manager – IDOT
Cleveland, OH Work Zone & Traffic Control Engineer – Ohio DOT
Detroit, MI Senior Engineer – SEMCOG
Hartford, CT Supervising Engineer – ConnDOT
Honolulu, HI Executive Director – Oahu Metropolitan Planning Organization
Indianapolis, IN INDOT
Kansas City, KS Manager, Transportation Programs – Mid-America Regional Council
Little Rock, AR Engineer – Metroplan
Long Island, NY Inform ODS Director – NYSDOT R-10
Milwaukee, WI TOC Assistant Manager, WisDOT
Oklahoma City, OK Associate Planner, ACOG
Omaha, NE Transportation Technology Engineer – Nebraska Department of Roads
Pittsburgh, PA Transportation Planner, Southwestern Pennsylvania Regional Planning Commission
Portland, OR Regional Traffic Engineer – ODOT
Providence, RI TMC Manager – RIDOT
Rochester, NY ITS Coordinator – NYSDOT
Sacramento, CA Senior Analyst – Sacramento Council of Governments
St. Louis, MO TIC Manager – MoDOT
State College, PA Risk Management/ITS Administrator – PennDOT 2-0

TOC      Previous Page      Next Page FHWA