PMP/高项 04-项目范围管理

项目范围管理

============

概念

项目范围（Project Scope）

对项目最终产品和期望可交付成果及实现该产品和期望可交付成果所需各项具体工作简要精确的描述。
即为成功交付具有规定特性与功能的产品或服务而必须完成的工作

产品范围

客户对项目最终产品或服务所期望包含的特征和功能的总和。

项目范围服务于产品范围，有时也包括了产品范围
项目管理计划（范围说明书、WBS和WBS词典）-> 衡量项目范围是否完成
产品需求（需求规格说明书）-> 衡量产品范围是否完成

项目范围管理

确保项目做而且只做成功完成项目所需的全部工作的各过程。
管理项目范围主要是在定义和控制哪些工作应该包括在项目内，哪些不应包括在项目内。还确认清楚项目工作中的分工和责任

最好就是做且只做范围内的事情

项目范围基准

经批准的详细项目范围说明书、相应的工作分解结构、工作分解结构词典

项目目标是项目范围管理计划编制的一个基本依据。
企业管理层关注范围对项目进度、资金和资源影响，是否超出了组织的承受范围，是否在投入产出上具有合理性。

内容

项目范围管理内容

作用

• 为项目实施提供工作范围的框架

项目范围管理最重要的作用就是为项目实施提供了一个项目工作范围的边界和框架，并通过该边界和框架去规范项目组织的行动，在澄清了项目工作范围和条件之后，就可以让人们放弃不必要的工作和各种不切合实际的想法。

• 提高资金、时间、人力和其他资源估算的准确性

项目的具体工作内容明确以后，可以依据各项具体工作来规划其所需的资金、时间、人力和其他资源，这样对整体和各项工作的需求估计就容易多了

• 确定进度测量和控制的基准，便于对项目的实施进行有效的控制

项目范围是项目计划的基础，项目范围确定了，就为项目进度计划的执行和控制确定了基准，从而可以采取相应的纠偏行动

• 有助于清楚地分派责任

一旦项目范围界定了，也就确定了项目的具体工作任务，为进一步分派任务奠定了基础

过程

一、规划范围管理

规划范围管理：是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。

规划好项目范围该如何管理，可以有效的减少项目范围蔓延的风险，计划好范围管理该做的事情，可以让我们对于项目中遇到与范围相关的内容可以有明确的指导做法。
客户认可的管理计划可以让我们沟通实施起来更加通畅，减少扯皮。

输入

项目管理计划

依据项目管理计划中已批准的子计划来创建范围管理计划

项目章程

项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书

事业环境因素

组织过程资产

工具技术

专家判断

专家判断是指由具备相关知识和经验的各方所提供的意见

会议

项目团队可以参加项目会议来制定范围管理计划;与会人员可能包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人，以及其他必要人员

输出

范围管理计划

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

主要内容：

制定项目范围说明书；
根据详细项目范围说明书创建WBS；
确定如何审批和维护范围基准；
正式验收已完成的项目可交付成果
处理对项目范围说明书或WBS变更

范围管理计划可以是正式或非正式的，是制定项目管理计划的依据，规定了如何制定范围说明书

需求管理计划

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。

主要内容：

如何规划、跟踪和报告各种需求活动；
需求优先级排序过程；
需求管理需要使用的资源
培训计划；
干系人参与需求管理的策略；
判断项目范围与需求不一致的指标和纠正规程；
测量指标及使用这些指标的理由；
反映哪些需求属性将被列入跟踪矩阵的跟踪结构
配置管理活动；

二、收集需求

定义

收集需求：为实现项目目标而定义并记录干系人的需求的过程，旨在定义和管理客户期望。

作用

仔细掌握和管理项目需求与产品需求，对促进项目成功有重要作用
为定义产品范围和项目范围奠定基础

发生时间

仅开展一次或仅在项目的预定义点开展

收集需求的重点是工具与技术，在实际应用中该怎么沟通，和选择采用哪种方法与客户沟通非常重要。

在大项目中也有专业的BA来做需求分析，分析完成后也有相应的需求评审，评审过后的需求才拿给开发来做相应的设计。但在小项目中，只能项目经理来做兼职了，这就要求项目经理不仅要把管理做好，还要把需求和技术连接起来，相当的High。

