让变化成为计划的一部分。

这是九十年代IBM的一句广告词。自从接触了项目管理之后，是深有体会其意境。项目经理对于项目中的范围变更，就需要抱有变更是项目的一部分的态度。正面拥抱他，不害怕，不躲避，积极面对。

《一》项目的变更是不可避免的

对于一个项目而言，从立项到最后收尾，短的2-3个月，长的可能2-3 年。这时间短里，或大或小都会经历到项目变更，不变的项目目标，万变的项目需求。为什么会这样呢？

1. 前期讨论没有说清楚

项目开始初期，双方会有多次的需求讨论，怎样确保说出来的和听到的是同一个意思，也就是双方理解完全一致是重中之重。而就现实来讲，多少会有偏差。这种偏差可能是遗漏，可能是表述的不恰当，也可能是理解的不正确。而随着项目的深入，慢慢的这些偏差就会显现。如果发现及时，对项目造成的影响就会以及控制，如果发现的晚，后果不可想象。

2. 前期没有想清楚

因为大家的信息不均等，带有局限性，于是造成了设计的时候觉得没有问题，实施的时候发现有许多的点没有考虑到的情况。正所谓每一个项目都有其独特性，而大多数人都是带着之前项目的经验进行设计，这些经验可以规避80%的问题，但是还有20%是要具体问题具体分析的。而这20%在项目初期的确很难想清楚，需要在项目实施的过程中逐步明确。

3. 外在因素没法控制

正如前文提到的，有些项目的工期长达几年，在这几年时间里，外部环境的变化，投资人想法的变化都会对项目范围造成影响。而如今，跳槽，人员变动更是如同家常便饭，关键干系人的变更对于项目影响也是比比皆是。客户换了新领导，是否对于项目的期望会发生变化，是否依旧重视该项目，是否仍旧会资助项目？都有可能左右一个项目的命运。

《二》项目变更对于项目的影响有哪些？

既然变更无可避免，那么我们就好好拥抱变更吧。不妨从以下几点分析变更对于项目的影响：

1. 项目范围—— 变更对于项目而言，是增加了范围还是减少了范围。

2. 项目工时—— 对于该变更，项目团队需要增加工作量还是减少工作量。进而对于项目预算的影响是增加还是减少。

3. 项目进度—— 变更是否对于现有关键路径有影响，是否会产生新的关键路径。最终对于交付日期会有什么影响？ 提前交付或延迟交付

4. 对于甲乙双方的影响—— 项目经理会本能的考虑变更对于本方团队的影响，在此不妨思考下为什么甲方会需要这个变更，从而找到变更的根本目的。从而便于之后站在双方立场上考虑问题，寻求解决方案。

5. 项目外再看看—— 一般对于变更，考虑的仅仅是当前项目。在此不妨跳出当前项目，从整体找找影响。对于甲方而言，系统也好产品也罢，看问题做计划的角度不仅仅局限于单个项目。而是需要从整体系统，或者是产品线的角度出发。同样乙方也不能仅仅局限于当前项目的得失，而是需要从长远考虑。尤其是项目集群管理的角度。如何以逸待劳，通过适当增加当前项目的成本，从而达到整体战略上的共赢。

《三》沟通的目的是双赢

当遇到项目变更时，项目经理应该怎么办？

1. 正确认识该变更，对于项目的利弊，对于本方项目集群的利弊，以及对于客户产品的利弊。

2. 积极面对，正面沟通，达到双赢乃至三赢的效果

第一点，前文已经提及，在此不再多做评述。

第二点，在此会详细展开。

真正项目实施的时候，遇到变更的情况很常见，而对于变更，很多项目经理是抱着反感的态度的。因为很多情况是没说清楚造成的认知不统一，也就是上文的第一点，没说清楚。亦或者是第三点，外在因素的变化。对于项目经理而言其实没有做错什么。于是会有羞于开口的局面。从而产生逃避的想法。

这种态度是万万不可的。任何时候的变更标明了分歧，而放任分歧不管对于项目是毁灭性的打击。

所以对于项目变更而言，不可回避，要积极面对，多沟通多商议。寻求共赢或者三赢的局面。

现代项目管理不仅仅是甲乙双方，单就乙方而言可能因为组织架构的关系，会有集群管理，于是就是三方。

