PMP必过

前言

针对这次的备考，有一点点心得，记录一下！

1.只看书是很难通过考试的，得刷题。就好比高中时你掌握了课本上的知识，但你不一定能考满分，因为考试题是灵活的，多变的，只看书掌握不到知识的精髓。

2.学习要注意逻辑性，需要掌握知识整体的框架和做好同类别知识的归类、对比。

3.项目经理要有整体性的思维以及清晰的思路，考试答题的原则也是如此，通常是要选整体性的，即大而全，还有明确知道下一步要做什么，即选最应该、最先做的事。

4.以下内容主要是自己对错题进行的记录，并不是完整的PMP学习资料。

几乎不考纯输入输出的题

一、基础

引论

项目集	项目组合
相互关联、依赖关系 为了获得更大的利益对项目进行协调管理	战略目标、价值最大化、优先顺序、提高资源利用率

工作绩效数据	工作绩效信息	工作绩效报告
实时显示项目的进展	已经发生绩效偏差	便于制定决策、提出问题、采取行动或引起关注

阶段

项目阶段关口，决定是否停留在当前阶段

PMBOK

适用于大多数项目，得到一致性认可

单个项目的管理

责任、尊重、公平和诚实

商业价值

公共利益属于无形价值

生命周期

混合型=预测型+适应型

适应型=迭代型+增量型--每个迭代期都会创建可交付成果，项目团队要持续开展控制范围，发起人和客户要及时对成果进行正式验收

开始项目、组织与准备、执行项目工作、结束项目

项目成功标准

主要相关方和PM就如何评价项目成功达成一致

项目效益管理计划

目标效益、战略一致性、效益责任人

项目运行环境

组织过程资产	事业环境因素
作为项目的借鉴	制约和限制项目
可裁剪、可选择	没得选、只能适应
程序	系统
自己积累的数据库	在外面买的数据库

冲突
我和另一位PM同时需要一位专家-->询问专家意见+和另一位PM沟通
建设性冲突对项目是有益的，需要有适当数量的冲突

相对来说，选择最正确的答案
虚拟团队-->认可文化多样性
项目发生变更-->通知相关方

组织结构

简约型-->决策权高度集中、书面规章制度少，商量着办

混合型-->多个不同层面的项目需要执行、需要不同的技术知识
多部门型，也就是事业部型，每个产品或服务部门就是一个事业部

职能型-->兼顾项目工作和职能工作
矩阵型-->充分利用资源、PM需跟职能经理合作|跨部门的项目
项目型-->PM权利大，对资源有控制权

虚拟型组-->特定时间临时集中办公

项目治理

四个领域：一致性、风险、绩效和沟通

四大职能：监督、控制、整合与决策

发起人  主要作用是提供资金

1.超出PM控制范围的，上报给发起人
比如：公司要把子公司卖了，而子公司还有个未完成的项目，
PM应该与发起人和关键相关方沟通，核实是否继续进行项目

2.尚未获得合同和项目章程、处于项目边界之外的，由发起人领导项目，直到项目正式批准
即：项目未批准、发起人负责

PM
PM是领导项目团队达成项目目标的管理角色，为达成目标的项目第一责任人

PM要服从项目组合经理、项目集经理的要求

PM-->组织项目团队和其他相关方来完成项目工作
发现一个未定义的可交付成果-->需要更新项目章程-->需要发起人的支持
在采购过程中，PM是管理整个采购过程的人，无权签署协议

项目经理发展、维护和培养非正式人际关系更加重要

为实现某个特定目标而开展的一系列活动，只能由一个人来领导-->统一方向

统一命令：人对人

统一方向：人、事对事

系统与组件

系统的功能要远大于各要素的功能之和

系统和组件不能同时优化，某个组件的过分优化会损害系统的整体功能

系统可以实现单个组件无法实现的成果

PMO--常设的永久职能部门

协调跨项目的沟通、为项目提供咨询和指导、制定组织的项目管理规章制度

