# PMBOOK

# 启动

# 1️⃣ 制定项目章程

• 项目和项目经理要名正言顺。

• 制定项目章程，实际上是确立项目的正式地位，授权项目进行使用组织资源的一份文件。

• 由发起人最终发布和批准。

输入

• 一开始项目要立项的时候，能参考的输入是比较少的。
• 只有前期的商业文件，包括商业论证、效益管理计划。
• 如果跟客户签了合同，那么协议也可以作为输入。
• 还有事业环境因素跟组织过程资产。

工具

• 自己不会，可以找经过培训的有经验的那些人 - 专家判断；
• 还有跟别人畅所欲言 - 头脑风暴。
• 需要聚焦在某一个点，比如聚焦在法律领域，或者聚焦在财务领域，让一群人聚焦在某一个点 - 焦点小组。
• 以及访谈，包括开会议、会议管理

输出

• 项目章程
  • 往往跟公司的战略有关，里面包含的内容都是一些高层级的内容。比如说项目的目的、目标、成功标准、退出标准。
  • 还有高层级的范围，总体的里程碑进度计划，总体的预算，高层级的风险等等，这些都是高层级的。
  • 还包括项目经理的职责，发起人的姓名等等。
• 假设日志
  • 把所有的假设条件跟制约因素都写到假设日志里面
  • 假设条件和制约因素分析，实际上就是识别风险的一个工具。

项目经理可以做项目章程，但批是发起人去批。和商业论证是一样的。商业论证项目经理早期可以参与，但是商业论证效益管理计划这种商业文件最终也是由发起人来负责的

# 2️⃣ 识别相关方

• 不是只做一次，要定期去做
• 不管是能够影响项目，还是受到项目影响，都叫相关方

输入

• 早期也可以从项目章程，商业文件，包括协议里面去识别相关方。

工具

• 可以通过问卷调查、头脑风暴、头脑写作这种简单的工具来收集相关方的很基本的身份信息。包括比如性别、年龄、电话、邮箱等等。
• 相关方分析，分析他们的期望态度，得到相关方的评估信息
• 权利利益方格，相关方立方体或者凸显模型，得到分类信息。
  • 权力高利益高的，要重点管理；
  • 权力高利益低的，令其满意；
  • 权力低利益高的，随时告知；
  • 两个都低的，要监督。

输出

• 相关方登记册
  • 身份信息 + 评估信息 + 分类信息
• 变更请求
  • 后面定期的去识别、去更新而产生的

# 规划

# 1️⃣ 规划范围管理

• PMP 是按照预测型的生命周期来讲的。预测型生命周期的特点是范围明确，而且范围是龙头。只有知道范围，才知道进度和成本。
• 所以首先写了两个指南型的计划【输出】，相对来说比较空洞，叫范围管理计划和需求管理计划，告诉我们如何去管理范围，如何去管理需求。

# 2️⃣ 收集需求

输入（找谁收集）

• 找相关方去收集它的输入，有相关方登记册

工具（怎么收集）

• 可以大家一起畅所欲言，头脑风暴
• 可以在信任和保密的环境下去开展访谈
• 可以找同一个职能或者同一个领域的去做焦点小组 focus group。
• 受众多样，地理位置分散，要快速开展统计分析 - 调查问卷
• 自己不会，可以找标杆去学；因为那些榜样和标杆有最佳实践，我们可以识别最佳实践，形成改进意见 - 标杆对照 benchmark
• 做一些决策
  • 德尔菲（专家、匿名、多轮、趋同、消除偏见）
  • 有大多数同意，超过百分之五十的人同意
  • 还有相对多数
  • 独裁型决策
  • 多标准决策分析，从多个维度设置不同的权重，然后去打分分数乘以权重，然后算出总分。
• 收集一堆需求
  • 相亲相近的进行分组 - 亲和图
  • 把所有的信息整合在一起，反映共性与差异，激发新创意 - 思维导图
