Back Up Next

Chapter 5: Infrastructure Deployment Track Milestones

Certification Objectives. 2

The Elements of the Enterprise Architecture. 3

From the Classroom.. 5

Process Model 5

Achieving a Shared Vision for the Infrastructure Deployment Project Team.. 6

Vision/Scope Approved Milestone Envisioning Phase. 6

Vision. 6

Scope. 6

Tasks That Occur During the Envisioning Phase. 7

Team Formation Complete. 7

Draft Vision/Scope. 7

Final Vision/Scope. 8

Roles and Responsibilities of Infrastructure Deployment Team Members That Lead to Vision/Scope Approval 8

Deliverables Produced During the Envisioning Phase. 8

Writing the Vision/Scope Document 8

Vision/Scope Document: Description of Deliverables and Content 9

SMART Vision/Scope Document Content 9

Exercise 5-1: Envisioning Phase. 9

Setting the Target for the Project Plan Approved Milestone. 9

Roles and Responsibilities That Lead to the Project Plan Approved Milestone. 10

Deliverables To Be Produced at Project Plan Approved. 10

Conceptual Design Document 11

Design Specification Drill Down and Detailed Descriptions of Deliverables and Content 11

Master Project Schedule Drill Down and Detailed Descriptions of Deliverables and Content 12

Master Project Plan Drill Down. 12

Defining the Focus and Deliverables of Each MSF Team and Their Role at Project Plan Approved. 12

Test Lab Setup. 13

Risk Assessment 13

Business Manager Approval 13

Exercise 5-2: Planning Phase. 14

Tasks That Lead to the Scope Complete/First Use Milestone. 14

Identifying the Interim Milestones Leading to Scope Complete/First Use. 14

Listing the Interim Milestones Leading to Scope Complete/First Use. 14

Defining the Focus and Deliverables of Each MSF Team and Their Role at Scope Complete/First Use. 15

Describing the Process for Driving to the Release Milestone. 16

Exercise 5-3: Developing Phase. 16

Defining the Release Milestone. 17

Tasks That Occur During the Release Milestone. 17

Describing the Deliverables for the Release Milestone. 18

Describing the Focus for Each MSF Team Role at Release. 18

Identifying the Activities Leading to the Release Milestone and Laying the Foundation for Future Projects. 19

Exercise 5.4: Stabilizing Phase. 19

Exercise 5.5: Identify the phase for the following interim milestones and deliverables. 19

Certification Summary. 20

Two-Minute Drill 20

Answers to Exercise 5-1. 21

Answers to Exercise 5-2. 21

Answers to Exercise 5-3. 21

Answers to Exercise 5-4. 21

Answers to Exercise 5-5. 21

 

Certification Objectives

·       Enterprise Architecture Overview

·       Infrastructure: Overview and Drill Down

·       Infrastructure: Deployment and the MSF Process Model

·       The Vision/Scope Approved Milestone

·       The Project Plan Approved Milestone

·       The Scope Complete/First Use Milestone

·       The Release Milestone

You’ve learned about the MSF team model and process model. You’ve applied these models to software development. Now it’s time to apply them to infrastructure projects. Why should a programmer, an MCSD, care about infrastructure projects? Because we do so much more than code. Much of what we do requires working with networks, hardware, and even phones. We increase our professional value by expanding our expertise out of the developer’s cube into the real-world workings of the enterprise. In this chapter, we’ll discuss the MSF guidelines for infrastructure deployment.

Enterprise Architecture Overview

Enterprise architecture is built on the interdependencies of people, process, and technology. We have technology to aid productivity, and each team member brings unique skills and characteristics to the process. Figure 5-1 illustrates the MSF enterprise architecture.

Figure 1: Enterprise architecture consists of people, process, and technology

Thinking about the architecture of our enterprise helps us to categorize the various components of an organization. It’s a way of breaking down the whole into understandable pieces. Not only can you view the enterprise architecture of an entire business, but also the architecture of the IT organization, which is, the focus of this chapter. The enterprise architecture consists of people, technology, and processes.

The Elements of the Enterprise Architecture

One crucial element of the enterprise architecture is people. People use technology, create processes, and provide the intellectual energy to keep our enterprise moving forward. In the end, the benefit comes back to people. Sometimes developers want people to adjust to the technology, and we may even want them to change processes because of how our technology works. A more balanced view of the enterprise architecture leads developers to value the people in the organization.

The second element of enterprise architecture is processes. For example, computer departments commonly buy new desktop systems in batches after a bidding process. The bidding process is a well-established procedure for getting good prices. There are forms involved, relationships with vendors, and reasonable criteria for making a decision. Processes exist on every level of the organization, for everything from rudimentary daily tasks to the hiring of a new CIO. Every good programmer knows how to isolate the process from the people who use it, and from the technology it may run on.

