#   *Cross-Cutting activities*

## Purpose of this Document  {#purpose-of-this-document .HB-Heading-2}

The primary purpose of this chapter is to introduce and describe the
activities of an ITS program that are important to successful migration.
These activities should occur throughout the life-cycle of all systems
and software projects, including migration projects, and are thus
referred to as "cross-cutting" activities. The three cross-cutting
activities for the purposes of this document are:

-   Change/configuration management and documentation - Identifies the
    policies, procedures, and tools to effectively manage system change.
    Addresses documentation of the system configuration and the changes
    made to it. Documentation allows an on-going understanding of the
    system and the changes made so that the system can evolve in a cost
    effective manner. Documentation usually serves as a means to
    baseline a system and all of its components each and every time a
    change is made.

-   Risk Management -- An activity that helps to identify and resolve
    risks that may affect project success.

-   Outreach -- Provides the means through which the reasons for and
    benefits of system migration can be expressed. Outreach also
    provides the ability to solicit and incorporate stakeholder feedback
    into the migration process.

The discussion of each of these activities that follows is intended to
raise awareness of these activities and demonstrate the need to include
them in a migration project. Each section will refer to other documents
that cover the subject activity in more depth. Readers are encouraged to
go to these references for information on how to conduct each of these
activities.

## Change/Configuration Management and Documentation {#changeconfiguration-management-and-documentation .HB-Heading-2}

Transportation systems are in a constant state of change. Regardless of
whether systems are repaired, updated or replaced practitioners
responsible for making these changes should follow a formal change
control, or configuration management process. Without a configuration
management process, transportation systems may be changed without prior
written approval or consideration of the impacts associated with the
change. Changes that are less important may be implemented, absorbing
resources that could be applied to the most important and valuable
changes. Without configuration management, changes may not be documented
at all. Without documentation of changes, an effort to make a needed
change may start from an old version of the system or may not take into
account undocumented changes. Reworking the needed changes is likely to
result, causing more time and resources to be invested.

As transportation management systems become more complex and the cost of
these systems grow, more and more agencies have established formal
change control procedures to better manage changes to their systems.
Configuration management controls change by defining a new baseline
every time system change occurs.[^1] In doing so, adverse effects of
system change are minimized and system performance, reliability and
interoperability are improved. A configuration management program will
help establish an effective and consistent approach to manage
system/software change and will mitigate the potential negative impacts
associated with these changes. The purpose of configuration management
is to keep the physical implementation of a product consistent with the
documentation that describes how to build it and what it is supposed to
do.[^2] This is achieved by keeping the product and all its associated
documentation synchronized throughout the system life cycle. (The FHWA
has two excellent documents that discuss configuration management for
ITS. They are Configuration Management for Transportation Management
Systems Handbook, report number FHWA-OP-04-013, and A Guide to
Configuration Management for Intelligent Transportation Systems, report
number FHWA-OP-02-048.)

Configuration management helps agencies to:

-   Maintain the system.

-   Maintain system reliability.

-   Upgrade existing systems.

-   Expand existing systems.

-   Share information with other systems.

Change/Configuration management provides:

-   A mechanism for individuals to request a change.

-   An analysis of the impact of a change.

-   A formal decision regarding the change.

Change/Configuration management processes are also needed to document
the following;[^3]

-   The individual or parties making the change,

-   A description of the change that is made and its effects,

-   Reasoning as to why the change was made, and

-   The date and time when the change was made.

Documentation is critical for successfully completing TMS migration
projects. Generally speaking, documentation is needed to preserve
knowledge of both legacy and target systems.[^4] For instance,
documentation is needed to preserve legacy system attributes and to
communicate how these attributes will evolve over time to meet future
agency needs and goals. Documentation is also needed as aspects of the
target system change over time. In these roles, documentation helps
maintain an up-to-date understanding of the system or project. Failure
to document changes may result in practitioners having to back track to
baseline the system so future changes or improvements can be made. In
those cases where no documentation has been preserved, baseline systems
cannot be reproduced at all.

At various points throughout an ITS migration project, aspects
pertaining to the project should be documented and preserved in a formal
change/ configuration management process.

##  Risk Management {#risk-management .HB-Heading-2}

All ITS projects, whether they are new implementations or migrations,
should include a risk management process. The process is easily scalable
to the needs of each project, so it need not be onerous. The essence of
risk management can be boiled down to answering the following four
questions:

-   What can go wrong on this project?

```{=html}
<!-- -->
```
-   What is the likelihood of each of these risks?

-   If realized, how severe would the effect of these risks be?

-   What can I do to avoid, or reduce the impact of, key risks?

