高项 - 项目范围管理

个人总结，仅供参考，欢迎加好友一起讨论

博文更新参考时间点：2024-12

高项 - 章节与知识点汇总：点击跳转

高项 - 项目范围管理

范围管理ITO

规划

监控

管理基础

产品范围与项目范围

在项目环境中，“范围”这一术语有两种含义：

• 产品范围：指某项产品、服务或成果所具有的特征和功能。产品范围的完 成情况是根据产品需求来衡量的。
• 项目范围：包括产品范围，是为交付具有规定特性与功能的产品服务或成 果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。

另外，一般情况下：项目范围包含产品范围

管理新实践

需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。

商业分析师，该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创 造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。

5大过程组与范围管理

过程概述

裁剪考虑因素

因为每个项目是独特的，所以可能需要对项目范围过程进行裁剪。裁剪考虑：

• 知识和需求管理
• 确认和控制
• 开发方法
• 需求的稳定性
• 治理

敏捷与适应方法

敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间。在许多情况下，不断涌现的需求往往导致真实 的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。

采用敏捷或适应型生命周期，旨在应对大量变更，需要干系人持续参与项目。因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完成项），通过多次迭代来并发可交付成果，并在每次迭代开始时定义和批准详细的范围。在一个迭代开始时，团队将努力确定产品未完成项中，哪些优先级高的未完成项需要在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：①收集需求；②定义范围；③创建WBS。

在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，并对迭代交付的可交付成果提供反馈意见，确保产品未完成项真实地反映了他们的当前需求。在每次迭代中，都会重复开展两个过程：①确认范围；②控制范围。

规划范围管理

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

本过程的主要作用：在整个项目期间对如何管理范围提供指南和方向。

本过程仅开展一次或仅在项目的预定义点开展。

输入

• 项目章程：记录项目目的、项目描述、假设条件、制约因素，以及项目意图实现的高层级需求。

• 项目管理计划

  质量管理计划：在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。

  项目生命周期描述：定义了项目从开始到完成所经历的一系列阶段。

  开发方法：定义了项目是采用预测型、适应型还是混合型的开发方法。

• 事业环境因素

• 组织过程资产

工具与技术

• 专家判断
• 数据分析（备选方案分析）：用于评估、收集需求，详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。
• 会议（项目规划会议）：通过规划会议来制订范围管理计划。参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人等。

输出

范围管理计划

范围管理计划：描述将如何定义、制定、监督、控制和确认项目范围。

用于指导如下过程和相关工作：

• 制订项目范围说明书
• 根据范围说明书创建WBS
• 确定如何审批和维护范围基准
• 正式验收已完成的项目可交付成果

特别注意的是：

• 范围管理计划没有“范围”，范围在范围基准中
• 范围管理计划（以及其他所有管理计划）都可以是正式的或者非正式的，非常详细的或者是概括的

需求管理计划

需求管理计划：描述将如何分析、记录和管理项目和产品需求。

需求管理计划中没有“需求”，详细的需求在需求文件里面。

包含的内容：

• 如何规划、跟踪、报告各种需求活动
• 配置管理活动（如何启动变更，如何分析其影响，如何进行追溯，跟踪和报告，以及变更审批权限）
• 需求优先级排序过程
• 测量指标及使用这些指标的理由
• 反映哪些需求属性将被列入跟踪矩阵

需求和范围的区别和联系

• 需求：需求来源于干系人的需要和期望的
• 范围：范围是满足“需求”必须交付的可交付成果和相关工作，用于确定项目边界

收集需求

收集需求：为实现目标而确定、记录并管理干系人的需要和需求的过程。

本过程的作用：为定义产品范围和项目范围奠定基础。

本过程仅开展一次或仅在项目的预定义点开展。

输入

• 立项管理文件：商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。

• 项目章程：记录了项目概述以及将用于制定详细需求的高层级需求。

• 项目管理计划

  范围管理计划：包含如何定义和制定项目范围的信息。

  需求管理计划：包含如何收集、分析和记录项目需求的信息。

  干系人参与计划：从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的 参与程度。

• 项目文件

  假设日志：识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件。

  干系人登记册：用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。

• 协议：包含项目和产品的需求

• 事业环境因素与组织过程资产

工具与技术

输出

需求文件

需求文件：描述各种单一需求将如何满足与项目相关的业务需求。

只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人认可的需求，才能作为基准。

需求的类别包括：

1. 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。

2. 干系人需求：干系人的需要。

3. 解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的 特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：

   ①功能需求 ：描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。

   ②非功能需求：是对功能需求的补充，是产品正常运行所需的环境条件或质量要求， 例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。

4. 过渡和就绪需求：描述了从“当前状态”过 渡到“将来状态”所需的临时能力，例如，如数据转换和培训需求。

