The client is not the only stakeholder
Stakeholders are people and groups who influence a project or are affected by its outcome. Their interests may differ even when everyone supports the overall idea.
The team in this example is launching a new class registration page. The owner wants more suitable enquiries, the administrator wants complete information, teachers want to understand students’ expectations, and visitors want to understand the format quickly. Discussing the project only with the owner could miss a problem when enquiries are handed over.
A stakeholder list is not a mailing list for every message. It helps identify whose knowledge, decisions and expectations matter at a particular moment. A small project only needs a simple record; a complex map is optional.
- Who decides?
Allocates resources, approves boundaries or accepts the outcome.
- Who is involved?
Does the work or supplies necessary information.
- Who is affected?
Will use the outcome or change their process.
An example interest and influence map
| Stakeholder | What matters to them | How to involve them |
|---|---|---|
| Owner | Matching the service to enquiries | Agree on the goal and significant changes |
| Administrator | Clear enquiries and a response process | Check the handling process before launch |
| Teacher | An accurate description of the class format | Clarify the content and limitations |
| Visitor | Understanding whether the class is suitable | Check understanding using an accessible scenario |
The familiar influence–interest matrix helps choose how closely to engage. It does not make people with little influence unimportant. A user may have no management authority and still be best placed to explain why the outcome is difficult to use.
Map ratings are working assumptions, not an objective ranking of people. Interest and influence change as the project progresses. Someone who initially only advised may become essential to accepting a particular deliverable.
How to uncover expectations
Ask what change the stakeholder expects, what concerns them and how they will know the outcome is suitable. Go beyond “What would you like on the page?” The administrator may care more about enquiry quality after submission than the appearance of the first screen.
- Request
“Add more fields.” This is a proposed solution.
- Need
“I do not have enough information to suggest a suitable class.” This is a problem to solve together.
Needs can conflict: the administrator needs information, while the visitor needs a short form. Do not dismiss either side because of their job title. Compare options and check which details are essential at the first step and which can be clarified later.
A communication plan without unnecessary meetings
For each significant decision, identify whom to consult beforehand and whom to inform afterwards. Distinguish consultation from final approval authority. This reduces the risk of five people leaving contradictory mandatory comments.
- Name the event that requires communication.
- Identify the relevant people and their roles in the decision.
- Prepare brief context and a specific question.
- Agree on how and when they will respond.
- Record the decision so it can be revisited.
“Please take a look” creates uncertainty. A more useful message is: “Check whether the information is sufficient for an initial client response; we are not approving the appearance yet.” Defining the question makes feedback actionable.
A form launch map: who is easily overlooked
An enquiry form project has a client, developer and designer—usually the first people named. Yet it also affects the person handling enquiries, a visitor using a mobile device, the person responsible for data, and the specialist maintaining the integration. Forgetting the enquiry handler could produce an easy submission process that nobody follows up.
For each stakeholder, clarify not only their interest but their influence, expectations, authority and the possible consequences of a change. The handler needs the right information and a clear next step. The visitor needs to send a request and receive clear confirmation. The client needs to agree on the outcome’s boundaries. These different expectations cannot be reduced to “make it convenient”.
An interest and influence matrix helps choose communication intensity, but does not justify ignoring people with little formal influence. Their needs may determine quality, accessibility and fitness for use. The map is a communication planning tool, not a ranking of people’s importance.
Check hidden failure points: who might withhold access, who accepts the deliverable, who uses it after handover and who supports it. A conversation before development is usually more useful than explaining after launch why a necessary scenario is missing.
How to handle conflicting expectations
The client wants a minimal one-field form; the handler asks for ten qualification fields. Record both goals: make submission easier and obtain the information needed to respond. Examine each field: why is it needed now, could it be requested later, and how would its absence affect handling? Find a solution through the scenario rather than voting for a favourite layout.
Record the agreed constraint and how to check it. For example, the first version keeps only information essential for a response, with additional questions asked during the next contact. This is an illustrative option whose suitability depends on the process and data requirements. It is not universal advice to shorten every form.
A communication plan connects a message to a decision: who needs a draft before implementation, who receives an update after testing, and who needs instructions before launch. Sending everything to everyone often buries important information in noise.
Review the map when scope or the team changes. A new external service may introduce a dependency and a stakeholder whose deadlines affect the whole project. RACI can then assign responsibility for specific deliverables, but does not replace understanding these interests.
Plan a conversation about a stakeholder’s expectations
Start with one task: “Ask the administrator which enquiry details are essential.” Record the expected outcome in the description: clarity on which details are needed for the initial response and which can wait. You do not need to move the entire article into the service; save what you will need while doing the work.
Schedule the conversation before final form design. Save the specific question and the decision that depends on the answer in the description.
- Create a task with a specific action in its title.
- Add the completion conditions and necessary context to the description.
- Choose a day and check whether the work fits alongside your other commitments.
Signing up for Sinqly is free. You can also work through the article's example in an ordinary document; the app helps you return to the actions you chose.
How to distinguish a stakeholder map from RACI
A stakeholder map shows interests, influence and communication. RACI assigns roles for specific work: responsible, accountable, consulted and informed. Neither replaces the other, but a small project does not necessarily need two separate documents.
Revisit the map when a new user of the outcome appears, the approver changes or the scope shifts. Do not maintain a document simply to have a complete list of names. Its value lies in involving the right people in time and avoiding unexpected conflicts of expectations.
Good communication is directed. The right person receives a clear question while their answer can still influence the work.
More questions to clarify
Is every employee in the company a project stakeholder?
Not necessarily. Include those who actually influence the work or are affected by its outcome. An overly broad list obscures significant connections.
Can job titles be used instead of names?
Yes, if roles are stable and it is clear who currently fills them. For actual communication, you still need a reachable person.
What should you do with conflicting expectations?
Make the conflict explicit, compare the consequences of the options and identify who has authority to decide. Do not silently try to satisfy incompatible requests.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian: stakeholder analysis
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Project communication plan: example, channels and escalation rules
How to create a communication plan: who needs information, how often and who is responsible. A completed launch example, a status message and a response to delay.
SWOT analysis: a small project example and practical next steps
How to fill a SWOT matrix with facts, distinguish internal constraints from external threats, and choose actions after analysis. Detailed case study of a small service.
RACI matrix: how to assign project responsibilities
Explore the four RACI roles through a website launch: who does the work, who accepts the result and who really needs to participate. With a completed example and error checks.