Hi, my name is Nicole, and I love Change Management! Yup, I said it. It is my favorite ITIL process. Why do I love Change Management so much? I’ve learned that if you carefully implement and scale a Change Management process to your organization’s needs, the benefits can be astounding. With more organizations adopting the fast moving Agile methodologies and practices, it is important to evaluate how effective your Change Management process is. This blog illustrates how one IT organization renovated their Change Management process and became IT Superstars.
The Change Management Nightmare
When I first joined this major telecom organization, the Change Management process made everyone groan. Everyone in IT, Customer Care, Revenue Assurance, and many other business partners were required to attend the infamous Change Management Advisory Board (CAB). For a major telecom company, we only had eighty people in IT, but all these valuable resources and business stake-holders were required to attend. What other way could there possibly be for the Business and IT to coordinate, learn, or even understand what changes were being made?
Not only did the Change process waste all of these resources’ valuable time, it served as nothing more than a checklist of changes. The Change Manager would call out a change ticket number, ask the responsible party if the change was ready or not, and discuss any objections. How could anyone object to a change if there was no discussion around the impacts or risks involved with said change? We were so busy reviewing every single change the organization was making, that we left no time for these critical conversations. Instead of Change Management acting as an enabler of change, it was just more red tape that offered zero value to the organization.
One Indication Your Change Management Process Needs Work
Have you noticed that every change is an emergency change in your organization? This may be an indication that your Change Management process is hard to do business with. I have seen Change Management processes that require engineers and programmers to submit their change ten or more days in advance, go through extensive approvals, and get scheduled over a month out for an actual implementation. In an agile world, that simply doesn’t work. As the business is pushing IT for new systems and enhancements to be completed in days or weeks, instead of months and years, Change Management can’t be another red tape process. Many programmers and engineers would rather take the risk of doing an emergency change, than delay the project that the business is chomping at the bit for. Look at what is driving your emergency changes. Chances are, Change Management is too hard to do business with.
So, what made that major telecom IT shop realize that their Change Management process simply didn’t work anymore? After implementing two SAAS (Software-As-A-Service) solutions and seeing how quickly change could be done, it was immediately realized that our Change Management process and the new technologies didn’t mix together. After our initial implementation of ServiceNow, we saw not only how quickly small configuration changes could be done, but that entire business applications could be built and implemented in relatively short amounts of time. We were able to develop an entire Human Resources Case Management application in one day. One day!
We realized though, that as long as our Change Management process held up deployment with silly red tape, our ability to develop quickly didn’t matter. That’s when we came to the conclusion that agile-based solutions needed a faster way to deploy changes in their solutions, while still ensuring operational stability. The changes that needed to be deployed were low risk and low impact, so was it really necessary that we waited for the one change window that was offered, along with many other hurdles? The same was realized with our Workday solution; why would we need to wait over ten days just to simply update an executive’s dashboard?
So, what was our solution to this new agile world and change management colliding?
Our Change Management Process Become More Agile with these Steps
1. Increased the number of Change windows. No longer were changes required to go in on Wednesday nights at 10pm. Smaller changes that had a low impact and low risk were allowed to be deployed nightly from 10pm – 5am. Examples of these ‘smaller changes’ run along the lines of changing a color on a report or adding a category in your ITSM solution. More significant changes were to go on two specified nights.
2. Simplified Categorization of Changes. The IT group was already familiar with categorizing incidents from Priority 1 (P1) through Priority 4 (P4). Priority 1 changes were equivalent to Emergency Changes. A priority 2 change was a normal change, and was usually a significant release or large code push. Priority 3 changes were in the middle of a standard and normal change. They were given additional scrutiny, upon the discretion of the Change Manager. And finally, priority 4 changes were Standard changes that required no review by the Change Advisory Board, and had many change windows to choose from. These changes would be category changes on the ServiceNow platform, or a dashboard change in Workday.
Using that same framework for Change Management made identifying the changes that needed additional discussion and communication requirements easy. It wasn’t traditional ITIL, but it worked well for a small IT group that was adopting agile methodologies, and who needed to keep up with increased market competition.
3. Reduced the number of changes discussed at CAB. Only changes identified as being higher level, a P3 or P2, were subject to CAB review. We also made CAB strictly an IT function. This opened the discussion to topics such as cross-system impacts and risks. Post CAB, we would send an IT newsletter to the Enterprise outlining upcoming changes and potential impacts to the end-user communities. This freed up our business partners to focus on their projects instead of having to worry about ‘what IT was doing.’
4. Changed our ITSM solution. Before, our Change Management solution was slow, complicated, and often lost track of submissions. Implementing ServiceNow allowed us to link Incident Management to Change Management, Change Management to our Configuration Management Database (CMDB), and so on. There were also a ton of other cool things that we were able to do with that platform, but I will save that for another blog post!
These simple changes to our process resulted in great value to our organization. No organization is alike, and the changes that we made may not work for your organization. But I strongly encourage you to look at your Change Management process and see if it is time for a little polishing.
For more on the Agile Scrum Project Management Methodology, check out our Scrum series:
- 3 Ways Scrum Can Transform Your Organization
- Scrum as a Strategy: Better Manage your ServiceNow Environment
- Velocity: Cut Costs & Improve Service with Scrum
