When the final milestones for the Building Phase have been met, the Deploying Phase begins, starting with the initial deployment.

The Deploying Phase

The Deploying Phase is the period during which the team deploys the solution and ensures that it is stable and usable. The Deploying Phase culminates in the Deployment Complete Milestone, at which point responsibility for the solution shifts to IT Operations and the support teams.

Key Tasks

Table 11 lists key Deploying Phase tasks and deliverables and their owners.

Table 11. Deploying Phase Key Tasks , Deliverables , and Owners

Key tasks



Deploying core technology

Deployment servers at each location have been installed, configured, and tested; administrative staff have been trained

Release Management; User Experience; Test

Deploying sites

All computers at each site have been fully installed, configured, and tested; users have been trained

Release Management; User Experience; Test

Stabilizing the deployment

All computers are stable and have been measured against the project success criteria

All roles

Completing the deployment

IT Operations and support staff have assumed responsibility for all computers; all roles sign off on the Deployment Complete Milestone; the customer is satisfied with the deployment as indicated in writing

All roles

Team Focus

Table 12 outlines the primary activities of each team role during the Deploying Phase.

Table 12. Deploying Phase Role Clusters and Focus

Role Cluster


Product Management

Customer feedback and sign-off

Program Management

Stabilization management


Problem resolution


Test case results and issue tracking

User Experience


Release Management

Deployment management; change approval

Feature Team and Job Aid Documents

The following documents are used in the Deploying Phase:

  • Deployment Plan (job aid)

  • Application Compatibility Feature Team Guide

  • Deployment Feature Team Guide

  • Desired Configuration Monitoring Feature Team Guide

  • Infrastructure Remediation Feature Team Guide

  • Test Feature Team Guide

  • User State Migration Feature Team Guide

Deploying Core Technology

Deploying the core systems and services that support the client deployments is a key step in the Deploying Phase and includes updating the deployment plan and establishing deployment servers.

Updating the Deployment Plan

If the team has properly planned and developed the solution, deployment should be a routine activity. During the Envisioning Phase, teams assessed and documented the current computing and networking environment, including information about domains and physical locations. During the Planning Phase, teams created the deployment plan with more specific and up-to-date details about deployment. Now that development activities are finished, the teams must update the deployment plan again with the most current information they have and use it to deliver the solution to their users.

Establishing Deployment Servers

Teams must establish servers to hold the images unless they plan to format all hard disks at a central location and ship them to the different sites covered in the project. Many projects, therefore, require that the team establish one or more deployment servers to be used in deployment. These servers can contain disk images, solution scripts to be used in the deployment process, and applications to be installed for specific users, as well as backup copies of user data and entire system backups. The team should have specified distribution server placement in the Planning Phase. Review this plan and update it, if necessary.

Deploying Sites

With site deployments, the project team completes the final step in the process of bringing the solution to the users. Deployment personnel visit each site and use the selected delivery vehicle (disk images or unattended installation from distribution servers) to install Windows and associated applications on each targeted computer.

For the purposes of deployment, the team should consider each site separately and independently because different sites may have unique requirements that make a strict overall deployment strategy impractical. Treat each site as a miniature deployment project that requires its own preparing, installing, training, and stabilizing stages.

Site Deployment Strategies

Site deployments necessarily involve trade-offs, which carry certain risks. The team should take the schedule, resource availability, and project scope into account and use MSF concepts such as the trade-off triangle when making decisions about the site deployment strategies to use. To minimize risk, the team should decide during the Envisioning and Planning Phases which deployment strategies to use before beginning any deployment-related tasks.

The team may also choose to deploy the solution to sites serially or in parallel. In a serial deployment, the Deployment feature team performs all deployment tasks at one site, then moves to the next site, and so on. Serial deployments generally require fewer resources and cost less but typically take longer than comparable parallel deployments. In a parallel deployment, the Deployment feature team performs all deployment tasks at all of the sites at the same time. Parallel deployments cost more because of the additional resources they require (including staff at each location), but the team can complete them more quickly.

