BDD Operations Feature Team Guide

Business Desktop Deployment

On This Page

Using This Guide
Introduction
Planning for Operations Integration
Developing IT Operations Processes and Tools
Developing a Training Program
Stabilizing Operations Activities During the Pilot
Transitioning the Deployment to Operations

Using This Guide

This guide is intended to be used as a part of the Microsoft Business Desktop Deployment (BDD) Solution Accelerator. The focus of the document is to guide a specialist team in preparing to hand off the deployed solution to the in-place IT operations team. Several tasks and checkpoints are recommended in order to ensure that preparations for operation are managed as an important specialist initiative within the larger deployment project. This is done to ensure that the decisions made within this initiative align with the overall project goals and that the deliverables are well integrated into the total migration project.

Setting Up the Team

The specialist team responsible for ensuring the success of this initiative is the operations feature team. A feature team is a cross-organizational team responsible for solving a defined problem. Within the Business Desktop Deployment project, the operations team is one of several feature teams that works with a project management team to accomplish specific project tasks.

Feature teams are an important component of the Microsoft Solutions Framework (MSF) Team Model. The ability to split a large and complex project into smaller sets of related tasks allows work to be performed in parallel on many tasks, with the application of specialized expertise where needed. A great advantage of this approach is an enhanced ability to manage large projects by executing many tasks simultaneously.

For the approach to work, however, it is vitally important that the teams synchronize their efforts and maintain active communication between each other and the project management team. This is particularly important in complex projects, where a feature team may focus on its portion of the project to the exclusion of the role they play in the overall project. Within a Business Desktop Deployment project, the operations feature team must be especially cognizant of the need for synchronization and interaction with the existing IT operations team members; in fact, there may be crossover between the two groups, which helps ensure that the project’s transition from development to production is a smooth one.

Communication

Key to successful project implementation is the team’s ability to cooperate and communicate both internally with its own members and externally with other feature or function teams within the project and project stakeholders.

Within the team, each role is considered to have equal importance, even though the roles may vary. Important team decisions are characterized by joint decision-making.

For communication across teams and between individual feature teams and the project management team (defined as the lead team in this document), the process is more formal, with well-defined pathways. This formality does not prevent informal communication between the teams, which is encouraged, but does ensure that significant communications are well documented, occur at the appropriate level, and are directed to the appropriate team members.

An important consideration for feature teams is communicating with the project stakeholders, which typically includes various entities within the customer organization. To avoid confusion, incomplete or conflicting messages, or misunderstood expectations, it is important that the product manager on the project management team ("lead team") act as the official project voice to the stakeholders. This ensures that management is always aware of the state of the customer relationship and helps to enhance customer satisfaction in the deployment process.

Additional Guidance on MSF and MOF Team Models

For additional guidance on the MSF Team Model, see the MSF Team Model white paper at https://www.microsoft.com/technet/itsolutions/msf/default.mspx. Additional guidance on MOF is available through https://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Introduction

Organizations that consistently do an excellent job of using IT to deliver substantial value are committed to the management of IT functions, just as they manage other strategic business functions or processes. Understanding your company business model is critical for any project that introduces changes to the IT environment. While planning and preparing to incorporate these changes, you must first understand the current status of your organization’s environment, identify other sources of change that may affect this project, perform a risk mitigation approach to the changes, and then incorporate the approved changes. This implies active risk analysis and management throughout the project life cycle and into the production mode.

The goal of this guide is to integrate the activities of the BDD feature teams with the ongoing management and operating functions of the IT operations staff. To do this, the operations feature team must accomplish the following tasks:

• Confirm that the workstation roles identified in the functional specification are still valid.

• Analyze and evaluate the management tools currently in use.

• Assess the current maturity of the operations environment in key operational areas.

• Establish effective management processes and/or tools in deficient key areas.

• Develop a training program for operations and support staff.

• Prepare the operations staff for the pilot.

Background

The tasks described in this guide, although mostly associated with the Deploying Phase of the project, actually extend throughout the project life cycle. The team begins its work during the Planning Phase by performing operational assessments of the current IT environmental status. This information is used during the Development and subsequent phases to guide strategy, create appropriate processes, and train the IT personnel who will ultimately be responsible for operating the BDD solution. The operations feature team performs a considerable amount of its work in the transitional period as the deployment is stabilized prior to, during, and following the pilot, in preparation to deploying the solution organization-wide.

This guide describes several tasks to be completed by the operations feature team. Although this feature team is organized as an MSF feature team, under the MSF Team Model, team members should be familiar with their counterparts within the Microsoft Operations Framework model, typically used to structure operations staff. Similarly, although the activities performed by the operations feature team are considered to be project tasks, it is important to place these tasks within the context of operational practices and processes in order to ease the transition from development to operations.

This guide provides examples of possible risks to the deployment. The examples provided are not meant to be exhaustive but are indicative of similar risks that have been encountered by other project teams while performing similar types of engagements. The intent in including these examples is to help the reader identify risks to the deployment and operation of the solution.

Prerequisites

To help gather the required information for this phase of the project, certain prerequisites must be met or recognized. The operations feature team requires personnel who should be familiar with the concepts of:

• Network operations

• Network infrastructure and support

• Intra-team collaboration

• Security administration

• Workstation imaging and deployments

• Change management

• Configuration management

• Hardware configuration

• Software licensing and asset tracking

The operations feature team will rely heavily on the development teams that created the workstation images, USMT process, application packages, network analysis, application-remediation strategies, and hardware inventories to act as escalation contacts for troubleshooting and resolving problems that may arise in the transition to operations. In particular, they will need the assistance of their team associates in identifying specific training issues and developing the training that must be provided to the operations staff. The team itself may consist of third-party consultants, internal organization staff members acting as consultants to the IT staff, or a blend of the two. Additionally, this guide assumes that a senior level IT or independent agent will act as the role of consultant in this guide.

