信息系统项目管理师考试辅导教程第3版第18章项目范围管理.docx

信息系统项目管理师考试辅导教程第3版第18章项目范围管理.docx

《信息系统项目管理师考试辅导教程第3版第18章项目范围管理.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师考试辅导教程第3版第18章项目范围管理.docx（36页珍藏版）》请在冰豆网上搜索。

信息系统项目管理师考试辅导教程第3版第18章项目范围管理

第18章项目范围管理

项目的范围管理影响到信息系统项目的成功。

在实践中，“需求蔓延”是信息系统

失败最常见的原因之一，信息系统项目往往在项目启动、计划、执行甚至收尾时不断加

入新功能，无论是客户的要求还是项目实现人员对新技术的试验，都可能导致信息系统

项目范围的失控，从而使信息系统项目在时间、资源和质量上都受到严重影响。

项目组

往往总是处于非常尴尬的地步：

如果对用户总是说是，那么必然意味着失控，另外一个

方面，如果总是说不，那么项目将受到客户的抵制。

在这个时候，项目组往往抱怨所谓的不合格的用户。

其实，在许多的信息系统项目

中，“需求蔓延”至少还有两个原因：

一个是项目组也从来不知道项目的范围是什么，

什么是项目应该做的，什么是项目不应该做的。

其次是许多信息系统的项目组从来没有

使用任何有效方式和过程来控制范围的变化。

如图18-1所示是项目范围管理的图示。

图18-1项目范围管理

项目范围是为了达到项目目标，为了交付具有某种特制的产品和服务，项目所规定

要做的。

项目的范围管理就是要确定哪些工作是项目应该做的，哪些不应该包括在项目

中。

项目范围是项目目标更具体的表达。

如果项目的范围不明确，那么项目解决的不是对应的问题，或者项目人员把时间浪

.360.信息系统项目管理师考试辅导教程（第3版）

费在从事不属于他们职责的工作上。

范围管理必须清晰地定义项目目标,此定义必须在客户与执行项目的组织或个人之

间达成一致，并且把项目工作范围详细地划分为工作包。

在信息系统项目中，实际上存在两个相互关联的范围：

产品范围和项目范围。

产品范围是指信息系统产品或者服务所应该包含的功能，如何确定信息系统的范围

在软件工程中常常称为“需求分析”。

项目范围是指为了能够交付信息系统项目所必须做的工作。

显然，产品范围是项目范围的基础，产品的范围定义是信息系统要求的量度，而项

目范围的定义是产生项目计划的基础,两种范围在应用上有区别。

另外产品范围在于“需

求分析”更加偏重于软件技术，而项目范围管理则更偏向于管理。

判断项目范围是否完

成，要以项目管理计划、项目范围说明书、工作分解结构、工作分解结构词汇表来衡量。

而信息系统产品或服务是否完成，则根据产品或服务是否满足了需求分析。

项目的范围基准是经过批准的详细的项目范围说明书、项目的工作分解结构和工作

分解结构词汇表。

由于进行项目的范围管理，能够确定项目的边界，明确项目的目标和项目的主要可

交付成果，所以范围管理能够提高对项目费用、时间和资源估算的准确性。

首先人们对

复杂的事务的预测要比相对简单的事务的预测要困难得多，而且误差也大得多。

而且，

即使两者误差相同，由于范围管理使用项目分解结构，将项目范围分解成可管理的工作

包，人们发现误差的和小于和的误差，虽然人们多项目分解结构的每一项的估算都存在

误差，但由于这些误差可能相互抵消，所以最终误差将比总估算的误差要小。

18.1范围管理计划编制

项目范围对项目的成功有重要的影响，范围管理包括如何定义项目的范围，如何管

理和控制项目范围的变化，如何考虑和权衡工具、方法、过程和程序，以确保为项目范

围所付出的劳动和资源能够和项目的大小、复杂性、重要性相称，使用不同的决策行为

要依据范围管理计划。

项目范围管理计划是一种规划的工具，说明项目组将如何进行项目的范围管理。

具

体来说，包括如何进行项目范围定义、如何制订工作分解结构、如何进行项目范围核实

和控制等。

