第五章-项目范围管理

5.项目范围管理

界说：项目范围管理包罗确保项目做且只做所需的全部工作，以乐成完成项目标各个过程。管理项目范围主要在于界说和控制哪些工作应该包罗在项目内，哪些不应该包罗在项目内。

明确两个范围的概念：

• 产物范围：某项产物、服务或成果所具有的特征和功能。
  
• 项目范围：为交付具有规定特性与功能的产物、服务或成果而必须完成的工作。项目范围有时也包罗产物范围。
  
• 总结的来说，产物范围决定的项目范围，项目范围反过来服务于产物范围。
  

项目范围管理的原则：

• 项目没有包罗与项目乐成无关的工作。
  
• 项目已经达到了项目乐成的全部工作。
  

在项目标范围管理中，有一个关键的逻辑需要注意的是，如果出现了不符合100%的原则的情况，那么这个项目就是失败的。
主要产生该问题的两种情况：范围蔓延，镀金。
范围蔓延：未经控制的产物或项目范围的扩大（未思量对时间，本钱和资源的影响）。范围蔓延会挤压项目标本钱，时间和资源，将项目推向失败的边缘。例如实际的开发功能超出了计划。
镀金：由于项目实行单位的人员主动的增加了功能或项目。例如超出了原有预期的工作预定时间而做出的其他附属工作，简朴理解就是在客户单位安装系统，提前了半个小时竣事战斗，为了给客户更好的印象而扫除了整个办公室，这个举措会导致在后续的人员配合中产生先入为主的情况，后续的开发人员是应该扫除还是不应该扫除，间接的扩大了项目范围。
提示：在以上范围蔓延中提到的问题，在已经发生了超出计划的开发，这时应该怎么处理？
答案：按照问题中情况的已经体现出变动不受控的情况，此时项目经理应及时补变动控制流程，确认提出变动的相关方，询问相关方是否真的有该变动需求，按照变动控制流程（补一个书面变动请求，再补一个项目团队与主题专家的确认，确认该变动不会对项目产生不良影响，大概与其他功能有辩论，末了决定是保存该功能大概是删除该功能）
5.1 规划范围管理

界说： 为纪录怎样界说、确认和控制项目范围及产物范围，而创建范围管理计划的过程。
主要作用： 在整个项目期间对怎样管理范围提供指南和方向。本过程仅开展一次或仅在项目标预界说点开展。

5.1.1规划范围管理：输入

5.1.1.1 项目章程

项目章程纪录项目目标、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。
5.1.1.2 项目管理计划

• 质量管理计划：在项目中实施构造的质量政策、方法和标准的方式会影响管理项目和产物范围的方式。在PMP中对于质量管理计划与范围管理计划的耦合性较高，所以列在此地。
  
• 项目生命周期描述：项目生命周期界说了项目从开始到完成所经历的一系列阶段。
  
• 开发方法：开发方法界说了项目是采用瀑布式、迭代型、适应型、灵敏型还是混淆型开发方法。
  

5.1.1.3 奇迹情况因素

• 构造文化
  
• 基础办法
  
• 人事管理制度
  
• 市场条件
  

5.1.1.4 构造过程资产

• 政策和程序
  
• 历史信息和经验教训知识库
  

5.1.2 规划范围管理：工具与技术

5.1.2.1 专家判断

具备相关专业知识或接受过相关培训的个人或小组的意见 – 拍脑壳
5.1.2.2 数据分析

适用于本过程的数据分析技术包罗（但不限于）备选方案分析。本技术用于评估收集需求、详述项目和产物范围、创造产物、确认范围和控制范围的各种方法。
5.1.2.3 会议

项目团队可以参加项目会议来制定范围管理计划。参会者大概包罗项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人，以及其他必要人员。
5.1.3 规划范围管理：输出

5.1.3.1 范围管理计划

范围管理计划是项目管理计划的组成部分，描述将怎样界说、制定、监督、控制和确认项目范围。 范围管理计划要对将用于下列工作的管理过程做出规定：

• 制定项目范围阐明书；
  
• 根据详细项目范围阐明书创建WBS；
  
• 确定怎样审批和维护范围基准；
  
• 正式验收已完成的项目可交付成果。
  

根据项目需要，范围计划可以是正式的大概非正式的，非常详细大概高度概括的。
范围管理的内核就是在项目实行过程中必须做的事情项目经理到底怎么管理（界说、制定、监督、控制和确认）。
5.1.3.2 需求管理计划