• 人手一票，体现了人民的意愿进行投票和排序的 - 民意小组。
• 在收集需求时，遇到别人不愿意说或者说不清楚的，可以通过观察和交谈来收集，还可以挖掘隐藏需求。
• 不同部门的跨部门的需求需要协调，要协调相关方的差异，可以用引导这种方法。包括软件开发行业的 JAD，制造业的 QFD，和敏捷里的用户故事。
• 用原型法可以减轻返工的风险

输出

• 需求文件
  • 需求文件里面的需求跟项目章程里面的需求有什么区别？项目章程里面的需求颗粒度很大，叫高层级需求。而需求文件里面的需求叫单一需求。
• 需求跟踪矩阵
  • 帮助我们在全过程去跟踪需求，确保每一个需求都有价值，确保每一个需求都得以实现

接下来要确定，哪些需求我们要做，哪些不在我们的范围内。
还有要明确用什么可交付成果来满足需求

# 3️⃣ 定义范围

• 我们要选取最终的需求
• 然后跟相关方定义好，用什么可交付成果来满足这些需求
• 以及这些可交付成果应该符合什么样的验收标准。

输入

需求文件

工具

备选方案分析，多标准决策分析，引导、产品分析。

输出

范围说明书

• 要交付哪些可交付成果
• 它对应的验收标准应该是什么
• 产品范围描述
• 以及除外责任，防止范围蔓延

接下来，将大的可交付成果，分解成较小的容易管理的组件

# 4️⃣ 创建 WBS

输入

范围说明书

工具

• 自上而下逐层分解，分到 4-6 层，80 小时原则。
• 不能有遗漏，100% 原则
• 分解到最后得到工作包。如果分析到一定的程度，由于信息不明朗，分解不下去，暂时先放在一边，有待进一步规划的叫规划包。
• 每一个工作包都要有唯一的小组来负责，避免职责不清。

输出

• 范围基准
  • 经批准的范围说明书
  • 工作分解结构 WBS
  • WBS 词典 - WBS 里面每一个组件都有一张纸来描述它，然后把这些纸装订起来，像一本词典

范围说明书归于项目文件里，而范围说明书是范围基准的一部分，它为什么不属于项目管理计划呢？
在【定义范围】过程中，输出的范围说明书，它只能叫项目文件。
因为它还没有形成基准，只有在【创建 WBS】过程中，范围说明书、WBS 和 WBS 词典一起获得批准之后，变成了范围基准，它才是项目管理计划的一部分。
就是批和没有批的区别

工作包直接拿来估时间不太合适，因为工作包是由很多活动做出来的。
而这些活动有的可以同时做，有的必须先后做。
所以说要估时间，要想知道进度，只停留在工作包这个层面是不够的。

# 5️⃣ 规划进度管理

• 先做一份进度管理计划
• 接着，把工作包进一步分解分解成活动

# 6️⃣ 定义活动

输入

范围基准

工具

分解，滚动式规划

输出

活动清单、活动属性和里程碑清单

活动与里程碑是不一样的
活动是有持续时间的。
里程碑是一个时间点或事件，持续时间是零，不是活动。

# 7️⃣ 活动排序

工具

• 逻辑关系
  • 紧前关系绘图法 PDM
  • 最常见的是 FS 关系。最不常见的是 SF 关系。
  • 提前量（减号 - ）和滞后量（加号 +）
• 依赖关系
  • 强制性依赖：不能调，是合同规定的或者法律要求的
  • 选择性依赖：可以调
  • 内部依赖：项目内部的
  • 外部依赖：项目以外的

输出

• 考虑到提前量滞后量，考虑到依赖关系，最形成了一张图，叫项目进度网络图
  • 在路径的汇聚点和分支点往往有高风险。

# 8️⃣ 估算活动资源

资源也有时间的限制，先估算资源，才能继续估时间

# 9️⃣ 估算活动持续时间

工具

• 速度快，成本低，但是不准，一般在项目的早期使用 - 类比估算 拍脑袋
• 也是用一些历史的数据，但是不是直接拿过来用，要套公式去算的 - 参数估计 套公式
• 考虑到风险和不确定性，用计划评审技术 PERT - 三点估算，默认用 beta 分布，最悲观 + 最乐观 + 四倍的最可能再除以六
• 除了估算，还要做好储备分析，比如对已知未知风险预留应急储备

