（13.1.3.2）PMBOK之三：十大知识领域之范围管理

过程	输入	工技	输出
5.1 规划范围管理	项目管理计划、项目章程、事业环境因素、组织过程资产、	专家判断、会议	范围管理计划、需求管理计划
5.2 收集需求	范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册	访谈、焦点小组、引导式讨论、群体创新技术、群体决策技术、问卷调查、观察原型法、标杆对照、系统交互图、文件分析	需求文件、需求跟踪矩阵
5.3 定义范围	范围管理计划、项目章程、需求文件、组织过程资产	专家判断、产品分析、备选方案生成、引导式研讨会	项目范围说明书、项目文件更新
5.4 创建工作分解结构	范围管理计划、项目范围说明书、需求文件、事业环境因素、组织过程资产	分解、专家判断	范围基准、项目文件更新
5.5 确认范围	项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据	检查、群体决策技术	验收的可交付成果、变更请求、工作绩效信息、项目文件更新
5.6 控制范围	项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产	偏差分析	工作绩效信息、变更请求、项目计划更新、项目文件更新、组织过程资产更新

3.2.1 概述

项目范围管理旨在保证做且只做为完成项目所需的全部工作，项目范围管理需要：

• 明确项目边界，明确什么工作是项目范围内的。
• 明确项目必须提交的全部可交付成果。
• 动态对项目工作进行监控，确保所有该做的工作都做了。
• 动态对项目工作进行监控，防止发生范围蔓延
• 对不包括在项目范围之内的额外工作说“不”，预防做额外工作（镀金） 。
• 及时对项目可交付成果进行实质性验收

项目范围管理的重要性：项目范围管理是项目其他各方面管理的基础。如果范围都弄不清楚，进度、成本和质量等也就无法弄清楚

• 范围蔓延( Scope Creep)指未经控制的项目范围扩大。
  
  • 一方面，项目范围很容易以一种不易察觉的方式逐渐扩大；等到察觉后，项目范围已经发生实质性变化，导致项目范围的重大偏离。
  • 另一方面， 项目干系人可能误认为，让项目团队多做事情能增加项目价值，从而不经过既定的申请和审批程序，就随意增加工作内容。
  • 范围蔓延导致的结果就是镀金，即做了额外的工作

产品范围与项目范围既有联系又有区别

• 产品范围是指项目将要形成的项目产品的特性和功能，而项目范围是指为了完成具有特定性质和功能的项目产品而必须开展的工作。

• 产品范围的完成情况，要依据产品需求文件来考核。项目范围的完成情况，要依据项目管理计划来考核

  • 一方面，产品范围决定项目范围，只有弄清楚产品范围，才能弄清楚项目范围
  • 另一方面，项目范围服务于产品范围，只有项目范围做到位，产品范围才能实现

产品范围的变化与项目范围的变化之间，没有必然的联系
例如，一面原计划油漆成白颜色的墙，要改油漆成黄色，产品范围发生了变化，但如果这一改变是在油漆采购之前做出的，项目范围不会发生变化

3.2.2 涉及过程

项目范围管理通过以下六个过程来实现：

• 规划范围管理。编制范围管理计划和需求管理计划。
• 收集需求。用各种方法，明确并记录项目干系人的相关需求。
• 定义范围。编制项目范围说明书，确定项目边界。
• 创建 WBS。把整个项目分解为较小的、易于管理的组成部分，形成一个自上而下分解的结构，并在此基础上得到项目范围基准。
• 确认范围。正式验收已完成并被核实为质量合格的可交付成果。
• 控制范围。监督项目和产品的范围状态，管理范围基准变更

3.2.2.1 规划范围管理

规划范围管理过程就是要编制范围管理计划和需求管理计划。

• 范围管理计划是关于将如何定义、制定、监控和确认产品范围与项目范围的计划。
  
  • 例如，将采用什么流程编制项目范围说明书、工作分解结构( WBS)以及WBS 词典？
  • 范围基准将由谁来审批？范围变更将按什么流程进行管理？
  • 将如何验收可交付成果？
• 需求管理计划是关于将如何收集、记录、分析和控制需求的计划。
  
  • 例如，将用什么方法收集什么人的需求？
  • 将用什么标准对需求进行优先级排序？
  • 将如何跟踪需求的实现过程？

3.2.2.2 收集需求

• 收集需求过程是根据范围管理计划和需求管理计划，收集项目干系人对项目的具体需求（要求）
  也就是说，把干系人对项目的需要( Needs)、想要(Wants)与期望( Expectations)，转变成具体的项目需求(Requirements)，并记录下来.

