Module 8: Deployment Complete
Milestone
8
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²6
2EMHFWLYHV
At the end of this module, you will be able to
„
Understand the deployment process
„
Effectively manage change during the
deployment process
„
Complete the transition to a production environment
„
Properly close out a project
At the end of this module, you will understand the infrastructure deployment
process 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.
;²7# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
/HVVRQV
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
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²8
/HVVRQ#4=#3ULQFLSOHV#DQG#&RQFHSWV

Lesson 1:
Principles and Concepts
The principles behind the
deploying phase and how
they enable you to achieve
the deployment complete
milestone
;²9# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
([HFXWLQJ#WKH#3ODQ
„
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 about
archery. In the vision/scope approved milestone module, you learned about the
importance of knowing your target before you shoot. You can think of the
planning phase as being analogous to aiming the arrow, and development as
being 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 would
obviously find it difficult to change the course of the arrow in midflight. It is
therefore important that you aim the arrow appropriately before releasing it.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²:
&RRUGLQDWLQJ#7DVNV
„

Use parallelism to reduce the
time to completion
„
Add resources to the team as
appropriate and feasible
„
Ensure that teams have
direction and purpose
During deployment, teams often use parallelism to save time and drive the
solution to completion faster. Parallelism is when different parts of the solution
are implemented simultaneously. For example, different team members could
work to deploy the solution at different sites in parallel.
The team may find it appropriate at this time to staff the deployment with
additional resources. These individuals will typically be more service-oriented
than the team members filling the architecturally focused roles that designed the
solution. These resources are often less expensive than other members of the
team, as they do not need to have the same level of in-depth experience as the
core team members. Adding new members can enable the team to deploy the
solution 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 and
purpose. Logistics management must ensure that parallel teams coordinate their
efforts and fully incorporate any new team members.
;²;# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
([SHFWLQJ#&KDQJH
„
Change is often external to and
independent of planning a project
„
Deployment may represent the

longest part of the process model
in infrastructure projects
„
Implementing change during
deployment may represent high
risk and cost
Despite the best-laid plans of any team, change is inevitable. Dealing with
change poorly during deployment can turn a minor obstacle into a cataclysmic
event that affects the entire project. In general, the team should manage change
proactively by dealing with it head-on. One way to facilitate this approach is to
maintain the same level of discipline the team used during the previous phases.
This is best accomplished by keeping the change management processes used
during development intact rather than dismantling them during deployment.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²<
6RXUFHV#RI#&KDQJH
Type of Change
Internal
External
Examples
Scope creep
Design flaws
Changing business
requirements
New product
releases
Service packs
Changing business
climate
Sources
Customer

Team
Users
Vendors
Suppliers
Environment
Change can be categorized as internal and external in relation to the project and
the customer. Furthermore, these types of change introduce different types of
risk, and you should manage them differently.
It is important to recognize that change often originates from external sources
that are beyond the sphere of influence for the team and/or the customer.
;²43# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
6WUDWHJLHV#IRU#0DQDJLQJ#&KDQJH
„
Going back
„
Redirecting it
„
Delaying it
Resources
Features
Schedule
MSF Trade-off Triangle
There are many different ways to accommodate change. Remember that change
is often negotiable. The trade-off triangle is an invaluable tool for
understanding 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 and
present the team’s recommended course of action, and to reach agreement with
the customer on the action to take. In some cases, the product manager may
need to provide context and other information to help the customer understand
the 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 procedure
rather than changing the load set.
„

Delaying it. Implement the change in the next version. This is often an
effective way to synchronize project and product release cycles.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²44
&KDQJH#&RQWURO#'XULQJ#'HSOR\PHQW
„
Freezing the design
„
Versioned releases
„
Risk management
„
Trade-off triangle
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 are
usually very expensive.: Unfreezing the design for any reason requires

stepping 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 as
such.
„

Trade-off triangle. The trade-off triangle is a good tool to use to
communicate the impact of change to the customer. It becomes the
customer’s decision whether to implement the change at the cost of time or
resources, or to defer the change to a later release.
;²45# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
$FWLYLW\=#8QGHUVWDQGLQJ#&KDQJH#&RQWURO
,QGLYLGXDOO\=#
Activit
y
„
Using the Electronics Source Corporation project
scenario as a guide, list some change control
issues the project team might face
„
Present your results to the class
Refer to the lab manual for instructions on completing this activity.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²46
/HVVRQ#5=#'HSOR\LQJ#3KDVH#2XWOLQH

Lesson 2:
Deploying Phase Outline
The organization of the
deploying phase and the
milestones and deliverables
that must be achieved
;²47# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
7KH#&XOPLQDWLRQ#RI#'HSOR\LQJ
„
A stable solution
that addresses
all major
issues
„
Transition
of operations
and support to
the customer
„
Achievement of the
success criteria
„
Project closure
Deployment Complete
Milestone
Agreement on
Release
Vision/Scope
Approved
Project Plan

Approved
Deployment
Complete
The final milestone marks a significant point in the project. By this point, the
deployed solution should be providing the expected business value to the
customer, and the team should have effectively shut down the processes and
activities it employed to reach this goal.
The customer must agree that the team has met its objectives before it can
declare 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 the
solution to be considered stable, appropriate operations and support systems
must be in place.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²48
,QWHULP#0LOHVWRQHV
6WDELOL]DWLRQ#&RPSOHWH
6LWH#'HSOR\PHQWV
&RPSOHWH
&RUH#7HFKQRORJ\
'HSOR\HG
Deployment
Complete
The deployment process consists of three major activities with associated
interim milestones: deployment of the core technology, deployment of the
site(s), and stabilization of the solution. The deployment complete milestone
signifies that the deployment plan has been fulfilled, the solution is stable, the
customer accepts that the team has met its objectives and the team has closed
out the project.
;²49# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
'HOLYHUDEOHV
„

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 not
culminate 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 operations
and support plan. These will typically include a support Knowledge Base for
resolved and unresolved issues, operations logbooks, and utilization reports.
The audience for these may vary. For instance, in some cases Knowledge Base
will be accessible to end users. In other situations, help desk will be the only
group to use it.
You will also need to hand access to the project’s document repository over to a
customer representative. Too often, the project team moves on to other
activities and the project documents are lost in the shuffle. The repository
should include an appropriate archive for recovery purposes.

Finally, the team should prepare and deliver a project close-out report for the
project. This will typically include final versions of the major deliverable
documents (vision statement, functional specification, and master project plan),
customer/user satisfaction data collected during deployment, and a summary of
possible directions for the next version of the solution.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²4:
7HDP#)RFXV#'XULQJ#'HSOR\LQJ
Product management
Program management
Development
User education
Testing
Logistics management
Role Focus
Promotion; feedback; assessment; sign-off
Solution/scope comparison; stabilization
management
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 to
deployment. Other methodologies often treat deployment as a separate process
from the development of the solution, and one that involves different people. In
the MSF model, the project team is involved from start to finish, although the
members 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 from
product manager (vision/scope approved milestone) to program manager
(project plan approved and release milestones). Here, the logistics manager will

step to center stage as the role that the majority of activity centers around. The
logistics manager will often share focus with user education as the systems are
actively deployed, users receive the appropriate training, and the operations and
support systems are activated.
;²4;# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²4<
/HVVRQ#6=#'HSOR\LQJ#WKH#&RUH#,QIUDVWUXFWXUH
Lesson 3:
Deploying the Core
Infrastructure
Installing the foundation for
the deployment
;²53# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
&RUH#YV1#6LWH#7HFKQRORJ\#&RPSRQHQWV
Most enterprise solutions consist of two distinct
classes of components
„
Core
. Components located at a central or core
location that enable interoperability of the overall
solution concept
„
Site-specific
. Components located at individual
sites that enable users to access and use the
solution
Most infrastructure deployment solutions today consist of two-tier or even n-
tier architectures. Yet, when looking at the location of the actual technology
components (that is, servers, routers, etc.) they often are still organized into

hub-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.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²54
6WUDWHJLHV#IRU#'HSOR\LQJ#WKH#&RUH#7HFKQRORJ\
„
Serial. Deploys core components before site
components
„
Less risk
„
Rapid or small deployments
„
Parallel. Deploys core and site components in
parallel
„

Large environments
„
Longer deployments
When considering how to deploy a solution, it is necessary to identify those
components that are not functionally vital to the overall solution and to decide
upon an effective strategy for deploying them. It is important to realize that the
strategy chosen is dependent on the specific solution and customer
requirements.
For virtually any solution, you must deploy some components before users can
utilize the solution. For many projects, however, the cost to deploy all core
components first is excessive and unnecessary. Devices that are functionally
redundant and only exist to provide capacity usually do not need to be installed
before 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 smaller
environments.
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.
;²55# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
&RUH#7HFKQRORJ\#'HSOR\HG#,QWHULP#0LOHVWRQH
„
Components are the enabling technology of the
enterprise solution
„
Examples: domain controllers, mail routers, remote
access servers, database servers
„
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 the
framework or backbone for the entire solution. These components do not
represent the solution from the perspective of a specific set of users or site. But
the deployment of sites or users generally depends on this framework.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²56
/HVVRQ#7=#'HSOR\LQJ#WKH#6LWHV
Lesson 4:
Deploying the Sites
Rolling out the solution
;²57# # 0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH
3HUIRUPLQJ#WKH#6LWH#'HSOR\PHQW
„
Transfers the solution to the end users and into
production
„
Can treat each deployment like a separate project
that “rolls up” into the overall deployment plan
„
Generally requires many ramping-up activities to
begin deploying sites
„
May require additional resources
„
Often includes acquisition of products and materials
Ramping up for a site deployment often involves bringing in new people to
assist with hardware staging, training users, and establishing a help desk
system. Ramping up often requires that the project team install new hardware

and software in advance of deploying the solution. As it typically doesn’t make
much sense to acquire these components several months in advance and store
them, they will likely need to be purchased at this time.
At this stage, the focus of the project typically transitions to the logistics role.
0RGXOH#;=#'HSOR\PHQW#&RPSOHWH#0LOHVWRQH##;²58
6LWH#'HSOR\PHQW#7UDGH0RIIV#DQG#5LVNV
Resources
Features
Schedule
MSF Trade-off Triangle
„
Serial versus parallel
„
Preplanned versus
just-in-time
„
Push versus pull
Site deployments necessarily involve trade-offs, which carry certain risks. One
trade-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-time
planning.
„


Preplanned deployments, in which the team conducts site surveys to plan
the deployments in advance, are preferable to just-in-time deployments, but
aren’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 are
necessary 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/or
divisions.
„

Pull deployments are deployments in which the team develops the solution
but doesn’t deploy it to individual sites until they request it. The pull
strategy is generally not as effective because it does not allow the team to
gather information about the number of sites or users that the solution needs
to serve. However, this is primarily a political decision; the customer may
require a pull strategy to avoid pushback from sites and users.