1.5 项目生命周期

标准是基于权威、惯例或共识而建立并用作模式或范例的文件。本标准的开发过程遵循协商一致、开放公开、程序公正和各方平衡的基本原则。本标准描述在大多数时候适用于大多数项目的、被视为良好实践的过程，并把这些过程归入相应的过程组。本标准也对关键的项目管理概念进行定义，包括项目管理与组织战略及目标的关系，项目管理与组织治理、项目组合管理、项目集管理、项目环境及项目成功之间的关系。本标准还介绍项目生命周期、项目相关方，以及项目经理的角色。第 1 章介绍一些基本概念，并提供有关项目管理的背景信息。第 2 章至第 6 章对五大过程组进行逐一定义，并描述其下属过程。第 2 章至第 6 章还描述各项目管理过程的主要作用、输入和输出。本标准将作为《项目管理知识体系指南》（《PMBOK® 指南》）1 的基础和框架。《PMBOK® 指南》通过对相关背景、环境及其对项目管理的影响进行更深入的阐述，来扩展本标准的内容。此外，《PMBOK® 指南》也描述项目管理过程的输入和输出，识别项目管理过程的工具和技术，并按知识领域讨论一些重要概念和新趋势。

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

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

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

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

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

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

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

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

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

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

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

项目经理应适当地为项目裁剪上述项目管理文件。某些组织会维护项目集层面的商业论证和效益管理计划。项目经理应与相应的项目集经理合作，确保项目管理文件与项目集文件保持一致。图 1-8说明了这些关键项目管理商业文件与需求评估之间的相互关系。图 1-8 展示了项目生命周期内各种文件大概的生命周期。

通过将成果与目标和确定的成功标准进行比较，商业论证文件为衡量整个项目生命周期的成功和进展奠定了基础。请参见《从业者商业分析：实践指南》[7]。

项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划的补充性文件。项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生命周期内始终保持一致。请参见《从业者商业分析：实践指南》[7]、《项目集管理标准》[3]和《项目组合管理标准》[2]。

除了事业环境因素和组织过程资产，组织系统对项目生命周期也起着重要的作用。组织系统（见2.4 节）进一步讨论了影响了组织系统内部人员的权力、影响力、利益、技能和政治能力的系统因素。

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

• 启动和规划nn指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
• 特定的组织标准，例如政策（如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策）；
• 产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义）；
• 模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及相关方登记册模板）；
• 预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和工料合同）。
• 执行、监控：
• 变更控制程序，包括修改组织标准、政策、计划和程序（或任何项目文件）所须遵循的步骤，以及如何批准和确认变更；
• 跟踪矩阵；
• 财务控制程序（如定期报告、必需的费用与支付审查、会计编码及标准合同条款等）；
• 问题与缺陷管理程序（如定义问题和缺陷控制、识别与解决问题和缺陷，以及跟踪行动方案）。
• 资源的可用性控制和分配管理；
• 组织对沟通的要求（如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求）；
• 确定工作优先顺序、批准工作与签发工作授权的程序；
• 模板（如风险登记册、问题日志和变更日志）；
• 标准化的指南、工作指示、建议书评价准则和绩效测量准则；
• 产品、服务或成果的核实和确认程序。
• 收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配，以及向生产和（或）运营部门转移知识）

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

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

项目整合管理过程包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

项目整合管理指的是：

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

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

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

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

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

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

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

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

通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。

项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件，取决于具体项目的需求。

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

• 子管理计划：
• 范围管理计划。见 5.1.3.1 节。确立如何定义、制定、监督、控制和确认项目范围。
• 需求管理计划。见 5.1.3.2 节。确定如何分析、记录和管理需求。
• 进度管理计划。见 6.1.3.1 节。为编制、监督和控制项目进度建立准则并确定活动。
• 成本管理计划。见 7.1.3.1 节。确定如何规划、安排和控制成本。
• 质量管理计划。见 8.1.3.1 节。确定在项目中如何实施组织的质量政策、方法和标准。
• 资源管理计划。见 9.1.3.1 节。指导如何对项目资源进行分类、分配、管理和释放。
• 沟通管理计划。见 10.1.3.1 节。确定项目信息将如何、何时、由谁来进行管理和传播。
• 风险管理计划。见 11.1.3.1 节。确定如何安排与实施风险管理活动。
• 采购管理计划。见 12.1.3.1 节。确定项目团队将如何从执行组织外部获取货物和服务。
• 相关方参与计划。见 13.2.3.1 节。确定如何根据相关方的需求、利益和影响让他们参与项目决策和执行。
• 基准：
• 范围基准。见 5.4.3.1 节。经过批准的范围说明书、工作分解结构 (WBS) 和相应的 WBS 词典，用作比较依据。
• 进度基准。见 6.5.3.1 节。经过批准的进度模型，用作与实际结果进行比较的依据。
• 成本基准。见 7.3.3.1 节。经过批准的、按时间段分配的项目预算，用作与实际结果进行比较的依据。
• 其他组件。大多数项目管理计划组件都来自于其他过程，虽然有些组件是在本过程生成的。