Planning for Operations Integration

Operations Planning Considerations

In the Planning Phase, the operations team performs several tasks of an analytical nature, designed to gain the information needed to produce a set of effective operations practices for use during the Developing Phase. These tasks include:

• Confirm that the workstation roles identified in the functional specification are still valid.

• Analyze and evaluate the management tools currently in use.

• Assess the current maturity of the operations environment in key operational areas.

Roles and Responsibilities of the Operations Assessment Team

Prior to completing the above tasks, the team should determine the necessary team roles and responsibilities required to accomplish them, as shown in Table 1. One of the first tasks to be accomplished is to assemble a working team to conduct an operations assessment. The members of this group will generally be recruited from the operations feature team, but may also include additional personnel specifically recruited to accomplish the assessment task. For an operations assessment, it is important to assign roles and responsibilities to both the customer’s team and the consulting team, usually by integrating members of both organizations into the feature team. This is necessary to assure appropriate levels of access to the needed information, as well as to ensure that all stakeholders maintain the required degree of commitment.

Table 1 Team Roles and Their Responsibilities During the Planning Phase of the Initiative

Consulting roles	Responsibilities
Lead Assessor	Responsible for assessment completion and customer satisfaction
Assessor	Works with the customer to gather data, deliver assessments
Apprentice	Assists other assessors, may have limited experience
Customer roles	Responsibilities
Project Manager	Coordinates and facilitates the assessment
Representatives	Provides information to the assessor, demonstrates processes, participates in the discussion groups
Executive Sponsor	Primary customer representative, final approving authority

Objectives in Assessing IT Operations

This set of tasks permits business and IT organizations to assess their current IT operations in the context of established industry best practices and to identify the gaps that should be corrected both prior to and following deployment.

When planning the assessment of current operations, team members should be aware that a Microsoft Solutions for Management offering, titled MSM Operations Assessment, is available to assist them. This is a full-scale assessment to determine the status and maturity of all of the service management functions (over 20 in all) defined in Microsoft Operations Framework. Although the MOF Operations Assessment is highly recommended for all IT organizations, it should not be confused with the limited assessment described in this guide, which is a subset of the complete assessment. However, information generated from an MSM Operations Assessment may be used as a substitute for the limited assessment described here.

Confirmation of Workstation Roles

As noted in the Plan, Build, and Deploy Guide, one of the initial tasks completed during the Envisioning Phase and early in the project’s Planning Phase is to identify the workstation roles that exist within the organization. Various roles may include workstations situated in a classroom environment, call center, kiosks, or worker desktops. This information is required by several of the feature teams, including the application compatibility feature team, the imaging feature team, and others.

For the operations feature team, the information is necessary because different workstation roles may require different strategies and processes for IT management. Recognizing these potential variations will aid in selecting appropriate practices for the IT operations staff to employ in managing the various workstations, as well as to guide the development of appropriate training.

The preliminary identification of workstation roles will be described in the functional specification. The feature team leader should assign a team member to review this information and confirm its current validity with the appropriate IT operations team member in the customer organization. In the context of Microsoft Operations Framework, this information should be available from personnel in charge of the configuration service management function and be accessible from the configuration management database (CMDB), if one exists.

Analysis of Management Tools

After determining the number and types of workstation roles in use, the team should conduct an analysis and evaluation of the types of management tools currently in use by the IT management personnel. If the organization has an established configuration management service function, the information will be readily available. If not, the team must determine the appropriate IT managers to contact, conduct interviews with them to document the current tools and associated practices, and compile the results.

Evaluation of the collected information will include, but not necessarily be limited to:

• The specific tools in use that may affect the deployment.

• How their current use may affect the planned deployment process—by introducing conflicts or redundant processes.

• Practices (for example, temporary disabling of a tool, or other tasks) that may be required for successful deployment.

• Ongoing practices that may affect deployment and/or operations of the new desktop.

Assessment of the Current Operations Environment Maturity

The final task in planning is to assess the IT organization’s maturity in several key areas that will have a direct effect on the continued successful operation of the new desktop investment.

As noted above, this solution accelerator is primarily concerned with only those operational areas (service management functions) that are likely to have a direct effect on the deployment or subsequent operation of the desktop. The operations assessment recommended to evaluate organization maturity of these key areas is a subset of the SMFs evaluated in a complete MOF-based Operations Assessment offering. The specific SMFs evaluated include:

• Change Management

• Configuration Management

• Release Management

• Service Continuity Management

• Security Management

• Service Desk

Each of these service management functions covers a variety of the aspects involved in the operation of a complex IT environment. The specific items within each of these service management functions that apply directly to the desktop deployment solution are discussed in greater detail below:

Change Management

Change management focuses on a variety of change-related issues during the pilot and following the deployment. The organizational changes subject to the change management process include hardware, software, system components, documents, and processes—anything deliberately introduced into the IT environment that could affect its functioning as reflected in the service level agreements (SLAs) existing between the IT department and the business it serves. (Changes to operational roles and responsibilities of IT personnel are not included in this management process.) Your evaluation of organizational maturity should include the following six activities.

• Change request. The formal initiation of a change through the submission of a request for change (RFC).

• Change classification. The assignment of a priority and a category to the change, using its urgency and its impact on the infrastructure or users as criteria. This assignment affects the implementation speed and route.

• Change authorization. The consideration and approval or disapproval of the change by the change manager and the change advisory board (CAB), a board containing IT and business representatives.