需求

概念

• 需求：指发起人、客户和其他干系人的已量化且记录下来的需要与期望。
• 让干系人积极参与需要发掘和分解工作（分解成需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。
• 需求是工作分解结构的基础。成本、进度和质量规划也都要在这些需求的基础上进行。

需求分类

• 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因
• 干系人需求：干系人或干系人群体的需要
• 解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求
  • 功能需求：是关于产品能开展的行为。如流程、数据，以及与产品的互动
  • 非功能需求：是对功能需求的补充，是产品正常运行所需的环境条件或质量。如可靠性、安防性、性能、安全性、服务水平、可支持性、保留/清除等
• 过渡需求：从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
• 项目需求：项目需要满足的行动、过程或其他条件
• 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。

输入

项目章程

可从项目章程中了解总体项目需求以及关于项目产品的总体描述，并据此制定详细的产品需求

范围管理计划

范围管理计划使项目团队知道应该如何确定所需收集的需求的类型

需求管理计划

需求管理计划规定了用于整个收集需求过程的工作流程，以便定义和记录干系人的需要

干系人管理计划

从干系人管理计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。

干系人登记册

可用来识别那些能提供详细的项目和产品需求信息的干系人。干系人登记册也记录了干系人对项目的主要需求和期望。

技术与工具

收集需求主要是在于应用方面，所以对如何操作这个过程要求很高，合理的应用以下方法，了解相应方法的优点，缺点，来决定方法的应用场景。除了下面这些，还有其他的很多方法，但在实际中，掌握好几种常用的，并把它们运用熟练更重要。

1、访谈

• 通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答

一对一的交谈，可以挖出客户更深层次的需求，也可用于获取机密信息

2、焦点小组

• 召集预先选定的干系人和主题专家，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。

焦点小组会议比访谈更加热烈

3、引导式研讨会

• 引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。

研讨会是快速定义跨职能需求和协调干系人差异的重要技术

用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。
用户故事描述哪个干系人将从功能中受益（角色），他需要实现什么（目标），以及他将获得的收益（动机）。用户故事在敏捷方法中广泛使用

在制造行业：使用“质量功能展开（Quality Function Deployment，QFD）”的引导式研讨会，帮助确定新产品的关键特征
QFD目标优化矩阵

4、群体创新技术

常用的群体创新技术：

1. 头脑风暴法：产生和收集对项目需求与产品需求的多种创意

2. 名义小组技术：通过投票来排列最有用的创意。是头脑风暴法的深化应用。

3. 概念/思维导图：把从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

4. 德尔菲技术：由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈，专家的答复只能交给主持人，以保持匿名状态

5. 亲和图法（KJ法/Affinity
   Diagram）:把大量收集到的事实、意见或构思等语言资料，按其相互亲和性（相近性）归纳整理这些资料，使问题明确起来，求得统一认识和协调工作，以利于问题解决的一种方法。

6. 多准则决策分析：借助决策矩阵，用系统分析方法建立如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序。

5、群体决策技术

为达成某种期望结果而对多个未来行动方案进行评估。用于生成产品需求，并对产品需求进行归类和优先级排序

• 一致同意
  每个人都同意某个行动方案。达成一致同意的一种方法就是德尔菲技术，由一组选定的专家回答问卷，并对每轮需求收集的结果给出反馈。只有主持人可以看
  到专家的答复，以保持匿名状态
• 大多数原则
  获得群体中超过 50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策
• 相对多数原则
  根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
• 独裁
  由某一个人为群体做出决策

群体决策技术都可以与群体创新技术联合使用

6、问卷调查

通过设计书面问题，向受访者快速收集信息。

问卷调查方法非常适用于以下情况：
受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

7、观察

直接观察个人在各自的环境中如何开展工作和实施流程。

• 当产品使用者难以或不愿说明他们的需求时，需要通过观察来了解细节。观察也称为“工作跟踪”。
• 通常由观察者从外部来观看业务专家如何执行工作。
• 也可以由“参与观察者”来观察，他通过实际执行一个流程或程序，来体验该流程或程序是如何实施的
• 便于挖掘隐藏的需求。

8、原型法

在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。

原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

9、标杆对照

将实际或计划的项目做法与可比项目的做法进行对照，以便识别最佳实践，形成意见，并为绩效考核提供依据。

