第四章项目整合管理

项目管理 • Oct 22, 2019 • 阅读量 1

什么是整合管理，整合什么？如何整合？

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

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

整合管理的过程包括：

4.1 制定项目章程

制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
作用是，明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺。

项目章程一旦被批准，就标志着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，且总应在规划开始之前任命。

项目章程可由发起人编制，或者由项目经理与发起机构合作编制。通过这种合作，项目经理可以更好地了解项目目的、目标和预期效益，以便更有效地向项目活动分配资源。

项目章程授权项目经理规划、执行和控制项目。

项目由项目以外的机构来启动，如发起人、项目集或项目管理办公室（PMO）、项目组合治理委员会主席或其授权代表。项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。

不要把项目章程看作合同，因为其中未承诺报酬或金钱或用于交换的对价。

4.1.1 输入

4.1.1.1 商业文件

商业论证
效益管理计划

虽然商业文件是在项目之前制定的，但需要定期审核。

项目章程包含来源于商业文件中的相关项目信息。

既然商业文件不是项目文件，项目经理就不可以对它们进行更新或修改，只可以提出相关建议。

4.1.1.2 协议

协议用于定义启动项目的初衷。

协议有多种形式，包括合同、谅解备忘录（MOUs）、服务水平协议（SLA）、协议书、意向书、口头协议、电子邮件或其他书面协议。

为外部客户做项目时，通常就以合同的形式出现。

4.1.1.3 事业环境因素

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

政府或行业标准（如产品标准、质量标准、安全标准和工艺标准）；
法律法规要求和（或）制约因素；
市场条件；
组织文化和政治氛围；
组织治理框架（通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标）；
相关方的期望和风险临界值。

4.1.1.4 组织过程资产

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

组织的标准政策、流程和程序；
项目组合、项目集和项目的治理框架（用于提供指导和制定决策的治理职能和过程）；
监督和报告方法；
模板（如项目章程模板）；
历史信息与经验教训知识库（如项目记录与文件、关于以往项目选择决策的结果及以往项目绩效的信息）。

4.1.2 工具与技术

4.1.2.1 专家判断

专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。

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

组织战略；
效益管理；
关于项目所在的行业以及项目关注的领域的技术知识；
持续时间和预算的估算；
风险识别。

4.1.2.2 数据收集

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

头脑风暴。本技术用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。
焦点小组。焦点小组召集相关方和主题专家讨论项目风险、成功标准和其他议题，比一对一访谈更有利于互动交流。
访谈。访谈是指通过与相关方直接交谈（一对一） 来了解高层级需求、假设条件、制约因素、审批标准以及其他信息。

4.1.2.3 人际关系与团队技能

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

冲突管理。冲突管理有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见。
引导。引导是指有效引导团队活动成功以达成决定、解决方案或结论的能力。
会议管理。会议管理包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和行动计划。

4.1.2.4 会议

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

4.1.3 输出

4.1.3.1 项目章程

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

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

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

4.1.3.2 假设日志

通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。

较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。

假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。

4.2 制定项目管理计划

制定项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。
作用是，生成一份综合文件，用于确定所有项目工作的基础及其执行方式。

4.2.1 输入

4.2.1.1 项目章程

4.2.1.2 其他过程的输出

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

4.2.1.3 事业环境因素

4.2.1.4 组织过程资产

4.2.2 工具与技术

4.2.2.1 专家判断

4.2.2.2 数据收集

头脑风暴
核对单，很多组织基于自身经验制定了标准化的核对单，或者采用所在行业的核对单。核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
焦点小组
访谈

4.2.2.3 人际关系与团队技能

4.2.2.4 会议

4.2.3 输出

4.2.3.1 项目管理计划

项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。
项目管理计划组件包括（但不限于）：

子管理计划：
- 范围管理计划。见 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.3 指导与管理项目工作

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。
作用是，对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。

