Change Management? Yea Nah!
This article is for an overview of change management that is not people change management. The change management conversation is about implementing technical product or code changes from a tech environment into a production environment.
We included this in the conversation only for those new to the conversation to understand and improve their awareness. When search for information about change management, these types of articles will appear.
The content has been republished from an article written in Atlassian. - Read the original article on Atlassian - Link here
Technical Change Management
The core goal of any change management practice is reducing incidents as you ship updates that make customers happy and keep you ahead of the competition. And the practice is consequential. Today, customers have heightened expectations for always-on, high performing services. In an increasingly dynamic environment, it is critical to carefully manage services and ship frequent improvements. Modern teams have embraced practices that enable risk mitigation while delivering value to customers in the most streamlined, agile manner possible.
To achieve these goals, organizations have designated a variety of roles and responsibilities associated with change management. In a large enterprise, these can be shared across a variety of job descriptions and teams.
In smaller organizations, one person may take on change management responsibilities along with other elements of their job. Someone with change management responsibilities may also be a developer or team lead. In other cases, processes may be slowly built into and shared among existing teams.
There is no one right model for assigning change management responsibilities. Organizations need to come up with the setup that best suits their needs. That said, all teams can benefit from rethinking an approach that delegates change responsibilities to those with specific titles who are often distant from the very projects they review.
By embracing new opportunities to automate and streamline the practice into existing workflows, we can allow those involved in change management to assume more strategic roles, and return time for teams to focus on their most important priorities.
Common Change Management Roles
The roles involved in change management depend on numerous factors, including the size and type of IT organization. Here are some of the most common positions.
Change Manager/coordinator
Change managers—sometimes also known as change coordinators—are typically responsible for managing all aspects of IT changes. They prioritize change requests, assess their impact, and accept or reject changes. They also document change management processes and change plans. Importantly, they prep for, organize, and act as chair of CAB meetings. A change manager’s success is typically assessed by whether they meet timing and budget objectives.
Change Authorities/Approvers
A change authority is a person who makes the decision on whether or not to authorize a change. Sometimes this is a single person, such as a manager or executive. Sometimes it’s a group of people on a change advisory board. Sometimes it’s a peer reviewer. According to ITIL 4, “In high-velocity organizations, it is common practice to decentralize change approval, making the peer review a top predictor of high performance.”
Change managers typically work closely with the change authority to approve changes and move them forward within an organization. In some cases, particularly in small organizations, the change manager is the change authority and has the power to make these decisions without looping in additional people or teams.
Business Stakeholders
Business stakeholders are often involved in change management and may be looped into the authorization process. This is increasingly common, given the critical importance of software services to most enterprises. For example, if a change impacts the connection between the finance team’s payment tracking software and the sales team’s CRM, stakeholders from the finance and sales teams may need to be involved in CAB meetings and the ultimate decisions made about a change.
Engineers/Developers
Development teams typically submit changes for approval and document the case for its necessity. Once a change is approved, in companies that have taken on a you-built-it-you-run-it approach, these teams deploy the change, monitor it, and often respond to any incidents or problems related to the change. In other cases, the incident management team responsible for any incidents caused by the change may be separate from the developers implementing the change.
Service Desk Agents
Service desk agents can bring a unique, front-line perspective on incidents and common service issues that a change may cause.
Ops Managers
Since they’re responsible for keeping systems running on a day-to-day basis, operations managers weigh in on risk and dependencies.
Customer Relationship Managers
To represent the voice of the customer, relationship managers can provide knowledge about customer mindsets, frustrations, and ever-changing needs.
Information Security Officers and Network Engineers
Network security and cloud infrastructure experts bring important insight about threats and vulnerabilities.
Stop treating change requests in a “one size fits all” way
Every change request is an opportunity to track and gather information. We can learn about success rates, related incidents, and the factors correlated with them. Over time, with the application of data, it should be possible to pre-approve and automate more and more changes. Only the most consequential and risky changes should require in-person approval.
Bring change and release management closer together
The legacy approach to releases was to bundle them together and launch them all at once. CABs are then left to painstakingly review and approve huge packages of changes. This approach can lend itself to major incidents and makes it harder to find the source of a problem when one arises. It also slows the rate by which teams can deliver value to their customers. This also means that change and release managers can allocate less time to project management tasks.
Use progressive releases to test and iterate
Progressive deploys canary or feature flag with a small subset of users to test and prove stability before the full deployment. This limits the scope of a potential incident and proves the success of a deploy before rolling it out to all environments.
Use automation and tools to streamline change management
High-velocity teams are starting to rethink previous approval models. Rather than addressing a long change request backlog in a weekly in-person meeting, it’s possible to make use of virtual collaboration. That can be as simple as an email detailing change requests so they can be reviewed in advance of a CAB meeting. In other cases, things like Jira tickets and Confluence pages can enable change reviewers the context they need to asynchronously collaborate and approve changes. Using Jira Service Management, teams can collaborate in these ways, to even hop on a video conference or create a designated Slack channel. Depending on how your team prefers to stay in touch, it’s still housed in the same place so everyone is on the same page.
Legacy ITSM tools make it difficult for infrastructure, operations, and development teams to raise a change request. Look to automation and modern software to reduce the burden of manually inputting change information. The last thing a developer wants to do is fill out tickets in a clunky, separate system, if that work could be automatically tracked. Within Jira Service Management, teams can harness automatic to streamline change process, minimize risk, and cut back on downtime.
Shift left and bring change management closer to practitioners
One of the most common strategies that’s often replacing or reducing CAB approvals is peer review, which puts the responsibility for identifying issues in the code on those who understand the code best. ITIL 4 points out that in “high-velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance.” Similarly, The 2019 State of DevOps report recommended that “organizations should “shift left” to peer review-based approval during the development process.”
To keep compliant with regulations, this approach needs to be meticulously documented, which is where systems like Bitbucket come in, automatically tracking authors and peer reviews and keeping changes from being pushed live without the required process.
At Atlassian, peer review is a core part of our approvals process. As one of our IT risk and compliance experts explains: “All Atlassian code is stored in Bitbucket. When a developer wants to make a change, they check the code out of Bitbucket and onto their laptop. When they check it back into the Bitbucket repository, instead of updating the code, the system is set up to require peer review. Only after that review is done and approved is the code pulled back into the repository. And if the code isn’t approved? It gets sent back to the original developer with the peer reviewer’s notes. They fix what’s wrong and submit it for another peer review.”
Convene experts to enable good practices
As organizations become more complex, facilitating information flow and coordination among teams is increasingly critical. Rather than approving individual change requests, CABs can move their focus to practice improvement. In this paradigm, they can look to provide practice improvement recommendations, implement better capabilities, and provide resources and tools that result in better performance. This extends the purview of the CAB to address the risk of being too slow to ship value to the market.
Even in more traditional IT organizations, the CAB can become a place for coming up with creative solutions. In one case, a risk-averse university adhering to legacy ITSM tools and practices needed to figure out how to inform students about an important service that would be unavailable. The CAB became a forum for brainstorming new communications tactics. They settled on scattering candy and posters, in a campaign that was effective in deflecting incoming requests about a planned system upgrade.
Assigning responsibilities in your organization’s change management practice
When it comes to defining roles and responsibilities in your change management practice, start with understanding that there is no one-size-fits-all answer. You’ll need to factor in your company’s culture, team structures, available skills, regulatory requirements, etc.
To get true buy-in for whatever roles and responsibilities your business requires, we recommend running our roles and responsibilities play - which involves bringing everyone together to understand each member’s contribution to the team and what everyone needs to be successful.
To hone in your roles and responsibilities in the context of change management, we recommend starting by bringing your team together and discussing the questions below.
- What do various frameworks mean to our team? DevOps, CI/CD, ITIL, etc.
- Have we embraced frameworks holistically? Is our understanding limited to tactical things like automation?
- How do these frameworks, particularly DevOps and ITIL, impact our change and release practices and how are they working together?
- What is our current change process?
- Who is involved?
- Where can we improve?
- What can we do to shift more normal changes to standard or pre-approved?
- What were the most common changes?
- Which changes are “standard changes”?
- What services do they impact?
- Which changes were successful?
Change management is an important practice - and it isn’t going away anytime soon. Regardless of the state of your change management practices, there is always room to improve, whether that’s getting started by tracking changes or implementing risk assessment and automation systems. Discover how Jira Service Management's change management capabilities can empower your IT operations teams.
