Knowledge Resources

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:

1. 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.
2. 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.)
3. 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.