信息系统管理师 项目范围管理.docx

《信息系统管理师 项目范围管理.docx》由会员分享，可在线阅读，更多相关《信息系统管理师 项目范围管理.docx（23页珍藏版）》请在三一办公上搜索。

1、 第六章 项目范围管理 项目范围管理，包括为成功完成项目所需要的一系列过程，以确保项目包含且仅仅只包含项目所必需完成的工作。范围管理首先要定义和控制在项目内包括什么、不包括什么。本章的主要内容包括：6.1 范围计划编制：制定一个项目管理计划，以规定如何被定一、检验、控制范围、创建与定义工作分解结构WBS。6.2 范围定义：编制一个详细的项目范围说明书作为将来项目决策的基础。6.3 创建工作分解结构WBS：将项目的主要可交付成果和项目工作细分为更小、更易于管理的部分。6.4 范围确认：正式接受已完成的项目范围。6.5 范围控制：控制项目范围变更。图6.1 是一个范围管理过程的流程图，表达了这些过

2、程和他们的输入、输出，以及与其他知识领域过程之间的关系。这些过程之间及其与其他领域的过程之间彼此互相影响。根据项目需要，每个过程可能会需要一个或多个个体或团体的努力。一般来说，在每个项目阶段，每个过程通常至少发生一次。尽管这里提到的这些过程是作为各自独立的组成部分给予明确的界定，但是，在实践中他们是各种形式重叠和相互影响的。在项目的背景下，范围这个术语可以指：l 产品范围：表示产品或服务的特性和功能。产品范围包含产品规格、性能技术指标的描述，即产品特征和具体功能。l 项目范围：为了完成具有所规定特征和功能的产品必须完成的工作。本章的重点是管理项目范围和产品范围所用的过程。这些过程以及关联的工具

3、和技术随应用领域而变化，通常作为项目生命周期定义的一个组成部分，被编制成文档列在范围管理计划中。一个项目通常会产生一个产品，这个产品可以包括若干个从属部分，这些从属部分又有其各自独立又项目依赖的产品范围。如：一个电信系统包括四个从属部分：硬件、软件、培训和实施。项目范围是否完成以项目管理计划作为衡量标准，而产品范围是否完成以产品需求作为衡量标准。两种范围管理需要很好的集成起来，以确保项目工作能产生所规定的产品标准并准时交付。项目的几个生命周期阶段和管理过程，项目的一次性及临时性，共同决定了项目的工作范围都是有限的、可控的，不是无限制和无序的。项目范围的定义可以是广义的，也可以是狭义的，根据项目

4、不同管理层需要，再集中结合应用项目的特点进一步阐述。既然完成项目工作范围是为了实现项目目标，那么如何有效的、全部的完成项目范围内的每项工作，是我们每个项目管理者不得不思考的问题。因此对项目范围管理及控制的有效性，是衡量项目是否成功的一个必要标准，项目范围管理不仅是项目管理计划的一个主要部分，同时在项目中不断地重申项目工作范围，有利于项目不偏离轨道，是项目中实施控制管理的一个主要手段。项目范围管理不仅是让项目管理和实施人员知道为达到预期目标需要完成哪些具体的工作，还要清除项目相关各方在每项工作中清晰的分工界面和责任。详细、清楚地界定分工界面和责任，不但利于项目实施中的变更管理和推进项目发展，减少

5、责任不清的事情发生，也便于项目结束时项目范围清晰的确认。如一个ERP（企业资源计划）项目有网络设备、小型机等，供货商提供设备和安装，客户提供项目实施场所，服务商负责软件开发和各项应用实施，到底每一方要完成哪些工作，这些工作彼此间的界限如何（含时间界限）要确认的很清楚，一旦其中一个系统出现工期延迟现象，便可以很快找到具体责任人并及时提供解决方案。项目范围的来源，一般而言是项目投资方或客户的一个明确的项目目标或具体需求，任何一个项目的建设都有其明确的目的（或目标），因此在讨论项目范围管理的时候，不可能脱离项目的目标，但项目的目标只是项目范围计划编制的一个基础依据，不能作为项目范围的一个具体细化的工

6、作范围部分。项目范围的“圈定”，并不能代表项目范围就是可控制的。因此要进一步对项目范围定义，实际就是对项目工作范围进一步细化的过程，使项目范围具体化、层次化、结构化，从而达到可管理、可控制、可实施的目的，减少项目风险。在项目范围管理过程中，最常用，也是必须要熟悉的工作分解方法是工作分解结构WBS。 WBS是一种以结果为导向的分析方法，用于分析项目所涉及的工作，所有这些工作构成了项目的整个工作范围。WBS为项目进度、成本、变更得计划和管理提供了基础。制定工作分解结构的主要方法包括：使用指导方针、类比法、自上而下和自下而上法等。 项目范围确认是指项目干系人对项目范围的正式承认，但实际上项目范围确认

