Stakeholder map: a worked example after a kickoff meeting
Build a stakeholder map from a kickoff. Record interests, influence, decision authority, and a communication plan. Includes a matrix and template.
Who is missing from the attendee list?
A manager may discuss the rollout even though other employees will use the result every day. The person who grants data access or gives final approval may be absent. Treat the attendee list as a starting point.
Use the map to decide who should discuss a decision, see a prototype, or simply hear about the change. It does not rank people. Influence depends on the question and can change across project phases.
Build the map in four passes
Name the project outcome
Describe the change in one sentence and list the affected activities. For example, staff will enter requests in a shared system. Ask who creates, checks, uses, and maintains the data. This reveals stakeholders who missed the kickoff.
Separate interests and authority
Record what the person wants to gain or preserve and what decisions they can make. An active participant may lack budget authority. Mark claims about authority that come from a colleague as needing confirmation.
Decide how to involve each stakeholder
For each issue, choose whether to decide jointly, ask for advice, show a draft, or send the result. Avoid inviting everyone to every meeting by default. State what event triggers their involvement.
Verify and maintain the map
Send stakeholders their relevant roles and agreements. Identify anyone missing. Review the map when the phase, sponsor, or decision owner changes. Different people may run the pilot and approve the full rollout.
Launching a single customer inquiry form
This fictional example uses names, conditions, and outcomes solely to explain the method.
I approve the form, but the support lead knows which fields are required. Staff will fill it in daily. The administrator grants access to the old data.
That one remark calls for four different conversations. Approving the appearance does not approve the fields, and granting access does not make someone responsible for data quality.
The example matrix shows actions for this situation. On a real project, clarify each stakeholder’s interests and influence first, then choose how to engage them.
| Stakeholder | What to clarify | When to involve them |
|---|---|---|
| Sponsor | Who approves the final version | Before approving the form |
| Support | What information is needed to respond | While designing the fields |
| Users | What is unclear when filling it in | During a trial run |
| Administrator | Access requirements and limits | Before migrating working data |
Stakeholder map and communication plan
Record the specific issue that needs this stakeholder’s involvement alongside their name or role.
Stakeholder / working role: How the outcome affects them: Interest or expectation: Decisions they can make: What remains unconfirmed: How to involve them: Event that triggers involvement: Who keeps in touch: Source: meeting, timecode, confirmation: Next review date:
Check who needs to join your next call
- The map includes users of the result even if they missed the kickoff.
- Decision authority is distinguished from team assumptions.
- Each stakeholder has a clear question or action.
- The map has a date and project phase.
A closer look
How does a stakeholder map differ from RACI?
A map shows who is affected and how to engage them. RACI assigns roles for specific tasks. The two documents complement each other.
Do we have to score everyone numerically?
No. For a small team, explain influence, interest, and the involvement needed. Scores without agreed criteria create an impression of precision.