标杆对照所采用的可比组织可以是内部的，也可以是外部的。

10、系统交互图

系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。

系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者

11、文件分析

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

可供分析的文档很多，包括（但不限于）：商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其他需求文档、问题日志、政策、程序和法规文件（如法律、准则、法令等）。

输出

需求文件

• 描述各种单一的需求将如何满足与项目相关的业务需求。
• 一开始只有高层级需求，然后逐步细化
• 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。

主要内容：

1. 业务需求–整个组织的高层级需要，在银行里科技就是为业务服务的
2. 干系人需求–干系人提出的与项目相关的需求
3. 解决方案需求–为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征
4. 过渡和就绪需求–这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
5. 项目需求–项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
6. 质量需求-用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

SMART原则，一般来描述项目目标需要符合的标准，在需求中也适用：
Simple：简单易懂，太复杂的目标无法凝聚项目团队人心。
Measurable：结果可测，即可以用量化的标准去检验成败。
Achievable：力所能及，即达到目标的途径必须是可行的。
Relavent：符合利益，当然是符合干系人共同的相关利益；
Time Frame：阶段性的，可以分阶段实现，积小胜为大胜。

需求跟踪矩阵（RTM）

是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪

作用：

• 把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值。
• 提供了在整个项目生命周期中跟踪需求的一种方法，用于监控，确保每个被批准的需求在项目结束时都可追溯能交付。
• 为管理产品范围变更提供了框架。
• 应记录各项需求的相关属性。这些属性有助于明确各项需求的关键信息。

跟踪内容：

业务需要、机会、目的和目标；
项目目标；
项目范围和 WBS 可交付成果；
产品设计；
产品开发；
产品测试（策略、场景、脚本）；
高层级需求到详细需求。

三、定义范围

定义

制定项目和产品详细描述的过程。

主要作用

明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书

定义范围在范围管理中就是决定我们项目该干多少事情的过程了，虽然项目是渐进明细的，但大体范围是不变的。把需求定在一个可控的，让人舒适的范围会让项目更好做一些。这个范围定义的时候尽量不要比实际少，该算工作量的就该把工作量统计出来。

输入

范围管理计划

是项目管理计划的组成部分，确定了制定、监督和控制项目范围的各种活动。

项目章程

对项目和产品特征的概括性描述，以及项目审批要求。

需求文件

组织过程资产

①用于制定项目范围说明书的政策、程序和模板；

②以往项目的项目档案；

③以往阶段或项目的经验教训。

技术与工具

产品分析

对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。
为开发一个更好、更明确的项目结果而进行的分析。如产品分解、系统分析、系统工程、价值工程、价值分析。

备选方案的识别

实现项目的目标成果并不局限一种方案，为了防范风险我们常常要准备许多备选方案

头脑风暴——比较适合那些大众化的项目，无须专业知识和经验。选择随和的场合，不设条条框框，让参加者随意畅想，集思广益，最后通过民主集中，筛选出好主意。

自由联想——类似头脑风暴，但是参与者最好是与项目没有直接关系的人，不受先入为主的经验和教条的束缚，能够产生大胆而新奇的思路。

专家判断

由来自项目内部和外部的具备专业知识或受过专门培训的人组成一个专家小组，该小组的成员凭借其专业知识和经验对所获得的信息进行分析和判断，以决定是否批准某项决议或采取某种措施

引导式研讨会

这个在收集需求里就有

输出

项目范围说明书

• 详细说明项目的可交付成果和为提交这些成果而必须开展的工作
• 是干系人对项目范围的共同理解，说明了项目的主要目标
• 是项目团队能够实施更详细的规划，在执行过程中指导项目团队的工作
• 构成了评价变更请求或增加的工作是否超出了项目边界的基准

主要内容

项目章程与项目范围说明书对比

更新的项目文件

干系人登记册、需求文件、需求跟踪矩阵

四、创建WBS

是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。

概念

WBS工作分解结构(Work Breakdown Structure)

以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。

注意：
构成WBS的是项目的工作而不是项目成果的内容。这是在编制WBS时最容易掉入的陷阱

工作包

计划要完成的工作包含在WBS最底层的组成部分。是完成项目目标所要完成的相关工作活动的集合，为项目控制提供充分和合适的管理信息