The third element of enterprise architecture is technology. Technology doesn’t mean just the network. It includes things like writeable CDs, Visual Studio 6.0, and phones. Remember that the enterprise architecture is not limited to a location, nor is not identified by size. It’s a model that we use to define organizational roles.

Infrastructure: Overview and Drill Down

Let’s understand the technology infrastructure of organizations by using an analogy. The infrastructure of a nation consists of things like roads, power facilities, waterways, airports, and phone lines. These are the systems that keep the country functioning. Infrastructure consists of both facilities and services. A school can be considered part of the infrastructure because of the service that goes on there, education, which produces people with the necessary skills to contribute to the larger enterprise.

Exam Watch: Understand the relationship between enterprise architecture and technology infrastructure.

The technology infrastructure consists of the resources that support the organization’s computing environment; that is, the systems that we need for the functioning of the computing environment. Figure 5-2 shows the relationship between the enterprise architecture and the technology infrastructure. Like the overall architecture, the technology infrastructure includes people and processes, as well as technology. The people in the infrastructure use, buy, and maintain the technology. Common processes in a technology infrastructure include network design, setup of personal systems, and training. The following are Microsoft’s eight categories of the technology portion of the infrastructure:

1.     Data transmission links

2.     Local area network architecture

3.     Wide area network architecture

4.     Protocols and transports

5.     Network operating systems

6.     Computer hardware

7.     Computer software

8.     Domain/site models

Figure 2: People, process, and technology come together in the technology infrastructure

The technology infrastructure exists to meet the business needs of the organization. We are the roads and bridges, the power lines and coal mines of the organization; the job we do makes it possible for the rest of the organization to meet the business goals.

Infrastructure: Deployment and the MSF Process Model

Deploying a new technology infrastructure element brings up issues such as the technical problems of getting operating systems to work together, dealing with aging hardware, getting enough server power for the job, and a number of resource allocations. Managers need to assign the appropriate resources to the task, establishing an appropriate budget. Managers also need to rally people around the business need that the new project is to address. Even with the best equipment in the world, you cannot neglect the workplace environment.

No one can fail to be impressed by the array of quality products Microsoft has produced in recent years. They have solved the problems involved in rolling out new technologies, and they share the answers with the rest of us.

At the core of the solution development discipline is the MSF process model, the subject of the rest of this chapter. You’ve already seen this model applied to software development; now it’s time to apply it to infrastructure deployment.

Exam Watch: Develop a thorough understanding of the MSF process model.

Figure 5-3 illustrates the MSF process model. From the first spark of an idea, envisioning leads to the vision/scope approved milestone. Planning will take you to the project plan approved milestone. The scope complete/first use milestone yields itself after a healthy dose of development. And finally release signals the end of the deployment phase. Working with the MSF model helps us to minimize problems, efficiently use resources, and achieve our business goals. The details of each milestone and phase make up the rest of this chapter, the core of the infrastructure deployment process.

Figure 3: The MSF process model has phases and milestones

From the Classroom

Process Model

The process model is an iterative process that allows for multiphase development projects to assume an organized, continuous, development process. It ensures the necessary emphasis on design and planning, which is often overlooked in many development projects. Special emphasis should be placed on the development of scope documents. Without a properly developed scope document, all aspects of a project are subject to increased risk and will not reach the desired milestones. Remember the SMART requirements of a vision/scope document: Specific, Measurable, Achievable, Results-based, and Time-oriented.

In preparation for the exam, or for leveraging the MSF process model for the first time, become familiar with the interim milestones and deliverables that map to each of the four phases of the MSF process model. It is also important to become familiar with the functionality and responsibilities of each of the six roles identified. Be able to match up a given project task with both the phase within which it should reside or be carried out, and the role responsible for carrying out the task.

by Michael Lane Thomas, MCSE+I, MCSD, MCT, MCP+SB, MSS, A+

The Vision/Scope Approved Milestone

When you achieve the first milestone of the infrastructure deployment process, you will have articulated a clear and inspiring vision and will have set an achievable scope for the project. A team effort must begin with a sense of vision. The larger the project, the more important a strong vision becomes. The vision motivates a team—it’s the focal point around which they can concentrate their best efforts. A team with a strong vision has members who feel they are important to the overall goals, and are all committed to a common purpose.

