PMBOK/PMP 项目管理计划

阶段关口在项目阶段结束时进行，将项目的绩效和进度与项目和业务文件比较，这些文件包括（但不限于）：

项目商业论证（见 1.2.6.1 节）；
项目章程（见 4.1 节）；
项目管理计划（见 4.2 节）；
效益管理计划（见 1.2.6.2 节）。

根据比较结果做出决定（例如继续/终止的决定），以便：

进入下个阶段；
整改后进入下个阶段；
结束项目；
停留在当前阶段；
重复阶段或某个要素。

在不同的组织、行业或工作类型中，阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。组织可以通过这些审查来检查本指南范围之外的其他相关项，例如产品相关文件或模型。

项目管理过程组指对项目管理过程进行逻辑分组，以达成项目的特定目标。过程组不同于项目阶段。项目管理过程可分为以下五个项目管理过程组：

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

本指南采用流程图。项目管理过程通过具体的输入和输出相互联系，即一个过程的成果或结果可能成为另一个过程（不一定在同一过程组）的输入。请注意，过程组与项目阶段不同（见 1.2.4.2 节）。

项目经理需要确保项目管理方法紧扣商业文件的意图。表 1-5 列出了这些文件的定义。在整个项目生命周期中，这两种文件相互依赖并得到反复制定和维护。

表 1-5项目商业文件

项目发起人通常负责项目商业论证文件的制定和维护。项目经理负责提供建议和见解，使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致，并与组织的目的和目标保持一致。

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

图 1-8需求评估与关键业务/项目文件的相互关系

项目效益管理计划描述了项目实现效益的方式和时间，以及应制定的效益衡量机制。项目效益指为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果。项目生命周期早期应确定目标效益，并据此制定效益管理计划。它描述了效益的关键要素，可能包括（但不限于）记录以下内容：

目标效益（例如预计通过项目实施可以创造的有形价值和无形价值；财务价值体现为净现值）；
战略一致性（例如项目效益与组织业务战略的一致程度）；
实现效益的时限（例如阶段效益、短期效益、长期效益和持续效益）；
效益责任人（例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人）；
测量指标（例如用于显示已实现效益的直接测量值和间接测量值）；
假设（例如预计存在或显而易见的因素）；
风险（例如实现效益的风险）。

制定效益管理计划需要使用商业论证和需求评估中的数据和信息，例如，成本效益分析数据。

在成本效益分析中已经把成本估算与项目拟实现的效益进行了比较。效益管理计划和项目管理计划描述了项目创造的商业价值如何能够成为组织持续运营的一部分，包括使用的测量指标。测量指标可核实商业价值并确认项目成功与否。

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

项目章程是由项目发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。

项目管理计划是描述如何执行、监督和控制项目的一份文件。

关于项目章程和项目管理计划的更多信息，请参见第 4 章项目整合管理。

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

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

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

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

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

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

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

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

项目经理可以致力于提高自己在组织内的总体项目管理能力和技能，并参与隐性和显性知识的转移或整合计划（见 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-4 描述本过程的输入、工具与技术和输出。

图 4-5 是本过程的数据流向图。

图 4-4制定项目管理计划：输入、工具与技术和输出

图 4-5制定项目管理计划：数据流向图

• Projectcharter项目管理计划确定项目的执行、监控和收尾方式，其内容会因项目所在的应用领域和复杂程度而异。

项目管理计划可以是概括或详细的，而每个组成部分的详细程度取决于具体项目的要求。项目管理计划应足够强大，可以应对不断变化的项目环境。这种敏捷性有利于随项目进展产出更准确的信息。

项目管理计划应基准化，即，至少应规定项目的范围、时间和成本方面的基准，以便据此考核项目执行情况和管理项目绩效。在确定基准之前，可能要对项目管理计划进行多次更新，且这些更新无需遵循正式流程。但是，一旦确定了基准，就只能通过实施整体变更控制过程进行更新。在这种情况下，如果需要进行变更，应提出变更请求以待决定。这一过程将形成一份项目管理计划。在项目收尾之前，该计划需要通过不断更新来渐进明细，并且这些更新需要得到控制和批准。

对隶属于项目集或项目组合的项目，则应该制定与项目集或项目组合管理计划相一致的项目管理计划。例如，项目集管理计划中要求超过某一特定成本的所有变更都需要上报变更控制委员会（CCB）审查，在项目管理计划中就应该对审查流程和成本临界值做出相应规定。

见 4.1.3.1 节。项目团队把项目章程作为初始项目规划的起始点。项目章程所包含的信息种类数量因项目的复杂程度和已知的信息而异。在项目章程中至少应该定义项目的高层级信息，供将来在项目管理计划的各个组成部分中进一步细化。

创建项目管理计划需要整合诸多过程（如第 5 章至第 13 章所述）的输出。其他规划过程所输出的子计划和基准都是本过程的输入。此外，对这些子计划和基准的变更都可能导致对项目管理计划的相应更新。

能够影响制定项目管理计划过程的事业环境因素包括（但不限于）：

政府或行业标准（如产品标准、质量标准、安全标准和工艺标准）；
法律法规要求和（或）制约因素；
垂直市场（如建筑）和（或）专门领域（如环境、安全、风险或敏捷软件开发）的项目管理知识体系；
组织的结构、文化、管理实践和可持续性；
组织治理框架（通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标）；
基础设施（如现有的设施和固定资产）。

能够影响制定项目管理计划过程的组织过程资产包括（但不限于）：

组织的标准政策、流程和程序；
项目管理计划模板，包括：
根据项目的特定要求而裁剪组织的标准流程的指南和标准；
项目收尾指南或要求，如产品确认及验收标准。
变更控制程序，包括修改正式的组织标准、政策、计划、程序或项目文件，以及批准和确认变更所须遵循的步骤；
监督和报告方法、风险控制程序，以及沟通要求；
以往类似项目的相关信息（如范围、成本、进度与绩效测量基准、项目日历、项目进度网络图和风险登记册）；
历史信息和经验教训知识库。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

根据项目需要裁剪项目管理过程，包括这些过程间的依赖关系和相互影响，以及这些过程的主要输入和输出；
根据需要制定项目管理计划的附加组成部分；
确定这些过程所需的工具与技术；
编制应包括在项目管理计划中的技术与管理细节；
确定项目所需的资源与技能水平；
定义项目的配置管理级别；
确定哪些项目文件受制于正式的变更控制过程；
确定项目工作的优先级，确保把项目资源在合适的时间分配到合适的工作。

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

头脑风暴。见 4.1.2.2 节。制定项目管理计划时，经常以头脑风暴的形式来收集关于项目方法的创意和解决方案。参会者包括项目团队成员，其他主题专家 (SME) 或相关方也可以参与。
核对单。见 11.2.2.2 节。很多组织基于自身经验制定了标准化的核对单，或者采用所在行业的核对单。核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
焦点小组。见 5.2.2.2 节。焦点小组召集相关方讨论项目管理方法以及项目管理计划各个组成部分的整合方式。
访谈。见 5.2.2.2 节。访谈用于从相关方获取特定信息，用以制定项目管理计划、任何子计划或项目文件。

制定项目管理计划时需要的人际关系与团队技能包括：

冲突管理。见 9.5.2.1 节。必要时可以通过冲突管理让具有差异性的相关方就项目管理计划的所有方面达成共识。
引导。见 4.1.2.3 节。引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果。
会议管理。见 10.2.2.6 节。有必要采用会议管理来确保有效召开多次会议，以便制定、统一和商定项目管理计划。

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

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

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

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

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

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

