5 - 项目范围管理

项目范围管理（Scope Management）就是要做范围内的事，而且只做范围内的事，既不少做也不多做。

内容

1. 明确项目边界
2. 对项目执行工作进行监控
3. 防止项目范围发生蔓延


产品范围 VS 项目范围 $\color{red}{★}$

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

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

项目范围管理的过程

1. 规划范围管理
2. 收集需求
3. 定义范围
4. 创建 WBS
5. 确认范围
6. 控制范围

规划范围管理

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

作用: 在整个项目中对如何管理范围提供指南和方向

• 输入：
  1. 项目管理计划
  2. 项目章程
  3. 事业环境因素
  4. 组织过程资产
• 输出：
  1. 范围管理计划
  2. 需求管理计划
• 工具与技术：
  1. 专家判断
  2. 会议

范围管理计划 $\color{red}{★}$

描述将如何定义、制定、监督、控制和确认项目范围

对下列工作的管理过程做出规定:

• 如何制订项目范围说明书。
• 如何根据范围说明书创建 WBS。
• 如何维护和批准 WBS。
• 如何确认和正式验收已完成的项目可交付成果。
• 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。

需求管理计划 $\color{red}{★}$

需求管理计划（Requirements Management Plan）描述在整个项目生命周期内如何分析、记录和管理需求。

主要内容至少包括：

• 如何规划、跟踪和汇报各种需求活动。
• 需求管理需要使用的资源。
• 培训计划
• 项目干系人参与需求管理的策略
• 判断项目范围与需求不一致的准则和纠正规程
• 需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求
• 配置管理活动

收集需求

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

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

• 输入：

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

• 输出：

  1. 需求文件
  2. 需求跟踪矩阵

• 工具与技术：

  1. 访谈
  2. 焦点小组
  3. 引导式研讨会
  4. 群体创新技术
  5. 群体决策技术
  6. 问卷调查
  7. 观察
  8. 原型法
  9. 标杆对照
  10. 系统交互图
  11. 文件分析

需求的分类

• 业务需求： 整个组织的高层级需要
• 干系人需求： 是指干系人或干系人群体的需要
• 解决方案需求： 是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征
• 过渡需求： 从当前状态过渡到将来状态所需的临时能力
• 项目需求： 项目需要满足的行动、过程或其他条件
• 质量需求： 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

收集需求的工具与方法

访谈

• 与干系人直接交谈来获取信息的正式或非正式的方法

焦点小组 $\color{red}{★}$

• 将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度
• 由一位受过训练的主持人引导大家进行互动式讨论

引导式研讨会 $\color{red}{★}$

$\color{red}{✓}$ 把主要的跨职能干系人召集在一起，对产品需求进行集中讨论来定义

$\color{red}{✓}$ 快速定义跨职能需求、协调干系人差异

$\color{red}{✓}$ 有助于参与者之间建立信任、改进关系、改善沟通、达成 一致意见

$\color{red}{✓}$ 联合应用开发（Joint Application Development JAD）就是一种典型的引导式研讨会

群体创新技术

$\color{red}{✓}$ 头脑风暴法

头脑风暴遵守如下原则 ：

• 庭外判决原则：对各种创意（意见、建议）、方案的评判必须放到最后阶段
• 欢迎各抒已见，自由鸣放
• 追求数量
• 探索取长补短和改进办法
• 

$\color{red}{✓}$ 名义小组技术

• 将全体参与者分成多个“名义”上的小组，由每个小组开展讨论
• 小组讨论结束后，主持人依次向每位参与者询问，请每人提出一个创意。这种询问可以进行很多轮，直至得到足够数量的创意。
• 对所有创意进行评审和排序

$\color{red}{✓}$ 概念/思维导图：

将创意用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

$\color{red}{✓}$ 亲和图

• 核心是头脑风暴
• 主要依据各种创意之间的相似性，对头脑风暴中得到的各种创意进行分类

$\color{red}{✓}$ 多标准决策分析： 借助决策矩阵，对众多方案进行评估和排序

