Change Management for Service Organizations: A Resourceful Guide

Service organizations are in a tight spot, with two critical yet conflicting expectations from user entities: providing reliable, stable services that meet end user expectations while also pushing regular updates to stay ahead of ever-changing requirements. Failing to maintain reliability can be extremely costly — Gartner reports an average downtime cost of $300,000 per hour — and not keeping up with the competition can be just as detrimental. To succeed in this harsh environment, a rigorous change management practice is essential for shipping updates quickly while preserving stability and minimizing risk.

Let’s explore what change management means for service organizations, the process, challenges and best practices.

What is change management?

Change management is the process used to ensure that all changes made to the production IT environment are approved, documented, tested, and implemented in a coordinated way. This helps to prevent unplanned outages and disruptions, and ensures that only authorized modifications are applied. Change management is often seen as part of the wider ITIL (Information Technology Infrastructure Library) best practices, but it can also be used as a standalone process.

For service organizations, change management is largely part of the general IT controls. Why? Because service organizations rely on technology to deliver their services. If something goes wrong with the technology, the service organization may be unable to meet its commitments to its customers. As a result, the service organization's change management controls will be subject to review as part of the requirements for SOC 1 and SOC 2 reporting.

Any addition, alteration or removal of anything that could potentially have an effect on the services an organization provides to its users is considered a change.

The main types of changes

There are three core types of changes namely normal, standard and emergency

1. Normal changes

Normal changes are those that don't have an established, pre-sanctioned process and are not urgent. But they still deserve proper planning and execution to ensure success. The key is to consider all of the variables involved with the change and create a plan accordingly.

For instance, if you're looking to upgrade the content management system, you'll need to understand what the new version offers compared to the current version, bring stakeholders on board for feedback and approval, make sure the new system will integrate properly with existing systems, set up appropriate training resources for user adoption, develop effective communication materials that explain why the change is occurring and how it benefits users — plus much more!

Taking these steps when planning a normal change will greatly help increase the chances of success while minimizing any unanticipated issues.

2. Standard changes

Standard changes are those that are regular and pre-approved. These are generally low-risk, occur frequently and adhere to a documented, accepted process. Not only are they a cost-effective means of achieving desired outcomes, but their frequency also stops them from becoming a daunting task due to their level of repetition. The processes followed for standard changes can further streamline operations, as the steps have already been documented and approved by IT personnel.

Standard changes provide a great opportunity to leverage automation. It's quite common for companies to automate a large segment of their standard changes, giving their teams time to focus on more complicated changes.

3. Emergency changes

Emergency changes are sudden modifications that need to be taken care of quickly, in order to protect customers, employees, and systems from unexpected threats or errors. For instance, as soon as a security patch becomes available, it needs to be immediately implemented. Such patches help maintain high levels of network security and safeguard sensitive customer data from attackers who could exploit vulnerabilities and disrupt operations.

Effective emergency changes are critical for any business to protect the integrity of their systems and ensure the safety of their users. Customer service is also paramount when it comes to an emergency change, as businesses should keep impacted customers updated on the progress of resolving changes, while also providing any security protocol they may need to follow in order to safeguard their information. Without swift action and sound customer service amidst emergencies, the service organization and their user entities can greatly suffer reputational damage.

Objectives of change management

The overall objective of change management is basically to ensure that changes on the production IT environment are successful without any impact on the services. Here is a comprehensive breakdown of the objectives:

• To ensure that changes are made in a controlled and predictable manner so that there is little to no risk of something going wrong during or after the change is made.
• To minimize the risk of disruptions to service due to changes to the production environment by making sure everyone is aware of the change and its potential effects on users or services.
• To ensure that all changes to the production environment are documented and tracked so that it's easy to identify what was changed, when it was changed, where, and by whom.
• To ensure that only authorized changes are made, and by authorized individuals only.
• To ensure that all changes to the production environment are tested before they are deployed.

The change management process

Not every change management process requires all the steps laid out below, but it is always beneficial to have a clearly-defined sequence of events that guide the transformation from request to execution and post-testing. That said, in some scenarios it may not be practical or possible to adhere strictly to such a procedure, for instance when dealing with an urgent situation and the IT team needs to act fast.