Vision supplies the why, which inspires the how. Good team leaders communicate vision both verbally and visually. Developing vision is much more than coming up with a mission statement that you post on your wall. The overriding sense of purpose must be active in the minds of team members. Remind your people of the vision; get excited about it; show everyone how they can have a fulfilling part of the new mission. Once a team begins to congeal around the vision, it’s ready to begin a phase of high-quality action.

Vision and scope work together. Vision points the direction; scope says how far. Scope helps team members see that real achievements can be met. Once the excitement of vision fades, the task can seem daunting, but scope reigns in the vision and helps people see the end of the tunnel.

Achieving a Shared Vision for the Infrastructure Deployment Project Team

Vision grows from a business need. The sustaining force of vision is the value to the organization. Vision has to result in something good for the business. Everyone should be able to agree on the fact that your project will be beneficial to the college, bank, charity, investment firm, or manufacturer you work for.

Achieving vision and scope takes time, lots of communication, and some interim steps. Microsoft suggests some interim milestones to mark your progress along the way. Deliverables mark the conclusion of each step. The envisioning phase culminates in the vision/scope document.

Vision/Scope Approved Milestone Envisioning Phase

The process of envisioning brings the team to the vision/scope approved milestone. At this milestone the members of the project team, the customer, and key project stakeholders reach a common agreement on the essential parts of vision and scope. These elements include the overall vision, the business requirements to be met first, time frame, risks, assumptions, business constraints, and the level of effort to give to the next phase, which is planning. Envisioning is a very creative process, characterized by excitement and enthusiasm.

Vision

Vision addresses how the business will change with the new solution. It identifies the business problem and provides the context for the solution. The vision doesn’t have limits. During envisioning, team members do not need to consider technical constraints. To reach the milestone, the differing ideas of vision must converge into a single agreed-upon statement.

Scope

During envisioning people take the vision and compare it to the reality of the situation. This gives the vision appropriate scope. Scope includes the elements essential for success, as made clear by the customer. While deciding on scope, team members consider things like the urgency of various pieces of the solution, which things can wait until the next release, and the constraints and risks involved with the project.

Resources, schedules, and solution functionality each impact the shape of the project. More functionality demands more resources and time. Envisioning is the time to decide how much time and money the result is worth. The scope should let the project achieve solid results while keeping costs and risks down. With most projects, the law of diminishing returns will eventually kick in. Setting an appropriate scope will make sure that benefit is maximized.

Tasks That Occur During the Envisioning Phase

Before you reach the vision/scope document and the approval milestone, Microsoft suggests some helpful intermediate points to measure progress. A team should have a deadline for each of these points. These interim milestones are: team formation complete, draft vision/scope, and final vision/scope. Table 5-1 describes the nature and effect of each milestone.

Interim Milestone

Description

Effect

Team Formation Complete

Team roles have been scaled to the needs of the project. Skill sets are identified. Primary team members are assigned tasks.

Encourages ownership of tasks. Ensures the timelines and quality of deliverables.

Draft Vision/Scope

Has problem statement, solution concept, and procedure for training during the project. Identifies the customer.

Defines what the teams do and why. Ensures that participants are together on the nature of the problem and solution.

Final Vision/Scope

The deliverables have been produced. Success factors and business improvement metrics are documented.

Establishes viability. Team and customer understand their responsibilities.

Table 1: The Envisioning Phase Has Three Interim Milestones

Team Formation Complete

Microsoft identifies six roles for members of a team: product management, program management, development, testing, logistics management, and user education. Team formation happens when particular team members take on each of these roles. During team formation, leaders match skill sets to roles, and each member commits the time necessary to complete the project.

Getting the right people for the job assures the quality of the product. Once the team has been formed, members take on a sense of ownership of the project. Reaching this milestone means that the project has gotten off the ground. Members have a sense that the project is underway. Once together, the core team can do the work of crafting a central vision.

Draft Vision/Scope

The two key elements of the vision/scope draft are the statement of the problem and the sketch of the solution. Make sure that your solution matches the problem! Establish the customer for the project. This is not always as simple as it might seem. For example, an IT department of a college may want to deploy an ATM network. Who is the customer here? All the potential users? The president of the college who got the grant for the network in the first place? Keep in mind that the customer will play a part in the rest of the process. You want to clearly identify the customer to allow them to participate in the following steps. The customer should see your draft statements at this stage, and give preliminary approval.

Final Vision/Scope

At this milestone the deliverables for the envisioning phase are complete. When this milestone has been met, both customers and team members understand their responsibilities for the project. By this point, the viability of the project should be apparent to all.

Roles and Responsibilities of Infrastructure Deployment Team Members That Lead to Vision/Scope Approval

