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

过程	输入	工技	输出
4.1制定项目章程	1.项目工作说明书 2.商业论证3.协议/合同4.事业环境因素5.组织过程资产	专家判断、引导技术	项目章程
4.2 制定项目管理计划	项目章程、其他规划过程输出、事业环境因素、组织过程资产	专家判断、引导技术	项目管理计划
4.3 指导与管理项目执行	项目管理计划、批准的变更请求、事业环境因素、组织过程资产	专家判断、项目信息管理系统PMIS、会议	项目管理计划、变更请求、可交付的成果、工作绩效信息、项目文件
4.4 监控项目工作	项目管理计划、进度预测、成本预测、确认的变更、工作绩效信息、事业环境因素、组织过程资产	专家判断、分析技术、项目管理信息系统、会议	变更请求、变更日志、项目管理计划更新、项目文件更新
4.5 实施整体变更控制	项目管理计划、工作绩效报告、变更请求、事业环境因素、组织过程资产	专家判断、会议、变更控制工具	批准的变更请求、变更日志、项目管理计划更新、项目文件更新
4.6 结束项目或阶段	项目管理计划、验收的可交付成果、组织过程资产	专家判断、分析技术、会议	最终产品/服务/成果的移交、组织过程资产更新

3.1.1 概述

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

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

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

3.1.1.1 项目经理作为整合者

项目经理最重要的角色就是 整合者

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

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

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

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

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

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

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

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

3.1.2 涉及过程

3.1.2.0 项目选择与启动

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

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

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

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

项目启动过程的成果就是项目章程，其中会正式任命项目经理.
项目经理不是项目启动的领导者，而应该是参与者，并在项目章程中得到明确任命

3.1.2.1. 制定项目章程-启动

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

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

项目章程是一份非常重要的、对主要项目干系人有约束力的文件，相当于项目的“宪法”，后续的一切项目计划都要围绕项目章程来编制，不能违反项目章程

项目章程主要内容：

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

其中签署人为：

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

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

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

制约因素 与假设条件

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

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

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

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

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

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

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

• 项目管理计划是综合性的计划

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

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

  • 项目范围管理知识领域的范围管理计划、 需求管理计划。
  • 项目时间管理知识领域的进度管理计划。
  • 项目成本管理知识领域的成本管理计划。
  • 项目质量管理知识领域的质量管理计划、 过程改进计划。
  • 项目人力资源管理知识领域的人力资源管理计划。
  • 项目沟通管理知识领域的沟通管理计划
  • 项目风险管理知识领域的风险管理计划。
  • 项目采购管理知识领域的采购管理计划。
  • 项目干系人管理知识领域的干系人管理计划。
  • 未列入任何特定知识领域的变更管理计划、 配置管理计划
  • 三大项目基准是范围基准（由项目范围说明书、工作分解结构和工作分解结构词典组成）、 进度基准和成本基准。这三大基准又综合构成项目的“绩效测量基准”
• 后面九大知识领域的规划过程所得到的其他输出，则是“项目文件”的组成部分

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

• 三大项目基准

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

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

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

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

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

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

3.1.2.2.2 项目管理计划的制定者

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

由项目团队成员进行编写，项目经理进行整理和汇总，其他重要干系人也要参与其中：

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

3.1.2.2.3 项目管理计划的作用

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

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

3.1.2.2.4 项目管理计划的时间

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

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

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

3.1.2.2.5 项目文件

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

从层次上讲

• 项目管理计划是高层次的项目计划，必须经高级管理层审批；
• 而项目文件是低层次的项目计划，不需高级管理层审批。
  项目文件对项目管理计划起细化和支持的作用。
  经过批准的变更请求，肯定要写入项目文件，导致项目文件更新，但不一定要写入项目管理计划，导致项目管理计划更新。
  例如，纠正措施会导致项目文件更新，但对项目管理计划没有任何影响。

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

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

