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