5.2 项目范围管理

四、定义范围

定义范围是制定项目和产品详细描述的过程，是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。

工具和技术

1. 产品分析

项目范围说明书中有验收标准，所以要做产品分析。
价值工程（产品没做出来之前）
价值分析（产品做出来之后）：

• 用最小的成本识别功能
• 为每个功能确定价值
• 用最少的成本实现功能

软件系统里的“僵尸功能”：
很多大型软件里有不少功能，用户是基本或从来不用的，我们把它称为僵尸功能。其收益极小，但成本可能很大（需要维护升级）
原因：闭门造车想当然；需求分析不到位；强势领导或客户乱加需求
解决：实现做好需求分析工作；事后可用功能计数器；统计功能使用率；做功能价值分析。优化频繁使用功能，做到机智体验（突出高价值）；不做或砍掉不必要的功能（去掉无价值的浪费）

2. 备选方案生成

用来指定尽可能多的潜在可选方案的技术。许多通用的管理技术都可用于生成备选方案。例如，头脑风暴、横向思维、备选方案分析等，其中：
（1）备选方案分析：是一种对己识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作
（2）横向思维：又称戴勃诺理论、发散思维、水平思维，是指思维的广阔度，它要求人们能全面的观察问题，从事物多种多样的联系和关系中去认识事物，它不一定是有顺序的，同时也不能预测。

范围说明书

1. 范围说明书内容：※※※（案例题，要背）

(1)产品范围描述。逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征。

(2)验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。

(3)可交付成果。可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，例如，项目管理报告和文件。对可交付成果的描述可详可简。

(4)项目的除外责任。通常需要识别出什么是被排除在项目之外的。
明确说明哪些内容不属于项目范围，有助于管理干系人的期望。

(5)制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素/例如，客户或执行组织事先确定的预算、强制性日期或强制性进度里程碑。如果项目是根据协议实施的，那么协议条款通常也是制约因素。

(6)假设条件。假设条件是指在制订计划时，不需验证即可视为正确、真实或确定的因素。在项目范围说明书中，需要列出并说明与项目范围有关的具体项目假设条件以及万一不成立而可能造成的后果。在项目规划过程中，项目团队应该经识别、记录并验证假设条件。

助记：产验可除制假

2. 项目范围说明书的主要作用（了解）

(1) 确定范围。项目范围说明书描述了可交付成果和所要完成的工作。
(2) 沟通基础。项目范围说明书表明项目干系人之间就项目范围所达成的共识。为了便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
(3) 规划和控制依据。项目范围说明书使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作。
(4) 变更基础。项目范围说明书为评价变更请求或额外工作是否超出项目边界提供基准。
(5) 规划基础。在项目范围说明书的基础上，其他计划也将被编制出来，它同时还是滚动式规划的基础。

五、创建工作分解结构（WBS）

创建WBS是将项目可交付成果和项目工作分解成较小的，更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。

创建WBS的表现形式

树形结构：层析清晰，适合小型项目
表格方式：适用大型及各类项目

工具及技术-分解

1.分解总述

WBS编制需要所有（主要）项目干系人和项目团队成员的共同参与

2. 分解活动及步骤 ※※※（背）

①识别和分析可交付成果及相关工作【要分解什么】
②确定WBS的结构和编排方法【怎么分解】
③自上而下逐层细化分解【开始分解】
④为WBS组件制定和分析标识编码【编码】
⑤核实分解的程度是否恰当【检查和确认】

4.分解结构形式

结构形式	举例说明
项目生命周期阶段作为第二层，交付物做为第三层	如按项目周期的需求、设计、开发、测试、实施等阶段作为第二层；把每个阶段产出的可交付成果作为第三层
以主要可交付物作为第二层	把交付成果做为第二层，然后进行细化分解
外包的子项目结构	如某大型ERP系统，将项目划分为多个子项目，以便外包和自制管理。外包子项目由卖方（承包方）负责分解详细WBS

第一层是项目名称

形式举例：

