Index

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

控制范围是监督项目和产品的范围状态,管理范围基准变更的过程。本过程的主要作用是,在整个项目期间保持对范围基准的维护,且需要在整个项目期间开展。图 5-17 描述本过程的输入、工具与技术和输出。图 5-18 是本过程的数据流向图。

图 5-17控制范围:输入工具与技术和输出

图 5-18控制范围:数据流向图

控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程(见 4.6 节)进行处理。在变更实际发生时,也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。变更不可避免,因此在每个项目上,都必须强制实施某种形式的变更控制。

.


ID:143
areaid:0
groupid:0
type:
post_name: 3.5.1
post_title: 在过程层面执行整合
post_excerpt: 第一部分 项目管理知识体系指南 / 3 项目经理的角色 / 3.5 执行整合 / 3.5.1 在过程层面执行整合
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:357
areaid:2
groupid:4
type:in
post_name: 5.6.1.4
post_title: 组织过程资产
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.6 控制范围 / 5.6.1 控制范围:输入 / 5.6.1.4 组织过程资产
post_content:

能够影响控制范围过程的组织过程资产包括(但不限于):


ID:359
areaid:2
groupid:4
type:tt
post_name: 5.6.2.1
post_title: 数据分析
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.6 控制范围 / 5.6.2 控制范围:工具与技术 / 5.6.2.1 数据分析
post_content:

可用于控制范围过程的数据分析技术包括(但不限于):

确定偏离范围基准(见 5.4.3.1 节)的原因和程度,并决定是否需要采取纠正或预防措施,是项目范围控制的重要工作。


ID:364
areaid:2
groupid:4
type:out
post_name: 5.6.3.4
post_title: 项目文件更新
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.6 控制范围 / 5.6.3 控制范围:输出 / 5.6.3.4 项目文件更新
post_content:

可在本过程更新的项目文件包括(但不限于):


ID:402
areaid:3
groupid:2
type:tt
post_name: 6.3.2.2
post_title: 确定和整合依赖关系
post_excerpt: 第一部分 项目管理知识体系指南 / 6 项目进度管理 / 6.3 排列活动顺序 / 6.3.2 排列活动顺序:工具与技术 / 6.3.2.2 确定和整合依赖关系
post_content:

如下所述,依赖关系可能是强制或选择的,内部或外部的。这四种依赖关系可以组合成强制性外部依赖关系、强制性内部依赖关系、选择性外部依赖关系或选择性内部依赖关系。

例如,只有机器组装完毕,团队才能对其测试,这是一个内部的强制性依赖关系。在排列活动顺序过程中,项目管理团队应明确哪些依赖关系属于内部依赖关系。


ID:566
areaid:5
groupid:3
type:tt
post_name: 8.2.2.2
post_title: 数据分析
post_excerpt: 第一部分 项目管理知识体系指南 / 8 项目质量管理 / 8.2 管理质量 / 8.2.2 管理质量:工具与技术 / 8.2.2.2 数据分析
post_content:

适用于本过程的数据分析技术包括(但不限于):

一项根本原因可能引起多项偏差、缺陷或风险。根本原因分析还可以作为一项技术,用于识别问题的根本原因并解决问题。消除所有根本原因可以杜绝问题再次发生。