IT Change Management; a Risk-Based Approach to Change Review and Approval

Generally speaking, it is now a requirement for ITSM software to include change management. In fact, studies will show that as much as 80% of ticket volume has historically been caused or generated by poor change management. Yet, knowing this, many organizations are still struggling to adopt a framework for managing risk and approvals around changes. Let’s look at how to get started with change management and improving your IT Service Management maturity. 

What is Change Management?

Change management is the discipline that guides how an organization prepares, equips and supports individuals to successfully adopt change in order to drive success and outcomes. The goal of Change Management is to minimize the risks associated with changes while maximizing the benefits of the change.

Proper change management is a core component of the ITIL framework. For organizations looking to improve their maturity around IT Service Management, this is a great place to start. From the rollout of new technology to changes in processes or procedures – change management is everywhere. Without proper change management principles in place, an organization may struggle to deliver results and drain valuable IT resources in the process. 

Change management is important because it helps to ensure that changes are made in a controlled and consistent manner, minimizing the potential for disruption to critical business systems and processes. Without proper Change Management, changes can be made without adequate testing, planning or communication, which can result in downtime, lost productivity and even data loss or security breaches.

Effective change management involves several key steps, including identifying the need for change, evaluating the potential impact of the change, developing a plan for implementing the change, testing the change in a controlled environment, communicating the change to all affected stakeholders, and documenting the change for future reference.

Within IT departments, most organizations use IT Service Management (ITSM) platforms to effectively manage the change management process. With the right tool, you can identify and avoid issues that could impact your existing services – meaning your IT resources will spend less time fixing failed changes and can focus on more proactive projects.  

One way to build out your change management process is by taking a risk-based approach to change review and approval where changes are evaluated in terms of risk. Here is how to do that. 

Start with Setting Risk and Approval Levels

Start with defining your risk levels: 

  • Low-risk – Requires approval by a local authority, such as an IT manager for the area that would perform the change. The local authority can choose to approve, reject, or escalate the change to medium risk. 
  • Medium-risk – Reviewed first by a local authority, and then they move on to the Change Advisory Board (or CAB). The CAB then chooses to approve, reject, or escalate the change to high risk. 
  • High-risk – Reviewed by the local authority and the CAB, and then a higher-level group such as an IT Management Board (ITMB) chooses to approve or reject the changes. 

When using multiple levels of risk to determine the path of approvals, it is important to have a clear definition of each level. Factors to consider include: 

  • The complexity of the change (in terms of interdependencies of systems and/or teams). 
  • Length of downtime. 
  • Criticality of the service(s) being impacted by the change. 
  • Confidence/capability of rolling back the change. 
  • Confidence in the change success (i.e. have we made a change like this in the past?). 

If you implement an approach like this, consider structuring your deadlines and meetings in such a way that escalating a change to a higher-level review does not take much time. 

For example, to efficiently escalate a change from the CAB to the ITMB: 

  • Friday at noon: Medium- and high-risk changes might be due to the CAB and ITMB for review. 
  • Friday, end of the day: An initial agenda could be sent to the CAB and ITMB. 
  • Monday morning: The CAB might meet to review and possibly escalate changes. 
  • Monday, end of the day: The ITMB could receive a list of changes escalated by the CAB. 
  • Tuesday morning: The ITMB might meet to review changes, including those escalated by the CAB. 

Example Change Advisory Board (CAB) Agenda

It can be helpful to have an agenda to send to a change advisory board (CAB) ahead of time, so that CAB attendees understand what will be covered in the meeting. Potentially, this same agenda can be used in the meeting to take notes, and afterward, that document becomes the CAB meeting minutes. 

If you do build CAB agendas and use them to record minutes, please consider archiving these minutes. They can be helpful later as a point of reference and sometimes IT auditors ask to see CAB documentation. 

Below is an example CAB agenda that you can use as a starting point for your meetings. 

CAB Agenda for Month/Day/Year 

Attendees 

[Add names for each person attending at the beginning of the meeting.] 

Action Item Review 

[Here, you put action items from previous CAB meetings. These are for items that aren’t changes, but that should be addressed.] 

Post-Implementation Reviews 

[This is an FYI – you do not need to talk about these closed changes in detail. However, the CAB may decide it wants to discuss selected changes or hold a separate review session. 

This section can be populated by a TeamDynamix report for changes with a resolved date greater than the value you specify.] 

Change Management in Action

For organizations undergoing rapid growth with limited IT resources, change management should be a priority. At Northeast Ohio Medical University (NEOMED) they were struggling with unforeseen issues after each technology-related change. Using TeamDynamix for their ITSM, they were able to build out a comprehensive and well-thought-out change management strategy to address their issues.  

“We set up a special form within the system called a change form, and whenever a production change is pending, we have the technical lead fill out that form,” Geri Hein, project manager within the university’s IT division, said. For larger changes, the change form is routed to a change control team that consists of Hein, a business analyst, the managers of the university’s IT infrastructure and database groups, and the IT director. 

This process has increased communication within the IT service management team and helped with troubleshooting problems. 

Now, whenever a change is coming, the key people who need to be aware are automatically notified in advance, so they can weigh in if they foresee any risks or dependencies in order to ensure a smooth transition. Changes are linked automatically to the ticket calendar feature within TeamDynamix, so IT staff can easily see which changes were made on which days. 

“If there’s a problem, we can go to the calendar and determine whether it was related to a particular change or not,” Hein says. “There have been a few instances where our infrastructure team made changes that we didn’t think would cause problems with our ERP system, but they did. [Because of the change management process] we were able to track it back to the right source and easily resolve the issue.” 

To read more about NEOMED’s experience, or other TeamDynamix customers, check out our Customer Spotlights. 

You might also like:

This website uses cookies to ensure you get the best experience on our website. By closing this notice you agree to the use of cookies.