4.核实分解是否正确

5.分解注意事项

(1) WBS必须是面向可交付成果的。
(2) WBS必须符合项目的范围。WBS必须包括 也仅包括为了完成项目的可交付成果的活动。100%原则(包含原则) 认为， 在WBS中， 所有下一级的元素之和必须100%的代表上一级元素。如果WBS没有覆盖全部的项目可交付成果； 那么最后提交的产品或服务是无法让用户满意的。
(3) WBS的底层应该支持计划和控制。
(4) WBS中的元素必须有人负责， 而且只由一个人负责， 尽管实际上可能需要多个人参与。这个规定又称为独立责任原则。
(5) WBS的指导。作为指导而不是原则， WBS应控制在4 ~ 6层。
(6) WBS应包括项目管理工作(因为管理是项目具体工作的一部分) ，也要包括分包出去的工作。
(7) WBS的编制需要所有(主要) 项目干系人的参与， 需要项目团队成员的参与。
(8) WBS并非是一成不变的， 在完成了WBS之后的工作中， 仍然有可能需要对WBS进行修改。WBS通常要滚动分解。

输出-范围基准

范围基准是经过批准的项目范围说明书、WBS和WBS词典。只有走正式变更程序，才能变更范围基准。
（1）范围说明书：
项目范围、主要可交付成果、边界、假设和制约的描述
（2）WBS：
WBS是详细范围说明书的进一步分解。它定义了整个项目的工作范围， 不在WBS里的，则不属于项目范围，要增加，必须走变更。
控制账户：每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识， 是创建WBS的最后步骤。控制账户是一个管理控制点， 在该控制点上， 把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。控制账户设置在WBS中选定的管理节点上。每个控制账户可能包括一个或多个工作包， 但是一个工作包只能属于一个控制账户。
规划包：也是WBS的组件， 位于控制账户之下， 工作内容已知， 但详细的进度活动未知，规划包最终会分解成工作包
（3）WBS词典：
工作单元（包）的细节描述，可能包括：账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等

六、确认范围

确认范围的主要作用是使得验收过程具有客观性，同时通过验收每个可交付成功，提高最终产品、服务或成果获得验收的可能性。
确认范围应该贯穿项目始终

1. 确认范围概述

2. 工具与技术

检查：也叫审查、产品评审、走查、审计、巡检。包括测量、测试、检验等活动，判断结果是否符合要求和期望。

评审和审计区分：
1.评审：在正式会议上，将各种需求、设计、或产品等提交给用户客户或有关人士供其评审或批准； 目的是找出其中的问题、缺陷、不足或可能的改进。
【正式评估找不足】

2.审计：为评估是否符合要求而进行的一种独立的检查；通过调查研究确定已制定的过程、指令、规格说明和标准或其他的合同及特殊要求是否恰当和被遵守， 以及其实现是否有效而进行的活动。
【独立检查看遵守、看有效】

七、控制范围

范围控制设计的内容及焦点问题

范围变更的原因：

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

范围变更控制的工作：

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

范围失控相关术语

范围蔓延：Scope Creep，未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）

镀金：指团队成员擅自增加需求……

项目范围管理过程及意义

范围管理存在的问题 ※※ 【案例分析】

·没有制定范围管理计划和需求管理计划

·没做好需求收集、分析、调研等工作

·没有做好需求跟踪工作

·不能仅依据过去经验来编写现在项目的范围说明书等工作

·项目范围说明书内容不全面或者项目范围定义不充分

·项目范围说明书不应由项目经理一人来编写

·WBS及范围基准应让项目团队和所有关键干系人一起来创建， 而不是项目经理创建， 导致工作遗漏

·项目范围基准未经评审和审批

·缺少范围确认等环节，项目成果等没有得到用户的正式确认和接受

·范围变更没有规范的变更控制流程

·项目变更实施前没有及时变更合同

·变更结果没有得到客户的确认

·未做好范围控制工作，对范围管理中的偏差和问题进行及时纠正