项目范围管理

> # 范围管理 过程 输入 输出 工具 技术

项目范围管理

6个过程

1.编制范围管理计划过程

定义、确认、控制项目范围的过程进行描述

2.收集需求

为实现项目目标，明确、记录项目干系人相关需求的过程

3.定义范围

详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础

4.创建工作分解结构

把整个项目分解为较小的、易于管理的组成部分，自上而下的分解结构

5.范围确认

正式验收已完成的可交付成果

6.范围控制

监督项目和产品的范围状态、管理范围基准变更

---

产品范围 和 项目范围

产品范围是项目范围的基础

产品范围

表示产品、服务、结果的特性和功能 -（需求分析，技术方面）

是否完成的依据

是否完成以产品要求作为衡量标准

项目范围

为了完成具有规定特征和功能的产品、服务、结果，而必须完成的项目工作 -（管理方面）

是否完成的依据

以项目管理计划、项目范围说明书、WBS、以及WBS字典作为衡量标准

---

项目范围管理计划

是项目或项目集管理计划的组成部分，描述如何定义、制定、监督、控制、确认项目范围

项目范围管理计划有助于 降低项目的范围蔓延的风险

项目团队成员可以参加 项目会议 来制定范围管理计划

项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理过程的负责人、以及必要人员

项目范围管理计划需要项目管理团队全员参加

依据实际情况，项目范围管理计划可以是 正式或非正式的、详细或粗略的

一个范围管理计划，可以包括在项目管理计划中、或者项目管理计划的一个分计划

项目管理计划，是项目其他知识域中的相关分计划的集合

范围管理计划内容

1.制定详细项目范围说明书

2.依据详细范围说明书，创建WBS

3.维护和批准WBS

4.验收项目可交付成果

5.处理变更详细项目范围说明书或WBS的变更 --该工作与实施整体变更控制过程直接相连

范围定义

的重要任务 –详细定义项目的 范围边界

范围边界将应该做的和不应该做的进行工作分界线

可以增加项目时间、成本、资源估算的准确度,定义项目控制的依据，明确责任人的责任，明确项目范围、合理性和项目目标，以及主要可交付成果

---

需求

需求文件内容

1.业务需求
2.干系人需求
3.解决方案需求
4.项目需求
5.过度需求
6.需求相关的假设条件、依赖关系、制约因素

收集需求工具和技术

访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析。。。

群体创新技术

群体决策技术

为了达到某种预期的结果，对多个未来行动方案进行评估的过程

用于生产产品需求，并对产品需求继续归类和优先级排序

达成群体决策方法

1.一致同意 --全部通过

2.大多数原则 --超过50%通过

3.相对对数原则 --相对多数同意的通过

4.独裁 --一人做决策

需求跟踪

1.业务需要、机会、目的、目标
2.项目目标
3.项目范围、WBS可交付成果
4.产品设计
5.产品开发
6.测试策略和测试场景
7.高层级需求到详细需求

需求跟踪矩阵

记录的典型属性包括

唯一标识、需求的文字描述、收录需求的理由、所有者、来源、优先级别、版本、当前状态、状态日期

连接了需求与需求源，用于整个项目生命周期中对需求进行跟踪

是把产品需求从来源到满足需求可交付成果的一种表格

---

定义范围

工具和技术

1.产品分析：对产品的要求 转化为 对项目的要求

2.备选方案：用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法

3.引导式研讨会 ：不同期望或专业知识的关键人参与研讨会，有助于项目目标和项目限制达成跨职能的共识

范围说明书

是对项目范围、主要可交付成果、假设条件和制约因素的描述

详细的范围说明书 或 引用的文档 包括以下内容

1.项目目标 2.产品范围描述 3.项目需求 4.项目边界 5.项目可交付成果 6.项目的制约因素 7.假设条件

---

工作分解结构 WBS

把项目可交付成果和项目工作分解程 较小的、易于管理的组件 的过程

工作分解结构 是项目管理的 基础

项目的所有规划和控制工作 都必须基于工作分解结构

WBS 对项目管理的意义

1.相关人员对项目一目了然
2.保证项目系统性、完整性
3.建立完整的项目保证体系
4.明确项目工作，便于责任划分

WBS最底层工作单元 - ==工作包

进行进度安排、成本估算、监控的基础

大小应至少需要 8小时完成，总时间也应不大于80小时

内容包括

