《系统集成项目管理》第七章 项目范围管理_收集需求过程的输入

一、项目范围管理概念

1、项目范围管理的含义及作用

项目范围管理：包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。

• 关注的焦点是：为项目工作明确划定边界。即什么是包括在项目之内的，什么是不包括在项目之内的。
  • 因某种原因，要改变项目的工作边界时，项目范围管理会提供一套规范的方法去处理范围变更。
• 项目范围是项目其他各方面管理的基础，若范围不清，成本、进度和质量等无从谈起。
• 重要性：
  • （1）清楚了项目的工作具体范围和具体工作内容，为提高成本、时间、资源估算的准确性提供了基础；
  • （2）项目范围既然是确定要完成哪些具体的工作，项目范围基准是确定项目进度测量和控制的基准。
  • （3）项目范围的确定就是确定了项目的具体工作任务，有助于清楚的责任划分和任务分配；

对项目范围管理和控制的有效性，是衡量项目是否达到成功的一个必要标准，项目范围的管理不仅仅是项目整体管理的一个主要部分，同时在项目中不断地重申项目工作范围，有利于项目不偏离轨道，是项目中实施控制管理的一个主要手段。

2、项目范围管理的主要过程

项目范围管理的主要过程：

1. 编制范围管理计划过程，对如何定义、确认和控制项目范围的过程进行描述；
2. 收集需求，为实现项目目标，明确并记录项目干系人的相关需求的过程；
3. 定义范围，详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础；
4. 创建工作分解结构，把整个项目工作分解成较小的、易于管理的组成部分，形成一个自下而上的分解结构；
5. 确认范围，正式验收已完成的可交付成果；
6. 范围控制，监督项目和产品的范围状态、管理范围基准变更。

二、编制范围管理计划和范围说明书

编制范围管理计划：是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。

• 编制范围管理计划和细化项目范围始于对下列信息的分析：项目章程中的信息、项目管理计划中已批准的子计划等。
• 作用：有助于降低项目范围蔓延的风险。
  

1、编制项目范围管理计划过程的工具与技术

编制项目范围管理的工具与技术：

• 会议。与会人员可能包括项目经理、项目发起人、选定的团队成员、选定的干系人、范围管理各过程负责人以及其他必要人员。
• 专家判断。

2、编制范围管理计划过程的输入

编制项目范围管理的输入：

• 项目管理计划；
• 项目章程，项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书；
• 组织过程资产
• 事业环境因素

3、编制范围管理计划过程的输出

编制项目范围管理的输出：

（1）范围管理计划：是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。

• 作用：是制定项目管理计划过程和其他范围管理过程的主要依据。
• 根据项目需要，范围管理计划可以是正式的或非正式的，非常详细或高度概括的。
• 范围管理计划要对将用于下列工作的管理过程做出决定：
  • 制定详细项目范围说明书；
  • 根据详细项目范围说明书创建WBS；
  • 维护和批准工作分解结构（WBS）；
  • 正式验收已完成的项目可交付成果。
  • 处理对详细项目范围说明书或WBS的变更。该工作与实施整体变更控制过程直接相联。

（2）需求管理计划：是项目管理计划的组成部分，描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。

• 项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。需求管理计划的许多内容都是以阶段关系为基础的。
• 需求管理计划的主要内容至少包括：
  • 如何规划、跟踪和报告各种需求活动；
  • 配置管理活动，例如：如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。
  • 需求优先级排序过程；
  • 产品测量指标及使用这些指标的理由。
  • 用来反映哪些需求属性被列入跟踪矩阵的跟踪结构。
  • 收集需求过程。

三、收集需求

收集需求：是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。

• 主要作用：为定义和管理项目范围（包括产品范围）奠定基础。

1、收集需求过程的工具与技术

