PMP项目管理考试第四章：项目整合管理

项目整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动。

第四章 项目整合管理

• 项目常见几方
• 十大知识领域学习重点
  • what--每个子过程的定义
  • why--每个子过程的作用
  • HOW--每个子过程的ITTO
    • 输入（Input）：依据是什么、参考什么、应该审查什么
    • 工具和技术（Tool Technology）：用什么方法、用什么技术。
    • 输出（Output）：是为了什么做，记录在什么文件中。
• 项目整合管理的核心概念
  • 在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终。
  • 项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家（如成本分析专家、进度规划专家、风险管理专家）管理，但是项目整合管理的责任不能被授权或转移。
  • 项目经理必须对整个项目承担最终责任。
  • 项目越复杂，相关方的期望越多样化，就需要越全面的整合方法。
• 项目整合管理的发展趋势和新兴实践
  • 项目整合管理知识领域要求整合所有其他知识领域的成果。
  • 与整合管理过程相关的发展趋势包括（但不限于）：
    • ◆　使用自动化工具。 项目经理需要整合大量的数据和信息，因此有必要使用项目管理信息系统（PMIS） 和自动化工具来收集、分析和使用信息，以实现项目目标和项目效益。
    • ◆　使用可视化管理工具。 有些项目团队使用可视化管理工具，而不是书面计划和其他文档，来获取和监督关键的项目要素。这样，就便于整个团队直观地看到项目的实时状态，促进知识转移，并提高团队成员和其他相关方识别和解决问题的能力。
    • ◆　项目知识管理。应对 项目人员的流动性和不稳定性，采用更严格的过程，在整个项目生命周期中积累知识并传达给目标受众，以防止知识流失。
    • ◆　增加项目经理的职责。 项目经理被要求介入启动和结束项目，例如开展项目商业论证和效益管理。按照以往的惯例，这些事务均由管理层和项目管理办公室负责。现在，项目经理需要频繁地与他们合作处理这些事务，以便更好地实现项目目标以及交付项目效益。项目经理也需要更全面地识别相关方，并引导他们参与项目，包括管理项目经理与各职能部门、运营部门和高级管理人员之间的接口。
    • ◆　混合型方法。 经实践检验的新做法会不断地融入项目管理方法，例如，采用敏捷或其他迭代做法，为开展需求管理而采用商业分析技术，为分析项目复杂性而采用相关工具，以及为在组织中应用项目成果而采用组织变革管理方法。
• 在敏捷和适应型环境中需要考虑的因素。
  • 迭代和敏捷方法中
    • 团队成员以相关领域专家的身份参与整合管理：
      • 团队成员自行决定计划
      • 团队成员自行决定组件的整合方式。
  • 与传统方法比较
    • 对项目经理的期望保持不变，但把对具体产品的规划和交付授权给团队
    • 项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那么这种合作型方法就会更加有效。
