项目范围管理

### 10大管理学习主线

每个管理领域有哪些过程？
每个过程的输入（做XX的依据）、输出（做XX的结果）、工具和技术（用XX方法和工具）是什么？
每个管理领域有什么问题，应该怎么解决？
每个管理领域和其余管理领域的关系是什么？

凡是监控过程，输入一定包含计划和绩效，结果必定包含变更和更新凡XX管理必定输出XX管理计划，作用是为管理XX提供指南和方向编写XX计划的工具和技术一定有专家判断和会议

范围管理概述

项目范围管理需要做以下三个方面的工作：

(1)明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。
(2)对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说 “不“， 杜绝做额外工作。
(3)防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

产品范围与项目范围

产品范围是指产品或者服务所应该包含的功能（技术主线），项目范围是指为了能够交付产品，项目所必须做的工作（管理主线）。

产品范围是项目范围的基础，产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础

项目的范围基准(Scope Baseline)是经过批准的项目范围说明书、WBS(Work Breakdown Structure)和WBS词典。判断项目范围是否完成，要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断。

产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。

范围管理的重要性

无重要考点

范围管理的过程

项目范围管理主要是通过规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的。

规划范围管理（过程一）

规划范围管理(Plan Scope Management)是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程， 其主要作用是在整个项目中对如何管理范围提供指南和方向。

规划范围管理过程的输入有项目管理计划、项目章程、事业环境因素和组织过程资产，使用的工具与技术有专家判断和会议，输出有范围管理计划和需求管理计划。本节主要简单介绍范围管理计划和需求管理计划。

范围管理计划

范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，要对将用于下列工作的管理过程做出规定：

如何制订项目范围说明书。
如何根据范围说明书创建WBS。
如何维护和批准WBS。
如何确认和正式验收已完成的项目可交付成果。
如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。

项目范围管理计划（同其他管理计划）可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。

需求管理计划

需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理计划主要包括以下内容：

(1)如何规划、跟踪和汇报各种需求活动
(2)需求管理需要使用的资源。
(3)培训计划。
(4)项目干系人参与需求管理的策略。
(5)判断项目范围与需求不一致的准则和纠正规程。
(6)需求跟踪结构
(7)配置管理活动

收集需求（过程二）

需求的分类

(1) 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
(2)干系人需求：是指干系人或干系人群体的需要。
(3)解决方案需求：是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。
(4)过渡需求：从当前状态过渡到将来状态所需的临时能力，例如，数据转换和培训需求。
(5)项目需求：项目需要满足的行动、过程或其他条件。
(6)质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为**基本需求、期望需求和意外需求**。
#### 收集需求的工具与技术收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。

焦点小组

焦点小组将预先选定的干系人和主题专家集中在—起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对—的访谈更加热烈。
焦点小组是—种群体访谈而非一对一访谈，可以有6~10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。

引导式研讨会

通过邀请主要的跨职能干系人一起参加会议，引导式研讨会(Facilitated Workshop)对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另—个好处是，能够比单项会议更快地发现和解决问题。

群体创新技术

群体创新技术(Group Creativity Technique)是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念／思维导图、亲和图和多标准决策分析等。

头脑风暴(Brain Storming, BS)法又称为智力激励法、自由思考法或集思广益法：各抒己见
名义小组技术(Nominal Group Technique)**通过投票来排列最有用的创意**，以便进行进—步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法
德尔菲技术(Delphi Technique)：防止个人的观点被不正确的放大
思维导图(Mind Mapping)又称为心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
亲和图(Affinity Diagram)又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统—认识，以利于解决的—种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。
多标准决策分析(Multi-Criteria Decision Analysis)是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益**等多种标准**，从而对众多方案进行评估和排序的一种技术。

群体决策

群体决策(Group Decision-Making)就是为达成某种期望结果而对多个未来行动方案进行评估：

—致同意(Unanimity)。所有人都同意某个行动方案。
大多数原则(Majority)。获得群体中50％以上的人的支持，就能做出决策。参与决策的人数定为奇数，防止因平局而无法达成决策。
相对多数原则(Plurality)。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。通常在候选项超过两个时使用该原则，例如，某个软件构件的功能有3种实现方案（标记为A、B、C) ，在群体决策时，同意A方案的人有40%，同意B方案的人有35%，同意C方案的人有25%，则最终确定采用A方案。
独裁(Dictatorship)。由某一个人（例如，项目经理）为群体做出决策。

原型法

原型法(Prototype) 是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法。

标杆对照

标杆对照(Benchmarking)将实际或计划的做法与其他类似组织的做法（例如，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的＂类似组织” 可以是内部组织，也可以是外部组织。

系统交互图

系统交互图(ContextDiagram)是范围模型的一个例子，它是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者

文件分析

文件分析(Document Analysis)就是通过分析现有文档，识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。

需求文件

