1.了解做好项目范围管理的重要。
2.讨论需求收集和记录的方法，以满足利益相关者的需求和期望。
3.解释范围定义的过程，描述项目范围说明书的内容。
4.讨论运用类比法、自上而下法、自下而上法、心智图法构建工作分解结构的过程。
5.解释范围验证的重要性及其与范围定义和范围控制的相互关系。
6.理解范围控制的重要性，以及解决与IT项目范围相关的问题的方法。
7.描述软件在项目范围管理中发挥的作用。
开篇案例
　　Kin Nguyen主持了首次项目团队会议，意在为IT升级项目构建工作分解结构。这个项目对于公司正在开发的几项高度优先的并且以互联网为基础的应用软件来说非常有必要。这个IT升级项目要在9个月内创建并实施一项计划，以发挥所有员工的信息技术技能，来满足公司的新标准。这些标准详细说明了每台台式电脑或笔记本电脑所需的最少设备，包括处理器类型、存储量、硬盘大小、网络连接类型以及软件。Kim知道要实施升级项目，必须首先掌握整个公司内2000名员工当前所有的硬件、网络及软件的详细清单。
　　Kim已经同其他利益相关者一起制定了项目章程以及初步范围说明书。这个项目章程包括项目的大致费用及时间进度估计，还有关键的利益相关者的签名；初步范围说明书除提供了与项目范围相关的信息外，还在界定硬件、软件及网络需求方面开了一个好头。Kim及其团队和其他利益相关者召开了电话会议，以进一步界定项目范围，包括项目涉及内容、谁将做些什么以及如何避免潜在的范围蔓延。她想获取每个人对上述各个方面的意见。公司新上任的CEO,沃尔特·施米茨，一直以来都密切关注如此重要的项目。公司已经开始使用一种新型的项目管理信息系统。这一系统能使每个人都能详尽、高水平地了解项目实施的状态。Kim知道，建立一个好的工作分解结构是项目范围管理、时间管理和成本管理取得成功的基础，但是她从未领导过项目团队去构建工作分解结构，或者是根据工作分解结构来分摊费用，Kim应该从哪里入手呢？ 
5.1 什么是项目范围管理
　　回顾第1章可知，有多种因素影响着项目能否取得成功。其中许多因素，如用户参与度、清晰的业务目标、一个最小化的或清晰界定的范围，以及公司的基本需求，都是项目范围管理的基本要素。凯勒管理研究生院的项目主管威廉。莱班曾经做过论证，他认为缺乏适当的项目定义和项目范围是项目失败的主要原因。
　　因此，项目管理中最重要也是最难的问题之一就是定义项目范围。范围(scope)是指生产项目的产品所牵涉到的丁作和用来生产产品的过程。回顾第2章可知，可交付成果(deliverable)是指作为项目一部分产生的产品。可交付成果可以是与产品相关的，如一套硬件或一段软件代码；也可以是与过程有关的，如一份规划文件或会议记录。项目的利益相关者必须在项目究竟要产生什么样的产品上达成共识，以及在一定程度上还要就如何生产这些产品以提交所有的可交付成果达成共识。
　　项目范围管理（project scope management）是指界定和控制项目中应包括什么和不包括什么的过程。这个过程确保了项目团队和项目的利益相关者对项目的可交付成果以及生产这些可交付成果所进行的工作达成共识。项目范同管理包含5个主要阶段：
　　(1)需求收集(collecting requirements)是指定义并记录项目最终产品的特点和功能，以及创造这些产品的过程。需求收集阶段的输出是项目团队编制的利益相关者需求文档和需求跟踪矩阵。
　　(2)范围定义(scope definition)是指评审项目章程、需求文档和组织过程资产来创建范同说明书，并且随着需求的扩展及变更请求得到批准，在规划过程中增加更多的信息。范围定义的主要输出有项目范同说明书以及项目文件的更新。
　　(3)创建工作分解结构(creating the WBS)就是将主要的项目可交付成果分解成更细小和更易管理的部分。它的主要输出包括工作分解结构(WBS)、WBS词典、范围基线、项目变更请求，以及项曰范围说明书和项目文件的更新。
　　(4)范围核实(scope verification)是指将项目可交付成果的认可正式化。关键的利益相关者，如项目的客户及项目发起人，在这一过程中进行审查，然后正式接受项目的可交付成果。如果不接受现有的可交付成果，客户或项目发起人通常会请求做些变更。因此，该阶段的主要输出包括被接受的可交付成果及变更请求。
　　(5)范围控制(scope control)是指对整个项目生命周期内范围的变化进行控制，这对于许多IT项目来说是很有挑战性的。范围变更经常影响团队实现项目的时间目标和成本目标的能力。因此，项目经理必须仔细权衡范围变更的成本及收益。这一阶段的主要输出包括变更请求；建议的纠正措施；项目范围说明书、WBS和WBS词典、范围基线、项目管理计划及组织过程资产的更新。
　　图5-l总结了这些阶段及其输出情况，并说明了在特定项目中各阶段可能发生的时间。

5.2需求收集
　　项目范围管理的第一步即需求收集，通常是最困难的。不能准确定义需求的主要后果是重复工作，这很可能会耗费项目总成本的一半之多，特别是对于软件开发的项目。正如图5-2所示，在项目接近收尾时才发现软件的缺陷并加以弥补，其成本比在需求收集阶段就发现并修正的成本要高得多。

