Plan, Build, and Deploy Guide
Solution Accelerator for
Business Desktop Deployment
Plan, Build, and Deploy Guide
Published: January 2007
For the latest information, please see .
The information in this document and any document referenced herein is provided for informational purposes only, is provided AS IS AND WITH ALL FAULTS and cannot be understood as substituting for customized service and information that might be developed by Microsoft Corporation for a particular user based upon that user’s particular environment. RELIANCE UPON THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN IS AT THE USER’S OWN RISK.
© 2007 Microsoft Corporation. All rights reserved.
If the user of this work is using the work solely for non-commercial purposes internally within a company or organization, then this work is licensed under the Creative Commons Attribution-NonCommercial License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
MICROSOFT CORPORATION PROVIDES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION CONTAINED IN THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN. Microsoft Corporation provides no warranty and makes no representation that the information provided in this document or any document referenced herein is suitable or appropriate for any situation, and Microsoft Corporation cannot be held liable for any claim or damage of any kind that users of this document or any document referenced herein may suffer. Your retention of and/or use of this document and/or any document referenced herein constitutes your acceptance of these terms and conditions. If you do not accept these terms and conditions, Microsoft Corporation does not provide you with any right to use any part of this document or any document referenced herein.
Complying with the applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter within this document. Except as provided in any separate written license agreement from Microsoft, the furnishing of this document does not give you, the user, any license to these patents, trademarks, copyrights or other intellectual property.
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.
Microsoft, Active Directory, Excel, Internet Explorer, Microsoft Press, Outlook, SQL Server, Visual Basic, Visual SourceSafe, Windows, Windows NT, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Introduction 1
The Problem 1
The Solution 2
About MSF 2
Using This Solution 5
The Plan, Build, and Deploy Guide 5
The Feature Team Guides 5
The Job Aids 5
The Solution Script Files 6
Who Should Use This Solution? 6
Solution Updates 6
The Sample Scenario 6
Feature Teams 7
Communication 7
Communications Within Teams 7
Communications Among Feature Teams and the Lead Team 8
Communications with Stakeholders 9
Scaling the Feature Team 10
Additional Guidance on the MSF Team Model 10
Scaling the Solution 11
Small Organizations 11
Medium-sized Organizations 12
Solution Architecture 15
Process Overview 16
Inventory 18
Application Installation Automation 18
Moving Toward Software State Restore 18
Computer Imaging 19
Data and Settings Retention 21
Network Analysis 22
Deployment Process 22
Implementing MSF 23
Planning 25
The Envisioning Phase 25
Key Tasks 25
Team Focus 26
Interim Milestone 26
Feature Team and Job Aid Documents 27
The MSF Team Model: Setting Up the Team 27
Role Clusters 27
The MSF Team Model: Scaling Teams 30
Assembling Small Teams 30
Assembling Larger Teams 31
The MSF Team Model: Assigning Team Members to Roles 31
Assessing the Current Situation 32
The Vision/Scope Document 32
Defining the Business Goals 33
Defining the Vision and Scope 33
Creating the Vision Statement 33
Defining the Scope 34
Creating User Profiles 34
Developing the Solution Concept 35
Writing a Project Structure 35
Planning Project Communication 35
Planning Documentation Standards 35
Planning Change Control 36
Creating the Risk Assessment Document 36
Initial Assessment of Risk 36
Potential Risks 37
Learning More About Risk Assessment 37
Key Milestone: Vision/Scope Approved 37
Envisioning Phase Checklist 38
The Planning Phase 39
Key Tasks 39
Team Focus 40
Feature Team and Job Aid Documents 41
Establishing the Lab 41
Developing the Solution Design 42
The Design Process 42
Conceptual Design 43
Logical Design 43
Physical Design 43
Creating the Functional Specification 44
Determining the Functional Specification Contents 44
Developing the Project Plan 45
Creating the Development Plan 45
Creating the Test Plan 46
Creating the Deployment Plan 47
Creating the Pilot Plan 47
Creating the Communications Plan 48
Creating the Training Plan 48
Creating the Facilities and Hardware Plan 49
Creating the Budget Plan 50
Creating the Project Schedule 50
Creating Project Schedules 50
Assembling the Project Schedule 51
Creating the Development and Testing Environment 52
Interim Milestone: Technology Validation Complete 52
Key Milestone: Project Plans Approved 52
Planning Phase Checklist 53
Moving to the Developing Phase 53
Building 55
The Developing Phase 55
Key Tasks 55
Team Focus 56
Feature Team and Job Aid Documents 57
Starting the Development Cycle 57
Using Interim Builds 57
Creating Issue-Tracking Procedures 58
Preparing the Computing Environment 59
Developing the Solution Scripts 59
Application Packaging 59
Application Remediation 60
Data Retention 60
Creating Computer Images 60
Deployment Process 60
Documenting the Development Process 60
Developing Deployment Procedures 61
Creating Site Deployment Procedures 61
Creating Communications Materials 61
Creating Training Materials 61
Developing Operations Procedures 61
Testing the Solution 62
Approving the Key Milestone: Scope Complete 62
Developing Phase Checklist 62
Moving to the Stabilizing Phase 63
The Stabilizing Phase 63
Key Tasks 63
Team Focus 64
Feature Team Documents and Job Aids 64
Testing the Solution 65
Identifying Testing Tasks 65
Conducting the Pilot 65
Collecting User Feedback 65
Interim Milestones 66
Approving the Key Milestone: Release Readiness Approved 66
Stabilizing Phase Checklist 66
Moving to the Deploying Phase 66
Deploying 69
The Deploying Phase 69
Key Tasks 69
Team Focus 70
Feature Team and Job Aid Documents 70
Deploying Core Technology 70
Updating the Deployment Plan 70
Establishing Deployment Servers 70
Deploying Sites 71
Site Deployment Strategies 71
Preparing for Site Deployment 71
Performing Installations 72
Stabilizing the Site Deployment 72
Stabilizing the Deployment 72
Completing the Deployment 72
Making the Transition to IT Operations and Support 72
Signing Off on the Project 73
Obtaining Customer Sign-Off 73
Key Milestone: Deployment Complete 73
Closing the Project 75
Conducting the Project Review 75
Producing the Close-out Report 75
Looking Ahead 75
Appendix A: Planning 77
Envisioning 77
Planning 78
Appendix B: Building 79
Developing 79
Stabilizing 80
Appendix C: Deploying 81
Introduction
The Microsoft® Solution Accelerator for Business Desktop Deployment (BDD) is part of a family of Microsoft solution offerings aimed at providing reusable components and repeatable processes to achieve timely and cost-effective information technology (IT) solutions. To help enterprises plan and implement technology solutions to business problems, Microsoft solution offerings combine:
• Specific architectural, hardware, and software recommendations.
• Microsoft Solutions Framework (MSF) best practices.
• Feature team guides.
• Development resources.
Note In this document, Windows applies to both the Microsoft Windows® XP and the Windows Vista™ operating systems unless otherwise noted.
BDD 2007 for Windows Vista and the 2007 Microsoft Office system (BDD 2007) is designed to help a team deploy Windows, the 2007 Office system, and other applications to computers across an organization quickly and reliably. It addresses Windows Vista, Windows XP Tablet PC Edition, and Windows XP Professional. To achieve this goal, this accelerated solution provides fully developed processes for:
• Computer imaging.
• Software and hardware inventory.
• Application compatibility evaluation and remediation.
• Application packaging and scripting.
• Network inventory and analysis.
• Computer deployment, including data migration.
• Project management throughout the project’s life cycle.
This solution is based on MSF project principles and Microsoft Worldwide Services real-world best practices. It provides guidance and documentation that team members can use for planning, developing, and customizing the organization’s deployment.
Note: Deploying Office 2003 BDD 2007 describes how to deploy the 2007 Office system as part of a larger desktop deployment initiative. The guidance in the Office Deployment Guide also describes how to deploy the 2007 Office system alone, as part of an upgrade process. For information about deploying Microsoft Office 2003, see .
The Problem
In an increasingly fast-paced and competitive business environment, organizations recognize that to succeed in business, they must use the best technology and business processes available. However, the constantly changing nature of technology and the difficulties of managing people and processes may introduce problems that threaten business goals. In addition, infrastructure management is complex, and many organizations find deploying new hardware and software as well as supporting existing hardware and software difficult.
When an organization’s IT environment falls short of the ideal, a gap forms. This gap is typically characterized by excessive and uncontrolled IT spending resulting from a complex, difficult-to-support computing environment. This inadequate environment makes new development and software implementations problematic. When the computing environment is complex and not standardized, software cannot be rolled out to users in a comprehensive manner. Legacy hardware and software can constrict the computing tasks and solutions that IT is capable of offering users. In some ways, IT can become a hindrance to the business goals rather than a help.
The Solution
The solution is to reduce complexity and increase standardization by selecting a hardware and software baseline (or set of similar baselines) to which all users have access. The solution also includes automating repetitive tasks. With standard baselines, the IT department can more easily manage computing resources and roll out new software and hardware to its users. In this way, IT can divert spending away from excessive support and maintenance and into strengthening the organization’s competitive advantage and ability to reach its goals. After a standard baseline has been identified, the process for migrating to that new baseline must be established, enacted, and managed.
MSF provides guidance for managing these tasks. At its heart, MSF is about dedicated people using technology standards and business processes to improve the computing environment and make it more efficient. This solution is designed to accomplish this goal through implementation of several basic principles:
• Automation tools help reduce labor and increase reliability.
• Desktop management standardization helps organizations operate better by cutting costs and simplifying management and support.
• Standardization means minimizing the use of or retiring hardware and software that do not meet the standard to ensure that all users within the organization are capable of following the prescribed processes.
• Documenting computing standards, processes, and practices helps all users get the information they need to do their jobs.
• Proper integration of the desktop with other components of the computing environment, such as messaging, networking, and security, is a key component of an effective computing environment.
• Windows and the 2007 Office system provide an excellent opportunity to implement these principles throughout the organization.
This solution is built around a set of MSF-based best practices and principles of desktop management. These principles prescribe an organization-wide, component-based approach to standardizing personal computing systems that will ultimately help the organization maintain the IT environment more efficiently and proactively, saving money and improving other business practices.
About MSF
MSF is a flexible, interrelated series of concepts, models, and best practices that serve as a foundation on which to plan and build technology projects. MSF principles and practices help organizations envision, plan, and implement technology solutions that meet business objectives.
Microsoft created MSF in 1994, basing it on best practices within Microsoft’s product development and IT organizations. Microsoft also developed standardized training courses for MSF to promote consistency and effectiveness for project teams that use MSF. Since then, Microsoft Worldwide Services, partners, and customers have used core MSF concepts, models, and practices to ensure success in a wide range of technology solutions. Meanwhile, Microsoft uses continuing research and customer feedback to improve the MSF models, principles, best practices, and course offerings.
Distributed computing projects tend to be long and complex, and MSF helps participants by creating high-level consensus on vision, architecture, responsibilities, scheduling, and other factors that determine success or failure. A shared vision makes it possible to define, schedule, and carry out detailed methods. MSF also makes it possible to measure progress against original goals.
A disciplined approach is crucial to creating the right business solution on time, in scope, and within budget. Most technology projects depend on project management, business objectives, and development processes as much as on high-quality code. Choosing which technologies to use is only part of the effort; team members must also maximize their effectiveness. MSF helps guide teams to a successful solution. For additional background on MSF, see Microsoft Solutions Framework at .
Using This Solution
The solution offering has four components: the Plan, Build, and Deploy Guide, the technical feature team guides, the job aid documents, and the solution scripts. The team can use these interdependent components in whole or in part depending on the role of a particular team member in the project.
The Plan, Build, and Deploy Guide
The Plan, Build, and Deploy Guide explains how to plan and complete the project and is intended for the IT project team. It describes project planning, timelines, team roles, and other project management information.
The Feature Team Guides
The feature team guides provide information about specific technical areas. Separating the technical content from the planning and management content enables readers to focus on the types of documents that are most pertinent to their roles on the team. Feature team guides steer specialist teams through planning, building, and deploying tasks and checkpoints within the larger deployment project. Guiding the teams through the checkpoints ensures that each team’s decisions align with the overall project goals and that the deliverables are well integrated into the total migration project.
For example, a program manager will spend much more time with the Plan, Build, and Deploy Guide than with a technical imaging document; conversely, developers will spend the greater part of their time with the feature team guides and less with the Plan, Build, and Deploy Guide. Although this Plan, Build, and Deploy Guide may indicate that it is time to create a computer image, it does not describe how to perform that imaging. Instead, it refers to an imaging feature team guide.
Each feature team guide contains synchronization points that refer to an interim milestone in the Plan, Build, and Deploy Guide. In this way, the technical content can be updated independently of the management guide while remaining synchronized with specific deliverables, milestones, and decisions in the management planning structure. In addition, step-by-step processes are separated from conceptual content as appendices in the feature team guides. This separation enables team members to quickly move into action items, particularly when team members are well versed in the concepts underlying the Planning or Deploying Phases.
Note For a brief description of the feature team guides, see the Getting Started Guide.
The Job Aids
Several job aids (templates) are provided as starting points for the project. For example, where the Plan, Build, and Deploy Guide indicates the need for a functional specification document, the corresponding job aid shows which type of content should be included in the specification. The job aids can be modified to fit the specific processes and requirements of each organization.
The Solution Script Files
Teams use the solution script files to set up the imaging and deployment servers that create standard Windows-based desktop configurations. These files include utilities to customize boot CD-ROMs and connect them to the various servers and other assorted development tools. Use the scripts to perform such tasks as creating customized bootable images, deploying Windows from a share or Universal Naming Convention (UNC) path, customizing the deployment with applications, performing unattended installations, and capturing user data.
The solution script files do not contain copies of Windows or the 2007 Office system. To proceed with the project, team members require licensed copies of this software and of other vendor-specific software such as DVD player software and CD-creation software. A complete description of these requirements is available in the feature team guides. The Getting Started Guide provides an overview of the entire solution and helps teams complete the initial steps necessary to start the project.
Who Should Use This Solution?
This solution is useful to readers in two primary categories:
• IT departments can use this accelerated solution to plan and carry out a Windows desktop deployment either internally or with help from contractors or consultants.
• Consulting organizations can use this accelerated solution to plan and carry out a Windows deployment for a client company or organization.
To obtain the maximum benefit from this solution, the reader should have at least a basic understanding of commonly used computer and networking terms and concepts and be familiar with the Windows platform and user interface (UI). Team members should be proficient in their assigned duties and be familiar with the other roles defined for MSF teams.
Solution Updates
The recommendations and resources provided in BDD 2007 are based on the best information available as of November 2006. Tools and best practices associated with Windows deployments will continue to be refined and enhanced. See Desktop Deployment at for any updates concerning Windows deployments.
The Sample Scenario
This solution combines many abstract concepts that are often difficult to interpret without citing specific examples. To address this issue, the Plan, Build, and Deploy Guide and the feature team guides reference a desktop deployment project at a fictional company called Woodgrove Bank.
Woodgrove Bank is a leading global investment bank that serves institutional, corporate, government, and individual clients in its role as a financial intermediary. Its business includes securities underwriting, sales and trading, financial advisory services, investment research, venture capital, and brokerage services for financial institutions.
Woodgrove Bank employs more than 15,000 people in 60 offices worldwide. Woodgrove’s enterprise headquarters is in New York. The company has division headquarters in London and Tokyo. In addition, it has 57 offices across the globe. Of those 57 offices, 13 are considered regional hubs and have server infrastructure and at least one full-time IT administrator on location. Ten locations are considered autonomous branch offices and include server infrastructure on location but no full-time IT staff. The remaining 34 branch offices are micro-branches and do not have any server infrastructure or IT staff on location.
Feature Teams
A feature team is a cross-organizational team of responsible owners organized to solve a defined problem. BDD 2007 includes the following nine feature teams:
• Application Compatibility
• Application Management
• Computer Imaging System
• Desired Configuration Monitoring
• Infrastructure Remediation
• Operations Readiness
• Security
• Test
• User State Migration
Note For a detailed description of the feature teams, see the Getting Started Guide.
There are many good reasons for using feature teams. However, some risks must be recognized and planned for, as well. The use of feature teams has several advantages:
• They divide the work of the solution into discrete, definable parts that can be more easily managed.
• They enable the application of specialized expertise in areas where it is needed.
• They ensure that adequate cross-discipline involvement is included in the team. This means that the work is addressed from several perspectives rather than just one.
• Most important, they foster ownership of the problem space involved by giving feature teams the empowerment and accountability they require to complete the work. This results in a high degree of focus.
Communication
Key to successful project implementation is each feature team’s ability to cooperate and communicate among its members, with other feature teams, and with project stakeholders.
Communications Within Teams
By definition, MSF teams are teams of peers. Each role is considered equally important in achieving the project’s goals and thus in contributing to its success. Teams of peers are also characterized by joint decision-making about important issues. Open communications among team members, or the sharing of needed information, is essential in arriving at sound decisions that make the best use of team roles’ different perspectives. The lead team and the feature teams are all teams of peers.
Communications Among Feature Teams and the Lead Team
Figure 1 shows that one management team, called the lead team, orchestrates the efforts of the other feature teams. The relationships are that of a conductor and a group of soloists in an orchestra. The soloists are not subservient to the conductor, nor does the conductor pretend to be a virtuoso in each of the particular specialty areas. The lead team’s role is to make sure that the expert efforts of the group of feature teams are integrated into a holistic symphony rather than isolated, competing performances.
Note that the channels shown in Figure 1 are formal communications channels. Informal communications among feature teams are also required. Informal communications among feature teams and between a team and users should be governed by the general principles of good communication:
• Identify the right people to communicate with. It is crucial that the information obtained and the decisions made on the basis of this information are relevant and of good quality. Otherwise, a substantial amount of effort, time, and money could be wasted in rework.
• Communicate at the right level. A user is likely to become alienated if the communication is not designed to address the perceived problem in the language and nomenclature this user expects. For example, when a business decision maker loses trust in a team as a result of a perception that the team is purely technical—when it is important that the team understand the business problem—it is extremely difficult for the team to regain this trust.
[pic]
Figure 1. Formal communication channels in the BDD 2007 project
Communications with Stakeholders
For any team to be successful, it must interact, communicate, and coordinate with other external groups. These groups range from customers and users to other development teams. In a BDD 2007 project, several stakeholders might have overlapping and conflicting interests. Therefore, it is strongly suggested that the stakeholders be organized into a team of peers, with an MSF Program Management Role Cluster assigned to balance and trade off the conflicting requirements among the stakeholder factions. If the stakeholders agree with this arrangement, the project will run much more smoothly. Be aware, however, that stakeholders are likely to preserve their views in this type of deployment project, because it touches the primary interface that the client employees have with the organization: the application portfolio and service portfolio on the business desktop.
It is therefore a requirement that the relevant communication with stakeholders be documented and routed through the channels as shown in Figure 1. Relevant communication is defined as any decision or flow of information that defines, refines, or alters the scope, time, or budget of the initiative.
Scaling the Feature Team
The feature team model scales elegantly. It is highly recommended that most, if not all, of the role clusters be represented in the lead team. A feature team that focuses specifically on a particular aspect of a project, such as application compatibility resolution, however, can be staffed by a single multi-skilled person for very small deployments or by multiple people in each role cluster for large, complex deployments.
Additional Guidance on the MSF Team Model
For additional guidance on the MSF Team Model, see the white paper, “MSF Team Model,” which is available for download at .
Scaling the Solution
While the BDD 2007 documentation was written to address the large-scale needs of enterprises, the BDD 2007 technology can scale to both small and medium organizations. Smaller organizations can bypass portions of the BDD 2007 documentation and use a more streamlined process. Additionally, organizations can minimize infrastructure requirements by deploying BDD 2007 without a Microsoft Systems Management Server (SMS) infrastructure.
The sections that follow describe how to use BDD 2007 in small- and medium-sized organizations.
Small Organizations
Small organizations typically have one or two technologists who will perform the tasks required by multiple feature teams. Additionally, small organizations typically deploy smaller numbers of computers, so it is more time-efficient to use a more manual process rather than investing time to completely streamline the deployment process. Small organizations can react more quickly to problems that occur during or after deployment, and therefore do not require as extensive testing beforehand. Because small organizations are personally aware of every computer, they do not need to dedicate as much energy to inventory and management.
Given these factors, small organizations should use the following abbreviated process to create a BDD 2007 infrastructure and deploy Windows:
• Read the Getting Started Guide.
• Read the Release Notes.
• Read this guide, the Plan, Build, and Deploy Guide.
• Read the Computer Imaging System Feature Team Guide. This guide walks through the process of configuring a deployment infrastructure. Read this guide before beginning to configure the deployment infrastructure to gain an understanding of the server and lab requirements and how the organization might be able to use BDD 2007 with its existing equipment.
• Optionally, read the Application Compatibility Feature Team Guide. This guide describes how to test applications to ensure they will work properly with the new operating system. Most common applications will work properly, however, if the organization has custom applications or other applications that might not work properly, team members should read this guide and test the applications thoroughly.
• Optionally, read the Application Management Feature Team Guide. This guide contains information to help automate the deployment of applications. Depending on the number of computers and applications the organization plans to deploy, it may be more efficient to manually install applications after deploying the operating system.
• If the organization plans to deploy Microsoft Office, read the Office Deployment Guide. Alternatively, if the organization is deploying a small number of computers, teams might choose to skip this guide and manually install Microsoft Office after completing Windows deployment.
• Read the User State Migration Feature Team Guide existing computers will be replaced. If the teams have not assessed application requirements already, they should take some time to verify that User State Migration feature team correctly transfers all application-specific files and settings. If the organization is deploying computers to new users, this guide is unnecessary.
• Optionally, read the Security Feature Team Guide. This guide discusses how to both improve the security of client computers and to improve the security of the deployment infrastructure. If the default security settings meet the organization’s needs, teams need not read this guide.
• Read the Deployment Feature Team Guide and the Lite Touch Installation Guide. These documents describe the actual deployment process.
Medium-sized Organizations
Medium organizations typically have a few technologists who are familiar with most aspects of the organization’s IT infrastructure. Additionally, medium-sized organizations typically deploy smaller numbers of computers than enterprises. Therefore, the deployment requirements for medium-sized organizations are not as extreme as they are for enterprises, however, BDD 2007 can still improve the efficiency of medium-sized organizations.
Given these factors, medium-sized organizations should use the following abbreviated process to create a BDD 2007 infrastructure and deploy Windows
• Read the Getting Started Guide.
• Read the Release Notes.
• Read this guide, the Plan, Build, and Deploy Guide.
• Read the Infrastructure Remediation Feature Team Guide. It is important that medium-sized organizations track their computer hardware and software, and having an accurate inventory will help the organization plan for upgrade and enable teams to ensure compatibility for all the applications in the organization. For many medium-sized organizations, this part of the process will reveal previously unknown software that individuals or groups within the organization have deployed without IT assistance. Being aware of these applications will enable teams to ensure that the applications function properly after the new operating system deployment. Additionally, this guide will help identify new infrastructure requirements for the deployment servers.
• Read the Computer Imaging System Feature Team Guide. This guide walks through the process of configuring a deployment infrastructure.
• Read the Application Compatibility Feature Team Guide. This guide describes how to test applications to ensure that they will work properly with the new operating system. Focus testing efforts on a small audience and on custom applications and industry-specific applications that are least likely to work properly with the new operating system.
• If the organization plans to deploy Microsoft Office, teams should read the Office Deployment Guide. Alternatively, if the organization is deploying a small number of computers, teams might choose to skip this guide and manually install Microsoft Office after completing Windows deployment.
• Read the Application Management Feature Team Guide. This guide contains information to help automate the deployment of applications.
• Read the User State Migration Feature Team Guide if existing computers will be replaced. If the organization is deploying computers to new users or performing in-place upgrades, teams need not read this guide.
• Read the Security Feature Team Guide. This guide discusses how to both improve the security of client computers and to improve the security of the deployment infrastructure. If the default security settings meet the organization’s needs, teams need not read this guide.
• Read the Deployment Feature Team Guide. Then, read the Lite Touch Installation Guide to prepare BDD 2007 to deploy client computers. These documents describe the actual deployment process. Alternatively, if the organization plans to deploy a large number of client computers and would rather spend additional time configuring and testing the deployment infrastructure to spend less time deploying client computers, teams should read the Zero Touch Installation Guide instead of the Lite Touch Installation Guide. If the organization chooses Zero Touch installation (ZTI) and uses Microsoft Operations Manager (MOM), teams should also read MOM 2005 Management Pack for Zero Touch Installation.
Solution Architecture
The technical issues for the team can be summarized in one question: “How do we upgrade all the computers in Woodgrove to Windows and the 2007 Office system in a cost-effective manner without losing data and with minimum impact to the user?” Several issues must be addressed in assembling the correct teams and starting the project so that it focuses on answering that one key question.
To make the project succeed, the team must:
• Document the project’s business case. The sample Woodgrove Business Case provides a starting point for writing a business case for the project.
• Take an inventory of the existing production computers to determine the installed application base and the types of hardware currently deployed.
• Determine which applications can be redeployed on new systems, and start a process for packaging or scripting those applications so that they can be reinstalled quickly and consistently without user intervention.
• Define a strategy for addressing applications that cannot be supported on the new platform.
• Determine which types of hardware will be reused as part of the new computer deployment and which types might need to be retired.
• Create an imaging process to produce a standard enterprise image of the computer to aid in configuration management and to speed deployments.
• Establish a process for capturing the user data, settings, and preferences on the currently deployed systems and for restoring them on the newly deployed systems.
• Provide a method for backing up the current computer before the redeployment.
• Establish a network map of the client computers, servers, and other networking equipment to assist in planning for the deployments.
• Provide an end-to-end process for the actual deployment of the new computers.
• Create a plan for training users for the updated software.
While these tasks could be and often are treated as separate team projects, they are also highly interrelated. This solution treats these tasks as one project with communication among all groups to reduce the risk of some tasks being omitted.
A brief description that sets a baseline for how this solution addresses each general task follows in this guide. Additional details are provided in feature team guides associated with each task. Management, monitoring, communication, education, and planning across all these areas help ensure timely resolution of any issues that may arise. The majority of this document is focused on addressing how the various technical requirements are met and, through the use of milestones, how issues are identified in a timely fashion.
Process Overview
Figure 2 provides a high-level overview of the tasks that will be involved during the deployment process.
[pic]
Figure 2. Overview of the deployment process
Inventory
The team uses the Application Compatibility Toolkit (ACT) to query each production computer and consolidate data at a central location that can then be imported in to a database. The ACT contains a small collector program that team members run on each production computer. Team members can include this program in logon scripts, or they can launch it from a Web page or file share. The program produces an inventory cabinet (.cab) file that is then sent to a central repository server that can consolidate the information from all the computers and generate reports and queries. This data can be stored in Microsoft SQL Server™ 2005, SQL Server 2005 Express Edition, or SQL Server 2000. After collecting the data, this tool can generate reports that provide information about:
• Computer application inventory.
• Applications’ compatibility with Windows.
• Simple computer hardware information (memory, CPU, hard disk).
Teams can use this information to plan the other core areas. For example, they can use it to:
• Decide which applications will require compatibility remediation planning.
• Assist in prioritizing the packaging of applications based on volume or location.
• Provide information on hardware that may need to be upgraded or replaced.
Application Installation Automation
To enhance the configuration management capabilities of the organization, it is essential that all applications be installed and configured in a known, documented, and consistent manner. To do this, teams must automate all application installations and configurations by using unattended or silent installation options whenever possible.
Several ways exist to automate or script application installation. This component of BDD 2007 provides general guidance on the various approaches to installing and configuring applications in the Application Management Feature Team Guide.
Moving Toward Software State Restore
The extension of automated inventory and automated application installation can be termed software state restore. The goal of software state restore is the automated identification of existing applications on client systems and subsequent deployment of those applications during desktop deployment. For some applications, this means deploying a newer version of the application where a new version is available and planned as a part of the deployment. In other cases, an existing version of the application is reinstalled to target desktops.
The elemental goals of a fully automated software state restore mechanism are to accurately identify existing applications, map those applications to an established database of supported applications, provide reporting capability for planning and development, and automate the installations of the applications on specific target systems as needed.
Many of the elements of software state restore are present in BDD 2007. For example, the collector in the ACT provides inventory capabilities to identify existing applications, and those applications can be deployed automatically as part of overall desktop deployment through separate scripted actions or through customization of Windows Setup.
Additional components and tools will be added to upcoming releases of BDD, but the Deployment feature team can begin planning and implementing individual elements of software state restore to facilitate application deployment before the availability of these additional tools. These elements include:
• Inventory. Successful application deployment as part of overall desktop deployment requires an accurate inventory of existing applications. An aspect of the inventory process should include identification of which applications will be reinstalled as-is, which will be upgraded with updates, and which will be replaced with newer versions.
• Approval. Existence of an application on a given computer does not imply that the application should be allowed on the system, whether for security, licensing, suitability, or other reasons. The Deployment feature team should work closely with users to validate and approve applications, and then implement a mechanism for tracking application approval.
• Availability. To facilitate automated installation across the enterprise, applications must be available on the network. A structured network share hosting the application source files is one method of making applications available, but as the number of applications grows, so does the need for better tools for managing the applications outside the actual Deploying Phase. A managed applications database can fill the need for tracking applications in the source pool and can include key data such as compatibility information, required post-installation steps, and other issues related to the deployment of each application.
• Deployment. The deployment methods and requirements of each application must be identified early in the Planning Phase to allow sufficient time for scripting or other tasks to support installation of the application. Information about deployment requirements and methods should be stored in the managed applications database.
• Sign-off. Deployment of applications to target systems is not the culmination of the application deployment process. Rather, final stakeholder approval of application mapping and installation should be considered the final step. The processes and practices that the Deployment feature team uses to accomplish software state restore should include reporting capabilities to enable the customer to sign off on the application transformation process.
Computer Imaging
BDD 2007 focuses on a clean installation of Windows rather than upgrading from previous versions. In this way, the project team, the help desk, and the organization can work from a known state. Every computer is configured this way, without unknown or unanticipated differences, which makes the computing environment easier to set up, more efficient to administer, and less expensive to support. This method is sometimes referred to as a wipe-and-load approach, because it wipes out the original system completely and loads a new image.
Note Although this guide focuses on clean installations, Lite Touch Installation (LTI) also supports upgrade, refresh, and replace scenarios. With this support, team members can deploy the operating system to computers that are not suitable for the wipe-and-load approach, perform in-place upgrades, and perform refresh operations for existing computers running Windows.
The idea of the image is to create a select number of computers in a lab environment that meet the business needs of the enterprise. Teams can use tools, applications, security configurations, and corporate branding to customize these computers so that all users in the enterprise can use the computers without further customization.
When these systems meet the needs of the enterprise, they are imaged (or copied) so that they can be reproduced easily during the deployment. This approach saves considerable time and complexity. The feature team installs, configures, and tests the systems once and can then reproduce them thousands of times with confidence that the configuration has not changed.
This component supports computer imaging for the Windows XP and Windows Vista operating systems:
• Windows XP. BDD 2007 supports System Preparation Tool (Sysprep)–based images created using ImageX.
• Windows Vista. BDD 2007 supports Windows Imaging Format (WIM) images created with ImageX.exe, a command-line tool for creating and applying .wim files. Sysprep has been updated to support image-based setup and modularization. Use these tools to create a single file image on one system and deploy it to many different systems. Non-Microsoft tools such as Norton Ghost and PQDI are not supported as an imaging technology for Windows Vista.
The imaging process is scalable and extensible. Teams use batch files and Microsoft Visual Basic® Scripting Edition (VBScript) files to customize the computer configuration.
Table 1 describes the Windows Vista upgrade and migration paths. As shown in the table, performing an in-place upgrade from Windows XP with Service Pack 2 (SP2) or later to Windows Vista is supported. Using Windows Easy Transfer to migrate user state data from Microsoft Windows 2000 with SP4 or later to Windows Vista is supported. However, upgrading or migrating user state data from Microsoft Windows 98 to Windows Vista is not supported.
Table 1. Upgrade and Migration Paths
|From |Upgrade to Windows |Migrate to Windows Vista |Migrate to Windows |Migrate to Windows XP|
| |Vista |by using Windows Easy |Vista by using |with SP2 by using |
| | |Transfer |Microsoft Windows |USMT |
| | | |User State Migration | |
| | | |Tool (USMT) | |
|Microsoft Windows 95 |( |( |( |( |
|Windows 98 |( |( |( |( |
|Windows 98 Second Edition |( |( |( |( |
|Microsoft Windows NT® 4.0 |( |( |( |( |
|Windows 2000 with SP4 or |( |( |( |( |
|later | | | | |
|Windows XP with SP2 or later |( |( |( |( |
|Windows Vista |( |( |( |( |
| |(higher SKU) | | | |
( = not supported ( = supported
Note Teams cannot upgrade Windows XP x64 to Windows Vista x64.
Caution BDD 2007 provides out-of-the-box support for partitioning and formatting the entire hard disk in New Computer scenarios. While editing the ZTIdiskpart.txt script to create multiple partitions is possible, doing so has downstream consequences for which must be tested.
Data and Settings Retention
Users have data scattered across their systems as well as operating system and application settings and preferences that must be preserved when the system is rebuilt. BDD 2007 uses USMT to scan a system and copy the specified data files and application settings from computers to a local backup or to a deployment server. After a new computer is built, the process is reversed, and all the data is restored to the user’s computer.
USMT can migrate not only the user data but also preferences, such as screen savers, wallpaper, and application preferences such as Microsoft Office Word and Office Excel® settings. USMT can also support custom applications.
Some organizations want to do more than copy a computer’s data and preferences. They want to copy the entire computer to the server temporarily to ensure that no files are lost. To accomplish this, BDD 2007 can optionally image the entire computer locally or to a server by using imaging software in addition to or instead of using the USMT.
Network Analysis
BDD 2007 offers guidance on the benefits and use of network discovery tools and graphical network maps in planning for deployments. Teams can use this information in the planning process by correlating it with computer inventories. Doing so helps locate potential network bottlenecks.
For example, teams might want to deploy computers to the accounting department in one evening, but after reviewing the network discovery data, they see that all 200 computers are connected to the deployment server by the same network switch. Therefore, the anticipated volume of data would be beyond the switch’s capacity.
Based on this information, the organization can schedule the deployment to span several days. In this way, teams reduce the risk of overusing the switch, and the performance and likelihood of success on each computer increases.
Deployment Process
BDD 2007 describes how to implement the deployment process to perform the migration on the computer. By combining other processes, BDD 2007 can:
• Execute a deployment wizard to orchestrate the deployment.
• Run the USMT to capture user data and preferences.
• Back up (image) the entire computer to a server (optional).
• Wipe the existing computer’s hard disk (optional).
• Restore the new image onto the computer.
• Customize the new image for hardware-specific needs.
• Install computer- and user-specific applications.
• Restore the user’s data and preferences (USMT).
BDD 2007 supports taking user data and settings off one computer and restoring them onto either the same hardware (the Refresh scenario) or a different piece of equipment (the Replace scenario). A technician runs the deployment wizard, which controls how the deployment progresses. The wizard can specify user-specific applications that were previously automated to be included on the computer. In this way, teams can use a consistent base image while still providing users with all the applications they need.
Implementing MSF
The remainder of this guide focuses on how to implement BDD 2007 by using the three main categories of the MSF Process Model: Planning (includes the Envisioning and Planning Phases), Developing (includes the Developing and Stabilizing Phases), and Deploying (includes the Deploying Phase). The guide describes the activities that should occur at each phase so that nothing is overlooked. The five phases of the MSF Process Model each culminate in an externally visible milestone.
Table 2 lists the three categories, shows the five MSF phases with which they align, and brief describes each MSF phase’s focus.
Table 2. MSF Categories and Phases
|Category |MSF phase |Focus of MSF phase |
|Planning |Envisioning |A project team is assembled. It defines the vision and scope of a solution that |
| | |will meet the customer’s goals. The team then organizes the project and delivers |
| | |an approved vision/scope document. The Product Management and Program Management |
| | |Role Clusters take the lead during this phase. |
|Planning |Planning |The conceptual, logical, and physical design processes and functional |
| | |specification are developed. The Program Management Role Cluster creates project |
| | |plans addressing development, communication, and other tasks; and each role |
| | |provides input to create the project schedule. The Program Management Role |
| | |Cluster takes the lead during this phase. |
|Building |Developing |The team builds and tests the solution. The Development Role Cluster takes the |
| | |lead during this phase. |
|Building |Stabilizing |The team pilots the solution in preparation for production release. The Test Role|
| | |Cluster takes the lead during this phase. |
|Deploying |Deploying |The team deploys the solution to all sites and ensures that it is stable and |
| | |usable. Responsibility then shifts to IT Operations and the support teams. The |
| | |Release Management Role Cluster takes the lead during this phase. |
Planning
Planning is the first phase of the overall deployment process. The Planning Phase consists of several steps, from envisioning the deployment goals and vision to gathering data and resources that the teams will use during the following phases. The first step in this phase is envisioning the deployment.
The Envisioning Phase
The Envisioning Phase unifies the project team with a common vision. It culminates with a well-defined scope of work and project structure indicating team and customer agreement on the project’s direction.
Key Tasks
Table 3 lists key Envisioning Phase tasks and deliverables and their owners.
Table 3. Envisioning Phase Key Tasks, Deliverables, and Owners
|Key tasks |Deliverables |Owners |
|Setting up a team |All six team roles represented |Product Management; Program Management|
|Assessing the current situation |Compiled information on the computing |Program Management |
| |environment | |
|Defining the business goals |Problem statements and business |Product Management |
| |objectives (part of the vision/scope | |
| |document) | |
|Creating the vision statement and |A vision statement and definition of |Product Management |
|defining scope |scope (part of the vision/scope | |
| |document) | |
|Creating user profiles |Identification of users and their needs|Program Management |
| |(part of the vision/scope document) | |
|Developing the solution concept |The solution concept (part of the |Program Management |
| |vision/scope document) | |
|Creating the risk assessment document |A preliminary risk-assessment document |Program Management |
| |and list of top risks (list is part of | |
| |the vision/scope document) | |
|Writing a project structure |An initial set of standards (part of |Program Management |
| |the vision/scope document) | |
|Approving the milestone |Assembled vision/scope document, and |All roles |
| |all Envisioning Phase work approved | |
Team Focus
Table 4 lists the key areas of focus for each role cluster during the Envisioning Phase.
Table 4. Envisioning Phase Role Clusters and Focus
|Role cluster |Focus |
|Product Management |Identification of customer needs and requirements |
| |Vision/scope document |
|Program Management |Documentation of design goals |
| |Solution concept |
| |Project structure |
|Development |Creation of prototypes |
| |Evaluation of development and technology options |
| |Feasibility analysis |
|Test |Testing strategies |
| |Testing criteria |
| |Reporting |
|User Experience |User education needs and implications |
|Release Management |Deployment consideration |
| |Operations management and supportability |
| |Operational acceptance |
| |Network discovery |
| |Application and hardware inventory |
| |Interfacing with IT Operations and the Security feature team |
IT Operations and the Security feature team should be included in the assessments to ensure that an accurate view of their respective areas is addressed.
Interim Milestone
The Envisioning Phase of the MSF Process Model contains one interim milestone. Use the information and techniques in this guide to complete this milestone, which is a prioritized list of applications that business management has decided to include in its solution.
Feature Team and Job Aid Documents
The following documents are used in the Envisioning Phase:
• Vision/Scope
• Assessment template
• Deployment Feature Team Guide
• Operations Readiness Feature Team Guide
• Security Feature Team Guide
• Test Feature Team Guide
The MSF Team Model: Setting Up the Team
Microsoft developed the MSF Team Model over a period of several years to compensate for some of the disadvantages imposed by the top-down, linear structure of traditional project teams. Teams organized under the MSF Team Model are small, multidisciplinary teams in which the members share responsibilities and balance each other’s competencies to focus tightly on the project at hand. They share a common project vision, a focus on deploying the project, high standards for quality (sometimes referred to as a zero-defect mindset), and a willingness to learn. The MSF Team Model prescribes no single leader; the members work together as a team of peers with their own defined role or roles, with each role taking the focal point at different points in the process.
Role Clusters
The MSF Team Model defines six interdependent, multidisciplinary roles or role clusters with responsibility for implementing different aspects of the project (see Figure 3). The organization may choose to change or add to the responsibilities listed as appropriate for the project, provided all six roles are represented.
[pic]
Figure 3. The MSF Team Model
Product Management Role Cluster
The product manager acts as the customer advocate to the project team by ensuring that the team addresses the customer’s requirements, concerns, questions, and feedback throughout the project. Likewise, the product manager acts as the team’s liaison to the customer, handling high-level communication and managing the customer’s expectations.
On this project, the product manager is likely to be an IT director or higher-level executive who is empowered to make decisions regarding scope, cost, and project resources. The product manager must demonstrate leadership ability and a sincere belief in the project and the benefits to be gained from implementing it.
Product Management responsibilities for a BDD 2007 project include:
• Marketing
• Business value
• Customer advocacy
• Product planning
Note The product manager should provide a written description for each of these responsibilities so that they will be clearly defined for the rest of the team.
Program Management Role Cluster
The program manager functions as a “traffic director” to manage and coordinate the activities of the other team members. Program Management is responsible for setting the project schedule and for reporting the project status. Whereas the Product Management Role Cluster facilitates external communication between the team and the customer, the Program Management Role Cluster is responsible for facilitating internal communication among the members of the project team. Program Management’s duties include establishing design goals, directing the creation of the functional specification and the project plan, and coordinating the use of development resources by the Development and Test Role Clusters.
Program Management requires a clear understanding of the whole project: what is to be done, how it is to be done, when it will be done, and who will do it. Program managers should be skilled organizers and technically proficient. They do not need to interact with the technical personnel at a detailed level, but they must be technically oriented enough to work knowledgeably with them.
Development Role Cluster
The team members filling the Development role are responsible for designing, building, and unit-testing the baseline and imaging architectures. This includes writing and adapting scripts to facilitate the unattended installation of Windows and the 2007 Office system on all the hardware platforms included in the project scope. In addition to performing the actual development tasks, the developers are responsible for documenting their work, including configuration details and installation procedures. The Development Role Cluster is often filled by several individuals, depending on the nature and complexity of the project.
The developers must exhibit a high degree of technical understanding as well as a comprehension of the organization’s computing architecture and how Windows and the 2007 Office system fit within it. They must be familiar with the products being deployed, their feature sets, and the components for which they are specifically responsible. Do not assign the same people to both the Development and Test Role Clusters, because doing so does not provide an adequate check of the development work.
Depending on their responsibilities, developers should demonstrate proficiency in these areas:
• Batch scripting
• Knowledge of VBScript
• Familiarity with Microsoft Windows Preinstallation Environment (Windows PE)
• Windows setup methods and tools
• Using and configuring Windows, including security, policies, services, and network settings
• Using, deploying, configuring, and maintaining the 2007 Office system
• Using the Microsoft Office 2007 Resource Kit
• Imaging hard disks, including using Sysprep to prepare disks for imaging
• Using, deploying, and configuring disk-imaging tools
• Configuring desktop and laptop hardware, including the basic input/output system (BIOS)
• Application installation packaging tools
For the deployment project, the Development Role Cluster could be divided into sub-teams, which are often referred to as feature teams, with each feature team responsible for areas such as:
• Computer imaging system.
• Application management.
• Application compatibility remediation.
• LTI deployment process.
Test Role Cluster
The team members filling the Test Role Cluster are responsible for testing the architecture and associated documentation against the functional specification and ensuring that the documentation meets the requirements designed by the scope.
Testers should have a background in testing and an understanding of what testing entails. Accordingly, they should be very detail oriented and technical, have an understanding of the operating environment, and be committed to proactively finding errors. Familiarity with the Windows operating system environment and with the applications to be deployed is valuable.
User Experience Role Cluster
The team members filling the User Experience Role Cluster are responsible for defining training and communication requirements for users. Whereas Product Management functions as the customer advocate, acting on behalf of the person or people commissioning or paying for the project, the User Experience Role Cluster functions as the user advocate, acting on behalf of the people who will use the solution on a daily basis. For this project, User Experience is also responsible for educating users on the benefits of the solution and how they can use it to carry out their duties more efficiently.
User Experience specialists should be familiar with users and the jobs they perform and be able to assess users’ training and communications needs. They should also be able to design and conduct training programs.
Release Management Role Cluster
The Release Management Role Cluster is responsible for coordinating the activities necessary to ensure a successful rollout and for defining and documenting life cycle management strategies and processes. Team members filling this role act as IT Operations support advocates on the team, including administering acceptance testing, rolling out the solution, and helping to hand the solution over to ongoing operational support personnel.
Release Management must be familiar with the operational environment, including technical support and the help desk. Team members must also understand the impact the solution will have on the previous environment.
The Release Management Role Cluster must include resources to manage the computer inventory process and the network analysis process. Team members work to ensure that this information is conveyed to the development teams.
Assigning Roles
Although MSF defines six distinct team role clusters, not every team must consist of six people. Depending on the nature and extent of the project, the organization may have a core project team composed of more or fewer than six people, some of whom may be working on the project part time.
Within a large organization, it often makes sense to dedicate some project members to their tasks to build a robust and supportable desktop architecture. Dedicated team members devote 100 percent of their time to the project and have no day-to-day operations responsibilities unrelated to the project. Within smaller organizations, this setup may not be feasible, and team members who divide their time between the project and day-to-day operations may manage the scope of the project. Take these considerations into account when planning and assembling a team for the project.
The MSF Team Model: Scaling Teams
The size of the teams depends in large part on the size of the deployment and the complexity of each team’s responsibilities.
Assembling Small Teams
For small or resource-limited projects, consider assembling a small core team in which at least one of the members assumes responsibilities for two or more roles. Some of the ways the roles for a desktop deployment project can be combined include meshing:
• Release Management and User Experience.
• Test and User Experience.
• Program Management and Release Management.
Some roles should not be combined. The developer should not be responsible for testing, because such a combination does not provide an adequate check on the development work. Likewise, one team member should not be responsible for the Program Management and Product Management roles. Although it may be tempting to assign these roles to the same person, they might represent competing interests.
Very small projects may have a core project team composed of only three people: one responsible for Program Management and Release Management; one responsible for Development; and one responsible for Test, User Experience, and Product Management. IT staff may choose a different permutation depending on the nature of the project and the skills of the team members, provided they keep the restrictions previously listed in mind.
Assembling Larger Teams
For larger projects, the IT department may want to assemble a team in which some roles include more than one team member. This will often be true of the Development Role Cluster, which can be divided into several feature teams depending on the nature of the project.
Create feature teams based on logical divisions of work. For example, IT may create a Desktop feature team, which performs development activities related to Windows; an Applications feature team, which performs activities related to the 2007 Office system; and a Messaging/Internet feature team, which performs activities related to Microsoft Office Outlook® and Windows Internet Explorer®. Each of these feature teams may consist of one or more developers, and each developer may work on one or more feature teams. As more resources are added to the team, be careful to ensure that the team does not become too large to work together effectively as a group.
The MSF Team Model: Assigning Team Members to Roles
Although every role should be represented during the Envisioning Phase, it is not necessary to assemble the entire team at this point, nor is it necessary for every team member to be fully dedicated to the project yet. Every role, however, should have an identified lead during the Envisioning Phase.
All six roles are vital parts of the team. For this reason, make an effort to fully dedicate every lead to the project from the beginning, with none of them working on other projects. In reality, of course, it is not always possible for all team members to fully disengage from their other responsibilities before beginning work on the desktop deployment project.
Follow these guidelines when assigning roles:
• The people filling the Product Management and Program Management Role Clusters should be fully dedicated at this point, if possible.
• Although the Development lead can be wrapping up other projects during the Envisioning Phase, this person should be fully dedicated to this project, if possible. Expect to add additional team members to the Development Role Cluster during the Developing Phase.
• The Test lead can be assigned to other projects during the Envisioning Phase, if necessary, but should be involved with the project from the beginning and be available to sign off on important decisions. Expect to add additional team members to the Test Role Cluster during the Developing and Stabilizing Phases, if necessary.
• The User Experience lead will be collecting user profile information during the Envisioning Phase. This person can be assigned to other projects during the Envisioning Phase, if necessary. Expect to add additional team members to the User Experience Role Cluster during the Developing and Deploying Phases.
• The Release Management lead will be helping assess the current situation during the Envisioning Phase. This person can be assigned to other projects during the Envisioning Phase, if necessary. Expect to add additional team members to the Release Management Role Cluster during the Deploying Phase.
Any team members who work on other projects during the Envisioning Phase must demonstrate an ability to manage their time and attention well so as not to neglect their project responsibilities. Having team members work on other projects is a risk and should be recorded and tracked as risk.
If Program Management or other leads know in advance which people will be added to the team at a later stage, note this in the vision/scope document. It is not crucial to engage these future team members in the project, yet. Consider making the project documentation available to them to read at their discretion.
Assessing the Current Situation
A map is valuable to travelers only when they know where they are. Likewise, IT cannot effectively envision a desktop deployment project without a clear understanding of the current state of the organization’s computing environment. This includes accurate and up-to-date information about such things as the organization’s systems architecture, including the hardware and software already deployed and in what combinations, and the operational procedures currently in place within the organization.
Think of a deployment project as a phase in an ongoing process of technology life cycle management encompassing years or even decades. When the project begins, therefore, teams draw upon work done and experience gained long ago. After the project is concluded, teams use that work and experience to inform future life cycle management actions.
As part of the decision to explore deploying Windows or the 2007 Office system, someone in the IT department should have assessed the current computing environment as a starting point for decision making. The IT department may have chosen to conduct this assessment itself, or it may have hired a consulting firm to do it. The result of such an assessment is typically a document describing the assessor’s findings in some detail, which may include recommendations for future actions. This document should contain sufficient information about the computing environment, including network, domain, and physical location information, to allow knowledgeable planning.
During the Envisioning Phase, it is the job of the project team to gather relevant information about the current situation and look for deficiencies that the project can address. The information-gathering process may be as simple as obtaining documents like the one described above from the IT department. If no such documents exist, the team may have to gather existing documentation from various sources throughout the organization and assess them for accuracy and comprehensiveness or conduct a brief review of its own.
This time is often ideal to start the network discovery and the computer inventory processes to get a more accurate view of the environment. Typically, the Release Management Role Cluster takes the lead in assessing the current situation.
The Vision/Scope Document
The primary deliverable of the Envisioning Phase is the vision/scope document, which provides a clear direction for the project and sets expectations within the organization as well as with sponsors and stakeholders. It is composed of:
• Business goals. Includes problem statements that define the problems the project is intended to solve and business objectives
• Vision statement. Establishes a vision for the project
• Scope definition. Establishes the project scope
• User profiles. Identifies the users who will benefit from the solution
• Solution concept. Outlines the approach the team will take to plan the project
• Project structure and standards. Guidance for the team to follow
• Risks. Lists the top identified risks from the risk assessment document
Defining the Business Goals
Organizations undertake infrastructure deployments to address business needs. By the time the project has reached the MSF Envisioning Phase, these needs should be clear enough to be expressed and defined as problem statements and corresponding business objectives.
Problem statements identify perceived deficiencies in the computing environment. Business objectives define the goals the team hopes to achieve by suggesting actions it can take to mitigate the identified problems. These problems are sometimes called business opportunities, because they represent an opportunity for the organization to improve its processes.
The team should not undertake the project with the sole purpose of deploying the latest technology. Instead, the team must identify specific deficiencies and opportunities in the organization’s computing infrastructure and in the business itself and position the project directly at these areas. The Product Management Role Cluster takes the lead in defining the business goals, which should be about a page long or less.
A typical problem statement and business objective for this project might read:
The organization currently has no defined operating system standard. Several mergers and acquisitions have resulted in different branch offices running Microsoft Windows Me, Windows 2000 Professional, and Windows 98. This lack of standardization has led to increased support costs. Moving to a single operating system standard would present an opportunity to make measurable reductions in support costs.
Here, the problem statement is the description of the known disadvantages of having multiple operating systems deployed throughout the organization. The business objective is to minimize or eliminate these disadvantages through the adoption of a single standard.
Defining the Vision and Scope
Key steps in the Planning Phase include creating the vision statement and defining the scope of the project. The scope leads from the vision statement.
Creating the Vision Statement
The vision statement establishes a long-term vision to address the problem statements and achieve the business goals. Typically only a paragraph or two in length, the vision statement is not bound by the actual work the team expects to perform as part of the current project, but it should balance competing interests to provide a vision that can be shared among team members and provide context for future decision making.
A typical vision statement for a Windows deployment project might read:
The IT department will select and implement a single computing platform across the company to cut support center call volume by 10 percent and enable field technicians to spend at least 15 percent of their time on value-added projects instead of reactive support.
Defining the Scope
The scope takes the overall project vision as expressed in the vision statement and incorporates the restraints imposed by time, resources, budget, and other limitations. Generally, this process involves using versioned releases to define an iterative approach to the project, wherein the project team identifies the organization’s most essential needs and prioritizes the deployment based on this assessment.
For example, the vision might call for deploying Windows Vista, the 2007 Office system, and a suite of non-Microsoft applications throughout the organization. Time and budgetary restrictions might make it impossible to achieve the entire vision as part of a single project. The scope might therefore restrict the current project to a deployment of Windows Vista to desktop computers and portable computers throughout the organization and the 2007 Office system to desktop computers throughout the organization. Further projects in the future might involve deploying the 2007 Office system to the portable computers and any additional software to all the computers in the organization. Depending on the needs of the organization, the scope might restrict the deployment by department, by computer manufacturer, by geographic location, or by other factors.
The trade-off triangle that Figure 4 shows is an important component of MSF and helps set the project scope. The trade-off triangle dictates that resources, schedule, and features are three interconnected elements of any project and that constraining or enhancing one or more of these elements will require trade-offs with the others. For example, a project team with finite available resources (for example, personnel, budget, facilities) that commits to an early completion date will probably make trade-offs regarding the feature set to make the date, perhaps deferring deployment at some remote sites or on some systems for a later time.
[pic]
Figure 4. The MSF trade-off triangle
Creating User Profiles
Project success depends on every member of the team possessing an accurate understanding of the users and their needs. User profiles identify the users so that the team can assess the expectations, project risks and goals, and constraints. These profiles typically include information such as users’ geographic locations, job functions, organizational structure, and communications patterns.
The purpose of user profiles is to outline who the solution’s users are and what their relationship to the solution will be. IT personnel probably want to draw up different profiles for the users, defined as those who will use at least part of the solution to perform their business functions, and the IT professionals who will be responsible for deploying and maintaining the solution. Therefore, it might be necessary to identify different classes of users and develop profiles for all of them.
Developing the Solution Concept
The solution concept outlines an approach that provides the basis for planning and scoping the analysis and investigative work required to build a specification. Now that the team has identified the business problem and defined the vision and scope, it creates the solution concept, which explains at a high level how the team intends to meet the requirements of the project. Program Management takes the lead in developing the solution concept, which should be reasonably succinct, perhaps a few pages in length.
Whereas the scope describes what the team intends to do, the solution concept describes how the team intends to do it. The solution concept should remain relatively high level and can address such things as:
• The duties of each of the six team roles and the people selected to fill them (at least the leads at this point).
• An overview of the project, including phases and their accompanying milestones and deliverables based on the MSF Process Model.
• Factors outlining how project success is defined and measured.
• Sample scenarios for when and how the system is implemented and how users employ the new technology.
• A checklist of requirements that must be satisfied before the solution goes into production.
• An early high-level draft of the schedule for the Planning Phase.
Writing a Project Structure
The project structure defines how the team manages and supports the project and describes the administrative structure for the project team going into the Planning Phase. The main function of the project structure is to define standards the team will use during the project. These standards include communication standards, documentation standards, and change-control procedures. Consider creating an intranet Web site for the purposes of communication and monitoring progress.
The Program Management Role Cluster takes the lead in defining the project structure, which is usually included as a component of the vision/scope document.
Planning Project Communication
The Program Management Role Cluster should use the project structure to define standards for team members to communicate with one another. These standards might include a definition of the reporting structure under which team members operate, procedures for elevating issues, regular status meetings, and any other project-specific communication-related standards that must be defined during the Envisioning Phase.
The document may also include e-mail names, aliases, telephone lists, mail addresses, server share names, directory structures, and other information crucial to team organization. Consider establishing an internal Web page on which this information can reside and be updated as necessary.
Planning Documentation Standards
The project structure can also define standards on how to create training materials and documentation related to the project, including standards prescribing the applications and job aids (templates) the team should use to create documents.
Planning Change Control
Change, or the possibility of change, is an integral factor in any high-tech deployment project. Manufacturers frequently release new versions of software or issue updates and service packs for existing versions. By exercising control over any changes that could affect the scope of the project, the team can help ensure that it will complete the project on time and on budget, and prevent scope creep—the tendency to add features to the project in increments until the aggregate effect of the changes jeopardizes the project’s success.
The Program Management role should consider including change-control standards in the project structure. These standards would apply to both changes in project structure and scope as well as to changes in scripts. These standards can include prescribed daily builds and use of source-control software such as Microsoft Visual SourceSafe® 6.0 to control access to scripts.
Creating the Risk Assessment Document
Project risk, or the possibility of negative outcomes associated with individual aspects of the project, is a part of every deployment project. Risk management is the process of anticipating, addressing, mitigating, and preventing risk. Under MSF, risk management is something the team practices continuously throughout the project rather than just at predefined intervals.
Risk management is proactive: The team concentrates on continuously assessing what could go wrong and how to prevent it or minimize the loss it will cause rather than waiting for something to go wrong and coping with its effects.
Note BDD provides the job aid, Woodgrove Risk Template Tool, to help identify and prioritize risks.
Initial Assessment of Risk
During the Envisioning Phase, the team practices risk management by creating an initial risk-assessment document, which assembles all the known risks and assesses them for probability (the chance the risk will occur) and impact (the amount of loss that will result if the risk does occur). The Program Management Role Cluster takes the lead in creating the risk-assessment document.
If teams use numeric scales to assess risk probability and impact, they can calculate each risk’s exposure by multiplying the two numbers together, such that probability × impact = exposure. This calculation makes it possible to compare risks with one another to determine their relative severity and priority, which may not be readily apparent if, say, one risk has a high probability but low impact and another has a low probability and high impact. For example, if a team uses a number between 1 and 4 to designate each risk’s probability and impact, with 4 being the highest and 1 the lowest, multiplying the two together gives each risk an exposure factor between 1 and 16, thereby allowing team members to address the most severe risks first.
Teams need not use the same numeric scale to assess both probability and impact. If team members can accurately calculate the financial loss to be caused by each risk, they can express impact in terms of a monetary amount. It is important, however, that they use a consistent scale to calculate the probability for every risk as well as a consistent scale to calculate the impact for every risk. Using a monetary amount to express the impact of some risks and a numeric scale for other risks makes it impossible to compare risks with one another.
After the team has created the risk-assessment document and ranked each risk by exposure, a list of the top risks can enable the team to focus on the highest-priority risks. Often called a top 10 list, this list does not have to contain exactly 10 risks but can contain more or fewer depending on the number of risks identified and the exact nature of the risks and of the project overall. Program Management should review this list frequently throughout the project, adding and removing risks as they move up and down in importance and as new risks are identified.
Potential Risks
Some of the risks the team may have to manage when deploying Windows, the 2007 Office system, and other applications include the following:
• Components of the selected technology may contain bugs that will hinder its ability to perform as planned.
• The time frame allotted for the project may be too aggressive to allow the team to acceptably implement it.
• The team members may be unfamiliar with the concepts and principles of MSF and the roles they are to fill.
• The team members assigned to the project may be busy with other duties.
• IT managers throughout the company, especially those at remote locations, may be accustomed to working with a certain degree of autonomy and may resist standards that managers impose.
• Some in-house applications may not function correctly under Windows XP or Windows Vista.
The project team almost certainly will not face all these risks, and it will almost certainly face others not even on this list. Remember, too, that risk management is an ongoing process, and some risks will not become apparent until later in the process.
Learning More About Risk Assessment
Performing proper risk assessment requires an understanding of the philosophies underlying risk management in general and MSF risk management in particular. A detailed white paper on the MSF Risk Management Discipline is available at , and a risk-assessment document job aid (template) is provided with this solution.
Key Milestone: Vision/Scope Approved
The Vision/Scope Approved Milestone concludes the Envisioning Phase. At this point, the project team and the customer have agreed on the overall direction of the project, including which features the solution will and will not include, and a general timetable for delivery.
After the team roles have been defined and the Envisioning Phase deliverables have been created, the program manager assembles them into the vision/scope document. This document is then baselined and serves as a basis for project planning.
Envisioning Phase Checklist
Before proceeding to the Planning Phase, the following items should have been addressed:
• Business case
• Core teams identified:
• Program Management
• Product Management
• Development
• Test
• User Experience
• Release Management
• Feature teams identified:
• Application Compatibility
• Computer Imaging System
• Application Management
• Deployment
• Infrastructure Remediation
• Operations Readiness
• Security
• Test
• User State Migration
• Network discovery may have been accomplished
• IT Operations integrated into the project
• Project structure approved
• Risk assessment complete
• Security feature team integrated into the project
• Vision/scope document approved
• Computer inventory may have been accomplished
After all the Envisioning Phase tasks are complete, the team must formally agree that the project has reached the Vision/Scope Approved Milestone. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone has been met. The sign-off document becomes a project deliverable and is archived for future reference. The project can now move to the Planning Phase.
The Planning Phase
The Planning Phase is the period during which the team defines the solution: what to build, how to build it, and who will build it. The Planning Phase culminates in the Project Plans Approved Milestone, indicating that the project team, customer, and key project stakeholders agree on the details of the plan.
The team’s goal during the Planning Phase is to document the solution in a set of plans to a sufficient degree that the team can produce and deploy the right solution in a timely and cost-effective manner. These are living documents, and the team will continue to update them throughout the Developing Phase.
The Planning Phase has four primary deliverables: the functional specification, which includes the solution design; the project plan; the project schedule; and the development and testing environment.
Key Tasks
Table 5 lists key project planning tasks and deliverables and their owners.
Table 5. Planning Phase Key Tasks, Deliverables, and Owners
|Key tasks |Deliverables |Owners |
|Developing the solution design |The solution design document |Program Management (with heavy input |
| | |from Development) |
|Creating the functional |An initial draft of the functional |Program Management (with heavy input |
|specification |specification |from Development) |
|Developing the project plan |The project plan (a roll-up of all |Program Management (with each role |
| |the individual plans) |owning the sections assigned to it) |
|Creating the project schedule |The project schedule |Program Management (with each role |
| | |owning the sections assigned to it) |
|Identifying and prioritizing |Application list, subject matter |Release Management |
|applications |experts (SMEs), media, and settings | |
|Taking an inventorying of hardware |Analyzer tool deployed; reports |Release Management |
|and applications |generated for application | |
| |compatibility and hardware inventory | |
|Creating the core applications |Migration plan |Development |
|migration plan | | |
|Creating the security policies and |Security policies, strategies, and |Development |
|strategies |configuration | |
|Analyzing the network |Network diagrams of topology and |Release Management |
| |inventory of network devices | |
|Creating the Test plan |Test plan |Test |
|Creating the test lab |Test lab ready for testing |Test, Development |
|Approving the milestone |All Planning Phase work approved |All roles |
Team Focus
Table 6 outlines the primary activities of each role cluster during the Planning Phase.
Table 6. Planning Phase Role Clusters and Focus
|Role cluster |Focus |
|Product Management |Input into conceptual design |
| |Business requirements analysis |
| |Communications plan |
|Program Management |Conceptual and logical design |
| |Functional specification |
| |Project plan and project schedule |
| |Budget |
|Development |Technology evaluations |
| |Logical and physical design |
| |Development plan and schedule |
| |Establishing the lab |
| |Migration strategy |
| |Security policies and strategy |
|Test |Test strategy, types, plan, and schedules |
|User Experience |Usage scenarios/use cases, user requirements, and localization/accessibility |
| |requirements |
| |User documentation and training plan, schedules |
|Release Management |Design evaluation |
| |Operations requirements |
| |Pilot and deployment plan/schedule |
| |Network discovery |
| |Application and hardware inventory |
| |Interfacing with IT Operations and the Security feature team |
IT Operations and the Security feature team are included in the assessments to ensure that an accurate view of their respective areas is addressed. The user community is included to ensure that the plans and designs being compiled are consistent with their needs.
If not completed previously, an analysis of deployed applications is conducted to see which applications will be redeployed and which applications may be retired. Release Management initially prioritizes applications to establish a sequence for automating the applications’ deployment.
Release Management also conducts an initial review of the hardware inventory (if it has not already been done as part of the technology life cycle planning) to determine which computers can be used unchanged, which may require modifications (for example, RAM, disk), and which must be replaced.
Feature Team and Job Aid Documents
The following documents are used in the Planning Phase:
• Functional specification
• Risk assessment
• Project schedule
• Project plan, including:
• Development plan
• Test plan
• Deployment plan
• Pilot plan
• Communication plan
• Training plan
• Facilities and hardware plan
• Budget plan
• Application Compatibility Feature Team Guide
• Application Management Feature Team Guide
• Computer Imaging System Feature Team Guide
• Deployment Feature Team Guide
• Desired Configuration Monitoring Feature Team Guide
• Infrastructure Remediation Feature Team Guide
• Operations Readiness Feature Team Guide
• Security Feature Team Guide
• Test Feature Team Guide
• User State Migration Feature Team Guide
Establishing the Lab
If the teams do not already have one, it is advisable to establish a dedicated and isolated lab environment for use in developing and testing the solution. The lab should mirror the production environment as closely as possible to ensure that all aspects of the production environment can be accounted for in the development process.
At a minimum, the lab should include:
• A Microsoft Active Directory® directory service domain (Microsoft Windows Server® 2003 or Windows 2000 Server) with administrative privileges.
• Windows Server 2003 with SP1. (Windows Server 2003 R2 is preferred, because it provides a useful replication mechanism.)
• Microsoft Virtual Server 2005 (optional).
• Dynamic Host Configuration Protocol (DHCP) services.
• Domain Name System (DNS) services.
• Windows Internet Naming Service (WINS) services (optional).
• MOM 2005 (optional).
• Microsoft Windows Deployment Services (Windows DS).
• SMS 2003 with SP1 and the SMS Operating System Deployment (OSD) Feature Pack.
• SQL Server 2000.
• SQL Server 2000 Reporting Services Standard Edition.
• Internet access (for downloading updates, files, and so on).
• A file server with sufficient capacity to host the imaging server; 50 gigabytes (GB) is recommended.
• Test computers that accurately reflect production computers.
• CD burner and writeable CDs (required) or DVD burner and writeable DVDs (optional).
• Backup media, such as a tape backup system and tapes.
• Software library, including Windows, the 2007 Office System, applications, disk imaging software, Windows PE, and hardware drivers.
Developing the Solution Design
The solution design is the first comprehensive design document and is part of the functional specification. This design prepares the team members for their responsibilities during the Developing Phase. It builds on the vision the team developed and technology information the team gathered during the Envisioning Phase, and it sets forth the conceptual, logical, and physical solution designs. Think of the processes that produce these designs as three overlapping stages of a design process that begins before the Envisioning Phase and continues throughout the project and afterward, with the project itself being only a component of a larger technology life cycle management process.
The Design Process
The design process is like a construction project for building a house. The conceptual design is analogous to the rough sketches and scenarios the architect creates in conjunction with the customer. The logical design is created by the architect’s team and lays out the structure of the solution and the communication paths among elements; it corresponds to a floor plan and elevation, where elements such as spatial relationships are organized. The physical design corresponds to a contractor’s blueprints for the physical elements of a structure—wiring, plumbing, heating, and ventilation. The contractor’s plans (physical design) add detail to the architect’s plans (logical design) and reflect real-world construction constraints.
Conceptual Design
Conceptual design involves understanding the business requirements and defining the features and functions users need to do their jobs. Product Management takes the lead in creating the conceptual design, which begins during the Envisioning Phase and continues throughout the Planning Phase. The conceptual design of this project should include:
• Design goals that describe the objectives of the project in ways that address the problem statements and business opportunities identified in the vision/scope document.
• The list of features and functions that the solution comprises. The conceptual design typically states this list in terms of the operating system and applications that are to be deployed (in this case, Windows and any additional applications), the unattended installation architecture (including distribution servers), and the disk-imaging architecture.
• Usage scenarios that anticipate the ways in which different types of users will implement, administer, and use the solution. Revisit the user profiles defined in the vision/scope document, and describe how the types of users identified will work with the solution. Tasks to document can include administering the distribution architecture, installing and configuring the solution on new computers, configuring Windows for first use, and using different components of the solution to implement business objectives.
Logical Design
Logical design uses the conceptual design and the current state of the technology infrastructure to define the new architecture at a high level. The logical design of this project should include:
• A high-level definition of the unattended installation architecture that the Deployment feature team uses to begin the deployment process on each affected computer as well as the configuration and placement of deployment servers. This definition does not necessarily include the exact physical location of each deployment server but should outline the rationale behind choosing the desired locations.
• A similar definition of the hard disk imaging architecture, including a justification for using disk images, a description of the facilities needed for performing disk duplication, and a description of the software tools the team uses to prepare hard disks for duplication (typically, Sysprep).
Physical Design
Physical design goes into greater detail about the desired architecture, and it defines the hardware configurations and software products to be used. The physical design of this project should include:
• Specifications for the hardware configurations included in the scope of the project.
• Specifications for the software to be installed.
• The tools to be used for project development.
As a general rule, the solution design should contain enough detail to enable the team to begin work on the project plan.
The team should complete the conceptual and logical designs by the end of the Planning Phase. The physical design is “baselined” to draft the solution design, but it continues to be refined throughout the remainder of the project, changing as the team makes and revises development and deployment decisions.
Creating the Functional Specification
The functional specification addresses what the solution must include. It represents the contract between the customer and the project team and is the basis for building the project plans and schedules. During the Planning Phase, the functional specification is baselined and placed under change control. Program Management takes the lead in compiling the functional specification with input from the role leads regarding their areas of responsibility. The Development, Product Management, and User Experience Role Clusters are often active in determining what to include in the functional specification.
As with the project plan and the project schedule, the primary purpose of the functional specification is to specify what work will be done in the Developing, Stabilizing, and Deploying Phases and how the work will be done.
Baseline early, freeze late is an MSF best practice. The functional specification is a living document, and the team continues to update it and add to it throughout the project. The Program Management Role Cluster should baseline the functional specification so that it contains enough detail to make accurate planning and scheduling possible. Developing the specification is an iterative process: The Program Management Role Cluster should expect to add to and refine the document as planning progresses, and to some extent during the Developing and Deploying Phases, when the document is under change control. The team freezes the functional specification at the end of the Developing Phase before moving on to the Deploying Phase.
Initially, creating the functional specification is typically a matter of assembling deliverables produced during the Envisioning and Planning phases and identifying the areas to expand on later in the project.
Determining the Functional Specification Contents
The functional specification documents the design process, incorporating the conceptual, logical, and physical designs. Accordingly, high-level design decisions such as server placement and network configuration, as well as aspects of the physical design such as configuration and initialization documents, should be documented in the functional specification. The team will not create some of these documents until the Developing, Stabilizing, and Deploying Phases, so it is not possible to include these components as part of the baseline. For the functional specification, however, components can be identified that the team must develop later.
The functional specification should include some or all of the following:
• A summary of the vision/scope document as agreed upon and refined, including background information to place the solution in a business context
• Any additional user and customer requirements beyond those already identified in the vision/scope document
• Specifications of the components that will be part of the solution, such as Windows and the 2007 Office system
During the Envisioning Phase, the project team defined the scope of the project as dictated by time, budget, and other considerations. Part of creating the functional specification is deciding which specific components of the solution fall within the scope and which do not. Document elements such as:
• Which hardware configurations the development effort will support (for example, hard disks, video cards, other peripherals).
• Which applications to include as part of the baseline.
• Version information for all the software to be deployed.
• The methods to use to deploy the baselines (for example, servers and/or CD-ROMs, images and/or unattended installations).
Developing the Project Plan
The project plan is a collection of plans that addresses the tasks the six team roles perform to carry out the project as defined by the functional specification. Not every project requires every plan listed here, and some projects may require additional plans. This section includes the following plans:
• Development plan
• Test plan
• Deployment plan
• Pilot plan
• Communications plan
• Training plan
• Facilities and Hardware plan
• Budget plan
Most of the plans in the project plan should be just a few pages long. The Program Management Role Cluster takes the lead in assigning the writing of plans to the appropriate roles, assisting with plans when needed, and assembling the project plan.
To facilitate developing the test plan, BDD 2007 includes the sample Test Plan, Test Specification, and Test Cases Workbook job aids. The Client Build Requirements and Vision/Scope job aids support the development plan. Also included are the Communications Plan, Pilot Plan, and Training Plan job aids.
Creating the Development Plan
The development plan is a crucial component of any infrastructure deployment project. It describes the approach the project team takes to develop the solution during the next phase to meet the requirements of the vision and scope. The Development Role Cluster takes the lead in creating this plan.
Among the areas the development plan can cover are:
• Team roles and responsibilities—specifically, detail each developer’s areas of responsibility.
• A list and description of the deliverables the developers will produce. Typically, these include:
• The actual scripts produced, including any modifications made to the scripts and configuration files.
• A description of the baseline architecture and the steps the team takes to deliver it.
• A list of the additional applications to be deployed as part of the baseline, including the 2007 Office system, along with any installation packages the team must create or customize.
• The kinds of documents, such as installation procedures and software configurations, that the Development Role Cluster expects to create during the Developing Phase.
• A brief treatment of the team’s approach to using unattended installations versus disk images. Expand on this in the deployment plan.
• Plans for interim builds, including how many to create and which aspects of the solution will be covered in each interim build.
Although the development plan is primarily intended for the developers, another goal of the plan is to formalize processes and plans to aid in the support and ongoing management of the solution. When the project team hands over responsibility for the solution to ongoing support and operations personnel, the latter group should be able to use these documents (covering such things as installation procedures and software configurations) to deploy Windows to new computers and provide technical support. The developers should make an effort to complete and submit this documentation at the same time they submit the corresponding solution scripts so that support and operations personnel have immediate access to all the available information on the solution.
Creating the Test Plan
The test plan outlines the strategy the team uses to test the solution. In this solution, different test plans are generated. For the overall initiative, the test plan addresses the verification of the process, image, and infrastructure needed to deploy the new desktop images and the required supplemental applications. The Application Compatibility feature team requires a detailed test plan to identify the relevant business applications to test and which tests to perform. The Computer Imaging System feature team must define the supported hardware profiles of the target infrastructure and test the different images for specific driver requirements for the hardware. A significant portion of the migration initiative will be spent in testing, so take time to identify the testing requirements and plan accordingly.
The Test Role Cluster typically takes the lead in creating the test plan. Areas to cover include:
• A description of the testing environment. Diagrams and schematics can help illustrate the environment.
• Change control and how it will be enforced.
• Issue-tracking procedures. Describe the issue-tracking database that will be used, including the program used to create it, who will have access to it, and the fields to be used.
• Who is responsible for testing each part of the solution.
• Test matrices that address which components of the solution team members must test and in what way. For example, a team may plan to develop test matrices for installation, configuration, the operating system, and the suite of applications.
• The materials the project team must create the developing and testing environments.
The test plan should specify the types of testing the team performs during the Developing Phase. Typical types of testing include:
• Installation testing. Installation testing ensures that each component has been installed without error. The tester installs a build and verifies that Windows Setup runs and finishes correctly, that application setup and configuration programs run and finish correctly, and that the process correctly installs every component included in the build.
• Configuration testing. Configuration testing ensures that the installation process configures each component correctly as indicated in the configuration documentation.
• Functionality testing. Functionality testing ensures that basic operating system and application functions work as expected without error. Functionality testing is not a repetition of testing that the manufacturers of the hardware and software performed. Rather, it verifies typical use scenarios. In this respect, functionality testing is much like user acceptance testing, except that project team members perform functionality testing before user acceptance testing.
• User acceptance testing. User acceptance testing ensures that the system as a whole operates in a manner that is suitable for users. Typically, this testing involves exposing a few users and IT deployment personnel to the solution and verifying that they can use it to perform their duties.
The team may choose to perform other types of testing, such as regression testing and compliance testing, in accordance with the requirements of the project.
Creating the Deployment Plan
The deployment plan outlines the strategy the team uses to deploy the solution. The main function of the plan is to address the tasks that must be performed during deployment and who will perform them. To this end, the deployment plan can include such information as:
• Whether the team plans to deploy the solution in phases or all at once.
• The order in which sites will receive the solution, if applicable.
• Whether internal IT staff or outside consultants perform the deployment.
• Checklists team members will use to perform deployment tasks at each site. The team creates these checklists later in the project.
• Plans for a database to keep track of users’ needs.
• Procedures to use for migrating data and applications to Windows after a clean installation on an existing computer and for testing migrated applications.
• How to handle feedback from the users affected by the deployment.
The Release Management Role Cluster typically takes the lead in developing this plan.
Creating the Pilot Plan
The pilot plan describes the team’s goals for conducting the pilot so as to best prepare for the full deployment. The Product Management or the Release Management Role Cluster typically takes the lead in developing this plan.
This is usually a good time in the planning process to select a group for the pilot, unless political, organizational, or other concerns prevent it. To ensure that the pilot group provides optimum feedback for the Deployment feature team, the group selected for the pilot should be representative of the organization as a whole. Product Management, or in some cases the Release Management Role Cluster, should lead the effort to find a pilot group. If the team already has a good idea which group will be tapped for the pilot, include this information in the pilot plan. If not, record the team’s criteria for an ideal pilot group, including considerations such as:
• The number of users to include in the pilot deployment.
• The hardware configurations that should be represented in the pilot group.
• Any location considerations, such as whether to employ users in a single physical location or scattered over distant offices.
• Political or organizational considerations.
In addition to describing characteristics of the pilot group, the pilot plan should identify characteristics of the pilot itself, such as:
• How long the pilot lasts.
• Which components of the solution will be included as part of the pilot.
• How to handle feedback from the pilot, including whether to make modifications to the solution as a result of the feedback.
• The pilot success criteria.
Creating the Communications Plan
The communications plan describes how the team communicates with the groups the solution affects. Identify everyone who has a stake in the solution and the level of communication needed. Typically, this includes not only users but also support and help desk personnel, other IT employees, the management staff responsible for budgeting the project, personnel whose work will be disrupted by project-related activities, and others.
The communications plan should prescribe communications strategies for each of the identified groups of people affected by the project. The team will likely have a wide range of options for communication, including:
• Face-to-face meetings.
• E-mail, including mailing lists.
• Printed or electronic newsletters. This step can involve either publishing project-specific newsletters or including project information in existing organizational newsletters. Consider IT newsletters or bulletins, department-specific or site-specific newsletters, and organization-wide bulletins.
• Informational intranet Web sites.
• Voice mail.
The communications plan should provide strategies for ensuring that every affected group gets the information it needs when it needs it without burdening people with too much information. Part of this task includes picking people with good communications skills to furnish this information. The plan should identify the people responsible for communicating the desired messages to the people who need to know that information.
Creating the Training Plan
The User Experience Role Cluster typically takes the lead in developing the training plan. As with the communications plan, the role should consider the different types of audiences that require training. At the very least, there will be two broad categories of people to consider: users and IT staff, including system administrators and help desk personnel. The role may identify other categories, depending on the requirements of the project.
There is no single right way to do training. Developing a training plan is always done within the constraints of the project. Factors that may influence how training is carried out include user knowledge, time, budget, and availability of skilled trainers and people to develop training. The organization’s culture and type of business may dictate particular training vehicles or the duration or technical level of training.
If the users in the organization are familiar with Windows XP and Windows 2000, for example, they will not require much training to maintain the same or better productivity with Windows Vista. However, additional training can enable them to take better advantage of new Windows Vista features and further improve productivity. IT professionals will typically require more in-depth instruction on the differences between Windows 2000, Windows XP, and Windows Vista.
Likewise, users who have used Microsoft Office XP or Office 97 should be able to learn later versions of the Microsoft Office System without much training. One approach to consider in these cases is a simple Web-based resource guide from which users can learn about the new features of Windows Vista and the 2007 Office system and how they can use them to become more productive.
If users are unfamiliar with the Windows operating system and the 2007 Office system and require more training, several options are available, including:
• Hands-on training, in which the user learns the software by using it.
• Presentation-style training, in which the user takes classes in using the software.
• Computer-based training (CBT) or Web-based training (WBT), in which special training software educates the user.
• One-on-one training.
• Job aids or handouts.
When designing training for IT staff, consider whether they must understand the entire unattended installation process or just portions of it and whether they will need to understand how to return a computer to the baseline configuration. Consider hands-on training and self-study methods. The documents the team creates as part of the functional specification can be invaluable teaching aids for IT staff.
Note Microsoft Learning Solutions is a cost-effective, self-hosted learning solution that provides valuable software training and reference materials on Microsoft products and technologies. For more information about Microsoft Learning Solutions, visit . Additionally, Microsoft Press® offers a variety of books and teaching aids to consider for training. For more information about these materials, including ordering information, visit the Microsoft Press Web site at .
The training plan should describe the project team’s approach to training, noting any constraints or requirements and explaining why the team chose that approach.
Creating the Facilities and Hardware Plan
If the project involves deploying the solution to existing computer systems, consider drawing up a facilities and hardware plan detailing how many computer systems in the organization meet these requirements and how many fall short. If a significant number of the computers fail to meet the requirements of Windows Vista or any of the software applications to be deployed, for example, use this plan to describe how the team will approach these computers. Possible courses of action include:
• Deploying only to those computers that are capable of running the solution and leaving the others untouched until they are upgraded or replaced at a future time.
• Planning upgrades and replacements of the less-powerful computers over time and including the upgrade cost in the project budget.
• Purchasing new hardware, such as RAM and hard disks for the less-powerful computers to bring them in line with the project specification.
As with the other components of the project plan, there is no right way to develop the facilities and hardware plan. The constraints imposed by time, budget, and other external considerations will dictate in part the team’s approach.
The Program Management or the Release Management Role Cluster typically takes the lead in developing this plan. An area that should be carefully considered in the facilities and hardware plan is the potential volume of disk storage required during the deployment process. In the deployment process, two options can significantly affect the amount of server disk space required during the deployment. The first is the use of USMT to capture all user data files, settings, and preferences from the computer onto a network share on the data server. This option can quickly increase the amount of space required on the data server. The second is the option to create a backup image of the entire computer before the migration. This option can add gigabytes per user to the amount of space required on the server. Most organizations retain this data only temporarily, so the disk requirements are also temporary. Teams can put these options into effect on a can-be-changed-on-a-user-by-user basis.
For a detailed description of the capacity requirements, refer to the Lite Touch Installation Guide.
Creating the Budget Plan
If cost will be a deciding factor in how the team implements the solution—which it will in most cases—the team should draw up a budget plan detailing how it will spend the money available. The budget plan should be the final component of the project plan. Program Management takes the lead in developing this plan, waiting until the rest of the project plan is complete before finalizing the budget to ensure that the budget is as accurate as possible, with all items accounted for. Areas to consider when creating a budget for the project include:
• The software the organization must purchase or license for the solution, including Windows, the 2007 Office system, and any non-Microsoft software to be deployed as part of the solution.
• Development tools or other software the project team purchases as part of the deployment process.
• Hardware and networking equipment the team deploys or uses during development.
• Contractors or other outside professionals the team shire to help with development, testing, training, or other project-related activities.
• Training courseware or other training aids.
Creating the Project Schedule
The project schedule is a compilation of schedules created by team members for the purpose of planning their activities. It can include some or all of the following as appropriate:
• A development schedule
• A test schedule
• A user experience schedule
• A release management schedule
• A deployment schedule
Any role may choose to divide its schedule by functional area. For example, if different development sub-teams will be working on the imaging and application packaging architectures, each sub-team might create its own schedule.
Creating Project Schedules
Each role lead performs a functional breakdown and prioritization of the role’s responsibilities, while team members perform task-level estimating. The length of an individual task should be between a half day and a week. If the task duration is too short, the overhead in managing the task may be too high. If the task duration is too long, it is difficult to manage the scope of the work.
In addition to planning task durations, the team members creating the schedules should assign names to tasks. After creating the vision/scope document, solution design document, and project plans, role leads should know which team members will be responsible for specific areas. Schedules make these assignments more specific so that all team members know what they will be doing and when.
Projects of this nature can take anywhere from a few weeks to several months. When scheduling the project, consider factors such as:
• The size of the organization.
• The extent of the deployment.
• The number of hardware configurations affected.
• The number of applications to support.
• How to handle data migration.
• The availability of resources.
• The amount of customization required.
• The requirements of different groups driving changes to the functional specification.
• Whether the project team is assisted by third parties, such as consultants, who have experience with similar projects.
The Developing Phase in typical desktop deployment projects in medium (5000 to 10,000 users affected) and large (more than 10,000 users affected) organizations might take 6–10 weeks. Project management software such as Microsoft Office Project can help create the project schedule. Project management software has features that enable teams to assign duration, resources, and prerequisites to tasks and automatically calculate important dates.
Assembling the Project Schedule
Program Management compiles and coordinates the schedules that the different roles submit so that team members can work effectively. The resulting document is the project schedule.
Program Management should build buffer time into the schedule to compensate for schedule slippage caused by unforeseeable delays. Team members should not view buffer time as a development cushion and should use it only if necessary and at the program manager’s discretion. To protect the buffer time from outside influences, designate internal milestones that are visible only to the team and separated from the externally visible milestone by buffer time (see Figure 5). For example, the team might plan to complete the Developing Phase by April 10 but designate April 17 as the externally visible milestone date for Developing Phase completion. The period of time between April 10 and April 17 would be buffer time.
[pic]
Figure 5. Planning buffer time
Creating the Development and Testing Environment
A key task of the Planning Phase is the creation of an environment in which team members can develop and test the solution without affecting day-to-day operations for other users. The development environment should be physically separate from the testing environment, though they may share some of the same resources at different times.
The development and testing environment is typically referred to as the lab, though it may not always be physically separate from the existing production environment. Weigh the costs and benefits of physical separation before creating the lab. By contrast, all developing and testing work should take place in an isolated network or a non-production Windows domain and network segment, if possible. Production users should not be granted access to computing resources in the lab, and the work that the developers and testers perform should not affect work that users perform.
The lab should contain at least one computer for each hardware configuration identified in the physical design. Remember that computers can be shared between the Development and Test Role Clusters, though not at the same time; use this setup to cut down on development costs, if necessary. For example, Development might use some computers and domains and hand them off to Test later in the Developing Phase.
Design the testing environment to emulate the production environment as closely as possible, as in the following example:
The corporate wide area network (WAN) encompasses 540 computers in six basic hardware configurations. The WAN is a Virtual Private Network (VPN) consisting of the home office in Minneapolis; five sales offices throughout Minnesota, Wisconsin, and South Dakota connected to the Internet through T-1 lines; and a service center in Eden Prairie, Minnesota, on an asymmetric digital subscriber line (ADSL) link. The testing environment will contain one computer for each hardware configuration, each of which from time to time will be connected either directly to the corporate local area network (LAN) or to the Internet, either through a dedicated T-1 line or an ADSL line installed in the testing lab.
Interim Milestone: Technology Validation Complete
To achieve this milestone, the project team must manually install the technology components of the solution on pristine hardware in the most accommodating environment. The goals of this milestone are to minimize extraneous variables and to ensure that the technology components work and conform to the functional specification.
Key Milestone: Project Plans Approved
At the Project Plans Approved Milestone, the project team and key project stakeholders agree that interim milestones have been met, due dates are realistic, project roles and responsibilities are well defined, and mechanisms are in place for addressing areas of project risk. The functional specification, the project plan, and the project schedule provide the basis for making future trade-off decisions.
After the team approves the specifications, plans, and schedules, the documents become the project baseline. The baseline takes into account the various decisions that are reached by consensus by applying the three project planning variables: resources, schedule, and features. After the baseline is completed and approved, it is placed under change control. This does not mean that all decisions reached in the Planning Phase are final. But it does mean that as work progresses in the Developing Phase, the team should formally review and approve any suggested changes to the baseline.
Planning Phase Checklist
Before proceeding to the Developing Phase, the following items should have been addressed:
• Application list, SMEs, and media
• Application packaging under way
• Core applications migration plan
• Functional specification approved
• Lab environment established for development and testing
• Network diagrams created and analyzed
• Operations review/assessment of the functional specification
• Project plan created
• Project schedule created
• Risk management plan updated and reviewed
• Security policies, strategies, and configuration
• Security review/assessment of the functional specification
• Technological approach has been validated
• Test plan created
• Computer application inventory conducted and reviewed
• Computer hardware inventory conducted and reviewed
Moving to the Developing Phase
When all the Planning Phase tasks are complete, the team must formally agree that the project has reached the Project Plans Approved Milestone. By completing the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
As before, project teams usually mark the completion of a milestone with a formal sign-off, including sign-offs by the customer and other key stakeholders. The sign-off document becomes a project deliverable and is archived for future reference.
Building
When the Planning Phase milestones have been met, the next phase—Building—begins. The first step in building the deployment is creating and testing the solution.
The Developing Phase
The Developing Phase is the period during which the team builds and unit-tests the solution. The Developing Phase culminates in the Scope Complete Milestone, indicating that the solution is ready to be tested (piloted) in production.
Key Tasks
Table 7 lists key developing tasks and deliverables and their owners.
Table 7. Developing Phase Key Tasks, Deliverables, and Owners
|Key tasks |Deliverables |Owners |
|Starting the development cycle |Distribution server for the development work |Development |
|Creating and testing application |Mitigation strategies and mitigation packages |Development |
|mitigation packages and strategies | | |
|Preparing the computing environment |A computing environment ready for development work|Development |
|Developing the solution scripts |A configured imaging and distribution server with |Development |
| |updated script, Windows Vista, and applications; | |
| |disk images | |
|Developing security configuration |Security configuration files and Windows Firewall |Development |
| |configuration | |
|Developing core and supplemental |Core applications packages, including the |Development |
|application packages |2007 Office system, and supplemental applications | |
| |packages | |
|Developing USMT configuration files and |USMT configuration files and test cases |Development; Test |
|test cases | | |
|Developing deployment procedures |Deployment procedures |Release Management; User |
| | |Experience |
|Developing operations procedures |Operations procedures |Release Management; User |
| | |Experience |
|Creating test cases and scenarios |Test cases and scenarios |Test |
|Testing the solution |A solution ready for piloting |Test |
|Approving the key milestone: scope |All Developing Phase work complete |All roles |
|complete | | |
Team Focus
Table 8 outlines the primary activities of each team role during the Developing Phase.
Table 8. Developing Phase Role Clusters and Focus
|Role Cluster |Focus |
|Product Management |Managing customer expectations |
|Program Management |Managing the functional specification |
| |Project management |
| |Updating plans |
| |Application mitigation strategies and application packages |
| |Security configuration |
| |USMT configuration files |
|Development |Script creation |
| |Infrastructure development |
| |Documentation |
| |Image creation |
|Test |Test lab, test scenarios, and test cases |
| |Functional testing |
| |Issues identification |
| |Documentation review |
|User Experience |Training |
| |Usability testing |
|Release Management |Deployment checklists, updated pilot plans |
| |Site preparation checklists |
| |Operations plans |
IT Operations and the Security feature team are included in the assessments to ensure that an accurate view of their respective areas is addressed. The user community is included to ensure that the plans and designs being compiled are consistent with its needs.
Feature Team and Job Aid Documents
The following documents will be useful in the Developing Phase:
• Functional specification (See “Creating the Functional Specification” earlier in this guide.)
• Risk assessment (See “Creating the Risk Assessment Document” earlier in this guide.)
• Application Compatibility Feature Team Guide
• Computer Imaging System Feature Team Guide
• Deployment Feature Team Guide
• Desired Configuration Monitoring Feature Team Guide
• Infrastructure Remediation Feature Team Guide
• Operations Readiness Feature Team Guide
• Security Feature Team Guide
• Test Feature Team Guide
Starting the Development Cycle
The solution script includes files and programs used to create a generic installation architecture for Windows and the 2007 Office system and easily customize it to meet the organization’s needs. The script includes software teams can use to set up an imaging server and customize boot CDs that are used to begin the installation process on individual computers and tools teams can use to prepare the system for creating hard disk images for distribution throughout the organization. Teams must have licensed copies of Windows and the 2007 Office system and, depending on the scope of the project, sufficient licenses for any other software needed to carry out the project.
It is generally a good idea to divide the development work into several periodic builds that the team can thoroughly test as independent units before the entire scope of work is complete. This process helps the project remain on track by providing short-term checkpoints, at which the team can assess progress and make changes, if necessary. It also helps minimize the impact and cost of issues by bringing them to light sooner in the development process.
Using Interim Builds
Infrastructure development is the process of using regular, or interim, builds to convert functional specifications and plans into a complete, deployment-ready solution. Using interim builds, teams can find issues earlier than if they waited until the end of the Developing Phase to build the solution. In addition, the Test feature team becomes involved in the development process earlier, which shortens the development cycle and lowers the cost of the project.
The team should use interim builds as synchronization points where developers check in the scripts they believe are ready for testing. The developers submit portions of the solution to the Test lead, who assembles the build and tests it while the developers continue to work on additional script components.
The first interim builds should be fairly simple—for example, an unattended installation of Windows and the 2007 Office system on a single computer with the UI customized for the environment. Subsequent builds should add support for additional hardware and any additional functionality until the final interim build before the pilot, which should incorporate all the functionality dictated by the functional specification.
Figure 6 is a flowchart illustrating the unattended installation development process as an example of an interim build.
[pic]
Figure 6. The unattended installation development process
Creating Issue-Tracking Procedures
The team uses issue tracking to manage risk and help build an effective solution. An issue is anything in the solution that negatively affects its ability to perform as specified—in short, a bug. Issues can occur almost anywhere in the solution and can include problems such as defects in the solution scripts, missing or obsolete device drivers, and incompatibilities between script components.
The team cannot successfully move past the Developing Phase until every known issue is resolved. To resolve the issue, the team does not necessarily have to fix it. For example, the issue may be of sufficiently low priority that the team elects to defer action until a later version of the solution or not to act on it at all.
Testers document issues as they find them. Each tester should add issues to the issue-tracking mechanism, with an estimation of the severity of that issue and a description of the steps necessary to reproduce it. Estimate the severity by using a numeric scale, typically from 1 to 4, with 1 being the most severe and 4 being the least severe. As with the risk-management practices the teams have been using throughout the project, this approach enables the Development Role Cluster to prioritize issues and rank them according to impact so that the developers can address the most severe issues first.
The Development lead prioritizes the issue using a similar scale. Then the lead assigns it to the developer responsible for that feature for resolution. The worst possible issue is one with a severity of 1 and a priority of 1. This is an issue that crashes the solution and must be tracked down and resolved.
The information the tester documents during the issue-tracking process is invaluable to the training and support staff. It shows them the history of the solution, the problems encountered during development, and the resolution.
A well-implemented issue-tracking system does not have to be custom-built. At the low end, a spreadsheet program such as Excel can serve to track issues and rank them by severity and priority. With a little more work, teams can use a database application such as Microsoft Office Access to build a database with custom fields for easier and more accurate data entry. Or if time, resources, and the nature of the project permit, teams can tailor a dedicated issue-tracking program or build one from scratch. The issue-tracking database becomes a permanent part of the project and is a deliverable of the Developing Phase.
The Development and Test Role Clusters should meet regularly to review issues and plan strategies for resolving them. A well-designed issue-tracking system is of little use without a good review process.
Preparing the Computing Environment
Most feature teams need a lab environment. Although separate labs could be constructed for each feature team, most organizations create a single lab that shares facilities such as servers, networking, system backup, and data repositories (such as Visual SourceSafe), with separate workspaces (computers and network shares) for each feature team. This enables the teams to work separately when necessary and jointly when appropriate. In addition, the organization can minimize the number of computers and servers required.
Developing the Solution Scripts
If the project has been sufficiently envisioned and planned, developing the solution scripts does not have to be an especially difficult or lengthy process, but it does need to be well coordinated. Several basic functions relating to development occur at this stage. Among them are:
• Application packaging.
• Application remediation.
• Data retention.
• Creating computer images.
• The deployment process.
Application Packaging
For the migration to be successful, users must have all the applications they need installed and ready to go. These applications must be packaged so that the scripted installation process can successfully install and configure each required application.
Using the information obtained during the Envisioning and Planning Phases when the application compatibility remediation tool was run, the developers have a list of applications that require packaging for automated installation and configuration. These are typically the items requiring the longest lead time. It is common for an organization of 5000 to10,000 computers to have 1000 applications or versions of applications that require packaging. Acquiring the software is also a time-consuming task. The earlier this task is started, the more efficient the process will be.
In addition, it is beneficial to identify an SME for each application. SMEs are usually power users from the organization who have deep knowledge of the application and how it should be configured and who can validate that the application is working correctly. SMEs aid the developers in determining how best to install and configure each application.
This is an excellent time in the project to review these applications, consolidate those that are redundant, and standardize the enterprise on fewer applications. For example, it is less expensive and easier to support one word-processing application or version of an application than it is to support two or three. It also facilitates easier sharing of documents across the enterprise if everyone is using the same application version.
The application packages created during this phase are further validated in the Stabilizing Phase and are used in the Deploying Phase of the project.
Note Refer to the Application Management Feature Team Guide for information about how to package applications.
Application Remediation
Using the information obtained from the Envisioning and Planning Phases when the application compatibility remediation tool was run, developers have a list of applications installed in the enterprise. They must research and evaluate each application to ensure that it functions under the new operating system. In some cases, the analyzer tool provides information about the compatibility state of an application; in other cases, developers must either research the application through the vendor who wrote it or load and test it on Windows. For applications that will not function correctly under Windows, develop a plan for managing these applications.
Note For information about how to use the analyzer tool to test and remediate incompatible applications, see the Application Compatibility Feature Team Guide.
Data Retention
During the Developing Phase, the developers review the lists of applications that are to be redeployed with an eye toward capturing user data files and application settings. They use the User State Migration Feature Team Guide to customize the configuration files that USMT uses to ensure that the proper data files as well as the application and user-preference settings are captured and restored during the Deploying Phase of the project.
Creating Computer Images
While some development teams are busy addressing applications and data retention, the Computer Imaging System feature team has the task of creating the computer images that will be used throughout the enterprise during the Deploying Phase. They will use the Computer Imaging System Feature Team Guide to build the imaging server, create startup CDs, and then create the deployable Windows images. They will customize the imaging process to reflect the business requirements that are defined in the functional specification.
These developers may also be engaged early in the project to assist with creating prototypes of images or computers. It is often beneficial to have a model computer present when discussing the components of the functional specification in the Planning Phase so that the team can evaluate the look and feel of a particular configuration.
Deployment Process
The developers working on the deployment process focus mainly on integration issues. They help define the preset options used in the deployment wizard, validate that the deployment process works with various images, and ensure that all the network shares, credentials, and other components are working properly.
They use the technical guidance on the imaging and deployment processes to guide their work. They also work closely with the Release Management Role Cluster.
Documenting the Development Process
When creating the development plan in the previous phase, the team should have specified the configuration documents that it would have to create during the Developing Phase. Typically, these would include documents describing the:
• Configuration of the unattended installation architecture.
• Deployment architecture.
• Configuration of Windows.
• Configuration of the 2007 Office system.
• Data-reclamation process.
• Application-packaging process.
• Application-remediation process.
• Specific hardware configurations to be deployed.
Teams must document their work as they continue through the Developing Phase. Teams are not only building the solution but also creating processes and procedures that others must follow when testing and deploying the solution. Documents to create can include:
• A checklist that IT personnel can use to perform an unattended installation from start to finish.
• Any site deployment checklists provided for in the development plan.
• Procedures for creating hard disk images to aid in deployment.
• Documents to help test the solution.
Developing Deployment Procedures
For a successful deployment, several kinds of documents are necessary. These include training and communications materials and site deployment and operations procedures.
Creating Site Deployment Procedures
Deployment procedures help carry out the deployment with greater efficiency. Creating a checklist of tasks for each site Deployment feature team to perform can help simplify and standardize the process of deploying the solution across sites. The pilot provides an opportunity to review and revise the deployment procedures.
Creating Communications Materials
Follow the communication plan, revising it as necessary to incorporate new developments in the project. The Product Management Role Cluster takes the lead in communicating with the customer. The User Experience Role Cluster takes the lead in communicating with users. The Release Management Role Cluster takes the lead in communicating with IT personnel. Rely on experienced people with good communications skills to drive this process.
Creating Training Materials
Before the team deploys the solution to the pilot group, it should develop the training materials provided for in the training plan and use the opportunity to pilot the training materials as well as the solution. Follow the training plan, revising it as necessary to incorporate new developments in the project.
Developing Operations Procedures
System administrators use operations procedures to support, maintain, and operate the solution. The Release Management Role Cluster takes the lead in developing these procedures, which should be in place by the time the team pilots the solution. Several of the plans in the project plan, including the deployment and training plans, can help develop operations procedures.
Deploying Windows and the 2007 Office system requires changes in the management of client computers and servers. The operations procedures should address ongoing desktop support in light of these changes.
Procedures to create can include:
• Maintenance procedures, including the proper care of client, server, and enterprise components.
• Disaster recovery after primary deployment, including contingency plans for reinstalling distribution servers and restoration from backups.
• New site installation procedures, with instructions on installing a new distribution server or Windows-based computer from scratch.
• Performance and fault-monitoring procedures, explaining what IT personnel should be aware of and pay close attention to when the technology is being deployed and afterward.
• Support and troubleshooting procedures for keeping baselines available and safe from changes so that the operations team can return to a known state when necessary.
Testing the Solution
Testers should follow the test plan to identify issues for other members of the team to resolve. Use the issue-tracking procedures created during the Planning Phase to document issues.
Approving the Key Milestone: Scope Complete
The Developing Phase culminates in the Scope Complete Milestone. At this milestone, all features are complete and the solution is ready for external testing and stabilization. This milestone gives customers and users, operations and support personnel, and key project stakeholders an opportunity to evaluate the solution and identify any remaining issues that must be addressed before beginning the transition to stabilization and ultimately to release.
Developing Phase Checklist
Before proceeding to the next phase, the Stabilizing Phase, verify that the following have been completed:
• Application mitigation packages and strategies created
• Application packages created
• Computer images created
• Core application packages, including the 2007 Office system, created
• Deployment procedures developed
• Frozen functional specification approved
• Operations procedures developed
• Risk-management plan updated and reviewed
• Security configuration files and Windows Firewall configuration
• Source scripts and executables for all deliverables created
• Test cases and scenarios created
• Test specifications and plans developed
• Test lab prepared
• Unit-tested proof of concept completed
Moving to the Stabilizing Phase
After all the developing tasks are complete, the team must formally agree that the project has reached the Scope Complete Milestone and that the solution is ready for general testing. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
As before, project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference.
The Stabilizing Phase
The Stabilizing Phase addresses the testing of a solution that is feature complete. This phase is typically when pilots are conducted, with an emphasis on real-world testing and with the goal of identifying, prioritizing, and fixing bugs.
Key Tasks
Table 9 lists key Stabilizing Phase tasks and deliverables and their owners.
Table 9. Stabilizing Phase Key Tasks, Deliverables, and Owners
|Key tasks |Deliverables |Owners |
|Conducting the pilot |Test case results and bug reports |Test |
|Application-mitigation strategies |Tested mitigation strategies |Test; Release Management; Development |
|tested, issues resolved, and results | | |
|reported to management | | |
|Operational readiness review |Operational readiness acceptance |Release Management |
|Final release |Final images and process |Development |
|Approving the key milestone: Release |All Stabilizing Phase work completed |All roles |
|Readiness Approved | | |
Team Focus
Table 10 outlines the primary activities of each team role during the Stabilizing Phase.
Table 10. Stabilizing Phase Role Clusters and Focus
|Role Cluster |Focus |
|Product Management |Communications plan execution |
| |Deployment launch planning |
|Program Management |Project tracking |
| |Bug management |
|Development |Bug resolution |
| |Script optimization |
| |Application mitigation strategies |
|Test |Unit, functional, and integration testing |
|User Experience |Training materials |
|Release Management |Pilot management and support |
| |Deployment planning |
| |Operations and support training |
| |Application mitigation strategies |
IT Operations and the Security feature team are included in the project discussions to ensure that an accurate view of their respective areas is addressed.
Feature Team Documents and Job Aids
The following documents, useful in the Stabilizing Phase, are included in this solution:
• Test Plan (job aid)
• Risk Assessment (job aid)
• Deployment Plan (job aid)
• Application Compatibility Feature Team Guide
• Application Management Feature Team Guide
• Computer Imaging Systems Feature Team Guide
• Deployment Feature Team Guide
• Desired Configuration Monitoring Feature Team Guide
• Infrastructure Remediation Feature Team Guide
• Operations Readiness Feature Team Guide
• Security Feature Team Guide
• Test Feature Team Guide
• User State Migration Feature Team Guide
Testing the Solution
Testers should follow the test plan to identify issues for other members of the team to resolve. Use the issue-tracking procedures created during the Planning Phase to document issues.
Identifying Testing Tasks
A matrix of testing tasks can be an efficient tool for identifying testing tasks and assigning them to different testers. If the Test feature team developed a test matrix as part of the test plan, it should take this opportunity to revisit and expand the matrix. If the testers have not created a matrix, they should create one now.
Divide the testing tasks by functional area. For example, the Woodgrove project team divided its test matrix into tasks related to the following:
• The deployment server
• The imaging/build server
• The boot CD-ROM
• Windows baseline installation
• Windows configuration
• Windows logon
• Windows functionality
• The 2007 Office system
• Computer hardware settings
• Hard disk–based image installation and configuration
• Windows DS–based image installation and configuration
• Deployment process testing (such as backup, USMT, and application installation)
Conducting the Pilot
The solution is ready for the pilot deployment as soon as a full build has been completed and passed testing. Follow the pilot plan, revising it as necessary to incorporate new developments in the project. Use the communications and training materials developed to keep users informed as to the nature and progress of the pilot. A well-planned pilot of a sufficiently tested solution should present few surprises.
Although the team will not have deployed the solution to the full production environment at this point, it must have at least part of the support structure in place to deal with issues arising from the pilot, with support personnel standing by to assist users.
Collecting User Feedback
Tell users how long the feedback period will last and how to communicate their comments. Process the feedback according to the Pilot plan. If the teams have been using an issue-tracking database throughout development, they should continue its use during the feedback period to record issues that users uncovered.
When customer and user feedback indicates that the pilot is working, have the team review the work that has been performed during this phase, and then proceed to the Deploying Phase.
Interim Milestones
The Stabilizing Phase of the MSF Process Model contains interim milestones. Use the information and techniques in this guide to complete each milestone in the order provided. Following these milestones in order ensures the gradual development, testing, and stabilization of the solution. The two interim milestones in the Stabilizing Phase are:
• Pilot Readiness Review Complete. To complete this milestone, the project team must expose the (now almost complete) solution to representatives of the various groups that will interact with the solution while it is still in the development environment. For example, the deployment group, the support group, and the proposed users of the solution are typical candidates.
• Deployment Readiness Review Complete. To complete this milestone, the project team moves the now completed and frozen solution to a limited release in the production environment. This dress rehearsal for the project team helps it practice the full deployment of the solution.
Approving the Key Milestone: Release Readiness Approved
The Stabilizing Phase culminates in the Release Readiness Approved Milestone. This milestone occurs when the team has conducted a successful pilot, addressed all outstanding issues, released the solution, and made it available for full deployment. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues they must address before deployment.
Stabilizing Phase Checklist
Before proceeding to the next phase, the Deploying Phase, the following items should have been addressed:
• Final release of images and process
• Project documents and release notes
• Approved operational readiness review
• Source scripts and executables for all deliverables
• Computer images
• Application packages
• Tested application-mitigation strategies and packages
• Test case results and bug reports
• Deployment procedures
• Operations procedures
Moving to the Deploying Phase
After all the Stabilizing Phase tasks are complete, the team must formally agree that the project has met the Release Readiness Approved Milestone and that the solution is ready for general release. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
As before, project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document becomes a project deliverable and is archived for future reference.
Deploying
When the final milestones for the Building Phase have been met, the Deploying Phase begins, starting with the initial deployment.
The Deploying Phase
The Deploying Phase is the period during which the team deploys the solution and ensures that it is stable and usable. The Deploying Phase culminates in the Deployment Complete Milestone, at which point responsibility for the solution shifts to IT Operations and the support teams.
Key Tasks
Table 11 lists key Deploying Phase tasks and deliverables and their owners.
Table 11. Deploying Phase Key Tasks, Deliverables, and Owners
|Key tasks |Deliverables |Owners |
|Deploying core technology |Deployment servers at each location |Release Management; User Experience; |
| |have been installed, configured, and |Test |
| |tested; administrative staff have been | |
| |trained | |
|Deploying sites |All computers at each site have been |Release Management; User Experience; |
| |fully installed, configured, and |Test |
| |tested; users have been trained | |
|Stabilizing the deployment |All computers are stable and have been |All roles |
| |measured against the project success | |
| |criteria | |
|Completing the deployment |IT Operations and support staff have |All roles |
| |assumed responsibility for all | |
| |computers; all roles sign off on the | |
| |Deployment Complete Milestone; the | |
| |customer is satisfied with the | |
| |deployment as indicated in writing | |
Team Focus
Table 12 outlines the primary activities of each team role during the Deploying Phase.
Table 12. Deploying Phase Role Clusters and Focus
|Role Cluster |Focus |
|Product Management |Customer feedback and sign-off |
|Program Management |Stabilization management |
|Development |Problem resolution |
|Test |Test case results and issue tracking |
|User Experience |Training |
|Release Management |Deployment management; change approval |
Feature Team and Job Aid Documents
The following documents are used in the Deploying Phase:
• Deployment Plan (job aid)
• Application Compatibility Feature Team Guide
• Deployment Feature Team Guide
• Desired Configuration Monitoring Feature Team Guide
• Infrastructure Remediation Feature Team Guide
• Test Feature Team Guide
• User State Migration Feature Team Guide
Deploying Core Technology
Deploying the core systems and services that support the client deployments is a key step in the Deploying Phase and includes updating the deployment plan and establishing deployment servers.
Updating the Deployment Plan
If the team has properly planned and developed the solution, deployment should be a routine activity. During the Envisioning Phase, teams assessed and documented the current computing and networking environment, including information about domains and physical locations. During the Planning Phase, teams created the deployment plan with more specific and up-to-date details about deployment. Now that development activities are finished, the teams must update the deployment plan again with the most current information they have and use it to deliver the solution to their users.
Establishing Deployment Servers
Teams must establish servers to hold the images unless they plan to format all hard disks at a central location and ship them to the different sites covered in the project. Many projects, therefore, require that the team establish one or more deployment servers to be used in deployment. These servers can contain disk images, solution scripts to be used in the deployment process, and applications to be installed for specific users, as well as backup copies of user data and entire system backups. The team should have specified distribution server placement in the Planning Phase. Review this plan and update it, if necessary.
Deploying Sites
With site deployments, the project team completes the final step in the process of bringing the solution to the users. Deployment personnel visit each site and use the selected delivery vehicle (disk images or unattended installation from distribution servers) to install Windows and associated applications on each targeted computer.
For the purposes of deployment, the team should consider each site separately and independently because different sites may have unique requirements that make a strict overall deployment strategy impractical. Treat each site as a miniature deployment project that requires its own preparing, installing, training, and stabilizing stages.
Site Deployment Strategies
Site deployments necessarily involve trade-offs, which carry certain risks. The team should take the schedule, resource availability, and project scope into account and use MSF concepts such as the trade-off triangle when making decisions about the site deployment strategies to use. To minimize risk, the team should decide during the Envisioning and Planning Phases which deployment strategies to use before beginning any deployment-related tasks.
The team may also choose to deploy the solution to sites serially or in parallel. In a serial deployment, the Deployment feature team performs all deployment tasks at one site, then moves to the next site, and so on. Serial deployments generally require fewer resources and cost less but typically take longer than comparable parallel deployments. In a parallel deployment, the Deployment feature team performs all deployment tasks at all of the sites at the same time. Parallel deployments cost more because of the additional resources they require (including staff at each location), but the team can complete them more quickly.
Another trade-off to consider involves preplanning a deployment versus using just-in-time planning. Preplanned deployments, in which the team conducts site surveys to plan the deployments in advance, are preferable to just-in-time deployments, in which the team members plan each deployment as they arrive at the site. However, the just-in-time approach is sometimes necessary in situations in which the sites are not easily accessible ahead of time.
Preparing for Site Deployment
Site deployment involves three distinct activities:
• Inventorying. Validating the information collected for the deployment plan or, if appropriate, conducting a new site survey
• Scheduling. Finalizing a schedule and timeline for the installation process
• Informing. Letting the site know when the deployment will occur, then using the strategy in the communications plan
The Release Management Role Cluster takes the lead in performing these preparatory tasks, which can usually be performed off-site. Perform all three of these activities for each site included in the deployment.
Performing Installations
The team does not install the solution until all preparatory activities are complete, thereby minimizing both disruption to the users and confusion over the process. In some cases, last-minute issues discovered during the preparatory phase may indicate a need to revisit the site later after issues are resolved.
Installing the solution should be one of the least complicated parts of the deployment project. If the team has accounted for all the computers and peripherals to be affected by the deployment and planned accordingly, it should encounter few, if any, surprises.
If the Deployment feature team encounters errors along the way, it should log them using its preexisting issue-tracking system and resolve them as quickly as possible. Depending on the nature of the issue, the development feature team may have to revise the solution scripts and perhaps create new disk images.
Stabilizing the Site Deployment
Stabilization is an important part of the site deployment process. It is the responsibility of the Deployment feature team to remain with the project until it is comfortable putting the solution into production.
Ensure that the system is stable while the Deployment feature team and any associated resources are still on-site. To do this, the team must focus on the success criteria as defined by the vision and scope and collect feedback, using the mechanisms defined in the deployment plan.
As with site installation, the Deployment feature team should stabilize each site individually, treating each as an autonomous unit. After all the sites are stable, the team can move on to consider the stability of the project as a whole.
Stabilizing the Deployment
It can be difficult to determine when a deployment is complete so that the team can close the project. Newly deployed systems are often in a constant state of flux, undergoing a continuous process of identifying and managing production support issues. The team can find it difficult to close the project because of ongoing issues that will surface after deployment. For this reason, the team needs to clearly define a completion milestone for the deployment. If the team does not perform a complete transition to a production operations and support system, it will not be able to disengage from the project or focus on closing it.
If the organization expects members of the project team to be involved in ongoing maintenance and support, those members should move into a new role as part of the operations and support structure after the project closes. At this late stage, team members not involved in operations and support will likely begin to leave the project.
Completing the Deployment
Upon completion of client system deployment, focus turns to transitioning the deployment to the customer and support staff.
Making the Transition to IT Operations and Support
Part of disengaging from the project includes moving operations and support functions to permanent staff. In many cases, the resources to manage the new systems will already exist. In other cases, designing new support systems may be necessary. Given the scope of designing new support systems, it may be wise to consider it a separate project.
Tasks to perform when making the transition to IT Operations and support teams include:
• Activating reporting systems to refer inquiries and help requests to appropriate operations and support personnel.
• Publishing a knowledge base to provide operations and support staff with access to information and documentation related to the project. For example, provide the issue-tracking and change-control databases to give operations and support information about the history of the project and the team’s decision-making process.
Signing Off on the Project
After all the deployment tasks are completed, the team must formally agree that the project has met the Deployment Complete Milestone and that project work is finished. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
As before, project teams usually mark the completion of a milestone with a formal sign-off. The sign-off document becomes a project deliverable.
Obtaining Customer Sign-Off
Upon project closure, the product manager obtains the final sign-off from a representative of the customer or organization, signaling approval of the solution and permission for the team to disengage from the project. Although at this point the team is busy informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgment that the project is complete.
Key Milestone: Deployment Complete
Before completing this phase, the following items should have been accomplished:
• Acceptance of responsibility for operations and support by IT Operations
• Project sign-off received
Closing the Project
The deployment does not end when the last client system is deployed. Closing the project involves a handful of steps that complete the transition to the customer and provide guidance for the Deployment feature teams of future projects.
Note The role of BDD 2007 does not end after the deployment project transitions to IT Operations. The team can maintain the distribution shares to keep them current. For example, computer deployments performed as part of daily operations benefit from having updated device drivers, security updates, core applications, and so on.
Conducting the Project Review
When the project is complete, the project team should hold a review meeting to discuss the project and identify what went well, what did not go well, what to replicate in future projects, and what to change. Without assigning blame, the members conduct the project review with the goals of learning from mistakes and improving future projects. Often called a postmortem, the project-review meeting sometimes takes place shortly before the end of the project rather than afterward, because team members often must leave the project shortly before it ends. The team must therefore conduct the meeting before customer sign-off.
The team documents suggestions for change as action items in the next project plan, if one is scheduled.
Producing the Close-out Report
The closeout report is the final physical deliverable of the deployment. It includes final versions of all the major deliverables: the vision/scope document, the functional specification, and so on. The product manager and program manager take the lead in compiling the close-out report, which the team and customer can use as a quick reference to the work performed during the project and as a basis for future planning. The closeout report also includes a summary of information solicited from the users and a summary of the next known steps.
Looking Ahead
The versioned-release concept means that the completion of one project is often a prelude to the next, in which the solution is iteratively built on and improved. Bearing in mind that resource, strategic, or other concerns may prevent or limit any immediate follow-ups to the just-completed desktop deployment, there are several possible next steps.
Although it is theoretically possible that the organization will be completely satisfied after the conclusion of the project and see no need for further change, most IT managers are constantly looking for ways in which the computing environment can be improved. The most immediate areas of concern will probably be the portions of the vision that were excluded by the scope of the just-completed project and that can be implemented in a future project as a versioned release. In a larger sense, remember that technology life-cycle management is ongoing and requires a long-term view, both of the state of computing technology and of the requirements of the organization itself.
The first order of business, then, will probably be to plan and conduct an updated enterprise deployment and life cycle management review to collect knowledge about the current state of the computing environment. The organization can then use that information to envision and plan future project work.
Note In the future, each computer in the organization will be retired from service. The organization should develop a process in which retired computers are moved to known locations, data on their hard disks and BIOS is securely wiped, and asset information is updated. In many countries and regions, computers are considered hazardous waste and must be disposed of properly.
Appendix A: Planning
Planning a Windows and 2007 Office system deployment involves two key phases that are explored in detail in the “Planning” section of this document. These phases, which include the Envisioning and Planning Phases, are summarized in this appendix.
Envisioning
The initial phase of the planning process involves envisioning the deployment project and determining goals and expected outcomes. This phase comprises several key steps:
• Set up teams. The initial task is to define the teams that plan, design, and accomplish the deployment. These teams are defined by their roles, which include Product Management (identify customer needs and requirements), Program Management (document design goals, solution concept, and project structure), Development (create prototypes, evaluate development and technology options, and perform feasibility analysis), Test (testing strategies, testing criteria, and reporting), User Experience (user education and implications), and Release Management (deployment consideration, operations management and supportability, operational acceptance, network discovery, application and hardware inventory, interfacing with operations and security).
• Perform a current assessment. This crucial step includes identifying existing systems and applications, determining existing operating systems, and identifying deficiencies in the current environment that the Windows and 2007 Office system will address. The Release Management Role Cluster generally takes the lead in this step.
• Define business goals. The need for the deployment should be driven by concrete and quantifiable business goals. Rather than simply planning to deploy the latest technology for technology’s sake, identify key deficiencies in the existing system that Windows and 2007 Office system will address as well as process and productivity gains to be made possible through the deployment.
• Create vision statement and define scope. Create a vision statement a paragraph or two long that defines how planned technology changes (including the Windows/2007 Office system deployment) will meet the defined business goals. The scope determines the extent of the vision that can be accomplished through the Windows and 2007 Office system deployment.
• Create user profiles. Develop an accurate and complete picture of users’ functions, needs, and wants. Refine these into user profiles that accurately identify the types of users in the organization. Understanding the users and what they need is the first step in determining how to structure the deployment to benefit the most users.
• Develop a solution concept. Create this high-level document to define how the team will meet the requirements of the project. The Project Management Role Cluster should take the lead in developing this two- to three-page document that explains how the deployment will be accomplished and evaluated.
• Create risk-assessment documents. In this step, carefully evaluate the overall deployment with the intent to anticipate, address, mitigate, and prevent risks associated with the deployment. Risk assessment and documentation is an ongoing task throughout the Planning and Deploying Phases.
• Write a project structure. This document details how the team manages and supports the project and describes the administrative structure for the project team going into the Planning Phase. This document should define the standards the team will use, methods of communication, documentation standards, and change-control standards.
• Approve milestones. With the initial planning and documentation complete, identify and schedule key milestones for the deployment.
Planning
The Envisioning Phase creates the framework for the Windows and 2007 Office system deployment. The next phase, Planning, serves as a transition between vision and implementation, laying the groundwork for the actual deployment. The Planning Phase uses the documents and processes created in the Envisioning Phase to add structure and content to the deployment plan. Key tasks for this phase include:
• Create the development and testing environment. Build a testing lab that adequately embodies the target deployment environment, using virtualization to reduce the cost of lab creation. In addition to resources such as servers and sample target systems used to develop and test the deployment, the lab should also include the resources the Deployment feature team will use to prepare and accomplish the final deployment.
• Develop the solution design. This document builds on the solution concept, project structure, and other documents created during the Envisioning Phase to define the conceptual, logical, and physical solution designs for the planned deployment. This document serves as a roadmap for the Deployment feature team to begin building the deployment.
• Create the functional specification. This document defines the requirements of all stakeholders targeted by the deployment and serves as a contract between the customer and the project team. It should clearly define the goals, scope, and outcomes of the deployment.
• Develop the project plan. This document is a collection of plans that address the tasks the Deployment feature team will perform to carry out the project as defined by the functional specification. Each plan in this document covers a particular area, such as facilities and hardware, testing, training, and communication.
• Create the project schedule. This schedule compiles individual schedules created by team members for the purpose of planning deployment activities.
• Complete a computer inventory. During the Planning Phase, a complete computer inventory must be made to identify existing systems and applications that the deployment will affect. In addition, the server resources to be used for deployment must also be identified and evaluated for suitability.
• Perform network analysis. Diagram network topology and identify and inventory network devices.
Appendix B: Building
Upon completion of the Planning Phase, the Deployment feature team can begin the process of building the solution. This process includes preparing the environment, completing the packaging of applications and creation of operating system images, performing test deployments, creating and completing deployment documentation, and more.
Building consists of two primary phases: Developing and Stabilizing. The following sections summarize these two phases.
Developing
The Developing Phase is the period during which the team builds and unit-tests the solution. The Developing Phase culminates in the Scope Complete Milestone, indicating that the solution is ready to be tested (piloted) in production.
The Developing Phase of building the deployment encompasses seven key tasks. These tasks include:
• Start the development cycle. In this initial step, the team creates a distribution server for development work and begins the process of creating images, installation scripts, and application packages. The team should also create an issue-tracking system to enable team members to communicate about and coordinate solutions to issues that arise during development.
• Prepare the computing environment. In this key task, the teams build a deployment environment with facilities such as servers, networking, system backup, and data repositories (such as Visual SourceSafe) with separate workspaces (computers and network shares) for each feature team. This environment provides the infrastructure for teams to work independently and jointly as necessary to complete their development tasks.
• Develop the solution scripts. In this step, the teams begin the process of packaging applications, creating computer images, and developing remediation steps for application-compatibility issues. The teams also plan how and what user data will be retained and migrated during the deployment and validate that network infrastructure (shares, credentials, and other components) are in place and functioning properly prior to deployment.
• Develop deployment procedures. Using the documents, processes, and other resources created to this point, begin creating the documents the teams will use to accomplish the deployment and post-deployment tasks. These documents include training materials for users as well as administrators and others who will maintain systems and applications after deployment; a plan for communicating with users about the upcoming changes; and site-deployment procedures to simplify and standardize the deployment of solutions across sites.
• Develop operations procedures. This document details the operations procedures to support, maintain, and operate the solution following deployment. Key processes to be detailed include maintenance, disaster recovery, new site installation, performance and fault monitoring, and support and troubleshooting.
• Test the solution. Perform test deployments and remedy any issues that arise, using the issue-tracking framework created during the Planning Phase to monitor and address these issues.
• Approve the key milestone: Scope Complete. All features are complete, and the solution is ready for external testing and stabilization. This milestone gives customers and users, operations and support personnel, and key project stakeholders an opportunity to evaluate the solution and identify any remaining issues that must be addressed before beginning the transition to stabilization and ultimately to release.
Stabilizing
The Stabilizing Phase addresses the testing of a solution that is feature complete. This phase is typically when pilots are conducted, with an emphasis on real-world testing and with the goal of identifying, prioritizing, and fixing bugs. Key tasks in this phase include:
• Conducting the pilot. At this stage, a small pilot deployment enables the teams to test the deployment and identify any remaining issues. Procedures, resources, and personnel should be in place to assist in addressing any user issues that arise during the pilot deployment. This key task should also include obtaining user feedback as well as review and remediation of issues identified during the pilot.
• Operational readiness review. All teams at this stage perform a complete operational-readiness review to determine that the deployment plan is ready to move forward to full-scale deployment. The solution is frozen at this stage, and any remaining issues are addressed.
• Final release. This task incorporates all fixes and issue resolutions to create the golden release of the solution, which should now be ready for full deployment.
• Approve the key milestone: Release Readiness Approved. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues they need to address before deployment.
Appendix C: Deploying
During the Deploying Phase, the team deploys the solution and ensures that it is stable and usable. The Deploying Phase culminates in the Deployment Complete Milestone, at which point responsibility for the solution shifts to the operations and support teams.
The key tasks comprised by the Deploying Phase include:
• Deploying core technology. Based on the plans and procedures developed in the Planning Phase, install, configure, and test deployment servers at each location. Also, train administration staff in preparation for deployment.
• Deploying sites. Teams perform the deployment of Windows and the 2007 Office system at each site using the procedures and resources developed during the Planning and Building Phases. Team members remain on site to stabilize each site deployment, ensuring that users can move forward with reliable systems and applications and that the goals of the deployment plan for the site have been met.
• Stabilizing the deployment. At this key step, the Deployment feature team ensures stabilization across all sites and addresses any remaining deployment issues.
• Completing the deployment. This step marks the transition from deployment to operations and support. Ongoing operations are transitioned from the Deployment feature team to permanent staff. Reporting systems are activated, and troubleshooting and support processes are made fully operational.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- rate and service guide 2019
- chevy equinox build and price
- 2019 ups rate and service guide usa
- build and maintain customer relationships
- build and print free resume
- how to build and maintain relationships
- build and download resume for free
- ford superduty build and price
- things to build and sell
- cr build and buy
- build and price ford
- audi q3 build and price