软考高项~项目范围管理

这是一篇关于项目范围管理的思维导图，主要内容包括：管理基础，项目范围管理过程，规划范围管理，收集需求，定义范围，创建WBS，确认范围，控制范围。

项目范围管理

• 管理基础
  • 产品范围和项目范围
    • 产品范围
      • 指某项产品、服务或成果所具有的特征和功能 。 产品范围的完成情况是根据产品需求来衡量的。
    • 项目范围
      • 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完 成的工作 。 项目范围的完成情况是根据项目管理计划来衡量的 。
  • 管理新实践
    • 需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。
    • 如果项目己配备商业分析师，该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。
    • 项目经理与商业分析师之间应该是伙伴式合作关系。
• 项目范围管理过程
  • 过程概述
    • 规划范围管理
      • 为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划
    • 收集需求
      • 为了 实现项目目标，确定、记录并管理干系人的需要和需求
    • 定义范围
      • 制定项目和产品详细描述
    • 创建WBS
      • 将项目可交付成果和项目工作分解为较小的、更易于管理的组件。
    • 确认范围
      • 正式验收己完成的项目可交付成果
    • 控制范围
      • 监督项目和产品的范围状态，管理范围基准的变更
  • 概述图
  • 裁剪考虑因素
    • 知识和需求管理
      • 项目经理应建立哪些指南?为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系?
    • 确认和控制
      • 组织是否有正式或非正式的与确认和控制相关政策、程序和指南?
    • 开发方法
      • 组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
    • 需求的稳定性
      • 项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?
    • 治理
      • 组织是否拥有正式或非正式的审计和治理政策、程序和指南?
  • 敏捷与适应方法
    • 对于需求不断变化、风险大或不确定性高的项目， 在项目开始时通常无法明确项目的范围 ，而需要在项目期间逐渐明确 。
    • 敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间 。
    • 敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。
    • 在预测型项目中，经过批准的项目范围说明书、工作分解结构 ( WBS )和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。 在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完成项(包括产品需求和用户故事)反映当前需求 。
• 规划范围管理
  • 过程概述
    • 定义
      • 规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
    • 作用
      • 本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向
    • 开展节点
      • 仅开展一次或仅在项目的预定义点开展
    • 流程图
    • 其他概念
      • 范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围 。
  • 输入
    • 项目章程
      • 项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目想要实现的高层级的需求。
    • 项目管理计划
      • 质量管理计划
        • 在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
      • 项目生命周期描述
        • 定义了项目从开始到完成所经历的一系列阶段。
      • 开发方法
        • 开发方法定义了项目是采用预测型、适应型还是混合型开发方法。
    • 事业环境因素
      • 主要包括组织文化、基础设施、人事管理制度和市场条件等。
    • 组织过程资产
      • 主要包括政策和程序、历史信息和经验教训知识库等。
  • 工具和技术
    • 专家判断
    • 数据分析
      • 适用于本过程的数据分析技术是备选方案分析。 备选方案分析技术用于评估、收集需求，详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。
    • 会议
  • 输出
    • 范围管理计划
      • 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围 。
      • 范围管理计划用于指导如下过程和相关工作
        • 制定项目范围说明书
        • 根据详细项目范围说明书创建WBS
        • 确定如何审批和维护范围基准
        • 正式验收己完成的项目可交付成果
      • 根据项目需要， 范围管理计划可以是正式或非正式的，非常详细或高度概括的
    • 需求管理计划
      • 需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。
      • 需求管理计划的主要内容包括
        • 如何规划、跟踪和报告各种需求活动
        • 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
        • 需求优先级排序过程
        • 测量指标及使用这些指标的理由
        • 反映哪些需求属性将被列入跟踪矩阵等
