第4章 项目整合管理

识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动而开展的过程与活动。

“整合”兼具统一、合并、沟通和集成的性质

选择资源分配方案、平衡相互竞争的目标和方案，以及管理项目管理知识领域之间的依赖关系。

当过程之间发生相互作用时，项目整合管理就显得非常必要。

在项目管理过程组的各过程间，经常反复发生联系。

总结

作为本书的第一个管理过程组，贯穿了整个项目。

其中涉及到了很多内容，都是在其他章节才有的，所以只要了解就行，以后多看几遍书，知识点就会交叉补充的。

4.1 制定项目章程

正式批准项目并授权项目经理在项目活动中使用组织资源

作用: 明确定义项目开始和项目边界，确立项目的正式地位,高级管理层直述他们对项目的支持

项目章程在项目执行组织与需求组织之间建立起伙伴关系。

在执行外部项目时，通常需要一份正式的合同来确立这种协作关系。

经批准的项目章程意味着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，最晚也必须在规划开始之前。项目章程应该由发起项目的实体批准。

项目由项目以外的实体来启动.项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。

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

4.1.1 制定项目章程：输入

4.1.1.1 项目工作说明书

项目工作说明书（Statement of Work，SOW）是对项目需交付的产品、服务或成果的叙述性说明。

对于外部项目，工作说明书则由客户提供，可以是招标文件（如建议邀请书、信息邀请书、投标邀请书）的一部分，或合同的一部分。

SOW包括以下内容:

• 业务需要
• 产品范围描述
• 战略计划

4.1.1.2 商业论证

商业论证或类似文件能从商业角度提供必要的信息，决定项目是否值得投资。

项目经理负责确保项目有效地满足在商业论证中规定的组织目的和广大干系人的需求。

4.1.1.3 协议

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

通常，为外部客户做项目时，就用合同。

4.1.1.4 事业环境因素

见2.1.5节。

• 政府标准、行业标准或法规
• 组织文化和结构
• 市场条件

4.1.1.5 组织过程资产

见2.1.4节。

• 组织的标准过程、政策和过程定义
• 模板（如项目章程模板）
• 历史信息与经验教训知识库（如项目记录和文件、完整的项目收尾信息和文档、关于以往项目选择决策的结果和以往项目绩效的信息，以及风险管理活动中产生的信息）

4.1.2 制定项目章程：工具和技术

4.1.2.1 专家判断

专家判断可来自具有专业知识或受过专业培训的任何小组或个人，可从许多渠道获取。

包括

• 组织内的其他部门
• 顾问
• 干系人，包括客户或发起人
• 专业与技术协会
• 行业团体
• 主题专家（SME）
• 项目管理办公室（PMO）

4.1.2.2 引导技术

头脑风暴、冲突处理、问题解决和会议管理

4.1.3 制定项目章程：输出

4.1.3.1 项目章程

在项目章程中记录业务需要、假设条件、制约因素、对客户需要和高层级需求的理解，以及需要交付的新产品、服务或成果

• 项目目的或批准项目的原因
• 可测量的项目目标和相关的成功标准
• 高层级需求
• 假设条件和制约因素
• 高层级项目描述和边界定义
• 高层级风险
• 总体里程碑进度计划
• 总体预算
• 干系人清单
• 项目审批要求
• 委派的项目经理及其权责
• 发起人或其他批准项目章程的人员的姓名和职权

4.2 制定项目管理计划

生成一份核心文件，作为所有项目工作的依据

该计划需要通过不断更新来渐进明细。

这些更新需要由实施整体变更控制过程（见 4.5 节）进行控制和批准。

4.2.1 制定项目管理计划：输入

4.2.1.1 项目章程

见 4.1.3.1 节。

项目章程至少应该定义项目的高层级边界。

4.2.1.2 其他过程的输出

编制项目管理计划需要整合诸多过程（如第 5 章至第 13 章所述）的输出。其他规划过程所输出的任何基准和子管理计划，都是本过程的输入。

4.2.1.3 事业环境因素

见 2.1.5 节。

• 政府或行业标准
• 纵向市场（如建筑）或专门领域（如环境、安全、风险或敏捷软件开发）的项目管理知识体系
• 项目管理信息系统（如自动化工具，包括进度计划软件、配置管理系统、信息收集与发布系统，或进入其他在线自动化系统的网络界面）
• 组织的结构、文化、管理实践和可持续发展
• 基础设施（如现有设施和固定资产）
• 人事管理制度（如人员招聘和解雇指南、员工绩效评价、员工发展与培训记录）

4.2.1.4 组织过程资产

见 2.1.4 节。

