A successful ITS project is one which completes on schedule, within budget, and delivers all capabilities required in a manner that meets the needs identified by its owner. ITS projects that are prone to failure typically involve systems not previously deployed by the agency, a new process that the lead agency has not done before, and/or the need to coordinate with other agencies. The project also might include new technology or new software, or new communications, or joint efforts with new partners. A key first step in the management of an ITS project is to evaluate the level of risk which the project will entail.
Project risks relate to the general categories of risk defined in Section 3.4.4 and include technical, schedule, cost, institutional, etc. When considering the overall risk associated with a project the likelihood that these risks listed above can increase or decrease significantly based on several identified factors associated with ITS projects. The factors are:
1.) Number of jurisdictions and modes
2.) Extent of software creation
3.) Extent of proven hardware and communications technology used
4.) Number and complexity of new interfaces to other systems
5.) Level of detail in requirements and documentation
6.) Level of detail in operating procedures and documentation
7.) Service life of technology applied to equipment and software
These risk factors are discussed in more detail in Table 14.
Table 14: Identifying Risk Factors
|
Factor |
Type of Risk |
Low-Risk Project Attributes |
Medium-Risk Project Attributes |
High-Risk Project Attributes |
Risk Factors |
|---|---|---|---|---|---|
|
1 Multiagency involvement |
Institutional |
Single agency and single transportation mode (highway, transit or rail) |
Multiple sections, departments or disciplines within an agency or a small number (e.g. 2or 3) agencies. |
Multi-Jurisdictional or Multi-modal |
With multiple agencies, departments, and disciplines, disagreements can arise about roles, responsibilities, cost sharing, data sharing, schedules, changing priorities, etc. Detailed written agreements can be an important way to reduce the risk for higher risk projects. Even within a single agency, agreements may be relevant if the project spans departments or disciplines. |
|
2 Software creation |
Technical, Schedule |
No software creation; includes software already used by agency to address similar requirements |
Primarily software / hardware used by the agency or existing software /hardware based with some new software development or new functionality added to existing software - evolutionary development. |
Custom software development is required |
Even existing ITS software-based systems have many optional capabilities and require customization and configuration. Custom software requires additional development, testing, training, documentation, maintenance, and product update procedures --all unique to one installation. This is very expensive, so hidden short-cuts are often taken to keep costs low. Additionally, integration with existing software can be challenging, especially because documentation is often not complete and out-of-date. |
|
3 Technological maturity |
Technical, Schedule |
Hardware and communications technology already used by the agency with documentation to address similar requirements |
Hardware and communications technology being used to address requirements that go beyond those that agency has previously defined. May involve multiple technologies to be implemented. |
Hardware or communications technology are “cutting edge” or not in common use. |
New technologies are not “proven” until they have been installed and operated in a substantial number of different environments and have It has been demonstrated (and documented) to fulfill the same set of requirements as are being used for the project in question. New environments often uncover unforeseen problems. New technologies or new businesses can sometimes fail completely. Multiple proven technologies combined in the same project would be high risk if there are new interfaces between them. |
|
4 Interface maturity |
Technical |
No new interfaces |
System implementation includes one or two major subsystems. May involve significant expansion of existing system. System interfaces are well known and based primarily on duplicating existing interfaces. |
New interfaces to other systems are required. |
New interfaces require that documentation for the “other” system be complete and up-to-date. If not (and often they are not), building a new interface can become difficult or impossible. Duplication of existing interfaces reduces the risk. “Open Standard” interfaces are generally well-documented and low risk. |
|
5 Requirements completeness |
Technical, Schedule |
System requirements fully-detailed in writing |
System requirements are only partly detailed- some additional definition work required |
System Requirements not detailed or not fully documented |
System Requirements are critical for an RFP. They must describe in detail all of the functions the system must perform, performance expected, plus the operating environment. Good requirements can be a dozen or more pages for a small system, and hundreds of pages for a large system. When existing systems are upgraded with new capabilities, requirements must be revised and rewritten. |
|
6 Operational preparedness |
Personnel, Schedule |
Operating procedures fully-detailed in writing |
Some operating procedures are detailed in writing, but revisions or new portions are required. |
Operating procedures not detailed or not fully documented |
Standard Operating Procedures are required for training, operations, and maintenance. For existing systems, they are often out-of-date. |
|
7 Technological obsolescence |
Technical, Schedule, Cost |
None of the technologies used are near end of service life |
One of the technologies included are near end of service life |
Multiple technologies included are near end of service life |
Computer technology changes rapidly (e.g. PC’s and cell phones become obsolete in 2-4 years). Local area networks using internet standards have had a long life, but in contrast some mobile phones that use proprietary communications became obsolete quickly. Similarly, the useful life of ITS technology (hardware, software, and communications) can be short. Whether your project is a new system or expanding an existing one, look carefully at all the technology elements to assess remaining cost-effective service life. |
There are other factors that can affect project risk including the experience of agency staff implementing the project, and the clarity of the user needs defined for the project.
An example of a Low-Risk ITS project is the addition of 30 full matrix dynamic message signs to an existing system that has five identical signs already deployed. Project sponsor’s needs and project requirements are well defined. No changes are needed to the existing central or field equipment. The system was initially designed to accommodate these additional signs so no additional software is needed. Assumptions are: 1) the initial system has been completed and the system is working well, 2) the contractor will deploy the signs, poles and foundations, controllers, and wire the controllers into the signs, and 3) the agency will add configuration information about the signs at the central computer. Updates to the existing plans have been reviewed to ensure that the original design and implementation is not adversely affected as a result of adding the elements.
During the design process, it may be discovered that a number of changes to the existing system are needed in addition to adding the expansion elements. This need could arise because of new and better technologies (or the old hardware is no longer available), or because of the desire to improve or expand the functionality of the “previous” system, or because of the need to use the system in a different way, e.g., sharing control with another party. Any of these instances would elevate the project to a Medium-Risk implementation.
Additional examples of Low-Risk ITS projects include:
· Adding new or existing signals to a new or coordinated signal system.
· Adding five identical CCTV cameras to the existing 20 – with no other changes to the system or how it’s used.
· Adding 50 identical new loops to the existing 200 – no other changes.
· Installing an existing parking management system at 2 additional garages – with no changes
· Expanding the pre-existing system/network by adding several more XXXX units – with no changes. (XXXX can be almost any ITS element).
· Expanding existing communications systems – this consists of extending existing fiber-optic or wireless communications systems, using the same technology and specifications as the pre-existing system.
· Leasing turnkey services only (e.g., website-based information service) – with no hardware or software purchases.
High-Risk projects imply that some (or all) of the seven risk factors have attributes in the medium or high-risk range. This can often occur when the project is a new system deployment such as creation of Transportation Management Centers, introduction of regional Integrated Corridor Management, development of new parking management systems, and creation or expansion of toll lanes. To give a more explicit example, a High-Risk ITS project might result from adding the following new requirement to the previously described Low-Risk project: “The changeable message signs will have shared control with a partner Agency B.” For this example, Agency B manages events at two activity centers. As part of the installation, Agency A will be installing six signs that would assist agency B for their event management. Agency B would use the CMS to divert traffic to get the attendees in and out of the event faster and more safely. To enable this shared control, new software may need to be developed and integrated into the existing system. With this requirement for new functionality (shared control), new risks and complexity are introduced. Although the traditional roadway Design/development and construction process is needed for the signs and controllers at each location, there will be a need for systems engineering to address the software development and integration efforts. In this example, revisions to the existing “concept of operations” and development of agreements for interagency coordination will be especially important to clarify expectations and avoid future disputes.
Additional examples of High-Risk ITS projects include:
· Development and/or deployment of applications for mobile computing devices that involve safety or liability considerations or integration with larger systems.
· Local agency using consultants to operate a TMC and/or centralized signal management facility.
· Multi-jurisdictional or multi-modal system implementation --Because of the external interfaces required, these projects generally include substantial software development. For example:
o A traveler information system that collects data from multiple agencies or modes
o A Bus Traffic Signal Priority system between City Traffic and Regional Transit, or one that crosses multiple jurisdictions.
· The first stage of an “umbrella” system implementation. During this first stage, the full systems engineering process would be used to develop the overall system framework plus the first implementation of that framework. For example:
o New Traffic Signal Coordination system design plus implementation at an initial number of signals, with more signals added in later project(s).
o New Traffic Information System design plus the first implementation in Cities X and Y, with more cities added in later project(s).
o New Electronic Fare-Payment System design and initial implementation on Metro buses, with other transit agencies added in later project(s). If subsequent stages replicate the initial implementation, they would not be high risk. Instead, they fit the definition of a low risk ITS project, expanding the existing system with no new capabilities, and no new interfaces.
To evaluate the agency’s overall level of risk of an ITS project, consider the 7 areas of risk described above. The result to this evaluation is not a binary (or trinary) choice, but should be evaluated based upon which areas of risk are higher and which lower. On one end of the spectrum, if all seven areas are judged to be have low risk attributes, then it’s clear that the overall risk would be judged as low. On the other end of the spectrum, a project that has all (or most) of the attributes that are high risk, and the project is clearly a high-risk project. If the seven areas are a mix of risk attributes levels, then an agency should consider customizing their process (see section below) around the level of risk to each of the questions. For example, if there are no requirements documented for the system, but other factors veer toward the low risk side of the spectrum, then the project should pay particular attention to requirements.