• 49个子过程
• 整合管理过程之一“制定项目章程”（启动过程组）
  • 制定项目章程
    • 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
      • 项目经理可以参与做
      • 批只能是领导
  • 主要作用是
    • 明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺。它仅开展一次或仅在项目的预定义点开展。
  • 制定项目章程的几个注意点
    • 项目章程在项目执行组织与需求组织之间建立起伙伴关系。
    • 项目章程一旦被批准，就标志着项目的正式启动。
    • 项目由项目以外的机构来启动，如发起人、项目集或项目管理办公室（PMO）、项目组合治理委员会主席或其授权代表。
    • 尽早确认并任命项目经理，项目经理应该参与项目章程的制定，以便对项目章程有基本了解
    • 最好在制定项目章程时就任命，最晚也必须在在规划开始之前任命。
    • 项目章程可由发起人编制，或者由项目经理与发起机构合作编制。
    • 通过编制项目章程，来确认项目符合组织战略和日常运营的需要。
    • 在执行外部项目时，通常需要用正式的合同来达成合作协议。
    • 不要把项目章程看作合同，因为其中未承诺报酬或金钱或用于交换的对价。
      • 一般现有合同再有项目章程
  • 输入
    • 商业文件
      • 商业文件是在项目之前制定的，但需要定期审核。
      • 商业文件不是项目文件，项目经理就不可以对它们进行更新或修改，只可以提出相关建议。
      • 商业文件包含
        • ◆　商业论证。 经批准的商业论证或类似文件是最常用于制定项目章程的商业文件。商业论证从商业视角描述必要的信息，并且据此决定项目的期望结果是否值得所需投资。高于项目级别的经理和高管们通常使用该文件作为决策的依据。一般情况下，商业论证会包含商业需求和成本效益分析，以论证项目的合理性并确定项目边界。
          • 商业需求分析
          • 成本效益分析，详见第七章
        • ◆　效益管理计划
          • 描述了项目实现效益的方式和时间，以及应指定的效益衡量机制。
    • 协议
      • 定义了启动项目的初衷
      • 协议形式
        • 合同（为外部客户做项目）
        • 谅解备忘录（MOUs）
        • 服务水平协议（SLA）
        • 协议书、意向书、口头协议、电子邮件或其他书面协议。
    • 事业环境因素 每个过程组都有
    • 组织过程资产 每个过程组都有
  • 工具
    • 专家判断
      • 基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。（基本上人人都是专家）
      • 本过程应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：
        • ◆　组织战略；
        • ◆　效益管理；
        • ◆　关于项目所在的行业以及项目关注的领域的技术知识；
        • ◆　持续时间和成本估算；
        • ◆　风险识别。
    • 数据收集
      • 头脑风暴
        • 本技术用于在短时间内获得大量创意，是典型的信息收集技术适用于团队环境，需要引导者进行引导。头脑风暴由两个部分构成：创意产生和创意分析。制定项目章程时可通过头脑风暴向相关方、主题专家和团队成员收集数据、解决方案或创意。原则是 不质疑 不分析 不批判不反对
      • 焦点小组
        • 焦点小组召集相关方和主题专家（SME）讨论项目风险、成功标准和其他议题，比一对一访谈更有利于互动交流。同职能
      • 访谈
        • 访谈是指通过与相关方直接交谈来了解高层级需求、假设条件、制约因素、审批标准以及其他信息。
    • 人际关系与团队技能
      • ◆　冲突管理。冲突管理有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见。
      • ◆　引导。 引导是指有效引导团队活动成功以达成决定、解决方案或结论的能力。引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果，以及所达成的行动计划和协议在之后得到合理执行。
      • ◆　会议管理。会议管理包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和行动计划。
        • 几点注意
          • 不要把各种会议混在一起开
          • 面对面的会议效果最好，有时也需要虚拟会议。
          • 应明确每个参会者的角色，确保有效参会
          • 会议要达成共识，要有行动计划
        • 会前
          • 要确定会议议程、目的、目标和期限
        • 会中
          • 不要跑题
        • 会后
          • 要形成书面的会议纪要和行动方案
    • 会议
      • 在本过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息。
  • 输出
    • 项目章程
      • 由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资产开展项目活动的文件，（是项目的"宪法"，是项目经理的“尚方宝剑”）
      • 包含内容
        • ◆　项目目的；
        • ◆　可测量的项目目标和相关的成功标准；
        • ◆　高层级需求；
        • ◆　高层级项目描述、边界定义以及主要可交付成果；
        • ◆　整体项目风险；
        • ◆　总体里程碑进度计划；
        • ◆　预先批准的财务资源；
        • ◆　关键相关方名单；
        • ◆　项目审批要求（例如，用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）；
        • ◆　项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）；
        • ◆　委派的项目经理及其职责和职权；
        • ◆　发起人或其他批准项目章程的人员的姓名和职权。
    • 假设日志
      • 通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。
      • 假设日志
        • 假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。
          • 假设条件（前提条件）
            • 不需要验证即可视为正确、真是或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。
          • 制约因素
            • 对项目或过程的执行有影响的限制性因素
