PMP-第五章 项目范围管理

范围概述与核心概念

• 范围管理目的：做且只做所需的全部工作，以成功完成项目
• 管理项目范围主要在于定义和控制哪些工作包括在项目内， 哪些不应包括在项目内
• 项目范围有时也包括产品范围
• 范围基准由范围说明书、WBS和WBS词典共同构成
• 范围区分：
  • 产品范围——某项产品、服务或成果所具有的特性和功能
  • 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
• 衡量依据：  
  • 产品范围——需求文件
  • 项目范围——项目管理计划

注意点：要了解范围与需求区别，
需求：客户想要的，为什么要。
范围：团队做什么能满足需求。

过程构成

规划范围管理

• Plan Scope Management
• 过程定义：创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程
• 过程作用：在整个项目中对如何管理范围提供指南和方向
• 项目范围管理计划是项目管理计划的组成部分描述将如何定义、制定、监督、控制和确认项目范围
• 范围管理是项目管理的基础

过程-规划范围管理

规划范围管理:输出

范围管理计划

• 项目管理子计划之一
• 范围管理计划对下列管理过程做出规定：
  • 制定项目范围说明书
  • 根据详细项目范围说明书创建WBS
  • 确定如何审批和维护范围基准
  • 正式验收已完成的项目可交付成果
  • 处理对详细项目范围说明书的变更（该工作与实施整体变更控制过程直接相联）
• 根据项目需要，范围管理计划可以是正式或非正式，非常详细或高度概括的

小结：范围管理计划通常情况下没有必要修改和更新。但是，流程和指南有问题，需要提交请求批准。

需求管理计划

• 项目管理子计划之一
• 描述将如何分析、记录和管理项目和产品需求
• 主要内容：
  • 如何规划、跟踪和报告各种需求活动
  • 配置管理活动
  • 需求优先级排序过程
  • 测量指标及使用这些指标的理由
  • 反映哪些需求属性将被列入需求跟踪矩阵

小结：需求管理计划没有必要修改和更新。

收集需求

• Collect Requirements
• 过程定义：为实现项目目标而确定、记录并管理干系人的需要(needs) 和需求(requirements)的过程
• 过程作用：为定义产品范围和项目范围奠定基础
• 需求是指根据特定协议或者其他强制性规范，产品、服务或成果必须具备的条件或能力
• 它包括发起人、客户和其他干系人的已量化且书面记录的需要 （needs）和期望(expectations)
• 让干系人积极参与需要探索和分解成需求的工作，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功
• 收集需求是开展项目工作的基础

收集需求 :过程

收集需求 :T&T

数据收集->问卷调查

• Questionnaires and Surveys
• 通过设计一系列书面问题，向众多受访者快速收集信息
• 适用场景：
  • 受众多
  • 需快速完成调查
  • 受访者地理位置分散
  • 适合使用统计分析

数据收集->标杆对照

• Benchmarking
• 将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据
• 标杆对象来源：
  • 执行组织内部或外部项目
  • 同一应用领域的项目
  • 不同应用领域的项目

数据分析-文件分析

• Document Analysis
• 通过分析现有文档，识别与需求相关的信息，来挖掘需求可供分析的文档包括(但不限于):
  • 协议
  • 商业计划
  • 业务流程和接口文档业务规则库
  • 现行流程
  • 市场文献
  • 问题日志
  • 政策和程序
  • 法规文件
  • 建议邀请书
  • 用例等

决策

• Decision-Making
• 投票（Voting）是一种为达成某种期望结果，而 对多个未来行动方案进行评估的集体决策技术
  • 一致同意(Unanimity)：100%同意，德尔菲技术
  • 大多数同意 (Majority)：超过50%同意，奇数原则，小数服从多数。
  • 相对多数同意 (Plurality)：候选项超过两个时使用，候选有三个以上，选择最多投票的。
• 独裁型决策（Autocratic）：一言堂
• 多标准决策分析（Multicriteria Decision Analysis）
  • 借助决策矩阵，用系统分析方法建立诸如风险水平、不确 定性和价值收益等多种标准，以对众多创意进行评估和排序

决策->投票->德尔菲技术

• Delphi Technique
• 用来获得专家意见的常用方法，防止个人对结果产生不恰当的影响
• 创始者：兰德（RAND）公司，借用古希腊神话典故命名
• 由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈，专家的答复只能交给主持人以保持匿名状态
• 用途：范围、时间、成本、质量、风险等
• 遵守下列基本规则：（vs 头脑风暴）
  • 专家之间背靠背（目的防止个人对投票影响）
  • 专家以匿名形式提出意见
  • 多轮次投票
  • 旨在取得一致意见(Consensus)