7、是贯穿整个项目生命周期，从开始项目管理组织确认WBS的具体内容，到项目各个阶段的交付物检验，直至最后项目收尾文档验收，甚至是最后项目评价的总结。项目范围变更控制实际发生在项目实施阶段，也就是计划执行阶段，只有具体实施项目，才有可能产生项目范围的变更，因为项目环境、资源水平和管理能力等因素会造成项目范围在实施过程中的增加或减少。对项目范围变更控制的主要工具是建立并运用项目变更控制系统，规范变更控制，划清相关责任。往往由于多种因素造成项目需求的模糊和不断的更改，从而给项目增加了控制难度和很大的风险，因此，这就更需要项目管理者发挥其应有的能力和作用，做好项目的控制工作和管理工作。项目范围管理水平的低

8、下是项目失败的主要因素之一。要实现高水平的项目范围管理，重点要做好用户参与、明确的要求以及范围变更管理的程序设置等。确认项目范围对项目管理而言有如下意义：l 清楚了项目的具体工作范围和具体工作内容，为提高费用、准确估算时间和资源性打下基础。l 项目范围是确定要完成哪些具体的工作，项目范围管理和控制是项目管理计划的一部分，也是项目各项计划的基础，因此项目范围计划编制是确定项目进度测量和控制的基准。l 项目范围的确定就是确定了项目的具体工作任务，这样有助于清楚地划分责任和分派任务，为进一步安排工作和任务打下了基础。对于项目管理者而言，只清楚项目范围的含义还是不够的，最重要的是正确、清楚地定义项目范

9、围，如果项目范围确定的不好，直接关系到项目工作内容的意外变更，有可能造成最终项目费用的提高、进度严重延迟，偏离了原定项目目标，影响了整个项目发展和项目团队成员的积极性。6.1 范围计划编制定义和管理项目范围影响到整个项目的成功与否。每个项目要求在工具、数据源、方法论、过程和程序以及一些其他因素之间取得稳妥地平衡性，以此确保在项目范围管理活动上所做的努力与项目的规模、复杂性和重要性相符。如：一个重要的项目需要做正式的、仔细的和时间性强的范围计划。常规项目则很少需要文档和详细审查。项目管理小组为范围管理计划决策编写文档。范围管理计划是一个计划工具，用以描述该团队如何定义项目范围，制定详细的范围说明

10、书，定义和编制工作分解结构，验证和控制范围。项目管理团队在编制计划时，需要联系实际工作考虑限制或制约自己行动的各种各种因素。如，准备采取的行动是否有可能违背本组织的既定方针，某些活动之间是否存在必然的联系等。6.1.1 范围计划编制的输入项目范围计划编制，需要合理的、有效的工具，才能制定出指导项目顺利进行的范围管理计划。一般而言项目范围管理计划编制，需要项目合同、初步的项目范围说明书、组织过程资产、环境和组织因素以及初步的项目管理计划。（1） 项目章程（2） 项目范围说明书（初步）（3） 组织过程资产组织过程资产是会影响如何进行项目范围管理的正式和非正式的政策、规程和指导方针。在项目规划时应特

11、别关注的是：l 适合于范围计划编制的组织政策。l 与范围计划编制和管理相关的组织和流程l 可用来在当前项目规划过程中作参考的过去项目形成的历史信息（4） 环境因素和组织因素环境和组织的因素包括关于当前组织的文化、组织基础结构、工具、人力资源、人事政策和市场条件等能够影响范围管理的信息。（5） 项目管理计划6.1.2 范围计划编制的工具和技术保证一个项目管理计划的合理性，必然需要合理、科学的分析方法和技术支持，对于项目范围计划编制所使用的工具与技术，主要有：1. 专家判断专家判断可用于制定详细的范围说明书、工作分解结构和范围管理计划。2. 模板、表格和标准模板、表格和标准包括工作分解结构模板、变

12、更控制表格和范围变更控制表格。通过采用组织过程资产的模板、表格和标准，可使范围计划编制过程规范化，效率、资源都得到有效的保障。同时也说明积累组织资产的意义和价值。在项目范围计划编制过程中，不止用到以上方法，这需要根据项目的复杂程度和具体情况来确认。关键一点要把握的是，任何工具和方式都是为了帮助项目管理者合理、科学地制定项目范围管理计划。不论是一个办公室自动化项目，还是复杂的全国性网络搭建和应用开发的项目。6.1.3 范围计划编制的输出1. 范围管理计划范围管理计划就项目管理团队为如何管理项目范围提供的指导。范围管理计划的组成成分包括：l 基于初步范围说明书准备一个详细的项目范围说明书的过程。l

