Skip to content

Lesson 3 — Complex Stakeholder Environments

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Distinguish stakeholders who are resistant from stakeholders who are in conflict with each other, and explain why the second is harder.
  2. Map a stakeholder environment by interest, influence, position on the decision, and what each can actually do to the project.
  3. Work with conflicting objectives between organisational units without pretending the conflict does not exist.
  4. Use decisions, boundaries, and explicit trades as the tools for managing disagreement, rather than more communication.
  5. Recognise situations where stakeholder management cannot resolve the problem, and name what has to change instead — including when the difficulty is an ethical one.

Prerequisites

  • Module 02 Lesson 1 — the interest/influence grid and the stakeholder register.
  • Module 10 Lesson 2 — communication planning and escalation.

Introduction

The core course treats stakeholders as a set of individuals with interests and influence, and asks how to engage each one. That model works until the difficult case appears, which is not a resistant stakeholder but a conflict between stakeholders — two senior people whose success criteria are incompatible, each able to stop the project, and neither willing to be the one who gives way.

Standard stakeholder management makes this worse in a specific way. It treats each stakeholder individually, so the project ends up trying to satisfy both sides with a document that contains both answers. The result is scope nobody agreed to, a design with two contradictory rules, and a project that appears to have full support right up to the moment testing produces behaviour the other side rejects.

This lesson is about that case: what to notice, what to do, and where the limits are.

1. Resistance versus conflict

Situation What it looks like What helps
Resistance One stakeholder disagrees with the project's direction, has influence, and could block adoption Engagement: understand the objection, address it or record it, keep them informed
Conflict Two or more stakeholders disagree with each other, and both can act on the project A decision made by someone with authority over both, in writing, with the trade-off named
Ambiguity Nobody disagrees, and nobody owns the outcome Finding the owner; a project with no real sponsor is unsupported, not uncontroversial
Indifference The stakeholder's objectives are unaffected Minimal engagement — and no attempt to manufacture enthusiasm

The distinction matters because the responses are different. Resistance is a relationship problem, and relationships can be worked on. Conflict is an authority problem: only someone with authority over both parties can resolve it, and the project's job is to force that decision rather than to mediate forever. Projects that try to resolve conflict themselves produce compromise documents, which in software means configurations and flags no one asked for.

2. Mapping what stakeholders can actually do

Interest and influence, the two axes from Module 02, tell you who to talk to. To manage a complex environment you need two more columns:

Column Why it matters
Position What they want to happen, stated as a decision rather than a feeling
What they can do The specific action available to them: refuse to sign off, withhold data, decline to release a person, escalate to the sponsor, block a release, brief the public
What they need to say yes The condition under which they would agree — often not the thing they are objecting to
Cost of not involving them The consequence of a decision made without them, which is usually a rework, not a complaint

Two patterns appear so often they are worth naming. First, the blocking stakeholder with no authority but real power — a team that operates the service, a records office that holds the data, a clinician whose objection will be repeated to the board. Formal governance does not see them. Second, the proxy stakeholder — someone who speaks for a group but has never checked with them, which is how a project discovers in acceptance testing that "the staff are happy" was one person's opinion.

3. Working with conflicting objectives between units

When two organisational units want incompatible things, the workable sequence is:

  1. Get the objectives stated in the same units. "Better service" and "lower cost" are not comparable. "Average time to book an appointment" and "number of staff hours per appointment" can both be measured, and naming both makes the trade-off visible.
  2. Quantify the trade-off roughly. Which direction does each option move each measure, and by how much? Rough numbers that both parties accept as fair is the target; precision that one party disputes is worse than a rough number both accept.
  3. Escalate with options, not a problem. "We cannot satisfy both; here are three combinations with their consequences" is a decision request. "The departments disagree" is a complaint, and it will be returned to you.
  4. Get the decision recorded in the decision log, with the decider named. Verbal agreement between two people who dislike the resolution does not hold when the consequence becomes visible.
  5. Tell both parties the same thing. Divergent accounts of the decision create a second conflict, and they are how projects acquire a reputation for managing people.

4. Boundaries, trades, and the tools that actually work

More communication is the usual prescription and usually the wrong one. The tools that resolve disagreement are structural:

Tool What it does
A named decider Replaces mediation with a decision, and a decision with a date
A written boundary "This release: X only" — a boundary can be held against a request in a way that a preference cannot
A costed trade Choice A costs B; choice C costs D; the comparison is what allows someone to choose
A small experiment Where the disagreement is about the effect rather than the goal, evidence ends it faster than argument
A staged release Allows both parties to be partly right, with a review point at which the effect is measured
Removal of a flag or configuration The tell-tale that a conflict was never resolved — if both behaviours ship, both stakeholders were promised

The last row is worth checking on your own project. Every configuration option that exists because two parties could not agree is a permanent maintenance cost and a permanent political question.

5. Where stakeholder management stops

