Release Planning

Releasing a new version/software/system requires planning called Release Planning on all fronts, including the IT department. The ITSM methodology defines a release as a set of authorized changes to an IT service. The Release Plan Template presents and records all necessary details regarding release plans.

Download This Template

Types of Release

Release are split into three types –

• 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 to a specific function that solves a symptom, allowing the IT department to root out the cause and fix the problem. 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 release plan template, and present the description of the release and the following details:

1. The owner of the plan. This is who will update the list and the details on a periodic timeline and what their role is.
2. When the release plans were submitted, and to whom (the approver of the project).
3. The type of release (one of the three types listed above), and the number of releases.
4. The plan (Approved, Pending Approval or Rejected) and its risk level (High, Medium, or Low). High risk means that if the implementation is unsuccessful, the organization will be impacted immensely.
5. The owner of the release program (usually this is the Project Manager).
6. The start & finish dates and the duration of the release plan.

• The version changes will be: These include the previous version's major changes or the last system used.
• 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 template 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 request 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.

How This Fits Into the ITSM Methodology

A release must be planned and tracked, like with any work plan. Planning the waiver allows the IT department to align its resources to its requirements while ensuring that it improves. A release plan considers the business needs and allows the IT department to prepare a solid plan to execute and bring the release to fruition.

Deploying the release is followed by KPI’s (Key Performance Indicators) gathering to ascertain whether the new release did, in fact, help the business side of the organization and to make any adjustments to improve these continuously.

Download This Template