• 整合管理过程之二“制定项目管理计划”（规划过程组）
  • 近期细排 后期概括 渐进明细 只是把子计划整合成一份计划
  • 制定项目管理计划
    • 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。
  • 主要作用是
    • 生成一份综合文件，用于确定所有项目工作的基础及其执行方式，它仅开展一次或仅在项目的预定义点开展。
  • 项目管理计划可以是概括的或详细的，详细程度取决于具体项目的要求
    • 项目管理计划应足够强大，可以应对不断变化的项目环境。这种敏捷性有利于随项目进展产出更准确的信息。
    • 项目管理计划应基准化，即至少应规定项目的范围、时间和成本
      • 在确定基准之前，可能要对项目管理计划进行多次更新，且这些更新无需遵循正式流程。
      • 就只能通过实施整体变更控制过程进行更新。
    • 渐进明细
      • 在项目收尾之前，该计划需要通过不断更新来渐进明细，并且这些更新需要得到控制和批准。
  • 制定项目管理计划在子过程（计划）后面
  • 输入
    • 项目章程
      • 项目团队把项目章程作为初始项目规划的起始点。
    • 其他过程的输出
      • 其他规划过程所输出的子计划和基准都是本过程的输入。此外，对这些子计划和基准的变更都可能导致对项目管理计划的相应更新。
  • 工具
    • 专家判断
    • 数据收集
      • 头脑风暴
      • 核对单
        • 包括需要考虑的项目、行动或要点的清单，常被用作提醒
      • 焦点小组
      • 访谈
    • 人际关系与团队技能
      • 冲突管理、引导、会议管理
    • 会议
      • 规划的最终一步 开工会议，kick off meeting
  • 输出
    • 项目管理计划
      • 项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。
      • 子计划分类
      • 项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划，但它们也是实现高效管理所必需的文件。表4.1列出了主要的项目管理计划组件和项目文件。
• 整合管理过程之三“指导与管理项目工作”（执行过程组）
  • 指导与管理项目工作
    • 指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。
  • 本过程作用
    • 对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。本过程需要在整个项目期间开展。
  • 该过程会实施以下活动
    • 1、实施已计划好的项目活动
    • 2、管理项目内的各种技术接口和组织接口
    • 3、回顾所有项目变更的影响，并实施已批准的变更
    • 4、收集工作绩效数据并传达给合适的控制过程。
  • 输入
    • 项目管理计划
      • 项目管理计划的任何组件都可用作本过程的输入
    • 批准的变更请求
      • 实施整体变更控制过程的输出，可能是纠正措施、预防措施或缺陷补救
  • 工具技术
    • 专家判断
    • 会议
      • 会议类型
        • 开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议以及回顾会议。
      • 参会人员
        • 项目经理、项目团队成员，以及与所讨论事项相关或会受该事项影响的相关方。
    • 项目管理信息系统 （PMIS）
      • PMIS 提供信息技术 （IT） 软件工具，例如进度计划软件工具、工作授权系统、配置管理系统、信息收集与发布系统，以及进入其他在线自动化系统（如公司知识库）的界面。自动收集和报告关键绩效指标（KPI）可以是本系统的一项功能。
  • 输出
    • 可交付成果
      • 在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是项目结果，并可包括项目管理计划的组成部分。
    • 工作绩效数据
      • 工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。
      • 在工作执行过程中收集数据，再交由控制过程做进一步分析。
    • 问题日志
      • 一种记录和跟进所有问题的项目文件，所需记录和跟进的内容可能包括：
        • ◆　问题类型；
        • ◆　问题提出者和提出时间；
        • ◆　问题描述；
        • ◆　问题优先级；
        • ◆　由谁负责解决问题；
        • ◆　目标解决日期；
        • ◆　问题状态；
        • ◆　最终解决情况。
      • 在此过程被创建，在整个项目生命周期应该随 监控活动更新
    • 变更请求
      • 变更请求是关于修改任何文件、可交付成果或基准的正式提议。可以是直接或间接的，可以有外部或内部提出，可能输自选或有法律/合同所强制的，可口头提，但必须书面记录
      • 包括
        • ◆　纠正措施。 为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
          • 目的是为了纠偏差
        • ◆　预防措施。 为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
          • 目的是为了防风险
        • 不会改变项目管理计划或基准，是用来维护基准的
        • ◆　缺陷补救。 为了修正不一致产品或产品组件的有目的的活动。
          • 目的是为了补质量（仅针对质量问题）
        • ◆　更新。 对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。
          • 通常改计划 -------会改变项目管理计划或基准，是用来修改基准的。
  • 注意 输入的批准的变更请求 与 输出 的 变更请求没有任何关系