主要包括

• 配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本与基准

4.2.2 制定项目管理计划：工具与技术

4.2.2.1 专家判断

主要为

• 根据项目需要而裁剪项目管理过程

4.2.2.2 引导技术

见 4.1.2.2 节。

4.2.3 制定项目管理计划：输出

4.2.3.1 项目管理计划

项目基准包括

• 范围基准（见 5.4.3.1 节）
• 进度基准（见 6.6.3.1 节）
• 成本基准（见 7.3.3.1 节）

子管理计划包括

• 范围管理计划（见 5.1.3.1 节）
• 需求管理计划（见 5.1.3.2 节）
• 进度管理计划（见 6.1.3.1 节）
• 成本管理计划（见 7.1.3.1 节）
• 质量管理计划（见 8.1.3.1 节）
• 过程改进计划（见 8.1.3.2 节）
• 人力资源管理计划（见 9.1.3.1 节）
• 沟通管理计划（见 10.1.3.1 节）
• 风险管理计划（见 11.1.3.1 节）
• 采购管理计划（见 12.1.3.1 节）
• 干系人管理计划（见 13.2.3.1 节）

项目管理计划可以是概括或详细的。

项目管理计划一旦被确定为基准，就只有在提出变更请求并经实施整体变更控制过程批准后，才能变更。

项目管理计划是用于管理项目的主要文件之一。

4.3 指导与管理项目工作

指导与管理项目工作：

• 纠正措施
• 预防措施
• 缺陷补救

4.3.1 指导与管理项目工作：输入

4.3.1.1 项目管理计划

见 4.2.3.1 节。

包括

• 范围管理计划（见 5.1.3.1 节）
• 需求管理计划（见 5.1.3.2 节）
• 进度管理计划（见 6.1.3.1 节）
• 成本管理计划（见 7.1.3.1 节）
• 干系人管理计划（见 13.2.3.1 节）

4.3.1.2 批准的变更请求

批准的变更请求是实施整体变更控制过程的输出，包括那些经变更控制委员会审查和批准的变更请求。

批准的变更请求可能是纠正措施、预防措施或缺陷补救。

4.3.1.3 事业环境因素

见 2.1.5 节。

主要包括

• 项目管理信息系统（如自动化工具，包括进度计划软件）

4.3.1.4 组织过程资产

见 2.1.4 节。

4.3.2 指导与管理项目工作：工具与技术

4.3.2.1 专家判断

4.3.2.2 项目管理信息系统

项目管理信息系统提供下列工具：进度计划工具、工作授权系统、配置管理系统、信息收集与发布系统，或进入其他在线自动化系统的网络界面。也可用于自动收集和报告关键绩效指标（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.3.3.5 项目文件更新

• 需求文件
• 项目日志（用于记录问题、假设条件等）
• 风险登记册
• 干系人登记册

4.4 监控项目工作

本过程的主要作用是，让干系人了解项目的当前状态、已采取的步骤，以及对预算、进度和范围的预测。

监督是贯穿于整个项目的项目管理活动之一

4.4.1 监控项目工作：输入

4.4.1.1 项目管理计划

见 4.2.3.1 节。

子计划和基准包括

• 范围管理计划（见 5.1.3.1 节）
• 需求管理计划（见 5.1.3.2 节）
• 进度管理计划（见 6.1.3.1 节）
• 成本管理计划（见 7.1.3.1 节）
• 质量管理计划（见 8.1.3.1 节）
• 过程改进计划（见 8.1.3.2 节）
• 人力资源管理计划（见 9.1.3.1 节）
• 沟通管理计划（见 10.1.3.1 节）
• 风险管理计划（见 11.1.3.1 节）
• 采购管理计划（见 12.1.3.1 节）
• 干系人管理计划（见 13.2.3.1 节）
• 范围基准（见 5.4.3.1 节）
• 进度基准（见 6.6.3.1 节）
• 成本基准（见 7.3.3.1 节）

4.4.1.2 进度预测

见 6.7.3.2.节。

基于实际进展与进度基准的比较而计算出进度预测，即完工尚需时间估算（ETC），通常表示为进度偏差（SV）和进度绩效指数（SPI）。

4.4.1.3 成本预测

见 7.4.3.2 节。

基于实际进展与成本基准的比较而计算出的完工尚需估算（ETC），通常表示为成本偏差（CV）和成本绩效指数（CPI）。通过比较完工估算（EAC）与完工预算（BAC），可以看出项目是否仍处于可容忍范围内，是否需要提出变更请求。

4.4.1.4 确认的变更

见 8.3.3.2 节。