需求管理计划是项目管理计划的组成部分，描述将怎样分析、纪录和管理项目和产物需求。 需求管理计划的主要内容包罗（但不限于）：

• 怎样规划、跟踪和陈诉各种需求运动；
  
• 配置管理运动。例如：怎样启动变动，怎样分析影响，怎样进行溯源等等；
  
• 需求优先级排序过程；
  
• 丈量指标以及使用这些指标的理由；
  
• 反应哪些需求属性将被列入跟踪矩阵的跟踪布局。
  

需求管理的过程是作为项目跟需求方互动的过程，需求排序的过程，度量需求指标的过程。
以下简朴列一个简易的需求管理计划的框架

• 需求收集：谁主导谁配合？调查需求的对象有哪些？
  
• 需求评估：具体的评估方法？
  
• 需求管理：新需求增加的方式？
  
• 需求跟踪和查抄：落实跟踪，纠偏措施，过程纪录。
  

5.2 收集需求

界说： 为实现项目目标而确定、纪录并管理相关方的需要和需求的过程。
主要作用： 为界说产物范围和项目范围奠基基础，且仅开展一次或仅在项目标预界说点开展。

5.2.1 收集需求：输入

5.2.1.1 项目章程

项目章程纪录了项目概述以及将用于制定详细需求的高层级需求。
5.2.1.2 项目管理计划

• 范围管理计划 ：范围管理计划包罗怎样界说和制定项目范围的信息。
  
• 需求管理计划 ：需求管理计划包罗怎样收集、分析和纪录项目需求的信息。
  
• 相关方管理计划 ：从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求运动的参与程度。
  

5.2.1.3 项目文件

• 假设日志 ：假设日志识别了有关产物、项目、情况、相关方以及会影响需求的其他因素的假设条件。
  
• 经验教训登记册 ：经验教训登记册提供了有用的需求收集技术，尤其针对使用迭代型或适应型产物开发方法的项目。
  
• 相关方登记册 ：相关方登记册用于了解哪些相关方能够提供需求方面的信息，及纪录相关方对项目标需求和期望。
  

5.2.1.4 商业文件

会影响收集需求过程的商业文件是商业论证，它描述了为满意业务需要而应该达到的必要、期望及可选标准。
5.2.1.5 协议

协议会包罗项目和产物需求。
5.2.1.6 奇迹情况因素

• 构造文化
  
• 基础办法
  
• 人事管理制度
  
• 市场条件
  

5.2.1.7 构造过程资产

• 政策和程序
  
• 历史信息和经验教训知识库
  

5.2.2 收集需求：工具与技术

5.2.2.1 专家判断

5.2.2.1 数据收集

分类名称关键词数据收集头脑风暴大量创意，各种想法，畅所欲言数据收集访谈直接交谈，预设和即兴问题，一对一，多对多，获取秘密信息数据收集焦点小组同一领域，主题专家数据收集文件调查受众多样化，需快速完成，地理位置分散，适合开展统计分析数据收集标杆对照识别最佳实践，形成改进意见。标杆可以是内部也可以是外部的 5.2.2.3 数据分析

可用于本过程的数据分析技术包罗（但不限于）文件分析。文件分析包罗审核和评估任何相关的文件信息。在此过程中，文件分析用于通太过析现有文件，识别与需求相关的信息来获取需求。
5.2.2.4 决议

投票是一种为告竣某种期望效果，而对多个未来行动方案进行评估的集体决议技术和过程。本技术用于天生、归类和排序产物需求。
分类名称关键词决议同等同意每个人都同意，菲尔德（专家，匿名，多轮，趋同，消除私见）决议大多数同意超过50%，一样平常把决议小组人数选定为奇数决议相对多数同意相对多数，通常候选项超过两个时使用决议独裁型决议制定一个人做决议决议多标准决议分析决议矩阵，多种标准，评估和排序 5.2.2.5 数据表现

• 亲和图：用来对大量创意进行分组的技术，以便进一步检察和分析。
  
• 头脑导图：把从头脑风暴中得到的创意整合成一张图，用以反映创意之间的共性与差别，激发新创意。
  

5.2.2.6 人际关系与团队技能

