The Goals of Change Management: What Outcomes Are We Trying to Achieve

Best of HDI in 2020 - #10

Technology is a never-ending series of changes. Sometimes big, sometimes small, there’s never a time when changes aren’t happening.

Depending on your perspective and the challenges you face in your service management organization, your approach to how changes are managed may vary greatly, ranging from highly automated build, test, and deployment work streams to a highly centralized formal change advisory board (CAB). In a growing number of cases, the same organization has both, which puts change management directly at the intersection of organizational agility and cultural transformation.

One thing is clear. Change management can no longer be a one size-fits-all approach. But we also can’t completely trash-can the practice of change management.

Organizations are subject to a great many internal and external business controls and compliance regulations—HIPAA, SOX, PCI/DSS, and standards like NIST 800-53. These compliance frameworks mandate certain controls to ensure operational activities are done in a way that adequately protects the interests of stakeholders.

For organizations subject to these requirements—as well as expectations set by the organizations’ own governing body—compliance is not optional and is subject to verification by audit and other measures. Many compliance frameworks have specific controls related to how an organization manages IT changes.

Outputs vs. Outcomes

A fair amount of what’s been done in what I’ll call “traditional change management” has been activity or process based. The idea being that if changes are managed consistently through well-designed and managed processes, the result will be improved change management.

Based on the belief that following the change process is the path to better change management, it’s not an unreasonable conclusion that rigid adherence to the process will produce even better results. And that gets us to a fundamental problem: the focus on (change process) outputs versus change outcomes.

In IT Change Management: A Practitioner’s Guide, I suggested that the goals of change management are:

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

A couple of observations emerge pretty quickly. First of all, none of these goals favor any particular approach, practice, or process often associated with “change management.” In fact, these goals can actually be achieved in a great many ways. And that’s entirely the point. Change management shouldn’t be limited to a particular approach, but rather focus on the desired outcomes the organization requires of change.

Next, four of the five directly include the term “business,” stating explicitly that whatever change hopes to achieve, it does so in support of the organization’s business objectives. I frequently say “outcomes over process,” and by that, I mean simply that the goal of a practice or process must be to achieve business outcomes that matter to organization.

For change management, these are change outcome expectations. Literally, what is the organization’s expectation for managing changes. (To be even more precise, technically, it’s the expectations of the organization’s governing body, but I digress.)

Change Outcome Expectations

Change outcome expectations, simply put, are the non-negotiable expectations for how changes are handled in the organization. I’m an advocate of replacing the traditional change policy document with one that focuses on outcomes.

If you had to broadly categorize change outcome expectations, they would generally fall into:

• Baseline. Applies to all IT changes
• Value stream specific. Expectations that are unique to individual value streams
• Adaptive. Apply differently, or to different degrees depending on the circumstances 

Examples might include:

• Changes are tested prior to deployment
• Changes are documented so other stakeholders have real-time access to detailed information about changes
• Changes that don’t achieve desired results can be rolled back in a defined time period
• Changes are approved by authorized business and IT

This is hardly an exhaustive list, and I wouldn’t want anyone to simply adopt a list from an article. Every organization must define change outcome expectations that suit their unique challenges, circumstances, culture, and business.

“What are we actually trying to achieve?” might seem like an obvious question, but in practice it is often fairly difficult to answer.

“What are we actually trying to achieve?” might seem like an obvious question.

Adaptive Change Management

There are very few organizations remaining with a monolithic approach to how changes are developed, tested, and deployed. A great many have either started or are well on their way toward adoption of Agile/DevOps methodologies for internally developed applications, especially core business applications that provide digital services directly to external customers.

While these methods show tremendous value for rapid delivery of small changes, in tight coordination with the business, they present a unique challenge where traditional change management is concerned.

One of the key reasons for defining change outcome expectations rather than a more traditional change policy approach is that outcome expectations can be readily applied to all value streams in the organization—regardless of the IT service, product, or business line supported. Change outcome expectations, by that definition, must be developed such that they are agnostic to process, product, means, and methods used to deliver changes.

Let’s say an organization has determined that changes to core business applications are expected to be tested before being implemented in production, which is a fairly common expectation. But the universal response from the Agile/DevOps/Continuous Integration/Continuous Delivery crowd will be “Duh! That’s the only way a change can even make it to production.”

If the application is one where changes are developed and deployed in an Agile/DevOps value stream, using automated testing and deployment tools, this expectation is fully realized in the value stream with limited change management intervention. In this case, change management should concern itself with understanding how this expectation is being achieved. So long as it’s achieved (the change outcome expectation), change management cannot add any value to the value stream by inspecting individual changes. It’s an outcome expectation that’s literally engineered into the value stream itself.

By contrast, if the same organization has an application that follows more traditional development, testing, and manual deployment, (and trust me, there are a great many such applications in many organizations), then some level of oversite would be required to ensure the change outcome expectation of testing all changes is accomplished. (Mind you, this isn’t justification for a CAB, though that’s also viable.)

The greater point here is that by focusing on outcome expectations, the value streams themselves can determine how to best achieve it for their particular circumstance. In this way, outcome-based change management is adaptive and fully supports higher velocity value streams that do not benefit from additional oversight from an external review.

Change management shifts its focus away from inspecting and approving individual changes, and focuses instead on outcome performance, change governance, and continual improvement.

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.