Persuasion and Perception

Every year, between forty and seventy percent of all corporations and public sector bodies attempt to make strategic change. Overwhelmingly, formal projects are the preferred structure used to organise such effort, regardless of whether the underlying goals are defined in terms of business process re-engineering (BPR), technology upgrades, mergers and acquisitions, due diligence or similar concepts.

Each organisation starts with a desire to make itself better. But "better" is a slippery concept. Certainly projects bring about change, but do they necessarily make things better? Better in the board room might mean lower costs through reduced head count, but would the rest of the team agree? Perspective matters.
In the absence of personal control of events, everybody hates change. A failure to remember this fundamental insight is the root cause of a great many failed projects. Sophisticated communication strategies and planning models may impress project owners, but these tools will not persuade a hostile group of users or stakeholders that a new project will improve their lot in life; certainly not when their instincts and reflexes are telling them to resist.

This resistance may manifest as scepticism of the projects aims or an unwillingness to contribute, but the diametric opposite is also common - those affected may leap in with enthusiasm to suggest, amend and discuss all aspects of the proposed change. While this may seem productive, and there may be no conscious efforts at sabotage, the underlying desire is to minimise the threat of the unknown; to control it, and thus to make it familiar.
Multiply this process by the number of people affected by a project and the net result is a myriad of different requests, memos, change notes, delays, clarifications, amendments to minutes, design reviews, audits, strategy seminars, away days, planning meetings and other artefacts of partial control. A further difficulty arises since stakeholders are not necessarily customers. The difference is simple, if money changes hands, it's a supplier-customer relationship; everyone else is a stakeholder. Stakeholders may be in a position to influence requirements and outcomes, but they don't have a direct financial interest in the project. And there's no money as easily wasted as other people's money.
Paradoxically then, although many project managers are criticised for failing to engage with their customers, there is just as much trouble to be found by too much engagement. A tricky situation...
What strategies are available to counter these problems, then? Very few project managers have the authority to forego persuasion on those affected by projects, and compel the wider organisation, and yet persuasion is not enough. There are also plenty of problems with a more autocratic style of leadership.
As project managers, we need a way to provide those on the receiving end of a project with a degree of control, without sacrificing the momentum of the project. And this is not as difficult as it might sound, as long as the project is properly structured and - of course - as long as you stay pragmatic. There are two simple, core methods.
The first method is to consider how to minimise the psychological impact of change. The single most effective technique for achieving this is to introduce a number of small, symbolic, changes early in the project and use these as a mechanism to create a perception of ownership, and thus the perception of personal control.
I say "perception of personal control," but a more cynical observer might call it the "illusion of personal control." They are not synonymous, though, since the underlying purpose of guiding perception is not to manipulate, but rather to encourage project stakeholders to focus on the benefits they will gain from a project; not the short term problems they will face on the path to improvement. This technique gels well with other pragmatic project management techniques- early prototyping, user evaluation and feedback. The only caveat is that such user involvement is structured and leads to a positive outcome.
The alternative is to present the stakeholders of a project with so much change that they are faced with an unpalatable challenge to their existing ways of working. This could be considered as offering total liberty to those most affected by the project. But in fact, it can be demonstrated that the outcome is to overwhelm them with choice. Remember, in the absence of personal control, everybody hates change.
The second method is to manage expectations, by controlling the release of change. Release management is a familiar discipline to anyone working in software engineering, and the related field of configuration management is an integral part of the physical engineering disciplines. The same methods - even the same processes - can be applied to change - specifically to the presentation and handover of project deliverables.
A crucial point in expectations management is to limit the magnitude of your promises. By their nature projects involve risk and uncertainty. After all, if you were doing something routine and predictable, why go to all the effort of creating a project? So accept that things will go wrong, and that consequently until you have objective evidence that your supply chain and team can perform, you are not helping the stakeholders by offering a fantasy instead of cold, unpleasant reality.
Try these techniques the next time you want to you want to make a change to your organisation. But always ask yourself, "Is this a change for the better, or change for change's sake?"
James M. Barlow is an IT Consultant based in the UK, with a successful career spanning two decades in the private and public sectors.