Plan, Build, and Deploy Guide -...

Solution Accelerator forBusiness Desktop DeploymentPlan, Build, and Deploy Guide

Published: January 2007

For the latest information, please see http://www.microsoft.com/technet/desktopdeployment/default.mspx.

http://www.microsoft.com/technet/desktopdeployment/default.mspx

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 http://creativecommons.org/licenses/by-nc/2.5 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.

http://creativecommons.org/licenses/by-nc/2.5

ContentsIntroduction.....................................................................................1

The Problem..................................................................................................1The Solution..................................................................................................2

About MSF..............................................................................................2Using This Solution...........................................................................5

The Plan, Build, and Deploy Guide................................................................5The Feature Team Guides.............................................................................5The Job Aids..................................................................................................5The Solution Script Files................................................................................6Who Should Use This Solution?.....................................................................6Solution Updates...........................................................................................6The Sample Scenario....................................................................................6

Feature Teams........................................................................................7Communication.............................................................................................7

Communications Within Teams...............................................................7Communications Among Feature Teams and the Lead Team.................8Communications with Stakeholders.......................................................9

Scaling the Feature Team............................................................................10Additional Guidance on the MSF Team Model.............................................10

Scaling the Solution........................................................................11Small Organizations....................................................................................11Medium-sized Organizations.......................................................................12

Solution Architecture......................................................................15Process Overview........................................................................................16Inventory....................................................................................................18Application Installation Automation............................................................18Moving Toward Software State Restore.......................................................18Computer Imaging......................................................................................19Data and Settings Retention.......................................................................21Network Analysis........................................................................................22Deployment Process...................................................................................22

Implementing MSF..........................................................................23Planning.........................................................................................25

The Envisioning Phase................................................................................25Key Tasks..............................................................................................25Team Focus...........................................................................................26Interim Milestone..................................................................................26

iv Solution Accelerator for Business Desktop Deployment

Feature Team and Job Aid Documents..................................................27The MSF Team Model: Setting Up the Team..........................................27

Role Clusters..................................................................................27The MSF Team Model: Scaling Teams...................................................30

Assembling Small Teams................................................................30Assembling Larger Teams..............................................................31

The MSF Team Model: Assigning Team Members to Roles....................31Assessing the Current Situation...........................................................32The Vision/Scope Document.................................................................32Defining the Business Goals.................................................................33Defining the Vision and Scope..............................................................33

Creating the Vision Statement.......................................................33Defining the Scope.........................................................................34

Creating User Profiles...........................................................................34Developing the Solution Concept.........................................................35Writing a Project Structure...................................................................35

Planning Project Communication....................................................35Planning Documentation Standards...............................................35Planning Change Control................................................................36

Creating the Risk Assessment Document.............................................36Initial Assessment of Risk...............................................................36Potential Risks................................................................................37Learning More About Risk Assessment..........................................37

Key Milestone: Vision/Scope Approved.................................................37Envisioning Phase Checklist.................................................................38

The Planning Phase.....................................................................................39Key Tasks..............................................................................................39Team Focus...........................................................................................40Feature Team and Job Aid Documents..................................................41Establishing the Lab.............................................................................41Developing the Solution Design...........................................................42

The Design Process........................................................................42Conceptual Design.........................................................................43Logical Design................................................................................43Physical Design..............................................................................43

Creating the Functional Specification...................................................44Determining the Functional Specification Contents.......................44

Developing the Project Plan..................................................................45Creating the Development Plan.....................................................45

Plan, Build, and Deploy Guide v

Creating the Test Plan....................................................................46Creating the Deployment Plan.......................................................47Creating the Pilot Plan....................................................................47Creating the Communications Plan................................................48Creating the Training Plan..............................................................48Creating the Facilities and Hardware Plan......................................49Creating the Budget Plan...............................................................50

Creating the Project Schedule..............................................................50Creating Project Schedules............................................................50Assembling the Project Schedule...................................................51

Creating the Development and Testing Environment...........................52Interim Milestone: Technology Validation Complete.............................52Key Milestone: Project Plans Approved.................................................52Planning Phase Checklist......................................................................53Moving to the Developing Phase..........................................................53

Building.........................................................................................55The Developing Phase................................................................................55

