什么是项目风险？类型、示例与风险描述

什么是项目风险？

项目风险 是一种不确定的事件或条件，一旦发生，会对一个或多个项目目标产生积极或消极的影响。PMI 在《PMBOK 指南》中采用了这一定义。其核心概念是不确定性（可能发生，也可能不发生）、未来（尚未发生）以及对项目所要实现的目标产生影响。

这三个概念是一个很有用的检验标准。如果某件事是确定的，它就是需要纳入计划的事实，而不是风险。如果它已经发生，它就是一个 问题。如果它不会影响范围、时间、成本、质量或预期收益，就不值得作为项目风险来跟踪。

• 风险可能影响的目标： 范围、进度、成本、质量、收益、安全、声誉或相关方满意度。
• 哪些不是风险： 确定的事情（“办公室将在 3 月搬迁”）、当前存在的问题（“服务器宕机了”）或含糊的担忧（“资源配置”）。
• 为什么这很重要： 项目具有临时性和独特性，因此总是伴随着不确定性。及早指明风险，能让您在选择成本仍然较低时有时间做出应对。

最新版的 PMBOK 指南 （第八版，2025 年 11 月发布）仍将风险作为其绩效域之一，并继续区分尚未发生的风险和已经发生的问题。

威胁与机会

大多数人一听到“风险”，就会想到坏事。在项目管理中，风险可好可坏。

团队很少会偶然发现机会。请在风险研讨会上直接提问：“哪些方面可能比计划进展得更好，我们怎样才能让它更有可能发生？”典型的机会包括重复利用其他项目的成果、价格下降、提前获批或供应商提前完工。

风险的三个组成部分：原因、事件和影响

描述得当的风险包含三个部分。将它们区分开来，可以避免团队把风险的原因或后果与风险本身混为一谈。

一个简单的模板可以将这三个部分合成一句话： 由于 [原因]， 存在以下风险： [事件]， 从而导致 [影响]。

如何撰写项目风险描述

风险描述是您写入以下文件的那句话： 风险登记册。写好风险描述能让评分、确定负责人和制定应对措施容易得多。

1. 从原因写起。 说明造成不确定性的事实或条件，例如制约因素、假设条件或依赖关系。
2. 描述一个不确定的事件。 使用“可能”一词。如果发现有两个事件，请将其拆分为两项风险。
3. 说明对目标的影响。 尽可能使其可衡量：延误天数、成本、损失的范围或受影响的质量。
4. 确认它不是问题或确定的事情。 如果它已经发生或肯定会发生，请以其他方式处理。
5. 确认有人能够对其采取行动。 好的风险描述能提示应由谁负责，以及应对措施大致是什么样子。

项目风险的类型

按类型对风险进行分组，有助于检查风险识别是否覆盖了所有领域，也有助于跨项目比较风险。并不存在唯一的官方清单；请使用适合您组织的类别。下表列出了一组常见类别。

许多组织将其风险类别整理成风险分解结构（RBS），即一个风险来源的层级结构，类似于 工作分解结构。在研讨会上逐项过一遍，是快速发现遗漏的好方法。

单个风险与整体项目风险

PMI 将 单个项目风险（即您登记册中的具体事件）与 整体项目风险（即所有不确定性对整个项目的影响）区分开来。一个项目可能没有任何单个重大风险，但由于存在许多中等风险、目标过于激进或复杂性高，整体上仍然风险很大。整体风险通常在发起人或董事会层面讨论，可以通过以下技术进行估算： 蒙特卡洛模拟.

已知风险和未知风险

• 已知风险 是已经识别和分析过的风险。您需要为其规划应对措施，并通常以应急储备来覆盖其预期成本，该储备包含在成本 基准.
• 未知风险 无法事先识别。组织通常用基准之外的管理储备来覆盖它们，并通过治理程序予以释放。
• 新兴风险 是随着项目推进才显现出来的风险，这也是风险识别必须贯穿始终的原因。

项目风险、业务风险与运营风险

项目风险 影响项目自身的目标：按时、按预算、按质量交付商定的范围。 业务风险 影响整个组织的目标，例如新产品上市后能否卖得好。 运营风险 存在于移交之后的日常业务运营中，例如系统停机。三者相互关联：项目的存在往往是为了降低某种业务风险，而项目期间走的捷径可能在日后造成运营风险。