• 收集需求
  • 过程概述
    • 定义
      • 收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程
    • 作用
      • 为定义产品范围和项目范围奠定基础
    • 开展节点
      • 仅开展一次或仅在项目的预定义点开展
    • 流程图
    • 其他概念
      • 让干系人积极参与需求的探索和分解工作(分解成项目和产品需求) ，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的己量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执行开始后对其进行测量。需求将作为后续工作分解结构 ( WBS)的基础，也将作为成本、进度、质量和采购规划的基础。
  • 输入
    • 立项管理文件
      • 会影响收集需求过程的立项管理文件是商业论证产生的文件，它描述了为满足业务需要而应该达到的必要、期望及可选标准 。
    • 项目章程
      • 项目章程记录了项目概述以及将用于制定详细需求的高层级需求。
    • 项目管理计划
      • 范围管理计划：包含如何定义和制定项目范围的信息。
      • 需求管理计划：包含如何收集、分析和记录项目需求的信息。
      • 干系人参与计划：从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。
    • 项目文件
      • 假设日志：识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件。
      • 干系人登记册：用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。
      • 经验教训登记册：提供了有效的需求收集技术 ，尤其针对使用敏捷或适应型产品开发方法的项目。
    • 协议
      • 协议会包含项目和产品需求。
    • 事业环境因素
      • 主要包括:组织文化、基础设施、人事管理制度、市场条件等。
    • 组织过程资产
      • 主要包括：政策和程序;包含以往项目信息的历史信息和经验教训知识库等。
  • 工具和技术
    • 专家判断
    • 数据收集
      • 头脑风暴
        • 是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
      • 访谈
        • 是通过与干系人直接交谈，来获取信息的正式或非正式的方法。
        • 访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。 访谈经常是一个访谈者和一个被访者之间的"一对一 "谈话，但也可包括多个访谈者或多个被访者。 访谈有经验的项目参与者、发起人和其他商管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。 访谈也可用于获取机密信息。
      • 焦点小组
        • 是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。 焦点小组往往比" 一对一"的访谈更热烈。
      • 问卷调查
        • 是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。
      • 标杆对照
        • 将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较， 以便识别最佳实践，形成改进意见，并为绩效考核提供依据。 标杆对照所采用的可比组织可以是内部的，也可以是外部的。
    • 数据分析
      • 可用于收集需求过程的数据分析技术是文件分析。文件分析指审核和评估任何相关的文件信息。在此过程中 ，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求
    • 决策
      • 投票
        • 是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过 程。本技术用于生成、归类和排序产品需求
      • 独裁型决策制定
        • 采用这种方法，将由一个人负责为整个集体制定决策
      • 多标准决策分析
        • 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
    • 数据表现
      • 亲和图
        • 用来对大量创意进行分组的技术 ，以便进一步审查和分析。
      • 思维导图
        • 把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差 异，激发新创意 。
    • 人际关系与团队技能
      • 名义小组技术
        • 是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
      • 观察和交谈
        • 是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。 当产品使用 者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细节。 观察也称为"工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由"参与观察者"来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
      • 引导
        • 引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。 研讨会可用于快速定义跨职能需求并协调干系人的需求差异 。
    • 系统交互图
      • 系统交互图是对产品范围的可视化描绘，可以直观显示业务系统(过程、设备、计算机系统等)及其与人和其他系统 ( 行动者)之间的交互方式。
    • 原型法
      • 原型法是指在实际制造预期产品之前 ，先造出该产品的模型，并据此征求对需求的早期反馈。
      • 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。 故事板用于各种行业的各种项目中 ，如电影、广告、教学设计以及敏捷和其他软件开发项目 .在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
  • 输出
    • 需求文件
      • 需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。 只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求， 才能作为基准。 需求文件的格式多种多样， 既可以是一份按干系人和优先级分类列出全部需求的简单文件， 也可以是一份包括内容提要、细节描述和附件等的详细文件。
      • 需求的类别
        • 业务需求
          • 整个组织的高层级需要
        • 干系人需求
          • 干系人的需要
        • 解决方案需求
          • 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征
          • 功能需求
            • 描述产品应具备的功能 例如，产品应该执行的行动、流程、数据和交互:
          • 非功能需求
            • 是对功能需求的补充，是产品正常运行所需的环境条件或质量要求 例如， 可靠性、保密性、性能、安全性、服务水平、可支持性、保留或消除等
        • 过渡和就绪需求
          • 如数据转换和培训需求。这些需求描述了从"当前状态"过渡到"将来状态"所需的临时能力。
        • 项目需求
          • 项目需要满足的行动、过程或其他条件， 例如里程碑日期、合同责任、制约因素等。
        • 质量需求
          • 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。
    • 需求跟踪矩阵
      • 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵， 把每个市求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。 需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。
      • 跟踪需求的内容包括
        • ①业务需要、机会、目的和目标
        • ②项目目标:
        • ③项目范围和WBS 可交付成果:
        • ④产品设计
        • ⑤产品开发.
        • ⑥测试策略和测试场景:
        • ⑦高层级需求到详细需求等。
      • 需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。 为确保干系人满意，可能需要增加一些补充属性， 如稳定性、复杂性和验收标准。
