# Stakeholder Map

A method for identifying the people a project affects or depends on, and deciding how to engage each one. The Plan phase of a Standard or Full sprint names "multiple stakeholders" but gives no way to find them or decide who needs what. This reference supplies that method and terminates in graph relationships, not a loose list.

Use this whenever a project has more than one interested party — a client plus their finance team, a landlord plus tenants, a partner plus the people who sign off the work. A project with a single decision-maker does not need it.

## Method: Power × Interest

Place each stakeholder on two axes:

- **Power** — how much influence they have over whether the project succeeds. Can they approve it, fund it, block it, or redirect it?
- **Interest** — how much the project's outcome affects them. Will they feel the result day to day, or is it peripheral to them?

Each stakeholder lands in one of four quadrants. Each quadrant has a default engagement posture:

| Quadrant | Power | Interest | Engagement posture |
|----------|-------|----------|--------------------|
| Manage closely | High | High | Involve in decisions, update frequently, resolve their concerns first |
| Keep satisfied | High | Low | Brief enough to keep onside, do not overload — they disengage if flooded |
| Keep informed | Low | High | Regular updates, listen for early warnings — they often see problems first |
| Monitor | Low | Low | Minimal contact, light-touch updates only when the outcome touches them |

Work through the project and ask, for each person or group: who decides, who pays, who does the work, who is affected by the result, who could block it. Place each one. The grid surfaces two failure modes a flat list hides: a high-power stakeholder being treated as peripheral, and effort spent over-communicating with someone who has neither power nor interest.

## Graph termination

A stakeholder map is not done until it lands in the graph against the project.

- **Record each stakeholder as a node related to the project.** If the person already exists, find them via `memory-search`; otherwise create them through the normal entity path. Then relate them to the project Task with `work-relate`: use `RAISED_BY` for the person who requested or sponsors the project, and `AFFECTS` for people or entities the project's outcome changes. Pass the project `taskId` from `project-create`/`project-get` and the stakeholder `elementId` from `memory-search`.
- **Record the engagement decision as a note.** Append the posture per quadrant to the project with `project-update`, e.g. `[PROJECT:PHASE] Stakeholders mapped — 2 manage-closely (client, surveyor), 1 keep-informed (tenant); client concerns resolved first`.

Do not leave the map as chat-only text. If a stakeholder is worth naming, the relationship is worth writing — that is what lets `project-get` and conflict detection (`AFFECTS`) see them later.

## Wiring

This method runs inside the Plan phase of `sprint.md` (Standard and Full tiers). Load it via `plugin-read` when a project has more than one interested party. Full tier maps all stakeholders; Standard tier maps the ones with high power or high interest and monitors the rest.

## When to Use

- A project Plan phase where "who are the deliverables for" has more than one answer.
- "Who do we need on side for this?"
- "Make sure we keep everyone in the loop on the refit."
- Before a project where one party could block progress and has not yet been engaged.