项目风险管理流程图（从风险台账到关闭）
项目风险管理流程图：登记风险、评估概率与影响、升级、选择应对策略、每次评审时重新评估，最后关闭风险或转为问题。
什么是项目风险管理流程图（从风险台账到关闭）流程
大多数项目风险台账都是写过一次、再没人读。它们在启动阶段的一场研讨会上被填满、打分、确认，然后一直到有人要为下一次指导委员会做一页幻灯片时才被重新打开——而到那时，其中一半条目描述的是早已结束的阶段，真正伤到项目的那条风险，从头到尾就没写进去过。让项目风险流程真正跑起来的，不是打分方法，而是那个循环：每一条未关闭的风险都会按固定节奏回到眼前，要么变化，要么发生，要么关闭。
本页是项目层面的循环，画在五条泳道和五个阶段上。它不是组织层面的风险评估方法——判定标准、可能性与影响的量表、固有分数与剩余分数的对照，以及现有控制措施有效性的判断，属于 /zh/templates/风险评估流程 上的风险评估流程图；本图假定这些量表已经存在，只是直接使用它们。它也不是针对单条风险的路由判定：如果问题是某条具体风险应当由哪个机构来承担，一份专门的风险升级决策树会比这里的一道门槛决策深入得多；而谁有权签字承担一项风险，则由风险接受决策流程图来确定。本图还止步于风险成真的那一刻：从那里开始由问题台账接手，而正在发生的业务中断则转入 /zh/templates/事件管理流程 上的事件管理流程。
多数项目风险程序留作默认的两件事，在这里被明确画了出来。升级阈值是项目经理在选择应对策略之前就要回答的一个决策，而不是等到缓解措施已经算完成本之后——这样严重的风险还能在仍有授权、仍有预算可争取的时候送到指导委员会。而“风险是否已发生？”是一条真实的分支：已经发生的风险不再是风险，所以它会被转为项目问题登记，台账里的那一条则按已发生结案，而不是一个月又一个月地重新打分。应对与关闭之间的一切都是一个循环——“风险是否仍然存在？”把未关闭的风险送回重新评估，只有窗口期已过的风险才会走到关闭，以及那条为下一轮识别提供养分的经验。
本流程图涵盖的内容
本模板包含
- 五条泳道——项目团队、风险责任人、项目经理、指导委员会、PMO——铺在五个阶段上：识别、评估、应对、监控与关闭。
- 来自任何来源的识别，全部汇入同一本台账：风险被提出、按原因与影响登记，并由一位具名的风险责任人接受责任归属，然后才开始打分。
- 由项目经理回答的“是否超过升级阈值？”。超过的送往指导委员会，由其评审已升级的风险并确定应对授权与预算；未超过的直接进入应对策略的选择。
- 四选一的“采用哪种应对策略？”——规避、降低、转移、接受——其中规避、降低与转移汇合于“分派行动项，明确责任人与期限”，而接受则直接进入监控，除了盯着它之外无事可做。
- 监控循环：“在每次评审时重新评估风险”通向“风险是否已发生？”，再到“风险是否仍然存在？”，其“仍存在”分支把风险送回下一次评审，而不是送出流程。
- 两个终点而不是一个。已发生的风险被转为项目问题登记，并在“转由问题台账管理”处离开本流程；窗口期已过的风险由 PMO 在风险台账中关闭，终止于“风险已关闭并沉淀经验”。
何时使用本模板
- 你们要写项目管理计划中的风险章节，需要用一张图说清楚谁识别、谁负责、谁升级、谁关闭。
- 你们的台账里有好几个月没动过的条目，需要把评审循环和关闭判定内建进流程，而不是交给做汇报材料的那个人。
- 风险和问题被登记在同一张清单里，你们希望把转换点和向问题台账的交接画出来，而不是默认它存在。
- 指导委员会一次又一次拿到已经来不及改变什么的风险，而升级决策需要放在应对策略之前，而不是之后。
- 你们要带新的项目经理或工作流负责人，希望用一张图把责任归属、升级阈值和四种应对讲清楚。
运作方式
把泳道改成你们的治理结构
把项目团队、风险责任人、项目经理、指导委员会和 PMO 换成你们真实存在的角色与机构。让风险责任人与项目经理保持分开：一个承担风险，另一个运行流程。如果没有 PMO，就把那条泳道并入项目经理，而不是在图里留一个从不做事的机构；如果在你们这里指导委员会和项目发起人是同一个人，就把这一点写明。
把升级阈值写成数字
“是否超过升级阈值？”在你附上数字之前是空的。多数项目会设一个与项目经理授权额度挂钩的金额数字，以及一个与浮动时间或合同里程碑挂钩的进度数字，然后以先被突破的那一个作为触发条件。另外增加一条完全不看评分的通道，用于安全、法律、监管或声誉方面的风险暴露——这类风险按其性质升级，而不是按其分数。
确定风险台账的必填字段
决定“将风险登记进风险台账”必须记录什么：原因、事件与影响各自成一个字段，提出日期，拟定的责任人，受影响的工作包或里程碑，概率与影响及其打分日期，选定的应对策略，带期限的行动项，以及当前状态。任何被设为选填的字段，一个月之内就会是空的；而一条只写了三个词的风险，当时不在场的人根本无从重新评估。
定下评审节奏，以及提前触发的条件
只有存在计划中的评审，这个循环才会转。把它挂在项目已有的汇报节奏上，而不是新开一个会；分数较高的风险比其余的评审得更频繁；并写明哪些事件会把重新评估提前拉出来：供应商更换、里程碑逾期、新增依赖、范围变更、一次事件，或者一项缓解行动开始滑期。一本只在汇报材料前才被动一动的台账，一个月里只有一天是准确的。
让缓解行动落到实处
“分派行动项，明确责任人与期限”意味着每一项行动都有一位具名的人、一个到期日，以及项目计划里带工作量的一行。只活在风险台账里的行动，要和大家被考核的那些工作竞争，然后落败。把它们放到团队本来就会看的地方去跟踪，并让风险责任人在评审上汇报进展，而不是汇报“风险没有变化”。
约定风险转问题的规则，然后发布一个版本
定义什么算已发生、谁可以不等开会就宣布，以及交叉引用如何双向保留，好让历史在转换之后仍然完整。然后带着定稿的图与项目经理、一位风险责任人和指导委员会的主持人一起走一遍，按他们实际的做法改正，再发布该版本并保留此前的版本，让日后打开它的人知道自己看的是哪一版。
常见问题
项目风险管理流程包含哪些步骤？
识别风险，按原因与影响把它登记进台账，让一位具名责任人接受它，评估概率与影响，判断它是否突破升级阈值，从规避、降低、转移、接受中选择一种应对，分派带责任人和期限的缓解行动，在每一次评审时重新评估，一旦发生就把它转为问题，并在其窗口期过去之后关闭。各种方法论用不同的词讲同一副骨架——PRINCE2 描述的风险管理程序从识别与评估走到规划与实施应对措施，沟通贯穿其间；而早期以过程为架构的 PMBOK 指南版本，则把规划应对与实施、监控应对分开。实践中失效的很少是这份清单，而是回到重新评估的那条路。
风险与问题有什么区别？
风险是不确定的：它可能发生，也可能不发生，所以要写成原因、事件与影响，并带有一个概率。问题则是已经发生、或现在已成定局的事。两者的管理方式不同，所以这个区分值得坚持。风险在事件发生之前得到应对策略和缓解行动；问题得到的是遏制、恢复方案，以及往往还有一份针对它所消耗的时间或金钱的变更申请。把两者放在同一张清单里，会让台账塞满已经无法缓解的条目，并把真正不确定的那些淹没掉。在本图中，这一转换是一条明确的分支：“风险是否已发生？”会开立一条项目问题登记，台账里的条目按已发生结案，而交叉引用双向保留。
风险应对的四种策略是什么？
规避、降低、转移与接受。规避消除原因，通常靠改变范围、顺序或做法，而且它是唯一一种把风险从台账上拿掉、而不只是把它缩小的策略。降低是压低概率、影响或两者，大多数缓解行动都落在这里。转移通过固定价格合同、责任条款或保险把后果转给另一方，这也是最常被高估的一种：它通常转移的是财务后果，而交付后果仍然留在项目身上。接受意味着明知而承担这项风险，配一位具名的批准人、一笔预留的应急储备和一个复评日期——没有人为之留出预算的风险，不是一项被接受的风险。如果你们的方法论把机会当作正面风险，它们有一组镜像的应对：利用、增强、分享与接受。
项目上的风险应该由谁负责？
一位具名的人，离原因足够近，能察觉它正在变化；层级又足够高，能对它做点什么。实践中这通常是某个工作流、技术或供应商方向的负责人，而不是项目经理——项目经理负责的是流程，而不是流程里的每一条记录。有两种模式带来了大部分麻烦：把责任归给一个团队或一个部门，于是没有人重新评估它，因为没有具体的谁被要求这么做；以及所有风险都由项目经理负责，这会把台账变成一份个人待办清单，并从此不再被打分。所以本图把“接受该风险的责任归属”单独做成评估之前的一个步骤——一位从未答应过的责任人，不会出现在评审上。
本页与风险评估流程图有什么不同？
两者覆盖的是不同的地面。风险评估流程图讲的是方法：如何商定判定标准与量表、如何描述风险、固有分数与剩余分数如何得出、如何判断现有控制措施的有效性，以及如何选定一项处置措施。它写一次，适用于整个组织。本页则是消费这些量表的项目层面运行循环——提出、登记、认领、评估、升级、应对、行动、评审、转换或关闭——贯穿一个项目的整个生命周期，并且图里有指导委员会、PMO 和问题台账。如果你们要定义风险如何打分，请用风险评估流程模板；如果你们要定义项目如何一周一周地运行自己的风险台账，请用这一份。