需求收集的一个难点在于，人们往往对需求缺乏一致性的定义，包括什么是需求、如何收集需求、如何编制需求文件。
5.2.1什么是需求
　　IEEE软件工程标准词汇表（1990年）中定义软件需求为：
　　-用户解决问题或达到目标所需的条件或能力。
　　-系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具备的条件或能力。
　　-一种反映上面两点所描述的条件或能力的文档说明。
　　PMBOK指南第4版对需求的定义与上述第二项的内容基本相同。需求(requirement)是指根据合同、标准、规格或其他正式的强制性文件，某个系统、产品、服务、成果或部件必须达到的条件或具备的能力。
　　项目执行中，将需求详细地记录下来以便于日后测量，这一点非常重要。毕竟，满足这些需求是实现项目范围目标的基础。
　　比如，开篇案例提到的通过升级IT资产满足公司标准的项目。这些标准说明了每台电脑或笔记本电脑所需要的最少设备，包括处理器类型、存储量和硬盘大小。因此，需求记录包括每台电脑都应配置英特尔处理器、4CB内存和160G硬盘。
　　对于一些IT项目，可以将需求分为启示、分析、详细说明和验证。这四类包含了软件或软件相关产品需求的收集、评估和记录的各种活动。而反复定义需求也很重要，因为在项目开始时，需求通常并不清晰。
5.2.2如何收集需求
　　收集需求的方法有很多。与利益相关者一对一访谈是一种很有效的方法，尽管成本高，且很花时间。而使用焦点小组会议、引导式研讨会、群体创新和决策技术法来收集需求，比一对一访谈法更快、成本更低。问卷调查法是一种行之有效的方法，前提是关键的利益相关者能够提供诚实而全面的信息。观察法也是很好的收集需求的技术，特别是对于需要改进工作流程或程序的项目。软件开发项目中，还有一种需求收集的常用技术，即原型法。此外，还有一些帮助收集和管理需求的软件工具，在下文和“对在哪里”的内容中将举例说明。
对在哪里
　　Genesys电信实验星以提供开创性的电话通信方案而享有广泛声誉。这蒙会司通过开发软件，管理与客户的电话、网络和电子邮件互动，其在全球拥有超过4 000个客户和l500名员工。但是，随着公司的发展，他们不得苹开发新产品，以应对保持竞争优势的挑战。例如，Ceriesys现在使用的Accept软件，是一项计划与创新方面的管理应用产品，获得了2006 -2008年产品管理优秀奖。在应用Accept软件之前，Genesys的产品计划过程很费时，而且版本之间难以复制。产品管理与战略副总裁保罗-兰说，Accept软件为他们提供了一个单一的系统，包含了多年度、多阶段项目的多种产品的全部规划数据。使用Accept，新产品曲定义和开发过程会逐步连贯、可重复且可预测。同时，他们可以定义哪些信息中包含了需求，并在相应的过程中强化铖练。兰说：“每巾需求都必须注明由谁提出，为什么提出，并且将这些需求与公司的战略、产品和发售主题相关联。”
　　要花费多大的精力去收集需求，取次于项目的规模、复杂程度、重要性和其他因素。例如，如果一个团队正在为一个拥有50多个地区分公司、数十亿美元资产的企业去更新整个公司的会计系统，那么该团队应该花相当多的时间来收集需求。与之相反的情况是，对于为一个只有5名员工的小型会计公司而做的软件和硬件升级项目而言，就只需要花很少的精力收集需求。无论如何，对一个项目团队来说，为其承担的项目收集和管理需求是非常重要的。如第4章所述，关键的利益相关者的投入，以及使整个项目范围的关键方面与企业战略相匹配是极其重要的。
5.2 3如何记录需求
　　正如收集需求的方法有很多种，记录需求的方法也不少。项目组最先阅读的应该是项目章程，因为它包含了项目的高层次需求或者指出其他列出需求的文件。他们还应该查阅利益相关者评论，以确保所有关键利益相关者在决定需求时都有所表述。需求文件的格式多种多样，既可以是在一页纸上列出全部需求的清单，也可以是堆满整个房间的记录各种需求的笔记本。参加过复杂项目（比如建造新飞机）的人员深知：一份记录飞机需求的文件比飞机本身更有价值！需求文件通常由软件制作，可以是文档、图像、程序、录像和其他媒介，也可将需求分类，如功能需求、服务需求、性能需求、质量需求、培训需求等。
　　除了将利益相关者需求文件作为需求收集过程的输出外，项目组经常会创建需求管理计划和需求跟踪矩阵。需求管理计划( recluiremenk management plan)是描述如何分析、记录和管理需求的计划。需求跟踪矩阵（reqmrements traceability matrix，RTM）是描述需求、需求源并对需求状态进行跟踪的表格。
　　以开篇案例中的IT更新项目为例，引入需求跟踪矩阵，如表5-1所示。需求跟踪矩阵可以包含很多变量。比如，用它记录软件需求时，将每个有关联的需求交叉引用( cross-references)，并列出具体测试来证明这些需求已被满足。记住，需求跟踪矩阵的主要目的是通过对需求的分解、执行和验证来保持每个需求源的联系。

5.3范围定义
　　项目范围管理的下一步是要进一步定义项目所需开展的工作。合理的范围定义对项目的成功非常重要，因为项目定义有助于提高时间、成本及资源估计的精确度，定义绩效测量及项目控制的基线，帮助理清和明确工作职责。在范围定义中，使用的主要工具及技术包括专家判断、产品分析；可供选择的T作方法识别和引导式研讨会等。范围定义的主要输出是项目范围说明书和项目文件更新。
　　项目范围说明书的关键输入包括：项目章程、需求文件、组织过程资产（如政策、范围说明书的相关程序）、项目文件以及以前做过的类似项目的经验教训。表5-2描述了“开篇案例”所述IT升级项目的项目章程。注意项目章程中的信息是如何为进一步定义项目范围做铺垫的。项目章程描述了为实现项目整体目标的范围、时间和成本目标、项目成功标准、完成项目目标的大致方式以及关键利益相关者的角色和责任。