虽然在本过程生成的组件会因项目而异，但是通常包括（但不限于）：

• 变更管理计划。描述在整个项目期间如何正式审批和采纳变更请求。
• 配置管理计划。描述如何记录和更新项目的特定信息，以及该记录和更新哪些信息，以保持产品、服务或成果的一致性和（或）有效性。
• 绩效测量基准。经过整合的项目范围、进度和成本计划，用作项目执行的比较依据，以测量和管理项目绩效。
• 项目生命周期。描述项目从开始到结束所经历的一系列阶段。
• 开发方法。描述产品、服务或成果的开发方法，例如预测、迭代、敏捷或混合型模式。
• 管理审查。确定项目经理和有关相关方审查项目进展的时间点，以考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施。

项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划，但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。

表 4-1项目管理计划和项目文件

问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。作为本过程的输出，问题日志被首次创建，尽管在项目期间任何时候都可能发生问题。在整个项目生命周期应该随同监控活动更新问题日志。

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

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

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

• 质量管理计划。见 8.1.3.1 节。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
• 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
• 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

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

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；工作包是 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 模板，可以在裁剪后应用于特定领域的具体项目。

滚动式规划是一种迭代式的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。它是一种渐进明细的规划方式，适用于工作包、规划包以及采用敏捷或瀑布式方法的发布规划。因此，在项目生命周期的不同阶段，工作的详细程度会有所不同。在早期的战略规划阶段，信息尚不够明确，工作包只能分解到已知的详细水平；而后，随着了解到更多的信息，近期即将实施的工作包就可以分解到具体的活动。

在项目生命周期中，项目估算的准确性亦将随着项目的进展而逐步提高。例如，在启动阶段可得出项目的粗略量级估算（Rough Order of Magnitude，ROM），其区间为 −25% 到 +75%；之后，随着信息越来越详细，确定性估算的区间可缩小至 −5% 到 +10%。某些组织已经制定出相应的指南，规定何时进行优化，以及每次优化所要达到的置信度或准确度。

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

• 挣值分析 (EVA)。挣值分析将实际进度和成本绩效与绩效测量基准进行比较。EVM把范围基准、成本基准和进度基准整合起来，形成绩效测量基准。它针对每个工作包和控制账户，计算并监测以下三个关键指标：
• 计划价值。计划价值（PV）是为计划工作分配的经批准的预算，它是为完成某活动或工作分解结构 (WBS) 组成部分而准备的一份经批准的预算，不包括管理储备。应该把该预算分配至项目生命周期的各个阶段；在某个给定的时间点，计划价值代表着应该已经完成的工作。PV的总和有时被称为绩效测量基准（PMB），项目的总计划价值又被称为完工预算（BAC）。
• 挣值。挣值（EV）是对已完成工作的测量值，用该工作的批准预算来表示，是已完成工作的经批准的预算。EV 的计算应该与 PMB 相对应，且所得的 EV 值不得大于相应组件的 PV 总预算。

EV 常用于计算项目的完成百分比，应该为每个 WBS 组件规定进展测量准则，用于考核正在实施的工作。项目经理既要监测 EV 的增量，以判断当前的状态，又要监测 EV 的累计值，以判断长期的绩效趋势。

