项目集风险识别的依据，要围绕“跨关联项目的相互影响”来组织，而不是把各项目风险简单汇总。核心依据包括五类：项目集目标与收益承诺、各项目状态与依赖关系、共享资源占用与冲突记录、外部与组织约束、历史风险与问题数据。把这些依据整理成可追溯的清单，再经过跨项目筛选和评审，才能形成项目集风险登记册的初版。
要点总览（TL;DR）
- 项目集风险识别的依据围绕跨关联项目的影响组织，核心是五类输入：项目集目标与收益承诺、各项目状态与依赖关系、共享资源占用与冲突记录、外部与组织约束、历史风险与问题数据。
- 每条依据要标注来源、形成时间和适用范围，形成可追溯的依据清单，评审时才能核对证据而不是凭印象判断。
- 依据转成风险条目分四步：收集并标注来源、按跨项目影响筛选、按“原因—事件—后果”登记描述与触发信号、评审确认后纳入风险登记册。
- 单项目内部风险退回项目层管理，项目集登记册只保留能说明影响其他项目或整体收益的事项，避免同一风险两处登记。
- 识别完成用检查清单核对：五类依据覆盖度、跨项目指向、来源证据、责任人与复审时点、单项目风险归位、更新频率。
项目集风险识别要准备哪几类依据
项目集风险识别的起点是“依据是否齐全、是否指向跨项目影响”。单项目内部的技术风险、进度偏差由项目层管理；项目集层关注的是一个项目的偏差、资源占用或依赖变化，如何传导到其他项目和整体收益。以下五类依据覆盖了这种传导关系的主要来源。
| 依据类别 | 具体内容 | 主要来源 | 用于识别什么 |
|---|---|---|---|
| 项目集目标与收益承诺 | 项目集章程、收益实现计划、成功标准、关键里程碑承诺 | 项目集经理、治理层、业务发起人 | 收益延期、目标冲突、范围蔓延对整体承诺的影响 |
| 各项目状态与依赖关系 | 项目状态报告、里程碑完成情况、跨项目交付依赖、接口约定 | 各项目经理、PMO | 一个项目延期或变更导致关联项目连锁受阻 |
| 共享资源与关键角色占用 | 关键团队和专家的工时投入、资源分配表、角色缺口记录 | 资源负责人、职能经理、项目经理 | 关键资源争抢、单点依赖、能力缺口扩散 |
| 外部与组织约束 | 合规要求、供应商合同与交付节点、预算周期、组织审批节奏 | 法务合规、采购、财务、治理层 | 外部节点变化或合规要求调整引发的整体风险 |
| 历史风险、问题与变更记录 | 以往风险登记册、已发生问题、重大变更单、复盘结论 | PMO、项目经理、项目集经理 | 重复出现的模式、尚未关闭的遗留隐患 |
整理这份清单时，每条依据都应标注来源、形成时间和适用范围。例如“某关键团队三季度同时支持两个项目”这条资源记录，要写清数据来自哪份资源报表、统计截止时间，以及涉及哪两个项目。标注来源的目的，是让后续评审能核对证据，而不是凭印象判断风险。
五类依据中，项目集目标与收益承诺决定“什么算风险”，其余四类提供“风险从哪里来”的证据。缺少目标依据，识别容易退化为罗列项目问题；缺少依赖和资源依据，跨项目传导关系就看不出来。因此建议先确认目标和收益口径，再收集状态、资源和约束数据，最后补充历史记录作为参照。
从依据到风险清单的操作步骤
依据收集完成后，需要经过筛选、登记和评审，才能转成可管理的风险条目。整个过程分四步，每步都有明确的输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：收集依据并标注来源与时间 | 项目集章程、项目状态报告、资源报表、合同与合规文件、历史风险记录 | 按五类依据归集材料，逐条登记来源、时间和提供人 | 风险识别依据清单 | 五类依据均有对应材料，每条材料可追溯到提供人和时间 |
| 第二步：按跨项目影响筛选 | 依据清单 | 逐条判断该事项是否影响两个及以上项目或整体收益；单项目内部事项退回项目层 | 跨项目影响事项列表 | 每条保留事项都能说明受影响的项目或收益目标 |
| 第三步：逐条登记风险描述、影响对象与触发信号 | 跨项目影响事项列表 | 把事项写成“原因—事件—后果”结构的风险描述，注明影响对象、触发信号和初步等级 | 风险条目草案 | 每条风险具备描述、影响对象、触发信号、来源证据四项要素 |
| 第四步：评审确认并纳入风险登记册 | 风险条目草案 | 组织项目经理和关键干系人评审，确认或调整描述、等级和责任人，纳入登记册 | 项目集风险登记册初版 | 评审意见有记录，每条风险有责任人和复审时点 |
第二步的筛选是项目集风险识别与单项目风险识别的分界。判断标准可以简化为两个问题：这个事项是否会影响另一个项目的交付或资源？是否会影响项目集整体收益承诺？两个问题都答“否”的事项，归入项目层风险管理，不在项目集登记册中重复登记，避免同一风险在两处被重复跟踪、责任不清。
第三步的风险描述建议采用统一结构，便于后续评估和沟通。例如“由于某关键团队在两个项目间并行投入（原因），可能导致其中一个项目的集成测试延期（事件），进而影响项目集整体上线节点和收益实现时间（后果）”。触发信号写成可观察的条件，如“该团队周工时投入超过约定上限”或“某项目里程碑延期超过一周”，这样风险从“描述”变成“可监控”。
在工具承载上，如果项目集使用 ONES Project 的项目集管理，多项目总览可以查看多项目数据集合、多维度掌握项目进度，资源报表能实时反馈项目投入情况，这些数据可作为状态与资源两类依据的日常来源。风险条目本身仍建议按组织习惯维护在风险登记册中，并与项目状态评审保持同一更新节奏。
角色分工与各环节交付物
风险识别不是项目集经理一个人的工作，依据的提供、识别、评审和维护需要由不同角色分担。分工清楚，依据才不会停留在“大家都知道但没人提供”的状态。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目集经理 | 组织识别过程，确认依据口径，把关跨项目筛选标准，主持评审 | 依据清单模板、评审纪要、风险登记册初版 | 识别启动时发布模板；评审后完成登记册 |
| 项目经理 | 提供本项目状态、里程碑、依赖关系和变更信息 | 项目状态报告、依赖清单、变更记录 | 按项目集约定的报告周期提交，评审前完成更新 |
| 资源/职能负责人 | 提供共享资源占用、关键角色缺口和冲突信息 | 资源分配表、工时投入记录、能力缺口说明 | 资源计划确定后及每月资源复盘时提交 |
| 关键干系人与治理层 | 确认收益承诺和风险容忍度，评审重大风险条目 | 评审意见、风险等级确认、处置方向 | 评审会上给出结论，重大风险按治理节奏复核 |
项目集经理的把关重点有两项：一是确认依据是否覆盖五类来源，避免只收到项目状态报告而缺少资源和外部约束信息；二是确认筛选标准被执行，防止单项目风险被大量搬入项目集登记册，稀释对跨项目影响的关注。项目经理的交付物应包含依赖关系，而不只是进度百分比，因为依赖是跨项目传导的主要通道。
交接时点建议与项目集既有的报告节奏对齐，例如项目状态报告按月更新，资源信息在资源复盘后同步，评审会安排在两者之后。这样评审时使用的是同一时间截面的数据，减少“依据过期”导致的误判。评审结论要回写到登记册，并明确每条风险的责任人和下次复审时间。
示例：一次跨项目依赖风险的识别过程
以下为演示情景，用于说明依据如何转成风险条目，不代表真实项目数据。
某项目集包含两个关联项目：项目A负责平台能力建设，项目B负责基于该平台交付业务应用。两个项目共用一支关键的技术支持团队，项目B的集成测试依赖项目A的接口冻结。
识别时从三类依据中发现信号：项目A的状态报告显示接口冻结里程碑存在延期趋势；资源报表显示该技术支持团队在两个项目的工时投入合计已接近上限；项目B的依赖清单把接口冻结列为集成测试的前置条件。三条依据指向同一个传导链条：关键团队资源紧张，可能导致接口冻结延期，进而阻塞项目B的测试和整体上线。
据此形成的风险条目可以写成：
- 风险描述：由于两个项目共用关键技术支持团队且投入接近上限，项目A接口冻结可能延期，导致项目B集成测试启动推迟，影响项目集整体上线节点。
- 影响对象：项目A接口冻结里程碑、项目B集成测试计划、项目集整体收益实现时间。
- 触发信号：该团队周投入超过约定上限，或接口冻结里程碑延期超过一周。
- 初步等级：高（同时影响两个项目的关键路径和整体收益节点）。
- 来源证据：项目A状态报告、资源投入报表、项目B依赖清单。
评审后的处置方向可以包括：调整该团队在两个项目间的投入优先级，提前冻结接口范围，或为项目B准备替代测试方案。处置方向在评审会上确认，并指定责任人和复审时点。这个例子说明，项目集风险条目要能还原“哪条依据、影响哪些项目、通过什么信号观察”，而不只是一句笼统的“资源不足”。
当项目集需要持续观察这类信号时，ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预；其效果取决于项目、缺陷与资源数据的完整程度。这类分析可以作为识别依据的补充来源，风险条目的确认和处置仍由评审机制决定。
识别完成的检查项与常见缺口
判断项目集风险识别是否做到位，可以用下面这份清单逐项核对。清单同时列出常见缺口，便于在评审前自查。
| 检查项 | 核对标准 | 常见缺口 |
|---|---|---|
| 依据覆盖度 | 目标与收益、项目状态与依赖、共享资源、外部与组织约束、历史数据五类均有材料 | 只收集项目状态报告，缺少资源冲突和外部约束信息 |
| 跨项目指向 | 每条风险都写明受影响的项目或整体收益目标 | 登记册中混入单项目技术风险，跨项目影响说不清 |
| 来源证据 | 每条风险可追溯到具体依据、提供人和时间 | 风险描述只有结论，评审时无法核对依据 |
| 责任人与复审 | 每条风险有明确责任人和下次复审时点 | 风险登记后无人跟进，复审时间缺失 |
| 单项目风险归位 | 单项目内部风险已在项目层登记，项目集层不重复登记 | 同一风险在两处登记，责任和状态不一致 |
| 更新频率 | 依据随项目状态和资源复盘节奏更新，风险登记册同步复审 | 识别一次后长期不更新，触发信号失效 |
更新频率建议与项目集治理节奏绑定：项目状态和资源信息按既定周期刷新时，风险登记册同步复审；出现重大变更、关键里程碑调整或外部约束变化时，触发临时复审。复审不只检查已有风险的状态，也要用更新后的依据重新做一次跨项目筛选，因为新的依赖和资源冲突往往在项目推进中才显现。
最后需要区分层次：单项目内部的风险识别与应对归项目层管理，投资风险分散与平衡归项目组合层，本篇讨论的是项目集层围绕跨关联项目影响的识别依据与流程。三层各司其职，项目集风险登记册才能保持聚焦，真正服务于整体收益目标的监控。
常见问题
项目集风险识别和单项目风险识别怎么划清界限？
用两个问题做筛选：这个事项是否会影响另一个项目的交付或资源？是否会影响项目集整体收益承诺？两个问题都答“否”的事项，归入项目层风险管理，不在项目集登记册中重复登记。这样做的目的是让项目集登记册保持聚焦，避免同一风险在两处被跟踪、责任和状态不一致。项目经理仍按项目层流程管理本项目内部风险，项目集经理只关注传导到其他项目或整体收益的部分。
依据收集时只有项目状态报告，资源和外部约束信息拿不到怎么办？
先确认缺口属于哪一类，再按来源找对应角色补齐：共享资源占用找资源负责人或职能经理，外部约束找法务合规、采购和财务，历史数据找 PMO。评审前可以在依据清单上标注“待补”并写明提供人和时间要求，评审时对缺少依据的风险条目降低确认程度或暂缓定级。依据覆盖不全时，识别结论应明确标注适用范围，后续依据更新后触发复审补充，而不是用现有材料推断完整结论。
风险条目登记后，复审频率怎么定？
建议与项目集治理节奏绑定：项目状态和资源信息按既定周期刷新时，风险登记册同步复审；出现重大变更、关键里程碑调整或外部约束变化时，触发临时复审。复审不只检查已有风险的状态，也要用更新后的依据重新做一次跨项目筛选，因为新的依赖和资源冲突往往在项目推进中才显现。每条风险在登记时就应写明责任人和下次复审时点，避免登记后无人跟进。
跨项目依赖关系在工具里怎么持续观察？
依赖关系首先要作为依据被显式记录，例如在项目状态报告和依赖清单中写明前置条件、接口约定和交付节点，而不是只报进度百分比。在 ONES Project 的项目集管理中，多项目总览可以查看多项目数据集合、多维度掌握项目进度，资源报表能实时反馈项目投入情况，这些数据可作为状态与资源两类依据的日常来源。风险条目本身仍建议按组织习惯维护在风险登记册中，并与项目状态评审保持同一更新节奏。
识别出的风险等级由谁确认，项目集经理可以单独定级吗？
初步等级可以由识别者提出，最终确认放在评审环节。评审由项目集经理组织，项目经理和关键干系人参与，治理层确认收益承诺和风险容忍度，重大风险按治理节奏复核。评审意见要有记录，等级调整的理由与依据对应，这样后续复审时能看出定级口径是否发生变化。项目集经理的把关重点是确认依据覆盖度和筛选标准被执行，定级结论由评审共同确认。
