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.

Dear readers—Please forward this to the business sponsor of the projects you might be working on. Ask them to subscribe as well!

Hi Business Sponsor!

I was thinking a lot about how to make your job easier, and it occurred to me that the place to start would be to tell you some of the things that you should be asking from IT.

Fundamentally, every human being wants similar things—Heck, one of my favorite books on software engineering even refers to Maslow’s hierarchy of needs.    Your sponsorship of this project (done well) should help you feel safe, part of a community, build confidence, and bring satisfaction and growth for those involved.

Being a good leader, to a large degree, is to understand that everyone, (IT, Management and Staff) has these similar needs.

So, keeping with the theme of good communication, let’s set a few expectations with IT.

• The IT Team should become highly familiar with the business problem to be solved or opportunity to be addressed; also, who will use the software, and what those people need to have to feel successful. Ideally, the IT teammates sit with the users for at least a day or so, learn how these do their jobs now, and what tools and procedures are currently in place.  In the process, a good IT teammate gets the opportunity to learn cool stuff, such as making guitar pedals , or what is needed to make a safe, clean industrial boiler.

This effort will probably require people to spend time together “IRL” (In real life), or face to face to get the maximum knowledge transfer.  This is difficult in these virtual days.   Try to make it happen—it is worth it.

• You should ask for a plan from IT, before each effort begins. (Readers!  Would it be helpful to you if we provided you with downloadable templates for these plans? Or a checklist you could use?)  Any plan should cover at least a few points:
  • A description of the problem to be addressed or opportunity to be chased
  • Possible options for the solution. (And don’t just accept one answer)
  • A draft schedule for the phase
  • A draft budget for the phase
  • Identified risks, and what preventions or mitigations could be applied
  • A quality assurance plan
  • Recognition of key Non-Functional Requirements (NFRs)

• Your project manager should schedule regular check ins, such as presentations, demonstrations, budget meetings or Steering committee meetings—Especially, make sure everyone involved knows the “No Surprises Rule” rules.

• Yes, you have a right to access any documents, test results, in progress work or demos whenever you want—BUT—you will get the best results when you avoid mistaking documentation for reality. So, work with IT, so that they can button up loose ends, organize their ideas and not waste your time or theirs.

Now, on to one request I have for you as a Business Sponsor (and there will be a lot of others later)

• I need you to be the one to drive acceptance of the business change. I need you to inspire the organization to embrace the change.  We both know the company must be willing to take the risks and learn from any failures.  We all want to be in the culture of innovation and learning—And this is something we can help with in IT, but you need to be the inspirational leader to help others get there.

# # #

Not to be missed on CIO.com’s CIO Survival Guide: “A CIO primer on addressing perceived AI risks.” It’s Bob Lewis’s take on real and perceived AI risks you probably haven’t read about anyplace else.