Methods of Change Management: Making It Work in Your Organization

Let’s start out by putting change management into perspective. While there’s much to learn from the “Unicorn” companies—those that make the headlines in trade publications, and those thought leaders who write the books we all love to read—in so many organizations around the world, there’s a context in which IT changes are made that can’t be ignored or willed away.

It’s working within that context that we shift to in this article on the methods of change management, which is the second article of a multi-part series on change management. If you haven’t read the first article, The Goals of Change Management, you may want to read it first.

It’s More than Application Development

While modern, digital organizations are often anchored in the company’s flagship applications—the core application(s) that IS the product the company sells. These applications are the very lifeblood of such organizations. The ability to rapidly respond to opportunities to meet needs, add business value, and address issues damaging customer experience can make the difference between the organization’s success and failure.

These applications are the perfect opportunity to maximize speed and agility in delivery. But IT is involved with much more than flagship applications.

Many, perhaps most, IT shops have not migrated everything to the cloud. In some cases, there are literally servers running under desks and in broom closets that host mission critical applications. For valid business reasons, including governance, prioritization, and funding, many organizations are in a hybrid state-of-flux between legacy applications, traditional on-premises data center, and cloud solutions.

With the growing popularity of subscription-based Software as a Service (SaaS), legacy systems are migrating to cloud versions for managing HR, finance, workflow, and a great many other solutions. The number and nature of SaaS solutions and the growing demand for effective integration and data interfacing of these systems has its own unique set of change management challenges.

Client computing platforms (desktops, laptops, mobile) are quickly moving to “evergreen,” auto-update adding new change management complexities.

IT is expected to manage conference room audio and video systems, in-classroom education technology, factory and warehouse management technology, omnichannel retail systems, security and surveillance systems that now include facial recognition using artificial intelligence and automation for private, government, and military. The vast diversity of needs and challenges for which organizations employ information technology is enormous, and modern IT shops must expertly manage change outcomes for all of these vast and varied systems.

Add to that a sharp increase in the focus on governance, risk, and compliance, including information security that’s often articulated in terms of operational controls, many of which apply directly to how IT changes are managed.

With this reality, then, it’s clear that whatever we do to manage changes, it must be adaptive enough for all types of IT changes—not just applications or infrastructure. What’s also clear is a changes process through which all changes must flow is simply out of the question.

Whatever we do to manage changes, it must be adaptive enough for all types of IT changes—not just applications or infrastructure.

For some changes, a traditional review might be the best format for managing changes. But there’s a great many changes for which it is not only problematic, but, owing to the highly automated delivery pipeline, it’s literally not possible.

In IT Change Management: A Practitioner’s Guide, I said: “As change management matures, it becomes increasingly focused on the end-to-end process, and less on the individual changes.” More recently, at DevOps Enterprise Summit, Jez Humble said “We think change management should meet a governance role—how we can make a more effective process…not inspecting individual changes, which is a terrible idea.”

The important point here is that it’s much more than mere semantics. The difference between inspecting each-and-every change (as is common in the traditional CAB-based change process) and ensuring change outcome expectations are being met in the pipeline is massive.

Outputs and Outcomes

As you know, outputs and outcomes are two very different results. We all know from Process 101 that a process is composed of:

• Inputs: What’s causing this to happen
• Activity: What needs to be done in order to accomplish an output
• Output(s): The result of the activity

In a traditional sense, the need for a change is raised (input) that triggers the change management process. Certain activities are carried out to complete the work that produces the eventual output of the change management process—the approved, implemented change.

This is all well and good, with a few notable challenges:

• It’s a linear approach with a start and an end
• As a process, work must flow through it
• Change management activities are being performed on the change itself (more below)
• There’s a practical bandwidth challenge: how many changes can flow through the change management process?
• It’s inherently consumed with ensuring that inputs are converted to outputs following the specified activity steps in a consistent manner

And last, but certainly not least, this process approach is simply not compatible with modern development methodologies like Agile and DevOps and with them, Continuous Integration and Continuous Deployment.

Outcomes and Business Value

You’ll recall the goals of change management from the first article in this series:

1. Support timely and effective implementation of business-required changes
2. Appropriately manage risk to the business
3. Minimize negative impact of changes to/for the business
4. Ensure changes achieve desired business outcomes
5. Ensure governance and compliance expectations are met

As I mentioned before, these are very business outcome focused, not process or activity.

By way of analogy, let’s say you’re in the market for a new car. If you look at car buying as a process, it starts with a need or want, a trigger if you will. Next, you embark on a process of sorts—a set of steps you take—to identify what you need and want, what you can afford, and where to make a purchase.

In a previous generation, the only approach possible was to physically go to car dealers, look at cars, and talk to salespeople. A thorough process would have you visit several dealers to compare various brands and models.

After having followed a car-buying process, the output would be a new car in your garage.

To be precise, the purchase and possession of a car is the output of a car buying process. What we can do with our new car is the outcome of having purchased a car.

But modern car buying includes comparing online reviews and product evaluations, formal and informal. There are now online car shopping sites where you can select a car, put it in your online cart, check out, and schedule delivery to your home or workplace. You can even buy a car from a massive vending machine.

If we are rigidly tied to car buying as a process, these modern approaches may prove problematic. But if we view car buying in terms of outcomes, these new methods may be incredibly efficient and effective in achieving the desired outcome.

What Are We Trying to Achieve?

Once change management embraces the role as governance and oversight, organizations can start focusing on what outcomes we are trying to achieve and whether this (process, activity, practice) is the best way to accomplish that.

The offramp from inspect-every-change begins with the increased focus on standard changes, delegated change authority, and change models. All three are intended to push change risk management and approval as close to the pipeline as possible, while ensuring broader expectations (such as compliance controls) are achieved. It’s a cross-silo partnership that embraces ownership and accountability in pipelines and focuses on the shared objective of achieving the organization’s change outcome expectations.

Greg Sanker is the author of IT Change Management: A Practitioner’s Guide, a former CIO, an international speaker, and a frequent blogger. Greg has decades of global IT experience with organizations ranging from Fortune 10 tech giants to the public sector. He is one of HDI’s Top 25 Thought Leaders. Find Greg at ITSMTransition.com and on Twitter at @gtsanker.