系统集成项目中范围管理.docVIP

系统集成项目中范围管理 　　摘要：系统集成项目中，由于客户经常不能拿出或者说根本都不可能拿出一套最终解决方案的全部功能和要求，因此，在项目进行的过程中可能有这样或是那样的变更，就有了“项目为什么总是做不完？”的感慨。因此，有效的控制和实现项目范围管理是项目全生命周期内十分重要的控制。 　　关键词：系统集成项目；范围管理；需求变更 　　 　　一、范围管理的概念 　　 　　范围管理（Scope Management）是为了实现项目的目标，对项目的工作内容进行控制的管理过程，包括对工作范围的界定、规划、调整。它的主要任务是界定项包含且仅包含所有需要完成的工作，并对项目其他方面的管理起到指导作用，最终的结果就是保证项目顺利完成。 　　定义并计划项目只是成功地管理一个项目的第一步。在你做完工作计划之后，就要按照这个计划工作。你必须保证你同意完成的工作在规定的时间和预算项目范围内完成。当项目的范围订立，项目的工作边界也随之定了，有了明确的项目目标和主要的项目交付成果。 　　 　　二、项目为什么做不完 　　 　　谈这个问题前，先举个例子，笔者在做一个学校的集成项目时候所遇到的问题。按照合同要求，工程只负责4栋宿舍楼内部的综合布线、中心机房改造、接入设备的升级。然而在实际的工作过程却增加了不少，中心机房改造，校方要求将大房间隔小；中心机房改造完成后，又要求把旧窗帘和吊灯给换新的，为了和整体风格呼应；宿舍综合布线完了，却因先前校方联系的电信运营商免费光纤敷设工作不能进行，而不得不去敷设光缆；在其它设备升级的过程中，校方要求对先前乱七八糟的配线间线缆重新测序，等等。不隔墙，中心机房装修无法进展，工作无法开展；窗帘、灯盏不给更换，校方明确表示要延后验收时间；光缆不拉，不能完成整体的验收。上述的这些问题都不是一次性冒出来的，而是在工程进行的过程中不断地出现。这样一来，全盘答应，成本、工期都得增加；不答应又会为验收工作的开展添堵。最后双方商议对项目做出了变更，我公司答应来全部要求，校方也接受了因变更带来的工期延后和成本增加。 　　上述实例说明，在实际的工程项目中范围蔓延随时可能发生。那么作为项目经理我们怎么做呢？项目经理的职责主要是承担项目并在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。然而，为了让客户满意我们是否就该不断满足客户无穷无尽的需求？不接受会不会导致项目的最终失败呢？我们应该分析范围变更出现问题的根本原因： 　　1. 签订合同时缺乏对信息系统集成项目熟悉的人员参加，导致项目目标描述不清，为后期的实施工作带来困惑。 　　2. 客户和项目组均希望将项目做好。但是客户可能对信息系统项目缺乏全面的了解，项目组对客户需求细节的了解也不充分，而且双方对实现需求的方式的理解也存在差异。而双方在项目初期又均未意识到这种沟通上的不畅，导致移交系统时才使问题暴露出来。 　　3. 项目组人员不能区分客户真正需求和镀金需求，全盘接受客户的变更请求。当然这样做也是为让客户满意，但是实际上不一定能达到目的。 　　 　　三、如何管理好项目范围 　　 　　项目经理和项目小组必须意识到范围变化本身并没有什么不对。也就是说在项目进行的过程中修改范围并不是什么坏事。事实上，很多时候项目范围变化是件好事，可以使系统更健壮、更完善。项目管理本身就是一个既然项目范围变更不可避免，那么我们就得找到一个行之有效的项目范围管理的手段。为执行变更控制，必须建立有效的范围变更流程。这个流程应该包括确认变更、评估变更的商业价值、分析变更对项目的影响，以及提交给项目发起人进行评价以确定是否执行变更。然而仅有范围变更流程尚不足以真正控制变更，这是因为项目组的外部有许多压力，同时与缺乏行之有效的变更控制手段密切相关。 　　目前流行的变更管理思想认为在范围变更流程中有四个关键点必须严格控制：谁有权确认变更、什么样的变更需要执行、变更的影响多大、客户是否接受变更的代价。 　　 （一）谁有权确认变更 　　不应当为节省时间而允许客户的业务人员与开发人员直接联系，这样无法控制变更。必须事先明确客户方有权提出变更请求的人员和项目组有权受理变更的人员，变更请求必须有书面材料。 　　当用户如果发现由于业务变化而引起的需求变更，需要向客户方项目负责人提出书面申请，由客户方项目负责人审批后移交实施方项目经理。 　　这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重，一般都在自己科室内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。 　　 （二）什么样的变更需要执行 　　不是所有的变更都需要修改，更不是所有的变更都需要立刻修改。必须对客户提出的范围变更进行审核，来决定哪些变更需要修改和什么时