项目范围管理（中英文对照）
Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and controlling what is or is not included in the project. Figure 5-1 provides an overview of the major project scope management processes:
项目范围管理包括确保项目成功完成所必需的所有且是仅仅需要工作。它主要关心定义和控制什么包括或什么不包括在项目中。图5-1是项目范围管理过程的概览：
5.1 Initiation—commiting the organization to begin the next phase of the project.
立项－证实组织开始项目的下个阶段。
5.2 Scope Planning—developing a written scope statement as basis for future project decisions.
范围计划编制－制定范围说明，作为未来项目决策的基础。
5.3 Scope Definition—subdividing the major project deliverables into smaller, more manageable components.
范围定义－将主要的项目可交付成果分成小的、容易管理的部分。
5.4 Scope Verification—formalizing acceptance of the project scope.
范围核实－正式接受项目范围。
5.5 Scope Change Control—controlling changes to project scope.
范围变更控制－控制项目范围的变更。
相关图片如下
Figure 5-1 Project Scope Management Overview
These processes interact with each other and with the processes in the other knowledge areas as well. Each process may involve effort from one or more individuals or groups of individuals based on the needs of the project. Each process generally occurs at least once in every project phase.
这些过程相互之间以及同其它知识领域的过程交互作用。每个过程包含了基于项目需求的个人或集体的努力。每个过程在每个项目阶段一般至少发生一次。
Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here. Process interactions are discussed in detail in Chapter 3.
尽管这里描述的过程有定义很好的接口，并且是独立、离散的要素，实际上它们以这里未描述的方式重叠和交互作用。第3章中详细讨论过程的交互作用。
In the project context, the term “scope” may refer to:
在项目概念中，术语“范围”是指：
· Product scope—the features and fuctions that are to be included in a product or service.
产品范围－产品或服务中包含的特征和功能。
· Project scope-the work that must be done in order to deliver a product with the specified features and functions.
项目范围－为了交付具有特定特征和功能的产品所必须做的工作。
The processes, tools and techniques used to manage project scope are the focus of this chapter. The processes, tools and techniques used to manage product scope vary by application area and are usually defined as part of the project life cycle (the project life cycle is discussed in Section 2.1).
用于管理项目范围的过程、工具和技术是本章的焦点。用于管理产品范围的过程、工具和技术随应用领域的变化而变化，并常定义为项目寿命期（见2.1节）的一部分。
A project consists of a single product, but that product may include subsidiary elements, each with their own separate but interdependent product scope. For example, a new telephone system would generally include four subsidiary elements—hardware, software, training and implementation.
项目包括单一的产品，但是产品可能包括辅助要素，每个有自己单独的但相互依赖的产品范围。例如，一个新的电话系统通常包括四个辅助要素－硬件、软件、培训和实施。
Completion of the product scope is measured against the requirements while completion of the project scope is measured against the plan. Both types of scope management must be well integrated to ensure that the work of the project will result in delivery of the specified product.
产品范围的完成以需求来衡量而项目范围的完成则是计划。两种类型的范围管理必须很好结合，确保项目工作可以得到特定产品这个交付成果。
第二篇：项目范围管理1(中英文对照)
D ocuments
Chapter 5 Project Scope Management
（第5章 项目范围管理）
Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and controlling what is or is not included in the project. Figure 5-1 provides an overview of the major project scope management processes:
项目范围管理包括确保项目成功完成所必需的所有且是仅仅需要工作。它主要关心定义和控制什么包括或什么不包括在项目中。图5-1是项目范围管理过程的概览：
5.1 Initiation—commiting the organization to begin the next phase of the project.
立项－证实组织开始项目的下个阶段。
5.2 Scope Planning—developing a written scope statement as basis for future
project decisions.
范围计划编制－制定范围说明，作为未来项目决策的基础。
5.3 Scope Definition—subdividing the major project deliverables into smaller,
more manageable components.
范围定义－将主要的项目可交付成果分成小的、容易管理的部分。
5.4 Scope Verification—formalizing acceptance of the project scope.
范围核实－正式接受项目范围。
5.5 Scope Change Control—controlling changes to project scope.
范围变更控制－控制项目范围的变更。
-1-
D
ocuments
Figure 5-1 Project Scope Management Overview
These processes interact with each other and with the processes in the other knowledge areas as well. Each process may involve effort from one or more individuals or groups of individuals based on the needs of the project. Each process generally occurs at least once in every project phase.
这些过程相互之间以及同其它知识领域的过程交互作用。每个过程包含了基
-2-
D ocuments
于项目需求的个人或集体的努力。每个过程在每个项目阶段一般至少发生一次。
Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here. Process interactions are discussed in detail in Chapter 3.
尽管这里描述的过程有定义很好的接口，并且是独立、离散的要素，实际上它们以这里未描述的方式重叠和交互作用。第3章中详细讨论过程的交互作用。
In the project context, the term “scope” may refer to:
在项目概念中，术语“范围”是指：
z Product scope—the features and fuctions that are to be included in a product
or service.
产品范围－产品或服务中包含的特征和功能。
z Project scope-the work that must be done in order to deliver a product with
the specified features and functions.
项目范围－为了交付具有特定特征和功能的产品所必须做的工作。
The processes, tools and techniques used to manage project scope are the focus of this chapter. The processes, tools and techniques used to manage product scope vary by application area and are usually defined as part of the project life cycle (the project life cycle is discussed in Section 2.1).
用于管理项目范围的过程、工具和技术是本章的焦点。用于管理产品范围的过程、工具和技术随应用领域的变化而变化，并常定义为项目寿命期（见2.1节）的一部分。
A project consists of a single product, but that product may include subsidiary elements, each with their own separate but interdependent product scope. For example, a new telephone system would generally include four subsidiary elements—hardware, software, training and implementation.
项目包括单一的产品，但是产品可能包括辅助要素，每个有自己单独的但相
-3-
D ocuments
互依赖的产品范围。例如，一个新的电话系统通常包括四个辅助要素－硬件、软件、培训和实施。
Completion of the product scope is measured against the requirements while completion of the project scope is measured against the plan. Both types of scope management must be well integrated to ensure that the work of the project will result in delivery of the specified product.
产品范围的完成以需求来衡量而项目范围的完成则是计划。两种类型的范围管理必须很好结合，确保项目工作可以得到特定产品这个交付成果。
5.1 Initiation（立项）
Initiation is the process of formally recognizing that a new project exists or that an existing project should continue into its next phase (see Section 2.1 for a more detailed discussion of project phases). This formal initiation links the project to the ongoing work of the performing organization. In some organizations, a project is not formally initiated until after completion of a feasibility study, a preliminary plan, or some other equivalent1 form of analysis which was itself separately initiated. Some types of projects, especially internal service projects and new product development projects, are initiated informally and some limited amount of work is done in order to secure the approval needed for formal initiation. Projects are typically authorized as a result of one or more of the following:
立项是正式认可一个新项目开始或一个已经存在的项目可以继续下个阶段的过程（项目阶段的详细讨论见2.1节）。正式立项将项目同执行组织的连续业务相联系。在某些组织，项目只有在可行性研究、初步计划或其它一些同类分析工作完成之后才正式立项。一些类型项目，特别是内部服务项目和新产品开发项1 a.相当的，相同的
-4-
D ocuments
目，立项并不正式，做一些有限的工作即可获得认可。项目是由于下面的一个或多个原因产生并获得认可：
z A market demand (e.g., an oil company authorizes a project to build a new
refinery2 in response to chronic3 gasoline shortages).
市场需求（比如，一个石油公司针对持续石油短缺的情况，决定建立一个建造新的精练厂的项目）。
z A business need (e.g., a training company authorizes a project to create a
new course in order to increase its revenues).
商业需求（比如，一个培训公司为增加收入建立一个开设新课程的项目）。
z A customer request (e.g., an electric utility authorizes a project to build a
new substation4 to serve a new industrial park).
用户请求（电力部门建立一个新变电站项目向一个新的工业区提供电力资源）。
z A technological advance (e.g., an electronics firm authorizes a new project
to develop a video game player after the introduction of the video cassette recorder).
技术领先需求（比如，一个电子公司在录像机进入市场后建立一个开发视频游戏播放机的项目）。
z A legal requirement (e.g., a paint manufacturer authorizes a project to
establish guidelines for the handling of toxic materials).
法律要求（比如，一个涂料厂商建立一个项目为处理有毒材料提供指南）。 2
3
4 n.精练厂 a.慢性的，长期的 n.分站，变压所
-5-
D ocuments
These stimuli may also be called problems, opportunities, or business requirements. The central theme5 of all these terms is that management generally must make a decision about how to respond.
这些原因也可称为问题、机会或商业需求。它们的中心议题是管理者必须对如何响应做出决策。
5.1.1 Inputs to Initiation（立项的输入）
.1 Product descriptions. The product description documents the characteristics of the product or service that the project was undertaken to create. The product description will generally have less detail in early phases and more detail in later ones as the product characteristics are progressively elaborated.
.1 产品描述。产品描述是说明项目所产生的产品或服务的特征。产品描述通常在项目早期决定细节较少，随着产品特征逐步细化细节增加。
The product description should also document between the product or service being created and the business need or other stimulus that give rise to the project (see list above). While the form and substance of the product description will vary, it should always be detailed enough to support later project planning.
产品描述也应说明产品或服务同商业需求以及其它导致项目产生的原因（上5 n.主题，论题
-6-
D ocuments
述列表）之间的关系。尽管产品描述的形式和实质会不同，它们都应有足够的细节来支持后续的项目计划编制。
Many projects involve one organization (the seller) doing work under contract to another (the buyer). In such circumstances, the initial product description is usually provided by the buyer. If the buyer’s work is itself a project, the buyer’s product description is a statement of work as described in Section 12.1.3.2.
许多项目包含一个组织（销售者）同另一个组织（购买者）以合同关系的方式工作。在这种情况下，产品描述通常由购买者提供。如果购买者本身的工作就是项目，购买者的产品描述是一个工作说明，见12.1.3.2节。
.2 Strategic plan. All projects should be supportive of the performing organization’s strategic plan—the strategic plan of the performing organization should be considered as a factor in project selection decisions.
.2 战略计划。所有项目都应支持执行组织的战略计划－执行组织的战略计划应作为项目选择的一个因素。
.3 Project selection criteria. Project selection criteria are typically defined in terms of the product of the project and can cover the full range of possible management concerns (financial return, market share, public perceptions, etc.).
.3 项目选择准则。项目选择准则典型地按照项目产品来定义，并且覆盖可能管理到的各个方面（投资回报、市场占有率、公众理解等）。
.4 Historical information. Historical information about both the results of previous project selection decisions and previous project performance should be considered to the extent it is available. When initiation involves approval for the next phase of a project, information about the results of precious phase is often critical.
.4 历史信息。有关以前项目选择决策的结果和以前项目执行情况的历史信息都应按合适的程度予以考虑。当批准项目的下个阶段开始立项时，有关前阶段
-7-
的结果信息通常十分关键。
D ocuments
5.1.2 Tools and Techniques for Initiation（立项的工具和技术）
.1 Project selection methods. Project selection methods generally fall into one of two broad categories:
.1 项目选择方法。项目选择方法通常分为两大类：
z Benefit measurement methods—comparative approach, scoring models,
benefit contribution, or economic models.
利益衡量法－对比法、计分模型、利益贡献或经济模型。
z Constrained optimization methods—mathematical models using linear,
nonlinear, dynamic, integer, and multi-objective programming algorithms.
有限优化法－使用线性、非线性、动态、整数和多目标编程算法的数学
模型。
These methods are often referred to as decision models. Decision models include generalized techniques (decision trees, forced choice, and others) as well as specialized ones (Analytic Hierarchy Process, Logical Framework Analysis, and others). Applying complex project selection criteria in a sophisticated model is often treated as a separate project phase.
决策模型包括通用技术（决策树、强制选择等）这些方法也经常指决策模型。
和专门技术（解析层次过程、逻辑框架分析等）。在复杂模型中应用项目选择准则通常作为一个单独的项目阶段。
.2 Expert judgment. Expert judgment will often be required to assess the inputs to this process. Such expertise6 may be provided by any group or individual with specialized knowledge or training and is available from many sources including: 6 n.专门技能，专门知识
-8-
D ocuments
.2 专家判断。评估本过程的输入时经常需要专家判断。这些专门技术由具有专业知识和培训的个人和团体提供，包括：
z Other units within the performing organization.
执行组织的其它单位。
z Consultants.
顾问。
z Professional and technical associations.
专业和技术协会。
z Industry groups.
工业集团。
5.1.3 Outputs from Initiation（立项的输出）
.1 Project charter. A project charter is a document that formally recognizes the existence of a project. It should include, either directly or by reference to other documents:
.1 项目章程。项目章程是正式承认项目存在的文件。它应直接或以参考的形式包括：
z The business need that the project was undertaken to address.
项目致力满足的商业需求。
z The product description (described in Section 5.1.1.1).
产品描述（见5.1.1.1节）。
The project charter should be issued by a manager external to the project and at a level appropriate to the need of the project. It provides the project manager with the authority to apply organizational resources to project activities.
项目章程应该由项目以外并且处于适合项目要求的级别的管理者来发布。它
-9-
D ocuments
向项目经理提供将组织资源应用到项目工序中的权力。
When a project is performed under contract, the signed contract will generally serve as the project charter for the seller.
当项目以合同形式执行时，签订的合同通常作为销售者的项目章程。
.2 Project manager identified/assigned. In general, the project manager should be identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of project plan execution (described in Section 4.2) and preferably before much project planning has been done (the project planning processes are described in Section 3.3.2).
.2 项目经理的认可和任命。项目经理应尽早任命，如项目的可行性论证阶段。一般情况，项目经理应在项目计划实施（见4.2节）之前任命，最好在项目计划编制（项目计划编制过程见3.3.2节）之前。
.3 Constraints. Constraints are factors that will limit the project management team’s options. For example, a predefined budget is a constraint that is highly likely to limit the team’s options regarding scope, staffing, and schedule.
.3 限制。限制是指限制项目管理队伍进行选择的因素。例如，一个预先定义的预算很可能使队伍在范围、人员和进度方面的考虑有所限制。
When a project is performed under contract, contractual provisions will generally be constraints.
当项目以合同形式执行时，合同条款一般要成为限制。
.4 Assumptions. Assumptions are factors that, for planning purposes, will be considered to be true, real, or certain. For example, if the date that a key person will become available is uncertain, the team may assume a specific start date. Assumptions generally involve a degree of risk. They may be an output of risk identification (described in Section 11.1).
.4 假定。对于计划而言，假定是被认为正确的、真实的或确定的要素。例
-10-
D ocuments
如，如果一个关键人物就位的时间不确定，那么队伍将假定一个具体的开始时间。假定通常包含一定程度的风险。假定可能是风险识别过程（见11.1节）的输出。
5.2 Scope Planning（范围计划编制）
Scope planning is the process of developing a written scope statement as the basis for future project decisions including, in particular, the criteria used to determine if the project or phase has been completed successfully. A written scope statement is necessary for both projects and subprojects. For example, an engineering firm contracted to design a petroleum processing plant must have a scope statement defining the boundaries of its work on the design subproject. The scope statement forms the basis for an agreement between the project team and the project customer by identifying both the project objectives and the major project deliverables.
范围计划编制是建立一个书面范围说明的过程，范围说明作为项目未来决策的基础，特别是决定项目或阶段是否成功完成的准则。一个书面的范围说明对于项目和子项目都是必须的。例如，一个工程公司承接了一个石油处理厂设计的合同，那么必须有一个定义设计子项目工作边界的范围说明。通过确定项目目标和主要的项目可交付成果，项目范围在项目队伍和项目用户中间形成一个协议基础。
If all the elements of the scope statement are already available (e.g., a request for proposal may identify the major deliverables, the project charter may define the project objectives), this process may involve little more than physically creating the written document.
如果范围说明的所有要素都具备（例如，标书定义主要可交付成果，项目章程定义项目目标），那么范围计划编制过程除了产生书面文档之外，其它要做的
-11-
工作就很少了。
D ocuments
5.2.1 Inputs to Scope Planning（范围计划编制的输出）
.1 Product description. The product description is discussed in Section 5.1.1.1. .1 产品描述。见5.1.1.1节。
.2 Project charter. The project charter is described in Section 5.1.3.1.
.2 项目章程。见5.1.3.1节。
.3 Constraints. Constraints are described in Section 5.1.3.3.
.3 限制。见5.1.3.3节。
.4 Assumptions. Assumptions are described in Section 5.1.3.4.
.4 假定。见5.1.3.4节。
5.2.2 Tools and Techniques for Scope Planning（范围计划编制的工具和技术）
.1 Product analysis. Product analysis involves developing a better understanding of the product of the project. It includes techniques such as system engineering, value engineering, value analysis, function analysis, and quality function deployment7. 7 n.配置
-12-
D ocuments
.1 产品分析。产品分析包含对项目产品建立一个更好的理解。它包括系统工程、价值工程、价值分析、功能分析和质量功能配置等技术。
.2 Benefit/cost analysis. Benefit/cost analysis involves estimating tangible and intangible costs(outlays) and benefits(returns) of various project alternatives, and then using financial measures such as return on investment or payback period to assess the relative desirability of the identified alternatives.
.2 效益/成本分析。效益/成本分析包括评估各种项目方案的有形和无形的成本（费用）和效益（回报），然后用金融的衡量尺度（如投资回报率、回报周期）来评估选定方案的相对期望。
.3 Alternatives identification. This is a catchall8 term for any technique used to generate different approaches to the project. There are a variety of general management techniques often used here, the most common of which are brainstorming and lateral9 thinking.
.3 方案确定。对于许多用于产生项目的不同方法的技术来讲，这是一个包罗万象的术语。此处常用许多一般管理技术，最普遍的是头脑风暴法和横向思维。
.4 Expert judgment. Expert judgment is described in Section 5.1.2.2.
.4 专家判断。见5.1.2.2节。
5.2.3 Outputs from Scope Planning（范围计划编制的输出）
.1 Scope statement. The scope statement provides a documented basis for making future project decisions and for confirming or developing common understanding of project scope among the stakeholders. As the project progresses, the scope statement may need to be revised or refined to reflect changes to the scope of the project. The scope statement should include, either directly or by reference to other documents: 8
9 a.包罗一切的 a.横向的
-13-
D ocuments
.1 范围说明。范围说明为未来项目决策提供一个文档化基准，并在项目利害关系者之间确认或建立一个共同的理解。随着项目进展，范围说明需要进行修正和精练，使之能够反映项目范围的变更。范围说明或者直接或者作为其它文档的参考包括如下部分：
z Project justification—the business need that the project was undertaken to
address. The project justification provides the basis for evaluating future trade-offs.
项目理由－项目所从事满足的商业需求。项目理由为未来效益平衡提供
基础。
z Project product—a brief summary of the product description (the product
decription is discussed in Section 5.1.1.1).
项目产品－产品描述（见5.1.1.1节）的一个简单概括。
z Project deliverables—a list of the summary level sub-products whose full
and satisfactory delivery marks completion of the project. For example, the major deliverables for a software development project might include the working computer code, a user manual, and an interactive tutorial. When known, exclusions should be identified, but anything not explicitly included is implicitly excluded.
项目可交付成果－概要级别的子产品列表清单，它们全部和满意的交付
标志项目的完成。例如，一个软件开发项目的主要可交付成果可能包括
运行的计算机代码、一个用户手册和一个交互式教程。可交付成果一旦
确定，非可交付成果部分也应明确，任何没有清楚明确的东西，意味着它们排除在可交付成果之外。
z Project objectives—the quantifiable criteria that must be met for the project
to be considered successful. Project objectives must include, at least, cost,
-14-
D ocuments
schedule, and quality measures. Project objectives should have an attribute10
(e.g., cost), a yardstick (e.g., U.S. dollars), and an absolute or relative value
(e.g., less than 1.5 million). Unquantified objectives (e.g., “customer satisfaction”) entail high risk.
项目目标－认为项目成功所必须满足的量化准则。项目目标至少包括成
本、进度和质量度量标准。项目目标应有一个属性（如成本）、一个单
位（如美元）和一个绝对或相对值（如小于1500000）。没有量化的目标
（如用户满意）常包含高风险。
In some application areas, project deliverables are called project objectives while project objectives are called critical success factors.
在某些应用领域中，项目可交付成果叫做项目目标而项目目标叫关键成功因素。
.2 Supporting detail. Supporting detail for the scope statement should be documented and organized as needed to facilitate its use by other project management processes. Supporting detail should always include documentation of all identified assumptions and constraints. The amount of additional detail varies by application area.
.2 辅助细节。辅助细节应当形成文档并适当组织，以利于其它项目管理过程使用。辅助细节应包括所有确定的假定和限制的文档。辅助细节的数量随应用领域的不同而变化。
.3 Scope management plan. This document describes how project scope will be managed and how scope changes will be integrated into the project. It should also include an assessment of the expected stability of the project scope (i.e., how likely is it to change, how frequently, and by how much). The scope management plan should also include a clear description of how scope changes will be identified and classified 10 n.属性
-15-
characteristics are still being elaborated). D ocuments (this is particularly difficult—and therefore absolutely essential—when the product
.3 范围管理计划。此文档是描述项目范围是如何被管理的，以及项目范围变更是如何被集成到项目中。它也应包括对项目范围的期望稳定性的评估（就是变更的可能性大小、频率和多少）。范围管理计划也应对范围如何被确定和分类作一个清楚的描述（做到这点很困难－因此有实质意义－尤其是当产品特征仍在被细化的时候）。
A scope management plan may be formal or informal, highly detailed or broadly framed based on the needs of the project. It is a subsidiary element of the overall project plan (described in Section 4.1.3.1).
范围管理计划按照项目的需要，既可能是正式的或非正式的，也可能是详细的或笼统的。它是整体项目计划（见4.1.3.1节）的一个辅助要素。
5.3 Scope Definition（范围定义）
Scope defintion involves subdividing the major project deliverables into smaller, more manageable components in order to:
范围定义是将项目的主要可交付成果分成小的、容易管理的部分，目的是： z Improve the accuracy of cost, time, and resource estimates.
提高成本、时间和资源评估的精确程度。
z Define a baseline for performance measurement and control.
为执行情况衡量和控制定义一个基准。
z Facilitate clear responsibility assignments.
有助于清楚的责任划分。
-16-
D ocuments
Proper scope definition is critical to project success. “When there is poor scope definition, final project costs can be expected to be higher because of the inevitable changes which disrupt project rhythm11, cause rework, increase project time, and lower the productivity and morale of the workforce12”.
正确的范围定义对项目成功非常关键。“当存在差的范围定义时，由于不可避免的变更，造成破坏项目节奏、重复工作、增加项目时间和降低劳动力的生产率和士气，最终导致项目成本大大增加”。
5.3.1 Inputs to Scope Definition（范围定义的输入）
.1 Scope statement. The scope statement is described in Section 5.2.3.1.
.1 范围说明。见5.2.3.1节。
.2 Constraints. Constraints are described in Section 5.1.3.3. When a project is done under contract, the constraints defined by contractual provisions are often important considerations during scope definition.
.2 限制。见5.1.3.3节。当项目以合同方式执行时，范围定义期间，合同条款的限制通常是重要的考虑因素。 11
12 n.节奏 n.劳动力
-17-
3.假定。见5.1.3.4节。 D ocuments 3.Assumptions. Assumptions are described in Section 5.1.3.4.
4.Other planning outputs. The outputs of the processes in other knowledge areas should be reviewed for possible impact on project scope definition.
4.其它项目编制输出。应当审查其它知识领域的过程输出对项目范围定义的可能影响。
5.Historical information. Historical information about previous projects should be considered during scope definition. Information about errors and omissions on previous projects should be especially useful.
5.历史信息。在项目定义的过程中，先前项目的历史信息应当予以考虑。先前项目中有关失误和忽略的信息应该特别有用。
5.3.2 Tools and Techniques for Scope Definition（范围定义的工具和技术）
.1 Work breakdown structure templates. A work breakdown structure (WBS, described in Section 5.3.3.1) from a previous project can often be used as a template for a new project. Although each project is unique, WBSs can often be “reused” since most projects will resemble another project to some extent. For example, most projects within a given organization will have the same or similar project life cycles and will thus have the same or similar deliverables required from each phases.
.1 工作分解结构模板。前一个项目的工作分解结构（WBS）常作为新项目的模板。尽管每个项目都是唯一的，但是由于多数项目都有不同程度相似之处，WBS常常可以被“重复”使用。例如，组织内的多数项目都有相同或相似的项目寿命期，因而它们有着相同或相似的阶段可交付成果。
Many application areas have standard or semi-standard WBSs that can be used as
-18-
D ocuments
templates. For example, the U.S. Department of Defense has defined standard WBSs for Defense Materiel Items. A portion of one of these templates is shown as Figure 5-2.
许多应用领域都有可用做模板的标准或半标准的WBS。例如，美国国防部为国防采购项目定义了标准的WBS模板，这些模板的一部分见图5-2。
.2 Decomposition. Decomposition involves subdividing the major deliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project activities (planning, executing, controlling, and closing). Decomposition involves the following major steps:
2.分解。分解是将主要的项目可交付成果分为更小的、易管理的部分，直到细化到足以支持项目未来活动（计划、执行、控制和收尾）。分解包括下面几个主要步骤：
(1)Identify the major elements of the project. In general, the major elements will be the project deliverables and project management. However, the major elements should always be defined in terms of how the project will actually be managed. For examples:
(1)确定项目的主要要素。一般情况下，项目的主要要素是项目的可交付成果和项目管理。但是，主要要素总应按照实际如何管理项目来确定。例如：
z The phases of the project life cycle may be used as the first level of
decomposition with the project deliverables repeated at the second level, as
illustrated in Figure 5-3.
项目寿命期阶段可作为分解的第一层次，而项目可交付成果作为第二层
次，如图5-3所示。
z The organizing principle within each branch of the WBS may vary, as
illustrated in Figure 5-4.
WBS的每个分支的组织原则可能变化，如图5-4所示。
-19-
D ocuments
Figure 5-2 Sample Work Breakdown Structure for Defense Materiel Items
-20-
D ocuments
Figure 5-3 Sample Work Breakdown Structure Organized by Phase
-21-
D
ocuments
Figure 5-4 Sample Work Breakdown Structure for Waste Water Treatment Plant
(2)Decide if adequate cost and duration estimates can be developed at this level of detail for each element. The meaning of adequate may change over the course of the project—decomposition of a deliverable that will be produced far in the future may not be possible. For each element, proceed to Step 4 if there is adequate detail and to Step 3 if there is not—this means that different elements may have differing levels of decomposition.
对于每个要素，决定在其细节层次上是否有足够的条件建立成本和持续时间的评估。足够的意义可能在项目整个过程发生变化－对在很远的未来才产生的可交付成果的分解是不可能的。如果每个要素有足够的细节，进行步骤4，否则进行步骤3－这意味着不同的要素有不同的分解层次。
-22-
D ocuments
(3)Identify constituent13 elements of the deliverable. Constituent elements should be described in terms of tangible, verifiable14 results in order to facilitate performance measurement. As with the major elements, the constituent elements should be defined in terms of how the work of the project will actually be accomplished. Tangible, verifiable results can include services as well as products (e.g., status reporting could be described as weekly status reports; for a manufactured item, constituent elements might include several individual components plus final assembly). Repeat Step 2 on each constituent element.
(3)确定可交付成果的组成要素。组成要素应以有形的、能证实的结果来描述，以便有助于衡量执行情况。与主要要素不同，组成要素应当按照项目工作实际上如何完成的方式来定义。有形的、能证实的结果包括产品和服务（比如，状况报告可描述为每周状况报告，对于一个制造项目，组成要素可能包括几个单个的部分加上最终装配）。对每个组成要素重复步骤2。
(4)Verify the correctness of the decomposition:
(4)核实分解的正确性：
z Are the lower-level items both necessary and sufficient for completion of the
item decomposed? If not, the constituent elements must be modified (added
to, deleted from, or redefined).
最低层次的项目是否为分解完成的充要条件？如果不是，组成要素应被
修改（增加、删除或重定义）。
z Is each item clearly and completely defined? If not, the descriptions must be
revised and expanded.
每个项目定义是否清楚和完整？如果不是，描述必须修正和扩展。
z Can each item be appropriately scheduled? Budgeted? Assigned to a specific
organizational unit (e.g., department, team, or person) who will accept 13 a.构成的，组成的
14 n.能证实的
-23-
D ocuments
responsibility for satisfactory completion of the item? If not, revisions are
needed to provide adequate management control.
每个项目是否能够适当地被安排进度、编制预算、分配到一个具体的组
织单位（比如部门、队伍或个人）？谁将负责项目的完成？如果不能，
需要进行修正以便提供足够的管理控制。
5.3.3 Outputs from Scope Definition（范围定义的输出）
.1 Work breakdown structure. A work breakdown structure is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project: work not in the WBS is outside the scope of the project. As with the scope statement, the WBS is often used to develop or confirm a common understanding of project scope. Each descending level represents an increasingly detailed description of the project elements. Section 5.3.2.2 describes the most common approach for developing a WBS. A WBS is normally presented in chart form as illustrated in Figure 5-2, 5-3, and 5-4; however, the WBS should not be confused with the method of presentation—drawing an unstructured activity list in chart form does not make it a WBS.
.1 工作分解结构。工作分解结构是一个面向可交付成果的项目要素集合，它组织和定义项目的整个范围：不在WBS中的工作也是在项目范围以外。与范围说明不同，WBS用于建立和确认对项目范围的共同理解。每个下级层次表示对项目要素的进一步细化描述。5.3.2.2节介绍了建立WBS的最通用的方法。WBS一般正常情况下用图表形式表示，如图5-2、5-3和5-4，但是，WBS不应同表述方法混淆－用图表绘制一个无结构工序的列表并不是一个工作分解结构。
Each item in the WBS is generally assigned a unique identifier; these identifier are often known collectively as the code of accounts. The items at the lowest level of
-24-
D ocuments
the WBS are often referred to as work packages. These work packages may be further decomposed as described in Section 6.1, Activity Definition.
WBS中的每个项目一般都有一个唯一的标识符，它们常被共同看成为账目代码。WBS中最低层次上的项目指工作包。这些工作包可以被再分解，6.1节（工序定义）中有详细描述。
Work elements are often collected in a WBS dictionary. A WBS dictionary will typically include work package descriptions as well as other planning information such as schedule dates, cost budgets, and staff assignments.
工作要素的描述常被收集到WBS词典中。WBS词典典型地包括工作包描述和其它计划编制信息，如进度日期、成本预算和人员安排等。
The WBS should not be confused with other kinds of “breakdown” structures used to present project information. Other structures commonly used in some application areas include:
WBS不应同其它种类用于表示项目信息的“分解”结构混淆。某些应用领域中普遍使用的其它结构包括：
z Contractual WBS (CWBS), which is used to define the level of reporting
that the seller will provide the buyer. The CWBS generally includes less
detail than the WBS used by the seller to manage the seller’s work.
合同工作分解结构(CWBS)，用于定义销售者提供给购买者的报告层次。
CWBS一般比销售者用来管理工作的WBS有着较少的细节。
z Organizational breakdown structure (OBS), which is used to show which
work elements have been assigned to which organizational units.
组织分解结构(OBS)，用来表示工作要素被分配到那个组织单位。
z Resource breakdown structure (RBS), which is a variation of the OBS and is
typically used when work elements are assigned to individuals.
资源分解结构(RBS)，它是OBS的一个变形，在工作要素被分配到个人
-25-
时使用。 D ocuments
z Bill of materials (BOM), which presents a hierarchical view of the physical
assemblies, subassemblies, and components needed to fabricate a manufactured product.
材料清单(BOM)，表述了用于一个制造产品所需的物理装配、部件装配
和成分的分级视图。
z Project breakdown structure (PBS), which is fundamentally the same as a
properly done WBS. The term PBS is widely used in application areas where
the term WBS is incorrectly used to refer to a BOM.
项目分解结构(PBS)，基本上同WBS。在WBS不能正确表示BOM的应
用领域内，PBS被广泛使用。
5.4 Scope Verification（范围核实）
Scope verification is the process of formalizing acceptance of the project scope by the stakeholders (sponsor, client, customer, etc.). It requires reviewing work products and results to ensure that all were completed correctly and satisfactorily. If the project is terminated early, the scope verification process should establish and document the level and extent of completion. Scope verification differs from quality control (described in Section 8.3) in that it is primarily concerned with acceptance of the work results while quality control is primarily concerned with correctness of the work results.
范围核实是项目利害关系者（发起人、客户、用户等）正式认可项目范围的过程。它需要回顾工作产品和结果，确保它们都正确地、令人满意地完成了。如果项目夭折，范围核实过程应该建立和记录在档完成的水平和程度。范围核实同质量控制（见8.3节）不同，前者主要关心工作结果的接受，后者则是工作结果
-26-
的正确性。
D ocuments
5.4.1 Inputs to Scope Verification（范围核实的输入）
.1 Work results. Work results—which deliverables have been fully or partially completed, what costs have been incurred or committed, etc.—are an output of project plan execution (discussed in Section 4.2).
.1 工作结果。工作结果是为完成项目所执行活动的各种结果。工作结果的信息－哪些可交付成果已完成、哪些未完成、满足质量标准的程度、哪些成本发生或提交等等－是项目计划执行的输出（见4.2节）。
.2 Product documentation. Documents produced to describe the project’s products must be available for review. The terms used to describe this documentation (plans, specifications, technical documentation, drawing, etc.) vary by application area.
.2 产品文档。描述项目产品的文档必须对回顾有用。描述本文档的术语（计划、规格、技术文档、图纸等）随应用领域不同而不同。
5.4.2 Tools and Techniques for Scope Verification（范围核实的工具和技术）
-27-
D ocuments
.1 Inspection. Inspection includes activities such as measuring, examining, and testing undertaken to determine whether results conform to requirements. Inspections are variously called reviews, product reviews, audits, and walk-throughs; in some application areas, these different terms have narrow and specific meanings.
.1 检查。检查是指结果是否满足需求的活动，比如测量、检验、测试等。检查有各种叫法，如回顾、产品回顾、审计和全面回顾等。在一些应用领域中，这些不同的术语有更狭窄和具体和含义。
5.4.3 Outputs from Scope Verification（范围核实的输出）
.1 Formal acceptance. Documentation that the client or sponsor has accepted the product of the project or phase must be prepared and distributed. Such acceptance may be conditional, especially at the end of a phase.
.1 正式接受。客户或发起人接受项目产品或阶段产品的文档必须准备和发布。这种接受可能是有条件的，特别是在一个阶段的末尾。
5.5 Scope Change Control（范围变更控制）
Scope change control is concerned with (a) influencing the factors which create changes to ensure that changes are beneficial, (b) determining that a change has occurred, and (c) managing the actual changes when and as they occur. Scope cnage control must be thoroughly integrated with the other control processes (time control, cost control, quality control, and others as discussed in Section 4.3).
范围变更控制所关心的是：(a)产生有益变更的影响因素，(b)决定变更已经发生，(c)管理实际发生的变更。范围变更控制必须同其它控制过程紧密集成（时
-28-
D ocuments
间控制、成本控制、质量控制以及4.3节中讨论的其它控制）：
5.5.1 Inputs to Scope Change Control（范围变更控制的输入）
.1 Work breakdown structure. The WBS is described in Section 5.3.3.1. It defines the project’s scope baseline.
.1 工作分解结构。见5.3.3.1节。它定义了项目范围基准。
.2 Performance reports. Performance reports discussed in Section 10.3.3.1 provide information on scope performance such as which interim products have been completed and which have not. Performance reports may also alert the project team to issues which may cause problems in the future.
.2 执行情况报告。10.3.3.1节中讨论的执行情况报告提供了范围执行情况的信息，比如哪些中间产品完成了或者没有完成。执行情况报告也提醒项目队伍将来可能造成什么问题。
.3 Change requests. Change requests may occur in many forms—oral or written, direct or indirect, externally or internally initiated, and legally mandated or optional. Changes may require expanding the scope or may allow shrinking it. Most change requests are the result of:
.3 变更请求。变更请求有很多形式－口头的或书面的、直接的或间接的、内部或外部开始的、法律强制的或随意的。变更可能需要扩大或缩小项目范围。
-29-
多数变更请求是由下列原因造成的： D ocuments
z An external event (e.g., a change in a government regulation).
一个外部事件（比如政府规章的变化）。
z An error or omission in defining the scope of the product (e.g., failure to
include a required feature in the design of a telecommunication system).
定义产品范围的错误或遗漏（比如，在一个电信系统设计时，没有包括
一个需要的特征）。
z An error or omission in defining the scope of the project (e.g., using a bill of
materials instead of a work breakdown structure).
定义项目范围的错误或遗漏（比如，使用材料清单代替工作分解结构）。
z A value-added change (e.g., an environment remediation15 project is able to
reduce costs by taking advantage of technology that was not available when
the scope was originally defined).
一个增加价值的变更（比如，一个环境补救项目可以通过采用最初定义
范围时并不合适的技术来减小成本）。
.4 Scope management plan. Scope management plan is described in Section
5.2.3.3.
.4 范围管理计划。见5.2.3.3节。
5.5.2 Tools and Techniques for Scope Change Control（范围变更控制的工具和技术）
.1 Scope change control system. A scope change control system defines the procedures by which the project scope may be changed. It includes the paperwork, tracking systems, and approval levels necessary for authorizing changes. The scope 15 n.补习，辅导
-30-
D ocuments
change control system should be integrated with the overall change control system described in Section 4.3 and, in particularly, with any system or systems in place to control product scope. When the project is done under contract, the scope change control system must also comply with all relevant contractual provisions.
.1 范围变更控制系统。一个范围变更控制系统定义了项目范围产生变更的程序。它包括日常文书工作、跟踪系统和用于授权变更的批准级别。范围变更控制系统应同整体变更控制系统（见4.3节）集成，特别是控制产品范围的系统。当项目以合同方式执行时，范围变更控制系统必须遵守相关的合同条款。
.2 Performance measurement. Performance measurement techniques, described in Section 10.3.2, help to assess the magnitude16 of any variations which do occur. An important part of scope change control is to determine what is causing the variance and to decide if the variance requires corrective action.
.2 执行情况衡量。执行情况衡量技术（见10.3.2节）帮助评定所发生偏差的大小。范围变更控制的重要部分是确定产生偏差的原因和决定是否需要纠正措施。
.3 Additional planning. Few projects run exactly according to plan. Prospective changes may require modifications to the WBS or analysis of alternative approaches.
.3 另外的计划。项目很少精确按计划执行。预期的变更可能需要修改WBS或者分析替代方法。
5.5.3 Outputs from Scope Change Control（范围变更控制的输出）
.1 Scope changes. A scope change is any modification to the agreed-upon project scope as defined by the approved WBS. Scope changes often require adjustments to cost, time, quality, or other project objectives. 16 n.大小
-31-
D ocuments
.1 范围变更。范围变更是对以WBS形式定义的共同接受的项目范围的修改。范围变更经常需要调整成本、时间、质量或其它项目目标。
Scope changes are fed back through the planning process, technical and planning documents are updated as needed, and stakeholders are notified as appropriate.
范围变更反馈到计划编制过程，技术和计划编制文档需要更新，通知适当的利害关系者。
.2 Corrective action. Corrective action is anything done to bring expected future project performance into line with the project plan.
.2 纠正措施。纠正措施是确保项目按计划执行所采取的措施。
.3 Lessons learned. The causes of variances, the reasoning behind the corrective action chosen, and other types of lessons learned from scope change control should be documented so that they become part of the historical database for both this project and other projects of the performing organization.
.3 得到的教训。来自范围控制中的产生偏差的原因、选择纠正措施的推理以及其它类型的教训都应记录下来，它们成为执行组织的这个项目和其它项目的历史数据库。
-32-