导图社区 PMP项目管理考试知识点总结
- 3
- 0
- 0
- 举报
PMP项目管理考试知识点总结
这是一篇关于PMP思维导图，第一部分规划风险管理，讲解风险、风险敞口、风险三要素等核心概念，明确中立评估标准、整合式管理思路，梳理该过程输入、干系人登记工具与输出风险管理计划；第二部分识别风险，核心目标是挖掘全部潜在风险与责任人，罗列头脑风暴、访谈、SWOT、核对单等八大实操工具，输出风险登记册、风险报告；第三部分实施定性风险分析，依托概率、影响、分值、责任人四维打分排序风险，包含概率影响评估、矩阵分析等工具，更新风险登记册并量化风险优先级。全图打通风险管理完整闭环，区分各过程边界与工具用途，解决考生混淆流程顺序、记错工具适用场景、分不清输入输出文件的复习痛点。适合 PMP 考前系统复习、项目管理从业者工作复盘，快速理清风险全流程管理逻辑。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- PMP考试
- 敏捷项目管理
- PMP指南
- 相似推荐
- 大纲
PMP思维导图
1.1项目的基本要素
标注
PMBOOK指南
是“指南”而非“具体的方法论”
针对“单个项目”，不针对项目集、项目组合
“普遍认可”(大多数时候适用于大多数项目)
“良好实践”(能够提高很多项目成功的可能性)
“裁剪”(确定过程、输入、工具、技术、输出和生命周期阶段的恰当组合)
项目管理业界定义的最重要的价值观：
责任、尊重、公正、诚实
一、 项目的定义
项目是为创造独特的产品、服务或成果而进行的临时性工作
二、 项目的特点
（一） 独特性
1. 独特性带来不确定性
风险
2. 可交付成果
是独特的，可核实的
(可能有形，可能无形）
3. 某些项目可交付成果和活动中可能存在重复的元素，但这种重复并不会改变项目本质上的独特性。
（二） 临时性
1. 需要收尾的几种情况
标注
有人不支持≠终止
中止/搁置收尾：可以重新启动
（1） 达成目标
（2） 不会或不能达成目标
（3） 没有资金
钱
（4） 没有资源
人/物
（5） 需求不存在
（6） 法律或便利原因
（甲方便利）
2. 项目是临时的，可交付成果是持久的
3. 项目有明确的起点和终点。
4. “临时性”并不一定意味着项目的持续时间短。
有长有短
（三） 项目驱动组织变革
（四） 项目创造商业价值
1. 有形
2. 无形
3. 有形和无形兼有
（五） 项目成功标准
项目的成功标准需要跟干系人达成共识
成功标准很多，具体以哪些标准来衡量要达成共识
三、 项目与项目集和项目组合的关系
（一） 项目集强调“关联关系"
“方式”正确
（二） 项目组合强调"竟争关系”
"选择”正确
关注优先级
了解”运营“
（1） 持续的
（2） 重复的
（3） 项目 往往 来自于运营又服务于运营
（三） 战略＞项目组合＞项目集＞项目
四、 项目生命周期
（一） 阶段
（二） 阶段关口
1. 审查
商业论证，项目章程，各种计划...
2. 决策
进入下一阶段；整改进入..；结束项目；停留当前；重复阶段或某个要素
（三） 通用生命周期
开始项目、组织与准备、执行项目工作、结束项目
（四） 生命周期的特点
1. 成本与人力投入：
项目开始时“缓慢增加”，在“执行工作”期间达到最高，项目快结束时“迅速回落”
2. 风险与不确定性、相关方的影响力、变更的数量：
项目开始时最大，后续“逐步降低”
3. 变更的代价、风险的影响：
项目开始时较小，后续“显著增高”
（五） 开发生命周期：类型×5
1. 预测型
瀑布型、计划驱动
范围、进度、成本在早期阶段就确定
按计划执行、一次交付。
充分了解产品；有厚实的行业基础;
概要
子主题
2. 迭代型
通过一系列重复的循环活动来开发产品
总结：从"模糊”到"清晰”
3. 增量型
渐进增加产品功能一系列增量来产出可交付成果
总结：从“部分"到“整体"
4. 适应型（敏捷）
较小的增量:每次均交付“最有价值”的功能
快速的迭代:一般2~4周一个迭代
频繁交付，干系人频繁参与
适用于创新项目，需要快速应对变化
5. 混合型
五、 项目管理
（一） 项目管理过程
为完成预定的产品、成果或服务而执行的一系列相互关联的行动和活动
（二） 五大过程组
（三） 十大知识领域
概要
（四） 项目管理中的数据和信息
1. 工作绩效数据
原始观察结果和测量值
2. 工作绩效信息
整合分析得到
3. 工作绩效报告
汇编工作绩效信息形成的文件
概要
（五） 项目管理商业文件
1. 商业论证
标注
1||| 商业需求
2||| 成本效益分析
指文档化的经济可行性研究报告
列出了项目启动的目标和理由。
论证项目是否值得投资
项目发起人负责项目商业论证文件的制定和维护
2. 效益管理计划
描述了项目实现效益的方式和时间，以及应制定的效益衡量机制
1.2项目运行环境
一、 事业环境因素
定义
事业环境因素(EEFs)是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件 这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。
Enterprise Environmental Factors(EEFs).
特点
不可控，需遵守
必须用
示例
（一） 组织外部
1||| 法律限制
2||| 政府或行业标准
3||| 财务因素
关税、汇率等
4||| 物理环境要素
天气等
5||| 商业数据库（外部）
（二） 组织内部
1||| 信息技术软件
组织使用的各种软件都属于事业环境因素
2||| 组织文化和结构
3||| 基础设施
4||| 资源可用性
5||| 员工能力
二、 组织过程资产
定义
执行组织特有并使用的计划、过程、政策、程序和知识库
特点
可裁剪使用，需要不断更新，多积累
参考用
示例
1. 过程、政策和程序
1||| 指南
2||| 模板
2. 组织知识库
1||| 经验教训知识库
2||| 以往的项目档案
三、 各种组织结构
1. 职能型（集中式）
兼职项目经理(联络员)
权力“很小”甚至“没有”
2. 矩阵型
1||| 弱矩阵
兼职项目经理(协调员)
权力“小”
2||| 平衡矩阵
兼职项目经理
权力“小~中”
3||| 强矩阵
全职项目经理
权力“中~大"
3. 项目型
全职项目经理
权力“大~全部”
概要
3兼职，2全职
4. 其他
有机型或简单型组织
非正式组织
适用于创业公司
工作专业化少，管理层次少，决策分散，监督不多
多部门组织
一个中心，多个部门/分区，半自治，重复组织的职能，不集中
虚拟型组织
（网络型组织）
临时组织
目标完成即解散
四、 PMO
定义
项目管理办公室(PMO)是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织结构
类型（支控指）
1||| 支持型
控制程度 很低
是顾问、项目资源库
2||| 控制型
控制程度 中等
支持+要求服从
3||| 指令型
控制程度 高
直接管理和控制
作用
1. 识别和制定“最佳实践”和"标准“
(管理功能)
2. 项目审计
(监督功能)
3. 制定政策、程序、模板，培训指导项目经理
(指导培训功能)
4. 协调“跨项目”的沟通
(协调功能)
1.3项目经理的角色
一、 定义
1. 由执行组织（公司）委派，领导团队实现项目目标的个人
2. 实现目标而不是制定目标(马仔)
二、 PMI人才三角
1. 技术项目管理技能
PMP知识
2. 战略和商务技能
行业知识
3. 领导力技能
软技能
三、 项目经理的几种权力
1||| 专家权力
2||| 参照（潜示）权力
1||| 后台
2||| 个人魅力
3||| 奖励权力
4||| 正式（合法、法定、职位）权力
5||| 惩罚权力
概要
四、 项目经理的几种领导力风格
1||| 放任型
容易失控，但有利于创新
2||| 交易型
定目标，给奖励
3||| 服务型
仆人式领导
4||| 变革型
通过促进创新来提高追随者的能力
5||| 魅力型
精神饱满、热情洋溢、充满自信、说服力强、能够激励他人
6||| 交互型
结合了交易型、变革型和魅力型的特点
2.1项目启动
2.1.1制定项目章程
要点
1||| 授权项目经理，确立项目的正式地位。
2||| 项目经理(参与)制定，发起人审批发布
3||| 项目经理尽早任命，最晚需要在规划开始前任命
注意点
经批准的项目章程=项目正式启动。
项目由项目以外的实体来启动，如发起人、项目集或项目管理办公室等等。
不要把项目章程看做合同，项目章程≠合同
输入
1. 商业文件
标注
商业文件需要定期审核
商业文件不是项目文件，项目经理不能修改，只能提出建议
只有发起人可以“批”
1||| 商业论证
商业论证论证了项目是否值得投资(成本效益分析)
（1）商业论证分析
（2）成本效益分析
2||| 效益管理计划
2. 事业环境因素
3. 组织过程资产
工具和技术
（1） 专家判断
具有专业学历、知识、技能、经验或培训经历的任何小组或个人。
（2） 头脑风暴
畅所欲言
（3） 焦点小组
召集同领域(职能)的干系人和主题专家讨论相关议题
（4） 访谈
与干系人直接交谈
（5） 引导
达成共识
针对：有分歧时
（6） 会议管理
输出
项目章程
项目的目的、目标、成功标准、退出标准
高层级的需求、主要可交付成果
项目经理的职责
项目审批要求、关键干系人名单
总体里程碑进度计划、总体预算、整体项目风险
假设日志
1||| 假设条件
定义：项目规划中视为真实、正确但未经验证的前提条件，用于支撑项目计划的制定。若假设不成立，可能导致项目目标无法实现
不需验证即可视为正确、真实或确定的因素；如果这些因素不成立，可能造成的潜在影响’
2||| 制约因素
定义：制约因素是限制项目团队选择余地的客观条件，可能来自内部（如资源、技术）或外部（如法规、市场）
有影响的限制性因素
2.1.2识别干系人
干系人：
是指会受项目的积极或消极影响，或者能对项目施加积极或消极的影响的任何人
干系人（也叫“相关方”）：能影响项目，或者受项目影响（包括自认为受到项目影响）的个人或组织。
要点：
定期识别项目干系人，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程
早识别，早分析，早参与
输入
项目章程
商业文件
协议
工具和技术
问卷调查、头脑风暴(写作)
1、身份信息
干系人分析
2、评估信息
干系人 权力/利益方格
3、分类信息
权力高，利益高:
重点管理
权力高，利益低:
令其满意
权力低，利益高:
随时告知
权力低，利益低:
监督
概要
干系人立方体
凸显模型
权力、紧迫性
输出
干系人登记册
（1） 身份信息
（2） 评估信息
（3） 分类信息
变更请求
2.2项目规划-上 （范围、进度、成本）
2.2.1规划范围管理
范围管理计划:
如何管范围
注意点
1、范围管理计划无范围(范围在范围基准中)
2、范围管理计划可以是正式或非正式的，非常详细或高度概括的。
需求管理计划 (商业分析计划):
如何管需求
注意点
1、需求管理计划无需求(需求在需求文件中)
2、内容包括配置管理活动、需求优先级排序过程、测量指标等。
2.2.2收集需求
什么是需求?
需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。
要点：
为实现目标而确定、记录干系人的需要
输入
项目章程
项日章程中记录的是高层级的(概括的)需求
干系人登记册
协议
商业文件
工具和技术
（1） 头脑风暴
大量创意、各种想法、畅所欲言
（2） 访谈
信任和保密的环境
直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
（3） 焦点小组
聚焦在某一个点，同一职能(部门）、同一领域、有相似背景、主题专家(SME)、主持人引导互动式讨论
（4） 问卷调查
地理位置分散，受众多样化，快速完成，适合开展统计分析
（5） 标杆对照
识别最佳实践，形成改进意见，标杆可以是内部或外部、同行业或不同行业
（6） 投票
1||| 一致同意
每个人都同意，德尔菲 (专家、匿名、多轮、趋同、消除偏见)
2||| 大多数同意
超过50%
3||| 相对多数同意
（7） 独裁型决策
（8） 多标准决策分析
多个标准设置权重，权重*得分算总分
决策矩阵、多种标准、评估和排序
（9） 亲和图
分组、分类
（10） 思维导图
整合，反应共性与差异、激发新创意、脑图
（11） 名义小组
投票、排序、5分制、数轮
（12） 观察和交谈
工作跟随，难以或不愿意说清楚，挖掘隐藏需求
（13） 引导
协调干系人差异，协调跨职能需求
联合应用设计或开发(JAD)
质量功能展开(QFD)
用户故事
（14） 系统交互图
拓扑图、可视化
（15） 原型法
支持渐进明细的理念。例如:故事板，减轻返工风险
概要
输出
1||| 需求文件
描述单一需求如何满足相关的业务需求
2||| 需求跟踪矩阵
把产品需求从来源 链接到 可交付成果的一种表格
确保每个需求都有对应的业务目标，确保每个需求都有价值
提供了在整个项目生命周期中跟踪需求的一种方法
确保每个需求都最终得以交付
概要
ZLD：需求到目标，可交付结果，对应关系的题型
2.2.3定义范围
要点：
从需求文件中选取最终的项目需求
定义好用什么可交付成果及验收标准来满足这些需求
输入
项目章程
需求文件
工具和技术
1||| 备选方案分析
对已识别的可选方案进行评估的数据分析技术，其核心目的是决定选择哪种方案或使用何种方法来执行项目工作，从而找到在定义的制约因素范围内执行项目活动的最佳方案（即“Plan B”）。
2||| 多标准决策分析
3||| 引导技能
4||| 产品分析
输出
项目范围说明书
代表了相关方之问就范围达成的共识
1||| 产品范围描述
逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
2||| 可交付成果
必须产出的任何独特并可核实的产品、成果或服务能力。也包括辅助成果，如项目管理报告和文件
3||| 验收标准
通过验收前必须满足的一系列条件
4||| 除外责任
明确说明哪些内容不属于项目范围
2.2.4创建WBS
要点：
WBS组织并定义了项目的总范围
把可交付成果分解成较小的、更易于管理的组件
创建WBS，就是要将整个项目工作分解为工作包
WBS最低层的组成部分称为工作包，其中包括计划的工作
输入
项目范围说明书
需求文件
工具和技术
分解
1||| 100%原则
无遗漏无多余
2||| 责任唯一
3||| 不宜过细分解
4||| 80小时原则(建议)
输出
范围基准
1||| 项目范围说明书
2||| WBS
3||| WBS词典
考点
哪儿找可交付成果和验收标准？
选择顺序：范围说明书 ＞ wbs词典＞ 范围基准。
2.2.5规划进度管理
要点
进度管理计划无进度
输出
进度管理计划
为编制、监督和控制项目进度建立准则和明确活动
指南型文件，没有实质内容
2.2.6定义活动
要点：
将工作包分解为活动
输入
项目管理计划
范围基准
工具和技术
1||| 分解
把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分。
团队成员参与有助于得到更准确的结果
2||| 滚动式规划
迭代式的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。
输出
1||| 活动清单
需要定期更新
2||| 活动属性
3||| 活动里程碑
一个重要的时间点或事件
里程碑不是活动，持续时间为0
里程碑可以是强制性的或者是选择性的
1||| 强制性里程碑（被动性里程碑）
“被推着走”的必经历程，强调外部约束和不可逆性
项目层面：如合同中规定的必须按时交付的节点、法律法规要求的合规性验收节点等
2||| 选择性里程碑（主动性里程碑）
强调主观能动性和灵活性
项目层面：如项目团队为了便于内部管理、优化进度而自主设定的内部汇报节点、阶段性成果自查节点等，这些节点可根据项目实际进展情况进行灵活调整。
2.2.7排列活动顺序
要点：
在既定制约因素下获得最高的效率
输入
活动清单
活动属性
活动里程碑
工具和技术
PDM紧前关系绘图法
S：开始
F：完成
FS、SS、FF、SF
确定和整合依赖关系
分类1
1||| 强制性依赖关系
(硬逻辑、硬依赖)
法律或合同要求的，或者由工作内在性质决定的
(项目团队不能违反)。
2||| 选择性依赖关系
(首选逻辑、优先逻辑、软逻辑)
基于最佳实践建立的、或基于项目的某些特殊性质而采用的依赖关系
(项目团队可自由选择)
可以调整，实现快速跟进
如果打算快速跟进，应当审查相应的选择性依赖关系。
分类2
1||| 内部依赖关系
项目活动之间的紧前关系
(项目团队可控）
2||| 外部依赖关系
项目活动与非项目活动之间的依赖关系
(项目团队不可控）
提前量和滞后量
定义
提前量---- 相对于紧前活动，紧后活动可以提前的时间量。(往往表示为负滞后量，如FS-3)
滞后量----相对于紧前活动，紧后活动必须推迟的时间量。(如FS+2)
注意
提前量和滞后量的使用 不能替代进度逻辑关系
活动持续时间估算中 不包括任何提前量或滞后量
输出
项目进度网络图
路径汇聚点 和 路径分支点 需要注意高风险
2.2.8估算活动资源
要点：
估算执行项目所需的团队资源，以及材料、设备和用品的类型和数量的过程
输入
(无考点)
工具和技术
(无考点)
输出
资源需求
估算依据
资源分解结构（RBS） Resource Breakdown Structure
2.2.9估算活动持续时间
估算活动持续时间
根据资源估算的结果，估算完成单项活动所需工作时段数(也叫工期)的过程。
要点：
应该由项目团队中最熟悉具体活动的个人或小组，来提供活动持续时间估算所需的各种输入。
需考虑的其他因素
收益递减规律
在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素(如资源)会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减。
资源数量
增加资源数量，不一定能缩短时间。可能会因风险造成持续时间增加，也可能因对于增加的资源，需要知识传递、学习曲线、额外合作等因素造成持续时间增加。
员工激励
估算时还需考虑“学生综合症”和“帕金森定律”
技术进步
输入
略
经验式定律
帕金森定律
只要还有时间，人们就会有意无意地多做不必要的工作(范围蔓延)，直到用完所有的时间。
学生综合症
工作范围通常不变，人们在较早时间完全不做事或者很少做事，总要等到截止日期快到时才着急做。
墨菲定律
有可能出错的事情，就会出错。
彼得定律
工作岗位总是被不能胜任的人占据的。
学习曲线
表示了经验与效率之间的关系，指的是越是经常地执行一项任务，每次所需的时间就越少(熟能生巧)
工具和技术
（1） 类比估算
自上而下
专家判断
项目启动阶段
速度快、成本低、不准
（2） 参数估算
基础数据、参数模型
（3） 三点估算（PERT）
考虑估算中的不确定性和风险，来提高估算的准确性。
贝塔分布
期望值(平均值)=(最悲观+最乐观+最可能X4)/6
（4） 自下而上估算
最准的一种方法但是耗吋
（5） 数据分析
备选方案分析
储备分析
1||| 应急储备
应对“已知一未知”风险
在最终的基准中
项目经理可以直接使用
2||| 营理储备
应对“未知一未知”风险
不在基准中
项目经理必须走变更流程申请使用
（6） 决策
（7） 会议
概要
输出
持续时间估算
不包括任何滞后量但可指出一定的变动区间
估算依据
2.2.10制定进度计划
要点：
为完成项目活动而制定具有计划日期的进度模型
输入
略
工具和技术
进度网络分析
一种综合的技术，综合了关键路径法、资源优化和建模技术
关键路径法：CPM Critical Path Method
（1） 所有路经中时间最长的路径， 决定了项目最短工期
关键路径=最长时长
（2） 关键路径越多，风险越大
（3） 关键路径不考虑资源约束，只考虑路径约束
关键路径法排出来的进度计划未必可行，关键路径法不考虑资源约束，需要配合资源平衡处理。
（4） 顺推和逆推
顺推找对大
逆推找最小
（5） 总浮动时间 TF
标注
1||| 正值+
活动有时间余量，该活动位于非关键路径上
2||| 零0
活动没有时间余量，该活动位于关键路径上
3||| 负值-
活动时间不足，进度落后于计划要求。
需要通过进度压缩（如赶工、快速跟进）或调整逻辑关系来纠正
1. 活动延期但不延误项目完工日期：TF=LF-EF=LS-ES=下-上
2. 体现进度灵活性。
（6） 自由浮动时间 FF
活动延期但不延误任何紧后活动最早开始日期：FF=紧后ES(min)-EF-1
（7）
非考点
资源优化技术
1||| 资源平衡
根据资源制约对开始日期和结束日期进行调整的一种技术。
实现资源优化，往往会导致关键路径的改变，一般是延长
2||| 资源平滑
对活动进行调整，使项目资源需求不超过预定的资源限制的技术，活动只在其自由和总浮动时间内延迟。所以该技术可能无法实现所有资源的优化。
不改变关键路径，完工日期也不会延迟
3|||
数据分析
假设情景分析
如果出现情景X，情况会怎样
模拟
蒙特卡罗（洛）分析
一种基于概率论与数理统计的数值计算方法。其核心思想是“通过大量随机抽样和统计模拟，用频率近似概率、用样本均值近似数学期望”
进度压缩
不缩减范围的前提下，缩短或加快工期
分类
1||| 赶工
通过增加资源，以最小的成本增加来压缩进度（关键路径上）。 加班、如人、加急。会增加成本。
“不计成本地去缩短关键路径”的题型
概要
无任何以上明确的限制条件描述的题型 选择优先级为：进度压缩>赶工>快速跟进
先宏观，后花钱，再并行
2||| 快速跟进
将顺序进行的活动改为至少部分并行，会增加风险
“没有额外的资源”或者“成本不能超支”的描述题型
只适用于相互为选择性依赖关系的活动。
输出
进度基准
经干系人接受和批准的进度模型，包含了基准的开始/结束日期等信息的，只有通过正式的变更控制程序才能进行变更，用作与实际结果进行比较的依据。
项目进度计划 （详细程度由低到高）
进度模型的输出，展示活动之间的相互关联，以及计划日期(至少要有)、持续时间、里程碑和所需资源。有三种层次的进度计划(详细程度由低到高)
（1）、里程碑图:
显示主要可交付成果和关键外部接口
方便向客户汇报
（2）、横道图(甘特图):
用于追踪活动进度
向管理层汇报进展
（3）、项目进度网络图
用于优化展现活动之间的关系
项目日历
规定可以开展进度活动的可用工作日和班次
2.2.11规划成本管理
要点：
成本管理计划
如何管成本(how)
描述将如何规划、安排和控制项目成本(成本管理计划无成本)
2.2.12估算成本
要点：
估算成本是对完成项目工作所需资源成本进行近似估算的过程。
进行成本估算，应考虑将向项目收费的全部资源(如特殊的:通货膨胀补贴、融资成本或应急成本等)
输入
项目进度计划
进度计划包括项目可用的团队和实物资源的类型，数量和可用时间的长短
工具和技术
（1） 类比估算
也是一种专家判断、也是整体估算、也是自上而下的
关键词：成本低、耗时少、不准准确性低、详细信息不足时、速度快，需要快速得到结果时、启动阶段时
（2） 参数估算
利用历史数据之间的统计关系和其他变量来估算。回归分析是典型的参数估算。
关键词：统计关系、参数模型、基础数据
（3） 三点估算
PERT计划评审技术
考虑风险和不确定、提高估算准确性
默认用贝塔分布
（最悲观+4*最可能+最乐观）/6
三角分布
(最悲观+最可能+最乐观)/3
（4） 自下而上估算
最准的一种方法，但是很慢
（5） 备选方案分析
（6） 储备分析
为”己知-未知“风险预留应急储备
项目经理可以动用、减少或取消应急储量
应急储备是成本基准的一部分，不需要走变更流程
ZLD：估算成本时不含管理储备
（7） 质量成本
输出
成本估算
估算依据
2.2.13制定预算
要点：
制定预算：汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。
成本基准是经过批准且按时间段分配的项目预算，包括应急储备，但不包括管理储备
项目预算=成本基准+管理储备
成本基准=工作包成本估算+应急储备
输入
成本估算
估算依据
商业文件
协议
需要考虑将要或已经采购的产品、服务或成果的成本
工具和技术
（1） 成本汇总
汇总路线自下而上
（2） 数据分析(储备分析)
针对“未知-未知”风险
建立项目管理储备的储备分析
管理储备动用需要走变更流程
动用的管理储备要纳入成本基准
（3） 历史信息审核
有助于进行参数估算或类比估算
（4） 资金限制平衡
可能会导致进度计划的改变，以平衡资金支出水平
输出
成本基准
包括应急储备，但不包括管理储备
项目资金需求（项目预算）
=成本基准+管理储备
项目资金通常以阶梯状的形态增量而非连续的方式投入。
成本基准中既包括预计的支出，也包括预计的债务。
2.2项目规划-下 （质量、资源、沟通、干系人、风险、采购）
2.2.14规划质量管理
要点：
识别项目及其可交付成果的质量要求和(或)标准，并书面描述项目将如何证明符合质量要求和(或)标准的过程
核心概念
质量兼顾“项目管理”和“可交付成果”两个方面
（过程 和 结果）
质量和等级的区别
质量
----作为实现的性能或成果，是一系列内在特性满足要求的程度。
等级
----作为设计意图，是对用途相同但技术特性不同的可交付成果的级别分类。
注意
高等级并不意味着一定高质量；低等级也并不意味着一定低质量;
质量水平未达到质量要求肯定是个问题，而低等级不一定是个问题。
项目经理及项目管理团队负责权衡，以便同时达到所要求的质量与等级水平。
质量管理的3类术语区别
预防和检查
1||| 预防
=避免，过程
保证过程中不出现错误
2||| 检查
=发现，结果
保证错误不落到客户手中
属性抽样和变量抽样
1||| 属性抽样
定性
结果为合格或不合格
2||| 变量抽样
连续区间
表明合格的程度
公差和控制界限
1||| 公差
结果的可接受范围
2||| 控制界限
稳定过程的普通偏差的边界
五种质量管理水平
（1） 让客户发现缺陷。
（2） 通过控制质量过程先检测和纠正缺陷，再交付客户。
QC
（3） 通过质量保证检查并纠正过程本身。
QA
（4） 将质量融入项目和产品的规划和设计中。
QP
（5） 在整个组织内创建一种关注并致力于实现过程和产品质量的文化。
新兴实践
1||| 客户满意
符合要求、适合使用
2||| 持续改进
PDCA是质量改进的基础，小改进的积累成大改进
3||| 管理层的职责
85/15原则
管理者85%责任，员工15%责任
4||| 与供应商的互利合作关系
概要
总结：规划质量“定标准”
输入
组织过程资产
质量政策由高级管理层推崇
工具和技术
标杆对照
头脑风暴
访谈
成本效益分析
比较其可能成本与预期效益
值得/不值得
质量成本
定义
在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求(返工)，而发生的所有成本。
分类
（1） 一致性成本
1||| 预防成本
事前
培训，流程文档化，设备，正确的时间做事
2||| 评价成本
事中
检查、测试、破坏性测试
（2） 非一致性(失败、缺陷)成本
1||| 内部失败成本
事后内
返工、废品
2||| 外部失败成本
事后外
客户发现的，导致债务、保修、业务流失
流程(过程)图
显示步骤顺序和可能分支，帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方
关键字
改进过程
识别潜在缺陷
估算质量成本
预测出错环节
输出
（1） 质量管理计划
质量政策
质量标准(国家标准或行业标准)
质量目标
质量方面的角色和职责
质量管理和控制活动
（2） 质量测量指标
针对具体的可交付成果
2.2.15规划资源管理
了解
马斯洛：需求层次理论
没有好坏之分
赫兹伯格：双因素理论
保健因素
应该的、必备的
麦格雷戈：X理论和Y理论
X理论
用命令+控制管理
Y理论
用支持+协助管理
边际福利、额外待遇、光环效应
项目经理的管理风格
要点：
定义如何估算、获取、管理和利用团队以及实物资源的过程。
两大类资源
（1） 团队资源（人力资源）
（2） 实物资源
输入
(无考点)
工具和技术
数据表现
层级型：有助于明确高层级的角色和职责
（1） WBS
工作分解结构
work
（2） OBS
组织分解结构
organization
（3） RBS
资源分解结构
resources
矩阵型:
（1） 责任分配矩阵（RAM）
高层次RAM可定义项目团队、小组或部门负责WBS中的哪部分工作，低层次RAM则可在各小组内为具体活动分配角色、职责和职权。
（2） RACI 矩阵
A只能有一个
Accountable (负责)
如果团队是由内部或外部人员组成，RACI矩阵对明确划分角色和职责特别有用
（3） 确保任何一项任务都只有一个人负责，避免职责不清。
输出
1||| 资源管理计划
（1） 如何识别资源
（2） 如何获取资源
（3） 角色和职责
角色
职务
职责
职责和工作。
（4） 项目组织图
（5） 培训策略
评估需求，制定策略，执行培训，检查效果
（6） 团队建设
建设项目团队的方法。
（7） 资源控制
既确保资源充足可用，又确保库存合理的方法
（8） 认可计划
何时给予团队成员哪些认可和奖励的说明。
概要
ZLD：以人为主，物为次
2||| 团队章程 （基本规则、工作协议)
也叫：基本规则
作用：减少误解，提高生产力
由团队成员制定或者参与制定，定期审查和更新
例子:会议礼仪
2.2.16规划沟通管理
核心概念
PMP中的沟通仅仅是指信息交换
通过沟通活动(如会议和演讲)，或以工件的方式(如电子邮件、社交媒体、项目报告或项目文档)等各种可能的方式来发送或者接收信息
分类·
（1） 正式
报告、会议记录、工作联系单
（2） 非正式
电子邮件、备忘录
要点：
基于每个干系人或干系人群体的信息需求制定恰当的沟通管理计划：量身定制、舔狗
输入
干系人登记册
工具和技术
沟通需求分析
分析沟通需求，确定项目干系人的信息需求，包括所需信息的类型和格式，以及信息对干系人的价值
沟通渠道的计算
N*(N-1)/2
沟通方法
1||| 推式沟通
发送方将信息发给特定的受众，只管发，不管是否收到是否理解
例如:电子邮件、传真备忘录、报告、新闻稿
2||| 互动式沟通
实时多向的沟通，达成共识效果最好
例如:会议、电话、即时通信、视频会议等
3||| 拉式沟通
接收方主动获取信息，信息量大，受众多的时候使用
例如:企业内网、经验教训数据库、知识库等
沟通风格评估
规划沟通活动时，用于评估沟通风格并识别偏好的沟通方法、形式和内容的技术。
常用于不支持项目的干系人
2个意识
政治意识
对正式或非正式权力关系的认知，以及在这些关系中工作的意愿。
文化意识
理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。
输出
沟通管理计划
（1） 干系人的沟通需求
（2） 需要沟通的信息，包括语言、格式、内容、详细程度
（3） 时限和频率
（4） 授权保密信息发布的人员
（5） 将要接收信息的人员或群体
（6） 通用术语表
可以包括用户沟通的指南和模板
（7） 问题升级程序
用于规定下层员工无法解决问题时的上报时限和上报路径
（8） 相关的法律法规
2.2.17规划干系人参与
要点：
根据干系人的需求、期望、利益和对项目的潜在影响，制定项目干系人参与项目的方法的过程
输入
干系人登记册
工具和技术
干系人参与度评估矩阵
C：当前参与程度
Current
D：期望的（所需）参与程度
Desired
参与水平分类：
领导（主动工作）
支持（被动工作）
中立
抵制
不了解
输出
干系人参与计划
确定用于促进干系人有效参与决策和执行的策略和行动
（1） 干系人当前的参与程度和期望的参与程度
（2） 干系人变更的影响
（3） 干系人之间的相互关系和潜在交叉
（4） 敏感性，预防措施
不能泄露
2.2.18规划风险管理
要点：
定义如何实施项目风险管理活动的过程
核心概念
项目风险：是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标造成积极或消极的影响
积极和消极风险通常被称为机会和威胁
风险的三要素：
风险事件、概率、影响
风险敞口=概率*影响
两个层面的风险
（1）单个项目风险
一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
（2）整体项目风险
不确定性对项目整体的影响，是干系人面临的项目结果正面和负面变异区间
整体项目风险大于项目中单个风险之和
三种性质的项目风险
1||| 已知—已知风险
已识别，可对这些风险规划应对措施。(计入时间/成本)
2||| 已知—未知风险
建立应急储备
3||| 未知—未知风险
使用管理储备，需要走变更流程
影响风险态度的因素
（1） （风险偏好
愿不愿承受
为了预期的回报，一个实体愿意承受不确定性的程度
（2） 风险承受力
能不能承受
组织或个人能承受的风险程度、数量或容量
（3） 风险临界值
要不要管理
反映了组织与项目干系人的风险偏好程度，是项目目标的可接收的变异程度
应该站在中立的角度：风险临界值＜风险偏好＜风险承受力
ZLD
偏好 < 临界值
风险态度：厌恶者
偏好 > 承受力
风险态度：冒进者
项目韧性
抗风险的能力
确实存在只有在发生后才能被发现的突发性风险，需要通过加强项目韧性来应对
整合式风险管理
输入
项目章程
有高层及的风险
干系人（相关方）登记册
工具和技术
干系人（相关方）分析
通过通过干系人（相关方）分析确定项目相关方的风险偏好
输出
风险管理计划
（1） 风险分解结构 RBS
（2） 相关方的风险偏好
（3） 概率和影响定义
（4） 概率和影响矩阵
2.2.19识别风险
要点：
识别单个项目风险以及整体项目风险的来源，并记录风险特征的过程
应鼓励所有项目干系人参与，项目团队的参与尤为重要
识别风险是一个迭代的过程，迭代的频率和每次迭代所需的参与程度应在风险管理计划中做出规定
识别风险过程为单个风险指定临时/潜在责任人，记录初步的潜在应对措施
输入
(无考点)
工具和技术
（1） 头脑风暴
自由或结构化的形式，可以用RBS作为识别风险的框架
（2） 访谈
信任和保密的环境
直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
（3） 核对单
是包括需要考虑的项目、行动或要点的清单，常被用作提醒。
从类似项目和其他信息来源积累的历史信息和知识来编制核对单
确保不要用核对单来取代所需的风险识别工作
注意考察未在核对单中列出的事项
（4） 根本原因分析
问题 放在鱼头的位置寻 找威胁
收益 放在鱼头的位置寻 找机会
（5） 假设条件和制约因素分析
假设条件不成立 识别威胁
制约因素消除/放松 带来机会
（6） 文件分析
（7） SWOT分析
优势Strength、劣势Weakness、机会Opportunity、威胁Threat
优势 可能带来机会
劣势 可能造成威胁
（8） 提示清单
提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单
单个项目风险
可以用风险分解结构RBS的底层作为提示清单
输出
风险登记册
风险登记册：记录已识别单个项目风险的详细信息
包含
（1） 已识别的风险清单
（2） 潜在的责任人
随后由实施定性风险分析过程进行确认风险责任人
（3） 潜在的应对措施清单
不属于项目管理计划，不需要审批
风险报告
提供关于整体项目风险的来源、已识别的单个项目风险的概述信息。编制需要渐进式。
2.2.20实施定性风险分析
要点：
评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序
确认每个风险的责任人，这个人负责后续的工作，包括制定和落实应对措施
输入
风险登记册
工具和技术
（1） 风险数据质量评估
（2） 风险概率和影响评估
对已识别的每个风险都要进行概率和影响评估
低概率和影响的风险将被列入风险登记册中的观察清单，以供未来监控
（3） 概率和影响矩阵
输出
风险登记册更新
2.2.21实施定量风险分析
要点：
量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划
并非所有的风险都可以量化
（并非所有项目都需要实施定量风险分析）
定量风险分析也可以在规划风险应对过程之后展开，以分析已规划的应对措施对降低整体项目风险敞口的有效性。
输入
风险登记册
工具和技术
（1） 访谈
当需要向专家征求信息时
访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。
（2） 不确定性表现方式
需求是不确定的，以在模型中用概率分布
（3） 模拟
关键性分析
通常采用蒙特卡洛分析
（4） 敏感性分析 (是一种单因素分析)
把所有其他不确定因素固定在基准值，考察每个因素的变化会对目标产生多大程度的影响
龙卷风图
(用于比较很不确定的变量与相对稳定的变量之间的相对重要性和相对影响
（5） 决策树分析
用决策树在若干备选行动方案中选择一个最佳方案。
计算每条分支的预期货币价值(EMV)，就可以选出最优的路径。 （ Expected Monetary Value）
输出
风险登记册更新。
2.2.22规划风险应对
要点：
制定应对整体项目风险和单个项目风险的适当方法
风险应对措施必须能获得全体干系人的同意，由一名责任人具体负责(风险应对责任人)
注意次生风险和残余风险
（1） 次生风险
并发症
由于应对一个风险而产生的另一个风险
（2） 残余风险
后遗症
仍然残留的风险
应急计划（弹回计划、备用计划）
指在主计划或主要风险应对措施失效时
针对风险应对策略无效或发生了已经接受的风险
输入
风险登记册
工具和技术
威胁应对策略
（1） 上报
在项目集或项目组合或其他组织管理，不在项目层面
一旦上报，项目团队不再监督
相关人员必须愿意承担应对责任。
（2） 规避
概率或者影响=0
消除威胁或免受威胁影响
延长进度、改变策略、缩小范围、澄清需求、获取信息、改善沟通、取得专有技能、终止项目
适用于高优先级风险
（3） 转移
将应对威胁的责任转移给第三方
保险、使用履约保函、担保、保证书、外包
通常需要支付风险转移费用。
（4） 减轻
采取措施降低威胁发生的概率和(或)影响
采用较简单的流程、进行更多测试、选用更可靠的卖方、原型开发、加入冗余部件
降低到可接受的临界值范围内
（5） 接受
承认威胁的存在，但不主动采取措施
主动接受：建立应急储备；被动接受：仅监督，定期复查
适用于低优先级风险，或者无法有效应对
机会应对策略
（1） 上报
在项目集或项目组合或其他组织管理， 不在项目层面
一旦上报，项目团队不再监督
相关人员必须愿意承担应对责任。
（2） 开拓
确保把握住高优先级的机会
把组织中最有能力的资源分配给项目来缩短完成时间(牛人) 采用全新或升级的技术来节约成本(牛技术)
适用于高优先级机会
（3） 分享
将应对机会的责任转移给第三方，使其享有机会所带来的部分收益
建立合伙关系、合作团队、特殊公司、合资企业
（4） 提高
提高机会出现的概率和(或)影响
增加普通资源缩短工期
（5） 接受
承认机会的存在，但不主动采取措施
主动接受：建立应急储备；被动接受：仅监督，定期复查
适用于低优先级机会，或者无法有效应对
应急应对计划
应对计划
适用于已知风险，需提前规划以降低风险影响或利用机会
应急计划（弹回计划、备用计划）
如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略
指在主计划或主要风险应对措施失效时
针对风险应对策略无效或发生了已经接受的风险
整体项目风险应对策略
没有“上报”
备选方案分析
成本效益分析
输出
风险登记册更新
变更请求
项目管理计划更新
2.2.23规划采购营理
新兴实践
（1） 网络摄像机
进展报告、索赔支持。
（2） 试用采购
先小批量试采，再批量采购
核心概念
项目经理不必成为采购管理法律法规领域的专家，但应对采购过程有足够了解
采购中有任何争议，以合同为依据
要点：
记录项目采购决策、明确采购方法、识别潜在卖方的过程
输入
组织过程资产
1. 预先批准的卖方清单
可以简化招标所需的步骤，并缩短卖方甄选过程的时间
2. 合同类型
一、 总价类合同
范围明确，不允许重大范围变更
分类
（1） 固定总价合同（FFP） Firm Fixed Price Con-tract
大多数买方都喜欢这种合同
（2） 总价加激励费用合同（FPIF） Fixed Price Incentive FeeContract
要设置价格上限，卖方必须完成工作并且要承担高于上限的全部成本
先算总价，和最高限价比较，计算最终总价。
总价=实际成本+目标利润+(目标成本-实际成本)*卖方应承担比例
目标成本(或称:估算成本)
目标利润(或称:目标费用)
分摊比例
买方/卖方
实际利润=最终总价-实际成本
（3） 总价加经济价格调整合同（FPEPA） Fixed Price with Eco-nomic Price AdjustmentContract
卖方履约期将跨越几年，或将以不同货币支付价款。
二、 成本补偿类合同
有范围，但是有可能出现重大范围变更
成本实报实销
分类
（1） 成本加固定费用合同（CPFF） Cost Plus Fixed Fee Contract
（2） 成本加激励费用合同（CPIF） Cost Plus Incentive FeeContract
先算利润，和利润上下限比，计算最终利润。
利润=目标利润+(目标成本-实际成本)*卖方应承担比例
实际总价=最终利润+实际成本
（3） 成本加奖励费用合同（CPAF） Cost Plus Award FeeContract
为卖方报销一切合法成本
主观判断来决定奖励费用，并且通常不允许申诉
三、 工料类合同
没有范围，创新项目
时间紧，任务重
单价合同
概要
混合型合同
适用于:在无法快速编制出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。
四、
工具和技术
自制或外购分析
哪个便宜用哪个
供方选择分析
输出
采购管理计划
（1） 如何协调采购工作与项目的其他工作
（2） 采购中的风险管理事项
招标文件
（1） 应答格式要求
（2） 采购工作说明书SOW
（3） 拟签订的合同条款
采购工作说明书 SOW (Statement of Work)
SOW应该详细描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供
工作说明书中可包括规格、数量、质量、性能参数、履约期限、工作地点和其他需求
在采购过程中，应根据需要对采购SOW进行修订和改进，直到成为所签协议的一部分
自制外购决策
独立成本估算
可自行准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准。
若二者之间存在明细差异，则可能：采购SOW存在缺陷或模糊，或潜在卖方误解或未能完全响应采购SOW
供方选择标准
标准可以是客观或主观的
2.2.24制定项目管理计划
要点：
"装订”所有的组成部分，整合成一份综合的项目管理计划
输入
项目章程
其他(规划)过程的输出
工具和技术
核对单
checklist，可以避免遗漏
会议
kick-off meeting 开工会议，规划的最后一件事情，所属规划过程组
召开时间
规划即将结束，执行尚未开始的时
在会议获得干系人对项目管理计划的一致认可
传达目标、获得团队的承诺、阐明相关方的角色和职责
输出
项目管理计划
范围管理计划
需求管理计划
进度管理计划
成本管理计划
质量管理计划
资源管理计划
沟通管理计划
风险管理计划
采购管理计划
干系人参与计划
概要
九大知识领域、十个子管理计划
变更管理计划
配置管理计划
概要
二个子管理计划
范围基准
进度基准
成本基准
概要
三大基准
项目生命周期描述
绩效测量基准
开发方法
概要
其他组件
2.3 项目执行
2.3.1获取资源
标注
ZLD：组件团队-招兵
要点：
获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程
项目经理应进行有效谈判，并影响那些能为项目提供所需资源的人员。
资源或人员能力不足会降低项目成功的概率，甚至可能导致项目取消
如无法获得所需资源，项目经理可能不得不使用替代资源(也许能力较低，需要培训)
输入
(无考点)
工具和技术
一、 预分派(事先分配好的)
1||| 竞标承诺
竞标过程中承诺分派
2||| 章程指定
项目章程中指定
3||| 专有技能
项目取决于特定人员的专有技能
二、 多标准决策分析
三、 谈判(协商)
（1） 跟职能经理谈判
（2） 跟其他项目管理团队谈判获得特殊稀缺资源
（3） 跟外部组织谈判获得特殊稀缺资源
四、 虚拟团队
需要特别重视"沟通”
云队友
项目团队可分布在不同地理区域；可将在家办公的、行动不便者或残疾人纳入团队
输出
（1） 实物资源分配单
（2） 项目团队派工单
记录了团队成员及其在项目中的角色和职责，可包括项目团队名录
（3） 资源日历
何时可用
ZLD：时间点
可用多久
ZLD：持续时长
2.3.2建设团队
标注
ZLD：打磨
要点：
提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程
塔克曼阶梯理论
（1） 形成阶段:
相互认识，相互独立，不一定开诚布公
（2） 震荡阶段:
冲突、矛盾、不同的观点和意见
（3） 规范阶段:
开始协同工作、开始相互信任
（4） 成熟阶段:
组织有序、相互依靠、平稳高效:
（5） 解散阶段:
释放人员，解散团队
概要
尽管这些阶段通常按顺序进行，然而，团队也可能停滞在某个阶段或退回到较早阶段的情况
如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。(可进、可退、可停)
输入
(无考点)
工具和技术
（1） 集中办公:
增进沟通、增强集体感
（2） 人际关系与团队技能
团队建设（协同工作）
（3） 认可与奖励:
带来激励的作用
注意无形的奖励
全生命周期给予奖励
（4） 培训:
针对技能不足，而不是经验不足
提高能力，减少差异
（5） 个人和团队评估:
有利于增进团队成员间的理解、信任、承诺和沟通
输出
团队绩效评价
（1） 个人能力提高：↑
（2） 团队能力提高：↑
（3） 团队凝聚力加强：↑
（4） 团队离职率下降：↓
2.3.3管理团队
标注
ZLD：着眼于“个体”
要点：
跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。管理冲突、解决问题。
输入
团队章程
为团队应如何决策、举行会议和解决冲突提供指南
工具和技术
冲突管理
冲突管理的顺序
（1） 团队成员自行解决
（2） 项目经理提供协助(私下)
（3） 正式的程序，包括惩戒措施
冲突管理五种方法
（1） 撤退/回避:
退出冲突，推迟解决，推给他人解决
（2） 强迫/命令:
推一方观点，解决紧急问题
（3） 合作/解决问题:
综合考虑不同的观点和意见，合作的态度和开放式对话，引导各方达成共识和承诺
（4） 缓和/包容:
缓和关系，不解决问题，考虑一致性而非差异（求同存异）
（5） 妥协/调解:
一定程度的满意，部分解决问题
情商
通过情商来识别、评估及控制项目团队成员的情绪，预测他们的行动，理解他们的焦虑，帮助解决他们的问题，从而减缓紧张，增进合作
2.3.4实施采购
要点：
实施采购：获取卖方应答、选择卖方并授予合同的过程
输入
采购文档
招标文件
采购工作说明书
独立成本估算
供方选择标准
卖方建议书
工具和技术
1||| 招
广告
2||| 投
投标人会议 (又称承包商会议、供货商会议或投标前会议)
在投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议。
目的是保证所有潜在卖方对采购要求都有清楚且一致的理解，保证没有任何投标人会得到特别优待
3||| 评
建议书评估
4||| 授
授予合同前进行采购谈判
输出
选定的卖方
协议
ZLD考点：
采购的任何争议，先参考协议/合同，后参考工作说明书SOW
2.3.5指导与管理项目工作
要点：
执行项目管理计划中确定的工作
实施已批准的变更请求
输入
项目管理计划
批准的变更请求
工具和技术
项目管理信息系统PMIS系统
输出
（1） 可交付成果
具有可核实性
包括项目管理计划的组成部分
一旦完成了第一个版本(图纸)，修改就需要走变更流程
（2） 工作绩效数据
原始观察结果和测量值
（3） 问题日志
三要素：问题、责任人、解决期限
问题日志随着新问题的出现和老问题的解决动态更新:
（4） 变更请求
可以口头提，但必须书面记录
2.3.6管理质量：QA
要点：
把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程
总结:
管理质量"管过程”，也叫实施质量保证(QA)
输入
质量测量指标
质量控制测量结果
根据结果反思过程
工具和技术
一、 核对单
质量核对单应该与范围基准中定义的验收标准保持协调一致
二、 质量审计
质量审计目标
1. 识别
识别最佳实践、违规做法、差距及不足
2. 分享
分享类似项目的良好实践
3. 协助
协助过程改进、提高生产效率
4. 积累
积累经验教训
5. 确认
确认已批准的变更请求的实施情况
内审或外审
事先安排或随机进行
三、 根本原因分析RCA （Root Cause Analysis）
识别问题的根本原因，杜绝问题的再次发生
四、 过程分析
识别过程改进机会，发现一个过程中存在的问题、制约因素，和非增值活动。
五、 鱼骨图 (鱼骨图、石川图、why-why分析图)
查根本原因或主要原因
追溯问题的来源
五个why、why-why分析
六、 直方图
显示频率和频次
集中趋势，分散程度，分布形状
七、 帕累托图
查主要原因
二八定律
优先排序
有重点地采取措施
八、 散点图 （相关图）
自变量和因变量
是否存在关联关系
九、 DFX
面向X的设计，优化设计的特定方面
十、 问题解决
1. 定义
定义(问题)
2. 识别
识别(根本原因)
3. 方案
方案(生成方案)
4. 选择
选择(最佳方案)
5. 执行
6. 验证
验证(有效性)
十一、 质量改进方法
PDCA
计划，实施，检查，行动
六西格玛
百万分之3.4
输出
质量报告
变更请求
2.3.7管理沟通
标注
拿报告找干系人汇报
要点：
促成项目团队与干系人之间的有效信息流动
输入
工作绩效报告
状态报告
进展报告
问题日志
变更日志
质量报告
工具和技术
项目报告发布
输出
项目沟通记录
2.3.8管理干系人参与
要点：
与相关方进行沟通和协作，以满足其需要与期望，处理问题，并促进相关方合理参与的过程
提高干系人的支持，并尽可能降低干系人的抵制
活动
1. 引导参与，获得支持
2. 谈判沟通，管理期望
3. 处理风险，预测问题
4. 澄清和解决问题
输入
(无考点)
工具和技术
(无考点)
输出
(无考点)
2.3.9实施风险应对
要点：
一个字“干”
只有风险责任人以必要的努力去实施商定的应对措施，项目的整体风险敞口和单个威胁及机会才能得到主动管理
2.3.10管理项目知识
要点：
使用现有知识，生成新知识，支持未来的项目
包括显性知识和隐性知识
（1） 显性知识
缺乏情境，易分享，却无法确保正确理解或应用
文字、图片和数字
（2） 隐性知识
蕴含情境，却很难编撰
信念、洞察力、经验和“诀窍”
最重要的环节：
营造信任的氛围，激励人们分享知识或关注他人知识
输入
经验教训登记册
工具和技术
（1） 知识管理
合作
集成
分享
（2） 信息管理
（3） 人际关系与团队技能
输出
（1） 经验教训登记册
早期创建、整个项目期间不断更新、最终纳入经验教训知识库
有利于未来的项目
（2） 组织过程资产更新
2.4 项目监控
2.4.1 控制范围
要点：
监督范围，管理范围基准的变更
防止范围蔓延和镀金
”镀金“
来自团队内部原因造成的范围蔓延
“讨好”客户而做的
“范围潜变”
来自团队外部原因造成的范围蔓延称
客户不断提出小的、不易察觉的范围改变
如果已经出现范围蔓延，要停止不良变更并补变更流程； 如果变更没有获得批准，需要取消不良变更。
输入
项目管理计划
工作绩效数据
工具和技术
（1） 偏差分析
（2） 趋势分析
输出
工作绩效信息
变更请求
2.4.2控制进度
要点：
详见挣值管理
（Earned Value Management，EVM），又称赢得值管理，是一种综合项目范围、进度和成本的绩效测量与项目监控方法
输入
工具和技术
输出
2.4.3控制成本
要点：
无重要考点
输入
工具和技术
挣值分析 (EVA)
偏差分析
SV和CV，＞0，好 SPI和CPI，＞1，好
完工偏差 VAC
VAC = BAC - EAC
完工估算 EAC
完工尚需估算 ETC
完工尚需绩效指数 TCPI
成本
财务知识
现值
净现值
NPV越大越好
NPV>0----接受该项目;
NPV<0----放弃该项目;
内部收益率 IRR (Internal Rate of Return)
净现值等于零时的折现率
代表了项目抗风险(通货膨胀等)能力的大小。越大越好。
投资回收期PP (Payback Period)
从项目的投建之日起，用项目所得的净收益偿还原始投资所需要的年限。
不考虑货币时间价值，越短越好(PMP只考静态回收期)
投资回报率ROI (Return On Investment)
年平均利润/投资总额X100%
不考虑货币时间价值，年平均利润是全部的利润。越大越好。
效益成本比 BCR (Benefit-Cost Ratio)
项目投资与效益之间关系的比率，收益/投资
越大越好
BCR>1--接受该项目
BCR<1--放弃该项目
输出
2.4.4控制资源
要点：
无重要考点
输入
工具和技术
输出
2.4.5监督沟通
要点：
无重要考点
输入
工具和技术
输出
2.4.6监督干系人参与
要点：
无重要考点
输入
工具和技术
输出
2.4.7监督风险
要点：
在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程
输入
风险登记册
工具和技术
储备分析
风险审计
评估风险管理过程的有效性
会议
风险审查会可以识别出新的单个项目风险(包括次生风险)，重新评估当前风险，关闭已过时风险，总结经验教训
输出
风险登记册更新
2.4.8控制采购
要点：
管理采购关系、监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程
输入
协议
批准的变更请求
合同的变更也需要走流程
工具和技术
索赔管理
1.谈判
2.ADR（替代争议解决方法）
3.起诉
采购绩效审查
审查供应商的过程
检查
检查供应商的可交付成果
采购审计
对采购过程的结构化审查
总结经验教训，有利于未来的采购
输出
采购关闭
2.4.9监控项目工作
要点：
整合工作绩效信息，形成工作绩效报告
输入
工作绩效信息
进度预测
成本预测
工具和技术
备选方案分析
成本效益分析
挣值分析
根本原因分析RCA
趋势分析
偏差分析
输出
工作绩效报告
2.4.10实施整体变更控制
要点：
贯穿始终，项目经理承担最终责任
任何干系人都可以提出变更，甚至可以口头提
可以先了解变更的内容或者变更的原因是什么
变更5步骤
0步：创建
1、记录
书面记录变更请求;
项目经理书面记录(变更日志)，或要求变更提出者提交书面的变更请求。
2、评估
充分了解变更，评估变更带来的影响;与相关的干系人沟通评估出的影响。
3、提交
指“项目经理”将变更请求和评估的结果提交给CCB
4、更新
不管变更通过还是不通过，必须更新变更日志；如果变更通过，更新项目管理计划(文件)
5、通知
应将变更的结果通知相关(受影响)的干系人
输入
项目管理计划
变更请求
工具和技术
变更控制工具
输出
批准的变更请求
项目文件更新
被否决的变更请求也应该记录在变更日志中
项目管理计划更新
考点
变更请求批准人的选择顺序
变更控制委员会(CCB) ＞ 指定的责任人 ＞ “PMO”、“发起人”、“项目经理”
2.4.11 控制质量：QC
要点：
核实项目可交付成果和工作已经达到主要干系人的质量要求
总结
控制质量“查结果”，QC
输入
质量测量指标
可交付成果
批准的变更请求
工具和技术
核对单
核查表
计数表
又经常使用帕累托图来显示
统计抽样
检查
控制图
用来确定一个过程是否稳定，或者是否具有可预测的绩效
控制界限和规格线
失控的两种情况
1、某个数据点超出控制界限;
2、连续7个点落在均值上方;3、连续7个点落在均值下方;
输出
质量控制测量结果
核实的可交付成果
变更请求
2.4.12确认范围
要点：
Validate Scope
通过验收每个可交付成果来提高收尾的可能性
输入
核实的可交付成果。
工具和技术
检查
输出
验收的可交付成果
验收的可交付成果需要客户或者发起人正式签字批准
变更请求
如果可交付成果没有通过验收:
1.记录未通过验收的原因
2.走变更流程做缺陷补救或纠正
2.5 项目收尾
2.5.1结束项目或阶段(收尾)
收尾的步骤
1. 获得验收
可以开展干系人满意度调查
1、如果提前终止要说明原因
2. 移交成果
3. 总结经验教训
4. 更新组织过程资产
5. 文件归档
6. 释放资源
释放资源之前可以开庆功会
输入
项目章程
成功标准
退出标准
验收的可交付成果
组织过程资产
项目或阶段的收尾指南或要求
工具和技术
会议
输出
最终的产品、服务或成果移交
最终报告
组织过程资产更新
项目或阶段收尾文件
3 敏捷
敏捷概述
生命周期类型
1. 预测型生命周期
范围明确、有厚实的经验基础、计划驱动，也叫瀑布型
ZLD
通过变更流程修改计划
项目结束时才能显现价值
应对市场变化不灵活
2. 混合型生命周期
（1） 可以实现预测向敏捷的过渡
（2） 可以在风险不大，具有中低程度不确定性的项目中尝试
3. 敏捷(适应型)生命周期
快速应对变化，以较小的增量，快速迭代，每次增量都注重价值
MVP：最小可行产品 (Minimum Viable Product)
定义
最小可行产品，符合产品预期的最小功能集合。在MVP的基础上继续快速迭代，直到产品稳定。
ZLD
最小：必备功能
可行：能用
作用
快速试错
快速获取市场反馈
典型场景
（1）不知道市场是否欢迎
（2）不知道是不是客户想要的
（3）时间比较紧或者预算有限的情况下需要发布产品
ZLD
（4）需求不明确
（5）时间/成本不够
（6）有竞品出现
（7）适用于创业团队
敏捷宣言和原则
一、 敏捷宣言
（1） 个体以及互动 胜过 过程和工具
（2） 可用的软件 胜过 完整的文档
（3） 客户合作 胜过 合同谈判
（4） 应对变更 胜过 遵循计划
二、 敏捷十二原则
（1） 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
及早
持续不断
价值驱动交付
客户满意
（2） 欣然面对需求变化，即使在开发后期也一样。为了客户的竟争优势，敏捷过程掌控变化。
拥抱变更
提高客户竞争优势
（3） 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
频繁交付
短周期
（4） 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
业务和开发相互合作
每天如此
（5） 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
提供环境
支持团队
对团队辅以信任
ZLD：仆人式领导
（6） 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
面对面沟通效果最好（ZLD：线下形式，非线上，提倡集中办公）
也可使用虚拟沟通
1. 鱼缸窗口
一种建立共享虚拟工作空间以容纳分教在多个位置的团队成员的方法。个人可以在工作日开始时加入实时视频流，并在工作日结束时将其关闭。这种方法旨在增强团队协作。
2. 远程结对
（7） 可工作的软件是进度的首要度量标准
根据可工作的软件度量
（8） 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
可持续开发
步调稳定
（9） 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
重构
不改变软件功能的前提下优化代码结构，以提高可维护性和可扩展性。敏捷开发强调通过持续重构来偿还技术债务，避免代码腐化。
（10） 以简洁为本，它是极力减少不必要工作量的艺术。
简洁
专注目标
（11） 最好的架构、需求和设计出自自组织团队。
自组织团队
（12） 团队定期地反思如何能提高成效，并依此调整自身的行为表现
定期回顾
不断改进
ZLD：PDCA循环
敏捷实践
scrum
基于迭代冲刺的敏捷项目管理框架
ZLD：Scrum 的核心：3-3-5-5
三个角色
（1） 产品负责人
Product Owner
（2） 敏捷教练
Scrum Master
（3） 开发团队
Dev Team
三个工件
（1） 产品待办事项列表
Product Backlog
（2） 冲刺待办事项列表
Sprint Backlog
（3） 产品增量
五个事件
（1） Sprint
（2） Sprint 计划会议
（3） 每日站会
（4） Sprint 评审会议
（5） Sprint 回顾会议
五个价值观
承诺、专注、开放、尊重、勇气
三个角色
1. 产品负责人PO
PO是负责管理产品待办事项列表PB的唯一责任人
清晰描述产品待办事项列表ProductBacklog(PB)
对列表项进行优先级排序
确保PB透明清晰
确保开发团队对PB有足够深的了解
团队可以参与上述工作，但是责任人还是PO
改变PB的优先级都需要经过PO产品负责人
常见考点
1||| 需求不明确，可以与PO和干系人(客户)澄清
2||| PO是某个业务专家，但一般不会由Scrum Master兼任
3||| PO决定接受或拒绝每次Sprint完成的增量
2. 开发团队
由组织创建并得到授权
（1）自组织
自主进行任务的估算、自主决定任务的分配、自行决定任务具体怎么执行
总结来说执行层面的工作自己决定
（2）跨职能
团队拥有创建产品的全部技能，T型人才一专多能
有利于协作、交叉培训和结对
（3）去中心化
不认可任何头衔，不管承担什么工作都叫开发人员，没有多个层级，也不认可子团队(比如测试、架构等等)
（4）相对稳定
一般3~9人，比较稳定，建议全职
（5）主动学习
愿意接受挑战，主动要求成长
（6）一般不包括PO和Scrum Master，除非他们也参与执行Sprint待办事项中的工作
常见考点
1||| 自行决定任务的分配
2||| 自行决定用什么方式完成任务
3||| 负责所有估算工作
4||| 强调团队协作
3. Scrum Master
服务型领导(仆人式领导)
也被称为项目经理、Scrum主管、团队促进者等
（1）、服务于产品负责人
确保团队理解目标
找到有效管理PB的技巧
确保产品负责人了解如何安排PB
帮助理解并实践敏捷性
（2）、服务于团队
作为教练在自组织和跨职能方面给予指导
移除开发团队工作中的障碍
在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队
（3）、服务于组织
作为教练指导组织采纳Scrum
帮助干系人理解并实施Scrum
引发提升团队生产率的改变
增强组织中Scrum应用的有效性
常见考点
1||| 仆人式领导提供协作和支持，而不会去命令和控制
2||| 不会去分配任务，不会去下达指示
3||| 当PO、团队或者其他干系人(比如客户)不了解敏捷时要提供培训，服务于各方
4||| 当团队遇到障碍，应该帮助团队扫清障碍
三个工件
1. 产品待办事项列表PB
用户故事
作为一个〈角色>，我想要〈功能>，以便于实现〈价值>
涵盖产品的已知需求
包括所有的特性、功能、需求、增强和修复
按照优先级排序，优先级越高则越详细
KANO模型*5
用户满意度与功能实现程度的关系
基本型需求（Must-be）：
产品必须具备的基础功能，缺失会导致用户极度不满，满足则用户认为理所当然，如手机的通话功能、电商的支付功能。
期望型需求（One-dimensional）：
用户明确期望的功能，满足度与满意度呈正比，如手机续航时间、软件启动速度。
兴奋型需求（Attractive）：
用户未主动提及但能带来惊喜的功能，满足会大幅提升满意度，如手机的AI拍照功能、酒店的免费房型升级。
无差异型需求（Indifferent）：
无论是否实现，对用户满意度无影响，如APP图标颜色微调。
反向型需求（Reverse）：
实现后反而降低用户满意度，如强制弹窗广告。
MoSCoW法*4
Must-have：
必须实现的需求，缺失则项目无法交付，如电商的支付功能、软件的核心登录功能。
Should-have：
重要但非必需的需求，缺失会影响版本质量，但可推迟到后续版本，如电商的保存常用支付方式。
Could-have：
锦上添花的需求，有额外资源时实现，如支付成功后分享至社交媒体。
Won't-have：
当前版本不实现的需求，明确排除，为未来版本规划提供参考。
优先级较高的，可以交给开发团队去开发的用户故事应该符合就绪的定义DOR(Definition of Ready)
验收标准清晰
更清晰、更具体
由产品负责人PO负责
（负责：内容、可用性、优先级）
最后的估算是由执于工作的人来决定的。
2. Sprint冲刺（迭代）待办列表 Sprint Backlog
为当前Sprint选出的产品待办事项
至少包括一项在前次回顾会议中确定的高优先级的改进
团队成员主动领取任务(而不是由其他人分配任务)。
是一份足够具体的计划，
3. 增量
一个Sprint完成的所有待办事项的总和，以及之前所有Sprint所产生的增量的价值总和
必须达到"完成”的定义标准DOD(Definition of Done)
测试要通过
无论产品负责人是否决定发布，增量必须可用
重构
技术负债(Technicaldebt)
指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。
五个事件
1. Sprint
长度固定(一般2~4周)
包括：Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会、Sprint回顾会议
Sprint期间的注意点
在整个开发过程期间，Sprint的长度通常保持一致（规定的“时间盒”）
不能做出有害于Sprint目标的改变
Sprint期间不变更
变更不应该纳入到Sprint待办事项中，变更纳入到PB产品待办事项中
不能降低质量
产品负责人和团队之间可以对要做的事情加以澄清
未完成的待办事项都会放回到PB中，重新估算和排序
Sprint 可以在Sprint结束之前取消，只有产品负责人有权取消Sprint，但是由于Sprint都短，取消的意义不大
Sprinti计划会议（P）
计划Sprint要做的工作，整个Scrum团队共同完成
有时间盒限定：
2周的Sprint，一般4小时；一个月的Sprint，最长8小时
Scrum Master确保会议举行，每个参会者都要理解会的目的并遵守时间盒的规则
会议回答两个问题
Sprint要交付的增量包括什么
如何完成交付增量所需的工作
在计划会议中确定Sprint目标
产品负责人PO帮助解释所选的产品待办事项
开发团队自己决定选择产品待办事项列表的数量
开发团队决定如何完成选定的产品待办事项
开发团队可以邀请其他人员参加会议以获取相关的知识或建议
由于每个团队选取的基准用户故事不同，不同的敏捷团队每个Sprint 完成的故事点不具有可比性。 完成的故事点并不是越多越好，而是越稳定越好。团队的速率一般需要经过多个Sprint才能稳定。
故事点(Story Point)和相对估算
选择一个最简单的用户故事作为基准，来衡量其他的用户故事的工作量是多少个故事点
好处
（1） 团队参与
（2） 容易达成共识
刺探/探测/探针(Spike)
一种快速而简陋的实现，是作为将被丢弃的试验品而设计的
每日Scrum会议(站会)（D）
借助站会检视完成Sprint目标的进度，检视Sprint待办列表的进度
时间盒限定为15分钟的事件，每天举行
会议的作用
增进沟通，同步信息
减少其他会议
发现需要移除的障碍
提高开发团队认知程度
会议内容
（1） 昨天，我为帮助开发团队达成Sprint目标做了什么?
（2） 今天，我为帮助开发团队达成Sprint目标准备做什么?
（3） 是否有任何障碍在阻碍我或开发团队达成Sprint目标?
注意点
每日Scrum站会上只记录问题不讨论问题，会后可以进行更详细的讨论
Scrum Master确保开发团队每日站会如期举行，但开发团队自己负责召开会议。
每日Scrum站会在同一时间同一地点举行，以便降低复杂性。
每日Scrum站会是开发团队的内部会议。
如果有开发团队之外的人出席会议，Scrum Master必须确保他们不会干扰会议进行。
只有开发团队成员才能参加(其他干系人也可以参加，但不能发言干扰会议)。
如果有多个敏捷团队为一个项目工作，需要召开SOS会议(Scrum of Scrums)
同步更新信息发射源/信息扩散器(更新信息发射源中的看板、燃尽图/燃起图、累积流量图、障碍板等等)
信息发射源
特点
可视化
：通过图表、图形、颜色等视觉元素，将复杂的信息转化为易于理解的形式。
实时性
：及时反映项目的最新状态，确保信息的准确性和时效性。
简洁性
：只展示关键信息，避免信息过载，让观众能够快速抓住重点。
位置显眼
：放置在团队工作区域的显眼位置，方便大家随时查看。
类型
任务看板
任务状态，如待办、进行中、已完成等
进度图表
甘特图、燃尽图等
问题列表
问题和风险，包括问题的描述、负责人、解决状态等
指标仪表盘
进度偏差、成本偏差、质量指标等
累积流量图
关注各流程阶段任务量的累积分布。图表呈现为面积图（纵轴为任务数量，横轴为时间），用不同颜色的色带展示任务在“待办、进行中、已完成”等各个流程阶段的累积数量。
Sprint评审会议（C）
在Sprint快结束时举行，用以检视所交付的产品增量，并按需调整PB
有时间盒限定：
2周的Sprint，一般2小时:对于一个月的Sprint，最长4小时
整个Scrum团队和干系人参加
评审内容
团队演示“完成”的工作
为了获取反馈并促进合作。
PO说明哪些已经完成，哪些没有完成
参会的所有人就下一步工作进行探讨
评审接下来要做的最有价值的东西的改变
评审会议的结果是一份修订后的PB产品待办事项列表，阐明很可能进入下一个Sprint的产品待办事项
Sprint回顾会议（A）
评审会议之后，下个Sprint之前开
团队检视自身，并创建下一个Sprint改进计划的机会
有时间盒限定：
2周的Sprint，一般1~2小时:对于一个月的Sprint，最长3小时
Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。
产品待办事项列表梳理会
澄清或细化用户故事，审查优先级等工作，一般不超过团队产能的10%的时间
五大价值观
（1） 勇气
有勇气做出承诺，履行承诺，接受别人的尊重
（2） 承诺
愿意对目标做出承诺
（3） 专注
把你的心思都用到你承诺的工作上去
（4） 开放
Scrum把项目中的一切开放给每个人
（5） 尊重
每个人都有他独特的背景和经验
看板系统
可视化管控
拉动式
消除瓶颈
JIT
极限编程
测试驱动开发 TDD
含义：先写测试代码再编写程序
类似的还有验收测试驱动开发 ATDD，行为驱动开发 BDD
重构
解决技术债务
结对编程
两个程序员，一个人负责写编码，而另一个负责保证代码的正确性与可读性。
代码集体所有
所有的人对于全部代码负责。
持续集成
提倡在一天中集成系统多次
敏捷中各个知识领域
1. 整合管理
团队自行决定计划及其组件的整合方式(自组织)
项目经理负责营造一个合作型的决策氛围
团队如果是T型人才有助于合作并解决知识孤岛
项目章程
为什么要做这个项目
谁会从中受益，如何受益
达到什么条件意味着项目完成
将怎么合作
2. 范围管理
先为整个项目确定一个高层级的愿景
多次迭代开发可交付成果
每次迭代开始定义详细范围
Sprint 计划会议
Sprint Backlog
干系人持续参与
有目的地构建和审查原型
增量
每次迭代都会确认范围和控制范围
Sprinti评审会议
专注Sprint目标，不能做出有害于Sprint目标的改变
3. 进度管理
实践
具有未完项的进度计划
Scrum
按需进度计划
看板
WIP限制（Work In Progress Limit，在制品限制）
消除瓶颈
敏捷发布规划
产品愿景、产品路线图(高层级)
发布计划（高层级）
每个产品版本需要多少次迭代
迭代计划
Sprint中的详细用户故事（最小可交付单元）
控制进度
燃尽图
燃起图
4. 成本管理
轻量级方法生成高层级预测
详细的估算适用于采用准时制的规划
5. 质量管理
完成的定义DOD
测试驱动开发、行为驱动开发、验收测试驱动开发
持续集成
Sprint回顾会议
代码集体所有
全员责任
6. 资源管理
集中办公
T型人才
协作型团队
自组织任务分配
交叉培训
团队章程
团队价值观
工作协议
DOR
DOD
时间盒
WIP
基本规则
团队规范
7. 沟通管理
透明、高效
信息扩散器(看板、燃尽图、燃起图、累积流图、障碍板)
面对面
虚拟沟通
（1） 鱼缸窗口
（2） 远程结对
多个敏捷团队沟通
Scrum of Scrums(SoS会i议)
追逐太阳（跨时区团队协作）
8. 风险管理
经常审查增量，加快知识分享
在迭代规划的时候考虑风险，在迭代期间识别、分析和管理风险
根据风险敞口的理解加深，重新排列优先级
9. 采购管理
客户协作高于合同谈判
灵活的协议
多层结构
主协议和补充文件
关注用户故事而非整个项目的预算
动态范围方案
提前取消方案
资助团队而非范围
10. 干系人管理
频繁参与
高效透明的沟通
常见的干系人管理
反复看
20、24、25
PMP
第1章： 引论
1. PMBOK 指南
（1） ➢ 是“指南”而非“具体的方法论”
（2） ➢ 只针对“单个项目”，不针对项目集、项目组合
（3） ➢ “普遍认可”（大多数时候适用于大多数项目）
（4） ➢ “良好实践”（能够提高很多项目成功的可能性）
（5） ➢ “裁剪”（确定过程、输入、工具、技术、输出和生命周期阶段的恰当组合）
（6） ➢ 项目管理业界定义的最重要的价值观：责任、尊重、公正、诚实。
2. 什么是项目
项目：是为创造独特的产品、服务或成果而进行的临时性工作
（1） 项目的“独特性” (P- 4）
1||| 项目的“独特性”
项目所创造的产品或服务在一定的程度或在某些方面与其他的产品和服务相比较，有明显的差别
（独特性带来不确定性）
不同的裁剪
2||| 可交付成果
在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
核实QC；验证交付
（可能有形，可能无形）
3||| 某些项目可交付成果和活动中可能存在重复的元素，但这种重复并不会改变项目本质上的独特性
（2） 项目的“临时性” (P- 4）
1||| 项目有明确的起点和终点
2||| “临时性”并不一定意味着项目的持续时间短
临时性≠时间短
3||| 项目是临时性工作，但其可交付成果可能会在项目的终止后依然存在。（项目临时，结果持久）
（3） 项目驱动变革 (P-6）
项目驱动组织进行变革：从商业角度来看，项目旨在推动组织从一个状态（当前状态）转到另一个状态（将来状态），从而达成特定目标。
（4） 项目创造商业价值 (P-7）
项目的“商业价值”：项目的成果能够为相关方带来的效益，效益可以是有形的、无形的或两者兼有之
有形效益：货币资产、股东权益、固定设施、工具、市场份额等
无形效益：商誉、品牌认知度、公共利益、战略一致性等
3. 项目终止的几种情况
1||| 达成项目目标（做完了）
2||| 不会或不能达到目标（做不完）
3||| 项目资金缺乏或没有可分配资金（没钱做了）
资金（钱）≠资源
4||| 无法获得所需人力或物力资源（没资源做了）
资源=人力+实物（设备、材料...）
5||| 项目需求不复存在（客户要求终止、组织管理层要求终止、战略或优先级变更致使终止）（不用做了）
6||| 法律或便利原因终止（不让做了）
便利原因：甲方便利，因出现某些原因二终止项目
4. 什么是项目管理
项目管理：将知识、技能、工具与技术应用于项目活动，以满足项目的要求
（1） 项目是组织创造价值和效益的主要方式
（2） 为了在全球经济中保持竞争力，公司日益广泛利用项目管理，来持续创造商业价值。
（3） 有效和高效的项目管理应被视为组织的战略能力。
（4） 有效的项目管理可以帮助：
1||| 管理制约因素（例如范围、质量、进度、成本、资源）
2||| 平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）
5. 什么是项目集和项目组合
（1）项目集：
关注协调，集合是绑定
方式正确
是一组相互关联且被协调管理的“项目、子项目集和项目集活动”，以便获得分别管理所无法获得的利益（1+1>2的效果）
（2）项目组合：
关注优先级，关注选择，组合是分散
选择正确
是指为了实现战略目标而组合在一起管理的“项目、项目集、子项目组合和运营工作”，它们不一定彼此依赖或者相关
6. 什么是运营
运营：是一种生产重复性结果的持续性工作
项目往往来自运营，又服务于运营
项目与运营会在产品生命周期的不同时点交叉。在每个交叉点，可交付成果及知识在项目与运营之间转移，以完成工作交接。
7. 什么是组织级项目管理 OPM
OPM：为实现战略目标而整合项目组合、项目集和项目管理与组织驱动因素的框架
OPM旨在确保组织开展正确的项目并合适地分配关键资源
8. 项目管理的关键要素
（1） ➢ 项目生命周期
项目生命周期：项目从启动到完成所经历的一系列阶段。这些阶段之间的关系可以顺序、迭代或交叠进行
项目通用生命周期
开始项目；组织与准备；执行项目工作；结束项目
（1）成本与人力投入：
项目开始时“缓慢增加”，在“执行工作”期间达到最高，项目快结束时“迅速回落”
（2）风险与不确定性、相关方的影响力、变更的数量：
项目开始时最大，后续“逐步降低”
收尾要快，防止拖延 变更越晚，成本越高
（3）变更的代价、风险的影响：
项目开始时较小，后续“显著增高”
什么是开发生命周期 (P-19)
开发生命周期：项目生命周期内与（产品、服务或成果的）开发相关的一个或多个阶段。
开发生命周期可以是：
1||| 预测型
（瀑布型、计划驱动）
80%的项目类型
范围、进度、成本在早期阶段就确定
按计划执行、一次交付
适用：充分了解产品；有厚实的行业基础；
（建筑业）
2||| 迭代型
总结：从“模糊”到“清晰”
迭代方法是通过一系列重复的循环活动来开发产品
范围在早期确定，但时间及成本估算将随项目团队对产品理解的不断深入而定期修改（重复的循环）
整体迭代
3||| 增量型
总结：从“部分”到“整体”
在预定的时间区间内渐进增加产品功能的一系列增量来产出可交付成果。只有在最后一次增量之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
4||| 适应型
（敏捷型）
较小的增量，相关方频繁参与，部分迭代
敏捷的特点：
较小的增量：每次均交付“最有价值”的功能
快速的迭代：一般2~4周一个迭代
频繁交付，相关方频繁参与
适用于创新项目，需要快速应对变化
适用：需应对快速变化的环境；需求和范围难以事先确定；
5||| 混合型
6|||
什么是产品生命周期 (P-19)
产品生命周期----一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。
5阶段
典型的产品生命周期一般可分为四个阶段：
投入期、成长期、成熟期、衰退期
（2） ➢ 项目阶段
概念：一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束
项目阶段的其中一个关键组成部分是阶段审查
阶段的属性是可测量且独特的，属性包括
阶段名称、阶段的数量、持续时间、资源需求、阶段的准入标准、阶段的退出标准
（3） ➢ 阶段关口
阶段与阶段之间：包括审查、决策
阶段关口----也可被称为阶段审查、阶段门、关键决策点、阶段入口、阶段出口、里程碑
（4） ➢ 项目管理过程
概念：是为完成预定的产品、成果或服务而执行的一系列相互关联的行动和活动
每个过程都有各自的输入、工具和技术以及相应输出
（5） ➢ 5大过程组
1启动、2规划、3执行、4监控、5收尾
（6） ➢ 10大知识领域
概念：按所需知识内容来定义的项目管理领域
1项目整合管理、2项目范围管理、3项目进度管理、4项目成本管理、5项目质量管理 6项目资源管理、7项目沟通管理、8项目风险管理、9项目采购管理、10项目相关方管理
（7）
（8）
9. 工作绩效数据、工作绩效信息、工作绩效报告
数据→（分析）→信息→（整合）→报告
客观的数据，主观的信息，到客观的报告
10. 项目管理商业文件 - 项目商业论证
项目商业论证
概念：指文档化的经济可行性研究报告，用来对尚缺乏充分定义的所选方案的收益进行有效性论证，是启动后续项目管理活动的依据。
商业论证列出了项目启动的目标和理由。 它有助于在项目结束时根据项目目标衡量项目是否成功
商业分析师
进行商业论证分析
项目发起人
负责项目商业论证文件的制定和维护
项目经理
负责提供建议和见解，确保各文件中的成功标准相一致，与组织的目的和目标保持一致
商业论证内容
1. 业务需要；
2. 形式分析；
3. 推荐；
4. 评估；
11. 项目管理商业文件 - 项目效益管理计划
项目效益管理计划
概念：描述了项目实现效益的方式和时间，以及应制定的效益衡量机制
包括记录以下内容
1. 目标效益
2. 战略一致性
3. 实现效益的时间
4. 效益责任人
5. 测量指标
6. 假设
7. 风险
项目效益
概念：为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果
12. 项目成功标准
确定项目是否成功，除了应达到时间、成本、范围和质量等项目管理测量指标外，还应考虑项目目标的实现情况，这些项目目标可能包括： ----完成项目效益管理计划； ----达到商业论证中记录的财务指标（NPV、ROI、IRR、PBP、BCR等） ----完成组织从“当前状态”转到“将来状态； ----履行合同条款和条件； ----使相关方满意； ----达到组织战略、目的和目标； ----…………
13. 第一章重点总结
第2章： 项目允许环境
1. 什么是事业环境因素
不可控，需遵守
概念：事业环境因素（EEFs）----项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。 这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。
分类
（1） 内部：
1. 组织文化、结构和治理
2. 设施和资源的地理分布
3. 基础设施
4. 信息技术软件
5. 资源可用性
6. 员工能力
（2） 外部：
1. 市场条件
2. 社会和文化影响与问题
3. 法律限制
4. 商业数据库
5. 学术研究
6. 政府或行业标准
7. 财务考虑因素
8. 物理环境要素
2. 什么是组织过程资产
可裁剪，多积累
概念：组织过程资产----执行组织特有并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管 理。在整个项目期间，项目团队成员可对组织过程资产进行必要的更新和增补。
供未来作参考，项目全过程更新
包括
1||| 工件、实践或知识；
2||| 经验教训和历史信息
3||| 完成的进度计划、风险数据和挣值数据
分类
1||| 过程、政策和程序：
指南和标准、模板、供应商清单和合同协议类型、变更控制程序、组织对沟通的要求...
2||| 组织知识库：
配置管理知识库、财务数据库、测量指标数据库、经验教训知识库，以往项目的档案...
3. 组织结构
分类
（1） 传统的组织结构
（2） 考试默认使用：矩阵型
分类
1||| 强矩阵
全职项目经理
项目经理＞职能经理
2||| 平衡矩阵
兼职项目经理
项目经理≤职能经理
需要谈判和协商
考点*5
先记中间
（3） 其他一些类型
有机型或简单型组织（Organic or simple organization）----是英国理论家Tom Burns和 George Stalker最初描述的一种非正式组织。有机组织是一个非常灵活的组织，能够很好 地适应变化。它的结构是：工作专业化少，管理层次少，决策分散，监督不多。
创业型
多部门组织（ Multi-divisional ）----一个中心，多个部门或分区，这些分区实行半自治，中心对其下达财务指标。比如按照区域划分部门，每个部门有重复的职能，不集中。
虚拟型组织----临时把人员召集起来，以利用特定的机遇，待目标完成后即行解散的一种临时组织。虚拟组织结构，也称为网络型组织
4. 项目管理办公室 (P-48）
项目管理办公室（PMO）----是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具 和技术共享的一个组织结构。PMO所支持和管理的项目不一定彼此关联。
总裁办/QA部门
PMO的类型（“支控指”）
1||| 支持型：
支持，是顾问、项目资源库，对项目控制程度很低
比较少
2||| 控制型：
支持+要求服从，对项目控制程度中等
比较多
关注项目的大方向
3||| 指令型：
直接管理和控制，对项目控制程度很高。
具体到项目细节
PMO 对项目经理支持的方式（P-49 ）
1||| （管理功能）
管理“共享资源”，识别和制定“最佳实践”和“标准”
2||| （监督功能）
通过“项目审计”，监督对“标准”的遵守程度
3||| （指导培训功能）
制定和管理政策、程序、模板，提供指导和培训
4||| （协调功能）
协调“跨项目”的沟通
第3章： 项目经理的角色
1. 什么是项目经理
概念：由执行组织委派，领导团队实现项目目标的个人
老大制定，马仔执行
项目经理无需承担项目中的每个角色，但应具备项目管理知识、技术知识、理解能力和相关经验。
项目经理通过沟通向项目团队提供领导、规划和协调的职能。
项目经理的沟通
分实时沟通（会议、口头沟通等）
非实时沟通（书面沟通、文档计划等）
2. 项目经理的影响力范围
（1） 项目
➢领导项目团队实现项目目标和相关方的期望； ➢ 利用可用资源，以平衡相互竞争的制约因素； ➢ 充当项目发起人、团队成员与其他相关方之间的 沟通者，包括提供指导和展示项目成功的愿景
（2） 组织
➢ 积极地与其他项目经理互动； ➢ 扮演强有力的倡导者角色，与项目发起人合作处 理内部的政治和战略问题； ➢ 提高自己在组织内的总体项目管理能力和技能
（3） 行业
➢ 时刻关注行业的最新发展趋势； ➢ 思考这一信息对当前项目是否有影响或可用
（4） 专业学科
➢ 持续的知识传递和整合
（5） 跨领域
➢ 指导和教育其他专业人员项目管理方法 ➢ 担任非正式的宣传大使
3. 项目经理的能力
PMI人才三角
（1） 技术项目管理技能
有效运用项目理知识实现项目集或项目的预期成果的能力
PMP
（2） 战略和商务管理技能
纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力
与行业有关
（3） 领导力技能
指导、激励和带领团队的能力（协商、抗压、沟通、解决问题、批判性思考、人际关系技能）
软技能
多学习公司销售+好项目经理
领导者的品质和技能
1||| 积极乐观
2||| 终身学习，结果导向
3||| 能运用批判性思维
4||| 关注重要事情
5||| 管理关系和冲突
6||| 正确沟通
7||| 有远见
卓越领导者的五种行为习惯 – 巴 里 · 波斯纳
1||| 率先垂范
2||| 共启愿景
3||| 挑战陈规
4||| 授权于人
5||| 鼓舞人心
了解项目经理的5种权力（ Power ）
了解项目经理的几种领导力风格（P-65 ）
（1） 放任型
或称“无为而治”，允许团队自主决策和设定目标，有利于创新
（2） 交易型
关注目标、反馈和成就以确定奖励，例外管理
（3） 服务型
服务优先于领导，处处先为他人着想；关注他人的成长、学习、发展、人际关系、团体与合作
（4） 变革型
通过理想化特质和行为、鼓舞性激励、促进创新和创造，以及个人关怀提高追随者能力
（5） 魅力型
精神饱满、热情洋溢、充满自信、说服力强、能够激励他人。
（6） 交互型
结合了交易型、变革型和魅力型的特点。
（7）
执行整合
整合的三个层面
（1） 背景层面
（2） 认知层面
（3） 过程层面
复杂性的三个维度
（1） 系统行为
（2） 人类行为
（3） 不明确性
4.
第4章：项目整合管理
1. 十大知识领域学习的重点
What----每个子过程的定义； Why----每个子过程的作用； How----每个子过程的ITTO；
2. 什么是ITTO
输入（Input）：依据是什么、参考什么、应该审查什么。
工具和技术（Tool & Technology） ：用什么方法、用什么技术。
输出（Output）：下一步制定什么、是为了做什么、记录在什么文件中。
3. 项目整合管理的“核心概念 ”
（1） 在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终。
（2） 项目整合管理由项目经理负责，并且整合管理的责任不能被授权或者转移。
（3） 项目经理必须对整个项目承担最终责任。
（4） 项目越复杂，相关方的期望越多样化，就需要越全面的整合方法。
4. 项目整合管理的“发展趋势和新兴实践”
（1） 项目整合管理知识领域要求整合所有其他知识领域的成果。
（2） 与整合管理过程相关的发展趋势包括：
1||| 使用自动化工具（如PMIS）
2||| 使用可视化管理工具（便于看到实时状态，促进知识转移，促进相关方参与到问题解决中）
3||| 项目知识管理（应对项目人员的流动性和不稳定性）
4||| 增加项目经理的职责（项目经理被要求介入启动和结束项目，例如开展商业论证和效益管理）
开展商业论证：发起人批准
开展商业论证：项目经理做
5||| 混合型方法（敏捷或其他迭代做法、商业分析技术--BA、组织变革管理方法等混合使用）
5. 整合管理过程
1. 整合管理过程之一“制定项目章程 ” （启动过程组）
（1） 概念：制定项目章程----编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程
（2） “制定项目章程”的几个注意点
1||| 项目章程在项目执行组织与需求组织之间建立起伙伴关系。
即：乙方和甲方
2||| 经批准的项目章程意味着项目的正式启动。
3||| 项目由项目以外的实体来启动，如发起人、项目集或项目管理办公室等等。
4||| 尽早确认并任命项目经理，项目经理应该参与项目章程的制定，以便对项目需求有基本的了解。
5||| 最好在制定项目章程时就任命，最晚也必须在规划开始之前。
6||| 通过编制项目章程，来确认项目符合组织战略和日常运营的需要。
7||| 在执行外部项目时，通常需要用正式的合同来达成合作协议。
8||| 不要把项目章程看做合同，因为其中未承诺报酬或金钱或用于交换的对价。
章程≠合同
（3） 制定项目章程 — 输入
1. ：商业文件
概念：商业文件----包含关于项目目标以及项目对业务目标的贡献等相关信息的文件。它包括：商业论证、效益管理计划。
（1） 商业论证 （文档化的经济可行性研究报告）
商业需求分析
成本效益分析
（2） 效益管理计划 (描述了项目实现效益的方式和时间、以及应制定的效益衡量机制)
目标效益、战略一致性、效益责任人……
商业文件是在项目之前制定的，需要定期审核。
商业文件不是项目文件，项目经理不可以对它们进行更新或修改，只可以提出相关建议。
批准的人有权修改
2. ：协议
协议----定义了启动项目的初衷。
协议的形式：合同（为外部客户做项目时）、谅解备忘录（MOUs）、服务品质协议（SLA）、意向书等
（4） 制定项目章程 — 工具与技术
1. 专家判断
概念：专家判断----基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合 理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人（人人都是“砖家”）
2. 数据收集
1||| 头脑风暴
短时间内获得大量创意，是典型的信息收集技术，原则是：不质疑、不分析、不批判、不 反对,不包含分析过程。
2||| 焦点小组
召集相关方和主题专家讨论相关议题，比一对一访谈更有利于互动交流（同职能）
3||| 访谈
通过与相关方直接交谈来了解相关信息。
3. 人际关系与团队技能
1||| 冲突管理
有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑等内容达成一致意见。
目的：解决冲突
2||| 引导
有效引导团队活动成功以达成决定、解决方案或结论的能力。
4. 会议
会议管理
不要把各种会议类型混合在一起；面对面的会议效果最好，有时也需要举行虚拟会议； 应明确每个参会者的角色，确保有效参会；会议要达成共识，要有行动计划；
会前----要确定会议议程、目的、目标和期限
会中----不要跑题；
会后----要形成书面的会议纪要和行动方案
在本过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、 总体里程碑和其他概述信息。
（5） 制定项目章程 — 输出
1. 项目章程
概念：项目章程----由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目 活动的文件。（是项目的“宪法”，是项目经理的“尚方宝剑”）
包含的内容：
1||| 委派的项目经理及其权责
2||| 项目的目的、目标、项目的成功标准
3||| 高层级的需求、高层级的项目描述、 高层级的战略和运营假设条件和制约因素
4||| 总体里程碑进度计划、总体预算、整体项目风险
5||| 项目审批要求、关键相关方名单、项目退出标准、主要可交付成果
2. 假设日志
概念：假设日志----用于记录整个项目生命周期中的所有假设条件和制约因素。
1||| 假设条件
不需验证即可视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。
有即威胁
2||| 制约因素
对项目或过程的执行有影响的限制性因素。
没有即机会
风险
2. 整合管理过程之二“制定项目管理计划 ” （规划过程组）
（1） 概念：制定项目管理计划----定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。
（2） 项目管理计划可以是概括的或详细的，详细程度取决于具体项目的要求。
（3） 制定项目管理计划 — 输入
1. 项目章程
项目团队把项目章程作为初始规划的起点。
2. 其他过程的输出
其他规划过程所输出的子计划和基准，都是本过程的输入。对这些子计划和基准的变更都可能导致对项目管理计划的相应更新。
（4） 制定项目管理计划 —工具与技术：
1. 数据收集
1||| 头脑风暴、核对单、焦点小组、访谈；
2||| 核对单----包括需要考虑的项目、行动或要点的清单，常被用作提醒。
2. 人际关系与团队技能
冲突管理、引导、会议管理；
3. 会议（ P86
规划的最后工作：开工会议
（5） 制定项目管理计划 —输出：
1. 项目管理计划
概念：项目管理计划----是说明项目执行、监控和收尾方式的一份文件。它整合并综合了所有子管理计划和基准，以及管 理项目所需的其他信息。
3. 整合管理过程之三“指导与管理项目工作 ” （执行过程组）
（1） 概念：指导与管理项目工作----为实现项目目标而领导和执行项目管理计划中确定的工作，并实施已批准变更的过程
（2） 指导与管理项目工作 — 输入
1. 项目管理计划
项目管理计划的任何组件都可用作本过程的输入
2. 批准的变更请求
批准的变更请求----实施整体变更控制过程的输出，可能是纠正措施、预防措施或缺陷补救。
（3） 指导与管理项目工作 — 工具与技术
1. 项目管理信息系统 PMIS
项目管理信息系统PMIS----为指导和管理项目工作提供自动化工具，并用于自动收集和报告关键绩效指标（KPI）
1||| 进度计划工具
Project
2||| 配置管理系统
SVN
3||| 工作授权系统
工作授权系统----用来保证项目工作由正确的组织、在正确的时间以正确的顺序执行。可以防止“镀金”
OA系统
4||| 信息收集
邮件系统
2. 会议
会议类型：开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议、回顾会议。
参会者： 项目经理、项目团队成员，以及与所讨论事项相关或会受该事项影响的相关方。
（4） 指导与管理项目工作 — 输出
1. 可交付成果
可交付成果----在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力，通常是项目结果，并可包括项目管理计划的组成部分
2. 工作绩效数据
在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。 在工作执行过程中收集数据，再交由控制过程做进一步分析；
3. 问题日志
问题日志----一种记录和跟进所有问题的项目文件。在此过程被首次创建，在整个项目生命周期应该随同监控活动更新。
包含的主要内容
1||| 问题描述
2||| 责任人
3||| 解决期限
4. 变更请求
变更请求----是关于修改任何文档、可交付成果或基准的正式提议。可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的，可口头提，但必须书面记录。
包括
1||| 纠正措施 — 纠偏差（事后）
2||| 预防措施 — 防风险（事前）
用来维护“某些” 基准
3||| 缺陷补救 — 补质量（针对质量缺陷）
4||| 更新 — 通常改计划
会修改计划或基准
4. 整合管理过程之四“管理项目知识 ” （执行过程组）
（1） 概念：管理项目知识----使用现有知识并生成新知识，以实现项目目标，并帮助组织学习的过程。
（2） 本过程的作用：利用已有的组织知识来创造或改进项目成果，并使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。
（3） 知识分类
（4） 知识管理注意点：
1. 组织角度看：在项目开始之前、开展期间和结束之后都能使用旧知识、生成新知识。
2. 最重要的环节：营造信任氛围，激励人们分享自己的知识和关注他人的知识。
3. 实践中双管齐下：
（1） 知识管理工具和技术 （用于人际互动）
（2） 信息管理工具和技术 （用于编撰显性知识）
（5） 管理项目知识 — 输入：
项目文件
（6） 管理项目知识 — 工具与技术：
1. 知识管理
（1） 知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识。
工作跟随
跟随指导
（2） 面对面互动最有利于建立知识管理所需的信任关系。 建立之后，可以用虚拟互动来维护这种信任关系。
2. 信息管理
概念：信息管理用于创建人们与知识之间的联系，可以有效促进简单、明确的显性知识的分享。
通过增加互动要素，比如：增加 “与我联系”的功能，使用户能够与经验教训发帖者联系，并向其寻求与特定项目和情境有关的建议。从而可以向隐性知识延伸。
3. 人际关系与团队技能
（1） 积极倾听----有助于减少误解并促进沟通和知识分享。
（2） 引导技术----有助于有效指引团队成功地达成决定、解决方案或结论。
（3） 领导力----可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标。
（4） 人际交往----促使项目相关方之间建立非正式的联系和关系，为显性和隐性知识的分享创造条件。
（5） 政治意识----有助于项目经理根据项目环境和组织的政治环境规划沟通
（7） 管理项目知识 — 输出：
经验教训登记册
（1） 项目早期：创建
（2） 项目期间：不断更新
（3） 项目结束：归入经验教训知识库
5. 整合管理过程组之五“监控项目工作 ” （监控过程组）
（1） 概念：监控项目工作----跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程
（2） 本过程的作用：
1. 让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动
2. 通过成本和进度预测，让相关方了解未来项目状态。
3. 监控项目工作贯穿于整个项目，是唯一输出工作绩效报告的过程。
（3） 监控项目工作 — 输入：项目文件
1. 项目文件
进度预测----基于项目以往的绩效，用于确定项目是否仍处于进度的公差区间内，并识别任何必要的变更
成本预测----基于项目以往的绩效，用于确定项目是否仍处于预算的公差区间内，并识别任何必要的变更
2. 工作绩效信息
将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。
绩效包含：范围、进度、成本、质量以及项目管理计划中定义的其他
工作绩效信息为决策提供依据。
（4） 监控项目工作 — 工具与技术：数据分析
1||| 挣值分析----对范围、进度、成本绩效进行综合分析，发现偏差
第七章详讲计算
2||| 偏差分析----审查目标绩效与实际绩效之间的差异，可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标
3||| 趋势分析----根据过去，预测将来。提前发现问题，提前纠偏或预防
4||| 根本原因分析----寻找偏差或潜在问题的根本原因
RCA
5||| 备选方案分析----选择纠正措施、预防措施
6||| 成本效益分析----选择成本最低的方案来纠偏
（5） 监控项目工作 — 工具与技术：决策
决策技术包括投票：一致同意、大多数同意、相对多数原则
（6） 监控项目工作 — 输出：工作绩效报告
基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注
根据项目沟通管理计划，通过沟通过程向项目相关方发送工作绩效报告（状态报告、进展报告）
6. 整合管理过程之六“实施整体变更控制 ” （监控过程组）
（1） 概念：实施整体变更控制----审查所有变更请求、批准变更、管理变更、并对变更处理结果进行沟通的过程
（2） 本过程的作用：
确保对项目中已记录在案的变更做综合评审，从而降低项目风险
本过程只会审批、管理变更，不会提出变更请求（我们只处理变更，不生产变更）
（3） 实施整体变更控制的几个注意点
1||| 实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任
2||| 应确保只有经批准的变更才能纳入修改后的基准中
3||| 任何相关方都可以提出变更请求，可以口头提出，必须以书面形式记录。并纳入变更管理和/或配置管理系统中
4||| 应该评估变更对时间和成本的影响，并向这些过程提供评估结果
5||| 每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，应在项目管理计划或组织程序中指定这位责任人，必要时，应由变更控制委员会（CCB）来开展实施整体变更控制过程
CCB----一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定
考点
（4） 实施整体变更控制 — 输入：变更请求
向变更请求的提出者了解变更的具体内容或变更的原因，告知变更的流程，防止不必要的变更
若确认必须变更则走以下5步流程
考点
变更题的常见考法
1. 变更的顺序
看看现在进行到了哪一步
根据顺序（1记录、2评估、3提交、4更新、5通知）来选择下一步做什么
2. 考要不要变更
当涉及到基准的修改的时候，需要走变更流程。（考试中几乎都是要走变更流程的）
1. 记录
书面记录变更请求；项目经理书面记录（变更日志），或要求变更提出者提交书面的变更请求
书面化提交给项目经理
2. 评估
充分了解变更， 评估变更带来的影响；与相关的相关方沟通评估出的影响
3. 提交
提交责任人审批；注意，这里的提交是指“项目经理”将变更请求和评估的结果提交给CCB
项目经理提交给CCB
4. 更新
不管变更通过还是不通过，必须更新变更日志；如果变更通过，更新项目管理计划（文件）；
5. 通知
应将变更的结果通知相关（受影响）的相关方
（5） 实施整体变更控制 — 工具与技术：变更控制工具
概念：配置管理系统----项目管理系统的子系统，由一系列正式的书面程序组成，为以下配置管理活动提供技术和管理方面的指导与监督：
1. 一识----配置识别：识别与选择配置项----规划
2. 二记----配置状态记录：关于各个配置项的信息记录和报告----执行
3. 三审----配置核实与审计：通过核实与审计保证配置项组成的正确性，及变更被正确实施----监控
（6） 实施整体变更控制 — 输出：批准的变更请求
变更请求批准人的选择顺序：
变更控制委员会（CCB）。（考试“默认” 变更提交给CCB来审批，最常见的选择）
项目管理计划或组织流程中指定的责任人。（最准确的说法，但不常见）
如题中无以上选项，则可选“PMO”、“发起人”、“项目经理”
（7） 实施整体变更控制 — 输出：项目文件更新
概念：变更日志----用来记录项目过程中出现的变更，被否决的变更请求也应该记录在变更日志中。
（8） 实施整体变更控制 — 输出：项目管理计划更新
对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性
7. 整合管理过程之七“结束项目或阶段 ” （收尾过程组）
（1） 概念：结束项目或阶段----终结项目、阶段或合同的所有活动的过程。
（2） 本过程的作用：
存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作。
（3） 结束项目或阶段注意点
在项目结束时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。
若项目在完工前就提前终止，结束项目或阶段过程还是需要制定程序，来调查和记录提前终止的原因
（4） 项目或阶段收尾
1||| 获得项目整体验收
2||| 相关方满意度调查
3||| 移交成果
4||| 总结和记录经验教训
5||| 组织过程资产更新
6||| 文件归档
7||| 庆功会
8||| 释放资源
（5） 结束项目或阶段 — 输入：
1. 项目章程
项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束
2. 验收的可交付成果
验收的可交付成果----包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果。
3. 商业文件
商业论证----用于确定项目是否达到了经济可行性研究的预期结果。
效益管理计划----用于测量项目是否达到了计划的效益。
4. 组织过程资产
项目或阶段收尾指南或要求----如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估，以及知识传递；
配置管理知识库----包括组织标准、政策、程序和项目文件的各种版本及基准
（6） 结束项目或阶段 — 工具与技术：
1. 数据分析
文件分析、回归分析、趋势分析、偏差分析
2. 会议
会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功。
会议的类型包括：收尾报告会、客户总结会、经验教训总结会、庆祝会
（7） 结束项目或阶段 — 输出：
1. 最终产品、服务或成果移交
把项目交付的最终产品、服务或成果（对于阶段收尾，则是所在阶段的中间产品、服务或成果）从一个团队转交到另一团队或组织，并由其在整个生命周期中进行运营、维护和支持。
2. 最终报告
用最终报告总结项目绩效
3. 组织过程资产更新
（1） 项目文件
（2） 运营和支持文件
（3） 项目或阶段收尾文件：1、表明项目或阶段完工的正式文件； 2、把可交付成果移交给他人的正式文件
若项目提前终止，需要：1、在正式的收尾文件中说明终止的原因； 2、把已完成未完成的可交付成果移交他人 3、把历史信息和经验教训信息存入经验教训知识库，供未来项目或阶段使用
（4） 经验教训知识库
（8） 项目完成收尾的标志：释放资源（解散团队）、项目或阶段收尾文件
如果当前项目在收尾，又被分配了新项目，项目经理优先保证当前项目的收尾
6.
第四章上：1:35开始答疑
第5章 项目范围管理
1. 项目范围管理的“核心概念 ”：项目范围管理包括做且只做所需的全部工作。
only and all
“范围”包括两重含义：
产品范围----某项产品、服务或成果所具有的特性和功能
项目范围----为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
2. 项目范围管理的“发展趋势和新兴实践”
3. 在敏捷和适应型环境中需要考虑的因素
4. “需求”和“范围”的区别
需求：需求是一种需要
范围：范围是满足“需求”必须交付的可交付成果和相关工作
5. 项目范围管理过程之一“规划范围管理 ” （规划过程组）
（1） 概念：规划范围管理----为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程本过程的作用：在整个项目中对如何管理范围提供指南和方向。
（2） 规划范围管理 — 输出：
1. 范围管理计划
范围管理计划----描述将如何定义、制定、监督、控制和确认项目范围。
注意点：
（1） 范围管理计划无范围（范围在范围基准中）
（2） 范围管理计划可以是正式或非正式的，非常详细或高度概括的
2. 需求管理计划
需求管理计划（商业分析计划）----描述将如何分析、记录和管理项目和产品需求
注意点：
（1） 需求管理计划无需求（需求在需求文件中）
（2） 内容包括配置管理活动、需求优先级排序过程、测量指标等
6. 项目范围管理过程之二“收集需求 ” （规划过程组）
（1） 概念：收集需求----为实现目标而确定、记录并管理相关方的需要和需求的过程
本过程的作用：为定义产品范围和项目范围奠定基础
（2） 什么是需求？
需求----根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望
（3） 收集需求 — 输入：
1. 项目文件
相关方登记册----用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望
2. 商业文件
会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准
3. 协议
协议会包含项目和产品需求
（4） 收集需求 -- 工具与技术
（5） 收集需求 — 输出：
1. 需求文件
概念：需求文件----描述各种单一需求将如何满足与项目相关的业务需求
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。
需求分类
2. 需求跟踪矩阵
概念：需求跟踪矩阵----把产品需求从其来源连接到能满足需求的可交付成果的一种表格
作用
◆ 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。 ◆ 提供了在整个项目生命周期中跟踪需求的一种方法（正向跟踪和逆向跟踪） ◆ 有助于确保需求文件中 被批准的每项需求在项目结束的时候都能交付。 ◆ 收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实范围 ◆ 需要进一步明确哪些包含在项目范围内，哪些排除在项目范围外。（定义范围）
7. 项目范围管理过程之三“定义范围 ” （规划过程组）
（1） 概念：定义范围----制定项目和产品详细描述的过程
（2） 本过程的作用：描述产品、服务或成果的边界和验收标准。
从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。
（3） 定义范围 — 输入：
1. 项目章程
项目章程中包含对项目的高层级描述、产品特征和审批要求
2. 项目文件
需求文件----识别了应纳入范围的需求
（4） 定义范围 — 工具与技术：
1. 数据分析
可用于本过程的数据分析技术包括：备选方案分析
2. 决策
可用于本过程的决策技术包括：多标准决策分析
3. 人际关系与团队技能
在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识
4. 产品分析
产品分析----把高层级的产品描述转变为有形的可交付成果。 产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等
（5） 定义范围 — 输出：
项目范围说明书
项目范围说明书----是对项目范围、主要可交付成果、假设条件和制约因素的描述。 记录了整个范围，包括项目和产品范围
项目范围说明书详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识
为了便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围
8. 项目范围管理过程之四“创建 WBS” （规划过程组）
（1） 创建WBS----把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
（2） 本过程的作用：对所要交付的内容提供架构
WBS （工作分解结构）组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）
WBS最低层的组成部分称为工作包，其中包括计划的工作。
在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身
（3） 创建 WBS 的四个注意
如果采用敏捷方法，可以将长篇故事分解成用户故事
不同的可交付成果可以分解到不同的层次
并不是分解得越细越好。过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难
远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划
（4） 创建 WBS 的四个主要原则
1. 无遗漏无多余
100%原则
2. 工作包80小时
80小时原则
3. 4~6层原则
不宜过细分解
4. 责任明确原则
有明确责任人
（5） 创建 WBS — 工具与技术：
分解
创建WBS，就是要将整个项目工作分解为工作包
工作包----WBS 最低层的组件，可对其成本和持续时间进行估算和管理
分解----把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术
分解的五个步骤
（1） 识别和分析可交付成果及相关工作
（2） 确定WBS的结构和编排方法
（3） 自上而下逐层细化分解
（4） 为WBS组件制定和分配标识编码
（5） 核实可交付成果分解的程度是否恰当
WBS 的结构可以采用如下形式
把项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
把主要可交付成果作为分解的第二层
纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）
（6） 创建 WBS 的输出：
范围基准
哪儿找 可交付成果和验收标准 ：首选范围说明书，次选wbs 词典，再次选范围基准
（7） 控制账户与工作包
控制账户（CA）----是一个管理控制点（可以与组织的财务程序链接），在该控制点上，把范围、 预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效
绩效测量基准（PMB）----由范围基准、进度基准、成本基准共同构成
每个控制账户可能包括一个或多个工作包（或规划包），但是一个工作包只能属于一个控制账户
9. 项目范围管理过程之五“确认范围 ” （监控过程组）
（1） 概念：确认范围----“客户”或“发起人”正式验收已完成的项目可交付成果的过程
（2） 本过程的作用：通过验收每个可交付成果，提高最终产品、服务或成果验收的可能性
（3） 确认范围 — 输入：
核实的可交付成果
核实的可交付成果----已经完成，并被控制质量过程检查为正确的可交付成果
（4） 确认范围 — 工具与技术：
检查
检查（审查、产品审查、巡检）----开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
（5） 确认范围 — 输出：
1. 验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准
应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收
2. 变更请求
如果未通过验收，处理步骤
（1） 记录（了解）原因；
（2） 走变更流程，进行缺陷补救
10. 项目范围管理过程之六“控制范围 ” （监控过程组）
（1） 控制范围----监督项目和产品的范围状态，管理范围基准变更的过程
（2） 本过程的作用：
在整个项目期间保持对范围基准的维护
确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理
（3） 控制范围 — 工具与技术：
数据分析
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作
1. 偏差分析----用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
2. 趋势分析----旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
（4） 范围蔓延、镀金、范围潜变
如果已经出现了范围蔓延，需要补变更流程。如果变更没有获得批准，需要取消不良变更
1. 范围蔓延----未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大
来自团队内部原因造成的范围蔓延称为“镀金”
来自团队外部原因造成的范围蔓延称为“范围潜变”
2. 镀金----项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动
3. 范围潜变----范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败
11.
12.
第5章 项目范围管理
1. 项目进度管理的“核心概念
2. 子主题
3. 子主题
4. 子主题
5. 子主题
6. 子主题
主题
来自团队外部原因造成的范围蔓延称为“范围潜变”
中心主题
1. 表1-1 范围内和范围外的事项
2. 图2-1《敏捷宣言》四大价值
3. 图2-2《敏捷宣言》十二大原则
4. 图2-3《敏捷宣言》价值观、原则和通用实践之间的关系
5. 图2-4敏捷是许多方法的一个总称
6. 图2-5受斯泰西复杂性模型启发的不确定性和复杂性模型
7. 表3-1四种生命周期的特征
8. 图3-1生命周期的连续区间
9. 图3-2预测型生命周期
10. 图3-3迭代型生命周期
11. 图3-4不同大小的增量的生命周期
12. 图3-5基于迭代和基于流程的敏捷生命周期
13. 图3-6敏捷开发后接预测型发布
14. 图3-7同时结合使用敏捷和预测的方法
15. 图3-8以预测法为主、敏捷方法为辅的方法
16. 图3-9以敏捷方法为主、预测法为辅的方法
17. 表3-2改进配合的裁剪方案
18. 表4-1成功敏捷团队的属性
19. 表4-2敏捷团队角色
20. 主题
21. 主题
22. 主题
23. PMP考试分为：预测型、敏捷型、混合型。这三大类，敏捷的内容基本就占到了50%
中心主题
1. 项目整合管理
2. 项目范围管理
3. 项目时间管理
4. 项目成本管理
5. 项目质量管理
6. 项目人力资源管理
7. 项目沟通管理
8. 项目风险管理
9. 项目采购管理
10. 干系人管理
11.