第5章 项目办法范围管理

第5章

项目范围管理

项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程。管理项目范围主要在于定义和控制哪些工作应包括在项目内，哪些不应包括在项目内。图5-1 概述了项目范围管理的各个过程，包括： 5.1 收集需求——为实现项目目标而定义并记录干系人的需求的过程。 5.2 定义范围——制定项目和产品详细描述的过程。

5.3 创建工作分解结构——将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。 5.4 核实范围——正式验收项目已完成的可交付成果的过程。

5.5 控制范围——监督项目和产品的范围状态、管理范围基准变更的过程。

上述过程不仅彼此相互作用，而且还与其他知识领域中的过程相互作用。基于项目的具体需要，每个过程都可能需要一人或多人的努力。每个过程在每个项目中至少进行一次，并可在项目的一个或多个阶段（如果项目被划分为多个阶段）中进行。虽然在本章中，各过程以界限线分明、相互的形式出现，但在实践中它们可能以本章未详述的方式相互交叠、相互作用。第3 章“项目管理过程”已对过程间的相互作用做了详细讨论。 在项目的环境中，“范围”这一术语有两种含义： ?? 产品范围——某项产品、服务或成果所具有的特性和功能。 ?? 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。 管理项目范围所需的各个过程及其工具与技术，因应用领域而异，并通常作为项目生命周期的一部分加以确定。经批准的详细项目范围说明书以及相应的工作分解结构、工作分解结构词典，构成项目的范围基准。然后，在整个项目生命周期中，对这个基准范围进行监督、核实和控制。在进行项目范围管理的5 个过程之前，项目管理团队应先进行规划工作，尽管本章未把该规划工作单独列为一个过程。该规划工作是制定项目管理计划过程（见4.2 节）的一部分，会产生一份范围管理计划，用来指导项目范围的定义、记录、核实、管理和控制。基于项目的需要，范围管理计划可以是正式或非正式的、非常详细或高度概括的。 根据项目管理计划（见4.2.3.1 节）来衡量项目范围是否完成，根据产品需求（见5.1 节）来衡量产品范围是否完成。项目范围管理各过程需要与其他知识领域中的过程整合起来，以确保项目工作能实现规定的产品范围。 5.1 收集需求 收集需求是为实现项目目标而定义并记录干系人的需求的过程。仔细掌握和管理项目需求与产品需求，对促进项目成功有重要作用。需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求，以便日后进行测量。收集需求旨在定义和管理客户期望。需求是工作分解结构的基础。成本、进度和质量规划也都要在这些需求的基础上进行。需求开发始于对项目章程（见4.1.3.1 节）和干系人登记册（见节）中相关信息的分析。许多组织把需求分为项目需求和产品需求。项目需求包括商业需求、项目管理需求、交付需求等。产品需求则包括技术需求、安全需求、性能需求等。

图 5-2 显示了收集需求过程的输入、工具与技术和输出，图5-3 概述了本过程的基本数据流向。

5.1.1 收集需求：输入

1．项目章程

可从项目章程中了解总体项目需求以及关于项目产品的总体描述，并据此制定详细的产品需求。项目章程已在4.1 节讨论。 2．干系人登记册

干系人登记册可用来识别那些能提供详细的项目和产品需求信息的干系人。干系人登记册将在10.1节讨论。

5.1.2 收集需求：工具与技术

1．访谈

欢迎阅读

访谈是一种通过与干系人直接交谈，来获得信息的正式或非正式方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。通常采取“一对一”的形式，但也可以有多个被访者和/或多个访问者共同参与。访谈有经验的项目参与者、干系人和主题专家，有助于识别和定义项目可交付成果的特征和功能。

2．焦点小组会议

焦点小组会议是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组会议往往比“一对一”的访谈更热烈。

3．引导式研讨会

