ITSM for high-velocity teams
How teams share change management roles and responsibilities
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 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 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.
The transforming role of CABs (change advisory boards)
Change advisory boards have historically played a crucial role in assessing the risks associated with change requests and approving or rejecting them. Traditional CABs often acted as gatekeepers controlling the release of proposed changes.
However, they have been criticized for poor time management skills, lengthy change request backlogs, and their detachment from the actual work. Fortunately, CABs are evolving to become more strategic advisors, transforming their role in the change management process.
The challenge of CABs
The cliches around bad meetings also apply to CABs. We fairly criticize them as time wasters, for not accomplishing enough, involving too many random people, and existing when they “could have been an email instead.” This is partially owing to the way that traditional CABs have been overburdened with responsibility.
Let’s look to an aviation metaphor to illustrate the challenge. We can imagine the CAB as a control tower at an airport. That control tower has one job -- tell the planes when they are clear to land. It would never be tasked with assessing whether the planes are structurally safe or whether the pilot has the right credentials, because those factors are already confirmed by the FAA and others.
Meanwhile, far too many CABs assemble a variety of stakeholders and are tasked with making broad safety decisions about all kinds of different changes. And, this often occurs at the end of the week, as fatigued people become eager to leave for their weekends. The CAB is simply not set up to succeed.
Moreover, CABs often are concerned primarily with the risk of changes causing incidents. This is of course important, but they also must weigh the risk of delaying valuable changes. Moving too slowly can hurt customers, and in an ultra-competitive software as a service world, sink an organization.
It’s possible to elevate and focus the role of the CAB. With the right practices in place, many changes could be automated. This way, the CAB can become an important advisor, tracking trends, and partnering with teams on ways to enable faster changes that benefit customers.
How to position your CAB as a strategic advisor
The first step in repositioning the CAB is dispelling the notion that heavyweight change management produces positive outcomes. Data from the State of DevOps Report 2019 found that processes that require the approval of a CAB had a negative impact on software delivery performance and respondents following these processes were 2.6 times more likely to be low performers. Moreover, there was no evidence to support that a formal approval process was associated with lower change fail rates!
For this reason, modern teams are taking these steps to improve their CABs.
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.
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 Management Explained | Atlassian
Knowledge management processes create, curate, share, use, and manage knowledge across an organization and even across industries. Learn more here.
Read the articleDon’t stop deploying: Practicing change management in uncertain times
Some companies are reverting to heavy-weight change management processes. Here’s guidance on how you can avoid adding controls and even improve your practice.