项目执行阶段的开始通常以“开踢会议”为标志。
- 该会议是项目计划编制工作结束、执行工作开始时，由项目经理和项目发起人召集主要项目干系人参加的一个会议，以便向主要干系人介绍项目目标与项目计划，获得他们对项目的承诺与支持，并宣布项目正式进入执行阶段。开踢会议相当于开工典礼

开踢会议是规划阶段的最后一项工作

在项目执行中，需要使用工作授权系统

• 工作授权系统是整个项目管理系统的一个子系统。它是一系列正式书面程序的集合，用来授权项目工作的开始，以保证该工作由正确的组织在正确的时间以正确的顺序执行
  
  • 项目执行期间的许多分部分项工作，不是到了进度计划规定的开始时间就可自动开始，还要得到正式的工作授权才能开始。就像大学生不是读完一年级之后即可自动进入二年级的，而必须经过一个“注册”（相当于授权）程序
  • 工作授权系统可以防止“镀金”，如增加额外的项目功能
  • 控制什么时候做什么工作以及以什么顺序做这些工作

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

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

3.1.2.4. 监控项目工作-监控

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

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

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

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

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

3.1.2.5. 实施整体变更控制-监控

对项目执行和监控过程中提出的变更请求进行综合评审，以便批准或否决变更请求，控制对项目的变更，维护项目基准的严肃性和完整性
项目计划一经批准，就成为项目执行与考核的基准线，只有经过规定的变更程序才能修改。该程序通常包括
- 提交正式的变更请求
- 对变更及其影响做出综合评价
- 批准或否决变更
该程序中的后面两个步骤，就是实施整体变更控制过程的主要工作.

• 综合性

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

• 主要任务

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

• 执行者

  • 对不会影响项目管理计划的、较小的变更，应该由项目经理或项目经理授权的团队成员，来开展整体变更控制
  • 对于会影响项目管理计划的、较大的变更，则应该由变更控制委员会，来开展整体变更控制
    变更控制委员会由主要项目干系人正式组建，并派代表参加。项目经理可以是其中的成员，但通常不是主任

• 变更控制系统

  • 变更控制系统是关于变更管理的一系列正式的书面程序的集合，包括所需文档、跟踪要求和审批层次等
  • 1、说明什么变更需要哪个层次的批准
  • 2、说明在什么情况下可以不经批准就实施变更
  • 3、说明变更控制委员会的组成、角色、权力与责任等
  • 4、通常，紧急情况下的变更可以不经批准就实施，待事后补办相关手续

• 配置管理

  • 最严格意义上的项目范围和质量变更管理，必须有一套严格的程序和其他书面规定
  • 1、识别和记录项目的重要功能以及为实现这些功能所需的物理特性（配置） 。
  • 2、跟踪这些配置，控制对这些配置的变更，并记录配置变更情况。
  • 3、按既定的配置执行项目，并记录与报告配置执行情况。
  • 4、审计项目以确保所要求的配置都已经实现（符合要求）

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

项目管理系统、变更控制系统与配置管理系统之间是什么关系

【3.1.2.5.1】

项目管理系统是一个外延最广的词汇
- 项目管理信息系统是一切项目管理工作的基础（提供一个信息平台）
- 工作授权系统则在执行过程中用于授权工作开始
- 变更控制系统关注绩效测量基准（范围、进度和成本基准）的变更
- 配置管理系统则关注项目重要技术参数的管理，特别是参数变更管理

3.1.2.6. 结束项目或阶段-结束

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

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

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

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

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

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

• 产品核实。确认全部工作都按要求完成了， 项目的产品符合既定的要求
• 财务收尾。支付最后的项目款项，完成财务结算
• 更新项目记录。完成最终的项目绩效报告和团队成员业绩记录
• 开展项目完工后评价，总结经验教训
• 更新组织过程资产。收集、整理和归档各种项目资料
• 结束项目干系人在项目上的关系，解散项目团队

行政收尾产生的成果：

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

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

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

3.1.3 输入输出

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

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

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

3.1.4 工具与技术

3.1.4.1 专家判断

