客户的需求过度蔓延，项目经理怎么控制项目范围？

（一）项目管理中如何更好的控制客户的需求？

   做项目管理经常会遇到这样的场景：公司的销售人员兴冲冲的拿来一份与客户签订的合同交给你，声称这项目已经搞定了，但是当你拿过来合同(或者任务委托书)一看，关于需求，项目范围的说明只有寥寥数行，要么是一些高举高打的套话，要么只说项目都包含什么样的模块，而对具体的业务只是一两句话就完事儿了，如果是一位身经百战的管理者并且对于项目的具体业务很熟悉还可以，如果不是那该如何开始这个项目呢？还有一种情况，客户在项目进程中，不断对阶段交付的系统提出各种修改意见，更令人气愤的是，有些问题开始提出更改，也有个能进行反复的更改，但是某一天客户突然就发现情况不对，又要求你给改回来，看起来客户的需求总是无穷无尽，作为项目的管理者该如何应对这种令人沮丧的局面呢？

（二）案例：客户的要求超出了项目范围怎么办？

　　我们公司是一个本地的软件公司，我担任一个项目中的项目经理职位。
　　之前我们接手了客户的一个单子，本来在初的期需求分析和前期的功能要求上上已经达到了客户的基本要求。在中期的时候我们也是实时进行客户的需求跟踪，已经把沟通做到最大化了。
　　但是在我的项目在验收阶段时，最近客户不断提出一些新的要求，有些明显超出项目范围，而且有些要去根本就不在项目任务书里面。
　　一时间，我们也乱了，因为我也是刚刚上任不久，对某些管理知识理解的不深刻，
　　1.客户的要求超出了项目范围，如何与客户沟通?
　　2.如何控制项目范围?
　　3.如何控制项目成本?
　　当然这些是维持与客户之间的良好合作关系的前提下。
　　在此谢过!

分析：在做项目的过程中，乙方受到甲方“盘剥”的可能性还是很大的，作为项目经理还是要做好让步一点的准备，但是前提是你一定要梳理好变更的性质。1. 如果是在项目初期，返工的成本比较小，所以变更还是欢迎的；2. 如果是在项目中后期，返工的成本会很大，这时，一定要梳理好变更本身的影响，包括时间影响、费用影响。列清楚后与甲方开诚布公地讲清楚，让他们自己考虑变更是否要继续。当然，也不能指望甲方知难而退，胡搅蛮缠的甲方也是很多的，如果沟通不下来，作为项目经理可以寻求自己公司的支持。以上，适当让步可以，把我往死里整，就得把球抛给自己公司了。

分析： 我虽然是做机械行业项目的，但是可以告诉你项目验收的环节必然面临着一次最后的交换；即客户以某些条件来交换他给你验收； 碰到这个问题，首先要搞清楚你们公司的常规验收是不是允许这么做，如果不允许，ok，动用你的项目经理权限，对项目组下达暂停任何服务的通知，让甲方有问题时只能找你，你就获得了一定的控制权； 如果允许，ok，搞清楚客户的要求，进行分析，投入的成本要求是多少，一般来讲并不需要都答应，部分满足即可；不能做的可以和客户讲清楚，一般客户还是懂道理的； 还告诉你另一个小技巧；一般来说超出合同范围外的条件要达成，需要你项目经理动用公司资源去完成，而这个资源的批准是领导决定的，为了推动领导同意，你不妨和客户沟通，先验收；要客户在验收单上写明条件，你在拿着这个验收单去找领导，请求领导资源支持；当然这是在你们公司允许这种模式的条件下。

分析：对当前案例处理的建议：1.处理前提：客户是重要的干系人，在得到老板批准的前提下，尽量让其满意；2.列举客户的要求，内部讨论其可行性之后，再与客户就变更事项一一讨论，对于可以执行的变更，可以承诺接受，但是提交新增的cost让客户承担，并提交交期影响，由其决定是否接受；对于不可以执行的变更，建议加到下一个版本/产品里面；3.新增的变更（应该不会太多，毕竟本来已经接近收尾了），交给成员执行，并及时与客户反馈效果及进度。对于后续与该客户的处理建议：1.在项目初始阶段，与客户商谈好项目范围，并且写入项目范围说明书；2.在各个阶段，积极与客户联系，听取客户的意见；防止客户对项目跟进不清楚，有突如其来的感觉，更防止出现后期突然增加项目。3.如果出现变更，先交给变更控制委员会讨论是否可以接受。并且随着项目进展，尽量少接受变更。因为一旦有变更，就会产生新的成本。