Each team member has a part to play in the envisioning phase. Product management identifies the problem, and documents the need. Product management also articulates the vision. Program management comes up with the design goals and documents the solution. Developers do the critical job of researching solutions and coming up with technical options. User education prepares by deciding on the requirements for training, as well as training scope. Testing creates criteria based on design goals. Logistics management reports on material constraints and considers long-term management and support.

Deliverables Produced During the Envisioning Phase

Table 5-2 describes the deliverables that the team produces in the envisioning phase.

Deliverable

Content

Vision/Scope Document

·       Problem statement/business objectives

·       Vision statement

·       User profile

·       Solution concept

Risk Management Plan

·       Identifies risks

·       Identifies new technologies that should be monitored

·       Identifies organizational issues that might impact the progress of the project

Project Structure

·       Defines how the project will be managed and supported

·       Defines the administrative structure for the project team, such as reporting structure, meetings, and schedules

Table 2: Deliverables of the Envisioning Phase

Writing the Vision/Scope Document

The vision/scope document, the deliverable that marks the vision/scope approved milestone, has several necessary characteristics:

·       It provides a clear direction for the team.

·       It sets customer expectations.

·       It approximates the risk involved in the project.

A baseline for planning, design, and deployment comes from the vision/scope document.

Vision/Scope Document: Description of Deliverables and Content

The vision/scope document has four parts. The first is the problem statement and business objectives, which address what you want to do and why you want to do it. Next is the vision statement itself, the heart of the document. This statement articulates the direction of the business and shows how the project contributes to the mission. The user profile lists the people that the project impacts. Finally, the solution concept gives the timeline for the project and, of course, sketches how the team intends to solve the stated problem.

SMART Vision/Scope Document Content

A SMART vision/scope document is Specific, Measurable, Achievable, Results-based, and Time-oriented. If the vision for your project is vague and hard to measure, how will you know when you’ve reached your goal? A specific and measurable vision and scope can help the team recognize the progress they are making as well as giving the project a clear end point. The middle of a project is not the time to discover that you don’t have the resources, expertise, and technology to get it done. You should be able to determine up front whether you can reach your objective. A good working timeline should be defined in the vision/scope document. In addition to the qualitative and quantitative measurement set out in the document, you should make sure that the document keeps the results in focus.

Exercise 5-1: Envisioning Phase

Identify the role responsible for each of the following tasks:

Research potential technical solutions: _____________________

Determine the requirements for training: ____________________

Articulate the vision and identify the problem: ________________

Determine the design goals: ______________________________

Create criteria for test suits based on design goals: _____________

Determine any material constraints: _________________________

The Project Plan Approved Milestone

The main task of this phase is planning. Your vision is in place; you know what the problem/need is; and you have a good handle on a solution. Now you have to plan the many details of your project. Have you ever been in the middle of a seat-of-the-pants project and thought that some day we’re going to do this the right way? Well, now is your chance. Just as a well-designed program tends to flow from your fingers and come together in good order, a well-planned infrastructure project puts peace in your soul.

Setting the Target for the Project Plan Approved Milestone

At the project plan approved milestone, agreement has been reached on a number of important items:

·       Project deliverables

·       Functional priorities

·       Risks

·       Ship date

·       Project plan

·       Business requirements

·       Conceptual design elements

·       Design specifications

·       Time and effort to complete project

Roles and Responsibilities That Lead to the Project Plan Approved Milestone

As with envisioning, three interim milestones occur during planning: conceptual design complete, design specification complete, and master project plan complete. Deliverables for this phase considerably outnumber those for envisioning. Table 5-3 lists each milestone with its measurement and effect on the project.

Interim Milestone

Measurement

Effect

Conceptual Design Complete

The vision, characteristics, distinctive benefits, and how the target audience will interact with the proposed solution are defined.

Structures the solution and ensures that activities adhere to the overall mission and objectives.

Design Specification Complete

Defines the technical components of the solution in detail and determines how they will be implemented.

Assigns technical detail to the structures defined in the functional specification.

Master Project Plan Complete

The master project plan includes the approach, dependencies, and assumptions of the project, as well as budget and costing information.

Ensures that all the participants have a common understanding relative to the functionality desired, resources required, and time constraints.

Table 3: Milestones of the Planning Phase

Deliverables To Be Produced at Project Plan Approved

The deliverables produced during this phase set the parameters and establish a guide for development. The planning phase documents can and do still change with time; they are not set in stone. These documents belong to the program management role, who should alter them as the process helps to define itself. Figure 5-4 illustrates the deliverables for the planning phase.

Figure 4: The planning phase has three deliverables

Conceptual Design Document

