如何管理项目干系人：识别影响力并制定沟通策略
管理项目干系人，重点是安排有用的参与：从项目要交付的结果和下一个关键节点出发，找出谁的知识、决定、执行或使用体验与它有关，再约定每个人需要收到什么、提供什么、决定什么，以及什么时候参与。给所有人发同一份进度表，不能代替这一步。 一张简短名单就可以开始。名单记录的是相关人，沟通安排记录的是要与这些人完成的事情。表格里有一个名字，不代表他的需求已经被听见，也不代表决定已经形成或交接已经被接受。
沿着工作找人，不只看组织架构
用一句话写出项目结果，再往前追溯这个结果被实际使用之前需要发生什么。把提供输入、批准承诺、执行工作、使用或维护成果的人都纳入检查。请发起人以及原本就与这些群体合作的同事核对遗漏。不常参加项目会议的人，可能掌握交付必需的信息；每次都参会的人，也可能并不参与下一个节点。 APM 对干系人的说明包含参与项目或受到项目影响的人与群体，也包含组织外部的相关者。Microsoft 关于维护干系人名单的指导同样关注项目成果的日常使用者。因此，识别范围不能停留在项目群成员或已经被抄送的人。先说明关联，再决定是否需要联系，避免名单无限扩大却没有用途。
把影响力落到下一件具体事情上
影响力判断要能改变参与安排才有用。对于下一次评审，确认谁有权批准结果、谁能解释关键需求、决定之后谁的工作会改变。不能默认职级最高的人批准所有细节，也不能因为使用者不能批准预算就忽视他的实际知识。一个成果是否方便交接和使用，可能正需要这些人的输入。 详细的权力、利益和参与分析可以单独完成。写沟通安排时，只记录它带来的联系需要，例如“这位同事核对交接条件，所以要在评审前收到草稿”，不要只写“重要人物”。权限或代表范围尚不明确，就向相关人核实，不要先按照猜测排好会议，再让所有人配合。
把每次联系写成有目的的交换
每次必要沟通明确目的、发送的信息、期待的回应、需要的日期，以及负责保持联系的人。举一个假设例子：团队在承诺交付日期前，请负责后续运营的同事指出草稿里缺少哪些交接说明。这与发一份通用进度摘要是不同的任务。请求中要说清楚他的回答会影响哪个决定，让对方知道该检查哪里。 ONS 的干系人映射指导说明，后续参与计划可以写明由谁、如何、多频繁联系，以及哪些具体事件需要联系。时间应围绕“回答还能改变工作”的节点安排。每周摘要可以用于了解进度，但周二就需要的决定，不能等到周五例行汇报才提出。频率不是越高越好，要与用途和双方可用时间相符。
约定可用渠道，也说明参与的真实范围
询问对方怎样方便审阅材料。简短交谈适合澄清不明确的需求，书面草稿适合检查具体措辞。需要看文件时，确认对方具有访问权限，而不是以为发了链接就能打开。请求也要准确：需要建议就征求建议，需要批准就联系有权者，只需对方安排后续动作时就清楚告知结果。 说明哪些还可以讨论、哪些已经决定。决定固定之后才邀请“共同决定”，会形成不实的参与预期。此时仍可询问执行上的问题，但要明确用途。把相关反馈记录下来，回应它是否改变了工作、是否需要另一个决定，或者为什么不在本次节点内。尊重参与，不等于答应每项意见。
项目变化时重新检查安排
进入新的交付阶段、需求改变、同事换人或使用群体变化，都可能让旧名单不完整。到这些节点时，检查谁新增了实际角色、谁不再需要原来的联系。Microsoft 建议在项目生命周期中维护名单，APM 也将参与描述为持续识别、分析、计划和行动的过程。不要把启动时的一张表当成永久结论。 复核的是联系后的结果，而不是发送了多少消息。所需输入是否在决定前到达？受影响的人是否及时知道结果？尚未回答的问题是否交给能处理的人？如果一次联系没有产生有用交换，先检查目的、权限与时间，再调整这项安排。不要立刻给所有人增加会议，用更大的沟通量掩盖原本没有说清的任务。