• Change development. The planning and development of the change, a process that can vary immensely in scope and includes reviews at key interim milestones.

• Change release. The release and deployment of the change into the production environment.

• Change review. A post-implementation process that reviews whether the change has achieved the goals established for it and determines whether to keep the change in effect or back it out.

At a minimum, determine and document the change management policies regarding the how, when, and who elements of the patch management process. Some items to consider are:

• Are changes managed (identified, tested, and deployed)?

• Do users or the operations staff perform the changes?

• What tools are utilized? Are they automated? In what way?

Configuration Management

The goal of configuration management is to ensure that only authorized components—including hardware, software, and even important settings—are used in the IT environment and that all changes to them are recorded and tracked throughout their life cycle. It is important to document the settings themselves and group them into workgroup, workstation, and user categories. Configuration management offers a standardized process to accomplish this task.

For the purposes of a desktop deployment project, the configuration service management function focuses most closely on user and workstation settings since the desktop hardware and software images are well defined as part of the project development. This service management function is closely related to the work performed by the user state migration feature team. In order to maintain the controlled environment established with the new rollout, it is important to have configuration management processes established.

A few of the configuration considerations with which the team must be concerned include the following:

Evaluating the Company Operating Scope

Organizations may operate over a broad range of geographic distribution models. Configuration management must account for both current needs and potential future expansion. Interconnectivity between regions and workgroups (the network architecture) also falls within the purview of operating scope. Most organization’s network architectures can be categorized into one of several operational models: from the single company model, incorporating a physically consolidated and well-connected infrastructure, up to an international model relying on physically disparate network resources that may have intermittent or varying degrees of connectivity.

Evaluating the Operations Environment

The operations environment typically mirrors the company operating scope. There are exceptions: for instance, an international company that relies completely on a single operations group located at the company’s headquarters, or a national company that outsources IT operations for remote locations. The company operations environment contains two elements for consideration:

Evaluating the Physical Environment:

The locations in which the operations group performs tasks and the interconnectivity used to access the infrastructure. These locations include the use of mobile devices.

Evaluating the Administrative Environment:

The IT administration model defines whether IT management occurs from a centralized location, multiple decentralized locales, or a hybrid of the two. The administrative environment is also the domain of the tools used to manage and administer the operations.

Evaluating Key Company Processes

This assessment task determines how a company collects, manages, and communicates information both internally and externally. The key processes may be categorized into four classes:

• Information flow

• Communications flow

• Service and product life cycle

• Decision making

Evaluating User Needs

User needs and requirements form a symbiotic relationship with key company processes and resource management. When determining current user needs, data from feature team groups may be utilized, in addition to information obtained from assessment team members and use cases. User types, such as roaming, mobile, remote, task-based, or knowledge-based, must be identified and related to other aspects of the environment. For instance, when determining the needs of a roaming user type, it will be necessary to document current access to resources. A mobile user may have multiple security and infrastructure configurations that must be accommodated. Some examples of cross-team collaborations that may occur when determining user needs are:

• The application compatibility feature team can provide data concerning current desktop applications and usage.

• The infrastructure compatibility feature team may have data concerning resource management pertaining to network access.

• The user state migration feature team can provide specific information about standard desktop configurations that may exist and about unique user configurations in particular.

Release Management

The Release Management SMF defines processes for deploying changes into an IT environment. Once one or more changes are developed, tested, and packaged into a release for deployment, release management is responsible for introducing these changes and managing their release into the IT environment. Release management also contributes to the efficient introduction of change by combining changes into one release and jointly deploying them. These activities are similar to those performed by the application compatibility and imaging feature teams but are performed in the production environment after appropriate testing in a test environment.

The goal of release management is to ensure that all changes are deployed successfully into the production IT environment in the least disruptive manner possible. An IT organization may employ various processes to do this, using a variety of different tools. An evaluation of the organization’s maturity in this service management function will include the following:

Evaluating Management and Release Policies.

The team should discover and document image creation and management, including:

• Definitive Software Library (DSL) location (hardware, connectivity).

• Image formats and usage (RIS-based, file-based).

• Identify management policies regarding the image approval, testing, and deployment procedures.

• Release acceptance criteria.

Evaluating Software Update Mechanisms

Many of the considerations regarding release management may be applied to the services IT uses to facilitate or automate software updates. The questions are still how, when, and who, plus some additional items to consider:

• Identify the processes (if any) by which updates are identified, tested, and deployed.

• Determine if different configurations or workgroups affect software updates and patches. Many times software applications are unique to an organizational unit or team within a company. Software update and configuration management may take place at the group level.

Service Continuity Management

Service continuity management encompasses the service management processes that ensure that any given IT service will continue to provide some level of value to the customer in the event that normal availability solutions fail. At a minimum, the data management policies and procedures for the workstations and users should be documented. Some elements to be considered include:

• Data access: How do users access data? This may be related to user type and network interconnectivity.

• Data availability: How is data synchronized and made available to users? Are there centralized storage locations such as shared file servers or source safe application servers?

• Data protection: Are there current policies in place regarding company data? Are centralized storage locations backed up? How often and at what level? How are data backups and recoveries performed?

Security Management

Security management is a function that describes the processes required to maintain a safe computing environment. Security is a critical part of company infrastructure, preventing malicious or accidental activities from causing data loss, unauthorized access to critical data, or other potentially harmful results. Security processes are categorized into six fundamental precepts:

• Identification. Deals with user names and how users identify themselves to the system.

• Authentication. Deals with passwords, smart cards, biometrics, and so on. Authentication is how users prove to the system that they are who they claim to be.

