The North Seattle Advanced Traffic Management System (NSATMS) was envisioned as a multi-jurisdictional arterial traffic data collection and data sharing system that would offer agencies and local governments throughout the greater Seattle, Washington, area real-time access to timely regional information about traffic conditions and traffic device status. The goals of the system were to promote regional agency coordination and cooperation, manage area traffic more efficiently, and serve as a data source for future metropolitan transportation planning and management efforts. The system would feature a central database management system that would collect information about traffic conditions and traffic device status throughout the region, and a wide-area network of remote workstations that would give participating jurisdictions access to that database.
In 1994, the Washington State DOT initiated a project to test this concept by developing an arterial data sharing system for an urban region that includes Seattle, unincorporated King County, and selected jurisdictions within northern King County and southern Snohomish County; it would also provide a testbed and data source for state intelligent transportation systems (ITS) activities. However, because of technical and project management issues, the system as originally envisioned was not implemented.
This lesson is based on excerpted results from the project’s evaluation report.
Establish a clear understanding of the research and development components of the project among ITS project partners. Software and hardware projects can range from the installation of established, widely deployed turnkey systems with well-defined installation, testing, and operations procedures to basic research projects involving the development of new and untested capabilities. The position of a project on this spectrum can have significant impacts on customer expectations, project management, scheduling, and costs.
In the case of the NSATMS project, there was a difference in perception between the client and the contractor regarding the nature of the project. The client viewed the project as a modified "turnkey" system, whereby the contractor would port an (largely) existing product to the client's environment, and the client would then direct the modifications necessary to customize the product to its particular requirements. In reality, however, the functionality of the existing modules was not as full-featured as the client had thought; as a result, the project had more of the characteristics of a software development effort, requiring software modules to be developed during the project. This difference in perceptions of the basic nature of the project had major effects upon project structure, expectations, and progress:
- The project management structure did not match the basic research and development elements of the project. Project tasks, schedules, and deliverables were based on a perception of the project as the deployment and modification of an existing product. When this turned out not to be the case, the structure of the original tasks, schedules, and deliverables were no longer well-matched to the technical and management needs of the project. The project structure was not designed with the software requirements definition and detailing tasks of a ground-up software development project in mind. Furthermore, he management tasks needed to maintain visibility into, and control over, such a project were not retroactively implemented.
- Schedules did not match the project's development components. The NSATMS project was extended well beyond its original two and one-half year schedule; the extensions were the result of factors such as changes in the scope of work (e.g., a change in operating system platform for the ATMS software) and software development issues. (Although the project schedule was not well matched to the project, it is interesting to note that participants did not consider this to be an undue inconvenience, in part because they themselves recognized the optimistic nature of the schedule. In addition, the project's relatively low public profile did not produce any firm public expectations of new public services. The absence of such expectations and any associated pressure to complete the project within a certain period reduced the impact of the schedule changes.)
- The cost estimates did not accurately reflect the project's basic research and development components. While there was some disagreement about the root cause of cost overruns for this project, the original project cost estimates did not appear to reflect the technical nature of the project.
The lesson learned from this is that the parties involved must be realistic about their technical capabilities and the true nature of the project. For this effort, the original description of existing or readily developable capabilities as perceived and accepted by the client was overly optimistic. This caused all parties to make decisions about project structure and management that in hindsight were not well matched to the software development tasks at hand. This delayed the project implementation.
(Our website has many links to other organizations. While we offer these electronic linkages for your convenience in accessing transportation-related information, please be aware that when you exit our website, the privacy and accessibility policies stated on our website may not be the same as that on other websites.)