Getting Started with IT Service Change Management

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 the 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. Additionally, studies have shown that 80% of IT outages are due to changes. Effective change management can therefore improve the quality of IT service.

Typically, IT service change management’s scope includes changes to production systems. However, institutions may also include changes to development systems, IT processes or even to the IT organizational chart. Organizations track these types of changes to ensure the potential risk and impact are identified and to help ensure the change can be implemented as planned.

IT service change management has several key activities. The following outlines the sequence of activities and describes what each entails:

  1. Defining what is a change: It is likely that your institution 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.

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

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.