Stakeholder Resistance vs. Stakeholder Disagreement: What Should the Project Manager Do?

September 30, 2026 September 22, 2026

admino

A stakeholder challenges the project.

Another refuses to support a proposed change.

A third says the project will create serious problems for their department.

Are all three simply “resistant”?

Not necessarily.

This distinction matters in PMP® scenario questions.

A stakeholder who disagrees may:

understand the project perfectly well,
have legitimate operational concerns,
represent competing priorities,
identify a missed requirement,
object to how a decision was made,
resist the impact of change rather than the project itself.

So before asking:

“How do I get this stakeholder to support the project?”

ask:

“What is the stakeholder actually objecting to, and why?”

That diagnosis should come before the response.

1. Stakeholder Opposition Is a Signal, Not a Diagnosis

Consider:

A department manager says the proposed solution will create additional work for the team.

Several explanations are possible.

The manager might:

misunderstand the solution,
understand it but disagree with the trade-off,
identify a genuine operational impact,
believe important requirements were missed,
feel excluded from the decision,
resist how the change affects existing responsibilities.

These are different problems.

And they require different responses.

A useful principle is:

Do not respond to the visible objection before understanding its cause.

2. Disagreement Is Not the Same as Resistance

A stakeholder can disagree with a project decision and still be constructively engaged.

Imagine:

A senior operations manager understands the implementation plan but argues that the proposed cutover will create unacceptable downtime.

That stakeholder may not be resisting the project.

They may be challenging an assumption.

Their objection could reveal:

operational risk,
weak implementation planning,
a missed dependency,
an incomplete requirement.

The project manager should not automatically treat the stakeholder as someone who needs to be persuaded.

Ask:

Is this disagreement blocking progress—or improving the quality of the decision?

That distinction matters.

3. Look for the Stake Behind the Position

Stakeholders often state a position:

“I don’t support this change.”

But the project manager needs to understand the interest underneath the position.

For example:

Position:
“We cannot implement this system in June.”

Underlying concern:
June is the department’s busiest month, and implementation would disrupt critical operations.

Those are not the same thing.

Once the underlying concern is understood, possible responses may emerge:

change the timing,
phase the rollout,
provide additional support,
adjust scope,
reduce operational risk.

Ask:

What does this stakeholder stand to gain, lose, or experience because of the project?

This often explains the objection better than the stakeholder’s initial wording.

4. A Stakeholder May Be Right

One of the easiest mistakes in a scenario question is assuming:

Project manager = correct

Opposing stakeholder = problem

That is not always true.

Consider:

A stakeholder argues that the proposed solution conflicts with an operational control the project team overlooked.

The correct response is not automatically:

Convince the stakeholder to support the plan.

The stakeholder may have identified a real project issue.

The project manager should investigate the concern.

Good stakeholder engagement includes listening to information that may be uncomfortable or inconvenient.

A useful question is:

What if the stakeholder’s objection contains information the project needs?

5. Three Similar-Looking Situations — Three Different Problems

Stakeholder scenarios can look similar on the surface but require very different reasoning.

Scenario 1: The Stakeholder Is Informed but Concerned About Impact

A department director receives regular updates and attends project meetings. The director still opposes the rollout because the department will lose access to a critical system for four hours.

This is not primarily a communication problem.

The stakeholder already understands the situation.

The project manager should investigate:

whether the downtime is necessary,
whether alternatives exist,
how serious the operational impact is,
whether the concern affects project risk or requirements.

The issue is the substance of the objection.

Scenario 2: The Stakeholder Was Excluded

A stakeholder opposes a new process after discovering that decisions affecting their department were made without their participation.

This may be primarily an engagement problem.

The stakeholder may have received information.

But they were not appropriately involved.

The project manager should consider:

whether the stakeholder should have participated,
whether important impacts or requirements were missed,
how to restore appropriate involvement,
whether prior decisions need review.

Remember:

Being informed is not the same as being engaged.

Scenario 3: The Stakeholder Understands and Still Disagrees

A stakeholder participated fully, understands the available options, and still prefers a different approach.

This is not necessarily a project failure.

Different stakeholders may legitimately prioritize different things:

finance may emphasize cost,
operations may emphasize stability,
customers may emphasize functionality,
compliance may emphasize control,
executives may emphasize speed or strategic value.

The project manager may need to:

clarify trade-offs,
facilitate discussion,
identify decision criteria,
determine who owns the final decision.

The goal is not always unanimous agreement.

The goal is an appropriate decision.

6. When Disagreement Becomes a Governance Question

Not every disagreement should be escalated.

Ask first:

Can the concern be clarified?
Can the project manager facilitate resolution?
Is there new evidence?
Can alternatives be explored?
Who owns the decision?

Escalation becomes more appropriate when:

authority is exceeded,
governance requires it,
project-level resolution has failed,
competing organizational priorities require a higher-level decision.

But the opposite mistake is also possible.

Suppose:

An authorized governance body makes a final decision after considering stakeholder concerns, and one stakeholder continues refusing to follow the approved direction.

At that point, the issue may no longer be ordinary disagreement.

It may involve:

accountability,
authority,
implementation,
governance.

A stakeholder’s continued dissatisfaction does not automatically reopen a properly authorized decision.

7. Resistance May Be About the Change, Not the Goal

A stakeholder may support the project’s purpose but resist what the change means personally or operationally.

For example:

Employees agree that a new system will improve customer service but oppose implementation because they believe they will lose control over how they perform their work.

They may not oppose the project itself.

They may resist:

changed responsibilities,
new workflows,
reduced autonomy,
new performance expectations,
uncertainty about future roles.

That points toward change-management reasoning.

The project manager may need to consider:

involvement,
training,
transition support,
role clarification,
feedback,
stakeholder concerns.

The key question is:

What exactly is being resisted?

8. The Project Reasoning Lab LISTEN Check

When a stakeholder objects, resists, or disagrees, use the LISTEN Check.

L — Listen

Ask:

What is the stakeholder actually saying?

Understand the concern before interpreting it.

I — Identify

Ask:

What is underneath the objection?

Is it:

missing information,
insufficient involvement,
operational impact,
competing interests,
requirements,
risk,
authority,
change resistance?

Different causes require different responses.

S — Stake

Ask:

What does this stakeholder stand to gain, lose, or experience?

Their stake often explains their position.

T — Test

Ask:

Does evidence support the concern?

Could it reveal:

a genuine risk,
a missed requirement,
a weak assumption,
a legitimate operational impact?

Do not dismiss disagreement merely because it is inconvenient.

E — Engage

Choose the response that fits the actual problem.

That may involve:

clarification,
collaboration,
negotiation,
facilitation,
requirements review,
change support,
governance involvement.

N — Next

Finally ask:

What logically needs to happen next?

The answer depends on what the objection actually means.

9. Quick Diagnostic Guide

What You Observe	Possible Underlying Problem	Reasoning Direction
Stakeholder lacks information	Communication	Improve information flow
Stakeholder was excluded	Engagement	Restore appropriate involvement
Stakeholder understands but disagrees	Competing interests	Evaluate trade-offs and facilitate
Stakeholder identifies operational impact	Risk / project impact	Investigate the concern
Stakeholder says requirements were missed	Requirements	Validate requirements
Stakeholder fears role changes	Change resistance	Support transition
Stakeholder rejects an authorized decision	Governance	Clarify authority and implementation
Project-level resolution fails	Authority/governance	Escalate appropriately