Skip to content
Log in
← Glossary

stakeholder map

Also called: stakeholder mapping, influence-interest grid

A one-page picture of everyone the project affects or depends on, placed by how much they can influence it and how much the result matters to them. It shows whom to involve closely, whom to keep informed and whom nobody has talked to yet.

A stakeholder map is a one-page picture of everyone the project affects or depends on, placed by two questions: how much can this person or group affect the project, and how much does the result matter to them? It turns a vague "keep people in the loop" into a short plan of whom to talk to, how often and about what.

The two questions give four zones. High influence and high interest: work closely with them, involve them in decisions. High influence, low interest: keep satisfied, with short, regular updates and no surprises. Low influence, high interest (often those who will live with the result): keep informed. Low on both: check now and then whether that has changed.

Building the map starts with a wide list, not the org chart: other teams who must change their work, people who will support customers after launch, outside parties whose calendars or rules you depend on. The most useful finding is usually someone nobody has mapped. Some stakeholders you can't talk to at all; turn what you depend on from them into a written assumption with a check and a date.

The map also shows where you will need influence without authority. With people you don't manage, start from their constraint, make one small and specific request with dates, offer something in return and confirm it in writing. Escalating to the sponsor is a last step after an honest attempt, and you tell the person before you go. Revisit the map when the project changes stage: people move between zones.

Example

The map for Klasna's physics launch in December:

Who
Influence
Interest
Zone
Leo, CEO and sponsor
high
high
work closely
Vira, academic lead
high
high
work closely
Hanna, head of finance
high (the 600,000 UAH ceiling)
low
keep satisfied: a monthly budget check, no surprises
Support coordinators
low
high: they answer families' physics questions from February
keep informed; nobody had told them anything yet
Roman, tutor operations
high for onboarding
low in his January peak
moved to work closely until onboarding is done
The candidates' schools
high, through their timetables
none
not on the map at first

The last row is the stakeholder nobody mapped. Four of the six candidates who passed the demo lesson teach at schools and can't promise February slots until the second-term timetable comes out in early January. The plan assumes about 15 learners per tutor, so it rests on calendars no one in the project controls. The lead writes it down as an assumption with a check: confirmed weekly slots from each tutor by 10 January.

Roman declined a separate physics onboarding in January. Instead of asking Leo to order him, the lead asked for one small thing: physics tutors join the weekly English onboarding session in the second week, and the lead covers the subject part.

Common mistakes

  • Mapping only the org chart. Support teams, other departments and outside calendars can stop a launch too.
  • Drawing the map once. People move between zones as the project changes stage; revisit it.
  • Treating "keep informed" as optional. Those who live with the result need to hear before launch, not after.
  • Escalating first. Going to the sponsor before an honest request works once and costs the relationship.
  • Leaving a dependency you can't talk to as a hope. Write it as an assumption with a check and a date.

Learn it in the course