This recipe discusses creating a Change and Release Management process for an organization.
In Change Management we focus on enhancing existing services, service components, or introducing new services and components without an unplanned interruption to existing services. Release Management focuses on when the changes are implemented and manages planned interruption to services.
The ITIL© framework online resources delve much deeper into the best practices for the Change and Release Management processes. You must plan to review and understand Change and Release Management principles as a prerequisite to creating the processes.
An example of the steps for creating a Change and Release Management process is as follows:
Agree and document the organization Change and Release Management policy with the aim of identifying the following :
Change types and categories
Change type priorities
Policy owner
Create and continually update a service map for all services and applications in scope of Change and Release Management. Examples include but are not limited to the following types of services: infrastructure services, messaging, and collaboration services. A best practice industry approach is the RACI model:
Responsible (R): Who is responsible for the service or service component?
Accountable (A): Who is accountable for the service? This is typically the assigned business unit application owner.
Consulted (C): Who is consulted about the service operations? Typically support team acting as the subject matter experts.
Informed (I): Who is informed about service availability?
Document the operational process to support the Change and Release Management policy. The operational procedures should include the following:
Create and assign people roles to manage the process. For example:
Change managers
Release managers
Change implementers (this would be a logical role as implementers will vary based on the change type and related service)
Review the Change and Release Management process with the aim of identifying instances of the following type:
Candidates for Service Request fulfillment (changes that have been successfully validated as low risk and low impact based on an agreed number of successful implementation results).
Changes requiring re-classification. For example, a minor change that results in a major outage due to an identified dependency service.
Release window adjustment due to a business process schedule change. For example, a financial audit application used during peak accounting periods may require a special release window.
The Change and Release Management process once established typically have the following operational states:
Initiate
Approve
Technical (validation from a technical perspective)
Management (validation from a cost and business risk perspective)
Implement and Release
Implementation steps and owners (who does it and how)
Release schedule alignment (when it gets done)
Post implementation review. For example:
Successful in the time allocated
Successful but overrun time allocated
Failed
Resubmissions
The following figure provides an example of the process from the change initiation stage:
In Change Management we use Release Management principles to coordinate multiple changes in cases where these changes may impact on each other. We focus on the following areas when creating and implementing Change Management:
Organization culture
Successful Change Management creation requires complete buy in from the whole organization
Exceptions and breaches of Change Management are opportunities to educate and refine the process as appropriate
Change Management is a journey not a destination (expect changing conditions and adapt as appropriate)
Categorization and classification
What type of change, and how it impacts existing services?
How important is the change?
Approvals
Who has the authority to approve?
Who has the best knowledge on the impact and risk to the existing services?
Cost justification
Post implementation analysis
Unplanned impact of changes
Configuration management updates and service catalogue maintenance
Lessons learnt (Knowledge management)
Release Management can be:
Simple:
Manage the forward change schedule
Multiple changes that affect the same service component requires coordination
Multiple changes grouped and released during the same maintenance window
Complex:
Extension of application life cycle management
New software developed in house
Patch Management is a candidate for Release Management
Release Management is a discipline with broad and wide coverage. Best practice for creating the process is; you should plan to assign a release management expert. The process should also have a supported agreed organizational policy.