（13.1.3.1）PMBOK之三：十大知识领域之整合管理

过程	定义	作用	时间	输入	工技	输出
4.1制定项目章程	编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。	明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺	单次	商业文件(商业论证、效益管理计划)、协议、事业环境因素、组织过程资产	数据收集(头脑风暴、焦点小组，访谈)、人际关系与团队技能(冲突管理、引导、会议管理)	项目章程、假设日志
4.2 制定项目管理计划	定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程	生成一份综合文件，用于确定所有项目工作的基础及其执行方式	单次	项目章程、其他规划过程输出、事业环境因素、组织过程资产	专家判断、会议、数据收集(头脑风暴、焦点小组，访谈、核对单)、人际关系与团队技能(引导、会议管理、冲突管理)	项目管理计划
4.3 指导与管理项目执行	为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程	对项目工作和可交付成果开展综合管理，以提高项目成功的可能性	alltime	项目管理计划、项目文件(经验教训登记册、变更日志、需求跟踪矩阵、里程碑清单、项目进度计划、项目沟通记录、风险登记册、风险报告)、批准的变更请求、事业环境因素、组织过程资产	专家判断、会议、项目管理信息系统	可交付成果、问题日志、工作绩效数据、变更请求、项目管理计划更新、项目文件更新(经验教训登记册、假设日志、需求文件、活动清单、风险登记册、相关方登记册)、组织过程资产更新
4.4 管理项目知识	使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程	利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。	alltime	项目管理计划、项目文件(经验教训登记册、资源分解结构、项目团队派工单、相关方登记册)、可交付成果、事业环境因素、组织过程资产	专家判断、知识管理、信息管理、人际关系与团队技能(引导、政治意识、积极倾听、领导力、人际交往)	经验教训登记册、项目管理计划更新、组织过程资产更新
4.5 监控项目工作	跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程	让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态	alltime	项目管理计划、项目文件(经验教训登记册、假设日志、问题日志、里程碑清单、估算依据、成本预测、进度预测、质量报告、风险登记册 风险报告)、工作绩效信息、协议、事业环境因素、组织过程资产	专家判断、会议、数据分析(备选方案分析、成本效益分析、挣值分析、根本原因分析、趋势分析、偏差分析)、决策	工作绩效报告、变更请求、项目管理计划更新、项目文件更新(经验教训登记册、问题日志、成本预测、进度预测、风险登记册)
4.6 实施整体变更控制	审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程	确保对项目中已记录在案的变更做综合评审，如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险	alltime	项目管理计划、项目文件(需求跟踪矩阵、估算依据、风险报告)、工作绩效报告、变更请求、事业环境因素、组织过程资产	专家判断、会议、数据分析(备选方案分析、成本效益分析)、决策(投票、独裁型制定、多标准分析)、变更控制工具	批准的变更请求、项目管理计划更新、项目文件更新(变更日志)
4.7 结束项目或阶段	终结项目、阶段或合同的所有活动的过程	存档项目或阶段信息，完成计划的工作，释放组织资源以展开新的工作	单次	商业文件(商业论证、效益管理计划)、协议、项目章程、项目管理计划、项目文件(经验教训登记册、假设日志、问题日志、变更日志 、需求文件、里程碑清单、估算依据、质量控制测量结果、质量报告、项目沟通记录、风险登记册)、验收的可交付成果、组织过程资产、采购文档	专家判断、会议、数据分析(文件分析、回归分析、趋势分析、偏差分析)	最终产品/服务/或成果移交、最终报告、项目文件更新(经验教训登记册)

一、概述

整合是指协调与统一。项目整合管理是项目管理的核心，是为了实现项目各要素之间的相互协调，并在相互矛盾、相互竞争的目标中寻找最佳平衡点。

之所以需要整合管理，是因为项目的结合部（界面）最容易出问题。例如，组织（部门）与组织（部门）之间的结合部、专业与专业之间的结合部、个人与个人之间的结合部、工序（过程）与工序（过程）之间的结合部等。就像供水管道或铁轨一样，最薄弱的环节是两段之间的连接处。

• 项目整合管理涉及以下几个方面：
  
  • 在相互竞争的项目各分目标之间的整合，即范围、时间、成本和质量
  • 在项目管理的各过程之间的整合。
    例如，把项目的进度管理与成本管理联合起来考虑，开展进度管理或成本管理时都要考虑风险，项目范围变更需要与可能连带的成本、进度变更联合起来考虑。
    项目管理是通过整合开展 49 个基本过程来实现的
  • 在具有不同利益的各项目干系人之间的整合，如建筑项目的业主、设计方与承包商等
  • 在项目所需要的不同专业工作之间的整合，如各种技术工作之间
  • 在管理与技术工作之间的整合。
    例如，管理者的管理工作必须与一线工人的技术工作协调起来，否则就无法实现管理者的意图

1.1 项目经理作为整合者

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

项目经理在项目管理中的角色是多方面的，其中最重要的角色是“整合者”。

作为整合者，项目经理必须看到项目的“大局图”，确保项目全局的利益。项目经理必须：

• 通过与项目干系人主动、全面的沟通，来了解他们对项目的需求
• 在相互竞争的众多于系人之间寻找平衡点
• 通过认真、细致的协调工作，来达到各种需求之间的平衡，实现整合

1.2 整合管理在项目管理知识领域中的地位

