项目范围管理
2019-02-15 16:20:22 3 举报AI智能生成
登录查看完整内容
PMBOK 第六版 项目进度管理
作者其他创作
大纲/内容
项目范围管理
规划范围管理
过程定义
描述如何定义，确认和控制范围的过程
过程作用
对如何管理范围提高指南和方向
输入
项目章程
项目管理计划
质量管理计划
项目生命周期描述
开发方法
事业环境因素
组织过程资产
工具与技术
专家判断
数据分析
分选方案分析
会议
输出
范围管理计划
描述如何定义，制定，监督，控制和确认项目范围
规定
如何制定项目范围说明书
如何根据详项目范围说明书创建WBS
如何确定如何审批和维护范围基准
如何正式验收已完成的项目可交付成果
如何处理对详细项目范围说明书的变更
可以是正式或非正式
可是是详细或概括
需求管理计划
描述如何分析，记录和管理项目和产品需求
主要内容
如何规划，跟踪和报告各种需求活动
配置管理活动
需求优先级排序过程
测量指标及使用这些指标的理由
反映哪些需求属性将被列入需求跟踪矩阵
收集需求
确定，记录并管理干系人的需要和需求的过程
为定义产品范围和项目范围奠定基础
包括发起人，客户和其他干系人的已量化且书面记录的需要和期望
让干系人积极参与，能促进项目成功
项目管理子计划
干系人参与计划
项目文件
假设日志
经验教训登记册
干系人登记册
商业文件
商业论证
协议
数据收集
头脑风暴
访谈
焦点小组
问卷调查
适用场景
受众多
需要快速完成
受访者地理位置分散
适合使用统计分析
标杆对照
将产品，过程和实践，与其他可比组织的实践进行比较
识别最佳实践
形成改进意见
为绩效考核提供依据
标杆对象
组织内或组织外部的项目
同意应用领域内的项目
不同应用领域内的项目
文件分析
分析现有文档
识别与需求相关的信息
挖掘需求
可分析文件
商业计划
业务流程和接口文档等
决策
投票
一致同意
100%同意，德尔菲技术
专家
匿名或背靠背，互相不知道
多轮次
旨在取的一致意见
大多数同意
超过50%的同意
相对大多数同意
候选项超过两个时使用
独裁型决策
一个人说了算
多标准决策分析
借助决策矩阵
数据表现
亲和图
对大量创意进行分组，归纳，以便进一步审批和分析
思维导图
用于激发新创意
人家关系与团队技能
名义小组技术
给头脑风暴产生的想法进行排序
观察/交谈
查看个人如何在环境中执行工和实施流程
阵针产品使用者对难以或不愿说清具体的需求
方法
工作跟随
外部观察业务专家如何执行工作
参与观察者
亲自体验流程或程序
引导
召集主要干系人一起定义产品需求
示例
联合应用设计/开发
软件行业应用
把客户和开发团队集中在一起，以收集需求和改进软件开发过程
适用于需求复杂且跨部门的软件项目
由于客户参与，大大加快开发速度，提高客户满意度
质量功能展开
制造应用使用
用户故事
敏捷方法中的使用
对需求的简短描述
角色
谁将受益
目标
需要什么
动机
将获得什么样的收益
系统交互图
对产品范围的可视化描述，显示业务系统和人及其他系统的交互方式
显示
业务系统的输入
输入者
业务系统的输出
输出的接受者
原型法
先弄出个模型，给客户看，看有什么要改进的
需求文件
描述单一需求将如何满足与项目相关的业务需求
一开始可能只有高层级，后来渐进明细
需求的分类
业务需求
整体组织的高层及需求
干系人需求
个人或整体的需要
解决方案需求
功能性需求
产品应具备的功能
非功能性需求
确保产品运行所需环境或质量要求，如可靠性，安全性，保密性
过渡和就绪要求
从当前状态到未来状态的转换能力
数据转换
培训
项目需求
质量需求
测试
认证
需求跟踪矩阵
提供整个项目生命周期跟踪需求
定义范围
制定项目和产品详细描述的过程
明确哪些需求是项目内的，哪些是不在项目范围内的，明确边界
需要多次反复开展
需求排序
必须有
基本需求
应该有
重要需求
可以有
锦上添花需求
不会有
确定什么在和什么不在范围内
风险登记册
备选方案分析
人际关系与团队技能
产品分析
定义产品和服务，描述产品用途，特征和其他方面
首先取得高层及需求，然后细化
分析技术
产品分解
以树状结构分解产品
需求分析
系统分析
系统工程
如何在整个项目过程中涉及和管理
价值工程
对项目的范围和成本进行分析
在项目活动前进行
价值分析
在项目活动后
项目范围说明书
描述项目范围，主要可交付成果，假设条件和制约因素
记录了项目和产品范围
描述为实现可交付成果需要做的工作内容
该说明书的建立代表项目干系人之间就项目范围达成共识
项目文件更新
创建WBS
分解项目工作成较小的，更易于理解的组成部分的过程
对所要交付的内容提供框架
创建方法
自上而下方法
使用组织特定的指南
使用WBS模板
自下而上方法
表现形式
提纲式
组织结构式
能说明层级结构的其他形式
WBS结构形式
生命周期为各阶段为分解第二层
已主要可交付成果作为分解第二层
分解
分解项目范围和成果为更小，更便于管理的技术
分解步骤
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配标识编码
核实成果分解是否恰当
工作包
WBS最底层组件，逻辑上不能再分下去
有一个可交付的结果和有标志性的结束
能够可靠估算和管理工作成本和持续时间
遵循80小时原则（清晖上课说40小时）
能够被外包出去
100%原则
自下而上汇总工作内容，确保没有遗漏
控制账户
管理控制点
一个控制账户包括两个或多个工作包，但是每个工作包只属于一个账户
控制账户可以包含一个或多个规划包
滚动式规划
一种迭代规划技术
运用与远期目标
低于控制账户，高于工作包，内容已知，详细进度活动未知
范围基准
范围说明书
WBS
WBS词典
WBS中每个组件详细描述解释，如变量的上下限
项目过程中慢慢添加
包括内容
账户编码标识
所需资源
工作描述
成本估算
质量要求
验收标准
确认范围
监督范围状态，管理变更过程
保持对范围基准的维护
变更管理计划
配置管理计划
绩效测量基准
工作绩效数据
偏差分析
针对现状
将基准与实际结果比较，确定是否出现偏差，是否有必要采取纠正或预防措施
趋势分析
针对未来
审查项目绩效趋势，以判断绩效是否在改善还是恶化
重要工作
确定偏离范围基准的原因和程度
决定是否需要采取纠正或预防措施
工作绩效信息
变更请求
项目管理计划更新
进度基准
成本基准
控制范围
正式验收已完成的项目可交付成果的过程
使验收过程客观
确认每个可交付成果
提交产品，服务或成果获得验收的可能性
与其他过程的关系
由客户或发起人来审查可交付成果，确认可交付成果已完成并通过验收
控制范围重在确保可交付成果的正确性
确认范围重在可交付成的验收
控制范围一般先于确认范围，但也可同时进行
所以可交付成果验收之后，项目进入收尾
质量报告
可核实的可交付成果
符合需求的程度
不一致的数量
不一致的严重性
在某时间段内开展确认的次数
检查
用于判断工作和可交付成果是否符合需求和验收标准
也称为审查，产品审查和巡检
验收的可交付成果
进度进展信息
哪些可交付成果已被验收
哪些可交付成果未通过验收及原因
开展缺陷补救
范围概述与核心概念
做且做所需的全部工作，以完成项目
定义和控制哪些工作包括在项目内，哪些不在项目内
项目范围包括产品范围
范围基准构成
范围区分
产品范围
特性和功能
项目范围
为交付具有特性和功能的成果等所需完成的工作
衡量依据
0 条评论
回复 删除
下一页
