高项-项目范围管理
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高项-项目范围管理相关的知识,希望对你有一定的参考价值。
参考技术A 一、六个过程:1.1 规划范围管理
ITO
输入:1)项目管理计划 2)项目章程 3)事业环境因素 4)组织过程资产
工具:1)专家判断 2)会议
输出:1)范围管理计划 2)需求管理计划
1.2 收集需求
ITO
输入:1)范围管理计划 2)需求管理计划 3)干系人管理计划 4)项目章程 5)干系人登记册
工具:1)访谈 2) 焦点小组 3)引导式研讨会 4)群体创新技术 5)群体决策技术 6)问卷调查等11个
输出:1)需求文件 2)需求跟踪矩阵
1.3 定义范围
ITO
输入:1)范围管理计划 2)项目章程 3)需求文件 4)组织过程资产
工具:1)专家判断 2)产品分析 3)备选方案生成 4)引导式研讨会
输出:1)项目范围说明书 2)项目文件更新
1.4 创建WBS
ITO
输入:1)范围管理计划 2)项目范围说明书 3)需求文件 4)事业环境因素 5)组织过程资产
工具:1)分解 2)专家判断
输出:1)范围基准 2)项目文件更新
工作包 8/80 原则
WBS 4--6层
控制账号>规划包>工作包
将整个项目工作分解为工作包,需要展开以下活动:
1)识别和分析可交付成果及相关工作
2)确定WBS的结构和编排方法
3)自上而下逐层细化分解
4)为WBS组件指定和分配标识编码
5)核实可交付成果分解的程度是否恰当
范围基准包括 项目工作说明书 WBS WBS词典
1.5 确认范围
ITO
输入:1)项目管理计划 2)需求文件 3)需求跟踪矩阵 4)确认的可交付成果 5)工作绩效数据
工具:1)检查 2)群体决策技术
输出:1)验收的可交付成果 2)变更请求 3)工作绩效信息 4)项目文件更新
确认范围和质量控制的区别
质量控制在确认范围之前或者同时
质量控制一般内部干系人做,确认范围是外部干系人做
1.6 控制范围
ITO
输入:1)项目管理计划 2)需求文件 3)需求跟踪矩阵 4)工作绩效数据 5)组织过程资产
工具:1)偏差分析
输出:1)工作绩效信息 2)变更请求 3)项目管理计划更新 4)项目文件更新 5)组织过程资产更新
五大过程组: 启动 规划 执行 监控 结尾
项目范围说明书内容
1)产品范围描述
2)验收标准
3)可交付成果
4)项目的除外的责任
5)制约因素
6)假设条件
项目范围说明书作用
1)确认范围
2)沟通基础
3)规划和控制依据
4)变更基础
5)规划基础
高项备考范围管理,过程域知识点案例学习
一、前言
最近准备备考信息系统项目管理师,将学习的东西总结一下。
总是学了就忘,就是学的不够深入,将知识再总结再提取,可以记忆更深刻。
学习就是这样,学习、总结,总结再学习,学而思,思而学。
不过这玩意记的东西真多。
二、过程域
范围管理过程域:
启动过程组 | 规划过程组 | 执行过程组 | 监控过程组 | 收尾过程组 |
---|---|---|---|---|
规划范围管理 | 确认范围 | |||
收集需求 | 控制范围 | |||
定义范围 | ||||
创建WBS(工作分解结构) |
规划范围管理ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
项目管理计划 | 范围管理计划 | 专家判断 |
项目章程 | 需求管理计划 | 会议 |
组织过程资产 | ||
事业环境因素 |
收集需求ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
范围管理计划 | 需求文件 | 专家判断 |
需求管理计划 | 需求跟踪矩阵 | 访谈 |
项目章程 | 焦点小组 | |
干系人管理计划 | 群体创新技术 | |
干系人登记册 | 群体决策技术 | |
问卷调查 | ||
观察 | ||
原型法 | ||
标杆对照 | ||
系统交付图 | ||
文件分析 | ||
引导式研讨会 |
定义范围ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
范围管理计划 | 项目范围说明书 | 专家判断 |
项目章程 | 项目文件更新 | 产品分析 |
需求文件 | 备选方案生成 | |
组织过程资产 | 引导式研讨会 |
创建WBS,ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
范围管理计划 | 范围基准 | 专家判断 |
范围说明书 | 项目文件更新 | 分解 |
需求文件 | ||
组织过程资产 | ||
事业环境因素 |
确认范围ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
项目管理计划 | 验收的可交付成果 | 检查 |
需求文件 | 变更请求 | 群体决策技术 |
需求跟踪矩阵 | 工作绩效信息 | |
确认的可交付成果 | 项目文件更新 | |
工作绩效数据 |
控制范围ITTO:
输入 | 输出 | 工具技术 |
---|---|---|
项目管理计划 | 工作绩效信息 | 偏差分析 |
需求文件 | 变更请求 | |
需求跟踪矩阵 | 项目管理计划更新 | |
工作绩效数据 | 项目文件更新 | |
组织过程资产 | 组织过程资产更新 |
三、知识点
项目范围说明书内容:
- 项目的目标。项目目标包括成果性目标和约束性目标。项目成果性目标指通过项目开发出的满足客户要求的产品、服务或成果。项目约束性目标是指完成项目成果性目标需要的时间、成本以及要求满足的质量。
- 产品范围描述。这一节描述了项目承诺交付的产品、服务或结果的特征。这种描述会随着项目的开展,其产品特征会逐渐细化。
- 项目的可交付物。可交付物包括项目的产品、成果或服务,以及附属产出物例如项目管理报告和文档。根据需要,可交付物可以被描述得比较概要,也可以很详细。
- 项目边界。边界严格定义了哪些事项属于项目,也应明确地说明什么事项不属于项目的范围。
- 产品验收标准。该标准明确界定了验收可交付物的过程和原则。
- 项目的约束条件。描述和列出具体的与项目范围相关的约束条件,约束条件对项目团队的选择会造成限制。例如,客户或组织发布的预算或任何强加的日期(进度里程碑)都应被包括在内。当一个项目按合同执行时,合同条款通带是约束条件。约束信息应该列入项目范围说明书或单独的文档。
- 项目的假定。描述并且列出了特定的与项目范围相关的假设,以及当这些假设不成立时对项目潜在的影响。作为计划过程的一部分,项目团队经常识别、记录和确认假设。假设信息应该列入项目范围说明书或单独的文档。
项目范围说明书的作用:
- 确定范围
- 沟通基础
- 规划和控制依据
- 变更基础
- 规划基础
WBS创建工作分解结构
WBS的介绍:
WBS是以可交付成果为导向的工作层级分解,其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。注意:WBS中的“工作”并不是指工作本身,而是指工作所导致的产品或可交付成果。
WBS的层次
WBS将项目整体或主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包,子项目需要继续分解为工作包,直至整个项目都分解为可管理的工作包,这些工作包的总和就是项目的所有工作范围。主要包括里程碑、工作包、控制账户、规划包、WBS词典。
WBS的内容
(1)里程碑:标志着某个可交付成果或者阶段的正式完成。
(2)工作包:最底层的可交付成果或项目工作组成部分。8/80规则建议:最大为一个人80个小时能完成的工作量,最小不低于8个小时。
(3)控制账户:是一种管理控制点,既可以是工作包,也可以是比工作包更高层次上的要素,用以测量绩效(比如挣值比较)。一个控制账户中可包含多个工作包,但一个工作包仅属于一个控制账户。
(4)规划包:控制账户之下,工作包之上,工作内容已知但尚缺详细的WBS组成部分,用来暂时做计划的,随着逐渐清晰,规划包最终都会被分解成工作包。
(5)WBS词典:是描述WBS各组成部分的文件。相当于新华字典。
创建WBS的步骤
(1)识别和分析可交付成果及相关工作
(2)确定WBS的结构和编排方法
(3)自上而下逐层细化分解
(4)为WBS组件指定和分配标识编码
(5)核实可交付成果分解的程度是恰当的
WBS的分层的特点
(1)每层中的所有要素之和是下一层的工作之和
(2)每个工作要素应该具体指派一个层次,不能指派给多个层次
(3) WBS需要有投入工作的范围描述
WBS分解的方法
(1)将项目生命周期的各阶段作为第二层,产品和可交付成果放在第三层
(2)主要可交付成果作为分解的第二层(如果有部分外包的,最好以这种方式分解,易于管理)
(3)外包工作也要整合进来分解,卖方需编制相应的合同WBS
WBS分解注意事项
(1)WBS必须是面向可交付成果的
(2)WBS必须符合项目的范围
(3)WBS底层应该支持计划和控制
(4)WBS中的元素必须要有人负责,且只由一人负责,尽管实际上多人参与
(5)WBS作为指导而不是原则,应控制在4~6层
(6)WBS应该包括项目管理工作,也要包含分包出去的工作
(7)WBS的编制需要所有项目干系人参与
(8)WBS并非是一成不变的,完成后有可能修改
WBS的目的和作用
(1)明确和准确说明项目范围
(2)清楚地定义项目的边界
(3)确定完成项目所需要的技术和人力资源
(4)提高对时间、成本和资源需求量的估算准确性
(5)为计划、预算、进度和费用控制奠定基础,确定项目进度和控制基准
(6)将项目工作和财务账目联系起来
(7)确定工作内容和顺序
(8)有助于防止需求蔓延
确认范围步骤
(1)确定需求金锭范围确认的时间
(2)识别范围确认需求那些投入
(3)确定范围正式被接收的标准和要素
(4)确定范围确认会议的组织步骤
(5)组织范围确认会议
四、案例分析
一、案例一
问题1:(找茬题)
1、有项目范围说明、需求文件,没有范围管理计划
2、参照类似项目文档编制项目范围说明书,范围定义存在问题
3、仅向甲方管理层进行需求调研,收集需求存在问题,需求获取不全面
4、不能只有项目经理一人进行任务分解,应该团队协助下进行分解
5、范围变更存在问题,没有按照变更流程处理变更
6、范围确认存在问题,导致试运行阶段,功能模块不符合需求和计划要求
问题2:(背书题)
1、规划范围管理(编制范围管理计划)
2、收集需求
3、定义范围
4、创建WBS(工作分解结构)
5、确认范围
6、管理范围
问题3:
(1)C
(2)E
(3)A
–
二、案例二
问题1:
应该扣除。(先拿1分)
因为张工对于范围的管理有疏漏:
(1)不应该王工一个人编写需求说明书,应该相关人员共同编写
(2)需求评审时不应该只在项目组成员内部进行,甲方也要参加
(3)未成立变更控制委员会CCB
(4)需求变更评估后未经CCB审批
(5)需求变更后未通知相关主要人员,尤其是公司领导
(6)未走需求变更流程
(7)未做好项目沟通管理
问题2:
(1)A
(2)C
(3)E
问题3:
范围变更控制的基本流程:
(1)提交变更申请
(2)进行变更评估
(3)CCB审批
(4)执行变更
(5)变更确认
(6)变更通知
三、案例三
问题1:
(1)没有制定项目范围管理计划
(2)没有进行范围定义(没有形成范围说明书)
(3)没有进行范围确认
(4)变更应该遵循整体变更流程
(5)范围管理中与干系人沟通存在问题,未与干系人取得统一意见
(6)SRS(需求规格说明书)未评审就付诸行动。
问题2:
(1)还可以采用项目生命周期进行分解,将可交付物作为第一层,子项目作为第二层
(2)项目管理工作
(3)ADEF
问题3:
(1)客户对项目、项目产品或服务的要求发生变化
(2)项目环境发生变化;范围计划编制有错误或遗漏;市场出现了新技术、新手段、新方案;项目实施组织发生了变化
以上是关于高项-项目范围管理的主要内容,如果未能解决你的问题,请参考以下文章