项目管理知识体系十大范围领域内容

5.项目范围管理

● 5 范围管理

● 考点分析

●

● 常考内容

●

产品范围的含义小于项目范围WBS是对可交付物的分解，而不是项目工作本身的分解

●

先验收后收尾，项目收尾的时候客户就已经验收完了，收尾是以移交为标志，收尾之前验收已经结束了，验收属于监控

●

ITO-1

●

● 记忆-

● 规划范围管理：业主两项工作；转会；需饭

● 收集需求：范围需要干项目人干；焦点访谈引二群问官员标系文；二需

● 定义范围：项目范围需要组织；专产备引；两项

● 创建WBS：项饭需施组；专分；项饭

● 确认范围：项目需要两次核实工作；群检；项目变更验收工作

● 范围控制：项目需要两次组织工作；偏差；项工变项组

● ITO-2

●

● ITO-3

●

● 4W1H

●

● 5.1 范围管理概述

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

● 明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。

● 对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。杜绝做额外工作。

● 防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。

● 产品范围与项目范围。

●

产品范围是指

产品或者服务所应该包含的功能，

项目范围是指

为了能够交付产品，项目所必须做的工作。

● 产品范围是项目范围的

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

基础。

● 项目的范围基准

是经过批准的项目范围说明书、WBS和WBS词典。

● 判断项目范围是否完成，

要以范围基准来衡量。而产品范围是否完成，则根据

产品是否满足了产品描述来判断。

● 产品范围变更后，首先受到影响的是项目的范围。产品范围发生变化，并不意味着项目范围就会跟着变化。

●

范围管理的ITO

● 5.2 规划范围管理

● 规划范围管理概念

● 是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。

● 其主要作用是在整个项目中对如何管理范围提供指南和方向。

● 5.2.1 范围管理计划

● 范围管理计划用于下列工作的管理过程做出规定，包含的内容为：

● 如何制订项目范围说明书。

● 如何根据范围说明书创建 WBS。

● 如何维护和批准WBS。

● 如何确认和正式验收已完成的项目可交付成果。

● 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。

● 总结及认知

● 项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。可以是详细的或者概括的，可以是正式的或者非正式的。

● 5.2.2 需求管理计划

● 基本概念

●

需求管理贯穿于整个过程。它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即

建立需求基线。

● 还要

建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

● 需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。

● 需求管理计划是对项目的需求进行定义、确定、记载、核实管理和控制的行动指南。

● 需求管理计划包括如下内容：

● 1）如何规划、跟踪和汇报各种需求活动。

● 2）需求管理需要使用的资源。

● 3）培训计划。

● 4）项目干系人参与需求管理的策略。

● 5）判断项目范围与需求不一致的准则和纠正规程。

● 6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。

● 7）配置管理活动

● 5.3 收集需求

● 基本概念

● 收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围奠定基础。

● 5.3.1 需求的分类

● 业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。

● 干系人需求：是指干系人或干系人群体的需要。

● 解决方案需求：是为满足业务需求和干系人需求。

● 过渡需求：从当前状态过渡到将来状态所需的临时能力，例如，数据转换和培训需求。

● 项目需求：项目需要满足的行动、过程或其他条件。

● 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。

● 5.3.2 收集需求的工具与技术

● 访谈：访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。

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

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

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

● 头脑风暴——又称为智力激励法、自由思考法或集思广益法，可产生尽可能多的设想的方法。

● 名义小组技术——通过

投票来

排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。

● 德尔菲技术——是

一种组织专家就某一主题达成一致意见的一种信息收集技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持

匿名状态。关键词：匿名、背靠背；几轮测试；有助于减轻数据的偏倚，防止任何个人对结果产生不恰当的影像。

● 思维导图——又称为心智图，是将从头脑风暴中获得的创意，

用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

● 亲和图——又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，

通过图解方式进行汇总。使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。

● 多标准决策分析——是

借助决策矩阵，用系统分析方法建立诸如

风险水平、不确定性和价值收益等多种标准，从而对众多方案进行

评估和排序的一种技术。

● 群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。可用来开发产品需求，以及对产品需求进行归类和优先排序。

● 一致同意

● 一致同意。所有人都同意

● 大多数原则。50%以上的人的支持

● 相对多数原则。针对某个方案相对多数者同意

● 独裁。一个人为群体做出决策。

● 问卷调查是指通过设计书面问题，向为数众多的受访者快速收集信息。

● 观察是指直接观察个人在各自的环境中如何开展工作和实施流程。

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

● 标杆对照将实际或计划的做法与其他类似组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。

● 系统交互图是范围模型的一个例子，它是对产品范围的可视化描述，显示系统与参与者之间的交互方式。

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

● 5.3.3 需求文件

● 需求文件描述各种单一的需求将如何满足与项目相关的业务需求。需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

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

● 5.3.4 需求跟踪

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

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

● 需求跟踪的内容

● 每个配置项的需求到其涉及的产品需求都要具有双向可跟踪性。所谓双向跟踪，包括

正向跟踪和

反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。

●

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

● 图左半部分表明，从用户原始需求可向前追溯到需求文件，也确保了需求文件中包括所有用户需求。

● 可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。

● 图右半部分表明，通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。

● 第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。

● 第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。

