Roles and Responsibilities
Stakeholder roles and responsibilities (R&Rs) are defined as part of the regional ITS architecture.
Definition
Typically in transportation stakeholders own, develop, operate, or maintain portions of the transportation system. Responsibilities cover activities that the stakeholders engage in as they perform their roles. For example, an agency that operates traffic signal systems will be responsible for providing adequately trained staff, maintenance of the system, and provision of information about the system to other agencies and the public.
Summary
|
POLICY |
An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture is required in 23CFR940.9(d)3 and FTA National ITS Architecture Policy Section 5.d.3.
|
|
Approach Key Activities
|
If updating an existing regional ITS architecture: - Gather data on revisions of existing Roles and Responsibilities - Update Architecture's R&Rs and enter into RAD-IT R&R Tab - Review with Stakeholders, In person or on-line
If defining a new regional ITS architecture: - Gather data from existing documents, e.g., Incident Management Plans - Develop Roles/Responsibilities or Operational Concept o Build the list of stakeholders based on the elements and services o Identify roles and responsibilities in general service package areas (e.g. traffic management, public transport, etc.) o Draft an operational concept - Develop several relevant operational scenarios - Walk through scenarios and identify roles and opportunities for enhanced cooperation - Document each stakeholder's current and future responsibilities in each scenario - Collect key findings into a high level Operational Concept o Build Consensus - Review drafts with stakeholders and revise as needed
|
|
INPUT Sources of Information |
- Existing Roles and Responsibility information - Inventory, Needs and Services - Any documents that identify roles and responsibilities
|
|
OUTPUT Results of Process
|
- Operational Concept documentation for the region, including how ITS services are provided and the stakeholders' roles and responsibilities
|
Relationship to Other Components
The inventory identifies the stakeholders that are associated with each system in the region and the service packages identify the services that those systems will provide. Here, each stakeholder's current and future roles and responsibilities (R&Rs) are defined in more detail.
Regional ITS Architecture Components – Roles & Responsibilities
Roles and Responsibilities are directly assigned to stakeholders. The second connection shown in the figure is with Services because stakeholder's participation in services implies responsibilities the stakeholders have.
Approach
Depending on whether this is an update to an existing architecture or the development of a new regional architecture there may be different steps to consider for the operational concept of a region.
Updating Roles and Responsibilities
Regional ITS architectures all have some version of roles and responsibilities. The descriptions of them may be in RAD-IT, but they might also be in an architecture document. The basic approach to updating follows that of the overall update approach: identify changes, incorporate them into the architecture and review with stakeholders.
Identify Changes
The approach to updating the roles and responsibilities is to review the current version of the roles and responsibilities with the stakeholders and get their inputs on changes. Because the range of service packages will likely expand in architecture updates, the new responsibilities implied by the new service packages should be considered in the update. This review could be done via interviews, or as part of stakeholder meetings.
Incorporate Changes into Architecture
Once the changes have been collected, they need to be entered into the
architectures. Use RAD-IT to enter roles and responsibilities as shown below to
allow the information to be accessible to stakeholders on any websites that are
created for the architecture or as documentation is updated. In most cases the
roles and responsibilities will be defined by service package area, which is
the way that RAD-IT organizes them. If the description is in a document rather
than RAD-IT, then other organizations of the information (e.g. by stakeholder)
may be the starting point for the update. In some cases a region may have
created a more complete operational concept organized around some of the
service package areas which will also need to be updated.
See the discussion below under Developing Roles and Responsibilities regarding an operational concept.
If the range of services performed by the architecture is expanding (e.g. if connected vehicle services are being added), then the roles and responsibilities will likely need to be expanded to cover the new services. This expanded set should then be reviewed with the stakeholders.
Review with Stakeholders
The updated version of roles and responsibilities should be reviewed with the stakeholders either in meetings or by requesting review of the architecture website or architecture document. Based on stakeholder comments the roles and responsibilities would be revised to provide the final update.
Roles and responsibilities represent a high-level view of the services
provided by a stakeholder. As part of the update it is a good idea to reconcile
inputs from the stakeholders on roles and responsibilities with the service
packages in which the stakeholders participate. This will provide a good early
validation that your architecture is on the right track.
Developing Roles & Responsibilities
When developing a new regional ITS architecture the development of roles and responsibilities is the step where integration opportunities in the region are first documented, with particular focus on stakeholder involvement. The objective is not to formally define each ITS element or specify detailed integration requirements. This will come in later steps. The objective in this step is to identify current and future organizational roles in the regional transportation system. As with the other regional ITS architecture products, exactly how the roles and responsibilities information is gathered and expressed will vary from region to region. The most common approach to developing roles and responsibilities is to organize them around service package areas such as traffic management, transit management, or incident management.
Start by gathering data from existing regional documents such as a TSM&O operational strategy or regional incident management plans. These will contain information about each of the major stakeholders and their roles in critical operations.
Next, start building the list of roles and responsibilities for the key stakeholders. Use the information from the Inventory of elements and the Services discussed in previous sections to come up with the list of stakeholders to focus on.
Some regions may develop only a set of roles and responsibilities, but some may choose to go further towards developing an Operational Concept, which could augment the roles and responsibilities to include a more detailed discussion of how stakeholders will interact to provide specific transportation services, possibly in specific scenarios.
Perhaps the most critical factor in the success of the roles and responsibilities step is stakeholder involvement. The ultimate objective is not just to create a table of roles and responsibilities, but to have the stakeholders suggest, review and tangibly buy in to these decisions so that they are owners of the roles and responsibilities. When a region chooses to go beyond this level of information to a full Operational Concept, they often define the operational concept around role and responsibility areas, selecting one or two service packages as representative of these areas and describing scenarios relating to these services. For example, "Traffic Incident Management" and "Regional Traffic Control" both require broad inter-agency coordination and make excellent examples for regional operational scenarios.
The National ITS Reference Architecture, ARC-IT, includes Service
Packages which can be used as a basis for operational concept development.
Basic service package information is readily accessible on the ARC-IT website. Click "Architecture" and
"Service Packages" from the pull-down menu to see a diagram, a tab of
enterprise information, planning goals/objectives, needs/requirements, source
information, security considerations, and standards that apply to the objects
in this service. These pages provide a good resource for those developing
operational concepts for the region.
Another approach used by some regions is to use real operational situations, or scenarios, to guide the discussion. For example, a large winter storm or hazardous material spill can provide vivid context to a discussion of the roles and responsibilities of stakeholders in the region. Create a scenario or scenarios that the stakeholders in the region are vitally interested in and then use the scenarios to encourage discussion and make the operational concept documentation more accessible.
One way to use a scenario-based approach is to organize a meeting where a facilitator walks key stakeholders through the events of a prepared scenario. At each step in the scenario, the facilitator works with the group to determine:
1. Current roles and responsibilities. For example, the state DOT currently faxes daily lane closure information to the counties, the major metropolitan city in the region, and the media.
2. What are the problems? For example, lane closure information tends to be very dynamic. Many agencies that could use the data don't receive it (e.g., emergency medical services).
3. What are the opportunities? For example, enhance coordination of longer-term closures between agencies. Collect closure information for the region in one place and make this available to all operating agencies as well as the traveling public.
The facilitator should be prepared for more "opportunities" to be identified than can be thoroughly addressed in real-time. A common approach is to list all the ideas and then prioritize a few to flesh out with an operational concept.
When it comes to the implementation and maintenance of complex regional
systems the lines of responsibility can get more complicated. One idea is to
develop a responsibility matrix with the shared resources on one axis and the
stakeholders on the other. Let the stakeholders populate each cell with their
responsibilities for the shared resource.
Security Considerations
From a security perspective, there are roles and responsibilities associated with making sure the security objectives are met. While you have your stakeholders thinking about their roles and responsibilities for ITS it can also be a good time to establish their R&Rs with respect to security as part of the operational concept. Leverage expertise from organizations in the region that have specific interest and expertise in information security.
RAD-IT
The key information about Roles and Responsibilities can be found on the RAD-IT R&R tab, where the roles and responsibilities are organized by Roles and Responsibility Areas. These areas usually represent service package areas (as defined in ARC-IT), however regions can choose to create their own areas if desired.
Within a single role and responsibility area, selecting one of the stakeholders provides a list of the actual roles and responsibilities, which can be edited as needed (see the figure below).
Examples
There are several examples below of Roles and Responsibilities from existing regional ITS architectures. In all of these cases the component is defined as Operational Concept, which contains the roles and responsibilities. In some cases these are shown in documents. The example below is the first page from the Operational Concept from the Alabama Statewide ITS Architecture.
Alabama Statewide Architecture Operational Concept Example
Roles and Responsibilities can be described on websites in a variety of ways. The diagram below shows one example from the Hawaii Statewide ITS Architecture, which is organized by stakeholder, with the example below showing a portion of the R&R for the Hawaii DOT – Highways Division.
Hawaii Statewide Architecture Operational Concept Example
Another example of Roles and Responsibilities on a web version of an architecture is the one shown below from the San Francisco Bay Area ITS Architecture. This architecture shows an Operational Concept organized by Service Package area with the example showing a portion of the Traveler Information section of the Operational Concept.
Bay Area ITS Architecture Operational Concept Example