当发生分歧时，项目经理应当先同自己上级沟通，寻找双方的共同点达到利益一致。

然后在同客户方进行沟通，探寻双方的共同点，从而达到利益一致。

所以在沟通环节上，项目经理需要一些谈判技巧，将看似矛盾的双方利益转化为共赢。

这里举一个例子。

小王所在的公司是专门提供仓储系统实施的公司。小王是仓储系统实施的项目经理。手上的项目是为某客户在亚太区10个仓库进行仓储系统的功能升级。项目范围是就客户指定的要求提供相关系统功能，部署到客户每个仓库系统中。项目工期为3个月。

开始对于功能的开发相对顺利。而随着项目的进行，小王发现了问题，由于系统都需要在客户仓库里安装升级，而客户仓库分布在亚太各个国家和地区。如果是有开发人员去现场安装，光是申请签证都来不及。而如果是将升级的动作做成脚本自动升级，会增加开发工期以及成本。

而客户的负责人小李觉得这些应该是有小王团队提供的。是在这个项目范围内的，不应该由自己团队来进行。也不应该有额外的费用来支持小王团队制作自动升级这个功能。

这是一个典型的没讲清楚的例子。项目经理没有在项目初期完全识别出潜在任务，而这些任务客户方想当然的觉得已经包括在项目范围内。双方对于项目范围的认识不一样。而暴露出这点的时间点已经在项目进行了大半的前提下。这个时候，如果你是小王你该怎么做？

是放之任之，到最后爆发出来的打官司吗？显然这是不可取的。这是一种双输的不负责任的方式。

是将制作自动升级的这个功能提出来，并要求客户支付响应的款项吗？可以一试，但是正如客户小李的观点，这些应该属于原来项目范围之内，所以这样做很有可能，小李会要求这个功能但是不支付费用。这对于小王团队是输，对于小李是赢。而考虑到这总做法对于项目是要延期的，所以是双输的局面。

那么该怎么办呢？

小王公司是项目集群管理的，他的项目需要自动升级功能，说明公司其他项目也需要这样的功能。于是小王找到自己的上司小赵，更他谈了自己项目的问题，以及制作自动升级功能的对策。同时对于项目需要额外预算也做了解释。

小赵考虑到自动升级这个功能对于公司整体是有所帮助的，表示愿意提供相关自己帮助小王制作该功能。

注意此处小王能够跳出自己项目，从公司整体集群管理的角度出发思考从而找到了自己项目和公司整体项目共赢的方式，顺利解决了新增功能资金的问题。

接下来，小王代表乙方向小李表示，原计划如果是人工安装，需要的时间会很长。耗时又费力。现在愿意提供这个自动升级的功能，能够帮助缩短升级所需要的时间。具体方案为前两个仓库又小王团队带着小李团队人员一同在现场操作自动升级，后续8个仓库由小李团队自行完成。

对于小李而言，项目预算没有增加，又可以按原定计划完成项目，自然接受。

而对于小王而言，从原先的识别出没有估计到的任务，项目必定延迟，项目超预算的局面。到项目按时完成，预算也没有超。可谓是顺利化解了项目风险。

对于小赵，虽然有一笔额外支出，但是对于整个公司的项目集群，是一劳永逸的事情，从此多了一个模块。也可谓是钱花的使得其所。

经过小王及时有效的沟通和谈判，项目从怎么都是双输到三赢。

《四》沟通的基本 —— 范围说明书

还记得之前几篇的成果物里边有一个叫做《范围说明书》的成果物吗？千万别小瞧了他。他是项目经理拿来沟通的基础。

范围说明书，规定了项目的范围，项目的工作分解结构，项目估算的假设和不属于项目范围的功能。清晰的项目范围说明书可以有效帮助甲乙双方认知项目范围。减少分歧。

而任何项目变更或者是变更引起的谈判，都需要基于这个文件进行，不然都是泛泛而谈。

好了最后对于本文要点，做一个总结：

1. 项目初期对于范围说明书需要清洗严格的定义。

2. 要积极面对项目变更，不可回避或者逃避。要通过有效的沟通谈判及早解决分歧。尽早合理控制客户期望，切不可放之任之，最后让客户希望破灭。

3. 努力寻找共赢的方法。寻找双方的共同利益。

4. 拥抱变更，害怕变更项项目经理不是好经理。