• 项目整合管理是项目管理的管理哲学，是项目管理与传统管理的最大区别所在，也是项目管理最本质的内容。

  • 项目管理是以整合为主的管理，强调整合各种要素来完成跨部门跨专业的工作；
  • 而传统管理是以分工为主的管理，强调各部门或专业分工负责，完成各自边界内的工作

• 从十大知识领域的相互关系来看

  • 整合管理是项目管理的指导思想。项目管理团队应该在整合管理的指导之下，去从事后面九大知识领域的管理
  • 整合管理也是项目管理的归宿。后面九大知识领域的管理，最终是为了实现项目的整合管理，实现项目目标的综合最优，而不只是哪一个方面最优

1.3 项目选择与启动

组织应该有一套正式的项目选择方法和程序，以便有效使用有限的资源。选择项目，其实是一个决策过程。决策是指在两个或两个以上的备选方案中，选择一个最好的方案。要启动一个项目，通常至少需要有两个方。案可供比较

• 有两类常用的项目选择方法
  
  • 效益测量法。包括对比法、质疑委员会法、同行评议法、综合打分法、经济模型法和成本效益分析法等
  • 约束优化法。包括线性编程、非线性编程、动态编程、整数编程和多目标编程等数学模型方法

• 对效益测量法，考生需要掌握一些具体的内容，如计算投资回收期、投资回报率、净现值、内部报酬率等（将在“成本管理”一章中讨论）
• 对约束优化法，考生不需要知道具体内容，只需要知道它们的名称以及它们属于约束优化法即可。在英文中，一般情况下，带有“Programming”这个词的项目选择方法就是约束优化法。

• 项目启动是项目管理的第一项工作，包括选择一个新项目和确认该项目的正式启动。在多阶段项目上， “启动”也可以针对项目生命周期中的每个阶段，即正式开始某个阶段，并审查原定的项目章程是否仍然合理

• 项目启动过程的成果就是项目章程，其中会正式任命项目经理.

• 项目经理不是项目启动的领导者，而应该是参与者，并在项目章程中得到明确任命

二、 涉及过程

根据 PMP 考试大纲，项目经理在启动过程组的第一项工作就是开展项目评估( Project assessment)，来确认商业论证报告中的结论仍然是合理的（没有过时的）

2.1 制定项目章程-启动**

这是项目启动阶段要做的一项重要工作，不可以没项目章程,否则项目就没有基本的保障以便:

• 正式启动已经选定的某个项目
• 确立该项目在组织中的合法地位
• 授权项目经理动用组织资源开展项目工作

项目章程包含一些高层级的概述的文件，往往会包含一些高层级的计划、约束条件等，是一份非常重要的、对主要项目相关方有约束力的文件，相当于项目的“宪法”，后续的一切项目计划都要围绕项目章程来编制，不能违反项目章程

2.1.1 项目章程的主要内容

• 宣告项目的正式启动

• 项目经理及其权责。谁是项目经理？他有什么权力和责任

• 概括性地描述项目目标、主要可交付成果、主要制约因素与主要假设条件等

  • 项目目的或批准项目的理由。为什么要做这个项目?
  • 可测量的项目成功标准。用什么具体标准来考核项目总体目标的实现情况?
  • 项目审批要求。在项目规划、执行、监控和收尾过程中，应该由谁来做出什么审批
  • 项目退出标准
  • 主要假设条件和制约因素。有哪些主要的前提条件？有哪些主要的制约因素?
  • 高层级的信息
  • 高层及的需求：项目概述和产品概述。这是一个什么项目？ 项目边界在哪里？要形成什么产品?
  • 总体里程碑进度计划。何时开工？何时完工？何时实现中间的各里程碑?
  • 高层及的项目描述和边界。项目的总体范围和总体质量要求
  • 提前批准的资金资源。对准确度要求不高的项目概算，甚至可以是一个区间，如100 万元至 130 万元
  • 项目的主要风险。有哪些大风险会影响项目的总体范围、质量、进度和成本目标的实现
• 相关人员的标注
  
  • 主要干系人。有哪些已知的主要干系人 7
  • 项目章程签发者的姓名和职权

2.1.2 项目章程的签署人

项目章程由 项目发起人或者启动者 编写，或 授权项目经理 编写

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

在执行外部项目时，通常需要用正式的合同来达成合作协议。这种情况下，可能仍要用项目章程来建立组织内部的合作关系，以确保正确交付合同内容。

这是，由于项目章程中由对公司资源的使用和分配，因此不能单单由客户直接审批的

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

• 项目章程由项目发起人或高级管理层签署，分发给主要的项目干系人。
  
  • 项目发起人是项目资金的提供者。
  • 高级管理层是项目执行组织中高于项目经理的管理者
• 对于某组织发起并执行的项目，该组织的领导，作为发起人兼高级管理层，签发项目章程
• 对于某组织发起但由另一个组织执行的项目，发起组织与执行组织签署合作协议，再由执行组织的高级管理层签发项目章程
• 对于由几个组织联合发起的项目，各发起组织之间签署合作协议，再由他们的领导根据合作协议联合签发项目章程

2.1.3 项目章程的主要作用

根据项目的大小、复杂程度不同， 项目章程可以是几页、几十页甚至更多。无论如何，项目章程至少要包括以下几个方面的内容，起到以下几个方面的作用：

