Blog

|

April 26, 2024

6 minutes read

Understanding Change Management and Its Importance Within Your Organization

By

Andrew Graf

Did you know that a significant number of IT incidents occur when someone makes a change to one system that then affects other systems in unexpected ways? (Some will even assert that poor change management accounts for 80% of all tickets!)

Change management is a critical component of improving an organization’s IT maturity. But for change management to work, you need to understand the ITIL standards that are the foundation of proper change management. Without this understanding, you’ll continue to see a drain on your IT resources every time a change is made within your organization.

What is Change Management?

Change management is a vital aspect of IT organizations that entails planning, tracking, and controlling all modifications made to IT systems, processes, and services. It ensures that organizational changes, such as software updates, hardware replacements, and network reconfigurations, are executed efficiently while minimizing the associated risks. The primary objectives of change management include minimizing disruptions caused by modifications, reducing downtime, enhancing software stability, and minimizing the likelihood of human error.

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.

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.

Change management processes consist of several steps, including assessing the need for change, logging change requests, evaluating the potential impact and risks associated with the proposed changes, and designing and testing the solution appropriately. Each step in this process should be thoroughly documented, and the change management team should ensure that the changes comply with organizational policies.

Many organizations follow the ITIL framework standards for change management. Within this framework, the objective of change management is to mitigate the risks and impacts of the change you are implementing. Following ITIL, it’s important to consider each of the following when rolling out a change:

  • The reduction of risk and impact
  • The maintenance of the current working state
  • The communication around the rollout and approval management
  • Effective change planning with optimized resources
  • The reduction in the number of incidents due to change execution

By using ITIL’s change management process, you can mitigate the unforeseen consequences and downtime that stem from improper or non-existent planning and controls. By managing and documenting changes, you can avoid the flood of major – often avoidable – issues.

Did you know poor change management can account for nearly 80 percent of all IT tickets?

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. 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 risks and impacts 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:

  • 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.
  • 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.
  • 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.
  • Reviewing the change: Changes are then reviewed and approved, often in proportion to the anticipated level of risk or impact.
  • 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.
  • Testing the change: Ideally, the change is tested in a non-production environment to confirm that it works.
  • Scheduling and communicating the change: When the change is ready for production, it is scheduled and potentially communicated to relevant stakeholders.
  • 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.
  • 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.
  • 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

Proper change management positively impacts IT organizations’ operations by ensuring fewer system outages, reduced downtime and fewer service disruptions. This means that IT teams can focus on identifying efficiencies, implementing new solutions and improving IT processes.

Before you get started with change management you should be aware that there are issues that 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 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.

Change Management in Action

No formal change management process existed when IT Manager Jason Mohs started working for the Walbec Group. “We’ve built one out in TeamDynamix, and it’s been very effective,” he said.

Whenever someone intends to make a change that will affect employees and IT systems, like updating software or implementing a new technology, they must submit a plan within TeamDynamix. This plan must describe what steps the change will involve, when the change will occur and why, and which other systems, technologies and users the change might affect. The plan is then reviewed and approved by the managers of the affected IT divisions.

This documentation process forces people to think carefully about the repercussions of any changes they make, thus reducing the chances that something will go wrong. It also creates a public record of the intended change. If something unexpected occurs, managers can quickly identify the cause of the problem and respond.

“I don’t have to email everyone in my department to find out what they did and when,” Mohs explained. “It takes away this potential time drain. Instead, I know exactly where to look to find what I need and troubleshoot if needed.” And because the information is all there, Mohs and his team can respond quicker if there’s a problem instead of trying to find where the issue originated.

You can read more about Walbec Group’s ITSM journey here.

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 division 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.

Andrew Graf

Related Articles