A stakeholder map starts with the classic two-axis grid, power (the ability to help or block the program) against interest (how much this person actually cares, day to day, about the outcome), sorting every stakeholder into one of four quadrants (the framework traces to Mendelow's 1991 power/interest formulation): manage closely (high power, high interest (the people whose active engagement the program's survival depends on), keep satisfied (high power, lower day-to-day interest) busy senior people who must never be surprised or under-informed, even though they do not want to be consulted on every detail), keep informed (lower power, high interest, people who care and are affected but cannot alone move the outcome, and whose goodwill or resentment still matters), and monitor (lower power, lower interest, worth a light touch, not neglect). The grid alone, though, only answers where a stakeholder sits; it says nothing about which way they are currently leaning, which is why a second, simpler layer belongs on top of every stakeholder in the "manage closely" and "keep satisfied" boxes especially: a current-sentiment read (champion, neutral, skeptic, or blocker) because a high-power champion and a high-power blocker sit in the identical quadrant on the first grid but need entirely different treatment: the champion needs to be equipped to advocate for the program to their own peers; the blocker needs to be engaged directly, often co-opted into shaping the very design they are resisting, not merely "managed around" until the meeting where their objection can no longer be avoided.
Advertisement
How do you refine a stakeholder map?
Two refinements matter in practice. First, collective power is easy to under-weight when a stakeholder map is built stakeholder-by-stakeholder: a single frontline employee scores low on power almost by definition, but a whole group of frontline employees who together control the day-to-day behavior a KPI cascade's leading indicators actually depend on is a genuinely high-power bloc, and mapping them individually into "monitor" while the program's own success metrics quietly depend on their collective behavior changing is a direct, avoidable contradiction between the stakeholder map and the KPI cascade, the two artifacts should agree with each other, and when they do not, the stakeholder map is usually the one that is wrong. Second, and this is the distinction that gives this section its name: managing up and managing down or across are not the same skill wearing different clothes. Managing up, the sponsor, the steering committee, the client's own C-suite, means pre-wiring before every contentious ask, protecting scarce senior time with concise and decision-ready material, equipping a champion with the specific numbers they need to defend the program to their own boss or board, and escalating a genuine blocker early rather than hoping it resolves itself. Managing down and across, workstream leads, the delivery team, frontline staff whose adoption the program depends on, means translating the north star into a locally meaningful "why" (the KPI cascade's real job, read as a leadership tool and not just an arithmetic one), protecting the team from scope churn the SteerCo has not actually approved, visible and frequent presence rather than distant memos, and, the direction beginners forget entirely, deliberately channeling frontline knowledge upward, because the person closest to the work often sees a risk or a flaw in the plan well before it reaches a workstream lead's status report. Worked Example 6 builds a full stakeholder map for a hospital transformation and shows exactly where a naive, individual-only reading of the grid would have gotten the frontline group's true influence wrong.