How to neutralize negative project stakeholders?

Question

There are positive and negative stakeholders in every project (according to PMBOK). Positive ones will benefit from project implementation, for example their work will become more effective, more automated, easier, and more fun. At the same time negative stakeholders will have problems once the project is implemented. For example, they will be fired because their job will be done by new software.

It's a project manager responsibility to take negative stakeholders into account and neutralize their influence to the project affairs. How do you do this in your real-life projects? What are the most effective methods?

Answer 1

I never would have said this a year ago, but sometimes giving negative stakeholders some attention and TLC can convert them into powerful allies for your project. In your example, if their job is being eliminated, there's nothing you can do. However, in one of my recent projects, we took a negative stakeholder aside, showed him how even though the project seemed like a headache for him, it was good for the company -- and he liked being employed by the company! In another instance, we gave a negative stakeholder an opportunity to give input into the product design. We haven't actually implemented her idea, but feeling like she had contributed and had ownership changed her attitude tremendously.

Converting negatives to positives is probably the exception rather than the norm, and I would not spend a ton of time and energy trying to do it. However, if you are able to succeed, it can reap great benefits. In both of my examples, the converts turned into great project champions.

Answer 2

I think attitude of negative stakeholders (as you define them) is usually out of control of project manager. In vast majority of cases PM has no power over them whatsoever so the tools which are available are limited:

• Escalation to people who have formal power over negative stakeholders usually positively influence their involvement in project.
• Ruling negative stakeholders out from every critical project tasks (if possible) would reduce impact of their attitude.
• Convincing some of them that their behavior would affect their future careers can bring you at least a few of allies, especially when firing all of them is not the only option at the end of the project.
• Basing on available documentation, although may be risky as it isn't always complete and up-to-date, may be alternative when negative stakeholders don't seem to be helpful.

But in terms of taking negative stakeholders into consideration it actually is PM's responsibility as this is one of project risks, often a big one, which should be dealt with. And this definitely is a job for PM.

By the way: the problem is by the way bread and butter for project managers who deal with transition projects.

Answer 3

I would not recommand on neutrelizing anyone from the project. Every opinion should be heared. sometimes there is a lot to learn from these so called negative opinions. People are often frustrated not becuase they are about to lose their job, but because they feel that they are not taken under consideration in planning/ implementing a new system/ work method.

Sometimes listening to what people have to say can really teach us PM a lot about what we do and how we do it. we may have focused on the technical side rather than the user experience, or we may have just forgot to explain the users what is happening. their disutisfaction is a warning sign for us.

things that makes a negative project stakeholder (excluding losing her job):

• Poor user experience
• Poor system performance
• Improper training about the new system/ process
• New solution doesn't fix the users' old problems
• Keeping the users out of the picture. lack of communication or poor PR for the project.

Answer 4

A 360 degree analysis of stakeholders will probably show that you have both positive and negative stakeholders who are:

1. Directly involved in the project (ie part of the extended project team);
2. Directly impacted by the project but not directly involved (ie their jobs will change specifically because of the project, one way or another);
3. Indirectly impacted (ie they may not have to change anything, but they will be aware of the project and may have more influence than might be expected).

The PM needs to deal with group 1, as they are within his or her sphere of control.

Group 2 can be dealt with by the PM (as per the other answers), and the PM may also involve other people such as HR, line managers, corporate communications (if this exists).

I believe that Group 3 is the hardest to handle. They will often be sitting outside the project, looking in at it, and may have the ear of the senior people in the company. You have to get them on side, and that needs the PM to work with professional communicators who can create a campaign of communication (which will also help Groups 1 and 2), designed to get the right message out. This is a part of the project, and is one that is easily forgotten, so I agree with @pawelbrodzinski's comment about this being a project risk which should be managed within the project.

Answer 5

First of all, some stakeholder analysis has to be done. in case of negative stakeholders, it is important to understand what it is their influence on the project. I have found this analysis in "The Lazy Project Manager" by Peter Taylor. I believe it is a very simple, yet effective way to put things. So, for a stakeholder considering:

• Power on the project or in the organization
• Interest in the Project

So, typically, a negative stakeholder with a lot of interest and a lot of power must be handled very carefully. For this kind of stakeholders, things like involving them in the product design or asking for feedback on a very early phase of the project might be used. However the most important step is understand why they are negative stakeholders, i.e. what do they have specifically against the project.

For other stakeholders, the one with not so much interest in the Project but considerable Power or -the other way around- lot of interest but not much Power, a good communication management is usually sufficient. For instance, let us send them a report on the project -say- once every two weeks, or, even better, let's take the time to meet them personally and do a short report personally. Sometimes much better than a dry E-mail in those cases.

The other negative stakeholders, with less power and less interest, can of course be ignored, saving our time for most important tasks.

Answer 6

TL;DR

"Negative stakeholders" are usually symptomatic of a process that lacks visibility, or lacks an objective methodology for evaluating project goals from a systems-thinking perspective. Not to worry; CodeGnome catch-phrase #432 is: There's an agile process for that!™

Who Owns Stakeholder Management?

In Scrum, stakeholder management is the responsibility of the Product Owner. The Wikipedia entry on core Scrum roles has this to say (emphasis mine):

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business.

Loosely translated, this means it is the Product Owner's job to actively manage stakeholder expectations, prioritize their requirements in accordance with organizational needs, and (by implication) to create sufficient buy-in for the project to succeed.

The Scrum Master and the Team certainly have a part to play in all this through articulating process, providing user-visible functionality to stakeholders at every Sprint Review, and by providing stakeholders the management levers they require (through the Scrum process itself and through the services of the Product Owner) to effectively manage the project in a change-embracing way.

However, the responsibility for managing stakeholders does not belong to the team or the Scrum Master. That responsibility is clearly defined as the job of the Product Owner, and by extension the project sponsors or steering committees that have imbued the Product Owner with sufficient authority to run the project.

Some Product Owner Tools

Buy-in is more of an art than a science, but some agile or traditional tools for creating stakeholder buy-in based on organizational value include:

• Theme Screening
• Theme Scoring
• Relative Weighting of Epics
• Project Success Sliders (e.g. constraints-based decision-making)
• Traditional ROI calculations.
• Theory of Constraints discussions as they apply to the organization.
• Time-to-market analysis.
• Budget, budget, budget.

For those who like tools, the folks at Mountain Goat Software have some excellent online tools that you can use for free, or can use as a conceptual starting point for other quantitative ranking approaches to stakeholder requirements.

Informed Consent vs. Enthusiastic Backing

In my personal experience, making sure everyone's vertical interests are at least assessed by the project by a formal, documented methodology (when the methodology is generally agreed to be politically impartial) is the key to success. Even if individual stakeholders aren't happy with the specific results of how their individual interests are prioritized by the organization as a whole, they are generally satisfied when they can see that the process takes their concerns into account and that they will see direct or indirect benefits from the project's overall value stream.

The fact that the prioritization is both visible and transparent to the stakeholders is the key. For example, as much as it may be important to my team that a therblig embiggening function is added, I will be more likely to buy into the immediate value of a proposed lead-into-gold transmutation feature. The fact that the embiggening feature I've championed is still added to the backlog, albeit further down the list, ensures that my concerns aren't being ignored--they're just being put into context based on the needs of the organization as a whole.