1.项目的全部工作都必须包含在WBS当中
2.编制需要所有项目干系人参与
3.逐层向下分解，每条分支分解层不必相等，控制在3-6层

工作包特征

1.规模较小，可以在短时间（80小时内）完成
2.从逻辑上讲，不能再分解
3.所需资源、时间、成本已经可以比较精确估算，可以进行有效的时间、成本、质量、范围、风险的控制

WBS中的要素应该是相对独立的，要尽量减少互相之间的交叉

常用WBS的形式

1.分级的树型结构

层次清晰、直观、结构性强 – 不易修改 – 小项目中使用

2.表格形式

反应项目的所有工作要素 --直观性差 – 在大项目、复杂项目中使用较多

编码设计对于WBS来说是个关键技术，进行编码设计时必须仔细考虑收集到的信息和收集方式

把项目分解成工作包，需要步骤

1识别、分析可交付成功及相关工作
2.确定WBS的结构和编排方式
3.自上而下的分解
4.为WBS组件制定和分配表示编码
5.核实可交付成果分解的程度是否恰当

WBS结构分层的方法 至少有以下三种

1.使用项目生命周期 的阶段作为第一层，项目可交付物作为第二层

2.可交付物作为分解第一层

3.把子项目作为第一层，再分解子项目的WBS

WBS原则

1.避免遗漏必要的组成部分
2.避免交叉部署
3.相同层次的工作单元应有相同性质
4.应能分开不同的责任人
5.便于项目管理计划需要
6.应该具有可比性，时刻管理的，可定量检查的
7.应包括项目管理工作，包括分包出去的工作

WBS每向下分解一层，代表着对项目工作更详细的定义

WBS字典

WBS字典实际是相当于新华字典，是对WBS中每个元素的描述

内容包括

账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关活动进度、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。

里程碑 = 具体时间 + 在这个时间内应完成的事件

控制账户

是一个控制管理点，在该控制点上，把范围、预算、实际成本和进度加以整合，与净值相比较，以测量绩效

控制账户在WBS中选定的(管理)控制节点上，每个控制账户可能包括一个或多个工作包，但一个工作包只属于一个控制账户

每个工作包分配到一个控制账号，根据“账户编码”为工作包建立唯一标识是创建WBS的最后步骤

范围基准 (输出)

经过批准的范围说明书、工作分解结构 WBS 、相应的WBS字典 组成范围基准

---

范围确认

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

范围确认需要审查可交付物和工作成果，以保证项目中所有工作都能准确的、满意的完成

贯穿项目始终,

范围确认过程应以书面文件的形式把完成情况记录下来

步骤

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

范围确认采用的方法

检查

开展 测量、审查、确认等活动来判断工作和可交付成果是否符合需求和产品验收标准，是否满足干系人的要求和期望

检查也被称为审查、产品审查、审计、巡检等

采用方法 -检查和群体决策技术

范围确认过程 与 控制质量过程

不同之处

范围确认：关注可交付成果的验收

控制质量：关注可交付成果的正确性以及是否满足质量要求

控制质量范围过程通常先于确定范围过程，但两者可同时进行

---

范围控制

监督项目和产品的范围状态，管理范围基准变更的过程。

范围控制 涉及到影响引起范围变更的因素，确保被请求的变更、推荐矫正的措施、预防措施 按住项目整体变更控制处理，并在范围变更实际发生是进行管理

范围控制过程，因该与其他控制过程协调展开

范围蔓延

未经控制的产品、项目范围的扩大(未对时间、成本、资源做出相应调整)

镀金

项目实施人员往往愿意尝试新的技术

变更不可避免，因此每个项目上，都必须以书面的形式记录实施某种形式的变更控制管理

变更控制的焦点问题

1.确定范围变更是否已发生 2.对造成范围变更的因素施加影响，以确保变更得到一致认可 3.范围变更发生时，对实际变更进行管理

范围管理是整体管理的一部分，变更流程可以统一设计、统一管理，因此没必要必须把范围变更和整体变更区分开来

---

需求基线

定义了项目的范围

随着项目进展，用户的需求可能发生变化，从而导致需求基线变化、项目范围变化

每次需求变更并经过需求评审后，都要重新确定新的需求基线

项目组需要维护需求基线文档，保存好各个版本的需求基线，备不时之需

随着项目的进展，需求基线越定越高，容许的需求变更也越来越少