对变更的管控，是项目管理水平的体现。

变更不可避免，冲突不一定都是坏的，但处理不好，就会形成矛盾。矛盾可能来自甲乙方、项目组内部，或是部门之间。

1.甲乙双方的主要矛盾，主要涉及要不要变更、变更的范围多大，以及由于变更而引起的时间、质量、成本上的变化等。

2.项目组内部的矛盾，主要来自变更要额外增加的工作量，以及对成员自身已完成工作的被推翻而引发的抵触情绪。

3.部门之间的矛盾，主要来自管理层对项目底线的坚持，以及市场、营销、销售等部门的工作调整。

由于项目变更引起的矛盾涉及到方方面面，项目的管理者需要保持警惕。

以下将梳理5种常见的变更场景下的应对方式。

场景1：项目范围蔓延

项目中，由于种种原因，人们会加入许多细小的计划外工作，当这些小工作的累加，会静静地改变了项目的范围，导致了项目范围的蔓延，直到某一天，这些变化使得项目被摧毁。

项目范围蔓延是什么原因导致的呢？

一方面是客户的原因，另一方面来自项目组自身。

对于来自客户的原因，是因为他们在项目过程中提出了一些小的、略微加一点工作量就能实现的想法，这些对于项目成果的特征和特性没有太大关系，也能提升客户满意度，但是这些小工作累加起来，就会对工期、费用造成影响，最终使得管理层不满，同时也使得客户对项目结果不满，客户并不会因为项目组做了额外的工作而抵消对项目延期、质量下降的不满，甚至还可能引起法律纠纷。

所以，项目管理者要认识到，客户的这些增加的想法，只会越来越多，因为人的欲望是无穷的。更现实的是，不管产品特性多么耀眼，人们在一段时间后，就还是只会把它当作正常的功能而已。如此一来，不管项目组做了多少，客户都总会觉得不够。

要避免项目蔓延，要谨记一条原则：决不让步，除非交换。

变更是客户的权利，但变更需要通过正规的变更控制程序去完成，同时必须在工期、费用、质量等方面作出相应的变更。

对于来自项目组自身的原因，要谨记，这样导致项目范围蔓延的情况，损失是只能自己买单的。

在项目执行过程中，团队内部或外部总会不时冒出新的想法，而技术人员容易受到技术心态的影响，而钻到某个想法里面去了，进而按个人兴趣做出了一些没必要的、不合理的，只是在满足自己情感的产品。这时候，项目管理者一定要谨慎对待，确认新想法是否有有助于项目实现，如果不是，那么不能放任自流，要及时停止做这些与项目结果关联不大的事情。

场景2：客户不满意一点小瑕疵

这种情况很常见，客户拿到产品后，发现了一处不影响使用的小瑕疵，通常会感到不舒服，然后要求更换。更换的要求是合理的，但对于商家而言并不是最经济的，但问题的矛头其实是客户的内心不舒服，而不一定是产品就不能用。所以，商家会设定一些繁琐的程序，即可以换，但是要等一段时间。这样的方式，让一部分客户最终放弃了更换。

这些繁琐程序，本身是正规存在的，但同时也是复杂的，它增加了变更的摩擦系数，让变更变得困难，客观上就降低了变更的频率。所以，现在大家都理解，这便是为什么很多公司都会设置很多复杂的程序的原因了。

场景3：开始时就给了客户多个选项

同一家公司，在洽谈阶段给了客户两套解决方案，当时客户选择了第一套解决方案，在第一套方案执行的过程中，客户突然发现第二套方案更好解决了某个问题，于是希望变更成第二套解决方案，这不禁让公司为难。

有什么解决办法吗？——有，就是让项目具有更大的灵活性。

有一种软件系统中常用的方法——系统变量设计，它的核心思想就是，在设计时就把可能的变化作为可选项来处理。

例如，一个APP首页界面，在设计的时候，就做成了客户可配置的自定义首页，如此，在客户需要变更的时候，可以自行配置，如此便可避免了代码的重写。但是，这样的可配置选项的工鞥，需建立在对用客户的了解程度上。

场景4：客户施压变更，你答不答应？

面对客户A的变更请求和催促，项目管理者的你，是答应还是婉拒？

如果答应了A的变更，那么你手头上的BCDE项目，都将可能陷入混乱，可能遇到不同程度的延后，导致更多客户的抱怨。

其实，很多时候，如果项目并没有出现计划外的问题，像客户A这样的变更请求，更多的只是一种试探，他们其实可以忍受原有的方案而不需要马上变更。

如果此时，项目管理者爽快答应了，那么后续，客户只会越来越喜欢变更，他喜欢变更，是因为你喜欢接受客户的变更请求。

那么，项目管理者该如何婉拒呢？

关键在于——谨慎对待第一次变更请求，能否用一个正式的理由拒绝第一次变更。

这个正式的理由，需要在项目开始前就制定好规矩，而不该是一个临时的规定，这样的规定，客户不容易买账，甚至会激怒对方。

不论是什么规矩，关键是先要有规矩，有规矩才能应对客户的“无理要求”。

场景5：给忠告，不如给警告

作为项目管理者的你，某天发现市面上的一项新技术，如果应用在团队和项目中，能够提高团队效率或产品的性能，但代价是增加一些成本、时间，如何和领导沟通这种变更？

可以利用框架效应，建立不同的参照点，让人的心理受到影响，进而影响决策。

同一件事，如果用不同的描述方式，会产生不一样的结果。

人在不同的参照点下，面对风险的态度是不同的。

当人面对收益的时候，往往会小心翼翼，规避风险，获得更稳当的收益。

当人面对的必然的损失时，便会甘愿冒险，选择倾向风险偏好，即既然怎么都是损失，那么不如拼死一搏，可能还有一点转机。

再拿上面新技术应用的例子来说，如何与领导沟通，效果更好？方法便是——给忠告，不如直接警告。

忠告式描述：领导，这项新技术的优点是xxx，有xxx的作用，如果采用了，我们的效率会更高，产品会更好……领导听完，可能还是觉得你是在忽悠，能拖则拖。

警告式描述：领导，这项新技术如果被竞争对手先用上了，那么我们的产品可能会被挤出市场，会导致xxx的损失……领导听完，可能马上吩咐你赶快跟进。

显然，警告式的描述更能影响领导的决策。忠告不如警告，以损失为导向的沟通，效果更强。

此外，由于沟通双方角度的不同，还可能产生矛盾，那就是在变更提出者与拒绝变更者之间，因为参照点不同而产生矛盾。

变更提出者的参照点是如果不变更，自己会受到损失，所以他倾向选择风险较大的方式；而变更拒绝者的参照点则是，变更可能对他的既得利益造成损失，所以避免风险会选择不变更。

如何化解矛盾？

可以利用框架效应重述问题，如：“如果不进行变更，我们可以在规定时间内完成xxx；如果进行变更，我们有很大概率不能按时完成xxx。不如让我们先把已经确定的可以实现的功能实现了，之后再来尝试增加新的功能吧。”

如此，双方的意愿都照顾了，变更被允许发生，但需要确保当前的任务可实现。

核心观点来自《极简项目管理》