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 approvals when notifications would 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:
- When is a notification sufficient and when is an approval required for a change?
- Who should approve and who should be notified?
- 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 service improvement (CSI) is crucial to address new challenges, executive directions, and lessons learned.
So, let’s address the first question.
Change Notification vs. Approval
Change management is all about communication and should not just be about covering your back, which is why you traditionally find a zillion approvals for change tickets. The alternative to approvals is notifications, which achieve the communication goal and underscore discipline and accountability.
The big difference between notifications and approvals is psychological. Notifications are sent in routine emails and are part of your daily jobs, while 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.
|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 notifications||Challenge of correct understanding of what’s being approved (problem of proforma or blind 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
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 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 approvals in the tools to less onerous and time-consuming notifications as stakeholders become more familiar with the complexity.
The Tool Perspective
Adding and verifying notifications in ServiceNow is easy. Adding an approval step, on the contrary, may require changing the workflow behind the normal or emergency change ticket. So, by definition, building additional 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 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:
- You build an 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 approvals to a compliance minimum.
- 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.
- Consider that if you have multiple approvals, there is a dilution of responsibility. Reviews become ineffective because the “other guy” has approved, so I can “rubber-stamp” it.
- 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.
My suggestion is to rely more on notifications instead of 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 notifications versus approvals.
I hope that this post was helpful. Please return to read my next change management article which will answer question #2: who should approve a change?