I’ve heard a lot of negative talk about ITIL over the years. Some say they tried it, it doesn’t work and it should die. Some say they tried to implement it, it didn’t work, and it should die. And some just say it should just die.
Many times, changes can be extremely helpful to an organization (for example, we need to implement a fix or patch, release a new application, etc.). Being able to make changes – and lots of them – quickly allows us to be an agile and responsible organization. However, when we change stuff, sometimes we break stuff. And that stuff can be pretty important. That’s why it’s so important to have a solid Change Management process in place. If your current organization does not have a good way of managing change, then rolling out a process to better manage changes can bring people who are otherwise used to making changes to their own stuff out of the shadows with pitchforks and torches. Here are some things to keep in mind if you are rolling out a new Change Management process and want to avoid a bit of the backlash.
Clearly define the scope of the process.
Not every single change needs to go through the Change Management process. Your goal should not be to bring everything to an immediate halt (that’s when people start looking for their torches). Only very important systems and services as well as items that have an impact on other groups should fall under the Change Management process - at least to start. To better understand what these items are, have a discussion with key members of the organization on the types of changes that need to be tracked and approved prior to making a change (think about those changes that have been the most visibly painful for the organization in the past and start there).
You will also want to discuss under what criteria you will require customers or vendors to follow the process. It’s ok to not capture every single change. Focus on the really important stuff first, and start simple if you have to. You can always add to the scope and overall process later. Document and communicate the scope of the process to everyone in IT as well as to customers and vendors. It’s helpful to ensure that everyone is clear on what constitutes a formal change and what does not.
Don’t treat all changes the same.
Not all changes are created equal, and in this case, one size definitely does not fit all. Very large, complex, costly, or risky changes should follow a separate, more robust process than those changes that are very simple and pose little threat to the environment. Make sure that the overall process and steps people have to go through are scaled accordingly. For the simple stuff, come up with a list (these are called Standard Changes. Here is a good article on how to define these types of changes).
Look at each of the steps along the way – the Request for Change form, the amount of approvals, the documentation you ask people to submit, etc. – and make sure it’s reasonable for the type of change that is being requested. If the process is too bureaucratic, particularly for the simple changes, people will go around the process, and you end up losing all value of the Change Management process in the first place (see a similar article I wrote on how to create or fix your Change Management process).
Hold people accountable.
Make sure you train everyone that will be submitting changes, so they fully understand the process; and make sure to communicate the importance of following the process. For Change Management to be effective and give you the benefit you want, everyone has to follow the process. That does not mean everyone except a Vice President and his or her team. It really does mean everyone. Leadership and customers have to buy into the importance of following the process, and the organization needs to set policy in place to hold everyone accountable. You may provide a short grace period while the process is still new. You may also decide to give people one warning, but if you don’t enforce real consequences to people that continue to go around the process, people will do it on a “best efforts” basis (AKA go around it). Hold people accountable and mean it. You must have a “zero tolerance” culture in order for this process to work well. And when it does, it’s pretty great.
What do you think? Have you rolled out a brand new Change Management process? Any great lessons you have learned in doing so?
The great irony of the Change Management process is that, once in place, it rarely changes. It should. All processes should be periodically assessed to determine what’s working and what isn’t – then updated accordingly. I can’t tell you how many times I’ve been told during consulting engagements that organizations:
1. Don’t have a Change Management process at all, or 2. Have one, but it’s a clunky, bureaucratic mess.
The implications of having disaggregated 911 call centers in this country is apparent. John Oliver featured the issue several weeks ago on Last Week Tonight, after which I did a little research of my own to see if I could learn more. In doing so, I realized there were people all over the country who’d had these terrible 911 call experiences. I am one of them – in our nation’s capital, no less.
As service organizations mature, and Incident and Service Request Management start to jell, executive management begins to get very interested in Service Asset and Configuration Management. And this is a very good thing. Knowing what assets we have and can provide service for is a powerful thing. It can drive increased budgets and resource allocation for IT, especially when we can point directly to how much time our staff spend on various CIs that might be obsolete or completely unused. If any of us look around, I'm sure we could find a lot of servers doing very little, if any work, but because of their age they require a great deal of resources to keep them "green" on our Event Monitors.
In my career I have held almost every position in IT Service Operations one might imagine. I have been a 1st level tech, operations manager, system engineer, even acted as a data center operations manager. I have also seen the consequences of poor communication within IT Operations. Service Transition without the hand-off is a major contributor to unplanned outages and confusion, which leads both IT and Business Management to lose faith in the efforts put forth by their technical staff.
Part 1 of a 5 part series
This is a 5 part blog series discussing the value to the business that can be found within a quality, well-maintained Configuration Management Database.
The importance of Change Management within an IT Service Provider is generally well understood. The need to document, evaluate, approve, schedule, and ultimately govern changes to services or IT Infrastructure is well documented. Generic process flow templates are widely available, a wide variety of suitable tools exist to support the process. So, why do so many organizations still struggle with this?