指导与管理项目工作包括执行计划的项目活动，以完成项目可交付成果并达成既定目标。

本过程需要分配可用资源并管理其有效使用，也需要执行因分析工作绩效数据和信息而提出的项目计划变更。

项目经理与项目管理团队一起指导实施已计划好的项目活动，并管理项目内的各种技术接口和组织接口。

指导与管理项目工作还要求回顾所有项目变更的影响，并实施已批准的变更，包括纠正措施、预防措施和（或）缺陷补救。

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

4.3.1 输入

4.3.1.1 项目管理计划

4.3.1.2 项目文件

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

变更日志。见 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.3.1.3 批准的变更请求

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

4.3.1.4 事业环境因素

4.3.1.5 组织过程资产

能够影响指导与管理项目工作过程的组织过程资产包括（但不限于）：

组织的标准政策、流程和程序；
问题与缺陷管理程序，用于定义问题与缺陷控制、问题与缺陷识别及其解决，以及行动事项跟踪；
问题与缺陷管理数据库，包括历史问题与缺陷状态、问题和缺陷解决情况，以及行动事项的结果；
绩效测量数据库，用来收集与提供过程和产品的测量数据；
变更控制和风险控制程序；
以往项目的项目信息（如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及经验教训知识库）。

4.3.2 工具与技术

4.3.2.1 专家判断

4.3.2.2 项目管理信息系统 (PMIS)

PMIS 提供信息技术 (IT) 软件工具，例如进度计划软件工具、工作授权系统、配置管理系统、信息收集与发布系统，以及进入其他在线自动化系统（如公司知识库）的界面。自动收集和报告关键绩效指标（KPI）可以是本系统的一项功能。

4.3.2.3 会议

4.3.3 输出

4.3.3.1 可交付成果

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

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

4.3.3.2 工作绩效数据

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

4.3.3.3 问题日志

在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理，以免影响项目绩效。
问题日志是一种记录和跟进所有问题的项目文件，所需记录和跟进的内容可能包括：

问题类型；
问题提出者和提出时间；
问题描述；
问题优先级；
由谁负责解决问题；
目标解决日期；
问题状态；
最终解决情况。
问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。

4.3.3.4 变更请求

变更请求是关于修改任何文件、可交付成果或基准的正式提议。

如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。

其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。
任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

变更请求源自项目内部或外部，是可选或由法律（合同）强制的。变更请求可能包括：

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

4.3.3.5 项目管理计划更新

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

4.3.3.6 项目文件更新

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

活动清单。见 6.2.3.1 节。为完成项目工作，可以通过增加或修改活动来更新活动清单。
假设日志。见 4.1.3.2 节。可以增加新的假设条件和制约因素，也可以更新或关闭已有的假设条件和制约因素。
经验教训登记册。见 4.4.3.1 节。任何有助于提高当前或未来项目绩效的经验教训都应得到及时记录。
需求文件。见 5.2.3.1 节。在本过程中可以识别新的需求，也可以适时更新需求的实现情况。
风险登记册。见 11.2.3.1 节。在本过程中可以识别新的风险，也可以更新现有风险。风险登记册用于在风险管理过程中记录风险。
相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。

4.3.3.7 组织过程资产更新

4.4 管理项目知识

管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。
作用是，利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。

知识通常分为**“显性知识”** （易使用文字、图片和数字进行编撰的知识）和**“隐性知识”** （个体知识以及难以明确表达的知识，如信念、洞察力、经验和“诀窍”）两种。

显性知识缺乏情境，可作不同解读，所以，虽易分享，但无法确保正确理解或应用。
隐性知识虽蕴含情境，却很难编撰。它存在于专家个人的思想中，或者存在于社会团体和情境中，通常经由人际交流和互动来分享。

知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。

因为知识存在于人们的思想中，且无法强迫人们分享自己的知识或关注他人的知识，所以，知识管理最重要的环节就是营造一种相互信任的氛围，激励人们分享知识或关注他人的知识。

