Deploying and Testing the Pilot

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When you deploy your pilot, you begin testing your Windows Server 2003 implementation under live conditions. Start the pilot deployment process with a trial run of the pilot to identify problems with the deployment and the pilot plan. Then, when the full pilot begins, keep track of which deployment tasks have been completed so that the team can monitor the progress of the pilot.

As participants use the system, have the release management team track the progress of the pilot, and pinpoint areas of concern. Encourage all participants to use the incident-tracking system to report problems and to use the escalation plan when immediate problem resolution is not possible.

In MSF, the pilot is conducted during the stabilizing phase. Figure 4.5 illustrates the steps involved in deploying and testing a pilot.

Figure 4.5   Deploying and Testing the Pilot

Conducting a Trial Run of the Pilot

Before you deploy the pilot, perform a trial run of the process. A trial run is a rehearsal of all the elements of the deployment that allows your team to identify problems prior to deploying the pilot.

To perform a trial run, schedule a time during nonbusiness hours to perform the entire upgrade process, to test the new setup thoroughly, and then to back out all components of the implementation. Use the same deployment task checklist that you plan to use for deploying the pilot, as described in the next section.

Deploying the Pilot

As the installation team deploys the pilot, they need to:

• Validate all backups, clearly label them, and store them in a safe place.

• Record how long installation takes so the team can update the schedule.

• Identify and document inefficiencies, and use this information to refine the rollout process.

• Update the production deployment documents to reflect all changes that have been made during the pilot.

• Ensure that a system administrator who has full security administrative credentials, including rights to administer mail and database server passwords, is available during the pilot deployment.

Instruct the installation team to check off each of the above steps in the deployment tasks checklist as it is completed.

Resolving Issues During the Pilot Deployment

During the pilot, the participants perform their regular, daily work and report any problems by using the incident-tracking system.

Problems that are reported are reviewed, prioritized, and fixed according to procedures outlined in the issue resolution plan. Problems can be resolved either by further development, by documenting resolutions and workarounds for the installation teams and support staff, or by incorporating the resolution or workaround as supplemental material in training courses.

Depending on your team’s rollback strategy, resolving problems might require rolling back the pilot. Clear communication with participants is essential when a rollback is required.

If multiple pilots are scheduled, evaluate the results of the current pilot to determine if it meets the success criteria before beginning the next pilot.

Monitoring the Pilot

During the pilot, the release management team should continually monitor the pilot system, including the network used by the pilot group, looking for bottlenecks and areas that need to be fine-tuned. The more information you collect during the pilot, the more accurately you can evaluate its success and recommend how to proceed with the full deployment to the entire business environment.

Have the team check problem reports frequently and look for trends and for problems with traffic flow and application performance, such as:

• Degradation in performance, such as slower response time.

• Improvement in performance, such as quicker response time.

• Tasks that could be performed before, but not after, the upgrade.

• Tasks that can be accomplished only by using a workaround.

It is important that release team members visit the pilot site periodically. Talking with users frequently reveals issues or problems that might otherwise go unnoticed.

As the release management team receives feedback, they will need to assess problems that pose risk to the overall project. Specifically, they should look for situations that might result in:

• Scope changes

• Cost increases

• Interoperability problems

• Unanticipated downtime

Assessing the severity of these issues allows the release management team to make informed decisions about whether to proceed with the deployment.