PMP项目管理 - 整合管理

系列文章目录

系统架构设计
PMP项目管理 - 质量管理
PMP项目管理 - 采购管理
PMP项目管理 - 资源管理
PMP项目管理 - 风险管理
PMP项目管理 - 沟通管理

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

需要对什么进行整合管理？
干系人需求、约束条件、项目管理各个过程、项目集、项目组合的政策、公司战略等等。

如何实现整合管理？
在整合管理的过程中要经常寻找平衡点，考虑各种约束条件、风险和不确定性来满足项目的目标。

一、制定项目章程（启动）- 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件

制定项目章程 过程定义编写一份正式批准项目并授权 PM 在项目活动中使用组织资源的文件的过程。
项目章程确立项目的正式地位，并展示组织对项目的承诺。
（1）最适合编写项目章程的是发起人或项目经理，由发起人、项目集、PMO 或项目组合治理委员会主席等等这些公司高层来批准。
（2）项目章程的批准，标志着项目的正式启动，项目经理的正式授权。
（3）尽早确认并任命项目经理，最好在制定章程时任命，最迟必须在规划开始前任命。

• 制定项目章程的输入：商业文件（包括商业论证和收益管理计划）
  （1） 商业论证 ：文档化的项目经济可行性研究报告，包含商业需要分析与成本效益分析。主要是从商业视角描述必要信息，论证项目的合理性，并据此决定项目的预期结果是否值得所需投资，并确定项目边界。高于项目级别的经理和高管们通常使用该文件作为决策的依据。
  商业论证的原因要符合组织战略需要：
  （a）市场需求（如为应对汽油紧缺，某汽车公司批准一个低油耗车型的研发项目）；
  （b）组织需要（如因为管理费用太高，公司决定合并一些职能并优化流程以降低成本）；
  （c）客户要求（如为了给新工业园区供电，某电力公司批准一个新变电站建设项目）；
  （d）技术进步（如基于技术进步，某航空公司批准了一个新项目，来开发电子机票以取代纸质机票）；
  （e）法律要求（如某油漆制品厂批准一个项目，来编写有毒物质处理指南）；
  （f）生态影响（如某公司批准一个项目，来降低对环境的影响）；
  （g）社会需要（如为应对霍乱频发，某发展中国家的非政府组织批准一个项目，为社区建设饮用水系统和公共厕所，并开展卫生教育）。
  （2） 收益管理计划 ：对创造、提高和保持项目收益的过程进行定义的书面文件。商业文件，不是PM做的，是商业分析师做的，PM不可以对商业文件进行更新或修改，PM可以参与，可以提出建议，也需要定期审查商业论证，确保项目有它的商业价值。

• 制定项目章程的输入：协议
  协议定义了启动项目的初衷。通常，为外部客户做项目时，就用合同。

• 制定项目章程的输入：事业环境因素、组织过程资产，基本上是所有过程的输入

• 制定项目章程的工具与技术：专家判断
  定义：具有专业知识或受过专业培训的任何小组或者个人，都可以提供专家判断。所以专家判断，有时不仅仅是一个人，有时可以是一个小组、多人。比如主题专家 SME、PMO、行业协会、客户、发起人等等都可以提供专家判断。
  项目经理的周边到处都是专家。项目经理自己本身是项目管理专家，但并不表示他什么都该知道。专业技术方面的问题可以咨询主题专家，财务问题可以咨询财务专家。专家判断可用于第四章整合管理的全部过程组。通俗点来说专家判断就是拍脑袋想问题。

• 制定项目章程的工具与技术：数据收集（头脑风暴、焦点小组、访谈）
  1） 头脑风暴 ：一种用来产生和收集对项目需求与产品需求的多种创意的技术，又称“集思广益”。拍脑袋、天马行空、集思广益、没有对错，能在短时间内获得大量创意，需要引导者进行引导。不涉及排序或投票。
  2） 焦点小组 ：召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度，由一位受过训练的主持人引导大家进行互动式讨论，比一对一的访谈更加热烈。
  3） 访谈 ：通过与干系人直接交谈，来获取信息的方法。采取“提问—回答”的方式，通常一对一，有时也可多对多。

• 制定项目章程的工具与技术：人际关系与团队技能（冲突管理、引导、会议管理）
  1） 冲突管理 ：（详见资源管理）有助于干系人就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见；
  
  2） 引导 ：引导者有效指导团队活动成功以达到成功决策、解决方案或结论的能力。
  3） 会议管理 ：（详见沟通管理）包括准备议程、确保邀请每个关键干系人群体的代表，以及准备和发送后续的会议纪要和行动计划。
  