见 4.6.3.1 节。批准的变更请求是实施整体变更控制过程的输出，包括经项目经理审查和批准的变更请求，必要时可经变更控制委员会 (CCB) 审查和批准。批准的变更请求可能是纠正措施、预防措施或缺陷补救，并由项目团队纳入项目进度计划付诸实施，可能对项目或项目管理计划的任一领域产生影响，还可能导致修改正式受控的项目管理计划组件或项目文件。

可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是项目结果，并可包括项目管理计划的组成部分。

一旦完成了可交付成果的第一个版本，就应该执行变更控制。用配置管理工具和程序来支持对可交付成果（如文件、软件和构件）的多个版本的控制。

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

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

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新。

可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是为实现项目目标而完成的有形的组成部分，并可包括项目管理计划的组成部分。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中更新。

监控项目工作是跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。本过程的主要作用是，让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态。本过程需要在整个项目期间开展。

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

图 4-10监控项目工作：输入、工具与技术和输出

• Projectcharter图 4-11监控项目工作：数据流向图

监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进。持续的监督使项目管理团队能洞察项目的健康状况，并识别须特别关注的任何方面。控制包括制定纠正或预防措施或重新规划，并跟踪行动计划的实施过程，以确保它们能有效解决问题。监控项目工作过程关注：

把项目的实际绩效与项目管理计划进行比较；
定期评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施；
检查单个项目风险的状态；
在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况；
为状态报告、进展测量和预测提供信息；
做出预测，以更新当前的成本与进度信息；
监督已批准变更的实施情况；
如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态；
确保项目与商业需求保持一致。

在工作执行过程中收集工作绩效数据，再交由控制过程做进一步分析。将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。通过这种比较可以了解项目的执行情况。

在项目开始时，就在项目管理计划中规定关于范围、进度、预算和质量的具体工作绩效测量指标。项目期间通过控制过程收集绩效数据，与计划和其他变量比较，为工作绩效提供背景。

例如，关于成本的工作绩效数据可能包含已支出的资金，但必须与预算、已执行的工作、用于完成工作的资源以及资金使用计划比较之后才能有用。这些附加信息为确定项目是否符合预算或是否存在偏差提供了相应的情境；还有助于了解偏差的严重程度。通过与项目管理计划中的偏差临界值进行比较，就可以确定是否需要采取预防或纠正措施。对工作绩效数据和附加信息进行综合分析，可以为项目决策提供可靠的基础。

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

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

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。在监控项目工作过程中提出的变更可能会影响整体项目管理计划。

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

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

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

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

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

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

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

项目管理计划的任一正式受控的组成部分，都可通过本过程进行变更。对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性和完整性。

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

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

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

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

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

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

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

项目文件。在项目活动中产生的各种文件，例如项目管理计划，范围文件、成本文件、进度文件和项目日历，以及变更管理文件。
运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件，或对已有文件的更新。
项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件，以及用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。在项目收尾期间，项目经理应该回顾以往的阶段文件，确认范围过程（见 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]。

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

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

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

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

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

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

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 5-2 描述本过程的输入、工具与技术和输出。图 5-3 是本过程的数据流向图。

图 5-2规划范围管理：输入、工具与技术和输出

图 5-3规划范围管理：数据流向图

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析：项目章程（见 4.1.3.1 节）中的信息、项目管理计划（见 4.2.3.1 节）中已批准的子计划、组织过程资产（见 2.3 节）中的历史信息和相关事业环境因素（见 2.2 节）。

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

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

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

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。根据《从业者商业分析：实践指南》[7]，有些组织称之为“商业分析计划”。需求管理计划的主要内容包括（但不限于）：

如何规划、跟踪和报告各种需求活动；
配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
需求优先级排序过程；
测量指标及使用这些指标的理由；
反映哪些需求属性将被列入跟踪矩阵的跟踪结构。

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

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

见 4.3.3.4 节。分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程（见 4.6 节）的审查和处理。

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

范围管理计划。见 5.1.3.1 节。可以更新范围管理计划，以反映范围管理方式的变更。
范围基准。见 5.4.3.1 节。在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后，需要对范围基准做出相应的变更。有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据。
进度基准。见 6.5.3.1 节。在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据。
成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
绩效测量基准。见 4.2.3.1 节。在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

进度管理计划是项目管理计划的组成部分，为编制、监督和控制项目进度建立准则和明确活动。

根据项目需要，进度管理计划可以是正式或非正式的，非常详细或高度概括的，其中应包括合适的控制临界值。

进度管理计划会规定：

项目进度模型制定。需要规定用于制定项目进度模型的进度规划方法论和工具。
进度计划的发布和迭代长度。使用适应型生命周期时，应指定固定时间的发布时段、阶段和迭代。固定时间段指项目团队稳定地朝着目标前进的持续时间，它可以推动团队先处理基本功能，然后在时间允许的情况下再处理其他功能，从而尽可能减少范围蔓延。
准确度。准确度定义了需要规定活动持续时间估算的可接受区间，以及允许的应急储备数量。
计量单位。需要规定每种资源的计量单位，例如，用于测量时间的人时数、人天数或周数，用于计量数量的米、升、吨、千米或立方码。
组织程序链接。工作分解结构（WBS，见 5.4 节）为进度管理计划提供了框架，保证了与估算及相应进度计划的协调性。
项目进度模型维护。需要规定在项目执行期间，将如何在进度模型中更新项目状态，记录项目进展。
控制临界值。可能需要规定偏差临界值，用于监督进度绩效。它是在需要采取某种措施前，允许出现的最大差异。临界值通常用偏离基准计划中的参数的某个百分数来表示。
绩效测量规则。需要规定用于绩效测量的挣值管理（EVM）规则或其他测量规则。例如，进度管理计划可能规定：
确定完成百分比的规则；
EVM 技术，如基准法、固定公式法、完成百分比法等。更多信息，参阅《挣值管理实践标准》[17]；
进度绩效测量指标，如进度偏差（SV）和进度绩效指数（SPI），用来评价偏离原始进度基准的程度。
报告格式。需要规定各种进度报告的格式和编制频率。

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

进度基准。见 6.5.3.1 节。在整个项目期间，工作包逐渐细化为活动。在这个过程中可能会发现原本不属于项目基准的工作，从而需要修改作为进度基准一部分的交付日期或其他重要的进度里程碑。
成本基准。见 7.3.3.1 节。在针对进度活动的变更获得批准后，需要对成本基准做出相应的变更。

进度基准是经过批准的进度模型，只有通过正式的变更控制程序才能进行变更，用作与实际结果进行比较的依据。经相关方接受和批准，进度基准包含基准开始日期和基准结束日期。在监控过程中，将用实际开始和完成日期与批准的基准日期进行比较，以确定是否存在偏差。进度基准是项目管理计划的组成部分。

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

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

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

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

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

见 4.3.3.4 节。修改项目范围或项目进度计划之后，可能会对范围基准和/或项目管理计划的其他组成部分提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

预防措施可包括推荐的变更，以消除或降低不利进度偏差的发生概率。

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

进度管理计划。见 6.1.3.1 节。可能需要更新进度管理计划，以反映制定和管理进度计划的方式的变更。
成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。

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

挣值分析。见 7.4.2.2 节。进度绩效测量指标（如进度偏差（SV）和进度绩效指数（SPI））用于评价偏离初始进度基准的程度。
迭代燃尽图。这类图用于追踪迭代未完项中尚待完成的工作。它基于迭代规划（见 6.4.2.8 节）中确定的工作，分析与理想燃尽图的偏差。可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。在燃尽图中，先用对角线表示理想的燃尽情况，再每天画出实际剩余工作，最后基于剩余工作计算出趋势线以预测完成情况。图 6-24 是迭代燃尽图的一个例子。