活动的顺序有了，活动的持续时间有了，就可以制定进度计划了。

# 1️⃣0️⃣ 制定进度计划

工具

• 关键路径法
  • 顺推找最大，逆推找最小
  • 推完了后，找到总浮动时间是零的这些活动，就形成了项目的关键路径
  • 关键路径实际上是项目的所有路径中最长的那条路径，决定了项目的最短的工期。
  • 总浮动时间体现了每一个活动的灵活性。如果为零，说明在关键路径上，这个活动就不能动了，就不允许延期了。
  • 自由浮动时间比总浮动时间更加严格，是不影响任何一个紧后活动的最早开始。

  关键路径法制定的进度计划，不一定切实可行，因为没有考虑到资源的约束。用了关键路径法，就必须要用另外一个工具。关键路径法的黄金搭档，即资源优化。如果发现资源被过度分配，资源负载过高，就要做资源优化了。

• 资源优化
  • 资源平衡，会导致关键路径的改变，一般是延长
  • 资源平滑，是在浮动时间里面做调整，但不一定能实现所有的优化
• 假设情景分析、模拟等

等时间估算完成后，发现项目排下来需要三十天，但是合同早就签了，合同里面要求的是二十八天，因此需要压缩进度

• 进度压缩，在不缩减范围的前提下缩短工期
  • 赶工
    以最小的成本增加来压缩进度。加班加人加急，花钱买时间，一定会导致成本增加。
  • 快速根进
    把原来顺序进行的，改成部分并行，调整的是逻辑关系，那么会导致风险的增加。

输出

• 进度基准
  • 一个经批准的进度模型
• 从进度基准里面还可以导出各种各样形式的进度计划
  • 向客户去汇报的最常用的是里程碑图
  • 向管理层去汇报进展，用横道图或称甘特图

进度搞清楚了，接下来要估算成本，是对项目成本做一个近似的估算

# 1️⃣1️⃣ 估算成本

输入

进度计划：有活动，活动持续时间，包括资源

工具

专家判断，类比估算，三点估算
最准的叫自下而上的估算

输出

• 成本估算
• 估算依据

估算还需要获得批准，建立一个经批准的成本基准。

# 1️⃣2️⃣ 制定预算

工具

• 成本汇总
• 管理储备分析
• 历史信息审核
• 资金限制平衡

输出

成本基准，里面包括应急储备，但不包括管理储备。

成本基准加上管理储备，就是项目的资金总需求。

以上为范进成，接下来要规划一下质量

# 1️⃣3️⃣ 规划质量管理

• 概念

  • 质量和等级的区别

  • 预防和检查的区别

  • 属性抽样和变量抽样的区别

  • 公差和控制界限的区别

  • 五种质量管理水平。最差的让客户发现问题，然后是 QC 发现问题，然后 QA 管过程，然后把质量融到计划 QP，包括形成一种组织文化。

  • 客户满意是指符合要求、适合使用

  • 持续改进，提供一些小的改进来实现最终一些大的改进。

  • 跟供应商互利合作的关系

  • 管理层的责任，八五一五原则

• 规划质量定标准

  • 要明确的说清楚项目会符合什么样的标准。
  • 要说清楚将如何证明将来会符合这样的一个标准。

工具

• 不会做，可以看一下别人做的好的是怎么做的 - 标杆对照。
• 规划将来如何达到这个质量标准，采取什么样的质量活动，打算花多少成本，又能带来多少收益，要做成本效益分析。
  • 质量成本分为：
    • 一致性成本，包括
      • 预防成本：培训、文档化、可靠的设备
      • 评估成本：检查测试、破坏性测试
    • 非一致性成本，也叫失败成本和曲线成本，包括
      • 内部失败：自己发现的
      • 外部失败：客户发现的
• 流程图
  • 显示整个项目的步骤、流程或者分支。
  • 可以协助了解过程，然后发现容易出现问题的地方。一旦发现容易出问题的地方，就可以把它纳入到将来要检查的部分

输出

• 质量管理计划
• 质量测量指标

