PMBOK/PMP 变更请求

项目集管理指在项目集中应用知识、技能与原则来实现项目集的目标，获得分别管理项目集组成部分所无法实现的利益和控制。项目集组成部分指项目集中的项目和其他项目集。项目管理注重项目本身的相互依赖关系，以确定管理项目的最佳方法。项目集管理注重作为组成部分的项目与项目集之间的依赖关系，以确定管理这些项目的最佳方法。项目集和项目间依赖关系的具体管理措施可能包括：

调整对项目集和项目的目的和目标有影响的组织或战略方向；
将项目集范围分配到项目集组成部分；
管理项目集组成部分之间的依赖关系，从而以最佳方式实施项目集；
管理可能影响项目集内多个项目的项目集风险；
解决影响项目集内多个项目的制约因素和冲突；
解决作为组成部分的项目与项目集之间的问题；
在同一个治理框架内管理变更请求；
将预算分配到项目集内的多个项目；
确保项目集及其包含的项目能够实现效益。

建立一个新的通信卫星系统就是项目集的一个实例，其所辖项目包括卫星与地面站的设计和建造、卫星发射以及系统整合。

关于项目集管理的更多信息，请参见《项目集管理标准》[3]。

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

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

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

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

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

项目管理可被看作为实现项目目标而采取的一系列过程和活动。有些过程可能只发生一次（例如项目章程的初始创建），但很多过程在整个项目期间会相互重叠并重复发生多次。这种重叠和多次出现的过程，比如需求变更，它会影响范围、进度或预算，并需要提出变更请求。控制范围过程和实施整体变更控制等若干项目管理过程可包括变更请求。在整个项目期间实施整体变更控制过程是为了整合变更请求。

虽然对项目过程的整合方式没有明确的定义，但如果项目经理无法整合相互作用的项目过程，那么实现项目目标的机会将会很小。

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

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

项目整合管理过程包括：

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）审查，在项目管理计划中就应该对审查流程和成本临界值做出相应规定。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

估算依据。见 6.4.3.2 节。估算依据指出了持续时间、成本和资源估算是如何得出的，可用于计算变更对时间、预算和资源的影响。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵有助于评估变更对项目范围的影响。
风险报告。见 11.2.3.2 节。风险报告提供了与变更请求有关的整体和单个项目风险的来源的信息。

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

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

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

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

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

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

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

备选方案分析。见 9.2.2.5 节。该技术用于评估变更请求，并决定哪些请求可接受、应否决或需修改。
成本效益分析。见 8.1.2.3 节。该分析有助于确定变更请求是否值得投入相关成本。

可用于本过程的决策技术包括（但不限于）：

投票。见 5.2.2.4 节。投票可以采取一致同意、大多数同意或相对多数原则的方式，以决定是否接受、推迟或否决变更请求。
独裁型决策制定。采用这种决策技术，将由一个人负责为整个集体制定决策。
多标准决策分析。见 8.1.2.4 节。该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求。

与变更控制委员会（CCB）一起召开变更控制会。变更控制委员会负责审查变更请求，并做出批准、否决或推迟的决定。大部分变更会对时间、成本、资源或风险产生一定的影响，因此，评估变更的影响也是会议的基本工作。此外，会议上可能还要讨论并提议所请求变更的备选方案。最后，将会议决定传达给提出变更请求的责任人或小组。

CCB 也可以审查配置管理活动。应该明确规定变更控制委员会的角色和职责，并经相关方一致同意后，记录在变更管理计划中。CCB 的决定都应记录在案，并向相关方传达，以便其知晓并采取后续行动。

由项目经理、CCB或指定的团队成员，根据变更管理计划处理变更请求（见 4.3.3.4 节），做出批准、推迟或否决的决定。批准的变更请求应通过指导与管理项目工作过程加以实施。对于推迟或否决的变更请求，应通知提出变更请求的个人或小组。

以项目文件更新的形式，在变更日志中记录所有变更请求的处理情况。

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

