Using This Solution

Article
03/05/2008

The solution offering has four components: the Plan, Build, and Deploy Guide, the technical feature team guides, the job aid documents, and the solution scripts. The team can use these interdependent components in whole or in part depending on the role of a particular team member in the project.

The Plan, Build, and Deploy Guide

The Plan, Build, and Deploy Guide explains how to plan and complete the project and is intended for the IT project team. It describes project planning, timelines, team roles, and other project management information.

The Feature Team Guides

The feature team guides provide information about specific technical areas. Separating the technical content from the planning and management content enables readers to focus on the types of documents that are most pertinent to their roles on the team. Feature team guides steer specialist teams through planning, building, and deploying tasks and checkpoints within the larger deployment project. Guiding the teams through the checkpoints ensures that each team’s decisions align with the overall project goals and that the deliverables are well integrated into the total migration project.

For example, a program manager will spend much more time with the Plan, Build, and Deploy Guide than with a technical imaging document; conversely, developers will spend the greater part of their time with the feature team guides and less with the Plan, Build, and Deploy Guide. Although this Plan, Build, and Deploy Guide may indicate that it is time to create a computer image, it does not describe how to perform that imaging. Instead, it refers to an imaging feature team guide.

Each feature team guide contains synchronization points that refer to an interim milestone in the Plan, Build, and Deploy Guide. In this way, the technical content can be updated independently of the management guide while remaining synchronized with specific deliverables, milestones, and decisions in the management planning structure. In addition, step-by-step processes are separated from conceptual content as appendices in the feature team guides. This separation enables team members to quickly move into action items, particularly when team members are well versed in the concepts underlying the Planning or Deploying Phases.

Note For a brief description of the feature team guides, see the Getting Started Guide.

The Job Aids

Several job aids (templates) are provided as starting points for the project. For example, where the Plan, Build, and Deploy Guide indicates the need for a functional specification document, the corresponding job aid shows which type of content should be included in the specification. The job aids can be modified to fit the specific processes and requirements of each organization.

The Solution Script Files

Teams use the solution script files to set up the imaging and deployment servers that create standard Windows-based desktop configurations. These files include utilities to customize boot CD-ROMs and connect them to the various servers and other assorted development tools. Use the scripts to perform such tasks as creating customized bootable images, deploying Windows from a share or Universal Naming Convention (UNC) path, customizing the deployment with applications, performing unattended installations, and capturing user data.

The solution script files do not contain copies of Windows or the 2007 Office system. To proceed with the project, team members require licensed copies of this software and of other vendor-specific software such as DVD player software and CD-creation software. A complete description of these requirements is available in the feature team guides. The Getting Started Guide provides an overview of the entire solution and helps teams complete the initial steps necessary to start the project.

Who Should Use This Solution?

This solution is useful to readers in two primary categories:

IT departments can use this accelerated solution to plan and carry out a Windows desktop deployment either internally or with help from contractors or consultants.
Consulting organizations can use this accelerated solution to plan and carry out a Windows deployment for a client company or organization.

To obtain the maximum benefit from this solution, the reader should have at least a basic understanding of commonly used computer and networking terms and concepts and be familiar with the Windows platform and user interface (UI). Team members should be proficient in their assigned duties and be familiar with the other roles defined for MSF teams.

Solution Updates

The recommendations and resources provided in BDD 2007 are based on the best information available as of November 2006. Tools and best practices associated with Windows deployments will continue to be refined and enhanced. See Desktop Deployment at https://www.microsoft.com/technet/desktopdeployment for any updates concerning Windows deployments.

The Sample Scenario

This solution combines many abstract concepts that are often difficult to interpret without citing specific examples. To address this issue, the Plan, Build, and Deploy Guide and the feature team guides reference a desktop deployment project at a fictional company called Woodgrove Bank.

Woodgrove Bank is a leading global investment bank that serves institutional, corporate, government, and individual clients in its role as a financial intermediary. Its business includes securities underwriting, sales and trading, financial advisory services, investment research, venture capital, and brokerage services for financial institutions.