（1）访谈：访谈是通过与干系人直接交流来获取信息的 正式或非正式的方法。访谈经常是一个访谈者和一个被访谈者之间的“一对一”活动，但也可以包括多个访谈者或多个被访谈者。

（2）聚焦小组：聚焦小组是召集预订的干系人和专题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。

（3）引导式研讨会：引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见，此外，研讨会能够比单项会议更早发现问题、更快解决问题。

（4）群体创新技术：可以组织一些群体活动来识别项目和产品需求，常用的群体创新技术有：

• 头脑风暴法。一种用来产生和收集对项目需求与产品需求的多种创意的技术；
• 名义小组技术。用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或有限排序。
• 概念/思维导图。把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。
• 亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。
• 多标准决策分析。借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。

（5）群体决策技术：群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生产产品需求，并对产品需求进行归类和优先级排序，例如：

• 一致同意。每个人都同意某个行动方案。
• 大多数原则。获得群体超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策。
• 独裁。由某一个人为群体做出决策。

（6）问卷调查：问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分数，并且适合开展统计分析。

（7）观察：观察是指直接察看个人在各自的环境中如何执行工作（或任务）和实施过程。

（8）原型法：原型法是指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

（9）标杆对照： 标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

（10）系统交互图：系统交互图是范围模型的一个例子，它是对产品范围的可视化描述，显示业务系统及其他与人和其他系统（行动者）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

（11）文件分析：文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求。

2、收集需求过程的输入

收集需求过程的输入：

• 范围管理计划
• 需求管理计划
• 干系人管理计划
• 项目章程
• 干系人登记册

3、收集需求过程的输出

收集需求过程的输出

• 需求文件：描述各种单一需求如何满足与项目相关的业务需求；
• 需求跟踪矩阵：把产品需求从其来源连接到能满足的可交付成果的一种表格。
  • 作用：（1）把每个需求与业务目标或者项目目标联系起来，有助于确保每个需求都具有商业价值。（2）需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。（3）为管理产品范围变更提供了框架。
  • 内容：应在需求跟踪矩阵中记录每个需求的相关属性。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为保证干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

四、范围定义

1、范围定义

定义范围：从需求文件中选取最终的项目需求（由于在收集需求过程中识别出的所有需求未必都包含在项目中），然后制定出关于项目及其产品、服务或输出的详细描述。

• 主要作用：明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
• 范围迭代过程：
  • 准备好详细的项目范围说明书，对项目成功至关重要。应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程。
  • 在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再针对每一次迭代明确详细范围。通常，随着当前迭代的项目范围和可交付成果的进展，而详细规划下一次迭代的工作。
• 最重要的任务就是：详细定义项目的范围边界，范围边界是应该做的工作和不需要进行的工作分界线。
• 意义：定义范围可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果。

2、范围定义的输入

范围定义的输入：

• 范围管理计划，确定了制定、监督和控制项目范围的各种活动；
• 项目章程，包含对项目和产品特征的高层级描述、项目审批要求。
  • 如果执行组织不使用项目章程，则应取得或编制类型的信息，用做制定详细范围说明书的基础。
  • 如果组织不制定正式的项目章程，通常会进行非正式的分析，为后续的范围规划提供依据。
• 需求文件，描述各种单一需求将如何满足与项目相关的业务需求。一开始，可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
  • 需求文件的主要内容至少包括：
    • 业务需求，包括：可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则；
    • 干系人需求，包括：对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求；
    • 解决方案需求，包括：功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求、报告需求（可用文本记录或用模型展示解决方案需求，也可两者同时使用）；
    • 项目需求，例如服务水平、绩效、安全和合规性，以及验收标准。
    • 过渡需求；
    • 与需求相关的假设条件、依赖关系和制约因素。

3、范围定义的输出

范围定义的输出：

• 项目范围说明书
• 项目文件更新。可能需要更新的项目文件至少包括：干系人登记册、需求文件、需求跟踪矩阵。

4、范围定义的工具和技术