• 制定项目章程的输出：项目章程
  项目章程又称“项目批准书”，是由项目启动者或发起人发布的，正式批准项目成立 ，并授权项目经理动用组织资源开展项目活动的文件。章程相当于发起人与项目经理之间的契约。项目章程确保干系人在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。
  包括以下 12 个内容：
  （1）项目目的
  （2）可测量的项目目标和相关的成功标准
  （3）高层级（high-level）需求：（是指宏观、大概、大体上、战略上的需求）
  （4）高层级项目描述、边界定义以及主要可交付成果（这是一个什么项目？要形成什么产品？）
  （5）整体项目风险；（主要的风险）
  （6）总体（Summary）里程碑进度计划：（几个关键的里程碑进度）
  （7）预先批准的财务资源（大概的项目预算）
  （8）关键干系人名单：（大概的干系人名单）
  （9）项目审批要求：（用什么标准评价成功、由谁对成功下结论、由谁来签署项目结束）
  （10）项目退出标准：（在何种条件下才能关闭或取消项目或阶段）
  （11）委派的项目经理及其权责
  （12）发起人或其他审批项目章程的人员的姓名和职权。
  3 高 2 总体 1 关键：高层级需求，高层级项目边界，高层级项目风险，总体进度，总体预算，关键相关方。

• 假设日志（假设条件、制约因素）
  假设日志：项目早期，以当时准确信息为基础，渐进明细具有时限。不受控制，但真是存在，必须实现/解决。
  假设条件 ：不确定因素、风险，需要渐进明细。
  制约因素 ：限制性的因素，比如事先确定的预算、强制性日期、进度里程碑、合同条件等，不是渐进明细的。

二、制定项目管理计划（规划）- 定义、准备和协调所有子计划，并把它们整合为一份综合项目管理计划

制定项目管理计划 过程定义准备和协调所有子计划，并把它们整合为一份综合项目管理计划。
过程作用：生成一份核心文件，用于确定所有项目工作的基础及其执行方式。项目管理计划确定项目执行、监控和收尾方式，应足够强壮和敏捷，以应对不断变化的项目环境。PMI 要求在项目中所做的所有事情都必须是在计划中所体现的，做计划之外试图“讨好”干系人被称为“镀金”，这是项目中明令禁止的。
比如客户要 PM 去买包烟，PM 买了烟后又私自决定给客户配了个打火机。这就是镀金了，客户并不需要打火机，也许客户自己有更高级的“ZIPPO”，并不需要 PM 给他买的打火机。镀金，是画蛇添足、因为浪费了资源。
制定项目管理计划：过程

• 制定项目管理计划的输入：“其他过程的输出”
  是指子计划和基准，比如：范围管理计划、进度管理计划、成本管理计划等等，制定项目管理计划要参考这些子计划，把他们整合为综合的“项目管理计划”。项目管理计划并不是一步到位，而是需要不断更新来渐进明细。
• 制定项目管理计划的工具：数据收集（头脑风暴、核对单、焦点小组、访谈）
  核对单：基于类似项目和历史信息来编制核对单，或采用所在行业的核对单。核对单用来指导项目经理制定计划或帮助检查项目管理计划是否包含所需的全部信息。