Woodgrove Bank employs more than 15,000 people in 60 offices worldwide. Woodgrove’s enterprise headquarters is in New York. The company has division headquarters in London and Tokyo. In addition, it has 57 offices across the globe. Of those 57 offices, 13 are considered regional hubs and have server infrastructure and at least one full-time IT administrator on location. Ten locations are considered autonomous branch offices and include server infrastructure on location but no full-time IT staff. The remaining 34 branch offices are micro-branches and do not have any server infrastructure or IT staff on location.

Feature Teams

A feature team is a cross-organizational team of responsible owners organized to solve a defined problem. BDD 2007 includes the following nine feature teams:

Application Compatibility
Application Management
Computer Imaging System
Desired Configuration Monitoring
Infrastructure Remediation
Operations Readiness
Security
Test
User State Migration

Note For a detailed description of the feature teams, see the Getting Started Guide.

There are many good reasons for using feature teams. However, some risks must be recognized and planned for, as well. The use of feature teams has several advantages:

They divide the work of the solution into discrete, definable parts that can be more easily managed.
They enable the application of specialized expertise in areas where it is needed.
They ensure that adequate cross-discipline involvement is included in the team. This means that the work is addressed from several perspectives rather than just one.
Most important, they foster ownership of the problem space involved by giving feature teams the empowerment and accountability they require to complete the work. This results in a high degree of focus.

Communication

Key to successful project implementation is each feature team’s ability to cooperate and communicate among its members, with other feature teams, and with project stakeholders.

Communications Within Teams

By definition, MSF teams are teams of peers. Each role is considered equally important in achieving the project’s goals and thus in contributing to its success. Teams of peers are also characterized by joint decision-making about important issues. Open communications among team members, or the sharing of needed information, is essential in arriving at sound decisions that make the best use of team roles’ different perspectives. The lead team and the feature teams are all teams of peers.

Communications Among Feature Teams and the Lead Team

Figure 1 shows that one management team, called the lead team, orchestrates the efforts of the other feature teams. The relationships are that of a conductor and a group of soloists in an orchestra. The soloists are not subservient to the conductor, nor does the conductor pretend to be a virtuoso in each of the particular specialty areas. The lead team’s role is to make sure that the expert efforts of the group of feature teams are integrated into a holistic symphony rather than isolated, competing performances.

Note that the channels shown in Figure 1 are formal communications channels. Informal communications among feature teams are also required. Informal communications among feature teams and between a team and users should be governed by the general principles of good communication:

Identify the right people to communicate with. It is crucial that the information obtained and the decisions made on the basis of this information are relevant and of good quality. Otherwise, a substantial amount of effort, time, and money could be wasted in rework.
Communicate at the right level. A user is likely to become alienated if the communication is not designed to address the perceived problem in the language and nomenclature this user expects. For example, when a business decision maker loses trust in a team as a result of a perception that the team is purely technical—when it is important that the team understand the business problem—it is extremely difficult for the team to regain this trust.

Figure 1. Formal communication channels in the BDD 2007 project

Communications with Stakeholders

For any team to be successful, it must interact, communicate, and coordinate with other external groups. These groups range from customers and users to other development teams. In a BDD 2007 project, several stakeholders might have overlapping and conflicting interests. Therefore, it is strongly suggested that the stakeholders be organized into a team of peers, with an MSF Program Management Role Cluster assigned to balance and trade off the conflicting requirements among the stakeholder factions. If the stakeholders agree with this arrangement, the project will run much more smoothly. Be aware, however, that stakeholders are likely to preserve their views in this type of deployment project, because it touches the primary interface that the client employees have with the organization: the application portfolio and service portfolio on the business desktop.

It is therefore a requirement that the relevant communication with stakeholders be documented and routed through the channels as shown in Figure 1. Relevant communication is defined as any decision or flow of information that defines, refines, or alters the scope, time, or budget of the initiative.

Scaling the Feature Team

The feature team model scales elegantly. It is highly recommended that most, if not all, of the role clusters be represented in the lead team. A feature team that focuses specifically on a particular aspect of a project, such as application compatibility resolution, however, can be staffed by a single multi-skilled person for very small deployments or by multiple people in each role cluster for large, complex deployments.

Additional Guidance on the MSF Team Model

For additional guidance on the MSF Team Model, see the white paper, “MSF Team Model,” which is available for download at https://www.microsoft.com/downloads/details.aspx?FamilyID=c54114a3-7cc6-4fa7-ab09-2083c768e9ab.