Creating a Change and Release Management process

This recipe discusses creating a Change and Release Management process for an organization.

Getting ready

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.

How to do it...

An example of the steps for creating a Change and Release Management process is as follows:

1. 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
2. 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 service: infrastructure services, messaging services, 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, this is a support team acting as the subject matter experts.
   • Informed (I): Who is informed about service availability?
3. Document the operational process to support the Change and Release Management policy. The operational procedures should include the following:
   • Technical approvers and management approvers
   • Plan for proxy approvers to cover expected or non-expected absence of main approvers
   • Maintenance schedules (approved change implementation windows)
   • Release process structure:
     • By change stage
     • By change type
     • By maintenance window
4. 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)
5. 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.
6. The Change and Release Management process, once established, typically has 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
     • Resubmission

   The following figure provides an example of the process from the change initiation stage:

   

How it works...

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 does it impact 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 learned (Knowledge Management)

There's more...

Release Management can be as follows:

• 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. A best practice for creating the process is this: you should plan to assign a Release Management expert. The process should also have a supported agreed organizational policy.