Case Study – CRM Resistance or Mutiny? A Stark Example of Collaboration Gone Wrong
Penny-wise and pound-foolish
Beware of IT lead CRM projects. That’s what we hear all the time and read about in all the articles. Well, I can say from experience, this is good advice.One UK client we had was replacing their CRM system. The IT department was mandating the system replacement. This was done for a variety of reasons – the biggest two being the technical limitations of the existing system that threatened future IT development, and that the vendor was sunsetting support for the system.The business liked the existing system and didn’t want the new one. And they still had a bad taste in their mouths from previous experiences dealing with failed system rollouts and perceived poor support from IT.So, you can image how warm of a reception IT received when they:
- Mandated the replacement of the existing CRM.
- Declared they only had budget enough for one release, so there would not be any future enhancements.
From passive resistance to active fighting
Over the next few months, the usual CRM planning meetings went on. And on. And on.
Meeting after meeting ended in disagreement and delays. Some legitimate technical, data and process issues were identified. But a lot of the issues that came up had nothing to do with the technology.
What became clearer each day is that the user groups were very afraid of what would happen after the system was live. They were fine with technology in general. They actually used the current systems quite well.
Instead, they were worried that they would be thrown to the wolves once the system was live and it wouldn’t work as they needed. There would be no money or resources to get things fixed. The users – not IT – not the system – would get blamed for everything that would go wrong.
It had happened before.
They weren’t going to let it happen again.
Things really came to a head in the days right before go-live. The users had identified three critical bugs that needed to be fixed before they would sign-off on going live. The bugs were fixed. The users retested and confirmed that they were fixed and the system was working as they needed. And yet, despite verbally stating that everything was fine, the business users still refused to sign-off that the bugs were fixed.
Breaking the logjam
After several tense meetings, issues were escalated to the executive committee. Two things happened. First, the users who were clearly active in preventing the system from going live got their hands slapped.
Second, the IT department acknowledged that they had bigger issues here and that they would need to do more to support the users. They agreed to shift some other priorities (and budgets) and decided that they would indeed schedule a second release for a couple of months after go-live to address any outstanding or emerging issues.
Once this happened, the two sides began to work together more effectively. Sure, they were still skeptical of each other, but they managed to move forward.
Among the many lessons here, one of the biggest is that emotional issues – fear, distrust, anger – affect how people approach CRM projects. Understanding these people-based issues and proactively dealing with them is the only way to prevent them from continuing to negatively impact your project.
Unfortunately, many projects ignore these critical components of human behavior. And it costs them a lot of time, money, and unnecessary hassle.