通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一好处是，能够比单项会议更快地发现和解决问题。 例如，在软件开发行业，就有一种被称为“联合应用开发（或设计）（Joint Application Development，JAD）”的引导式研讨会。这种研讨会注重把用户和开发团队集中在一起，来改进软件开发过程。在制造行业，则使用“质量功能展开（Quality Function Deployment，QFD）”这种引导式研讨会，来帮助确定新产品的关键特征。QFD 从收集客户需求（又称“顾客声音”）开始，然后客观地对这些需求进行分类和排序，并为实现这些需求 而设置目标。 4．群体创新技术 可以组织一些群体活动来识别项目和产品需求。下面是一些常用的群体创新技术： ?? 头脑风暴法。用来产生和收集对项目需求与产品需求的多种创意的一种技术。 ?? 名义小组技术。通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用。 ?? 德尔菲技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。 ?? 概念/思维导图。把从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。 ?? 亲和图。这种技术可以将大量创意分类，以便审查和分析。 5．群体决策技术 群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。达成群体决策的方法很多，例如： ?? 一致同意。每个人都同意某个行动方案。 ?? 大多数原则。获得群体中50%以上的人的支持。 ?? 相对多数原则。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。 ?? 。某一个人为群体做出决策。 在需求收集过程中，几乎可采用上述任何一种决策方法进行群体决策。 6．问卷调查

问卷调查是指通过设计书面问题，向为数众多的受访者快速收集信息。如果受众众多、需要快速完成调查，并想要使用统计分析法，就适宜采用问卷和/或调查方法。 7．观察

观察是指直接观察个人在各自的环境中如何开展工作和实施流程。当产品使用者难以或不愿说明他们的需求时，就特别需要通过观察来了解细节。观察，也称为“工作跟踪”，通常由观察者从外部来观察使用者的工作。观察也可以由“参与观察者（Participant observer）”进行。“参与观察者”需要实际执行一个流程或程序，体验该流程或程序是如何实施的，以便挖掘出隐藏的要求。 8．原型法

欢迎阅读

原型法是指在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。原型是有形的实物，它使干系人有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。原型法符合渐进明细的理念，因为原型需要重复经过制作、试用、反馈、修改等过程。在经过足够的重复之后，就可以从原型中获得足够完整的需求，并进而进入设计或制造阶段。

5.1.3 收集需求：输出

1．需求文件

需求文件描述各种单一的需求将如何满足与项目相关的业务需求。一开始，可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。 需求文件的组成部分包括（但不限于）：

?? 业务需求或需抓住的机遇，描述当前局面的不足以及启动项目的原因； ?? 可跟踪的业务目标和项目目标； ?? 功能要求，描述业务流程、信息以及与产品的内在联系。可采用适当的方式，如写成文本式需求清单或制作出模型，也可以同时采用这两种方法； ?? 非功能性要求，如服务水平、绩效、安全、防护、合规性、保障能力、保留／清除等； ?? 质量要求； ?? 验收标准； ?? 体现组织指导原则的业务规则； ?? 对组织其他领域的影响，如呼叫中心、销售队伍、技术团队； ?? 对执行组织内部或外部团体的影响； ?? 对支持和培训的需求； ?? 与需求有关的假设条件和制约因素。 2．需求管理计划 需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。生命周期各阶段间的关系（见2.1.3.2 节）对如何管理需求有很大影响。项目经理必须为项目选择最有效的阶段间关系，并记录在需求管理计划中。需求管理计划的许多内容都是基于该种关系的。 需求管理计划的内容包括（但不限于）： ?? 如何规划、跟踪和汇报各种需求活动； ?? 配置管理活动，例如，如何启动产品、服务或成果的变更，如何分析其影响，如何进行跟踪和汇报，以及谁有权批准变更； ?? 需求排序过程； ?? 产品测量指标及使用这些指标的理由； ?? 需求跟踪结构，即：哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。 3．需求跟踪矩阵 需求跟踪矩阵是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪。需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值。它为人们在整个项目生命周期中跟踪需求提供了一种方法，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。最后，需求跟踪矩阵为管理产品范围变更提供了框架。 跟踪需求的过程包括（但不限于）：

?? 从需求到业务需要、机会、目的和目标； ?? 从需求到项目目标；

?? 从需求到项目范围／WBS 中的可交付成果； ?? 从需求到产品设计； ?? 从需求到产品开发；

?? 从需求到测试策略和测试脚本；

欢迎阅读

?? 从宏观需求到详细需求。

应在需求跟踪矩阵中记录各项需求的相关属性。这些属性有助于明确各项需求的关键信息。需求跟踪矩阵中的典型属性包括：独特的识别标志、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、现状（如活跃中、已取消、已推迟、新增加、已批准）和实现日期。为确保干系人满意，可能需增加的补充属性包括：稳定性、复杂程度和验收标准。

5.2 定义范围

