Change Management: Change Notifications vs. Approvals

In a recent ServiceNow implementation, where we had to wean our client from the convoluted change management customizations they’d built in their existing IT service management (ITSM) tool, I had a heated discussion with an experienced colleague about change management notifications versus change approvals. I dared telling her that way too many change tickets are configured to chase change approvals when notifications wouldhttps://en.wikipedia.org/wiki/Change-advisory_board be sufficient.

In addition, our client was implementing a workbench utility plugin to help run a change advisory board (CAB), and the client process owner asked for best practices and guiding principles on running multiple CABs in his global environment.

The purpose of these questions and discussions was to establish a new change management process, and procedures, from the ground up, with scalability, standardization, risk mitigation, and efficiency all obviously core to these conversations.

The key questions that came up were:

1. When is a notification sufficient and when is an approval required for a change?
2. Who should approve and who should be notified?
3. How should the CAB then be structured to achieve maximum efficiency?

In this article, I attempt to answer the first of these questions, with the others covered in a further two posts, but the main challenge is that there are no infallible answers, only suggestions and guiding principles, since no two organizations are the same. For instance, change management for a 1,000-person distribution organization in the US is fundamentally different from the process for a 200,000-end-user behemoth with a global footprint in half a dozen different industries.

It’s also important to keep in mind that, as one of the most intricate processes in the ITIL books, the tweaking of change management is something that’s never finished. Continual improvement (formerly CSI) is crucial to address new challenges, executive directions, and lessons learned.

So, let’s address the first question.

Change Notifications vs. Change Approvals

Change management is all about communication and should not just be about covering your back, which is why you traditionally find a zillion change approvals for change tickets. The alternative to change approvals is notifications, which achieve the communication goal and underscore discipline and accountability.

The big difference between change notifications and change approvals is psychological. Notifications are sent in routine emails and are part of your daily jobs, while change approvals tend to be perceived as more formal and structured. In both cases, the communication goal is achieved: the recipient is informed that a change is pending.

Change Notifications	Change Approvals
One-way	Two-way (request and approval/rejection)
Routine, informal, simple	Formal, structured, can be complex
Informed and aware	Responsible: decision made or action taken
Easy to configure and flexible	Baked in the workflows
Deniable “I didn’t see that email”	Not deniable
Can be ignored if it’s not applicable to the recipient	Recipient must approve or reject
Will not cause delays	Can cause delays
Potentially causing email overload when recipient receives tons of change notifications	Challenge of correct understanding of what’s being approved (problem of proforma or blind change approvals)

Understanding the consequences of the distinction between the two is without a doubt difficult. There are no easy answers and the topic needs more analysis from a technical, tool, and governance perspective.

The Technical Perspective of Change Management

When you deal with a complex environment, it follows that the changes may be complex. If you don’t have a fully-developed dependency mapping of your configuration management database (CMDB) that’s graphically helping you understand the potential consequences of your changes, then you will have situations where you want to cover your behind and get change approvals from “everybody and their mother” to proceed with the intended change. After a few iterations of the same change, it becomes obvious where the dangerous single points of failure are, and which areas need a green light. You can then gradually shift from formal change approvals in the tools to less onerous and time-consuming notifications as stakeholders become more familiar with the complexity.

The Change Management Tool Perspective

Adding and verifying notifications in ServiceNow is easy. Adding a change approval step, on the contrary, may require changing the workflow behind the normal or emergency change ticket. So, by definition, building additional change approvals in your workflows will make your future upgrades subject to additional testing. Migrating from a tool like Remedy and trying to make ServiceNow emulate the status quo can consequently become a configuration nightmare. Thus, the easiest approach when you transition your change management is to avoid approvals, build lots of notifications, and then gradually scale the notifications down as you get more specific and granular with your CMDB in terms of the impact of your change.

The Governance Perspective

This is the real rub. Change management process people typically want to have lots of change approvals to mitigate risks and make sure that everybody is on board with a proposed change. That desire makes perfect sense. However, there are four major downsides to this approach:

1. You build a change approval bureaucracy. An IT organization’s discipline is particularly sensitive to bureaucratic hurdles and can quickly erode because of them. That’s why it is so important to build up your “standard changes” (pre-approved, low-risk changes, that are sluiced through the process with an approved template) and why it’s important to keep your regular change approvals to a compliance minimum.
2. Change approval schemes get complex quickly. Think about situations where you want one technical service owner to approve, but not if this particular network person approves, but only if that happens in the maintenance window, and provided that the moon is in its last phase. Or think about vacation scheduling and delegation rules for change approvals. Again, you create upgrade and testing nightmares.
3. Consider that if you have multiple change approvals, there is a dilution of responsibility. Reviews become ineffective because the “other guy” has approved, so I can “rubber-stamp” it.
4. You water down the responsibility of the change ticket owner. This is the most important downside, because change management discipline and professionalism start and end with the ticket owner. The ticket owner is responsible for the proper planning and scheduling, walks the ticket through its phases, keeps the business service owner (and potentially the end users) informed, and ensures technical and operational visibility for the relevant parties throughout the ticket’s lifecycle. The change ticket owner should not be given an opportunity to point fingers when issues are popping up.

In Conclusion on Change Approvals

My suggestion is to rely more on notifications instead of change approvals. Notifications will ensure communication and appropriate spreading of the information about the pending change and keep the responsibility in the lap of the ticket owner.

Granted, the formal clicking of an “approve” button removes any “plausible deniability” that a person was indeed informed of the impending change. But let me suggest that there’s something seriously wrong in an organization where people have the possibility to say: “I didn’t see those notification emails.” You may have a far bigger governance issue at hand than a heated discussion about change notifications versus change approvals.

I hope that this change approvals post was helpful. Please return to read my next change management article which will answer question #2: who should approve a change?

Thanks to my DXC colleagues Greg Dusault and Ian Golando for their insightful feedback regarding this topic.

ITIL Service Portfolio Management and Its Benefits Explained

Service Desk Basics: What to Do When the End User Doesn’t Respond?

ITIL 4 Dummies

ITSM and Availability Management

The Making of a Maturity Model: An Approach to Culture and Client Support

ITIL 4 Explained

Which ITSM Tool? Here’s an ITSM Tools List

Enterprise Service Management Explained

What ITSM Pros Need to Know About CMDBs

How to Define, Measure, and Report IT Service Availability