$\color{red}{✓}$ 德尔菲技术： 种组织专家就某一主题达成一致意见的一种信息收集技术。

• 步骤：

  • 吸收专家参与预测，充分利用专家的经验和学识。
  • 采用匿名或背靠背的方式，能使每一位专家独立自由地做出自己的判断。
  • 预测过程几轮反馈，使专家的意见逐渐趋同。
  • 有助于减轻数据的偏倚，防止任何个人对结果产生不恰当的影响。

• 优点：

  • 能充分发挥各位专家的作用，集思广益，准确性高。
  • 能将各位专家意见的分歧点表达出来，取各家之长，避各家之短。
  • 同时，德尔菲技术又能避免专家会议法的缺点，即∶
    • 权威人士的意见影响他人的意见。
    • 有些专家碍于情面，不愿意发表与其他人不同的意见。
    • 出于自尊心而不愿意修改自己原来不全面的意见。

• 缺点：

  • 德尔菲技术的主要缺点是过程比较复杂，花费时间较长。

群体决策技术 $\color{red}{★}$

群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。

$\color{red}{✓}$ 群体决策的方法：

• 一致同意： 所有人都同意某个行动方案
• 大多数原则： 获得群体 50%以上的人支持，就能做出决策
• 相对多数原则： 根据群体中相对多数者的意见做出决定
• 独裁： 由某一个人为群体做出决策

问卷调查

$\color{red}{✓}$ 设计一系列书面问题，向众多受访者快速收集信息 $\color{red}{✓}$ 适用于：受众多样化，需要快速完成调查，受访者地理位置分散，并想要使用统计分析方法

观察

$\color{red}{✓}$ 直接察看个人在各自的环境中如何开展工作和实施流程

$\color{red}{✓}$ 当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解细节

$\color{red}{✓}$ 体验该流程或程序是如何实施的，以便挖掘隐藏的需求

原型法

$\color{red}{✓}$ 先造出该产品的实用模型，据此征求对需求的早期反馈

$\color{red}{✓}$ 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径

系统交互图

$\color{red}{✓}$ 是对产品范围的可视化描绘

$\color{red}{✓}$ 显示系统（过程、设备、信息系统）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。 DFD、用例图都可以看作是系统交互图。

文件分析

$\color{red}{✓}$ 分析现有文档，识别与需求相关的信息，来挖掘需求

需求文件

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

需求跟踪矩阵

$\color{red}{✓}$ 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

需要跟踪的内容包括以下几个方面。

1. 业务需求、机会、目的和目标。
2. 项目目标。
3. 项目范围（WBS可交付成果）。
4. 产品设计。
5. 产品开发。
6. 测试策略和测试场景。
7. 高层级需求到详细需求。

定义范围

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

作用： 本过程的主要作用是描述产品、服务或成果的边界和验收标准。

产品分析

$\color{red}{✓}$ 对于以产品为可交付成果的项目非常有效

$\color{red}{✓}$ 包括：产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等

备选方案生成

$\color{red}{✓}$制定尽可能多的潜在可选方案

$\color{red}{✓}$ 识别执行项目工作的不同方法

$\color{red}{✓}$ 生成备选方案的技术有：头脑风暴、横向思维、备选方案分析

项目范围说明书 $\color{red}{★}$

$\color{red}{✓}$ 对项目范围、主要可交付成果、假设条件和制约因素的描述

$\color{red}{✓}$ 记录了整个范围，包括项目和产品范围

主要内容：

1. 产品范围描述
2. 验收标准
3. 可交付成果
4. 项目的除外责任
5. 制约因素
6. 假设条件

创建WBS

定义: 把项目可交付成果和项目工作分解成较小的、更易于管理的组件

作用: 本过程的主要作用是为所要交付的内容提供架构。

分解流程 $\color{red}{★}$

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

WBS

$\color{red}{✓}$ 对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解

$\color{red}{✓}$ 工作分解结构每向下分解一层，代表着对项目工作更详细的定义

