项目范围管理

项目范围管理

pmi推荐：做且只做该做（所需要的全部工作）的事情（额外的工作会多花成本），项目范围以外的事情，理论上就不是项目上该做的，不要“失控"。

客户的想法不一定都要去满足

1. 范围管理步骤

管理过程	解释
规划范围管理	为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
收集需求	为实现目标而确定、记录、管理相关方需要和需求的工程（输出需求规格说明书）
定义范围	制定项目和产品详细描述的过程（把需求转换为要做的事情）
创建WBS（工作分解结构）	将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
确认范围	正式验收已完成的项目可交付成果的过程
控制范围	监控项目和产品的范围状态，管理范围基准变更的过程

1.1项目环境中“范围” 定义

1. 产品范围：产品、服务、成果所具有的特征和功能（客户想要的） ------ 客户理想的效果，WHAT。需要注意，客户想要的往往要大于客户需要的。
2. 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作（我们必须做的）-------实际的施工图，HOW
   

1.2 不同类型项目中“控制范围”

1. 预测型：开始时定义可交付成果，过程中对所有范围变化进行渐进管理（变更）
2. 适应型或敏捷型：整体范围分解为一系列未完成项，多轮迭代完成。每次迭代前确定本次迭代的范围，每次迭代中，反复进行“收集需求–定义范围–创建WBS"的流程

2. 规范化范围管理

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

主要作用是，在整个项目期建对如何管理范围提供指南和方向

在项目期间只开展一次或者仅在预定义项目节点开展

输入	工具与技术	输出
1. 项目章程 2. 项目管理计划（质量管理计划、项目生命周期描述、开发方法 3. 事业环境因素 4. 组织过程资产	1. 专家判断 2. 数据分析（备选方案分析） 3. 会议	1. 范围管理计划 2. 需求管理计划

需求管理计划(What to do)	范围管理计划(How to do)
1. **如何**规划、跟踪和报告各种**需求**活动 2. 配置管理活动，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限 3. 需求优先级排序过程 4. 测量指标及使用这些指标的理由 5. 反映哪些需求属性将被列入需求跟踪矩阵的跟踪结构	1. 制定项目范围说明书 2. 根据详细项目范围说明书创建WBS 3. 确定如何审批和维护范围基准 4. 正式验收已完成的项目可交付成果
也称作”商业分析计划“，描述如何分析、记录和管理项目和**产品需求**	描述将如何定义、制定、监督、控制、确认**项目范围**

2.1 收集需求

收集需求是为了实现目标而确定、记录并管理相关方需求的过程，为定义产品范围和项目范围奠定基础

收集需求在项目周期中只开展一次，或者只在预定义的项目节点开展

输入	工具与技术	输出
1. 项目章程 2. 项目管理计划（范围管理计划、需求管理计划、相关方参与计划） 3. 项目文件（假设日志、经验教训登记册、相关方登记册） 4. 商业文件（商业论证） 5. 协议 6. 事业环境因素 7. 组织过程资产	1. 专家判断 2. 数据收集（头脑风暴、访谈、焦点小组、问卷调查、标杆对照、德尔菲法） 3. 数据分析（文件分析） 4. 决策（投票、多标准决策分析） 5. 数据表现（亲和图、思维导图） 6. 人际关系与团队技能（名义小组技术、观察/交谈 7. 系统交互图 8. 原型法	1. 需求文件（需求规格说明书） 2. 需求跟踪矩阵

2.1.1 需求收集技术

收集需求的输入：人（相关方）、文件、事业环境因素、组织过程资产

头脑风暴关键点：不做评判、以量求质

工具与技术	适用情况
头脑风暴	用来产生和收集项目需求和产品需求的多种创意的技术，关键是“延迟评判”，”追求数量“，头脑风暴不需要主持人
名义小组	用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或者优先排序
访谈	通过直接交谈来获取信息的正式、非正式方法 访谈可以是一对一的模式，也可以是一对多的模式，也可以用来获取机密信息或更准确的信息
焦点小组	由一位受过训练的主持人引导大家进行交互式讨论，往往比“一对一”的访谈更热烈
问卷调查	受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析
德尔菲技术	由一组选定的专家评估需求，专家的答复只能交给主持人，维护其匿名状态。评估结果有分歧时，进行多轮评估，直到达成一致（准确的说应该是趋向一致）,关键点是”匿名“，”反馈“，”统计“，主要是为了避免”光环效应“，防止权威意见的干扰导致其他人不敢表达异议
标杆对照	将实际或计划的产品、过程、实践，与其他可对比的时间进行比较，以便识别较优实践，关键词是模仿、抄袭
专家判断	专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。

2.1.2 数据决策技术

工具与技术	适用情况
投票	未达成某种期望，对多个备选方案进行评估的集体决策手段
一致同意	每个人都同意某个行动方案、达成一致同意的一种方法就是德尔菲技术
大多数原则	50%以上的人员认可，就能做出决策（群体成员设置为奇数，防止平局）
相对多数原则	根据群体中相对多数人的意见做出决策（通常在候选项两个以上的时候使用）
独裁型决策制定	某一个人负责为整个集体制定决策，必要时可起到高效决策作用
多标准决策分析（权重分析）	借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性、价值收益等多种标准，以对众多候选项进行排序、评估

