What is stakeholder analysis?
Stakeholder analysis is a structured way to identify who is affected by a project, who can influence it, and what engagement is needed. It makes the human context of a change visible before the team assumes that an internal project meeting represents everyone involved.
Elrha's Humanitarian Innovation Guide discusses both the impact of a solution on people and people's influence on its adoption. Its guidance also recommends revisiting the map. This article adapts that general planning idea to an original fictional SaaS rollout.
The exercise concerns a change to a client-file intake workflow in a fictional app called BriefRelay. Every role note, observation, and engagement decision below is invented teaching material, not real customer research or a description of ShowMeYourSaaS users.
Download the register and engagement worksheet
The CSV provides a completed fictional stakeholder register with role, effect of the change, need, influence context, evidence status, engagement action, owner, and review trigger. The text worksheet includes a blank analysis form and a meeting review checklist.
Replace the example with the people and groups relevant to one bounded project. Use permitted role references where names are unnecessary, and keep private contact details in the appropriate controlled system.
These files do not calculate a person's importance or make access decisions. Their purpose is to identify useful participation and unresolved needs. Record unknowns as unknowns rather than filling a map with plausible but unsupported opinions.
Bound the project and identify affected groups
The fictional project changes how a coordinator requests missing client files. The analysis covers that rollout and its permitted pilot, not every relationship in the company. A clear boundary helps the team decide whose experience could change.
Start with the workflow. The agency coordinator prepares the intake, the client uploader provides files, Support handles questions, Engineering maintains permissions, and Product owns the rollout decision. A security reviewer contributes to the access boundary.
Now look for missing perspectives. A buyer may approve spending without uploading files. A recipient may use a shared device or require an accessible interaction. Treat these as questions to investigate in the relevant context, not demographic assumptions about a whole audience.
Include external participants and people with little formal decision power when the change affects them. A map focused only on senior approvers can miss the person who must actually complete the task.
Record needs and influence without confusing them
Affectedness describes what changes for a stakeholder. Influence concerns how they can affect the project in this context. Interest concerns the issue's relevance to them. These are related but different observations; no single label captures the whole relationship.
In the exercise, the coordinator needs to know whether the next action belongs to the agency or client. The client uploader needs a clear permitted request without exposure to another client's files. Support needs enough safe context to route a failure.
Product owns the rollout decision, while the uploader's practical influence may come through whether the task can be completed. That does not make the uploader's experience less important. Use the distinction to plan participation rather than to ration respect or ignore a risk.
Where influence is uncertain, state the basis. Has the role approved this type of change before, operated the workflow, or only appeared in an assumption? Do not turn a job title into evidence of authority.
| Stakeholder role | Need to investigate | Planned participation |
|---|---|---|
| Agency coordinator | Recognize the next owner of an intake action | Review a prototype task |
| Client uploader | Provide the requested file within the correct boundary | Observe a permitted synthetic task |
| Support | Route a failure without exposing private material | Walk through a failure handoff |
| Engineering and security reviewer | Verify the access boundary and recovery implications | Review technical evidence |
| Product owner | Choose a bounded release decision | Review scope, evidence, and unresolved conditions |
Separate observations, assumptions, and engagement choices
The register's fictional evidence labels remain visible beside each need. In a real project, link an interview note, support pattern, policy, or role agreement with enough context for a reviewer to assess it. Do not invent an interview quote to make a stakeholder row look researched.
An observation that a coordinator maintains a separate checklist supports a question about missing status information. It does not prove that a new reminder feature is the right answer. The engagement action can be a prototype review that investigates that question.
Record what could change the analysis. A new permissions model, a different buyer, or a larger rollout audience can introduce people whose needs were outside the original scope. A stale map should not be used as evidence that consultation is complete.
Turn the map into an engagement plan
Choose a specific action, owner, and purpose for each relevant engagement. Consult Support is vague. Walk through a synthetic expired-upload request with the support owner to check the handoff gives the meeting a task and a useful result.
Match participation to the decision. An affected user can help evaluate the task, while an authorized reviewer assesses the permission boundary and a sponsor approves the commitment. A usability session does not replace an authorization review, and a sponsor's approval does not establish usability.
Make communication reciprocal. Record questions raised, evidence provided, unresolved disagreement, and the next owner. Sending a status update is not proof that the recipient understood or accepted the proposed change.
Use the customer interview guide and usability testing plan when those methods fit the question. Keep participants' actual permission and context separate from a planning assumption.
Connect stakeholder analysis to RACI and personas
A RACI matrix assigns responsibility, accountability, input, and updates to activities. Stakeholder analysis first asks who may need consideration and why. It can reveal someone missing from the responsibility discussion without assigning them a role automatically.
A user persona summarizes a recurring pattern among product users. A stakeholder register concerns a particular project's relationships and participation. The buyer, support operator, technical reviewer, and affected end user may all belong in the register even when only one persona informs the interface.
The customer journey map follows a person's steps and experience over time. Use it when the team needs to understand the sequence of work, then connect relevant stakeholders to the handoffs the map exposes.
Review what the analysis changed
At the next decision, ask which previously missing need or perspective affected the scope, test, communication, or rollout plan. The value is the improved decision and participation, not the number of rows in the register.
Name a review owner and trigger. Preserve the dated rationale for consequential choices, and revise assumptions when new evidence contradicts them. If every row says keep informed, check whether the team has avoided a real consultation or decision question.
The downloadable register and worksheet were checked for consistent fictional labels and distinct engagement purposes. No stakeholder research or live rollout was performed for this example. Source and original materials checked October 28, 2026.