收集需求过程的主要输出有需求文件(Requirements Documentation)和需求跟踪矩阵。需求文件描述各种单一的需求将如何满足与项目相关的业务需求。

需求文件的内容包括（但不限于）以下几个方面：

业务需求
干系人需求
解决方案需求
项目需求
过度需求
与需求有关的假设条件、依赖关系和制约因素

需求跟踪

需求管理包括在产品开发过程中维持需求—致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求—致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。

需求跟踪的内容

每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型，如图5-1所示。

箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。

从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。

需求跟踪矩阵

表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯—标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。

定义范围（过程三）

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

定义范围的工具与技术

定义范围过程的主要工具与技术有专家判断、产品分析、备选方案生成和引导式研讨会。

产品分析(Product Analysis)是—种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述备选方案生成(Alternatives Generation)是—种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。

范围说明书

作为定义范围过程的主要成果，项目范围说明书(Project Scope Statement)是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。

项目范围说明书包括如下内容：

产品范围描述
验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
可交付成果。
项目的除外责任。
制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素
假设条件。

项目范围说明书的主要作用如下:

(1)确定范围
(2)沟通基础
(3)规划和控制依据。
(4)变更基础。
(5)规划基础。

创建工作分解结构（过程四）

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程

WBS的层次

里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线

工作包(Work Package)是位于WBS每条分支最底层的可交付成果或项目工作组成部分。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。8/80规则(80小时原则）建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时。即工作一天（8小时）到两周（5X8X2=80小时）

控制账户(Control Account) 是—种管理控制点。控制账户是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后—种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。

规划包(Planning Package)是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包之上的WBS要素。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

在制作WBS的过程中，要给WBS的每个部分赋予—个账户编码(Code of Account)标志符，它们是成本、进度和资源使用信息汇总的层次结构。需要生成—些配套的文件，这些文件需要和WBS配套使用，称为WBS词典。WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。

分解

创建WBS 过程的工具与技术主要有分解和专家判断。

要将整个项目工作分解为工作包，通常需要开展以下活动：

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

分解的原则

创建WBS时对工作的划分，可以参考一些现成的原则，这些原则包括：

(1)功能或者技术原则。在创建WBS时，需要考虑将不同人员的工作分开。
(2)组织结构。对于职能型的项目组织而言， WBS也要适应项目的组织结构形式，
(3)系统或者子系统。总的系统划分为几个主要的子系统， 然后对每个子系统再进行分解。

在项目管理实践中，可以按照下列方式进行分解：

项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
主要可交付成果作为分解的第二层（将子项目作为分解的第二层）

工作过程

WBS不是某个项目团队成员的责任，应该由**全体项目团队成员、用户和项目干系人**共同完成和一致确认。较常用的WBS表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌；表格形式的直观性比较差，但能够反映出项目所有的工作要素。

值得注意的是，虽然有些参考文献也使用鱼骨图形式的WBS，但这种形式并不常用。

注意事项

在分解的过程中，应该注意以下8个方面：

WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是—连串特别的活动。
WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动。
WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算
WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
WBS的指导。作为指导而不是原则， WBS应控制在4~6层。
WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
WBS 并非是— 成不变的。在完成了WBS 之后的工作中，仍然有可能需要对WBS进行修改。
一个下层只可以有一个上层，一个上层可以有多个下层，避免交叉从属

WBS的作用

当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，WBS的目的和用途主要体现在以下8个方面：

(1)明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
(2)清楚地定义项目的边界
(3)为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
(4)针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
(5)为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
(6)将项目工作和项目的财务账目联系起来。
(7)确定工作内容和工作顺序， 将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
(8)有助于防止需求蔓延。

确认范围（过程五）

确认范围(Validate Scope)是正式验收项目已完成的可交付成果的过程，确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。

确认范围概述

确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审计、走查、巡检、测试等

确认范围的步骤

确认范围应该贯穿项目的始终，确认范围的一般步骤如下：

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

需要检查的问题

项目干系人进行范围确认时，一般需要检查以下6个方面的问题：

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

干系人关注点

考过几次，可以关注一下：

管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。

客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。

项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。

项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方。

几个术语的比较

确认范围与核实产品
核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
确认范围与质量控制
确认范围与质量控制的不同之处在于：
- 确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
- 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不—定在阶段未进行。
- 质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。

确认范围与项目收尾

确认范围与项目收尾的不同之处在于：
- 虽然确认范围与项目收尾工作都在阶段未进行， 但确认范围强调的是核实与接受
    可交付成果， 而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
- 确认范围与项目收尾都有验收工作， 确认范围强调验收项目可交付成果， 项目收
    尾强调验收产品。

控制范围（过程六）

控制范围(Control Scope)是监督项目和产品的范围状态、管理范围基准变更的过程

范围变更的原因

造成项目范围变更的主要原因是项目外部环境发生了变化，例如：

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

范围变更的工作

范围变更控制的主要工作如下：

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