除了质量要规划，资源也要规划。

# 1️⃣4️⃣ 规划资源管理

工具

怎么去明确团队的角色和职责？

• 可以借助 层级型的
  • 工作分解结构 WBS
  • 组织分解结构 OBS 来明确高层级的角色和职责
• 可以借助 矩阵型的
  • 责任分配矩阵
    • 可以高层级的来表示每一个工作包由哪一个小组和部门负责
    • 还可以细化到每一个活动由哪一个人来负责，如 RACI 矩阵，每个活动只可能有一个 “A（负责）”

输出

• 资源管理计划，包括
  • 团队的角色职责、职权、能力要求
  • 项目组织图来显示汇报关系
  • 培训计划或者培训策略
  • 认可和奖励计划，在什么时候用什么方式来给予认可
• 团队章程，也叫基本规则
  • 应该由团队来做，最起码也要参与团队章程的制定
  • 它的作用是减轻误解，提高生产力。
  • 还要不断的去更新，特别是有新成员加进来的时候

# 1️⃣5️⃣ 规划沟通管理

• 沟通是指信息的交换，怎么去收发信息
• 沟通是基于相关方的需要去量身定制的，而不是定一个原则让大家来遵守

工具

• 沟通需求分析
  • 分析相关方，看需要什么信息，用什么类型，用什么格式
  • 计算沟通渠道有几条，看总共有多少人，那么 n 乘以 n 减 1，再除 2。
• 沟通技术
• 沟通模型
• 沟通方法
  • 交互式 / 互动式沟通：快递当面交给你。 实时多向的，效果是最好的。
  • 推式沟通：快递往水表箱里面一放就走，不管你有没有收到。 发送方直接往那一推就结束了就不管了。
  • 拉式沟通：快递放在菜鸟驿站，需要自己去拿。 有很多信息放在网站上，要自己去查。适用于受众很多，信息量很大的时候。
• 沟通风格评估
  • 评估相关方喜欢、偏好用什么样的方式
  • 适用于不支持项目的相关方。

输出

• 详细的沟通管理计划
  • 沟通管理计划有沟通，明确包括了
    • 相关方的沟通需求，需要什么信息，用什么语言，用什么格式，用什么，详细程度
    • 沟通的实现和频率
    • 谁负责发送信息，谁应该接收什么信息，谁负责发送保密信息
    • 通用术语表
    • 沟通出问题的时候，需要问题升级程序。

# 1️⃣6️⃣ 规划风险管理

风险管理计划

• 事先说好风险应该怎么管，做好该做的准备工作，比如
• 风险分解结构 RBS
• 概率和影响的定义
• 概率和影响的矩阵
• 相关方对待风险是什么态度，相关方的风险偏好

# 1️⃣7️⃣ 识别风险

需要所有的相关方都参与识别，团队的参与很重要，不是一次性的，是一个迭代的过程

工具

• 结合 RBS 做头脑风暴、访谈
• 把历史的项目中存在的风险拿过来作为核对单，但要保证不能用核对单来取代风险识别工作，因为每个项目都是独特的
• 根本原因分析
• 假设条件和制约因素分析
• 文件审查
• SWOT 分析，通过优势来识别机会，通过劣势来识别威胁
• 用 RBS 的底层来做提示清单

输出

• 风险登记册，包括
  • 风险潜在的责任人
  • 潜在的应对方法
• 风险报告

# 1️⃣8️⃣ 定性风险分析

• 关注风险优先级，明确每一个风险具体的责任人是谁，并写入风险登记册

工具

• 风险概率和影响评估
  • 每一个风险都要根据概率和影响的定义来计算打分
  • 概率多少，影响多少，然后概率乘以影响最终的总分是多少。
  • 每一个风险都要算，算完后对风险进行优先级排序
  • 概率低、影响低的低优先级风险，不能把它删掉，要把它放到风险登记册的观察清单，也要监督的。
• 概率和影响矩阵
  • 在深灰色区域是高危风险

定性风险分析做完了之后，如果能定量的就定量。有的风险是不能量化的。

# 1️⃣9️⃣ 定量风险分析

