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

Change management auditing is conducted to find out if the current controls are effective in helping to achieve the change management goals. Do the controls help ensure that changes are properly authorized and followed according to the change management policy?

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.

ChallengeDetails

Disruption

There is a risk of disruption as changes can cause instances of downtime, resulting in failed services and lost productivity.

Incompatibility

Incompatibility between the existing system and the new changes may adversely affect users' experience.

Costs

The process may be unnecessarily resource-intensive or costly if not properly planned and tested ahead of time.

Troubleshooting

Inadequate documentation may result in difficulties when trying to troubleshoot issues or make future changes


Security

Some alterations might create unanticipated opportunities for malicious actors to gain access to sensitive information or interfere with operations. It is essential for organizations to ensure they have appropriate safeguards in place, such as actively monitoring modification processes and user authentication protocols.

Scoping

An incomplete understanding of the scope or scope creep can lead to unexpected problems due to missed implementation steps or unforeseen dependencies on other systems.

Unauthorized changes

An unauthorized change can have a catastrophic effect as it goes against guidelines and expectations, making the system totally unreliable.

Unpatched vulnerabilities

If left unchecked, imperfections in the system can turn into attack vectors that can be exploited, bringing security breaches and various other problems to the fore. It's essential to pay close attention to any weaknesses they know of and make sure they are taken care of before launching any changes into a system.

Unintended consequences

Changes can result in unintended consequences that may not become apparent until much later — which is why thorough testing should take place beforehand.

Missed issues

Tests may routinely be unable to detect issues prior to deployment. So even when all other measures have been taken there's still a chance something could slip through the cracks; this is why it's important to have multiple layers of protection in place.

Poor allocation of responsibilities

Any areas where responsibility is unclear or neglected could prove fatal for the entire change. This can complicate accountability and traceability in case something does go wrong during a change cycle.

Poor separation between production and non-production environment

A lack of separation between non-production and production environments can lead to unintentional performance degradation or downtime as untested code could be pushed into production and cause havoc.

Incorrectly approved emergency changes

Emergency changes are often rushed through due to their critical nature, leading to poor quality code entering production without the proper approval or follow-up procedures in place.

Undetected unauthorized changes

Unauthorized changes can occur either intentionally or accidentally, but they introduce a major security risk if they go unnoticed. Having multiple layers of compliance and review procedures can help minimize this type of risk.

Unlogged changes

Not only does this provide little traceability should there be a need for it, but it also paints a false image of activity on an infrastructure level which might lead stakeholders to make decisions based on incorrect information.

Poor version control

Failure to properly maintain version control when making updates and releasing new assets might cause serious issues if overlooked; understanding code dependencies and sequence through proper version tracking allows teams to efficiently manage their releases.

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:

Best PracticeAdoption

Roles

Establish clear roles and responsibilities for managers, affected employees and user entities.

Communication

Develop a communication plan to manage stakeholder expectations.

Feedback

Create middle-manager feedback loops to ensure buy-in from direct line managers.

Analytics

Use data-driven analytics to establish program scope, metrics, and timelines.

Risk management

Analyze risks and prepare alternate plans for dealing with unexpected outcomes. Always understand your organization’s risk tolerance and regulatory obligations. Consider using chaos engineering to reduce risks.

Training

Provide training opportunities for impacted personnel and stakeholders.

Release management

Use DevOps approaches for effective release management

Automation

Automate as many aspects of the change management process as it's possible.

Change Advisory Board

Use CABs more strategically than technically.

Resources

Make use of diverse frameworks like ITIL and DevOps for guidelines that would be best suited for your organization.

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.

Change management FAQ

What is the importance of change management?

Change management helps to drive change by setting up a framework to manage transitions, prioritizing the required changes to utilize resources efficiently, incorporating essential data for informed choices, involving necessary stakeholders from both dev and IT teams for approvals, testing the changes to avoid any potential issues, and optimizing the flow of changes to provide value.

What is a change management advisory board?

A change advisory board (CAB) is the team that's in charge of determining the risks and deciding whether or not to give the green light for each proposed change. In the traditional set up, CABs typically have regular meetings to go over all changes and bring in experts if any extra analysis is needed.

Today, though, many organizations are shifting away from traditional CABs and focusing more on agile approvals. For example, instead of setting up committees, change management can be integrated into everyday operations with relevant parties taking part. Automation and virtual checklists can take the place of CAB sessions and offer more agility.

Is change management the same as change control?

No. Change control is the framework for assessing the proposed changes against control objectives, while change management is the process of managing and tracking the changes. Change management involves the entire methodical process including managing and tracking the changes, all the way from when the change request is issued to when the ticket is closed.

1
No comments yet. Be the first to add a comment!
Our site uses cookies
';