Understanding Change Management and Its Importance Within Your Organization

IT service change management is a way for IT professionals to work together more effectively and more efficiently. With effective change management, you can 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.