Risks are typically characterized as negative impacts to cost, schedule,
and scope.

### Cost {#cost .HB-Heading-3}

For a given project, the cost-based risks include those that cause the
project to exceed the programmed budget and those that may result in
losing project funding. In addition, on a program-wide basis, the risk
of unmanageable ongoing operations and maintenance costs needs to be
assessed. The business planning element of a migration plan should
include mechanisms to minimize operations and maintenance costs.
Consideration should be given to costs of technology obsolescence,
technology age, market conditions, staff skills, and other factors.

### Schedule {#schedule .HB-Heading-3}

Risks to an individual project that affect the ability to meet important
schedule needs should also be identified. Additionally, the impact of
not meeting schedule, and appropriate contingency plans, should be
included in project risk assessments.

### Scope {#scope .HB-Heading-3}

The scope for an ITS project not only includes ensuring that a
particular set of items is installed at locations noted in contract
documents, but has a particular focus on functionality. What are the
risks that may cause a device or system to fall short of functionality
goals? With respect to migration, an additional question to ask is
question "What are the risks to maintaining system operation?".

### Risk Management Process {#risk-management-process .HB-Heading-3}

Time and effort are needed to identify and manage risks. However, by
proactively managing risks, potential problems and the costs associated
with fixing them can be mitigated or avoided all together. The act of
managing risks is more easily accomplished if practitioners follow a
commonly accepted process. In March 2000, the American Association of
State Highway and Transportation Officials (AASHTO) released a report,
titled "ITS Software: Effective Acquisition Practices".Error: Reference
source not found In this report a basic process for managing risks is
defined. This process is illustrated in Figure 8-1 and described in
greater detail in the following sections.

![](media/image1.wmf){width="4.495138888888889in"
height="4.316666666666666in"}

Figure 8‑1: Risk Management ProcessError: Reference source not found

Risk Identification

The risk identification process typically is accomplished in a working
meeting with the contractor and agency staff. Useful tools to help
facilitate risk identification include lists of key risks identified in
previous projects, or in the literature. If no prior experience exists,
the risks noted in Table 8-1 and Table 8-2, can be used as a starting
point. Table 8-1 is from Steve McConnell's *Rapid Development*, which
includes good discussion of risk management for software development
projects. Most of what McConnell includes for risk management can be
applied to any technology project, including ITS projects. Table 8-2 is
from AASHTO's *ITS Software: Effective Acquisition Practices*."

Table 8‑1: Example Project Risks[^5]

+-----------------+----------------------------------------------------+
| **Risk          | **Example Risks**                                  |
| Category**      |                                                    |
+-----------------+----------------------------------------------------+
| Schedule        | -   Schedule is optimistic "best case", rather     |
| Creation        |     then realistic "expected case".                |
|                 |                                                    |
|                 | -   Schedule omits necessary tasks.                |
+-----------------+----------------------------------------------------+
| Organization    | -   Project Languishes too long on the fuzzy       |
| and Management  |     front-end.                                     |
|                 |                                                    |
|                 | -   Non-technical third party tasks are longer     |
|                 |     than expected.                                 |
+-----------------+----------------------------------------------------+
| End Users       | -   End users insist on new requirements.          |
|                 |                                                    |
|                 | -   End user finds product to be unacceptable,     |
|                 |     requiring redesign and rework.                 |
|                 |                                                    |
|                 | -   End user input is not solicited, so product    |
|                 |     ultimately fails to meet user expectations.    |
+-----------------+----------------------------------------------------+
| Customer        | -   Customer insists on new requirements.          |
|                 |                                                    |
|                 | -   Customer will not participate in reviews for   |
|                 |     plans, prototypes, and specifications, or is   |
|                 |     incapable of doing so -- resulting is unstable |
|                 |     requirements and time consuming changes.       |
|                 |                                                    |
|                 | -   Customer-furnished components are a poor match |
|                 |     for the product under development, resulting   |
|                 |     in extra design and integration work.          |
+-----------------+----------------------------------------------------+
| Contractors     | -   Contractor does not deliver component when     |
|                 |     promised.                                      |
|                 |                                                    |
|                 | -   Contractor delivers components of unacceptably |
|                 |     low quality.                                   |
+-----------------+----------------------------------------------------+
| Requirements    | -   Requirements have been baselined, but continue |
|                 |     to change.                                     |
|                 |                                                    |
|                 | -   Requirements are poorly defined, and further   |
|                 |     definition expands the scope of the project.   |
+-----------------+----------------------------------------------------+
| Product         | -   Development of the wrong user interface        |
|                 |     requires additional redesign and rework.       |
|                 |                                                    |
|                 | -   Operation in an unfamiliar or unproven         |
|                 |     software environment causes unforeseen         |
|                 |     problems.                                      |
+-----------------+----------------------------------------------------+
| External        | -   Product depends on governmental regulations,   |
| Environment     |     which change unexpectedly.                     |
|                 |                                                    |
|                 | -   Product depends on draft technical standards,  |
|                 |     which change unexpectedly.                     |
+-----------------+----------------------------------------------------+
| Personnel       | -   Personnel need extra time to learn unfamiliar  |
|                 |     software tools or environment.                 |
|                 |                                                    |
|                 | -   The personnel most qualified to work on the    |
|                 |     project are not available.                     |
|                 |                                                    |
|                 | -   Key personnel are available only part of the   |
|                 |     time.                                          |
+-----------------+----------------------------------------------------+
| Design and      | -   Overly simple design fails to address major    |
| Implementation  |     issues and leads to redesign and               |
|                 |     re-implementation.                             |
|                 |                                                    |
|                 | -   Schedule savings from productivity enhancing   |
|                 |     tools are overestimated.                       |
+-----------------+----------------------------------------------------+
| Process         | -   Amount of paperwork results in slower progress |
|                 |     than expected.                                 |
|                 |                                                    |
|                 | -   Inaccurate quality tracking results in not     |
|                 |     knowing about quality problems that affect the |
|                 |     schedule until late in the process.            |
|                 |                                                    |
|                 | -   Half-hearted risk management fails to detect   |
|                 |     major project risks.                           |
+-----------------+----------------------------------------------------+

