Not so long ago, I presented a webinar on change managementcalled Never Underestimate the Importance of Change Management. Normally webinars are a lonely alternative to conventional seminars, because instead of looking at faces of real people, during the webinar it’s just you and a telephone and the hope of people out in cyberspace listening.

This time though, with good responses to our three polling questions (that’s another whole very interesting blog coming soon) and lots of questions from the listeners, I felt much less alone. The only downside though was that there wasn’t time to answer all of the listeners’ questions, hence this blog.

Most of the questions call for the traditional consultant’s first response: “It depends”; and this deserves attention in its own right. Best practice is about documenting approaches that seem to have worked for someone – be they best practices about IT service management (ITSM), cooking, or anything else. Whether they’ll work exactly like that for you depends on how matched your situation and circumstances are to those where the best practices initially succeeded.

Add in the wide variation in pressures and constraints that face different organizations and you see the limitations of a generic answer. I wrote about that recently here so I won’t go on about it again; instead let’s dive into those questions now. Please note that some answers could be an entire blog on their own, but I will be as brief as I can here to fit everything in.

Question: “I’m about to develop a change management policy for the department because I have realized that when other techs make changes on the environment, they do not document changes and it is very difficult to backtrack on changes that were made. How do I drive the point home that we need to have a policy in place and it is imperative that it needs to be followed?”

My answer: Anyone making changes needs to document what they are changing. Unless you have a perfect memory, and are immortal, there is a need for reference documentation. Not just in case it goes wrong, but for re-use if it goes right. In terms of getting a policy in place and adopted, the most powerful message I know is to determine, document, and present the damage that has been caused by NOT doing this over the last 12 months or so. Look back on incidents, errors, and especially business impact caused. Try and set financial costs for them and show that it’ll happen again next year unless a more sensible policy is adopted.

Question: “With standard changes (or as we call them routine changes), do they always need to be reported, or do you approve the ability to make those changes, and allow them to make those changes without having to report those changes every time they make them (especially for daily changes)?”

My answer: Yes, see above 🙂 – it’s like capturing events where most of what you capture won’t be used but you don’t know which bits you will need later. Be sensible – capture essentials and don’t waste resources capturing excessive detail. Much of the data for this kind of ‘safe’ change can be what I call ‘attic data’. You need to be sure it is still there if you ever need it. Like those things you keep in your attic in case you ever need them but don’t have around all the time.

Question: “My organization does IT application changes. Should we have two approval processes? That is, one before the change is actually developed, and then the Change Approval Board Review after it is developed?”

My answer: You can call it two approval processes that are connected or you can call it one that integrates what you need to do; just make sure the right people are asked, and answer, the right question at each stage. I’d say it was one process but a more important question I would ask is ”does your current situation work?” If it does, don’t change too much. In fact, the normal change process in the ITIL ST book encourages multi-point approvals through the process.

Question: “How would you apply change management to a practical area, for example, changing out a network switch?”

My answer: Again it depends on context; but assuming you trust your network team, then you empower them to make change under standard change procedure. They document it in such a way that problem management would spot it as a cause should it generate unwanted symptoms later.

Question: “How do you change the expectation of an environment that has become comfortable with disappointment in change?”

My answer: This question certainly warrants a whole blog to address properly. Quick response for now: show them what it could be like, pick a customer, run their changes right, write it up, publicize it, make the rest of your customers jealous. But be prepared to deliver against any promises you make, or you could just make things even worse.

3 Questions: “Do you have guidance on the appropriate level of change management to introduce into an organization that is growing from a startup into an enterprise size (400+ users, 250+ production systems)?”
“What is your perspective on how many changes to “bulk” into a single release package”
“IT CM is often perceived as an obstacle, too much paperwork. What is the right balance between process controls and process efficiency / agility?”

My answer: The answers to these questions really do depend on the actual situation, circumstances, and constraints of the organization. It’d be nice to come and see the situation and offer targeted advice. But for now, the answer really is ‘it depends’ – on frequency and scope of changes, security, success rates, business criticality, customer and staff expectations and abilities, and much more! First place I would go to get trusted opinions are to the people doing the job now.

Question: “Change Management in my previous company became very bureaucratic. Have you seen this and how do you think this can be avoided?”

My answer: Yes, it is very common. The answer is to embrace standard change, establish who you can trust, and trust them. Take some risks – falling into bureaucracy will likely stop the organization progressing more than a few failed changes.

Question: “What should be some ground rules for denying a change, particularly if we know that IT is not ready, yet business is pushing with urgency?”

My answer: Discuss damage! Establish what the likely damage would be if you went forward with the change. That is, presumably, your reason for not wanting to do it. If you are getting pressured to do the change anyway, despite the expected damage, then make those requiring it sign off and formally accept the risks you set out.

Question: “What do you think is the first step to prepare an organization for ITSM change management? What is your best tip to an organization to start from zero again?”

My answer: Start where you will make a difference. Focus as a first step on the kind of changes that have been causing the most trouble and/or causing the most damage recently.

Question: “How do you deal with change management when management is secretive and does not give you the full picture?”

My answer: This is another question that could inspire me to write a whole blog! Very few of us have the whole picture, even if we think we do. Establish what you do and what you don’t know. Make the best decisions you can. Document the damage caused by decisions that were not optimal because management withheld information. Let management know the damage they are causing.

Thanks to all those who sent in questions, and if you have more questions, follow-ups, or want to disagree with what I have said, then please respond to this blog, or find me on Twitter.