$\color{red}{✓}$ 是后续管理工作的主要依据，是项目时间、成本、人力等管理工作基础

$\color{red}{✓}$ 树形结构、列表形式

WBS 作用

创建 WBS 是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。WBS 是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。WBS 每下降一个层次就意味着对项目工作更详尽的定义。

分解-树形结构

分解-列表形式

分解-按生命周期

分解-按可交付成果

WBS-概念 $\color{red}{★}$

1.里程碑 在每个分解单元中都存在可交付成果和里程碑（Milestone）。

2. 工作包 工作包（Work Package）是位于 WBS 每条分支最底层的可交付成果或项目工组成部分。
3. 控制账户 控制账户（Control Account）是一种管理控制点。在该控制点 上，将范围、预算（资源计划）、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。
4. 规划包 规划包（Planning Package）是指在控制账户之下，工作内容已知但尚缺详细进度活动的 WBS 组成部分。
5. WBS词典 在制作 WBS 的过程中，要给 WBS 的每个部分赋予一个账户编码（Code of Account）标志符，它们是成本、进度和资源使用信息汇总的层次结构。

WBS原则和注意事项

1. WBS 必须是面向可交付成果的。
2. WBS 必须符合项目的范围。
3. WBS 的底层应该支持计划和控制。
4. WBS 中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个 人参与。
5. WBS 的指导。作为指导而不是原则，WBS 应控制在 4～6 层。
6. WBS 应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分 包出去的工作。
7. WBS 的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
8. WBS 并非是一成不变的。

范围基准$\color{red}{★★★}$

$\color{red}{✓}$ $\color{red}{范围基准：批准的范围说明书、工作分解结构（WBS）和相应的WBS词典}$

$\color{red}{✓}$ WBS词典是描述WBS 各组成部分的文件

$\color{red}{✓}$ WBS词典包括：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息

确认范围

定义： 确认范围是正式验收己完成的项目可交付成果的过程。

作用： 本过程的主要作用：①使验收过程具有客观性；②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。

确认范围的步骤

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

检查什么

1. 可交付成果是否是确定的、可确认的
2. 每个可交付成果是否有明确的里程碑
3. 是否有明确的质量标准
4. 审核和承诺是否有清晰的表达
5. 项目范围是否覆盖了完成产品或服务的所有活动
6. 项目范围的风险是否太高，是否能够降低可预见风险对项目的冲击

干系人关注点

管理层： 范围对项目的进度、资金和资源的影响 客户： 产品范围，项目的可交付成果是否足够完成产品或服务 项目管理人员： 可交付成果是否足够和必须完成，时间、资金和资源是否足够 项目团队成员： 项目范围中自己参与的元素和负责的元素

验收的可交付成果

$\color{red}{✓}$ 由客户或发起人正式签字批准的符合验收标准的可交付成果

$\color{red}{✓}$ 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收

控制范围

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

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

偏差分析

$\color{red}{✓}$ 一种确定$\color{red}{实际}$绩效与$\color{#1989fa}{基准}$的差异程度及原因的技术

$\color{red}{✓}$ 可利用项目绩效测量结果评估偏离范围基准的程度，并决定是否需要采取纠正或预防措施

范围蔓延 vs. 镀金 $\color{red}{★}$

蔓延： 未经变更控制的产品或项目范围的扩大；往往由客户导致

镀金： 团队主动增加的项目范围以外的工作

几个术语的比较

确认范围与核实产品

核实产品是针对产品是否完成，在项目 （或阶段）结束时由发起人或客户来验证， 强调产品是否完整;确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验 收的过程。

确认范围与质量控制

确认范围与质量控制的不同之处在于∶

• 确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
• 质量控制一般在确认范围前进行，也可同时进行;确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。
• 质量控制属内部检查，由执行组织的相应质量部门实施;确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。从检查的详细程度来说，核实产品、确认范围和质量控制是递进的、越来越细的检查过程。

确认范围与项目收尾

确认范围与项目收尾的不同之处在于∶

• 虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
• 确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。