图 6-24迭代燃尽图

绩效审查。绩效审查是指根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比，以及当前工作的剩余持续时间。
趋势分析。见 4.5.2.2 节。趋势分析检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化。图形分析技术有助于理解截至目前的绩效，并与未来的绩效目标（表示为完工日期）进行对比。
偏差分析。偏差分析关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，以及浮动时间的偏差。它包括确定偏离进度基准（见 6.5.3.1 节）的原因与程度，评估这些偏差对未来工作的影响，以及确定是否需要采取纠正或预防措施。例如，非关键路径上的某个活动发生较长时间的延误，可能不会对整体项目进度产生影响；而某个关键或次关键活动的稍许延误，却可能需要立即采取行动。
假设情景分析。见 6.5.2.4 节。假设情景分析基于项目风险管理过程的输出，对各种不同的情景进行评估，促使进度模型符合项目管理计划和批准的基准。

见 4.3.3.4 节。通过分析进度偏差，审查进展报告、绩效测量结果和项目范围或进度调整情况，可能会对进度基准、范围基准和/或项目管理计划的其他组成部分提出变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。预防措施可包括推荐的变更，以消除或降低不利进度偏差的发生概率。

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

进度管理计划。见 6.1.3.1 节。可能需要更新进度管理计划，以反映进度管理方法的变更。
进度基准。见 6.5.3.1 节。在项目范围、活动资源或活动持续时间估算等方面的变更获得批准后，可能需要对进度基准做相应变更。另外，因进度压缩技术或绩效问题造成变更时，也可能需要更新进度基准。
成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。
绩效测量基准。见 4.2.3.1 节。在范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

规划成本管理是确定如何估算、预算、管理、监督和控制项目成本的过程。本过程的主要作用是，在整个项目期间为如何管理项目成本提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 7-2 描述本过程的输入、工具与技术和输出，图 7-3 是本过程的数据流向图。

图 7-2规划成本管理：输入、工具与技术和输出

图 7-3规划成本管理：数据流向图

应该在项目规划阶段的早期就对成本管理工作进行规划，建立各成本管理过程的基本框架，以确保各过程的有效性及各过程之间的协调性。成本管理计划是项目管理计划的组成部分，其过程及工具与技术应记录在成本管理计划中。

成本管理计划是项目管理计划的组成部分，描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。

例如，在成本管理计划中规定：

计量单位。需要规定每种资源的计量单位，例如用于测量时间的人时数、人天数或周数，用于计量数量的米、升、吨、千米或立方码，或者用货币表示的总价。
精确度。根据活动范围和项目规模，设定成本估算向上或向下取整的程度（例如 995.59 美元取整为 1,000 美元）。
准确度。为活动成本估算规定一个可接受的区间（如 ±10%），其中可能包括一定数量的应急储备。
组织程序链接。工作分解结构（见 5.4 节）为成本管理计划提供了框架，以便据此规范地开展成本估算、预算和控制。在项目成本核算中使用的 WBS 组成部分，称为控制账户（CA），每个控制账户都有唯一的编码或账号，直接与执行组织的会计制度相联系。
控制临界值。可能需要规定偏差临界值，用于监督成本绩效。它是在需要采取某种措施前，允许出现的最大差异，通常用偏离基准计划的百分数来表示。
绩效测量规则。需要规定用于绩效测量的挣值管理（EVM）规则。例如，成本管理计划应该：
定义 WBS 中用于绩效测量的控制账户；
确定拟用的 EVM 技术（如加权里程碑法、固定公式法、完成百分比法等）；
规定跟踪方法，以及用于计算项目完工估算（EAC）的 EVM 公式，该公式计算出的结果可用于验证通过自下而上方法得出的完工估算。
报告格式。需要规定各种成本报告的格式和编制频率。
其他细节。关于成本管理活动的其他细节包括（但不限于）：
对战略筹资方案的说明；
处理汇率波动的程序；
记录项目成本的程序。

关于挣值管理的更多信息，参见《挣值管理实践标准》（第 2 版）[17]。

见 4.3.3.4 节。分析项目绩效后，可能会就成本基准和进度基准，或项目管理计划的其他组成部分提出变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

成本管理计划。见 7.1.3.1 节。成本管理计划中需要更新的内容包括：用于管理项目成本的控制临界值或所要求的准确度。要根据相关方的反馈意见，对它们进行更新。
成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。在某些情况下，成本偏差可能太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
绩效测量基准。见 4.2.3.1 节。在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。在某些情况下，绩效偏差可能太过严重，以至于需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

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

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

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

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

风险管理计划。见 11.1.3.1 节。在确定质量管理方法时可能需要更改已商定的项目风险管理方法，这些变更会记录在风险管理计划中。
范围基准。见 5.4.3.1 节。如果需要增加特定的质量管理活动，范围基准可能因本过程而变更。

WBS 词典记录的质量要求可能需要更新。

见 4.3.3.4 节。如果管理质量过程期间出现了可能影响项目管理计划任何组成部分、项目文件或项目/产品管理过程的变更，项目经理应提交变更请求并遵循 4.6 节定义的实施整体变更控制过程。

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

质量管理计划。见 8.1.3.1 节。可能需要根据实际结果修改已商定的质量管理方法。
范围基准。见 5.4.3.1 节。范围基准可能因特定的质量管理活动而变更。
进度基准。见 6.5.3.1 节。进度基准可能因特定的质量管理活动而变更。
成本基准。见 7.3.3.1 节。成本基准可能因特定的质量管理活动而变更。

见 4.3.3.4 节。如果控制质量过程期间出现了可能影响项目管理计划任何组成部分或项目文件的变更，项目经理应提交变更请求，且应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

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

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

获取资源是获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。本过程的主要作用是，概述和指导资源的选择，并将其分配给相应的活动。本过程应根据需要在整个项目期间定期开展。图 9-8 描述本过程的输入、工具与技术和输出。图 9-9 是本过程的数据流向图。

图 9-8获取资源：输入、工具与技术和输出

• Projectcharter图 9-9获取资源：数据流向图

项目所需资源可能来自项目执行组织的内部或外部。内部资源由职能经理或资源经理负责获取（分配），外部资源则是通过采购过程获得。

因为集体劳资协议、分包商人员使用、矩阵型项目环境、内外部报告关系或其他原因，项目管理团队可能或可能不对资源选择有直接控制权。重要的是，在获取项目资源过程中应注意下列事项：

项目经理或项目团队应该进行有效谈判，并影响那些能为项目提供所需团队和实物资源的人员。
不能获得项目所需的资源时，可能会影响项目进度、预算、客户满意度、质量和风险；资源或人员能力不足会降低项目成功的概率，最坏的情况可能导致项目取消。
如因制约因素（如经济因素或其他项目对资源的占用）而无法获得所需团队资源，项目经理或项目团队可能不得不使用也许能力和成本不同的替代资源。在不违反法律、规章、强制性规定或其他具体标准的前提下可以使用替代资源。

在项目规划阶段，应该对上述因素加以考虑并做出适当安排。项目经理或项目管理团队应该在项目进度计划、项目预算、项目风险计划、项目质量计划、培训计划及其他相关项目管理计划中，说明缺少所需资源的后果。

项目团队派工单记录了团队成员及其在项目中的角色和职责，可包括项目团队名录，还需要把人员姓名插入项目管理计划的其他部分，如项目组织图和进度计划。