• 定义范围
  • 过程概述
    • 定义
      • 定义范围是制定项目和产品详细描述的过程。
    • 作用
      • 描述产品、服务或成果的边界和验收标准。
    • 开展节点
      • 在整个项目期间多次反复开展
    • 流程图
    • 其他概念
      • 由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文件(收集需求过程的输出)中选取最终的项目需求， 然后制定出关于项目及其产品、服务或成果的详细描述。 准备好详细项目范围说明书，对项目成功至关重要。 应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息了解的逐渐深入， 应该更加详细、具体地定义和描述项目范围。此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。
  • 输入
    • 项目章程
      • 项目章程中包含对项目的高层级描述、产品特征和审批要求。
    • 项目管理计划
      • 定义范围中使用的项目管理计划组件是范围管理计划， 其中记录了如何定义、确认和控制项目范围。
    • 项目文件
      • 假设日志
        • 识别了有关产品、项目、环境、干系人以及会影响项目和产品范围的假设条件和制约因素。
      • 需求文件
        • 识别了应纳入范围的需求。
      • 风险登记册
        • 包含了可能影响项目范围的应对策略
    • 事业环境因素
      • 主要包括.组织文化、基础设施、人事管理制度、市场条件等。
    • 组织过程资产
      • 主要包括·用于制定项目范围说明书的政策、程序和模板；以往项目的项目档案，以往阶段或项目的经验教训等。
  • 工具和技术
    • 专家判断
      • 征求具备类似项目的知识或经验的个人或小组的意见
    • 数据分析
      • 可用于定义范围过程的数据分析技术是备选方案分析。 备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。
    • 决策
      • 可用于定义范围过程的决策技术是多标准决策分析。 多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。
    • 人际关系和团队技能
      • 人际关系与团队技能的一个典型示例是引导。 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键干系人，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
    • 产品分析
      • 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。 用以把高层级的产品或服务描述转变为有意义的可交付成果。 产品分析技术主要包括: 产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。
  • 输出
    • 项目范围说明书
      • 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围， 包括：项目和产品范围；详细描述了项目的可交付成果；代表项目干系人之间就项目范围所达成的共识。 为便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
      • 详细的项目范围说明书包括内容
        • 产品范围描述
          • 逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
        • 可交付成果
          • 为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。 对可交付成果的描述可略可详。
        • 验收标准
          • 可交付成果通过验收前必须满足的一系列条件。
        • 项目的除外责任
          • 明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
    • 项目文件（更新）
      • 假设日志
        • 随同本过程识别出更多的假设条件或制约因素， 从而更新假设日志。
      • 需求文件
        • 可以通过增加或修改需求而更新需求文件。
      • 需求跟踪矩阵
        • 应该随同需求文件的更新而更新需求跟踪矩阵。
      • 干系人登记册
        • 如果在定义范围过程中收集到了现有或新干系人的更多信息，则记录到干系人登记册中。