Conceptual design, a non-technical document, describes what the final product includes. This detailed document covers the functionality of the solution, how the product might impact the current infrastructure, and the relationship between user and product. The conceptual design document includes a vision/scope summary, which is a refined distillation of the results of the previous phase. Of course the conceptual and logical design is fully detailed within the document. This deliverable also includes design goals, usability goals, constraints, and expectations. Besides acting as a guide to developers, the design goals give the testing team something to test. Detailed field surveys can be an important part of this deliverable. The project team must be able to gauge expectations for the solution. Documenting these expectations at this stage can be very helpful. Finally, the conceptual design document includes user profiles and usage scenarios. The scenarios focus on the environment as it will be, comparing it to the present environment.

Design Specification Drill Down and Detailed Descriptions of Deliverables and Content

While the conceptual design provided a non-technical view of the solution, the design spec itself fills in these technical details. Here’s where you get into the fun stuff, thinking of hardware and all the nuts and bolts of your solution. Additionally, this deliverable lists standards and guidelines, change control methodology, the life cycle management plan, and the security plan. Table 5-4 presents these parts.

Item

Description

Logical and physical design

The details of the team’s solution.

Standards and guidelines

Ensures that the proposed solution facilitates the communication, integration, and consistency of information between and within elements of the organization.

Change control methodology

Framework for establishing why the change is needed, who is accountable for the change, what the impact of the change is, and how the change will be traced.

Life cycle management plan

Considers the rapid evolution of individual and aggregate technologies, together with dynamic organizational factors.

Security plan

Serves to ensure that data, resource, and service integrity are maintained during the project.

Table 4: Design Specification Content

Master Project Schedule Drill Down and Detailed Descriptions of Deliverables and Content

The schedules contained in this deliverable are also not set in stone. Scheduling can be an iterative process, but the mechanism for dealing with project schedule changes must be established. The master project schedule evolves over time. This deliverable consists of a task list, implementation schedule, test schedule, preliminary training estimates, logistics schedule, and marketing schedule.

Master Project Plan Drill Down

The master project plan consists of the following plans: implementation, test, user education, logistics, solution marketing, and also a budget. The user education plan can be a key component of this deliverable. Your team should have idea of what kinds of solutions it will take to help users work with the product. A needs assessment, purpose statement, and evaluation strategy are parts of the user education plan.

Defining the Focus and Deliverables of Each MSF Team and Their Role at Project Plan Approved

Table 5-5 gives a complete listing of each MSF team role during the planning phase. As with all the other phases, each team has a very important role in planning. Ownership for the project really starts to take off in this phase, as each member gets a clear grasp on how they’re going to contribute to the solution. The remaining deliverables are test lab setup, risk assessment, and business manager approval.

Team

Role

Product Management

·       Project vision

·       User needs analysis

·       Schedule

Program Management

·       Project design

·       Project master plan/schedule

Development

·       Technology evaluation

·       Physical design

·       Development plan/schedule

User Education

·       User performance solution strategy

·       Training needs

Testing

·       Design evaluation

·       Testing plan/schedule

Logistics Management

·       Materials/facilities procurement

·       Rollout plan/schedule

Table 5: Responsibilities of Each Team in the Planning Phase

Test Lab Setup

Planning test lab setups includes deciding who will be responsible for the labs, what activities will be performed there, how the lab should be configured, and how to establish the guidelines and policies for the lab. Like the SMART vision/scope document of the previous phase, Microsoft suggests a BEST way to define the main focus of the test lab. BEST stands for:

·       Baseline and backup, making sure that your system can return to the original state in the case of a problem

·       Eliminate risk by working through the problems and coming up with acceptable solutions

·       Stress testing the solution under full load

·       Testing and tracking, testing transitional components and generating useful statistics

Risk Assessment

Risk assessment goes on through all phases, but planning is a good time to start eliminating risk. The team should prioritize and identify the most probable risks. Work on plans to mitigate these top risks and incorporate the plans into the project plan, providing necessary additional resources.

Business Manager Approval

The business manger approves the budget and resources required for the project. This deliverable represents the last element of the planning phase. Once you’ve got your resources, you’re ready to move to the next phase.

The Scope Complete/First Use Milestone

This milestone comes as your hard work begins to pay off. The scope complete/first use milestone occurs when your solution has been tried in a production environment and your team has consensus on the solution meeting the objectives of the vision/scope document. Figure 5-5 shows our progress through the process model. The developing phase has its own set of interim milestones and deliverables, which we will discuss in turn.

Figure 5: Developing leads to the scope complete/first use milestone

Exercise 5-2: Planning Phase

Identify the role responsible for each of the following tasks:

