项目风险监控需要四类依据：风险登记册及更新记录、项目计划基线、进度与成本等监控数据、评审与审批等沟通决策记录。它们分别回答“盯什么风险、敞口是否变化、偏差是否真实、决定是否已作出”。本文按周度跟踪和阶段评审两种节奏，说明依据的取用顺序、角色分工、示例与核对清单，适用于单个项目的风险监控；已发生的阻塞问题处置和项目组合层面的风险平衡不在本文范围。
要点总览（TL;DR）
- 项目风险监控需要四类依据：风险登记册及更新记录、项目计划基线、进度与成本等监控数据、评审与审批等沟通决策记录，分别回答盯什么风险、敞口是否变化、偏差是否真实、决定是否已作出。
- 取用顺序建议为：先从风险登记册确定监控对象和责任人，再用计划基线判断敞口变化，随后用监控数据验证偏差，最后用评审与审批记录确认决定已落实。
- 周度跟踪解决变化是否被及时发现，阶段评审解决风险是否升级、关闭或调整策略；两者输入输出不同，不宜合并成一次会议。
- 项目经理对依据完整性负责，风险责任人对单条风险事实准确性负责，职能经理或技术负责人提供专业判断，项目发起人或管理层作出接受或资源调整决定。
- 阶段评审前可用完整性、时效性、可追溯性三个维度核对依据，任一项不通过应先补录或重新评审，再进入决策环节。
风险监控依据的四类来源与取用顺序
风险监控的依据需要同时覆盖“对象、基准、证据、决定”四个层面。只保留风险登记册，容易停留在主观判断；只看偏差数据，又难以解释偏差是否构成风险。四类依据配合使用，才能支撑一次有结论的评审。
第一类：风险登记册及其更新记录
风险登记册是监控的主依据，它确定本轮要盯哪些风险。可用字段至少包括：风险编号、风险描述、发生概率与影响、风险等级、责任人、触发条件、应对措施、计划完成时间、当前状态、最近更新日期。更新记录保留每次状态变化的原因和时间，避免评审时只看到结论、看不到过程。
第二类：项目计划基线
范围、进度、成本、质量基准用来判断风险敞口是否发生变化。基线本身是参照物：关键路径是否移动、里程碑日期是否调整、预算余量是否收窄，都会改变同一风险的影响程度。基线发生变更时，应同步检查关联风险的等级和应对措施是否仍然成立。
第三类：监控数据与偏差指标
监控数据为风险判断提供事实证据，常用包括：进度偏差与里程碑完成情况、成本偏差、缺陷数量与分布、变更请求数量与处理周期、任务逾期情况。取用时注意口径一致，例如偏差均以同一基线版本为参照，避免用不同版本的进度数据互相比较。
第四类：沟通与决策记录
风险评审纪要、升级审批、应对措施执行结果和责任人确认记录，说明风险经过了谁的判断、作出了什么决定。这类记录让监控形成闭环：风险从“被识别”走到“被处置、被关闭或被接受”，每一步都有据可查。
取用顺序
建议按以下顺序组织一次监控：先从风险登记册取出本轮监控对象和责任人；再用计划基线判断风险敞口是否变化；随后用监控数据验证偏差是否真实、是否在扩大；最后用评审与审批记录确认决定已作出、责任已落实。这个顺序先定对象、再定判断、后定动作，能减少评审会上临时找数据的情况。
按监控节奏组织依据：从周度跟踪到阶段评审的操作步骤
依据的价值在于按固定节奏被使用。周度跟踪解决“变化有没有被及时发现”，阶段评审解决“风险是否需要升级、关闭或调整策略”。两者输入不同、输出不同，不宜合并成一次会议。
周度风险跟踪
输入：风险登记册中处于开放状态的风险条目、本周任务与里程碑状态、进度与成本偏差数据、本周新增变更和缺陷记录。
动作：风险责任人逐条核对触发条件是否出现；项目经理汇总偏差数据，标记与风险描述相关的异常；对已触发风险，确认应对措施是否启动、是否按计划推进。
输出：更新后的风险状态（未触发、已触发、应对中、已关闭）、新增风险条目、需要升级的事项清单。
完成标志：每条开放风险都有本周状态和责任人确认；新增风险已指定责任人和初步应对措施。
月度或阶段风险评审
输入：周度跟踪汇总、应对措施执行结果、基线变更记录、上一轮评审遗留事项。
动作：评估风险等级是否需要调整；检查应对措施的有效性，对连续未达预期的措施提出替代方案；对超出阈值的风险作出升级、接受或关闭决定；核对基线变更对风险敞口的影响。
输出：评审纪要、风险等级与状态调整记录、升级审批单、关闭确认。
完成标志：评审结论逐条对应到风险条目；升级事项已提交审批并明确反馈时限。
触发升级的判断条件
出现以下情况之一时，应在周度跟踪中即提出升级，不必等到阶段评审：风险敞口超出预设阈值；应对措施连续两个周期未按期完成；风险影响范围扩大到其他工作流或关键交付物；触发条件已出现且现有措施不足以控制影响。升级判断条件应在风险登记册中预先写明，避免临场争议。
角色分工与交付物：谁提供依据、谁做判断、谁留记录
依据齐备与否，很大程度取决于职责是否清楚。下面按角色列出主要输入和交付物，团队规模较小时可由一人兼任多个角色，但交付物仍需分开留存。
| 角色 | 提供的依据 | 作出的判断 | 交付物 |
|---|---|---|---|
| 项目经理 | 计划基线、偏差汇总、评审议程 | 风险等级调整建议、是否提交升级 | 周度风险状态汇总、评审纪要、升级申请 |
| 风险责任人 | 触发条件观察记录、应对措施执行进展 | 风险是否已触发、措施是否有效 | 风险条目更新、措施执行说明 |
| 职能经理或技术负责人 | 技术评估结论、资源可用性、缺陷与质量数据 | 技术影响范围、替代方案可行性 | 技术评估意见、资源承诺 |
| 项目发起人或管理层 | 审批所需的风险汇总与影响说明 | 是否接受、升级资源或调整目标 | 审批结论、决策记录 |
项目经理负责把分散的依据汇总成可评审的材料，并对完整性负责；风险责任人对单条风险的事实准确性负责；职能经理或技术负责人提供专业判断，避免风险等级仅凭主观估计；项目发起人或管理层在超出项目权限时作出接受或资源调整的决定。记录由项目经理统一归档，确保同一风险的历次判断可以按时间顺序查阅。
示例：一个进度风险从触发到关闭的依据链
以下为演示情景，用于说明依据如何串联，不代表特定项目数据。
风险识别。某项目在风险登记册中登记风险 R-07：“核心模块联调依赖外部接口交付，若接口延迟两周以上，联调里程碑将顺延。”字段包括责任人（联调负责人）、触发条件（接口交付日期晚于计划日期 10 个工作日）、应对措施（提前准备模拟接口、每周与外部团队确认进度）、风险等级（高）。
触发时的依据。周度跟踪中，责任人提交外部团队进度确认记录，显示接口交付已晚于计划 12 个工作日，触发条件成立。项目经理对照计划基线，确认联调里程碑位于关键路径，风险敞口未因其他任务提前而缩小。依据链为：进度确认记录 → 触发条件比对 → 基线关键路径核对 → 风险状态更新为“已触发”。
应对措施执行中的依据。模拟接口启用后，联调任务部分恢复。责任人每周更新措施执行说明，项目经理在偏差数据中记录联调任务完成率变化。第三周发现模拟接口覆盖不足，措施执行说明中记录原因，评审会上据此决定增加技术负责人评估，形成技术评估意见作为补充依据。
关闭或升级时的依据。外部接口最终交付后，联调完成并通过验收测试，验收记录与里程碑完成情况作为关闭依据。项目经理在评审纪要中记录关闭决定，风险状态更新为“已关闭”，并保留从触发到关闭的全部更新记录。若接口延迟继续扩大并影响其他里程碑，则依据升级条件提交审批，由管理层决定调整目标或追加资源。
这个示例体现的字段与记录包括：风险编号与描述、责任人、触发条件、应对措施、状态变化时间、支撑每次判断的数据与记录。字段不必多，但要保证每个状态变化都能指向具体依据。
完成检查：风险监控依据是否齐备的核对项
在阶段评审前，可用以下清单判断依据是否达到可用状态。任一项不通过，应先补录或重新评审，再进入决策环节。
| 维度 | 核对项 | 不通过时的处理 |
|---|---|---|
| 完整性 | 每条开放风险都有责任人、触发条件、应对措施和当前状态 | 由项目经理退回责任人补录，补齐后再纳入评审 |
| 完整性 | 本轮评审覆盖的偏差数据与基线版本一致 | 统一基线口径后重新汇总偏差 |
| 时效性 | 风险状态更新日期在最近一个跟踪周期内 | 要求责任人补充本周观察记录 |
| 时效性 | 应对措施执行结果有最近一次确认 | 安排责任人在评审前完成确认 |
| 可追溯性 | 每次状态变化都能对应到数据、记录或评审结论 | 补充变更原因和依据来源 |
| 可追溯性 | 升级与关闭决定有审批或评审记录 | 补做审批确认，或在纪要中说明决定过程 |
清单通过后，评审材料即可作为决策输入；未通过项应明确补录责任人和时限，避免带着缺口进入升级审批。
用ONES承载风险监控依据的衔接方式
上述方法落到工具上，关键是把风险条目、计划基线、偏差数据和评审记录放在同一项目空间中，让每次判断都能回到原始记录。ONES 可帮助团队规划项目工作、安排任务、跟踪进度，并围绕关键阶段和交付目标开展协同管理；在瀑布项目管理场景中，支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，用于提早识别风险和问题。这与前文“用基线判断风险敞口是否变化”的动作相对应。
在记录方式上，团队可以把风险条目作为工作项纳入项目，明确责任人和计划完成时间，并通过从项目到任务的多层级管理实现自下而上的进度反馈和自上而下的进度监控。评审时，项目经理可结合多维度项目数据统计和分析评估项目绩效，为风险等级调整和升级判断提供数据依据；计划发生变更时，可通过对比版本细节追溯变更内容，支撑风险敞口变化的说明。对于需要全过程追溯的协作场景，ONES 支持跨域协作全过程的可追溯性，便于把风险相关的任务、变更和评审结论关联起来查阅。
需要说明的是，风险登记册的具体字段设计、状态流转规则和评审记录的关联方式，应结合团队现有流程在项目中约定；工具承载的是记录与追溯，判断标准和升级阈值仍需由项目经理、风险责任人和管理层按本文前述分工确定。
常见问题
风险登记册里字段很多，监控时最少要保留哪些？
监控阶段最少要能回答四个问题：这条风险由谁负责、什么条件下算触发、准备怎么应对、现在处于什么状态。对应字段包括责任人、触发条件、应对措施、当前状态和最近更新日期，再加上风险编号与描述便于引用。概率、影响和等级可以保留，但不必在每次周度跟踪中重新打分，等级调整放到阶段评审处理即可。
字段精简的前提是每个状态变化都能指向具体依据，例如触发条件成立时附上进度确认记录，措施执行有变化时写明原因。
项目计划基线发生变更后，风险监控要跟着做哪些调整？
基线变更会改变同一风险的影响程度，因此变更确认后应同步检查关联风险。具体动作包括：核对关键路径和里程碑日期是否移动，判断原触发条件是否仍然适用；检查预算余量或资源安排变化后，风险等级是否需要调整；确认原应对措施在新基线下是否仍然可行。调整结果记入风险条目更新记录，并在下一次阶段评审中说明变更对风险敞口的影响。
如果变更涉及多个工作流，建议在变更审批时就把关联风险清单作为附件一并提交。
周度跟踪发现风险已触发，但还没到阶段评审，应该怎么处理？
周度跟踪中即可启动应对措施，不必等待阶段评审。风险责任人确认触发条件成立后，更新风险状态为“已触发”，按预案执行措施并记录执行进展；项目经理核对偏差数据，判断影响是否在可控范围内。出现风险敞口超出预设阈值、措施连续两个周期未按期完成、影响范围扩大到其他关键交付物等情况时，应在当周提出升级，提交审批并明确反馈时限。
升级判断条件最好在风险登记册中预先写明，避免临场争议。
团队规模较小、一人兼任多个角色时，依据记录怎么保证可追溯？
角色可以合并，交付物仍建议分开留存。例如同一人既担任项目经理又担任风险责任人时，风险条目的状态更新与评审纪要分别记录，评审纪要中写明判断依据和决定时间。这样在后续复盘或交接时，能区分“谁观察到了什么”和“谁作出了什么决定”。
记录的关键是每次状态变化都能对应到数据、记录或评审结论，而不是记录由几个不同的人填写。
风险关闭后，相关依据还需要保留吗？
建议保留。关闭依据包括验收记录、里程碑完成情况、评审纪要中的关闭决定，它们说明风险为何可以关闭。保留这些记录的价值在于：同类风险再次出现时可参考当时的判断过程；阶段复盘时可以核对应对措施是否有效；项目交接时新成员能了解风险处理的历史。
保留范围以能还原判断过程为准，不必保存全部过程数据，但触发、措施执行、关闭三个节点的记录应完整。
