系统集成项目范围管理
在管理项目的范围之前，首先应收集客户等干系人的需求，并根据需求来定义并记 录产品的特征与功能，这一部分内容在第3章的“系统分析”中已经作过介绍。 范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项 目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。 项目范围的变化也叫变更。对项目范围的管理，是通过5个管理过程来实现的。 (l)编制范围管理计划；制定一个项目范围管理计划，以规定如何定义、检验、控 制范围，以及如何创建与定义工作分解结构。
(2)范围定义：这个过程给出关于项目和产品的详细描述。这些描述写在详细的项 目范围说明书里，作为将来项目决策的基础。
(3)创建工作分解结构：将项目的可交付成果和项目工作细分为更小的、更易于管 理的单元。在项目范围管理过程中，最常用工具就是工作分解结构(Work Breakdown 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)根据初步的项目范围说明书编制一个详细的项目范围说明书的方法。
(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.2 WBS的表示形式
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 中工作包的格式
在项目管理工具软件Project 2003中，工作包的形式之一像图7-2中的“项目范围规 划”，它包含的一项工作是“确定项目范围”。“确定项目范围”的格式如图7-5所示。 图7。5项日话动，任务的梏式示例
“确定项目范围”的编号是“2”，这个编号是由Project 2003自动分配的。
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 应该给予确认，并对此要达成共识。工作分解结构每细分一层就表示对项目要素更细致 的描述。
WBS 的最低层次通常是指工作包。WBS 的每一个工作包都应有唯一的标识，其标 识能够反映该工作包的成本等信息。
WBS 中包含的元素（包括工作包）细节通常在工作分解结构字典中加以描述。WBS 字典是WBS 的配套文档，用来描述每个WBS 元素。对每一个WBS 元素，应该说明如 下内容：
①编号。
②名称。
③工作说明。
④相关活动列袁。
⑤里程碑列表。
@承办组织。
⑦开始和结束日期。
@资源需求、成本估算、负载量。
@规格。
@合同信息。
Ol 质量要求和有关工作质量的技术参考资料。
除WBS 外，还有一些其他的分解结构，包括以下内容。
①组织分解结构：提供项目组织的层次化描述，使得工作包同组织执行单元相关 联。它用于显示各个工作元素由哪个组织单元负责。
②物料清单：表述用于加工一个产品所需的子部件的一个列表。
@风险分解结构：是关于已识别的项目风险的层次化描述，这些风险按风险类别 排列。
(2)范围基准。
被批准的详细的项目范围说明书和其相关的WBS 以及WBS 词典是项目的范围基 准。范围基准是项目管理计划的一个组成部分。
(3)更新的项目管理计划。
如果在创建WBS 过程中，出现的变更请求被批准，那么项目干系人需求文档需要 更新，以包括被批准的变更。可能被更新的项目文件包括（但不限于）：
①项目干系入需求文档。
②项目管理计划。
7.4.5范围基准
项目范围说明书、与之联系的WBS 以及WBS 字典作为项目的范围基准，在整个项 目的生命期，这个范围基准被监控、核实和确认。
一般地说，客户等项目干系人是在项目的交付物这个层次上提出范围变更，而项目 范围说明书正是详细地描述项目交付物的。项目管理团队遵循变更控制流程，在变更控 制委员会批准的情况下，对得到批准的项目交付物进行变更，通过对比变更前后项目的 WBS ，可以具体地评估变更对项目的进度、成本和质量等带来的影响，并制订相应的变 更措施。
7.5范围确认
范围确认是客户等项目干系人正式验收并接受已完成的项目可交付物的过程。也称 范围确认过程为范围核实过程。项目范围确认包括审查项目可交付物以保证每一交付物 令人满意地完成。如果项目在早期被终止，项目范围确认过程将记录其完成的情况。 项目范围确认应该贯穿项目的始终。范围确认与质量控制不同，范围确认是有关工 作结果的接受问题，而质量控制是有关工作结果正确与否，质量控制一般在范围确认之 前完成，当然也可并行进行。
7.5.1范围确认的工具和技术
检查包括诸如测量、测试和验证以确定工作和可交付物是否满足要求和产品的验收 标准。检查有时被称为审查、产品评审、审计和走查。在一些应用领域中，这些不同的 条款有其具体的、特定的含意。
确认项目范围时，项目管理团队必须向客户方出示能够明确说明项目（或项目阶段） 成果的文件，如项目管理文件（计划、控制，沟通等）、需求说明书、技术文件、竣工图 纸等。当然，提交的验收文件应该是客户已经认可了的这个项目产品或某个阶段的文件， 他们必须为完成这项工作准备条件，做出努力。
范围确认完成时，同时应当对确认中调整的WBS 及WBS 字典进行更新。
7.5.2范围确认的输入、输出
1．输入
(1)项目管理计划。
用于范围确认的项目管理计划的组成部分包括如下的范围基准：
①项目范围说明书。项目范围说明书包括产品范围描述、项目可交付物、验收标 准。关于项目范围说明书的详细描述请参见7.3.3节。
②WBS 。WBS 定义了项目的每一个可交付物以及可交付物到工作包的分解。
③WBS 词典。WBS 词典有项目工作以及每个WBS 元素的详细说明。WBS 和WBS 字典用于定义范围以及确认项目进行中的工作成果是不是项目的一部分。
(2)可交付物。
可交付物是那些已经被完全或部分完成的项目部分，并且已经过质量控制过程检验 了其正确性。
2．输出
(l)可接受的项目可交付物和工作。
范围确认过程记录那些已完成的、已被正式接受（验收）的项目可交付物。还要记 录那些已完成尚未被正式接受的项目可交付物，以及不被接受的原因。范围核实还包括 这样的支持文档：客户或者赞助者等项目干系人承诺接受的项目可交付物。
(2)变更申请。
范围确认过程中产生的变更申请，一般包括对缺陷的修复要求。变更申请要经过整 体变更控制过程及变更控制委员会的受理、评审和可能的部署。
(3)更新的WBS 和WBS 字典。
WBS 和WBS 字典帮助定义范围，依据范围确认过程的结果要进行相应的更新。
7.6范围控制
范围控制是监控项目状态如项目的工作范围状态和产品范围状态的过程，也是控制 变更的过程。控制项目范围以确保所有请求的变更和推荐的纠正行动，都要通过整体变 更控制过程处理。当变更发生并且集成到其他控制过程对，项目范围控制也被用来管理 实际的变更。经常把不受控制的变更称作为项目“范围蔓延”。变更是不可避免的，进而 需要某种类型的变更控制过程。
变更是项目干系人常常由于项目环境或者是其弛的各种原因要求对项目的范围基 准进行修改，甚至是重新计划，而这一类修改或变化就叫做变更。
范围控制涉及以下内容：影响导致范围变更的因素，确保所有被请求的变更按照项 目整体变更控制过程娃理，范围变更发生时管理实际的变更。范围控制还要与其他控制 过程相结合。
1．变更产生的原因
项目管理者必须对变更进行控制。造成项目范围变更的主要原因如下。
①项目外部环境发生变化，例如，政府政策的问题。
@项目范围的计划编制不周密详细，有一定的错误或遗漏。
③市场上出现了或是设计人员提出了新技术、新手段或新方案。
④项目实施组织本身发生变化。
⑤客户对项目、项目产品或服务的要求发生变化。
2．变更控制的焦点问题
许多情况下，项目管理者在进行范围变更控制时，更关心的问题如下。
①确定范围变更是否已经发生。
②对造成范围变更的因素施加影响，以确保这些变更得到一致的认可。
③当范围变更发生时，对实际的变更进行管理。
7.6.1范围控制的工具和技术
1．偏差分析
根据范围基准，测量到的项目绩效如实际完成的项目范围被用来评估变更的程度。 项目范围控制的重要一点是确定有关变更的原因、确定是否需要纠正行动。
2．重新制订计划
已批准了的变更申请影响项目范围（见表7-1），因而要修改WBS 和WBS 词典、 项目范围说明书，甚至项目干系人的需求文档。这些批准了的变更申请可以触发项目管 理计划的更新。
3．变更控制系统和变更控制委员会
范围变更控制的方法是定义范围变更的有关流程。它包括必要的书面文件（如变更
申请单）、纠正行动、跟踪系统和授权变更的批准等级。变更控制系统与其他系统相结合， 如配置管理系统，来控制项目范围。当项目受合同约束时，变更控制系统应当符合所有 相关合同条款。
由变更控制委员会负责枇准或者拒绝变更申请。
变更控制流程及变更控制委员会的组成是灵活的，在项目管理中，可以根据具体情 况设立不同的控制点，有些没有必要通过流程解决的变更，可以授权现场实施负责人或 团队成员完成，但有些项目范围的变更，如直接关系到项目成本增加和进度延误的变更， 一定要通过变更控制系统来解决。
一般在项目范围管理计划中描述变更控制系统和变更控制委员会。如无项目范围管 理计划文档，则直接在项目管理计划中描述变更控制系统和变更控制委员会。
4．配置管理系统
范围变更将带来一系列项目交付物、文档的系统变化。这一切需要正规的配置管理 系统对此加以管理。
7.6.2范围控制的输入、输出
1．输入
(1)项目管理计划。
项目管理计划用来控制范围的下列信息。
①范围基准。范围基准用来与项目的实际结果相比较，以确定是否确实需要一种 变更、„纠正的行动或者预防性的行动。
@变更管理计划。变更管理计划定义了管理项目变更的过程。
@配置管理计划。配置管理计划定义了配置项以及有关配置项变更的正式变更控 制过程。
(2)工作绩效数据。
收集项目进展的数据包括项目可交付物的开始时间、进展和完成时间。
(3)绩效报告。
绩效报告提供项目绩效信息，如已经完成的中间可交付成果。
绩效报告是直接可以反应当前项目执行情况的文件，可以从项目范围相关的绩效报 告中获得范围绩效的信息，以此来作为项目变更控制的一个依据，例如，中间产品（或 服务）已经完成、哪些还没有完成、关注工作的当前执行情况等。同时，绩教报告也能
提醒项目团队预测项目的未来，把握项目范围变更控制的风险。
(4)已批准的变更请求。
范围变更是对达成一致的、WBS 中定义的项目范围的修改。已经接受的范围变更经 常需要调整成本、进度、质量以及其他项目管理目标。
2．输出 ‟
范围控制的输出结果如下。
(l)变更请求。
范围控制的结果也可能产生变更请求，变更请求是对已被认可的WBS 所确定的项 目范围的修改。范围变更经常导致对成本、进度、质量和其他项目管理目标进行调整。 变更的处理要依据项目整体变更控制过程进行处理。
(2)工作绩效。
分析工作绩效数据用以评估和度量项目的进展。这些度量用于计划数据与实际绩效 的对比，其比较的结果是绩效报告的一个输入。
(3)组织过程资产更新。
可能被更新的组织过程资产包括（但不限于）：
①偏差的原因。
②选择的纠正行动和理由。
③其他的从项目范围变更控制过程吸取的经验教训。
(4)更新的项目管理计划。
由于变更，相应的基准文档要进行修改并重新发布，例如：
①范围基准更新。如果批准的变更申请对项目范围有影响，那么范围说明书、WBS 、 WBS 词典被修订并且重新发布以反映批准的变更。这些修订后的、最新的文件成为新的 项目范围基准。
②其他基准更新。如果批准的变更申请对项目范围有影响，那么相应的成本基准 和进度基准也要被修订，并且重新发布以反映批准的变更。
对项目管理计划和它的分计划的变更申请都要通过整体变更控制进行处理。
系统集成项目范围管理
在管理项目的范围之前，首先应收集客户等干系人的需求，并根据需求来定义并记 录产品的特征与功能，这一部分内容在第3章的“系统分析”中已经作过介绍。 范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项 目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。 项目范围的变化也叫变更。对项目范围的管理，是通过5个管理过程来实现的。 (l)编制范围管理计划；制定一个项目范围管理计划，以规定如何定义、检验、控 制范围，以及如何创建与定义工作分解结构。
(2)范围定义：这个过程给出关于项目和产品的详细描述。这些描述写在详细的项 目范围说明书里，作为将来项目决策的基础。
(3)创建工作分解结构：将项目的可交付成果和项目工作细分为更小的、更易于管 理的单元。在项目范围管理过程中，最常用工具就是工作分解结构(Work Breakdown 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)根据初步的项目范围说明书编制一个详细的项目范围说明书的方法。
(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.2 WBS的表示形式
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 中工作包的格式
在项目管理工具软件Project 2003中，工作包的形式之一像图7-2中的“项目范围规 划”，它包含的一项工作是“确定项目范围”。“确定项目范围”的格式如图7-5所示。 图7。5项日话动，任务的梏式示例
“确定项目范围”的编号是“2”，这个编号是由Project 2003自动分配的。
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 应该给予确认，并对此要达成共识。工作分解结构每细分一层就表示对项目要素更细致 的描述。
WBS 的最低层次通常是指工作包。WBS 的每一个工作包都应有唯一的标识，其标 识能够反映该工作包的成本等信息。
WBS 中包含的元素（包括工作包）细节通常在工作分解结构字典中加以描述。WBS 字典是WBS 的配套文档，用来描述每个WBS 元素。对每一个WBS 元素，应该说明如 下内容：
①编号。
②名称。
③工作说明。
④相关活动列袁。
⑤里程碑列表。
@承办组织。
⑦开始和结束日期。
@资源需求、成本估算、负载量。
@规格。
@合同信息。
Ol 质量要求和有关工作质量的技术参考资料。
除WBS 外，还有一些其他的分解结构，包括以下内容。
①组织分解结构：提供项目组织的层次化描述，使得工作包同组织执行单元相关 联。它用于显示各个工作元素由哪个组织单元负责。
②物料清单：表述用于加工一个产品所需的子部件的一个列表。
@风险分解结构：是关于已识别的项目风险的层次化描述，这些风险按风险类别 排列。
(2)范围基准。
被批准的详细的项目范围说明书和其相关的WBS 以及WBS 词典是项目的范围基 准。范围基准是项目管理计划的一个组成部分。
(3)更新的项目管理计划。
如果在创建WBS 过程中，出现的变更请求被批准，那么项目干系人需求文档需要 更新，以包括被批准的变更。可能被更新的项目文件包括（但不限于）：
①项目干系入需求文档。
②项目管理计划。
7.4.5范围基准
项目范围说明书、与之联系的WBS 以及WBS 字典作为项目的范围基准，在整个项 目的生命期，这个范围基准被监控、核实和确认。
一般地说，客户等项目干系人是在项目的交付物这个层次上提出范围变更，而项目 范围说明书正是详细地描述项目交付物的。项目管理团队遵循变更控制流程，在变更控 制委员会批准的情况下，对得到批准的项目交付物进行变更，通过对比变更前后项目的 WBS ，可以具体地评估变更对项目的进度、成本和质量等带来的影响，并制订相应的变 更措施。
7.5范围确认
范围确认是客户等项目干系人正式验收并接受已完成的项目可交付物的过程。也称 范围确认过程为范围核实过程。项目范围确认包括审查项目可交付物以保证每一交付物 令人满意地完成。如果项目在早期被终止，项目范围确认过程将记录其完成的情况。 项目范围确认应该贯穿项目的始终。范围确认与质量控制不同，范围确认是有关工 作结果的接受问题，而质量控制是有关工作结果正确与否，质量控制一般在范围确认之 前完成，当然也可并行进行。
7.5.1范围确认的工具和技术
检查包括诸如测量、测试和验证以确定工作和可交付物是否满足要求和产品的验收 标准。检查有时被称为审查、产品评审、审计和走查。在一些应用领域中，这些不同的 条款有其具体的、特定的含意。
确认项目范围时，项目管理团队必须向客户方出示能够明确说明项目（或项目阶段） 成果的文件，如项目管理文件（计划、控制，沟通等）、需求说明书、技术文件、竣工图 纸等。当然，提交的验收文件应该是客户已经认可了的这个项目产品或某个阶段的文件， 他们必须为完成这项工作准备条件，做出努力。
范围确认完成时，同时应当对确认中调整的WBS 及WBS 字典进行更新。
7.5.2范围确认的输入、输出
1．输入
(1)项目管理计划。
用于范围确认的项目管理计划的组成部分包括如下的范围基准：
①项目范围说明书。项目范围说明书包括产品范围描述、项目可交付物、验收标 准。关于项目范围说明书的详细描述请参见7.3.3节。
②WBS 。WBS 定义了项目的每一个可交付物以及可交付物到工作包的分解。
③WBS 词典。WBS 词典有项目工作以及每个WBS 元素的详细说明。WBS 和WBS 字典用于定义范围以及确认项目进行中的工作成果是不是项目的一部分。
(2)可交付物。
可交付物是那些已经被完全或部分完成的项目部分，并且已经过质量控制过程检验 了其正确性。
2．输出
(l)可接受的项目可交付物和工作。
范围确认过程记录那些已完成的、已被正式接受（验收）的项目可交付物。还要记 录那些已完成尚未被正式接受的项目可交付物，以及不被接受的原因。范围核实还包括 这样的支持文档：客户或者赞助者等项目干系人承诺接受的项目可交付物。
(2)变更申请。
范围确认过程中产生的变更申请，一般包括对缺陷的修复要求。变更申请要经过整 体变更控制过程及变更控制委员会的受理、评审和可能的部署。
(3)更新的WBS 和WBS 字典。
WBS 和WBS 字典帮助定义范围，依据范围确认过程的结果要进行相应的更新。
7.6范围控制
范围控制是监控项目状态如项目的工作范围状态和产品范围状态的过程，也是控制 变更的过程。控制项目范围以确保所有请求的变更和推荐的纠正行动，都要通过整体变 更控制过程处理。当变更发生并且集成到其他控制过程对，项目范围控制也被用来管理 实际的变更。经常把不受控制的变更称作为项目“范围蔓延”。变更是不可避免的，进而 需要某种类型的变更控制过程。
变更是项目干系人常常由于项目环境或者是其弛的各种原因要求对项目的范围基 准进行修改，甚至是重新计划，而这一类修改或变化就叫做变更。
范围控制涉及以下内容：影响导致范围变更的因素，确保所有被请求的变更按照项 目整体变更控制过程娃理，范围变更发生时管理实际的变更。范围控制还要与其他控制 过程相结合。
1．变更产生的原因
项目管理者必须对变更进行控制。造成项目范围变更的主要原因如下。
①项目外部环境发生变化，例如，政府政策的问题。
@项目范围的计划编制不周密详细，有一定的错误或遗漏。
③市场上出现了或是设计人员提出了新技术、新手段或新方案。
④项目实施组织本身发生变化。
⑤客户对项目、项目产品或服务的要求发生变化。
2．变更控制的焦点问题
许多情况下，项目管理者在进行范围变更控制时，更关心的问题如下。
①确定范围变更是否已经发生。
②对造成范围变更的因素施加影响，以确保这些变更得到一致的认可。
③当范围变更发生时，对实际的变更进行管理。
7.6.1范围控制的工具和技术
1．偏差分析
根据范围基准，测量到的项目绩效如实际完成的项目范围被用来评估变更的程度。 项目范围控制的重要一点是确定有关变更的原因、确定是否需要纠正行动。
2．重新制订计划
已批准了的变更申请影响项目范围（见表7-1），因而要修改WBS 和WBS 词典、 项目范围说明书，甚至项目干系人的需求文档。这些批准了的变更申请可以触发项目管 理计划的更新。
3．变更控制系统和变更控制委员会
范围变更控制的方法是定义范围变更的有关流程。它包括必要的书面文件（如变更
申请单）、纠正行动、跟踪系统和授权变更的批准等级。变更控制系统与其他系统相结合， 如配置管理系统，来控制项目范围。当项目受合同约束时，变更控制系统应当符合所有 相关合同条款。
由变更控制委员会负责枇准或者拒绝变更申请。
变更控制流程及变更控制委员会的组成是灵活的，在项目管理中，可以根据具体情 况设立不同的控制点，有些没有必要通过流程解决的变更，可以授权现场实施负责人或 团队成员完成，但有些项目范围的变更，如直接关系到项目成本增加和进度延误的变更， 一定要通过变更控制系统来解决。
一般在项目范围管理计划中描述变更控制系统和变更控制委员会。如无项目范围管 理计划文档，则直接在项目管理计划中描述变更控制系统和变更控制委员会。
4．配置管理系统
范围变更将带来一系列项目交付物、文档的系统变化。这一切需要正规的配置管理 系统对此加以管理。
7.6.2范围控制的输入、输出
1．输入
(1)项目管理计划。
项目管理计划用来控制范围的下列信息。
①范围基准。范围基准用来与项目的实际结果相比较，以确定是否确实需要一种 变更、„纠正的行动或者预防性的行动。
@变更管理计划。变更管理计划定义了管理项目变更的过程。
@配置管理计划。配置管理计划定义了配置项以及有关配置项变更的正式变更控 制过程。
(2)工作绩效数据。
收集项目进展的数据包括项目可交付物的开始时间、进展和完成时间。
(3)绩效报告。
绩效报告提供项目绩效信息，如已经完成的中间可交付成果。
绩效报告是直接可以反应当前项目执行情况的文件，可以从项目范围相关的绩效报 告中获得范围绩效的信息，以此来作为项目变更控制的一个依据，例如，中间产品（或 服务）已经完成、哪些还没有完成、关注工作的当前执行情况等。同时，绩教报告也能
提醒项目团队预测项目的未来，把握项目范围变更控制的风险。
(4)已批准的变更请求。
范围变更是对达成一致的、WBS 中定义的项目范围的修改。已经接受的范围变更经 常需要调整成本、进度、质量以及其他项目管理目标。
2．输出 ‟
范围控制的输出结果如下。
(l)变更请求。
范围控制的结果也可能产生变更请求，变更请求是对已被认可的WBS 所确定的项 目范围的修改。范围变更经常导致对成本、进度、质量和其他项目管理目标进行调整。 变更的处理要依据项目整体变更控制过程进行处理。
(2)工作绩效。
分析工作绩效数据用以评估和度量项目的进展。这些度量用于计划数据与实际绩效 的对比，其比较的结果是绩效报告的一个输入。
(3)组织过程资产更新。
可能被更新的组织过程资产包括（但不限于）：
①偏差的原因。
②选择的纠正行动和理由。
③其他的从项目范围变更控制过程吸取的经验教训。
(4)更新的项目管理计划。
由于变更，相应的基准文档要进行修改并重新发布，例如：
①范围基准更新。如果批准的变更申请对项目范围有影响，那么范围说明书、WBS 、 WBS 词典被修订并且重新发布以反映批准的变更。这些修订后的、最新的文件成为新的 项目范围基准。
②其他基准更新。如果批准的变更申请对项目范围有影响，那么相应的成本基准 和进度基准也要被修订，并且重新发布以反映批准的变更。
对项目管理计划和它的分计划的变更申请都要通过整体变更控制进行处理。