• Access control. (Also called authorization). Deals with access and the privileges granted to users so that they may perform certain functions on the system.

• Confidentiality. Deals with encryption. Confidentiality mechanisms ensure that only authorized people can see data stored on or traveling across the network.

• Integrity. Deals with checksums and digital signatures. Integrity mechanisms ensure that data is not garbled, lost, or changed when traveling across the network.

• Nonrepudiation. This is a means of providing proof of data transmission or receipt so that the occurrence of a transaction cannot later be denied.

During the security assessment, key areas to consider are:

Desktop security is a multifarious topic that should encompass every aspect of the desktop assessment. The security feature team may provide data concerning current desktop security. Security management is typically articulated as a fundamental strategy embedded in key company processes.

Antivirus solutions is also a diverse topic that typically involves several facets of the desktop assessment. Antivirus software is commonly managed by a security group within the organization. Depending on the IT administration model, it is conceivable that the group responsible for software update services may have this responsibility. Protection for e-mail, Web browsing, downloads, and software installations are some of the solutions that need to be identified. Collaboration with other feature teams, such as the security feature team and the infrastructure compatibility feature team, will be essential when gathering this information. When documenting the company’s antivirus solution, several items should be considered:

• The network level at which the antivirus protection is installed, such as firewall, server, or client. Simply put, where are the antivirus product(s) installed?

• The vendor(s) and product(s) utilized, including version numbers and licensing models.

• The degree of management to which the antivirus solution is subjected. This would include configuration management and release management as it affects update policies.

Service Desk

The level and type of support that users and key company processes rely on are an important aspect of the operations assessment. The focus for service desk operations is on incident and problem management in order to solve user's issues as quickly as possible. While documenting the service desk environment, it is essential to not only examine the IT functions but also the user expectations. It is important to document the standard operating procedures of the service desk and the operating procedures they actually provide. Use case studies and trouble call scenarios may be utilized for these purposes. Additionally, the skill and knowledge levels of the operations staff must be assessed.

Conducting the Assessment

A fully implemented operations assessment completed under MOF guidance is organized and executed through a five-step process that aligns with the five phases of the MSF Process Model. For detailed guidance on conducting an assessment of this scope, you should refer to the MOF Operations Assessment service offering.

In the limited engagement assessment conducted as part of the Business Desktop Deployment Solution Accelerator, many of the preliminary steps completed in the full operations assessment will have already been completed as part of the project kickoff and planning process. Many of those steps have been described in the previous section, included in the descriptions of the SMFs to be assessed. Other portions of the full assessment may not be required. A complete listing of the steps recommended to conduct an abbreviated assessment within the context of a deployment project is presented in the following table. In the MSF Envisioning and Planning phases, the team lays the groundwork for conducting the assessment, which is completed as a series of tasks in the Developing Phase.

Table 2 Phases and Tasks for Conducting an Abbreviated Operations Assessment

Phase	Task
Envisioning	Select team leader Contribute to vision/scope document
Planning	Confirm status and requirements for workstation roles Conduct preliminary survey of existing processes Identify key IT organization interviewees Create assessment plan Develop interview schedule
Developing: [Compiling data]	Conduct interviews Document information Organize and compile interview data
Developing: [Analyzing data]	Review information Derive maturity ratings for SMFs Identify gaps and needed improvements for each workstation role
Developing: [Building action plan]	Prioritize improvements with stakeholders Identify tasks to implement improvements Produce final report Present results

Most of the activities listed for the Envisioning Phase will have been completed prior to the creation of an operations feature team. The Planning Phase will first require a preliminary survey of existing operations practices, to the extent necessary to allow the team to identify those personnel who are best placed to provide the information needed to successfully complete the assessment. These individuals are then asked to participate in the interview process, using a formalized process that will aid in determining the organization’s maturity level in planning, organizing, and executing specific IT processes.

A full MOF Operations Assessment for an organization equivalent to the Contoso example (5,000 workstations) typically requires approximately six weeks to complete, with a team of two assessors. The assessment described in this guide, focusing on IT operations specifically related to the desktop deployment, requires the participation of fewer IT staff and a shorter time period. For a suite of suggested survey questions, please refer to the “Focused Operations Assessment for Business Desktop Deployment” document.

After conducting the interviews, the assessment team will review and compile the acquired data and calculate the overall maturity levels for each of the target IT processes. This will then be used to conduct a gap analysis, which identifies the deficient areas in the organization’s processes, as well as those areas that are working well or may serve as best practices.

Finally, the assessment team works with customer representatives and other appropriate members of the desktop deployment team to determine the priorities for addressing the gaps identified in the survey, devise a plan to address them, and report the findings. The following section provides details for specific IT operations processes that should be in place in order to successfully complete the deployment project and maintain the newly deployed desktop environment(s) into the future.

Developing IT Operations Processes and Tools

Considerations for the Developing Phase

During the Developing Phase, the feature team uses the data gathered and analyzed during planning to establish a viable set of operational processes, applicable to the BDD project, and creates a training program to facilitate their adoption by the operations staff. The roles and responsibilities listed below are those of the MOF Team Model. For detailed information on the MOF Team Model, refer to the team model white paper available at
https://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Roles and Responsibilities

During the developing phase, the team members are primarily concerned with using the operations assessment data to choose appropriate operational practices to implement and with building a training program to enable production staff to implement them.

Table 3 Roles and Responsibilities During the Developing Phase

Role cluster	Involvement in evaluating operations process activities
Infrastructure	Provides technical expertise, including advice and guidance on how to identify and manage the relationship between CIs
Operations	Provides input into operational CIs
Partner	Provides partner/third-party input, particularly in cases where the partner manages this CI
Release	Manages and owns the identification of CI process. Co-ordinates with the deployment feature team to ensure that co-dependencies between new processes and tools and deployment plans are accommodated.
Security	Provides input into security CIs and security issues with this activity
Support	Provides input into support CIs. Also provides direct support for this activity.

