Planning
Planning is the first phase of the overall deployment process. The Planning Phase consists of several steps, from envisioning the deployment goals and vision to gathering data and resources that the teams will use during the following phases. The first step in this phase is envisioning the deployment.
On This Page
.gif){kind=icon}
The Envisioning Phase
The Planning Phase
The Envisioning Phase
The Envisioning Phase unifies the project team with a common vision. It culminates with a well-defined scope of work and project structure indicating team and customer agreement on the project’s direction.
Key Tasks
Table 3 lists key Envisioning Phase tasks and deliverables and their owners.
Table 3. Envisioning Phase Key Tasks , Deliverables , and Owners
Key tasks |
Deliverables |
Owners |
|---|---|---|
Setting up a team |
All six team roles represented |
Product Management; Program Management |
Assessing the current situation |
Compiled information on the computing 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 Focus
Table 4 lists the key areas of focus for each role cluster during the Envisioning Phase.
Table 4. Envisioning Phase Role Clusters and Focus
Role cluster |
Focus |
|---|---|
Product Management |
|
Program Management |
|
Development |
|
Test |
|
User Experience |
|
Release Management |
|
IT Operations and the Security feature team should be included in the assessments to ensure that an accurate view of their respective areas is addressed.
Interim Milestone
The Envisioning Phase of the MSF Process Model contains one interim milestone. Use the information and techniques in this guide to complete this milestone, which is a prioritized list of applications that business management has decided to include in its solution.
Feature Team and Job Aid Documents
The following documents are used in the Envisioning Phase:
Vision/Scope
Assessment template
Deployment Feature Team Guide
Operations Readiness Feature Team Guide
Security Feature Team Guide
Test Feature Team Guide
The MSF Team Model: Setting Up the Team
Microsoft developed the MSF Team Model over a period of several years to compensate for some of the disadvantages imposed by the top-down, linear structure of traditional project teams. Teams organized under the MSF Team Model are small, multidisciplinary teams in which the members share responsibilities and balance each other’s competencies to focus tightly on the project at hand. They share a common project vision, a focus on deploying the project, high standards for quality (sometimes referred to as a zero-defect mindset), and a willingness to learn. The MSF Team Model prescribes no single leader; the members work together as a team of peers with their own defined role or roles, with each role taking the focal point at different points in the process.
Role Clusters
The MSF Team Model defines six interdependent, multidisciplinary roles or role clusters with responsibility for implementing different aspects of the project (see Figure 3). The organization may choose to change or add to the responsibilities listed as appropriate for the project, provided all six roles are represented.
.gif)
Figure 3. The MSF Team Model
Product Management Role Cluster
The product manager acts as the customer advocate to the project team by ensuring that the team addresses the customer’s requirements, concerns, questions, and feedback throughout the project. Likewise, the product manager acts as the team’s liaison to the customer, handling high-level communication and managing the customer’s expectations.
On this project, the product manager is likely to be an IT director or higher-level executive who is empowered to make decisions regarding scope, cost, and project resources. The product manager must demonstrate leadership ability and a sincere belief in the project and the benefits to be gained from implementing it.
Product Management responsibilities for a BDD 2007 project include:
Marketing
Business value
Customer advocacy
Product planning
Note The product manager should provide a written description for each of these responsibilities so that they will be clearly defined for the rest of the team.
Program Management Role Cluster
The program manager functions as a “traffic director” to manage and coordinate the activities of the other team members. Program Management is responsible for setting the project schedule and for reporting the project status. Whereas the Product Management Role Cluster facilitates external communication between the team and the customer, the Program Management Role Cluster is responsible for facilitating internal communication among the members of the project team. Program Management’s duties include establishing design goals, directing the creation of the functional specification and the project plan, and coordinating the use of development resources by the Development and Test Role Clusters.
Program Management requires a clear understanding of the whole project: what is to be done, how it is to be done, when it will be done, and who will do it. Program managers should be skilled organizers and technically proficient. They do not need to interact with the technical personnel at a detailed level, but they must be technically oriented enough to work knowledgeably with them.
Development Role Cluster
The team members filling the Development role are responsible for designing, building, and unit-testing the baseline and imaging architectures. This includes writing and adapting scripts to facilitate the unattended installation of Windows and the 2007 Office system on all the hardware platforms included in the project scope. In addition to performing the actual development tasks, the developers are responsible for documenting their work, including configuration details and installation procedures. The Development Role Cluster is often filled by several individuals, depending on the nature and complexity of the project.
The developers must exhibit a high degree of technical understanding as well as a comprehension of the organization’s computing architecture and how Windows and the 2007 Office system fit within it. They must be familiar with the products being deployed, their feature sets, and the components for which they are specifically responsible. Do not assign the same people to both the Development and Test Role Clusters, because doing so does not provide an adequate check of the development work.
Depending on their responsibilities, developers should demonstrate proficiency in these areas:
Batch scripting
Knowledge of VBScript
Familiarity with Microsoft Windows Preinstallation Environment (Windows PE)
Windows setup methods and tools
Using and configuring Windows, including security, policies, services, and network settings
Using, deploying, configuring, and maintaining the 2007 Office system
Using the Microsoft Office 2007 Resource Kit
Imaging hard disks, including using Sysprep to prepare disks for imaging
Using, deploying, and configuring disk-imaging tools
Configuring desktop and laptop hardware, including the basic input/output system (BIOS)
Application installation packaging tools
For the deployment project, the Development Role Cluster could be divided into sub-teams, which are often referred to as feature teams, with each feature team responsible for areas such as:
Computer imaging system.
Application management.
Application compatibility remediation.
LTI deployment process.
Test Role Cluster
The team members filling the Test Role Cluster are responsible for testing the architecture and associated documentation against the functional specification and ensuring that the documentation meets the requirements designed by the scope.
Testers should have a background in testing and an understanding of what testing entails. Accordingly, they should be very detail oriented and technical, have an understanding of the operating environment, and be committed to proactively finding errors. Familiarity with the Windows operating system environment and with the applications to be deployed is valuable.
User Experience Role Cluster
The team members filling the User Experience Role Cluster are responsible for defining training and communication requirements for users. Whereas Product Management functions as the customer advocate, acting on behalf of the person or people commissioning or paying for the project, the User Experience Role Cluster functions as the user advocate, acting on behalf of the people who will use the solution on a daily basis. For this project, User Experience is also responsible for educating users on the benefits of the solution and how they can use it to carry out their duties more efficiently.
User Experience specialists should be familiar with users and the jobs they perform and be able to assess users’ training and communications needs. They should also be able to design and conduct training programs.
Release Management Role Cluster
The Release Management Role Cluster is responsible for coordinating the activities necessary to ensure a successful rollout and for defining and documenting life cycle management strategies and processes. Team members filling this role act as IT Operations support advocates on the team, including administering acceptance testing, rolling out the solution, and helping to hand the solution over to ongoing operational support personnel.
Release Management must be familiar with the operational environment, including technical support and the help desk. Team members must also understand the impact the solution will have on the previous environment.
The Release Management Role Cluster must include resources to manage the computer inventory process and the network analysis process. Team members work to ensure that this information is conveyed to the development teams.
Assigning Roles
Although MSF defines six distinct team role clusters, not every team must consist of six people. Depending on the nature and extent of the project, the organization may have a core project team composed of more or fewer than six people, some of whom may be working on the project part time.
Within a large organization, it often makes sense to dedicate some project members to their tasks to build a robust and supportable desktop architecture. Dedicated team members devote 100 percent of their time to the project and have no day-to-day operations responsibilities unrelated to the project. Within smaller organizations, this setup may not be feasible, and team members who divide their time between the project and day-to-day operations may manage the scope of the project. Take these considerations into account when planning and assembling a team for the project.
The MSF Team Model: Scaling Teams
The size of the teams depends in large part on the size of the deployment and the complexity of each team’s responsibilities.
Assembling Small Teams
For small or resource-limited projects, consider assembling a small core team in which at least one of the members assumes responsibilities for two or more roles. Some of the ways the roles for a desktop deployment project can be combined include meshing:
Release Management and User Experience.
Test and User Experience.
Program Management and Release Management.
Some roles should not be combined. The developer should not be responsible for testing, because such a combination does not provide an adequate check on the development work. Likewise, one team member should not be responsible for the Program Management and Product Management roles. Although it may be tempting to assign these roles to the same person, they might represent competing interests.
Very small projects may have a core project team composed of only three people: one responsible for Program Management and Release Management; one responsible for Development; and one responsible for Test, User Experience, and Product Management. IT staff may choose a different permutation depending on the nature of the project and the skills of the team members, provided they keep the restrictions previously listed in mind.
Assembling Larger Teams
For larger projects, the IT department may want to assemble a team in which some roles include more than one team member. This will often be true of the Development Role Cluster, which can be divided into several feature teams depending on the nature of the project.
Create feature teams based on logical divisions of work. For example, IT may create a Desktop feature team, which performs development activities related to Windows; an Applications feature team, which performs activities related to the 2007 Office system; and a Messaging/Internet feature team, which performs activities related to Microsoft Office Outlook® and Windows Internet Explorer®. Each of these feature teams may consist of one or more developers, and each developer may work on one or more feature teams. As more resources are added to the team, be careful to ensure that the team does not become too large to work together effectively as a group.
The MSF Team Model: Assigning Team Members to Roles
Although every role should be represented during the Envisioning Phase, it is not necessary to assemble the entire team at this point, nor is it necessary for every team member to be fully dedicated to the project yet. Every role, however, should have an identified lead during the Envisioning Phase.
All six roles are vital parts of the team. For this reason, make an effort to fully dedicate every lead to the project from the beginning, with none of them working on other projects. In reality, of course, it is not always possible for all team members to fully disengage from their other responsibilities before beginning work on the desktop deployment project.
Follow these guidelines when assigning roles:
The people filling the Product Management and Program Management Role Clusters should be fully dedicated at this point, if possible.
Although the Development lead can be wrapping up other projects during the Envisioning Phase, this person should be fully dedicated to this project, if possible. Expect to add additional team members to the Development Role Cluster during the Developing Phase.
The Test lead can be assigned to other projects during the Envisioning Phase, if necessary, but should be involved with the project from the beginning and be available to sign off on important decisions. Expect to add additional team members to the Test Role Cluster during the Developing and Stabilizing Phases, if necessary.
The User Experience lead will be collecting user profile information during the Envisioning Phase. This person can be assigned to other projects during the Envisioning Phase, if necessary. Expect to add additional team members to the User Experience Role Cluster during the Developing and Deploying Phases.
The Release Management lead will be helping assess the current situation during the Envisioning Phase. This person can be assigned to other projects during the Envisioning Phase, if necessary. Expect to add additional team members to the Release Management Role Cluster during the Deploying Phase.
Any team members who work on other projects during the Envisioning Phase must demonstrate an ability to manage their time and attention well so as not to neglect their project responsibilities. Having team members work on other projects is a risk and should be recorded and tracked as risk.
If Program Management or other leads know in advance which people will be added to the team at a later stage, note this in the vision/scope document. It is not crucial to engage these future team members in the project, yet. Consider making the project documentation available to them to read at their discretion.
Assessing the Current Situation
A map is valuable to travelers only when they know where they are. Likewise, IT cannot effectively envision a desktop deployment project without a clear understanding of the current state of the organization’s computing environment. This includes accurate and up-to-date information about such things as the organization’s systems architecture, including the hardware and software already deployed and in what combinations, and the operational procedures currently in place within the organization.
Think of a deployment project as a phase in an ongoing process of technology life cycle management encompassing years or even decades. When the project begins, therefore, teams draw upon work done and experience gained long ago. After the project is concluded, teams use that work and experience to inform future life cycle management actions.
As part of the decision to explore deploying Windows or the 2007 Office system, someone in the IT department should have assessed the current computing environment as a starting point for decision making. The IT department may have chosen to conduct this assessment itself, or it may have hired a consulting firm to do it. The result of such an assessment is typically a document describing the assessor’s findings in some detail, which may include recommendations for future actions. This document should contain sufficient information about the computing environment, including network, domain, and physical location information, to allow knowledgeable planning.
During the Envisioning Phase, it is the job of the project team to gather relevant information about the current situation and look for deficiencies that the project can address. The information-gathering process may be as simple as obtaining documents like the one described above from the IT department. If no such documents exist, the team may have to gather existing documentation from various sources throughout the organization and assess them for accuracy and comprehensiveness or conduct a brief review of its own.
This time is often ideal to start the network discovery and the computer inventory processes to get a more accurate view of the environment. Typically, the Release Management Role Cluster takes the lead in assessing the current situation.
The Vision/Scope Document
The primary deliverable of the Envisioning Phase is the vision/scope document, which provides a clear direction for the project and sets expectations within the organization as well as with sponsors and stakeholders. It is composed of:
Business goals. Includes problem statements that define the problems the project is intended to solve and business objectives
Vision statement. Establishes a vision for the project
Scope definition. Establishes the project scope
User profiles. Identifies the users who will benefit from the solution
Solution concept. Outlines the approach the team will take to plan the project
Project structure and standards. Guidance for the team to follow
Risks. Lists the top identified risks from the risk assessment document
Defining the Business Goals
Organizations undertake infrastructure deployments to address business needs. By the time the project has reached the MSF Envisioning Phase, these needs should be clear enough to be expressed and defined as problem statements and corresponding business objectives.
Problem statements identify perceived deficiencies in the computing environment. Business objectives define the goals the team hopes to achieve by suggesting actions it can take to mitigate the identified problems. These problems are sometimes called business opportunities, because they represent an opportunity for the organization to improve its processes.
The team should not undertake the project with the sole purpose of deploying the latest technology. Instead, the team must identify specific deficiencies and opportunities in the organization’s computing infrastructure and in the business itself and position the project directly at these areas. The Product Management Role Cluster takes the lead in defining the business goals, which should be about a page long or less.
A typical problem statement and business objective for this project might read:
The organization currently has no defined operating system standard. Several mergers and acquisitions have resulted in different branch offices running Microsoft Windows Me , Windows 2000 Professional , and Windows 98. This lack of standardization has led to increased support costs. Moving to a single operating system standard would present an opportunity to make measurable reductions in support costs.
Here, the problem statement is the description of the known disadvantages of having multiple operating systems deployed throughout the organization. The business objective is to minimize or eliminate these disadvantages through the adoption of a single standard.
Defining the Vision and Scope
Key steps in the Planning Phase include creating the vision statement and defining the scope of the project. The scope leads from the vision statement.
Creating the Vision Statement
The vision statement establishes a long-term vision to address the problem statements and achieve the business goals. Typically only a paragraph or two in length, the vision statement is not bound by the actual work the team expects to perform as part of the current project, but it should balance competing interests to provide a vision that can be shared among team members and provide context for future decision making.
A typical vision statement for a Windows deployment project might read:
The IT department will select and implement a single computing platform across the company to cut support center call volume by 10 percent and enable field technicians to spend at least 15 percent of their time on value-added projects instead of reactive support.
Defining the Scope
The scope takes the overall project vision as expressed in the vision statement and incorporates the restraints imposed by time, resources, budget, and other limitations. Generally, this process involves using versioned releases to define an iterative approach to the project, wherein the project team identifies the organization’s most essential needs and prioritizes the deployment based on this assessment.
For example, the vision might call for deploying Windows Vista, the 2007 Office system, and a suite of non-Microsoft applications throughout the organization. Time and budgetary restrictions might make it impossible to achieve the entire vision as part of a single project. The scope might therefore restrict the current project to a deployment of Windows Vista to desktop computers and portable computers throughout the organization and the 2007 Office system to desktop computers throughout the organization. Further projects in the future might involve deploying the 2007 Office system to the portable computers and any additional software to all the computers in the organization. Depending on the needs of the organization, the scope might restrict the deployment by department, by computer manufacturer, by geographic location, or by other factors.
The trade-off triangle that Figure 4 shows is an important component of MSF and helps set the project scope. The trade-off triangle dictates that resources, schedule, and features are three interconnected elements of any project and that constraining or enhancing one or more of these elements will require trade-offs with the others. For example, a project team with finite available resources (for example, personnel, budget, facilities) that commits to an early completion date will probably make trade-offs regarding the feature set to make the date, perhaps deferring deployment at some remote sites or on some systems for a later time.
.gif)
Figure 4. The MSF trade-off triangle
Creating User Profiles
Project success depends on every member of the team possessing an accurate understanding of the users and their needs. User profiles identify the users so that the team can assess the expectations, project risks and goals, and constraints. These profiles typically include information such as users’ geographic locations, job functions, organizational structure, and communications patterns.
The purpose of user profiles is to outline who the solution’s users are and what their relationship to the solution will be. IT personnel probably want to draw up different profiles for the users, defined as those who will use at least part of the solution to perform their business functions, and the IT professionals who will be responsible for deploying and maintaining the solution. Therefore, it might be necessary to identify different classes of users and develop profiles for all of them.
Developing the Solution Concept
The solution concept outlines an approach that provides the basis for planning and scoping the analysis and investigative work required to build a specification. Now that the team has identified the business problem and defined the vision and scope, it creates the solution concept, which explains at a high level how the team intends to meet the requirements of the project. Program Management takes the lead in developing the solution concept, which should be reasonably succinct, perhaps a few pages in length.
Whereas the scope describes what the team intends to do, the solution concept describes how the team intends to do it. The solution concept should remain relatively high level and can address such things as:
The duties of each of the six team roles and the people selected to fill them (at least the leads at this point).
An overview of the project, including phases and their accompanying milestones and deliverables based on the MSF Process Model.
Factors outlining how project success is defined and measured.
Sample scenarios for when and how the system is implemented and how users employ the new technology.
A checklist of requirements that must be satisfied before the solution goes into production.
An early high-level draft of the schedule for the Planning Phase.
Writing a Project Structure
The project structure defines how the team manages and supports the project and describes the administrative structure for the project team going into the Planning Phase. The main function of the project structure is to define standards the team will use during the project. These standards include communication standards, documentation standards, and change-control procedures. Consider creating an intranet Web site for the purposes of communication and monitoring progress.
The Program Management Role Cluster takes the lead in defining the project structure, which is usually included as a component of the vision/scope document.
Planning Project Communication
The Program Management Role Cluster should use the project structure to define standards for team members to communicate with one another. These standards might include a definition of the reporting structure under which team members operate, procedures for elevating issues, regular status meetings, and any other project-specific communication-related standards that must be defined during the Envisioning Phase.
The document may also include e-mail names, aliases, telephone lists, mail addresses, server share names, directory structures, and other information crucial to team organization. Consider establishing an internal Web page on which this information can reside and be updated as necessary.
Planning Documentation Standards
The project structure can also define standards on how to create training materials and documentation related to the project, including standards prescribing the applications and job aids (templates) the team should use to create documents.
Planning Change Control
Change, or the possibility of change, is an integral factor in any high-tech deployment project. Manufacturers frequently release new versions of software or issue updates and service packs for existing versions. By exercising control over any changes that could affect the scope of the project, the team can help ensure that it will complete the project on time and on budget, and prevent scope creep—the tendency to add features to the project in increments until the aggregate effect of the changes jeopardizes the project’s success.
The Program Management role should consider including change-control standards in the project structure. These standards would apply to both changes in project structure and scope as well as to changes in scripts. These standards can include prescribed daily builds and use of source-control software such as Microsoft Visual SourceSafe® 6.0 to control access to scripts.
Creating the Risk Assessment Document
Project risk , or the possibility of negative outcomes associated with individual aspects of the project, is a part of every deployment project. Risk management is the process of anticipating, addressing, mitigating, and preventing risk. Under MSF, risk management is something the team practices continuously throughout the project rather than just at predefined intervals.
Risk management is proactive: The team concentrates on continuously assessing what could go wrong and how to prevent it or minimize the loss it will cause rather than waiting for something to go wrong and coping with its effects.
Note BDD provides the job aid, Woodgrove Risk Template Tool, to help identify and prioritize risks.
Initial Assessment of Risk
During the Envisioning Phase, the team practices risk management by creating an initial risk-assessment document, which assembles all the known risks and assesses them for probability (the chance the risk will occur) and impact (the amount of loss that will result if the risk does occur). The Program Management Role Cluster takes the lead in creating the risk-assessment document.
If teams use numeric scales to assess risk probability and impact, they can calculate each risk’s exposure by multiplying the two numbers together, such that probability x impact = exposure. This calculation makes it possible to compare risks with one another to determine their relative severity and priority, which may not be readily apparent if, say, one risk has a high probability but low impact and another has a low probability and high impact. For example, if a team uses a number between 1 and 4 to designate each risk’s probability and impact, with 4 being the highest and 1 the lowest, multiplying the two together gives each risk an exposure factor between 1 and 16, thereby allowing team members to address the most severe risks first.
Teams need not use the same numeric scale to assess both probability and impact. If team members can accurately calculate the financial loss to be caused by each risk, they can express impact in terms of a monetary amount. It is important, however, that they use a consistent scale to calculate the probability for every risk as well as a consistent scale to calculate the impact for every risk. Using a monetary amount to express the impact of some risks and a numeric scale for other risks makes it impossible to compare risks with one another.
After the team has created the risk-assessment document and ranked each risk by exposure, a list of the top risks can enable the team to focus on the highest-priority risks. Often called a top 10 list, this list does not have to contain exactly 10 risks but can contain more or fewer depending on the number of risks identified and the exact nature of the risks and of the project overall. Program Management should review this list frequently throughout the project, adding and removing risks as they move up and down in importance and as new risks are identified.
Potential Risks
Some of the risks the team may have to manage when deploying Windows, the 2007 Office system, and other applications include the following:
Components of the selected technology may contain bugs that will hinder its ability to perform as planned.
The time frame allotted for the project may be too aggressive to allow the team to acceptably implement it.
The team members may be unfamiliar with the concepts and principles of MSF and the roles they are to fill.
The team members assigned to the project may be busy with other duties.
IT managers throughout the company, especially those at remote locations, may be accustomed to working with a certain degree of autonomy and may resist standards that managers impose.
Some in-house applications may not function correctly under Windows XP or Windows Vista.
The project team almost certainly will not face all these risks, and it will almost certainly face others not even on this list. Remember, too, that risk management is an ongoing process, and some risks will not become apparent until later in the process.
Learning More About Risk Assessment
Performing proper risk assessment requires an understanding of the philosophies underlying risk management in general and MSF risk management in particular. A detailed white paper on the MSF Risk Management Discipline is available at https://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 Approved
The Vision/Scope Approved Milestone concludes the Envisioning Phase. At this point, the project team and the customer have agreed on the overall direction of the project, including which features the solution will and will not include, and a general timetable for delivery.
After the team roles have been defined and the Envisioning Phase deliverables have been created, the program manager assembles them into the vision/scope document. This document is then baselined and serves as a basis for project planning.
Envisioning Phase Checklist
Before proceeding to the Planning Phase, the following items should have been addressed:
Business case
Core teams identified:
Program Management
Product Management
Development
Test
User Experience
Release Management
Feature teams identified:
Application Compatibility
Computer Imaging System
Application Management
Deployment
Infrastructure Remediation
Operations Readiness
Security
Test
User State Migration
Network discovery may have been accomplished
IT Operations integrated into the project
Project structure approved
Risk assessment complete
Security feature team integrated into the project
Vision/scope document approved
Computer inventory may have been accomplished
After all the Envisioning Phase tasks are complete, the team must formally agree that the project has reached the Vision/Scope Approved Milestone. By approving the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone has been met. The sign-off document becomes a project deliverable and is archived for future reference. The project can now move to the Planning Phase.
The Planning Phase
The Planning Phase is the period during which the team defines the solution: what to build, how to build it, and who will build it. The Planning Phase culminates in the Project Plans Approved Milestone, indicating that the project team, customer, and key project stakeholders agree on the details of the plan.
The team’s goal during the Planning Phase is to document the solution in a set of plans to a sufficient degree that the team can produce and deploy the right solution in a timely and cost-effective manner. These are living documents, and the team will continue to update them throughout the Developing Phase.
The Planning Phase has four primary deliverables: the functional specification, which includes the solution design; the project plan; the project schedule; and the development and testing environment.
Key Tasks
Table 5 lists key project planning tasks and deliverables and their owners.
Table 5. Planning Phase Key Tasks , Deliverables , and Owners
Key tasks |
Deliverables |
Owners |
|---|---|---|
Developing the solution design |
The solution design document |
Program Management (with heavy input from Development) |
Creating the functional 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 Focus
Table 6 outlines the primary activities of each role cluster during the Planning Phase.
Table 6. Planning Phase Role Clusters and Focus
Role cluster |
Focus |
|---|---|
Product Management |
|
Program Management |
|
Development |
|
Test |
|
User Experience |
|
Release Management |
|
IT Operations and the Security feature team are included in the assessments to ensure that an accurate view of their respective areas is addressed. The user community is included to ensure that the plans and designs being compiled are consistent with their needs.
If not completed previously, an analysis of deployed applications is conducted to see which applications will be redeployed and which applications may be retired. Release Management initially prioritizes applications to establish a sequence for automating the applications’ deployment.
Release Management also conducts an initial review of the hardware inventory (if it has not already been done as part of the technology life cycle planning) to determine which computers can be used unchanged, which may require modifications (for example, RAM, disk), and which must be replaced.
Feature Team and Job Aid Documents
The following documents are used in the Planning Phase:
Functional specification
Risk assessment
Project schedule
Project plan, including:
Development plan
Test plan
Deployment plan
Pilot plan
Communication plan
Training plan
Facilities and hardware plan
Budget plan
Application Compatibility Feature Team Guide
Application Management Feature Team Guide
Computer Imaging System Feature Team Guide
Deployment Feature Team Guide
Desired Configuration Monitoring Feature Team Guide
Infrastructure Remediation Feature Team Guide
Operations Readiness Feature Team Guide
Security Feature Team Guide
Test Feature Team Guide
User State Migration Feature Team Guide
Establishing the Lab
If the teams do not already have one, it is advisable to establish a dedicated and isolated lab environment for use in developing and testing the solution. The lab should mirror the production environment as closely as possible to ensure that all aspects of the production environment can be accounted for in the development process.
At a minimum, the lab should include:
A Microsoft Active Directory® directory service domain (Microsoft Windows Server® 2003 or Windows 2000 Server) with administrative privileges.
Windows Server 2003 with SP1. (Windows Server 2003 R2 is preferred, because it provides a useful replication mechanism.)
Microsoft Virtual Server 2005 (optional).
Dynamic Host Configuration Protocol (DHCP) services.
Domain Name System (DNS) services.
Windows Internet Naming Service (WINS) services (optional).
MOM 2005 (optional).
Microsoft Windows Deployment Services (Windows DS).
SMS 2003 with SP1 and the SMS Operating System Deployment (OSD) Feature Pack.
SQL Server 2000.
SQL Server 2000 Reporting Services Standard Edition.
Internet access (for downloading updates, files, and so on).
A file server with sufficient capacity to host the imaging server; 50 gigabytes (GB) is recommended.
Test computers that accurately reflect production computers.
CD burner and writeable CDs (required) or DVD burner and writeable DVDs (optional).
Backup media, such as a tape backup system and tapes.
Software library, including Windows, the 2007 Office System, applications, disk imaging software, Windows PE, and hardware drivers.
Developing the Solution Design
The solution design is the first comprehensive design document and is part of the functional specification. This design prepares the team members for their responsibilities during the Developing Phase. It builds on the vision the team developed and technology information the team gathered during the Envisioning Phase, and it sets forth the conceptual, logical, and physical solution designs. Think of the processes that produce these designs as three overlapping stages of a design process that begins before the Envisioning Phase and continues throughout the project and afterward, with the project itself being only a component of a larger technology life cycle management process.
The Design Process
The design process is like a construction project for building a house. The conceptual design is analogous to the rough sketches and scenarios the architect creates in conjunction with the customer. The logical design is created by the architect’s team and lays out the structure of the solution and the communication paths among elements; it corresponds to a floor plan and elevation, where elements such as spatial relationships are organized. The physical design corresponds to a contractor’s blueprints for the physical elements of a structure—wiring, plumbing, heating, and ventilation. The contractor’s plans (physical design) add detail to the architect’s plans (logical design) and reflect real-world construction constraints.
Conceptual Design
Conceptual design involves understanding the business requirements and defining the features and functions users need to do their jobs. Product Management takes the lead in creating the conceptual design, which begins during the Envisioning Phase and continues throughout the Planning Phase. The conceptual design of this project should include:
Design goals that describe the objectives of the project in ways that address the problem statements and business opportunities identified in the vision/scope document.
The list of features and functions that the solution comprises. The conceptual design typically states this list in terms of the operating system and applications that are to be deployed (in this case, Windows and any additional applications), the unattended installation architecture (including distribution servers), and the disk-imaging architecture.
Usage scenarios that anticipate the ways in which different types of users will implement, administer, and use the solution. Revisit the user profiles defined in the vision/scope document, and describe how the types of users identified will work with the solution. Tasks to document can include administering the distribution architecture, installing and configuring the solution on new computers, configuring Windows for first use, and using different components of the solution to implement business objectives.
Logical Design
Logical design uses the conceptual design and the current state of the technology infrastructure to define the new architecture at a high level. The logical design of this project should include:
A high-level definition of the unattended installation architecture that the Deployment feature team uses to begin the deployment process on each affected computer as well as the configuration and placement of deployment servers. This definition does not necessarily include the exact physical location of each deployment server but should outline the rationale behind choosing the desired locations.
A similar definition of the hard disk imaging architecture, including a justification for using disk images, a description of the facilities needed for performing disk duplication, and a description of the software tools the team uses to prepare hard disks for duplication (typically, Sysprep).
Physical Design
Physical design goes into greater detail about the desired architecture, and it defines the hardware configurations and software products to be used. The physical design of this project should include:
Specifications for the hardware configurations included in the scope of the project.
Specifications for the software to be installed.
The tools to be used for project development.
As a general rule, the solution design should contain enough detail to enable the team to begin work on the project plan.
The team should complete the conceptual and logical designs by the end of the Planning Phase. The physical design is “baselined” to draft the solution design, but it continues to be refined throughout the remainder of the project, changing as the team makes and revises development and deployment decisions.
Creating the Functional Specification
The functional specification addresses what the solution must include. It represents the contract between the customer and the project team and is the basis for building the project plans and schedules. During the Planning Phase, the functional specification is baselined and placed under change control. Program Management takes the lead in compiling the functional specification with input from the role leads regarding their areas of responsibility. The Development, Product Management, and User Experience Role Clusters are often active in determining what to include in the functional specification.
As with the project plan and the project schedule, the primary purpose of the functional specification is to specify what work will be done in the Developing, Stabilizing, and Deploying Phases and how the work will be done.
Baseline early , freeze late is an MSF best practice. The functional specification is a living document, and the team continues to update it and add to it throughout the project. The Program Management Role Cluster should baseline the functional specification so that it contains enough detail to make accurate planning and scheduling possible. Developing the specification is an iterative process: The Program Management Role Cluster should expect to add to and refine the document as planning progresses, and to some extent during the Developing and Deploying Phases, when the document is under change control. The team freezes the functional specification at the end of the Developing Phase before moving on to the Deploying Phase.
Initially, creating the functional specification is typically a matter of assembling deliverables produced during the Envisioning and Planning phases and identifying the areas to expand on later in the project.
Determining the Functional Specification Contents
The functional specification documents the design process, incorporating the conceptual, logical, and physical designs. Accordingly, high-level design decisions such as server placement and network configuration, as well as aspects of the physical design such as configuration and initialization documents, should be documented in the functional specification. The team will not create some of these documents until the Developing, Stabilizing, and Deploying Phases, so it is not possible to include these components as part of the baseline. For the functional specification, however, components can be identified that the team must develop later.
The functional specification should include some or all of the following:
A summary of the vision/scope document as agreed upon and refined, including background information to place the solution in a business context
Any additional user and customer requirements beyond those already identified in the vision/scope document
Specifications of the components that will be part of the solution, such as Windows and the 2007 Office system
During the Envisioning Phase, the project team defined the scope of the project as dictated by time, budget, and other considerations. Part of creating the functional specification is deciding which specific components of the solution fall within the scope and which do not. Document elements such as:
Which hardware configurations the development effort will support (for example, hard disks, video cards, other peripherals).
Which applications to include as part of the baseline.
Version information for all the software to be deployed.
The methods to use to deploy the baselines (for example, servers and/or CD-ROMs, images and/or unattended installations).
Developing the Project Plan
The project plan is a collection of plans that addresses the tasks the six team roles perform to carry out the project as defined by the functional specification. Not every project requires every plan listed here, and some projects may require additional plans. This section includes the following plans:
Development plan
Test plan
Deployment plan
Pilot plan
Communications plan
Training plan
Facilities and Hardware plan
Budget plan
Most of the plans in the project plan should be just a few pages long. The Program Management Role Cluster takes the lead in assigning the writing of plans to the appropriate roles, assisting with plans when needed, and assembling the project plan.
To facilitate developing the test plan, BDD 2007 includes the sample Test Plan, Test Specification, and Test Cases Workbook job aids. The Client Build Requirements and Vision/Scope job aids support the development plan. Also included are the Communications Plan, Pilot Plan, and Training Plan job aids.
Creating the Development Plan
The development plan is a crucial component of any infrastructure deployment project. It describes the approach the project team takes to develop the solution during the next phase to meet the requirements of the vision and scope. The Development Role Cluster takes the lead in creating this plan.
Among the areas the development plan can cover are:
Team roles and responsibilities—specifically, detail each developer’s areas of responsibility.
A list and description of the deliverables the developers will produce. Typically, these include:
The actual scripts produced, including any modifications made to the scripts and configuration files.
A description of the baseline architecture and the steps the team takes to deliver it.
A list of the additional applications to be deployed as part of the baseline, including the 2007 Office system, along with any installation packages the team must create or customize.
The kinds of documents, such as installation procedures and software configurations, that the Development Role Cluster expects to create during the Developing Phase.
A brief treatment of the team’s approach to using unattended installations versus disk images. Expand on this in the deployment plan.
Plans for interim builds, including how many to create and which aspects of the solution will be covered in each interim build.
Although the development plan is primarily intended for the developers, another goal of the plan is to formalize processes and plans to aid in the support and ongoing management of the solution. When the project team hands over responsibility for the solution to ongoing support and operations personnel, the latter group should be able to use these documents (covering such things as installation procedures and software configurations) to deploy Windows to new computers and provide technical support. The developers should make an effort to complete and submit this documentation at the same time they submit the corresponding solution scripts so that support and operations personnel have immediate access to all the available information on the solution.
Creating the Test Plan
The test plan outlines the strategy the team uses to test the solution. In this solution, different test plans are generated. For the overall initiative, the test plan addresses the verification of the process, image, and infrastructure needed to deploy the new desktop images and the required supplemental applications. The Application Compatibility feature team requires a detailed test plan to identify the relevant business applications to test and which tests to perform. The Computer Imaging System feature team must define the supported hardware profiles of the target infrastructure and test the different images for specific driver requirements for the hardware. A significant portion of the migration initiative will be spent in testing, so take time to identify the testing requirements and plan accordingly.
The Test Role Cluster typically takes the lead in creating the test plan. Areas to cover include:
A description of the testing environment. Diagrams and schematics can help illustrate the environment.
Change control and how it will be enforced.
Issue-tracking procedures. Describe the issue-tracking database that will be used, including the program used to create it, who will have access to it, and the fields to be used.
Who is responsible for testing each part of the solution.
Test matrices that address which components of the solution team members must test and in what way. For example, a team may plan to develop test matrices for installation, configuration, the operating system, and the suite of applications.
The materials the project team must create the developing and testing environments.
The test plan should specify the types of testing the team performs during the Developing Phase. Typical types of testing include:
Installation testing. Installation testing ensures that each component has been installed without error. The tester installs a build and verifies that Windows Setup runs and finishes correctly, that application setup and configuration programs run and finish correctly, and that the process correctly installs every component included in the build.
Configuration testing. Configuration testing ensures that the installation process configures each component correctly as indicated in the configuration documentation.
Functionality testing. Functionality testing ensures that basic operating system and application functions work as expected without error. Functionality testing is not a repetition of testing that the manufacturers of the hardware and software performed. Rather, it verifies typical use scenarios. In this respect, functionality testing is much like user acceptance testing, except that project team members perform functionality testing before user acceptance testing.
User acceptance testing. User acceptance testing ensures that the system as a whole operates in a manner that is suitable for users. Typically, this testing involves exposing a few users and IT deployment personnel to the solution and verifying that they can use it to perform their duties.
The team may choose to perform other types of testing, such as regression testing and compliance testing, in accordance with the requirements of the project.
Creating the Deployment Plan
The deployment plan outlines the strategy the team uses to deploy the solution. The main function of the plan is to address the tasks that must be performed during deployment and who will perform them. To this end, the deployment plan can include such information as:
Whether the team plans to deploy the solution in phases or all at once.
The order in which sites will receive the solution, if applicable.
Whether internal IT staff or outside consultants perform the deployment.
Checklists team members will use to perform deployment tasks at each site. The team creates these checklists later in the project.
Plans for a database to keep track of users’ needs.
Procedures to use for migrating data and applications to Windows after a clean installation on an existing computer and for testing migrated applications.
How to handle feedback from the users affected by the deployment.
The Release Management Role Cluster typically takes the lead in developing this plan.
Creating the Pilot Plan
The pilot plan describes the team’s goals for conducting the pilot so as to best prepare for the full deployment. The Product Management or the Release Management Role Cluster typically takes the lead in developing this plan.
This is usually a good time in the planning process to select a group for the pilot, unless political, organizational, or other concerns prevent it. To ensure that the pilot group provides optimum feedback for the Deployment feature team, the group selected for the pilot should be representative of the organization as a whole. Product Management, or in some cases the Release Management Role Cluster, should lead the effort to find a pilot group. If the team already has a good idea which group will be tapped for the pilot, include this information in the pilot plan. If not, record the team’s criteria for an ideal pilot group, including considerations such as:
The number of users to include in the pilot deployment.
The hardware configurations that should be represented in the pilot group.
Any location considerations, such as whether to employ users in a single physical location or scattered over distant offices.
Political or organizational considerations.
In addition to describing characteristics of the pilot group, the pilot plan should identify characteristics of the pilot itself, such as:
How long the pilot lasts.
Which components of the solution will be included as part of the pilot.
How to handle feedback from the pilot, including whether to make modifications to the solution as a result of the feedback.
The pilot success criteria.
Creating the Communications Plan
The communications plan describes how the team communicates with the groups the solution affects. Identify everyone who has a stake in the solution and the level of communication needed. Typically, this includes not only users but also support and help desk personnel, other IT employees, the management staff responsible for budgeting the project, personnel whose work will be disrupted by project-related activities, and others.
The communications plan should prescribe communications strategies for each of the identified groups of people affected by the project. The team will likely have a wide range of options for communication, including:
Face-to-face meetings.
E-mail, including mailing lists.
Printed or electronic newsletters. This step can involve either publishing project-specific newsletters or including project information in existing organizational newsletters. Consider IT newsletters or bulletins, department-specific or site-specific newsletters, and organization-wide bulletins.
Informational intranet Web sites.
Voice mail.
The communications plan should provide strategies for ensuring that every affected group gets the information it needs when it needs it without burdening people with too much information. Part of this task includes picking people with good communications skills to furnish this information. The plan should identify the people responsible for communicating the desired messages to the people who need to know that information.
Creating the Training Plan
The User Experience Role Cluster typically takes the lead in developing the training plan. As with the communications plan, the role should consider the different types of audiences that require training. At the very least, there will be two broad categories of people to consider: users and IT staff, including system administrators and help desk personnel. The role may identify other categories, depending on the requirements of the project.
There is no single right way to do training. Developing a training plan is always done within the constraints of the project. Factors that may influence how training is carried out include user knowledge, time, budget, and availability of skilled trainers and people to develop training. The organization’s culture and type of business may dictate particular training vehicles or the duration or technical level of training.
If the users in the organization are familiar with Windows XP and Windows 2000, for example, they will not require much training to maintain the same or better productivity with Windows Vista. However, additional training can enable them to take better advantage of new Windows Vista features and further improve productivity. IT professionals will typically require more in-depth instruction on the differences between Windows 2000, Windows XP, and Windows Vista.
Likewise, users who have used Microsoft Office XP or Office 97 should be able to learn later versions of the Microsoft Office System without much training. One approach to consider in these cases is a simple Web-based resource guide from which users can learn about the new features of Windows Vista and the 2007 Office system and how they can use them to become more productive.
If users are unfamiliar with the Windows operating system and the 2007 Office system and require more training, several options are available, including:
Hands-on training, in which the user learns the software by using it.
Presentation-style training, in which the user takes classes in using the software.
Computer-based training (CBT) or Web-based training (WBT), in which special training software educates the user.
One-on-one training.
Job aids or handouts.
When designing training for IT staff, consider whether they must understand the entire unattended installation process or just portions of it and whether they will need to understand how to return a computer to the baseline configuration. Consider hands-on training and self-study methods. The documents the team creates as part of the functional specification can be invaluable teaching aids for IT staff.
Note Microsoft Learning Solutions is a cost-effective, self-hosted learning solution that provides valuable software training and reference materials on Microsoft products and technologies. For more information about Microsoft Learning Solutions, visit https://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 https://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 Plan
If the project involves deploying the solution to existing computer systems, consider drawing up a facilities and hardware plan detailing how many computer systems in the organization meet these requirements and how many fall short. If a significant number of the computers fail to meet the requirements of Windows Vista or any of the software applications to be deployed, for example, use this plan to describe how the team will approach these computers. Possible courses of action include:
Deploying only to those computers that are capable of running the solution and leaving the others untouched until they are upgraded or replaced at a future time.
Planning upgrades and replacements of the less-powerful computers over time and including the upgrade cost in the project budget.
Purchasing new hardware, such as RAM and hard disks for the less-powerful computers to bring them in line with the project specification.
As with the other components of the project plan, there is no right way to develop the facilities and hardware plan. The constraints imposed by time, budget, and other external considerations will dictate in part the team’s approach.
The Program Management or the Release Management Role Cluster typically takes the lead in developing this plan. An area that should be carefully considered in the facilities and hardware plan is the potential volume of disk storage required during the deployment process. In the deployment process, two options can significantly affect the amount of server disk space required during the deployment. The first is the use of USMT to capture all user data files, settings, and preferences from the computer onto a network share on the data server. This option can quickly increase the amount of space required on the data server. The second is the option to create a backup image of the entire computer before the migration. This option can add gigabytes per user to the amount of space required on the server. Most organizations retain this data only temporarily, so the disk requirements are also temporary. Teams can put these options into effect on a can-be-changed-on-a-user-by-user basis.
For a detailed description of the capacity requirements, refer to the Lite Touch Installation Guide.
Creating the Budget Plan
If cost will be a deciding factor in how the team implements the solution—which it will in most cases—the team should draw up a budget plan detailing how it will spend the money available. The budget plan should be the final component of the project plan. Program Management takes the lead in developing this plan, waiting until the rest of the project plan is complete before finalizing the budget to ensure that the budget is as accurate as possible, with all items accounted for. Areas to consider when creating a budget for the project include:
The software the organization must purchase or license for the solution, including Windows, the 2007 Office system, and any non-Microsoft software to be deployed as part of the solution.
Development tools or other software the project team purchases as part of the deployment process.
Hardware and networking equipment the team deploys or uses during development.
Contractors or other outside professionals the team shire to help with development, testing, training, or other project-related activities.
Training courseware or other training aids.
Creating the Project Schedule
The project schedule is a compilation of schedules created by team members for the purpose of planning their activities. It can include some or all of the following as appropriate:
A development schedule
A test schedule
A user experience schedule
A release management schedule
A deployment schedule
Any role may choose to divide its schedule by functional area. For example, if different development sub-teams will be working on the imaging and application packaging architectures, each sub-team might create its own schedule.
Creating Project Schedules
Each role lead performs a functional breakdown and prioritization of the role’s responsibilities, while team members perform task-level estimating. The length of an individual task should be between a half day and a week. If the task duration is too short, the overhead in managing the task may be too high. If the task duration is too long, it is difficult to manage the scope of the work.
In addition to planning task durations, the team members creating the schedules should assign names to tasks. After creating the vision/scope document, solution design document, and project plans, role leads should know which team members will be responsible for specific areas. Schedules make these assignments more specific so that all team members know what they will be doing and when.
Projects of this nature can take anywhere from a few weeks to several months. When scheduling the project, consider factors such as:
The size of the organization.
The extent of the deployment.
The number of hardware configurations affected.
The number of applications to support.
How to handle data migration.
The availability of resources.
The amount of customization required.
The requirements of different groups driving changes to the functional specification.
Whether the project team is assisted by third parties, such as consultants, who have experience with similar projects.
The Developing Phase in typical desktop deployment projects in medium (5000 to 10,000 users affected) and large (more than 10,000 users affected) organizations might take 6–10 weeks. Project management software such as Microsoft Office Project can help create the project schedule. Project management software has features that enable teams to assign duration, resources, and prerequisites to tasks and automatically calculate important dates.
Assembling the Project Schedule
Program Management compiles and coordinates the schedules that the different roles submit so that team members can work effectively. The resulting document is the project schedule.
Program Management should build buffer time into the schedule to compensate for schedule slippage caused by unforeseeable delays. Team members should not view buffer time as a development cushion and should use it only if necessary and at the program manager’s discretion. To protect the buffer time from outside influences, designate internal milestones that are visible only to the team and separated from the externally visible milestone by buffer time (see Figure 5). For example, the team might plan to complete the Developing Phase by April 10 but designate April 17 as the externally visible milestone date for Developing Phase completion. The period of time between April 10 and April 17 would be buffer time.
.gif)
Figure 5. Planning buffer time
Creating the Development and Testing Environment
A key task of the Planning Phase is the creation of an environment in which team members can develop and test the solution without affecting day-to-day operations for other users. The development environment should be physically separate from the testing environment, though they may share some of the same resources at different times.
The development and testing environment is typically referred to as the lab, though it may not always be physically separate from the existing production environment. Weigh the costs and benefits of physical separation before creating the lab. By contrast, all developing and testing work should take place in an isolated network or a non-production Windows domain and network segment, if possible. Production users should not be granted access to computing resources in the lab, and the work that the developers and testers perform should not affect work that users perform.
The lab should contain at least one computer for each hardware configuration identified in the physical design. Remember that computers can be shared between the Development and Test Role Clusters, though not at the same time; use this setup to cut down on development costs, if necessary. For example, Development might use some computers and domains and hand them off to Test later in the Developing Phase.
Design the testing environment to emulate the production environment as closely as possible, as in the following example:
The corporate wide area network (WAN) encompasses 540 computers in six basic hardware configurations. The WAN is a Virtual Private Network (VPN) consisting of the home office in Minneapolis; five sales offices throughout Minnesota , Wisconsin , and South Dakota connected to the Internet through T-1 lines; and a service center in Eden Prairie , Minnesota , on an asymmetric digital subscriber line (ADSL) link. The testing environment will contain one computer for each hardware configuration , each of which from time to time will be connected either directly to the corporate local area network (LAN) or to the Internet , either through a dedicated T-1 line or an ADSL line installed in the testing lab.
Interim Milestone: Technology Validation Complete
To achieve this milestone, the project team must manually install the technology components of the solution on pristine hardware in the most accommodating environment. The goals of this milestone are to minimize extraneous variables and to ensure that the technology components work and conform to the functional specification.
Key Milestone: Project Plans Approved
At the Project Plans Approved Milestone, the project team and key project stakeholders agree that interim milestones have been met, due dates are realistic, project roles and responsibilities are well defined, and mechanisms are in place for addressing areas of project risk. The functional specification, the project plan, and the project schedule provide the basis for making future trade-off decisions.
After the team approves the specifications, plans, and schedules, the documents become the project baseline. The baseline takes into account the various decisions that are reached by consensus by applying the three project planning variables: resources, schedule, and features. After the baseline is completed and approved, it is placed under change control. This does not mean that all decisions reached in the Planning Phase are final. But it does mean that as work progresses in the Developing Phase, the team should formally review and approve any suggested changes to the baseline.
Planning Phase Checklist
Before proceeding to the Developing Phase, the following items should have been addressed:
Application list, SMEs, and media
Application packaging under way
Core applications migration plan
Functional specification approved
Lab environment established for development and testing
Network diagrams created and analyzed
Operations review/assessment of the functional specification
Project plan created
Project schedule created
Risk management plan updated and reviewed
Security policies, strategies, and configuration
Security review/assessment of the functional specification
Technological approach has been validated
Test plan created
Computer application inventory conducted and reviewed
Computer hardware inventory conducted and reviewed
Moving to the Developing Phase
When all the Planning Phase tasks are complete, the team must formally agree that the project has reached the Project Plans Approved Milestone. By completing the milestone, team members indicate that they are satisfied with the work performed in their areas of responsibility.
As before, project teams usually mark the completion of a milestone with a formal sign-off, including sign-offs by the customer and other key stakeholders. The sign-off document becomes a project deliverable and is archived for future reference.
Download
Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007
Update Notifications
Sign up to learn about updates and new releases
Feedback