How to improve your IT support workflow
What is IT change management
Change management—also known as change enablement—is an IT practice designed to minimize disruptions to IT services while making changes to critical systems and services.
A change is adding, modifying, or removing anything that could have a direct or indirect effect on services.
Change management practices are designed to reduce incidents and meet regulatory standards. The practices ensure efficient and prompt handling of changes to IT infrastructure and code. Whether you’re rolling out new services, managing existing ones, or resolving problems in code, modern change management approaches break down silos, provide context and transparency, avoid bottlenecks, and minimize risk.
Risk management is a related ITIL 4 practice, followed “to ensure the organization understands and effectively handles risks.” Both change and risk management require tracking and linking changes to provide an auditable record. The ability to draw on data about previous changes and their success rates enables organizations to adapt their practices in a manner that smartly balances risk and speed.
Data-informed, adaptive practices strive for efficiency, in contrast with traditional change management, that can often be unnecessarily slow, process-heavy, and overburdened. Because change management deals with challenges around risk and compliance, auditability, and cross-team coordination it too often becomes complex, bureaucratic, and painful.
It doesn’t have to be this way though. Think of change management as “eat your vegetables”of ITSM -- not always appetizing, but critically important. With the right practices and culture, change management can result in fewer incidents, less stress on your teams, and more time spent delivering value to customers.
Defining change management
When some of us think of change management, our definition involves every aspect of change—from technology, people, and process to the impact on customers and systems. To provide clarity within the context of ITSM, ITIL 4 has drawn a distinction between IT change management and organizational change management practices.
- Organizational change management is the “practice of ensuring that changes in an organization are smoothly and successfully implemented and that lasting benefits are achieved by managing the human aspects of the changes.”
ITIL 4 then redefined their former change management process as the “change control” practice.
- The change control practice ensures “that risks are properly assessed, authorizing changes to proceed and managing a change schedule in order to maximize the number of successful service and product changes.”
This new name choice stoked controversy, with many IT teams rejecting the association with “control”. To some, it’s a toxic word that evokes the bureaucracy, bottlenecks, and unnecessary steps that traditional change management has become infamous for creating.
Axelos listened to the feedback and responded. “Following the release of ITIL 4 Foundation, we have heard from several people around the world that “the practice was being misinterpreted or misunderstood as focused on ‘controlling changes’ or ‘controlling teams’, rather than ‘controlling the rate of changes’”
ITIL ultimately switched to calling the practice “change enablement.” The new name connotes a practice that helps teams, providing them with the ability--and freedom-- to move changes forward.
At the end of the day, we don’t think the term you use is especially important. (In this article, and at Atlassian, we refer to it as change management.) What does matter is your approach. Start with healthy teams and the right culture, and your organization is on the right track to create an effective change management practice.
The relationship between change management and release management
Release management is another practice that’s important in the change management conversation. According to ITIL 4, the purpose of “release management…is to make new and changed services and features available for use.” Releases may include everything from changes in software functionality to documentation and training updates.
Historically, release management has bundled changes together, presenting them to customers as a package. Traditional release management upholds rigid project management standards and can create friction in shipping valuable updates to customers, leading to frustration among teams that adhere to Agile principles.
We can reimagine release management for the DevOps context. Shifting away from its traditional project management function, release management should become about integration and automation. It starts by bringing code pipelines into a secure system that incorporates automated review where possible and provides tracking and oversight. This can break down the siloed approaches of the past and provide a frictionless path to production. Release management could be all about making it easier than ever to continuously deliver value and applying the “you build it, you own it” principle.
Why is IT change management important?
Modern organizations have a couple of critical and competing expectations for their IT team. First, they expect stable, reliable services that ensure the organization is productive and able to meet end-user expectations. Second, the IT team needs to implement regular service updates to enable the organization to adapt to constantly changing security, cost, and business requirements.
Failure to do either can result in dire consequences. Inability to maintain reliable service can cause massive damage to productivity and costs. Many organizations report downtime costing more than $300,000 per hour, according to Gartner. For some web-based services, that number can be dramatically higher.
At the same time, organizations that aren’t adapting for the future will become unable to keep pace with the speed of business and fall behind their competition. Deploying changes too slowly could result in employees defecting to work in places with less clunky systems or your customers sending their support and dollars to other organizations that provide them more value.
So, how are you supposed to manage these conflicting needs? A change management practice enables your organization to ship updates while ensuring stability and mitigating risk. Change management helps accomplish change in the following ways:
- Establishing a framework to manage the change process
- Prioritizing necessary changes to properly allocate resources
- Incorporating relevant information for smarter decision making
- Involving necessary stakeholders from dev and IT for approvals
- Incorporating testing of changes, to avoid incidents
- Streamlining and improving the flow of changes to deliver value more quickly
Types of changes
ITIL defines three types of changes.
Standard changes
Standard changes are low-risk, commonly repeated, and pre-approved. They’re performed frequently and follow a documented, approved process.
For example, adding memory or storage is a standard change. Replacing a failing router with an identical working router is a standard change. Creating a new instance of a database is a standard change.
All of these changes are common and follow a well-defined process. And because, presumably, that process has already gone through change management’s risk assessment and approval process once, it doesn’t need to go through the process again every time a router needs replacing.
For many companies, standard changes are a prime opportunity for automation. Some companies report that as many as 70% of standard changes can be automated—freeing up their teams to focus on normal and emergency changes.
Normal changes
Normal changes are non-emergency changes that don’t have a defined, pre-approved process.
For example, upgrading to a new content management system is a normal change. Migrating to a new data center is a normal change. Performance improvements are normal changes. They’re not standard and repeatable. There are risks involved. But they’re also not emergencies. Which means they can go into the usual change management queue for risk assessment and approval.
Some normal changes—like a data center switch—are high-risk and may require risk assessment and approval from a change advisory board (CAB). Others—like a website change—may be low-risk and can be approved on a quicker timeline by a designated change authority or via automated checks and peer review.
Emergency changes
These changes arise from an unexpected error or threat and need to be addressed immediately—usually to restore service for customers or employees or secure systems against a threat.
For example, implementing a security patch is an emergency change. Dealing with a server outage is an emergency change. Resolving a major incident is an emergency change.
The urgency of emergency changes means they need to be handled on a much tighter timeline because the risk of a lengthy review process is higher than the risks involved with resolving the issue quickly.
How you categorize your changes depends on factors including your organization, processes, and risk tolerance. We advocate dropping the "one size fits all" approach, and treating each change differently based on risk assessment. As your organization learns more about previous incidents, particular systems, and incorporates other relevant data, it should be possible to designate a higher share of changes as standard and pre-approve them. Modern change management should make change requests as simple and streamlined as possible.
What is a change advisory board (CAB)?
In most traditional IT organizations, a change advisory board (CAB) is tasked with assessing the risks of and approving (or not approving) each change. Typically, the CAB holds regularly scheduled meetings to review all proposed upcoming changes, pulling in experts as needed to explain, defend, or assess the change with them.
On one hand, change advisory boards can help reduce risk and raise the alert when a change simply won’t work for the company. On the other hand, they can also create a bottleneck—especially when they’re made up of people who aren’t close to the changes being deployed. In many enterprises, the change advisory board (CAB) approval process is complex and time-consuming, which slows down the change process.
Many IT teams are moving away from traditional CAB meetings or restricting the scope to the most risky changes and important organizational concerns. In this paradigm, CABs can become trusted advisors responsible for monitoring trends, advising on how practices can address them, and coordinating between teams and their needs.
ITIL 4 also encourages decentralizing your change authority into the business stakeholder or peer level. Instead of using a separate committee, build change management into normal workflows with relevant stakeholders. To avoid bottleneck situations, look to automation, virtual checklists, and peer review as a nimbler and more collaborative alternative.
The change management process
For nimble, high-velocity teams, the change management process is shifting—away from lengthy reviews and non-technical stakeholder approvals and toward automated, collaborative processes between IT and development teams that increase agility while still balancing risk.
Here is a basic overview of a change management process, along with some recommendations to increase your speed to delivering value.
| Step | Best Practices |
| Change request - Someone requests a change and includes notes on possible risks, expected implementation, and affected systems. | Set up an intuitive self-service portal for stakeholders and IT staff to easily raise a standard change request. Assure that your development teams and IT teams can collaborate on the same platform for full context and transparency throughout the change request workflow. |
| Change request review - A change manager or peer reviewer reviews the initial change request. How likely is it to be successful? Are the risks and rewards accurate? Is it worth making? | Use automation to auto-approve the change or kick off a brief approval process before the change gets implemented. |
| Change plan - The team creates a game plan for the change. They document expected outcomes, resources, timeline, testing requirements, and ways to roll back the change if needed. | Align stakeholders quickly with a change management kick-off. Get teams on the same page with knowledge base templates to document your change plans. |
| Change approval -The appropriate change manager, peer reviewer, or CAB reviews the plan and approves the change. | Streamline approvals with peer reviews. Fight siloes, with shared work tracking and documentation, so people can easily and asynchronously collaborate. |
| Change implementation -The team ships the change, documenting procedures and results along the way. | Use automation to enable your processes and standards. Workflow automation can route and assign requests to the next authorized person based on your business rules. |
| Change closure - When appropriate, the change manager reviews and closes the change when appropriate. Their report should communicate whether the change was successful, timely, accurately estimated, within budget, etc. | Retain accessible knowledge base articles and tickets so teams can learn from previous work. Perhaps there are opportunities to automate similar change requests in the future. |
Change management best practices
As we mentioned before, change management brings about the same kind of dread some of us feel about eating leafy greens. We don’t always look forward to the dish, but know just how important it is. And, we can take steps to make both things more appealing.
Here are some best practices for modern change management:
- Understand your organization’s risk tolerance and regulatory obligations
- Simplify and automate change management processes wherever possible
- Give CABs a more strategic focus
- Embrace practices that make standard change the new normal change
- Look to various frameworks like ITIL and DevOps to find guidelines that work best for your organization
- Prioritize collaboration
- Use chaos engineering to reduce your risk
- Streamline change request intake for IT and developer teams
- Unlock learning with change metrics and KPIs
- Embrace a DevOps-driven approach to release management
Rising to the challenges of change management
Developers want to roll out code quickly and without expending additional time and effort on manual documentation. IT operations teams seek to reduce risk, maintain detailed records for audits, and avoid incidents. Asking developers to add an extra step to their processes, write things down, clock in and clock out, can feel like it’s keeping them from the ultimate goals of their jobs. Asking the ops team to overhaul existing processes, lifting approval checks, and leaving more to automation is not easy and can feel like it’s creating more risk.
Meanwhile, the stakes are higher than ever. The rise of software-powered services has raised customer expectations and demand for always-on, high-performing services. In an increasingly dynamic environment, the work needed to manage services keeps growing.
So, how can we overcome these challenges? Well, it begins with dispelling the myth that heavy process reduces risks. Then embracing a culture, corresponding practices, and tools that help teams collaborate and ship. And finally, continuously incorporating information to demonstrate the value of the previous steps and continue striving for improvement.
Want to see how Jira Service Management can transform your change management process?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Read the whitepaperKnowledge base: your solution for improved collaboration
Discover the power of a knowledge base for your business. Boost productivity, enhance customer service, and streamline information management effectively.
Read the article