由于范围管理计划描述项目范围如何进行管理,项目范围怎样变化才能与项目要求

相一致等问题。

所以它也应该对怎样变化、变化频率如何及变化了多少这些项目范围预

期的稳定性进行评估。

范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一

类等问题的清楚描述。

在信息系统项目的产品范围还没有确定之前，确定这些问题非常

困难，但是仍然有必要进行。

项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。

根据不同的

第18章项目范围管理.361•

项目，可以是详细的或者概括的，可以是正式的或者非正式的。

如果项目没有范围管理计划，就如同许多己经成功或者失败的信息系统，那么在面

对范围管理出现的问题，需求的变化、设计中的错误等“意外”情况时，项目组就缺乏

一个行动指导方针，对于用户提出的新的需求，要么全部说不，要么全说是，或者更糟:

全凭借想象说是或者不，这无疑会严重打击项目组的积极性，对项目的进度、资源使用

和完成带来非常不利的影响。

18.1.1项目范围管理计划的编制依据

编制的依据包括事业环境因素、组织过程资产、项目章程、项目初步范围说明书、

项目管理计划等。

这些因素大多在前面的章节中有所说明，组织对项目的管理，包括范围管理，往往

会形成一种约定俗成的解决方式，这些方式又随着组织的变化和市场的变化在不断变

化。

编制项目范围管理计划必须充分考虑组织的管理资产和当前项目的特殊变化。

18.1.2编制范围管理计划的工具和技术

编制范围管理计划的工具和技术包括专家判断、样板、表格和标准。

对于和其他项目类似的项目，编制范围管理计划可以遵从有其他项目范围管理的经

验的专家对当前项目的范围管理计划进行的判断和抉择。

组织中以前的项目对范围管理计划会留下一些样板、控制表格和执行标准，可以利

用这些现成的、证明有效的工具和技术来制订范围管理计划。

18.1.3范围管理计划的内容

项目的范围管理计划是对项目的范围进行确定、记载、核实管理和控制的行动指南，

与项目范围计划不同，范围计划是描述的是项目的边界，而范围管理计划是如何保证项

目边界应该采取的行为。

项目的范围管理计划包括如下内容：

•如何从项目初步的范围说明书来编制详细的范围说明书。

•如何进行更加详细的项目范围说明书编制工作分解结构，如何核准和维持编制

的工作分解结构。

•如何核实和验收项目所完成的可交付成果。

•如何进行变更请求的批准。

例如，对于工作分解结构的编制指南可能有如下内容：

•确定工作分解结构满足职能和项目的要求，包括重置和非重置成本。

•检查工作分解结构是否为所有的项目工作提供了逻辑细分。

•保证每一个特定层的总成本等于下一个层次构成要素的成本和。

•362.信息系统项目管理师考试辅导教程（第3版）

用户

系统设计师

项目经理

程序员

图18-2不同人认为的项目范围

项目和子项目都需要编写项目的范围定义，项目范围定义明确项目的范围：

项目的

合理性、目标，以及主要可交付成果。

一般来说，项目范围计划由项目小组编写，也可

以由项目委托者编写。

它是项目的相关各方之间协议的基础。

范围定义所编制的详细的范围说明书根据项目的主要可交付成果、假设和制约因

素，具体地说明和确定项目的范围。

另外，项目范围定义是在项目方案决定之后才进行的，但是在进行项目范围定义的

•从全面适应和连续角度来检查工作分解结构。

•所有的工作职责需制订到个人或组织。

例如，对范围管理的常见问题的建议如表18-1所示。

表18-1范围管理中的常见问题和建议

常见问题建议

不完整的需求得到完整的需求

缺乏用户参与联系所有的项目利益相关人

不现实的期望加强沟通

需求改变进行范围控制

缺乏计划增强项目计划

在压力下放弃计划增强项目计划

遗漏必要的任务加强范围确认

开发人员的镀金界定项目边界

功能蔓延进行范围控制

18.2范围定义

范围定义对于项目而言非常重要，它增加项目时间、费用和资源估算的准确度，定

义了实施项目控制的依据，明确了相关责任人在项目中的责任。

如图18-2所示为不同

人认为的项目范围。