Key Tasks..............................................................................................55Team Focus...........................................................................................56Feature Team and Job Aid Documents..................................................57Starting the Development Cycle...........................................................57

Using Interim Builds.......................................................................57Creating Issue-Tracking Procedures................................................58

Preparing the Computing Environment................................................59Developing the Solution Scripts...........................................................59

Application Packaging....................................................................59Application Remediation................................................................60Data Retention...............................................................................60Creating Computer Images............................................................60Deployment Process.......................................................................60

Documenting the Development Process...............................................60Developing Deployment Procedures....................................................61

Creating Site Deployment Procedures............................................61Creating Communications Materials..............................................61Creating Training Materials............................................................61

Developing Operations Procedures......................................................61Testing the Solution..............................................................................62Approving the Key Milestone: Scope Complete....................................62Developing Phase Checklist..................................................................62

vi Solution Accelerator for Business Desktop Deployment

Moving to the Stabilizing Phase............................................................63The Stabilizing Phase..................................................................................63

Key Tasks..............................................................................................63Team Focus...........................................................................................64Feature Team Documents and Job Aids................................................64Testing the Solution..............................................................................65Identifying Testing Tasks.......................................................................65Conducting the Pilot.............................................................................65Collecting User Feedback.....................................................................65Interim Milestones................................................................................66Approving the Key Milestone: Release Readiness Approved................66Stabilizing Phase Checklist...................................................................66Moving to the Deploying Phase............................................................66

Deploying.......................................................................................69The Deploying Phase..................................................................................69

Key Tasks..............................................................................................69Team Focus...........................................................................................70Feature Team and Job Aid Documents..................................................70Deploying Core Technology..................................................................70

Updating the Deployment Plan......................................................70Establishing Deployment Servers..................................................70

Deploying Sites.....................................................................................71Site Deployment Strategies...........................................................71Preparing for Site Deployment.......................................................71Performing Installations.................................................................72Stabilizing the Site Deployment.....................................................72

Stabilizing the Deployment..................................................................72Completing the Deployment.................................................................72

Making the Transition to IT Operations and Support......................72Signing Off on the Project...............................................................73Obtaining Customer Sign-Off.........................................................73

Key Milestone: Deployment Complete..................................................73Closing the Project.........................................................................75

Conducting the Project Review...................................................................75Producing the Close-out Report..................................................................75Looking Ahead............................................................................................75

Appendix A: Planning......................................................................77Envisioning.................................................................................................77Planning......................................................................................................78

Plan, Build, and Deploy Guide vii

Appendix B: Building......................................................................79Developing..................................................................................................79Stabilizing...................................................................................................80

Appendix C: Deploying......................................................................................81

IntroductionThe 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 http://go.microsoft.com/fwlink/?LinkId=78158.

http://go.microsoft.com/fwlink/?LinkId=78158

http://go.microsoft.com/fwlink/?LinkId=78158

2 Solution Accelerator for Business Desktop Deployment

The ProblemIn 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 SolutionThe 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.

Plan, Build, and Deploy Guide

3

About MSFMSF 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 http://www.microsoft.com/technet/itsolutions/msf.

http://www.microsoft.com/technet/itsolutions/msf

Using This SolutionThe 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 GuideThe 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 GuidesThe 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 AidsSeveral 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 FilesTeams 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 UpdatesThe 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 http://www.microsoft.com/technet/desktopdeployment for any updates concerning Windows deployments.

The Sample ScenarioThis 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

http://www.microsoft.com/technet/desktopdeployment


7includes 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 TeamsA 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 MigrationNote 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.


CommunicationKey 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 TeamsBy 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 TeamFigure 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.


9

Figure 1. Formal communication channels in the BDD 2007 project

Communications with StakeholdersFor 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 TeamThe 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 ModelFor additional guidance on the MSF Team Model, see the white paper, “MSF Team Model,” which is available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab.

http://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab

http://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab

Scaling the SolutionWhile 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 OrganizationsSmall 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 OrganizationsMedium 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.


13 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 ArchitectureThe 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 OverviewFigure 2 provides a high-level overview of the tasks that will be involved during the deployment process.

Plan, Build, and Deploy Guide 17

Figure 2. Overview of the deployment process