（1）产品分析。产品分析旨在弄清产品范围，并把对产品的要求转化成项目目标的要求（即有形的可交付成果）。

• 包括：产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
• 例如：一个IT系统可以划分为几个子系统，以及这些子系统之间如何交互，直接影响到项目团队如何实现这些子系统，即采用什么样的项目策略，从而影响到项目范围的定义。

（2）焦点小组。召集预订的干系人和主题专家（可以有6-10个被访者），了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。

（3）备选方案生成。备选方案生成是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的管理技术都可用于生成备选方案，如头脑风暴、横向思维、备选方案分析等。

（4）引导式研讨会：把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，研讨会能够比单项会议更早发现问题，更快解决问题。

• 其中，目标优化矩阵是项目管理中进行干系人收集需求调查的有效工具之一，它可以被设计成客户调查表或名义调查表来使用，而且可以大规模取样，涉及的人越多越好。

5、范围说明书

项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。=》明确指出哪些工作不属于本项目范围

• 项目范围说明书记录了整个范围，包括项目和产品范围。
• 项目范围说明书详细描述项目的可交付成果，以及创建这些可交付成果而必须开展的工作。

项目范围边界一定是闭合的，否则我们就不能判断某变更是对原项目范围的变更还是新添加的项目范围。

详细的范围说明书或引用的文档通常包含以下内容：

• 项目目标，包括衡量项目成功的可量化标准。
  • 项目可能具有多种业务、成本、进度、技术和质量上的目标。项目目标还可以包括成本、进度和质量方面的具体目标。
• 产品范围描述，描述了项目承诺交付的产品、服务或结果的特征。这种需求在早期比较粗略，而在后期随着产品特征逐步细化会更加详细。
• 项目需求，描述了项目承诺交付物要满足合同、标准、规范或其他强制性文档所必须具备的条件或能力。项目干系人分析把干系人的要求、期望翻译成项目需求，并进行排序。
• 项目边界：项目边界严格定义了项目内容包括什么和不包括什么，以防有的项目干系人假定某些产品或服务是项目中的一部分。
• 项目的可交付成果：在某一过程、阶段或项目完成时，产出的任何独特并可核实的产品、成果或服务。可交付成果也包括各种辅助成功，如项目管理报告和文件。
• 项目的制约因素。项目范围说明书的约束条件比项目章程中列出的约束条件更多且更详尽。需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件。
• 假设条件：与范围相关的假设条件，以及当这些条件不成立时对项目造成的影响。作为计划过程的一部分，项目团队要经常识别、记录和确认创设条件的有效性。在制定计划时，不需验证即可视为正确、真实或确定的因素就是假设。关于假设条件的信息可以列入项目范围说明书，也可以独立成册。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程序完全不同。

• 项目章程包含高层级的信息，而项目范围说明书则是对项目范围的详细概述。项目范围需要在项目过程中渐进明细。

五、创建工作分解结构（WBS）

1、创建工作分解结构概述

创建工作分解结构：是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

• 重要性：工作分解结构（WBS）是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构。如果没有工作分解结构，就谈不上项目的进度计划、成本计划、质量计划、人力资源计划和风险计划等。
• 主要作用：对所要交付的内容提供一个结构化的视图。
• 作用和意义：工作分解结构是后续管理工作的主要依据，是项目时间、成本、人力等管理工作的基础。因此从某种程度上讲，工作结构分解的过程，也就是为项目搭建管理骨架的过程。
  • 通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明和具体。使项目管理者和项目干系人如投资人或客户，都能通过WBS把握项目、了解和控制项目过程；
  • 保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在遗漏，进而保证了项目的完整性；
  • 通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实施项目目标；
  • 项目工作结构分解能够明确项目相关各方面的工作界面，便于责任划分和落实；
  • 最终工作分解结构，可以直接作为进度计划和控制的工具。
  • 为建立项目沟通管理提供依据，便于把握信息重点；
  • 是项目各分计划和控制措施制定的基础和主要依据。
  • 有助于防止需求和范围蔓延。