13、 从详细的项目范围说明书创建WBS的过程。l 详细说明已完成项目的可交付物是如何得到正式的确认和认可，以及获得与之相伴的WBS的过程。l 一个用来控制需求变更如何落实到详细的项目范围说明书中的过程。这个过程直接与综合变更控制相关联。根据具体项目工作的需要，项目范围管理计划可以是正式的或非正式的、很详细的或粗略的。一个范围管理计划是包括在项目管理计划中的或者是项目管理计划的补充。项目范围管理计划是全部项目管理计划的组成要素之一。6.2 范围的定义在初步项目范围说明书中已文档化的主要可交付物、假设和约束条件的基础上准备详细的项目范围说明书，使项目成功的关键。在项目规划中，知道了更多的项目信息，项目

14、范围应被更详细地进行描述。应检查假设和约束条件的完整性，并根据需要增加必要的补充假设和约束条件。项目团队和其他对项目范围有不同见解的项目干系人，可以基于此履行和准备项目分析。6.2.1 范围定义的输入范围定义的输入包括以下内容。（1）项目章程如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。（2）项目范围管理计划（3）组织过程资产（4）批准的变更请求经核准的需求变更能引发项目质量、范围、成本或进度的变更。，变更申请常常在项目进行过程中被确认，变更申请有多种形式：口头的或书面的，直接的或间接的，外在的或内部的，法律、契约要求的活随

15、意的。6.2.2 范围定义的工具和技术1. 产品分析每个应用领域都有一些通用的方法把项目目标转变为切实的可交付的成果。产品分析包括许多技术，如产品分解、系统分析/工程学、价值工程学、价值分析和功能分析等。2. 可选方案识别可选方案识别是一种用来产生各种不同的项目工作方案的技术。在此可应用很多通用管理方法，最常用的有“头脑风暴法”和“横向思维法”。3. 专家判断法每个应用领域都有一些专家定义项目范围说明书。6.2.3 范围定义的输出范围定义工作 ，会进一步形成详细的范围说明书，以及对项目的管理计划进行更新。1. 项目范围说明书（详细） 项目范围说明书详细描述了项目的可交付物和产生这些可交付物所必

16、须作的项目工作。项目范围说明书在所有项目干系人之间建立了一个对项目范围的共识，描述了项目的主要目标，使团队能进行更详细的规划，指导团队在项目实施期间的工作，并为评估是否为客户需求进行变更或附加的工作是否在项目范围之内提供基线。详细的范围说明书直接或以引用其他文档的方式包括以下内容。l 项目范围的目标这些目标包括衡量项目成功的可量化标准。，项目可能有多种业务、成本、进度、技术和质量上的目标。项目目标包括成本、进度和质量方面的具体目标。项目目标应该有一定属性（如成本）、计量单位（如人民币）、一个绝对或相对的数值（如至多1 500 000元）。要成功完成项目，没有量化的目标（如“客户满意”）通常隐含

17、较高的风险。l 产品范围描述这一节描述了项目承诺交付的产品、服务或结果的特征。这种需求在早期很少有详细说明，在后期随着产品特征的逐渐细化会更详细。当需求的形式和实质改变的时候，他将提供充分的细节来支持后期的项目计划。l 项目边界边界严格定义了项目内包括什么和不包括什么。l 项目的可交付物可交付物包括项目的产品和附属产出物（如项目管理报告和文档）。，依靠项目敢立范围说明书，可交付物可以被描述得比较概要，也可以很详细。l 产品可接受的标准这一节定义了接收可交付物的标准。l 项目的约束条件这一节描述和列出具体的与项目范围相关的约束条件，其对项目团队的选择会造成限制。如，客户或组织发布的预算或任何强加

18、的日期（进度里程碑）都应包括在内。当一个项目按合同执行时，合同条款通常是约束条件。项目范围说明书的约束条件比项目章程中列出的约束条件更为详尽。l 项目的假定这一节描述并且列出了特定的与范围相关的假设，和这些假设被证明为假时对项目的潜在的影响。作为计划过程的一部分，项目团队经常识别、记录和确认假设。项目范围说明书中列出的假设比项目章程中列出的假设更多，更加详细。l 初始的项目组织确定团队成员和项目干系人。项目组织也被记录于文档。l 初始被定义的风险包含已知风险l 进度里程碑客户或组织给项目团队强加日期。这些日期可当作进度里程碑，在这一节应该说明或作为约束处理。l 量级成本预算项目成本估算包括项目