● 需求跟踪矩阵

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

● 有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。

●

需要跟踪的内容包括一下方面：

● 业务需求、机会、目的和目标。

● 项目目标。

● 项目范围。

● 产品设计

● 产品开发。

● 测试策略和测试场景。

● 高层级需求到详细需求

●

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。另外，为了确保干系人满意，可能需要增加一些补充属性，例如，稳定性、复杂性和验收标准等。

● 5.4 定义范围

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

● 5.4.1 定义范围的工具与技术

● 产品分析是一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。

● 备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。

● 5.4.2 项目范围说明书

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

● 范围说明书的内容

● 产品范围描述。

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

● 可交付成果。

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

● 制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。

● 假设条件。

● 范围说明书的作用：确定范围、沟通基础、规划和控制依据、变更基础、规划基础。

●

5.5

创建工作分解结构

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

● 5.5.1 WBS的层次

● 1.里程碑。里程碑标志着某个可交付成果或者阶段的正式完成。

● 2.工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分。

● 工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。

● 8/80规则建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时。

● 3.控制账户是一种管理控制点。

● 控制账户是一种管理控制点。在该控制点上，将范围、预算、实际成本和进度加以整合，并将它们与挣值进行比较，以测量绩效。

● 控制账户是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。

● 项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。

● 4.规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。

● 规划包是在控制账户之下、工作包之上的WBS要素。

● 随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

● 5.WBS 词典它是描述WBS各组成部分的文件。WBS的每个部分赋予一个账户编码标志符

● WBS词典也称为WBS词汇表

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

● 5.5.2 分解

● 分解如何进行：

● 识别和分析可交付成果及相关工作。

● 确定WBS的结构和编排方法。

● 省而下路层细化分解。

● 为WBS组件制定和分配标识编码。

● 核实可交付成果分解的程度是恰当的。

●

分解的原则

● 分解原则

● 功能或者技术原则——在创建WBS时，需要考虑将不同人员的工作分开。

● 组织结构——职能型项目组织而言，WBS也要适应项目组织的结构形式。

● 系统或者子系统——总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。

● 分解的方式

● 项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。

● 主要可交付成果作为第二层。

● 整合可能由项目团队以外的组织来实施的各种组件，然后作为外包工作一部分，由卖方编制相应的WBS。

●

工作过程

● WBS不是某个项目团队成果的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。

● 较常用的WBS表示形式主要有分级的树型结构和表格形式。

● 树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。

● 表格形式的WBS的直观性比较差，但能够反映出项目所有的工作要素。

● 有些参考文献也使用鱼骨图形式的WBS，但这种形式并不常用。

●

注意事项

● WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。

● WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动。100%原则认为，在WBS中，所有下一级的元素之和必须100%的代表上一级元素。

● WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。

● WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。

● WBS的指导。作为指导而不是原则，WBS应控制在4~6层。如果超过6层的大项目可分解成子项目，然后针对子项目来做WBS。

● WBS应包括项目管理工作，也要包括分包出去的工作。

● WBS的编制需要所有项目干系人的参与，需要项目团队成员的参与。

● WBS并非是一成不变的。有可能需要对WBS进行修改，既滚动分解原则。

● 5.3.3 WBS的作用

● WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识，然后才能据此进行时间估算和成本估算。

● WBS的目的和用途主要体现在以下8个方面。

● 明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。

● 清楚地定义项目的边界

● 为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。

● 针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。

● 为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。

● 将项目工作和项目的财务账目联系起来。

● 确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。

● 有助于防止需求蔓延。

● 5.6 确认范围

● 确认范围是正式验收项目已完成的可交付成果的过程，其主要作用是使验收过程具有客观性，同时，通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。

● 5.6.1 确认范围的概述

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

● 确认范围的步骤

● 确定需要进行范围确认的时间。

● 识别范围确认需要哪些投入。

● 确定范围正式被接受的标准和要素。

● 确定范围确认会议的组织步骤。

● 组织范围确认会议。

● 需要检查的问题

● 可交付成果是否是确定的、可确认的。

● 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。

● 是否有明确的质量标准，

● 审核和承诺是否有清晰的表达。

● 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。

● 项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

● 5.6.2 干系人的关注点

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

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

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

● 项目团队成员主要关心项目范围中自己参与的元素和负责的元素。

● 5.6.3 几个术语的比较

● 确认范围与核实产品

● 核实产品是针对产品是否完成，在项目结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。

● 确认范围与质量控制

● 确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求。

● 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。

● 质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人对项目可交付成果进行检查验收。

● 确认范围与项目收尾

● 确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目所要做的流程性工作。

● 确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。

● 5.7 控制范围

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

● 范围变更的原因

● 主要常见原因

● 政府政策的问题。

● 项目范围的计划编制不周密详细，有一定的错误或遗漏。

● 市场上出现了或是设计人员提出了新技术、新手段或新方案。

● 项目执行组织本身发生变化。

● 客户对项目、项目产品或服务的要求发生变化。

● 未经控制的产品或项目范围的扩大称为范围蔓延。

● 变更是不可避免的，

● 范围变更控制包括书面文件、跟踪系统和授权变更所必须的批准级别。

● 范围变更控制工作

● 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。

● 判断范围变更是否已经发生。

● 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。