WBS包括的内容：WBS最低层的工作单元被称为工作包，是进行进度安排、成本估算和监控的基础。工作包对相关活动进行归类：

• 工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构当中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”。=》工作分解结构必须且只能包括100%的工作。
• 工作分解结构的编制需要所有项目干系人的参与，需要项目团队成员的参与 。
  • 各项目干系人站在自己的立场上，对同一个项目可能编制出差别较大的工作分解结构。项目经理应发挥“整合者”的作用。组织他们进行讨论，以便编制出一份大家都能接受的工作分解结构；
• 工作分解结构是逐层向下分解的。工作分解结构最高层的要素总是整个项目或分项目的最终成果。
  • 工作分解结构中每条分支分解层次不必相等。
  • 一般情况下，工作分解结构应控制在3~6层为宜。若项目比较大，以至于工作分解结构要超过6层，可以将大项目分解成子项目，然后对子项目做工作分解结构。

工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。

较常用的工作分解结构表示形式主要有以下两种：

• 分级的树型结构。
  • 
  • 特点：层次清晰，非常直观，结构性强，但是不容易修改，对大型的、复杂的项目也很难表示出项目的全景。
  • 适用性：一般在一些小的、适中的应用项目中用得较多。
• 表格形式
  • 
  • 
  • 该表能够反映出项目所有的工作要素，可是直观性较差。但在一些大型的、复杂的 项目中使用较多，因为有些项目分解后，内容分类较多、容量较大，用缩进图表的形式表示比较方便，也可装订为手册。
  • 特点：每层中的所有要素之和是下一层的工作之和；每个项目要素应该具体指派一个层次，而不应该指派给多个层次；工作分解结构需要有投入工作的范围描述，使项目团队成员及要完成的工作有全面的了解。

其他概念：

• 里程碑：标志着某个可交付成果或阶段的正式完成。里程碑和可交付成果密切联系在一起，但并不是一个概念。可交付成果可能包括报告、原型、成果和最终产品，而“里程碑=具体时间+在这个时间应完成的事件”，里程碑关注事件是否完成，例如：用户签署正式的认可文件等。工作分解结构中的任务有明确的开始时间和结束时间，任务的结果可以和预期的结果相比较。
  • 重要的检查点叫做里程碑；
  • 重要的里程碑叫做基线；
• 工作包：工作包是位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分。
  • 作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要9个小时来完成，而总完成时间也不应该大于80小时。
  • 在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识，这些标识为进行成本、进度与资源信息的层级汇总提供了层级结构。控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。控制账户设置在WBS中选定的管理节点上。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。需要生产一些配套的文件，这些文件需要和工作分解结构配合使用，称为工作分解结构词典，包括供工作分解结构组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单等等，还可能包括合同信息、质量要求、技术文献、计划活动、资源和成本估计等。
  • 判断：具有如下特征之一，就可能被当作工作包：
    • 规模较小，可以在短时间（80小时）完成；
    • 从逻辑上讲，不能再分了。
    • 所需资源、时间、成本等已经可以比较准确的估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制。
• WBS编码设计：通常利用编码技术对WBS进行信息交换，以现实简化WBS的信息交流过程。

2、WBS创建工作的工具与技术

WBS创建工作的工具与技术：

（1）分解。分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包。

• 通常需要开展以下活动：
  • 识别和分析可交付成果及相关工作。
  • 确定 WBS的结构和编排方法。
  • 自上而下逐层细化分解。
  • 为WBS组件制定和分配标识编码。
  • 核实可交付成果分解的程度是否恰当。
• 流程如下：
  • 