5. 项目需求：项目需要满足的行动、过程或其他条件，例如，里程碑日期、合同责任、制约因素等。

6. 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等。

需求跟踪矩阵

需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

需求跟踪矩阵的关注点：

• 把每个需求与业务目标或项目目标联系起来，确保每个需求都具有业务价值
• 需求跟踪矩阵需要在整个项目生命周期中跟踪和更新
• 提供了在整个项目生命周期中跟踪需求的一种方法（正向跟踪和逆向跟踪）
• 正向跟踪原始需求 → 需求文件 → 产品
• 反向跟踪产品 → 需求文件 → 原始需求

跟踪需求的内容包括：

• 业务需要、机会、目的和目标
• 项目目标
• 项目范围和WBS可交付成果
• 产品设计
• 产品开发
• 测试策略和测试场景
• 高层级需求到详细需求等

需求跟踪矩阵示例，如下图：

定义范围

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

本过程的作用：描述产品、服务或成果的边界和验收标准。从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

本过程需要在整个项目期间多次反复开展。

输入

• 需求文件：识别了应纳入范围的需求。

• 项目章程：项目章程中包含对项目的高层级描述、产品特征和审批要求。

• 项目文件

  范围管理计划：记录了如何定义、确认和控制项目范围。

  风险登记册：包含了可能影响项目范围的应对策略，如缩小或改变项目和产品范围，以规避或缓解风险。

• 事业环境因素与组织过程资产

工具与技术

• 专家判断
• 数据分析（备选方案分析）：制定尽可能多的潜在可选方案的技术，用于评估实现需求和目标的各种方法。
• 决策（多标准决策分析）：建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。
• 人际关系与团队技能：典型示例是引导。
• 产品分析：把高层级的产品描述转变为有形的可交付成果。包括：产品分解、系统分析、需求分析、 系统工程、价值工程、价值分析等。

输出

项目范围说明书

项目范围说明书：对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。

项目范围说明书代表干系人之间就项目范围所达成的共识。

详细的项目范围说明书内容有：

• 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
• 可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核 实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。
• 验收标准：可交付成果通过验收前必须满足的一系列条件。
• 项目的除外责任：识别排除在项目之外的内容。明确说明哪些内容不属于 项目范围，有助于管理干系人的期望及减少范围蔓延。

特别注意：

• 注意区分验收标准（项目范围说明书），成功标准（项目章程）
• 注意区分可交付成果（项目范围说明书，渐进明细），高层级的范围，需求（项目章程），需求和可交付成果能不能对应上（需求跟踪矩阵）

项目文件（更新）

可在定义范围过程更新的项目文件包括：

• 假设日志
• 需求文件
• 需求跟踪矩阵
• 千系人登记册

创建WBS

创建WBS（Work Breakdown Structure）：把项目可交付成果和项目工作分解成较小的、更易于管理的组件（工作包）的过程。

本过程的作用：对所要交付的内容提供架构。它仅开展一次或仅在项目的预定义点开展。

WBS组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）。

WBS最低层的组成部分称为工作包，其中包括计划的工作。“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

输入

• 范围管理计划
• 项目文件（需求文件，项目范围说明书）

工具与技术

分解：把项目范围和项目可交付成果逐步划分为更小的、更便于管理的组成部分。

工作包：WBS最低层的组件，可对其成本和持续时间进行估算和管理。不是分解得越细越好。过细的分解会造成管理努力的无效耗费。

远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划。

创建WBS的常用的方法包括自上而下的方法、使用组织特定的指南和使用WBS模板。项目工作分解为工作包，通常需要开展如下活动：

1. 识别和分析可交付成果及相关工作
2. 确定WBS的结构和编排方法
3. 自上而下逐层细化分解
4. 为WBS组成部分制定和分配标识编码
5. 核实可交付成果分解的程度是否恰当

WBS 的结构可以采用多种形式：

• 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
• 以主要可交付成果作为分解的第二层
• 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作） 。 随 后，作为外包工作的一部分，卖方须制定相应的合同WBS。

WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式（表格方式：提纲式，树型方式：组织结构图）。

WBS分解的8个注意事项：

1. WBS必须符合项目的范围（100%原则），所有下一级的元素之和必须100%代表上一级元素

2. WBS应包括项目管理工作，也要包括分包出去的工作

3. WBS中的元素必须有且只有一人负责（独立责任原则）

4. WBS应控制在4 ~ 6层

   若项目规模大，要超过6层，则可将大项目分解成子项目，再针对子项目做WBS

   每个级别的WBS将上一级的一个元素分为4 ~ 7个新元素，同一级元素大小应相似

   一个工作单元只能从属于某个上层单元，避免交叉从属

