Stakeholders & Their Needs

Stakeholders & Their Needs

Every system exists to serve people — and those people rarely agree on what "serving them" means. A stakeholder is any person, group, or organisation that is affected by a system or that can affect the outcome of a project. Identifying all relevant stakeholders early, understanding what each of them needs, and balancing those needs against one another is one of the most critical skills a systems analyst can develop. Getting it wrong means building a system that technically works but that nobody actually uses — or worse, one that actively harms part of the organisation.

Who Counts as a Stakeholder?

The word stakeholder is broader than most junior analysts expect. Consider a clinic booking system being built for a small medical practice:

• Patients — want to book, cancel, and view appointments easily, ideally without phoning the clinic.
• Receptionists — need to manage the schedule, handle walk-ins, and avoid double-bookings.
• Doctors — need accurate schedules, patient history at a glance, and no interruptions to their workflow.
• Practice manager — needs reporting on no-shows, revenue, and staff utilisation.
• IT administrator — needs the system to be maintainable, secure, and backed up.
• Health authority / regulator — requires that patient data is handled according to privacy law.
• Software vendor / development team — needs clear, stable requirements so the build can proceed on time and within budget.

Notice that some of these stakeholders will never log in to the system at all, yet their interests must still be served. The regulator does not touch a keyboard, but a data-breach fine could shut the clinic down. Always ask: "Who benefits if this goes well, and who is harmed if it goes wrong?"

Categorising Stakeholders by Role

A useful classification for systems analysis practice groups stakeholders into four roles:

1. Owners — those who commission and fund the system (executives, board members, budget holders). They define the high-level vision and set constraints such as budget and deadline.
2. Users — those who interact with the system day-to-day (operational staff, customers, field workers). Their usability and workflow needs drive the detailed functional requirements.
3. Designers & builders — the technical team who implement the system. They need requirements that are precise, testable, and free of ambiguity.
4. Evaluators — those who inspect or audit the system (quality assurance, regulators, auditors). They define the non-negotiable compliance and quality constraints.

Understanding Stakeholder Needs, Wants, and Constraints

Three questions cut through the noise in any stakeholder interview:

1. What problem are you trying to solve? (the real need, which may differ from what they ask for)
2. What does success look like for you? (their definition of value)
3. What is non-negotiable? (hard constraints — budget, timeline, regulatory)

In an online store project, the marketing manager says "I want a homepage carousel with five rotating banners." The underlying need is actually highlighting promotions to increase click-through rates. Locking down the solution (a carousel) too early forecloses better options (a featured-product grid, a hero section). The analyst's job is to surface the need beneath the request.

The Stakeholder Power/Interest Grid

Not all stakeholders deserve the same level of engagement. The Power/Interest Grid (also called the Stakeholder Matrix) is the analyst's go-to tool for prioritising communication effort. It plots each stakeholder on two axes:

• Power — the ability to influence the project's direction, budget, or outcome.
• Interest — how much the stakeholder is affected by or cares about the system.

The four quadrants translate directly into four engagement strategies:

• Manage Closely (High Power, High Interest) — your most critical stakeholders. Involve them in workshops, review every major decision with them, and keep communication frequent and detailed.
• Keep Satisfied (High Power, Low Interest) — dangerous if ignored. They do not want to be bombarded with detail, but a nasty surprise will mobilise them against the project. Send concise executive summaries; escalate risks early.
• Keep Informed (Low Power, High Interest) — often the heaviest daily users. They care deeply and will flag usability problems early if given a channel. Use demos, sprint reviews, and user-testing sessions.
• Monitor (Low Power, Low Interest) — track them in a register but do not over-invest. A monthly status email or a shared portal is usually sufficient.

Running a Stakeholder Analysis: Step by Step

For a logistics firm rolling out a new shipment-tracking portal, a practical stakeholder analysis runs as follows:

1. Brainstorm — list every individual and group you can think of. No filtering yet. Typical outputs: 15–30 entries.
2. Classify — group them into owners, users, builders, and evaluators.
3. Score — rate each on Power (1–5) and Interest (1–5). Use team consensus, not a single analyst's opinion.
4. Plot — place on the grid. Clusters tell you where engagement effort is concentrated.
5. Define engagement approach — for each stakeholder: preferred communication channel (face-to-face, email, shared portal), frequency, and the analyst responsible.
6. Validate — share the register with the project sponsor and key stakeholders. Hidden stakeholders often surface at this step.
7. Maintain — update the register whenever the project moves into a new phase or a major change occurs.

Documenting the Stakeholder Register

The output of this process is a Stakeholder Register — a living document that typically captures: name, role/title, organisation, power score, interest score, quadrant, key interests and concerns, preferred engagement channel, and the analyst who owns the relationship. Modern tools (Confluence, SharePoint, even a shared spreadsheet) all work; the format matters less than the habit of keeping it current.

Common Pitfalls

• Forgetting silent stakeholders — regulators, auditors, and third-party API providers often have the highest power and the least visible presence. Add a "who could block this?" check to your brainstorm.
• Treating users as a monolith — "users" in a logistics portal include warehouse staff scanning barcodes on a handheld device, dispatchers on a desktop, and customers checking delivery status on a mobile phone. Each sub-group has different needs.
• One interview, done — stakeholder needs evolve. A receptionist who says "the current system is fine" in week one may reveal critical pain points in week three once trust is established.
• Ignoring internal politics — two department heads may have conflicting goals. Document it, escalate it, do not paper over it with vague requirements.

Thorough stakeholder analysis is the foundation on which every other analysis activity rests. Requirements elicitation, feasibility studies, and system scope — all of them depend on knowing who you are building for and why they need it.