However, for well-planned changes, here's an outline of a typical modern service organization's change management process:

Step 1: Change request

Someone triggers a request by creating a ticket. This ticket contains all the necessary information regarding the proposed changes from who requested it, what needs to be changed, why this change has been requested, and when it needs to be implemented into production. This helps to ensure that all changes are clearly documented and that there is a clear understanding of the impact each change may have on any aspect of operations. It is essential for organizations to keep an accurate record of their requests for changes. This record can then be evaluated and discussed before implementation.

You can enhance the change request process by establishing a user-friendly self-service portal for stakeholders and IT personnel to easily submit a standard change request. In other words it’s essential for the development and IT teams to work together on the same platform to provide full visibility and transparency over the change request process.

Step 2: Evaluation of change request

This is a crucial step and requires careful consideration from a team of experts. A change manager or peer reviewer initially reviews the proposed change, posing such questions as: will this change be effective? Is it worth implementing? The team will analyze the implications of the proposed changes, evaluating factors such as feasibility, cost efficiency, and consistency with existing policies and procedures. Without this expert assessment, it would be difficult to decide which changes should be adopted, leading to costly delays or worse yet mistakes.

Consider automating the review process by implementing a set of criteria to auto-accept the request or forward it for further evaluation.

Step 3: Planning

A team of planners develops a comprehensive plan to ensure successful deployment of the requested changes. This plan will cover all the major steps — from training requirements to communication strategies — as well as resources and timelines that are essential for completing each task along the way. By having all these details prepared ahead of time, organizations can be sure that they have all the tools necessary to make their desired changes happen effectively and with minimal disruption.

Make sure that everyone is on the same page and provide teams with the resources they need to properly document the change plan.

Step 4: Approval

The Change Managers and Change Advisory Board review the plan and sign it off, giving the green light for the changes to proceed.

You can make the approval process more efficient through peer review. Utilize collaboration tools to avoid the isolation of any information or tasks.

Step 5: Code review

Where software changes are involved, code review ensures that any changes are both accurate and of high quality. This involves teams of developers examining source code, making sure it adheres to coding standards and assessing customer requirements to make sure the final product meets expectations.

With each developer evaluating and checking code written by another, this rigorous process helps to ensure a more secure result while also reducing delays that can come from releasing untested software into the production environment.

Step 6: Testing

All changes should be tested in a controlled environment before implementation in production. This allows for any potential issues to be identified and resolved before they cause problems in the live environment.

During testing, information about the change can be gathered that can't be discovered in other ways. Additionally, a controlled environment provides insights into how the change could interact with existing systems.

With successful testing, a potentially disruptive change can be implemented with confidence, enabling smoother operations in production environments.

Step 7: Deployment

The change team implements the changes in production, taking care to document their actions and results throughout. During deployment, teams must ensure that new services account for customer satisfaction and organizational efficiency concerns, create clear communication between all stakeholders, address any known issues before implementation, review resources and team capacities for effective execution, and develop ways to monitor success after implementation.

Maximize the automation of the deployment process whenever you can. For example, by using workflow automation, you can ensure that tasks are seamlessly handed off to the right teams or persons.

Step 8: Post-implementation review

A post-implementation review is conducted to assess the impact of the change and identify any areas that could be improved upon or even reversed.

This review also provides the organization with useful information on whether the changes they have made have had the desired impacts or if more adjustments need to be made.

The result of a post-implementation review sheds light on how beneficial the new changes are as well as how reliable and effective they are in achieving goals.

Step 9: Post-deployment testing

The goal of this step is to ensure all changes have been added, integrated and operationalized successfully. By running tests on the newly implemented changes, it becomes possible to determine if anything requires fine-tuning or if additional improvements can be made down the line.

Post-implementation testing allows for any issues with the new changes to be identified before the system or process goes live. It also ensures that everything is working in line with organizational expectations and goals.

Step10: Documentation

The lessons learned from the deployment are documented and used to improve future changes. This information is essential to continually refine the change management process, and mistakes can be avoided when the important key takeaways are factored into upcoming changes.

The act of systematic documentation provides a valuable record to research and identify any gaps or issues in current processes, assisting further enhancement of future change management operations.