• 正式确认项目的存在，给项目一个合法的地位。任何一个项目，都必须有项目章程。绝对不能在没有项目章程的情况下就开始做项目
• 通过叙述启动项目的理由，把项目与公司的日常经营运作及战略计划联系起来
• 规定项目的总体目标，包括范围、时间、成本和质量等
• 确定项目经理，规定项目经理的权力。由于项目经理的岗位通常不在公司的正常权力阶梯结构之内，所以需要在项目章程中确立项目经理的权力

在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，且总应在规划开始之前任命。

2.1.4 制约因素 与假设条件

• 制约因素，也叫限制条件，是限制项目团队的选择余地的因素

  • 最常见的是范围、时间、成本、质量、人力资源等方面的制约因素。
    例如，发起人事先规定了强制性的完工日期，这个日期就是一个重要的制约因素，会使进度安排失去一些灵活性
  • 此外，还有许多其他制约因素，如项目所在执行组织的组织结构与组织文化

• 假设条件则是编制项目计划所依据的假设为“真实”或“确定”的条件，是项目计划的重要基础

  • 由于是假设为“真实”或“确定”的，所以假设条件中仍包含一定的风险，即存在得不到落实的可能性（尽管这种可能性比较小）
  • 例如：“计划所依据的基础资料是真实的”
  • 例如：“项目所需要的人力资源在某个时候可以得到”

• 假设日志

  • 高层级的战略和运营假设条件与制约因素被纳入项目章程；
  • 而假设日志用于记录整个项目生命周期中的所有假设条件和制约因素

2.2. 制定项目管理计划-规划

项目正式启动之后，就要编制综合性的项目管理计划，即把全部的分项管理计划汇编成综合的项目管理计划。这个过程是在其他各知识领域的分项管理计划编制过程的基础上开展的

2.2.1 项目管理计划的概念：分项、基准与其他

• 项目管理计划是综合性的计划
  
  • 是整合一系列分项管理计划和项目基准的结果
  • 用于指导项目的执行、监控和收尾工作

项目管理计划之分项

• 后面九大知识领域所编制的各分项管理计划，以及创建 WBS、 制定进度计划和制定预算三个过程所得到的各种项目基准，都是“制定项目管理计划过程”的输入

  1. 项目范围管理知识领域的范围管理计划、 需求管理计划。
  2. 项目时间管理知识领域的进度管理计划。
  3. 项目成本管理知识领域的成本管理计划。
  4. 项目质量管理知识领域的质量管理计划、 过程改进计划。
  5. 项目资源管理知识领域的资源管理计划。
  6. 项目沟通管理知识领域的沟通管理计划
  7. 项目风险管理知识领域的风险管理计划。
  8. 项目采购管理知识领域的采购管理计划。
  9. 项目相关方管理知识领域的相关方参与计划。
  10. 未列入任何特定知识领域的变更管理计划、 配置管理计划
  11. 三大项目基准是范围基准（由项目范围说明书、工作分解结构和工作分解结构词典组成）、 进度基准和成本基准。这三大基准又综合构成项目的“绩效测量基准”

• 变更管理计划：管理项目中的变更和变更流程；

  • 识别、汇报和跟踪可能的变更
  • 定义负责人
  • 建立并编写单个变更事项的跟踪管理日志
  • 向管理层商讨变更汇报门槛和授权水平
  • 评审风险管理计划和应对策略，并作出针对变更的相关准备
  • 分析变更影响，指定应对策略
  • 确定相关行动被认可，以更改项目绩效标准
  • 更新项目绩效标准
• 配置管理计划
  
  • 明确如何开展配置管理，并记录可交付物及项目流程变*的过程，描述项目的配置项、识别应记录和更新的配置项，以便保持项目产品的一致性和有效性。；
• 过程改进计划
  
  • 过程边界（责任人等）、过程配置、过程测量指标（控制界限等）、绩效改进目标

后面九大知识领域的规划过程所得到的其他输出，则是“项目文件”的组成部分

在项目管理计划中没有“质量基准”，在 PMBOK 指南的其他部分也没有出现“质量基准”。这可能是因为：
①在西方发达国家，质量已成为最基本的要求，不需特别强调；
②确定了范围、进度和成本基准后，质量要求就能相应确定。
从《 PMBOK 指南》第 4 版（ 2008 年）起， PMI 在 PMBOK指南中取消了“质量基准”

项目管理计划之基准

项目的绩效和项目经理的绩效是需要通过基准进行度量和考核的，项目经理也需要将基准与项目的实际情况进行对比，以获得项目是否存在偏差。一旦项目产生偏差，往往是风险识别做的不够完备或者风险管理做的不够好导致的，需要评审项目中的风险管理流程

• 三大项目基准

  • 范围基准（由项目范围说明书、工作分解结构和工作分解结构词典组成）
  • 进度基准
  • 成本基准

• 基准是经过批准的、高层次的项目计划

  • 以便作为比较的基础
  • 据此考核项目执行情况
  • 确定实际绩效是否在可接受的偏差范围内

• 也可以说，基准是一种特殊版本的项目计划

  • 在确定基准之前，可能要对项目管理计划进行多次更新，且这些更新无需遵循正式流程。但是，一旦确定了基准，就只能通过实施整体变更控制过程进行更新
  • 是项目经理和项目管理团队据以考核项目执行情况的依据，即作为比较的基础
    并不是所有项目计划都有这个作用。例如，大量的细节性计划是项目小组或团队成员自行编制和使用的，项目经理不会依据这些计划来考核项目执行情况
  • 一定是经过高级管理层和主要项目干系人批准的，而不是项目团队自编自用、无须特定批准的细节性计划
  • 除非另行说明，都是指最新版本的项目计划，即当前基准，而不是过去曾经作为基准使用过的项目计划
  • 如果要对基准进行变更，只有变更控制委员会才有权力批准。 项目经理无权批准

  项目管理计划之其他

