管理和控制项目的变更

项目在一开始就要定义变更流程，让所有人都意识到，任何更改都有成本和代价。要尽量在前期规划阶段就把这项工作做细、做好。

一般要求所有需求变更由客户统一归口汇总，再由内部意见一致后，统一以正式项目文件的方式提交给项目经理，评估其对成本和进度的影响。项目经理提交书面文档给公司领导并等待处理意见，主要说明申请变更原因，并指出由此带来的不确定后果。如果同意变更，则让客户在变更方案上签字；如果不同意，就按照公司指示和客户反复沟通。

要分辨面对的是扩大范围的变更，还是发现范围的变更。

扩大范围的变更会增加费用和时间，却不能给客户带来巨大的价值，而且会使项目变得不清晰、困惑、重点不清楚。所带来的价值可以通过另一个独立项目来完成。通常只是满足领导的需要，而不是实际的需要。

发现范围的变更能够更好地实现结果和利益相关方的迫切需求，能更加明确项目的目的，把项目范围缩小到一个更加可控的解决方案。

项目范围蔓延的主要原因，要么来自客户，要么来自项目组自身。

如果来自项目组自身，一般是由于项目人员的技术心态造成的。技术人员想从技术中获得成就感的渴望，促使他们自觉或不自觉地按照兴趣创造一些没有必要、不合理、仅满足自身情感需要的产品。所以，对于项目组自身造成的项目范围蔓延，一定要谨慎对待，确认新想法是否有助于项目目标的实现。

如果项目范围蔓延来自客户，客户不会因为供应商所做的额外工作而抵消对整个项目延期的不满。那么应对原则就是绝不让步，除非交换。变化是客户的权利，但任何变更都需要通过正规的变更控制程序来完成，必须在项目工期、费用或质量等方面做出相应的正规变更。

对变更的管控是项目管理水平的体现。项目经理的成功取决于能否按时、按预算、按质量地完成项目。变更是不可避免的，处理不当就常会导致冲突。这种矛盾可能来源于甲乙双方、项目组内部，或者部门之间。甲乙双方的矛盾主要涉及是否变更、变更范围，以及由变更引发的时间、质量、成本上的变化等。项目组内部的矛盾，来源于项目组成员对变更所增加的工作量，或者对否定自己已完成工作的强烈抵触情绪。部门之间的矛盾，往往来源于公司管理层对项目底线的坚持，以及市场营销、售后等部门的工作调整。

变更好的一面是可以发现项目中的不足，及时调整，进一步优化项目的资源配置。但是执行变更的前提必须是能够更有效地推动项目。

当变更真的发生时，一定要有正式的变更机制，冷静应对。可以人为地增加变更的摩擦系数，让变更变得更困难，客观上降低变更的频率。能否用一个正式的理由拒绝第一次变更至关重要，这个正式的理由必须是在项目开始前就制定好的规矩。要建立变更申请登记表和变更申请表，并让客户签字走流程，让客户意识到变更是需要付出成本的，不是想改就能改的。

在做出是否变更的决定之前，不需要完全拒绝可能的变化。具体而言，要做到以下几点：

通过项目限制模型逐项过滤，形成一份言之有理的文件，作为与变化提议者谈话的基础。
必须了解变更的内容和原因，必要时可以向主要相关利益方提问，以便澄清。
使用项目变更需求，确定该变更给时间、费用、质量等方面带来的影响。
需要对原有项目规划的执行负责，明确说明自己必须做出调整，并将其加入规划中，确保利益相关方十分明确局限性变更带来的影响。如果有影响，让他们对变更需求给予批准或否定。

在项目生命周期中，变更的处理原则是：

项目早期的变更，原则上应倾向于接受，当然必须遵守变更控制程序。
项目中期的变更，要分析变更的影响，原则上尽可能与相关人员沟通，取消变更。
项目后期的变更，成本太高，原则上应尽量不变。遇到大的变更，可以考虑启动一个新的项目；遇到小的变更，也要到售后服务的时候再做。

客户提出变更时查看以前的方案和备忘录，看看前期相关问题和意见是如何界定的。如果有变化，需要和客户再签字确认，避免以后说话没有凭据。同时和客户心平气和地沟通，探讨客户想变更的根本原因是什么。是不是有同样能达到相同目的，但对大家来说代价更小的选择，努力去寻找这样的方案。

变更管理的程序分为以下几个步骤：

评估信息的准确性，确认项目变更事实：

这一步最应该做的是了解客户真正的需要，而非变更管理。

提供变更申请的书面记录：

原则上讲，谁提出变更，就由谁提出书面申请。项目变更申请文档的作用不是为了避免变更，而是对可能的变更进行评估，以便实现更好的结果。文档中要有项目变更建议、变更建议原因、变更将对项目局限性产生什么影响、主要相关利益方审批。

除此之外，还需要界定变更发生时能做什么、不能做什么，规定一个大家都同意的办法，以便提出变更，并评估其对项目基准的影响；评审变更会引起哪些连锁变更，以及如何对这些变更进行管理。

分析变更对范围、进度、成本、质量等诸方面的影响：

不要忽视变更对时间安排和质量的影响。

向提出变更者表明预期：

沟通变更影响，确认是否取消变更。谁先找到最佳结论并不重要，重要的是寻找最佳结论的过程。

如果能给那些试图说服项目团队的人一个信号，表明在这个探索过程中，项目团队是他们的伙伴，探索过程的双方都有益，也许他们就会把项目团队的批判性问题看作是双方都不可缺少的工具。

可以通过利益相关方访谈的形式，了解变更的每个细节，完成变更需求文件，填入变更原因；带着这些信息与团队一起开会，共同思考每个局限项。忠告不如警告，以损失为导向的沟通会更有效。要勇敢地与提议的人进行对话，甚至有必要可以和主要利益相关方对话。

针对变更请求提出相应的解决方案：

要给客户多个选项。还要建立由来自不同领域的人组成的变更控制委员会，以批准或否决变更。这个委员会的组成人员必须有相应的职位和权限，有能力在管理上做出承诺。

在没有解决方案之前，不要向高层汇报。最佳的方式应该是给出至少三种方案，让管理层做选择题，不要让他们做问答题。

查阅审批权限，选择合适人员对变更进行审批：

没有合法授权的人签字批准，会造成令人不快的矛盾。

召开变更控制会议，批准或否决变更，对变更做出决策。
根据对变更请求的审批状态与相关人员进行沟通：

完成项目变更需求文件后，要告知利益相关方，让他们了解最新的进展。如果他们同意上述变更，则需要在变更表上签字；如果不同意，可以记录相应的理由，将它存档，以备今后有类似的问题出现。

指导与执行变更相关的工作，跟踪变更的执行状态：

保证变更的正确执行，保证相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保所规定的功能要求都能实现。

在变更过程中，要注意将变更执行结果及时通知相关人员，同时做好执行结果的实时跟踪。

如果项目中，客户自己糊涂，又是强势大客户，根本听不进去我方的规范和流程，这个时候就不要固守上述变更流程，要另想办法。