假设日志。见 4.1.3.2 节。假设日志记录了与技术规范、估算、进度和风险等有关的全部假设条件和制约因素。
估算依据。见 6.4.3.2 节和 7.2.3.2 节。估算依据用于根据实际结果来评估持续时间、成本和资源估算，以及成本控制。
变更日志。见 4.6.3.3 节。变更日志包含了整个项目或阶段期间的所有变更请求的状态。
问题日志。见 4.3.3.3 节。问题日志用于确认没有未决问题。
经验教训登记册。见 4.3.3.1 节。在归入经验教训知识库之前，完成对阶段或项目经验教训的总结。
里程碑清单。见 6.2.3.3 节。里程碑清单列出了完成项目里程碑的最终日期。
项目沟通记录。见 10.2.3.1 节。项目沟通记录包含整个项目期间所有的沟通。
质量控制测量结果。见 8.3.3.1 节。质量控制测量结果记录了控制质量活动的结果，证明符合质量要求。
质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。
需求文件。见 5.2.3.1 节。需求文件用于证明符合项目范围。
风险登记册。见 11.2.3.1 节。风险登记册提供了有关项目期间发生的风险的信息。
风险报告。见 11.2.3.2 节。风险报告提供了有关风险状态的信息，用于确认项目结束时没有未关闭的风险。

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

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

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

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

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

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

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。图 5-17 描述本过程的输入、工具与技术和输出。图 5-18 是本过程的数据流向图。

图 5-17控制范围：输入、工具与技术和输出

图 5-18控制范围：数据流向图

控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程（见 4.6 节）进行处理。在变更实际发生时，也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。

.

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

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

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

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

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

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

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

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

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

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

图 7-10控制成本：输入、工具与技术和输出

图 7-11控制成本的数据流向图

要更新预算，就需要了解截至目前的实际成本。只有经过实施整体变更控制过程（见 4.6 节）的批准，才可以增加预算。只监督资金的支出，而不考虑由这些支出所完成的工作的价值，对项目没有什么意义，最多只能跟踪资金流。所以在成本控制中，应重点分析项目资金支出与相应完成的工作之间的关系。有效成本控制的关键在于管理经批准的成本基准。

项目成本控制包括：

对造成成本基准变更的因素施加影响；
确保所有变更请求都得到及时处理；
当变更实际发生时，管理这些变更；
确保成本支出不超过批准的资金限额，既不超出按时段、按 WBS 组件、按活动分配的限额，也不超出项目总限额；
监督成本绩效，找出并分析与成本基准间的偏差；
对照资金支出，监督工作绩效；
防止在成本或资源使用报告中出现未经批准的变更；
向相关方报告所有经批准的变更及其相关成本；
设法把预期的成本超支控制在可接受的范围内。

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

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

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

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

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

审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展，如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。质量审计目标可能包括（但不限于）：

识别全部正在实施的良好及最佳实践；
识别所有违规做法、差距及不足；
分享所在组织和/或行业中类似项目的良好实践；
积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率；
强调每次审计都应对组织经验教训知识库的积累做出贡献。

采取后续措施纠正问题，可以降低质量成本，并提高发起人或客户对项目产品的接受度。质量审计可事先安排，也可随机进行；可由内部或外部审计师进行。

质量审计还可确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预防措施）的实施情况。

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

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

见 4.6.3.1 节。在实施整体变更控制过程中，通过更新变更日志，显示哪些变更已经得到批准，哪些变更没有得到批准。批准的变更请求可包括各种修正，如缺陷补救、修订的工作方法和修订的进度计划。完成局部变更时，如果步骤不完整或不正确，可能会导致不一致和延迟。批准的变更请求的实施需要核实，并需要确认完整性、正确性，以及是否重新测试。

以下会议可作为控制质量过程的一部分：

审查已批准的变更请求。对所有已批准的变更请求进行审查，以核实它们是否已按批准的方式实施，确认是否已完成局部变更，以及是否已执行、测试、完成和证实所有部分。
回顾/经验教训。项目团队举行的会议，旨在讨论：
项目/阶段的成功要素；
待改进之处；
当前项目和未来项目可增加的内容；
可增加到组织过程资产中的内容。

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

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

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

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

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

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

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

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

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

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

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

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

变更日志。见 4.6.3.3 节。变更日志用于向受影响的相关方传达变更，以及变更请求的批准、推迟和否决情况。
问题日志。见 4.6.3.3 节。将与问题有关的信息传达给受影响的相关方。
经验教训登记册。见 4.4.3.1 节。项目早期获取的与管理沟通有关的经验教训，可用于项目后期阶段改进沟通过程，提高沟通效率与效果。
质量报告。见 8.2.3.1 节。质量报告包括与质量问题、项目和产品改进，以及过程改进相关的信息。这些信息应交给能够采取纠正措施的人员，以便达成项目的质量期望。
风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险的来源的信息，以及关于已识别的单个项目风险的概述信息。这些信息应传达给风险责任人及其他受影响的相关方。
相关方登记册。见 13.1.3.1 节。相关方登记册确定了需要各类信息的人员、群体或组织。

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

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

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

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

