Understanding stakeholders
“The biggest risk to your project is rarely the code. It’s the person you forgot to ask.”
Every year, some group of students builds a genuinely impressive piece of software and then gets a mediocre grade or an unhappy client, not because the code was bad, but because they built the wrong thing for the wrong person — or built the right thing but never got buy-in from someone who could have quietly killed the project at the end. Usually, that someone was a stakeholder nobody thought to ask.
Before you write a single line of code, before you even finish your requirements, you need to know: who actually cares about this project, and what do they each want from it?
What is a stakeholder?
A stakeholder is anyone who affects, or is affected by, your project. That's a deliberately wide net. It's not just "the client." It includes:
- The client / project owner — the person or organisation who commissioned the work and will (hopefully) use or sell it.
- End users — the people who will actually click the buttons. Often not the same person as the client.
- Your supervisor / module coordinator — they grade you, and they have their own expectations about process, documentation, and rigor that have nothing to do with what the client wants.
- Your teammates — yes, really. They have a stake in the project's success (their grade too) and in how the work gets divided.
- Regulators, IT/security staff, future maintainers — anyone downstream who will have to live with the decisions you make now.
Notice something: these groups don't always want the same thing. The client might want a flashy feature shipped fast; the end users might just want the thing to load quickly and not be confusing; your supervisor wants to see a properly documented process; and the future maintainer (possibly a version of you, six months from now) wants code that doesn't make them cry. Managing a project is largely managing this tension.
Why is this important?
Skipping stakeholder analysis is one of the most common (and most avoidable) ways student projects go wrong. A few concrete failure modes:
- You build for the person who talks to you the most (often the client's junior contact) and completely miss what the actual decision-maker cares about — then get told to redo half the project two weeks before the deadline.
- You never talk to real end users, so your "intuitive" interface makes perfect sense to you and to no one else.
- You assume your supervisor just wants "a working app," when really 40% of the grade is about your process, documentation, and justified design decisions.
- A stakeholder with quiet but real power (an IT department that has to approve deployment, a compliance officer, a professor who has to sign off) gets ignored until the very end, when they turn out to have a veto.
Doing this analysis early costs you maybe an hour or two. Doing it never can cost you your entire final sprint.
How to identify and analyse your stakeholders
Step 1 — Brainstorm broadly. List everyone who touches this project in any way, even loosely. Don't filter yet. Ask: who asked for this? Who will use it? Who has to approve it? Who could block it? Who inherits it after we're done?
Step 2 — Map them on a power/interest grid. This is the classic tool (sometimes called Mendelow's Matrix) for making sense of a messy list of names. Draw a 2x2 grid: power (how much influence they have over the project's success or failure) on one axis, interest (how much they actually care) on the other.
- High power, high interest — manage these people closely. Usually your client and your supervisor.
- High power, low interest — keep them satisfied. A department head who signed off on the project but isn't in the weeds — don't overload them, but don't blindside them either.
- Low power, high interest — keep them informed. Often your actual end users. They can't override decisions, but ignoring their feedback is how you end up with something no one wants to use.
- Low power, low interest — monitor with minimal effort.
Step 3 — Write down what each one actually wants. Not what you assume they want — what they've told you, or what you need to go ask them. This is the bridge into requirement analysis: stakeholders are the source of your requirements, and mixing up whose requirement is whose is a very common source of conflicting specs later on.
Step 4 — Revisit it. Stakeholder maps aren't static. A quiet stakeholder can become a loud one the moment you show them a prototype. Check in on this every few weeks, not just once at kickoff.
A worked example
Say your team is building a course sign-up tool for a university department. At first glance, the "stakeholder" is just "the department." Dig one level deeper and you'll usually find:
- The programme coordinator who requested it (high power, high interest — the actual client).
- Students who will use it to sign up for courses (low power, high interest — they can't change the spec, but if the tool is unusable they will complain loudly, and rightly so).
- The university's IT department, who has to approve where and how the tool is hosted, and what data it can store (high power, often low interest until you break a policy they care about).
- Academic staff whose timetables depend on accurate sign-up data (low power, medium interest).
- Your module supervisor, who is grading your process and documentation, not just the final product (high power, high interest, and easy to forget because they aren't the "client").
Five very different groups, five different sets of expectations, all tangled up in what looks like a simple "build us a sign-up tool" request. That's the norm, not the exception.
Tips
- Ask "who else should I be talking to?" at the end of every stakeholder conversation. It's the cheapest way to surface people you missed.
- Don't confuse "the person emailing me" with "the stakeholder." Sometimes you're only ever in contact with a proxy, and the real decision-maker only appears at the final review — with opinions.
- Write your stakeholder map down somewhere your whole team can see, and keep it in your documentation. Supervisors like seeing that you actually did this deliberately, rather than by accident.
- When stakeholders disagree, don't just pick a side — go back to the root cause analysis approach to figure out why they disagree. Often it's not that they want different features, it's that they're solving for different underlying problems.
References
Sethi, R. Software Engineering: Basic Principles and Best Practices — a solid grounding in stakeholder identification and requirements as part of the wider software engineering process.
Mindtools — Stakeholder Analysis
Video: Stakeholder Analysis — How to Use the Power/Interest Grid