考试指南还将 投机风险（可能带来收益或损失）与 纯粹风险（只会带来损失，例如火灾或盗窃）区分开来。纯粹风险通常通过保险来转移。

按行业划分的项目风险示例

真实的风险描述是针对具体项目的。以下示例展示了不同场景中的威胁和机会。

常见的项目风险及预警信号

有些风险几乎在每个项目中都会出现。了解它们的预警信号，即 触发因素，有助于您在风险演变为问题之前采取行动。

在每项风险旁边记录触发因素，让负责人知道应关注什么。我们关于 相关方管理 的指南更深入地介绍了许多与人员相关的风险。

应记录的风险属性

仅有风险描述还不足以管理风险。大多数团队会为每项风险记录以下属性。

我们的免费 风险登记册模板 包含核心属性，并可自动计算概率 x 影响得分。

风险、问题、假设条件与制约因素的区别

这些术语经常被混淆。每一种的处理方式都不同，因此值得加以区分。

假设条件是最好的风险来源之一。针对每项假设条件，问一问如果它被证明不成立会怎样。如果答案很严重，就登记一项风险。 RAID 日志 将风险、假设、问题和依赖关系集中记录，适合较小的项目；参见我们的 RAID 日志模板.

如何识别项目风险

风险识别最好作为团队活动开展，从启动阶段开始，一直持续到收尾。

1. 审查项目文件。 阅读 项目章程、范围、进度、预算、假设条件和制约因素，思考哪些方面可能出现不同的情况。
2. 质疑假设条件。 针对每一项，问问自己有多大把握，以及如果它是错的会怎样。
3. 逐项梳理工作。 逐一检查工作分解结构和进度计划，尤其是关键路径和外部依赖关系。
4. 举办风险研讨会。 召集团队、发起人、用户和关键供应商，按类别对威胁和机会进行头脑风暴。
5. 借鉴以往经验。 请查看 经验教训 以及类似项目的风险登记册。
6. 请教专家。 采用 专家判断 ，涉及技术、法律、安全或商务领域。
7. 使用结构化技术。 检查清单、风险分解结构、SWOT 分析以及根本原因分析工具（例如 鱼骨图 ）能帮助团队跳出显而易见的思路。
8. 记录并指派。 将每项风险按原因、事件和影响写下来，登记到登记册中，并指定负责人。

风险识别是一个更广泛过程的第一步，该过程还包括分析、应对规划和监控。

相关风险术语

应对措施落实后，重新为每项风险评分，以了解还剩下哪些风险。

敏捷项目中的项目风险

敏捷工作方式本身就能降低许多风险。短迭代、频繁演示和排好优先级的待办事项列表能及早暴露问题，并在方向改变时限制工作的损失。不过，风险仍然需要关注。

• 在冲刺计划会、每日站会和回顾会中提出风险，而不只是在单独的会议上提出。
• 尽早处理高技术风险，例如开展时间盒式的技术探究（spike），安排在早期的 冲刺.
• 将降低风险的工作加入待办事项列表，使其与功能一起排定优先级。
• 使用清晰的 完成的定义 来降低质量风险。
• 对于跨越多个冲刺或依赖其他团队的风险，维护一份轻量级的风险清单或看板。

描述项目风险时的常见错误

• 写下的是类别而不是风险。 “人员风险”无法评分，也无法指定负责人；“首席开发人员可能在第二季度离职”则可以。
• 将问题记录为风险。 如果它已经在发生，请将其移入问题日志并立即采取行动。
• 罗列确定的事情。 已知的公共假日是计划中的事实，而不是风险。
• 在一条描述中混入多个事件。 将它们拆分开，以便分别评分和指定负责人。
• 忽视机会。 只记录威胁的登记册会错过更快或更省钱地完成项目的途径。
• 只识别一次风险。 每个阶段都会出现新的风险；请在每个阶段关口以及发生任何重大变化时审查风险清单。
• 没有负责人。 没有指定负责人的风险很少会得到管理。

本主题的免费模板

浏览所有模板

常见问题