Project vision, user needs analysis, and a schedule: _______________

Project design and the project master plan/schedule: _______________

Design evaluation and the testing plan/schedule: __________________

Materials/facilities procurement and the rollout plan/schedule: _______

Technology evaluation, the physical design and the development plan/schedule: _______________

User performance solution strategy and training needs: ________________

Tasks That Lead to the Scope Complete/First Use Milestone

As with other phases, interim milestones help developers track progress on the way to the completion of the phase, the scope complete/first use milestone. In this section we’ll look at each of the interim milestones and discuss how they fit into the developing phase.

Identifying the Interim Milestones Leading to Scope Complete/First Use

Three somewhat similar milestones happen along the way to scope complete/first use. Each involves testing. The lab test complete interim milestone makes use of a test lab, which the team planned in the previous phase. This lab does not mimic the production environment, but verifies the soundness of the solution’s functionality. At lab test complete, the pieces of the solution have been tested. Some problems will be discovered and alternatives tested.

The proof-of-concept complete interim milestone takes place in the proof-of-concept lab. This lab, a successor of the test lab, does mimic the production environment. Here the whole model of the solution gets a test. The main goal of the proof-of-concept complete milestone is to reduce as much of the risk as possible. Here’s where you try the product without risking other enterprise resources.

The pilot complete interim milestone means that you’re almost ready to begin deployment. During the pilot, your team deploys a portion of your system in the actual user environment. Hopefully the bugs have been worked out by this stage, but you’ll likely find any that are left, without sharing them with the whole organization.

Listing the Interim Milestones Leading to Scope Complete/First Use

Table 5-6 gives each milestone’s description and effect.

Interim Milestone

Description

Effect

Lab Testing Complete

Testing has been completed in an isolated technology infrastructure lab.

Validates the technology

Proof of Concept Complete

The solution has been installed in a controlled test environment that mimics the anticipated production.

Validates the solution

Pilot Complete

The solution has been tested in a limited, controlled production environment, and all known issues have been resolved or a contingency plan has been developed.

Real-world validation

Table 6: Interim Milestones of the Developing Phase

Defining the Focus and Deliverables of Each MSF Team and Their Role at Scope Complete/First Use

Your team will produce five deliverables during the development phase: pilot plan, training plan, capacity plan, business continuation plan, and rollout plan. Each MSF team has a role to play in developing these documents. Communication through this phase is essential. You want your teams not only to keep each other up-to-date on their progress, but also to let them share ideas and input. First, we’ll discuss the deliverables and then the roles of each team.

The pilot plan sets up the pilot test. It should contain all the necessary steps and procedures to run the test. Be sure that the plan accounts for each usage scenario. You’ll want the pilot to give a realistic representation of the product. Keep in mind that the pilot happens once. The pilot plan sets the stage for escalation to deployment.

Scope/complete first use is the time for training. Your team should complete a training plan as a deliverable for this phase. Good training doesn’t just teach users the mechanics of a solution; it also helps the organization get the greatest advantage possible for your project. With this in mind, your training plan should include a view of how job functions will change with the new solution, training logistics, and conclusions based on the user profiles.

The capacity plan functions as a kind of check to see if you’ve got enough of what you need. Is your infrastructure solution up to the job? Your team must determine if the components of your system can handle their required functions. Additionally, the product should allow for growth, without going overboard. The capacity plan is also a good place to check if your solution fits the vision, at least in terms of being adequate for the job.

The business continuation plan reduces risk by establishing procedures to recover to an acceptable threshold of performance in the case of a disaster. The plan doesn’t restore everything to its pre-failure state, but just gets things working enough so business can continue. To do this, your team must identify the critical systems that have to stay up, and what it would take to bet them back up. Identify areas where load can be reduced; in other words, functions that are not essential and can be shut down to devote resources to the more critical operations. A recovery plan takes the enterprise back to normal from where the business continuation plan leaves off.

And finally, the rollout plan! This plan gets your team ready for the next phase. It contains step-by-step procedures for delivering the solution. The strategy includes who gets the product when, and who will give it to them. The plan addresses how to get this done with minimal disruption. A good key to success for the rollout plan is for your team to get consensus, participation, and ownership of the user community. Don’t assume that everyone will think the product is as super as you do and worth the effort of change. Get the users involved and excited, and they’ll make rollout a lot more fun.

Table 5-7 shows the role of each MSF team during the development phase.

Team

Role

Product Management

·       Customer expectations

·       Schedule

Program Management

·       Functional specification management

·       Project tracking/communication

·       Pilot plan

Development

System compliance

User Education

User/deployment team training

Testing

Issue identification

Logistics Management

