全部展开 全部合拢

5.1.3.1 范围管理计划

范围管理计划项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定:

根据项目需要,范围管理计划可以是正式或非正式的,非常详细或高度概括的。

项目管理计划是说明项目执行、监控和收尾方式的一份文件,它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件,取决于具体项目的需求。

项目管理计划组件包括(但不限于):

  • 子管理计划:
  • 范围管理计划。见 5.1.3.1 节。确立如何定义、制定、监督、控制和确认项目范围。
  • 需求管理计划。见 5.1.3.2 节。确定如何分析、记录和管理需求。
  • 进度管理计划。见 6.1.3.1 节。为编制、监督和控制项目进度建立准则并确定活动。
  • 成本管理计划。见 7.1.3.1 节。确定如何规划、安排和控制成本。
  • 质量管理计划。见 8.1.3.1 节。确定在项目中如何实施组织的质量政策、方法和标准。
  • 资源管理计划。见 9.1.3.1 节。指导如何对项目资源进行分类、分配、管理和释放。
  • 沟通管理计划。见 10.1.3.1 节。确定项目信息将如何、何时、由谁来进行管理和传播。
  • 风险管理计划。见 11.1.3.1 节。确定如何安排与实施风险管理活动。
  • 采购管理计划。见 12.1.3.1 节。确定项目团队将如何从执行组织外部获取货物和服务。
  • 相关方参与计划。见 13.2.3.1 节。确定如何根据相关方的需求、利益和影响让他们参与项目决策和执行。
  • 基准:
  • 范围基准。见 5.4.3.1 节。经过批准的范围说明书、工作分解结构 (WBS) 和相应的 WBS 词典,用作比较依据。
  • 进度基准。见 6.5.3.1 节。经过批准的进度模型,用作与实际结果进行比较的依据。
  • 成本基准。见 7.3.3.1 节。经过批准的、按时间段分配的项目预算,用作与实际结果进行比较的依据。
  • 其他组件。大多数项目管理计划组件都来自于其他过程,虽然有些组件是在本过程生成的。

虽然在本过程生成的组件会因项目而异,但是通常包括(但不限于):

  • 变更管理计划。描述在整个项目期间如何正式审批和采纳变更请求。
  • 配置管理计划。描述如何记录和更新项目的特定信息,以及该记录和更新哪些信息,以保持产品、服务或成果的一致性和(或)有效性。
  • 绩效测量基准。经过整合的项目范围、进度和成本计划,用作项目执行的比较依据,以测量和管理项目绩效。
  • 项目生命周期。描述项目从开始到结束所经历的一系列阶段。
  • 开发方法。描述产品、服务或成果的开发方法,例如预测、迭代、敏捷或混合型模式。
  • 管理审查。确定项目经理和有关相关方审查项目进展的时间点,以考核绩效是否符合预期,或者确定是否有必要采取预防或纠正措施。

项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划,但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。

表 4-1项目管理计划和项目文件

项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。

项目范围管理过程包括:

5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。

5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。

5.3 定义范围 — 制定项目和产品详细描述的过程。

5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。

5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。

5.6 控制范围 — 监督项目和产品的范围状态,管理范围基准变更的过程。

图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出

现,但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。

图 5-1项目范围管理概述

项目范围管理的核心概念在项目环境中,“范围”这一术语有两种含义:

  • 产品范围。某项产品、服务或成果所具有的特征和功能。
  • 项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。

从预测型方法到适应型或敏捷型方法,项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期,旨在应对大量变更,需要相关方持续参与项目;因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完项)。在一个迭代开始时,团队将努力确定产品未完项中,哪些最优先项应在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:收集需求、定义范围和创建 WBS。相反,在预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围。相反,在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程。

在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更。在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。在这里,“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入,而验收的可交付成果是确认范围过程的输出之一,由获得授权的相关方正式签字批准。因此,相关方需要在规划阶段早期介入(有时需要在启动阶段就介入),对可交付成果的质量提出意见,以便控制质量过程能够据此评估绩效并提出必要的变更建议。

目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点,并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂,组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理:实践指南》[14],需求管理过程始于需要评估,而需要评估又可能始于项目组合规划、项目集规划或单个项目。

在项目范围管理过程中,收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括(但不限于)注重与商业分析专业人士的合作,以便:

  • 确定问题并识别商业需要;
  • 识别并推荐能够满足这些需要的可行解决方案;
  • 收集、记录并管理相关方需求,以满足商业和项目目标;
  • 推动项目集或项目的产品、服务或最终成果的成功应用 [7]。

需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。

应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责,项目成功的可能性就更大。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括(但不限于):

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了在未来项目中重复使用需求,项目经理应建立哪些指南?
  • 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南?
  • 开发方法。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 需求的稳定性。项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求,直至需求稳定且定义明确?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。本过程的主要作用是,在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 5-2 描述本过程的输入、工具与技术和输出。图 5-3 是本过程的数据流向图。

图 5-2规划范围管理:输入、工具与技术和输出

图 5-3规划范围管理:数据流向图

范围管理计划是项目或项目集管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析:项目章程(见 4.1.3.1 节)中的信息、项目管理计划(见 4.2.3.1 节)中已批准的子计划、组织过程资产(见 2.3 节)中的历史信息和相关事业环境因素(见 2.2 节)。

项目团队可以参加项目会议来制定范围管理计划。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人,以及其他必要人员。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。范围管理计划包含如何定义和制定项目范围的信息。
  • 需求管理计划。见 5.1.3.2 节。需求管理计划包含如何收集、分析和记录项目需求的信息。
  • 相关方参与计划。见 13.2.3.1 节。从相关方参与计划中了解相关方的沟通需求和参与程度,以便评估并适应相关方对需求活动的参与程度。