2.1.3 数据表现技术

头脑风暴：简单整理，信息比较凌乱

亲和图：聚类过程，将近似的数据分类汇总

思维导图：跟亲和图的差别是，思维导图有一个中心思想

2.1.4数据建模工具

系统交互图：对产品范围的可视化描绘，显示业务系统及其与人和其它系统（行动者）之间的交互方式。

原型法：在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维或三位模型、实体模型或模拟。
原型法支持渐进明细的理念
故事板是一种原型技术，通过一系列的图像或图示展现顺序或导航路径

2.1.5 人际关系与团队技能

侧重点是：达成一致，达成共识，有分歧注意不站队
观察：也称为“工作跟随”，当产品使用者难以或不愿清晰说明他们的需求时适用

两种观察：旁站观察、参与式观察

引导：引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求，研讨会可用于快速定义跨职能需求并协调相关方的需求差异。与分别召开会议相比，研讨会能够更早的发现差异性分歧

适合采用引导技能的情境：

场景	描述
联合应用设计或开发（JAD）	适用于软件开发行业，研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程
质量功能展开（QFD）	适用于制造行业，用来帮助确定新产品的关键特征，从收集客户需要（客户声音）开始，然后客观的对这些需要进行分类和排序，并为实现这些需要设定目标
用户故事	用户故事是对需求的简短文字描述，经常产生于需求梳理会 用户故事描述哪些相关方（角色）从产品中受益，能够实现什么（目标），为他创造什么（价值）

2.1.6 收集需求的输出

需求文件：包含业务需求（业务解决方案）和产品需求（技术解决方案）

只有明确的（可测量、可测试的）、可跟踪的，完整的、相互协助的、且主要想官方愿意认可的需求，才能作为基准（smart原则）

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

​ 跟踪的需求一定是经过裁剪后，被批准的需求文件中的需求，每项需求在项目结束时都能交付。

2.1.6.1 需求文件

需求文件描述各种单一需求将如何满足与项目相关的业务需求。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要想官方愿意认可的需求，才能作为基准。

需求可以分为业务解决方案和技术解决方案，前者是相关方的需要，后者是指如何实现这些需要。

需求类型包括：相关方需求、解决方案需求（功能需求+非功能需求）、过度和就绪需求、项目需求、质量需求等。

2.1.6.2 需需求跟踪矩阵

把产品需求是用来对连接到能满足需求的可交付成果的一种表格。
提供了在整个生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的没想需求在项目结束的时候都能交付
最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

需求跟踪矩阵相较于需求文件，多了WBS和设计、开发、测试等环节的记录。需求文件和范围说明里面都只有描述，没有结果，如果出现”需求“、”实现“不一致的情况，查看需求跟踪矩阵。

2.2 定义范围

制定项目和产品详细描述的过程。

主要作用是描述产品、可交付成果的边界和验收标准
收集完需求之后，把从客户获得到需求转换为可交付成果，定义范围就是对可交付成果的描述过程
定义范围是要从需求文件中选取最终的项目需求，并制定关于项目及其产品、服务、成果的边界和最终验收标准

输入	工具与技术	输出
1. 项目章程 2. 项目管理计划（范围管理计划） 3. 项目文件（假设日志、需求文件、风险登记册） 4. 事业环境因素 5. 组织过程资产	1. 专家判断 2. 数据分析（备选方案分析） 3. 决策（多标准决策分析） 4. 人际关系与团队技能（引导） 5. 产品分析	1. 项目范围说明书 2. 项目文件更新（假设日志、需求文件、需求跟踪矩阵、相关方登记册）

2.2.1 范围说明书

需求文件（头）—> 需求跟踪矩阵（桥梁）—> 范围说明书（尾）

• 需求文件中，只有需求描述
• 范围说明书中，只有结果的描述
• 需求跟踪矩阵中，包含需求的分析、设计、实现的过程。

范围说明书包括以下内容：

1. 产品范围描述，包括产品和项目范围
2. 可交付成果--------范围说明书中详细描述了可交付成果，项目章程中会描述主要可交付成果（高阶）
3. 验收标准：可交付成果通过验收前必须满足的一系列条件
4. 项目的除外责任：识别排除在项目之外的内容，明确说明哪些不属于项目范围，有助于管理相关方的期望及减少范围蔓延
5. 项目边界基准：为评价变更请求或额外工作是否超过项目边界提供基准

项目章程	范围说明书
项目目的	项目范围描述（渐进明细）
可测量的项目目标和相关的成功标准（high level)	项目可交付成果
高层及需求	验收标准
高层级项目描述、边界定义	项目排除项
主要可交付成果
总体里程碑进度计划
......

2.2.2 创建WBS（work breakdown structure）

把项目可交付成果和项目工作分解成较小、更容易管理的组件的过程

主要作用：为所要交付的内容提供架构