分类名称关键词人际关系与团队技能名义小组促进头脑风暴，投票，优先级排序人际关系与团队技能观察和交谈工作跟随，对于难以或不肯清楚阐明、发掘隐藏的需求人际关系与团队技能引导与主题研讨会结合使用，跨职能，协调相关方差别人际关系与团队技能引导（JAD）软件开发行业，业务主题专家和开发团队集中人际关系与团队技能引导（QFD）制造业，收集客户需要（客户声音）开始，分类排序人际关系与团队技能引导（用户故事）需求研讨会，角色，目标，动机 5.2.2.7 系统交互图

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

原型法是指在实际制造预期产物之前，先造出该产物的模子，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模子创建、用户体验、反馈收集到原型修改（大概要走变动流程）的反复循环过程。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学计划，以及灵敏和其他软件开发项目。在软件开发中，故事板使用实体模子来展示网页、屏幕或其他用户界面的导航路径。
5.2.3 收集需求：输出

5.2.3.1 需求文件

需求文件描述各种单一需求将怎样满意与项目相关的业务需求。一开始大概只有高层级的需求，然后随着有关需求信息的增加而渐渐细化。只有明确的（可丈量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意承认的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简朴文件，也可以是一份包罗内容提要、细节描述和附件等的详细文件。
许多构造把需求分为不同的种类，如业务解决方案和技术解决方案。前者是相关方的需要，后者是指怎样实现这些需要。把需求分成不同的种别，有利于对需求进行进一步完善和细化。需求的种别包罗：

• 业务需求：针对于某一个业务去做的需求。例如基于考勤而衍生的考勤打卡系统，亦大概基于考勤信息进行考勤分析的业务需求。
  
• 干系人需求：与相关方需求同义。简朴的理解就是项目中相关方或相关方群体的需要。还是考勤系统的举例，涉及该系统的使用者，管理者，即前台与人事部分的相关责任人，提出的需求。即可以简朴的理解为相关方需求。
  
• 解决方案需求：解决方案需求黑白常详细的具体的落地的细节需求。比招投标文件还详细。
  
• 解决方案需求（功能性）：功能需求描述产物应具备的功能。
  
• 解决方案需求（非功能性）：非功能需求是对功能需求的补充。是产物正常运行所需的情况条件或质量要求，例如，可靠性、保密性、性能、安全性、服务程度、可支持性、保存或清除等。
  
• 过渡需求：这些需求描述了从“当前状态”过渡到“未来状态”所需的临时本事。如数据转换和培训需求。例如考勤系统完成后，在使用的过程中会出现纸质审批流与线上审批流并行的情况，针对于这种情况，会出现些过渡期的需求。
  
• 项目需求：项目需要满意的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
  
• 质量需求：用于确认项目可交付成果的乐成完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
  

5.2.3.2 需求跟踪矩阵

需求跟踪矩阵是把产物需求从其泉源毗连到能满意需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标接洽起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被答应的每项需求在项目竣事的时间都能交付。末了，需求跟踪矩阵还为管理产物范围变动提供了框架。

5.3 界说范围

界说： 制定项目和产物详细描述的过程。
主要作用： 描述产物、服务或成果的边界和验收标准。
需要多次反复开展界说范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展而详细规划下一个迭代期的工作。

5.3.1 界说范围：输入

5.3.1.1 项目章程

项目章程中包罗对项目标高层级描述、产物特征和审批要求。
5.3.1.2 项目管理计划

项目管理计划组件包罗（但不限于）范围管理计划（见 5.1.3.1 节），其中纪录了怎样界说、确认和控制项目范围。
5.3.1.3 项目文件

同 5.2.1.3
5.3.1.4 奇迹情况因素

同 5.2.1.6
5.3.1.5 构造过程资产

• 用于制定项目范围阐明书的政策、程序和模板
  
• 以往项目标项目档案
  
• 以往阶段或项目标经验教训
  

5.3.2 界说范围：工具与技术

5.3.2.1 专家判断

5.3.2.2 数据分析

备选方案分析
5.3.2.3 决议

多标准决议分析
5.3.2.4 人际关系与团队技能

引导
5.3.2.5 产物分析

产物分析可用于界说产物和服务，包罗针对产物或服务提问并回答，以描述要交付的产物的用途、特征及其他方面。
每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产物或服务描述转变为有意义的可交付成果。起首获取高层级的需求，然后将其细化到终极产物计划所需的详细程度。产物分析技术包罗（但不限于）：

• 产物分解
  
• 需求分析
  
• 系统分析
  
• 系统工程
  
• 价值分析
  
