Here are my top 5 lessons learned implementing IT Change Management that will save you endless heartache.
Having recently implemented a Basic IT Change Management Process, I’m sometimes asked about lessons learned implementing IT 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 allowed 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 IT Operations in general, and IT 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. Acknowledge things that are working – it’s neither the name or form of the capability that matters – it’s the outcomes (in this case, changes are well managed) that matters!
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.
You might also be interested in How to Measure a Basic IT Change Management Process, and How to Mature a Basic IT Change Management Process.
I’d love to hear the unique challenges you’ve faced with Change Management. What are your lessons learned implementing Change Management?