• 实际成本。实际成本（AC）是在给定时段内，执行某活动而实际发生的成本，是为完成与 EV相对应的工作而发生的总成本。AC 的计算方法必须与 PV 和 EV 的计算方法保持一致（例如，都只计算直接小时数，都只计算直接成本，或都计算包含间接成本在内的全部成本）。AC 没有上限，为实现 EV 所花费的任何成本都要计算进去。
• 偏差分析。见 4.5.2.2 节。在 EVM 中，偏差分析用以解释成本偏差（CV = EV – AC）、进度偏差（SV = EV – PV）和完工偏差（VAC = BAC – EAC）的原因、影响和纠正措施。成本和进度偏差是最需要分析的两种偏差。对于不使用正规挣值分析的项目，可开展类似的偏差分析，通过比较计划成本和实际成本，来识别成本基准与实际项目绩效之间的差异；然后可以实施进一步的分析，以判定偏离进度基准的原因和程度，并决定是否需要采取纠正或预防措施。可通过成本绩效测量来评价偏离原始成本基准的程度。项目成本控制的重要工作包括：判定偏离成本基准（见 7.3.3.1 节）的原因和程度，并决定是否需要采取纠正或预防措施。随着项目工作的逐步完成，偏差的可接受范围（常用百分比表示）将逐步缩小。偏差分析包括（但不限于）：
• 进度偏差。进度偏差（SV）是测量进度绩效的一种指标，表示为挣值与计划价值之差。

它是指在某个给定的时点，项目提前或落后的进度，它是测量项目进度绩效的一种指标，等于挣值（EV）减去计划价值（PV）。EVA 进度偏差是一种有用的指标，可表明项目进度是落后还是提前于进度基准。当项目完工时，全部的计划价值都将实现（即成为挣值），所以 EVA 进度偏差最终将等于零。最好把进度偏差与关键路径法 (CPM) 和风险管理一起使用。

公式：SV = EV – PV。

• 成本偏差。成本偏差（CV）是在某个给定时点的预算亏空或盈余量，表示为挣值与实际成本之差。它是测量项目成本绩效的一种指标，等于挣值（EV）减去实际成本（AC）。

项目结束时的成本偏差，就是完工预算（BAC）与实际成本之间的差值。由于成本偏差指明了实际绩效与成本支出之间的关系，所以非常重要。负的 CV 一般都是不可挽回的。公式：CV = EV – AC。

• 进度绩效指数。进度绩效指数（SPI）是测量进度效率的一种指标，表示为挣值与计划价值之比，反映了项目团队完成工作的效率。有时与成本绩效指数（CPI）一起使用，以预测项目的最终完工估算。当 SPI 小于 1.0 时，说明已完成的工作量未达到计划要求；当 SPI 大于1.0 时，则说明已完成的工作量超过计划。由于 SPI 测量的是项目的总工作量，所以还需要对关键路径上的绩效进行单独分析，以确认项目是否将比计划完成日期提前或推迟完工。SPI等于 EV 与 PV 的比值。公式：SPI = EV/PV。
• 成本绩效指数。成本绩效指数（CPI）是测量预算资源的成本效率的一种指标，表示为挣值与实际成本之比。它是最关键的 EVA 指标，用来测量已完成工作的成本效率。当 CPI 小于 1.0时，说明已完成工作的成本超支；当 CPI 大于 1.0 时，则说明到目前为止成本有结余。CPI 等于 EV 与 AC 的比值。公式：CPI = EV/AC。
• 趋势分析。见 4.5.2.2 节。趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。图形分析技术有助于了解截至目前的绩效情况，并把发展趋势与未来的绩效目标进行比较，如 BAC 与EAC、预测完工日期与计划完工日期的比较。趋势分析技术包括（但不限于）：
• 图表。在挣值分析中，对计划价值、挣值和实际成本这三个参数，既可以分阶段（通常以周或月为单位）进行监督和报告，也可以针对累计值进行监督和报告。图 7-12 以 S 曲线展示了某个项目的 EV 数据，该项目预算超支且进度落后。

图 7-12挣值、计划价值和实际成本

• 预测。随着项目进展，项目团队可根据项目绩效，对完工估算（EAC）进行预测，预测的结果可能与完工预算（BAC）存在差异。如果 BAC 已明显不再可行，则项目经理应考虑对EAC进行预测。预测EAC是根据当前掌握的绩效信息和其他知识，预计项目未来的情况和事件。

预测要根据项目执行过程中所提供的工作绩效数据（见 4.3.3.2 节）来产生、更新和重新发布。工作绩效信息包含项目过去的绩效，以及可能在未来对项目产生影响的任何信息。

在计算 EAC 时，通常用已完成工作的实际成本，加上剩余工作的完工尚需估算（ETC）。