见 4.3.3.4 节。如果获取资源过程中出现变更请求（例如影响了进度），或者推荐措施、纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求，且应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。

开展本过程可能导致项目管理计划更新的内容包括（但不限于）：

资源管理计划。见 9.1.3.1 节。更新资源管理计划，以反映获取项目资源的实际经验，包括在项目早期获取资源的经验教训，这些经验会影响项目后期的资源获取过程。
成本基准。见 7.3.3.1 节。在项目资源采购期间，成本基准可能发生变更。

见 4.3.3.4 节。如果建设团队过程中出现变更请求，或者推荐的纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求并遵循 4.6 节定义的实施整体变更控制过程。

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

见 4.3.3.4 节。如果管理团队过程中出现变更请求，或者推荐措施、纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

例如，人员配备变更，无论是自主选择还是由不可控事件造成，都会干扰项目团队，这种干扰可能导致进度落后或预算超支。人员配备变更包括转派人员、外包部分工作，或替换离职人员。

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

资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目团队管理经验更新。
进度基准。见 6.5.3.1 节。可能需要更改项目进度，以反映团队的执行方式。
成本基准。见 7.3.3.1 节。可能需要更改项目成本基准，以反映团队的执行方式。

见 4.3.3.4 节。如果控制资源过程出现变更请求，或者推荐的纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程（见 4.6节）对变更请求进行审查和处理。

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

资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目资源管理经验更新。
进度基准。见 6.5.3.1 节。可能需要更新项目进度，以反映管理项目资源的方式。
成本基准。见 7.3.3.1 节。可能需要更新项目成本基准，以反映管理项目资源的方式。

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是，为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 10-2 描述本过程的输入、工具与技巧和输出。图 10-3 是本过程的数据流向图。

图 10-2规划沟通管理：输入、工具与技术和输出

• Projectcharter图 10-3规划沟通管理：数据流向图

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

在大多数项目中，都需要很早就开展沟通规划工作，例如在识别相关方及制定项目管理计划期间。

虽然所有项目都需要进行信息沟通，但是各项目的信息需求和信息发布方式可能差别很大。此外，在本过程中，需要考虑并合理记录用来存储、检索和最终处置项目信息的方法。应该在整个项目期间，定期审查规划沟通管理过程的成果并做必要修改，以确保其持续适用。

沟通管理计划是项目管理计划的组成部分，描述将如何规划，结构化、执行与监督项目沟通，以提高沟通的有效性。该计划包括如下信息：

相关方的沟通需求；
需沟通的信息，包括语言、形式、内容和详细程度；
上报步骤；
发布信息的原因；
发布所需信息、确认已收到，或作出回应（若适用）的时限和频率；
负责沟通相关信息的人员；
负责授权保密信息发布的人员；
接收信息的人员或群体，包括他们的需要、需求和期望；
用于传递信息的方法或技术，如备忘录、电子邮件、新闻稿，或社交媒体；
为沟通活动分配的资源，包括时间和预算；
随着项目进展，如项目不同阶段相关方社区的变化，而更新与优化沟通管理计划的方法；
通用术语表；
项目信息流向图、工作流程（可能包含审批程序）、报告清单和会议计划等；
来自法律法规、技术、组织政策等的制约因素。

沟通管理计划中还包括关于项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模板。如果项目要使用项目网站和项目管理软件，那就要把它们写进沟通管理计划。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括（但不限于）相关方参与计划（见 13.2.3.1 节）。需要更新相关方参与计划，反映会影响相关方参与项目决策和执行的任何过程、程序、工具或技术。

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

沟通管理计划。见 10.1.3.1 节。如果本过程导致了项目沟通方法发生变更，就要把这种变更反映在项目沟通计划中。
相关方参与计划。见 13.2.3.1 节。本过程将导致相关方的沟通需求以及商定的沟通策略需要更新。

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

沟通管理计划。见 10.1.3.1 节。需要更新沟通管理计划，记录能够让沟通更有效的新信息。
相关方参与计划。见 13.2.3.1 节。需要更新相关方参与计划，反映相关方的实际情况、沟通需求和重要性。

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

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

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

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

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

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

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

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

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

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

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

根本原因分析。根本原因分析（见 8.2.2.2 节）常用于发现导致问题的深层原因并制定预防措施。可以用问题陈述（如项目可能延误或超支）作为出发点，来探讨哪些威胁可能导致该问题，从而识别出相应的威胁。也可以用收益陈述（如提前交付或低于预算）作为出发点，来探讨哪些机会可能有利于实现该效益，从而识别出相应的机会。
假设条件和制约因素分析。每个项目及其项目管理计划的构思和开发都基于一系列的假设条件，并受一系列制约因素的限制。这些假设条件和制约因素往往都已纳入范围基准和项目估算。开展假设条件和制约因素分析，来探索假设条件和制约因素的有效性，确定其中哪些会引发项目风险。从假设条件的不准确、不稳定、不一致或不完整，可以识别出威胁，通过清除或放松会影响项目或过程执行的制约因素，可以创造出机会。
SWOT 分析。这是对项目的优势、劣势、机会和威胁 (SWOT) 进行逐个检查。在识别风险时，它会将内部产生的风险包含在内，从而拓宽识别风险的范围。首先，关注项目、组织或一般业务领域，识别出组织的优势和劣势；然后，找出组织优势可能为项目带来的机会，组织劣势可能造成的威胁。还可以分析组织优势能在多大程度上克服威胁，组织劣势是否会妨碍机会的产生。
文件分析。见 5.2.2.3 节。通过对项目文件的结构化审查，可以识别出一些风险。可供审查的文件包括（但不限于）计划、假设条件、制约因素、以往项目档案、合同、协议和技术文件。

项目文件中的不确定性或模糊性，以及同一文件内部或不同文件之间的不一致，都可能是项目风险的指示信号。

规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法；本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。本过程需要在整个项目期间开展。图 11-16 描述本过程的输入、工具与技术和输出。图 11-17 是本过程的数据流向图。

图 11-16规划风险应对：输入、工具与技术和输出

图 11-17规划风险应对：数据流向图

有效和适当的风险应对可以最小化单个威胁，最大化单个机会，并降低整体项目风险敞口；不恰当的风险应对则会适得其反。一旦完成对风险的识别、分析和排序，指定的风险责任人就应该编制计划，以应对项目团队认为足够重要的每项单个项目风险。这些风险会对项目目标的实现造成威胁或提供机会。项目经理也应该思考如何针对整体项目风险的当前级别做出适当的应对。

风险应对方案应该与风险的重要性相匹配、能经济有效地应对挑战、在当前项目背景下现实可行、能获得全体相关方的同意，并由一名责任人具体负责。往往需要从几套可选方案中选出最优的风险应对方案。应该为每个风险选择最可能有效的策略或策略组合。可用结构化的决策技术来选择最适当的应对策略。对于大型或复杂项目，可能需要以数学优化模型或实际方案分析为基础，进行更加稳健的备选风险应对策略经济分析。

要为实施商定的风险应对策略，包括主要策略和备用策略（若必要），制定具体的应对行动。

如果选定的策略并不完全有效，或者发生了已接受的风险，就需要制定应急计划（或弹回计划）。

同时，也需要识别次生风险。次生风险是实施风险应对措施而直接导致的风险。往往需要为风险分配时间或成本应急储备，并可能需要说明动用应急储备的条件。

针对威胁，可以考虑下列五种备选策略：

