How to we keep up with the development and at the same time make sure not to disturb the ongoing operations? The answer is change management.
The best IS/IT providers out there are those that successfully masters Change management, trust me, there is no other way. You can have an excellent service desk, the best developers on the planet or an own Skynet infrastructure, none of these matters if you constantly fumble the change management ball.
Please allow me to illustrate the problems with lacking change management, because most of you have already seen the crippling forces of bad change management.
Pick one really important IS/IT service, that will imply large revenue loss almost instantly when offline. Therefore, you have dedicated support specialists that can resolve potential problems really fast, you are putting a lot of effort in keeping this service healthy. You buy 23423423 servers to never run out of capacity (in later blogs we will talk about demand management, do not worry), you have large LCD screen showing CPU- and storage utilization levels. In short, you have done everything you possible can to make sure this service is well guarded. Only one Sunday, a very clever technician fixed an incident by changing the configuration. Suddenly everything falls apart, nobody has a clue what happened and very soon heads start to roll down the IS/IT service provider corridors. The very famous “shit” has hit the even more famous “fan” and everyone is yelling.
Blaming the technician that caused this incident is as clever as blaming my 2-yearold when he tips over his glass of juice.
What you need is to protect your services from unwanted and/or unforeseen events and the only way you can do this is by applying change control. Not doing change management is as clever as going to the supermarket without first checking what is missing in the fridge at home; you need to think before acting. Since our IS/IT infrastructure gets more complicated every day, the dependencies and joint utilization of physical equipment increases every day and we are human beings, the use of change management is mandatory, there is no excuse ladies and gentlemen.
Ok, so let us assume you decided to implement change management. When doing this you really need to slice the elephant. Trying to establish change control for all your services, at the same time, is going effectively to kill you, mentally. Change control, with a big emphasis on the word “control”, requires a lot of oil in the cogwheels, believe me!
Simply assigning a change manager, produce a set of document templates and take some organizational hostage in the CAB solves very little.
Like I always do I am going to provide a few pointers what will help you to lubricate the change management machine parts, to keep your service development from getting partly or fully crippled by a super heavy bureaucracy. Take my word for it, so far I´ve done at least 15 rescue projects in organizations in deep crisis based on not taking this seriously. Here are a few key areas:
- Start small-scale and multiply: Choose a couple of services/a service area or likewise and start there, set up the CAB (Change Advisory Board, or similar) meeting structure, assign and empower a change manager, roll-out the normal-, standard- and emergency change process flows. Make sure you have a simple yet sufficient CR (change request) template and focus on informing/educating/supporting both IT-, and business staff. As soon as the change machinery is working well, multiply the same approach to the next area, and the next. The baby step model is really to prefer, especially for Change management, so far I think I´ve done about 15 rescue projects and this process is normally one of the biggest pain points (when done wrong, otherwise it kicks butt!).
- Start creating a battery of standard changes right away: This is super important, do the normal change process just once for simple, low-risk, cheap and normally very frequent changes. The second time and forward these changes will not even enter the CAB or need approval; normally you delegate them, for example in requests models and support scripts for the service desk. A healthy change management process has a big library of standard changes. DO NOT forget to maintain these; they are also subject to change control ladies and gentlemen!
- Make an effort to create a really good emergency change process: One things are really bad we do not have time to do things the way we would like to. This does however not mean we do nothing. Your Emergency change process needs to include the Emergency CAB (ECAB), normally the main people that needs to be involved, using a virtual conference, to get the approval quickly. The administrative tasks are normally carried out after the deployment. This is your fast track; however, it cannot be a shortcut for those who wants to get ahead faster. Make sure you have very clear rules for when a change is an emergency change and use KPIs to do follow-up, if you are above 15% emergency changes, you have either a crappy infrastructure or very creative staff.
- Let there be no exceptions: There is absolutely no reason to allow anyone perform changes of anything in the change control scope, we are doing this for a very good reason. Unfortunately, many organizations seems to think that change management only is valid for “line organization changes” and not projects. This is not at all a good idea, projects are a great way to achieve a lot, in a controlled manner, with defined resources, but of course, the changes planned needs to be approved in the CABs. Furthermore, in my experience, projects are normally walking in the beginning and running for their lives in the end to reach their objectives, this means cutting corners. This also means tipping over a lot of semi-tested, half-ready or non-documented changes, many times without any form of operational readiness. This is a good way to make sure that your service desk is punched in the face the first 1-2 weeks after each project has delivered.
As always, be smart about it, change management is the key to master the balancing act between the required status quo and the flexibility needed to support our business, it’s very important that this process is always developed (CSI remember), measured and always considers oiling up the cogs to make it faster. Please let me know if you are interested in diving deeper into any of these subjects, I would love to learn more about what you want to read!