• 制定项目管理计划的输出：项目管理计划
  项目管理计划，是说明项目将如何执行、监控和收尾的一份文件。它整合并综合所了有子管理计划和基准，以及管理项目所需的其他信息（取决于具体项目的需求）。
  构成：子计划、基准和其他组件。
  
  （1）子计划：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、干系人管理计划、风险管理计划、采购管理计划。
  （2）3 个基准：范围基准、进度基准、成本基准。
  基准：工作产品、项目计划，经过批准，即成为基准。只有通过正式的变更控制程序才能对其进行变更。用于与实际绩效比较，来确定绩效是否在可接受的偏差范围内。
  比如：某网银每天限制转账额度5000，超过5000 就要使用大额转账技术，比如u 盾、密保
  卡等等。这个5000 就是一个基准。
  如果这个基准需要变化，需要经过正式的变更控制程序才能变更。
  （3）其他组件（配置管理计划、变更管理计划、绩效测量基准、项目生命周期、开发方法、管理审查）：
  变更管理与配置管理：配置管理 是交付成果，各过程的技术规范。变更控制 是识别、记录、批准/否决项目计划和基准的变更，变更是配置的一部分。
  绩效测量基准 Performance Measurement Baseline，简称PMB。项目范围-进度-成本三位一体基准。为项目工作制定的，经批准的范围-进度-成本综合计划，用来与项目执行情况相比较，以测量和管理绩效。
  项目管理计划的批准：《项目管理计划》一定要得到管理层、发起人、项目经理、项目团队代表和相关项目干系人的同意和正式批准。一个项目或项目阶段，如没有正式批准的《项目管理计划》是难以有效开展的。正式批准意味着干系人的签名，签名意味着发起人与项目经理，项目经理与团队成员之间建立的契约关系。
  开工会议： Kickoff Meeting ： 又称启动大会、开工会议、开踢会议
  （1）每个项目必须有启动大会，是个动员大会。
  召开时间：项目规划完成后、项目执行开始前召开；属于规划过程组；
  （2）参加方：项目各重要干系人（发起人、顾客、高层管理、职能管理部门、卖方代表、项目团队等）。
  （3）是个宏观、务虚会议。作用：传达项目目标与项目管理计划，获得干系人对项目的承诺与支持，阐明每个干系人的角色和职责，并宣布项目正式进入执行，相当于开工典礼。

三、指导与管理项目工作（执行）- 为实现项目目标而领导和执行项目管理计划中所确定的工作，实施已批准的变更

指导与管理项目工作 为实现项目目标而领导和执行项目管理计划中所确定的工作，实施已批准的变更。
输入批准的变更请求，输出可交付成果。

四、管理项目知识（执行）- 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程

管理项目知识 过程定义使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。管理显性和隐性知识，重复使用现有知识并生成新知识。重点关注把现有知识条理化和系统化，以便更好的加以利用。

• 管理项目知识的工具：知识管理（无法脱离人而存在）
  促进员工合作创造新知识，分享隐性知识。
  比如人际交往、工作跟随和跟随指导。
  （1）人际交往：在组织、行业或职业环境中与他人的正式或非正式互动。
  人际交往在项目初始时特别有用，目的是为了建立关系，增加获取资源的途径，改进人力资源管理。人际交往的方式有很多种：写信、午餐会、座谈会等等。
  （2）工作跟随：徒弟跟着师傅实习，徒弟无需承担任何责任，全部责任由师傅承担。
  （3）跟随指导：师傅跟随和观察新手的工作情况，并给予指导。
• 管理项目知识的工具：信息管理（可以脱离人而存在）
  用于促进显性知识分享的各种具体方法。
  比如：图书馆服务、文献检索、经验教训登记册编制。
  最重要的是需要把隐性知识显性化，把那些难以传递、难以理解、难以分享的知识收集
  下来更新在经验教训登记册当中
• 管理项目知识的输出：经验教训登记册
  会得到更新，最终存入组织过程资产中。

五、监控项目工作（监控）- 跟踪、审查和报告项目进展，以实现项目管理计划中确定的绩效目标

监控项目工作 过程定义跟踪、审查启动、规划、执行、收尾各个过程，来实现项目管理计划中确定的绩效目标。就是把实际绩效和项目管理计划进行对比，发现偏差、分析原因，提出变更。

• 监控项目工作的输入：工作绩效信息work performance information
  从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。
  比如：第一天计划预习PMBOK 到50 页，实际只预习到30 页。对比发现，比计划少预习
  20页，20 是工作绩效信息。
• 监控项目工作的工具：数据分析
  - 监控项目工作的输出：工作绩效报告 work performance reports
  为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息，所形成的实物或电子项目文件。
  比如：第一天计划预习PMBOK 到50 页，实际只预习到30 页。对比发现，比计划少预习20页。第二天少预习10 页、第三天又少预习15 页??最终写成一份报告，为什么总是不遵守计划，怎么总是少预习。是工作效率太低、还是懒惰引起的，分析找到原因等等。汇总写成一份状态报告。
• 监控项目工作的输出：变更请求
  是指监控项目工作时会引发变更请求。
  通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或縮小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。

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

实施整体变更控制 过程定义审查所有变更请求，批准或否决变更，并管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。
这个过程的作用，就是对这四种提出来的变更请求，批准或否决，然后更新相应的计划或文件。
提出的变更到底是同意，还是拒绝？需要在这个过程做判断。
实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任。
这句话说明PM对变更负最终责任，万一哪个变更变得不好，责任都在PM没有把控好。PM要对变更请求跟踪负责到底。