对所辖各项目共享的人力资源进行管理--就是跨项目的，只管共享资源，独享的就不是跨项目了

支持型

指令型--使用特定的模板

控制型--直接管理和控制

项目经理的角色

领导	管理
关注长期愿景	关注近期目标
需要引导创新	需要正式权力、按流程和计划做事

领导风格

独裁式--容易出错

放任式--对人员容易失去控制、高度创新项目和能力强的人

民主式--决策速度慢，因为要征求大家的意见

交互型=交易+变革+魅力的混合体

过程	协调开展各种项目管理过程
认知	提高自己的知识水平并综合利用各领域知识
背景	了解与项目有关的背景及所需资源并加以利用

某团队专家声明，明天他绝对不会和弄虚做假的人一起上台领奖--回避权力

项目经理已经率先取得了专业资格证，团队成员都以他为榜样，努力学习考取证书--参考权力

二、整合管理

变更

必须是正式的

非法变更-->先停止，然后补变更流程

问题日志

在指导与管理项目工作过程被首次创建

指导与管理项目工作

项目管理信息系统

监控项目工作

对进度预测和成本预测进行综合分析，并把分析结果写入工作绩效报告，确定是否需要采取预防措施

结束项目或阶段过程

行政收尾，包括了财务收尾和法律收尾

合同收尾与每个合同对应，不与整个项目或阶段对应

使用数据分析来分析项目的成功程度并总结经验教训

配置控制	变更控制
关注项目的技术参数	关注项目的绩效测量基准

三、范围管理

规划范围管理-->收集需求-->定义范围-->创建WBS-->控制范围-->确认范围

规划范围管理--创建范围管理计划

定义范围--给项目范围划定边界

确认范围--对可交付成果的验收

控制范围--监督项目和产品的范围状态，管理范围基准变更

变更请求得到批准-->更新项目管理计划和项目文件[如果是更新了范围基准，那么需要更新范围基准的文件，即范围说明书、WBS、WBS词典]

WBS

创建WBS需要使用项目范围说明书

需求跟踪矩阵--确认范围和控制范围

控制账户是PM对项目的管理控制点，以便针对控制账户进行挣值管理，计算相关的指标

名称	产品范围	项目范围
特点	产品、服务或成果所具有的特性和功能	为了交付产品、服务或成果所必须完成的工作

预测型	适应型或敏捷型	敏捷方法
项目开始时定义范围 经批准的范围说明书+WBS+WBS词典=范围基准[范围基准在项目管理计划中] 通过正式变更控制程序才能进行基准变更	项目开始时无法确定范围，需要多次迭代 需要相关方持续参与项目 每次迭代中重新收集需求、定义范围	使用产品代办列表来记录需求 迭代开始时确定优先项

规划阶段无法确认部分细节信息时-->滚动式规划，近细远粗、渐进明细、不断完善

需求来自相关方，在项目过程中不断进行确定、记录并管理

可交付成果未确定-->定义范围未完成-->重新确定范围

对范围定义有争论-->产品分析和备选方案分析-->定义范围

需求管理计划-->执行阶段没有提供正确的需求-->需要重新收集和确认需求

需求文件-->单一需求如何满足于项目相关的业务需求

需求跟踪矩阵-->了解项目所有需求以及相应的变更执行情况
              了解可交付成果是否满足业务需要以及项目工程中发生的范围变更
              对可交付成果有疑问
              无法确认产品是否符合要求-->需求定义不清或没有跟踪清楚
              不确定是否满足客户需求

项目范围说明书-->可以了解到可交付成果

四、进度管理

规划进度管理--定义活动--排列活动顺序--估算活动持续时间--制定进度计划--控制进度

规划进度管理--制订项目进度管理计划

排列活动顺序--确定活动之间的依赖关系

估算活动持续时间--估算单个活动或项目所需要的时间，由项目团队中最熟悉活动的人来进行

制订进度计划--产生进度基准

批准【快速跟进】改变活动顺序的变更请求前，先分析活动之间的依赖关系，确定是否可以并行