19、的成本、资源和历时，总是在修改之前进行估算。成本估算包括一些精确性指标，如：数量级和概念级。l 项目配置管理需求描述了为项目实现的配置管理和变更控制的水平。l 已批准的请求这一节包括任何项目干系人委托的已批准的请求。已批准的请求应用于项目目标、可交付物和项目工作中。2项目管理计划（更新）由于范围定义过程的变更会导致范围管理计划的变更，从而项目管理计划应该作相应的更新。对于项目管理计划和他的辅助计划的必要变更（补充、修改、修订）通过综合变更控制进行处理。6.3 创建工作分解结构6.3.1项目工作结构分解的目的和意义 工作分解结构WBS是面向可交付物的项目元素的层次分解，他组织并定义了整个项目范围

20、。WBS是一个详细的项目范围说明的表示法，详细描述了项目所要完成的工作。WBS的组成元素有助于项目干系人检查项目的最终产品。WBS的最底层元素是能够被评估的、安排进度的和被跟踪的。工作分解结构是组织管理工作的主要依据，使项目管理工作的基础。这些项目管理工作包括：定义工作范围，定义项目组织，设定项目产品的质量规格，估算和控制费用，估算时间周期和安排进度。因此，从某种程度上讲，工作分解结构的过程就是为项目搭建管理骨架的过程。项目的工作结构分解，对项目管理有着重要的意义。l 通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明、具体。使项目管理者

21、和项目的主要干系人，如投资人或客户，都能通过WBS把握项目、了解和控制项目的过程。l 保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在遗漏，进而达到了项目的完整性。l 通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标的要求。l 项目工作结构分解能够明确项目相关各方面的工作界面，便于责任划分和落实。l 最终工作分解结构，可以直接作为进度计划和控制的工具。l 为建立项目信息沟通系统提供依据，便于把握信息重点。l 使项目各项计划和控制措

22、施制定的基础和主要依据。工作分解结构的表示形式工作分解结构一般用图表形式表达，其形式是工作分解结构的具体表现，是实施项目、实现最终产品或服务所必须进行的全部活动的一张清单，也是进度计划、人员分配、预算计划的基础。当前较常用的工作分解结构表示形式主要有以下两种：l 分级的树形结构类似于组织结构图，如图6.2所示。树形结构图的WBS层次清晰，非常直观，结构性很强，但不是很容易修改，对于大的、复杂的项目也很难表示出项目的全景。由于其直观性，一般在一些小的、适中的应用项目中较多。l 表格形式类似于分级的图书目录该表能够反映出项目所有的工作要素，可是直观性较差。但在一些大的，复杂的项目中使用还是较多的，

23、因为有些项目分解后，内容分类较多，容量较大，用缩进图表的形式表示比较方便，也可以装订手册。6.3.2 创建工作分解结构的输入范围定以后，创建工作分解结构，前者的输出是后者的输入，包括：（1） 项目范围说明书（详细）（2） 项目管理计划6.3.2 创建工作分解结构的工具和技术这部分涉及的主要工具有分解结构模板分解技术。但实际上，工作分解结构模板更像是一个现成的工具，同时又可以作为后一种技术的结果或一个组成部分。其实，二者是相辅相成的，一个强调的是结果的使用，一个强调的是具体过程，但又可以融为一体来谈。1. 工作分解结构模板以前项目的WBS常被用于一个新的项目的模板。虽然每个项目是不同的，但大多数

24、的项目有相似之处，所以WBS能时常被重复使用。如：在一个给定的组织里大部分的项目都有相似的生命周期，从而每一个阶段需要提交相同或相似的可交付物。许多应用领域或项目执行机构都有标准的WBS模板。2001年，美国项目管理学会PMI出版了工作分解结构的试用标准工作分解结构的实践标准，对工作分解结构的产生、开发和应用提供指导。内容还包括了一些能够适用于特定工业领域的WBS示例。2. 分解进行工作分解是非常重要的工作，他在很大程度上决定项目能否成功。如果项目分解的不好，在实施过程中难免要进行修改，就会打乱项目的进程，造成返工、延误时间、增加费用等。分解是将主要项目可交付物分成更小的，更易管理的单元，直到

