Module 7: Release Milestone
7
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²6
2EMHFWLYHV
At the end of this module, you will be able to
„
Understand the infrastructure
development process
„
Prepare for deployment
„
Perform effective solution testing
„
Use change control processes
„
Perform a pilot
At the end of this module, you will be able to define and understand the
infrastructure development process and what it takes to prepare for deployment
of a wide variety of technologies. Specifically, this module presents concepts
and processes necessary to take the vision, functional specification, and plans
from previous milestones and develop what is necessary for the deploying
phase ahead.
:²7# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
/HVVRQV
Lessons
1. Principles and Concepts
2. Developing Phase Outline
3. Validating the Technology
4. Developing the Proof of Concept
5. Performing Preproduction Testing

6. Performing Pilot Testing
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²8
/HVVRQ#4=#3ULQFLSOHV#DQG#&RQFHSWV
Lesson 1:
Principles and Concepts
The principles behind the
developing phase and how
they enable you to achieve
the release milestone
:²9# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
5LVN#$VVHVVPHQW
„
Perform as an ongoing activity
„
Develop contingency plans based on known
risks and their level of impact
„
Escalate high-impact risks to the external
audience
Risk assessment is an important ongoing activity. It is not an event. Risks affect
everything from planning, schedules, and communications, to development
activity itself. Identify and communicate risks to the team periodically.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²:
&KDQJH#&RQWURO
Change control allows
you to track, capture, and
document changes to the
solution as development
progresses
„

Provides central access for all
project-related material
„
Ensures that development and
testing efforts are not lost
„
Allows for rollback if
errors are made in
subsequent versions
„
Divides the development
process into manageable
parts
Change control enables the team to break the development process into
manageable parts, mitigate problems, and fall back to the last known good
configuration if the mitigation fails.
The project team must be able to determine the who, what, why, where, when,
and how of proposed changes. The team must be able to assess the risk and
impact of the change and have a mechanism for tracking the changes that have
been implemented.
By using change control, the test team knows that the components of the build
won’t change during the testing process. In other words, for any given build, the
environment is contained (unchanged) versus dynamic (changing constantly).
:²;# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
7HVWLQJ
„
Makes known all issues that
team must resolve
„
Validates against the functional specification

„
Performs regression testing (whether the solution
breaks anything in the existing environment)
„
Determines whether the solution requires
supplemental components (updated drivers,
dynamic-link libraries, or service packs)
„
Captures user behavior to test against unstated
expectations
The testing team is responsible for making all issues known. It is then up to the
team to resolve those issues and communicate the resolution back to testing.
This is done so that the issue-tracking system that testing maintains can be
updated to reflect the current state of the build.
Is this solution built according to the functional specification? That is the
question that the test team is trying to answer when it validates the solution
against the functional specification.
Regression testing is used to make sure that the current build of the solution
does not break what is already there.
Testing is vital to the success of the project. If the team is to deploy the element
to 40,000 workstations, for example, one issue resolved in the lab saves 40,000
problems after deployment.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²<
,VVXH07UDFNLQJ#3URFHVV
Identify Issues and
Record Them
Review
Issues Each Day
Resolve Issues
Move

Forward
Testing documents the issues as it finds them. The testing team member should
add an issue to the issue-tracking mechanism with an estimation of the severity
of that issue and a description of the steps that it takes to reproduce it.
The development lead prioritizes the issue using a scale of 1 to 4, with 1 being
the worst and 4 being a trivial issue. Then the lead assigns it to the developer
responsible for that feature for resolution. The worst possible issue is one with a
severity of 1 and a priority of 1. This is an issue that crashes the solution and
must be tracked down and resolved.
The information the tester documents during the issue-tracking process is
invaluable to the training and support staff. It shows them the history of the
solution, the problems encountered during development, and the resolutions.
:²43# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
3URMHFW#&RPPXQLFDWLRQV
Identify key audiences
and messages
Prepare users,
management, support, and
administrators for what will
come, when, and why
Set expectations by
discussing the good and
bad elements
Improve
chance of
success by
increasing
project support
Communications during the development phase is more nebulous than in other
phases because so much depends on the complexity of the project, organization