一份完整的项目管理计划，还应该包括计划编制所依据的基本资料（或基本资料目录）。这些基本资料是计划编制工作的基础，又称“支持细节”，如假设条件、计划编制所用的基本方法等

• 项目生命周期。描述项目从开始到结束所经历的一系列阶段
• 开发方法。描述产品、服务或成果的开发方法，例如预测、迭代、敏捷或混合型模式。
• 管理审查。确定项目经理和有关相关方审查项目进展的时间点，以考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施。

2.2.2 项目管理计划的制定者

制定项目管理计划过程是收集其他规划过程的结果（输出），并汇总成一份综合的、经批准的、现实可行的、正式的项目管理计划

由项目经理整体负责，项目团队成员进行编写，项目经理进行整理和汇总，其他重要相关方也要参与其中：

• 项目管理计划不仅要经高级管理层批准，可能还要经其他主要项目相关方批准
• 在项目管理中，通常不能由上级或某个专门的计划编制部门“关起门来”编制出一份计划，然后布置给项目团队去执行。项目计划必须是自下而上编制出来的。项目团队成员要对与自己密切相关的部分（如自己所从事的工作）编制相应计划，并逐层向上报告和汇总。最后，由项目经理汇编出综合性的项目管理计划和项目文件
• 在编制项目计划的过程中，项目经理和项目团队成员也要充分听取其他主要项目干系人的意见，以便把干系人的需求尽可能地反映在项目计划中

2.2.3 项目管理计划的作用

项目管理计划的主要用途包括（但不限于）：

• 指导项目执行、监控和收尾。
• 为项目绩效考核和项目控制提供基准线。
• 记录项目计划编制所依据的假设条件。
• 记录项目计划编制过程中的有关方案选择。
• 促进项目干系人之间的沟通。
• 规定管理层审查项目的时间、内容和方式

2.2.4 项目管理计划的时间

在项目执行开始之前，要编制出尽可能完整的项目计划（包括项目管理计划和项目文件）。但是，项目计划也需要在项目生命周期的后续阶段中不断审阅、细化、完善和更新

把后续的计划更新也考虑在内， 项目计划的编制要经历以下步骤：

• 各具体知识领域编制各自的分项计划
• 整合管理知识领域收集各分项计划，整合成项目管理计划和项目文件
• 用项目管理计划和项目文件指导项目的执行和监控工作，并在执行和监控过程中提出必要的变更请求，报实施整体变更控制过程审批
• 根据经批准的变更请求，更新项目管理计划和项目文件

2.2.5 项目文件

PMBOK 指南中的“项目文件”，包括的内容很多。 47 个过程的全部输出中，除了少数非文件类输出（如可交付成果、确认的可交付成果）及以项目管理计划及其组成部分的形式出现的输出以外，其他输出全都是项目文件的组成部分

从层次上讲

• 项目管理计划是高层次的项目计划，必须经高级管理层审批；
• 而项目文件是低层次的项目计划，不需高级管理层审批。

项目文件对项目管理计划起细化和支持的作用。

经过批准的变更请求，肯定要写入项目文件，导致项目文件更新，但不一定要写入项目管理计划，导致项目管理计划更新。例如，纠正措施会导致项目文件更新，但对项目管理计划没有任何影响。

2.3 指导与管理项目工作-执行

按项目管理计划的要求，开展项目管理工作，实现项目目标。这个过程是在其他各知识领域的所有执行过程的基础上开展的

1. 以“开踢会议”为标志，于是项目执行工作的开始
2. 按计划实施，完成项目活动和可交付成果，产出工作绩效数据和必要的变更请求

3. 需要工作授权系统：保证在正确的时间以正确的顺序进行，防止镀金

4. 实施经过批准的变更，批准的变更请求可能是

   • 对正规受控的项目计划（如项目管理计划）的修改建议
   • 纠偏措施
   • 预防措施
   • 缺陷补救措施
   • 更新

2.3.1 开踢会议(Kick-off Meeting)

项目执行阶段的开始通常以“开踢会议”为标志。开踢会议相当于开工典礼，是规划阶段的最后一项工作