上报。如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采用上报策略。被上报的风险将在项目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。项目经理确定应就威胁通知哪些人员，并向该人员或组织部门传达关于该威胁的详细信息。对于被上报的威胁，组织中的相关人员必须愿意承担应对责任，这一点非常重要。威胁通常要上报给其目标会受该威胁影响的那个层级。威胁一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记册中供参考。
规避。风险规避是指项目团队采取行动来消除威胁，或保护项目免受威胁的影响。它可能适用于发生概率较高，且具有严重负面影响的高优先级威胁。规避策略可能涉及变更项目管理计划的某些方面，或改变会受负面影响的目标，以便于彻底消除威胁，将它的发生概率降低到零。

风险责任人也可以采取措施，来分离项目目标与风险万一发生的影响。规避措施可能包括消除威胁的原因、延长进度计划、改变项目策略，或缩小范围。有些风险可以通过澄清需求、获取信息、改善沟通或取得专有技能来加以规避。

转移。转移涉及到将应对威胁的责任转移给第三方，让第三方管理风险并承担威胁发生的影响。采用转移策略，通常需要向承担威胁的一方支付风险转移费用。风险转移可能需要通过一系列行动才得以实现，包括（但不限于）购买保险、使用履约保函、使用担保书、使用保证书等。也可以通过签订协议，把具体风险的归属和责任转移给第三方。
减轻。风险减轻是指采取措施来降低威胁发生的概率和（或）影响。提前采取减轻措施通常比威胁出现后尝试进行弥补更加有效。减轻措施包括采用较简单的流程，进行更多次测试，或者选用更可靠的卖方。还可能涉及原型开发（见 5.2.2.8 节），以降低从实验台模型放大到实际工艺或产品中的风险。如果无法降低概率，也许可以从决定风险严重性的因素入手，来减轻风险发生的影响。例如，在一个系统中加入冗余部件，可以减轻原始部件故障所造成的影响。
接受。风险接受是指承认威胁的存在，但不主动采取措施。此策略可用于低优先级威胁，也可用于无法以任何其他方式加以经济有效地应对的威胁。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包括预留时间、资金或资源以应对出现的威胁；被动接受策略则不会主动采取行动，而只是定期对威胁进行审查，确保其并未发生重大改变。

见 4.3.3.4 节。规划风险应对后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

进度管理计划。见 6.1.3.1 节。对进度管理计划的变更包括：资源负荷和资源平衡变更，或进度策略更新等。
成本管理计划。见 7.1.3.1 节。对成本管理计划的变更包括：成本会计、跟踪和报告变更，以及预算策略和应急储备使用方法更新等。
质量管理计划。见 8.1.3.1 节。对质量管理计划的变更包括：满足需求的方法、质量管理方法，或质量控制过程的变更等。
资源管理计划。见 9.1.3.1 节。对资源管理计划的变更包括：资源配置变更，以及资源策略更新等。
采购管理计划。见 12.1.3.1 节。对采购管理计划的变更包括：自制或外购决策或合同类型的更改等。
范围基准。见 5.4.3.1 节。如果商定的风险应对策略导致了范围变更，且这种变更已经获得批准，那么就要对范围基准做出相应的变更。
进度基准。见 6.5.3.1 节。如果商定的风险应对策略导致了进度估算变更，且这种变更已经获得批准，那么就要对进度基准做出相应的变更。
成本基准。见 7.3.3.1 节。如果商定的风险应对策略导致了成本估算变更，且这种变更已经获得批准，那么就要对成本基准做出相应的变更。

见 4.3.3.4 节。实施风险应对后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

见 4.3.3.4 节。执行监督风险过程后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

变更请求可能包括：建议的纠正与预防措施，以处理当前整体项目风险级别或单个项目风险。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任何组件都可能受本过程的影响。

见 4.3.3.4 节。关于采购货物、服务或资源的决策，可能导致变更请求；规划采购期间的其他决策，也可能导致变更请求。对项目管理计划及其子计划和其他组件的修改都可能导致会影响采购行为的变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

见 4.3.3.4 节。通过实施整体变更控制过程（见 4.6 节），来审查和处理对项目管理计划及其子计划和其他组件的变更请求。

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

需求管理计划。见 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 节。在项目交付期间，承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

见 4.3.3.4 节。在控制采购过程中，可能提出对项目管理计划及其子计划和其他组件的变更请求，例如，成本基准、进度基准和采购管理计划。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

已提出而未解决的变更，可能包括买方发布的指示或卖方采取的行动，而对方认为该指示或行动已构成对合同的推定变更。因为双方可能对推定变更存在争议，并可能引起一方向另一方索赔，所以通常应该在项目往来函件中对推定变更进行专门识别和记录。

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

风险管理计划。见 11.1.3.1 节。每个协议和卖方都会带来独特的风险，因此可能需要更新风险管理计划。如果在执行合同期间发生重大的意外风险，则风险管理计划可能需要更新。应该把具体的风险记录到风险登记册中。
采购管理计划。见 12.1.3.1 节。采购管理计划包含在采购过程中需要开展的活动。可能需要基于卖方执行工作的绩效情况，对采购管理计划进行更新。
进度基准。见 6.5.3.1 节。如果卖方的重大进度变更影响到了项目的整体进度绩效，则可能需要更新并审批基准进度计划，以反映当前的期望。买方应该注意某个卖方的进度拖延，可能对其他卖方的工作造成连锁影响。
成本基准。见 7.3.3.1 节。在项目交付期间，承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是，使项目团队能够建立对每个相关方或相关方群体的适度关注。本过程应根据需要在整个项目期间定期开展。图 13-2 描述本过程的输入、工具与技术和输出。图 13-3 是本过程的数据流向图。

图 13-2识别相关方：输入、工具与技术和输出

图 13-3识别相关方：数据流向图

本过程通常在编制和批准项目章程之前或同时首次开展。本过程需在必要时重复开展，至少应在每个阶段开始时，以及项目或组织出现重大变化时重复开展。每次重复开展本过程，都应通过查阅项目管理计划组件及项目文件，来识别有关的项目相关方。

• Projectcharter

见 4.3.3.4 节。首次开展识别相关方过程，不会提出任何变更请求。但随着在后续项目期间继续识别相关方，新出现的相关方或关于现有相关方的新信息可能导致对产品、项目管理计划或项目文件提出变更请求。

应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

在项目初始时识别相关方，不会导致项目管理计划更新。但随着项目进展，项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.1.2 节。新识别的相关方可能会影响规划、跟踪和报告需求活动的方式。
沟通管理计划。见 10.1.3.1 节。沟通管理计划记录相关方的沟通要求和已商定的沟通策略。
风险管理计划。见 11.1.3.1 节。如果相关方的沟通要求和已商定的沟通策略会影响管理项目风险的方法，就应在风险管理计划中加以反映。
相关方参与计划。见 13.2.3.1 节。相关方参与计划记录针对已识别相关方的商定的沟通策略。

相关方参与计划是项目管理计划的组成部分。它确定用于促进相关方有效参与决策和执行的策略和行动。基于项目的需要和相关方的期望，相关方参与计划可以是正式或非正式的，非常详细或高度概括的。

相关方参与计划可包括（但不限于）调动个人或相关方参与的特定策略或方法。

D C

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

沟通管理计划。见 10.1.3.1 节。需要更新沟通管理计划，以反映新的或已变更的相关方需求。
相关方参与计划。见 13.2.3.1 节。需要更新相关方参与计划，以反映为有效引导相关方参与所需的新的或更改的管理策略。

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

