Mindset Mismatches That Plague Stakeholder Management

• Fact: You know how critical stakeholder management is to your personal career success and to the overall success of your IT group.
• Fact: You spend a great deal of time coaching and reminding your people about the importance of stakeholder management.
• Fact: You go home at night frustrated by the absence of critical stakeholder management activities that have cost you your reputation, your time and your political capital with your peers.

Where’s the problem?

Ask around and the answers you typically hear fall into one (or more) of the following categories:

• Blame the staff – Stakeholder management is mostly about communications and you know how it is with IT professionals, they’re just not good communicators.
• Blame the boss – IT leaders may be saying what to do but they aren’t really teaching their people how to do it. Besides, most of them are pretty bad communicators themselves, so how are they supposed to teach their people?
• Blame the stakeholders – They think they know it all. They hate IT and never listen anyway. So it doesn’t really matter what IT does.

IT Stakeholder Management Fail: Conflicting Mindsets


It’s convenient to blame one or more of the parties to the problem, but this doesn’t yield much progress. So, for today I’d like to suggest a different approach. Instead of blaming people, I’ll point out three fundamentally conflicting mindsets (between IT and stakeholders) that are quietly sabotaging your stakeholder management activities. And, since each mindset is totally justified in its own right, it’s no surprise that stakeholder management is in such a sorry state. Of course once these mindset differentials are recognized, they can be addressed and overcome. More on that in a later column.

Mindset Conflict No. 1: IT wants to be “understood” (and appreciated). Stakeholders couldn’t care less.

In my line of work, I get to help IT execs at all levels prepare stakeholder management presentations. Without fail, the No. 1 most common approach used by IT managers (even experienced ones) is to explain to stakeholders what’s going on in hopes of educating them about the challenges of the project so that they understand.

To achieve this understanding, they provide great amounts of detailed information so their stakeholders can see for themselves what’s going on. (Read – so they don’t get yelled at for the project being late or whatever.)

For the vast majority of IT professionals, the key goal of stakeholder management activities is to get stakeholders to see the complexity and appreciate the difficulty of what they are doing. In other words, to give stakeholders knowledge so they can appreciate how hard IT is working. As a fundamental approach, this is flawed.

That’s because your stakeholders are not in a learning mindset. They have little interest in learning about your problems. Their mindset is simply this: Why are you here? Is there a problem? Do I really need to care? When’s it going to be fixed? Will it cost me time or money?

Your stakeholders don’t have the time, desire or ability to comprehend the complexity of what you want to tell them, let alone appreciate it. All they hear is that you are trying to make them understand something by burying them in details.

Mindset Conflict No. 2: IT thinks process. Stakeholders think results.

Let’s say you’re the IT executive charged with managing a complex multi-vendor, multi-platform e-commerce project that is supposed to enable major revenue growth by driving an increase in direct-to-consumer sales of your company’s products.

You know that it’s going to take time to get it right and that there are a number of steps to be followed. You spare your stakeholders the technical details (see Conflict No. 1) yet all you hear is “I don’t care about what you have to do, just make it happen.”

All you can do as the IT guy (or gal) is take responsibility for managing the process correctly. Your stakeholders couldn’t care less about “the process,” all they want to hear you say is that you will take responsibility for the results. But how can you? So many of the issues are out of your hands.

Mindset Conflict #3: When IT thinks a project is nearly finished, stakeholders are just getting started.

You made it through the project. Along the way you somehow managed to keep stakeholders informed, aware, and engaged. The system goes live. No crashes. You breathe a sigh of relief. And then, as if out of nowhere, the complaints come streaming in:

• “This isn’t what we expected at all.”
• “How are we supposed to work in this system, it’s nothing like what we are used to.”
• “We have a major problem here.”

“What???” you say. “But you and your team signed off on the designs months ago. Your people all went to training. Your people all signed off on the user acceptance test.” (I’ll spare you the rest of the conversation. You’ve had it 100x already.)

The answer once again lies in conflicting mindsets. Your stakeholders may indeed have gone along with the program and followed your process but, at best, they were only 50 percent present. For them, the system isn’t real until they have to use it on a daily basis to do their job. Then, and only then, do you they really experience the system. No extrapolations, no prototypes, but the real thing up and running and working with their real live data. That’s day one. And boy-o-boy will they need some serious day-one stakeholder management in light of their out-of-this-world expectations.

Meanwhile, the IT team is cracking open the champagne to celebrate the go-live and the on-time, on-budget delivery. Oops. That’s a big mindset mismatch.

So, there you have it: The three big mindset mismatches that are at the root of stakeholder management problems. In the next column, we’ll dig into what you can do to address these problems.