项目范围管理Scope Management
一.概述
1. 项目范围管理需要做三个方面的工作：
1）明确项目边界
2）对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做
3）防止项目范围发生蔓延
2. 产品范围和项目范围
1）产品范围指产品或者服务所应该包含的功能，定义的是产品要求的描述
判断产品范围是否完成，则根据产品是否满足了产品描述来判断。
2）项目范围指为了能够交付产品，项目所必须做的工作。定义的是产生项目管理计划的基础。
判断项目范围是否完成，要以范围基准来衡量
3）产品范围是项目范围的基础
4）项目的范围基准（Scope Baseline）是经过批准的项目范围说明书、WBS和WBS词典。
5）产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目范围。
二. 项目管理的过程
1. 规划范围管理
规划范围管理
输入：
1）项目管理计划
2）项目章程
3）事业环境因素
4）组织过程资产
输出:
1）范围管理计划
2）需求管理计划
工具和技术：
1）专家判断
2）会议
1.1 规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
1.2 范围管理计划
项目或项目集管理计划的组成部分，描述将如何定义、制订、监督、控制和确认项目范围。
范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，用于将作用于下列工作的管理过程做出规定。
- 如何制定项目范围说明书
- 如何根据范围说明书创建WBS
- 如何维护和批准WBS
- 如何确认和正式验收已完成的项目可交付成果
- 如何处理项目范围说明书的变更，该工作与实施整体项目变更控制过程直接相联
- 确定WBS满足职能和项目的要求，包括重置和非重置成本。
- 检查WBS是否为所有项目工作提供了逻辑细分
- 保证每一个特定层的总成本等于下一个层次构成要素的成本和
- 从全面适应和连续角度来检查WBS
- 所有的工作职责需分配到个人或组织单元
项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概况的，可以是正式的或者非正式的。
1.3 需求管理计划Requirement Management Plan
最基本任务是明确需求，并使项目团队和用户达成共识，即建立需求基线，还要建立需求跟踪能力联系链
需求管理计划是对项目的需求进行定义、确定、记载、核实管理和控制的行动指南。包括以下内容：
- 如何规划、跟踪和汇报各种需求活动
- 需求管理需要使用的资源
- 培训计划
- 项目干系人参与需求管理的策略
- 判断项目范围与需求不一致的准则和纠正规程
- 需求跟踪结构
- 配置管理活动
2. 收集需求
收集需求Collect Reqirement是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。
收集需求
输入：
1）范围管理计划
2）需求管理计划
3）干系人管理计划
4）项目章程
5）干系人登记册
输出：
1）需求文件
2）需求跟踪矩阵
2.1 需求的分类
1）业务需求：整个组织的高层级需要
2）干系人需求：干系人或干系人群体的需要
3）解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征、
4）过渡需求：从当前状态过渡到将来状态所需的临时能力，例如，数据转换和培训需求
5）项目需求：项目需要满足的行动、过程和其他条件
6）质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准
QFD对质量需求进行了细分，分为基础需求，期望需求和意外需求
2.2 手机需求的技术和工具
2.2.1 访谈
访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法，是最基本的一种收集需求的手段（1V1）
2.2.2 焦点小组
焦点小组将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论
焦点小组比一对一的访谈更热烈
2.2.3 引导式研讨会
通过邀请主要的跨职能干系人一起参加会议，引导式研讨会Facilitated Workshop对产品需求进行集中谈论和定义
2.2.4 群体创新技术
Group Creativity Technique指可以组织一些群体活动来识别项目和产品需求。包括多种技术。
1）头脑风暴
头脑风暴BrainStorming,BS又称为智力激励法、自由思考法或集思广益法。
分为直接头脑风暴法（头脑风暴法）和质疑头脑风暴法（反头脑风暴法）
一般参加人数5~10人，最好由不同专业或不同岗位者组成，时间在1个小时左右。
原则：庭外判决原则； 欢迎各抒己见，自由鸣放； 追求数量； 探索取长补短和改进办法。
2）名义小组技术
名义小组Nominal Group Technique通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴的深化应用，是更加结构化的头脑风暴法
3）德尔菲技术（私聊）
德尔菲技术Delphi Technique是一种组织专家就某一主题达成一致意见的一种信息收集技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。缺点是过程比较复杂，花费时间较长。
4）概念/思维导图
思维导图Mind Mapping又称为心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性和差异，从而引导出新的创意。
5）亲和图
亲和图Affinity Diagram又称KJ法，是针对某一问题，充分收集各种经验，知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。
6）多标准决策分析
多标准决策分析（Multi-Criteria Decision Analysis）是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
2.2.5 群体决策技术（Group Decision-Making）
群体决策技术为达成某种期望结果而对多个未来行动方案进行评估。
1）一致同意（Unanimity）
2）大多数原则（Majority）
3）相对多原则（Plurality）
4）独裁（Dictatorship）
2.2.6 问卷调查
2.2.7 观察
指直接观察个人在各自环境中如何开展工作和实施流程
2.2.8 原型法
根据干系人初步需求，利用产品开发工具，快速建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法。
2.2.9 标杆对照
将实际或计划的做法与其他类似组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据
2.2.10 系统交互图
对产品范围的可视化描述，显示系统与参与者之间的交互方式
2.2.11 文件分析
通过现有文档，识别与需求相关的信息来挖掘需求
2.3 需求文件
需求文件描述各种单一的需求将如何满足与项目相关的业务需求
包括：业务需求，干系人需求，解决方案需求，项目需求，过度需求，与需求有关的假设条件、依赖关系和制约因素。
2.4 需求跟踪
需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划于需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
2.4.1 可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪。
1）需求跟踪内容
双向可跟踪性，包括正向跟踪和反向跟踪。
正向跟踪指检查需求文件中的每个需求是否都能在后续工作产品(成果)中找到对应点；
反向跟踪也称逆向跟踪，指检查设计文件、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。
见课本P233页，图中箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。
左半部分表明，从用户原始需求可向前追溯到需求文件，可以从需求文件回溯到相应的用户原始需求。
第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
2）需求跟踪矩阵
表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪矩阵。
可以定义各种产品元素类型间的一对一，一对多和多对多关系
3. 定义范围
制定项目和产品详细描述的过程，主要作用是明确所收集的需求哪些将包含在项目范围之内，哪些将排除在项目范围外，从而明确产品、服务或者成果的边界。
定义范围
输入：
1）范围管理计划
2）项目章程
3）需求文件
4）组织过程资产
输出：
1）项目范围说明书
2）项目文件更新
工具和技术：
1）专家判断
2）产品分析
3）备选方案生成
4）引导式研讨会
3.1 工具和技术
3.1.1 产品分析
产品分析技术包括产品分解，系统分析，需求分析，系统工程，价值工程和价值分析等
价值工程和价值分析两种活动都是对商品的价值、功能和成本进一步做思考与探索，朝各方向寻求最佳方案。
3.1.2 备选方案生成
用来指定尽可能多的潜在可选方案的技术
备选方案分析是一种对已识别的可选方案进行评估的技术
横向思维又称戴博诺理论、发散思维、水平思维，指思维的广阔度
3.2 项目范围说明书
3.2.1 内容
1）产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征
2）验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程
3）可交付成果。既包括组成项目产品或服务的各种结果，也包括各种辅助效果
4）项目的除外责任。通常需要识别出什么是被排除在项目之外的
5）制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素
6）假设条件。在制订计划时，不需验证即可视为正确、真实或确定的因素
3.2.2 作用
1）确定范围
2）沟通基础
3）规划和控制依据
4）变更基础
5）规划基础
4. 创建工作分解结构 WBS
将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。主要作用是对所要交付的内容提供一个结构化的视图。
4.1 WBS的层次
1）里程碑：标志某个可交付成果或者阶段的正式完成
2）工作包：位于WBS每条分支最底层的可交付成果或项目工作组成部分。
作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应至少需要8个小时来完成，总完成时间不应大于80H
3）控制账户：管理控制点，将范围、预算、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效
4）规划包：在控制账户内，工作内容已知但尚缺详细进度活动的WBS组成部分
5）WBS词典：为WBS的每个部分赋予一个账户编码标识符，是成本进度和资源使用信息汇总的层次结构
4.2 分解
4.2.1 通常需要开展以下活动：
1）识别和分析可交付成果及相关工作
2）确定WBS的结构和编排方法
3）自上而下逐层细化分解
4）为WBS组件制定和分配标识编码
5）核实可交付成果分解的程度是恰当的
4.2.2 分解的原则：
1）功能或者技术原则
2）组织结构
3）系统或者子系统
4.2.3 项目管理实践中，可以按照下列方式进行分解：
1）项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
2）主要可交付成果作为分解的第二层
3）整合可能由项目团队以外的组织来实施各种组件（如外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。
5. 确认范围
6. 控制范围
