Close

10 change management best practices

Change management has a reputation for being process-heavy, clunky, and difficult. But the truth is that it doesn’t have to be. When run well, IT change management reduces incidents while also keeping processes agile and minimizing work disruptions.

So, how should we run change management? These ten best practices are a good start:

1. Understand your organization’s risk tolerance—and plan accordingly

When it comes to balancing risk and speed, in change management there is no one-size-fits-all solution. Every organization has its own culture, risk tolerance, and regulatory requirements to deal with, and each should incorporate these considerations into their change management practices.

Part of understanding risk is understanding your business’ regulatory and compliance obligations. When regulation enters the picture, it’s no longer a question of how much downtime your system can risk before losing business or what resources will cost if you have to fix a problem. Now, it’s a non-negotiable set of rules. You will have certain approvals required. You will segregate duties. Regulations like SOX and GDPR make certain activities non-negotiable, even if they slow the process a little.

The good news is that this planning doesn’t have to be static. Companies that choose a conservative approach with more approvals and rigid workflows can always reevaluate over time, adjusting the level of rigor in their processes in balance with the level of risk.

2. Use data-driven risk assessment to continually adapt your change management practice

Tracking metrics, especially links between changes and incidents is an important foundation in improving your change practices. Data will highlight trends, revealing the types of changes, team members, and services that are least likely to be involved in an incident. That information can help you match rigor to risk for different change requests. 

Smart risk assessment means more change requests can often be downgraded to less rigorous approval workflows. As Gartner’s adaptive change management process suggests, organizations can strive for more and more normal changes to be classified as standard, then pre-approved and automated.

Below, we’ve compiled some practical steps for making standard changes the new normal. 

  1. Review your changes in the past few months
    • What were the most common changes?
    • Which changes are “standard changes”? 
    • What services do they impact?
    • Which changes were successful?
    • What was the average time to implement these changes?
    • Which changes were requested by development teams? 
  2. Select three to five standard changes as candidates to automate
  3. Build out self-service request types for the standard changes in your service management software
    • Add text to clarify the purpose and scope of the standard change request
    • Capture important fields, such as the system, application, or service that’s being changed
    • Create automation rules to auto-approve the change, transition statuses, and notify staff with updates
  4. Take time to educate and train your IT staff and development teams on this new capability 
  5. Monitor performance over the next few months 
    • Gain insights to improve your existing offerings
    • Identify additional standard changes to automate 

3. Make change management as simple as possible

Nobody wants extra work. And it’s why change management is often considered a nuisance. Change management practices often ask people to document something, often in a tool they don’t like working in, and wait for a process with an additional step or two. And for developers tasked with pushing code live, those additional tasks can feel like they’re getting in the way of the real work.

The answer to this major challenge is making change management processes as simple as possible. Keep approvals to a minimum where you can. Choose tech tools that integrate seamlessly so that developers don’t have to enter the same information into multiple systems. And automate wherever possible. 

The simpler you can make the process, the easier it will be to get—and keep—teams on board.

4. Rethink the traditional CAB model

In most traditional IT organizations, a change advisory board (CAB) is tasked with assessing the technical and business implications of change requests. The traditional process creates some challenges - slow releases, clunky processes, and sometimes a lack of communication and collaboration. Which is why top-performing teams are re-thinking the CAB model.

The goal is to keep the value these boards add to our IT processes - enabling communications and balancing the need for changes with the risks of those changes - while making the typical CAB process more nimble and strategic. This typically means:

  • Only asking for CAB approval on the riskiest changes (and using proven tools like peer review, virtual checklists, and automation to manage less risky changes)
     
  • Tasking CABs with strategy and helping teams develop practices  that reduce risk and reduce the workload of change management through process efficiencies and automation
     
  • Making CABs virtual and real-time instead of waiting for in-person meetings to address major changes or process questions

The key here is a shift toward strategy. Instead of acting as gatekeepers, the new CAB is there to enable change. Instead of becoming a bottleneck, the new CAB is a strategic resource. Code review and getting into the technical weeds is reserved for peer reviews and people who are best suited to catching errors in the code and the CAB is freed up to focus on process, strategy, and supporting continuous delivery.

5. Use tools to automate and hone your processes

Automation within your tools is one of the best ways to minimize the burden of change management processes on your teams. Simple checks and balances within our tools can keep us compliant and significantly reduce risk without requiring individuals to devote unnecessary time to new processes. 

As Atlassian’s Risk Futurist, Guy Herbert, explained in a recent piece on compliance and risk: “The truth is that most of us don’t really need a six-layer approval process and months of back-and-forth with compliance approval boards…What we really need is some simple checks and balances that ensure non-compliant changes don’t make it past the door. And much of that can be done by our tools themselves. Bitbucket, for example, won’t let our developers push code they’ve been working on back into the database until it’s been peer-reviewed by another appropriate developer. Bamboo won’t launch new code that hasn’t been through our compliance processes in BitBucket.”  

6. Deploy smaller releases, progressively to ensure your changes go well

The legacy approach to releases was to bundle them together and launch them all at once. What most of us know now is that this approach lends itself to major incidents and makes it harder to find the source of a problem when one arises. Smaller, more frequent releases can limit the scope of a potential incident. Progressive deploys canary or feature flag with a small subset of users to test and prove stability before the full deployment.

7. Treat ITIL as guidelines, not hard-and-fast rules

ITIL sometimes gets a bad rap. It’s seen as restrictive and outdated. But the truth is ITIL has a lot to offer to IT teams—including those who’ve embraced a DevOps culture. And the problem here isn’t that ITIL is too rigid. It’s how we’re approaching its guidelines.

Approach ITIL as a series of hard-and-fast rules and of course it’ll feel restrictive. Approach it as a set of foundational guidelines your company can build on and it’ll feel like a leg up as you develop your change management practice.

This applies to every framework and cultural approach. ITIL, lean, DevOps, Agile, CD...no framework, however beloved, is going to solve all your problems in one fell swoop. Too often, we look to a framework or tool to solve internal problems when we should be looking at team culture.

8. Prioritize collaboration

From CABs to DevOps groups, leading teams are embracing collaboration, openness, and real-time updates. Change management exists to coordinate across teams. Changes, incidents, and problems have ripple effects across more than one team—a fact that becomes more evident the more complex your organization gets. 

Good change management simply can’t happen in silos. Organizations that work to encourage more open collaboration are likely to improve their change practice.

9. Take advantage of chaos and resilience engineering

Chaos engineering is a recent practice focused on testing resilience by breaking or shutting off components of a product or service. Similarly, resilience engineering deliberately addresses all possible stressors on a system—pushing the system with high user counts or high traffic, for example. 

Both practices are there to identify problems and the changes that need to happen to avoid future incidents. This preemptive approach is bringing a lot of value to the table for change management teams and saving incident management teams significantly in time, budget, and alert fatigue.

10. Choose tools that are familiar to and embraced by your development teams

Good change management processes should be built into and across the tools your developers use. Asking teams to learn a new tool, enter info into multiple tools, or deal with a tool that’s unfamiliar and uncomfortable tends to slow down adoption, which will hurt your ability to deliver valuable updates to customers. 

At Atlassian, we track changes using Jira Service Desk. The Jira platform makes it easy to bring dev and ops teams together, providing transparency and traceable context from before developers even start coding all the way through to when changes are deployed to production.