PMBOK/PMP 可交付成果

项目是为创造独特的产品、服务或成果而进行的临时性工作。

独特的产品、服务或成果。开展项目是为了通过可交付成果达成目标。目标指的是工作所指向的结果，要达到的战略地位，要达到的目的，要取得的成果，要生产的产品，或者准备提供的服务。可交付成果指的是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。可交付成果可能是有形的，也可能是无形的。

实现项目目标可能会产生以下一个或多个可交付成果：

一个独特的产品，可能是其他产品的组成部分、某个产品的升级版或修正版，也可能其本身就是新的最终产品（例如一个最终产品缺陷的修正）；
一种独特的服务或提供某种服务的能力（如支持生产或配送的业务职能）；
一项独特的成果，例如某个结果或文件（如某研究项目所创造的知识，可据此判断某种趋势是否存在，或判断某个新过程是否有益于社会）；
一个或多个产品、服务或成果的独特组合（例如一个软件应用程序及其相关文件和帮助中心服务）。

某些项目可交付成果和活动中可能存在重复的元素，但这种重复并不会改变项目工作本质上的独特性。例如，即便采用相同或相似的材料，由相同或不同的团队来建设，但每个建筑项目仍具备独特性（例如位置、设计、环境、情况、参与项目的人员）。

项目可以在组织的任何层面上开展。一个项目可能只涉及一个人，也可能涉及一组人；可能只涉及一个组织单元，也可能涉及多个组织的多个单元。

项目的例子包括（但不限于）：

为市场开发新的复方药；
扩展导游服务；
合并两家组织；
改进组织内的业务流程；
为组织采购和安装新的计算机硬件系统；
一个地区的石油勘探；
修改组织内使用的计算机软件；
开展研究以开发新的制造过程；
建造一座大楼。
临时性工作。项目的“临时性”是指项目有明确的起点和终点。“临时性”并不一定意味着项目的持续时间短。在以下一种或多种情况下，项目即宣告结束：
达成项目目标；
不会或不能达到目标；
项目资金缺乏或没有可分配资金；
项目需求不复存在（例如，客户不再要求完成项目，战略或优先级的变更致使项目终止，组织管理层下达终止项目的指示）；
无法获得所需人力或物力资源；
出于法律或便利原因而终止项目。

虽然项目是临时性工作，但其可交付成果可能会在项目的终止后依然存在。项目可能产生与社会、经济、材料或环境相关的可交付成果。例如，国家纪念碑建设项目就是要创造一个流传百世的可交付成果。

项目驱动变更。项目驱动组织进行变更。从商业角度来看，项目旨在推动组织从一个状态转到另一个状态，从而达成特定目标（见图 1-1）。在项目开始之前，通常将此时的组织描述为“当前状态”。项目驱动变更是为了获得期望的结果，即“将来状态”。

有些项目可能会创造一个过渡状态，即由多个步骤组成的连续区间，以过渡到将来状态。通过成功完成项目，组织可以实现将来状态并达成特定目标。关于项目管理和变更的更多信息，请参见《管理组织变更：实践指南》[6]。

图 1-1组织通过项目进行状态转换

项目创造商业价值。PMI 将商业价值定义为从商业运作中获得的可量化净效益。效益可以是有形的、无形的或两者兼有之。在商业分析中，商业价值被视为回报，即以某种投入换取时间、资金、货物或无形的回报（参见《从业者商业分析：实践指南》，第 185 页 [7]）。

项目的商业价值指特定项目的成果能够为相关方带来的效益。项目带来的效益可以是有形的、无形的或两者兼有之。

有形效益的例子包括：

货币资产；
股东权益；
公共事业；
固定设施；
工具；
市场份额。

无形效益的例子包括：

商誉；
品牌认知度；
公共利益；
商标；
战略一致性；
声誉。
项目启动背景。组织领导者启动项目是为了应对影响该组织的因素。这些基本因素说明了项目背景，大致分为四类（见图 1-2）：
符合法规、法律或社会要求；
满足相关方的要求或需求；
执行、变更业务或技术战略；
创造、改进或修复产品、过程或服务。

图 1-2项目启动背景

这些因素会影响组织的持续运营和业务战略。领导者应对这些因素，以便组织持续运营。项目为组织提供了一个有效的途径，使其能够成功做出应对这些因素所需的变更。这些因素最终应与组织的战略目标以及各个项目的商业价值相关联。

表 1-1 展示了如何将示例因素归入一个或多个基本因素类别。

表 1-1促成项目创建的因素示例

业务或组织运营的改变也许就是某个项目的关注焦点，尤其当项目交付的新产品或新服务将导致业务运营的有实质性改变时。持续运营不属于项目的范畴，但是它们之间存在交叉。

项目与运营会在产品生命周期的不同时点交叉，例如：

在新产品开发、产品升级或提高产量时；
在改进运营或产品开发流程时；
在产品生命周期结束阶段；
在每个收尾阶段。

在每个交叉点，可交付成果及知识在项目与运营之间转移，以完成工作交接。在这一过程中，将转移项目资源或知识到运营中，或转移运营资源到项目中。

项目组合、项目集和项目均需符合组织战略，或由组织战略驱动，并以不同的方式服务于战略目标的实现：

项目组合管理通过选择适当的项目集或项目，对工作进行优先排序，以及提供所需资源，来与组织战略保持一致。
项目集管理对其组成部分进行协调，对它们之间的依赖关系进行控制，从而实现既定收益。
项目管理使组织的目的和目标得以实现。

作为项目组合或项目集的组成部分，项目是实现组织战略和目标的一种手段，常常应用于作为项目投资主要引导因素的战略规划之中。为了使项目符合组织的战略业务目标，对项目组合、项目集和项目进行系统化管理，可以应用组织级项目管理 (OPM)。OPM 指为实现战略目标而整合项目组合、项目集和项目管理与组织驱动因素的框架。

OPM 旨在确保组织开展正确的项目并合适地分配关键资源。OPM 有助于确保组织的各个层级都了解组织的战略愿景、支持愿景的举措、目标以及可交付成果。图 1-4 展示了战略、项目组合、项目集、项目和运营相互作用的组织环境。

关于 OPM 的更多信息，请参见《实施组织项目管理：实践指南》[8]。

图 1-4组织项目管理

项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。所有项目都呈现图 1-5 所示的通用的生命周期。

项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式：

预测型生命周期，在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。预测型生命周期也称为瀑布型生命周期。
迭代型生命周期，项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。
增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
适应型生命周期属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。请参见附录 X3。
混合型生命周期是预测型生命周期和适应型生命周期的组合。充分了解或有确定需求的项目要素遵循预测型开发生命周期，而仍在发展中的要素遵循适应型开发生命周期。

由项目管理团队确定各个项目最适合的生命周期。项目生命周期需要足够灵活，能够应对项目包含的各种因素。可以通过以下方法实现生命周期的灵活性：

确定需要在各个阶段实施的一个或多个过程；
在合适的阶段实施确定的一个或多个过程；
调整阶段的各种属性（例如名称、持续时间、退出标准和准入标准）。

项目生命周期与产品生命周期相互独立，后者可能由项目产生。产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。

生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段，属性是可测量且独特的。属性可能包括（但不限于）：

名称（例如阶段 A、阶段 B、阶段 1、阶段 2、提建议阶段）；
数量（例如项目的三个阶段、项目的五个阶段）；
持续时间（例如一个星期、一个月、一个季度）；
资源需求（例如人力、建筑、设备）；
项目进入某一阶段的准入标准（例如已获得特定批准文件、已完成特定文件）；
项目完成某一阶段的退出标准（例如已获得批准文件、已完成文件、已达成可交付成果）。

项目可以分解为不同的阶段或子组件，这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括（但不限于）：

概念开发；
可行性研究；
客户要求；
解决方案开发；
设计；
原型法；
建造；
测试；
转换；
试运行；
里程碑审查；
经验教训。

项目阶段可基于各种因素而建立，其中包括（但不限于）：

管理需求；
项目性质；
组织、行业或技术的独特性；
项目的组成要素，包括但不限于技术、工程、业务、过程或法律；
决策点（例如资金、继续/终止项目，里程碑审查）。

分为多个阶段的方式有助于更好地掌控项目管理，同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查（见 1.2.4.3 节）。

项目生命周期是通过一系列项目管理活动进行的，即项目管理过程。每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。输出可以是可交付成果或结果。

结果是过程的最终成果。项目管理过程适用于全球各个行业。

各项目管理过程通过它们所产生的输出建立逻辑联系。过程可能包含了在整个项目期间相互重叠的活动。一个过程的输出通常成为以下二者之一：

另一个过程的输入；
项目或项目阶段的可交付成果。

图 1-6 的示例说明了一个过程的输入、工具、技术和输出的关系以及与其他过程的关系。

图 1-6过程示例：输入、工具与技术和输出

过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类：

仅开展一次或仅在项目预定义点开展的过程。例如制定项目章程以及结束项目或阶段。
根据需要定期开展的过程。在需要资源时执行获取资源。在需要采购之前执行实施采购。
贯穿项目始终执行的过程。在整个项目生命周期中可能执行的过程定义活动，特别是当项目使用滚动式规划或适应型开发方法时。从项目开始到项目结束需要持续开展许多监控过程。

项目管理通过合理运用与整合按逻辑分组的项目管理过程而得以实现。过程分类方法有很多种，但《PMBOK® 指南》把过程归纳为五大类，即五大过程组。

整个项目生命周期需要收集、分析和转化大量的数据。从各个过程收集项目数据，并在项目团队内共享。在各个过程中所收集的数据经过结合相关背景的分析、汇总，并加工成项目信息。信息通过口头形式进行传达，或以各种格式的报告存储和分发。关于这一主题的更多信息，请参见 4.3 节。

在整个项目生命周期中需要定期收集和分析项目数据。关于项目数据和信息的主要术语定义如下：

工作绩效数据。在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。例如包括工作完成百分比、质量和技术绩效测量结果、进度计划活动的开始和结束日期、变更请求的数量、缺陷的数量、实际成本和实际持续时间等。项目数据通常记录在项目管理信息系统 (PMIS)（见 4.3.2.2 节）和项目文件中。
工作绩效信息。从各控制过程收集，并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。绩效信息的例子包括可交付成果的状态、变更请求的落实情况及预测的完工尚需估算。
工作绩效报告。为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息所形成的实物或电子项目文件。例如包括状况报告、备忘录、论证报告、信息札记、电子仪表盘、推荐意见和情况更新。

图 1-7 展示了项目管理各个过程中的项目信息流。

图 1-7项目数据、信息和报告流向

确定项目是否成功是项目管理中最常见的挑战之一。

时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素。

最近，从业者和学者提出，确定项目是否成功还应考虑项目目标的实现情况。

关于项目成功的定义和最重要的因素，项目相关方可能有不同的看法。明确记录项目目标并选择可测量的目标是项目成功的关键。主要相关方和项目经理应思考以下三个问题：

怎样才是项目成功？
如何评估项目成功？
哪些因素会影响项目成功？

主要相关方和项目经理应就这些问题达成共识并予以记录。

项目成功可能涉及与组织战略和业务成果交付有关的其他标准。这些项目目标可能包括（但不限于）：

完成项目效益管理计划；
达到商业论证中记录的已商定的财务测量指标。这些财务测量指标可能包括（但不限于）：
净现值 (NPV)；
投资回报率 (ROI)；
内部报酬率 (IRR)；
回收期 (PBP)；
效益成本比率 (BCR)。
达到商业论证的非财务目标；
完成组织从“当前状态”转到“将来状态”；
履行合同条款和条件；
达到组织战略、目的和目标；
使相关方满意；
可接受的客户/最终用户的采纳度；
将可交付成果整合到组织的运营环境中；
满足商定的交付质量；
遵循治理规则；
满足商定的其他成功标准或准则（例如过程产出率）。

为了取得项目成功，项目团队必须能够正确评估项目状况，平衡项目要求，并与相关方保持积极主动的沟通。

但在业务环境中，如果项目能够与组织的战略方向持续保持一致，那么项目成功的概率就会显著提高。

有可能一个项目从范围/进度/预算来看是成功的，但从商业角度来看并不成功。这是因为业务需要和市场环境在项目完成之前发生了变化。

组织用于执行项目工作的流程与程序，包括（但不限于）：

启动和规划
- 指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
- 特定的组织标准，例如政策（如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策）；
- 产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义）；
- 模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及相关方登记册模板）；
- 预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和工料合同）。
执行、监控：