dynamics, and so on. A review of best practices found the following:
„

The communications plan must remain flexible. It will almost always
change because of various circumstances surrounding the project.
„

The project team should continually review the plan and raise issues to key
stakeholders, who will have the most input into changes in the plan.
„

If the communications plan has been fully developed, project
communications is a simple matter of telling targeted groups what they need
to hear, when they need to hear it. For example, during piloting you will
deal only with pilot issues and only communicate them to people affected
by the pilot, rather than to the entire enterprise.
„

The team should continually track the effectiveness of the communications,
which amounts to a scaled-down project review after each major
communication.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²44
%HJLQQLQJ#WKH#'HYHORSPHQW#3URFHVV
Gain Commitment
to a Clear Purpose
Review and
Validate Plans
and Strategies
Define and Agree
upon Success

Criteria
Begin
Development
Processes
Clear objectives, mutual
accountability, and
responsibility are key
Before delving into the development process, everyone must be on the same
page. Members of the extended team must all buy in to the goals and objectives
of the project and understand not only what they must accomplish, but also the
importance of their contribution and how it affects the entire effort.
Documentation is crucial for future communications, training, implementation,
and support. Without an understanding of the overall process, those responsible
for development may see this as a distraction from other work.
Plans may require “no user interaction” during implementation because of the
end users’ lack of technical knowledge. If the development team doesn’t fully
understand that requirement, users may receive a prompt or be required to
modify the configuration in some way before they can use the new technology.
:²45# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²46
/HVVRQ#5=#'HYHORSLQJ#3KDVH#2XWOLQH
Lesson 2:
Developing Phase Outline
The organization of the
process model developing
phase and the milestones
and deliverables that must be
achieved
:²47# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH

7KH#&XOPLQDWLRQ#RI#'HYHORSLQJ
Release Milestone
Deployment Complete
Vision/Scope
Approved
I
E
N
V
S
O
G
I
N
N
I
P
L
A
N
I
G
N
N
D
E
P
L
O
I

G
Y
N
Release
D
E
V
L
O
P
I
G
E
N
Project Plan
Approved
Agreement on
„
Technology
„
Training,
documentation,
communications
„
The solution
„
Selected
technology
frozen
At the release milestone, the team will have tested and piloted the solution and

will be prepared to perform a deployment. The team also develops training
material and documentation, and prepares installation scripts and processes in
advance of the deployment.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²48
,QWHULP#0LOHVWRQHV
Technology
Validation Complete
Proof of Concept
Complete
Pilot Complete
Preproduction
Test Complete
Release
Each of these phases, and the tasks associated with them, is described later in
this module.
„

Technology validation complete. To achieve this interim milestone, the
team evaluates the technology against the functional specification in an
isolated, clean environment.
„

Proof of concept complete. Here, the technology is integrated into an
isolated lab environment that closely simulates the production environment.
„

Preproduction test complete. To achieve this interim milestone, the team
tests all the elements created during development as a whole and validates
them against the functional specification. Think of this as a rehearsal of the
solution.

„

Pilot complete. This interim milestone can be thought of as an “opening
night,” where the team introduces the solution to the production
environment for the first time and installers, systems support staff, and end
users get an opportunity to work with it.
:²49# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
'HOLYHUDEOHV
„
Training material
„
Communications
„
Deployment processes
„
Installation procedures and
scripts
„
Checklists and templates
„
Operational procedures
„
Documentation
„
Deployment processes
„
Support/troubleshooting
„
Updated master project plan and schedule
Release milestone

Deliverables, in this case, are the documents that will be passed along to the
team for use during the deploying phase.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²4:
7HDP#)RFXV#'XULQJ#'HYHORSLQJ
Product management
Program management
Development
User education
Testing
Logistics management
Role Focus
Customer expectations
Functional specification management;
project tracking; updated plans
Solution and documentation
Solution test; issues identification;
documentation test; updated testing plan
Rollout checklists; updated rollout and pilot plans;
site preparation checklists
Training; updated training plan; user communications
The members of the MSF team have the following responsibilities during this
phase:
„