定量不是必须要做的。

工具

• 敏感性分析 - 龙卷风图，分析最大的潜在影响
• 决策树分析 - 计算预期货币价值，在备选方案中选中最佳的，算利润时选择最大，算成本时选择最小

# 2️⃣0️⃣ 规划风险应对

定应对策略

工具

• 威胁应对策略
  • 上报
  • 规避：不希望这个风险发生，或者希望项目免受风险的影响，将概率或影响降到零
  • 转移：找第三方买保险
  • 减轻：降低风险发生的概率和影响，如原型开发、冗余部件
  • 接受：分主动接受（应急储备）和被动接受（躺平）
• 机会应对策略
  • 上报
  • 开拓：想百分之百抓住这个机会时，用组织最有资源的最资深的人，或用全新的技术
  • 分享：找第三方成立合作企业，要建立合作伙伴关系啊，去分享收益
  • 提高：提高也是增加资源，跟开拓的区别是只增加普通的资源，来缩短工期等
  • 接受
• 应急应对策略
  • 在有预警的时候可以做的，比如应急计划、弹回计划（Plan B）。
• 备选方案分析，确定哪个应对方案最为适用
• 成本效益分析，要经济可行

做完上述应对，会对原本的范围进度成本基准造成影响

输出

• 变更请求
• 项目管理计划更新

有些东西自己不生产，需要采购别人的

# 2️⃣1️⃣ 规划采购管理

输入

• 组织过程资产
  • 合格的供应商清单，可以缩短招标的过程，或者简化卖方周旋的过程。
  • 合同的类型

工具

• 自制或外购分析，谁划算用谁
• 供方选择分析

输出

• 采购管理计划
• 甲方的招标文件
• 采购说明书 SOW
  • 要清楚的说明需要采购哪些东西，包括数量、质量、性能要求、履约地点等等，让潜在的供应商能够自己判断是不是能够提供这些东西。
• 供方选择标准
• 独立成本估算

# 2️⃣2️⃣ 规划相关方参与

• 相关方当前是什么参与程度？我们又期望它是什么参与程度？

工具

• 相关方参与度评估矩阵，显示当前的和期望的差距。
  • 用 C 表示当前的 current ，用 D 表示期望的 desire
  • 如果 C 和 D 不在一起，就需要通过一些努力来弥补这些差距

输出

• 相关方参与计划
  • 定义了怎样来提高相关方参与度的策略

# 2️⃣3️⃣ 制定项目管理计划

• 以上所有计划和基准，拿过来用订书机装订在一起，形成了一份综合的文件，即项目管理计划。

工具

• 核对单
  • 由于子计划和基准特别多，为了避免遗漏，用一个清单，每整合一个就打一个勾
• 开工会议 kick off
  • 规划阶段做的最后一个会议和最后一件事。
  • 传达目标，阐明角色和职责，获得承诺，主要的相关方要一致认可这份项目管理计划。

# 执行

招兵买马

# 1️⃣ 招兵 获取资源

• 尤其是人力资源，因此
  1. 要跟有资源的人去谈判
  2. 如果没有资源，可能会导致项目失败
  3. 在不得已的情况下可以使用替代资源，替代资源可能需要培训

工具

• 先获得预分派给项目的人
  • 在竞标过程中承诺的
  • 在章程中指定的
  • 取决于专有技能的
• 还不够，则要到公司内部去物色，进行多标准决策分析，制定出标准和权重，进行评级或打分，看哪些人比较合适
• 物色的这些人，要么在职能经理在职能部门，要么在别的项目上别的项目上，因此还需要谈判或协商来拉人
• 发现在公司以外的其他地方也可以参与我们的项目，可以用虚拟团队来纳入到项目中。虚拟团队最大的问题是沟通，要注意事先定好沟通规划。

输出

• 项目团队派工单
• 资源日历
  • 这些资源并不是从头到尾都可以用的。有的人只有一段时间在项目上，所以每一个资源都是有档期的。
  • 资源何时可用，可用多久

招兵招过来了，这些人在一起，要想办法把他们打造成一支团队

# 2️⃣ 招兵 建设团队

