高项总笔记（原版）
2023-09-15 13:16:24 28 举报AI智能生成
登录查看完整内容
高项总笔记（原版）是一份详尽且深入的记录，涵盖了各种主题和领域。这份笔记以其全面性和深度而闻名，无论是对于专业人士还是对于普通读者，都能提供大量的信息和知识。它的内容丰富多样，包括了科学、技术、艺术、历史、文化等各个领域，既有理论知识，也有实践技巧。此外，这份笔记的语言清晰易懂，逻辑严谨，使得读者能够轻松理解和掌握其中的内容。总的来说，高项总笔记（原版）是一份非常有价值的学习资料，无论你是想提升自己的专业技能，还是想拓宽自己的知识视野，都能从中获得巨大的帮助。
作者其他创作
大纲/内容
信息系统项目管理师（高项）十大知识领域-第四版
PMP49个详细过程(输入、工具、输出).xlsx
6.1 PMBOK的发展
通过可交易成果达成目标
可能存在相同的元素，不改变本质上的独特性
独特产品、服务或成果而进行的临时性工作
可能有形，可能无形
独特并可验证的产品、服务或成果
过程、阶段或项目完成时
可交付成果
明确的起点和终点
时间不一定短
比如建成的系统或者建筑等
临时性一般不适用于项目所产生的产品、服务或成果
临时性（一次性）
推动组织从一个状态（当前状态）到领一个状态（未来状态）
业务价值
项目驱动变更
可量化的净效益
有形的、无形的或两者兼而有之
效益
创造业务价值
满足法律法规或社会需求
满足干系统人要求或需求
创造、改进或修复产品、过程或服务
执行、变更业务或技术战略
促成项目创建的因素
项目启动背景
解释
项目基础
项目基本要素
将知识、技能、工具和技术应用于项目活动，以满足项目的要求
12点
项目管理的作用
8点
项目管理不善或缺失可能导致的问题
4点
有效和高效的项目管理是一个组织的战略能力
项目管理的定义
项目管理的重要性
项目成功的测量指标
与组织的战略方向持续保持一致
时间、成本、范围和质量
四要素
项目成功的标准
统一考虑以实现更大利益
获得分别管理无法获得的利益
不是大项目
是一组相互关联且被协调管理的“项目、子项目集和项目集活动”，以便获得分别管理所无法获得的利益(1+1>2的效果)。
项目和项目集的重点在于正确地做事
项目集
实现战略目标而组合在一起的
重点在于做正确的事
项目组合
图
不同
项目集管理
项目组合中的部件不一定存在彼此依赖或者直接相关的关联关系
项目组合管理的目的
确定各组成部分的优先级，使最有利于组织战略目标的部分拥有所需的财力、人力和实物资源
项目组合管理
不属于项目管理的范围
运营管理
不同的时间点存在交叉，可交付成果及知识会相互转移
运营管理与项目管理
项目组合通过选择适当的项目集或项目，对工作进行优先级排序，并提供所需的资源，与组织战略保持一致
项目集管理通过对其组成部分进行协调，对他们之间的依赖关系进行控制，从而实现既定收益
项目管理使组织的目标得以实现
组织机项目管理旨在确保组织开展正确项目并合适地分配关键资源
组织级项目管理和战略
项目、项目集、项目组合和运营管理之间的关系
过程资产
治理文件
数据资产
知识资产
安保和安全
组织过程资产
组织文化、结构和治理
设施和资源的物理分布
基础设施
信息技术软件
资源可用性
员工能力
组织内部的事业环境因素
市场条件
社会和文化影响因素
监管环境
商业数据库
学术研究
行业标准
财务考虑因素
物理环境因素
组织外部的事业环境因素
因素和资产的总结
项目内外部运行环境
治理框架
管理要素
组织结构对项目的影响
组织结构
支持型
使用项目管理框架或方法论
使用特定的模版、格式和工具
遵从治理框架
可能要求项目
控制型
指令性
分类
PMO还有可能承担整个组织范围的职责
集中管理项目，但所支持和管理的项目之间不一定彼此关联
重要干系人和关键决策者
共享资源管理
识别和制定项目管理方法、最佳实践和标准
指导、辅导、培训和监督
通过项目审计，监督项目对项目管理标准、政策、程序和模版的合规性
制定和管理项目政策、程序、模版及其他共享的文件（组织过程资产）
对跨项目的沟通进行协调等
通过各种方式向项目经理提供支持
主要职能
项目管理办公室（PMO）
2.5 组织结构对项目的影响
组织结构类型
组织系统
可量化生产的工件（包括服务及其组件）
产品
产品生命周期中包含项目集管理
产品生命周期包含单个项目管理
项目集内的产品管理
表现形式
产品管理
引入、成长、成熟、下降/衰退
指一个产品从引入、成长、成熟 到衰退的整个演变过程的一系列阶段
产品生命周期
定义
项目管理和产品管理
分步、连续的积累
逐步完善
面向目标
资源约束
目的性
项目和日常运作的区别
时间、成本和质量
主要目标
项目的三重制约
项目的特点
整体性、长期性、基本性
战略制定
战略实施
战略评价
战略管理三个过程
项目经常当做实现组织战略计划的一种手段
企业战略
项目和战略规划
目标不明确、需求变化频繁、智力密集型、设计队伍庞大、设计人员高度专业化、涉及的承包商多、各级承包商分布在各地，相互联系复杂、系统集成项目中需要研制开发大量的软硬件系统、项目生命期通常较短、通常要采用大量的新技术、使用与维护的要求非常复杂
信息系统项目的特点
复杂
具有创造性
需要集权领导和建立专门的项目组织
在项目管理中起着非常重要的作用
成功的管理还取决于预测和控制人的行为的能力
项目负责人（项目经理）
社会经济、政治、文化、自然环境等对项目的影响
项目管理的特点
6.2 项目基本要素
职能经理专注于对某个职能领域或业务部门的管理监督。运营经理负责保证业务运营的高效性。 项目经理则由执行组织委派，负责领导团队实现项目目标。
领导项目团队实现项目目标和干系人的期望;
利用可用资源，以平衡相互竞争的制约因素;
充当项目发起人、团队成员与其他干系人之间的沟通者，包括提供指导和展示项目成功 的愿景
沟通者
8个方面
沟通
正式的人际网络
与专家和具有影响力的领导者建立的个人人际关系
非正式人际网络
人际网络
软技能
项目
资源
资金
可交付成果的接受或发布
项目与组织战略和目标的一致性
与其他项目经理互动
与项目发起人合作
与职能经理互动
提高总体项目管理能力和技能
组织
时刻关注行业的最新发展趋势，获取并判断这些信息对当前项目的影响。
行业
持续的知识传递和整合
专业学科
指导和教育其他专业人员项目管理方法;担任非正式的宣传大使
跨领域范围内
角色
项目经理的影响力范围
与项目、项目集和项目组合管理特定领域相关的知识、技能和行为，可以帮助达成项目目标。
成功关键因素、进度表、指定的财务报告和问题日志
关键管理要素
裁剪有选择的使用工具、技术、方法
制定完整的计划并谨慎排定优先顺序
管理项目制约因素
关键技能
项目管理
关于行业和组织的知识和专业技能，有助于提高绩效并取得更好的业务成果。
风险和问题
财务影响
成本效益分析
效益预期实现情况和战略
范围、预算、进度和质量等
商业因素包括
商务信息
交付策略
执行策略
战略和商务
指导、激励和带领团队所需的知识、技能和行为，可以帮助组织达成业务目标。
人际交往
13项
领导者品质和技能
政策和权力
领导力技能
区别
无为而治
有利于创新
放任型
关注目标、反馈和成就以确定奖励
交易型
服务优先于领导
服务型
提高追随者能力
变革型
魅力型
结合了交易型、变革型和魅力型的特点
交互型
领导力风格
领导力与管理
项目经理的能力（关键技能）
6.3 项目经理的角色
基础
1、勤勉、尊重和关心他人
2、营造协作的项目管理团队环境
3、促进干系人有效参与
商业需要、项目理由和商业战略
4、聚焦于价值
5、识别、评估和响应系统交互
6、展现领导力行为
7、根据环境进行裁剪
8、将质量融入到过程和成果中
9、驾驭复杂性
不确定程度
风险偏好
可接受的偏差范围
风险临界值
10、优化风险应对
11、拥抱适应性和韧性
12、为实现目标而驱动变革
项目管理原则
启动项目；组织与准备；执行项目工作；结束项目
项目通用生命周期
成本和人力投入在开始时交底，在工作执行期间达到最高，并在项目快要结束时迅速回落
风险与不确定性在项目开始最大，逐步降低
改变项目产品最终特性的能力在项目开始时最大
通用的生命周期结构特征
预测型生命周期（瀑布型生命周期）
迭代式的过程中，每个阶段都包括不同的比例的所有活动
重复的循环属于“完善型迭代”
适用于：不能完整定义产品的所有需求、计划多期开发的、在开发早期需求可能有所变化、需要降低项目复杂性的、部分交付有利于干系人的
迭代模型和增量模型的区别
概念
迭代模型
渐进增加产品功能
增量型生命周期
是一种以人为核心、迭代、循序渐进的开发方法
更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队
能够很好滴使用需求变化的代码编写和团队组织方法
也更注重软件开发中人的作用
迭代型和增量型的混合
需求不确定，不断变化的项目
每次迭代需要定义和批准范围
通常用于敏捷软件开发
迭代式增量软件开发过程
负责维护过程和任务
Scrum主管
代表利益所有者
产品负责人
包括了所有开发人员
开发团队
主要角色
Scrum
适应型生命周期（敏捷型、变更驱动型项目）
预测型和适应型的组合（瀑布与敏捷的混合）
混合型生命周期
各生命周期之间的联系与区别
项目生命周期类型
项目生命周期和项目阶段
启动、规划、执行、监控、收尾（管理工作维度）
按需要重复开展
适应型项目中的过程组
项目管理生命周期（项目管理过程组）
十大知识领域
项目管理知识领域
一组对有效地交付项目成果至关重要的活动
需要密切关注的相互作用、相互关联和相互依赖的领域
干系人、团队、开发方法和证明周期、规划、项目工作交付、测量、不确定性
项目绩效域
创造价值
价值交付系统是组织内部环境的一部分，该环境受政策、程序、方法论、框架、治理结构等制约
价值交付组件
信息流
价值交付系统
6.4 价值驱动的项目管理知识体系
06 项目管理概论
项目立项管理是对拟规划和实施的项目技术上的先进性、适用性，经济上的合理性、效益性，实施上的可能性、风险性以及社会价值的有效性、可持续性等进行全面科学的综合分析，为项目决策提供客观依据的一种技术经济研究活动
需求调研→编写项目申请书→可行性研究(机会、初步、详细)→项目论证→项目评估→评审获得批准→发布招标文件!
甲方
看到招标文件→进行项目识别→ 可行性研究(机会、初步、详细)→项目论证→项目评估→参加投标→中标拿到项目→签订合同
乙方
第四版取消了项目论证
甲乙方立项的区别
项目建议与立项申请
初步可行性研究
详细可行性研究
评估与决策
项目投资前时期的四个阶段
是项目建设单位向上级主管部门提交项目申请时必须的文件
是项目发展周期的初始阶段，是国家或上级主管部门选择项目的依据，也是可行性研究的依据
作用
项目的必要性
项目的市场预测
产品预期成果（如产品方案或服务）的市场预测
项目建设必需的条件
项目建议书的内容
1必要2预测1条件
立项申请（项目建议书）
7.1 项目建议与立项申请
预见性、公正性、可靠性、科学性
特点
是指在当前的技术、产品条件限制下，能否利用现在拥有的以及可能拥有的技术能力、产品功能、人力资源来实现项目的目标、功能、性能，能否在规定的时间期限内完成整个项目。
往往决定了项目的方向
项目开发的风险
人力资源的有效性
技术能力的可能性
物资（产品）的可用性
考虑因素
技术的可行性
开发费、培训费、差旅费、初始数据录入、设备购置费等
一次性支出
软/硬件租金、人员工资及福利、水电等公用设施使用费、以及其他消耗品支出等
非一次性支出
支出分析
是对整个项目的投资及所产生的经济效益和对项目的社会效益进行分析，具体包括支出分析、收益分析、投资回报分析以及敏感性分析。
如销售项目产品的收入
直接收益
如成本的降低
间接收益
知识产权、软件著作权等
其他收益
收益分析
确定项目的收益和投资回收期
投资回报分析
收益投资比、投资回收期分析
当诸如设备和软件配置、处理速度要求、系统的工作负荷类型和负荷量等关键因素变化时，对支出和收入的影响的估计
敏感性分析
管理水平、技术手段、人员素质等方面获得潜在的效益
社会效益
内容
经济可行性
品牌效益、竞争力效益、技术创新效益、人员提升收益、管理提升效益
对组织内部
公共效益
文化效益
环境效益
社会责任感效益
对社会发展
社会效益可行性
运行环境是制约信息系统在用户单位发挥效益的关键。
管理体制、管理方法、规章制度、人员素质、数据资源积累、基础软硬件平台
运行环境可行性
诸如法律可行性、政策可行性等方面的可行性分析
其他
可行性研究内容
初步可行性研究一般是在对市场或者客户情况进行调查后，对项目进行的初步评估。
项目的前途
关键技术及核心问题
必须进行的辅助研究，解决项目的核心问题
几个方面进行衡量
必要性
周期
人力财力资源的接受度
功能和目标是否可以实现
经济效益、社会效益是否可以保证
经济上、技术上是否合理
需求与市场预测
设备与资源投入分析
网络规划、物理布局方案的选择
空间布局
包括项目总体规划、信息系统设计和设备计划、网络工程规划等
项目设计
项目进度安排
投资估算、成本估算、资金渠道及初步筹集方案
项目投资与成本估算
主要内容
进度和成本
与详细可行性研究占有的资源细节有较大差异
不是所有方面
性质不同
如有，则其内容是必不可少的部分
费用部分和项目可行性研究的费用联系起来考虑
市场研究
配件和投入的物资的研究
实验室和中间工厂的试验
网络物理布局设计
规模的经济性研究
设备选择研究
辅助（功能）研究
机会研究
可行性研究阶段划分
前三个可以合并，详细可行性研究是不可或缺的
7点
详细可行性研究的依据
项目评估和决策的依据
最终提交的可行性研究报告
需要对项目在技术、经济、社会、法律、社会环境等方面的条件和情况，进行详尽的、系统的、全面地调查、研究和分析
经济评价法、市场预测法、投资估算法和增量净效益法
投资估算法
增量净效益法（有无比较法）
方法
科学性原则、客观性原则、公正性原则
基本原则
市场需求预测
部件和投入的选择供应
技术的先进性
实用性
可靠性
连锁效果
技术后果的危害性
信息系统架构及技术方案的确定
技术与设备选择
物理布局设计
投资、成本估算与资金筹措
进行分析的基础准备
编制财务报表
进行经济效果计算
步骤
投资收益率与投资回收期
静态评价方法
净现值法、内部收益率法、外部收益率法
动态评价方法
组织经济评价
国民经济评价
经济评价
综合分析
经济评价及综合分析
研发成本
行政管理费
销售和分销费用
不是经营成本
财务费用和折旧
项目总成本
总和称为经营成本
项目背景
可行性研究的结论
项目提出的技术背景
项目的技术发展现状
编制项目建议书的过程及必要性
市场情况调查分析
客户现行系统业务、资源、设施情况调查
项目总体目标
项目实施进度计划
项目投资估算
项目组人员组成
项目风险
经济效益预测
社会效益分析预评价
可行性研究报告结论
附件
详细可行性研究报告
可行性研究的步骤
7.2 项目可行性研究
评价、分析和论证
由第三方（国家、银行或有关机构）
项目投资前期决策管理的重要环节
可靠性、真实性和客观性
为银行的贷款决策或行政主管部门的评审决策提供科学依据
项目评估报告
最终成果
1、项目建议书及其批准文件
2、项目可行性研究报告
3、报送组织的申请报告及主管部门的初审意见
4、项目关键建设条件和工程等的协议文件
5、必须的其他文件和资料
评估依据
1、成立评估小组，分工，制定评估计划
2、开展调查研究，收集数据资料，并对可行性研究报告和相关资料进行审查和分析
3、分析与评估
4、编写、讨论、修改评估报告
5、召开专家论证会
6、评估报告定稿并发布
评估程序
15点
项目评估内容
项目概况
详细评估意见
总结和建议
项目评估报告内容大纲
项目评估
7.3 项目评估与决策
07 项目立项管理
从过程想结果
从结果知输入
从输入选工具
三从
一得文件计划
二得成果数据
三得变更请求
四得因素资产
四得
三从四德
ITO共性总结
1、上一个过程的输出大部分是下一个过程的输入2、计划和文件是不一样的(每个输入都有计划和文件) 3、被批准的变更请求约等于计划【批准得变更请求要列入计划执行，所以约等于项目管理计划作用】4、在执行和监控过程产生新的变更请求(变更请求包括变什么和怎么变，这是变更请求和纠正、预防、缺陷补救的关系) 5、执行过程产生工作绩效数据---数据+背景在监控过程组成为了工作绩效信息然后输出工作绩效报告注意工作绩效数据是执行过程的输出→那么就是监控的输入→监控的输出就成了工作绩效信息6、通过过程的含义记忆每个过程组最主要的成果(输出)! 7、监控过程组每个过程都有计划+工作绩效报告，要记住我说的监控的那些原理 跟踪进展→拿着计划的这把尺子测量实际的工作绩效报告→偏差计算→偏差评估、分析是否变更→预测 →趋势分析 8、项目存续期间，变更请求是不可避免得，不可避免也要控制，控制需要机制。 9、组织过程资产和事业环境因素一般是输入因素，可以作为绝大多数过程的输入。
项目管理规律总结
包括识别、定义、组合、统一和协调项目管理过程组的各个过程和管理活动。
资源分配
平衡竞争性需求
研究备选方法
裁剪过程以实现项目目标
管理各个项目管理知识领域之间的依赖关系
目标
概述
项目经理负责，整合管理的责任不能被授权或转移，承担最终责任
了解战略目标并确保项目目标和成果与项目组合、项目集以及业务领域保持一致
组织层面上
关注真正重要的事务并协同工作
整合过程、知识和人员
项目层面上
双重角色
发生整合的三个层面:1.过程层面执行整合2.认知层面执行整合3.背景层面执行整合
执行整合
系统行为、人类行为以及组织或环境中的不确定性
整合的复杂性
使用信息化工具（自动化工具）
使用可视化管理工具
应对项目人员的流动性和不稳定性
项目知识管理
立项前、结项后的可行性研究、评估和效益管理
全面地识别干系人
项目经理在项目之外的职责
项目管理方法
相关分析工具
组织变革管理方法
混合型方法
管理新实践
（范围、需求、进度、成本、质量、人力、沟通、干系人、风险、采购、变更、配置）管理计划
（进度、成本、范围）基准
绩效测量基准
项目生命周期描述
开发方法
项目管理计划
活动属性、活动清单、假设日志、估算依据、变更日志、成本估算、持续时间估算、问题日志、经验教训登记册、里程碑清单、物质资源分配单、项目日历、项目沟通记录、项目进度计划、项目进度网络图、项目范围说明书
项目团队派工单、质量控制测量结果、质量测量指标、需求文件、需求跟踪矩阵、资源分解结构、资源日历、资源需求、风险登记册、风险报告、进度数据、进度预测、干系人登记册、团队章程、测试与评估文件
项目文件
项目管理计划和项目文件
8.1 管理基础
过程概述
项目生命周期、开发生命周期、管理方法、知识管理、变更、治理、经验教训、效益
裁剪考虑因素
团队成员可以自行决定并控制具体产品的规划和交付
团队成员自行决定各个组件的整合方式
敏捷与适应方法
8.2 项目整合管理过程
正式批准项目的文件
项目经理任何时候都应该在规划开始之前被委派
正式批准项目并授权项目经理在活动中使用组织资源
项目章程在项目执行和项目需求之间建立了联系
明确项目与组织战略项目之间的直接联系
确立项目的正式地位
展示组织对项目的承诺
本过程主要作用
项目经理应该参与制定项目章程
发起人、项目集或项目管理办公室、项目组合治理委员会主席或其授权代表
经启动者签字
标志着项目的正式启动
由项目实施组织外部签发的
制定项目章程
ITTO
包含商业需求和成本效益分析
立项管理文件不是项目文件
立项管理文件
包括合同、谅解备忘录、服务水平协议SLA、协议书、意向书、口头协议或其他书面协议
协议
输入
项目经理的周边到处都是专家。（自身也是专家）
专家判断
用于在短时间内获得大量创意
制定项目章程时可通过头脑风暴向干系人、主题专家和团队成员收集数据、解决方案或创意。
【关键词:大量创意、各种想法、畅所欲言】
头脑风暴
召集干系人和主题专家讨论项目风险、成功标准和其他议题，比一对一访谈更有利于互动交流。
【关键词:同职能、同一领域、有相似背景、主题专家(SME)、主持人引导互动 式讨论】
焦点小组
通过与干系人直接交谈，了解高层级需求、假设条件、制约因素、审批标准以及其他信息。
【关键词:直接交谈、预设和即兴问题、一对一、多对多、获取机密信息】
访谈
数据收集
冲突管理
引导
会议管理
人际关系与团队技能
会议
工具与技术
项目章程不能当作合同
项目章程记录了关于项目和项目预期交付的产品、服务或成果的高层级信息
项目目的
可测量的项目目标和相关的成功标准
高层级需求、高层级项目描述、边界定义以及主要可交付成果
项目整体风险
总体里程碑进度计划
预先批准的财政资源
关键干系人名单
项目审批要求
项目退出标准
委派的项目经理及其职责和职权
发起人或者其他批准项目章程的人员的姓名和职权
项目章程内容
项目章程
记录整个项目生命周期中的所有假设条件和制约因素
假设日志
输出
8.2 制定项目章程
生成一份综合文件，用于确定所有项目工作的基础及其执行方式
主要作用
项目管理计划应基准化，即至少应规定项目的范围、时间和成本方面的基准，以便据此考核项目执行情况和管理项目绩效
制定项目管理计划
收集关于项目方法的创意和解决方案
用来核对该做的事项有没有做
制订计划或帮助检查项目管理计划是否包含所需的全部信息
核对单
召集干系人讨论项目管理方法以及项目管理计划各个组成部分的整合方式
从干系人获取特定信息
让具有差异性的干系人就项目管理计划的所有方面达成共识。
项目管理计划是说明项目执行、监控和收尾方式的一份文件
10个
各个子管理计划
范围基准
进度基准
成本基准
基准
变更管理计划
配置管理计划
项目生命周期
管理审查
项目管理计划组件
PM要求在项目中所做的所有事情都必须是在计划中所体现的，做计划之外试图“讨好”干系人被称 为“镀金”，这是项目中明令禁止的。
镀金
8.4 制定项目管理计划
为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程
指导与管理项目工作
批准的变更请求是实施整体变更控制过程的输出
包括经项目经理审查和批准的变更请求，必要时需要经变更控制委员会(CCB)审查和批准。
纠正措施
预防措施
缺陷补救措施
实施
批准的变更请求
项目管理信息系统给项目提供了IT软件工具
例如进度计划软件工具、工作授权系统、配置管理系统、 信息收集与发布系统，以及进入其他在线信息系统(如知识库)的登录界面，支持自动收集和报告关键 绩效指标(KPI)。
项目管理信息系统
开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议以及回顾会议
会议类型
独特并可核实的产品、成果或服务能力
它通常是项目的结果，包括项目管理计划的组成部分
数据流向
工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。
工作绩效数据
问题日志是一种记录和跟进所有问题的项目文件
在整个项目生命周期应该随时监控活动更新问题日志
问题日志
变更请求是关于修改任何文件、可交付成果或基准的正式提议
任何项目干系人都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理
纠偏差
◆纠正措施:为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动;
防风险
◆ 预防措施:为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动;
补质量
◆ 缺陷补救:为了修正不一致的产品或产品组件而进行的有目的的活动;
◆ 更新:对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。
变更请求
维护基准
修改基准
计划和文件更新
组织过程资产（更新）
8.5 指导与管理项目工作
使用现有知识并生成新知识，以实现项目目标并且帮助组织学习的过程
利用已有的组织知识来创造或改进项目成果
使当前项目存在的知识可用于支持组织运营和未来的项目或阶段
组织角度看:在项目开始之前、开展期间和结束之后都能使用旧知识、生成新知识。
最重要的环节:营造信任氛围，激励人们分享自己的知识和关注他人的知识
实践中双管齐下:知识管理工具和技术(用于人际互动)、信息管理工具和技术(用于编撰显性知识)
管理项目知识
知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识。
社区和特别兴趣小组
工作跟随和跟随指导
讨论论坛
知识分享活动
探讨会
讲故事
创造力和创意管理技术
知识展会和插座
交互式培训
知识管理
信息管理用于创建人们与知识之间的联系，可以有效促进简单、明确的显性知识的分享
信息管理
有助于减少误解并促进沟通和知识分享
积极倾听
领导力
有助于项目经理根据组织政策与职权结构等进行规划与沟通
大局观
可以包含执行情况的类别和详细的描述，还可包括与执行情况相关的影响、建议和行动方案。
可以记录遇到的挑战、问题、意识到的风险和机会以及其他适用的内容
在项目早期创建，作为管理项目知识过程的输出
在项目或阶段结束时，把 相关信息归入经验教训知识库，作为组织过程资产一部分。
经验教训登记册
计划更新
组织过程资产更新
8.6 项目管理知识
监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进
实际绩效与项目管理计划进行比较
决定是否需要采取纠正或预防措施，并推荐必要的措施
定期评估项目绩效
检查单个项目风险的状态
维护一个准确且及时更新的信息库，以反映产品及文件的情况
为状态报告、进展测量和预测提供信息
做出预测，更新当前的成本与进度信息
监督已批准变更的实施情况
如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态
确保项目与商业需求保持一致等
主要关注点
监控项目工作
用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合
备选方案分析
有助于出现偏差时确定最节约成本的纠正措施
挣值分析
根本原因分析
趋势分析
审查目标绩效与实际绩效之间的差异(或偏差)，可涉及持续时间估算，可以在每个知识领域，针对特定变量开展偏差分析
偏差分析
数据分析
一致同意
大多数同意
相对多数
决策
基于工作绩效信息，以实体或电子形式编制形成工作绩效报告，以制定决策、采取行动或引起关注。根据项目沟通管理计划，通过沟通过程向项目干系人发送工作绩效报告。
工作绩效报告
文件更新
8.7 监控项目工作
贯穿项目始终，项目经理对此承担最终责任
变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件
任何干系人都可以提出
确定项目基准后，必须通过实施整体变更控制过程来处理变更请求
实施整体变更控制
配置控制重点关注可交付成果及各个过程的技术规范
变更控制重点关注识别、记录、批准或否决对项目文件、可交付成果或基准的变更
识别与选择配置项，为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
识别配置项
对各个配置项的信息进行记录和报告
记录并报告配置项状态
通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，确保配置文件所规定的功能要求都已实现。
进行配置项核实与审计
配置管理活动
识别变更
记录变更
作出变更决定
跟踪变更
变更管理活动
变更控制工具
评估变更请求，并决定哪些请求可接受、应否决或需修改
有助于确定变更请求是否值得投入相关的成本
可以采取一致同意、大多数同意或相对多数原则的方式
投票
将由一个人负责为整个集体制定决策
独裁型决策制定
该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求
多标准决策分析
被否决的变更请求也应该记录在变更日志中。
变更日志
8.8 实施整体变更控制
检查
为达到阶段或项目的完工或退出标准所必须的行动和活动
关闭
为关闭项目合同协议或项目阶段合同协议所必须开展的活动
总结
为完成收集项目或阶段记录、审计项目成败、管理知识分享和传递、总结经验教训、存档项目信息以供组织未来使用等工作所必须开展的活动
移交
为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务和成果所必须开展的行动和活动
改进
收集关于改进或更新组织政策和程序的建议，并将他们发送给相应的组织部门
测量
测量干系人的满意程度等
如果项目在完工前提前终止，结束项目或阶段过程还需要制定程序，调查和记录提前终止的原因。为了实现上述目的，项目经理应该引导所有合适的干系人参与结束项目或阶段的工作。
所需执行的活动
结束项目或阶段
批准的产品规范、交货收据和工作绩效文件
对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果
验收的可交付成果
评估现有文件有助于总结经验教训和分享知识，以改进未来项目和组织资产
文件分析
作用于项目结果的不同项目变量之间的相互关系，以提高未来项目的绩效
回归分析
用于确认组织所用模式的有效性，并且为未来项目而进行相应的模式调整
可通过比较计划目标与最终结果来改进组织的测量指标
用于确认可交付成果已通过验收，已达到退出标准，正式关闭合同，评估干系人满意度，收集经验教训，传递项目知识和信息以及庆祝成功。
收尾报告会、客户总结会、经验教训会、庆祝会等
项目文件更新
最终产品、服务或成果移交
总结项目绩效
项目最终报告
运营和支持文件
项目或阶段收尾文件
经验教训知识库
8.8 结束项目或阶段
从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。
用工作绩效数据和基准计划的对比结果，也可以理解为偏差结果。是对工作绩效数据进行处理(主要是与基准计划对比)后的结果
工作绩效信息
可以正式提交给干系人，全面反映项目情况的正式文件
资源可用情况、进度和成本数据、正式管理报告、燃烧图或燃尽图
绩效数据、绩效信息和绩效报告的区别
08 项目整合管理
明确项目边界
不少做
对项目执行工作进行监控
不多做
防止项目范围发生蔓延
三方面工作
产品、服务或成果所应该具有的特征和功能
完成情况是根据产品需求来衡量的
产品范围
包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
完成情况是根据项目管理计划来衡量的
项目范围
产品范围与项目范围
需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。
该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。
项目经理与商业分析师之间应该是伙伴式合作关系
商业分析师
9.1 管理基础
管理的过程
6个过程
知识和需求管理
确认和控制
需求的稳定性
治理
敏捷或适应型生命周期
预测型项目
经过批准的项目范围说明书、WBS和WBS词典
9.2 项目范围管理过程
为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
对如何管理范围提供指南和方向
规划范围管理
描述如何定义、制定、监督、控制和确认项目范围
如何制定项目范围说明书
如何根据范围说明书创建WBS
如何审批和维护范围基准
如何正式验收已完成的项目可交付成果
作用（指导如下过程和相关工作）
范围管理计划
描述如何分析、记录和管理需求
如何规划、跟踪和汇报各种需求活动
例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
需求优先级排序过程
测量指标及使用这些指标的理由
反映哪些需求属性将被列入跟踪矩阵等
需求管理计划
9.3 规划范围管理
商业论证
高层级需求
因素+资产
大量创意、各种想法、畅所欲言
直接交谈、预设和即兴问题、深入了解、一对一、一对多、获取机密和敏感的信息
有主持人，分主题、分小组讨论
同职能、同一领域、有相似背景、主题专家(SME)、主持人、互动式讨论
最终是为了获取整个焦点小组更有价值的集体意见
受众多，地理位置分散
关键词:受众多样化、快速完成、成本低、地理位置分散、适合开展统计分析 缺点:缺乏灵活性、无法了解细节及更隐性的信息、干系人不重视、真实性差
问卷调查
将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
标杆对照所采用的可比组织可以是内部的，也可以是外部的
标杆对照
协议、商业计划、业务流程或接口文档、业务规则库、现行流程、市场文献、问题日志、政策、程序和法规文件、建议邀请书、用例等
可供分析的文档
关键词:分析现有文档
生成、归类和排序产品需求
借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序
多种标准、权重、评估、排序
分组技术
用来对大量创意进行分组的技术，以便进一步审查和分析
有助于WBS制订
亲和图
整合、反映共性与差异、激发新创意、图文并重
思维导图
数据表现
投票、排序
名义小组技术
“工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求
观察和交谈
与主题研讨会结合使用、跨职能、不同部门、协调相关方差异
是对产品范围的可视化描绘，可以直观显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式
直观、交互、拓扑图、可视化
系统交互图
步骤:1.模型创建;2.用户体验;3.反馈收集;4.原型修改;
关键词:减轻风险、渐进明细、敏捷、故事板
故事版是一种原型技术
原型法
可简可繁
需求文件描述各种单一需求将如何满足项目相关的业务需求。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准
高层级的需要
业务需求
干系人需求
产品应具备的功能
例如，产品应该执行的行动、流程、数据和交互
功能需求
对功能需求的补充，产品正常运行所需的环境条件或质量要求
例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除
非功能需求
解决方案需求
如数据转换和培训需求
描述了从“当前状态”过渡到“将来状态”所需的临时能力
过渡和就绪需求
项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素
项目需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认
基本需求
期望需求
意外需求
QFD对质量需求的分类
质量需求
与需求有关的假设条件、依赖关系和制约因素
需求的分类
需求文件
产品需求从来源连接到能满足需求的可交付成果的一种表格
使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。
需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。
业务需要、机会、目的和目标
项目目标
项目范围和WBS可交付成果
产品设计
产品开发
测试策略和测试场景
高层级需求到详细需求
跟踪需求的内容
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(例如，进行中、已取消、已推迟、新增加、已批准、已分配、己完成等)和状态日期。
为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准
需求跟踪矩阵
9.4 收集需求
制定项目和产品详细描述的过程
描述产品、服务或成果的边界和验收标准
定义范围
决策矩阵
可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。
用以把高层级的产品或服务描述转变为有意义的可交付成果
主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程
产品分析
对项目范围、主要可交付成果、假设条件和制约因素的描述
包括项目和产品范围
项目范围说明书可明确指出哪些工作不属于本项目范围
逐步细化在项目章程和需求文件中所述的产品、服务或成果特征
产品范围描述
为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果；也包括各种辅助成果，如项目管理报告和文件
可交付成果通过验收前必须满足的一系列条件
验收标准
识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
项目的除外责任
确定范围
沟通基础
规划和控制依据
变更基础
规划基础
例子
项目范围说明书
假设条件或制约因素
干系人登记册
9.5 定义范围
把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程
为所要交付的内容提供框架
WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。
是指作为活动结果的工作产品或可交付成果，而不是活动本身
工作（工作分解结构中的工作）
创建WBS
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。
自上而下的方法
使用组织特定的指南
使用WBS模版
创建WBS的方法
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上向下逐层细化分解
为WBS组件制定和分配标识编码
核实可交付成果分解的程度是恰当的
分解活动
1、项目生命周期的各级阶段的第二层，产品和项目可交付成果放在第三层
2、主要可交付成果作为分解的第二层
卖方需制定相应的合同WBS
3、纳入由项目团队以外的组织开发的各种较低层次组件，作为外包的一部分
WBS结构
提纲式
组织结构图
能说明层次结构的其他形式
WBS形式
要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。
滚动式规划
面向可交付成果的
在WBS中，所有下一级的元素之和必须100%代表上一级的元素
100%原则
必须符合项目的范围
WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算
底层应该支持计划和控制
可以多人参与
独立责任原则
可以使用工作责任矩阵来描述WBS和责任人的关系
元素必须有人负责，而且只由一个人负责
一个工作单元只能从属于某个上层单元，避免交叉从属
WBS应控制在4-6层
WBS应包括管理工作，也要包括分包出去的工作
WBS的编制需要所有（主要）项目干系人的参与
WBS并非是一成不变的
WBS分解注意8个方面
分解
工具和技术
经过批准的项目范围说明书、WBS和相应的WBS词典
范围说明书
具体
账户编码
带有独特标识号
一个管理控制点
在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效
控制账户
是一种低于控制账户而高于工作包的工作分解结构组件
工作内容已知但尚缺详细进度活动的WBS组成部分
规划包
工作包
WBS
WBS词汇表
针对WBS中的每个组件，项目描述可交付成果、活动和进度信息的文件
包括账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文件、协议信息等
WBS词典
9.6 创建WBS
正式验收已完成的项目可交付成果
使验收过程具有客观性
通过确认每个可交付成果，提高最终产品、服务或成果获得验收的可能性
确认范围应该贯穿项目的始终
确定需要进行范围确认的时间
识别范围确认需要哪些投入
确定范围正式被接受的标准和要素
确定范围确认会议的组织步骤
组织范围确认会议
确认范围的步骤
确认范围关注可交付成果的验收
控制质量关注可交付成果的正确性及是否满足质量要求
也可同时进行
通常情况下，在确认范围前，需要先进行质量控制工作
确认范围与控制质量的区别
可交付成果是否是确定的、可确认的
每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书 面认可等。
是否有明确的质量标准
审核和承诺是否有清晰的表达
项目范围是否覆盖了需要完成的产品或服务的所有活动
管理层是否能够降低风险发生时对项目的影响
项目范围的风险是否太高
项目干系人进行范围确认时，一般需要检查以下6个方面的问题
是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性
管理层关注项目范围
关心项目的可交付成果是否足够完成产品或服务
客户关注产品范围
可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法
项目管理人员关注项目制约因素
通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作
项目团队成员主要关心自己参与和负责的元素
干系人关注点的不同
确认范围
审查、产品审查和巡检
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
确认范围和项目收尾的区别
在正式会议上，将各种需求、 设计、或产品等提交给用户、客户或有关人士供其评审或批准;目的是找出其中的问题、缺陷、不足或可能的改进。 【正式评估找不足】
评审
为评估是否符合要求而进行的一种独立的检查;通过调查研究确定已制定的过程、指令、 规格说明和标准或其他的合同及特殊要求是否恰当和被遵守，以及其实现 是否有效而进行的活动。【独立检查看遵守、看有效】
审计
评审和审计
9.7 确认范围
监督项目和产品的范围状态、管理范围基准变更的过程
确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理
在变更实际发生时，也需要采用控制范围过程来管理这些变更
控制范围
用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有 必要采取纠正或预防措施
旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
客户没有提新需求，乙方自己做了额外客户不需要的工作，项目人员为了“讨好”客户而做的 不解决实际问题、没有应用价值的项目活动。
客户提出新需求，超出了范围基准
蔓延
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）
范围蔓延
9.8 控制范围
09 项目范围管理
选择进度计划方法
将项目特定数据，如活动、计划时间、持续时间、资源、依赖关系和制约因素等输入进度计划编制工具，创建项目进度模型
根据进度模型形成形成项目进度计划
项目管理团队编制进度计划的一般步骤
小型项目中，定义活动、排列活动顺序、估算活动持续时间及制定进度模型形成进度计划等过程的联系非常密切，可以视为一个过程，可以由一个人在较短时间内完成
适应型生命周期的滚动式规划进度计划的方法，它允许在整个开发生命周期期间进行变更
这种方法将需求记录在用户故事中，然后在建造之前按优先级排序并优化用户故事，最后在规定的时间内开发产品功能
一方法通常用于向客户交付增量价值，或多个团队并行开发大量的、内部关联的、较小的功能
具有未完成项的迭代型进度计划
不依赖于预先定义好的进度计划，而是在资源可用时立即从未完成项和工作序列中提取工作任务
在运营或持续环境中以增量方式研发产品的项目
工作任务的规模或范围相对类似的项目
可以按照规模或范围对任务进行组合的项目
适用于具有如下特征的项目
按需进行的进度计划
10.1 管理基础
管理过程
生命周期方法
项目维度
技术支持
在大型组织中，可能同时存在小规模项目和大规模项目的组合，需要制定长期路线图，通过规模参数(如团队规模、物理分布、法规合规性、组织复杂性和技术复杂性)来管理这些项目组合和项目集。
为管理大规模的、全组织系统的、完整的交付生命周期，可能需要采用一系列技术，包括预测型方法、适应型方法或两种方法的混合。
10.2 项目进度管理过程
备选方案分析可包括确定采用哪些进度计划方法，以及如何将不同方法整合到项目中
还可以包括确定进度计划的详细程度、滚动式规划的持续时间以及审查和更新频率。
项目进度模型
进度计划的发布和迭代长度
准确度
计量单位
工作分解结构
项目进度模型维护
控制临界值
绩效测量规则
报告格式
进度管理计划
10.3 规划进度管理
WBS中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果
滚动式规划是一种迭代式的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。
它是一种渐进明细的规划方式，适用于工作包、规划包
活动清单包括每个活动的标识及工作范围详述
对于使用滚动式规划或敏捷技术的项目，活动清单会在项目进展过程中得到定期更新
活动清单
可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量、资源需求、强制日期、制约因素和假设条件
活动属性
里程碑是项目中的重要时点或事件
并指明每个里程碑是强制性的(如合同要求的)还是选择性的(如根据历史信息确定的)
持续时间为零
里程碑清单
项目管理计划更新
10.4 定义活动
前导图法
活动节点图AON
单代号网络图
FS、FF、SS、SF
四种依赖或逻辑关系
PDM图中的节点表示
ES、EF、LS、LS
几个时间
紧前关系绘图法PDM
活动箭线图AOA
双代号网络图
网络图中每一活动和每一事件都必须有唯一的一个代号，即网络图中不会有相同的代号
任两项活动的紧前事件和紧后事件代号至少有一个不相同，节点代号沿箭线方向越来越大
流入(流出)同一节点的活动，均有共同的紧后活动(或紧前活动)
三个原则
为了绘图的方便，在箭线图中又人为引入了一种额外的、特殊的活动
只是为了弥补箭线图在表达活动依赖关系方面的不足
虚活动不消耗时间，也不消耗资源
虚活动
箭线图法（ADM）
与进度约束条件不同
硬逻辑关系或硬依赖关系
法律或合同要求的或工作的内在性质决定的依赖关系
强制性依赖关系
基于最佳实践建立的、或基于项目的某些特殊性质而采用的依赖关系 (项目团队可自由选择)
如果打算快速跟进，应当审查相应的选择性依赖关系。
选择性依赖关系
项目活动与非项目活动之间的依赖关系，往往不在项目团队的控制范 围内。
外部依赖关系
是项目活动之间的紧前关系，在项目团队的控制之中。
内部依赖关系
确定和整合依赖关系
提前量是相对于紧前活动，紧后活动可提前的时间量，提前量一般用负值表示
滞后量是相对于紧前活动，紧后活动需要推迟的时间量，滞后量一般用正值表示
提前量与滞后量
是表示项目进度活动之间的逻辑关系(也叫依赖关系)的图形
项目进度网络图
10.5 排列活动顺序
首先估算完成活动所需的工作量和计划投入该活动的资源数量
结合项目日历和资源日历
据此估算出完成活动所需的工作时段（即活动持续时间）
在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素(如资源)会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减
收益递减规律
增加资源数量，比如两倍投入资源但完成工作的时间不一定能缩短一半，因为投入资源可能会增加额外的风险
比如如果增加太多活动资源，可能会因知识传递、学习曲线、额外合作等其他相关因素而造成持续时间增加
资源数量
在确定持续时间估算时，技术进步因素可能发挥重要作用
技术进步
人们只有在最后一刻，即快到期限时才会全力以赴
拖延症
只要还有时间，工作就会不断扩展，直到用完所有的时间
帕金森定律
为了克服帕金森定律、克服懒惰综合症，我们引入了关键链法
关键链法:所有活动都是最早时间、最快速度去做，克服懒惰综合征。但是在路径末端，加上了时间缓冲段。
员工激励
需要考虑的其他因素包括
估算活动持续时间
使用相似活动或项目的历史数据来估算当前活动或项目的持续时间或成本的技术
成本较低、耗时较少，但准确性也较低
类比估算可以针对整个项目或项目中的某个部分进行，也可以与其他估算方法联合使用
类比估算法
基于历史数据和项目参数，使用某种算法来计算成本或持续时间的估算技术
它是指利用历史数据之间的统计关系和其他变量(如建筑施工中的平方英尺)，来估算诸如成本、预算和持续时间等活动参数
把需要实施的工 作量乘以完成单位工作量所需的工时，即可计算出持续时间。
参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性
参数估算可以针对整个项目或项目中的某个部分，并可以与其他估算方法联合使用
参数估算法
当历史数据不充分时，通过考虑估算中的不确定性和风险，可以提高活动持续时间估算的准确性。
使用三点估算有助于 界定活动持续时间的近似区间
三角分布:期望值(平均值)(Te)=(最悲观 P + 最乐观 O + 最可能 M)/ 3
贝塔分布:期望值(平均值)(Te)=(最悲观 P + 最乐观 O + 最可能 M✖️4)/ 6
三点估算
通过从下到上逐层汇总WBS组成部分的估算而得到项目估算
自下而上估算
用于比较不同的资源能力或技能水平、进度压缩技术、不同工具（手动和自动），以及关于资源的创建、租赁和购买决策
已知-未知风险
应急储备
未知-未知风险
不包括在进度基准中，但属于项目总持续时间的一部分
使用管理储备需要变更进度基准
管理储备
储备分析
举手表决
对完成某项活动、阶段或项目所需的工作时段数的定量评估，其中并不包括任何的滞后量，但可指出一定的变动区间
持续时间估算
持续时间估算所需的支持信息的数量和种类，因应用领域不同而不同
不论其详细程度如何，支持性文件都应该清晰、完整地说明持续时间估算是如何得出的
估算依据
10.6 估算活动持续时间
为完成项目活动而制定具有计划日期的进度模型
定义项目里程碑，识别活动并排列活动顺序，估算持续时间，并确定活动的开始和完成日期
由分配至各个活动的项目人员审查其被分配的活动
项目人员确认开始和完成日期与资源日历和其他项目或任务没有冲突，从而确认计划日期的有效性
分析进度计划，确定是否存在逻辑关系冲突，以及在批准进度计划并将其作为基准之前是否需要资源平衡，并同步修订和维护项目进度模型，确保进度计划在整个项目期间一直切实可行
制订进度计划的关键步骤
制订进度计划
进度网络分析
规则1：某项活动的最早开始时间必须相同或晚于直接指向这项活动的最早结束时间中的最晚时间
规则2：某项活动的最迟结束时间必须相同或早于该活动直接指向的所有活动最迟开始时间的最早时间
两个规则
用于在进度模型中估算项目的最短工期，确定逻辑网络路径的进度灵活性
从起点到终点持续时间最长的路径就是关键路径，关键路径可能有多条
项目中时间最长的活动顺序
决定着可能的项目最短工期
总浮动时间通常为0
关键路径
计算出工作的最早完工时间
通过反向计算来推算出最晚完工时间
总浮动时间=本活动的最迟完成时间减去本活动的最早完成时间，或本活动的最迟开始时间减去本活动的最早开始时间
总浮动时间
就是指在不延误任何紧后活动的最早开始日期或不违反进度制约因素的前提下，某进度活动可以推迟的时间量
紧后活动最早开始时间的最小值减去本活动的最早完成时间
自由浮动时间
为了使网络路径的总浮动时间为0或正值，可能需要调整活动持续时间（可增加资源或缩减范围）、逻辑关系（选择性依赖关系）、提前量和滞后量，或其他进度制约因素
关键路径法
是为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进 行调整的一种技术
通常是延长了关键路径
资源平衡往往导致关键路径改变
资源平衡是把非关键路径上的资源转移到关键路径，由于延后了非关键路径，使得关键路径发生了变化，产生新的关键路径，导致工期延长。
资源平衡
对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术
资源平滑不会改变项目的关键路径，完工日期也不会延迟
活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化
资源平滑
根据资源供需情况来调整进度模型的技术。用于调整活动的开始和完成日期以调整计划使用的资源，使其等于或少于可用的资源
资源优化
是对各种情景进行评估，预测它们对项目目标的影响(积极或消极的)
假设情景分析
是把单个项目风险和不确定性的其他来源模型化的方法，以评估它们对项目目标的潜在影响
蒙特卡洛分析
使用概率分布和不确定性的其他表现形式，来计算出多种可能的工作包持续时间
模拟
提前量和滞后量
进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满足进度制约因素、强制日期或其他进度目标
是通过增加资源，以最小的成本代价来压缩进度工期的一种技术
批准加班、增加额外资源或支付加急费用来加快关键路径上的活动
赶工只适用于那些通过增加资源就能缩短持续时间的且位于关键路径上的活动
可能导致风险和/或成本的增加
赶工
将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展
只适用于能够通过并行活动来缩短关键路径上的项目工期的情况
可能造成返工和风险增加
还有可能增加项目成本
若是使用提前量，通常会增加相关工作之间的协调工作，并增加质量风险
快速跟进
进度压缩
三点估算技术
计划评审技术（PERT）
进度计划软件
基于项目路线图和产品发展愿景，提供了高度概括的发布进度时间轴（通常是3-6个月）
同时还确定了发布的迭代或冲刺次数
敏捷或适应型发布规划
经过批准的进度模型
是进度模型的输出，为各个相互关联的活动标注了计划日期、持续时间、里程碑和所需资源
甘特图
横道图
仅标示出主要可交付成果和关键外部接口的计划开始或完成日期
里程碑图
通常用活动节点法绘制，没有时间刻度，存粹显示活动及其相互关系
称为时标图
也可以是包含时间刻度的进度网络图
项目进度计划
用以描述和控制进度计划的信息集合
进度数据
规定可以开展进度活动的可用工作日和工作班次
项目日历
10.7 制订进度计划
监督项目状态，以更新项目进度和管理进度基准变更的过程
在整个项目期间保持对进度基准的维护
定期了解里程碑的状态
确保进度受控
确保承包商报告准确且完整
执行进度状态评审和巡检
工作外包时
判断项目进度的当前状态
对引起进度变更的因素施加影响
重新考虑必要的进度储备
判断项目进度是否已经发生变更
在变更实际发生时对其进行管理
关注内容
控制进度
进度绩效测量指标（如进度偏差SV和进度绩效指数SPI）用于评价偏离初始进度基准的程度
用于追踪迭代未完项中尚待完工的工作
迭代燃尽图
根据进度基准测量、对比和分析进度绩效
绩效审查
检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化
关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，以及浮动时间的偏差
基于项目风险管理过程的输出，对各种不同的情景进行评估，促使进度模型符合项目管理计划和批准的基准
检查关键路径的进展情况
关键路径上的偏差将对项目的结束日期产生直接影响
评估次关键路径上的活动的进展情况，有助于识别进度风险
包括与进度基准相比较的项目工作执行情况
进度预测
10.8 控制进度
10 项目进度管理
对项目工程认识不足
组织制度不健全
方法问题
技术的制约
需求管理不当
项目成本失控的原因
在获得阶段(设计、生产、安装和测试等活动，即项目存续期间)、运营与维护及生命周期结束时对产品的处置所发生的全部成本。【设计、生产、运维、处置】
产品的全生命周期成本
变动成本
可变成本
固定成本
直接可以归属于项目工作的成本为直接成本
如项目团队差旅费、工资、项目使用的物料及设备使用费。(一个项目承担)
直接成本
来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本
如税金、额外福利和保卫费用。(几个项目分摊)
间接成本
是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会就是机会成本
泛指一切在做出选择后其中一个最大的损失
机会成本
是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。沉没成本是一种历史成本
在投资决策时应排除沉没成本的干扰。
沉没陈本
成本的类型
“已知-未知”风险
应急储备通常是预算的一部分
应急储备是包含在成本基准内的一部分预算
可以为某个具体活动建立应急储备，也可以为整个项目建立应急储备，还可以同时建立
应急储备可取成本估算值的某一百分比、某个固定值或者通过定量分析来确定。
管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分，使用前需要得到高层管理者审批
当动用管理储备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致成本基准变更
应急储备和管理储备
经批准的按时间安排的成本支出计划，并随时反映了经批准的项目成本的变更（所增加或减少的资金数目），被用于度量和监督项目的实际执行成本
通过对挣值管理EVM的扩展，引入挣得进度ES这一概念
11.1 管理基础
估算和预算
挣值管理
敏捷方法的使用
对易变性高、范围并未完全明确、经常发生变更的项目，可以采用轻量级估算方法快速生成对项目人力成本的高层级预测，这样在出现变更时容易调整预测
详细的估算适用于采用准时制的短期规划
11.2 项目成本管理过程
应该在项目规划阶段的早期就对成本管理工作进行规划，建立各成本管理过程的基本框架，以确保各过程的有效性及各过程之间的协调性
规划成本管理
如自筹资金、股权投资、借贷投资等
包括审查筹资的战略方法
还可以包括对筹集项目资源的方法(如自制、采购、租用或租赁)的考量
计量单位、精确度、准确度、组织程序连接、控制临界值、绩效测量规则EMV、报告格式、其它细节
成本管理计划
11.3 规划成本管理
对完成活动所需资源的可能成本进行的量化评估，是在某特定时点根据已知信息所做出的成本预测
估算成本
类比估算
参数估算
三角分布和贝塔分布
可能要用到关于质量成本的各种假设
质量成本
成本估算包括对完成项目工作可能需要的成本、应对已识别风险的应急储备
成本估算应覆盖全部资源，包括直接人工、材料、设备、服务、设施、信息技术以及一些特殊的成本种类，如融资成本(包括利息)、通货膨胀补贴、汇率或成本应急储备。
成本估算
11.4 估算成本
先把成本估算汇总到WBS中的工作包，再由工作包汇总至WBS的更高层次(如控制账户)，最终得出整个项目的总成本
活动成本—WBS工作包―控制账户―项目预算(成本基准+管理储备)
成本汇总
建立项目管理储备的储备分析
审核历史信息有助于进行参数估算或类比估算
用来建立模型的历史信息准确
模型中的参数易于量化
模型可以调整，以便对大项目、小项目和各项目阶段都适用
满足以下情况时，模型预测最为可靠
历史信息审核
应该根据对项目资金的限制来平衡资金支出，如果发现资金限制与计划支出之间存在差异，则可能需要调整工作的进度计划，以平衡资金的支出水平
例如可以通过在项目进度计划中添加 强制日期来实现
在进度计划中，标明一个时间点，在这个时间点能有多少预算给项目。限制资金过 多或者过度的提前使用
资金限制平衡
为项目获取资金
融资
经过批准的、按时间段分配的项目预算，不包括任何管理储备
项目预算的组成
成本基准、支出与资金需求
包含预计支出及预计债务
对于使用挣值管理的项目，成本基准指的是绩效测量基准
根据成本基准，确定总资金需求和阶段性(如季度或年度)资金需求
成本基准中包括预计支出及预计债务
项目资金通常以增量的方式投入，并且可能是非均衡的，呈现阶梯状
项目资金需求
11.5 制定预算
应重点分析项目资金支出与完成的相应工作之间的关系
有效成本控制的关键在于管理经批准的成本基准
对造成成本基准变更的因素施加影响
确保所有变更请求都得到及时处理
当变更实际发生时，管理这些变更
确保成本支出不超过批准的资金限额，既不超出按时段、WBS组件和活动分配的限额，也不超出项目总限额
监督成本绩效，找出并分析与成本基准间的偏差
对照资金支出，监督工作绩效
防止在成本或资源使用报告中出现未经批准的变更
向干系人报告所有经批准的变更及其相关成本
设法把预期的成本超支控制在可接受的范围内
项目成本控制的目标
控制成本
是为计划工作分配的经批准的预算
不包括管理储备
PV的总和有时被称为绩效测量基准（PMB），项目的总计划价值又被称为完工预算BAC
计划价值PV
是对已完成工作的测量值，用该工作的批准预算来表示，是已完成工作的经批准的预算
挣值EV
是在给定时段内执行某活动而实际发生的成本，是为完成与EV相对应的工作而发生的总成本
没有上限
实际成本AC
挣值、计划价值和实际成本
挣值分析EVA
SV=EV-PV
进度偏差SV
CV=EV-AC
成本偏差CV
SPI=EV/PV
进度绩效指数SPI
CPI=EV/AC
成本绩效指数CPI
VAC=BAC-EAC
完工偏差
预测
完工尚需估算（ETC）
EAC=AC+(BAC-EV)
假设将按预算单价完成ETC工作
EAC=BAC/CPI
假设以当前CPI完成ETC工作
EAC=AC+[(BAC-EV)/(CPI*SPI)]
假设SPIyuCPI将同时影响ETC工作
计算基于EVM数据的EAC值
TCPI=(BAC-EV)/(BAC-AC)
基于BAC的TCPI公式
TCPI=(BAC-EV)/(EAC-AC)
基于EAC的TCPI公式
完工尚需绩效指数TCPI
成本预测
11.6 控制成本
11 项目成本管理
反应实体满足主体明确和隐含需求的能力的特性总和
国际标准ISO定义
一组固有特性满足要求的程度
国家标准GB/T 19000
质量
质量与质量管理
质量作为实现的性能或成果，是“一系列内在特性满足要求的程度(ISO 9000)”
等级是对用途相同但技术特性不同的可交付成果的级别分类
质量与等级
保证过程中不出现错误
预防
保证错误不落到客户手中
结果的可接受范围
公差
在统计意义上稳定的过程或过程绩效的普通偏差的边界
控制界限
统计相关的术语
项目合同通常是进行项目质量管理的主要依据
在质量方面指挥和控制的活动，一般包括质量方针和质量目标以及质量规划、质量保证、质量控制和质量改进
是总方针的一个组成部分，由最高管理者批准
由组织的最高管理者正式发布的该组织总的质量宗旨和方向
质量方针
在质量方面所追求的目的
应分解落实到各部门及项目的全体成员，以便于实施、检查和考核
质量目标
让客户发现缺陷
该过程会带来相关成本，主要是评估成本和内部失败成本。
先检查和纠正缺陷，再将可交付成果发送给客户
通过质量保证检查并纠正过程本身
将质量融入项目和产品的规划和设计中
在整个组织内创建一种关注并致力于实现过程和产品质量的文化
按有效性递增排列的五种质量管理水平
全员、全过程、全组织的品质管理
全员参加
全过程
全面方法
全面结果
四个核心特征
全面质量管理TQM
质量管理标准体系
了解、评估、定义和管理要求，以便满足客户的期望
在敏捷环境中，干 系人与项目管理团队合作可确保在整个项目期间始终做到客户满意
客户满意
“计划-实施-检查-行动(PDCA)”循环是质量改进的基础
全面质量管理(TQM)、六西格玛和精益六西格玛等质量改进举措
持续改进
项目的成功需要项目团队全体成员的参与
管理层的责任
组织与其供应商相互依赖，组织应着眼于长期关系而不是短期利益
与供应商的互利合作关系
质量管理
12.1 管理基础
主要项目质量管理过程的相互关系
政策合规与审计
标准与法规合规性
干系人参与
裁剪考虑的因素
为引导变更，敏捷或适应型方法要求多个质量与审核步骤贯穿整个项目，而不是在面临项目结束时才执行
循环回顾、定期检查质量过程的效果
寻找问题的根本原因
建议实施新的质量改进方法
回顾会议评估试验过程，确定是否可行，是否应继续，做出调整或者直接弃用
为促进频繁的增量交付，敏捷或适应型方法关注于小批量工作，纳入尽可能多的项目可交付成果的要素
质量保证与质量控制的区别
12.2 项目质量管理过程
将实际或计划的项目实践或项目的质量标准与可比项目的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据
标杆对照也允许用不同应用领域或行业的项目做类比
有经验的项目参与者、干系人和主题专家有助于了解他们对项目和产品质量的隐性和显性、正式和非正式的需求和期望
用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选方案
可帮助项目经理确定规划的质量活动是否有效利用了成本
达到质量要求的主要效益包括减少返工、提高生产率、降低成本、提升干系人满意度及提升盈利能力
培训、文件过程、设备、完成时间
预防成本
测试、破坏性试验损失、检查
评估成本
管理质量的工作属于一致性成本
一致性成本
内部失败成本(项目中发现的失败):返工、报废
外部失败成本(客户发现的失败): 债务、保修工作、失去业务
失败成本（内部/外部）
非一致性成本
可用于识别关键事项和合适的备选方案，并通过一系列决策排列出备选方案的优先顺序
优先矩阵
多标准决策技术
决策技术
过程图
用来显示将一个或多个输入转化成一个或多个输出的过程中，所需步骤顺序和可能分支
有助于了解和估算一个过程的质量成本
可帮助改进过程并识别可能出现质量缺点或可以纳入质量检查的地方
流程图
把组织数据可视化，用业务语言加以描述，不依赖任何特定技术
可用于识别会出现数据完整性或其他问题的地方
逻辑数据模型
在行列交叉的位置展示因素、原因和目标之间的强弱关系
L、T、Y、X、C型和屋顶型矩阵
不同形状
有助于识别对项目成功至关重要的质量测量指标
矩阵图
是一种用于可视化组织信息的绘图法
有助于快速收集项目质量要求、制约因素、依赖关系和联系
在规划阶段，项目经理和项目团队决定如何测试或检查产品、可交付成果或服务，以满足干系人的需求和期望，以及如何满足产品的绩效和可靠性目标
不同行业有不同的测试与检查
测试与检查的规划
描述如何实施适用的政策、程序和指南以实现质量目标
它描述了项目管理团队为实现一系列项目质量目标所需的活动和资源
项目采用的质量标准
项目的质量目标
质量角色与职责
需要质量审查的项目可交付成果和过程
为项目规划的质量控制和质量管理活动
项目使用的质量工具
例如处理不符合要求的情况、纠正措施程序以及持续改进程序等
与项目有关的主要程序
质量管理计划
质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。
按时完成的任务的百分比、以CPI测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数，以及测试计划所涵盖的需求百分比（即测试覆盖度）
质量测量指标
12.3 规划质量管理
提高实现质量目标的可能性
识别无效过程和导致质量低劣的原因
使用控制质量过程的数据和结果向干系人展示项目的总体质量状态
管理质量也称为“质量保证”，但“管理质量”的定义比“质量保证”更广，因其可用于非项目工作。
管理质量的工作属于质量成本框架中的一致性工作。
质量管理是所有人的共同职责
通过执行有关产品特定方面的设计原则，设计出最优的成熟产品
建立信心，相信通过质量保证技术和工具可以使未来输出在完工时满足特定的需求和期望
确保使用质量过程并确保其使用能够满足项目的质量目标
提高过程和活动的效果与效率，获得更好的成果和绩效并提高干系人的满意度
执行项目质量管理计划中所定义的一系列有计划有系统的行动和过程，有助于
管理质量
控制质量的输出
质量控制测量结果
使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素，这些因素能够影响项目的质量目标
风险报告
用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足
文本分析
过程分析
根本原因分析RCA
可包括在不同执行情景或供应商中加以选择
项目决策
可包括评估生命周期成本、进度、干系人的满意程度，以及与解决产品缺陷有关的风险。
产品决策
可以对潜在缺陷成因进行分类，展示最应关注的领域
鱼骨图、why-why分析图、石川图
识别主要原因或根本原因
因果图
展示引发缺陷的一系列步骤
展示数字数据的条形图
可展示每个可交付成果的缺陷数量、缺陷成因排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式
直方图
在行列交叉的位置展示因素、原因和目标之间的关系强弱
是一种展示两个变量之间关系的图形，比如一只轴表示过程、环境或活动的任何要素，另一只轴表示质量缺陷
散点图
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程
如组织内部审计部门、项目管理办公室(PMO)或组织外部的审计师
质量审计通常由项目外部的团队开展
识别全部正在实施的良好及最佳实践
识别所有违规做法、差距和不足
分享所在组织和/或行业中类似的项目的良好实践
积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率
强调每次审计都应对组织经验教训知识库的积累做出贡献
质量审计目标一般包括
采取后续措施纠正问题可以降低质量成本，并提高发起人或客户对项目产品的接受度
质量审计可事先安排，也可随机进行;可由内部或外部审计师进行。
质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况
是产品设计期间可采用的一系列技术指南，旨在优化设计的特定方面，可以控制或提高产品最终特性。
DfX中的X可以是产品开发的不同方面，例如可靠性、调配、装配、制造、成本、服务、 可用性、安全性和质量
使用DfX可以降低成本、改进质量、提高绩效和客户满意度
面向X的设计
发现解决问题或应对挑战的解决方案
使用结构化的问题解决方法有助于消除问题和制定长久有效的解决方案
定义问题、识别根本原因，生成可能的解决方案，选择最佳解决方案，执行解决方案，验证解决方案的有效性等
问题解决方法通常包括以下要素
问题解决
质量改进的开展，可基于质量控制过程的发现和建议、质量审计的发现或管理质量过 程的问题解决
PDCA和六西格玛
质量改进方法
其中包含的信息可帮助其他过程和部门采取纠正措施，以实现项目质量期望
可能是图形、数据或定性文件
质量报告的信息可以包含团队上报的质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议(包括返工、缺陷/漏洞补救、100%检查等)，以及在控制质量过程中发现的情况的概述。
质量报告
可基于行业需求和组织模板创建测试与评估文件
它们是控制质量过程的输入，用于评估质量目标的实现情况
这些文件可能包括专门的核对单和详尽的需求跟踪矩阵
测试与评估文件
12.4 管理质量
合适项目可交付成果和工作已经达到主要干系人的质量要求，可供最终验收
确定项目输出是否达到预期目的
这些输出需要满足所有使用标准、要求、法规和规范
目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。通过测量所有步骤、属性和变量，来核实与规划阶段所描述规范的一致性和合规性
控制质量
有助于以结构化的方式管理控制质量活动
计数表，用于合理排列各种事项，以便有效地收集关于潜在质量问题的有用数 据。
核查表
从目标总体中选取部分样本用于检查。抽样的频率和规模应在规划质量管理过程中确定
抽样统计
可用于在部署产品或服务之后收集关于客户满意度的数据
针对实际结果测量、比较和分析规划质量管理过程中定义的质量测量指标
用于识别缺陷成因
根本原因分析RAC
是指检验工作产品，以确定是否符合书面标准
检查也可称为审查、同行审查、审计或巡检等，检查也可用于确认缺陷补救。
测试是一种有组织的、结构化的调查，旨在根据项目需求提供有关被测产品或服务质量的客观信息
测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。
测试可以贯穿于整个项目，可以随着项目的不同组成部分变得可用时进行，也可以在项目结束(即交付最终可交付成果)时进行
软件测试可能包括单元、集成、黑盒、白盒、接口、回归、α测试等
软件测试
硬件开发测试
建筑项目测试
测试类型
测试/产品评估
用于识别质量缺陷和错误可能造成的结果
用于确定一个过程是否稳定，或者是否具有可预测的绩效
控制图可用于监测各种类型的输出变量
虽然控制图最常用来跟踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控
控制图
可按来源或组成部分展示缺陷数量
可在一支轴上展示计划的绩效，在另一支轴上展示实际绩效
是对质量控制活动结果的书面记录，应以质量管理计划所确定的格式加以记录
开展控制质量过程的结果是核实的可交付成果，后者又是确认范围过程的一项输入，以便正式验收。
核实的可交付成果
12.5 控制质量
12 项目质量管理
项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程，包括实物资源和团队资源。
设备、材料、机械和基础设施
实物资源
人力资源
团队资源
类别
项目资源管理是为了降低项目成本，而对项目所需的人力、材料、机械、技术、资金等资源所进行的计划、组织、指挥、协调和控制等的活动。
执行项目工作，以实现项目目标的一组人员
由为了完成项目而承担不同角色与职责的人员组成
项目团队
直接参与项目管理活动的项目团队成员
负责项目管理和领导活动
项目管理团队
由执行组织委派，领导项目团队实现项目目标的个人
领导者+管理者
项目经理
为团队设定目标，描绘愿景，制定战略
确定方向
协调人员，团结尽可能多的力量来实现愿景和项目目标
统一思想
在向项目目标努力的过程中不可避免地要遇到艰难险阻，领导者要激励和鼓舞大家克服困难奋勇前进
激励和鼓舞
领导者
领导者设立目标，管理者率众实现目标
尊重和信任是有效领导力的关键要素
项目经理具有领导者和管理者的双重身份
领导和管理
来源于管理者在组织中的职位和职权，高级管理层对项目经理的正式授权
职位权力
使用降职、扣薪、惩罚、批评、威胁等负面手段的能力，应谨慎使用
惩罚权利
包括加薪、升职、福利、休假、礼物、口头表扬、认可度、特殊的任务以及其他的奖励员工满意行为的手段
奖励权利
来源于个人的专业技能
专家权力
由于成为别人学习参照榜样所拥有的力量
参照权利
项目经理权力的5种来源
组织授权
管理者自身
对于双重汇报关系和非直接汇报关系人员的管理，更注重运用奖励权力、专家权力和参照权利，避免使用惩罚权利
权力
冲突不一定是有害的
一团和气的集体不一定是一个高效率的集体
鼓励良性竞争，利用有益冲突，解决或减少有害冲突
冲突
冲突和竞争
相互认识、相互独立，不一定开诚布公
一个个的个体转变为团队成员，逐渐相互认识并了解项目情况及他们在项目中的角色与职责
开始形成共同目标
形成阶段
冲突、矛盾、不同的观点和意见
希望被现实打破个体之间开始争执，互相指责，并且开始怀疑项目经理的能力
震荡阶段
开始协同工作、开始相互信任
团队成员开始相互信任，项目经理能够得到团队的认可
规范阶段
组织有序、相互依靠、平稳高效
团队成员的集体荣誉感会非常强
发挥阶段
所有工作完成后，项目结束，团队解散
解散阶段
可进可退可停
不管目前处于什么阶段，增加一个人或减少一个人，都从形成期重新开始
团队发展阶段（优秀团队的建设5个阶段）
员工宿舍、工作餐、工作服、班车、工资、补贴、奖金等
生理需求
养老保险、医疗保障、长期劳动合同、意外保险、失业保险等
安全需求
定期员工活动、聚会、比赛、俱乐部等
社会交往的需求
分别来自别人和自己
自尊心和荣誉感
荣誉性的奖励，形象、地位提升，颁发奖章，作为导师培训别人
受尊重的需求
给他更多的空间让他负责、让他成为智囊团、参与决策、参与组织的管理会议
自我实现的需求
马斯洛需求层次理论
基本的需求
高层次的需求
无法起到激励作用的
不满足就会不满意，满足了不会更满意
与工作环境或条件有关的能防止人们产生不满意感的一类因素
工作环境、工资薪水、组织政策、个人生活、管理监督、人际关系等
保健因素
才能真正激励员工
不满足不会不满意，满足了才会更满意
员工的工作本身或工作内容有关的、能促使人们产生工作满意感的一类因素是高层次的需要
成就、承认、工作本身、责任、发展机会
激励因素
赫茨伯格的双因素理论
人天生好逸恶劳，只要有可能就会逃避工作
人生来就以自我为中心，漠视组织的要求
人缺乏进取心，逃避责任，甘愿听从指挥，安于现状，没有创造性
人们通常容易受骗，易受人煽动
人们天生反对改革
人的工作动机就是为了获得经济报酬
X理论对人性的假设
在项目团队的开始阶段
用X理论可以加强管理，但项目团队成员通常比较被动地工作
X理论（不好）
人天生并不是好逸恶劳，他们热爱工作，从工作得到满足感和成就感
外来的控制和处罚对人们实现组织的目标不是一个有效的办法，下属能够自我确定目标，自我指挥和自我控制
在适当的条件下，人们愿意主动承担责任
大多数人具有一定的想象力和创造力
在现代社会中，人们的智慧和潜能只是部分地得到了发挥，如果给予机会，人们喜欢工作，并渴望发挥其才能
Y理论对人性的假设
当项目团队进入执行阶段
用Y理论可以激发员工主动性，但对于员工把握工作而言可能又放任过度
Y理论（好）
麦格雷戈的X理论和Y理论
指实现该目标对个人有多大价值的主观判断
目标效价
指个人对实现该目标可能性大小的主观估计
期望值
一个目标对人的激励程度受2个因素影响
激励水平=目标效价和期望值的乘积，即: 激发力量=目标效价×期望值
期望理论
激励理论
术语
精益管理、准时制（JIT）生产、持续改善（Kaizen）、全员生产维护（TPM）、约束理论等
资源管理方法
情商EI
由通用的专才而不是主题专家组成，无需集中管控运作
PM为团队创造环境、提供支持并信任团队
自组织团队
优势：项目团队可分布在不同地理区域;可将在家办公的、行动不便者或残疾人纳入团队
挑战：沟通
虚拟/分布式团队
13.1 管理基础
多元化
物理位置
行业特定资源
团队成员的获得
团队管理
对于易变性高的项目，更适合采用能够最大限度地集中和协作的团队结构形式
协作旨在提高生产率和促进创新问题的解决，协作型团队可以促进不同工作活动的快速整合、改善沟通、增加知识分享，同时可以灵活地分配工作
对于易变性高的项目，对实物和人力资源规划具有较高的不可预测性。在这些环境中，快速供应协议和精益方法对控制成本和实现进度非常重要
敏捷与适应
13.2 项目资源管理过程
数据表现有多种格式来记录和阐明团队成员的角色与职责
层级型可用于表示高层及角色，文本型更适用于记录详细职责
可采用传统的组织结构图，自上而下地显示各种职位及其相互关系
用来显示如何把项目可交付成果分解为工作包，有助于明确高层级的职责
工作分解结构WBS
按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包
组织分解结构OBS
按资源类别和类型，对团队和实物资源的层级列表，用于规划、管理和控制项目工作，每向下一个层级代表对资源的更详细描述，直到信息细到可以与工作分解结构(WBS)相结合。
资源分解结构
层级型
展示项目资源在各个工作包中的任务分配
它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系
在大型项目中，可以制定多个层次的RAM
矩阵型图表能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清
RAM的一个例子是RACI(执行、负责、咨询和知情)矩阵
职责分解矩阵RAM
矩阵型
如果需要详细描述团队成员的职责，就可以采用文本型。提供诸如职责、职权、能力和资格等方面的信息
文本型
阐述个人、团队和组织部门的行为方式
组织理论
资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南
资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划
识别资源
获取资源
角色与职责
项目组织图
项目团队资源管理
培训
团队建设
资源控制
认可计划
资源管理计划
为团队创建团队价值观、共识和工作指南的文件
团队章程包括:团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南和团队共识。
团队章程
13.3 规划资源管理
适用于项目经理只能识别WBS的几个高层级的情况。
识别了各个工作包或工作包中每项活动所需的资源类型和数量
可以汇总这些需求，以估算每个工作包、每个WBS分支以及整个项目所需的资源
资源需求
支持性文件都应该清晰完整地说明资源估算是如何得出的
是资源依类别和类型的层级展现
资源类别包括(但不限于)人力、材料、设备和用品
资源类型则包括技能水平、要求证书、等级水平或适用于项目的其他类型
13.4 估算活动资源
获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程
项目所需资源可能来自项目执行组织的内部或外部。内部资源由职能经理或资源经理负责获取(分配)，外部资源则通过采购过程获得。
因为集体劳资协议、分包商人员使用、矩阵型项目环境、内外部报告关系或其他原因，项目管理团队有可能没有对资源选择的直接控制权。
概述和指导资源的选择
将选择的资源分配给相应的活动
项目经理或项目团队应该进行有效谈判，并影响那些能为项目提供所需团队和实物资源的人员
不能获得项目所需的资源时，可能会影响项目进度、预算、客户满意度、质量和风险，资源或人员能力不足会降低项目成功的概率，最坏情况下可能导致项目被取消
在不违反法律、规章、强制性规定或其他具体标准的前提下可以使用替代资源等
因制约因素而无法获得所需团队资源时，使用替代资源
在获取项目资源过程中应注意如下事项
选择标准常用于选择项目的实物资源或项目团队
使用多标准决策分析工具制定出标准，用于对潜在资源进行评级或打分(例如，在内部和外部团队资源之间进行选择)
可用性、成本、能力
经验、知识、技能、态度、国际因素
团队资源的独特选择标准
可使用的选择标准
确保项目在要求的时限内获得最佳资源，直到完成职责
职能经理
合理分配稀缺或特殊资源
执行组织中的其他项目管理团队
提供合适的、稀缺的、特殊的、合格的、经认证的或其他特殊的团队或实物资源
特别需要注意与外部谈判有关的政策、惯例、流程、指南、法律及其他标准
外部组织和供应商
项目管理团队需要与下列各方谈判
事先确定项目的实物或团队资源
竞标过程中承诺分派特定人员进行项目工作
项目取决于特定人员的专有技能
完成资源管理计划的前期工作之前，制定项目章程过程或其他过程已经指定了某些团队成员的工作
如下情况时可采用预分派
预分派
虚拟团队可定义为具有共同目标，在完成角色任务的过程中很少或没有时间面对面工作的一群人
不同地理位置
增加特殊技能和专家
在家办公的员工纳入团队
在工作班次、工作小时或工作日不同的员工之间组建团队
将行动不便者或残疾人纳入团队
执行那些原本会因差旅费用过高而被搁置或取消的项目
节省员工所需的办公室和所有实物设备的开支等
优势
虚拟团队
记录了项目将使用的材料、设备、用品、地点和其他实物资源
物质资源分配单
记录了团队成员及其在项目中的角色和职责
可包括项目团队名录，还需要把人员姓名插入项目管理计划的其他部分，如项目组织图和进度计划
项目团队派工单
识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期
规定了项目期间确定的团队和实物资源何时可用和可用多久
资源日历
组织内资源的可用性;组织已使用的消耗资源数量。
因素和资产更新
13.5 获取资源
提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程
改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效
使用开放与有效的沟通
创造团队建设机遇
建立团队成员间的信任
以建设性方式管理冲突
鼓励合作型的问题解决方法
鼓励合作型的决策方法等
可实现团队的高效运行的行为有
项目管理团队应该利用文化差异，在整个项目生命周期中致力于发展和维护项目团队，并促进在相互信任的氛围中充分协作;通过建设项目团队，可以改进人际技巧、技术能力、团队环境及项目绩效
提高团队成员的知识和技能
提高团队成员之间的信任和认同感
创建富有生气、凝聚力和协作性的团队文化
提高团队参与决策的能力
建设项目团队的目标包括
建设团队
集中办公
集中办公:团队营造一个融洽的环境
共享门户
视频会议
音频会议
电子邮件/聊天软件
虚拟团队(团队成员分散在不同时区的团队)
沟通技术
项目经理应及时地以建设性方式解决冲突，从而创建高绩效团队
收集相关的关键信息，在维护相互信任的关系时，用来解决重要问题并达成一致意见
影响力
为采取行动提供了理由。提高团队参与决策的能力并鼓励独立工作
激励
团队成员之间的谈判旨在就项目需求达成共识。
谈判有助于在团队成员之间建立融洽的相互信任的关系
谈判
通过举办各种活动，强化团队的社交关系，打造积极合作的工作环境。
状态审查会上的5分钟议程
专业提升活动
团队建设活动
非正式的沟通和活动有助于建立信任和良好的工作关系。就需要持续不断地开展团队建设。
最初的奖励计划是在规划资源管理过程中编制的
只有能满足被奖励者的某个重要需求的奖励，才是有效的奖励。
项目经理应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时才给予。
认可与奖励
培训包括旨在提高项目团队成员能力的全部活动
如果项目团队成员缺乏必要的管理或技术技能，可以把对这种技能的培养作为项目工作的一部分
或者如果增加的技能有利于未来的项目，则由执行组织承担
培训成本通常应该包括在项目预算中
个人和团队评估工具能让项目经理和项目团队洞察成员的优势和劣势
这些工具有利于增进团队成员间的理解、信任、承诺和沟通
工具：态度调查、专项评估、结构化访谈、能力测试及焦点小组
个人和团队评估
使成员更有效地完成工作任务
个人技能的改进
从而使团队成员更好地开展工作
团队能力的改进
团队成员离职率的降低
从而使团队成员公开分享信息和经验，并互相帮助来提高项目绩效。
团队凝聚力的加强
评价团队有效性的指标
团队绩效评价
员工发展计划的记录;技能评估等
13.6 建设团队
跟踪团队成员工作表现、提供反馈、解决问题并管理团队变更以优化项目绩效的过程
影响团队行为、管理冲突以及解决问题
管理团队
来源包括资源稀缺、进度优先级排序和个人工作风格差异等
撤退/回避
缓和/包容
双输
妥协/调解
输-赢
强迫/命令
双赢
合作/解决问题
冲突解决方法
而不是决策工具集所描述的一系列工具
谈判能力以及影响组织与项目管理团队的能力
制定决策
识别、评估和管理个人情绪、他人情绪及团体情绪的能力
情商
适时影响干系人的能力，对保证项目成功非常关键
说服他人
清晰表达观点和立场
积极且有效的倾听
了解并综合考虑各种观点
收集相关信息
在维护相互信任的关系下，解决问题并达成一致意见
主要体现
影响
是领导团队、激励团队做好本职工作的能力
人员配备变更，无论是自主选择还是由不可控事件造成，都会干扰项目团队，这种干扰可能导致进度落后或预算超支
人员配备变更包括转派人员、外包部分工作和替换离职人员
项目信息系统
13.7 管理团队
确保按计划为项目分配实物资源，以及根据资源使用计划监督资源实际使用情况，并采取必要纠正措施的过程
更新资源分配时，需要了解已使用的资源和还需要获取的资源。应审查至今为止的资源使用情况。
确保所分配的资源适时、适地可用于项目
资源在不再需要时被释放
监督资源支出
及时识别和处理资源缺乏/剩余情况
确保根据计划和项目需求使用并释放资源
出现资源相关问题时通知相应干系人
影响可以导致资源使用变更的因素
在变更实际发生时对其进行管理等
控制资源过程关注
控制资源
有助于选择最佳解决方案以纠正资源使用偏差
可将加班和增加团队资源等备选方案与延期交付或阶段性交付比较，以权衡利弊
有助于项目成本出现差异时确定最佳的纠正措施
测量、比较和分析计划的资源使用和实际资源使用的不同
分析成本和进度工作绩效信息有助于指出可能影响资源使用的问题
可能会用到一系列工具，有助于项目经理解决控制资源过程中出现的问题
项目经理需要就增加实物资源、变更实物资源或资源相关成本进行谈判
人际关系技能
13.8 控制资源
13 项目资源管理
项目沟通管理确保及时、正确地产生、收集、分发、存储和最终处理项目信息所需的过程
项目沟通管理由两部分组成:一是制定策略，确保沟通对干系人行之有效;二是执行必要活动，以落实沟通策略。
书面、口头、正式或非正式、手势、媒体、遣词造句
沟通的形式
编码、信息和反馈信息、媒介、噪声、解码
沟通模型的关键要素
已发送、已收到、已理解、已认可、已转化为积极的行动
沟通模型的状态
沟通的模型
内部沟通
外部沟通
正式沟通
非正式沟通
向上、向下和横向
层级沟通
官方沟通
非官方沟通
书面与口头沟通
沟通分类
正确的语法和拼写
简洁的表述
清晰的目的和表述
连贯的思维逻辑
善用控制语句和承接
书面沟通的5C原则
理解文化和个人差异
识别、设定并管理干系人期望
强化技能
其他的沟通技巧
沟通的技巧
定期对项目相关方群体的成员进行评审，识别是否还是利益方，以及态度的变化，并顺变管理策略
将干系人纳入项目评审范围
如敏捷中的每日站会。站会上，项目团队和主要相关方就前一天的成绩和问题以及当天的工作计划展开讨论
让干系人参加项目会议
社交媒体工具不仅能支持信息交换，而且也有助于建立更深层次的信任和社群关系。
社交工具的使用日益增多
考虑所有可用技术，尊重因文化、实践和个人背景而产生的对沟通方式的偏好。根据需要采用社交媒体和其他电脑技术，与不同年代和文化背景的相关方沟通。
多面性沟通方法
14.1 管理基础
干系人
物理地点
语言
在模糊不定的项目环境中，必然需要对不断演变和出现的细节情况进行更频繁和快速地沟通
应该尽量简化团队成员获取信息的通道，要经常进行团队检查，并让团队成员集中办公。此外为了促进与高级管理层和干系人的沟通，还需要以透明的方式发布项目成果，并定期邀请干系人评审项目成果
14.2 项目沟通管理过程
及时向干系人提供相关信息
引导干系人有效参与项目
编制书面沟通计划
规划沟通管理
分析沟通需求，确定项目干系人的信息需求，包括所需信息的类型和格式，以及信息对干系人的价值
沟通需求分析
信息需求的紧迫性
技术的可用性和可靠性
易用性
项目环境
信息的敏感性和保密性
影响沟通技术选择的因素
沟通模型
会议、电话、即时通信、社交媒体、视频会议
互动式沟通
信件、备忘录、报告、电子邮件、传真语音邮件、博客和新闻稿
推式沟通
门户网站、组织内网、电子在线课程、 经验教训数据库或知识库
拉式沟通
干系人分享信息沟通方法
人际沟通
小组沟通
公众沟通
大众传播
网络和社交工具沟通
沟通方法
常用于不支持项目的干系人
沟通风格评估
有助于项目经理根据项目环境和组织的政策环境来规划沟通
政策意识是指对正式和非正式权力关系的认知，以及在这些关系中工作的意愿
政策意识
指理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。
文化意识
干系人参与度评估矩阵显示了个体干系人当前和期望参与度之间的差距
描述将如何规划、结构化、执行与监督项目沟通，以提高 沟通的有效性。
干系人的沟通需求
需沟通的信息
上报步骤
发布信息的原因
发布所需信息、确认已收到或作出回应的时限和频率
负责沟通相关信息的人员
负责授权保密信息发布的人员
接受信息的人员或群体，包括他们的需要、需求和期望
用于传递信息的方法或技术
为沟通活动分配的资源，包括时间和预算
随着项目进展而更新与优化沟通管理计划的方法
通用术语表
项目信息理想图、工作流程（可能包含审批程序）、报告清单和会议计划等
来自法律法规、技术、组织政策等的制约因素等
项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模版
项目网站和项目管理软件
还包括
沟通管理计划
14.3 规划沟通管理
管理沟通过程会涉及与开展有效沟通有关的所有方面，包括使用适当的技术、方法和技巧
还应允许沟通活动具有灵活性，允许对方法和技术进行调整，以满足干系人及项目不断变化的需求
本过程不局限于发布相关信息，它还设法确保信息以适当的格式正确生成和送达目标受众
本过程也为干系人提供机会，允许他们参与提供更多信息、澄清和讨论。
发送方-接收方模型
媒介选择
写作风格
演示
有效的沟通管理需要借助的技术
管理沟通
状态报告和进展报告
工作绩效报告会通过本过程传递给项目干系人
工作绩效报告可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息以及风险概述信息
可表现为有助于引起关注、制定决策和采取行动的仪表指示图、热点报告、信号灯图或其他形式。
经过裁剪的沟通技能的组合，有助于明确关键信息的目的、建立有效关系、实现信息共享和采取领导行为
沟通胜任力
是关于沟通、可交付成果或情况的反应信息
反馈
通过示意、语调和面部表情等适当的肢体语言来表达意思
非口头技能
演示是信息和文档的正式交付
向干系人明确、有效地演示项目的信息
向干系人报告项目进度和信息更新
提供背景信息以支持决策制定
提供愿意项目及其目标的通用信心，以提升项目工作和项目团队的形象
提供具体信息，以提升对项目工作和目标的理解和支持力度
沟通技能
发布是收集和发布项目信息的行为
项目信息应发布给众多干系人群体
从简单的沟通到详尽的定制报告和演示，报告的形式各不相同。
应针对每种干系人来调整项目信息发布的适当层次、形式和细节
项目报告
准备并发布会议议程
确保会议在规定的时间开始和结束
确保适当参与者受邀并出席
切题
处理会议中的期望、问题和冲突
记录所有行动以及所分配的行动责任人
规划会议的一般步骤
通过与他人互动交流信息，建立联系
有助于项目经理在项目期间引导干系人参与，以保持干系人的支持
包括绩效报告、可交付成果的状态、进度进展、产生的成本、演示，以及干系人需要的其他信息。
项目沟通记录
资产更新
14.4 管理沟通
确保满足项目及其干系人的信息需求的过程
按沟通管理计划和干系人参与计划的要求优化信息传递流程
监督沟通
干系人参与度评估矩阵
14.5 监督沟通
14 项目沟通管理
项目风险会对项目目标产生负面或正面的影响也就是风险与机会
风险事件的随机性
收益的大小
投入的大小
个人或组织拥有的资源越多，其风险承受能力也越大
项目活动主体的地位和拥有的资源
风险承受能力的因素
风险的相对性
风险性质的变化
风险后果的变化
出现新风险
风险的可变性
风险的属性
不能带来机会、无获得利益可能
后果：造成损失和不造成损失
纯粹风险
既可能带来机会、获得利益，又隐含威胁、造成损失的风险
纯粹风险和投机风险在一定条件下可以相互转化
很多情况下，涉及风险的各个方面都要蒙受损失，无一幸免
风险不是零和游戏
投机风险
按风险后果划分
自然风险
人为风险
按风险来源划分
按风险是否可管理划分
局部风险和总体风险
按风险影响范围划分
业主、政府、承包商、投资方、设计单位、监理单位、供应商、担保方和保险公司
按风险后果的承担者划分
可以分析、经常发生、后果亦可预见
已知风险
可以预见其发生，不可预见其后果
可预测风险
可能发生，可能性不能预见
未知风险或未识别风险
例如地震、百年不遇的暴雨、通货膨胀和政策变化
不可预测风险
按风险的可预测性划分
风险的分类
直接损失
间接损失
有形成本
风险损失减少了机会
风险阻碍了生产率的提高
风险造成资源分配不当
无形成本
既有直接的，也有间接的
向保险公司投保、向有关方面咨询、配备必要的人员、购置用于预防和减损的设备、对有关人员进行教育或训练以及人员和设备的维持和维护费用
预防与控制风险的成本
风险成本及其负担
已规划的目标、活动或决策的某些关键方面存在不确定性
可用蒙特卡洛分析
变异性风险
对未来可能发生什么存在不确定性
获取外部专家的意见或以最佳实践为标杆来填补差距
可以用增量开发、原型搭建或模拟等方法来处理
模糊性风险
非事件类风险
预留合理应急预算和时间
采用灵活的项目过程
授权目标明确且值得信赖的项目团队在商定范围内完成工作
留意早期预警信号，以尽早识别突发性风险
明确征求干系人的意见，为应对突发性风险而可以调整项目范围或策略的领域
要求
加强项目韧性
突发性风险
较高层面识别出的某些风险，可以及时授权给项目团队去管理
较低层面识别出的某些风险，又可以交给较高层面去管理
利用组织级的风险管理方法，来确保所有层面的风险管理工作的一致性和连贯性
整合式风险管理
15.1 管理基础
项目规模
项目复杂性
项目重要性
在选择每个迭代期的工作内容时都要考虑风险;在每个迭代期间应该识别、分析和管理风险。
应根据对当前风险忍受度的深入理解，定期更新需求文件，并随项目进展重新排列工作优先级
15.2 项目风险管理过程
确保风险管理的水平、方法和可见度与项目风险程度相匹配，与对组织和其他干系人的重要程度相匹配
后期可能有必要重新开展本过程
立项阶段就应开始，并在项目早期完成
规划风险管理
确定项目干系人的风险偏好
干系人分析法
风险管理策略
方法论
时间安排
风险分解结构RBS
风险类别
应该针对每个项目目标，把干系人的风险偏好表述成可测量的风险临界值
干系人风险偏好
风险概率和影响
概率和影响矩阵
跟踪
风险管理计划
15.3 规划风险管理
识别单个项目风险以及整体项目风险的来源，并记录风险特征的过程
记录现有的单个项目风险，以及整体项目风险的来源
汇总相关信息，以便项目团队能够恰当地应对已识别的风险
识别风险
获取一份全面的项目风险来源的清单
应该特别注意对头脑风暴识别 的风险进行清晰描述。
包括需要考虑的项目、行动或要点的清单。用作提醒。
检查单
识别项目风险的来源
从假设条件的不准确、不稳定、不一致或不完整，可以识别出威胁
通过清除或放松会影响项目或过程执行的制约因素，可以创造出机会
假设条件和制约因素分析
SWOT分析
是关于可能引发项目风险来源的风险类别的预设清单
可以用风险分解结构底层的风险类别作为提示清单，来识别单个项目风险。
某些常见的战略框架更适用于识别整体项目风险的来源，如外部影响(政策、经济、社会、技术、法律、环境)、内部影响(技术、环境、商业、运营、政治)和性质(易变性、不确定性、复杂性、模糊性)
提示清单
已识别风险的清单、潜在风险责任人、潜在风险应对措施清单
已识别风险的清单
潜在风险责任人
潜在风险应对措施清单
简短的风险名称
当前风险状态
一项或多项原因
对目标的影响
风险触发条件
受影响的WBS组件
时间信息（风险何时识别、可能何时发生、何时可能不再相关、采取行动的最后期限）
其他数据
风险登记册
整体项目风险的来源
关于已识别单个项目风险的概述信息
15.4 识别风险
评估单个项目风险发生的概率和影响及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程
重点关注高优先级的风险
本过程会为每个风险识别出责任人，以便由他们负责规划风险应对措施，并确保应对措施的实施
实施定性风险分析
结构化或半结构化的访谈可用于评估单个项目风险的概率和影响
旨在评价关于单个项目风险的数据的准确性和可靠性
风险数据质量评估
风险概率评估考虑的是特定风险发生的可能性
风险影响评估考虑的是风险对一项或多项项目目标的潜在影响
低概率和影响的风险将被列入风险登记册中的观察清单，以供未来监控
风险概率和影响评估
紧迫性、临近性、潜伏期、可管理性、可控性、可监测性、连通性、战略影响力、密切度
考虑这些特征有助于进行更稳健的风险优先级排序
其他风险参数评估
对风险进行分类，有助于把注意力和精力集中到风险可能发生的最大的领域
或针对一组相关的风险 制定通用的风险应对措施
风险分类
把每个风险发生的概率和该风险一旦发生对项目目标的影响映射起来的表格
基于所得到的概率和影响的组合，使用概率和影响矩 阵，来为单个项目风险分配优先级别
X轴代表可监测性，Y轴代表邻近性，影响值则以气泡大小表示
气泡图能显示三维数据
层级图
更新内容可能包括:每项单个项目风险的概率和影响评估、优先级别或风险分值、指定风险责任人、风险紧迫性信息或风险类别，以及低优先级风险的观察清单和需要进一步分析的风险。
15.5 实施定性风险分析
量化整体项目风险最大可能性
提供额外的定量风险信息，以支持风险应对规划
并非所有项目都需要实施定量风险分析
定量风险分析也可以在规划风险应对过程之后开展，以分析已规划的应对措施对降低整体项目风险最大可能的有效性
实施定量风险分析
三角分布、正态分布、对数正态分布、贝塔分布、均匀分布或离散分布
概率分布的形式
不确定性表现方式
对成本风险进行蒙特卡洛分析时，使用项目成本估算作为模拟的输入
对进度风险进行蒙特卡洛分析时，使用进度网络图和持续时间估算作为模拟的输入;其输出就是定量风险分析模型
典型的输出包括:表示模拟得到特定结果的次数的直方图，或表示获得等于或小于特定数值的结果的累积概率分布曲线(S曲线)
以确定风险模型的哪些活动对项目 关键路径的影响最大
关键性分析
龙卷风图
有助于确定哪些单个项目风险或不确定性来源对项目结果具有最大的潜在影响
用决策树在若干备选行动方案中选择一个最佳方案
决策树分析
影响图
对整体项目风险最大可能性的评估结果
项目详细概率分析的结果
单个项目风险优先级清单
定量风险分析结果的趋势
风险应对建议
15.6 实施定量风险分析
应对项目风险，而制定可选方案、选择应对策略并商定应对行动的过程
制定应对整体项目风险和单个项目风险的适当方法
分配资源，并根据需要将相关活动添加进项目文件和项目管理计划中
风险应对方案应该与风险的重要性相匹配，并且能够经济有效地应对挑战，同时在当前项目背景下现实可行，获得全体干系人的同意，并由一名责任人具体负责。
如果选定的策略并不完全有效，或者发生了已接受的风险，就需要制定应急计划
也需要识别次生风险，次生风险是实施风险应对措施直接导致的风险
规划风险应对
上报
消除威胁的原因、延长进度计划、改变项目策略或缩小范围
规避
通常需要想承担威胁的一方支付风险转移费用
也可以通过签订协议
购买保险、使用履约保函、使用担保书和使用保证书等
转移
降低概率和影响
减轻
承认威胁的存在
建立应急储备。包括预留时间、资金或资源以应对出现的威胁
主动接受策略
不会主动采取行动，而只是定期对威胁进行审查，确保其并未发生重大改变
被动策略
接受
针对威胁备选的应对策略
威胁应对策略
确保其肯定出现，从而获得与其相关的收益
分配最有能力的资源缩短完工时间，采用全新技术或技术升级来节约成本并缩短项目持续时间
开拓
第三方
安排新的责任人
建立合伙关系、合伙团队、特殊公司和合资企业分享机会
分享
提高机会出现的概率
为早日完成活动而增加资源
提高
针对机会备选的应对策略
机会应对策略
可设计一些仅在特定事件发生时才采用的应对措施。
对于某些风险，如果项目团队相信其发生会有充分的预警信号，那么就应该制订仅在某些预定条件出现时才执行的应对计划
通常称为应急计划
应该定义并跟踪应急应对策略的触发条件
应急应对策略
建立买房和卖方分享整体项目风险的协作式业务结构、成立合资企业后特殊目的公司，或对项目的关键工作进行分包
转移或分享
重新规划项目、改变项目范围和边界、调整项目优先级、改变资源配置、调整交付时间等
减轻或提高
整体项目风险应对策略
确定备选风险应对策略的成本有效性
策略的有效性=应对的结果/应对花费的成本
成本收益分析
应对成本、应对策略在改变概率和影响方面的预计有效性、资源可用性、时间限制（紧迫性、临近性和潜伏期）、风险发生的影响级别、应对措施对相关风险的作用、导致的次生风险等
选择标准
商定的应对策略
实施所选应对策略所需要的具体行动
风险发生的触发条件、征兆和预警信号
实施所选应对策略所需要的预算和进度活动
应急计划及启动该计划所需的风险触发条件
回退计划，供风险发生且主要应对措施不足以应对时使用
采取预定应对措施之后仍存在的残余风险，以及被有意接受的风险
由实施风险应对措施而直接导致的次生风险
15.7 规划风险应对
执行商定的风险应对计划的过程
确保按计划执行商定的风险应对措施
管理整理项目风险入口、最小化单个项目威胁，以及最大化单个项目机会
实施风险应对
有些风险应对措施可能由项目团队以外的人员执行，或由存在其他竞争性需求的人员执行。
这种情况下，负责引导风险管理过程的项目经理或人员就需要施展影响力，去鼓励指定的风险责任人采取所需的行动
15.8 实施风险应对
评估风险管理有效性
实施的风险应对是否有效
整体项目风险级别是否已改变
已识别单个项目风险的状态是否已改变
是否出现新的单个项目风险
风险管理方法是否依然适用
项目假设条件是否仍然成立
风险管理政策和程序是否已得到遵守
项目策略是否仍然有效
采用项目执行期间生成的绩效信息，以确定
监督风险
把项目执行期间所取得的技术成果与取得相关技术成果的计划进行比较
技术绩效分析
在项目的任一时点比较剩余应急储备与剩余风险量，从而确定剩余储备是否仍然合理
可以用各种图形(如燃尽图)来显示应急储备的消耗情况
项目经理负责确保按项目风险管理计划所规定的频率开展风险审计
风险审计可以在日常项目审查会和风险审查会上开展，团队也可以召开专门的风险审计会
在实施审计前，应明确定义风险审计的程序和目标
评估风险管理过程的有效性
风险审计
风险审查会
15.9 监督风险
15.10 风险管理示例
15 项目风险管理
项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程
协议可以是合同、服务水平协议（SLA）、谅解备忘录、协议备忘录（MOA）或订购单
承包商、供货商、服务提供商或供应商
卖方
最终产品的所有人、分包商、收购机构、服务需求者或购买方
买方
主要公司和政府都开始要求在大型项目中使用建筑信息模型(BIM)
工具的改进
编制合同时准确地将具体风险分配给最有能力对其加以管理的一方
更先进的风险管理
超大型项目数量显著增加，要求与多个国家签署国际合同，采用国际公认的标准合同范本日益普遍
变化中的合同签署实践
订购周期长的产品提前采购
明确主要、次要、备选采购渠道
要求跨国承包商向当地供应商采购一定比例的材料和用品
物流和供应链管理
网络摄像机的应用:进展报告、索赔支持
技术和关系人关系
先小批量试采，再批量采购
试用采购
16.1 管理基础
采购的复杂性
治理和法规环境
承包商的可用性
在敏捷或适应型环境中，可能需要与特定卖方进行协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目收益。
在大型项目上，可能针对某些可交付成果采用敏捷或适应型方法，而对其他部分则采用更稳定的方法
在这种情况下，可以通过主体协议，如主要服务协议(MSA)来管理整体协作关系，而将敏捷或适应型工作写入附录或补充文件
16.2 项目采购管理过程
记录项目采购决策、明确采购方法，及识别潜在卖方的过程
准备采购工作说明书SOW或工作大纲TOR
准备高层级的成本估算，制定预算
发布招标广告
确定合格卖方的名单
准备并发布招标文件
由卖方准备并提交建议书
对建议书开展技术（包括质量）评估
对建议书开展成本评估
准备最终的综合评估报告（包括质量及成本），选出中标建议书
结束谈判，买方和卖方签署合同
一般采购的步骤
规划采购管理
预先批准的卖方清单
正式的采购政策、程序和指南
固定总价FFP
价格上限
总价加激励费用FPIF
总价加经济价格调整FPEPA
总价合同FPC
成本加固定费用CPFF
成本加激励费用CPIF
不允许申诉
主观判断绩效
成本加奖励费用CPAF
成本补偿合同
混合型合同
工料合同T&M
合同类型
市场调研
组织当前的资源配置及其技能和能力
对专业技术的需求
不愿承担永久雇佣的义务
对独特技术专长的需求
评估与每个自制或外购决策相关的风险
自制或外购分析
标准化或常规采购
最低成本
仅凭资质
基于技术方案
同时考虑质量和成本。当风险大时，质量更关键
基于质量和成本
特殊情况
仅在有适当理由时
唯一来源
SOW定义精确，预期不会发生变更预算固定不超出
固定预算
选择方法
供方选择分析
采购管理计划包含要在采购过程中开展的各种活动
协调采购与项目的其他工作
开展重要采购活动的时间表
用于管理合同的采购测量指标
与采购有关的干系人角色和职责
可能影响采购工作的制约因素和假设条件
司法管辖权和付款货币
是否需要编制独立估算，以及是否应将其作为评价标准
风险管理事项，包括对履约保函或保险合同的要求，以减轻某些项目风险
拟使用的预申合格的卖方（如果有）
采购管理计划
专业服务项目的交付方法
交钥匙式、设计-建造(DB)、设计-招标-建造(DBB)、设计-建造-运营(DBO)、建造-拥有-运营-转让(BOOT)及其他
工业或商业施工项目的交付方法
交付方法
合同支付类型
采购工作的顺序安排或阶段划分
每个阶段的描述
以及每个阶段的具体目标
用于监督的采购绩效指标和里程碑
从一个阶段过渡到下一个阶段的标准
用户追踪采购进展的监督和评估计划
向后续阶段转移知识的过程
采购阶段
采购策略
规格、所需数量、质量水平、绩效数据、履约期间、工作地点和其他请求
采购工作说明书
用于向潜在卖方征求建议书
更多信息
信息邀请书RFI
如何满足需求和/或将需要多少成本
报价邀请书RFQ
项目中出现问题且解决办法难以确定
最正式的邀请书文件
建议邀请书RFP
其他适当的采购文件
形式
招标文件
自制或外购决策
对于大型的采购，采购组织可自行准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准
独立成本估算
主要包括:能力和潜能;产品成本和生命周期成本;交付日期;技术专长和方法;具体的相关经验;用于响应工作说明书的工作方法和工作计划;关键员工的资质、可用性和胜任力;组织的财务稳定性;管理经验;知识转移计划，包括培训计划等。
供方选择标准
组织资产更新
16.3 规划采购管理
获取卖方应答、选择卖方并授予合同的过程
实施采购
采购文档
卖方为响应采购文件包而编制的建议书，其中包含的基本信息将被评估团队用于选定一个或多个投标人(卖方)
如果卖方将提交价格建议书，最好要求他们将价格建议书与技术建议书分开
卖方建议书
是就产品、服务或成果与用户或潜在用户进行的沟通
扩充现有的潜在卖方名单
广告
承包商会议、供应商会议或投标前会议
投标人会议
确定它们是否对包含在招标文件包中的招标文件、采购工作说明书、供方选择标准和其他文件，都做出了完整且充分的响应
建议书评估
谈判是为达成协议而进行的讨论
采购谈判是指在合同签署之前，对合同的结构、各方的权利和义务，以及其他条款加以澄清，以便双方达成共识
最终的文件措辞应该反映双方达成的全部一致意见
是在建议书评估或投标评估中被判断为最有竞争力的投标人
选定的卖方
合同是对双方都有约束力的协议
它强制卖方提供规定的产品、服务或成果，强制买方向卖方支付相应的报酬。
采购工作说明书或主要的可交付成果
进度计划、里程碑，或进度计划中规定的日期
绩效报告
定价和支付条款
检查、质量和验收标准
担保和后续产品支持
激励和惩罚
保险和履约保函
下属分包商批准
一般条款和条件
变更请求处理
终止条款和替代争议解决方法
主要包括
16.4 实施采购
管理采购关系、监督合同绩效、实施必要的变更和纠偏，以及关闭合同的过程
合同关系的法律性质，要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果。
控制采购的质量，包括采购审计的独立性和可信度，是采购系统可靠性的关键决定因素
组织的道德规范、内部法律顾问和外部法律咨询，包括持续的反腐计划，都有助于实现适当的采购控制
在控制采购过程中，需要开展财务管理工作，包括监督向卖方付款。
在合同收尾前，若双方达成共识，可以根据协议中的变更控制条款，随时对协议进行修改。通常要书面记录对协议的修改
控制采购
包含用于管理采购过程的完整支持性记录，包括工作说明书、支付信息、承包商工作绩效信息、计划、图纸和其他往来函件
谈判是解决所有索赔和争议的首选方法
替代争议解决方法(ADR)
索赔管理
对照协议，对质量、资源、进度和成本绩效进行测量、比较和分析，以审查合同工作的绩效
其中包括确定工作包提前或落后于进度计划、超出或低于预算，以及是否存在资源或质量问 题
是甲方对乙方过程的审查
可能涉及对可交付成果的简单审查或对工作本身的实地审查
是指对承包商正在执行的工作进行结构化审查
是甲方对乙方可交付成果的检查
是对采购过程的结构化审查
甲方对自己整个采购过程的审计
买方通常通过其授权的采购管理员，向卖方发出合同已经完成的正式书面通知
已按时按质按技术要求交付全部可交付成果
没有未决索赔或发票
全部最终款项己付清
关于正式关闭采购的要求，通常已在合同条款和条件中规定，包括在采购管理计划中
项目管理团队应该在关闭采购之前批准所有的可交付成果。
采购关闭
采购文档更新
支付计划和请求
卖方绩效评估文件
预审合格卖方清单更新
采购档案
16.5 控制采购
容易管理和协调
项目总承包合同
单项实力强
项目单项承包合同
经过买方认可
分包的部分必须是项目非主体工作
只能分包部分项目，而不能转包整个项目
分包的部分必须具备相应的资质条件
分包方不能再次分包
必须满足的条件
项目分包合同
按项目范围划分
总价合同
工料合同
按项目付款方式划分
合同的类型
工作范围很明确，且项目的设计已具备详细的细节
卖方承担成本风险
工作性质清楚，但范围不是很清楚，而且工作不复杂，又需要快速度签订合同
双方分担风险
工作范围尚不清楚
买方承担成本风险
购买标准产品，且数量不大
单边合同（订购单）
合同类型选择
项目的名称
标的的内容和范围
项目的质量要求
项目的计划、进度、地点、地域和方式
项目建设过程中的各种期限
技术情报和资料的保密
风险责任的承担
技术成果的归属
验收的标准和方法
价款、报酬（或使用费）及其支付方式
违约金或者损失赔偿的计算方法
解决争议的方法
名词术语解释
相关文档资料
项目变更的约定
技术支持服务
补充条款或附件
合同的内容
市场调查
潜在合作伙伴或竞争对手的资信调查
了解相关环境，做出正确的风向分析判断
合同签订之前
使用国家或行业标准的合同格式
准确、简练、清晰
为避免因条款的不完备或歧义而引起合同纠纷，卖方应认真审阅买房拟定的合同条款
对合同中的质量条款应具体写清规格、型号、适用的标准等
对于合同中需要变更、转让和解除等内容也应详细说明
如果合同有附件，对于附件的内容也应精心准备，并注意保持与主合同一致，不要相互之间产生矛盾
对于既有投标书，又有正式合同书、附件等包含多项内容的合同，要在条款中列明适用顺序
为避免合同纠纷，保证合同订立的合法性和有效性，当事人可以执签订的合同到公证机关进行公证
避免方案变更导致工程变更，从而引发新的误解
注意合同内容的前后一致性
合同一致理解的建议
合同的签订管理
合同争议、合同违约和合同索赔
检查、处理和解决问题
谈判（协商）、调解、仲裁、诉讼
解决争议的方法其优先顺序为
合同的履行管理
书面提出
合同的变更管理
合同档案管理(文本管理)是整个合同管理的基础。合同档案管理还包括正本和副本管理、合同文件格式等内容
在文本格式上，为了限制执行人员随意修改合同，一般要求采用电脑打印文本，手写的旁注和修改等不具有法律效力
合同的档案管理
工期索赔和费用索赔
按索赔的目的分类
合同规定的索赔和非合同规定的索赔
按索赔的依据分类
工程索赔和商务索赔
按索赔的业务性质分类
单向索赔和总索赔
按索赔的处理方式分类
必须以合同为依据
必须注意资料的积累
及时、合理地处理索赔
加强索赔的前瞻性
索赔原则
索赔的起因和原则
一般由监理工程师调解，若调解不成，由政府主管机构进行调解，若仍调解不成，由经济合同仲裁委员会进行调解或仲裁。
28天
提出理赔要求
总论部分、根据部分、计算部分和证据部分
索赔事件应该真实
责任分析应清楚、准确、有根据
充分论证事件给索赔方造成的实际损失
索赔计算必须合理、正确
文字要精炼，条理要清楚，语气要中肯
编写的一般要求
赔偿报告
报送索赔资料
监理工程师答复
视为该项索赔已经认可
监理工程师预期答复后果
持续索赔
仲裁与诉讼
索赔具体流程如下
合同索赔流程
主导语言原则
适用法律原则
特殊条件优先于一般条件
具体规定优先于笼统规定
手写条文优先于印刷条文
单价优先于总价
价格的文字表达优先于阿拉比数字表达
技术规范优先于图纸
整体解释原则
按不利于合同起草一方（一般为买方）的原则
公平诚信原则
合同解释原则
合同违规索赔管理
合同管理过程
16.6 项目合同管理
16 项目采购管理
识别干系人和引导干系人参与的过程需要迭代开展
项目进入其生命周期的不同阶段
当前干系人不在与项目工作有关，或者在项目的干系人群体中出现了新的干系人成员
组织内部或更大领域的干系人群体发生重大变化
至少要在以下时点开展
识别所有干系人，而非在限定范围内
确保所有团队成员都涉及引导干系人参与的活动
定期审查干系人群体，可与单个项目风险的审查工作并行开展
应用”共创“概念，咨询受项目工作或成果影响最大的干系人，视其为合作伙伴
关注干系人有效参与程度的正面与负面价值
17.1 管理基础
过程
干系人多样性
干系人关系的复杂性
频繁变化的项目更需要项目干系人的有效互动和参与
为了开展及时且高效的讨论并制定决策，适应型团队会直接与干系人互动，而不是通过层层的管理级别
客户、用户和开发人员在动态的共创过程中交换信息，干系人参与和满意程度更高
为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明
17.2 项目关系人管理过程
识别干系人管理过程通常在编制和批准项目章程之前或同时首次开展
识别干系人
在首次识别干系人时，项目管理计划并不存在
干系人参与计划
问卷和调查
头脑写作是头脑风暴的改良形式，让个人参与者有时间在小组创意讨论开始前单独思考问题
头脑风暴和头脑写作
会产生干系人清单和关于干系人的各种信息
兴趣
所有权
知识
贡献
干系人利害关系的组合
干系人分析
基于干系人的职权级别(权力)、对项目成果的关心程度(利益)、对项目成果的影响能力(影响)，或改变项目计划或执行的能力
权力利益方格、权利影响方格，或作用影响方格
将干系人视为一个多维实体，便于分析，从而有助于沟通策略的制定
方格模型的改良形式
干系人立方体
通过评估干系人的权力、紧迫性和合法性，对干系人进行分类
可以用邻近性取代合法性，以便考察干系人参与项目工作的程度
凸显模型
向上、向下、向外、横向
影响方向
优先级排序
数据表现（干系人映射分析和表现）
可用于在重要项目干系人之间达成谅解
引导式讨论会、指导式小组讨论、虚拟小组讨论
姓名、组织职位、地点、联系方式，以及在项目中扮演的角色
身份信息
主要需求、期望、影响项目成果的潜力，以及干系人最能影响或冲击的项目生命周期阶段
评估信息
用内部或外部，作用、影响、权力或利益，上级、下级、外围或横向，或者项目经理选择的其他分类模型进行分类的结果等
干系人分类
17.3 识别干系人
提供与干系人进行有效互动的可行计划
项目新阶段开始
组织结构或行业内部变化
新的个人或群体称为干系人，现有干系人不再是干系人群体的成员，或特定干系人对项目成功的重要性发生变化
当其他项目过程(如变更管理、风险管理或问题管理)的输出导致需要重新审查干系人参与策略等
该计划更新的主要情况
规划干系人参与
可能需要分析当前的假设条件和制约因素，以合理剪裁干系人参与策略
以便选择适当 策略来改进其参与水平
应该对干系人需求以及干系人本身进行优先级排序或分级
具有最大利益和最高影响的干系人，通常应该排在优先级清单的最前面。
优先级排序或分级
用于将干系人当前参与水平与期望参与水平进行比较
不了解型
抵制型
中立型
领导型
干系人参与水平可分为如下
该计划制订了干系人有效参与和执行项目决策的策略和行动
包括调动干系人个人或群体参与的特定策略或方法
17.4 规划干系人参与
尽可能提高干系人的支持度，并降低干系人的抵制程度
在适当的项目阶段引导干系人参与，以便获取、确认或维持他们对项目成功的持续承诺
通过谈判和沟通的方式管理干系人期望
处理与干系人管理有关的任何风险或潜在关注点，预测干系人可能在未来引发的问题
澄清和解决已识别的问题等
需要开展的活动
管理干系人参与
根据团队章程中定义的基本规则，明确项目团队成员和其他干系人引导干系人参与的行为
基本规则
17.5 管理干系人参与
维持或提升干系人参与活动的效率和效果
监督干系人参与
在干系人参与效果没有达到期望要求时，应该开展备选方案分析，评估应对偏差的各种备选方案
考察干系人成功参与项目的标准，并根据其优先级排序和加权，识别出最适当的选项
确定干系人群体和个人在项目任何特定时间的状态
通过投票选出应对干系人参与水平偏差的最佳方案
跟踪每个干系人参与水平的变化，对干系人参与加以监督。
用于确保发送给干系人的信息被接收和理解
为干系人提供清晰的信息
有助于理解组织战略，理解谁能行使权力和施加影响，以及培养与这些干系人沟通的能力
监督和评估干系人状态
回顾会
其他会议
17.6 监督干系人参与
17 干系人管理
系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性
变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等
软件、硬件和各种文档
项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号极其关键部件等
典型的配置项
所有的设计文档和源程序
向开发人员开放读取权限
基线配置项
项目的各类计划和报告
向项目经理、CCB及相关人员开放
非基线配置项
配置项分类
所有配置项的操作权限应由CMO(配置管理员)严格管理
配置项CI
草稿
正式
修改
配置项状态
0.YZ
X.Y
X.YZ
配置项版本号
配置标识、配置控制和配置审计、发布和交付
按照一定的规则保存配置项的所有版本
配置项版本管理
对基线的变更必须遵循正式的变更控制程序
基线通常对应于项目过程中的里程碑
交付给用户使用的基线
发行基线
内部过程使用的基线
构造基线
建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限
内容
配置基线
发布内容，包括每个配置项及其版本号
经批准变更可能影响到的配置项
与某个配置项有关的所有变更请求
与配置项有关的变更和问题
来自特定时期特定供应商的配置项
受问题影响的所有配置项
配置管理数据库
存放配置项并记录与配置项相关的所有信息
动态库、程序员库或工作库
开发库
主库
阶段工作结束时，当前的工作产品存入受控库
包含当前基线以及对基线的变更
受控库
最终的产品
已发布使用的各种基线的存档
静态库、发行库、软开仓库
产品库
类型
通用软件的开发组织
工作目录结构复杂
按配置项的类型分类建库
专业软件的开发组织
按开发任务建立相应的配置库
建库模式
配置库
管理基础
变更控制委员会（CCB）、配置管理负责人、配置管理员和配置项负责人
管理和决策配置活动
配置经理
管理所有活动，包括计划、识别、控制、审计和回顾
负责配置管理过程
审批结构性变更
定义配置项责任人
指派配置审计员
定义配置管理数据的范围、配置项属性、配置项之间关系和配置项状态
参与变更过程评估
对项目成员进行配置管理培训
负责
配置管理负责人
主要实施活动
建立和维护配置管理系统
建立和维护配置库或配置管理数据库
配置项识别
建立和管理基线
版本管理和配置控制
配置状态报告
配置审计
发布管理和交付
配置管理员
确保所负责的配置项准确和真实
记录所负责配置项的所有变更
维护配置项之间的关系
调查审计中发现的配置项差异，完成差异报告
遵从配置管理过程
参与配置管理过程评估
配置项负责人
目标与方针
配置管理的目标和范围
配置管理活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等
配置管理角色和责任安排
实施这些活动的规范和流程
实施这些活动的进度安排
与其他管理之间的接口控制
负责实施这些活动的人员或团队，以及他们和其他团队之间的关系
配置管理信息系统的规划
配置管理的日常事务
计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划
制订配置管理计划
确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等
确定配置项范围
确认和记录配置项属性
为配置项定义标识符
确定配置基准线
确定配置结构
确定配置项命名规则
对配置项和基线的变更控制
变更申请
变更对项目的影响
变更的内容是否必要
变更的范围是否考虑周全
变更单实施方案是否可行
变更的工作量估计是否合理
CCB负责对变更申请进行评估并确定
变更评估
通告评估结果
变更实施
变更验证与确认
变更的发布
基于配置库的变更
配置项控制
配置状态统计
每个受控配置项的标识和状态
每个变更申请的状态和已批准的修改的实施状态
每个基线的当前和过去版本的状态以及各版本的就比较
其他配置管理活动过程的记录等
配置审核或配置评价
防止向用户提交不适合的产品
发现不完善的实现
找出个配置项间不匹配或不相容的现象
确认配置项已在所要求的质量控制审核之后纳入基线并入库保存
确认记录和文档保持着可追溯性
确保项目配置管理的有效性
目的
配置项的开发已圆满完成
配置项已达到配置标识中规定的性能和功能特征
配置项的操作和支持文档已完成并且是符合要求的
一致性
功能配置审计
要交付的配置项是否存在
配置项中是否包含了所有必需的项目等
完整性
物理配置审计
实施新的配置库或配置管理数据库之后
对信息系统实施重大变更前后
在一项软件发布和安装被导入实际运作环境之前
灾难恢复之后或事件恢复正常之后
发现未经授权的配置向后
任何其他必要的时候
审计场景
根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息
对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议
对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况
根据会议结论，制定并提交服务改进计划
根据过程改进计划，协调、落实改进等
召开配置管理回顾会议
配置管理回顾与改进
管理活动
19.1 配置管理
不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值
实质
产品范围（成果）定义过失或疏忽
项目范围（工作）定义过失或疏忽
增值变更
应对风险的紧急计划或回避计划
项目执行过程与基准要求不一致带来的被动调整
外部事件
变更的常见原因
重大、重要、一般变更
通过不同的审批权限控制
变更性质
紧急、非紧急
通过不同变更处理流程进行
变更迫切性
根据行业特点分类
进度、成本、质量、设计、实施和工作（产品）范围变更等
领域和阶段
使得项目基准与项目实际执行情况相一致，应对项目变化
拒绝变化
调整项目基准
结果
变更管理是项目整体管理的一部分
变更管理与配置管理为相关联的两套机制
变更管理是配置管理的一部分
变更管理与配置管理的关系（2种观点）
项目基准化、变更管理过程规范化
基准是变更的依据
建立初始基准
变更通过评审后，都应重新确定基准
基准管理
变更控制流程化
至少应明确变更相关工作的评估、评审、执行的职能
明确组织分工
评估变更的可能影响
适当时可以引入配置管理工具
妥善保存变更产生的相关文档
管理原则
负责裁定接受那些变更
用户和实施方的决策人员
多方人员共同组成
CCB是决策机构，不是作业机构
通过评审手段来决定项目基准是否能变更，但不提出变更方案
项目控制委员会或配置控制委员会（CCB）
基准中不包括的储备资源需经授权人批准后方可使用
项目经理的正式权力由项目章程取得，而资源调度的权力通常由基准中明确。
响应变更提出者的需求；
评估变更对项目的影响及应对方案；
将需求由技术要求转化为资源需求，供授权人决策
并据评审结果实施（即调整基准），确保项目基准反映项目实施情况
项目经理在变更中的作用
变更经理
负责整个变更过程方案的结果
负责变更管理过程的监控
负责协调相关的资源，保障所有变更按照预定过程顺利运作
确定变更类型，组织变更计划和日程安排
管理变更的日程安排
变更实施完成之后的回顾和关闭
承担变更相关责任，并且具有相应权限
可能以主机审批形式或团队会议的形式参与变更的风险评估和审批
职责
变更管理负责人
记录与提交变更请求单
提交初步的变更方案和计划
初步评价变更的风险和影响，给变更请求设定适当的变更类型
对理解变更过程有能力要求
具体为
变更请求者
变更实施者
在紧急变更时，其中被授权者行使审批权限
定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等
对重大变更行使审批，提供专业意见和辅助审批
变更顾问委员会
正式方式提出，留下书面记录
变更的提出可以是各种形式，评估前应该以书面形式提出
项目的干系人都可以提出变更申请。项目经理或项目配置管理员可负责相关信息的收集和初审
1、提出与接受变更申请
对变更提出方施加影响，确认变更的必要性，确保变更是有价值的
格式校验，完整性校验，确保评估所需信息准备充分
在干系人间就提出评估的变更信息达成共识
常见方式为变更申请的文档的审核流转
2、对变更的初审
首先对变更请求是否可行实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求。以供CCB决策
评估需求如何转化为成果
技术评估
评估变更方面的经济与社会价值和潜在的风险
经济与社会效益评估
方案内容
3、变更方案论证
审查过程，是项目所有者根据变更申请及评估方案，决定是否变更项目基准
评审过程常包括客户、相关领域的专业人士等
审查通常采用文档、会签形式，重大变更审查可以包括正式会议形式
应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户的意见应该放在核心位置
项目管理委员会
4、变更审查
变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位
如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布
5、发出通知并实施
调整基准中设计变更的内容
调整过的基准设计变更的内容和整体基准是否反映项目实施情况
变更实施的过程监控，通常由项目经理负责基准的监控
管理人员会监控变更明确的主要成果、进度里程碑等，可以通过监理单位完成
6、实施监控
评估依据是项目的基准
结合变更的目标，评估变更所要达到的目的是否已达成
评估变更方案中的技术论证、经济论证内容与实施过程的差距并促使解决
7、效果评估
判断发生变更后的项目是否已纳入正常轨道
资源是否及时到位
8、变更收尾
变更流程（工作程序）
项目整体压力较大，强调变更的提出和处理应该规范化，可以使用分批处理、分优先级等方式提高效率
对变更产生的因素施加影响：防止不必要的变更，减少无谓的评估，提高必要变更的通过效率
对变更的确认应当正式化
变更的操作过程应当规范化
项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上可力求简便、高效
确保覆盖所有变更操作
某些情况下使用进度管理中的快速跟进等方法
变更申请的控制
变更过程的控制
变更控制
项目变更就必需做相应的版本发布，并制订相应的应急回退方案。为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案
为确保版本发布的成功，在版本发布前应对每次版本发布的风险做相应的评估，对版本发布的过程Check list做严格的评审。在评审发布内容时对存在风险的发布项做重点评估，确定相应的回退范围，制定相应的回退策略。为确保每次版本发布风险的可防可控，特准备回退方案。
回退分析
备份存储过程、函数等其他数据的存储及回退管理
备份配置数据，保罗数据备份的防护四
备份在线生产平台接口、应用、工作流等版本
启动回退机制的触发条件
对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点等
版本发布前的准备工作
通知相关用户系统开始回退
通知各关联系统进行版本回退
回退储存过程等数据对象
配置数据回退
应用程序、接口程序、工作流等版本回退
回退完成通知各周边关联系统
回退后进行相关测试，保证回退系统能够正常运行
通知用户回退完成
回退步骤
版本发布应急回退方案
版本发布和回退实施过程总结
版本发布和回退计划
19.2 变更管理
开发过程本身
可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明（包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等）
开发文档
开发过程的产物
培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告
产品文档
记录项目管理的信息
开发过程每个阶段的进度和进度变更的记录；软件变更的记录；开发团队职责定义、项目计划、项目阶段报告；配置管理计划
管理文档
信息系统开发项目的文档分类
开发工作量低于一个月的开发者自用程序
最低限度文档（1级文档）
没有与其他用户共享资源的专用程序
内部文档（2级文档）
由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
工作文档（3级文档）
正式发行供普遍使用的软件产品
正式文档（4级文档）
文档的质量分级
文档书写规范
图标编号规则
文档目录编写标准
文档管理制度
规则和方法
19.3 项目文档管理
19 配置与变更管理
0 条评论
回复 删除
下一页