·       Operations/support/systems administration

·       Final release schedule

Table 7: Team Roles during Development Phase

Describing the Process for Driving to the Release Milestone

As your team approaches scope complete/first use and starts to think about deploying, some tasks help to wrap up development. During this phase, your team has validated the project. You know now that it will work. Plans made earlier, such as conceptual design, design specification, and project plans should be in their final form and consistent with the solution you are about to deliver. As your team transitions to deployment, work on stabilization of the system, making sure everything is settled and functioning as load begins to increase. Also, take a look at the milestones reached so far, and review what when wrong, and what went right. Examine your successes and failures so the team can be ready for the release milestone.

Exercise 5-3: Developing Phase

Identify the role responsible for each of the following tasks:

Functional specification management, project tracking/communication, and the pilot plan: _____________

User/deployment team training: _______________

Issue identification: _____________________

System compliance: ____________________

Operations/support/systems administration, and the final release schedule: _____________

Customer expectations and the schedule: _________________________

The Release Milestone

Figure 5-6 shows how far the team has gotten in the process: we’re almost there! The last phase, deploying, leads to the release milestone. Microsoft defines the point of release as when management of the system shift from the product team to the normal operations and support mechanisms. At this milestone the solution has been deployed and is considered stable. The customer has accepted the product and signs off in some way. Your team then moves on to the next project.

Figure 6: The last milestone: Release!

Defining the Release Milestone

Four milestones occur during the deploying phase: rollout begins, training complete, rollout complete, and stabilization complete. Rollout begins is pretty easy! Your team should pretty much be there having finished the pilot of the previous phase. Training has been ongoing for some time now, but as rollout continues training concludes as users jump on the system and take off. As your team reaches rollout complete, there may be some significant problems remaining that prevent you from handing over support to the operational staff. Your team must complete stabilization before your role can end.

Tasks That Occur During the Release Milestone

Table 5-8 describes each of the interim milestones in more detail. As your team reaches these milestones, a number of tasks are underway. Logistics management comes to the fore in this phase as they handle site preparation and rollout itself. In preparing the site, the team checks the site against operations requirements and sets up user administration.

Interim Milestone

Description

Effect

Rollout Begins

Deployment of the new technology solution is extended beyond the safety net of the pilot group.

Allows business to begin to realize incremental benefits from the solution.

Training Complete

Trainers, implementers, administrators, users, and operations personnel have all received the training they need.

Meets explicit training needs of all user segments.

Rollout Complete

Technology solution has been deployed to all of the targeted users.

Conveys the project business benefits to the customer.

Stabilization Complete

Rate of new problem reports has declined steadily and is at or near zero each day.

Facilitates the transfer of support for the new technology to the infrastructure management team.

Table 8: Interim Milestones Leading to Release

During the previous phase, development has adjusted the rollout plan to fit the solution. Now it’s time for logistics to execute the plan, providing the material and doing the legwork for getting the system in place. Logistics also sets up the appropriate help-desk mechanisms for long-term support after your team withdraws.

The testing done up to now has been good and has eliminated a lot of problems, but you know that problems will pop up when the system hits the production environment. Now your labs switch over to solving real-world problems. Testing continues throughout deployment as you work to bring the solution to stabilization and optimize its performance.

Describing the Deliverables for the Release Milestone

The deploying phase has two deliverables: post-rollout baselining of user profiles and usage scenarios, and project review. Do you remember the predictions of how the enterprise environment would change at the conclusion of the project? In the initial phase, your team developed a vision for a new system. In the planning phase your team took that vision and produced a document outlining the new environment. Now is the time to compare these predications to reality. How did your solution match what you envisioned? For the post-rollout baselining of user profiles and usage scenarios, you take the user profiles and usage scenarios of the previous phases and compare them to the result.

The project review examines the course you took in the deploying phase. Your team looks at what went wrong and what went right. The project review documents what you learned from your mistakes. Your team can then use these best practices for future infrastructure projects.

Describing the Focus for Each MSF Team Role at Release

Table 5-9 gives a complete listing of the role of each MSF team during the deploying phase. As your team moves towards the goal, each segment still needs to focus on its role, keeping communication open throughout.

Exam Watch: Remember how each MSF team role relates to each phase of the project.

Team

Role

Product Management

·       Promotion

·       Feedback

·       Assessment

·       Signoff

Program Management

·       Solution/scope comparison

·       Project tracking/coordination

Development

·       Problem resolution

·       Release

User Education

·       Need-specific training

·       Training schedule

Testing

·       Performance metrics

·       Problem resolution

Logistics Management

·       Site prep setup/support

·       Rollout management