• 工作结构分解应把握如下原则：
  • 在层次上保持项目的完整性，避免遗漏必要的组成部分；
  • 一个工作单元只能从属于某个上层单元，避免交叉从属；
  • 相同层次的工作单元应用相同性质；
  • 工作单元应能分开不同的责任者和不同的工作内容；
  • 便于项目管理计划和项目控制的需要；
  • 最底层工作应该具有可比性，是可管理的，可定量检查的；
  • 应包括项目管理工作，包括分包出去的工作。

（2）专家判断：专家判断和专业知识可用来处理有关项目范围的各种技术细节，并协调各种不同的意见，以便用最好的方法对项目整体范围进行分解。

3、创建工作分解结构的输入

创建工作分解结构的输入：

• 项目范围管理计划。定义了应该如何根据详细项目说明书创建WBS，以及应该如何维护和批准WBS。
• 项目范围说明书。描述了需要实施的工作及不包含在项目中的工作，同时也列举和描述了会影响项目执行的各种内外部制约或限制条件。
• 需求文件。

4、创建工作分解结构的输出

创建工作分解结构的输出：

• 范围基准。经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典组成了范围基准，只有通过正式的变更控制程序才能进行变更这个基准，它被用作比较的基础。
  • 范围基准是项目管理计划的组成部分，包括:
    • 项目范围说明书。包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
    • WBS。
    • WBS词典。是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。WBS词典中的内容可能至少包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。
• 项目文件更新，可能需要更新的项目文件至少包括需求文件。

六、项目范围确认

1、项目范围确认概述

确认范围：是正式验收已完成的项目可交付成果的过程。

• 确认范围需要审查可交付物和工作成果，以保证项目中所有工作都能准确地、满意地完成。
• 确认范围应该贯穿项目的始终，从WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验。
• 确认范围过程应该以书面文件的形式把它完成情况记录下来。
• 主要作用是：使验收过程具有客观性，同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。

2、项目范围确认的工作要点

（1）制定并执行确认程序。

• 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常优先于确认范围过程，但二者也可同时进行。
• 确认范围的一般步骤如下：
  • 确定需要进行确认范围的时间；
  • 识别确认范围需要哪些投入；
  • 确定范围正式被接受的标准和要素；
  • 确定确认范围会议的组织步骤；
  • 组织确认范围会议。

（2）项目干系人对项目范围的正式承认。在每个阶段中，有必要说明最重要的活动，但没必要过分强调涉及细节。除非项目干系人特别提到，而且要有详细讨论每个细节的准备。项目干系人进行确认范围时，一般需要检查以下6个方面的问题：

• 可交付成果是否确实的、可确认的或者说可核实的；
• 每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的。例如：客户的书面认可书等。
• 是否有明确的质量标准；
• 审核或承诺是否表达清晰。项目投资人必须正式同意项目的边界、项目完成的产品或服务、以及项目相关的可交付成果。项目团队必须清楚了解并取得一致的意见。
• 项目范围是否覆盖了需要完成的产品或服务进行的所有活动；
• 项目范围的风险发生概率，管理层是否能够降低可预见性的风险对项目的影响。

3、项目范围确认采用的方法

（1）检查：开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准，是否满足项目干系人的要求和期望。检查有时也被称为审查、产品审查、审计和巡检等。

（2）群体决策技术：为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序。达成群体决策的方法有很多，例如：一致同意、大多数原则、相对多数原则、独裁。

4、项目范围确认的输入

项目范围确认的输入：

• 项目管理计划，包括范围管理计划和范围基准。
• 需求文件
• 需求跟踪矩阵。是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。需求跟踪矩阵通常包括有以下内容，具体取舍根据项目需要：
  • 业务需要、机会、目的和目标；
  • 项目目标；
  • 项目范围 /WBS 可交付成果；
  • 产品设计
  • 产品开发
  • 测试策略和测试场景；
  • 高层级需求到详细需求。
• 核实的可交付成果。指已经完成，并经质量过程检查为正确的可交付成果。
• 工作绩效数据。