Table 8‑2: Example Project RiskError: Reference source not found

+-----------------+----------------------------------------------------+
| **Risk          | **Example Risks**                                  |
| Category**      |                                                    |
+-----------------+----------------------------------------------------+
| Institutional   | -   Departments within the agency do not work well |
|                 |     together.                                      |
|                 |                                                    |
|                 | -   The agency staff are inexperienced in ITS      |
|                 |     projects.                                      |
|                 |                                                    |
|                 | -   The contractor staff are inexperienced in ITS  |
|                 |     projects.                                      |
|                 |                                                    |
|                 | -   The decision making process at the public      |
|                 |     agency is slow.                                |
|                 |                                                    |
|                 | -   Contractor project management is poor.         |
|                 |                                                    |
|                 | -   Loss/change over of key staff (agency or       |
|                 |     contractor) during the project development     |
|                 |     life cycle.                                    |
+-----------------+----------------------------------------------------+
| Technical       | -   Attempting to implement a system that has      |
|                 |     never been developed before, or modifying a    |
|                 |     system to add never-before-developed           |
|                 |     functionality.                                 |
|                 |                                                    |
|                 | -   Legacy systems are involved.                   |
|                 |                                                    |
|                 | -   "Closed" systems (proprietary) must be         |
|                 |     integrated.                                    |
|                 |                                                    |
|                 | -   Inability to beta-test the system using "live" |
|                 |     or real data.                                  |
|                 |                                                    |
|                 | -   Poor functional requirements.                  |
+-----------------+----------------------------------------------------+
| External Risks  | -   Foreign market conditions change component     |
|                 |     costs or delivery schedules.                   |
|                 |                                                    |
|                 | -   Technology changes during development,         |
|                 |     affecting the system design.                   |
+-----------------+----------------------------------------------------+

Risk identification is not a one-time activity. As part of overall risk
management, once a list is developed, it must be revisited to determine
if new risks have been identified, and if any risks already identified
have disappeared. Some projects merit reviewing the risk list as part of
regular progress meetings. Others require review at key milestones.

Risk Analysis

Risk analysis involves identifying the risks that are most critical.[^6]
This helps focus risk management efforts, and ensures that resources are
used to manage only the worst risks.

Once risks are identified, they need to be analyzed for potential impact
-- the extent of damage that would occur if the risk were realized. The
impact should relate to cost, schedule, and scope (functionality). Risk
analysis should also include assessments of risk to the agencies
standing in the view of key decision-makers, agency leadership, and the
general public, if appropriate. Risks can then be ranked with the most
severe risks at the top of the list.

The analysis should also address the likelihood that a risk may occur. A
matrix can be developed with impact and likelihood on the axes, as shown
in Table 8-3.

Table 8‑3: Example Project RiskError: Reference source not found