• 通过需求分析，得到需求文件和需求跟踪矩阵，为项目范围管理奠定坚实基础.

  • 需求文件记录项目干系人对项目的各种具体需求（要求）
  • 需求跟踪矩阵则说明相关需求与高层目标之间的对应关系，以及相关需求与细节层次上的项目设计、 可交付成果等之间的对应关系

在项目监控过程中，应该依据需求跟踪矩阵，来跟踪（监控）需求的实现情况
通过需求跟踪矩阵，来确保每个具体的需求都有实际意义（为高层目标服务），确保每个需求都能实现（通过细节层次上的工作）。

为了更好地管理需求，可以把需求归为以下类别：

• 商业需求(BusinessRequirements):它要回答的问题是“为什么要做某个项目”
  这是最高层次的、整个组织的需求
• 干系人需求(StakeholderRequirements)：它要回答的问题是“干系人想要用项目产品做什么
  这是中间层次的、每个或每组干系人的需求
• 解决方案需求(SolutionRequirements)：它要回答的问题是“项目团队必须开发出什么样的项目产品”
  这是最低层次的、技术方面的需求。为了实现商业需求和干系人需求， 项目产品必须具备的功能和特性。
  
  • 功能需求是项目产品必须实现的功能，关注项目产品能够做什么
  • 非功能需求则是用来支持功能需求的，关注项目产品能够多好地(Howwell)以及在什么条件下才能发挥既定的功能
• 过渡需求( Transition Requirements)
  临时性需求，旨在完成某系统从当前状态到未来状态的过渡。一旦过渡完成，这种需求就自动消失

除了层级上的分类，还有以下两种：

• 项目需求是对项目过程的需求，如采用什么项目管理方法，在什么时间用多大成本完成什么工作
• 质量需求是项目过程或可交付成果必须达到的质量要求

3.2.2.3 定义范围

在收集需求过程中收集到的需求，不一定都要在本项目中来实现。只有那些必须通过本项目实现的需求，才能成为定义项目范围的基础

定义范围过程就是确定哪些需求必须在本项目上实现，并基于这些需求编制项目范围说明书，明确项目边界。

• 项目范围说明书的主要内容包括：
  
  • 产品范围描述。细化项目工作说明书、 项目章程以及需求文件中的产品范围
  • 验收标准。 项目最终可交付成果必须满足的标准
  • 项目可交付成果。项目必须提交出的中间及最终可交付成果。以后还要在创建 WBS 过程中进一步细分
  • 项目除外责任。本项目必须不做什么事情。防止干系人对项目产生不合理的期望
  • 项目制约因素。细化项目章程中的制约因素，并做必要补充
  • 项目假设条件。细化项目章程中的假设条件，并做必要补充

3.2.2.4 创建工作分解结构

创建 WBS 过程就是用工作分解结构(WBS)，把项目范围说明书中的项目可交付成果细分为更小、更便于完成的可交付成果，并在此基础上形成范围基准。

如果说项目范围说明书旨在确定项目边界，那么工作分解结构就是确定边界之内有什么。

3.2.2.4.1 WBS、 WBS 词典及范围基准

可交付成果是指为完成项目而必须提交的、可核实的、可测量的项目中间或最终成果，可以是有形或无形的

• WBS 工作分解结构，顾名思义，是把整个项目逐层分解到比较小的、便于管理的要素——可交付成果
  
  • 参与者：工作分解结构的编制需要全部主要项目干系人的参与，需要项目团队成员的参与
  • 结构：工作分解结构最高层的要素，总是整个项目的最终成果。每下一个层次都是上一层次相应要素的细分，上一层次则是下一层次各要素之和
  • 结构：工作分解结构中，同一层次的各要素应该相对独立，尽量不相互交叉
  • 层数：一般情况下，工作分解结构应控制在 4-6 层。如果项目比较大，以至于工作分解结构要超过 6 层，就应该先把大项目分解成子项目（编制“项目分解结构”），再针对子项目来编制工作分解结构
  • 效用：把工作逐层分解，能提高管理的效果，但会降低管理的效率。如果分解得过细，就会导致管理工作量增加太多，导致资源的浪费
  • 工作分解结构 100%规则的要求：工作分解结构必须且只能包括100%的工作

工作分解结构在项目管理中有极其重要的作用。项目的所有规划和控制工作都必须基于工作分解结构。如果没有工作分解结构，就谈不上项目的进度计划、成本计划、质量计划、人力资源计划和风险计划等。

