Five lessons learned implementing ITIL Change Management
Having recently implemented a Basic ITIL Change Management Process, I’m sometimes asked about lessons learned implementing ITIL Change Management. – What would I do differently.
Here’s the top 5, in no particular order:
1. Communicate, Communicate, Communicate
Change Management effects pretty much everyone. Just because you understand what we’re doing and why does not mean staff will understand. It’s hard for staff to ‘get on board’ for something they haven’t had the chance to hear and understand.
Start communicating right at the beginning – “We are starting to develop a Change Management program to more rapidly meet business needs while minimizing risk of business impact.” Be clear about the business value, and communicate it early and often.
Connect with key business stakeholders. Speak in their language. Talk about how Change Management will give them more of what they want (better, faster, cheaper), and less of what they don’t (downtime, rework, increased costs)
If people don’t know what you’re doing, (and worse, why) – they will make up their own narrative… and it probably won’t bet the one you’d like.
Depending on the culture – communicate through multiple means (email, blogs, flyers, etc), but especially face to face informal conversations. Anything you can do to reduce anxiety and FUD (Fear, Uncertainty, Doubt) before The Story is cast in cultural stone.
Trust me, it’s much harder to re-cast the story once the die is cast. Control the message
2. Understand More, Implement Less
Example: I unwittingly used the category of “Standard” to describe non-emergency changes. We didn’t have any Standard, pre-approved changes. We’re now working on version two, and we need to recover/redefine ‘Standard’ to mean just this. It would have been much easier to use the terms correctly from the beginning.
In the early stage of planning your Change Management program, learn everything you can about Service Transition in general, and Change Management in particular. Seek to understand the big picture, and be completely convinced of the business value of Change Management.
Do yourself a favor and don’t assume you know how it should work. Immerse yourself in all things Change Management. Learn from those who are doing it, and don’t assume that they are fanatical because they are doing things you don’t (yet) understand.
If you understand just enough when you begin implementing Change Management, you are likely to do things that you’ll later regret, or that make the next iteration harder. Think about how Change Management will fit with other processes to be implemented later – Configuration Management, Release and Deployment, etc.
Once you have a solid understanding, implement far less than you understand. It’s very tempting to do more. Don’t fall for it. Better to be successful with a small program, and make incremental changes forward.
3. Embrace Existing Processes where it makes sense
Example: When I started Change Management in my organization, there was little evidence of any formal Change Management. I accepted a prior external assessment that rated the organization a zero for Change Management.
It took months for me to realize that many of the fundamentals of Change Management were being done, just in isolated, informal processes. As time went on, I had to extend trust to embrace the best of those process, while getting the benefit of a single, visible Change Advisory Board (CAB).
Not understanding and acknowledging existing processes caused unnecessary insult and hit to morale.
It’s extremely rare for an IT organization to have NO Change Management practices. It is very common for those processes to be informal and undocumented. Take the time to understand how Change is really done. Just because there’s not a CAB, doesn’t (necessarily) mean there’s no Change Management.
Leverage existing practices unless they are completely whack. And by ‘whack’ I mean – they’re not producing value for the business. If they are effectively facilitating Changes, assessing and mitigating risk of negative impact, embrace them.
I know this sounds very un-ITIL-ish, but if you have aspirations for a broader Service Management program, you are in for a marathon, and you need to get people on board. Look for the bright spots. Acknowledge things that are working.
4. Establish Change Authority and Delegate Smaller Changes
Example: I implemented Change Management primarily as a stop-the-bleeding effort. We had had some major failures related to Un-managed Changes. Everything was brought to CAB. We spent as much time reviewing very minor changes as we did major implementations.
Staff saw the disconnect, and felt the “whole CAB thing” was an unnecessary bureaucratic process with little real value. Buy-in was low, and it took much longer to implement.
This is perhaps the biggest lesson learned. Establishing a Delegated Change Authority model seemed overly complex to start with, but treating all Changes the same was more damaging.
Take the time to understand the spectrum of changes in the organization. Make intentional decisions about which present the highest risk, and focus CAB on them.
For lower risk changes, empower technical team managers to approve Changes. Development Manager for application changes, Network Operations for network, etc.
Make sure you document and communicate who is responsible for approving which changes.
5. Focus More on Relationships (and less about process)
Example: I was focused on reducing avoidable negative business impact, and didn’t invest enough in relationships. Staff became overly sensitive when CAB asked basic questions. Morale suffered, and CAB became a chore for staff.
Motivated, engaged staff are critical to effective Change Management. CAB needs to be a place people want to be.
Invest the time to get key thought leaders on board. Attend staff meetings, take people to coffee. Build relationships.
Acknowledge the work staff do, ask how to make Change work better for them. Incorporate as many of their ideas as possible.