定义范围是制定项目和产品详细描述的过程。详细项目范围说明书的编制，对项目成功至关重要。应该根据项目启动过程中记载的主要可交付成果、假设条件和制约因素，来编制项目范围说明书。在规划过程中，由于对项目有了更多的了解，所以应该更具体地定义与描述项目范围。应该分析现有风险、假设条件和制约因素的完整性，并在必要时补充其他的风险、假设条件和制约因素。图5-4 显示了定义范围过程的输入、工具与技术和输出，图5-5 概述了本过程的基本数据流向。 5.2.1 定义范围：输入 1．项目章程 项目章程中包含对项目和产品特征的概括性描述，以及项目审批要求。项目章程已在4.1.3.1 节中讨论。如果执行组织不使用项目章程，则应取得或编制类似的信息，并用做制定详细范围说明书的基础。 2．需求文件 见 5.1.3.1 节。 3．组织过程资产 可能影响定义范围过程的组织过程资产包括（但不限于）： ?? 用于制定项目范围说明书的、程序和模板； ?? 以往项目的项目档案； ?? 以往阶段或项目的经验教训。 5.2.2 定义范围：工具与技术 1．专家判断 专家判断常用来分析制定项目范围说明书所需的信息。专家判断和专业知识可用来处理各种技术细节。专家判断可来自具有专门知识或经过专门培训的任何小组或个人，可从许多渠道获得，包括： ?? 组织内的其他部门； ?? 顾问； ?? 干系人，包括客户和发起人； ?? 专业与技术协会； ?? 行业团体； ?? 主题专家。 2．产品分析 对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。每个应用领域都有一种或几种普遍公认的、把概括性的产品描述转变为有形的可交付成果的方法。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。 3．备选方案识别

备选方案识别是用来为项目工作提出不同执行方法的一种技术。许多通用管理技术都可用于备选方案识别，如头脑风暴、横向思维和配对比较等。 4．引导式研讨会 见 5.1.2.3 节。

5.2.3 定义范围：输出

1．项目范围说明书

项目范围说明书详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。项目范围说明书也表明项目干系人之间就项目范围所达成的共识。为了便于管理干系人的期望，项目范围说明书可明

欢迎阅读

确指出哪些工作不属于本项目范围。项目范围说明书使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作；它还为评价变更请求或额外工作是否超出项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容（可能直接列出或引用其他文件）：

?? 产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。 ?? 产品验收标准。定义已完成的产品、服务或成果的验收过程和标准。

?? 项目可交付成果。可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可详可简。

?? 项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。

?? 项目制约因素。列出并说明与项目范围有关、且项目团队选择的具体项目制约因素，例如，客户或执行组织事先确定的预算、强制性日期或强制性进度里程碑。如果项目是根据合同实施的，那么合同条款通常也是制约因素。有关制约因素的信息可以列入项目范围说明书，也可以成册。 ?? 项目假设条件。列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果。在项目规划过程中，项目团队应该经常识别、记录并验证假设条件。有关假设条件的信息可以列入项目范围说明书，也可以成册。 2．项目文件（更新） 可能需要更新的项目文件包括（但不限于）： ?? 干系人登记册； ?? 需求文件； ?? 需求跟踪矩阵。 5.3 创建工作分解结构 创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作（见图5-6 和图5-7）。 计划要完成的工作包含在工作分解结构底层的组成部分中，这些组成部分被称为“工作包”。可以针对工作包安排进度、估算成本和实施监控。在“工作分解结构”这个词中，“工作”是指经过努力所取得的成果，如工作产品或可交付成果，而非“努力”本身。图5-6 显示了创建工作分解结构过程的输入、工具与技术和输出，图5-7 概述了本过程的基本数据流向。可 参 考 《 工 作 分 解 结 构 实 践 标 准 》（ Practice Standard for Work Breakdown Structure）（第2 版）[1]*，了解关于工作分解结构的详细信息。 5.3.1 创建工作分解结构：输入 1．项目范围说明书 见 5.2.3.1 节。 2．需求文件 见 5.1.3.1 节。 3．组织过程资产

可能影响创建工作分解结构过程的组织过程资产包括（但不限于）： ?? 用于创建工作分解结构的、程序和模板； ?? 以往项目的项目档案； ?? 以往项目的经验教训。

5.3.2 创建工作分解结构：工具与技术

1．分解

分解就是把项目可交付成果划分为更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包的层次。工作包是工作分解结构的底层，是能够可靠地估算和管理工作成本和活动持续时间的位置。工