Three limits are worth stating plainly, because the core course's stakeholder material cannot cover them.

You cannot satisfy everyone, and trying to is a failure mode. A project that adds scope for every objection has no boundary, and its absence of conflict is bought with an unmaintainable system. At some point someone must be disappointed, deliberately and visibly.

Power asymmetry is real. Some stakeholders' opinions carry more weight than others because of their position, not because they are better informed. This is the environment you work in, but the honest response is to record the basis of the decision — "the decision was made on authority, against the advice of the clinical lead" — rather than to present it as agreement. Recording it is what allows the decision to be revisited when its consequences appear.

Some disagreements are ethical, not managerial. If a stakeholder is asking for something that would mislead users, hide a safety-relevant limitation, or process personal data without a lawful basis, the correct response is not a communication plan. It is to refuse, in writing, and to escalate. Module 12 Lesson 4 and the ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice (1999, jointly published by the ACM and the IEEE Computer Society) are the reference points — and the practical point is that the code's usefulness comes from having thought about the position before you are asked to compromise it.

Key terms

Term Meaning
Stakeholder conflict Two or more stakeholders whose objectives are incompatible and who can each act on the project
Position What a stakeholder wants to happen, stated as a decision rather than a sentiment
Leverage The specific action a stakeholder can take, as opposed to a general influence rating
Cost of exclusion The rework or delay caused by deciding without a stakeholder
Proxy stakeholder Someone who claims to represent a group without having confirmed the group's view
Escalation with options Presenting decisions with costs rather than problems
Power asymmetry Unequal weight held by stakeholders irrespective of the quality of their argument
Ethical escalation Refusing and recording a request that conflicts with professional or legal obligations

Worked example

Task: resolve a conflict on the hospital appointment system between the outpatient director and the clinical lead. Figures are invented for teaching.

Step 1 — Classify the situation before acting. The outpatient director wants online self-booking; the clinical lead wants all bookings triaged by a clinician first. This is not resistance to the project — both support it and both can stop it. It is a conflict over the booking rule, and only someone with authority over both clinical and administrative practice can settle it. Classifying it correctly changes the task from persuasion to escalation.

Step 2 — State both objectives in measurable terms. The director's objective is average time from patient request to a confirmed appointment. The clinical lead's objective is the proportion of appointments that a clinician has reviewed for clinical appropriateness. Both are measurable, and measuring both immediately shows that each is improved by the other's option — the disagreement is about the threshold, not the goal.

Step 3 — Quantify the trade-off roughly, with numbers both parties accept. Two options: (A) direct self-booking for all appointment types, giving the shorter time to appointment and review by exception; (B) self-booking for a named set of appointment types with clinician triage for the rest, giving partial improvement with review preserved. The numbers used are estimates of average time-to-appointment and review coverage per option, explicitly labelled as estimates, with the estimating basis stated. A rough figure both parties accept is more useful than a precise one that one party disputes.

Step 4 — Escalate with options and a recommendation. The project manager presents A and B to the medical director, who has authority over both, with the trade-off for each and a recommendation of B on the grounds that it preserves the clinical control that the clinicians would otherwise escalate, while delivering most of the time improvement. The escalation is a decision request with costs, not a report of disagreement.

Step 5 — Record the decision and its basis. The decision log records: option B, decided by the medical director, on the stated trade-off, with the review date at which the measured effect on both objectives will be examined. The entry also records that the clinical lead accepted the decision on authority after arguing for triage of all types — because when the first clinical incident occurs, the project's record should show honestly how the rule was decided.

Step 6 — Remove the temptation to promise both. No configuration option is added to allow either booking rule to be switched on later. If the review date shows B performing badly, that is a change request with a cost, not a hidden flag. Every flag added "just in case" is a decision deferred into permanent maintenance.

Common misconceptions

“With enough communication, stakeholders will agree”

Communication resolves misunderstanding and reveals shared goals. It does not resolve conflicting objectives, because both parties already understand each other. Where the objectives genuinely conflict, the missing ingredient is authority, and the project's contribution is to make the trade-off legible so that authority can be exercised.

“The most vocal stakeholder is the most important one”

Volume is not leverage. What matters is what a stakeholder can do — withhold data, refuse sign-off, release a person, escalate publicly. A quiet records office holding the data can stop a project that a loud enthusiast cannot.

“Recording that a decision went against advice is disloyal”

It is the opposite. Recording the basis — authority, not agreement — protects the decider, protects the project, and makes the decision revisitable on evidence. An organisation that cannot record dissent cannot learn from its decisions.

“Stakeholder management is a technique for getting people to agree with the plan”

That framing points at manipulation and produces plans that collapse at the first consequence. The professional version is to understand interests, make trade-offs visible, get decisions recorded, and be honest about who was disappointed.

Practical activity

