项目范围管理，就是确保项目做且只做所需的全部工作

产品范围：

• 某项产品、服务或成果所具有的特性和功能

项目范围：

• 为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
• 项目范围有时也包括产品范围

规划范围管理

• 定义：创建范围管理计划，书面描述将如何定义、确认和控制项目范围
• 作用：在整个项目中对如何管理范围提供指南和方向

范围管理计划

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

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

• 制定详细项目范围说明书
• 根据详细项目范围说明书创建WBS
• 维护和批准工作分解结构（WBS）
• 正式验收已完成的项目可交付成果
• 处理对详细项目范围说明书或WBS的变更

需求管理计划

描述如何分析、记录和管理需求

主要内容至少包括：

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

收集需求

• 定义：为实现项目目标而确定、记录并管理干系人的需要和需求
• 作用：为定义和管理项目范围（包括产品范围）奠定基础

项目章程：项目产品、服务或成果的高层级描述

干系人管理计划：干系人的沟通需求和参与程度

干系人登记册：哪些干系人能够提供需求方面的信息、干系人对项目的主要需求和期望

访谈

• 与干系人直接交谈来获取信息
• 一对一、多对多
• 有经验的项目参与者、发起人、其他高管、主题专家

焦点小组

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

引导式研讨会

• 把主要干系人召集在一起，集中讨论来定义产品需求
• 快速定义跨职能需求、协调干系人差异
• 有助于参与者之间建立信任、改进关系、改善沟通、达成一致意见
• 联合应用设计/开发（JAD）、质量功能展开（QFD）
• 用户故事

群体创新技术

• 头脑风暴法：庭外判决、自由鸣放、追求数量
• 名义小组技术：分组、多轮询问、评审排序
• 概念/思维导图：将创意用一张简单的图联系起
• 亲和图：对大量创意进行分组
• 多标准决策分析：借助决策矩阵，对众多方案进行评估和排序
• 德尔菲技术：组织专家就某一主题达成一致意见的信息收集技术
• 特点：
• 吸收专家参与预测，充分利用专家的经验和学识
• 采用匿名或背靠背的方式，能使每一位专家独立自由地做出自己的判断
• 预测过程几轮反馈，使专家的意见逐渐趋同
• 减轻数据偏倚，防止个人对结果产生不恰当的影响
• 专家、函询、匿名、多轮

群体决策技术

• 一致同意
• 大多数原则
• 相对多数原则
• 独裁

问卷调查

• 设计一系列书面问题，向众多受访者快速收集信息
• 适用于：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析

 观察

• 直接察看个人在各自的环境中如何执行工作和实施流程
• 当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节
• 体验该流程或程序是如何实施的，以便挖掘隐藏的需求

原型法

• 先造出该产品的实用模型，据此征求对需求的早期反馈
• 故事版是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径

标杆对照

• 将实际或计划的做法与其他可比的做法进行比较，以便识别最佳实践，形成改进意见，并未绩效考核提供依据
• 所采用的可比做法可以是内部的，也可以是外部的

系统交互图

• 是对产品范围的可视化描绘
• 显示业务系统与人和其他系统之间的交互方式

文件分析

分析现有文档，识别与需求相关的信息，来挖掘需求

如：

• 商业计划
• 业务规则库
• 应用软件文档
• 业务流程或接口文档
• 用例
• 其他需求文档
• 问题日志
• 政策
• 程序和法规文件（如法律、准则、法令等）

需求文件

• 业务需求：整个组织的高层级需要
• 干系人需求：干系人或干系人群体的需要
• 解决方案需求：功能需求/非功能需求
• 项目需求：项目需要满足的行动、过程或其他条件
• 过渡需求：从“当前状态”过渡到“将来状态”所需的临时能力
• 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准

需求跟踪矩阵

• 把产品需求从某来源连接到能满足需求的可交付成果的一种表格
• 提供了在整个项目生命周期中跟踪需求的一种方法
• 为管理产品范围变更提供了框架

定义范围

• 定义：制定项目和产品详细描述
• 作用：明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界

产品分析

• 对于产品为交付成果的项目非常有效
• 包括：产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等

备选方案分析

制定尽可能多的潜在可选方案

识别执行项目工作的不同方法

生成备选方案的技术有：头脑风暴、横向思维、备选方案分析

项目范围说明书

对项目范围、主要可交付成果、假设条件和制约因素的描述

记录了整个范围，包括项目和产品范围

包括：

• 项目目标
• 产品范围描述
• 项目需求
• 项目边界
• 项目的可交付成果
• 项目的制约因素
• 假设条件

创建工作分解结构（WBS）

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

作用：对所要交付的内容提供一个结构化的视图

分解

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

WBS

• 对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
• 工作分解结构每向下分解一层，代表着对项目工作更详细的定义
• 是后续管理工作的主要依据，是项目时间、成本、人力等管理工作基础
• 树形结构、列表形式

WBS概念

项目为创造独特的产品、服务和成果而进行的临时性的工作

子项目是整个项目中的一个半独立、便于管理、较小部分的项目，由一个专业团队或分包组织来负责

控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较以测量绩效。每个控制账户与组织分解结构中的一个具体组织组件想关联。

工作包是WBS最底层的可交付成果或项目工作组件。便于完整的交由专人（或组织单元）负责。遵循8/80规则（经验法则）。一个控制账户可以包含多个工作包；一个工作包只能属于一个控制账户。

规划包是工作内容已知，但详细的进度活动未知的WBS组件。在控制账户之下、工作包之上（同级）。随项目深入，将被分解成工作包。提前“占坑”。

活动是工作包的组成部分，不属于WBS组件。是制定进度计划的基本单元。一般由执行部门定义。

任务是活动的组成部分，不属于WBS组件。一般由个人定义。

WBS原则

• 有理
• 有据
• 有人管
• 不缺
• 不重
• 不添乱

范围基准

批准的范围说明书、工作分解结构（WBS）和相应的WBS词典

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

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

确认范围

定义：正式验收已完成的项目可交付成果

作用：使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性

确认范围VS控制质量

确认范围：关注可交付成果的验收

控制质量：管理可交付成果的正确性及是否满足质量要求

确认范围的步骤

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

检查什么？

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

干系人关注点

管理层：范围对项目的进度、资金和资源的影响

客户：产品范围，项目的可交付成果是否足够完成产品或服务

项目管理人员：可交付成果是否足够和必须完成，时间、资金和资源是否足够

项目团队成员：项目范围中自己参与的元素和负责的元素

验收的可交付成果

由客户或发起人正式签字批准的符合验收标准的可交付成果

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

控制范围

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

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

偏差分析

一种确定实际绩效与基准的差异程度及原因的技术

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

范围蔓延VS镀金

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

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