资源管理计划。见 9.1.3.1 节。可能需要更新团队对引导相关方参与的职责。
沟通管理计划。见 10.1.3.1 节。可能需要更新项目的沟通策略。
相关方参与计划。见 13.2.3.1 节。可能需要更新关于项目相关方社区的信息。

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

项目的启动通常出于以下一项或多项战略考虑：

市场需求；
战略机会/业务需求；
社会需要；
环境考虑；
客户要求；
技术进步；
法律或法规要求；
现有问题或已预见到的问题。

效益管理计划描述项目效益的实现方法和时间及其衡量方式。效益管理计划可能包括以下内容：

目标效益。使用产品、服务或成果而预期获得的有形和无形商业价值。
战略一致性。项目效益如何支持组织的业务战略并与之保持一致。
实现效益的时限。效益按阶段划分，包括：短期效益、长期效益和持续性效益。
效益责任人。在效益实现计划规定的整个时限内，监督、记录和报告效益实现情况的责任个人或小组。
测量指标。用于考核效益实现情况的直接和间接方法。
风险。与实现目标效益有关的风险。

根据项目目标和成功标准考核项目的成功程度。在许多情况下，产品、服务或成果的成功只有在项目完成后一段时间方能知晓。例如，在项目产品、服务或成果交付运营时，市场份额增加、运营成本降低或新产品成功可能都是未知的。在这些情况下，项目管理办公室 (PMO)、项目组合指导委员会或组织内的其他职能部门，应该在稍晚时间才对项目成功进行评估，以确定结果是否符合业务目标。

商业论证和效益管理计划都是在项目启动之前编制的，并且要成为项目完成之后评估项目成功的依据。因此，它们被视为商业文件，而非项目文件，或者项目管理计划的组成部分。这些商业文件可能成为某些项目管理过程的输入，例如，制定项目章程。

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

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

虽然项目规模及复杂程度各不相同，但是典型项目都呈现下列项目生命周期结构（见图 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项目管理过程组与知识领域

在本标准中，术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件，用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪，因此，并非每个项目都需要每个过程、输入、工具、技术或输出。

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

子管理计划是与项目特定方面或知识领域相关的计划，如进度管理计划、风险管理计划和变更管理计划。进行裁剪时，需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入，而项目管理计划更新是本标准中许多过程的输出。在本标准中，不会在输入和输出表中直接列出单个项目管理计划组件，而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件（输入）或可能得到的项目管理计划组件更新（输出）。所列出的组件仅为示例而已。在开展每个特定过程时，项目经理既非必须、也非限于用到上述输入或得到上述输出。

项目管理计划是主要的项目工件之一。另外，还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似，过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件，以及将作为过程输出的项目文件更新。在本标准中，在输入和输出表下方的正文中列出的项目文件，仅为项目文件的可能示例，而非完整列表。

表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项

目文件，但的确列出了有助于管理项目的常用计划组件和项目文件。

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

商业文件通常是在项目之外创建的文件，用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件，将取决于公司文化和项目启动过程。

会影响项目的事业环境因素，以及可用于项目的组织过程资产，将因项目及其所处环境而异，所以并未在本标准中列出。

识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是，使项目团队能够建立对每个相关方或相关方群体的适度关注。本过程应根据需要在整个项目期间定期开展。图 2-4 描述了本过程的输入和输出。

图 2-4识别相关方：输入和输出

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

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

沟通管理计划；
相关方参与计划。

可在本过程更新的项目管理计划组件包括（但不限于）：

需求管理计划；
沟通管理计划；
风险管理计划；
相关方参与计划。

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

在规划项目、制定项目管理计划和项目文件时，项目管理团队应当征求适当相关方的意见，并鼓励相关方参与。初始规划工作完成时，经批准的项目管理计划就被视为基准。在整个项目期间，监控过程将把项目绩效与基准进行比较。

规划过程组（图 3-1）包括第 3.1 节至 3.24 节所列的项目管理过程。

图 3-1规划过程组

制定项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。本过程的主要作用是，生成一份综合文件，用于确定所有项目工作的基础及其执行方式。本过程仅开展一次或仅在项目的预定义点开展。图 3-2 描述了本过程的输入和输出。

图 3-2制定项目管理计划：输入和输出

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

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-3 描述了本过程的输入和输出。

图 3-3规划范围管理：输入和输出

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

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

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

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是，为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。图 3-4 描述了本过程的输入和输出。

图 3-4收集需求：输入和输出

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

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

范围管理计划；
需求管理计划；
相关方参与计划。

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。本过程仅开展一次或仅在项目的预定义点开展。图 3-5 描述了本过程的输入和输出。

图 3-5定义范围：输入和输出

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

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

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

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

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

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

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

本过程的主要作用是，为如何在整个项目期间管理项目进度提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-7 描述了本过程的输入和输出。

图 3-7规划进度管理：输入和输出

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

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

范围管理计划；
开发方法。

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

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

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

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

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

进度管理计划；
范围基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

进度基准；
成本基准。

排列活动顺序是识别和记录项目活动之间的关系的过程。本过程的主要作用是定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。本过程需要在整个项目期间开展。

图 3-9 描述了本过程的输入和输出。

图 3-9排列活动顺序：输入和输出

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

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

进度管理计划；
范围基准。

估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。本过程的主要作用是，确定完成每个活动所需花费的时间量。本过程需要在整个项目期间开展。图 3-10 描述了本过程的输入和输出。

图 3-10估算活动持续时间：输入和输出

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

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

进度管理计划；
范围基准。

制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。本过程的主要作用是，为完成项目活动而制定具有计划日期的进度模型。

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

图 3-11制定进度计划：输入和输出

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

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

进度管理计划；
范围基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

进度管理计划；
成本基准。

规划成本管理是确定如何估算、预算、管理、监督和控制项目成本的过程。本过程的主要作用是，在整个项目期间为如何管理项目成本提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-12 描述了本过程的输入和输出。

图 3-12规划成本管理：输入和输出

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

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

进度管理计划；
风险管理计划。

估算成本是对完成项目工作所需资金进行近似估算的过程。本过程的主要作用是，确定项目所需的资金。本过程应根据需要在整个项目期间定期开展。图 3-13 描述了本过程的输入和输出。

图 3-13估算成本：输入和输出

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

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

成本管理计划；
质量管理计划；
范围基准。

制定预算是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。本过程的主要作用是，确定可据以监督和控制项目绩效的成本基准。本过程仅开展一次或仅在项目的预定义点开展。图 3-14 描述了本过程的输入和输出。

图 3-14制定预算：输入和输出

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

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

成本管理计划；
资源管理计划；
范围基准。

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

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

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

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

需求管理计划；
风险管理计划；
相关方参与计划；
范围基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

风险管理计划；
范围基准。

规划资源管理是定义如何估算、获取、管理和利用实物以及团队资源的过程。本过程的主要作用是，根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度。本过程仅开展一次或仅在项目的预定义点开展。图 3-16 描述了本过程的输入和输出。

图 3-16规划资源管理：输入和输出

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

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

质量管理计划；
范围基准。

估算活动资源是估算执行项目所需的团队资源，以及材料、设备和用品的类型和数量的过程。

本过程的主要作用是，明确完成项目所需的资源种类、数量和特性。本过程应根据需要在整个项目期间定期开展。图 3-17 描述了本过程的输入和输出。

图 3-17估算活动资源：输入和输出

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

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

资源管理计划；
范围基准。

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是，为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 3-18 描述了本过程的输入和输出。

图 3-18规划沟通管理：输入和输出

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

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

资源管理计划；
相关方参与计划。