• 创建WBS
  • 过程概述
    • 定义
      • 创建工作分解结构( WBS ) 是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程.
    • 作用
      • 是为所要交付的内容提供架构
    • 开展节点
      • 仅开展一次或仅在项目的预定义点开展
    • 流程图
    • 其他概念
      • WBS 是对项目团队为实现项目目标， 创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。 WBS 最低层的组成部分称为工作包， 其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排迸度， 进行估算，开展监督与控制。在" 工作分解结构" 这个词语中"工作"是指作为活动结果的工作产品或可交付成果， 而不是活动本身。
  • 输入
    • 项目管理计划
      • 创建WBS 中使用的项目管理计划组件是范围管理计划
    • 项目文件
      • 需求文件
        • 详细描述了各种单一需求如何满足项目的业务需要。
      • 项目范围说明书
        • 描述了需要实施的工作以及不包含在项目中的工作。
    • 事业环境因素
      • 包括项目所在行业的WBS 标准，这些标准可以作为创建WBS 的外部参考资料。
    • 组织过程资产
      • 主要包括: 用于创建WBS 的政策、程序和模板；以往项目的项目档案；以往项目的经验教训等。
  • 工具和技术
    • 专家判断
      • 应征求具备类似项目知识或经验的个人或小组的意见.
    • 分解
      • 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。 工作包是WBS 最低层的工作，可对其成本和持续时间进行估算和管理。 创建WBS 的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南和使用WBS模板。自下而上的方法可用于归并较低层次的组件。
      • 分解活动
        • 把整个项目工作分解为工作包
        • ①识别和分析可交付成果及相关工作:
        • ②确定WBS 的结构和编排方法:
        • ③自上而下逐层细化分解:
        • ④为WBS 组成部分制定和分配标识编码；
        • ⑤核实可交付成果分解的程度是否恰当。
      • WBS结构
        • WBS可以采用多种形式
          • 以项目生命周期的各阶段作为分解的第二层， 把产品和项目可交付成果放在第三层。
          • 以主要可交付成果作为分解的第二层
          • 纳入由项目团队以外的组织开发的各种较低层次组件( 如外包工作) 。 作为外包工作的一部分，卖方须制定相应的合同WBS。
        • 对WBS 较高层组件进行分解， 就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。 如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。 WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。
        • 不同的可交付成果可以分解到不同的层次。
        • 工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低， 同时造成WBS 各层级的数据汇总困难。
        • 要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS 中的相应细节。这种技术又称为滚动式规划。
      • 注意事项
        • WBS必须是面向可交付成果的
          • 项目的目标是提供产品或服务， WBS 中的各项工作是为提供可交付的成果服务的
        • WBS必须符合项目的范围
          • WBS必须包括也仅包括为了完成项目的可交付成果的活动。 100%原则( 包含原则)认为，在WBS 中，所有下一级的元素之和必须100%代表上一级的元素。
        • WBS的底层应该支持计划和控制
          • WBS是项目管理计划和项目范围之间的桥梁. WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
        • WBS中的元素必须有人负责，且只有一个人负责
          • WBS和责任人可以使用工作责任矩阵来描述。
        • WBS应该控制在4-6层
          • 如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。 每个级别的WBS将上一级的一个元素分为4 -7个新元素，同一级元素的大小应该相似。 一个工作单元只能从属于某个上层单元，避免交叉从属。
        • WBS应包括项目管理工作(因为管理是项目具体工作的一部分)，也要包括分包出去的工作。
        • WBS 的编制需要所有(主要)项目干系人的参与
        • WBS并非是一成不变的
          • 在完成了WBS之后的工作中， 仍然有可能需要对WBS进行修改。
  • 输出
    • 范围基准
      • 范围基准是经过批准的范围说明书、WBS 和相应的WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。 范围基准是项目管理计划的组成部分。
      • 项目变更范围书
        • 项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
      • WBS
        • WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。 工作分解结构每向下分解一层，代表对项目工作更详细的定义。
      • 工作包
        • WBS 的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。 每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。 在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效。 控制账户包含两个或更多工作包， 每个工作包只与一个控制账户关联。
      • 规划包
        • 规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容己知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
      • WBS字典
        • WBS 字典是针对WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件，WBS 字典对WBS 提供支持， 其中大部分信息由其他过程创建，然后在后期添加到字典中。 WBS 字典中的内容一般包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
    • 项目文件（更新）
      • 假设日志
        • 随着创建WBS过程识别出更多假设条件或制约因素而更新。
      • 需求文件
        • 可以更新需求文件，以反映在创建WBS过程提出井已被批准的变更。
