Confessions of a Change Manager

By Donna Knapp 

At one point in my career, I was a change manager. I ran my company’s change advisory board (CAB), and I spent endless hours trying to convince project managers to submit requests for change (RFCs). Despite my best efforts, I invariably had to explain, fairly often, that ‘poor planning on your part does not constitute an emergency change on mine.’

At that time, the change manager role was one of the many hats that I wore. My ‘real’ job was service desk manager. We called it a ‘hotline’ then and so yes… it was many, many years ago. In that role, I and my team saw the impact of poorly executed and failed changes. We dealt every Monday morning with the chaos that came out of the massive changes made over the weekend.

That was then. Since then, much has changed. But it was through that lens that, more than 10 years ago, I first started researching a movement in the IT industry called DevOps. At the time, it was early days for DevOps and individuals and organizations were still grappling with how to define what the movement was all about. What its principles and practices were. That research eventually produced the DevOps Institute’s DevOps Foundation certification course which continues to provide a great introduction to the capabilities needed for DevOps success.

Viewed through my skeptical change manager lens this movement seemed, to be honest, a bit crazy. Frequent software changes. Few approvals. Crazy! It wasn’t until I understood the influence that Agile and Lean practices were having on this movement that the revelations began. It made sense to me that decreasing the size of changes could help minimize risk and make it easier to troubleshoot incidents when something went wrong. My transformative ‘aha!’ moment came when I finally wrapped my head around all the technical practices being introduced as part of this movement. I realized that practices such as continuous integration, continuous delivery, continuous testing, and dark launches all support (vs. circumvent) the aims of change management.

In my 30+ years as a service management professional, I have concluded that the what and why of service management doesn’t change over time… it’s the how that must evolve. It’s a notion that can be applied to any ITSM practice, as we do in our ITSM for DevOps course.

In the case of change management, now change enablement in ITIL 4, a fundamental premise is to balance effectiveness, throughput, compliance, and risk control for all changes within the defined scope of the practice.

• Effectiveness speaks to the fact that changes should enable the desired outcomes or results
  
• Throughput represents the number and speed of changes being made
• Compliance relates to meeting governance requirements and adhering to legal and regulatory controls
• Risk control ensures that risks are well understood and managed

Hindsight, as they say, is always 20/20. What I’ve also realized through the years is that when you place too much emphasis on any one aspect of anything, it’s unlikely you’ll get the desired result. In the case of how we have historically managed changes, organizations have often (and in some cases still do) placed too much emphasis on managing risk. For some organizations, it’s systemic. The culture of the organization is risk-averse so negative risks are overestimated and positive risks are underestimated. It’s important to keep in mind, however, that being risk-aware is not the same as being risk-averse, and that risks can be mitigated in ways that don’t slow things down.

Some organizations also believe that they can inspect quality in. A notion that W. Edwards Deming discouraged close to 30 years ago and that was disproved in the 2014 State of DevOps report. This report found that external change approval boards had a big negative impact on throughput and a negligible impact on stability. What did, however, have a positive impact on performance was when the technical team held itself accountable for the quality of its code through peer review.

“Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.” W. Edwards Deming

It’s why organizations today, if they haven’t already, should consider abandoning the notion of weekly CAB meetings. I get it. Back in the day we had monolithic applications, typically being changed via massive waterfall projects. We didn’t have robust CMDBs that we could use to conduct risk and impact assessments and assist with scheduling activities. Our only choice was to bring together a group of subject matter experts (SMEs) to perform those activities. A ‘biological CMDB’ so to speak. But again, that was then. Today, we can automate these assessments and we can use DevOps and AIOps practices to identify conflicting changes and to predict and prevent failed changes.

This doesn’t mean there won’t be times when it makes sense to pull together a temporary team to assess, authorize, and oversee a particularly complex change. If you are moving a data center from one building to another, or you are transitioning a legacy application to the cloud, a meeting or two to ensure the change goes smoothly makes sense.

Day-to-day, simple improvements such as increasing the number of standard changes, delegating the

authority to approve changes to as close to the work as possible, using change models that require ‘just enough’ control, and automating the flow of changes can go a long way towards minimizing bureaucracy.

Today, a change enablement practice that combines a healthy blend of principles-based thinking with modern technological ways of working will allow organizations to find that sweet spot where speed and quality and stability meet.

The change manager (or owner) plays an essential role here in terms of driving continuous improvement and discouraging a one-size-fits-all approach. This is achieved by combining an open mind with a commitment to continuous learning and improvement. Learning not only about the change enablement practice itself but also about the technological advances and changes in ways of working that are impacting or could be impacting the practice in your organization.

It’s okay to view these new technologies and ways of working with a dose of skepticism. Just keep asking questions. Find SMEs who are willing to engage in meaningful discussions and healthy debates. Find and learn from practitioners who are constantly innovating such as Mike Weaver, who we chatted with about the Bullet Train process his organization has introduced to accelerate the change enablement practice. Learn how to formulate and conduct experiments to determine what works (and doesn’t work) for your organization.

The what and why of change enablement hasn’t changed over time… maximizing the number of successful changes by ensuring they enable the desired outcomes and meet the organization’s requirements regarding change throughput and risk management. It’s the how that must evolve.

Just as we all need to evolve. I admit there is a part of me that cringes when I think back to the change manager that I was. I take comfort in the words of author Alain de Botton who once said, “Anyone who isn't embarrassed of who they were last year probably isn't learning enough.”

The reality of the world we live in is that technology and ways of working continuously influence and shape each other in an ongoing cycle of innovation and adaptation. These changes are impacting and will continue to impact all of the ITSM practices. How do we as practice managers survive and thrive?

Just keep learning!

Additional reading to consider about this topic:

ITIL 4 Change Enablement: Streamlining Your IT Service Management

Incident, Problem and Change Management Integration 

Related training opportunities from ITSM Academy:

Certified Process Design Engineer (CPDE): Provides clear, step-by-step methods and techniques for designing, reengineering and improving processes.

Certified Agile Service Manager (CASM): Introduces Agile Service Management and how to apply agile thinking to service management processes and process design projects.

ITIL 4 Foundation: Provides an overview of ITIL 4 practices, including Change Enablement, and introduces the fundamental concepts and principles of the ITIL framework.

ITIL 4 Practitioner: Change Enablement: Single-day Practice Manager Course, part of the Plan, Implement & Control bundle.

ITIL 4 Specialist: Create, Deliver and Support (CDS): Delves into the practical and technical aspects of ITSM, including Change Enablement, focusing on the creation and delivery of services.

ITIL 4 Strategist: Direct, Plan and Improve (DPI): Focuses on the practical skills needed to create a 'learning and improving' IT organization, with Organizational Change Management being a key component of continual improvement and strategic planning.

About ITSM Academy

ITSM Academy is a female-owned small business, started in 2004. Our comprehensive training programs, expert-led courses, and industry certifications are designed to elevate your career and enhance your organization's performance. If you are looking for training for yourself, a small team, or a large group - we have options for you. In our classrooms... or yours.