变更控制程序，包括修改组织标准、政策、计划和程序（或任何项目文件）所须遵循的步骤，以及如何批准和确认变更；
跟踪矩阵；
财务控制程序（如定期报告、必需的费用与支付审查、会计编码及标准合同条款等）；
问题与缺陷管理程序（如定义问题和缺陷控制、识别与解决问题和缺陷，以及跟踪行动方案）。
资源的可用性控制和分配管理；
组织对沟通的要求（如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求）；
确定工作优先顺序、批准工作与签发工作授权的程序；
模板（如风险登记册、问题日志和变更日志）；
标准化的指南、工作指示、建议书评价准则和绩效测量准则；
产品、服务或成果的核实和确认程序。

收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配，以及向生产和（或）运营部门转移知识）

项目经理需要积极地与其他项目经理互动。其他独立项目或同一项目集的其他项目可能会对项目造成影响，原因包括（但不限于）：

对相同资源的需求；
资金分配的优先顺序；
可交付成果的接受或发布；
项目与组织的目的和目标的一致性。

与其他项目经理互动有助于产生积极的影响，以满足项目的各种需求。这些需求可能是团队为完成项目而需要的人力、技术或财力资源和可交付成果。项目经理需要寻求各种方法来培养人际关系，从而帮助团队实现项目目的和目标。

此外，项目经理在组织内扮演强有力的倡导者的角色。在项目过程中，项目经理积极地与组织中的各位经理互动。此外，项目经理应与项目发起人合作处理内部的政治和战略问题，这些问题可能会影响团队或项目的可行性或质量。

项目经理可以致力于提高自己在组织内的总体项目管理能力和技能，并参与隐性和显性知识的转移或整合计划（见 4.4 节的管理项目知识）。项目经理还应致力于：

展现项目管理的价值；
提高组织对项目管理的接受度；
提高组织内现有 PMO 的效率。

基于组织结构，项目经理可能向职能经理报告。而在其他情况下，项目经理可能与其他项目经理一起，向 PMO、项目组合或项目集经理报告。项目组合或项目集经理对整个组织范围内的一个或多个项目承担最终责任。为了实现项目目标，项目经理需要与所有相关经理紧密合作，确保项目管理计划符合所在项目组合或项目集的计划。项目经理还需与其他角色紧密协作，如组织经理、主题专家以及商业分析人员。在某些情况下，项目经理可以是临时管理角色的外部顾问。

战略和商务管理技能包括纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力。这项能力可能涉及其他职能部门的工作知识，例如财务部、市场部和运营部。战略和商务管理技能可能还包括发展和运用相关的产品和行业专业知识。这种业务知识也被称为领域知识。项目经理应掌握足够的业务知识，以：

向其他人解释关于项目的必要商业信息；
与项目发起人、团队和主题专家合作制定合适的项目交付策略；
以实现项目商业价值最大化的方式执行策略。

为制定关于项目成功交付的最佳决策，项目经理应咨询具备关于组织运营的专业知识的运营经理。这些经理应了解组织的工作以及项目计划会对工作造成的影响。对项目经理而言，对项目主题的了解越多越好，至少应能够向其他人说明关于组织的以下方面：

战略；
使命；
目的和目标；
产品和服务；
运营（例如位置、类型、技术）；
市场和市场条件，例如客户、市场状况（发展或萎缩）和上市时间因素等；
竞争（例如什么、谁、市场地位）。

为确保一致性，项目经理应将以下关于组织的知识和信息运用到项目中：

战略；
使命；
目的和目标；
优先级；
策略；
产品或服务（例如可交付成果）。

战略和商业技能有助于项目经理确定应为其项目考虑哪些商业因素。项目经理应确定这些商业和战略因素会对项目造成的影响，同时了解项目与组织之间的相互关系。这些因素包括（但不限于）：

风险和问题；
财务影响；
成本效益分析（例如净现值、投资回报率），包括各种可选方案；
商业价值；
效益预期实现情况和战略；
范围、预算、进度和质量。

通过运用这些商务知识，项目经理能够为项目提出合适的决策和建议。随着条件的变化，项目经理应与项目发起人持续合作，使业务战略和项目策略保持一致。

项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终。项目整合管理包括进行以下选择：

资源分配；
平衡竞争性需求；
研究各种备选方法；
为实现项目目标而裁剪过程；
管理各个项目管理知识领域之间的依赖关系。

项目整合管理过程包括：

4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。

4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。

4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。

4.4 管理项目知识 — 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。

4.5 监控项目工作 — 跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。

4.6 实施整体变更控制 — 审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。

4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。

图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中，各项目整合管理过程

以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 4-1项目整合管理概述

项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家（如成本分析专家、进度规划专家、风险管理专家）管理，但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果，并掌握项目总体情况。项目经理必须对整个项目承担最终责任。

项目与项目管理本质上具有整合性质，例如，为应急计划制定成本估算时，就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时，可能需要再次进行上述某个或某几个过程。

项目管理过程组的各个过程之间经常反复发生联系。例如，在项目早期，规划过程组为执行过程组提供书面的项目管理计划；然后，随着项目的进展，规划过程组还将根据变更情况，更新项目管理计划。

项目整合管理指的是：

确保产品、服务或成果的交付日期，项目生命周期以及效益管理计划这些方面保持一致；
编制项目管理计划以实现项目目标；
确保创造合适的知识并运用到项目中，并从项目中获取必要的知识；
管理项目管理计划中活动的绩效和变更；
做出针对影响项目的关键变更的综合决策；
测量和监督项目进展，并采取适当措施以实现项目目标；
收集关于已达成结果的数据，分析数据以获取信息，并与相关方分享信息；
完成全部项目工作，正式关闭各个阶段、合同以及整个项目；
管理可能需要的阶段过渡。

项目越复杂，相关方的期望越多样化，就需要越全面的整合方法。

项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括（但不限于）：

使用自动化工具。项目经理需要整合大量的数据和信息，因此有必要使用项目管理信息系统(PMIS) 和自动化工具来收集、分析和使用信息，以实现项目目标和项目效益。
使用可视化管理工具。有些项目团队使用可视化管理工具，而不是书面计划和其它文档，来获取和监督关键的项目要素。这样，就便于整个团队直观地看到项目的实时状态，促进知识转移，并提高团队成员和其他相关方识别和解决问题的能力。
项目知识管理。项目人员的流动性和不稳定性越来越高，就要求采用更严格的过程，在整个项目生命周期中积累知识并传达给目标受众，以防止知识流失。
增加项目经理的职责。项目经理被要求介入启动和结束项目，例如开展项目商业论证和效益管理。按照以往的惯例，这些事务均由管理层和项目管理办公室负责。现在，项目经理需要频繁地与他们合作处理这些事务，以便更好地实现项目目标以及交付项目效益。项目经理也需要更全面地识别相关方，并引导他们参与项目，包括管理项目经理与各职能部门、运营部门和高级管理人员之间的接口。
混合型方法。经实践检验的新做法会不断地融入项目管理方法，例如，采用敏捷或其他迭代做法，为开展需求管理而采用商业分析技术，为分析项目复杂性而采用相关工具，以及为在组织中应用项目成果而采用组织变革管理方法。

裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括（但不限于）：

项目生命周期。什么是合适的项目生命周期？项目生命周期应包括哪些阶段？
开发生命周期。对特定产品、服务或成果而言，什么是合适的开发生命周期和开发方法？预测型或适应型方法是否适当？如果是适应型，开发产品是该采用增量还是迭代的方式？混合型方法是否为最佳选择？
管理方法。考虑到组织文化和项目的复杂性，哪种管理过程最有效？
知识管理。在项目中如何管理知识以营造合作的工作氛围？
变更。在项目中如何管理变更？
治理。有哪些监控机构、委员会和其他相关方该参与项目治理？对项目状态报告的要求是什么？
经验教训。在项目期间及项目结束时，应收集哪些信息？历史信息和经验教训是否适用于未来的项目？
效益。应该在何时以何方式报告效益：在项目结束时还是在每次迭代或阶段结束时？

在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。

在适应型环境下，《整合管理的核心概念》中所述的对项目经理的期望保持不变，但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那么这种合作型方法就会更加有效。

在本过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息。

项目章程是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理使用组织资源开展项目活动的文件。它记录了关于项目和项目预期交付的产品、服务或成果的高层级信息，例如：

项目目的；
可测量的项目目标和相关的成功标准；
高层级需求；
高层级项目描述、边界定义以及主要可交付成果；
整体项目风险；
总体里程碑进度计划；
预先批准的财务资源；
关键相关方名单；
项目审批要求（例如，用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）；
项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）；
委派的项目经理及其职责和职权；
发起人或其他批准项目章程的人员的姓名和职权。

项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。本过程的主要作用是，对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。本过程需要在整个项目期间开展。图 4-6 描述本过程的输入、工具与技术和输出。图 4-7 是本过程的数据流向图。

图 4-6指导与管理项目工作：输入、工具与技术和输出

图 4-7指导与管理项目工作：数据流向图

指导与管理项目工作包括执行计划的项目活动，以完成项目可交付成果并达成既定目标。本过程需要分配可用资源并管理其有效使用，也需要执行因分析工作绩效数据和信息而提出的项目计划变更。指导与管理项目工作过程会受项目所在应用领域的直接影响，按项目管理计划中的规定，开展相关过程，完成项目工作，并产出可交付成果。

项目经理与项目管理团队一起指导实施已计划好的项目活动，并管理项目内的各种技术接口和组织接口。指导与管理项目工作还要求回顾所有项目变更的影响，并实施已批准的变更，包括纠正措施、预防措施和（或）缺陷补救。

在项目执行过程中，收集工作绩效数据并传达给合适的控制过程做进一步分析。通过分析工作绩效数据，得到关于可交付成果的完成情况以及与项目绩效相关的其他细节，工作绩效数据也用作监控过程组的输入，并可作为反馈输入到经验教训库，以改善未来工作包的绩效。

可作为本过程输入的项目文件包括（但不限于）：

变更日志。见 4.6.3.3 节。变更日志记录所有变更请求的状态。
经验教训登记册。见 4.4.3.1 节。经验教训用于改进项目绩效，以免重犯错误。登记册有助于确定针对哪些方面设定规则或指南，以使团队行动保持一致。
里程碑清单。见 6.2.3.3 节。里程碑清单列出特定里程碑的计划实现日期。
项目沟通记录。见 10.2.3.1 节。项目沟通记录包含绩效报告、可交付成果的状态，以及项目生成的其他信息。
项目进度计划。见 6.5.3.2 节。进度计划至少包含工作活动清单、持续时间、资源，以及计划的开始与完成日期。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵把产品需求连接到相应的可交付成果，有助于把关注点放在最终结果上。
风险登记册。见 11.2.3.1 节。风险登记册提供可能影响项目执行的各种威胁和机会的信息。
风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险来源的信息，以及关于已识别单个项目风险的概括信息。

工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。数据通常是最低层次的细节，将交由其他过程从中提炼出信息。在工作执行过程中收集数据，再交由控制过程做进一步分析。

例如，工作绩效数据包括已完成的工作、关键绩效指标 (KPI)、技术绩效测量结果、进度活动的实际开始日期和完成日期、已完成的故事点、可交付成果状态、进度进展情况、变更请求的数量、缺陷的数量、实际发生的成本、实际持续时间等。

变更请求是关于修改任何文件、可交付成果或基准的正式提议。如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。变更请求源自项目内部或外部，是可选或由法律（合同）强制的。变更请求可能包括：

纠正措施。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
预防措施。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
缺陷补救。为了修正不一致产品或产品组件的有目的的活动。
更新。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。

所有项目都会生成新知识。有些知识应该被编撰，并在管理项目知识过程中被嵌入可交付成果，或者被用于改进过程和程序。在本过程中，也可以首次编撰或使用现有知识，例如，关于新程序的现有想法在本项目中试用并获得成功。

可在本过程更新任一组织过程资产。

见 4.3.3.4 节。通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。变更请求可能导致需要收集和记录新的需求。变更可能会影响项目管理计划、项目文件或产品可交付成果。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。变更可能包括（但不限于）：

纠正措施。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
预防措施。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
缺陷补救。为了修正不一致产品或产品组件而进行的有目的的活动。

实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 4-12 描述本过程的输入、工具与技术和输出。图 4-13 是本过程的数据流向图。

图 4-12实施整体变更控制：输入、工具与技术和输出

图 4-13实施整体变更控制：数据流向图

实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间，参与项目的任何相关方都可以提出变更请求。变更控制的实施程度，取决于项目所在应用领域、项目复杂程度、合同要求，以及项目所处的背景与环境。

在基准确定之前，变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准，就必须通过本过程来处理变更请求。依照常规，每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求，并经过正式控制。

尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和（或）配置管理系统中。在批准变更之前，可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下，都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人，必要时，应该由变更控制委员会（CCB）来开展实施整体变更控制过程。CCB 是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。

