《信息系统集成项目中如何控制客户需求.doc》由会员分享，可在线阅读，更多相关《信息系统集成项目中如何控制客户需求.doc（7页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、信息系统集成项目中如何控制客户需求【摘要】信息系统集成项目中，项目经理经常会面临这样的情况：拿过来合同(或者任务委托书)里关于项目范围的说明只有寥寥数行，只有一些套话，简单地说明项目都包含什么样的模块，而没有具体的业务描述。客户在项目进程中，不断对移交的系统提出修改意见，有些问题开始提出更改，某一天客户突然就发现情况不对，又要求你给改回来。为了避免这种情况的发生，项目经理需要使用项目范围管理的手段对客户需求的肆意膨胀进行有效的控制。【关键字】信息系统集成 范围管理 客户需求一、两个案例案例一 某公司的市场销售人员为了争取某银行的呼叫中心项目，答应可以满足用户（银行）的一切需求，在没有对项目的范
2、围进行确定的情况下，就与用户签订了合同。并且在合同中用户（银行）要求该公司提交的呼叫中心系统要随着银行系统业务的改变而改变。在项目启动后，由于对项目的范围没有确定，导致项目的需求总是在变化，项目周期一再延期，用户也不满意，公司项目小组也很累，成本也很难控制！案例二 笔者公司一卡通项目组在接手一个项目前，由市场人员和相关技术人员共同与用户的相关人员进行了业务与技术方面的详细研究，与客户在业务需求方面达成一致，明确了客户做项目的目的，最后生成项目范围说明书，并由客户签字确认。在客户需求变更时与客户有效沟通，既保证可项目进度计划，又满足了客户需求。 从上面的两个案例可以看出，在项目管理中，是否实行项
3、目范围管理、能否有效的控制客户需求，对于项目的成功与否具有举足轻重的作用。下面就从项目范围管理角度具体阐述在信息系统集成项目中如何有效控制客户需求的过度膨胀。二、为什么客户需求会肆意膨胀首先我们来分析一下案例一，从案例描述中可以肯定的得出结论：项目周期一再延期的原因是由于客户需求的过度膨胀，导致了客户需求的过度膨胀的原因是什么？我们知道对于项目经理及项目组所有成员来说，在规定时间用有限的资源来保质保量的完成项目，并让最终客户满意是项目组的神圣职责。但是为了让客户满意就要满足客户所有的需求吗？因为不断满足客户的需求会不会导致项目失败怎么办呢？为了弄清楚这些原因，首先应该找到这些问题发生的根源。1
4、.项目范围描述不清楚。案例一给出的描述是：为了争取项目，“答应可以满足用户（银行）的一切需求，在没有对项目的范围进行确定的情况下，就与用户签订了合同。并且在合同中用户（银行）要求该公司提交的呼叫中心系统要随着银行系统业务的改变而改变”。显然，案例一的问题在于签订合约时对项目范围描述不清楚。这也是最常见的问题之一，正是早期的这些问题没有引起项目组的足够重视，导致后期项目无穷无尽的修改。想想看，“随着银行系统业务的改变而改变”这样的合同条款在项目管理中可以视为死亡合约，它会使整个项目组深陷一个不见底的泥潭之中。2.客户和项目组对需求理解不一致。 这种情况体现在客户已经确认了项目组提交的项目范围说明
5、书，项目组也是完全按照这个文件规定的内容做的，但是客户还要求改，当项目组拿着纸面的文件与客户对质的时候，才发现客户也认可这需求，但是同样一件事情，客户的认知和项目组的理解完全不同。举个笔者亲身经历的的例子：笔者的某个客户要求笔者开发一台新的消费系统来取代不能满足需要的另外一家公司的旧系统，客户要求员工在旧系统中使用的消费卡余额可以退款，然后加入到新的消费系统卡，我们当时的考虑的解决方案是是在旧系统退卡，然后新系统发卡时将旧系统的卡片余额加入到新系统的消费卡中。但是当移交给客户的时候才发现，客户的想法是：不能在旧系统中退还卡上余额，而是采用在新系统中自动转账的形式进行新卡对旧卡的替换。可见，有时
6、候就是当初一点点疏忽，导致项目后期大量修改甚至项目延期。3.客户总是希望在项目结束时满足自己所有的关于该项目的设想。一般来讲，在项目结项之前，客户都会把所有的想法尽量逼着项目组解决，因为一般的客户心理都会认为：一旦结项了，再想找项目组成员对业务系统进行修改可就难了，因为IT公司人员流动性强的特点，即便以后能够找到承包商，当初做项目的项目组成员也不一定在了，或者很多公司因为业务繁忙，已经顾不得原来已经结款的客户了。4.项目组人员总是无条件迁就客户，对客户有求必应。这种做法的出发点是好的，目的是要客户完全满意，但是实际上这种做法不一定能达到目的。而且客户有时考虑问题不够周到，有些问题开始提出更改，
7、某一天客户突然就发现情况不对，又要求你给改回来，如果项目组人员无条件的答应了这种要求，影响项目进展是必然的结果。三、如何避免客户需求的肆意膨胀案例二成功的地方在于：市场人员和相关技术人员共同与用户的相关人员进行了业务与技术方面的详细研究，与客户在业务需求方面达成一致，明确了客户做项目的目的，最后生成项目范围说明书，并由客户签字确认。在客户需求变更时与客户有效沟通。既然已经分析出了项目问题以及发生的原因，根据前面成功的案例二，并结合以前一些项目的教训经验，现在来谈谈有效屏蔽客户需求过渡膨胀的方法。1制定项目基准和项目范围 项目管理知识体系指南中关于项目范围管理的描述是：项目范围管理是确保项目包括
8、成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。它主要关心的是确定与控制哪些工作应该包括在项目之内，哪些工作不应该包括在项目之内。范围定义是制定详细的项目范围说明书，作为将来项目决策的根据。项目范围说明书详细地说明了项目的可交付成果和为提交这些可交付成果而必须开展的工作。项目范围说明书还是所有项目利害关系者对项目范围的共同理解，说明了项目的主要目标。项目范围说明书还使项目团队能够实施更详细的规划，在执行过程中指导项目团队的工作，并构成了评价变更请求或增加的工作是否超出了项目边界的基准。基于项目管理知识体系指南中关于项目范围管理的描述，可以肯定的是在项目初期一定要制定清晰的目标和
9、项目范围，生成项目范围说明书，并且让项目主要干系人(最重要的当然是最终客户了)确认。不管通过什么途径得到的项目，作为项目主管，在项目前期，可以分三步走。第一步，想到的问题应该是“为什么”，也就是客户做项目的目的，知道这些以后，才能在以后的工作中更加想客户之所想，不至于项目方向错误，最终争取达到双赢得局面。第二步，知道了“为什么”以后，接下来就要非常清晰的知道“做什么”，有一个比较好的办法就是用一两句非常简洁的话概括出来整个项目，能够用这种方法概括出项目中的各个子任务，并且能够让前台业务人员和后台研发人员都能够心领神会，那么说明项目主管对项目的内容在大方向上已经有很好的把握了。第三步，要弄明白“
10、怎么做”，对于比较陌生的项目来讲，这一阶段工作量比较大也很重要，在这个阶段多花点精力绝对值得，当然，根据具体的情况，也可以在这个需求调研阶段简化一些不必要的工作，这需要项目主管具备平衡那些彼此冲突的项目目标的能力。在实际的工作中，这需要一个过程，值得注意的是，在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍，在实际的操作中，这种做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大降低，还可以很好的发现潜在的问题，并且掌握一些沟通技巧，也会让客户更能深刻的感觉到承包商对他们的重视。另外，如果项目前期的需求人员对技术非常不了解，根据实际情况最好在需求每次提交
11、给客户前与研发人员沟通，以避免不必要的给客户的承诺，更加准确的界定工作量。总之，有效的计算出项目范围将会占用一定的时间，但是同样会节省资源、资金以及解决项目今后令人头疼的问题，例如：需求(范围)变更。2. 变更控制委员会控制需求变更最理想的办法是由客户方、开发方的项目经理和需求顾问共同组织变更控制委员会，文档化所有需求变更，双方签字然后归档需求变更。如果这样比较难以实现，那么最起码的要求是，必须由客户方项目经理（也就是甲方最终用户需要把需求变更汇总报告给甲方项目经理）向开发方项目经理提出需求变更，开发方项目经理评估工作量，并文档化需求变更，在与客户方负责人充分沟通后，使用正式方式将沟通结果（最
12、好是打印出来给甲方签字，最起码是要求回执的电子邮件）通知客户。必要的时候需要业务人员协助，比如要求签署附加合同或者新开一个项目等等。3客户签字确认 一个很值得注意的问题是，项目的需求经过几次确认以后，要让有权力的客户明确确认，而且要有书面签字，这个有说服力的文件会在以后客户发生需求变更的时候起到很好的作用，很显然，因为客户已经签字确认，总是反悔肯定理亏，即便因为业务变化不得不对项目进行大的调整以至于项目延期，这种情况下也会是项目组处于有利地位，不至于让自己的公司非常不满，甚至可以以此为依据来要求客户重新考虑项目经费。当然，对于客户来讲，通过这些很好理解的需求的阐述，也会以此作为以后交付产品的依
13、据，做到心里有数，消除不必要的疑虑，这个对双方有同等的约束力，很有好处。例如：本文案例二的项目，在与客户详细讨论了业务需求后，对方的主管领导进行了签字确认，后来对方的技术人员因为其个人原因要改变业务需求，我们就把经过他们领导签字的业务需求拿出来给他看了，让他去和他的领导重新商量变更需求的问题，后来他放弃了自己不合理的想法。4项目实施工程中保持与客户沟通项目的实施过程中，需求变更是必然的，但是同时也是可控的、有益的。项目实施阶段的变更控制需要做的是分析变更请求以及评估变更可能带来的风险和修改基准文件。例如，经常有这种情况，项目都已经执行到最后阶段，客户突然提出了新的要求或者要求对已有需求进行更改
14、，这会让项目主管非常为难：一方面要尽量满足客户的需求；另一方面又不能对系统做太大的改动，影响进度计划。这种情况发生除了和需求阶段有关以外，同时说明在实施过程中没有与客户有密切的联系，缺乏沟通。从客户的心理来分析。由于软件的特殊性，客户通常非常关注后期的服务，尤其是在国内大家做的软件绝大多数都是与实际业务紧密相连的。作为项目经理，非常忌讳的是在做项目的过程中对客户置之不理，而最后交付的时候才与客户突然发生大量接触，本来后期的实施过程出现问题的可能性最大，之前与客户又比较生疏，很可能会造成非常大的风险。比较稳妥的办法就是在项目进程中让项目组与客户保持联系，相互了解，建立更加融洽和谐的沟通气氛，为以
15、后关键的实施移交阶段可能与客户发生的冲突做好准备。值得一提的是：在项目进程中阶段性的给客户呈现一下项目的进展状况，让客户对项目有一个更加直接可视化的认识，更能及早的发现解决问题免除后患，在不断的沟通过中，应该让客户认识到项目组时时站在客户角度着想，让客户的主要负责人也能深深的感觉到他们是项目组的重要组成部分、荣辱与共，并且项目组能为客户提供完善持续的后续服务，这样可以有效的避免客户绞尽脑汁想把所有的事情在第一次结项之前做完。即便前期工作做得再好，很多情况下，需求变更是不可避免的。项目主管通过良好的沟通机制随时掌握变更情况和可能发生的变更，一旦发生了变更，项目组一定要冷静处理这些问题，一般可以按
16、照产品分析-成本/收益分析-备选方案-专家判断这四个步骤来首先评估需求变更，并且尽快形成项目范围变更书面的说明书，它是以后项目决策的基础，当然比较稳妥地办法还是让客户对明显发生的变更签字确定，尤其是在评估了变更可能导致的工作量增加以后，让客户认识到过多的变更很显然会造成项目延期，客户对此也要负责任。在客户提出需求变更的时候，一定要掌握一定的沟通技巧，一定不要总是无条件迁就客户。一般来讲客户对信息系统都不太熟悉，他们认为很简单的事情，可能要花费项目组大量的无谓得多余精力，所以千万不要认为客户所说的就一定是他想得到的！大部分客户都是第一时间突然脑海里面冒出的火花，所以项目组人员要冷静的分析一下：客
17、户到底想要实现什么目的，抓住问题得本质。一般来讲，实现客户本质的需求有很多种办法。在与客户的沟通中，一定避免与客户正面冲突。在初期认真倾听客户意见，多问一些“您还有什么想法”之类的问题，等客户把他的想法都表述清楚以后，项目组成员成员最好迅速评估一下客户的建议，如果实现起来实在太困难，可以给客户一些更加中肯的提议，多问些“您看这样行不行？其实可以达到同样的目的。”之类的问题，最后还有一个重要的过程就是要与客户确认这次沟通的结论。总之，项目整体管理是平衡那些彼此冲突的项目目标的一种能力。看起来简单，但是实际上很复杂，项目主管在项目进程中要学会如何对常见变更进行控制，控制客户需求的肆意膨胀，保证项目健康稳定的进行。参考文献项目管理知识体系指南项目管理：管理新视觉