Implementing Key Service Management Functions

Investigation and analysis of the current state of the IT organization are the key tasks performed by the operations feature team during the Planning Phase of the Business Desktop Deployment project. As the project moves into the Developing Phase, the team coordinates with the customer stakeholders to determine the priority in mitigating any operational deficiencies found prior to the pilot and subsequent deployment.

As discussed in the introduction, more than 20 SMFs have been identified in MOF that address key aspects of operating and managing an IT environment. Although MOF recommendations prescribe that all of these SMFs should be implemented, this may not be possible in the short term to meet the operational objectives of a deployment project. This section provides guidance on the most significant operational processes that should either be in place or implemented.

The critical SMFs in deploying and maintaining the post-deployment health of the deployed environment were discussed in the section, “Objectives in Assessing IT Operations.” Each of these SMFs was described in detail. The SMFs included:

• Change Management

• Configuration Management

• Release Management

• Service Continuity Management

• Security Administration

• Service Desk

Note that these processes should be in place for each of the workstation roles identified in prior investigation. Particularly in organizations with distributed IT operations, it is critical that all workstation roles be managed in a consistent manner. Those involved in the assessment activities conducted in the previous phase should also be familiar with these processes in order to direct their investigations appropriately.

Change Management

During the pilot and following deployment, the customer IT organization should implement several key change management processes. Change management enables the IT managers to control the stability of the IT environment, preventing the introduction of unauthorized or ill-conceived changes that may have deleterious effects on the environment. For additional information, review the MOF Change Management SMF. The recommended change management processes include:

• Change request procedures. Each change request should follow a standard format, which must be defined and implemented.

• Change classification. Requested changes will be categorized on the basis of the urgency of their implementation and their effect on the infrastructure. This classification will affect the timing for the implementation and the strategy for implementing it.

• Change authorization. Requested changes will be reviewed and authorized or denied by a change manager and/or change review board (CAB). The CAB is a board comprising IT and business representatives, appointed by the IT management.

• Change development. The change and its deployment strategy will be planned and developed with reviews at key interim milestones.

• Change release. The release and deployment of the change into the production environment will be defined.

• Change review. A post-implementation process review will be conducted to determine whether the change has achieved the goals that were established for it. At this review, a decision will be made to either keep the change in effect or back it out.

Configuration Management

Configuration management, in general terms, is a set of processes intended to identify and track each of the component parts of an IT infrastructure and its relationship with the other parts of the infrastructure. This includes hardware, operating systems, applications software, and other related components.

The configuration management processes that are recommended for implementation include:

• Establishing configuration items (CIs)

• Assessing CIs

• Changing CIs

• Reviewing CIs

Each of these processes is described below. For more detailed discussion of the configuration management service function, refer to the MOF Configuration Management SMF.

Establishing Configuration Items

Document the identity of each of the workstations to be affected by the pilot and the desktop deployment. Workstations are defined as the combination of any desktop computer—with its operating system and applications—that is connected to and uses the network. The proper understanding and documentation of relationships between IT components make it possible to perform detailed impact analysis on a proposed change.

Accessing Configuration Items

After the CI data for each of the workstation is collected, it is entered into a tracking system, typically a database referred to as the configuration management database (CMDB). The CMDB enables other SMFs to access the data they require in order to implement their functions. For example, change management uses the relationships defined within the CMDB to determine the impact of a change on other components within the IT environment. Problem management uses the CMDB as a resource to identify which CIs are the root cause of incidents, and so on.

Changing Configuration Items

As release management begins to make changes to IT components, corresponding updates must be made to the CMDB because without accurate and up-to-date information, the value of configuration management is lost. This process should be done automatically, wherever possible. The amount of information and the frequency of change make manual data entry impractical for all but the smallest organizations.

Reviewing Configuration Items

The accuracy of the information stored in the CMDB is crucial to the success of change management and other service management functions. A review process that ensures that the database accurately reflects the production IT environment should be established.

Release Management

Release management encompasses the decision making, planning, testing, and eventual roll out of a change. In the case of the Business Desktop Deployment Solution Accelerator, release management constitutes the primary interface between the existing IT operations organization and the desktop deployment project team. In reality, the deployment feature team is actually an extension of the IT release management function into the development process.

Subsequent to the approval of a change in the change management service function by the change advisory board (CAB), the release transitions through several steps as it moves toward and through rollout. Those steps include:

• Release planning

• Release building

• Acceptance testing

• Release readiness review

• Rollout planning

• Rollout preparation

• Rollout

• Rollout complete

A summary of how each of these steps applies in the case of a desktop deployment is provided below. For a detailed discussion of the release management process function, please refer to the MOF Release Management SMF.

Release Planning

During release planning, an assigned release manager determines what changes must be made to the production environment in order to implement the Business Desktop Deployment project. Having established what needs to be done, the release manager can then decide how those changes should be released into the production environment. Once the contents of a release have been defined, the release manager can formulate and build a release plan that lists the tasks and activities required to deploy into the production environment.

Release Building

During this activity, members of the release team begin to develop the processes, tools, and technologies required to deploy the release into the production environment. Collaboration between all of the BDD feature teams will be essential in this process.

Acceptance Testing

Testing of the planned release ensures that releases will not adversely impact the production environment. Although testing in a simulated production environment provides the release team with some confidence in the release, it does not guarantee that the release will perform well in production, where conditions may be significantly different. In some cases, it may be necessary to conduct a number of controlled tests in production to confirm that the release meets expectations.

