Last updated: 2026-10-06

U
Undergraduate level

Stakeholders and Working With Clients

Every project has people who are affected by it, people who can change it, and people who will judge it. Some of them are obvious, such as the supervisor and the client. Others are less visible, such as the participants whose data is used, the colleagues whose systems are touched, or the assessor who reads the final report. Missing one of them usually means a late change, and late changes are the most expensive kind.late changes cost more than fixing early

This page covers how to identify stakeholders, how to decide which ones need the most attention, and how to work with a client or supervisor in a way that keeps the project's decisions visible. It connects to Scope, Feasibility, and Defining Success, because requirements come from stakeholders, and to Ethics, Security, Sustainability, and Professional Conduct, which covers the obligations stakeholders can reasonably expect.

What a Stakeholder Is

The term was introduced to management thinking by Freeman, who argued that a firm should be managed with regard to the groups that can affect or are affected by its objectives[1]. The idea carries over to a project without much change. A stakeholder is anyone who can affect the project's outcome or be affected by it. For a student project this list is usually longer than students expect.includes silent ones: users who never complain

A quick way to build the list is to walk through the project's life. Who supplies the data or the system? Who uses the result? Who reviews the work, and who approves the ethics? Who would notice if the project went wrong? Each answer is a stakeholder, and each one should be written down.

Deciding Who Matters Most

Not every stakeholder needs the same attention. A useful way to decide is to ask whether each one has power over the project, whether their claim on it is legitimate, and whether they need a response urgently. Mitchell, Agle, and Wood proposed that stakeholders who hold some combination of these attributes are the ones a manager should attend to most closely[2]. The rule translates to a project as a short question for each stakeholder:power, legitimacy, urgency: the 3 filters

  • Power. Can they stop, redirect, or sign off the work?
  • Legitimacy. Is their interest in the project one that should be taken into account, such as a participant whose data you are using?
  • Urgency. Do they need something from you soon, such as an ethics approval or a data request?

Stakeholders who score on all three need regular contact. Those who score on one or two need a clear channel and an update at the right points. Those who score on none need to be recorded, so that their absence is a decision rather than an oversight.

Working With a Client or Supervisor

Most friction with a client or supervisor comes from unstated expectations rather than from disagreement. Settle the following early and write them down:

  1. How often you will meet, and how. A fixed fortnightly slot is more reliable than arranging meetings as they become necessary.
  2. What you need from them, and by when. A specific request with a date gets a response far more often than a general wish for feedback.
  3. Who decides what. Which decisions belong to you, which need agreement, and which are theirs alone. Scope changes should be in the decision list.
  4. What counts as sign-off. A written confirmation that a milestone is met, even a short email, is worth more than a verbal "that looks fine".
Send a short written summary after each meeting. Three lines are enough: what was agreed, what you will do, and what you need from them. It protects both of you when memories differ.

When a client's request conflicts with the success criteria, do not absorb it silently. Explain the trade-off in writing. Either the criteria change, with the change recorded, or the request goes into the list of deferred work. Both are legitimate outcomes. Quietly doing more than agreed is not.

Stakeholders Who Are Not in the Room

Some of the most important stakeholders will not attend any meeting. Participants in a study, users of a system, and the people whose data appears in a dataset all have interests in the project, and their interests are often the ones most easily overlooked. Their requirements usually appear as constraints: consent, anonymity, storage, and the right to withdraw. These are covered in the ethics pages linked from the professional responsibilities page, and they should be on the stakeholder list from the start.

When Stakeholders Disagree

Stakeholders will sometimes want incompatible things. A client may want a feature that the supervisor considers out of scope. A participant group may want faster results than the evaluation design allows. The approach that works best is to make the conflict visible, identify the decision that resolves it, and name the person who makes it. Then record the decision and its reasons. A project that carries an unresolved disagreement into the report will be marked down for it, whichever side turns out to be right.

References

  1. Freeman, R. E. (1984). Strategic Management: A Stakeholder Approach. Pitman.
  2. Mitchell, R. K., Agle, B. R., & Wood, D. J. (1997). Toward a theory of stakeholder identification and salience: Defining the principle of who and what really counts. Academy of Management Review, 22(4), 853–886.