5、项目范围确认的输出

项目范围确认的输出：

• 验收的可交付成果。该由客户或发起人以书面的形式正式签字批准。没有被客户接受的交付物也应该被记录下来，同时还要记录未被客户接受的原因。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。由于范围的确认可以是阶段性的，所以此处所讲的交付物可能是中间交付物。这涉及到系统集成项目的验收问题，即可先分批验收，最后再终验，但是每一次验收都需要客户的书面确认。
• 变更请求。对未被客户接受的可交付成果，可能需要针对这些可交付成果提出变更请求以进行缺陷补救。变更请求应该由实施整体变更控制过程进行审查与处理。
• 工作绩效信息。
• 项目文件更新。

七、项目范围控制

1、项目范围控制概述

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

• 未经控制的产品或项目范围的扩大被称为范围蔓延。
• 变更不可避免，因此在每个项目上，都必须以书面的形式记录并实施某种形式的变更控制管理。
• 作用：在整个项目期间保持对范围基准的维护。

2、项目范围控制与项目整体变更管理的联系

项目范围控制与项目整体变更管理的联系：

• 变更是项目干系人常常由于项目环境或者是其他原因要求而对项目的范围计划进行修改甚至是重新规划，有时变更也叫变化。
• 项目的范围变更控制、管理是对项目中存在的或潜在的变化采用正确的策略和方法来降低项目的风险。
• 范围变更管理过程中经常遇见的问题包括：
  • 项目范围蔓延。小的范围变化的聚合形成大的范围 变化。
  • 得不到投资人的批准。只有投资人或其授权的人有批准权。
  • 项目小组未尽责任；

3、项目范围控制与用户需求变更的联系

项目范围控制与用户需求变更的联系：

• 用户的需求变更必须控制在可控范围之内。
• 需求基线定义了项目的范围。随着项目的进展，用户的需求可能发生变化，从而导致需求基准变化以及项目范围的变化。每次需求变更并经过需求评审后，都要重新确定新的需求基线。

4、项目范围控制涉及所用的工具与技术

项目范围控制涉及所用的工具与技术：

• 偏差分析：是一种确定实际绩效与基准的差异程度及原因的技术。
  • 可利用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

5、项目范围控制的输入

项目范围控制的输入：

• 项目管理计划：用于范围控制的，如范围基准、范围管理计划、变更管理计划、配置管理计划、需求管理计划；
• 需求文件；应明确（可测量且可测试）、可跟踪、完整、一致且得到主要干系人的认可。记录完好的需求文件便于发现任何对批准的项目或产品范围的偏离。
• 需求跟踪矩阵；有助于发现任何变更或对范围基准的任何偏离给项目目标造成的影响。
• 工作绩效数据；可能包括变更请求的数量、接受的变更请求的数量，或完成的可交付成果数量等

6、项目范围控制的输出

项目范围控制的输出：

• 工作绩效信息；
• 变更请求；
• 项目管理计划更新，可能至少包括：
  • 范围基准更新；
  • 其他基准更新；
  • 项目文件更新；

5. 确认范围，正式验收已完成的可交付成果；
6. 范围控制，监督项目和产品的范围状态、管理范围基准变更。

补充内容：产品范围 和 项目范围

• 产品范围：表示产品、服务或结果的特性和功能。
  • 产品范围包括产品规格、性能技术指标的描述，即产品包含的特性和具体的功能性能情况等。随着项目的开展，其产品特征会逐渐细化。
• 项目范围：为了完成具有规定特征和功能的产品、服务或结果，而必须完成的项目工作。
  • 项目范围是否完成以项目管理计划、项目范围说明书、WBS、以及WBS字典作为衡量标准，而产品范围是否完成以产品要求作为衡量准备。
• 两种范围管理需要很好地集成起来，以确保项目工作能产生所规定的产品并准时交付。

第十一章

第十二章