4.5 监控项目工作

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

作用是，让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态。

绩效测量基准包括范围、进度和成本基准，一般用于计算挣值。通常不包括质量基准。质量基准经常被单独拿出来加以考核。

监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进。

监控项目工作过程关注：

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

指导与管理项目工作（输出） → 工作绩效数据 → 控制过程分析（形成） → 工作绩效信息 → （输入）监控项目工作（输出） → 工作绩效报告。

在工作执行过程中收集工作绩效数据，再交由控制过程做进一步分析。将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。工作绩效信息可以用实体或电子形式加以合并、记录和分发。基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注。工作绩效报告可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息和风险情况概述。

4.5.1 输入

4.5.1.1 项目管理计划

4.5.1.2 项目文件

4.5.1.3 工作绩效信息

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

4.5.1.4 协议

4.5.1.5 事业环境因素

4.5.1.6 组织过程资产

4.5.2 工具与技术

4.5.2.1 专家判断

4.5.2.2 数据分析

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

备选方案分析。备选方案分析用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合。
成本效益分析。见 8.1.2.3 节。成本效益分析有助于在项目出现偏差时确定最节约成本的纠正措施。
挣值分析。见 7.4.2.2 节。挣值分析对范围、进度和成本绩效进行了综合分析。
根本原因分析。见 8.2.2.2 节。根本原因分析关注识别问题的主要原因，它可用于识别出现偏差的原因以及项目经理为达成项目目标应重点关注的领域。
趋势分析。趋势分析根据以往结果预测未来绩效，它可以预测项目的进度延误，提前让项目经理意识到，按照既定趋势发展，后期进度可能出现的问题。应该在足够早的项目时间进行趋势分析，使项目团队有时间分析和纠正任何异常。可以根据趋势分析的结果，提出必要的预防措施建议。
偏差分析。偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标。

可以在每个知识领域，针对特定变量，开展偏差分析。在监控项目工作过程中，通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的总体偏差情况。这样就便于采取合适的预防或纠正措施。

4.5.2.3 决策

4.5.2.4 会议

4.5.3 输出

4.5.3.1 工作绩效报告

工作绩效信息可以用实体或电子形式加以合并、记录和分发。基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注。

4.5.3.2 变更请求

通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。

变更请求可能导致需要收集和记录新的需求。

变更可能会影响项目管理计划、项目文件或产品可交付成果。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

4.5.3.3 项目管理计划更新

4.5.3.4 项目文件更新

4.6 实施整体变更控制

实施变更控制过程旨在审批提出的变更请求。

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

本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。

作用是，确保对项目中已记录在案的变更做综合评审。

实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。

在整个项目生命周期的任何时间，参与项目的任何相关方都可以提出变更请求。

对配置要素的任何变更都应该提出变更请求，并经过正式控制。

尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和（或）配置管理系统中。

每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是项目发起人或项目经理。必要时，应该由变更控制委员会（CCB） 来开展实施整体变更控制过程。CCB 是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。

变更请求得到批准后，可能需要新编（或修订）成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可能要求调整项目管理计划和其他项目文件。

4.6.1 输入

4.6.1.1 项目管理计划

4.6.1.2 项目文件

4.6.1.3 工作绩效报告

4.6.1.4 变更请求

很多过程都会输出变更请求。变更请求（见 4.3.3.4 节）可能包含纠正措施、预防措施、缺陷补救，以及对正式受控的项目文件或可交付成果的更新，以反映修改或增加的意见或内容。

变更可能影响项目基准，也可能不影响项目基准，而只影响相对于基准的项目绩效。变更决定通常由项目经理做出。

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

4.6.1.5 事业环境因素

4.6.1.6 组织过程资产

4.6.2 工具与技术

4.6.2.1 专家判断

4.6.2.2 变更控制工具

4.6.2.3 数据分析

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

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

