Release Plan Procedure

Overview

This document will be to describe the Release Plan Procedure for in-house applications developed by Pasco County Information Technology Open Systems. 

Instructions 

Types of Releases 

  • Minor Release: A significant improvement to an existing system, many times packaging together several fixes. These are usually numbered after the decimal point of the major release. For example, a minor release to version 2 will be numbered 2.1 

  • Major Release: Introducing new functionality to the organization and contain either hardware or software. These are usually numbered before the decimal point. For example, a major release will be numbered 1.0 

  • Emergency Release: As the name implies, this is an un-planned fix that will only be used to resolve critical system errors that directly impacts business activities and where no practical workaround exists or the integrity of data within the application is at risk. These are usually numbered after the minor release number. For example, an emergency release to minor release 3.1 will be numbered 3.1.1 

Release Plan Template 

The release plan template presents and records the following details regarding a release plan. 

The basic details of the plan appear at the top of the template, and present the description of the release and the following details – 

  1. Description: Give a brief description of the items contained in the release. Describe any major issues being fixed or new functionality being introduced. 

  1. Plan Owner: This is who will update the list and the details on a periodic timeline and what their role is. 

  1. Submitted On: When the release plans were submitted, and to whom (the approver of the project) 

  1. Release Type: The type of release (one of the three types listed above), and the Release Number. 

  1. Status: Status of the plan (Approved, Pending Approval or Rejected)  

  1. Risk Level: Risk level of the plan (High, Medium, or Low). High risk means that if the implementation is unsuccessful, the organization will be impacted immensely. 

  1. Owner of the Release: The owner of the release program (usually this is the Project Manager). 

  1. The start & finish dates and the duration of the release plan 

  • Detailed Version List: Give a detailed list of items included in this release. Refer to Issues or Enhancement request numbers. You can insert the Chart from your tracking sheet. 

  • Who will be affected by the release: This can focus on the internal users who will need to adapt to the recent release changes and prepare accordingly. 

  • Risks: Every change includes risks, and a release plan must address these. Otherwise, they may be overlooked. The risk should have mitigation plans as well, not just the potential problem. 

  • Who needs to approve any CR (Change Request): Any change to the release must be submitted, reviewed, approved, and documented. This section outlines what the chain for these approvals is. 

  • The timeline: This is usually a high-level plan for the release and outlines what needs to be done and who, the status, and any comments about the tasks. The format can be Excel, MS-Project, etc. 

  • Implementation Notes: This section will be to describe how the release implementation went and any notes to consider or add to the Lessons Learned documents as well as any fallout from the implementation. 

Procedure 

  • For each new release, use the below template to communicate the details of the release. This document should be attached to the TDNext ticket and accompanying Change Request. 

  • Save a copy of this document in the appropriate IT Support Documentation folder. 

  • T:\IT Documents\IT Support Documentation\<Application Name>\Release Plans
Uploaded Image

Detailed Version List:

Who will be affected by the release:

Risks:

Release Plan Timeline:

Completed Release Notes:

Print Article