• 确认范围
  • 过程概述
    • 定义
      • 确认范围是正式验收己完成的项目可交付成果的过程。
    • 作用
      • ①使验收过程具有客观性:
      • ②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
    • 开展节点
      • 根据需要在整个项目期间定期开展
    • 流程图
    • 其他概念
      • 由主要干系人，尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。确认范围过程依据从项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准) ，以及从其他知识领域的执行过程获得的工作绩效数据，对可交付成果的确认和最终验收。
    • 确认范围的步骤
      • 确认范围应该贯穿项目的始终。
      • 确认范围的一般步骤包括
        • ①确定需要进行范围确认的时间:
        • ②识别范围确认需要哪些投入:
        • ③确定范围正式被接受的标准和要素:
        • ④确定范围确认会议的组织步骤:
        • ⑤组织范围确认会议。
      • 通常情况下， 在确认范围前，项目团队需要先进行质量控制工作，以确保确认工作的顺利完成。
      • 确认范围过程与控制质量过程的不同之处在于， 前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。 控制质量过程通常先于确认范围过程，但二者也可同时进行。
    • 需要检查的问题
      • 可交付成果是否是确定的、可确认的。
      • 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如， 客户的书面认可等。
      • 是否有明确的质量标准
      • 审核和承诺是否有清晰的表达
      • 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误.
      • 项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响.
    • 干系人关注点的不同
      • 管理层主要关注项目范围：是指范围对项目的迸度、资金和资源的影响， 这些因素是否超过了组织承受范围， 是否在投入产出上具有合理性。
      • 客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。 在项目中，客户往往有在当前版本中加入所有功能和特征的意愿， 这对于项目来说是一种潜在的风险， 会给组织和客户带来危害和损失。
      • 项目管理人员主要关注项目制约因素: 关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
      • 项目团队成员主要关注项目范围中自己参与的元素和负责的元素: 通过定义范围中的时间检查自己的工作时间是否足够， 自己在项目范围中是否有多项工作， 而这些工作是否有冲突的地方。
  • 输入
    • 项目管理计划
      • 范围管理计划
        • 定义了如何正式验收己经完成的可交付成果。
      • 需求管理计划
        • 描述了如何确认项目需求。
      • 范围基准
        • 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
    • 项目文件
      • 需求文件
        • 将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。
      • 需求跟踪矩阵
        • 含有与需求相关的信息，包括如何确认需求.
      • 质量报告
        • 该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
      • 经验教训登记册
        • 在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
    • 工作绩效数据
      • 工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
    • 核实的可交付成果
      • 核实的可交付成果是指已经完成， 并被控制质量过程检查为正确的可交付成果。
  • 工具和技术
    • 检查
      • 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。 检查有时也被称为审查、产品审查和巡检等。
    • 决策
      • 可用于确认范围过程的决策技术是投票 当由项目团队和其他干系人进行验收时，使用投票来形成结论。
  • 输出
    • 验收的可交付成果
      • 符合验收标准的可交付成果应该由客户或发起人正式签字批准。 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
    • 变更请求
      • 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展相应的缺陷补救工作。变更请求应该由实施整体变更控制过程进行审查与处理。
    • 工作绩效信息
      • 工作绩效信息包括项目进展信息，例如， 哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人。
    • 项目文件（更新）
      • 需求文件
        • 记录实际的验收结果， 更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求己经被放弃的情况。
      • 需求跟踪矩阵
        • 根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果.
      • 经验教训登记册
        • 更新经验教训登记册， 以记录所遇到的挑战、本应如何避免该挑战的方法，以及良好的可交付成果验收的方法。
• 控制范围
  • 过程概述
    • 定义
      • 监督项目和产品的范困状态， 管理范围基准变更的过程。
    • 作用
      • 在整个项目期间保持对范围基准的维护
    • 开展节点
      • 在整个项目期间开展
    • 流程图
    • 其他概念
      • 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。 在变更实际发生时， 也需要采用控制范围过程来管理这些变更。 控制范围过程应该与其他项目管理知识领域的控制过程协调开展。 未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整) 被称为范围蔓延。
  • 输入
    • 项目管理计划
      • 范围管理计划
        • 记录了如何控制项目和产品范围
      • 需求管理计划
        • 记录了如何管理项目需求
      • 变更管理计划
        • 定义了管理项目变更的过程
      • 配置管理计划
        • 定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
      • 范围基准
        • 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施.
      • 绩效测量基准
        • 使用挣值分析时， 将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施.
    • 项目文件
      • 需求文件
        • 用于发现任何对商定的项目或产品范围的偏离。
      • 需求跟踪矩阵
        • 有助于探查任何变更或对范围基准的任何偏离对项目目标的影响， 它还可以提供受控需求的状态。
      • 经验教训登记册
        • 项目早期的经验教训可以运用到后期阶段，以改进范围控制.
    • 工作绩效数据
      • 工作绩效数据可能包括收到的变更请求的数量， 接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。
    • 组织过程资产
      • 能够影响控制范围过程的组织过程资产主要包括. 现有的、正式的和非正式的与范围控制相关的政策、程序和指南: 可用的监督和报告的方法与模板等。
  • 工具和技术
    • 数据分析
      • 偏差分析
        • 用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
      • 趋势分析
        • 旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
      • 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
  • 输出
    • 工作绩效信息
      • 控制范围过程产生的工作绩效信息是有关项目和产品范围实施情况(对照范围基准)的相互关联且与各种背景相结合的信息
    • 变更请求
      • 分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。 变更请求需要经过实施整体变更控制过程的审查和处理。
    • 项目管理计划（更新）
      • 范围管理计划
        • 更新范围管理计划，以反映范围管理方式的变更。
      • 范围基准
        • 在针对范围、范围说明书、WBS或WB S词典的变更获得批准后，需要对范围基准做出相应的变更。
      • 进度基准
        • 在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。
      • 成本基准
        • 在针对范围、资源或成本估算的变更获得批准后， 需要对成本基准做出相应的变更。
      • 绩效测量基准
        • 在针对范围、进度续效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。
    • 项目文件（更新）
      • 需求文件
        • 可以通过增加或修改需求而更新需求文件。
      • 需求跟踪矩阵
        • 应该随同需求文件的更新而更新需求跟踪矩阵。
      • 经验教训登记册
        • 更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。