Tài liệu Module 8: Deployment Complete Milestone doc

At the end of this module, you will be able to „ Understand the deployment process „ Effectively manage change during thedeployment process „ Complete the transition to a production envi

8

At the end of this module, you will be able to

„ Understand the deployment process

„ Effectively manage change during thedeployment process

„ Complete the transition to a production environment

„ Properly close out a project

At the end of this module, you will understand the infrastructure deploymentprocess and how to deploy selected technologies in an enterprise environment.You will learn how to manage change during the deployment process, and how

to transition to a production environment and close out the project

Lessons

1 Principles and Concepts

2 Deploying Phase Outline

3 Deploying the Core Infrastructure

4 Deploying the Sites

5 Stabilizing the Deployed Solution

6 Completing the Project

Lesson 1:

Principles and Concepts

The principles behind the deploying phase and how they enable you to achieve the deployment complete milestone

„Treat deployment as an active phase rather than an

analytical one

„Act as a unified team

„Manage change effectively throughout the deployment process

The team must be focused during deployment To use an analogy, think aboutarchery In the vision/scope approved milestone module, you learned about theimportance of knowing your target before you shoot You can think of theplanning phase as being analogous to aiming the arrow, and development asbeing like pulling the arrow back and releasing it Deployment, then, is the path

of the arrow in flight toward the target Looking at it this way, you wouldobviously find it difficult to change the course of the arrow in midflight It istherefore important that you aim the arrow appropriately before releasing it

The team may find it appropriate at this time to staff the deployment withadditional resources These individuals will typically be more service-orientedthan the team members filling the architecturally focused roles that designed thesolution These resources are often less expensive than other members of theteam, as they do not need to have the same level of in-depth experience as thecore team members Adding new members can enable the team to deploy thesolution faster than they otherwise could by allowing the core members to focus

on stabilizing the solution and closing out the project

As always, team members must work toward their goals with direction andpurpose Logistics management must ensure that parallel teams coordinate theirefforts and fully incorporate any new team members

Despite the best-laid plans of any team, change is inevitable Dealing withchange poorly during deployment can turn a minor obstacle into a cataclysmicevent that affects the entire project In general, the team should manage changeproactively by dealing with it head-on One way to facilitate this approach is tomaintain the same level of discipline the team used during the previous phases.This is best accomplished by keeping the change management processes usedduring development intact rather than dismantling them during deployment.

Type of Change Internal

External

Examples

Scope creepDesign flawsChanging businessrequirementsNew productreleasesService packsChanging businessclimate

Sources

CustomerTeamUsersVendorsSuppliersEnvironment

Change can be categorized as internal and external in relation to the project andthe customer Furthermore, these types of change introduce different types ofrisk, and you should manage them differently

It is important to recognize that change often originates from external sourcesthat are beyond the sphere of influence for the team and/or the customer

There are many different ways to accommodate change Remember that change

is often negotiable The trade-off triangle is an invaluable tool forunderstanding both the impact and options in relation to change management

It is the job of the product manager to communicate the risk to the customer andpresent the team’s recommended course of action, and to reach agreement withthe customer on the action to take In some cases, the product manager mayneed to provide context and other information to help the customer understandthe value and the implications (that is, risk) of making the change

Strategies for managing change include:

„ Going back Stop and go back to planning or developing activities This is

often necessary for design change requests or design errors

„ Redirecting it Use a different vehicle to implement the change For

example, plan to deliver a service pack to desktops as a support procedurerather than changing the load set

„ Delaying it Implement the change in the next version This is often aneffective way to synchronize project and product release cycles

MSF principles relevant to change management during deployment include:

„ Freezing the design The design should be frozen by the time the team

begins deploying the solution Late changes in design or implementation areusually very expensive.: Unfreezing the design for any reason requiresstepping backward and effectively “throwing away” some amount of effort,which represents an unbudgeted expenditure

„ Versioned releases Versioning generally provides the best method for