InventoryThe 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 AutomationTo 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 RestoreThe 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 ImagingBDD 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 Vista

Migrate to Windows Vista by using Windows Easy Transfer

Migrate to Windows Vista by using Microsoft Windows User State Migration Tool (USMT)

Migrate to Windows XP with SP2 by using 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 RetentionUsers 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 AnalysisBDD 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 ProcessBDD 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 MSFThe 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.

PlanningPlanning 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 PhaseThe 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 TasksTable 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 environment

Program Management

Defining the business goals Problem statements and business objectives (part of the vision/scope document)

Product Management

Creating the vision statement and defining scope

A vision statement and definition of scope (part of the vision/scope document)

Product Management

Creating user profiles Identification of users and their needs (part of the vision/scope document)

Program Management

Developing the solution concept

The solution concept (part of the vision/scope document)

Program Management

Creating the risk assessment document

A preliminary risk-assessment document and list of top risks (list is part of the vision/scope document)

Program Management

Writing a project structure An initial set of standards (part of the vision/scope document)

Program Management


Approving the milestone Assembled vision/scope document, and all Envisioning Phase work approved

All roles

Team FocusTable 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 MilestoneThe 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 DocumentsThe 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 TeamMicrosoft 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 ClustersThe 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.

Figure 3. The MSF Team Model

Product Management Role ClusterThe 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 planningNote 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 ClusterThe 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 ClusterThe 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 ClusterThe 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 ClusterThe 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 ClusterThe 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 RolesAlthough 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 TeamsThe size of the teams depends in large part on the size of the deployment and the complexity of each team’s responsibilities.

Assembling Small TeamsFor 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 TeamsFor 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 RolesAlthough 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 SituationA 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 DocumentThe 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 GoalsOrganizations 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 ScopeKey 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 StatementThe 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 ScopeThe 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.

Figure 4. The MSF trade-off triangle

Creating User ProfilesProject 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 ConceptThe 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 StructureThe 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 CommunicationThe 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 StandardsThe 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 ControlChange, 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 DocumentProject 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 RiskDuring 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 RisksSome 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 AssessmentPerforming 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 http://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942, and a risk-assessment document job aid (template) is provided with this solution.

Key Milestone: Vision/Scope ApprovedThe 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.

http://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942

http://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942


Envisioning Phase ChecklistBefore 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 PhaseThe 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 TasksTable 5 lists key project planning tasks and deliverables and their owners.

Table 5. Planning Phase Key Tasks, Deliverables, and Owners


Developing the solution design

The solution design document

Program Management (with heavy input from Development)

Creating the functional specification

An initial draft of the functional specification

Program Management (with heavy input from Development)

Developing the project plan

The project plan (a roll-up of all the individual plans)

Program Management (with each role 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 applications

Application list, subject matter experts (SMEs), media, and settings

Release Management

Taking an inventorying of hardware and applications

Analyzer tool deployed; reports generated for application compatibility and hardware inventory

Release Management

Creating the core applications migration plan

Migration plan Development

Creating the security policies and strategies

Security policies, strategies, and configuration

Development

Analyzing the network Network diagrams of topology and inventory of network devices

Release Management



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 FocusTable 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 DocumentsThe 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


Desired Configuration Monitoring Feature Team Guide

Infrastructure Remediation Feature Team Guide




User State Migration Feature Team Guide

Establishing the LabIf 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 DesignThe 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 ProcessThe 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 DesignConceptual 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 DesignLogical 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 DesignPhysical 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 SpecificationThe 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 ContentsThe 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 PlanThe 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 PlanThe 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 PlanThe 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 PlanThe 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 PlanThe 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 PlanThe 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 PlanThe 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 http://www.microsoft.com/learning/mls. 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 http://mspress.microsoft.com.

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 PlanIf 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

http://mspress.microsoft.com/

http://www.microsoft.com/learning/mls


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 PlanIf 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 ScheduleThe 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 SchedulesEach 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 ScheduleProgram 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.

Development TimeDevelopment Time Buffer TimeBuffer Time

Internal Milestone

Externally Visible Milestone

Figure 5. Planning buffer time


Creating the Development and Testing EnvironmentA 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 CompleteTo 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 ApprovedAt 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 ChecklistBefore 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 PhaseWhen 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.

BuildingWhen 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 PhaseThe 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 TasksTable 7 lists key developing tasks and deliverables and their owners.

Table 7. Developing Phase Key Tasks, Deliverables, and Owners


Starting the development cycle

Distribution server for the development work

Development

Creating and testing application mitigation packages and strategies

Mitigation strategies and mitigation packages

Development

Preparing the computing environment

A computing environment ready for development work

Development

Developing the solution scripts

A configured imaging and distribution server with updated script, Windows Vista, and applications; disk images

Development

Developing security configuration

Security configuration files and Windows Firewall configuration

Development

Developing core and supplemental application packages

Core applications packages, including the 2007 Office system, and supplemental applications packages

Development

Developing USMT configuration files and test cases

USMT configuration files and test cases

Development; Test

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 complete

All Developing Phase work complete

All roles

Team FocusTable 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 DocumentsThe 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.)


