系统集成项目范围管理.docx
《系统集成项目范围管理.docx》由会员分享，可在线阅读，更多相关《系统集成项目范围管理.docx（30页珍藏版）》请在冰豆网上搜索。
系统集成项目范围管理
系统集成项目范围管理
在管理项目的范围之前，首先应收集客户等干系人的需求，并根据需求来定义并记
录产品的特征与功能，这一部分内容在第3章的“系统分析”中已经作过介绍。
范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项
目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。
项目范围的变化也叫变更。
对项目范围的管理，是通过5个管理过程来实现的。
（l）编制范围管理计划；制定一个项目范围管理计划，以规定如何定义、检验、控
制范围，以及如何创建与定义工作分解结构。
（2）范围定义：
这个过程给出关于项目和产品的详细描述。
这些描述写在详细的项
目范围说明书里，作为将来项目决策的基础。
（3）创建工作分解结构：
将项目的可交付成果和项目工作细分为更小的、更易于管
理的单元。
在项目范围管理过程中，最常用工具就是工作分解结构（WorkBreakdown
StnIture，WBS）。
工作分解结构是一种以结果为导向的分析方法，用于分析项目所涉及
的工作，所有这些工作构成项目的整个工作范围。
WBS为项目进度管理、成本管理和范
围变更提供了基础。
（4）范围确认：
该过程决定是否正式接受己完成的顼目可交付成果。
（5）范围控制：
监控项目和产品的范围状态，管理范围变更。
在第6章项目整体管理中，项目章程、项目范围说明书（初步）、项目管理计划的
完成，为本章的编制范围管理计划提供了依据。
而范围管理计划为范围定义和创建工作
分解结构提供了方法。
编制范围管理计划、范围定义和创建工作分解结构属于计划过程。
而范围确认和范
围控制则属于监控过程。
本章的7.2节～7.6节将介绍这5个过程。
这些过程之间及其与其他领域的过程之间彼此互相影响。
根据项目需要，每个过程
可能会需要一人或多人的努力。
每个过程通常在项目中至少发生一次。
如果项目被划分
为阶段的话，每个过程通常至少在项目的某个阶段中发生一次，甚至可能在多个阶段被
执行多次。
尽管这里提到的这些过程是作为各自独立豹组成部分给予了明确的界定，但是在实
践中它们是以各种形式重叠和相互影响的。
7.1产品范围与项目范围
在项目背景下，范围指如下几个术语。
（1）产品范围；表示产品、服务或结果的特性和功能。
产品范围包含产品规格、性能技术指标的描述，即产品所包含的特征和具体的功能
性能情况等。
（2）项目范围：
为了完成具有规定特征和功能的产品、服务或结果，而必须完成的
项目工作。
本章的重点是管理项目范围所作用的过程。
这些过程、支持工具和技术随应用领域、
项目所在的行业而变化，通常作为项目生命期定义的一个组成部分，记录在范围管理计
划中。
项目范围是否完成以项目管理计划、项目范围说明书、WBS、以及WBS字典作为
衡量标准，而产品范围是否完成以产品要求作为衡量标准。
两种范围管理需要很好地集
成起来，以确保项目工作能产生所规定的产品并准时交付。
项目的范围一般来自项目投资方或客户的明确的项目目标或具体需求，任何一个项
目的建设过程都有其明确的目标，因此在讨论项目范围管理的时候，我们不可能脱离项
目的目标。
项目的目标是项目范围管理计划编制的一个基本依据。
完成项目工作范围是为了实现项目目标，那么如何有效地、全部地完成项目范围内
的每项工作，这是我们每个项目管理者不得不思考的问题。
因比对项目范围管理及控制
的有效性，是衡量项目是否达到成功的一个必要标准，项目范围的管理不仅仅是项目管
理计划的一个主要部分；同时在项目中不断地重申项目工作范围，有利于项目不偏离轨
道，是项目中实施控制管理的一个主要手段。
“圈定”项目的范围，并不能说明项目范围就是可控制的。
因此要进一步对项目范
围定义，实际就是对项目工作范围进一步细化的过程，使项目范围具体化、层次化、结
构化，从而达到可管理、可控制、可实施的目的，减少项目风险。
项目范围管理不仅仅是让项目管理和实施人员知道为达到预期目标需要完成哪些
具体的工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任。
详细、
清楚地界定分工界面和责任，不但有利于项目实施中的变更管理和推进项目发展，减少
责任不清的事情发生，也便于项目结束时对项目范围清晰的确认。
例如，如果项目的某
个工作包出现工期延迟现象，那么就可以很快找到具体的责任人并及时提出解决方案。
项目范围确认是指项目干系人对项目范围的正式承认，但实际上项目范围确认是贯
穿整个项目生命周期，从项目管理组织确认WBS的具体内容开始，到项目各个阶段的
交付物检验，直至最后项目收尾文档验收，甚至是最后项目评价的蒽结。
确认项目范围对项目管理而言有如下意义。
（1）清楚了解项目的工作具体范围和具体工作内容，为提高成本、时间和资源估算
的准确性打下基础。
（2）项目范围的确定就是确定了项目的具体工作任务，这样有助于清楚地划分责任
和分派任务，为进一步安排工作和任务打下了基础。
因此项目范围管理和控制是项目管
理计划的一部分，也是项目各项计划的基础。
对于项目管理者而言，只清楚项目范围的含义还是不够的，最重要的是正确、清楚
地定义项目范围并管理项目范围的变更，否则会造成最终项目成本超支、进度严重拖延，
偏离了项目既定目标，严重时会导致项目的失败。
项目范围是否完成要基于项目管理计划来度量。
产品范围是否完成要基于产品要求
来度量。
项目范围管理过程需要与其他知识域的过程相结合，只有如此项目的工作才能
提交满足要求的产品。
7.2编制范围管理计划
项目范围的定义和管理过程将影响到整个项目是否成功。
每个项目都必须慎重地权
衡工具、数据来源、方法论、过程和程序以及一些其他因素，以确保在管理项目范围时
所做的努力与项目的规模、复杂性和重要性相符。
例如，关键项目需要做正式的、彻底
的范围管理。
而常规项目则可以相应地简化。
项目管理团队要把这样的决策写入范围管
理计划中，
范围管理计划是一个计划工具，用以描述该团队如何定义项目范围、如何制订详细
的范围说明书、如何定义和编制工作分解结构，以及如何验证和控制范围。
项目管理团队在编制计划时，需要联系实际工作，考虑各种主要制约因素。
例如，
准备采取的行动是否有可能违背本组织的既定方针，某些活动之间是否存在必然的联
系等。
7.2.1编制范围管理计划的工具和技术
保证一个计划的合理性，必然需要合理、科学的分析方法和技术来支持，对于编制
项目范围管理计划所使用的工具与技术，主要有以下几种。
1．专家判断
专家用以往的同类项目的范围管理经验，可以为现在管理的项目提供有关的范围说
明书、工作分解结构和范围管理计划等方面的有价值的、详细的参考资料。
2．模板、表格和标准
模板、表格和标准包括工作分解结构模板、变更控制表格和范围变更控制表格。
通过采用组织的或项目经理个人的模板、表格和标准，可以规范范围管理计划编制
过程，提高过程效率。
在编制项目范围管理计划过程中，不仅限于以上方法，这需要根
据项目的实际情况来灵活地创造出新方法。
7.2.2编制范围管理计划的输人、输出
1．输入
项目范围管理计划的编制，需要合理的、有效的根据，以制定出能指导项目顺利进
行的范围管理计划。
一般而言，编制项目范围管理计划，需要项目合同、初步的项目范
围说明书、组织过程资产、环境和组织因素以及初步的项目管理计划。
（1）项目章程。
项目章程是正式批准一个项目的文档，或者是批准现行项目是否进入下一阶段的文
档，项目章程也为项目经理使用组织资源进行项目活动提供了授权。
作为项目启动重要
的标志性文件，项目章程为编制范围管理计划提供了重要的参考，关于项目章程，详见
6.2节。
（2）项目范围说明书（初步）。
项目范围说明书在“可交付物”层次上明确了要完成项目需要做的相应工作。
项目
范围说明书（初步）明确项目及其相关的产品和服务的特性和边界，以及范围控制和验
收的方法。
在范围管理计划中，应明确从项目范围说明书（初步）分解出项目范围说明
书（详细）的方法，关于项目范围说明书（初步）的详细说明请参见6.3节。
（3）组织过程资产。
组织过程资产是能够影响项目范围管理的正式和非正式的政策、程序和指导方针。
在编制顼目范围管理计划时应特别关注：
①适合于编制范围管理计划的组织政策。
②与编制范围管理计划和范围管理相关的组织程序。
③可用来在当前编制项目范围管理计划过程中用作参考的、过去项目形成的知识
库中的历史信息。
（4）环境因素和组织因素。
环境的和组织的因素包括关于当前组织的文化、基础设施、工具、人力资源、人事
政策以及市场条件等能够影响范围管理的信息。
（5）项目管理计划。
项目管理计划的制订是一个逐步完善的过程，从项目早期的简略的项目计划逐步演
化到计划阶段末期的详细的项目管理计划，在这个过程中吸收了范围管理、进度计划、
预算等分计划。
反过来项目管理计划的整体视角又为分计划的完善提供了依据。
有关项
目管理计划的详细说明请参考6.4节。
2．输出
编制项目范围管理计划过程的成果是项目范围管理计划，项目范围管理计划简称为
项目范围计划或范围计划。
作为编制项目范围管理计划过程的交付物，项目范围管理计划是项目管理团队确
定、记录、核实或确认、管理和控制项目范围的指南。
项目范围管理计划的内容如下。
（1）根据初步的项目范围说明书编制一个详细的项目范围说明书的方法。
<2）从详细的项目范围说明书创建WBS的方法。
（3）关于正式确认和认可己完成可交付物方法的详细说明。
（4）有关控制需求变更如何落实到详细的项目范围说明书中的方法。
需求变更常常
触发整体变更控制过程。
根据具体项目的实际情况，项目范围管理计划可以是正式的或非正式的、详细的或
粗略的。
一个范围管理计划可以包括在项目管理计划中，或者是项目管理计划的一个分
计划。
项目管理计划是项目其他知识域中的相关分计划的集合。
7.3范围定义
范围定义过程是详细描述项目和产品的过程，并把结果写进详细的项目范围说明书
中。
准备一个详细的项目范围说明书，对项目的成功是至关重要的，这个工作基于在项
目启动阶段的主要可交付物如初步的项目范围说明书、假定以及约束上。
当获知更多的
项目信息时，项目范围被更清晰地定义和描述。
为了完成项目，分析现存的风险、假定
以及约束，同时把必要的新发现的风险、假定以及约束遣加到详细的项目范围说明书中。
7.3。
l范围定义的工具和技术
1．产品分析
每个应用领域都有一些通用的方法把高层的产品描述转变为切实的可交付的成果。
产品分析包括许多技术，例如产品分解、系统分析、系统工程、价值工程、价值分析和
功能分析等。
2．识别出多个可选的方案
识别出可选方案是一种技术，该技术用来产生执行和完成项目工作的多种方法。
在
这个过程中可应用很多通用的管理方法，例如“头脑风暴法”和“横向思维法”。
3．专家判断法
每个应用领域都有一些专家，其经验可用于定义详细的项目范围说明书。
他们的判
断和专长可运用于任何技术的细节。
7.3.2范围定义的输入，输出
1．输入
范围定义的输入包括以下内容。
（l）项目章程和初步的范围说明书。
如果项目执行组织中没有使用项目章程或初步的范围说明书，就需要收集包括产品
范围说明书等信息，以产生详细的项目范围说明书。
（2）项目范围管理计划。
在项目范围管理计划中，给出了从初步的项目范围说明书编制一个详细的项目范围
说明书的方法。
详细说明请参见7.2节。
（3）组织过程资产。
组织过程资产包括组织中指导工作的过程、程序以及组织的全部知识，在范围定义
过程中可以提供有价值的参考资料，详细说明请参见7.2节。
（4）批准的变更申请。
经核准的需求变更能引发项目范围、进度、成本或质量的变更。
变更申请常常在项
目进行过程中被确认，变更申请有多种形式：
口头的或书面的、直接的或间接的、外在
的或内部的、法律要求的或随意的，一般情况下，建议变更申请以书面形式提出。
2．输出
范围定义的主要交付物是范围说明书。
在范围定义过程中，还可能对项目的管理计
划进行更新。
项目范围说明书详细描述了项目的可交付物以及产生这些可交付物所必须做的项
目工作。
项目范围说明书在所有项目干系人之间建立了一个对项目范围的共同理解，描
述了项目的主要目标，使项目团队能进行更详细的计划，指导项目团队在项目实施期间
的工作，并力评估是否为客户需求进行变更或附加的工作是否在项目范围之内提供基准。
（l）项目范围说明书（详细）。
也可以把“项目范围说明书（详细）”称为“详细的项目范围说明书”。
详细的范围
说明书包括的直接内容或引用内容如下：
’①项目的目标。
项目目标包括成果性目标和约束性目标。
项目成果性目标指通过
项目开发出的满足客户要求的产品、服务或成果。
项目约束性目标是指完成项目成果性
目标需要的时间、成本以及要求满足的质量。
②产品范围描述。
这一节描述了项目承诺交付的产品、服务或结果的特征。
这种
描述会随着项目的开展，其产品特征会逐渐细化。
③项目的可交付物。
可交付物包括项目的产品、成果或服务，以及附属产出物例
如项目管理报告和文档。
根据需要，可交付物可以被描述得比较概要，也可以很详细。
④项目边界。
边界严格定义了哪些事项属于项目，也应明确地说明什么事项不属
于项目的范围。
⑤产品验收标准。
该标准明确界定了验收可交付物的过程和原则。
⑥项目的约束条件。
描述和列出具体的与项目范围相关的约束条件，约束条件对
项目团队的选择会造成限制。
例如，客户或组织发布的预算或任何强加的日期（进度里
程碑）都应被包括在内。
当一个项目按合同执行时，合同条款通带是约束条件。
约束信
息应该列入项目范围说明书或单独的文档。
⑦项目的假定。
描述并且列出了特定的与项目范围相关的假设，以及当这些假设
不成立时对项目潜在的影响。
作为计划过程的一部分，项目团队经常识别、记录和确认
假设。
假设信息应该列入项目范围说明书或单独的文档。
（2）更新的项目文档。
范围定义过程的变更会导致范围管理计划的变更，从而相应的项目文档也会得到更
新，这些文档包括项目管理计划、各分计划、项目干系人需求文档以及需求追踪矩阵。
这些更新要通过整体变更控制进行处理。
7.4创建工作分解结构
7.4.1项目工作结构分解的目的和意义
创建工作分解结构是一个把项目可交付物和项目工作逐步分层分解为更小的、更易
于管理的项目单元的过程，它组织并定义了整个项目范围。
项目的工作分解结构（WBS）
是管理项目范围的基础，详细描述了项目所要完成的工作。
WBS的组成元索有助于项目
干系人检查项目的最终产品。
WBS的最低层元素是能够被评估的、可以安排进度的和被
追踪的。
WBS的晟底层的工作单元被称为工作包，它是定义工作范围、定义项目组织、设定
项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度的基础。
如果准确无误地分觯出WBS，并且这样的WBS得到了客户等项目干系人的认可，
那么凡是出现在WBS中的工作都应该属于项目的范围，都是应该完成的。
凡是没有出
现在WBS中的工作，则不属于项目的范围，要想完成这样的工作，要遵循变更控制流
程并需经过变更控制委员会的批准。
7.4.2WBS的表示形式
WBS-般用图形或列表形式表示。
WBS包含了项目的全部工作，包括项目的管理
工作以及实现昂终产品或服务所必须进行的技术工作，也是制定进度、分配人员、分配
预算的基础。
当前较常用的工作分解结构表示形式主要有以下两种。
（l）分级的树型结构，类似于组织结构图，如图7-1所示。
树型结构图的WBS层次清晰，非常直观，结构性很强，但不是很容易修改，对于
大的、复杂的项目也很难表示出项目的全景。
由于其直观性，一般在一些中小型的应用
项目中用得较多。
大型的项目要分解为多个子项目进行统一管理，大型项目的WBS要
首先分解为子项目，然后由各子项目进一步分解出自己的WBS。
（2）列表形式，类似于书籍的分级目录，最好是直观的缩进格式，如图7-2所示。
该表格能够反映出项目所有的工作要素，可是直观性较差。
常用在一些大的、复杂
的项目中，因为有些项目分解后，内容分类较多，容量较大，用缩进图表的形式表示比
较方便，也可以装订成册。
在项目管理工具软件中，也会采用列表形式的WBS。
7.4.3创建WBS的工具和技术
工作分解结构模板和分解技术为创建WBS提供了工具和技术。
但实际上，工作分
解结构模板更像是一个现成的工具，同时又可以作为分解技术的结果或一个组成部分。
其实，二者是相辅相成的，一个强调的是结果的使用，一个强调的是具体的过程。
1．分解
分解是将项目可交付物分成更小的、更易管理的单元，直到可交付物细分到足以支
持未来的、清晰定义项目活动的工作包（业内一般把一个人2周能干完的工作称为一个
工作包，或把一个人80小时能干完的工作称为一个工作包）。
依据分解得到的工作包能
够可靠地估计出成本和进度，工作包的详细程度取决于项目的规模和复杂程度。
把整个项目的工作分解为工作包，一般包括下列活动。
（1）识别和分析项目可交付物和与其相关的工作。
（2）构造和组织WBS。
（3）把高层的WBS工作分解为低层次的、详细的工作单元。
（4）为WBS的工作单元分配代码。
（5）确认工作分解的程度是必要和充分的。
把项目可交付物和项目工作构造组织成为WBS，进而满足项目管理团队的控制和管
理的需求，是一种好的分析方法。
在此过程中，如果有WBS模板，则尽可能地使用WBS
模扳。
分解WBS结构的方法至少有如下三种。
（1）使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层，
如圈7。
3所示。
（2）把项目重要的可交付物作为分解的第一层，如图7.4所示。
（3）把子项目安排在第一层，再分解子项目的WBS。
在进行项目工作分解的时候，一般遵从以下几个主要步骤：
（1）识别和确认项目的阶段和主要可交付物。
首先识别出项目生命期的各个阶段，
然后把每阶段的交付物明确和确认出来。
（2）分解并确认每一组成部分是否分解得足够详细。
一般来讲至少分解到可以合理
的对其进行成本和历时的估算为止。
（3）确认项目主要交付成果的组成要素。
交付成果的组成要素应当用有形的、可检
验的结果来描述，以便据此进行绩效评估。
（4）核实分解的正确性。
核对分解是否正确，可以通过回答下列问题来确定：
①最底层要素对项目分解来说是否是必需而且充分的呢？
如果不是，则必须修改
组成要素（例如添加、删除或重新定义）。
②每个组成要素的定义是否清晰完整？
如果不完整，则需要修改或扩展描述。
③每个组成要素是否都能够恰当地编制进度和预算？
是否能够分配到接受职责并
能够圆满完成这项工作的具体组织单元（例如部门、项目队伍或个人）?
如果不能，需
要做必要的修改，以保证合理的管理控制。
分解工作结构应把握如下原则：
（1）在各层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）-个工作单元只能从属于某个上层单元，避免变叉从属。
（3）相同层次的工作单元应有相同性质。
（4）工作单元应能分开不同的责任者和不同工作内容。
（5）便于项目管理进行计划和控制的管理需要。
（6）最低层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作（因为管理是项目具体工作的一部分），包括分包出去的
工作。
（8）WBS的最低层次的工作单元是工作包。
一个项目的WBS是否分解到工作包，
跟项目的阶段、复杂程度和规模有关，一般来说早期，或复杂，或大规模的项目，其
WBS的分解颗粒要大一些，粗一些。
以上总结得出在项目工作分解过程中应该把握的原则，但是这些只是比较重要的、
基础的原则，读者应该结合具体项目的实际情况来把握整个分解过程。
产生一个项目WBS的一个简便的方法是参考历史上同类项目的WBS或行业辨会等
组织给出的WBS模板，在此基础上根据现行项目的需要进行增删改，最终产生现行项
目的WBS（当然要经过评审和确认），也就是下面要讲的“工作分解结构模板法”。
2．工作分解结构模扳
以前项目的WBS常被当作新项目的模板。
虽然每个项目是不同的，但大多数的项
目是有相似之处的，所以WBS能时常被重复使用。
例如，在一个给定的组织里大部分
的项目都有相似的生命周期，从而每一个阶段需要提交相同或相似的可交付物。
许多应
用领域或项目执行组织都有标准的WBS楼板。
2001年，美国项目管理学会（PMI）出版了工作分解结构的试用标准《工作分解结
构的实践标准》，对工作分解结构的产生、开发和应用提供指导。
内容还包括一些能够适
用于特定工业领域的WBS示例。
3．WBS中工作包的格式
在项目管理工具软件Project2003中，工作包的形式之一像图7-2中的“项目范围规
划”，它包含的一项工作是“确定项目范围”。
“确定项目范围”的格式如图7-5所示。
图7。
5项日话动，任务的梏式示例
“确定项目范围”的编号是“2”，这个编号是由Project2003自动分配的。
4．滚动波式计划
分解WBS高层的组成单元时，需要把每个项目可交付物或子项目进一步分解为基
本单元，而这些WBS基本单元应该是可验证的产品、服务或者成果。
核实分解的正确
性时，要求确定低层的WBS单元对于相应高层的项目可交付物的完成是必要和充分的。
不同的项目可交付物可以有不同水平的分解。
为了分解到底层的工作包，有些项目可交
付物只需分解到下一层，而有些项目可交付物需要分解到多层。
当工作被分解到更低的、
更详细的层次时，有助于对这些工作的计划、管理和控制。
然而，过度的分解反而有害。
详细的分解对遥远的将来才能完成的交付物或子项目是不需要的，也是不可能的。
一般地，项目管理团队应该等待交付物或子项目足够清晰时才制订详细的WBS。
这种
技术有时被称作滚动波式计划。
滚动波式计划的实质是近期的工作计划得细一些，远期
的工作计划得相对粗一些。
7.4.4创建WBS的输入、输出
1．输入
范围定义后得到详细的范围说明书，基于此说明书创建工作分解结构。
创建工作分
解结构过程的输入包括以下内容。
（1）详细的项目范围说明书。
项目范围说明书详细描述了项目的可交付物以及产生这些可交付物所必须做的项
目工作，是分解WBS的依据。
详细介绍请参见7.3.3节。
（2）项目管理计划。
这里的项目管理计划，是到目前为止的最新版本的项目管理计划。
详细内容请参见
6.4.1节的介绍。
（3）纽织过程资产。
影H向创建WBS的组织过程资产包括（但不限）：
①关于WBS的政策、程序和样板。
②来自以前项目的项目文件。
③以前的项目经验教训。
2．输出
创建工作范围分解的主要结果就是WBS;在这个过程中，可能需要更新项目范围管
理计划。
因为实际的工作分解过程，也是对项目范围分解方法描述准确、清晰和合理与
否的一个验证过程，如果出现不一致，应该及时更正。
（1）WBS和WBS字典。
WBS描述的是可交付物及其具体内容，定义了整个项目的工作范围。
如果一个工作
不在WBS内，那么这个工作就会被排除在项目范围之外。
项目相关人员对完成的WBS
应该给予确认，并对
升级会员 