Map a conflict, real or plausible.

  1. Choose a project with at least two stakeholders whose objectives could conflict — or use the hospital appointment system from the worked example with your own variation.
  2. Build the extended register: interest, influence, position (stated as a decision), leverage (the specific action available), and what they need to say yes.
  3. Write both parties' objectives in the same measurable units, and note whether they conflict in goal or only in threshold.
  4. Draft an escalation with two or three options, each with its cost, and a recommendation. Keep it to one page; a decision request that requires reading is a decision deferred.
  5. Identify one thing the project might be tempted to ship as a configuration option to keep both parties happy, and argue for or against doing so.

What "good" looks like: positions stated as decisions rather than attitudes, leverage described as concrete actions, an escalation with costs and a recommendation rather than a report, and at least one place where you accept that a stakeholder will be disappointed.

Self-assessment

  1. Why is stakeholder conflict harder to manage than stakeholder resistance, and what does each need?
  2. What does the "leverage" column add that a high/medium/low influence rating does not?
  3. You have written three options with costs for a decision that two senior stakeholders cannot agree on. The decision is not made and the project is blocked. What do you do next?
  4. Give an example of a configuration flag that exists because a conflict was never resolved, and explain its cost.

  5. A powerful stakeholder asks you to omit a known limitation from the release notes. What is the professional response, and why is it different from a stakeholder-management problem?

  6. Apply it — conflicting stakeholders. In a university LMS project, the teaching office wants a single sign-on journey for students, the examinations office wants an additional identity check before results are published, and the data protection office wants the number of identity attributes kept to a minimum. All three have influence, none is unreasonable, and they are in direct conflict about the payload of the same integration.

    Hint: A strong answer distinguishes resistance from conflict and names the artefact that resolves it.

Show answers
  1. Resistance is a relationship problem: one party disagrees and can be engaged, persuaded, or at least kept informed, and the project can proceed. Conflict is an authority problem between parties who understand each other and hold incompatible objectives, so engagement cannot resolve it; only a decision by someone with authority over both can. Resistance needs understanding and honest engagement; conflict needs a decision request with options, and a recorded outcome.
  2. It converts a vague rating into the specific thing the stakeholder can do — withhold sign-off, decline to release data or a person, escalate to the board, brief the press. That determines what the project must actually do about them, and it captures influence that formal governance does not see, such as a supporting team whose cooperation is needed after go-live.
  3. Escalate to a named decision-maker with authority over both parties, with a deadline attached to the request, and state the consequence of the decision not being made — a date, a scope reduction, or a risk accepted. If no such person exists, that is the finding, and it should go to the sponsor as a governance problem: a project cannot be held to a date by people who will not resolve its blocking trade-off.
  4. For example, a booking system with both "clinician triage" and "direct booking" modes because two stakeholders could not agree. The costs are testing every combination, documenting both paths, maintaining both indefinitely, and the political argument reopening every time one path misbehaves. The flag converts a decision that should have been made once into a permanent liability.
  5. Refuse, in writing, with the reason — an omission that misleads users about a known limitation is a misrepresentation, and release notes are a communication to users rather than a marketing decision. It differs from a stakeholder problem because the resolution is not agreement: the professional obligation is independent of what the stakeholder wants, and the reference point is a code of ethics and, where applicable, law or regulation. Escalate, record the request and the refusal, and expect this to be easier if you decided your position before being asked.
  6. This is not resistance, which is a relationship problem; it is conflict between stakeholders, which is a design and decision problem — there is no single conversation that makes it go away. Map each stakeholder's position on the decision and their leverage (the teaching office sets the student experience, examinations controls the results release, data protection holds a legal veto), then make the trade explicit in one artefact: an interface or decision record that states the identity attributes exchanged, at which step, why each is needed, and who accepted the residual risk. The resolution is usually not compromise on the payload but a design change that satisfies the constraints differently — for example moving the extra check to the results-publishing step so it is not carried in the sign-on payload at all. What to avoid: solving it by quietly satisfying whoever is loudest, and resolving it in corridor conversations that leave two of the three parties unaware of what was agreed.

Summary

  • The hard stakeholder case is not resistance but conflict between stakeholders, which is an authority problem rather than a relationship one.
  • Map more than interest and influence: record each stakeholder's position as a decision, their leverage as a concrete action, what they need to agree, and the cost of excluding them.
  • When objectives conflict, state them in the same measurable units, quantify the trade-off roughly, and escalate with options and a recommendation.
  • Record decisions with their basis, including where a decision went against advice. That record is what makes the decision revisitable and protects everyone involved.
  • Structural tools do this work: a named decider, a written boundary, a costed trade, a small experiment, a staged release. Configuration flags are the symptom of a decision nobody made.
  • Stakeholder management has limits: you cannot satisfy everyone, power is asymmetrical, and some disagreements are ethical rather than managerial — where the response is refusal and escalation, not another communication plan.

Further learning

The ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice (1999) is the verifiable reference for the professional obligations mentioned in section 5; it is published jointly by the ACM and the IEEE Computer Society and is freely available from both organisations.