Release Readiness Review

The release readiness review is the final management checkpoint and approval step before the release team begins detailed rollout planning and preparations. The release readiness review ensures the readiness of the release for deployment and produces a go/no go decision about whether to deploy the release. The review considers the operability and supportability of the release itself, as well as the readiness of the target production environment to support and operate the deployed release. If the decision is a go, the release moves to rollout planning and preparations; otherwise, the deployment is postponed until the necessary improvements take place, or it is canceled.

Rollout Planning

Rollout planning is where the strategy for the rollout itself is created. This step includes a review of the rollout by the release manager. The release manager needs to review the rollout order to determine whether it is still aligned with business requirements and priorities. If there is a pressing need for the release in finance, for example, it may be preferable to change the rollout order so that the release is deployed to the finance department before sales and marketing. Having confirmed the rollout order, the task of building detailed rollout plans to deploy the release into production can begin.

Rollout Preparation

Prior to the actual rollout, preparations must be made in the production (or pilot) environment to accept the deployment. The tasks and activities required to achieve this often include communicating information about the release to users and other personnel, training service desk and technical support staff, and making backups of critical IT components.

Rollout

Rollout is the actual process of moving the BDD into the production environment and depends on the type and nature of the release and on the selected release mechanism. In all cases, however, the release manager should be provided with status reports and, where appropriate, tools and technologies that will enable him or her to track and monitor the progress of deployment. As changes are made to IT components during deployment, corresponding changes must be made to the configuration items and relationships that model them in the configuration management database (CMDB). If the release fails to meet expectations or if serious problems are encountered during deployment, problem management may be needed to identify and diagnose the root cause of the problem. If a suitable fix or workaround can be found, this should be documented and a request for change (RFC) created to deploy it into the production environment. If not, it may be appropriate to use the rollback procedures to remove the release from that environment.

Service Continuity Management

The service continuity management function is concerned with managing risks to ensure that an organization’s IT infrastructure can continue to provide services in the event of an unlikely or unanticipated event. This is accomplished through a process that analyzes business processes, their impact on the organization, and the IT infrastructure vulnerabilities that these processes face from a myriad of possible risks. Each phase has tasks and deliverables associated with it that assist in determining cost-effective solutions. The deliverables need to be maintained as active documents and updated as needed. In the context of the Business Desktop Deployment project, the focus of this service function will be to ensure service if the deployment fails in some way, thereby allowing the IT environment to recover to a stable, usable state. The process comprises four main processes and several subprocesses as follows:

• Acquiring service level requirements.

• Proposing contingent solution.

• Formalizing operating level agreements.

• Formalizing contingency plan.

Although the extent of a full implementation of the service continuity service management function is beyond the scope of a Business Desktop Deployment project, there is considerable similarity in the tasks that must be accomplished.

Acquiring Service Level Requirements

Service continuity management starts by carefully agreeing to availability targets with the customer and determining the cost of downtime or unavailability of the IT service in question so that a realistic IT budget can be established. It is also important that the negotiation includes realistic expectations of reduced system availability while the contingency plan is in place. In the case of the Business Desktop Deployment project, this negotiation is confined to service availability only during the duration of the deployment itself. For a full-scale MOF implementation of the service function, this negotiation would cover 24x7 operations for the length of a long-term agreement.

This process involves an element of education and negotiation on both sides (the customer and the IT organization). The customer needs to understand how to define and articulate its availability requirements. The IT organization needs to understand the functions that make up the overall IT service and which functions are the most critical.

Proposing Contingent Solution

Service continuity management ensures that the service is available in the event of a service disruption, regardless of the cause of the disruption (disaster, component failure, virus attack, and so on). During desktop deployment, the deployment team must develop strategies for maintaining service in the event of a failure due to the deployment itself. Service continuance typically involves two separate but equal functions:

• Failover

• Restoration

Formalizing Operating Level Agreements

When IT and the customer agree on a cost-effective contingency solution, the agreement needs to be formalized in a document called an operating level agreement (OLA). The OLA serves as one of the building blocks for the service level agreement (SLA) between IT and the customer. The service level agreement is a formal, legal document between IT and its customer. For a singular, limited-duration event, such as the desktop deployment project, the stakeholders must consider the level of formality required to guarantee appropriate levels of service availability.

Formalizing the Contingency Plan

The contingency plan should be a prescriptive guide that can be used by IT personnel to failover and recover the service in the event of a significant event. This document needs to include information on escalation and notification procedures, startup and shutdown procedures, communication methods, and status reporting requirements.

Security Management

Security management functions can affect an entire information system, including interactions with many of the other service management functions. In fact, security management acts as an “umbrella” process in the Operating Quadrant of the MOF Process Model. Every other process must conform to the guidelines set forth by security management. The main processes encompassed by the Security Management SMF are as follows:

• Identification

• Authentication

• Access control

• Confidentiality

• Public key encryption and PKI

• Virtual private networks

• Integrity

• Nonrepudiation

• Auditing

Since security is embedded at the core of most IT operations, the Business Desktop Deployment Solution Accelerator has incorporated a feature team that is focused on the security issues of planning, developing, and deploying the solution. See the Security Feature Team Guide for additional details on implementing security service management functions.

Service Desk

Service desk operating processes are extremely important, particularly after the migration to an updated IT environment that includes new hardware, operating system, and productivity applications. Most IT operations organizations maintain some form of service desk service function, which can form the basis for service management of the new desktop.

A complete description of the service desk function is provided in the MOF Service Desk Service Management Function document, however, some of the key objectives that should be accomplished in preparing the service desk to handle desktop service requests include:

