识别风险是什么
识别风险要同时做两件事：找出可能影响项目的单个风险，并评估整体项目风险水平。它贯穿项目全过程，不是启动阶段的一次性动作：随着设计细化、供应商到位与需求变更，新的风险会持续出现。识别质量的决定因素是覆盖度与描述质量，而不是工具的高明程度。
基本信息
| 所属过程组 | 规划（11.2），并在全过程反复开展 |
|---|
| 识别对象 | 单个风险与整体项目风险来源 |
|---|
| 常用技术 | 头脑风暴、德尔菲、访谈、根本原因分析、假设分析、SWOT |
|---|
| 主要输出 | 风险登记册、风险报告、项目文件更新 |
|---|
典型使用场景
- 启动阶段：结合章程、商业论证与假设日志建立初版风险登记册
- 设计评审：技术方案确定后识别性能、架构与集成风险
- 采购前：识别供应商能力、交期与合同条款风险
- 上线前：识别切换、数据迁移与回退预案相关风险
- 复盘时补充：把已发生的问题转为同类风险的识别输入
风险来源分类
| 类别 | 典型风险 | 识别抓手 |
|---|
| 技术 | 方案未验证、性能不足、集成冲突 | 评审记录、原型结论、历史故障 |
| 外部 | 供应商延迟、法规变化、市场变化 | 合同条款、政策跟踪、行业动态 |
| 组织 | 资源被抽调、优先級变更、重组 | 资源计划、决策会议记录 |
| 项目管理 | 估算偏差、沟通失效、范围蔓延 | 过程审计、绩效偏差趋势 |
识别技术对照
| 技术 | 适用场景 | 注意点 |
|---|
| 头脑风暴 | 快速铺开风险清单 | 需要跨职能参与，避免同质化 |
| 德尔菲 | 专家意见分歧较大时 | 匿名多轮，避免权威压制 |
| 访谈 | 关键角色深度挖掘 | 受个人视角限制，需交叉验证 |
| 根本原因分析 | 已发生问题的同类风险 | 区分原因与现象 |
| SWOT | 结合内外部环境识别 | 需转换为具体风险描述 |
| 假设分析 | 检查假设是否成立 | 假设失效常被忽略 |
风险登记册字段
风险登记册字段
编号 | 风险描述（原因-事件-影响） | 类别 | 概率 | 影响 | 分值
触发条件 | 应对策略 | 责任人 | 状态 | 上次更新
# 描述格式示例：因第三方接口未按时联调（原因），导致上线延期（事件），
# 影响里程碑与验收（影响）；缺少原因与影响的描述无法评估也无法跟踪
风险与问题的区别
| 维度 | 风险 | 问题 |
|---|
| 状态 | 尚未发生，可能发生 | 已经发生 |
| 管理载体 | 风险登记册 | 问题日志 |
| 管理动作 | 识别、分析、规划应对 | 指派责任人、限期解决、跟踪闭环 |
| 混淆后果 | 用问题思维管风险，永远在救火 | 把已发生的问题当风险登记，会延误处置 |
落地要点
- 风险描述统一写成原因、事件、影响三段式，便于评估与跟踪
- 识别活动定期开展，变更与阶段转换是必设的识别时点
- 对已发生的问题做同类风险回溯，避免同类问题重复出现
- 责任人指派到个人，多人共同负责等于无人负责
风险描述只写事件不写影响与触发条件，后续既无法量化概率影响，也无法判断何时该启动应对措施。
高风险领域提示
- 未验证的技术方案与首次使用的第三方组件
- 外部依赖与供应商交付节点的可靠性
- 关键人员的单点依赖与技能不可替代
- 监管、数据合规与安全评审带来的等待周期