• 整合管理过程之四“管理项目知识”(执行过程组)
  • 管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。
  • 本过程的主要作用是，利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。
  • 显性知识与隐性知识
    • 知识通常分为“显性知识”（易使用文字、图片和数字进行编撰的知识）和“隐性知识”（个体知识以及难以明确表达的知识，如信念、洞察力、经验和“诀窍”）两种。知识管理指管理显性和隐性知识，旨在重复使用现有知识并生成新知识。有助于达成这两个目的的关键活动是知识分享和知识集成（不同领域的知识、情境知识和项目管理知识）。 一个常见误解是，知识管理只是将知识记录下来用于分享；另一种常见误解是，知识管理只是在项目结束时总结经验教训，以供未来项目使用。这样的话，只有经编撰的显性知识可以得到分享。因为显性知识缺乏情境，可作不同解读，所以，虽易分享，但无法确保正确理解或应用。隐性知识虽蕴含情境，却很难编撰。它存在于专家个人的思想中，或者存在于社会团体和情境中，通常经由人际交流和互动来分享。
  • 管理知识注意点
    • 组织角度看
      • 从组织的角度来看，知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。
    • 最重要的环节
      • 因为知识存在于人们的思想中，且无法强迫人们分享自己的知识或关注他人的知识，所以，知识管理最重要的环节就是营造一种相互信任的氛围，激励人们分享知识或关注他人的知识。如果不激励人们分享知识或关注他人的知识，即便最好的知识管理工具和技术也无法发挥作用。
    • 实践中双管齐下
      • 在实践中，联合使用知识管理工具和技术（用于人际互动）以及信息管理工具和技术（用于编撰显性知识）来分享知识。
  • 输入
    • 项目管理计划--项目管理计划的所有组成部分均为本过程的输入。
    • 项目文件
      • ◆　经验教训登记册。 见4.4.3.1节。提供了有效的知识管理实践。
      • ◆　项目团队派工单。 见9.3.3.1节。说明了项目已具有的能力和经验以及可能缺乏的知识。
      • ◆　资源分解结构。 见9.2.3.3节。包含有关团队组成的信息，有助于了解团队拥有和缺乏的知识。
      • ◆　相关方登记册。 见13.1.3.1节。包含已识别的相关方的详细情况，有助于了解他们可能拥有的知识。
    • 可交付成果
      • 可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是为实现项目目标而完成的有形的组成部分，并可包括项目管理计划的组成部分。
    • 事业环境因素
      • 能够影响管理项目知识过程的事业环境因素包括（但不限于）：
      • ◆　组织文化、相关方文化和客户文化。 相互信任的工作关系和互不指责的文化对知识管理尤其重要。其他因素则包括赋予学习的价值和社会行为规范。
      • ◆　设施和资源的地理分布。 团队成员所在的位置有助于确定收集和分享知识的方法。
      • ◆　组织中的知识专家。 有些组织拥有专门从事知识管理的团队或员工。
      • ◆　法律法规要求和（或）制约因素。 包括对项目信息的保密性要求。
    • 组织过程资产
      • 与项目管理有关的知识往往内嵌于工作过程和例行工作中。能够影响管理项目知识过程的组织过程资产包括（但不限于）：
      • ◆　组织的标准政策、流程和程序。 可能包括：信息的保密性和获取渠道、安全与数据保护、记录保留政策、版权信息的使用、机密信息的销毁、文件格式和最大篇幅、注册数据和元数据、授权使用的技术和社交媒体等。
      • ◆　人事管理制度。 包括员工发展与培训记录以及关于知识分享行为的能力框架。
      • ◆　组织对沟通的要求。 正式且严格的沟通要求有利于信息分享。对于生成新知识和整合不同相关方群体的知识，非正式沟通更加有效。
      • ◆　正式的知识分享和信息分享程序。 包括项目和项目阶段开始之前、开展期间和结束之后的学习回顾，例如识别、吸取和分享从当前项目和其他项目获得的经验教训。
  • 工具与技术
    • 专家判断
    • 知识管理
      • 知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识。
      • 面对面互动最有利于建立知识管理所需的信任关系。一旦信任关系建立，可以用虚拟互动来维护这种信任关系。
    • 信息管理
      • 信息管理工具和技术用于创造信息并建立人们与信息之间的联系。可以有效促进简单、明确的显性知识的分享
      • 通过增加互动要素，比如：通过增加互动要素，如“与我联系”的功能，使用户能够与经验教训发帖者联系，并向其寻求与特定项目和情境有关的建议。从而可以向隐形知识延伸
    • 人际关系与团队技能
      • ◆　积极倾听。 见10.2.2.6节。积极倾听有助于减少误解并促进沟通和知识分享。
      • ◆　引导。 见4.1.2.3节。引导有助于有效指引团队成功地达成决定、解决方案或结论。
      • ◆　领导力。 见3.4.4节。领导力可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标。
      • ◆　人际交往。 见10.2.2.6节。人际交往促使项目相关方之间建立非正式的联系和关系，为显性和隐性知识的分享创造条件。
      • ◆　政治意识。 见10.1.2.6节。政治意识有助于项目经理根据项目环境和组织的政治环境规划沟通。
  • 输出
    • 经验教训登记册
      • 项目早期创建。项目期间不断更新。项目结束归入项目经验教训知识库
    • 项目管理计划更新
      • 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中更新。
    • 组织过程资产更新
      • 所有项目都会生成新知识。通过管理项目知识过程，某些新知识被编撰，被嵌入可交付成果，或者被用于改进过程和程序。在本过程中，也可以首次编撰或使用现有知识，例如，关于新程序的现有想法在本项目中试用并获得成功。