尽管内容各异，但是项目范围说明书至少应该包括：产品范围描述、产品可接受标准、所有可交付成果的详细信息。它还有助于将其他与项目范围相关的信息文档化，如项目界限、项目的限制条件和假设条件。项目范围说明书也应参考一些支持性文件，如产品的具体说明，它会影响到生产或购买什么样的产品；以及经营政策，它可能影响到如何提供产品或服务。许多IT项目也需要开发软件的功能和设计说明，这些都应该在范围说明书中详细阐述。
　　随着时间的推移，一个项目的范围应该变得更加清晰和具体。例如在表5-2中所示的IT升级项目，其项目章程巾包括了关于服务器、其他计算机，还有IT升级项目可能涉及的软件的简短说明。而表5-3举例说明了在项目范同说明书的版本1和版本2中，范围是如何逐步细化的。

从表5—3中可见，项目范围说明书通常是指一些相关的文件，如产品规格说明、产品手册或者其他计划。随着与项目范围相关的信息以及决定的增加，例如将要购买的具体产品或已批准的变更，项目团队应当不断更新项目范围说明书，可以把范围说明书的不同版本命名为版本1、版本2等。其他项目文件可能也需要随之变更。例如，如果公司必须从以前从未合作过的供应商那里购买项目所需的服务器，那么范围管理计划应该包含与新供应商合作的信息。
　　拥有一份最新的项目范围说明书对于建立和确认项曰范围的一般共识是非常重要的。它具体描述了项目要完成的工作，并且如本章后面所述的，它还是确保顾客满意及预防范围蔓延的一个重要丁具。
　　回顾第1章中提出的项目管理的3个限制条件——实现项目的范围、时间和成本目标。时间及成本目标一般是很简单的。例如，IT升级项目的时间目标是9个月完成，成本目标是l500万美元。而描述、接受并实现许多项目的范围目标则要困难得多。
5.4创建工作分解结构
　　完成范围计划及定义过程之后，项目范围管理的下一步就是创建工作分解结构。工作分解结构( work breakdown structure．WBS)以可交付成果为中心，将项目中所涉及的工作进行分解，定义出项目的整体范围。因为大多数项目涉及很多人，以及很多不同的可交付成果，所以根据工作开展的方式，组织好工作并将其合理地进行分解是非常重要的。WBS在项目管理中是一个功能性的文件，因为它为计划并管理项目的时间进度、成本、资源及变更提供了基础。WBS定义了项目的全部范围，由此一些项目管理专家认为，不包括在WBS中的工作就不应该去做。所以，创建一个良好的WBS是至关重要的。
　　创建工作分解结构的主要输入是：项目范围说明书、利益相关者需求文件和组织过程资产。需要的主要工具或技术是分解( decomposition)，即将项目可交付成果分解为更小的部分。制作WBS这一阶段的输出为WBS、WBS词典、范围基线及项目文件更新。
　　WBS是什么样子的呢？WBS通常画成以任务为导向的各种活动组成的家谱形式，类似一个组织结构图。项目团队经常围绕项目产品、项目阶段，以及使用项目管理过程小组来构建WBS。很多人喜欢首次用图表形式制作WBS，以便能够认清整个项目及其主要的组成部分。例如，图5-3就是一个内联网项目。注意产品结构为其组织结构提供了基础。在此例中，WBS上有主要的模块或分组，包括网页设计、内联网主页、市场营销部页面及销售部页面等。

与之相对应，同样的内联网项目的WBS也可以围绕项目阶段来组织编制，如图5-4所示。注意项目阶段中的概念、网站设计、网站开发、推出及支持阶段为组织结构设计提供了基础。
　　注意图5-4中的层级。工作分解结构中的最高层级即层级1，注明了项目名称。下一层级称为层级2，是层级l的主要分支，包含了工作的主要分组。层级的序号是根据项目管理协会( PMI)的《工作分解结构实践标准》第2版（2006年）编制的。这些分支都可以分解为若干子分支，以体现工作的等级。PMI用“任务”来表示WBS中每一个层级的工作。例如，在图5—4中，以下层级的内容都可用“任务”命名：层级2的内容称为“概念”，层次3的内容称为“定义需求”，层级4的内容称为“定义用户需求”。将任务进一步分解后的部分，称为简要任务。图5-4是分别用图表和表格形式制作的WBS样本。注意，两种形式包含的信息是相同的。许多文件，如合同都使用这种表格形式。项目管理软件也使用这种形式。在Microsoft Project软件中，WBS是“任务名称”栏的内容，而任务层级以任务识别及编号的形式体现。图5-4下半部分左侧的表格编号与Microsoft Project或其他软件的编号方式一致，右侧的表格序号是根据项目管理协会(PMI)的《工作分解结构实践标准》（第2版）编制的。因此，创建工作分解结构时，请确认组织使用哪种编号系统。

在网5-4中，WBS的最低层为层级4。工作包(Work package)即为WBS最低层的一项任务。图5-4中，任务1 2 1，1.2.2，1.2 3和1.2 4（基于左侧的编号系统）都是工作包。其他任务很可能将被进一步分解。但是，WBS的层级2或层级3的一些任务可以保留，其他的可能要分解为层级5或层级6，这要根据工作的复杂程度而定。工作包也代表了项目经理用来监控项目的工作层级。你也可以把工作包理解为问责制和汇报的实施单元。如果一个项目要在短期内完成，并且需要每周都进行进度报告，那么一个工作包可能代表一周或更短时间内的工作。另一方面，如果项目进行时问较长，需要按季度做进度报告，那么一个工作包可能代表一个月或更长时间的工作。工作包也可能是一种或多种具体产品的采购，比如从外部购买这些产品。
　　另一个考虑工作包的方法是，把数据输入项目管理软件。你可以仅仅输入工作包的工期估计，而WBS条目则是工作包的分组或汇总。软件会根据每个工作包输入的数据及WBS层级自动为各种WBS层级计算工期估计。用Project 2007制作WBS的具体说明见附录A。
　　图5=5显示了以项目阶段为导向的内联网WBS，这一工作分解结构使用与图5-4相同的编号计划，并且使用Project 2007制作的甘特图形式。注意，工作分解结构位于任务名称栏下方图示的左边，相应的时间进度位于右边。在第6章中还将详细介绍甘特图。

