The purpose of the Change Management process is to enable beneficial changes to be made with minimum disruption to business operations, ensuring that the best possible levels of service quality and availability are maintained.
IT Change Management process is to enable beneficial changes to be made with minimum disruption to business operations, ensuring that the best possible levels of service quality and availability are maintained.
The scope of Change Management includes managing all changes to the live environment, including both services and technology
The objectives of Change Management are to:
The Change Management Process Owner’s primary objective is to own and maintain the Change Management process. The role of Process Owner is usually a senior manager with the ability and authority to ensure the process is rolled out and used by all stakeholders.
Responsible for:
The IT Change Manager handles the day-to-day facilitation of the change process. This role is focused on the management and administration of all changes.
Responsible for:
The Change Requester/Implementer
Responsible for:
Responsible for:
The Change Approver must decide if a change has been well planned to have mitigated any risks to services. All non-Standard change requests have one or more Change Approvers. The primary approver is the group/team manager who validates the change for technical accuracy and completeness.
Responsible for:
The CAB Manager will facilitate the CAB meeting or can delegate the responsibility.
Responsible for:
The CAB performs the assessment and authorization of changes. CAB members are approvers. The CAB reviews, authorizes, prioritizes and dispositions requests. The CAB is typically made up of representatives from all areas within the IT service provider and may include stakeholders from business units, partner IT teams and third parties such as suppliers. If a standing member of the CAB is unable to attend, a delegate may be assigned to the CAB meeting. The CAB is considered a change authority.
The ECAB is an ad-hoc gathering of individuals needed to make a decision on the timing, urgency, risk and impact of the change activity. The ECAB may be a subgroup of the change advisory board that makes decisions about emergency changes. Membership may be decided when a meeting is called and depends on the nature of the emergency change. The ECAB is considered a change authority.
The change management process uses a state model which is designed to make it clear at what stage of the life cycle the change currently resides. Specific activities occur at each state based on change type.
Identifying risks associated with change requests is critical for an effective change process.
Assessing risk can be challenging especially if there is no history or sufficient data to support a level of risk.
The risk value is defined as the risk of implementing the change - what effects could occur to disrupt the impacted service?
Examples
Is there redundancy?
Low risk for implementing the change.
Impact to business services unknown?
Potential high risk for implementing the change.
The expected or anticipated risk if the change is not implemented is a Justification for performing the change.
High risk for not implementing a change may rise to the level of an emergency change.
When identifying risks, keep a business-impact focus in mind:
Every change request includes the requester’s initial assessment of the impact and urgency of the change but may be modified in the change authorization process.
Impact values range from Low to High. Impact is the measure of how critical the impacted service is to the business. Widespread services affecting a large number of users would have a high impact value. Impact may drive urgency. When a large number of users are affected, urgency may be elevated. Applying quantitative analysis or level of criticality for the impacted service may help to determine impact.
Urgency values range from Low to High. The more the business is reliant on the availability of the service and the need not to delay implementation, the higher the urgency to complete the change request. Heavily utilized services that the user base is highly dependent on, are usually associated with a higher impact value. For example, delaying the deployment of the change for two weeks implies low urgency. Urgency is relative to the current time; the time the change request is submitted.
Guidance for selecting the impact and urgency for the change request is determined by applying judgment and knowledge.
Priority is derived from the agreed impact and urgency. If the Priority value is HIGH or CRITICAL, a emergency change may be required.
Normal changes are not pre-authorized or pre-approved and there are no routine procedures or work instructions that have previously been approved by the Change Advisory Board or change authority. This type of Request for Change (RFC) is not routinely done and the outcome may not always be known.
An emergency change is used when a change must be introduced as soon as possible.
An emergency change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Emergency changes stress the IT change management system and should not be used to compensate for poor planning. Emergency changes must be for exceptions and not become a shortcut to getting changes into production for any reason.
An emergency change is sometimes required and while time is of the essence, it should be designed carefully and tested as much as possible before implementation. The impact of the emergency change may be greater than the original incident that instigated the change.
The ECAB may be a subgroup of the regular change advisory board (CAB), or a different change authority that makes decisions about emergency changes. Membership may be decided at the time a meeting is called, and depends on the nature of the emergency change. The Change Requester/Implementer contacts the appropriate change authority for approval.
A standard change is a routine change. Standard changes are “a pre-authorized change that is low risk, relatively common and follows a procedure or work instruction” and the outcomes are well known and predictable.
By definition, standard changes should be repeatable, occur frequently, and are proven to be low risk. Any procedure or work instruction for standard changes must be pre-approved by a change authority. Approved proposals become standard change templates and can be implemented anytime without approval.
The Standard Change process offers a method to reduce some of the administration around changes. This process allows certain changes to avoid a lengthy approval process and formal discussions and can be implemented in a much faster timescale.
Standard changes are those that are low risk, with repeatable implementation steps and a proven history of success.
Once a standard change is submitted into the lifecycle, the standard change does not require approvals.
A standard change proposal is a formal request to implement a common, low-risk change that follows a documented process.
The proposal will be converted to a template and made available for use after full approval from the change authorities.
Standard change templates can also be modified or retired. The IT Change Manager will monitor how frequently the templates are used and decide whether the template should be retired or temporarily withdrawn. Modifying or retiring a template follows the same workflow as creating a standard change proposal.
Incident Pending Change
Changes can be raised to resolve an existing incident. Once the change is implemented the incident can be reviewed to confirm that it has been resolved.
Incident Caused by Change
Incidents may be caused by a recently implemented change. These incidents are associated with the change that caused the incident. To clear the incident(s), a new change will be raised to resolve the issue.
The configuration management system (CMS) underpins all records and activities related to any configuration item (CI). It contains details of the infrastructure vital to services, CIs, and any relationships.
Affected CIs identified in the change record are the CIs that are being changed while the identified impacted CIs are those CIs that are affected by the changes made to the affected CIs.
The configuration management database (CMDB) is used within the change management process by relating CIs including services and service offerings to the change.
Risk and Impact Assessment: Consistently evaluate and document risks, business impact, and resource requirements for each change.
Thorough Change Approval Process: Ensure appropriate review and authorization to minimize disruption.
Effective Planning and Scheduling: Balance the urgency of changes with their impact on operations to maintain business continuity.
Stakeholder Communication: Inform and engage stakeholders at all stages of the change lifecycle.
Post-Implementation Review: Measure change success, analyze failures, and document lessons learned for continuous improvement.
Change Success Rate: Percentage of changes implemented successfully without causing incidents or disruptions.
Change Approval Time: Average time taken for changes to be reviewed and approved, reflecting process efficiency.
Number of Failed Changes: Number or percentage of changes resulting in failure or unplanned incidents.
Emergency Change Percentage: Proportion of changes classified as emergency, indicating the level of proactive planning.
Post-Implementation Review (PIR) Completion Rate: Percentage of changes with completed post-implementation reviews to analyze outcomes.
Service Desk managers meeting
ITSM Advisory/steering teams