变更请求得到批准后，可能需要新编（或修订）成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求，在 CCB 批准之后，可能还需要得到客户或发起人的批准，除非他们本身就是 CCB 的成员。

很多过程都会输出变更请求。变更请求（见 4.3.3.4 节）可能包含纠正措施、预防措施、缺陷补救，以及对正式受控的项目文件或可交付成果的更新，以反映修改或增加的意见或内容。变更可能影响项目基准，也可能不影响项目基准，而只影响相对于基准的项目绩效。变更决定通常由项目经理做出。

对于会影响项目基准的变更，通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。这种变更应由 CCB（如有）和客户或发起人审批，除非他们本身就是 CCB 的成员。只有经批准的变更才能纳入修改后的基准。

为了便于开展配置和变更管理，可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

工具的选择应基于项目相关方的需要，包括考虑组织和环境情况和（或）制约因素。工具应支持以下配置管理活动：

识别配置项。识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
记录并报告配置项状态。关于各个配置项的信息记录和报告。
进行配置项核实与审计。通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。

工具还应支持以下变更管理活动：

识别变更。识别并选择过程或项目文件的变更项。
记录变更。将变更记录为合适的变更请求。
做出变更决定。审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。

也可以使用工具来管理变更请求和后续的决策，同时还要格外关注沟通，以帮助变更控制委员会的成员履行职责，以及向相关方传达决定。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是，存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作。它仅开展一次或仅在项目的预定义点开展。图 4-14 描述本过程的输入、工具与技术和输出。图 4-15 是本过程的数据流向图。

图 4-14结束项目或阶段：输入、工具与技术和输出

图 4-15结束项目或阶段：数据流向图

• Projectcharter在结束项目时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。项目或阶段行政收尾所需的必要活动包括（但不限于）：

为达到阶段或项目的完工或退出标准所必须的行动和活动，例如：
确保所有文件和可交付成果都已是最新版本，且所有问题都已得到解决；
确认可交付成果已交付给客户并已获得客户的正式验收；
确保所有成本都已记入项目成本账；
关闭项目账户；
重新分配人员；
处理多余的项目材料；
重新分配项目设施、设备和其他资源；
根据组织政策编制详尽的最终项目报告。
为关闭项目合同协议或项目阶段合同协议所必须开展的活动，例如nn确认卖方的工作已通过正式验收；
最终处置未决索赔；
更新记录以反映最后的结果；
存档相关信息供未来使用。
为完成下列工作所必须开展的活动：
收集项目或阶段记录；
审计项目成败；
管理知识分享和传递；
总结经验教训；
存档项目信息以供组织未来使用。
为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门。
测量相关方的满意程度。

如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。为了实现上述目的，项目经理应该引导所有合适的相关方参与本过程。

见 5.5.3.1 节。验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果。

会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功。参会者可包括项目团队成员，以及参与项目或受项目影响的其他相关方。会议可以是面对面或虚拟会议，正式或非正式会议。会议的类型包括（但不限于）：收尾报告会、客户总结会、经验教训总结会，以及庆祝会。

需要更新的组织过程资产包括（但不限于）：

项目文件。在项目活动中产生的各种文件，例如项目管理计划，范围文件、成本文件、进度文件和项目日历，以及变更管理文件。
运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件，或对已有文件的更新。
项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件，以及用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。在项目收尾期间，项目经理应该回顾以往的阶段文件，确认范围过程（见 5.5 节）所产生的客户验收文件，以及合同协议（如果有的话），以确保在达到全部项目要求之后才正式关闭项目。

如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。

经验教训知识库。将在整个项目期间获得的经验教训和知识归入经验教训知识库，供未来项目使用。

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。

项目范围管理过程包括：

5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。

5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。

5.3 定义范围 — 制定项目和产品详细描述的过程。

5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。

5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。

5.6 控制范围 — 监督项目和产品的范围状态，管理范围基准变更的过程。

图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出

现，但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。

图 5-1项目范围管理概述

项目范围管理的核心概念在项目环境中，“范围”这一术语有两种含义：

产品范围。某项产品、服务或成果所具有的特征和功能。
项目范围。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。

从预测型方法到适应型或敏捷型方法，项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，随同可交付成果的创建提供反馈意见，并确保产品未完项反映他们的当前需求。在每次迭代中，都会重复开展两个过程：确认范围和控制范围。相反，在预测型项目中，确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。

在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完项（包括产品需求和用户故事）反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的，而产品范围的完成情况是根据产品需求来衡量的。在这里，“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。因此，相关方需要在规划阶段早期介入（有时需要在启动阶段就介入），对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。

目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点，并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂，组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理：实践指南》[14]，需求管理过程始于需要评估，而需要评估又可能始于项目组合规划、项目集规划或单个项目。

在项目范围管理过程中，收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括（但不限于）注重与商业分析专业人士的合作，以便：

确定问题并识别商业需要；
识别并推荐能够满足这些需要的可行解决方案；
收集、记录并管理相关方需求，以满足商业和项目目标；
推动项目集或项目的产品、服务或最终成果的成功应用 [7]。

需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益。

应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师，那么，与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排，并且在预算内按时完成，同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责，项目成功的可能性就更大。

裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）：

知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系？为了在未来项目中重复使用需求，项目经理应建立哪些指南？
确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南？
开发方法。组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
需求的稳定性。项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？
治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南？

在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定：

制定项目范围说明书；
根据详细项目范围说明书创建 WBS；
确定如何审批和维护范围基准；
正式验收已完成的项目可交付成果。

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

可用于本过程的数据收集技术包括（但不限于）：

头脑风暴。见 4.1.2.2 节。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
访谈。访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
焦点小组。焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
问卷调查。问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
标杆对照见。 8.1.2.2 节。标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是相关方的需要，后者是指如何实现这些需要。把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别包括：

业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
相关方需求。相关方或相关方群体的需要。
解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
功能需求。功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

跟踪需求包括（但不限于）：

业务需要、机会、目的和目标；
项目目标；
项目范围和 WBS 可交付成果；
产品设计；
产品开发；
测试策略和测试场景；
高层级需求到详细需求。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。图 5-7是需求跟踪矩阵示例，其中列有相关的需求属性。

图 5-7需求跟踪矩阵示例

Programs Portfolios

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。图 5-8 描述本过程的输入、工具与技术和输出。图 5-9 是本过程的数据流向图。

图 5-8定义范围：输入、工具与技术和输出

图 5-9定义范围：数据流向图

由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。

此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

见 4.1.2.3 节。人际关系与团队技能的一个示例是引导。在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。

产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。

每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括（但不限于）：

产品分解；
需求分析；
系统分析；
系统工程；
价值分析；
价值工程。

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：

产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
验收标准。可交付成果通过验收前必须满足的一系列条件。
项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。

表 5-1项目章程与项目范围说明书的内容

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。图 5-10 描述本过程的输入、工具与技术和输出。图 5-11 是本过程的数据流向图。

图 5-10创建 WBS：输入、工具与技术和输出

图 5-11创建 WBS：数据流向图

WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。

WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

WBS 最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目的高效管理；工作包的详细程度则因项目规模和复杂程度而异。要把整个项目工作分解为工作包，通常需要开展以下活动：

识别和分析可交付成果及相关工作；
确定 WBS 的结构和编排方法；
自上而下逐层细化分解；
为 WBS 组成部分制定和分配标识编码；
核实可交付成果分解的程度是否恰当。

图 5-12 显示了某工作分解结构的一部分，其中若干分支已经向下分解到工作包层次。

图 5-12分解到工作包的 WBS 示例

创建 WBS 的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次组件。WBS 的结构可以采用多种形式，例如：

以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层，如图 5-13 所示；
以主要可交付成果作为分解的第二层，如图 5-14 所示；
纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。

图 5-13 WBS 示例：以阶段作为第二层

图 5-14 WBS 示例：以主要可交付成果作为第二层

对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。如果采用敏捷方法，可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。

要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。

WBS 包含了全部的产品和项目工作，包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。这有时被称为 100% 规则。

关于 WBS 的详细信息，可参考《工作分解结构实践标准》（第 2 版）[15]。该标准列举了一些具体行业的 WBS 模板，可以在裁剪后应用于特定领域的具体项目。

范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：

项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述（见 5.3.3.1 节）。
WBS。WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
工作包。WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账户拥有两个或更多工作包，但每个工作包只与一个控制账户关联。
规划包。一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
WBS 词典。WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。WBS 词典中的内容可能包括（但不限于）：
账户编码标识；
工作描述；
假设条件和制约因素；
负责的组织；
进度里程碑；
相关的进度活动；
所需资源；
成本估算；
质量要求；
验收标准；
技术参考文献；
协议信息。

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。图 5-15 描述本过程的输入、工具与技术和输出。图 5-16 是本过程的数据流向图。

图 5-15确认范围：输入、工具与技术和输出

图 5-16确认范围：数据流向图

由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收，需要依据：从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。

确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

范围管理计划。见 5.1.3.1 节。项目管理计划定义了如何正式验收已经完成的可交付成果。
需求管理计划。见 5.1.3.2 节。需求管理计划描述了如何确认项目需求。
范围基准。见 5.4.3.1 节。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

可作为本过程输入的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
需求文件。见 5.2.3.1 节。将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。

核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

见 8.3.2.3 节。检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。在某些应用领域，这些术语具有独特和具体的含义。

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程（见 4.7 节）。

工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来（见 10.3.3.1 节）并传递给相关方。

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。变更请求（见 4.3.3.4 节）应该由实施整体变更控制过程（见 4.6 节）进行审查与处理。

可在本过程更新的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。
需求文件。见 5.2.3.1 节。记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
需求跟踪矩阵。见 5.2.3.2 节。根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。

工作绩效数据可能包括收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量。

项目进度管理包括为管理项目按时完成所需的各个过程。其过程包括：

6.1 规划进度管理 — 为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。

6.2 定义活动 — 识别和记录为完成项目可交付成果而需采取的具体行动的过程。

6.3 排列活动顺序 — 识别和记录项目活动之间的关系的过程。

6.4 估算活动持续时间 — 根据资源估算的结果，估算完成单项活动所需工作时段数的过程。

6.5 制定进度计划 — 分析活动顺序、持续时间、资源需求和进度制约因素，创建项目进度模型，从而落实项目执行和监控的过程。

6.6 控制进度 — 监督项目状态，以更新项目进度和管理进度基准变更的过程。

图 6-1 概括了项目进度管理的各个过程。虽然在本《PMBOK® 指南》中，各项目进度管理过程以界限

分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 6-1项目进度管理概述

项目进度管理的核心概念项目进度计划提供详尽的计划，说明项目如何以及何时交付项目范围中定义的产品、服务和成果，是一种用于沟通和管理相关方期望的工具，为绩效报告提供了依据。

项目管理团队选择进度计划方法，例如关键路径法或敏捷方法。之后，项目管理团队将项目特定数据，如活动、计划日期、持续时间、资源、依赖关系和制约因素等输入进度计划编制工具，以创建项目进度模型。这件工作的成果就是项目进度计划。图 6-2 是进度计划工作的概览，展示如何结合进度计划编制方法、编制工具及项目进度管理各过程的输出来创建进度模型。

在小型项目中，定义活动、排列活动顺序、估算活动持续时间及制定进度模型等过程之间的联系非常密切，以至于可视为一个过程，能够由一个人在较短时间内完成。但本章仍然把这些过程分开介绍，因为每个过程所用的工具和技术各不相同。有关某些过程的更详细的描述，请参见《进度计划实践标准》[2]。

在可能的情况下，应在整个项目期间保持项目详细进度计划的灵活性，使其可以随着知识的获得、对风险理解的加深，以及增值活动的设计而调整。

图 6-2进度规划工作概述

项目进度管理的发展趋势和新兴实践全球市场瞬息万变，竞争激烈，具有很高的不确定性和不可预测性，很难定义长期范围，因此，为应对环境变化，根据具体情景有效采用和裁剪开发实践就日益重要。适应型规划虽然制定了计划，但也意识到工作开始之后，优先级可能发生改变，需要修改计划以反映新的优先级。

有关项目进度计划方法的新兴实践包括（但不限于）：

具有未完项的迭代型进度计划。这是一种基于适应型生命周期的滚动式规划，例如敏捷的产品开发方法。这种方法将需求记录在用户故事中，然后在建造之前按优先级排序并优化用户故事，最后在规定的时间盒内开发产品功能。这一方法通常用于向客户交付增量价值，或多个团队并行开发大量内部关联较小的功能。适应型生命周期在产品开发中的应用越来越普遍，很多项目都采用这种进度计划方法。这种方法的好处在于，它允许在整个开发生命周期期间进行变更。
按需进度计划。这种方法通常用于看板体系，基于制约理论和来自精益生产的拉动式进度计划概念，根据团队的交付能力来限制团队正在开展的工作。按需进度计划方法不依赖于以前为产品开发或产品增量制定的进度计划，而是在资源可用时立即从未完项和工作序列中提取出来开展。按需进度计划方法经常用于此类项目：在运营或持续环境中以增量方式研发产品，其任务可以被设计成相对类似的规模和范围，或者可以按规模和范围进行组合的工作。