Another trade-off to consider involves preplanning a deployment versus using just-in-time planning. Preplanned deployments, in which the team conducts site surveys to plan the deployments in advance, are preferable to just-in-time deployments, in which the team members plan each deployment as they arrive at the site. However, the just-in-time approach is sometimes necessary in situations in which the sites are not easily accessible ahead of time.

Preparing for Site Deployment

Site deployment involves three distinct activities:

  • Inventorying. Validating the information collected for the deployment plan or, if appropriate, conducting a new site survey

  • Scheduling. Finalizing a schedule and timeline for the installation process

  • Informing. Letting the site know when the deployment will occur, then using the strategy in the communications plan

The Release Management Role Cluster takes the lead in performing these preparatory tasks, which can usually be performed off-site. Perform all three of these activities for each site included in the deployment.

Performing Installations

The team does not install the solution until all preparatory activities are complete, thereby minimizing both disruption to the users and confusion over the process. In some cases, last-minute issues discovered during the preparatory phase may indicate a need to revisit the site later after issues are resolved.

Installing the solution should be one of the least complicated parts of the deployment project. If the team has accounted for all the computers and peripherals to be affected by the deployment and planned accordingly, it should encounter few, if any, surprises.

If the Deployment feature team encounters errors along the way, it should log them using its preexisting issue-tracking system and resolve them as quickly as possible. Depending on the nature of the issue, the development feature team may have to revise the solution scripts and perhaps create new disk images.

Stabilizing the Site Deployment

Stabilization is an important part of the site deployment process. It is the responsibility of the Deployment feature team to remain with the project until it is comfortable putting the solution into production.

Ensure that the system is stable while the Deployment feature team and any associated resources are still on-site. To do this, the team must focus on the success criteria as defined by the vision and scope and collect feedback, using the mechanisms defined in the deployment plan.

As with site installation, the Deployment feature team should stabilize each site individually, treating each as an autonomous unit. After all the sites are stable, the team can move on to consider the stability of the project as a whole.

Stabilizing the Deployment

It can be difficult to determine when a deployment is complete so that the team can close the project. Newly deployed systems are often in a constant state of flux, undergoing a continuous process of identifying and managing production support issues. The team can find it difficult to close the project because of ongoing issues that will surface after deployment. For this reason, the team needs to clearly define a completion milestone for the deployment. If the team does not perform a complete transition to a production operations and support system, it will not be able to disengage from the project or focus on closing it.

If the organization expects members of the project team to be involved in ongoing maintenance and support, those members should move into a new role as part of the operations and support structure after the project closes. At this late stage, team members not involved in operations and support will likely begin to leave the project.

Completing the Deployment

Upon completion of client system deployment, focus turns to transitioning the deployment to the customer and support staff.

Making the Transition to IT Operations and Support

Part of disengaging from the project includes moving operations and support functions to permanent staff. In many cases, the resources to manage the new systems will already exist. In other cases, designing new support systems may be necessary. Given the scope of designing new support systems, it may be wise to consider it a separate project.

Tasks to perform when making the transition to IT Operations and support teams include:

  • Activating reporting systems to refer inquiries and help requests to appropriate operations and support personnel.

  • Publishing a knowledge base to provide operations and support staff with access to information and documentation related to the project. For example, provide the issue-tracking and change-control databases to give operations and support information about the history of the project and the team’s decision-making process.

Signing Off on the Project

After all the deployment tasks are completed, the team must formally agree that the project has met the Deployment Complete Milestone and that project work is finished. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.

As before, project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document becomes a project deliverable.

Obtaining Customer Sign-Off

Upon project closure, the product manager obtains the final sign-off from a representative of the customer or organization, signaling approval of the solution and permission for the team to disengage from the project. Although at this point the team is busy informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgment that the project is complete.

Key Milestone: Deployment Complete

Before completing this phase, the following items should have been accomplished:

  • Acceptance of responsibility for operations and support by IT Operations

  • Project sign-off received


Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases


Send us your comments or suggestions