本文为大家介绍的是昆山企业内训|实施整体变更控制的全过程，下面是昆山企业内训|实施整体变更控制的全过程的具体内容，供大家参考，更多PMP考试相关资讯可关注思摩特项目管理

↑ PMI授权办学资质（11年~12年）↑最新资质在PMI官方网站或者思摩特百度百科查询（十余年PMP、ACP、企业敏捷内训等项目管理教学保证）

实施整体变更控制过程是PMBOK中最重要的流程，没有之一，这个流程如果不能掌握，不仅说明没有理解pmbok的精髓，还非常有可能影响考试的通过。变更的管理为什么这么重要? 因为PMBOK有一个假设，我们要管理的项目的生命周期的类型是预测型。在预测型的生命周期中，需求是一开始就定好的，范围也是一开始定好的，时间也是，成本也是。如果要改，抱歉，必须要走流程。走流程的意思就是要通过实施整体变更控制的过程来进行管理。

那么变更控制流程是怎么一回事呢？从PMP的考试题目来看，一会要评估，一会儿要跟干系人沟通，一会儿要执行，学友们经常晕掉。这个不怪大家，也不怪PMI的考试题目，一方面，书上对于实施整体变更控制的过程并没有特殊对待，用的是ITTO的形式来处理，所以搞不清楚是正常的，另一方面，这是PMP考试的特点决定的，对于监控过程组，考的是情景题，而在实际的情境中，根本没有标准答案，只能根据实际的情景和我们能够选择的选项进行选择。这两个因素加在一起，学友们看到变更的题目就晕就不奇怪了。

我们这一讲的目的就是给大家提供一个完整而且标准的流程，当遇到变更的题目和情景的时候，就往这个流程中去套，看一下现在在哪一步，接下来的工作就按照流程做下一步，如果题目选项不巧没有流程的下一步怎么办？按照顺序选择再下一步即可。

【整个流程的详细步骤如下图所示】：

接下来我们进行详细的解析：

1. PM对可能的因素施加影响。首先要说明的是，在预测型的生命周期中，变更不可避免。为什么不可避免呢？因为项目是面向未来的，对于未来，我们可以预测，但是预测不准是正常，预测准确反而不正常，比如说，团队成员下个月会不会休假？没有人知道，连他自己都不能确定。虽然变更不可避免，但是项目经理可以通过努力让变更尽可能少的发生。避免干系人的主管臆断，觉得自己的变更没有啥影响就自己提出变更了。尤其是客户，项目经理应该花大量的时间和客户在一起，让客户明白，变更会对项目造成影响。每当客户想提交变更的时候都会想到PM的艰难处境，从心理上打消了变更的念头。或者即使想提变更也是提交对项目经理有利的变更，比如延长进度，增加预算。

2. 干系人向项目经理提交变更请求。虽然PM施加了影响,避免了不必要的变更,但是有些变更是无法避免的,也是必要的变更,比如客户在项目进行到一半发现产品在逻辑上少一个防护措施,以前太理想化了.需要再产品上加一个灯。这时候客户会向PM提出变更请求。这里的干系人可以是任何人，比如团队成员，客户，用户，NGO组织，工会等，也可以是任何形式，可以是发邮件通知PM，也可以是找PM聊了下，说出了他们的想法。但只要他们通知到PM，PM就收到了他们的变更请求，

3.PM记录并且评估变更请求的影响。收到了变更请求之后，这时候PM要做的第一件事就是记录。记录到哪里呢？变更日志中。然后评估影响，这个评估是PM自己评估，主要有2个方面，

a.这个变更的影响有多大，首先评估对相关知识领域的影响，比如团队成员说他的工作要提前1周完成。项目经理首先评估他的工作对进度的影响，接下来评估对成本的影响，工作提前完成看上去是好事，如果他的工作需要其他人或者资源的配合，那么就对成本造成了影响。尤其是设备，在不同的时间，设备的租赁费用可以差很多。比如春节前后的运输费用和人力成本都会大幅上涨。

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拒绝了，你就不做呗，为什么还要重新提交呢？这个原因有两点，1. PM是项目的负责人，当PM提交变更请求的时候，意味着PM做了一个决定，要做这个事情，这时候要促成相关干系人赞同自己的观点。2. 变更请求被拒绝，并不意味着变更请求有问题，可能是备选方案不太理想。所以PM修改之后，重新提交变更请求。确保在项目中PM具有能力负责和管理。

变更控制的全过程图，为了通过PMP这个图需要你至少看10遍（是的，是十遍！），看不是目的，要能够默写下来。

有几个点主要注意：

1. 没有经过影响因素评估就不能做出决定；

2. 没有进行方案识别就不能行动；

3. 寻找和沟通备选方案时，要遵循 PM自己-组织内部-组织外部的流程，不要一上来就找客户。

4. 即使变更被拒绝了也要更新管理计划和文件，因为项目的状态发生了变化，而且重要的是会涉及到沟通的问题。

5. 即使变更被拒绝了也要跟踪变更的实施情况，避免拒绝的变更被执行。