核心概念及要素
- 用户需求（用户看得见的需求）
- 项目需求（用户看不见但是必须的需求）
- 产品规格（产品范围）
- 项目范围说明书
- 力求避免发生未计划的工作，主要需要避免镀金和范围蔓延
- 镀金：以讨好相关方为目的，项目团队未经控制主动完成额外工作
- 范围蔓延：在客户或发起方的要求下，团队未经控制地完成额外工作
- 额外工作：无法纳入绩效
项目范围管理包括
- 5.1 规划范围管理：为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程，可以理解为定义管理方法论
- 5.2 收集需求：为实现项目目标而确定、记录并管理相关方的需要和需求的过程
- 5.3 定义范围：制定项目和产品详细描述的过程（框架级的需求）
- 5.4 创建WBS：将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程（可用于实施的详细需求）
- 5.5 确认范围：正式验收已完成的项目可交付成果的过程
- 5.6 控制范围：监督项目和产品的范围状态，管理范围基准变更的过程
子过程分解
5.1 规划范围管理
定义
- 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程，可以理解为定义管理方法论，简而言之就是立规矩
理解
- 同时关注项目范围和产品范围
- 从需求到范围
- 确定方法论，注意与项目集的一致性
作用
- 在整个项目期间对如何管理范围提供指南和方向
- 明确需求及范围的收集、定义、确认、调整所需的文档、模板、表格、行为方式等内容
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 瀑布型仅开始项目及变更时开展
- 有迭代时每迭代开始时展开
参与方
- 项目经理主导
- 项目管理团队及主题专家贡献意见
输入、工具与技术和输出
5.2 收集需求
定义
- 为实现项目目标而确定、记录并管理相关方的需要和需求的过程
理解
- 区分：需要和需求
- 需要：相关方对希望达成目标的表述
- 需求：相关方实际需要解决的痛点
什么是需求
- 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力
- 它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望
- 应该足够详细的探明、分析和记录这些需求，将其包含在范围基准中，并在项目开始后对其进行测量
- 需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础
作用
- 为定义产品范围和项目范围奠定基础
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 瀑布型仅立项及变更时开展
- 有迭代时每迭代开始时开展
参与方
- 项目经理主导，但可能不会参与到每个具体的调研工作中
- 项目管理团队，或者如果存在预分配的一线团队成员，开展实质性工作
- 面向所有相关方进行收集
输入、工具与技术和输出
5.3 定义范围
定义
- 制定项目和产品详细描述的过程（框架级的需求）
理解
- 从需求分析出需要完成的工作
- 包括产品的定义、描述，以及为了完成产品所需的管理文件、技术文件以及相关的管理工作
- 收集需求过程中识别出的所有需求未必都包含在项目中
作用
- 描述产品、服务或成功的边界和验收标准
发生时机
- 按需开展，渐进明细
- 在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围
参与方
- 项目经理领导完成范围说明书的编制，并征得相关方认可
- 项目团队、主题专家在定义范围中贡献力量
输入、工具与技术和输出
5.4 创建WBS
定义
- 把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程
理解
- 根据项目规模对比和团队能力，将全部范围拆解成易于管理预算、进度的工作包
- WBS是对项目工作的组织，形成的WBS代表团队对项目工作组织形式的共识
- WBS词典是对WBS条目所需代表的工作的展开描述
什么是WBS？
- WBS是对项目团队为实现项目目标、创建可交付成功而需要实施的全部工作范围的层级分解
- WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作
- WBS最底层的元素被称为工作包（work package），可以对工作包：规划进度、估算成本、监督和控制
- 在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身
作用
- 为所要交付的内容提供架构
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 预测型生命周期随范围定义完成展开
- 迭代型每次迭代开始前完成
参与方
- 项目经理领导本项目工作的开展
- 项目团队负责完成WBS条目的拆解和说明
- 相关方承诺对工作结果的支持
输入、工具与技术和输出
5.5 确认范围
定义
- 正式验收已完成的项目可交付成果的过程
理解
- 明确需要验收方（客户/发起方）参与
- 是对项目工作、可交付成功的正式验收检查
- 相当于验收测试
作用
- 使验收过程具有客观性，同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性
发生时机
- 应根据需要在整个项目期间定期开展
- 就算是瀑布生命周期也要完成阶段验收
- 迭代中每个迭代末固定需要完成
- 迭代中可能随机对工作进行阶段验收
参与方
- 项目经理、发起人、客户
- 验收流程要求的其他相关方
输入、工具与技术和输出
5.6 控制范围
定义
- 监督项目和产品的范围状态，管理范围基准变更的过程
理解
- 由于范围涉及其他约束的调整，因此范围调整时，参考文件顺序是范围管理计划先于变更管理计划
作用
- 在整个项目期间保持对范围基准的维护
- 所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程（4.6章）进行处理
- 在变更实际发生时，也要采用控制范围过程来管理这些变更
发生时机
- 在整个项目期间开展
- 只要开展项目工作，就有可能收到范围的调整，因此随时可能开展控制范围工作
参与方
- 项目经理主导，项目管理团队协助分析和判断
- 当遇到需要发起变更时，还需提出变更的相关方参与
输入、工具与技术和输出
需要项目管理资料合集的同学可先关注然后私信我哦
更多精彩内容请关注了解
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。