见 4.2.3.1 节。项目管理计划组件包括(但不限于)范围管理计划(见 5.1.3.1 节),其中记录了如何定义、确认和控制项目范围。

项目管理计划组件包括(但不限于)范围管理计划。见 5.1.3.1 节,范围管理计划定义了如何根据项目范围说明书创建 WBS。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。项目管理计划定义了如何正式验收已经完成的可交付成果。
  • 需求管理计划。见 5.1.3.2 节。需求管理计划描述了如何确认项目需求。
  • 范围基准。见 5.4.3.1 节。用范围基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。范围管理计划记录了如何控制项目和产品范围。
  • 需求管理计划。见 5.1.3.2 节。成本管理计划记录了如何管理项目需求。
  • 变更管理计划。见 4.2.3.1 节。变更管理计划定义了管理项目变更的过程。
  • 配置管理计划。见 4.2.3.1 节。配置管理计划定义了哪些是配置项,哪些配置项需要正式变更控制,以及针对这些配置项的变更控制过程。
  • 范围基准。见 5.4.3.1 节。用范围基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施。
  • 绩效测量基准。见 4.2.3.1 节。使用挣值分析时,将绩效测量基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施。

项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。可以更新范围管理计划,以反映范围管理方式的变更。
  • 范围基准。见 5.4.3.1 节。在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后,需要对范围基准做出相应的变更。有时范围偏差太过严重,以至于需要修订范围基准,以便为绩效测量提供现实可行的依据。
  • 进度基准。见 6.5.3.1 节。在针对范围、资源或进度估算的变更获得批准后,需要对进度基准做出相应的变更。有时进度偏差太过严重,以至于需要修订进度基准,以便为绩效测量提供现实可行的依据。
  • 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更。有时成本偏差太过严重,以至于需要修订成本基准,以便为绩效测量提供现实可行的依据。
  • 绩效测量基准。见 4.2.3.1 节。在针对范围、进度绩效或成本估算的变更获得批准后,需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重,需要提出变更请求来修订绩效测量基准,以便为绩效测量提供现实可行的依据。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。范围管理计划描述如何定义和制定范围,并提供有关如何制定进度计划的信息。
  • 开发方法。见 4.2.3.1 节。产品开发方法有助于定义进度计划方法、估算技术、进度计划编制工具以及用来控制进度的技术。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。范围管理计划说明如何在项目的实施阶段管理承包商的工作范围。
  • 质量管理计划。见 8.1.3.1 节。质量管理计划包含项目需要遵循的行业标准与准则。这些标准与准则应写入招标文件,如建议邀请书,并将最终在合同中引用。这些标准与准则也可用于供应商资格预审,或作为供应商甄选标准的一部分。
  • 资源管理计划。见 9.1.3.1 节。资源管理计划包括关于哪些资源需要采购或租赁的信息,以及任何可能影响采购的假设条件或制约因素。
  • 范围基准。见 5.4.3.1 节。范围基准包含范围说明书、WBS 和 WBS 词典。在项目早期,项目范围可能仍要继续演进。应该针对项目范围中已知的工作,编制工作说明书 (SOW) 和工作大纲 (TOR)。

见 4.2.3.1 节。项目管理计划组件包括(但不限于):

  • 范围管理计划。见 5.1.3.1 节。范围管理计划描述如何管理总体工作范围,包括由卖方负责的工作范围。
  • 需求管理计划。见 5.1.3.2 节。需求管理计划描述将如何分析、记录和管理需求。 它可能还包括卖方将如何管理按协议规定应该实现的需求。
  • 沟通管理计划。见 10.1.3.1 节。沟通管理计划描述买方和卖方之间如何开展沟通。
  • 风险管理计划。见 11.1.3.1 节。风险管理计划是项目管理计划的组成部分,描述如何安排和实施项目风险管理活动。
  • 采购管理计划。见 12.1.3.1 节。采购管理计划包含在实施采购过程中应该开展的活动。
  • 配置管理计划。见 5.6.1.1 节。配置管理计划定义了哪些是配置项,哪些配置项需要正式变更控制,以及针对这些配置项的变更控制过程。它包括卖方开展配置管理的形式和过程,以便与买方采取的方法保持一致。
  • 成本基准。见 7.3.3.1 节。成本基准包括用于开展采购的预算,用于管理采购过程的成本,以及用于管理卖方的成本。

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。本过程的主要作用是,在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-3 描述了本过程的输入和输出。

图 3-3规划范围管理:输入和输出

究竟需要哪些项目管理计划组件,取决于具体项目的需求。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 需求管理计划;
  • 相关方参与计划。

可用作本过程输入的项目管理计划组件包括(但不限于)范围管理计划。

可用作本过程输入的项目管理计划组件包括(但不限于)范围管理计划。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 开发方法。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 质量管理计划;
  • 资源管理计划;
  • 范围基准。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 需求管理计划;
  • 沟通管理计划;
  • 风险管理计划;
  • 采购管理计划;
  • 配置管理计划;
  • 成本基准。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 需求管理计划;
  • 范围基准。

可用作本过程输入的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 需求管理计划;
  • 变更管理计划;
  • 配置管理计划;
  • 范围基准;
  • 绩效测量基准。

可在本过程更新的项目管理计划组件包括(但不限于):

  • 范围管理计划;
  • 范围基准;
  • 进度基准;
  • 成本基准;
  • 绩效测量基准。