信息于系统集成项目中如何控制客户需求.doc

信息系统集成项目中如何控制客户需求 【摘要】信息系统集成项目中拿过来合同(或者任务委托书)关于项目范围的说明只有寥寥数行，套话，项目都包含什么样的模块，具体的业务客户在项目进程中，不断对移交的系统提出修改意见，有些问题开始提出更改，某一天客户突然就发现情况不对，又要求你给改来信息系统集成没有对项目的范围进行确定就与用户签订了合同。在项目启动后，由于对项目的范围没有确定，导致项目的需求总是在变化，项目周期一再延期，用户也不满意，公司项目小组也很累，成本也很难控制！、客户需求肆意膨胀 项目，在规定时间用有限的资源来保质保量的完成项目，让最终客户满意是项目组的神圣职责。但是为了让客户满意就要满足客户所有的需求吗？因为不断满足客户的需求会不会导致项目失败怎么办呢？为了弄清楚这些原因，首先应该找到这些问题发生的根源。 1.项目范围描述不清楚。 ???没有对项目的范围进行确定就与用户签订了合同。最常见的问题之一，正是早期的这些问题没有引起项目组的足够重视，导致后期项目无穷无尽的修改。2.客户和项目组对需求理解不一致。 ??? 这种情况客户已经确认了项目组提交的项目范围说明书，项目组也是完全按照这个文件规定的内容做的，但是客户还要求改，当项目组拿着纸面的文件与客户对质的时候，才发现客户也认可这需求，但是同一件事情，客户的认知和项目组的完全不同。举个的例子：，但是当移交给客户的时候才发现，客户有时候就是当初一点点疏忽，导致项目后期大量修改甚至项目延期。 3.客户。 一般来讲，在项目结项之前，客户都会把所有的想法尽量逼着项目组解决，因为一般的客户心理都会认为：一旦结项了，再想找项目组成员对业务系统进行修改可就难了，因为IT公司人员流动性强的特点，即便以后能够找到承包商，当初做项目的项目组成员也不一定在了，或者很多公司因为业务繁忙，已经顾不得原来已经结款的客户了。项目组人员总是无条件迁就客户，客户有求必应。这种做法的出发点是好的，目的是要客户完全满意，但是实际上这种做法不一定能达到目的。有些问题开始提出更改，某一天客户突然就发现情况不对，又要求你给改来、客户需求肆意膨胀 项目问题以及发生的原因，结合以前一些项目的教训经验，有效屏蔽客户需求过渡膨胀 《项目管理知识体系指南》中关于项目范围管理的描述是：项目范围管理是确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。它主要关心的是确定与控制哪些工作应该包括在项目之内，哪些工作不应该包括在项目之内。范围定义是制定详细的项目范围说明书，作为将来项目决策的根据。项目范围说明书详细地说明了项目的可交付成果和为提交这些可交付成果而必须开展的工作。项目范围说明书还是所有项目利害关系者对项目范围的共同理解，说明了项目的主要目标。项目范围说明书还使项目团队能够实施更详细的规划，在执行过程中指导项目团队的工作，并构成了评价变更请求或增加的工作是否超出了项目边界的基准。 基于《项目管理知识体系指南》中关于项目范围管理的描述，可以肯定的是在项目初期一定要制定清晰的目标和项目范围，并且让项目主要干系人(最重要的当然是最终客户了)确认。 　　不管通过什么途径得到的项目，作为项目主管，在项目前期，可以分三步走。 　　第一想到的问题应该是“为什么”，也就是客户做项目目的，知道这些以后，才能在以后的工作中更加想客户之所想，不至于项目方向错误，最终争取达到双赢得局面。 　　知道了“为什么”以后，接下来就要非常清晰的知道“做什么”，有一个比较好的办法就是用一两句非常简洁的话概括出来整个项目，能够用这种方法概括出项目中的各个子任务，并且能够让前台业务人员和后台研发人员都能够心领神会，那么说明项目主管对项目的内容在大方向上已经有很好的把握了。 要弄明白“怎么做”，对于比较陌生的项目来讲，这一阶段工作量比较大也很重要，在这个阶段多花点精力绝对值得，当然，根据具体的情况，也可以在这个需求调研阶段简化一些不必要的工作，这需要项目主管具备平衡那些彼此冲突的项目目标的能力。在实际的工作中，这需要一个过程，值得注意的是，在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍，在实际的操作中，这种做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大降低，还可以很好的发潜在的问题，并且掌握一些沟通技巧，也会让客户更能深刻的感觉到承包商对他们的重视。另外，如果项目前期需求人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通，以避免不必要的给客户的承诺，更加准确的界定工作量。总之，有效的计算出项目范围将会占用一定的时间，但是同样会节省资源、资金以及解决项目今后令人头疼的问题，例如：需求(范围)变更。 变更控制委员会控制需求变更最理想的办法是由客户方、开发方的项目经理和需求