注：加粗部分均为考点

一、预测型

4. 项目整合管理

三大基准：范围、进度、成本。围绕的核心是质量。（三大基准敲定了，项目的目标才能定下来，因为预测型的项目目标一定要明确才能开工）
【要做什么】
^
||
|| 沟通：协同这些人，将目标和实现之间协同
||
ˇ
【谁来做】
需要人来完成，资源的三大来源：资源（内部的团队成员）、干系人（更多指的是外部客户等）、采购（外包）
风险一直贯穿基准的全程。
这些就对应的是项目管理过程中的十大知识领域。

启动：

4.1 制定项目章程

作用：发起人（sponser）签署发布章程，明确项目的总体目标，发起人一般是个乙方的领导。
考点：

• PM可以参与编制。
• PM未被授权，不开工。
• PM更换，修改项目章程。

输入：

1. 商业文件：
   商业论证：启动前想了解项目，看商业论证。即论证有没有利益可图，有没有必要做，是一个可行性研究报告。
   效益管理计划：跟踪性文件
2. 协议：合同
3. 事业环境因素
4. 组织过程资产

项目章程或商业论证要修改，PM报项目发起人。

项目章程中的内容：
（1）项目总体要事先的目标：
3高：高层级需求，高层级的可交付成果，高层级的风险
2总：总体进度，总体成本
1标准：成功标准
（2）任命项目经理
（3）项目章程经启动者签字，项目即获批准

项目经理参加的越早越好，可以参加项目章程的编制。
项目章程有，但未发布，项目经理就没有职权。【注意流程高于一切】
项目经理走了，更新项目章程。
发起人走了，更新干系人登记册。

启动阶段开的是项目处初始化会议。

规划：

4.2 制定项目管理计划

作用：（1）明确基准；（2）明确项目管理的各种方法论；验收标准
总体/宏观的一些表述，找项目章程；验收标准这种比较细的要看项目管理计划。

开工大会（Kickoff Meeting）/启动大会：（1）明确团队成员的角色和职责；（2）明确方法论。旨在传达项目目标、获得团队对项目的承诺，以及阐明每个干系人的角色和职责。在规划阶段的末尾召开，标志着项目正式由规划阶段进入了执行阶段。

项目管理计划主要由项目经理牵头，带领大家来共同编制，所以团队成员也参与计划的编制。

执行：

4.3 指导与管理项目工作

变更请求的4种类型：
** 1. 纠正措施：目前和计划不符，但还没造成恶果（恶果比如质量缺陷、客户投诉）
2. 预防措施：目前没错，避免将来出错
3. 缺陷补救：已造成恶果
4. 更新：外部因素引发变更**

PMIS属于事业环境因素。——PMIS就是项目管理信息系统，是公司内部用来进行项目管理所用的工具，属于内部事业环境因素中的信息技术软件。

变更请求的三个状态：变更请求、批准的变更请求、确认的变更。

可交付成果的三个状态：可交付成果（刚生产出来）、核实的可交付成果（内部测试通过后对应8.3控制这质量）、验收的可交付成果（用户测试后对应5.5确认范围）。

4.4 管理项目知识

作用： 总结经验教训，边做边总结。
显性知识：可以言传，使用文字、图片或数字进行编辑的知识。显性知识
隐性知识：没有经验或体会不会懂的知识。

监控

4.5监控项目工作

作用：找到偏差，纠正偏差

4.6 实施整体变更控制【都是重点】

CCB是什么：CCB（Change Control Board，变更控制委员会），包括（1）项目发起人（乙方领导）（2）客户（3）项目经理。

整体变更控制流程步骤：

1. 书面记录变更请求
2. 评估变更影响
3. 准备备选方案
4. 与干系人沟通讨论
5. 决策（CCB或PM）
6. 更新变更日志、基准/项目文件
7. 通知干系人
8. 协调团队开工

有变更，走流程，享受幸福人生。

考点1：书面记录变更请求：变更请求的第一步就是书面记录变更请求/正式提出变更请求。（书面指的是记录在变更日志中）（目前邮件发送在PM中还不算正式的沟通渠道）
变更请求第一步是啥，看选项，有书面选书面，没书面选评估。
考点2：当基准（范围、进度、成本）有变化时需CCB进行审批，若变更不涉及基准，则由PM项目经理直接决策即可。
考点3：提出和提交的区别：CCB审批的时候有个会议——CCB会议或叫CCB大会，是审核变更的。不是提出（submit）请求，而是提交（issue，呈上）请求的。
考点4：CCB通过后，接下来先更新项目管理计划，然后再更新基准。
考点5：变更日志的更新：变更通过后要更新变更日志，不通过也要更新，需要写下来否决变更的理由。
考点6：验收：在验收化解，有人提出重大变更请求怎么办？——走流程（至于通不通过还交由CCB审批决定）
考点7：验收完成后，有人提出小的变更请求，怎么办？——请客户将变更请求当做一个新项目提出。（因为验收完成后欧PM都卸任了）
考点8：项目做到一半，内部团队人员相处了一个变更请求不再原先范围中，该请求对客户有重大的好处，怎么办？——走流程

收尾

4.7 结束项目或阶段

• 先5.5确认范围，进行用户测试、验证，再进入4.7结束项目或阶段
• 想要长期协作，进行客户满意度调查。
• 收尾不总结等于没收尾。
• 4.7结束项目或阶段流程：
  （1）获得项目正式验收。开验收会
  （2）产品移交客户，同时做客户满意度调查（目的是与客户保持长期合作）
  （3）财务收尾、采购收尾
  （4）经验教训总结【必须要做经验教训总结】
  （5）文件归档，行政收尾
  （6）团队解散
  收尾结束后就没办法再响应用户的请求了，因为团队已经解散了。
  

5. 项目范围管理

启动：/

规划：/

5.1 规划范围管理

作用： 形成需求管理计划和范围管理计划这两个方法论。
方法论：

5.2 收集需求

作用：全量收集不筛选， 手机玩需求写（1）需求文件（2）RTM需求跟踪矩阵。
收集需求的工具：
访谈：一对一谈话，也可用户获取机密/私密信息。
专家判断：
头脑风暴：只管收集，不管需求优先级排序。用来产生和收集对项目需求与产品需求的多种创意的技术。
名义小组：公开投票技术
标杆对照：与其他可比组织进行比较，以便识别出最佳实践。
文件分析：比如分析法律规范等。
观察与交谈：旁站式/参与式。
问卷调查：关键词：多、快、省
德尔菲技术：关键词：匿名、多轮、帮助专家达成一致、所有投票统一交给主持人
焦点小组：一对N，召集相关方和主题专家，主题专家通常是受过训练的主持人，让大家聚焦在主题上。
亲和图：关键词：分类、总结、归纳
原型法：敏捷中用的多。
引导：可解决跨职能部门、相关方之间的差异。
投票：投几个手指。
输出：
（1）需求文件（word版）
（2）RTM需求跟踪矩阵（excel版）：
将需求和可交付成果对应/关联起来；
确保所有得到批准的需求在项目收尾时都能被交付；
RTM是不断更新的，目前填不上，后边分解了WBS之后才会更新

5.3 定义范围

作用：将需求翻译成范围，描述产品、服务或成果的便捷和验收标准。

代表性工具：产品分析TT：将需求翻译成产品或可交付成果。

项目范围 = 产品范围（最终交付的内容） + 管理工作（完成项目需要做的事）

输出：范围说明书

项目范围说明书：
（1）产品范围描述（最终交付什么）
（2）验收标准（达到啥质量）
（3）可交付成果（针对管理类的文档交付）
（4）项目的除外责任