项目变更申请流程图（范围、成本、进度）
项目变更申请流程图：变更登记册、影响评估、容许偏差决策、指导委员会审批，以及项目基准的重新设定。
什么是项目变更申请流程图（范围、成本、进度）流程
项目变更申请要求改动的，是已经议定过的东西：已批准基准中的范围、成本或日期。这正是它与普通的重新安排之间的分别。调整任务顺序、把一个人从一条工作流挪到另一条、或者在浮动时间内吸收两天的滑期，都是项目经理的本职工作，不需要提出申请。这个流程从有人要求某件基准当前并未承诺的事情开始，结束于两种情形之一：一份说法不同的基准，或者一份已结案且记录了理由的申请。
这是项目变更控制，而不是 IT 服务的变更管理。如果你们要决定的是一项变更能否发布到生产环境，涉及 CAB、变更日历、停机窗口与回滚方案，那么 /zh/templates/变更管理流程 上的变更管理流程图，以及 /zh/templates/变更控制流程 上的通用变更控制流程，才是覆盖那片领域的。这里的问题在性质上不同：变更要花多少钱、会挪动什么、由谁出资，以及商业论证是否仍然成立。它也不是组织层面的变革管理——ADKAR 之类模型背后那门与人有关的学问——它更不是阶段关口。如果你们要决定的是在一个阶段结束时是否继续推进，而不是要不要改动基准，请使用 /zh/templates/发布放行决策流程 上的放行与否决策流程。
两个决策支撑着这张图。第一个是容许偏差：这项变更是否小到项目经理可以在授权范围内自行批准，还是大到必须提交指导委员会。没有成文的限额，要么什么都递到委员会——于是它变成一条队列——要么什么都不递，变更就在私下被做掉了。第二个是变更审批方被允许给出什么答案。批准与否决都很直接；暂缓才是大多数登记册处理得最差的一项，因为一项被搁置而没有复议日期的变更，与一项被无视的变更根本分辨不出来。在这里，暂缓有自己通往下一次评审的回路，而否决有一个明确的结案状态，而不是沉默。
本流程图涵盖的内容
本模板包含
- 五条泳道——申请人、项目经理、项目团队、财务，以及变更审批方／指导委员会——横跨五个阶段：申请、影响评估、审批、基准更新，以及实施与结案。
- 申请人与项目经理两条泳道上的受理：提出带有说明与理由的变更申请，把变更登记进变更登记册，然后是“申请是否清楚到足以评估？”这道关口，它把内容单薄的申请退回申请人补充细节与理由，再重新进入同一道校核。
- 项目团队与财务两条泳道中的影响评估：评估对范围、进度与质量的影响，估算成本并评估风险，验证成本与资金来源，然后留下一份完整的影响评估记录——含备选方案、建议与不作为方案——而不是一串评论。
- 容许偏差决策“是否在项目经理的容许偏差之内？”，它把“之内”导向在授权范围内批准，把“超出”导向升级至指导委员会。
- 变更审批方的决策“批准、否决还是暂缓？”，带三条具名分支：批准通往基准更新，否决通往申请人泳道中的一个结案终点，暂缓通往一个搁置步骤，在此后的指导委员会评审上重新提交。
- 从基准更新到结案：更新项目基准，财务更新预算与成本预测，把变更沟通给相关方，项目团队在计划中实施变更，并在变更记录结案之前确认交付。
何时使用本模板
- 你们在编写项目管理计划或 PMO 手册中的变更控制章节，希望把从申请到重设基准的路径放在同一页上。
- 变更是在会议和聊天串里议定的，于是事后没有人说得出批准了什么、由谁批准、以及它给成本和完工日期加了多少。
- 你们需要在下一个项目启动之前把授权范围定下来：项目经理自己可以吸收什么，什么必须提交指导委员会。
- 你们要把项目交接给新的项目经理，或者要向新的指导委员会作说明，必须能讲清楚范围、成本与进度的变更是如何获得批准的。
- PMO 或项目群要在各做各的多个项目之间统一变更控制，而这要在项目工具里配置变更登记册之前完成。
运作方式
把泳道改成与你们角色相符
把申请人、项目经理、项目团队、财务与变更审批方／指导委员会，换成你们实际拥有的角色。在小项目里，变更审批方可能就是一位发起人，财务可能只是一位通过邮件审阅数字的业务伙伴。请合并泳道，而不要画出并不存在的治理机构，并把泳道数量控制在五条以内，好让这张图仍然读得下去。
把你们的容许偏差写在决策旁边
“是否在项目经理的容许偏差之内？”只有在背后有数字时才有用。写下项目经理可以批准的成本与进度偏差幅度，再加一条范围规则，例如不得改动已议定的交付物、效益或合同义务。如果你们运行 PRINCE2，这就是项目管理委员会下放的容许偏差，它还可能附带一笔变更预算，好让常规变更根本不必送到委员会。请在启动时就把限额议定，而不是等到它第一次被试探的时候。
定义影响评估必须包含什么
把“记录影响评估”做成一份真正的模板：对范围、进度、成本、质量与风险的影响，资金来源，考虑过的备选方案，一项建议，以及不作为方案。指明每个维度由谁评估、他们有多少时间——因为一份要做三个星期的评估，最后会变成一个没有评估就作出的决定。
指名变更审批方及其召开节奏
在指导委员会评审这一步上记录：审批人是谁、是否需要法定人数、他们多久开一次会、以及进入议程的截止时间。明确决定会议之间会发生什么：要么由一位具名人员紧急批准并在下次评审上汇报，要么变更等着。把这一点留空，正是那些在走廊上被批准的变更的来源。
让暂缓带上时限
一项被暂缓的变更需要一个复议日期、一位负责人，以及登记册中一个仍然有效的状态——这就是这里的暂缓分支回到此后的指导委员会评审，而不是回到一个终点的原因。在每次评审上检查被暂缓的条目，把已被形势超越的条目连同理由一起结案，好让登记册反映的是决定，而不是把它们堆积起来。
定下重设基准的规则，然后发布并对这张图做版本管理
写明哪些已批准的变更会触发一次正式的基准重设，哪些只是被吸收进预测，并要求在新的基准版本上记录变更编号。保留此前的各版基准，好让几个月后仍然解释得清楚一项偏差。然后把这张图分享到工作真正发生的地方——变更申请表旁边、项目手册里——并保留它自身的版本历史，好让你们能说明程序是什么时候改的、为什么改。
常见问题
项目变更申请与 IT 变更管理有什么区别？
它们回答的是不同的问题。项目变更申请问的是一份已议定的基准——范围、成本、日期，往往还包括效益——是否应当改动，而这个决定是商务性的：要花多少钱、会推迟什么、由谁出资，以及商业论证是否仍然成立。IT 变更管理问的是一项针对在线服务的变更能否发布，而这个决定是运行性的：对用户的风险、测试、停机窗口与回滚。如果对话里出现的是 CAB、变更日历与回滚方案，请使用变更管理流程图。如果出现的是指导委员会、一个修订后的完工日期和一条预算科目，那么这张图才是对的。
一份项目变更申请应当包含什么？
足以让另一个人不开会也能评估它：改动的是什么、为什么改，由谁在什么时候提出，触发因素是什么——一项新需求、一个缺陷、一个外部依赖、一个被推翻的决定——紧急程度如何、谁会受到影响，以及什么都不改会发生什么。评估补上其余部分：对范围、进度、成本、质量与风险的影响，资金来源，考虑过的备选方案，以及一项建议。请把这两者作为各自独立的记录保存。申请是申请人的原话，评估是项目的回答；把两者合并，事后就再也看不出当初实际要求的是什么。
谁批准项目变更申请？
这取决于规模，而这正是本图中容许偏差决策的用途。落在项目经理启动时获授权的偏差幅度之内的变更，在项目经理泳道内获得批准并被登记。超出的一律送交变更审批方，通常是指导委员会、项目管理委员会或发起人。PRINCE2 把变更审批方描述为项目管理委员会可以下放的一个角色，有时还附带一笔变更预算，好让常规变更不必占用一次完整的委员会决定；PMI 的整体变更控制则用变更控制委员会做同一件事。无论你们叫它什么，都请把限额写下来：一个未定义的容许偏差意味着，要么什么都升级，要么什么都不升级。
暂缓一项变更究竟意味着什么？
意味着决定被推迟，而不是被拒绝——通常是因为影响还不清楚、这项变更取决于另一个决定，或者它本就属于更晚的阶段或版本。它只有在暂缓带上时限时才管用。在本图中，暂缓分支通往一个搁置步骤，在此后的指导委员会评审上重新提交，而不是通往一个终点，因为一项没有回路的暂缓变更，就是一次没有人需要说明理由的否决。请为每一个被暂缓的条目给出复议日期、负责人，以及登记册中一个看得见的状态。
每一项批准的变更都必须重设基准吗？
凡是改动了项目承诺交付什么、什么时候交付、以及花多少钱的，都要重设基准。否则偏差报告衡量的是一份你们已经同意放弃的计划，而每一份状态报告都需要口头解释。请保留此前的各版基准，而不是覆盖它们，在新版本上记录变更编号，并写下批准日期。在容许偏差内批准的小变更通常被吸收进预测，而不触发正式的基准重设——请在计划里写明哪些属于哪一类，好让两个人读同一份报告时得到同一个数字。
这个流程如何遏制范围蔓延？
靠的是在变更被议定之前、而不是在它交付之后，就让它的代价看得见。范围蔓延很少是一个大决定；它是一连串被团队吸收、从未送去评估的小增补。这里真正起作用的控制有三项：登记册，让每一项申请都有一条记录；影响评估，让没有人在看不到它对日期和预算做了什么之前就批准一项增补；以及容许偏差限额，让项目经理清楚知道自己的权限到哪里为止。这个流程无法阻止变更，也不应当阻止——它让变更成为有意识的、可追溯的。