Planning

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

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

• Analyzing and evaluating the management tools currently in use.

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

On This Page

Roles and Responsibilities
Assessing IT Operations
Conducting the Assessment
Milestone: Operational Assessment Complete

Roles and Responsibilities

Before completing the above tasks, the team should determine the necessary team roles and responsibilities required to accomplish them, as Table 1 shows. One of the first tasks is to assemble a working team to conduct an operations assessment. The members of this group will generally be recruited from the Operations Readiness 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 operational and the project team, usually by integrating members of both teams into the feature team. If possible, replace members of the operational team with temporary staff members to let in-house staff members play an active part in the project itself. This type of training is often the best type they can get.

This step is necessary to ensure that team members have appropriate levels of access to the needed information and that all stakeholders maintain the required degree of commitment.

Table 1. Roles and Responsibilities During the Planning Phase

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 before and after deployment.

Note   When planning the assessment of current operations, team members should be aware that a Microsoft Solutions for Management (MSM) offering, called MOF Operations Assessment, is available to assist them (see “Microsoft Operations Framework Self-Assessment Tool 2.0” at https://www.microsoft.com/technet/itsolutions/cits/mo/mof/moftool.mspx). This full-scale assessment determines the status and maturity of more than 20 service management functions (SMFs) defined in the MOF. 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. However, information that a MOF Operations Assessment generates 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 computers situated in classroom environments, call centers, kiosks, or worker desktops. Several of the feature teams require this information, including the Application Compatibility feature team and the Computer Imaging System feature team.

For the Operations Readiness 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 computers 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 MOF, this information should be available from personnel in charge of the Configuration Management SMF 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 SMF, 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 will not necessarily be limited to:

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

• How the tools’ current use may affect the planned deployment process (for example, by introducing conflicts or redundant processes).

• Practices that may be required for a successful deployment.

• Ongoing practices that may affect deployment and operation of the new client computer.

Assessment of IT Operation’s Maturity

The final planning task 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 client computer investment.

As noted earlier, BDD 2007 is primarily concerned with only those operational areas that are likely to have a direct effect on the deployment or subsequent operation of client computers. The operations assessment recommended to evaluate organizational maturity of these key areas is a subset of the SMFs evaluated in a complete MOF Operations Assessment offering. The specific SMFs evaluated include:

• Change Management.

• Configuration Management.

• Release Management.

• Service Continuity Management.

• Security Management.

• Service Desk.

Each SMF covers a variety of the aspects involved in the operation of a complex IT environment. The specific items within each SMF that apply directly to the desktop deployment solution are discussed in greater detail later.

Change Management

The Change Management SMF 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.) The team’s evaluation of organizational maturity should include the following 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 effect 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.

  At a minimum, determine and document the change management policies regarding the how, when, and who elements of the deployment and software update processes. Some items to consider include:

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

  • Do users or the IT Operations staff perform the changes?

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

Configuration Management

The goal of the Configuration Management SMF 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 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, this SMF focuses most closely on user and workstation settings, because the desktop hardware and software images are well defined as part of the project development. This SMF is closely related to the work the User State Migration feature team performs. To maintain the controlled environment established with the new rollout, establishing configuration management processes is important.

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 organizations’ network architectures can be categorized into one of several operational models: from the single company model, incorporating a physically consolidated and well-connected infrastructure, 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 organization 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 considerations:

  • Evaluating the physical environment. The physical environment denotes 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 locations, 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 fall into five classes:

  • Information flow

  • Communications flow

  • Service and product life cycle

  • Decision-making

  • Evaluation of 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 used in addition to information obtained from assessment team members and user 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 example, 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. Here are some examples of cross-team collaborations that may occur when determining user needs:

• The Application Compatibility feature team can provide data concerning current desktop applications and usage.

• The Infrastructure Remediation 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.

Release Management

