信息系统项目管理师：第5章：项目范围管理（2）-重点汇总

五、创建工作分解结构(WBS)

1、相关概念

创建WBS：创建工作分解结构(WBS)是面向可交付物的层次型结构,它组织并定义了整个项目范围，并把项目工作细分为更小、更易管理的工作单元的过程。

工作包：WBS每条分支最底层的可交付成果或项目工作组成部分，工作包大小依据8/80规则。

规划包

• ①工作包之上，控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。
• ②对目前尚不清楚具体活动的模块可以使用规划包进行分解，随着情况的逐渐清晰,规划包最终将被分解成工作包以及相应的具体活动。

控制账户

• ①既可以是工作包,也可以是比工作包更高层次上的一个要素。
• ②每个控制账户可能包括一个或多个工作包,但是一个工作包只能属于一个控制账户。

WBS词典：WBS词典也称为WBS词汇表,它是描述WBS各组成部分的文件

2、IPO图

3、输入(依据)

• Ø范围管理计划
• Ø项目范围说明书
• Ø需求文件

4、工具技术（分解）

★需要开展的活动

• 识别和分析可交付成果及相关工作
• 确定WBS的结构和编排方法
• 自上而下逐层细化分解
• 为WBS组件制定和分配标识编码
• 核实可交付成果分解的程度是恰当的

分解的原则

• ①在创建WBS时,需要考虑将不同人员的工作分开。
• ②在创建WBS时,需要适应组织结构形式。
• ③项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放在第三层。

• ④主要可交付成果作为分解的第二层

• ⑤总的系统划分为几个主要的子系统

 

★注意事项

• ①WBS必须是面向可交付成果的
• ②WBS必须符合项目的范围,必须并且只能包括100%的工作
• ③WBS的底层应该支持计划和控制
• ④WBS中的元素必须有人负责,而且只由一个人负责
• ⑤WBS的指导，WBS应控制在4~6层,一个工作单元只能从属于某个上层单元
• ⑥WBS应包括项目管理工作,也要包括分包出去的工作
• ⑦WBS的编制需要所有(主要)项目干系人的参与,不是某个项目团队成员的责任，应该由所有干系人共同完成和一致确认
• ⑧WBS并非是一成不变的,在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改

 

输入(依据)—★范围基准(Scope Baseline)—经过批准的项目范围说明书、WBS和WBS词典。

六、确认范围(Validate Scope)

1、确认范围概述

确认范围是正式验收已完成的项目可交付成果的过程

一般步骤

• 确定需要进行确认范围的时间
• 识别范围确认需要哪些投入
• 确定范围正式被接受的标准和要素
• 确定确认范围会议的组织步骤
• 组织范围确认会议

需要检查的问题

• 可交付成果是否是确定的、可确认的
• 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件
• 是否有明确的质量标准
• 审核和承诺是否有清晰的表达
• 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误
• 项目范围的风险是否太高,管理层是否能够降低可预见的风险发生时对项目的冲击

2、IPO图

3、输入(依据)

• 需求文件
• 需求跟踪矩阵

4、工具技术—检查

5、输出(成果)

• 验收的可交付成果
• 变更请求

6、★注意(P245-P246)

①确认范围与核实产品

②确认范围与质量控制

• (1)质量控制属内部检查,由执行组织的相应质量部门实施
• (2)确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收

③确认范围与项目收尾

七、控制范围 (Control Scope)

 

1、控制范围概述

• 控制范围是监督项目和产品的范围状态、管理范围变更的过程,其主要作用是在整个项目期间保持对范围的维护
• 在变更实际发生时,应采用范围控制过程来管理这些变更

2、范围变更的原因

• 政府政策的问题
• 项目范围的计划编制不周密详细,有一定的错误或遗漏
• 市场上出现了或是设计人员提出了新技术、新手段或新方案
• 项目执行组织本身发生变化
• 客户对项目、项目产品或服务的要求发生变化

3、范围变更控制的主要工作

• 影响导致范围变更的因素,并尽量使这些因素向有利的方面发展
• 判断范围变更是否已经发生
• 范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理

4、IPO图

5、输入(依据)

• 项目管理计划—范围基准
• 工作绩效数据
• 需求跟踪矩阵

6、输出(成果)—变更请求

 

汇总图片