PMP/PMBOK 项目管理计划

项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理运用与整合特定项目所需的项目管理过程得以实现。项目管理使组织能够有效且高效地开展项目。

有效的项目管理能够帮助个人、群体以及公共和私人组织：

达成业务目标；
满足相关方的期望；
提高可预测性；
提高成功的概率；
在适当的时间交付正确的产品；
解决问题和争议；
及时应对风险；
优化组织资源的使用；
识别、挽救或终止失败项目；
管理制约因素（例如范围、质量、进度、成本、资源）；
平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）；
以更好的方式管理变更。

项目管理不善或缺乏项目管理可能会导致：

超过时限；
成本超支；
质量低劣；
返工；
项目范围扩大失控；
组织声誉受损；
相关方不满意；
正在实施的项目无法达成目标。

项目是组织创造价值和效益的主要方式。在当今商业环境下，组织领导者需要应对预算紧缩、时间缩短、资源稀缺以及技术快速变化的情况。商业环境动荡不定，变化越来越快。为了在全球经济中保持竞争力，公司日益广泛利用项目管理，来持续创造商业价值。

有效和高效的项目管理应被视为组织的战略能力。它使组织能够：

将项目成果与业务目标联系起来；
更有效地展开市场竞争；
支持组织发展；
通过适当调整项目管理计划，以应对商业环境改变给项目带来的影响（见 4.2 节）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

项目整合管理过程包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

项目整合管理指的是：

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

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

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

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

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

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

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

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

对隶属于项目集或项目组合的项目，则应该制定与项目集或项目组合管理计划相一致的项目管理计划。例如，项目集管理计划中要求超过某一特定成本的所有变更都需要上报变更控制委员会（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-1项目管理计划和项目文件

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

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

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

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

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

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

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

见 4.2.3.1 节。项目管理计划的所有组成部分均为本过程的输入。

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

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

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

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

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

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

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

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

见 4.2.3.1 节。监控项目工作包括查看项目的各个方面。项目管理计划的任一组成部分都可作为本过程的输入。

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

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

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

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

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

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

变更管理计划。见 4.2.3.1 节。变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会（CCB）的角色和职责。
配置管理计划。见 4.2.3.1 节。配置管理计划描述项目的配置项、识别应记录和更新的配置项，以便保持项目产品的一致性和有效性。
范围基准。见 5.4.3.1 节。范围基准提供项目和产品定义。
进度基准。见 6.5.3.1 节。进度基准用于评估变更对项目进度的影响。
成本基准。见 7.3.3.1 节。成本基准用于评估变更对项目成本的影响。

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

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

见 4.2.3.1 节。项目管理计划的所有组成部分均为本过程的输入。

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

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

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

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

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

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

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

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

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）范围管理计划（见 5.1.3.1 节），其中记录了如何定义、确认和控制项目范围。

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

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

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

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

范围管理计划。见 5.1.3.1 节。范围管理计划记录了如何控制项目和产品范围。
需求管理计划。见 5.1.3.2 节。成本管理计划记录了如何管理项目需求。
变更管理计划。见 4.2.3.1 节。变更管理计划定义了管理项目变更的过程。
配置管理计划。见 4.2.3.1 节。配置管理计划定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
范围基准。见 5.4.3.1 节。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

见 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 节。在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

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

范围管理计划。见 5.1.3.1 节。范围管理计划描述如何定义和制定范围，并提供有关如何制定进度计划的信息。
开发方法。见 4.2.3.1 节。产品开发方法有助于定义进度计划方法、估算技术、进度计划编制工具以及用来控制进度的技术。

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

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

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

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

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

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

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

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

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

进度管理计划。见 6.1.3.1 节。进度管理计划描述了进度的更新频率、进度储备的使用方式，以及进度的控制方式。
进度基准。见 6.5.3.1 节。把进度基准与实际结果相比，以判断是否需要进行变更或采取纠正或预防措施。
范围基准。见 5.4.3.1 节。在监控进度基准时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。
绩效测量基准。见 4.2.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 节。在范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

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

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

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

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