最先知道的就是WBS标识、活动名称和活动标识

排列活动顺序-->活动之间的逻辑关系-->紧前活动或紧后活动

估算活动资源-->活动资源需求

标准差=（最悲观时间-最乐观时间）/6

三点估算题目，没有特殊提醒时，都使用贝塔分布来计算

资源平衡-->一个资源在同一时段被分配多个任务时，关键路径会变化
资源平滑-->关键路径不会变化、可以节约出一些潜在的免费资源

提前量--提前搞，快速跟进
滞后量--缓一缓，晚点搞，弹性

故事点-->评估用户故事的工作量大小
[敏捷]遣散计划-->定义了发布的迭代次数

按需进度计划-->根据团队能力选择能够完成的任务
工作绩效信息-->评价状态更新对原始基准的影响

蒙特卡洛模拟-->计算概率分布
参数估算-->基于历史数据和项目参数来估算
帕金森定律-->只要还有时间，工作就不断扩展，直到用完所有时间

五、成本管理

	直接成本	间接成本
	仅本项目使用	多项目分摊

	机会成本	沉没成本
	例子：   选A赚10万，选B赚8万，选C赚9万   那么选A时的机会成本是9万，   选B时的机会成本是10万	做决策，不要考虑沉没成本 已经花费无法收回的成本

管理储备不包括在成本基准中

管理储备不包括在成本基准中

管理储备不包括在成本基准中

成本基准=直接成本+应急储备

估算=成本基准+管理储备

估算=成本基准+管理储备

估算=成本基准+管理储备

项目成本控制

目的：分享资金支出与已完成工作是否匹配

挣得进度理论将如何测量进度偏差？挣得进度-实际时间

制定预算中的储备分析--计算管理储备

估算成本的储备分析--计算应急储备

机会成本

做决策时需要考虑，但机会成本不是实际会发生的成本，不应计入活动成本估算中

挣值分析

EV>PV，SPI【进度绩效】>1，进度提前
EV<AC，CPI【成本绩效】<1，成本超支

偏差分析

SPI、CPI大于1，就是好
PV、AC小于EV，就是好

完工尚需绩效指数（TCPI）是一种为了实现特定的管理目标，剩余资源的使用必须达到的成本绩效指标，是完成剩余工作所需的成本与剩余预算之比

TCPI越小，意味着项目资金压力越小

完工估算等于实际成本加完工尚需估算

六、质量管理

规划质量管理--识别项目及其可交付成果的质量要求和标准，书面描述项目将如何证明符合质量要求和标准

输出：质量策略在测量指标

管理质量--提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因

包括：开展过程改进和编写质量报告

不遵守流程-->质量审计，属于管理质量过程的工具

控制质量--核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收

最终产品不符合质量--修复缺陷，属于控制质量过程

问题解决步骤是：定义问题→分析根本原因→生成可能的解决方案→选择最佳解决方案→执行解决方案→验证解决方案的有效性

符合质量要求会减少问题的出现，但不一定能减少风险

质量缺陷-->对实施过程进行审计和监控

质量功能展开

1.了解客户声音

2.对客户需要进行分类和排序

3.为实现客户需要设定目标

面向X

重点改进[优化]产品的某个特性、不一定能降低质量成本

X：产品的某个特性[可靠性、可用性]

控制图

系统的声音：控制上限和下限

客户的声音、要求：规格上限和下限

安装缺陷属于质量问题，应记录在质量报告中
团队成员为了奖金，选择忽视质量，偷工减料。不可取，要让团队成员必须按照质量管理计划来做

七、资源管理

发现团队成员能力不足或缺少技能，有三个正确做法：培训、调整岗位、修改计划

资源需求：估算活动资源过程的输出，识别了各个工作包或活动所需的资源类型和数量，并进行汇总

资源分解结构：资源按类别和类型的层级分解结构，不如资源需求文件内容详细

资源日历：获取资源过程的输出，规定了在项目期间团队和实物资源何时可用，可用多久

项目资源管理中，