按需进度计划方法通常用于产品在运营和维护环境下以增量方式演进，且任务的规模或范围相对类似，或者，可以按照规模或范围对任务进行组合的项目。

裁剪考虑因素由于每个项目都是独特的，因此项目经理可能需要裁剪项目进度管理过程。裁剪时应考虑的因素包括（但不限于）：

生命周期方法。哪种生命周期方法最适合制定详细的进度计划？
资源可用性。影响资源可持续时间的因素是什么（如可用资源与其生产效率之间的相关性）？
项目维度。项目复杂性、技术不确定性、产品新颖度、速度或进度跟踪（如挣值、完成百分比、“红黄绿”停止信号灯指示）如何影响预期的控制水平？
技术支持。是否采用技术来制定、记录、传递、接收和存储项目进度模型的信息以及是否易于获取？

有关进度计划的更多信息，参阅《进度计划实践标准》[16]。

关于敏捷/适应型环境的考虑因素适应型方法采用短周期来开展工作、审查结果，并在必要时做出调整。这些周期可针对方法和可交付成果的适用性提供快速反馈，通常表现为迭代型进度计划和拉动式按需进度计划，具体参见“项目进度管理的发展趋势和新兴实践”一节。

在大型组织中，可能同时存在小规模项目和大规模举措，需要制定长期路线图，通过规模参数（如团队规模、地理分布、法规合规性、组织复杂性和技术复杂性）来管理这些项目集。为管理大规模的、全企业系统的、完整的交付生命周期，可能需要采用一系列技术，包括预测型方法、适应型方法或两种方法的混合。组织还可能需要结合几种核心方法，或采用已实践过的方法，并采纳来自传统技术的一些原则和实践。

无论是采用预测型开发生命周期来管理项目，还是在适应型环境下管理项目，项目经理的角色都不变。但是，要成功实施适应型方法，项目经理需要了解如何高效使用相关的工具和技术。

定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。

本过程需要在整个项目期间开展。图 6-5 描述本过程的输入、工具与技术和输出，图 6-6 是本过程的数据流程图。

图 6-5定义活动：输入、工具与技术和输出

图 6-6定义活动：数据流程图

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划定义进度计划方法、滚动式规划的持续时间，以及管理工作所需的详细程度。
范围基准。见 5.4.3.1 节。在定义活动时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。

见 5.4.2.2 节。分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。活动表示完成工作包所需的投入。定义活动过程的最终输出是活动而不是可交付成果，可交付成果是创建 WBS 过程（见 5.4 节）的输出。

WBS、WBS 词典和活动清单可依次或同时编制，其中 WBS 和 WBS 词典是制定最终活动清单的基础。WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队成员参与分解过程，有助于得到更好、更准确的结果。

见 4.3.3.4 节。一旦定义项目的基准后，在将可交付成果渐进明细为活动的过程中，可能会发现原本不属于项目基准的工作，这样就会提出变更请求。在这情况下，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划规定了排列活动顺序的方法和准确度，以及所需的其他标准。
范围基准。见 5.4.3.1 节。在排列活动顺序时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划规定了用于制定进度计划的进度计划编制方法和工具，以及推算进度计划的方法。
范围基准。见 5.4.3.1 节。范围说明书、WBS 和 WBS 词典包含了项目可交付成果的详细信息，供创建进度模型时借鉴。

项目进度计划是进度模型的输出，为各个相互关联的活动标注了计划日期、持续时间、里程碑和所需资源等星系。项目进度计划中至少要包括每个活动的计划开始日期与计划完成日期。即使在早期阶段就进行了资源规划，但在未确认资源分配和计划开始与完成日期之前，项目进度计划都只是初步的。一般要在项目管理计划（见 4.2.3.1 节）编制完成之前进行这些确认。还可以编制一份目标项目进度模型，规定每个活动的目标开始日期与目标完成日期。项目进度计划可以是概括（有时称为主进度计划或里程碑进度计划）或详细的。虽然项目进度计划可用列表形式，但图形方式更常见。可以采用以下一种或多种图形来呈现：

横道图。横道图也称为“甘特图”，是展示进度信息的一种图表方式。在横道图中，纵向列示活动，横向列示日期，用横条表示活动自开始日期至完成日期的持续时间。横道图相对易读，比较常用。它可能会包括浮动时间，也可能不包括，具体取决于受众。为了便于控制，以及与管理层进行沟通，可在里程碑或横跨多个相关联的工作包之间，列出内容更广、更综合的概括性活动，并在横道图报告中显示。见图 6-21 中的“概括性进度计划”部分，它按 WBS 的结构罗列相关活动。
里程碑图。与横道图类似，但仅标示出主要可交付成果和关键外部接口的计划开始或完成日期，见图 6-21 的“里程碑进度计划”部分。
项目进度网络图。这些图形通常用活动节点法绘制，没有时间刻度，纯粹显示活动及其相互关系，有时也称为“纯逻辑图”，如图 6-11 所示。项目进度网络图也可以是包含时间刻度的进度网络图，有时称为“逻辑横道图”，如图 6-21 中的详细进度计划所示。这些图形中有活动日期，通常会同时展示项目网络逻辑和项目关键路径活动等信息。本例子也显示了如何通过一系列相关活动来对每个工作包进行规划。项目进度网络图的另一种呈现形式是“时标逻辑图”，其中包含时间刻度和表示活动持续时间的横条，以及活动之间的逻辑关系。它们用于优化展现活动之间的关系，许多活动都可以按顺序出现在图的同一行中。

图 6-21 是一个正在执行的示例项目的进度计划，工作进展是通过截止日期或状态日期表示的。针对

一个简单的项目，图 6-21 给出了进度计划的三种形式：（1）里程碑进度计划，也叫里程碑图；（2）概括性进度计划，也叫横道图；（3）详细进度计划，也叫项目进度关联横道图。图 6-21 还直观地显示出项目进度计划不同详细程度的关系。

图 6-21项目进度计划示例

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是在整个项目期间保持对进度基准的维护，且需要在整个项目期间开展。图 6-22 描述本过程的输入、工具与技术和输出，图 6-23 是本过程的数据流程图。

图 6-22控制进度：输入、工具与技术和输出

图 6-23控制进度：数据流程图

要更新进度模型，就需要了解迄今为止的实际绩效。进度基准的任何变更都必须经过实施整体变更控制过程的审批（见 4.6 节）。控制进度作为实施整体变更控制过程的一部分，关注如下内容：

判断项目进度的当前状态；
对引起进度变更的因素施加影响；
重新考虑必要的进度储备；
判断项目进度是否已经发生变更；
在变更实际发生时对其进行管理。

如果采用敏捷方法，控制进度要关注如下内容：

通过比较上一个时间周期中已交付并验收的工作总量与已完成的工作估算值，来判断项目进度的当前状态；
实施回顾性审查（定期审查，记录经验教训），以便纠正与改进过程（如果需要的话）；
对剩余工作计划（未完项）重新进行优先级排序；
确定每次迭代时间（约定的工作周期持续时间，通常是两周或一个月）内可交付成果的生成、核实和验收的速度；
确定项目进度已经发生变更；
在变更实际发生时对其进行管理。

将工作外包时，定期向承包商和供应商了解里程碑的状态更新是确保工作按商定进度进行的一种途径，有助于确保进度受控。同时，应执行进度状态评审和巡检，确保承包商报告准确且完整。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划描述了进度的更新频率、进度储备的使用方式，以及进度的控制方式。
进度基准。见 6.5.3.1 节。把进度基准与实际结果相比，以判断是否需要进行变更或采取纠正或预防措施。
范围基准。见 5.4.3.1 节。在监控进度基准时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。
绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

成本管理计划。见 7.1.3.1 节。成本管理计划描述了可使用的估算方法以及成本估算需要达到的准确度和精确度。
质量管理计划。见 8.1.3.1 节。质量管理计划描述了项目管理团队为实现一系列项目质量目标所需的活动和资源。
范围基准。见 5.4.3.1 节。范围基准包括项目范围说明书、WBS 和 WBS 词典：
项目范围说明书。范围说明书（见 5.3.3.1 节）反映了因项目资金支出的周期而产生的资金制约因素，或其他财务假设条件和制约因素。
工作分解结构。WBS（见 5.4.3.1 节）指明了项目全部可交付成果及其各组成部分之间的相互关系。
WBS 词典。在 WBS 词典（见 5.4.3 节）和相关的详细工作说明书中，列明了可交付成果，并描述了为产出可交付成果，WBS 各组成部分所需进行的工作。

适用于估算成本过程的数据分析技术包括（但不限于）：

备选方案分析。备选方案分析是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。例如评估购买和制造可交付成果分别对成本、进度、资源和质量的影响。
储备分析。为应对成本的不确定性，成本估算中可以包括应急储备（有时称为“应急费用”）。

应急储备是包含在成本基准内的一部分预算，用来应对已识别的风险；应急储备还通常是预算的一部分，用来应对那些会影响项目的“已知 — 未知”风险。例如，可以预知有些项目可交付成果需要返工，却不知道返工的工作量是多少。可以预留应急储备来应对这些未知数量的返工工作。小至某个具体活动，大到整个项目，任何层级都可有其应急储备。应急储备可取成本估算值的某一百分比、某个固定值，或者通过定量分析来确定；

而随着项目信息越来越明确，可以动用、减少或取消应急储备。应该在成本文件中清楚地列出应急储备。应急储备是成本基准的一部分，也是项目整体资金需求的一部分。

质量成本。在估算时，可能要用到关于质量成本（见 8.1.2.3 节）的各种假设，这包括对以下情况进行评估：是为达到要求而增加投入，还是承担不符合要求而造成的成本；是寻求短期成本降低，还是承担产品生命周期后期频繁出现问题的后果。

项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求，以满足相关方目标的各个过程。此外，项目质量管理以执行组织的名义支持过程的持续改进活动。

项目质量管理过程包括：

8.1 规划质量管理 — 识别项目及其可交付成果的质量要求和/或标准，并书面描述项目将如何证明符合质量要求和/或标准的过程。

8.2 管理质量 — 管理质量是把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。

8.3 控制质量 — 为了评估绩效，确保项目输出完整、正确，并满足客户期望，而监督和记录质量管理活动执行结果的过程。

图 8-1 概述了项目质量管理的各个过程。虽然各项目质量管理过程通常以界限分明、相互独立的形

式出现，但在实践中它们会以《PMBOK® 无法全面叙述的方式相互交叠、相互作用。此外，不同行业和公司的质量过程各不相同。

图 8-1项目质量管理概述

图 8-2 概述了项目质量管理过程的主要输入和输出以及这些过程在项目质量管理知识领域中的相

互关系。规划质量管理过程关注工作需要达到的质量，管理质量则关注管理整个项目期间的质量过程。在管理质量过程期间，在规划质量管理过程中识别的质量要求成为测试与评估工具，将用于控制质量过程，以确认项目是否达到这些质量要求。控制质量关注工作成果与质量要求的比较，确保结果可接受。项目质量管理知识领域有两个用于其他知识领域的特定输出，即核实的可交付成果和质量报告。

图 8-2主要项目质量管理过程的相互关系

项目质量管理的核心概念项目质量管理需要兼顾项目管理与项目可交付成果两个方面，它适用于所有项目，无论项目的可交付成果具有何种特性。质量的测量方法和技术则需专门针对项目所产生的可交付成果类型而定，例如，对于软件与核电站建设的可交付成果，项目质量管理需要采用不同的方法和措施。无论什么项目，若未达到质量要求，都会给某个或全部项目相关方带来严重的负面后果，例如：

为满足客户要求而让项目团队超负荷工作，就可能导致利润下降、整体项目风险增加，以及员工疲劳、出错或返工。
为满足项目进度目标而仓促完成预定的质量检查，就可能造成检验疏漏、利润下降，以及后续风险增加。

“质量”与“等级”不是相同的概念。质量作为实现的性能或成果，是“一系列内在特性满足要求的程度”（ISO 9000）[18]。等级作为设计意图，是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及项目管理团队负责权衡，以便同时达到所要求的质量与等级水平。质量水平未达到质量要求肯定是个问题，而低等级产品不一定是个问题。例如：