仅开展一次或仅在项目的预定义点开展

WBS中的“工作”指的是 项目活动中的可交付成果或工作产品，而不是项目活动本身

WBS组织并定义了项目的总范围，代表了经批准的当前项目范围说明书中所规定的工作。

WBS中最低层级是带有独特标识号的工作包，只是要对事情的拆解，是个名词，比工作包更小的叫**”活动“**

规划包：比工作包高一层级，可用于规划的内容
WBS拆解以终为始，以可交付成果为导向

输入	工具与技术	输出
1. 项目管理计划（范围管理计划） 2. 项目文件（项目范围说明书、需求文件） 3. 事业环境因素 4. 组织过程资产	1. 专家判断 2. 分解	1. 范围基准（范围说明书、WBS、WBS词典 2. 项目文件更新（假设日志、需求文件）

2.2.2.1 WBS分解技术

1. 自上而下

   逐层细化分解

2. 自下而上

   用于归并较低层次组件

3. 滚动式规划

   要在未来远期中才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致，才能制定出WBS中相应的细节

8-80H原则：每个工作包应该在8-80小时比较合适（1d-2w）
100%原则：项目中所有的工作包都需要在WBS中（不管是不是外包，是不是本团队在做，一个都不能多，一个都不能少）

2.2.2.2 WBS词典

WBS词典：针对WBS中的每个组件（工作包、规划包）的详细描述

WBS词典包含不限于：

1. 账户编码标识（工作编号）
2. 工作描述
3. 假设条件和制约因素
4. 负责的组织
5. 进度里程碑
6. 相关的进度活动
7. 所需资源
8. 成本估算
9. 质量要求
10. 验收标准 ----- 针对的是对工作包的验收标准（更细化的标准），汇总后才是范围说明书中的标准
11. 技术参考文献
12. 协议信息

2.2.3 范围基准

2.3 确认范围

确认范围是正式验收已完成的可交付工作成果。工作中顺序是**”控制质量“—> 确认范围—> 收尾**
主要作用：使验收过程具有客观性，同时通过确认每个可交付成果来提高最终产品、服务、成果获得验收的可能性
确认范围 按需在整个项目过程中定期开展
注意区分确认范围和定义范围，确认范围是做验收，定义范围是前期确定要做什么。
正式验收（确认范围）的基准是范围说明书中的验收标准。

输入	工具与技术	输出
1. 项目管理计划（范围管理计划、需求管理计划、范围基准） 2. 项目文件（经验教训登记册、质量报告、需求文件、需求跟踪矩阵） 3. 核实的可交付成果 4. 工作绩效数据	1. 检查 2. 决策	1. 验收的可交付成果 2. 工作绩效信息 3. 变更请求 4. 项目文件更新（经验教训登记册、需求文件、需求跟踪矩阵）

2.3.1 确认范围的概念

由客户或发起人审查从控制质量过程输出的核实的可交付成果，是对可交付成果的确认和最终验收。。

确认范围与控制质量过程不同之处在于，确认范围关注可交付成果的验收，控制质量关注可交付成果的正确性及是否满足质量要求
可交付成果不是一步到位的，如下图（经过反复控制、核对的）

2.3.2 确认范围的执行

时间：确认范围在每个可交付成果生成时，或者在阶段审查点开展（阶段结束时）

事件：通过检查开展测量、审查、确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准

人物：符合验收标准的可交付成果应该由客户或发起人正式签字批准，应该从客户或发起人那里获取正式文件，证明相关方对项目可交付成果的正式验收

2.3.3 确认范围的方法

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

2.4 控制范围

控制范围是：监督项目和产品的范围状态，管理范围基准变更的过程-----------监督、控制，控制可以通过走变更，调整范围或修正范围

主要作用：在项目期间保持对项目基准的维护，且需要在整个项目过程中开展

不支持镀金（镀金存在失败的可能，失败造成损失怎么办），有变更走流程

输入	工具与技术	输出
1. 项目管理计划（范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准） 2. 项目文件（经验教训登记册、需求文件、需求跟踪矩阵） 3. 组织过程资产 4. 工作绩效数据	1. 数据分析（偏差分析、趋势分析）	1. 工作绩效信息 2. 变更请求 3. 项目管理计划更新（范围管理计划、范围基准、进度基准、成本基准、绩效测量基准） 4. 项目文件更新（经验教训登记册、需求文件、需求跟踪矩阵）

2.4.1 有变更、走流程

通常只有三种情况需要进行范围变更：

1. 客户提出新需求
2. 执行过程中范围蔓延要变更
3. 验收未达预期变更

范围蔓延：未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整），被称为范围蔓延。注意如果客户提了新需求，对这部分需求产生的成本认可，增加相应的预算，则不算是范围蔓延。

流程：先了解—> 再分析—> 提申请

2.4.2 控制范围技术

1. 偏差分析：旨在分析用于将实际结果和基准进行比较，确定偏差是否处于临界值范围内
2. 趋势分析：旨在审查项目绩效随时间的变化情况，判断绩效是正在改善还是正在恶化