过程中，必然又对项目的目标和方案进行疑问，如果在此期间发现项目的目标和方案有

错误，应该立即提出疑问。

18.2.1范围边界

范围定义最重要的任务就是详细定义项目的范围边界，范围边界是应该做的工作和

不需要进行的工作的分界线。

如图18-3所示为项目边界。

第18章项目范围管理.363.

不在项目范围内的工作

在项目范围内的工作

图18-3项目边界

项目小组应该把工作时间和资源放在范围边界之内的工作上。

如果相反，把精力和

时间放在项目范围边界之外的工作上，那么得到的回报将非常少。

在制订了项目范围边

界之后，这看起来是非常明显的事情。

但实现中却有许多遗憾，第一，许多信息系统项

目并没有真正试图清晰地定义项目边界；其次是在信息系统的项目开发中，经常存在着

一种称为“镀金”的行为，项目实施人员往往愿意尝试新的技术或者为信息系统项目加

上一些无关紧要的华丽界面，而不考虑所做的工作是否是在项目范围边界之内。

如何减

少“镀金”行为对信息系统项目的影响应该列入项目范围管理计划。

范围边界的定义往往来源于项目初步范围说明书和批准的变更。

有些项目并没有项

目的初步范围说明书，而常常利用产品的范围说明书。

显然，项目的存在就是为了产生

相应的产品或者服务，产品的范围是决定项目的范围的重要因素。

例如，某个组织需要建立一个远程数据采集系统，要求提供一个用户在中心机房采

集远程数据的系统，并对采集的数据进行相应的分析。

项目的初步范围说明书为：

（1）硬件安装，包括采集器、集中器、数据通道和中心机房的安装。

（2）软件编制，包括采集器控制软件、集中器控制软件和中心机房监控软件。

许多时候，项目范围定义重要的工作不仅仅是确定什么工作需要完成，而且也要确

定什么工作不需要完成。

在进行范围定义时，信息系统项目范围边界不可避免地受到了开发工具（代码库、

类库、快速开发语言其他支持工具等）的限制，如图18-4所示。

理想的项目范围

提供的功能

项目不包括\

的内容、

项目包含/

的功能/

图18-4信息系统项目开发工具对项目范围边界的限制

.364.信息系统项目管理师考试辅导教程（第3版）

18.2.2产品范围和项目范围

项目范围应该以产品范围为基础，产品范围的分析随项目的产品领域不同而不同，

在每个领域中都有一些公认的分析方法。

在信息系统项目所产生的软件产品或服务领

域，软件工程己经成为公认，传统的数据流图、面向对象分析和设计、统一建模语言中

的用例分析等技术都在相当程度上提高了软件产品分析和实现的效率。

软件工程师在这

些方面有无数的失败教训，也有无数的成就积累，这些方面的内容是信息系统项目管理

的重要基础知识。

例如，对采集器控制软件的进行用例分析可以大致得到如图18-5所示的结果。

其他方案识别用来提出不同的方案和技术，并进行比较。

最常用的是头脑风暴法和

横向思维。

对于信息系统而言，技术方案的选择也非常重要，虽然计算机显得无所不能，

但是如果不选择合适的技术和方法，信息系统项目往往会陷入泥潭。

比如公文的传递、

修改，以及和公文流转相关的权限和流程不使用0A系统技术而使用关系数据库系统，

广域网的软件不使用B/S方式或者多层技术而使用C/S方式，都会有事倍功半的效果。

这时候资深技术专家的咨询无疑能有效地进行范围定义，并及时发现范围定义中的错

误。

产品范围并不是必然能推出项目范围。

事实上，会存在许多对产品范围的误解而造

成项目范围和用户预期格格不入的情况发生。

比如，某公司开发过许多管理系统，这次

和某客户签订了合同，为该客户开发管理信息系统。

在需求调研完成后，公司发现客户

需要一个全新的版本，而不是公司开始所预计在旧版本上的为客户的定制。

而公司在投

标报价时是按照所设想的情况进行报价的，这给以后的项目实施埋下了隐患。

最后，项

目完成时间一次次推迟，用户和公司都一致认为，这是一个失败的项目。

无论产品范围定义得多么