一个低等级（功能有限）产品具备高质量（无明显缺陷），也许不是问题。该产品适合一般使用。
一个高等级（功能繁多）产品质量低（有许多缺陷），也许是个问题。该产品的功能会因质量低劣而无效和/或低效。

预防胜于检查。最好将质量设计到可交付成果中，而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。

根据不同的项目和行业领域，项目团队可能需要具备统计控制过程方面的实用知识，以便评估控制质量的输出中所包含的数据。项目管理团队应了解以下术语之间的差别：

“ 预防”（保证过程中不出现错误）与“检查”（保证错误不落到客户手中）；
“ 属性抽样”（结果为合格或不合格）与“变量抽样”（在连续的量表上标明结果所处的位置，表明合格的程度）；
“ 公差”（结果的可接受范围）与“控制界限”（在统计意义上稳定的过程或过程绩效的普通偏差的边界）。

质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求（返工）而发生的所有成本。失败成本通常分为内部（项目团队发现的）和外部（客户发现的）两类。失败成本也称为劣质成本。第 8.1.2.3 节给出了每类质量成本的一些例子。

组织选择投资缺陷预防，因为它对产品生命周期有利。由于项目的临时性，针对产品生命周期的COQ 决策，通常是项目集管理、项目组合管理、PMO 或运营的关注点。

按有效性递增排列的五种质量管理水平如下：

通常，代价最大的方法是让客户发现缺陷。这种方法可能会导致担保问题、召回、商誉受损和返工成本。
控制质量过程包括先检测和纠正缺陷，再将可交付成果发送给客户。该过程会带来相关成本，主要是评估成本和内部失败成本。
通过质量保证检查并纠正过程本身，而不仅仅是特殊缺陷。
将质量融入项目和产品的规划和设计中。
在整个组织内创建一种关注并致力于实现过程和产品质量的文化。

项目质量管理的趋势和新兴实践现代质量管理方法力求缩小差异，交付满足既定相关方要求的成果。项目质量管理的趋势可能包括（但不限于）：

客户满意。了解、评估、定义和管理要求，以便满足客户的期望。这就需要把“符合要求”（确保项目产出预定的成果）和“适合使用”（产品或服务必须满足实际需求）结合起来。在敏捷环境中，相关方与项目管理团队合作可确保在整个项目期间始终做到客户满意。
持续改进。由休哈特提出并经戴明完善的“计划 — 实施 — 检查 — 行动 (PDCA)”循环是质量改进的基础。另外，诸如全面质量管理（TQM）、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量。
管理层的责任。项目的成功需要项目团队全体成员的参与。管理层在其质量职责内，肩负着为项目提供具有足够能力的资源的相应责任。
与供应商的互利合作关系。组织与其供应商相互依赖。相对传统的供应商管理而言，与供应商建立合作伙伴关系对组织和供应商都更加有益。组织应着眼于长期关系而不是短期利益。互利合作关系增强了组织和供应商互相为对方创造价值的能力，推动他们共同实现客户的需求和期望，并优化成本和资源。

裁剪考虑因素每个项目都是独特的，因此项目经理需要裁剪项目质量管理过程。裁剪时应考虑的因素包括（但不限于）：

政策合规与审计。组织有哪些质量政策和程序？组织使用哪些质量工具、技术和模板？
标准与法规合规性。是否存在必须遵守的行业质量标准？需要考虑哪些政府、法律或法规方面的制约因素？
持续改进。如何管理项目中的质量改进？是在组织层面还是在单个项目层面进行管理？
相关方参与。项目环境是否有利于与相关方及供应商合作？

关于敏捷/适应型环境的考虑因素为引导变更，敏捷方法要求多个质量与审核步骤贯穿整个项目，而不是在面临项目结束时才执行。

循环回顾，定期检查质量过程的效果；寻找问题的根本原因，然后建议实施新的质量改进方法；

后续回顾会议评估试验过程，确定是否可行、是否应继续、或做出调整，或者直接弃用。

为促进频繁的増量交付，敏捷方法关注于小批量工作，纳入尽可能多的项目可交付成果的要素。

小批量系统的目的是在项目生命周期早期（整体变更成本较低）发现不一致和质量问题。

规划质量管理是识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程。本过程的主要作用是，为在整个项目期间如何管理和核实质量提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 8.3 描述了本过程的输入和输出。图 8.4 是本过程的数据流向图。

图 8-3规划质量管理：输入、工具与技术和输出

图 8-4规划质量管理：数据流向图

质量规划应与其他规划过程并行开展。例如，为满足既定的质量标准而对可交付成果提出变更，可能需要调整成本或进度计划，并就该变更对相关计划的影响进行详细风险分析。

本节讨论项目中最常用的质量规划技术，但在特定项目或应用领域中，还可采用许多其他质量规划技术。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。需求管理计划提供了识别、分析和管理需求的方法，以供质量管理计划和质量测量指标借鉴。
风险管理计划。见 11.1.3.1 节。风险管理计划提供了识别、分析和监督风险的方法。将风险管理计划和质量管理计划的信息相结合，有助于成功交付产品和项目。
相关方参与计划。见 13.2.3.1 节。相关方参与计划提供了记录相关方需求和期望的方法，为质量管理奠定了基础。
范围基准。见 5.4.3.1 节。在确定适用于项目的质量标准和目标时，以及在确定要求质量审查的项目可交付成果和过程时，需要考虑WBS和项目范围说明书中记录的可交付成果。范围说明书包含可交付成果的验收标准。该标准的界定可能导致质量成本并进而导致项目成本的显著升高或降低。满足所有的验收标准意味着满足相关方的需求。

可作为本过程输入的项目文件包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志记录与质量要求和标准合规性有关的所有假设条件和制约因素。
需求文件。见 5.2.3.1 节。需求文件记录项目和产品为满足相关方的期望应达到的要求，它包括（但不限于）针对项目和产品的质量要求。这些需求有助于项目团队规划将如何实施项目质量控制。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求连接到可交付成果，有助于确保需求文件中的各项需求都得到测试。矩阵提供了核实需求时所需测试的概述。
风险登记册。见 11.2.3.1 节。风险登记册包含可能影响质量要求的各种威胁和机会的信息。
相关方登记册。见 13.1.3.1 节。相关方登记册有助于识别对质量有特别兴趣或影响的相关方，尤其注重客户和项目发起人的需求和期望。

能够影响规划质量管理过程的事业环境因素包括（但不限于）：

政府法规；
特定应用领域的相关规则、标准和指南；
地理分布；
组织结构。
市场条件；
项目或可交付成果的工作条件或运行条件；
文化观念。

适用于本过程的数据分析技术包括（但不限于）：

成本效益分析。成本效益分析是用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选方案。成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本。达到质量要求的主要效益包括减少返工、提高生产率、降低成本、提升相关方满意度及提升赢利能力。对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。
质量成本。与项目有关的质量成本 (COQ) 包含以下一种或多种成本（图 8-5 提供了各组成本的例子）：
预防成本。预防特定项目的产品、可交付成果或服务质量低劣所带来的相关成本。
评估成本。评估、测量、审计和测试特定项目的产品、可交付成果或服务所带来的相关成本。
失败成本（内部/外部）。因产品、可交付成果或服务与相关方需求或期望不一致而导致的相关成本。

最优 COQ 能够在预防成本和评估成本之间找到恰当的投资平衡点，以规避失败成本。有关模型表明，最优项目质量成本，指在投资额外的预防/评估成本时，既无益处又不具备成本效益。

图 8-5质量成本

在规划阶段，项目经理和项目团队决定如何测试或检查产品、可交付成果或服务，以满足相关方的需求和期望，以及如何满足产品的绩效和可靠性目标。不同行业有不同的测试与检查，可能包括软件项目的 α 测试和 β 测试、建筑项目的强度测试、制造和实地测试的检查，以及工程的无损伤测试。

质量管理计划是项目管理计划的组成部分，描述如何实施适用的政策、程序和指南以实现质量目标。它描述了项目管理团队为实现一系列项目质量目标所需的活动和资源。质量管理计划可以是正式或非正式的，非常详细或高度概括的，其风格与详细程度取决于项目的具体需要。应该在项目早期就对质量管理计划进行评审，以确保决策是基于准确信息的。这样做的好处是，更加关注项目的价值定位，降低因返工而造成的成本超支金额和进度延误次数。

质量管理计划包括（但不限于）以下组成部分：

项目采用的质量标准；
项目的质量目标；
质量角色与职责；
需要质量审查的项目可交付成果和过程；
为项目规划的质量控制和质量管理活动；
项目使用的质量工具；
与项目有关的主要程序，例如处理不符合要求的情况、纠正措施程序，以及持续改进程序。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）质量管理计划。如 8.1.3.1 节所述，质量管理计划定义了项目和产品质量的可接受水平，并描述了如何确保可交付成果和过程达到这一质量水平。

质量管理计划还描述了不合格产品的处理方式以及需采取的纠正措施。

可作为本过程输入的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。项目早期与质量管理有关的经验教训，可以运用到项目后期阶段，以提高质量管理的效率与效果。
质量控制测量结果。见 8.3.3.1 节。质量控制测量结果用于分析和评估项目过程和可交付成果的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
质量测量指标。见 8.1.3.2 节。核实质量测量指标是控制质量过程的一个环节。管理质量过程依据这些质量测量指标设定项目的测试场景和可交付成果，用作改进举措的依据。
风险报告。见 11.2.3.2 节。管理质量过程使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素，这些因素能够影响项目的质量目标。

适用于本过程的数据表现技术包括（但不限于）：

亲和图。见 5.2.2.5 节。亲和图可以对潜在缺陷成因进行分类，展示最应关注的领域。
因果图。因果图，又称“鱼骨图”、“why-why分析图”和“石川图”，将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。图 8-9 是因果图的一个例子。
流程图。见 8.1.2.5 节。流程图展示了引发缺陷的一系列步骤。
直方图。直方图是一种展示数字数据的条形图，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。
矩阵图。见 8.1.2.5 节。矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。
散点图。散点图是一种展示两个变量之间的关系的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。

图 8-9因果图

问题解决发现解决问题或应对挑战的解决方案。它包括收集其他信息、具有批判性思维的、创造性的、量化的和/或逻辑性的解决方法。有效和系统化地解决问题是质量保证和质量改进的基本要素。问题可能在控制质量过程或质量审计中发现，也可能与过程或可交付成果有关。使用结构化的问题解决方法有助于消除问题和制定长久有效的解决方案。问题解决方法通常包括以下要素：

定义问题；
识别根本原因；
生成可能的解决方案；
选择最佳解决方案；
执行解决方案；
验证解决方案的有效性。

控制质量是为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。本过程的主要作用是，核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收。控制质量过程确定项目输出是否达到预期目的，这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。

图 8-10 描述本过程的输入、工具与技术和输出。图 8-11 是本过程的数据流向图。

图 8-10控制质量：输入、工具与技术和输出

图 8-11控制质量的数据流向图

控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。

本过程通过测量所有步骤、属性和变量，来核实与规划阶段所描述规范的一致性和合规性。

在整个项目期间应执行质量控制，用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。

控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如，相比其他行业，制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序，为满足标准付出的工作也会更广；在敏捷项目中，控制质量活动可能由所有团队成员在整个项目生命周期中执行，而在瀑布式项目中，控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。

能够影响控制质量过程的事业环境因素包括（但不限于）：

项目管理信息系统；质量管理软件可用于跟进过程或可交付成果中的错误和差异；
政府法规；
特定应用领域的相关规则、标准和指南。

测试是一种有组织的、结构化的调查，旨在根据项目需求提供有关被测产品或服务质量的客观信息。测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。用于评估各项需求的测试的类型、数量和程度是项目质量计划的一部分，具体取决于项目的性质、时间、预算或其他制约因素。测试可以贯穿于整个项目，可以随着项目的不同组成部分变得可用时进行，也可以在项目结束（即交付最终可交付成果）时进行。早期测试有助于识别不合规问题，帮助减少修补不合规组件的成本。

不同应用领域需要不同测试。例如，软件测试可能包括单元测试、集成测试、黑盒测试、白盒测试、接口测试、回归测试、α 测试等；在建筑项目中，测试可能包括水泥强度测试、混凝土和易性测试、在建筑工地进行的旨在测试硬化混凝土结构的质量的无损伤测试，以及土壤试验；在硬件开发中，测试可能包括环境应力筛选、老化测试、系统测试等。

控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果是核实的可交付成果，后者又是确认范围过程的一项输入（见 5.5 节），以便正式验收。如果存在任何与可交付成果有关的变更请求或改进事项，可能会执行变更、开展检查并重新核实。

见 4.5.1.3 节。工作绩效信息包含有关项目需求实现情况的信息、拒绝的原因、要求的返工、纠正措施建议、核实的可交付成果列表、质量测量指标的状态，以及过程调整需求。

