Sometimes, there’s a crucial conversation that needs to happen between IT leadership and someone else in the business. Until that conversation takes place, a grudge might linger, causing friction in new or existing projects. This grudge might not even come to light until the project is nearing completion.

Let’s step back for a moment. People disagree about projects and solutions all the time. Usually, goodwill and trust can be built, and differing views can be reconciled. When views can’t be reconciled for whatever reason, the best outcome is for those who disagree with the consensus view to agree to the consensus view. Failing that, agreeing to disagree is usually good enough.

In our jobs, we’re expected to be experts in change management, helping people see a brighter future through the solutions we implement. The solution may not make every person’s job easier, but overall, it will help the organization be more successful. Communicating this difference is important.

We’re also expected to be transparent. While we’re not blind to office politics, we genuinely strive to rise above these issues where we can. We understand that people sometimes worry about how a change effort will affect their job security, seniority, career, or have other very personal concerns.

One concern that often goes unnoticed isn’t, strictly speaking, a concern at all. It’s a grudge, held and left to fester because nobody in the organization owns the spot-and-defuse-grudges process.

Which explains why, when things go sideways, it often happens as we approach a Go-Live.   This is when a naysayer has the most leverage and, motivated by a long-standing grudge, responds to it by creating roadblocks under the guise of their concern.

The Grudgeholder may not say, “I didn’t like the IT Director, the software, or the vendor she chose, but I couldn’t give a solid reason to object earlier.”  They are more likely to rationalize the resistance, not recognizing their own part in stirring the pot.

The Protagonist (usually the CIO or IT Director) will point out, “Hey, we agreed on a selection process, a project management and reporting process, and a steering committee to manage this project. We agreed on a change management and training plan. We picked a vendor that was transparent in their reporting and billing, and we are on track for a successful project. What gives?”

When the dust settles, several points commonly emerge:

• The grudge existed before the project started.
• At best, the Grudgeholder’s concerns might be valid. It’s their timing that’s invalid.
• As a result, by entertaining a Grudgeholder’s challenges, senior management has sent the message that project failure is an okay outcome. Rather than accepting the Grudgeholder’s challenges, senior management should make it clear that the time to raise and address them is in the next release.
• Behavior that would never be tolerated between Sales and Production is tolerated between parts of the Business and IT. Company Senior leadership needs to take a hard look at themselves and their role in achieving the desired outcome.

How can this be avoided?

It seems easy to say now, but it probably starts with addressing the first point. Company leadership should sort out (and not tolerate) grudges between different parts of the business before starting projects together. If there’s a conflict, get it resolved and make necessary changes before embarking on any project together. Most of the time, these issues can be worked out through a focused conversation, or better yet, over lunch.

Recognizing the need to identify and neutralize Grudgeholders … and not just Grudgeholders but all manner of change resisters … is easy to miss during the overall effort of ramping up a change effort.

And even if you recognize the importance, you can’t expect someone to just tell you they’re going to resist the project.

Which is why every project should start with a formal Stakeholder Analysis – a set of techniques for identifying which stakeholders and stakeholder groups you can expect to promote, accept, or resist the change the project is supposed to institute. And, all project managers should engage in organizational listening – techniques for discovering What’s Going On Out There as standard practice.

Regardless of whether you get this support or not, as an IT leader, if you know there’s bad blood with another part of the team, get ahead of it now and resolve the issue. Otherwise, you can bet you’ll hear about it again, right when it’s most inconvenient.