项目范围管理：定义、控制与确认-CSDN博客

本文链接：https://blog.csdn.net/xhmico/article/details/131992450

第七章范围管理

7.1 项目范围管理概念

概述：项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。

包括：

产品范围
- 衡量标准：是否完成以产品需求说明书的要求
项目范围
- 衡量标准：是否完成以项目管理计划、项目范围说明书、WBS 和 WBS 字典的要求

对项目管理的重要性：

1）清楚了项目的工作具体范围和具体工作内容，为提高成本，时间和资源估算的准确性提供了基础
2）项目范围既然是确定要完成哪些具体的工作，项目范围基准是确定项目进度测量和控制的基准
3）项目范围的确定就是确定了项目的具体工作任务，有助于清楚地责任划分和任务分配

项目的范围基准：经批准的项目范围说明书、与之联系的 WBS 以及 WBS 字典

项目投资人：针对项目范围变化的需求或者涉及重大的变更，真正具备批准权力的人

7.2 主要过程

包括：

规划范围管理（计划过程组）
收集需求（计划过程组）
定义范围（计划过程组）
创建工作分解结构 - WBS（计划过程组）
范围确认（监控过程组）
范围控制（监控过程组）

7.2.1 规划范围管理

概述：范围项目管理计划是项目或项目集管理计划的组成部分，描述了如何定义，监督，控制和确认项目范围。（概况：编写计划文档）

在这里插入图片描述

规划范围管理的输入：

1）项目管理计划
2）项目章程
3）组织过程资产
4）事业环境因素

规划范围管理的工具与技术：

① 会议
② 专家判断

规划范围管理的输出：

① 范围管理计划
- 描述：作为指定项目管理计划过程的主要依据，范围管理计划可以是非正式的，规定了如何制定详细范围说明书
- 内容：包括范围管理中的工具选用、方法论等
② 需求管理计划：用于规划，跟踪和报告各种需求活动

7.2.2 收集需求

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

主要作用：为定义和管理项目范围（包括产品范围）奠定基础。

收集需求的输入：

1）范围管理计划
2）需求管理计划
3）干系人管理计划
4）项目章程
5）干系人登记册

收集需求的工具与技术：

① 访谈 — 一对一
② 焦点小组 — 一对多
③ 引导式研讨会 — 跨职能
④ 群体创新技术 — 头脑风暴、名义小组、思维导图、亲和图、多标准决策分析
⑤ 群体决策技术 — 一致同意原则、大多数原则、相对多少原则、独裁
⑥ 问卷调查
⑦ 观察
⑧ 原型法
⑨ 标杆对照
⑩ 系统交互图
⑪ 文件分析

收集需求的输出：

① 需求文件
② 需求跟踪矩阵

7.2.3 定义范围

概述：定义范围是制定项目产品详细描述的过程。（粗略到详细的过程）

主要任务：详细定义项目的范围边界，范围边界是应该做的工作和不需要进行的工作分界线。

变更的流程：包括必要的书面文件、纠正行动、跟踪系统和授权变更的批准等级。

定义范围的输入：

1）范围管理计划
2）项目章程
3）需求文件
4）组织过程资产

定义范围的工具与技术：

① 产品分析
- 概述：产品分析通过产品分解、系统分析、价值工程等技术厘清产品范围，并把对产品的要求转化成项目的要求。
② 专家判断
③ 备选方案生成
④ 引导式研讨会

定义范围的输出：

① 项目范围说明书
② 项目文件更新

项目范围说明书：