·       Change approval

Table 9: Team Roles during the Release Phase

Identifying the Activities Leading to the Release Milestone and Laying the Foundation for Future Projects

Deploying culminates in the release milestone. The solution achieves release when all the users identified in the scope have received the solution, the rate of new problems approaches zero, the solution can be supported by permanent staff, and the customer expresses satisfaction with the performance, quality, and functionality of the solution.

So what do you do after product management obtains customer signoff? You celebrate, of course! If you’ve achieved your vision, your team has indeed done something worth celebrating. During this happy time, you can receive feedback from users, review milestones, and prepare for future technology infrastructure projects.

Exercise 5.4: Stabilizing Phase

Identify the role responsible for each of the following tasks:

Promotion, feedback, assessment, and signoff: _____________________

Solution/scope comparison and project tracking/coordination: _________

Need-specific training and training schedule: _______________________

Problem resolution and release: __________________________________

Site prep setup/support, rollout management, and change approval: _______

Performance metrics and problem resolution: _______________________

Exercise 5.5: Identify the phase for the following interim milestones and deliverables

Interim Milestone

Deliverables

Phase

Conceptual Design Complete

Design Specification Complete

Master Project Plan Complete

Conceptual Design Document

Design Specification

Master Project Plan

_________________

Team Formation Complete

Draft Vision/Scope

Final Vision/Scope

Vision/Scope Document

Risk Management Plan

Project Structure

_____________

Rollout Begins

Training Complete

Rollout Complete

Stabilization Complete

Post-Rollout Baselining of User Profiles and Usage Scenarios

Project Review

______________

Lab Testing

Complete

Proof of Concept Complete

Pilot Complete

Pilot Plan

Training Plan

Capacity Plan

Business Continuation Plan

Rollout Plan

________________

Certification Summary

The enterprise architecture consists of people, process, and technology. The technology infrastructure is an intersection of these three. The MSF process model can guide infrastructure deployment projects. The model consists of four phases: envisioning, planning, developing, and deploying. Each phase concludes with a milestone: vision/scope approved, project plan approved, scope complete/first use, and release. Each phase has interim milestones and deliverables. The MSF team model organizes the deployment team into six roles: product management, program management, development, user education, testing, and logistics management.

Two-Minute Drill

·       The technology infrastructure exists to meet the business needs of the organization.

·       Microsoft’s eight categories of the technology portion of the infrastructure are: data transmission links, local area network architecture, wide area network architecture, protocols and transports, network operating systems, computer hardware, computer software, and domain/site models.

·       The process model is an iterative process that allows for multiphase development projects to assume an organized, continuous, development process.

·       Remember the SMART requirements of a vision/scope document: Specific, Measurable, Achievable, Results-based, and Time-oriented.

·       The process of envisioning brings the team to the vision/scope approved milestone. At this milestone the members of the project team, the customer, and key project stakeholders reach a common agreement on the essential parts of vision and scope.

·       Microsoft suggests some helpful intermediate points to measure progress: team formation complete, draft vision/scope, and final vision/scope.

·       Microsoft identifies six roles for members of a team: product management, program management, development, testing, logistics management, and user education.

·       The vision/scope document, has several necessary characteristics: it provides a clear direction for the team; it sets customer expectations; and it approximates the risk involved in the project.

·       Conceptual design, a non-technical document, describes what the final product includes. This detailed document covers the functionality of the solution, how the product might impact the current infrastructure, and the relationship between user and product

·       Planning test lab setups includes deciding who will be responsible for the labs, what activities will be performed there, how the lab should be configured, and how to establish the guidelines and policies for the lab.

·       Your team will produce five deliverables during the development phase: pilot plan, training plan, capacity plan, business continuation plan, and rollout plan.

·       The rollout plan contains step-by-step procedures for delivering the solution.

·       Four milestones occur during the deploying phase: rollout begins, training complete, rollout complete, and stabilization complete.

·       The deploying phase has two deliverables: post-rollout baselining of user profiles and usage scenarios, and project review.

Answers to Exercise 5-1

Developer Team

User Education Team

Product Team

Program Team

Testing Team

Logistics Team

Answers to Exercise 5-2

Product Team

Program Team

Testing Team

Logistics Team

Developer Team

User Education Team

Answers to Exercise 5-3

Program Team

User Education Team

Testing Team

Developer Team

Logistics Team

Product Team

Answers to Exercise 5-4

Program Team

Product Team

User Education Team

Developer Team

Logistics Team

Testing Team

Answers to Exercise 5-5

The third column should have the following answers:

Planning Phase

Envisioning Phase

Stabilizing Phase

Developing Phase