• 配置管理系统
  包含在配置管理计划中，由一系列正式的书面程序组成，用于对以下工作提供技术和管理方面的指导与监督：
  （1）识别并记录产品、成果、服务或部件的功能特征和物理特征
  （2）控制对上述特征的任何变更
  （3）记录并报告每一项变更及其实施情况
  （4）支持对产品、成果或部件的审查，以确保其符合要求
  配置管理系统明确了为核准和控制变更所需的批准层次。
  配置管理活动包括：
  （1）识别配置项：选择与识别配置项，从而为定义与核实产品配置、 标记产品和文件、管理变更和明确责任提供基础。（相当于编号，version 1.0,version 2.0）
  （2）记录并报告配置项状态：关于各个配置项的信息记录和报告。（相当于记录版本的说明，1.0 版本拓展了场景文字??；2.0 版本优化了bug，解决了闪退问题）
  （3）配置核实与审计：保证项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。（确保配置项组成的正确性，确保变更都被记录、评估、批准、跟踪和正确实施。现在2.0的版本要变更到2.1 了，要确保这个变更符合流程。）
  也可以用五大过程组的关系来理解这三个活动：
  识别配置项、记录并报告配置项状态属于执行过程组的活动；
  配置项核实与审计属于监控过程组的活动；
  简单理解配置管理包含了变更管理和版本管理。
• 变更控制委员会 （CCB：Change Control Board）
  （1）CCB 是正式的团体，但不一定是固定的团体；
  （2）组成：项目发起人、客户、项目经理、相关专家、其他主要干系人；
  （3）任务：审查、评价、批准、推迟或否决项目变更，记录和传达变更处理请求；
  （4）设立原因：项目经理权力有限，对于涉及计划基准的变更不能自做主张；
  一句话概括CCB 设立的原因：PM 一个人决定不了的大事需要通过CCB 来群体决策。
• 变更控制系统：Change Control System
  包含在变更管理计划中
  （1）是指包括变更管理的一系列正式的书面程序，包括文档、跟踪系统和变更的批准层次等；
  （2）该系统不仅说明什么样的变更需要哪个层次的批准，而且也说明在什么情况下可以不经
  批准就实施变更；
  （3）该系统说明CCB 的组成、权力与责任；
  （4）紧急情况下的变更可以不经CCB 批准就实施，但事后需补办相关变更手续；
• 变更的批准权限
  每项记录在案的变更请求都必须由一位责任人批准或否决。这个责任人通常是PM 或者发起人，在项目管理计划或组织流程中会指定批准责任人。必要时由CCB 开展实施整体变更控制过程。
  （1）PM：一般批准不涉及基准的变更请求，紧急情况可批准特殊的变更请求。
  比如有客户老板的连环夺命call，要求马上、立即、立刻进行一个变更，不变就解约，非常紧急。那就PM 自己决定要不要变吧。因为如果走流程的话，时间来不及。
  注意：一些很简单的变更，不涉及基准的，比如说干系人登记册里一位干系人的名字写错了，这种小问题，PM 也可以自行决定，不用走流程
  （2）发起人：一般批准章程的变更；
  章程写的不清楚，要进行变更，由发起人来决定要不要变；
  （3）变更控制委员会CCB：批准或否决基准的变更请求；
  （4）客户：批准按合同实施的项目的某些变更请求
  虽然影响基准的变更必须要通过CCB 的批准,但并不意味着CCB 只能批准影响基准的变更,有一些在变更控制系统中指定需要CCB 批准的变更但并没有影响基准。
• 完整的变更管理流程
  
  流程如下：
  （0）PM 对可能引起变更的因素施加影响；
  注意！是“施加”影响，而不是第2 步的“评估”影响。看看是否是不必要的变更，
  避免因个人的主观臆断随意进行变更。
  （1）干系人正式向PM 提交变更请求，并记录变更请求；
  ——书面记录变更、创建变更请求。
  （2）PM 评估变更对项目的影响；
  ——记录后，评估如果实施变更会对项目产生什么影响。
  （3）PM 与干系人沟通并寻求处理变更的备选方案；
  ——寻找处理变更的解决方案
  （4.1）PM 自主决策；
  ——如果变更不影响基准，PM 自主决策，之后更新到变更日志中。
  （4）PM 提交含解决方案的变更请求给CCB 审批；
  ——如果变更影响基准，PM 将变更请求提交给CCB。
  ——如果CCB 否决了变更请求，将结果更新到变更日志中。
  （5）更新项目管理计划与项目文件；
  ——如果CCB 批准了变更请求，就需要更新项目管理计划／文件。
  （6）通知受变更影响的干系人；
  ——通知会受到变更影响的干系人。
  （7）项目团队执行批准的变更；
  ——项目团队执行、实施批准的变更请求。
  （8）跟踪确认变更的实施情况；
  ——被批准执行的变更，跟踪、记录实施情况如何。

