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:
- 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’. 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.
Thats an honest account Simon. And I sympathize as I know how easy it is to forget to put ones head above the parapet and look at the situation with fresh eyes. Something similar happened to me with a technical project that upset our whole user base and we had to do some severe recovery work on the relationship before we could progress again!
Simon I am assuming you don’t mean Change Management in the ITIL definition. Sounds like you forgot some basics but maybe when you’re charged with delivery, the Change Management aspects are best done by the client and not the delivery people.
It’s debatable whether CM should be done by the client as it depends on whether the client has the competency. I think this has to be based on the circumstances. Ideally, you’d be right!
Simon, my opinion is from a developer’s point of view so here goes…
A lot of clients had too many processes and procedure that are hampering productivity from a delivery point of view. I was in a situation where if I wanted to change a small thing like “displaying a word in uppercase”, I had to fill in a couple of forms, sit in a telecon with a client as they were overseas based, convince them that the change will not impact anything else and then implement if I’m lucky.
The turnaround time for this process could be anything from 1 week to a couple of months. As a developer, this got extremely frustrating.
Change Management procedures should not be stumbling blocks between IT and Business.