managing change during deployment

„ Risk management Change requests represent risk and should be treated assuch

„ Trade-off triangle The trade-off triangle is a good tool to use to

communicate the impact of change to the customer It becomes thecustomer’s decision whether to implement the change at the cost of time orresources, or to defer the change to a later release

„Present your results to the class

Refer to the lab manual for instructions on completing this activity

Lesson 2:

Deploying Phase Outline

The organization of the deploying phase and the milestones and deliverables that must be achieved

„ A stable solutionthat addressesall majorissues

„ Transition

of operationsand support tothe customer

„ Achievement of thesuccess criteria

„ Project closure

Deployment Complete Milestone

Agreement on

Approved

Project Plan Approved

Deployment Complete

The final milestone marks a significant point in the project By this point, thedeployed solution should be providing the expected business value to thecustomer, and the team should have effectively shut down the processes andactivities it employed to reach this goal

The customer must agree that the team has met its objectives before it candeclare the solution to be in production and close out the project This requires

a stable solution as well as clearly stated success criteria In order for thesolution to be considered stable, appropriate operations and support systemsmust be in place

The deployment process consists of three major activities with associatedinterim milestones: deployment of the core technology, deployment of thesite(s), and stabilization of the solution The deployment complete milestonesignifies that the deployment plan has been fulfilled, the solution is stable, thecustomer accepts that the team has met its objectives and the team has closedout the project.

„Operations and support information systems

„Procedures and processes

„Knowledge Base, reports, logbooks

„Documentation repository for all versions of documents, load sets, and scripts and procedures developed during the project

„Project close-out report

„Final versions of all project documents

„Customer/user satisfaction data

„Definition of next steps

Unlike the previous milestones, the deployment complete milestone does notculminate with a major deliverable other than the deployed solution

Nonetheless, this milestone requires a number of key deliverables

You will need to create a number of deliverables to implement the operationsand support plan These will typically include a support Knowledge Base forresolved and unresolved issues, operations logbooks, and utilization reports.The audience for these may vary For instance, in some cases Knowledge Basewill be accessible to end users In other situations, help desk will be the onlygroup to use it

You will also need to hand access to the project’s document repository over to acustomer representative Too often, the project team moves on to other

activities and the project documents are lost in the shuffle The repositoryshould include an appropriate archive for recovery purposes

Finally, the team should prepare and deliver a project close-out report for theproject This will typically include final versions of the major deliverabledocuments (vision statement, functional specification, and master project plan),customer/user satisfaction data collected during deployment, and a summary ofpossible directions for the next version of the solution

Problem resolution; escalation support

Performance testing; problem identification Site deployment management; change approval Training; training schedule management

The MSF team model differs from some more traditional approaches todeployment Other methodologies often treat deployment as a separate processfrom the development of the solution, and one that involves different people Inthe MSF model, the project team is involved from start to finish, although themembers may bring in additional resources to perform the actual deployment

During this phase, a subtle shift occurs in the dynamics of the project team.Throughout the prior phases of the process model, the focus has shifted fromproduct manager (vision/scope approved milestone) to program manager(project plan approved and release milestones) Here, the logistics manager willstep to center stage as the role that the majority of activity centers around Thelogistics manager will often share focus with user education as the systems areactively deployed, users receive the appropriate training, and the operations andsupport systems are activated

THIS PAGE LEFT INTENTIONALLY BLANK

Most enterprise solutions consist of two distinct classes of components

„ Core Components located at a central or core

location that enable interoperability of the overallsolution concept

„ Site-specific Components located at individual

sites that enable users to access and use thesolution

Most infrastructure deployment solutions today consist of two-tier or even

n-tier architectures Yet, when looking at the location of the actual technologycomponents (that is, servers, routers, etc.) they often are still organized intohub-and-spoke models When this is the case, those components positioned at

the hub locations are called core components.

