The Dog That Doesn't Bark

Change is about hearts and minds. Most advice focuses on the heart - but we need to address the mind if we are to address the rational causes of resistance and make it work.

An axiom of much change management advice is that people resist change. Regardless of how true this is in general, in business many of the problems of change are laid at the door of people resisting the change.

This in turn has created a mini-industry of change-management professionals offering advice almost all of which is concerned with overcoming resistance. Workshops, town hall meetings, posters, stakeholder management, mugs, force-field analysis and a whole panoply of consultant jargon, academic theorising and a panoply of tools, instruments and methods to 'engage people', 'secure buy-in' and 'obtain senior management commitment'.

And almost all of it barking up the wrong tree.

The issue is not overcoming resistance. It's about understanding the causes of resistance and removing them.

Most of the time, people resist change because the work environment in which they find themselves makes resistance a reasonable response to change. In other words, they resist change because the business environment encourages them to do so.

To give a simple example: if, say, we want middle managers to use a central recruiting process rather than go to their own local network of recruiters, then we will see rational resistance if the new process compared with current local practice is slower, more cumbersome, less flexible, has higher impact on local budgets, is less trustworthy or reduces the manager's choice over whom they hire. If I am locally measured on these things, reducing my ability to meet these metrics will, of course, increase my resistance.

No amount of persuasion, engagement or group working will change this logic. To change the logic, we need to change those aspects of the work environment that make resistance a correct and rational position.

So: if you want to make change happen (rather than talk to people about change), here are a few things to consider. Identify three or four places in the workflow of your new way of working where the quality of the process is visible.

Now change the environment round these three or four places by implementing answers to questions like these. What triggers the new way of working? What is in place to make it easy, practical, quick and aligned with relevant local metrics? What standards of performance are expected? What information do people get in real time about how well they are doing - and who notices?

Have the business put in place specific actions to reduce specific causes of resistance, real-time, in key places, as people work in the new ways. (And conversely, put in place things to make working the old ways harder).

Don't overanalyse, don't try to change everything (as I said, three or four places only) and don't work too hard to secure 'buy-in'. Try making operational changes quickly and seeing what works in terms of performance. When things work, the performance changes. 'Acceptance' is secondary.

You should find quite quickly a cluster of focused specific work environment changes that lead to people working differently. Document these and implement them pragmatically if you need to to roll the change out further.

While efforts to overcome resistance through persuasion, communication and engagement are good things, experience - and logic - show that you will get a better outcome if you adjust the work environment instead: this is the dog that doesn't bark.

- Mike

Beaming like a baby

Communication can kill your project.

I was at a client's project washup session (a 'post-implementation review' in the jargon) a while ago where we were to review a project to relocate a couple of call centres.

The project, to put it politely, had been going to hell in a handbasket. The client asked me to help when the project was already seriously derailed.

We got it back on course, and delivered much of what was wanted, not too late, and without doing too much damage to an already stretched budget.

Even so, very few were looking forward to the session. Three hours of reports of limited success, powerpoint presentations on 'things we should have done earlier/better/faster', flipcharts full of 'learnings for next time' - a steady stream of formal self-flagellation, almost like a Maoist re-education session. What could be more exciting :-( ?

The only person smiling was the representative from the communications ('comms') team. By luck or judgement, he went first. He presented a set of (beautifully prepared) slides showing us the comms plan, how they had delivered against it (largely on time and under budget, unlike almost every other part of the project) and then he revealed his coup de grace - the project comms team had been shortlisted for the final of a national competition run by a trade magazine. He sat down, beaming like a baby, newly fed.

His bubble was only slightly burst when John, the project manager, commented, “I wonder why the communications team keeps winning awards, while the projects they work on don’t?”

And I was struck by a blinding flash of the obvious.

Of course the communications team were winning the awards – because, for them, their job was delivery of defined communications, not the delivery of the project. When we reviewed the communications plan in the project each week, we were reviewing communications activity, not whether the communication was successful in helping the project meet its goals. Mugs and posters (not like these) and 'plenary sessions' were all very well, but very little of this directly affected what was delivered on the ground.

Suddenly other things fell into place. A key frustration during the project was that it had been very tough to brief delivery teams and stakeholders directly. The reason? We had to comply with our communications team policy that our messages 'were consistent’ and that ‘the seniors had been briefed’ before we could discuss the project with others. This in turn delayed project work as we waited for ‘communications’.

Worse, because the comms team moderated communications from the middle, and not on the ground, much of what they did communicate was too general to be relevant to those doing the work. As the project delivery teams did not understand what was needed - in terms that mattered to them - much of the work they did needed to be redone. No wonder (as we found when we completed the washup) the single biggest issue affecting the project was 'communication'.

All the communication activity in the comms plan and in our policies was actually damaging the project – because it was preventing effective communication.

The project team had abdicated responsibility for communication to the communications machine – just when we needed to be able to explain to our project people, in practical, day-to-day terms, what we needed them to do.

I have seen this behaviour before in a number of my clients and it explains a lot. The logic of giving communications to a specialist overwhelms the common sense notion of enabling folks on the ground to communicate quickly and easily with each other to get the work done.

'Communication' can fill your project’s pockets with lead weights and send it for a swim straight to the bottom.

Remember, communication is no substitute for conversation.

- Mike