欢迎阅读

作包的详细程度因项目大小与复杂程度而异。要把整个项目工作分解成工作包，一般需开展下列活动： ?? 识别和分析可交付成果及相关工作； ?? 确定工作分解结构的结构与编排方法； ?? 自上而下逐层细化分解；

?? 为工作分解结构组成部分制定和分配标志编码； ?? 核实工作分解的程度是必要且充分的。

图 5-8 显示了某工作分解结构的一部分，其中若干分支已经向下分解到工作包层次。 工作分解结构可以采用多种形式，例如：

?? 把项目生命周期的各阶段作为分解的第一层，把产品和项目可交付成果放在第二层，如图5-9 所示； ?? 把主要可交付成果作为分解的第一层，如图 5-10 所示；

?? 按子项目进行第一层分解。子项目（如外包工作）可能由项目团队之外的组织实施。然后，作为外包工作的一部分，卖方需编制相应的合同工作分解结构。 对工作分解结构上层的组成部分进行分解，就是要把每个可交付成果或子项目都分解为基本的组成部分，即可核实的产品、服务或成果。工作分解结构可以采用列表式、组织结构图式、鱼骨图式或其他方式。通过确认工作分解结构下层的组成部分是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解一层，即可到达工作包的层次，而另一些则需分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下以及工作实施效率降低。 要在未来远期才完成的可交付成果或子项目，当前可能无法分解。项目管理团队通常要等到这些可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的相应细节。这种技术有时称做滚动式规划。工作分解结构包含了全部的产品和项目工作，包括项目管理工作。通过把工作分解结构底层的所有工作逐层向上汇总，来确保没有遗漏工作，也没有增加多余的工作。这有时被称为100%规则。 项目管理协会的《工作分解结构实践标准》（Practice Standard for Work Breakdown Structure）（第2 版），是创建、开发和应用工作分解结构的指南。该标准列举了一些具体行业的工作分解结构模板。可对这些模板进行“剪裁”，以便应用于特定应用领域的具体项目。 5.3.3 创建工作分解结构：输出 1．工作分解结构 工作分解结构是以可交付成果为导向的工作层级分解。其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。工作分解结构每向下分解一层，代表着对项目工作更详细的定义。为工作包建立控制账户，并根据“账户编码”分配标志号，是创建工作分解结构的最后步骤。这些标志号为汇总成本、进度与资源信息建立了层级结构。控制账户是一种管理控制点。在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。控制账户设置在工作分解结构中的特定管理节点上。每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户。 2．工作分解结构词典 工作分解结构词典是在创建工作分解结构过程中产生并用于支持工作分解结构的文件。工作分解结构词典对工作分解结构组成部分（包括工作包和控制账户）进行更详细的描述。工作分解结构词典的内容包括（但不限于）：

?? 账户编码标志号； ?? 工作描述； ?? 负责的组织；

?? 进度里程碑清单； ?? 相关的进度活动； ?? 所需的资源； ?? 成本估算； ?? 质量要求； ?? 验收标准；

欢迎阅读

?? 技术参考文献； ?? 合同信息。 3．范围基准

范围基准是项目管理计划的组成部分。范围基准包括： ?? 项目范围说明书。项目范围说明书包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。 ?? 工作分解结构。工作分解结构定义每一项可交付成果，并把可交付成果分解为工作包。

?? 工作分解结构词典。工作分解结构词典对每一个工作分解结构要素的工作和技术文件做详细说明。 4．项目文件（更新）

可能需要更新的项目文件包括（但不限于）需求文件。如果在创建工作分解结构过程中提交了变更请求并获得了批准，那么应当更新需求文件，以反映经批准的变更。