成本管理计划。见 7.1.3.1 节。成本管理计划描述将如何管理和控制项目成本。
成本基准。见 7.3.3.1 节。把成本基准与实际结果相比，以判断是否需要进行变更或采取纠正或预防措施。
绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

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

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

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

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

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

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

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

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）质量管理计划。见 8.1.3.1 节。质量管理计划定义了如何在项目中开展质量控制。

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

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

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

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

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

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

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

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

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）资源管理计划。见 9.1.3.1 节，资源管理计划为如何通过团队绩效评价和其他形式的团队管理活动，为项目团队成员提供奖励、提出反馈、增加培训或采取惩罚措施提供了指南。资源管理计划可能包括团队绩效评价标准。

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）资源管理计划。见 9.1.3.1 节，资源管理计划为如何管理和最终遣散项目团队资源提供指南。

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）资源管理计划。见 9.1.3.1 节，资源管理计划为如何使用、控制和最终释放实物资源提供指南。

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

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

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

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

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

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

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

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

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

见 4.2.3.1 节。在规划项目风险管理时，应该考虑所有已批准的子管理计划，使风险管理计划与之相协调；同时，其他项目管理计划组件中所列出的方法论可能也会影响规划风险管理过程。

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

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

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

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

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

见 4.2.3.1 节。项目管理计划组件包括风险管理计划（见 11.1.3.1 节）。本过程中需要特别注意的是风险管理的角色和职责、预算和进度活动安排，以及风险类别（通常在风险分解结构中定义）、概率和影响定义、概率和影响矩阵和相关方的风险临界值。通常已经在规划风险管理过程中把这些内容裁剪成适合具体项目的需要。如果还没有这些内容，则可以在实施定性风险分析过程中编制，并经项目发起人批准之后用于本过程。

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

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

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

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

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

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

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

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

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）风险管理计划。见 11.1.3.1 节，风险管理计划列明了与风险管理相关的项目团队成员和其他相关方的角色和职责。应根据这些信息为已商定的风险应对措施分配责任人。风险管理计划还会定义适用于本项目的风险管理方法论的详细程度，还会基于关键相关方的风险偏好规定项目的风险临界值。风险临界值代表了实施风险应对所需实现的可接受目标。

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）风险管理计划（见 11.1.3.1 节）。风险管理计划规定了应如何及何时审查风险，应遵守哪些政策和程序，与本监督过程有关的角色和职责安排，以及报告格式。

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

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

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

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

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

范围管理计划。见 5.1.3.1 节。范围管理计划描述如何管理总体工作范围，包括由卖方负责的工作范围。
需求管理计划。见 5.1.3.2 节。需求管理计划描述将如何分析、记录和管理需求。它可能还包括卖方将如何管理按协议规定应该实现的需求。
沟通管理计划。见 10.1.3.1 节。沟通管理计划描述买方和卖方之间如何开展沟通。
风险管理计划。见 11.1.3.1 节。风险管理计划是项目管理计划的组成部分，描述如何安排和实施项目风险管理活动。
采购管理计划。见 12.1.3.1 节。采购管理计划包含在实施采购过程中应该开展的活动。
配置管理计划。见 5.6.1.1 节。配置管理计划定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。它包括卖方开展配置管理的形式和过程，以便与买方采取的方法保持一致。
成本基准。见 7.3.3.1 节。成本基准包括用于开展采购的预算，用于管理采购过程的成本，以及用于管理卖方的成本。

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

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

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

需求管理计划。见 5.1.3.2 节。需求管理计划描述将如何分析、记录和管理承包商需求。
风险管理计划。见 11.1.3.1 节。风险管理计划描述如何安排和实施由卖方引发的项目风险管理活动。
采购管理计划。见 12.1.3.2 节。采购管理计划规定了在控制采购过程中需要开展的活动。
变更管理计划。见 4.2.3.1 节。变更管理计划包含关于如何处理由卖方引发的变更的信息。
进度基准。见 6.5.3.1 节。如果卖方的进度拖后影响了项目的整体进度绩效，则可能需要更新并审批进度计划，以反映当前的期望。

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

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

见 4.2.3.1 节。在首次识别相关方时，项目管理计划并不存在；不过，一旦编制完成，项目管理计划组件包括（但不限于）：

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

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

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

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

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

沟通管理计划。见 10.1.3.1 节。沟通管理计划描述与相关方沟通的方法、形式和技术。
风险管理计划。见 11.1.3.1 节。风险管理计划描述了风险类别、风险偏好和报告格式。这些内容都可用于管理相关方参与。
相关方参与计划。见 13.2.3.1 节。相关方参与计划为管理相关方期望提供指导和信息。
变更管理计划。见 4.2.3.1 节。变更管理计划描述了提交、评估和执行项目变更的过程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 5-1监控过程组

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mm项目管理计划更新；

mm项目文件更新；

mm组织过程资产更新。

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

4.2.3.1 项目管理计划