The Release Management SMF defines processes for deploying changes into an IT environment. After 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 the Application Compatibility and Computer Imaging System feature teams perform 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 SMF 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 and connectivity).

  • Image formats and use (Microsoft Windows Deployment Services [Windows DS] or file based).

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

  • Release acceptance criteria.

• Evaluating software deployment mechanisms. Many of the considerations regarding release management may be applied to the services IT uses to facilitate or automate software deployments. This should be done in conjunction with the evaluation of software update mechanisms. The questions are still how, when, and who, but team members must consider these additional items:

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

  • Determining whether different configurations or workgroups affect software deployments, updates, and patches. Often, software applications are unique to an organizational unit (OU) or team within a company. Software deployment, update, and configuration management may take place at the group level.

Service Continuity Management

The Service Continuity Management SMF encompasses the processes that ensure that any given IT service will continue to provide some level of value to the customer in the event that typical availability solutions fail. At a minimum, the data management policies and procedures for the computers and users should be documented. Some elements to consider 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 Microsoft Visual SourceSafe® application servers?

• Data protection. Are 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 and validated?

Security Management

The Security Management SMF describes the processes required to maintain a safe computing environment. Security, a critical part of company infrastructure, guards against malicious or accidental activities that can cause data loss, unauthorized access to important data, and other potentially harmful events. Security processes are categorized into six fundamental precepts:

• Identification includes user names and the ways in which users identify themselves to the system.

• Authentication is the way in which users prove to the system that they are who they claim to be. Authentication tools include passwords, smart cards, and biometrics.

• Access control (also known as authorization) encompasses access and privileges granted to users so that they can perform certain functions on the system.

• Confidentiality deals with encryption. Confidentiality mechanisms ensure that only authorized users 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 is a means of providing proof of data transmission or receipt so that the occurrence of a transaction cannot be denied later.

During the security assessment, key areas to consider are:

• Desktop security , 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 , anti-spyware , and antispam solutions, also a diverse topic that typically involves several facets of the desktop assessment. A security group within the organization commonly manages antivirus software. 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 Remediation feature team, will be essential when gathering this information. When documenting an organization’s antivirus, antispyware, and antispam solution, team members should consider several items:

  • The network level at which the antivirus, anti-spyware, and antispam protection is installed, such as firewall, server, or client. Simply put, where are the products installed?

  • The vendors and products used , including version numbers and licensing models.

  • The degree of management to which the solutions are subjected. How do configuration and release management relate to 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 to solve users’ issues as quickly as possible. While documenting the service desk environment, it is essential that team members examine not only the IT functions but also the user expectations. Documenting the standard operating procedures of the service desk and the operating procedures it provides is important. Teams can use case studies and trouble call scenarios for these purposes. Additionally, teams must assess the skill and knowledge levels of the operations staff.

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 about conducting an assessment of this scope, refer to the MOF Operations Assessment service offering.

In the limited engagement assessment conducted as part of BDD 2007, many of the preliminary steps of the full operations assessment will have been completed as part of the project kickoff and planning process, as described earlier. Other portions of the full assessment may not be required. Table 2 presents a complete listing of the steps recommended to conduct an abbreviated assessment within the context of a deployment project. 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

Most of the activities listed for the Envisioning Phase will have been completed before the creation of an Operations Readiness 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 personnel best placed to provide the information needed to successfully complete the assessment. The team will then ask these individuals 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 a large organization (for example, 5000 computers) typically requires approximately six weeks, with a team of two assessors; smaller organizations may take less time. The assessment described in this guide, focusing on IT Operations specifically related to the desktop deployment, requires the participation of fewer IT staff and less time.

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. The team will then use this data to conduct a gap analysis to identify the deficient areas in the organization’s processes and 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 next section provides details for specific IT operations processes that should be in place to successfully complete the deployment project and maintain the newly deployed desktop environment into the future.

Milestone: Operational Assessment Complete

Table 3 shows all deliverables and their descriptions that should be completed at the conclusion of this phase.

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

Table 3. Deliverables

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions