Skip to main content

Getting Started with IT Service Change Management

Published Date
Author Brooke Tajer

IT service change management is the process of identifying, classifying, controlling, communicating and reviewing changes that may affect IT services. The Information Technology Infrastructure Library (ITIL) is one of the key IT frameworks that address IT service change management. In TeamDynamix, IT service change management is all handled within Ticketing Applications.

IT Service Change Management Process and Activities

IT service change management is a way for IT professionals to work together more effectively and more efficiently – it involves thinking through the potential impact of making a change, such as a system upgrade or reconfiguration and then developing a process that will cause the least amount of disruption.

With effective change management, you can prevent unforeseen complications and your IT team can spend less time resolving issues related to whatever upgrade or enhancement was made. And this is important because studies have shown that 80% of IT outages are due to changes, so having proper change management in place is critical in ensuring quality IT service.

Typically, IT service change management includes changes to production systems. However, institutions may also include changes to development systems, IT processes or even to the IT organizational chart. Organizations that want to avoid issues when updating these systems and processes track these types of changes within their IT Service Management (ITSM) tool to ensure the potential risks and impacts are identified and to help ensure any planned changes can be implemented with minimal negative impact to employees and customers.

When it comes to getting started with change management there are a few steps to follow:

  1. Defining what is a change: Your institution likely has some work that requires changing a production system, but that should not be called a change. For example, rotating a log file. Your institution should identify its threshold for what is considered pre-approved work vs. what should be tracked as a change.
  2. Logging the change: Before a change is performed, it will be logged or documented. In TeamDynamix, this means creating a ticket classification change. This change may be logged by an end-user requesting the change, or anyone else including the person who will eventually perform the change.
  3. Classifying the change: Logged changes can be classified to identify a rough sense of how risky they are or what their potential impact might be.
  4. Reviewing the change: Changes are then reviewed and approved, often in proportion to the anticipated level of risk or impact. 
  5. Building the change: The change is then built or prepared. This is a big step and includes most of the actual work of a change, such as scripting the change to be in production mode or writing the code.
  6. Testing the change: Ideally, the change is tested in a non-production environment to confirm that it works.
  7. Scheduling and communicating the change: When the change is ready for production, it is scheduled and potentially communicated to relevant stakeholders.
  8. Implementing the change: At the scheduled time, the change is implemented in production. If there are issues, appropriate roll-back plans are used to revert the change.
  9. Closing out the change: After the change has been implemented, it is closed. A post-implementation review can be conducted to identify lessons learned for future changes.
  10. Emergency change process: The process used for changes that must be implemented to restore production service.

It is common for change approval to happen after the change has been built and tested, prior to the production roll-out of a change. However, this means that the change management process is always stalling the production implementation, which can lead to many emergency or expedited changes.

In TeamDynamix ITSM, IT service changes are recorded as a ticket classification change. Change tickets often have workflows associated with them to map to an organization’s change management processes. One institution may have one simple notification-based change process; another may have a large set of change workflows depending on the ticket type or level of risk identified.

Pitfalls To Look Out For

These issues may affect how quickly you can implement an IT service change management process:

  • When implementing an IT service change management process, someone who can speak with authority to the mandate for change management ideally needs to be included, so that decisions can be made about the process while it is being implemented.
  • Some project teams may not have knowledge of IT service change management or awareness of why the process exists. This can hinder the decision-making process for the implementation. This could be mitigated by ensuring the project team has an orientation.

Examples of IT Service Change Management

The following are examples of IT service change management:

  • Alex in networking needs to upgrade a core network switch. Alex logs a change request for this upgrade. That change request is then reviewed and approved as a low-risk change. It is noted that no communication is required. Alex schedules and then performs the core network switch upgrade. The upgrade goes as planned and Alex closes out the change request.
  • Billy on the systems administration team needs to perform a routine OS upgrade to the campus enterprise resource planning (ERP) system. Billy logs a change request for this upgrade. As part of the change request review, it is noted that the last time a change like this occurred, the service was down for a long time. The change is approved as a medium-risk change after a back-out plan is identified. Billy performs the change during a maintenance window. There are a few hiccups, but Billy still completes the change within the window. Billy closes out the change request.
  • Carly on the database administration team needs to add database extents to a financial system. However, no one besides Carly knows what that means, and the work has previously been de-prioritized. Carly logs a change request for this work. As part of the change review, people learn more about the importance of the change. They also realize that the work needs to happen immediately so that the financial system can handle the year-end financial rollover. The change is identified as a high-risk change due to its business impact and the change is approved to be completed ASAP. IT managers work with the finance department to schedule a special outage window and communicate with the departments affected. Carly can perform this important work and close out the change request once it is performed.

Finding the Right ITSM Tool to Support Change Management

“We started our search with Info-Tech looking at just change management tool to add to our existing ITSM tool at the time, then realized we also wanted to find a tool that could help us automate processes,” he said. “Info-Tech provided us with some great options, so we started the vetting process and found that TeamDynamix really fit our needs – not just for change management and automation, but for everything.”

“We were blown away by all that TeamDynamix offers, and our renewal was up with our former ITSM tool so we decided to just replace it all,” Keyon Farrier, service desk manager at Legacy Supply Chain Services, said. “We were really excited about the out-of-the-box features from TeamDynamix and knew the tool would help not just with change management and automation, but with some of the other challenges we were facing as well.” 

As a result of the switch to TeamDynamix “we’ve become a lot more efficient as a team because we’re getting the right tickets to the right people faster,” said Farrier. “We can now respond to service requests quicker as well. And we have a lot more visibility in terms of reporting.”

With TeamDynamix, the Legacy Supply Chain Services implemented a self-service portal—and IT staff have taken the time to build out forms that gather as much information on the front end as they can. As a result, “We’re now able to provide support in a timelier fashion,” he said.

What’s more, by expanding the number of service categories they have, Legacy’s IT team has been able to create more accurate reporting.

“Having better reporting has allowed us to focus our attention on areas that are demanding change,” Farrier said. “We can engage the right individuals to bring forth the right type of change based on the data we’re seeing.”

With more accurate information, Farrier and his team can address the root cause of problems, instead of repeatedly addressing the same types of service issues. “This has been a tremendous help to our overall processes and reducing the drain on our IT resources,” he concluded.

Looking to learn more about ITSM change management? Check out: ITSM Change Management; a Risk-Based Approach to Change Review and Approval