When I think of “Change Programmes” I am thinking of the scenario where an organization decided something must change. Someone - consultants, managers, senior folk - decide what need sot change and how, e.g. introduce a new IT system, change the business processes, etc. - and then set about making it happen.
From time to time I run across articles online, in blogs and in prints journals and books which address the question like:
- how to you motivate people to change?
- how do you overcome resistance to change?
- why do so many change projects fail?
- why do people resist change?
This is a problem many IT projects of all shapes and sizes face at times. Its also a problem faced within IT when Managers want to change the way the team works.
I don’t believe people resist change. I think people, for Workers are always People, are happy to embrace change when they see the advantage, when they have choice and when they are involved actively in the change.
For example: many people are only too happy to get a new mobile phone when their supplier tells them they can have a free upgrade.
Change problems only exist when one group of people want to impose change on another group. Its not resistance to change, its it resistance to being changed. Been told what to do differently.
As long as one group of people think they know best and try to impose change on another group people will continue resist change, articles like I mention above will continue to be written and change initiatives will continue to fail.
The solution is to change the way you deal with the problem. Those who want change need to involve those who need to change. If you are a Manager who wants a team to improve their performance then ask team what they could do to improve. Ask the team what they would do differently. Take the teams ideas and help the team turn them into action.
If you are an IT expert charged with delivering a new IT system - to support business change or otherwise - then ask the people who will use the new system what it should do, give them demonstrations as the system developers, ask their opinion, deploy the system early and incorporate the feedback of the Workers.
I’m not saying you ignore long term issues, strategy, corporate objectives and such. Tell your Workers about these things and harness their ideas. Integrate the ideas and goals into a shared understanding.
This advice applies to all change initiatives and all IT change projects. (My “Agile approach to BPM” entry a few weeks ago put this in the context of Agile and BPM.)
Too often companies use IT as a blunt instrument to impose a change in process, behavior and working practices. I sometimes imagine it as a dice game. Faced with imagined resistance to change and complex systems Managers commission an IT projects in the hope that it will create change. They grab the dice - very expensive dice I should say - and roll them in the hope that they will roll a six and win.
Surely we can do better and move beyond luck for success.