Product management. Primarily responsible for developing and delivering
communications to the user community outside the project team.
„

Program management. Responsible for managing the functional
specification and ensuring that the solution developed during this phase

meets those specifications. When the original expectations are larger than
the team can meet, program management must work with the other
members of the team to modify the functional specification to meet the
business goals as well as the constraints of the project.
„

Development. Responsible for the actual development work of all technical
aspects of the solution. This role is generally composed of several
individuals with skill sets appropriate for the different tasks that must be
performed during this phase.
„

User education. Responsible for documenting the solution, developing,
purchasing, or modifying training material, maintaining the training plan,
and communicating and advocating for the users and their requirements.
„

Testing. Responsible for testing each aspect of the solution, making issues
known to the appropriate member or members of the team, testing
documentation, and managing the testing plan.
„

Logistics management. Responsible for developing the rollout and site
preparation checklists, and updating the deployment and pilot plans.
:²4;# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²4<
/HVVRQ#6=#9DOLGDWLQJ#WKH#7HFKQRORJ\
Lesson 3:
Validating the Technology

How to determine if the
technology can work
:²53# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
7HFKQRORJ\#9DOLGDWLRQ#&RPSOHWH#,QWHULP#0LOHVWRQH
„
Look at the technology
„
Manually install or configure technology (in ideal
conditions for the technology, rather than matching
production environment)
„
Document what must be done to make the
technology work
„
Begin to identify and document issues and
technical risks
„
Update the master project schedule based on
better understanding of risks and issues
„
Begin solution development process
The technology validation complete interim milestone ensures that the new
technology meets the criteria outlined in the functional specification.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²54
8SGDWLQJ#3ODQQLQJ#'HOLYHUDEOHV
„
Determine if the deployment package will
allow for meeting previous schedule and plan
„
Update the project schedule based on risks,

developed processes, and schedule
variances
„
Use the update to reflect any risks identified
during technology validation
As the team delves deeper into technology validation, many of the earlier
identified risks may prove incorrect and many new risks may become evident.
As these new risks are identified and communicated to the rest of the team, the
program manager must update the master project plan and schedule to reflect
the new perspectives.
:²55# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
$FWLYLW\=#3UHSDULQJ#IRU#7HFKQRORJ\#9DOLGDWLRQ
,QGLYLGXDOO\=#
Activit
y
„
Using the Electronics Source Corporation project
scenario as a guide, identify some types of
technology that the project team will have to
validate
„
Present your results to the class
Refer to the lab manual for instructions on completing this activity.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²56
/HVVRQ#7=#'HYHORSLQJ#WKH#3URRI#RI#&RQFHSW
Lesson 4:
Developing the Proof
of Concept
Determining if the
technology meets the

business or user
requirements
:²57# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH
3URRI#RI#&RQFHSW#&RPSOHWH#,QWHULP#0LOHVWRQH
„
Test the solution on a nonproduction simulation of
existing environment
„
Walk users through the solution to validate their
requirements
„
Develop implementation procedures
„
Automate deployment and installation processes
„
Test the solution and processes
„
Develop deployment checklists
„
Develop operations and management procedures
The proof of concept complete interim milestone is not complete until the team
has ensured that the solution will coexist in a simulation of the product
environment.
0RGXOH#:=#5HOHDVH#0LOHVWRQH##:²58
3URRI#RI#&RQFHSW=#8VHU#5HTXLUHPHQWV#:DON0WKURXJK
Freeze dates
Walk-through
External
Freeze
Date

Internal
Freeze
Date
Development Process
The external freeze date is the last opportunity for stakeholders outside the MSF
team to modify the solution. Any changes at this point must have minimal
impact, however. This is also an opportunity to aid the communications process
and gain buy-in from users before the development effort proceeds. The internal
freeze date is the last opportunity for members of the team to modify the
solution. The user requirements walk-through may fall on or just before the
external freeze date.
The project team should not view this as an opportunity to introduce new
requirements, but rather as an opportunity to identify critical elements to the
success of the project that may not be known. Avoid the temptation to engage
in “scope creep.”