A Painful Reminder About Change Management

Perplexed look

Perplexed look

Estimated reading time: 3 mins

When you’re headlong into a programme of work which requires significant process change, it is so easy to forget about the people the processes have an effect on. I’ve just realized this to my dispeasure!

Right now I am involved in a programme of working changing IT delivery processes, that covers the standard ITIL approach of Release Management. My team have been working on a number of changes to tighten up the way we release changes into a technology platform, and we’ve been engineering new processes like crazy – all towards best practice and the avoidance of failure. Things like scheduling regular release slots with agreed scope in advance; avoidance of conflicting code bases; reduction of unplanned releases. In the assumption we were doing the right thing, we’ve been pushing their implementation and adoption.

But what I’d forgotten is to make sure other teams affected were with us on the change, and that they knew the why as well as the what. I’ve not done this. And it took an independent person to remind me. The result is that I am now faced with disgruntled colleagues who are confused about why we are making the changes and are resistant, of a sort, to adopting them. ‘The old way was better’ I hear, and justifiably too, now that I have an awareness of the situation and how it is perceived.

What I had done is to ignore Change Management. Change Management, done well, gives people who are affected by a change, i.e. the stakeholders, an opportunity to buy into the changes and to challenge them. It is about creating the awareness in the stakeholders and allow the full change-cycle to happen and progress. Most people resist change, not malisciously. People tend to need time to emotionally accept change and to grasp how the change affects them and to see a way of overcoming it. If there are benefits to the stakeholders, they must be well articulated in order to motivate folks to get through the ‘change bump’.

In my experience, Change Management doesn’t work in total perfection. Leaders who appoint Change Managers also assume that the Change Manager totally buys into the changes themself and has the leadership comptencies to be persuasive, which isn’t always the case. The best Change Managers exhibit Transformational Leadership tendencies. The worst Change Managers are those that have a conflict of interest, where the change affects them personally or professionally and the conflict can’t be managed effectively.

Where I feel I have really shot myself in the foot is recently I wrote about 15 Blunders to Avoid when Implementing BPM. Two of these ‘blunders’ are ‘Ignore your end users’ and ‘Not giving your users adequate support’. This is what I’ve done, because what I’ve been trying to change is a Business Process at the end of the day – eek.

I’m not going to beat myself up though as I’m focusing on fixing the situation. I assume authority for this. If you’re in a similar situation, you should assume authority until told otherwise. I will:

What I’ve written above is really a 101 on Change Management. These are not new discoveries and certainly nothing I haven’t been aware of before or done before. But they are principles in which I seem to have lost because I’ve been so ‘in the thick of it’. I’m not too proud to disclose my pain! And I thought I’d share this experience as a way of hopefully reminding anyone who is involved in process change and the Industrialization of IT that Change Management (not in the ITIL sense) is still an important consideration and vital to progress.

Exit mobile version