第五章 项目范围管理
基本介绍
- 项目管理的49个子过程，项目范围管理占
6个 - 项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内
- 项目范围管理过程包括
- 5.1 规划范围管理——为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
- 5.2 收集需求——为实现项目目标而确定、记录并管理相关方的需要和需求的过程
- 5.3 定义范围——制定项目和产品详细描述的过程
- 5.4 创建WBS——将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
- 5.5 确认范围——正式验收已完成的项目可交付成果的过程
- 5.6 控制范围——监督项目和产品的范围状态，管理范围基准变更的过程
核心概念
- 在项目环境中，“范围”这一术语有两种含义
- 产品范围：某项产品、服务或成果所具有的特征和功能
- 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围
- 在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理
- 适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围
- 采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建WBS
- 预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的WBS词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础
- 项目范围的完成情况是根据项目管理计划来衡量的，而产品范围的完成情况是根据产品需求来衡量的。在这里，“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力
发展趋势和新兴实践
- 需求一起是项目管理中的重点，并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂，组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始
- 在项目范围管理过程中，收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括（但不限于）注重与商业分析专业人士的合作，以便
- 确定问题并识别商业需要
- 识别并推荐能够满足这些需要的可行解决方案
- 收集、记录并管理相关方需求，以满足商业和项目目标
- 推动项目集或项目的产品、服务或最终成果的成功应用
- 需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益
裁剪时需要考虑的因素
- 因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）
- 知识和需求管理
- 确认和控制
- 开发方法
- 需求的稳定性
- 治理
在敏捷或适应型环境中需要考虑的因素
- 对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项
5.1 规划范围管理
- 作用：在整个项目期间对如何管理范围提供指南和方向（本过程仅开展一次或仅在项目的预定义点开展）
- 范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析：项目章程中的信息、项目管理计划中已批准的子计划、组织过程资产中的历史信息和相关事业环境因素
5.2 收集需求
- 作用：为定义产品范围和项目范围奠定基础（且开展一次或仅在项目的预定义点开展）
- 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础
- 需求管理计划包括以下内容
- 如何规划、跟踪和汇报各种需求活动
- 需求管理需要使用的资源
- 培训计划
- 项目干系人与需求管理策略
- 判断项目范围与需求不一致的准则和纠正规程
- 需求跟踪结构
- 配置管理活动
5.3 定义范围
- 作用：描述产品、服务或成果的边界和验收标准
- 由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要
- 项目范围说明书内容
- 产品范围描述
- 验收标准
- 可交付成果
- 项目的除外责任
- 制约因素
- 假设条件
5.4 创建WBS
- 作用：为所要交付的内容提供架构（仅开展一次或仅在项目的预定义点开展）
- WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
- WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作
- WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制
- 在“工作分解结构”这个词语中，在该控制点上，将范围、预算、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效
- 控制账户是WBS某个层次上的要素，可以是工作包，也可以是比工作包更高层次上的一个要素
- 规划包是指在控制账户下，工作包之上的WBS要素，由于当前无法分解到编制项目管理计划所需要的详细程度，规划包是暂时用来做计划的
- 注意事项
- WBS必须面向可交付成果
- WBS必须符合项目的范围
- WBS的底层应该支持各计划控制
- WBS的元素必须有人负责
- WBS应该控制在4-6层
- WBS也要控制外包出去的工作
- WBS编制需要所有干系人及项目团队成员参与
- WBS并非一成不变
5.5 确认范围
- 作用：使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性（本过程应根据需要在整个项目期间定期开展）
- 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行
- 确认范围与项目收尾的不同之处在于：虽然确认范围与项目收尾工作都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所在做的流程性工作。确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品
5.6 控制范围
- 控制范围是监督项目和产品的范围状态、管理范围基准变更过程
- 作用：在整个项目期间保持对范围基准的维护（且需要在整个项目期间开展）
- 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也要采用控制范围过程来管理这些变更。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延
产品范围、项目范围、产品范围
- 项目范围包括：项目的最终产品或服务，以及实现该产品或服务所需要的各项具体工作。项目范围的确定就是为成功实现项目的目标，规定或控制哪些方面是项目应该做的，哪些是不该做的，也就是定义项目的范畴。范围有多种含义：产品范围、项目范围、产品规范
- 产品范围：即确定产品或服务中应包含哪些功能和特征（就是对产品的度量）
- 项目范围：项目要做些什么，如何做，才能实现项目的目标（也是产生项目计划的基础）。也就是为了交付具有一定特征和功能的产品或服务所应做的工作
- 产品规范：即项目产品或服务所包含的具体特征和功能
- 项目范围的定义要以其组成的所有产品或服务的范围界定为基础，这是一个由一般到具体、层层深入的过程。产品范围的定义就是对产品要求的度量，项目范围的定义在一定程度上是产生项目计划的基础；产品范围的完成是对照产品要求来进行度量的，而项目范围的完成是对照项目计划来进行度量的
项目范围说明书
- 项目范围说明书规定了项目的范围也主要定义了项目的工作边界，明确了项目的目标和主要的项目可交付成果。项目范围说明书应该包括以下3个方面的内容
- 项目的合理性说明书（说明解释了为什么要进行这一项目）
- 项目目标（确定了项目成功所必须满足的某些数量标准。至少应包括费用、时间进度和技术性能或质量标准）
- 项目可交付成果（是一份主要的、具有归纳性层次的产品清单；这些产品完全、满意的交付标志着项目的完成）
- 再细化一下版项目范围说明书内容
- 产品范围描述
- 验收标准
- 可交付成果
- 项目的除外责任
- 制约因素
- 假设条件
项目范围管理过程
- 启动：是指组织正式开始一个项目或继续到项目的下一个阶段
- 范围计划：是指进一步形成各种文档，为将来项目决策提供基础，这些文档中包括用以衡量一个项目或项目阶段是否已经顺利完成的标准等
- 范围定义：将项目主要的可交付成果细分为较小的更易管理的组分。需要建立工作分解结构（WBS）
- 范围核实：项目的主要利益相关者对项目范围的正式验收
- 范围变更控制：对项目范围的变更实施控制
创建WBS
- 项目工作分解的步骤
- 首先明确并识别出项目的各主要组成部分，即明确项目的主要可交付成果
- 确定每可交付成果的详细程度是否已经达到了足以编制恰当的成本和历时估算
- 确定可交付成果的组成元素
- 核实分解的正确性
- 补充WBS制作注意事项
- WBS必须面向可交付成果
- WBS必须符合项目的范围
- WBS的底层应该支持各计划控制
- WBS的元素必须有人负责
- WBS应该控制在4-6层
- WBS也要控制外包出去的工作
- WBS编制需要所有干系人及项目团队成员参与
- WBS并非一成不变
范围核实和范围变更控制
- 范围核实是指利益相关者对项目范围的正式接受。为了能使项目范围得以正式认可，项目团队必须形成明确的正式文件，说明项目产品及评估程序，以评估是否正确和满意地完成了项目产品
- 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行
- 范围变更控制则是对项目范围变更进行控制
- 引起项目问题常见的因素
- 缺少用户参与
- 不完整的要求说明
- 易变的需求和说明
- 缺乏主管领导的支持技术不过关
- 缺乏资源
- 不切实际的愿望
- 目标不明确
- 不切实际的实际安排
- 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也要采用控制范围过程来管理这些变更。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延
项目章程与范围说明书
- 项目章程
- 项目目的
- 可测量的项目目标和相关的成功标准
- 高层级需求
- 高层级项目描述、边界定义以及主要可交付成果
- 整体项目风险
- 总体里程碑进度计划
- 预先批准的财务资源
- 关键相关方名单
- 项目审批要求（例如，用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）
- 项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）
- 委派的项目经理及其职责和职权
- 发起人或其他批准项目章程的人员的姓名和职权
- 项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识
- 项目范围说明书
- 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
- 产品验收标准：定义已完成的产品、服务或成果的验收过程和标准
- 项目可交付成果：可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，如项目管理报告和文件
- 项目的除外责任：需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人期望
- 项目制约因素：列出并说明与项目范围有关、且限制项目团队选择的具体项目制约因素。如合同条款或管理政策，可独立成册