分析：1.分析需求是否合理，是不是影响主要功能的使用，成本是多少进行评估，如果可以，在保证客户满意度的情况下进行添加2.若花费时间/人员成本太高，与客户进行友好沟通，并拿出《项目范围》合同进行说明，以及明确告知客户所需要花费的时间成本，如用户执意要加，则列入合同列为新增需求3.为防止以后出现这种情况，在前期规划《项目范围书》的时候就将所有项目范围表述清楚 。

分析：1、尽量满足客户的需求，若超过预算，需要与客户沟通，各自商量出个解决方案。2、 需要把这件事与上级反馈，自己代表的是公司利益。同时把自己的想法，反馈到上级那。3、 冷静，思考，不能慌。 

（三）客户需求为何过渡蔓延

　　作为项目的管理着，在规定时间用有限的资源来保质保量的完成项目，让公司和最终客户都满意是项目组的神圣职责。但是为了让客户满意就要满足客户所有的需求吗？因为不断满足客户的需求会不会导致项目失败怎么办呢？为了弄清楚这些原因，首先应该找到这些问题发生的根源。

　　1.签订合同的时候，项目范围描述不清楚。这是最常见的问题之一，也正是早期的这些问题没有引起项目组的足够重视，导致后期项目无穷无尽的修改。

　　2.客户和项目组对写成纸面文件的需求理解不一致。这种情况也较常见，虽然客户已经确认了项目组提交的项目范围说明书，项目组也是完全按照这个文件规定的内容做的，但是客户还要求改，当项目组拿着纸面的文件与客户对质的时候，才发现客户也认可这需求，但是同一件事情，客户的认知和项目组的认知完全不同。举个简单的例子：客户要求系统能够电子签名，项目组的成员就模拟了一个，自动产生客户的签名在系统中，但是当移交给客户的时候才发现，客户要求的电子签名实际上是想把原来手写签名的工作也移植到电子化的系统中，让领导能够通过画图的方式产生一个手写的签名在文档中应该落签字的地方！有时候就是当初一点点疏忽，导致项目后期大量修改甚至项目延期。

　　3.客户总有在结项之前把每一件事情都做得淋漓尽致的初衷。一般来讲，在项目结项之前，客户都会把所有的想法尽量逼着项目组解决，因为一般的客户心理都会认为：一旦结项了，再想找项目组成员对业务系统进行修改可就难了，因为IT公司人员流动性强的特点，即便以后能够找到承包商，当初做项目的项目组成员也不一定在了，或者很多公司因为业务繁忙，已经顾不得原来已经结款的客户了。

　　4.项目组人员总是无条件迁就客户，客户有求必应。这种做法的出发点是好的，目的是要客户完全满意，但是实际上这种做法不一定能达到目的。一般的客户需求都是无底洞，这样做对整个项目经常也会带来很多负面影响。当然，如果过分控制客户的需求，客户肯定也不会满意。

（四）客户需求过渡蔓延解决办法

　　针对上述项目问题以及发生的原因，结合以前一些项目的教训经验，我感觉可以通过以下几点来有效屏蔽客户需求过渡膨胀的问题，让项目完成得更加漂亮。
    
        1、未雨绸缪

　　项目初期一定要制定清晰的目标和项目范围，并且让项目主要干系人(最重要的当然是最终客户了)确认。

　　不管通过什么途径得到的项目，作为项目主管，在项目前期，可以分三步走。

　　第一个想到的问题应该是“为什么”，也就是客户做项目有什么目的，知道这些以后，才能在以后的工作中更加想客户之所想，不至于项目方向错误，最终争取达到双赢得局面。

　　知道了“为什么”以后，接下来就要非常清晰的知道“做什么”，有一个比较好的办法就是用一两句非常简洁的话概括出来整个项目，并且能够用这种方法概括出项目中的各个子任务，并且能够让前台业务人员和后台研发人员都能够心领神会，那么说明项目主管对项目的内容在大方向上已经有很好的把握了。

　　最后就要弄明白“怎么做”了，对于比较陌生的项目来讲，这一阶段工作量比较大也很重要，在这个阶段多花点精力绝对值得，当然，根据具体的情况，也可以在这个需求调研阶段简化一些不必要的工作，这需要项目主管具备平衡那些彼此冲突的项目目标的能力。在实际的工作中，这需要一个过程，值得注意的是，在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍，在实际的操作中，这种做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大降低，还可以很好的发先潜在的问题，并且掌握一些沟通技巧，也会让客户更能深刻的感觉到承包商对他们的重视。另外，如果项目前期得需求人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通，以避免不必要的给客户的承诺，更加准确的界定工作量。总之，有效的计算出项目范围将会占用一定的时间，但是同样会节省资源、资金以及解决项目今后令人头疼的问题，例如：需求(范围)变更。

