Releasing a new version / software / system requires planning called Release Planning on all fronts, including the IT department. The ITIL methodology defines a release as a set of authorized changes to an IT service. The Release Plan Template presents and records the all necessary details regarding a release plans.
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 to will be numbered 1.0
- Emergency Release: As the name implies, this is an un-planned fix to a certain function which simply 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 template, and present the description of the release and the following details –
- The owner of the plan. This is who will update the plan and the details on a periodic timeline, and what their role is
- When the release plans was submitted, and to whom (the approver of the plan)
- The type of release (one of the three types listed above), and the number of release
- The status of the plan (Approved, Pending Approval or Rejected) and its risk level (High, Medium or Low). A High risk means that if the implementation is unsuccessful, the organization will be impacted immensely
- The owner of the release program (usually this is the Project Manager)
- The start & finish dates, and the duration of the release plan
- What the changes in the version will be: These include the major changes from the previous version, or the last system which was used.
- Who will be affected by the release: This can focus the internal users who will need to adapt to the changes of the new release, and help them prepare accordingly.
- Risks: Every change includes risks and a release plan must address these, otherwise they may be overlooked. The risk should include 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 by who, the status and any comments pertaining to the tasks. The format can be Excel, MS-Project, etc.
How This Fits Into the ITIL Methodology
A release must be planned and tracked, like with any work plan. Planning the release allows the IT department to align its resources to the requirement of the organization, while making sure that the business improves as a result. A release plan takes into consideration the business needs, and allows the IT department to prepare a solid plan which will 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 in order to continuously improve these.
Download Release Plan Template