We love changes, if they are for the better. But Change Management is still arguably the ITIL-process that causes most people on a project the most problems. But these problems can easily be avoided! Asking these four questions before you implement Change will make it easier.
1. What exactly is a Change?
The start of any Change Management project is the most critical opportunity for things to go wrong. You will find that different people have VERY different ideas about what a Change should be and how it should be treated.
If everybody isn’t clear—or worse, disagrees—about what a change is from day 1, you’ll kick yourself if things go south later on, because all you had to do was say ‘Does everybody know what a change is?’ in that first meeting.
Not that I have a problem with ITIL, but to pre-empt questions along the lines of ‘ITIL clearly defines changes and the change management process…’, I refer to my previous blog post. And I also want to point out that not everyone in your meeting will know everything about ITIL, or what Change implies.
2. Why is this Change necessary?
Before you even start any kind of project involving Change Management, ask "Why is this change necessary?". If you can’t answer this question, that never bodes well for the prospects of success.
For some projects, all that’s required is that anything that's not an incident or a problem goes through the change process so that there’s a record of everything else you’ve done. This is useful to demonstrate to management that you do other stuff than just put out fires. More sophisticated projects will be looking to incorporate process to prevent Incidents from happening in the first place, or focus on additonal reporting, streamlining of standard requests, etc.
Understanding the reason for the Change is instrumental to being able to cope with any resitance you face towards it. If you want more tips on overcoming resistance to Change, check this post out.
3. What do we need from the process?
Save yourself time from getting bogged-down in endless logging of ultimately irrelevant data by setting clear goals.
For example, if you want change requests to be submitted through a form, don’t ask a million questions that don't give relevant answers. Make sure the answer to every question will actually be insightful and helpful to the process, or you’re frankly just wasting everybody’s time. My colleague Sam wrote more on this topic over here.
If everyone knows what you are doing and why you are doing it, no one will waste time measuring things you don't need, or working on unneccesary parts of the process. The end-goal should be a successful implementation that makes everyones work life easier.
4. Do we all agree on the Change Management process?
If you come into a project involving Change halfway through, you can be forgiven for not really knowing what’s going on. This is because, at this stage, the rest of the project team probably also has no idea what’s going on.
Make sure everyone is starting off on the same page, and keep everyone on that page. Stick to your plan - and let everyone know if you have to deviate from it.
Good planning an some serious documentation helps. And leadership. Your Change Manager should be concerned not only with that everyone involved in the project knows what's going on, but also that all stakeholders (including management and users) are aware of the Change, what it implies and if any processes change on their end.
You can have a look at our checklist items for Change Managers if you want some more tips on this.