<PROJECT NAME>

RELEASE STRATEGY
Version <1.0>
Date <mm/dd/yyyy>

[Insert appropriate Disclaimer(s)]

 <Project Name>

VERSION HISTORY
[Provide information on how the development and distribution of the Release Strategy
up to the final point of approval was controlled and tracked. Use the table below to
provide the version number, the author implementing the version, the date of the
version, the name of the person approving the version, the date that particular version
was approved, and a brief description of the reason for creating the revised version.]
Version Implemented Revision Approved Approval Reason
# By Date By Date

1.0 <Author name> <mm/dd/ <name> <mm/dd/yyyy> <reason>

yyyy>

Release Strategy Template (v1.0) Page 2 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

Note to the Author

[This document is a template of a Release Strategy document for a project. The template includes
instructions to the author, boilerplate text, and fields that should be replaced with the values
specific to the project.

Blue italicized text enclosed in square brackets ([text]) provides instructions to the document
author, or describes the intent, assumptions and context for content included in this document.

Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with
information specific to a particular project.

Text and tables in black are provided as boilerplate examples of wording and formats that may be
used or modified as appropriate to a specific project. These are offered only as suggestions to
assist in developing project documents; they are not mandatory formats.

When using this template for your project document, it is recommended that you follow these steps:
Replace all text enclosed in angle brackets (i.e., <Project Name>) with the correct field values.
These angle brackets appear in both the body of the document and in headers and footers. To
customize fields in Microsoft Word (which display a gray background when selected):
a. Select File>Properties>Summary and fill in the Title field with the Document Name and
the Subject field with the Project Name.
b. Select File>Properties>Custom and fill in the Last Modified, Status, and Version fields
with the appropriate information for this document.
c. After you click OK to close the dialog box, update the fields throughout the document with
these values by selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update
an individual field by clicking on it and pressing F9. This must be done separately for
Headers and Footers.
2. Modify boilerplate text as appropriate to the specific project.
3. To add any new sections to the document, ensure that the appropriate header and body text
styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and
Heading 3. Style used for boilerplate text is Body Text.
4. To update the Table of Contents, right-click and select “Update field” and choose the option-
“Update entire table”
5. Before submission of the first draft of this document, delete this “Notes to the Author” page and all
instructions to the author, which appear throughout the document as blue italicized text enclosed
in square brackets.]

Release Strategy Template (v1.0) Page 3 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

TABLE OF CONTENTS
1 INTRODUCTION......................................................................................................................5
1.1 Purpose of Release Strategy.................................................................................5
1.2 Overview...................................................................................................................5
1.3 Assumptions.............................................................................................................5
1.4 Constraints................................................................................................................5
1.5 Risks..........................................................................................................................5
2 RELEASE APPROACH..........................................................................................................6
2.1 Rationale...................................................................................................................6
2.2 Release Strategy.....................................................................................................6
2.3 Release Content......................................................................................................6
2.4 Release Schedule...................................................................................................6
2.5 Release Impacts......................................................................................................6
2.6 Release Notification................................................................................................6
2.7 Release Management.............................................................................................7
2.8 Release Numbering................................................................................................7
APPENDIX A: RELEASE STRATEGY APPROVAL............................................................8
APPENDIX B: REFERENCES...................................................................................................9
APPENDIX C: KEY TERMS......................................................................................................10

Release Strategy Template (v1.0) Page 4 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

1 INTRODUCTION
1.1 PURPOSE OF RELEASE STRATEGY
[Describe the purpose of the Release Strategy.]
The intended audience of the <Project Name> Release Strategy is the Business
Sponsor and the Integrated Project Team.
1.2 OVERVIEW
[Briefly describe the purpose and context for the system or situation, and
summarize the history of its development. Include the high-level context
diagram(s) for the system and subsystems previously provided in the Design
Document, Requirements Document, and/or System Design Document (SDD),
updated as necessary to reflect any changes that have been made based on more
current information or understanding. If the high-level context diagram has been
updated, identify the changes that were made and why.]
1.3 ASSUMPTIONS
This section identifies the statements believed to be true for the release of the
product or IT system.
[Describe any assumptions about the current capabilities and use of the system
when it is released in accordance with this plan. Include any information regarding
external circumstances or commitments that may impact the release of the
system.

Describe any dependencies that can affect the deployment of the system. Be sure
to identify any other systems or subsystems that are impacted directly as a result
of this Release Strategy. Describe any dependencies including staffing,
divisional/group participation, external system dependencies or dependencies due
to specific business cycles that can impact this Release Strategy.]
1.4 CONSTRAINTS
This section identifies any limitation that must be taken into consideration prior to
the release of the product or IT system.
[Describe factors that limit the ability to deploy the system or have some impact to
the release of the system in accordance with this plan (e.g., budget and schedule
constraints). Be sure to include constraints due to group/divisional involvement or
any other external system or infrastructure constraints that impact the
environment.]
1.5 RISKS
[Describe any risks associated with release of the system in accordance with this
Release Strategy. Identify any adverse impacts to stakeholders (e.g., end users)
during the release cycle. Be sure to include any factors that may adversely impact
a successful deployment. Also provide a mitigation strategy for each identified risk
that describes specifically the fallback position if a risk is realized. This information
should also be documented in the project’s Risk List and managed in accordance
with the Project Management Plan (Risk Management Plan).]

