利用WBS，我们可以更清晰地定义项目范围。然而，在项目的实施过程中，范围仍然极有可能会发生变化，一成不变的项目范围是很少见的。
变更是客观存在的
组织倾向于以二选一的方式做出目标选择。我们要么保证质量，要么按时完成工作，但不能同时做到这两点。这种方式有时会让人们把客户看成敌人，在客观上制造了双方的对立。
有一次，我在浦东国际机场搭了一辆出租车，要去黄楼镇的一家宾馆。他一边启动，一边大声说：“其他出租车都去市区，我得去那种地方。”
我对他说：“如果你不去那儿，让我下车，我换另一辆车。”
他说：“不行，太晚了。”他的意思是，他已经失去原先排队的位子，如果从头排队，会失去更多。
当时我很生气。最后我告诉他：“你可能忘了是谁付给你工资。你的客人不是你的敌人，如是你不想载我到那个地方，就应该在车窗上挂一个‘仅去市区’的标志。”
这位司机没有再说什么，但我知道他只是想着利益。假如去市区，他很可能会从宾馆拉上一位客户，返回机场。带我到郊外，意味着他可能不得不空车返回机场，这样就损失了钱。
我理解他的不满，但他难为我，难为客户，这是不对的。
正如项目使命所言，项目团队必须明白项目存在的根本原因，那就是满足干系人需求。忘记这一点，肯定会全盘皆输。商业的主要动机是获取利润，但它的使命必须是干系人满意。这两者并不是二选一的，必须同时达到。项目团队也必须这样做。
项目经理和项目小组必须意识到范围变化本身并没有什么不对，也就是说在项目进行过程中修改范围并不是个坏主意。事实上，在很多时候，这也是一件好事。首先，客户通常都不能确定其所希望的解决方案具有何种功能和特性。其次，就算客户十分清楚终极目标，商业环境也随着时间不断变化，因此项目的需求也会发生变化。
避免变更处于“非管理状态”
项目一旦开始，就到了必须进行范围变化管理的时候。因为客户会不断要求你完成超出原来范围的工作，或者和原来范围不同的工作。如果你不善于范围控制，你就要完成原先预定范围以外的工作，还要花上更多预算。换句话说，你将面临很大的麻烦。
范围变更是导致项目失败的主要原因。项目经理们都经历过不太成功的项目。切记：“糟糕的范围控制是项目管理第一大失误。”
发生范围变更不是问题，问题是许多变更处于“非管理状态”。变更请求的形式多种多样：清晰的或微妙的，内部的或外部的，操作上的、管理上的或者技术限制性上的，等等。
在变更时，需要界定以下几个问题：范围变化发生时要确定项目经理能做什么，以及不能做什么；规定一个大家都同意的办法，以便评估变化对项目基准的影响；说明为何批准或者不批准变化所需的时间、工作量、经费。尤其重要的是， CCB需要加强以下工作：评审变更会引起哪些连锁的变更，以及如何对这些变更进行管理；变更效果达到后要不要更改管理标准等。
为规范化项目变更管理，需要制订明确的变更管理程序，其主要内容是识别并管理项目内外引起超出或缩小项目范围的所有因素。它包括三个主要过程。
• 对引起工作范围变更的因素进行识别；
• 确认是否确实需要发生变更，并施加影响以保证变更是有益的；
• 管理那些实际发生的变更。
此外，范围变更会影响整个项目计划编制阶段的各种文件，要对诸如WBS和项目进度等的文件重新评价、更新，考虑范围变更所带来的影响。项目经理应将范围变更的有关内容及时同干系人沟通清楚，项目组成员需要理解范围变更对他们在项目中的角色所带来的影响，其他干系人需要得到范围变更后的最新信息。
项目生命周期中变更控制
我们知道，在通用的生命周期结构中（图1-1）：
• 干系人的影响力、项目的风险与不确定性在项目开始时影响力最大，并在项目的整个生命周期中随时间推移而递减；
• 在不显著影响成本的前提下，改变项目产品最终特性的能力在项目开始时影响力最大，并随项目进展而减弱。
图1-1表明，变更和纠正错误的代价在项目接近完成时通常会显著增高。因此，站在项目实施方（乙方）来说，在项目生命周期中变更处理的原则是：
• 项目早期的变更，原则上倾向于接受（我称之为“让怎么干就怎么干”），当然必须遵守变更控制程序。
• 项目中期，要通过分析变更的影响，原则上尽可能与干系人沟通取消变更（我称之为“要变更先谈谈”）。
• 项目后期，变更代价太大，原则上尽可能不变更：遇到大的变更时可以考虑启动一个新的项目，遇到小的变更也要到售后服务时再做。当务之急，必须获得验收，收尾项目。（我称之为“生米已成熟饭”——吃，是这盘菜；不吃，还是这盘菜！）
看来，站在实施方（乙方）的角度：项目过程就是“绑架客户上咱们贼船的过程”。当然，如果站在委托方（甲方）的角度：项目过程就是“逐步移交主动权的过程”。
消减范围还是降低质量的选择
师父问：“如果你要烧壶开水，生火到一半时发现柴不够，你该怎么办？”有的弟子说赶快去找，有的说去借，有的说去买，有人说烧成怎样就怎样。师父说：“为什么不把壶里的水倒掉一些呢，有舍才有得。”
当项目资源（费用）不足时，消减范围而不是降低质量。
请注意，对项目范围的不满是暂时的，糟糕质量的影响将是持久的。
变更管理“九阴真经”
这是某世界500强公司对项目经理面试的题目：“依据客户要求正在定制研发的一款手机已经进行到了一半，突然客户觉得应该增加一项新功能（理由是市面上的手机已经提供这种功能），但客户不想增加任何成本，请问该如何解决这个问题？”
这是项目过程中的典型情况——变更！
关于变更控制过程，如图1-2所示，我将其命名为变更管理的“九阴真经”。
第一步，当客户提出变更时，首先要评估信息的准确性，确认项目变更事实
一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命——为了节省项目的时间而走愚蠢的捷径是会付出巨大代价的。切记，定义问题比解决问题难。
第二步，提供变更申请的书面记录
原则上讲，谁提出变更就应由谁提供书面申请。不得不面对的一个现实是，在一个不成熟的商业环境中，我们的客户一般都位于相对强势的位置——不愿意甚至不提供书面申请！怎么办？既然客户不愿意提供，那么我们来写好了。当我们完成了书面文件以后，呈给客户：“领导，这是根据我理解的您的意思所起草的文件，请审阅。如果我的理解是正确的，就请您给我确认一下；如果我的理解有问题，请您批评指正，然后我修改后再给您汇报。”
一般而言，当我们这样跟客户沟通时，客户会认可并确认的，因为客户也想把项目做好。
有没有客户会“打死也不确认（签字）”？对于这个问题，我不敢说就一定没有；只能说，在我本人从事项目工作的20年中还没有遇到。
第三步，分析变更对范围、进度、成本、质量等诸方面的影响
项目的十大知识领域之间是一个相互联系的系统。一个方面的改变，会对至少一个项目目标造成影响。所以，需要分析变更对范围、进度、成本、质量等诸方面的影响。
第四步，与相关干系人沟通变更影响，确认是否取消变更
对项目问题讨论和探索过程中，谁先找到最好的结论并不重要，重要的是寻找最佳结论的过程。如果你能给那些试图说服你的人一个信号，表明在这个探索过程中你是他们的伙伴，这个探索过程对双方都有益，也许他们就会把你的批判性问题看作是对双方都不可缺少的工具。
对于这个面试题，我们可以尝试采用如下沟通策略。
“如果增加这个新功能，原来10个月的研发时间，需要再增加10个月。”
“没问题，延长10个月我们认可。”
“研发时间只是一方面。麻烦的是，原来100万元的费用不够了！需要再增加100万元。”
“可以的，增加预算100万元。”
“费用还不是最关键的——您知道的，手机是电子器件组成的系统。增加新功能，需要引入新的器件，系统的电磁兼容性问题需要验证，恐怕会导致系统整体性能和质量的恶化。”
“质量恶化，我们可以接受。”
“更麻烦的是，这种新功能我们的团队没有做过，也没有这个能力。因此，需要寻找新的研发人员。”
“哦！”
“国内没有实现这种新功能的器件。根据调研，只有美国有；更麻烦的是，美国对这种器件是禁运的！”
“这个……”
“即便是能拿到这种器件，毕竟是第一次研制，风险是存在的——也不能保证能成功。”
……
假如，真这样沟通，结果会怎样？不出意外，客户会说“还是不要做了吧！”
第五步，针对变更请求，提出相应解决方案
项目范围变更很可能需要额外项目资金、额外的资源与时间，因此，应建立包括来自不同领域的项目干系人在内的变更控制委员会，以批准或否决变更。这个委员会应当由具有代表性的人员组成，而且有能力在管理上作出承诺。
索取企业OKR和绩效管理成功案例，直观体验《Tita一体化管理平台》，立即申请 《Tita 产品演示》 或 最受客户欢迎的《帮我配置考核表》 。
2024, Tita 重磅发布新品，开启“客户管理”与“项目交付”双引擎，帮助企业驱动业绩飙升！立即了解 《Tita 新CRM销售管理一体化》 。