• Supporting the upgraded environment across business, technology, and process boundaries.

• Providing a single and central point of contact between users and the IT department.

• Providing an interface for users to other service management functions, such as change management, problem management, configuration management, release management, and so on.

• Identifying additional business opportunities for the desktop deployment project.

Developing a Training Program

To ensure a smooth transition from a successful deployment to an efficient operations environment, the desktop deployment team should develop a training program for IT operations staff. MSF, through its Readiness Management Discipline, defines a rigorous readiness management process to help organizations prepare for change. By applying appropriate components of this process, the deployment feature team can build a targeted training program to meet the requirements of the overall project scope.

Through MSF, the process to manage readiness for change comprises four steps: Define, Assess, Change, and Evaluate. Each of these is described below:

Define

Key to a successful training program is a clear and concise definition of the specific items that must be taught. For some projects, this may require considerable research. For the desktop deployment project, the key IT operations items are relatively well defined: they are the limited set of SMFs that are described in the previous sections. The IT organization personnel who will manage the deployed desktop must be familiarized with the SMFs that will allow them to make necessary changes, ensure availability and security, provide support, and execute the other functions required to maintain organizational productivity. For each of the service functions described, the feature team must list in detail each of the specific processes, procedures, and tasks that must be accomplished. The published SMFs will provide specific references in this task.

Also included in the definition process is an analysis of the required levels of proficiency for each of the learning units. For example, for a service desk technician, there may be little need for an expert knowledge of system architecture. Proper determination of the depth of knowledge required will be crucial in scoping and developing the training program.

Assess

Having defined the training requirements, the team must then assess the current state of readiness in the host IT organization. An organization with well-established IT management processes may require very little training to bring its members to the desired levels of proficiency. Conversely, an organization with few standardized processes may require a focused effort to bring its members to the desired level.

Assessment activities may take a variety of forms. Typically, the team will use some combination of surveys and interviews to obtain the required information. This effort is most efficiently done during the operations assessment, described in the “Planning for Operations Integration” section. It is relatively straightforward to assess not only which service management functions the organization has implemented, but also their proficiency in executing them.

Change

This step of the readiness process includes development and presentation of the training program. The training team evaluates the results of the assessment program and performs a gap analysis to determine where gaps in knowledge, skills, and proficiency exist, prioritizes them, and selects appropriate training or other approaches (such as outsourcing) to address them. During this process, the team will also establish a method to track the progress of the training program. This is of particular importance in cases where it may be impractical to provide centralized training to the required IT staff because the deployment is occurring in diverse geographic areas or to diverse user workgroups.

This learning program may be developed entirely by the feature team, but it is more practical to make use of existing Microsoft courseware, including the MOF Essentials and MOF Changing Quadrant courses, as well as related courses. In addition to these courses, the training team may also develop shorter workshops or presentations to address specific organizational needs or issues. The contents of the official MOF curricula may be reviewed at the following links:

• MOF Essentials course: https://www.microsoft.com/learning/

• MOF Changing Quadrant course: https://www.microsoft.com/learning/

Evaluate

After implementing the training program, the training team will evaluate the program’s efficacy. This evaluation will typically take the form of a readiness review.

Readiness Review

This evaluation step could be the end of the readiness management process. But since learning is an ongoing need for continued success, evaluation is typically viewed as the beginning to an iterative process. Some of the elements of the readiness review are:

• Review Results: A real-world test of training’s success is the effectiveness of the individual back on the job. One of the activities during the change step is identifying the most effective approach to the transfer of knowledge. A suggested approach is to follow traditional training delivery, such as instructor-led and self-study, with on-the-job mentoring or coaching. The individuals’ activities in this phase may include some introspection and self-assessment to determine whether the learning was effective before putting those new competencies to work. Individuals may also decide it is a good time to become certified because they have done the learning, performed the key tasks, and assimilated the knowledge.

• Manage Knowledge: A natural side-effect of training individuals is that the knowledge they acquire becomes intellectual capital that the individual can then pass on throughout the organization. As learning plans are completed and applied on the job, individuals utilize key learning that their training provided. Sharing this information with others throughout the organization enhances the collective knowledge and fosters a learning community. One objective of the Readiness Management Discipline is to encourage development of a knowledge management system to better enable the sharing and transfer of proven practices and lessons learned, as well as to create a skills baseline of the knowledge contained within the organization.

Milestone: Operations Processes and Skills Upgrade Scope Complete

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide for the Microsoft Business Desktop Deployment Solution Accelerator.

Deliverables

Deliverable ID	Description
Operations Processes	Operations processes are updated, supported by the relevant tools and integrated into the operations management architecture and operations environment
Trained Operations Personnel	Operations personnel has been trained to sufficient level that they can support and manage the new desktop environment

Stabilizing Operations Activities During the Pilot

Considerations for the Stabilizing Phase

During the Stabilizing Phase, the operations team implements the training program developed previously and then takes the lead in implementing related operational tasks associated with deploying the pilot. At the end of the Stabilizing Phase, the operations team conducts a deployment readiness review, which is the last opportunity for a go/no go decision to deploy the solution across the organization.

Roles and Responsibilities

During the Stabilizing Phase, the team is focused on deploying the pilot and training the operations staff. The specific responsibilities for each team role are described in Table 4.

Table 4 Roles and Responsibilities During the Stabilizing Phase