可在本过程更新的项目文件包括（但不限于）：

问题日志。见 4.3.3.3 节。多次不符合质量要求的可交付成果通常被记录为问题。
经验教训登记册。见 4.4.3.1 节。质量缺陷的来源、本应可以规避它们的方法，以及有效的处理方式，都应该记录到经验教训登记册中。
风险登记册。见 11.2.3.1 节。在本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。
测试与评估文件。见 8.2.3.2 节。本过程可能导致测试与评估文件修改，使未来的测试更加有效。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

质量管理计划。见 8.1.3.1 节。质量管理计划有助于定义项目所需的资源水平，以实现和维护已定义的质量水平并达到项目测量指标。
范围基准。见 5.4.3.1 节。范围基准识别了可交付成果，决定了需要管理的资源的类型和数量。

适用于本过程的数据表现技术包括（但不限于）图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划（如风险、质量或沟通管理计划）中列出。无论使用什么方法来记录团队成员的角色，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色，而文本型则更适合用于记录详细职责。

层级型。可以采用传统的组织结构图，自上而下地显示各种职位及其相互关系。
工作分解结构 (WBS)。WBS 用来显示如何把项目可交付成果分解为工作包，有助于明确高层级的职责。
组织分解结构 (OBS)。WBS 显示项目可交付成果的分解，而 OBS 则按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包。运营部门（如信息技术部或采购部）只需要找到其所在的 OBS 位置，就能看到自己的全部项目职责。
资源分解结构。资源分解结构是按资源类别和类型，对团队和实物资源的层级列表，用于规划、管理和控制项目工作。每向下一个层次都代表对资源的更详细描述，直到信息细到可以与工作分解结构（WBS）相结合，用来规划和监控项目工作。
责任分配矩阵。责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是职责分配矩阵(RAM)，它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系。在大型项目中，可以制定多个层次的 RAM。例如，高层次的RAM 可定义项目团队、小组或部门负责 WBS 中的哪部分工作，而低层次的 RAM 则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。RAM的一个例子是 RACI（执行、负责、咨询和知情）矩阵，如图 9-4 所示。图中最左边的一列表示有待完成的工作（活动）。分配给每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI 矩阵对明确划分角色和职责特别有用。
文本型。如果需要详细描述团队成员的职责，就可以采用文本型。文本型文件通常以概述的形式，提供诸如职责、职权、能力和资格等方面的信息。这种文件有多种名称，如职位描述、角色 — 职责 — 职权表，该文件可作为未来项目的模板，特别是在根据当前项目的经验教训对其内容进行更新之后。

图 9-4 RACI 矩阵示例

作为项目管理计划的一部分，资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划。资源管理计划可能包括（但不限于）：

识别资源。用于识别和量化项目所需的团队和实物资源的方法。
获取资源。关于如何获取项目所需的团队和实物资源的指南。
角色与职责。
角色。在项目中，某人承担的职务或分配给某人的职务，如土木工程师、商业分析师和测试协调员。
职权。使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力。例如，下列事项都需要由具有明确职权的人来做决策：选择活动的实施方法，质量验收标准，以及如何应对项目偏差等。当个人的职权水平与职责相匹配时，团队成员就能最好地开展工作。
职责。为完成项目活动，项目团队成员必须履行的职责和工作。
能力。为完成项目活动，项目团队成员需具备的技能和才干。如果项目团队成员不具备所需的能力，就不能有效地履行职责。一旦发现成员的能力与职责不匹配，就应主动采取措施，如安排培训、招募新成员、调整进度计划或工作范围。
项目组织图。项目组织图以图形方式展示项目团队成员及其报告关系。基于项目的需要，项目组织图可以是正式或非正式的，非常详细或高度概括的。例如，一个 3000 人的灾害应急团队的项目组织图，要比仅有 20 人的内部项目的组织图详尽得多。
项目团队资源管理。关于如何定义、配备、管理和最终遣散项目团队资源的指南。
培训。针对项目成员的培训策略。
团队建设。建设项目团队的方法。
资源控制。依据需要确保实物资源充足可用、并为项目需求优化实物资源采购，而采用的方法。包括有关整个项目生命周期期间的库存、设备和用品管理的信息。
认可计划。将给予团队成员哪些认可和奖励，以及何时给予。

建设团队是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。

本过程的主要作用是，改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。本过程需要在整个项目期间开展。

图 9-10 描述本过程的输入、工具与技术和输出。图 9-11 是本过程的数据流向图。

图 9-10建设团队：输入、工具与技术和输出

• Projectcharter图 9-11建设团队：数据流向图

项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队，使团队高效运行，并实现项目目标。团队协作是项目成功的关键因素，而建设高效的项目团队是项目经理的主要职责之一。

项目经理应创建一个能促进团队协作的环境，并通过给予挑战与机会、提供及时反馈与所需支持，以及认可与奖励优秀绩效，不断激励团队。通过以下行为可以实现团队的高效运行：

使用开放与有效的沟通；
创造团队建设机遇；
建立团队成员间的信任；
以建设性方式管理冲突；
鼓励合作型的问题解决方法；
鼓励合作型的决策方法。

项目经理在全球化环境和富有文化多样性的项目中工作：团队成员经常来自不同的行业，讲不同的语言，有时甚至会在工作中使用一种特别的“团队语言”或文化规范，而不是使用他们的母语；

项目管理团队应该利用文化差异，在整个项目生命周期中致力于发展和维护项目团队，并促进在相互信任的氛围中充分协作；通过建设项目团队，可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中，团队成员之间都要保持明确、及时、有效（包括效果和效率两个方面）的沟通。建设项目团队的目标包括（但不限于）：

提高团队成员的知识和技能，以提高他们完成项目可交付成果的能力，并降低成本、缩短工期和提高质量；
提高团队成员之间的信任和认同感，以提高士气、减少冲突和增进团队协作；
创建富有生气、凝聚力和协作性的团队文化，从而：（1）提高个人和团队生产率，振奋团队精神，促进团队合作；（2）促进团队成员之间的交叉培训和辅导，以分享知识和经验；
提高团队参与决策的能力，使他们承担起对解决方案的责任，从而提高团队的生产效率，获得更有效和高效的成果。

有一种关于团队发展的模型叫塔克曼阶梯理论 [19，20]，其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕见；而如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。

形成阶段。在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。在这一阶段，团队成员倾向于相互独立，不一定开诚布公。
震荡阶段。在本阶段，团队开始从事项目工作、制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见，团队环境可能变得事与愿违。
规范阶段。在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员会学习相互信任。
成熟阶段。进入这一阶段后，团队就像一个组织有序的单位那样工作，团队成员之间相互依靠，平稳高效地解决问题。
解散阶段。在解散阶段，团队完成所有工作，团队成员离开项目。通常在项目可交付成果完成之后，或者，在结束项目或阶段过程中，释放人员，解散团队。

某个阶段持续时间的长短，取决于团队活力、团队规模和团队领导力。项目经理应该对团队活力有较好的理解，以便有效地带领团队经历所有阶段。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见：

组织内的政治和权力结构；
组织及其他客户组织的环境和文化；
组织变革管理方法和实践；
项目可交付成果所属的行业或类型；
组织沟通技术；
关于遵守与企业沟通有关的法律要求的组织政策与程序；
与安全有关的组织政策与程序；
相关方，包括客户或发起人。

适用于本过程的沟通技能包括（但不限于）：

沟通胜任力。经过裁剪的沟通技能的组合，有助于明确关键信息的目的、建立有效关系、实现信息共享和采取领导行为。
反馈。反馈是关于沟通、可交付成果或情况的反应信息。反馈支持项目经理和团队及所有其他项目相关方之间的互动沟通。例如，指导、辅导和磋商。
非口头技能。例如，通过示意、语调和面部表情等适当的肢体语言来表达意思。镜像模仿和眼神交流也是重要的技能。团队成员应该知道如何通过说什么和不说什么来表达自己的想法。
演示。演示是信息和/或文档的正式交付。向项目相关方明确有效地演示项目信息可包括（但不限于）：
向相关方报告项目进度和信息更新；
提供背景信息以支持决策制定；
提供关于项目及其目标的通用信息，以提升项目工作和项目团队的形象；
提供具体信息，以提升对项目工作和目标的理解和支持力度。

为获得演示成功，应该从内容和形式上考虑以下因素：

受众及其期望和需求；
项目和项目团队的需求及目标。

项目沟通工件可包括（但不限于）：绩效报告、可交付成果的状态、进度进展、产生的成本、演示，以及相关方需要的其他信息。

监督沟通是确保满足项目及其相关方的信息需求的过程。本过程的主要作用是，按沟通管理计划和相关方参与计划的要求优化信息传递流程。本过程需要在整个项目期间开展。图 10-7 描述本过程的输入、工具与技巧和输出。图 10-8 是本过程的数据流向图。

图 10-7监督沟通：输入、工具与技巧和输出

• Projectcharter图 10-8监督沟通：数据流向图

通过监督沟通过程，来确定规划的沟通工件和沟通活动是否如预期提高或保持了相关方对项目可交付成果与预计结果的支持力度。项目沟通的影响和结果应该接受认真的评估和监督，以确保在正确的时间，通过正确的渠道，将正确的内容（发送方和接收方对其理解一致）传递给正确的受众。

监督沟通可能需要采取各种方法，例如，开展客户满意度调查、整理经验教训、开展团队观察、审查问题日志中的数据，或评估相关方参与度评估矩阵（见 13.2.2.5 节）中的变更。

监督沟通过程可能触发规划沟通管理和（或）管理沟通过程的迭代，以便修改沟通计划并开展额外的沟通活动，来提升沟通的效果。这种迭代体现了项目沟通管理各过程的持续性质。问题、关键绩效指标、风险或冲突，都可能立即触发重新开展这些过程。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。需求管理计划可能指出了特别有风险的项目目标。
进度管理计划。见 6.1.3.1 节。进度管理计划可能列出了受不确定性或模糊性影响的一些领域。
成本管理计划。见 7.1.3.1 节。成本管理计划可能列出了受不确定性或模糊性影响的一些领域。
质量管理计划。见 8.1.3.1 节。质量管理计划可能列出了受不确定性或模糊性影响的一些领域，或者关键假设可能引发风险的一些领域。
资源管理计划。见 9.1.3.1 节。资源管理计划可能列出了受不确定性或模糊性影响的一些领域，或者关键假设可能引发风险的一些领域。
风险管理计划。见 11.1.3.1 节。风险管理计划规定了风险管理的角色和职责，说明了如何将风险管理活动纳入预算和进度计划，并描述了风险类别（可用风险分解结构表述）。
范围基准。见 5.4.3.1 节。范围基准包括可交付成果及其验收标准，其中有些可能引发风险；

还包括工作分解结构，可用作安排风险识别工作的框架。

进度基准。见 6.5.3.1 节。可以查看进度基准，找出存在不确定性或模糊性的里程碑日期和可交付成果交付日期，或者可能引发风险的关键假设条件。
成本基准。见 7.3.3.1 节。可以查看成本基准，找出存在不确定性或模糊性的成本估算或资金需求，或者关键假设可能引发风险的方面。

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程，例如，合同、订购单、协议备忘录 (MOA)，或服务水平协议 (SLA)。被授权采购项目所需货物和（或）服务的人员可以是项目团队、管理层或组织采购部（如果有）的成员。

项目采购管理过程包括：

12.1 规划采购管理 — 记录项目采购决策、明确采购方法，及识别潜在卖方的过程。

12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。

12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏，以及关闭合同的过程。

虽然在本指南中，采购过程以界限分明和相互独立的形式出现，但在实践中，采购过程相当复杂且相互作用，还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。

图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中，各项目采购管理过程

以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 12-1项目采购管理概述

项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚，通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家，但应该对采购过程有足够了解，以便做出与合同及合同关系相关的明智决定。通常情况下，项目经理无权签署对组织有约束力的法律协议，这项工作仅由具备相关职权的人员执行。

项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单，如以特定人工单价购买所需的工时，也可以很复杂，如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性，其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。

合同应明确说明预期的可交付成果和结果，包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记，无论合同规定如何详尽，文化和当地法律对合同及其可执行性均有影响。

采购合同中包括条款和条件，也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时，项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同，协议可以是合同、服务水平协议（SLA）、谅解备忘录、协议备忘录（MOA）或订购单。

大多数组织都有相关的书面政策和程序，来专门定义采购规则，并规定谁有权代表组织签署和管理协议。在世界各地，组织虽然用不同的名称来称呼负责采购的单位或部门，如购买部、合同部、采购部或收购部，但其实际职责大同小异。

