Skip to content

Lesson 1 — Stakeholders and Governance

At a glance

  • Module: 02 — Project Initiation & Stakeholders
  • Level: Beginner
  • Estimated time: 35 minutes
  • Example project: the LMS and the hospital appointment system

Learning objectives

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

  1. Identify the stakeholders of a project, including those who can block it without being users.
  2. Analyse stakeholders by influence, interest, and attitude, and explain what each combination implies for engagement.
  3. Explain how governance allocates decision rights, and identify the approval path for a change on a given project.
  4. Construct a stakeholder register that another person could act on.

Prerequisites

Introduction

Projects do not fail because the code is wrong. They fail because the wrong people were not consulted, because someone with the power to stop the work was surprised by it, or because nobody could say who was allowed to approve a change.

Both problems are addressed before any planning starts. Identifying stakeholders tells you whose interests have to be satisfied; defining governance tells you who decides what and how disagreements are resolved. Get these right and most later conflicts become routine. Get them wrong and every decision becomes a negotiation.

1. Who counts as a stakeholder

A stakeholder is anyone who affects, is affected by, or believes they are affected by the project. The third clause matters: a group that merely believes it is affected can still create serious problems, so belief is enough to make them a stakeholder.

Stakeholders are rarely just "the users". For a university LMS, they include:

Stakeholder Interest
Students Use it daily; want it to work during exams
Teaching staff Publish materials and grades; some resist change
Teaching and learning office Sponsors the project; wants adoption
IT operations Must run and secure it; can veto technical choices
Accessibility office Requires compliance; can block release
Examinations office Depends on grade data; a downstream consumer
Data protection officer Regulates personal data; approval is mandatory

Note that IT operations, the accessibility office, and the data protection officer are not users, but each can stop the project. These are the stakeholders teams most often forget.

2. Analysing stakeholders

Recording names is not analysis. What matters is each stakeholder's influence (can they stop or redirect the project?), interest (do they care about the detail?), and attitude (supportive, neutral, resistant, or unaware).

Influence Attitude What it means What to do
High Supportive Your strongest ally Keep them informed; use them to unblock others
High Resistant Can stop you and does not want this Highest priority: understand the objection
High Unaware A risk waiting to happen Inform them before they find out
Low High interest Affected, cannot decide Keep informed; they will notice exclusion
Low Low interest Monitor only Brief updates; do not over-report

The dangerous quadrant is high influence with resistance. It is dangerous precisely because it is easy to avoid: nobody wants to talk to the person who opposes the project. Avoiding them is how a project discovers its blocker at the release meeting.

Hospital appointment system (illustrative)

A developer assumes the users are clinicians. In the hospital appointment system, the reception staff actually run the current process and will be the heaviest users. Ignoring them means the new system is designed around a workflow nobody performs; the clinicians, meanwhile, are a high-influence group whose concerns are about appointment duration, not data entry.

3. Governance and decision rights

Governance is the set of rules that says who decides what, and how disputes are resolved. It answers four questions:

  1. Who sponsors the project? The senior person accountable for the business outcome.
  2. Who approves scope and budget changes? Usually the sponsor, within defined limits.
  3. What may the project manager decide alone? Day-to-day trade-offs, within the baseline.
  4. How is a deadlock broken? An escalation path with a named decision-maker.

A project without an explicit answer to question 3 produces a manager who either cannot decide anything — and is therefore a bottleneck — or decides everything and surprises the sponsor.

flowchart TD
    accTitle: Who decides when a change affects the baseline
    accDescr {
    The sponsor, who owns the outcome, asks whether a change affects the baseline. If it does not,
    the project manager decides. If it does, the sponsor or steering group approves. Either decision
    is recorded in the change log.
    }
    S[Sponsor<br/>owns the outcome] --> C{Change affects<br/>baseline?}
    C -->|No| P[Project manager decides]
    C -->|Yes| A[Approval: sponsor or steering group]
    P --> R[Recorded in the change log]
    A --> R

4. Engagement planning

Analysis becomes useful only when it turns into a plan. For each high-influence or resistant stakeholder, write down what they need, in what form, how often, and who will provide it. That is the minimum; Module 10 develops it into a full communication plan.

A practical test: could you hand your stakeholder register to a colleague and have them run the engagement without asking you anything? If not, it is a list, not a plan.

Key terms

Term Meaning
Stakeholder Anyone who affects, is affected by, or believes they are affected by the project
Influence The ability to stop, redirect, or accelerate the project
Governance The rules determining who decides what, and how disputes are resolved
Decision rights The specific decisions a role is authorised to make
Sponsor The senior person accountable for the project's business outcome
Escalation Raising a decision to someone with the authority to resolve it
Stakeholder register The maintained record of stakeholders and their engagement needs

Worked example

Task: build the first section of a stakeholder register for the illustrative LMS project.