见 12.3.1.4 节。如果需要从外部采购项目资源，就应该审查初始采购文档，因为从组织外部采购商品和服务可能提高或降低整体项目风险，并可能引发更多的单个项目风险。随着采购文档在项目期间的不断更新，还应该审查最新的文档，例如，卖方绩效报告、核准的变更请求和与检查相关的信息。

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

进度管理计划。见 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 节。如果商定的风险应对策略导致了成本估算变更，且这种变更已经获得批准，那么就要对成本基准做出相应的变更。

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

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

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

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

需求管理计划。见 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.6.3.1 节。批准的变更请求可能包括对合同条款和条件的修改，例如，修改采购工作说明书、定价，以及对产品、服务或成果的描述。与采购相关的任何变更，在通过控制采购过程实施之前，都需要以书面形式正式记录，并取得正式批准。在复杂的项目和项目集中，变更请求可能由参与项目的卖方提出，并对参与项目的其他卖方造成影响。项目团队应该有能力去识别、沟通和解决会影响多个卖方的工作的变更。

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

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

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

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

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

可用作本过程输入的项目文件（尤其在初始规划之后）包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志中关于假设条件和制约因素的信息，可能与特定相关方相关联。
变更日志。见 4.6.3.3 节。变更日志记录了对原始项目范围的变更。变更通常与具体相关方相关联，因为相关方可能是：变更请求的提出者，变更请求的审批者，或受变更实施影响者。
问题日志。见 4.3.3.3 节。为了管理和解决问题日志中的问题，需要与受影响的相关方进行额外沟通。
项目进度计划。见 6.5.3.2 节。进度计划中的活动可能需要与具体相关方相关联，即把特定相关方指定为活动责任人或执行者。
风险登记册。见 11.2.3.1 节。风险登记册包含项目的已识别风险，它通常会把这些风险与具体相关方相关联，即把特定相关方指定为风险责任人或受风险影响者。
相关方登记册。见 13.1.3.1 节。相关方登记册提供项目相关方的清单，以及分类情况和其他信息。

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

变更日志。见 4.6.3.3 节。变更日志会记录变更请求及其状态，并将其传递给适当的相关方。
问题日志。见 4.3.3.3 节。问题日志会记录项目或相关方的关注点，以及关于处理问题的行动方案。
经验教训登记册。见 4.4.3.1 节。在项目早期获取的与管理相关方参与有关的经验教训，可用于项目后期阶段，以提高本过程的效率和效果。
相关方登记册。见 13.1.3.1 节。相关方登记册提供项目相关方清单，以及执行相关方参与计划所需的任何信息。

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

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

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

变更日志。见 4.6.3.3 节。根据变更请求更新变更日志。
问题日志。见 4.3.3.3 节。可能需要更新问题日志，以反映问题日志条目的更新或添加。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录管理相关方参与的有效或无效方法，以供当前或未来项目借鉴。
相关方登记册。见 13.1.3.1 节。可能需要基于提供给相关方的关于问题解决、变更审批和项目状态的新信息，来更新相关方的登记册。

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

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

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

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

图 4-1执行过程组

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

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

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

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

图 5-1监控过程组

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

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

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

监控过程组指的是跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更所需的一组过程。

在迭代型、敏捷型和适应型方法中，通过维护未完项清单，对进展和绩效进行跟踪、审查和调整。在项目团队的协助（分析并提供有关技术依赖关系的信息）下，业务代表对未完项进行优先级排序。基于业务优先级和团队能力，提取未完项清单最前面的任务，供下一个迭代期完成。业务代表在听取项目团队的技术意见之后，评审变更请求和缺陷报告，排列所需变更或补救的优先级，并列入工作未完项清单。

这种把工作和变更列入同一张清单的做法，起源于充满变更的项目环境。在这种项目环境中，无法把变更从原先计划的工作中分离出来。把变更和原先的工作整合到一张未完项清单中，就便于对全部工作进行重新排序，也能够为相关方管理和控制项目工作、实施变更控制和确认范围提供单一的平台。

随着排定了优先级的任务和变更从未完项清单中提取出来，并通过迭代加以完成，就可以测算已完成工作的趋势和指标，以及变更工作量和缺陷率。通过在短期迭代中频繁抽样，计算变更影响的数量和缺陷补救工作量，就可以对照原来的范围来考察团队能力和工作进展。这样一来，就能基于实际的进展速度和变更影响来估算项目成本、进度和范围。

应该借助趋势图表（信息扩散器）与项目相关方分享这些指标和预测，以便沟通进展情况、共同面对问题、推动持续改进，以及管理相关方期望。

12.1.3.8 变更请求