5. WBS必须是面向可交付成果的

6. WBS的底层应该支持计划和控制，支持项目管理计划、进度和预算的控制

7. WBS的编制需要所有（主要）干系人的参与

8. WBS并非是一成不变的。

输出

范围基准

范围基准：经过批准的范围说明书、 WBS和相应的WBS词典， 只有通过正式的变更控制程序才能进行变更。

• 项目范围说明书：记录了整个范围，包括项目和产品范围

• WBS：全部工作范围的层级分解，包括工作包（WBS的最低层是带有独特标识号的工作包）和规划包（低于控制账户而高于工作包的工作分解结构组件）

  每个控制账户可能包括一个或多个工作包（或规划包），但一个工作包只能属于一个控制账户

  控制账户是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效

• WBS词典：针对每个WBS组件 ，详细描述可交付成果、活动和进度信息的文件。

项目文件（更新）

• 假设日志
• 需求文件

确认范围

确认范围：“客户”或“发起人”正式验收已完成的项目可交付成果的过程。

本过程的作用：1.使验收过程具有客观性，2.通过确认每个可交付成果，提高最终产品、服务或成果验收的可能性。

确认范围过程应根据需要在整个项目期间定期开展。

确认范围的步骤包括：

1. 确定需要进行范围确认的时间
2. 识别范围确认需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定范围确认会议的组织步骤
5. 组织范围确认会议。

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

控制质量和确认范围的区别：

确认范围需要检查的6个问题：

1. 可交付成果是否是确定的、可确认的。
2. 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
3. 是否有明确的质量标准；
4. 审核和承诺是否有清晰的表达。
5. 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误；
6. 项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

干系人关注点的不同：

• 管理层，关注范围对进度、资金和资源的影响，这些因素是否超过了组织承受范围，投入产出是否合理。
• 客户，关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。
• 项目管理人员，关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险等。
• 项目团队成员，关心自己参与的元素和负责的元素，检查自己的工作时间是否足够。
• 另外要了解客户和项目团队成员往往有在当前版本中加入所有功能和特征的意愿，这是一种潜在风险。

输入

• 项目管理计划

  范围管理计划：如何正式验收已完成的可交付成果。

  需求管理计划：如何确认项目需求。

  范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防。

• 项目文件

  需求文件：将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。

  需求跟踪矩阵：含有与需求相关的信息，包括如何确认需求。

  质量报告：该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。

  经验教训登记册：在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。

• 工作绩效数据

• 核实的可交付成果（被控制质量过程检查为正确的可交付成果）

工具与技术

• 检查：指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
• 决策：投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。

输出

验收的可交付成果

验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。（验收通过，则等待收尾时的整体验收）

变更请求

变更请求：验收不通过，则记录原因，走变更控制管理流程，进行缺陷补救。

工作绩效信息

工作绩效信息：包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人。

项目文件（更新）

• 需求文件（记录实际的验收结果）
• 需求跟踪矩阵
• 经验教训登记册

控制范围

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

本过程的作用：在整个项目期间保持对范围基准的维护。

需要在整个项目期间开展。

确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。

范围蔓延

范围蔓延：未经控制的产品或项目范围的扩大（未对时间、成本和资源作相应的调整）

• 镀金：项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。
• 范围潜变：范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。

需注意：

• 已经发生了范围蔓延，额外的需求已经完成，而且导致进度落后了，那怎么办？要走变更控制流程，不是简单的直接删除多做的需求。
• PM发现团队成员正在做范围蔓延的需求，那怎么办？先停下来，然后还是走变更控制流程。

输入

• 项目管理计划

  范围管理计划：记录如何控制项目和产品范围。

  需求管理计划：记录如何管理项目需求。

  变更管理计划：定义了管理项目变更的过程。

  配置管理计划：定义了哪些配置项。

  范围基准：用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防。

  绩效测量基准：

• 项目文件

  需求文件：将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。

  需求跟踪矩阵：有助于探查任何变更或对范围基准的任何偏离对项目目标的影响。

  经验教训登记册：在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。

• 工作绩效数据：收到的、接受的变更请求的数量。核实、确认和完成的可交付成果的数量。

• 组织过程资产

工具与技术

• 偏差分析：将基准与实际结果比较，确定偏差是否处于临界值区间内或是否有必要纠正或预防措施。
• 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
• 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

输出

验收的可交付成果

验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。（验收通过，则等待收尾时的整体验收）

工作绩效信息

工作绩效信息：识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。

变更请求

变更请求：分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出 变更请求。

项目管理计划（更新）

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

项目文件（更新）

• 需求文件
• 需求跟踪矩阵
• 经验教训登记册

工作绩效数据，工作绩效信息，工作绩效报告