Summary

Relationship to other components

As shown in the figure below, stakeholders are mapped to several other components of the Regional ITS Architecture. Each element in an inventory has an associated stakeholder(s). Roles and responsibilities are organized by stakeholders. Stakeholders also have user needs that are included in the architecture by way of the services they choose. Once interfaces are identified between agencies then agreements are necessary between different stakeholders. Projects, which really represents a subset of the above set of components for a single project, also are defined by which stakeholder funds, develops, operates and maintains the system deployed by the project. In addition, a variety of stakeholders may participate in a project by providing information to or receiving information from the systems deployed.

Regional ITS Architecture Components – Stakeholders

Considering the way stakeholders' names will be listed will make it easier to access and understand other parts of the architecture. The key information about Stakeholders is usually described by a table or the stakeholder page on the website. A recommendation is that agencies of similar nature are described in a consistent manner. For example, the various municipalities might each be named "City of xxx", while the counties might be named "yyy County." If departments are called out separately, then the agency name should be used to group departments for a given agency, e.g., City of xxx Public Works Department. This allows the stakeholders to more easily see their relevant information.

Approach

Whether this is an update to an existing architecture or the development of a completely new architecture the approach for the architecture's stakeholders involves ensuring the right stakeholders are involved in each step of the process and that the set of stakeholders is as inclusive as possible. The next sections describe the different activities involved in each approach.

-         Updating Stakeholders

-         Developing Initial List of Stakeholders

Updating an Existing Architecture's Set of Stakeholders

In an Architecture Update, stakeholders play a key role in providing data for the update and reviewing the drafts and finalizing the outputs. Every region has a core group of stakeholders that would have been involved in the previous update(s) and will play a role in any update.

Core stakeholders represent key transportation agencies in the region who plan, deploy and maintain ITS systems. They are most commonly traffic, transit and maintenance groups at the state, county or municipal level. It is desirable to have public safety agencies part of the core stakeholders, but they are often not as heavily involved in the update process. Core stakeholders are often a part of ITS committees or technical groups that meet on a periodic basis. These meetings serve as excellent venues for meetings throughout the architecture update. The basic activities in updating stakeholders are given below.

Gather Data on Stakeholder Changes in Region

Some changes occur in the stakeholders in almost every update. One of the key ways to gather these changes is to interview the stakeholders (likely the core stakeholders plus a few key others as appropriate) to find out what changes have occurred since the previous update. One of the common changes that occurs is that the name or description of the stakeholder has changed since the last update. This often occurs because agencies change names or responsibilities over time. This is particularly true if the stakeholder names in the architecture are broken down to the departments within an agency (e.g. Public Works Department, vs agency name alone). In addition, new stakeholders may have come to the table and need to be included in the architecture.

Update Stakeholder information in the architecture

The architecture as previously defined will have a list of stakeholders that will serve as the starting point for the update. The primary updates relating to stakeholder are done on the Stakeholder tab of RAD-IT, where the names and descriptions are contained (see description of the Stakeholder Tab below). The changes determined in the previous activity should be entered into the RAD-IT file.

Review Changes with Stakeholders

Once the changes are defined, they need to be reviewed by the relevant stakeholders to obtain concurrence on the changes. The review will usually be done with a table of stakeholders or via the relevant section of an architecture website.

Developing a New Architecture's List of Stakeholders

In a new Architecture development, the stakeholders in the regional surface transportation system are identified and the process of encouraging their participation in the regional ITS architecture development is initiated. This effort usually begins by identifying a core group of stakeholders who will be key participants in the architecture development.

Identify Core Stakeholders

Each architecture development needs a set of core stakeholders that will play a key role in the development over the architecture. This core stakeholder group usually includes the planners and operations staff from the primary transportation agencies in the region. This usually includes key transportation agencies at the state, county or municipal level. This core group provides continuity to the development effort and an important set of contacts for the organization that is responsible for the architecture development and the 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.

Identify Full Set of Stakeholders:

The core stakeholder group usually works with the responsible organization and the architecture developers to identify the wider range of stakeholders that they would like to participate in the architecture development. This effort usually starts with identifying the candidate stakeholders including the agency, company or interest group, transportation area, and possibly key participant contact information.

The list of stakeholders identified in the table below 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 the regional ITS architecture. In creating the full set of stakeholders it is helpful to look outside the immediate set of peers of the core stakeholders, considering the range of stakeholders identified in the list below.

Candidate Stakeholders

Review with Stakeholders

Depending on the level of knowledge in the region, it can be useful to engage the wider set of stakeholders in an 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.

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.

Once the list of stakeholders is developed, the names and descriptions should be reviewed with the relevant stakeholders to ensure a correct representation. 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.

Recognize and respect that everyone's time is limited. Draw participants into the process without bogging them down. This is true for all aspects of the architecture, and is mentioned here during the discussion of the stakeholders. 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.

It is 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 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.

RAD-IT

The key information about Stakeholders is contained on the Stakeholder Tab of RAD-IT. As shown on the tab, each stakeholder has a name and description. The stakeholder Tab on RAD-IT is shown below and is the tab where the initial updates of stakeholder names or descriptions are performed.

RAD-IT Stakeholders Tab

As mentioned on the Relation to Other Components tab, stakeholders are mapped to several other components of the architecture. The updates of each of these components will require that their mapping to stakeholders is also updated. Based on the way RAD-IT works, an update to stakeholder information on the Stakeholder Tab will automatically be updated in the mapping to stakeholders on the other tabs represented by the components above.

You can also use RAD-IT to create groups of stakeholders. Sometimes a stakeholder may belong to a larger organization and it may be the larger organization that is technically owning or managing an ITS system. In the example above you can see the 'group' icon in RAD-IT that has the multiple heads next to the name.

The key outputs used to discuss stakeholders are either a table, which can be created by going to the RAD-IT top menu Output/Tables and selecting the Stakeholder Table- shown below, or going to the stakeholder Tab on an architecture website.

RAD-IT Output Tables Menu for Stakeholders

Create a Stakeholder Group when you want to associate more than one stakeholder with the same element. This could be a group of stakeholders, such as several emergency services agencies, that may be in charge of an emergency center in the Regional Architecture which is actually a group of emergency centers. On the Stakeholders tab of RAD-IT, individual stakeholders are represented by the single person icon while stakeholder groups are shown using the multiple person icon.

Examples

Examples of Stakeholders can be found in every regional ITS architecture either in tables or on the architecture websites. A common approach is to put a table with all the stakeholders (and their description) in an Architecture Document. The figure below shows a portion of such a table from the Austin Regional ITS Architecture document.

Stakeholder Descriptions - Austin Regional ITS Architecture

Another common approach to representing a set of stakeholders is on the stakeholder page of a website version of the architecture. Below is an example of the stakeholder page from the Northeastern Illinois Regional ITS Architecture v.3.0.

Stakeholder Output Example - Chicago