Planning Phase

Article
12/19/2007

The primary focus in this phase is identifying the CIs that must be changed, planning and scheduling the release deployment, and executing the deployment smoothly without interruptions to the existing IT services. Table 2 shows the high-level steps in the release Planning Phase.

Table 2. Release Planning Phase Checklist

	High-level steps in the release Planning Phase
	Scope the release. Identify which CIs will be changed with the new release.
	Define and prioritize the release. Select the release type and prioritize it according to other releases to be deployed.
	Plan and schedule activities. Determine how and when the deployment will occur.

Scope the release.

Identify which CIs will be changed with the new release.

Define and prioritize the release.

Select the release type and prioritize it according to other releases to be deployed.

Plan and schedule activities.

Determine how and when the deployment will occur.

The detailed process flow for the release Planning Phase is shown in Figure 3.

Figure 3. Release Planning process flow

Figure 3. Release Planning process flow

During the Planning Phase, all role clusters from the MOF Team Model are active and executing different tasks, as defined in Table 3.

Table 3. Release Planning Phase Activities

Role cluster	Activities
Infrastructure	Identifies how the release will interact with existing CIs in the IT infrastructure
Operations	Defines how the release should be deployed to avoid interruptions in day-to-day operations
Partner	Defines how the release may affect outsourced partners and serves as liaison between the team and third parties involved in the release
Release	Manages the entire process and other role clusters
Security	Advises on security issues related to the release
Support	Ensures that the release is fully supportable and prepares training for help desk staff and users
Services	Defines how the release may affect existing services in the IT infrastructure

Scope the Release

After an RFC is approved and passed on to release management, the release manager is in charge of identifying all CIs affected by the new release. This is done in conjunction with all MOF Team Model role clusters and involves consulting existing information in the CMDB.

The CMDB can be provided using technologies such as a Microsoft SQL Server™ 2005 database containing information gathered from Microsoft System Center Configuration Manager 2007, Microsoft System Center Operations Manager 2007, and the Active Directory® directory service as well as non-Microsoft applications.

In an operating-system deployment project, the CIs involved represent the different computers to be installed or upgraded, the services being delivered to the end users of such computers, and the images available in the DSL that will be used for deployment.

Define and Prioritize the Release

A major release, such as a new operating-system deployment, should be treated as a single separate project by the release manager. Keep in mind that a single release may encompass multiple RFCs. This is normally done when the RFCs change the same CI and have some type of dependency. For instance, a single operating-system upgrade may be composed of RFCs for a memory upgrade, a disk upgrade, and the actual operating-system deployment.

After the RFCs’ dependencies are identified through the several RFCs received from change management, the release manager can define what RFCs will be group into a release. After the releases are defined, the release manager can move on to prioritizing the releases based on the information gathered by the release team from all MOF role clusters.

Plan and Schedule Release Activities

After a release has been defined and prioritized, the release manager can start planning the tasks that need to be executed in order for the release to be deployed in the IT infrastructure. In an operating-system deployment project, release planning identifies the necessary conditions that must be met in order for an image to be deployed. For some computers, the deployment can occur only when users are not using their computers. For servers, the deployment may occur only during a planned downtime of the IT service affected by the release.

The release plan should also include a detailed back-out plan that specifies the tasks to be executed to return the CIs to their original states prior to deployment in case anything goes wrong. For instance, if the upgrade to Windows Vista on a given computer is not performed within a certain amount of time, the release manager may want to abort the upgrade and recover the previous operating system settings.

Determine Release Team Composition and Roles

Team composition and roles are defined based on the type of release. For a minor release, it may only be necessary to distribute a package in a scheduled time—a task that can be performed by a single individual. However, a major release, such as an operating system deployment, may be composed of several tasks: a hardware upgrade, configuration changes, an image deployment, and so on. In this case, the release manager may choose different team members to execute each task, according to the required knowledge and skill level.

Identify Training, Logistics, and Communication Requirements

When deploying a new operating system to workstations and servers, the release manager has to worry about the possible need to train the personnel who will use the operating system as well as the service desk staff, technical support team, and operations staff. As part of their responsibilities, the release manager must identify the people affected by the release and determine whether and what kind of training should be applied.

In addition to training needs, the release manager is also responsible for managing the logistics of the release in terms of scheduling the release to occur and ensuring that the proper resources are available when needed. This may sound simple; but in a major operating system rollout across multiple regions with thousands of client computers, it may be a complex and time-consuming task.

Finally, proper communication channels must be in place for a successful release. For an operating system rollout, users must be informed when their computers will be replaced or upgraded. The operations team must be aware of the changed CIs, because they monitor the CIs in their day-to-day activities. Ensure that a good communication plan is in place to inform all interested parties about the release.

Document and Agree on a Release Strategy

After the release manager has allocated resources for the release, determined the deployment schedule, created a communication plan, and identified the necessary training for the release, the release strategy can be put together.

The release strategy is composed of all information referred to previously along with a risk assessment of the release, a back-out plan, and all the necessary forms to get the release deployment started.