项目间风险传导分析要回答一个具体问题：一个项目的风险会通过什么路径影响另一个项目，影响多大。分析依据主要有四类：项目间真实的依赖关系、各项目的风险登记册与问题清单、进度与资源负荷数据、历史传导事件与变更记录。本文面向项目集经理和PMO，给出从界定范围、建立依赖图谱、收集依据、推演路径到分工复核的完整步骤，并说明ONES项目集管理在其中的承载方式。
要点总览（TL;DR）
- 项目间风险传导分析的依据分四类：项目间真实依赖关系、各项目风险登记册与问题清单、进度与资源负荷数据、历史传导事件与变更记录。
- 判断传导可能看四类共享对象：共享资源、共享交付物、共享供应商、共同技术底座；据此输出纳入分析的项目清单。
- 依赖图谱以项目为节点、依赖为边，记录依赖对象、方向、强度、时间窗口与可替代性，作为逐条推演的载体。
- 推演按“风险源项目→依赖边→受影响项目→二次传导”进行，区分直接与间接传导，从时间、成本、范围、质量四个维度评级并写明理由。
- 传导清单由项目集经理汇总、在项目集例会定期复核，重大变更或新增共享依赖时触发临时复核。
先明确分析对象：哪些项目之间存在传导可能
传导分析的第一步是划定边界。单项目内部的风险识别、评估与应对属于项目风险管理，由项目经理在本项目范围内闭环；传导分析只处理一个项目的风险越过项目边界、影响另一个项目的情况。边界不清会导致两种偏差：把单项目风险重复纳入传导清单，稀释分析重点；或者遗漏真正跨项目的关联，等到影响发生才发现。
判断两个项目之间是否存在传导可能，看它们是否共享以下四类对象：
- 共享资源：同一批关键人员、同一台关键设备、同一个测试环境在两个项目的关键时段被同时占用。资源冲突本身就是传导通道，一个项目加班占用资源，另一个项目的进度就会受挤压。
- 共享交付物：项目A的输出是项目B的输入，包括接口、组件、数据、文档或验收结论。上游交付延迟或质量不达标，会直接传到下游。
- 共享供应商：两个项目向同一供应商采购组件或服务，供应商的产能、交付节奏或质量问题会同时作用于多个项目。
- 共同技术底座：共用平台、框架、基础服务或基础设施。底座升级、故障或架构变更会波及所有依赖它的项目。
完成初判后，输出一份纳入分析的项目清单，逐项标注关联类型。清单应写明关联对象的具体名称，例如“共享资源：后端架构师张某，3月至5月同时投入A、B两项目”，而不是只写“资源相关”。这份清单是后续依赖图谱的输入，也是分析范围的书面记录。
建立依赖图谱：传导路径的载体
依赖关系如果只存在于项目经理的口头描述中，传导分析就无法逐条推演，也无法复核。依赖图谱的作用是把关联整理成结构化记录：以项目为节点，以依赖关系为边，每条边标注类型与方向，使“风险从哪来、经过谁、到哪里去”可以被逐条追踪。
每条依赖边至少记录以下字段：
| 字段 | 记录内容 | 作用 |
|---|---|---|
| 依赖对象 | 具体的人员、组件、供应商、平台或交付物名称 | 定位传导的实际载体 |
| 方向 | 由哪个项目指向哪个项目，或双向共享 | 确定传导的起点与终点 |
| 依赖强度 | 强依赖（不可替代、无缓冲）或弱依赖（有替代方案或缓冲） | 判断传导是否必然发生 |
| 时间窗口 | 依赖生效的起止时间，如某组件在4月交付 | 判断传导的时间条件是否成立 |
| 可替代性 | 是否存在备选资源、备选供应商或替代方案，切换代价多大 | 评估传导的可阻断程度 |
依赖图谱建议用表格或矩阵维护，按项目对逐行记录，并指定维护责任人。矩阵形式适合快速查看两两项目之间是否存在依赖；表格形式适合记录字段细节。两种形式可以并存，但必须保持同一份数据源，避免各项目自行维护的版本互相矛盾。图谱更新应与项目变更同步，新增共享资源或调整交付接口时及时补录。
收集四类分析依据：风险源、进度、资源与历史记录
依赖图谱提供结构，四类依据为结构填入判断所需的数据。每类依据都要明确从哪里取、取哪些字段、用来回答什么问题。
风险登记册与问题清单
从各项目的风险登记册和问题清单中提取：风险描述、发生可能性、影响范围、责任人、当前状态与应对措施。用途是识别可能外溢的风险源。筛选时重点关注影响范围涉及共享对象的风险条目，例如“关键组件供应商产能不足”“核心开发人员流失风险”。已经发生的问题同样纳入，因为问题比风险更确定地沿依赖边传导。
进度与里程碑数据
提取各项目的关键路径、里程碑交付日期、当前完成情况和缓冲余量。用途是判断传导的时间窗口和延迟量级。两个项目共享资源但时间窗口不重叠，传导可能性就低；上游里程碑紧邻下游开工日期且缓冲不足，传导就会直接体现为下游延期。
资源负荷数据
提取关键人员与关键设备在各项目间的占用比例、投入时段和冲突时段。用途是量化共享资源的紧张程度。负荷数据应覆盖分析周期内的全部关键时段，而不只是当前时点，否则会漏掉未来数月的资源冲突。
历史传导事件与变更记录
提取过去同类传导事件的发生条件、传导路径、实际影响和处置结果，以及相关的变更记录。用途是校准判断：同类依赖在过去是否真的发生过传导、影响持续多久、哪类应对有效。历史记录还能帮助识别被忽视的隐性依赖，例如某次变更暴露出的接口耦合。
四类依据建议整理成取数清单，逐项写明数据来源系统或文档、字段、更新频率和提供人，避免每次分析重新确认口径。
推演传导路径并评估影响程度
依据齐备后，按固定顺序逐条推演：从风险源项目出发，沿依赖边找到直接受影响项目，再检查受影响项目是否通过其他依赖边把影响传给第三个项目，形成二次传导。每条路径记录链条长度，链条越长，传导越隐蔽，越需要在清单中单独标注。
推演时区分直接传导与间接传导。直接传导是风险源项目与受影响项目之间存在直接依赖边；间接传导是影响经过一个或多个中间项目才到达。间接传导容易被忽略，因为它不体现在任何单一项目的风险登记册中，只能通过图谱逐边追踪发现。
影响程度从四个维度评估：
- 时间延迟：受影响项目的里程碑推迟多少天，是否侵蚀关键路径缓冲。
- 成本增量：为弥补延迟或切换替代方案产生的额外投入。
- 范围缩减：是否被迫削减交付内容或降低验收标准。
- 质量风险：替代资源或赶工是否带来缺陷率上升、返工增加。
每条路径给出可能性与影响量级的初步评级，并写明判断理由。例如“可能性高：供应商近三个月交付准时率为60%，且两项目均无备选供应商；影响量级大：项目B的验收里程碑依赖该组件，缓冲仅5天”。评级可以先用高、中、低三档，重点是理由可追溯，而不是评级本身精确。
在工具承载上，ONES Project 项目集管理支持借助项目集总览查看多项目信息，并可通过自定义项目属性区分项目类型、查看多项目数据集合，便于把依赖关系与项目状态放在同一视图中维护；其资源报表可实时反馈项目投入情况，为共享资源的负荷判断提供数据。是否具备专门的依赖图谱或传导路径记录能力，需结合所购版本与配置确认。
角色分工与交付物：谁提供依据、谁做判断
传导分析跨多个项目，责任不清会导致依据缺失或结论无人认领。各角色的输入与输出应事先约定：
| 角色 | 输入责任 | 输出责任 |
|---|---|---|
| 项目经理 | 维护本项目风险登记册、问题清单、进度与里程碑数据 | 提供风险源信息，确认本项目受影响的实际情况 |
| 项目集经理 | 汇总各项目依据，组织依赖图谱维护 | 组织传导推演，汇总传导清单与评级结果，分配应对责任 |
| 资源负责人 | 提供关键人员与设备的占用、冲突与调配信息 | 确认共享资源的可替代方案与切换代价 |
| 采购负责人 | 提供共享供应商的交付记录、产能与变更信息 | 确认供应商风险的缓解措施与备选来源 |
交付物包括三份：依赖关系表、风险传导路径清单、应对责任分配表。评审节点建议设在项目集例会上，按固定周期复核传导清单，并在发生重大变更、新增共享依赖或风险状态变化时触发临时复核。复核结论要落到具体角色与时间点，例如“由采购负责人在两周内完成备选供应商评估”。
示例：一次共享供应商风险的传导分析
以下为演示情景，用于说明分析流程，不代表真实客户案例。
背景：项目A与项目B共用同一供应商提供的关键控制组件。项目A计划6月完成集成，项目B的验收里程碑依赖项目A交付的集成模块，计划8月完成。
依据收集：采购记录显示该供应商近三个月交付准时率为65%，最近一次延期两周；项目A的集成里程碑缓冲为7天，项目B的验收缓冲为10天；项目A风险登记册中已有“供应商交付延迟”条目，状态为“已发生倾向”；项目B的风险登记册未记录该供应商，因为B不直接采购，只依赖A的交付物。
推演过程：风险源为供应商延期，沿“共享供应商”边直接传导至项目A，导致集成里程碑推迟；项目A的集成模块沿“共享交付物”边二次传导至项目B，压缩B的验收准备时间。链条长度为二，属于间接传导，项目B自身风险登记册无法发现该路径。
结论与责任分配：传导清单记录两条路径，可能性评级为高，影响量级为项目A延迟约两周、项目B验收缓冲被侵蚀至接近零。应对责任分配为：采购负责人两周内完成备选供应商评估并给出切换代价；项目A项目经理调整集成计划并每周更新供应商交付状态；项目集经理在下次例会上复核项目B的缓冲余量，必要时调整验收范围。
完成检查：传导分析是否可用的判断标准
分析完成后，用以下清单逐项核对，判断本次结果是否达到可用水平：
- 依赖关系是否覆盖全部已知共享对象，包括共享资源、共享交付物、共享供应商和共同技术底座，且每条依赖都有具体对象名称。
- 每条传导路径是否可追溯到具体依据，例如某条风险登记册条目、某个里程碑日期或某份供应商交付记录。
- 影响评级是否附有判断理由，理由中是否包含时间窗口、缓冲余量和可替代性等条件。
- 直接传导与间接传导是否已区分，间接传导的链条长度是否已标注。
- 应对责任是否落到具体角色与时间点，而非仅写“加强监控”。
- 复核机制是否明确：在什么节点、由谁更新传导清单，触发临时复核的条件是否写明。
全部条目可核对通过，说明本次分析具备可执行性；存在缺项的，应回到对应步骤补齐后再提交项目集例会。传导清单不是一次性文档，随依赖变化和风险状态更新持续维护，才能在下一次风险真正传导时提供可用的判断基础。
常见问题
两个项目只是使用同一套技术平台，没有直接交付关系，需要纳入传导分析吗？
需要纳入初判，是否形成传导路径取决于平台变更的时间窗口和影响范围。共同技术底座属于四类共享对象之一，平台升级、故障或架构调整会同时作用于依赖它的项目。判断时补充两个条件：平台变更是否落在相关项目的关键时段，以及项目是否有替代环境或回退方案。条件不成立时可以标注为低优先级，但仍应保留在依赖图谱中，便于后续复核。
间接传导在单个项目的风险登记册里看不到，怎么保证不漏？
间接传导只能通过依赖图谱逐边追踪发现，因此要把“沿边推演”作为固定动作，而不是依赖各项目自行上报。具体做法是从每个风险源项目出发，先找直接依赖边，再检查受影响项目是否通过其他依赖边继续外传，并记录链条长度。链条越长越容易遗漏，建议在传导清单中单独标注链条长度为二及以上的路径，在例会上优先复核。
风险登记册里的条目很多，哪些需要进入传导分析？
筛选标准是影响范围是否涉及共享对象。风险描述指向共享资源、共享交付物、共享供应商或共同技术底座的条目优先纳入；已经发生的问题也应纳入，因为问题比潜在风险更确定地沿依赖边传导。与共享对象无关的单项目风险留在本项目风险管理中闭环，不重复进入传导清单。
传导分析多久做一次，什么情况下需要临时复核？
常规复核可跟随项目集例会周期进行，重点是更新依赖图谱和传导清单的状态。触发临时复核的条件建议写明：新增或解除共享依赖、关键里程碑日期调整、共享供应商交付状态变化、关键资源投入计划变更。复核结论要落到具体角色和时间点，避免只写“持续关注”。
用ONES承载传导分析时，哪些环节可以直接依托现有能力？
ONES Project 项目集管理可借助项目集总览查看多项目信息，支持自定义项目属性区分项目类型并查看多项目数据集合，其资源报表可实时反馈项目投入情况，这些能力可用于维护多项目视图和判断共享资源负荷。依赖图谱与传导路径记录是否具备专门承载方式，需结合所购版本与配置确认；没有专门模块时，可用表格形式在项目集层面统一维护。
