一. 前言

项目管理的产生起源于传统行业，目前广泛应用于各行各业，尤其是计算机信息集成行业等高科技企业。其根本原因在于适应瞬息万变的组织经营环境，提高企业的核心竞争力。

计算机信息集成行业较之其它传统行业来讲，其项目的特点具有动态性和不确定性，项目管理过程不可简单重复，灵活性较强。这些特点使得计算机信息集成行业的项目成功率始终处于一个较低的水平，不仅造成了直接的经济损失，而且制约着行业的发展。

1994年，Standish Group 对于IT 8400个项目（投资250亿美圆）的研究结果

表明：项目实现其目标的只有16%，需要补救的项目占50%，完全失败的项目为34%。据分析，成功的软件项目依赖于成功的项目管理。而失败的原因很多，拙劣的范围管理占据了相当大的比重。其中范围计划和范围定义作为项目的前期阶段，其所注入的缺陷造成的返工工作量较之其它过程要多得多，其所造成的影响更大。而且，随之而来的是无法控制项目的风险和成本，最终导致项目的滞后和失败。

本文从范围管理的基本内容和范围管理的基本过程出发，对计算机信息集成项目中范围管理常见问题及解决办法进行探讨和总结。

二. 简述项目范围管理

1. 项目范围

项目范围指的是工作范围的界定，即：项目工作的完成为的是能交付一个有特殊的特征和功能的产品。项目范围的完成情况参照计划来检验的。

通俗地讲，项目范围是界定项目包括什么和不包括什么，做什么和不做什么，同时，也包括对如何实现这些目标的控制过程的定义。需要注意的是，过程中的工作成果也属于项目范围范畴，项目最终的工作成果是由过程中所有工作成果的集合。项目范围目标是项目其他三个目标即进度、成本、质量目标的基础。

2. 范围管理

范围管理是用以保证项目包含且只包含所有需要完成的工作，以顺利完成项目所需要的所有过程。这个过程确保了项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。

3. 项目范围管理过程

科学的范围管理是项目成功的第一步，它的基础是一个科学的范围管理流程。范围管理的基本内容包括：项目启动、范围计划编制、范围定义、范围验证、范围变更控制这五个要素，由于项目启动实际上属于企业战略管理内容，在本文中不做详细讨论：

1) 项目启动—启动项目，阐述组织为什么要做这个项目。

2) 范围计划--写出一份书面报告，作为未来项目决策基础。

3) 范围定义--把主要的项目工作细目分解成更小、更易管理操作的单元。

4) 范围验证--项目范围的正式验收。

5) 范围变更控制--对项目范围的变更进行控制。

以下分别介绍范围计划编制、范围定义、范围验证、范围变更控制四个要素：

1) 范围计划和范围说明书：

ü 范围计划编制是将产生项目产品所需进行的项目工作（项目范围）渐进明细和归档的过程。

ü 项目范围说明书说明项目论证、项目产品、项目可交付成果和项目目标。项目论证是商家的既定目标，要为估算未来的得失提供基础；项目产品是产品说明的简要概况。

ü 范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。

ü 范围管理计划描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类）等问题的清楚描述。

2) 范围定义与工作分解结构(WBS)

ü 正确的范围定义是项目成功的关键。范围定义包括分解这个主要工作细目的子项目，使它变成更小、更易管理、操作的东西。以便于提高估算成本、时间和资源的准确性。并为绩效测量和控制确定一个基准线。同时，使工作变得更易操作的，责任分工更加明确。

ü 工作分解结构进行范围定义的工具，它通过层层分解把项目主要的可交付成果分成更容易管理的单元。

3) 范围验证

ü 范围核定是通过参与者（倡议者、委托人和顾客等）的行为正式确定项目范围的过程。它要求回顾生产工作和生产成果，以保证所有项目都能准确地、满意地完成。

ü 如果这个项目已提前终止，这个范围核实过程也应该证实并应以书面文件的形式把它的完成情况记录下来。

ü 验收文件是当事人、项目发起人或投资者已经认可了这个项目产品或某个阶段的文件，他们必须为完成这项工作准备条件，做出努力。

4) 范围变更控制

ü 范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。

ü 规范的变更控制过程有助于有效控制范围变更。

三. 范围管理在计算机信息系统集成项目的重要性

信息系统项目实施失败的原因，包括项目管理九大知识体系的方方面面。由于实施信息系统项目实施周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把企业的全业务流程稳定下来，并通过系统实现，需要较长的时间来巩固。因此常常出现一些需求不稳定、需求变更，项目范围失控的现象。在信息化集成项目中项目范围管理显得尤为重要，较之其它八个领域更为关键。

项目范围是项目其它三个要素即质量、进度、成本目标的基础，项目所有管理工作和技术工作均以基线化的项目范围为基础。要做好信息化集成项目，首先要做好项目范围管理。

四. 范围管理知识领域常见问题及解决办法

1. 需求获取

l 问题描述

一个项目的各种不同干系人有各种不同的需求，而且由缺乏专门知识，难以将其需求确切、清晰地表达出来，因此，仅依赖于用户获取的需求总是不能真实反映用户业务。项目干系人在提出其需求时，不可能充分地考虑了其实现的可能性，需求往往比较零散且无法实现。

l 解决办法

