做且只做,防止范围蔓延,反对镀金!
5.1 规划范围管理 (规划过程组)
5.2 收集需求(规划过程组)
5.3 定义范围
5.4 创建WBS
5.5 确认范围(验收)
5.6 控制范围
范围管理包括:
•产品范围(椅背,椅座...)
项目将得到产品所具有的特性与功能
•项目范围(锯木头,刷漆...)
为得到产品,必须完成的项目工作
❗️项目范围包含产品范围(即项目范围服务于产品范围)
5.1 规划范围管理 (规划过程组)
对如何管理范围提供指南和方向
指导如何进行5.2~5.6
•定义
创建范围管理计划,书面描述将如何定义、确认、控制项目范围
•作用
在整个项目中如何管理范围提供指南和方向
•输入
1.项目章程⭐️
包含高层级需求、高层级项目描述、边界和主要可交付成果
2.项目管理计划
•质量管理计划
•项目生命周期描述
•开发方法
3.事业环境因素
4.组织过程资产
•工具与技术
1.专家判断
请教专家类似项目、专业领域的信息
2.数据分析
备选方案分析:比较两种方案的优劣
3.会议
通过会议讨论并制定范围管理计划
•输出
1.范围管理计划⭐️
如何管理范围
•内容包括
如何制定项目范围说明书、实施整体变更控制
如何创建WBS
如何审批和维护范围基准
如何验收已完成的可交付成果
•格式
正式或非正式、非常详细或高度概括
2.需求管理计划⭐️
如何管理需求
•定义
是项目管理计划的组成部分;描述将如何记录、分析和管理需求
•规划
(1)需求管理:如何规划、跟踪和报告需求
(2)配置管理(如何启动变更、如何分析其影响..)
(3)排序需求优先级
(4)测量指标及使用这些指标的理由
(5)定义需求跟踪矩阵
•格式
正式或非正式、非常详细或高度概括
5.2 收集需求(规划过程组)
•定义
为实现项目目标而确定、记录并管理相关方的需要和需求的过程
•作用
为定义和管理项目范围奠定基础
- 需求决定范围
- 需求应当是量化的、并可被测量的
- 多关注说不清的需求、少关注合同
- 为实现项目目标(确定,记录,管理)相关方需求
- 相关方深入参与需求的探索和分析能直接促进新项目成功
•输入
1.项目章程⭐️
包含高层级需求
2.项目管理计划
范围/需求/相关方 管理计划
3.项目文件
•假设日志
•经验教训登记册
•相关方登记册
4.商业文件(商业论证)⭐️
包含了项目的背景和启动原因
Ex:市场需求、组织需要、客户要求...
5.协议⭐️
包含项目和产品的明确需求
6.事业环境因素
7.组织过程资产
•工具与技术
1.专家判断
2.数据收集
•头脑风暴:短时间内收集大量创意
•访谈:一对一、直接
•焦点小组:主持人、深入定向了解(收集同一领域的相关方需求)
•问卷调查:受众多样化、需快速完成、地理位置分散、并且适合开展统计分析
•标杆对照:最佳实践
3.数据分析
•文件分析:分析文件(协议、商业计划、问题日志...)
4.决策
•投票
一致同意:100%
大多数同意:超过50%
相对多数同意
•独裁
•多标准决策:对众多创意进行评估和排序
5.数据表现
•亲和图:对大量创意进行分组(分类)
•思维导图:层级关系、分散思维
6.人际关系与团队技能
•名义小组:通过投票排列最有用的创意(主持人记录每个人的想法)
•观察与交谈:挖掘隐藏需求
Ex:工作跟随、参与观察
•引导:跨职能、协调相关方的需求差异
(1)联合应用设计或开发(JAD)
业务专家和技术专家一起讨论需求,改进软件开发过程
(2)质量功能展开(QFD)
•收集客户声音
•对客户需要进行分类和排序
•为实现客户需要设定目标
Ex:质量屋
(3)用户故事
需求-需求相关方-期望获得的效果-需要实现的目标
故事的要素:谁、(目标)需要的是什么、(动机)为什么
7.系统交互图
对产品范围的可视化描绘、显示业务系统与其他系统之间的交互方式
Ex:淘宝用户-淘宝-商家-支付宝
8.原型法
制作有型的实物或模型,不再抽象讨论
渐进明细(通过新原型对旧原型的迭代,不断明确客户需求)
Ex:故事版
•输出
1.需求文件⭐️
❗️罗列
单一需求如何满足项目与项目相关的业务需求
•需求的类别:
- 业务需求
- 相关方需求
- 解决方案需求:可交付成果必须具备的特性、功能和特征
·功能需求:产品应具备的功能
·非功能需求:性能、保密性、安全性...
- 过度和就绪需求:数据转换、培训需求
- 项目需求:项目里程碑、合同工期...
- 质量需求:应用在化工园区的产品,必须通过防爆认证
2.需求跟踪矩阵⭐️
❗️跟踪
(产品需求)什么样的需求、(需求源)谁提出的、为什么收录该需求、优先级如何、(可交付成果)通过可交付成果的哪些特性来响应需求、需求当前状态如何等
了解项目的所有需求、以及相应的变更执行情况
5.3 定义范围(规划过程组)
制定项目和产品的详细描述
•作用
描述产品、服务或成果的边界和验收标准
•输入
1.项目章程
2.项目管理计划
3.项目文件
•假设日志
•需求文件
•风险登记册
4. 事业环境因素
5.组织过程资产
过往项目的经验教训
•工具与技术
1.专家判断
2.数据分析
•备选方案分析
3.决策
4.人际关系与技能
•引导
5.产品分析
把高层级的产品或服务描述转变为有意义的可交付成果
产品分析技术包括:
•产品分解
•需求分析
•系统分析
•系统工程
•价值分析
•价值工程
•输出
1.项目范围说明书⭐️
内容包括:
•产品范围描述
•项目可交付成果:新来的pm想了解可交付成果,可查看…
•验收标准
•项目除外责任
2.项目文件更新
•假设日志
•需求文件
•需求跟踪矩阵
•相关方登记册
5.4 创建WBS(规划过程组)
将可交付成果分解为较小的、更易于管理的组件的过程
•作用
对所要交付的内容提供架构
工作分解结构中的工作是指:
为活动结果的工作产品或可交付成果,而不是活动本身
•输入
1.项目管理计划
•范围管理计划:定义了如何创建WBS
2.项目文件
•项目范围说明书:描述了需要实施的工作及不包含在项目中的工作
•需求文件:详细的描述了各种单一的需求如何满足项目的业务需求
3.事业环境因素
项目所在行业的WBS标准…
4.组织过程资产
•政策、程序和模版
•以往项目的项目档案
•以往项目的经验教训
•工具与技术
1.专家判断
2.分解
整个项目工作分解为工作包:
•识别和分析可交付成果和编排方法
•确定WBS的结构和编排方法
•自上而下逐层细化分解,提高估算的准确性
•为WBS组成部分制定和分配标识编码
•核实可交付成果分解的程度是否恰当
WBS的结构:P159
•以项目生命周期的各个阶段作为分解的第二层
•以主要可交付成果作为分解的第二层
•纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)
过细的分解:
会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低、同时造成WBS各层级的数据汇总困难
滚动式规划:未来远期才能完成的可交付成果或组件、当前可能无法分解…
100%规则:确保WBS中的要素是必要且充分的
WBS包含了全部的产品和项目工作,包括项目管理工作(组织并定义了项目的总范围)
•输出
1.范围基准⭐️⭐️⭐️
•项目范围说明书
•WBS
•工作包:WBS的最低层级是带有独特标识号的工作包,
❗️每个工作包都是控制账户的一部分,而控制账户则是一个管理控制点
❗️控制账户:把范围、预算、进度加以整合,并与挣值相比较,以测量绩效(进行挣值管理)
•规划包:工作内容已知,但详细的进度活动未知
•WBS词典:用于详细描述WBS的每个组件,包括其工作内容,进度信息,成本信息…
2.项目文件更新
•假设日志
•需求文件
5.5 确认范围(监控过程组)
❗️验收
•定义
正式验收已完成的项目可交付成果的过程
•作用
使验收过程具有客观性;
验收每个可交付成果,提高最终产品、服务或成果获得验收的可能性;
通过获得客户对每个可交付成果的及时验收,保证项目不偏离轨道
•输入
1.项目管理计划
•范围管理计划:定义了如何验收
•需求管理计划:定义了如何验证需求是否满足
•范围基准:将可交付成果和基准做比较
2.项目文件
•经验教训登记册
•质量报告:内容包括由团队管理或需上报的全部质量保证事项、改进建议、以及在控制质量过程中发现的情况的概述。在验收产品之前,需要查看所有这些内容
•需求文件:将需求与实际结果做比较,…
•需求跟踪矩阵
3.核实的可交付成果
是8.3控制质量的输出
4.工作绩效数据
包含符合需求的程度,不一致的数量等信息
•工具与技术
1.检查
开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和(项目范围说明书中)产品验收标准
其他名称
审查review
产品审查product review
审计audit
巡检walkthrough
2.决策
投票:项目团队和其他相关方进行验收时通过投票来形成结论
•输出
1. 验收可交付成果
符合验收标准的可交付成果,应该由客户或发起人正式签字批准,同意验收
将作为4.7结束项目或阶段过程的输入
2.工作绩效信息
包括:
•项目进展信息,
•验收了多少
•未通过的验收有多少
•验收通过率是多少
•哪些可交付成果未通过验收及原因
•如何处理未符合验收的可交付成果
记录这些内容后传递给相关方
3.变更请求
记录未通过验收可交付成果及原因;
提出变更请求进行缺陷补救;
由实施整体变更控制流程进行审查与处理;
4.项目文件更新
•经验教训登记册:记录所遇到的挑战、本应如何避免该挑战挑战,以及良好的可交付成果验收方法;
•需求文件:记录实际的验收结果,更新需求文件。需要注意实际结果比原定需求更好的情况,或者原定需求已经被放弃的情况;
•需求跟踪矩阵:根据验收结果更新,包括所采用的验收方法及其使用结果;
❗️确认范围和控制质量的区别:
确认范围是验收,是让用户确认,这个可交付成果是不是他想要的;
控制质量是合规,确认可交付成果是否符合规格,质量是否过关;
控制质量在前,确认范围在后;
5.6 控制范围(监控过程组)
持续对范围进行监督,管理范围变更,在整个项目期间开展
•定义
监督项目或产品的范围状态、管理范围基准变更的过程
•作用
在整个项目期间保持对范围基准的维护
•范围蔓延:未经控制的产品或项目范围的扩大
•输入
1.项目管理计划
怎么控制:
和什么去比较:
组件包括:
•范围管理计划
•需求管理计划
•变更管理计划
•配置管理计划
•范围基准
•绩效测量基准
2.项目文件
•经验教训登记册
•需求文件
•需求跟踪矩阵:用于确认范围和控制范围过程,来跟踪需求的实现情况
3.工作绩效数据
已审核/未审核的可交付成果数量
收到的/批准的范围变更请求数量
4.组织过程资产
•工具与技术
1.数据分析
偏差分析:将实际值和基准值做比较,检查偏差是否在合理范围之内
趋势分析:预测未来,判断情况会改善还是恶化
将实际绩效与计划绩效进行分析,并做出决策
•纠偏措施
•预防措施
•调整计划
•输出
1.工作绩效信息
将工作绩效数据通过数据分析(偏差分析、趋势分析)得出的结果
例如多做了多少工作,少做了多少工作
2.变更请求
变更范围基准、进度基准或项目管理计划中的其他组件
3.项目管理计划更新
•范围管理计划
•范围基准:在针对范围、范围说明书、WBS或WBS词典的变更获得批准后,需要对范围基准做出相应的变更
•进度基准
•成本基准
•绩效测量基准
4.项目文件更新
•经验教训登记册
•需求文件
•需求跟踪矩阵