项目团队要根据已有的经验，考虑实施 ETC 工作可能遇到的各种情况。把挣值分析与手工预测 EAC 方法联合起来使用，效果会更佳。由项目经理和项目团队手工进行的自下而上汇总方法，就是一种最普通的 EAC 预测方法。

项目经理所进行的自下而上的 EAC 估算，就是以已完成工作的实际成本为基础，并根据已积累的经验来为剩余项目工作编制一个新估算。公式：EAC = AC + 自下而上的 ETC。

可以很方便地把项目经理手工估算的 EAC 与计算得出的一系列 EAC 作比较，这些计算得出的EAC 代表了不同的风险情景。在计算 EAC 值时，经常会使用累计 CPI 和累计 SPI 值。尽管可以用许多方法来计算基于 EVM 数据的 EAC 值，但下面只介绍最常用的三种方法：

mm假设将按预算单价完成 ETC 工作。这种方法承认以实际成本表示的累计实际项目绩效（不论好坏），并预计未来的全部 ETC 工作都将按预算单价完成。如果目前的实际绩效不好，则只有在进行项目风险分析并取得有力证据后，才能做出“未来绩效将会改进”的假设。

公式：EAC = AC +（BAC – EV）。

mm假设以当前 CPI 完成 ETC 工作。这种方法假设项目将按截至目前的情况继续进行，即 ETC工作将按项目截至目前的累计成本绩效指数（CPI）实施。公式：EAC = BAC/CPI。

mm假设 SPI 与 CPI 将同时影响 ETC 工作。在这种预测中，需要计算一个由成本绩效指数与进度绩效指数综合决定的效率指标，并假设 ETC 工作将按该效率指标完成。如果项目进度对 ETC 有重要影响，这种方法最有效。使用这种方法时，还可以根据项目经理的判断，分别给 CPI 和 SPI 赋予不同的权重，如 80/20、50/50 或其他比率。公式：EAC =AC +［（BAC – EV）/（CPI x SPI）］。

• 储备分析。见 7.2.2.6 节。在控制成本过程中，可以采用储备分析来监督项目中应急储备和管理储备的使用情况，从而判断是否还需要这些储备，或者是否需要增加额外的储备。随着项目工作的进展，这些储备可能已按计划用于支付风险或其他应急情况的成本；反之，如果抓住机会节约了成本，节约下来的资金可能会增加到应急储备中，或作为盈利/利润从项目中剥离。

如果已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备，为其他项目或运营腾出资源。同时，在项目中开展进一步风险分析，可能会发现需要为项目预算申请额外的储备。

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

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

组织理论阐述个人、团队和组织部门的行为方式。有效利用组织理论中的常用技术，可以节约规划资源管理过程的时间、成本及人力投入，提高规划工作的效率。此外，可以根据相关的组织理论灵活使用领导风格，以适应项目生命周期中团队成熟度的变化。重要的是要认识到，组织的结构和文化影响项目组织结构。

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

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

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

大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业技能迎接新挑战，而受到激励。项目经理应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时。

适用于本过程的人际关系与团队技能包括（但不限于）：

• 冲突管理。在项目环境中，冲突不可避免。冲突的来源包括资源稀缺、进度优先级排序和个人工作风格差异等。采用团队基本规则、团队规范及成熟的项目管理实践（如沟通规划和角色定义），可以减少冲突的数量。

成功的冲突管理可提高生产力，改进工作关系。同时，如果管理得当，意见分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素，应该首先由项目团队成员负责解决；如果冲突升级，项目经理应提供协助，促成满意的解决方案，采用直接和合作的方式，尽早并且通常在私下处理冲突。如果破坏性冲突继续存在，则可使用正式程序，包括采取惩戒措施。

项目经理解决冲突的能力往往决定其管理项目团队的成败。不同的项目经理可能采用不同的解决冲突方法。影响冲突解决方法的因素包括：

• 冲突的重要性与激烈程度；
• 解决冲突的紧迫性；
• 涉及冲突的人员的相对权力；
• 维持良好关系的重要性；
• 永久或暂时解决冲突的动机。

有五种常用的冲突解决方法，每种技巧都有各自的作用和用途。

mm撤退/回避。从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。

mm缓和/包容。强调一致而非差异；为维持和谐与关系而退让一步，考虑其他方的需要。

mm妥协/调解。为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案，但这种方法有时会导致“双输”局面。

mm强迫/命令。以牺牲其他方为代价，推行某一方的观点；只提供赢 — 输方案。通常是利用权力来强行解决紧急问题，这种方法通常会导致“赢输”局面。