　　另外一个很值得注意的问题是：项目的需求经过几次确认以后，要让有权力的客户明确确认，最好有书面签字，这个有说服力的文件会在以后客户发生需求变更的时候起到很好的作用，很显然，因为客户已经签字确认，总是反悔肯定理亏呀，即便因为业务变化不得不对项目进行大的调整以至于项目延期，这种情况下也会是项目组处于有利地位，不至于让自己的公司非常不满，甚至可以以此为依据来要求客户重新考虑项目经费。当然，对于客户来讲，通过这些很好理解的需求的阐述，也会以此作为以后交付产品的依据，做到心里有数，消除不必要的疑虑，这个对双方有同等的约束力，很有好处。

      2、灵活应变：遇到变更要与客户沟通

　　经常有这种情况，项目都已经执行到最后阶段，客户突然提出了新的要求或者要求对已有需求进行更改，这会让项目主管非常为难：一方面要尽量满足客户的需求，另一方面又不能对系统做太大的改动，影响进度计划。这种情况发生除了和需求阶段有关以外，同时说明在实施过程中没有与客户有密切的联系，缺乏沟通。

　　从客户的心理来分析。由于软件的特殊性，客户通常非常关注后期的服务，尤其是在国内大家做的软件绝大多数都是与实际业务紧密相连的。作为项目管理者，非常忌讳的是在做项目的过程中对客户置之不理，而最后交付的时候才与客户突然发生大量接触，本来后期的实施过程出现问题的可能性最大，之前与客户又比较生疏，很可能会造成非常大的风险。比较稳妥的办法就是在项目进程中也要让项目组与客户保持联系，相互了解，建立更加融洽和谐的沟通气氛，为以后关键的实施移交阶段可能与客户发生的冲突做好准备。值得一提的是：在项目进程中阶段性的给客户呈现一下项目的进展状况，让客户对项目有一个更加直接可视化的认识，更能及早的发现解决问题免除后患，在不断的沟通过中，应该让客户认识到项目组时时站在客户角度着想，让客户的主要负责人也能深深的感觉到他们是项目组的重要组成部分、荣辱与共，并且项目组能为客户提供完善持续的后续服务，这样可以有效的避免客户绞尽脑汁想把所有的事情在第一次结项之前做完。

　　即便前期工作做得再好，很多情况下，需求变更是不可避免的。项目主管通过良好的沟通机制随时掌握变更情况和可能发生的变更，一旦发生了变更，项目组一定要冷静处理这些问题，一般可以按照产品分析—〉成本/收益分析—〉备选方案—〉专家判断这四个步骤来首先评估需求变更，并且尽快形成项目范围变更书面的说明书，它是以后项目决策的基础，当然比较稳妥地办法还是让客户对明显发生的变更做出确定(选择签字最好)，尤其是在评估了变更可能导致的工作量增加以后，让客户认识到过多的变更很显然会造成项目延期，客户对此也要负责任。 

　　在客户提出需求变更的时候，一定要掌握一定的沟通技巧，一定不要总是无条件迁就客户。一般来讲客户对IT都不太熟悉，他们认为很简单的事情，可能要花费项目组大量的无谓得多余精力，所以千万不要认为客户所说的就一定是他想得到的！大部分客户都是第一时间突然脑海里面冒出的火花，所以项目组人员要冷静的分析一下：客户到底想要实现什么目的，抓住问题得本质。一般来讲，实现客户本质的需求有很多种办法。在与客户的沟通中，一定避免与客户正面冲突。在初期认真倾听客户意见，多问一些“您还有什么想法”之类的问题，等客户把他的想法都表述清楚以后，项目组成员成员最好迅速评估一下客户的建议，如果实现起来实在太困难，可以给客户一些更加中肯的提议，多问些“您看这样行不行？其实可以达到同样的目的。”之类的问题，最后还有一个重要的过程就是要与客户确认这次沟通的结论。

       项目范围管理流程：
         
　　总之，基本上所有的项目都会遇到项目范围的问题，项目范围管理是平衡那些彼此冲突的项目目标的一种能力。看起来简单，但是实际上很复杂，项目主管在项目进程中要学会如何对常见变更进行控制，控制客户需求的肆意蔓延，保证项目健康稳定的进行。
　　1.在项目启动时，公司会批准一个新的项目阶段的开始。
　　2.在范围计划编制的过程中，将制定一份说明书来描述在项目中将做什么。
　　3.在范围定义中，项目的主要部分被分成更小的部分。
　　4.在范围审核时，需要验收项目的范围。
　　5.在范围变更控制中，随着时间的过去，需要对项目范围变更进行监督。
       