25、可交付物细分到足以用来支持未来的项目活动定义的工作包。依据分解得到的工作包能够可靠的估计出成本和时间进度，会有助于整个项目生命周期中的项目管理活动。分解也许不足以支持很久以后将产生的可交付物或者子产品。项目管理团队必须等待，直到可交付物或子产品被清楚定义出来。不同的可交付物使用的产品可以有不同的分解水平。为了达到易管理的目的（如一个工作包），许多可交付物使用的产品需要进一步分解。被分配到一个工作包的工作量是基于项目时间框架的。工作包的不同细化水平依据项目的大小和复杂性而变化。一般情况下，在进行工作分解的时候，可以参照以前其他相关项目的分界结构作为分解的样板对现有项目进行分解。对于某个具体的项目

26、而言，该项目的项目经理在着手进行工作分解之前应该清楚地了解项目的各方面的具体情况，以便于正确有效的进行项目分解。在进行项目工作分解的时候，一般遵循以下主要步骤。l 识别和确认项目的主要组成部分。l 分解并确认每一组成部分是否分解的足够详细。l 确认项目主要交付成果组成要素。l 核实分解的正确性。第一步：识别和确认项目的主要组成部分一般而言项目的主要组成部分是项目的主要可交付物，包括项目管理方面的可交付物和合同所要求的可交付物。然而，在现实中，这个主要可交付成果是可以根据项目的实际管理而定的。，如，项目生命期的各个阶段可以第一层次的划分，把第一层次中的项目具体内容在第二阶段继续进行划分。因为有了

27、项目主要工作任务，我们才可能进一步考虑，为完成这项任务，或实现交付成果目标，还需要进行哪些工作等。见下图6.3，是一个IT软件的项目工作分解结果。在实际应用中，我们也可以将其总目标的交付成果作为第一层次的划分，如图中的“YY管理软件系统”，而将项目管理的各个阶段表示为第二层。第二步：分解并确认每一组成部分是否分解的足够详细如何判断是否详细？ 一般来讲是至少分解到可以合理的对其进行成本和历时的估算。对每个主要成果，如果已经足够详细，则进入第四步，否则接着进入第三步这意味着不同的可交付物可能有不同的分界层次。第三步：确认项目主要交付成果的组成要素组成要素应当用有形的、可检验的结果来描述，以便据此进

28、行绩效评估。与主要交付成果一样，交付成果的组成要素的定义应该根据项目工作实际上是如何组织和完成的。有形的、可检测的结果，即可包括产品，又可包括服务。这一步要解决的问题是：要完成上述各组成部分，有哪些更具体的工作要做。对于各组成部分的更小的构成部分，应该说明需要取得哪些可以核实的结果以及完成这些更小的组成部分的先后顺序。如果我们把网络调测单独拿出，作为第一层的一部分，那么在一定意义上可以说是很详细工作，不需要再分解了；但是如果项目非常大，而且复杂，那么网络调测，可能还进一步包括广域网、局域网测试和网络管理软硬件调测等，这又需要不同技术力量给予支持。那么相应的网络测试，也应该从这三方面着手。其实，

29、在实际当中主要交付成果的组成要素，有可能可以进一步提炼交付物，进而作进一步的划分，这就是第二步体系的内容。如图中的培训，可以视培训完成，提交所有培训报告是一个交付成果，但其中包括不同的培训：网络培训、DB/OS（数据库操作系统）培训、应用培训等，可以进一步细化。第四步：核实分解的正确性核对分解是否正确，可以通过回答下列问题来确定：最底层要素对项目分解来说是否是必需而且充分的呢？ 如果不是，则必须修改组成要素（添加、删除或重新定义）；每个组成要素的定义是否清晰完整？ 如果不完整，描述泽需要修改或扩展；每个组成要素是否都能够恰当地编制进度和预算？是否能够分配到接受职责并能够圆满完成这项工作的具体组

30、织单元（如部门、项目队伍或个人）？ 如果不能，需要做必要的修改，以保证合理的管理控制。整个项目工作的分界过程可以用流程图来表示。确定各层次的组成要素时，首先是从项目的主要可交付物开始的。在确定可交付物时，是根据项目的实际管理方式来进行的。当分解完成，则要核实分解的正确性。包括四个方面，如图6.4所示。最后输出理想的分解结果。工作分解的过程，也是项目结构化和层次化的过程。在整个过程中，除了产生最终认定的工作分解结构外，同时可以根据项目的需要进一步确定子项目，通过子项目管理者做进一步细化工作，这对一些大的、复杂的项目而言是很有必要的，这样不同层次的项目管理者只对应其相应层次的工作分解结构WBS，便

