Project Scope Management
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。它关注的焦点是:什么是包括在项目之内的,什么是不包括在项目之内的,即为项目工作明确划定边界。通俗地讲,项目范围管理就是要做范围内的事,而且只做范围内的事，既不少做也不多做。少做会影响项目既定功能的实现，多做会浪费资源。因某种原因,要改变项目的工作边界时,项目范围管理会提供一套规范的方法去处理范围变更。项目范围的定义可以是广义的，也可以狭义的，根据项目不同管理层的需要,再集中结合应用项目的特点进一步阐述。
项目范围的管理不仅仅是项目整体管理的一个主要部分,同时在项目中不断地重申项目工作范围,有利于项目不偏离轨道,是项目中实施控制管理的一个主要手段。项目范围管理不仅仅是让项目管理和实施人员知道为达成预期目标需要完成哪些具体的工作,还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任。详细、清楚地界定分工界面和责任,不但有利于项目实施中的变更管理和推进项目发展,减少责任不清的事情发生,也便于项目结束时项目范围的明确、清晰地确认。项目范围是项目其他各方面管理的基础,如果范围都弄不清楚,成本、进度和质量等就无从谈起。
确认项目范围对项目管理有如下的重要性：(1)清楚了项目的工作具体范围和具体工作内容，为提高成本、时间和资源估算的准确性提供了基础。(2)项目范围既然是确定要完成哪些具体的工作，项目范围基准是确定项目进度测量和控制的基准。(3)项目范围的确定就是确定了项目的具体工作任务，有助于清楚的责任划分和任务分配。
项目范围管理通过以下6个过程来实现：
（1）编制范围管理计划过程，对如何定义、确认和控制项目范围的过程进行描述。
（2）收集需求。为实现项目目标，明确并记录项目干系人的相关需求的过程。
（3）定义范围。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。
（4）创建工作分解结构。把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。
（5）确认范围。正式验收已完成的可交付成果。
（6）范围控制。监督项目和产品的范围状态、管理范围基准变更。
根据项目需要，每个过程可能会需要一个或多个个体或团队的共同努力。一般来说，在每个项目阶段，每个过程通常至少发生一次。尽管这些过程是作为各自独立的组成部分而进行定义的，但是，在实践中它们是以各种形式相互交叠、相互影响的。
编制范围管理计划是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。编制范围管理计划和细化项目范围始于对下列信息的分析:项目章程中的信息、项目管理计划中已批准的子计划等。编制范围管理计划有助于降低项目范围蔓延的风险。
7.2.1 编制范围管理计划过程所用的工具与技术
1、会议
项目团队可以参加项目会议来制定范围管理计划。与会人员可能包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人，以及其他必要人员。
2、专家判断
具有与制定范围管理计划相关的专业学历、知识、技能、经验或培训经历的任何小组或个人，都可以提供专家判断。
7.2.2 编制范围管理计划过程的输入、输出
编制范围管理计划过程的输入
1）项目管理计划
依据项目管理计划中已批准的子计划来创建范围管理计划，它们会对用于规划和管理项目范围的方法产生影响。
2）项目章程
依据项目章程中的项目背景信息来规划各个范围管理过程。项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书。
3)组织过程资产
影响编制范围管理计划过程的组织过程资产包括政策和程序以及历史信息和经验教训知识库。
4）事业环境因素
影响编制范围管理计划过程的事业环境因素包括组织文化、基础设施、人事管理制度、市场条件等。
范围管理计划是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。范围管理计划是制定项目管理计划过程和其他范围管理过程的主要依据。范围管理计划要对将用于下列工作的管理过程做出规定：
（1）制定详细项目范围说明书。
（2）根据详细项目范围说明书创建WBS。
（3）维护和批准工作分解结构(WBS)。
（4）正式验收已完成的项目可交付成果。
（5）处理对详细项目范围说明书或WBS的变更。该工作与实施整体变更控制过程直接相联。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
需求管理计划是项目管理计划的组成部分，描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。需求管理计划的许多内容都是以阶段关系为基础的。
需求管理计划的主要内容至少包括：
（1）如何规划、跟踪和报告各种需求活动。
（2）配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。
（3）需求优先级排序过程。
（4）产品测量指标及使用这些指标的理由。
（5）用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
（6）收集需求过程。
需求跟踪矩阵（Requirement traceability matrix），也译作需求追溯矩阵，是一种主要管理需求变更和验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态。
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义和管理项目范围（包括产品范围）奠定基础。
访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付的成果特征和功能。访谈也可用于获取机密信息。
焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义 跨职能需求 和 协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，研讨会能够比单项会议更早发现问题，更快解决问题。例如，在软件开发行业，就有一种称为“联合应用设计/开发(JAD)”的引导式研讨会。这种研讨会注重把业务主题专家和开发团队集中在一起，来改进软件开发过程。在制造行业，则使用“质量功能展开(QFD)”这种引导式讨论会，来帮助确定新产品的关键特征。QFD从收集客户需要(又称“客户声音”)开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个干系人将从功能中受益(角色)，他需要实现什么(目标)，以及他将获得的收益(动机)。用户故事在敏捷方法中广泛使用。
可以组织一些群体活动来识别项目和产品需求。下面是一些常用的群体创新技术：
1）头脑风暴法。一种用来产生和收集对项目需求与产品需求的多种创意的技术。头脑风暴法本身不包含投票或排序，但常与包含该环节的其他群体创新技术一起使用。
2）名义小组技术。用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
3）概念/思维导图。把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。
4）亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。
5）多标准决策分析。借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序。达成群体决策的方法有很多，例如：
1）一致同意。每个人都同意某个行动方案。
2）大多数原则。获得群体中超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策。
3）相对多数原则。根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
4）独裁。在这种方法中，由某一个人为群体做出决策。
在收集需求过程中，上述群体决策技术都可以与群体创新技术联合使用。
问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
观察是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。观察，也称为“工作跟踪”，通常由观察者从外部来观看业务专家如何执行工作。也可以由“参与观察者”来观察，他通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
原型法是指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比划较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求。可供分析的文档很多，包括：商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其他需求文档、问题日志、政策、程序和法规文件等。
7.3.2 收集需求过程的输入、输出
收集需求过程的输入
（1）范围管理计划
（2）需求管理计划
（3）干系人管理计划
（4）项目章程
（5）干系人登记册
从干系人登记册中了解哪些干系人能够提供需求方面的信息。干系人登记册也记录了干系人对项目的主要需求和期望。
需求文件描述各种单一需求将如何满足与项目相关的业务需求。
需求文件的主要内容包括：
（1）业务需求。①可跟踪的业务目标和项目目标；② 执行组织的业务规则；③ 组织的指导原则。
（2）干系人需求。① 对组织其他领域的影响；②对执行组织内部或外部团体的影响；③ 干系人对沟通和报告的需求。
（3）解决方案需求。① 功能和非功能需求；② 技术和标准合规性需求；③ 支持和培训的需求；④质量需求；⑤报告需求(可用文本记录或用模型展示解决方案需求，也可两者同时使用)。
（4）项目需求。①服务水平、绩效、安全和合规性等；②验收标准。
（5）过渡需求。
（6）与需求相关的假设条件、依赖关系和制约因素。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。需求跟踪矩阵还为管理产品范围变更提供了框架。
需求跟踪包括跟踪以下内容：
（1）业务需要、机会、目的和目标；
（2）项目目标；
（3）项目范围/WBS可交付成果；
（4）产品设计；
（5）产品开发；
（6）测试策略和测试场景；
（7）高层级需求到详细需求。
应在需求跟踪矩阵中记录每个需求的相关属性。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。
7.4.1 范围定义
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
范围定义的内容和作用
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件(收集需求过程的输出)中选取最终的项目需求，然后制定出关于项目及其产品、服务或输出的详细描述。
定义范围最重要的任务就是详细定义项目的范围边界，范围边界是应该做的工作和不需要进行的工作分界线。定义范围可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果。
范围定义的输入
（1）范围管理计划
（2）项目章程
（3）需求文件
（4）组织过程资产
范围定义的输出
（1）项目范围说明书
（2）项目文件更新
可能需要更新的项目文件至少包括：干系人登记册、需求文件、需求跟踪矩阵。
范围定义的工具和技术
（1）产品分析
产品分析旨在弄清产品范围，并把对产品的要求转化成项目的要求。
（2）专家判断
（3）备选方案生成
备选方案生成是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的管理技术都可用于生成备选方案，如头脑风暴、横向思维、备选方案分析等。
（4）引导式研讨会
具有不同期望或专业知识的关键人物参与研讨会，有助于就项目目标和项目限制达成跨职能的共识。
7.4.2 范围说明书
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目和产品范围。项目范围说明书详细描述项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。
（1）项目目标（可量化标准）
（2）产品范围描述
（3）项目需求
（4）项目边界
（5）项目的可交付成果
（6）项目的制约因素（事先确定的预算、强制性日期或进度里程碑）
（7）假设条件
与范围相关的假设条件，以及当这些条件不成立 时对项目造成的影响。作为计划过程的一部分，项目团队要经常识别、记录和确认创设条件的有效性。在制定计划时，不需验证即可视为正确、真实或确定的因素就是假设。关于假设条件的信息可以列入项目范围说明书，也可以独立成册。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包括高层级的信息，而项目范围书说则是对项目范围的详细描述。项目范围需要在项目过程中渐进明细。
创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。工作分解结构（WBS）是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构。如果没有工作分解结构，就谈不上项目的进度计划、成本计划、质量计划、人力资源计划和风险计划等。本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
（1）通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明和具体。使项目管理者和项目干系人如投资人或客户，都能通过WBS把握项目、了解和控制项目过程。
（2）保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在遗漏，进而保证了项目的完整性。
（3）通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标要求。
（4）项目工作结构分解能够明确项目相关各方的工作界面，便于责任划分和落实。
（5）最终工作分解结构，可以直接作为进度计划和控制的工具。
（6）为建立项目沟通管理提供依据，便于把握信息重点。
（7）是项目各分计划和控制措施制定的基础和主要依据。
（8）有助于防止需求和范围蔓延。
WBS最低层的工作单元被称为工作包，是我们进行进度安排、成本估算和监控的基础。工作包对相关活动进行归类。
（1）工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构当中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”。这是工作分解结构百分百规则的要求，即工作分解结构必须且只能包括 100%的工作。
（2）工作分解结构的编制需要所有项目千系人的参与，需要项目团队成员的参与。
（3）工作分解结构是逐层向下分解的。一般情况下，工作分解结构应控制在3〜6层为宜。
工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
（1）分级的树型结构
类似于组织结构图。树型结构图的WBS层次清晰，非常直观，结构性强，但是不容易修改，对于大型的、复杂的项目也很难表示出项目的全景。由于其直观性，一般在一些小的、适中的应用项目中用得较多。
（2）表格形式
类似于分级的图书目录。该表能够反映出项目所有的工作要素，可是直观性较差。但在一些大型的、复杂的项目中使用还是较多的，因为有些项目分解后，内容分类较多、容量较大，用缩进图表的形式表示比较方便，也可装订为手册。
分解结构的一些概念
（1）里程碑
标志着某个可交付成果或者阶段的正式完成。重要的检查点叫做里程碑，重要的里程碑叫做基线。
（2）工作包
是位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分。作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要 8个小时来完成，而总完成时间也不应该大于80小时。
在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识，这些标识为进行成本、进度与资源信息的层级汇总提供了层级结构。控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。控制账户设置在WBS中选定的管理节点上。每个控制账户 可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。需要生成一些配套的文件，这些文件需要和工作分解结构配合使用，称为工作分解结构词典，它包括工作分解结构组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单等，还可能包括合同信息、质量要求、技术文献、计划活动、资源和成本估计等。
（3）WBS 编码设计
为了简化WBS的信息交流过程，通常利用编码技术对WBS进行信息交换。编码设计与结构设计存在对应关系。结构的每一层次代表编码的某一位数，有一个分配给它特定的代码数字。
在 WBS 编码中，任何等级的一位项目要素，是其余全部次一级项目要素的总和。如第二个数字代表子项目要素。所有子项目的编码第一位数字是相同的，再下一级的工作单元的编码依此类推。
编码设计对于WBS来说是个关键技术。不管对于使用者是高级管理人员还是其他层次的员工来说编码都有共同的意义。在进行编码设计时必须仔细考虑收集到的信息和收集所用的方法，使信息能够通过WBS编码进入到应用记录系统中。
1、分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包。
通常需要开展以下活动：（22年上已考）
（1）识别和分析可交付成果及相关工作
（2）确定WBS的结构和编排方法
（3）自上而下逐层细化分解
（4）为WBS组件制定和分配标识编码
（5）核实可交付成果分解的程度是否恰当
工作结构分解应把握如下原则：（非常重要）
（1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）—个工作单元只能从属于某个上层单元，避免交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的工作内容。
（5）便于项目管理计划和项目控制的需要。
（6）最底层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。
2、专家判断
创建工作分解结构的输入
（1）项目范围管理计划
（2）项目范围说明书
（3）需求文件
（4）事业环境因素
（5）组织过程资产
创建工作分解结构的输出
经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典组成了范围基准，只有通过正式的变更控制程序才能进行变更这个基准，它被用作比较的基础。
范围基准包括：① 项目范围说明书② WBS③ WBS词典
WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。WBS词典中的内容可能至少包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。
（2）项目文件更新
确认范围是 正式验收 己完成的项目可交付成果的过程。
确认范围应该贯穿项目的始终。范围确认过程中可能产生变更申请，例如对缺陷的修复要求。
确认范围的主要作用：
(1) 使验收过程具有客观性
(2) 同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
1、制定并执行确认程序
确认范围过程与控制质量过程的不同之处：前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
确认范围的一般步骤：
（1）确定需要进行确认范围的时间
（2）识别确认范围需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定确认范围会议的组织步骤。
（5）组织确认范围会议。
2、项目干系人对项目范围的正式承认
在每个阶段中,有必要说明最重要的活动，但没必要过分强调涉及细节。除非项目干系人特别提到,而且要有详细讨论每个细节的准备。
项目干系人进行确认范围时，一般需要检查以下6个方面的问题：
（1）可交付成果是否确实的、可确认的或者说可核实的。
（2）每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的。例如,客户的书面认可书等。
（3）是否有明确的质量标准。
（4）审核或承诺是否表达清晰。项目投资人必须正式同意项目的边界、项目完成的产品或服务，以及项目相关的可交付成果。项目团队必须清楚了解并取得一致的意见。
（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动。
（6）项目范围的风险发生概率，管理层是否能够降低可预见性的风险对项目的影响。
（1）检查
是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准，是否满足项目干系人的要求和期望。检查有时也被称为审查、产品审查、审计和巡检等。在某些应用领域，这些术语具有独特和具体的含义。
（2）群体决策技术
当由项目团队和其他干系人进行确认时，可以使用群体决策技术来达成结论。
项目范围确认的输入
1）项目管理计划
2）需求文件
3）需求跟踪矩阵
4）核实的可交付成果：核实的可交付成果是指已经完成，并经质量过程检查为正确的可交付成果。
5）工作绩效数据
项目范围确认的输出
1）验收的可交付成果
2）变更请求
3）工作绩效信息
4）项目文件更新
7.7.1 项目范围控制涉及的主要内容
范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。范围控制涉及到影响引起范围变更的因素，确保所有被请求的变更、推荐的纠正措施或预防措施按照项目整体变更控制处理，并在范围变更实际发生时进行管理。范围控制过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须以书面的形式记录并实施某种形式的变更控制管理。本过程的主要作用是，在整个项目期间保持对范围基准的维护。
7.7.2 项目范围控制与项目整体变更管理的联系
范围变更管理过程中经常遇见的问题包括：（1）项目范围蔓延（2）得不到投资人的批准（3）项目小组未尽责任
7.7.3 项目范围控制与用户需求变更的联系
7.7.4 项目范围控制涉及所用的工具与技术
进行项目范围控制时，所用的技术和工具是偏差分析。
偏差分析是一种确定实际绩效与基准的差异程度及原因的技术。可利用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
7.7.5 项目范围控制的输入、输出
输入
1）项目管理计划
2）需求文件
3）需求跟踪矩阵
4）工作绩效数据
5）组织过程资产
输出
1）工作绩效信息
2）变更请求
3）项目管理计划更新
4）项目文件更新
5）组织过程资产更新