塔克曼模型

• 大家在一起一开始只能叫形成阶段，相互认识，相互独立，不一定开诚布公。
• 后面还有可能会出现震荡，不同的观点和意见会有一些矛盾
• 然后接下来才会到规范阶段开始协同工作、学习，相互信任
• 然后才能到成熟，平稳高效，组织有序，相互依靠

工具

• 集中办公
  • 非常提倡
  • 实在没有条件，要在一些关键的时间点集中办公
• 团队建设 Team Building，为了让团队成员之间能够更好的协同工作。
• 认可与奖励
  • 通过任何与奖励来体现他们的价值，他们就会获得激励。
  • 马斯洛需求层次，我们奖励要根据不同的人，他处于不同的马斯洛需求层次，要给予合适的奖励。
  • 无形的奖励也是比较有用的
• 培训，减小成员之间的能力差异。
• 360 度全方位绩效考核法，可以从四个指标，比如说个人能力的提高、团队能力的提高、离职率的降低、凝聚力的加强，来判断团队绩效。

有矛盾也要处理

# 3️⃣ 招兵 管理团队

• 管理团队的核心就是发现问题，解决冲突。

输入

• 团队章程

工具

• 冲突管理
  • 冲突管理的解决步骤
    1. 首先要由团队成员自行解决
    2. 然后项目经理提供私下的协助
    3. 接下来实在不行，再用正式的程序，甚至包括惩罚措施。
  • 冲突管理的五种解决方法
    • 撤退 / 回避，从冲突中退退出，推迟解决，推给他人解决
    • 强迫 / 命令，推一方，用来解决紧急问题
    • 妥协 / 调节，部分解决问题，一定程度满意
    • 缓和 / 包容，只是为了缓和关系，问题并没有解决
    • 合作 / 解决问题，最好的方法，综合考虑不同的观点和意见，开放式的对话，合作的态度

# 4️⃣ 买马 实施采购

• 招投评授
  • 发布广告
  • 你有不清楚的，我来组织投标人会议。
  • 你投完标之后，我来评标
  • 然后选定卖方授予合同

招好兵买好马了，接下来根据项目管理计划，去把可交付成果做出来

# 5️⃣ 指导与管理项目工作

• 根据项目管理计划的很核心的执行过程。
• 如果有变更，一定要获得批准，才能作为输入
• 根据批准的变更请求，把可交付成果做出来。

输出

• 可交付成果（还不能交给客户，因为还需要核实）
• 工作绩效数据（是指原始的观察值和测量值）
• 有问题，记问题日志
• 有变更，提变更请求

伴随着执行过程，还要对过程进行管理
预防胜于检查，要看过程的每一步，是否遵守了组织的政策、流程和程序

# 6️⃣ 管理质量

管理质量 QA，管过程

输入

• 质量管理计划
• 质量控制测量结果

工具

• QA 拿着核对单
• 对每一步做质量审计，看是不是都符合组织的政策、流程和程序
  • 质量审计的目标：
    1. 识别（做的好的跟不好的）
    2. 分享（行业的良好实践）
    3. 协助（过程改进，提高生产力）
    4. 积累（组织教育，提供积累）
    5. 确认（已批准的变更请求的实施情况）
  • 审计可以是内审或者外审，可以是事先安排的，或者随机进行的。做这件事情的人叫审计师。
• 根本原因分析
• 过程分析
• 用数据的条形图来显示频率和频次的直方图
• 显示主要原因的帕雷托图
• 显示根本原因的鱼骨图 / 因果图
• 用来分析两个变量之间有没有关系的散点图
• 面向 X 的设计 DFX，考虑到了设计部分。面向成本的设计，就是为了优化成本；面向安全的设计，就是为了优化安全。
• 问题解决的步骤：
  1. 定义问题
  2. 识别问题的根本原因
  3. 选很多的方案
  4. 选一个方案
  5. 去执行
  6. 去验证
• 质量改进方法：PDCA，六西格玛

输出

• 质量报告
• 如果确实有地方需要调整的，可能会输出变更请求

# 7️⃣ 管理沟通、管理相关方参与