31、于项目的管理。那么一个项目到底分解成几个层次是合适的，这需要根据项目的具体情况而定，但一般在35层，如果层次过多，最好将项目进一步划分为不同的子项目；如果层次太少，对于较大的项目而言，又不便于控制和管理。工作结构分解应把握的原则是：l 在各层次上保持项目的完整性，避免遗漏必要的组成部分。l 一个工作单元只能从属于某个上层单元，避免交叉从属。l 相同层次的工作单元应用相同的性质。l 工作单元应能分开不同责任者和不同工作内容。l 便于项目管理计划、控制和管理需要。l 最底层工作应该具有可比性，是可管理的，可定量检查的。l 应包括项目管理工作（因为是项目具体工作的一部分），包括分包出去的工作。如：一

32、个IT厂商，将某子项目的软件开发任务外包给其他公司，但从项目总体而言软件开发只是其中的一部分工作，并且直接影响项目的进度，因此必须将其考虑进来，这个时候分包商可以视为有法律合同约束的一个子项目团队。3. WBS编码设计为了简化WBS的信息交流过程，常常利用编码技术对WBS进行信息交换。编码设计与结构设计是有对应的关系的。结构的每一层次代表编码的某一位数，有一个分配给他的特定的代码数字。见表6.1。在表6.1中，WBS编码是由3位数字组成的，第一位数表示处于0级的整个项目；第二位表示处于第1级的子项目要素（或子项目）的编码；第三位数十处于第二级的具体活动单元的编码。编码的每一位数字，由左到右表示

33、不同的级别，即第一位代表0级，第二位代表1级，以此类推。在WBS编码中，任何等级的一位项目要素，是其余全部次一级项目要素的总和。如第二个数字代表子项目要素（或子项目），也就把原项目分解为更小的部分。于是，整个项目就是子项目的总和。所有子项目的编码第一位数字相同，而代表子项目的数字不同，紧接着后面两位数字是零。再下一级的工作单元的编码以此类推。在制定WBS编码时，责任与预算可以用统一编码数字制定出来。就职责来说，第一位数字代表责任最大者项目经理，第二位数字代表各子项目的负责人，第三和第四位数字代表2、3级项目要素的相应负责人。对于预算也有着同样的关系。编码设计对于作为项目控制系统应用手段的WBS

34、来说是个关键，不管使用者是高级管理人员何时其他层次员工，编码对于所有的人来说都应当有共同的意义。在进行编码设计时，必须仔细考虑收集到的信息和收集信息所用到的方法，使信息能够自然地通过WBS编码进入应用记录系统。在进行编码设计时，如果在一个既定层次上，应该尽量使用同一种代码使用与类似的信息，这样可以编码更容易被理解。此外，在设计编码时还应当考虑到使用者的方便，使编码以使用者容易理解的方式出现。如，在有的WBS设计中，用代码的第一个字母简单的给出其代表的意义，如用M代表人力等。6.4.3 创建分解结构的输出工作范围分解的结果就是形成工作分解结构WBS，同时完成项目范围管理计划的更新，因为实际工作分

35、解过程，也是对项目范围描述准确、清晰和合理与否的一个检验过程，如果出现偏差，应该及时更正。1. WBS 和 WBS字典工作分解结构描述的是可交付物和其组成要素的具体内容，定义了整个项目的工作范围。如果一个工作不在WBS内，那么这个工作就会被排除在项目范围之外。项目相关人员对完成的WBS应该给予确认，并对此要达成共识。工作分解结构每细分一层就表示对项目要素更细致的描述。WBS的最底层通常是指工作包。通常，在WBS中每一个工作包被指定唯一的标识，这些标识反映各级成本和资源结构。这些工作包被分解成各项活动，以便进行项目进度安排。WBS中包含的要素（包括工作包）细节通常在工作分解结构字典中加以描述。W

36、BS字典是WBS的配套文档，用来描述每个WBS元素。对每一个WBS元素，包括其工作说明、相关活动列表和里程碑列表。其他信息包括承办组织、开始日期和结束日期、资源需求、成本估算、负载量、合同信息、质量要求和提高工作质量的技术参考资料。在适当的情况下，每个WBS元素应当与WBS字典中的其他元素交叉参考。WBS不能同其他种类的表示项目信息的分解结构混淆。一些应用领域中的其他分解结构包括：l 组织分解结构WBS提供项目组织安排的层次化的有组织的描述，使得工作包同组织执行单元相关联。它用于显示各个工作元素被分配到那个组织单元。l 物料清单表述用于制造加工一个产品所需要的实际部件、组件和构件的分级层次表格

