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 a forwardly agreed scope; 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 and 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:
- Ensure that the vision we are trying to create is complete and realizable
- Have the new processes documented at a level the layman can understand – avoid jargon
- Embark on a face-to-face campaign of articulating why the changes are being made with particular attention to the benefits
- Form a working group of stakeholders to discuss the changes and the plans
- Advertise myself as an arbiter and negotiator for the changes whilst we deal with exceptions to the process
- Ensure adequate time and resource has been allocated to complex changes that affect people and systems
- Facilitate discussion between teams to avoid conflict and encourage negotiation and problem-solving
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’.