- Briefing Room
U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
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.
CONTEXT OF PROCESS:
INITIAL SYSTEM DEPLOYMENT PROCESS
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.
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:
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.
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?
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?
|Has a comprehensive set of deployment goals been developed?|
|Can those deployment goals be traced into the deployment strategy?|
|Does the deployment strategy consider available funding?|
|Does each step in the deployment strategy produce an operationally useful and maintainable deployed system?|
|Does the deployment strategy minimize the risk of interference to on-going operations?|
|Does the deployment strategy offer a viable operational fallback at each step of the process?|
|Are all stakeholders in a deployment step aware of their roles and responsibilities?|
|Are all resources needed for a deployment step available?|
|Has a work-around plan been developed in case a needed resource is not available?|
Are there any other recommendations that can help?
Factors that should be considered when developing a deployment plan:
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.
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.