mm合作/解决问题。综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺，这种方法可以带来双赢局面。

• 制定决策。这种情况下，决策包括谈判能力以及影响组织与项目管理团队的能力，而不是决策工具集所描述的一系列工具。进行有效决策需要：
• 着眼于所要达到的目标；
• 遵循决策流程；
• 研究环境因素；
• 分析可用信息；
• 激发团队创造力；
• 理解风险。
• 情商。情商指识别、评估和管理个人情绪、他人情绪及团体情绪的能力。项目管理团队能用情商来了解、评估及控制项目团队成员的情绪，预测团队成员的行为，确认团队成员的关注点及跟踪团队成员的问题，来达到减轻压力、加强合作的目的。
• 影响力。在矩阵环境中，项目经理对团队成员通常没有或仅有很小的命令职权，所以他们适时影响相关方的能力，对保证项目成功非常关键。影响力主要体现在如下各方面：
• 说服他人；
• 清晰表达观点和立场；
• 积极且有效的倾听；
• 了解并综合考虑各种观点；
• 收集相关信息，在维护相互信任的关系下，解决问题并达成一致意见。
• 领导力。成功的项目需要强有力的领导技能，领导力是领导团队、激励团队做好本质工作的能力。它包括各种不同的技巧、能力和行动。且领导力在项目生命周期中的所有阶段都很重要。

有多种领导力理论，定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。

应在所有项目阶段和整个项目生命周期期间持续开展控制资源过程，且适时、适地和适量地分配和释放资源，使项目能够持续进行。控制资源过程关注实物资源，例如设备、材料、设施和基础设施。管理团队过程关注团队成员。

需在项目生命周期的早期，针对项目相关方多样性的信息需求，制定有效的沟通管理计划。应该定期审核沟通管理计划，并进行必要的修改，例如在相关方社区发生变化或每个新项目阶段开始时。

因为风险会在项目生命周期内持续发生，所以，项目风险管理过程也应不断迭代开展。在项目规划期间，就应该通过调整项目策略对风险做初步处理。接着，应该随着项目进展，监督和管理风险，确保项目处于正轨，并且突发性风险也得到处理。

规划风险管理过程在项目构思阶段就应开始，并在项目早期完成。在项目生命周期的后期，可能有必要重新开展本过程，例如，在发生重大阶段变更时，在项目范围显著变化时，或者后续对风险管理有效性进行审查且确定需要调整项目风险管理过程时。

风险管理计划是项目管理计划的组成部分，描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容：

• 风险管理战略。描述用于管理本项目的风险的一般方法。
• 方法论。确定用于开展本项目的风险管理的具体方法、工具及数据来源。
• 角色与职责。确定每项风险管理活动的领导者、支持者和团队成员，并明确他们的职责。
• 资金。确定开展项目风险管理活动所需的资金，并制定应急储备和管理储备的使用方案。
• 时间安排。确定在项目生命周期中实施项目风险管理过程的时间和频率，确定风险管理活动并将其纳入项目进度计划。
• 风险类别。确定对单个项目风险进行分类的方式。通常借助风险分解结构 (RBS)来构建风险类别。风险分解结构是潜在风险来源的层级展现（示例见图 11-4）。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源，对识别风险或归类已识别风险特别有用。组织可能有适用于所有项目的通用风险分解结构，也可能针对不同类型项目使用几种不同的风险分解结构框架，或者允许项目量身定制专用的风险分解结构。如果未使用风险分解结构，组织则可能采用某种常见的风险分类框架，既可以是简单的类别清单，也可以是基于项目目标的某种类别结构。

图 11-4风险分解结构（RBS）示例

• 相关方风险偏好。应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是，应该针对每个项目目标，把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平，而且也用于制定概率和影响定义。以后将根据概率和影响定义，对单个项目风险进行评估和排序。
• 风险概率和影响定义。根据具体的项目环境，组织和关键相关方的风险偏好和临界值，来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义，或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度，来确定概率和影响级别的数量，即：更多级别（通常为五级）对应于更详细的风险管理方法，更少级别（通常为三级）对应于更简单的方法。表 11-1 针对三个项目目标提供了概率和影响定义的示例。

通过将影响定义为负面威胁（工期延误、成本增加和绩效不佳）和正面机会（工期缩短、成本节约和绩效改善），表格所示的量表可同时用于评估威胁和机会。