Step 11: Change request ticket is closed

Once the post-implementation tests pass, the change ticket is closed and the process is declared complete. This step can often be overlooked as it isn't considered to be of any importance.

However, closing the request serves an important purpose in completing the full change management cycle and accurately recording information for future reference. It's only then that the entire process can be declared complete.

It’s important to note that the change management process is rapidly evolving from the traditional model which involved lengthy meetings with non-technical individuals.Today's change management has embraced automated methods and collaboration.

Change management controls

Implementing change management controls usually requires a blend of preventative and detective controls. It's essential to remember that these controls can only provide reasonable assurance that the desired control objectives are met — they typically don't guarantee it, since this would usually be too expensive.

Here are some common examples of change management controls:

• Using project management tools to help manage the process, keeping track of progress and providing an ongoing view of how the change request is coming along.
• Demanding that change requests must be authorized by both business owners and IT management
• Once a change is implemented, it needs to be tested and approved by users to confirm that it meets the necessary criteria before being deployed into production.
• The Change Advisory Board (CAB) must provide authorization for any modifications before they can be put into action in production; this ensures that all changes have been considered from a range of perspectives.
• Using a code repository tool is a great way to ensure that all changes are reviewed before being merged into the code base. Automated notifications can be set up so that when changes are successfully merged, everyone is alerted and no modifications go unnoticed.
• Developers are not allowed to make any changes to the production environment without proper supervision.
• Records of all changes that are made are periodically examined to make sure no unauthorized changes have been done.

Not every kind of control is a must-have for the change management process, since there isn't a «one size fits all» solution across all service organizations. Therefore, the controls should be tailored to suit each specific service organization's change management environment.

Service organizations should also take advantage of user entity controls. For example, when a client needs changes to be done to a tool that the service organization is responsible for, a user entity control would require the client to test, accept and approve the change prior to deploying it into their production environment. This type of control guarantees that the change functions correctly in the client's production environment and meets all of the system requirements and service commitments of the service organization.

Change management auditing

Audits for change management are performed to determine whether existing controls are successful in aiding the accomplishment of change management objectives. Are these controls instrumental in validating that alterations are correctly sanctioned and adhered to as per the change management guidelines?

The auditors need to refer to the service organization's change management policy to understand how changes are authorized before any work commences; review the change documentation process; make sure testing is always done before and after deployment; confirm that deployment in production is always approved; and check evidence that the changes are implemented by an approved individual.

Here are some of the key tests that auditors are likely to perform during change management auditing:

• Checking that the changes are only executed by qualified staff. This must be confirmed by management in addition to relevant certifications.
• Witnessing that the said controls are indeed implemented.
• Examining documentation to prove the controls are consistently applied.
• A practical walk through of the controls.

Testing a sample of changes can help to evaluate the effectiveness of the controls in place. If the auditors identify an issue, it's essential to assess its importance and evaluate it in relation to the other controls in order to ascertain its true influence on the change management objectives. Just because there are one or a few flaws does not necessarily mean the service organization won't be able to meet their objectives.

There are two types of deficiencies: design and operational. A design deficiency is when a control needed to meet an objective is absent or not designed properly, which means it won't meet the change management objective even if it works as intended. An operational deficiency happens when a control is designed correctly but implemented the wrong way, preventing it from meeting the desired change management goal. This will call for training of relevant personnel, more stringent review by management, or automating the controls.

Change management challenges

When dealing with change management, it’s important to be mindful of the potential challenges.

Here are some of the more frequent ones.

Change management best practices

Let's face it, not a lot of IT managers relish the change management process. We can think of it as an unavoidable chore. With this in mind, here are some top practices to make the change management procedure more appealing:

Conclusion

Change management makes it simple for service organizations to work through changes into the production environment, whether they are planned or unplanned, thus decreasing disruptions.

While at it, don’t forget about controls. It's essential that service organizations have independent auditors assess their change management controls. This audit provides management and stakeholders with feedback on the design and operational efficiency of the controls in place to meet the change management objectives set out in the change management policy.

A comprehensive audit can rapidly detect any gaps and offer a timely opportunity to address any deficiencies.