Index

所属知识领域:项目范围管理
所属过程组:监控过程组
第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.5 确认范围
post_title:确认范围
post_content:

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是,使验收过程具有客观性;同时通过确认每个可交付成果,来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。图 5-15 描述本过程的输入、工具与技术和输出。图 5-16 是本过程的数据流向图。

图 5-15确认范围:输入工具与技术和输出

图 5-16确认范围:数据流向图

由客户或发起人审查从控制质量过程输出的核实的可交付成果,确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收,需要依据:从项目范围管理知识领域的各规划过程获得的输出(如需求文件范围基准),以及从其他知识领域的各执行过程获得的工作绩效数据

确认范围过程与控制质量过程的不同之处在于,前者关注可交付成果的验收,而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程,但二者也可同时进行。


ID:270
areaid:1
groupid:5
type:out
post_name: 4.7.3.4
post_title: 组织过程资产更新
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理 / 4.7 结束项目或阶段 / 4.7.3 结束项目或阶段:输出 / 4.7.3.4 组织过程资产更新
post_content:

需要更新的组织过程资产包括(但不限于):

如果项目在完工前提前终止,则需要在正式的收尾文件中说明项目终止的原因,并规定正式程序,把该项目的已完成和未完成的可交付成果移交他人。


ID:271
areaid:2
groupid:0
type:
post_name: 5
post_title: 项目范围管理
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理
post_content:

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

项目范围管理过程包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ID:280
areaid:2
groupid:2
type:tt
post_name: 5.1.2.2
post_title: 数据分析
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.1 规划范围管理 / 5.1.2 规划范围管理:工具与技术 / 5.1.2.2 数据分析
post_content:

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


ID:597
areaid:5
groupid:4
type:out
post_name: 8.3.3.2
post_title: 核实的可交付成果
post_excerpt: 第一部分 项目管理知识体系指南 / 8 项目质量管理 / 8.3 控制质量 / 8.3.3 控制质量:输出 / 8.3.3.2 核实的可交付成果
post_content:

控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果是核实的可交付成果,后者又是确认范围过程的一项输入(见 5.5 节),以便正式验收。如果存在任何与可交付成果有关的变更请求或改进事项,可能会执行变更、开展检查并重新核实。


ID:1261
areaid:0
groupid:0
type:
post_name: X3.3.4
post_title: 监控过程组
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.3 适应型环境中的过程组 / X3.3.4 监控过程组
post_content:

监控过程组指的是跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更所需的一组过程。

在迭代型、敏捷型和适应型方法中,通过维护未完项清单,对进展和绩效进行跟踪、审查和调整。在项目团队的协助(分析并提供有关技术依赖关系的信息)下,业务代表对未完项进行优先级排序。基于业务优先级和团队能力,提取未完项清单最前面的任务,供下一个迭代期完成。业务代表在听取项目团队的技术意见之后,评审变更请求和缺陷报告,排列所需变更或补救的优先级,并列入工作未完项清单。

这种把工作和变更列入同一张清单的做法,起源于充满变更的项目环境。在这种项目环境中,无法把变更从原先计划的工作中分离出来。把变更和原先的工作整合到一张未完项清单中,就便于对全部工作进行重新排序,也能够为相关方管理和控制项目工作、实施变更控制和确认范围提供单一的平台。

随着排定了优先级的任务和变更从未完项清单中提取出来,并通过迭代加以完成,就可以测算已完成工作的趋势和指标,以及变更工作量和缺陷率。通过在短期迭代中频繁抽样,计算变更影响的数量和缺陷补救工作量,就可以对照原来的范围来考察团队能力和工作进展。这样一来,就能基于实际的进展速度和变更影响来估算项目成本、进度和范围。

应该借助趋势图表(信息扩散器)与项目相关方分享这些指标和预测,以便沟通进展情况、共同面对问题、推动持续改进,以及管理相关方期望。