Stakeholder management in a single organization with a clear hierarchy is a coordination problem. Stakeholder management across agencies, departments with different leadership chains, or organizations with formally equal standing is a negotiation problem. The techniques that work in one setting transfer imperfectly to the other, and the gaps show up at the worst moments: during a decision that needs to happen before a deadline, when two parties discover they had different understandings of what was agreed, or when someone exercises a veto that nobody's project plan accounted for.
What follows comes from leading teams where the stakeholders spanned multiple agencies with distinct mandates, different accountability structures, and occasionally competing interests in the same project's outcome. The methods I describe here were learned partly from what I did right and partly from what I did wrong in those environments.
The stakeholder map that actually works
The standard stakeholder analysis matrix (high influence / high interest in one quadrant, low influence / low interest in another) is a useful starting point and an insufficient destination. It categorizes stakeholders as a snapshot, but influence in complex environments is not static and is not fully visible from the outside. The person with the modest job title who has the director's ear is not visible in the org chart. The technical lead who can surface a compliance concern that halts procurement is not visible in the influence/interest grid.
The map I build has three layers:
Formal authority. Who has the organizational standing to approve, reject, or modify the deliverable? Who sits on the governance body that makes binding decisions? Formal authority is usually visible and usually documented.
Informal influence. Who do the formal decision-makers listen to? Who shapes the agenda before the meeting? Whose objection, even without a formal veto, would change the outcome? This layer requires conversations, not org charts, and it takes time to build because it depends on the relational knowledge that only comes from being inside the environment long enough to observe it.
Veto capacity. Who has the ability to stop, delay, or substantially redirect the project, whether or not they have formal authority to do so? A procurement officer with a compliance concern. A legal team with a data-sharing objection. A partner agency whose participation is necessary for the initiative to function. Veto capacity often doesn't appear on governance documents, and finding out about it during a project review is too late.
The authority versus influence gap
In well-functioning hierarchies, authority and influence correlate reasonably well: the people with formal authority tend to be the people whose views matter most to outcomes. In interagency and complex multi-stakeholder environments, this correlation breaks down. You will encounter stakeholders with high formal authority over one piece of the project and low practical leverage over the conditions that make the project succeed, and stakeholders with no formal authority who can nonetheless determine whether the work is worth doing.
Managing toward formal authority alone is how projects get approved by all the right people and still fail to land. The technical expert who doesn't endorse the approach won't say anything in the plenary meeting, and will say everything in the corridor. The partner agency representative who appears committed in the steering committee will discover unexpected organizational constraints when implementation begins. These aren't anomalies. They're the normal operating mode of environments where no single line of authority runs through every participant.
The practical response is to treat informal influence as a primary input to engagement planning, not a secondary one. Who needs to believe in this before the formal approval is sought? Who needs to understand it before they'll champion it to the people above them? Those conversations happen before the meeting, bilaterally, without an audience.
The bilateral conversation before the group meeting
The group meeting is the wrong place to surface a concern, resolve a conflict, or build alignment. By the time a stakeholder raises a substantive objection in a plenary session, the stakes of the conversation have increased: they're now managing their position in front of peers, and positions in public are harder to move than positions in private. The public objection is a symptom. The condition that produced it was already present before the meeting started, and the place to address it was before the meeting started.
My rule is that I should have no significant surprises in a group meeting. Not because surprises don't happen, but because the work of eliminating them is the work of stakeholder management: individual conversations that surface concerns early, so that concerns can be addressed or accommodated before they become positions. A stakeholder who raises a concern in a bilateral conversation is sharing a problem. A stakeholder who raises the same concern in a governance meeting is creating leverage.
In interagency environments, the bilateral conversation also serves another function: it communicates respect for the stakeholder's mandate. A partner agency has its own objectives, its own leadership, and its own accountability to constituents that are not yours. Taking the time to understand those before asking for their support is not relationship management theater. It's the minimum requirement for asking someone to take a risk on your project with their organizational reputation.
The explicit alignment document
Verbal agreement in a meeting is not agreement. It is agreement until someone walks out of the room, returns to their own organization, and interprets what was said through the lens of their own organizational interests. This is not bad faith. It is what happens when people with genuinely different mandates use the same words to mean slightly different things, and nobody checked.
An explicit alignment document captures what was agreed, by whom, on what date, with any constraints, conditions, or open items noted. It doesn't have to be formal. It can be an email summary of the meeting sent to all participants with a request to flag any discrepancies within a specified period. The function is not to create a legal record: it is to surface discrepancies while they're still easy to resolve, rather than discovering them when the project is in implementation and the disagreement has become a dispute.
The blocker who won't say no directly
In high-stakes environments, few people say no directly. They say "I need more information." They say "this needs further review." They raise concerns in a form that doesn't constitute a veto but creates indefinite delay. The indirect block is common in environments where a formal rejection carries political cost, and where delay achieves the same practical outcome with lower exposure.
The response is to make the no-saying easier, not harder. Ask specifically: "What would need to be true for this to move forward?" or "Is there a version of this that would work for your organization?" These questions convert a passive block into an active conversation about conditions. They also reveal whether the block is substantive (the stakeholder has a genuine concern that can be addressed) or structural (the concern is the project itself, and no version of it will find support). The second case calls for escalation or scope revision, not more bilateral conversations that won't change the answer.
When to escalate and when to absorb
Escalation is the right response when a decision is genuinely above the level at which it can be made: when the competing interests can only be resolved by someone with authority over both parties, or when a delay has consequences that the escalating parties don't have the standing to accept on behalf of the project. Escalation in those cases is not a failure. It is the correct use of the governance structure.
Escalation is the wrong response when the concern is substantive and addressable, when the blocker has legitimate authority over the matter in question, or when the escalation would damage a relationship whose long-term value exceeds the cost of absorbing the current obstruction. The decision between escalate and absorb is a judgment call that depends on the specific environment, and getting it wrong in either direction carries costs: escalating unnecessarily makes the escalating party look unable to manage their own stakeholder landscape; absorbing when escalation is warranted allows a project to be held hostage indefinitely.
The rule I use: escalate when the decision cannot be made without the authority being escalated to, and the cost of delay exceeds the cost of the relationship friction. Absorb when the concern is legitimate, the relationship matters more than the specific issue, and a different path through the problem exists. Neither answer is permanent: a concern that was appropriate to absorb in month two may be appropriate to escalate in month five if nothing has changed.