Let’s take a lighthearted look at ITIL change management.
This is a story about ITIL change management (or change enablement as ITIL 4 has termed it). There once was a man named Garry who worked as an infrastructure architect in the IT department of a manufacturing company. The enterprise used a big data analytics solution to ensure proactive maintenance of their manufacturing processes. And as happens with big data, its servers got constantly overloaded with sensor data.
One day, Garry heard his colleague complain that he couldn’t create a ITIL change management-related report in their big data solution despite trying for what seemed forever. And that’s when Garry realized that it was finally time to expand the company’s on-premises data center.
Chapter I: The man who justified
Having mulled the idea over for some time, Garry felt he now needed to do something about it. The level of IT service management (ITSM) maturity in Garry’s company was high enough to solve this data center issue through the ITIL change management process in the company’s ITSM tool.
Garry knew that lots of configuration changes were expected (new servers, network hardware, new operating system instances, etc.), and that they needed to be properly documented in the configuration management database (CMDB). And upon doing so, various employees needed to be notified of the new changes in the IT infrastructure. And Garry was sure that maintaining awareness of changes was a good reason for using the ITIL change management process in this case.
This made Garry create a change request in the company’s ITSM tool. But it wasn’t that easy. To request his change properly, he needed to have a good justification for the change, a detailed implementation, backout, and testing plan, as well as a detailed risk and impact analysis. Without these, his change was bound to be rejected.
According to ITIL change management best practices, all these points were highly important, and Garry knew this. The justification wasn’t difficult to do, since the data center expansion had been on his mind for a long time. All the rest required more effort, but he willingly made it and the change passed to the next stage – the change advisory board (CAB).
Chapter II: The mystery of the CAB in ITIL change management
It would have been a lot easier if Garry could implement the change right away, but the ITIL change management process is there for a reason. It prevents chaotic and uncontrollable changes that can cause serious disruptions to a company’s operations.
For this reason, the change needed to be authorized. Since Garry’s company used its ITSM tool’s out-of-the-box (OOTB) ITIL change management capabilities, the authorization process wasn’t that complicated.
First, Garry’s change went to the service maintenance group, where Revill Topbottom (one of the group’s members) assessed the change and analyzed Garry’s justification and implementation, backout, and testing plans. If Revill thought that the change was warranted, then it would get its technical approval.
As Garry had given the change enough thought and effort, he got the tech team’s approval easily. Piece of cake.
But this wasn’t the end of the authorization process. What Garry was less sure about was CAB approval. While the CAB was analyzing the impact of the change, its risks, and the change-related costs that the company would bear, Garry’s proposal spent some time in the CAB.
Quite frankly, it was not a pleasant time for Garry. But what Garry didn’t know was that the CAB couldn’t agree on the change’s expenses. Some of the members thought the change cost too much, while others were convinced that this money would be well spent. However, in a week, the whole CAB managed to come to a change management decision.
After this seemingly endless wait, Garry was notified that his change received the desired CAB approval and was scheduled for implementation in a month. His efforts in planning had paid off!
Chapter III: The implemented change and the obstacle
Their system admin, Angus Rumbledoor, assigned the implementation of the change to Garry’s friend and colleague Ermione, who was considered one of the most capable employees. And Don, another friend of Garry’s, got to help her.
Although Garry really couldn’t understand why, since Don while being a good IT specialist was quite clumsy. And Ermione would do well anyway. But still, he was sure that his colleagues would manage splendidly.
The whole ITIL change management process was carried out in the company’s ITSM tool – ServiceNow. The implementation plan was also stored within it. However, ServiceNow did not track the implementation steps themselves (which Don and Ermione needed to follow). They could make work notes in the corresponding change task enough.
They needed to do a lot: select servers, deal with the vendor, receive the delivery, check whether the delivered items were in one piece, install the servers, etc. So, it didn’t help much just to write who did what. They needed their tool to be more interactive and useful – to help them with planning and send alerts if they didn’t do what they should have. So, instead of using work notes in the change task, Don and Ermione used an external tool to help them track their progress.
Chapter IV: The consequence of change (without ITIL change management)
After Garry’s friends had carried out the work, one more important step had to happen. The review.
Garry knew that, having come this far, there would be issues if the review of the change was poor, which added to his nerves. What bothered Garry even more though was that the review of the change was assigned to the frightening and mighty Lazarus Frape. And it would be very easy to get nervous right now, if you were Garry, because he knew that Frape didn’t like him. At all.
In his review, Lazarus could say two terrible things. The first is that the change wasn’t implemented the way it should have been, which would tarnish Ermione’s and Don’s good names. And the second is that the change wasn’t necessary in the first place, which would badly affect Garry’s reputation. Although the guys had tried their best and were sure that they had done everything right, now their reputation was at stake. Would Lazarus really give the change a poor review because of a personal dislike?
Surprisingly for everyone, Frape didn’t malign the change. He verified that everything worked well, analyzed the impact of the change once again, and closed the successfully-completed change record.
Epilog
This change was extremely necessary for Garry’s company. And if it was not for ITIL change management, alterations in the company’s IT infrastructure could have soon got out of hand.
Garry, Don, and Ermione had saved the day again.
Vladimir Leinov
Vladimir is an IT Project Coordinator at ScienceSoft, with a 13-year background in resource management and project coordination, and a 19-year work experience in IT. His portfolio includes projects on architecture design, databases, integration, and deployment of ITSM solutions based on ServiceNow.
