项目范围管理
2021-08-02 15:49:23 0 举报AI智能生成
登录查看完整内容
范围管理，软考
作者其他创作
大纲/内容
项目范围管理
定义
项目范围
是为了达到项目目标，交付具有某种特质的产品或服务，项目所规定要做的工作
产品范围
指产品或服务应该包含的功能
关系
产品范围是项目范围的基础，项目范围是产生项目管理计划的基础
范围基准
经过批准的项目范围说明书
WBS
WBS字典
主要工作
明确项目边界
对项目执行工作进行监控
防止项目范围发生蔓延
规划范围管理
范围管理计划
如何制定项目范围说明书
如果根据范围说明书创建WBS
如何维护和批准WBS
如何确认和正式验收已完成的项目可交付成果
如何处理项目范围说明书的变更
需求管理计划
如何规划、跟踪和汇报各种需求活动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围和需求不一致的准则和纠正规程
需求跟踪结构
配置管理活动
输入
项目管理计划
项目章程
组织过程资产
事业环境因素
工具
专家判断
会议
输出
收集需求
需求的分类
业务需求
整个组织的高层级需求
干系人需求
干系人或干系人群体的需求
解决方案需求
为了满足业务需求和干系人需求，产品、服务或成果所必须具备的特性、功能和特征
过渡需求
从当前状态过渡到将来状态所需的临时能力
项目需求
项目需要满足的行动、过程或其他条件
质量需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准
干系人管理计划
干系人登记册
访谈
通过与干系人直接交谈来获取信息的正式或非正式方法，是最基本的一种方式
形式有结构化和非结构化
结构化是事先准备好一些列的问题，有针对的进行
非结构化只是提出一个粗略的想法，根据实际情况发挥
有效的访谈结合两种形式进行
焦点小组
将预先选定的干系人和主题专家集中在一起，了解他们的期望和态度
是一种群体访谈
引导式研讨会
通过邀请主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义
是快速定义跨职能需求和协调干系人差异的重要技术
有助于建立信任、促进关系、改善沟通，比单项会议更快发现问题和解决问题
群体创新技术
头脑风暴法
直接头脑风暴法
质疑头脑风暴法
名义小组技术
通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序
头脑风暴的深化应用，更结构化的头脑风暴
德尔菲技术
是一种组织专家就某一主题达成一致意见的一种信息收集技术
吸收专家参与预测，充分利于专家的经验和学识
匿名，使之独立判断
过程多次反馈，使专家意见逐渐趋同
有助于减少数据的偏倚，防止个人对结果造成不好的影响
概念/思维导图
将从头脑风暴中获得的创意，用一张图联系起来，以反映创意之间的共性和差异，进而激发新的创意
亲和图
针对某一问题，头脑风暴，通过图解方式汇总，按相互亲和性归纳整理，使问题明确
多标准决策分析
借助决策矩阵，用系统分析方法建立多种标准，从而对多方案进行评估和排序
群体决策技术
一致同意
大多数原则
相对大多数
独裁
问卷调查
设计书面问题，向大量受访者快速收集信息
观察
直接观察个人在各自环境中如何开展工作和实施流程
原型法
标杆对照
将实际或计划的做法与类似组织的做法信息比较，以便识别最佳实践
系统交互图
是范围模型的一个例子，对产品范围的可视化描述，显示系统与参与者之间的交互方式
文件分析
通过分析现有文档，识别与需求相关的信息来挖掘需求
需求文件
与需求有关的假设条件、依赖关系、制约因素
需求跟踪矩阵
定义范围
项目范围说明书
内容
产品范围描述
验收标准
可交付成果
项目的除外责任
制约因素
假设条件
作用
确定范围
沟通基础
规划和控制依据
变更基础
规划基础
产品分析
对于以产品为交付物的项目，产品分析是一种很有效的工具
备选方案生成
是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
项目文件更新
创建WBS
概念
里程碑
标志着某个可交付成果或阶段的正式完成
工作包
位于WBS最底层的可交付成果或项目工作组成部分
8-80规则
控制账户
是一种管理控制点，在该点上，将范围、预算、进度、成本等加以整合，与挣值比较，以测量绩效
规划包
是在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分
处于控制账户和工作包之间
WBS词典
和WBS配套使用，用于描述WBS各组成部分的文件
分解
是一种将项目可交付成果和项目分解成较小的、更易于管理的组件的技术
活动
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配标识编码
核实可交付成果的程度是恰当的
分解原则
功能或技术原则
组织结构
系统或者子系统
分解实践
项目生命周期为第二层，产品和项目可交付成果为第三层
主要可交付成果在第二层
整合可能由项目团队以外的组织来实施的各种组件，然后作为外包工作的一部分，卖方需要编制相应的WBS
注意事项
面向可交付成果
符合项目的范围
底层应该支持计划和控制
元素必须有人负责
WBS的指导
要包括管理工作及分包出去的工作
需要项目所有（主要）干系人参与
是可变的，可调整的
形式
树形（组织结构图示）
表格形（列表式）
鱼骨，不常用
明确和准确说明项目范围
明确人员职责
底层估算，提高估算准确性
为其他流程提供基础
将项目工作与财务账目联系起来
确定工作内容和顺序，便于安排、调节和控制
有助于防止项目范围蔓延
确认范围
是正式验收项目已完成可交付成果的过程
包括与客户或发起人一起审查可交付成果，确保已经完成，并获得正式验收
步骤
确定需要进行确认范围的时间
识别范围确认需要哪些投入
确定范围正式被接受的标准和要素
确定范围确认会议的组织步骤
组织范围确认会议
需要检查的问题
可交付成果是确定的，可确认的
可交付成果是否有明确的里程碑
是否有明确的质量标准
审核和承诺是否有清晰的表达
项目范围是否覆盖了需要完成的产品或服务进行的所有活动，是否遗漏或错误
项目范围的风险是否过高，管理层是否能降低可预见的风险发生时对项目产生的冲击
干系人关注点
管理层
关注对项目的进度、资金和资源的影响，是否超过组织承受范围，投入是否合理
客户
关注产品的范围，关系项目的可交付成果是否能够完成产品或服务
项目管理人员
关注可交付成果是否完成，资源是否足够，风险及应对策略
项目团队成员
关注自己参与的元素是否能正常完成，是否存在冲突
术语比较
确认范围--核实产品
核实产品是针对产品是否完成，在项目或阶段结束时，由发起人或客户来验证，强调是否完整
确认范围针对可交付成果，在阶段末，由发起人或客户来确认验收
确认范围--质量控制
质量控制一般在之前进行，也可同时进行
确认范围一般在阶段末进行，质量控制并不一定在阶段末进行
确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付物的正确性，并符合为其制定的具体质量要求
质量控制属于内部检查，由执行组织的相应质量部门实施；确认范围则是外部干系人对可交付成果进行检查验收
确认范围--项目收尾
都在阶段末进行的，确认范围强调的是核实和接受可交付成果，项目收尾是结束项目或阶段所要做的流程性工作
都有验收工作，确认范围验收的可交付成果，项目收尾强调验收产品
确认的可交付成果
工作绩效数据
检查
审查
评审
走查
审计
巡检
测试
验收的可交付成果
变更请求
工作绩效信息
控制范围
是监督项目和产品的范围状态、管理范围基准变更的过程，主要作用是在整个项目期间保持对范围基准的维护
范围蔓延
未经控制的产品或项目范围的扩大
范围变更的原因
政策变化
计划不够周密详细
市场变化
执行组织本身发生变化
客户要求变化
范围变更控制的工作
影响导致变更的因素，使之往有利方向发展
判断变更是否已经发生
管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
偏差分析
项目管理计划更新
组织过程资产更新
0 条评论
回复 删除
下一页
