...focus their attention on selling the project to staff who are likely to support it.
But writing off the naysayers is a mistake as it can end up entrenching their opposition, and risks them poisoning the minds of other or creating rifts within a department. And if you can win over a project's most vehement critics then their change of heart is likely to go a long way towards convincing other staff about its benefits.
Become a storyteller
The idea of sharing information and beliefs by creating myths and telling stories is older than civilisation. And while tall tales might seem to have little place in an IT department - a myth can be exactly what an IT change team needs to inspire them to go the extra mile during a change programme.
Benson tells the story of how a lone member of staff, named John, saved the day by taking it upon himself to stay up all night fixing the tape back-up the day before the storage area network was accidentally wiped. Not only did John save the customer and order data but he passed into legend. From that point on the team would regularly ask themselves 'What would John do?' when faced with a dilemma that required them to go beyond the call of duty.
Look out for 'change' burnouts
Changing working practices can both unsettle and stress staff. Keep an eye out for telltale signs that a member of staff is not coping with the upset, looking out for signs such as poor timekeeping, less socialising with the team, less enthusiasm for the job and even subtle clues such as a change in the tone of their emails. Try and benchmark staff's behavioural patterns to monitor for these changes in behaviour.
These shifts in behaviour are indications that change is happening too rapidly for that individual, leading to them getting stressed out or losing belief in themselves.
Avoid the big bang approach
It is far easier to measure the success of a change programme when business processes are changed a few at a time, rather than every business process being altered at the same time.
Carrying out changes in steps will allow you to see what's working and what isn't. Trying to judge the success of a programme where every process has been altered can become difficult because it is tricky to pinpoint what each process change has achieved.
Beware of the pendulum effect
In attempting to correct the drawbacks of an existing way of working businesses will often implement change programmes that overcompensate and swing too far the other way. Take IT: an attempt to move away from a heavily documented development approach to an agile approach can result in an anarchic development process. Similarly a move towards more process driven development from agile could result in an overly bureaucratic, top down way of working.
Be aware of this tendency for change programmes to swing from one approach to its polar opposite and try to settle the destination of the programme somewhere between the two extremes. It normally takes at least two or three iterations of process change to end up at this happy medium.
Don't expect to do everything at once
Break down the change programme into stages or iterations rather than attempting to implement the entire programme in one go.
Expect that it will take several iterations to achieve the goals of the change programme.
Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.