Top 10 change management best practices

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.

Using Jira Service Management, approvals and workflows can be customized to an organization's specifications. Make processes as flexible or automatic as desired. Perhaps, automate more low-risk processes and safeguard more intricate processes with approvals.

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 change management, 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 

After evaluating your team’s previous change management practices and assessing the change risk, it can be helpful to compile the risk assessment documentation in one place. With Jira Service Management’s Confluence integration, teams can refer to one source of truth housed in a change plan document. On this page, collaborators can add a change plan template in addition to risk assessment information.

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. This is where a central point of truth, like a change plan Confluence page, can make documentation easy by involving the whole team.

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. These features within Jira Service Management give teams the flexibility to operate at their own pace, their own way.

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

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.

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.

Organizing smaller, controlled releases is easier when teams can coordinate these releases on a change schedule. This helps developers avoid areas of conflict or identify blackout dates. Jira Service Management change management features allow teams access to a centralized schedule with the information they need to execute these fragmented releases.

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.

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.

Everything about Jira Service Management is geared toward unifying teams to accomplish goals faster — in this case, enact changes faster, without incident. The mechanism of cohesive, high-velocity teams is collaboration. A transparent platform equipped with tools like Confluence, integrated chat and video conferencing, and customizable workflows allows everyone to jump in and do their part, their way, with full context.

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.

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