项目范围管理 Scope Management原创
步骤：规划范围管理计划、收集需求、定义范围、创建工作分解结构、确认范围、控制范围。
产品范围：指产品或服务所应包含的功能。
项目范围：指为能够交付产品，项目必须要做的工作。
PS:产品范围是项目范围的基础
项目范围管理需要做好的工作：
- 明确项目边界
- 对项目执行工作进行监控，
确保所有该做的工作都做了，杜绝做额外的工作 - 防止项目范围反生蔓延
# 范围蔓延
是指未对时间、成本核资源做相应调整，未经控制的产品或项目范围的扩大。
警告
项目范围管理的重要性：
项目范围管理及控制的有效性，是衡量项目是否达到成功的一个必要标准。同时，不断重申项目工作范围，保障项目不偏离轨道。通过项目范围管理详细、清楚地界定分工界面和责任，有利于项目实施中的变工控制和项目的推进，便于项目结束时对项目范围的核实。通过项目范围管理，能够提高对成本、进度和资源估算的准确性。
项目范围管理能影响项目的成功，范围蔓延是最为常见的原因之一。在启动、计划、执行，甚至是收尾时不断假如新功能，无论是客户的要求还是项目团队的创新或是新技术的出现，都可能导致项目范围的失控，使进度、成本、质量受到严重影响。
# 1.规划范围管理
为项目编制范围管理计划，书面描述将如何定义、制定、监督、控制和确认项目范围，为如何管理项目范围提供指南和方向。
# 输入
# 技术与工具
# 输出
# 范围管理计划
规定内容：
- 如何制定项目范围说明书
- 如何根据范围说明书创建WBS
- 如何维护和批准WBS
- 如何确认和正式验收已完成的项目可交付成果
- 如何处理项目范围说明书的变更，该工作与实施整体变更控制直接相联
# 需求管理计划
需求管理计划(Requirements Management Plan)描述在整个项目生命周期内如何分析、记录和管理需求。
需求管理计划是对项目的需求进行定义、确定、记载、核实管理和控制的行动指南。
主要包括：
- 如何规划、跟踪和汇报各种需求活动
- 需求管理需要使用的资源
- 培训计划
统一项目团队成员的共识，规范行动步骤。 - 项目干系人参与需求管理的策略
- 判断项目范围与需求不一致的准则和纠正规程
- 需求跟踪结构
- 配置管理活动
# 2.收集需求
收集需求(Collect Requirement)是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，为定义和管理项目范围(包括产品范围)奠定基础。
需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或产品、服务或成果必须具备的条件。
定义和管理客户的期望，是WBS的基础，成本、进度和质量计划也都在需求的基础上进行。
需求分类(不是从单一角度进行分类的，不同场合会有不同说法)：
- 业务需求
- 干系人需求
- 解决方案需求
- 过渡需求
- 项目需求
- 质量需求
# 质量功能部署 quality Function Deployment ,QFD
对质量需求进行了细分：- 常规需求
用户认为系统应该做的的功能或性能，实现越多用户越满意。 - 期望需求
用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没得到实现，用户会感到不满意。 - 意外需求
- 常规需求
# 输入
# 技术与工具
# 访谈
通过直接与干系人直接交谈来获取信息的正式或非正式的方法。(最基本的一种收集手段)
- 结构化
事先准备好一系列问题，有针对地进行。 - 非结构化
只列出一个粗略的想法，根据访谈的情况发挥。
访谈的缺点：
- 干系人如果较忙，则难以安排时间
- 面谈信息量大时，记录较为困难(通常纸笔记录，如若录音录像，需经干系人同意)
- 沟通需要技巧
- 可能涉及机密或敏感话题
# 问卷调查
问卷调查(Questionnaire and Survey)是指通过设计书面问题，向为数众多的受访者快速收集信息。
与访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许匿名填写，大多数干系人可能会提供真实信息；问卷调查的结果比较好整理和统计。
问卷调查最大的缺点就是缺乏灵活性，同时还具备以下缺点：
- 双方未见面，项目经理无法从干系人的表情等其他动作来获取一些更隐性的信息，干系人也没有机会立即澄清对问题有含糊或者错误的回答；
- 干系人可能在心理上不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面；
- 调查表不利于对问题进行展开的回答，无法了解一些细节问题；
- 回答者的数量往往比预期的要少，无法保证干系人会回答问题或进一步说明所有问题；
因此，可以先进行问卷调查，在进行访谈，两者结合才能更好收集到更多有用的信息。
# 观察
观察(Observation)也称为工作跟踪，是指直接观察个人在各自的环境中如何开展工作和实施流程。
当产品使用者难以或不愿说明他们的需求时使用。
可以从外部观察，也可以实际执行一个流程或程序，体验该流程或程序是如何实施的，以便挖掘出隐藏的要求。
# 标杆对照
标杆对照(Benchmarking)将实际或计划的做法与其他类似组织的做法（例如，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
所谓的“类似组织”可以是外部的，也可以是内部的。
PS:规划质量管理也使用该技术。
# 原型法
原型法(Prototype)是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人的产品快速开发的方法。
# 焦点小组
将预先选定的干系人和专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由受训的主持人引导进行互动式讨论。6至10个被访谈者参加。
# 引导式研讨会
引导式研讨会(Facilitated Workshop)是一种跨职能部门的群体访谈。邀请主要的跨职能干系人参加会议，对产品需求进行集中讨论和定义。
PS:焦点小组是同领域同方向的群体访谈。
# 群体创新技术
群体创新技术(Group Creativity Technique)是指可以组织一些群体活动来识别项目和产品需求。包括：
# 头脑风暴法
头脑风暴(Brain Storming,BS)又称为智力激励法、自由思考法和集思广益法，是用来产生和手机对项目需求与产品需求的多种创意的一种技术。
- 直接头脑风暴法(简称头脑风暴法)
在专家群体决策时尽可能激发创造性，产生尽可能多的设想的方法。 - 质疑头脑风暴法(也称反头脑风暴法)
对头脑风暴法提出的设想、方案逐一质疑，分析其实现可行性的方法。
头脑风暴法参加人数一般为5至10人，最好由不同专业或岗位人员组成，时间控制在1小时内。1名主持人，1至2名记录员。无论好坏设想均记录，畅所欲言，相互启发和激励。创意越多越好。
# 名义小组技术
名义小组技术(Nominal Group Technique)通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优选排序。是头脑风暴法的深化引用，是更加架构化的头脑风暴法，过程如下：
- 首相，将全体参与者分成多个“名义”上的小组，由每个小组开展讨论。
- 小组讨论结束后，主持人依次项每位参与者询问，请每人提出一个创意。询问可以进行多次，直到得到足够的创意。
- 最后，请全体参与者对所有创意进行评审和排序。
名义小组优点：使哪些不善言辞的参与者也能充分发表自己的意见。
# 德尔菲技术
德尔菲技术(Delphi Technique)是一种组织专家就某一主题达成一致意见的一种信息收集技术。
由一组选定的专家回答问卷，并对每一轮需求收集的结果在给出反馈。专家的答复只能交给主持人，以保持匿名状态。步骤如下：
- 根据问题的特点，选择和邀请做过相关研究或有相关经验的专家；
- 将于问题有关的信息分别提供给专家，请他们各自独立发表自己的意见，并写成书面材料；
- 主持收集并综合专家们的意见后，将综合意见反馈给个专家，请他们在此发表意见。若分歧很大，可以开会集中讨论；否则，主持人分头与专家联络；
- 如此反复多次，最后形成代表专家组意见的方案；
德尔菲技术技术的典型特征如下：
- 吸收专家参与预测，充分利用专家的经验和学识；
- 采用匿名或背靠背的方式，能使每一位专家独立自由地做出自己的判断；
- 预测过程几轮反馈，使专家的意见逐渐趋同；
- 有助于减轻数据的偏倚，防止任何个人对结果产生不恰当的影响；
这些特点使德尔菲技术成为一种最为有效的判断预测法。
德尔菲技术与专家会议对比：
发挥专家会议的优点：
- 能充分发挥各位专家的作用，集思广益，准确性高；
- 能将个专家的分歧点表达出来，取各家之长，避各家之短；
避免专家会议的缺点：
- 权威人事的意见影响他人的意见；
- 有些专家碍于情面，不愿意发表与他人不同的意见；
- 出于自尊心而不愿意修改自已原来不全面的意见；
# 概念/思维导图
思维导图(Mind Mapping)又称心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
思维导图运用图文并重的技巧，将各级主体关系用相互隶属与相关的层级图表现出来，将主题关键词与图像、颜色等建立记忆链接，充分运用左右脑的技能，利用记忆、阅读、思维的规律，协助人们在科学以艺术、逻辑与想象之间平衡发展。
# 亲和图
质量管理新七工具之一
亲和图(Affinitu Diagram)又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以便于解决的一种方法。
亲和图的核心是头脑风暴，是根据结果去找原因。可以将大量创意分类，以便审查和分析。主要依据各种创意之间的相似性，对头脑风暴中得到的各种创意进行分类。
亲和图针对某个问题，产生出可联成有组织的想法模式的各种创意，主要用来确定范围分解的结构，有助于WBS的制订。
# 多标准决策分析
多标准决策分析(Multi-Criteria Decision Analysis)是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
# 群体决策技术
群体决策(Group Decision-Makeing)就是为达成某种期望结果而对多个未来行动方案进行评估，可以用来开发产品需求，以及对产品需求进行归类和优先排序。
笔记
群体决策的方法：
- 一致同意(Unanimity)
- 大多数原则(Majority)，获得群体中50%以上人的支持，就能做出决策，参与决策人数定为奇数。
- 相对多数原则(Plurality),多个方案存在时，支持率最高的那个方案。
- 独裁
# 系统交互图
系统交互图(Context Diagram)是范围模型的一个例子，它是对产品范围的可视化描述，显示系统(过程、设备、信息系统等)与参与者(用户、独立于本系统之外的其他系统)之间的交互方式。
例如：软件需求分协中的DFD、用例图都可以看做是系统交互图。
# 文件分析
文件分析(Document Analysis)是通过分析现有文档，识别与需求相关的信息来挖掘需求。
文档包括：商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
# 输出
# 需求文件
需求文件(Requirements Documentation)描述各种单一的需求将如何满足于项目相关的业务需求。
需求文件不是一个文件的名字，并且其格式多种多样，不同组织可能有不同的称呼。例如：软件需求规格说明书就是一种典型的需求文件。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。其内容包括（但不限于）：
- 业务需求。包括可跟踪的业务目标和项目目标、执行组织的业务规划、组织的指导原则
- 干系人需求。包括对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求
- 解决方案需求。包括功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求和报告需求。可用纯文本或模型展示解决方案需求，也可两者同时使用
- 项目需求。包括服务水平、绩效、安全和合规性等，以及验收标准
- 过渡需求
- 与需求有关的假设条件、依赖关系和制约因素
# 需求跟踪矩阵
涉及需求管理。CMMI中，需求管理是已管理级的一个关键过程域，其目标是为产品需求建立一个基线，供软件开发及其管理使用，使计划、产品和活动与需求保持一致。
可跟踪性包含两层含义：
- 项目执行过程的两个或多个产品之间能够建立关系的程度。尤其是哪些具有前后关系或主从关系的产品。
- 项目产品中每个元素能够建立其存在理由的程度。
正向跟踪是指检查需求文件中的每个需求是否都能在后续工作产品（成果）中找到对应点。
反向跟踪也称为逆向跟踪是指检查设计文档、产品构建、测试文档等工作成果是否都能在需求文件中找到出处。
需求跟踪设计5种类型：
- 正向跟踪：用户原始需求 -> 需求文件。这样能区分出项目过程中或项目结束后由于变更收到影响的需求，确保了需求文件中包括所有用户需求。
- 反向跟踪：需求文件 -> 用户原始需求。确认每个需求的出处。
- 跟踪：需求文件之间的跟踪。这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
- 正向跟踪：需求文件 -> 下游工作产品。确保产品元素满足每个需求。
- 返向跟踪：下游工作产品 -> 需求文件。使项目成员知道每个产品元素存在的原因，否则可能出现镀金行为；或某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
需求跟踪（能力）矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格，有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。
需求跟踪的内容包括：
- 业务需求、机会、目的和目标
- 项目目标
- 项目范围（WBS可交付成果）
- 产品设计
- 产品开发
- 测试策略和测试场景
- 高层级需求到详细需求
需求跟踪矩阵，按照5种不能类型跟踪建立响应表格。
# 3.定义范围
定义范围（Define Scope）是制定项目和产品详细描述的过程，因为收集需求过程中识别的所有需求未必都包含在项目中，因此我们要明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界，同时定义范围会影响项目进度、成本管理，需尽早完成，并根据风险分析、假设条件和制约因素做必要的增补更新。
# 输入
# 技术与工具
# 产品分析
对于以产品为可交付成果的项目，产品分析（Product Analysis）是一种有效的工具。
针对产品提问并回答，形成对将要开发产品的用途、特征和其他方面的描述。
产品分析技术包括：产品分解
WBS就是一种典型的产品分解技术。
系统分析
需求分析
系统工程
价值工程(Value Engineering)
是在产品开发设计结点进行价值与成本革新活动，因为仍在工程设计阶段，故称为价值工程。
价值分析(Value Analysis)
价值工程之后的持续分析是降低成本的主要方法。一旦开始量产，如果不进行详尽的价值分析，就难以发掘可以降低成本或提高价值的改善点。
其他
价值工程和价值分析都是对项目的范围和成本进行分析，以便确保项目范围不便的前提下，降低项目成本，追求功能与成本之间的更高的性价比。
# 备选方案生成
备选方案生成（Alternatives Generation）是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
方法有：备选方案分析
备选方案分析（Alternative Analysis）是一种对已识别的可选方案进行评估的技术，用来决定选择那种方案或使用何种方法来执行项目工作。
横向思维
横向思维（Lateral Thinking）又称为戴勃诺理论、发散思维、水平思维，是指思维的广阔度，它要求人们能全面地观察问题，从事物多种多样的联系和关系中去人事事物，它不一定是有顺序的，同时也不能预测。
纵向思维（Vertical Thinking）是指在一种结构范围内，按照有顺序的、可预测的、程序化的方向进行思维形式。这是一种符合事物发展方向和人类认识习惯的思维方式，遵循由低到高、由浅到深、由始到终等线索，因而清晰明了，合乎逻辑。
# 输出
# 项目范围说明书
项目范围说明书（Project Scope Statment）是对项目范围、主要可交付成果、假设条件和制约因素的描述。包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成而必须开展的工作。
警告
范围说明书内容：
- 产品范围描述
是项目范围说明书的重要组成部分。用来判断产品范围是否完成。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征。 - 验收标准
定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。 - 可交付成果
即包括组成项目产品或服务的各种结果，也包括各种辅助成果。如：项目管理报告和文件。对可交付成果的描述可详可简。 - 项目的除外责任
明确说明哪些内容不属于项目范围，有助于管理干系人的期望。 - 制约因素
列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。如：强制性日期、强制性进度里程碑、协议条款等。 - 假设条件
是指在制定计划时，不需验证即可视为正确、真实或确定的因素，以及万一不成立而可能造成的后果。
范围说明书的作用：
- 确定范围
描述了可交付成果和所要完成的工作。 - 沟通基础
表明项目干系人之间就项目范围所达成的公式。可明确指出哪些工作不属于项目范围。 - 规划和控制依据
- 变更基础
为评价变更请求和额外工作是否超出项目便捷提供基准。 - 规划基础
在项目范围说明书的基础上，其他计划也将被编制出来，同时还是滚动式规划的基础。
提示
项目范围说明书的作用同样适用于WBS。
项目范围说明书与项目章程的区别：
- 两者内容有一定的重叠，但是他们的详细程度完全不同。项目章程包括高层级的信息，而项目范围说目标书则是对项目范围的详细描述。
- 项目范围需要在项目过程中渐进明细，而项目章程一般保持不变。
PS:同时更新项目相关文件。
# 4.创建工作分解结构(WBS)
创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，对所要交付的内容提供一个结构化的视图。
WBS是以可交付成果为导向的工作层分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。
警告
WBS中的“工作”并不是指工作本身，而是指工作所导致的产品或可交付成果。
将整体或者主要可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解成为工作包，直到整个项目都分解成为可管理的工作包。
工作包(Work Package)是位于WBS每条分支最底层的可交付成果或项目工作组成部分。内容非常具体，以便承担者明确自己的任务、努力的目标和承担的责任。工作包是基层任务或工作的指派，同时具有检测和报告工作的作用，让成本管理者和项目监督人员理解，并能够清楚区分不同工作包的工作。
工作包如果太多，则那一达到可管理和可控制的目标；如果太小，则创建WBS需要消耗大量时间和精力，且工作包过多时，会造成逻辑结构复杂。
在每个分解单元中都存在可交付成果和里程碑(Milestone)。里程碑标志着某个可交付成果或者阶段的正式完成。
# 可交付成果
可能是报告、原型、成果和最终产品。
# 输入
# 技术与工具
警告
# 分解
- 自上而下
- 控制在4~6层
- 100%原则
项目全体成员、用户和项目干系人一致确认；
WBS中的元素只能由一个人负责。 - 8/80原则
最小8小时，最大不操过80小时(即10天)。 - WBS分解的主要活动
- 判断为了交付可交付成果需要进行的工作
- 确定工作分解结构的结构和编排
- 将工作分解结构自上而下逐层分解(
一般4至6层) - 为每个部分表示编码
- 审核工作分解结构的每个部分是否必要和足够
分解没有所谓的正确方式，可以用白板、草图或专业软件。
# 分解开展的活动(必须掌握)：
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法
- 自上而下逐层细化分解
- 为WBS组件制定和分配标识编码
- 核实可交付成成果分解的程度是否恰当
# WBS分解时，需要注意的事项：
- WBS必须是面向可交付成果的
- WBS必须符合项目的范围
- WBS的底层应该支持计划和控制
- WBS的元素必须有负责人，而且只能有一个人负责
- WBS应控制在4~6层，编码为：a.b.c.d 至 a.b.c.d.e.f
- WBS应包括项目管理工作，也要包括分包出去的工作
- WBS的编制需要所有(主要)项目干系人的参与，需要项目团队成员的参与
- WBS并非一成不变，后续可能需要对WBS进行修改
# 输出
# 范围基准 Scope Baseline
范围基准用来衡量项目范围是否完成。
警告
范围基准(估算成本时会用到)包含：
批准的项目范围说明书
工作分解结构(WBS)
# WBS词典
又称为WBS词汇表，可能包括：账户编码标识、工作描述、假设条件和制约因素、负责人和组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
WBS词典比WBS包含的信息更多，因此作用更大。
PS：同时更新项目相关文件。
# WBS的作用
WBS并非一成不变。WBS的目的和主要作用：
- 明确和准确说明项目范围，项目成员能够清楚地理解任务的性质和需要努力的方向
- 清楚地定义项目的边界，一致认可项目需要做的工作和不需要做的工作
- 为各独立单元分派人员，规定人员的职责，确定完成项目所需的技术和人力资源。
- 针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性
- 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准
- 项项目工作和财务账目联系起来
- 确定工作内容和工作顺序
- 有助于防止需求蔓延，视图增加项目功能时，在WBS增加相应的工作的同时，相关成本核进度也必须做相应的改变，让相关人员容易理解。
# 5.确认范围
确认范围(Validate Scope)就是通过相关技术和工具来判断工作和可交付成果是否符合需求和产品验收标准，难点在于与用户的沟通。
确认范围时需要检查的问题有：
- 可交付成果是否是可确定的、可确认的
- 每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的时间
- 是否有明确的质量标准
- 审核和承诺是否有清晰的表达
- 范围是否覆盖了需要完成的产品或服务进行的所有活动
- 有无遗漏或错误
- 范围的风险是否太高
确认范围的步骤： - 确定需要进行范围确认的时间
- 识别范围确认需要哪些投入
- 确定范围正式被接受的标准和要素
- 确定范围确认会议的组织步骤
- 组织确认范围会议
确认范围时，不同干系人的关注点不同：
- 管理层关注项目范围，即范围对项目的进度、资金和资源的影响，是否超过组织承受范围，是否在投入产出上具有合理性。可能会导致管理层取消项目。
- 客户主要关心产品反问，即可交付成果是否足够完成产品或服务。
- 项目管理人员关注可交付唱过是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
- 项目团队成员关心范围中自己参与的元素和负责的元素，检查自己的工作时间是否足够，是否在范围中有多项工作，工作是否有冲突。
在确认范围工作中若发现项目范围说明书、WBS中有遗漏或错误，需明确指出错误并给出修正意见。并且关注范围变更请求的请求、批准与实施等状态。
警告
# 确认范围与控制质量的区别：
| 确认范围 | 控制质量 |
|---|---|
| 关注可交付成果获得客户或发起人的接受 | 关注可交付成果的正确性即是否满足质量要求 |
| 一般在阶段末尾进行而质量控制不一定在阶段末 | 一般在确认范围前进行，也可同时进行 |
| 由外部干系人(客户或发起人)对项目可交付成果进行检查验收 | 属于内部检查，由执行组织的相应质量部门实施 |
# 输入
# 技术与工具
# 输出
PS:同时更新项目其他相关文件。
# 术语比较
- 确认范围与核实产品
核实产品时针对产品是否完成，在项目(或阶段)结束是由烦气人和客户来验证，强调产品是否完整。
确认范围是针对可交付成果，由客户或烦气人在阶段末确认验收的过程。 - 确认范围和质量控制
不同之处再与：- 确认范围强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）
- 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末尾进行
- 质量控制属于内部检查，由执行组织相应质量部门实施；确认范围则由外部干系人对项目可交付成果进行检查验收
- 确认范围和项目收尾
不同之处在于：- 虽然两者都是在阶段末尾进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作
- 都有验收工作，但确认范围强调验收项目可交付成果，项目收尾强调验收产品
核实产品 -> 质量控制 -> 确认范围 -> 项目收尾
# 6.控制范围
控制范围（Control Scope）是监督项目和产品的范围状态、管理范围基准变更过程，保持对范围基准的维护，必须确保所有的请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程处理。
范围变更的原因：
- 政府政策
- 项目范围计划编制不周密详细，有一定的错误或遗漏
- 市场出现或设计人员提出新技术、新手段或新方案
- 项目执行组织本身发生变化
- 客户对项目、项目产品或服务的要求发生变化
范围变更的工作：
- 影响导致范围变更的因素，尽量使这些因素向有利的方面发展
- 判断范围变更是否已经发生
- 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
# 输入
# 技术与工具
# 偏差分析
也用于成本管理的绩效审查。
用以解释成本偏差（CV=EV-AC）、进度偏差（SV=EV-PV）和完工偏差（AVC=BAC-EAC）的原因、影响和纠正措施。
# 输出
- 工作绩效信息
- 变更请求
- 项目管理计划更新
- 项目文件更新
- 组织过程资产更新