建立有效工作包的原则如下：
①工作包应该是可确定的、特定的、可交付的独立单元；
②工作包中的工作责任应落实到具体的单位或个人；
③工作包的大多数工作应该适用相同的工作人员，从而提高人员之间的沟通；
④工作包应与特定的WBS单元直接相关，并作为其扩延；
⑤工作包单元的周期应是最短周期；
⑥应明确本工作包与其他工作包之间的关系；
⑦能确定实际的预算和资源需求。

工作包分解程度

项目中最常见的困难是，工序规模太大难以控制，导致不能完成进度安排。
如果一个工作包需要8个月时间、10个工人全职工作，那就不是一项任务，而是一个子项目。

8/80原则

• 任何一个工作包都应当不少于8个工时，不多于80个工时。也就是，任何一个工作包都应在1~10天内完成。

报告期原则

• 任何一个工作包的持续时间不能超过两次情况报告之间的时间间隔

“如果有用” 原则

• 继续分解工作任务需要有3个支持理由：
  1、便于估算（减少不确定性）
  2、便于分配（小任务负责人明确）
  3、便于跟踪（更准确汇报进展情况）
  如果将某项任务分解后，不能方便地估算、分配或跟踪，那这样的分解就是无效的，那就不要把它分解。

控制账户CA

项目成本核算中使用的 WBS组成部分，每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。

WBS字典

对工作分解结构组成部分进行更详细的描述。

内容：

账户编码标志号
工作描述
假设条件和制约因素
负责的组织
进度里程碑
相关的进度活动
所需的资源
成本估算
质量要求
验收标准
技术参考文献
合同信息

对每一活动包括的详细内容进行表述，包括：任务编号、名称、如何做、投入资源、结果、完成的标准/质量、由谁做

范围基准

被批准的详细的项目范围说明书和其相关的WBS以及WBS词典

注意：
可以针对工作包安排进度、估算成本和实施监控，但并不能直接通过WBS明确人员的责任。

范围说明书和需求文件里有详细的需求内容，创建wbs也就是把需求变成了详细的工作事项，完成这个项目需要多少个步骤，就如同把大象放进冰箱需要多少步一样，然后再看每个事项方法都该包含在哪个对象中，也就是工作该分配给谁来做。
这个时候项目经理对于整个项目就应该有谱了，团队整个参与wbs的编制工作，在团队成员心中也就大概能知道自己适合做项目中的哪部分工作，按wbs的工作包来界定工作范围，也避免了重复工作的可能。

创建WBS步骤

1. 识别和分析可交付成果及相关工作

• 得到范围说明书(Scope Statement)或工作说明书(Statement of Work，承包子项目时)。

2. 确定WBS结构形式和编排方式

• 召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。

3. 自上而下逐层细化分解

• 分解项目工作。如果有现成的模板，应该尽量利用。
• 画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
• 将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。

4. 为WBS组成部分制定和分配标志编码

• 如果有必要，建立一个编号系统。

5. 核实WBS分解程度是必要且充分的

• 验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。
  必要且充分：最底层是否为必须，组成部分的定义完整清晰，组织

结构形式：生命周期、可交付成果、子项目
编排方式：

• 图解式：树形结构、鱼骨图。清晰，不易修改，适合小项目
• 列表：内容丰富，易修改，适合大项目
• 文本大纲

标志编码：运用特定的规则对分解结构图中的各个结点进行编码，可简化项目实施过程中的信息交流

树形

鱼骨型

列表
文本

标志编码

创建WBS方法

创建WBS原则

• 进行充分的层次分解：分解到有利于有效管理的详细层次，既不能太小，也不能太大。
• 100%原则：下一层次是对上一层次百分之百的分解。充分、满足，没有遗漏，是WBS的核心特点。
• 滚动式规划：等到可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的细节。
• 适用于根据项目或组织的具体要求进行跟踪：提供逻辑的汇总点和控制点。
• 分解后的任务应该是：可管理的、可定量检查的、可分配任务的、独立的。
• 在适当层次分配责任：分解到一个工作可以授权一个人（部门）负责，与（RAM）和（OBS）建立关联。

注意：

• 构成WBS的是项目的工作而不是项目成果的内容
• 一个工作任务只能在WBS中出现一次
• 一个子项目的工作内容是下一级工作任务之和