表 11-1概率和影响定义示例

• 概率和影响矩阵。见 11.3.2.6 节。组织可在项目开始前确定优先级排序规则，并将其纳入组织过程资产，或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中，会同时列出机会和威胁；以正面影响定义机会，以负面影响定义威胁。概率和影响可以用描述性术语（如很高、高、中、低和很低）或数值来表达。如果使用数值，就可以把两个数值相乘，得出每个风险的概率 - 影响分值，以便据此在每个优先级组别之内排列单个风险相对优先级。

图 11-5 是概率和影响矩阵的示例，其中也有数值风险评分的可能方法。

图 11-5概率和影响矩阵示例（有评分方法）

• 报告格式。确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分，描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
• 跟踪。跟踪是确定将如何记录风险活动，以及将如何审计风险的管理过程。

在整个项目生命周期中，单个项目风险可能随项目进展而不断出现，整体项目风险的级别也会发生变化。因此，识别风险是一个迭代的过程。迭代的频率和每次迭代所需的参与程度因情况而异，应在风险管理计划中做出相应规定。

根据风险管理计划的规定，在整个项目生命周期中要定期开展实施定性风险分析过程。在敏捷开发环境中，实施定性风险分析过程通常要在每次迭代开始前进行。

可作为本过程输出的项目文件包括（但不限于）风险报告（见 11.2.3.2 节）。更新风险报告，反映定量风险分析的结果，通常包括：

• 对整体项目风险敞口的评估结果。整体项目风险有两种主要的测量方式：
• 项目成功的可能性。基于已识别的单个项目风险和其他不确定性来源，项目实现其主要目标（例如，既定的结束日期或中间里程碑、既定的成本目标）的概率。
• 项目固有的变异性。在开展定量分析之时，可能的项目结果的分布区间。
• 项目详细概率分析的结果。列出定量风险分析的重要输出，如 S 曲线、龙卷风图和关键性指标，以及对它们的叙述性解释。定量风险分析的详细结果可能包括：
• 所需的应急储备，以达到实现目标的特定置信水平；
• 对项目关键路径有最大影响的单个项目风险或其他不确定性来源的清单；
• 整体项目风险的主要驱动因素，即：对项目结果的不确定性有最大影响的因素。
• 单个项目风险优先级清单。根据敏感性分析的结果，列出对项目造成最大威胁或产生最大机会的单个项目风险。
• 定量风险分析结果的趋势。随着在项目生命周期的不同时间重复开展定量风险分析，风险的发展趋势可能逐渐清晰。发展趋势会影响对风险应对措施的规划。
• 风险应对建议。风险报告可能根据定量风险分析的结果，针对整体项目风险敞口或关键单个项目风险提出应对建议。这些建议将成为规划风险应对过程的输入。

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

相关方登记册是识别相关方过程的主要输出。它记录关于已识别相关方的信息，包括（但不限于）：

• 身份信息。姓名、组织职位、地点、联系方式，以及在项目中扮演的角色。
• 评估信息。主要需求、期望、影响项目成果的潜力，以及相关方最能影响或冲击的项目生命周期阶段。
• 相关方分类。用内部或外部，作用、影响、权力或利益，上级、下级、外围或横向，或者项目经理选择的其他分类模型，进行分类的结果。

• Projectcharter为满足项目相关方的多样性信息需求，应该在项目生命周期的早期制定一份有效的计划；然后，随着相关方社区的变化，定期审查和更新该计划。在通过识别相关方过程明确最初的相关方社区之后，就应该编制第一版的相关方参与计划，然后定期更新相关方参与计划，以反映相关方社区的变化。会触发该计划更新的典型情况包括（但不限于）：

启动项目旨在抓住与组织的战略目标相符的商业机会。在启动项目之前，通常需要编制商业论证，以概述项目目标、所需投资，以及用于测量项目成功的财务标准和其他量化标准。商业论证为在整个项目生命周期中衡量项目成功和进展奠定了基础，以便把实际结果与预定的目标和成功标准进行比较。

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

供全方位资助，包括资金支持、政治支持或其他类型的支持。在整个项目生命周期内，他们参与项目的方式和程度可能差别很大，因此，在整个项目生命周期中，有效识别和分析相关方，引导他们合理参与，并有效管理他们对项目的期望和参与，对项目成功至关重要。

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

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