可建立需求分析组，通过项目干系人责任矩阵明确职责和义务并文档化。小组成员除了需求分析专家外，还应有系统设计人员，用户方代表。这里需要强调的是，用户方代表应为用户各项业务的代表，他们能代表大多数用户需求。必要的话，需明确用户需求的最终确认人。

项目需求分析组需制定需求调研计划，探讨需求调研方法。业界通用的项目调研方法用问卷调查或面对面交谈(由调研方提问)等方法。无论采用哪一种办法，在需求调研开始之前，进行调研方法的培训和用户业务流程的培训是非常必要的。这样，有利于调研双方充分合作，获取到较为清晰的项目范围。

由于项目的唯一性特点，调研双方应明白项目需求是渐进明细的过程，一定范围的需求变更是正常的。当然，需求文档经评审基线后不可随意更改。

2. WBS分解

l 问题描述

大多数项目经理认为WBS分解的维度和粒度不好把握。

l 解决办法

WBS分解的维度和粒度应根据项目具体特点来把握。一般来讲，WBS分解从工作成果和工作进度两个维度进行占大多数。较上层的以工作成果来分，形成大的成果框架，每层下面再把工作分解。当然，比较常用的方式是两者相结合，这种方式的优点是结合进度划分直观，时间感强，项目配置项也不容易被遗漏。

到于WBS分解的粒度问题，我们在完成WBS后，不妨回答以一下以下问题就可以确认WBS是否够细了：

ü 划分更低层次的细目是否必要和充分？

ü 每个工作细目都要有明确的、完整的定义吗？

ü 是否每个工作细目都有适当的日程表、预算能分配给特殊的组织单位？

ü 谁能担负起满意地完成这个项目的任务？

3. 范围验证

l 问题描述

系统测试是范围验证的一种方法，但仅依靠系统测试是不够的。我曾遇到过这样一种情况，那就是系统测试人员本身对需求的理解就是错误的。

很多软件项目通过需求功能审计来验证项目范围的实现程度，但是多数情况下流于形式，没有起到很好的作用。

还有很多人认为范围验证仅发生在项目结项的时候。

l 解决办法

理想的做法是在项目的各个阶段，请需求分析组(特别的用户代表)、项目发起人、投资方参与评审和验证。每个阶段由工作成果的作者进行宣讲。

当然，在条件不允许的情况做一些必要的变通也是可以的，但至少在系统提交系统测试前必须得到用户方的验证。

范围验证的一个重要的方法就是进行需求编号，为各阶段成果建立必要的追溯关系。

4. 范围控制

l 问题描述

ü 沟通：用户通常认为项目的管理和控制是项目实施方的责任，用户方可以不考虑范围的限制，只需无条件的提出自己的需求，需求提得越多越好。

ü 需求范围蔓延：范围蔓延指的是当项目在不经过仔细考虑而接受了太多小的变化之后造成超出预算，延误工期的现象。很多项目经理能够意识到大的范围改变，但是对于小的改变却没有那么敏感了。

ü 变更决策的有效性：很多看似合理的变更在没有有效决策的前提下导致项目陷入困境。一个典型的问题就是有权决定这种变更的人—发起人，并没有同意这样做。

ü 项目小组的责任：项目小组成员不明白知道在范围变化管理方面职责和权力。他们经常自己答应进行一些额外的工作，从而危及整个项目的进行。

l 解决办法

控制好变更必须有一套规范的变更控制过程，变更控制过程明确规定提交变更、影响范围分析、决策、执行、通知受影响各方、配置归档等的流程。项目变更严格按变更流程执行。

在变更控制计划中，应明确项目的变更控制委员会(CCB)组织及职责，变更控制委员会由主席负责。需要特别注意的是，变更控制委员会必须包含用户或用户代表。

此外，在变更控制过程中，变更控制委员会(CCB)的决策标准是什么呢？我认为可以这样考虑：

CCB首先判断这个业务需求是否对关键业务构成关键的影响。如果不是，建议不纳入项目范围内，或者暂时不纳入本次的项目范围内，而作为日后一个扩展的功能。如果此需求对关键业务构成必要的影响，则进一步分析目前系统功能是否可以解决这个需求？如果可以，实现难度如何？如果实现难度不大，可以纳入项目范围。如果实现难度大，那么进行成本分析。项目成本分析可以从以下三个方面来分析：

（1）内部资源是否足够应付新需求的实现？包括业务部门人员、技术人员、软硬件支撑。
（2）在整体项目计划当中是否允许作这样的调整？能否在项目计划时间内完成？
（3）是否能保证项目的质量？会不会对其他功能造成影响？

如果上述成本分析回答都是肯定的，那么就可以把需求纳入实施范围，如果全为否，建议就不把其纳入本项目范围。但是由于该项需求是一个关键业务需求，可以考虑把此项目作为扩展功能在以后实现，目前可以采用其他灵活的方式处理。如果上述的回答中有肯定也有否定的，那么首先要以内部资源的问题作为重点，如果此条件不能满足，则目前先采取其他灵活的方式处理，这样既保证当前项目在原既定范围内完成，新需求在新的项目中实现。如果内部资源条件满足，那就要判断是否对项目的计划和质量造成影响或者说造成多大的影响？这种影响能否被接受和控制等等。如果会失去控制，建议不纳入范围而采取其他方式解决。