控制资源过程是监控过程组开展的，但它关注的是实物资源的管理。[问题解决]、不会对事业环境因素造成更新

管理团队过程是执行过程组开展的，关注对团队成员的管理。

文本型比RACI矩阵更详细

资源的可用性--资源管理

团队成员的关系问题，团队建设最有效

八、沟通管理

确定沟通方法的复杂性-->沟通需求分析
信息过多且难以分类-->规划沟通实施不当
会议被中断-->沟通管理计划没有对会议规则进行有效的规划


不知情就是项目的信息传递不到位-->修订沟通管理计划

九、风险管理

规划风险管理-->针对整个项目的风险管理
规划风险应对-->针对具体的风险

识别完风险，更新到风险登记册
选择更可靠的卖方，属于减轻

概率和影响矩阵-定性
决策树分析、成本风险模拟--定量

风险分解结构是给风险做分类的

十、采购管理

总价合同	固定总价 卖方成本风险最高	工作范围变化则可以调整合同价格
	总价+激励费用	超过上限，卖方承担，低于下限则奖励卖方
	总价+经济价格调整	履约时间长[汇率？]或不同货币支付
成本补偿	成本+固定费用 卖方成本风险最低	固定成本+为卖方报销成本
	成本+激励费用	报销卖方成本，最终成本按比例分摊
	成本+奖励费用	满足了买方的绩效标准才报销
工料合同		卖方需要承担工料单价的风险

总价合同	工作范围明确	卖方承担
工料合同	工作性质清楚、范围不是很不清楚、工作不复杂、快速签订合同	双方承担风险
成本补偿合同	工作范围不清楚	买方承担

招标文件--应答格式
详细程度与采购的价值和风险相符
足够详细而非非常详细，能让卖方做出一致且恰当的回答
足够灵活，让卖方为满足相同要求提出更好的建议
方便买方对卖方的应答进行评价

采购工作说明书不包含应答格式，包含规格、数量、质量水平、绩效数据、履约期限和地点

十一、相关方管理

新相关方出现的三个条件：进入不同阶段、换人加人、组织重组
相关方发生变化--记录《相关方登记册》--分析和处理【采取措施】

项目已经延迟，可能会引起相关方的不满，因此要管理相关方的期望

发起人参与的过程：制定项目章程、确认范围、结束项目或阶段

未签署协议，说明项目还没启动--找发起人

【启动阶段】识别相关方--记录《相关方登记册》--分析和处理【采取措施】--规划相关方参与&制定相关方参与计划--分析--制定管理策略

收集重要相关方的高层次需求--项目章程

相关方不了解他们在项目中的参与情况--完成《相关方登记册》，明确相关方在项目中扮演的角色
相关方的需求不被满足--查询《相关方登记册》--进行相关方方分析【分析他的需求】--评估相关信息

确保相关方参与，需要对比他现在和期望的参与水平--相关方参与度评估矩阵

	权利/利益方格	凸显模型	相关方优先级排序
特点	根据相关方的职权【权力】和对项目结果的关注【利益】程度进行分类 记录关键相关方的想法	复杂	频繁变化
	权力高、利益低--令其满意 权利低、利益高--随时告知

	相关方登记册	相关方参与计划
	识别、登记	解决相关方的需求 相关方参与度的问题

十二、十二项原则，八大绩效域

PM应提供协助，促成满意的解决方案，采用直接和合作的方式，尽早并且通常在私下处理冲突
PM使用自己的领导力影响相关方遵守约定的项目目标

冲突管理，首先采用合作/解决问题

一个新的行业，一般"行业的问题都找专家"会更好

将项目分为多个阶段通常是为了减少风险

1.干系人绩效域

目的：
搞好关系
目标一致
提高客户满意度、降低负面影响

内功[原则]：
沟通、人际关系、参与

外功[技术]：
干系人参与：识别、理解、分析、优先级、参与、监督
与其他绩效域的相互作用：团队、交付、规划、测量等
检查结果

2.团队绩效域

3.开发方法和生命周期绩效域