这里展示的WBS样本看起来相对比较容易制作，也容易理解。然而，真正创建一个好的WBS是很困难的。为制作良好的WBS，你必须了解项目及其范围，并将利益相关者的需求及支持包括进去予以综合考虑。项目经理及项目团队必须决定，作为一个小组如何组织工作，以及WBS中应包括多少层级。许多项目经理发现，重点将WBS最高层次工作做好比陷入更多的细节之中要好得多。
　　许多人将WBS中的任务与具体丁作混淆了。WBS中的任务代表了为完成项目所需开展的工作。例如，你正在为重新设计厨房制作一个WBS，那么层级2可能包括设计、采购、地板材料、墙壁、厨具及设施。但在“地板材料”这一条目下，你可能还有很多工作要做，例如要去除旧地板材料，铺上新材料及配饰等。你不可能一下子细到像“12:14轻质栎木板”或“地板必须耐用”这样的任务和要求。
　　另外，制作WBS时要注意的是，如何编制WBS，以使其为项目时间进度提供基础。你应该关注的是，什么工作需要完成及如何完成，而不是什么时候完成。换句话说，任务不必排成一个有序的清单。你如果打算以时间流程为基础来工作，则可以利用项目管理过程组，即启动、计划、实施、监控及收尾。作为WBS中的层级2来制作WBS，这样做的活，不仅可以使项目团队遵守了良好的项目管理实践，也使WBS任务能更容易地以时间为轴来进行安排。例如，图5-6显示了内联网项目的WBS及甘特图，它们就是通过5个项目管理过程组来进行组织的。启动条目下的任务包括选择项目经理、组建项目团队及制定项目章程。计划条目下的任务包括制作范围说明书、构建WBS、制定及改进其他计划。还可以将这些任务分解得更为详细一些，以使其成为一个真正的项目。在图5-4中，概念、网站设计、网站开发及推出等任务曾是WBS的层级2中的条目，现在成为实施条目之下的WBS层级3的条目。在项目与项目之间，实施条目的任务差别最大，而其他项目管理过程组的条目下的大多数任务刈所有项目来说是很相似的。在WBS中，如果不使用项目管理过程组，你可以将层级2条目设置为项目管理，以确保将与管理项目相关的任务都考虑进来。记住，所有工作都要包括在WBS之中，包括项目管理。
　　JWD咨询公司使用了项目管理过程组作为第3章中项目管理内联网项目的WBS的层级2条目。在分解实施过程中的任务时，项目团队要重点关注他们为产出项目的产品而提供的可交付成果。表5-4显示了团队列于WBS中这个部分建立的相应条目。一些项目团队喜欢列出需要提交的每一个可交付成果，然后用它们作为制作全部或部分WBS的基础。由前面所介绍的内容可知，范围说明书必须罗列并描述项目要求的所有可交付成果。因此，保证项目章程、范围说明书、WBS及甘特图的一致性，精确地确认项目范围是非常重要的。

让项目团队及客户参与创建并商讨WBS也是非常重要的。从事具体工作的人应通过制作WBS来帮助为这些T作制定计划。另外，如果大家都来参与的话，召开团队会议来创建WBS会使每个人都能认识到，要完成整个项目必须要做什么工作，以及如何去做。这电有助于认清在不同的工作包之间有哪些地方需要做好协调工作。

5.4.1  制作工作分解结构的方法
    你可以使用以下几种方法来制作丁作分解结构：
     -使用指南；
     -类比法：
     -自上而下法：
     -自下而上法：
     -心智图法。
1.使用指南
　　如果要制作WBS的指南，那么遵循这一指南非常重要。一些组织，例如美国国防部(DOD)规定了特殊项目的形式和内容。许多DOD项目要承包者根据DOD提供的WBS准备他们的方案。这些方案必须包括WBS中的具体层次及总结层次的每一任务的成本估算。整个项目的成本必须通过所有WBS低一级任务成本加总计算得来。当DOD的人员评价成本方案时，他们必须要将承包者的预算与DOD的预算估计进行对比。如果一项既定的WBS任务在成本方面存在大的偏差，那通常意味着在必须要完成的工作方面出现了异议。
　　下面来看美国空军的一个大的自动化项目。在20世纪80年代中期，空军提出了一个地方联线网络系统( LONS)项目，要求15个空军系统的司令部基地实现联网自动化。这一2.5亿美元的项目包括提供硬件，以及为共享文件，如合同、规格、征求建议等开发软件。空军建议性的指南包括在要求承包商准备预算方案时所遵循的WBS。WBS的层级2条目包括硬件、软件开发、培训和项目管理等。硬件条曰由几个层级3条目构成，如服务器、工作站、打印机和网络硬件等。空军人员通过对比同样依据此WBS做出的内部预算估计来重新评审承包商的预算方案。预先指定的WBS可以帮助供应商准备其预算方案，并帮助空军来评价这些方案。
　　除了应用过去项目中的WBS样本，许多组织还为制作WBS提供指南和模板。Microsoft Project2007有几个模板，在微软的专用网站上还可以找到更多的模板。在很多成员的要求下，美国项目管理协会建立了一个WBS实施标准，为制作及使用项目管理中的WBS提供了指导。这份文件包括了各种行业中多种多样的项目的WBS样本，例如网站设计、通信、服务外包及软件开发等项目。
　　但是，为了更有效地为特定的项目开发WBS，项目经理及其团队应重视自己项目的适当信息。例如，在“开篇案例”中，在为制作WBS召开团队会议之前及期间，Kim Nguyen及其关键团队成员应该仔细考虑公司的WBS创建指南、模板及其他相关信息。
    2.类比法