数据表现->亲和图

• Affinity diagrams
• 对大量创意进行分组，以便进一步审查和分析
• 又称KJ法
• 归纳法的运用

小结：分组、分类、归纳

数据表现->思维导图

• Mind mapping
• 把从头脑风暴中获得的创意整合成一张图，以反映创意之间的共性与差异，激发新创意
• 演绎法的运用

人际关系与团队技能->名义小组技术

• Nominal group technique （NGT）
• 名义小组技术：用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序
• 典型方法：
  • 管理者先选择一些对要解决的问题有研究或者有经验的人作为小组成员，并向他们提供与决策问题相关的信息
  • 小组成员各自先不通气，请他们独立思考，要求每个人尽可能把自己的备选方案和意见写下来。 
  • 然后再按次序让他们一个接一个地陈述自己的方案和意见
  • 由小组成员对提出的全部备选方案进行投票
  • 根据投票结果，赞成人数最多的备选方案即为所要的方案

小结： 头脑风暴 + 排序：1）组织决策；2) 互不通气，写下方案和意见；3）陈述方案和意见； 4）投票；5)最多票为所方案；

人际关系与团队技能->观察/交谈

• Observation/Conversation
• 直接察看个人在各自的环境中如何执行工作（或 任务）和实施流程
• 针对产品使用者难以或不愿清晰说明他们的需求
• 两种观察法：
  • 工作跟随（Job shadowing） • 由观察者从外部来观察业务专家如何执行工作，获得隐性知识。
  • 参与观察者（Participant observer） • 参与观察者实际执行一个流程或程序，体验该流程或程序是如 何实施，以便挖掘隐藏的需求

人际关系与团队技能->引导

• Facilitation
• 引导与主题研讨会结合使用，召集主要干系人一起定义产品需求
• 研讨会可用于快速定义跨职能需求和协调干系人的需求差异
• 由于具有群体互动的特点，有效引导的研讨会有助于参与者建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。
• 研讨会能够比单项会议更快地发现并解决问题。
• 引导式研讨会在不同情境有不同的实践应用

小结：推动技术、推进技术。跨职能、跨部门、达成一致。
达成一致二个工具：《人际关系与团队技能->引导》 、《人际关系与团队技能->名义小组技术》和 《决策->投票->德尔菲技术》

联合应用设计/开发(JAD)

• Joint Application Design/Development
• 引导式研讨会在软件行业的应用
• 把用户和开发团队集中在一起，以收集需求和改进软件开发过程
• 适用于需求复杂并且跨部门的软件项目
• 因为用户参与了开发的全过程，JAD大大加快了开发的速度，并提高了客户的满足感

小结：软件行业 + 引导式研讨会 = 联合应用设计/开发(JAD)，关键字： 跨部门

质量功能展开(QFD)

• Quality Function Deployment
• 引导式研讨会在制造业中的应用
• 采用QFD来帮助确定新产品的关键特征
• QFD 从收集客户需求(又称顾客声音，VOC)开始，然后客观地对这些需求进行分类和排序
• 并为实现这些需求而设置目标

小结：制造业 + 引导式研讨 =  质量功能展开(QFD)，关键字：分类、排序，听客户声音

用户故事

• User Story
• 引导式研讨会在敏捷方法中的应用
• 用户故事是对所需功能的简短文字描述，产生于需求研讨会(Requirements workshop )
• 用户故事描述了:
  • 角色:哪个干系人将从功能中受益
  • 目标:他需要实现什么
  • 动机:以及他将获得什么收益

小结：敏捷方法 + 引导式研讨会 = 用户故事

原型法

• Prototypes
• 在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈意见
• 原型包括微缩产品， 2D或3D模型、实体模型或模拟，使干系人有机会体验最终产品的模型

收集需求 : 输出

需求文件

• Requirements Documentation
• 需求文件描述各种单一需求将如何满足与项目相关的业务需求
• 一开始可能只有高层级需求，随着有关需求信息的增加而逐步细化
• 需求文件格式可详可简
• 主要干系人认可的、明确的（可测量和可测试的）、可跟踪的、完整 的、相互协调的需求才可作为需求

需求跟踪矩阵

• Requirements Traceability Matrix（RTM）
• RTM是把产品需求从其来源连接到能满足需求的可交付成果的一种表格
• 使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起 来， 有助于确保每个需求都具有商业价值。此外， RTM提供了 在整个项目生命周期中跟踪需求的一种方法，有助于确保需求 文件中被批准的每项需求在项目结束时候都能交付。
• 应在RTM中记录需求属性（来源， 优先级、版本、当前状态 （进行中、已取消、已推迟、新增加、已批准、被分配、已完 成）和状态日期等）
  