Release Strategy Template (v1.0) Page 5 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

2 RELEASE APPROACH
[Describe the strategy and activities that will be addressed in the planning for the
release. ]

The <Project Name> Release Strategy provides an outline of activities necessary

to ensure that the project’s product is available for use by its end-users as
originally planned.
2.1 RATIONALE
[Describe the rationale for establishing this release approach. Reference any
information or other deliverables (e.g. Requirements Document, Design
Document, Project Management Plan (Communication Management Plan,
Acquisition Management Plan, Risk Management Plan), and Project Process
Agreement (PPA)) that may have influenced the development of the release
approach. Include key considerations such as how the assumptions, constraints,
and risks from the previous section impact the release strategy. Also consider
lessons learned from other deployments.]
2.2 RELEASE STRATEGY
[Describe at a high level the overall strategy for segmenting the delivery of the
Business Product/Code into specific releases. Identify if the release strategy is for
a phased function rollout/deployment or for a phased user base
rollout/deployment.]
2.3 RELEASE CONTENT
[Identify each specific release, including a description of the functionality to be
delivered in each release. Explain what the proposed system will do (and not do, if
necessary). Map individual requirements from the Requirements Document to the
specific release(s) that will provide that functionality, as appropriate. Provide any
additional rationale for dividing the content into the specific releases.]
2.4 RELEASE SCHEDULE
[Provide a high-level schedule for planned delivery of the releases and the
significant milestones associated with transitioning each release through the life
cycle to production.]
2.5 RELEASE IMPACTS
[Describe any business and/or system impacts associated with each release and
the business processes that will be modified as a result of the deployment
specified in this Release Strategy. Identify any systems and interfaces that are
directly impacted by the release strategy and any impacts to end users during the
release cycle. Describe the relevant benefits, objectives, and goals to be met with
each release.]
2.6 RELEASE NOTIFICATION
[If there is release-specific communication that needs to occur that is not already
described in the Project Management Plan (Communication Management Plan),
Release Strategy Template (v1.0) Page 6 of 10
[Insert appropriate disclaimer(s)]
 <Project Name>

please describe here. Specify the individual stakeholders and/or groups requiring
notification of an impending release. Also describe the method for providing
notification prior to and/or following successful release of the system/application.
Specify the information required by each person or group and the timeframes for
receipt of the information, prior to release. For example, the help desk may
require that a notification be received 10 days prior to release and provide the
release date, a user impact assessment, and a help desk impact assessment.]
2.7 RELEASE MANAGEMENT
[Identify the activities to manage the planning, organization, development, testing,
and implementation of new features and functions, defects, change requests, etc.
into the application being developed. Identify the individuals involved in a typical
release process.
Develop a release checklist that can be used to help the project team identify
when the product is ready for release for use by the client. ]
2.8 RELEASE NUMBERING
[Identify a standard for numbering and naming releases that follows any
established standards if available. Software release numbering may appear trivial
but is critical to the overall success of any effective release strategy.]

Release Strategy Template (v1.0) Page 7 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX A: RELEASE STRATEGY APPROVAL

The undersigned acknowledge they have reviewed the Release Strategy and
authorize and fund the <Project Name> project. The undersigned herby give the
project manager the authority to apply the approved level of organizational
resources to project activities. Changes to this Release Strategy will be
coordinated with and approved by the undersigned or their designated
representatives.
[List the individuals whose signatures are desired. Examples of such individuals
are Business Sponsor and Project Manager. Add additional lines for signature as
necessary. Although signatures are desired, they are not always required to move
forward with the practices outlined within this document.]

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Signature: Date:
Print Name:
Title:
Role:

Release Strategy Template (v1.0) Page 8 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX B: REFERENCES
[Insert the name, version number, description, and physical location of any
documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Description Location
Name and
Version
<Document [Provide description of the <URL or Network path where
Name and document] document is located>
Version
Number>

Release Strategy Template (v1.0) Page 9 of 10

[Insert appropriate disclaimer(s)]
 <Project Name>

APPENDIX C: KEY TERMS

[Insert terms and definitions used in this document. Add rows to the table as
necessary. Follow the link below to for definitions of project management terms
and acronyms used in this and other documents.]

The following table provides definitions for terms relevant to this document.
Term Definition
[Insert Term] [Provide definition of the term used in this document.]

[Insert Term] [Provide definition of the term used in this document.]

[Insert Term] [Provide definition of the term used in this document.]

Release Strategy Template (v1.0) Page 10 of 10

[Insert appropriate disclaimer(s)]