5.4 核实范围 核实范围是正式验收项目已完成的可交付成果的过程。核实范围包括与客户或发起人一起审查可交付成果，确保可交付成果已完成，并获得客户或发起人的正式验收。范围核实与质量控制的不同之处在于，范围核实主要关注对可交付成果的验收，而质量控制则主要关注可交付成果是否正确以及是否满足质量要求。质量控制通常先于范围核实进行，但二者也可同时进行。图5-11 显示了本过程的输入、工具与技术和输出，图5-12概述了本过程的基本数据流向。 5.4.1 核实范围：输入 1．项目管理计划 项目管理计划（见4.2.3.1 节）中包含范围基准。范围基准的组成部分包括： ?? 项目范围说明书。项目范围说明书包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。 ?? 工作分解结构。工作分解结构定义每一项可交付成果，并把可交付成果分解为工作包。 ?? 工作分解结构词典。工作分解结构词典对每一个工作分解结构要素的工作和技术文件做详细说明。 2．需求文件 需求文件列明了全部项目、产品和技术需求，以及项目和产品必须满足的其他需求，连同相应的验收标准。需求文件已在5.1.3.1 节讨论。 3．需求跟踪矩阵 需求跟踪矩阵（见5.1.3.3 节）连接需求和需求源，用于在整个项目生命周期中对需求进行跟踪。 4．确认的可交付成果 确认的可交付成果是指已经完成并经实施质量控制过程检验合格的可交付成果。 5.4.2 核实范围：工具与技术 1．检查

检查是指开展测量、审查与核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准。检查有时也被称为审查、产品审查、审计和巡检等。在某些应用领域，这些术语的含义比较狭隘和具体。

5.4.3 核实范围：输出 1．验收的可交付成果 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程（见4.6 节）。 2．变更请求

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案，并提出适当的变更请求，以便进行缺陷补救。变更请求应该由实施整体变更控制过程（见4.5 节）审查与处理。 3．项目文件（更新）

作为核实范围过程的结果，可能需要更新的项目文件包括定义产品或报告产品完成情况的任何文件。

5.5 控制范围

控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。对项目范围进行控制，就必须确保所

欢迎阅读

有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程（见4.5 节）的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。控制范围过程需要与其他控制过程整合在一起。未得到控制的变更通常被称为项目范围蔓延。变更不可避免，因而必须强制实施某种形式的变更控制。图5-13 显示了本过程的输入、工具与技术和输出，图5-14 概述了本过程的基本数据流向。

5.5.1 控制范围：输入

1．项目管理计划

项目管理计划（见 4.2.3.1 节）中包含以下可用来控制范围的信息：

?? 范围基准。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或采取预防措施。 ?? 范围管理计划。范围管理计划描述将如何管理和控制项目范围。 ?? 变更管理计划。变更管理计划定义管理项目变更的过程。

?? 配置管理计划。配置管理计划定义配置项，定义需要正式变更控制的内容，并为这些配置项和内容规定变更控制过程。 ?? 需求管理计划。需求管理计划说明如何规划、跟踪和报告需求活动，以及如何启动对产品、服务或成果需求的变更。需求管理计划还会说明将如何分析变更的影响以及谁有权批准这些变更。 2．工作绩效信息 工作绩效信息是关于项目进展情况的信息，如哪些可交付成果已开始，其进展如何，哪些可交付成果已完成等。

3．需求文件 见 5.1.3.1 节。 4．需求跟踪矩阵 见 5.1.3.3 节。 5．组织过程资产 可能影响控制范围过程的组织过程资产包括（但不限于）： ?? 现有的、正式和非正式的，与范围控制相关的、程序和指南； ?? 可用的监督和报告方法。 5.5.2 控制范围：工具与技术 1．偏差分析 可利用项目绩效测量结果，来评估偏离范围基准的程度。确定偏离范围基准（见5.3.3.3 节）的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。 5.5.3 控制范围：输出 1．工作绩效测量结果 工作绩效测量结果包括计划与实际技术性能的对比，或其他的范围绩效测量结果。这些信息需要记录下来并传递给相关干系人。 2．组织过程资产（更新） 可能需要更新的组织过程资产包括（但不限于）： ?? 造成偏差的原因； ?? 所选的纠正措施及其理由；

?? 从项目范围控制中得到的其他经验教训。 3．变更请求

通过范围绩效分析，可能会提出对范围基准或项目管理计划其他组成部分的变更请求。变更请求可包括预防措施、纠正措施或缺陷补救。变更请求需要由实施整体变更控制过程（见4.5 节）来审查和处理。 4．项目管理计划（更新）

?? 范围基准（更新）。如果批准的变更请求会对项目范围产生影响，那么范围说明书、工作分解结构及工作分解结构词典都需要重新修订和发布，以反映这些批准的变更。

?? 其他基准（更新）。如果批准的变更请求会对项目范围产生影响，那么相应的成本基准和进度基准也需要重新修订和发布，以反映这些批准的变更。

欢迎阅读

5．项目文件（更新）

可能需要更新的项目文件包括（但不限于）： ?? 需求文件； ?? 需求跟踪矩阵。