37、。l 风险分解结构是关于已识别的项目风险的层次化有组织的描述，这些风险按风险类别排列。2. 项目管理计划（更新）如果在创建WBS过程中发生变更，则项目管理计划可能需要被升级，以包括范围管理计划中的变更信息。项目管理计划和辅助计划中被请求的变更（补充、修改、修订）通过整体变更控制来处理。在制定WBS时，对于发现的针对项目范围的缺乏合理性和正确性的情况下，应该给予及时更正，修改项目范围说明书和相应的范围管理计划。根据实际需要，必须通知相关的项目干系人。6.4 范围确认范围确认是项目干系人（发起人、客户和顾客）正式接受已完成的项目范围的过程。范围确认需要审查可交付物和工作成果，以保证项目中所有工作都

38、能准确、满意地完成。项目范围确认应该是贯穿项目的始终，从WBS的确认（或合同中具体分工界面的确认），到项目验收时范围的检查。如果项目被提前终止，范围确认过程应该以书面文件的形式把它的完成情况记录下来。范围确认和质量控制不同，范围确认是有关工作结果的接受问题，而质量控制是有关工作结果正确性的审核。这些过程一般并行，以确保可接受性和正确性。6.4.1 范围确认的输入1. 项目范围管理计划2. 可交付物可交付物是那些已经被完全或部分完成的部分，并且是指导和管理项目执行过程的输出结果，是项目或项目某阶段的部分或全部的可交付成果，当然也可能是客户或上层管理比较关注的里程碑事件完成结果。3. 项目范围说明

39、书项目范围说明书详细描述了将被审查的项目产品的产品范围。4. WBS和WBS字典WBS和WBS字典用于范围的定义和确认项目进行中的工作成果是不是项目的一部分。6.4.2 范围确认的工具和技术对于项目经理或项目管理人员来说，可以通过“检查”来实现范围的确认。检查包括测量、测试、检验等活动以判断结果是否满目项目干系人的要求和期望，检查也可被称为审查、产品评审和走查等。在某些应用领域，这些不同的词有他自己的使用范围和特定的含义。如：在软件开发项目中，经常会有客户要求的回归测试的过程，其中很多时候往往不是质量问题，而是由于前期确认的相关需求内容没有实现或满足客户需求。项目范围确认时，项目管理组织必须向

40、客户方出示能够明确说明项目（或项目阶段）成果文件，如项目管理文件（计划、控制、沟通）、技术需求说明书、技术文件、竣工图纸等。当然，提交的验收文件应该是客户已经认可了这个项目产品或某个阶段的文件，他们必须为完成这项工作准备条件，做出努力。像这种验收可能是有条件的，尤其是在一个阶段结束的时候。范围确认完成时，同时应当对确认中调整的WBS及WBS字典进行更新。6.4.3 范围确认的输出1. 确认后的范围确认后的范围包括被客户或项目发起人接受的文档，或项目交付成果的认可证明。这种接收是有条件的，特别是在某个阶段的结束点上。2. WBS和WBS字典（更新）WBS和WBS字典帮助定义范围，依据范围确认过程

41、的结果要进行相应的更新。6.5 范围控制范围控制涉及到以下内容：影响范围变更的因素，确保所有被请求的变更按照项目综合变更控制处理，范围变更发生时管理实际的变更。范围控制与其他控制过程完全结合。未控制的变更经常被看作范围溢出。变更应当被视作不可避免的，因此要颁布一些类型的变更控制过程。项目范围的变化，在实际项目中经常发生，因此对项目范围的变更控制和管理，是当前项目管理控制中的重点工作之一。很明显的例子，由于多方面原因导致项目的需求无法及时确定，项目范围后期变更太多、成本压力太大，使得很多研发项目和应用项目以失败告终。当然，有些时候项目变更时对项目有利的，甚至大大促进了项目的实施。变更是项目干系人

42、常常由于项目环境或者是其他的各种原因要求而对项目的范围计划进行修改，甚至是重新规划，而这一类修改后变化就叫做变更。项目范围的变更控制、管理是对项目中存在的或潜在的变化采用正确的策略和方法成功地处理他。1. 变更产生的原因项目管理必须对变更进行控制管理。一般情况下，造成项目范围变更的原因很多，主要有：l 项目外部环境发生变化，如政府政策的问题。l 项目范围的计划编制不周密详细，有一定的错误和遗漏，如：在设计语音数据处理系统时没有考虑到计算机网络的承载流量问题。l 世界上出现了或是设计人员提出了新技术、手段或方案。在项目实施过程中，常常会出现制定范围管理计划时尚未出现的，可以大幅度降低成本的新技术