虽然所有项目文件可能都要经过某种形式的审查与批准，但是，鉴于其法律约束力，合同或协议需要经过更多的审批程序，而且通常会涉及到法务部。在任何情况下，审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果，且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录，以便合同正文使用标准化的法律合同用语。

在复杂项目中，可能需要同时或先后管理多个合同。这种情况下，不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系，可存在于项目的许多层次上。

因应用领域不同，卖方可以是承包商、供货商、服务提供商或供应商；买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中，卖方首先是投标人，然后是中标人，之后是签约供应商或供货商。

中标人可将所承揽的工作当作一个项目加以管理。在这种情况下：

买方就变成了承包商、供应商及服务提供商的客户，因此也就是卖方的关键项目相关方。
卖方的项目管理团队就需要关注工作执行或服务提供所涉及的所有过程。
对于卖方来说，合同条款和条件以及采购工作说明书 (SOW) 都是其许多管理过程的重要输入。

在合同中，可实际列出各种输入（如，主要可交付成果、关键里程碑、成本目标），或者可限制项目团队的选择余地（如，在 IT 整合项目中，关于人员配备的决定往往要征得买方的批准）。另外，采购工作说明书可能使用其他名称，如技术工作说明书。

卖方本身也可能成为更低层级的产品、服务和材料分包商及供应商的买方。

本节假设项目所需物品或服务的买方是项目团队，或者是组织内部的某个部门，同时假设卖方是为项目提供物品或服务的一方，且通常来自执行组织外部。在某些项目上，卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上，卖方可能在授予合同后才成为整合式项目团队的一部分。

在小型组织或初创企业，以及未设置购买、合同或采购部门的组织，项目经理可以拥有采购职权，能够直接谈判并签署合同（分散式采购）。在更成熟的组织中，由专设部门开展实际的采购和合同签署工作，即采购、谈判和签署合同（集中式采购）。

在签署国际合同时，应该在合同中明确规定对合同的法律管辖权。在大多数情况下，卖方是受正式合同关系约束的外部承包商。

采购管理的发展趋势和新兴实践不同行业各方面（软件工具、风险、过程、物流和技术）的一些重大趋势，会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括（但不限于）：

工具的改进。用于管理项目采购和项目执行的工具已经取得重大发展。现在，买方能够使用在线工具集中发布采购广告；卖方也能够使用在线工具集中查找采购文件，并直接在线填写。在施工、工程和基础设施领域，建筑信息模型(BIM) 软件的应用日益广泛，为工程项目节省了大量时间和资金。它能够大幅减少施工索赔，从而降低成本、缩短工期，因此世界各地的主要公司和政府都开始要求在大型项目中使用 BIM。
更先进的风险管理。在风险管理领域日益流行的一个趋势，就是在编制合同时准确地将具体风险分配给最有能力对其加以管理的一方。没有任何承包商有能力管理项目的所有重大风险，买方因而必须接受承包商无法掌控的风险，例如，采购方公司政策的不断变化、法规要求的不断变化，以及项目以外的其他风险。在合同中可以明确规定风险管理是合同工作的一部分。
变化中的合同签署实践。在过去几年时间内，超大型项目的数量显著增加，尤其是在基础设施建设和工程项目领域。数十亿美元的项目现在已十分常见。大部分此类项目都要求与多个国家的多家承包商签署国际合同，因此肯定比仅使用当地承包商的项目具有更大的风险。承包商越来越重视在采购过程中与客户开展密切合作，以便对批量采购或有其他特殊关系的客户给予折扣优惠。对于此类项目来说，为了减少执行过程中的问题和索赔，采用国际公认的标准合同范本也日益普遍。
物流和供应链管理。因为如此多的大型工程、施工和基础设施建设项目都由多家跨国承包商来完成，材料物流管理对于项目成功完成至关重要。对采购周期较长的产品，制造环节和运输（到项目现场）环节都是项目进度的决定因素。在 IT 领域，有些产品可能需要提前 2 至 3 个月订购；在复杂的施工项目上，订购时间可能需要提前 1-2 年，甚至更长。在这些项目上，可能需要在签订其他采购合同之前就采购这些订购周期长的产品，以便项目如期完成。在最终产品的最终设计完成之前，就可能需要根据总体设计中已确定的要求开始订购采购周期较长的材料、用品或设备。供应链管理也是承包商的项目团队日益重视的一个领域。在项目早期，不仅要明确主要的采购渠道，通常还需要明确次要和备选渠道。全球很多国家会要求跨国承包商至少向当地供应商采购一定比例的材料和用品。
技术和相关方关系。公共资助的项目正受越来越多的关注。基础设施和商业建设项目正日益采用包括网络摄像（webcams）在内的技术，以改善与相关方的沟通和关系。在施工期间，施工现场会安装一台或多台网络摄像机，定期更新并发布到公开的网站上，方便所有相关方在互联网上查看项目进展。另外，视频资料可以储存，有助于在索赔发生时进行分析。有些项目显示，使用网络摄像机记录现场情况，能够避免对事实的分歧，从而能够把与现场施工有关的争议降到最低程度。
试用采购。并非每一个卖方都能很好地适应买方组织的环境，因此，在决定大批量采购之前，有些项目会试用多个候选卖方，向他们采购少量的可交付成果和工作产品。这样一来，买方可以在推进项目工作的同时，对潜在合作伙伴进行评估。

裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括（但不限于）：

采购的复杂性。只开展一次主要的采购，或者需要在不同时间向不同卖方进行多次采购（会提高采购的复杂性）？
物理地点。买方和卖方在同一或邻近地点，或者位于不同时区、国家或大洲？
治理和法规环境。组织的采购政策是否和当地相关的法律法规兼容？当地的法律法规会如何影响合同审计工作？
承包商的可用性。是否有具备工作执行能力的承包商可供选择？

在敏捷或适应型环境中需要考虑的因素在敏捷型环境中，可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励。

在大型项目上，可能针对某些可交付成果采用适应型方法，而对其他部分则采用更稳定的方法。

在这种情况下，可以通过主体协议，如主要服务协议（MSA），来管辖整体协作关系，而将适应型工作写入附录或补充文件。这样一来，变更只针对适应型工作，而不会对主体协议造成影响。

可作为本过程输入的项目文件包括（但不限于）：

里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
项目团队派工单。见 9.3.3.2 节。项目团队派工单包含关于项目团队技能和能力的信息，以及他们可用于支持采购活动的时间。如果项目团队不具备开展采购活动的能力，则需要外聘人员或对现有人员进行培训，或者二者同时进行。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
资源需求。见 9.2.3.1 节。资源需求包含关于某些特定需求的信息，例如，可能需要采购的团队及实物资源。
风险登记册。见 11.2.3.1 节。风险登记册列明风险清单，以及风险分析和风险应对规划的结果。有些风险应通过采购协议转移给第三方。
相关方登记册。见 13.1.3.1 节。相关方登记册提供有关项目参与者及其项目利益的详细信息，包括监管机构、合同签署人员和法务人员。

适用于本过程的数据分析技术包括（但不限于）自制或外购分析。自制或外购分析用于确定某项工作或可交付成果最好由项目团队自行完成，还是应该从外部采购。制定自制或外购决策时应考虑的因素包括；组织当前的资源配置及其技能和能力，对专业技术的需求，不愿承担永久雇用的义务，以及对独特技术专长的需求；还要评估与每个自制或外购决策相关的风险。

在自制或外购分析中，可以使用回收期、投资回报率（ROI）、内部报酬率 (IRR)、现金流贴现、净现值（NPV）、收益成本（BCA）或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买。

可在本过程更新的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录任何与法规和合规性、数据收集、数据分析和供方选择分析相关的经验教训。
里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，任何被选中的卖方都会带来特殊的风险。
相关方登记册。见 13.1.3.1 节。更新相关方登记册，记录任何关于相关方的补充信息，尤其是监管机构、合同签署人员，以及法务人员的信息。

合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果，强制买方向卖方支付相应的报酬。合同建立了受法律保护的买卖双方的关系。协议文本的主要内容会有所不同，可包括（但不限于）：

采购工作说明书或主要的可交付成果；
进度计划、里程碑，或进度计划中规定的日期；
绩效报告；
定价和支付条款；
检查、质量和验收标准；
担保和后续产品支持；
激励和惩罚；
保险和履约保函；
下属分包商批准；
一般条款和条件；
变更请求处理；
终止条款和替代争议解决方法。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。项目需求可能因卖方的要求而变更。
质量管理计划。见 8.1.3.1 节。卖方可能提出备选质量标准或备选解决方案，从而影响质量管理计划中规定的质量管理方法。
沟通管理计划。见 10.1.3.1 节。在选定卖方后，需要更新沟通管理计划，记录卖方的沟通需求和方法。
风险管理计划。见 11.1.3.1 节。每个协议和卖方都会带来独特的风险，从而需要更新风险管理计划。具体的风险应该记录到风险登记册中。
采购管理计划。见 12.1.3.1 节。可能需要基于合同谈判和签署的结果，而更新采购管理计划。
范围基准。见 5.4.3.1 节。在执行采购活动时，需明确考虑范围基准中的项目工作分解结构和可交付成果。本过程可能导致对任何一个或全部可交付成果的变更。
进度基准。见 6.5.3.1 节。如果卖方交付成果方面的变更影响了项目的整体进度绩效，则可能需要更新并审批基准进度计划，以反映当前的期望。
成本基准。见 7.3.3.1 节。在项目交付期间，承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

控制采购是管理采购关系，监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。本过程的主要作用是，确保买卖双方履行法律协议，满足项目需求。本过程应根据需要在整个项目期间开展。图 12-6 描述本过程的输入、工具与技术和输出，图 12-7 是本过程的数据流向图。

图 12-6控制采购：输入、工具与技术和输出

• Projectcharter图 12-7控制采购：数据流向图

买方和卖方都出于相似的目的来管理采购合同，每方都必须确保双方履行合同义务，确保各自的合法权利得到保护。合同关系的法律性质，要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果。对于有多个供应商的较大项目，合同管理的一个重要方面就是管理各个供应商之间的沟通。

鉴于其法律意义，很多组织都将合同管理视为独立于项目的一种组织职能。虽然采购管理员可以是项目团队成员，但通常还向另一部门的经理报告。

在控制采购过程中，需要把适当的项目管理过程应用于合同关系，并且需要整合这些过程的输出，以用于对项目的整体管理。如果涉及多个卖方，以及多种产品、服务或成果，就往往需要在多个层级上开展这种整合。

合同管理活动可能包括：

收集数据和管理项目记录，包括维护对实体和财务绩效的详细记录，以及建立可测量的采购绩效指标；
完善采购计划和进度计划；
建立与采购相关的项目数据的收集、分析和报告机制，并为组织编制定期报告；
监督采购环境，以便引导或调整实施；
向卖方付款。

控制措施的质量，包括采购审计的独立性和可信度，是采购系统可靠性的关键决定因素。组织的道德规范、内部法律顾问和外部法律咨询，包括持续的反腐计划，都有助于实现适当的采购控制。

在控制采购过程中，需要开展财务管理工作，包括监督向卖方付款。这是要确保合同中的支付条款得到遵循，确保按合同规定，把付款与卖方的工作进展联系起来。需要重点关注的一点是，确保向卖方的付款与卖方实际已经完成的工作量之间有密切的关系。如果合同规定了基于项目输出及可交付成果来付款，而不是基于项目输入（如工时），那么就可以更有效地开展采购控制。

在合同收尾前，若双方达成共识，可以根据协议中的变更控制条款，随时对协议进行修改。通常要书面记录对协议的修改。

可作为本过程输入的项目文件包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志记录了采购过程中做出的假设。
经验教训登记册。见 4.4.3.1 节。在项目早期获取的经验教训可供项目未来使用，以改进承包商绩效和采购过程。
里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
质量报告。见 8.2.3.1 节。质量报告用于识别不合规的卖方过程、程序或产品。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。
相关方登记册。见 13.1.3.1 节。相关方登记册包括关于已识别相关方的信息，例如，合同团队成员、选定的卖方、签署合同的专员，以及参与采购的其他相关方。

检查是指对承包商正在执行的工作进行结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。在施工、工程和基础设施建设项目中，检查包括买方和承包商联合巡检现场，以确保双方对正在进行的工作有共同的认识。

买方通常通过其授权的采购管理员，向卖方发出合同已经完成的正式书面通知。关于正式关闭采购的要求，通常已在合同条款和条件中规定，并包括在采购管理计划中。一般而言，这些要求包括：已按时按质按技术要求交付全部可交付成果，没有未决索赔或发票，全部最终款项已经付清。

项目管理团队应该在关闭采购之前批准所有的可交付成果。

