Skip to content

Lab 02 — Identifying and Classifying Stakeholders

At a glance

Learning objectives

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

  1. Generate a stakeholder list from a project description rather than from memory of who attended a meeting.
  2. Classify stakeholders by power and interest, and choose an engagement stance for each.
  3. Identify stakeholders who will change position as the project progresses.
  4. Choose one pre-emptive action for a stakeholder who is currently uninterested but will become decisive.

Scenario

The provincial government has funded a Public Service Complaint Management System. Citizens will lodge complaints about municipal services — street lighting, waste collection, water supply, road repair — through a web form or a phone line staffed by operators. Complaints are routed to the responsible department, tracked against a service-level target, and closed with a response to the citizen. The public will be able to see aggregate complaint volumes by district.

The funding was announced publicly, so the launch date is a political commitment. The province's IT department will host it. Each of the five municipal departments must accept complaints through the system, and each has its own existing paper register.

Facts about the stakeholders, as far as anyone knows today:

Who What is known
Provincial minister for local government Announced the launch date publicly. Wants visible improvement in response times.
Provincial IT department Hosts systems; must approve the security architecture; has a two-month approval queue.
Municipal department heads (five) Each owns a department whose work changes. Two are supportive, one has objected publicly to "being monitored", two are undecided.
Department complaints clerks Will process complaints in the new system instead of a paper register. Fear job evaluation by complaint volume.
Call-centre operators Will register complaints by phone. Concerned about training time and system speed.
Citizens, including an active residents' association Will lodge complaints. The association has campaigned for years for a public complaint process.
Provincial auditor general Will audit whether complaints are resolved within the published service levels. Currently uninvolved.
A local advocacy group for disability rights Has not been contacted. Will examine accessibility of the citizen-facing form.
The project's own developers (a contracted firm) Delivering the system; their contract includes penalty clauses for late delivery.

Your role

You are the project manager appointed by the provincial IT department. You have four weeks before requirements workshops begin, and no stakeholder map exists.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Launch date: fixed, fourteen months from funding approval, announced publicly.
  • Budget: fixed for this financial year.
  • Five municipal departments must be onboarded; each has its own complaint categories and registers.
  • A citizen-facing service in this jurisdiction is expected to meet accessibility expectations, and the applicable standard must be confirmed rather than assumed.
  • No department has been promised extra staff for the transition.
  • Assume the existing paper registers contain inconsistent categories, and that this is a data migration problem rather than a stakeholder problem.

Work with these facts as given. Where you need an assumption to proceed, write it down and label it as an assumption.

Tasks

Task 1 — Generate the stakeholder list

Start from the scenario, not from the table alone. For each stakeholder group, note what they contribute, what they receive, and what they can do to the project.

Then add at least two groups the scenario does not name. Justify each addition in one sentence. (This is the part that distinguishes a real map from a copy of the facts you were given.)

Task 2 — Classify by power and interest

Place each stakeholder on a power/interest grid. For each, record:

  • Power: can they affect the outcome (approve, block, fund, delay, or refuse to adopt)?
  • Interest: do they care about this project's outcome, now?

Then choose an engagement stance for each: manage closely, keep satisfied, keep informed, or monitor.

Task 3 — Identify who will move

At least three stakeholders will change position during the project. Identify them, state the trigger that will move them, and whether the move makes them more or less helpful.

Task 4 — One pre-emptive action

Choose the stakeholder with high power and low current interest. Write one concrete action you will take in the next four weeks to engage them before they become decisive. Be specific about who does what and by when.

Task 5 — Classify the resistance

One department head has publicly objected to "being monitored". Write two or three sentences explaining what information that objection might carry — treat it as data, not as obstruction — and what you would do with it.

Deliverable

  1. A stakeholder map — a table is fine, or a labelled diagram.
  2. A classification table: stakeholder · power (H/M/L) · interest (H/M/L) · stance · rationale.
  3. A movement table: stakeholder · trigger · new position · implication.
  4. One pre-emptive action paragraph, naming the stakeholder, the action, the owner, and the date.
  5. Your answer to Task 5, in two or three sentences.

Use the Stakeholder Register template if you find it helpful, or a plain table for the map itself.

Hints and guidance

  • Power and interest are not the same as like and dislike. A hostile but powerful stakeholder needs more management, not less.
  • Interest is time-dependent. A department head with no involvement today may become highly interested the week their staff begin using the system.
  • Look for the missing stakeholder. Ask: who bears a consequence if this succeeds? Who bears a consequence if it fails? Who is legally or professionally obliged to review it?
  • Resistance often carries a requirement. "Being monitored" frequently encodes a concern about how performance data will be used — which is a design question you can act on.

Self-check criteria

Check How to verify it
Stakeholder list is complete enough Every group named in the scenario appears, plus at least two you added with a justification
Classification is not arbitrary Each power and interest rating has a one-line reason
Stance matches the grid No stakeholder is marked "manage closely" while rated low interest and low power
Movement analysis is present At least three stakeholders with a named trigger each
The pre-emptive action is actionable It names a person, an action, and a date
Resistance is treated as information Task 5 states what you learned from the objection, not just how you will overcome it

Reflection

  1. Which stakeholder was hardest to classify, and what information would resolve the difficulty?
  2. Did you add a stakeholder the scenario did not name? What made you think of them?
  3. Which stakeholder, if you ignore them, is most likely to stop this project outright?
  4. The launch date is a political commitment. How does that affect the stance you take with the minister?
Model discussion points

These are reasoning prompts, not a marking scheme — there is more than one defensible map.

  1. The auditor general is typically the hardest: high power, near-zero current interest, and the power arrives only at audit time. The information that resolves it is whether published service levels create an audit obligation.
  2. Plausible additions include the citizens' data-protection or privacy regulator (a complaint system holds personal data), municipal frontline supervisors (whose staff change how they work), the hosting and operations team that must keep the service available, the procurement or legal office handling the developer contract, and the press, which will report on the published response times.
  3. The auditor general or the privacy regulator, because both can invalidate the operating model after delivery rather than merely slow it down.
  4. A public commitment makes the date a constraint, so the right stance is to keep the minister accurately informed of forecast variance — including bad news — rather than to protect them from it. Discovery at launch is far more damaging than a warning at month six.

Extension challenge

Two municipal departments refuse to onboard until the system matches their existing paper register categories exactly. Model this as a stakeholder problem rather than a requirements problem: produce a one-page engagement plan that would move both to at least neutral within six weeks, without changing the launch date or adding budget. State the single concession you would be willing to make and why it is cheaper than the delay it prevents.