Objections to Change
"All change is not growth, as all movement is not forward." — Ellen Glasgow
It happens when I kick off a project that will alter existing processes. It also happens when I introduce Agile to teams. Whatever the scenario, human beings are creatures of habit, and so when change is brought up, dread, anxiety, and resistance are usually the immediate reaction. The good aspect of this is that not all change should be accepted.
Establishing a rule that all office photocopies have to be documented on a shared document, including number of pages and purpose, is likely to get a lot of pushback. It represents a lack of trust in employees, and creates additional work for them as well. Anyone would be right to argue against such a rule, perhaps advocating for a guidelines quantifying what would be considered excessive use, and asking people to be responsible. Anything but a draconian rule about tracking.
On the other hand, creating a process to facilitate transfer of assets between teams, making the experience faster and more intuitive, should go through collaborative testing and feedback for appropriate revision, but not outright rejection. And yet, such a thing often happens. People get used to their existing systems and the workarounds they invented to deal with faulty software and outdated procedures. Ultimately, unless the workplace is deeply and systemically dysfunctional, the most resistant workers aren't going to get their way, because the needs of the business will prevail.
And yet, they try anyway. Here are the two most common reactions to change that I encounter in the workplace, in the order that I usually hear them.
First, citing history.
"This is how we've always done it!"
You may hear the negative instead:
"We've never done it this way before!"
In my ministry days I encountered the latter fairly frequently, coming from entrenched church people who liked the status quo and just wondered why that wasn't good enough for the people who visited and then never returned. For whatever reason, I hear the former version more often in business circles. Both arguments attempt to stall any efforts toward change.
When working on a project and dealing with people and teams that would be required to prepare and follow a new procedure, it helps to have a mandate. If the business requires the change, whether to improve disaster recovery preparations, migrate to the cloud, or something else, people have the option of doing their jobs as required, or finding something else to do with their lives.
However, the project manager still has to get them on board emotionally, because although you can compel cooperation through a business mandate, that doesn't mean people will give their best efforts to the project. The most effective strategy in the long run is one that sometimes requires a lot of work in the short term, such as holding listening and brainstorming sessions in order to align interests and get everyone — or at least almost everyone — on board.
The second objection I run into, usually following close on the heels of the first one, is citing authority
"This is how <insert manager/director/vp name here> told us to do it!"
Or:
"This is how <insert manager/director/vp name here> wants it done!"
This case can be a little tricky, if what you're trying to do requires buy-in from a superior. Most often, though, this hasn't been an issue for me, because by the time a project reaches me to carry forward, the work of checking in with upper-management has already been done. That is, unless this is a legal or business requirement that overrides the level in question. Then you have to resort to aligning interests, as described in the first point above. In one instance I was told that a certain manager wouldn't be pleased, and I had to inform the team that the directive came from the company board. I'd really not play such 'my boss is bigger than your boss' games at the office. At the end of the day, we all work for the same company and just want to get things done right.
Both of these objections come up in various ways, and of course I've faced them with Agile transformations. I've lead successful implementations of Scrum with teams that knew all about Agile ahead of time and were champing at the bit to get started, as well as with teams that didn't understand what the word 'Agile' meant in the context of working as a team. Most teams have fallen on a range somewhere between those two extremes. The same essential objections and responses are come into play, with the values and virtues of Agile being clearly communicated, so people will understand the benefit, and also with management support.
Whatever the case may be, antagonism is counterproductive and unprofessional, and the project manager and/or Agile change agent should avoid even the appearance of such an attitude. Firmness is required, but also a willingness to listen, learn, and adapt to make certain the best solution or practice is implemented in as transparent and collaborative an environment as possible.
