收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是,为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展。图 5-4 描述本过程的输入、工具与技术和输出。图 5-5 是本过程的数据流向图。
图 5-5收集需求:数据流向图
《PMBOK® 指南》并没有专门讨论产品需求,因为产品需求因行业而异。《从业者商业分析:
实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作(分解成项目和产品需求),并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功。需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求,将其包含在范围基准中,并在项目执行开始后对其进行测量。需求将成为工作分解结构(WBS)的基础,也将成为成本、进度、质量和采购规划的基础。
项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。
项目范围管理过程包括:
5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
5.3 定义范围 — 制定项目和产品详细描述的过程。
5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。
5.6 控制范围 — 监督项目和产品的范围状态,管理范围基准变更的过程。
图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出
现,但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。
图 5-1项目范围管理概述
项目范围管理的核心概念在项目环境中,“范围”这一术语有两种含义:
从预测型方法到适应型或敏捷型方法,项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。
采用适应型生命周期,旨在应对大量变更,需要相关方持续参与项目;因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完项)。在一个迭代开始时,团队将努力确定产品未完项中,哪些最优先项应在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:收集需求、定义范围和创建 WBS。相反,在预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。
在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围。相反,在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程。
在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更。在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。
项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。在这里,“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。
确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入,而验收的可交付成果是确认范围过程的输出之一,由获得授权的相关方正式签字批准。因此,相关方需要在规划阶段早期介入(有时需要在启动阶段就介入),对可交付成果的质量提出意见,以便控制质量过程能够据此评估绩效并提出必要的变更建议。
目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点,并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂,组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理:实践指南》[14],需求管理过程始于需要评估,而需要评估又可能始于项目组合规划、项目集规划或单个项目。
在项目范围管理过程中,收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括(但不限于)注重与商业分析专业人士的合作,以便:
需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。
应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。
项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责,项目成功的可能性就更大。
裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括(但不限于):
在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。
适用于本过程的数据分析技术包括(但不限于)备选方案分析。本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。
见 1.2.6 节。会影响收集需求过程的商业文件是商业论证,它描述了为满足业务需要而应该达到的必要、期望及可选标准。
会影响收集需求过程的事业环境因素包括(但不限于):
会影响收集需求过程的组织过程资产包括(但不限于):
适用于收集需求过程的决策技术包括(但不限于):
通常在候选项超过两个时使用。
见 4.1.2.3 节。可用于本过程的人际关系与团队技能包括(但不限于):
研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点,有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通,从而有利于相关方达成一致意见。此外,与分别召开会议相比,研讨会能够更早发现并解决问题。
适合采用引导技能的情境包括(但不限于):
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是,描述产品、服务或成果的边界和验收标准。图 5-8 描述本过程的输入、工具与技术和输出。图 5-9 是本过程的数据流向图。
图 5-8定义范围:输入、工具与技术和输出
图 5-9定义范围:数据流向图
由于在收集需求过程中识别出的所有需求未必都包含在项目中,所以定义范围过程就要从需求文件(收集需求过程的输出)中选取最终的项目需求,然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书,对项目成功至关重要。
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中,随着对项目信息的更多了解,应该更加详细具体地定义和描述项目范围。
此外,还需要分析现有风险、假设条件和制约因素的完整性,并做必要的增补或更新。需要多次反复开展定义范围过程:在迭代型生命周期的项目中,先为整个项目确定一个高层级的愿景,再一次针对一个迭代期明确详细范围。通常,随着当前迭代期的项目范围和可交付成果的进展,而详细规划下一个迭代期的工作。