Most organizations have implemented Change Management, but the results vary. In particular, some organizations lack effective control over core change-management activities, leading to unsatisfactory outcomes and even exposing them to the risk of losing control. It is therefore necessary to examine the key activities in change management in detail and illustrate them with examples.
01 Change Model and Applicable Scenarios
A change model is a repeatable management approach for a specific type of change. It provides guidance for handling general changes and addresses the challenge of applying different management approaches. Organizations can define change models according to the assessment, authorization, and ongoing control required, thereby improving change efficiency and effectiveness.
When designing change models, different models can be defined based on the following:
The system/technology involved in the change
The scale of the change
Location/region
Customers/Users
Compliance requirements affecting the change
The following are multiple change models defined by an IT organization:
02 The Role of Change Windows
In IT O&M, changes are often implemented without sufficient planning or coordination and may even be carried out arbitrarily. To avoid this, planned changes should be coordinated and scheduled through change windows.
The purpose of a change window is to designate specific dates or time periods for implementing changes across different business lines and systems, thereby reducing the impact of ad-hoc changes on services.
When establishing change windows, multiple factors need to be considered:
Impact on Business
Geographic Distribution
Specific business requirements of individual customers
Time required for implementation and rollback
……
Once defined, change windows should be officially published for all personnel involved in the change process.
The following is an example of a change window:
03 Definition of Standard Changes
Standard changes, also known as pre-authorized changes, are changes that occur frequently, have a limited scope, follow standard operating procedures, and carry low implementation risk. They are characterized by high frequency, ease of execution, and a low probability of failure. Such changes can be pre-authorized to avoid cumbersome approval processes and improve efficiency. Examples include creating user accounts, modifying network connections, and reinstalling operating systems.
In daily IT O&M, 70% to 80% of changes are simple and repetitive. Standard changes enhance the efficiency of change management. By standardizing these routine tasks, eliminating approval steps, and empowering the personnel responsible for implementation, the overall efficiency of the change management process is improved. This is the core value of standard changes.
However, it is important to note:
The primary purpose of standard changes is to increase efficiency. Therefore, changes that are simple and low-risk but occur infrequently do not need to be defined as standard changes.
A standard change does not mean that risk control is ignored; rather, the change has already been risk-assessed before being classified as standard. To qualify, a change must have been executed successfully many times without failure; otherwise, its inherent risks make it ineligible. Standard changes should also involve relatively small amounts of money. Changes involving significant expenditure require approval from relevant stakeholders and cannot be handled as standard changes.
Methods for Defining Standard Changes
Establishing Rules
This approach defines standard changes through rules. Rules are easy to create, but they may lead to disputes during execution. Rules can define the attributes or categories of a standard change, but they cannot enumerate every possible case.
The following is an example of a standard change defined by an IT department using a rule-based method:
No more than 2 personnel are involved in the implementation.
No adjustments to the technical architecture shall be involved.
The associated costs shall be below 3000 yuan.
Enumerating Scenarios
This approach lists the standard changes used in daily operations and creates a predefined standard-change catalog. The catalog is not static; it expands as new change scenarios arise. It should be reviewed every six months or annually by members of the Change Advisory Board (CAB). The advantages are clear definitions, strong scenario specificity, and high operability. Its weakness is incomplete coverage, since some standard changes may be omitted. Continuous expansion of the catalog helps mitigate this limitation.
04 How to Conduct CAB Meetings
The CAB (Change Advisory Board) team and CAB meetings are critical to change management implementation. Many organizations that are planning or have already implemented ITSM are uncertain about how to conduct CAB meetings effectively. The following provides a concise introduction to the key practices.
CAB Membership and Responsibilities
The selection of CAB members requires comprehensive consideration of various aspects, such as the underlying infrastructure architecture, business requirements, SLA/OLA, and relationships with suppliers. Selecting appropriate members is crucial for the correct assessment of changes.
The personnel involved in CAB meetings consist of two categories: CAB Members and Meeting Attendees.
CAB members must attend all CAB meetings and have the authority to approve or reject changes, set priorities, and schedule changes.
Meeting Attendees include experts, technical teams, supplier representatives, and business stakeholders. They are responsible for providing specific information related to the change and offering professional advice. Attendees are invited by the Change Manager as needed.
At the same time, the CAB must assume defined responsibilities and possess the corresponding authority. The following is an example of a responsibility-and-authority list developed by an IT department:
CAB Voting Process
One of the most common activities in CAB meetings is voting on items within the change list to determine whether changes should proceed as planned. The following outlines the CAB voting-related strategy of an IT department, including pre-meeting requirements, in-meeting activities, voting options, and the meeting agenda. These elements should be officially documented in the Change Advisory Board Charter and published.
1 Before the Meeting
If a change management tool is in place, it may be equipped with a voting function for CAB members after they complete the review of change tickets:
Modern change management software provides risk assessment, impact analysis, and automated approval routing. Modern change management software provides risk assessment, impact analysis, and automated approval routing.This is particularly useful when not all CAB members can attend the meeting. In such cases, notifications containing the Request for Change (RFC) details and voting buttons (e.g., via IM or email) should be sent.
If the pre-meeting vote is not decisive, a secondary vote must be conducted during the meeting.
2 During the Meeting
Voting shall be conducted during CAB meetings.
3 Voting Options
Approve
Reject
Postpone
Request further testing
4 Meeting Agenda
The agenda should include the following activities:
1 Review of the final RFCs: Understand and address any unresolved or questionable aspects of the RFCs with the help of the present experts.
2 Vote to approve or reject changes.
3 Prioritize Changes
4 Schedule Changes
5 Review Implementation Results: Review the outcomes of all changes implemented since the last CAB meeting, with a focus on failed implementations.
6 Discuss Other Business:
Changes in roles within change management activities.
Identify and document general changes that could potentially be designated as standard (or pre-authorized) changes.
Process improvement suggestions and actions.
Metrics and reporting.
Given the complexity of the topics that must be discussed and decided, CAB meeting time is often limited. Thorough preparation is therefore essential. For a one-hour meeting, each agenda item should generally be limited to 10–20 minutes.
05 Change Risk Assessment
Risk assessment determines a change’s risk level by scoring information about the change comprehensively and then classifies the change type. Once the type is identified, the change follows the corresponding approval path.
Risk = Impact × Likelihood of Risk Occurrence
The risk matrix below classifies changes by risk level based on impact and likelihood and provides examples of how impact and likelihood are defined.
Risk Definitions
Likelihood Definitions
06 Post-implementation Review of Changes
The purpose of post-change review is to determine:
Whether the change achieved the expected outcomes and objectives
Whether users, customers, and other stakeholders accept the results of the change
Whether the change had no other adverse impacts on service levels (e.g., availability, capacity, security, performance, or cost)
Assess whether the change achieved its intended objectives.
Assess whether stakeholders accept the change results.
Whether the change was implemented on time and within the expected cost
Confirm whether the change caused any additional incidents.
Organizations can use the following content for post-implementation reviews to confirm that change objectives were achieved, that the initiator and other stakeholders accept the results, and that the change did not trigger additional incidents.
Overall, an effective change management process not only ensures the stability and security of IT services but also improves business efficiency and user satisfaction. By clarifying change types, establishing change windows, defining standard changes, and organizing CAB meetings, enterprises can better control change risks and manage changes in an orderly manner.
We hope that these detailed guidelines and case analyses will provide useful references for organizations implementing ITSM change management and help them continuously optimize their IT O&M management practices.