• 价值工程
  

5.3.3 界说范围：输出

5.3.3.1 项目范围阐明书

项目范围阐明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它纪录了整个范围，包罗项目和产物范围；详细描述了项目标可交付成果；还代表项目相关方之间就项目范围所告竣的共识。为便于管理相关方的期望，项目范围阐明书可明确指出哪些工作不属于本项目范围。项目范围阐明书使项目团队能进行更详细的规划，在实行过程中指导项目团队的工作，并为评价变动请求或额外工作是否超过项目边界提供基准。
项目范围阐明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有用程度。详细的项目范围阐明书包罗以下内容（大概直接列出或参引其他文件）：

• 产物范围描述：渐渐细化在项目章程和需求文件中所述的产物、服务或成果的特征。
  
• 可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产物、成果或服务本事，可交付成果也包罗各种辅助成果，如项目管理陈诉和文件。对可交付成果的描述可略可详。
  
• 验收标准：可交付成果通过验收前必须满意的一系列条件。
  
• 项目标除外责任：识别排除在项目之外的内容。明确阐明哪些内容不属于项目范围，有助于管理相关方的期望及淘汰范围蔓延。
  

虽然项目章程和项目范围阐明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包罗高层级的信息，而项目范围阐明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。

5.3.3.2 项目文件更新

可在本过程更新的项目文件包罗（但不限于）：

• 假设日志：随同本过程识别出更多的假设条件或制约因素而更新假设日志。
  
• 需求文件：可以通过增加或修改需求而更新需求文件。
  
• 需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵。
  
• 相关方登记册：如果在本过程中收集到了现有或新相关方的更多信息，则纪录到相关方登记册中。
  

5.4 创建WBS

界说： 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
主要作用： 为所要交付的内容提供架构，它仅开展一次或仅在项目标预界说点开展。

WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 构造并界说了项目标总范围，代表着经答应的当前项目范围阐明书中所规定的工作。
WBS 最低层的组成部分称为工作包，其中包罗计划的工作。工作包对相关运动进行归类，以便对工作安排进度、进行估算、开展监督与控制。在“工作分解布局”这个词语中，“工作”是指作为运动效果的工作产物或可交付成果，而不是运动本身。
5.4.1 创建 WBS：输入

5.4.1.1 项目管理计划

项目管理计划组件包罗（但不限于）范围管理计划。范围管理计划界说了怎样根据项目范围阐明书创建 WBS。
5.4.1.2 项目文件

• 项目范围阐明书：项目范围阐明书描述了需要实施的工作及不包罗在项目中的工作。
  
• 需求文件：需求文件详细描述了各种单一需求怎样满意项目标业务需要。
  

5.4.1.3 奇迹情况因素

会影响创建 WBS 过程的奇迹情况因素包罗（但不限于）项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料。
5.4.1.4 构造过程资产

• 用于创建 WBS 的政策、程序和模板
  
• 以往的项目档案
  
• 以往的项目经验教训
  

5.4.2 创建 WBS：工具与技术

5.4.2.1 专家判断

5.4.2.2 分解

分解是一种把项目范围和项目可交付成果渐渐分别为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其本钱和一连时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目标高效管理；工作包的详细程度则因项目规模和复杂程度而异。要把整个项目工作分解为工作包，通常需要开展以下运动：

• 识别和分析可交付成果及相关工作
  
• 确定 WBS 的布局和编排方法
  
• 自上而下逐层细化分解
  
• 为 WBS 组成部分制定和分配标识编码
  
• 核实可交付成果分解的程度是否恰当
  

创建 WBS 的方法多种多样，常用的方法包罗自上而下的方法、使用构造特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次组件。WBS 的布局可以采用多种形式，例如：

• 以项目生命周期的各阶段作为分解的第二层，把产物和项目可交付成果放在第三层
  
• 以主要可交付成果作为分解的第二层
  
• 纳入由项目团队以外的构造开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。
  

对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最根本的组成部分，即可核实的产物、服务或成果。如果采用灵敏方法，可以将长篇故事分解成用户故事。WBS 可以采用提要式、构造布局图或能阐明层级布局的其他形式。==通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充实的工作，来核实分解的正确性。==不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。==工作分解得越细致，对工作的规划、管理和控制就越有力。==但是，==过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，==同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件，当前大概无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分告竣同等意见，才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。
WBS 包罗了全部的产物和项目工作，包罗项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。这有时被称为 100% 规则。
5.4.3 创建 WBS：输出