　　构建WBS的另一种方法是类比法。在类比法(analogy approach)中，会使用一个类似项目的WBS作为起点。比如在“开篇案例”中，Kim Nguyen可能会获悉，其公司的一个供应商去年做过一个类似的IT升级项目。因此她可以询问一下他们，看看是否可以共享这一项目的WBS，这样就为自己的项目提供了一个起点。
　　麦道公司，现在是波音的一部分，给我们提供了一个制作WBS时使用类比法的例子。麦道公司设计并制造了几种不同的战斗机。当为一种新飞机设计制作WBS时，开始是根据过去的经验使用74种提前定义的制造战斗机的子系统来进行的。飞机结构属于WBS的层级2条目，它由诸如前部机身、中部机身、尾部机身及机翼这样的层级3条目构成。这种以产品为导向的WBS为定义新飞机项目的范围，并为新飞机设计进行成本估算提供了一个起点。
　　一些组织还设立专门的地方将WBS及其他项目文件存档保存起来，以帮助人们继续做项目。Project 2007及许多其他软件工具都包含帮助用户制作WBS及甘特图的样本文件。通过浏览其他类似项目的WBS样本，能够使你了解到更多制作WBS的不同方法。
    3.自上而下法和自下而上法
　　其他两种制作WBS的方法是自上而下法和自下而上法。多数项目经理认为，自上而下构建WBS的方法是较为常用的。在使用自上而下法(top-doWn approach）时，要从项目最大的条目开始，并将它们分解为低层次的条目。这一过程要将工作精炼为更加具体的层级。例如，图5-4展示了内联网项目的部分工作是如何被分解到层级4的。在此过程完成之后，所有的资源将被分配到工作包层级。自上而下法对于有深刻的技术洞察力及视野广阔的项日经理是最适用的。
　　在自下而上法( bottom-up approach)中，团队成员首先尽可能多地辨清与项目有关的具体任务，然后聚集这些具体任务并将其汇总成总体性的活动或WBS中更高的层级活动。例如，如果一个小组负责设计电子商务设施制造的WBS，那么他们不是先寻找如何制作WBS的指南依据，也不是先查阅类似项目的WBS，而是一开始就列举他们认为制造此设施需要执行的具体任务。在列举出具体任务后，他们会将任务归类，然后将这些类别再组成更高层级的类别。有人发现，将所有可能的任务先记录下来，然后贴在墙上，可有助于看清项目所需要的所有工作，并为开展工作进行合理分组。例如，项目团队的业务分析师知道，他们必须要为电子商务设施项目定义用户需求及内容需求。这些任务可能是他们必须要完成的且作为项目可交付成果之一的需求文件的一部分。硬件专家知道他们必须要定义系统需求和服务器需求，这些也是需求文件的一部分。作为一个群体，他们可能会决定将这4部分任务放在更高一级条目“定义需求”之下，这一条目会产生作为可交付成果之一的需求文件。然后他们会认识到，同其他与概念设计相关的任务类别一样，定义需求应该放在电子商务设施项目中“概念设计”这一更宏大的分类之中。出上可见，自下而上法非常费时，但同时也是非常有效的制作WBS的方法。项目经理经常将自下而上法用于描述新系统，或作为完成工作的方法，或帮助创造团队建立共识和互信。
    4.心智图法
　　有些项目经理喜欢使用心智图法来帮助构建WBS。心智图法（mind mapping）是一种结构分解的技术，通过从一种核心理念发散出来，将思想和想法结构化。心智图法不是将任务列成清单或立即试图构建任务结构，而是让人们写下甚至用非线条方式画出心智图。它是一种更加可视化、结构限制少、先定义后再组织任务的方法，可以发挥个人的创造力，并提高团队的参与度和士气。
　　图5-7显示了如何使用心智图法来为第3章中的IT升级项目制作WBS，是用Mindjet的Mind-manager软件制作的。中心的圆圈代表整个项目，从中心辐射出的4大主枝，每枝代表WBS的主要任务或层级2条目。在使用和制作此心智图的人中，不同人在项目中扮演不同的角色，以此来帮助确定项目的任务及WBS结构。例如，Kim虽然想要注重所有的项目管理任务，而她可能也知道，自己仅仅有能力忙于一个单独的预算分类。类似地，熟悉获取或安装硬件、软件的人可能会关注获取或安装工作等。从主任务“更新库存”中分离出来的是两个子任务：“进行实物盘点”及“数据库升级”。“进行实物盘点”下的子任务是3个更细的子分支，标记为建筑A、建筑B及建筑C等。直到想不出还有什么T作需要做了，团队才会不再继续增加分支及条目。

在使用心智图技术开发出WBS条目及结构后，你可以将有关信息转换为如前所述的图表或表格形式。MmdManager软件的特点在于，你可以将做出的心智图导人Microsoft Project软件。Microsoft Project根据心智图，自动创建WBS结构，并在“任务清单”栏中生成WBS。图5-8是IT升级项目中生成的Project 2007文档。

在使用白上而下法或自下而上法制作WBS时都可以应用心智罔法。例如，如果要为整个IT项目绘制心智图，可通过在一个文件的中心列出整个项目，增添从中心辐射出来的主要类别分支，然后增添相应子类别分支。当然，你也可以为每一个可交付成果制作不同的心智图，然后将其合并组成整个项目的大图。还可以不用遵循严格的自上而下法或岛下而上法，而是在心智图绘制文件上随处增添条目。当完成心智图绘制文件后，也可将其转换为WBS的图表形式。
5.4.2  WBS词典及范围基线
　　如同你从WBS的样本中所看到的，列出的许多条目是相当含糊的。例如，“数据库升级”确切地说是什么意思？负责此任务的人可能认为，这样就可以了，无须再往下分解了。然而，对此任务还必须更详尽地予以描述，以便每个人都能对其所包含的内容有相同的理解。如果其他人实施此任务的话，他会做些什么呢？你要告诉他做什么？完成此任务要花费多少时间？因此，还需要更详尽的信息来回答这些问题，以及其他一些问题。
　　WBS词典(WBS dictionary)是一个描述WBS每项条目详细信息的文件。WBS的格式可根据项目的需要而定，有时仅用简短篇幅描述一下每一工作包就可以了。但对更为复杂的项目而言，丁作包描述可能需要一整页甚至更多。有些项目可能要求对每一个WBS的条目都要描述负责的组织、资源需求、预算费用以及其他一些信息。
　　Kim应该和她的凼队及项目发起人一起共同决定WBS词典所需要的详细程度。他们还应当确定这些信息需要输入到哪里，以及如何进行更新。项目团队通常会参考类似任务的WBS词典条目，以便更好地了解如何编制这些条目。对IT升级项目来说，Kim和她的团队决定遵循部门的相关指南，将所有WBS词典的信息输入到公司的项目管理系统。表5-5是一个条目的词典示例。

核准的项目范围说明书及其相关的WBS和WBS词典构成了范围基线。实现项目范围目标的绩效依据的就是这个范围基线。
5.4.3构建WBS及WBS词典的建议
　　如前所述，构建一个好的W-BS并不是一项简单的任务，一般要遵循几项要求。通常最好是将几种方法结合起来构建项目的WBS。这里有一些基本原则可以适用于构建任何良好的WBS及WBS词典。
　　 -一个工作单元应该只出现在WBS中一次。
　　 -一个WBS条目的工作内容是它下一级WBS条目的总和。
　　 -一个WBS条目仅有一人自责，尽管可能有很多人在为其工作。
　　 -WBS必须与实际开展工作的方式保持一致；它必须首先为项目团队服务，然后如果可行的话，再服务于其他目的。
　　 -项目团队成员应当参与建立WBS，以确保一致和遵从。
　　 -每一WBS条目必须记载在WBS词典中，以确保大家都能准确明白该条目包含及不包含哪些工作范围。
　　 -在根据范围说明书进行项目工作内容控制时，WBS必须是一个能灵活变通的工具，以应对一些不可避免的变更。
5.5范围核实
　　为一个项目制定出好的项目范围说明书及WBS是很难的。特别是对IT项目而言，要核实范围并将范围变更最小化则更难了。一些项目团队一开始就知道，范围非常不明确，并且他们必须与项目客户密切合作，共同设计并产出各种可交付成果。在这种情况下，项目团队必须为满足特殊项目需求的范围验证建立一个流程；必须设立详细的步骤确保客户得其所需，并且项目团队有足够的时间和资金来产m所需的产品和服务。
　　就算界定了项目范围，许多IT项目还是会遭遇范围蔓延——项目范同越来越大的趋势。有很多由于范围问题，如范围蔓延（scope creep），导致IT项目失败的可怕的事例，一些典型的例子可参考下文“错在哪里”，因此在贯穿项目生命周期的整个过程中与用户一起更新项目范围并为控制范围变化设立流程是非常必要的。
错在哪里
　　一个项目的范围如幂太宽泛、庞大将会引发许多问题。范围蔓延以及出于技术考虑过分强调技术，导致了一个大制药公司--总部设在德州的FoxMeyer药物公司破产了。994年，公司CIO开发了一个价值6500万美元的系统来管理公司的关键运营。然而他并不相信把事情做简单的意义何在。公司将1000万美元投在先进的硬件和软件上，并通过签订合同将项目的管理工作外包给一家有威望且收费昂贵的咨询公司。据知情人说，项目包括建设造价1800万美元的机械化货仓，此货仓看起来像出自一部科幻电影。项目范围变得越来越炙且更加不切实际。这一精心打造的货仓并没有按时完成，帮系统引发的秩序混乱使FoxYkyer药物会司在无法挽回的过量运输土损失了1500万美元。1996年7月，公司第4个财政季度损失了3400万美元。当年8月，FoxMleyer药物公司申请破产。6范围蔓延的另一个例子是麦当劳餐馆。2001年，该快餐连锁店开始了构建内联网的项目。此内联网将总部与所有的餐馆联系起来，可以宾时提供详细的运营信息。例如，总部要知道销售颤是否下降或每家后铺烧烤温度是否正确--在120多个国家的所有3万家店里。麦当劳没有透露详细信息，但他们承认此项目规模及范围太大。在花费了l7亿美元用于咨询及初期执行计划后，麦当劳认识到要控制并完成到这一项目是太困难了。
　　IT项目的另一个主要范围问题是缺少用户参与。在20世纪80年代末期，在Northrop Grumman，一家专业生产国防电子产品、信息技术、高端飞行器、造船度空问技术的公司里，一个IT项目团队认为能够且应该将审查和批准政府建议的过程自动化。固阻开发了一个强有力的工作流程系统来管理整个过程。不幸的是，此系统的最终用户是航天技术工程师，他们喜欢以更加轻松、随意的方式工作．他们称此系统为“纳粹软件”并拒绝使用。此例展现的是一个耗费数百万美元构建一个与最终用户工作方式并不一致的系统的IT项目。
　　不遵守良好的、规范的项目管理过程并应用现成的软件，也会导致范围问题。坐落于加刺福尼亚Woodland I-1ills的21世纪保险集团支付了l亿美元给一家电脑技术公司，要为业务管理建立一个系统，包括管理保险政策、账单、赔偿及客户服务。5年后，也就是2002年，该系统仍在建设之中，并且仅可以支持不到2%的公司业务。Joshua Greenbauni是企业应用咨询的一个分析师，他称此项目为一个“巨大灾难”，并质疑保险公司的能力“能否管理好最新流行的过程，我怀疑使用现有的东西来建立他们需要的系统并降低风险是没法实现的。”
　　范围核实（scope verification）是由利益相关者对已界定的项目范围进行的正式确认。这一确认通常由客户检查完成，然后由关键利益相关者来收尾。为获得项目范围的正式验证，项目团队必须建立项目产品和程序的清晰的文档存储，以评价项目团队在产出产品和遵守程序上是否正确及令人满意。如第4章所述，配嚣管理专家会确认并将项目产品的功能特性和物理特性存档，记录并报告出现的变更，审核产品并证明其是否与需求一致。要将范围变更最小化，做好配置管理及项目范围核实工作很关键。
　　项目管理计划、需求文件、需求跟踪矩阵和成果验证是范围核实工作的主要输入。开展范围核实的主要工具是检查。工作结束后由客户、项目发起人或用户进行检查。范围核实的主要输出是验收的可交付成果、变更请求、项目文件更新等。例如，假设Kim的团队成员将升级的电脑交付给用户作为IT升级的一部分。可能有几个用户会提出抱怨，因为电脑没有他们由于医学需要的特殊键盘。有关人员会商讨这一变更需求，并采取相应的纠正措施，如在得到项目发起人的许可后购买特殊的键盘。
5.6范围控制
　　如第4章集成变更控制部分所讲的，在项目中出现变更是无法避免的，尤其是押项目的范围变更。范围控制( scope control)是指控制项目范围的变更。用户通常不明确他们想要的系统界面看起来是什么样子的，或者他们实际上需要什么功能来改善经营业绩。开发商不能明确是否准确理解了用户需求，而且他们还要面对不断变化的技术环境。
　　范围控制的目的是对那些引起范围变化的因素施加影响，确保变更能依据集成变更控制建立的程序有序进行，并管理已发生的变更。如果没有做好需求收集、范围定义和验证工作，就不可能做好范围控制工作。如果你没有同意做某项工作，并且发起人还未证实计划的工作得到验收，那你如何预防范围蔓延？所以你需要为要求并监测项目范围变更设立一个流程，应该激励利益相关者针对有益于整个项目的变更提出建议，同时拒绝那些项目不需要的变更建议。
　　范围控制的主要输入有：项目范围管理计划、工作绩效信息、需求文件、需求跟踪矩阵和组织过程资产。范围控制的主要工具是实施偏差分析。偏差（vanance）是指计划与实际绩效的差异。比如，供应商本该提供5个键盘，而你只收到了4个，那么偏差是1个键盘。范围控制的输出包括工作绩效测量结果、组织过程资产更新、变更请求、项目管理计划更新以及项目文件更新。
　　表l-2曾列举了有助于IT项目成功的前10大因素。在这10个因素中，有4个与范围核实和控制相关：客户参与、明确的目标、较小或清晰定义的范围以及公司的基本需要。因此，为避免项目失败，对IT项目经理及其团队来说，至关重要的是要共同致力于提高用户投入程度，减少不完整且不断变化的需求及说明书。
　　下面的内容提供了更多的有关改进IT项目范围管理的建议。
5.6.1  提高用户投入的建议
　　缺少用户的投入导致了管理范围蔓延及控制的变更。如何管理这些重要的问题呢？下面是提高用户投入的一些建议。
　　-为IT项目设立良好的选择过程。要确保所有项目都有来自用户组织的发起人。项目发起人应该既不是IT部门中的某个人，也不是项目经理。要确保项目信息，包括项目章程、项目管理计划、项目范围说明书、WBS及WBS词典，在组织中很容易获得。获得基本的项目信息可以帮助避免重复劳动，并保证最重要的项目正是人们在做的项目。
　　-项目团队中有用户参与。一些组织要求项目经理来自项目的业务领域而非IT部门。一些组织任命IT项目的合作项目经理，一个来自IT部门，一个来自主要的经营部门。应该将用户全职分配给大的IT项目，兼职配置给小的项目。美国西北航空公司ResNet项目的一个关键成功因素是培训预订系统代理人——用户如何为他们新的预订系统编写程序代码。因为精通经营知识，所以销售代表提供了优质的输入信息并且实际开发了大多数软件。
　　-在既定日程举行定期会议。常规性会议显然是需要的，但是很多IT项目失败是因为项目团队成员没有与用户定期进行相互沟通。没有得到直接的反馈信息，他们就自认为知晓了用户所需。为促进这种相互沟通，用户应该在会议上提交的关键可交付成果上签字。
　　-定期向项目的用户和项目发起，人交付一些成果。如果是硬件或软件之类的，应确保优先完成。
　　-不要承诺在特殊的时间框架内交付不能交付的成果。应确保在项目时间进度中有足够时间产生可交付成果。
　　-用户和开发商共处一处办公室。空间距离接近时，人们通常更容易了解对方。如果用户在整个项目期间不能搬至邻近承包商处，他们应拿出一些时间来共处。
5.6 2减少不完整的和不断变化的需求的建议
　　对IT项目来说，可以预计会发生某些需求变更，而许多项目出现了太多的需求变更，特别是在项目生命周期末期实施变更困难的时候。有关改进需求过程的建议如下：
　　-设立并遵循一个需求管理过程。这一过程包括确定初步需求的程序。
　　-利用某些技术工具，如原型制作、用况模型创建法及合作应用技术程序设计来全面了解用户需求。原型制作( prototyping)是指设计一个系统或系统某些方面的工作模型。这些工作模型可能是一次性的或者是可交付系统附属的部分。原型制作是为了获得对需求的认识、确定需求的可行性及解决用户界面不确定性而使用的一个有效工具。用况模型创建法( use case modeling)是一个辨识业务经营事件并将其建模的过程，例如谁引发这些事件，系统如何应对这些事件等。它是了解信息系统需求的有效工具。合作应用程序设计(jointapplication design，JAD)使用高层组织的、深入的专题讨论会将项目利益相关者--项目发起人、用户、业务分析师、程序员等聚集在一起，共同定义并建立信息系统。这些技术也可帮助用户更好地参与定义系统的需求。
　　-记录所有的需求信息，随时更新，并且随时可获得。要想自动实施此功能，有几种工具可行。比如，一种叫做“需求管理工具”的软件可帮助获取并保存需求信息，还可及时存取信息，并帮助建立需求与其他工具构建的信息之间的必要关系。
　　-为文档化及控制需求构建需求管理数据库。计算机辅助软件工程( CASE)或其他技术可帮助存储项目数据。一个CASE工具的数据库也可用于存储和控制需求。
　　-进行适当的测试，以证明项目产品能否满足需求。测试要贯穿整个项目生命周期。在第8章包含了更多的关于测试的信息。
　　-从系统角度使用某种过程方法来审视所要求的需求变更。比如，要确保项目范围变更中有相应的成本及时间进度的变更；要获得适当的利益相关者的同意。对项目经理而言，至关重要的是要领导团队致力完成认可的范围目标，并且不能把重点转到额外的工作上。例如，Andy Crowe在他的《阿尔法项目经理》中试图揭示“最佳的”或“阿尔法”项目经理与其他项目经理做事的区别。其中一位阿尔法项目经理提到了他是如何学习一节有关范围控制重要一陛的课程的：
　　“在我做过的一些项目接近结束时，经理们真的让其团队工作了太长时间。当这种事情接二连三发生时，我仅仅以为事情本来就是这样的。其后我与另一位经理共事，这位经理把任何事情计划得非常好，始终使团队按节拍运转，并且我们一直遵守时间进度安排。当发现项目如期进行时，客户试图增加范围，但这次我们有一个优秀的经理，没有调整基准，她不会让客户这么做的。那是第一次我所工作的项目的所有事情都按时按预算完成。对她为何如此轻松地完成工作我感到很惊讶。”;
　　-强调完工日期。比如，在密苏里州堪萨斯市的Farmland Industries公司里有一位项目经理．通过设定项目的截止时间，使一个历时15个月、耗资700万美元的一体化供应链项目按部就班地完成了。她说：“5月1日是最后期限，其他所有事情都要以此为依据。用户如果来我们这里并要求我们做某事，那么我们就要问他们放弃什么来交换。坚持此日期是我们管理范围蔓延的一个方法”。
　　-为处理变更需求专门分配资源。例如，美国西北航空公司的Peeter Kivestu与他的ResNet团队获悉，用户要求他们增强正在开发的预订系统。为满足用户请求，他们在ResNet屏幕上增加了一个特殊的功能键，并且项目安排了3名专职程序员来处理这些请求。用户提出了11000多个强化请求。发起4名主要软件应用项目的经理梳理了软件强化请求的优先次序，并作为一个小组决定同意哪些变更。然后这3名程序员按优先次序，在给定时间内处理尽可能多的变更条目。尽管他们仅处理了强化请求的38%，但是这部分却是最重要的，并且用户对系统及过程感到非常满意。
5.7利用软件辅助项目范围管理
　　项目经理及其团队可以使刷几种软件辅助项目范围管理。正如本章的各种图表所示，你可以使用文字处理软件来编辑与项目范围相关的文件；也可以像大多数人那样，使用电子表格或演示软件来构建范围管理相关的各种图表、瞌线图和模型，也可以用心智图软件创建WBS。项目利益相关者也利用各种沟通软件，如电子邮件和各种基于网络的应用系统，来传输项目范围管理的信息。
　　项目管理软件可以帮你建立WBS，进而为构建甘特图、分配资源、分担成本等提供基础。你还可使用各种项目管理软件附带的模板为项目制作WBS。关于使用Project 2007的详细信息可参见附录A中项目范围管理部分。
　　你也可以使用各种专业化软件来支持项目的范围管理。许多IT项目使用特殊软件来进行需求管理，像原形制作、建模及其他与范围相关的工作。范围是项目管理中至关重要的部分，因此有许多可行的软件产品可以帮助管理项目范围。
　　项日范围管理非常重要，特别是对于IT项目。筛选项目后，组织必须计划开展项日工作的内容，将丁作分解为便于管理的部分。要与项目利益相关者共同验证范围，并管理项目范同的变更。应用本章所讲的基本项目范围管理概念、工具及技术司成功地实施项目范闹管理。
案例结局
　　Kim Nguyen再次审视了由公司爱其他渠道获得的构建WBS的相关指南。她与3位项目团队领导召开了一次会议，着手计划他们可提供的输人。在商讨了几种样本文件后，他们决定根据最新的库存清单，将项目工作分组，包括获取需要的硬件和软件，安装硬件和软件，实旋项目管理。在确定了基本方法后，Kim与整个项目团队共计12个人又召开了会议。她匪顾了项匿章程和利益相关者记录，说明了收集需求和定义项目范围的基本方法，评论了一些WBS样本。Kim请大家畅所欲言，提出问题，并非常自信地进行了解答。然后她让每个豳队主管与自己的成员起共同开始撰写详细的范围说明书以及ViBS和ViBS词典的相应部分。每个人都参加了会议，分享了个人的专业技能，公开提问。Kim看到项目有了一个良好的开端。