4.6.2.4 决策

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

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

4.6.2.5 会议

与变更控制委员会（CCB）一起召开变更控制会。变更控制委员会负责审查变更请求，并做出批准、否决或推迟的决定。

4.6.3 输出

4.6.3.1 批准的变更请求

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

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

4.6.3.2 项目管理计划更新

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

4.6.3.3 项目文件更新

正式受控的任一项目文件都可在本过程变更，通常在本过程更新的一种项目文件是变更日志。

变更日志用于记录项目期间发生的变更。

注：旧“三重制约”，指的是“进度、成本和质量”。新“三重制约” 指的是“范围、进度和成本”以及夹杂在中间的“质量”。适当扩展得到广义三重制约（4.6）。它表明了项目管理就是要在充分考虑风险的前提下，为满足相关方的需求，而确定并实现项目的范围、进度、成本和质量要求。

4.7 结束项目或阶段

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

作用是，存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作。

4.7.1 输入

4.7.1.1 项目章程

项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束。

4.7.1.2 项目管理计划

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

4.7.1.3 项目文件

4.7.1.4 验收的可交付成果

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

4.7.1.5 商业文件

见 1.2.6 节。商业文件包括（但不限于）：

商业论证。商业论证记录了作为项目依据的商业需求和成本效益分析。
效益管理计划。效益管理计划概述了项目的目标效益。
商业论证用于确定项目是否达到了经济可行性研究的预期结果。效益管理计划用于测量项目是否达到了计划的效益。

4.7.1.6 协议

通常在合同条款和条件中定义对正式关闭采购的要求，并包括在采购管理计划中。

4.7.1.7 采购文档

为关闭合同，需收集全部采购文档，并建立索引和加以归档。有关合同进度、范围、质量和成本绩效的信息，以及全部合同变更文档、支付记录和检查结果，都要归类收录。
在项目结束时，应将“实际执行的”计划（图纸）或“初始编制的”文档、手册、故障排除文档和其他技术文档视为采购文件的组成部分。这些信息可用于总结经验教训，并为签署以后的合同而用作评价承包商的基础。

4.7.1.8 组织过程资产

4.7.2 工具与技术

4.7.2.1 专家判断

4.7.2.2 数据分析

4.7.2.3 会议

会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功。

参会者可包括项目团队成员，以及参与项目或受项目影响的其他相关方。

会议可以是面对面或虚拟会议，正式或非正式会议。

会议的类型包括（但不限于）：收尾报告会、客户总结会、经验教训总结会，以及庆祝会。

4.7.3 输出

4.7.3.1 项目文件更新

可在本过程更新所有项目文件，并标记为最终版本。
特别值得注意的是，经验教训登记册的最终版本要包含阶段或项目收尾的最终信息。
最终版本的经验教训登记册可包含关于以下事项的信息：效益管理、商业论证的准确性、项目和开发生命周期、风险和问题管理、相关方参与，以及其他项目管理过程。

4.7.3.2 最终产品、服务或成果移交

项目交付的产品、服务或成果可转交给另一团队或组织，并由其在整个生命周期中进行运营、维护和支持。

4.7.3.3 最终报告

用最终报告总结项目绩效，其中可包含诸如以下信息：

项目或阶段的概述；
范围目标、范围的评估标准，以及证明达到完工标准的证据；
质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因；
成本目标，包括可接受的成本区间、实际成本，以及产生任何偏差的原因；
最终产品、服务或成果的确认信息的总结。
进度计划目标包括成果是否实现项目所预期的效益。如果在项目结束时未能实现效益，则指出效益实现程度并预计未来实现情况。
关于最终产品、服务或成果如何满足商业计划所述业务需求的概述。如果在项目结束时未能满足业务需求，则指出需求满足程度并预计业务需求何时能够得到满足。
关于项目过程中发生的风险或问题及其解决情况的概述。

4.7.3.4 组织过程资产更新

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

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

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