• 引导参与，获得知识，谈判沟通，管理期望，预测和处理相关方的问题和风险，澄清和解决问题，管理相关方参与

# 8️⃣ 管理项目知识

• 做好显性知识和隐性知识的传递

# 9️⃣ 管理风险应对

• 要让风险责任人做好实施风险应对

以上所有的工作都是为了顺利的把可交付成果做出来。
可交付成果做出来之后，不能直接交给客户，自己内部要先核实，做好 QC 控制质量。

# 监控

# 1️⃣ 控制质量

• 控制质量 QC 就是看可交付成果是不是符合质量标准，或者符合质量测量指标。

输入

• 可交付成果
• 质量测量指标

工具

• 检查（最典型的工具）
• 测试
• 核查表
• 核对单
• 控制图
  • 反映过程是否稳定，是否具有可预测的绩效
  • 在均值的正负三个西格玛的位置有两根线，叫控制上下线。
  • 如果超出控制线或者连续七点在均值的同一侧，那么就是失控了，要去查原因。
  • 在控制线以外还有两根线，这是客户可以接受的范围，这个叫规格上下限。规格线中间的叫公差。

输出

• 核实的可交付成果
• 质量控制测量结果
• 如果可交付成果质量是不合格的，是有缺陷的，应该了解原因，然后提出变更请求

控制质量核实了没问题了，才能够交给相关方或者客户和发起人去验收。
验收可交付成果的过程叫确认范围。

# 2️⃣ 确认范围

• 把核实的可交付成果变成验收的可交付成果

• 验收标准是可交付成果的验收标准

• 每一个可交付成果都验收了，那么整个项目就可以开一个形式的验收会议来做一个收尾，即结束项目或阶段

• 如果没有通过验收，则要查原因，走变更流程，走缺陷补救

# 3️⃣ 其他各种监控

• 在整个项目做的过程中，要对工作绩效进行监控，把工作绩效数据变成工作绩效信息

  • 控制范围，是多做了还是少做了
  • 控制进度，进度是快了还是慢了
  • 控制成本，成本是节约了还是超支了
  • 监督风险
  • 控制采购
  • 监督沟通

• 再通过监控项目工作这个过程，把信息进行整合，整合成报告，然后跟相关方去汇报

• 项目中所有的变更都必须要经过变更流程去处理，专门处理变更的叫实施整体变更控制过程。

# 收尾

• 结束项目或阶段

• 正常收尾

  1. 要开一个会议，获得整个项目的验收
  2. 接下来移交，把最终的产品服务成果移交给相关方
  3. 总结经验教训
  4. 更新组织过程资产
  5. 归档好
  6. 释放资源，收尾的最后一步，完成的标志
  • plus
  1. 客户满意度调查，或者叫相关方满意度调查
  2. 庆功会

• 提前终止

  1. 了解项目提前终止原因
  2. 把已完成和未完成的可交付存款移交给他人

# 敏捷复习

# 解题思路

# 答题步骤建议

浏览选项

快速浏览选项中的内容，如果能看出选项中大致在说什么，可以缩小选择的范围。

注意问题

快速浏览问题，有的时候问题问得很明确，甚至跟题干没有什么太大的关系。

阅读题干（重点）

找出题干中需要你解决的问题，找出关键字，理解这个题目要让你干什么。

定位过程

这个题目目前在哪个过程，问的是这个过程的输入、工具、还是输出。

好中选优

排除明显有错误的选项，留下没有明显错误的选项。

# 注意题干中的重点描述

找到题目中的关键字、需要或者问题
关键字：额外的、可能、根本原因、是否存在相关关系、新的相关方等等
需要：若要避免这个问题，若要解决这个问题，若要确保
问题：虚拟团队、技能不足、会议礼仪、不遵守变更流程

遇到类似的题目，要根据题目中的关键字、需要或者问题做出选择，针对题目中的重点内容对症下药

# 变更题

• 变更的本质是对项目管理计划（基准）、可交付成果的修改

• 变更往往是出于某种需要，无所谓好与不好；不要看成是问题，也不要看成是风险；

