Managing Resistance to Organizational Change

The project manager held a product demonstration with the department’s users last week. Although their manager had been unable to attend, the department representatives were positive as the features of the new system were shown.

But late Friday afternoon, the PM received a surly email from the manager complaining that staff reported the solution was inconsistent with current practice and unresponsive to their needs. The email closed with, “We don’t want to have another debacle like Project X,” referring to a troubled software implementation a year prior. The email copied the staff that had been present in the demonstration, as well as the VP in charge of the department.

In our coaching meeting Monday morning, the PM felt understandably frustrated and betrayed. I asked what response she had made thus far and she said, “Only a quick ‘reply all’ acknowledgement on Friday that I had received the email and would address the concerns on Monday. I wanted a chance to think through a response.”

Prompt acknowledgment without rushing her reply was wise. She had begun crafting an email that addressed several points diplomatically but firmly:

1. Staff feedback during the meeting had been positive and the PM was unaware of issues until the email was received
2. The off-the-shelf software being implemented wasn’t advertised or expected to exactly match local business processes, only to assure that business requirements were met
3. It was early in the analysis/implementation portion of the project, and there was time to address the manager’s concerns
4. Project X (which had been quite challenged) was a different project, done by a different organization, and had very little resemblance to this project

She was particularly worried about #4, which seemed inserted just to provoke. The distribution list was also troubling. We discussed what an organizational change disaster it is for any project to have gossip circulating that it was “just like [insert catastrophe here]” and how important it would be to tamp down that sentiment.

I suggested she strip her response down to a minimal version of item #3, a reminder that everyone involved wants the project to be successful, and assurance that she would follow up in person this week to discuss concerns.

I encouraged her to meet one on one with everyone copied on the original email, especially the VP. Addressing concerns in person provides an opportunity to explore issues more thoroughly:

• What are the concerns? Is it simply a response to change and the new system, or are there unmet requirements?
• Why didn’t participants raise concerns in the meeting or afterward with the PM?
• Why involve the VP?
• In what ways do people perceive this project is like Project X?

Email battles between “us” and “them” rarely de-escalate tensions. If people are predisposed to think their concerns aren’t being heard, your project is on a trajectory for disaster. The initial email was a warning sign that user expectations were off track. Adjusting and managing those expectations thoughtfully and with minimal drama is essential to project success.