One of the things that worries me most about where the IT industry is headed is how we sometimes get so caught up in “the new stuff” that we forget to make sure that we have all the basics covered. A good example is change management, which can be easily overlooked while we’re looking at, and then researching, the newest and shiniest trends, and technologies, in the world of IT and IT service management (ITSM).
Unfortunately IT change doesn’t happen in isolation. In fact, these days it’s common for IT change to be business change – and it can impact the whole organization around it, and all the people touched by it. Consequently, changes that are inadequately assessed, managed, and reviewed can have a significantly harmful impact on both IT and business operations. In my opinion, not taking change seriously is akin to playing business-continuity Russian roulette.
Of course change will always involve a certain level of risk, but taking the time to properly assess the impact of a change can make things significantly less risky for everyone involved. Ultimately, it doesn’t matter how brilliant your service desk is, or how talented your tech support people are, if you get changes right the first time, you’ll break less things, generate less incidents, and have happier end users. It’s a win, win, win situation!
What to Look for When Assessing a Change
I’ve seen some pretty poor excuses for change requests in my time. Some have been so bad that they’ve resulted in me going to the requesters to find out what I’ve done to make them hate me. Remember though that some of your colleagues will request changes very infrequently and so, to save them time and energy, and yourself from head-butting the wall, it’s worth having a check list of everything you need to adequately consider a request for change:
Change title. Is the title clear and does it make sense? It’s not rocket science but when you’re working through lots of changes, possibly with your change advisory board (CAB), you might need to instantly be able to tell what something is and what it’s trying to achieve.
Change description. Is the description easy to understand and is it written in clear business language, or at least in something that you can easily translate to the rest of the organization when seeking customer approval? The last thing you want is to have to come away and ask more questions of the requester. You want the business to have faith in you knowing what you’re doing and, if you can’t explain what you’re trying to achieve to them, you might as well just tell them that you don’t have a clue.
Change reason. Why do we need to do this change? It sounds obvious, but once I had a change request appear in my queue where the server support analyst wanted to move a business-critical server, which hosted the transactional part of the corporate website, from a secure data center to under his desk because, and I quote, “My legs are getting tired walking to and from the server room.” I hope you’ll agree that this wasn’t an acceptable reason for a change. So to be better at change assessment, we don’t just want to know why we want to do a change, we also need to know how it will benefit the business.
The systems/services/groups/users affected by the change. In order to let your stakeholders know that they won’t be able to access something, or if there is a risk-involving change proposed, you need to know whose IT and business services and operations will be affected by a change request. Ideally, this information will be driven by your CMDB, as this should give you the most up-to-date and trustworthy information. If you’re unable to use your CMDB for this task, it’s still vitally important to have this impact information available to identify and inform interested parties. You can do this manually using a spreadsheet or you might be able to pull it from your service catalog. The important thing is that you do it.
Risk assessment. What happens if it all goes wrong? In my experience, too many people choose “medium risk” when requesting a change because they either don’t know, or don’t care, what the risk actually is. There really is no excuse for this and I suggest using a change management risk matrix in your organization, like this example, so that change requesters can select a tangible, meaningful level of risk that’s appropriate for the work being carried out. This also gives the change assessor(s) added peace of mind that the risk category hasn’t been chosen at random.
Well, that’s it for Part 1. I’ll return with Part 2 to cover implementation planning, post-implementation testing, back-out plans, and more. In the meantime I’d love to hear any change assessment advice you can share.