一、前言范围管理（Scope Management）是项目管理中的一个专用词汇，它的主要任务是界定项目包含且只包含所有需要完成的工作，并对项目其他管理工作起到指导作用，以保证顺利完成项目的所有过程。

　　一般来说，确定了项目范围，也就确定了项目的工作边界，明确了项目目标和项目主要可交付成果。对于信息系统集成项目，如果不能明确的定义和有效的控制项目范围，将会产生非常严重的后果。例如：项目实际需要包含，客户 因不能提供完整、详细的描述而未能明确定义范围，从而导致项目最终解决方案的不可用；另一方面，项目范围的蔓延或频繁变更，从而影响项目成本、进度。

　　以笔者主管和参与多个项目的实际经历来看：范围蔓延是非常可怕的事，客户总是想把所有的需求都在一个系统里实现，从而导致项目成果的臃肿和不切实际。客户有种想法是非常不可取的：“（开发人员）做好了先放在那儿，即使不用也好，以后万一用上了呢？”。还有，客户在项目进程中，尤其是到了项目后期，不断对移交的系统提出修改意见，甚至有时刚刚重新设计完成开始更改，客户又要求改回去或改成另一种模式。“无底洞”是国内大部分项目经理进行信息系统集成项目的共同感觉。

　　“项目为什么总是做不完？！”

　　二、原因分析项目经理作为项目的承担者，在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗？这样会不会导致项目的最终失败呢？我们应该分析范围变更出现问题的根源原因。

　　1、 签订合同时缺乏对信息系统集成项目熟悉的人员参加，导致项目目标描述不清，为后期的实施工作带来困惑。

　　2、 客户和项目组均希望将项目做好。但是客户可能对信息系统项目缺乏全面的了解，项目组对客户需求细节的了解也不充分，而且双方对实现需求的方式的理解也存在差异。而双方在项目初期又均未意识到这种沟通上的不畅，导致移交系统时才使问题暴露出来。

　　列举几个笔者碰到的具体问题：

　　A、IT项目的客户往往认为计算机是万能的，有了它，自己只需要输入几个参数就什么都不用管了。而实际上任何技术都有局限性。

　　B、某客户知道自己需要一个库存管理软件，但是，是引进新的库存管理思想还是沿用目前的模式却还没有考虑好，而开发人员已经到位，于是要求项目组先按目前模式做。当后来客户想要更改管理方式时，问题出现了，设计的更改导致大量模块的重写，工期不可避免的延长。

　　C、某客户要求“方便”的查询设备位置，于是开发人员设计了一个界面可以按各种条件来查询设备的所在位置。当移交系统时，客户发现与预想的不一样，原来客户的“方便”是指用图形化界面的方式直观的表现。项目组只好延期几天来开发这一功能。

　　3、 项目组人员不能区分客户真正需求和镀金需求，全盘接受客户的变更请求。当然这样做也是为让客户满意，但是实际上不一定能达到目的。

　　三、范围变更管理首先，签订合同时就需要明确定义项目的范围，这当然需要熟悉信息系统集成项目的人员参加合同谈判。合同中定义好的项目范围可以为以后各项工作的开展奠定深厚的基础。

　　其次，合同中的项目范围应该还只是粗线条的约定，必须进行细化和深入。编制范围说明书和范围管理计划是其中重要的部分。范围说明书应该包括项目论证、产品简介、主要可交付物、验收标准等。另外必须为项目组预留足够的时间来进行详细需求的调研，并提出工作分解结构（WBS）和需求分析报告。WBS可以为项目执行绩效评测和项目控制提供一个基准。

　　在系统需求分析阶段，项目组成员和客户的深入交流是项目成功的关键。但是由于双方的误解通常使交流难以进行。AMT的刘立军先生总结的Why、What、How方式可以非常有效的使沟通顺畅。简单的说，在项目初期，项目经理首先需要考察客户做这个项目有什么用处，就是“为什么”，这样才能真正从客户的角度来考虑系统的设计；接下来需要总结出整个项目是“做什么”，并能概括出各个子任务，让开发人员对项目内容的大方向有很好的把握；最重要的当然是“怎么做”了，对信息系统集成项目而言，这个阶段多花点时间绝对值得。其中也有些小技巧：需求分析报告应以客户认为易于翻阅和理解的方式进行编写，同时也要有助于开发人员开发出真正需要的系统；项目组成员最好就需求分析报告给客户详细的讲述，并达成共识，沟通手段在这里很重要；另外，需求确认之后，最好让客户方管理层书面签字，作为终止需求分析过程的标志，但是绝不是作为拒绝范围变更的手段。

　　四、行之有效的变更控制一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。项目经理和项目小组必须意识到范围变更本身并没有什么不对，事实上很多时候这会让你的系统更健壮、更实用。客户通常不能一开始就确定所有需求，而且情况会随时间而变化，如果不能包容变更，那么最终解决方案可能就达不到应有的价值。

　　但是如果变更失控，后果也非常严重，甚至于导致整个项目的失败。根据1995年斯坦迪什公司的研究结果，最可能引起IT项目失败的前三个因素分别为：缺乏用户参与、不完整的要求和说明、易变的要求和说明，这几个因素都直接或间接与范围变更管理有关。

　　因此，必须进行范围变更管理。潘东先生认为：“变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”

　　为执行变更控制，必须建立有效的范围变更流程。这个流程应该包括确认变更、评估变更的商业价值、分析变更对项目的影响，以及提交给项目发起人进行评价以确定是否执行变更。

　　但是仅有范围变更流程尚不足以真正控制变更，这是因为项目组的外部有许多压力，同时与缺乏行之有效的变更控制手段密切相关。

　　目前流行的变更管理思想认为在范围变更流程中有四个关键点必须严格控制，既：谁有权确认变更、什么样的变更需要执行、变更的影响多大、客户是否接受变更的代价。

　　1、 谁有权确认变更：

　　不应当为节省时间而允许客户的业务人员与开发人员直接联系，这样无法控制变更。必须事先明确客户方有权提出变更请求的人员和项目组有权受理变更的人员，变更请求必须有书面材料。

[1] [2] 下一页