Agreements
Agreements between stakeholders define the integration planned between their systems, the plans for maintaining and operating the elements and each other's funding responsibilities.
Definition
To deploy the services and projects defined in the architecture, agreements between stakeholders may be required especially when inter-jurisdictional interfaces are involved. The architecture should list the agreements needed in order for cooperation and integration to be achieved, including how to deploy interfaces, who maintains and operates the elements, and how the operations will be funded.
Summary
|
POLICY
|
Any agreements (existing or new) required for operations, including at a minimum those affecting ITS project interoperability, utilization of ITS related standards, and the operation of the projects identified in the regional ITS architecture are required in 23CFR940.9(d)4 and FTA National ITS Architecture Policy Section 5.d.4.
|
|
APPROACH Key Activities
|
If updating an existing regional ITS architecture: - Revise existing list of agreements o Review new interfaces, services, or stakeholders o Add any new agreements or amend existing agreements to include new stakeholders, etc.
If defining a new regional ITS architecture: - Identify agency records/agreements that can be amended to include ITS - Utilize existing standard agreements for operations, integration, funding, etc. - Evaluate what kind of agreement is needed and build consensus with each of the stakeholders involved: o Memorandum of Understanding o Interagency Agreements o Intergovernmental Agreements o Operational Agreements o Funding Agreement w/ project scope and operations. - Agreements take a long time to execute. Build consensus early with simple agreements like MOUs while final agreements are being developed.
|
|
INPUT Sources of Information |
- Existing operational, intergovernmental, interagency and/or funding agreements between ITS element operating and user stakeholders. - Existing process and procedures for executing agreements between agencies. - Operational concept, interconnects, and project sequencing outputs from the regional ITS architecture.
|
|
OUTPUT Results of Process |
- List of inter-agency agreements required to deploy, operate, and maintain ITS in the region as defined in the regional ITS architecture
|
Relationship to Other Components
As shown in the figure below, agreements are mapped directly to stakeholders involved in the agreements. Although not shown in the diagram, some interfaces between elements owned by different stakeholders (but not all of such interfaces) in the regional ITS architecture might require data sharing agreements in order to be implemented.
Regional ITS Architecture Components – Agreements
Approach
The "Update Existing" and "Develop from Scratch" approaches for drafting the list of agreements differ only in the starting point. Both require review and involvement by the stakeholders involved.
The next sections describe the different activities involved in each approach:
- Updating List of Stakeholders' Agreements
- Developing a New List of Agreements
Updating List of Agreements
Agreement are directly related to stakeholders. The architecture as previously defined will have a list of stakeholders that will serve as the starting point for the update. Start by reviewing the existing stakeholder agreements that support sharing of information, funding, or specific ITS projects. Review each agreement and determine whether the existing agreement needs be amended or modified to include additional new requirements for cooperation identified in the regional ITS Architecture. Decide if current agreements are sufficient until more specific operational agreements are identified in the future. If not, develop a list of required new agreements between agencies, perhaps a handshake agreement or a simple Memorandum of Understanding (MOU) will suffice in the interim. At any step of the work, ensure all stakeholders are aware of the required agreements and their status.
At this point, the list of required agreements is compiled and new agreements that must be created are identified. Note that all that is required is a list of the agreements, not the agreements themselves. The detailed work, including the preparation and execution of the identified agreements will be performed to support ITS project implementation later in the process. A fairly detailed understanding of the existing agreements in the region and the various options for structuring new agreements are critical to composing a realistic list of agreements.
In general, the process of building consensus for any agreements can build on the process of updating the regional ITS architecture: achieving regional consensus on needs, services, roles and responsibilities, and the architectural requirements on ITS elements, their functional requirements, information flows and standards for encoding the information flows. Once these institutional and technical issues have been agreed to, the foundation for the institutional agreements is in place.
There is considerable variation between regions and among stakeholders regarding the types of agreements that are created to support ITS integration. Some common types of agreements are shown in the table below.
|
Type |
Description |
|
Handshake Agreement. |
- Early agreement between one or more partners - Not recommended for long term operations. |
|
Memorandum of Understanding. |
- Initial agreement used to provide minimal detail and usually demonstrating a general consensus. - Used to expand a more detailed agreement like an Interagency Agreement which may be broad in scope but contains all of the standard contract clauses required by a specific agency. - May serve as a means to modify a much broader Master Funding Agreement, allowing the master agreement to cover various ITS projects throughout the region and the MOUs to specify the scope and differences between the projects. |
|
Interagency Agreement |
- Between public agencies (e.g., transit authorities, cities, counties, etc.) for operations, services or funding - Documents responsibility, functions and liability, at a minimum. |
|
Intergovernmental Agreement. |
- Between governmental agencies (e.g., Agreements between universities and State DOT, MPOs and State DOT, etc.) |
|
Operational Agreement |
- Between any agency involved in funding, operating, maintaining or using the right-of-way of another public or private agency. - Identifies respective responsibilities for all activities associated with shared elements being operated and/or maintained. |
|
Funding Agreement |
- Documents the funding arrangements for ITS projects (and other projects) - Includes at a minimum standard funding clauses, detailed scope, services to be performed, detailed project budgets, etc. |
Consider the agreements needed for information sharing for integration,
which is one of the key reasons for developing the architecture. Also, avoid
being "technology prescriptive" in the initial agreements whenever possible
since technology changes rapidly. The technology selected during the planning
phase may well change as the project nears the final design phases. Of course,
there are times when technology is non-negotiable – the region may have an
agreement to use a specific standard or a legacy system must continue to be
supported or the region has already made significant investments in a
particular technology. In such cases, the agreements should reflect the
technology decisions that have been made by the stakeholders of the region.
Developing a New List of Agreements
The approach to developing a list of agreements mirrors that described above in the Updating Agreements section, just without the existing list to start from. As mentioned above, the architecture should contain a list of agreements and not the actual agreements. Through stakeholder interactions, identify existing agreements that are relevant to the regional ITS architecture. These would be agreements that address operations, maintenance, funding, etc. Next, consider any agreements needed to deploy ITS projects defined for the architecture. Agreements that support integration of systems in the region are especially important to consider and document, as these agreements are important to creating the system or data integration that is one of the key goals of deploying ITS in a region. Once agreements have been collected they can be entered into RAD-IT as described in the RAD-IT tab and reviewed by the stakeholders on the architecture website or in documentation.
RAD-IT Tab for Component
The Agreements Tab in RAD-IT is shown below and is the tab to use to enter and collect the list of existing agreements and the agreements potentially needed to deliver ITS services. Each list entry identifies the agreement title, the stakeholders involved, the type of agreement that is anticipated, high level status (existing or planned), and a concise statement of the purpose of the agreement.
Agreements Tab in RAD-IT
The RAD-IT Agreements tab has an Autoselect feature that is a good way to create your starting list. It can be used to analyze your architecture to come up with a proposed list of agreements. It will look at the interfaces tab and the inventory. For each interface where the source and destination elements are 'owned' by different stakeholders it will create a draft Information Exchange agreement.
Examples
The following example is a partial list of agreements taken from the Austin Texas Regional ITS Architecture. This regional ITS architecture identifies existing and planned agreements based on the projects developed for the region. This page is a part of the interactive architecture and for each of the agreements, the description and relevant stakeholders can be shown by selection the agreement title. An example of this, for the second agreement in the list is shown below.
Portion of the Agreements for the Austin Regional ITS Architecture
Specific Agreement from Austin Regional ITS Architecture