Within Service Management, the role of Change Manager is unique to their peers. They regularly face challenges different from those of a Problem Manager or Incident Manager. Below are four challenges that Change Managers regularly face.
Change Manager: “It takes me longer to submit a change than it does for me to do the work.”
Every Change Manager has heard this gem more than once. I’d venture a guess that every person in IT has said or thought this same thing. (Only the brave ones will say it to the Change Manager). A Change Manager’s role is not to tie people up with red-tape. Rather, it’s to protect the production environment by minimizing risks introduced by changes. This requires a level of formality and checks to ensure the change has minimal risk yet successful implementation. But the reality is some changes are low risk with a history of success. A Change Manager should facilitate these types of changes as Standard Changes. By doing this, they minimize the effort, paperwork, and approval typically required for Normal Changes.
Change Manager: “The business wants this change in immediately, it must be an Emergency Change.”
While there is a level of formality to Emergency Changes, they’re rarely sufficiently tested prior to implementation. Then, a Senior Leader approves them via a quick “go ahead test” email/text message. Mistakes happen when we rush. In true Emergency Change situations, a Change Manager accepts this increased level of risk. They accept the risk because the change should correct or prevent a critical issue. Successful Change Managers prepare for these scenarios and identify true Emergency situations. If an urgent change requires implementation (thus bypassing the Normal Change process) there are a series of steps. This ensures the awareness of the Service Desk for potential issues. In addition, business partners and the Change Requester know the benefits of following the Normal Change process in the future.
Identifying the right changes to discuss and key people to attend CAB
There is a balance to Change Advisory Board meetings. The presence of the correct attendees to review the right changes is imperative. By ensuring the correct people are in attendance, you don’t need to invite all of IT to review submitted changes to answer questions. Failure to achieve this balance results in meetings that drag on and wasted hours. Even worse, it could end in meetings with more questions remaining than answered.
First, identify the changes you want to discuss. Not all Normal Changes need to be part of the CAB agenda. Initially, target those changes with higher risk. Then extend implementation (and/or validation) times, focus on high visibility and/or customer impact, and collaborate with multiple groups (including testers). The remaining changes stay on the Forward Schedule of Change. By doing this, the Change Manager can ask questions when necessary.
Once you have identified the changes to discuss at CAB, selecting the attendees becomes clearer. Invite those responsible for implementing the discussed changes and key management representatives from IT departments. They provide a holistic view of potential impact and risk when advising the Change Manager. Don’t forget a Service Desk representative! Business stakeholders or representatives can be invited to CAB based on the changes being reviewed. This also depends on your organization’s culture of IT and Business integration.
Getting your ITSM peers to follow the Change Management process.
Seriously ITSM Process Managers, we know your processes are important and great things come from them. However, when you want to implement a Change to resolve an Incident or fix the root cause of a Problem, the Change Management process still needs to be followed. Please do not ask the Change Manager how the process can be skirted or attempt to utilize your ITIL knowledge to prove that “technically it’s not really a change per se”!