Computer Imaging System Feature Team Guide







Starting the Development CycleThe 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 BuildsInfrastructure 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.

Figure 6. The unattended installation development process

Creating Issue-Tracking ProceduresThe 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 EnvironmentMost 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 ScriptsIf 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 PackagingFor 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 RemediationUsing 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 RetentionDuring 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 ImagesWhile 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 ProcessThe 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 ProcessWhen 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 ProceduresFor a successful deployment, several kinds of documents are necessary. These include training and communications materials and site deployment and operations procedures.

Creating Site Deployment ProceduresDeployment 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 MaterialsFollow 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 MaterialsBefore 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 ProceduresSystem 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 SolutionTesters 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 CompleteThe 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 ChecklistBefore 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 PhaseAfter 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 PhaseThe 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 TasksTable 9 lists key Stabilizing Phase tasks and deliverables and their owners.

Table 9. Stabilizing Phase Key Tasks, Deliverables, and Owners


Conducting the pilot Test case results and bug reports

Test

Application-mitigation strategies tested, issues resolved, and results reported to management

Tested mitigation strategies Test; Release Management; Development

Operational readiness review

Operational readiness acceptance

Release Management

Final release Final images and process Development

Approving the key milestone: Release Readiness Approved

All Stabilizing Phase work completed

All roles


Team FocusTable 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 AidsThe 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 Management Feature Team Guide

Computer Imaging Systems Feature Team Guide









Testing the SolutionTesters 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 TasksA 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 PilotThe 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 FeedbackTell 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 MilestonesThe 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 ApprovedThe 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 ChecklistBefore 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 PhaseAfter 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.

DeployingWhen the final milestones for the Building Phase have been met, the Deploying Phase begins, starting with the initial deployment.

The Deploying PhaseThe 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 TasksTable 11 lists key Deploying Phase tasks and deliverables and their owners.

Table 11. Deploying Phase Key Tasks, Deliverables, and Owners


Deploying core technology Deployment servers at each location have been installed, configured, and tested; administrative staff have been trained

Release Management; User Experience; Test

Deploying sites All computers at each site have been fully installed, configured, and tested; users have been trained

Release Management; User Experience; Test

Stabilizing the deployment All computers are stable and have been measured against the project success criteria

All roles

Completing the deployment

IT Operations and support staff have 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

All roles

Team FocusTable 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 DocumentsThe following documents are used in the Deploying Phase:

Deployment Plan (job aid)







Deploying Core TechnologyDeploying 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 PlanIf 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 ServersTeams 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 SitesWith 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 StrategiesSite 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 DeploymentSite 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 InstallationsThe 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 DeploymentStabilization 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 DeploymentIt 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 DeploymentUpon completion of client system deployment, focus turns to transitioning the deployment to the customer and support staff.


Making the Transition to IT Operations and SupportPart 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 ProjectAfter 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-OffUpon 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 CompleteBefore 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 ProjectThe 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 ReviewWhen 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 ReportThe 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 AheadThe 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: PlanningPlanning 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.

EnvisioningThe 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.

PlanningThe 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: BuildingUpon 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.

DevelopingThe 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.

StabilizingThe 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: DeployingDuring 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.

Plan, Build, and Deploy Guide -...

Documents

Transcript of Plan, Build, and Deploy Guide -...