项目集风险台账、单项目风险登记册与项目集问题清单的区别

项目集风险台账、单项目风险登记册和项目集问题清单常被混用，但三者回答的问题不同：风险台账记录尚未发生、可能影响项目集目标的不确定性；单项目风险登记册记录项目范围内的风险；项目集问题清单跟踪已经发生、需要项目集层面推动解决的事项。判断一个条目该放在哪里，先看它是否已发生，再看影响是否跨越单个项目边界。

要点总览（TL;DR）

• 项目集风险台账管理跨关联项目、影响项目集整体目标与依赖关系的不确定性，由项目集经理或项目集管理办公室维护。
• 单项目风险登记册管理单个项目范围内的风险，由项目经理负责识别、评估与应对；影响超出项目边界或需跨项目资源时升级到项目集台账。
• 项目集问题清单跟踪已经发生、需要项目集层面推动解决的事项，核心是责任归属与关闭时限，与风险台账的分界在于是否已经发生。
• 常见误用包括把所有项目风险塞进项目集台账、把已发生问题记在风险台账、用项目集问题清单替代项目内部问题跟踪。
• 落地时先明确升级条件、升级评审人和问题关闭确认人，再用工作项类型与状态流转在协作工具中承载。

一句话区分：管理对象与管理层级

三者的差异可以归纳为两个主轴：管理对象是“未发生的不确定性”还是“已发生的问题”，管理层级是“项目集”还是“单项目”。把这两个主轴交叉起来，三个载体的位置就清楚了。

项目集风险台账是面向项目集整体的风险登记载体。它记录可能影响项目集收益、里程碑或项目间依赖关系的不确定性，由项目集经理或项目集管理办公室维护，服务于跨项目的协调决策。

单项目风险登记册是面向单个项目范围的风险登记载体。它记录本项目交付过程中可能出现的不确定性，由项目经理负责识别、评估、制定应对措施并跟踪，是项目日常风险管理的执行台账。

项目集问题清单是面向已发生问题的跟踪载体。问题一旦发生并造成或即将造成实际影响，就进入问题清单，由明确的责任人推动解决，并设定关闭时限。它关注的是“谁在什么时候把这件事解决掉”。

由此可以形成一条快速判断路径：条目尚未发生，先看影响是否超出单个项目，超出则进项目集风险台账，否则留在单项目风险登记册；条目已经发生，且需要项目集层面协调资源或裁决优先级，则进项目集问题清单。风险与问题的分界不是严重程度，而是是否已经发生。

项目集风险台账管什么、不管什么

项目集风险台账的纳入标准，核心是风险影响是否跨越项目边界、是否需要项目集层面协调资源或调整优先级。符合以下情形的风险，适合纳入项目集台账：

• 风险同时影响两个及以上关联项目，或影响项目之间的依赖关系，例如共享供应商、共享关键资源、接口交付顺序。
• 风险威胁项目集整体收益或阶段性里程碑，单个项目无法独立消化其后果。
• 风险的应对需要项目集层面调配资源、调整项目优先级或与其他项目集协商。
• 风险涉及项目集层面的外部约束，如合同条款、监管要求、关键干系人承诺。

相应地，以下内容不纳入项目集风险台账：仅影响单个项目、且该项目团队有能力自行应对的风险，留在单项目风险登记册中管理；项目组合层面的投资风险分散与组合平衡，属于项目组合风险管理的范畴，由组合管理层级处理。把这两类内容都塞进项目集台账，会让台账失去聚焦，评审时难以分辨哪些风险真正需要项目集层面介入。

一个实用的判断标准是：如果这个风险的应对方案不需要动用项目集层面的资源或决策权，它就不必进入项目集台账。台账的价值在于聚焦少数需要跨项目协调的事项，而非穷举所有风险。

单项目风险登记册与项目集风险台账如何衔接

两级载体的分工是：单项目风险登记册由项目经理维护，覆盖项目范围内部的风险识别、评估与应对执行；项目集风险台账由项目集层面维护，聚焦跨项目影响与协调决策。两者不是上下级复制关系，而是不同粒度的视图。

风险从单项目登记册升级到项目集台账，通常有以下触发条件：