• 我们更多的是关注变更的受控，评估对项目管理计划（基准）的影响，而不是 “担心” 带来的问题或风险对待变更的态度：无所谓 “欢迎” 还是 “不欢迎”，需要变更就变更，但是要受控

• 当题干中出现：新的、额外的、设备变化、工作遗漏、范围蔓延、确保缺陷补救正确、争论要不要变更、等等均属于变更题。

• 变更流程：（了解变更的具体内容或原因，告知变更的流程，避免不必要的变更）

  1. 记录（项目经理书面记录或要求变更提出者提交书面的变更）
  2. 评估
  3. 提交（项目经理提交给 CCB）
  4. 更新
  5. 通知

• 如果获得批准，就必须要去执行批准的变更，如果其他相关方有意见可以重新提交新的变更

• 如果变更没有获得批准就直接执行了，则需要：

  1. 停止不良变更（不是停止整个项目）
  2. 补变更流程。

# 相关方与沟通

• 相关方的管理在于管理人

• 遇到相关方反对、担忧、抵制、威胁、不支持、不参与，事后提出不同意见等等，均属于相关方题

• 如果之前没有识别该相关方：更新相关方登记册，做好相关方分析和分类（权力利益）

• 如果已经识别了该相关方：审查相关方参与计划，或者，管理相关方参与（引导参与，获得支持；谈判沟通，管理期望；处理风险，预测问题；澄清和解决已识别的问题）

• 如果问事先要做好什么：早识别、早分析（相关方分析）、早参与

• 沟通的管理在于管理信息传递

• 信息流传递的问题才是沟通问题：多发少发，没有及时发，看不懂，不是想要的，不方便阅读，虚拟团队的沟通问题，相关方抱在怨沟通不及时，虚拟团队的误解，均是沟通题

• 常见的选项有：审查管理计划、更新沟通管理计划、创建沟通管理计划，以及跟规划沟通有关的工具：沟通需求分析，沟通风格评估等等

• 注意区分，是要你管人，还是要你管信息的传递；人的问题属于相关方知识领域、信息传递的问题属于沟通知识领域

# 风险和问题

• 风险是一种不确定性的事件，有概率发生，发生之后会对项目产生积极或消极的影响问题是当前客观存在的情形，已经对项目产生了影响

• 对于风险来说：

  1. 未来可能发生，
  2. 一旦发生就会有影响

• 对于问题来说：

  1. 当前客观存在，
  2. 已经对项目产生影响

• 风险的题目（大多数风险题，题干中会明确说到 “可能” 带来的影响）

  • 识别到风险：更新（查阅）风险登记册、定性、定量、规划应对、实施应对
  • 发生了风险：已知风险，查阅风险登记册直接应对，如果要用储备，“应急储备”；未知风险：权变，走变更流程，用管理储备。

• 问题的题目

  • 记录问题日志 ，分析根本原因（或评估影响），确定解决方案。
  • 问题解决的完整步骤：
    1. 定义，
    2. 识别，
    3. 方案，
    4. 选择，
    5. 执行，
    6. 验证

# 定位过程，注意 ITTO 顺序

• PMP 中最正规的解题方法就是定位，需要仔细分析：

  1. 这个题目目前在说哪个子过程
  2. 这个题目问的是什么
  3. 根据问题，应该选择输入，还是工具，还是输出

• 注意：如果没有明确地问输入、工具还是输出，要注意 ITTO 的顺序

  • 先审查输入，审查输入其实就是参考输入，
  • 再使用工具和技术，得到所需的输出

# 好中选优，差中选好

• 如果选项中都是符合要求的，选择一个最合适的

• 如果选项中都有一些问题，选择一个相对最合适的

• 排除法

  • 动不动就上报发起人
  • 要求发起人去做事
  • 跟相关方审查沟通管理计划或相关方参与计划
  • 向非 CCB 人员提交变更请求
  • 冲突时只考虑一方的利益，但又不需要强迫
  • 没有走变更，直接修改项目管理计划或基准
  • XX 管理计划没问题，但是直接去更新了 XX 管理计划；比如更新风险管理计划等等