• 该会议是项目计划规划结束后、执行工作开始之前，由项目经理和项目发起人召集主要项目相关方参加的一个会议，以便向

  • 核心：向相关方介绍项目目标与项目计划，获得他们对项目的承诺与支持，宣读综合性的项目管理计划
    
    • 项目管理计划的正式批准应该在开踢会议之前。从某中意义上，开踢会议属于执行过程组了
  • 宣布项目正式进入执行阶段。
  • 项目团队成员互相认识
    
    • 要求必须全体成员参与,相当于团队的形成阶段

  • 落实具体的项目工作，确保个人和团队职责范围，获得成员承诺

  • 风险管理计划的编制可以是项目开工会议上的一项工作，或者可以举办专门的规划会议来编制风险管理计划。参会者可能包括项目经理、指定项目团队成员、关键相关方，或负责管理项目风险管理过程的团队成员；如果需要，也可邀请其他外部人员参加，包括客户、卖方和监管机构

  开踢会议与“启动会议(initiating metting）”，后者是启动完成之后，规划开始之前召开的一个会议，主要任务是发布项目章程并任命项目经理，赋予项目经理动用组织资源的权利，主要参与人是高级管理者‘、发起人和项目经理

2.3.2 项目管理信息系统和工作授权系统

• 项目管理信息系统是指由收集、整合和传播项目管理过程成果的工具和技术所组成的信息系统，他为项目从启动到收尾所有方面提供智慧
• 在项目执行中，需要使用工作授权系统，工作授权系统是整个项目管理系统的一个子系统。它是一系列正式书面程序的集合，用来授权项目工作的开始，以保证该工作由正确的组织在正确的时间以正确的顺序执行
  
  • 项目执行期间的许多分部分项工作，不是到了进度计划规定的开始时间就可自动开始，还要得到正式的工作授权才能开始。就像大学生不是读完一年级之后即可自动进入二年级的，而必须经过一个“注册”（相当于授权）程序
  • 工作授权系统可以防止“镀金”，如增加额外的项目功能
  • 控制什么时候做什么工作以及以什么顺序做这些工作
• 变更控制系统关注绩效测量基准（范围、进度和成本基准）的变更
• 配置管理系统则关注项目重要技术参数的管理，特别是参数变更管理

本书第 2 章曾经提到工作授权系统作为事业环境因素，工作授权程序作为组织过程资产。那里的工作授权系统和程序都是整个组织层面的。而作为项目执行中要使用的 I 作授权系统（包括程序），是专为具体项目而设立的，相当于工具与技术

2.3.3 预防措施、纠正措施与缺陷补救措施

除了按原定计划执行项目工作以外，本过程也要指导那些经批准的变更请求的执行，包括经批准的预防措施、纠正措施与缺陷补救措施

• 对正规受控的项目计划（如项目管理计划）的修改建议
• 纠正措施
  
  • 为使项目工作的未来期望绩效和项目管理计划保持一致，而对项目执行工作下达的书面指令
  • 一般是发现项目偏离轨道后所采取的措施
  • 通常不会影响项目基准，而只对基于基准的具体实施工作产生影响
  • 推荐的纠正措施包括 应急计划和权变措施
    
    1. 接受项目风险的一种做法，事先计划好当接受的风险发生时，应该采取的具体步骤，例如制定备用的活动顺序。需要建立一定的应急储备，用于应对已知风险和已知—未知型风险，应急计划中同时规定风险触发因素，即出现何种征兆时执行应急计划
    2. 后者是针对以往未曾识别或被动接受的、目前正在发生的风险而采取的未经事先计划的应对措施。是整体变更控制过程的依据之一
• 缺陷补救
  
  • 识别项目组成部分的某一缺陷之后所形成的正式文件，用于就如何修补或彻底替换提出建议
  • 一般只针对质量
• 预防措施
  
  • 为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
• 更新
  
  • 对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容

2.4 管理项目知识-执行

• 管理项目知识
  
  • 定义：使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程
  • 作用：利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。
  • 时间：在整个项目期间开展
  • 输入：项目管理计划、项目文件(经验教训登记册、资源分解结构、项目团队派工单、相关方登记册)、可交付成果、事业环境因素、组织过程资产
  • 输出：经验教训登记册、项目管理计划更新、组织过程资产更新
  • 工技：专家判断、知识管理、信息管理、人际关系与团队技能(引导、政治意识、积极倾听、领导力、人际交往)

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

知识管理指管理显性和隐性知识，旨在重复使用现有知识并生成新知识。有助于达成这两个目的的关键活动是知识分享和知识集成

2.4.1 经验教训登记册

经验教训登记册在项目早期创建，作为本过程的输出。因此，在整个项目期间，它可以作为很多过程的输入，也可以作为输出而不断更新

经验教训登记册包括 偏差和他们的原因

在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分

2.5 监控项目工作-监控

对项目执行工作进行监督与控制，以保证实现项目管理计划所定义的项目绩效目标,是从整个项目的层面上进行的总体监控
尽管项目的启动、规划和收尾工作也需要监控，但”监控项目工作过程”只针对项目执行工作

监控项目工作过程是在后九大知识领域的全部局部监控过程（如控制范围）的基础上，从整个项目层面开展的监控。它基于项目管理计划和工作绩效信息，编制各种工作绩效报告，并据此提出必要的变更请求。

• 比较项目的实际情况与项目计划中的要求，发现偏差。
• 分析偏差，评价项目绩效。
• 决定是否需要提出变更请求。
• 如果需要，则提出变更请求，并提交 “实施整体变更控制过程” 审批

PMBOK 指南中的“变更请求”是广义的，不仅包括对正规受控的项目计划（如项目管理计划）的修改建议，而且包括

• 预防措施建议，是针对将来可能出现的偏差的
  
  • 当预计项目绩效可能出现某种不能接受的偏差时（与基准比较），采取预防行动来降低消极风险发生的概率和后果，防止这种偏差的出现
• 纠正措施建议，是针对实际已经出现的偏差的
  
  • 当项目绩效发生了某种不能接受的实际偏差（与基准比较）时，采取纠偏行动来把将来的项目绩效拉回到项目计划上来
• 缺陷补救建议，只针对项目质量缺陷
  
  • 当发现项目的质量存在缺陷时，采取补救措施进行补救，以使质量符合要求
• 更新

2.6 实施整体变更控制-监控**

对项目执行和监控过程中提出的变更请求进行综合评审，以便批准或否决变更请求，控制对项目的变更，维护项目基准的严肃性和完整性

项目计划一经批准，就成为项目执行与考核的基准线，只有经过规定的变更程序才能修改。该程序通常包括

• 提交正式的变更请求
• 对变更及其影响做出综合评价
• 批准或否决变更

该程序中的后面两个步骤，就是实施整体变更控制过程的主要工作：

• 主要任务

  • 实施整体变更控制过程的主要任务是接收变更请求、分析变更请求、批准或否决变更请求。
  • 需要特别强调，实施整体变更控制过程对变更请求的分析必须是全面、系统、综合的，必须考察一个变更可能给项目各方面带来的影响，而不能局限于考察对一两个方面的影响

• 执行者

  • 对不会影响项目管理计划的、较小的变更，应该由项目经理或项目经理授权的团队成员，来开展整体变更控制
  • 对于会影响项目管理计划的、较大的变更，则应该由变更控制委员会，来开展整体变更控制
    变更控制委员会由主要项目干系人正式组建，并派代表参加。项目经理可以是其中的成员，但通常不是主任
  • 某些特定的变更请求，在 CCB 批准之后，可能还需要得到客户或发起人的批准，除非他们本身就是 CCB 的成员

• 综合性

  • 实施整体变更控制是指综合评价变更及其后果，以便在整个项目期间和整个项目范围内协调各种类型的项目变更，确保从总体上有利于项目的变更才能被批准。
  • 这个过程是专用于“综合”评价并审批变更请求的。任何过程提出的变更请求，都必须报给实施整体变更控制过程审批

变更请求可以是书面或口头，但是口头提出后需补书面记录。

2.6.1 变更管理

如果变更太大太多，可能需要修改项目章程，甚至需要终止项目，另外启动一个新项目

• 项目规划和执行都不可能完美无缺，更何况项目情况不断变化，所以项目变更是必然的。进行变更管理，项目经理应该：
  
  • 对可能引起变更的因素施加影响
  • 确认是否需要变更
  • 确认变更是否已经发生
  • 确保变更有利于项目
  • 避免（拒绝）不必要的变更
  • 识别、评价变更的备选方案
  • 全面评价变更对项目目标的影响
  • 尽量减轻变更带来的负面影响
  • 通知受变更影响的项目干系人
  • 在变更发生时，对变更进行管理
  • 记录变更情况
  • ·根据经批准的变更，更新项目文件甚至项目管理计划

三种常见的变更：

1. 纠错变更
2. 适应外界变更
3. 增值变更

变更并不可怕，可怕的是无序的变更。 项目管理特别强调有计划、按程序来开展变更

• 从源头规避
  
  • 对可能引起变更的因素施加影响
  • 对可能导致规避整体变更控制的因素施加影响
• 1、识别变更（弄清楚变更是什么）
  
  • 弄清楚变更到底是什么，提出变更申请
• 2、评价变更对项目的影响
  
  • 评价变更对所在领域的影响
  • 全面评价变更对项目的综合影响，包括对范围、时间、成本、质量、风险、客户满意度等方面的影响
• 3、寻找处理变更的备选方案
  
  • 设计处理变更的备选方案，并分析比较，选择最好的方案
• 4、征求项目干系人的意见
  
  • 征求项目团队和执行组织内部的干系人的意见
  • 如果必要，征求外部项目干系人（如客户）的意见
• 5、批准或否决变更
  
  • 批准、否决或悬置变更。悬置的变更，通常要返回提出者补充资料
• 6、追踪变更的实施情况
  
  • 更新项目文件和项目管理计划
  • 通知受变更影响的项目干系人
  • 追踪变更的实施情况与效果
  • 在变更实施完毕后，做后评价

2.6.1.2 变更的提出

• 三要素：书面申请，审批层次，跟踪变更
• 来源：参与项目的任何相关方

变更必须是正式的

1. 客户的变更处理：首先得到正式的变更申请；把变更纳入合同变更控制系统；然后进行整体变更控制；最后你才去CCB或发起人那里。

2. 通过整体变更：1）确定变更是否已发生或要发生；2）必要的批准和管理；3）批准的变更如果影响基线时，要修改基线。

3. 基准的变更通常需要得到CCB的批准。项目经理可以进行小幅度调整。而对紧急情况，项目经理可以实施应急计划，但要事先定义（“自动批准”）。

2.6.1.2 变更的批准

任何人都可以提出变更请求，但不是任何人都有权批准变更

• 如果是对项目章程的变更，只有签署或批准该章程的人（通常是发起人或高级管理层）才有权力批准，而项目经理只能提出建议
• 如果变更将影响到项目的范围、时间、成本和质量目标，即导致项目基准的变化，只有变更控制委员会才有权批准这类变更，项目经理可以分析变更的情况，提出意见
• 如果变更是项目管理计划内的，不会导致项目基准的修改，那么项目经理有权做出决定
• 但是，项目经理有权批准紧急情况下的任何变更

任何变更，无论大小，都必须经过综合评审，确认从总体上有利于项目，才能加以批准。

• 只有经过批准的变更，才能被实施、跟踪、考核和报告。
• 如果某个变更已经发生但未经审批，必须先补办审批手续，然后才能去跟踪、考核和报告

实施整体变更控制需要关于变更的详细信息，没有需要变更的证据，就没有理由去实施它。

2.6.1.3 变更的阶段处理准则

变更请求通常发生在项目工作完成时

2.6.2 变更流程概述

.基准变更后，以前的基准需要保存

1. 对项目引起的变更因素施加影响
   
   • 项目经理的主要职责不仅仅是管理变更，也要积极的预防
2. 提出变更请求
   
   • 任何相关方都可以提出变更请求，所有的变更请求都要汇总到项目经理这里记录和管理
   • 通常五大过程组仅有收尾过程组没有变更请求
   • 注意：项目章程没有变更，只有修改，修改后需要发起人的批准和签署
3. 项目经理需要和团队成员一起评估变更的影响
4. 将评估结果发给客户和变更发起人，如果不能接受结果，则直接结束
5. 如果变更涉及基准，则需要变更委员会CCB审批，否则项目经理有权直接审批，作出批准、拒绝或者延迟的决定
   
   • 变更委员会可以包括项目经理、客户、专家、发起人、职能经理等
   • 变更控制委员会审批变更，要基于项目经理上报的变更评审报告
6. 项目经理 先更新管理计划，再更新变更日志 ，并通知相关方
7. 执行和跟踪变更

针对紧急变更(事发突然，需要立即作出变更决策)，项目经理有权直接决策变更，并且先执行变更，后补充相关文件

2.6.3 变更控制系统

• 变更控制系统通常作为配置管理系统的一个子系统
• 整体变更控制通过变更控制系统来完成
• 任何变更请求都必须是正式提出的。
• 该系统主要关注绩效测量基准的变更，如范围、进度、成本等

变更控制系统是关于变更管理的一系列正式的书面程序的集合，包括所需文档、跟踪要求和审批层次等

• 1、说明什么变更需要哪个层次的批准
• 2、说明在什么情况下可以不经批准就实施变更
• 3、说明变更控制委员会的组成、角色、权力与责任等
• 4、通常，紧急情况下的变更可以不经批准就实施，待事后补办相关手续

2.6.4 配置管理系统**

配置管理计划定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程

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

最严格意义上的项目范围和质量变更管理，必须有一套严格的程序和其他书面规定，配置管理包括了组织的标准配置管理工具、过程和程序，用以跟踪和控制项目的相关记录

配置管理系统项目管理系统的一个子系统。它由一系列正式的书面程序组成，该系统包括文件和跟踪系统，并明确了为核准和控制变更所需的批准层次。该系统识别可交付成果状态、指导记录变更*

配置项

配置的对象要么是可交付成果，要么是各个过程的技术规范。

配置管理的目的

1. 建立一种先进的方法，以便规范地识别和提出对既定基准的变更，并评估变更的价值和有效性；
2. 通过分析各项变更的影响，为持续验证和改进项目创造机会；
3. 建立一种机制，以便项目管理团队规范地向有关干系人沟通变更的批准和否决情况。

注意：分清哪个是目的，哪个是手段。配置管理目的与手段的区分是一个常考点，也易错

配置管理的手段

• 1、【识别】识别和记录项目的重要功能以及为实现这些功能所需的物理特性（配置） 。
• 2、【记录变更】跟踪这些配置，控制对这些配置的变更，并记录配置变更情况。
• 3、【记录状态】按既定的配置执行项目，并记录与报告配置执行情况。
• 4、【审计】审计项目以确保所要求的配置都已经实现（符合要求）

配置管理的重点是：确定哪些是重要的技术参数，并以严格的程序来控制对这些参数的变更()，确认变更可控、在控、可追踪

配置管理的工作步骤

进行配置管理，通常包含以下三个步骤：

1. 配置项识别
   
   • 选择与识别配置项，从而为定义与核实产品配置、标志产品和文件、管理变更和明确责任提供基础。（相当于一个命名的规划过程）
2. 配置项状态
   
   • 包括已批准的配置识别清单、配置变更请求的状态和已批准的变更的实施状态。（相当于执行过程）
3. 配置项审计
   
   • 确保配置文件所规定的功能要求都已实现。（相当于监控过程）

示例：手机版本号(识别)，识别后形成基准；提醒升级并同意(变更管理)，更新后能在系统中看到当前的版本号(配置项状态)；具体是否包含了该版本相关功能(配置项审计)

2.6.5 配置管理系统与变更控制系统的区别

配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
从某种意义上来说，变更管理是一种内部的管理，而配置管理被相关干系人所关注

1. 变更控制系统是是配置管理系统的一个子系统,包含关系。
2. 关注的对象不同：
   
   • 配置管理系统的对象：要么是可交付成果，要么是各个过程的技术规范。配置管理重点关注技术规范
   • 变更控制系统的管理对象：项目及产品基准（变更）。可以是产品的特性与性能（即产品范围），可以是为实现这些特性与功能的各种具体的项目工作（即项目范围）。变更控制系统重点关注基准的变更。
3. 目的不同：
   
   • 配置管理在于 控制变更的绩效，使得变更朝向有利于项目的方向进行
   • 变更管理在于 管理和审批各种变更

2.7 结束项目或阶段-结束**

通过正式的工作程序，来结束项目管理过程组的所有活动，正式结束项目或项目阶段

结束项目过程需要实施各种活动，以达到项目的完工标准，向运营部门移交项目产品、服务或成果，以及收集项目记录、审核项目成败、总结经验教训和存档项目信息（进行组织过程资产更新）

• 项目经理需要编写最终报告，主要在于总结项目的绩效

  • 项目或阶段概述
  • 范围目标以及达到完工标准的依据
  • 质量目标以及偏差原因
  • 成本目标以及偏差原因
  • 最终产品服务或成果的确认信息的总结

• 回归分析 <结束项目或阶段>

  • 是基于历史数据，探究变量之间的因果关系，以便根据自变量的值预测（回归出）因变量的值
  • 在项目或者阶段结束的时候，通过回归分析来确定作用于项目结果的不同项目变量之间的相互关系，以找到提高未来绩效的方法

技术收尾不等于项目收尾，技术收尾往往在监控阶段完成

本过程的实质是开展项目行政收尾。在结束项目过程中，虽然也需要获得项目发起人或客户对项目产品、服务或成果的最终验收，但是这个验收主要是走一个必需的程序，是形式上的验收，而非实质性技术验收。真正的技术验收早就在确认范围过程中完成了

2.7.1 行政收尾

无论什么原因结束或终止项目，都必须进行行政收尾

在行政收尾之前，需要将可交付成果的所有权转移给指定的干系人，推动项目收尾

什么时候开展行政收尾工作？ 项目结束时、项目提前终止时、项目每个阶段结束时

行政收尾是项目管理中必须要做的一项工作。它旨在移交项目可交付成果，收集、整理、分发和归档各种项目资料，总结经验教训，更新组织过程资产，使整个项目及其管理工作有一个“善终”

依据主要见PMBOK123页小黑框，内容比较多，在考试中是有主次之分的。最核心的几项工作是：移交最终结果、归档项目文件、总结经验教训、分发最终报告、遣散资源等

1. 产品核实。确认全部工作都按要求完成了， 项目的产品符合既定的要求；
2. [产品验收]：获得了客户对于最终产品的验收；
3. [产品移交]：移交完成的产品
4. 采购收尾。支付最后的项目款项，完成财务结算
5. 开展项目完工后评价，争取对相关方对项目的反馈
6. [归档项目文件]归档了所有项目记录。完成最终的项目绩效报告和团队成员业绩记录
7. [总结经验教训] 更新组织过程资产。收集、整理和归档经验教训报告，并更新了知识库
8. [遣散资源] 结束项目相关方在项目上的关系，解散项目团队
   
   • 最后一步，在PMP考试中，默认是矩阵型组织，解散团队以回归各自的职能部门

其中，经验教训总结会，要求全部现相关方都参与

如何测量满意度：用会议来评估相关方满意度

行政收尾产生的成果：

• 对项目产品的正式接受
• 完整的项目档案
• 组织过程资产更新
• 资源释放（包括人力和非人力资源）

行政收尾与合同收尾既有联系又有区别

• 联系在于：都需要进行产品核实，总结经验教训，整理和归档相关资料，更新组织过程资产
• 差异
  
  • 行政收尾是针对项目和项目各阶段的，不仅整个项目要进行一次行政收尾，而且每个项目阶段结束时都要进行相应的行政收尾；
    而合同收尾是针对合同的，每个合同需要而且只需要进行一次合同收尾
  • 从整个项目说，合同收尾发生在行政收尾之前；如果是以合同形式进行的项目，在收尾阶段，先要进行采购审计和合同收尾，然后进行行政收尾
  • 从某一个合同的角度说，合同收尾中又包括行政收尾工作——合同的行政收尾
  • 行政收尾要由项目发起人或高级管理层给项目经理签发项目阶段结束或项目整体结束的书面确认
    而合同收尾则要由买方的采购管理员（可能是项目经理或其他人）向卖方签发合同结束的书面确认

三、 输入输出

• 整合管理的六个过程只有结束项目或阶段不用“事业环境因素”这个输入其他都要
• 整合管理的六个过程都要用“组织过程资产”作为输入

【图3.1.3.0】（未考虑事业环境因素、 组织过程资产和各种更新）

• 历史资料、经验教训与组织过程资产
  从历史资料到经验教训再到组织过程资产，这是人们对过去项目的资料的认识的两个飞跃，即要从历史资料中总结出经验教训，要把历史资料和经验教训提升到组织过程资产的高度
  
  • 历史资料是过去项目所留下来的记录，是不断改进项目管理所必需的，是未来编制项目计划和开展项目管理的重要参考资料。
    历史资料是组织过程资产的重要组成部分。
    历史资料的范围是很广的，包括经验教训、各种工作流程、各种文件模板（格式）、工作分解结构、 项目预算、项目计划等
  • 经验教训是项目完成后所形成的书面总结，阐述在该项目上什么做得好，什么做得不好，以及如果有机会重做，哪些方面可以改进等
    经验教训的总结至少要包括项目技术、项目管理、主要干系人的表现及相互之间的关系等
    在实际工作中，经验教训的总结是贯穿于项目的始终的。特别是，在项目生命周期每个阶段收尾时和整个项目收尾时，必须做这项工作
    经验教训的总结是组织过程资产更新的重要内容之一，是项目各阶段完成和项目完成的必要条件之一
    本项目的经验教训是以后项目的历史资料的重要组成部分之一
    项目经理和项目团队要总结，各主要项目干系人要分别或联合地总结，最后还要由外部专家对整个项目做独立、全面、系统的总结