实际上，几乎任何管理和技术工作都离不开专家判断，专家判断适用于一切管理和技术工作

专家判断可来自具有相应专业知识、专业实践或专业培训经历的任何小组或个人，可以从许多渠道获取。甚至可以说，专家判断可以来自你想得到的任何人

3.1.4.2 引导技术

• 引导是指引导者( Facilitator)运用适当的技术，帮助和促进一群人达成协议，关注大家的共同目标
  
  • 在制定项目章程时，项目发起人或高级管理层充当引导者，也可授权项目经理充当引导者
  • 在制定项目管理计划时，项目经理充当引导者，来协调项目的各种相互竞争的要求或事项

3.1.4.3 会议

从会议目的来讲，会议可以分成信息交流会议，方案产生与评审会议，以及决策制定会议。

• 指导与管理项目工作以及监控项目工作过程
  
  • 召开项目状态评审会议，来交流和评审项目进展情况，做出相关决定
• 实施整体变更控制过程
  
  • 召开变更控制会，来评审变更请求，做出批准、否决或悬置变更请求的决定
• 结束项目或阶段过程
  
  • 经验教训总结会、完工庆祝会

• 虽然 PMBOK 指南对制定项目章程过程和制定项目管理计划过程，没有列出会议这个工具，但实际上，在这两个过程中也是需要开会的

  • 启动阶段结束之前，需要召开项目启动会议( Initiating Meeting)，来发布项目章程，宣布项目经理的任命，宣告项目正式启动
  • 规划阶段结束之前，需要召开项目开踢会议( Kick-Off Meeting)，来介绍项目目标和项目计划，获取主要干系人的支持，宣布项目正式进入执行阶段

• 对于会议， 项目经理应该：

  • 事先明确会议目的
  • 事先制定会议规则，准备会议议程，并分发给相关人员
  • 只邀请相关人员参加会议，并要求每个参会者明白自己的责任
  • 按时开始、按时结束会议
  • 在会议上要坚持事先制定的议程，避免跑题。例如，不要试图解决会议上所产生的全部冲突，否则很容易跑题。
  • 除了解决特定问题之外，还应该使与会者享受团队的气氛
  • 做好会议记录，并在会后及时整理和分发会议纪要。会议纪要应该在会议结束后24 小时之内分发给相关人员

  如果团队内做什么都需要召开会议来解决，那说明组织的工作程序与制度不健全

  在项目执行、监控和收尾过程中，需要定期或不定期开会。但是，并不是一切问题都要依靠会议来解决的

3.1.4.4 分析技术

分析技术是用来探究变量之间的复杂关系的各种技术的总称
- 回归分析是基于历史数据，探究变量之间的因果关系，以便根据自变量的值预测（回归出）因变量的值
- 归类分析是根据一定的标准，把各种现象归入一些类别

• 监控项目工作过程
  
  • 分析是哪些因素导致了项目偏差，并据此对未来的情况做出预测
• 结束项目或阶段过程
  
  • 分析是哪些因素导致了项目偏差，并对项目产品未来的效益做出预测

3.1.4.5 项目管理信息系统

整个组织层面的项目信息系统，是项目的事业环境因素

指导与管理项目工作过程和监控项目工作过程，需要使用项目管理信息系统，则是为某个具体项目专设的项目管理信息系统，其中包括自动化的工具，如信息收集与发布系统、项目关键绩效指标监控系统

3.1.4.6 变更控制工具

借助变更控制工具，可以更有效地管埋变更请求，追踪变更处理情况，以及沟通相关事宜。例如，变更管理软件、版本控制软件，都是软件开发项目常用的变更控制工具

应该根据项目的具体情况、干系人对变更管理的要求以及各种环境因素，选择合适的变更控制工具.

3.1.5 变更管理

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

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

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

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

• 6、追踪变更的实施情况

  • 更新项目文件和项目管理计划
  • 通知受变更影响的项目干系人
  • 追踪变更的实施情况与效果
  • 在变更实施完毕后，做后评价

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

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

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

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