+------+--------------------+-------------+-------------+-------------+
|      |                    | *           |             |             |
|      |                    | *Likelihood |             |             |
|      |                    | of          |             |             |
|      |                    | O           |             |             |
|      |                    | ccurrence** |             |             |
+------+--------------------+-------------+-------------+-------------+
|      |                    | High        | Medium      | Low         |
+------+--------------------+-------------+-------------+-------------+
| > ** | High               | A           | B           | C           |
| Impa |                    |             |             |             |
| ct** |                    |             |             |             |
+------+--------------------+-------------+-------------+-------------+
|      | Medium             | D           | E           | F           |
+------+--------------------+-------------+-------------+-------------+
|      | Low                | G           | H           | I           |
+------+--------------------+-------------+-------------+-------------+

The focus of risk planning and mitigation can then be placed on the
risks in cells A, B, and D if the list does not become too long. Many
risk management experts also suggest that risks in cell C should not be
ignored. This is because participants in risk planning often are not
able to accurately assess the likelihood of risk occurrence as well as
risk impact. Murphy's Law applies, in that the risks that are not
expected are often the ones that do occur. In addition, individuals
often mentally prepare for risks with high likelihood, while ignoring
the risks with the lowest likelihood.

Risk Planning

Risk Planning involves identifying early indicators that the risk may
occur, and identifying potential avoidance and/or mitigation strategies.
For example, an early indicator that key staff may be contemplating
leaving could be high overall staff turnover. Another indicator could be
that competing industries (e.g., the dot.com industry) are growing and
recruiting staff. A mitigation strategy could include contract terms
that ask the prime to contract with key staff who have departed to bring
the project to conclusion or to a key progress milestone. This action
could only be implemented if the key staff agree to such a contract and
there was a mechanism to compensate the contractor for any added costs
that might occur because of this additional subcontracting effort.

Risk Resolution

Identifying, analyzing and planning for risks alone does not constitute
an effective risk management process. Identified risks may be avoided on
a project-by-project basis; however, if risks are left unresolved, they
may resurface, and may affect not only a current project but potentially
a future project. Therefore, the factors that cause a risk must be
resolved so that risks do not reappear and inflict additional damage.
For example, a key risk that was identified by ITS practitioners is that
staff lack key ITS skills. A particular project may be successful
despite the lack of skills, but the ITS Program should still address the
staff skills issue to avoid future problems.

Risk Monitoring

Risks identified through the risk identification process should be
continually monitored to determine the impact(s), if any, risks have had
on the project, and how well the agency has mitigated the effects of
these risks. Practitioners should develop a means to track and
prioritize risks as they are identified. Depending on the needs of the
practitioner, this may be as simple as listing risks on a sheet of paper
and crossing them out when either they are addressed or as other
"higher" risks are identified.

## Outreach {#outreach .HB-Heading-2}

ITS Program outreach activities include both delivering and gathering
information from three key stakeholder groups:

-   Intra-agency stakeholders.

-   Inter-agency stakeholders.

-   General public and key decision makers.

The key goals of ITS outreach programs are to:

-   Gather support for ITS program activities and funding.

-   Develop projects that meet stakeholder needs.

-   Ensure that implemented ITS meets goals and objectives.

-   Develop consensus for multi-agency ITS efforts.

Outreach efforts for an ITS program should be on-going, whether or not
anything "new" is happening within the program. Simply connecting with
key stakeholders to let them know how the ITS systems are performing and
delivering benefits is important. Agency staff and key decision-makers
are always changing and having a consistent means to deliver a
consistent message is important to ensure continuity despite changes in
personnel. ITS program outreach can be integrated with project-specific
outreach efforts such as those involved in developing regional ITS
architectures, business plans, and project development activities.
Regular reports can be provided on a monthly or annual basis and
disseminated to all of the stakeholder groups. (More information on
outreach efforts can be found in *Building Quality Intelligent
Transportation Systems Through Systems Engineering* report number
FHWA-OP-02-046 and *Migration of Systems to Open Architectures* from the
Software Productivity Consortium.)

Intra- and inter-agency support and understanding of ITS activities, is
critical to define migration efforts, and to ensure that key
stakeholders understand the need for investment in migration. Additional
outreach is required when developing a specific migration project
design, to develop the functional and technical requirements.

Intra- and inter-agency outreach provides a medium through which the
reasons for, and benefits of, system migration can be expressed. This
helps to smooth the implementation of strategies by promoting
inter-agency cooperation while at the same time mitigating any adverse
reaction. Outreach should target upper management, system users, and
those individuals from other agencies that may be affected by migration
activities. Outreach should focus on obtaining support and input from
these groups well in advance of when transportation systems are proposed
to be migrated. At a minimum, support and input from these three groups
are needed to successfully determine what systems will be migrated, how
migration will occur and what impacts, if any, may result. Outreach
directed toward the aforementioned groups should be tailored to the
specific needs and concerns of each group. Likewise, the reasons for and
benefits of migration need to be expressed in terms each group can
easily understand.