5.4.3.1 范围基准

范围基准是经过答应的范围阐明书、WBS 和相应的 WBS 词典，只有通过正式的变动控制程序才能进行变动，它被用作比较的基础。范围基准是项目管理计划的组成部分，包罗：

• 项目范围阐明书：项目范围阐明书包罗对项目范围、主要可交付成果、假设条件和制约因素的描述。
  
• WBS：WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解布局每向下分解一层，代表对项目工作更详细的界说。
  
• 工作包：WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行本钱、进度和资源信息的逐层汇总提供了层级布局，构成账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以丈量绩效。控制账户拥有两个或更多工作包，但每个工作包只与一个控制账户关联。
  
• 规划包：一个控制账户可以包罗一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解布局组件，工作内容已知，但详细的进度运动未知。
  
• WBS词典：WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、运动和进度信息的 文件。WBS 词典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。
  

以下是一个WBS词典的demo

5.4.3.2 项目文件更新

• 假设日志：随同本过程识别出更多的假设条件或制约因素而更新假设日志。
  
• 需求文件：可以更新需求文件，以反映在本过程提出并已被答应的变动。
  

5.5 确认范围

界说： 正式验收已完成的项目可交付成果的过程。
主要作用： 使验收过程具有客观性；同时通过确认每个可交付成果，来进步终极产物、服务或成果得到验收的大概性。本过程应根据需要在整个项目期间定期开展。

由客户或发起人检察从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和终极验收，需要依据：从项目范围管理知识领域的各规划过程得到的输出（如需求文件或范围基准），以及从其他知识领域的各实行过程得到的工作绩效数据。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满意质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
确认范围的几点问题

各个交付成果的关系图

5.5.1 确认范围：输入

5.5.1.1 项目管理计划

• 范围管理计划：项目管理计划界说了怎样正式验收已经完成的可交付成果。
  
• 需求管理计划：需求管理计划描述了怎样确认项目需求。
  
• 范围基准：用范围基准与实际效果比较，以决定是否有必要进行变动、采取改正措施或预防措施。
  

5.5.1.2 项目文件

• 经验教训登记册：在项目早期得到的经验教训可以运用到后期阶段，以进步验收可交付成果的效率与效果。
  
• 质量陈诉：质量陈诉的内容可包罗由团队管理或需上报的全部质量包管事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产物之前，需要查看所有这些内容。
  
• 需求文件：将需求与实际效果比较，以决定是否有必要进行变动、采取改正措施或预防措施。
  
• 需求跟踪矩阵：需求跟踪矩阵含有与需求相关的信息，包罗怎样确认需求。
  

5.5.1.3 核实的可交付成果

核实的可交付成果是指已经完成，并被控制质量过程查抄为正确的可交付成果。
5.5.1.4 工作绩效数据

工作绩效数据大概包罗符合需求的程度、不同等的数量、不同等的严重性或在某时间段内开展确认的次数。
5.5.2 确认范围：工具与技术

5.5.2.1 查抄

查抄是指开展丈量、检察与确认等运动，来判断工作和可交付成果是否符合需求和产物验收标准。查抄有时也被称为检察、产物检察和巡检等。在某些应用领域，这些术语具有独特和具体的含义。
5.5.2.2 决议

当由项目团队和其他相关方进行验收时，使用投票来形成结论。
5.5.3 确认范围：输出

5.5.3.1 验收的可交付成果

符合验收标准的可交付成果应该由客户或发起人正式签字答应。应该从客户或发起人那里得到正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给竣事项目或阶段过程。
5.5.3.2 工作绩效信息

工作绩效信息包罗项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及缘故原由。这些信息应该被纪录下来并通报给相关方。
5.5.3.3 变动请求

对已经完成但未通过正式验收的可交付成果及其未通过验收的缘故原由，应该纪录在案。大概需要针对这些可交付成果提出变动请求，开展缺陷调停。变动请求应该由实施团体变动控制过程进行检察与理。
5.5.3.4 项目文件更新

• 经验教训登记册：更新经验教训登记册，以纪录所碰到的挑战、本应怎样避免该挑战，以及良好的可交付成果验收方法。
  
• 需求文件：纪录实际的验收效果，更新需求文件。需要特殊注意实际效果比原定需求更好的情况，大概原定需求已经被放弃的情况。
  
