A stakeholder map for cross-functional work
By Alice Huang, Chief of Staff and operator
Build a stakeholder map around who decides, contributes, does the work and is affected. Verify needs and choose a communication plan.
If a project touches several teams, knowing the org chart is not enough. Find out who makes the decision, who has useful information and who will live with the result.
Atlassian describes stakeholder mapping as identifying people or groups who influence or are affected by a project, understanding their needs and planning engagement. Treat the map as something to check with people, not a scorecard of who is important.
Start with the work
Name the project and decision. List the people doing the work, the approver, contributors and affected teams. Include outside parties where the project actually depends on them.
DACI helps separate decision roles. An expert contributor is not necessarily the person with the final call.
Ask what people need
What changes for them? What information do they hold? What constraints could the project miss? What do they need before the next step?
Do not infer motivation from a title or difficult meeting. Ask, and keep anything unconfirmed as an open question.
A simple map
- Person or team and project role.
- Decision, contribution or work owned.
- How the project affects them.
- Information or concern to check.
- Update method, audience and next touchpoint.
This is a suggested outline. Keep unrelated personal details and sensitive judgments out. Being affected does not give everyone access to every private document.
Prevent surprises
Confirm the communication plan and revisit it when scope or ownership changes. Atlassian's dependency guidance also asks teams to name owners and feedback loops. That helps when progress depends on another team's work.
The map should help you involve people at the right point. If it becomes a diagram nobody consults, simplify it until the next decision and conversation are visible.