### Intra-Agency Outreach {#intra-agency-outreach .HB-Heading-3}

Practitioners should actively engage personnel at various levels within
their organization during the ITS Business Planning stage, and at the
project implementation stage.[^7] Once internal consensus on a migration
program is achieved, practitioners should extend outreach efforts to
other individuals inside their respective organization to convey the
reasons for, and the benefits of, migration. In-reach efforts will not
only ensure common understanding between personnel, but also provides a
medium through which knowledge can be promoted and disseminated to
individuals of outside agencies.

Upper Management and Support

System migration programs require approval and support from upper
management and other department managers before they can be seriously
considered. Written approval should be obtained from upper management to
demonstrate that upper management is committed to the migration effort
and that the necessary resources will be available to ensure that the
newly implemented target system can be integrated into the everyday
operations of the agency. Support from upper management is needed to
secure the funding needed to complete migration activities and to
support staff when the target system is rolled-out. Input from managers
of other departments is needed to verify the impact of migration on
their current operations and to ensure that the target system can be
effectively integrated with other systems used in the day-to-day
operation of the agency. Managers of other departments may also identify
implementation challenges associated with the migration effort, which
can be resolved before target systems are rolled-out.

User Involvement and Assistance

Intra-agency outreach should target legacy and target users to
incorporate the needs of these individuals and to acquire input that
will benefit the migration effort. System users may provide valuable
information that may be used to plan the ITS migration effort. For
instance, user input may help those responsible for migrating systems to
more easily identify risks. Such risks may only be identified with the
knowledge of those who use the system.

Migration Management Team Formation

Practitioners charged with the responsibility of transportation system
migration may wish to use outreach as a spring board for forming teams
to conduct migration activities.

### Inter-Agency Outreach {#inter-agency-outreach .HB-Heading-3}

Practitioners responsible for migrating systems should seek to inform
other agencies that may be potentially affected by migration activities
at various points during the migration effort to keep these groups
abreast of project progress and to solicit information when needed to
support subsequent project activities. At the onset of a migration
project practitioners should engage in activities that expand the
visibility of migration activities. Practitioners should clearly explain
the benefit of, and reasons for systems migration. As the scope of the
migration becomes clearer, practitioners should provide opportunities
for stakeholders to review and comment on various activities that
dictate how the legacy system will be migrated.

### Public and Elected Officials {#public-and-elected-officials .HB-Heading-3}

Intra- and inter-agency outreach is vital for planning and implementing
ITS migration projects as previously stated. However, outreach should
extend beyond these groups to elected officials and, if the effects will
be visible, to the general public. Outreach efforts directed at these
groups should convey the benefits of migration activities in terms the
public can understand, which in turn helps to build consensus and
support for not only migration related projects and activities but also
every project implemented by the agency. Outreach efforts directed at
the general public and elected officials should seek to inform these
groups of the following issues.

-   The need for migrating the system,

-   How migration projects will be funded,

-   When migration activities will take place and timeframes for when
    benefits will be realized, and

-   How projects will be developed, including any impacts that may be
    negatively perceived by the public.

[^1]: *Configuration Management for Transportation Management Systems
    Handbook*. Report No. FHWA-OP-04-013. Federal Highway Administration
    Operations Office of Transportation Management. September 2003.
    Available at:
    <http://ops.fhwa.dot.gov/freewaymgmt/cm/docs/handbook/index.htm>

[^2]: *A Guide to Configuration Management for Intelligent
    Transportation Systems*. Report No. FHWA-OP-02-048. U.S. Department
    of Transportation Joint Program Office. April 2002. Available at:
    <http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/13622.html>

[^3]: *ITS Software: Effective Acquisition Practices.* American
    Association of State Highway and Transportation Officials. March
    2000.

[^4]: David Robinson. *Embracing Change in Real World ITS Deployments.*
    Open Roads Consulting, Inc. Available at:
    http://tmcpfs.ops.fhwa.dot.gov/cfprojects/uploaded_files/EmbracingChange.pdf

[^5]: Steve McConnell. *Rapid Development,* Microsoft Press, 1996.

[^6]: Building Quality Intelligent Transportation Systems Through
    Systems Engineering. Report No. FHWA-OP-02-046. U.S. Department of
    Transportation. April 2002.

[^7]: Migration of Systems to Open Architectures. Software Productivity
    Consortium. Available at:
    [www.software.org/sysmigweb](http://www.software.org/sysmigweb)
    Accessed January 15, 2004.