6.2 项目的范围管理
项目从其成立开始，项目各方利益相关者都会期望项目能够按照既定的计划顺利地走向最后的成功。项目范围管理是指为了成功完成项目，对项目工作包括什么与不包括什么的定义与控制过程。这个过程用于确保项目团队和项目利益相关者对项目的可交付成果以及生产这些可交付成果所进行的工作有一个共同的理解，并保证项目包含了所有要做的工作而且只包含了这些工作（没有多余的工作）。项目范围管理主要就是保证项目利益相关者在项目要产生什么样的可交付成果方面达成共识，也要在如何生产这些可交付成果方面达成一定的共识。
项目范围管理的基本流程包括项目范围管理计划编制和项目范围定义阶段、工作分解阶段、项目范围核实阶段及项目范围变更计划和控制阶段。
6.2.1 项目范围管理计划编制和项目范围定义阶段
1.项目范围管理计划编制
项目范围管理计划是说明对项目范围的管理方式以及对项目范围变更管理方式的一个计划书。在项目范围管理计划中确定应该采用什么样的方法和标准来定义、管理和控制项目的范围。项目范围管理计划的主要任务是描述项目团队如何定义项目的范围，如何制定项目范围说明书，如何制定工作分解结构，如何核实项目的范围以及如何控制项目的范围。同时在范围管理计划中要对项目范围预期的稳定性进行评估。例如，怎样变化，变化频率如何，变化了多少，对变化范围怎样确定，变化应归为哪类等问题进行描述。项目范围管理计划是所有项目计划中最早也是最重要的一份项目计划管理文件。
项目范围计划的编制工作不是一蹴而就的过程，而是一个渐进明细的过程，需要参考大量的项目背景信息。除了考虑项目所处的大环境和项目自身的一些特征外，项目团队主要依据项目章程来进行项目范围计划。通常项目章程对项目范围已经有了粗线条的约定，范围计划是在项目章程的基础上对项目工作进一步深入和细化。在制定项目范围管理计划的时候，还应该考虑组织的文化、人力资源、市场条件以及相关的制度等主客观因素对项目范围计划所产生的影响。一个标准的项目范围管理计划应该包括以下内容：
（1）采用什么样的方法、格式来制定项目的范围说明书。
（2）如何定义项目的可交付成果。这些可交付成果成功交付的标准是什么。
（3）采用什么样的方法和标准来制定工作分解结构（WBS）以及描述工作分解结构在项目范围控制过程中的作用。
（4）如何定义项目的范围变更，采取什么样的流程和方式来控制这些变更。
项目的范围管理计划应该在项目的早期尽快发布给项目的相关人员，这样可以促使项目的各利益相关者对项目的范围达成一致，可以避免在项目的计划和执行过程中“黑屋”（Black House）现象的发生。项目的黑屋现象指的是在项目的工作过程中项目工作人员看不清项目的目标，项目利益相关者不知道项目团队在做什么等类似的现象。
2.项目范围定义阶段
很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后往往就感觉到不知道项目什么时候才能真正结束。要使项目结束到底还需要投入多少资源，整个项目就像一个无底洞，对项目的结局谁的心里也没有底。这种情况的出现无论是对于组织的高层还是项目团队来说，都是最不希望看到的。然而类似情况的出现并不罕见，造成项目“无底洞”的结果就是由于没有定义、控制和管理好项目的范围。
项目范围如何定义才算“合适”呢？因为项目范围本身涉及不同利益多方之间的关系，而且还涉及复杂的业务关系逻辑。在项目开始描述项目的需求范围时，对项目范围边界的定义上就存在着一定的模糊性和不确定性。项目的工作是从来没有发生过的一次性的独特工作，如“该怎么样做”“做到什么程度”这些都是定义项目范围的过程中不可回避的难题。
（1）项目范围与质量、时间和成本的关系。任何一个项目都有三个约束条件，即质量、时间和成本。在整个项目管理的过程中，这三个条件都是相互影响、相互制约的。在项目的设计阶段，这三个条件的相互作用对项目范围的影响尤其显著。
项目设计阶段项目的三个约束条件的相互作用对项目范围的影响：
①如果项目的时间充裕、质量要求高、成本预算充足，那么项目的范围就可以扩大，反之亦然。
②在项目设计阶段如果确定的项目范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。
③如果项目的范围（三角形的面积）能变更，那么变更三个制约条件中的任何一项就不一定以牺牲另外两个条件为前提。如果项目的范围不能变更，那么变更三个制约条件中的任何一项就必须以牺牲另外两个条件为前提。
在很多项目管理的课题研究中提出，项目管理的四个关键要素（范围、成本、质量和时间）彼此之间互相约束和互相影响，并可以得出一个计算公式：
成本=f（质量，时间，范围）
f在这里可以解释为质量、时间、范围的综合作用对于项目成本的影响。
从这个计算公式中可以看出，一般情况下，我们认为项目的范围在项目开始初期就已经是确定的，也就是假设公式中的范围（S）是“固定”的，因此在后面的项目成本控制过程中主要关注的就是质量（Q）和时间（T）之间的权衡和约束关系。
回想很多项目管理书籍中谈到的项目三角制约模型，这是一个比较理想的模型。在实际的项目实施中，往往出现项目范围的变动，而且一般是向外扩大的现象，项目的范围边界有可能出现模糊、扩大的现象。在这种情况下，上述控制模型中对成本的控制就失去了基本线的限制，C（成本）、Q、T、S之间就存在着难以计算的复杂关系，对项目的管理和控制难度就会扩大，甚至失控。
如果项目范围即既定的面积S不变，C、Q、T就可以在一个固定S的边界限制下给出一个约束的关系模型。但是，如果S的值并不是固定的，出现边界模糊或者向外扩展时，C、Q、T就失去了可依赖的边界限制，其间的约束关系就会变得复杂。因此，我们在对项目范围进行管理的时候，一是要保证项目初期的范围是准确可靠的，尽量减少范围边界的模糊性；二是要保证在项目实施过程中范围的稳定，尽量避免项目范围的变更，即使有变更也应受到合理的控制。
（2）项目范围定义的要点。项目范围的定义是项目团队根据项目的需求提出来的一个框架性的工作纲领，在对这个框架的定义过程中一般会涉及多块的业务，如财务管理、采购管理、客户管理、技术管理等。在对这些来自不同领域的工作范围的定义和描述当中，一般项目团队只可能以粗条目的方式列出，且很难做到细化。细化的工作一般都是随着对项目工作的不断认识，在项目的执行过程中通过需求调研的方式来具体化。换言之，项目范围包含的内容在项目的开始阶段可能是“广泛”的，其深度和广度从本质上来说是模糊的，因此在项目的前期，应该认识到对项目范围进行定义的工作是很重要也是很困难的，项目团队应该对项目范围的定义工作予以足够的、充分的重视。同时，在项目计划和执行的整个过程中，时刻都要注意对项目范围的控制，这样才能对项目的质量、时间和成本达到有效的控制。既要做到不能让需求“泛滥”导致项目范围的蔓延，同时也要满足业务的需要把所有必须要做的工作都定义到项目的范围管理过程中，以此保证项目的质量。项目团队把握这个尺度是很重要的。
此外，还要注意对范围的定义应该是做到可量化、可验证的程度。在很多项目团队的实际工作中，很多时候都是一些定性的要求，而不是定量的，如“界面友好，可操作性强，提高用户满意度”等。类似这些模糊的定义也是导致后来在项目的范围管理过程中出现问题的一个主要原因。
所以，在项目的计划阶段，项目团队就应该提出一个比较稳定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也为后期的项目管理划出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此圈内进行。在项目范围定义阶段，项目团队应该广泛地收集有关项目的各种信息，包括项目的产品信息、客户的信息、项目利益相关者的需求、项目的制约条件和项目的假设条件等。在这个阶段的核心工作就是在组织战略、项目使命、项目目标和项目范围管理计划的指导下进一步定义项目可交付成果的特征和为了生产项目可交付成果所必须开展的工作。这些信息都可以包含在项目范围说明书的文件中，本阶段工作的主要任务就是由项目团队和相关的项目利益相关者共同完成项目的范围说明书。
3.项目范围说明书
项目范围说明书是项目文档中最重要的文件之一，它进一步并且正式明确了项目所应该产生的成果和项目可交付成果的特征，并在此基础上进一步明确和规定项目利益相关者之间希望达成共识的项目范围，为未来的项目决策提供一个管理基线（Baseline）。在实际的项目实施中，不管是对于主项目还是子项目，项目管理人员都要编写其各自的项目范围说明书。项目在进入执行阶段后，项目管理团队应该根据项目环境和内容的变化而保持对项目范围说明书的更新，以确保项目的范围自始至终都是围绕项目的目标来开展的。在项目的交付阶段，项目团队应该根据项目范围说明书的内容来确定项目的可交付成果，并以此为基础来评估项目是否取得了成功。
因为项目范围说明书要经过项目利益相关者的审阅和评估，在编写项目范围说明书时要注意做到文字清晰、准确，尽量避免出现过多的专业术语。一个标准的项目范围说明书应该包含以下内容。
（1）项目目标。项目目标是项目要达到的期望产品或服务。确定了项目目标，也就确定了成功实现项目所必须满足的基本数量标准。项目目标至少应该包括费用、时间进度和质量标准。在项目范围说明书中目标应该列在文件第一个部分的位置，以提示项目工作人员对所有工作的计划和执行都应该围绕项目目标而展开。
（2）产品的特征和客户的接受标准。在项目范围说明书中，应该对产品特征做出详细的描述，对产品特征的描述又可以分为：
1）功能特征描述。功能特征是指项目客户希望从产品中得到的能够创造使用价值的相关特征。例如，该项目产品在哪几个方面能够帮助客户解决实际问题。
2）结构特征描述。产品的功能特征可以用不同的方式和手段去实现，或者说可以由不同结构特征的产品实现相同的功能特征。结构特征包括尺寸、形状、形式、颜色、材料、味道和触觉等。所以在项目范围说明书中还要详细描述项目产品的结构特征。要注意产品的功能特征、结构特征是彼此紧密相关的。每一项产品结构特征的选择，其范围是很大的，可以有多种多样的组合，所以在项目范围说明书中还要明确记录客户对这些特征的验收过程和接受标准。
（3）项目可交付成果清单。在编写项目范围说明书时必须有项目可交付成果清单，以此作为项目范围计划的前提依据。项目的可交付成果是指项目的客户在项目结束或者项目某个阶段结束时要求项目团队交出的具体的、可以测量和核实的工作成果。这些工作成果可以是某种产品、服务或结果。在项目范围说明书中应该列出项目的主要可交付成果，而且对于这些要求交付的成果都必须有明确的要求和说明。如果这些被列入项目可交付成果清单的事项被圆满完成，并交付给项目的使用者，就标志着项目阶段或项目的完成。例如，某软件开发项目的可交付成果包括电脑程序、用户手册、帮助用户掌握该电脑软件的教学程序和一个为期三天的培训课程，对于以上四个可交付成果在计划的时间和成本内完成并被客户接受，就标志着项目的圆满完成。
（4）项目的限制条件。项目的限制条件是指在项目中客观存在的因素，因为这些因素的存在会对项目的绩效造成一定的影响。一般来说，项目的预算、完工时间和客户对项目的需求以及其他合同条款都可以构成项目的限制条件。项目团队必须在范围定义阶段认真分析项目的限制因素，从而在制定工作范围的时候才知道哪些是项目团队能够开展的工作，哪些工作的开展是必须要做的，哪些工作是不能做的。例如，对于一个卫星发射的项目来说，气候因素就构成了该项目的限制条件。如果项目团队预测到7月将会有不利的天气，项目团队在这种限制条件下，只能回避气候的影响，提前或推后卫星的发射日期。
（5）项目的假设条件。项目的假设条件是为了进行项目计划，而被假定为存在的、真实的一些因素。对这些因素进行的假定会影响项目计划的各个方面，而且项目的假设条件会随着项目的进展而逐渐得到证实。对于项目假设条件的分析，是在制定项目范围时一项很重要的工作，但其往往也是项目团队最容易忽略的工作。很多项目团队在制定项目的范围计划时，由于没有对项目的假设条件进行充分分析，直接导致了项目的失败。因此，对项目假设条件的分析应该引起项目团队的高度重视。强调一点，项目假设是项目团队在主观上的一种认识。在项目管理中，对于假设条件的识别、分析和管理往往是构成项目计划和实施最根本的基础。
例如，在国外的某项目里，某城市对造成城市交通压力的原因进行了研究，他们发现造成该城市交通压力的一个主要原因来自那些拥有私家车的居民开车上街购物，因此该城市设立了一个项目以此来缓解交通压力。该项目计划在各商业中心和较富裕的小区之间开设专用的公交车供小区的居民乘坐去购物，这样就可以大大减少拥有私家车的居民开车上街购物的次数，从而缓解城市的交通压力。在这个案例中，项目的假设条件就是那些拥有私家车的居民在上街购物时愿意乘坐公交车。也就是说，如果这些居民开私家车去购物是为了购物的安全或者为了满足面子上的需要，那么政府就算提供了专用的公交车供小区的居民乘坐去购物，他们也很有可能不去乘坐。在这个案例中，对于居民愿意乘车这个条件的假设，是该项目成功的必要条件。所以项目团队应该在项目计划的阶段就开展调研活动来证实该项目中存在的假设条件的有效性。任何一个项目都存在一定的假设条件。在一个工程设计、施工的项目中，一个最重要的假设条件就是项目团队得到的图纸和数据是正确的；在一个国际合作项目中，一个最重要的假设条件就是外方的项目理念、项目方法和衡量成功的标准与中方是一致的。
在实际的项目管理过程中，项目团队往往把项目的限制条件、假设条件和项目的风险因素混为一谈。在项目的范围计划阶段，区分这三个因素对于整个项目范围的定义是很重要的。限制条件一般来说比较容易识别和分析，它有可能构成项目的风险，也有可能不构成项目的风险。项目假设对于项目风险来说是最主要的风险源之一，在识别和定义出项目的假设条件后，必须把对项目假设条件的管理纳入风险管理的范围之中。例如，上文提到的缓解交通压力的项目，项目团队首先要做的就是确认居民愿意放弃开私家车购物这一假设条件。这一假设条件所产生的风险就是项目团队在采访居民的过程中有可能出现的样本错误或者测量错误，项目团队应该在整个项目的计划过程中对这一项风险予以关注。在上文提到的工程设计、施工的项目中，项目团队也应该充分认识到由于设计图纸和数据的错误给项目带来的风险。
（6）项目的需求识别。项目的需求识别主要是识别和描述本项目的开展应该满足哪些需求。例如，可交付成果应该是哪些，每项可交付成果应该具备什么样的特征才能满足项目的需求（详见第4章），项目利益相关者的需求是哪些（详见第3章）。
（7）项目的除外责任。在项目范围说明的时候要尽量明确项目的工作边界，识别哪些工作或成果是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望，避免项目到计划或执行阶段项目范围蔓延的现象。
（8）识别出的项目风险。这个部分主要介绍到目前为止已识别的项目风险是哪些，应该如何计划和控制这些风险（详见第7章）。
（9）项目的里程碑计划。项目的里程碑一般是项目中完成阶段性工作的标志。项目里程碑应该由相关的项目利益相关者、项目团队和有经验的专家共同确定。
（10）项目的成本计划。对项目总成本中的主要要素进行描述，在项目范围说明书中只需要概括性地描述项目的成本构成，详细的项目成本描述包含在项目成本计划中。
以上是制定一个标准的项目范围说明书的十大要素，范围说明书因项目类型的不同而不同。规模大、内容复杂的项目，其范围说明书可能会很长。有的项目范围说明书加上附件可以长达几百页；而有的项目，可能只要几页纸就够了。总之，范围说明书应根据项目的实际情况做适当的调整以满足不同的、具体的项目需要。随着项目的不断实施进展，需要对项目的范围说明进行修改和细化，以反映项目本身和外部环境的变化。这十个要素是构成项目范围最基本的条件，制定一个项目范围说明书应该包括以上的十大要素。
项目章程和项目范围说明书在很多内容上都是重复的，但是其用途和详细程度不一样。项目章程是说明项目团队已经取得了授权并以此来开展项目工作的正式文件，而项目范围说明书是说明项目团队开展项目管理工作的基础和依据。在实际的项目管理过程中，项目团队依据项目章程来制定项目范围说明书，再以项目范围说明书为基础开始项目的工作范围定义和分解，然后根据工作分解结构来开始项目的各项计划工作。
6.2.2 工作分解阶段
工作分解阶段主要是运用工作分解结构对项目的范围内所要开展的工作进行分解的阶段。本节主要介绍工作分解结构的运用原理、方法及其重要意义。
1.工作分解结构
目前关于工作分解结构（Work Breakdown Structure，WBS）的定义多种多样，本书使用的是美国项目管理协会的定义。根据PMI的定义，工作分解结构是一个以项目的可交付成果为中心的，为了完成项目的目标和创造项目的可交付成果，由项目团队进行的一种对项目工作有层次的分解。工作分解结构定义和组织了项目的全部范围。
对项目范围内的工作任务进行分解的过程看起来比较简单，就是把一个项目的全部工作分解成更为细小和具体的工作。所以在实际工作中大多数项目的工作分解都是一种自发性的，很多项目经理既没有接受过运用工作分解结构进行工作分解的培训，在工作分解的过程中对于工作分解的科学性也没有予以足够的重视。目前无论是在项目管理理论描叙还是在工作实践中，工作分解结构都没有得到应有的重视。实际上运用工作分解结构进行分解的过程是一个很科学也包含很多艺术性的过程。用不同的分解方法会得到一个完全不同的项目管理成果，而这个成果，直接影响到项目的所有计划管理和控制管理以及项目最终可交付成果的产出。
运用工作分解结构对项目的工作进行分解是项目管理过程中最为重要，也是最为复杂的管理工作之一。项目的所有计划工作，包括项目的时间计划、成本计划、风险计划、质量计划、人力资源计划、沟通计划、采购计划和对项目的集成管理，都必须居于一个良好的工作分解结构。在整个项目的设计和范围计划的管理过程中，工作分解结构是在这两个管理过程中产生的最主要管理成果之一。项目的工作分解结构应该能够直接反映项目所在组织的战略设计和项目环境对项目的影响，如果没有一个良好的工作分解结构，就不可能实现项目为战略提供支持和服务的目标。同样，在对项目进行管理的阶段，没有工作分解结构，后来所有的项目计划和管理工作也都不可能取得良好的效果。可以说，工作分解结构是整个项目管理系统中的骨架和枢纽，没有这个骨架和枢纽，就没有项目管理。
2.运用工作分解结构的基本方法
WBS的运用结构应以等级状或树状来构成。根据实践和研究表明，在范围计划中运用WBS的时候，主要有以下几种方法。
（1）类比法。以一个类似项目的WBS为基础，制定本项目的工作分解结构。例如，某IT组织在开发某种软件方面有着丰富的经验，当他们计划投入设计生产某种新的软件时，就可以借鉴以前开发过的类似项目的WBS，以旧的WBS的范围和层级为基础，开始新项目WBS的编制。例如，该项目是第二次为A组织开发软件，那么第一次项目WBS中的关于了解用户、了解管理部门、了解企业环境等一些重复性较强的工作包就可以借鉴到新的WBS的工作包设计中。一般来说，重复次数较多的项目、管理经验比较成熟的项目在运用WBS的时候可以使用类比法。
（2）自上而下法。这是构建WBS的常规方法，即逐步将工作分解成下一级的多个子项，这个过程就是不断细化工作任务。自上而下法实际上是一种系统思考法，这种方法需要项目团队必须具备比较全面的项目经验，项目经理要具备一定的系统思维能力和相关的知识。自上而下法最符合人们的常规思维和计划方式，即从宏观开始计划和考虑，在宏观的指导下逐步细化和分解为下一级的多个子项工作。这个过程就是要不断增加级数，细化工作任务。
如果项目团队中有对本项目经验丰富的专家，或者项目对于项目团队来说不是很陌生，使用自上而下法是最佳的方法。
（3）自下而上法。自下而上法实际上是对项目工作分解的一个先发散后归纳的过程。自下而上法就是要让项目团队成员从一开始就尽可能地确定与项目有关的各项具体任务，然后将各项具体任务进行分析和整合，再归纳总结到一个整体活动或WBS的上一级内容中去。还是以IT软件开发为例子。例如，如果该项目是第一次为A组织开发软件，那么项目团队在制定确认用户需求工作包的时候，就可以采取自下而上法来制定该工作包。项目团队的营销人员负责制定如何拜访客户的工作包，软件工程师负责制定如何确定客户对系统要求的工作包。项目经理把这两个工作包集合在一起就可以得出上一级的工作包——确认客户需求。
自下而上法一般都很费时，团队成员可以用类似头脑风暴的方法，一开始尽可能地确定各项具体任务，然后将各项具体任务进行分析和整合，形成零散的思路，最后再由微观到宏观地归纳。自下而上法对于独特性和创新性比较强的项目WBS的创建来说，是一种很好的方法。
需要强调的一点是，以上这三种方法可以交替使用，一个项目团队可以在制定WBS时首先使用类比法借鉴相关项目的经验，然后使用自上而下法对项目的工作进行系统的分解，最后使用自下而上法再对WBS中有可能遗漏的工作进行补充。在实际的项目范围计划中，WBS的自上而下法和自下而上法应该是交替使用的。对于项目的这两种工作的分解也是项目团队对项目工作分析的两种思维方式，只有从上往下的演绎思维和从下而上的归纳思维结合在一起，思维才能有系统性和全局性，才能做到对项目工作的计划是全局考虑而且没有遗漏的。这一点也正是项目范围管理的核心所在。
3.运用工作分解结构对项目工作进行分解的方法
运用工作分解结构对项目工作进行分解有许多方法，如按照项目的可交付成果分解，按项目的专业分工分解，按照项目的子系统、子工程分解，按照项目生命周期的不同阶段分解等。以上每种方法都有其优缺点，一般情况下，确定项目的WBS结构需要组合以上几种方法进行，在WBS的不同层次使用不同的方法。小的项目只需要很简单的WBS结构，结构的划分基本上是一目了然的。随着项目规模的增加，WBS也就越复杂。对于大型的项目而言，确定项目的WBS结构是一个循序渐进的过程，往往不可能一两次就成功，需要经过多次沟通、反馈和修正，最后才能得到一个项目各方都能接受的WBS结构。
现在的项目管理实践中，对WBS第一层次的分解主要有以下几种普遍的分解方法。
（1）按项目的专业分工分解项目。这种方法是比较容易的分解方法，项目团队在确定了项目的专业工作分工后就可以进行工作的分解。但是用这种方法划分项目工作最大的缺点就是很难对项目的工作进行协调，也就是项目的协调工作或者沟通工作有时候很难设计到项目的工作包中。例如，在制定某项目客户需求调查的工作包中，该项工作需要市场部的人员和技术部的人员密切配合，如果该项目是按照专业分工来进行分解的，那么客户需求调查工作包的内容就很容易被划分在不同的领域或者层级中。对于一些大型项目中需要包含大量协调工作的工作包来说，这样的划分方式就会让两个项目组之间的协调工作很困难。按照这种方式分解工作，项目团队成员在分解到一定层级的时候，尤其是涉及很多协调工作的时候，往往不知道该如何进一步划分，或者某项工作包到底是该属于谁的。
（2）按照项目生命周期的不同阶段分解项目。按照项目生命周期的不同阶段分解项目是目前很多项目团队在使用WBS的过程中最常用的方法，使用这种方法最大的好处就是项目的工作分解比较容易，只要按照项目的可行性研究阶段、项目的启动、计划、执行和收尾阶段来分解工作任务就行。但是按照项目生命周期的不同阶段分解项目工作对于时间要求比较紧（这样的项目往往因为比较紧的工期而要求采用大量的并行工程）的项目来说，或者对于不确定性比较大（项目的后期工作不确定性很大）的项目来说，按照项目生命周期的不同阶段分解项目就不太科学，同时也会造成很多协调上的麻烦。例如，在某项应急项目中可能很难（也没有时间）预测出什么时候进入项目的计划阶段，什么时候进入项目的执行阶段。在一些边计划边执行的项目中，按照项目生命周期的不同阶段分解项目的工作就会造成项目工作包之间逻辑上的混乱。
（3）按照项目的子系统、子工程分解项目。按照项目的子系统、子工程分解工作容易界定项目的范围。该分解结构是对项目产品物理结构的分解，WBS层次的划分取决于子系统和子工程的复杂程度。这种划分方法对于子系统与子系统之间联系比较简单的项目来说相对容易一些，但这种方法应用到系统界面或接口比较复杂的项目中容易出现项目管理过程中横向管理关系工作难以界定的问题，对于一些项目中集成工作包的安排也不容易界定，如建筑工程的总体设计工作包、弱电系统设计工作包等。在实践中，按照项目的子系统、子工程进行分解的项目往往很容易忽略一些技术管理外的工作，比如客户关系的管理等。这样就会使得项目的可交付成果没有完全被工作分解结构所支持，导致最后项目交付的时候无法完全满足项目客户或者项目利益相关者对项目成果的接受。
（4）按照项目的可交付成果分解项目。项目团队把在项目范围说明书中定义出来的项目可交付成果作为分解结构的第一层，然后围绕项目的可交付成果进行分解。本书认为在大多数的情况下，项目团队应该运用这种方法对项目工作进行分解，主要理由如下。
1）项目的可交付成果代表着客户和项目利益相关者的愿望，是项目团队和项目客户协议后的结果。以项目的可交付成果为中心的WBS可以保证项目的所有工作是围绕客户的需求来开展的。
2）按照项目的可交付成果进行工作分解，可以确保项目的工作是紧紧围绕项目的可交付成果来开展的。项目团队的工作目标明确，责任容易划分，可以有效地避免那些不支持项目可交付成果的工作列入WBS中。
3）把项目的可交付成果列为工作分解结构的第一层，可以保证项目的成功完成。项目团队在项目范围说明书中列出了项目的主要可交付成果，而且对于这些要求交付的成果都做出了明确的要求和说明。如果这些被列入项目可交付成果清单的事项被圆满完成，并交付给项目的客户，就标志着项目阶段或项目的成功完成。所以，把可交付成果列为WBS的第一层然后进行工作的分解，那么只要完成了第二层以下的全部工作，就意味着项目阶段或项目的完成。
4）以可交付成果为中心的工作分解结构，可以加强项目中各利益相关者的沟通和管理（因为项目中各利益相关者更加关心项目可交付成果的完成情况）。
5）因为项目可交付成果是在组织的战略指导下完成的，以可交付成果为中心的工作分解结构，可以保证项目和项目工作的开展有效地支持组织战略目标的完成。
4.运用WBS进行工作分解的步骤（自上而下法）
以下是运用WBS进行工作分解的基本步骤。
（1）了解项目环境，明确项目的目标。项目团队在制定项目的WBS之前，一定要再次评估项目所在的环境，确认项目的目的和目标（包括子目标），了解项目的技术要求和功能特征以及其他对项目的特殊要求。在制定WBS前，涉及项目各部门的重要人员、项目分包商和其他与项目有关的关键工作人员都应该被确定下来，并且参与到WBS的制定中去。这样有助于保证在WBS中工作定义的准确性和充分性，并同时得到他们对项目工作在时间和资源上的承诺。
（2）明确项目的主要可交付成果。项目团队应该根据项目范围说明书中的信息进一步细化项目的主要可交付成果，对这些主要成果的完全交付标志着项目的圆满完成。明确后的主要可交付成果被列为WBS的第一层，构成了项目的全部范围。正如上文提到的，本书建议运用主要的可交付成果作为WBS的第一层，一个原因是运用主要可交付成果进行WBS的工作分解在项目的工作关系上逻辑要清晰一些。其次，运用可交付成果进行项目的分解可以保证项目的工作是围绕可交付成果开展的。在项目设计的过程中，可交付成果是围绕项目的战略设计和客户需求产生的，这样可以用一个结构化的方式来定义项目的工作，并且保证这些工作的开展是在战略指导下和围绕客户的需求而进行的工作。最后，通过可交付成果来进行的工作定义，在项目执行过程中，可以保证项目工作有很强的目的性，即只有那些对可交付成果有效的工作才做，因此项目的计划和执行工作也变得更加稳定和高效。即使在项目环境不断变化的情况下，可以确定的项目工作也应该始终围绕项目的可交付成果来开展。
（3）根据项目的可交付成果选择构建WBS的方法。在这个阶段建立WBS的树状结构，将项目的可交付成果不断地划分或分解成一些较小的工作单元。分解结构应以等级划分来构成，最上一层（可交付成果）代表为了完成项目所必须开展的所有工作，从而构成了项目的范围。然后每个层次向下分解，结构上的第二个层次比第一层要窄，工作分解结构每细分一层次表示对项目元素更细致的描述。为了完成上一层次任务的所有工作都包含在下一层次中，依次类推。WBS结构底层是管理项目所需的最低层次的工作，通常被称为工作包。工作包是完成一项具体的项目工作所要求的一个特定的、可确定的、可交付以及独立的工作单元，为项目控制提供充分而合适的管理信息，也代表着项目团队和各项目利益相关者对管理项目所要求的最低控制水平。
并非工作分解结构中所有的分支都必须分解到同一水平，各分支中的分解原则可能会不同。原则上对WBS中工作的分解应该是到可操作和可计量的程度，并确定对每个工作包分解的详细程度是否已经达到了足以编制恰当的成本和时间估算的要求。国外有的项目经理提出，工作包应该分解到80小时以内能够完成，也有人认为应该分解到40小时之内能够完成。但实际上，哪一种对于工作包划分的定量方法都是不准确的。在实际工作中项目团队对于工作包的划分应该结合项目的具体情况来分析。一些简单、重复劳动的工作包，或者对于项目来说不是管理重点的工作包，不一定非要划分到80小时以内完成的层次。而那些很重要的工作包，或者风险比较大的工作包，则是分解得越细越好。对于工作包的分解实际上是项目团队对于项目工作的管理行为进行的一个选择过程，项目团队在这个过程中应该考虑到项目组织的实际情况、客户的需求情况、项目范围说明书中的信息。
在分解工作包的时候还要考虑到管理跨度的问题。如果将工作包分解到相当小和详细的程度，对于一些大型项目来说，可能就会形成上万个工作包。要用这些工作包对项目活动进行管理，可能会使项目的计划和执行陷入无穷无尽的细节中去，极大地增加了管理成本。总之，进行工作分解总的原则是WBS能满足项目经理管理项目的需要，工作包界面清晰，项目团队能够对分解后的工作包进行有效和精确的控制。
在工作分解的过程中有时候会遇到项目团队分解工作到一定程度的时候就不知道如何分解的情况。在这种情况下，项目团队应该积极寻找外部的专家来帮助项目团队做分解工作。对于确定性很小，实在无法分解的工作，可以暂时不用分解，等项目进行到一定程度的时候，随着对项目工作越来越了解，再进行工作的分解。
在WBS的层次分解过程中，普遍的实践是WBS的上面三层反映了项目整合的努力程度，主要体现的是对项目的管理层面，也是项目管理者、各项目利益相关者应该关注的部分。三层以下一般都是技术层面的工作，由其他的项目团队成员进行管理和控制。
（4）核实工作分解的充分性。整个项目的范围计划过程实际上就是定义为完成项目所必须进行的工作，而且也只定义那些能够满足项目范围的工作，不在一个WBS范围内的工作就不是项目中的工作。因此，应该将项目中的所有工作都分解到WBS中去。在WBS的工作分解中，也同样运用范围管理这个原理。
在制定完初步的WBS后，要运用完全支持的原则来核实WBS的完整性。首先核实WBS的第一层是不是包含了所有的项目可交付成果，以及第二层的工作是不是完全支持了项目的可交付成果。其次运用WBS分解的百分之百原则核实，即对下一层中所有工作的完成能不能实现上一层的任务；为完成上一层任务的工作是不是全部而且也仅仅是这些工作都包含在下一层的任务中。
需要强调的一点是，国外的项目团队在制定工作分解结构的时候，很注重对项目管理过程活动的分解，而国内的项目团队很容易忽略这一点。对项目管理过程活动的分解实际上是对项目团队在管理项目的过程中的一种管理要求，以实现项目管理流程的不断改进。例如，可以把项目管理过程列为项目的可交付成果之一，并作为WBS的第一层。这样就可以把项目管理过程分解为：项目可行性研究、项目计划、项目状态报告、项目流程控制和项目收尾。
这种对项目管理过程活动的分解极大地起到了支持项目管理的作用。可以把很多无法放入项目工作包的任务，如项目会议的组织、对项目报表的要求等一些重要的管理行为放到这个工作包里，从而极大地增强项目团队对项目的管理和整合能力。
（5）核实工作分解的正确性。核实工作分解的正确性主要是指WBS是否符合以下要求：
1）各项工作包是否得到了清晰的定义。
2）各子项间工作界面是不是清晰。
3）成本是否便于进行预算、跟踪并得到有效控制。
4）进度是否能得到有效的跟踪和控制。
5）质量是否能得到有效的跟踪和控制。
6）是否能够准确地识别出项目的里程碑事件。
7）能否识别出项目风险源，对风险源能否进行有效的跟踪和控制。
8）能否支持项目的采购任务。
9）能否支持项目的分包任务。
10）各项工作是否得到了有效的管理控制。
11）能否支持项目团队人员明确工作职责。
（6）制定WBS词典，进行工作单元编码。工作分解结构中的每项工作单元都要编上号码，用来识别工作分解结构中的每项工作任务。对WBS的编码在整个WBS的制定过程中是很重要的一步，编码工作在开始制定WBS的时候就可以开始。在进行编码工作后就可以开始制定工作分解结构词典，也就是对工作分解结构中的每项工作给予定义，具体描述该工作任务所含的全部工作内容。工作分解结构词典中包含的内容主要有：识别编码，工作包的工作内容描述以及相关的计划编制信息，如进度计划、成本预算、人员安排、质量标准、技术要求和合同信息等，以便在需要时随时查阅。
在项目计划和以后的各个阶段，项目工作中各工作任务的查找、时间安排、费用预算、资源安排、质量控制和变更等各项工作都可以按照这个编码系统来按图索骥。若编码系统不完整或出现错误，在将来的管理中会引起很多麻烦。对于大型的项目来说，在进行编码设计时也应该考虑其有效性和科学性。例如，一个大型项目WBS中的一项工作包编码为CT12-OESC001-R03，其中C是指为完成某项可交付成果的工作包，T是指分配给某部门的工作包。如果这个工作包的执行情况不理想，项目管理人员在审核该工作包的时候，只要一看编码，就知道是哪里出了问题，这个问题该由谁负责。一个标准的WBS词典。
（7）给相关的项目利益相关者审阅和评估WBS。项目利益相关者应该对WBS的分解结果有一个明确的承认和认可，这样可以帮助项目利益相关者对项目工作进一步认可和理解。通过加强沟通尽量避免对项目可交付成果及要开展的工作所产生的理解上的不一致，同时也争取到项目利益相关者对项目工作开展的进一步支持。
（8）根据WBS开始项目的各项计划工作。要记住的是，WBS不是在制定出来后就一成不变的。随着项目的开展，可能出现的范围变更、项目风险的发生或对可交付成果的进一步认识都有可能导致项目工作的增加或减少，从而造成对WBS不断修改。例如，很多的项目不可能等到WBS的各个要素都计划完后才开始项目的各项计划工作，尤其对于一些在时间要求上比较急迫或不确定性比较强的项目，采取的是波浪形的计划方式，即边计划边施工，这将导致项目任务不可能一次就明确，因此，项目的WBS也不可能一次性分解到位。另外，对于一些大型项目来说，由于规模很大，头绪繁多无法一下分解到位，在这种情况下也可以逐步分解，先将已经明确纳入实施计划的工作进行分解，再逐步分解其他工作。但是在任何情况下都应该保证WBS的百分百原则，即上一级的工作任务被下一级的工作完全支持。有的WBS可能到项目的后期才能够做全。在这个对WBS不断完善的过程中应该运用PDCA（计划—实施—检查—处理）循环以实现WBS质量的不断提高。
有的项目团队在项目后期不太注意对WBS工作内容的完善，认为对于整个项目来说，在这个阶段对WBS进行完善已经没有必要了。但是作为项目经理或者项目所在的组织应该在项目结束的时候提交一个完善的WBS，这样做一方面可以帮助以后的项目团队在开展类似项目的时候有系统的经验可以借鉴，另一方面有助于项目所在组织项目管理成熟度的不断提高。
对WBS的管理也应该注意其保密性。有些工作分解结构可能包含了组织的商业机密和技术机密，对项目的工作分解充分体现了一个组织的管理模式和工作方式的经验和成熟度。同样的项目，一个具有丰富的管理和技术经验的组织和一个经验和技术上还不成熟的组织做出来的工作分解结构是不可能一样的。组织往往依靠对一些项目的成功管理而获得竞争优势。