七、结束项目或阶段（收尾）- 审核所有变更请求、批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通

结束项目或阶段 定义完结所有项目管理过程的所有活动，正式结束项目或阶段。结束项目也叫项目收尾、行政收尾、阶段收尾。
项目有明确的起点和终点，起点是项目章程获得批准。终点是：
（1）目标达成
（2）不能达到目标项目终止
（3）项目需求不复存在
（4）客户或发起人希望终止等等
如果项目在完工前就提前终止，本过程还需制定程序，来调查和记录提前终止的原因。

• 结束项目或阶段的输入：项目章程
  记录了项目成功标准、审批要求，以及由谁来签署项目结束
• 结束项目或阶段的输入：项目管理计划
  结束项目时,项目经理需要审查项目管理计划中的范围基准，确保所有的项目工作均已完成，才可以进行收尾。
• 结束项目或阶段的输入：商业文件
  商业论证：用于确定项目是否达到了经济可行性研究的预期结果
  收益管理计划：用于测量项目是否达到了计划的收益
• 结束项目或阶段的输入：验收的可交付成果
  正常收尾的验收的可交付成果包括批准的产品规范、交货收据和工作绩效文件；
  分阶段或被取消的项目中，包括未全部完成的可交付成果或中间可交付成果。
• 结束项目或阶段的工具：会议
  用于确认可交付成果已通过验收、确定已达到退出标准、正式关闭合同，评估干系人满意度，传递项目知识和信息，以及庆祝成功。
  参与者：团队成员、参加项目或受项目影响的干系人
  会议类型：收尾报告会、客户总结会、经验教训总结会，以及庆祝会等
• 结束项目或阶段的输出：最终产品、服务或成果移交
  项目收尾，移交项目所产出的最终产品、服务或成果；
  阶段收尾，移交该阶段所产出的最终产品、服务或成果。
• 结束项目或阶段的输出：最终报告
  用最终报告总结项目绩效，可包括以下信息：
  （a) 项目或阶段的概述
  （b) 范围目标、范围的评估标准，以及证明达到完工标准的证据
  （c) 质量目标、项目产品和质量的评估标准，核实信息以及偏差原因
  （d) 成本目标，包括可接受的成本区间、实际成本，以及偏差原因
  （e) 最终产品、服务或成果的确认信息的概述
  （f) 进度目标，包括成果是否实现项目所预期的收益，以及未来实现情况
  （g) 最终产品、服务或成果如何满足商业计划所述业务需求的概述
  （h) 项目过程中发生的风险或问题及其解决情况的概述
• 行政收尾活动
  

（1）为达到阶段或项目的完工或退出标准所必需的行动和活动 (确认该做的已经做完，怎么确认，通过什么确认，审查项目管理计划中的范围基准)；
（2）确认卖方的工作已通过正式验收，并处置未决索赔;(确认供应商交付的产品已通过验收，并处理采购工作涉及的索赔)；
（3）为向下一个阶段或向生产和/或运营部门移交项目的产品、服务或成果所必需的行动和活动(最终成果做移交)；
（4）总结经验教训并存档；
（5）收集关于改进的建议；
（6）测量干系人满意程度；
接下来
（7）庆功会；
（8）释放资源；

• 合同收尾与行政收尾
  

八、PMP考试要点

1. 看到“新项目”、“项目经理权力责任”——选项中找“项目章程”
2. 看到“是否值得投资”——选项中找“商业论证”
3. 看到制约因素(或假设条件)——选项中找 “假设日志”
4. 看到“纠正措施、预防措施、缺陷补救、更新”——选项中找“变更请求”
5. 看到“计划制定完成”、“章程制定完成”——选项中找“批准”
6. 看到“版本问题”——选项中找“配置管理”
7. 看到“新任项目经理”——选项中找“项目章程”
8. 看到“项目完成”或“终止”——选项中找“经验教训”
9. 看到“某某人很有经验”——选项中找“专家判断”
10. 看到“考虑所有意见”、“既定决策流程”——选项中找“引导”
11. 看到“分享知识”——选项中找“信息管理”