小结：需求跟踪矩阵把产品需求与可交付成果关联；

定义范围

• Define Scope
• 过程定义：制定项目和产品详细描述的过程
• 过程作用：明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外， 从而明确项目、服务或成果的边界
• 定义范围要从需求文件中选取最终的项目需求
• 准备好详细的项目范围说明书，对项目成功至关重要

定义范围-过程

定义范围-T&T

产品分析

• Product Analysis
• 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品用途、特征及其他方面
• 每个应用领域都有一种或几种普遍公认的方法，用于把高层级的产品描述转变为有意义的可交付成果
• 首先获取高层级需求，然后将其细化到最终产品设计所需的详细程度
• 产品分析技术包括（但不限于）：
  • 产品分解 product breakdown
  • 需求分析 requirements analysis（参见需求文件）
  • 系统分析 systems analysis（参见系统交互图）
  • 系统工程 systems engineering
  • 价值工程 value engineering
  • 价值分析 value analysis

产品分解

• 通过树状结构反映产品的各类部件，每类部件在结构中仅出现一次
• 产品分解结构（Product Breakdown Structure， PBS）

定义范围：输出

项目范围说明书

• Project Scope Statement
• 是对项目范围、主要可交付成果、假设条件和制约因素的描述
• 记录了整个范围，包括项目和产品范围
• 详细描述项目的可交付成果，以及为创建这些可交付成果而必须开展的工作

项目范围说明书

创建WBS

• Create WBS（Work Breakdown Structure）
• 过程定义：把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程
• 过程作用：对所要交付的内容提供框架
• WBS是对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作范围的层级分解
• WBS的最底层的组件称为工作包
• WBS中的“工作” 代表了作为活动结果的工作产品或可交付成果，而非活动本身

创建WBS-过程

创建WBS-T&T

分解

• Decomposition
• 分解是把项目范围和可交付成果逐步划分为更小、 更便于管理的组成部分的技术
• 分解的程度取决于所需的控制程度， 以实现对项目的高效管理
• 分解的步骤：
  • 识别和分析可交付成果及其相关工作
  • 确定WBS的结构和编排方法
  • 自上而下逐层细化分解
  • 为WBS组件(Components)制定和分配标识编码
  • 核实可交付成果分解的程度是否恰当

按项目生命周期分解WBS

按主要可交付成果分解WBS

工作包

• Work Package
• 工作包是WBS最底层的组件， 可对其进行成本和持续时间进行估算和管理
• 工作包的详细程度因项目规模和复杂度而异
• 从逻辑的角度上讲不能再分下去了
• 有一个可交付的结果和有标志性的结束
• 能够可靠地估算和管理工作成本和持续时间

滚动式规划

• Rolling Wave Planning
• 一种迭代式的规划技术
• 对于远期才完成的可交付成果或组件，当前可能无法分解
• 项目管理团队通常需要等待对该可交付成果或组件的一致意见，以便能够制定出WBS的相应细节
• 规划包（planning package）体现了滚动式规划与渐进明细的精神
• 规划包是一种低于控制帐户而高于工作包的WBS组件，工作内容已知，但详细的进度活动未知

100%原则

• 指导WBS编制、分解和评价的最重要原则之一
• 是WBS的核心特点
• 说明WBS 包括项目范围所定义的全部产品和项目工作以及项目管理工作
• 通过把WBS底层的所有工作逐层向上汇总， 确保既没有遗漏的工作，也没有多余的工作
  • 适用于WBS的所有层次：“子”层次上的工作 总和应100％ 地完全等于“母”层次上的工作
  • 也适用于活动层次，在每个工作包中，由活动表示的工作总和应100％等于完成此工作包所 需要的所有工作

创建WBS-输出

范围基准

范围基准

• Scope Baseline 
• 范围基准是经过批准的范围说明书、WBS和WBS词典
• 只有通过正式的变更控制程序才能进行变更
• 被用做绩效比较的基础

WBS词典

• WBS Dictionary
• 针对WBS中的每个组件， 详细描述可交付成果、 活动和进度等信息的文件
• WBS词典对WBS提供支持， 其中大部分信息由其他过程创建，然后在后期添加到词典中
• WBS词典的内容可能包括： 账户编码标识，工作描述， 假设条件和制约因素， 负责的组织， 进度里程碑， 相关的进度活动， 所需资源， 成本估算， 质量要求， 验收标准， 技术参考文献， 协议信息；