• 需求跟踪矩阵：根据验收效果更新需求跟踪矩阵，包罗所采用的验收方法及其，使用效果。
  

5.6 控制范围

界说： 监督项目和产物的范围状态，管理范围基准变动的过程。
主要作用： 在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

控制项目范围确保所有变动请求、推荐的改正措施或预防措施都通过实施团体变动控制过程进行处理。在变动实际发生时，也要采用控制范围过程来管理这些变动。控制范围过程应该与其他控制过程协调开展。未经控制的产物或项目范围的扩大（未对时间、本钱和资源做相应调整）被称为范围蔓延。变动不可避免，因此在每个项目上，都必须逼迫实施某种形式的变动控制。
5.6.1 控制范围：输入

5.6.1.1 项目管理计划

• 范围管理计划：范围管理计划纪录了怎样控制项目和产物范围。
  
• 需求管理计划：本钱管理计划纪录了怎样管理项目需求。
  
• 变动管理计划：变动管理计划界说了管理项目变动的过程。
  
• 配置管理计划：配置管理计划界说了哪些是配置项，哪些配置项需要正式变动控制，以及针对这些配置项的变动控制过程。
  
• 范围基准：用范围基准与实际效果比较，以决定是否有必要进行变动、采取改正措施或预防措施。
  
• 绩效丈量基准：使用挣值分析时，将绩效丈量基准与实际效果比较，以决定是否有必要进行变动、采取改正措施或预防措施。
  

5.6.1.2 项目文件

• 经验教训登记册：在项目早期得到的经验教训可以运用到后期阶段，以改进范围控制。
  
• 需求文件：需求文件用于发现任何对商定的项目或产物范围的偏离。
  
• 需求跟踪矩阵：需求跟踪矩阵有助于探查任何变动或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
  

5.6.1.3 工作绩效数据

工作绩效数据大概包罗收到的变动请求的数量、接受的变动请求的数量，大概核实、确认和完成的可交付成果的数量。
5.6.1.4 构造过程资产

• 现有的、正式和非正式的，与范围控制相关的政策、程序和指南
  
• 可用的监督和陈诉的方法与模板
  

5.6.2 控制范围：工具与技术

5.6.2.1 数据分析

• 偏差分析：偏差分析用于将基准与实际效果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取改正或预防措施。
  
• 趋势分析：趋势分析旨在检察项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
  
  
  
  

确定偏离范围基准的缘故原由和程度，并决定是否需要采取改正或预防措施，是项目范围控制的紧张工作。
5.6.3 控制范围：输出

5.6.3.1 工作绩效信息

本过程产生的工作绩效信息是有关项目和产物范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包罗收到的变动的分类、识别的范围偏差和缘故原由、偏差对进度和本钱的影响，以及对未来范围绩效的预测。
5.6.3.2 变动请求

分析项目绩效后，大概会就范围基准和进度基准，或项目管理计划的其他组成部分提出变动请求。变动请求需要经过实施团体变动控制过程的检察和处理。
5.6.3.3 项目管理计划更新

项目管理计划的任何变动都以变动请求的形式提出，且通过构造的变动控制过程进行处理。大概需要变动请求的项目管理计划组成部分包罗（但不限于）：

• 范围管理计划：可以更新范围管理计划，以反映范围管理方式的变动。
  
• 范围基准：在针对范围、范围阐明书、WBS 或 WBS 词典的变动得到答应后，需要对范围基准做出相应的变动。有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效丈量提供现实可行的依据。
  
• 进度基准：在针对范围、资源或进度估算的变动得到答应后，需要对进度基准做出相应的变动。有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效丈量提供现实可行的依据。
  
• 本钱基准：在针对范围、资源或本钱估算的变动得到答应后，需要对本钱基准做出相应的变动。有时本钱偏差太过严重，以至于需要修订本钱基准，以便为绩效丈量提供现实可行的依据。
  
• 绩效丈量基准：在针对范围、进度绩效或本钱估算的变动得到答应后，需要对绩效丈量基准做出相应的变动。有时绩效偏差太过严重，需要提出变动请求来修订绩效丈量基准，以便为绩效丈量提供现实可行的依据。
  

5.6.3.4 项目文件更新

• 经验教训登记册：更新经验教训登记册，以纪录控制范围的有用技术，以及造成偏差的缘故原由和选择的改正措施。
  
• 需求文件 ：可以通过增加或修改需求而更新需求文件。
  
• 需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。