4.4.1.5 工作绩效信息

工作绩效数据就转化为工作绩效信息。

4.4.1.6 事业环境因素

见 2.1.5.节。

4.4.1.7 组织过程资产

见 2.1.4.节。

4.4.2 监控项目工作：工具与技术

4.4.2.1 专家判断

4.4.2.2 分析技术

分析技术来预测潜在的后果。

• 根本原因分析
• 故障树分析（FTA）
• 储备分析
• 挣值管理

4.4.2.3 项目管理信息系统

4.4.2.4 会议

见 4.3.2.3 节。

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

4.4.3 监控项目工作：输出

4.4.3.1 变更请求

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

4.4.3.2 工作绩效报告

工作绩效报告是为制定决策、采取行动或引起关注而汇编工作绩效信息所形成的实物或电子项目文件。

4.4.3.3 项目管理计划更新

• 范围管理计划（见 5.1.3.1 节）
• 需求管理计划（见 5.1.3.2 节）
• 进度管理计划（见 6.1.3.1 节）
• 成本管理计划（见 7.1.3.1 节）
• 质量管理计划（见 8.1.3.1 节）
• 范围基准（见 5.4.3.1 节）
• 进度基准（见 6.6.3.1 节）
• 成本基准（见 7.3.3.1 节）

4.4.3.4 项目文件更新

• 进度和成本预测
• 工作绩效报告
• 问题日志

4.5 实施整体变更控制

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

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

来确保只有经批准的变更才能纳入修改后的基准中。

项目的任何干系人都可以提出变更请求。尽管也可以口头提出，但所有变更请求都必须以书面形式记录。

变更请求应该由变更控制系统和配置控制系统中规定的过程进行处理。应该评估变更对时间和成本的影响，并向这些过程提供评估结果。

每项记录在案的变更请求都必须由一位责任人批准或否决，这个责任人通常是项目发起人或项目经理。

应该由变更控制委员会（CCB）来开展实施整体变更控制过程。CCB 是一个正式组成的团体，负责审查、
评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。

在 CCB 批准之后，还可能需要得到客户或发起人的批准，除非他们本来就是 CCB的成员。

配置控制重点关注可交付成果及各个过程的技术规范。

分配置管理活动：

• 配置识别
• 配置状态记录。为了能及时提供关于配置项的适当数据，应记录和报告相关信息。
• 配置核实与审计

4.5.1 实施整体变更控制：输入

4.5.1.1 项目管理计划

见 4.2.3.1 节。

4.5.1.2 工作绩效报告

见 4.4.3.2 节。

4.5.1.3 变更请求

所有监控过程及很多执行过程都会输出“变更请求”。

纠正和预防措施通常不会影响项目基准，而只影响相对于基准的项目绩效。

4.5.1.4 事业环境因素

见 2.1.5 节。

4.5.1.5 组织过程资产

见 2.1.4 节。

4.5.2 实施整体变更控制：工具与技术

4.5.2.1 专家判断

4.5.2.2 会议

CCB 的决定都应记录在案，并向干系人传达，以便其知晓并采取后续措施。

4.5.2.3 变更控制工具

4.5.3 实施整体变更控制：输出

4.5.3.1 批准的变更请求

全部变更请求的处理结果，无论批准与否，都要在变更日志中更新。这种更新是项目文件更新的一部分。

4.5.3.2 变更日志

变更日志用来记录项目过程中出现的变更。

被否决的变更请求也应该记录在变更日志中。

4.5.3.3 项目管理计划更新

4.5.3.4 项目文件更新

4.6 结束项目或阶段

总结经验教训 ， 开展新工作而释放组织资源。

项目经理需要审查范围基准，确保在项目工作全部完成后才宣布项目结束。如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。

4.6.1 结束项目或阶段：输入

4.6.1.1 项目管理计划

见 4.2.3.1 节。

项目经理和项目发起人之间的协议，其中规定了项目完工的标准。

4.6.1.2 验收的可交付成果

见 5.5 节。

验收的可交付成果可能包括批准的产品规范、交货收据和工作绩效文件。

4.6.1.3 组织过程资产

见 2.1.4 节。

4.6.2 结束项目或阶段：工具与技术

4.6.2.1 专家判断

由相关专家确保项目或阶段收尾符合适用标准。

4.6.2.2 分析技术

见 4.4.2.2 节。

4.6.2.3 会议

见 4.3.2.3 节。

4.6.3 结束项目或阶段：输出

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

4.6.3.2 组织过程资产更新

• 项目档案。在项目活动中产生的各种文件
• 项目或阶段收尾文件。如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。
• 历史信息