Step 1 — Brainstorm without filtering. List everyone who touches, funds, runs, regulates, or is affected by the system. Include negative and indirect stakeholders. Do not assess them yet.

Step 2 — Rate each one. For each, record influence (low/medium/high), interest (low/medium/high), and attitude (supportive/neutral/resistant/unaware).

Name / group Influence Interest Attitude
Teaching and learning office High High Supportive
IT operations High Medium Neutral
Accessibility office Medium High Unaware
Data protection officer High Low Neutral
Departmental teaching staff Medium High Resistant
Students Low High Unaware

Step 3 — Find the dangerous cells. The data protection officer has high influence and low interest, and is currently neutral. High influence plus low engagement is a classic late blocker: they will engage only when a problem reaches them. The accessibility office is unaware with medium influence and high interest — it should be informed immediately.

Step 4 — Turn attitude into action. The resistant teaching staff are the real risk: medium influence but high interest, and numerous. The action is not to argue but to ask what they are concerned about, and to test the assumption that the concern is about the tool rather than the change.

Step 5 — State the engagement plan for the top three. For each, record what they need (a fortnightly demo, an early technical review, an accessibility consultation), how often, and who owns it.

Step 6 — Set the governance. Name the sponsor (teaching and learning office). State that scope changes require sponsor approval above one week of effort, that the project manager decides trade-offs within the baseline, and that technical vetoes belong to IT operations and the data protection officer.

Common misconceptions

“Users are the stakeholders”

Users are a subset. Funders, operators, regulators, security, and accessibility functions can each stop a project while never using it.

“High interest means high influence”

They are independent. An enthusiastic department with no budget authority cannot approve anything; a disinterested compliance officer can veto everything. Rate them separately.

“Governance is bureaucracy”

Governance is the answer to "who decides?". A project without it does not avoid the question — it discovers the answer at the worst possible moment, usually in an argument.

Practical activity

Build a stakeholder register. Choose one of the example projects you did not use in the worked example.

  1. List at least eight stakeholders, including three who are not users.
  2. Rate each for influence, interest, and attitude.
  3. Identify every stakeholder with high influence, and state whether they are supportive.
  4. Write engagement actions for the three highest-risk stakeholders, using the Stakeholder Register template.
  5. Define the four governance answers: sponsor, change approval, project manager authority, and escalation path.

What "good" looks like: a high-influence stakeholder you initially missed, and at least one engagement action that is uncomfortable (talking to the resistor). A register containing only supportive users is not yet analysis.

Self-assessment

  1. Why does "believes they are affected" belong in the definition of a stakeholder?
  2. A stakeholder with high influence and low interest is currently unaware of your project. What is the risk, and what do you do about it?

  3. Why should the project manager's authority be written down rather than assumed?

  4. Apply it — hospital appointment system. The outpatient department sponsors the project. The clinicians who will use the system say they were never consulted and are writing collectively to the medical director. The hospital's data protection officer holds a veto on anything that touches patient data. The clinical scheduling manager is enthusiastic about the project but controls no budget.

    Hint: A strong answer names the dangerous influence-and-attitude combination and gives one concrete engagement action for it.

Show answers
  1. Because perception creates real behaviour. A group that only believes it is affected can still campaign, escalate, or block. If you treat them as a non-stakeholder, you are managing the situation only in your own head, not in theirs.
  2. The risk is a late, unbudgeted constraint or veto: they will engage at the moment their interest is triggered, usually when something is nearly finished. The response is proportionate early contact — a short briefing that gives them the choice of staying informed, so that you learn their constraints while they are still cheap.
  3. Because authority that is assumed is authority that can be withdrawn retroactively. If it is written down, the project manager knows what they may decide without asking, and the sponsor cannot later claim a decision was unauthorised. An unspecified boundary produces either a bottleneck or an unpleasant surprise.
  4. The dangerous combination is high influence with resistance or unawareness, and there are two of them. The clinicians have high influence over whether the system is used at all and are now actively resisting: a resistance that is high-influence cannot be managed with a presentation, so bring them in as designers of their own workflow and let their objections change the scope. The data protection officer's influence is a formal veto, which is engaged cheaply and early through the review gate — and must not be discovered at release. The scheduling manager is high interest, low influence: keep them informed and use them as the route to the clinicians. The sponsor, who is accountable, must hear about the clinicians' letter from you before it escalates without you.

Summary

  • A stakeholder is anyone who affects, is affected by, or believes they are affected by the project — including the operators, regulators, and functions that can veto it.
  • Analyse stakeholders by influence, interest, and attitude separately; the dangerous combination is high influence with resistance or unawareness.
  • Governance answers who decides what and how deadlocks are broken. It is a decision tool, not paperwork.
  • Analysis becomes useful only when it turns into written engagement actions someone else could execute.

Further learning

Next

Continue to Lesson 2 — Project Initiation and the Business Case.