项目集风险台账围绕“跨关联项目影响”记录风险，最小可用信息分为五组：识别信息、跨项目影响、评估信息、应对信息和跟踪信息。单项目内部风险留在项目风险登记册，只有会传导到其他项目或影响项目集目标的风险才进入本台账。下面给出可直接复制的空白表格、逐字段填写口径、必填与选填划分，以及一条完整示例和维护规则。
要点总览（TL;DR）
- 项目集风险台账的最小可用字段分五组：识别信息、跨项目影响、评估信息、应对信息、跟踪信息，共22列，可直接复制空白表格使用。
- 台账只收会传导到其他项目或影响项目集目标的风险；只在本项目内部消化的风险留在项目风险登记册。
- 必填字段建议控制在13项以内，包括编号、标题、登记日期、登记人、受影响项目、影响类型、概率、影响程度、风险等级、应对策略、责任人、当前状态、最近更新日期；其余按治理成熟度逐步启用。
- 填写时先固定概率与影响程度的刻度，再用固定矩阵判定风险等级；影响链路写清依赖对象和传导路径，关闭条件写成可核验的事实。
- 台账启用时同步确定评审节奏、状态更新规则和升级触发条件，字段增删先在说明页记录变更再改表格结构。
可复制的项目集风险台账空白模板
下表是一份可直接粘贴到电子表格或在线协作表格中的空白台账。字段按五组排列，列名在后续字段说明和填写示例中保持一致，便于对照使用。建议一行记录一条风险，表头下方保留若干空行即可开始登记。
| 风险编号 | 风险标题 | 登记日期 | 登记人 | 所属项目集 | 风险类别 | 受影响项目 | 影响类型 | 影响链路 | 影响窗口 | 发生概率 | 影响程度 | 风险等级 | 评估依据 | 应对策略 | 责任人 | 关键动作 | 目标完成日期 | 当前状态 | 最近更新日期 | 升级路径 | 关闭条件 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果表格工具列宽有限，可以把“影响链路”和“评估依据”设为较宽的文本列，其余字段用下拉选项或短文本。台账首行建议冻结，并在表格之外单独维护一页“填写说明”，固定概率刻度、影响程度刻度和风险等级判定规则，避免不同登记人对同一取值理解不一致。
每个字段记录什么、怎么填
字段说明解决“同名不同义”的问题。同一个“影响程度”，有人按工期填、有人按成本填，台账就会失真。下表逐字段给出含义与填写口径，与空白模板的列顺序一一对应。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 风险编号 | 台账内唯一标识 | 建议“项目集简称-风险-序号”，如 PJT-A-R-012；编号一经分配不复用，关闭后保留 |
| 风险标题 | 一句话描述风险事件 | 写“因何原因，可能导致什么结果”，避免只写“进度风险”这类笼统词 |
| 登记日期 | 首次进入台账的日期 | 填写首次登记日，后续更新不改动此列 |
| 登记人 | 提出并录入该风险的人 | 填姓名或工号，便于追溯来源和补充信息 |
| 所属项目集 | 风险归属的项目集 | 一个项目集一张台账时固定填写；多项目集共用一张表时必填 |
| 风险类别 | 风险来源分类 | 使用组织统一分类，如进度、资源、技术、供应商、合规、需求变更 |
| 受影响项目 | 会被该风险波及的其他项目 | 列出项目名称或编号；只影响本项目的不填此项，应转回项目风险登记册 |
| 影响类型 | 传导到其他项目的方式 | 常见取值：交付延期、接口变更、资源占用、质量返工、预算追加、验收受阻 |
| 影响链路 | 风险从源头传到受影响项目的路径 | 按“源头项目→中间依赖→受影响项目”描述，写清依赖对象，如共享组件、关键人员、上游交付物 |
| 影响窗口 | 影响可能发生的时间段 | 填写起止时间或里程碑区间，如“2025年Q2集成测试阶段” |
| 发生概率 | 风险事件发生的可能性 | 按组织固定刻度填写，如高/中/低或1–5分，刻度定义写在说明页 |
| 影响程度 | 一旦发生对项目集目标的冲击 | 按统一口径评估，可综合工期、成本、范围、质量，取最高影响维度定档 |
| 风险等级 | 概率与影响组合后的优先级 | 用固定矩阵判定，如高概率×高影响=高；等级决定评审频率和升级要求 |
| 评估依据 | 支撑概率和影响判断的事实 | 写数据、历史记录、专家判断或依赖方反馈，避免只写“经验判断” |
| 应对策略 | 总体处理方向 | 常见取值：规避、转移、减轻、接受；策略与风险等级匹配，高等级风险应有明确策略 |
| 责任人 | 对应对动作负责的人 | 填具体个人，不填部门；跨项目风险宜由能协调双方的角色担任 |
| 关键动作 | 落实策略的具体步骤 | 写可执行、可验证的动作，如“与B项目确认接口冻结日期”，与策略区分开 |
| 目标完成日期 | 关键动作的计划完成时间 | 填具体日期，多个动作可分条列出各自日期 |
| 当前状态 | 风险所处阶段 | 建议取值：待评估、应对中、已缓解、已发生、已关闭 |
| 最近更新日期 | 本条记录最后一次实质更新的日期 | 每次修改状态、评估或动作后同步更新，便于识别长期未动的记录 |
| 升级路径 | 超出责任人权限时的上报对象 | 写清升级到哪一级，如项目集经理、项目集指导委员会，并注明触发条件 |
| 关闭条件 | 判定风险可关闭的标准 | 写可核验的条件，如“依赖交付物已验收且B项目确认无后续影响” |
跨项目影响的判定口径需要提前说清。判断标准是：该风险一旦发生，是否会改变本项目之外的其他项目的交付、资源或验收安排，或是否会影响项目集整体目标。会传导的进入本台账；只在本项目内部消化、由项目经理自行处理的，留在项目风险登记册。对于边界不清的风险，可先登记在本台账并标注“待确认传导范围”，在下一次评审时定论。
概率与影响程度建议采用组织内统一刻度。三档适合起步阶段，五档适合风险数量较多、需要更细排序的项目集。无论几档，刻度定义要写进说明页，例如“高=发生可能性超过60%”或“高影响=导致项目集里程碑延期超过两周”。风险等级由概率与影响交叉判定，形成固定矩阵，避免逐条主观定级。
应对策略与关键动作是两个层次。策略回答“总体怎么处理”，关键动作回答“具体做什么、谁在什么时候做完”。一条风险可以有一个策略和多个关键动作，动作完成后要回填状态，而不是只在年初填一次。
哪些字段必填、哪些按需填写
台账起步阶段字段过多，登记人会倾向于少填或拖延更新。建议先保证最小可用字段集，让台账能运转起来，再按治理成熟度逐步增加字段。
| 字段 | 建议 | 理由或启用条件 |
|---|---|---|
| 风险编号 | 必填 | 唯一标识，支撑引用、升级和关闭追溯 |
| 风险标题 | 必填 | 没有标题无法在评审中讨论 |
| 登记日期 | 必填 | 判断风险存续时间和更新及时性 |
| 登记人 | 必填 | 便于补充背景信息 |
| 受影响项目 | 必填 | 项目集台账的核心筛选口径 |
| 影响类型 | 必填 | 决定后续应对方向和责任归属 |
| 发生概率 | 必填 | 风险等级判定的输入 |
| 影响程度 | 必填 | 风险等级判定的输入 |
| 风险等级 | 必填 | 决定评审频率与升级要求 |
| 应对策略 | 必填 | 没有策略的风险只是问题清单 |
| 责任人 | 必填 | 明确跟进主体 |
| 当前状态 | 必填 | 支撑日常跟踪和关闭判断 |
| 最近更新日期 | 必填 | 识别长期未更新的记录 |
| 所属项目集 | 按需 | 一个项目集一张台账时可省略；多项目集共用一张表时必填 |
| 风险类别 | 按需 | 风险数量较多、需要分类统计时启用 |
| 影响链路 | 按需 | 跨项目依赖复杂时启用，简单传导可先写在标题中 |
| 影响窗口 | 按需 | 需要与项目集里程碑对齐时启用 |
| 评估依据 | 按需 | 高等级风险建议必填，低等级可简写 |
| 关键动作 | 按需 | 起步阶段可与应对策略合并；治理成熟后拆分 |
| 目标完成日期 | 按需 | 有明确动作时填写 |
| 升级路径 | 按需 | 存在跨层级协调需求时启用 |
| 关闭条件 | 按需 | 建议高等级风险必填，避免风险被随意关闭 |
项目集规模较小时，可先保留必填字段加“影响链路”一列，控制在十余列以内。项目集涉及多个子项目集、跨部门依赖较多时，再补充影响窗口、升级路径和关闭条件。字段增加应伴随一次评审，说明新增字段的用途和填写责任，避免出现无人维护的空列。
一条完整填写示例：跨项目依赖导致的交付延期风险
以下示例为演示情景，用于说明字段之间的对应关系，不指向任何真实组织。背景：某项目集包含A、B两个项目，B项目的移动端开发依赖A项目提供的统一登录组件。A项目组件交付推迟，可能影响B项目的联调与上线。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | PJT-X-R-007 |
| 风险标题 | A项目统一登录组件交付推迟，可能导致B项目联调延后并影响上线窗口 |
| 登记日期 | 2025-03-10 |
| 登记人 | 项目集PMO 李某 |
| 所属项目集 | 客户门户项目集 |
| 风险类别 | 进度 / 跨项目依赖 |
| 受影响项目 | B项目（移动端） |
| 影响类型 | 交付延期、验收受阻 |
| 影响链路 | A项目统一登录组件→B项目移动端登录模块→B项目联调与验收 |
| 影响窗口 | 2025年4月中旬至5月上旬联调阶段 |
| 发生概率 | 高 |
| 影响程度 | 高（B项目上线窗口可能顺延两周以上） |
| 风险等级 | 高 |
| 评估依据 | A项目组件当前完成度约70%，剩余接口联调未开始；B项目排期已无缓冲 |
| 应对策略 | 减轻 |
| 责任人 | 项目集技术负责人 王某 |
| 关键动作 | 1. 与A项目确认组件冻结日期；2. B项目先使用模拟接口开展联调；3. 每周同步组件进度 |
| 目标完成日期 | 2025-04-05（冻结日期确认）；2025-04-20（模拟接口联调完成） |
| 当前状态 | 应对中 |
| 最近更新日期 | 2025-03-24 |
| 升级路径 | 若4月5日前未确认冻结日期，升级至项目集指导委员会 |
| 关闭条件 | A项目组件交付并通过B项目联调，且B项目确认上线窗口不受影响 |
这条记录示范了几个填写要点：影响链路写清了依赖对象和传导路径，而不只是写“影响B项目”；关键动作拆成可验证的三步，并分别给出日期；升级路径带有明确触发条件，便于责任人在期限内判断是否需要上报；关闭条件可核验，避免风险在口头确认后被提前关闭。
台账的调整与日常维护方法
台账上线后最容易出现的问题是“建表时热闹、三个月后无人更新”。维护规则要在启用时一并确定，并写进台账说明页。
- 评审节奏与参与角色。建议高等级风险每周评审一次，中低等级风险每两周或每月评审一次。参与角色包括项目集经理、各项目项目经理、风险责任人和PMO；评审输出是状态变更、等级调整和新风险登记。
- 状态更新规则。责任人每次完成关键动作或发现情况变化时更新状态，并同步修改最近更新日期。评审时优先查看超过两周未更新的“应对中”记录，逐条确认是否仍然有效。
- 升级触发条件。常见触发条件包括：风险等级升为高、目标完成日期已过而未完成、影响窗口进入两周内、需要跨项目集调配资源。触发后由责任人按升级路径提交项目集决策层，并在台账中记录升级日期和结论。
- 字段增删的版本管理。字段调整先在说明页记录变更内容、生效日期和影响范围，再修改表格结构。历史记录保留原字段值，避免因删列导致信息丢失；重大调整后对存量记录做一次补填。
- 与相邻台账的分工。单项目内部风险由项目风险登记册管理，项目集台账只接收会传导到其他项目或影响项目集目标的风险；项目组合层面的投资风险分散与平衡由组合管理流程处理，不在本台账展开。三者之间通过风险编号和升级记录衔接，避免同一风险在多处重复登记。
当台账需要多人协作维护时，可以把风险条目承载为工作项，把填写说明和评审记录放在文档中。ONES Plan 支持借助项目集管理总览多项目信息，并支持自定义项目属性、查看多项目数据集合，适合按受影响项目、风险等级等维度汇总查看；ONES Wiki 支持使用模板库一键创建制式化文档，并记录页面版本、支持查看与回滚，可用于维护台账说明页和评审记录。具体功能范围以实际版本和套餐为准。工具承载的是登记、流转和留痕，字段口径与评审规则仍需团队自行确定并持续执行。
常见问题
项目集风险台账和项目风险登记册可以合并成一张表吗？
可以放在同一个表格文件里，但建议分成两个工作表，用同一套风险编号规则衔接。合并成一张表的主要风险是筛选口径混乱：项目集台账按“受影响项目”筛选，项目登记册按“本项目”筛选，混在一起后评审时容易把单项目风险也拉进项目集会议。
如果团队规模小、项目集只包含两三个项目，可以先共用一张表，但要在表内增加“是否跨项目传导”一列作为筛选条件，并在评审时分别查看。项目数量增加后再拆分为两张表，历史记录按原编号迁移，避免重复登记。
风险等级用三档还是五档更合适？
起步阶段用三档（高、中、低）更容易统一理解，登记人填写速度快，评审时也便于快速排序。当项目集内风险数量超过二三十条、需要更细的优先级区分时，再扩展到五档。
无论几档，关键是把刻度定义写进说明页并保持稳定，例如“高概率=发生可能性超过60%”“高影响=导致项目集里程碑延期超过两周”。刻度中途变更会导致历史记录无法比较，建议在版本变更时保留旧记录的原始取值。
跨项目影响的风险由谁担任责任人？
责任人应填具体个人，并且这个人要具备协调受影响项目的能力。常见选择是项目集技术负责人、项目集经理或PMO中负责跨项目协调的角色。由源头项目的项目经理单独担任责任人，往往难以推动受影响项目调整排期。
如果风险涉及两个以上项目且需要资源调配，责任人可以设为项目集经理，同时在各项目侧指定对接人，把对接动作写进关键动作列。责任人变更时同步更新最近更新日期，并在评审记录中说明交接原因。
台账里的风险关闭后还需要保留记录吗？
建议保留。关闭的风险记录是后续类似风险的评估依据，也是复盘时判断应对策略是否有效的材料。关闭时把当前状态改为“已关闭”，填写关闭日期和关闭依据，风险编号不复用。
如果台账记录数量增长较快，可以按季度或年度把已关闭记录归档到单独的工作表，主表只保留未关闭和近期关闭的记录。归档前确认关闭条件已满足并有可核验的事实，例如依赖交付物已验收、受影响项目已书面确认。
评审会上发现风险等级需要调整，应该改哪些字段？
至少更新三项：发生概率或影响程度、风险等级、最近更新日期。如果等级上调导致应对策略变化，还要同步修改应对策略和关键动作，必要时调整责任人。
调整依据写进评估依据列，例如新增的进度数据或依赖方反馈。等级从低升为高时，按升级路径判断是否需要提交项目集决策层，并在台账中记录升级日期和结论，便于后续追溯定级变化的原因。
