How to succeed at stakeholder management

Earlier this week one of my favorite clients (we’ll call her Sharon) asked me an interesting question. It went something like this:

“I’ve been spending an awful lot of time on stakeholder management-meeting with the key stakeholders across the business to ensure we’re meeting their needs. Yet at a recent operating committee meeting (at which I wasn’t present) I learned that a pretty unpleasant discussion took place regarding one of our key market intelligence systems and the strategy associated with the eight-figure investment in this system.

“What’s worse, the questions and the issues were all about tools and technology, matters that really have no bearing for the operating committee AND that I thought I had already resolved in previous stakeholder management meetings.

“What’s going on? Am I doing something wrong?”

Sharon’s a reflective IT pro. I admire the way she objectively looks at what’s working and what’s not. When something’s not quite right, she’s never afraid to call it and then go to work on fixing it. Step 1: Root Cause Analysis. Listen in on our conversation below.

“What makes you think it’s a stakeholder management problem?” I asked.

“Well, if my stakeholder management was working, I wouldn’t have this sort of situation on my hands with the operating committee. They would better understand where we’re going and what our core strategy is.

“We wouldn’t have these questions and diversions that come out of left field so frequently.”

“OK, fair enough,” I say. “But is there anything else about your stakeholder management activities that make you think it’s not working? Couldn’t this just be a problem specific to this initiative?”

“I wish.

“Here’s another example of why I think the stakeholder management isn’t working:

“In my meetings with them I am constantly bombarded with issues of the day. I get very little time to meaningfully engage on strategy, planning or how to better work with us.

“Our relationships are good, but we’re not getting the right outcomes from these activities.”

“And what are the right outcomes in your opinion?”

“Well, the number one goal of my stakeholder management activities is to drive knowledge and understanding by the key stakeholders.

“If our stakeholders are fully knowledgeable and understand our strategy and plan that, in turn, will yield all sorts of benefits such as smoothing the way for implementation, stopping discussions about tools and technology and the issues of the day.”

At this point I stop Sharon and repeat back to her what I’ve heard her say.

“Sharon, to me it sounds like the outcome you really want is TRUST and INFLUENCE and you believe the best way to build that trust is via knowledge building and understanding.”

“Exactly.”

Before I can even get the next question out, Sharon jumps in.

“Hang on a minute, Marc, I think I see where you’re headed. Knowledge and education isn’t really my goal, in fact it’s just a means to the real goal. I’m putting a lot of effort into an important activity on the assumption that it will support my goal but that may not be the case.”

“Quite right. When approaching stakeholder management it’s helpful to keep your real goals in mind not the means to achieving that goal.”

Let’s pause my conversation with Sharon for a moment and look at the issue of stakeholder management goals. It turns out that this is a pretty common issue for truth-seeking IT professionals. Most IT professionals identify the following five goals for investing in stakeholder management activities:

• 1. Achieving knowledge and understanding on the part of the stakeholder relative to IT strategy, vision, budgets, programs, plans, etc.
• 2. Achieving direct stakeholder engagement in some IT-related project, issue, or problem.
• 3. Achieving stakeholder support, i.e., assigning the stakeholders people or other resources toward an IT-related project or objective.
• 4. Securing stakeholder budget in order to create or build a particular IT program, system, etc.
• 5. Building stakeholder confidence in the IT team generally with regard to a particular aspect of service delivery.

What’s so interesting about this is that it is nearly the reverse order required to support an influence- and trust-building agenda as Sharon accurately identified.

OK, with this information in mind, let’s go back to the conversation with Sharon.

”

So if my stakeholder management activities need to center on the goal of building influence, what’s the best way to approach it? What do I focus on?”

“Actually, you’ve already taken the first and most important step. You’ve shifted the prism through which you look at stakeholder management. Knowing what you now know, you can confidently shift your communication and content priorities with stakeholders.

You can self-assuredly spend lots of time answering their “mundane,” “techie” questions as opposed to engaging in a strategic review because that’s what they need to talk about in order to have confidence in you and your team. (It may not always be the case, but it is for now.)

The next thing you can do is spend time talking about money. Talk about the financial ramifications of your stakeholders’ project(s), their budget status, whatever. Just make sure to demonstrate that you and your team have a very firm grip on the money. That’s what inspires confidence.

If you still have time in your stakeholder management meetings, you can now shift emphasis to knowledge and understanding, but not the kind you think. It’s not that you want to get your stakeholders to understand you, rather you need to demonstrate that you understand them; that you understand their needs and concerns and are not afraid to listen to feedback and deal with tough issues.

And Sharon, one last thing before we go: Many IT leaders consider getting senior business leaders to be “part of” the project the crowning achievements of their careers. And in some cases having a senior business person participate in a kick-off meeting or steering committee meeting makes a lot of sense. But as a general rule, the last thing business leaders are interested in is participating directly in IT-related projects; that’s what you and your team do. You’ll build far more influence and credibility by demonstrating that you don’t need them than by trying to get them involved.

Good luck with the next round of meetings. And let me know how it goes.”