• 工作分解结构在项目管理中的主要作用如下：
  
  • 促使人们在尽可能早的时间，就周全地考虑项目范围，防止遗漏或多列某些内容
  • 作为基础性文件，促进项目干系人之间的沟通，使他们对项目范围有一致认识
  • 是编制项目进度计划、成本计划、质量计划等的基础。
    项目的进度、成本和质量都应该层层分别落实到工作分解结构的每个要素上
  • 是进行项目组织设计的依据之一
    应该根据工作分解结构的内容，把其中每个要素的责任落实到项目团队中的某个人或小组
  • 是进行项目执行和监控的重要依据
    应该依据工作分解结构中的内容以及在此基础上所形成的项目计划，开展项目执行并监控项目执行情况
  • 考核项目是否完工的依据
    应该依据工作分解结构所确定的可交付成果清单，来考核项目执行是否已经完成所要求的可交付成果，从而判断项目是否已经完成

• 工作分解结构是用来确定项目的总范围的，项目的全部工作都必须包含在工作分解结构之中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”；修改工作范围需要“控制范围”过程的支持
• 工作分解结构可单独列出来一个“项目管理”分支，包括项目管理计划制定等工作

• 在编制 WBS 的同时，应该编制 WBS 词典，对每个 WBS 要素进行解释

  • WBS 相当于名词汇编， WBS 词典相当于名词解释

• 编制出 WBS 和 WBS 词典后，把这两个文件连同项目范围说明书，报给高级管理层审批。经过高级管理层审批的项目范围说明书、 WBS 和WBS 词典，就是项目的范围基准

3.2.2.4.2 控制账户、规划包及工作包

• 控制账户

  • 用来进行项目范围、时间和成本等控制的，工作分解结构某个层次上的要素
  • 可以是工作包，也可以是比工作包更高层次的要素。一个控制账户中就包括几个工作包
  • 是一种管理控制点， 项目经理针对控制账户来考核项目的执行情况，即在控制账户的相应要素上，把项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差
  • 项目经理不直接关心低于控制账户的 WBS 要素的执行情况，而是授权下级直接负责
  • 通常在项目规划阶段，就要确定项目的控制账户

• 规划包

  • 在控制账户之下、 工作包之上的 WBS 要素
  • 适用场景：人们虽然已经知道它是一个什么样的成果，但是尚不清楚究竟要做哪些具体的活动，才能把该成果提交出来。此时，由于还无法分解出编制详细进度计划所需的进度活动，规划包只是暂时用于方便项目计划编制工作。随着情况的明朗，规划包最终将被分解成工作包以及相应的进度活动。
  • 规划包不能直接付诸执行，而必须先拆分为工作包

• 工作包

  • 工作分解结构每条分支底层的要素（没有子要素的要素）
  • 工作包只是在当前的“创建工作分解结构过程”中不能再度分解，但是在其他过程中细分为进度活动
  • 关于多大的可交付成果可以作为工作包，并没有标准答案。通常，按两周的间隔来检查项目实施情况，有利于对项目的有效控制——-80 小时法则（每天工作 8 小时，每周工作 5 天）

• 某个可交付成果，如果具有下列特征之一，就可以被当做工作包：

  • 规模较小，可以在短时间内完成。
  • 从逻辑上讲，不能再分了。
  • 所需资源、时间、成本等已经可以比较准确地估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制。
  • 准备把这部分工作外包出去，而且希望由承包者来继续细分

3.2.2.5 确认范围

• WBS 所列的每个可交付成果，在完成之后，都要及时进行质量合格性核实（ 控制质量过程），及时进行验收（确认范围过程）
  
  • 确认范围Validation与控制质量Verification是不同的，前者注重的是可交付成果的可接受性，而后者注重的是可交付成果的正确性（符合质量要求）
  • 通常是控制质量在前，确认范围在后；控制质量过程的输出之一“核实的可交付成果”，是确认范围过程的输入
  • 确认范围过程是项目团队邀请项目发起人和客户来做的; 控制质量过程是项目团队内部的工作

确认范围过程是由项目发起人、客户和其他主要干系人正式验收已经完成的，并已被核实为质量合格的可交付成果。

3.2.2.6 控制范围

控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比较，发现偏差，分析偏差，提出解决偏差的建议。

通过控制范围过程，防止范围蔓延，管理范围基准变更。

• 虽然控制范围与确认范围过程都是监控过程组的过程，但它们的差别很大。
  
  • 控制范围是由项目团队在可交付成果的完成过程中开展的。
  • 确认范围是由项目发起人或客户在可交付成果完成之后开展的

范围审查( Scope Review)与范围确认、范围控制．也是不同的。范围审查不是 PMBOK 指南中的专业术语，但可以用来指对项目范围计划的审查

3.2.3 输入输出