• 风险的影响范围扩展到其他项目，或影响到项目间的依赖交付。
• 风险的应对需要跨项目调配资源，超出项目经理的授权范围。
• 风险威胁项目集整体收益目标或关键里程碑。
• 风险的概率或影响评估在项目层面已无法单独控制，需要项目集层面介入。

升级后的处理方式建议采用“汇总视图加执行细节”的分工：项目集台账保留该风险的汇总条目，记录跨项目影响、协调责任人和项目集层面的应对策略；原项目登记册保留执行细节，继续跟踪具体应对动作的落地情况。这样既避免项目集台账被细节淹没，也避免项目层面失去对风险应对的掌控。

避免同一风险在两处重复维护的做法是明确字段分工：项目集台账记录“为什么需要项目集介入”和“项目集层面的协调动作”，项目登记册记录“本项目内的具体应对步骤和完成状态”。两处通过风险编号或关联关系对应，评审时以项目集台账看全局，以项目登记册看执行。

项目集问题清单与风险台账的关键区别

风险与问题的本质差异在于是否已经发生。风险是尚未发生的不确定性，管理动作是评估概率与影响、制定应对策略、设置触发条件并定期复评；问题是已经发生并造成或即将造成实际影响的事项，管理动作是明确责任人、设定解决时限、推动关闭。

两类载体的核心字段因此不同：

维度	项目集风险台账	项目集问题清单
管理对象	未发生的不确定性	已发生、已造成影响的事项
核心字段	风险描述、概率与影响评估、应对策略、责任人、触发条件	问题描述、影响范围、责任人、解决时限、关闭状态
使用方式	定期评估与应对跟踪，关注触发条件是否出现	责任落实与关闭推进，关注时限是否达成
关闭条件	风险已消除、已转化为问题，或影响已降至可接受水平	问题已解决并经确认关闭

使用节奏上也有差别：风险台账适合按固定周期评审，例如在项目集例会上逐条复评概率、影响和应对进展；问题清单更适合按责任人和时限推进，在每次例会上检查逾期项和阻塞项。把已发生的问题记在风险台账里，会导致台账中混杂两类管理动作，评审时既无法判断风险趋势，也无法追踪问题关闭。

三者的对照表与常见误解

把三个载体放在同一张表中横向对照，差异更直观：

对照维度	项目集风险台账	单项目风险登记册	项目集问题清单
管理对象	跨项目、影响项目集目标的不确定性	项目范围内的不确定性	已发生、需项目集推动解决的问题
管理层级	项目集	单项目	项目集
责任人	项目集经理或项目集管理办公室	项目经理	问题责任人，项目集经理督办
核心字段	概率、影响、应对策略、触发条件	概率、影响、应对措施、跟踪状态	影响范围、责任人、解决时限、关闭状态
更新节奏	按项目集评审周期复评	按项目例会或周报更新	按责任时限推进，例会检查逾期
关闭条件	风险消除、转化或降至可接受	风险消除或项目结束	问题解决并确认关闭

常见误解有三类。第一类是把所有项目风险都放进项目集台账，导致台账臃肿、评审失焦；纠正方法是坚持“是否需要项目集层面协调”这一纳入标准。第二类是把已发生的问题记在风险台账里，混淆风险与问题；纠正方法是条目登记时先判断是否已发生，已发生的进入问题清单。第三类是让项目集问题清单替代单项目问题跟踪，造成责任不清；项目集问题清单应聚焦需要项目集层面推动的事项，项目内部问题仍由项目层面跟踪。

举一个具体例子：某项目集下有两个项目共用一家关键供应商，项目A的项目经理在登记册中记录“供应商交付可能延迟，影响本项目联调计划”。随后评估发现，该供应商同时供应项目B的关键部件，延迟会同时冲击两个项目的上线节点，且需要项目集层面与供应商重新谈判交付优先级。此时该风险满足升级条件，在项目集风险台账中建立汇总条目，记录跨项目影响和谈判责任人；项目A的登记册保留本项目联调计划调整的执行细节。若供应商最终确认延迟并已造成联调延期，则该事项从风险转为问题，进入项目集问题清单，明确责任人和解决时限，推动替代方案落地。

在协作工具中承载三类载体的管理动作

三类载体的差异最终要落到日常管理动作上：登记、评审、升级、关闭。协作工具的价值在于让这些动作留下可追溯的记录，而不是另建一套管理逻辑。