预测型、混合型【预测+敏捷】和适应型【迭代型、增量型、敏捷型】

4.规划绩效域

准确度：90、92、95、97、98、99
精确度：95、95、95、95、95、95

赶工：加班
快速跟进：并发

资源： 资源分解、定岗定责

5.项目工作绩效域

6.交付绩效域

完成的定义(DoD)：须达到的所有准则的检查清单。
质量：一系列内在特征满足需求的程度。
质量成本(COQ)：在整个产品生命周期所产生的以下所有成本。

7.测量绩效域

8.不确定性绩效域

十三、敏捷

路线图和愿景文件先于发布计划
发布计划  有更高的优先级
迭代计划  从发布计划中提取其优先级

产品路线图--计划何时完成工作
用户故事待办事项列表--项目上还有哪些工作要做
对待办事项进行优先排序，是为了更好地理解和吸收利益相关方重视的内容

任务板是一种图表工具，基本功能是帮助团队整理和分析他们的工作进度。
整理工作并将迭代中的剩余工作可视化
显示在制品的最佳工具

拳五
拳头表示不支持
所有人都伸出三根以上手指，就表示全体达成共识


详解：
在任务板中，冲刺中的任务分为 3 个主要类别：
1. 即将开始的任务，2. 进行中的任务，和 3. 已完成的任务。
每个人都可以通过任务版轻松查看团队当前正在处理的任务并选择下一批任务。

客户期望延长迭代以增加产品特性--不行，迭代是有时间限制的，团队只需要完成为该迭代计划的内容

PO
产品负责人负责最终确定工作是否完成

十四、归纳，对比

引导式主题研讨会	对具有不同期望和专业知识的相关方进行需求收集、跨职能 定义产品需求 包括质量功能展开、联合应用设计或开发、用户故事
头脑风暴	产生和收集[项目需求与产品需求]的多种创意
访谈	1对1或多对多的互动沟通，获取直接或机密信息
焦点小组	主持人引导相关方和主题专家进行互动讨论 同一领域，不需要得出结论
问卷调查	受众多样化、快速完成调查、受访者地理位置分散、适用于开展统计分析
标杆对照	对比
多标准决策分析	评估和排序
亲和图	分组、便于审查和分析
思维导图	反映创意间的共性和差异
名义小组	投票排列、优先排序
用户故事	记录每个需求、描述需求相关方、需要实现的目标以及期望效果 哪个相关方受益、需要实现什么目标、希望获得什么利益
散点图	相关性

因果图	找根本原因的【鱼骨图、石川图】
直方图	帕累托图：识别重要问题与根本原因
散点图	两个变量之间的关系
亲和图	分类的，可用于头脑风暴之后

预期货币价值分析	风险概率X风险影响	概率+影响
蒙特卡洛分析	关键字：概率	概率
敏感性分析	识别影响最大的风险，不分析风险概率	影响

挣值分析	评价偏离初始项目基准的程度
偏差分析	将实际结果和基准进行比较，以确定偏差是否大到需要提出变更
趋势分析	审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
回归分析	建立与项目结果有关的不同项目变量之间的统计量化关系

文件分析--针对之前的项目
偏差分析、回归分析、趋势分析--总结经验教训，用于当前的项目
挣值分析是监控项目工作、控制进度、控制成本和控制采购四个过程的工具与技术

	WBS分解	活动分解
	可交付成果-->工作包	工作包-->活动

流程：

识别完风险--更新到风险登记册

项目技术工作完成--产品通过最终验收--写项目总结--举行经验教训会议--经验教训更新到组织过程资产--庆功宴--释放资源

<制定项目章程阶段>针对相关方的高层次需求-->与相关方、发起人一起开会讨论-->获得一致后纳入项目章程

收尾阶段应该编制最终项目绩效报告，不再需要更新问题日志

十五、总结

1.问首先  顺序优先，选择最靠前的
2.问现在  最全面、重要优先、合规优先
3.问未来  与经验教训相关
4.问提前  没出问题之前，最正确的流程和做法