（五）总结，项目范围管理概述

项目的范围，简单来说，就是我们需要做什么、我们不需要做什么。之前有一次我们公司在跟客户为一个项目做前期谈判，中途把我叫过去开会，听了一会儿感觉大家说的好像不是一回事，于是就问客户这个项目的范围能不能再澄清一下，客户是瑞士人，我记得很清楚，他回答说“good question, scope is everything”。
　　的确，范围是一切的基础，作为项目经理，不管你是制定进度计划，还是制定预算，或者后续的监控，都是建立在范围的基础之上的。
那么，范围管理的核心是什么呢?
简单来说，就是“No More, No Less”，不多也不少，也就是100%原则!范围少了，客户不同意也不会满意，直接影响到项目的验收和交付，所以要去不断的核实范围，做到范围100%的实现了，不要做99%，后面我会用苹果公司的一个案例来说明99%的后果。
　　在实际做项目的过程中，客户经常会提出超出原始范围的一些要求，也就是一些范围变更，虽然客户是上帝，但我建议一定要按照正式的变更流程去做决定，不要认为是很小变更就答应客户了。
你多做了，客户可能当时满意，可是你知道额外的范围意味着额外的风险吗?比如说，你的项目是给客户修一段公路，客户见你的工地有挖掘机，就让你顺便在工地不远处挖个坑掩埋垃圾，看似是个小活，可是你没有那个区域的地下施工图纸，结果不幸的是你的挖掘机一铲下去把地下燃气管道给挖泄露了，这个责任你能承担吗?
所以，对待额外的范围一定要小心，即使是为了客户关系可能不得不做，也要按照正式的变更流程去评估风险、成本等，不要随便去做那101%的工作。
　　下面用两个比较经典的案例分析一下范围管理的100%原则：
　　1、完成了99%，少了1%
　　大家都知道，iPhone手机给苹果公司带来了巨大的成功，可以说让其他手机制造商只能去模仿而无法去超越。但是，有些人可能不知道，在研发第一代iPhone时，苹果公司竟然出现了可能是消费电子市场上最尴尬的一个失误：其已经投入生产的iPhone手机没有电话功能!iPhone这款最酷最炫的手机，或者已经不能称为手机，叫做最酷的手持计算设备可能更贴切一些，竟然不能打电话，着实给期待它的全球消费者开了一个大大的玩笑!
　　2007年初，苹果公司宣布召回所有正在生产的iPhone手机，因为它发现这款大肆炒作的便携设备竟然漏掉了“电话”功能!苹果公司创始人史蒂夫乔布斯在公司总部为这个荒唐的失误发表了致歉词，脸色通红的乔布斯在与华尔街分析师召开的电话会议上说：“首先，我们表示十分的歉意。 因为我们在iPhone这款产品中漏掉了电话功能。” 他解释说，苹果的设计工程师们一直在琢磨那些与电话无关的功能，比如照相机、MP3播放器、跟踪天线系统以及其他高级功能等。
虽然乔布斯表示首批已经运送到全球各地的零售店的九百万台iPhones手机大部分已经“打道回府”，重新运回苹果的生产厂，但是他还是建议那些通过某种方式已经拿到iPhone手机的消费者“拿起iPhone手机然后放在耳边，假装在打电话。”现在iPhone手机已风靡全球，再听到上面这个故事可能都无法相信，但，这是真的!
2、多做了1%
想必大家都很熟悉一个成语故事：画蛇添足。
　　这个故事形象的告诉我们，多做了那1%，客户很生气，后果很严重!
　　我想所有的项目经理都曾遇到过客户要求增加范围的情况，而其中有些我们肯定在没增加项目预算的情况下执行了客户的要求。正如之前所说的，可能单纯执行客户的那额外1%的要求不会增加多少成本，
但是你评估过这1%带来的潜在风险吗?另外有些情况是，开始你觉得这额外的1%不会增加多少成本，于是答应了客户，可等你做着做着就会发现，它竟然是个无底洞，甚至影响到了项目原始范围的交付!

所以，范围无小事，谨慎的对待一切范围变更，坚持“不多也不少的100%原则”，经常去核实范围、控制范围，项目才会成功。在研发这款革命性的手机产品时，项目团队可能太过于关注那么令人激动的额外功能，却把最基本的通话功能给遗漏了，毫无疑问的是，这个项目团队在制定项目范围时绝对的忽略了这1%的功能，我想他们肯定在研发中不断的核实项目范围，却从未发现，甚至在投产的产品测试时也没有把这1%加到试验计划中，最终导致在量产时才尴尬的发现了这个致命疏忽!