项目范围管理
项目范围管理
核心概念
项目范围管理包括做且只做所需的全部工作。
产品范围：某项产品、服务或成果所具有的特性和功能，决定项目范围（产品需求文件）。
项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作，服务于产品范围（项目管理计划）。
发展趋势和新兴实践
商业分析活动可在项目启动和项目经理任命之前就开始。
需求管理过程始于需要评估，结束于需求关闭。
需求：需求是一种需要。
范围：范围是满足“需求”必须交付的可交付成果和相关工作。
规划范围管理（规划过程组之一）
规划范围管理—-为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
- 作用： 在整个项目中对如何管理范围提供指南和方向。
输出①：范围管理计划
范围管理计划 —- 描述将如何定义、制定、监督、控制和确认项目范围。
注意：
范围管理计划无范围（范围在范围基准中）。
范围管理计划可以是正式或非正式的，非常详细或高度概括的。
输出②：需求管理计划
需求管理计划（商业分析计划）—-描述将如何分析、记录和管理项目和产品需求。
注意：
需求管理计划无需求（需求在需求文件中）。
内容包括配置管理活动、需求优先级排序过程、测量指标等。
收集需求（规划过程组之一）
需求—-根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。
收集需求—-为实现目标而确定、记录并管理相关方的需要和需求的过程。
- 作用： 为定义产品范围和项目范围奠定基础。
关键输入①：项目文件
- 相关方登记册—-用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。
关键输入②：商业文件
- 会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。
关键输入③：协议
- 协议包含项目和产品需求
工具与技术
数据收集
头脑风暴：大量创意、各种想法、畅所欲言
访谈：直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
焦点小组：同职能、同一领域、有相似背景、主题专家（SME）、主持人引导互动式讨论
问卷调查：受众多样化、需快速完成、地理位置分散、适合开展统计分析
标杆对照：标杆可以是内部或外部、同行业或不同行业、识别最佳实践、形成改进意见
数据分析
- 文件分析：分析现有文件
决策
一致同意：每个人都同意、德尔菲（专家、匿名、多轮、趋同、消除偏见）
大多数同意：超过50%、一般把决策小组的人数定为奇数
相对多数同意：相对多数，通常候选项超过两个时使用
独裁型决策制定：一个人做决策
多标准决策分析：决策矩阵、多种标准、评估和排序
数据表现
亲和图：分组、分类
思维导图：整合、反映共性与差异、激发新创意、脑图
人际关系与团队技能
名义小组：促进头脑风暴、投票、优先排序、5分制、数轮
观察（工作跟随）和交谈：“工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求
引导：与主题研讨会结合使用、跨职能、不同部门、协调相关方差异
联合应用设计或开发（JAD）：软件开发行业、业务主题专家和开发团队集中
质量功能展开（QFD）：制造行业、收集客户需要（客户声音）开始、分类和排序
用户故事：需求研讨会、角色、目标、动机
系统交互图
- 拓扑图、可视化
原型法
支持渐进明细的理念。例如：故事板，能减轻返工的风险。
步骤（反复循环）：1.模型创建、2.用户体验、3.反馈收集、4.原型修改（可能需要走变更流程）
输出①：需求文件
需求文件—-描述各种单一需求将如何满足与项目相关的业务需求。
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
需求的分类：
业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
相关方需求：相关方或相关方群体的需要。
解决方案需求：为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。
过渡和就绪需求：这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
项目需求：项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
输出②：需求跟踪矩阵
需求跟踪矩阵—-把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
把每个需求与业务目标或项目目标联系起来，确保每个需求都具有商业价值
提供了在整个项目生命周期中跟踪需求的一种方法（正向跟踪和逆向跟踪）
有助于确保需求文件中 被批准的每项需求在项目结束的时候都能交付
收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实范围
需要进一步明确哪些包含在项目范围内，哪些排除在项目范围外。（定义范围）
定义范围（规划过程组之一）
定义范围—-制定项目和产品详细描述的过程。
作用： 描述产品、服务或成果的边界和验收标准。
从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书。
还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。
需要多次反复开展定义范围过程（涉及多个迭代）
输入①：项目章程
- 项目章程中包含对项目的高层级描述、产品特征和审批要求。
输入②：项目文件
- 需求文件 —- 识别了应纳入范围的需求。
工具与技术①：数据分析
- 备选方案分析
工具与技术②：决策
- 多标准决策分析
工具与技术③：人际关系与团队技能
- 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
工具与技术④：产品分析
- 产品分析—-把高层级的产品描述转变为有形的可交付成果。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等。
输出①：项目范围说明书
项目范围说明书—-是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。
项目范围说明书详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识。
项目范围说明书可明确指出哪些工作不属于本项目范围。
包含内容：
产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
可交付成果：必须产出的任何独特并可核实的产品、成果或服务能力。也包括辅助成果，如项目管理报告和文件
验收标准：可交付成果通过验收前必须满足的一系列条件
除外责任：明确说明哪些内容不属于项目范围， 有助于管理相关方的期望及减少范围蔓延
创建WBS（规划过程组之一）
创建WBS—-把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
作用： 对所要交付的内容提供架构
WBS （工作分解结构）组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）
WBS最低层的组成部分称为工作包，其中包括计划的工作
“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身
工具与技术①：创建WBS
分解—-把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包—-WBS 最低层的组件，可对其成本和持续时间进行估算和管理。
创建WBS，就是要将整个项目工作分解为工作包：
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配标识编码；
核实可交付成果分解的程度是否恰当
WBS的结构可以采用如下形式：
把项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。
把主要可交付成果作为分解的第二层。
纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）
注意：
不同的可交付成果可以分解到不同的层次。
并不是分解得越细越好。过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。
远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划。
原则：
无遗漏无多余（100%原则）
工作包80小时（80小时原则）
不宜过细分解（4~6层原则）
有明确责任人（责任明确原则）
输出①：范围基准
可交付成果和验收标准来源：首选范围说明书，次选wbs词典，再次选范围基准。
控制账户与工作包
控制账户（CA）—-是一个管理控制点（可以与组织的财务程序链接），在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
绩效测量基准（PMB）—-由范围基准、进度基准、成本基准共同构成
每个控制账户可能包括一个或多个工作包（或规划包），但是一个工作包只能属于一个控制账户。
确认范围（外部检查）（监控过程组之一）
确认范围—-“客户”或“发起人”正式验收已完成的项目可交付成果的过程。
- 作用：通过验收每个可交付成果，提高最终产品、服务或成果验收的可能性。
输入①：核实的可交付成果
- 核实的可交付成果—-已经完成，并被控制质量过程检查为正确的可交付成果。
工具与技术①：检查
- 检查（审查、产品审查、巡检）—-开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
输入①：验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。
输出②：变更请求
如果未通过验收，处理步骤：
记录（了解）原因；
走变更流程，进行缺陷补救。
控制范围（监控过程组之一）
控制范围—-监督项目和产品的范围状态，管理范围基准变更的过程。
作用：
在整个项目期间保持对范围基准的维护。
确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。
工具与技术①：数据分析
偏差分析—-用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采
趋势分析—-旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工
作。
范围蔓延、镀金、范围潜变
范围蔓延—-未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
来自团队内部原因造成的范围蔓延称为“镀金”
来自团队外部原因造成的范围蔓延称为“范围潜变”
镀金—-项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。
范围潜变—-范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。
如果已经出现了范围蔓延，需要补变更流程。如果变更没有获得批准，需要取消不良变更。