• 整合管理过程之五“监控项目工作”(监控过程组)
  • 监控项目工作
    • 监控项目工作是跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。
    • 本过程作用
      • 让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，
      • 以及通过成本和进度预测，让相关方了解未来项目状态。
      • 监督是贯穿于整个项目的项目管理活动之一，是唯一输出工作绩效报告的过程。
    • 输入
      • 项目管理计划
      • 项目文件
        • 进度预测
          • 进度预测基于项目以往的绩效，用于确定项目是否仍处于进度的公差区间内，并识别任何必要的变更。
        • 成本预测
          • 成本预测基于项目以往的绩效，用于确定项目是否仍处于预算的公差区间内，并识别任何必要的变更。
        • ◆　假设日志。 见4.1.3.2节。假设日志包含会影响项目的假设条件和制约因素的信息。
        • ◆　估算依据。 见6.4.3.2节和 7.2.3.2节。估算依据说明不同估算是如何得出的，用于决定如何应对偏差。
        • ◆　问题日志。 见4.3.3.3节。问题日志用于记录和监督由谁负责在目标日期内解决特定问题。
        • ◆　经验教训登记册。 见4.4.3.1节。经验教训登记册可能包含应对偏差的有效方式以及纠正措施和预防措施。
        • ◆　里程碑清单。 见6.2.3.3节。里程碑清单列出特定里程碑的实现日期，用于检查是否达到计划的里程碑。
        • ◆　质量报告。 见8.2.3.1节。质量报告包含质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（包括返工、缺陷或漏洞补救、100% 检查等），以及在控制质量过程中发现的情况的概述。
        • ◆　风险登记册。 见11.2.3.1节。风险登记册提供在项目执行过程中发生的各种威胁和机会的相关信息。
        • ◆　风险报告。 见11.2.3.2节。风险报告提供关于整体项目风险和单个风险的信息。
      • 工作绩效信息
        • 在工作执行过程中收集工作绩效数据，再交由控制过程做进一步分析。将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。
        • 绩效包含：范围、进度、预算和质量以及项目管理计划中定义的其他的具体工作绩效测量指标。
        • 工作绩效信息为决策提供依据。
      • 进度预测
      • 成本预测
    • 工具技术
      • 数据分析
        • ◆　挣值分析。 见7.4.2.2节。挣值分析对范围、进度和成本绩效进行了综合分析。
        • ◆　偏差分析。 偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标。
        • ◆　趋势分析。 根据过去预测将来，趋势分析根据以往结果预测未来绩效，它可以预测项目的进度延误，提前让项目经理意识到，按照既定趋势发展，后期进度可能出现的问题。应该在足够早的项目时间进行趋势分析，使项目团队有时间分析和纠正任何异常。可以根据趋势分析的结果，提出必要的预防措施建议。
        • ◆　根本原因分析。 见8.2.2.2节。根本原因分析关注识别问题的主要原因，它可用于识别出现偏差的原因以及项目经理为达成项目目标应重点关注的领域。
          • 从源头上解决问题
        • ◆　备选方案分析。 备选方案分析用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合。
        • ◆　成本效益分析。 见8.1.2.3节。选择成本最低的方案来纠偏。成本效益分析有助于在项目出现偏差时确定最节约成本的纠正措施。
      • 决策
        • 决策技术包括（但不限于）投票。如 5.2.2.4所述，投票可以包括用下列方法进行决策：一致同意、大多数同意或相对多数原则。
      • 工作绩效报告
    • 输出
      • 工作绩效报告
        • 基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注。
        • 根据项目沟通管理计划，通过沟通过程向项目相关方发送工作绩效报告。（状态报告、进展报告）
      • 变更请求
        • 通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。
      • 项目管理计划更新
        • ◆　纠正措施。 为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
        • ◆　预防措施。 为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
        • ◆　缺陷补救。 为了修正不一致产品或产品组件而进行的有目的的活动。
      • 项目管理计划更新
        • 在监控项目工作过程中提出的变更可能会影响整体项目管理计划。
      • 项目文件更新
        • ◆　成本预测。 见7.4.3.2节。本过程引起的成本预测的变更应通过成本管理过程进行记录。
        • ◆　问题日志。 见4.3.3.3节。在本过程中产生的新问题应该记录到问题日志中。
        • ◆　经验教训登记册。 见4.4.3.1节。更新经验教训登记册，记录应对偏差的有效方式以及纠正措施和预防措施。
        • ◆　风险登记册。 见11.2.3.1节。在本过程中识别的新风险应记录在风险登记册中，并通过风险管理过程进行管理。
        • ◆　进度预测。 见6.6.3.2节。本过程引起的进度预测的变更应通过进度管理过程进行记录。
