主题
项目范围管理
管理基础
- 产品范围和项目范围
- 产品范围：
- 项目范围：
- 管理新实践 需求一直是项目管理的关注重点，需求管理过程结束于需求关闭。项目范围管理的新趋势和新兴实践更加注重与商业分析师一起合作，以便： 确定问题并识别商业需要；识别并推荐能够满足需要的可行解决方案；收集、记录并管理干系人需求满足商业和项目目标；推动项目集或项目产品、服务或 最终成果成功应用。
裁剪考虑因素
- 知识和需求管理
- 确认和控制
- 开发方法
- 需求的稳定性
- 治理
- 敏捷与适应方法
敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义。 采用敏捷或适应型版生命周期，旨在应对大量变更，需要干系人持续参与项目。在每次迭代中，都会重复开展三个过程：1.收集需求；2.定义范围；3.创建WBS。
在预测型项目中，经过批准的项目范围说明书、工作分解结构 (WBS) 和相应的 WBS 词 典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。 在开展确认范围、控 制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未 完成项(包括产品需求和用户故事)反映当前需求。
确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可 交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授 权的千系人正式签字批准。因此，干系人需要在规划阶段早期介入(有时需要在启动阶段就介 入)，对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。
1. 规划范围管理
TIP
规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。
输入
项目章程
-
项目管理计划
-
事业环境因素
-
组织过程资产
-
工具与技术
专家判断
-
数据分析
备选方案分析技术用千评估、收集需求，详述项目和产品范围，创造产品，确认范围和控制范围的各种方法。
会议
-
输出
范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。 范围管理计划指导如下过程和相关工作：
- 制定项目范围说明书
- 根据详细项目范围说明书创建WBS
- 确定如何审批和维护范围基准
- 正式验收已完成的项目科交付成果
根据项目需要，范围管理计划可以是正式或非正式的，非常详细的或高度概括的。
需求管理计划
需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。 需求管理计划的主要内容包括：
- 如何规划、跟踪和报告各种需求活动
- 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
- 需求优先级排序过程
- 测量指标及使用这些指标的理由
- 反映哪些需求属性将被列入跟踪矩阵等
2. 收集需求
TIP
收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程。
本过程的主要作用是为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。
需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他 干系人的已量化且书面记录的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目 执行开始后对其进行测量。需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质量和采购规划的基础。
输入
立项管理文件
-
项目章程
-
项目管理计划
-
项目文件
- 假设日志：
- 干系人登记册：
- 经验教训登记册
协议
-
事业环境因素
-
组织过程资产
-
工具与技术
专家判断
数据收集
- 头脑风暴：是一种用来产生和收集对项目需求与产品需求的多种创意的技术
- 访谈：是通过与干系人直接交谈，来获取信息的正式或非正式方法
- 焦点小组：
- 问卷调查：是指设计一系列书面问题。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散 并且适合开展统计分析的情况
- 标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见， 并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
数据分析
可供分析并有助于获取需求的文件包括： 协议、商业计划、业务流程或接口文档、业务规则库、现行流程、市场文献、问题日志、政策和程序、 法规文件，如法律/准则/法令等、建议邀请书、用例
决策
- 投票：是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过程。本技术用于生成、归类和排序产品需求。
- 独裁型决策制定：用这种方法，将由一个人负责为整个集体制定决策。
- 多标准决策分析：技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
数据表现
- 亲和图：
- 四维导图：
人际关系与团队技能
- 名义小组技术：
- 观察和交谈：
- 引导：
系统交互图
系统交互图是对产品范围的可视化描绘，可以直观显示业务系统
原型法
原型法是指在实际制造预期产品之前，先造出该产品的模型。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。
故事版是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学 设计以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
输出
需求文件
需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。 只有明确的(可测量和可测试的)、可跟踪的、 完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是干系人的需要，后者是指如何实现这些干系人需要的方案。 需求的类别一般包括：
- 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因
- 干系人需求：干系人的需要
- 解决方案需求：
- 过渡和就绪需求：
- 项目需求：
- 质量需求：
需求跟踪矩阵
需求跟踪矩阵是把产品需求从其来源连接到满足需求的可交付成果的一种表格。
需求跟踪矩阵还为管理产品范围变更提供了框架。跟踪需求的内容包括：
- 业务需要、机会、目的和目标
- 项目目标
- 项目范围和WBS可交付成果
- 产品设计
- 产品开发
- 测试策略和测试场景
- 高层级需求到详细需求等
3. 定义范围
TIP
定义范围是制定 项目和产品详细描述的过程。 本过程的主要作用是描述产品、服务或成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文 件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。 准备好详细项目范围说明书，对项目成功至关重要。
输入
项目章程
-
项目管理计划
-
项目文件
- 假设日志：
- 需求文件：
- 风险登记册：
事业环境因素
-
组织过程资产
-
工具与技术
专家判断
-
数据分析
可用于定义范围过程的数据分析技术是备选方案分析。
决策
可用于定义范围过程的决策技术是多标准决策分析。
人际关系与团队技能
人际关系与团队技能的一个典型示例是引导。在研讨会和座谈会中使用引导技能来协调具 有不同期望或不同专业知识的关键千系人，使他们就项目可交付成果以及项目和产品边界达成 跨职能的共识。
产品分析
产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。
产品分析技术主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。
输出
项目范围说明书
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括：项目和产品 范围；详细描述了项目的可交付成果；代表项目干系人之间就项目范围所达成的共识。
为便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。 详细的项目范围说明书包括内容有：
- 产品范围描述
- 可交付成果：
- 验收标准：
- 项目的除外责任：
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。 项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部 分需要在项目过程中渐进明细。
项目文件（更新）
-
4. 创建WBS
TIP
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
本过程的主要作用是为所要交付的内容提供架构。它仅开展一次或仅在项目的预定义点开展。
WBS是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了 项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS最低层的组成部分称为工作包，其中包括计划的工作。”工作“是指作为活动结果的工作产品或可交付成果，而不是活动本身。
输入
项目管理计划
-
项目文件
-
事业环境因素
-
组织过程资产
-
工具与技术
专家判断
-
分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。 工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。
工作包的详细程度则因项目规模和复杂程度而异。
- 分解活动 要把整个项目工作分解为工作包，通常需要开展如下活动：
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法
- 自上而下逐层细化分解
- 为WBS组成部分制定和分配标识编码
- 核实可交付成果分解的程度是否恰当
- WBS结构 WBS的结构可以采用多种形式
- 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
- 以主要可交付成果作为分解的第二层
- 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后，作为外包 工作的一部分，卖方须制定相应的合同 WBS
如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。
要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需 要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术 又称为滚动式规划。
- 注意事项 在分解的过程中，应该注意以下8个方面
- WBS必须是面向可交付成果的
- WBS必须符合项目的范围
- WBS的底层应该支持计划和控制
- WBS中的元素必须有人负责
- WBS应控制在4~6层
- WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作
- WBS的编制需要所有(主要)项目干系人的参与
- WBS并非是一成不变的
输出
范围基准
范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作 比较的基础。范围基准是项目管理计划的组成部分。
- 项目范围说明书：项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述
- WBS：WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构 每向下分解一层，代表对项目工作更详细的定义。
- 工作包：WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。 每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。控制账户包含两个或更多工作包，每个工作包只与 一个控制账户关联。
- 规划包：规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制 账户可以包含一个或多个规划包
- WBS字典：是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS字典中的内容一般包括：账户编码标识、工作描述、假设条 件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
项目文件（更新）
-
5. 确认范围
TIP
确认范围是正式验收已完成的项目可交付成果的过程。
本过程的主要作用：1.使验收过程具有客观性；2.通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
确认范围过程应根据需要在整个项目期间定期开展。
一、确认范围的步骤
确认范围应该贯穿项目的始终。如果是在项目的各个阶段对项目的范围进行确认工作，则还要考虑如何通过项目协调来降低项目范围改变的频率， 以保证项目范围的改变是有效率和适时的。确认范围一般步骤包括：
- 确定需要进行范围确认的时间
- 识别范围确认需要哪些投入
- 确定范围正式被接受的标准和要素
- 确定范围确认会议的组织步骤
- 组织范围确认会议
通常情况下，在确认范围前，项目团队需要先进行质量控制工作，例如，在确认软件项目的范围之前，需要进行系统测试等工作， 以确保工作的顺利完成。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量 要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
二、需要检查的问题
项目干系人进行范围确认时，一般需要检查以下6个方面的问题：
- 可交付成果是否是确定的、可确认的
- 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如。客户的书面认可等
- 是否有明确的质量标准：可交付成果的交付不但要有明确的标准版标志，而且要有是否按照要求完成的标准，可交付成果 和其标准之间是否有明确联系
- 审核和承诺是否有清晰的表达：项目发起人必须正式同意项目的边界，项目完成的产品或服务，以及项目相关的可交付成果。 项目团队必须清楚地了解可交付成果是什么。
- 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误
- 项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响
三、干系人关注点的不同 每个人对项目范围所关注的方面是不同的：
- 管理层主要关注项目范围
- 客户主要关注产品范围
- 项目管理人员主要关注项目制约因素
- 项目团队成员主要关注项目范围中自己参与的元素和负责的元素
输入
项目管理计划
-
项目文件
- 需求文件
- 需求跟踪矩阵
- 质量报告
- 经验教训登记册
工作绩效数据
工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内 开展确认的次数。
核实的可交付成果
核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
工具与技术
检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
决策
可用千确认范围过程的决策技术是投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论
输出
验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付 成果的正式验收。这些文件将提交给结束项目或阶段过程。
变更请求
-
工作绩效信息
-
项目文件（更新）
-
6. 控制范围
TIP
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
本过程的主要作用是在整个项目期间保持对范围基准的维护。需要在整个项目期间开展。
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。
输入
项目管理计划
-
项目文件
-
工作绩效数据
工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数最或者核实、确认和 完成的可交付成果的数量。
组织过程资产
-
工具与技术
数据分析
- 偏差分析：
- 趋势分析：
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
输出
工作绩效信息
-
变更请求
-
项目管理计划（更新）
项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。 可能需要变更请求的项目管理计划组成部分包括：
- 范围管理计划：
- 范围基准：有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据。
- 进度基准：有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效初量提供现实可行的依据。
- 成本基准：有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
- 绩效测量标准：有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。
项目文件（更新）
可在控制范围过程更新的项目文件主要包括：
- 需求文件：可以通过增加或修改需求而更新需求文件
- 需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵
- 经验教训登记册：更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。