Roles	Responsibilities
Release Manager	Manages the overall release process Develops detailed release plans Coordinates all project teams associated with the release Acts as a liaison to appropriate management Manages the evaluation process upon completion of the project Forms a release team to manage the many required activities (selects team members and assigns team roles and responsibilities) Facilitate team communication to ensure that releases are implemented according to schedule
Change Owner	Manages the planning and coordination of the pilot staging and organization-wide implementations Develops implementation plans and determines site locations for pilot rollouts Establishes implementation schedules Identifies and communicates problems and schedule changes based on feedback from release team coordinators Ensures that the rollout team is properly trained Validates rollout and backout plans during release testing
Training Coordinator	Identifies user competency to use the release Performs gap analysis against target competencies and skill requirements Identifies individuals to be trained to meet goals and objectives of the release Selects training methodologies best-suited for content and audience Designs, builds, and implements the training strategy Communicates training plan to audience Manages and coordinates daily training activities Collects and analyzes feedback from trainees for effectiveness of training methodology and content
Communications Coordinator	Develops and manages the communications plan Develops content based on input from all project members Finalizes and distributes content Determines the channels of information dissemination Develops feedback mechanisms and a collection database for user comments Ensures issue resolution is communicated in a timely and effective manner Evaluates and updates the communications plan to maintain its effectiveness throughout the release process Communicates release goals and scope to users Communicates release status, progress, and issues to appropriate groups
Documentation Coordinator	Assesses current user guides, administrator guides, and reference manuals Defines purpose and use of required documentation Identifies required documentation from developers and users Identifies documentation options and formats that meet the users’ needs Designs, develops, and proofs documentation Tests and validates documentation with users Manages the modification of existing documentation to support the release Disseminates documentation to appropriate personnel
Testing Coordinator	Designs, builds, and maintains the test environment Prepares tests and procedures and executes testing strategies Identifies testers and assigns testing responsibilities Develops and manages testing schedule Documents test procedures and problems Manages problem resolution and re-testing Gathers, documents, and analyzes test results Communicates results and provide recommendations to appropriate parties Validates readiness of release package to be integrated into the production environment

Integrating the Operations Team During Pilot

As part of the release management process, the deployment feature team will work in conjunction with key stakeholders and business partners within the IT operations group to create a test plan that enables these business partners to develop confidence in the release and its ability to perform in a production environment. During the pilot, the deployment team will perform these tests jointly with members of the IT operations team, who should be actively involved with the release and long-term support of the release.

Once the release is deployed in the pilot environment, users and administrative staff can monitor and evaluate performance based on real-world conditions. If this process leads to the conclusion that the release does not meet expectations, it should be backed out. The operations team will provide feedback directly to the release team regarding the successes or failures encountered during the pilot of a release. All test results will be documented and verified against the expected results. Testing failures should be investigated and evaluated to determine if the failure is acceptable or if components in the release need to be reworked. The pilot is also helpful in determining the level of operational support that will be needed after full implementation.

After the pilot is complete, the next step is to evaluate the test results and determine the action to be taken: move forward with the release or return to the change owner or release manager for additional work. The release manager, the change manager, and the change owner are the primary participants in this discussion, but it may also involve representatives from the operational support teams. If there were issues identified during the testing that affect the user community or service levels, it is necessary to discuss workarounds and expected problems with the service desk representatives and to ensure the workarounds will be available to the service desk prior to deployment.

Deployment Readiness Review

The deployment readiness review is the final operations management checkpoint and approval step before rollout. It should not be confused with the readiness review described in the training section, which is more limited in scope and is intended only to gauge the proficiency levels of the operations staff who will maintain the solution.

The release readiness review ensures the readiness of the release for deployment and includes the operability and supportability of the release itself, as well as the readiness of the target production environment to support and operate the deployed release. This release readiness review produces a go/no go decision about whether to deploy the release. Delegates from each of the feature teams, the management team, and key stakeholder groups should participate in the review. Details of the release readiness review are provided in the core MOF documentation, available at https://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Transitioning the Deployment to Operations

Considerations in Transitioning

The operations feature team will rely heavily on the development teams that created the workstation images, USMT process, application packages, network analysis, application-remediation strategies, and hardware inventories to act as escalation contacts for troubleshooting and resolving problems that arise during the deployment. Furthermore, the project operations feature team will be largely responsible for managing and confirming the successful transition of the project to the IT operations team.

Roles and Responsibilities

The following table illustrates the roles and responsibilities of the operations feature team, its counterpart in an IT operations organization, and the responsibilities that must be handed off.

Table 5 Role and Responsibility Map Between Project and Production Roles

Deployment role	Primary information flow	Operations role	Information transfer
Release Management	<-->	Release	Primary transfer point of information, as this is the same role cluster that was involved during the deployment of the desktops
	->	Infrastructure	Handover of architectures and designs for labs and staging areas
	->	Operations	Provides role and account information to the operations role in order to ensure that accounts and permissions have been set up
	<-		Provides feedback to deployment team with respect to the deployment load on operational resources such as the network in order to balance deployment and operations
	->	Partner	Provides standard images for use by hardware vendors in order to ensure that new machines are delivered in an acceptable preconfigured state
	->	Security	Handover of standardized security information files used to harden the desktops
Development	->	Infrastructure	Provides decision criteria for trade-off decisions with respect to infrastructure
	<-	Support	Receives feedback from operational support on issues that should be resolved by development team
	->	Infrastructure	Handover of standard images, interview information files, and USMT information files
	->	Security	Handover of standardized security information files used to harden the desktops
Test	->	Support	Provides a list of known issues and quick fixes to the support role
User Experience	->	Infrastructure	Handoff of policies and procedures identified and/or developed during the course of the deployment project
	->	Support	Handoff of design documentation to the support team to ensure that information is available to support team
	->	Operations	Handoff of operations policies and procedures identified and/or developed during the course of the deployment project