In change management, the act of approving gives someone the power to stop a change. Thus, when evaluating a change management approval structure, this should always be the foremost question – should the person you’re asking to approve actually be able to stop a change from occurring, even if everyone else agrees it should occur? That question has helped people really focus on to whom they give that power.
Please read on to understand who, in your organization, is best positioned to approve changes.
The Power of Change Approval
This power aspect drives the need for a thoughtful approach to your approval structure. A great litmus test that can be applied is as follows: if you don’t have a specific scope of approval, then you shouldn’t be an approver. If you’re not actually deciding or influencing subsequent actions related to the change, you could be notified, but shouldn’t approve.
Change Management Gates
In ITIL change management, there are two main gates: the acceptance at the beginning of the ticket lifecycle and the approval right before implementation. The technical green lights are covered by the fact that the change ticket owner is a technical person who “walks” the ticket through its lifecycle. This person is responsible for the risk mitigation, for any consequences of the change, and thus, obviously, for the communication with the other technical towers that need to be aware of the change.
I would argue that these technical aspects should all be covered by notifications that are managed and sent out by the change (technical) ticket owner. Trying to codify all possible scenarios in the workflows, to get relevant approvals, is a nightmare and a sure-fire formula to get your change managers bogged down in a continuous struggle to get it right.
My previous ITSM.tools blog, “Change Management: Change Notification vs. Approval,” explains this further.
The Change Acceptance Gate
In some organizations, this may be called the authorization gate. There’s not yet a need for a technical approval at this stage and, conceptually, you need two types of approvals at this point:
- Does the change ticket make business sense?
- Is the change management process the proper venue for this ticket?
The first question needs to be answered by the service owner and addresses the investment in time and resources. For instance, if someone proposes a major upgrade or investment for an application that’s slated for replacement – then the business or application service owner can stop the ticket.
The second question is about the process itself. Should the change ticket have been submitted as a request or should it have been introduced via a demand process? Does this ticket belong in change management? This question is supposed to be answered by the process owner or a change manager working on his or her behalf.
There’s the obvious situation where the risk and impact of the change are huge, and executive management (e.g., via an IT Steering Committee or an Architectural Review Board) should assume the risk. This type of change does not belong in a Change Advisory Board (CAB), except for purely informational purposes.
For the tickets that do belong in a CAB, the differentiation related to the two types of approvals can be a matter of splitting up the tickets according to the purpose of the change ticket:
- Is the purpose of the ticket to change the business (CTB)? Or
- Is the record part of “keeping the lights on” (KTLO) or running the business (RTB)?
In the first case, I suggest getting the service owner’s approval as the change may affect the budget for the service and is strategic. In the second case, the change manager’s approval should suffice as the change is part of planned and expected operational activities. To make this work, you obviously need documentation about the characteristics and guidelines to properly distinguish between CTB and RTB.
An additional benefit of making the distinction between RTB and CTB is that you have a better-defined pool of changes that you want to potentially convert to standard changes. And I cannot imagine situations where you would convert a CTB change ticket into a standard change.
The Approval Gate
This approval needs to occur before implementation and is being done either via a CAB (for major and significant changes) or by the change manager (for minor changes). There are basically three main open questions at this moment:
- Are there any technical red flags?
- Has the change been properly communicated (including to the business)?
- Has the process been followed?
Counting on the CAB to ensure there are no technical red flags is a sign of poor planning from the side of the change ticket owner. When the ticket arrives in the CAB, it should be ready to go, except for some extraordinary or new circumstances. Some organizations use meetings (“red team” or “T-CAB” meetings) before the actual CAB to ensure that all technical stakeholders are on board. The CAB then serves as the last gate to check for red flags.
The change process is all about the three Cs: communication, communication, and communication. The role of the CAB should focus on the effectiveness of that communication. At a high level, the documentation of a change is to guide the ticket through its paces or, in other words, to ensure that the process is followed. So, I want to argue that the main approvers for the ticket need to be process people, rather than the service owners.
The decision to adhere to the above suggested guidelines obviously needs to be aligned with the organization’s size and maturity. In the beginning of greenfield change implementation stages, adhering to a strict process focus may not be advisable. The goal and the vision (together with continual process improvement activities) however, should point to an increasing emphasis on the process over time.
My suggestion is to eventually (1) ensure the presence of the relevant stakeholders during the CAB meeting and (2) have the change process manager approve the change. This is not achievable from one day to the next but needs to be gradually implemented. The necessary resolve and starting principle though, is that CAB meetings need to stop being a “gab-fest” and should get teeth.
I hope that this article was helpful. Please return to read my next change management post which will answer how to structure the CAB for maximum effectiveness.
Jan is a process architect, focusing on IT service management, operational governance, and outsourcing. He is an accredited ServiceNow system administration trainer, and certified in ITIL Service Management (v3 Expert level), Project Management (PMP), Governance of Enterprise IT (CGEIT), ISO/IEC20000 training and consulting, and TOGAF 9. He earned an MBA from Rice University in Houston and is a Principal Consultant with DXC/Fruition Partners.