【图3.2.3.1】

项目范围管理各过程的输入输出之间的关系可以概括为如图3.2.3.1 所示（未考虑事业环境因素、组织过程资产和各种更新）

• 规划范围管理。
  
  • 在项目章程的指导之下， 参考项目管理计划中已有的子计划，编制范围管理计划和需求管理计划
• 收集需求
  
  • 在项目章程的指导之下，根据范围管理计划和需求管理计划，收集干系人的需求。
  • 应该收集哪些干系人的需求，要看干系人登记册。
  • 干系人应如何参与收集需求过程，要看干系人管理计划。
  • 收集来的需求，必须记录下来，形成需求文件，同时编制需求跟踪矩阵
• 定义范围
  
  • 在项目章程的指导之下，根据范围管理计划和需求文件，编制项目范围说明书
• 创建 WBS
  
  • 根据范围管理计划、 需求文件和项目范围说明书，编制WBS 和 WBS 词典，并进而形成项目的范围基准
• 确认范围
  
  • 根据项目管理计划中的验收程序， 需求文件中的验收标准，以及需求跟踪矩阵中的验收方法，基于工作绩效数据，对已核实的可交付成果进行验收
  • 验收工作中会形成相关资料，即工作绩效信息。
  • 如符合验收标准，就得到“验收的可交付成果”。
  • 如不符合验收标准，就提出变更请求
• 控制范围。
  
  • 把体现在工作绩效数据中的项目范围实际绩效，与体现在项目管理计划、 需求文件和需求跟踪矩阵中的计划要求，做比较，得到工作绩效信息
  • 如果绩效偏差太大，就提出变更请求

过程	输入	工技	输出
5.1 规划范围管理	项目管理计划、项目章程、事业环境因素、组织过程资产、	专家判断、会议	范围管理计划、需求管理计划
5.2 收集需求	范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册	访谈、焦点小组、引导式讨论、群体创新技术、群体决策技术、问卷调查、观察原型法、标杆对照、系统交互图、文件分析	需求文件、需求跟踪矩阵
5.3 定义范围	范围管理计划、项目章程、需求文件、组织过程资产	专家判断、产品分析、备选方案生成、引导式研讨会	项目范围说明书、项目文件更新
5.4 创建工作分解结构	范围管理计划、项目范围说明书、需求文件、事业环境因素、组织过程资产	分解、专家判断	范围基准、项目文件更新
5.5 确认范围	项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据	检查、群体决策技术	验收的可交付成果、变更请求、工作绩效信息、项目文件更新
5.6 控制范围	项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产	偏差分析	工作绩效信息、变更请求、项目计划更新、项目文件更新、组织过程资产更新

3.2.4 工具和技术

下面对除专家判断之外的工具与技术，进行简单讨论

3.2.4.1 规划范围管理 2

编制计划，通常都需要召开“规划会议”

项目经理需要邀请相关项目团队成员和主要项目干系人，召开会议，来讨论项目范围管理计划、 需求管理计划的编制。

3.2.4.2 收集需求 11

• 【访谈】：直接询问干系人需要什么。有效的访谈，需要事先准备访谈提纲。访谈可以是一对一、一对多、多对多或多对一的。但是，多对多、多对一的访谈，较少使用

• 【焦点小组】：这是一对多的群体访谈，通常有 6—10 个被访谈者（形成一个焦点小组）参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的、焦点小组的集体意见。参加者通常是同一个领域的主题专家，都熟悉作为会议主题的、某个特定的领域

• 【引导式研讨会】:主持人引导下的研讨会，通常邀请各主要项目干系人派代表参加，共同定义需求.

  • 【联合应用开发】
    联合应用开发是软件开发行业常用的引导式研讨会，强调由用户与项目开发团队一起共同定义需求
  • 【质量功能展开】
    质量功能展开在制造行业的新产品研发项目中很常用。
    它是把用户需求转化成产品功能的结构化方法（通常用矩阵表格的形式），以便开发出最能满足用户需求的那些功能
    首先把用户的多种需求（如方便性、安全性、价格便宜等）及其相对重要性（权重）列为矩阵表的第一列，其次把产品可能的多种特性（功能）列为矩阵表的第一行，然后再由相关专家集体讨论每种特性与每种需求之间的关联性（每种特性能满足每种需求的程度），并记录在矩阵表相应的空格中；最后，按列加权（考虑需求的重要性）汇总，得出产品功能的优先级排序
  • 【用户故事会】
    参会者一起创建关于干系人需求的故事
    故事通常由三部分构成：干系人的角色，干系人想要什么（需求），干系人为什么想要它（想用它获得什么利益）