内容：
- ① 项目目标：项目目标包括成果性目标和约束性目标。项目成果性目标指通过项目开发出的满足客户要求的产品、服务或成果。项目约束性目标是指完成项目成果性目标需要的时间、成本以及要求满足的质量。
- ② 产品范围描述：这一节描述了项目承诺交付的产品、服务或结果的特征。这种描述会随着项目的开展，其产品特征会逐渐细化。
- ③ 项目需求：可交付物包括项目的产品、成果或服务，以及附属产出物例如项目管理报告和文档。根据需要，可交付物可以被描述得比较概要，也可以很详细。
- ④ 项目边界：边界严格定义了哪些事项属于项目，也应明确地说明什么事项不属于项目的范围。
- ⑤ 项目的可交付成果：在某一过程、阶段或项目完成时，产出的任何独特并可核实的产品、成果或服务。可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
- ⑥ 项目的职业因素：指具体的与项目范围有关的约束条件，它会对项目团队的选择造成限制。项目范围说明书的约束条件比项目章程中列出的约束条件更多，而且更加详尽。需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件，例如，客户或执行组织事先确定的预算、强制性日期或进度里程碑都应该被包括在内。如果项目是根据协议实施的，那么合同条款通常也是制约因素。关于制约因素的信息可以列入项目范围说明书，也可以独立成册。
- ⑦ 假设条件：与范围相关的假设条件，以及当这些条件不成立时对项目造成的影响。作为计划过程的一部分，项目团队要经常识别、记录和确认创设条件的有效性。在制定计划时，不需验证即可视为正确、真实或确定的因素就是假设。关于假设条件的信息可以列入项目范围说明书，也可以独立成册。

7.2.4 创建工作分解结构 - WBS

工作分解结构（WBS）：

概述：
- 是项目管理的基础。项目的所有规划和控制工作都必须基于工作分解结构。
- 是对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作范围的层次分解。WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书所规定的工作。
- WBS 是自上而下分解的，最低层的工作单元被称为工作包，是我们进行进度安排，成本估算和监控的基础。
前提：基于项目可交付成果来分解
主要作用：对所要交付的内容提供一个结构化的视图
相关概念：
- 里程碑
  - 概述：里程碑标志着某个可交付成果或者阶段的正式完成。里程碑和可交付成果紧密联系在一起，但并不是一个概念。可交付成果可能包括报告、原型、成果和最终产品，而 里程碑=具体时间+在这个时间应完成的事件，里程碑关注事件是否完成，例如，用户签署正式的认可文件等。工作分解结构中的任务有明确的开始时间和结束时间，任务的结果可以和预期的结果相比较。
- 工作包
  - 概述：工作包是位于工作分解结构每条分支最低的可交付成果或项目工作组成部分。由于工作包便于完整地分派给不同的人或组织、所以要求工作包应当非常具体，以便承担着能明确各自己的任务、目标以及责任。工作包是基层任务或工作的指派，同时其具有检测和报告工作的作用。工作包是 WBS 最底层单位，包括项目的所有工作，它是定义项目批准、定义项目组织，设定项目产品质量和规格，可以可靠估算的基础和用于控制项目费用、进度的依据。如果工作包的大小过大会导致难以达到可控的管理、目标；如果工作包太小，那么工作分解结构就需要消耗项目管理人员和项目团队成员的大量时间和精力。作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要8小时完成，而总完成时间也不应该大于80小时。
  - 特征：
    - ① 规模较小，可以在短时间（80小时）完成
    - ② 从逻辑上讲不能再分了
    - ③ 所需资源、时间、成本等已经可以比较准确地估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制
- WBS 编码设计
  - 概述：为了简化 WBS 的信息交流过程，通常利用编码技术对 WBS 进行信息交换。编码设计与结构设计存在对应关系。结构的每一层次代表编码的某一位数，有一个分配给它特定的代码数字。在WBS 编码中，任何等级的一位项目要素，是其余全部次一级项目要素的总和。如第二个数字代表子项目要素。所有子项目的编码第一位数字是相同的，再下一级的工作单元的编码依此类推。编码设计对于 WBS 来说是个关键技术。不管对于使用者是高级管理人员还是其他层次的员工来说编码都有共同的意义。在进行编码设计时必须仔细考虑收集到的信息和收集所用的方法，使信息能够通过 WBS 编码进入到应用记录系统中。