输入

范围管理计划

定义了应该如何根据详细项目范围说明书创建WBS，以及应该如何维护和批准WBS

项目范围说明书

需求文件

需要产出什么项目结果，需要做什么来交付项目及其最终产品

事业环境因素

组织过程资产

技术与工具

分解

把项目可交付成果划分为更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包的层次

分解到何种程度，这个是实际管理中的重点，分解的多了管不过来，分解的少了没有什么跟踪的意义，或者时间上拖太长不利于估计时间和工作量。

这在实际中感觉比较好的方法是：项目经理负责协调管理上层的，大块的内容；继续分解的任务下放到项目团队，每个人在分到上层工作包时继续分解为个人可在每周、每天把控的工作事项，最后汇总进行管理。

工作分解结构可以采用多种形式

• 把项目生命周期的各阶段作为分解的第一层，把产品和项目可交付成果放在第二层；
• 把主要可交付成果作为分解的第一层；
• 按子项目进行第一层分解。
  

专家判断

需要依据各种信息，把项目可交付成果分解为更小的组成部分。专家判断常用于分析这些信息，以便创建有效的WBS

专家判断也是各个地方都可以用，在实际中就是请教专业人员，谈需求就找BA，技术上就问开发，业务上就问专业的业务人员，每项工作在组织中总有擅长的人员，找这些人核对其实就是专家判断。

输出

范围基准

经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典。

项目范围说明书

包括产品范围描述和项目可交付成果，并定义用户对产品的验收标准。

工作分解结构WBS

定义每一项可交付成果，并把可交付成果分解为工作包。

工作分解结构词典

对每一个工作分解结构要素的工作和技术文件做详细说明。

更新的项目文件

五、确认范围

定义

• 范围确认是由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收。

• 如果这个项目已提前终止，这个范围确认过程也应该证实并应以书面文件的形式把它的完成情况记录下来。

• 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。经质量检查合格的可交付成果才能进行范围确认。

范围核查

• 项目范围审核是项目干系人(发起人、客户和顾客等)最终认可和接受项目范围的过程。在项目范围审核工作中，要对范围定义过程的工作结果——工作分解结构进行审查，确保所有的、必需的工作都在工作分解结构中，而一切与项目目标无关的工作均不包括在项目范围中，以保证项目范围的准确性。
• 项目范围审核的常用工具有如下两张核检表，即项目范围核检表和工作分解结构核检表，在项目范围管理中是十分有效的。
• 另外，雷达图也常被使用

项目范围&WBS核检表

可交付成果有时候比较大，等最后验收的时候再确认是否符合范围，这就很爆炸。在实际中需要比可交付成果更小的粒度来进行验收和确认，减少变更的内容。在项目过程中还需要不断地完善范围，避免出现项目缺胳膊少腿在最后验收的时候才发现。

雷达图

雷达图是另一个有效的项目范围审核工具。它通过图标直观地反映工作成果与目标业绩之间差距，因为图形酷似雷达而被称为雷达图。利用雷达图可以使项目取得的成绩与要求的目标之间的差距一目了然，同时还可以看到工作各个方面完成情况之间的差距，此外，雷达图还能对所涉及的各类数据进行相对量化的比较。

输入

项目管理计划

包含范围管理计划和范围基准。

范围管理计划定义了项目已完成可交付成果的正式验收程序
范围基准包含批准的范围说明书、WBS和相应的WBS词典

需求文件

需求跟踪矩阵

连接了需求与需求源，用于在整个项目生命周期中对需求进行跟踪

核实的可交付成果

是指已经完成并经实施质量控制过程检验合格的可交付成果

工作绩效数据

技术与工具

检查

是指开展测量、审查与核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准。有时也被称为审查、产品审查、审计和巡检等。

群体决策技术

这个合格不合格的话也是由客户来决定，但在验收之前，项目经理就该把整个给确认一遍，预防总是胜过事后补救。

输出

验收的可交付成果

①符合验收标准的可交付成果应该由客户或发起人正式签字批准。
②应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
③这些文件将提交给结束项目或阶段过程。

可交付成果验收与项目验收 辨析

变更请求

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

工作绩效信息

