I’ve previously written an “IT service management (ITSM) Basics” blog on change management that covers what it is, but I thought it’d be a good idea to talk about how to take the next step from understanding the principles to actively benefiting from the process. So how do you get started?
Well, there’s a lot of information out there including the ITIL books, free information on the internet (I highly recommend Stuart Rance’s blogs “What Is Change Management For?” and “Defining Metrics for Change Management” as well as Sarah Lahav’s blog “Should Change Management Be That Difficult?” and I’m not just calling it out because she’s my boss), and the distillation of previous customer success stories from your service desk or ITSM tool provider.
But sometimes you can be given too much information. So let me try to break it down for you.
So What Should You Bear In Mind When Getting Started With Change Management?
Firstly, keep in mind that, in simple English, change management is all about knowing what needs to change and why, approving and prioritizing the changes, and then ensuring that changes are quickly deployed with risk optimally managed (you can see all the official definitions in my previous blog here).
Now, I’d like to offer you my tips and things to consider when getting started:
1. Ensure that everyone who will be impacted by change management knows what it is and why it is needed.
Consider and communicate why you are doing, or wanting to do it, and maybe even what change is, as per Greg Sanker’s blog “We Need to Talk…about Change Management.” This might include what change management will accomplish for different stakeholder groups. If your answer is “to absolutely prevent all change-related incidents” then you are probably going to design and implement a process that slows down change so much that people start to circumvent it. Please don’t try to “sell” change management per se, instead sell positive business outcomes (which are of course the result of effective change management). Your business stakeholders aren’t interested in what you “do” – they’re only interested in what you achieve. And that’s business-level rather than IT-level achievements.
2. Don’t just blindly start to do it.
Don’t do it because you’re told to do it or because it “seems like a good thing to do.” Instead, start because you need to – with an understanding that the real need is external, i.e. business affecting, rather than internal to the IT department. Starting change management purely because you’re told to or because it “seems like a good thing to do” will probably result in little more than the adoption of a new (or now formalized) process and little by way of justification when people start to question why change management is slowing down business operations.
3. Get universal backing for it.
Don’t just start change management; justify it first (and maybe again and again). Otherwise it’ll probably be a victim of “the senior manager that shouts loudest” or the endless flow of annual IT budget cuts that many corporate IT organizations now face. And again, ensure that you justify it in business terms.
4. Appreciate that your organization is probably already doing some form of change management.
Even if done informally, the IT department will already be delivering some form of change control – they can’t afford not to. They might call it something else but it will be likely that you’re already dealing with a flow of IT-related changes on a daily basis. And when you formalize change management, don’t automatically ditch what you currently do in a rip-and-replace manner by copying the new change management process from the ITIL books. Much of the current activity can probably still be used to support the new, formalized change management capability.
5. Start small, stay focused, and communicate successes.
Ideally, resources should be focused on a small, prioritized set of initial changes, with change management activity ramped up as successes are achieved. And it doesn’t have to be expensive, as you don’t have to start with a team of change managers and an expensive ITSM tool. Just start with what you think is the best way to handle changes in a manner that best balances risk, time, and costs. You don’t have to deliver perfectly from the get-go; instead, deliver good and improve it to great. It’s important, however, to ensure that the respective roles and responsibilities in the change management process are understood and agreed to.
6. Ensure that you take an end-to-end view of change management.
Firstly, don’t confuse change management with a simple “request for change (RFC) submission” process – it’s about so much more than just filling out a form with the required information and variables. Instead, it will need to encompass steps such as: initial assessment of RFCs; RFC filtering; change assessment by the change advisory board (CAB) if appropriate; change scheduling and build authorization; change deployment authorization; and post implementation review (PIR) and change closure. Plus, of course, then there are all the elements of the release and deployment process to consider alongside change management.
7. Be prepared for the “unexpected” issues that can arise.
Learn from the experiences of others and anticipate and plan for them. These are the types of things that conversations with a handful of peers at different companies will bring to light. And don’t expect your people to automatically know how to “do” change management either. Educate and train people, bringing in advisory resources as needed.
So that’s the first seven of my 15 tips for getting started. Please return here in the not too distant future to learn what the remaining eight are.