项目风险评估的依据主要来自四类可查证材料：项目自身的章程、WBS、进度与预算等文件，类似项目复盘与问题记录等历史数据，合同、法规、供应商与技术环境等外部约束，以及干系人访谈和专家评审形成的人员判断。评估前先确定对象与分级口径，再按识别、分析、排序、记录、复核五步执行，最终留下带依据出处的风险登记册与评估记录。
要点总览（TL;DR）
- 项目风险评估的依据分四类：项目文件（章程、WBS、里程碑、预算与资源计划）、历史数据（复盘、风险登记册、问题记录）、外部约束（合同、法规、供应商、技术环境）、人员判断（访谈与专家评审）。
- 评估启动前先定口径：评估对象是单个项目还是项目阶段、风险边界、概率与影响分级标准、评估周期与参与角色，形成书面口径说明。
- 操作按识别、分析、排序、记录、复核五步执行，每条风险保留依据出处、责任人、复查时点，最终产出可跟踪的风险登记册与评估记录。
- 判断评估是否可用，看每条风险是否有可回查的依据出处、分级是否一致执行、是否有责任人与复查时点、记录是否可追溯。
评估前先定口径：评估对象、范围与判定标准
依据收集散乱，通常源于评估开始前没有说清“评什么、评到哪、按什么标准判”。口径说明不需要很长，但要在评估启动会上形成书面记录，参与评估的人共用同一份。
需要先确认四项内容：
- 评估对象：明确本次评估针对单个项目还是某个项目阶段。针对阶段时，写清阶段起止时间和阶段交付物，避免把整个项目的风险与当前阶段的风险混在一张表里。
- 风险定义与边界：风险指尚未发生、可能影响项目目标的不确定性；已经发生并造成阻塞的事项转入问题管理，按问题流程处置。边界写清后，识别环节就不会把已发生的延期、已暴露的缺陷当作风险条目重复登记。
- 概率与影响的分级标准：给出可判断的档位，例如概率分为高、中、低三档并附判断说明，影响按进度、成本、质量、范围等维度分别定档。分级标准要在同一评估周期内一致使用，否则排序结果无法比较。
- 评估周期与参与角色：确定本次评估的时间窗口、复盘频率，以及谁提供依据、谁打分、谁复核。
这四项确认后形成一份《风险评估口径说明》，作为后续所有条目的判定基准。口径一旦确定，评估过程中如需调整，应记录调整原因和生效时间。
四类评估依据及取用方式
依据的价值在于可查证、可追溯。下表按四类整理来源、取用人和用途，实际使用时可按项目规模增删条目，但每条依据都应能指向具体文件、记录或人员意见。
| 依据类别 | 具体来源 | 取用人 | 用途 |
|---|---|---|---|
| 项目文件类 | 项目章程、WBS、里程碑计划、预算与资源计划、需求与范围说明 | 项目经理、计划负责人 | 确定评估对象与关键路径，识别范围、进度、成本、资源方面的不确定性 |
| 历史数据类 | 类似项目复盘报告、既往风险登记册、问题记录、经验教训库、缺陷统计 | 项目经理、领域负责人 | 提供同类风险的参照，校准概率判断，避免重复踩坑 |
| 外部约束类 | 合同条款、法规与合规要求、供应商与依赖方信息、技术环境限制 | 项目经理、法务或合规接口人、技术负责人 | 识别交付义务、合规时限、外部依赖中断、技术条件不足带来的风险 |
| 人员判断类 | 干系人访谈记录、专家评审意见、专题研讨会结论 | 项目经理组织，干系人与专家提供 | 补充文件与数据覆盖不到的经验判断，对概率和影响进行打分 |
取用依据时有两点操作要求。其一，每条依据注明出处，例如“依据：2024年同类项目复盘报告第3节”，便于复核时回查。其二，区分事实性依据与判断性依据：文件和数据属于事实输入，访谈和专家意见属于判断输入，两者在登记册中分别标注，复核时对判断性依据重点确认其合理性。
项目文件类依据中，WBS和里程碑计划决定风险落在哪些工作包和时间点上；预算与资源计划决定成本与人力风险的判断基础。历史数据类依据用于校准，例如既往项目中某类接口联调反复延期，本次评估就应把该环节的概率档位调高，并写明参照来源。外部约束类依据往往对应硬性时限和责任划分，需要逐条对照合同与合规要求确认。人员判断类依据适合覆盖新业务、新技术等缺少历史数据的场景。
在工具承载上，项目计划、WBS与里程碑可以在ONES中建立，并通过设置计划和里程碑基线、对比计划与执行的偏差来提早识别风险；工时日历与饱和度报表可作为资源类风险的判断输入。评估依据与评估记录则可沉淀在项目文档中，与风险条目关联保存。
五步评估操作：从识别到复核
五步操作的核心是每一步都有输入、动作、输出和完成标志，评估结束后能拿出可跟踪的产物，而不只是一次讨论。
第一步：识别
输入为依据清单和口径说明。动作是逐类翻阅依据，按WBS工作包、里程碑、外部依赖、资源与合规等线索列出风险条目，每条用“原因—事件—影响”的句式描述。输出为风险条目初稿。完成标志是依据清单中每一类都至少被检查过一遍，且每条风险都能对应到具体工作包或项目目标。
第二步：分析
输入为风险条目初稿和分级标准。动作是逐条判断概率与影响档位，并在条目上标注判断所依据的材料出处；对判断分歧较大的条目，补充访谈或专家意见。输出为带概率、影响和依据出处的分析结果。完成标志是每条风险都有概率档、影响档和至少一条依据出处。
第三步：排序
输入为分析结果和分级标准中的优先级规则。动作是按概率与影响的组合确定优先级，对高优先级条目检查是否需要立即安排应对措施。输出为排序后的风险清单。完成标志是排序规则被一致执行，没有出现同类条目档位判断不一致的情况。
第四步：记录
输入为排序后的清单。动作是写入风险登记册，字段至少包括：风险编号、描述、类别、触发条件、概率、影响、优先级、依据出处、应对措施、责任人、复查时点、当前状态。输出为风险登记册。完成标志是登记册字段完整，且与评估记录可互相引用。
第五步：复核
输入为风险登记册。动作是由评审角色确认条目描述、分级结论和应对措施是否合理，确定跟踪责任人与复查时点，对不成立的条目说明移除理由。输出为评审确认后的登记册和评估记录。完成标志是评审意见已闭环，每条风险都有责任人和复查时点。
在跟踪环节，风险条目可以作为工作项在ONES中指派责任人、设置状态与复查时间，评估依据和评审记录保存在关联文档中，形成从依据到结论再到跟踪的完整链路。具体字段和流程按团队实际配置设定。
角色分工与各环节交付物
评估能否落地，取决于每个环节是否有人负责、有物交付。下表给出常见分工，小团队可一人兼多角，但职责要写清。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织评估、确定口径、维护风险登记册、推动复核与跟踪 | 口径说明、风险登记册、评估记录 |
| 领域负责人（技术、业务、采购等） | 提供本领域的文件与数据依据，参与条目识别与分析 | 领域依据清单、风险条目初稿、分析意见 |
| 干系人与专家 | 参与访谈与评审，对概率和影响提供判断 | 访谈记录、专家评审意见、打分结果 |
| 评审角色（项目负责人或质量接口人） | 复核条目描述、分级结论与应对措施 | 评审意见、确认后的登记册 |
分工确定后，建议在口径说明中一并写明各角色的响应时限，例如领域负责人需在识别启动后两个工作日内提交依据，评审意见需在登记册提交后三个工作日内反馈。这样评估周期才有可预期的节奏。
示例：一个迭代项目的评估依据与记录
以下为演示情景，用于说明依据如何落到登记册条目，不代表真实项目结论。
某团队计划在一个六周迭代内完成支付模块改造。评估对象为该迭代，口径说明中确定概率与影响各分三档，影响按进度和成本两个维度判断。
依据来源包括：迭代范围说明与WBS（项目文件类）；上一版本支付模块的问题记录和同类项目复盘（历史数据类）；与第三方支付渠道的服务协议及接口变更通知（外部约束类）；技术负责人和渠道对接人的访谈意见（人员判断类）。
登记册条目示例：
- 风险编号R-01，描述“第三方支付渠道接口在迭代期内变更，导致联调返工、进度延后”，类别为外部依赖，概率高、影响中，优先级高；依据出处为渠道变更通知和技术负责人访谈记录；应对措施为提前锁定接口版本并安排备用联调窗口；责任人为渠道对接人；复查时点为迭代第二周。
- 风险编号R-02，描述“支付模块历史缺陷集中在退款流程，本次改造可能引入同类问题”，类别为质量，概率中、影响中，优先级中；依据出处为上一版本问题记录；应对措施为退款流程增加回归用例；责任人为测试负责人；复查时点为提测前一周。
两条条目都保留了依据出处和复查时点，复核时可直接回查原始材料，跟踪时按复查时点更新状态。
完成检查：评估是否可用的判断项
评估结束前，用以下清单逐项核对。全部通过，说明本次评估具备可用性；有未通过项，补齐后再提交复核。
- 每条风险是否都有至少一条依据出处，且出处可回查。
- 概率与影响的分级是否按口径说明一致执行，同类条目的档位判断是否有明显矛盾。
- 每条风险是否都有明确的责任人和复查时点。
- 风险登记册与评估记录是否可互相追溯，评审意见是否闭环。
- 已发生并造成阻塞的事项是否已转入问题管理，未与风险条目混记。
- 口径说明中的评估对象、边界和周期是否与实际执行一致，如有调整是否记录了原因。
这份清单也可以作为下一次评估的启动检查，帮助团队在依据收集阶段就对齐标准，减少复核阶段的返工。
常见问题
项目进行到一半才开始做风险评估，依据还来得及补吗？
可以补，但取用顺序要调整。先以当前的项目计划、WBS和里程碑基线为起点，对比计划与执行偏差，把已经显现的偏差趋势转成尚未发生的风险条目；再补历史数据类依据，用类似项目复盘和问题记录校准概率判断。已经发生并造成阻塞的事项转入问题管理，不混入风险登记册。补做时同样要形成口径说明，写明本次评估的对象是剩余阶段还是整体项目，避免与前期评估口径冲突。
缺少历史项目数据时，概率判断怎么做才不至于拍脑袋？
历史数据不足时，把判断依据转向人员判断类和外部约束类。组织技术负责人、业务负责人和外部依赖方接口人做结构化访谈，围绕工作包逐项询问“哪些环节可能出问题、出问题的前兆是什么”，把访谈记录作为判断性依据标注在条目上。概率档位可以先用相对比较的方式确定，例如在同一批条目中排出高低顺序再映射到档位，并在口径说明中写明这种做法的适用条件。后续项目积累的问题记录和复盘材料，可以逐步替换这部分判断性依据。
风险条目和已发生的问题记录放在一起管理，会有什么影响？
混记会让两类数据的用途都变模糊。风险条目描述尚未发生的不确定性，需要概率、影响和复查时点来支撑跟踪；问题记录描述已发生的事实，需要处置进展和关闭结论。放在同一张表里，排序时无法区分优先级来源，复盘时也难以判断哪些判断准确、哪些环节反复出问题。建议在口径说明中明确边界，风险登记册与问题记录分开维护，需要关联时通过编号互相引用。
评估周期应该设多长，复查频率怎么定？
评估周期跟随项目节奏确定，没有统一标准。迭代型项目可以在每个迭代开始前做一次轻量评估，重点检查外部依赖和资源变化；阶段型项目在里程碑节点做完整评估。复查频率按风险条目的优先级区分，高优先级条目复查间隔短，低优先级条目可以合并到阶段复盘中检查。关键是复查时点写进登记册并指派到人，否则评估结论会停留在文档里，无法随项目推进更新。
评估结论在评审时被质疑分级不合理，怎么处理？
先回到口径说明核对分级标准是否被一致执行，再看该条目的依据出处是否充分。如果问题出在标准本身，例如影响维度没有覆盖质量或合规，应记录标准调整的原因和生效时间，并对同批条目重新校准；如果问题出在依据不足，补充访谈或专家意见后重新判断档位。评审意见和调整过程一并留在评估记录中，便于后续复查时理解当时的判断逻辑。