辨析 工作绩效数据、工作绩效信息、工作绩效报告

项目文件更新

六、控制范围

定义

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

对范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。

项目范围蔓延：未得到控制的变更

输入

项目管理计划

①范围基准（用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或采取预防措施）
②范围管理计划（描述如何管理和控制项目范围）
③变更管理计划（定义管理项目变更的过程）
④配置管理计划（定义配置项，定义需要正式变更控制的内容，并为这些配置项和内容规定变更控制过程）
⑤需求管理计划。

需求文件

需求应该明确（可测量且可测试）、可跟踪、完整、一致且得到主要干系人的认可。

需求跟踪矩阵

需求跟踪矩阵有助于发现任何变更或对范围基准的任何偏离给项目目标所造成的影响。

工作绩效数据

组织过程资产

技术与工具

偏差分析

是一种确定实际绩效与基准的差异程度及原因的技术。
①可利用项目绩效测量结果评估偏离范围基准的程度。
②确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施。（常用的偏差分析法为挣值法）

输出

工作绩效信息

是有关项目范围实施情况（对照范围基准）的相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。这些信息时制定范围决策的基础。

变更请求

对范围绩效的分析，可能导致对范围基准或项目管理计划其他组成部分提出变更请求。

项目管理计划更新

范围基准更新

• 如果批准的变更请求会对项目范围产生影响，那么范围说明书、工作分解结构及工作分解结构词典都需要重新修订和发布，以反映这些批准的变更。
• 其他基准更新如果批准的变更请求会对项目范围以外的方面产生影响，那么相应的成本基准和进度基准也需要重新重新修订和发布，以反映这些批准的变更。

项目文件更新

需求文件和需求跟踪矩阵。

组织过程资产更新

项目范围变更控制

由于项目条件和环境的变化会使项目范围发生变动，由此可能造成项目工期、成本或质量等的改变。范围变更控制要解决的问题是：

• 对可能造成范围变更的因素施加影响，以确保出现范围变更时，其变更因素能得到一致认可；
• 确定范围变更是否已经发生；
• 当范围变更发生时，对实际的变更进行管理。

1、项目范围变更的原因

项目干系人常常由于各种原因要求对项目范围进行修改，造成范围变更的原因很多，主要有：

（1）项目的外部环境发生变化，如政府的有关规定发生变化；
（2）在项目范围计划或定义时出现错误或遗漏；
（3）项目团队提出了新的技术、手段或方案；
（4）项目实施的组织本身发生了变化；
（5）客户对项目或项目产品的要求发生变化。

2、项目范围变更控制的工作

• 分析和确定影响项目范围变动的因素和环境条件。
• 管理和控制那些能够引起项目范围变动的因素和条件。
• 分析和确认各方面提出的项目变动要求的合理性和可行性。
• 分析和确认项目范围变动是否已发生，以及这些变动的风险和内容。
• 当项目范围变动发生时，对其进行管理和控制，设法使这些变动朝有益的方向发展，努力消除项目范围变动的不利影响。

3、项目范围变更控制的方法和技术

• 项目范围变更控制系统
  范围变更控制系统是一系列正式的、文档化的程序，这些程序定义了对项目绩效进行监控和评价的过程。范围变更控制系统包括正式项目文档变更的步骤，还包括文档系统、跟踪系统、过程和必要的变更批准层次。
• 项目绩效的度量技术
  度量实际变化发生的程度，发现偏差及分析造成偏差原因、是否需要纠正等技术。
• 范围计划调整
  很少有项目能按项目的初始计划进行运转，项目的范围随时都有可能发生变化，因此就要根据范围的变动来随时调整补充原有的工作分解结构图，并以此为基础，调整、确定新的项目计划，并根据新的项目计划的要求，对项目范围的变更进行控制。

4、项目范围变更控制的输出

• 范围变更
  对经批准的工作分解结构中所定义的项目范围所作的任何修改。范围变更一般要求对成本、时间、质量或其他项目目标进行调整。
• 项目变更控制中的纠正行动
  纠正行动指为了将预期的项目绩效控制与项目计划相符而采取的任何措施。
• 经调整的基准
  根据变更的性质，相应的基准文件有可能需要修改并重新分发，并作为今后变更的新基准。
• 从项目变更中学到的经验与教训

思维导图