项目管理离不开变更管理。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。变更请求在项目中是常有的，并以多种不同的形式出现。变更是允许的，但它应该在可控的范围内。
实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。该过程审查所有针对项目文件、可交付成果、基准或项目管理计划的变更请求，并批准或否决这些变更。本过程的主要作用是，从整合的角度考虑记录在案的项目变更，从而降低因未考虑变更对整个项目目标或计划的影响而产生的项目风险。该过程的输入、工具与技术和输出，如下图所示：
项目管理系统实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任。需要通过谨慎、持续的管理变更，来维护项目管理计划、项目范围说明书、和其他可交付成果。应该通过否决或批准变更，来确保只有经批准的变更才能纳入修改后的基准中。
项目的任何干系人都可以提出变更请求。尽管也可以口头提出，但所有变更请求都必须以 书面形式记录，并纳入变更管理和/或配置管理系统中。变更请求应该由变更控制系统和配置控制系统中规定的过程进行处理。应该评估变更对时间和成本的影响，并向这些过程提供评估结果。
每项记录在案的变更请求都必须由一位责任人批准或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织流程中指定这位责任人。必要时，应该由变更控制委 员会（CCB）来开展实施整体变更控制过程。CCB 是一个正式组成的团体，负责审查、评价、 批准、推迟或否决项目变更，以及记录和传达变更处理决定。变更请求得到批准后，可能需要编制新的（或修订的）成本估算、活动排序、进度日期、资源需求和风险应对方案分析。这些变更可能要求调整项目管理计划和其他项目文件。变更控制的实施程度，取决于项目所在应 用领域、项目复杂程度、合同要求，以及项目所处的背景与环境。某些特定的变更请求，在CCB 批准之后，还可能需要得到客户或发起人的批准，除非他们本来就是CCB 的成员。实施整体变更控制流程可以参考下图:
实施整体变更控制输出
接下来我们进行详细的解析：
1. PM对可能的因素施加影响
首先要说明的是，在预测型的生命周期中，变更不可避免。为什么不可避免呢？因为项目是面向未来的，对于未来，我们可以预测，但是预测不准是正常，预测准确反而不正常，比如说，团队成员下个月会不会休假？没有人知道，连他自己都不能确定。虽然变更不可避免，但是项目经理可以通过努力让变更尽可能少的发生。避免干系人的主管臆断，觉得自己的变更没有啥影响就自己提出变更了。尤其是客户，项目经理应该花大量的时间和客户在一起，让客户明白，变更会对项目造成影响。每当客户想提交变更的时候都会想到PM的艰难处境，从心理上打消了变更的念头。或者即使想提变更也是提交对项目经理有利的变更，比如延长进度，增加预算。
2. 干系人向项目经理提交变更请求
虽然PM施加了影响,避免了不必要的变更,但是有些变更是无法避免的,也是必要的变更,比如客户在项目进行到一半发现产品在逻辑上少一个防护措施,以前太理想化了.需要再产品上加一个灯。这时候客户会向PM提出变更请求。这里的干系人可以是任何人，比如团队成员，客户，用户，NGO组织，工会等，也可以是任何形式，可以是发邮件通知PM，也可以是找PM聊了下，说出了他们的想法。但只要他们通知到PM，PM就收到了他们的变更请求。
3. PM记录并且评估变更请求的影响
收到了变更请求之后，这时候PM要做的第一件事就是记录。记录到哪里呢？变更日志中。然后评估影响，这个评估是PM自己评估，主要有2个方面：
a.这个变更的影响有多大，首先评估对相关知识领域的影响，比如团队成员说他的工作要提前1周完成。项目经理首先评估他的工作对进度的影响，接下来评估对成本的影响，工作提前完成看上去是好事，如果他的工作需要其他人或者资源的配合，那么就对成本造成了影响。尤其是设备，在不同的时间，设备的租赁费用可以差很多。比如春节前后的运输费用和人力成本都会大幅上涨。
b.PM要看这个变更请求自己能做决定么？比如说团队成员告诉PM，因为过去一周公司出现了紧急状况，所以项目工作延迟了2天。这时候，PM看下这个成员的工作，有1周的自由浮动时间，那么PM自己就可以做决定，调整一下进度计划就好了。如果是客户通知PM需要增加一个功能，那这时候就不在PM的权限范围，因为范围基准需要做调整。
4. PM能做决策么？
只要涉及到基准，PM肯定不能做决定，于是要提交正式的变更请求到CCB去审批。对于那些PM能做决定的变更，PM自己来决定是还是否。
5. 寻找变更的备选方案
一旦PM发现这个变更自己不能做决定，那么就需要提交变更请求到CCB去审批，提交变更请求和提交问题报告一样，在提交之前需要识别备选方案。比如说，客户要求项目要提前一个月完成，并且正式通知项目经理，这时候PM自己就做不了决定，因为改了基准，于是PM要和团队一起讨论如何缩短时间，是团队增加工作时间？还是增加资源？还是把部分工作外包？这个过程就叫备选方案分析。最终，团队应该提交变更请求，同时提供备选方案，并且把推荐的备选方案列出。
6. PM与内部干系人沟通影响
团队在讨论完备选方案之后，PM需要与内部干系人沟通，这里的内部干系人可以简单理解为公司高层，当然不限于公司高层，而是除了团队之外的其他重要干系人。为什么要跟他们沟通？前面和团队一起讨论出了备选方案，这时候团队的任务结束了，PM作为团队和高层之间的接口，这时候就要发挥自己的作用。要确保内部能够达成一致，尤其是高层这些能够做决定的人。高层最终决定给项目增加资源，从而压缩工期。那项目经理就有了内部结论。
7. 跟客户沟通变更影响和备选方案
内部达成一致了，再去跟客户沟通这个变更请求和我们打算采取的措施。这时候还是PM的事情，因为PM是客户和公司之间的接口。PM可以回复客户，缩短交期是可行的，会有成本上的影响。客户也认同这个方案了。那就可以提交变更请求了。
8. 提交变更请求到CCB
这时候PM已经和内部沟通好了，也和外部的客户沟通好了。所以接下来就可以让CCB开会了。为什么要先沟通再开会，难道开会不就是用来讨论方案作出决定的么？非也。作为PM，开会不能开surprise的会，既然是大家一起开会，那更多的工作就应该在会议之前就应该解决而不是到了会议上发现突然出问题。在开会方面，我们需要标杆对照的就是我们党的会议。党的会议一定不会有surprise，有问题都在会议前解决了。PM要召开的会议也应该一样。
9. CCB召开会议评审变更请求
变更请求正式提交之后，CCB召开会议进行评审变更请求和解决方案，CCB不是一个固定的团体，但他们是一个正式的组织。对于不同的变更请求应该由不同的成员组成CCB来进行评审。比如变更请求的解决方案是要增加资源（多招一些临时工进行赶工），那么跟生产相关的管理层就需要成为CCB成员，如果变更请求的解决方案是研发人员加班完成工作，那么这是就不需要生产管理，就需要研发的管理层。CCB会在会议上做出决定，是批准还是拒绝变更。并且要通知到PM变更请求的决定是什么。
10. 更新变更日志
变更请求无论是被批准还是别拒绝，PM接下来要做的第一件事情就是记录。所以要把变更请求的决定记录到变更日志中。在项目管理系统中，问题日志，变更日志，假设日志，这些文件一旦出现状态的变化，接下来马上要做的事情就是更新它们。
11. 更新项目管理计划和文件
如果变更被批准了。这个比较容易理解，因为变更可能会影响基准或者影响项目管理计划，这时候就需要更新管理计划和文件。如果变更被拒绝了呢，为什么还要更新？虽然变更被拒绝了，但是之前已经和团队讨论过，和高层汇报过，这时候需要更新相关的文件跟他们沟通，可能会更新会议纪要，问题日志，项目报告，严重的情况下可能要单独做一个报告跟高层沟通。
12. 通知受影响的干系人
如果变更被批准了，要通知相关的人，因为接下来要执行。如果变更没有被批准，更需要通知受影响的人，因为这个变更曾经多次讨论过，现在被拒绝了。一定要让他们知道！
13. 执行变更
通知完了就要执行了。变更一旦被批准，项目团队就需要执行。
14. 跟踪变更的实施情况
如果变更被批准了。PM要跟踪确认变更是按照既定的解决方案进行的，并且没有偏差。批准的变更实际上已经成为了项目工作的一部分。在8.3控制质量的过程，还需要对变更请求进行检查，确保符合质量要求。如果变更没有被批准，PM也要注意确保团队不会执行变更。一旦没有管理好，团队可能会自己以为这个变更是要执行的。从而变成范围蔓延。
15. 重新提交变更请求
这个点特别重要。很多人会有疑惑，CCB拒绝了，你就不做呗，为什么还要重新提交呢？这个原因有两点：PM是项目的负责人，当PM提交变更请求的时候，意味着PM做了一个决定，要做这个事情，这时候要促成相关干系人赞同自己的观点。变更请求被拒绝，并不意味着变更请求有问题，可能是备选方案不太理想。所以PM修改之后，重新在项目管理系统提交变更请求。确保在项目中PM具有能力负责和管理。
有几个点主要注意：
1. 没有经过影响因素评估就不能做出决定；
2. 没有进行方案识别就不能行动；
3. 寻找和沟通备选方案时，要遵循 PM自己-组织内部-组织外部的流程，不要一上来就找客户。
4. 即使变更被拒绝了也要更新管理计划和文件，因为项目的状态发生了变化，而且重要的是会涉及到沟通的问题。
5. 即使变更被拒绝了也要跟踪变更的实施情况，避免拒绝的变更被执行。
粤公网安备 44030402004833号
粤ICP备19092870号
