U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.6.3 Initial System Deployment



The deployment process for tested system/sub-systems installs them in the intended environment for operations.


Deployment is the final design/build step in the development of a system. The deployment strategy must reflect the plan for the project. It must provide an operationally useful component of the system at each step of the process and deployment location. The deployment strategy may involve a single deployment to a single site. Or, may have to deal with multiple, partial deployments to multiple sites over an extended period of time. A complex deployment also may require post acceptance testing at each site. A written Deployment Plan may be necessary to ensure a successful deployment, especially if multiple agencies are involved. A Deployment Plan will define all the work steps for complete deployment, and who does them. At each deployment site the hardware and software is configured, installed, and then tested to show it is ready to support operations.


Shows the flow for Phase [3] Task 4, Initial System Deployment Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.



Concept of Operations provides general guidance on how the system is to be operated and therefore on how it must be deployed.

Accepted and verified sub-systems / systemsare ready for deployment.

Support Products includes training materials, users, and maintenance manuals.


Project Plan/SEMP establishes a high level description of the project management and system engineering plan for deployment.


Stakeholder involvement is needed to support the deployment activities.


Deployment Master Planestablishes the goals and a strategy for deployment. This is included in the Project Plan/System Engineering Management Plan [SEMP].

Deployment Plan [optional] documents the high level plan for deploying the system.

Deployed system is ready for operational use.

Process Activities:

Develop Deployment Strategy

The strategy defines what capabilities and parts of the overall system will be deployed, where the part will be deployed, and the timing of the deployment. The Strategy is used to allocate funding for the project over time by identifying what the timeline will be for the projects.

Write Deployment Plan [optional]

The following are considerations to prepare, review, and the approving of a written Deployment Plan:

  • A complex deployment schedule with multiple deployments of different configurations to multiple sites. For instance, a deployment of a number of Transportation Management Systems statewide with different configurations at each site
  • The needed facilities, such as electrical, air conditioning, communications infrastructure, and lighting needed to support the system. In addition, personnel training will be needed for operations & maintenance. This must be planned and performed in time for the delivery of the system
  • Several stakeholders whose activities must be coordinated for the deployment effort, especially stakeholders from different organizations and agencies. For instance, even a single ITS site may have multiple inter-agency interfaces that, when implemented, will change the operations at these external systems
  • Stakeholder consensus for the deployment plan by showing the analysis of alternatives that led to the selection approach. This is especially useful for trying to balance operationally viable deployment steps with funding availability

Whether or not a written Deployment Plan is needed, the planning must consider the timing deployment of what parts of the system, and with what capabilities.

Perform deployment activities

Managing deployment follows the same path that integration and verification have followed. First, all needed resources must be identified, obtained, and trained, including all facilities [electrical, communications, lighting], and personnel training for operations & maintenance. Then, just prior to the start of each deployment step, the readiness of those resources is determined and any work-around plans put into effect. During the performance of a deployment step, progress should be monitored and reviewed with the deployment team on a regular basis. The final step of a deployment is usually an integration and verification of the deployed system prior to operational acceptance.

Illustrates where Initial System Deployment occurs in the Vee Development Model. The deployment strategy is planned in the System Engineering Management Plan section and the initial deployment occurs in the System Verification and Initial Deployment and the System Validation sections.

Where does Initial System Deployment take place in the project timeline?

Is there a policy or standard for deployment?

FHWA Final Rule does not specifically mention initial system deployment as one of the required systems engineering analysis activities.

Which activities are critical for the system's owner to do?

  • In concert with the operating agencies, develop, review, and approve the goals and a general strategy for deployment
  • Identify and recruit agency stakeholders to participate in deployment
  • Review and approve all deployment plans
  • Monitor deployment activities. Witness critical post deployment verification

How do I fit this step to my project? [Tailoring]

Depending on various factors of the project, deployment can range from very simple to very complex. The number of deployment steps and the number of stakeholders involved in deployment are the best indicators of complexity, although there may be others of equal importance. If either of these factors warrant, then project management may decide that the expense of preparing, reviewing, and approving a Deployment Plan document is justified. If it is not, then the guidance in the Program Plan and in the SEMP, plus a qualified person in charge of deployment, is quite sufficient.

What should I track to reduce project risk and to get what is expected? [Metrics]

Deployment involves elements of both integration and verification and each of these processes has its own set of useful metrics. Beyond that, tracking progress to the schedule is the most useful thing project management can do to reduce project risk and get what is expected.

Checklist: Are all the bases covered?

check Has a comprehensive set of deployment goals been developed?
check Can those deployment goals be traced into the deployment strategy?
check Does the deployment strategy consider available funding?
check Does each step in the deployment strategy produce an operationally useful and maintainable deployed system?
check Does the deployment strategy minimize the risk of interference to on-going operations?
check Does the deployment strategy offer a viable operational fallback at each step of the process?
check Are all stakeholders in a deployment step aware of their roles and responsibilities?
check Are all resources needed for a deployment step available?
check Has a work-around plan been developed in case a needed resource is not available?

Are there any other recommendations that can help?

Recommendation.Factors that should be considered when developing a deployment plan:

  • If multiple locations are involved, the final desired configuration at each site
  • If multiple sites are involved, the relative sequence in which each site needs to reach its desired final configuration
  • The dependence on prior deployments to this or any other site. For instance, an operational site only may be viable if a maintenance center needed to support the operational site has been previously upgraded or installed
  • If a phased deployment is required [say due to a funding profile spread over several fiscal years] then a number of other factors must be considered, including:
  • Each incremental deployment phase must result in an operationally useful system
  • Each incremental deployment phase and all dependencies must be included or already installed. [ It does little good to install capability B, if capability A is needed to use B, but A is not installed until later
  • The cost of each incremental deployment phase cannot exceed the incrementally available funds

Using the Deployment Plan for selling the strategy and to provide planning and advice for a "ribbon cutting" ceremony

Use the Deployment Plan document to "sell" the selected deployment strategy. This is much more likely when a relatively complex set of deployment goals have to be met, such as when the conflicting goals of operationally useful but funding-constrained deployment phases are required. It then becomes necessary to show that not only the selected strategy meets those goals; but meets them better than any alternative strategy. The Deployment Plan is then an excellent place to document this strategy selection since much of the information is eventually needed for implementing the deployment plan.

Plan for the "ribbon cutting" ceremony – Since the deployment activity is the last step in the development process and the point where the system is turned over to the system's owner, there is sometimes a desire to turn that hand-over into a "ribbon cutting" ceremony. If this, or any other public relations type of activities, is required of the project office [as opposed to being the responsibility of the operating organization], then planning for this activity should be included as part of the deployment effort, and, if one is written, documented in the Deployment Plan.

Caution.Make sure that the operational and support team is in place when the system is commissioned into operations.In addition to the challenge of deploying an operationally viable system that meets all of its requirements, very often two other conditions have to be met. The first is that the operations people have to be available and trained in the new system's features. This may involve the recruitment of additional staff and certainly includes operational training for both new and existing staff. The second condition is to ensure that adequate maintenance support will be available. Not only does this require trained staff, but also sometimes additional facilities are required. Sometimes an existing maintenance facility has to be upgraded with additional test equipment and additional spare parts to support the system's new hardware. Sometimes a software test bed has to be created to give support staff a place to fix and test the existing software products and to develop upgrades to those same products, without interfering with normal use of the operational system.


Related Template Checklist  


Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000