4. 项目整合管理
PM必须对整个项目承担最终责任
系统很复杂，所以要整合，所以使用自动化工具来整合，使用可视化管理工具，项目知识管理，增加PM的职责，混合型的方法来管理项目
4.1制定项目章程
定义 1.批准项目 2.授权PM 3.使用组织资源
作用 明确项目与组织战略之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺
输出 项目章程 假设日志
项目由项目以外的实体来启动。多阶段项目中需要项目章程来正式启动一个新阶段，也就是说一个项目可以有多个阶段，每个阶段也可以当一个新的子项目，那么也就可以有多个项目章程
批准 通常是发起人来批准，哪怕没有发起人，没有PMO,也要有人批准，总之需要高级管理层批准
授权 授权PM作为项目的执行责任人
支持 项目启动者应该具有一定的职权，能为项目提供资金、提供资源
ITTO
输入 协议当合同来处理， 事业环境因素 和 组织过程资产 理论上来说49个过程都可以来当输入的。
工具与技术 专家判断 专家可以是人也可以是组织 理论上49个过程都可以拿来用，焦点小组 针对某一个主题来讨论 大家的立场是一致的，访谈 一对一 一对多，冲突管理 这是一个很广义的概念 有正反两个方面 推广正面 避免负面，引导 将大家引导到一个方面 达成一致 最后要得到一个一致的结论或结果；会议管理 有章法 有流程的开会 看谁能参与 开会之后形成一个会议纪要 希望是一个有效的会议 会议 启动会比较重要
输出 项目章程★ 内容重要，假设日志
项目章程内容★★
内容：项目目的（要赚多少钱，要为企业创造什么样的价值）、目标（可量化的），项目成功、退出标准，高层级信息（粗略的、宏观的、大致上的信息，9个子知识领域都能写进去），项目经理及职权（谁是PM，权力有多大），章程审批信息（怎么审，谁来审，流程）
审批：发起人/PMO/高层级管理（指导管理委员会）
作用：开始项目，授权
假设日志（包含所有假设条件和制约因素）
假设日志——假设条件（个人主观认为可行/成立，假设就是不确定，就是风险）渐进明细的文档（随着时间的推移慢慢可以确定下来）
假设日志——制约因素 事先都知道，不能改变、不渐进明细，只能遵守的因素，限制团队做出选择(比如疫情期间PMP考试，要做核酸检测)
项目启动会——imitate meeting 启动阶段结束，规划阶段之前。项目章程批准之后召开，与关键相关方一起，发布项目章程，任命项目经理，介绍项目章程内容；与关键相关方达成一致，并使得PM能够获得关键相关方的承诺★。
4.2制定项目管理计划
定义 定义、准备和协调项目计划的所有组成部分
内容 生成一份综合文件，用于确定所有项目工作的基础及执行方式
输出 项目管理计划（全员参与）
制定项目管理计划的原则 滚动式规划方法，必须明确编写计划的截止日期；需要主要相关方（这个人必须有权力，比如客户、发起人等等）的批准；变更控制；所有相关方参与，PM起总负责和整合的主要作用
ITTO
输入 项目章程 其他过程的输出（9个子计划）
工具与技术 核对单（用于检查的清单，checklist，基于历史的清单，是组织过程资产，发现缺少的，可以更新）
输出 项目管理计划（PM经理先写）
项目管理计划内容★ 9（9个子计划）+3（需求、变更、配置）+3（至少有范围、进度、成本基准）+1（绩效测量基准）+其他 。需求很重要，需求定义了范围的边界，所以要有需求管理计划来指导工作；项目中变更无处不在，所以变更很重要，同样需要一个计划来指导变更的流程；变更多，所以肯定有很多不同版本的文档，配置就是要记录所有版本信息等等。
项目管理计划 项目文件 讲义P76 帮助巩固知识点
基准 范围基准+进度基准+成本基准——>绩效测量基准PMB 1、需要高级管理层（发起人）和主要项目相关方批准 2、用来测量绩效 3、基准的变更，只有CCB才有权，PM无权 4、当前的基准指最新版本的项目计划
- CCB 变更控制委员会 临时的组织 都是一些有权力的人：可以是发起人、客户、PMO、项目集经理等等
计划得到审批之后，执行之前有个很重要的会议
★★开踢（开工）会——KICK-OFFMEETING 开会的目的：1、传达目标（传达给相关方） 2、获得承诺 （团队成员的承诺）3、阐述每个相关方的角色和职责
批准 项目管理计划提前拿到批准，不然怎么在会上说呢
共识 获得大家的一致认可
加油 启动会结束了，就进去执行阶段了，任何对计划的修改都要走完整的变更流程，因为有基准呀
如下思考：
开踢会的时候有团队了 启动会的时候还没有团队
开会之前就拿到批准了
这个会议是不是必须得开？不是：比如小型项目，从头到尾都是那3~5个人，就没有必要来了，他们早就知道了
假如，发起人、领导有事来不了，还要开会吗？ 要开
延期开？还是按计划开？ 按计划开
人不来怎么办？ 可以会前、会后可以去找他们，单独沟通，一定要获得他们的反馈，获得他们的承诺
项目中的主要会议 相关方识别会 ——> ★项目启动会 ——> 项目规划会（制定计划的时候开多次会议，开让大家达成一致）——> ★★项目开踢会 ——> 状态审查会（汇报绩效的，把工作绩效报告拿到会上给领导们汇报）——> 变更控制会 ——>★项目收尾总结会（总结经验的）
4.3指导与管理项目工作
定义 执行项目管理计划中确定的工作，并实施已批准的变更
作用 就是做事
输出 ★可交付成果 工作绩效数据（就是原始的测量值，不经过任何加工处理的数据） 变更请求
执行计划过程中 管理团队 使用资源 执行计划 看绩效 数据收集 记录风险，分析，规划应对措施 处理变更
ITTO
输入 计划VS实施批准的变更 先按计划去做，如果有变更，按已批准的变更修改计划，再按计划去做，如此循环 ； 项目文件
工具与技术 项目管理信息系统 粗暴理解为 软件 来帮助我们管理项目 还有：变更控制系统 配置管理系统 工作授权系统
- 工作授权系统 可以想想红绿灯的例子 （正确时间、正确顺序、做正确事）在正确的时间，按照合理的顺序，来开展我们的工作
输出 问题日志 发现问题，先记录下来 ；强调指导与管理项目工作过程中会出现大量问题，避免未来再犯这个问题
思考：
在启动过程，在规划过程组发现问题记录到哪里？ 记在问题日志中
例 风险登记册在49个过程 都可以拿来指导工作
输出 可交付成果★★ 可交付成果（4.3指导与管理项目工作）能不能直接给客户做验收，可以，但不好，最好先做一个内部的验收 内部QC核实（8.3控制质量） 核实的可交付成果——>给客户验收（5.5确认范围），变成验收的可交付成果——>（4.7结束项目或阶段）移交的可交付成果
输出 工作绩效数据 干了多少活，花了多少时间，花了多少成本 包括：KPI 计划开始与完成日期 变更请求数量 缺陷数量 实际持续时间
输出 变更请求 有4种：1、预防措施 （针对未来的工作，避免发生偏差） 2、纠正措施 （针对已经发生的偏差） 3、缺陷补救（针对的是成果） 4、更新（针对的是文档）
1和2 针对绩效
3 针对成果 服务 产品
4 针对文档
输出 项目文件更新 包括但不限于 活动清单、风险登记册、相关方登记册、需求文件、假设日志（有33个呢）
4.4管理项目知识
定义 使用现有的知识，生成新的知识，实现项目目标，并帮助组织学习
内容 利用已有的知识创造改进项目成果，使用当前项目创造的知识可用于支持组织运营和未来的项目或阶段
输出 ★经验教训登记册（无处不在） 项目管理计划更新
知识管理惯贯穿项目全过程
显性知识 记录下来的知识
隐性知识 大脑里的知识，难以明确表达，如经验、信念、洞察力等等
误解一 知识管理只是将知识记录下来用于分享（记录下来的知识就是显性知识，那隐性知识怎么办？所以不对）
误解二 知识管理只是在项目结束时总结经验教训，以供未来项目使用（在整个项目生命周期中定期总结，持续改进）
隐性知识的传递 通常经由人际交流和互动来分享
知识管理 联合使用知识管理工具技术（用于人际互动）以及信息管理工具和技术（用于编撰显性知识）来分享知识（显性和隐性）
ITTO
输入 根本没有必要记，因为项目中所有的东西都可以拿来学
工具与技术 知识管理 信息管理 人际关系与团体技能（软技能）
知识管理 人际交往 分享 ；会议、人际关系适用于隐性知识的分享
信息管理 项目管理信息系统（PMIS）（软件）：适用于显性知识的分享
思路：
隐性知识显性化（虽然难，但还是要想办法记录下来）；显性知识体系化（让人愿意看）、显性知识隐性化（学到头脑里）；例：想想PMBOK怎么来的
知识管理最重要的环节是营造一种相互信任的氛围，激励人们分享知识或关注他人的知识
输出 ★经验教训登记册 最后放在组织库中——>组织过程资产更新
- 经验教训登记册 整个项目期间，全员参与 ；在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分 ；最终的目的是为了企业
4.5监控项目工作
监控就要看绩效了，这也是一个定期开展的工作
定义 跟踪、审查和报告整体项目进展，和项目管理计划做对比
目的 让相关方了解项目状态（当前状态、未来状态）
输出 变更请求、工作绩效报告
监控项目工作过程涉及内容 1、把项目实际绩效和项目管理计划进行比较 2、找到解决措施 3、及时更新项目绩效报告 4、做出预测，未来的绩效是什么样子，能采取什么预防措施
输入 ★工作绩效信息
思考逻辑如下：
指导与管理项目工作——>输出很多原始的绩效数据——>然后放在9个子知识领域的控制过程来做分析——>看看当前数据和计划有没有偏差，若果有，看看偏差在不在可接受范围内（控制临界值）——>分析原因（有没有偏差，偏差有多大，为什么会有这些偏差：这就是工作绩效信息了）——>PM汇总成工作绩效报告（包含1、绩效信息，2、预测信息，3、问题，4、风险，5、解决措施）——>给关键相关方
输入 ★2个报告+2个预测 质量报告 风险报告 进度预测 成本预测★
工具与技术 ★ 挣值分析 偏差分析 根本原因分析 备选方案分析 成本效益分析 趁势分析★ 决策
★6个分析工具：
挣值分析：绩效怎么样？
偏差分析：有没有不一致？
根本原因分析：原因是什么？
备选档案分析：都能如何解决？
成本效益分析：怎么解决好？
趁势分析：未来？
最终形成了工作绩效报告。
工具与技术 决策
一致同意 全票通过
大多数原则 50%以上同意
相对多原则 40%、30%、20%、10%，没有超过50的，那就选择一个相对多的
输出 ★工作绩效报告
下面都是工作绩效报告里的东西：
汇编工作绩效信息，不是直接抄，需要综合6大制约因素来考虑、平衡
向关键相关方报告
燃尽图★ 讲义P90 来分析项目当前进展，剩余工作的情况
缺陷直方图
合同绩效信息
风险情况概述
挣值图表和信息
趁势线和预测
输出 更新
项目管理计划更新
项目文件更新
ITTO
4.6实施整体变更控制
定义：实施整体变更控制是审查所有变更请求、审批变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程
目的：确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更往往会加剧整体项目风险
输出：批准的变更请求、变更日志
实施整体变更控制涉及内容 PM对此负最终责任，项目的任何相关方+任何时候都可以提出变更请求；所有变更请求都必须以书面形式★记录，并纳入变更管理和配置管理系统中；记录在案的变更都必须有责任人（CCB）批准或否决；
变更控制委员会 必须要涉及到基准的变更才需要找CCB，通常会动用管理储备以应对变更。
CCB的组成：发起人、PMO、FM、客户、供应商
功能：是对变更做决策的，不是帮忙分析问题的，分析问题是PM的事
控制：所有的变更都需要实施整体变更控制，但不是都需要提交CCB，基准内的不用，PM决定就行了
ITTO
输入：变更请求★（书面的）、工作绩效报告
工具与技术：变更控制工具；决策：独裁型决策制定、多标准决策分析；
配置管理关注的重点是结果；变更管理关注的重点是过程。
配置管理：1、识别配置项；2、记录；3、定期核实与审计（持续跟踪）。总之就是对结果做管理；
★变更控制工具，就是如下的8个变更控制流程；
识别变更
记录变更（记录到变更日志）
综合评估（这里要考虑6大制约因素、相关方的满意度、一定要接着团队一起评估）
考虑施加影响（有利于项目，对提出者施加影响；不利于项目，对审批人施加影响）
提交审批
批准或否决变更
更新（被否决，更新变更日志；被批准：更新变更日志、计划或文件）
通知相关方 （团队等）
输出：批准的变更请求、变更日志、项目管理计划更新
- 项目管理计划更新 ★对基准的变更,只能针对今后的情况,而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性+完整性★。基准发生变更，只能立新基准，而不能覆盖原来的基准。
变更处理应对原则：不论什么时间变更，都得走流程。
计划执行前（验收前）：变更影响大：走流程；小：也走流程。
后期或收尾（验收完）：影响大:可以立新项目；小：1、通常建议用户取消(万一搞不好，有风险)；2、在运营中解决这个问题。（前提是：千万不要直接的拒绝客户,而是提建议）
4.7结束项目或阶段
定义：终结项目、阶段或合同的所有活动的过程。
内容：存档、释放资源等
输出：产品移交、最终报告、组织过程资产更新
原则：想进入结束项目或阶段有一个前提：客户一定要正式★验收通过。（为什么是正式，因为要签字）
进入结束 阶段3种情况：1、正常结束；2、内部：发起人/组织宣布结束；3、外部：客户/市场决定结束。---> 行政收尾★★（调查原因等）
ITTO
输入：所有的东西都可以拿来更新存档
工具与技术：数据分析：回归分析（看质量那章）、趋势分析、偏差分析
输出：最终产品、服务或成果移交；最终报告
- ★最终报告★ 与工作绩效报告的区别： 项目阶段关口或收尾的时时候，最终形成的报告；工作绩效报告是项目过程中定期就整理出来的；在时间点是不一样的。
合同收尾：一般是我和我的供应商来做。在项目阶段结束时乙方找丙方做合同收尾；在整个项目结束时，是甲方找乙方做，那时就是甲方要做合同收尾。
收尾工作一般流程：
- 制定收尾程序;
- 完成合同收尾(如果有)
- 确认工作完成,达到验收标准;
- 已获得产品的验收,并移交
- 收集客户满意度;
- 最终的绩效报告;
- 更新项目记录
- 总结经验教训,归档(存档项目信息);
- 庆功会;
- 释放资源。