• 整合管理过程之六“实施整体变更控制”(监控过程组)
  • 实施整体变更控制
    • 审查所有变更请求、批准变更、管理变更、并对变更处理结果进行沟通的过程。
    • 几个注意点
      • 实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。
      • 应确保只有经批准的变更才能纳入修改后的基准中。
      • 任何相关方都可提出变更请求，可以口头提出，必须以书面形式记录。并纳入变更管理和/或配置管理系统中
      • 应该评估变更对时间和成本的影响，并向这些过程提供评估结果。
      • 每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，应在项目管理计划或组织程序中指定这位责任人，必要时，应由变更控制委员会（CCB）来开展实施整体变更控制过程。
        • CCB-一个正是组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。
          • 甲方领导
          • 乙方领导
          • 专家
          • 监理
          • 代理方
  • 本过程作用
    • 确保对项目中已记录在案的变更做综合评审。从而降低整体项目风险。
    • 本过程只会审批、管理变更，不会提出变更请求（只处理变更不生产变更）
  • 输入
    • 变更请求
      • 向变更请求的提出者了解变更的具体内容或变更的原因，告知变更的流程，防止不必要的变更。
      • 若确认必须变更则走以下5步流程
        • 1、记录：书面记录变更请求；项目经理书面记录（变更日志），或要求变更提出者提交书面的变更请求。
        • 2、评估：充分了解变更，评估变更带来的影响；与相关的相关方沟通评估出的影响。
        • 3、提交：提交责任人审批；注意，这里提交是指“项目经理”将变更请求和评估的结果提交给CCB
        • 4、更新：不管变更通过还是不通过，必须更新变更日志；如果变更通过，更新项目管理计划。
        • 5、通知（重中之重）：应将变更的结果通知相关（受影响）的相关方
      • 变更题的常见考法
        • 1、变更的顺序
          • 首先看现在进行到哪一步了
          • 根据顺序（1.记录、2评估、3审批、4更新、5通知）来选择下一步做什么
        • 2、考要不要变更
          • 凡是涉及到基准的修改的时候，都需要走流程
  • 工具与技术
    • 变更控制工具
      • 工具应支持以下配置管理活动：
        • ◆　识别配置项。 识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
        • ◆　记录并报告配置项状态。 关于各个配置项的信息记录和报告。
        • ◆　进行配置项核实与审计。 通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
      • 工具还应支持以下变更管理活动：
        • ◆　识别变更。 识别并选择过程或项目文件的变更项。
        • ◆　记录变更。 将变更记录为合适的变更请求。
        • ◆　做出变更决定。 审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
        • ◆　跟踪变更。 确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。
      • 数据分析
        • ◆ 备选方案分析。 见9.2.2.5节。该技术用于评估变更请求，并决定哪些请求可接受、应否决或需修改。 ◆ 成本效益分析。 见8.1.2.3节。该分析有助于确定变更请求是否值得投入相关成本
      • 决策
        • ◆　投票。 见5.2.2.4节。投票可以采取一致同意、大多数同意或相对多数原则的方式，以决定是否接受、推迟或否决变更请求。
        • ◆　独裁型决策制定。 采用这种决策技术，将由一个人负责为整个集体制定决策。
        • ◆　多标准决策分析。 见8.1.2.4节。该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求。
      • 会议
  • 输出
    • 批准的变更请求
      • 变更请求批准人的选择顺序：
        • 首选：项目管理计划或组织流程中指定的责任人。（最准确的说法，但不常见，题中如出现优先选。）
        • 次选：变更控制委员会（CCB）。（默认变更都是通过CCB来审批，最常见的选择）
        • 再选：如题中无以上选项，则可选择“PMO”、发起人、项目经理
      • 以项目文件更新的形式，在变更日志中记录所有变更请求的处理情况。
    • 项目文件更新
      • 式受控的任一项目文件都可在本过程变更。通常在本过程更新的一种项目文件是变更日志。变更日志用于记录项目期间发生的变更。被否决的变更请求也应记录在变更日志中。
    • 项目管理计划更新
      • 对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性。
