Five lessons learned implementing ITIL Change Management

 Here are my top 5 lessons learned implementing ITIL Change Management that will save you endless heartache.

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.Lessons Learned Implementing ITIL Change Management


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.

You might also be interested in How to Measure a Basic ITIL Change Management Process, and How to Mature a Basic ITIL Change Management Process.

Your Turn!

I’d love to hear the unique challenges you’ve faced with Change Management. What are your lessons  learned implementing ITIL Change Management?

 Image Credit



  • Pingback: How to Implement Basic ITIL Change Management()

  • Pingback: What is ITIL CAB? A Simple Explanation.()

  • Pingback: Help! I've been asked to implement IT Change Management. What do I do?()

  • Vijay

    Hi Greg,
    Thanks a lot for the above post which is very helpful. I am currently implementing change process for IT dept of a govt org. Though I have operational experience, implementation is something new to me & bit of daunting. Did not have clear idea where to start or what to focus. Your post gives me a good insight especially the point 3 & 5. I will continue to read the blog & get benefited.

    But in the mean time, I hope you don’t mind me asking a Qn. I heard someone mentioning about SLA for changes. SLA for change requests? Are they referring to the concept of lead times or is it some kind of agreement from Change Management process to rest of the operations stating they will action on a change within defined time frame? Hope you can share your insights.


    • Vijay,

      Thanks for stopping by. Nice when others can benefit from hard-learned lessons.

      SLA for Change Management, though not unheard of, is hard one. Basic Change Management is often very operational focused – where CAB is engaged only as the last-check before a Change is being implemented. If that’s the case, an SLA most likely is about how quickly and accurately Change Management implements a change that is thought to be fully complete, and just waiting for operational approval.

      But as Change Management matures, it is engaged at the beginning of changes, and oversees a change from idea, through development and implementation, where end-to-end time is very dependant on the type and complexity of the Change.

      A couple articles that you may find helpful:

      I hope you’ll check back in and let us know how you’re doing.

  • Pingback: What's the Difference Between Standard and Normal Changes in ITIL?()

  • Clayt

    When you delegate authority the old adage give them an inch and they take a foot seems to come into play. All changes can become minor changes . How do you validate the authority and that changes are correctly catregorized and appropiately reviewed.

    • Talk about getting right to the heart of the matter!

      You’re spot on. This is a huge challenge for Change Management. It’s a catch 22 – if you don’t delegate, you hamstring the organization with bureaucracy. If you over delegate, you potentially loose control.

      Key in delegated authority is clarity in ownership and accountability. You know how in a RACI chart, there can only be one A (accountable)? That’s the Change Manager, who is ultimately accountable for effectively managing change – both in it’s ability to manage risk and impact avoidance, and also the time to value of business-required changes.

      Change authority is delegated, not abdicated. The Change process should have effective oversight over delegated change authority, and make adjustments as needed.

      In practice, Change Management could impose a temporary requirement that RFCs come to the next higher level for approval in response to failed changes or business impact from the delegated authority.

      Conversely, if RFCs coming from a particular area have a good track record, the Change Manager should consider delegating change authority lower.

      The challenge, of course, is there’s no ‘right answer’. The right answer is highly dependent on business requirements, the infrastructure, and the culture.

  • Allwin Bangera

    Hi Greg,

    I really liked the way you explain. Would you mind answering my below questions, which I am unable to answer myself please:

    1. As per your experience how many approval a Change process flow should have and which are those?
    2. I am facing difficulty in handling engineers, who does not give importance to Change Management flow, any advise will be helpful to deal with such people.
    3. If the implementor Implements the change and misses a step and client escalates even after signing UAT, can you please guide how to handle such situation.
    4. Please suggest some books to develop my ITIL Change and Release Management knowledge. Currently I am reading books if Larry Klosterboer – Implementing ITIL Change & Release Management.