• 【群体创新技术】
  通过群体的集思广益活动，来明确产品和项目需求

  • 【头脑风暴】
  • 【名义小组技术】: 更加结构化的头脑风暴法
  • 【概念／思维导图】:把头脑风暴中得到的各种主意联系起来
  • 【亲和图】:依据各种主意之间的相似性对头脑风暴中得到的各种主意进行分类
  • 【多标准决策分析技术】:指做决策时必须考虑多重相互矛盾的标准。可以建立矩阵表格，基于多重标准，做出决策

• 【群体决策技术】：基于许多人的共同讨论来做决策的技术，包括所有人一致同意、超过50%的大多数同意、不足 50%的相对多数人同意，以及在众人讨论的基础上由某一个人（独裁者）做出决定

• 【问卷调查】：用事先设计好的问卷调查表进行调查

• 【观察】可以是旁站式观察：观察者以外人的身份观察干系人有什么需求。也可以是参与式观察：观察者亲自体验做某事，来了解干系人的需求
  观察更适合用于了解干系人的较深层次的甚至他们自己都不知道的需求

• 【原型法】：通过开发原型，由干系人试用原型并提出反馈意见的方法，来逐渐明确干系人的需求。

• 【标杆对照】：用可比项目的最佳实践作为标杆，来确定本项目的需求。
  可比项目可以来自项目执行组织内部或外部，也可以来自本行业内部或外部

• 【系统交互图】：把某个系统置于大背景中，用图形直观地展示该系统与其他系统之间的接口关系。例如，该系统从哪里获得输入，又会向哪里输出什么，该系统与周围环境是什么关系

• 【文件分析】：从各种文件中识别干系人的需求

3.2.4.3 定义范围 4

• 产品分析
  确定项目产品应该具备的功能，即明确产品范围
• 备选方案生成
  设计可以用来实现既定产品功能的不同方案，即明确可供选择的项目范围
• 引导式研讨会
  引导项目干系人就产品功能和项目方案达成一致意见

3.2.4.4 创建工作分解结构 2

利用分解技术，把项目分解成较小的可交付成果和相关工作

• 分解可按下面几个步骤进行
  
  • 识别项目的全部可交付成果。应该用多种方法识别可交付成果，防止遗漏
  • 分析可交付成果之间的从属关系，确定 WBS 的编排方式
  • 把可交付成果从大到小、按隶属关系排列
  • 建立 WBS 编号系统，对每个 WBS 要素编号
  • 自下而上检查工作分解是否符合 100%规则，做必要修改

对于不产出可交付成果的辅助性工作，如 WBS 中的项目管理分支，可参照上述步骤分解，然后合并到可交付成果的分解结构中，得到完整的工作分解结构

3.2.4.5 确认范围 2

在对已完成的可交付成果进行实地检查的基础上，用群体决策技术，来决定可交付成果能否通过验收

3.2.4.6 控制范围 1

在对已完成的可交付成果进行实地检查的基础上，用群体决策技术，来决定可交付成果能否通过验收

3.2.5 其他

用于描述项目范围的主要文件包括（按编制的先后顺序排列） ：

• 启动阶段
  
  • 项目工作说明书（有初步的产品范围，没有项目范围）
  • 项目章程（有产品范围和初步的项目范围）
• 规划阶段
  
  • 需求文件（是进一步确定项目范围的基础）
  • 需求跟踪矩阵（用来追踪项目范围和产品范围实现情况）
  • 项目范围说明书（有产品范围和项目范围）
  • 工作分解结构（只有项目范围）
  • 工作分解结构词典（只有项目范围）
  • 范围基准（经过批准的项目范围）
  • 采购工作说明书（即将外包的工作的范围说明书）

• 执行阶段

  • 合同工作分解结构（外包工作的 WBS）

• 另外，还有两个与范围管理直接相关的文件，即需求管理计划和范围管理计划。它们是项目管理计划的重要组成部分

• 项目范围说明书、工作分解结构和工作分解结构词典又联合构成项目的范围基准，作为项目执行过程中用于绩效考核的比较基础

各种范围文件(除了分解结构)，都会包含除了范围之外一些信息

• 价值工程和价值分析
  都是要追求性价比最优。
  
  • 价值工程是在产品设计定型前的设计阶段使用的，可以既改变产品的功能，又改变产品生产的成本。也就是说，分子（性能）分母（成本）可以同时变，追求比值最大。
  • 价值分析则是在产品设计定型之后的产品生产阶段使用的。由于设计已经定型，所以产品功能不能变（分子不能变），只能通过降低生产成本（分母），来提高比值