It’s a common refrain: the hardest part of any IT-enabled change project is not managing the technology, it’s persuading the people.

Recalcitrant staff who resist change or employees whose productivity falls off a cliff when faced with new working practices can derail change programmes and drag projects into delay and overspend.

Graham Benson, HR and IT director at online clothing retailer M&M Direct has managed business change programmes throughout much of his career, which includes senior IT management roles at Avis, online entertainment retailer Play.com and DIY outfit Screwfix Direct.

For Benson, running a successful change programme is just as dependent on knowing how to handle people as it is on getting the technology right. Here are his top 10 tips for keeping people on side when an organisation runs a change programme, shared at The CIO Event conference in Wales this week.

Head off mutiny

Don’t compromise when picking the team who will work with you to deliver a change project.

Change tends to be a painful process, and while it’s easy for a team to paper over the cracks when things are going well. When things go wrong it really tests that group’s mettle. If the team’s skillset or relationship is not strong enough to weather setbacks, then the results can be quite destructive.

Military recruiters ask themselves ‘Would you trust this person enough to put your life in their hands?’. Similarly, in the world of business, the question that change programme managers should be asking is ‘Would you trust the success of your enterprise, project or team to that person?’. If you can’t answer ‘Yes’, then you shouldn’t be entering into the project with that person.

Staff

Successful business change is often reliant on keeping staff onsidePhoto: Shutterstock

Communicate but don’t vacillate

Make a point of telling those people affected by change how it will impact them, and do it by talking to them. Don’t try and fudge the communication using half-measures like sending memos as these can be misunderstood or missed altogether.

However, while it is important to be clear with staff about the changes and to allow them to express their views, don’t try to accommodate everybody’s point of view. Better to bear the general view in mind while delivering the project as planned, rather than reshaping the project in an attempt to satisfy everyone.

What’s in it for me?

Self-interest is a powerful motivator. As nice as it is to think that staff will be won over by a well-argued and reasonable thesis on why change is needed, they are far more likely to be persuaded if you can tell them how the changes will benefit them.

If you are selling change then you have to tell people why they want to buy it.

Don’t rubbish the past

Marching into a department and telling staff that things need to change because everything they’ve done up to that point has been crap is not going to win you any supporters.

Be very careful when highlighting why the current ways of working are wrong because staff can take it as a personal attack on their past performance. Such an approach can trigger negativity and resistance to change.

Embrace the naysayers

During any change project there will usually be a few people who will dig their heels in and resist what is being proposed. Faced with such negativity the temptation for the manager is to…

…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.