A core component is often shared by multiple locations; more importantly,though, it is usually a critical or enabling part of the overall solution Examples

of core components for various BackOffice® solutions may include:

„ Windows NT® server-based solution Domain controllers, routers, remote

access servers, enterprise file shares, intranet servers, Internet proxy servers

„ Microsoft Exchange server-based solution Message servers, public folder

servers, Internet mail servers, X.509 Public Key Servers

„ Systems management server-based solution Central site server, primary site

servers, SQL servers for central and primary sites

„Serial Deploys core components before site

components

„ Less risk

„ Rapid or small deployments

„Parallel Deploys core and site components in

requirements

For virtually any solution, you must deploy some components before users canutilize the solution For many projects, however, the cost to deploy all corecomponents first is excessive and unnecessary Devices that are functionallyredundant and only exist to provide capacity usually do not need to be installedbefore deploying to the sites

Serial—All core components are deployed prior to any site deployments This

approach has less risk and is adequate for more rapid deployments and smallerenvironments

Parallel—Core components are deployed as needed in parallel to support each

site deployment This is a more cost-effective approach for larger environments

or where the deployment will extend over a longer period

„Site deployments depend on this technology

„Depending on the solution, the core technology may need to be deployed before or in parallel with site deployments

Most infrastructure solutions include a number of components that provide theframework or backbone for the entire solution These components do notrepresent the solution from the perspective of a specific set of users or site Butthe deployment of sites or users generally depends on this framework

Lesson 4:

Deploying the Sites

Rolling out the solution

„ May require additional resources

„ Often includes acquisition of products and materials

Ramping up for a site deployment often involves bringing in new people toassist with hardware staging, training users, and establishing a help desksystem Ramping up often requires that the project team install new hardwareand software in advance of deploying the solution As it typically doesn’t makemuch sense to acquire these components several months in advance and storethem, they will likely need to be purchased at this time

At this stage, the focus of the project typically transitions to the logistics role

„Push versus pull

Site deployments necessarily involve trade-offs, which carry certain risks Onetrade-off involves deploying the solution to sites serially or in parallel

„ Serial deployments generally require fewer resources and cost less, but

generally take longer than a comparable parallel deployment

„ Parallel deployments cost more due to the additional resources they need,

but they can be completed more quickly

Another trade-off involves preplanning a deployment versus using just-in-timeplanning

„ Preplanned deployments, in which the team conducts site surveys to plan

the deployments in advance, are preferable to just-in-time deployments, butaren’t always feasible

„ Just-in-time deployments, in which the team plans each deployment as it

arrives at the site, are not as desirable as preplanned deployments, but arenecessary in situations where the site is not easily accessible ahead of time

A third trade-off involves deciding between push and pull deployments

„ Push deployments are deployments in which a central unit within the

enterprise makes the decision to roll out the solution to various sites and/ordivisions

„ Pull deployments are deployments in which the team develops the solution

but doesn’t deploy it to individual sites until they request it The pullstrategy is generally not as effective because it does not allow the team togather information about the number of sites or users that the solution needs

to serve However, this is primarily a political decision; the customer mayrequire a pull strategy to avoid pushback from sites and users

Vision/Scope Approved Release

Deployment Complete

Project Plan Approved

Site Training Complete

S ta bil iz ing

Pr ep ar

in g

In

al lin g

Tr aini ng

Site Preparation Complete

Site Deployment Complete

Site Installation Complete

Start

Site deployment represents a process within a process It involves the execution

of a well-thought-out-plan for installing the solution

Sites may be deployed serially by fewer teams or in parallel by more teams.Parallel site deployment requires more coordination and provides lessopportunity to deal with the ramp-up of usage However, a more serializeddeployment may introduce more confusion to the users, especially when thenew solution must coexist with a legacy system

Site deployment also marks the use of the system by users in a productionenvironment The team must take steps to ensure that the necessary operationsand support infrastructure exist for these users as they gain access to the system