43、。l 项目实施组织本身发生变化。如：由于项目所在单位同其他单位合并或是出现了其他情况，项目班子成员组织发生变化。l 客户对项目、项目产品后服务的要求发生变化。2. 变更控制的焦点问题许多情况下，项目管理者在进行范围变更控制时，更关心的问题是：l 对造成范围变更的因素施加影响，以确保这些变更得到更一致的认可。l 确定范围变更已经发生。l 当范围变更发生时，对实际的变更进行管理。6.5.1 范围控制的输入1. 范围管理计划范围管理计划是范围控制的主要依据。2. WBS和WBS字典WBS和WBS字典定义项目的范围基线。WBS的制定完成，是需要项目相关干系人确认的，确认后的WBS体现的具体工作，将成为

44、项目范围的一个基准参考，范围的任何变更都要以此为依据，加以比较分析，得出变更的结论。3. 绩效报告绩效报告提供项目绩效信息，如已经完成的中间可交付成果。绩效报告是直接可以反映当前项目执行情况的文件，可以从项目范围相关的绩效报告中获得范围绩效的信息，以此来作为项目变更控制的一个依据，如，中间产品（或服务）已经完成、哪些还没有完成、关注的几个工作的当前执行情况等。同时，绩效报告也能提醒项目管理团队预测项目的未来性，把握项目范围变更控制的风险。4. 工作绩效信息变更工作基于目前已经完成的工作，是整体关联的，基于发生的工作进行变更控制。5. 比准的变更需求范围变更是对达成一致的、WBS定义的项目范围的

45、修改。已经接受的范围变更经常需要调整成本、时间、质量、进度以及其他项目目标。在项目实施过程中，可能由于项目环境的变化，项目前期工作的过失，项目额外工作的增加，甚至是WBS制定的错误等都有可能造成项目的变更，影响到项目范围的增大和减少。变更形式有多种，书面的、口头的、直接的、间接的、外部的、内部的等，有些变更根据需要是强制性的。6.5.2 范围控制的工具和技术1. 变更控制系统在项目范围管理计划文档中描述的范围变更控制方法是定义项目范围变更的有关流程。它包括必要的书面文件（如变更申请表）、跟踪系统和授权变更的批准等级。变更控制系统与其他系统相结合，如配置管理系统，控制项目范围。当项目受合同约束时

46、，变更控制系统应当符合所有相关合同条款。具备了合理的变更控制系统，可以减少项目中盲目的变更，降低变更的随意性。特别是IT行业，许多需求很多时候会因为客户随着理解的改变和随时发生变化，如果没有变更正式的书面确认过程和有效的控制系统来规避相关事件，项目的范围（需求）将与项目初始确认大相径庭，从而使项目无法控制。变更控制系统，不是死板的，应该是灵活的。在项目管理中，可以根据具体情况设立不同的控制点，有些没有必要通过流程解决的变更，可以授权现场实施负责人或团队成员完成。但有些项目范围的变更，如直接关系到项目成本和进度增加的变更，一定要通过变更控制系统来解决。2. 偏差分析项目绩效测量用来估计变更的量级

47、。范围控制的重要方面包括确定相对于基线变更的原因和是否需要采取纠正措施。3. 重新规划很少有项目能够按计划精确的实施，范围变更要求对WBS和WBS字典或项目范围说明书进行修改。这些修改会引起对项目管理计划的更新。由于项目是综合性的整体工作，局部的工作调整牵动整体的变化，需要在每个变更发生时触发规划性的工作。4. 配置管理系统范围变更将带来一系列项目交付物、文档系统的变化。正规的配置管理系统就以下这些方面指定了相应的规程：给出可交付物的状态报告，在批准对项目的变更前，对建议的变更通盘考虑并记录在文档中。6.5.3 范围控制的输出范围控制的结果是：1. 变更请求范围控制的结果能产生变更请求，变更的

48、处理要符合项目综合变更控制的过程。变更请求是对已被认可的WBS所确定的项目范围的任何修改。范围变更经常要求对成本、时间、质量和其他项目目标进行调整。但范围变更应该反馈到计划编制过程中，技术信息和规划文件，要根据需要进行更新，并恰当地通知项目干系人。2. 建议的纠正措施纠正措施是为了达到将来预期的与项目计划一致的项目绩效而采取的任何措施。3. 组织过程资产（更新）应该把各种变更的原因，纠正措施被选择的理由，以及从范围变更控制中得出的其他形式的经验教训，当作文件记录下来，目的是把这些资料变成历史记录的一部分存入历史数据库，为项目管理组织执行当前项目和其他项目积累经验，提供参考。4. 项目管理计划（更新）由于变更，相应的基准文档要进行修改并重新发布，如项目范围