Getting Started with IT Service Change Management

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.