见 4.5.1.3 节。工作绩效信息是卖方正在履行的工作的绩效情况，包括与合同要求相比较的可交付成果完成情况和技术绩效达成情况，以及与SOW预算相比较的已完工作的成本产生和认可情况。

采购文档更新可包括用于支持合同的全部进度计划、已提出但未批准的合同变更，以及已批准的变更请求。采购文档还包括由卖方编制的技术文件，以及其他工作绩效信息，例如，可交付成果的状况、卖方绩效报告和担保、财务文件（包括发票和支付记录），以及与合同相关的检查结果。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见：

理解组织内的政治和权力结构；
了解所在组织和其他受影响组织（包括客户及其他组织）的环境和文化；
了解项目所在行业或项目可交付成果类型；
了解个体团队成员的贡献和专长。

项目生命周期指项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限，有一个起始点、结束点或控制点（有时称为阶段审查、阶段关口或控制关口，也可以用其他类似名称）。在控制点，需要根据当前环境，重新审查项目章程和商业文件。在该时点，把项目绩效与项目管理计划进行比较，以确定项目是否应该变更、终止或按计划继续。

项目生命周期会受组织、行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点，但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么，生命周期都可以为管理项目提供基本框架。

虽然项目规模及复杂程度各不相同，但是典型项目都呈现下列项目生命周期结构（见图 1-2）：

开始项目；
组织与准备；
执行项目工作；
结束项目。

图 1-2项目生命周期的通用结构

通用的生命周期结构一般具有以下特征：

成本与人力投入在开始时较低，在工作执行期间逐渐增加，并在项目快要结束时迅速回落。
项目开始时风险最大，如图 1-3 所示。在项目的整个生命周期中，随着决策的制定与可交付成果的验收，风险会逐步降低。
在不显著影响成本和进度的前提下，相关方改变项目产品最终特性的能力在项目开始时最大，并随项目进展而减弱。图 1-3 表明，做出变更和纠正错误的成本，通常会随着项目越来越接近完成而显著增高。

图 1-3随时间而变化的变量影响

本标准描述用于实现项目目标的项目管理过程。项目管理过程可归为五大项目管理过程组：

启动过程组定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的过程。启动过程组详见第 2 章。
规划过程组明确项目范围，优化目标，为实现目标制定行动方案的过程。规划过程组详见第 3 章。
执行过程组完成项目管理计划中确定的工作，以满足项目要求的过程。执行过程组详见第 4 章。
监控过程组跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的过程。

监控过程组详见第 5 章。

收尾过程组正式完成或结束项目、阶段或合同所执行的过程（组）。收尾过程组详见第 6 章。

这五大过程组与应用领域（如营销、信息服务或会计）或行业（如建筑、航天、电信）无关。

在阶段或项目完成之前，往往需要反复实施过程组中的单个过程。过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类：

仅开展一次或仅在项目预定义点开展的过程。例如，制定项目章程，以及结束项目或阶段。
根据需要定期开展的过程。例如，在需要资源时开展获取资源过程，在需要使用采购品之前开展实施采购过程。
需要在整个项目期间持续开展的过程。例如，可能需要在整个项目生命周期持续开展定义活动过程，特别是当项目使用滚动式规划或适应型开发方法时；从项目开始到项目结束需要持续开展许多监控过程。

一个过程的输出通常成为另一个过程的输入，或者成为项目或项目阶段的可交付成果。例如，需要把规划过程组编制的项目管理计划和项目文件（如风险登记册、责任分配矩阵等）及其更新，提供给执行过程组作为输入。图 1-4 是各过程组在项目或阶段期间的重叠关系示例。

过程组不同于项目阶段。如果将项目划分为若干阶段，则各过程组中的过程会在每个阶段内相互作用。在一个阶段内可能需要使用所有的过程组，如图 1-5 所示。当项目被分为不同的阶段（例如概念开发、可行性研究、设计、原型、构建或测试等）时，各过程组中的过程根据需要在每个阶段中重复，直到达到该阶段的完工标准。

图 1-5项目或阶段中的过程组相互作用示例

过程组和知识领域涵盖的 49 个过程如表 1-1 所示。

表 1-1项目管理过程组与知识领域

启动过程组包括定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的一组过程。

启动过程组的目的是：协调相关方期望与项目目的，告知相关方项目范围和目标，并商讨他们对项目及相关阶段的参与将如何有助实现其期望。在启动过程中，定义初步项目范围和落实初步财务资源，识别那些将相互作用并影响项目总体结果的相关方，指派项目经理（如果尚未安排）。这些信息应反映在项目章程和相关方登记册中。一旦项目章程获得批准，项目也就正式立项，同时，项目经理就有权将组织资源用于项目活动。

本过程组的主要作用是，确保只有符合组织战略目标的项目才能立项，以及在项目开始时就认真考虑商业论证、项目效益和相关方。在一些组织中，项目经理会参与制定商业论证和分析项目效益，会帮助编写项目章程。在另一些组织中，项目的前期准备工作则由项目发起人、项目管理办公室 (PMO)、项目组合指导委员会或其他相关方群体完成。本标准假设项目已获得发起人或其他治理机构的批准，并且他们在批准项目之前已经审核了商业文件。

虽然商业文件通常是在项目之外创建的，但是要用作项目的输入。商业文件包括商业论证和效益管理计划。图 2-1 显示了项目发起人及商业文件与启动过程的关系。

图 2-1项目边界

如第 1.5 节所述，项目通常划分为多个阶段。一旦划分了阶段，就需要在后续阶段复审从启动过程得到的信息，以确认是否仍然有效。在每个阶段开始时重新开展启动过程，有助于保持项目符合其预定的商业需求，有助于核实项目章程、商业文件和成功标准，有助于复审项目相关方的影响、动机、期望和目标。

发起人、客户和其他相关方参与项目启动，有助于促进他们对项目成功标准达成一致，也有助于提升项目完成时可交付成果通过验收的可能性，以及在整个项目期间相关方的满意程度。

启动过程组包括第 2.1 节至 2.2 节所列的项目管理过程。

图 2-2启动过程组

创建工作分解结构 (WBS) 是把项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构。本过程仅开展一次或仅在项目的预定义点开展。图 3-6 描述了本过程的输入和输出。

图 3-6创建 WBS：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。

本过程需要在整个项目期间开展。图 3-8 描述了本过程的输入和输出。

图 3-8定义活动：输入和输出

究竟需要哪些项目管理计划组件，取决于具体项目的需求。

规划质量管理是识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程。本过程的主要作用是，为在整个项目期间如何管理和核实质量提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-15 描述了本过程的输入和输出。

图 3-15规划质量管理：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。本过程的主要作用是，对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。本过程需要在整个项目期间开展。图 4-2 描述了本过程的输入和输出。

图 4-2指导与管理项目工作：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

实施整体变更控制是指审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是，确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 5-3 描述了本过程的输入和输出。

图 5-3实施整体变更控制：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。图 5-4 描述了本过程的输入和输出。

图 5-4确认范围：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

控制质量是为了评估绩效，确保项目输出完整、正确并满足客户期望，而监督和记录质量管理活动执行结果的过程。本过程的主要作用是，核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收。本过程需要在整个项目期间开展。图 5-8 描述了本过程的输入和输出。

图 5-8控制质量：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

《PMBOK® 指南》的 1.2.4.2 节将阶段定义为“一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束”，过程组中的各个过程会在每个阶段按需要重复开展，直到达到该阶段的完工标准。

连续区间中更倾向于适应型的项目，会使用 X3.2.1 节和 X3.2.2 节所述的两种项目阶段关系模式。

启动过程组是指定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的一组过程。

在适应型项目中，需要频繁回顾和重新确认项目章程。随着项目进展，对优先级的竞争和情况的动态变化，可能导致项目制约因素和成功标准过时。因此，需要定期开展启动过程，以确保项目在最新的制约因素内朝最新的目标推进。

适应型项目非常依赖知识丰富的客户或客户代表，他们要能够持续地表达需要和意愿，并不断针对新形成的可交付成果提出反馈意见。应该在项目开始时就识别出这个相关方或其他相关方，以便在开展执行和监控过程组时与他们频繁互动。有关的反馈意见则能够确保项目交付出正确的成果。

如前所述，在采用适应型生命周期的项目上，启动过程通常要在每个迭代期开展。

项目整合管理的核心概念包括：

项目整合管理是项目经理的具体职责，不能委托或转移。项目经理要整合所有其他知识领域的成果，以提供与项目总体情况有关的信息。项目经理必须对整个项目承担最终责任。
项目和项目管理具有整合性质，大多数任务涉及不止一个知识领域。
项目管理过程组内部和项目管理过程组之间的过程存在迭代型关系。
项目整合管理指的是：
确保项目可交付成果的最终交付日期、项目生命周期及效益实现计划保持一致；
提供可实现项目目标的项目管理计划；
确保创造合适的知识以运用到项目中，并从项目中汲取知识；
管理项目绩效和项目活动的变更；
做出针对影响项目的关键变更的综合决策；
衡量和监督进展，并采取适当的措施；
收集、分析项目信息，并将其传递给有关的相关方；
完成全部项目工作，正式关闭各个阶段、合同以及整个项目；
管理可能需要的阶段过渡。

项目范围管理的核心概念包括：

范围可以指产品范围（产品、服务或成果具有的特性和功能），或项目范围（为交付具有特定特性和功能产品、服务或成果而开展的工作）。
项目生命周期的连续区间涵盖预测型、适应型或敏捷型。在预测型生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理；而在适应型或敏捷型生命周期中，可交付成果经过多次迭代，详细范围得到了定义，并且在每次迭代开始时完成审批。
应该根据项目管理计划来衡量项目范围的完成情况，根据产品需求来衡量产品范围的完成情况。

项目成本管理的核心概念包括：

项目成本管理主要关注完成项目活动所需的资源成本，但它也要考虑到项目决策对后续多次使用、维护和支持项目可交付成果所需成本的影响。
不同的相关方会在不同的时间、用不同的方法测算项目成本，因此应明确考虑管理成本的相关方需求。
预测和分析项目产品的潜在财务绩效可能在项目以外进行，或作为项目成本管理的一部分。

项目质量管理的核心概念包括：

项目质量管理需要兼顾项目管理与项目可交付成果两个方面，它适用于所有项目，无论项目的可交付成果具有何种特性。质量的测量方法和技术则需视专门针对项目所产生的可交付成果类型而定。
质量和等级是不同的概念。质量是“一系列内在特性满足要求的程度”（ISO 9000）1，而等级是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及团队要负责权衡，以便同时达到所要求的质量与等级水平。
预防胜于检查。最好是在设计时考虑可交付成果的质量，而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。
项目经理可能需要熟悉抽样。属性抽样的结果为合格或不合格，而变量抽样指的是在连续的量表上标明结果所处的位置，以表明合格的程度。
很多项目会为项目和产品衡量确立公差（结果的可接受范围）和控制界限（在统计意义上稳定的过程或过程绩效的普通差异的边界）。
质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求（返工）而发生的所有成本。质量成本通常关注项目集管理、项目组合管理、PMO 或运营。
当质量整合到项目和产品规划和设计中时，以及组织文化意识致力于提高质量时，就能达成最有效的质量管理。

X4.6项目资源管理的核心概念项目资源管理的核心概念包括：

项目资源包括物质资源（设备、材料、设施和基础设施）和团队资源（担任项目角色及承担相关职责的人员）。
管理团队资源和物质资源需要不同的技能和能力。
项目经理应同时是项目团队的主管和经理，而且应在聘用、管理、激励和授权团队成员方面做出适当的努力。
项目经理应了解影响团队的因素，例如，团队环境、团队成员所在的地理位置、相关方之间的沟通、组织变更管理、内部和外部政治、文化问题，以及组织的独特性，uu项目经理还负责积极培养团队技能和能力，同时提高并保持团队的满意度和积极性。
物质资源管理着眼于以有效和高效的方式，分配和使用成功完成项目所需的物质资源，而无法有效管理和控制资源可能会降低项目顺利完工的概率。

为了体现更全球化的视角，我们更新了此知识领域内的大量信息。许多项目是由在多个不同国家的相关方来完成的，或由多个不同国家所设置办公室的组织负责。

市场调查结果显示，实际上很少由项目经理负责结束采购。而是通常由合同、采购或法务部门中拥有此项职权的相关人员负责。因此，结束采购中关于评估所有已完成的可交付成果以及将其与合同比较的信息，已合并到控制采购中；与行政、沟通和记录有关的信息也移到结束项目或阶段。

与从 X1.1 至 X1.11 节所述信息一致的变更也得到采纳。表 X1-7 对第 12 章的过程进行了总结：

表 X1-7 第 12 章变更

4.4.1.3 可交付成果