包含的内容：
- （1）工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构当中
- （2）工作分解结构的编制需要所有项目干系人的参与，需要项目团队成员的参与
- （3）工作分解结构是逐层向下分解的
- （4）工作分解结构的各要素应该是相对独立的，要尽量减少相互之间的交叉
表现形式：
- 结构图：
  - 树形结构图
    - 图例：
    - 优点：层次清晰，非常直观，结构性强
    - 缺点：不容易修改，对于大型的，复杂的项目也很难表示出项目的全景
    - 适用范围：由于其直观性，一般在一些小的，适中的项目中用的较多
  - 表格结构图
    - 图例：
    - 优点：该表能够反映出项目所有的工作要素
    - 缺点：直观性差
    - 适用范围：适用在一些大型的，复杂的项目中使用较多。因为有些项目分解后，内容分类较多，容量较大，用缩进图表的形式表示比较方便，也可装订为手册。
形式：
- 交付物
- 子项目
- 项目生命周期 — 需求分析、方案设计、实施准备、测试和验收
注意：
- WBS 工作包一般不包括的成本是管理成本
- WBS 的制定由项目团队主要完成

过程：
在这里插入图片描述

创建工作分解结构的输入：

1）范围管理计划
2）项目范围说明书
3）需求文件
4）组织过程资产
5）事业环境因素

创建工作分解结构的工具与技术：

① 分解
- 步骤：
  - 识别和分析可交付成果及相关工作
  - 确定 WBS 的结构和编排方法（树形或表格）
  - 自上而下逐级细化分解
  - 为 WBS 组件制定和分配标识编码
  - 核实可交付成果分解的程度是否恰当
- 原则：
  - 在层次上保持项目的完整性，避免遗漏必要的组成部分
  - 一个工作单元只能属于某个上层单元，避免交叉从属
  - 相同层次的工作单元应用相同性质（分解时可按照可交付物，生命周期，各子项目划分）
  - 工作单元应能分开不同的责任者和不同的工作内容
  - 便于项目管理计划和项目控制的需要
  - 最低层工作应该具有可比性，是可管理的，可定量检查的
  - 应包括项目管理工作，包括分包出去的工作
  - 8/80 原则：每一个工作包的工作量大小介于 8/80
② 专家判断

创建工作分解结构的输出：

① 范围基准
② 项目文件更新

里程碑：重要的检查点叫做里程碑，里程碑标志着某个可交付成果或者阶段的正式完成。

基线：重要的里程碑叫做基线

控制账户：

概述：
- 在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据 “账户编码”为工作包建立唯一标识，这些标识为进行成本，进度与资源信息的层级汇总提供了层级结构。
- 控制账户是一个管理控制点。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。需要生成一些配套文件，这些文件需要和工作分解结构配套使用，称为工作分解结构词典。(WBS 词典)

7.2.5 范围确认

概述：

范围确认是客户等项目干系人正式验收并接受已完成的项目可交付物的过程，也称范围确认过程为范围核实过程。项目范围确认包括审查项目可交付物以保证每一交付物令人满意地完成。
范围确认过程中可能产生的变更申请，例如对缺陷的修复要求。
是客户等项目干系人正式验收并接收已完成的项目可交付物的过程。

包括：产品的确认和相关文档及项目工作等的确认

主要作用：提高最终产品、服务或成果获得验收的可能性

工作要点：

1）制定并执行确认程序
2）确认范围的一般步骤
- ① 确定需要进行确认范围的时间
- ② 识别确认范围需要哪些投入
- ③ 确定范围正式被接受的标准和要素
- ④ 确定确认范围会议的组织步骤
- ⑤ 组织确认范围会议

过程：

在这里插入图片描述

范围确认的输入：

1）项目管理计划
2）需求跟踪矩阵
3）需求文件
4）核实的可交付成果
5）工作绩效数据

范围确认的工具与技术：

① 检查
- 概述：有时也叫审查、产品评审、审计或走查，可以用来确定可交付成果是否符合需求和验收标准。
② 群体决策技术
- 分类：
  - 一致同意
  - 大多数原则：获得群体中超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策。
  - 相对多少原则：根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
  - 独裁

范围确认的输出：