How to succeed at stakeholder management

Most IT professionals identify the correct five goals for investing in stakeholder management activities but they put them in the wrong order. Here are tips for engaging stakeholders the right way.

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."


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."


The first comment I have is that it would have been nice if you made it a little clearer that the operating committee's responsibility was strategy. And that the discussion was outside their area of concern. Yes, I know you said "What's worse, the questions and the issues were all about tools and technology, matters that really have no bearing for the operating committee" but combining it with "AND that I thought I had already resolved in previous stakeholder management meetings." and placing it where you did softened the message. I guess what I am really saying is you needed to be clearer that the operating committee was discussing an issue it had no business discussing. Other than that I thought it was a very, very well done piece with lots of good information both on the surface and underneath. The second comment was that you failed to recognize that some people are not able to function at a strategic level -- they need to think at a concrete, example level. (Yes, there are reasons). As a result they will flee the strategic discussion and take refuge in the details and the technology. This could have been the case in this situation depending on the nature and makeup of the operating committee.


This approach is indicative of backward thinking that is bound to fail. IT isn?t there to manage stakeholders. IT is there to help stakeholders achieve the organization objectives. IT shouldn?t be aiming to drive knowledge and understanding by the key stakeholders. Rather, IT needs to be gaining knowledge and understanding of the key stakeholders and their needs. Not until IT catches on to that will the stakeholders find it productive to engage with, support, budget, and have confidence in IT. Those all are necessary for IT to gain the influence it desires. IT strategy has value only to the extent it serves the stakeholders? strategy, and thus stakeholders are unlikely to care much about IT strategy from the folks who mistakenly think _it_ is their concern. Stakeholders are relegated to dwelling on the trivial when it?s the only thing meaningful to them that they find IT seems capable of communicating about.


As a former project manager, business analyst and all-round "IT guy", I must reiterate that is so very important to achieve stakeholder buy-in by understanding their goals and requirements in an IT project. And, once you can articulate those back to them, you will achieve that level of trust and thus quicker buy-in and ongoing cooperation/coordination. Great article. I look forward to the book.


That "may" be true about IT (and I'm not going to get into that argument). However, it isn't true about project management which was the real subject of the discussion. Part of the Project Manager's role -- regardless of the task -- is to manage stakeholders. In some cases, that is hands on management. In some cases, that is limited to stakeholder's expectations. If the Stakeholders are responsible for strategy (typically in an IT project they aren't) then the project manager's responsibiity is to see that they live up to their responsibility. If the Stakeholders are responsible for requirements only, then the project manager's job is to focus them on requirements and away from implementation. And if the stakeholders' responsibility is to survive the result then the project manager's job is to focus them on how much better they will be after the project delivers. And that's why project managers are called managers. This article could have just as easily been written about marketing or construction or organizational development ... it just happened to be that the project manager was in IT.