联合风险应对处理的是多个关联项目之间同源、传导或叠加的风险：同一供应商出问题会同时拖慢几个项目，一个项目的延期会把接口压力推给下游项目，多个项目争抢同一支团队也会互相挤压。本文按“划定范围建台账—评估传导路径—设定处置与触发条件—跟踪升级关闭”的顺序，给出每一步的输入、动作、输出和责任人，并附一份填好的示例条目和一张完成检查清单。
要点总览（TL;DR）
- 联合风险应对针对跨关联项目的同源、传导和叠加风险，单项目内部可自行处置的风险留在项目层面管理。
- 操作分四步：按依赖关系圈定联动项目组并建立联合风险台账，评估风险关联与传导路径，为每条风险设定唯一牵头人、处置动作与可观测的触发条件，再按固定节奏跟踪、升级和关闭。
- 核心产物是一份联合风险台账、一张传导关系图、一套联合处置方案与跟踪升级规则。
- 机制是否有效，重点看三条：牵头人是否真正推动、触发条件是否可观测、关闭是否有受影响项目的确认依据。
联合风险应对要解决什么问题
联合风险指跨关联项目发生的风险：几个项目依赖同一家供应商或同一个合规节点，属于同源；一个项目的交付变化导致另一个项目的接口、测试或上线推迟，属于传导；多个项目在同一时间段占用同一团队、同一预算或同一发布窗口，属于叠加。这类风险在单个项目的登记册里往往各记一条，看起来影响有限，合在一起却会冲击项目集目标。
与单项目风险管理的分工可以这样划：单项目内部的风险由项目经理在本项目风险登记册中识别、评估和处置，不必上升；当风险的影响范围超出单个项目、处置动作需要跨项目协调、或者资源需要在项目间重新分配时，上升到项目集层面做联合应对。项目集层面不接管单项目风险的全部细节，只接管那些需要联动的那部分。
判断一条风险是否需要联合应对，可以看三个信号：
- 同一外部依赖：两个及以上项目依赖同一供应商、同一外部接口、同一合规审查或同一客户验收节点。
- 风险在项目间传导：一个项目的里程碑变化会直接改变另一个项目的前置条件或交付时间。
- 多个项目争抢同一资源或窗口：同一团队、同一测试环境、同一上线窗口被多个项目同时需要。
出现任一信号，就应把相关风险纳入联合风险台账。单项目风险登记册的写法、投资组合层面的风险分散策略不在本文展开，前者由各项目自行维护，后者属于更高层级的资源配置决策。
第一步：划定联动范围与建立联合风险台账
这一步的目标是把散落在各项目里的关联风险收拢成一份可跟踪的清单。输入包括三样：各项目的风险登记册、项目之间的依赖清单、共同的外部条件（供应商合同、合规节点、共享资源池）。缺少依赖清单时，可以先由各项目经理列出“我的哪些交付依赖别人、哪些交付被别人依赖”，再交叉比对。
动作分三步：按依赖关系圈定联动项目组，把存在直接依赖或共享外部条件的项目归入同一组；从各项目登记册中抽取同源类和传导类风险，同时补充叠加类风险；合并重复条目，同一供应商导致的三个项目风险合并为一条联合风险，在“涉及项目”字段中列全。
台账建议包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 风险编号 | 项目集内唯一，便于跨项目引用 |
| 涉及项目 | 列出全部受影响项目，注明主责项目 |
| 风险描述 | 写清事件、原因和后果，避免只写“供应商有风险” |
| 触发条件 | 可观测的信号，如“供应商连续两周交付延迟超过3天” |
| 传导路径 | 从源头项目到受影响项目的传导链条 |
| 影响窗口 | 风险可能造成影响的时间段 |
| 牵头人 | 唯一责任人，对本条风险的处置负责 |
| 参与方 | 各受影响项目的接口人 |
| 状态 | 待评估、处置中、已升级、已关闭 |
输出是一份跨项目联合风险台账，每条风险都能追溯到来源项目和原始登记条目。完成标志是：联动项目组内的每个项目都确认自己涉及的联合风险已被收录，且没有两条记录描述同一件事。
第二步：评估风险关联与传导路径
台账建立后，需要判断风险之间的关系和处置先后。关联类型分三种：同源型，多个项目受同一供应商、同一合规要求或同一外部接口影响；传导型，A项目的延期导致B项目的接口联调推迟，B的推迟又压缩C的测试时间；叠加型，多个项目在同一时段占用同一团队或同一预算，单独看都可承受，合在一起就超出容量。
评估维度建议用四个：发生可能性、对项目集目标的影响程度、传导速度（从触发到影响其他项目需要多久）、可干预程度（现在采取动作还能改变结果的空间）。传导速度快、可干预程度低的风险，处置窗口很短，需要优先安排。
把风险与受影响项目画成传导关系图：节点是风险和项目，箭头表示“导致”或“影响”，在图上标出关键节点——即被多条箭头指向的项目或风险，它们一旦出问题，波及面最大。传导关系图不必追求精细，能看清源头、路径和受影响终点即可。
排序规则可以简化为：优先处理传导面广（受影响项目多）、干预窗口短（留给动作的时间少）的风险；对传导面广但窗口较长的风险，安排提前干预；对影响局限在单个项目、且该项目可自行处置的，退回项目层面管理。
第三步：设定联合处置动作与触发条件
评估结果要落成方案：每条联合风险由谁、在什么条件下、做什么、多久内完成。首先确定唯一牵头人。牵头人按风险源头或影响最大的项目指定，不按项目数量投票；参与方为各受影响项目指定接口人，负责在本项目内落实动作并反馈状态。
处置策略沿用规避、转移、减轻、接受四类，联合场景下常见组合用法：
- 统一谈判：多个项目共用同一供应商时，由牵头人汇总需求统一与供应商谈产能保障和交付优先级，避免各项目分别施压导致供应商顾此失彼。
- 统一调整交付窗口：传导型风险中，与其让下游项目被动等待，不如在项目集层面统一重排接口和上线窗口，一次性通知相关方。
- 集中管理缓冲：共享资源、预算或时间缓冲由项目集集中持有，按触发条件释放，避免各项目重复预留造成浪费。
触发条件要写成可观测的信号，并配响应时限。例如“供应商月度交付达成率低于90%”触发联合处置，“牵头人须在2个工作日内召集参与方确认替代方案”。模糊表述如“情况恶化时启动”无法执行，也无法事后判断是否该启动而未启动。
输出是每条联合风险的处置方案，包含牵头人、参与方、处置动作、触发条件、响应时限和所需资源。完成标志是牵头人和参与方均确认方案，且触发条件能被数据或明确事件观测到。
角色分工与交付物
联合风险应对失效，常见原因是责任悬空：台账有人建没人管，牵头人挂名不推动。下表把角色、职责和交付物对应起来。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目集经理 | 主持联合风险评审，裁定跨项目优先级与资源调配，决定是否升级 | 评审结论、优先级裁定记录、资源调配决定 |
| 风险牵头人 | 维护本条风险的台账信息，推动处置动作，按触发条件启动响应，必要时上报升级 | 本条风险的处置方案、状态更新、升级申请 |
| 项目接口人 | 在本项目内落实处置动作，反馈执行状态和残留影响 | 本项目内的执行记录、状态反馈、关闭确认意见 |
| PMO或风险管理岗 | 维护台账模板和字段口径，汇总整体状态，组织复盘 | 台账模板、状态汇总、复盘记录 |
交接节点设在三处：风险纳入台账时，由来源项目的项目经理向牵头人移交背景信息；处置方案确定时，牵头人向参与方下达动作和时限；风险关闭时，参与方确认无残留影响后由牵头人提交关闭。每个节点都应有书面记录，避免口头交接后无人跟进。
跟踪、升级与关闭机制
联合风险进入运行期后，靠固定节奏的评审维持跟踪。建议项目集层面每两周召开一次联合风险评审会，议题固定为三项：新增和状态变化的联合风险、触发条件已出现的风险及其响应进展、需要项目集经理裁定的优先级或资源问题。风险数量多或影响窗口集中时，可缩短为一周一次。
状态更新规则要明确：牵头人在每次评审前更新本条风险的状态和处置进展；触发条件出现时，牵头人在响应时限内将状态改为“处置中”并通知参与方；处置动作完成但影响尚未消除的，状态保持“处置中”，不提前关闭。
升级路径分三种情形：超出牵头人权限的资源调配，上报项目集经理；风险将影响项目集里程碑，上报项目集经理并在评审会上列为专项议题；多方无法就处置方案达成一致，由项目集经理裁定，仍无法解决的提交项目集指导委员会。每种情形约定上报时限，例如触发后2个工作日内提出。
关闭需同时满足三个条件：触发条件已解除或不再可能发生；处置动作已全部完成；受影响项目确认无残留影响。关闭后由PMO组织简短复盘，记录传导路径是否与实际一致、处置动作是否有效、触发条件设置是否合理，供后续项目集参考。
台账和评审在工具中承载时，可以选择支持多项目统一总览的项目集管理工具。ONES Plan 提供多项目进度管控和资源管理，借助项目集管理总览多项目信息，并可查看多项目数据集合、多维度掌控项目进度；其资源报表可实时反馈项目投入情况，且能直接查看 ONES Project 中的登记工时、预估工时和剩余工时数据。这些能力适合承载联合风险台账所依赖的项目状态与共享资源投入信息，风险条目本身可按团队既有工作项规范登记。具体字段配置和报表口径需结合实际使用确认。
示例：一个跨项目供应商风险的联合应对
以下为演示情景，用于说明方法如何落地，不代表真实客户案例。
场景：某项目集下三个关联项目共用同一关键零部件供应商，供应商近期产能波动，交付周期从4周延长到6周。项目A负责整机集成，项目B负责配套软件适配，项目C负责现场交付。
台账填写：风险编号R-012；涉及项目为A（主责）、B、C；风险描述为“供应商产能不足导致关键零部件交付延迟，A的集成测试顺延，B的适配验证缺少实物样机，C的现场交付窗口错过客户验收期”；触发条件为“供应商连续两周交付延迟超过5个工作日”；传导路径为供应商→A集成测试→B适配验证→C现场交付；影响窗口为第8周至第14周；牵头人为A的项目经理；参与方为B、C的接口人；状态为待评估。
处置方案：牵头人汇总三个项目的零部件需求，统一与供应商谈判产能保障和交付优先级；同时启动备选供应商评估作为减轻措施。触发条件出现后2个工作日内召集参与方确认替代方案。项目集层面预留两周时间缓冲，由项目集经理集中管理，按需释放给受影响项目。
跟踪与升级：第6周供应商交付延迟达到触发条件，牵头人将状态改为“处置中”，组织与供应商的谈判。第7周谈判未取得产能承诺，风险将影响项目集里程碑，牵头人按升级路径上报项目集经理，评审会上裁定优先保障项目A的样机需求，B改用仿真环境先行验证，C与客户协商调整验收窗口。第12周供应商恢复交付，三个项目完成剩余验证。
关闭与复盘：第14周触发条件解除，处置动作全部完成，B、C确认无残留影响，风险关闭。复盘结论：传导路径与实际一致，统一谈判比各项目分别施压更有效；触发条件设置偏晚，下次应将交付延迟预警阈值提前到3个工作日。
完成检查：联合风险应对是否到位
机制是否真正运转，可以逐项核对：
- 每条联合风险都有唯一牵头人和明确的参与方，牵头人不是挂名。
- 传导路径已识别并记录在台账中，传导关系图能看清源头和受影响终点。
- 触发条件可观测、响应时限可执行，不依赖“情况严重时”这类判断。
- 台账状态按约定节奏更新，评审会有固定议题和结论记录。
- 升级发生过并被记录，升级后的裁定有明确执行人。
- 关闭有受影响项目的确认依据，复盘记录已归档。
常见缺口集中在三处：台账只登记不跟踪，建完就搁置；牵头人由职位最高者挂名，实际推动落在接口人身上却无授权；触发条件写成模糊描述，导致该启动时没启动、事后也无法追责。检查时对这三项重点核对，比增加台账字段更能提升机制的有效性。
常见问题
联合风险台账和单项目风险登记册需要重复登记吗？
不需要重复登记同一件事。单项目风险登记册由各项目自行维护，记录本项目全部风险；联合风险台账只收录需要跨项目联动的那部分，并在“涉及项目”字段中列全来源项目，保留对原始条目的追溯关系。项目内风险状态变化时，由项目接口人同步给联合风险牵头人，避免两份记录出现不一致。
牵头人应该由源头项目的项目经理担任，还是由受影响最大的项目担任？
按风险源头或影响最大的项目指定，两种做法都可以，关键是只设一个牵头人并给出相应授权。源头项目牵头，便于从起因上推动处置；影响最大的项目牵头，便于围绕项目集目标安排动作。无论哪种，都应在台账中写明选择理由，并明确牵头人可调用的资源和需要上报的情形，避免挂名。
触发条件写成什么程度才算可执行？
标准是能被数据或明确事件观测到，并且事后可以判断是否该启动。例如“供应商连续两周交付延迟超过5个工作日”“某项目接口联调计划推迟超过3天”，都带有对象、阈值和时间口径。同时配上响应时限，如“触发后2个工作日内召集参与方确认替代方案”。只写“情况恶化时启动”无法执行，也无法复盘。
多个项目争抢同一团队时，联合风险应对和资源排期怎么衔接？
把资源冲突作为叠加型联合风险登记，由项目集经理在评审会上裁定优先级和资源分配，裁定结果回写到各项目的排期和本条风险的状态中。共享资源或时间缓冲由项目集集中持有、按触发条件释放，各项目不重复预留。资源投入数据可在项目集管理工具中统一查看，ONES Plan 提供多项目进度管控和资源管理，其资源报表可反馈项目投入情况，具体口径需结合实际配置确认。
风险关闭后还需要保留哪些记录？
至少保留三项：关闭确认依据（触发条件解除的证明、受影响项目无残留影响的确认意见）、处置过程记录（启动时间、采取的动作、升级与裁定结果）、复盘结论（传导路径是否与实际一致、触发条件设置是否合理）。这些记录供后续项目集参考，也是检查机制是否真正运转的证据。