可在本过程更新的项目管理计划组件包括（但不限于）相关方参与计划。

规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是，确保风险管理的水平、方法和可见度与项目风险程度，以及项目对组织和其他相关方的重要程度相匹配。本过程仅开展一次或仅在项目的预定义点开展。图 3-19 描述了本过程的输入和输出。

图 3-19规划风险管理：输入和输出

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

在规划项目风险管理时，应考虑项目管理计划的所有可用组件，以确保风险管理符合具体项目的需求。

识别风险是识别单个项目风险，以及整体项目风险的来源，并记录风险特征的过程。本过程的主要作用是，记录现有的单个项目风险，以及整体项目风险的来源。本过程还汇集相关信息，以便项目团队能够恰当应对已识别风险。本过程需要在整个项目期间开展。图 3-20 描述了本过程的输入和输出。

图 3-20识别风险：输入和输出

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

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

需求管理计划；
进度管理计划；
成本管理计划；
质量管理计划；
资源管理计划；
风险管理计划；
范围基准；
进度基准；
成本基准。

实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先排序，从而为后续分析或行动提供基础的过程。本过程的主要作用是重点关注高优先级的风险。本过程需要在整个项目期间开展。图 3-21 描述了本过程的输入和输出。

图 3-21实施定性风险分析：输入和输出

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

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

实施定量风险分析是就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。本过程的主要作用是，量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划。本过程需要在整个项目期间开展。图 3-22 描述了本过程的输入和输出。

图 3-22实施定量风险分析：输入和输出

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

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

风险管理计划；
范围基准；
进度基准；
成本基准。

规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法。本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。本过程需要在整个项目期间开展。图 3-23 描述了本过程的输入和输出。

图 3-23规划风险应对：输入和输出

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

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

资源管理计划；
风险管理计划；
成本基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

进度管理计划；
成本管理计划；
质量管理计划；
资源管理计划；
采购管理计划；
范围基准；
进度基准；
成本基准。

规划采购管理是记录项目采购决策，明确采购方法，识别潜在卖方的过程。本过程的主要作用是，确定是否从项目外部获取货物和服务，如果是，则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购，或者从外部渠道采购。本过程仅开展一次或仅在项目的预定义点开展。图 3-24 描述了本过程的输入和输出。

图 3-24规划采购：输入和输出

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

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

范围管理计划；
质量管理计划；
资源管理计划；
范围基准。

规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程。本过程的主要作用是，提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。图 3-25 描述了本过程的输入和输出。

图 3-25规划相关方参与：输入和输出

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

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

资源管理计划；
沟通管理计划；
风险管理计划。

执行过程组包括完成项目管理计划中确定的工作，以满足项目要求的一组过程。本过程组需要按照项目管理计划来协调资源，管理相关方参与，以及整合并实施项目活动。本过程组的主要作用是，根据计划执行为满足项目要求、实现项目目标所需的项目工作。相当多的项目预算、资源和时间将用于开展执行过程组的过程。开展执行过程组的过程，可能导致变更请求。一旦变更请求获得批准，则可能触发一个或多个规划过程，来修改管理计划、完善项目文件，甚至建立新的基准。

执行过程组（图 4-1）包括第 4.1 节至 4.10 节所列的项目管理过程。

图 4-1执行过程组

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

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

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

项目管理计划的任何组件都可用作本过程的输入。

项目管理计划的任何组件都可在本过程更新。

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

本过程的主要作用是，利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。图 4-3 描述了本过程的输入和输出。

图 4-3管理项目知识：输入和输出

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

项目管理计划的所有组件都可用作本过程的输入。

项目管理计划的任何组件都可在本过程更新。

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

本过程的主要作用是，提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。

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

图 4-4管理质量：输入和输出

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

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

可在本过程更新的项目管理计划组件包括（但不限于）：

质量管理计划；
范围基准；
进度基准；
成本基准。

获取资源是获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。本过程的主要作用是，概述和指导资源的选择，并将其分配给相应的活动。本过程应根据需要在整个项目期间定期开展。图 4-5 描述了本过程的输入和输出。

图 4-5获取资源：输入和输出

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

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

资源管理计划；
采购管理计划；
成本基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

资源管理计划；
成本基准。

建设团队是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。本过程的主要作用是，改进团队协作、增强人际技能、激励员工、减少摩擦以及提升整体项目绩效。

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

图 4-6建设团队：输入和输出

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

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

可在本过程更新的项目管理计划组件包括（但不限于）资源管理计划。

管理团队是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。本过程的主要作用是，影响团队行为、管理冲突以及解决问题。本过程需要在整个项目期间开展。图 4-7 描述了本过程的输入和输出。

图 4-7管理团队：输入和输出

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

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

可在本过程更新的项目管理计划组件包括（但不限于）：

资源管理计划；
进度基准；
成本基准。

管理沟通是指确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。本过程的主要作用是，促成项目团队与相关方之间的有效信息流动。本过程需要在整个项目期间开展。图 4-8 描述了本过程的输入和输出。

图 4-8管理沟通：输入和输出

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

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

资源管理计划；
沟通管理计划；
相关方参与计划。

可在本过程更新的项目管理计划组件包括（但不限于）：

沟通管理计划；
相关方参与计划。

实施风险应对是执行商定的风险应对计划的过程。本过程的主要作用是，确保按计划执行商定的风险应对措施，来管理整体项目风险敞口，以及最小化单个项目威胁，最大化单个项目机会。本过程需要在整个项目期间开展。图 4-9 描述了本过程的输入和输出。

图 4-9实施风险应对：输入和输出

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

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

实施采购是获取卖方应答、选择卖方并授予合同的过程。本过程的主要作用是，选定合格卖方并签署关于货物或服务交付的法律协议。本过程应根据需要在整个项目期间定期开展。图 4-10 描述了本过程的输入和输出。

图 4-10实施采购：输入和输出

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

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

范围管理计划；
需求管理计划；
沟通管理计划；
风险管理计划；
采购管理计划；
配置管理计划；
成本基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

需求管理计划；
质量管理计划；
沟通管理计划；
风险管理计划；
采购管理计划；
范围基准；
进度基准；
成本基准。

管理相关方参与是与相关方进行沟通和协作，以满足其需求与期望，处理问题，并促进相关方合理参与项目活动的过程。本过程的主要作用是，让项目经理提升相关方的支持，降低相关方的抵制。本过程需要在整个项目期间开展。图 4-11 描述了本过程的输入和输出。

图 4-11管理相关方参与：输入和输出

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

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

沟通管理计划；
风险管理计划；
相关方参与计划；
变更管理计划。

可在本过程更新的项目管理计划组件包括（但不限于）：

沟通管理计划；
相关方参与计划。

监控过程组包括跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的一组过程。监督是收集项目绩效数据，计算绩效指标，并报告和发布绩效信息。控制是比较实际绩效与计划绩效，分析偏差，评估趋势以改进过程，评价可选方案，并建议必要的纠正措施。本过程组的主要作用是，按既定时间间隔、在特定事件发生时或在异常情况出现时，对项目绩效进行测量和分析，以识别和纠正与项目管理计划的偏差。监控过程组还涉及：

评价变更请求并制定恰当的响应行动；
建议纠正措施，或者对可能出现的问题建议预防措施；
对照项目管理计划和项目基准，监督正在进行中的项目活动；
影响可能导致规避变更控制过程的因素，确保只有经批准的变更才能付诸执行。

持续的监督使项目团队和其他相关方得以洞察项目的健康状况，并识别需要格外注意的方面。