• 整合管理过程之七“结束项目或阶段”(收尾过程组)
  • 项目或阶段---终结项目、阶段或合同的所有活动的过程。
  • 本过程作用：存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作
  • 结束项目或阶段注意点
    • 在项目结束时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。
    • 若项目在完工前就提前终止，结束项目或阶段过程还是需要制定程序，来调查和记录提前终止的原因。
  • • 6+2
    • 如果项目提前终止
      • 1、需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，
      • 相关方满意度调查
      • 2、把该项目的已完成和未完成的可交付成果移交他人。
      • 3、总结记录经验教训
      • 4、组织过程资产更新
      • 5、文件归档
      • 庆功会
      • 6、释放资源
  • 输入
    • 项目章程
      • 项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束。
    • 项目管理计划
      • 项目管理计划的所有组成部分均为本过程的输入。
    • 验收的可交付成果
      • 验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果。
    • 项目文件
      • 可用于本过程输入的项目文件包括（但不限于）：
        • ◆　假设日志。 见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节。风险报告提供了有关风险状态的信息，用于确认项目结束时没有未关闭的风险。
    • 商业文件
      • 商业文件包括（但不限于）：
        • ◆　商业论证。 商业论证记录了作为项目依据的商业需求和成本效益分析。
        • ◆　效益管理计划。 效益管理计划概述了项目的目标效益。
    • 协议
      • 通常在合同条款和条件中定义对正式关闭采购的要求，并包括在采购管理计划中。在复杂项目中，可能需要同时或先后管理多个合同
    • 采购文档
      • 见12.3.1.4节。为关闭合同，需收集全部采购文档，并建立索引和加以归档。有关合同进度、范围、质量和成本绩效的信息，以及全部合同变更文档、支付记录和检查结果，都要归类收录。在项目结束时，应将“实际执行的”计划（图纸）或“初始编制的”文档、手册、故障排除文档和其他技术文档视为采购文件的组成部分。这些信息可用于总结经验教训，并为签署以后的合同而用作评价承包商的基础。
    • 4.7.1.8　组织过程资产
      • 能够影响结束项目或阶段过程的组织过程资产包括（但不限于）：
      • ◆　项目或阶段收尾指南或要求（如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估，以及知识传递）；
      • ◆　配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准。
  • 工具与技术
    • 专家判断
      • 见4.1.2.1节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：
        • ◆　管理控制；
        • ◆　审计；
        • ◆　法规与采购；
        • ◆　法律法规。
    • 数据分析
      • 可用于项目收尾的数据分析技术包括（但不限于）：
        • ◆　文件分析。 见5.2.2.3节。评估现有文件有助于总结经验教训和分享知识，以改进未来项目和组织资产。
        • ◆　回归分析。 该技术分析作用于项目结果的不同项目变量之间的相互关系，以提高未来项目的绩效。
        • ◆　趋势分析。 见4.5.2.2节。趋势分析可用于确认组织所用模式的有效性，并且为了未来项目而进行相应的模式调整。
        • ◆　偏差分析。 见4.5.2.2节。偏差分析可通过比较最初计划目标与最终结果来改进组织的测量指标。
    • 会议
      • 会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功。参会者可包括项目团队成员，以及参与项目或受项目影响的其他相关方。会议可以是面对面或虚拟会议，正式或非正式会议。会议的类型包括（但不限于）：收尾报告会、客户总结会、经验教训总结会，以及庆祝会。
  • 输出
    • 项目文件更新
    • 最终产品、服务或成果移交
      • 本输出所指的正是把项目交付的最终产品、服务或成果（对于阶段收尾，则是所在阶段的中间产品、服务或成果）从一个团队转交到另一个团队。并由其在整个生命周期中进行运营、维护和支持。
    • 最终报告
      • 用最终报告总结项目绩效
    • 组织过程资产更新
      • 需要更新的组织过程资产包括（但不限于）：
        • ◆　项目文件。 在项目活动中产生的各种文件，例如项目管理计划，范围文件、成本文件、进度文件和项目日历，以及变更管理文件。
        • ◆　运营和支持文件。 组织维护、运营和支持项目交付的产品或服务时所需的文件。可以是新生成的文件，或对已有文件的更新。
        • ◆　项目或阶段收尾文件。
          • 1、 项目或阶段收尾文件包括表明项目或阶段完工的正式文件，2、以及用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。在项目收尾期间，项目经理应该回顾以往的阶段文件，确认范围过程（见5.5节）所产生的客户验收文件，以及合同协议（如果有的话），以确保在达到全部项目要求之后才正式关闭项目。
          • 如果项目在完工前提前终止，则1、需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，2、把该项目的已完成和未完成的可交付成果移交他人。
        • ◆　经验教训知识库。 将在整个项目期间获得的经验教训和知识归入经验教训知识库，供未来项目使用。
• 举例
  • 项目启动管理
    • 售前文档审查
      • 招标文件
      • 投标文件
      • 合同
    • 售前交底会
    • 项目经理任命书
  • 项目启动汇报
  • 变更管理
    • 会前沟通
  • 收尾过程中
    • 客户有新需求
      • 走变更流程
      • 新开一个项目
    • 发现问题
      • 项目经理解决
    • 安排项目经理做下一个项目
      • 优先完成收尾工作
  • 收尾完成后
    • 客户有新需求
      • 新开一个项目
    • 发现问题
      • 维护人员解决