登记环节，风险与问题适合作为不同类型的工作项分别管理，用字段区分管理对象：风险类工作项设置概率、影响评估、应对策略和触发条件字段；问题类工作项设置影响范围、责任人和解决时限字段。字段区分让后续的筛选、统计和评审有统一口径。

升级环节，风险从项目登记册进入项目集台账时，需要有明确的状态流转和评审动作：由项目经理提出升级，项目集经理或项目集管理办公室评审确认，确认后在项目集层面建立关联条目并保留与原条目的对应关系。ONES 项目集管理支持多项目进度管控和资源管理，借助项目集管理总览多项目信息，并支持自定义项目属性、查看多项目数据集合，这些能力可以为项目集层面的风险汇总与评审提供多项目视图基础；风险条目本身的具体字段与流转配置，需结合团队实际使用的项目模板与工作项设置来确定。

评审与关闭环节，项目集层面的定期风险评审和问题关闭推进应形成可追溯记录：每次评审记录复评结论、应对进展和下一步动作，问题关闭记录解决结果和确认人。ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析、根因判断和资源合理性建议，帮助管理者在风险扩大前完成干预；这类分析可作为项目集风险评审的输入，评审结论仍应回写到台账条目中，形成完整记录。

落地时建议先明确三件事：哪些风险必须升级、升级由谁评审、问题关闭由谁确认。把这三条规则写进团队的项目集管理约定，再在工具中用工作项类型和状态流转承载，三类载体就能各司其职，既不过度集中，也不遗漏关键事项。

常见问题

一个风险同时影响两个项目，但两个项目经理都认为可以各自应对，还需要进项目集风险台账吗？

判断依据是应对方案是否需要项目集层面的资源或决策权。如果两个项目各自调整计划就能消化影响，且不涉及共享资源重新分配、优先级裁决或对外承诺变更，可以分别留在各自的风险登记册中，在项目集例会上做信息同步即可。

当两个项目的应对动作相互冲突，例如争抢同一批关键人员，或需要与同一供应商重新谈判交付顺序，就应升级到项目集风险台账，由项目集层面协调。升级的判断标准是协调需求，而非风险条目的数量。

风险升级到项目集台账后，原项目登记册里的条目要删除吗？

建议保留。项目集台账记录跨项目影响、协调责任人和项目集层面的应对策略；原项目登记册继续跟踪本项目内的具体应对步骤和完成状态。两处通过风险编号或关联关系对应，形成汇总视图加执行细节的分工。

如果直接删除原条目，项目团队会失去对执行细节的跟踪依据，评审时也难以核对应对动作是否落地。保留双份记录的关键是字段分工清晰，避免两处重复填写相同内容。

项目集问题清单里的问题解决后，还需要在风险台账中做记录吗？

通常不需要重复登记。问题关闭后在问题清单中记录解决结果和确认人即可。需要回写风险台账的情形是：该问题由某条风险转化而来，此时在对应风险条目中更新状态，注明已转化为问题并关联问题编号，便于后续复盘时看清从风险到问题的演变过程。

如果问题解决后暴露出新的不确定性，例如替代方案带来新的交付依赖，则应作为新风险登记，按影响范围判断进入项目集台账还是单项目登记册。

项目集风险台账的评审频率应该怎么定？

常见做法是与项目集例会节奏对齐，按固定周期逐条复评概率、影响和应对进展，并在里程碑节点前增加专项评审。频率取决于项目集的风险密度和外部环境变化速度，没有统一标准。

比频率更重要的是评审产出：每次评审应记录复评结论、触发条件是否出现、下一步动作和责任人。缺少这些记录，台账会退化为静态清单，无法支撑项目集层面的协调决策。

用协作工具承载三类载体时，最小配置需要做到什么程度？

最小配置包括三点：风险与问题作为不同类型的工作项分别登记，用字段区分概率、影响、解决时限等关键信息；风险升级时有明确的状态流转和评审确认动作；评审与关闭结论回写到条目中形成可追溯记录。

ONES 项目集管理支持多项目进度管控和资源管理，借助项目集管理总览多项目信息，并支持自定义项目属性、查看多项目数据集合，可为项目集层面的风险汇总与评审提供多项目视图基础。风险条目的具体字段与流转配置，需结合团队实际使用的项目模板与工作项设置来确定。