监控过程组详见第 5 章。

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

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

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

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

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

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

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

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

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

项目管理计划是最常用的工件，有许多组成部分，如子管理计划、基准和项目生命周期描述。

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

规划过程组包括明确项目全部范围、定义和优化目标，并为实现目标制定行动方案的一组过程。规划过程组中的过程制定项目管理计划的组成部分，以及用于执行项目的项目文件。取决于项目本身的性质，可能需要通过多轮反馈来做进一步分析。随着收集和掌握更多的项目信息或特性，项目很可能需要进一步规划。项目生命周期中发生的重大变更，可能引发重新开展一个或多个规划过程，甚至一个或全部两个启动过程。这种对项目管理计划的持续精细化叫做“渐进明细”，表明项目规划和文件编制是迭代或持续开展的活动。本过程组的主要作用是，确定成功完成项目或阶段的行动方案。

可用作本过程输入的项目管理计划组件包括（但不限于）：

• 质量管理计划；
• 项目生命周期描述；
• 开发方法。

《PMBOK® 指南》的1.2.4.1 节指出“项目生命周期需要足够灵活，能够应对项目包含的各种因素”。

处于连续区间中间位置的项目生命周期，可以更倾向于预测型或敏捷型。这取决于需求的确定方式、风险与成本的管理方式，以及关键相关方的参与性质。处于连续区间中间位置的项目可以采用混合型项目方法。

高度适应型项目往往在整个项目生命周期内持续实施所有的项目管理过程组。受来自精益思维的技术的启发，这种方法往往被称为“持续且适应式规划”。它承认：工作一旦开始，计划就需根据新情况而改变。其目的是，不断调整和改进项目管理计划的所有要素，而不局限在迭代中的预定检查点。这种方法中的过程组相互作用，见图 X3-3 所示。

如上节所述，无论所用的项目生命周期是处于连续区间的哪一个位置，每个项目都需要使用每一个项目管理过程组。在适应型和高度适应型生命周期中，过程组之间相互作用的方式会有所不同。

通常，高预测型项目生命周期的特点是，项目范围变更很少，以及相关方之间有高度共识。这类项目会受益于前期的详细规划。而适应型生命周期的特点是，先基于初始需求制定一套高层级的计划，再逐渐把需求细化到适合特定规划周期所需的详细程度。因此，预测型和适应型生命周期的主要区别在于：做多少规划工作，以及什么时间做。

在敏捷型、迭代型和适应型项目生命周期中，通过迭代对工作进行指导和管理。每次迭代都是在一个很短的固定时间段内开展工作，然后演示所形成的功能或设计。有关的相关方和团队再基于演示来开展回顾性审查。这种演示和审查有助于对照计划检查进展情况，确定是否有必要对项目范围、进度或执行过程做任何变更；也有助于通过展示已完成的工作增量，以及讨论未来工作，更好地管理相关方参与。进行回顾性审查，有利于及时发现和讨论与执行方法有关的问题，以及提出改进建议。通过讨论富有成效的做法以及依靠团队解决问题，回顾性审查也是管理项目知识和建设项目团队的主要工具。

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

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

项目风险管理的核心概念包括：

• 所有项目都有风险。组织应选择承担项目风险，以便创造价值并在风险和奖励之间取得平衡。
• 项目风险管理的目的在于，识别并管理其他项目管理过程中未处理的风险。
• 每个项目中都存在两个级别的风险：单个风险指的是一旦发生，会对一个或多个项目目标产生积极或消极影响的不确定事件或条件；整体项目风险指的是不确定性对项目整体的影响，它代表相关方面临的项目结果可能的积极和消极变化。这些影响源于包括单个风险在内的所有不确定性。项目风险管理过程要处理这两个项目级别上的风险。
• 一旦发生，单个风险可能对项目目标产生积极或消极的影响，而整体项目风险也有积极或消极之分。
• 在项目生命周期内，风险将持续涌现，所以，项目风险管理过程也应不断重复。
• 为了对特定项目的风险进行有效管理，项目团队需要认清在努力实现项目目标过程中，什么级别的风险敞口可以接受。这一点则由反映组织与项目相关者风险偏好的可测量风险临界值来确定。

裁剪项目整合管理时要考虑的因素包括（但不限于）：

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

并非每个项目管理计划组成部分都在独立的过程中创建，部分组件将在制定项目管理计划的过程中创建。它们包括变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法和管理审查。