大纲
返回目录
第9章 项目范围管理项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目 。
9.1 管理基础 9.1.1 产品范围和项目范围在项目环境中，“范围”这一术语有两种含义:
产品范围: 指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。 “需求”是指根据特定协议或其他强制性规范，产品、服务或成果 必须具备的条件或能力 。
项目范围: 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。 项目范围的完成情况是根据项目管理计划来衡量的。
项目经理与商业分析师之间应该是伙伴式合作关系 。
9.2 项目范围管理过程 9.2.1 过程概述项目范围管理过程包括:
规划范围管理: 为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划 。
收集需求: 为了实现项目目标，确定 、 记录并管理干系人的需要和需求。
定义范围 : 制定项目和产品详细描述。
创建WBS: 将项目可交付成果和项目工作分解为较小的、更易于管理的组件。
确认范围 : 正式验收己完成的项目可交付成果。
控制范围 : 监督项目和产品的范围状态 ， 管理范围基准的变更。
裁剪时应考虑的因素包括:
知识和需求管理: 项目经理应建立哪些指南?为了在未来项目中重复使用需求，组织是 否拥有正式或非正式的知识和需求管理体系?
确认和控制: 组织是否有正式或非正式的与确认和控制相关政策、程序和指南?
开发方法: 组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
需求的稳定性: 项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?
治理: 组织是否拥有正式或非正式的审计和治理政策、程序和指南?
9.2.3 敏捷与适应方法敏捷方法有目的地构建和审查原型，并 通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。
在每次迭代中，都会重复开展三个过程:1收集需求:2定义范围:3创建 WBS。
在每次迭代中，都 会重复开展两个过程:1确认范围:2控制范围 。
9.3 规划范围管理规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计 划的过程。
本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向 。
本过程仅开展一次或仅在项目的预定义点开展。
1、项目章程
2、项目管理计划
规划范围管理中使用的项目管理计划组件主要包括:
质量管理计划: 在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产 品范围的方式。
项目生命周期描述: 定义了项目从开始到完成所经历的 一系列阶段。
开发方法: 开发方法定义了项目是采用预测型、适应型还是混合型开发方法 。
3、事业环境因素 能够影响规划范围管理过程的事业环境因素主要包括:组织文化、基础设施、人事管理制 度和市场条件等。
4、组织过程资产 能够影响规划范围管理过程的组织过程资产主要包括:政策和程序、历史信息和经验教训 知识库等 。
9.3.2 工具与技术专家判断
规划范围管理过程中，应征求具备如下领域相关专业知识或接受过相关培训的个人或小组 的意见，涉及的领域包括:以往类似项目:特定行业、学科和应用领域的信息等。 2. 数据分析
适用于本过程的数据分析技术是备选方案分析 。 备选方案分析技术用于评估、收集需求， 详述项目和产品范围，创造产品，确认范围和控制范围的各种方法 。
会议 项目团队可参加项目会议来制订范围管理计划 。参会者包括项目经理、项目发起人、选定 的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员 。
9.3.3 输出1 范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项 目范围 。
范围管理计划用于指导如下过程和相关工作:
制定项目范围说明书:
根据详细项 目范围说明书创建 WBS:
确定如何审批和维护范围基准:
正式验收己完成的项目可交付成果。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的 。
2 需求管理计划
需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。
需求管理计划的主要内容包括 :
如何规划、跟踪和报告各种需求活动;
配置管理活动， 例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限:
需求优先级排序过程 :
测量指标及使用这些指标的理由:
反映哪些需求属性将被列入跟踪矩阵等 。
9.4 收集需求收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程 。
本过程的主要作 用是为定义产品范围和项目范围奠定基础 。
本过程仅开展一次或仅在项目的预定义点开展。
1、立项管理文件
会影响收集需求过程的立项管理文件是商业论证产生的文件，它描述了为满足业务需要而 应该达到的必要、期望及可选标准。
2、项目章程 项目章程记录了项目概述以及将用于制定详细需求的高层级需求。
3、项目管理计划
范围管理计划:包含如何定义和制定项目范围的信息。
需求管理计划:包含如何收集、分析和记录项目需求的信息。
干系人参与计划 : 从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系 人对需求活动的参与程度。
4、项目文件
假设日志: 识别了有关产品、项 目、 环境、干系人以及会影响需求的其他因素的假设条件。
干系人登记册: 用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望 。
经验教训登记册: 提供了有效的需求收集技术，尤其针对使用敏捷或适应型产 品开发方法的项目 。
5、协议
协议会包含项目和产品需求 。
6、事业环境因素
会影响收集需求过程的事业环境因素主要包括:组织文化、基础设施、人事管 理制度 、市 场条件等 。
7、组织过程资产 会影响收集需求过程的组织过程资产主要包括:政策和程序:包含以往项目信息的历史信 息和经验教训知识库等 。
9.4.2 工具与技术1、专家判断
2、数据收集
头脑风暴: 是一种用来产生和收集对项 目需求与产品 需求的多种创意的技术 。
访谈: 是通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。 访谈经常是一个访谈者和一个 被访者之间的 “一对一”谈话， 但也可包括多个访谈者或多个被访者。 访谈有经验的项 目参与者、 发起人和其他高管及主题专家， 有助于识别和定义所需产品可交付成果的特 征和功能。 访谈也可用于获取机密信息。
焦点小组: 是召集预定的干系人和主题专家，了解他们对所讨论的产品、 服务或成果的 期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。 焦点小组往往比“一对一 ”的访谈更热烈 。
问卷调查: 是指设计一系列书面问题，向众多受访者快速收集信息。 问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的 情况。
标杆对照: 将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便 识别最佳实践，形成改进意见，并为绩效考核提供依据 。 标杆对照所采用的可比组织可 以是内部的，也可以是外部的 。
3、数据分析
可用于收集需求过程的数据分析技术是文件分析 。
文件分析指审核和评估任何相关的文件 信息。在此过程中 ， 文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求，可供分析井有助于获取需求的文件包括: 协议:商业计划;业务流程或接口文档;业务规则库;现行流程: 市场文献;问题日志;政策和程序、法规文件，如法律、准则、法令等:建议邀请书:用例等 。
4、决策
适用于收集需求过程的决策技术主要包括:
投票 : 是一种为达成某种期望结果 ，而对未来 多个行动方案进行评估的决策技术和过程 。 本技术用于生成、归类和排序产品需求 。
独裁型决策制定: 采用这种方法，将由 一个人负责为整个集体制定决策 。
多标准决策分析: 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序 。
5、数据表现
亲和图（KJ法）: 用来对大量创意进行分组的技术，以便进一步审查和分析 。
思维导图:把从头脑风暴中获得的创意整合成 一 张图，用以反映创意之间的共性与差异，激发新创意 。
6、人际关系与团队技能
名义小组技术: 是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。 名义小组技术是一种结构化的头脑风暴形式，由四个步 骤组成 :
提出问题：向集体提出一个问题或难题，每个人在沉思后写出自己的想法
记录想法：主持人在活动挂图上记录所有人的想法
达成共识：集体讨论各个想法，直到全体成员达成一个明确的共识
投票排序：个人私下投票决出各种想法的优先排序，通常采用 5分制， 1分最低， 5分最高 。 为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出 。
观察和交谈:是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程 。 当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作 细节 。 观察也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是 如何实施的，以便挖掘隐藏的需求 。
引导: 引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可 用于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点，有效引 导的研讨会有助于参与者之间建立信任、改进关系、改善沟通 ，从而有利于干系人达成 一致意见 。 此外 ， 与分别召开会议相比，研讨会能够更早发现并解决问题 。
7、系统交互图
系统交互图是对产品范围的可视化描绘，可以直观显示业务系统 (过程、设备、 计算机系 统等)及其与人和 其他系统(行动者)之间的交互方式 。
8 原型法
原型法是指在实际制造预期产品之前，先造出该产品的模型， 并据此征求对需求的早期反馈。 原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。 因为原型是有形的 实物，它使得干系人可以体验最终产 品的模型 ，而不是仅限于讨 论抽 象的 需求描述 。原型法支持渐进明细的理念， 需要经历从模型创建、 用户体验、 反馈收集到原型修改的反复循环过程。 在经过足够的反馈循环之后，就可以通过原型获得足够的 需求信息 ，从而进入设计或制造阶段。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。 故事板用于各 种行业的各种项目中，如电影、广告、教学设计以及敏捷和其他软件开发项目 。在软件开发中， 故事板使用实体模型来展示网页、 屏幕或其他用户界面的导航路径。
9.4.3 输出1、需求文件
需求文件描述各种单一需求将如何满足项目 相关的业务需求。一开始可能只有高层级的需求， 然后随着有关需求信息的增加而逐步细化。 只有明确的 (可测量和可测试的)、 可跟踪的、 完整的、相互协调的， 且主要干系人愿意认可的需求， 才能作为基准。需求文件的格式多种多 样，既可以是一份按干系人和优先级分类列出全部需求的简单文件， 也可以是一份包括 内容提 要、细节描述和附件等的详细文件。 许多组织把需求分为不同的种类，如业务解决方案和技术 解决方案。 前者是干系人的需要， 后者是指如何实现这些干系人需要的方案。 把需求分成不同 的类别， 有利于对需求进行进一步完善和细化。需求的类别一般包括:
业务需求: 整个组织的高层级需要，例如， 解决业务问题或抓住业务机会，以及实施 项目 的原因 。
干系人需求: 干系人的需要。
解决方案需求: 为满足业务需求和干系人需求， 产品、 服务或成果必须具备的特性、 功能和特征。解决方案需求又进一步分为功能需求和非功能需求:
功能需求: 描述产品应具 备的功能，例如， 产品应该执行的行动、 流程、数据和交互;
非功能需求: 是对功能需求的 补充， 是产品正常运行所需的环境条件或质量要求，例如， 可靠性、 保密性、 性能、安全性、 服务水平、可支持性、保留或清除等。
过渡和就绪需求:如数据转换和培训需求 。 这些需求描述了从“当前状态”过渡到 “将来状态”所需的临时能力。
项目需求 :项目 需要满足的行动 、过程或其他条件，例如 里程碑日期、合同责任、制 约因素等 。
质量需求:用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或 标准，例如，测试、认证、确认等 。
2、需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到 能满足需求的可交付成果的 一种表格。
使用需 求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价 值。
跟踪需求的内容包括:
业务需要、机会、目的和目标;
项目目标;
项目范围和 WBS 可交付成果;
产品设计:
产品开发;
测试策略和测试场景:
高层级需求 到详细需求等 。
定义范围是制定项目 和产品详细描述的过程。
本过程的主要作用是描述产品、服务或成果的边界和验收标准。
本过程需要在整个项目期间多次反复开展。
1、项目章程
项目章程中包含对项目的高层级描述、 产品特征和审批要求。
2、项目管理计划
范围管理计划
3、项目文件
假设日志: 识别了有关产品、 项目 、 环境、干系人以及会影响项目和产品范围的假设条 件和制约因 素。
需求文件: 识别了应纳入范围的 需求。
风险登记册: 包含了可能影响项目范围 的应对策略，例如缩小或改变项目和产 品范围 ， 以规避或缓解风险。
4、事业环境因素
会影响定义范围过程的事业环境因素主要包括:组织文化、基础设施、人事管理制度、市 场条件等 。
5、组织过程资产
能够影响定义范围过程的组织过程资产主要包括:用于制定项目范围说明书的政策、程序 和模板:以往项目的项目档案;以往阶段或项目的经验教训等 。
9.5.2 工具与技术1、专家判断 定义范围过程中，应征求具备类似项目的知识或经验的个人或小组的意见 。
2、数据分析 可用于定义范围过程的数据分析技术是备选方案分析 。 备选方案分析可用于评估实现项目 章程中所述的需求和目标的各种方法。
3、决策 可用于定义范围过程的决策技术是多标准决策分析。多标准决策分析是 一种借助决策矩阵 来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目 和产品范围 。
4、人际关系与团队技能 人际关系与团队技能的 一个典型示例是引导 。 在研讨会和座谈会中使用引导技能来协调具 有不同期望或不同专业知识的关键干系人，使他们就项目可交付成果以及项目和产品边界达成 跨职能的共识 。
5、产品分析 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答 ，以描述要交付产品的 用途、特征及其他方面 。
9.5.3 输出1、项目范围说明书
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了 整个范围，包括:项目和产品范围;详细描述了项目的可交付成果:代表项目干系人之间就项 目范围所达成的共识。为便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围 。 项目范围说明书帮助项目团队进行更详细的规划，在执行过程中指导项目团队工 作，并为评价变更请求或额外工作是否超过项目边界提供基准 。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目 范围的有效程度 。
详细的项目范围说明书包括内容有(直接列出或参引其他文件) :
产品范围描述: 逐步细化在项目 章程和需求文件中所述的产品、服务或成果特征 。
可交付成果: 为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成 果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件 。对可交付成 果的描述可略可详 。
验收标准 : 可交付成果通过验收前必须满足的 一系列条件 。
项目的除外责任: 识别排除在项目之外的内容。
项目章程和项目范围说明书异同：
它们的详细程度完全不同
项目章程包含高层级的信息，项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。
2、项目文件(更新)：
假设日志
需求文件
需求跟踪矩阵
干系人登记册
9.6 创建 WBS创建工作分解结构( WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组 件的过程 。 本过程的主要作用是为所要交付的内容提供架构 。 它仅开展 一 次或仅在项目的预定 义点开展。
工作包时WBS的最小单位
补充内容：
工作分解结构WBS
组织分解结构OBS
资金分解结构ABS
风险分解结构RBS
分解形式：
树状
文本
表格
9.6.1 输人1、项目管理计划
范围管理计划
2、项目文件
需求文件: 详细描述了各种单一需求如何满足项目的业务需要 。
项目范围说明书: 描述了需要实施的工作以及不包含在项目中的工作 。
3、事业环境因素 会影响创建 WBS 过程的事业环境因素包括项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料 。
4、组织过程资产
用于创建 WBS 的政策、程序和模板;
以往项目的项目档案;
以往项目的经验教训等 。
9.6.2 工具与技术1、专家判断
2、分解 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术 。
工作包是 WBS 最低层的工作
1 )分解活动（背诵）
要把整个项目工作分解为工作包，通常需要开展如下活动:
识别和分析可交付成果及相关工作
确定 WBS 的结构和编排方法
自上而下逐层细化分解
为 WBS 组成部分制定和分配标识编码
核实可交付成果分解的程度是否恰当
WBS 结构
WBS 的结构可以采用多种形式:
以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
以主要可交付成果作为分解的第二层
纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后， 作为外包工作的一部分，卖方须制定相应的合同WBS。
3 )注意事项
在分解的过程中，应该注意以下 8个方面:
WBS必须是面向可交付成果的: 项目的 目标是提供产品或服务， WBS中的各项工作是 为提供可交付的成果服务的。 WBS井没有明确地要求重复循环的工作，但为了达到里程 碑，有些工作可能要进行多次。最明显的例子是软件测试，软件必须经过 多 次测试后才 能作为可交付成果 。
WBS必须符合项目的范围: WBS必须包括也仅包括为了完成项目的可交付成果的活 动。 100%原则(包含原则)认为，在WBS中，所有下一级的元素之和必须100%代表上 一级的元素 。 如果WBS没有覆盖全部的项目可交付成果，那么最后提交的产品或服务是 无法让用户满意的 。 WBS的底层应该支持计划和控制: WBS是项目管理计划和项目范围之间的桥梁， WBS 的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。 WBS中的元素必须有人负责，而且只有 一个人负责:如果存在没有人负责的内容，那么 WBS发布后，项目团队成员将很少能够意识到自己和其中内容上的联系 。 WBS和责任 人可以使用工作责任矩阵来描述 。 在一些参考文献中，这个规定又称为独立责任原则 。 e WBS应控制在4~6层:如果项目规模比较大，以至于WBS要超过6层，此时，可以使用 项目分解结构将大项目分解成子项目，然后针对子项目来做 WBS 。每个级别的 WBS将 上一级的一个元素分为4~7个新元素，同 一级元素的大小应该相似。 一个工作单元只能 从属于某个上层单元，避免交叉从属 。 • WBS应包括项目管理工作(因为管理是项目具体工作的一部分〉，也要包括分包出去的 工作 。 • WBS的编制需要所有(主要)项目干系人的参与:各项目干系人站在自己的立场上，对 同一个项目可能编制出差别较大的 WBS。 项目经理应该组织他们进行讨论，以便编制出 一份大家都能接受的 WBS。 • WBS并非是一成不变的:在完成了WBS之后的工作中，仍然有可能需要对WBS进行修 改 。 如果没有合理的范围控制，仅仅依靠WBS会使得后面的工作僵化。
9.6.3 输出范围基准
范围基准是经过批准的范围说明书、 WBS 和相应的 WBS 词典 1 )项目范围说明书 项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述 。 2) WBS WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层 级分解 。 工作分解结构每向下分解 一层，代表对项目工作更详细的定义。 3 )工作包 WBS 的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇 总提供了层级结构，即账户编码。 每个工作包都是控制账户的一部分，而控制账户则是一个管 理控制点 。 在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效。控制 账户包含两个或更多工作包，每个工作包只与 一个控制账户关联 。 4 )规划包 进度活动未知， 一个控制账户可以包含 一个或多个规划包。 5) WBS 字典 WBS 字典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件 。 WBS 宇典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到宇典中 。 WBS 字典中的内容 一 般包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、 进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、 协议信息等 。
项目文件(更新) 可在创建 WBS 过程更新的项目文件主要包括: · 假设日志:随着创建WBS过程识别出更多假设条件或制约因素而更新。 · 需求文件 : 可以更新需求文件，以反映在创建WBS过程提出并己被批准的变更 。
9.7 确认范围确认范围是正式验收己完成的项目可交付成果的过程。本过程的主要作用 : 1使验收过程 具有客观性:2通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。确 认范围过程应根据需要在整个项目期间定期开展。
1、确认范围的步骤
确认范围应该贯穿项目的始终。 如果是在项目的各个阶段对项目 的范围进行确认工作 ，则 还要考虑如何通过项目协调来降低项目范围改变的频率，以保证项目 范围的改变是有效率和适 时的。
确认范围的一般步骤包括(背诵):
确定需要进行范围确认的时间:
识别范围确认需要哪些投入:
确定范围正式被接受的标准和要素:
确定范围确认会议的组织步骤;
组织范围确认会议。
先进行质量控制，再进行确认范围
质量控制: 关注可交付成果的正确性
确认范围: 关注可交付成果的验收
2、 需要检查的问题
可交付成果是否是确定的、可确认的 。
每个可交付成果是否有明确的里程碑， 里程碑是否有明确的、 可辨别的事件， 例如， 客 户的书面认可等 。
是否有明确的质量标准:可交付成果的交付不但要有明确的标准标志，而且要有是否按 照要求完成的标准，可交付成果和其标准之间是否有明确 联系。
审核和承诺是否有清晰的表达: 项目发起人必须正式同意项目 的边界，项目完成的产品 或者服务，以及项目相关的可交付成果。 项 目团队必须清楚地了解可交付成果是什么。 所有的这些表达必须清晰，并取得一致的同意。
项目范围是否覆盖了需要完成的产品或服务的所有活动， 有没有遗漏或错误。
项目范围的风险是否太高 : 管理层是否能够 降低风险发生时对项目 的影响 。
3、干系人关注点的不同
管理层主要关注项目范围
客户主要关注产品范围
项目管理人员主要关注项目制约因素
项目团队成员主要关注项目范围中自己参与的元素和负责的元素
9.7.1 输人1、项目管理计划
范围管理计划 : 定义了如何正式验收己经完成的可交付成果 。
需求管理计划 : 描述了如何确认项目需求 。
范围基准: 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或 预防措施 。
2、项目文件
需求文件: 将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防 措施 。
需求跟踪矩阵: 含有与需求相关的信息，包括如何确认需求 。
质量报告: 该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以 及在控制质量过程中发现的情况的概述 。 在验收产品之前，需要查看所有这些内容 。
经验教训登记册: 在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付 成果的效率与效果 。
3、 工作绩效数据
工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内 开展确认的次数。
4、核实的可交付成果 核实的可交付成果是指己经完成，并被控制质量过程检查为正确的可交付成果 。
9.7.2 工具与技术1、检查
检查是指开展测 量 、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验 收标准 。 检查有时也被称为审查、 产 品审查和巡检等 。
2、决策
可用于确认范围过程的决策技术是投票，当由项目团队和其他干系人进行验收时，使用投 票来形成结论 。
9.7.3 输出1、验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里 获得正式文件，证明干系人对项目可交付成果的正式验收 。 这些文件将提交给结束项目或阶段 过程。
2、变更请求
对己经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案 。 可能 需要针对这些可交付成果提出变更请求，开展相应的缺陷补救工作 。 变更请求应该由实施整体 变更控制过程进行审查与处理 。
3、 工作绩效信息
工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以 及原因 。 这些信息应该被记录下来并传递给干系人 。
4、 项目文件(更新)
· 需求文件:记录实际的验收结果，更新需求文件 。 需要特别注意实际结果比原定需求更 好的情况，或者原定需求己经被放弃的情况 。 · 需求跟踪矩阵:根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用 结果。 · 经验教训登记册:更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战的 方法，以及良好的可交付成果验收的方法 。
9.8 控制范围控制范围是监督项目和产品的范围状态，管理范围基准变更的过程 。
本过程的主要作用是 在整个项目期间保持对范围基准的维护 。
本过程需要在整个项目期间开展 。
1、项目管理计划
范围管理计划: 记录了如何控制项目和产品范围 。
需求管理计划: 记录了如何 管理项目需求。
变更管理计划: 定义了 管理项目变更 的过程 。
配置管理计划: 定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配 置项的变更控制过程 。
范围基准: 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或 预防措施。
绩效测量基准: 使用挣值分析时，将绩效测 量基准与实际结果比较，以决定是否有必要 进行变更、采取纠正措施或预防措施 。
2、项目文件
需求文件 : 用于发现任何对商定的项目或产品范围的偏离 。
需求跟踪矩阵 : 有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还 可以提供受控需求的状态。
经验教训登记册 :
3、工作绩效数据
工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数量或者核实、确认和 完成的可交付成果的数 量。
4、组织过程资产 能够影响控制范围过程的组织过程资 产 主要包括:现有的、正式的和非正式的与范围控制 相关的政策、程序和指南;可用的监督和报告的方法与模板等 。
9.8.2 工具与技术数据分析
偏差分析: 用于将基准与实际结果进行比较，以确定偏 差 是否处于临界值区间内或是否 有必要采取纠正或预防措施 。
趋势分析: 旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在 恶化。确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施 ， 是项目范围控制的重要工作。
9.8.3 输出1、工作绩效信息
2、变更请求
3、项目管理计划(更新)
范围管理计划 : 更新范围管理计划 ， 以反映范围管理方式的变更 。
范围基准 : 在针对范围、范围说明书、 WBS或WBS词典的变更获得批准后， 需要对范 围基准做出相应的变更 。有 时范围偏 差 太过严重，以至于 需要修 订范围基准，以便为 绩 效测量提供现实可行的依据。
进度基准 : 在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应 的变更。 有时进度偏差太过严重，以至于需要修订进度基准， 以便为绩效测量提供现实 可行的依据 。
成本基准 : 在针对范围、资源或成本估算的变更获得批准后， 需要对成本基准做出相应 的变更。 有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实 可行的依据 。
绩效测量基准: 在针对范围、进度绩效或成本估算的变更获得批准后， 需要对绩效测量 基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基 准 ， 以便为绩效测 量提供现实可行的依据 。
4、项目文件(更新)
需求文件
需求跟踪矩阵
经验教训登记册
上次更新:
PagerPrevious page第8章 项目整合管理
Next page第10章 项目进度管理