在监控过程组，需要监督和控制在每个知识领域、每个过程组、每个生命周期阶段以及整个项目中正在进行的工作。监控过程组（图 5-1）包括 5.1 节至 5.12 节所列的项目管理过程。

图 5-1监控过程组

监控项目工作是跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。本过程的主要作用是，让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态。本过程需要在整个项目期间开展。图 5-2 描述了本过程的输入和输出。

图 5-2监控项目工作：输入和输出

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

项目管理计划的任何组件都可用作本过程的输入。

项目管理计划的任何组件都可在本过程更新。

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

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

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

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

变更管理计划；
配置管理计划；
范围基准；
进度基准；
成本基准。

项目管理计划的任何组件都可在本过程更新。

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

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

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

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

范围管理计划；
需求管理计划；
范围基准。

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护。本过程需要在整个项目期间开展。图 5-5 描述了本过程的输入和输出。

图 5-5控制范围：输入和输出

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

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

范围管理计划；
需求管理计划；
变更管理计划；
配置管理计划；
范围基准；
绩效测量基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

范围管理计划；
范围基准；
进度基准；
成本基准；
绩效测量基准。

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是，在整个项目期间保持对进度基准的维护。本过程需要在整个项目期间开展。图 5-6 描述了本过程的输入和输出。

图 5-6控制进度：输入和输出

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

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

进度管理计划；
进度基准；
范围基准；
绩效测量基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

进度管理计划；
进度基准；
成本基准；
绩效测量基准。

控制成本是监督项目状态，以更新项目成本和管理成本基准变更的过程。本过程的主要作用是，在整个项目期间保持对成本基准的维护。本过程需要在整个项目期间开展。图 5-7 描述了本过程的输入和输出。

图 5-7控制成本：输入和输出

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

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

成本管理计划；
成本基准；
绩效测量基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

成本管理计划；
成本基准；
绩效测量基准。

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

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

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

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

可在本过程更新的项目管理计划组件包括（但不限于）质量管理计划。

控制资源是确保被分配给项目的物质资源按计划就位，以及监督资源的计划和实际使用情况，并采取必要纠正措施的过程。本过程的主要作用是，确保所分配的资源适时适地可用于项目，且在不再需要时被释放。本过程需要在整个项目期间开展。图 5-9 描述了本过程的输入和输出。

图 5-9控制资源：输入和输出

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

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

可在本过程更新的项目管理计划组件包括（但不限于）：

资源管理计划；
进度基准；
成本基准。

监督沟通是确保满足项目及其相关方的信息需求的过程。本过程的主要作用是，按沟通管理计划和相关方参与计划的要求开展高效的信息传递。本过程需要在整个项目期间开展。图 5-10 描述了本过程的输入和输出。

图 5-10监督沟通：输入和输出

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

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

资源管理计划；
沟通管理计划；
相关方参与计划。

可在本过程更新的项目管理计划组件包括（但不限于）：

沟通管理计划；
相关方参与计划。

监督风险是在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。本过程的主要作用是，使项目决策都基于关于整体项目风险敞口和单个项目风险的当前信息。本过程需要在整个项目期间开展。图 5-11 描述了本过程的输入和输出。

图 5-11监督风险：输入和输出

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

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

项目管理计划的任何组件都可在本过程更新。

控制采购是管理采购关系，监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。本过程的主要作用是，确保买卖双方履行法律协议，满足项目需求。如果存在一系列采购活动，本过程就需要在整个项目期间开展。图 5-12 描述了本过程的输入和输出。

图 5-12控制采购：输入和输出

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

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

需求管理计划；
风险管理计划；
采购管理计划；
变更管理计划；
进度基准。

可在本过程更新的项目管理计划组件包括（但不限于）：

风险管理计划；
采购管理计划；
进度基准；
成本基准。

监督相关方参与是监督项目相关方关系，并通过修订参与策略和计划来引导相关方合理参与项目的过程。本过程的主要作用是，随着项目进展和环境变化，维持或提升相关方参与项目的效率和效果。本过程需要在整个项目期间开展。图 5-13 描述了本过程的输入和输出。

图 5-13监督相关方参与：输入和输出

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

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

资源管理计划；
沟通管理计划；
相关方参与计划。

可在本过程更新的项目管理计划组件包括（但不限于）：

资源管理计划；
沟通管理计划；
相关方参与计划。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是，存档项目或阶段信息，完成计划的工作，释放组织资源以展开新的工作。本过程仅开展一次或仅在项目的预定义点开展。图 6-2 描述了本过程的输入和输出。

图 6-2结束项目或阶段：输入和输出

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

项目管理计划的任何组件都可用作本过程的输入。

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

图 X3-3持续阶段中的过程组关系这种高度适应型方法要求不断地从工作优先级清单中提取任务。其目的在于通过删去迭代期的开始活动和结束活动，将用于重复管理过程组的管理费用最小化。不断提取任务的做法可被视为“微型迭代”，旨在最大化用于执行而非管理的时间。不过，这种做法仍然需要有自身的规划、跟踪和调整机制，以确保其既不脱离正轨又能适应变更。

执行过程组是完成项目管理计划中确定的工作，以满足项目要求的一组过程。

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

虽然工作是通过短期迭代进行的，但是也需要对照长期的项目交付时间框架对其进行跟踪和管理。先在迭代期层面上追踪开发速度、成本支出、缺陷率和团队能力的走势，再汇总并推算到项目层面，来跟踪完工绩效。高度适应型方法旨在利用团队的专业知识去完成任务。有别于由项目经理确定工作内容和排定工作顺序，在这种方法中，项目经理解释高层级的目标，同时授权团队成员作为一个小组用最能实现目标的方式自行安排具体工作。这就使团队成员能够高度投入，制定出切合实际的计划。

对于高度适应型项目上的初级团队，在其达到适合授权的状态之前，通常都需要进行辅导和分配工作。可以在一个短暂迭代期中开展渐进式试验，然后在回顾性审查会上对团队进行审查，确定团队是否已具备无需辅导即能开展工作的技能。

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

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

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

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

以下业务规则用于确保每个项目管理过程中输入和输出的顺序及信息的一致性：

基本规则：
输入是对过程很关键的任何文件。
除非输出为最终输出或被其他输入（如项目文件）采纳，否则输出应成为另一个项目管理过程的输入。
若输入并非来自项目外部，它们应该是其他项目管理过程的输出。
项目文件规则：
具体项目文件首次被识别时会列为具体输出。然后，它们将作为“项目文件更新”列入输出清单，内容叙述部分会对其加以描述。
当任何项目文件是输入时，会列出“项目文件”一词，而且内容叙述部分会说明具体的项目文件。
项目管理计划规则：
对于会制定子计划的规划过程来说，项目章程是第一项输入，项目管理计划为第二项输入。
创建项目管理计划组件的过程将具体列出组成部分。在此之后，它们会作为“项目管理计划更新”列入输出清单，内容叙述部分会对其加以描述。
如果项目管理计划是过程输入，在内容叙述部分可能会对视为输入的具体项目管理计划组成部分进行说明。
排序规则：
若项目章程是输入，则其为第一项输入。
如果项目管理计划是输入或输出，子管理计划会按《PMBOK® 指南》中输出它们的章节顺序列出，随后列出基准和任何其他计划。
项目文件会以字母排列顺序列出。
事业环境因素和组织过程资产也会按该顺序列在末尾。
如果更新是输出，它们的排列顺序如下：

项目管理计划更新；

项目文件更新；

组织过程资产更新。

12.3.1.1 项目管理计划