PMP考试2022

详解考纲新变化，学习笔记，备考指南，做到把书读薄；针对考试新题型，提供解题方法和解题思路。

PMP考试 2021

• 知识体系（旧）
  • 引论
    • PMBOK® 指南 的目的
    • 什么是项目
      • 项目组合、项目集和项目之间的关系
    • 什么是项目管理
    • 项目组合管理、项目集管理、项目管理和组织级项目管理之间 的关系
      • 项目集管理
      • 项目组合管理
      • 项目与战略规划
      • 项目管理办公室
    • 项目管理、运营管理与组织战略之间的关系
      • 运营与项目管理
        • 运营管理
        • 项目管理中的运营干系人
      • 组织与项目管理
        • 基于项目的组织
        • 项目管理和组织治理之间的联系
        • 项目管理和组织战略之间的关系
    • 商业价值
    • 项目经理的角色
      • 项目经理的责任与能力
      • 项目经理的人际技能
    • 项目管理知识体系
    • 讲义
      • 关于项目管理
        • 项目的定义
        • 企业的形态
          • 为客户做项目的企业
          • 自己内部做项目的企业
          • 企业内部工作也只有两种
            • 项目
            • 运营
        • 项目的特征
          • 企业管理的发展趋势
          • 战略管理
          • 项目产生的机制
      • 组织级项目管理
        • 项目集管理
        • 项目组合管理
        • 项目、项目集、项目组合管理的关系
  • 组织影响和项目生命周期
    • 组织对项目管理的影响
      • 组织文化与风格
      • 组织沟通
      • 组织结构
      • 组织过程资产
        • 流程与程序
        • 共享知识库
        • 项目档案
        • 项目或阶段收尾文件
        • 历史信息
      • 事业环境因素
        • 组织文化
        • 基础设施
        • 人事管理制度
        • 市场条件
    • 项目干系人与治理
      • 项目干系人
      • 项目治理
      • 项目成功
    • 项目团队
      • 项目团队的组成
    • 项目生命周期
      • 项目生命周期的特征
      • 项目阶段
        • 阶段与阶段的关系
        • 预测型生命周期
        • 迭代和增量型生命周期
        • 适应型生命周期（也称为变更驱动方法或敏捷方法）
  • 项目管理过程
    • 项目管理过程间的相互作用
    • 项目管理过程组
      • 启动过程组
      • 规划过程组
      • 执行过程组
      • 监控过程组
      • 收尾过程组
    • 项目信息
    • 10大知识领域
  • 项目整合管理
    • 制定项目章程
      • 制定项目章程：输入
        • 项目工作说明书
        • 商业论证
        • 协议
        • 事业环境因素
        • 组织过程资产
      • 制定项目章程：工具与技术
        • 专家判断
        • 引导技术
          • 头脑风暴
          • 冲突处理
          • 问题解决
          • 会议管理
      • 制定项目章程：输出
        • 项目章程
      • 指导与管理项目工作
    • 制定项目管理计划
      • 制定项目管理计划：输入
        • 项目章程
        • 其他过程的输出
        • 事业环境因素
        • 组织过程资产
      • 制定项目管理计划：工具与技术
        • 专家判断
        • 引导技术
      • 制定项目管理计划：输出
        • 项目管理计划
        • 项目管理计划与项目文件的区别
    • 指导与管理项目工作
      • 指导与管理项目工作：输入
        • 项目管理计划
        • 批准的变更请求
        • 事业环境因素
        • 组织过程资产
      • 指导与管理项目工作：工具与技术
        • 专家判断
        • 项目管理信息系统
        • 会议
          • 交换信息
          • 头脑风暴、方案评估或方案设计
          • 制定决策
        • 指导与管理项目工作：输出
          • 可交付成果
          • 工作绩效数据
          • 变更请求
          • 项目管理计划更新
          • 项目文件更新
    • 监控项目工作
      • 监控项目工作：输入
        • 项目管理计划
        • 进度预测
        • 成本预测
        • 确认的变更
        • 工作绩效信息
        • 事业环境因素
        • 组织过程资产
      • 监控项目工作：工具与技术
        • 专家判断
        • 分析技术
          • 回归分析
          • 分组方法
          • 因果分析
          • 根本原因分析
          • 预测方法（如时间序列、情景构建、模拟等）
          • 失效模式与影响分析（FMEA）
          • 故障树分析（FTA)
          • 储备分析
          • 趋势分析
          • 挣值管理
          • 差异分析
        • 项目管理信息系统
        • 会议
      • 监控项目工作：输出
        • 变更请求
          • 纠正措施
          • 预防措施
          • 缺陷补救
        • 工作绩效报告
        • 项目管理计划更新
        • 项目文件更新
    • 实施整体变更控制
      • 实施整体变更控制：输入
        • 项目管理计划
        • 工作绩效报告
        • 变更请求
        • 事业环境因素
        • 组织过程资产
      • 实施整体变更控制：工具与技术
        • 专家判断
        • 会议
        • 变更控制工具
      • 实施整体变更控制：输出
        • 批准的变更请求
        • 变更日志
        • 项目管理计划更新
        • 项目文件更新
    • 结束项目或阶段
      • 结束项目或阶段：输入
        • 项目管理计划
        • 验收的可交付成果
        • 组织过程资产
      • 结束项目或阶段：工具与技术
        • 专家判断
        • 分析技术
        • 会议
      • 结束项目或阶段：输出
        • 最终产品、服务或成果移交
        • 组织过程资产更新
  • 项目范围管理
    • 产品范围和项目范围
    • 规划范围管理
      • 规划范围管理：输入
        • 项目管理计划
        • 项目章程
        • 事业环境因素
        • 组织过程资产
      • 规划范围管理：工具与技术
        • 专家判断
        • 会议
      • 规划范围管理：输出
        • 范围管理计划
        • 需求管理计划
    • 收集需求
      • 需求
        • 业务需求
        • 干系人需求
        • 解决方案需求
          • 功能需求
          • 非功能需求
        • 过渡需求
        • 项目需求
        • 质量需求
      • 收集需求：输入
        • 范围管理计划
        • 需求管理计划
        • 干系人管理计划
        • 项目章程
        • 干系人登记册
      • 收集需求：工具与技术
        • 访谈
        • 焦点小组
        • 引导式研讨会
          • 联合应用设计/开发（JAD）
          • 质量功能展开（QFD）
          • QFD（客户声音）
          • 用户故事
        • 群体创新技术
          • 头脑风暴法
          • 名义小组技术
          • 概念/思维导图
          • 亲和图
          • 多标准决策分析
        • 群体决策技术
          • 一致同意
          • 大多数原则
          • 相对多数原则
          • 独裁
        • 问卷调查
        • 观察
        • 原型法
        • 标杆对照
        • 系统交互图
        • 文件分析
      • 收集需求：输出
        • 需求文件
        • 需求跟踪矩阵
    • 定义范围
      • 定义范围：输入
        • 范围管理计划
        • 项目章程
        • 需求文件
        • 组织过程资产
      • 定义范围：工具与技术
        • 专家判断
        • 产品分析
          • 产品分解
          • 系统分析
          • 需求分析
          • 系统工程
          • 价值工程
          • 价值分析
        • 备选方案生成
        • 引导式研讨会
      • 定义范围：输出
        • 项目范围说明书
          • 产品范围描述
          • 验收标准
          • 可交付成果
          • 项目的除外责任
          • 制约因素
          • 假设条件
        • 项目文件更新
    • 创建 WBS
      • 创建 WBS：输入
        • 范围管理计划
        • 项目范围说明书
        • 需求文件
        • 事业环境因素
        • 组织过程资产
      • 创建 WBS：工具与技术
        • 分解
        • 专家判断
      • 创建 WBS：输出
        • 范围基准
          • 项目范围说明书
          • WBS
          • WBS 词典
        • 项目文件更新
    • 确认范围
      • 确认范围：输入
        • 项目管理计划
        • 需求文件
        • 需求跟踪矩阵
        • 核实的可交付成果
        • 工作绩效数据
      • 确认范围：工具与技术
        • 检查
        • 群体决策技术
      • 确认范围：输出
        • 验收的可交付成果
        • 变更请求
        • 工作绩效信息
        • 项目文件更新
      • 控制范围
        • 控制范围：输入
          • 项目管理计划
          • 需求文件
          • 需求跟踪矩阵
          • 工作绩效数据
          • 组织过程资产
        • 控制范围：工具与技术
          • 偏差分析
        • 控制范围：输出
          • 工作绩效信息
          • 变更请求
          • 项目管理计划更新
          • 项目文件更新
          • 组织过程资产更新
      • 项目时间管理
        • 规划进度管理
          • 规划进度管理：输入
            • 项目管理计划
            • 项目章程
            • 事业环境因素
            • 组织过程资产
          • 规划进度管理：工具与技术
            • 专家判断
            • 分析技术
            • 会议
          • 规划进度管理：输出
            • 进度管理计划
            • 定义活动
        • 定义活动：输入
          • 进度管理计划
          • 范围基准
          • 事业环境因素
          • 组织过程资产
        • 定义活动：工具与技术
          • 分解
          • 滚动式规划
          • 专家判断
        • 定义活动：输出
          • 活动清单
          • 活动属性
          • 里程碑清单
        • 排列活动顺序
          • 排列活动顺序：输入
            • 进度管理计划
            • 活动清单
            • 活动属性
            • 里程碑清单
            • 项目范围说明书
            • 事业环境因素
            • 组织过程资产
          • 排列活动顺序：工具与技术
            • 紧前关系绘图法
            • 确定依赖关系
            • 提前量和滞后量
          • 排列活动顺利：输出
            • 项目进度网络图
            • 项目文件更新
        • 估算活动资源
          • 估算活动资源：输入
            • 进度管理计划
            • 活动清单
            • 活动属性
            • 资源日历
            • 风险登记册
            • 活动成本估算
            • 事业环境因素
            • 组织过程资产
          • 估算活动资源：工具与技术
            • 专家判断
            • 备选方案分析
            • 发布的估算数据
            • 自下而上估算
            • 项目管理软件
          • 估算活动资源：输出
            • 活动资源需求
            • 资源分解结构
            • 项目文件更新
        • 估算活动持续时间
          • 估算活动持续时间：输入
            • 进度管理计划
            • 活动清单
            • 活动属性
            • 活动资源需求
            • 资源日历
            • 项目范围说明书
            • 风险登记册
            • 资源分解结构
            • 事业环境因素
            • 组织过程资产
          • 估算活动持续时间：工具与技术
            • 专家判断
            • 类比估算
            • 参数估算
            • 三点估算
              • 最可能时间
              • 最乐观时间
              • 最悲观时间
              • 三角分布
              • 贝塔分布
            • 群体决策技术
            • 储备分析
          • 估算活动持续时间：输出
            • 活动持续时间估算
            • 项目文件更新
        • 制定进度计划
          • 制定进度计划：输入
            • 进度管理计划
            • 活动清单
            • 活动属性
            • 项目进度网络图
            • 活动资源需求
            • 资源日历
            • 活动持续时间估算
            • 项目范围说明书
            • 风险登记册
            • 项目人员分派
            • 资源分解结构
            • 事业环境因素
            • 组织过程资产
          • 制定进度计划：工具与技术
            • 进度网络分析
            • 关键路径法
            • 关键链法
            • 资源优化技术
            • 建模技术
              • 假设情景分析
              • 模拟
            • 提前量和滞后量
            • 进度压缩
              • 赶工
              • 快速跟进
            • 进度计划编制工具
          • 制定进度计划：输出
            • 进度基准
            • 项目进度计划
              • 横道图
              • 里程碑图
              • 项目进度网络图
            • 进度数据
            • 项目日历
            • 项目管理计划更新
            • 项目文件更新
        • 控制进度
          • 控制进度：输入
            • 项目管理计划
            • 项目进度计划
            • 工作绩效数据
            • 项目日历
            • 进度数据
            • 组织过程资产
          • 控制进度：工具与技术
            • 绩效审查
              • 趋势分析
              • 关键路径法
              • 关键链法
              • 挣值管理
            • 项目管理软件
            • 资源优化技术
            • 建模技术
            • 提前量和滞后量
            • 进度压缩
            • 进度计划编制工具
          • 控制进度：输出
            • 工作绩效信息
            • 进度预测
            • 变更请求
            • 项目管理计划更新
            • 项目文件更新
            • 组织过程资产更新
      • 项目成本管理
  • 项目成本管理
    • 规划成本管理
      • 规划成本管理：输入
        • 项目管理计划
        • 项目章程
        • 事业环境因素
        • 组织过程资产
      • 规划成本管理：工具与技术
        • 专家判断
        • 分析技术
        • 会议
      • 规划成本管理：输出
        • 成本管理计划
    • 估算成本
      • 估算成本：输入
        • 成本管理计划
        • 人力资源管理计划
        • 范围基准
        • 项目进度计划
        • 风险登记册
        • 事业环境因素
        • 组织过程资产
      • 估算成本：工具与技术
        • 专家判断
        • 类比估算
        • 参数估算
        • 自下而上估算
        • 三点估算
        • 储备分析
        • 质量成本（COQ）
        • 项目管理软件
        • 卖方投标分析
        • 群体决策技术
      • 估算成本：输出
        • 活动成本估算
        • 估算依据
        • 项目文件更新
    • 制定预算
      • 制定预算：输入
        • 成本管理计划
        • 范围基准
        • 活动成本估算
        • 估算依据
        • 项目进度计划
        • 资源日历
        • 风险登记册
        • 协议
        • 组织过程资产
      • 制定预算：工具与技术
        • 成本汇总
        • 储备分析
        • 专家判断
        • 历史关系
        • 资金限制平衡
      • 制定预算：输出
        • 成本基准
        • 项目资金需求
        • 项目文件更新
    • 控制成本
      • 控制成本：输入
        • 项目管理计划
        • 项目资金需求
        • 工作绩效数据
        • 组织过程资产
      • 控制成本：工具与技术
        • 挣值管理
          • 计划价值
          • 挣值
          • 实际成本
          • 进度偏差
          • 成本偏差
          • 进度绩效指数
          • 成本绩效指数
        • 预测
          • 假设将按预算单价完成 ETC 工作
          • 假设以当前 CPI 完成 ETC 工作
          • 假设 SPI 与 CPI 将同时影响 ETC 工作
        • 完工尚需绩效指数（TCPI）
        • 绩效审查
          • 偏差分析
          • 趋势分析
          • 挣值绩效
        • 项目管理软件
        • 储备分析
      • 控制成本：输出
        • 工作绩效信息
        • 成本预测
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
  • 项目质量管理
    • 规划质量管理
      • 规划质量管理：输入
        • 项目管理计划
        • 干系人登记册
        • 风险登记册
        • 需求文件
        • 事业环境因素
        • 组织过程资产
      • 规划质量管理：工具与技术
        • 成本效益分析
        • 质量成本（COQ）
        • 七种基本质量工具
          • 因果图
          • 流程图
          • 核查表
          • 帕累托图
          • 直方图
          • 控制图
          • 散点图
        • 标杆对照
        • 实验设计
        • 统计抽样
        • 其它质量管理工具
          • 头脑风暴
          • 力场分析
          • 名义小组技术
          • 质量管理和控制工具
        • 会议
      • 规划质量管理：输出
        • 质量管理计划
        • 过程改进计划
        • 质量测量指标
        • 质量核对单
        • 项目文件更新
    • 实施质量保证
      • 实施质量保证：输入
        • 质量管理计划
        • 过程改进计划
        • 质量测量指标
        • 质量控制测量结果
        • 项目文件
      • 实施质量保证：工具与技术
        • 质量管理和控制工具
          • 亲和图
          • 过程决策程序图（PDPC）
          • 关联图
          • 树形图
          • 优先矩阵
          • 活动网络图
          • 矩阵图
        • 质量审计
        • 过程分析
      • 实施质量保证：输出
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
    • 控制质量
      • 控制质量：输入
        • 项目管理计划
        • 质量测量指标
        • 质量核对单
        • 工作绩效数据
        • 批准的变更请求
        • 可交付成果
        • 项目文件
        • 组织过程资产
      • 控制质量：工具与技术
        • 七种基本质量工具
        • 统计抽样
        • 检查
        • 审查已批准的变更请求
      • 控制质量：输出
        • 质量控制测量结果
        • 确认的变更
        • 核实的可交付成果
        • 工作绩效信息
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
  • 项目人力资源管理
    • 规划人力资源管理
      • 规划人力资源管理：输入
        • 项目管理计划
        • 活动资源需求
        • 事业环境因素
        • 组织过程资产
      • 规划人力资源管理：工具与技术
        • 组织图和职位描述
          • 层级型
          • 矩阵型
          • 文本型
        • 人际交往
        • 组织理论
        • 专家判断
        • 会议
      • 规划人力资源管理：输出
        • 人力资源管理计划
          • 角色和职责
          • 项目组织图
          • 人员配备管理计划
    • 组建项目团队
      • 组建项目团队：输入
        • 人力资源管理计划
        • 事业环境因素
        • 组织过程资产
      • 组建项目团队：工具与技术
        • 预分派
        • 谈判
        • 招募
        • 虚拟团队
        • 多标准决策分析
      • 组建项目团队：输出
        • 项目人员分派
        • 资源日历
        • 项目管理计划更新
    • 建设项目团队
      • 建设项目团队：输入
        • 人力资源管理计划
        • 项目人员分派
        • 资源日历
      • 建设项目团队：工具与技术
        • 人际关系技能
        • 培训
        • 团队建设活动
          • 塔克曼阶梯理论
            • 形成阶段
            • 震荡阶段
            • 规范阶段
            • 成熟阶段
            • 解散阶段
          • 基本规则
          • 集中办公
          • 认可与奖励
          • 人事测评工具
      • 建设项目团队：输出
        • 团队绩效评价
        • 事业环境因素更新
    • 管理项目团队
      • 管理项目团队：输入
        • 人力资源管理计划
        • 项目人员分派
        • 团队绩效评价
        • 问题日志
        • 工作绩效报告
        • 组织过程资产
      • 管理项目团队：工具与技术
        • 观察和交谈
        • 项目绩效评估
        • 冲突管理
          • 撤退/回避
          • 缓和/包容
          • 妥协/调解
          • 强迫/命令
          • 合作/解决问题
        • 人际关系技能
          • 领导力
          • 影响力
          • 有效决策
        • 管理项目团队：输出
          • 变更请求
          • 项目管理计划更新
          • 项目文件更新
          • 事业环境因素更新
          • 组织过程资产更新
  • 项目沟通管理
    • 规划沟通管理
      • 规划沟通管理：输入
        • 项目管理计划
        • 干系人登记册
        • 事业环境因素
        • 组织过程资产
      • 规划沟通管理：工具与技术
        • 沟通需求分析
        • 沟通技术
        • 沟通模型
        • 沟通方法
          • 交互式沟通
          • 推式沟通
          • 拉式沟通
        • 会议
      • 规划沟通管理：输出
        • 沟通管理计划
        • 项目文件更新
    • 管理沟通
      • 管理沟通：输入
        • 沟通管理计划
        • 工作绩效报告
        • 事业环境因素
        • 组织过程资产
      • 管理沟通：工具与技术
        • 沟通技术
        • 沟通模型
        • 沟通方法
        • 信息管理系统
        • 报告绩效
      • 管理沟通：输出
        • 项目沟通
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
    • 控制沟通
      • 控制沟通：输入
        • 项目管理计划
        • 项目沟通
        • 问题日志
        • 工作绩效数据
        • 组织过程资产
      • 控制沟通：工具与技术
        • 信息管理系统
        • 专家判断
        • 会议
      • 控制沟通：输出
        • 工作绩效信息
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
  • 项目风险管理
    • 规划风险管理
      • 规划风险管理：输入
        • 项目管理计划
        • 项目章程
        • 干系人登记册
        • 事业环境因素
        • 组织过程资产
      • 规划风险管理：工具与技术
        • 分析技术
        • 专家判断
        • 会议
      • 规划风险管理：输出
        • 风险管理计划
          • 风险分解结构（RBS）
          • 风险概率和影响的定义
    • 识别风险
      • 识别风险：输入
        • 风险管理计划
        • 成本管理计划
        • 进度管理计划
        • 质量管理计划
        • 人力资源管理计划
        • 范围基准
        • 活动成本估算
        • 活动持续时间估算
        • 干系人登记册
        • 项目文件
        • 采购文件
        • 事业环境因素
        • 组织过程资产
      • 识别风险：工具与技术
        • 文档审查
        • 信息收集技术
          • 头脑风暴
          • 德尔菲技术
          • 访谈
          • 根本原因分析
        • 核对单分析
        • 假设分析
        • 图解技术
          • 因果图
          • 系统或过程流程图
          • 影响图
        • SWOT 分析
        • 专家判断
      • 识别风险：输出
        • 风险登记册
          • 已识别风险清单
          • 潜在应对措施清单
    • 实施定性风险分析
      • 实施定性风险分析：输入
        • 风险管理计划
        • 范围基准
        • 风险登记册
        • 事业环境因素
        • 组织过程资产
      • 实施定性风险分析：工具与技术
        • 风险概率和影响评估
        • 概率和影响矩阵
        • 风险数据质量评估
        • 风险分类
        • 风险紧迫性评估
        • 专家判断
      • 实施定性风险分析：输出
        • 项目文件更新
    • 实施定量风险分析
      • 实施定量风险分析：输入
        • 风险管理计划
        • 成本管理计划
        • 进度管理计划
        • 风险登记册
        • 事业环境因素
        • 组织过程资产
      • 实施定量风险分析：工具与技术
        • 数据收集和展示技术
          • 访谈
          • 概率分布
        • 定量风险分析和建模技术
          • 敏感性分析
          • 预期货币价值分析
          • 建模和模拟
          • 专家判断
        • 实施定量风险分析：输出
          • 项目文件更新
    • 规划风险应对
      • 规划风险应对：输入
        • 风险管理计划
        • 风险登记册
      • 规划风险应对：工具与技术
        • 消极风险或威胁的应对策略
          • 规避
          • 转移
          • 减轻
          • 接受
        • 积极风险或机会的应对策略
          • 开拓
          • 提高
          • 分享
          • 接受
        • 应急应对策略
        • 专家判断
      • 规划风险应对：输出
        • 项目管理计划更新
        • 项目文件更新
    • 控制风险
      • 控制风险：输入
        • 项目管理计划
        • 风险登记册
        • 工作绩效数据
        • 工作绩效报告
      • 控制风险：工具与技术
        • 风险再评估
        • 风险审计
        • 偏差和趋势分析
        • 技术绩效测量
        • 储备分析
        • 会议
      • 控制风险：输出
        • 工作绩效信息
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
  • 项目采购管理
    • 规划采购管理
      • 规划采购管理：输入
        • 项目管理计划
        • 需求文件
        • 风险登记册
        • 活动资源需求
        • 项目进度计划
        • 活动成本估算
        • 干系人登记册
        • 事业环境因素
        • 组织过程资产
          • 合同
            • 总价合同
              • 固定总价合同（FFP）
              • 总价加激励费用合同（FPIF）
              • 总价加经济价格调整合同（FP—EPA）
            • 成本补偿合同
              • 成本加固定费用合同（CPFF）
              • 成本加激励费用合同（CPIF）
              • 成本加奖励费用合同（CPAF）
            • 工料合同（T&M）
      • 规划采购管理：工具与技术
        • 自制或外购分析
        • 专家判断
        • 市场调研
        • 会议
      • 规划采购管理：输出
        • 采购管理计划
        • 采购工作说明书
        • 采购文件
        • 供方选择标准
        • 自制或外购决策
        • 变更请求
        • 项目文件更新
    • 实施采购
      • 实施采购：输入
        • 采购管理计划
        • 采购文件
        • 供方选择标准
        • 卖方建议书
        • 项目文件
        • 自制或外购决策
        • 采购工作说明书
        • 组织过程资产
      • 实施采购：工具与技术
        • 投标人会议
        • 建议书评价技术
        • 独立估算
        • 专家判断
        • 广告
        • 分析技术
        • 采购谈判
      • 实施采购：输出
        • 选定的卖方
        • 协议
        • 资源日历
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
    • 控制采购
      • 控制采购：输入
        • 项目管理计划
        • 采购文件
        • 协议
        • 批准的变更请求
        • 工作绩效报告
        • 工作绩效数据
      • 控制采购：工具与技术
        • 合同变更控制系统
        • 采购绩效审查
        • 检查与审计
        • 报告绩效
        • 支付系统
        • 索赔管理
        • 记录管理系统
      • 控制采购：输出
        • 工作绩效信息
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
    • 结束采购
      • 结束采购：输入
        • 项目管理计划
        • 采购文件
      • 结束采购：工具与技术
        • 采购审计
        • 采购谈判
        • 记录管理系统
      • 结束采购：输出
        • 结束的采购
        • 组织过程资产更新
  • 项目干系人管理
    • 识别干系人
      • 识别干系人：输入
        • 项目章程
        • 采购文件
        • 事业环境因素
        • 组织过程资产
      • 识别干系人：工具与技术
        • 干系人分析
          • 权力/利益方格
          • 权力/影响方格
          • 影响/作用方格
          • 凸显模型
        • 专家判断
          • 会议
      • 识别干系人：输出
        • 干系人登记册
    • 规划干系人管理
      • 规划干系人管理：输入
        • 项目管理计划
        • 干系人登记册
        • 事业环境因素
        • 组织过程资产
      • 规划干系人管理：工具与技术
        • 专家判断
        • 会议
        • 分析技术
          • 不知晓
          • 抵制
          • 中立
          • 支持
          • 领导
        • 规划干系人管理：输出
          • 干系人管理计划
          • 项目文件更新
    • 管理干系人参与
      • 管理干系人参与：输入
        • 干系人管理计划
        • 沟通管理计划
        • 变更日志
        • 组织过程资产
      • 管理干系人参与：工具与技术
        • 沟通方法
        • 人际关系技能
        • 管理技能
      • 管理干系人参与：输出
        • 问题日志
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
    • 控制干系人参与
      • 控制干系人参与：输入
      • 项目管理计划
        • 问题日志
        • 工作绩效数据
        • 项目文件
      • 控制干系人参与：工具与技术
        • 信息管理系统
        • 专家判断
        • 会议
      • 控制干系人参与：输出
        • 工作绩效信息
        • 变更请求
        • 项目管理计划更新
        • 项目文件更新
        • 组织过程资产更新
• 22年新考纲变化
  • 考纲变化，教材不变：知识点不变，分类方法和考察侧重做了调整
    • 调整1：五变三
    • 调整2：侧重与人交流的部分
    • 调整3：重点考察敏捷的内容
  • 第六版教材新大纲要点解读
    • 第1章 引论
      • 1.1 项目管理知识体系
        • 1.1.1 概述
          • 项目管理知识体系（Project Managment Body of Knuwledge,PMBOK）是项目管理领域（职业和学科）全部知识的综合
          • PMBOK是项目管理职业和学科的基础
        • 1.1.2 《PMBOK指南》
          • 《PMBOK指南》是PMI发布的一份全球性的项目管理知识体系文件。它起源于PMI在1981年至1983年所做的“道德、标准和认证”研究项目。在1996年正是出第1版。概括项目管理知识体系中被普遍公认为良好做法的那一部分内容
          • 在学习和应用《PMBOK指南》时，需要注意：
            • 运用到具体项目时，还需要掌握该项目所在领域的独特知识
            • 只针对单个项目管理。而不是项目集或项目组合的管理
            • 没有收录哪些通用的、非专门用于管理项目的知识
            • 没有收录那些只适用于某类特别项目的项目管理知识
            • 没有收录那些尚不成熟的项目管理做法
        • 1.1.3 《PMBOK®指南》第6版
          • 可以把《PMBOK®指南》的主要内容概述为：在项目管理基本概念的支持下，项目管理的五大过程组与十大知识领域之间形成纵横交叉的严密控制网，来实现对项目中的关键节点的控制，极大地提高项目成功的可能性
        • 1.1.4 《PMBOK®指南》的作用
          • 用于指导项目管理实践，使项目管理知识广泛共享，避免因“重复发明轮子”而浪费时间和精力
          • 对促进全球项目管理资格认证、培训和教育的发展，都起到了极其重要的作用
          • 对促进项目管理基本术语的科学化、规范化与统一化起到了重要作用，有助于人们就项目管理主题进行交流，降低沟通成本
        • 1.1.5 PMP®考试大纲
          • 总共200道考题中所占的题目比例：人员部分42%，过程部分50%，商业环境部分8%
          • 由于《PMP®考试大纲》写得很粗略，考生即便认真阅读，也不一定能读出多少内涵。所以，考生没有必要专门阅读
      • 1.2 战略目标、项目和运营
        • 1.2.1 战略目标及其实现手段
          • 组织需要通过做项目来创造有利于分项和总体战略目标实现的条件。然后，在日常运营中，持续有效地使用这些条件，获取收益，从而实现分项和总体战略目标。项目和运营都是实现战略目标的手段
          • 战略目标、项目和运营之间的关系
        • 1.2.2 项目组合与项目集
          • 项目组合是为实现战略目标而被集中管理的一些项目。项目组合通常并非一成不变，需要定期审查、删减、补充。根据优先顺利分配资源。
          • 项目集是相互关联并被协调管理的一组项目，也就是通常所说的一系列配套项目。项目集是为了抓住项目之间的横向联系来协调管理，以便获得各项目分别管理所不能获得的更大效益。
          • 项目组合与项目集的区别
        • 1.2.3 项目与子项目
          • 项目是为创造独特的产品、服务或成果而进行的临时性工作。具有临时性、独特性和成果导向性
          • 项目经常可以被划分成一些子项目，有利于管理。项目与子项目的概念是相对的
          • 在项目或子项目内部，又有可交付成果、工作包、进度活动等概念
            • 工作包是项目中最小的可交付成果
            • 进度活动则是为完成工作包而必须开展的具体活动
          • 相关概念的层次结构
        • 1.2.4 项目与运营
          • 组织所做的工作可以分为两类：项目与运营。它们有许多共同之处：都由人来做，都受制于有限的资源，都要被规划、执行与监控，都要为组织的经营和战略目标服务
          • 项目与运营的主要区别在于：
            • 项目是临时的，而运营是持续不断的。
            • 项目是要创造独特的可交付成果，而运营是要产出同样的结果
            • 项目可交付成果的开发过程是渐进明细的，而运营是在标准化的生产线上或根据标准化的服务流程开展的
          • 在实际工作中，持续性的运营往往可以被划分为许多临时性的项目
          • 在组织中，运营与项目相互支持、相互协调，共同为实现组织的经营目标和战略目标服务
      • 1.3 项目的特点
        • 1.3.1 项目的普遍性
          • 项目是为组织的经营需要与战略目标服务的。组织中会存在不同层级的项目，其规模、复杂程度可能相差很大。任何一个需要在特定时间内解决的问题都是项目
          • PMP®考试题目中的“项目”，一般都是中等以上规模且跨专业、跨部门的项目，而不是很小的单专业项目
        • 1.3.2 项目的临时性
          • 临时性，是指项目有明确的开始时间和明确的结束时间
          • 项目无论何因何时结束，都必须经过既定的批准程序
          • 项目的临时性决定了项目团队的临时性
          • 临时性的项目所创造的产品、服务或成果，具有可持续的长期生命力
        • 1.3.3 项目的独特性
          • 独特性，也叫“一次性”，只做一次的事肯定是独特的
          • 把工作当项目来做，就必须看重其独特性，做出特色
        • 1.3.4 项目的成果导向性
          • 项目所要创造的产品、服务或成果，可以统称为“可交付成果”（Deliverable）
          • 必须坚持以可交付成果为导向，做出符合要求的成果，防止只有苦劳而没有功劳
        • 1.3.5 项目的渐进明细性
          • 项目具有渐进明细性，即应该在连续积累中分步骤开发，以便逐步明确项目的细节特征
          • 项目的特点应该随着时间的推移、情况的明朗和信息的增加而逐渐细化出来
          • 渐进明细必须在确定的项目范围边界之内进行，不能“溜出”项目边界
      • 1.4 战略管理、项目管理和运营管理
        • 1.4.1 战略管理与项目组合管理
          • 战略管理旨在确定组织的长远发展方向和战略目标
          • 项目组合管理是要排列所有备选项目的优先顺序，并选择一系列排序靠前的、最有利于实现战略目标的项目（正确的项目）来做。项目组合管理的出发点是组织的战略目标和资源限制。项目组合管理其实是进行投资决策。项目组合经理往往由组织中的高级管理人员（如副总裁）兼任
        • 1.4.2 项目集管理
          • 项目集管理是要正确地完成一系列相互关联的项目。它通过管理项目之间的内在联系，取得每个项目单独管理所不能取得的效益。平等看待同一项目集中的所有项目，重点管理项目之间的相互联系，通过它们之间的有效配合来取得更大的效益
          • 项目集管理旨在正确地完成一系列相互配套的项目，获得更大的效益
        • 1.4.3 项目管理与运营管理
          • 项目管理旨在正确地完成单个项目
          • 运营管理是确保持续且有效地应用项目或项目集所产出的生产能力或服务能力
        • 战略管理、项目组合管理、项目集管理、项目管理与运营管理的主要区别
        • 1.4.4 组织级项目管理
          • 组织级项目管理是组织中的项目、项目集和项目组合管理做法，以及有利于这些做法的推行的各种因素的总和
      • 1.5 项目管理的基本内容
        • 1.5.1 项目目标
          • 从狭义上讲，做项目就是要在规定的范围、进度、成本和质量要求之下完成项目可交付成果。项目范围、进度、成本和质量，是用于规定项目目标的四个必不可少的维度，缺一不可
          • 从广义上讲，做项目就是要满足项目相关方在项目上的利益追求
          • 三重制约
        • 1.5.2 项目目标各维度的优先顺序
          • 项目的范围、进度、成本和质量这四个维度紧密相连，既相互依存又相互竞争
          • 在具体的项目上，必须排列各维度的优先顺序，牺牲排序靠后的维度来保全排序靠前的维度
          • 在某个具体项目上，它们的优先顺序通常由高级管理层而不是项目经理决定。项目经理需要在项目规划和执行过程中贯彻高级管理层所决定的优先顺序
          • 不同的项目相关方可能对哪个维度更重要有不同意见，从而增加管理项目的难度
          • 如果项目产品是为某个外在事件（如奥运会开幕）服务的，且该外在事件的开始时间无法更改，那么“进度”往往是最重要的维度
          • 笼统地讲，项目的范围、进度、成本和质量等分目标没有优先顺序；在具体项目上的优先顺序由高级管理层决定
        • 1.5.3 项目目的
          • 项目目标是指要做出怎样的项目可交付成果（符合范围、进度、成本和质量要求），而项目目的是指为什么要做出这样的项目可交付成果（这个成果能够带来什么效益）
          • 《PMBOK®指南》指出，项目应该具有驱动组织变革和为组织创造商业价值的特性。这两条其实就是项目目的，即组织做项目的根本原因
          • 项目经理应该从组织变革管理的高度来做项目，把项目看成变革型项目，即实现组织变革的手段
          • 《PMBOK®指南》中，除非特别说明，项目都是组织内部的，而非为外部客户而做的
          • “效益（benefit）”和“价值（value）”经常同义。如果要区分，那就是效益-成本=价值，其中成本是为获得效益所付出的代价
        • 1.5.4 项目管理的实现过程
          • 项目管理是通过整合开展49个基本的项目管理过程来实现的
          • 管理一个项目，就需要应用合适的项目管理过程，做好以下工作：
            • 与项目主要相关方沟通，识别他们的项目需求
            • 分析相关方的项目需求，了解项目需求之间的一致性、协调性和矛盾性
            • 权衡相互竞争（矛盾）的项目需求，寻找最佳平衡点
            • 建立具体、明确且现实可行的项目目标
            • 把项目目标转化为具体的实施计划，组建项目团队具体实施
            • 对项目进展情况进行动态监督与控制，及时纠正偏差，保证项目顺利实施
            • 对项目阶段或整个项目进行正式收尾工作，结束阶段或整个项目
          • 在整合管理的指导之下：
            • （1）规划该做什么（范围管理）
            • （2）规划该在什么时候做（进度管理）
            • （3）规划该用多大成本做（成本管理）
            • （4）规划该做到什么质量要求（质量管理）
            • （5）把以上步骤得到的范围、进度、成本和质量计划整合成初步的项目目标计划
            • （6）针对初步的项目目标计划，识别和分析项目风险（风险管理）
            • （7）根据风险分析结果，调整初步的项目目标计划，得到确定的项目目标计划
            • （8）安排所需资源（特别是人力资源）去执行确定的项目目标计划。先使用组织内部已有的资源（资源管理），再通过采购获取组织缺少的资源（采购管理）
            • （9）始终保持与组织内外部项目工作人员密切沟通（沟通管理）
            • （10）通过积极与各种相关方打交道，来提升相关方对项目的支持，削弱相关方对项目的抵制，促进项目成功（相关方管理）
          • 项目管理十大知识领域的关系
          • 要有效地管理项目，还要掌握：
            • 应用领域的知识、标准与法规
            • 对项目环境的理解
            • 通用的管理知识
            • 人际关系技能
    • 第2章 项目运行环境与项目经理
      • 2.1 项目执行组织
        • 《PMBOK®指南》和PMP®考试中的“项目”，都是在一个或几个组织中开展的。这个或这些组织就是“项目执行组织”，也就是平常所说的“项目所在单位”
        • 2.1.1 组织作为一个系统
          • 系统是由一系列相互关联的组件所构成的复杂整体。在一个有效的系统中，系统整体的功能要远大于各组件的功能之和。系统可以分成：自然系统与人造系统，静态系统与动态系统，封闭系统与开放系统。毫无疑问，组织是一个开放且动态的人造系统
          • 组织的开放性是指组织会与环境互动。组织既要从环境获取各种输入，又会向环境输出所生成的各种成果
          • 组织中的高级管理层负责组织系统建设，以便主要用系统而不是靠个人去管人管事。系统由三个要素构成：组件、组件属性以及组件关系
          • 《PMBOK®指南》中重点讨论了组织系统的三大决定因素：组织治理框架、管理要素（原则）和组织结构
        • 2.1.2 组织治理与项目治理
          • 组织治理框架是组织中的重要决策制定框架，即在组织中，谁有权在什么时候用什么方法做出并推行什么重要决策，如董事长、总经理、财务总监、PMO主任分别有权做出什么决策
          • 以下四条是最重要的决策规则：
            • （1）关于如何处理公司与股东及其他相关方的权责利关系的规则
            • （2）关于如何协调各相关方的利益矛盾的规则
            • （3）关于董事会如何代表各相关方对公司业务进行监督和控制的规则
            • （4）关于公司如何向各相关方发布业务信息的规则
          • 公司董事会做公司治理，公司总经理做公司管理。项目治理是组织为项目建立的高级别的指导、支持、监督与控制框架。项目治理是联系组织治理与项目管理的桥梁
          • 项目治理与组织治理、项目管理的关系
          • 项目经理在接手某个项目之前，必须了解有关的项目治理框架，争取更好的保障。
        • 2.1.3 基本的管理要素
        • 2.1.4 组织结构的主要类型
          • 有机型或简约型
          • 职能型
          • 事业部型
          • 矩阵型（包括弱矩阵型、平衡矩阵型和强矩阵型）
          • 项目型
          • 虚拟型
          • 混合型
          • 项目管理办公室（PMO）型
          • PMP®考试中可能出现的“紧密型矩阵”，并不是一种特别的矩阵型组织结构，而是指矩阵型组织结构之下的项目成员集中办公
        • 2.1.5 组织结构对项目的影响
          • 职能通常是：把某个项目放到现有的某个职能部门内部去做
          • 矩阵型通常是：为某个项目组建专门的项目部，其中部分员工全职做项目，部分员工兼职做项目（仍兼做各职能部门的工作）
          • 项目型通常是：为某个项目组建专门的项目部，其全部员工都全职做项目
          • 常用的项目组织结构
          • 不同组织形式的主要区别
          • 矩阵型组织最常用。它能够同时利用职能型组织和项目型组织的优点。其主要特点是：
            • ①借资源，即许多项目团队成员是从职能部门借来的（可能只是在项目上兼职）
            • ②两个老板，即项目团队成员需要同时接受项目经理和职能经理的领导
            • 这两个特点决定了矩阵型组织中的项目经理并没有管理项目的全权
        • 2.1.6 项目管理办公室
          • PMO是组织中指导、协调和支持项目管理工作的一个常设职能部门，也就是管理项目管理的常设职能部门。它负责：
            • 制定和贯彻标准化的项目管理方法论（包括工作流程与规章制度等）
            • 协调所辖各项目对资源、工具、技术和方法的共享
            • 为所辖各项目提供必要的支持
          • PMO分成以下三种：
            • 支持型
            • 控制型
            • 指令型
      • 2.2 事业环境因素和组织过程资产
        • 2.2.1 事业环境因素
          • 事业环境因素是能影响项目但项目团队无法控制的任何内外部环境因素。内部环境因素来自项目执行组织内部，外部环境因素来自项目执行组织外部
          • 事业环境因素可能提高或限制项目管理的灵活性，可能对项目有积极或消极的影响。
          • 组织内部的事业环境因素
          • 组织外部的事业环境因素
          • 《PMBOK®指南》中只有三个过程会导致事业环境因素更新
            • 获取资源
            • 建设团队
            • 管理团队
        • 2.2.2 组织过程资产
          • 组织过程资产是来自执行组织的，正式或非正式的政策、流程、程序、模板、工作指南和知识库（数据库），用于帮助项目成功
          • 在实际工作中，组织过程资产与事业环境因素肯定是交叉的
          • 究竟是资产还是环境取决于项目经理的态度。主动利用就是资产；不想利用它但又不得不遵守就是环境
          • 组织过程资产的主要内容
          • PMP®考试中，一定要假设项目执行组织有很好的历史资料库，有很好的组织过程资产积累
          • 在整个项目生命周期中，要经常更新组织过程资产；在项目阶段结束及整个项目结束时，必须更新组织过程资产
          • 组织过程资产更新的主要内容
        • 2.2.3 事业环境因素和组织过程资产的动态性
          • 在整个项目期间，事业环境因素和组织过程资产都并非一成不变，而是会动态变化的
          • 对于事业环境因素，项目经理应该：
            • 持续关注和定期调查商业环境的变化
            • 评估环境变化对项目的影响
            • 为适应环境变化而提出对项目的变更建议
            • 跟踪经批准的变更的实施情况，评价变更的有效性
          • 对于组织过程资产，项目经理应该：
            • 持续关注新积累的经验教训、工作流程、工作模板和工作数据等
            • 分析其与本项目的相关性，加以选择利用
      • 2.3 项目合规
        • 2.3.1 概述
          • 项目合规是指项目必须符合相关的法律、规则、标准或要求，包括内部合规和外部合规。
            • 内部合规是指符合项目内部以及组织内部的规则或要求
            • 外部合规是指符合项目所在组织外部的法律、规则或标准
            • 通常，要通过内部监控来确保内部合规，再以内部合规来确保外部合规
        • 2.3.2 合规要求
          • 对项目的合规要求会来自许多不同方面，如国际组织、政府机构、行业协会和项目执行组织等。各种合规要求对项目的影响也会有所不同。有些合规要求可归类于事业环境因素，有些可归类于组织过程资产，它们都会从外部对本项目施加影响。还有些合规要求则必须作为本项目的一部分，列入项目工作分解结构和相关项目计划加以实施
        • 2.3.3 合规管理的步骤
          • 项目合规管理的基本步骤包括：
            • 调查和确认项目合规要求
            • 分析不合规的后果
            • 分析可能导致不合规的主要威胁
            • 为方便管理，对合规要求进行归类
            • 采取必要的方法和措施来响应合规要求
            • 采取合适的措施支持对合规要求的响应
            • 内部评估项目合规程度
            • 外部审计项目合规程度
      • 2.4 项目生命周期
        • 2.4.1 概述
          • 项目生命周期是项目从开始到结束所经历的一系列技术工作阶段。每个阶段都有阶段准入标准、应完成的工作和应提交的可交付成果，都需要有阶段验收标准与阶段放行口
          • 项目生命周期阶段的多少与项目工期长短没有必然联系，而取决于所需的管理和控制的严格程度
          • 在项目关闭阶段，对资源的需求必须急剧下降，因为收尾要快，不能拖拖拉拉
        • 2.4.2 项目生命周期的特点
          • 项目生命周期是按技术工作来划分项目阶段的，每个阶段都要完成不同的技术任务
          • 对于项目生命周期，需要注意以下几点：
            • 不同类型的项目有不同的阶段划分
            • 每个阶段都可看作一个单独的项目或子项目
            • 通常，一个阶段结束后，才开始另一个阶段（阶段之间为先后顺序关系）
            • 阶段之间也可以是迭代关系
            • 如果一个项目包括几个相对独立的部分，各阶段既可能在各个组成部分同步演进，也可能不同步演进
            • 一个阶段的结束并不一定意味着下个阶段的开始
        • 2.4.3 项目生命周期的类型
          • 《PMBOK®指南》列出了以下五种不同的项目生命周期：
            • 预测型生命周期，也叫计划驱动型生命周期，是先编制好项目计划，详细定义项目产品及所需开展的工作，再严格按计划开展工作并完成已定义好的产品
            • 迭代型生命周期，是通过越来越精细地重复开展同种类的技术工作来不断优化产品功能
            • 增量型生命周期，是经过一个又一个固定时间段（称为“时间盒”）来逐渐增加产品功能
            • 适应型生命周期，也叫敏捷型或变更驱动型生命周期，是迭代型和增量型的混合
            • 混合型生命周期，是预测型和适应型的混合
          • 开展迭代，是因为不可能一次就做好某个功能；进行增量开发，是因为不可能一次就做全所有功能
          • 预测型&迭代型&增量型
            • 预测型
            • 迭代型
            • 增量型
          • 预测型和适应型项目生命周期比较
        • 2.4.4 产品生命周期
          • 产品生命周期是从项目开始到项目结束再到项目产品运营终止（退出市场）的全过程。项目生命周期只是产品生命周期中的一个产品阶段
          • 产品生命周期由一系列产品阶段构成，如研发阶段、导入阶段、上升阶段、成熟阶段、衰退阶段和退出阶段
          • 与产品生命周期相对应的成本概念，是“生命周期成本”，即在整个产品生命周期中所发生的全部成本，包括项目建设成本、项目建成后的运营成本，以及产品退市的处理成本
      • 2.5 项目经理
        • 2.5.1 项目经理的定义
          • 项目经理是受项目执行组织委派，领导项目团队去实现项目目标的个人。一个项目可能有多个执行组织，而每个执行组织都有一个对本组织负责的项目经理
          • 由于不同项目在组织中具有不同的重要性，项目经理在组织中的地位也就高低不等
        • 2.5.2 项目经理的责任
          • 项目经理对所管理的项目、项目所在组织、项目管理职业以及相关行业和学科，都负有程度不等的责任
          • 项目经理是所管理的项目的唯一责任点，必须确保在规定的范围、进度、成本和质量要求之下交付出可交付成果，并满足项目相关方在项目上的利益追求
        • 2.5.3 项目经理的胜任力
          • 胜任力是指为了胜任某个特定岗位而必须具备的知识、技能和态度，以及相应的行为
          • 不同于一般意义上的“能力”，“胜任力”专门针对特定岗位或特定工作而言
          • 胜任力开发需要通过以下五个阶段：
            • 知自己无能
            • 知道自己无能
            • 知道自己有能
            • 不知道自己有能
            • 故意保持自己有能
          • PMI发布的“人才三角”，是高层级的项目经理胜任力框架，其中包含项目管理技术、领导力以及战略和商务管理三个维度
        • 2.5.4 项目经理的权力
          • 在项目管理中，项目经理往往需要在正式权力（职位权力）不足的情况下，组织其他人来完成任务，所以他必须知道如何取得他人的合作
          • 各种权力及其归类和解释
          • 来自人身的权力是长久有效的权力，是每个人都应该尽力追求的。正式权力不足的项目经理，就更应该注重自己的参照权力、专家权力和魅力权力
        • 2.5.5 领导风格
          • 领导，主要是对人；管理，主要是对事。领导是指创建愿景，使员工看到愿景，并通过启发和激励带领员工朝愿景前进
          • 项目经理应该用源自职位的权力做好管理，用源自人身的权力做好领导
          • 《PMBOK®指南》列出了六种常用的领导风格：
            • 放任型
            • 交易型
            • 仆人型
            • 变革型
            • 魅力型
            • 交互型
          • 领导风格划分成：
            • 命令式
            • 推销式
            • 参与式
            • 授权式
          • 领导风格甚至可以被最粗略地分为：
            • 独裁式
            • 民主式
            • 放任式
          • 三种领导风格的比较
          • 究竟采用哪种领导风格或管理风格，需要因人因事因时而异。
      • 2.6项目经理作为整合者
        • 2.6.1 概述
          • 项目经理需要懂技术，具备一定的技术能力，但不必是技术专家
          • 作为跨专业的项目的管理者，项目经理必须是一个整合者
          • 项目经理绝对不能把整合管理授权给别人去做，而必须自己亲自做
        • 2.6.2 项目的复杂性
          • 项目的复杂性主要来自三个方面
            • 一是系统行为
            • 二是人类行为
            • 三是事物的模糊性
        • 2.6.3 两个角度
          • 一是项目外部角度。使项目符合所在组织的需要
          • 二是项目内部角度。使项目团队中的每个人都朝着同一个方向努力
        • 2.6.4 三个层面
          • 一是过程层面
          • 二是认知层面
          • 三是背景层面
        • 2.6.5 四大技能
          • 一是掌握项目管理的主要技术，能够自己亲自做事
          • 二是具备强大的领导力，能够激励和领导别人做事
          • 三是掌握一些商务管理知识，能够取得职能经理的支持，并使项目更好地服务于组织经营
          • 四是掌握一些战略管理知识，能够有效地与高层管理人员对话，并使项目更好地服务于组织的战略目标
        • 2.6.6 五大关系
          • 一是项目内部的关系
          • 二是项目与所在组织的关系
          • 三是项目与所在行业的关系
          • 四是项目与项目管理职业的关系
          • 五是项目与其他职业的关系
    • 第3章 项目管理过程
      • 3.1 过程及其相互关系
        • 3.1.1 定义和作用
          • 定义：过程是旨在完成预定目标的、一系列相互关联的活动的集合，以便运用一系列工具与技术把特定的输入转化成特定的输出
          • 作用：《PMBOK®指南》的主要贡献就是把非结构化的项目管理，变成相对结构化的项目管理
        • 3.1.2 项目管理过程之间的逻辑关系
          • 为了讨论的方便，项目管理各过程以相互独立、界限分明、首尾相连的形式，出现在《PMBOK®指南》中
          • 理解项目管理各过程之间的逻辑关系时，需要注意以下几点：
            • 在实际工作中，各过程之间的界面不一定非常明确，它们之间可能有很大程度的相互交叠，即并行开展
            • 每个过程在一个项目上可能需要反复进行几次甚至许多次，有2种情况
              • 一种是每次都在更加详细的程度上进行，这是由项目渐进明细性决定的
              • 另一种是在下一个过程的进行期间，发现有必要重新进行上一个过程
            • 监控过程实际上会针对所有其他过程，而不只是针对执行过程，因为任何工作都要被监控
            • 除了专门开展的事后监控，更多的监控工作会随被监控工作同时开展，而不能在时间段上独立存在
            • 一个项目或子项目或某个阶段，在正式启动之后、正式结束之前，往往需要反复开展规划、执行与监控过程
          • 不能用纯直线型思维去理解项目管理各过程之间的关系，各过程之间通常存在交叠和循环关系
        • 3.1.3 项目管理过程的开展频率（一次+定期+持续）
          • 仅开展一次或仅在预定义时点开展的项目管理过程
          • 需要定期开展的过程
          • 需要持续开展的过程
      • 3.2 过程组
        • 3.2.1 过程组与戴明环
          • 《PMBOK®指南》把49个项目管理过程归纳为五大过程组，即启动、规划、执行、监控和收尾
            • 启动过程组有2个过程
            • 规划过程组有24个过程
            • 执行过程组有10个过程
            • 监控过程组有12个过程
            • 收尾过程组有1个过程
            • 项目管理过程组与知识领域
          • 戴明环：五大过程组的理论基础是著名的“计划—实施—检查—行动”循环（PDCA循环）
            • 规划过程--计划Plan
            • 执行过程--实施Do
            • 监控过程组--检查+行动Check+Action
            • 项目管理过程组比戴明环多一个入口（启动过程组）和一个出口（收尾过程组）
        • 3.2.2 过程组之间的关系
          • 项目管理各过程之间的交叠和循环关系，当然就造成了项目管理五大过程组之间的交叠和循环关系
          • 《PMBOK®指南》特别强调“项目阶段不同于项目管理过程组”。项目阶段关注的是项目的技术工作，即每个阶段开展不同的技术工作。项目管理过程组关注的是项目的管理工作，即各过程组开展不同的管理工作
          • 实际上，任何一个项目管理过程都可以在任何一个项目阶段开展。甚至在项目的起始阶段也可以开展结束项目或阶段过程，考虑将来的项目收尾该怎么做
          • 项目管理五大过程组之间的主要关系
        • 3.2.3 启动和收尾过程组的主要工作
          • 启动过程组
            • 启动过程组旨在制定项目的总体目标，并宣布项目正式立项。启动过程组其实是办理项目的立项手续
            • 通常，项目经理参与但并不领导项目启动工作。启动工作由项目发起人或高级管理层领导
          • 收尾过程组
            • 收尾过程组旨在正式关闭项目，并更新组织过程资产
            • 需要注意
              • 如果项目是通过合同来做的，对每个合同都要进行合同收尾
              • 项目的产品范围或技术工作全部完成了，并不代表项目结束。项目必须经过正式的结束项目或阶段过程，完成行政收尾工作，才可以正式关闭
              • 收尾工作不仅针对整个项目，也要在每个阶段结束时进行
              • 做好向后续阶段或成果运营的知识转移，以支持后续阶段或成果运营的开展
            • 收尾过程组并非用来解决项目中存在的问题，所有问题都必须通过监控过程组和其他三大过程组加以解决
        • 3.2.4 规划过程组的工作流程
          • 规划过程组旨在细化项目目标，并为实现项目目标编制项目计划（包括项目管理计划和各种项目文件）
          • 规范过程组的总体思路是
            • 首先，编制各分项管理计划（程序性计划，或程序性和实体性计划的综合）
            • 然后，根据各分项管理计划编制项目范围计划、进度计划、成本计划、质量计划、风险计划和采购计划（实体计划）
            • 最后，把所有分项管理计划以及高层次的范围计划（范围基准）、进度计划（进度基准）和成本计划（成本基准）汇编成项目管理计划。其他低层次实体性计划则作为项目文件或采购文档而在存在
          • 在项目范围管理、进度管理、成本管理、质量管理、风险管理和采购管理这六大知识领域，程序性计划和实体性计划是分开的
          • 在项目资源管理、沟通管理和相关方管理，程序性计划和实体性计划合二为一
          • 规划过程组的内容比较多，总共有24个项目管理过程。为便于掌握，应该对项目计划（包括项目管理计划和各种项目文件）编制的步骤进行总结
          • 规划过程组的总体工作流程
        • 3.2.5 执行过程组的工作流程
          • 执行过程组旨在获取资源，开展项目计划中的项目工作，实现项目目标
          • 执行过程组内部的工作流程，可以概括为如下10个步骤：
            • 第1步：获取项目资源，包括人力和实物资源（获取资源过程）
            • 第2步：开展项目团队建设（建设团队过程）
            • 第3步：管理项目团队（管理团队过程）
            • 第4步：管理相关方参与（管理相关方参与过程）
            • 第5步：对外购部分进行采购，选择卖方，签订采购合同（实施采购过程）
            • 第6步：按项目计划开展项目实施（指导与管理项目工作过程）
            • 第7步：管理项目知识（管理项目知识过程）
            • 第8步：开展质量管理，包括质量保证（管理质量过程）
            • 第9步：实施风险应对策略和措施（实施风险应对过程）
            • 第10步：发布项目信息（管理沟通过程）
          • 在实际工作中这些步骤往往是纠缠在一起的，没有明显的先后顺序
          • 执行过程组的主要成果是工作绩效数据和可交付成果
        • 3.2.6 监控过程组内的工作流程
          • 监控过程组旨在监督项目进展情况，发现并分析实际与计划的偏差，提出并审批变更请求，以保证项目目标的实现
          • 每个知识领域都有监控过程（12个）
          • 监控过程组的总体工作流程如下：
            • 第1步：开展基层局部监控
            • 第2步：开展高层全局监控，监控整个项目的绩效
            • 第3步：审批变更请求
          • 无论是哪个过程提出的变更请求，都必须提交实施整体变更控制过程审批
          • 监控过程组的总体工作流程
      • 3.3 数据、信息和报告
        • 3.3.1 工作绩效数据
          • 工作绩效数据（Work Performance Data）
            • 是在项目执行过程中，一边执行一边收集起来的，未经任何加工整理的原始资料，用于真实、完整地记录工作的执行情况
            • 是指导与管理项目工作过程的输出，是项目监控时用来与计划要求做比较的实际数据
        • 3.3.2 工作绩效信息
          • 工作绩效信息（Work Performance Information）
            • 是对工作绩效数据进行加工整理后得到的，是相互联系且有明确的产生背景的数据
            • 它是全部的基层局部监控过程的输出，并成为监控项目工作过程（高层全局监控过程之一）的输入
          • 监督风险过程，用于单个项目风险时，为基层局部的监控过程；用于整体项目风险时，则为高层全局的监控过程
        • 3.3.3 工作绩效报告
          • 工作绩效报告（Work Performance Reports）则是对工作绩效信息进行进一步加工、整理、汇编而得到的，关于项目绩效的专题或综合报告，可以定期编制，或为某种特殊目的而专门编制（如配合领导即将对项目进行的检查）
        • 工作绩效数据、工作绩效信息与工作绩效报告之间的主要区别
        • 工作绩效数据、信息与报告之间的关系
      • 3.4 全部过程的输入：事业环境因素和组织过程资产+项目管理计划+项目文件+其他输入
        • 3.4.1 概述
          • 《PMBOK®指南》共列出了20个输入和73个输出
            • 输入：4+1+15
              • 外部：4个来自项目外部，即事业环境因素、组织过程资产、商业文件和卖方建议书
              • 既外部又内部：1个（协议）既可以来自项目外部也可以来自项目内部
              • 内部：其他15个都是本项目内部产生的，即相应项目管理过程的输出
              • 来自项目外部的协议有2种情况：
                • 一种是项目发起人之间关于发起项目的合作协议
                • 另一种是从承包商的角度来看的它与业主之间的合同，该合同是承包商启动承包项目的依据
            • 输出：2+4+67
              • 2个会成为项目最终的成果，即最终产品、服务或成果移交，最终报告
              • 4个先成为本项目其他项目管理过程的输入，待最后更新后就成为最终成果（输出-->其他项目输入-->更新后成为最终成果），即事业环境因素更新、组织过程资产更新、采购文档更新、项目文件更新
              • 67个都会成为本项目其他项目管理过程的输入，即仅在项目内部使用（13+54）
                • 54个都被归并到了“项目管理计划”“项目文件”“采购文档”和“其他过程的输出”中
                • 除了项目章程、项目管理计划、项目资金需求、可交付成果、变更请求、批准的变更请求、协议、团队绩效评价、核实的可交付成果、验收的可交付成果、工作绩效数据、工作绩效信息和工作绩效报告
              • 项目资金需求主要供发起人及时按量为项目准备资金，而非供项目团队内部使用，故没有归入“项目文件”
              • 各种输出归并为输入的情况
                • 注：* 供方选择标准在《PMBOK®指南》第98页又被列为“项目文件”，这不合理
              • “项目管理计划”是一份单一的文件，而“项目文件”和“采购文档”都不是单一的文件，只是各种文件的统称
        • 3.4.2 事业环境因素和组织过程资产
          • 《PMBOK®指南》中共有40个过程使用事业环境因素这个输入（全部启动+全部规划+8个执行+6个监控）
            • 全部2个启动过程
            • 全部24个规划过程
            • 8个执行过程，即指导与管理项目工作、管理项目知识、管理沟通、管理相关方参与、实施采购、获取资源、建设团队、管理团队。只有“管理质量”和“实施风险应对”这2个执行过程没有事业环境因素这个输入
            • 6个监控过程，即监控项目工作、实施整体变更控制、控制质量、监督沟通、监督相关方参与、控制采购。另外6个监控过程，即控制范围、确认范围、控制进度、控制成本、控制资源和监督风险，没有事业环境因素这个输入
          • 在整个项目生命周期中，都要利用组织过程资产。在全部49个过程中，对47个过程列出了“组织过程资产”这个输入，只有以下2个监控过程不用组织过程资产：确认范围、监督风险
        • 3.4.3 项目管理计划
          • 《PMBOK®指南》各过程的文件类输出，又可以分成2类（项目管理计划+具体文件）：
            • 第一类是项目管理计划及其组成部分。项目管理计划是关于管理工作的安排和高层次的项目要求（项目基准）
            • 第二类是各种各样的具体文件。规划阶段所编制的各种具体文件，则是关于技术工作安排和细节性的项目要求（为了确保基准的实现）
          • 在全部49个项目管理过程中，只有“制定项目章程”和“制订项目管理计划”这2个过程没有“项目管理计划”这个输入
          • 各过程所使用的“项目管理计划”的具体内容不一定相同。例如，所有“规划××管理/参与过程”仅使用“项目管理计划”大纲，或已编制出的子管理计划
        • 3.4.4 项目文件
          • 在全部49个项目管理过程中，只有6个过程没有“项目文件”这个输入，即制定项目章程、制订项目管理计划、规划范围管理、规划进度管理、定义活动、规划成本管理
        • 3.4.5 其他输入
          • 其他输入与相应过程的对照
      • 3.5 全部过程的输出：变更请求+项目管理计划更新+项目文件更新+组织过程资产更新+其他输出
        • 3.5.1 概述
          • 《PMBOK®指南》所列的73个输出中，只有4个是非文件类的输出，即可交付成果、核实的可交付成果、验收的可交付成果和最终产品、服务或成果移交（移交的可交付成果）
        • 3.5.2 变更请求（24个过程）
          • 总共24个过程会提出变更请求（1+4+8+11）
            • 1个启动过程，即识别相关方。重复开展识别相关方过程时，可能提出变更请求
            • 4个规划过程，即定义活动、制订进度计划、规划风险应对、规划采购管理
            • 8个执行过程，即指导与管理项目工作、管理质量、获取资源、建设团队、管理团队、实施风险应对、实施采购、管理相关方参与。其他2个执行过程，即管理项目知识、管理沟通，没有“变更请求”这个输出
            • 除实施整体变更控制过程以外的全部（11个）监控过程，即监控项目工作、确认范围、控制范围、控制进度、控制成本、控制质量、控制资源、监督沟通、监督风险、控制采购、监督相关方参与。监控就是发现偏差，提出必要的变更请求。实施整体变更控制过程则专用于审批变更请求
          • 变更请求主要是执行与监控过程的输出。因为收尾阶段不能再变更，所以收尾过程不会提出变更请求
        • 3.5.3 项目管理计划更新（26个过程）
          • 总共26个过程会输出“项目管理计划更新”（1+5+9+11）
            • 1个启动过程，即识别相关方
            • 5个规划过程，即定义活动、制订进度计划、规划质量管理、规划沟通管理、规划风险应对
            • 9个执行过程，即指导与管理项目工作、管理项目知识、管理质量、获取资源、建设团队、管理团队、管理沟通、实施采购、管理相关方参与。只有1个执行过程，即实施风险应对，不会导致项目管理计划更新
            • 11个监控过程，即监控项目工作、实施整体变更控制、控制范围、控制进度、控制成本、控制质量、控制资源、监督沟通、监督风险、控制采购、监督相关方参与。只有1个监控过程，即确认范围，不会导致项目管理计划更新
          • “项目管理计划更新”主要是执行和监控过程的输出
        • 3.5.4 项目文件更新（29个过程）
          • 总共39个过程会输出“项目文件更新”。只有10个过程没有“项目文件更新”，即制定项目章程、制订项目管理计划、管理项目知识、规划范围管理、收集需求、规划进度管理、定义活动、规划成本管理、规划风险管理、规划相关方参与
          • 除了管理项目知识过程，其余全部执行过程都有“项目文件更新”。全部监控过程都有“项目文件更新”
          • 项目文件（Project Documents）并不是一个单一的文件，而是各种项目文件的统称
          • 更新项目管理计划必须走变更流程、经过审批，而更新项目文件不一定要走流程审批
        • 3.5.5 组织过程资产更新（10个过程）
          • 总共10个过程有“组织过程资产更新”这个输出（1+6+2+1）
            • 1个规划过程，即规划采购管理
            • 6个执行过程，即指导与管理项目工作、管理项目知识、获取资源、建设团队、管理沟通、实施采购
            • 2个监控过程，即监督风险、控制采购
            • 1个收尾过程，即结束项目或阶段
          • 另外，《PMBOK®指南》中
            • 3个过程有“事业环境因素更新”，即获取资源、建设团队、管理团队
            • 1个过程有“采购文档更新”，即控制采购
        • 3.5.6 其他输出
          • 除变更请求及各种更新以外的输出及其相应的项目管理过程
      • 3.6 全部过程的工具与技术（65个工具与技术，49个项目管理过程）
        • 《PMBOK®指南》总共列出了65个工具与技术（这里把一个技术组暂且当作一个技术看待），用于49个项目管理过程。其中有些工具与技术是2个或以上过程共用的
        • 3.6.1 专家判断：35个过程（2个启动+22个规划+5个执行+5个监控+1个收尾）
          • 使用“专家判断”的35个过程是：（2个启动+22个规划+5个执行+5个监控+1个收尾）
            • 全部2个启动过程，即制定项目章程、识别相关方
            • 22个规划过程。只有2个规划过程没有“专家判断”，即排列活动顺序、制定进度计划
            • 5个执行过程，即指导与管理项目工作、管理项目知识、实施风险应对、实施采购、管理相关方参与
            • 5个监控过程，即监控项目工作、实施整体变更控制、控制成本、监督沟通、控制采购
            • 1个收尾过程，即结束项目或阶段
        • 3.6.2 数据分析：32个过程（1个启动+18个规划+2个执行+10个监控+1个收尾）
          • 使用“数据分析”的32个过程是：（1个启动+18个规划+2个执行+10个监控+1个收尾）
            • 1个启动过程，即识别相关方
            • 18个规划过程。只有6个规划过程没有“数据分析”，即创建WBS、定义活动、排列活动顺序、规划资源管理、规划沟通管理、制订项目管理计划
            • 2个执行过程，即管理质量、实施采购。
            • 10个监控过程。只有2个监控过程没有“数据分析”，即确认范围、监督沟通
            • 1个收尾过程，即结束项目或阶段
        • 3.6.3 会议：28个过程（2个启动+15个规划+4个执行+6个监控+1个收尾）
          • 使用“会议”的28个过程是：（2个启动+15个规划+4个执行+6个监控+1个收尾）
            • 全部2个启动过程，即制定项目章程、识别相关方
            • 15个规划过程，即制订项目管理计划、规划范围管理、规划进度管理、规划成本管理、规划质量管理、规划资源管理、规划沟通管理、规划风险管理、规划采购管理、规划相关方参与、定义活动、排列活动顺序、估算活动资源、识别风险、实施定性风险分析
            • 4个执行过程，即指导与管理项目工作、建设团队、管理沟通、管理相关方参与
            • 6个监控过程，即监控项目工作、实施整体变更控制、控制质量、监督沟通、监督风险、监督相关方参与
            • 1个收尾过程，即结束项目或阶段
        • 3.6.4 人际关系与团队技能：20个过程（1个启动+8个规划+8个执行+3个监控）
          • 这是一个技术组，其下属有17个技术。使用“人际关系与团队技能”的20个过程是：（1个启动+8个规划+8个执行+3个监控）
            • 1个启动过程，即制定项目章程
            • 8个规划过程，即制订项目管理计划、收集需求、定义范围、规划沟通管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对
            • 8个执行过程。只有2个执行过程没有“人际关系与团队技能”，即指导与管理项目工作、管理质量
            • 3个监控过程，即控制资源、监督沟通、监督相关方参与
        • 3.6.5 数据收集：13个过程（2个启动+9个规划+1个执行+1个监控）
          • 这是一个技术组，其下属有9个技术。使用“数据收集”的13个过程是：（2个启动+9个规划+1个执行+1个监控）
            • 全部2个启动过程，即制定项目章程、识别相关方
            • 9个规划过程，即制订项目管理计划、规划质量管理、规划采购管理、收集需求、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、规划相关方参与
            • 1个执行过程，即管理质量
            • 1个监控过程，即控制质量
        • 3.6.6 决策：13个过程（7个规划+2个执行+4个监控）
          • 这是一个技术组，其下属有2个技术。使用“决策”的13个过程是：（7个规划+2个执行+4个监控）
            • 7个规划过程，即收集需求、定义范围、估算活动持续时间、估算成本、规划质量管理、规划风险应对、规划相关方参与
            • 2个执行过程，即获取资源、管理质量
            • 4个监控过程，即监控项目工作、实施整体变更控制、确认范围、监督相关方参与
        • 3.6.7 项目管理信息系统：12个过程（4个规划+4个执行+4个监控）
          • 使用“项目管理信息系统”的12个过程是：（4个规划+4个执行+4个监控）
            • 4个规划过程，即排列活动顺序、估算活动资源、制订进度计划、估算成本
            • 4个执行过程，即指导与管理项目工作、管理团队、实施风险应对、管理沟通
            • 4个监控过程，即控制进度、控制成本、控制资源、监督沟通
        • 3.6.8 数据表现：11个过程（1个启动+6个规划+1个执行+3个监控）
          • 这是一个技术组，其下属有15个技术。使用“数据表现”的11个过程是：（1个启动+6个规划+1个执行+3个监控）
            • 1个启动过程，即识别相关方
            • 6个规划过程，即规划质量管理、规划资源管理、规划沟通管理、规划相关方参与、收集需求、实施定性风险分析
            • 1个执行过程，即管理质量
            • 3个监控过程，即控制质量、监督沟通、监督相关方参与
        • 2～4个过程共用的工具与技术
        • 仅供一个过程使用的工具与技术
    • 第4章 项目整合管理
      • 4.1 概述
        • 4.1.1 基本概念
          • 整合是指协调、统一与综合
            • 协调是指使各要素没有矛盾
            • 统一是指使各要素都指向同样的目标
            • 综合是指使各要素形成一个能发挥更大作用的新系统
          • 项目整合管理是项目管理的核心，是为了实现项目各要素之间的相互协调，并在相互矛盾或竞争的目标中寻找最佳平衡点
          • 整合管理涉及以下几个方面：项目内部+项目外部
            • 项目内部
              • 在相互竞争的项目各分目标之间的整合
              • 在具有不同利益的各项目相关方之间的整合
              • 在项目所需要的不同专业工作之间的整合
              • 在项目管理的各过程之间的整合
              • 在管理与技术工作之间的整合
            • 项目外部
              • 项目目标与组织的战略目标之间的整合，确保项目目标符合组织战略
              • 项目目标与组织的运营目标之间的整合，确保项目成果能够有效融入日常运营
          • 需要整合的地方，无法一一列举，因为只要存在结合部，就需要整合
        • 4.1.2 项目经理作为整合者
          • 项目经理在项目管理中的角色是多方面的，其中最重要的角色是整合者。作为整合者，项目经理必须看到项目的“大局图”，确保项目全局的利益。需做到：
            • 通过与项目相关方主动、充分的沟通，来了解他们对项目的需求
            • 在相互竞争的众多相关方之间寻找平衡点
            • 通过认真、细致的协调工作，来达到各种需求之间的平衡，实现整合
          • 《PMBOK®指南》特别强调，项目经理必须亲自承担项目整合管理的工作，而不能把这个工作授权给任何其他团队成员去开展
        • 4.1.3 整合管理在各知识领域中的地位
          • 项目整合管理是项目管理的管理哲学，是项目管理与传统管理的最大区别所在
          • 项目管理是以整合为主、分工为辅的管理
          • 从十大知识领域的相互关系来看，整合管理是项目管理的指导思想
      • 4.2 各过程的输入与输出
        • 4.2.1 输入与输出的关系总览
          • 项目整合管理的实现过程包括制定项目章程、制订项目管理计划、指导与管理项目工作、管理项目知识、监控项目工作、实施整体变更控制和结束项目或阶段
          • 这些过程通过输入与输出相互联系。前一个过程的输出往往就是后一个或几个过程的输入
          • 项目整合管理各过程的输入与输出之间的关系
        • 4.2.2 对输入与输出的解释
          • 过程p82
            • 项目发起人组织开展项目前期准备工作，发布商业文件（含商业认证和效益管理计划）和协议。然后项目进入制定项目章程过程，办理立项手续。协议，既可以是发起人之间的合作协议（如果不止一个发起人），也可以是承包合同（对承包商而言）。
            • 在制定项目章程过程中，项目经理起草项目章程并报发起人签发。为了便于将来为断更新并逐项落实假设条件，还需要单独编制假设日志。
            • 项目经理带领项目团队，在项目章程的指导之下，把后九大知识领域各规划过程所编制的分项管理计划和分项基准，即其他过程的输出，汇编成项目管理计划并报高级管理层审批。
            • 项目团队依据项目管理计划和各种项目文件开展项目执行。一边执行，一边收集工作绩效数据。通过执行，产出可交付成果。在执行中，可能需要提出变更请求，还需要把发现的问题记入问题日志。
            • 项目团队在项目管理计划的指导下，根据后面各知识领域的基层监控过程所得到的工作绩效信息，以及各种项目文件，编制整个项目的工作绩效报告，并提出必要的变更请求。对于外包出去或所承包的工作，还需要根据协议（承包合同）来监控。
            • 任何过程提出的变更请求，都要提交实施整体变更控制过程审批，得到批准的变更请求。审批变更请求，需要在项目管理计划的指导下进行，并参考工作绩效报告和相关项目文件。批准的变更请求，又要提交给指导与管理项目工作过程实施。
            • 项目团队把执行过程所产出的可交付成果，提交给控制质量过程核实（是否符合质量要求），得到核实的可交付成果；继而再由确认范围过程确认（验收），得到验收的可交付成果。
            • 在结束项目或阶段过程中，根据项目管理计划以及各种项目文件、商业文件和协议，把验收的可交付成果移交给项目发起人或客户，并编制项目的最终报告。需要考察项目管理计划、商业文件和协议中的项目目标和商业价值的实现情况
          • 整合管理是从整个项目的全局视角开展的，项目管理计划的任何内容以及任何一种项目文件都可以成为其中的执行、监控和收尾过程的输入
      • 4.3-4.9项目整合管理过程
        • 4.3 制定项目章程
          • 制定项目章程，是项目启动阶段的一项重要工作，以便正式启动已经选定的某个项目，确立该项目在组织中的合法地位，授权项目经理动用组织资源开展项目工作。制定项目章程过程是要对已经被选定的项目办理正式的立项手续。
          • 4.3.1 项目的前期准备：落实项目的可行性+项目所需资金
            • 在制定项目章程过程之前须完成的准备工作，包括：
              • 项目发起人提出项目的初步设想
              • 聘请专家团队对项目开展商业论证（形成商业论证报告和效益管理计划）
              • 以及与相关机构签署关于发起项目的合作协议
            • 前期准备工作通常是在项目组合管理和项目集管理的层面上开展的。前期准备工作的主要目的是，落实项目的可行性，落实项目所需资金
            • 严格地说，前期准备工作不包括在项目管理的五大过程组之中，也不包括在项目管理的十大知识领域之中，当然也就不在项目经理的工作范畴之内
          • 4.3.2 项目启动
            • 发起人会亲自领导整个启动阶段，直至项目章程发布。项目章程发布之后，就由项目经理来领导项目
            • 在项目启动阶段，发起人授权候任项目经理开展以下主要工作：
              • 开展项目评估
              • 识别高层级的可交付成果
              • 确定高层级的进度和成本要求
              • 确定整体项目风险的级别及其主要来源
              • 识别主要的假设条件和制约因素
              • 识别和分析项目的主要相关方
              • 编制项目章程，获得发起人对项目章程的批准，并分发项目章程
            • 开展商业论证是为了筛选项目，而开展项目评估是为了确认可行的项目仍然可行。进入制定项目章程过程的项目一般不会被砍掉
          • 4.3.3 项目章程
            • 项目章程是一份非常重要的、对主要项目相关方有约束力的文件，相当于项目的“宪法”
            • 项目章程宣告项目的正式立项，确定项目的高层级目标，宣布项目经理的任命
            • 项目发起人或高级管理层可以亲自编制项目章程，也可以授权项目经理代为编制
            • 编制项目章程，不是要无中生有，而是要收集、分析、汇编和提炼已有的各种资料，如商业论证报告、效益管理计划、合作协议和项目评估报告
            • 项目章程必须由项目发起人或高级管理层签署，并发布给主要的项目相关方，以便各相关方都知道项目已经正式启动，都了解项目的主要目标，都了解各自在项目上的角色和职责
            • 通常不会因项目变更而导致对项目章程的修改。万一要对项目章程进行修改（如项目目标的修改），只有发起人或高级管理层才有权修改。谁签发项目章程，谁才有权修改项目章程
            • 项目章程应该包括以下主要内容：
              • 项目概述和产品概述
              • 项目目的或批准项目的理由
              • 可测量的项目成功标准
              • 高层级需求和相应的项目总体要求
              • 总体里程碑进度计划
              • 预先批准的财务资源
              • 整体项目风险的程度
              • 主要相关方
              • 项目审批权限
              • 项目退出标准
              • 项目经理及其权责
              • 项目章程签发者的姓名和职权
            • 项目章程至少包括以下方面的内容：
              • 正式确认项目的存在，给项目一个合法的地位
              • 明确启动项目的理由，把项目与运营及战略目标联系起来
              • 规定项目的高层级目标，包括范围、进度和成本和质量要求
              • 授权项目经理动用组织资源去开展项目工作
        • 4.4 制订项目管理计划（分项管理计划+分项基准=项目管理计划）
          • 把全部的分项管理计划和分项基准汇编成综合的项目管理计划
          • 分项管理计划是后面九大知识领域中各规划××管理过程和规划相关方参与过程的输出
          • 分项基准则是创建WBS、制订进度计划和制定预算过程的输出
          • 4.4.1 项目管理计划的主要内容（分项管理计划+三大基准+项目生命周期）
            • 根据《PMBOK®指南》，项目管理计划由3大部分组成：分项管理计划、三大基准、项目生命周期
              • 分项管理计划，主要的包括：
                • 范围管理计划、需求管理计划
                • 进度管理计划
                • 成本管理计划
                • 质量管理计划
                • 资源管理计划
                • 沟通管理计划
                • 风险管理计划
                • 采购管理计划
                • 相关方参与计划
                • 变更管理计划、配置管理计划
              • 三大基准是范围基准、进度基准和成本基准（范进成）
                • 在制订项目管理计划过程中，要把这三大基准整合成“绩效测量基准”。基准是一种特殊版本的项目计划。其特殊性表现在以下几个方面：
                  • 是项目经理据以考核项目执行情况的依据
                  • 一定是经过高级管理层和主要项目相关方批准的，而不是项目团队自编自用、无须特定批准的细节性计划
                  • 除非另行说明，都是指最新版本的项目计划，即当前基准，而不是过去曾经作为基准使用过的项目计划
                  • 如果要对基准进行变更，只有变更控制委员会才有权力批准。项目经理无权批准
                • 项目管理计划中没有“质量基准”，这是因为高层级的质量标准通常并非由项目经理或项目执行组织自行制定，而是在法律法规或行业标准中规定的
              • 项目生命周期的类型和阶段划分、计划采用的产品开发方法，以及管理层对项目进行审查的时点和内容安排
              • 项目管理计划是综合性计划，任何单项计划都不等同于项目管理计划（除非上下文另有要求）
          • 4.4.2 项目管理计划的作用
            • 项目管理计划是关于将如何开展项目规划、执行、监控和收尾，经过正式批准的综合性计划。一旦有了项目管理计划，后续的一切规划、执行、监控和收尾工作都必须按该计划开展
            • 除制定项目章程和制订项目管理计划过程以外，全部47个项目管理过程都要用项目管理计划作为输入
          • 4.4.3 项目管理计划和项目文件的区别
            • 项目管理计划是一份综合性计划，而项目文件是各种单个文件的统称，包括未经汇编的各种各样的文件
            • 具体区别
              • 项目管理计划一定是经过高级管理层审批的，而项目文件一般无须高级管理层审批，通常是项目团队自编自用的。某些文件在经高级管理层审批之前，属于项目文件；经高级管理层审批之后，就成了项目管理计划的组成部分，如项目范围说明书、概括性进度计划
              • 项目管理计划中的分项管理计划是程序性计划，相当于法律中的程序法（如刑事诉讼法）；而产生于规划过程组的各种项目文件都是实体性计划，相当于法律中的实体法（如刑法）
              • 对项目管理计划更新（修改）必须走变更流程，经高级管理层审批；而对项目文件更新则不一定需要走变更流程；即便需要走变更流程的项目文件更新，也无须高级管理层审批
            • 考试时，看到“项目管理计划”和“项目文件”这两个词时，要根据题意小心判断它们的覆盖范围
          • 4.4.4 项目计划的编制者
            • 项目团队成员编制项目计划，项目经理起总负责和整合的作用。其他重要相关方也要参与项目计划的编制工作
          • 4.4.5 项目计划的编制时间
            • 在项目执行开始之前，要编制出尽可能完整的项目计划（包括项目管理计划和项目文件）
            • 项目计划编制无法一蹴而就、一劳永逸，而是需要在相当长的时间内不断对计划进行审查、细化、完善和更新
            • 把后续的计划更新也考虑在内，项目计划的编制要经历以下步骤：
              • 各具体知识领域编制各自的分项计划，包括分项管理计划、分项基准和其他文件
              • 整合管理知识领域收集各分项管理计划和分项基准，整合成项目管理计划
              • 用项目管理计划和各种分项计划去指导项目的执行和监控工作，并在执行和监控过程中提出必要的变更请求，报实施整体变更控制过程审批
              • 根据经批准的变更请求，更新项目管理计划和各种分项计划
            • 通常采用滚动式规划方法编制项目计划，即对近期就要开展的工作，编制详细计划；而对远期的工作，只做粗略计划，以后再随时间推移而细化
          • 4.4.6 项目计划的整合
            • 要求整合开展各种项目规划活动，把各种分项计划综合成一个有机整体
            • 第一，要确定编制和整合各分项计划所需要的关键信息
            • 第二，要收集和分析这些信息，并编制出各分项计划
            • 第三，分析各分项计划之间的衔接关系，防止衔接不良
            • 第四，汇编各分项计划，形成完整的项目计划
            • 第五，确认完整的项目计划能够持续实现商业价值
        • 4.5 指导与管理项目工作
          • 本过程是开展项目管理计划中的各种活动，来实现计划的要求，完成可交付成果，并识别必要的项目变更，提出变更请求。项目执行阶段的开始通常以“开工会议”为标志
            • 召开开工会议通常是规划阶段的最后一项工作。如果计划编制者和执行者是不同的两批人，而执行者的就位又需要一段时间，则召开开工会议是执行阶段的第一项工作。例如，大型施工项目必须等施工队伍进点后才能召开开工会议
          • 在项目执行中，需要使用工作授权系统。工作授权系统是整个项目管理信息系统的一个子系统。它是一系列正式书面程序的集合，用来授权项目工作的开始，以保证该工作由正确的组织在正确的时间以正确的顺序执行
          • 除了按原定计划执行项目工作，本过程也要执行那些经批准的变更请求，包括经批准的预防措施、纠正措施与缺陷补救措施
        • 4.6 管理项目知识
          • 本过程是知识管理学科在项目管理中的应用
          • 知识管理的重点是把现有的知识条理化和系统化，以便更好地加以利用；同时，还要基于这些条理化和系统化的知识，以及对这些知识的实践来生成新的知识
          • 《PMBOK®指南》中特别提及了2个重要的知识管理活动：知识分享和知识集成。项目经理要创造一个很好的氛围，激励大家分享知识（显性知识+隐性知识）
          • 在《PMP®考试大纲》中，要求为确保“项目连续性（Project Continuity）”而进行知识分享。项目连续性是指项目工作不因严重风险或问题的发生而中断
          • 应创造有利于知识分享的氛围，明确与知识分享有关的权责，采用合适的知识分享途径和方法
        • 4.7 监控项目工作
          • 本过程是对项目工作进行监控，以保证实现项目管理计划所定义的项目目标。在《PMBOK®指南》中：
            • 一方面，提到了监控是贯穿项目始终的，即对启动、规划、执行和收尾工作都要进行监控
            • 另一方面，重点讨论了针对执行工作的监控。本书下文仅讨论针对执行工作的监控
          • 监控过程组中的“监控”，就是“监督”+“控制”
            • 监督是指把实际执行情况与计划要求相比较，发现偏差
            • 控制是指分析偏差，并提出和审批必要的变更请求，以便解决不可接受的大偏差
          • 在《PMBOK®指南》中，共有12个监控过程。除了专用于审批变更请求的“实施整体变更控制过程”，其他监控过程都要把执行情况与计划要求相比较，发现并分析偏差，并为解决不可接受的大偏差提出变更请求
          • 监控项目工作过程是整个项目层面上的高层面全局监控，是后九大知识领域的全部10个基层局部监控过程的基础上开展的。依据这些基层局部的监控过程所得到的“工作绩效信息”和其他资料，以及制订项目管理计划过程所得到的“项目管理计划”，来编制工作绩效报告，并提出 必要的变更请求
          • 《PMBOK®指南》中的“变更请求”是广义的，不仅包括对正式受控的项目计划（如项目管理计划）的修改建议，而且包括纠正措施建议、预防措施建议和缺陷补救建议
        • 4.8 实施整体变更控制
          • 本过程是对项目启动、规划、执行和监控过程中提出的变更请求进行综合评审，以便批准或否决变更请求，控制对项目的变更，维护项目基准的严肃性和完整性
          • 本过程专用于审批各种变更请求。无论哪个过程提出的哪种变更请求，都必须提交给实施整体变更控制过程审批
          • 本过程的主要任务是接收变更请求，评审变更请求，批准或否决变更请求。需要特别强调，本过程对变更请求的评审必须是全面、系统和综合的，必须考察一个变更可能给项目各方面带来的影响，而不能局限于考察对一两个方面的影响
          • 对变更请求的评审必须是综合性的。只有从总体上有利于项目的变更，才能被批准。必须防止因局部利益而损害全局利益
          • 对某个变更请求，可能既没有理由批准，也没有理由否决。在这种情况下，本过程就会做出一个临时的决定：暂时悬置变更请求。悬置的变更请求，往往要退回给变更请求的提出者，要求他们补充资料。
        • 4.9 结束项目或阶段
          • 本过程是按照正式的收尾程序，正式关闭采购合同、项目阶段或整个项目
          • 项目无论何因何时终止，都必须用结束项目或阶段过程来正式关闭
          • 为了关闭项目，必须开展以下行政收尾工作：
            • 完成剩余尾工，开展财务结算和决算，确保项目达到既定的完工（退出）标准
            • 获得重要相关方对项目可交付成果的最终验收。注意：这里的验收，只是形式上的验收，而不是实质性的技术验收（实质性的技术验收应早就在“确认范围过程”中完成了）
            • 项目可交付成果以及对其的照管责任移交给指定的相关方，如发起人或客户。这项工作往往与最终验收同时开展
            • 编制和分发最终的项目绩效报告
            • 收集各主要相关方对项目的反馈意见，了解他们的满意度
            • 整理项目资料，开展项目后评价，总结经验教训，更新组织过程资产，为组织和以后项目提出改进建议
            • 分享项目知识，如分发项目后评价报告，召开经验交流会
            • 释放资源（如退还剩余的资金和材料），解散团队，宣布项目正式关闭
      • 4.10 各过程的工具与技术
        • 4.10.1 专家判断：7个过程（全部）
          • 专家判断是项目整合管理7个过程共同使用的工具与技术
          • 专家判断是有关专家根据自己的知识与经验对问题做出判断。因为项目管理既有科学的成分，也有艺术的成分
          • 专家判断适用于一切管理和技术工作
          • 专家判断可以来自项目执行组织内部或外部、项目团队内部或外部
        • 4.10.2 会议：6个过程（除管理项目知识过程外）
          • 在项目整合管理的7个过程中，只有管理项目知识过程没有会议这个工具：
            • 在制定项目章程过程中：主要相关方会议+项目启动会
              • 需要召集主要相关方开会，讨论项目章程的主要内容并达成一致意见
              • 还需要召开由主要相关方参加的项目启动会（Initiating Meeting），来分发项目章程，宣布项目经理上任，宣布项目正式立项。启动会由项目发起人主持
            • 在制订项目管理计划过程中：计划编制会议+项目开工会（Kick-off Meeting）
              • 需要召开计划编制会议
              • 还需要在计划编制完成时，召开项目开工会（Kick-off Meeting），来介绍项目目标和项目计划，获取主要相关方的支持，宣布项目正式进入执行阶段
              • 在大型项目上，开工会可能在执行阶段召开；在多阶段项目上，每个阶段开始时都需要召开开工会。
              • 开工会是很可能要考的，且往往与启动会一起考。考试中，可能把Kick-offMeeting也翻译成“启动会”。在看到“启动会”时，一定要看一下它的英文究竟是什么。
            • 在指导与管理项目工作过程中：需要召开项目状态评审会，来交流项目进展情况
            • 在监控项目工作过程中，需要召开项目状态评审会，来评审项目进展情况，做出相关决定。因为监控和执行实际上无法截然分开，所以项目状态评审会，既是执行过程组的会，也是监控过程组的会
            • 在实施整体变更控制过程中，需要召开变更控制会，来评审变更请求，做出批准、否决或悬置变更请求的决定
            • 在结束项目或阶段过程中，需要召开收尾报告会、客户总结会、经验教训总结会、完工庆祝会
          • 从会议目的来讲
            • 分成：信息交流会+方案产生与评审会+决策制定会
            • 最好依次分开召开，如果必须合在一起开，也应该把整个会议分成3个大阶段：
              • 第一个阶段：只交流信息，确认事实
              • 第二个阶段：提出主意并对主意进行评审
              • 第三个阶段：做出决定，选择最好的主意
          • 对于会议，项目经理应该：
            • 事先明确会议目的
            • 事先制定会议规则，准备会议议程，并分发给相关人员
            • 只邀请相关人员参加会议，并要求每个参会者明白自己的责任
            • 按时开始、按时结束会议
            • 在会议上要坚持事先制定的议程，避免跑题
            • 除了解决特定问题，还应该使会议起到团队建设的作用
            • 做好会议记录，并在会后及时整理和分发会议纪要（24小时之内）
        • 4.10.3 人际关系与团队技能：3个过程（制定项目章程+制订项目管理计划+管理项目知识）
          • 是制定项目章程、制订项目管理计划和管理项目知识过程的工具
          • 制定项目章程和制订项目管理计划过程中，使用人际关系与团队技能，主要是引导、冲突管理和会议管理
          • 制定项目章程和制订项目管理计划过程中，使用人际关系与团队技能，是为了解决对项目目标和计划的意见不一致，而管理项目知识过程则是为了促进知识分享和知识创造
        • 4.10.4 数据收集：2个过程（制定项目章程+制订项目管理计划）
          • 是制定项目章程和制订项目管理计划过程的工具，是各种各样的数据收集技术的统称
          • 《PMBOK®指南》为这2个过程列出了都需要使用的头脑风暴、焦点小组和访谈
          • 对制订项目管理计划过程，《PMBOK®指南》还列出了核对单这个数据收集技术。可以用自己编制或其他标准化的核对单来检查项目管理计划是否包含了全部内容
        • 4.10.5 数据分析：3个过程（监控项目工作+实施整体变更控制+结束项目或阶段）
          • 是监控项目工作、实施整体变更控制和结束项目或阶段过程的工具，是用来探究变量之间的复杂关系的各种技术的统称
          • 在监控项目工作过程中：挣值分析+偏差分析+趋势分析+备选方案分析+成本效益分析
            • 需要计算已发生的绩效偏差（挣值分析）并分析其程度（偏差分析）和原因（根本原因分析）
            • 需要预测未来绩效（趋势分析）
            • 还需要为纠正偏差制定和选择备选方案（备选方案分析、成本效益分析）
          • 在实施整体变更控制过程中：备选方案分析+成本效益分析
            • 需要分析变更的备选方案（备选方案分析），分析变更的成本和效益（成本效益分析），以便做出批准或否决变更请求的决定
          • 在结束项目或阶段过程中：文件分析+回归分析+趋势分析+偏差分析技术
            • 需要分析最终项目偏差的严重程度，以及究竟是哪些因素导致了项目偏差，并对项目产品未来的效益做出预测。本过程需要使用文件分析、回归分析、趋势分析和偏差分析技术。
        • 4.10.6 决策：2个过程（监控项目工作+实施整体变更控制）
          • 是监控项目工作和实施整体变更控制过程的工具，是用于做决策的各种具体技术的统称
          • 在监控项目工作过程中：投票
            • 可能需要通过投票决定是否需要提出变更请求，以及需要提出怎样的变更请求
          • 在实施整体变更控制过程中：多标准决策分析+投票+独裁型决策制定
            • 通常需要采用多标准决策分析技术，从多个方面（用多个标准）去评价某个或某几个变更方案的优劣，以便做出决定
            • 也可以由一些专家通过投票来决定是否批准某个变更请求
            • 特殊情况下，可以由一个人进行独裁型决策制定
        • 4.10.7 项目管理信息系统：1个过程（指导与管理项目工作）
          • 指导与管理项目工作过程，需要使用项目管理信息系统。整个组织层面的项目信息系统，是项目的事业环境因素
          • 这个过程要使用的项目管理信息系统，则是为某个具体项目专设的信息系统，其中包括自动化的工具，如信息收集与发布系统、项目关键绩效指标监控系统
        • 4.10.8 知识管理：1个过程（管理项目知识）
          • 是管理项目知识过程的工具，是用于促进员工分享隐性知识、集成各人的知识以及合作创造新知识的各种具体方法的统称，如人际交往、会议、研讨会、讲故事、工作跟随和跟随指导
          • 工作跟随（Work Shadowing）是徒弟跟着师傅实习，徒弟无须承担任何责任，全部责任都由师傅承担。
          • 跟随指导（Work Reverse Shadowing）是反向跟随，是指经验丰富的人在特定时间跟随和观察新手的工作情况，并给予指导
        • 4.10.9 信息管理：1个过程（管理项目知识）
          • 是管理项目知识过程的工具，是用于促进显性知识分享的各种具体方法的统称，如图书馆服务、文献检索、经验教训登记册编制
        • 知识管理VS信息管理
          • 知识管理用于在人与人之间建立联系，以便分享隐性知识（无法脱离人而存在）
          • 信息管理用于在人和信息之间建立联系，以便分享显性知识（可以脱离人而存在）
        • 4.10.10 变更控制工具：1个过程（实施整体变更控制）
          • 是实施整体变更控制过程的工具
          • 应该根据项目的具体情况、相关方对变更管理的要求和各种环境因素，选择合适的变更控制工具
          • 借助变更控制工具，可以更有效地记录和评审变更请求，追踪变更处理情况，以及沟通相关事宜
      • 4.11 项目变更管理（重点）
        • 4.11.1 基本概念
          • 项目变更管理是指基于拥抱变更的心态，采用合适的变更管理策略（不同的产品开发方法需要不同的变更管理策略），主动预测和开展变更，确保项目一直朝正确的方向前进
          • 项目变更是指采取纠正措施、缺陷补救措施或预防措施，以及因计划本身的问题而修改已经批准的项目计划
            • 如果项目执行有问题，出现了不可接受的较大偏差，就需要采取纠正措施
            • 如果正在或已经形成的可交付成果存在范围或质量缺陷，就要采取缺陷补救措施
              • 范围缺陷是指产品功能不全
              • 质量缺陷是指已有的功能不符合技术要求
            • 如果预计未来的项目绩效达不到要求，就要采取预防措施
        • 4.11.2 变更产生的原因
          • 基本原因包括项目计划中的缺陷，项目外界情况的变化，以及项目执行的低效
          • 内部变更+外界变更
            • 项目经理不仅应该为确保项目目标的实现而开展变更管理，而且应该协助项目集经理或其他高管人员为确保项目继续符合组织的商业需求而开展变更管理。前者属于项目内部的变更管理，后者则属于为适应外界新情况而开展变更管理
          • 对项目变更必须进行有效的控制，防止无序、过多、过大的变更
          • 如果变更太多、太大，就可能需要修改项目章程，甚至必须终止现行项目，而另外启动一个新项目
        • 4.11.3 变更管理的程序
          • 5大步骤：源头上管理变更+提出变更请求+评审变更请求+实施和跟踪批准的变更+总结经验教训
            • 从源头上管理变更
              • 项目经理应该积极主动而非消极被动地工作。他要主动地对引发变更的各种因素施加影响，以避免不必要的变更
              • 项目经理还要主动地对导致人们规避整体控制的因素施加影响，防止人们有意无意地规避对变更的综合评审
              • 虽然《PMBOK®指南》中没有专用于从源头上管理变更的过程，但是大多数过程中都隐含着这项工作
            • 提出变更请求
              • 任何人都可以提出变更请求
              • 无论是书面还是口头的变更请求，都必须是正式提出的。非正式提出的变更请求，不能进入后续的变更管理程序
              • 提出变更请求者，必须清楚地说明变更是什么、为什么要进行变更，必须初步说明变更可能产生的后果，变更可用什么方案实现，必须防止相关方随意地提出变更请求，不考虑后果地乱提变更请求
              • 在项目计划被批准之后重复开展启动和规划过程，可能提出变更请求
              • 《PMBOK®指南》中共有24个过程会提出变更请求（包括1个启动过程和4个规划过程）
              • 项目计划被批准之后重复开展启动和规划过程，可能提出变更请求
            • 评审变更请求
              • 任何变更请求，都必须提交给项目经理。项目经理收到变更请求后，立即进行形式审查，并把看似有效的变更请求写入变更日志。一旦变更请求被写入变更日志，它就进入了评审阶段
              • PMP®考试中的“记录变更”，一般都是指把变更请求写入变更日志
              • 先基于变更请求中的变更方案，评审变更对所在领域的影响
              • 再基于变更请求中的变更方案，全面评审变更对项目各方面的综合影响
              • 如果必要，再设计其他备选方案并进行评审。某个变更，也许用多个不同的方案都能够实现
              • 变更无论大小，都必须经过综合评审，确认从总体上有利于项目，才能加以批准
              • 变更无论大小，都必须经过综合评审，确认从总体上有利于项目，才能加以批准
              • 在设计变更方案、进行变更评审的过程中，必须与主要相关方密切沟通，征求他们对变更的意见。应先征求项目团队成员的意见，再征求项目执行组织中相关部门和人员的意见。如有必要，还要征求外部相关对变更的意见。
              • 应该根据变更的审批权限，由项目经理、变更控制委员会、高级管理层或项目发起人来审批变更请求，做出批准、否决或悬置变更请求的书面决定。悬置的变更请求，通常要返回给提出者补充资料
            • 实施和跟踪批准的变更
              • 只有经过批准的变更，才能被实施、跟踪、考核和报告
              • 如果某个变更已经发生但未经审批，必须先补办审批手续，然后才能去跟踪、考核和报告
              • 变更请求被批准后，要及时更新项目文件和项目管理计划。批准的纠正措施、缺陷补救措施和预防措施，都要写入相应的项目文件。批准的计划修改，根据具体情况，写入项目文件甚至项目管理计划
              • 在《PMBOK®指南》中，对变更的实施，是通过指导与管理项目工作过程来开展的；对变更实施情况的追踪，是通过控制质量过程来开展的
            • 总结经验教训
              • 一项变更实施完毕后，必须及时考察变更的效率和效果，总结经验教训。在《PMBOK®指南》中，这项工作是通过监控项目工作过程来开展的，即通过该过程把变更管理的经验教训及时写进工作绩效报告
              • 考试中可能问你，在某一个情景下，项目经理紧接着该做什么。这就需要你按照本节提示的变更管理程序来判断项目经理已做过什么、接下去该做什么
        • 4.11.4 变更的审批权限
          • 任何人都可以提出变更请求，但不是任何人都有权批准变更的。谁有权批准什么变更，这是与变更管理程序同样重要的问题
          • 变更是项目管理计划内的，不会导致项目基准的修改，项目经理有权做出决定
          • 变更将导致项目目标的修改，即会导致项目基准的修改，项目经理就要判断该变更是否属于紧急情况。
            • 若为紧急情况，项目经理有权先行审批，以后再向变更控制委员会或其他高级管理人员补办审批手续
            • 如果不是紧急情况，且不会导致项目章程的修改，项目经理就要编写变更评审报告，上报给变更控制委员会审批
            • 如果不是紧急情况，且会导致项目章程的修改，就必须上报给项目章程的签发者审批
          • 不影响基准的变更，由项目经理审批。会影响基准的变更，项目经理无权审批，除非是紧急情况
          • 提前终止项目的变更，是项目上可能出现的最大变更，只能由项目发起人审批
        • 4.11.5 变更控制委员会和变更控制系统
          • 变更控制委员会
            • 由项目主要相关方正式组建并派代表参加。项目经理可以是其中的成员，但通常不是主任
            • 该委员会负责审查某些变更请求，批准或否决这些变更请求
            • 对于会影响项目目标（基准）的变更，必须经过变更控制委员会的批准才能付诸实施
          • 变更控制系统
            • 变更控制系统是关于变更管理的一系列正式的书面程序的集合，包括所需文档、跟踪要求和审批层次等
            • 该系统不仅要规定什么变更需要哪个层次的批准，而且可以规定在什么特殊情况下可以不经批准就实施变更
        • 4.11.6 配置管理
          • 配置管理是项目整体变更管理的组成部分
          • 配置是会直接决定项目产品的功能的重要技术参数。为了保证项目产品能够发挥既定的功能，对项目配置及其变更的管理必须十分严格
          • 配置管理通过以下4个步骤来完成：（识别+记录--跟踪--执行+记录与报告--审计）
            • 识别和记录项目产品的重要功能以及为实现这些功能所需的技术参数
            • 跟踪这些参数，控制对这些参数的变更，并记录参数变更情况
            • 按既定的参数（包括变更后的参数）执行项目，并记录与报告参数实现情况
            • 审计项目产品，以确保所有参数都已实现，项目产品能发挥既定功能
          • 配置管理的重点是，确定哪些是核心技术参数，并以特别严格的程序来控制对这些技术参数的变更，确保配置变更可控、在控、可追踪
    • 第5章 项目范围管理
      • 5.1 概述
        • 5.1.1 基本概念
          • 项目范围管理旨在保证做且只做为完成项目所需的全部工作。它关注的焦点是，什么是包括在项目之内的，什么是不包括在项目之内的，以便为项目工作明确划定边界
          • 项目范围管理需要：
            • 明确项目边界，明确什么工作是项目范围内的
            • 明确项目必须提交的全部可交付成果
            • 动态对项目工作进行监控，确保所有该做的工作都做了
            • 动态对项目工作进行监控，防止发生范围蔓延
            • 对不包括在项目范围之内的额外工作说“不”，预防做额外工作（镀金）
            • 及时对项目可交付成果进行实质性验收
          • 范围蔓延（Scope Creep）
            • 是指未经控制的项目范围逐渐扩大。
            • 一方面，项目范围很容易以一种不易察觉的方式逐渐扩大，等到察觉后，项目范围已经发生实质性变化；这就导致项目范围重大偏离
            • 另一方面，项目相关方可能误认为，让项目团队多做事情能增加项目价值，从而不经过既定的申请和审批程序，就随意增加工作内容
          • 范围蔓延导致的结果就是镀金，即做了额外的工作
          • 镀金的项目是失败的，因为用于镀金的资源本可用于更有价值的事情
        • 5.1.2 范围管理的重要性
          • 项目范围管理是项目其他各方面管理的基础。如果范围都弄不清楚，进度、成本和质量等也就无法弄清楚
          • PMI在1983年出版的《ESA研究报告》中首次把项目范围与项目进度、成本及质量一起列作用来定义项目目标的重要维度，而且是第一个维度。在该报告中，“项目范围管理”被正式列为项目管理的一个新功能
        • 5.1.3 产品范围与项目范围：既有联系又有区别
          • 产品范围：指项目将要形成的项目产品的特性和功能
          • 项目范围
            • 指为了完成具有既定特性和功能的项目产品而必须开展的工作
            • 广义的项目范围，由产品范围和狭义的项目范围构成
          • 产品范围是面向客户，项目范围是面向项目团队的
          • 产品范围的变化与项目范围的变化，没有必然的联系
          • PMP®考试中，考项目范围的可能性比较大。考生应该看清楚题目中说的是“产品范围”还是“项目范围”。也有可能考产品范围与项目范围之间的联系和差别。
      • 5.2 各过程的输入与输出
        • 5.2.1 输入与输出的关系总览
          • 项目范围管理的实现过程是规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围
        • 5.2.2 规划范围管理
          • 在项目章程的指导之下，参考项目管理计划中已有的子计划（如质量管理计划）和其他内容（如项目生命周期、开发方法），编制范围管理计划和需求管理计划
          • 这两个管理计划（范围管理计划和需求管理计划）将作为项目管理计划的组成部分，用于指导收集需求、定义范围、创建WBS、确认范围和控制范围过程
        • 5.2.3 收集需求
          • 在项目章程和项目管理计划（如需求管理计划、范围管理计划、相关方参与计划）的指导之下，根据项目文件（如相关方登记册、假设日志）去收集相关方的需求。在收集需求的过程中，需要用商业文件（如商业论证）去引导相关方表述合理的需求。对于为客户做项目的乙方，还需要使用协议（合同）
          • 重复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训
          • 收集来的需求，必须记录下来，形成需求文件，同时编制需求跟踪矩阵
          • 需求文件是定义、管理和控制项目范围的基础，将作为一种项目文件用作定义范围、创建WBS、确认范围和控制范围过程的输入
          • 需求跟踪矩阵是用来动态跟踪、监控需求的实现情况的，将作为一种项目文件用作确认范围和控制范围过程的输入
        • 5.2.4 定义范围
          • 在项目章程和项目管理计划（如范围管理计划）的指导之下，基于前一个过程所得到的需求文件（一种项目文件），依据假设日志（一种项目文件），编制项目范围说明书。项目范围说明书在经高级管理层批准之前，将作为一种项目文件用作创建WBS过程的输入。经批准之后，成为范围基准和项目管理计划的组成部分
          • 在风险管理知识领域分析风险之后，可能要根据风险登记册（一种项目文件）来缩减项目范围，以减轻作为威胁的整体项目风险；或者扩大项目范围，以提升作为机会的整体项目风险
        • 5.2.5 创建WBS
          • 根据项目管理计划中的范围管理计划，以及项目文件中的需求文件和项目范围说明书，编制WBS和WBS词典，并进而形成项目的范围基准（是项目管理计划的组成部分）
        • 5.2.6 确认范围
          • 根据项目管理计划中的范围管理计划、需求管理计划和范围基准，项目文件中的需求文件（含验收标准）、需求跟踪矩阵（含验收方法）和质量报告，以及工作绩效数据，对核实的可交付成果进行实质性验收。验收工作中会形成相关资料，即工作绩效信息如果符合验收标准，就得到验收的可交付成果。如果不符合验收标准，就提出变更请求
          • 重复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训
        • 5.2.7 控制范围
          • 把体现在工作绩效数据中的项目范围实际绩效，与体现在项目管理计划（如范围管理计划、需求管理计划、范围基准、绩效测量基准）和项目文件（如需求文件、需求跟踪矩阵）中的计划要求做比较，得到工作绩效信息
          • 如果绩效偏差太大，就应该根据变更管理计划和配置管理计划（项目管理计划的组成部分）中的规定，提出变更请求
      • 5.3 各过程的主要工作和成果
        • 5.3.1 规划范围管理
          • 在与项目目标直接相关的五大知识领域中，都首先通过“规划××管理过程”编制相关的管理计划（关于管理工作的程序性计划），以便后续根据程序性计划制订实体性计划（关于技术工作的安排）
          • 程序性计划VS实体性计划的对照
          • 规划范围管理过程就是要编制范围管理计划和需求管理计划
            • 范围管理计划
              • 范围管理计划规定定义范围、创建WBS、确认范围和控制范围过程将如何开展。（关于将如何定义、制定、监控和确认产品范围与项目范围的计划）
              • 例如，采用什么流程编制项目范围说明书、工作分解结构WBS和WBS词典？范围基准将由谁来审批？范围变更将按什么流程进行管理？将如何验收可交付成果？
            • 需求管理计划
              • 需求管理计划规定收集需求过程将如何开展。（关于将如何收集、记录、分析和控制需求的计划）
              • 例如，将用什么方法收集什么人的需求？将用什么标准对需求进行优先级排序？需求文件和需求跟踪矩阵将采用什么格式？将如何跟踪需求的实现过程？
        • 5.3.2 收集需求
          • 收集需求过程是根据范围管理计划和需求管理计划，收集项目相关方对项目的具体需求。也就是说，把相关方对项目的需要（needs）、想要（wants）与期望（expectations），转变成具体的项目需求（requirements），并记录下来
          • 收集需求旨在使需求明确化、具体化和书面化。需求必须是可测量的、文档化的
          • 通过需求分析，得到需求文件和需求跟踪矩阵，为项目范围管理奠定坚实基础
            • 需求文件记录项目相关方对项目的各种具体需求（要求）
            • 需求跟踪矩阵则说明具体需求与高层目标之间的对应关系，以及具体需求与细节层次上的项目设计、项目工作和可交付成果之间的对应关系。通过需求跟踪矩阵来确保每个具体需求都有实际意义（为高层目标服务），且都能实现（通过细节层次上的工作）。在项目监控过程中，应该依据需求跟踪矩阵来跟踪（监控）需求的实现情况
          • 为了更好地管理需求，可以把需求归为以下类别：商业+相关方+解决方案+过渡和就绪+项目+质量
            • 商业需求（Business Requirements）：最高层次的、整个组织的需求。它要回答的问题是：“为什么要做某个项目？”
            • 相关方需求（Stakeholder Requirements）:中间层次的、每个或每组相关方的需求。它要回答的问题是：“相关方想要用项目产品做什么？”
            • 解决方案需求（Solution Requirements）：最低层次的、技术方面的需求，是为实现商业需求（Business Requirements）和相关方需求（Stakeholder Requirements），项目产品必须具备的特性和功能。它要回答的问题是：“项目团队必须开发出什么样的项目产品？”。用一定的解决方案去满足相关方需求，并通过满足相关方需求来实现商业需求
              • 功能需求：是项目产品必须实现的功能，关注项目产品能够做什么
              • 非功能需求：用来支持功能需求的。在非功能技术特性的支持下，项目产品的功能 才能正常发挥。非功能需求关注项目产品能够多好地（How well）以及在什么条件下才能发挥既定的功能。
            • 过渡和就绪需求（Transition and Readiness Requirements）：临时性需求，旨在完成某系统从当前状态到未来状态的过渡，使该系统一切就绪。一旦数据迁移完成，这种需求就会自动消失
            • 项目需求（Project Requirements）：对项目过程的需求，如采用什么项目管理方法、在什么时间、用多大成本完成什么工作
            • 质量需求（Quality Requirements）：是项目过程或可交付成果必须达成的质量要求
        • 5.3.3 定义范围
          • 在收集需求过程中收集到的需求，不一定都要在本项目上得到实现。定义范围过程就是确定哪些需求必须在本项目上实现，并基于这些需求编制项目范围说明书，明确项目范围边界
          • 项目范围说明书的主要内容包括：产品范围描述+可交付成果+验收标准+项目除外责任
            • 产品范围描述。细化项目章程和需求文件中的产品范围
            • 可交付成果。项目必须提交的中间及最终可交付成果。以后还要在创建WBS过程中进一步细分
            • 验收标准。可交付成果必须满足的标准
            • 项目除外责任。本项目必须不做什么事情，防止相关方对项目产生不合理的期望
          • 在定义范围过程中，还要细化制定项目章程过程所列出的制约因素和假设条件，更新假设日志
          • 项目经理应该把必须由高层管理人员或职能经理搞定的事情列为假设条件，以便保护自己
        • 5.3.4 创建WBS
          • 创建WBS过程就是用工作分解结构（WBS），把项目范围说明书中的项目可交付成果细分为更小、更便于完成的可交付成果，并在此基础上形成范围基准
          • 1、WBS、WBS词典和范围基准
            • 工作分解结构：顾名思义，是把整个项目逐层分解到较小的、便于管理的要素——可交付成果
            • 除第二层可以是阶段名称，以及在项目管理分支中可出现活动，工作分解结构中每个要素都必须是可交付成果（“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身）
            • 工作分解结构一般应该由产品范围和项目范围构成，项目范围中又包括技术工作和管理工作
            • 工作分解结构中，应专列一条“项目管理”分支，使“项目管理”成为必须完成的工作之一
            • 可交付成果是指为完成项目而必须提交的、可核实的、可测量的项目中间或最终成果，可以是有形或无形的
            • 100%规则：工作分解结构是用来确定项目的总范围的，项目的全部工作都必须包含在工作分解结构中。不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是镀金，这是工作分解结构100%规则的要求--工作分解结构必须且只能包含100%的工作
            • WBS中的任何工作都是必须做的。如果有多余的，必须经过变更控制程序把它去掉，才能不做。WBS之外的任何工作都是必须不做的。如果要做，必须先经过变更控制程序把它加进去
            • 工作分解结构的编制需要全部主要项目相关方和项目团队成员参与
            • 工作分解结构的层次
              • 最高层的要素，是项目名称或最终项目成果
              • 上一个层次的要素则是下一个层次各要素之和
              • 工作分解结构中每条分支的分解层次不必相等
              • 工作分解结构应控制在4-6层。若项目比较在，以至于工作分解结构要超过6层，就应该先把大项目分解成子项目（编制“项目分解结构”），再针对子项目编制工作分解结构
              • 把工作逐层分解，能提高管理效果，但会降低管理效率。如果分解过细，会导致管理工作量增加过多，甚至根本管不过来
            • 逐层向下分解是为了提高时间和成本估算的准确性，更有效地开展项目规划、执行与控制
            • 工作分解结构中，同一层次的各要素应该相对独立，尽量不相互交叉
            • 在编制WBS的同时，应该编制WBS词典，对每个WBS要素进行解释
            • 编制出WBS和WBS词典后，把这两个文件连同项目范围说明书，报给高级管理层审批
            • 经过高级管理层审批的项目范围说明书、WBS和WBS词典，就是项目的范围基准
          • 2、控制账户、规划包和工作包
            • 控制账户
              • 控制账户是用来进行项目范围、进度、成本和质量控制的，工作分解结构某个层次上的要素，既可以是工作包，也可以是比工作包更高层次的要素
              • 控制账户是一种管理控制点，项目经理针对控制账户考核项目执行情况，即在控制账户的相应要素上，把项目执行情况与计划要求进行比较，评价执行情况的好坏，发现并纠正偏差
              • 通常在项目规划阶段，就要确定项目的控制账户。控制账户设在较高或较低层次上，就表明项目经理想要对项目实施“粗管”或“细管”。如果项目遇到严重危机，为了加强控制，项目经理可以临时决定下移控制账户--把更低层的要素定为控制账户
            • PMP®试题中的“控制账户”，一般都是高于工作包的WBS要素。每个工作包只能属于一个控制账户
            • 规划包
              • 规划包是在控制账户之下、工作包之上的WBS要素
              • 规划包只是暂时用于项目计划编制工作。随着情况的明朗，规划包最终将被分解成工作包和相应的进度活动
              • 规划包不能直接付诸执行，必须先分解成工作包
              • 规划包只是暂时的底层要素
            • 工作包
              • 工作包：工作分解结构每条分支底层的要素（没有子要素的要素）
              • 工作包是永久的底层要素
              • 工作包是项目上的最小的可交付成果。把工作包再分解，等到的就不是可交付成果而是进度活动
              • 80小时法则：通常，按2周的间隔来检查项目实施情况，有利于对项目的有效控制（每天工作8小时，每周工作5天）。但并不具强制性
              • 工作包必须小到这样的程度，以至于能够比较准确地对该工作包安排进度、编制预算、识别风险、分配负责人
              • 工作包特征（可交付成果具有以下特征即 为工作包）
                • 规模较小，可在短时间内完成
                • 从逻辑上讲，不能再分了
                • 所需资源、时间、成本等已能较准确地估算，已经能够对其进行有效的进度、成本、质量、范围和风险控制
                • 准备把这部分工作外包出去，且希望由承包者来继续细分。这部分工作就相当于子项目
            • 工作包只是在本WBS中不再细分，但还可以在其他下级WBS中细分（针对子项目），或者由具体负责该工作包的人把工作包再细分为各种进度活动
          • 3、工作分解结构的作用
            • 工作分解结构在项目管理中有极其重要的作用。项目的所有规划、执行、监控和收尾工作都必须基于工作分解结构
            • 编制工作分解结构不仅是一项技术和管理工作，而且是重要的项目团队建设工作
            • 编制工作分解结构的过程，能促使项目相关方尽早提出自己对项目的要求，并有效协调不同的要求
            • 工作分解结构在项目管理中的主要作用如下：
              • 促使人们在尽可能早的时间，就周全地考虑项目范围，防止遗漏或多列某些内容
              • 作为基础性文件，促进项目相关方之间沟通，使他们对项目范围有一致认识
              • 是编制项目进度计划、成本计划、质量计划、风险计划等的基础
              • 是进行项目组织设计的依据之一
              • 是进行项目执行和监控的重要依据
              • 是考核项目是否完工的依据
        • 5.3.5 确认范围
          • 确认范围过程是由项目发起人、客户和其他主要相关方正式验收已经完成并被核实为质量合格的可交付成果
          • 必须在监控阶段完成对各个可交付成果的实质性验收，以便在还有时间解决问题时发现并解决问题。整个项目完工时，再开展项目产品的整体验收（形式验收），办理移交手续
          • 【注意】确认范围与控制质量是不同的，前者注重的是可交付成果的可接受性，而后者注重的是可交付成果的正确性（符合质量要求）。通常控制质量在前，确认范围在后；有时，也可以同时开展
          • 控制质量过程中的“核实”（verify），是核实可交付成果技术上的正确性，是项目团队内部的工作
          • 确认范围过程中的“确认”（validate），是确认可交付成果对项目目标的有用性以及能否通过验收，是项目团队邀请项目发起人和客户来做
        • 5.3.6 控制范围
          • 控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比较，发现偏差，分析偏差，提出解决偏差的建议
          • 通过控制范围过程，防止范围蔓延，管理范围基准变更
          • 控制范围与确认范围都是监控过程组的过程
            • 控制范围是由项目团队在可交付成果的完成过程中开展的
            • 确认范围是由项目发起人或客户在可交付成果完成之后开展
          • 【区别】控制质量、控制范围和确认范围的区别
      • 5.4 各过程的工具与技术
        • 项目范围管理的6个过程中，只有确认范围和控制范围过程中没有“专家判断”这个工作，不再赘述
        • 5.4.1 规划范围管理
          • 项目经理需要邀请相关项目团队成员和主要项目相关方召开会议，来讨论项目范围管理计划、需求管理计划的编制。编制计划，通常都需要召开规划会议。
          • 备选方案分析，作为一种数据分析技术，用于分析收集需求和开展范围管理的多种备选方案，并做出选择
        • 5.4.2 收集需求
          • 《PMBOK®指南》中列出了如下工具：专家判断、数据收集、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法。除专家判断以外，其余这些工具之间存在如下的逻辑关系：
            • 首先，使用数据收集、数据分析、人际关系与团队技能、系统交互图和原型法，收集相关方的原始需求
            • 其次，使用数据表现来分析各种原始需求之间的关系，如因果联系和同类关系
            • 最后，使用决策来确定对需求的归类和排序。
          • 1、收集原始需求：数据收集、数据分析、人际关系与团队技能、系统交互图和原型法
            • 收集原始需求，可以采用2类方法：
              • 一类是分析现有的各种各样的文件。相关方的需求会体现在他们所编制的各种文件中。这就是使用数据分析中的文件分析工具
              • 另一类是现场调查的方法。现场调查的方法又可以分成个人调查法、小组调查法和联系对比法
                • 个人调查法：访谈+问卷和调查+观察
                  • 调查每个人的需求，可以采用数据收集中的访谈、问卷和调查，人际关系与团队技能中的观察
                    • 访谈：访谈者直接问被访谈者有什么需求
                    • 问卷和调查：用事先设计好的问卷或其他调查方法来收集需求
                    • 观察：分为旁站式观察和参与式观察
                      • 旁站式观察：观察者以外人的身份观察相关方有什么需求
                      • 参与式观察：观察者亲自体验做某事，来了解相关方的需求
                • 小组调查法：头脑风暴+焦点小组+名义小组+引导
                  • 调查一群人的需求，可以采用数据收集中的头脑风暴和焦点小组，以及人际关系与团队技能中的名义小组和引导
                  • 这里的引导主要是指召开引导式研讨会，包括联合应用开发、质量功能展开和用户故事会
                    • 引导式研讨会是由主持人引导，邀请不同背景、部门或领域的相关方派代表参加，共同讨论需求，以识别一些跨界需求，并协调需求矛盾
                    • 联合应用开发是软件开发行业常用的引导式研讨会，强调由项目开发团队和用户一起共同定义需求
                    • 质量功能展开在制造行业的新产品研发项目中很常用。它是一种把用户需求转化成产品功能的结构化方法（通常用矩阵表格的形式），以便开发出最能满足用户需求的那些功能
                    • 用户故事会则是参会者一起创建关于相关方需求的故事。故事通常由三部分构成：相关方的角色，相关方想要什么（需求），相关方为什么想要它（想用它获得什么利益）
                • 联系对比法：系统交互图+原型法+标杆对照
                  • 包括系统交互图、原型法以及数据收集中的标杆对照
                    • 系统交互图是指把拟建的特定系统置于大背景中，用图形直观地展示该系统与其他系统之间的接口关系，从而确定该系统应该满足什么需求
                    • 原型法是指通过开发原型、由相关方试用原型并提出反馈意见，来逐渐明确相关方的需求
                    • 标杆对照是用可比项目的最佳实践作为标杆，来确定本项目的需求
          • 2、分析和整理需求：数据表现
            • 使用数据表现中的亲和图和思维导图来分析和整理原始需求
              • 亲和图用于对原始需求进行归类，把具有亲近关系（相似性）的各种需求归为一个更大的需求
              • 思维导图用来找出各种原始需求之间的先后顺序关系、因果关系或隶属关系
          • 3、做出关于需求的决定：决策
            • 使用决策中的投票和多标准决策分析，做出关于需求归类和需求排序的决定
              • 投票是指由一群人基于所有人一致同意、超过50%的大多数人同意或不足50%的相对多数人同意的规则，进行投票表决
              • 多标准决策分析是指用多种标准（如需求的紧急性、实现难易度、成本效益比）对所有需求进行列表分析，排出优先顺序
        • 5.4.3 定义范围
          • 定义范围过程要使用专家判断、产品分析、数据分析中的备选方案分析、决策中的多标准决策分析和人际关系与团队技能中的引导
            • 首先，通过产品分析，确定项目产品应该具备的功能，即明确产品范围
            • 其次，通过备选方案分析，设计和分析可以用来实现既定产品功能的不同项目方案，即明确可供选择的项目范围
            • 再次，用多标准决策分析，对备选方案进行评价和打分
            • 最后，引导项目相关方就产品功能和项目方案达成一致意见
        • 5.4.4 创建WBS
          • 利用分解技术，把项目分解成较小的可交付成果和相关工作。分解可按下面6个步骤进行：识别+分析+排列+编号+检查
            • 识别项目的全部可交付成果。应该用多种方法识别可交付成果，防止遗漏
            • 分析可交付成果之间的从属关系，确定WBS的编排方式
            • 把可交付成果从大到小按隶属关系排列
            • 建立WBS编号系统，对每个WBS要素编号
            • 自下而上检查工作分解是否符合100%规则，做必要修改
        • 5.4.5 确认范围
          • 在对已完成的可交付成果进行实地检查的基础上，由验收小组用决策中的投票技术来决定可交付成果能否通过验收
        • 5.4.6 控制范围
          • 使用数据分析中的偏差分析技术来确定项目范围绩效偏离范围基准的程度和原因。还要使用数据分析中的趋势分析来预测未来的项目范围绩效
      • 5.5 描述项目范围的主要文件
        • 5.5.1 文件种类
          • 用于描述项目范围（广义）的主要文件包括（按编制的先后顺序排列）：
            • 项目章程。其中有初步的产品范围和初步的项目范围
            • 需求文件。用作进一步明确产品范围和项目范围的基础
            • 需求跟踪矩阵。用来追踪项目范围和产品范围的实现情况
            • 项目范围说明书。其中包括产品范围和项目范围，用来确定范围边界
            • 工作分解结构。用来明确必须完成的全部可交付成果
            • 工作分解结构词典。对WBS中的要素进行解释
            • 范围基准。经过批准的产品范围和项目范围
            • 采购工作说明书。即将外包的工作的范围说明书，由买方在编制采购计划时编制
            • 合同工作分解结构。外包工作的WBS，由卖方在签订合同后编制并报买方确认
          • 合同工作分解结构是卖方用来与买方就合同工作范围统一认识的，与卖方内部用的工作分解结构不一定完全相同
          • 项目章程是在项目启动阶段编制的，合同工作分解结构是在项目执行阶段编制的，其他的都是在项目规划阶段编制的
          • 还有2个与范围管理直接相关的文件，即需求管理计划和范围管理计划。它们是项目管理计划的重要组成部分
        • 5.5.2 几个文件的比较
          • 各种范围文件（工作分解结构除外）都在不同程度上包括一些非项目范围的信息
    • 第6章 项目进度管理
      • 6.1 概述
        • 在工作分解结构的基础上，针对交付工作包的需要，列出为完成项目而必须进行的全部活动，然后分析这些活动之间的逻辑关系，估算各活动所需要的持续时间（工期），制订项目进度计划，并随同项目执行对进度绩效进行监控。在开展这些工作之前，须先行编制项目进度管理计划
        • 项目进度管理通过下列6个过程来实现：
          • 规划进度管理。编制作为项目管理计划的组成部分的进度管理计划。进度管理计划是后续各种进度管理工作的依据
          • 定义活动。弄清楚必须做哪些进度活动才能完成工作分解结构中的工作包以及更高层的可交付成果
          • 排列活动顺序。弄清楚活动之间的逻辑关系，并用网络图表述由这些逻辑关系所构成的项目活动的工作流
          • 估算活动持续时间。根据活动属性和可用资源，估算完成每项活动究竟需要多长时间（工期）
          • 制订进度计划。分析并综合前述三个过程的成果，同时考虑对进度安排构成约束的各种制约因素，编制项目进度计划
          • 控制进度。与项目进度计划对照，监督项目进度执行情况，发现进度偏差，预测未来进度绩效，提出必要的变更请求
        • 估算活动持续时间过程与项目资源管理知识领域中的估算活动资源过程存在密切的互动关系，通常需要循环开展这2个过程多次
        • 编制项目进度计划旨在：
          • 弄清楚项目要进行的全部进度活动
          • 弄清楚各活动之间的逻辑（依赖）关系
          • 弄清楚每个活动所需的持续时间
          • 在资源许可的情况下，把可以同时进行的活动尽量同时进行，以缩短工期
          • 找出关键路径上的活动，即那些不允许有任何延误的活动，以便重点管理
          • 找出完成项目的可行的最短时间
        • 必须掌握手工绘制网络图的方法，以及手工计算持续时间（工期）、活动开始与结束时间、浮动时间等的方法
      • 6.2 各过程的输入与输出
        • 6.2.1 输入与输出的关系总览
          • 项目进度管理各过程的输入与输出关系可以概括为如图6-2所示（未考虑事业环境因素、组织过程资产和各种更新）
        • 6.2.2 规划进度管理
          • 在项目章程的指导下，参考项目管理计划中已有的范围管理计划和开发方法，编制进度管理计划。进度管理计划将作为项目管理计划的组成部分，用于指导后续的5个进度管理过程。采用不同的产品开发方法，进度管理方法也会有所不同
        • 6.2.3 定义活动
          • 根据项目管理计划中的进度管理计划，把项目管理计划中的范围基准中的工作包分解成进度活动，得到活动清单、活动属性和里程碑清单。它们将作为项目文件用作后续相关过程的输入
          • 在项目基准被批准后，重复开展定义活动过程，可能提出变更请求，如要求修改工作分解结构
        • 6.2.4 排列活动顺序
          • 根据项目管理计划中的进度管理计划和范围基准，对活动清单（一种项目文件）中的活动，依据活动属性（一种项目文件）进行排序，编制项目进度网络图。需要依据里程碑清单（一种项目文件）在进度网络图中标出里程碑
          • 排列活动顺序时，需要考虑各种假设条件和制约因素，所以会用到假设日志
        • 6.2.5 估算活动持续时间
          • 根据项目管理计划中的进度管理计划和范围基准，以及隶属于项目文件的活动清单、活动属性和里程碑清单，估算活动持续时间，得到持续时间估算和估算依据
          • 需要用到来自项目资源管理知识领域中估算活动资源过程和获取资源过程的相关项目文件，包括资源需求、资源分解结构、资源日历和项目团队派工单
          • 对得到的持续时间估算，需要在风险管理知识领域分析会有多大风险不能在该持续时间内完成活动，分析结果写入风险登记册（一种项目文件）。如果不能按期完成的风险太高或太低，就根据风险登记册在本过程调整持续时间估算
          • 估算持续时间时，需要考虑各种假设条件和制约因素，所以会用到假设日志
          • 重复开展本过程时，需要参考经验教训登记册（一种项目文件）中记录在案的经验教训
        • 6.2.6 制订进度计划
          • 根据项目管理计划中的进度管理计划和范围基准，把本知识领域定义活动、排列活动顺序和估算活动持续时间过程所得到的输出（隶属于项目文件）综合起来，编制出项目进度计划，同时形成配套的支持文件进度数据和项目日历。接着，把高层次进度计划报给领导审批，得到进度基准，进度基准是项目管理计划的组成部分
          • 因为进度计划必须有资源保证，所以还需要用到来自项目资源管理知识领域估算活动资源过程和获取资源过程的相关项目文件，包括资源需求、资源日历和项目团队派工单
          • 编制出进度计划初稿之后，需要通过风险管理知识领域来分析风险，并把分析结果写入风险登记册（一种项目文件）。如果必要，再据此调整进度计划
          • 编制进度计划时，需要考虑各种假设条件和制约因素，所以会用到假设日志
          • 重复开展本过程时：
            • （1）需要参考经验教训登记册（作为一种项目文件）中的经验教训，并可能提出变更请求
            • （2）可能要根据协议调整进度计划
        • 6.2.7 控制进度
          • 把体现在工作绩效数据中的进度实际绩效与体现在项目管理计划（进度管理计划、范围基准、进度基准和绩效测量基准）和各种项目文件（项目进度计划、进度数据、项目日历和资源日历）中的计划要求进行比较，发现进度绩效偏差，并记录在工作绩效信息中，同时，对未来进度绩效做出预测，得到进度预测。如果偏差太大或预测结果不理想，就提出变更请求
          • 重复开展本过程时，需要参考经验教训登记册（一种项目文件）中记录在案的经验教训
      • 6.3 各过程的主要工作和成果
        • 6.3.1 规划进度管理
          • 概述：规划进度管理过程旨在编制进度管理计划，规定项目进度管理工作必须遵守的程序和方法
          • 进度管理计划的主要内容包括：
            • 进度模型的制定方法。用什么方法和工具来制定项目进度模型
            • 版本发布和迭代长度。敏捷型项目各版产品的发布时间，以及所需迭代期固定时长
            • 准确程度。活动及项目的工期估算应该准确到什么程度，允许有多大的误差
            • 计量单位。用什么单位来计算资源的数量、工作的数量及活动的工期，如10个工人、100立方米土石方开挖、30个日历月
            • 组织程序链接。项目的进度管理应该如何与执行组织的管理系统衔接
            • 进度模型（计划）维护。在项目执行过程中，如何把实际进度绩效代入进度模型来更新进度计划
            • 控制临界值。在项目执行中，允许出现的最大进度偏差
            • 绩效测量规则。测量、考核和预测项目进度绩效的规则
            • 报告格式。各种进度绩效报告的格式、内容和报送时间
          • 把有关数据输入进度模型，即可自动生成进度计划。有时，可把进度模型理解成进度计划
        • 6.3.2 定义活动和排列活动顺序
          • 定义活动过程旨在把工作包分解成进度活动，列出进度活动的各种属性，确定将随同一系列进度活动的完成而实现的里程碑
          • 排列活动顺序过程则基于定义活动过程的成果，绘制项目进度网络图。进度网络图用于项目活动排序，表明项目从开始到结束的活动流，是项目各活动之间逻辑关系的图示表达
          • 《PMBOK®指南》提到的2种网络图是节点图和逻辑横道图
            • 节点图，用节点表示活动，用箭线连接活动并表示逻辑关系
            • 逻辑横道图，在传统的横道图上添加用来表示逻辑关系的箭线
            • 在这2种网络图中，可以使用下列4种活动之间的逻辑关系：
              • 完成到开始关系（Finish to Start，FS）。紧前活动完成后，紧后活动才能开始
              • 完成到完成关系（Finish to Finish，FF）。紧前活动完成后，紧后活动才能完成
              • 开始到开始关系（Start to Start，SS）。紧前活动开始后，紧后活动才能开始
              • 开始到完成关系（Start to Finish，SF）。紧前活动开始后，紧后活动才能完成或必须完成
            • 在这些逻辑关系中，可能还有一定的“提前量”或“滞后量”
              • 提前量，是指以紧前活动的完成或开始时间为基点，紧后活动的开始或完成可以提前的时间，用公式表示：FS−3天
              • 滞后量，是指以紧前活动的完成或开始时间为基点，紧后活动的开始或完成必须推迟的时间。用公式表示：FS+3天
            • 活动之间的逻辑关系可能是强制性或选择性的
              • 强制性关系，也叫硬逻辑关系，是由活动的内在性质决定的，如基础建好了才能砌墙壁；项目团队无法改变这种逻辑关系
              • 选择性关系，也叫软逻辑关系，是由项目团队基于自己的经验、偏好、习惯等，自行选择的逻辑关系。软逻辑关系完全在项目团队掌控之中
              • 进行活动排序，要重点针对相互之间具有软逻辑关系的各种活动，以便缩短项目工期
            • 活动之间的逻辑关系可以是外部关系或内部关系
              • 外部关系是取决于项目外部的任何第三方的逻辑关系。是项目内部活动与项目外部的活动之间的逻辑关系，项目团队可以对外部关系施加一定的影响，但通常无法掌握。
              • 内部关系是项目内部两项活动之间的逻辑关系
          • 进度网络图中可能存在路径汇聚或路径分支
            • 路径汇聚是指两条或更多路径汇聚到同一个紧后活动上
            • 路径分支是指一个紧前活动分出两条或更多路径指向两个或更多紧后活动
        • 6.3.3 估算活动持续时间
          • 一个活动究竟需要多长时间才能完成，既取决于活动的性质，也取决于活动的资源配置情况。因此，应该根据活动的性质和资源配置情况来估算活动持续时间
          • 通常，应该先估算出完成某个活动所需的工时数（Amount of Efforts），再根据资源的可用性，计算出该活动所需的持续时间（duration）
            • 例如，某活动需要100个工时，有2个人可用，他们每周分别为项目工作10小时，那么，该活动的持续时间就是：100工时÷20小时/周=5周
          • 考虑到活动面临的风险，估算的结果可以是一个区间，如10±2天。
            • 如果威胁发生，该活动需要12天
            • 如果机会发生，该活动需要8天
            • 估算结果也可以是用概率表示的某个时间段，如有80%的概率在10天内完成
          • 在估算活动持续时间时，通常需要考虑：
            • 收益递减规律。在资源投入到达某个点后，每个单位的投入所带来的产出会逐渐下降
            • 最佳资源数量。选择用于开展某个活动的最佳资源数量。资源数量并非越多越好，一是因为收益递减规律，二是因为相互干扰等其他原因
            • 技术进步。往往可以采用先进技术来缩短活动工期
            • 人员激励。防止人们犯学生综合征（拖延症），或受帕金森定律的影响
        • 6.3.4 制订进度计划
          • 制订进度计划过程，是在进度管理计划的指导下，把定义活动、排列活动顺序和估算活动持续时间等过程的成果综合起来，编制出项目进度计划，并把其中高层次的进度计划报给高级管理层审批，成为进度基准
          • 在编制项目进度计划的同时，需要确定哪些数据是进度数据（Schedule Data），以便将来通过控制这些数据来控制项目进度，或者通过修改这些数据来修改进度计划。在编制项目进度计划的同时，还要编制项目日历，确定项目的工作日和非工作日
          • 项目进度计划通常包括详细进度计划、概括性进度计划和里程碑进度计划，构成从低级到高级、从详细到粗略的层级结构，满足不同层次人员了解项目进度的需要。经高级管理层批准的概括性进度计划和里程碑进度计划，就是进度基准
            • 详细进度计划通常用网络图（常用节点图或逻辑横道图）来表示。进度活动是在详细进度计划中被列出来的最低层级的各项活动
            • 概括性进度计划是针对概括性活动（汇总活动），用传统的横道图编制的。至少2个进度活动所组成的更大的活动。是比详细进度计划更高层次的进度计划
            • 里程碑进度计划，又称主进度计划、控制性进度计划或一级进度计划。里程碑本身没有工期，是项目中的重要时点或事件
          • 在PMP®考试中，应该按如下规则来选择使用网络图、横道图或里程碑图：
            • 如须显示活动之间的逻辑关系、项目从开始到结束的工作流，用网络图
            • 如须了解项目内外部之间的关键接口，用里程碑图
            • 如须向管理层或客户汇报项目进度计划或实际进展情况，用里程碑图或横道图
            • 如须追踪活动进度，用横道图
            • 【总结】优势
              • 网络图的优势是表示活动之间的逻辑关系
              • 横道图的优势是追踪活动进度
              • 里程碑图的优势是概述项目进展情况
        • 6.3.5 控制进度
          • 控制进度过程旨在把实际进度绩效与进度计划中的要求做比较，发现、记录并分析偏差，预测未来的进度绩效，并提出必要的变更请求
          • 控制进度过程与控制成本过程紧密相连，需要借助挣值管理方法来实现
      • 6.4 各过程的工具与技术
        • 6.4.1 规划进度管理
          • 采用数据分析中的备选方案分析，来分析多种可用的进度管理方法、进度计划详细程度、滚动式规划的滚动期和进度计划更新频率，并做出选择。还需要召开会议，采用专家判断
        • 6.4.2 定义活动
          • 采用分解技术，把工作包分解成活动。不是所有的工作包都要一次分解到位，可采用滚动式规划方法对近期要完成的工作包做详细分解，对远期才完成的工作包做粗略分解，以后再逐渐细化。究竟要怎么分解，需要专家判断，还需要召开会议
        • 6.4.3 排列活动顺序
          • 使用紧前关系绘图法绘制进度网络图，通过确定和整合依赖关系来区分强制、选择、外部与内部依赖关系，在进度网络图中须考虑活动之间的提前量和滞后量。项目管理信息系统中的进度计划编制软件有助于更有效地生成进度网络图
          • 紧前关系绘图法（也可译成“前导图法”）用节点表示活动，把活动名称及相关信息表示在节点上，所以又叫节点法（Activity-On-Node，AON）。它用位于节点的一个代号表示一个活动，所以又叫单代号法。节点法用箭线表示活动之间的逻辑关系
          • 还有2种《PMBOK®指南》中没有提及但PMP®考试有可能考到的网络图绘制方法：条件图法和箭线绘图法
            • 条件图法，以图形评审技术（Graphical Evaluation andReview Technique，GERT）为代表。它与其他三种方法的区别：其他三种方法都不允许在网络图中出现“回路”和“有条件的路径（如果什么则什么）”，而条件图法则允许
            • 箭线绘图法（Activity-On-Arrow，AOA）用箭线表示活动，把活动名称及相关信息表示在箭线上。它用位于两个节点的两个代号表示一个活动，所以又叫双代号法。箭线法用节点表示连接活动的“事件”（event）
            • “活动”有持续时间，而“事件”没有持续时间，只是一个时点，作为活动（或阶段）开始或结束的标志
            • 节点法与箭线法的比较
            • “虚活动”是实际上并不存在的虚拟活动，不消耗任何时间或其他资源，只是为了在箭线法中表示逻辑关系
          • 如果项目有不止一个起始工作或结束工作，画网络图时就需要在网络图的两端分别增加一个“起始”节点和“结束”节点，作为网络图的起点与终点
        • 6.4.4 估算活动持续时间
          • 有4种常用的估算技术，即类比估算、自下而上估算、参数估算、三点估算，供项目团队根据具体情况选择使用。还要用专家判断、数据分析、决策和会议
            • 1．类比估算和自下而上估算
              • 类比估算
                • 是一种专家判断的方法，也是一种自上而下估算方法
                • 可以针对项目、阶段或活动，根据过去类似项目、阶段或活动的实际工期，来估算本项目、阶段或活动的工期
                • 使用类比估算，要注意项目、阶段或活动的实质相似性，还需要估算者富有经验
              • 自下而上估算
                • 与类比估算相反的方法，既可以针对整个项目或阶段，也可以针对某个活动
                • 自下而上估算是指先对工作分解结构底层的要素进行估算，再逐层向上汇总
                • 类比估算是指把活动分解成更小的组成部分，先对这些组成部分进行估算，再汇总到整个活动
                • 汇总持续时间时，必须注意各组成部分之间可能存在的时间提前量或滞后量
                • 通常，自下而上估算会比类比估算更加准确
            • 2．参数估算和三点估算
              • 参数估算
                • 是一种数学模型法。基于大量的历史数据，把决定项目、阶段或活动工期的各种参数列出来，找出相互之间的数学关系，建立数学公式（模型）来计算工期
                • 常见的两种参数估算方法是回归分析和学习曲线
                  • 回归分析，是根据一个或多个自变量的数值（参数）来预测一个因变量的数值（工期）
                  • 学习曲线，是指随着产品生产数量的增加，工人能不断学习、积累经验，生产每个单位产品所需要的时间会有规律地逐渐减少
                  • 考试中，如果着眼于项目、阶段或活动整体的相似性来主观估算工期，就是类比估算；如果着眼于各具体参数（如房屋建设的总面积，以及单位面积所需的建设时间）来估算工期，就是参数估算
              • 三点估算法，也叫PERT估算法（Program Evaluation and Review Technique）
                • 在估算活动工期时考虑3种可能的情况（最坏、一般和最好），得出最悲观工期、最可能工期和最乐观工期，再据此计算出期望工期（平均工期）
                • 用PERT法计算工期（T），必须记住下面四个公式（其中P代表最悲观工期，M代表最可能工期，O代表最乐观工期）：
                • 在PMP®考试中，只要题目中没有指明活动工期是呈三角分布的，就要假设呈贝塔分布，采用“PERT公式1”
                • 用PERT公式计算出来的是完成某活动的平均工期，即有50%的可能性在该工期内完成。用正态统计分布图，工期落在平均工期一个标准差（通常用σ表示标准差）之内的概率是68.26%，两个标准差之内的概率是95.46%，三个标准差之内的概率是99.73%
                • 这3个概率是考生必须记住的。如果用一个标准差来估算工期，那工期就是在平均工期加减一个标准差的区间内；如果用两个标准差，则是平均工期加减两个标准差的区间内；如果用三个标准差，则是平均工期加减三个标准差的区间内
                • 例如
                • 计算项目的工期，可把同一条关键路径上的全部活动（假设都是不带提前量或滞后量的完成到开始关系）的平均工期加起来，得到项目的平均工期，然后再把这些活动的方差之和开平方得到项目工期的标准差，从而计算出在指定标准差区间内的相应项目工期区间
                • 各项活动的标准差不能相加，只有方差才能相加
                • 单点估算是只考虑一种最可能的情况，用最可能的工期作为活动的工期估算。单点估算法就是CPM（关键路径）估算法
                • 多点估算，当然要考虑很多种可能性。蒙特卡洛模拟法是一种常用的多点估算法，往往用于整个项目而不是某个活动层面
            • 3．数据分析
              • 数据分析中的备选方案分析，用于分析开展活动的各种备选方案，如自己做或外包，采用不同的资源配置、技术或进度压缩方法
              • 数据分析中的储备分析，用于分析活动、阶段或项目面临的已知和未知风险，以便在持续时间中预留合理的应急储备（应急时间）。
              • 预留进度“管理储备”只能针对整个项目，而不能针对活动或阶段
            • 4．决策
              • 为了提高估算的准确性，可以组织一群人（如团队成员或主题专家），使用决策技术来估算活动工期
              • 对工期估算，必须取得全部人员的一致同意。为了取得一致同意，可能需要经过多轮投票
              • 德尔菲技术也是一种常用的一致同意投票技术
                • 德尔菲技术是用来引导众多专家就某事项达成一致意见的常用方法
                • 使用范围很广，可以用于估算工期、估算成本、识别风险和评价风险等
                • 使用德尔菲技术，必须遵守以下6个规则：
                  • 每个专家只与主持人单线联系
                  • 专家之间完全背靠背，更不能进行讨论。为保证专家提出独立见解，甚至需要把专家分散在不同的物理地点
                  • 专家以匿名的书面形式提出意见
                  • 绝对的一人一票制，且不允许弃权
                  • 必须经过“投票—汇总—反馈”多轮循环。专家匿名投票，主持人收集和汇总意见，向专家反馈汇总情况，专家再次投票……一直到达成一致意见
                  • 在多轮投票中，专家不断修正自己的意见，以使意见逐渐趋于一致。如果后一轮的意见更分散，那就必须立即停止，宣布本次德尔菲技术应用无效
                • 德尔菲技术有助于人们减少偏见和克服个人对结果的不合理影响
              • 德尔菲技术流程
              • 应由直接负责或最熟悉某活动的团队成员来估算活动持续时间，项目经理提供支持和协调
        • 6.4.5 制订进度计划
          • 制订进度计划过程要使用的8种工具
            • 其中6种属于进度网络分析技术，即进度网络分析、关键路径法、资源优化、数据分析、提前量与滞后量、进度压缩。其实，进度网络分析是一个更高层次的术语，包含了后面5种技术。还有2种工具则是项目管理信息系统和敏捷发布规划。项目管理信息系统中主要是用于编制进度计划的软件
            • 各种进度网络分析技术之间的关系
              • 先用关键路径法编制出理论上可行的进度计划
              • 再用资源优化技术把上述计划调整成实际上也可行的
              • 再使用提前量与滞后量和进度压缩来优化进度计划（缩短工期）
              • 对于复杂项目，还需要用数据分析（包括假设情景分析和模拟）来进一步考察进度计划的可行性，进一步优化进度计划
            • 1．关键路径法（最基本）
              • 关键路径法，是指在不考虑资源限制和完工时间强制的情况下，计算各活动及整个项目理论上的开始时间和结束时间
                • 顺推法，从项目的开始时间出发，顺时针推算，计算出各活动的最早开始时间和最早结束时间以及整个项目的完工时间。最早开始或结束时间则是指一项活动可以开始或完成的最早时间
                • 逆推法，再从完工时间出发，用逆推法逆时针推算，计算出各活动的最晚结束时间和最晚开始时间。最晚结束或开始时间是指一项活动必须开始或完成的最晚时间
                • 通常，顺推法的终点就是逆推法的起点，除非发起人已为项目指定完工日期。在后一种情况中，就无须顺推，直接逆推计算即可
                • 关键路径是项目进度计划中总工期最长的路径，决定着项目的最短工期。需要注意的是：
                  • 项目的关键路径至少有一条，可能不止一条
                  • 项目的关键路径可能发生变化，即原来的非关键路径可能变成关键路径，原来的关键路径也可能变成非关键路径
                • 浮动时间
                  • 浮动时间是指在不延误整个项目的情况下一项活动允许延误的时间
                    • 正常情况下，关键路径上的活动，其浮动时间为零
                    • 浮动时间意味着分配资源和安排项目计划的灵活性
                    • 浮动时间等于最晚开始时间减去最早开始时间，或者最晚结束时间减去最早结束时间
                  • 浮动时间的概念：自由浮动时间+总浮动时间+项目浮动时间
                    • 自由浮动时间。一项活动可以延误的时间，而不会导致任一紧后活动不能在最早开始时间开始
                    • 总浮动时间。一项活动可以延误的时间，而不会导致项目不能按期完工。总浮动时间可能等于或大于自由浮动时间
                    • 项目浮动时间。一个项目可以延误的时间，而不会导致项目不能按外界（如客户）要求的日期完工
              • 项目进度管理的2个难点：关键路径可能不止一条，关键路径可能发生变化
              • 关键路径的基本问题
              • PMP®考试中会有进度管理方面的计算题。考生需要掌握如下基本道理：
                • 活动的持续时间是开展该活动所需的工作时间数
                • 活动的开始是指在开工日的上班时间开始
                • 活动的结束是指在完工日的下班时间结束
                • 计算工期，要“彻头彻尾（包头包尾）”
                • 某项活动在紧前活动结束后立即开始，是指在紧前活动结束日的次日的上班时间开始，如果中间有滞后量或提前量，则相应加上或减去该时间
                • 计算某个活动的工期时，不应该考虑提前量或滞后量。但是，计算某条路径或整个项目的工期时，则应该考虑提前量或滞后量
            • 2．资源优化
              • 在用关键路径法编制出理论上可行的进度计划后，就需要考虑资源限制了。应该采用资源优化技术，根据资源限制来调整项目进度计划，或者为了提高资源使用效率而调整项目进度计划
                • 资源平衡（Resource Leveling）：没有足够的资源来实施原来计划的工作任务（出现资源短缺），就需要进行资源平衡
                • 资源平滑（Resource Smoothing）：如果在原计划中各个时段所需要的资源数量起伏太大，就需要进行资源平滑，使各时段所需的资源数相对平稳
                • 广义的资源平衡也包括资源平滑。也就是说，可以把资源平滑看成资源平衡的一种特殊形式
                • 应该先做资源平滑，再做资源平衡
            • 3．提前量与滞后量和进度压缩
              • 实际上可行的进度计划不一定就是最优的，发起人不一定愿意接受，可能还需要优化（缩短工期）。可以通过增加活动之间的时间提前量，或减少活动之间的时间滞后量，来缩短工期。无论是增加提前量还是减少滞后量，都可能导致风险增加。所以，必须同时考虑风险，把风险控制在可接受的程度内
              • 可以使用进度压缩技术，包括赶工和快速跟进
                • 赶工是指在保持活动的工作范围不变的情况下，在单位时间内投入更多的资源，如安排加班或使用额外资源，以加快工作进度。赶工只能针对关键路径上的活动
                • 快速跟进是指把关键路径上本应按先后顺序进行的工作调整为至少部分并行。快速跟进只能针对存在软逻辑关系的活动，可能导致返工风险
                • 【注意】快速跟进不同于并行工程（Concurrent Engineering）。并行工程是指下一道工序的人派代表参加上一道工序，以便加快两道工序之间的衔接（也可能导致两道工序部分并行）
              • 一般情况下，赶工的缺点是直接成本增加，快速跟进的缺点是导致返工风险
              • 快速跟进从形式上看，也是增加2个活动之间的提前量，但其前提是这2个活动本来是应该按先后顺序进行的。而在提前量与滞后量中的增加提前量，针对的是本来就可部分并行的2个活动
              • 如果出现了负浮动时间，不要立即告诉客户或管理层没法按规定时间完工或要求延长工期。项目经理首先应分析可否通过赶工或快速跟进来解决负浮动时间。如果可以，赶工或快速跟进又会给项目带来什么样的影响。项目经理必须是积极主动的，必须首先自己想办法解决问题
              • 如何选择赶工和快速跟进
                • 如果项目风险较低，活动之间主要是软逻辑关系，就选快速跟进
                • 如果赶工只涉及在项目内部调剂资源且不会增加成本，则选赶工，因为赶工不会增加工作的复杂性和项目的风险
              • 优化（压缩）进度计划后，必须重新检查项目的关键路径，因为它可能已经发生变化
              • 压缩工期最不可取的方法是，不加分析而硬性压缩工期的百分之几，简单地要求人员加班工作，或降低质量标准
            • 4．数据分析
              • 有2种常用的数据分析技术：假设情景分析和蒙特卡洛模拟
                • 假设情景分析是假设某种有利或不利情况发生，考察项目进度计划的可行性。有助于合理确定项目的应急储备时间
                • 蒙特卡洛模拟是在电脑上使用软件模拟实施项目很多次，甚至成千上万次，来计算项目的全部可能工期及其概率分布
            • 5．敏捷发布规划
              • 这是适用于敏捷项目的进度计划编制方法：
                • 项目经理先与发起人商定各个产品版本的发布时间（相当于里程碑进度计划）
                • 再与项目团队及发起人商定为实现每一次发布所需的迭代次数和时间（相当于概括性进度计划）
                • 然后，由项目团队编制每个迭代期的进度计划（相当于详细进度计划）
        • 6.4.6 控制进度
          • 在控制进度过程中，首先要考察项目的进度绩效，其次要分析偏差并预测未来绩效，最后要解决不可接受的偏差或可能发生的不利绩效
          • 控制进度过程的7个工具就是围绕这3项工作的。这些工具的使用又需要借助项目管理信息系统中的进度管理软件
            • 用于考察进度绩效的工具包括关键路径法，以及数据分析中的绩效审查、挣值分析和迭代燃尽图。用关键路径法审查关键路径（最长的路径）和次关键路径（第二长的路径）的进度绩效
            • 用绩效审查来考察项目的总体进度绩效
            • 用挣值分析来计算进度偏差、进度绩效指数等指标
            • 用迭代燃尽图来直观地显示已经完成和还剩余的工作量
            • 用于分析偏差的工具包括数据分析中的绩效审查和偏差分析
            • 用于预测未来绩效的工具包括数据分析中的挣值分析和趋势分析。在挣值分析中，可以计算各种预测指标
            • 用于解决问题的工具包括资源优化、提前量与滞后量、进度压缩，以及数据分析中的假设情景分析。出现了进度落后，首先设法在项目内部调剂资源加以解决（资源优化），其次设法通过调整提前量与滞后量来解决，再次通过进度压缩（赶工或快速跟进）来解决，最后用假设情景分析来寻找其他解决方法。如果排序靠前的方法能够解决问题，那么就无须使用后面的方法了
    • 第7章 项目成本管理
      • 7.1 相关基础知识
        • 7.1.1 概述
          • 旨在确保在批准的预算内完成项目
          • 主要关心项目本身的成本，也需要考虑项目决策对今后项目产品使用与维护成本的影响，即需要考虑项目产品的生命周期成本。生命周期成本包括：
            • 项目建设期的建设成本
            • 项目产品运行期的运营和维护成本
            • 项目产品报废时的处置成本等全部成本
        • 7.1.2 考察项目可行性的主要财务指标
          • 现值：是指某笔未来现金在今天的价值，是考虑货币时间价值的结果
          • 未来值：与现值相反的是未来值，如银行存款在一定时期后的本利和
          • 净现值：收入的现值减去支出的现值，就得到净现值。净现值是用来选择项目的一个重要财务指标。从理论上讲，净现值大于零的项目都可以做
            • 在计算净现值时，已经考虑了时间，所以项目工期或投资回收期长短通常不再需要考虑
          • 投资回收期：是指用多长时间能把项目投资收回来，通常是项目建设期加上项目投产后累计运营利润达到投资金额所需的时间
          • 投资回报率：是指项目投产后的年均运营利润与项目投资额之比。投资回报率越高越好。
          • 内部报酬率：是一种特殊的贴现率，即项目净现值等于零时的贴现率。内部报酬率代表着项目产品的盈利能力大小以及抵抗风险能力大小
          • 内部报酬率：是一种特殊的贴现率，即项目净现值等于零时的贴现率。内部报酬率代表着项目产品的盈利能力大小以及抵抗风险能力大小
        • 7.1.3 其他重要的财务概念
          • 固定成本。不随生产量或工作量的变动而变动的成本
          • 可变成本。随生产量或工作量的变动而变动的成本
          • 直接成本。可以直接计入某项目的成本，通常是某项目所专用的资源的成本
          • 间接成本。不能直接计入某项目，而需要在几个项目或该项目与运营之间进行分摊的成本，如总部管理费
            • 直接成本和间接成本的划分会受看问题的层次的影响。如果从整个项目的层次看，全职项目经理的工资是直接成本，但如果从项目内部各工作的层次看，该项目经理的工资又是间接成本（需要由项目内部各项工作分摊）
            • 在PMP®考试中，如果题目中没有明确说“从项目内部的层次看”，就应该“从整个项目的层次看”
          • 机会成本。因为选择一个项目而必须放弃另一个项目，另一个项目可以带来的利益就是这个被选择项目的机会成本
          • 沉没成本。任何已经发生的成本，与是否合理无关。决策是针对未来的，做决策时，不能考虑沉没成本
          • 收益递减规律。在累计投入到达某个点之后，随着投入的连续增加，单位投入的产出会呈现逐渐减少的趋势
          • 边际分析。假设投入连续增加，分析单位投入所能带来的单位产出
          • 折旧。固定资产随时间而产生的逐渐损耗
          • 直线折旧法。每年提取等额的折旧数
          • 加速折旧法。在固定资产使用寿命期内，越是早期，提取的折旧数越大
          • 价值分析或价值工程。价值分析与价值工程经常替换使用，都是指对项目的范围（功能）和成本进行分析，追求功能与成本（价格）之间的更高的性价比
            • 如果一定要区分价值分析与价值工程，为了达到比值更高，价值分析是分子不变（范围或功能）降分母，而价值工程则可以同时改变分子和分母。旨在改进工程设计的合理化建议，是价值工程的典型例子
        • 7.1.4 成本管理的重要做法
          • 项目成本管理必须同时考虑2个方面：
            • 一是项目的每项工作需要多少成本
            • 二是整个项目生命周期中的每个时段（周、月、季）需要多少成本
          • 按工作内容进行的成本管理是依据工作分解结构进行的，而按时间段进行的成本管理是按项目进度计划以现金流量表的形式进行的
          • 项目成本管理与项目进度管理密切相关，许多做法是相通的
          • 编制项目预算，应该采用自下而上的方法，按如下主要步骤进行：
            • 第1步，计算出各活动所需要的成本，包括应急储备
            • 第2步，汇总得出工作包的成本，包括应急储备
            • 第3步，把各工作包的成本汇总，得到控制账户的成本，包括应急储备
            • 第4步，把各控制账户的成本汇总，得到项目的成本，包括应急储备
            • 第5步，对成本汇总的结果（包括应急储备）进行验证和调整，并报领导审批，得到项目成本基准
            • 第6步，增加一定的管理储备，得出项目预算
            • 在自下而上汇总出项目成本之后，需要对汇总的结果进行调整，特别是调整应急储备（第5步）。这种调整又可能导致返回第1步，重新估算活动的成本
          • 还需要注意相关以下相关内容：
            • 工作分解结构和项目进度计划都是进行成本估算的重要基础，以便提高估算的准确性
            • 估算应该由最熟悉相应活动的人来进行，而不是项目经理或管理层（项目早期的自上而下估算除外）
            • 历史资料（组织过程资产）对做好估算工作非常重要
            • 扣除管理储备之后的项目预算，是用于控制项目成本的基准线。除非经过既定的变更审批程序，成本基准不能改变（范围基准、进度基准也是如此）
            • 如果在执行过程中出现了不可接受的成本偏差，必须采取纠正措施
            • 项目经理不能简单、被动地接受管理层对项目的成本和进度要求，而要积极主动地分析项目的实际需要，向管理层提出合理建议
            • 应该为应对风险增加一定的储备（应急资金），但不允许单纯为保护自己而增加“水分”。储备必须明示，不能隐藏着
      • 7.2 各过程的输入与输出
        • 7.2.1 输入与输出的关系总览
          • 项目成本管理的实现过程包括规划成本管理、估算成本、制定预算和控制成本。项目成本管理各过程的输入与输出关系如图所示
          • 7.2.2 规划成本管理
            • 在项目章程的指导下，编制成本管理计划。因为成本管理与进度管理密切相关，所以需要参考项目管理计划中的进度管理计划。项目管理计划中的风险管理计划，有利于确定该如何开展成本管理，以便达到所需的风险管控水平
          • 7.2.3 估算成本
            • 在项目管理计划中的成本管理计划的指导下，估算完成项目工作所需的成本，得出成本估算和估算依据
            • 项目管理计划中的质量管理计划，有利于估算该留出多少钱去管理项目质量。项目管理计划中的范围基准，有利于根据项目的范围大小来估算成本
            • 项目进度计划（一种项目文件）中的活动名称以及活动开展时间，对估算成本有重要影响，因为：
              • ①活动在不同时间开展，成本可能不同
              • ②有些成本（如利息）与活动工期长短有直接关系
            • 资源需求（一种项目文件）有利于估算开展项目工作所需资源的成本。估算成本时，需要考虑风险，故需要风险登记册（一种项目文件）
            • 复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训
          • 7.2.4 制定预算
            • 根据成本管理计划（项目管理计划的组成部分）和商业文件（列有财务指标），把各活动或工作包的成本估算（一种项目文件）汇总成成本基准，并编制配套的项目资金需求文件。汇总时，须参考前个过程得到的估算依据（一种项目文件）
            • 资源管理计划（项目管理计划的组成部分）中的资源性质、资源价格和资源日历，有利于在项目预算中留足用于买资源的钱。范围基准（项目管理计划的组成部分）有利于把预算分配到WBS的各个要素
            • 项目进度计划（一种项目文件）有利于把预算分配到项目的各个时间段，确定每个时间段需要多少钱
            • 对于已经外包出去的工作，需要把协议（合同）中的合同价纳入项目预算；对于打算外包出去的工作，需要考虑预留出多少钱，即预估未来协议中的价格
            • 制定预算时，需要考虑风险，故需要风险登记册（一种项目文件）
          • 7.2.5 控制成本
            • 把体现在工作绩效数据中的成本实际绩效与体现在项目管理计划（成本管理计划、成本基准和绩效测量基准）和项目资金需求中的计划要求进行比较，发现成本绩效偏差，并记录在工作绩效信息中，同时，对未来成本绩效做出预测，得到成本预测。如果偏差太大或预测结果不理想，就提出变更请求
            • 重复开展本过程时，需要参考经验教训登记册（作为一种项目文件）中记录在案的经验教训
      • 7.3 各过程的主要工作和成果
        • 7.3.1 规划成本管理
          • 规划成本管理过程旨在编制一份用来指导后续成本管理工作的成本管理计划。它是项目管理计划的组成部分。成本管理计划的主要内容如下：
            • 测量单位。用什么单位测量项目成本。通常都用货币单位，也可以用非货币单位，如人日数
            • 精确程度。成本估算和项目预算应精确到什么程度，如元、十元、百元或千元
            • 准确程度。成本估算和项目预算应准确到实际成本的正负百分之几，如±5%。项目早期（如启动阶段）的成本估算可以是粗略量级估算，准确性是−25%～+75%；在规划阶段后期的成本预算，应该是确定性估算，准确性是−5%～+10%
            • 组织程序链接。项目成本账应如何与执行组织财务账相连，项目成本管理应如何符合组织财务会计制度的要求，如成本的记账时间和方法
            • 控制临界值。允许出现的最大成本偏差。一旦突破控制临界值，就要采取纠正措施。控制临界值应该随项目进展越来越小
            • 绩效测量规则。主要是挣值管理规则，包括针对哪些WBS要素（控制账户）计算挣值，间隔多长时间计算挣值，采用什么挣值计算方法，如何预测未来成本绩效
            • 报告格式。将来要编制的各种成本管理报告的格式、内容、报送时间等
            • 其他细节。如何处理汇率变动，如何记录成本开支等
        • 7.3.2 估算成本
          • 估算成本过程旨在估算整个项目的成本，或估算各个活动或工作包的成本
          • 在项目规划阶段的中期，工作分解结构和进度计划的初稿编制出来后，就需要用本过程估算活动或工作包的成本
          • 应该由最熟悉相应活动或工作包的人来估算。应该计算所需的全部资源的成本。对于免费使用的资源，也要按合理的数字计算其成本
            • 对于免费使用的资源，也要按合理的数字计算其成本。如果不计算免费资源的成本，就会使成本估算数字失真，无法供以后类似活动或工作包的成本估算工作参考（不会总有免费资源）
            • 对免费资源，随后在计算项目资金需求时就无须考虑。也就是说，如果有免费资源，项目资金需求就会小于项目预算。如果没有，则两者相等
            • 除非特别指明，均默认没有免费资源
          • 在成本估算中，应该包括所有的成本种类，如固定成本和可变成本、直接成本和间接成本，以及应急储备。如果哪种成本没有包括在成本估算中，就必须在估算依据中特别加以说明。不过，管理储备肯定不包括在活动或工作包的成本估算中，这一点无须说明。管理储备只应包括在整个项目的成本估算中
          • 本过程的名称之所以不是“估算活动成本”而是“估算成本”，是因为它可以在项目早期用于粗略地估算整个项目的成本
        • 7.3.3 制定预算
          • 制定预算过程是把各活动或工作包的成本逐层向上汇总，并对汇总结果进行验证和调整，报领导审批，得到项目成本基准；再增加一定的管理储备，得到项目预算。汇总的结果，不一定十分合理，所以需要用其他方法进行交叉验证，并做必要调整。这种调整会导致制定预算过程与估算成本过程之间循环。项目成本基准的准确性必须达到确定性估算的水平
          • 成本基准需要按工作内容分配到各控制账户，需要按时间分配到项目的不同阶段。按时间段分配的成本基准，通常可表现为S形状的一条曲线
          • 非关键路径上的活动有一定的灵活性（浮动时间），是进行资源平衡时首先要利用的。从项目进度的安排来看，我们希望所有活动都在最早开始时间开始，但从现金流的安排来看，我们又希望在最晚开始时间开始这些活动。在最早开始时间或最晚开始时间开始这些活动，特定时点的项目累计成本支出可能有很大差别，形成“香蕉图”。管进度的人会追求最早开始曲线，而管成本的人却会追求最晚开始曲线。
          • 项目预算必须有资金的保证。所以，需要编制项目资金需求文件来配合项目预算。不仅项目整体要有资金保证，而且各WBS要素和各时间段都要有资金保证
          • 项目的成本产生与资金支出不一定同步。如果有预付款，资金支出就早于成本产生；如果有债务（应付未付款），资金支出就晚于成本产生。如果没有免费的资源，在整个项目关闭时，项目总成本与总资金支出应该完全相等
          • 如果没有管理储备，那么项目预算就正好等于成本基准。因为“项目预算”和“成本基准”这两个词经常替换使用，所以在看到“项目预算”时，必须合理判断它的真实意思
        • 7.3.4 控制成本
          • 控制成本过程旨在把实际成本绩效与计划要求做比较，发现、记录和分析成本偏差，对未来的成本绩效做出预测，并提出必要的变更请求。因为成本与进度密不可分，所以控制成本过程与控制进度过程通常是整合在一起开展的，借助挣值管理方法来实现
      • 7.4 各过程的工具与技术
        • 7.4.1 规划成本管理
          • 采用数据分析中的备选方案分析，来分析多种可用的成本管理方法、预算详细程度或资源获取方法（如购买或租赁），并做出选择。还需要召开会议，采用专家判断
          • 备选方案分析也用于考察不同的项目融资方式，确定符合特定融资方式要求的成本管理方法。不同的融资方式，通常对成本管理有不尽相同的要求
        • 7.4.2 估算成本
          • 估算成本过程所使用的工具大多与估算活动持续时间过程相同。对于已经在估算活动持续时间过程中讲过的类比估算、自下而上估算、参数估算、三点估算，以及决策中的投票和数据分析中备选方案分析、储备分析。专家判断和项目管理信息系统
          • 本过程比较特别的工具是数据分析中的质量成本。质量成本是用于质量管理的成本，是活动、工作包或项目成本的重要组成部分。在估算成本时，需要考虑打算花多少钱去做质量管理
        • 7.4.3 制定预算
          • 首先，要运用成本汇总，把活动或工作包的成本逐层向上汇总到控制账户和整个项目
          • 其次，要通过历史信息审核和专家判断来验证汇总结果的合理性，决定是否需要回头调整活动或工作包的成本估算
            • 历史信息审核可以用类比估算或参数估算的方法进行，即用类比估算或参数估算计算整个项目的成本，以便与成本汇总的结果进行比较
            • 如果用各种方法计算出的结果差别较大，就应该认真分析原因，并做必要调整
          • 再次，用数据分析中的储备分析来估算整个项目需要多少管理储备
          • 最后，要对初步确定的项目预算做资金限制平衡，即根据资金限制调整项目预算，确保项目预算有资金保证
          • 在工期较长的大型项目上，往往不可能一次就准备好全部资金，所以需要使用融资工具来分阶段获取项目资金，特别是外部资金
        • 7.4.4 控制成本
          • 专家判断和项目管理信息系统
          • 在控制成本过程中，需要使用数据分析中的储备分析来判断为整个项目、控制账户、工作包或活动所预留的应急储备是否仍然合理。如果不合理，就需要提出调整建议。由于随项目进展，项目的不确定性逐渐降低，因此应急储备通常应该逐渐调减。只有在特殊情况下，才会调增，如项目情况发生了很大的变化，或者原先预留的储备太少
          • 完工尚需绩效指数，以及数据分析中的挣值分析、偏差分析和趋势分析，都是挣值管理中的内容。挣值管理是项目管理的三大核心技术之一，也是PMP®考试的重点之一
          • 项目管理的3大核心技术：工作分解结构、网络计划技术和挣值管理技术
      • 7.5 挣值管理
        • 挣值管理是用来综合考察项目范围、进度和成本绩效的方法，是项目整合管理的要求。挣值管理是一种把范围、进度和成本绩效整合起来考察的方法，就是要在既定的范围之下追求进度和成本绩效的综合最优
        • 挣值管理可以在整个项目、控制账户或工作包层面上进行。这三个层面的挣值管理，道理完全一样
        • 7.5.1 基本概念
          • “挣值”是针对“计划价值”而言的。编制项目计划时，须按不同时点对项目应该完成的工作量及其相应价值制订计划；而后在执行过程中，随着项目的实施，逐渐把“纸面上”的计划价值一点一点地“挣”回来，形成“挣值”——实际上已经实现的价值
          • 学习挣值管理，必须掌握以下基本概念：
            • 计划价值（Planned Value，PV）。截至某时点计划要完成的工作的价值，是计划完成工作的预算价值，可以表示为：计划价值=计划要完成的工作量×预算单价
            • 挣值（Earned Value，EV）。截至某时点实际已经完成的工作的预算价值，是实际已完工作的预算价值，可以表示为：挣值=实际已完成的工作量×预算单价
            • 实际成本（Actual Cost，AC）。截至某时点实际已经发生的成本，是实际已完成工作的实际成本，应该可以在项目的成本账上查到，可以表示为：实际成本=实际已完成的工作量×实际单价
            • 完工预算（Budget At Completion，BAC）。整个项目的成本基准，除非已批准进行变更，完工预算不会变化。如果是针对工作分解结构中的某个要素来计算挣值，那么就是该要素的成本基准
            • 计划价值、挣值、实际成本和完工预算是挣值管理中最基本的概念
        • 7.5.2 计算公式
          • 考察成本绩效的主要指标
          • 考察进度绩效的主要指标
          • 预测未来情况的主要指标
            • 对表中的“完工尚需估算”计算方法，补充说明如下：
              • 如果项目已经发生的成本偏差（绩效指数）是典型的（具有代表性），这种偏差还会在以后继续同样规模地发生，则用“（BAC−EV）÷CPI”计算
              • 如果截至目前的成本绩效和进度绩效都未达到计划要求，而又必须按期完工，则用“（BAC−EV）÷（CPI×SPI）”计算，其中的“CPI×SPI”的结果又称“关键比率”（Critical Ratio，CR），用来考核成本与进度的综合绩效。背后的道理是：以后将以成本增加为代价进行赶工，以便按期完工
              • 如果项目已经发生的成本偏差（绩效指数）是非典型的，这种偏差以后不会发生，且以后的工作能够完全照预算进行，则用“BAC−EV”计算
              • 如果不属于上述三种情况，则可以采用自下而上的方式全新地估算一个数字。全新估算的数字通常更加准确，但是进行估算需要花费额外的时间和成本
              • 在预测未来绩效时，只要题目中没有明示项目过去已发生的偏差属于“非典型”，则一律按“典型”来考虑
          • 还可以总结出以下几点：
            • 在计算偏差的公式中，EV总是出现在公式的第一位
            • 在计算指数的公式中，EV总是作为分子出现
            • 在计算偏差时，正的结果是有利的，负的结果是不利的，零是正好符合计划
            • 在计算指数时（完工尚需绩效指数除外），大于1的结果是有利的，小于1的结果是不利的，1正好符合计划
            • 除了BAC，其他计算都要考虑“截至或在某个时点”
            • 除非成本基准线发生了变化，BAC在整个项目执行期间保持不变
          • 在挣值管理中，既可以计算某个时段（报告期）的挣值指标，也可以计算从开工截至目前的累计挣值指标
          • 只要题目中未指明要计算某个时间段的指标，就要计算自开工以来累计的指标
          • 在挣值管理中，既可以针对整个项目计算各种挣值指标，也可以针对某些工作分解结构要素（如控制账户）计算各种挣值指标。应该事先规定将针对工作分解结构中的哪些要素计算各种挣值指标。至少要针对控制账户计算
          • 为了连续动态地跟踪项目进展情况，应该规定计算各种挣值指标的时间间隔，如每个月计算一次
        • 7.5.3 已完工作量的测算方法
          • 测算已完工作量，应该把活动分成下列3种类型：
            • 独立型活动（Discrete Effort）。可独立开展的、直接导致项目产品形成的活动，其已完工作量可以准确地测量并计算出来。例如，在砌墙项目中，建筑工人的砌墙活动
              • 对于独立型活动，可以用下列方法测量已完工作量：
                • 完成百分比法。实际测量已完工作量，并计算已完工作量占总工作量的百分比
                • 加权里程碑法。对控制账户或工作包规定进度里程碑及相应权重，某个里程碑实现了，就视为完成了多少工作量
                • 固定公式法。在控制账户或工作包开始时计算某个百分比的已完工作量，在控制账户或工作包完工时再计算剩余百分比的已完工作量
                  • 如果没有办法或不需要准确测量控制账户或工作包的实际完成状况，而只能或只须大概估计一下，就应该使用固定公式法。固定公式法中最常用的是50/50规则
                  • 工作一旦开始，就视为已完成50%的工作量；然后，在工作的整个执行期间不计算任何已完工作量，要等到工作全部完成，才计算另外50%的已完工作量
                  • 根据需要，50/50规则也可以被修改成30/70规则、20/80规则、10/90规则甚至0/100规则
            • 依附型活动（Apportioned Effort）。无法独立开展，而是依附于独立型活动，会间接导致项目产品形成的活动，其完成情况按独立型活动的完成情况的同样百分比来计算。独立型活动完成了百分之几，依附型活动也就完成了同样的百分之几。例如，砌墙项目的监理工作
            • 支持型活动（Level of Effort）。与项目产品形成无关，对独立型和依附型活动起支持作用的后勤工作，其完成情况按日历时间的流失来计算。只要日历时间过掉了，应该完成的支持型活动就视为全都完成了。例如，厨师为砌墙工人和监理工程师做饭
              • 支持型活动不会出现进度偏差，既不会进度提前，也不会进度落后
          • 一般情况下，不要直接用已经消耗的材料、人工等的数量占计划的全部数量的百分比来报告项目的进展情况
        • 7.5.4 挣值管理练习（略）
    • 第8章 项目质量管理
      • 8.1 相关基础知识
        • 8.1.1 质量管理概述
          • 项目质量管理旨在保证项目达到既定的质量要求，保证项目产品能够发挥既定的功能，从而满足项目相关方的特定需求。它包括制定和执行质量政策、质量目标和质量职责等
          • 质量管理不仅是一系列技术的应用，而且更重要的是，人们必须具备一系列特定的理念。质量管理，不仅是技术问题，更是理念（价值观）问题
          • 项目质量管理的许多理念和做法与一般的质量管理相同。项目质量管理既包括对项目的产品（结果）的质量管理，也包括对项目的管理工作的质量管理
        • 8.1.2 质量的概念
          • 质量是产品、服务或成果用于满足用户明示和潜在需求的全部特性和功能的总和。这个定义很全面，但是不太可操作
          • 质量是指达到技术要求和适合用户使用。这个定义不全面，但更可操作
          • 与项目范围管理反对镀金一样，项目质量管理也反对镀金
          • 好质量的产品是符合要求的适用产品，而不是超过要求的优质产品
          • 对项目团队外部的相关方（如项目发起人），项目经理对整个项目的质量承担最终责任
        • 8.1.3 有效的质量管理做法
          • 最重要的是，在整个组织中建立和维护优秀的质量管理文化，使每个人在每个环节都自觉地确保工作过程的质量和工作成果的质量
          • 在进行项目规划和产品设计时，必须认真考虑对工作过程和工作成果的质量要求，把质量融入项目规划和产品设计中。
          • 在项目执行和产品开发中，必须严格执行事先规划和设计的工作过程，并做必要的持续改进来保证质量。
          • 在交付工作成果之前，必须进行适当的检查以发现和纠正缺陷。在工作成果交付之后，还要通过用户调查等方法来了解客户满意度，包括发现和解决可能存在的产品缺陷。这都属于质量控制。
        • 8.1.4 重要的质量管理理念
          • 第一次就把事情做对。这才是最节约成本的方法，因为可以避免返工、避免废品等。
          • 质量是免费的。使质量合格所得到的回报，通常都要大于所付出的代价。
          • 预防胜于检查。
          • 持续改进或凯思恩（Kaizen）。这两个词的意思相同，后者是日本语中的“改善”的音译。通过持续不断的小改进积累成大改进，往往比瞬间的大改进更有价值。
          • 准时制（零库存）管理（Just In Time，JIT）。它本来是一个用来降低库存成本的方法，是财务会计中的概念，但也可以用来促进质量管理水平的提高。
          • 全面质量管理（Total Quality Management，TQM）。强调全过程的质量管理和全员参与质量管理。整个生产过程中的每个环节都要做好质量管理，任何一个环节出错，产品质量就会出错。
          • 管理者对质量负85%的责任，而工人只有15%的责任。
      • 8.2 各过程的输入与输出
        • 8.2.1 输入与输出的关系总览
        • 8.2.2 规划质量管理
          • 在项目章程的指导下，根据项目管理计划中已有的内容，以及多种项目文件来编制质量管理计划和质量测量指标。质量测量指标是对质量管理计划中的高层级质量标准的具体化。
          • 项目章程中的项目目标、项目成功标准、项目审批要求等内容，都会对编制质量管理计划和质量测量指标有直接影响。
          • 项目管理计划的各个组成部分对本过程的作用为：
            • 需求管理计划有利于把质量管理的方法与需求管理的方法协调起来。
            • 风险管理计划有利于明确该如何管理与质量有关的风险。
            • 相关方参与计划有利于引导相关方合理参与质量管理计划和质量测量指标的制订。
            • 范围基准有利于针对每个WBS要素制定质量测量指标。
          • 以下项目文件对本过程的作用为：
            • 假设日志。需要考虑各种假设条件和制约因素。
            • 需求文件。其中包含的需求及其验收标准，对确定质量管理方法和质量测量指标有直接影响。
            • 需求跟踪矩阵。其中的需求验收方法（如测试场景），对确定质量检查方法有直接影响。
            • 相关方登记册。有利于识别对质量管理和质量标准有特别要求的相关方。
            • 风险登记册。在确定质量标准和质量测量指标时，必须考虑风险。
          • 实际上，项目管理计划中的范围基准、进度基准和成本基准，都会直接影响质量标准和质量测量指标的确定，只是《PMBOK®指南》中没有列全。
        • 8.2.3 管理质量
          • 管理质量过程的输入与输出：
            • 执行质量管理计划（项目管理计划的组成部分）中规定的质量管理活动。
            • 按质量测量指标（一种项目文件）把质量做合格。
            • 把质量标准和质量测量指标转化成测试与评估文件，供控制质量过程使用。
            • 根据风险报告（一种项目文件）动态评审实现项目质量目标的机会和威胁，以便提出必要的变更请求（如调整质量管理方法或质量测量指标）。
            • 根据质量控制测量结果（一种项目文件）反思质量管理体系的合理性，以便提出必要的变更请求。
            • 重复开展本过程时，需要参考已记进经验教训登记册（一种项目文件）的质量管理经验教训。
            • 根据各种资料编制质量报告，向项目相关方报告项目质量绩效。
        • 8.2.4 控制质量
          • 控制质量过程的输入与输出：
            • 把体现在工作绩效数据中的质量实际绩效，与体现在质量管理计划（项目管理计划的组成部分）和质量测量指标（一种项目文件）的计划要求进行对比，得出质量控制测量结果
            • 检查项目工作或成果的质量时，需要使用测试与评估文件（如其中的质量测试程序）
            • 对已经完成的可交付成果进行质量检查。如果质量合格，就得到核实的可交付成果；如果不合格，就提出变更请求
            • 检查已批准的变更请求的执行情况，把检查结果写入质量控制测量结果（是否已执行到位及其原因）
            • 把质量控制测量结果、工作绩效数据和项目计划要求综合起来分析，得出工作绩效信息。如果工作绩效信息不理想，就提出变更请求
      • 8.3 各过程的主要工作和成果
        • 8.3.1 规划质量管理
          • 规划质量管理过程旨在确定项目的质量标准，并决定如何通过管理质量过程与控制质量过程来达到这些标准。这些内容会包含在质量管理计划和质量测量指标中
            • 质量管理计划描述将如何在执行组织的质量政策的指导下开展质量管理工作，以便达到项目的质量要求。
            • 质量管理计划将作为项目管理计划的组成部分，用来指导管理质量和控制质量过程
            • 质量测量指标是对质量管理计划中的高层级质量标准的具体化和可操作化
          • 质量管理计划的主要内容包括：
            • （1）项目的质量政策。可以直接引用组织的质量政策，也可以对组织的质量政策略加修改
            • （2）项目的质量目标。包括项目的总体质量要求和高层级质量标准，如项目必须符合某个行业标准中的规定
            • （3）质量角色和职责。谁应该对项目质量承担什么责任
            • （4）质量管理程序、活动和工具。用于履行职责和实现目标的程序、活动和工具
            • （5）对工作过程和成果的质量评审。哪些工作过程和成果必须接受质量评审？将如何进行质量评审？将如何利用评审结果？
          • 规划质量管理过程不仅要编制程序性计划（质量管理计划），而且要编制实体性计划（质量测量指标）
        • 8.3.2 管理质量
          • 管理质量过程是把质量管理计划中的内容细化成可执行的质量管理活动，并加以执行，以在项目上落实组织的质量政策。在管理质量过程中，要做以下五件主要工作：
            • （1）让主要相关方确信项目将会达到质量要求，从而能够满足他们的需要、期望和需求
            • （2）执行（包括细化后执行）质量管理计划中规定的质量管理活动，确保项目工作过程和工作成果达到具体质量测量指标和高层级质量标准
            • （3）编制将用于质量控制的质量测试与评估文件。这是把质量标准和质量测量指标转化成质量测评工具（如质量核对单）
            • （4）根据质量管理计划和质量控制测量结果（实际质量绩效），提出变更请求，实现过程改进
            • （5）根据质量管理计划、质量测量指标、本过程的实施情况，以及质量控制测量结果，编制质量报告
          • 每个人都需要参与管理质量过程，包括项目经理、项目团队成员、执行组织的管理人员，甚至客户
        • 8.3.3 控制质量
          • 控制质量过程旨在检查具体的工作过程或可交付成果的质量，并记录检查结果，确定是否符合质量测量指标和高层级质量标准。如果不符合，则要找出原因，并提出纠偏建议（针对工作过程）或缺陷补救建议（针对可交付成果）
          • 本过程要做以下4件事情：
            • （1）检查具体的工作过程的质量，并记录检查结果（质量控制测量结果）
            • （2）检查已完成的可交付成果是否符合质量要求（技术上是否正确），并记录检查结果（质量控制测量结果）
            • （3）检查已批准的变更请求是否实施到位，并记录检查结果（质量控制测量结果）
            • （4）基于前述检查结果和相关计划，整理出工作绩效信息，并提出变更请求
          • 质量控制往往由专门的质量控制人员或质量控制部门来做
        • 8.3.4 三个过程之间的关系
          • 控制质量过程提出的“变更请求”是要求解决具体的工作过程或可交付成果中存在的质量问题，而管理质量过程提出的“变更请求”则是要求修改质量管理体系
          • 这三个过程之间的关系可以简述为：
            • （1）在规划质量管理过程中，建立质量管理体系，包括质量标准、质量测量指标，以及将如何实现
            • （2）在管理质量过程中，执行质量管理体系
            • （3）在控制质量过程中，检查质量管理体系的执行结果
            • （4）在管理质量过程中，根据控制质量过程的检查结果以及规划质量管理过程编制的计划，评价质量管理体系的合理性，提出变更请求（改进建议）
            • （5）在变更请求（改进建议）被批准之后，回到规划质量管理过程修改（完善）质量管理体系
          • 《PMBOK®指南》中，把旧版中的“实施质量保证过程”改成了“管理质量过程”, 质量保证和质量控制的主要区别
      • 8.4 各过程的工具与技术
        • 8.4.1 规划质量管理
          • 本过程的工具可以概述为：
            • 先使用数据收集来收集数据，再使用数据分析来分析数据，最后使用决策来做出关于质量管理方法、质量标准和质量测量指标的决定。
            • 整个过程中，需要借助专家判断，附加开展测试与检查规划（策划将如何开展质量测试和检查）
            • 整个过程中，需要使用数据表现，借助一些可视化图形技术来更有效地规划质量管理。必要时，召开会议
          • 1．数据收集
            • 访谈项目相关方、主题专家和团队成员等，了解他们对质量管理、质量标准和质量测量指标的意见。也可以召集相关人员进行头脑风暴
            • 用标杆对照的方法，收集可比项目的质量管理做法、质量标准和质量测量指标，作为本项目的标杆
          • 2．数据分析
            • 通过成本效益分析，了解各种不同质量管理方案或质量标准所需的成本和能产生的效益。在确定质量标准时，应该考虑实现质量标准所需的成本及带来的效益。可以用边际分析的方法，确定最佳质量标准。边际效益等于边际成本时的质量标准是最佳的
            • 列入工具与技术的“质量成本”其实是“质量成本分析”
            • 通过质量成本分析，了解各种可能的质量成本组合方案（不同种类的质量成本各占多大比重）。质量成本是为达到产品或服务的质量标准而付出的所有努力的总代价，也就是用于质量管理的成本
            • 质量管理是需要花钱的，在确定质量标准时应该考虑愿意花多少钱去做质量管理。较高的质量标准往往需要较高的质量成本
            • 质量成本中既包括为保证质量符合要求所做的工作的成本，即一致性成本；也包括因质量不符合要求而产生的成本，即不一致性成本
            • 质量成本的另一种常见分类方法，是把成本分成预防成本、评估成本和失败（缺陷）成本
              • 预防成本是预防项目发生质量问题的成本，如质量计划编制、人员培训、设计复核等。用于规划质量管理与管理质量的成本都属于预防成本
              • 评估成本是检查产品或生产过程，确认它们是否符合要求而发生的成本，如检查和测试成本。用于质量控制的成本属于评估成本
              • 失败成本是进行缺陷补救所发生的成本，以及因质量缺陷而遭受的其他损失，又可分为内部失败成本和外部失败成本
                • 内部失败成本：前者是指在产品交给客户之前，在项目内部处理缺陷所产生的成本
                • 外部失败成本：后者是指产品交给客户之后，而产生的缺陷处理成本、产品召回成本和信誉损失成本等
            • 预防成本和评估成本属于一致性成本，而失败成本则属于不一致性成本
          • 3．决策：多标准决策分析
            • 借助多标准决策分析技术，用一系列标准（可带不同权重）对各种质量管理方法、各种质量标准或各种质量测量指标进行打分，排出优先级顺序，并据此选择排序靠前的方法、标准或指标
          • 4．数据表现：流程图+逻辑数据模型+矩阵图+思维导图
            • 流程图：用流程图描述一个生产过程怎样从开始走到结束，以及中间各步骤之间的相互关系，有助于分析生产过程中的哪个或哪几个环节最容易出现质量问题
            • 逻辑数据模型（Logical Data Model）：常用于数据库开发的一种可视化技术。
              • 逻辑数据模型其详细程度介于概念数据模型（Conceptual Date Model）和实物数据模型（Physical Date Model）之间
                • 概念数据模型只显示概念之间的逻辑关系。逻辑数据模型则在概念之下添加了一些细节信息
                • 实物数据模型则进一步添加用于实现这些细节的技术信息。逻辑数据模型有利于防止数据不完整
                • 如果删去任何一条逻辑关系线，就会导致最后的数据不完整
            • 矩阵图：用于考察各种质量指标之间的相互关系，或者质量指标与影响因素之间的关系
              • 有以下6种常用的矩阵图：
                • 屋顶形。用于表示同属一组变量的各个变量之间的关系
                • L形。通常为倒L形。用于表示两组变量之间的关系
                • T形。用于表示一组变量分别与另两组变量的关系。后两组变量之间没有关系
                • X形。用于表示四组变量之间的关系。每组变量同时与其他两组有关系
                • Y形。用于表示三组变量之间两两关系。每两组变量之间都有关系
                • C形。用于表示三组变量之间的关系。三组变量同时有关系
            • 思维导图用于把各种条件、因素等与某个核心质量要求联系起来，特别适合做个人或群体的发散性思考
        • 8.4.2 管理质量
          • 管理质量过程的工具，从数据收集和数据分析到决策和数据表现，这些大类与规划质量管理过程一致。但是，大类下面的具体技术并不完全相同。本过程还有审计、面向X的设计、问题解决和质量改进方法
          • 数据收集和数据分析
            • 因为在管理质量过程中需要收集客观数据，所以就没有用规划质量管理过程中的头脑风暴和访谈。在本过程，可以用核对单收集数据，反映该做的事情是否已做，又是否已做到符合要求
            • 数据分析中包括备选方案分析、文件分析、过程分析和根本原因分析
              • 备选方案分析用于分析多种可选的质量活动实施方案，并做出选择
              • 文件分析用于分析质量控制测量结果、质量测试与评估结果、质量报告等，以便判断质量过程的实施情况好坏
              • 过程分析用于把一个生产过程分解成若干环节，逐一加以分析，发现最值得改进的环节
              • 根本原因分析用于分析导致某个或某类质量问题的根本原因（系统原因）
            • 这些数据收集和分析技术也可用于控制质量过程
          • 决策
            • 可用多标准决策分析技术来对多种质量活动实施方案进行排序，并做出选择
          • 数据表现
            • 数据表现中包括亲和图、因果图、流程图、直方图、矩阵图和散点图
              • 亲和图用于对导致质量问题的各种原因，根据其亲近关系进行归类
              • 因果图，也叫鱼刺图或石川图，用来分析导致某一结果的一系列原因；有助于人们进行创造性、系统性思维，找出问题的根源。它是进行根本原因分析的常用方法
              • 流程图用于完整地分析某个或某类质量问题产生的全过程
              • 直方图是一种显示各种问题分布情况的柱状图。每根柱子代表一个问题，柱子的高度代表问题出现的次数
              • 矩阵图，如前文所述。
              • 散点图，用X轴表示自变量，Y轴表示因变量，定量地显示两个变量之间的关系，是最简单的回归分析。所有数据点的分布越靠近某条斜线，两个变量之间的关系就越密切
            • 这些数据表现技术也可用于控制质量过程
          • 审计
            • 质量审计旨在对质量管理活动进行独立的、结构化的审查，以便总结质量管理方面的经验教训
              • 独立的审查是指审计人员应该不受干扰地开展工作，提出意见
              • 结构化审查是指按事先规定的审查程序、方法和内容进行审查
          • 面向X的设计
            • 面向X的设计中的X既可以是卓越（Excellence）的意思，也可以是产品的某种特性，如可靠性、可用性、安全性、经济性。前者追求整个产品在整个生命周期中的最优化，后者重点改进产品的某个特性
          • 问题解决和质量改进方法
            • 问题解决是指用结构化的方法从根本上解决在控制质量过程或质量审计中发现的质量管理问题。从定义问题、识别根本原因，到形成备选解决方案、选择最好的方案，再到实施选定的方案、核实解决效果
            • 在管理质量过程中，要基于过程分析的结果，用质量改进方法去做过程改进。过程改进旨在使生产过程更加顺畅、稳定，减少生产过程中的浪费或（和）降低产品缺陷率。可以用来做过程改进的方法有很多，如戴明环、六西格玛、精益生产、精益六西格玛等
        • 8.4.3 控制质量
          • 控制质量过程的工具包括数据收集、数据分析和数据表现，还有检查、测试或产品评估，以及会议
          • 1．数据收集
            • 在检查质量时，可用核对单和核查表收集客观数据。核对单用于打勾，了解哪些要求已经或没有达到
            • 用统计抽样从全部产品中抽取少量样本进行检查，并根据样本的情况推论出总体（全部产品）的情况
            • 通过问卷和调查，收集客户对产品质量的满意度，以及客户在产品使用过程中可能已经发现的质量缺陷
          • 2．数据分析
            • 通过绩效审查，分析实际质量绩效偏离计划要求的程度和原因
            • 用根本原因分析找出导致某个具体质量缺陷的根本原因
          • 3．数据表现：因果图、直方图、散点图和控制图
            • 直方图（常用来控制质量）
              • 即帕累托图。帕累托图是“二八定律”（20%的原因导致了80%的问题）的图示，用来对导致问题的各种原因按发生频率从高到低排序（频率最高的排在最左边），以便人们集中精力处理最关键的少数（约20%）原因
            • 控制图
              • 用控制图按一定的时间间隔检查和记录质量情况，考察一个过程是否稳定。在规划质量管理时，需要确定图中目标值、控制上下限、规格上下限的位置，以及质量检查的频率。在控制质量过程中，用控制图来检查过程的质量和成果的质量
              • 关于控制图的一些重要概念如下：
                • 控制上限和下限
                  • 通常用两条虚线表示，是需要或不需要采取纠正措施的分水岭。如果质量偏差落在控制上限和下限之内（七点规则的情况除外），项目执行过程就是受控的，不需采取纠正措施。如果落在控制上下限之外，项目执行过程就失控了，就需要调查原因并采取纠正措施。对于重复性的过程，控制上限和下限通常设在正负三个标准差
                • 目标值
                  • 位于控制上限和下限中间的那条线，表示允许的偏差或绩效的平均值
                • 规格上限和下限
                  • 客户要求、合同规定或法律规定的质量底线。控制上限和下限是项目管理团队自行设计的，而规格上限和下限则来自客户、合同或法律的硬性要求。质量偏差只要在规格上限和下限之内，哪怕超出了控制上限或下限，产品质量仍然是合格的，不需要缺陷补救。一旦质量偏差突破规格上限或下限，产品就是不合格的，必须进行缺陷补救。规格上限和下限通常是控制上限和下限之外的两条线，用实线表示
                  • 控制限是系统的声音（Voice of System），规格限则是客户的声音（Voice of Customer）。前者是项目经理根据一般的统计原则计算出来的，后者是客户要求的
                • 过程失控
                  • 如果偏差超出了控制上限或下限，或者虽然在控制上限与下限之内，但是偏差分布具有非随机特性，那么，从统计意义上讲，项目执行过程失控了，就应该调查原因并采取相应措施予以纠正
                • 七点规则
                  • 与“二八定律”相似的经验式规则。如果连续七个观测值都落在控制图目标值线的同一边（即便都在控制上限与下限之内），或者在目标值线两边呈同方向变动（越来越高或越来越低），那么也应该认为这种数据分布是“非随机”的，意味着执行过程失控了，需要及时调查原因并采取纠正措施。由随机原因引起连续七个点都落在同一边或呈同方向变化的概率是非常低的，以至于我们宁愿相信是非随机原因（特殊原因）引起的
                • 非随机原因或特殊原因
                  • 控制图中任何需要调查分析的观测值，都是非随机原因引起的，如七个观测点在同一边或呈同方向变动、任一观测点超过控制上限或下限。非随机原因引起的偏差，意味着项目执行过程失控
                    • 随机原因或普遍原因。系统本身的内在特性决定的、可预测的偏差来源
                    • 任何随机原因引起的偏差都是可接受的，不意味着过程失控；任何非随机原因引起的偏差都是不可接受的，都意味着过程失控
              • 结果失控（超出规格上限或下限）往往是过程失控（超出控制上限或下限，或其他非随机的变化）长期得不到解决而必然导致的。控制图的一个重要意义是：提醒人们在还有时间解决问题时发现问题并采取措施，即在结果失控之前就及时发现和解决过程失控
              • 运用控制图，能够及时监测到项目执行过程的失控，即何时出现了非随机原因引起的偏差。但单纯依靠控制图，还不能知道为何失控。要探究失控背后的原因，还需要借助因果图、流程图等其他工具
              • 质量控制图及一些重要跟踪点的含义图示
          • 4．其他工具
            • 开展实地检查以及测试或产品评估，核实可交付成果的质量是否合格。不同行业的项目，检查或测试方法可能有很大区别
            • 召开会议，确认已批准的变更请求是否已经实施到位，也可回顾和总结质量管理方面的经验教训
      • 8.5 统计概念和质量管理大师
        • 8.5.1 统计概念
          • 概率
            • 某件事发生的可能性大小，如1%
          • 随机抽样
            • 总体中的每个个体都有等同的机会（概率）被抽中
          • 统计上的独立性
            • 两个事件之间没有任何联系，前一事件的结果丝毫不会影响后一事件的结果
          • 统计上相互排斥
            • 在同一次实验中，两个结果不可能同时出现。相互排斥，是在同一次实验中；而相互独立，则是在不同的实验中
          • 【注】相互排斥，是在同一次实验中；而相互独立，则是在不同的实验中
          • 六西格玛管理
            • 西格玛是标准差的符号。六西格玛管理就是六个标准差管理，是指质量管理要达到这样的高水平：每生产100万个产品，只有3.4个有质量问题。合格率达到了99.9997%
          • 均值、中位数和众数
            • 均值是所有测量数据的算术平均值、
            • 中位数是指区分上下各50%的数据数目的分界点（所有数据从小到大顺序排列）
            • 众数是指在所有数据中出现次数最多的那个数据
            • 通过把各数据与均值比较，而不是与中位数或众数比较，计算标准差
          • 边际分析
            • 分析单位质量改进能够产生的效益增加或需要支付的成本增加。最佳的质量应该是效益增加和成本增加相等时的质量
        • 8.5.2 质量管理大师
          • 戴明（Deming）。重要贡献包括戴明环、质量管理14条、持续改进、预防胜于检查等
          • 朱兰（Juran）。强调“质量是适合使用”，提出质量与等级的区别，提出质量管理三部曲（质量规划、控制和改进）
          • 克劳斯比（Crosby）。强调“质量是符合要求”，提出零缺陷和第一次就把事情做对，提出质量可以用不一致性成本来衡量（当不一致性成本为零时，质量就是好的，所以又可以说，质量是免费的）
          • 石川（Ishikawa）。提出质量圈和鱼刺图，总结出七种基本质量工具
          • 田口（Taguchi）。提出质量损失函数（产品质量波动会给社会带来损失）、稳健设计方法（质量首先是设计出来的，其次才能制造出来）、实验设计方法
        • 8.5.3 几个注意点
          • 保证质量可以提高生产率，降低成本
          • 劣质和低等级不是一回事。前者是指质量不符合要求，有缺陷；后者是指质量没有问题，只是功能少一些
          • 如果没有足够的成本来满足既定的项目要求，可以降低项目的等级（缩小项目范围，减少项目功能），但不能牺牲质量
    • 第9章 项目资源管理
      • 9.1 概述
        • 项目资源管理是指为完成项目而识别、获取和管理所需的人力资源和实物资源
          • 人力资源是直接从事项目工作（包括管理工作和技术工作）的项目团队成员
          • 实物资源是直接用于项目的材料、设备和设施
        • 对于项目团队，项目经理应该：
          • 首先必须是领导者。作为领导者，他必须创建有利于合作的团队氛围，建设高效的项目团队；必须激励团队成员，培养成员和团队的工作能力，鼓励成员积极参与项目规划和决策
          • 其次，项目经理必须是管理者。作为管理者，他必须要求团队成员遵守规范的项目管理制度，严格按要求开展启动、规划、执行、监控和收尾过程组的各种活动
          • 领导主要靠软技能，管理主要靠硬技能
        • 对于实物资源，项目经理必须有效地获取、分配和使用
          • 必须了解项目当前和未来对实物资源的需求，包括资源的种类、性能和数量
          • 必须了解可用的实物资源供应渠道
          • 必须在确保实物资源按时可用的同时，防止库存过多
        • 无论是人力资源还是实物资源，都既可以来自项目执行组织内部，也可以来自项目执行组织外部。项目资源管理知识领域关注来自组织内部的资源，项目采购管理知识领域关注来自组织外部的资源
      • 9.2 各过程的输入与输出
        • 9.2.1 输入与输出的关系总览
        • 9.2.2 规划资源管理
          • 在项目章程的指导下，根据项目管理计划中的质量管理计划和范围基准编制资源管理计划。质量管理计划和范围基准有利于确定为达到既定的质量标准和交付特定的WBS要素，而需要如何开展资源管理
          • 虽然《PMBOK®指南》中只列出了质量管理计划和范围基准，但实际上，需求管理计划、范围管理计划、进度管理计划、成本管理计划、进度基准和成本基准（都是项目管理计划的组成部分），也会影响规划资源管理过程
          • 应该根据项目目标以及拟用的目标实现方法来确定项目资源管理方法
          • 本过程还需要用以下项目文件作为输入：项目进度计划+需求文件+风险登记册+相关方登记册+团队章程
            • 项目进度计划。资源管理方法应该有利于项目进度计划的实现
            • 需求文件。资源管理方法应该有利于实现既定的需求
            • 风险登记册。开展资源管理时，应该利用与资源有关的机会，减轻与资源有关的威胁
            • 相关方登记册。有些相关方对资源管理方法有特别的要求
            • 本过程还需要编制团队章程
        • 9.2.3 估算活动资源
          • 根据项目管理计划和各种项目文件编制资源需求，以及作为附件的估算依据。然后，再把用于不同工作的同种资源汇总，形成资源分解结构
          • 项目管理计划中的资源管理计划规定了估算活动资源的方法，范围基准则有利于把活动的资源需求逐层向上汇总到工作包、控制账户和整个项目
          • 在本过程中，也需要汇总得出整个项目的资源需求
          • 以下项目文件是本过程的输入：活动清单、活动属性+假设日志+成本估算+风险登记册+资源日历
            • 活动清单、活动属性。根据活动的性质，对每个活动估算资源
            • 假设日志。估算资源时需要考虑相关的假设条件和制约因素，如关于劳动生产率的假设
            • 成本估算。准备花多少钱去做某个活动，会直接决定能够找什么级别的资源
            • 风险登记册。有利于挑选合适类别的资源或使用合适数量的资源去应对风险登记册中的风险
            • 资源日历。资源（人员、设备或设施）可用于项目的日期，会直接决定所需资源的数量
        • 9.2.4 获取资源
          • 根据项目管理计划和各种项目文件，获取所需的人力资源和实物资源，并进行分配，得出实物资源分配单和项目团队派工单，同时需要确定资源的实际可用日期，形成资源日历。如果实际获取的资源并不完全符合原定的要求（如技能水平较低），就需要提出变更请求
          • 项目管理计划中的资源管理计划规定了用于获取资源的方法，如人员招聘程序和渠道；采购管理计划有利于通过采购从组织外部获取资源；成本基准则有利于控制用于获取资源的总成本
          • 以下4种项目文件，也是本过程的输入：项目进度计划+资源需求+相关方登记册+资源日历
            • 项目进度计划。获取资源的时间、种类和数量，必须符合进度计划的要求
            • 资源需求。按其中的规定，获取所需要的资源
            • 相关方登记册。需要与掌握资源的相关方打交道
            • 资源日历。根据需要资源的日期，去获取资源
              • 资源日历，既是估算活动资源过程和获取资源过程的输入，又是获取资源过程的输出
              • 首先，根据预订的资源日历（记录需要资源的日期）估算所需资源；其次，根据预订的资源日历去获取资源；最后，获取资源之后，确认资源的实际可用日期，得出更新后的资源日历（记录资源的实际可用日期）
        • 9.2.5 建设团队
          • 根据项目管理计划中的资源管理计划，以及各种项目文件，开展团队建设活动，提高团队绩效。团队绩效的提高情况，需要记录在团队绩效评价中。开展团队建设活动，可能导致需要修改项目管理计划或相关的项目文件，从而需要提出变更请求
          • 以下项目文件都是本过程的输入：项目进度计划+项目团队派工单+资源日历+团队章程+经验教训登记册
            • 项目进度计划。为实现进度计划而开展团队建设活动
            • 项目团队派工单。针对不同岗位的成员开展不同的团队建设活动
            • 资源日历。只能选择相关成员在项目上工作的日期开展团队建设活动
            • 团队章程。用于指导团队建设的高层次文件
            • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训
        • 9.2.6 管理团队
          • 本过程旨在了解团队成员和整个团队的工作表现，解决问题和冲突，并提出必要的变更请求
          • 项目管理计划中的资源管理计划，规定了管理团队的基本方法
          • 成员个人和整个团队的表现好坏，需要查看团队绩效评价文件。需要根据工作绩效报告中的项目实际绩效及其与计划要求的偏离程度，来反思团队的表现
          • 以下项目文件也是本过程的输入：团队章程+项目团队派工单+问题日志+经验教训登记册
            • 团队章程。用于指导团队管理的高层次文件
            • 项目团队派工单。对不同岗位的人员，业绩（工作表现）要求不尽相同
            • 问题日志。根据项目所发生的问题的数量和严重性，来反思团队的表现
            • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训
            • 需要特别提及的是，获取资源、建设团队和管理团队这三个过程都有事业环境因素更新这个输出
          • 为了强调项目经理应该实实在在地与团队成员打交道，而不是居高临下地以旁观者的身份去“监督”团队成员的表现，《PMBOK®指南》故意把管理团队过程放在执行过程组，而不是监控过程组
        • 9.2.7 控制资源
          • 根据项目管理计划中的资源管理计划，把体现在工作绩效数据和问题日志中的资源获取、分配和使用的实际情况，与体现在相关项目文件中的计划要求进行比较，并把比较的结果记录在工作绩效信息中。如果结果不理想，就提出变更请求。对于按协议（合同）获取的资源，需要与协议中的规定进行比较
          • 项目文件包括：问题日志+实物资源分配单、项目进度计划、资源需求、资源分解结构+风险登记册+经验教训登记册
            • 问题日志。其中会记录与资源有关的实际问题，如资源短缺或供应延迟。也可以根据其中记录的其他问题去反思资源的使用情况
            • 实物资源分配单、项目进度计划、资源需求、资源分解结构。这些文件都直接记录了对相关资源的计划要求，例如，何时何种资源应该就位
            • 风险登记册。其中记录了与资源有关的风险，有利于分析资源问题产生的原因及后果
            • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训
      • 9.3 各过程的主要工作和成果
        • 9.3.1 规划资源管理
          • 本过程旨在编制资源管理计划，规定将如何估算、获取、使用和管理项目资源，包括人力资源和实物资源。资源管理计划的主要内容包括：
            • 同时适用于人力和实物资源的内容：资源估算方法和资源获取方法
            • 专用于人力资源的内容：团队中应该设立的角色及其权责、团队的组织结构图、成员管理安排（如分配、考核和遣散）、成员培训安排、团队建设方法（如对团队建设活动的要求）、认可和奖励安排（如何时颁发何种奖励）
            • 专用于实物资源的内容：资源监控方法，即如何监督和控制实物资源的获取和使用情况
            • 对于人力资源，本过程还要制定团队章程，规定项目团队的愿景和使命，以及项目团队的核心价值观、行为规范和工作规则。团队章程使团队成员对什么行为是可接受或不可接受的，建立和保持基本一致的认识
        • 9.3.2 估算活动资源
          • 本过程旨在估算项目工作所需的资源的类别、类型和数量，包括人力资源和实物资源
            • 资源的类别是指资源的种类，如人力、材料、设备
            • 资源的类型是指资源的技能水平（等级），如一级工、二级工、三级工
            • 这些信息都需要反映在资源需求文件中
          • 首先估算各个活动的资源需求，然后协调各个活动的资源需求（如两个活动可以共享同一个资源），并逐层向上汇总，得出工作包、控制账户、WBS分支和整个项目的资源需求
          • 整个项目的资源需求情况可以用资源分解结构来表示。在资源分解结构中，根据资源的类别和类型把整个项目所需的资源逐层分解。用于不同活动或WBS要素的同样类型或类别的资源，在资源分解结构中都被汇总在一起。便于掌握对每种类型或类别的资源的需求总量，有利于准备或采购资源
          • 本过程的输出是“资源需求”而非“活动资源需求”，是因为估算的结果不局限于“活动”的资源需求，还有工作包、控制账户和整个项目的资源需求
        • 9.3.3 获取资源
          • 本过程旨在以正确的方式在正确的时间获取正确的人力资源和实物资源
          • 本过程还需要对所获取的资源进行分配，并形成相应的资源分配文件，包括实物资源分配单和项目团队派工单
          • 对所获得的团队成员，必须仔细分析他们的性格、态度、能力、胜任力和可用性等，并基于分析结果进行工作分配，确定该采用什么领导风格和手段去启发、激励和影响他们
        • 9.3.4 建设团队
          • 本过程旨在开展各种团队建设活动，创建和维护良好的团队氛围，提高团队成员个人的胜任力，提高整个团队的工作能力，以提高团队绩效，实现项目目标
          • 决定一群人成为一个团队的最关键的因素是团队精神
          • 为了取得优秀的团队绩效，在团队中需要有开放式沟通、相互信任的氛围、建设性的冲突解决、合作式的问题解决和决策制定
          • 项目通常是跨专业和跨部门的，项目团队也就因此具有较高的多样性（多元化），即团队成员来自不同的专业、不同的部门，具有不同的背景
          • 按照塔克曼的团队建设5阶段理论，项目团队要经过从形成、震荡、规范、成熟到解散这5个阶段
            • 形成阶段：团队成员抱着自己的个人目的加入团队，需要相互认识。因为成员之间还不熟悉，所以不能采用参与式领导风格，只能采用命令或指挥式领导风格
            • 震荡阶段：团队成员尝试合作，出现了大量矛盾，就需要磨合。项目经理应该像教练一样指导团队成员尽快完成磨合。教练型领导风格是介于命令式与参与式之间的
            • 规范阶段：团队建立了一系列书面规章制度，团队成员都按规章制度行事。项目经理应该给团队成员提供支持，以便他们遵守规章制度。支持型领导风格是参与式领导风格的一种
            • 成熟阶段：书面规章制度已经在团队成员的心里内在化了，即便不存在，也无所谓了。项目经理应该用授权型领导风格（参与式领导风格的一种），把大量工作授权给团队成员去完成
            • 解散阶段：不少团队成员都在找以后的出路，可能不安心本项目的工作。项目经理又要重新采用命令或指挥式领导风格
          • 在项目团队建设的不同阶段，项目经理应该采取有所不同的领导风格
          • 优秀的项目团队是以工作和结果为导向的，并且能够把结果做得符合要求，也就是说，团队成员把按要求完成工作任务放在第一位。只有能够按要求实现目标的团队，才算优秀的团队
        • 9.3.5 管理团队
          • 本过程旨在跟踪团队成员和整个团队的工作表现，并把跟踪到的情况反馈给团队成员；还要预防和解决团队中出现的问题，管理团队成员的变化
          • 在实际工作中，建设团队与管理团队肯定无法截然分开。它们之间的主要区别是：
            • 建设团队过程，是基于对什么行为能导致良好团队绩效的预测，采取这些行为来“推动”团队的发展
            • 管理团队过程，是基于对实际行为及其效果的回顾，采取补充行为来“拉动”团队的发展。管理团队，更像一个监控过程
        • 9.3.6 控制资源
          • 本过程旨在监督和控制实物资源的获取、分配和使用，提出必要的变更请求
          • 必须确保在正确的时间把正确的资源用到正确的地方，确保资源使用的效率和效果，并在使用完毕后及时释放设备和设施类资源
          • 应该及时发现和处理资源短缺或资源剩余，通知项目相关方资源使用情况和出现的问题，管理与资源有关的变更
      • 9.4 各过程的工具与技术
        • 9.4.1 规划资源管理
          • 本过程的工具包括专家判断、会议、组织理论和数据表现
            • 组织理论是关于组织中的个人、小组、团队、部门，以及整个组织应该如何行动的学问。在理论的指导下编制团队资源管理计划，效率更高（编计划更容易），效果更好（计划的质量更好）
            • 数据表现包括用于描述项目团队的组织结构的3种主要方式：层级型+责任分配矩阵+文本型
              • 传统的层级型。层级型中又包括工作分解结构和组织分解结构
              • 责任分配矩阵。用二维的矩阵图把每项工作分配给相应的人员或部门
              • 文本型，如岗位说明书，主要用文字来描述哪个人或部门将对哪项工作承担什么职责
            • 数据表现中的资源分解结构（属于层级型），则是用来展示团队和实物资源的类别、类型和数量的一种图形
          • 在资源管理计划中需要规定将用什么方式来表示项目团队的组织结构，以及项目所需资源的分类，即需要提供相应的格式和模板
        • 9.4.2 估算活动资源
          • 本过程的工具包括专家判断、自下而上估算、类比估算、参数估算、数据分析、项目管理信息系统和会议。几个特别的地方：
            • 自下而上估算。本过程需要把各活动的资源需求向上逐层汇总到工作包、控制账户和整个项目
            • 数据分析。用备选方案分析来选择用于开展活动的最佳资源配置方案。不同的方案对活动的成本、工期和质量会有不同的影响
            • 会议。估算资源时，需要与职能经理开会，因为他们是资源（特别是人力资源）的掌握者
        • 9.4.3 获取资源
          • 本过程的工具主要是用于获取人力资源，包括预分派、决策、人际关系与团队技能，以及虚拟团队
          • 有些关键的工作岗位，需要在项目正式启动之前就指定人选，这些人就是预分派的。项目章程中指定的人员、投标文件中指定的人员或者在项目启动前就预约好的专业人才，都是预分派的
          • 如果项目经理对团队成员有选择权，就需要运用决策中的多标准决策分析去挑选最合适的人员
          • 项目经理需要运用人际关系与团队技能中的谈判，与职能经理谈判，向职能经理借人；与其他项目经理谈判，争取优秀人员；与外部资源供应商谈判，获取本组织无法提供的人员
          • 在互联网日益发达的今天，项目经理可以借助虚拟团队来提高获取人力资源的灵活性
          • 虚拟团队需要特别好的沟通计划，需要真正的团队建设
          • 可以把这些工作之间的关系进一步概括为：先用预分派预约好一些关键人员，再用多标准决策分析选择其他团队成员。对于选中的人员，需要用谈判的方式获取。对于无法面对面方式加入团队的成员，就用虚拟团队的形式让他们加入。
        • 9.4.4 建设团队
          • 集中办公，无疑有利于团队建设。在虚拟团队中，应该开展临时的集中办公。在矩阵型项目组织中，不少兼职人员平常仍在各自的职能部门办公，所以临时的集中办公也就特别重要。这种临时的集中办公又称紧密式矩阵（Tight Matrix）
          • 对于无法集中办公的成员，可以借助虚拟团队技术来建设团队，需要借助各种网络交流和沟通工具
          • 团队建设当然需要使用沟通技术。开展正式和非正式的沟通，是团队建设的重要手段。像视频会议、在线聊天、共享网页，都是常用的沟通技术
          • 在团队建设中，项目经理应该借助人际关系与团队技能，与团队成员打交道，激励和影响他们，并解决冲突。作为组织团队成员完成项目任务的人，项目经理必须具备很强的人际关系技能
          • 项目经理必须具备一定的技术能力、较好的概念性能力（抽象思维能力）、很强的人际关系能力
            • 技术能力是指从事技术工作、解决技术问题的能力。项目经理需要了解技术，但不必是技术方面的专家
            • 概念性能力是抽象思维、把握全局、掌控方向的能力，是高层经理必须具备的能力
          • 《PMBOK®指南》列出了以下5种人际关系技能：
            • 团队建设。开展各种各样的团队建设活动。需要有大量的成员互动和非正式沟通，以及专门开展的和融入日常工作的团队建设活动。应以融入日常工作的团队建设活动为主，以专门开展的活动为辅
              • 项目管理中的许多技术工作，都不仅是技术工作，而且是很重要的团队建设活动
            • 谈判。对工作任务安排，项目经理往往需要与团队成员谈判，做交易
            • 激励。基于团队成员的需求，采取措施，使成员去做项目经理希望他们做的事情
            • 影响力。不借助正式权力（职位权力）而让他人服从自己。项目经理的正式权力往往是不足的，故需要施加影响力
            • 冲突管理。用建设性方式及时解决冲突。冲突解决得好，有利于团队建设；解决得不好，就会妨碍团队建设
          • 在团队建设中，应该经常对团队成员的优良行为或业绩进行认可与奖励。为了使认可与奖励真正起到激励所有团队成员的作用，应该针对每个人都能够做到的行为开展认可与奖励，而不只是针对少数人能够做到的行为。认可与奖励应该经常开展，不能只是等到项目结束时；应该考虑团队成员的需求，只有能满足需求的认可与奖励才是有效的
          • 如果团队成员不具备项目所需的技能，就要对他们进行培训。培训通常是团队建设中的一项重要工作
            • 广义的培训（training）也包括教练（coach）和辅导（mentor）。表中概述了培训（狭义）、教练与辅导的主要区别
            • 项目经理应该使用各种个人和团队评估工具，来了解团队成员的优势、劣势、喜好和厌恶等，以便有针对性地开展培训和其他团队建设活动
            • 在团队建设中经常需要召开会议。其中的项目说明会，是指向新成员介绍项目情况和团队情况
        • 9.4.5 管理团队
          • 本过程的工具比较简单，只有项目管理信息系统和人际关系与团队技能。以下是一些重要的人际关系技能：
            • 冲突管理。以建设性方式及时解决冲突
            • 制定决策。通过与组织或项目团队谈判来制定决策，或者通过对组织或项目团队施加影响来制定决策
            • 情商。能够识别、评价和管理自己和他人的情绪，也包括识别、评价和管理团队集体的情绪
            • 影响力。不依靠正式权力而使他人服从自己
            • 领导力。启发和激励员工做好工作，实现目标
        • 9.4.6 控制资源
          • 本过程的工具包括项目管理信息系统、人际关系与团队技能、数据分析、问题解决
            • 人际关系与团队技能中的谈判和影响力，有助于项目经理获取其他人（如职能经理）的支持，来解决实物资源获取和使用中的问题，如资源的工作效率达不到既定要求
            • 数据分析中的绩效审查，用于综合分析资源使用绩效，发现偏差。其中：备选方案分析+成本效益分析+趋势分析
              • 备选方案分析，用于分析解决资源绩效偏差的多种方案，并做出选择
              • 成本效益分析用于选择效益成本比最好的资源绩效偏差解决方法。
              • 趋势分析用于预测未来的资源使用绩效
            • 问题解决是指结构化的问题解决方法，用于解决资源获取、分配和使用中的问题
      • 9.5 冲突管理
        • 9.5.1 冲突的概念
          • 冲突是指双方或多方的意见或行动不一致。有效地管理冲突，有利于加强团队建设，提高项目绩效
          • 有效管理冲突是项目经理的重要任务之一
          • 现代的冲突观念与传统的冲突观念的不同点：
        • 9.5.2 冲突产生的背景和原因
          • 冲突的产生往往有相应的微观、中观和宏观背景
          • 需要注意下面4种引起冲突的原因（按常见程度排序，最常见原因排在第一位，最不常见原因排在最后）：
            • 资源稀缺。导致人们对资源的争夺
            • 进度优先级排序。对各项工作的重要性有不同看法
            • 工作风格差异。各人所喜欢的工作风格不同
            • 个性（Personality）差异。人与人之间的个性不同
          • 知道个性是引起冲突的最少见原因，有利于处理冲突时对事不对人
        • 9.5.3 冲突的发展阶段：潜伏阶段+感知阶段+呈现阶段+结束阶段
          • 对冲突的发展阶段，有多种不同的划分方法。较常用的一种方法是，把冲突的发展划分成如下5个阶段：潜伏阶段+感知阶段+感受阶段+呈现阶段+结束阶段
            • 潜伏阶段。冲突潜伏在相关的背景中，例如，对两个工作岗位的职权描述存在交叉
            • 感知阶段。各方意识到可能发生冲突，例如，人们发现了岗位描述中的职权交叉
            • 感受阶段。各方感受到了压力和焦虑，并想要采取行动来缓解压力和焦虑。例如，某人想要把某种职权完全归属于自己
            • 呈现阶段。一方或各方采取行动，使冲突公开化。例如，某人采取行动行使某种职权，从而与也想要行使该职权的人产生冲突。在呈现阶段，冲突往往又要经过出现、升级、僵持和缓和等阶段
            • 结束阶段。冲突呈现之后，经过或长或短的时间，得到解决。例如，该职权被明确地归属于某人
            • 冲突潜伏在背景中，感受于意识中，呈现于言行中，结束于解决时
        • 9.5.4 冲突解决的基本理论和原则
          • 可用于指导冲突解决的基本理论包括：
            • 利益决定立场理论。立场的冲突往往源自利益的冲突，所以要重点关注利益而不是立场
            • 需求满足理论。冲突可能源自需求未得到满足，所以要设法使相应的需求得到满足
            • 冲突转化理论。要设法把破坏性冲突转化为建设性冲突
          • 可用于指导冲突解决的基本原则包括：
            • 开诚布公。冲突双方开诚布公地讨论冲突事项
            • 对事不对人。用对事不对人的态度对待冲突
            • 着眼于团队和项目。以最有利于团队和项目的方式解决冲突
            • 着眼于现在和未来。从过去的阴影中摆脱出来，寻找有利于现在和未来的解决方法
            • 当事人自己解决。冲突最好由当事人自己尽早解决，他们的直接上级可以协助
          • 对一方违反职业道德或法律而引起的冲突，另一方必须向有关机构报告，而不能由当事人自己解决
        • 9.5.5 解决冲突的基本方法
          • 在冲突发展的潜伏阶段和感知阶段，重点是预防冲突。在冲突发展进入感受阶段特别是呈现阶段以后，则重在解决冲突。可以用如下6种常用的方法去解决冲突：
            • 合作或解决问题。这是“双赢”的方法
            • 面对（Confrontation）。摆在台面谈
            • 合作是取两个现有方案的优点，形成新方案；面对是选择一个现有的方案，放弃另一个现有的方案
            • 妥协或调解。各让一步。所以可看作“双输”，但并非不好的解决方法
            • 缓和或包容。“求同存异”。是“双赢”的方法（但只是部分解决冲突）
            • 撤退或回避。如把问题留到以后去解决，是“双输”的方法
            • 强制或命令。一方强制另一方，这是最坏的解决方法，是“赢-输”的方法
          • 西方文化鼓励“把问题摆到桌面上”——工作中的问题都应该摆到桌面上。PMP®考试要按这个观点来答题。在PMP®考试中，除非题目中的情景使你有理由选择排序靠后的解决方法，一般情况下都应选择前文排序靠前的解决方法
          • 注意：对于团队成员之间的私人矛盾，不能用合作或面对的方法去解决，而只能用缓和的方法，即要求成员以工作为重（共同点），不要把私人矛盾（差异点）带到工作中
      • 9.6 团队工作分配与成员激励
        • 9.6.1 狭义与广义的项目团队
          • 项目经理是受项目执行组织委派，领导项目团队去实现项目目标的个人
          • “项目团队”这个词有狭义与广义之分
            • 狭义的项目团队，仅指一线的工作团队，从事具体的项目活动，完成相应的工作包；或者仅指项目管理团队。项目管理团队是项目团队中直接从事项目管理工作的成员的集合。项目经理是项目管理团队的一员
            • 中观层面的项目团队，是包括项目管理团队和一线工作团队在内的
            • 广义的项目团队，则包括项目管理团队、一线工作团队以及其他主要项目相关方
            • 碰到“项目团队”这个词时，必须根据上下文判断其外延。如无法判断，则理解成中观层面的项目团队
          • 项目经理、项目管理团队和一线工作团队按如下顺序出场：
            • 在项目启动阶段，项目发起人指定项目经理，项目经理正式出场
            • 在规划阶段开始时，项目经理组建项目管理团队编制项目计划，项目管理团队正式出场
            • 在执行阶段开始时，项目经理组建一线工作团队，一线工作团队正式出场
        • 9.6.2 责任分配矩阵
          • 项目管理中，经常使用责任分配矩阵来分配工作任务，把各WBS要素或进度活动分配给相应的小组或个人负责
          • 《PMBOK®指南》中列举了以RACI形式呈现的责任分配矩阵。其中：
            • R代表职责（Responsible），是执行某项工作的责任。对某项工作，可以有两个甚至更多的R
            • A代表终责（Accountable），是对某项工作负有最终责任。对某项工作，只能出现一个A，作为该工作的唯一责任点
            • C代表咨询（Consulting），是应该对某项工作提出意见。对某项工作，通常有多个C
            • I代表知情（Informing），是应该了解某项工作的情况。对某项工作，通常有多个I
          • 作为组织专家做事的人，项目经理必须善于授权。关于授权，需要注意：
            • 按团队成员的能力优势进行授权，决定授权种类和级别
            • 按结果而非过程进行授权，即明确要求该取得的成果，而把工作过程留给被授权者掌控
            • 授权不能消除或减轻自己对被授权工作的终责
            • 不能把项目整合管理的工作授权出去
            • 不能把自己不想做的事授权给下级去做
            • 不能把颁发奖励或实施惩戒的工作授权给助手去做
          • 把工作授权给下级去做，只是向下级转移了执行的责任，而无法转移对工作的终责
        • 9.6.3 激励理论
          • 激励理论也是PMP®考试中的重要内容之一。激励是指因为某个行为能够满足个人的某种需要而促使一个人去从事这种行为
          • 管理学中有多种激励理论：
            • 马斯洛的需求层次理论（Maslow's Hierarchy of Needs）。
              • 人有五个层次的需求：
                • 生理需求（食物、水、空气、衣服等）
                • 安全需求（安全、稳定、免受伤害）
                • 社会需求（友爱、归属、朋友）
                • 尊重需求（成就、受到尊敬、引起别人注意）
                • 自我实现需求（学习、发展）
              • 通常，人们只有在较低层次的需求得到满足后，才会追求较高层次的需求
              • 激励与个人的需求有关，而且只有尚未满足的需求才能起到激励的作用
            • 麦格雷戈的X理论和Y理论（McGregor's Theory X andTheory Y）
              • X理论认为人是消极懒惰的，设法逃避工作，缺乏进取心，总是逃避责任
              • Y理论则相反，认为人是积极的，愿意工作，愿意进步，愿意承担责任等
              • 传统的管理比较偏向于X理论，现代管理越来越偏向于Y理论
            • 赫兹伯格的双因素理论（Herzberg's Theory ofMotivation）
              • 该理论认为有两类因素会决定人的行为，即保健因素和激励因素
                • 保健因素导致不满足感，做得不好就会损害激励，做得好却不会提高激励，如工作条件、工资、同事之间的关系、安全、职位等，相当于马斯洛的需求层次理论的较低层次的需求（生理和安全）
                • 激励因素是导致满足感的因素，是能够真正起激励作用的，如责任、自我实现、职业发展、得到承认等，相当于马斯洛的需求层次理论的较高层次需求（尊重和自我发展）
            • 弗鲁姆的期望理论（Vroom's Expectancy Theory）
              • 一种行为倾向的强度取决于个人对于这种行为可能带来的结果的期望度，以及这种结果对个人的吸引力。如果一个人认为努力工作会带来成功的结果，而这种成功又会带来相应的回报，他就会受到激励而努力工作
            • 麦克利兰的成就动机理论（McClelland's AchievementMotivation Theory），又称“三种需要理论”
              • 该理论认为各人在不同程度上有3种需要：成就需要、权力需要和亲和需要。管理者应该根据各人更重视的需要来制定激励措施。例如，为成就需要者设立具有挑战性但可实现的目标，为权力需要者提供较能体现地位的工作环境，为亲和需要者提供合作而非竞争的工作环境
        • 9.6.4 其他重要概念
          • 资源直方图。用来表示每个时间段（如周、月）所需资源数量的柱状图。柱子的高度代表所需资源的数量。可以用一条横线表示可用的最大资源数量。如果柱子超出横线，就是资源短缺
          • 资源横道图。在横道图的每条横道上面或旁边，添加从事活动的人员的姓名
          • 边际福利（Fringe Benefit）。所有员工都可享受的福利，如基础培训、失业保险、养老保险、医疗保险等，与员工的业绩好坏没有直接关系。它用来保障员工的经济安全性，使他们无后顾之忧，属于保健因素
          • 光环效应（Halo Effect）。因为一个人在某个方面表现好，人们就理所当然地认为他在其他方面也会表现好。例如，不进行综合评价，就简单地指定一个优秀的技术专家当项目经理，很可能就是光环效应的表现。要注意防止光环效应
          • 额外待遇（Perquisites）。给某些员工特殊奖励，如固定的停车位、靠窗的办公室、与总经理一起吃饭等。它主要用来奖励优秀员工，属于激励因素
      • 9.7 《PMP考试大纲》中的人员管理
        • 《PMP®考试大纲》中的人员管理内容都可以归并到《PMBOK®指南》中的规划资源管理、估算活动资源、获取资源、建设团队和管理团队过程中
          • 在规划资源管理过程中
            • 设定清晰的团队愿景和使命
            • 根据组织原则确定团队基本规则、所需的成员胜任力和成员培训、考核团队绩效的关键绩效指标和向成员反馈考核结果的方法
            • 这些内容都应该写入团队章程
          • 在估算活动资源过程中
            • 评估相关方具有的知识和技能，据此推算所需的人力资源和所需的培训，并估算和分配培训所需的资源
            • 如有虚拟团队，则还要确定所需的虚拟团队成员及其参与项目的方式
          • 在获取资源过程中
            • 从相关方获取所需的人力资源（团队成员），分析和了解团队成员（例如，用性格指数去了解成员的个性，分析虚拟团队成员对沟通时间和方式等的需求）
            • 根据团队成员的优势来组建团队和分配工作任务（例如，让最擅长者充当特定工作的终责人，根据成员能力来确定工作授权级别）
            • 与团队成员协商达成工作协议，确定所需的具体培训方案
            • 对于虚拟团队，还要确定虚拟团队成员的具体工作方式
          • 在建设团队过程中
            • 建立和维护团队共识，创建和维护团队氛围，赋能团队成员（包括使成员有权做决策和有能力做工作）
            • 采用合适的领导风格（如仆人型风格）和高级的情商并根据团队成员的特性（如性格）去启发、激励和影响团队成员
            • 支持团队的多样性和包容性，支持和认可团队成员的成长，支持团队成员履行工作职责和承担工作终责
            • 开展所需培训、教练和辅导
            • 支持成员之间的知识分享，发现和排除妨碍团队的困难和障碍，支持团队成员遵守基本规则
            • 对于虚拟团队，则还要采取措施支持虚拟团队成员参与项目
          • 在管理团队的过程中
            • 分析冲突的背景、原因和阶段，采用适当方法解决冲突
            • 考核团队绩效并向成员反馈考核结果
            • 持续评估工作终责的落实情况，分析团队绩效的改进情况，考核培训、教练和辅导的效果
            • 持续评估团队成员的技能并提出改进建议，持续评估妨碍团队的困难和障碍的排除情况，持续评估与成员的工作协议的落实情况
            • 发现、分析和解决成员之间的误解，发现和纠正违反基本规则的言行
            • 对于虚拟团队，则还要持续评估虚拟团队成员参与的有效性
    • 第10章 项目沟通管理
      • 10.1 概述
        • 10.1.1 项目沟通管理的本质
          • 项目沟通管理是要确保及时正确地产生、收集、发布、存储和最终利用项目信息
          • 沟通是项目信息的产生、收集和利用的过程
            • 首先，基于相关方的信息需求、项目本身的需求、可用的组织过程资产，以及相关的事业环境因素，制定项目沟通策略（关于沟通的原则性规定）
            • 其次，制订沟通管理计划，规定用于实现沟通策略的沟通工件和沟通活动
              • 沟通工件是由人工编制或机器生成的任何类型的信息载体，如绩效报告、电子邮件
              • 沟通活动则是用于传递信息载体的任何活动，如发送绩效报告或电子邮件
            • 再次，生成所需的沟通工件，开展所需的沟通活动
            • 最后，监控沟通工件和沟通活动的绩效
          • 沟通工件是由人工编制或机器生成的任何类型的信息载体，如绩效报告、电子邮件
          • 需要遵循5C原则
            • 目的明确（Clear Purpose）：基于自己和对方的需求，确定明确的沟通目的
            • 表达正确（Correct Expression）：用词正确，语法正确，方式和方法正确
            • 表达简洁（Concise Expression）：使用尽可能简单的词语和句子
            • 逻辑连贯（Coherent Logic）：在书面文件中，可以使用标题或小标题明示各部分的逻辑关系。在口头沟通中，可以使用“第一点”“第二点”等来明示各部分的逻辑关系
            • 思路掌控（Controlling Ideas）：在沟通的最后，用图形、文字或语言总结来概述思路的全貌
        • 10.1.2 项目经理在沟通中的角色
          • 沟通能力是项目经理最重要的能力，比技术能力更重要。沟通能力也是谈判能力和团队建设能力的基础
          • 项目经理的大多数时间（甚至高达90%）用于沟通。他要通过沟通来协调，通过协调来整合
          • 虽然项目经理不能控制全部沟通，但是应该设法管理沟通，以尽量避免不必要的变更、误解、指示不清等
          • 项目经理在沟通中的角色可以是整合者、协调者、促进者、领导者、谈判者、聆听者、解释者和调解者
          • 项目经理作为项目沟通的核心，应该通过以下措施来促进有效沟通：
            • 充分认识沟通的困难，设法消除沟通障碍
            • 充当有效的沟通者
            • 使用紧密式矩阵
            • 建立作战指挥部（War Room）
            • 建立、维护和利用各种项目信息发布制度
            • 采取各种措施提高自己及团队其他成员的沟通技巧
            • 提高会议的效率和效果
        • 10.1.3 沟通的种类
          • 正式沟通与非正式沟通
            • 正式沟通是组织规章制度中明确规定的强制性的沟通，是必须做的
            • 非正式沟通则是规章制度中未明确规定的，而是由团队成员自由选择的，是可做可不做的
          • 官方沟通与非官方沟通
            • 官方沟通是作为组织的正式意见而发布的信息
            • 非官方沟通则不是组织的正式意见
            • 【区别】官方/非官方沟通VS正式/非正式沟通
              • 官方沟通肯定是正式沟通，但正式沟通不一定就是官方沟通，非正式沟通肯定是非官方沟通
              • 非官方沟通不一定就是非正式沟通
              • 有些正式沟通可能不是官方沟通
          • 内部沟通与外部沟通
            • 内部沟通是项目团队内部的沟通
            • 外部沟通是项目团队与外部相关方的沟通
            • 内部或外部是针对项目层面而言的
          • 纵向沟通与横向沟通
            • 纵向沟通是不同级别的人之间的沟通
            • 横向沟通是同一级别的人之间的沟通
            • 一般情况下，纵向沟通中的信息损耗比横向沟通更加严重
            • 在纵向沟通中，上级应尽力把自己放在与下级平等的位置上，来减少损耗
          • 口头沟通与书面沟通
            • 口头沟通是以口头语言进行的沟通
            • 书面沟通是以书面形式进行的沟通
          • 口头语言沟通与非口头语言沟通
            • 口头语言沟通包括讲话的内容、语音语调、声音大小等
            • 非口头语言沟通则是以形体语言或外在器物（如信号旗）进行的
          • 在考试中，可能有题目要求根据某个情景选择最合适的沟通方式
          • 人与人之间的许多问题都是沟通不充分或沟通中的误解引起的。所以，与别人发生矛盾后，应该首先检查一下沟通有没有问题
      • 10.2 各过程的输入与输出
        • 10.2.1 输入与输出的关系总览
          • 项目沟通管理的实现过程包括规划沟通管理、管理沟通和监督沟通
        • 10.2.2 规划沟通管理
          • 在项目章程的指导下，根据项目管理计划中已有的相关内容，以及相关的项目文件，编制沟通管理计划
          • 通常，项目章程中会列出一些最重要的相关方及其角色和职责。这些信息有利于明确该如何与他们沟通
          • 资源管理计划（项目管理计划的组成部分）中与人力资源有关的部分，有利于规划项目团队内部的沟通。相关方参与计划（项目管理计划的组成部分）则有利于规划该如何与相关方沟通，才能引导相关方合理参与项目
          • 作为一种项目文件，需求文件中可能包括相关方的重大沟通需求。相关方登记册则是确定该与哪些相关方沟通的依据
        • 10.2.3 管理沟通
          • 根据项目管理计划中的沟通管理计划实实在在地开展沟通，得到项目沟通记录
          • 项目管理计划中的资源管理计划，有利于为协调和管理资源（包括人力和实物资源）而开展有效的沟通；相关方参与计划则有利于为引导相关方合理参与项目而开展沟通
          • 应该在管理沟通过程中把工作绩效报告发送给项目相关方。应该在管理沟通过程中把各种项目文件发送给项目相关方，如质量报告、风险报告。这些项目文件，如变更日志和问题日志，即便不需要或不应该完整地发给项目相关方，也应该以合理方式把其中的部分内容传递给项目相关方。作为一种项目文件，相关方登记册会显示团队成员应该与哪些相关方沟通
          • 重复开展沟通时，需要借鉴已记录在经验教训登记册（一种项目文件）中的与沟通有关的经验教训
        • 10.2.4 监督沟通
          • 应该把体现在项目沟通记录和问题日志（都是项目文件），以及工作绩效数据中的沟通实际情况，与沟通管理计划、资源管理计划和相关方参与计划（都是项目管理计划的组成部分）中的沟通要求相比较，发现、记录并分析沟通绩效的偏差，形成工作绩效信息。如果偏差不可接受，就提出变更请求
          • 问题日志不仅会记录与相关方沟通中出现的问题，而且有利于从发生的问题去反思沟通的效率和效果。许多问题都是沟通不合理引起的
          • 资源管理计划有利于考察沟通是否促进了对资源的有效协调和管理。相关方参与计划有利于考察沟通是否起到了引导相关方合理参与项目的作用
      • 10.3 各过程的主要工作和成果
        • 10.3.1 规划沟通管理
          • 规划沟通管理过程旨在了解项目相关方的信息需求、项目本身的需求，以及组织过程资产和事业环境因素，编制沟通管理计划。沟通管理计划也就是沟通计划，包括3大主体内容：
            • 关于沟通管理的程序性规定
            • 关于将要生成的沟通工件的规定
            • 关于沟通活动的规定
          • 编制沟通管理计划，是非常重要的一项工作
            • 一方面，在新成立的项目团队中，团队成员可能从未在一起工作过，项目团队与项目相关方也可能从未合作过。不熟悉的人，不可能自然地了解彼此的沟通需求，如对方需要什么信息、喜欢什么沟通方式等
            • 另一方面，项目管理有非常明确且具有挑战性的目标，即通过许多人的合作，在规定的限制条件下完成项目任务。无效沟通会严重妨碍目标的实现。这两个方面决定了编制沟通管理计划的重要性
            • 编制沟通管理计划的过程，本身也是项目管理团队与主要项目相关方密切沟通的过程
          • 沟通管理计划中应该包括：
            • 需要收集什么信息
            • 在什么时候收集
            • 以什么方式收集
            • 什么时候、以什么方式、向谁发送什么信息
            • 主要项目相关方的联系方式
            • 对于关键术语的定义
            • 如何更新沟通管理计划
          • 信息既需要向项目内部的相关方（如团队成员）发布，也需要向项目外部的相关方（如政府部门、用户、媒体）发布
          • 项目沟通管理应该贯穿于项目的整个生命周期。沟通管理计划应该尽早编制并不断审查和更新。通常，在识别项目相关方（项目启动阶段）的同时，就应编制初始的沟通管理计划
        • 10.3.2 管理沟通
          • 管理沟通过程旨在根据沟通管理计划，生成、收集、发布、存储、利用和最终处置项目信息
          • 本过程不局限于发布信息，还包括前端的生成和收集信息，以及后端的确认信息发布的有效性
          • 可以把管理沟通过程解释为实实在在地开展沟通。它得到的成果就是已经开展的、既有效率又有效果的项目沟通
          • 有效果的沟通，是指在正确的时间把正确的信息发给正确的人，以便信息起到正确的作用
          • 在管理沟通过程中发布的一些重要信息，会成为组织过程资产的组成部分
        • 10.3.3 监督沟通
          • 监督沟通过程旨在根据沟通管理计划，监督项目沟通情况，发现、记录和分析沟通工作中的偏差，提出变更请求
          • 监督沟通过程经常导致重新开展规划沟通管理过程，修改沟通管理计划
        • 【总结】规划沟通管理+管理沟通+监督沟通
          • 规划沟通管理过程是为了开展有效率和有效果的沟通而编制计划
          • 管理沟通过程是实实在在地开展有效率和有效果的沟通
          • 监督沟通过程则是监控沟通的效率和效果是否达到了计划中的要求
      • 10.4 各过程的工具与技术
        • 10.4.1 规划沟通管理
          • 本过程的工具与技术可概述为：在沟通模型的指导下，进行沟通需求分析，并选择适当的沟通技术与沟通方法；需要召开会议，运用专家判断。人际关系与团队技能及数据表现，都有助于更有效地进行沟通需求分析，选择沟通技术与沟通方法
          • 沟通模型是由信息发出者、信息、媒介、噪声、信息接收者和反馈意见等诸多要素所组成的一个循环。首先信息发出者对想要发出的信息进行编码，并通过一定的媒介发送给信息接收者，然后由信息接收者对收到的信息进行解码，并把相应的反馈发送给信息发出者
          • 在沟通过程中，各种各样的因素会干扰信息的编码、传送、接收和解码。这些因素统称为沟通中的“噪声”
          • 信息发出者对信息的编码和信息接收者对信息的解码，都会直接影响沟通的质量
          • 沟通中最重要的不是你发出了什么，而是对方接收和理解了什么
          • 沟通是需要质量控制的。信息接收者向发出者的及时反馈就是沟通中的质量控制
          • 即便你暂时无法理解信息的意思，也必须在收到信息后立即告知收悉
          • 应该认真进行沟通需求分析，弄清楚项目相关方在整个项目生命周期中对信息的需求，包括需要什么信息、什么时候需要、喜欢什么格式、为什么需要等。在沟通需求分析中，应该计算相关方之间的潜在沟通渠道的数量。潜在沟通渠道越多，沟通就越复杂，也就越容易发生沟通不充分的情况
          • 沟通网络是指信息流动的通道。有3种常见的网络类型：链式、轮式和全通道式
            • 链式网络严格遵守正式的命令系统，只有上下级之间的纵向沟通，没有横向沟通
            • 轮式网络严格以某个领导者为沟通的核心，一切沟通都围绕他进行
            • 全通道网络则允许全体成员之间进行自由沟通，任何人都可以与任何人沟通
          • 在PMP®考试中，可能考全通道沟通网络下沟通渠道数量的计算
            • 在全通道网络下，相关方或团队成员之间的沟通渠道数量：
              • 沟通渠道数量=N（N−1）/ 2。其中，N为相关方或团队成员的人数
              • 例如，一个团队由5个人组成，则总共有5（5−1）/ 2=10条沟通渠道。如果在该团队中再增加3个人，则沟通渠道会增加18条
            • 考试时，一定要仔细看清楚，是问你沟通渠道总共有多少条，还是增加或减少了多少条
          • 在规划沟通管理过程中，需要根据项目的具体情况以及相关方的具体情况，为拟开展的沟通选择合适的沟通技术。被选定的沟通技术，需要写入沟通管理计划。可以按下列规则做出选择：
            • 正式书面沟通。适用于复杂、重要的事情，如发布项目章程、合同
            • 正式口头沟通。适用于需要立即得到反馈的重要事情，如合同谈判
            • 非正式书面沟通。适用于需要在以后查询但不太重要的事情，如用备忘录通知项目周报的提交时间从原来的周一中午12点改为周一上午10点
            • 非正式口头沟通。适用于既不重要也无须在以后查询的事情，如私下谈话
            • 如果需要立即解决问题，就选择口头沟通；如果问题比较重要，口头沟通之后 再进行书面确认；如果要批评别人或解决与别人的冲突，最好采用非正式口头沟通，如果不起作用或解决不了，再用正式书面沟通
            • 在口头沟通中，最重要的信息传递途径并不是口头（verbal）语言（包括内容、声音大小、语音语调），而是非口头（nonverbal）语言（形体语言，如面部表情、身体之间的距离等）
          • 在规划沟通管理过程中，需要根据项目以及相关方的具体情况选择合适的沟通方法，用于将来的沟通。被选定的沟通方法需要写入沟通管理计划。主要有以下3种沟通方法：
            • 交互式沟通。沟通双方或多方多方位地交流信息。适用条件：要沟通的信息不多，要沟通的对象不多，且需要立即获得反馈甚至达成协议。例如，开会、打电话、网络在线即时沟通
            • 推式沟通。把信息推送给信息接收者。信息接收者处于他们的本来位置不变。适用条件（暂且不考虑电子信息推送）：信息有明确的受众，要沟通的信息和对象不多，而且无须立即得到反馈。例如，给项目相关方发送绩效报告，给别人发短信
            • 拉式沟通。把信息放在一个固定的位置，把项目相关方拉到这个位置查看信息。适用条件：要沟通的信息很多，或者要沟通的对象不明确或数量很多。例如，张贴公告，建立项目网页
          • 人际关系与团队技能中的沟通风格评估有助于针对不同的人和事，选择最合适的沟通风格；政治意识有助于了解相关的政治氛围，确定有效的沟通需求、沟通技术和沟通方法；文化意识有助于了解相关的文化氛围，确定有效的沟通需求、沟通技术和沟通方法；文化意识有助于了解相关的文化氛围，确定有效的沟通需求、沟通技术和沟通方法
          • 可以借助数据表现中的相关方参与度评估矩阵，分析为了填补相关方参与项目的程度的不足，需要开展什么沟通，以及该用什么沟通技术和方法
        • 10.4.2 管理沟通
          • 管理沟通过程就是使用已选定的沟通技术与沟通方法，运用自己的人际关系与团队技能及沟通技能，实实在在地开展沟通。项目管理信息系统是用于收集、存储、发布和检索信息的自动化系统（如电子 邮件管理系统、在线聊天系统），是需要使用的沟通工具。项目报告发布是指收集和发布工作绩效报告。经常需要召开会议来开展沟通
          • “项目管理信息系统”和“项目报告发布”有实质性交叉；“人际关系与团队技能”与“沟通技能”也有实质性交叉
          • 主要的人际关系与团队技能包括：
            • 积极倾听（专注听别人说话，并适时提供反馈）
            • 冲突管理（有效预防和解决与别人的冲突）
            • 政治意识（了解政治氛围）
            • 文化意识（了解文化氛围）
            • 会议管理（有效召开会议）
            • 人际交往（建立关系网络，如微信朋友圈）
          • 主要的沟通技能包括：
            • 具有沟通胜任力（针对特定事情或对象的沟通能力）
            • 能够提供反馈、使用非口头技能和进行演示
        • 10.4.3 监督沟通
          • 在监督沟通过程中，应该通过观察和交谈（属于人际关系与团队技能），以及召开会议，来了解沟通的效率和效果
          • 应该使用相关方参与度评估矩阵（属于数据表现）来分析沟通是否达到了引导相关方合理参与项目的目的
          • 专家判断和项目管理信息系统也是应该使用的工具
    • 第11章 项目风险管理
      • 11.1 概述
        • 11.1.1 风险管理的必要性
          • 项目是独特的一次性事业，必然存在风险
            • 项目经理必须积极主动地开展项目风险管理，而不只是消极被动地去应对已发生的风险
            • 积极主动，意味着事先就认真预计可能发生的风险，分析这些风险发生的可能性和万一发生的后果，并制定和执行相应的风险应对策略和措施
          • 项目经理应该知道，项目中的大多数风险（甚至90%的风险）都可以预测和管理
        • 11.1.2 风险的定义
          • 有两个层面的风险，即整体项目风险、单个项目风险
            • 整体项目风险是项目的全部不确定性来源可能对项目的综合影响。综合影响既可能是项目目标的正向变异（如提前完工），也可能是项目目标的负向变异（如推迟完工）
            • 单个项目风险是一旦发生会对项目目标产生积极或消极影响的不确定性事件。有积极影响的，是机会；有消极影响的，是威胁
          • 风险既包括威胁，也包括机会。对“风险”这个词，必须根据上下文判断其真实内涵
          • 整体项目风险是已经识别出来的所有单个项目风险加上未识别出来的全部其他不确定性来源
          • “风险”这个词，如果前面没有任何修辞语，通常是指单个项目风险，除非上下文另有要求
          • 风险总是与不确定性联系在一起的，既可能发生，也可能不发生。风险也总是与目标联系在一起的，如果发生，会对项目范围、进度、成本和质量的至少一个方面，有积极或消极影响
        • 11.1.3 管理整体项目风险和单个项目风险
          • 只有先管理好整体项目风险，管理单个项目风险才会有意义
          • 在进行项目设计、确定项目范围和其他目标时，必须考虑与此有关的整体项目风险
          • 整体项目风险的大小，也取决于事业环境因素和组织过程资产。在一个有利或不利的环境中，项目目标发生正向或负向变异的可能性比较大
          • 只有把整体项目风险控制在可接受的区间内，管理单个项目风险才有意义
        • 11.1.4 风险的四要素
          • 风险会涉及事件、原因、后果和可能性。这四者合在一起，可称为风险的四要素，即风险是一个什么事件，由什么原因引起，发生后会导致什么后果，发生的可能性有多大
          • 在上述风险的四要素中，原因又是由风险起因和风险条件联合构成的。风险起因是某个或某些风险得以存在的“土壤”。风险条件则是引发风险事件的“催化剂”
          • 在上述风险的四要素中，可能性和后果联合决定了风险敞口（Risk Exposure）。如果把可能性和后果都量化，那么这两者的乘积就是风险敞口。风险敞口越大，风险就越严重
        • 11.1.5 风险类别
          • 可以用不同的标准，把项目风险分成不同的类别，以便有效管理。可以用风险分解结构来展示风险的类别，为进一步识别风险提供基础（出发点）。以下是常见的风险类别
            • 按专业分类：技术风险、组织风险、管理风险和财务风险
            • 按内外分类：内部风险和外部风险
            • 按与经营者的关系分类：经营风险和纯风险
              • 前者是与经营活动密切相关的风险，发生的可能性和后果与经营者的水平和努力程度有密切关系，如市场风险，通常不能买保险
              • 后者则是与经营者的水平和努力程度完全无关的意外事件，如自然灾害，通常可以买保险
              • 当然，两者之间的界限并非十分明确
            • 按已知程度分类：已知风险和未知风险。已知风险又可分为已知已知风险和已知未知风险。未知风险则是未知未知风险
              • 已知已知风险是已经识别出并分析过的风险，人们不仅知道它们是什么风险，而且知道它们发生的可能性和后果。对已知已知风险可能造成的损失，在编制项目成本预算时，通常按计算出的风险敞口计入受影响的项目工作的直接成本
              • 已知未知风险是已经识别出但其发生的可能性或后果还不清楚的风险，通常在项目预算和进度计划中列出一定的应急储备（包括应急资金和时间）来应对
              • 未知风险，也叫未知未知风险，是过去从未遇到过的、完全未知的风险。未知风险，也叫突发风险（Emergent Risk），是只有实际发生后才会知道的风险。例如，第一例非典型肺炎发生前，“非典”就属于未知风险
              • 未知未知风险通常无法预防，只能通过提高项目韧性（抵抗未知未知风险的能力）来减轻万一发生的后果。提高项目韧性的办法包括：在预算中预留充足的管理储备，采用能够灵活变通的项目管理过程，赋予项目团队灵活应变的权力和能力，在项目范围中留出应变的余地
              • 在编制项目预算时，应该把已知已知风险可能造成的损失直接列入项目“直接成本”，把已知未知风险可能造成的损失列入“应急储备”，把未知未知风险可能造成的损失列入“管理储备”
        • 11.1.6 风险态度、偏好、承受力和临界值
          • 风险态度（Risk Attitude）、风险偏好（Risk Appetite）、风险承受力（Risk Tolerance）和风险临界值（RiskThreshold）这四个词，既有联系又有区别
            • 风险态度是指个人或组织认为自己应该冒多大的风险。如果实际所冒风险未超出应该冒的风险，就觉得很舒服、不紧张
            • 风险偏好是指为了实现目标（获得利益），个人或组织愿意冒多大的风险。高风险偏好者愿意为获得大利益而冒大风险，低风险偏好者不愿意为了获得利益而冒看似很小的风险。对于不同的风险，个人或组织可能有不同的风险偏好
            • 风险承受力是指个人或组织能够承受的最高风险程度。如果实际风险水平超出风险承受力，个人或组织就会破产。通常，个人或组织愿意冒的风险（风险偏好）应该小于风险承受力
            • 风险临界值是指个人或组织能够承受的风险程度，而不需要采取应对措施。例如，允许成本超支5%，如果成本超支预计或已经突破5%的临界值，就必须采取预防措施或应急措施
            • 风险临界值是必须采取措施的起点，风险偏好是愿意冒的风险程度，风险承受力是能够承受的最大风险。通常，风险临界值最低，风险偏好中间，风险承受力最高
      • 11.2 各过程的输入与输出
        • 11.2.1 输入与输出的关系总览
          • 项目风险管理的实现过程包括规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险
        • 11.2.2 规划风险管理
          • 在项目章程的指导下，参考项目管理计划中已有的内容，编制风险管理计划。风险管理计划必须与项目管理计划中已有的内容相协调
          • 项目文件中的相关方登记册，有助于邀请相关方参加风险管理计划的编制，有助于根据相关方的情况（如风险态度）确定本项目的风险管理该如何开展
        • 11.2.3 识别风险
          • 因为项目的方方面面都存在可能影响项目目标的不确定性事件，所以识别风险过程的输入其实是非常多的。可以说，项目上的任何一种计划或文件，都可以作为识别风险过程的输入。识别出来的风险及其特性，都应该写入风险登记册，并汇编进风险报告
          • 当然必须根据项目管理计划中的风险管理计划来识别风险。此外，项目管理计划中的其他子计划和项目基准，也都是识别风险的依据
          • 《PMBOK®指南》列出了作为识别风险过程的输入的下列主要项目文件：
            • 相关方登记册。应该邀请尽可能多的相关方参与风险识别，还可以根据相关方登记册预选风险责任人
            • 假设日志。所需的假设条件越多，所面临的制约因素越多，单个项目风险就越多，整体项目风险也会越高
            • 需求文件。各种需求都有实现不了的风险
            • 成本估算。有助于识别不能在规定的成本内完成项目工作的风险
            • 持续时间估算。有助于识别不能在规定时间内完成项目工作的风险
            • 问题日志。虽然问题本身不是风险，但是问题可能引发新的风险
            • 资源需求。有助于识别与资源需求有关的风险
            • 经验教训登记册。重复开展本过程时，需要参考以前的经验教训
          • 对于外包出去的工作，协议和采购文档有助于识别与采购有关的风险
          • 让尽可能多的相关方参与识别风险，尽可能全面地识别出项目风险
        • 11.2.4 实施定性风险分析
          • 在风险管理计划（项目管理计划的组成部分）的指导下，对前一个过程得到的风险登记册（一种项目文件）中的所有风险都进行定性分析。在定性分析中，需要分析相关方登记册（一种项目文件）中的哪些人适合作为各种风险的责任人。作为一种项目文件的假设日志，有利于对风险进行定性分析
        • 11.2.5 实施定量风险分析
          • 在风险管理计划（项目管理计划的组成部分）的指导下，对前一个过程得到的风险登记册（一种项目文件）中的某些风险进行定量分析，然后用这些定量分析的信息、风险登记册中的所有风险的相关信息，以及有关项目不确定性的其他信息，作为输入数据，对整体项目风险进行定量分析。定量分析的结果应该汇编进风险报告。更新后的风险报告属于项目文件更新
          • 项目管理计划中的范围基准、进度基准和成本基准，有助于定量分析实现这些基准将面临的风险
          • 《PMBOK®指南》还列出了作为输入的以下项目文件：
            • 风险报告。已有的风险报告，可以为当前开展整体项目风险定量分析提供依据
            • 假设日志。项目的假设条件和制约因素，都是开展整体项目风险定量分析的依据
            • 成本估算、持续时间估算、估算依据和资源需求。它们既是对某些单个项目风险进行定量分析的依据，也是对整体项目风险进行定量分析的依据
            • 里程碑清单、成本预测和进度预测。应该定量分析实现里程碑、成本预测或进度预测的可能性
        • 11.2.6 规划风险应对
          • 在风险管理计划（项目管理计划的组成部分）的指导下，针对风险登记册和风险报告（都是项目文件）中的风险情况，制定风险应对策略和措施。应对策略和措施，必须与资源管理计划（项目管理计划的组成部分）中用于应对风险的资源相对应，必须与成本基准（项目管理计划的组成部分）中用于风险应对的资金相对应
          • 《PMBOK®指南》还列出了作为输入的以下项目文件：
            • 相关方登记册。制定应对策略和措施，应该邀请相关方参与，征求相关方的意见
            • 项目进度计划。有助于把风险应对活动与进度计划中的相关活动协调起来
            • 项目团队派工单。从中找出谁应该负责哪些风险应对活动
            • 资源日历。从中了解哪些资源何时可用于风险应对
            • 经验教训登记册。重复开展本过程时，需要参考过去的经验教训
          • 规划风险应对过程的结果，应该记入风险登记册和风险报告。更新后的风险登记册和风险报告都属于项目文件更新。重复开展规划风险应对过程，通常都会引发项目计划调整的需要，所以，本过程会提出变更请求
        • 11.2.7 实施风险应对
          • 在风险管理计划（项目管理计划的组成部分）的指导下，由风险责任人负责执行风险登记册（一种项目文件）中的单个项目风险应对策略和措施，由项目经理负责执行风险报告（一种项目文件）中的整体项目风险应对策略和措施。重复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训。风险应对情况需要写入风险登记册和风险报告。更新后的风险登记册和风险报告都属于项目文件更新
          • 开展本过程，可能提出对项目计划的变更请求
        • 11.2.8 监督风险
          • 在风险管理计划（项目管理计划的组成部分）的指导下，由风险责任人监督已写入风险登记册（一种项目文件）的单个项目风险的应对策略和措施的实施情况，由项目经理监督已写入风险报告（一种项目文件）的整体项目风险的应对策略和措施的实施情况。作为一种项目文件的问题日志，有助于监督可能引发风险的各种问题的解决情况。重复开展本过程时，需要参考已写入经验教训登记册（一种项目文件）的经验教训
          • 从工作绩效数据和工作绩效报告中，可以看出风险应对或发生的实际情况，作为监督风险的依据
          • 单个项目风险的实际发生情况与预计发生情况的偏离，需要作为工作绩效信息加以记录
          • 在监督风险过程中所产生的信息需要写入风险登记册和风险报告。更新后的风险登记册和风险报告都属于项目文件更新
          • 后六个过程的最主要的输入是项目管理计划中的风险管理计划，以及前一个过程所得到的风险登记册和风险报告；最主要的输出则是完整程度不等的风险登记册和风险报告
          • 需要根据监督发现的情况，提出必要的变更请求，如要求修改风险管理计划
          • 因为存在两个层面的风险，即整体项目风险和单个项目风险，所以每个风险管理过程其实都可以分成两个不同层面的，即整体项目风险层面的和单个项目风险层面的。这两个层面的风险管理过程，既有联系又有区别
      • 11.3 各过程的主要工作和成果
        • 11.3.1 规划风险管理
          • 本过程旨在对将来的风险管理工作做出安排，包括如何识别风险、如何进行风险分析、如何制定应对策略和措施、如何实施风险应对计划以及如何监控风险。本项目的风险管理将要怎么做、做到什么程度？将要采取什么风险管理做法，不仅取决于项目的复杂程度及规模大小，而且取决于主要相关方的需要。规划风险管理过程，应该邀请尽可能多的相关方参加
          • 各主要项目相关方都要参与风险管理计划的编制工作
          • 风险管理计划应该包括如下主要内容：
            • 风险管理策略。这是关于本项目的风险管理工作的原则性安排
            • 方法论。为实现原则性安排，将采用的风险管理过程、数据资料，以及工具与技术
            • 角色和职责安排。将设立什么风险管理的岗位，各岗位的权责和能力要求
            • 预算和时间安排。将花多少钱和时间做风险管理（需要加到预算和进度计划中），将如何确定、使用和调整项目的应急储备
            • 风险类别。用风险分解结构把大类别风险分解成小类别风险，作为识别风险的出发点
            • 主要相关方的风险偏好。主要相关方对于不同的项目目标或项目风险，究竟是风险冒险者、中立者还是规避者？
            • 风险概率和影响定义。规定表示风险发生的可能性和后果的方法。例如，数字量表（0.1，0.2，0.3…）、相对量表（几乎不发生、很不可能、不可能、可能、很可能、几乎肯定发生）。同时，还要规定可能性多高才算是很高、高、低或很低，后果严重到什么程度才算是很严重、严重、一般、轻或很轻
            • 概率和影响矩阵。根据风险敞口（可能性与后果的乘积）对风险进行分级的表格，也叫风险级别矩阵。例如，把风险分成严重、中等、轻微三个级别。相当于用来度量每个风险的严重性的统一尺子
            • 报告格式。将来要编制的风险管理报告的格式、内容和报送时间等
            • 风险管理跟踪。将如何记录和审查风险管理工作的开展情况
        • 11.3.2 识别风险
          • 本过程旨在对将来的风险管理工作做出安排，包括如何识别风险、如何进行风险分析、如何制定应对策略和措施、如何实施风险应对计划以及如何监控风险。
          • 本过程要回答的问题是：
            • 本项目的风险管理将要怎么做、做到什么程度？
            • 将要采取什么风险管理做法，不仅取决于项目的复杂程度及规模大小，而且取决于主要相关方的需要
            • 规划风险管理过程，应该邀请尽可能多的相关方参加
          • 识别整体项目风险的来源，主要在项目启动阶段开展，而在规划和执行阶段只需要注意整体项目风险的来源的变化情况。整体项目风险的情况应该写入风险报告
            • 识别单个项目风险，主要在项目规划阶段开展，也需要在项目的其他阶段开展
            • 识别风险其实是一个须反复开展的过程，贯穿项目生命周期的始终
          • 通常，风险登记册仅供项目团队内部使用，而风险报告则应该报送给主要相关方
          • 作为识别风险过程的输出，初始的风险登记册中应该包括：
            • 风险编号。每个风险都有独一无二的编号
            • 风险名称。每个风险都有独特的名称
            • 风险描述。尽可能详细地描述风险
            • 预选的风险责任人。供实施定性风险分析过程确认
            • 初步应对措施。只是凭直觉得出的，还要在规划风险应对过程中加以分析和确认
        • 11.3.3 实施定性风险分析
          • 本过程是对所有已识别的单个项目风险进行主观定性分析，评估其可能性、后果和其他情况，并据此进行风险排序，决定哪些风险需要进一步定量分析，哪些风险可直接进行风险应对规划，哪些只需要列入观察清单。其他情况包括风险的可监测性、紧迫性等可能影响风险排序的各种风险参数
          • 即便使用一些数字，只要是主观的分析，仍然是定性分析。所以，从严格意义上讲，不能以是否用到数字来判断是定量还是定性分析
          • 定性风险分析的目的是：
            • 以主观的方式评价已识别风险发生的可能性、后果和其他情况
            • 得到基于定性分析结果的风险排序
            • 为每个单个项目风险指定风险责任人。·确定哪些风险需要进一步定量分析，哪些风险可直接进入规划风险应对过程，哪些风险可直接列入观察清单
            • 对风险进行归类，指出高风险的项目领域
            • 了解风险发展趋势。多次定性分析后，可看出风险发展趋势，如发生可能性是逐渐提高的还是降低的
          • 每个单个项目风险的责任人，在识别风险过程中预选，在定性分析过程中正式指定
          • 定性分析的上述结果都要记入风险登记册，导致风险登记册更新；同时，在风险报告中概述上述分析结果，导致风险报告更新
          • 在项目正式启动之前，需要对整体项目风险做定性分析，以便决定项目能否启动。在规划和执行阶段，要重新对整体项目风险做定性分析，决定项目是否需要变更或提前终止。如果整体项目风险太严重且无法减轻，就不得不提前终止项目
        • 11.3.4 实施定量风险分析
          • 本过程需要做2件事
            • 一是对被定性分析确认为严重且可量化的单个项目风险做客观的定量分析
            • 二是以这些定量分析的结果和全部其他不确定性的情况作为输入数据，对整体项目风险进行定量分析，并据此确定整个项目所需的应急储备
          • 定量风险分析并不是简单的算术计算，而是需要建立比较复杂的数学模型的
          • 对所有项目以及已识别的全部单个项目风险，都要进行定性分析，但不是都要进行定量分析的
          • 定量分析的结果要记入风险报告。定量分析的结果主要包括：
            • 单个项目风险的量化排序
              • 通常是敏感性分析的结果。可用龙卷风图从大到小依次列出对项目目标有不同程度影响的单个项目风险，及其量化的影响程度
            • 整体项目风险的情况。主要包括：
              • ①导致整体项目风险的主要因素
              • ②项目进度和成本的概率分布（一端是最短工期或最低成本及其几乎为0的概率，另一端是最长工期或最高成本及其几乎为1的概率）
              • ③在特定的时间和成本之内完成项目的概率
              • ④整个项目需要预留多少应急储备，以便把项目按期按预算完工的概率提升到所需的水平
            • 风险的发展趋势
              • 多次定量分析后，可以看出一些单个项目风险的发展趋势，以及整体项目风险的发展趋势
            • 风险应对建议
              • 用于定量分析的模型，通常能够自动提出针对单个项目风险或整体项目风险的一些应对建议
          • 实施定性风险分析过程的落脚点是单个项目风险，实施定量风险分析的落脚点则是整体项目风险
        • 11.3.5 规划风险应对
          • 本过程旨在根据定性与定量分析的结果，考虑项目相关方的风险态度、风险偏好、风险承受力和风险临界值，制定整体项目风险的应对策略和措施，以及单个项目风险的应对策略和措施。单个项目风险的应对措施，既包括风险发生之前的预防措施或促进措施，也包括风险发生之后的应急措施或利用措施
          • 开展本过程，通常会导致需要重新开展识别风险、实施定性风险分析、实施定量风险分析等过程
          • 开展本过程，通常也会导致重新开展其他知识领域中的规划过程，即回头调整项目计划
            • 一是因为原先对风险的考虑不尽合理
            • 二是因为需要把风险应对活动及其所需的时间和成本等添加到项目计划中
          • 规划风险应对过程的结果，需要写入风险登记册和风险报告，从而导致对这两份项目文件的更新
            • 风险登记册更新的主要内容包括：
              • 商定的单个项目风险应对策略及措施。主要项目相关方应就应对策略和措施达成一致意见
              • 采取应对措施所需要的时间、成本和其他资源
              • 风险触发因素。也叫风险警告信号或风险症状。出现某种因素、信号或症状时，预示着某个风险即将发生，或者显示某个风险正在或已经发生
              • 针对高优先级且有强烈预警信号的风险的应急预案（计划）
              • 与应急预案配套的弹回计划。这是备用的应急预案（计划），以便在主应急预案（计划）不起作用时采用
              • 次生风险。应对某个风险而带来的另一个风险。如果不应对原生风险，次生风险本来不存在。需要防止次生风险比原生风险更严重
              • 残余风险。采取风险应对措施后仍然存在的风险，是没有主动应对或应对后所剩余的风险。例如，购买保险（风险应对）后，保险公司的免赔额（万一风险发生，你仍要承担这个损失）
            • 风险报告更新的主要内容包括：
              • 针对整体项目风险的应对策略和措施，以及它们对整体项目风险的预期效果
              • 针对高优先级单个项目风险的应对措施概述
          • 应该定期或不定期对风险应对策略和措施进行审查和更新，以确保有效性
        • 11.3.6 实施风险应对
          • 在本过程中，单个项目风险的责任人必须根据规划风险应对过程的结果，组织所需的资源，去实施风险应对策略和措施，以便提高机会，减轻威胁
          • 在本过程中，项目经理作为整体项目风险的责任人，必须根据规划风险应对过程的结果，组织所需的资源，采取已商定的应对策略和措施处理整体项目风险，使整体项目风险保持在合理水平
          • 单个项目风险的应对策略和措施的实施情况，应该记入风险登记册；整体项目风险的应对策略和措施的实施情况，应该记入风险报告
        • 11.3.7 监督风险
          • 在本过程中，监督整体项目风险和单个项目风险的应对策略和措施的实施情况，跟踪整体项目风险和已识别的单个项目风险的变化，监测残余风险，识别和分析新风险，并评价风险管理的有效性，提出变更请求
          • 本过程的主要工作包括：
            • 注意风险触发因素。是否出现了某种风险预警信号？
            • 追踪已识别的单个项目风险，包括应对情况。例如，发生的可能性和后果是否已经发生变化？
            • 监测与已识别的单个项目风险有关的残余风险和次生风险
            • 附带地识别和分析一些新的单个项目风险
            • 监督整体项目风险的应对情况。整体项目风险是变大了还是变小了？
            • 开展风险审计，评估风险管理工作的有效性
            • 与项目相关方沟通项目风险情况
            • 必要时提出变更请求，以便制定新的应对措施，甚至新的应对策略
            • 收集风险资料，更新风险登记册、风险报告和组织过程资产
          • 风险登记册和风险报告的内容都要通过各个风险管理过程来不断更新和逐渐完善
          • 作为消极风险的威胁一旦发生，就成了“问题”；作为积极风险的机会一旦出现，就成了“利益”。对问题或利益，要及时发现，并与项目相关方密切合作，进行处置或利用
      • 11.4 各过程的工具与技术
        • 11.4.1 规划风险管理
          • 借助数据分析、会议和专家判断，编制风险管理计划。数据分析中的相关方分析，有助于分析相关方的风险态度、偏好、临界值和承受力；也可以借助数据分析技术来分析项目失败的风险敞口。这些因素都对本项目的风险管理应该怎么做有直接影响。应该邀请主要相关方，召开风险管理规划会议，讨论项目的风险管理应该做到什么程度
        • 11.4.2 识别风险
          • 包括头脑风暴、核对单和访谈在内的各种数据收集技术，都是识别风险时常用的技术
            • 头脑风暴用于召集许多人通过集思广益来识别尽可能多的风险
            • 过去项目积累下来或行业中标准化的核对单，用于判断核对单所列的各种风险在本项目上是否也存在。也可以分析核对单本身的不完整性，识别出因此而导致的风险
            • 可以对相关人员进行访谈，识别出一些风险
          • 包括文件分析、根本原因分析、SWOT分析、假设条件和制约因素分析等在内的数据分析技术，也是识别风险时常用的技术
          • 通过根本原因分析，把导致某个问题的各种可能原因挖掘出来，每个可能的原因就是一个风险
          • 通过SWOT分析（优势、劣势、机会、威胁）分析，从组织或项目团队的优势中识别出机会，从劣势中识别出威胁
          • 通过分析假设条件和制约因素，识别出相应的威胁或机会
          • 无论使用数据收集还是数据分析技术，都应该借助会议、人际关系与团队技能和专家判断
          • 提示清单则为识别风险提供出发点
          • 应该尽可能用多种多样的方法去识别风险，并邀请众多相关方参与风险识别
        • 11.4.3 实施定性风险分析
          • 除了专家判断、会议和人际关系与团队技能中的引导技术，其他的工具与技术，可以按下列顺序使用：
            • （1）使用数据收集中的访谈，去收集相关的风险数据
            • （2）使用数据分析中的风险数据质量评估，来评估风险数据的质量，确保只有质量可靠的数据才用于定性分析
            • （3）基于风险数据，使用数据分析中的风险概率和影响评估、其他风险参数评估，来评估风险发生的概率、影响和其他参数（如紧迫性、可监测性）
            • （4）综合（3）的结果，使用数据表现中的概率和影响矩阵或层级图，对每个风险进行分级
            • （5）按共同原因、项目部位或时间段，对各种风险进行风险分类，发现高风险的项目领域，以便更有针对性地管理项目风险
            • 虽然概率和影响矩阵通常是由数字构成的，却是实施定性风险分析过程的工具
        • 11.4.4 实施定量风险分析
          • 除了专家判断和人际关系与团队技能中的引导技术，其他的工具与技术可以按下列顺序使用：
            • （1）使用数据收集中的访谈，收集专家们的量化数据
            • （2）结合访谈收集的数据和其他来源的数据，使用不确定性表现方式来生成各种适用的概率分布图
              • 概率分布图能够展示各活动的可能工期或成本的分布情况，作为后续定量分析的基础
              • 常用的概率分布图包括贝塔分布、三角分布、均匀分布和正态分布
            • （3）使用数据分析中的影响图、模拟、敏感性分析和决策树分析，进行风险定量分析，得出分析结果
          • 可以借助影响图建立与风险有关的情景，找出具有不确定性的各种因素，再用模拟或敏感性分析来分析哪些因素对项目有最显著的影响
          • 最常用的模拟技术是蒙特卡洛模拟，即在计算机上模拟项目实施成千上万次，看看有多少次是在多少天或多少成本之内完工的
          • 敏感性分析用来确定某一变量的单位变化对项目的影响程度
          • 决策树分析是计算各种备选方案的预期货币价值。决策树分析是为了对将来的事情做出决策。决策树同级分支的概率之和必须等于1
          • PMP®考试中可能考到决策树方面的计算题，所以必须彻底掌握《PMBOK®指南》中图11-15的内容
        • 11.4.5 规划风险应对
          • 下面对除专家判断以外的工具与技术进行解释。
            • 通过数据收集技术中的访谈，了解各主要相关方对风险应对策略和措施的喜好
            • 通过人际关系与团队技能中的引导，引导相关方对应对策略和措施达成一致意见
            • 通过数据分析中的备选方案分析，分析多种备选的应对策略和措施。开展备选方案分析时，需要进行成本效益分析，以选择效益成本比最高的策略和措施
            • 决策技术中的多标准决策分析，也是用来做备选方案分析的一种具体技术，即从多种标准入手对多个方案进行排序，以选择排序靠前的方案
          • 针对威胁，可以采取5种应对策略：
            • 上报。对于应该在更高的项目集、项目组合或整个组织层面来处理的风险，项目经理应该采取上报策略
            • 规避。通过消灭原因来消除风险，如取消高风险的工作；或者，把项目与某个风险隔离开来，如抢在雨季到来之前完成项目，使项目不受雨季的影响。采取规避策略，通常要改变项目计划
            • 减轻。设法降低风险发生的概率或（和）后果。例如，使用成熟技术和熟练工人，对机器操作人员进行培训，开车时系好安全带
            • 转移。用一定的代价，把应对风险的责任与风险的后果转移给第三方。通常，需要签署风险转移合同。例如，购买保险，把工作外包，业主要求承包商提交由银行出具的履约担保
            • 接受。不主动管理风险。对于可承受的风险或无法用其他策略的风险，可以使用接受策略。接受又分成两种：
              • 一种是被动接受，即不采取任何行动，顺其自然，风险发生后再说
              • 另一种是主动接受，即预留应急储备，以便风险发生后使用
            • 对于整个项目的应急储备，如果没有任何可靠的依据，就按项目总成本的10%计算。这是一个经验式规则
          • 在一个项目中，对不同的风险，通常要采用不同的应对策略。风险减轻、转移和接受策略，可以在某一个风险上组合使用，即同时采取这三种策略
          • 对于不严重的风险（通常是采用“接受”策略的风险），不可以简单地置之不理，而需要记录下来，注意观察，防止变严重
          • 选择风险应对策略不仅是项目经理和项目团队的事情，也是其他主要相关方的事情。大家要对风险应对策略达成一致意见
          • 针对机会，也可以采取五种应对策略：
            • 上报。把机会上报给更高层去管理
            • 开拓。采取措施，确保机会肯定出现。与威胁规避正好相反
            • 分享。与其他方一起共同促进机会发生，共享机会发生的利益
            • 提高。采取措施，提高机会出现的可能性或影响
            • 接受。不主动促进机会发生，只是在机会自然发生时利用机会
          • 针对整体项目风险，可以采取五种应对策略：
            • 规避。通过取消某种或某些高威胁的工作来降低整体项目风险水平。如果整体项目风险太高且无法降低，就不得不提前终止整个项目
            • 开拓。扩大项目范围，确保抓住某种即将出现的巨大机会，以提高项目对相关方的价值
            • 转移或分享。如果负面的整体项目风险太高，就采取转移策略；如果正面的整体项目风险很大且仅靠自身力量难以实现，就采取分享策略
            • 减轻或提高。采取措施，降低整体项目风险（威胁）的水平，提高整体项目目标出现正向变异的可能性（如提前完工）
            • 接受。按当前的状况继续实施项目，不采取任何主动的应对措施
            • 在实际工作中，威胁、机会和整体项目风险的应对策略并不能截然分开，往往是交叉在一起的
          • 应急应对策略既可以针对单个项目风险（机会或威胁），也可以针对整体项目风险，相当于我们平时所说的应急预案。对于很大且有明显预警信号的威胁或机会，可以制定应急应对策略及其启动条件
        • 11.4.6 实施风险应对
          • 本过程的工具与技术只有三个：专家判断、项目管理信息系统、人际关系与团队技能
            • 对于要由项目团队以外的人去实施的应对措施，项目经理就需要施展个人影响力（属于人际关系与团队技能）
            • 影响力是指在没有正式职权的情况下使他人服从自己的能力
          • 11.4.7 监督风险
            • 召开风险审查会（属于会议），审查应对策略和措施的实施情况，重新评估风险发生的可能性、后果和其他情况
            • 采用数据分析技术中的储备分析，来考察项目的进度和成本绩效，判断预留的应急时间和应急资金是否仍然合理
            • 采用数据分析技术中的技术绩效分析，来考察项目的范围和质量绩效，据此评价风险的实际影响，预判未来可能的影响
            • 开展风险审计，总结风险管理方面的经验教训，为以后的风险管理积累新的知识
    • 第12章 项目采购管理
      • 12.1 基础知识
        • 12.1.1 概述
          • 项目采购管理是指项目执行组织从外部获取产品、服务或成果来最优满足项目的需求。由于项目的复杂性，项目执行组织往往不可能依靠自身的力量完成全部项目工作，而是需要把某些项目工作外包给其他组织进行。外包通常是以合同的形式进行的
          • 一个项目可能有多个执行组织。如果某个执行组织与其他执行组织之间需要签订正式的项目工作合同，就需要运用项目采购管理的知识
          • 在PMP®考试中，除非题目另有特别要求，有关采购管理的问题都是从买方的角度提出的。虽然业主是最经常的买方，但是买方不局限于业主。承包商或其他项目执行组织在许多情况下也会成为买方
          • 判断买方的标准是：支付金钱获得产品、服务或成果的一方
          • 因为从外部获取货物或服务是通过合同进行的，所以采购管理也是围绕合同开展的。合同签订之前，需要做大量准备工作；合同签订之后，需要执行和管理合同；合同关闭前，需要开展合同收尾工作
          • 需要重点掌握：
            • 合同的性质。合同是很严肃的，具有法律效力。
            • 合同当事人之间的关系。合同当事人之间是地位平等和权责对等的关系
            • 合同签订的条件、程序。合同双方需要具备相应的权利与行为能力才能签合同；双方通过一定程序达成一致意见，才能成立合同
            • 合同的种类、各种类的特点及适用的项目。各种合同有各自的优缺点，适用于不同的项目
            • 合同的主要条款。只有具备这些条款，合同才能有效
            • 合同的风险分担，即如何在当事人之间分配风险
            • 合同绩效监控及合同变更，即如何监控合同绩效，如何管理合同变更
            • 合同争议的解决，即对协商不能达成一致的事项，应该如何解决
            • 合同的终止，包括未完成前的提前终止与完成时的正常终止
        • 12.1.2 合同的性质
          • 合同是用来明确当事人双方权利义务关系的，是对双方都具有法律约束力的协议。合同肯定是协议，但协议不一定是严格意义上的合同。不具有可操作性的协议就不能成为严格意义上的合同
          • 《PMBOK®指南》中对“协议”和“合同”这两个词的使用比较混乱，其中大多数“协议”都应理解成“合同”
          • 通常，意向书不具有约束力，备忘录不具有正式约束力，协议具有有限约束力，合同则具有正式（法律）约束力
          • 合同一旦签订，其中的所有条款都必须执行，除非个别条款违反法律规定。合同任何一方不能只执行对自己有利的条款，也不能有利时就执行，不利时就不执行
          • 合同是双方当事人协商一致的产物，当事人处于平等地位
          • 合同是双方当事人之间的约定，不应该涉及第三方的权利义务，除非这个第三方是其中一方当事人的代表或按法律规定所必需的
          • 在项目的所有文件中，合同是最正式的，没有哪个文件会比合同更加正式。对合同的修改必须以正式、书面的方式进行
          • 任何合同都是在一定的法律背景下起作用的。法律是合同效力的保障。法律也为解决合同争议提供了最后的途径，即诉讼
          • 合同签订后，可以提出变更，但变更须经双方当事人一致同意。如无法达成一致，则按解决争议的方法解决
        • 12.1.3 合同成立及其主要条款
          • 要约（Offer）和承诺（Acceptance）是合同成立的必要且充分条件
            • 要约，又称发盘或报价，是一方当事人向另一方当事人所做的、邀请订立合同的意思表示
            • 承诺则是被要约人无条件、完全地同意要约人的要约，愿意按此成立合同的意思表示
            • 合同是否成立，不取决于有无一份双方都在上面签过字的协议，而取决于是否已经完成要约和承诺
            • 只要完成了要约和承诺，即便没有一份双方都签过字的协议，合同也已成立
          • 合同通过许多具体条款来明确双方的权利义务关系。合同条款应该明确、齐全，便于双方全面、严格地履行合同。合同应当具备以下几个主要条款：
            • 标的（指货物、劳务、工程项目等）。没有标的，权利义务就无所指向，合同也就根本无法存在
            • 数量和质量。这是对标的的具体要求
            • 价款或酬金。这是一方向交付标的的另一方支付的对等代价
            • 履行合同的期限、地点和方式。这是指当事人必须在什么时间、什么地点，以什么方式履行义务和享受权利
            • 违约责任。这是指一方因过错不能履行或不能完全履行合同，而侵犯另一方的权利时，必须承担的经济责任
          • 在较大的合同中，通常还有争议解决条款。也就是，由双方当事人自行约定争议的解决方式，以便他们对争议的解决有更大的自主权，而不需要一有争议就到法院打官司
          • 针对PMP®考试，还应该了解合同中的以下重要条款：
            • 工作范围。合同规定的工作范围是什么？《PMBOK®指南》指出，买方用“采购工作说明书”明确合同的工作范围，卖方在获得合同后要及时编制“合同工作分解结构”，与买方确认工作范围
            • 合同转让。任何一方都不能随意把合同权利或义务转让给第三方，合同转让必须征得另一方的同意
            • 合同付款。有什么种类的付款？什么时候支付？付款的程序与条件是什么？延迟支付的利息如何计算？
            • 合同工作的验收。工作达到何种数量和质量要求、在何时完成，才是可以接受的？应该通过何种程序来验收？
            • 合同代表及其权力。谁是合同当事人的代表？有什么权力？
            • 违约。什么构成违约？违约方应承担什么责任？如规定的违约金，它是事先确定的、针对某种特定违约的赔偿金
            • 担保。合同当事人应提供什么担保？如承包商应提供的预付款担保和履约担保，还有以保留金形式的现金担保
            • 报告。什么时候、以什么方式、向谁提交何种报告？
            • 不可抗力。什么是不可抗力以及不可抗力的风险如何分担？不可抗力引起的损失，通常落在谁头上，就由谁承担
            • 合同变更。变更的程序、时间、种类和谈判等
            • 索赔。根据合同或法律，一方可以向另一方索取损失补偿。合同中需要明确索赔的条件与程序
            • 弃权。一方以行为（有意或无意）放弃合同中的部分权利
            • 争议解决。双方当事人协商不成，就产生“争议”。合同中可以约定争议解决办法
            • 合同终止。包括在工作未全部完成之前终止合同以及工作全部完成后终止合同
          • 一方违约，另一方必须在发现这种违约之后及时书面通知违约方，声明对方已经违约并保留自己的索赔权利
      • 12.2 合同类型：总价合同+成本补偿合同+工料合同
        • 这是PMP®考试中的重要内容之一。考生必须弄清楚合同的类型及其特点、适用的项目。考试中可能出现情景题，让你选择最适合的合同类型
          • 按《PMBOK®指南》，有三种基本的合同类型，即总价合同、成本补偿合同和工料合同
          • 在实际工作中，这些合同类型可以混合使用，即在同一个合同中，有些工作采用总价合同，有些采用成本补偿合同，有些又采用工料合同
        • 12.2.1 总价合同
          • 总价合同是指对合同工作规定一个总价。从成本风险的角度来说，业主的成本风险最低，基本没有成本风险。在这种合同下，买方必须准确定义工作范围。只有工作范围很清楚的项目，才可以采用总价合同。如果工作范围发生变化，通常允许调整总价
          • 总价合同又可以衍生出：固定总价合同+总价加经济价格调整合同+总价加激励费用合同
            • （1）固定总价合同（Firm Fixed Price，FFP）。在既定的工作范围之下，价格是绝对固定的。除非工作范围出现变更，否则不允许调整价格
            • （2）总价加经济价格调整合同（Fixed Price with EconomicPrice Adjustment，FPEPA）。在总价的基础上，允许根据通货膨胀情况来调整合同价格。适用于履行期较长（跨年度）的合同。合同中应该规定详细的价格调整方法，如调价系数的计算公式，以及公式中的价格指数的来源
            • （3）总价加激励费用合同（Fixed Price Incentive Fee，FPIF）。在总价的基础上，规定相应的激励费用，以调动卖方的积极性，使买卖双方的目标趋于一致。在这种合同下，通常会规定一个最高限价。付款总数不得超过最高限价。激励费用的计算基础可以是某种绩效标准，如目标工期、目标成本、质量达标率
              • 基于目标工期的总价加激励费用合同比较好理解，规定合同总价、提前完工奖励或延误完工罚款、最高限价，有时还会规定最低限价。
              • 基于目标成本的总价加激励费用合同比较复杂，在过去的PMP®考试中也出现过。合同中需要规定：
                • 目标成本。正常情况下项目将要花费的成本
                • 目标费用（利润）。如果卖方以目标成本完成项目，将可以获得的利润
                • 目标价格。目标成本与目标费用之和
                • 最悲观成本。如果卖方没有任何管理或技术上的失误，项目可能发生的最大成本数。如果卖方实际成本超出此数，则认为超出部分是卖方失误造成的，全部由卖方独自承担。由于最悲观成本是假设的最大成本数，因此其正规术语是“Point ofTotal Assumption（PTA）”，可翻译成“总体假设点”
                • 最悲观成本（PTA）具有如下意义：
                  • 在实际成本未超过PTA之前，成本超支数由买方与卖方按事先约定的比例分担。一旦实际成本突破PTA值，卖方必须独自承担高于PTA值的全部超支数（买方不再分担）
                  • 在实际成本达到PTA时，买方向卖方支付的合同价款也就达到最高限价。这之后无论实际成本多高，买方都只向卖方支付最高限价
                  • 知道了PTA，卖方就可以更好地控制成本。随着实际成本超过目标成本，卖方的可得利润数会逐步减少
                • 成本分担比例。卖方实际成本（不得超过最悲观成本）超过目标成本的部分，买方和卖方按比例分担
                • 最高限价（封顶价）。买方可能向卖方支付的最高价格。无论如何，合同付款不得超出此数
                • 其中，最悲观成本、成本分担比例和最高限价是紧密相连的，知道了其中的任意两个，就可以计算出剩余的第三个。基本的计算公式如下：
                  • 最高限价=（目标成本+目标利润）+（最悲观成本−目标成本）×买方分担比例
                  • 买方分担比例=（最高限价−目标价格）/（最悲观成本−目标成本）
                  • 最悲观成本=［（最高限价−目标价格）/买方分担比例］+目标成本
              • 在基于目标成本的总价加激励费用合同中，买方并不分享可能的成本节约（实际成本低于目标成本的部分）
        • 12.2.2 成本补偿合同
          • 成本补偿合同是指以卖方从事项目工作的实际成本作为付款的基础，即成本实报实销。在这种合同下，买方的成本风险最大
            • 这种合同适用于买方仅知道要一个什么产品但不知道具体工作范围的情况，也就是工作范围很不清楚的项目
            • 当然，成本补偿合同也适用于买方特别信得过卖方、想要与卖方全面合作的情况
          • 卖方在获得成本补偿的基础上，还需要获得一定的利润。根据利润的计算方法不同，成本补偿合同又可分为：成本固定费用+成本加激励费用+成本加奖励费用+成本加百分比
            • （1）成本加固定费用（Cost Plus Fixed Fee，CPFF）
              • 成本实报实销，买方另外向卖方支付固定金额的利润
              • 这是最常用的成本补偿合同，对卖方有一定的制约作用。无论实际成本是多少，利润都保持不变（在合同中规定的金额）
            • （2）成本加激励费用（Cost Plus Incentive Fee，CPIF）
              • 买方向卖方的付款由3部分组成：实际成本、一笔固定的费用、按合同规定的方法计算的对固定费用的调整数
                • 这种合同与“总价加激励费用合同”类似，会规定目标成本、目标费用（固定费用）和成本超支分担比例
                • 不同的是，在成本加激励费用合同中，不会规定最高限价，但会规定成本节约的分享比例。如果卖方的实际成本低于目标成本，节约部分由双方按一定比例分享（如60/40，即买方60%，卖方40%）
                • 如果卖方的实际成本高于目标成本，超支部分由双方按比例分担（如60/40，即买方60%，卖方40%）
                • 在成本加激励费用合同下:
                  • 如果实际成本大于目标成本，卖方可得的付款总数=目标成本+目标费用+买方应负担的成本超支
                  • 如果实际成本小于目标成本，卖方可得的付款总数=目标成本+目标费用−买方应享受的成本节约
            • （3）成本加奖励费用（Cost Plus Award Fee，CPAF）
              • 成本实报实销，买方再凭自己的主观感觉给卖方支付一笔利润，而卖方对利润数没有任何讨价还价的余地
            • （4）成本加百分比（Cost Plus Percentage of Cost，CPPC）
              • 买方在卖方实际成本的基础上，再加上以该成本的某个百分比计算的利润，向卖方付款。由于买方通常不喜欢用这种合同，《PMBOK®指南》中已删去这种合同
            • 注意：费用（Fee）不同于成本（Cost）。在成本补偿合同中，费用主要是卖方可以得到的利润。
        • 12.2.3 工料合同
          • 工料合同，也叫“时间和手段合同”，是指按项目工作所花费的实际工时数和材料数、事先确定的单位工时费用标准（单价）和单位材料费用标准（单价）付款
            • 这类合同适用于工作性质清楚但具体的工作量无法确定的采购
            • 在这种合同下，买方与卖方分担成本风险，即买方承担工作量的风险，卖方承担单价的风险
          • 需要注意的是，《PMBOK®指南》中没有提到大型土木工程经常使用的“综合单价合同”。在综合单价合同下，买方按实际工程量和合同规定的综合单价向卖方付款。综合单价是把人工费、材料费、设备费、管理费和利润都综合在一起的。工料合同中的单价不是综合单价，而是针对每种人工、材料或设备的单价，如每小时钢筋工的单价、每立方米木材的单价、每个台班设备的单价
          • 工料合同适用于规模小、工期短、不复杂的工作，而不适用于规模大、工期长、很复杂的工作。如果对后面这种工作使用工料合同，那么合同管理工作将十分烦琐，会导致管理成本的不合理上升
          • 项目中的另一种常用合同是订购单。非大量采购标准化产品，通常可以由买方直接填写卖方提供的订购单，卖方照此供货。因为订购单通常不需要谈判，所以又叫单边合同
        • 在考试中，可能有题目要求选择最合适的合同种类。关于合同种类的选择：
          • 如果工作范围很明确，项目的设计已具备充分的细节，则使用总价合同
          • 如果工作性质清楚，但工作量无法确定，而且工作不复杂，又需要快速签订合同，就用工料合同。工料合同常用于聘请咨询专家，紧急招聘人员来替代突然离职的团队成员，聘请技术专家检修机器
          • 如果工作范围很不清楚，就用成本补偿合同
          • 如果希望双方分担风险，就用工料合同
          • 如果希望买方承担成本风险，就用成本补偿合同
          • 如果希望卖方承担成本风险，就用总价合同
          • 从买方的角度讲，除非万不得已，不要选用成本加百分比合同
          • 如果购买标准产品，且数量不大，就用“单边合同”，即直接发出订购单
      • 12.3 各过程的输入与输出
        • 12.3.1 输入与输出的关系总览
          • 项目采购管理的实现过程包括规划采购管理、实施采购和控制采购
        • 12.3.2 规划采购管理
          • 规划采购管理过程的输入和输出：
            • 在项目章程的指导下编制关于采购的计划和文件
            • 关于采购的计划和文件都必须符合商业文件（包括商业论证和效益管理计划）中的规定，有利于实现商业文件中的要求
            • 项目管理计划中的范围管理计划，有助于策划该如何管理拟外包工作的范围；质量管理计划有助于确定拟外包工作的质量标准和质量管理方法；资源管理计划有助于确定哪些资源需要外购；范围基准有助于确定哪些WBS要素需要外包出去
            • 项目文件中的里程碑清单有助于确定重要的可交付成果的交付日期；项目团队派工单有助于了解哪些团队成员应该对采购工作承担什么职责；需求文件有助于确定哪些需求必须依靠外购来实现；需求跟踪矩阵有助于确定为了实现特定的高层目标而必须交付哪些可交付成果；资源需求有助于确定哪些资源必须外购；风险登记册有助于确定哪些风险应该采取转移策略；相关方登记册有助于了解与采购工作有密切关系的相关方
            • 本过程的主要输出，请见下文12.4.1节
            • 关于采购的计划和文件编制出来后，可能需要提出变更请求，回头调整已有的项目计划
        • 12.3.3 实施采购
          • 实施采购过程的输入和输出：
            • 根据项目管理计划中的相关内容开展实施采购过程:
              • 需求管理计划有助于识别和分析拟通过采购来实现的需求
              • 范围管理计划有助于合理确定拟外包工作的范围
              • 沟通管理计划有助于在实施采购过程中开展有效的沟通
              • 风险管理计划有助于分析和管理与采购工作有关的风险
              • 采购管理计划有助于按正确的程序实施各种采购管理活动
              • 配置管理计划有助于确定卖方必须实现的重要技术参数
              • 成本基准有助于把采购的成本控制在规定的数额内
            • 项目文件中的:
              • 项目进度计划有助于确定该在何时开展采购活动以及卖方必须在何时交付可交付成果
              • 需求文件有助于评价卖方建议书中的方案能否实现既定的需求
              • 风险登记册有助于评估与特定潜在卖方及其建议书有关的风险
              • 相关方登记册有助于邀请潜在卖方（也属于相关方）提交建议书，以及考虑各主要相关方对建议书评审的要求和期望
            • 把前一个过程所编制的各种文件归并为采购文档，作为本过程的输入
              • 在本过程中，买方根据自制或外购决策，以及采购策略，把包含采购工作说明书在内的招标文件发给潜在卖方
              • 然后，潜在卖方准备卖方建议书并报给买方。买方再按供方选择标准和独立成本估算对卖方建议书进行评审
            • 买方评审卖方建议书后，选定一家中标商（选定的卖方），报给领导审批。领导审批后，买方正式与中标商签订协议（合同）
            • 协议签订后，可能需要提出变更请求，回头修改项目计划
            • 再次开展采购时，需要参考经验教训登记册（一种项目文件）
        • 12.3.4 控制采购
          • 控制采购过程的输入和输出：
            • 根据项目管理计划开展控制采购过程
              • 需求管理计划有助于有效监控合同执行是否能够有效实现既定的需求
              • 风险管理计划有助于管理与合同执行有关的风险
              • 采购管理计划有助于按既定的程序监控合同执行绩效
              • 变更管理计划有助于处理与合同有关的变更
              • 进度基准有助于监控合同执行是否能够保证项目进度目标的实现
            • 各种项目文件是本过程的输入
              • 假设日志有助于监督与合同执行有关的假设条件的落实情况以及制约因素是否有变化
              • 里程碑清单有助于监督卖方提交可交付成果的时间能否满足里程碑实现时间的要求
              • 质量报告有助于发现卖方的工作过程或结果的质量问题
              • 需求文件和需求跟踪矩阵有助于监控卖方的工作能否实现项目既定的需求
              • 风险登记册有助于监控合同执行中的风险
              • 相关方登记册有助于了解哪些相关方最关心合同的执行绩效
              • 重复开展本过程时，需要参考已写入经验教训登记册的经验教训
            • 需要把体现在工作绩效数据和采购文档中的合同执行绩效，与协议和采购文档中的要求进行比较。采购文档中既有规划阶段编制的文件（如招标文件），也有执行阶段形成的文件（如买方和卖方之间的往来函件）
            • 通过监控，发现合同执行绩效的偏差，形成工作绩效信息。如果合同执行绩效不理想，就提出变更请求
            • 对要求修改合同的变更请求，无论是哪方提出的，都要由双方协商。协商达成一致，就变成批准的变更请求，即合同变更令。后续的控制采购过程就应该根据批准的变更请求去开展
            • 收集本过程得到的各种文件，形成采购文档更新。再根据采购管理计划和最新的采购文档，关闭合同，得到结束的采购
      • 12.4 各过程的主要工作和成果
        • 12.4.1 规划采购管理
          • 本过程旨在确定哪些工作要外包，编制招标采购计划和文件，为开展招标采购做好准备。本过程的输出，除了作为程序性计划的采购管理计划，其他所有输出都属于实体性计划
          • 在本过程中，按以下基本顺序开展如下工作：
            • （1）编制采购管理计划
              • 采购管理计划是关于将如何开展采购工作的计划，需要说明将如何做出自制或外购决策，如何识别潜在卖方，如何编写采购文件，采用何种采购方法，采用什么合同类型，如何选择卖方，如何管理合同，如何开展合同收尾。采购管理计划所包括的内容可以很多，取决于项目的需要。它是项目管理计划的组成部分
            • （2）做出自制或外购决策
              • 自制或外购决策是关于哪些工作要自己做、哪些工作要外包出去的决定，可以用表格列明
            • （3）制定采购策略
              • 采购策略是针对单次特定的采购，对采购管理计划中的相关内容的具体化。整个项目只有一份采购管理计划，但也许有多份采购策略，每份采购策略针对一次特定的采购
              • 《PMBOK®指南》中详细规定了采购策略的三部分内容，即交付方式（如总承包方式）、合同类型（如总价合同）和采购阶段（是否分阶段采购）
              • 采购策略中的这些内容都需要在后续的采购工作说明书、招标文件和协议（合同）中进一步具体化
            • （4）编制采购工作说明书
              • 采购工作说明书是对即将外包出去的那些工作的书面描述，用来告诉潜在卖方需要他们做什么工作，以便他们判断是否有能力、有兴趣承接该工作
              • 有能力、有兴趣的潜在卖方还可以据此提出承接工作的建议书或报价
              • 采购工作说明书相当于即将外包出去的工作的范围说明书
            • （5）编制招标文件
              • 招标文件用于邀请潜在卖方提交投标书、建议书或报价。《PMBOK®指南》提到了“信息邀请书”“建议邀请书”和“报价邀请书”等词语
              • 信息邀请书，严格地讲，并不是一种招标文件，只是用于邀请厂家提供更多的信息
              • 如果主要依据技术方案来选择卖方，就使用“建议邀请书”；如果主要依据价格选择卖方，就使用“报价邀请书”；如果同时考虑技术方案和报价，就使用狭义上的“招标文件”。例如，要采购咨询服务，通常用“建议邀请书”
            • （6）编制独立成本估算，即俗称的“标底”
              • 买方自己要预判一下完成合同工作将需要多少钱
            • （7）编制供方选择标准，即评标标准
              • 主要的评标程序和标准应该写入招标文件，详细的评标程序和标准不必写入。在价格不是唯一决定因素的采购中，评标程序和标准是非常重要的
            • （8）汇编成招标文件包
              • 把采购工作说明书、招标文件、主要的供方选择标准等汇编成招标文件包，以便在实施采购过程中向潜在供应商发放
        • 12.4.2 实施采购
          • 本过程是按采购管理计划和采购策略中规定的采购方法，开展实际的招标采购（包括招标、投标、评标和授标这四个环节），签订采购合同
          • 采购方法是多种多样的，应根据具体情况选用。例如：
            • 直接采购。直接邀请某一家厂商报价或提交建议书，没有竞争性
            • 邀请招标。邀请一些厂家报价或提交建议书，具有有限竞争性
            • 竞争招标。公开发布招标广告，以便潜在卖方报价或提交建议书，具有很大的竞争性
          • 应该尽可能采用竞争招标的方式。只有在下列情况下，可以采用非竞争方式：
            • 项目的时间很紧，没有时间编制竞争招标所要求的招标文件
            • 只有唯一的一个供应商能够提供所需货物或服务，别无选择，这种情况叫“独有来源”（Sole Source）
            • 虽然有多个供应商能够提供所需货物或服务，但买方因确信某个特定供应商具有特别的优势，而直接向该供应商采购。这种情况叫“单一来源”（Single Source）
            • 在非竞争的情况下，也能得到合理、有利的价格和产品。例如，规模很小的采购、不具有吸引力的采购
          • 如果打算向过去已合作多年的厂家直接采购，即开展单一来源采购，在做出决定之前，仍然必须审查该厂家是否有资格承接本次工作任务
          • 由政府公共资金资助的采购，通常都必须用竞争招标的方式，以保证所有合格的潜在卖方都获得公平的竞争机会
          • 下面以竞争招标方式为例，讨论实施采购过程
            • 招标与投标在合同成立过程中起要约邀请和要约的作用。首先，买方发出招标文件，邀请潜在卖方要约；其次，潜在卖方购买招标文件，并应邀参加投标人会议；最后，潜在卖方根据招标文件编制投标文件，进行投标，向买方要约。由于要约对要约人有约束力，因此潜在卖方在投标时需要提交投标保证金或投标担保。在规定的投标有效期内，投标文件对投标人具有约束力。他不得撤回或修改投标文件，否则投标保证金或担保就要被招标方没收
            • 招标方收到投标文件后，就要按既定的评标程序和标准开展评标工作。评标工作通常由专门的评标委员会进行。评标委员会编写评标报告，推荐某投标商中标，并建议招标方的高级管理层授予合同
            • 基于评标委员会的推荐，招标方的高级管理层正式批准某厂商中标，并向其发出授标信，与其成立合同。授标信起“承诺”的作用。在该厂商收到授标信时，合同就正式成立，哪怕这时还没有一页双方都在上面签过字的协议
          • 在《PMBOK®指南》中，实施采购过程的第二个输出“协议”，理解成“合同”更合适
        • 12.4.3 控制采购
          • 控制采购过程是管理合同双方的合同关系，监控合同工作绩效，管理合同变更。简单地说，就是随合同执行进行合同管理。必须从确保项目目标实现的高度来开展控制采购过程
          • 合同签订以后，千万不要把它扔到一边，只是到迫不得已需要时才去查一查。对合同一定要熟读，一定要掌握合同的整体精神，并且在日常工作中按合同的要求去做
          • 合同管理的目的，不仅是要促使合同双方认真履行各自的合同义务，而且是要充分协调好双方之间的合同行为，在双方之间建立一种相互支持、相互促进的伙伴型关系，以便通过严格的过程控制来达到范围、进度、成本和质量的整体最优，保证合同工作按计划有效完成
          • 合同解释是合同管理工作中的重点和难点之一。合同解释应该遵循的几个主要原则是：
            • 主导语言原则：如果合同存在两种语言的文本，必须约定哪一种语言是主导语言。当两者不一致时，应该以主导语言文本为准
            • 适用法律原则：确定以哪个国家的法律作为合同的适用法律。合同的解释必须根据适用法律进行
            • 整体解释原则：
              • 合同是一个整体，不能割断各部分之间的联系，不能断章取义
              • 在长期的合同实践中，已经形成一套公认的合同整体解释惯例。如果合同中没有其他特别规定，在出现含糊或矛盾时应该按这些惯例进行解释
              • 一般来说，专用条件优先于通用条件，具体规定优先于笼统规定，手写条文优先于印刷条文，单价优先于总价，价格的大写（文字）优先于小写（数字），技术规范优先于图纸
            • 公平诚信原则：在解释合同时应公平合理，兼顾双方当事人的利益。如果按上述整体解释原则进行解释后仍含混不清，则可按不利于合同起草方的原则进行解释。在这种情况下，可以理解为起草方故意使用了有歧义的词句，故应该承担相应的责任
          • 在合同解释时需要谨慎对待“备忘录”和“意向书”。如果备忘录与合同规定不一致，合同规定的效力要高于备忘录。从本质上讲，意向书是没有法律约束力的，其效力当然就远低于备忘录和合同
          • 采购，有集中采购与分散采购之分
            • 集中采购是指由执行组织统一对外采购各项目所需的材料、设备或服务
            • 分散采购是指由各项目分别对外采购各自需要的材料、设备或服务
            • 这两种方式可在一个项目上同时存在
          • 合同管理，也有集中合同管理与分散合同管理之分
            • 集中合同管理是指在项目执行组织中有一个专门的职能部门，负责所有项目的合同管理工作
            • 分散合同管理是指每个项目都有自己的合同管理人员，专门负责本项目的合同管理工作
            • 当然，在实际工作中，经常是部分集中、部分分散的混合式合同管理
          • 公司通过合同开展的业务越多，就越要采用集中合同管理
        • 【对比】集中合同管理与分散合同管理各有优缺点
        • 在《PMBOK®指南》中，把关闭合同（结束采购）的工作也归入了控制采购过程。为了正式关闭合同，就需要结束合同工作以及当事人之间的合同关系，进行采购审计，并将有关资料收集归档，更新组织过程资产
        • 无论何种原因导致合同终止，都要进行合同收尾。即便合同提前终止，也必须进行合同收尾，把合同正式关闭
        • 合同收尾要做的主要工作包括：
          • 产品核实。是否所有合同工作都已按要求完成？产品是否符合要求？
          • 可交付成果验收。按合同规定的验收程序与标准，对合同可交付成果进行最终验收
          • 财务结算。结算合同最终价款，支付最终款项，更新项目财务记录
          • 退还保证金或担保函（如保留金、履约担保）
          • 总结合同实施情况，进行采购审计，从独立、公正的第三方角度来总结采购工作的经验教训
          • 更新合同记录，收集资料，整理合同档案，更新组织过程资产
        • 各采购管理过程的主要工作
      • 12.5 各过程的工具与技术
        • 12.5.1 规划采购管理
          • 首先，通过市场调研来开展数据收集，了解市场情况；其次，根据市场调研所得到的资料，开展自制或外购分析（属于数据分析），确定哪些工作该外包出去。无论是做市场调研还是自制或外购分析，都需要召开会议
          • 可以采用多种多样的方法进行市场调研，了解市场供需情况，以便合理做出与采购有关的安排。会议既包括项目团队或执行组织内部的会议，也包括项目团队或执行组织与市场上的潜在买方或其他相关方的会议，它们有助于了解市场情况，编制采购管理计划
          • 自制或外购分析是规划采购管理过程中的一项重要工作。一个项目，也许可以全部自制、全部外购，或者部分自制、部分外购。自制或外购分析原本是管理会计中的一个重要概念，用来比较两者之间哪个成本更低。计算外购的成本，要包括外购的实际成本和外购工作的管理费用
          • 当然，自制或外购的理由，并不局限于成本方面的考虑。例如，自己有闲置的设备或人力，或者自己想掌控这部分工作，或者这部分工作涉及一些机密的信息或程序，就应该“自制”。除了降低成本，也可以为缩短研发周期、建立长期伙伴关系等而“外购”
          • 自制或外购分析在PMP®考试中也可能引申为购买或租赁分析。道理是一样的
          • 在PMP®考试中，除非题目明确告诉你，如果购买该设备，本项目使用后还可以再出售或供执行组织其他工作使用，否则就不用考虑再出售或供其他工作使用
          • 风险管理中的风险接受或转移分析，也属于自制或外购分析的延伸
          • 在规划采购管理过程中，需要使用“供方选择分析”来确定将用什么方法来选择卖方（评标）
            • 注：* 本表对独有来源的描述，与《PMBOK®指南》第474页的内容有所不同。《PMBOK®指南》中的“独有来源”（SoleSource）更像“单一来源”（Single Source）。前者是只有一家能提供所需的货物或服务，后者是虽然有多家能够提供所需的货物或服务，但是只认其中的某一家。要用单一来源的方式，就必须特别说明理由
        • 12.5.2 实施采购
          • 实施采购过程包括招标、投标、评标和授标4个环节。本过程的工具与技术自然也就是用于开展这4个环节的。专家判断是四个环节都要使用的
            • 第一是招标环节的广告
              • 买方发布招标采购广告，让潜在卖方知道有这么一回事。当然，发广告的方式可以多种多样
                • 竞争性招标，应该在公共媒体上发布广告
                • 邀请招标，应该在有限范围内发布广告
                • 直接采购，则只需要向特定厂家发出采购消息
            • 第二是投标环节的投标人会议
              • 潜在卖方购买招标文件之后，就根据招标文件编制投标文件。在编制投标文件的过程中，潜在卖方会对招标文件有各种疑问。招标方应该通过投标人会议，给他们提问的机会，并回答他们的问题。在投标人会议期间，招标方也应该带潜在卖方考察项目现场
              • 在投标人会议期间，买方必须确保公平地对待每个潜在卖方，不使任何一个受到特别优待或歧视，必须确保每个潜在卖方得到完全一样的信息
              • 在竞争性招标中，投标人会议（标前会议）必不可少
            • 第三是评标环节的建议书评价（属于数据分析）
              • 这是用于评标的方法。常用的评标方法包括：
                • 加权打分法。用具有不同权重的各评标标准，对各投标文件进行打分，然后加权汇总，得到各潜在卖方的排名顺序。将选择得分最高的潜在卖方中标
                • 筛选系统，也叫过滤系统。通过多轮过滤，逐步淘汰掉达不到既定标准的投标商，直到剩下一家。用于淘汰的标准，各轮逐渐提高。最后剩下的那家，就是中标者
                • 独立估算。把潜在卖方的报价与买方事先编制的独立成本估算（俗称“标底”）进行比较，选择与标底最接近的报价中标
            • 第四是授标环节的谈判（属于人际关系与团队技能）
              • 在确定中标者（正式授标）之前，需要与潜在卖方进行谈判。注意：谈判的目的不是“卡”对方，而是要与潜在卖方加深了解，得到公平、合理的价格，为以后可能的合同关系奠定良好基础
              • 好的谈判应该是与卖方进行团队建议的好机会，能够得到“双赢”的结果
              • 谈判是为了保护将来合同成立之后的双方关系
              • 还要特别注意的一点是：不要设法从对方口袋里去“拿”钱，而要从减轻风险入手去“省”钱。如果想要卖方降价，最好设法为他减轻一些风险
          • 列举一些常见的谈判策略：
            • 最后期限。设定一个达成协议的最后期限
            • 自己的权力有限，有决策权的人又不在场。声称自己无权对某些问题做出决定，需要向领导请示，而领导又不在场
            • 拖延。以各种方式拖延对其中某个问题的讨论，甚至拖延整个谈判
            • 撤退。故意表现出自己对某个事物没有什么兴趣，以退为攻
            • 出乎意料。突然抛出一个全新的、出乎意料的方案，以期打对方一个措手不及
            • 公平合理。以各种方式证明自己所提的方案是公平合理的
            • 既成事实（Fait Accompli）。坚持某个问题已有既定的解决方案，不需要再讨论
            • 好人坏人。参与谈判的成员中，一人当好人，一人当坏人。通常，坏人先说，好人随后来收拾局面
          • 谈判需要遵守以下四大原则：
            • 人与事分开的原则。应该尽量理性地谈判，不要带入个人感情
            • 关注利益而非立场的原则。因为利益决定立场，所以必须关注对方的利益
            • 创造共赢的解决方案。上文提及的从风险入手谈价格，就符合这个原则
            • 坚持与客观标准比较。客观标准可以是法律法规、行业标准或其他公认资料中的规定。用客观标准作为依据来说明自己的要求的合理性
        • 12.5.3 控制采购
          • 第一，要对卖方的工作情况进行检查。买方和卖方应该共同签署日常检查记录，对检查结果达成一致，以便作为卖方申请付款和买方支付款项的依据。如果检查结果不合格，买方可以拒付款项
          • 第二，要使用数据分析中的挣值分析来计算进度和成本绩效指标，并据此进行进度和成本绩效的趋势分析
          • 第三，要定期或不定期地开展审计，总结合同履行方面的经验教训，提出相应的变更请求
          • 第四，要使用数据分析中的绩效审查，确定卖方的工作绩效和工作能力是否令买方满意，以决定该卖方以后是否适合承接类似的工作
          • 第五，要通过索赔管理去预防、记录和处理卖方向买方的索赔
            • 索赔管理是合同管理中的一个难题。索赔是一方遭受了某种不该自己承担的实际损失（包括金钱或时间损失），而基于法律或合同规定向对方提出的补偿请求
            • 索赔的实质是要求损失补偿，不带任何惩罚性质。虽然合同任何一方都可以向对方索赔，但一般只讨论卖方（承包商）向买方（业主）的索赔
            • 索赔可以分成不同的类别，如工期延误索赔、赶工索赔、变更索赔、不利现场条件索赔、违约索赔。PMP®考试中可能考到工期延误索赔和买方违约索赔。
            • 工期延误又可分为：
              • 可原谅延误与不可原谅延误。前者是承包商没有过错的延误，允许承包商延长工期；后者是承包商有过错的延误，不允许延长工期
              • 可补偿延误与不可补偿延误。前者是承包商无过错但业主有过错的延误，不仅允许承包商延长工期，还对承包商因延误而遭受的经济损失给予补偿；后者是承包商和业主均无过错的延误，允许延长工期，但不补偿承包商的经济损失
            • 违约索赔是一方违约，另一方向违约方提出损失索赔。绝不能用“以牙还牙”的方式处理违约。一方违约后，另一方不能以另一种违约来对付。另外，除非是特别明显的恶意违约，一般只能索赔实际损失，而不能对违约方进行实质性惩罚
          • 虽然在本过程中没有直接列出专用于关闭采购合同的工具，但是审计、绩效审查和索赔管理都可用于关闭采购合同。审计是总结采购管理的经验教训，以便以后的采购管理做得更好。绩效审查是要审查卖方的总体工作能力，以便决定它以后是否还有资格来承接类似工作。索赔管理是要通过谈判或采用替代争议解决方法解决尚未解决的索赔
    • 第13章 项目相关方管理
      • 13.1 基本概念
        • 项目相关方是其利益会受项目活动或结果的正面或负面影响的任何个人、群体或组织，以及能对项目活动或结果施加正面或负面影响的任何个人、群体或组织。通俗地讲，与项目有直接或间接关系的任何个人、群体或组织，都是项目相关方
        • 应该把项目相关方的外延考虑得尽可能宽一些，因为遗漏重要相关方会给项目带来很大麻烦
        • 项目相关方管理的重要性不言而喻。一方面，项目要取得成功，离不开项目相关方的支持与参与。另一方面，做项目最终是要满足项目相关方的利益追求，让相关方满意。在《PMBOK®指南》中，特别强调了项目相关方应该在整个项目生命周期中参与项目工作
        • 项目经理应该以各种方式调动相关方合理参与项目工作。例如：
          • 认真评估和利用相关方的知识和技能，促进项目成功。不同的相关方拥有不同的知识和技能，只要是有利于项目的，都应该加以利用
          • 在制订沟通管理计划时，应该切实弄清楚项目相关方对项目信息的需求，并在整个项目生命周期中向他们分发各种必要的项目信息，如关于项目进展或项目变更的报告，为他们参与项目工作创造条件
          • 鼓励项目相关方参与项目制约因素与假设条件的鉴别工作，参与项目计划编制工作，作为项目大团队的组成部分参与项目大团队建设
          • 把某些风险分配给项目相关方，请他们担任风险责任人管理这些风险
        • 相关方参与，对取得项目成功至关重要。相关方参与，有利于他们了解项目并为项目做贡献，有利于提升他们对项目的主人翁感
        • 对于项目相关方管理，考生应该注意：
          • 需要识别出全部的项目相关方
          • 需要考虑全部的项目相关方的利益与影响
          • 需要充分发挥全部的项目相关方的作用来保证项目成功
          • 相关方管理做得不好，往往是造成项目失败的主要原因
          • 应该尽早积极面对负面相关方，如同面对正面相关方
          • 应该充分评价项目相关方的知识与技能，并加以充分利用
        • 不是只考虑一个或几个项目相关方，而是全部的项目相关方，至少理论上是这样要求的
      • 13.2 项目相关方管理的发展
        • 13.2.1 在《PMBOK®指南》中的发展
          • 发展趋势：
            • 第1版和第2版：基本不理相关方。只是简单地提及“项目相关方”这个词，并没有讨论“项目相关方管理”
            • 第3版：被动地解决与相关方之间的问题，专列了一个“管理相关方过程”
            • 第4版：主动地管理相关方，新增了一个“识别相关方过程”，要求在项目启动阶段就主动识别相关方。还把“管理相关方过程”改成了“管理相关方期望过程”，要求主动引导相关方对项目抱有合理的期望
            • 第5版：提出双向式相关方管理。把项目相关方管理单列为一个知识领域，强调鼓励相关方合理参与项目
            • 第6版：更加强调相关方参与的重要性。把第5版的“相关方管理计划”改成了“相关方参与计划”，强调主动引导相关方合理地参与项目
        • 13.2.2 《PMP®考试大纲》中的发展
          • 2015年版《PMP®考试大纲》新增了许多与项目相关方管理直接相关的内容
          • 2019年版《PMP®考试大纲》中直接提及项目相关方的内容，整理如下：
            • 分析相关方对项目的权力、利益和影响等，并据此对相关方进行归类
            • 建立与相关方的信任关系，用合适的方式去领导（启发、激励和影响）相关方
            • 赋能相关方，包括授予相关方合适的决策权限，以及通过培训、教练或辅导去提升相关方的能力
            • 评估所需的相关方参与程度，制定引导相关方以所需程度参与项目的策略，并加以执行
            • 让项目团队外部的相关方了解项目执行组织和项目团队的组织原则
            • 分析相关方的沟通需求，与他们保持合适的沟通，包括沟通渠道、频率和信息详细程度等，确保相关方持续了解项目信息
            • 与相关方合作，解决项目问题
            • 动态评估相关方从项目上获得价值的进展情况
      • 13.3 主要项目相关方
        • 一个项目通常有众多的项目相关方，他们在项目上有不同的利益，对项目有不同的影响，对项目成功起不同的作用
        • 13.3.1 项目发起人
          • 项目发起人是为项目提供资金和其他重要资源的人。项目发起人在提出项目的初步设想之后，会组织一班专家开展项目商业论证，然后对可行的项目落实所需资金。项目发起人亲自领导项目启动工作。在项目正式启动之后，发起人应该授权项目经理管理项目，并充当项目最重要的高层支持者
          • 项目发起人作用是提供资金
          • 关于项目发起人的角色，还需要注意以下几点：
            • 发起人应该对项目及其成果提出一些原则性要求
            • 发起人可以亲自起草项目章程或授权项目经理代为起草
            • 发起人可以亲自签发项目章程或授权项目执行组织高级管理层签发
            • 发起人应该与其他重要项目相关方（如客户）一起验收项目成果
            • 应该由项目发起人或其授权人员宣布项目正式关闭（结束）
        • 13.3.2 高级管理层
          • 高级管理层是项目执行组织中高于项目经理的全体管理者的集合。如果某个项目由某个公司发起并执行，那么该公司的管理者既是项目的发起人，也是项目的高级管理层
          • 高级管理层又包括如下主要成员：
            • 项目治理委员会。项目的高层决策机构
            • 项目组合经理。负责确保项目与组织战略的一致性
            • 项目集经理。负责管理项目集中的各个项目之间的横向联系
            • 项目管理办公室。项目执行组织中负责管理项目管理工作的常设职能部门
        • 13.3.3 客户
          • 客户是项目成果的使用者，既包括直接使用者，也包括间接使用者。一个项目可能有多种客户
          • 必须在起草和签发项目章程时，就明确谁是本项目的客户，了解客户对项目的重要利益追求。当然，对于项目经理来讲，发起人或高级管理层本身也是客户，至少也是客户之一
          • 众多项目相关方之间有利益冲突。发起人、高级管理层或项目经理应该尽力协调相关方之间的利益冲突。如果实在无法协调，通常应该按有利于客户的原则处理。如果有多个客户，又应该以最终端客户的利益至上
          • 同一个人或一群人，既可以是发起人（提供资金），也可以是高级管理层（对项目进行高层监管），还可以是客户（接受或使用项目成果）
        • 13.3.4 项目经理
          • 项目发起人或高级管理层应该尽早指定项目经理。一般应在项目启动阶段指定，以便项目经理参与项目章程的编写，甚至在获得授权后，主持项目章程的编写。最迟要在项目规划阶段初期指定，绝对不能到规划阶段中后期或者项目执行阶段再指定
          • 项目发起人或高级管理层应该在项目章程中赋予项目经理管理项目的权责。虽然我们也希望项目经理的权责对等，但在项目实际环境中，往往职责大于职权
          • 项目经理应该积极主动地工作，而不是消极被动地工作。要主动预防问题的出现，并积极解决已经出现的问题。项目经理作为项目管理专业人士，必须理解并遵守项目管理的职业要求（如职业道德）
          • 如果高级管理层要求降低成本或压缩工期，项目经理不能简单接受，而要进行专业分析，并写出分析报告提交给高级管理层，供其进一步考虑
          • 项目经理控制着项目，但不一定控制着资源。在矩阵式组织下，项目经理对一些人力资源与非人力资源没有控制权
          • 项目经理作为一个整合者，应该在更大程度上是一个通才而不是专才
          • 技术专家应该关注某种技术工作的细节，而项目经理应该关注各种技术工作之间的结合部。这是项目经理与技术专家的根本区别
        • 13.3.5 项目管理团队与项目团队
          • 在项目启动阶段，项目发起人或高级管理层指定项目经理。在项目规划阶段开始时，项目经理组建项目管理团队。在项目执行阶段开始时，项目经理组建在一线从事具体项目活动的项目团队（狭义的）
          • 狭义的项目团队从事具体项目活动，完成各个工作包。广义上的项目团队应是项目管理团队加狭义的项目团队再加其他的主要相关方。从广义上说，项目经理应该把主要相关方都看成项目团队的组成部分，而不能把项目团队局限于自己所在组织内部的小团队。中观层面的项目团队则是项目管理团队和狭义项目团队的组合
          • 在《PMBOK®指南》中，“项目管理团队”和“项目团队”这两个词经常替换使用，并没有严格区分开来。项目管理团队是项目团队中直接从事管理工作的人的集合
        • 13.3.6 职能经理和职能部门
          • 为了简便起见，此处的职能经理包括运营经理或直线经理，职能部门也包括运营部门
          • 职能部门通常是项目所需的专业技术和专业人才的蓄水池
          • 职能经理参与项目的程度取决于项目所采用的组织形式
          • 在采用矩阵式组织的项目中，职能经理对项目成败有重要影响。为了避免不必要的冲突，项目经理与职能经理必须充分合作。在矩阵式组织中，项目经理与职能经理的分工可以参照一个大的原则来进行，即项目经理负责“做什么、什么时候做、为什么要做、以多大代价来做”等问题，职能经理负责“具体技术工作由谁来做和怎么做”等问题
          • 针对某个具体项目，职能经理应该：
            • 参与项目启动工作，参与制定项目目标，参与项目计划的编制和审批工作
            • 与项目经理就项目所需的资源进行协商，分派具体人员到项目上
            • 就自己部门的专业领域，向项目提供技术支持
            • 告知项目经理可能影响本项目的其他项目或工作的情况
        • 13.3.7 卖方和合作伙伴
          • 通过合同为项目提供货物、服务或其他成果的人，就是卖方。对于需要开展采购工作的项目，卖方就是重要的项目相关方
          • 合作伙伴与项目执行组织之间通常也有协议（不一定是严格的合同），但不是卖方与买方的关系。合作伙伴关系可能是通过某种认证过程建立的
      • 13.4 各过程的输入与输出
        • 13.4.1 输入与输出的关系总览
          • 项目相关方管理的实现过程包括识别相关方、规划相关方参与、管理相关方参与和监督相关方参与
        • 13.4.2 识别相关方
          • 首次开展识别相关方过程时，只有商业文件、项目章程和协议这3个输入
            • 商业文件中的商业论证报告会提及一些重要相关方，效益管理计划也会提及一些重要相关方（如受益人）
            • 项目章程已经列出一些重要相关方
            • 无论是联合发起项目的合作协议，还是作为承发包合同的协议，与协议有关的各方都是项目相关方
          • 重复开展本过程时，还需要项目管理计划中的沟通管理计划、相关方参与计划作为输入，以及项目文件中的需求文件、问题日志和变更日志作为输入
            • 沟通管理计划所列的信息发送者和接收者都是项目的相关方
            • 相关方参与计划则规定了应该在何时如何重复开展相关方识别
            • 需求文件有助于识别与特定需求有关的相关方
            • 问题日志中所记录的问题可能引出新的相关方
            • 变更日志中的变更请求的提出和处理情况可能引出新的相关方
          • 识别出来的相关方及其信息，应写入相关方登记册。重复开展本过程，识别出新的相关方，就可能需要提出变更请求
        • 13.4.3 规划相关方参与
          • 项目章程中关于项目目的、目标和成功标准的规定，有助于规划所需的相关方参与程度。相关方参与程度必须有利于项目成功
          • 项目管理计划中的资源管理计划有助于规划该如何与项目团队成员打交道，沟通管理计划规定了与相关方沟通的方法，风险管理计划有助于确定相关方应该如何参与风险管理
          • 以下项目文件也是本过程的输入：
            • 相关方登记册。提供了相关方的信息
            • 假设日志。有助于识别与特定假设条件或制约因素有关的相关方。例如，某个假设条件需要由某个相关方去落实
            • 项目进度计划。需要把某些相关方列作进度活动的负责人、执行人或支持者
            • 风险登记册。需要把某些相关方列作各单个项目风险的责任人，也需要考虑将受风险影响的相关方
            • 变更日志。重复开展本过程时，需要考虑与变更有关的相关方，如变更请求的提出者、将受变更影响者，考虑该如何让他们参与变更管理
            • 问题日志。重复开展本过程时，需要根据问题日志考虑相关方应该如何参与识别、分析和解决问题
          • 协议有助于规划如何引导与采购有关的相关方参与项目
          • 本过程的输出是相关方参与计划，将成为项目管理计划的一部分
        • 13.4.4 管理相关方参与
          • 项目管理计划中的以下组成部分是本过程的输入：
            • 相关方参与计划。根据该计划实实在在地与相关方打交道
            • 沟通管理计划。沟通是与相关方打交道的一种重要手段
            • 风险管理计划。引导相关方合理参与风险管理
            • 变更管理计划。引导相关方合理参与变更管理
          • 以下项目文件是本过程的输入：
            • 相关方登记册。可以从中了解该与哪些相关方打交道
            • 变更日志。变更请求的提出和处理情况，都需要及时通知相关方。处理变更请求，也需要邀请相关方参与
            • 问题日志。应该与相关方协作，有效解决问题日志中的问题
            • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训
            • 本过程可能提出变更请求
        • 13.4.5 监督相关方参与
          • 作为一个监控过程，需要把相关方参与的实际情况与计划要求做比较。实际情况体现在工作绩效数据和作为项目文件的项目沟通记录中。计划要求体现在项目管理计划的资源管理计划、沟通管理计划和相关方参与计划中
          • 以下项目文件是本过程的输入：
            • 相关方登记册。有助于监督相关方的变化情况，如哪些相关方已经退出，哪些是新出现的
            • 问题日志。有助于评价相关方参与的程度是否有效地促进了问题的解决
            • 风险登记册。有助于监督与相关方参与程度有关的风险的发展趋势和应对情况。如果相关方参与程度不足，某些风险发生的可能性会显著提高，后果会显著加重
            • 重复开展本过程时，应该参考已记录在经验教训登记册中的经验教训
          • 相关方实际参与程度与计划要求的偏差，记录在工作绩效信息中。如果情况不理想，就提出变更请求
      • 13.5 各过程的主要工作和成果
        • 项目相关方管理旨在弄清楚有哪些相关方及其基本情况，策划将如何引导他们参与项目，实际与他们打交道，监督相关方参与情况并提出变更请求
        • 13.5.1 识别相关方
          • 本过程旨在全面识别项目相关方并对他们进行分析。需要特别注意以下几点：
            • 尽早识别相关方。之所以把本过程放在启动过程组，就是要强调尽早识别。越是在项目早期，相关方对项目的影响力就越大，就越可以用较低的代价去考虑相关方的要求
            • 在整个项目生命周期中，要定期重新识别相关方。可以删去过时的相关方，增加新出现的相关方
            • 全面识别相关方。相关方识别要尽可能全面，防止遗漏重要项目相关方
            • 需要众多人的参与。识别相关方不只是项目经理或项目管理团队的事情，也应该鼓励其他相关方参与。项目经理和项目管理团队可以与已识别出的相关方一起，识别出更多的相关方
          • 相关方识别应该尽早、尽量全面、定期重复开展，且需要众多人参与
          • 当然，实际工作中可能面临这种情况：无论怎么强调要全面识别相关方，也总会有一些相关方不能被及时识别出来。这些相关方就是潜在相关方
          • 不仅要了解相关方的基本情况，如名称、联系方式，而且要认真分析相关方对项目的要求与期望、可能对项目施加的影响、与哪个阶段的关系最密切；不仅要特别注意相关方对项目的不同甚至冲突的要求，还要根据相关标准，对相关方进行分类。这些内容都要写入相关方登记册。相关方登记册需要在整个项目生命周期中定期更新
        • 13.5.2 规划相关方参与
          • 本过程旨在基于相关方识别和分析的结果，确定为取得项目成功所需要的相关方参与项目的程度，以及为此而应该采取的与相关方打交道的措施。更通俗地讲，就是要确定将如何与各种相关方打交道，如何引导他们合理参与项目
          • 本过程编制的相关方参与计划，应该同时包括程序性计划和实体性计划的内容。其主要组成部分为：
            • 来自相关方登记册的内容
            • 相关方现有的参与项目的程度，以及所需的参与项目的程度
            • 为了获得所需的参与程度，应该采取的与相关方打交道的策略和措施
            • 相关方参与计划与沟通管理计划的关系
            • 应该如何更新相关方登记册和相关方参与计划
        • 13.5.3 管理相关方参与
          • 本过程旨在根据相关方参与计划，通过沟通及其他方法，实实在在地与相关方打交道，引导相关方合理参与项目，并解决实际出现的相关方之间的问题，以便满足相关方的需要和期望。通过这个过程，把相关方实际参与项目的程度提高到项目经理期望的程度
          • 在这个过程中，需要把项目团队中的问题、项目团队与其他相关方之间的问题以及其他相关方之间的问题记录下来，形成问题日志更新。在这个过程中，需要提出变更请求。变更请求可能包括对相关方参与计划的修改建议，以及对项目及其成果的修改建议（也许原来误解了相关方的需求，或者相关方的需求发生了变化）
        • 13.5.4 监督相关方参与
          • 作为一个监控过程，本过程与其他基层监控过程类似。在本过程中，把相关方实际参与项目的程度和计划所要求的参与程度进行比较，发现并分析偏差，形成工作绩效信息，并提出变更请求。变更请求可以是要求修改相关方参与计划，也可以是要求采取纠正措施或预防措施
      • 13.6 各过程的工具与技术
        • 13.6.1 识别相关方
          • 除了专家判断和会议（相关方识别会和相关方分析 会），可以按如下顺序使用各种工具与技术
          • 首先，进行数据收集。可以通过问卷和调查（如焦点小组讨论），请大家识别出各种相关方。也可以通过口头的头脑风暴或书面的头脑写作，请大家集思广益，识别出各种相关方
          • 其次，进行数据分析。先分析一些现有的文件（文件分析），从中识别出一些相关方。再开展相关方分析，分析他们的兴趣、利益、权力、知识和影响等
          • 再次，用数据表现技术（相关方映射或展现）来呈现分析的结果。可以用权力利益方格、权力影响方格、影响作用方格来呈现分析结果
          • 在方格中，可以把相关方分成不同的四个大类别，如权力大、利益大，权力大、利益小，权力小、利益大，权力小、利益小。其中的权力是指相关方有多大的职权对项目施加干预。影响是指相关方有多强的主观愿望对项目施加干预，而作用则是相关方施加干预后能在多大程度上促使项目计划或执行做出变更
          • 可以用相关方立方体来呈现分析的结果。例如，建立相关方的权力、影响和作用立方体，突出那些权力大、影响大和作用也大的相关方
          • 可以用凸显模型来呈现分析结果。其中的三个维度是相关方施加影响的力量（能力）、紧急性和合法性。在这个模型中，把相关方分成七种不同类型，包括只与一个维度有关的自主型、潜伏型和苛求型，与两个维度有关的支配型、危险型和依赖型，与三个维度都有关的确定型
          • 还可以用影响方向来呈现分析的结果，包括上级相关方、下级相关方、外部相关方和横向（同级）相关方
          • 最后，应该基于相关方分析的结果，对相关方或相关方类别进行优先级排序（一种数据表现技术），以便重点抓排序靠前的相关方的管理
        • 13.6.2 规划相关方参与
          • 除了专家判断和会议（相关方分析会），可以按如下顺序使用各种工具与技术
          • （1）使用数据收集技术中的标杆对照，收集先进的、可作为标杆的相关方参与方式和程度，以及用于引导相关方参与的方法
          • （2）使用数据分析技术中的假设条件和制约因素分析，来分析与相关方特定的参与方式或程度有关的假设条件和制约因素；使用其中的根本原因分析来分析导致相关方支持或抵制项目的根本原因
          • （3）使用数据表现技术进行进一步分析，并呈现分析结构。其中的思维导图有助于分析某个相关方的多种信息之间的联系，也有助于分析不同相关方之间的联系。相关方参与度评估矩阵有助于分析相关方实际参与项目的程度以及所需的参与程度，直观地呈现两者之间的差距。相关方参与度可从低到高分为以下5种：
            • 无知型。包括根本不知道项目存在的相关方，以及虽然知道项目存在，但是不知道项目可能对自己有影响的相关方
            • 抵制型。知道项目及其潜在影响，但是抵制项目
            • 中立型。知道项目及其潜在影响，既不支持也不抵制项目
            • 支持型。知道项目及其潜在影响，而且支持项目
            • 领导型。知道项目及其潜在影响，而且特别支持项目
          • 支持型相关方是仅仅自己支持项目。而领导型相关方则不仅自己支持项目，还鼓动（领导）别人一起来支持项目
          • （4）基于上述结果，使用决策技术对相关方重新进行优先级排序或分级
          • （5）基于分析和排序的结果，编制相关方参与计划，在其中规定将如何与相关方打交道，以便维护和提升相关方参与项目的程度
        • 13.6.3 管理相关方参与
          • 本过程就是实际与相关方打交道，获得他们对项目的支持和参与。除了专家判断，其他工具与技术包括：
            • 召开各种类型的会议，与相关方实实在在地打交道
            • 运用沟通技能，与相关方实实在在地打交道
            • 运用人际关系与团队技能，与相关方实实在在地打交道。包括使用其中的政治意识和文化意识（必须了解政治和文化氛围）、观察和交谈（这是与相关方打交道的手段）、谈判（通过谈判与相关方达成协议）和冲突管理（及时解决相关方之间的冲突）
            • 与相关方打交道时，必须遵守事先制定的基本规则（基本的行为规范）
          • 如果相关方实际参与项目的程度已经达到所要求的程度，就要设法维护他们的参与程度。如果没有达到所要求的程度，就要把他们的参与程度引导到所要求的程度。当然，也必须防止相关方实际参与项目的程度出现下降
          • 本过程可能提出“变更请求”
        • 13.6.4 监督相关方参与
          • 本过程的工具与技术比较多，可以做如下概括：
            • （1）使用沟通技能和人际关系与团队技能来了解相关方实际参与项目的程度。沟通技能中包括向相关方演示项目情况，以及收集相关方的反馈意见。人际关系与团队技能中包括政治意识、文化意识、积极倾听、领导力和人际交往
            • （2）使用数据分析技术中的相关方分析，来分析在特定的监控时点，相关方的实际参与情况，包括支持或抵制项目的程度
            • （3）使用数据表现技术中的相关方参与度评估矩阵，来评价和呈现相关方实际参与项目的程度的动态变化情况，以便据此判断用于引导相关方的策略和措施的有效性。动态变化情况和措施的有效性，都应该写入“工作绩效信息”
            • （4）使用数据分析技术中的根本原因分析，来分析相关方参与程度不理想的根本原因；使用其中的备选方案分析，来分析多种用于解决这种不理想状况的备选方案
            • （5）使用决策技术（包括多标准决策分析、投票）来选择最好的解决方案，并据此提出“变更请求”
    • 第14章 五大过程组的工作要点
      • 14.1 概述
        • 结合《PMBOK®指南》和《PMP®考试大纲》，来讨论在每个项目管理过程组应该开展的主要工作。所讨论的每项工作都是PMP®考试中的必考知识点。在讨论时，采用了从全局到细节的方法，以及图示和文字解释相结合的方法
      • 14.2 五大过程组之间的关系
        • 项目管理的五大过程组是启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组虽然有一定的先后顺序，但是又并非简单地以首尾相接方式严格按顺序开展。它们之间存在着用语言无法描述清楚的交叉和循环关系。任意两个过程组之间都可能严重交叉和反复循环
        • 项目管理五大过程组之间的基本关系
        • 在《PMBOK®指南》中，总共有49个项目管理过程，隶属于项目管理5大过程组。其中，启动过程组有2个过程，规划过程组有24个过程，执行过程组有10个过程，监控过程组有12个过程，收尾过程组有1个过程。每个过程都要用特定的工具与技术，把特定的输入转化为特定的输出
      • 14.3 启动过程组
        • 启动过程组的工作概览
        • 解释：
          • （1）项目发起人组织一个专家团队开展项目商业论证，编制出商业文件，其中包括商业论证报告和效益管理计划
          • （2）在开展商业论证的同时或之后，发起人可以寻求其他组织来共同为项目出资。发起人和合作组织之间签署（合作）协议
          • （3）发起人通过以上两个步骤落实好项目的可行性和资金（完成项目的前期准备工作）以后，就会物色一名候任的项目经理，项目就进入启动过程组，办理正式的立项手续
          • （4）启动项目时，需要考虑事业环境因素，需要利用组织过程资产
          • （5）启动过程组的最终成果是项目章程、假设日志和相关方登记册
        • 根据发起人的授权，候任项目经理通过制定项目章程过程，编制项目章程并报发起人签发，同时需要编制假设日志。一旦发起人批准了项目章程，项目就正式启动（立项），项目经理也就正式上任，开始领导项目工作了。紧接着，项目经理要组织开展识别相关方过程，编制出相关方登记册
        • 启动过程组的制定项目章程过程和识别相关方过程之间的基本关系
        • 启动过程组需要开展以下主要工作：
          • （1）基于事业环境因素、组织过程资产和项目的前期准备资料（包括商业论证、效益管理计划和协议），开展项目评估，来确认以前做出的关于项目可行性的商业论证结论仍然是合理可靠的
          • （2）在开展项目评估时，应该广泛征求相关方的意见，并与重要相关方一起分析项目效益，确认项目仍然符合组织战略，能够为组织实现拟定的变革，创造预期的商业价值
          • （3）明确为了实现变革和创造价值，项目必须在特定范围、进度、成本和质量要求下完成的关键可交付成果。这也有利于引导相关方（特别是客户）对项目抱有合理的期望
          • （4）分析整体项目风险，确认整体项目风险水平是可接受的
          • （5）分析项目合规性要求，制定项目合规目标
          • （6）识别项目的单个项目风险类别、主要制约因素和主要假设条件
          • （7）确定项目治理结构，组建项目治理委员会，并规定其权责
          • （8）初选适用的项目开发方法（预测型、敏捷型或混合型）
          • （9）提出项目执行的总体要求，如项目范围设计、里程碑进度计划、所需的财务资源估计
          • （10）对前述所有工作的成果进行整理、分析和提炼，编制出项目章程和假设日志。在这个过程中，应该保持与相关方的良好沟通，以便大家对项目章程和假设日志的内容达成一致意见
          • （11）获得发起人对项目章程的批准，以便项目正式立项，项目经理正式上任
          • （12）向相关方分发（可召开项目启动会）已批准的项目章程，确保他们理解项目的意义和目标，以及各自的角色和职责
          • （13）与已有的相关方一起，开展相关方识别和分析工作，编制出相关方登记册
      • 14.4 规划过程组
        • 规划过程组的工作概览
        • 解释：
          • （1）根据在前期准备工作中形成的商业文件和（合作）协议，编制项目计划
          • （2）根据项目章程和假设日志编制项目计划
            • 既要把项目章程中的项目目标逐渐具体化、可操作化，又要设计出用于实现项目目标的、具体的项目执行、监控和收尾方法
            • 编制计划时，既需要考虑假设日志中已有的假设条件和制约因素，又需要把相关假设条件和制约因素逐渐细化
          • （3）在编制项目计划的过程中，应该根据相关方登记册，邀请尽可能多的相关方参与，以便提高项目计划的质量，并使相关方对项目计划有强烈的主人翁感
          • （4）在编制计划时，需要考虑事业环境因素，需要利用组织过程资产
          • （5）项目计划由项目管理计划、项目文件（仅限各规划过程编制的各种文件）、项目资金需求，以及采购文档（仅限规划采购管理过程编制的与采购有关的计划）构成
        • 规划过程组共有24个项目管理过程。由于项目计划的编制不可能一蹴而就，需要反复循环，因此这24个过程之间的关系非常复杂。不仅如此，各种执行过程和监控过程还会导致项目计划更新，包括项目管理计划更新、项目文件更新和采购文档
        • 不考虑可能的循环和更新，这24个过程之间的基本关系
        • 解释：
          • （1）通过各规划××管理（或参与）过程，编制各种分项管理（或参与）计划
          • （2）通过制订项目管理计划过程，把全部分项管理（或参与）计划整合成项目管理计划
          • （3）根据项目管理计划，开展后续的全部规划过程，编制项目计划
          • （4）通过收集需求、定义范围和创建WBS过程，编制范围计划
          • （5）根据范围计划中的范围基准，通过规划质量管理过程，确定各种项目工作和可交付成果的质量测量指标
          • （6）根据范围计划中的范围基准，通过规划采购管理过程，确定哪些项目工作和可交付成果需要外包出去，并编制相应的采购计划（如招标文件）
          • （7）通过定义活动过程，把范围基准中的工作包分解成进度活动；通过排列活动顺序过程编制项目进度网络图；根据估算活动资源过程所得到的资源需求，通过估算活动持续过程估算活动持续时间；通过制订进度计划过程，把前述成果整合成项目进度计划
          • （8）根据资源需求和项目进度计划，通过估算成本过程估算活动成本；通过制定预算过程把各活动的成本汇总成项目预算（成本计划）
          • （9）编制出初步的范围、进度、成本、质量和采购计划之后，通过识别风险、实施定性风险分析、实施定量风险分析和规划风险应对过程，来考虑与初步计划有关的风险；然后，根据风险情况，回头调整初步计划。可能要经过多次调整，才能得到可行的项目计划
          • （10）高层级的项目计划是范围基准、进度基准和成本基准，需要被汇编进项目管理计划。低层级的项目计划则作为项目文件或采购文档而存在。项目资金需求，因为主要供项目发起人为项目按时按量提供资金，而非供项目团队使用，所以不归入项目文件，而是独立存在的
        • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，规划过程组需要开展以下主要工作：
          • （1）通过规划××管理（或参与）过程，编制需求管理计划、范围管理计划、进度管理计划、成本管理计划、质量管理计划、风险管理计划、资源管理计划、沟通管理计划、采购管理计划和相关方参与计划
          • （2）通过制订项目管理计划过程，编制变更管理计划和配置管理计划，确定项目开发方法和项目生命周期类型
          • （3）根据需求管理计划和范围管理计划，编制范围目标计划，包括项目范围说明书、工作分解结构和WBS词典
          • （4）根据资源管理计划、范围目标计划以及其他相关信息，估算活动和项目所需的资源，得到资源需求
          • （5）根据进度管理计划、范围目标计划和资源需求，编制进度目标计划，包括里程碑进度计划、汇总进度计划和详细进度计划，以及相应的支持材料
          • （6）根据成本管理计划、范围目标计划、进度目标计划和资源需求，编制成本目标计划，包括成本估算、项目预算和项目资金需求
          • （7）根据质量管理计划、范围目标计划、进度目标计划和成本目标计划，编制质量目标计划，即质量测量指标
          • （8）根据范围管理计划、质量管理计划、资源管理计划，以及范围、进度、成本和质量目标计划，编制采购计划，包括采购策略、采购工作说明书、招标文件和供方选择标准等
          • （9）根据风险管理计划、其他各种管理计划和其他相关信息，对已编制出的范围、进度、成本和质量目标计划，以及采购计划，进行风险识别和分析，并制定风险应对措施
          • （10）根据风险识别、分析和应对措施制定的结果，回头调整范围、进度、成本和质量目标计划以及采购计划
          • （11）根据需要，反复开展上述第3步至第10步，直到得到现实可行、令人满意的范围、进度、成本和质量目标计划以及采购计划和风险计划（风险登记册）
          • （12）把最终的项目范围说明书、工作分解结构和WBS词典汇编在一起报领导和主要相关方批准，得到范围基准。把最终的里程碑进度计划和汇总进度计划，报领导和其他主要相关方批准，得到进度基准。把最终的项目预算报领导和其他主要相关方批准，得到成本基准
          • （13）把所有的分项管理计划和分项基准汇编在一起，形成项目管理计划，并报领导和其他主要相关方批准。把其他不属于项目管理计划的组成部分的内容（项目资金需求除外），归入“项目文件”或“采购文档”
          • （14）把项目资金需求报给项目发起人，以便他据此准备和提供资金
          • （15）召集项目开工会议，向相关方介绍项目计划和项目目标，获得相关方对项目的支持和参与，宣布项目正式进入执行阶段
        • 在编制计划的过程中，要留意并考虑项目执行组织内外部的商业环境的动态变化，考虑如何确保项目合规、如何确保项目能够实现组织变革和创造商业价值
      • 14.5 执行过程组
        • 执行过程组的工作概览
        • 解释：
          • （1）根据项目管理计划（高层级项目计划）、项目文件（低层级项目计划）和采购文档（采购计划）开展项目执行。其中，采购文档是签署协议（合同）的主要依据
          • （2）一边执行，一边收集工作绩效数据
          • （3）通过切实的执行，做出所要求的可交付成果
          • （4）根据来自监控过程的质量控制测量结果及其他相关信息，编制质量报告
          • （5）在执行中，及时总结和记录经验教训，形成经验教训登记册
          • （6）在执行中，可能发现项目计划需要修改，并提出变更请求
          • （7）经监控过程更新的风险登记册、风险报告和经验教训登记册，以及监控过程编制的工作绩效报告，需要反馈给执行过程组
          • （8）监控过程得到的“批准的变更请求”需要交给执行过程组执行
        • 执行过程组共有10个项目管理过程，这些过程的开展并没有严格的先后顺序，通常都是交叉在一起开展的，无法截然分开。它们之间的基本关系。如图
        • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，执行过程组需要开展以下主要工作：
          • （1）按照资源管理计划，从项目执行组织内部获取项目所需的团队资源和实物资源
          • （2）对于团队资源，组建、建设和管理团队。对于实物资源，在正确的时间分配到正确的工作上
          • （3）按照采购计划，开展采购工作，从项目执行组织外部获取项目所需的资源、产品或服务
          • （4）领导团队按计划执行项目工作，随时收集能够真实反映执行情况的工作绩效数据，并完成符合范围、进度、成本和质量要求的可交付成果
          • （5）开展管理质量过程，有效执行质量管理体系
          • （6）执行经批准的变更请求，包括纠正措施、缺陷补救措施和预防措施
          • （7）执行经批准的风险应对策略和措施，来降低威胁对项目的影响，提升机会对项目的影响
          • （8）执行沟通管理计划，管理项目信息的流动，确保相关方了解项目情况
          • （9）执行相关方参与计划，维护与相关方的关系，引导相关方对项目抱有合理期望并积极参与和支持项目
          • （10）开展管理项目知识过程，利用现有知识，形成新知识，进行知识分享和知识转移，以便促进本项目顺利实施，以及项目执行组织发展
          • （11）对项目团队成员和项目相关方进行培训、教练和辅导，以便他们能够更好地参与项目
      • 14.6 监控过程组
        • 监控过程组的工作概览
        • 解释：
          • （1）监控就是把执行情况与计划要求相比较，发现偏差。所以，监控过程组的输入，既有来自规划过程组的成果，也有来自执行过程组的成果。规划过程组的成果包括项目管理计划、项目文件和采购文档；执行过程组的成果包括工作绩效数据、可交付成果、质量报告、协议、经验教训登记册和变更请求
          • （2）把偏差记录下来，形成工作绩效信息、质量控制测量结果和工作绩效报告。因为工作绩效信息仅供监控过程组内部使用，所以没有出现在本图中
          • （3）如果偏差超出了可接受的区间（控制临界值），就需要提出变更请求并进行审批。监控过程组提出的变更请求，需要在本过程组审批，故没有作为输出出现在本图中
          • （4）及时审批变更请求，得到批准的变更请求
          • （5）及时检查已完成的可交付成果是否符合质量要求和验收标准。如果符合，就得到验收的可交付成果；如果不符合，就提出变更请求
          • （6）根据在监控中发现的问题，及时更新风险登记册、风险报告和经验教训登记册
        • 监控过程组共有12个项目管理过程。项目整合管理知识领域的2个监控过程都是整个项目层面的全局监控过程，其中的实施整体变更控制过程专用于审批变更请求。后九大知识领域的全部10个监控过程都是基层的局部监控过程
        • 需要注意的是，监督风险过程既包括基层的局部监控（用“工作绩效数据”作为输入，监督单个项目风险），也包括整个项目层面的全局监控（用“工作绩效报告”作为输入，监督整体项目风险）
        • 监控过程组的各过程之间的基本关系
        • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，监控过程组需要开展以下主要工作：
          • （1）把执行情况与计划要求相比较，考核项目绩效（包括范围、进度、成本和质量绩效），识别和量化绩效偏差
          • （2）分析偏差的程度和原因，并预测未来绩效
          • （3）基于分析和预测的结果（如果超出了控制临界值），提出变更请求，包括纠正措施建议、缺陷补救措施建议、计划修改建议和预防措施建议
          • （4）根据变更管理计划的规定，对变更请求进行综合评审，做出批准、否决或悬置的决定
          • （5）除了为实现项目的既定目标而管理项目变更，还要从确保项目继续符合商业需求的高度来管理项目变更，提出修改项目目标的变更请求，并报变更控制委员会或发起人审批
          • （6）及时审阅和处理随同项目执行而记录在问题日志中的各种问题，最小化这些问题对项目的不利影响
          • （7）及时检查已完成的可交付成果的质量，并及时验收质量合格的可交付成果，确保项目可交付成果能够满足项目要求，实现组织变革和创造商业价值
          • （8）监控团队成员和相关方对项目的参与情况，确保有利于项目成功
          • （9）监控项目采购活动，确保采购工作有利于项目目标的实现
          • （10）既要监控单个项目风险的情况，又要监控整体项目风险的情况，还要监控风险管理工作的有效性，以便降低对实现项目目标的威胁，提高对实现项目目标的机会
          • （11）不断总结经验教训，以便持续改进
      • 14.7 收尾过程组
        • 收尾过程组的工作概览
        • 解释：
          • （1）根据项目章程和项目管理计划，把已经通过实质性验收的可交付成果移交给项目发起人或他所指定的其他人
          • （2）根据采购文档和协议（合同），确认项目上的所有合同都已经妥善关闭
          • （3）根据图中的所有输入，总结经验教训，编写最终项目报告，更新组织过程资产
          • （4）图中的“协议”，既可以是买卖方的合同，也可以是项目发起人之间关于联合出资的合作协议
        • 《PMBOK®指南》中只有一个收尾过程，即结束项目或阶段。之所以仍然称“过程组”，是因为在实际项目工作中，项目经理可以添加所需的其他过程
        • 《PMBOK®指南》对收尾过程组写得很简单。其总体思想是：收尾过程组不是用来解决问题的，而只是用来关闭项目或阶段并更新组织过程资产的。项目中的所有问题都必须在监控过程组发现并提出解决建议，然后通过规划过程组和执行过程组加以解决。所有问题都不能带到收尾过程组
        • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，收尾过程组需要开展以下主要工作：
          • （1）确认所有的项目合同都已经妥善关闭，没有未解决问题
          • （2）获得主要相关方对项目可交付成果的最终验收，确保项目目标已经实现。注意：这里的验收只是形式上的验收，而不是实质性的技术验收。实质性的技术验收早就在“确认范围过程”中完成了
          • （3）把项目可交付成果移交给指定的相关方，如发起人或客户。这件工作经常可以与最终验收同时开展
          • （4）编制和分发最终的项目绩效报告。这份报告既有利于相关方了解项目的最终绩效，又可以成为开展项目后评价的重要依据
          • （5）收集、整理并归档项目资料，更新组织过程资产。这是为了保留项目记录，遵守相关法律法规，供后续审计（如果需要开展）使用，以及供以后项目借鉴
          • （6）收集各主要相关方对项目的反馈意见，调查他们的满意度
          • （7）评估项目合规性、实现组织变革和创造商业价值的情况
          • （8）全面开展项目后评价，总结经验教训，更新组织过程资产
          • （9）开展知识分享和知识转移，为在后续的项目成果运营中实现商业价值提供支持
          • （10）开展财务、法律和行政收尾，宣布项目正式关闭，把对项目可交付成果的照管和使用责任转移给指定的相关方，如发起人或客户
    • 第15章 敏捷型项目管理方法
      • 15.1 概述
        • 所谓“敏捷”，就是主动且快速地应对甚至引领变化。敏捷型（也称适应型）项目管理方法是指采用迭代和增量的方式开发项目产品，适用于需求不明确或很容易变化且产品可以一部分一部分交付的项目（不是只能一次性完整地交付）。这种项目适合采用敏捷型开发方法（也称适应型开发方法）
        • 《PMP®考试大纲》指出，PMP®考试中，大约一半题目考预测型项目管理方法，另一半考敏捷型或混合型项目管理方法。因为PMI另外有一个专门的敏捷项目管理师资格认证，所以PMP®考试中的敏捷型方法应该不会太深太细，而主要涉及基本概念、基本方法和基本理念
        • PMP®考试兼考预测型、敏捷型和混合型项目管理方法
      • 15.2 项目开发方法的种类
        • 以预测型方法为一端，敏捷型方法为另一端，构成了项目开发方法的连续区间。中间则是迭代型方法、增量型方法和混合型方法
        • 预测型方法，也称计划驱动型方法，是指先编制出完善的项目计划，再严格照计划执行（基本无须变更）去实现目标。预测型方法相当于“想好了再做”，旨在严格按计划执行，打中静态的目标
        • 敏捷型方法，也称变更驱动型方法，是指先编制出简略的方向性计划，再按较短时间段逐一编制和执行阶段计划（便于及时变更）去实现目标。它是迭代型方法和增量型方法的综合。敏捷型方法相当于“一边做一边变”，旨在通过不断调整，打中动态的目标
        • “敏捷型方法”这个词，也可兼指迭代型方法或增量型方法
          • 迭代型方法是指通过多次短期迭代（循环）来不断优化同一个或同一系列产品功能
          • 增量型方法是指通过多次短期迭代来逐渐增加新的产品功能。在形成最终产品之前，每次迭代所得到的初级产品都叫“原型”
        • 混合型方法则是预测型方法和敏捷型方法的混合，例如，在项目的某个阶段或某个部分用预测型方法，而在另一阶段或另一部分用敏捷型方法；对整个项目用预测型方法，而对其中的产品开发部分用敏捷型方法
        • 所用的项目开发方法决定了项目开发生命周期的类型，也就决定了项目生命周期的类型。开发生命周期只针对产品开发，而项目生命周期的覆盖面更宽，覆盖全部的项目工作。采用预测型开发方法的项目，其开发生命周期和项目生命周期也就都是预测型的。其他方法依此类推
      • 15.3 项目开发方法的选择
        • 选择项目开发方法，要考虑的主要因素包括：
          • 项目相关方（特别是发起人和客户）对价值实现的紧迫性
            • 越要快速实现价值，就越要采用迭代型、增量型或敏捷型方法。采用预测型方法，是等到项目全部完成时才一次性实现价值。采用其他方法，都是分阶段或分模块来分批实现价值
          • 项目需求的明确程度
            • 项目需求越不明确，越易变，就越要采用迭代型、增量型或敏捷型方法
          • 项目的复杂程度，包括技术的不确定性和项目的可分性
            • 技术越不确定，可分性（可以分阶段或分模块开发）越高，越需要创新，就越要采用迭代型、增量型或敏捷型方法。敏捷型方法的最根本的基础就是项目产品开发的可分性。因为IT软件开发项目具有很高的可分性，所以敏捷型方法发源于这类项目
        • 仅从项目需求和技术这两个方面来看：
          • 需求明确且技术确定，就用预测型方法。例如，普通的房屋建设项目
          • 需求明确但技术不确定，就用迭代型方法。例如，研发治疗某种特定疾病的药物
          • 需求模糊但技术确定，就用增量型方法。例如，公司网站建设项目
          • 需求模糊且技术不确定，就用敏捷型方法。例如，研发可同时治疗多种疾病的药物
        • 敏捷型方法所包含的快速应对甚至引领变化的思想、观念和技术，具有广泛的适用性，从而使它不同程度地适用于几乎所有行业的所有项目。即便传统的建设工程项目，也可以在局部应用敏捷型方法，更可以在整个项目上采用一些敏捷观念。可以说，混合型方法的应用将越来越普遍
        • 采用敏捷型方法，对项目所在组织、项目客户和项目团队也有相应的要求
        • 选择项目开发方法，需要考虑项目本身、所在组织和项目团队的情况
      • 15.4 不同开发方法下的生命周期
        • 预测型生命周期的每个阶段的工作不同，阶段成果不供客户使用。项目阶段通常首尾相接，有时也可部分并行
        • 迭代型生命周期的每个阶段（迭代期）的工作相同，通过各阶段把同样的功能做得越来越精致，阶段成果（产品原型）通常不供客户使用（也可应客户要求，把原型交付其使用）
        • 增量型生命周期的每个阶段（迭代期）的工作不同，通过各阶段逐渐增加产品功能，阶段成果（产品原型）可供客户使用
        • 敏捷型生命周期，是迭代型和增量型的综合，通过各阶段（迭代期）在优化同样功能的同时新增其他功能，阶段成果（产品原型）可供客户使用。图
        • 是迭代型、增量型和敏捷型生命周期示例
        • 迭代型生命周期中的原型通常不供客户使用，仅供项目团队内部评审；而增量型生命周期中的原型通常要交付客户使用
      • 15.5 敏捷型方法下的人员管理
        • 15.5.1 项目经理
          • “引导者（Facilitator）”“教练（coach）”或“敏捷大师（Scrum Master）”。项目经理应该：
            • 在更大程度上是一个领导者，而不是一个管理者。对于团队成员，他应该主要进行启发与激励，而不是约束与控制
            • 关注创建和维护合作式团队氛围，以及提升整个团队的工作能力，同时把具体的项目工作授权给自组织的项目团队去负责
            • 主要采用仆人式领导风格，通过服务团队成员来启发和激励他们，帮助他们进步和成长
            • 在项目执行之前，对项目团队和客户进行敏捷方法培训，让他们了解和掌握敏捷方法和观念
            • 与团队成员一起识别和分析团队障碍物（impediment）或阻碍物（blocker），进行优先级排序，采取措施加以缓解或消除，并评价和确认缓解或消除的效果。障碍物会减慢团队的工作进程，阻碍物则会使项目工作完全停滞不前。这两个词也经常等同使用
        • 15.5.2 项目团队
          • 在敏捷型方法下，项目团队需要这三种基本角色：
            • 团队引导者（Team Facilitator，相当于项目经理）
            • 产品负责人（Product Owner，充当客户代表）
            • 跨职能团队成员（Cross-functional Team Members）
          • 在敏捷方法下，项目团队应该具有自我组织、自我管理和自我决策的能力，团队成员合作解决问题。采用敏捷方法，对团队成员的自觉性和工作能力都有很高的要求
            • 项目团队应该是小规模全功能的，即人数少（5～9人最为合适），能做所有事情。这就要求每一位成员都是多面手，即通用的专才，而不是只懂某一个领域的主题专家
            • 在每个项目阶段（迭代期）都需要全部工种人员，如分析人员、设计人员、建造人员和测试人员，而不是不同阶段需要不同工种人员
            • 团队成员在充分透明和合作的团队氛围中快速创造、利用和解决冲突，快速达成共识。可以说，无冲突就无敏捷、无创新
          • 创造和利用冲突，是敏捷型方法的一大特点
          • 团队成员具有充分的包容性，采用协作式工作方式。每个成员都能充分包容不同专业、不同背景的成员，善于与他们协作。要防止歧视与自己不同的成员，防止各专业或小组各自为政，防止形成“组织独奏（Organizational Solo）”
          • 团队成员开展及时且充分的沟通。敏捷团队会借助各种技术来辅助沟通，例如：
            • 迭代规划会议（Sprint Planning）
              • 也可称冲刺规划会议，因为一次冲刺也就是一次迭代。这是在每个迭代期开始之初的规划会议，会形成本迭代期的迭代任务单（SprintBacklog）
            • 每日站立会议（Daily Standups）
              • 在每天早上上班时召开，时间10～15分钟，交流昨天做了什么、今天要做什么以及有什么困难
            • 看板（Kanban）
              • 看板源自丰田生产方式（精益生产方式），是指在实体板或电子板上记录有待开始、正在进行和已经完成的工作等信息
            • 迭代评审会议（Sprint Review）
              • 在当前迭代期结束时向产品负责人（客户）展示成果，并收集反馈意见
            • 迭代回顾会议（Sprint Retrospective）
              • 项目团队在迭代期结束或其他必要时间对开发过程进行总结回顾，以便后续改进
            • 产品未完项（Product Backlog）
              • 按优先级罗列有待完成的产品功能（用户故事）
            • 迭代任务单（Sprint Backlog）
              • 对产品未完项中的用户故事再分解，列出为实现某个用户故事而需要开展的具体任务及其时间要求
            • 信息发射源（Information Radiator）
              • 在任何人都可以看见的公共地方用简洁易懂的方式显示项目信息，如用于显示项目进展情况的迭代燃尽图或燃烧图
          • 在敏捷型方法下，项目团队尽量面对面集中办公，而不是以虚拟团队或分散式团队（成员在不同地点）远程办公，因为远程办公远不如面对面那样有创造性。如果不得不采用虚拟团队或分散式团队，则对团队建设会有更高的要求
        • 15.5.3 项目相关方
          • 在敏捷型方法下，项目相关方（特别是客户）应该：
            • 在整个项目期间都频繁且深入地参与项目，包括及时提出需求、参与讨论、使用（评审）原型和提供反馈等
            • 派代表参加项目团队，作为团队的一员参与项目工作。该成员通常是产品负责人
            • 平等地对待项目团队及其成员。客户不能认为“项目是我出的钱，所以项目团队应该听我的”，否则，就会严重妨碍团队的创造力，使敏捷型方法完全失败
            • 接受和配合项目团队对自己的相关培训、教练和辅导，以便更加了解敏捷型方法和项目情况，更好地参与项目工作
          • 在敏捷型方法下，项目团队成员是自觉性高且能力很强的主人，项目经理是为成员提供服务的忠实仆人，客户则是团队成员和项目经理的有力支持者和配合者
      • 15.6 敏捷型方法下的五大过程组
        • 无论采用什么项目开发方法，项目管理五大过程组都是适用的。在产品开发采用敏捷型方法的情况下，对整个项目的管理仍然要按项目管理五大过程组来启动、规划、执行、监控和收尾。没有任何一个项目可以不用项目管理五大过程组加以管理
        • 在敏捷型方法下，项目管理五大过程组的应用要比预测型方法下更加灵活，例如：
          • 项目启动过程组和规划过程组都应更快速地迭代开展，而不是用较长时间一次就做到足够深入和详细的程度
          • 五大过程组的交叉和循环更加明显，界线更加模糊，特别是规划、执行和监控过程组之间
          • 每个迭代期结束时都要通过收尾过程组来开展原型评审和回顾总结，为下一个迭代期做好准备
        • 严格地讲，任何应变领变都离不开一定的规矩。所以，任何项目在整个项目的层面上，都必须用预测型方法按五大过程组加以管理，没有任何项目能够百分之百地用敏捷型方法加以管理
      • 15.7 敏捷型方法下的项目目标管理
        • 因为项目目标是用范围、进度、成本和质量来表示的，而风险则是万一发生会对其中的至少一个方面产生影响的不确定性事件，所以下面将讨论敏捷型方法下的项目范围管理、进度管理、成本管理、质量管理和风险管理。因为目标往往并非一成不变，所以还会讨论敏捷型方法下的项目变更管理
        • 15.7.1 项目范围管理
          • 在预测型方法下，先确定项目范围目标，再确定项目进度、成本和质量；而在敏捷型方法下，则先确定项目进度目标（例如，新产品的上市日期），再确定范围、成本和质量。前者根据要做的事情来确定需要多长时间，后者根据固定的时间来确定能做多少事情
          • 在敏捷型方法下，项目需求和范围并非一开始就全部明确，而是随项目进展，在每个迭代期逐渐明确。通常，项目需求和范围在一个迭代期内保持不变，但在两个迭代期之间有所变化。为了快速实现价值，在每个迭代期结束时，都要交付出供评审且可使用的产品原型。在设计项目范围时，应该先找出最初的产品原型，即最小可用产品（Minimum Viable Product），然后考虑在后续的迭代开发中不断增加产品功能
          • 在敏捷型方法下，用“用户故事（User Story）”表示产品功能，一个用户故事代表一个功能。用户故事通常由3部分组成：用户，想要什么，为何想要。一系列待完成的用户故事则构成产品未完项。产品未完项中的用户故事有优先级排序，并且在每个迭代期开始时都要重新进行排序。必须最先开发出最重要（最有价值）的产品功能，再开发出第二重要的功能，以此类推。这样一来，即便第一个迭代期结束时项目就被迫终止，项目也在一定程度上是成功的，因为已经开发出最重要的功能
          • 在敏捷型方法下，工作分解结构（WBS）的第二层通常为开发迭代期或产品版本号。在最终产品交付之前，每一个产品版本都是精致或完善程度不同的产品原型
          • 在敏捷型方法下，在每个迭代期中，由项目团队自行开展《PMBOK®指南》中的控制范围过程；在每个迭代期结束时，项目团队与客户一起开展《PMBOK®指南》中的确认范围过程，对成果按照事先确定的“完成定义（Definition ofDone）”进行实质性评审和验收。“完成定义”用于规定成果必须满足哪些条件才能供客户使用
        • 15.7.2 项目进度管理
          • 如前所述，在敏捷型方法下，先确定进度目标。固定的项目工期，又要被划分为时间很短且通常长度相同的多个迭代期（短至几天，长至一个月）。每个迭代期都是一个固定的、绝不能突破的“时间盒（Time Box）”。之所以要规定时间盒，是为了促使人们集中精力于最重要的少数工作，按规定时间开发出既定的功能，即通过小批量工作快速交付原型
          • 在敏捷型方法下，用于估算所需努力程度（人力投入量）的相对最小单位是“故事点（Story Point）”。在同一个项目中，每个故事点所需的人力投入量（工时数）是相等的。在不同的项目上，则不一定相等。应该为每个用户故事估算所需的故事点，以此作为进度管理的依据
          • 在敏捷型方法下，项目进度计划通常包括版本进度计划、发布进度计划和迭代进度计划，分别对应预测型方法下的里程碑进度计划、汇总进度计划和详细进度计划。在版本进度计划中，规定每个版本（原型）的发布时间。在发布进度计划中，规定每个版本的发布需要完成的迭代次数和时间。在迭代进度计划中，则规定在一个迭代期内所需实现的用户故事及其时间要求。迭代进度计划在每个迭代期开始时编制
          • 敏捷型方法下的项目进度管理，应该始终贯彻“持续集成”和“持续交付”的理念。持续集成是指要经常对团队成员的工作成果进行整合（集成）和确认，持续交付是指以小步快跑的增量方式频繁地向客户交付可用的产品功能
        • 15.7.3 项目成本管理
          • 在敏捷型方法下，因为项目需求和范围并非一开始就明确，所以无法一开始就制定较准确的项目预算。起初，只能采用轻量级估算方法来制定粗略的项目预算（留出较充分的余地），以后再随需求和范围的逐渐明确来编制详细的迭代期预算
          • 迭代期预算的编制通常采用增量预算的方法而非零基预算的方法，即以前一个迭代期的成本为基础，经过适当调整，编制出下一个迭代期的预算。零基预算则完全不考虑过去的成本情况而编制全新的预算
          • 敏捷型方法其实是精益思想的一种应用。精益思想中的核心观念，如关注价值、小批量生产和消除浪费，也都体现在敏捷型方法中。因此，在敏捷型方法中，对资源供应就特别强调采用“准时制”，即需要时立即送来，以消除资源的库存成本和资源的过量储备
        • 15.7.4 项目质量管理
          • 无论用预测型还是敏捷型方法，质量都必须合格。敏捷型方法下的项目质量管理有如下几个特点：
            • 为了保证质量，可以在早期进行小批量试开发，以发现和解决质量问题，为后续大批量开发做好准备
            • 在开发过程中，由团队成员随同开发执行，自行进行更频繁的质量检查
            • 在每个迭代期结束时，都要通过迭代评审会议向客户展示成果，由客户评审质量是否符合要求
            • 在每个迭代期结束后，都要通过回顾会议来总结经验教训，引导下一个迭代期的质量改进。因为迭代期的时间较短，迭代期的数量较多，所以在整个项目期间较易开展持续改进
          • 敏捷型方法下的三重制约是确定的进度、估算的范围、合格的质量和估算的成本，不同于预测型方法下的确定的范围、合格的质量、估算的进度和估算的成本
        • 15.7.5 项目风险管理
          • 敏捷项目的需求、范围和技术的不确定性更大，相应的风险（包括机会和威胁）也就更大。应该在每个迭代期内识别、分析和管理风险，确保开发出所需的原型。原型开发出来之后，要立即交付给客户进行使用和评审，客户要尽快提出相应的反馈意见，作为开展下一次迭代的依据之一
          • 应该通过迭代来探索正确的技术，降低项目的技术风险（威胁）。例如，要研发某种特定疾病的治疗药物，因为用于实现治疗功能的技术手段很难确定，所以只能通过迭代去探索。应该通过增量来引导客户的需求，降低项目的需求和范围风险（威胁）
          • 敏捷型方法中的以下做法都有利于做好风险管理：
            • 不断对需求重新排序
            • 快速和频繁交付原型供评审
            • 反馈路径快速和短周期
            • 随迭代的进行不断持续改进
        • 15.7.6 项目变更管理
          • 在敏捷型方法下，因为一次只针对当前迭代期编制计划，以及文档尽可能量少而实用，所以针对既定计划进行的变更数量较少。不过，基于对前一个迭代期的经验教训总结，以及对所开发的原型的评审而提出的工作过程变更和需求变更数量较多。从这两类变更来讲，敏捷型方法要求人们拥抱变更，把变更看成提升项目价值的机会。正如《敏捷宣言》中所说的“响应变化高于遵循计划”，以及敏捷原则中所说的“欢迎对需求进行变更，即便是在项目开发后期”
          • 工作过程或需求变更尽可能在两个迭代期之间进行，而不是在一个迭代期内进行。例如，在第一个迭代期结束后，客户提出了四项需求（功能）变更申请。经过评审，其中的两项被批准了。接着，就要把这两项变更与原有产品未完项中的全部用户故事放在一起，重新进行优先级排序，得到变更后的产品未完项，作为下一个迭代期的工作依据
          • 敏捷型方法要求基于价值来开展变更管理。一项变更能否被批准，取决于它能否为客户创造出应有的价值
      • 15.8 敏捷型方法下的项目采购管理
        • 在敏捷型方法下开展项目采购管理，应该遵守《敏捷宣言》所述的“客户合作优先于合同谈判”，即合同谈判固然重要，与客户的合作却更加重要。这就要求，买方与卖方之间有更好的合作，有更加合理的风险分担
        • 因为敏捷项目具有需求不明、需求易变和技术易变的特点，所以无法一开始就编制出详细准确的采购工作说明书，而只能编制出轻量级（简略）的采购工作说明书。鉴于此，在敏捷型方法下，往往：
          • 采用多层次合同。多层次合同由主体协议和扩展协议组成。把确定的内容放入主体协议，把不确定的、易变的内容放入扩展协议。起初，双方可以只签主体协议。随后，再签也许不止一份扩展协议
          • 实行固定价格增量采购。按每个用户故事来确定固定价格，每增加一个用户故事就相应增加合同价格
          • 买卖双方联合组建团队。按团队工作时间付费，而不是按工作内容付费
          • 允许取消后续工作。例如，某病原计划治疗三个疗程，却两个疗程就治好了，那么就允许买方（病人）在向卖方（医生）支付一定费用的情况下取消第三个疗程。买方支付的费用应该确保卖方不因第三个疗程的取消而遭受经济损失
          • 实行分阶段采购。一次只签一个阶段的合同。随着情况明朗，逐期签订后续阶段的合同
          • 越需要敏捷的项目，就越不能把合同签死，越不能采用固定总价合同
      • 15.9 敏捷宣言和敏捷原则
        • 敏捷型方法发源于20世纪90年代的IT软件开发行业。2001年2月，软件开发业的17位领导者在美国犹他州聚会，发布了《软件开发敏捷宣言》（Manifesto for Agile SoftwareDevelopment）（简称《敏捷宣言》）
        • 《敏捷宣言》所推崇的四大价值观是：
          • 个人和互动优先于流程和工具
          • 可用的软件优先于详尽的文档
          • 客户合作优先于合同谈判
          • 响应变化优先于遵循计划
        • 从《敏捷宣言》派生出的12条敏捷原则是：
          • （1）我们的最高目标是，以尽早和持续地交付有价值的软件来满足客户
          • （2）欢迎对需求进行变更，即便是在项目开发后期。我们利用需求变更来为客户建立竞争优势
          • （3）频繁交付可用的软件，周期从几周到几个月不等，且越短越好
          • （4）在整个项目期间，商务人员和开发人员必须每天都紧密合作
          • （5）由被激励的个体去完成项目。为他们提供所需的环境和支持，并相信他们能够完成项目
          • （6）无论在开发团队内部还是向开发团队传递信息，最有效率和效果的沟通方式都是面对面交谈
          • （7）可用的软件是衡量进度的主要指标
          • （8）敏捷过程提倡可持续开发。发起人、开发者和用户应该始终保持稳定的步调
          • （9）通过持续关注技术卓越和设计精良来提升敏捷性
          • （10）追求简化，即尽量减少不必要的工作
          • （11）最好的架构、需求和设计出自自组织团队
          • （12）团队要定期反省如何更加有效，并相应调整团队的行为
    • 第16章 PMP考试的难点与易点
      • 16.1 PMP认证简介
        • 考试时间4小时（9：00--13：00）
        • 正确率62%
        • 200道选择题
      • 16.2 PMP考试的难点
      • 16.3 PMP考试的易点
      • 16.4 应试技巧
      • 16.5 其他
• 敏捷项目管理
  • how
    • 怎样落地敏捷——scrum模式
      • scrum：3-3-5-5-原则
        • 3 roles：
          • product owner（产品经理，简称PO）：build the right thing，对产品的价值观有把控
          • team member（团队成员，开发团队）：build the thing right，保证项目实施进展正确
          • scrum master：build it fast，为团队赋能，团队核心
        • 3 artifacts
          • product backlog（user story：用户故事/用户需求）
          • sprint（冲刺） backlog：forecast，to do ，doing，done
            • 让团队进度更加透明直观
            • 项目进度可视化
          • sprint burn down gadget（任务量大，曲线陡）
        • 5 meetings
          • sprint planning（计划会议）：安排周期性mvp
            • goal
            • PI（产品增量）
            • classify（工作分类）
              • 产品设计
              • 产品开发
              • 产品测试
            • 安排MVP
            • setup stories——拆解story——可操作化
              • 调研用户需求
              • 设计bbs
              • 设计测试与回归测试
            • estimate story point（估测工作量）
              • 定义最小工作量，将实际工作量与最小工作量作比较，估算story point
            • assign
            • break down to tasks
          • daily meeting/stand up meeting（简明扼要）
            • 昨天做了什么
            • 今天要做什么
            • 遇到了哪些困难
          • sprint review
            • 呈现既有可行产品的review
          • sprint retrospect（回顾会）
            • 成员提出项目进展中的优点与缺点
            • 团队进行汇总与反思
          • product backlog grooming（梳理）
            • 对user story进行梳理，筛选出符合用户需求和价值观的story
        • 5 values：核心——以人为本
    • scrum项目的一天
      • product backlog（user story）
      • sprint planning
      • sprint backlog（daily meeting）
      • sprint（1——3weeks）
      • 产出product
      • review——retrospect
  • what
    • 什么是敏捷
      • 敏捷（agile）：快速的反应能力，能让市场、产品快速适应变化和迭代
      • 敏捷宣言（价值观+原则）：以人为本的团队，自组织团队
        • 个体的互动（team合作，重视个体价值，以人为本）高于流程和工具
        • 工作的软件（现成可用的产品，可操作，可落地）高于详尽的文档
        • 客户合作高于合同谈判
        • 响应变化高于遵循计划
      • 敏捷视角：
        • 产品视角：精益思想
        • 规模化视角：SAFE LESS
        • 研发视角：SCRUM XP
  • why
    • 敏捷（agile） vs 瀑布（waterfall）
      • 瀑布：项目过程理想化，但只能自上而下推进，且在最终端产出价值
      • 敏捷：应对需求变更频繁的市场，每个阶段结束都能产出有商业价值的产品（缩短整体成本）
    • 敏捷的优势
      • 频繁变动更新的市场要求缩短产品研发周期
      • 瀑布模式如果产品失败则整体投入落空，风险巨大
      • 敏捷利用短周期适应市场变化、降低研发成本、降低风险
• （第六版）PMBOK结构化解读
  • 第1章 引论
    • 1.1 指南概述与目的
      • 1.1.1 项目管理标准
      • 1.1.2 通用词汇
      • 1.1.3 道德与专业行为规范
    • 1.2 基本要素
      • 1.2.1 项目
      • 项目是为创造独特的产品、服务或成果而进行的临时性工作。
      • 1.2.2 项目管理的重要性
      • 1.2.3 项目、项目集、项目组合以及运营管理之间的关系
      • 1、项目集、项目组合之前怎么区分？ 项目组合主要是为实现战略目标而进行的多个项目。 比如俺们村要发展经济。制定了一个发展战略。要修路，要建厂，要种树，要整田。这些方面都有很多项目，在一起形成了项目组合。 项目集中的项目之间存在着关联关系，要统一考虑以实现更大利益。 比如修路包括多个项目，要修村里的路，村外的路，去乡里赶集的路。这些项目要统筹考虑。别到时修的互相不通，标准不齐。建厂要建养鸡厂，养鸭厂，养驴厂，养鱼塘，要统一考虑，业态互补，别一古脑全上一个类型，死都不知怎么死的。 项目就不说了，可以单独存在，也可以存在于项目组合和项目集中。
        • 1.2.3.1 概述
          • 项目管理过程、工具和技术的运用为组织达成目的和目标奠定了坚实的基础。一个项目可以采用三种不同的模式进行管理：作为一个独立项目（不包括在项目集、项目组合中）、在项目集内或项目组合内。如果在项目集或项目组合内管理项目，则项目经理需要与项目集项目组合经理互动合作。例如，为达成组织的一系列目的和目标，可能需要实施多个项目。在这种情况下，项目可能归入项目集中。项目集是一组相互管理且被协调管理的项目、子项目集和项目集活动，以便获得分别管理所无法获得的利益。项目集不是大项目。规模特别大的项目成为大型项目。
        • 1.2.3.2 项目集管理
        • 1.2.3.3 项目组合管理
          • 项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。
        • 1.2.3.4 运营管理
          • 运营管理关注产品的持续生产和(或)服务的持续运作 。 它使用最优资源满足客户要求，来保证 业务运作的持续高效。它重点管理那些把各种输入(如材料、零件、能源和劳力)转变为输出(如 产品、商品和(或)服务)的过程。
        • 1.2.3.5 运营与项目管理
        • 1.2.3.6 组织级项目管（OPM）与战略
      • 1.2.4 指南的组成部分
        • 1.2.4.1 项目生命周期
          • 项目从开始到结束所经历的一系列阶段
          • 生命周期模式
            • 预测型
            • 迭代型
            • 增量型
            • 适应型
            • 混合型 （预测型和适用型的组合）
        • 1.2.4.2 项目阶段
          • 一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。
        • 1.2.4.3 阶段关口
          • 为做出进入下个阶段、进行整改或结束项目集或项目的决定，而开展的阶段末审查。
          • 阶段关口可能被称为阶段审查、阶段门、关键决策点、和阶段入口或阶段出口
        • 1.2.4.4 项目管理过程
          • 旨在创造最终结果系统化的系列活动，以便对一个或多个输入进行加工，生产一个或多个输出。
        • 1.2.4.5 项目管理过程组
          • 启动过程组
          • 规划过程组
          • 执行过程组
          • 监控过程组
          • 收尾过程组
        • 1.2.4.6 项目管理知识领域
        • 1.2.4.7 项目管理数据和信息
          • 工作绩效数据
          • 工作绩效信息
          • 工作绩效报告
      • 1.2.5 裁剪
        • 应选择恰当的项目管理过程、输入、工具、技术、输出和生命周期阶段以管理项目。这一选择活 动即为针对项目裁剪的项目管理
      • 1.2.6 项目管理商业文件
        • 1.2.6.1 项目商业论证
        • 1.2.6.2 项目绩效管理计划
        • 1.2.6.3 项目章程和项目管理计划
          • 项目章程是由项目发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件
          • 项目管理计划是描述如何执行、监督和控制项目的一份文件。
        • 1.2.6.4 项目成功标准
          • 时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素。
  • 2 项目运行环境
    • 2.1 概述
      • 项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为
      • 事业环境 因素 (EEF) 和组织过程资产 (OPA)
    • 2.2 事业环境因素
      • 事业环境因素(EEFs)是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条 件。这些条件可能来自于组织的内部和(或)外部。事业环境因素是很多项目管理过程，尤其是大 多数规划过程的输入。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极 或消极的影响。
      • 2.2.1 组织内部的事业环境因素
        • 组织文化、结构和治理
        • 设施和资源的地理分布
        • 基础设施
        • 信息技术软件
        • 资源可用性
        • 员工能力
      • 2.2.2 组织外部的事业环境因素
        • 市场条件
        • 社会和文化影响与问题
        • 法律限制
        • 商业数据库
        • 学术研究
        • 政府或行业标准
        • 财务考虑因素
        • 物理环境因素
    • 2.3 组织过程资产
      • 概述
        • 组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管理。
        • 组织过程资产包括来自任何(或所有)项目执行组织的，可用于执行或治理项目的任何工件、实践或知识，还包括来自组织以往项目的经验教训和历史信息。组织过程资产可能还包括完成的进度计划、风险数据和挣值数据。组织过程资产是许多项目管理过程的输入。由于组织过程资产存在于组织内部，在整个项目期间，项目团队成员可对组织过程资产进行必要的更新和增补。组织过程资产可分成以下两大类：过程、政策和程序；组织知识库
        • 第一类资产的更新通常不是项目工作的一部分，而是由项目管理办公室 (PMO) 或项目以外的其他职能部门完成。更新工作仅须遵循与过程、政策和程序更新相关的组织政策。有些组织鼓励团队裁剪项目的模板、生命周期和核对单。在这种情况下，项目管理团队应根据项目需求裁剪这些资产。
        • 第二类资产是在整个项目期间结合项目信息而更新的。例如，整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息。
      • 2.3.1 过程政策和程序
        • 启动和规划
        • 执行、监控
        • 收尾项目收尾指南或要求
      • 2.3.2 组织知识库
        • 配置管理知识库，包括软件硬件组件版本以及所有执行组织的标准、政策、程序和任何项目文件的基准。
        • 财务数据库，包括人工时、实际成本、预算和成本超支等方面的信息;uu历史信息与经验教训知识库(如项目记录与文件、完整的项目收尾信息与文件、关于以往项目
        • 选择决策的结果及以往项目绩效的信息，以及从风险管理活动中获取的信息);
        • 问题与缺陷管理数据库，包括问题与缺陷的状态、控制信息、解决方案以及相关行动的结果;
        • 测量指标数据库，用来收集与提供过程和产品的测量数据;
        • 以往项目的项目档案(如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及相关方登记册)。
    • 2.4 组织系统
      • 2.4.1 概述
      • 2.4.2 组织治理框架
        • 2.4.2.1 治理框架
        • 2.4.2.2 项目组合、项目集和项目治理
          • 四个治理领域
            • 一致性
            • 风险
            • 绩效
            • 沟通
          • 职能部门
            • 监督
            • 控制
            • 整合
            • 决策
          • 项目治理是指用于指导项目管理活动的框架、功能和过程，从而创造独特的产品、服务或结果以 满足组织、战略和运营目标。
      • 2.4.3 管理要素
      • 2.4.4 组织结构类型
        • 2.4.4.1 组织结构类型
        • 2.4.4.2 组织结构选择考虑的因素
          • 与组织目标的一致性
          • 专业能力
          • 控制、效率与效果的程度
          • 明确的决策升级渠道
          • 明确的职权线和范围
          • 授权方面的能力
          • 终责分配
          • 职责分配
          • 设计的灵活性
          • 实施效率
          • 成本考虑
          • 物理位置
          • 清晰的沟通
        • 2.4.4.3 项目管理办公室
        • 项目管理办公室 (PMO) 是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技 术共享的一个组织结构。PMO 的职责范围可大可小，从提供项目管理支持服务，到直接管理一个 或多个项目
        • 类型
          • 支持型
          • 控制型
          • 指令型
  • 3 项目经理的角色
    • 3.1 概述
      • 成员与角色
      • 在团队中的职责- 为团队的成果负责
      • 知识和技能
    • 3.2 项目经理的定义
      • 职能经理
      • 专注于对某个职能领域或业务 部门的管理监督
        • 运营经理
      • 负责业务运营的高效性
        • 项目经理
      • 是由执行组织委派，领导团队实现项目目标的个人
    • 3.3 项目经理的影响力范围
      • 3.3.2 项目
      • 3.3.3 组织
        • 基于组织结构项目经理可能向职能经理汇报
      • 3.3.4 行业
        • 时刻关注行业最新趋势
          • 产品和技术开发
          • 新且正在变化的市场空间
          • 标准（项目管理标准、质量管理标准、信息安全管理标准）
          • 技术支持工具
          • 影响当前项目的经济力量
          • 影响项目管理学科的影响力
          • 过程改进和可持续发展战略
      • 3.3.5 专业学科
        • 持续的知识传递和整合很重要
      • 3.3.6 跨领域
    • 3.4 项目经理的能力
      • 技术项目管理
      • 领导力
        • 领导者的品质和技能
        • 权力
          • 地位(有时称为正式的、权威的、合法的，例如组织或团队授予的正式职位);
          • 信息(例如收集或分发的控制);
          • 参考(例如因为他人的尊重和赞赏，获得的信任);
          • 情境(例如在危机等特殊情况下获得的权力);
          • 个性或魅力(例如魅力、吸引力);
          • 关系(例如参与人际交往、联系和结盟);
          • 专家(例如拥有的技能和信息、经验、培训、教育、证书);
          • 奖励相关的(例如能够给予表扬、金钱或其他奖励);
          • 处罚或强制力(例如给予纪律处分或施加负面后果的能力);
          • 迎合(例如运用顺从或其他常用手段赢得青睐或合作);
          • 施加压力(例如限制选择或活动自由，以符合预期的行动);
          • 出于愧疚(例如强加的义务或责任感);
          • 说服力(例如能够提供论据，使他人执行预期的行动方案);
          • 回避(例如拒绝参与)。
        • 领导力风格
          • 放任型领导(例如，允许团队自主决策和设定目标，又被称为“无为而治”);
          • 交易型领导(例如，关注目标、反馈和成就以确定奖励，例外管理);uu服务型领导(例如，做出服务承诺，处处先为他人着想;关注他人的成长、学习、发展、自主性和福祉;关注人际关系、团体与合作;服务优先于领导);
          • 变革型领导(例如，通过理想化特质和行为、鼓舞性激励、促进创新和创造，以及个人关怀提高追随者的能力);
          • 魅力型领导(例如，能够激励他人;精神饱满、热情洋溢、充满自信;说服力强);uu交互型领导(例如，结合了交易型、变革型和魅力型领导的特点)。
      • 战略和商务管理
    • 3.5 执行整合
      • 过程层面整合
      • 认证层面整合
      • 背景层面整合
      • 整合与复杂性
        • 项目的复杂型来源与组织的系统行为、人类行为、组织或环境的不确定性
        • 系统行为
        • 人类行为
        • 不确定性
  • 4 项目整合
    • 4.1 制定项目章程（启动过程组）
      • 输入
        • 商业文件（企业组织）
          • 商业论证
          • 效益管理计划
          • 注意点
            • 项目外的文件
            • PM无权修改，可建议
        • 协议（实施采购）
        • 事业环境因素（获取资源、建设团队、管理团队）
          • 组织外部
            • 政府行业标准
            • 法律法规
            • 市场条件
            • 组织文化政治氛围
          • 组织内部
            • 组织治理框架
            • 相关方的期望和风险临界值
        • 组织过程资产
          • 过程政策和程序（PMO制定更新）
            • 组织的标准政策
            • 项目组合项目集和项目的治理框架
            • 监督和报告方法
            • 模板
          • 组织知识库（在项目中更新）
            • 历史信息与经验教训登记册
      • 制定一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程
      • 工具与技术
        • 专家判断
          • 组织战略
          • 效益管理
          • 项目所在行业以及项目关注的领域的技术知识
          • 持续的时间和成本估算
          • 风险识别
        • 数据收集
          • 头脑风暴
            • 引导者进行引导 产生创意----> 创意分析
          • 焦点小组
            • 召集相关方讨论项目风险、成功标准、其他。
          • 访谈
            • 了解高层需求
            • 假设条件
            • 制约因素
            • 审批标准
            • 其他信息
        • 人际关系团队技能
          • 冲突管理
            • 达成一致（目标、需求、成功标准、里程碑）
          • 引导
          • 会议管理
            • 准备议程
            • 关键相关方
            • 会议纪要
            • 行动计划
        • 会议
          • 识别项目目标
          • 成功 标准
          • 主要可交付成果
          • 高层需求
          • 总体里程碑
          • 其他
      • 输出
        • 项目章程（发起人发布、授权项目经理） 项目启动会议（initiating meeting）
          • 项目目的
          • 可测量的项目目标和相关方的成功标准
          • 高层级需求
          • 高层级的项目描述、边界定义、主要交付结果
          • 整体项目风险
          • 总体里程碑进度计划
          • 预先批准的财务资源
          • 关键相关方名单
          • 项目审批要求 （什么标准、谁下结论、谁定义）
          • 项目退出标准
          • 委派PM
          • 发起人或其他批准项目章程的人员的姓名
        • 假设日志
          • 假设条件
          • 制约因素
    • 4.2 制定项目管理计划（规划过程组）
      • 输入
        • 项目章程
        • 其他规程的输出
        • 事业环境因素
        • 组织过程资产
      • 定义准备和协调项目计划的所有组成部分，整合成一份综合项目管理计划。
      • 工具与技术
        • 专家判断
        • 数据收集
          • 头脑风暴
          • 核对单 （之前张老师讲过PMP考试前的那个核对单）
            • 很多组织基于自身经验制定了标准化的核对单，或者采用所在行业的核对单。
            • 核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
          • 焦点小组
            • 召集相关方讨论项目管理方法以及项目管理计划哥哥组成部分的整合方式
          • 访谈
            • 从相关方获取特定信息
        • 人际关系与团队技能
          • 冲突管理
          • 引导
          • 会议管理
        • 会议
          • 开工会议
      • 输出
        • 项目管理计划
          • 子管理计划
          • 基准
          • 其他组件
    • 4.3 指导与管理项目工作（执行过程组）
      • 输入
        • 项目管理计划
          • 任何组件
        • 项目文件
          • 变更日志
          • 经验教训登记册
          • 里程碑清单
          • 项目沟通记录
          • 项目进度计划
          • 需求跟踪矩阵
          • 风险登记册
          • 风险报告
        • 批准的变更请求
          • 批准的变更请求是实施整体变更控制过程的输出，包括经项目经理审查和批准的变 更请求，必要时可经变更控制委员会 (CCB) 审查和批准。
        • 事业环境因素
        • 组织过程资产
          • 组织的标准政策、流程和程序;
          • 问题与缺陷管理程序，用于定义问题与缺陷控制、问题与缺陷识别及其解决，以及行动事项跟踪;
          • 问题与缺陷管理数据库，包括历史问题与缺陷状态、问题和缺陷解决情况，以及行动事项的结果;
          • 绩效测量数据库，用来收集与提供过程和产品的测量数据;
          • 变更控制和风险控制程序;
          • 以往项目的项目信息(如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及经验教训知识库)。
      • 实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准的变更。
      • 。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
        • 预防措施
      • 。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
        • 缺陷补救
      • 。为了修正不一致产品或产品组件的有目的的活动。
        • 更新
      • 。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。（12 + 6）
        • 项目管理计划更新
          • 任何组件
          • 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新。
      • 工具与技术
        • 专家判断
        • 项目管理信息系统
        • 会议
      • 输出
        • 可交付成果
          • 可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是项目结果，并可包括项目管理计划的组成部分。
          • 一旦完成了可交付成果的第一个版本，就应该执行变更控制。用配置管理工具和程序来支持对可交付成果(如文件、软件和构件)的多个版本的控制。
        • 工作绩效数据
        • 问题日志
        • 变更请求
          • 纠正措施
        • 项目文件更新
          • 活动清单
          • 假设日志
          • 经验教训登记册
          • 需求文件
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
    • 4.4 管理项目知识（执行过程组）
      • 输入
        • 项目管理计划
          • 所有组件
        • 事业环境因素
          • 组织文化、相关方文化和客户文化
          • 设施和资源的地理分布
          • 组织中的知识专家
          • 法律法规要求和制约因素
        • 组织过程资产
          • 组织的标准政策、流程和程序
          • 人事管理制度
          • 组织对沟通的要求
          • 正式的知识分享和信息分享程序
      • 管理项目知识使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。 知识分为显性知识、隐性知识。 营造氛围，激励大家互相分享知识。
      • 创造信息并建立人们与信息之间的联系。 直接询问通常是一种更轻松快捷的方式
        • 编撰显性知识的方法：例如确认经验教训登记册的条目
        • 经验教训登记册
        • 图书馆服务
        • 信息收集
        • PMIS
      • 工具与技术
        • 专家判断
        • 知识管理（面对面互动最有利于建立知识管理所需的信任关系）
          • 人际交往
          • 实践社区
          • 会议
          • 工作跟随和跟随指导
          • 讨论论坛
          • 知识分享活动
          • 研讨会
          • 等
        • 信息管理
        • 人际关系与团队技能
          • 积极倾听
            • 减少误解
          • 引导
            • 达成统一决定、解决方案和结论。
          • 领导力
            • 帮助沟通愿景并鼓舞项目团队关注何时的知识和知识目标。
          • 人际交往
            • 为显示知识和隐形知识创造条件
          • 政治意识
      • 输出
        • 经验教训登记册
        • 项目管理计划更新
          • 任何组件
        • 组织过程资产
          • 可更新任一组织过程资产
    • 4.5 监控项目工作（监控过程组）
      • 输入
        • 项目管理计划
          • 任何组件（12+6）
        • 项目文件
          • 假设日志
          • 估算依据
          • 成本预测
          • 问题日志
          • 经验教训登记册
          • 里程碑清单
          • 质量报告
          • 进度预测
        • 工作绩效信息
        • 协议
        • 事业环境因素
        • 组织过程资产
      • 跟踪审查和报告整体项目进展
      • 工具与技术
        • 专家判断
        • 数据分析
          • 备选方案分析
          • 成本效益分析
          • 挣值分析
          • 根本原因分析
          • 趋势分析
          • 偏差分析
        • 决策
        • 会议
      • 输出
        • 工作绩效报告
        • 变成请求
        • 项目管理计划
          • 项目文件更新
          • 成本预测
          • 问题日志
          • 经验教训登记册
          • 风险登记册
          • 进度预测
    • 4.6 实施整体变更控制（监控过程组）
      • 实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。 所有变更都必须以书面形式记录
      • 输入
        • 项目管理计划
          • 变更管理计划
          • 配置管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件
          • 估算依据
          • 需求跟踪矩阵
          • 风险报告
        • 工作绩效报告
        • 变更请求
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 变更控制工具
        • 数据分析
          • 备选方案分析
          • 成本效益分析
        • 决策
          • 投票
          • 独裁你型决策制定
          • 多标准决策制定
        • 会议
      • 输出
        • 批准的变更请求
        • 项目管理计划更新
          • 任何组件
        • 项目文件更新
          • 变更日志
    • 4.7 结束项目或阶段（结束过程组）
      • 输入
        • 项目章程
        • 项目管理计划
          • 所有组件
        • 项目文件
          • 假设日志
          • 估算依据
          • 变更日志
          • 问题日志
          • 经验教训登记册
          • 里程碑清单
          • 项目沟通记录
          • 质量控制测量结果
          • 质量报告
          • 需求文件
          • 风险登记册
          • 风险报告
        • 验收的可交付成果（确认范围）
        • 商业文件
          • 商业论证
          • 效益管理计划
        • 协议
        • 采购文件
        • 组织过程资产
      • 终结项目、阶段或合同的所有活动的过程。 存档项目或阶段信息，完成计划的工作，释放组织团队资源。 仅开展一次。​
      • 工具与技术
        • 专家判断
        • 数据分析
        • 会议
      • 输出
        • 项目文件更新
        • 最终产品服务或成果移交
        • 最终报告
        • 组织过程资产
  • 5 项目范围管理
    • 规划范围
      • - 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
    • 收集需求
      • - 为实现项目目标而确定、记录并管理相关方的需要和需求过程
    • 定义范围
      • - 制定项目和产品详细描述的过程
    • 创建WBS
      • - 将项目可交付成果和项目工作分解为较小的、更易于组件管理的过程
    • 确认范围
      • - 正式验收已完成的项目可交付成果的过程
    • 控制范围
      • - 监督项目和产品的范围状态，管理范围基准变更的过程
  • 8 项目质量管理
    • 规划质量管理
    • 管理质量
    • 控制质量
  • 13 项目相关方管理
    • 识别相关方
    • 规划相关方参与 提供与相关方进行有效互动的可行计划。 输出相关方参与计划 ​
    • 管理相关方参与
    • 监督相关方参与
• 知识体系（第六版）
  • 49个过程可分为5大过程组也可分为10大知识领域。每个过程都有自己的输入、工具与技术换输出，这49个过程一共涉及到80个输或输出以及132个工具与技术
  • 49个过程
    • 这49个过程横向可分为10大知识领域，纵向分为5大过程组，如下图 
    • 每个过程相当于一个黑箱，黑箱内藏着各种工具与技术。每个黑箱有数量不等的输入，也同样有数量不等的输出。这些黑箱通过输入和输出相互衔接组成了一个极度复杂的网络。 
  • 5大过程组
    • 包括启动过程组（2个过程）、规划过程组（24个过程）、执行过程组（10个过程）、监控过程组（12个过程）和收尾过程组（1个过程）
    • 在工作中这5个过程组并非简单地顺序执行，而是相互交叉甚至循环执行，如下图 
  • 10大知识领域
    • 10大知识领域可以简单分为三个部分。
      • 【项目整合管理】和【项目风险管理】负责总体把控；
      • 【项目范围管理】、【项目进度管理】、【项目成本管理】和【项目质量管理】负责管事；
      • 【项目资源管理】、【项目沟通管理】、【项目采购管理】和【项目相关方管理】负责管人。
      • 
  • 80个输入输出
    • 前面介绍了过程是一个黑箱，每个黑箱都会有若干个输入和输出，这些输入输出的总数是80个，也大体可以分为3类，即项目管理计划（18个）、项目文件（33个）和其他（29个）。项目管理计划和项目文件如下图 
  • 132个工具与技术
    • 每个过程都有自己的多个【工具与技术】包括数据收集（9个）、数据表现（15个）、决策（3个）、沟通技巧（2个）、人际关系与团队技能（17个）、未分组（59个）。其中数据收集工具与技术如下图，图中的数字表示章节。 
  • 《PMBOK指南》是一个复杂的知识体系，在项目管理工作中不必完全照搬所有的过程，需要进行裁剪。它就像一个武器库，供你在需要的时候抽出若干件武器应用于工作中；它也像一本字典，供你在遇到项目管理难题时进行查阅；它更像一个产品，随着时间的推移在不断迭代升级。所以在工作中需要活学活用。
• ITTO
  • 输出
    • 项目章程（Project Charter）
      • 制定项目章程
    • 可交付成果（Deliverable）
      • 指导与管理项目工作
    • 验收的可交付成果（Accepted Deliverables）
      • 确认范围
    • 核实的可交付成果（Verified Deliverables）
      • 控制质量
    • 工作绩效数据（Work Performance Data）
      • 指导与管理项目工作
    • 工作绩效信息（Work Performance Information）
      • 确认范围
      • 控制范围
      • 控制进度
      • 控制成本
      • 控制质量
      • 控制资源
      • 监督沟通
      • 监督风险
      • 控制采购
      • 监督相关方参与
    • 工作绩效报告（Work Performance Reports）
      • 监控项目工作
    • 假设日志（Assumption Log）
      • 制定项目章程
    • 问题日志（Issue Log）
      • 指导与管理项目工作
    • 变更请求（Change Request）
      • 指导与管理项目工作
      • 监控项目工作
      • 确认范围
      • 控制范围
      • 定义活动
      • 制定进度计划
      • 控制进度
      • 控制成本
      • 管理质量
      • 控制质量
      • 获取资源
      • 建设团队
      • 管理团队
      • 控制资源
      • 监督沟通
      • 规划风险应对
      • 实施风险应对
      • 监督风险
      • 规划采购管理
      • 实施采购
      • 控制采购
      • 识别相关方
      • 管理相关方参与
      • 监督相关方参与
    • 批准的变更请求
      • 实施整体变更控制
    • 经验教训登记册（Lessons Learned Register）
      • 管理项目知识
    • 相关方登记册（Stakeholder Register）
      • 识别相关方
    • 风险登记册（Risk Register）
      • 识别风险
    • 最终产品、服务或成果移交
      • 结束项目或阶段
    • 最终报告
      • 结束项目或阶段
    • 质量报告（Quality Report）
      • 管理质量
    • 风险报告（Risk Report）
      • 识别风险
    • 测试与评估文件（Test and Evaluation Documents）
      • 管理质量
    • 质量控制测量结果（Quality Control Measurements）
      • 控制质量
    • 项目管理计划（Project Management Plan）
      • 制定项目管理计划
    • 范围管理计划（Scope Management Plan）
      • 规划范围管理
    • 需求管理计划（Requirements Management Plan）
      • 规划范围管理
    • 进度管理计划（Schedule Management Plan）
      • 规划进度管理
    • 质量管理计划（Quality Management Plan）
      • 规划质量管理
    • 资源管理计划（Resource Management Plan）
      • 规划资源管理
    • 沟通管理计划（Communications Management Plan）
      • 规划沟通管理
    • 风险管理计划（Risk Management Plan）
      • 规划风险管理
    • 采购管理计划（Procurement Management Plan）
      • 规划采购管理
    • 成本管理计划（Cost Management Plan）
      • 规划成本管理
    • 相关方参与计划（Stakeholder Engagement Plan）
      • 规划相关方参与
    • 项目进度计划（Project Schedule）
      • 制定进度计划
    • 质量测量指标（Quality Metrics）
      • 规划质量管理
    • 采购策略（Procurement Strategy）
      • 规划采购管理
    • 采购工作说明书（Procurement Statement of Work）
      • 规划采购管理
    • 招标文件（Bid Documents）
      • 规划采购管理
    • 供方选择标准（Source Selection Criteria）
      • 规划采购管理
    • 自制或外购策略（Make-or-Buy Decisions）
      • 规划采购管理
    • 独立成本估算
      • 规划采购管理
    • 投标人会议（Bidder Conference）
      • 实施采购
    • 结束的采购
      • 控制采购
    • 协议（Agreements）
      • 实施采购
    • 需求文件（Requirements Documentation）
      • 收集需求
    • 需求跟踪矩阵（Requirements Traceability Matrix）
      • 收集需求
    • 项目范围说明书（Project Scope Statement）
      • 定义范围
    • 范围基准（Scope Baseline）
      • 创建 WBS
    • 进度基准（Schedule Baseline）
      • 制定进度计划
    • 成本基准（Cost Baseline）
      • 制定预算
    • 活动清单（Activity List）
      • 定义活动
    • 活动属性（Activity Attributes）
      • 定义活动
    • 里程碑清单（Milestone List）
      • 定义活动
    • 项目进度网络图（Project Schedule Network Diagram）
      • 排列活动顺序
    • 进度数据（Schedule Data）
      • 制定进度计划
    • 进度预测（Schedule Forecasts）
      • 控制进度
    • 项目日历（Project Calendar）
      • 制定进度计划
    • 资源日历（Resource Calendar）
      • 获取资源
    • 持续时间估算
      • 估算活动持续时间
    • 估算依据（Basis of Estimates）
      • 估算活动持续时间
      • 估算成本
      • 估算活动资源
    • 成本估算
      • 估算成本
    • 成本预测
      • 控制成本
    • 团队章程（Team Charter）
      • 规划资源管理
    • 团队绩效评价
      • 建设团队
    • 资源需求（Resource Requirements）
      • 估算活动资源
    • 资源分解结构（Resource Breakdown Structure）
      • 估算活动资源
    • 物质资源分配单
      • 获取资源
    • 项目团队派工单
      • 获取资源
    • 项目资金需求（Project Funding Requirements）
      • 制定预算
    • 项目沟通记录
      • 管理沟通
    • 项目文件更新
      • 活动属性
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 估算活动资源
      • 活动清单
        • 指导与管理项目工作
        • 排列活动顺序
      • 假设日志
        • 指导与管理项目工作
        • 定义范围
        • 创建 WBS
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 估算成本
        • 控制成本
        • 规划资源管理
        • 估算活动资源
        • 控制资源
        • 识别风险
        • 实施定性风险分析
        • 规划风险应对
        • 监督风险
        • 识别相关方
      • 里程碑清单
        • 排列活动顺序
        • 规划采购管理
      • 经验教训登记册
        • 指导与管理项目工作
        • 监控项目工作
        • 结束项目或阶段
        • 确认范围
        • 控制范围
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 估算成本
        • 控制成本
        • 规划质量管理
        • 管理质量
        • 控制质量
        • 估算活动资源
        • 获取资源
        • 建设团队
        • 管理团队
        • 控制资源
        • 管理沟通
        • 监督沟通
        • 识别风险
        • 规划风险应对
        • 实施风险应对
        • 监督风险
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 管理相关方参与
        • 监督相关方参与
      • 需求文件
        • 指导与管理项目工作
        • 定义范围
        • 创建 WBS
        • 确认范围
        • 控制范围
        • 规划采购管理
        • 实施采购
      • 需求跟踪矩阵
        • 定义范围
        • 确认范围
        • 控制范围
        • 规划质量管理
        • 规划采购管理
        • 实施采购
        • 控制采购
      • 资源需求
        • 制定进度计划
        • 获取资源
        • 控制采购
      • 测试与评估文件
        • 控制质量
      • 资源日历
        • 控制进度
        • 建设团队
        • 实施采购
      • 资源分解结构
        • 获取资源
        • 控制资源
      • 物质资源分配单
        • 控制资源
      • 风险登记册
        • 指导与管理项目工作
        • 制定进度计划
        • 控制进度
        • 估算成本
        • 制定预算
        • 控制成本
        • 规划质量管理
        • 管理质量
        • 控制质量
        • 规划资源管理
        • 获取资源
        • 控制资源
        • 管理沟通
        • 实施定性风险分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 识别相关方
        • 监督相关方参与
      • 变更日志
        • 实施整体变更控制
        • 管理相关方参与
      • 问题日志
        • 监控项目工作
        • 管理质量
        • 控制质量
        • 管理团队
        • 控制资源
        • 管理沟通
        • 监督沟通
        • 识别风险
        • 实施定性风险分析
        • 实施风险应对
        • 监督风险
        • 识别相关方
        • 管理相关方参与
        • 监督相关方参与
      • 风险报告
        • 实施定性风险分析
        • 实施定量风险分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
      • 团队章程
        • 建设团队
      • 进度预测
        • 监控项目工作
      • 进度数据
        • 控制进度
      • 成本预测
        • 监控项目工作
        • 规划风险应对
      • 成本估算
        • 制定预算
        • 控制成本
      • 持续时间估算
        • 制定进度计划
      • 估算依据
        • 控制进度
        • 控制成本
      • 项目进度计划
        • 控制进度
        • 制定预算
        • 获取资源
        • 建设团队
        • 规划沟通管理
        • 管理沟通
        • 规划风险应对
      • 项目团队派工单
        • 建设团队
        • 管理团队
        • 规划风险应对
        • 实施风险应对
      • 相关方登记册
        • 指导与管理项目工作
        • 定义范围
        • 规划质量管理
        • 获取资源
        • 规划沟通管理
        • 管理沟通
        • 监督沟通
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 管理相关方参与
        • 监督相关方参与
    • 采购文档更新
      • 控制采购
    • 项目管理计划更新
      • 范围管理计划
        • 控制范围
      • 范围基准
        • 控制范围
        • 规划质量管理
        • 管理质量
        • 规划风险应对
        • 实施采购
      • 进度基准
        • 控制范围
        • 定义活动
        • 控制进度
        • 管理质量
        • 管理团队
        • 控制资源
        • 规划风险应对
        • 实施采购
        • 控制采购
      • 成本基准
        • 控制范围
        • 定义活动
        • 制定进度计划
        • 控制进度
        • 控制成本
        • 管理质量
        • 获取资源
        • 管理团队
        • 控制资源
        • 规划风险应对
        • 实施采购
        • 控制采购
      • 进度管理计划
        • 制定进度计划
        • 控制进度
        • 规划风险应对
      • 绩效测量基准
        • 控制范围
        • 控制进度
        • 控制成本
      • 成本管理计划
        • 控制成本
        • 规划风险应对
      • 风险管理计划
        • 规划质量管理
        • 实施采购
        • 控制采购
        • 识别相关方
      • 质量管理计划
        • 管理质量
        • 控制质量
        • 规划风险应对
        • 实施采购
      • 资源管理计划
        • 获取资源
        • 建设团队
        • 管理团队
        • 控制资源
        • 规划风险应对
        • 监督相关方参与
      • 采购管理计划
        • 规划风险应对
        • 实施采购
        • 控制采购
      • 沟通管理计划
        • 管理沟通
        • 监督沟通
        • 实施采购
        • 识别相关方
        • 管理相关方参与
        • 监督相关方参与
      • 需求管理计划
        • 实施采购
        • 识别相关方
      • 相关方参与计划
        • 规划沟通管理
        • 管理沟通
        • 监督沟通
        • 识别相关方
        • 管理相关方参与
        • 监督相关方参与
      • 任何组件
        • 指导与管理项目工作
        • 管理项目知识
        • 监控项目工作
        • 实施整体变更控制
        • 监督风险
    • 事业环境因素更新
      • 获取资源
      • 建设团队
      • 管理团队
    • 组织过程资产更新
      • 指导与管理项目工作
      • 管理项目知识
      • 结束项目或阶段
      • 获取资源
      • 建设团队
      • 管理沟通
      • 监督风险
      • 规划采购管理
      • 实施采购
      • 控制采购
  • 工具与技术
    • 专家判断（Expert Judgment）
      • 制定项目章程
      • 制定项目管理计划
      • 指导与管理项目工作
      • 管理项目知识
      • 监控项目工作
      • 实施整体变更控制
      • 结束项目或阶段
      • 规划范围管理
      • 收集需求
      • 定义范围
      • 创建 WBS
      • 确认范围
      • 控制范围
      • 规划进度管理
      • 定义活动
      • 排列活动顺序
      • 估算活动持续时间
      • 制定进度计划
      • 控制进度
      • 规划成本管理
      • 估算成本
      • 制定预算
      • 控制成本
      • 规划质量管理
      • 管理质量
      • 控制质量
      • 规划资源管理
      • 估算活动资源
      • 获取资源
      • 建设团队
      • 管理团队
      • 控制资源
      • 规划沟通管理
      • 管理沟通
      • 监督沟通
      • 规划风险管理
      • 识别风险
      • 实施定性风险分析
      • 实施定量风险分析
      • 规划风险应对
      • 实施风险应对
      • 监督风险
      • 规划采购管理
      • 实施采购
      • 控制采购
      • 识别相关方
      • 规划相关方参与
      • 管理相关方参与
      • 监督相关方参与
    • 类比估算（Analogous Estimating）
      • 估算活动持续时间
      • 估算成本
      • 估算活动资源
    • 参数估算（Parametric Estimating）
      • 估算活动持续时间
      • 估算成本
      • 估算活动资源
    • 三点估算（Three-Point Estimating）
      • 估算活动持续时间
      • 估算成本
    • 自下而上估算（Bottom-Up Estimating）
      • 估算活动持续时间
      • 估算成本
      • 估算活动资源
    • 变更控制工具（Change Control Tools）
      • 实施整体变更控制
    • 成本汇总（Cost Aggregation）
      • 制定预算
    • 知识管理
      • 管理项目知识
    • 信息管理
      • 管理项目知识
    • 历史信息审核
      • 制定预算
    • 资金限制平衡（Funding Limit Reconciliation）
      • 制定预算
    • 融资
      • 制定预算
    • 广告
      • 实施采购
    • 投标人会议（Bidder Conference）
      • 实施采购
    • 审计
      • 管理质量
      • 监督风险
      • 控制采购
    • 面向 X 的设计
      • 管理质量
    • 问题解决
      • 管理质量
      • 控制资源
    • 质量改进方法
      • 管理质量
    • 完工尚需绩效指数（To-Complete Performance Index）
      • 控制成本
    • 测试与检查的规划
      • 规划质量管理
    • 测试/产品评估
      • 控制质量
    • 组织理论
      • 规划资源管理
    • 预分派
      • 获取资源
    • 沟通需求分析（Communication Requirements Analysis）
      • 规划沟通管理
    • 沟通技术（Communication Technology）
      • 建设团队
      • 规划沟通管理
      • 管理沟通
    • 沟通模型（Communication Models）
      • 规划沟通管理
    • 沟通方法（Communication Methods）
      • 规划沟通管理
      • 管理沟通
    • 沟通技能
      • 沟通胜任力
        • 管理沟通
      • 反馈
        • 管理沟通
        • 管理相关方参与
        • 监督相关方参与
      • 非言语
        • 管理沟通
      • 演示
        • 管理沟通
        • 监督相关方参与
    • 数据收集（Data Gathering Techniques）
      • 头脑风暴
        • 制定项目章程
        • 制定项目管理计划
        • 收集需求
        • 规划质量管理
        • 识别风险
        • 识别相关方
      • 核对单
        • 制定项目管理计划
        • 管理质量
        • 控制质量
      • 核查表（Checksheets）
        • 控制质量
      • 统计抽样（Statistical Sampling）
        • 控制质量
      • 焦点小组（Focus Groups）
        • 制定项目章程
        • 制定项目管理计划
        • 收集需求
      • 访谈（Interviews）
        • 制定项目章程
        • 制定项目管理计划
        • 收集需求
        • 规划质量管理
        • 识别风险
        • 实施定性风险分析
        • 实施定量风险分析
        • 规划风险应对
      • 问卷调查（Questionnaires）
        • 收集需求
        • 控制质量
        • 识别相关方
      • 标杆对照（Benchmarking）
        • 收集需求
        • 规划质量管理
        • 规划相关方参与
      • 市场调研
        • 规划采购管理
    • 数据分析（Data Analysis Techniques）
      • 备选方案分析（Alternative Analysis）
        • 监控项目工作
        • 实施整体变更控制
        • 规划范围管理
        • 定义范围
        • 规划进度管理
        • 估算活动持续时间
        • 规划成本管理
        • 估算成本
        • 管理质量
        • 估算活动资源
        • 控制资源
        • 规划风险应对
        • 监督相关方参与
      • 成本效益分析（Cost-Benefit Analysis）
        • 监控项目工作
        • 实施整体变更控制
        • 规划质量管理
        • 控制资源
        • 规划风险应对
      • 储备分析（Reserve Analysis）
        • 估算活动持续时间
        • 估算成本
        • 制定预算
        • 控制成本
        • 监督风险
      • 质量成本（Cost of Quality）
        • 估算成本
        • 规划质量管理
      • 挣值分析（Earned Value Analysis）
        • 监控项目工作
        • 控制进度
        • 控制成本
        • 控制采购
      • 迭代燃尽图
        • 控制进度
      • 绩效审查（Performance Reviews）
        • 控制进度
        • 控制质量
        • 控制资源
        • 控制采购
      • 根本原因分析（Root Cause Analysis）
        • 监控项目工作
        • 管理质量
        • 控制质量
        • 识别风险
        • 规划相关方参与
        • 监督相关方参与
      • 趋势分析（Trend Analysis）
        • 监控项目工作
        • 结束项目或阶段
        • 控制范围
        • 控制进度
        • 控制成本
        • 控制资源
        • 控制采购
      • 过程分析
        • 管理质量
      • 文件分析
        • 结束项目或阶段
        • 收集需求
        • 管理质量
        • 识别风险
        • 识别相关方
      • 回归分析（Regression Analysis）
        • 结束项目或阶段
      • 假设情景分析（What-If Scenario Analysis）
        • 制定进度计划
        • 控制进度
      • 模拟（Simulation）
        • 制定进度计划
        • 实施定量风险分析
      • 敏感性分析（Sensitivity Analysis）
        • 实施定量风险分析
      • 决策树分析（Decision Tree Analysis）
        • 实施定量风险分析
      • 影响图（Influence Diagram）
        • 实施定量风险分析
      • 相关方参与度评估矩阵（Stakeholder Engagement Assessment Matrix）
        • 监督沟通
      • 相关方分析（Stakeholder Analysis）
        • 规划风险管理
        • 识别相关方
        • 监督相关方参与
      • 偏差分析（Variance Analysis）
        • 监控项目工作
        • 结束项目或阶段
        • 控制范围
        • 控制进度
        • 控制成本
      • 假设条件和制约因素分析
        • 识别风险
        • 规划相关方参与
      • SWOT 分析（SWOT Analysis）
        • 识别风险
      • 风险数据质量评估（Risk Data Quality Assessment）
        • 实施定性风险分析
      • 风险概率和影响评估
        • 实施定性风险分析
      • 其他风险参数评估
        • 实施定性风险分析
      • 技术绩效分析
        • 监督风险
      • 自制或外购分析（Make-or-Buy Analysis）
        • 规划采购管理
      • 建议书评价（Proposal Evaluation Techniques）
        • 实施采购
    • 数据表现（Data Representation Techniques）
      • 亲和图（Affinity Diagrams）
        • 收集需求
        • 管理质量
      • 思维导图（Mind-Mapping）
        • 收集需求
        • 规划质量管理
        • 规划相关方参与
      • 因果图（Cause and Effect Diagram）
        • 管理质量
        • 控制质量
      • 流程图（Flowchart）
        • 规划质量管理
        • 管理质量
      • 直方图（Histogram）
        • 管理质量
        • 控制质量
      • 控制图（Control Chart）
        • 控制质量
      • 逻辑数据模型
        • 规划质量管理
      • 散点图
        • 管理质量
        • 控制质量
      • 文本型
        • 规划资源管理
      • 责任分配矩阵（Responsibility Assignment Matrix）
        • 规划资源管理
      • 层级型
        • 规划资源管理
        • 实施定性风险分析
      • 相关方参与度评估矩阵（Stakeholder Engagement Assessment Matrix）
        • 规划沟通管理
        • 规划相关方参与
        • 监督相关方参与
      • 相关方映射分析/表现
        • 识别相关方
      • 矩阵图（Matrix Diagrams）
        • 规划质量管理
        • 管理质量
      • 概率和影响矩阵（Probability and Impact Matrix）
        • 实施定性风险分析
    • 决策（Decision-Making Techniques）
      • 投票
        • 监控项目工作
        • 实施整体变更控制
        • 收集需求
        • 确认范围
        • 估算活动持续时间
        • 估算成本
        • 监督相关方参与
      • 独裁型决策制定
        • 实施整体变更控制
      • 一人拍板的决策
        • 收集需求
      • 多标准决策分析（Multicriteria Decision Analysis）
        • 实施整体变更控制
        • 收集需求
        • 定义范围
        • 规划质量管理
        • 管理质量
        • 获取资源
        • 规划风险应对
        • 监督相关方参与
      • 优先级排序或分级
        • 规划相关方参与
    • 人际关系与团队技能（Interpersonal and Team Skills）
      • 积极倾听
        • 管理项目知识
        • 管理沟通
        • 监督相关方参与
      • 领导力
        • 管理项目知识
        • 管理团队
        • 监督相关方参与
      • 人际交往（Networking）
        • 管理项目知识
        • 管理沟通
        • 监督相关方参与
      • 政治意识
        • 管理项目知识
        • 规划沟通管理
        • 管理沟通
        • 管理相关方参与
        • 监督相关方参与
      • 文化意识
        • 规划沟通管理
        • 管理沟通
        • 管理相关方参与
        • 监督相关方参与
      • 冲突管理
        • 制定项目章程
        • 制定项目管理计划
        • 建设团队
        • 管理团队
        • 管理沟通
        • 管理相关方参与
      • 引导
        • 制定项目章程
        • 制定项目管理计划
        • 管理项目知识
        • 收集需求
        • 定义范围
        • 识别风险
        • 实施定性风险分析
        • 实施定量风险分析
        • 规划风险应对
      • 观察和交谈
        • 收集需求
        • 监督沟通
        • 管理相关方参与
      • 名义小组技术（Nominal Group Technique）
        • 收集需求
      • 谈判
        • 获取资源
        • 建设团队
        • 控制资源
        • 实施采购
        • 管理相关方参与
      • 影响力
        • 建设团队
        • 管理团队
        • 控制资源
        • 实施风险应对
      • 激励
        • 建设团队
      • 团队建设
        • 建设团队
      • 制定决策
        • 管理团队
      • 情商（Emotional Intelligence）
        • 管理团队
      • 沟通风格评估（Communication Styles Assessment）
        • 规划沟通管理
      • 会议管理
        • 制定项目章程
        • 制定项目管理计划
        • 管理沟通
    • 系统交互图（Context Diagrams）
      • 收集需求
    • 原型法（Prototypes）
      • 收集需求
    • 产品分析（Product Analysis）
      • 定义范围
    • 分解（Decomposition）
      • 创建 WBS
      • 定义活动
    • 滚动式规划（Rolling Wave Planning）
      • 定义活动
    • 检查（Inspection）
      • 确认范围
      • 控制质量
      • 控制采购
    • 紧前关系绘图法（Precedence Diagramming Method）
      • 排列活动顺序
    • 确定和整合依赖关系
      • 排列活动顺序
    • 提前量和滞后量（Lead and Lag）
      • 排列活动顺序
      • 制定进度计划
      • 控制进度
    • 进度压缩（Schedule Compression）
      • 制定进度计划
      • 控制进度
    • 关键路径法（Critical Path Method）
      • 制定进度计划
      • 控制进度
    • 进度网络分析（Schedule Network Analysis）
      • 制定进度计划
    • 资源优化（Resource Optimization Technique）
      • 制定进度计划
      • 控制进度
    • 敏捷发布规划
      • 制定进度计划
    • 集中办公（Colocation）
      • 建设团队
    • 虚拟团队（Virtual Teams）
      • 获取资源
      • 建设团队
    • 认可与奖励
      • 建设团队
    • 培训
      • 建设团队
    • 个人和团队评估
      • 建设团队
    • 项目报告
      • 管理沟通
    • 提示清单
      • 识别风险
    • 风险分类（Risk Categorization）
      • 实施定性风险分析
    • 不确定性表现方式
      • 实施定量风险分析
    • 威胁应对策略
      • 规划风险应对
    • 机会应对策略
      • 规划风险应对
    • 应急应对策略（Contingent Response Strategies）
      • 规划风险应对
    • 整体项目风险应对策略
      • 规划风险应对
    • 供方选择分析
      • 规划采购管理
    • 索赔管理（Claims Administration）
      • 控制采购
    • 基本规则（Ground Rules）
      • 管理相关方参与
    • 项目管理信息系统（Project Management Information System）
      • 指导与管理项目工作
      • 排列活动顺序
      • 制定进度计划
      • 控制进度
      • 估算成本
      • 控制成本
      • 估算活动资源
      • 管理团队
      • 控制资源
      • 管理沟通
      • 监督沟通
      • 实施风险应对
    • 会议
      • 制定项目章程
      • 制定项目管理计划
      • 指导与管理项目工作
      • 监控项目工作
      • 实施整体变更控制
      • 结束项目或阶段
      • 规划范围管理
      • 规划进度管理
      • 定义活动
      • 估算活动持续时间
      • 规划成本管理
      • 规划质量管理
      • 控制质量
      • 规划资源管理
      • 估算活动资源
      • 建设团队
      • 规划沟通管理
      • 管理沟通
      • 监督沟通
      • 规划风险管理
      • 识别风险
      • 实施定性风险分析
      • 监督风险
      • 识别相关方
      • 规划相关方参与
      • 管理相关方参与
      • 监督相关方参与
  • 输入
    • 商业文件
      • 商业论证（Business Case）
        • 制定项目章程
        • 结束项目或阶段
        • 收集需求
        • 制定预算
        • 规划采购管理
        • 识别相关方
      • 效益管理计划（Benefits Management Plan）
        • 结束项目或阶段
        • 制定预算
        • 规划采购管理
        • 识别相关方
    • 协议（Agreements）
      • 制定项目章程
      • 监控项目工作
      • 结束项目或阶段
      • 收集需求
      • 制定进度计划
      • 制定预算
      • 控制资源
      • 识别风险
      • 控制采购
      • 识别相关方
      • 规划相关方参与
    • 项目章程（Project Charter）
      • 制定项目管理计划
      • 结束项目或阶段
      • 规划范围管理
      • 收集需求
      • 定义范围
      • 规划进度管理
      • 规划成本管理
      • 规划质量管理
      • 规划资源管理
      • 规划沟通管理
      • 规划风险管理
      • 规划采购管理
      • 识别相关方
      • 规划相关方参与
    • 项目管理计划（Project Management Plan）
      • 变更管理计划（Change Management Plan）
        • 实施整体变更控制
        • 控制范围
        • 控制采购
        • 管理相关方参与
      • 配置管理计划（Configuration Management Plan）
        • 实施整体变更控制
        • 控制范围
        • 实施采购
      • 质量管理计划（Quality Management Plan）
        • 规划范围管理
        • 估算成本
        • 管理质量
        • 控制质量
        • 规划资源管理
        • 识别风险
        • 规划采购管理
      • 范围管理计划（Scope Management Plan）
        • 收集需求
        • 定义范围
        • 创建 WBS
        • 确认范围
        • 控制范围
        • 规划进度管理
        • 规划采购管理
        • 实施采购
      • 需求管理计划（Requirements Management Plan）
        • 收集需求
        • 确认范围
        • 控制范围
        • 规划质量管理
        • 识别风险
        • 实施采购
        • 控制采购
      • 进度管理计划（Schedule Management Plan）
        • 定义活动
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 规划成本管理
        • 识别风险
      • 风险管理计划（Risk Management Plan）
        • 规划成本管理
        • 规划质量管理
        • 识别风险
        • 实施定性风险分析
        • 实施定量风险分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
        • 实施采购
        • 控制采购
        • 规划相关方参与
        • 管理相关方参与
      • 成本管理计划（Cost Management Plan）
        • 估算成本
        • 制定预算
        • 控制成本
        • 识别风险
      • 资源管理计划（Resource Management Plan）
        • 制定预算
        • 估算活动资源
        • 获取资源
        • 建设团队
        • 管理团队
        • 控制资源
        • 规划沟通管理
        • 管理沟通
        • 监督沟通
        • 识别风险
        • 规划风险应对
        • 规划采购管理
        • 规划相关方参与
        • 监督相关方参与
      • 采购管理计划（Procurement Management Plan）
        • 获取资源
        • 实施采购
        • 控制采购
      • 沟通管理计划（Communications Management Plan）
        • 管理沟通
        • 监督沟通
        • 实施采购
        • 识别相关方
        • 规划相关方参与
        • 管理相关方参与
        • 监督相关方参与
      • 相关方参与计划（Stakeholder Engagement Plan）
        • 收集需求
        • 规划质量管理
        • 规划沟通管理
        • 管理沟通
        • 监督沟通
        • 识别相关方
        • 管理相关方参与
        • 监督相关方参与
      • 项目生命周期描述
        • 规划范围管理
      • 开发方法（Development Approach）
        • 规划范围管理
        • 规划进度管理
      • 范围基准（Scope Baseline）
        • 实施整体变更控制
        • 确认范围
        • 控制范围
        • 定义活动
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 估算成本
        • 制定预算
        • 规划质量管理
        • 规划资源管理
        • 估算活动资源
        • 识别风险
        • 实施定量风险分析
        • 规划采购管理
      • 进度基准（Schedule Baseline）
        • 实施整体变更控制
        • 控制进度
        • 识别风险
        • 实施定量风险分析
        • 控制采购
      • 成本基准（Cost Baseline）
        • 实施整体变更控制
        • 控制成本
        • 获取资源
        • 识别风险
        • 实施定量风险分析
        • 规划风险应对
        • 实施采购
      • 绩效测量基准（Performance Measurement Baseline）
        • 控制范围
        • 控制进度
        • 控制成本
      • 任何组件
        • 指导与管理项目工作
        • 管理项目知识
        • 监控项目工作
      • 所有组件
        • 结束项目或阶段
        • 规划风险管理
    • 项目文件
      • 假设日志（Assumption Log）
        • 监控项目工作
        • 结束项目或阶段
        • 收集需求
        • 定义范围
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 规划质量管理
        • 估算活动资源
        • 识别风险
        • 实施定性风险分析
        • 实施定量风险分析
        • 控制采购
        • 规划相关方参与
      • 持续时间估算
        • 制定进度计划
        • 识别风险
        • 实施定量风险分析
      • 估算依据（Basis of Estimates）
        • 监控项目工作
        • 实施整体变更控制
        • 结束项目或阶段
        • 制定进度计划
        • 制定预算
        • 实施定量风险分析
      • 成本预测
        • 监控项目工作
        • 实施定量风险分析
      • 成本估算
        • 制定预算
        • 估算活动资源
        • 识别风险
        • 实施定量风险分析
      • 问题日志（Issue Log）
        • 监控项目工作
        • 结束项目或阶段
        • 管理团队
        • 控制资源
        • 管理沟通
        • 监督沟通
        • 识别风险
        • 监督风险
        • 识别相关方
        • 规划相关方参与
        • 管理相关方参与
        • 监督相关方参与
      • 质量报告（Quality Report）
        • 监控项目工作
        • 结束项目或阶段
        • 确认范围
        • 管理沟通
        • 控制采购
      • 质量控制测量结果（Quality Control Measurements）
        • 结束项目或阶段
        • 管理质量
      • 质量测量指标（Quality Metrics）
        • 管理质量
        • 控制质量
      • 测试与评估文件（Test and Evaluation Documents）
        • 控制质量
      • 变更日志（Change Log）
        • 指导与管理项目工作
        • 结束项目或阶段
        • 管理沟通
        • 识别相关方
        • 规划相关方参与
        • 管理相关方参与
      • 经验教训登记册（Lessons Learned Register）
        • 指导与管理项目工作
        • 管理项目知识
        • 监控项目工作
        • 结束项目或阶段
        • 收集需求
        • 确认范围
        • 控制范围
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 估算成本
        • 控制成本
        • 管理质量
        • 控制质量
        • 建设团队
        • 管理团队
        • 控制资源
        • 管理沟通
        • 监督沟通
        • 识别风险
        • 规划风险应对
        • 实施风险应对
        • 监督风险
        • 实施采购
        • 控制采购
        • 管理相关方参与
        • 监督相关方参与
      • 项目团队派工单
        • 管理项目知识
        • 估算活动持续时间
        • 制定进度计划
        • 建设团队
        • 管理团队
        • 规划风险应对
        • 规划采购管理
      • 资源分解结构（Resource Breakdown Structure）
        • 管理项目知识
        • 估算活动持续时间
        • 控制资源
      • 物质资源分配单
        • 控制资源
      • 项目日历（Project Calendar）
        • 控制进度
      • 资源日历（Resource Calendar）
        • 估算活动持续时间
        • 制定进度计划
        • 控制进度
        • 估算活动资源
        • 获取资源
        • 建设团队
        • 规划风险应对
      • 资源需求（Resource Requirements）
        • 估算活动持续时间
        • 制定进度计划
        • 估算成本
        • 获取资源
        • 控制资源
        • 识别风险
        • 实施定量风险分析
        • 规划采购管理
      • 相关方登记册（Stakeholder Register）
        • 管理项目知识
        • 收集需求
        • 规划质量管理
        • 规划资源管理
        • 获取资源
        • 规划沟通管理
        • 管理沟通
        • 规划风险管理
        • 识别风险
        • 实施定性风险分析
        • 规划风险应对
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 规划相关方参与
        • 管理相关方参与
        • 监督相关方参与
      • 活动属性（Activity Attributes）
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 估算活动资源
      • 活动清单（Activity List）
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 估算活动资源
      • 里程碑清单（Milestone List）
        • 指导与管理项目工作
        • 监控项目工作
        • 结束项目或阶段
        • 排列活动顺序
        • 估算活动持续时间
        • 制定进度计划
        • 实施定量风险分析
        • 规划采购管理
        • 控制采购
      • 项目沟通记录
        • 指导与管理项目工作
        • 结束项目或阶段
        • 监督沟通
        • 监督相关方参与
      • 项目进度计划（Project Schedule）
        • 指导与管理项目工作
        • 控制进度
        • 估算成本
        • 制定预算
        • 规划资源管理
        • 获取资源
        • 建设团队
        • 控制资源
        • 规划风险应对
        • 实施采购
        • 规划相关方参与
      • 项目范围说明书（Project Scope Statement）
        • 创建 WBS
      • 需求跟踪矩阵（Requirements Traceability Matrix）
        • 指导与管理项目工作
        • 实施整体变更控制
        • 确认范围
        • 控制范围
        • 规划质量管理
        • 规划采购管理
        • 控制采购
      • 需求文件（Requirements Documentation）
        • 结束项目或阶段
        • 定义范围
        • 创建 WBS
        • 确认范围
        • 控制范围
        • 规划质量管理
        • 规划资源管理
        • 规划沟通管理
        • 识别风险
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 识别相关方
      • 风险登记册（Risk Register）
        • 指导与管理项目工作
        • 监控项目工作
        • 结束项目或阶段
        • 定义范围
        • 估算活动持续时间
        • 制定进度计划
        • 估算成本
        • 制定预算
        • 规划质量管理
        • 规划资源管理
        • 估算活动资源
        • 控制资源
        • 实施定性风险分析
        • 实施定量风险分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
        • 规划采购管理
        • 实施采购
        • 控制采购
        • 规划相关方参与
        • 监督相关方参与
      • 风险报告（Risk Report）
        • 指导与管理项目工作
        • 监控项目工作
        • 实施整体变更控制
        • 结束项目或阶段
        • 管理质量
        • 管理沟通
        • 实施定量风险分析
        • 规划风险应对
        • 实施风险应对
        • 监督风险
      • 团队章程（Team Charter）
        • 建设团队
        • 管理团队
      • 项目进度网络图（Project Schedule Network Diagram）
        • 制定进度计划
      • 进度数据（Schedule Data）
        • 控制进度
      • 进度预测（Schedule Forecasts）
        • 监控项目工作
        • 实施定量风险分析
    • 工作绩效数据（Work Performance Data）
      • 确认范围
      • 控制范围
      • 控制进度
      • 控制成本
      • 控制质量
      • 控制资源
      • 监督沟通
      • 监督风险
      • 控制采购
      • 监督相关方参与
    • 工作绩效信息（Work Performance Information）
      • 监控项目工作
    • 工作绩效报告（Work Performance Reports）
      • 实施整体变更控制
      • 管理团队
      • 管理沟通
      • 监督风险
    • 可交付成果（Deliverable）
      • 管理项目知识
      • 控制质量
    • 核实的可交付成果（Verified Deliverables）
      • 确认范围
    • 验收的可交付成果（Accepted Deliverables）
      • 结束项目或阶段
    • 变更请求（Change Request）
      • 实施整体变更控制
    • 批准的变更请求
      • 指导与管理项目工作
      • 控制质量
      • 控制采购
    • 项目资金需求（Project Funding Requirements）
      • 控制成本
    • 采购文档（Procurement Documentation）
      • 结束项目或阶段
      • 识别风险
      • 实施采购
      • 控制采购
    • 卖方建议书（Seller Proposals）
      • 实施采购
    • 团队绩效评价
      • 管理团队
    • 其他过程的输出
      • 制定项目管理计划
    • 事业环境因素（Enterprise Environmental Factors）
      • 制定项目章程
      • 制定项目管理计划
      • 指导与管理项目工作
      • 管理项目知识
      • 监控项目工作
      • 实施整体变更控制
      • 规划范围管理
      • 收集需求
      • 定义范围
      • 创建 WBS
      • 规划进度管理
      • 定义活动
      • 排列活动顺序
      • 估算活动持续时间
      • 制定进度计划
      • 规划成本管理
      • 估算成本
      • 制定预算
      • 规划质量管理
      • 控制质量
      • 规划资源管理
      • 估算活动资源
      • 获取资源
      • 建设团队
      • 管理团队
      • 规划沟通管理
      • 管理沟通
      • 监督沟通
      • 规划风险管理
      • 实施定性风险分析
      • 实施定量风险分析
      • 规划风险应对
      • 规划采购管理
      • 实施采购
      • 控制采购
      • 识别相关方
      • 规划相关方参与
      • 监督相关方参与
      • 管理相关方参与
    • 组织过程资产（Organizational Process Assets）
      • 制定项目章程
      • 制定项目管理计划
      • 指导与管理项目工作
      • 管理项目知识
      • 监控项目工作
      • 实施整体变更控制
      • 结束项目或阶段
      • 规划范围管理
      • 收集需求
      • 定义范围
      • 创建 WBS
      • 控制范围
      • 规划进度管理
      • 定义活动
      • 排列活动顺序
      • 估算活动持续时间
      • 制定进度计划
      • 控制进度
      • 规划成本管理
      • 估算成本
      • 制定预算
      • 控制成本
      • 规划质量管理
      • 管理质量
      • 控制质量
      • 规划资源管理
      • 估算活动资源
      • 获取资源
      • 建设团队
      • 管理团队
      • 控制资源
      • 规划沟通管理
      • 管理沟通
      • 监督沟通
      • 规划风险管理
      • 识别风险
      • 实施定性风险分析
      • 实施定量风险分析
      • 规划风险应对
      • 实施风险应对
      • 规划采购管理
      • 实施采购
      • 控制采购
      • 识别相关方
      • 规划相关方参与
      • 管理相关方参与
      • 监督相关方参与
• 各章知识要点
  • 启动
    • 项目管理的难点
      • 需求多变，范围划算：唯一的不变就是“一直会变”
      • 估算不准，工期紧张：需要多久全靠猜
      • 成本有限，预算紧张：预算总是不足，成本一直超支
      • 难搞的各方
      • 质量太差，返工频繁：不是在处理问题，就是在处理问题的路上
      • 压抑的团队：冲突频发，士气低落
    • 相互影响的制约因素
      • 范围
      • 成本
      • 进度
      • 质量
      • 资源
      • 风险
    • 项目经理的困境
      • 权力不大，责任大
      • 地位不高，要求高：“难处”、“亮点”
      • 收入不多，付出多
      • 事情要干，人难管
  • 第一章 引论
    • pmbok指南
      • 是“指南”而非“具体的方法论”
      • 只针对“单个项目”，不针对项目集、项目组合
      • “普遍认可”/“良好实践”/“裁剪”（确认过程、输入、工具、技术、输出和生命周期阶段的恰当组合）
      • 项目管理业界定义的最重要的价值观：责任、尊重、公正、诚实
    • 项目
      • 项目：为创造独特的产品、服务或成果而进行的临时性工作
      • 项目的特点：独特性+临时性+驱动变革+创造商业价值+渐进明细
        • 独特性
          • 项目所创造的产品或服务在一定的程度或在某些方面与其他产品和服务相比较，有明显的差别（独特性带来的不确定性）
          • 开展项目是为了通过可交付成果达成目标
          • 可交付成果：在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力（可能有形，可能无形）。某些项目可交付成果和活动中可能存在重复的元素，但这种重复并不会改变项目本质上的独特。
        • 临时性
          • 项目有明确的起点和终点
          • 临时性并不一定意味着持续时间短
          • 虽然项目是临时性工作，但其可交付成果可能会在项目的终止后依然存在（项目临时，结果持久）
        • 驱动变革
          • 项目驱动组织进行变革。从商业角度来看，项目旨在推动组织从一个状态（当前状态）转到另一个状态（将来状态），从而达成特定目标
        • 创造商业价值
          • 目的“商业价值”：项目的成果能够为相关方带来的效益，效益可以是有形的、无形的或两者兼有之
          • 有形效益：货币资产、股东权益、固定设施、工具、市场份额等
          • 无形效益：商誉、品牌认知度、公共利益、战略一致性等
        • 渐进明细
          • 随着信息越来越详细和估算越来越准确，而持续改进和细化
          • 【区别】渐进明细和范围蔓延
          • 成果性目标（项目目标），指通过项目开发出的满足客户要求的产品、服务或成果
      • 项目终止的6种情况
        • 达成项目目标（做完了）
        • 不会或不能达到目标（做不完）
        • 项目资金缺乏或没有可分配资金（没钱做了）
        • 项目需求不复存在（客户要求终止、组织管理层要求终止、战略或优先级变更致使终止）（不用做了）
        • 无法获得所需人力或物力资源（没资源做了）
        • 法律或便利原因终止（不让做了）
      • 项目管理
        • 【项目管理】将知识、技能、工具与技术应用于项目活动，以满足项目的要求
        • 项目是组织创造价值和效益的主要方式
        • 为了在全球经济中保持竞争力，公司日益广泛利用项目管理，来持续创造商业价值
        • 有效和高效的项目管理应被视为组织的战略能力
        • 有效的项目管理可以帮助：管理制约因素+平衡制约因素对项目的影响
          • 管理制约因素（例如范围、质量、进度、成本、资源）
          • 平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）
      • 项目管理的关键要素：项目生命周期（开始项目-->组织与准备-->执行项目工作-->结束项目）+项目阶段+阶段关口+项目管理过程（5个）+项目管理知识领域（10个）
        • 项目生命周期：开始项目-->组织与准备-->执行项目工作-->结束项目
          • 项目从启动到完成所经历的一系列阶段。这些阶段之间的关系可以顺序、迭代或交叠进行。
          • 项目生命周期可以是：预测型、适应型。 
          • 项目通用生命周期：开始项目-->组织与准备-->执行项目工作-->结束项目（所有项目都呈现该通用的生命周期）
            • 成本与人力投入：项目开始时“缓慢增加”，在“执行工作”期间达到最高，项目快结束时“迅速回落”
            • 风险与不确定性、相关方的影响力、变更的数量：项目开始时最大，后续“逐步降低”
            • 变更的代价、风险的影响：项目开始时较小，后续“显著增高”
          • 开发生命周期（预测型、迭代型、增量型、适应型、混合型）
            • 开发生命周期：项目生命周期内与（产品、服务或成果的）开发相关的一个或多个阶段。
            • 开发生命周期可以是：预测型、迭代型、增量型、适应型、混合型。
              • 预测型
                • 
                • 
                • 预测型生命周期（瀑布型、计划驱动）
                • 范围、进度、成本在早期阶段就确定。
                • 按计划执行、一次交付。
                • 充分了解产品；有厚实的行业基础；
              • 迭代型
                • 
                • 迭代型生命周期，项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品。
                • 总结：从“模糊”到“清晰”
              • 增量型
                • 
                • 增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列增量来产出可交付成果。只有在最后一次增量之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
                • 总结：从“部分”到“整体”
              • 适应型
                • 
                • 
                • 敏捷型生命周期（适应型、变更驱动）----详细范围在迭代开始之前就得到了定义和批准。
                • 适应型生命周期属于敏捷型、迭代型或增量型适应型生命周期也称为敏捷或变更驱动型生命周期在考试中，适应型往往特指敏捷
                • 敏捷的特点：较小的增量：每次均交付“最有价值”的功能
                • 快速的迭代：一般2~4周一个迭代
                • 频繁交付，相关方频繁参与
                • 适用于创新项目，需应对快速变化的环境；需求和范围难以事先确定；
                • 关于用户故事、故事点、迭代燃尽图以及敏捷的几个重要的会议等等，将在课程结束后安排时间详细讲解。
            • 
          • 产品生命周期（投入期、成长期、成熟期和衰退期）
            • 产品生命周期----一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。
            • 典型的产品生命周期一般可分为四个阶段：投入期、成长期、成熟期和衰退期
        • 项目阶段
          • 项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果 的完成为结束
          • 项目阶段的其中一个关键组成部分 是 阶段审查
          • 阶段的属性是可测量 且 独特的 ，属性包括： 阶段名称、阶段的数量、持续时间、资源需求、阶段的准入标准、阶段的退出标准
          • 如何划分项目阶段：项目特征+管理便利+决策点+部门矩阵型组织+组织/行业最佳实践
            • 根据项目的自然特征
            • 根据管理的便利
            • 根据决策点（例如资金决策、继续/终止项目、里程碑审查）
            • 部门矩阵型组织
            • 根据组织、行业的最佳实践
        • 阶段关口（阶段审查：审查+决策）
        • 也可被称为阶段审查、阶段门、关键决策点、阶段入口、阶段出口
          • 审查：把项目绩效与项目进展与下列文件进行比较
            • 项目商业论证
            • 项目章程
            • 项目管理计划
            • 效益管理计划
            • ……
          • 决策：根据审查结果，制定如下决策
            • 进入下个阶段
            • 整改后进入下个阶段
            • 结束项目
            • 停留在当前阶段
            • 重复阶段或某个要素
        • 项目管理过程（5大过程组）：
        • 启动+规划+执行+监控+收尾
          • 项目管理过程是为
        • 完成预定的产品、成果或服务而执行的一系列相互关联的行动和活动
          • 每个过程都有各自的
        • 输入、工具 和 技术 以及相应 输出
          • ITTO
            • 项目管理过程可分为5个项目管理过程组：
        • 启动、规划、执行、监控、收尾（五大过程组）
        • 项目管理知识领域（10大知识领域）
          • 项目知识领域是按所需知识内容来定义的项目管理领域
          • 可分为十大知识领域
            • 项目
        • 整合 管理
          • 项目
        • 范围 管理
          • 项目
        • 进度 管理
          • 项目
        • 成本 管理
          • 项目
        • 质量 管理
          • 项目
        • 资源 管理
          • 项目
        • 沟通 管理
          • 项目
        • 风险 管理
          • 项目
        • 采购 管理
          • 项目
        • 相关方 管理
        • 【总结】5大项目管理过程与10大知识领域
      • 工作绩效数据、工作绩效信息、工作绩效报告
      • 项目管理商业文件：项目商业认证+项目效益管理计划
        • 项目商业论证
          • 项目商业论证：指文档化的
      • 经济可行性研究报告 ，用来对尚缺乏充分定义的所选方案的收益进行有效性论证，是启动后续项目管理活动的依据
        • 商业论证列出了
      • 项目启动的目标和理由 。它有助于在项目结束时根据项目目标衡量项目是否成功
        • 商业论证可能包括记录以下内容
          • 业务需要
          • 形式分析
          • 推荐
          • 评估
        • 项目效益管理计划
          • 项目效益管理计划：描述了项目实现效益的方式和时间，以及应制定的效益衡量机制
          • 项目效益，为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果
          • 项目效益管理计划（必须明确项目拟实现的商业价值）可能包括记录以下内容
            • 目标效益
            • 战略一致性
            • 实现效益的时间
            • 效益责任人
            • 测量指标
            • 假设
            • 风险
      • 项目成功标准
        • 确定项目是否成功，除了应达到时间、成本、范围和质量等项目管理测量指标外，还应考虑项目目标的实现情况，这些项目目标可能包括：
          • 完成项目效益管理计划
          • 达到商业论证中记录的财务指标（NPV、ROI、IRR、PBP、BCR等）
          • 完成组织从“当前状态”转到“将来状态
          • 履行合同条款和条件
          • 使相关方满意
          • 达到组织战略、目的和目标
          • ………
      • 项目集和项目组合
        • 项目集：是一组
      • 相互关联且被协调管理的项目、子项目集和项目集 活动，以便获得分别管理所无法获得的利益（1+1>2的效果）
        • 项目组合：是指为了
      • 实现战略目标 而组合在一起管理的项目、项目集、子项目组合和运营工作，它们不一定彼此依赖或者相关
        • 例子
      • 什么是运营
        • 是一种生产重复性结果的持续性工作
        • 项目往往来自运营，又服务于运营
        • 项目与运营会在产品生命周期的不同时点交叉。在每个交叉点，可交付成果及知识在项目与运营之间转移，以完成工作交接
      • 【区别】项目与运营
      • 什么是
      • 组织级项目管理OPM
        • OPM是为实现
      • 战略目标 而整合项目组合、项目集和项目管理与组织驱动因素的 框架
        • OPM旨在确保组织开展正确的项目并合适地分配关键资源
    • 重点
      • 项目的特点：
      • 独特性、临时性、渐进明细、促进组织变更、商业价值
      • “项目组合” 和“项目集”的区别
      • 项目生命周期、阶段、开发生命周期的含义
      • 预测型、迭代型、增量型、适应型（敏捷）的特点
      • 【区别】“
      • 生命周期的阶段 ”（开始项目+组织与准备+执行项目工作+结束项目）和“ 管理过程 ”（启动+规划+执行+监控+收尾）
      • 工作绩效数据、工作绩效信息、工作绩效报告的区别和联系
      • 商业论证的作用
      • 项目的成功标准很多，具体以哪些标准来衡量要与相关方达成共识
  • 第二章 项目运行环境
    • 项目影响力：事业环境因素+内部组织过程资产
    • 事业环境因素EEF：
    • 内部+外部 不可控，需遵守
      • 事业环境因素（EEFs）：项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响
      • 内部
        • 组织文化、结构和治理
        • 设施和资源的地理分布
        • 基础设施
        • 信息技术软件
        • 资源可用性
        • 员工能力
      • 外部
        • 市场条件
        • 社会和文化影响与问题
        • 法律限制
        • 商业数据库学术研究
        • 政府或行业标准
        • 财务考虑因素
        • 物理环境要素
    • 组织过程资产OPA：
    • 过程、政策和程序+组织知识库 可裁剪，多积累
      • 组织过程资产：执行组织特有并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管理。在整个项目期间，项目团队成员可对组织过程资产进行必要的更新和增补。它包括：
        • 工件、实践或知识
        • 经验教训和历史信息
        • 完成的进度计划、风险数据和挣值数据
      • 第一类资产：过程、政策和程序
        • 包括：指南和标准、模板、供应商清单和合同协议类型、变更控制程序、组织对沟通的要求。
        • 第一类资产的更新通常不是项目工作的一部分，而是由项目管理办公室 (PMO) 或项目以外的其他职能部门完成。更新工作仅须遵循与过程、政策和程序更新相关的组织政策。有些组织鼓励团队裁剪项目的模板、生命周期和核对单。在这种情况下，项目管理团队应根据项目需求裁剪这些资产。
      • 第二类资产：组织知识库
        • 包括：配置管理知识库、财务数据库、测量指标数据库、经验教训知识库，以往项目的档案
        • 第二类资产是在整个项目期间结合项目信息而更新的。例如，整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息
    • 组织结构（职能型+项目型+弱矩阵型+平衡矩阵型+强矩阵型+其他）
    • 蓝色底为项目参与成员
      • 职能型+项目型+弱矩阵型+平衡矩阵型+强矩阵型
        • 职能型（集中式）
          • 特点
            • 兼职项目经理（联络员）
            • 权力大小：“很小”或“没有”
            • 职业路径清晰、横向联系薄弱
        • 项目型
          • 特点
            • 全职项目经理
            • 权力大小：“大”甚至“全部”
            • 项目经理控制度高
            • 重复配置，无家可归
        • 弱矩阵型
          • 特点
            • 兼职项目经理
            • 权力大小：“小”
            • 资源利用率高；有利于跨部门协调；
            • 多头领导；管理难度大；资源争夺；
        • 平衡矩阵型
          • 特点
            • 兼职项目经理
            • 权力大小：“小”到“中”
            • 资源利用率高；有利于跨部门协调；
            • 多头领导；管理难度大；资源争夺；
        • 强矩阵型
          • 特点：
            • 全职项目经理
            • 权力大小：“中”到“大”
            • 资源利用率高；有利于跨部门协调；
            • 多头领导；管理难度大；资源争夺；
        • 【补充】常见组织结构项目经理与职能经理权力对比
      • 其他一些类型组织结构：有机型（简单型）+多部门组织+虚拟型组织
        • 有机型或简单型组织（Organic or simple organization）是英国理论家Tom Burns和George Stalker最初描述的一种非正式组织。有机组织是一个非常灵活的组织，能够很好地适应变化。它的结构是：工作专业化少，管理层次少，决策分散，监督不多。
        • 多部门组织（ Multi-divisional ）一个中心，多个部门或分区，这些分区实行半自治，中心对其下达财务指标。比如按照区域划分部门，每个部门有重复的职能，不集中。
        • 虚拟型组织（网络型组织），临时把人员召集起来，以利用特定的机遇，待目标完成后即行解散的一种临时组织。
      • 【总结】组织结构对项目的影响
    • 项目管理办公室（PMO）
      • 项目管理办公室（PMO），是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织结构。
    • PMO所支持和管理的项目不一定彼此关联
      • PMO的类型：支控指
        • 支持型：支持，是顾问、项目资源库，对项目控制程度很
    • 低
      • 控制型：支持+要求服从，对项目控制程度
    • 中 等
      • 指令型：直接管理和控制，对项目控制程度很
    • 高
      • PMO对项目经理支持的方式：
    • 管理+监督+指导培训+协调
      • 管理“共享资源”，识别和制定“最佳实践”和“标准”（管理功能）
      • 通过“项目审计”，监督对“标准”的遵守程度（监督功能）
      • 制定和管理政策、程序、模板，提供指导和培训（指导培训功能）
      • 协调“跨项目”的沟通（协调功能）
    • 【重点】
      • 事业环境因素和组织过程资产的区别和典型的例子
      • 各个组织结构中项目经理的权力大小，考试中默认用
    • 矩阵型 以协调跨部门项目
  • 第三章 项目经理的角色
    • 项目经理
      • 项目经理：
    • 由执行组织委派，领导团队实现项目目标的个人
      • 项目经理：专注项目目标的达成
      • 职能经理：专注某个职能领域或业务单元的管理和监督
      • 运营经理：专注业务运营的高效性
      • 项目经理无需承担项目中的每个角色，但应具备
    • 项目管理知识、技术知识、理解能力 和 相关经验
      • 项目经理通过沟通向项目团队提供领导、规划和协调的职能。项目经理的沟通分实时沟通（会议、口头沟通等）和非实时沟通（书面沟通、文档计划等）
    • 项目经理的影响力范围：
    • 项目+组织+行业+专业学科+跨领域
      • 项目
        • 领导项目团队实现项目目标和相关方的期望
        • 利用可用资源，以平衡相互竞争的制约因素
        • 充当项目发起人、团队成员与其他相关方之间的沟通者，包括提供指导和展示项目成功的愿景
      • 组织
        • 积极地与其他项目经理互动
        • 扮演强有力的倡导者角色，与项目发起人合作处理内部的政治和战略问题
        • 提高自己在组织内的总体项目管理能力和技能
      • 行业
        • 时刻关注行业的最新发展趋势
        • 思考这一信息对当前项目是否有影响或可用
      • 专业学科：持续的知识传递和整合
      • 跨领域
        • 指导和教育其他专业人员项目管理方法
        • 担任非正式的宣传大使
    • 项目经理的能力：PMI人才三角，
    • 技术项目管理+战略和商务管理+领导力
      • 技术项目管理：有效运用项目管理知识实现项目集或项目的预期成果的能力
        • 重点关注所管理的各个项目的关键技术项目管理要素，包括
          • 项目成功的关键因素
          • 进度
          • 指定的财务报告
          • 问题日志
        • 针对每个项目裁剪传统和敏捷工具、技术和方法
        • 花时间制定完整的计划并谨慎排定优先顺序
        • 管理项目要素，包括但不限于进度、成本、资源和风险
      • 战略和商务管理：纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力
        • 向其他人解释关于项目的必要商业信息
        • 与项目发起人、团队和主题专家合作制定合适的项目交付策略
        • 以实现项目商业价值最大化的方式执行策略
      • 领导力：指导、激励和带领团队的能力（协商、抗压、沟通、解决问题、批判性思考、人际关系技能）
        • 领导力技能
          • 领导者的品质和技能
            • 能运用批判性思维
            • 关注重要事情
            • 终身学习结果导向
            • 正确沟通
            • 管理关系和冲突
            • 积极乐观
            • 有远见
          • 了解项目经理的几种权力：专家权力+参照权力+奖励权力+正式权力+惩罚权力
            • 奖励权力：来自于项目经理职位通过给予他人有价值的物质奖励的能力
            • 正式权力：来自于项目经理职位和职务所拥有的权利
            • 惩罚权力：来自于项目经理职位通过使用或威胁使用惩罚手段来影响他人的能力（慎用）
            • 专家权力：来自于项目经理个人具有的某些技能或技术专长
            • 参照权力：来自于项目经理个人吸引他人并建立起他人对自己的忠诚度的能力
          • 了解项目经理的几种领导力风格：放任+交易+服务+变革+魅力+交互
            • 放任型：“无为而治”，允许团队自主决策和设定目标，有利于创新，但易失控
            • 交易型：关注目标、反馈和成就以确定奖励，例外管理
            • 服务型：服务优先于领导，处处先为他人着想；关注他人的成长、学习、发展、人际关系、团队与合作
            • 变革型：通过理想化特质和行为、鼓舞性激励、促进创新和创造，以及个人关怀提高追随者能力
            • 魅力型：精神饱满、热情洋溢、充满自信、说服力强、能够激励他人
            • 交互型：结合 了交易型、变革型和魅力型的特点
    • 执行整合
      • 整合中项目 经理承担的双重角色
        • 与发起人合作，了解战略目标 并确保项目目标和成果与项目组合、项目集以及业务领域保持一致
        • 负责指导团队关注真正重要的事务并协同工作
      • 发生整合的3个层面：
    • 过程层面+认知层面+背景层面
      • 复杂性的3个维度：
    • 系统行为+人类行为+不明确性
    • 【重点】
      • PMO的三种类型
    • ：支持型、控制型、指令型
      • 项目经理的定义
    • ：由执行组织委派，领导团队实现项目目标的个人
      • PMI人才三角
    • 技术项目管理技能 + 战略和商务管理技能 + 领导力技能
      • 项目经理的几种权力和几种领导力风格
  • 第四章 项目整合管理
    • 项目中常见的几方
    • 十大知识领域学习的重点
      • What：每个子过程的定义
      • Why：每个子过程的作用
      • How：每个子过程的ITTO
        • 输入（Input）：依据是什么、参考什么、应该审查什么
        • 工具和技术（Tool & Technology） ：用什么方法、用什么技术
        • 输出（Output）：下一步制定什么、是为了做什么、记录在什么文件中
    • 核心概念P72
      • 在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终
      • 项目整合管理由
    • 项目经理 负责，并且整合管理的责任不能被授权或者转移
      • 项目经理必须对整个项目承担最终责任
      • 项目越复杂，相关方的期望越多样化，就需要越全面的整合方法
    • 发展趋势和新兴实践P73
      • 项目整合管理知识领域要求整合所有其他知识领域的成果
      • 与整合管理过程相关的发展趋势
        • 使用自动化工具（如PMIS）
        • 使用可视化管理工具（便于看到实时状态，促进知识转移，促进相关方参与到问题解决中）
        • 项目知识管理（应对项目人员的流动性和不稳定性）
        • 增加项目经理的职责（项目经理被要求介入启动和结束项目，例如开展商业论证和效益管理
    • 项目整合管理过程：
    • 启动过程组 制定项目章程 + 规划过程组 制定项目管理计划 + 执行过程组（ 指导与管理项目工作 + 管理项目知识 + 监控过程组 监控项目工作 + 实施整体变更控制 + 收尾过程组 结束项目或阶段
      • 启动过程组
    • 制定项目章程
      • 之一“
        • “制定项目章程”的注意点 P77
          • 项目章程在
    • 制定项目章程 ”P75
      • What：制定项目章程，
    • 编写一份 正式批准项目 并 授权项目经理 在项目活动中使用组织资源的文件的过程
      • Why：本过程的作用，
    • 明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺
      • How：制定项目章程
        • 工具与技术：
          • 数据收集P80（头脑风暴+焦点小组+访谈）
            • 头脑风暴：短时间内获得大量创意，是典型的信息收集技术，原则是：不质疑、不分析、不批判、不反对,不包含分析过程
            • 焦点小组（focus group）：召集相关方和主题专家（sme）讨论相关议题，比一对一访谈更有利于互动交流（同职能）
            • 访谈：通过与相关方直接交谈来了解相关信息
          • 人际关系与团队技能P80（冲突管理、引导、会议管理）
            • 冲突管理：
          • 会议P80
            • 在本过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息
        • 输出：
    • （ITTO）， 输入 商业文件 + 协议 ）+ 工具与技术 专家判断 + 数据收集 + 人际关系与团队技能 + 会议 ）+ 输出 项目章程 + 假设日志
      • 输入：
    • 商业文件（商业论证+效益管理计划）+协议
      • 商业文件P77
        • 包含关于项目目标以及项目对业务目标的贡献等相关信息的文件。它包括：
    • 商业论证、效益管理计划
      • 商业文件是在
    • 项目之前制定 的，需要 定期审核
      • 商业文件
    • 不是项目文件 项目经理 不可以对它们进行 更新或修改 ，只可以提出相关建议
      • 协议P78
        • 协议：定义了启动项目的初衷
        • 协议的形式：合同（为外部客户做项目时）、谅解备忘录（MOUs）、服务品质协议（SLA）、意向书等
    • 专家判断+数据收集（头脑风暴+焦点小组+访谈）+人际关系与团队技能（冲突管理+引导+访会议管理）+会议
      • 专家判断P79
        • 基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人（人人都是“砖家”）
    • 有助于相关方 就目标、成功标准、高层级需求、项目描述、总体里程碑等内容 达成一致意见
      • 引导：有效
    • 引导 团队活动成功以 达成 决定、解决方案或结论的能力
      • 会议管理
        • 不要把各种会议类型混合在一起
        • 面对面的会议效果最好，有时也需要举行虚拟会议
        • 应明确每个参会者的角色，确保有效参会
        • 会议要
    • 达成共识，要有行动计划
      • 会前、中、后的注意点
        • 会前：要确定会议议程、目的、目标和期限
        • 会中：不要跑题
        • 会后：要形成书面的会议纪要和行动方案
    • 项目章程+假设日志
      • 项目章程P81
        • 由
    • 项目启动者 或 发起人发布 的，正式 批准项目成立 ，并授权 项目经理 动用 组织资源 开展项目活动的文件。（是项目的“宪法”，是项目经理的“尚方宝剑”）， 包含的内容
      • 委派的项目经理及其权责
      • 项目的目的、目标、
    • 项目的成功标准
      • 高层级
    • 的需求、 高层级 的项目描述、 高层级 的战略和 运营假设条件和制约因素
      • 总体
    • 里程碑进度计划、 总体 预算、 整体 项目风险
      • 项目审批要求、关键相关方名单、项目退出标准、
    • 主要可交付成果
      • 假设日志P81：假设条件+制约因素
        • 假设日志，用于记录
    • 整个项目生命周期 中的 所有 假设条件和制约因素
      • 假设条件：
    • 不需验证 即可 视为正确 、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响
      • 制约因素：对
    • 项目或过程 的执行有影响的 限制性因素
      • 【讨论】项目章程让“项目”和“项目经理”名正言顺，发布项目章程时需要的内容：
        • 项目的目的
        • 项目的目标和成功标准
        • 项目的退出标准
        • 概括的（高层级的）范围、进度、成本、风险
        • 项目经理的责任和职权
        • 发起人的姓名和职权
    • 项目执行组织 与 需求组织 之间建立起伙伴关系
      • 经批准的项目章程意味着
    • 项目的正式启动
      • 项目由项目以外的实体来启动，如发起人、项目集或项目管理办公室等等
      • 尽早确认并任命项目经理
    • ，项目经理 应该参与项目章程的制定 ，以便对项目需求有基本的了解
      • 最好
    • 在 制定项目章程时就任命 最晚 也必须在规 划开始之前
      • 通过编制项目章程，来
    • 确认项目符合组织战略 和 日常运营的需要
      • 在执行外部项目时，通常需要用正式的
    • 合同 来达成合作协议
      • 不要把项目章程看做合同
    • ，因为其中未承诺报酬或金钱或用于交换的对价
      • 规划过程组
    • 制定项目管理计划
      • 之二“
        • 项目管理计划应该：足够强大+基准化+渐进明细
          • 足够强大，可以应对不断变化的项目环境（敏捷性），这有利于项目进展产出更准确的信息
          • 基准化，确定基准前、确定基准后
            • 确定基准前：可进行多次更新，无需遵循正式流程
            • 确定基准后：
        • 【补充】“项目管理计划”和“项目文件”件 P89
          • “项目管理计划”，需要相关方的一致认可，需要经过变更流程的审批才能修改
          • “项目文件”，是团队自行维护的，更倾向于工作过程的记录
        • 【讨论】为什么要做计划，做什么方面的计划，计划最终需要不需要整合
          • 计划是依据，是参照，是基准（base line）
          • 范围、进度、成本、质量、资源、风险、采购等等5~13章各个领域都要计划
          • 计划需要整合
    • 制定项目管理计划 ”P82
      • What：制定项目管理计划，
    • 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程
      • Why：本过程的作用：
    • 生成一份综合文件，用于确定所有项目工作的基础及其执行方式
      • How：制定项目管理计划
        • 工具与技术
          • 人际关系与团队技能P86
            • 冲突管理、引导、会议管理
          • 会议（P86）重点kick-off meeting
        • 输出
          • 指南型计划（渔）：是一种指南，如何去管理XX。强调的是How
          • 实体型计划（鱼）：具体描述：范围包括哪些，工期多久，成本多少。描述的是What
    • （ITTO） 输入 项目章程 + 其他过程的输出 ）+ 工具与技术 数据收集 + 人际关系与团队技能 + kick-off meeting会议 ）+ 输出 项目管理计划
      • 输入
        • 其他过程的输出P83
          • 其他规划过程所输出的子计划和基准，都是本过程的输入。对这些子计划和基准的变更都可能导致对项目管理计划的相应更新
    • 项目章程 + 其他过程的输出
      • 项目章程P83
        • 项目团队把项目章程作为初始规划的起点
    • 数据收集 + 人际关系与团队技能 + kick-off meeting会议
      • 数据收集P85
        • 头脑风暴、核对单、焦点小组、访谈
        • 核对单：包括需要考虑的项目、行动或要点的清单，常被用作提醒
    • 项目管理计划（指南型+实体型） （P89）
      • 项目管理计划的组成部分（指南型、实体型）
        • 项目管理计划，是说明项目执行、监控和收尾方式的一份文件。它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息
    • 只能通过实施整体变更控制过程 进行更新
      • 渐进明细：在项目收尾之前，该计划需要通过
    • 不断更新 来渐进明细，并且这些更新需要得到控制和批准
      • 项目管理计划可以是概括的或详细的，详细程度取决于具体项目的要求
      • 【讨论】为什么项目管理计划需要主要相关方的批准
        • 让主要相关方对项目管理计划有一致的理解
        • 获得主要相关方的支持和承诺，并作为项目工作的基准和依据
        • 不能随意修改或私下修改
        • 如果需要修改，一定要走合理的变更流程，并告知相关方
      • 执行过程组
        • 之四“
          • 知识管理注意点
            • 组织角度看：在项目开始之前、开展期间和结束之后都能使用旧知识、生成新知识
            • 最重要的环节：营造信任氛围，激励人们分享自己的知识和关注他人的知识
            • 实践中双管齐下
              • 知识管理工具和技术（用于人际互动）
              • 信息管理工具和技术（用于编撰显性知识）
          • How：
            • 输出：
              • 经验教训登记册在不同项目节点的状态
                • 项目早期：创建
                • 项目期间：不断更新
                • 项目结束：归入经验教训知识库
    • 指导与管理项目工作 + 管理项目知识
      • 之三“
        • 该过程会实施以下活动
          • 实施已计划好的项目活动
          • 管理项目内的各种技术接口和组织接口
          • 回顾所有项目变更的影响，并实施已批准的变更
          • 收集工作绩效数据并传达给合适的控制过程
    • 指导与管理项目工作 ”P90
      • What：
    • 指导与管理项目工作，为实现项目目标而领导和执行项目管理计划中确定的工作，并实施已批准变更的过程
      • Why：
        • 工具与技术：
          • 会议（P95）
            • 会议类型：开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议、回顾会议
            • 参会者： 项目经理、项目团队成员，以及与所讨论事项相关或会受该事项影响的相关方
        • 输出：
          • 工作绩效数据P95
            • 在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。在工作执行过程中收集数据，再交由控制过程做进一步分析
          • 问题日志P96
            • 一种记录和跟进所有问题的项目文件。在此过程被首次创建，在整个项目生命周期应该随同监控活动更新
            • 包含的主要内容：问题描述、责任人、解决期限
          • 变更请求P96（
    • 本过程的作用，对项目工作和可交付成果开展综合管理，以提高项目成功的可能性 How：指导与管理项目工作 （ITTO）， 输入 （项目管理计划 + 批准的变更请求）+ 工具与技术 项目管理信息系统PMIS + 会议 ）+ 输出 可交付成果 + 工作绩效数据 + 问题日志 + 变更请求
      • 输入：
    • 项目管理计划 + 批准的变更请求
      • 项目管理计划P92，项目管理计划的任何组件都可用作本过程的输入
      • 批准的变更请求P93，实施整体变更控制过程的输出，可能是纠正措施、预防措施或缺陷补救
    • 专家判断 + 项目管理信息系统PMIS + 会议
      • 项目管理信息系统PMIS，P95
        • 项目管理信息系统PMIS，为指导和管理项目工作提供自动化工具，并用于自动收集和报告关键绩效指标（KPI）
        • 工作授权系统，用来保证项目工作由正确的组织、在正确的时间以正确的顺序执行。可以防止“镀金”
    • 可交付成果 + 工作绩效数据 + 问题日志 + 变更请求
      • 可交付成果P95
        • 在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力，通常是项目结果，并可包括项目管理计划的组成部分
    • 纠正措施+预防措施+缺陷补救+更新
      • 是关于修改任何文档、可交付成果或基准的正式提议。可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的，可口头提，但必须书面记录。包括：
        • 纠正措施 — 纠偏差（事后）
    • ------>用来维护“某些” 基准
      • 预防措施 — 防风险（事前）
      • 缺陷补救 — 补质量（针对质量缺陷）
      • 更新 — 通常改计划
    • ------>会修改计划或基
      • 【补充】如何理解指导与管理项目工作的ITTO
    • 管理项目知识 ”P98
      • What：
    • 管理项目知识，使用现有知识并生成新知识，以实现项目目标，并帮助组织学习的过程
      • Why：
    • 本过程的作用，利用已有的组织知识来创造或改进项目成果，并使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展
      • 知识类型：显性知识+隐性知识
    • 管理项目知识（ITTO）， 输入 项目文件 ）+ 工具与技术 知识管理+信息管理+人际关系与团队技能 ）+ 输出 经验教训登记册
      • 输入：
    • 项目文件 （P101）
      • 经验教训登记册：提供了
    • 有效的知识管理实践。
      • 项目团队派工单：说明了项目
    • 已具有 的能力和经验以及 可能缺乏 的知识。
      • 资源分解结构：有助于了解
    • 团队拥有和缺乏 的知识。
      • 相关方登记册：有助于了解
    • 相关方可能拥有 的知识。
      • 工具与技术：
    • 知识管理+信息管理+人际关系与团队技能
      • 知识管理（P102）
        • 知识管理工具和技术
    • 将员工联系起来 ，使他们能够 合作 生成新知识、 分享 隐性知识，以及 集成 不同团队成员所拥有的知识
      • 面对面互动
    • 最有利于 建立 知识管理所需的 信任关系 。建立之后，可以用 虚拟互动 来维护这种 信任关系
      • 信息管理（P103）
        • 信息管理用于创建
    • 人们与知识之间的联系 ，可以有效促进简单、明确的 显性知识的分享
      • 通过增加互动要素
    • ，比如：增加 “与我联系”的功能，使用户能够与经验教训发帖者联系，并向其寻求与特定项目和情境有关的建议。从而可以 向隐性知识延伸
      • 人际关系与团队技能（P104）：积极倾听+引导技术+领导力+人际交往+政治意识
        • 积极倾听：有助于减少误解并促进沟通和知识分享
        • 引导技术：有助于有效指引团队成功地达成决定、解决方案或结论
        • 领导力：可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标
        • 人际交往：促使项目相关方之间建立非正式的联系和关系，为显性和隐性知识的分享创造条件
        • 政治意识：有助于项目经理根据项目环境和组织的政治环境规划沟通
    • 经验教训登记册 （P104）
      • 包含的内容
        • 情况的类别和描述
        • 与情况相关的影响、建议和行动方案
        • 遇到的挑战、问题、意识到的风险和机会或其他适用的内容
      • 监控过程组
        • 之六“
          • How
            • 工具与技术
          • 实施整体变更控制的注意点（P115）
            • 实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任
            • 应确保只有经批准的变更才能纳入修改后的基准中
            • 任何相关方都可以提出变更请求，可以口头提出，必须以
    • 监控项目工作 + 实施整体变更控制
      • 之五“
        • How
          • 工具与技术
            • 决策（P111）
              • 决策技术包括投票：一致同意、大多数同意、相对多数原则
          • 输出
    • 监控项目工作 ”P105
      • What
    • ：监控项目工作，跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程
      • Why
    • ：本过程的作用
      • 让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动
      • 通过成本和进度预测，让相关方了解未来项目状态
      • 监控项目工作贯穿于整个项目，是唯一输出工作绩效报告的过程
    • ：监控项目工作（ITTO）： 输入 （项目文件+工作绩效信息） + 工具与技术 （数据分析+决策） + 输出 （工作绩效报告）
      • 输入
        • 工作绩效信息（P109）
          • 将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息
          • 绩效包含：
    • 项目文件+工作绩效信息
      • 项目文件（P108）（
    • 进度预测+成本预测
      • 进度预测：基于项目以往的绩效，用于确定项目是否仍处于进度的公差区间内，并识别任何必要的变更
      • 成本预测：基于项目以往的绩效，用于确定项目是否仍处于预算的公差区间内，并识别任何必要的变更
    • 范围、进度、成本、质量 以及项目管理计划中定义的 其他
      • 工作绩效信息为决策提供依据
    • 数据分析+决策
      • 数据分析（P111）（挣值分析+偏差分析+趋势分析+根本原因分析+备选方案分析+成本效益分析）
        • 挣值分析：对范围、进度、成本绩效进行综合分析，发现偏差
        • 偏差分析：审查目标绩效与实际绩效之间的差异，可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标
        • 趋势分析：根据过去，预测将来。提前发现问题，提前纠偏或预防
        • 根本原因分析：寻找偏差或潜在问题的根本原因
        • 备选方案分析：选择纠正措施、预防措施
        • 成本效益分析：选择成本最低的方案来纠偏
    • 工作绩效报告 （P112）
      • 基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注
      • 根据项目沟通管理计划，通过沟通过程向项目相关方发送工作绩效报告（状态报告、进展报告）
    • 实施整体变更控制 ”P113
      • What
    • ：实施整体变更控制，审查所有变更请求、批准变更、管理变更、并对变更处理结果进行沟通的过程
      • Why
    • ：本过程的作用
      • 确保对项目中已记录在案的变更做综合评审，从而降低项目风险
      • 本过程只会审批、管理变更，不会提出变更请求（我们只处理变更，不生产变更）
    • ：实施整体变更控制（ITTO）： 输入 变更请求 ）+ 工具与技术 配置管理系统 ）+ 输出 批准的变更请求 + 项目文件更新 + 项目管理计划更新
      • 输入
    • ：变更请求（P117）
      • 向变更请求的提出者了解变更的具体内容或变更的原因，告知变更的流程，防止不必要的变更。若确认必须变更则走以下5步流程：
    • 1记录、2评估、3提交、4更新、 5通知（重中之重）
      • 1、记录
    • ：书面记录变更请求。 项目经理书面记录（变更日志） 或要求变更提出者提交书面的变更请求
      • 2、评估
    • ：充分了解变更， 评估变更带来的影响 。与相关的相关方沟通评估出的影响
      • 3、提交
    • ：提交责任人审批。 注意，这里的提交是指 “项目经理” 将 变更请求 和 评估的结果 提交给CCB
      • 4、更新：
    • 不管变更通过还是不通过， 必须更新变更日志 。如果变更通过，更新项目管理计划（文件）
      • 5、通知：
    • 应将变更的 结果通知 相关（受影响）的相关方
      • 【变更题的常见考法】
        • 1. 变更的顺序
          • 看看现在进行到了哪一步
          • 根据顺序（1记录、2评估、3提交、4更新、5通知）来选择下一步做什么
        • 2. 考要不要变更
          • 但涉及到基准的修改的时候，需要走变更
        • 注意常见的一些说法各自代表的意思
          • 要求客户提交一份变更请求、分析变更对进度和成本带来的影响
          • 处理变更请求、实施整体变更控制过程、创建一份变更请求
          • 遇到纠结的说法，可以参考英文
    • 配置管理系统
      • 变更控制工具（P118）：配置管理系统
        • 配置管理系统：
    • 项目管理系统的子系统 ，由一系列 正式的书面程序 组成，为以下 配置管理活动 提供技术和管理方面的指导与监督：
      • 一识：配置识别。识别与选择配置项---->
    • 规划
      • 二记：配置状态记录。关于各个配置项的信息记录和报告---->
    • 执行
      • 三审：配置核实与审计。通过核实与审计保证配置项组成的正确性，及变更被正确实施---->
    • 监控
      • 输出
        • 项目文件更新（P120）
          • 变更日志，用来记录项目过程中出现的变更，被否决的变更请求也应该记录在变更日志中
        • 项目管理计划更新（P120）
          • 对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性
    • ：批准的变更请求+项目文件更新+项目管理计划更新
      • 批准的变更请求（P120）
        • 变更请求批准人的选择顺序
          • 项目管理计划或组织流程中指定的责任人（最准确的说法，但不常见）
          • 变更控制委员会（CCB）（考试“默认” 变更提交给CCB来审批，最常见的选择）
          • 如题中无以上选项，则可选“PMO”、“发起人”、“项目经理”
    • 书面形式 记录。 并纳入变更管理和/或配置管理系统中
      • 应该评估变更对时间和成本的影响，并向这些过程提供评估结果
      • 每项记录在案的变更请求都
    • 必须由一位责任人批准、推迟或否决 ，应在项目管理计划或组织程序中指定这位责任人，必要时， 应由变更控制委员会（CCB）来开展实施整体变更控制过程
      • CCB：
    • 一个正式组成的团体 ，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定
      • 【补充】“变更日志”和“变更请求”实例
      • 收尾过程组
    • 结束项目或阶段
      • 之七“
        • 项目整合管理（收尾的补充）
          • 项目完成收尾的标志：释放资源（解散团队）、项目或阶段收尾文件
            • 如果当前项目在收尾，又被分配了新项目，项目经理优先保证当前项目的收尾
    • 结束项目或阶段 ”P121
      • What：
    • 结束项目或阶段，终结项目、阶段或合同的所有活动的过程
      • Why：
    • 本过程的作用， 存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作
      • 结束项目或阶段注意点（P101）
        • 项目或阶段收尾
          • 获得项目整体验收
          • 相关方满意度调查
          • 移交成果
          • 总结和记录经验教训
          • 组织过程资产更新
          • 文件归档
          • 庆功会
          • 释放资源
        • 在项目结束时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现
        • 若项目在完工前就提前终止，结束项目或阶段过程还是需要制定程序，来调查和记录提前终止的原因
        • 工具与技术
        • 输出
          • 最终报告（P127）
            • 用最终报告总结项目绩效
          • 组织过程资产更新（P128）（
            • 经验教训知识库：把历史信息和经验教训信息存入经验教训知识库，供未来项目或阶段使用
    • How： 结束项目或阶段（ITTO）： 输入 项目章程 + 验收的可交付成果 + 商业文件 + 组织过程资产 ）+ 工具与技术 数据分析 + 会议 ）+ 输出 最终产品、服务或成果移交 + 最终报告 + 组织过程资产更新
      • 输入
        • 验收的可交付成果（P125）
          • 包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果
        • 商业文件（P125）：商业论证+效益管理计划
          • 商业论证：用于确定项目是否达到了经济可行性研究的预期结果
          • 效益管理计划：用于测量项目是否达到了计划的效益
        • 组织过程资产（P126）：项目或阶段收尾指南或要求+配置管理知识库
          • 项目或阶段收尾指南或要求。如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估，以及知识传递
          • 配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准
    • 项目章程+验收的可交付成果+商业文件+组织过程资产
      • 项目章程（P124）
        • 项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束
    • 数据分析+会议
      • 数据分析（P126），可用于项目收尾的数据分析技术有：文件分析、回归分析、趋势分析、偏差分析
      • 会议（P126）
        • 会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功
        • 会议的类型包括：收尾报告会、客户总结会、经验教训总结会、庆祝会
    • 最终产品、服务或成果移交+最终报告+组织过程资产更新
      • 最终产品、服务或成果移交（P127）
        • 把项目交付的最终产品、服务或成果（对于阶段收尾，则是所在阶段的中间产品、服务或成果）从一个团队转交到另一团队或组织，并由其在整个生命周期中进行运营、维护和支持
    • 项目文件 + 运营和支持文件 + 项目或阶段收尾文件 + 经验教训知识库
      • 项目文件
      • 运营和支持文件
      • 项目或阶段收尾文件
        • 表明项目或阶段完工的正式文件
        • 把可交付成果移交给他人的正式文件
        • 若项目提前终止，需要：
          • 在正式的收尾文件中说明终止的原因
          • 把已完成未完成的可交付成果移交他人
    • 【重点】
      • 项目章程的作用、谁批准、制定项目章程的输入、输出的项目章程中包括的内容
      • 制定项目管理计划的工具kick-off会议，什么时候开，目的是什么，需要谁认可
      • 指导与管理项目工作的2个重要输入、输出
      • 管理项目知识的三个要点：信任的氛围、工具、输出
      • 监控项目工作的目的
      • 实施整体变更控制的流程以及对流程的理解
      • 收尾的步骤，关键的输入和输出
  • 第五章 项目范围管理
    • 核心概念
      • 项目范围管理包括
    • 做且只做所需 的全部工作
      • “范围”包括两重含义
        • 产品范围：某项产品、服务或成果所具有的特性和功能
        • 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
      • 【对比】产品范围与项目范围+预测型和适应型生命周期之范围管理
        • 产品范围VS项目范围
        • 预测型和适应型生命周期之范围管理
    • 发展趋势和新兴实践
      • 需求一直是项目管理中的重点
      • 组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势
      • 商业分析活动可在项目启动和项目经理任命之前就开始。要注重与商业分析专业人士的合作
      • 需求管理过程始于需要评估，结束于需求关闭
      • 项目经理与商业分析师之间是伙伴式合作关系
        • 商业分析师负责需求管理相关的活动
        • 项目经理负责确保这些活动在项目管理计划有所安排，并且在预算内按时完成，同时能够创造价值
    • 在敏捷和适应型环境中需要考虑的因素
      • 特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间
      • 有目的地构建和审查原型，并通过多次发布版本来明确需求。把需求列入未完项
    • 【讨论】“需求”和“范围”的区别
      • 需求：需求是一种需要
      • 范围：范围是满足“需求”必须交付的可交付成果和相关工作
    • 项目范围管理过程：
    • 规划过程组（ 规划范围管理+收集需求+定义范围+创建WBS + 监控过程组（ 确认范围+控制范围
      • 规划过程组
        • 之二“收集需求”
          • What
        • 之三“定义范围”
          • What
          • How
            • 工具与技术：
          • 【区别】项目章程与项目范围说明书的内容P155
            • 项目章程的内容
              • 项目目的
              • 可测量的项目目标和相关的成功标准
              • 高层级需求
              • 高层级项目描述、边界定义以及主要可交付成果
              • 整体项目风险
              • 总体里程碑进度计划
              • 预先批准的财务资源
              • 主要相关方名单
              • 项目审批要示
              • 项目退出标准
              • 委派的项目经理及其职责和职权
              • 发起人或其他批准项目章程的人员的姓名和职权
            • 项目范围说明书的内容：
          • 【举例区别】高层级需求、需求、范围
        • 之四“创建WBS”
          • WBS 组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）
          • WBS最低层的组成部分称为工作包，其中包括计划的工作
          • 在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身
    • （规划范围管理+收集需求+定义范围+创建WBS）
      • 之一“规划范围管理”
        • What
    • ：为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
      • Why
    • ：本过程的作用，在整个项目中对如何管理范围提供指南和方向
      • How
    • ：规划范围管理（ITTO）， 输入 项目章程+项目管理计划 ）+ 工具与技术 （专家判断+数据分析+会议）+ 输出 （范围管理计划+需求管理计划）
      • 输入：
    • 项目章程+项目管理计划 （质量管理计划+项目生命周期描述+开发方法）
      • 工具与技术：
    • 专家判断+数据分析 （备选方案分析） +会议
      • 输出
        • 需求管理计划（P137）
          • 需求管理计划（商业分析计划），描述将如何分析、记录和管理项目和产品需求
          • 需求管理计划将用于下列工作的管理过程做出规定：
            • 如何规划 、跟踪和报告各种需求活动
            • 配置管理活动
            • 需求优先级排序过程
            • 测量指标及使用这些指标的理由
            • 反映哪些需求属性将补列入跟踪矩阵的跟踪结构
          • 注意点
            • 1、
    • 范围管理计划+需求管理计划
      • 范围管理计划（P137）
        • 范围管理计划，描述将如何定义、制定、监督、控制和确认项目范围
        • 将用于下列工作的管理过程做出规定
          • 制定项目范围说明书
          • 根据详细项目范围说明书创建WBS
          • 确定如何审批和维护范围基准
          • 正式验收已完成的项目可交付成果
        • 注意点
          • 1、
    • 范围管理计划无范围（范围在范围基准中）
      • 2、范围管理计划可以是正式或非正式的，非常详细或高度概括的
    • 需求管理计划无需求（需求在需求文件中）
      • 2、内容包括配置管理活动、需求优先级排序过程、测量指标等
    • ：为实现目标而确定、记录并管理相关方的需要和需求的过程
      • Why
    • ：本过程的作用，为定义产品范围和项目范围奠定基础
      • How
        • 输入：
          • 商业文件（P141）
            • 会影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准
          • 协议（P141）
            • 协议会包含项目和产品需求
        • 工具与技术
          • 数据分析：文件分析，分析现有文件
          • 决策：投票+独裁型决策制定+标准决策分析
            • 投票
              • 一致同意：每个人都同意+
            • 独裁型决策制定：一个人做决策
            • 多标准决策分析：决策矩阵、多种标准、评估和排序
          • 数据表现：
          • 系统交互圈：拓扑图、可视化
          • 原型法：支持渐进明细的理念（1模型创建2用户体验3反馈收集4原型修改）
        • 输出
          • 需求跟踪矩阵（P148）
            • 需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格
            • 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值
            • 提供了在整个项目生命周期中跟踪需求的一种方法（正向跟踪和逆向跟踪）
            • 有助于确保需求文件中 被批准的每项需求在项目结束的时候都能交付
            • 收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实范围
            • 需要进一步明确哪些包含在项目范围内，哪些排除在项目范围外（定义范围）
    • ：收集需求过程（ITTO）， 输入 项目文件+商业文件+协议 ）+ 工具与技术 数据收集+数据分析+决策+数据表现+人际关系与团队技能+系统交互圈+原型法 ）+ 输出 需求文件
      • 什么是需求？
        • 需求：根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力
        • 需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望
    • 项目文件+商业文件+协议
      • 项目文件（P141）
        • 相关方登记册：用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望
    • （P142-P144） ：数据收集+数据分析+决策+数据表现+人际关系与团队技能+系统交互圈+原型法
      • 数据收集：头脑风暴+访谈+焦点小组+问卷调查+标杆对照
        • 头脑风暴：大量创意，各种想法、畅所欲言
        • 访谈：直接交谈、预设和即兴问题，一对一、多对多、获取机密信息
        • 焦点小组：同职能，同一领域，有相似背景，主题专家（SME）、主持人引导互动式讨论
        • 问卷调查：受众多样化，需快速完成、地理位置分散、适合开展统计分析
        • 标杆对照：标杆可是内部或外部、同行业或不同行业、识别最佳实践、形成改进意见
    • 德尔菲（专家、匿名、多轮、趋同、消除偏见）
      • 大多数同意：超过50%，一般把决策小组的人数定为奇数
      • 相对多数同意：相对多数，通常候选项超过2个时使用
    • 亲和图+思维导图
      • 亲和图：分组、分类；以便进一步审查分析
      • 思维导图
    • ：整合、反映共性与差异、激发新创意、脑力
      • 人际关系与团队技能：
    • 名义小组+观察和交谈+引导
      • 名义小组：促进头脑风暴、投票、优先排序、5分制、数轮
      • 观察（工作跟随）和交谈：难以或不愿清晰说明、挖掘隐藏的需求
      • 引导：与主题研讨会结合使用、跨职能、不同部门、协调相关方差异
        • 联合应该设计或开发：软件开发行业，业务主题专家和开发团队集中
        • 质量功能展开：制造行业、收集客户需要（客户声音）开始、分类和排序
        • 用户故事：需求研讨会、角色、目标、动机
    • 需求文件+需求跟踪矩阵
      • 需求文件
        • 需求文件：描述各种单一需求将如何满足与项目相关的业务需求
          • 只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准
        • 需求的分类：业务需求+相关需求+解决方案需求+过程和就绪需求+项目需求+质量需求
          • 业务需求：整个组织的高层级需要
          • 相关方需求：相关方或相关方群体的需要
          • 解决方案需求：为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征
          • 过渡和就绪需求：从“当前状态”过渡到“将来状态”所需的临时能力。如，数据转换和培训需求
          • 项目需求：项目需要满足的行动、过程或其他条件，如里程碑日期、合同 责任、制约因素
          • 质量需求：用于确认可交付成果的成功完成或其他项目需求的实现的任何条件或标准，如测试、认证、确认
    • ：定义范围，制定项目和产品详细描述的过程
      • Why
    • ：本过程的作用， 描述产品、服务或成果的边界和验收标准
      • 从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述（P151）
        • 应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书
        • 还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新
        • 需要多次反复开展定义范围过程（涉及多个迭代）
    • ：定义范围（ITTO）， 输入 项目章程+项目文件 ）+ 工具与技术 数据分析+决策+人际关系与团队技能+ 产品分析 ）+ 输出 （项目范围说明书）
      • 输入：
    • 项目章程+项目文件
      • 项目章程（P152），包含对项目的高层级描述、产品特征和审批要求
      • 项目文件（P152）需求文件，识别了应纳入范围的需求
    • 数据分析+决策+人际关系与团队技能+产品分析
      • 数据分析（P153）可用于本过程的数据分析技术包括：备选方案分析
      • 决策（P153）可用于本过程的决策技术包括：多标准决策分析
      • 人际关系与团队技能（P153）在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识
      • 产品分析（P153）
    • 把高层级的产品描述转变为有形的可交付成果。 产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等
      • 输出：项目范围说明书
        • 项目范围说明书：
        • 包含的内容：产品范围描述+可交付成果+验收标准+除外责任
          • 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
          • 可交付成果：必须产出的任何独特并可核实的产品、成果或服务能力。也包括辅助成果，如项目管理报告和文件
          • 验收标准：可交付成果通过验收前必须满足的一系列条件
          • 除外责任：明确说明哪些内容不属于项目范围，有助力管理相关方的期望及减少范围蔓延
    • 是对项目范围、主要可交付成果、假设条件和制约因素的描述 。记录了整个范围，包括项目和产品范围
      • 项目范围说明书详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识
      • 为了便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围
    • 项目范围描述+项目可交付成果+验收标准+项目排除项
      • 项目范围描述（渐进明细）
      • 项目可交付成果
      • 验收标准
      • 项目排除项
    • （工作分解结构）
      • What：
    • 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
      • Why：
    • 本过程的作用， 对所要交付的内容提供架构
      • How：
        • 分解的五个步骤（P158）
          • 01识别和分析可交付成果及相关工作
          • 02 确定WBS的结构和编排方法
          • 03 自上而下逐层细化分解
          • 04 为WBS组件制定和分配标识编码
          • 05 核实可交付成果分解的程度是否恰当
        • WBS的结构形式（P159）
          • 把项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
            • 【示例】 以“阶段”作为第二层
          • 把主要可交付成果作为分解的第二层
            • 【补充示例】 以“主要交付成果”作为第二层
          • 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）
        • 【补充】WBS词典的含义
        • 创建WBS：4个注意+4个主要原则+创建WBS的输出，范围基准
          • 4个注意（P160）
            • 如果采用敏捷方法，可以将长篇故事分解成用户故事
            • 不同的可交付成果可以分解到不同的层次
            • 并不是分解得越细越好。过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难
            • 远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划
          • 4个主要原则（P161）
            • 无遗漏无多余：100%原则
            • 工作包80小时：80小时原则
            • 4~6层原则：不宜过细分解
            • 责任明确原则：有明确责任人
          • 创建WBS的输出，范围基准（P161-P162）
            • 哪儿找可交付成果和验收标准：首选范围说明书，次选wbs词典，再次选范围基准
        • 控制账户与工作包（P161）
          • 控制账户（CA）：是一个管理控制点（可以与组织的财务程序链接），在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效
          • 绩效测量基准（PMB）：由范围基准、进度基准、成本基准共同构成
          • 每个控制账户可能包括一个或多个工作包（或规划包），但是一个工作包只能属于一个控制账户
    • 创建WBS（ITTO）， 输入 项目管理计划+项目文件+事业环境因素+组织过程资产 ）+ 工具与技术 专家判断+ 分解 ）+ 输出 范围基准+项目文件更新
      • 概念：分解、工作、创建WBS
        • 分解：把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术
        • 工作包：WBS 最低层的组件，可对其成本和持续时间进行估算和管理
        • 创建WBS：就是要将整个项目工作分解为工作包
      • 监控过程组
        • 之六“控制范围”
          • What：
          • How：
            • 工具与技术
            • 输出：
              • 项目文件更新：经验教训登记册+需求文件+需求跟踪矩阵
                • 经验教训登记册
                • 需求文件
                • 需求跟踪矩阵
    • （确认范围+控制范围）
      • 之五“确认范围”
        • What
        • 【补充】
    • ：“客户”或“发起人”正式验收已完成的项目可交付成果的过程
      • Why：
    • 本过程的作用，通过验收每个可交付成果，提高最终产品、服务或成果验收的可能性
      • How： 确认范围
        • 工具与技术
        • 输出：
          • 变更请求
            • 如果未通过验收，处理步骤（1）记录（了解）原因；（2）走变更流程，进行缺陷补救
          • 工作绩效信息
          • 项目文件更新
            • 经验教训登记册
            • 需求文件
            • 需求跟踪矩阵
    • （ITTO） 输入 （项目管理计划+项目文件+核实的可交付成果+工作绩效数据）+ 工具与技术 （检查+决策）+ 输出 （验收的可交付成果+ 变更请求+工作绩效信息+项目文件更新）
      • 输入：
    • 项目管理计划+项目文件+核实的可交付成果+工作绩效数据
      • 项目管理计划：范围管理计划+需求管理计划+范围基准
      • 项目文件：经验教训登记册+质量报告+需求文件+需求跟踪矩阵
      • 核实的可交付成果：已经完成，并被控制质量过程检查为正确的可交付成果
      • 工作绩效数据
    • 检查+决策（投票）
      • 检查（审查、产品审查、巡检），开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准
      • 决策
    • 验收的可交付成果+ 变更请求+工作绩效信息+项目文件更新（经验教训登记册+需求文件+需求跟踪矩阵）
      • 验收的可交付成果
        • 符合验收标准的可交付成果应该由客户或发起人正式签字批准
        • 应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收
    • 监督项目和产品的范围状态，管理范围基准变更的过程
      • Why：
    • 本过程的作用
      • 在整个项目期间保持对范围基准的维护
      • 确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理
    • 控制范围（ITTO）， 输入 项目管理计划+项目文件+工作绩效数据+组织过程资产 ）+ 工具与技术 （数据分析）+ 输出 （工作绩效信息）
      • 输入
        • 项目文件：经验教训登记册+需求文件+需求跟踪矩阵
          • 经验教训登记册
          • 需求文件
          • 需求跟踪矩阵
        • 工作绩效数据
        • 组织过程资产
    • ：项目管理计划+项目文件+工作绩效数据+组织过程资产
      • 项目管理计划：范围管理计划+需求管理计划+变更管理计划+配置管理计划+范围基准+绩效测量基准
        • 范围管理计划
        • 需求管理计划
        • 变更管理计划
        • 配置管理计划
        • 范围基准
        • 绩效测量基准
    • ：数据分析（偏差分析+趋势分析）
      • 偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施
      • 趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
      • 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作
    • 工作绩效信息+变更请求+项目管理计划更新+项目文件更新
      • 工作绩效信息
      • 变更请求
      • 项目管理计划更新：范围管理计划+范围基准+进度基准+成本基准+绩效测量基准
        • 范围管理计划
        • 范围基准
        • 进度基准
        • 成本基准
        • 绩效测量基准
    • 【区别】范围蔓延、镀金、范围潜变
      • 范围蔓延：未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大（P168）。如果已经出现了范围蔓延，需要
    • 补变更流程 。如果变更没有获得批准，需要取消不良变更
      • 镀金：来自团队
    • 内部 原因造成的范围蔓延称为“镀金”（项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动）
      • 范围潜变：来自团队
    • 外部 原因造成的范围蔓延称为“范围潜变”（范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败）
    • 【重点】
      • 范围强调“做且只做”，要多做、少做都要走变更流程
      • “产品需求”衡量产品范围的完成情况，“项目管理计划”衡量项目范围的完成情况
      • 范围管理计划中无范围，需求管理计划中无需求
      • 收集需求的输入、工具、输出
      • 定义范围的定义，输入、工具、输出
      • 创建WBS的输入、工具和输出
      • 确认范围的定义和作用，输入、工具和输出
      • 控制范围的定义，范围蔓延的定义和处理方式
  • 第六章 项目进度管理
    • 适应型生命周期 的 滚动式规划 （如敏捷）
      • 做法：3点
        • 需求记录在用户故事中
        • 建造之前按优先级排序并优化用户故事
        • 在规定时间盒内开发产品功能
      • 在敏捷和适应型环境中需要考虑的因素（P178）
        • 适应型方法采用短周期来开展工作、审查结果，并在必要时做出调整
        • 通常表现为迭代型进度计划和拉动式按需进度计划
        • 在大型组织中，可能同时存在小规模项目和大规模举措，需要制定长期路线图
        • 为管理大规模的、全企业系统的、完整的交付生命周期，可能需要采用预测型方法、适应型方法或两种方法的混合
        • 无论是采用预测型还是适应型，项目经理的角色都不变
        • 但要成功实施适应型方法，项目经理需要了解如何高效使用相关的工具和技术
        • 监控过程组：
    • 项目进度管理过程 规划过程组 （规划进度管理 + 定义活动 + 排列活动顺序+估算活动持续时间+制定进度计划） + 监控过程组（ 控制进度）
      • 规划过程组
        • 之二“
          • How
            • 工具与技术
              • 滚动式规划（P185）
                • 滚动式规划，迭代式的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。
                • 滚动式规划是一种渐进明细的规划方式。适用于工作包、规划包以及采用敏捷或瀑布式方法的发布规划
                • 早期的战略规划阶段，信息尚不够明确，工作包只能分解到已知的详细水平；随着了解到更多的信息，近期即将实施的工作包就可以分解到具体的活动
            • 输出
              • 里程碑清单（P186）
                • 里程碑是重要的时点或事件
                • 里程碑可以是强制性的或者是选择性的
                • 里程碑与活动有相同的结构和属性，但是它不是活动，持续时间为零，只代表一个时间点
              • 变更请求（P186）
        • 之四“
          • How
            • 输出（持续时间估算）（P203）
              • 持续时间估算：持续时间估算是对完成某项活动、阶段或项目所需的工作时段数的定量评估，其中并不包括任何滞后量但可指出一定的变动区间
              • 例如：2 周 ± 2 天，表明活动至少需要 8 天，最多不超过 12 天（假定每周工作 5 天）；超过 3 周的概率为 15%，表明该活动将在 3 周内（含 3 周）完工的概率为 85%
              • 估算依据：应该清晰、完整地说明持续时间估算是如何得出的
        • 之五“
        • 20世纪管理学界三大经验式定律
          • 之一帕金森定律，只要还有时间，人们就会有意无意地多做不必要的工作（范围蔓延），直到用完所有的时间。学生综合症----工作范围通常不变，人们在较早时间完全不做事或者很少做事，总要等到截止日期快到时才着急做（比如大家学PMP的进度）
          • 之二墨菲定律，20世纪管理学界三大经验式定律之二有可能出错的事情，就会出错
          • 之三彼得定律，20世纪管理学界三大经验式定律之三工作岗位总是被不能胜任的人占据的
        • 学习曲线
          • 表示了经验与效率之间的关系，指的是越是经常地执行一项任务，每次所需的时间就越少（熟能生巧）
    • ：规划进度管理+定义活动+排列活动顺序+估算活动持续时间+制定进度计划
      • 之一“
    • 规划进度管理 ”P179
      • what
    • ：为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程
      • why
    • ：本过程的作用，为如何在整个项目期间管理项目进度提供指南和方向
      • How
    • ：规划进度管理（ITTO），输出（ 进度管理计划 ）（P181）
      • 输出：进度管理计划
        • 进度管理计划：为编制、监督和控制项目进度建立准则和明确活动
        • 进度管理计划无进度，包含的内容
          • 进度计划的发布和迭代长度
    • ：使用适应型生命周期时，应指定固定时间的发布时段、阶段和迭代。固定时间段有助于尽可能减少范围蔓延
      • 准确度
    • ：活动持续时间估算的可接受区间及允许的应急储备数量。比如：估算某活动的工期是10+2天
      • 计量单位
    • ：每种资源的计量单位。比如：时间计量用“人天”，数量计量用吨、千米等等
      • 控制临界值
    • ：项目执行中，采取某种措施前，允许出现的最大进度偏差。通常用偏离基准计划中的参数的某个百分数来表示
      • 绩效测量规则
    • ：需要规定用于绩效测量的挣值管理(EVM)规则或其他测量规则
      • 挣值测量技术，固定公式法(适用工作量无法准确测量来估算EV)
        • 50/50法则：开始计50%，结束计另外50%（保守，PMP认证最常用）
        • 20/80法则：开始计20%，结束计另外80%（更加保守） 了解即可
        • 0/100法则：开始计0%，结束计100%（最保守的）
    • 定义活动 ”P183
      • what
    • ：识别和记录为完成项目可交付成果而需采取的具体行动的过程
      • why
    • ：本过程的作用
      • 将工作包分解为活动，作为对项目工作进行估算、进度规划、执行、监督和控制的基础
      • 工作包是WBS中最低层的可交付成果
      • 工作包通常还应进一步细分为更小的组成部分，即“活动”， 代表着为完成工作包所需的工作投入
    • ：定义活动（ITTO）， 输入 项目管理计划 ）+ 工具与技术 分解 + 滚动式规划 ）+ 输出 活动清单 + 里程碑清单 + 变更请求 + 项目管理计划更新
      • 输入
    • ：项目管理计划（P184）
      • 范围基准，需明确考虑范围基准中的项目WBS、可交付成果、制约因素和假设条件
    • ：分解+滚动式规划
      • 分解（P185）
        • 分解，把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分
        • WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果
        • 让团队成员参与分解过程，有助于得到更好、更准确的结果
    • ：活动清单+里程碑清单+变更请求+项目管理计划更新
      • 活动清单（P185）
        • 包含项目所需的全部进度活动的综合清单，还包括每个活动的标识及工作范围详述
        • 使用滚动式规划或敏捷技术的项目，活动清单需要定期更新
    • 一旦定义基准后，在将可交付成果渐进明细为活动的过程中，可能会发现原本不属于项目基准的工作，这样就会提出变更请求。对变更请求的处理要通过实施整体变更控制过程。
      • 项目管理计划更新（P186）
    • 可能需要变更请求的项目管理计划组成部分包括：进度基准，成本基准
      • 之三“
    • 排列活动顺序 ”P187
      • what
    • ：识别和记录项目活动之间的关系的过程
      • why
    • ：定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率
      • How
        • 输出：项目进度网络图（P194）
          • 路径汇聚，带有多个紧前活动的活动（如活动I）
          • 路径分支，带有多个紧后活动的活动（如活动K）
          • 带汇聚和分支的活动受到多个活动的影响或能够影响多个活动，因此存在更大的风险
    • ：排列活动顺序（ITTO），工具与技术（ 紧前关系绘图法PDM + 确定和整合依赖关系 + 提前量和滞后量 ）+输出（ 项目进度网络图
      • 工具与技术（紧前关系绘图法PDM+确定和整合依赖关系+提前量和滞后量）
        • 紧前关系绘图法PDM（P189）
          • 紧前关系绘图法（PDM、节点法、AON、前导图法、单代号法），创建进度模型的一种技术，用节点表示活动，用一种或多种逻辑关系连接活动，以显示活动的实施顺序
          • 紧前活动，进度计划的逻辑路径中，排在非开始活动前面的活动
          • 紧后活动，进度计划的逻辑路径中，排在某个活动后面的活动
          • 紧前关系绘图法PDM的四种逻辑关系（P190）
        • 确定和整合依赖关系（P191）
          • 强制性依赖关系（硬逻辑、硬依赖），法律或合同要求的或工作的内在性质决定的依赖关系（项目团队不能违反）
          • 选择性依赖关系（首选逻辑、优先逻辑、软逻辑），基于最佳实践建立的、或基于项目的某些特殊性质而采用的依赖关系（项目团队可自由选择）
          • 如果打算快速跟进，应当审查相应的选择性依赖关系
          • 外部依赖关系，项目活动与非项目活动之间的依赖关系（项目团队不可控）
          • 内部依赖关系，是项目活动之间的紧前关系（项目团队可控）
          • 可两两组合形成：强制性外部关系、强制性内部关系、选择性外部关系、选择性内部关系
        • 提前量和滞后量（P192）
          • 提前量，相对于紧前活动，紧后活动可以提前的时间量。（往往表示为负滞后量，如FS-3）
          • 滞后量，相对于紧前活动，紧后活动必须推迟的时间量。（如FS+2）
          • 提前量和滞后量的使用不能替代进度逻辑关系，活动持续时间估算中不包括任何提前量或滞后量
    • 估算活动持续时间 ”P195
      • what
    • ：估算活动持续时间，根据资源估算的结果，估算完成单项活动所需工作时段数（也叫工期）的过程
      • 应该由项目团队中最熟悉具体活动的个人或小组，来提供活动持续时间估算所需的各种输入
      • 【注意】向某个活动新增资源或分配低技能资源，就需要增加沟通、培训和协调工作。从而可能导致活动效率或生产率下降，以致需要更长的持续时间
      • 估算活动持续时间需考虑的其他因素（P197）
        • 收益递减规律，在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素（如资源）会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减
        • 资源数量，增加资源数量，不一定能缩短时间。可能会因风险造成持续时间增加，也可能因对于增加的资源，需要知识传递、学习曲线、额外合作等因素造成持续时间增加
        • 技术进步
        • 员工激励，估算时还需考虑“学生综合症”和“帕金森定律”
    • ：估算活动持续时间（ITTO），工具与技术（ 三点估算 ）+输出（持续时间估算）
      • 工具与技术（
        • 自下而上估算：从下到上、逐层汇总
        • 数据分析：备选方案分析+储备分析
          • 备选方案分析：比较不同、有助于权衡、确定最佳方式。
          • 储备分析：应急储备（已知—未知）、管理储备（未知—未知）
        • 决策：投票，举手表决（常用于敏捷）、达成共识或同意进入下一个决定
        • 会议：敏捷中，冲刺或迭代计划会议、未完项
        • 储备分析
          • 应急储备是包含在进度基准中的一段持续时间，用来应对已经接受的已识别风险（已知 – 未知）
          • 管理储备是为管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作（未知 – 未知）
    • 三点估算 ）（P200~P203）
      • 类比估算：相似活动、历史数据、也是一种专家判断、也是整体估算、也是自上而下的、成本较低、耗时较少，准确性也较低、项目详细信息不足时、在启动阶段
      • 参数估算：历史数据、项目参数、统计关系、参数模型、基础数据、公式
      • 三点估算：
    • 考虑不确定性和风险、计划评审技术PERT、最乐观、最可能、最悲观
      • 三点估算，源自计划评审技术（PERT）。考虑估算中的不确定性和风险，来提高估算的准确性。
      • 三个估算值：
    • 最可能时间、最乐观时间、最悲观时间
      • 两种假定分布
        • 三角分布----期望值（平均值） = （最悲观 + 最乐观 + 最可能） / 3
        • 贝塔分布----期望值（平均值） = （最悲观 + 最乐观 + 最可能×4） / 6 （默认使用）
    • 制定进度计划 ”P205
      • what
    • ：分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程
      • why
    • ：为完成项目活动而制定具有计划日期的进度模型
      • How
        • 输出（
          • 项目进度计划（P217）
            • 项目进度计划，进度模型的输出，展示活动之间的相互关联，以及计划日期（至少要有）、持续时间、里程碑和所需资源。有三种层次的进度计划（详细程度由低到高）
          • 项目日历（P220）
            • 项目日历，规定可以开展进度活动的可用工作日和工作班次，它把可用于开展进度活动的时间段与不可用的时间段区分开来
    • ：制定进度计划（ITTO），工具与技术（ 进度网络分析 + 关键路径法CPM + 资源优化 + 数据分析 + 提前量和滞后量 + 进度压缩 + 项目管理信息系统PMIS + 敏捷发布规则 ）+输出（ 进度基准 + 项目进度计划 + 项目日历
      • 工具与技术（
        • 关键路径法CPM（P210）
          • 7格图计算活动的日期
            • 步骤1 顺推标出所有活动的ES、EF
              • 顺推找最大----意思是当某一活动（如下图的D）有多个紧前活动（如下图的B、C）那么根据公式：ES = （所有紧前活动的EF中最大的值） + 1活动D的ES = （活动B的EF—10和活动C的EF—15两者之间最大的值）+1 = 15+1=16
            • 步骤2 逆推标出所有活动的LS、LF、TF
              • 逆推找最小----意思是当某一活动（如下图的A）有多个紧后活动（如下图的B、C）那么根据公式：LF = （所有紧后活动的LS中最小的值） - 1 活动A的LF = （活动B的LS—11和活动C的LS—6两者之间最小的值）-1 = 6-1=5
            • 步骤3 根据最终结果得出一些结论
              • 结论一、根据时间最长的活动顺序，可以找到关键路径：ACD=30天（最短工期）
              • 结论二、各活动的TF----A：0；B：5；C：0；D：0；此题关键活动的TF都为0
              • 结论三、各活动的FF----A：6-5-1=0；B：16-10-1=5；C：16-15-1=0
          • 总浮动和自由浮动
          • 【总结】
            • 关键路径是项目中时间最长的活动顺序，决定着可能的项目最短工期
            • 总浮动时间：活动延期但不至于延误项目完工日期。体现进度灵活性
            • 自由浮动时间：活动延期但不延误任何紧后活动最早开始日期
            • 关键路径的总浮动时间可能是正值、零或负值
            • 关键路径可能存在多条，关键路径越多，风险越大。（次关键路径与关键路径越接近，风险越大）关键路径上的活动被称为关键路径活动
            • 关键路径法排出来的进度计划未必可行，关键路径法不考虑资源约束，需要配合资源平衡处理
            • 关键路径不考虑资源约束，只是考虑路径约束
        • 资源优化（P211）
          • 资源优化技术，根据资源供需情况，来调整进度模型的技术。包括“资源平衡”和“资源平滑”
          • 资源平衡，根据资源制约对开始日期和结束日期进行调整的一种技术。
          • 需要资源平衡的情况：
            • 1、资源只在特定时间可用；
            • 2、资源数量有限；
            • 3、资源被过度分配（如一个资源在同一时间段内被分配至多个活动）
            • 4、也可以为保持资源使用量处于均衡水平而进行资源平衡（减少资源负荷的变化）
          • ➢ 资源平衡往往导致关键路径改变，通常是延长。
          • ➢ 理想情况下，资源平衡应作用于非关键路径上的活动
          • 资源平滑,对活动进行调整，使项目资源需求不超过预定的资源限制的技术，活动只在其自由和总浮动时间内延迟。所以该技术可能无法实现所有资源的优化
          • 资源平滑不会改变项目关键路径，完工日期也不会延迟
          • 【补充】
        • 数据分析（P213）
          • 假设情景分析，对各种情景进行评估，预测它们对项目目标的影响（积极或消极的）
          • 对“如果情景X 出现，情况会怎样？”这样的问题进行分析。既基于已有的进度计划，考虑各种各样的情景
          • 根据假设情景分析的结果，评估项目进度计划在不利条件下的可行性，以及为应对意外情况的影响而编制进度储备和应对计划
          • 模拟，把单个项目风险和不确定性的其他来源模型化的方法，以评估它们对项目目标的潜在影响
          • 常用的模拟技术是蒙特卡洛分析
        • 提前量和滞后量（P214）
          • 通过调整紧后活动的开始时间来编制一份切实可行的进度计划
          • 提前量用于在条件许可的情况下提早开始紧后活动
          • 滞后量是在某些限制条件下，在紧前和紧后活动之间增加一段不需工作或资源的自然时间
        • 进度压缩（P215）
          • 进度压缩，不缩减项目范围的前提下，缩短或加快进度工期（进度压缩之后要进行关键路径分析，防止出现新的关键路径）
          • 进度压缩包括以下两种方式：
            • ◆ 赶工，通过増加资源，以最小的成本増加来压缩进度工期。可能导致成本和/或风险的增加。赶工只适用于那些通过增加资源就能缩短持续时间的，且位于关键路径上的活动。
            • ◆ 快速跟进，按顺序进行的活动或阶段改为至少是部分并行开展。可能造成返工和风险增加。快速跟进只适用于相互为选择性依赖关系的活动。
        • 项目管理信息系统PMIS（P216）
          • 用进度计划软件，自动生成开始和完成日期，从而可加快进度计划的编制过程
        • 敏捷发布规则（P216）
          • 基于项目路线图和产品发展愿景，提供了高度概括的发布进度时间轴（通常是3到6个月）
          • 确定了发布的迭代或冲刺次数，使产品负责人和团队能确定达到产品放行所需的时间。
          • 对客户而言，产品功能就是价值，因此，该时间轴定义了每次迭代结束时交付的功能，提供了易于理解的项目进度计划，而这些就是客户真正需要的信息
        • 做题时关于进度压缩、赶工、快速跟进的优先选择次序，进度落后
          • 有明确“不计成本地去缩短关键路径”的描述，选“赶工”
          • 有明确“没有额外的资源”或者“成本不能超支”的描述，选“快速跟进”
          • 无任何以上明确的限制条件描述，选择优先级为：进度压缩>赶工>快速跟进
    • 进度网络分析 + 关键路径法CPM + 资源优化 + 数据分析 + 提前量和滞后量 + 进度压缩 + 项目管理信息系统PMIS + 敏捷发布规则
      • 进度网络分析（P209）
        • 进度网络分析，是创建项目进度模型的一种综合技术，它采用了其他几种技术，例如关键路径法、资源优化技术、建模技术
        • 当多个路径在同一时间点汇聚或分叉时，评估汇总进度储备的必要性，以减少出现进度落后的可能性
        • 审查网络，看关键路径是否存在高风险活动或具有较多提前量的活动，是否需要降低关键路径的风险
    • 进度基准 + 项目进度计划 + 项目日历
      • 进度基准（P217）
        • 进度基准，经相关方接受和批准的进度模型，包含了基准的开始/结束日期等信息的，只有通过正式的变更控制程序才能进行变更，用作与实际结果进行比较的依据
    • 控制进度
      • 之六“
        • 敏捷方法中，控制进度关注的内容
          • 判断进度状态
          • 实施回顾性审查，以便纠正与改进过程
          • 对剩余工作计划（未完项）重新进行优先级排序
          • 确定每次迭代时间内可交付成果的生成、核实和验收的速度
          • 确定项目进度已经发生变更
          • 在变更实际发生时对其进行管理
    • 控制进度 ”P222
      • what
    • ：监督项目状态，更新项目进展，管理进度基准变更的过程
      • why
    • ：本过程的作用，整个项目期间保持对进度基准的维护
      • How
    • ：控制进度（ITTO），工具与技术（数据分析）
      • 工具与技术：数据分析（P226）
        • 挣值分析，将进度绩效测量指标与进度基准比较。
        • 迭代燃尽图，用于追踪迭代未完项中尚待完成的工作。可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。
          • 1、用对角线表示理想的燃尽情况
          • 2、每天画出实际剩余工作
          • 3、基于剩余工作计算出趋势线以预测完成情况
          • 绩效审查，根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比及当前工作的剩余持续时间
        • 趋势分析，检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化
        • 偏差分析，关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，浮动时间的偏差
        • 假设情景分析，基于项目风险管理过程的输出，对各种不同的情景进行评估，促进符合基准
      • 【补充】几个注意点
        • 如果在执行过程中发现某个活动的总浮动时间为负，极有可能该活动是关键活动，而且已经延期
        • 如果题目中体现了时间要缩短，需要压缩工期，选择进度压缩（赶工或者快速跟进）
        • 如果题目中体现了资源负荷大，需要平摊负荷，选择资源优化（资源平衡或资源平滑）
        • 关键路径上压工期，非关键路径上抽资源
        • 进度落后，产生进度偏差，优先考虑用纠正措施压缩进度（赶工或快速跟进）
        • 如果实在无法符合进度，不得已的情况下，再考虑通过变更流程缩减范围或延长进度
      • 项目进度管理
      • 【重点】
        • 进度管理计划中无进度
        • 定义活动的输入、工具和输出
        • 排列活动顺序的工具和输出
        • 估算活动持续时间应该由谁来估
        • 估算活动持续时间的工具
        • 制定进度计划的工具和输出
        • 注意总浮动时间和自由浮动时间、赶工和快速跟进、资源平衡和资源平滑各自的区别
        • 如果进度延期，优先采取纠正措施（进度压缩）来维护基准
    • 核心概念（P175）
      • 项目管理团队通过以下步骤开展进度规划工作
        • ① 选择进度计划方法（如关键路径法、敏捷方法）
        • ② 将项目特定数据（如活动、计划日期、持续时间、资源、依赖关系、制约因素等）输入进度计划编制工具，创建出项目进度模型
        • ③ 通过以上工作输出“项目进度计划”这个成果
      • 应在整个项目期间保持项目详细进度计划的灵活性，使其可以随着知识的获得、对风险理解的加深，以及增值活动的设计而调整
    • 发展趋势和新兴实践（P177）
      • 具有未完项的迭代型进度计划
        • 基于
        • 适用于：A、向客户交付增量价值；B、多个团队并行开发大量内部关联较小的功能
        • 好处：允许在整个开发生命周期期间进行变更
      • 按需进度计划
        • 基于制约理论和来自精益生产的拉动式进度计划
        • 根据团队的交付能力来限制团队正在开展的工作
        • 通常用于看板体系
        • 做法：在资源可用时立即从未完项和工作序列中提取出来开展
        • 适用于：A、在运营或持续环境中以增量方式研发产品；B、任务的规模或范围相对类似；C、可以按照规模和范围进行组合的工作
  • 第七章 项目成本管理
    • 规划过程组 规划成本管理+估算成本+制定预算 +监控过程组 控制成本
      • 规划过程组：规划成本管理+估算成本+制定预算
        • 之一“
        • 之二“
        • 之三“
    • 规划成本管理 ”P235
      • what
    • ：规划成本管理，确定如何估算、预算、管理、监督和控制项目成本的过程
      • why
    • ：本过程的作用，在整个项目期间为如何管理项目成本提供指南和方向
      • How
    • ：规划成本管理（ITTO）， 输出 成本管理计划
      • 输出
    • 成本管理计划 （P238）
      • 成本管理计划，描述将如何规划、安排和控制项目成本（成本管理计划无成本）包含的内容
        • 计量单位：每种资源的计量单位。比如：时间计量用“人天”，数量计量用吨、千米等等
        • 准确度：为活动成本估算规定一个可接受的区间（如±10%)，其中可能包括一定数量的应急储备
        • 精确度：根据活动范围和项目规模，设定成本估算向上或向下取整的程度
        • 组织程序链接：在项目成本核算中使用的WBS组件，称为控制账户（CA）。每个CA都有唯一的编码或账号，直接与执行组织的会计制度相联系
        • 控制临界值：项目执行中，采取某种措施前，允许出现的最大成本偏差。通常用偏离基准计划中的参数的某个百分数来表示
        • 绩效测量规则：需要规定用于绩效测量的挣值管理(EVM)规则或其他测量规则
    • 估算成本 ”P240
      • what
    • ：估算成本，对完成项目工作所需资源成本进行近似估算的过程。
      • why
    • ：本过程的作用, 确定项目所需的资金。成本估算是在某特定时点，根据已知信息所做出的成本预测。在估算成本时，需要识别和分析可用于启动与完成项目的备选成本方案；需要权衡备选成本方案并考虑风险，如比较自制成本与外购成本、购买成本与租赁成本及多种资源共享方案，以优化项目成本
      • How
        • 工具与技术：类比估算+参数估算+自下而上估算+三点估算PERT+数据分析
          • 类比估算（P244）参照过去，估算当前。也是一种专家判断、也是整体估算、也是自上而下的关键词：成本低、耗时少、准确性低、详细信息不足时、需要快速得到结果时、启动阶段时
          • 参数估算（P244）利用历史数据之间的统计关系和其他变量来估算。回归分析是典型的参数估算。关键词：统计关系、参数模型、基础数据
          • 自下而上估算（P244）估算个体，逐层汇总。自下而上估算的准确性及其本身所需的成本，通常取决于单个活动或工作包的规模和复杂程度
          • 三点估算PERT（P244）关键词：考虑不确定性与风险、提高估算准确性
          • 数据分析
            • 储备分析（P245）应急储备针对“已知 — 未知”风险，应急储备包含在基准中，项目经理有权使用。随着项目信息越来越明确，可以动用、减少或取消应急储备。应急储备是成本基准的一部分，也是项目整体资金需求的一部分。
            • 质量成本（P245，先了解）
        • 输出：成本估算+估算依据
          • 成本估算（P246）成本估算----包括对完成项目工作可能需要的成本、应对已识别风险的应急储备。
          • 估算依据（P247）支持性文件应清晰、完整地说明成本估算是如何得出的。
    • ：估算成本（ITTO）， 输入 项目文件 ）+ 工具与技术 类比估算+参数估算+自下而上估算+三点估算PERT+数据分析 ）+ 输出 成本估算+估算依据
      • 输入：项目文件
        • 项目文件，项目进度计划（P242）
    • 制定预算 ”P248
      • what
    • ：制定预算，汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程
      • why
    • ：本过程的作用，确定成本基准，可据此监督和控制项目绩效项目预算包括经批准用于项目的全部资金。成本基准是经过批准且按时间段分配的项目预算，包括应急储备，但不包括管理储备
      • How
        • 工具与技术
          • 历史信息审核（P253）
            • 审核历史信息有助于进行参数估算或类比估算。
          • 资金限制平衡（P253）
            • 资金限制平衡：在既定的资金限制下，确保项目各阶段、各部位和整个项目都有足够的资金，可能会导致进度计划的改变。
            • 可以通过在项目进度计划中添加强制日期来实现。
        • 输出
    • ：制定预算（ITTO）， 输入 商业文件+协议 ）+ 工具与技术 成本汇总+数据分析+历史信息审核+资金限制平衡 ）+ 输出 成本基准+项目资金需求
      • 输入
    • 商业文件+协议
      • 商业文件（P251）。商业论证，识别了项目成功的关键因素，包括财务成功因素。
      • 效益管理计划----包括目标效益，例如净现值的计算、实现效益的时限，以及与效益有关的测量指标
      • 协议（P251）需要考虑将要或已经采购的产品、服务或成果的成本，以及适用的协议信息。
    • 成本汇总+数据分析+历史信息审核+资金限制平衡
      • 成本汇总（P252），成本汇总路线：活动的成本估算→工作包→控制账户→整个项目。
      • 数据分析（P252）
        • 管理储备针对“未知 — 未知”风险，管理储备不包含在基准中，项目经理使用前需要提出变更请求。
        • 管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分。
        • 如果动用管理储备，动用的管理储备应该被纳入基准中，从而导致成本基准变更
    • 成本基准+项目资金需求
      • 成本基准（P254），成本基准是经过批准、按时间段分配的项目预算。包括应急储备，但不包括管理储备
      • 项目资金需求（P256），成本基准+管理储备。项目资金通常以阶梯状的形态，增量而非连续的方式投入。成本基准中既包括预计的支出，也包括预计的债务
    • 控制成本 ”P257
      • what
    • ：控制成本，监督项目状态，以更新项目成本，管理成本基准变更的过程
      • why
    • ：本过程的作用，在整个项目期间保持对成本基准的维护。在成本控制中，应重点分析项目资金支出与相应完成的实际工作之间的关系。有效成本控制的关键在于管理经批准的成本基准
      • How
        • 工具与技术
          • 偏差分析，SV、CV、SPI、CPI（P262）
          • 预测，EAC的四种计算公式（P264）
          • 完工尚需绩效指数，TCPI（P266）
          • 储备分析（P265）
            • 在控制成本过程中，可以采用储备分析来监督项目中应急储备和管理储备的使用情况从而判断是否还需要这些储备，或者是否需要增加额外的储备。
            • 如果已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备，为其他项目或运营腾出资源
    • ：控制成本（ITTO）， 输入 项目管理计划+项目资金需求+工作绩效数据 ）+ 工具与技术 挣值分析+偏差分析+预测EAC+完工尚需绩效指数+储备分析
      • 输入
    • 项目管理计划+项目资金需求+工作绩效数据
      • 项目管理计划（P259）需要使用其中的成本基准、成本管理计划、绩效测量基准等。
      • 项目资金需求（P260）包含预计支出和预计债务
      • 工作绩效数据（P260）包含关于项目状态的数据，例如哪些成本已批准、发生、支付和开具发票。
    • 挣值分析+偏差分析+预测EAC+完工尚需绩效指数+储备分析
      • 挣值分析（EVA），BAC、AC、PV、EV（P261）
        • BAC（完工预算），全部计划工作的预算价值，就是成本基准。BAC=完工时的PV的总和。若BAC=EV就表明项目已完工。
        • PV（计划价值）截止到某个时间点，计划完成工作的预算价值。PV（别称BCWS）= 计划工作量×预算单价。
        • EV（挣值）截止到某个时间点，实际完成工作的预算价值。EV（别称BCWP）= 实际工作量×预算单价。
        • AC（实际成本）截止到某个时间点，实际花了多少钱。AC（别称ACWP）= 实际工作量×实际单价
        • 【练习】
      • 重点
        • 估算成本的定义，工具和输出
        • 应急储备和管理储备的区别
        • 排列活动顺序的工具和输出
        • 制定预算的定义，工具和输出
        • 挣值分析：BAC、PV、EV、AC的含义
        • 偏差分析：SV、CV、SPI、CPI的公式和含义
        • 趋势分析：EAC、ETC的公式和含义
        • TCPI的公式和含义
    • 核心概念（P233）
      • 项目成本管理重点关注完成项目活动所需资源的成本，但同时也应考虑项目决策时对项目产品、服务或成果的使用成本、维护成本和支持成本的影响
      • 不同的相关方会在不同的时间、用不同的方法测算项目成本
    • 趋势和新兴实践（P233）
      • 对挣值管理（EVM)进行扩展，引入挣得进度（ES）的概念
    • 在敏捷和适应型环境中需要考虑的因素（P234）
      • 对易变性高、范围并未完全明确、经常发生变更的项目，可以采用轻量级估算方法快速生成对项目人力成本的高层级预测，在出现变更时容易调整预测
      • 详细的估算适用于采用准时制的短期规划
    • 项目成本管理过程
      • 监控过程组：控制成本
        • 之四“
          • 【补充知识】
            • 内部收益率IRR（Internal Rate of Return），净现值等于零时的折现率。代表了项目抗风险（通货膨胀等）能力的大小。越大越好。
            • 投资回收期PP（Payback Period），从项目的投建之日起，用项目所得的净收益偿还原始投资所需要的年限。不考虑货币时间价值，越短越好（PMP只考静态回收期）
            • 【练习】
            • 投资回报率ROI（Return On Investment），年平均利润 / 投资总额 × 100%不考虑货币时间价值，年平均利润是全部的利润。越大越好。
            • 效益成本比BCR（Benefit-Cost Ratio） ----项目投资与效益之间关系的比率，收益 / 投资BCR > 1--接受该项目；BCR < 1--放弃该项目；越大越好
            • 【总结】财务概念
  • 第八章 项目质量管理
    • ：规划如何管理质量、控制质量；需要遵守的质量标准、可交付成果的质量测量指标；
      • 管理质量“管过程”
    • ：做好质量审计，过程分析；分析质量控制测量结果，反思过程，持续改进；
      • 控制质量“查结果”
    • ：核实可交付成果是否满足质量测量指标。
      • 项目质量管理过程
        • 执行过程组：管理质量
          • 之二“
            • 管理质量的人员和角色（P290）
              • QA部门：执行某些管理质量活动，例如故障分析、实验设计和质量改进
              • 全员责任：所有人（项目经理、项目团队、项目发起人、执行组织的管理层，甚至是客户）在管理项目质量方面都扮演一定的角色
              • 质量管理在敏捷项目与传统项目
                • 敏捷项目中：所有团队成员执行
                • 传统项目中：特定团队成员执行
            • How
              • 工具与技术
                • 审计（P294）
                  • 质量审计：用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化的独立过程
                  • 质量审计的目标：识别+分享+协助+积累+确认
                    • 识别最佳实践、违规做法、差距及不足
                    • 分享类似项目的良好实践
                    • 协助过程改进、提高生产效率
                    • 积累经验教训
                    • 确认已批准的变更请求的实施情况
                  • 质量审计通常由项目外部的团队开展，如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。（内审或外审、事先安排或随机进行）
                • 数据分析（P292）
                  • 文件分析：分析项目控制过程所输出的文件，如质量报告、测试报告、绩效报告和偏差分析，找到失控的过程，或有问题的过程。
                  • 根本原因分析 (RCA)：找到根本原因，杜绝问题再次发生。
                  • 过程分析：识别过程改进机会，发现一个过程中存在的问题、制约因素，和非增值活动。
                  • 备选方案分析：选择那些最合适的质量方案或方法。
                • 决策（P293）
                  • 多标准决策分析：用于讨论影响项目或产品质量的备选方案。
                  • “项目”决策：在多个实施方案或供应商之间做出选择。
                  • “产品”决策：综合考虑生命周期成本、进度、相关方满意度等。
                • 数据表现（P293）
                  • 因果图
                    • 因果图（鱼骨图、石川图、why-why分析图）：将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。
                    • 关键词：5个why
                      • 根本原因
                      • 主要原因
                      • 为什么
                      • 为什么怎样
                      • 怎样
                  • 直方图
                    • 直方图：是一种展示数字数据的条形图，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。
                    • 关键词：
                      • 集中趋势
                      • 分散程度
                      • 分布形状
                      • 特定变量发生的频率
                  • 帕累托图
                    • 帕累托图：一种特殊的垂直条形图，用于识别造成大多数问题的少数重要原因。
                    • 帕累托法则（二八定律）：数据的绝大部分存在于很少类别中，极少剩下的数据分散在大部分类别中（“至关重要的极少数（20%）”和“微不足道的大多数（80%）” ）
                    • 关键词：
                      • 主要原因
                      • 二八定律
                      • 80/20法则
                      • 优先排序
                      • 有重点地采取纠正措施
                  • 散点图
                    • 散点图（相关图）：展示两个变量之间的关系（解释因变量Y 相对于自变量X 的变化）。
                    • 关键字
                      • 两个变量
                      • 回归线
                      • 强相关性
                      • 自变量
                      • 因变量
                • 面向X的设计（P295）
                  • 面向X的设计（DfX）：产品设计期间可采用的一系列技术指南，旨在优化设计的特定方面，可以控制或提高产品最终特性。
                  • DfX中的“X”可以是产品开发的不同方面。
                  • 使用DfX可以降低成本、改进质量、提高绩效和客户满意度。
                • 问题解决（P295）
                  • 问题解决：发现解决问题或应对挑战的解决方案。
                  • 问题解决方法有助于消除问题和制定长久有效的解决方案。
                  • 1定义（问题）、2识别（根本原因）、3方案（生成方案）、4选择（最佳方案）、5执行、6验证（有效性）
                • 质量改进方法（P296）
                  • PDCA：计划、实施、检查、行动
                  • 六西格玛：百万分之三点四
              • 输出
                • 测试与评估文件（P296）
                  • 测试与评估文件：是一份项目文件，也被称为测试与评估指导方案。里面列出了一些活动，通过这些活动来确定项目是否满足质量目标（供控制质量使用，评估质量目标的实现情况），如质量核对单、需求跟踪矩阵等。
                • 变更请求（P296）
                  • 如果管理质量过程期间出现了可能影响项目管理计划任何组成部分、项目文件或项目/产品管理过程的变更，项目经理应提交变更请求并遵循 4.6 节定义的实施整体变更控制过程。
                  • 改善建议、纠正措施等会导致变更请求。
        • 监控过程组：控制质量
          • 之三“
            • How
              • 工具与技术：数据收集+数据分析+检查+测试/产品评估
                • 数据收集（P302）：核对单+核查表+统计抽样+问卷调查
                  • 核对单（ checklists ）
                  • 统计抽样：
                  • 问卷调查：
                • 检查（P303）
                  • 检查（审查、同行审查、审计、巡检）：指检验工作产品，以确定是否符合书面标准，也可用于确认缺陷补救。
                  • 检查可在任何层面上进行。可以检查单个活动的成果，也可以检查项目的最终产品。
                • 测试/产品评估（P303）
                  • 测试：有组织的、结构化的调查，旨在根据项目需求提供有关被测产品或服务质量的客观信息。
                  • 测试可以贯穿于整个项目，可以可用时进行，也可以在项目结束时进行，但建议尽早测试。
              • 输出：质量控制测量结果+核实的可交付成果+变更请求和项目文件更新
                • 质量控制测量结果（P305）
                  • 质量控制测量结果：对质量控制活动的结果的书面记录，应以质量管理计划所确定的格式加以记录
                • 核实的可交付成果（P305）
                • 变更请求和项目文件更新（P306）
                  • 问题日志：多次不符合质量要求的可交付成果通常被记录为问题。
                  • 测试与评估文件：本过程可能导致测试与评估文件修改，使未来的测试更加有效。
                  • 风险登记册：记录在本过程中识别的新风险，并通过风险管理过程进行管理。
                  • 经验教训登记册：记录质量缺陷的来源、本应可以规避它们的方法，以及有效的处理方式。
    • 规划过程组 规划质量管理 +执行过程组 管理质量 +监控过程组 控制质量
      • 规划过程组：规划质量管理
        • 之一“
    • 规划质量管理 ”P277
      • what
    • ：规划质量管理：识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程
      • why
    • ：本过程的作用，为整个项目中如何管理和核实质量提供指南和方向
      • How
        • 工具与技术：数据收集+数据分析+决策+数据表现+检查与测试的规划
          • 数据收集（标杆对照+头脑风暴+访谈）
            • 标杆对照（P281）：将实际或计划的项目实践或项目的质量标准与组织内部或外部、同一应用领域或不同应用领域的可比项目的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。（可用于确定质量标准）
            • 头脑风暴（P281）：收集数据，制定最适合新项目的质量管理计划。
            • 访谈：了解有经验的相关方和主题专家对项目和产品质量的隐性和显性、正式和非正式的需求和期望。应在信任和保密的环境下开展访谈，以获得真实可信、不带偏见的反馈。
          • 数据分析（成本效益分析+质量成本）
            • 成本效益分析
              • 成本效益分析（P282）达到质量要求的主要效益包括：减少返工、提高生产率、降低成本、提升相关方满意度、提升赢利能力。对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。
            • 质量成本（COQ）（P282）
              • 质量成本：在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求（返工），而发生的所有成本。
          • 决策（P283）
            • 多标准决策分析（如优先矩阵）
              • 可用于识别关键事项和合适的备选方案，并通过一系列决策排列出备选方案的优先顺序。
              • 在本过程中，它有助于排定质量测量指标的优先顺序。
          • 数据表现
            • 流程图（P284）
              • 流程图（过程图）：用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要的步骤顺序和可能分支。它展示了流程中的活动、决策点、分支循环、并行路径及整体处理顺序。
              • 可以通过分析流程图来估算质量成本。通过展示过程步骤，可帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方。
            • SIPOC模型（P285）
              • SIPOC模型：由戴明提出，用于组织流程管理和改进。通过分析，识别核心过程。戴明认为任何一个组织都是一个由供应者、输入、流程、输出、还有客户这样相互关联、互动的5个部分组成的系统。
              • SIPOC是Value Chain（价值链）的一种
            • 逻辑数据模型（P284）
              • 逻辑数据模型：把组织数据可视化，以商业语言加以描述，不依赖任何特定的软件开发技术。
              • 逻辑数据模型可用于识别会出现数据完整性或其他质量问题的地方。
              • 由于不涉及软件技术，所以项目经理、相关方都可以研究这份文件。如果发现与项目需求不符合、或其他问题就马上提出来。避免后续出现问题。
            • 思维导图（P284）
              • 思维导图：一种用于可视化组织信息的绘图法。
              • 可以从一个质量概念开始，开展发散性思维，快速收集项目质量要求、制约因素、依赖关系和联系等各种信息。
            • 矩阵图（P284）
              • 矩阵图：在行列交叉的位置展示因素、原因和目标之间的关系强弱。
              • 在本过程中，它们有助于识别对项目成功至关重要的质量测量指标。
          • 检查与测试的规划（P285）
            • 检查与测试的规划：在规划阶段项目经理和团队决定如何测试或检查产品、服务或成果。
            • 不同的行业有不同的检查和测试。
        • 输出：质量管理计划+质量测量指标
          • 质量管理计划（P286）
            • 质量管理计划：描述如何实施适用的政策、程序和指南以实现质量目标。描述项目管理团队为实现项目质量目标所需的活动和资源。
            • 包括质量政策、质量标准（国家标准/行业标准等）、质量目标（可量化的目标）、角色职责、相关活动、质量工具等等。应该在项目早期就对质量管理计划进行评审，以确保决策是基于准确信息的。
          • 质量测量指标（P287）
            • 质量测量指标：描述项目或产品属性，以及控制质量过程将如何验证符合程度。（属于“项目文件”）
            • 质量测量指标是对高层级的质量标准的具体化和可操作化。
    • ：规划质量管理（ITTO）， 输入 组织过程资产 ）+ 工具与技术 数据收集+数据分析+决策+数据表现+检查与测试的规划 ）+ 输出 质量管理计划+质量测量指标
      • 输入：组织过程资产（P281）
        • 执行组织的质量政策是高级管理层所推崇的，规定了组织在质量管理方面的工作方向。如果执行组织没有正式的质量政策，或项目涉及多个执行组织（如合资项目）。项目经理或项目管理团队就需要为项目制定质量政策。
    • 管理质量 管理质量的工作属于质量成本框架中的一致性工作。
      • what
    • ：管理质量，把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程
      • why
    • ：本过程的作用
      • 1、提高实现质量目标的可能性
      • 2、识别无效过程
      • 3、识别导致质量低劣的原因管理质量有时被称为“质量保证”，但“管理质量”的定义比“质量保证”更广
    • ：管理质量（ITTO）， 输入 （项目文件）+ 工具与技术 （数据收集+审计+数据分析+决策+数据表现+面向X的设计+问题解决+质量改进方法）+ 输出 （质量报告+测试与评估文件+变更请求）
      • 输入
    • 项目文件
      • 项目文件（P291）
        • 质量控制测量结果：用于分析和评估项目过程和可交付成果的质量是否符合执行组织的标准或特定要求；也有助于分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
        • 质量测量指标：依据这些质量测量指标设定项目的测试场景和可交付成果，用作改进举措的依据。
        • 风险报告：使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素，这些因素能够影响项目的质量目标。
        • 经验教训登记册：项目早期与质量管理有关的经验教训，可以运用到项目后期阶段，以提高质量管理的效率与效果。
    • 数据收集+审计+数据分析+决策+数据表现+面向X的设计+问题解决+质量改进方法
      • 数据收集（P292）
        • 核对单：一种结构化工具，通常列出特定组成部分。
        • 用途：2点
          • 1、核实所要求的一系列步骤（质量活动）是否已得到执行；
          • 2、检查需求列表是否已得到满足。质量核对单应该与范围基准中定义的验收标准保持协调一致。
    • 质量报告+测试与评估文件+变更请求
      • 质量报告（P296）
        • 关键内容：
          • 团队上报的质量问题
          • 针对项目、产品、过程的改善建议
          • 纠正措施建议（包括返工、缺陷/漏洞补救、100% 检查等）
          • 在控制质量过程中发现的情况的概述
        • 形式： 图形、数字、定性文件
        • 目的：帮助其他过程和部门采取纠正措施，以实现项目质量期望
    • 控制质量 ”P298
      • what
    • ：控制质量（ Quality Control，针对可交付成果）：为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程
      • why
    • ：本过程的作用
      • 1、核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收
      • 2、在整个项目期间应执行质量控制
      • 3、敏捷项目中：QC由全部成员、全生命周期执行
      • 4、瀑布模式中：特定成员在特定时间段或项目/阶段快结束时进行
      • 5、 以下行业QC更为严格：制药、医疗、运输、核能等
    • ：控制质量（ITTO），输入（项目文件+批准的变更请求+可交付成果）+工具与技术（数据收集+数据分析+检查+测试/产品评估）+输出（质量控制测量结果+核实的可交付成果+变更请求和项目文件更新）
      • 输入：项目文件+批准的变更请求+可交付成果
        • 项目文件（P300）
          • 质量测量指标：专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度（来自规划）。
          • 测试与评估文件：用于评估质量目标的实现程度（来自管理）。
          • 经验教训登记册：项目早期获得的经验教训，可以运用到项目后期阶段，以改进质量控制。
        • 批准的变更请求（P301）
          • 完成局部变更时，如果步骤不完整或不正确，可能会导致不一致和延迟。
          • 批准的变更请求的实施需要核实，并需要确认完整性、正确性，以及是否重新测试。
        • 可交付成果（P301）
          • 可交付成果：在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
          • 作为指导与管理项目工作过程的输出的可交付成果将得到检查，并与项目范围说明书定义的验收标准作比较。
    • ：有助于以结构化方式管理控制质量活动。
      • 核查表（ check sheets ）
    • ：用于合理排列各种事项，以便有效地收集关于潜在质量问题的有用数据
      • 在开展检查以识别缺陷时，用核查表收集属性数据就特别方便，例如关于缺陷数量或后果的数据。
      • 用核查表收集的关于缺陷数量或后果的数据，又经常使用帕累托图来显示。
      • 关键词：
        • 收集数据
        • 潜在质量问题
        • 缺陷数量或后果
        • 统计分析结果
    • 从目标总体中选取部分样本用于检查，抽样的频率和规模应在规划质量管理过程中确定。
      • 属性抽样：结果为合格或不合格（需要较多的样本）
      • 变量抽样：在连续的量表上标明结果所处的位置，表明合格的程度（需要专门人员进行）
    • 用于在部署产品或服务之后收集关于客户满意度的数据。
      • 数据分析（P303）
        • 绩效审查：针对实际结果，测量、比较和分析规划质量管理过程中定义的质量测量指标。
        • 根本原因分析（RCA）：用于识别缺陷成因。
      • 【区别】“确认范围”和“控制质量”汇总
        • 质量管理三个过程的区分
          • 规划质量“定标准”
          • 管理质量“管过程”（所有项目管理过程）QA
          • 控制质量“查结果”QC
        • 关于“如何避免”的选择
          • 客户发现了缺陷，事先应该做好“控制质量”QC
          • 控制质量发现了缺陷，事先应该做好“管理质量”QA
        • 控制质量时发现缺陷的处理方法
          • 如果是少数、部分可交付成果有缺陷，需要走变更流程做缺陷补救
          • 如果是大量可交付成果有缺陷，需要反思过程做好QA
      • 常见工具串讲
        • 公司最近人员离职略多，HR先判断离职人数有没有失控；（控制图）
        • 一个一个去判断各个可能的离职原因是否跟离职数量是否存在相关性；（散点图）
        • 将有关的原因导致的离职数量进行统计，形成计数表；（核查表）
        • 用更直观的工具来展示计数表，明确这些原因中的主要原因；（帕累托）
        • 把这些问题找到，一个一个放在鱼头的位置，分别看看根本原因出在什么地方；（鱼骨图）
      • 重点
        • 几个质量管理大师
        • 质量和等级、预防和检查、属性抽样和变量抽样、公差和控制界限的区别
        • 客户满意、持续改进、管理层的责任、与供应商的互利合作关系
        • 规划质量“定标准”，管理质量“管过程”，控制质量“查结果”
        • 规划质量的定义；工具中的成本效益分析、质量成本、流程图；输出管理质量的输入和工具（比较重要）
        • 控制质量的输入、工具和输出
    • 质量管理大师
      • 戴明
        • 原则内容1、持续改进产品和服务2、采用新的观念3、预防胜于检查4、质量成本85%都是管理问题5、结束只以价格为基础的采购习惯6、实行岗位职能培训7、建立领导力企业管理8、排除恐惧9、打破部门之间的障碍10、取消对员工的标语训词和告诫11、取消定额管理和目标管理12、消除打击员工工作情感的考评13、鼓励学习和自我提高14、采取行动实现转变
      • 朱兰
        • 质量螺旋（质量环） 强调质量是适合使用调研计划设计规格仪器 采购 工艺生产工序检验测试销售售后服务 调研适用性提出质量与等级的区别提出质量管理三部曲（质量计划、质量控制、质量改进）
      • 克鲁斯比
        • 强调质量是符合要求
        • 强调第一次就把事做对
        • 提出质量是免费的
        • 提出质量用非一致性成本衡量
      • 石川
        • 鱼骨图（因果图、石川图）
        • 提出质量圈
        • 总结质量七工具的使用
      • 田口玄一
        • 提出实验设计方法
        • 提出稳健设计方法
      • 【总结】
        • 戴明：PDCA环（休哈特提出，戴明完善）、质量管理14条原则（预防胜于检查、质量成本85%都是管理问题）
        • 朱兰：质量螺旋（质量环）、强调质量是适合使用、提出质量与等级的区别、提出质量管理三部曲（质量计划、质量控制、质量改进）
        • 克鲁斯比：提出零缺陷、强调质量是符合要求、强调第一次就把事做对、提出质量是免费的、提出质量用非一致性成本衡量
        • 石川：鱼骨图（因果图、石川图）、提出质量圈、总结质量七工具的使用
        • 田口玄一：质量损失函数、提出实验设计方法、提出稳健设计方法
      • 项目质量管理要兼顾项目管理与项目可交付成果两个方面
    • 核心概念
      • 【区别】质量与等级（P274）
        • 质量：作为实现的性能或成果，是一系列内在特性满足要求的程度。
        • 等级：作为设计意图，是对用途相同但技术特性不同的可交付成果的级别分类。
        • 高等级并不意味着一定高质量；
        • 低等级也并不意味着一定低质量；
        • 质量水平未达到质量要求肯定是个问题，而低等级不一定是个问题。项目经理及项目管理团队负责权衡，以便同时达到所要求的质量与等级水平。
      • 【区别】一些术语（P274）
        • 预防/检查
          • 检查：保证错误不落到客户手中
          • 预防：保证过程中不出现错误
        • 属性抽样/变量抽样
          • 属性抽样：结果为合格或不合格
          • 变量抽样：表明合格的程度
        • 公差/控制界限
          • 公差：结果的可接受范围
          • 控制界限：稳定过程的普通偏差的边界
      • 按有效性递增的五种质量管理水平（P275）
        • 1让客户发现缺陷
        • 2通过控制质量过程先检测和纠正缺陷，再交付客户
        • 3通过质量保证检查并纠正过程本身
        • 4将质量融入项目和产品的规划和设计中
        • 5在整个组织内创建一种关注并致力于实现过程和产品质量的文件
    • 趋势和新兴实践（P275）
      • 1、客户满意：了解、评估、定义和管理要求。符合要求+适合使用。敏捷中可确保始终做到客户满意
      • 2、持续改进：通过持续不断的小改进积累成大改进，往往比瞬间的大改进更有价值。PDCA环是质量改进的基础。全面质量管理（TQM）、六西格玛和精益六西格玛也可以提高质量。
      • 3、管理层的责任 85/15原则：管理者对质量负85%的责任，工人只有15%的责任。
      • 4、与供应商的互利合作关系：组织与其供应商相互依赖。组织应着眼于长期关系而不是短期利益。
      • 5、预防胜于检查：最好将质量设计到可交付成果中。质量是规划和实施出来的，不是检查出来的。
      • 6、质量成本（COQ）：一致性工作成本+非一致性工作成本；一致性工作是为预防工作出错而做的附加努力；非一致性工作是为纠正已经出现的错误而做的附加努力。
      • 7、反对“镀金” ：镀金不会增加项目价值，会造成较大机会成本；资源有限，只提供答应的东西。
      • 8、第一次就把事情做对（质量是免费的）：就是“零缺陷管理”，最节约成本的方法，虽不能绝对做到，但可不断接近。
      • 9、准时制（零库存）管理（JIT）：由于零库存，没有多余的材料，促使人们更注重质量，力争一次做对，力争零缺陷
      • 10、全面质量管理（TQM）：强调全过程的质量管理和全员参与质量管理。
    • 在敏捷和适应型环境中需要考虑的因素（P276）
      • 为引导变更，敏捷方法要求多个质量与审核步骤贯穿整个项目，而不是在面临项目结束时才执行。
      • 1、循环回顾，定期检查效果；
      • 2、寻找问题原因，建议改进方法；
      • 3、评估试验过程，确定措施。
      • 为促进频繁的增量交付，敏捷方法关注于小批量工作，目的是在项目生命周期早期发现不一致和质量问题。
    • 【补充】项目质量管理
      • 考虑以下几个问题
      • 1. 如果你在肯德基负责炸薯条，你如何保证炸出来的薯条的质量？
      • 2. 要满足质量要求，是不是只需要做好控制质量？
      • 3. 为什么很多大型企业都有自己的流程和规范，流程和规范的意义是什么？为什么需要遵守？
      • 规划质量“定标准”
  • 第九章 项目资源管理
    • ：规划过程组（规划资源管理+估算活动资源）+执行过程组（获取资源+建设团队+管理团队）+监控过程组（控制资源）
      • 规划过程组：规划资源管理+估算活动资源
        • 之一“规划资源管理”P312
          • what
          • How：
            • 工具与技术：数据表现(P316)
              • 本过程的数据表现格式分为：层级型、矩阵型、文本型。
              • 无论使用哪种格式，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理 解其角色和职责。
              • 层级型可用于表示高层级角色，文本型更适合用于记录详细职责。
              • 数据表现格式
                • 层级型
                • 责任分配矩阵
                  • 如果团队是由内部或外部人员组成，RACI矩阵对明确划分角色和职责特别有用(PMBOK317)
            • 输出：资源管理计划+团队章程
              • 资源管理计划(P318)
                • 资源管理计划
                  • 提供了关于如何分类、分配、管理和释放项目资源的指南。
                  • 可以根据项目的具体情况分为团队管理计划和实物资源管理计划。
                • 资源管理计划的内容(P318)
                  • 识别资源：识别和量化项目所需的团队和实物资源的方法。
                  • 获取资源：如何获取项目所需的团队和实物资源的指南。
                  • 角色与职责
                    • 角色:在项目中，某人承担的职务或分配给某人的职务。
                    • 职权:使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力。
                    • 职责:为完成项目活动，项目团队成员必须履行的职责和工作。
                    • 能力:为完成项目活动，项目团队成员需具备的技能和才干。
                  • 项目组织图：以图形方式展示项目团队成员及其报告关系。
                  • 项目团队资源管理----如何定义、配备、管理和最终遣散项目团队资源的指南。
                  • 培训：针对项目成员的培训策略。
                  • 团队建设：建设项目团队的方法。
                  • 资源控制：既确保资源充足可用，又确保库存合理的方法。
                  • 认可计划：何时给予团队成员哪些认可和奖励的说明。
              • 团队章程(基本规则)(P319)
                • 团队章程：为团队创造团队价值观、共识和工作指南的文件。
                • 团队章程对项目团队成员的可接受行为确定了明确的期望。
                • 尽早认可并遵守明确的规则，有助于减少误解，提高生产力。
                • 讨论诸如行为规范、沟通、决策、会议礼仪等领域，团队成员可以了解彼此重要的价值观
                • 团队制定或参与制定的团队章程可发挥最佳效果，并需要定期审查和更新。
        • 之二“估算活动资源”P320
          • what
    • ：规划资源管理：定义如何估算、获取、管理和利用团队以及实物资源的过程。
      • why
    • ：本过程的作用
      • 根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度。
      • 有效的资源规划需要考虑稀缺资源的可用性和竞争，并编制相应的计划。
      • 资源可以从组织内部资产获得，或者通过采购过程从组织外部获取。
    • 规划资源管理（ITTO），输入（项目文件）+工具与技术（数据表现）+输出（资源管理计划+团队章程）
      • 输入：项目文件(P314)
        • 项目进度计划：提供了所需资源的时间轴。
        • 需求文件：指出了项目所需的资源的类型和数量，并可能影响管理资源的方式。
        • 风险登记册：包含可能影响资源规划的各种威胁和机会的信息。
        • 相关方登记册：有助于识别对项目所需资源有特别兴趣或影响的那些相关方，以及会影响资源使用偏好的相关方。
    • (P316)
      • 层级型，可以采用传统的组织结构图，自上而下地显示各种职位及其相互关系。
        • 工作分解结构WBS ：可交付成果为导向的工作层级分解，有助于明确高层级的职责。
        • 组织分解结构OBS：组织的部门、单元或团队为导向的层级分解，有助于查看对应的全部项目职责
        • 资源分解结构RBS：资源的类别和类型为导向的层级分解，用于规划、管理和监控项目工作
    • (P317)
      • 展示项目资源在各个工作包中的任务分配。一个例子是职责分配矩阵(RAM)。
      • 在大型项目中，可以制定多个层次的RAM:高层次RAM 可定义项目团队、小组或部门负责WBS中的哪部分工作，低层次RAM 则可在各小组内为具体活动分配角色、职责和职权。
      • 矩阵图能：
        • 1、反应与每个人相关的所有活动;
        • 2、反应与每项活动相关的所有人员;
        • 3、确保任何一项任务都只有一个人负责，从而避免职责不清。
    • ：估算活动资源：估算执行项目所需的团队资源，以及材料、设备和用品的类型和数量的过程。
      • why
    • ：本过程的作用，明确完成项目所需的资源种类、数量和特性。估算活动资源过程与估算成本过程紧密相关。
      • How：
        • 输出：资源需求+估算依据+资源分解结构
          • 资源需求(P325)，识别了各个工作包或工作包中每个活动所需的资源类型、可用性、所需数量。
          • 估算依据(P326)，支持性文件，清晰完整地说明资源估算是如何得出的。
          • 资源分解结构(RBS)(P326)
            • 资源分解结构(RBS)：资源依类别和类型的层级展现。
            • 资源类别：人力、材料、设备和用品;
            • 资源类型：技能水平、要求证书、等级水平等。RBS有助于对资源进行获取、管理和报告。
    • 估算活动资源（ITTO）：输入（项目文件）+输出（资源需求+估算依据+资源分解结构）
      • 输入：项目文件(P322)
        • 活动属性：为每项活动所需的资源提供了主要的数据来源 活动清单----识别了需要资源的活动
        • 假设日志：有关生产力因素、可用性、成本估算以及工作方法的信息。
        • 成本估算：资源成本从数量和技能水平方面会影响资源选择。
        • 资源日历：具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。(哪些资源可用：人力、设备、材料等、何时可用、可用多久)。另外还需考虑更多的资源属性，例如，经验和 / 或技能水平、来源地和可用时间。
        • 风险登记册：可能影响资源选择和可用性的各个风险。
    • ：获取资源，获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。
      • why
    • ：本过程的作用，概述和指导资源的选择，并将其分配给相应的活动。
      • 本过程的注意事项:◆ 内部资源----从职能经理或资源经理处获得;外部资源----通过采购/租赁等途径获得。
      • ◆ 项目经理对资源没有直接控制权的情况:
      • 项目经理应进行有效谈判，并影响那些能为项目提供所需资源的人员。 ◆ 资源或人员能力不足会降低项目成功的概率，甚至可能导致项目取消。 ◆ 如因制约因素无法获得所需资源，项目经理可能不得不使用替代资源(也许能力较低)。
      • 1
    • 获取资源（ITTO），工具与技术（决策+人际关系与团队技能+预分派+虚拟团队）+输出（实物资源分配单+项目团队派工单+资源日历+事业环境因素更新）
      • 工具与技术：决策+人际关系与团队技能+预分派+虚拟团队
        • 决策：多标准决策分析(P332)
          • 使用多标准决策分析工具制定出标准;
          • 根据标准的相对重要性对标准进行加权;
          • 对于各项标准基于权重进行评级或打分;
          • 将各标准的打分进行汇总，得到最终的得分。
        • 人际关系与团队技能：谈判(协商)(P332)
          • 职能经理：确保项目在要求的时限内获得最佳资源;
          • 组织中其他项目管理团队：稀缺或特殊资源;
          • 外部组织：合适的、稀缺的、特殊的、合格的、经认证的或其他诸如此类的特殊人力资源;
        • 预分派(P333)
          • 预分派：事先确定项目的实物或团队资源。
          • 预分派的情况:
            • 1、竞标过程中承诺分派;
            • 2、项目取决于特定人员的专有技能;
            • 3、项目章程中指定;
        • 虚拟团队(P333)
          • 虚拟团队----具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。
          • 现代沟通技术使虚拟团队成为可行。在虚拟团队的环境中，沟通规划变得日益重要。
    • ：建设项目团队，是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。
      • why
    • ：本过程的作用， 改进团队协作，增强人际关系技能，激励员工，减少摩擦，提升整体项目绩效。(好->更好)
      • How
        • 输出：团队绩效评价+事业环境因素更新
          • 团队绩效评价(P343)
            • 基于项目技术成功度、项目进度绩效和成本绩效来评价团队绩效。
            • 评价团队有效性的指标可包括:
              • 1、个人技能的改进;
              • 2、团队能力的改进;
              • 3、团队成员离职率的降低;
              • 4、团队凝聚力的加强。
          • 事业环境因素更新(P344)，可能需要更新的有:员工发展计划的记录、技能评估。
    • ：建设团队（ITTO），工具与技术+输出
      • 工具与技术：集中办公+沟通技术+人际关系与团队技能+认可与奖励+培训+个人和团队评估
        • 集中办公(P340)，把许多或全部最活跃的项目团队成员安排在同一个物理地点工作，以增强团队工作能力，增进沟通、加强集体感，可以临时也可以贯穿整个项目。(比如“作战室”)
        • 沟通技术(P340)
          • 对于集中办公，营造一个融洽的环境;对于虚拟团队----促进更好地相互理解
          • 可采用的沟通技术包括:共享门户;视频会议;音频会议;电子邮件/聊天软件。
        • 人际关系与团队技能(P341)
          • 冲突管理----应及时地以建设性方式解决冲突。
          • 影响力----收集相关的关键信息，在维护相互信任的关系时，来解决重要问题并达成一致意见。
          • 激励----为某人采取系行动提供了理由。提高团队参与决策的能力并鼓励他们独立工作。
          • 谈判----有助于达成共识，在彼此之间建立融洽的相互信任的关系。
          • 团队建设----通过举办各种活动，强化团队的社交关系，打造积极合作的工作环境。可以是五分钟议程，也可以是专业提升活动。在项目前期必不可少，是个持续的过程。对于虚拟团队，更要加强团队建设活动。
        • 认可与奖励(P341)
          • 当人们感受到自己在组织中的价值，并且可以通过获得奖励来体现这种价值，他们就会受到激励。
          • 最初的奖励计划是在规划人力资源管理过程中编制的。
          • 只有能满足被奖励者的某个重要需求的奖励，才是有效的奖励。决定认可与奖励时，应考虑文化差异。
          • 可以正式或非正式的方式做出奖励决定。但不要授权别人颁发奖励，以免被人误认为不重视。
          • 通常，金钱是奖励制度中的有形奖励，然而也存在各种同样有效、甚至更加有效的无形奖励。
          • 应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时。
        • 培训(P342)
          • 培训，包括旨在提高项目团队成员能力、减少成员之间的差异的全部活动。
          • 如果项目团队成员缺乏必要的管理或技术技能，可以把对这种技能的培养作为项目工作的一部分。
          • 培训成本通常应该包括在项目预算中(或由执行组织承担)。
          • 培训可以由内部或外部培训师来执行。
        • 个人和团队评估(P342)
          • 个人和团队评估工具能让项目经理洞察团队成员的优势和劣势，评估他们的偏好和愿望。有利于增进团队成员间的理解、信任、承诺和沟通，在整个项目期间不断提高团队成效。
          • 360度反馈(360度绩效考核法、全方位考核法)，最早由英特尔首先提出并加以实施。指由员工自己、上司、直接部署、同仁同事甚至顾客等全方位的个人角度来了解个人的绩效:沟通技巧、人际关系、领导能力、行政能力等等。通过这种理想的绩效评估，被评估者可从多种角度、不同的反馈中清楚自己的不足长处与发展需求，使以后的职业发展更为顺畅。
    • ：管理团队，是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。
      • why
    • ：本过程的作用:影响团队行为，管理冲突，解决问题。(不好->好)
      • How：管理团队（ITTO），输入（项目文件）+工具与技术（人际关系与团队技能）
        • 输入：项目文件(P347)
          • 团队章程：为团队应如何决策、举行会议和解决冲突提供指南。
        • 工具与技术：人际关系与团队技能
          • 人际关系与团队技能—冲突管理(P348)
            • 冲突不可避免，冲突的来源:
              • 1、资源稀缺;
              • 2、进度优先级排序;
              • 3、个人工作风格差异;
              • 4、性格差异
            • 冲突管理的解决步骤:
              • 1、首先由项目团队成员负责解决;
              • 2、冲突升级，项目经理应提供协助(私下处理);
              • 3、如果破坏性冲突继续存在，则可使用正式程序，包括采取惩戒措施
            • 五种常用的冲突解决方法(P349)
              • 撤退/回避:退出冲突、将问题推迟或推给他人解决。
              • 缓和/包容(安抚、圆滑、smooth):强调一致而非差异，考虑其他方的需要。(求同存异)
              • 妥协/调解:部分解决问题，一定程度上满意。
              • 强迫/命令:推行某一方的观点，通常是利用权力来强行解决紧急问题。
              • 合作/解决问题:综合考虑不同的观点和意见，合作的态度和开放式对话，引导各方达成共识和承诺。(最佳方式)
          • 人际关系与团队技能(P349)
            • 决策：包括谈判能力以及影响组织与项目管理团队的能力，而不是决策工具。
            • 决策方式
              • Command 命令;
              • Consultation 咨询;
              • Consensus 协商(全体表决、达成众议);
              • Coin flip 随机(抛硬币)
            • 情商
              • 识别、评估和管理个人情绪、他人情绪及团体情绪的能力。
              • 通过情商来识别、评估及控制项目团队成员的情绪，预测他们的行动，理解他们的焦虑，帮着解决他 们的问题，从而减缓紧张，增进合作。
            • 影响力
              • 1、说服他人;
              • 2、清晰表达观点和立场;
              • 3、积极且有效的倾听;
              • 4、了解并综合考虑各种观点;
              • 5、解决问题并达成一致意见。
            • 领导力
              • 领导团队、激励团队做好本质工作的能力。
              • 有多种领导力理论，定义了适用于不同情形或团队的领导风格。
    • ：控制资源，是确保按计划为项目分配实物资源，以及根据资源使用计划监督资源实际使用情况，并采取必要纠正措施的过程。
      • why
    • ：本过程的作用:确保所分配的资源适时适地可用于项目，且在不再需要时被释放。控制资源过程关注实物资源;管理团队过程关注团队成员。
      • How
    • ：控制资源（ITTO），工具与技术（数据分析+人际关系与团队技能+项目管理信息系统）
      • 工具与技术：数据分析+人际关系与团队技能+项目管理信息系统
        • 数据分析(P356)
          • 备选方案分析----选择最佳解决方案以纠正资源使用偏差，可以将加班和增加团队资源等备选方案与延期交付或阶段性交付相比较，以权衡利弊。
          • 成本效益分析----寻找既能解决问题而又节省成本的纠正措施。绩效审查----测量、比较和分析计划的资源使用和实际资源使用的不同。分析成本和进度工作绩效信息有助于指出可能影响资源使用的问题。
          • 趋势分析----基于当前绩效信息来确定未来项目阶段所需的资源。趋势分析检查项目绩效随时间的变化情况，可用于确定绩效是在改善还是在恶化。
        • 人际关系与团队技能(P357)
          • 谈判----项目经理可能需要就增加实物资源、变更实物资源或资源相关成本进行谈判。
          • 影响力----有助于项目经理及时解决问题并获得所需资源。
        • 项目管理信息系统PMIS(P357)
          • 包括资源管理或进度计划软件，可用于监督资源的使用情况，帮助确保合适的资源适时适地用于合适的活动。
      • 【重点】
        • 几个激励理论
        • 规划资源管理的工具RAM(RACI)，输出
        • 了解估算活动资源
        • 获取资源的3个注意点，工具和输出
        • 塔克曼模型
        • 建设团队的工具和输出
        • 管理团队的输入(团队章程)，工具(冲突管理)
    • 课前知识
      • 了解几个激励理论
        • 马斯洛的需求层次理论
          • 人有五个层次的需求，从最低等级到最高等级依次是:生理需求、安全需求、 社交需求、尊重需求、自我实现需求。通常，人们只有在较低层次的需求得到满足后，才会追求较高层次 的需求。
        • 赫兹伯格：双因素理论
          • 赫兹伯格的双因素理论----有两类因素(保健因素和激励因素)会决定人的行为。保健因素----是导致不满足感的因素，这些因素做得好不会提高激励，做得不好就会损害激励。
          • 比如:工作环境或条件、工资、同事或上下级之间关系、个人生活、安全、地位、职务等;
          • 相当于马斯洛需求层次理论的较低层次的需求(生理需求、安全需求、社交需求)激励因素----是导致满足感的因素，能够真正起激励作用的。
          • 比如:成就感、责任感、得到任何和赞赏、挑战性和兴趣、发展前途、个人成长等;相当于马斯洛需求层次理论的较高层次的需求(尊重需求、自我实现需求)
        • 麦格雷戈:X理论和Y理论
          • 麦格雷戈的X理论----认为人是消极懒惰的，缺乏进取心，总是逃避责任(传统管理偏向此“人性本惰”论)麦格雷戈的Y理论----认为人是积极的，愿意进步，愿意承担责任(现代管理偏向此“人性本善”论)X理论认为只能用低层次的需求进行激励；Y理论认为人更应该受到高层次需求的激励。
        • 大内的Z理论
          • 大内的Z理论----主要观点是:终身雇佣制、缓慢的评价和晋升、分散与集中决策、含蓄的控制但检测手段明确正规、融洽管理人员与员工的关系，让员工得到多方面的锻炼。
        • 弗鲁姆的期望理论
          • 一种行为倾向的强度取决于个人对于这种行为可能带来的结果的期望度，以及这种结果对个人的吸引力。M=V×E； M—激励；V—行动结果的价值评价；E—行动结果的期望值；比如：一个人认为努力工作会带来成功的结果，而这种成功又会带来相应的回报，他就会受到激励努力工作。
        • 麦克利兰：成就动机理论
          • 麦克利兰的成就动机理论：各人在不同程度上有这三种需要:成就需要、权力需要、亲和需要。管理者应 根据个人更重视的需要来制定激励措施，例如：为成就需要者设立具有挑战性但可实现的目标;为权力需要 者提供较能体现地位的工作环境;为亲和需要者提供合作而非竞争的工作环境 。
      • 了解几个概念：边际福利、额外待遇、光环效应
        • 边际福利：所有员工都可享受的福利，与员工的业绩好坏没有直接关系。用来保障员工的经济安全性，使他们无后顾之忧。属于保健因素，如:五险一金、基础培训等。
        • 额外待遇：给某些员工的特殊奖励，主要用来奖励优秀员工。属于激励因素。如:固定的停车位、靠窗的办公室、与总经理一起吃午饭等。
        • 光环效应：因一个人在某个方面表现好，人们就理所当然地认为他在其他方面也会表现好。要防止光环效应。如:指定一个优秀的技术专家当项目经理。
      • 了解项目经理的管理风格(对事)
        • 独裁型(专制型)：领导严格控制+独自决断
        • 民主型(参与型)：团队成员参与决策+项目上用得最多
        • 放任型(自由型)：对员工放任自流+进行松散式管理
      • 了解项目经理的几种权力(Power)
        • 专家权力
        • 参照权力（潜示权力）
        • 奖励权力
        • 正式权力（法定权力）
        • 惩罚权力
    • 核心概念
      • 两大类资源(P309)
        • 团队资源：既人力资源。项目团队成员可能具备不同的技能，可能是全职或兼职的，可能随项目进展而增加或减少
        • 实物资源：包括设备、材料、设施和基础设施
      • 项目经理的定位(P309)
        • 管理者：负责启动、规划、执行、监控和关闭等各阶段的项目管理;负责建设高效的团队。
        • 领导者：负责积极培养团队的技能和能力;负责提高并保持团队的满意度和积极性。
        • 职业道德：自己——留意并支持职业与道德行为;团队——确保所有成员都遵守这些行为。
    • 趋势和新兴实践
      • 项目管理风格的变化
        • 过去：命令和控制
        • 现在：协作和支持，授权团队成员寻求优化资源使用
      • 几种实践(P310)
        • 资源管理方法：出现了精益管理、准时制 (JIT) 生产、Kaizen(持续改善)、全员生产维护 (TPM)、约束理论
        • 情商(EI)：项目经理应提升，内在(如自我管理和自我意识；外在(如管理管理)。
        • 自组织团队：由通用的专才而不是主题专家组成，无需集中管控运作。PM为团队创造环境、提供支持并信任团队。
        • 虚拟团队/分布式：
          • 优势:项目团队可分布在不同地理区域;可将在家办公的、行动不便者或残疾人纳入团队
          • 挑战:沟通
    • 在敏捷和适应型环境中需要考虑的因素(P311)
      • 最大限度地集中和协作的团队结构(如拥有通才的自组织团队)有利于易变性高的项目。
      • 协作型团队的优势：
        • 1、促进不同工作活动的加速整合；
        • 2、改善沟通；
        • 3、增加知识分享；
        • 4、提供工作分配的灵活性；
      • 由于易变性高的项目在实物和人力资源规划的可预测性方面要低得多，因此快速供应和精益方法，对控制成本和实现进度而言至关重要。
    • 项目资源管理过程
      • 执行过程组：获取资源+建设团队+管理团队
        • 之三“获取资源”P328
          • what
          • How：
            • 输出：实物资源分配单+项目团队派工单+资源日历+事业环境因素更新
              • 实物资源分配单(P333)，记录了项目将使用的材料、设备、用品、地点和其他实物资源。
              • 项目团队派工单(P334)，记录了团队成员及其在项目中的角色和职责，可包括项目团队名录。
              • 资源日历(P334)，识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。规定了在项目期间确定的团队和实物资源何时可用、可用多久。
              • 事业环境因素更新(P335)，需要更新的事业环境因素包括(但不限于):组织内资源的可用性;组织已使用的消耗资源的数量。
          • 团队发展的模型：塔克曼阶梯理论(P338)
            • 形成阶段:相互认识、相互独立，不一定开诚布公;
            • 震荡阶段:冲突、矛盾、不同的观点和意见;
            • 规范阶段:开始协同工作、开始相互信任;
            • 成熟阶段:组织有序、相互依靠、平稳高效;
            • 解散阶段:释放人员，解散团队
            • 尽管这些阶段通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕见。
            • 如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。(可进可退可停)
        • 之四“建设团队”P336
          • what
        • 之五“管理团队”P345
          • what
      • 监控过程组：控制资源
        • 之六“控制资源”P352
          • what
  • 第十章 项目沟通管理
    • 5C原则可以减轻但无法消除理解错误
      • correct：正确的语法和拼写
      • concise：简洁的表述和无多余字
      • clear：清晰的目的和表述
      • coherent：连贯的思维逻辑
      • controlling：受控的语句和想法承接
      • 趋势和新兴实践：项目管理风格的变化(P364)
        • 将相关方纳入项目评审范围，定期对项目相关方群体的成员进行评审，识别是否还是利益方，以及态度的变化，并顺变管理策略
        • 让相关方参加项目会议，如敏捷中的每日站会。站会上，项目团队和主要相关方就前一天的成绩和问题以及当天的工作计划展开讨论。
        • 社交工具的使用日益增多，社交媒体工具不仅能支持信息交换，而且也有助于建立更深层次的信任和社群关系。
        • 多面性沟通方法，考虑所有可用技术，尊重因文化、实践和个人背景而产生的对沟通方式的偏好。根据需要采用社交媒体和其他电脑技术，与不同年代和文化背景的相关方沟通。
      • 在敏捷或适应型环境中需考虑的因素(P365)
        • 1、简化团队成员获取信息的通道;
        • 2、频繁进行团队检查;
        • 3、让团队成员集中办公
        • 4、以透明的方式发布项目工件，让领导和相关方指导;
        • 5、定期邀请相关方评审项目工件
      • 项目沟通管理过程：规划过程组（
        • 执行过程组：管理沟通
          • 之二“管理沟通”P379
            • what
        • 监控过程组：监督沟通
          • 之三“监督沟通”P388
            • what
            • How
              • 输出：变更请求(P393)
                • 本过程产生的变更请求可能导致:
                  • 1、修正相关方的沟通要求;
                  • 2、建立消除瓶颈的新程序。
    • 规划沟通管理 ）+执行过程组 （管理沟通） +监控过程组 （监督沟通）
      • 规划过程组：规划沟通管理
        • 之一“规划沟通管理”P366
          • what
          • How
            • 工具与技术：沟通需求分析+沟通技术+沟通模型+沟通方法+人际关系与团队技能
              • 沟通需求分析(P369)
                • 沟通需求分析----分析沟通需求，确定项目相关方的信息需求，包括所需信息的类型和格式，以及信息对相关方的价值。
                • 沟通渠道:计算公式----n(n-1)/2 根据题干具体描述，注意判断是否包含项目经理，以及是“增加到”还是“增加了”。
              • 沟通技术(P370)
                • 沟通技术，用于项目相关方之间交换信息和协作的特定工具、系统或计算机程序等。
                • 常见方法包括对话、会议、书面文件、数据库、社交媒体和网站。
                • 可能影响沟通过技术选择的因素包括:
                  • 1、紧迫性:信息需要的紧急程度
                  • 2、可用性/可靠性:技术的可获取性
                  • 3、易用性:项目团队是否会使用该技术
                  • 4、项目环境:是同地办公，还是虚拟团队;时区、语言、文化等
                  • 5、敏感性和保密性:是否需要额外的安全措施
              • 沟通模型(P371)
              • 沟通方法(P374)
                • 互动沟通
                  • 在两方或多方之间进行实时多向信息交换。 确保全体参与者达成共识的最有效的方法。
                  • 例如:会议、电话、即时 通信、视频会议等
                • 拉式沟通
                  • 用于信息量很大或受众很多的情况。要求接收者自主自行地访问信息内容。
                  • 例如：企业内网、经验教训数据库、知识库等
                • 推式沟通
                  • 把信息发送给需要接收这些信息的特定接收方。
                  • 可以确保信息的发送，但不能确保信息送达受众或被目标受众理解。
                • 人际沟通--个人之间交换信息，通常面对面;
                • 小组沟通--在三到六名人员的小组内部开展;
                • 公众沟通--单个演讲者面向一群人。
                • 大众传播--信息发送人员或小组与大量目标受众(有时为匿名)之间只有最低程度的联系。
                • 网络和社交工具沟通--借助社交工具和媒体，开展多对多的沟通。
              • 人际关系与团队技能(P375)
                • 沟通风格评估
                  • 规划沟通活动时，用于评估沟通风格并识别偏好的沟通方法、形式和内容的技术。
                  • 这种技术常用于不支持项目的相关方。
                  • 可以先开展相关方参与度评估，再开展沟通风格评估。
                • 政治意识
                  • 对正式或非正式权力关系的认知，以及在这些关系中工作的意愿。
                  • 政治意识有助于项目经理根据项目环境和组织的政治环境来规划沟通。
                • 文化意识
                  • 理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。
                  • 文化意识有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划
            • 输出：沟通管理计划(P377)
              • 项目沟通管理计划，描述将如何规划，结构化、执行与监督项目沟通，以提高沟通的有效性。包含如下内容：
                • 01相关方的沟通需求
                • 02需要沟通的信息，包括语言、格式、内容、详细程度
                • 03发布信息及告知收悉或做出回应(如适用)的时限和频率;
                • 04负责授权保密信息发布的人员；负责沟通相关信息的人员；
                • 05将要接收信息的人员或群体;
                • 06为沟通活动分配的资源，包括时间和预算
                • 07问题升级程序，用于规定下层员工无法解决问题时的上报时限和上报路径;
                • 08通用术语表，可以包括用户沟通的指南和模板。
    • ：规划沟通管理：基于每个相关方或相关方群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。
      • why
    • ：本过程的作用
      • 根据相关方需求、组织实际条件、项目的情况，制定合适的项目沟通计划，使得项目沟通效率高、效果好。
      • 需在项目生命周期的早期，针对项目相关方多样性的信息需求，制定有效的沟通管理计划。
      • 在整个项目期间，定期审查规划沟通管理过程的成果并做必要修改，以确保其持续适用。
    • ：规划沟通管理（ITTO），输入（项目文件）+工具与技术（沟通需求分析+沟通技术+沟通模型+沟通方法+人际关系与团队技能）+输出（沟通管理计划）
      • 输入：项目文件(P368)
        • 相关方登记册----用于规划与相关方的沟通活动。
    • ：管理沟通，确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。
      • why
    • ：本过程的作用，促成项目团队与相关方之间的有效信息流动。
      • How
        • 工具与技术：项目报告发布(P385)
          • 项目报告发布是收集和发布项目信息的行为。项目信息应发布给众多相关方群体。
          • 应针对每种相关方来调整项目信息发布的适当层次、形式和细节。
          • 从简单的沟通到详尽的定制报告和演示，报告的形式各不相同。
        • 输出：项目沟通记录(P387)
          • 可包括:绩效报告、可交付成果的状态、进度进展、产生的成本、演示，以及相关方需要的其他信息。
    • ：管理沟通（ITTO），输入（工作绩效报告）+工具与技术（项目报告发布）+输出（项目沟通记录）
      • 输入：工作绩效报告(P382)
        • 根据沟通管理计划的定义，工作绩效报告会通过本过程传递给项目相关方。
        • 典型示例包括状态报告和进展报告。
        • 可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息以及风险概述信息。
        • 可以表现为有助于引起关注、制定决策和采取行动的仪表指示图、热点报告、信号灯图或其他形式。
    • ：监督沟通，确保满足项目及其相关方的信息需求的过程。
      • why
    • ：本过程的作用
      • 按沟通管理计划和相关方参与计划的要求优化信息传递流程。
      • 通过监督沟通过程，来确定沟通确实提高或保持了相关方对项目的支持度。
      • 对沟通结果应该认真评估，确保在正确的时间、正确的渠道、把正确的内容发给正确的人，并产生正确的影响。
      • 监督沟通过程可能触发规划沟通管理和管理沟通过程的迭代，以便修改沟通计划并开展额外的沟通活动，来提升沟通的效果。
    • ：监督沟通（ITTO），工具与技术（人际关系与团队技能）+输出（变更请求）
      • 工具与技术：人际关系与团队技能(P392)
        • 适用于本过程的人际关系与团队技能包括:观察和交谈。
        • 通过观察和交谈，项目经理能够发现团队内的问题、人员间的冲突、或个人绩效问题。
      • 【重点】
        • 只有“信息交换”的问题，才是沟通问题，例如：信息多发(很多无关邮件)、少发(没有收到信息)、迟发(听到消息很惊讶)、看不懂(汉谟拉比法典)、不方便阅读、虚拟团队等都很可能是沟通问题。
        • 沟通策略是根据相关方登记册为不同的相关方量身定制的，注意迎合偏好
        • 规划沟通的几个重要工具：沟通需求分析、沟通方法、沟通风格评估
        • 规划沟通的输出：沟通管理计划有沟通
        • 管理沟通：拿着“工作绩效报告”，做“项目报告发布”(汇报)，得到“沟通记录”
        • 监督沟通：如有需要，输出变更请求，调整沟通管理计划
    • 核心概念：信息交换+沟通的划分维度+沟通+传统书面沟通的5C原则
      • 信息交换(P360)
        • ⚫ 梅拉宾法则(7%-38%-55% 规律 )
        • ➢ 任何面对面的沟通都存在三个基本因素:Words 词语 7%
        • Tone of voice 语气语调 38%
        • Nonverbal behavior (e.g. facial expression)非语言行为(如表情)55%
        • ➢ 两个结论:
        • 1. 在对感觉和态度的沟通上，非语言元素更为重要。
        • 2. 尤其是出现矛盾时:如果词语和语气语调、非语言行为产生冲突，人们倾向于相信后者。
      • 沟通的划分维度(P361)
        • 内部/外部
          • 内部:项目内
          • 外部:客户、供应商、其他项目、组织、公众
        • 正式/非正式
          • 正式:报告、会议记录、简报
          • 非正式:电子邮件、备忘录...
        • 垂直/水平
          • 垂直:上下级之间
          • 水平:同级之间
        • 官方/非官方
          • 官方:新闻通讯、年报，官方的沟通最能反映组织的真实意图
          • 非官方:私下沟通
        • 口头语言/非口头语言
          • 口头语言:占比45%
          • 非口头语言:占比55%
        • 书面/口头
          • 书面:书面沟通有助于解决复杂问题
          • 口头:
      • 沟通
        • 通过沟通活动(如会议和演讲)，或以工件的方式(如电子邮件、社交媒体、项目报告或项目文档)等各种可能的方式来发送或者接收信息。
        • 项目经理的大多数时间用于与团队成员、组织内部、组织外部的项目相关方沟通。
        • 项目沟通管理由两部分组成:
          • 1、制定策略，确保沟通对相关方行之有效;
          • 2、执行必要的活动，以落实沟通策略。
        • 在项目沟通中，需要尽力预防理解错误和沟通错误，并从规划过程所规定的各种方法、发送方、接收方和信息中做出谨慎选择。
      • 传统书面沟通的5C原则(P363)
  • 第十一章 项目风险管理
    • 规划风险管理+识别风险+实施定性风险+实施定量风险分析+规划风险应对 ）+执行过程组 （实施风险应对） +监控过程组 （监督风险）
      • 规划过程组：规划风险管理+识别风险+实施定性风险+实施定量风险分析+规划风险应对
        • 之一“规划风险管理”P401
          • what
          • 【补充】“RBS”示例
          • 【补充】“影响量表”示例
        • 之二“识别风险”P409
          • what
          • How
            • 输出：风险登记册+风险报告
              • 风险登记册(P417)
                • 风险登记册，记录已识别单个项目风险的详细信息。
                • 随着其他风险管理过程的实施，风险登记册还将包括这些过程的输出，其中的信息种类和数量也就逐渐增加。
                  • 风险登记册的编制始于识别风险过程。
                  • 完成识别风险过程时，风险登记册包括如下信息:
                    • 已识别风险清单，要以所需的详细程度对已识别风险进行描述，确保明确理解。
                    • 潜在风险责任人，记录识别出的潜在风险责任人，随后由实施定性风险分析过程进行确认。
                    • 潜在应对措施清单，记录识别出的潜在风险应对措施，随后由规划风险应对过程进行确认。
              • 风险报告(P418)
                • 风险报告：提供关于整体项目风险的来源、已识别的单个项目风险的概述信息。编制需要渐进式。
        • 之三“实施定性风险分析”P419
          • what
          • How
        • 之四“实施定量风险分析”P428
          • what
          • How
            • 输出：项目文件更新(P436)
              • 更新风险报告，反应定量风险分析的结果。
                • 对整体项目风险敞口的评估结果
                • 项目详细概率分析的结果
                • 单个项目风险优先级清单
                • 定量风险优先级清单
                • 风险应对建议
        • 之五“规划风险应对”P437—P439
          • what
          • How
            • 输出：项目文件更新+变更请求+项目管理计划更新
              • 项目文件更新(P448)
                • 风险登记册
                  • 1、商定的应对策略、实施应对策略所需的具体行动;
                  • 2、风险发生的触发条件、征兆和预警信号;
                  • 3、实施所选应对策略所需的预算和进度活动;
                  • 4、应急计划、弹回计划、残余风险、次生风险;
                • 风险报告
                  • 1、针对当前整体项目风险敞口和高优先级风险的经商定的应对措施;
                  • 2、实施这些措施后的预期变化;
              • 变更请求(P447)
                • 规划风险应对后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求。
                • 应该通过实施整体变更控制过程对变更请求进行审查和处理。
              • 项目管理计划更新(P447)
                • 进度管理计划:对进度管理计划的变更，包括:资源负荷和资源平衡变更，或进度策略更新等。
                • 成本管理计划:对成本管理计划的变更，包括:成本会计、跟踪和报告变更，以及预算策略和应急储备使用方法更新等。
                • 质量管理计划:对质量管理计划的变更，包括:满足需求的方法、质量管理方法，或质量控制过程的变更等。
                • 资源管理计划:对资源管理计划的变更，包括:资源配置变更，以及资源策略更新等。
                • 采购管理计划:对采购管理计划的变更，包括:自制或外购决策或合同类型的更改等。
                • 范围基准:如果商定的风险应对策略导致了范围变更，且这种变更已经获得批准，那么就要对范围基准做出相应的变更。
                • 进度基准:如果商定的风险应对策略导致了进度估算变更，且这种变更已经获得批准，那么就要对进度基准做出相应的变更。
                • 成本基准:如果商定的风险应对策略导致了成本估算变更，且这种变更已经获得批准，那么就要对成本基准做出相应的变更。
    • ：规划风险管理，定义如何实施项目风险管理活动的过程。
      • why
    • ：本过程的作用：确保风险管理的水平、方法和可见度与项目风险程度，及项目对组织和其他相关方的重要程度相匹配。
      • How
        • 工具与技术：数据分析(P404)
          • 相关方分析：通过相关方分析确定项目相关方的风险偏好。
        • 输出：风险管理计划(P405-P408)
          • 风险管理计划：描述如何安排与实施风险管理活动。(风险管理计划无风险)。
          • 管理计划的内容:
            • 风险管理战略、方法论、资金、时间安排
            • 角色与职责：确定每项风险管理活动的领导者、支持者和团队成员，并明确他们的职责。
            • 风险类别：确定对单个项目风险进行分类的方法，通常借助风险分解结构(RBS) 来构建风险类别。
          • 风险分解结构(RBS)，是潜在风险来源的层级展现。有助于项目团队考虑单个项目风险的全部可能 来源，对识别风险或归类已识别风险特别有用。
          • 相关方风险偏好：应该针对每个项目目标，把相关方的风险偏好表述成可测量的风险临界值。
          • 风险概率和影响定义：根据具体的项目环境、组织和关键相关方的风险偏好和临界值，来制定风险概率和影响定义。项目可能自行制定具体定义，或者用组织提供的通用定义作为出发点。
          • 概率和影响矩阵：把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。通常由组织来设定概率和影响的各种组合，并据此设定高、中、低风险级别。
          • 报告格式、跟踪。
    • ：规划风险管理（ITTO），输入（项目章程+项目文件）+工具与技术（数据分析）+输出（风险管理计划）
      • 输入：项目章程和项目文件(P402~403)
        • ◼ 项目章程----项目章程中有高层级的风险。
        • ◼ 相关方登记册----包含项目相关方的详细信息，并概述其在项目中的角色和对项目风险的态度;可用于确定项目风险管理的角色和职责，以及为项目设定风险临界值。
    • ：识别风险，识别单个项目风险以及整体项目风险的来源，并记录风险特征的过程。
      • why
    • ：本过程的作用
      • 记录现有的单个项目风险，以及整体项目风险的来源。
      • 汇集相关信息，以便项目团队能够恰当应对已识别的风险。
        • 应鼓励所有项目相关方参与单个项目风险的识别工作。
        • 项目团队的参与尤其重要，以便培养和保持他们对风险管理的主人翁意识和责任感。
        • 可以在识别风险过程中为单个项目风险指定风险责任人，待实施定性风险分析过程确认。
        • 可以识别和记录初步的风险应对措施，待规划风险应对过程审查和确认。
        • 识别风险是一个迭代的过程。迭代的频率和每次迭代所需的参与程度应在风险管理计划中做出规定。
    • ：识别风险（ITTO），工具与技术（数据收集+数据分析+人际关系与团队技能+提示清单）+输出（风险登记册+风险报告）
      • 工具与技术：数据收集+数据分析+人际关系与团队技能+提示清单
        • 数据收集（头脑风暴+访谈+核对单）(P414)
          • 头脑风暴
            • 可以采用自由或结构化的形式开展头脑风暴，在引导者的指引下产生各种创意。可以用风险类别(如RBS)作为识别风险的框架。
          • 访谈
            • 应该在信任和保密的环境下开展访谈，以获得真实可信、不带偏见的意见
          • 核对单(有具体的风险)
            • 是包括需要考虑的项目、行动或要点的清单，常被用作提醒。
            • 基于从类似项目和其他信息来源积累的历史信息和知识来编制核对单。
            • 因不能穷尽所有风险，所以必须确保不要用核对单来取代所需的风险识别工作；另外也应注意考察未在核对单中列出的事项。
        • 数据分析(P415)
          • 根本原因分析
            • 常用于发现导致问题的深层原因并制定预防措施。
            • 问题陈述作为出发点，识别威胁；
            • 收益陈述作为出发点，识别机会；
          • 假设条件和制约因素分析
            • 从假设条件的不准确、不稳定、不一致或不完整，识别威胁；
            • 通过清除或放松会影响项目过程执行的制约因素，创造机会；
          • 文件分析
            • 对项目文件的结构化审查，识别风险。
          • SWOT分析
            • SWOT--优势Strength、劣势Weakness、机会Opportunity、威胁Threat
            • 1. 关注项目、组织或一般业务领域，识别出组织的优势和劣势；
            • 2. 找出优势可能会带来的机会，劣势可能造成的威胁；
            • 3. 分析优势能在多大程度上克服威胁，劣势是否会妨碍机会产生。
        • 人际关系与团队技能(P416)
          • 引导，能提高用于识别单个项目风险和整体项目风险来源的许多技术的有效性。
        • 提示清单(P416)
          • 提示清单，是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。
          • 可以用风险分解结构(RBS)底层的风险类别作为提示清单。
          • 识别单个项目风险的框架：提示清单
          • 识别整体项目风险的框架：PESTLE+TECOP+VUCA
            • PESTLE(政治、经济、社会、技术、法律 、环境)
            • TECOP(技术、环境、商业、运营、政治)
            • VUCA(易变性、不确定性、复杂性、模糊性)
    • ：实施定性风险分析，通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。
      • why
    • ：本过程的作用，重点关注高优先级的风险。
      • 由于相关方对风险的感知程度不同，因此会导致评估时出现主观性的偏见。
      • 克服方法是：1、注意找出偏见并加以纠正；2、评估单个项目风险的现有信息的质量。
      • 另外，本过程还会确认每个风险的责任人，这个人负责后续的工作，包括制定和落实应对措施。
      • 在整个项目生命周期中要定期开展实施定性风险分析过程。
      • 在敏捷开发环境中，实施定性风险分析过程通常要在每次迭代开始前进行。
      • 本过程完成后，可进入实施定量风险分析过程或直接进入规划风险应对过程。
    • ：实施定性风险分析（ITTO），工具与技术（数据分析+风险分类+数据表现）+输出
      • 工具与技术：数据分析+风险分类+数据表现
        • 数据分析(P423)
          • 风险数据质量评估，旨在评价关于单个项目风险的数据的准确性和可靠性。
            • 可以开展问卷调查，了解项目相关方对数据质量各方面的评价。
            • 可以计算数据的完整性、客观性、相关性和及时性等方面的加权平均数，作为数据质量的总体分数
          • 风险概率和影响评估
            • ----风险概率评估考虑的是特定风发生的可能性；
            • ----风险影响评估考虑的是风险对项目目标(如进度、成本、质量或绩效)的潜在影响(消极和积极)。
            • 对已识别的每个风险都要进行概率和影响评估。
            • 可以选择熟悉相应风险类别的人员，以访谈或会议的形式进行风险评估。
            • 低概率和影响的风险将被列入风险登记册中旳观察清单，以供未来监控。
          • 其他风险参数评估----紧迫性、邻近性、潜伏期、可管理性、可控性、可监测性、连通性、战略影响力、密切度等。考虑这些特征有助于进行更稳健的风险优先级排序。
        • 风险分类(P425)
          • 可按照不同的分类标准对项目风险分类，以确定哪些项目领域最容易被不确定性影响。
          • 风险分类标准：
            • 1、RBS;
            • 2、WBS;
            • 3、项目阶段、预算、角色和职责;
            • 4、共同的根本原因；
          • 对风险进行分类，有助于：
            • 1、把注意力和精力集中到风险敞口最大的领域。
            • 2、针对一组相关的风险制定通用的风险应对措施。
        • 数据表现(P425)
          • 概率和影响矩阵，此矩阵对概率和影响进行组合，以便于把单个项目风险划分成不同的优先级组别。
            • 采用风险管理计划中规定的风险概率和影响定义，逐一对单个项目风险的发生概率及其对一项或多项项目目标的影响进行评估。再基于所得到的概率和影响的组合，使用概率和影响矩阵，来分配风险的优先级别。
          • 层级图，如使用了两个以上的参数对风险进行分类，则不能使用概率和影响矩阵，而需要使用其他图形。
            • 如:气泡图(X轴值、Y轴值和气泡大小来表示风险的三个参数)。
    • ：实施定量风险分析，就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。
      • why
        • 如要评估所有单个项目风险对项目整体的综合影响，定量风险分析就成为唯一可靠的方法。
        • 实施定量风险分析的对象，是在定性分析过程中被评估为对项目目标存在重大潜在影响的，并且能被 量化的单个项目风险的信息。
        • 定量风险分析也可以在规划风险应对过程之后展开，以分析已规划的应对措施对降低整体项目风险敞 口的有效性。
    • ：本过程的作用：量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划。
      • 并非所有项目都需要实施定量风险分析，它最可能适用的情况如下:
        • 1、大型或复杂的项目
        • 2、具有战略重要性的项目
        • 3、合同要求进行定量分析的项目
        • 4、主要相关方要求进行定量分析的项目
    • ：实施定量风险分析（ITTO），工具与技术（数据收集+不确定性表现方式+数据分析）+输出（项目文件更新）
      • 工具与技术：数据收集+不确定性表现方式+数据分析
        • 数据收集(P432)
          • 访谈，当需要向专家征求信息时，访谈尤其适用。
          • 访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。
        • 不确定性表现方式(P432)
          • 如果活动的持续时间、成本或资源需求是不确定的，就可以在模型中用概率分布(如三角分布、正态分布、对数正态分布、贝塔分布、均匀分布或离散分布)来表示其数值的可能区间。
        • 数据分析：模拟+敏感性分析+决策树分析
          • 模拟(P433)
            • 模拟(是单变量反复模拟)----通常采用蒙特卡洛分析。
            • 蒙特卡洛分析（输入-->随机选择-->蒙特卡洛分析-->输出）
              • 输入：成本估算+进度网络图+持续时间估算
              • 蒙特卡洛分析：计算机软件数千次迭代运行
              • 输出：次数的直方图+累积概率分布+S曲线
            • 关键性分析----对项目进度进行蒙特卡洛模拟时，计算风险模型中的每个活动出现在关键路径上的次数和频率。出现频率高的那些活动，我们要重点关注，并规划风险应对措施。这个频率也可以称作为“关键性指标”。
          • 敏感性分析(P434)
            • 敏感性分析(是一种单因素分析)，有助于确定哪些风险对项目具有最大的潜在影响。它有助于理解项目结果变异与定量风险分析模型中的要素变异之间存在怎样的联系。
            • 把所有其他不确定因素固定在基准值，考察每个因素的变化会对目标产生多大程度的影响
            • 敏感性分析的典型表现形式是龙卷风图(用于比较很不确定的变量与相对稳定的变量之间的相对重要性和相对影响)
          • 决策树分析(P435)
            • 决策树分析，用决策树在若干备选行动方案中选择一个最佳方案。不同的分支代表不同的决策或事件。
            • 在决策树分析中，通过计算每条分支的预期货币价值(EMV)，就可以选出最优的路径。
            • 机会的EMV 通常表示为正值，而威胁的EMV 则表示为负值。
            • EMV 是建立在风险中立的假设之上的，既不避险，也不冒险。
          • 影响图(P436)
            • 影响图，不确定条件下决策制定的图形辅助工具。是对变量与结果之间的因果关系、事件时间顺序及其他关系的图形表示。
            • 影响图分析，可以得出类似于其他定量风险分析的结果，如S曲线图和龙卷风图
    • ：规划风险应对，为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。
      • why
        • 往往需要为风险分配时间或成本应急储备，并可能需要说明动用应急储备的条件。
    • ：本过程的作用
      • 制定应对整体项目风险和单个项目风险的适当方法
      • 分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。
        • 风险应对措施必须
          • 1、与风险的重要性相匹配
          • 2、能经济有效地应对挑战
          • 3、现实可行
          • 4、能获得全体相关方的同意
          • 5、由一名责任人具体负责(风险应对责任人)
        • 如果选定的策略并不完全有效，或者发生了已接受的风险，就需要制定应急计划(或弹回计划)。
        • 次生风险，实施风险应对措施而直接导致的风险。规划风险应对时，需要识别次生风险。
    • ：规划风险应对（ITTO），工具与技术（威胁应对策略+机会应对策略+应急应对策略+整体项目风险应对策略+数据分析）+输出（项目文件更新+变更请求+项目管理计划更新）
      • 工具与技术：威胁应对策略+机会应对策略+应急应对策略+整体项目风险应对策略+数据分析
        • 威胁应对策略(P442)
        • 机会应对策略(P444)
        • 应急应对策略(P445)
          • 应急应对策略，仅在特定事件发生时才采用的应对措施。(注意区分“应急响应”)
            • 如果确信风险的发生会有充分的预警信号，就应该制定应急应对策略
            • 采用此技术制定的风险应对计划称为应急计划或弹回计划，包括已识别的、用于启动计划的触发事件
          • 规划风险应对时还需要注意以下风险
            • 次生风险，实施风险应对措施的直接结果。由于应对一个风险而产生的另一个风险。
            • 残余风险，执行风险应对计划后仍然残留的风险，通常是可接受的。
        • 整体项目风险应对策略(P445)
        • 数据分析(P446)
          • 备选方案分析----对备选风险应对方案的特征和要求进行简单比较，进而确定哪个应对方案最为适用。
          • 成本效益分析----如果能够把单个项目风险的影响进行货币量化，那么就可以通过成本收益分析来确定备选风险应对策略的成本有效性。
          • 策略的有效性=应对的结果/应对花费的成本
        • 【补充】威胁应对策略的理解
        • 【补充】
          • 风险登记册
          • 应对计划、应急应对计划
            • 风险:小严今晚陪客户搓麻将，回家很晚，可能会被老婆打得生活不能自理
            • 一般的应对:
              • 小严识别到该风险。经过定性分析，该风险属于高危风险。规划应对时采用的策略为“规避”
              • 应对计划:“直接离家出走，将风险发生的概率降低到0，以规避该风险”。
            • 应急应对:
              • 识别到该风险。经过定性分析，该风险属于高危风险。但是，这个风险是有预警的:如果回家老婆叫小严亲爱的，则代表没 事;如果老婆很大声吼出小严的全名，代表小严即将遭受毒打。
              • 应急计划:先不要直接离家出走，毕竟风险有不确定性，不一定会遭受毒打。如果回家老婆还是叫小严“亲爱的”就算了;当小严老婆大声吼出他的全名时(预警发生时)，马上跑!!
    • ：实施风险应对，执行商定的风险应对计划的过程。
      • why
    • ：本过程的作用
      • 确保按计划执行商定的风险应对措施，来管理整体项目风险敞口、最小化单个项目威胁、最大化单个
      • 项目机会。
      • 只有风险责任人以必要的努力去实施商定的应对措施，项目的整体风险敞口和单个威胁及机会才能得到主动管理。
    • ：实施风险应对（ITTO），工具与技术（人际关系与团队技能）
      • 工具与技术
        • 人际关系与团队技能(P451)
          • 影响力----有些风险应对措施可能由直属项目团队以外的人员去执行，或由存在其他竞争性需求的人去执行。这种情况下，项目经理需要施展影响力，去鼓励指定的风险责任人采取所需的行动。
    • ：监督风险，在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。
      • why
    • ：本过程的作用:使项目决策都基于关于整体项目风险敞口和单个项目风险的当前信息。
      • How
        • 工具与技术：数据分析+风险审计+会议
          • 数据分析(P456)：技术绩效分析+储备分析
            • 技术绩效分析，把项目执行期间所取得的技术成果与取得相关技术成果的计划进行比较。
              • 要求定义关于技术绩效的客观的、量化的测量指标。
              • 实际结果偏离计划的程度可以代表威胁或机会的潜在影响。
            • 储备分析，在项目的任一时点比较剩余应急储备与剩余风险量，从而确定剩余储备是否仍然合理。
              • 可以用各种图形(如燃尽图)来显示应急储备的消耗情况。
          • 风险审计(P456)
            • 风险审计，用于评估风险管理过程的有效性。(第二大审计，针对过程)
            • 可开展的地方:1、日常项目审查会;2、风险审查会;3、专门的风险审计会;
          • 会议(P457)
            • 适用于本过程的会议包括:风险审查会。应该定期安排风险审查，来检查和记录风险应对在处理整体项目风险和已识别单个项目风险方面的有效性。
            • 在风险审查中，还可以识别出新的单个项目风险(包括次生风险)，重新评估当前风险，关闭已过时风险，讨论风险发生所引发的问题，以及总结可用于当前项目后续阶段或未来类似项目的经验教训。
            • 根据风险管理计划的规定，风险审查可以是定期项目状态会中的一项议程，或者也可以召开专门的风险审查会。
        • 输出：项目文件更新----风险登记册(P458)
          • 风险登记册----添加新风险、更新已过时风险或已发生风险、更新风险应对措施。
    • ：监督风险（ITTO），输入（风险登记册）+工具与技术（工具与技术）+输出（风险登记册）
      • 输入：风险登记册(P455)
        • 风险登记册中包括:已识别的单个项目风险、风险责任人、商定的风险应对策略、具体的应对措施、用于评估应对计划有效性的控制措施、风险征兆和预警信号、残余风险和次生风险、低优先级风险观察清单
      • 风险答题技巧
        • 首先看是“识别了风险”还是“风险发生了”。
          • 如是“识别了风险”，则更新风险登记册，或者，查阅风险登记册、记录在风险登记册。
          • 如是“发生了风险”，则确定是“已知”风险还是“未知”风险:
            • 已知风险:查阅风险登记册，直接应对;如果要使用储备，一般是使用应急储备。
            • 未知风险:采取权变措施，提交变更请求，使用管理储备。
          • 如果是“已知”风险，但是应对无效，同样需要权变，提交变更请求，使用管理储备。
        • 风险管理的顺序如下:1.识别 2. 定性(必须要做) 3.定量(可以不做) 4.规划应对 5.实施应对
      • 风险登记册
      • 【重点】
        • 风险：某个事件，未来可能发生(概率)，一旦发生会产生积极或消极的影响(影响)
        • 风险管理计划无风险
        • 理解风险管理计划中的四个重点:相关方风险偏好、RBS、概率和影响的定义、矩阵
        • 识别风险的工具、输出
        • 定性风险分析的作用、工具
        • 定量风险分析的工具:敏感性分析、决策树分析
        • 规划风险应对的工具、输出
        • 实施风险应对的目的，谁来实施
        • 监督风险的工具
    • 核心概念
      • 项目风险
        • 项目风险是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标造成积极或消极的影响。
        • 风险的三要素:风险事件、概率、影响。
        • 积极和消极风险通常被称为机会和威胁。
      • 两个层面的风险(P397)
        • 单个项目风险----一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
        • 整体项目风险----不确定性对项目整体的影响，是相关方面临的项目结果正面和负面变异区间。
        • 整体项目风险大于项目中单个风险之和，因为整体风险源于包括单个风险在内的所有不确定性。
      • 三种性质的项目风险
        • “已知 — 已知” 风险----已识别，可对这些风险规划应对措施。(计入时间/成本)
        • “已知 — 未知” 风险----已识别，但无法(或不需要)主动管理的风险，分配应急储备。
        • “未知 — 未知” 风险----未识别，无法进行主动管理，因此需要预留一定的管理储备。
      • 影响风险态度的因素
        • 风险偏好----为了预期的回报，一个实体愿意承受不确定性的程度。(愿不愿意承受)
        • 风险承受力----组织或个人能承受的风险程度、数量或容量。(能不能承受)
        • 风险临界值----反映了组织与项目相关方的风险偏好程度，是项目目标的可接收的变异程度。(要不要管理)P398
        • 较为合适且正确的做法是如下排列:风险承受力>风险偏好>风险临界值
      • 什么是风险态度
        • 风险态度----个人或组织认为自己应该冒多大的风险。如果实际所冒风险未超出应该冒的风险，就觉得很舒服。个人和团体的风险态度影响其应对风险的方式。
        • 风险冒进者:常常采用“接受”的策略。
    • 发展趋势和新兴实践
      • 非事件类风险(P398)
        • 传统关注:事件类风险----可能发生或可能不发生的不确定性未来事件的风险。
        • 发展趋势:非事件类风险----变异性风险、模糊性风险。
      • 项目韧性(P399)
        • 项目韧性：确实存在只有在发生后才能被发现的突发性风险，需要通过加强项目韧性来应对。
        • 应对思路
          • 留出储备
          • 灵活的变更管理机制
          • 足够授权、值得信赖的团队
          • 关注早期风险信号
          • 沟通相关方，明确面对突发可采取的策略的范围。
      • 整合式风险管理(P399)
        • 在较高层面识别出的某些风险，将被授权给项目团队去管理;
        • 而在较低层面识别出的某些风险，又可能上交给较高层面去管理。
        • 应该采用协调式企业级风险管理方法，来确保所有层面的风险管理工作的一致性和连贯性。
    • 在敏捷和适应型环境中需要考虑的因素(P400)
      • 要应对快速变化，就需要采用适应型方法管理项目。
      • 即:通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。
      • 在选择每个迭代期的工作内容时，应该考虑风险;在每个迭代期间应该识别、分析和管理风险。
      • 应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级。
    • 项目风险管理过程：规划过程组（
      • 执行过程组：实施风险应对
        • 之六“实施风险应对”P449
          • what
          • How
      • 监控过程组：监督风险
        • 之七“监督风险”P453
          • what
  • 第十二章 项目采购管理
    • ：规划采购管理，记录项目采购决策、明确采购方法、识别潜在卖方的过程。
      • why
    • ：本过程的作用，确定是否从项目外部获取货物和服务。如果是，则还要确定将在什么时间、以什么方式获取什么货物和服务。
      • How
        • 工具与技术：数据分析自制或外购分析+数据收集+供方选择分析+会议
          • 数据分析自制或外购分析(P473)
            • 自制或外购分析----用于确定某项工作最好由项目团队自行完成，还是应该从外部采购(谁划算用谁)
            • 自制或外购分析应考虑全部相关成本，包括直接成本与间接成本。
            • 【练一练】
          • 数据收集(P473)
            • 市场调研----包括考察行业情况和具体卖方的能力。
            • 采购团队可运用从会议、在线评论和各种其他渠道得到的信息，来了解市场情况。
          • 供方选择分析(P473)
            • 最低成本，标准化或常规采购.
            • 基于技术方案，打技术分，按技术谈价格/商务
            • 独有来源，特殊情况理由充分
            • 仅凭资质，采购价值小，不值得开展完整选择过程
            • 基于质量和成本，同时考虑质量和成本。当风险大时，质量 更关键。
            • 固定预算，SOW定义精确预期不会发生变更预算固定不超出
          • 会议(P474)
            • 潜在投标人的信息交流会----有利于卖方以互惠的方法提供产品或服务，从而使采购方从中受益。
        • 输出：采购管理计划+采购策略
          • 采购管理计划(P475)
            • 包含要在采购过程中开展的各种活动。
              • 如何协调采购工作与项目的其他工作，如制定进度计划与报告项目绩效;
              • 开展重要采购活动的时间表。
              • 用于管理合同的采购测量指标。
              • 与采购有关的相关方角色和职责。
              • 可能影响采购工作的制约因素和假设条件;
              • 拟使用的预审合格的卖方(如果有);
              • 风险管理事项;
              • 是否需要编制独立估算，以及是否应把独立估算作为评价标准;
              • 司法管辖权和付款货币。
          • 采购策略(P476)
            • 采购策略，如果决定从项目外部渠道采购，就应制定一套采购策略，包括项目交付方法、具有法律约束力的协议类型、如何在采购阶段推动采购进展。
            • 交付方法
              • 专业服务项目----不得分包;可以分包;买卖双方设立合资企业;买方或卖方仅充当代表。
              • 工业或商业施工项目----交钥匙式、设计-建造 (DB)、设计-招标-建造 (DBB)、设计-建造-运营(DBO)、建造-拥有-运营-转让 (BOOT)
            • 合同支付类型
              • 总价合同----适用于工作类型可预知、需求能清晰定义、不太可能变更;
              • 成本补偿合同----适用于工作不断演进、很可能变更、未明确定义;
              • 激励和奖励费用----用于协调卖方和卖方的目标。
            • 采购阶段
              • 采购工作的顺序，每个阶段的描述，阶段具体目标；过渡到下一个阶段的标准;
              • 用于监督的采购绩效指标和里程碑；用于追踪采购进展的监督和评估计划；
              • 向后续阶段转移知识的过程。
          • 招标文件(P477)
            • 招标文件----用于向潜在卖方征求建议书(可以是:信息邀请书RFI、报价邀请书RFQ、建议邀请书RFP等)
            • 主要依据价格来选择卖方(如购买商业或标准产品时)，通常就使用标书、投标或报价等术语。
            • 如果主要依据其他考虑因素(如技术能力或技术方法)来选择卖方，通常就使用诸如建议书之类的 术语。
            • 信息邀请书(RFI)----如需卖方提供关于拟采购货物和服务的更多信息时使用。
            • 报价邀请书(RFQ)----如需供应商提供关于将如何满足需求和(或)将需要多少成本时使用。
            • 建议邀请书(RFP)----如项目中出现问题且解决办法难以确定时使用。(最正式的“邀请书”文件)
            • 采购文件中应包括:1、应答格式要求;2、相关的采购工作说明书;3、所需的合同条款
          • 采购工作说明书(P477)
            • 采购工作说明书----依据项目范围基准，为每次采购编制工作说明书(SOW)， 仅对将要包含在相关合同中的那一部分项目范围进行定义。
            • SOW应该详细描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供。
            • 工作说明书中可包括规格、数量、质量、性能参数、履约期限、工作地点和其他需求。
            • 在采购过程中，应根据需要对采购SOW进行修订和改进，直到成为所签协议的一部分。
            • 对于服务采购，可能会用“工作大纲(TOR)”这个术语。
          • 自制或外购决策(P479)
            • 通过自制或外购分析，做出某项特定工作最好由项目团队自己完成，还是需要从外部渠道采购的决策。
          • 独立成本估算(P479)
            • 可自行准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准。
            • 若二者之间存在明细差异，则可能:采购SOW存在缺陷或模糊，或潜在卖方误解或未能完全响应采购SOW
          • 供方选择标准(P478)
            • 供方选择标准，这些标准是加权系统的组成部分，可据此以加权打分的方法排列所有建议书的顺序，以便确定谈判的顺序，并与某个卖方签订合同。标准可以是客观或主观的。
            • 可能的供方选择标准如下:
              • 能力和潜能;
              • 产品成本和生命周期成本;
              • 交付日期;
              • 技术专长和方法;
              • 具体的相关经验;管理经验;
              • 用于响应工作说明书的工作方法和工作计划;知识转移计划，包括培训计划。
              • 关键员工的资质、可用性和胜任力;
              • 公司的财务稳定性;
          • 组织过程资产更新(P481)
            • 作为规划采购管理过程的结果，需要更新的组织过程资产包括(但不限于)关于合格卖方的信息。
            • 对于采购次数少且相对简单的项目，作为本过程输出的有些文件可以合并。
            • 对于采购规模较大、较复杂，而且大部分工作需由承包商完成的项目，就需要使用几种不同类型的文件。
    • ：规划采购管理（ITTO）， 输入 （项目章程+商业文件+项目管理计划+项目文件+组织过程资产）+工具与技术（数据分析自制或外购分析+数据收集+供方选择分析+会议）+输出（采购管理计划+采购策略）
      • 输入：项目章程+商业文件+项目管理计划+项目文件+组织过程资产
        • 项目章程(P468)，包括目标、项目描述、总体里程碑、预先批准的财务资源。
        • 商业文件(P469)：商业论证+收益管理计划
          • 商业论证，采购策略需要和商业论证保持一致。
          • 收益管理计划，描述应在何时产出具体的项目收益，这将影响采购日期和合同条款的确定。
        • 项目管理计划(P469)：范围管理计划+质量管理计划+资源管理计划+范围基准
          • 范围管理计划，说明如何在项目的实施阶段管理承包商的工作范围。
          • 质量管理计划，其中的项目需遵循的行业标准与准则，应写入招标文件，并将最终在合同中引用；也可用于供应商资格预审，或作为供应商甄选标准的一部分。
          • 资源管理计划，包括关于哪些资源需要采购或租赁的信息，以及任何可能影响采购的假设条件或制约因素。
          • 范围基准，针对项目范围书中已知的工作，编制工作说明书(SOW)和工作大纲(TOR)
        • 项目文件(P469)
          • 里程碑清单，说明卖方需要在何时交付成果。
          • 项目团队派工单，包含关于项目团队技能和能力的信息，以及他们可用于支持采购活动的时间。如团队不具备采购能力，则需外聘或培训。
          • 需求文件，卖方需满足的技术要求；具有合同和法律意义的需求。
          • 需求跟踪矩阵；资源需求
          • 风险登记册，有些风险应通过采购协议转移给第三方。
          • 相关方登记册，监管机构、合同签署人员、法务人员。
        • 组织过程资产(P471)
          • 预先批准的卖方清单，经过适当审查的卖方清单可以简化招标所需的步骤，并缩短卖方甄选过程的时间。
          • 正式的采购政策、程序和指南，一般都有，若没有，项目团队就应配备相关的资源和专业技能，来实施采购
          • 合同类型，总价、成本补偿、混合类型(工料合同)。单次采购可合并使用两种或者更多合同类型。
            • 合同类型
              • 总价合同 Fixed-Price Contract
                • 固定总价合同Firm Fixed Price Contract (FFP)
                • 总价加激励费用合同 Fixed Price Incentive Fee Contract (FPIF)
                • 总价加经济价格调整合同 Fixed Price with Economic Price Adjustment Contract(FPEPA)
              • 成本补偿合同Cost-Reimbursable Contract
                • 成本加固定费用合同Cost Plus Fixed Fee Contract (CPFF)
                • 成本加激励费用合同Cost Plus Incentive Fee Contract (CPIF)
                • 成本加奖励费用合同Cost Plus Award Fee Contract (CPAF)
              • 工料合同Time and Material Contract (T&M)
            • 合同类型----总价合同(P471)
              • 总价合同，此类合同为既定产品、服务或成果的采购设定一个总价。
              • 适用于：已明确定义需求，且不会出现重大范围变更的情况下使用。
              • 固定总价合同(FFP)，FFP 是最常用的合同类型。
                • 大多数买方都喜欢这种合同。
                • 因为采购的价格在一开始就确定，并且不允许改变(除非工作范围发生变更)。
                • 卖方有义务完成工作，并且承担因不良绩效导致的任何成本增加。
                • 在FFP 合同下，买方应该准确定义拟采购的产品和服务，对采购规范的任何变更都会增加买方的成本。
              • 总价加激励费用合同(FPIF)，允许一定的绩效偏离，并对实现既定目标给与相关的财务奖励(通常取决于卖方的成本、进度或技术绩效)。
                • 在FPIF 合同中，要设置价格上限，卖方必须完成工作并且要承担高于上限的全部成本。
              • 总价加经济价格调整合同(FPEPA)，适用于：卖方履约期将跨越几年;将以不同货币支付价款。
                • 允许根据条件变化(如通货膨胀、某些特殊商品的成本增降)，以事先确定的方式对合同价格进行最终调整。
              • 总价+激励费用合同计算的要素及含义
                • 总价 = 实际成本+目标利润+(目标成本-实际成本)*卖方应承担比例
                • 先算总价，和最高限价比较，计算最终总价。
                • 实际利润=最终总价-实际成本
              • 【练一练】
            • 合同类型----成本补偿合同(P4 72)
              • 成本补偿合同，向卖方支付为完成工作而发生的全部合法实际成本(可报销成本)，外加一笔费用作为卖方的利润
              • 适用于：工作范围预计会在合同执行期间发生重大变更。
              • 成本加固定费用合同(CPFF)
                • 为卖方报销履行合同工作所发生的一切可列支成本，并向卖方支付一笔固定费用，该费用以项目初始成本估算的某一百分比计算。
                • 例:A公司为B公司提供产品，他们签订了成本加固定费用合同，合同规定了130万的目标成本，利润10%，项目实际成本为140万，则B公司应该支付多少钱?
              • 成本加激励费用(CPIF)
                • 为卖方报销履行合同工作所发生的一切可列支成本，并在卖方达到合同规定的绩效目标时，向卖方支付预先确定的激励费用。
                • 在CPIF 合同中， 如果最终成本低于或高于原始估算成本，则买方和卖方需要根据事先商定的成本分摊比例来分享节约部分或分担超出部分。
                • 与总价加激励费用相比，不存在总价上的最高限价。
                • 但有时会出现利润的最高限价和最低限价。
              • 成本+激励费用合同计算的要素及含义
                • 目标成本(估算成本)
                • 目标利润(目标费用)
                • 实际成本
                • 分摊比例(买方 / 卖方，如:80/20即买方承当80，卖方承担20)
                • 利润= 目标利润+(目标成本-实际成本)*卖方应承担比例
                • 先算利润，和利润上下限比，计算最终利润。
                • 实际总价=最终利润+实际成本
              • 【练一练】
              • 成本加奖励费用(CPAF) ，为卖方报销一切合法成本，但只有在卖方满足合同规定的、某些笼统主观的绩效标准的情况下，才向卖方支付大部分费用。
              • 完全由买方根据自己对卖方绩效的主观判断来决定奖励费用，并且通常不允许申诉。
            • 合同类型----工料合同(T&M)(P472)
              • 工料合同(T&M，时间和手段合同) ----兼具成本补偿合同和总价合同的某些特点的混合型合同。
              • 适用于:在无法快速编制出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。
              • 这类合同与成本补偿合同的相似之处在于，它们都是开口合同，合同价因成本增加而变化。
              • 在授予合同时，买方可能并未确定合同的总价值和采购的准确数量。
              • 因此，如同成本补偿合同，工料合同的合同价值可以增加。
              • 很多组织要求在工料合同中规定最高价值和时间限制，以防止成本无限增加。
              • 由于合同中确定了一些参数，工料合同又与固定单价合同相似。
              • 预先设定了单位人力或材料费率(包含卖方利润)。
              • 补充：成本加百分比合同(CPPC )，美国法律已经禁止使用。
            • 七种常用的合同
            • 合同的选择标准
              • 范围角度
                • 范围明确、设计详细----总价合同
                • 范围不清----成本补偿合同或工料合同
              • 风险承担角度
                • 甲方承担----成本补偿合同
                • 双方承担----工料合同
                • 乙方承担----总价合同
              • 时间紧任务重，需要专家以及其他外部支持的短期项目。
              • 工料合同比较灵活，随时叫停或更换供应商。
    • ：实施采购，是获取卖方应答、选择卖方并授予合同的过程。
      • why
    • ：本过程的作用，选定合格卖方并签署关于货物或服务交付的法律协议。本过程最后的成果是签订的协议，包括正式合同。
      • How：实施采购（ITTO），输入（采购文档+卖方建议书）+工具与技术（广告+投标人会议+数据分析+人际关系与团队技能）+输出（选定的卖方+协议）
        • 输入：采购文档+卖方建议书
          • 采购文档(P485)
            • 采购文档，用于达成法律协议的各种书面文件，其中可能包括当前项目启动之前的旧文件。
            • 招标文件，包括发给卖方的信息邀请书、建议邀请书、报价邀请书，或其他文件，以便卖方编制应答文件。
            • 采购工作说明书，向卖方清晰地说明目标、需求及成果，以便卖方据此做出量化应答。
            • 独立成本估算，可由内部或外部人员编制，用于评价投标人提交的建议书的合理性。
            • 供方选择标准，描述如何评估投标人的建议书，包括评估标准和权重。为了减轻风险，买方可能决定与多个卖方签署协议，以便在单个卖方出问题并影响整体项目时，降低由此导致的损失。
          • 卖方建议书(P486)
            • 包含的基本信息将被评估团队用于选定一个或多个投标人(卖方) 。价格建议书应与技术建议书分开。
        • 工具与技术：广告+投标人会议+数据分析+人际关系与团队技能-->招+投+评+授
          • 广告(P487)
            • 广告----是就产品、服务或成果与用户或潜在用户进行的沟通。
            • 在大众出版物(如指定的报纸)或专门行业出版物上刊登广告，往往可以扩充现有的潜在卖方名单。
            • 大多数政府机构都要求公开发布采购广告，或在网上公布拟签署的政府合同的信息。
          • 投标人会议(P487)
            • 投标人会议(又称承包商会议、供货商会议或投标前会议)，就是在投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议。
            • 目的是保证所有潜在卖方对采购要求都有清楚且一致的理解，保证没有任何投标人会得到特别优待。
            • 买方必须尽力确保每个潜在卖方都能听到任何其他卖方所提出的问题，以及买方所做出的每个回答。
            • 可以运用相关技术来促进公平，例如，在召开会议之前就收集投标人的问题或安排投标人考察现场。
            • 要把对问题的回答，以修正案的形式纳入采购文件中。
          • 数据分析(P487)：建议书评估+加权系统+筛选系统
            • 建议书评估，对于复杂的采购，如果要基于卖方对既定加权标准的响应情况来选择卖方，则应该根据买方的采购政策，规定一个正式的建议书评审流程。
            • 加权系统，指把定性数据加以量化，以减少个人偏见对卖方选择的影响的方法
              • 多数加权系统包括对每项评估标准赋予一个数字权重
              • 为潜在卖方评定每项评估标准的得分
              • 把得分乘以权重
              • 再把所得乘积相加，求出总得分
            • 筛选系统，指为一项或多项评估标准建立最低的绩效要求，并可应用加权系统和独立估算。
          • 人际关系与团队技能--采购谈判(P488)
            • 采购谈判，指在合同签署之前，对合同的结构、各方的权利义务，及其他条款加以澄清，以便双方达成共识。
            • 最终的合同措辞应该反映双方达成的全部一致意见。
            • 采购谈判应由采购团队中拥有合同签署职权的成员主导，项目经理可以不是主谈人，但可参加并提供协助。
        • 输出：选定的卖方+协议
          • 选定的卖方(P488)
            • 选定的卖方，在建议书评估或投标评估中被判断为最有竞争力的投标人。
            • 对于较复杂、高价值和高风险的采购，在授予合同前，要把选定的卖方报给组织高级管理人员审批。
          • 协议(P489)
            • 合同是对双方都有约束力的协议。合同建立了受法律保护的买卖双方的关系。
            • 协议文本的内容各不相同，通常包括
              • SOW或交付物
              • 进度基线
              • 绩效报告
              • 执行期间
              • 角色和职责
              • 实施场所
              • 价格
              • 付款条款
              • 交货地点
              • 检查和验收标准
              • 质保期
              • 产品支持
              • 责任范围
              • 费用及定金
              • 罚约
              • 激励
              • 保险
              • 履约保函
              • 变更处理
              • 终止和ADR机制
              • 等
    • ：控制采购，是管理采购关系、监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。
      • why
    • ：本过程的作用
      • 确保买卖双方履行法律协议，满足项目需求
      • 合同关系的法律性质，要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果
      • 对于有多个供应商的较大项目，合同管理的一个重要方面就是管理各个供应商之间的沟通
      • 鉴于其法律意义，很多组织都将合同管理视为独立于项目的一种组织职能。虽然采购管理员可以是项目团队的成员，但通常还向另一部门的经理报告
      • 控制措施的质量(采购审计的独立性和可信度)，是采购系统可靠性的关键决定因素
      • 组织的道德规范、内部法律顾问和外部法律咨询，包括持续的反腐计划，都有助于实现适当的采购控制
      • 在合同收尾前，若双方达成共识，可以根据协议中的变更控制条款，随时对协议进行修改。同样要书面记录对协议的修改
    • ：控制采购（ITTO），输入（协议+采购文档+批准的变更请求）+工具与技术（索赔管理+数据分析+检查+审计）+输出（采购关闭）
      • 输入：协议+采购文档+批准的变更请求
        • 协议(P496)
          • 协议，是双方之间达成的谅解，包括对各方义务的一致理解。对照相关协议，确认其中的条款和条件的遵守情况。
        • 采购文档(P496)
          • 采购文档，包含用于管理采购过程的完整支持性记录，包括工作说明书、支付信息、承包商工作绩效信息、计划、图纸和其他往来函件。
        • 批准的变更请求(P496)
          • 批准的变更请求，可能包括对合同条款和条件的修改。
          • 与采购相关的任何变更，在通过控制采购过程实施之前，都需要以书面形式正式记录，并取得正式批准。
          • 在复杂的项目和项目集中，变更请求可能由参与项目的卖方提出，并对参与项目的其他卖方造成影响。
    • 核心概念(P460)
      • 01 项目经理不必成为采购管理法律法规领域
      • 02分散式采购+集中式采购
        • 分散式采购:项目经理有采购职权(小型或初创组织)
        • 集中式采购:专设部门开展采购(成熟组织)
        • 通常情况下，项目经理无权签署对组织有约束力的法律协议
      • 03合同应明确说明预期的可交付成果和结果，包括从卖方到卖方的任何知识转移;
      • 04对于国际合作的项目，文化和当地法律对合同及其可执行性均有影响。
      • 05卖方+买方
        • 卖方:承包商、供货商、服务提供商、供应商
        • 买方:最终产品所有人、分包商、收购机构、购买方
        • 卖方:投标人→中标人→签约供应商或供货商
      • 06合同和协议需要经过更多的审批程序，目标是确保合同充分描述将由卖方提供的产品、服务或成果，且符合法律法规关于采购的规定
      • 07复杂项目中，可能需要管理多个合同，不同合同的生命周期可在项目生命周期的任何阶段开始与结束
      • 08协议可以是合同、服务水平协议(SLA)、谅解备忘录、协议备忘录(MOA)或订购单
    • 发展趋势和新兴实践(P463)
      • 工具的改进，主要公司和政府都开始要求在大型项目中使用建筑信息模型(BIM)
      • 更先进的风险管理，编制合同时准确地将具体风险分配给最有能力对其加以管理的一方
      • 变化中的合同签署实践，超大型项目数量显著增加，要求与多个国家签署国际合同，采用国际公认的标准合同范本日益普遍
      • 物流和供应链管理，订购周期长的产品提前采购明确主要、次要、备选采购渠道;要求必须从当地采购一定比例的材料
      • 技术和相关方关系，网络摄像机的应用:进展报告、索赔支持。
      • 试用采购，先小批量试采，再批量采购
    • 在敏捷和适应型环境中需要考虑的因素(P465)
      • 在敏捷型环境中，可能需要与特定卖方协作来扩充团队，让买方和卖方共担风险和共享奖励。
      • 大型项目上，通过主体协议，来管辖整体协作关系，将适应型工作写入附录或补充文件。这样做以便变更只针对适应型工作，而不会对主体协议造成影响。
    • 项目采购管理过程：规划过程组（规划采购管理）+执行过程组（实施采购）+监控过程组（控制采购）
      • 规划过程组
        • 之一“规划采购管理”P466
          • what
      • 执行过程组
        • 之二“实施采购”P482
          • what
      • 监控过程组
        • 之三“控制采购”P492
          • what
          • How
            • 工具与技术：索赔管理+数据分析+检查+审计
              • 索赔管理(P498)
                • 有争议的变更也称为索赔、争议或诉求
                • 谈判是解决所有索赔和争议的首选方法
                • 索赔和争议的处理顺序
                  • 1、谈判
                  • 2、ADR(替代争议解决方法)
                  • 3、起诉
              • 数据分析(P498)：绩效审查+挣值分析+趋势分析
                • 绩效审查，对照协议，对质量、资源、进度和成本绩效进行测量、比较和分析，以审查合同工作的绩效。其中包括确定工作包提前或落后于进度计划、超出或低于预算，以及是否存在资源或质量问题。是甲方对乙方过程的审查。
                • 挣值分析 (EVA)，计算进度和成本偏差，以及进度和成本绩效指数，以确定偏离目标的程度。
                • 趋势分析，可用于编制关于成本绩效的完工估算 (EAC)，以确定绩效是正在改善还是恶化。
              • 检查(P498)
                • 检查，对承包商正在执行的工作进行结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。是甲方对乙方可交付成果的检查。
              • 审计(P498)
                • 采购审计，是对采购过程的结构化审查。(三大审计之一)
                • 应该在采购合同中明确规定与审计有关的权利和义务。
                • 采购审计是甲方对自己整个采购过程的审计
            • 输出：采购关闭(P499)
              • 买方通常通过其授权的采购管理员，向卖方发出合同已经完成的正式书面通知。
              • 关于正式关闭采购的要求，通常已在合同条款和条件中规定，并包括在采购管理计划中。
              • 一般而言，这些要求包括
                • 已按时按质按技术要求交付全部可交付成果
                • 没有未决索赔或发票
                • 全部最终款项已经付清
              • 项目管理团队应该在关闭采购之前批准所有的可交付成果。
              • 合同提前终止
                • 合同提前终止是结束采购的一个特例，有以下3种情况会提前终
                  • 合同可由双方协商一致而提前终止
                  • 或因一方违约而提前终止
                  • 或者为买方的便利而提前终止(如果合同中有这种规定)
                • 如果合同提前终止
                  • 对该合同或该部分中已经完成和验收的工作支付报酬
                  • 对卖方为该合同或该部分所做的准备工作给予补偿
          • 【重点】
            • 几种常见的合同类型、合同的选择、总价加激励和成本加激励费用合同的计划
            • 规划采购的工具和输出:自制外购分析、招标文件、SOW、独立成本估算
            • 实施采购的工具:招、投、评、授
            • 实施采购的输出:选定的卖方、协议
            • 控制采购的工具和输出
  • 第十三章 项目相关方管理
    • ：识别相关方，定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程
      • why
    • ：本过程的作用：使项目团队能够建立对每个相关方或相关方群体的适度关注
      • How
        • 工具与技术：数据收集+数据分析+数据表现+相关方映射分析/表现+会议
          • 数据收集(P511)
            • 问卷和调查：一对一调查、焦点小组讨论、或其他大规模信息收集技术。
            • 头脑风暴：通用的数据收集和创意技术，用于向小组征求意见。
            • 头脑写作：头脑风暴的改良形式，让个人参与者有时间在小组创意讨论开始前单独思考问题。信息可通过面对面小组会议收集，或在由技术支持的虚拟环境中收集。
          • 数据分析(P512)
            • 相关方分析：会产生相关方清单和关于相关方的各种信息(组织内的位置、项目中的角色、与项目的利害关系、期望、态度、对项目信息的兴趣)。
            • 相关方的利害关系可包括:兴趣、权利(合法权利或道德权利)、所有权、知识、贡献。
            • 文件分析：评估现有项目文件及以往项目的经验教训，以识别相关方和其他支持性信息。
          • 数据表现(P512)
            • 相关方映射分析/表现：利用不同方法对相关方进行分类的方法。分类有助于团队与已识别的相关方建立关系。
          • 相关方映射分析/表现
            • 二维方格(P512)
              • 影响/作用方格
              • 相关方权力/利益方格：适用于小型项目、相关方与项目的关系很简单，相 关方之间的关系很简单
              • 权力/利益方格
              • 权力/影响方格
              • 作用：改变项目计划或执行的能力
              • 权力：职权
              • 利益：对项目结果的关注程度
              • 影响：主动参与项目的程度
              • 权低利低：仅监督
              • 权高利低：让他爽
              • 权低利高：常告知
              • 权高利高：重管理
            • 相关方立方体(P513)
              • 方格模型的改良形式。把方格中的要素组合成三维模型，项目经理和团队可据此分析相关方并引导相关方参与项目。
              • 作为一个多维模型，它将相关方视为一个多维实体，更好地加以分析，从而有助于沟通策略的制定。
            • 凸显模型(P513)权力
              • 根据相关方的权力、紧迫性和合法性，对相关方进行分类。用于确定已识别相关方的相对重要性
                • --权力:职位权力、对项目成果的影响能力
                • --紧迫性:是否需要立即关注，由于时间约束、重大利益诉求而导致
                • --合法性:有权参与，参与的适当性
              • 用邻近性代替合法性，用于评估团队成员参与项目工作的程度
              • 适用于:复杂的相关方大型社区、相关方社区内部存在复杂的关系网络
            • 影响方向(P513)
              • 根据相关方对项目工作或项目团队本身的影响方向，对相关方进行分类。
                • 向上(执行组织或客户组织、发起人和指导委员会的高级管理层);
                • 向下(临时贡献知识或技能的团队或专家);
                • 向外(项目团队外的相关方群体及其代表，如供应商、政府部门、公众、最终用户和监管部门);
                • 横向(项目经理的同级人员，如其他项目经理或中层管理人员，他们与项目经理竞争稀缺项目资源或者合作共享资源或信息)。
            • 优先级排序(P513)，适用于:
              • 项目有大量相关方
              • 相关方社区的成员频繁变化
              • 相关方和项目团队之间或相关方社区内部的关系复杂
          • 会议(P514)
            • 引导式研讨会、指导式小组讨论会、虚拟小组讨论
        • 输出：相关方登记册+变更请求
          • 相关方登记册(P514)
          • 变更请求(P514)
            • 首次开展识别相关方过程，不会提出任何变更请求。
            • 随着在后续项目期间继续识别相关方，新出现的相关方或关于现有相关方的新信息可能导致对产品、项目管理计划或项目文件提出变更请求。
    • ：识别相关方（ITTO），输入（项目章程+商业文件+项目管理计划+项目文件+协议）+工具与技术（数据收集+数据分析+数据表现+相关方映射分析/表现+会议）+输出（相关方登记册+变更请求）
      • 输入：项目章程+商业文件+项目管理计划+项目文件+协议
        • 项目章程：会列出关键相关方清单，还可能包含与相关方职责有关的信息。
        • 商业文件(P509)
          • 商业论证，确定项目目标，以及受项目影响的相关方的最初清单。
          • 效益管理计划，描述了如何实现商业论证中所述收益。它可能指出将从项目成果交付中获益并因此被视为相关方的个人及群体。
        • 项目管理计划(P509)
          • 首次识别相关方时，项目管理计划并不存在;但持续识别的过程中，需要参考:
            • 沟通管理计划----沟通与相关方参与之间存在密切联系。沟通管理计划中的信息是了解项目相关方的主要依据
            • 相关方参与计划----确定了用于有效引导相关方参与的管理策略和措施。
        • 项目文件(P510)
          • 变更日志，可能引入新的相关方，或改变相关方与项目的现有关系的性质。
          • 问题日志，可能为项目带来新的相关方，或改变现有相关方的参与类型。
          • 需求文件，可以提供关于潜在相关方的信息。
        • 协议(P510)
          • 协议的各方都是相关方，还可涉及其他相关方。
    • ：规划相关方参与，根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程
      • why
    • ：本过程的作用: 提供与相关方进行有效互动的可行计划
      • How
        • 工具与技术：数据收集+数据分析+决策+数据表现+相关方参与度评估矩阵
          • 数据收集(P520)
            • 标杆对照----将相关方分析的结果与其他被视为世界级的组织或项目的信息进行比较。
          • 数据分析(P521)
            • 假设条件和制约因素分析----分析当前的假设条件和制约因素，以合理裁剪相关方参与策略。
            • 根本原因分析----识别是什么根本原因导致了相关方对项目的某种支持水平，以便选择适当策略来改进其参与水平。
          • 决策(P521)
            • 优先级排序或者分级----具有最大利益和最高影响的相关方，通常应排在优先级清单的最前面。
          • 数据表现(P521)
            • 思维导图----对相关方信息、相互关系以及他们与组织的关系进行可视化整理。
            • 相关方参与度评估矩阵----用于将相关方当前参与水平与期望参与水平进行比较。
          • 相关方参与度评估矩阵(P521-P522)
            • 可在相关方参与评估矩阵中记录相关方的当前参与程度。
            • 通过分析，识别出当前参与程度与所需参与程度之间的差距。
            • 项目团队可以使用专家判断来制定行动和沟通方案，以消除上述差距。
        • 输出：相关方参与计划
          • 相关方参与计划(P522)
            • 相关方参与计划，确定用于促进相关方有效参与决策和执行的策略和行动。
            • 除了相关方登记册中的资料，相关方参与计划通常还包括:
              • 关键相关方的所需参与程度和当前参与程度;
              • 相关方变更的范围和影响;
              • 相关方之间的相互关系和潜在交叉;
            • 项目经理应该意识到相关方参与计划的敏感性，并采取恰当的预防措施
    • ：规划相关方参与（ITTO），输入（项目管理计划+项目文件）+工具与技术（数据收集+数据分析+决策+数据表现+相关方参与度评估矩阵）+输出（相关方参与计划）
      • 输入：项目管理计划+项目文件
        • 项目管理计划(P518)
          • 资源管理计划：包含关于团队成员及其他相关方的角色和职责的信息。
          • 沟通管理计划：用于相关方管理的沟通策略以及用于实施策略的计划，既是项目相关方管理中的各个过程的输入，又会收录来自这些过程的相关信息。
          • 风险管理计划：包含风险临界值或风险态度，有助于选择最佳的相关方参与策略组合。
        • 项目文件(P519)
          • 相关方登记册：提供项目相关方的清单，以及分类情况和其他信息。
    • ：管理相关方参与，与相关方进行沟通和协作，以满足其需要与期望，处理问题，并促进相关方合理参与的过程
      • why
    • ：本过程的作用，让项目经理能够提高相关方的支持，并尽可能降低相关方的抵制
      • 管理相关方参与包括以下活动:
        • 1. 引导参与，获得支持;
        • 2. 谈判沟通，管理期望
        • 3. 处理风险，预测问题;
        • 4. 澄清和解决问题
    • ：管理相关方参与（ITTO），输入（项目管理计划+项目文件）+工具与技术（沟通技能+人际关系与团队技能+基本规则）+输出（变更请求）
      • 输入：项目管理计划+项目文件
        • 项目管理计划(P525)
          • 沟通管理计划----描述与相关方沟通的方法、形式和技术。
          • 风险管理计划----描述了风险类别、风险偏好和报告格式。这些内容都可用于管理相关方参与。
          • 相关方参与计划----为管理相关方期望提供指导和信息。
          • 变更管理计划----描述了提交、评估和执行项目变更的过程。
        • 项目文件(P525)
          • 变更日志----会记录变更请求及其状态，并将其传递给适当的相关方。
          • 问题日志----会记录项目或相关方的关注点，以及关于处理问题的行动方案。
          • 经验教训登记册----在项目早期获取的与管理相关方参与有关的经验教训，可用于项目后期阶段，
          • 以提高本过程的效率和效果。
          • 相关方登记册----提供项目相关方清单，以及执行相关方参与计划所需的任何信息。
    • ：监督相关方参与，监督项目相关方关系，并通过修订参与策略和计划来引导相关方合理参与项目的过程。
      • why
    • ：本过程的作用：随着项目进展和环境变化，维持并提升相关方参与活动的效率和效果。
      • How：监督相关方参与（ITTO），输入（项目管理计划+项目文件）+工具与技术（数据分析+决策+数据表现+沟通技能+人际关系技能+会议）+输出（变更请求）
        • 输入：项目管理计划+项目文件
          • 项目管理计划(P532)
            • 资源管理计划----确定了对团队成员的管理方法。
            • 沟通管理计划----描述了适用于项目相关方的沟通计划和策略。
            • 相关方参与计划----定义了管理相关方需求和期望的计划。
          • 项目文件(P532)
            • 问题日志----记录了所有与项目和相关方有关的已知问题。
            • 经验教训登记册----在项目早期获取的经验教训，可用于项目后期阶段，以提高引导相关方参与的效率和效果。
            • 项目沟通记录----包含根据沟通管理计划和相关方参与计划而与相关方开展的项目沟通。
            • 风险登记册----记录了与相关方参与及互动有关的风险，它们的分类，以及潜在的应对措施。
            • 相关方登记册----记录了各种相关方信息，包括相关方名单、评估结果和分类情况。
        • 工具与技术：数据分析+决策+数据表现+沟通技能+人际关系技能+会议
          • 数据分析(P533)
            • 相关方分析：确定相关方群体和个人在项目任何特定时间的状态。
            • 根本原因分析：确定相关方参与未达预期效果的根本原因。
            • 备选方案分析：在相关方参与效果没有达到期望要求时，应该开展备选方案分析，评估应对偏差的各种备选方案。
          • 决策(P534)
            • 多标准决策分析：对考察相关方参与的成功程度的多种标准进行优先级排序和加权，识别出最适当的选项。
            • 投票：通过投票，选出应对相关方参与水平偏差的最佳方案。
          • 数据表现(P534)
            • 相关方参与度评估矩阵：用于跟踪每个相关方参与水平的变化，对相关方参与加以监督。
          • 沟通技能(P534)
            • 反馈----用于确保发送给相关方的信息被接收和理解。
            • 演示----为相关方提供清晰的信息。
          • 人际关系技能(P534)
            • 积极倾听----减少理解错误和沟通错误。
            • 文化意识----有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。
            • 领导力----成功的相关方参与，需要强有力的领导技能，以传递愿景并激励相关方支持项目工作和成果。
            • 人际交往----了解关于相关方参与水平的信息。
            • 政治意识----有助于理解组织战略，理解谁能行使权力和施加影响，以及培养与这些相关方沟通的能力。
          • 会议(P535)
            • 状态会议、站会、回顾会、相关方参与计划中规定的其他任何会议。
            • 不再局限于互动最为理想但成本偏高的面对面会议，可采用成本较低的电话会议和电信技术相关的会议方式。
        • 输出：变更请求
          • 变更请求(P535)，包括用于改善相关方当前参与水平的纠正及预防措施。
      • 【重点】
        • 识别相关方的重要工具和输出
        • 相关方参与度评估矩阵的作用
        • 管理相关方参与的四个要点
          • 引导参与，获得支持
          • 谈判沟通，管理期望
          • 处理风险，预测问题
          • 澄清和解决问题
        • 事先:早识别、早分析、早参与;事后:管理相关方参与
    • 项目相关方管理的核心概念(P504)
      • 相关方，会受项目的积极或消极影响，或者能对项目施加积极或消极的影响的任何人
      • 强调结构化方法对识别所有相关方、进行相关方优先级排序，以及引导相关方参与的重要性
      • 为提高项目成功的可能性，应该在项目章程被批准、项目经理被委任，以及团队开始组建之后，尽早开始识别相关方并引导相关方参与
      • 相关方满意度应作为项目目标加以识别和管理
      • 有效引导相关方参与的关键是:与所有相关方保持持续沟通(包括团队成员)，以理解他们的需求和期望、处理所发生的问题、管理利益冲突，并促进相关方参与项目决策和活动
    • 项目相关方管理的发展趋势和新兴实践(P505)
      • “相关方”的外延正在扩大：管机构、游说团体、环保人士、金融组织、媒体，以及自认为是相关方的人员
      • 应用“共创”概念，咨询最受项目工作或成果影响的相关方
      • 关注与相关方有效参与程度有关的正面(更积极支持带来的效益)及负面价值(未有效参与造成的真实成本)
    • 在敏捷和适应型环境中需要考虑的因素(P506)
      • 适应型团队会直接与相关方互动，而不是通过层层的管理级别
      • 在整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出项目调整，从而节约成本，提高项目成功的可能性
      • 为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明
    • 项目相关方管理过程
      • 启动过程组：识别相关方
        • 之一“识别相关方”P507
          • what
      • 规划过程组：规划相关方参与
        • 之二“规划相关方参与”P516
          • what
      • 执行过程组：管理相关方参与
        • 之三“管理相关方参与” P523
          • what
          • How
            • 工具与技术：沟通技能+人际关系与团队技能+基本规则
              • 沟通技能(P527)
                • 应根据沟通管理计划，针对每个相关方采取相应的沟通方法。
                • 反馈机制，来了解相关方对各种项目管理活动的关键决策的反应。
              • 人际关系与团队技能(P527)
                • 冲突管理----项目经理应确保及时解决冲突。
                • 文化意识----有助于项目经理和团队通过考虑文化差异和相关方需求，来实现有效沟通。
                • 政治意识----通过了解项目内外的权力关系，建立政治意识。
                • 谈判----用于获得支持或达成关于支持项目工作或成果的协议，并解决团队内部或团队与其他相关方之间的冲突。
                • 观察和交谈----及时了解项目团队成员和其他相关方的工作和态度。
              • 基本规则(P528)
                • 根据团队章程中定义的基本规则，来明确项目团队成员和其他相关方应该采取什么行为去引导相关方参与。
            • 输出：变更请求(P528)
              • 作为管理相关方参与的结果，项目范围或产品范围可能需要变更。
      • 监控过程组：监督相关方参与
        • 之四“监督相关方参与”P530
          • what
• 备考攻略
  • 第1章 引论
    • 1.1 项目管理知识体系
      • 1.1.1 概述
        • 项目管理知识体系（Project Managment Body of Knuwledge,PMBOK）是项目管理领域（职业和学科）全部知识的综合。
        • PMBOK是项目管理职业和学科的基础。
      • 1.1.2 《PMBOK指南》
        • 《PMBOK指南》是PMI发布的一份全球性的项目管理知识体系文件。它起源于PMI在1981年至1983年所做的“道德、标准和认证”研究项目。在1996年正是出第1版。概括项目管理知识体系中被普遍公认为良好做法的那一部分内容。
        • 在学习和应用《PMBOK指南》时，需要注意：
          • 运用到具体项目时，还需要掌握该项目所在领域的独特知识。
          • 只针对单个项目管理。而不是项目集或项目组合的管理。
          • 没有收录哪些通用的、非专门用于管理项目的知识。
          • 没有收录那些只适用于某类特别项目的项目管理知识。
          • 没有收录那些尚不成熟的项目管理做法。
      • 1.1.3 《PMBOK®指南》第6版
        • 可以把《PMBOK®指南》的主要内容概述为：在项目管理基本概念的支持下，项目管理的五大过程组与十大知识领域之间形成纵横交叉的严密控制网，来实现对项目中的关键节点的控制，极大地提高项目成功的可能性。
      • 1.1.4 《PMBOK®指南》的作用
        • 用于指导项目管理实践，使项目管理知识广泛共享，避免因“重复发明轮子”而浪费时间和精力。
        • 对促进全球项目管理资格认证、培训和教育的发展，都起到了极其重要的作用。
        • 对促进项目管理基本术语的科学化、规范化与统一化起到了重要作用，有助于人们就项目管理主题进行交流，降低沟通成本。
      • 1.1.5 PMP®考试大纲
        • 总共200道考题中所占的题目比例：人员部分42%，过程部分50%，商业环境部分8%。
        • 由于《PMP®考试大纲》写得很粗略，考生即便认真阅读，也不一定能读出多少内涵。所以，考生没有必要专门阅读。
    • 1.2 战略目标、项目和运营
      • 1.2.1 战略目标及其实现手段
        • 组织需要通过做项目来创造有利于分项和总体战略目标实现的条件。然后，在日常运营中，持续有效地使用这些条件，获取收益，从而实现分项和总体战略目标。项目和运营都是实现战略目标的手段。
        • 战略目标、项目和运营之间的关系
      • 1.2.2 项目组合与项目集
        • 项目组合是为实现战略目标而被集中管理的一些项目。项目组合通常并非一成不变，需要定期审查、删减、补充。根据优先顺利分配资源。
        • 项目集是相互关联并被协调管理的一组项目，也就是通常所说的一系列配套项目。项目集是为了抓住项目之间的横向联系来协调管理，以便获得各项目分别管理所不能获得的更大效益。
        • 项目组合与项目集的区别
      • 1.2.3 项目与子项目
        • 项目是为创造独特的产品、服务或成果而进行的临时性工作。具有临时性、独特性和成果导向性。
        • 项目经常可以被划分成一些子项目，有利于管理。项目与子项目的概念是相对的。
        • 在项目或子项目内部，又有可交付成果、工作包、进度活动等概念。
          • 工作包是项目中最小的可交付成果。
          • 进度活动则是为完成工作包而必须开展的具体活动。
        • 相关概念的层次结构
      • 1.2.4 项目与运营
        • 组织所做的工作可以分为两类：项目与运营。它们有许多共同之处：都由人来做，都受制于有限的资源，都要被规划、执行与监控，都要为组织的经营和战略目标服务。
        • 项目与运营的主要区别在于：
          • 项目是临时的，而运营是持续不断的。
          • 项目是要创造独特的可交付成果，而运营是要产出同样的结果。
          • 项目可交付成果的开发过程是渐进明细的，而运营是在标准化的生产线上或根据标准化的服务流程开展的。
        • 在实际工作中，持续性的运营往往可以被划分为许多临时性的项目。
        • 在组织中，运营与项目相互支持、相互协调，共同为实现组织的经营目标和战略目标服务。
    • 1.3 项目的特点
      • 1.3.1 项目的普遍性
        • 项目是为组织的经营需要与战略目标服务的。组织中会存在不同层级的项目，其规模、复杂程度可能相差很大。任何一个需要在特定时间内解决的问题都是项目。
        • PMP®考试题目中的“项目”，一般都是中等以上规模且跨专业、跨部门的项目，而不是很小的单专业项目。
      • 1.3.2 项目的临时性
        • 临时性，是指项目有明确的开始时间和明确的结束时间。
        • 项目无论何因何时结束，都必须经过既定的批准程序。
        • 项目的临时性决定了项目团队的临时性。
        • 临时性的项目所创造的产品、服务或成果，具有可持续的长期生命力。
      • 1.3.3 项目的独特性
        • 独特性，也叫“一次性”，只做一次的事肯定是独特的。
        • 把工作当项目来做，就必须看重其独特性，做出特色。
      • 1.3.4 项目的成果导向性
        • 项目所要创造的产品、服务或成果，可以统称为“可交付成果”（Deliverable）。
        • 必须坚持以可交付成果为导向，做出符合要求的成果，防止只有苦劳而没有功劳。
      • 1.3.5 项目的渐进明细性
        • 项目具有渐进明细性，即应该在连续积累中分步骤开发，以便逐步明确项目的细节特征。
        • 项目的特点应该随着时间的推移、情况的明朗和信息的增加而逐渐细化出来。
        • 渐进明细必须在确定的项目范围边界之内进行，不能“溜出”项目边界！
    • 1.4 战略管理、项目管理和运营管理
      • 1.4.1 战略管理与项目组合管理
        • 战略管理旨在确定组织的长远发展方向和战略目标。
        • 项目组合管理是要排列所有备选项目的优先顺序，并选择一系列排序靠前的、最有利于实现战略目标的项目（正确的项目）来做。项目组合管理的出发点是组织的战略目标和资源限制。项目组合管理其实是进行投资决策。项目组合经理往往由组织中的高级管理人员（如副总裁）兼任。
      • 1.4.2 项目集管理
        • 项目集管理是要正确地完成一系列相互关联的项目。它通过管理项目之间的内在联系，取得每个项目单独管理所不能取得的效益。平等看待同一项目集中的所有项目，重点管理项目之间的相互联系，通过它们之间的有效配合来取得更大的效益。
        • 项目集管理旨在正确地完成一系列相互配套的项目，获得更大的效益。
      • 1.4.3 项目管理与运营管理
        • 项目管理旨在正确地完成单个项目。
        • 运营管理是确保持续且有效地应用项目或项目集所产出的生产能力或服务能力。
      • 战略管理、项目组合管理、项目集管理、项目管理与运营管理的主要区别
      • 1.4.4 组织级项目管理
        • 组织级项目管理是组织中的项目、项目集和项目组合管理做法，以及有利于这些做法的推行的各种因素的总和。
    • 1.5 项目管理的基本内容
      • 1.5.1 项目目标
        • 从狭义上讲，做项目就是要在规定的范围、进度、成本和质量要求之下完成项目可交付成果。项目范围、进度、成本和质量，是用于规定项目目标的四个必不可少的维度，缺一不可。
        • 从广义上讲，做项目就是要满足项目相关方在项目上的利益追求。
        • 三重制约
      • 1.5.2 项目目标各维度的优先顺序
        • 项目的范围、进度、成本和质量这四个维度紧密相连，既相互依存又相互竞争。
        • 在具体的项目上，必须排列各维度的优先顺序，牺牲排序靠后的维度来保全排序靠前的维度。
        • 在某个具体项目上，它们的优先顺序通常由高级管理层而不是项目经理决定。项目经理需要在项目规划和执行过程中贯彻高级管理层所决定的优先顺序。
        • 不同的项目相关方可能对哪个维度更重要有不同意见，从而增加管理项目的难度。
        • 如果项目产品是为某个外在事件（如奥运会开幕）服务的，且该外在事件的开始时间无法更改，那么“进度”往往是最重要的维度。
        • 笼统地讲，项目的范围、进度、成本和质量等分目标没有优先顺序；在具体项目上的优先顺序由高级管理层决定。
      • 1.5.3 项目目的
        • 项目目标是指要做出怎样的项目可交付成果（符合范围、进度、成本和质量要求），而项目目的是指为什么要做出这样的项目可交付成果（这个成果能够带来什么效益）。
        • 《PMBOK®指南》指出，项目应该具有驱动组织变革和为组织创造商业价值的特性。这两条其实就是项目目的，即组织做项目的根本原因。
        • 项目经理应该从组织变革管理的高度来做项目，把项目看成变革型项目，即实现组织变革的手段。
        • 《PMBOK®指南》中，除非特别说明，项目都是组织内部的，而非为外部客户而做的。
        • “效益（benefit）”和“价值（value）”经常同义。如果要区分，那就是效益-成本=价值，其中成本是为获得效益所付出的代价。
      • 1.5.4 项目管理的实现过程
        • 项目管理是通过整合开展49个基本的项目管理过程来实现的。
        • 管理一个项目，就需要应用合适的项目管理过程，做好以下工作：
          • 与项目主要相关方沟通，识别他们的项目需求。
          • 分析相关方的项目需求，了解项目需求之间的一致性、协调性和矛盾性。
          • 权衡相互竞争（矛盾）的项目需求，寻找最佳平衡点。
          • 建立具体、明确且现实可行的项目目标。
          • 把项目目标转化为具体的实施计划，组建项目团队具体实施。
          • 对项目进展情况进行动态监督与控制，及时纠正偏差，保证项目顺利实施。
          • 对项目阶段或整个项目进行正式收尾工作，结束阶段或整个项目。
        • 在整合管理的指导之下：
          • （1）规划该做什么（范围管理）。
          • （2）规划该在什么时候做（进度管理）。
          • （3）规划该用多大成本做（成本管理）。
          • （4）规划该做到什么质量要求（质量管理）。
          • （5）把以上步骤得到的范围、进度、成本和质量计划整合成初步的项目目标计划。
          • （6）针对初步的项目目标计划，识别和分析项目风险（风险管理）。
          • （7）根据风险分析结果，调整初步的项目目标计划，得到确定的项目目标计划。
          • （8）安排所需资源（特别是人力资源）去执行确定的项目目标计划。先使用组织内部已有的资源（资源管理），再通过采购获取组织缺少的资源（采购管理）。
          • （9）始终保持与组织内外部项目工作人员密切沟通（沟通管理）。
          • （10）通过积极与各种相关方打交道，来提升相关方对项目的支持，削弱相关方对项目的抵制，促进项目成功（相关方管理）。
        • 项目管理十大知识领域的关系
        • 要有效地管理项目，还要掌握：
          • 应用领域的知识、标准与法规。
          • 对项目环境的理解。
          • 通用的管理知识。
          • 人际关系技能。
  • 第2章 项目运行环境与项目经理
    • 2.1 项目执行组织
      • 《PMBOK®指南》和PMP®考试中的“项目”，都是在一个或几个组织中开展的。这个或这些组织就是“项目执行组织”，也就是平常所说的“项目所在单位”。
      • 2.1.1 组织作为一个系统
        • 系统是由一系列相互关联的组件所构成的复杂整体。在一个有效的系统中，系统整体的功能要远大于各组件的功能之和。系统可以分成：自然系统与人造系统，静态系统与动态系统，封闭系统与开放系统。毫无疑问，组织是一个开放且动态的人造系统。
        • 组织的开放性是指组织会与环境互动。组织既要从环境获取各种输入，又会向环境输出所生成的各种成果。
        • 组织中的高级管理层负责组织系统建设，以便主要用系统而不是靠个人去管人管事。系统由三个要素构成：组件、组件属性以及组件关系。
        • 《PMBOK®指南》中重点讨论了组织系统的三大决定因素：组织治理框架、管理要素（原则）和组织结构。
      • 2.1.2 组织治理与项目治理
        • 组织治理框架是组织中的重要决策制定框架，即在组织中，谁有权在什么时候用什么方法做出并推行什么重要决策，如董事长、总经理、财务总监、PMO主任分别有权做出什么决策。
        • 以下四条是最重要的决策规则：
          • （1）关于如何处理公司与股东及其他相关方的权责利关系的规则。
          • （2）关于如何协调各相关方的利益矛盾的规则。
          • （3）关于董事会如何代表各相关方对公司业务进行监督和控制的规则。
          • （4）关于公司如何向各相关方发布业务信息的规则。
        • 公司董事会做公司治理，公司总经理做公司管理。项目治理是组织为项目建立的高级别的指导、支持、监督与控制框架。项目治理是联系组织治理与项目管理的桥梁
        • 项目治理与组织治理、项目管理的关系
        • 项目经理在接手某个项目之前，必须了解有关的项目治理框架，争取更好的保障。
      • 2.1.3 基本的管理要素
      • 2.1.4 组织结构的主要类型
        • 有机型或简约型。
        • 职能型。
        • 事业部型。
        • 矩阵型（包括弱矩阵型、平衡矩阵型和强矩阵型）。
        • 项目型。
        • 虚拟型。
        • 混合型。
        • 项目管理办公室（PMO）型。
        • PMP®考试中可能出现的“紧密型矩阵”，并不是一种特别的矩阵型组织结构，而是指矩阵型组织结构之下的项目成员集中办公。
      • 2.1.5 组织结构对项目的影响
        • 职能通常是：把某个项目放到现有的某个职能部门内部去做
        • 矩阵型通常是：为某个项目组建专门的项目部，其中部分员工全职做项目，部分员工兼职做项目（仍兼做各职能部门的工作）。
        • 项目型通常是：为某个项目组建专门的项目部，其全部员工都全职做项目。
        • 不同组织形式的主要区别
        • 矩阵型组织最常用。它能够同时利用职能型组织和项目型组织的优点。其主要特点是：
          • ①借资源，即许多项目团队成员是从职能部门借来的（可能只是在项目上兼职）；
          • ②两个老板，即项目团队成员需要同时接受项目经理和职能经理的领导。
          • 这两个特点决定了矩阵型组织中的项目经理并没有管理项目的全权。
      • 2.1.6 项目管理办公室
        • PMO是组织中指导、协调和支持项目管理工作的一个常设职能部门，也就是管理项目管理的常设职能部门。它负责：
          • 制定和贯彻标准化的项目管理方法论（包括工作流程与规章制度等）
          • 协调所辖各项目对资源、工具、技术和方法的共享
          • 为所辖各项目提供必要的支持
        • PMO分成以下三种：
          • 支持型
          • 控制型
          • 指令型
    • 2.2 事业环境因素和组织过程资产
      • 2.2.1 事业环境因素
        • 事业环境因素是能影响项目但项目团队无法控制的任何内外部环境因素。内部环境因素来自项目执行组织内部，外部环境因素来自项目执行组织外部。
        • 事业环境因素可能提高或限制项目管理的灵活性，可能对项目有积极或消极的影响。
        • 组织内部的事业环境因素
        • 组织外部的事业环境因素
        • 《PMBOK®指南》中只有三个过程会导致事业环境因素更新
          • 获取资源
          • 建设团队
          • 管理团队
      • 2.2.2 组织过程资产
        • 组织过程资产是来自执行组织的，正式或非正式的政策、流程、程序、模板、工作指南和知识库（数据库），用于帮助项目成功。
        • 在实际工作中，组织过程资产与事业环境因素肯定是交叉的。
        • 究竟是资产还是环境取决于项目经理的态度。主动利用就是资产；不想利用它但又不得不遵守就是环境。
        • 组织过程资产的主要内容
        • PMP®考试中，一定要假设项目执行组织有很好的历史资料库，有很好的组织过程资产积累。
        • 在整个项目生命周期中，要经常更新组织过程资产；在项目阶段结束及整个项目结束时，必须更新组织过程资产。
        • 组织过程资产更新的主要内容
      • 2.2.3 事业环境因素和组织过程资产的动态性
        • 在整个项目期间，事业环境因素和组织过程资产都并非一成不变，而是会动态变化的。
        • 对于事业环境因素，项目经理应该：
          • 持续关注和定期调查商业环境的变化
          • 评估环境变化对项目的影响
          • 为适应环境变化而提出对项目的变更建议
          • 跟踪经批准的变更的实施情况，评价变更的有效性。
        • 对于组织过程资产，项目经理应该：
          • 持续关注新积累的经验教训、工作流程、工作模板和工作数据等。
          • 分析其与本项目的相关性，加以选择利用。
    • 2.3 项目合规
      • 2.3.1 概述
        • 项目合规是指项目必须符合相关的法律、规则、标准或要求，包括内部合规和外部合规。
          • 内部合规是指符合项目内部以及组织内部的规则或要求。
          • 外部合规是指符合项目所在组织外部的法律、规则或标准。
          • 通常，要通过内部监控来确保内部合规，再以内部合规来确保外部合规。
      • 2.3.2 合规要求
        • 对项目的合规要求会来自许多不同方面，如国际组织、政府机构、行业协会和项目执行组织等。各种合规要求对项目的影响也会有所不同。有些合规要求可归类于事业环境因素，有些可归类于组织过程资产，它们都会从外部对本项目施加影响。还有些合规要求则必须作为本项目的一部分，列入项目工作分解结构和相关项目计划加以实施。
      • 2.3.3 合规管理的步骤
        • 项目合规管理的基本步骤包括：
          • 调查和确认项目合规要求
          • 分析不合规的后果
          • 分析可能导致不合规的主要威胁
          • 为方便管理，对合规要求进行归类
          • 采取必要的方法和措施来响应合规要求
          • 采取合适的措施支持对合规要求的响应
          • 内部评估项目合规程度
          • 外部审计项目合规程度
    • 2.4 项目生命周期
      • 2.4.1 概述
        • 项目生命周期是项目从开始到结束所经历的一系列技术工作阶段。每个阶段都有阶段准入标准、应完成的工作和应提交的可交付成果，都需要有阶段验收标准与阶段放行口。
        • 项目生命周期阶段的多少与项目工期长短没有必然联系，而取决于所需的管理和控制的严格程度。
        • 在项目关闭阶段，对资源的需求必须急剧下降，因为收尾要快，不能拖拖拉拉。
      • 2.4.2 项目生命周期的特点
        • 项目生命周期是按技术工作来划分项目阶段的，每个阶段都要完成不同的技术任务。
        • 对于项目生命周期，需要注意以下几点：
          • 不同类型的项目有不同的阶段划分
          • 每个阶段都可看作一个单独的项目或子项目
          • 通常，一个阶段结束后，才开始另一个阶段（阶段之间为先后顺序关系）
          • 阶段之间也可以是迭代关系
          • 如果一个项目包括几个相对独立的部分，各阶段既可能在各个组成部分同步演进，也可能不同步演进。
          • 一个阶段的结束并不一定意味着下个阶段的开始。
      • 2.4.3 项目生命周期的类型
        • 《PMBOK®指南》列出了以下五种不同的项目生命周期：
          • 预测型生命周期，也叫计划驱动型生命周期，是先编制好项目计划，详细定义项目产品及所需开展的工作，再严格按计划开展工作并完成已定义好的产品。
          • 迭代型生命周期，是通过越来越精细地重复开展同种类的技术工作来不断优化产品功能。
          • 增量型生命周期，是经过一个又一个固定时间段（称为“时间盒”）来逐渐增加产品功能。
          • 适应型生命周期，也叫敏捷型或变更驱动型生命周期，是迭代型和增量型的混合。
          • 混合型生命周期，是预测型和适应型的混合。
        • 开展迭代，是因为不可能一次就做好某个功能；进行增量开发，是因为不可能一次就做全所有功能。
        • 预测型&迭代型&增量型
          • 预测型
          • 迭代型
          • 增量型
        • 预测型和适应型项目生命周期比较
      • 2.4.4 产品生命周期
        • 产品生命周期是从项目开始到项目结束再到项目产品运营终止（退出市场）的全过程。项目生命周期只是产品生命周期中的一个产品阶段。
        • 产品生命周期由一系列产品阶段构成，如研发阶段、导入阶段、上升阶段、成熟阶段、衰退阶段和退出阶段。
        • 与产品生命周期相对应的成本概念，是“生命周期成本”，即在整个产品生命周期中所发生的全部成本，包括项目建设成本、项目建成后的运营成本，以及产品退市的处理成本。
    • 2.5 项目经理
      • 2.5.1 项目经理的定义
        • 项目经理是受项目执行组织委派，领导项目团队去实现项目目标的个人。一个项目可能有多个执行组织，而每个执行组织都有一个对本组织负责的项目经理。
        • 由于不同项目在组织中具有不同的重要性，项目经理在组织中的地位也就高低不等。
      • 2.5.2 项目经理的责任
        • 项目经理对所管理的项目、项目所在组织、项目管理职业以及相关行业和学科，都负有程度不等的责任。
        • 项目经理是所管理的项目的唯一责任点，必须确保在规定的范围、进度、成本和质量要求之下交付出可交付成果，并满足项目相关方在项目上的利益追求。
      • 2.5.3 项目经理的胜任力
        • 胜任力是指为了胜任某个特定岗位而必须具备的知识、技能和态度，以及相应的行为。
        • 不同于一般意义上的“能力”，“胜任力”专门针对特定岗位或特定工作而言。
        • 胜任力开发需要通过以下五个阶段：
          • 知自己无能
          • 知道自己无能
          • 知道自己有能
          • 不知道自己有能
          • 故意保持自己有能
        • PMI发布的“人才三角”，是高层级的项目经理胜任力框架，其中包含项目管理技术、领导力以及战略和商务管理三个维度。
      • 2.5.4 项目经理的权力
        • 在项目管理中，项目经理往往需要在正式权力（职位权力）不足的情况下，组织其他人来完成任务，所以他必须知道如何取得他人的合作。
        • 各种权力及其归类和解释
        • 来自人身的权力是长久有效的权力，是每个人都应该尽力追求的。正式权力不足的项目经理，就更应该注重自己的参照权力、专家权力和魅力权力。
      • 2.5.5 领导风格
        • 领导，主要是对人；管理，主要是对事。领导是指创建愿景，使员工看到愿景，并通过启发和激励带领员工朝愿景前进。
        • 项目经理应该用源自职位的权力做好管理，用源自人身的权力做好领导。
        • 《PMBOK®指南》列出了六种常用的领导风格：
          • 放任型
          • 交易型
          • 仆人型
          • 变革型
          • 魅力型
          • 交互型
        • 领导风格划分成：
          • 命令式
          • 推销式
          • 参与式
          • 授权式
        • 领导风格甚至可以被最粗略地分为：
          • 独裁式
          • 民主式
          • 放任式
        • 三种领导风格的比较
        • 究竟采用哪种领导风格或管理风格，需要因人因事因时而异。
    • 2.6项目经理作为整合者
      • 2.6.1 概述
        • 项目经理需要懂技术，具备一定的技术能力，但不必是技术专家。
        • 作为跨专业的项目的管理者，项目经理必须是一个整合者。
        • 项目经理绝对不能把整合管理授权给别人去做，而必须自己亲自做。
      • 2.6.2 项目的复杂性
        • 项目的复杂性主要来自三个方面
          • 一是系统行为
          • 二是人类行为
          • 三是事物的模糊性
      • 2.6.3 两个角度
        • 一是项目外部角度。使项目符合所在组织的需要。
        • 二是项目内部角度。使项目团队中的每个人都朝着同一个方向努力。
      • 2.6.4 三个层面
        • 一是过程层面。
        • 二是认知层面。
        • 三是背景层面。
      • 2.6.5 四大技能
        • 一是掌握项目管理的主要技术，能够自己亲自做事。
        • 二是具备强大的领导力，能够激励和领导别人做事。
        • 三是掌握一些商务管理知识，能够取得职能经理的支持，并使项目更好地服务于组织经营。
        • 四是掌握一些战略管理知识，能够有效地与高层管理人员对话，并使项目更好地服务于组织的战略目标。
      • 2.6.6 五大关系
        • 一是项目内部的关系
        • 二是项目与所在组织的关系
        • 三是项目与所在行业的关系
        • 四是项目与项目管理职业的关系
        • 五是项目与其他职业的关系
  • 第3章 项目管理过程
    • 3.1 过程及其相互关系
      • 3.1.1 定义和作用
        • 定义：过程是旨在完成预定目标的、一系列相互关联的活动的集合，以便运用一系列工具与技术把特定的输入转化成特定的输出。
        • 作用：《PMBOK®指南》用项目管理过程把项目管理方法结构化，使其便于操作。
      • 3.1.2 项目管理过程之间的逻辑关系
        • 为了讨论的方便，项目管理各过程以相互独立、界限分明、首尾相连的形式，出现在《PMBOK®指南》中。
        • 理解项目管理各过程之间的逻辑关系时，需要注意以下几点：
          • 在实际工作中，各过程之间的界面不一定非常明确，它们之间可能有很大程度的相互交叠，即并行开展。
          • 每个过程在一个项目上可能需要反复进行几次甚至许多次。
            • 一种是每次都在更加详细的程度上进行。
            • 另一种是在下一个过程的进行期间，发现有必要重新进行上一个过程。
          • 监控过程实际上会针对所有其他过程，而不只是针对执行过程，因为任何工作都要被监控。
          • 除了专门开展的事后监控，更多的监控工作会随被监控工作同时开展，而不能在时间段上独立存在。
          • 一个项目或子项目或某个阶段，在正式启动之后、正式结束之前，往往需要反复开展规划、执行与监控过程。
        • 不能用纯直线型思维去理解项目管理各过程之间的关系，各过程之间通常存在交叠和循环关系。
      • 3.1.3 项目管理过程的开展频率
        • 仅开展一次或仅在预定义时点开展的项目管理过程
        • 需要定期开展的过程
        • 需要持续开展的过程
    • 3.2 过程组
      • 3.2.1 过程组与戴明环
        • 《PMBOK®指南》把49个项目管理过程归纳为五大过程组，即启动、规划、执行、监控和收尾。
          • 启动过程组有2个过程
          • 规划过程组有24个过程
          • 执行过程组有10个过程
          • 监控过程组有12个过程
          • 收尾过程组有1个过程
          • 图例
        • 戴明环：五大过程组的理论基础是著名的“计划—实施—检查—行动”循环（PDCA循环）
      • 3.2.2 过程组之间的关系
        • 项目管理各过程之间的交叠和循环关系，当然就造成了项目管理五大过程组之间的交叠和循环关系。
        • 《PMBOK®指南》特别强调“项目阶段不同于项目管理过程组”。项目阶段关注的是项目的技术工作，即每个阶段开展不同的技术工作。项目管理过程组关注的是项目的管理工作，即各过程组开展不同的管理工作。
        • 实际上，任何一个项目管理过程都可以在任何一个项目阶段开展。甚至在项目的起始阶段也可以开展结束项目或阶段过程，考虑将来的项目收尾该怎么做。
        • 项目管理五大过程组之间的主要关系
      • 3.2.3 启动和收尾过程组的主要工作
        • 启动过程组
          • 启动过程组旨在制定项目的总体目标，并宣布项目正式立项。启动过程组其实是办理项目的立项手续。
          • 通常，项目经理参与但并不领导项目启动工作。启动工作由项目发起人或高级管理层领导。
        • 收尾过程组
          • 收尾过程组旨在正式关闭项目，并更新组织过程资产。
          • 需要注意：
            • 如果项目是通过合同来做的，对每个合同都要进行合同收尾。
            • 项目的产品范围或技术工作全部完成了，并不代表项目结束。项目必须经过正式的结束项目或阶段过程，完成行政收尾工作，才可以正式关闭。
            • 收尾工作不仅针对整个项目，也要在每个阶段结束时进行。
            • 做好向后续阶段或成果运营的知识转移，以支持后续阶段或成果运营的开展。
          • 收尾过程组并非用来解决项目中存在的问题，所有问题都必须通过监控过程组和其他三大过程组加以解决。
      • 3.2.4 规划过程组的工作流程
        • 规划过程组旨在细化项目目标，并为实现项目目标编制项目计划（包括项目管理计划和各种项目文件）。
        • 在项目范围管理、进度管理、成本管理、质量管理、风险管理和采购管理这六大知识领域，程序性计划和实体性计划是分开的。
        • 规划过程组的内容比较多，总共有24个项目管理过程。为便于掌握，应该对项目计划（包括项目管理计划和各种项目文件）编制的步骤进行总结
        • 规划过程组的总体工作流程
      • 3.2.5 执行过程组的工作流程
        • 执行过程组旨在获取资源，开展项目计划中的项目工作，实现项目目标。
        • 执行过程组内部的工作流程，可以概括为如下10个步骤：
          • 第1步：获取项目资源，包括人力和实物资源（获取资源过程）。
          • 第2步：开展项目团队建设（建设团队过程）。
          • 第3步：管理项目团队（管理团队过程）。
          • 第4步：管理相关方参与（管理相关方参与过程）。
          • 第5步：对外购部分进行采购，选择卖方，签订采购合同（实施采购过程）。
          • 第6步：按项目计划开展项目实施（指导与管理项目工作过程）。
          • 第7步：管理项目知识（管理项目知识过程）。
          • 第8步：开展质量管理，包括质量保证（管理质量过程）。
          • 第9步：实施风险应对策略和措施（实施风险应对过程）。
          • 第10步：发布项目信息（管理沟通过程）。
        • 执行过程组的主要成果是工作绩效数据和可交付成果。
      • 3.2.6 监控过程组内的工作流程
        • 监控过程组旨在监督项目进展情况，发现并分析实际与计划的偏差，提出并审批变更请求，以保证项目目标的实现。
        • 监控过程组的总体工作流程如下：
          • 第1步：开展基层局部监控。
          • 第2步：开展高层全局监控，监控整个项目的绩效。
          • 第3步：审批变更请求。
        • 无论是哪个过程提出的变更请求，都必须提交实施整体变更控制过程审批。
        • 监控过程组的总体工作流程
    • 3.3 数据、信息和报告
      • 3.3.1 工作绩效数据
        • 工作绩效数据（Work Performance Data）是在项目执行过程中，一边执行一边收集起来的，未经任何加工整理的原始资料，用于真实、完整地记录工作的执行情况。它是指导与管理项目工作过程的输出，是项目监控时用来与计划要求做比较的实际数据。
      • 3.3.2 工作绩效信息
        • 工作绩效信息（Work Performance Information）是对工作绩效数据进行加工整理后得到的，是相互联系且有明确的产生背景的数据。它是全部的基层局部监控过程的输出，并成为监控项目工作过程（高层全局监控过程之一）的输入。
        • 监督风险过程，用于单个项目风险时，为基层局部的监控过程；用于整体项目风险时，则为高层全局的监控过程。
      • 3.3.3 工作绩效报告
        • 工作绩效报告（Work Performance Reports）则是对工作绩效信息进行进一步加工、整理、汇编而得到的，关于项目绩效的专题或综合报告，可以定期编制，或为某种特殊目的而专门编制（如配合领导即将对项目进行的检查）。
      • 工作绩效数据、工作绩效信息与工作绩效报告之间的主要区别
      • 工作绩效数据、信息与报告之间的关系
    • 3.4 全部过程的输入
      • 3.4.1 概述
        • 《PMBOK®指南》共列出了20个输入和73个输出。
          • 输入
            • 4个来自项目外部，即事业环境因素、组织过程资产、商业文件和卖方建议书；
            • 1个（协议）既可以来自项目外部，也可以来自项目内部；
            • 其他15个都是本项目内部产生的，即相应项目管理过程的输出。
            • 来自项目外部的协议有两种情况：
              • 一种是项目发起人之间关于发起项目的合作协议。
              • 另一种是从承包商的角度来看的它与业主之间的合同，该合同是承包商启动承包项目的依据。
          • 输出
            • 2个会成为项目最终的成果，即最终产品、服务或成果移交，最终报告；
            • 4个先成为本项目其他项目管理过程的输入，待最后更新后就成为最终成果，即事业环境因素更新、组织过程资产更新、采购文档更新、项目文件更新；
            • 67个都会成为本项目其他项目管理过程的输入，即仅在项目内部使用。
              • 注意：这67个输出在成为其他过程的输入时，除了项目章程、项目管理计划、项目资金需求、可交付成果、变更请求、批准的变更请求、协议、团队绩效评价、核实的可交付成果、验收的可交付成果、工作绩效数据、工作绩效信息和工作绩效报告这13个，其余54个都被归并到了“项目管理计划”“项目文件”“采购文档”和“其他过程的输出”中
            • 各种输出归并为输入的情况
              • 注：* 供方选择标准在《PMBOK®指南》第98页又被列为“项目文件”，这不合理。
            • 项目资金需求主要供发起人及时按量为项目准备资金，而非供项目团队内部使用，故没有归入“项目文件”。
            • “项目管理计划”是一份单一的文件，而“项目文件”和“采购文档”都不是单一的文件，只是各种文件的统称。
      • 3.4.2 事业环境因素和组织过程资产
        • 《PMBOK®指南》中共有40个过程使用事业环境因素这个输入
          • 全部2个启动过程。
          • 全部24个规划过程。·
          • 8个执行过程，即指导与管理项目工作、管理项目知识、管理沟通、管理相关方参与、实施采购、获取资源、建设团队、管理团队。只有“管理质量”和“实施风险应对”这两个执行过程没有事业环境因素这个输入。
          • 6个监控过程，即监控项目工作、实施整体变更控制、控制质量、监督沟通、监督相关方参与、控制采购。另外6个监控过程，即控制范围、确认范围、控制进度、控制成本、控制资源和监督风险，没有事业环境因素这个输入。
        • 在整个项目生命周期中，都要利用组织过程资产。在全部49个过程中，对47个过程列出了“组织过程资产”这个输入，只有以下2个监控过程不用组织过程资产：确认范围、监督风险。
      • 3.4.3 项目管理计划
        • 《PMBOK®指南》各过程的文件类输出，又可以分成两类：
          • 第一类是项目管理计划及其组成部分。项目管理计划是关于管理工作的安排和高层次的项目要求（项目基准）。
          • 第二类是各种各样的具体文件。规划阶段所编制的各种具体文件，则是关于技术工作的安排和细节性的项目要求（为了确保基准的实现）。
        • 在全部49个项目管理过程中，只有“制定项目章程”和“制订项目管理计划”这两个过程没有“项目管理计划”这个输入。
        • 各过程所使用的“项目管理计划”的具体内容不一定相同。例如，所有“规划××管理/参与过程”仅使用“项目管理计划”大纲，或已编制出的子管理计划。
      • 3.4.4 项目文件
        • 在全部49个项目管理过程中，只有6个过程没有“项目文件”这个输入，即制定项目章程、制订项目管理计划、规划范围管理、规划进度管理、定义活动、规划成本管理。
      • 3.4.5 其他输入
        • 其他输入与相应过程的对照
    • 3.5 全部过程的输出
      • 3.5.1 概述
        • 《PMBOK®指南》所列的73个输出中，只有4个是非文件类的输出，即可交付成果、核实的可交付成果、验收的可交付成果和最终产品、服务或成果移交（移交的可交付成果）。
      • 3.5.2 变更请求
        • 总共24个过程会提出变更请求
          • 1个启动过程，即识别相关方。重复开展识别相关方过程时，可能提出变更请求。
          • 4个规划过程，即定义活动、制订进度计划、规划风险应对、规划采购管理。
          • 8个执行过程，即指导与管理项目工作、管理质量、获取资源、建设团队、管理团队、实施风险应对、实施采购、管理相关方参与。其他2个执行过程，即管理项目知识、管理沟通，没有“变更请求”这个输出。
          • 除实施整体变更控制过程以外的全部（11个）监控过程，即监控项目工作、确认范围、控制范围、控制进度、控制成本、控制质量、控制资源、监督沟通、监督风险、控制采购、监督相关方参与。监控就是发现偏差，提出必要的变更请求。实施整体变更控制过程则专用于审批变更请求。
        • 变更请求主要是执行与监控过程的输出。因为收尾阶段不能再变更，所以收尾过程不会提出变更请求。
      • 3.5.3 项目管理计划更新
        • 总共26个过程会输出“项目管理计划更新”
          • 1个启动过程，即识别相关方。
          • 5个规划过程，即定义活动、制订进度计划、规划质量管理、规划沟通管理、规划风险应对。
          • 9个执行过程，即指导与管理项目工作、管理项目知识、管理质量、获取资源、建设团队、管理团队、管理沟通、实施采购、管理相关方参与。只有一个执行过程，即实施风险应对，不会导致项目管理计划更新。
          • 11个监控过程，即监控项目工作、实施整体变更控制、控制范围、控制进度、控制成本、控制质量、控制资源、监督沟通、监督风险、控制采购、监督相关方参与。只有一个监控过程，即确认范围，不会导致项目管理计划更新。
        • “项目管理计划更新”主要是执行和监控过程的输出。
      • 3.5.4 项目文件更新
        • 总共39个过程会输出“项目文件更新”。只有10个过程没有“项目文件更新”，即制定项目章程、制订项目管理计划、管理项目知识、规划范围管理、收集需求、规划进度管理、定义活动、规划成本管理、规划风险管理、规划相关方参与。
        • 除了管理项目知识过程，其余全部执行过程都有“项目文件更新”。全部监控过程都有“项目文件更新”。
        • 项目文件（Project Documents）并不是一个单一的文件，而是各种项目文件的统称。
        • 更新项目管理计划必须走变更流程、经过审批，而更新项目文件不一定要走流程审批。
      • 3.5.5 组织过程资产更新
        • 总共10个过程有“组织过程资产更新”这个输出
          • 1个规划过程，即规划采购管理。
          • 6个执行过程，即指导与管理项目工作、管理项目知识、获取资源、建设团队、管理沟通、实施采购。
          • 2个监控过程，即监督风险、控制采购。
          • 1个收尾过程，即结束项目或阶段。
        • 另外，《PMBOK®指南》中的3个过程有“事业环境因素更新”，即获取资源、建设团队、管理团队；1个过程有“采购文档更新”，即控制采购。
      • 3.5.6 其他输出
        • 除变更请求及各种更新以外的输出及其相应的项目管理过程
    • 3.6 全部过程的工具与技术
      • 《PMBOK®指南》总共列出了65个工具与技术（这里把一个技术组暂且当作一个技术看待），用于49个项目管理过程。其中有些工具与技术是2个或以上过程共用的。
      • 3.6.1 专家判断
        • 使用“专家判断”的35个过程是：
          • 全部2个启动过程，即制定项目章程、识别相关方。·
          • 22个规划过程。只有2个规划过程没有“专家判断”，即排列活动顺序、制定进度计划。
          • 5个执行过程，即指导与管理项目工作、管理项目知识、实施风险应对、实施采购、管理相关方参与。
          • 5个监控过程，即监控项目工作、实施整体变更控制、控制成本、监督沟通、控制采购。
          • 1个收尾过程，即结束项目或阶段。
      • 3.6.2 数据分析
        • 使用“数据分析”的32个过程是：
          • 1个启动过程，即识别相关方。
          • 18个规划过程。只有6个规划过程没有“数据分析”，即创建WBS、定义活动、排列活动顺序、规划资源管理、规划沟通管理、制订项目管理计划。
          • 2个执行过程，即管理质量、实施采购。
          • 10个监控过程。只有2个监控过程没有“数据分析”，即确认范围、监督沟通。
          • 1个收尾过程，即结束项目或阶段。
      • 3.6.3 会议
        • 使用“会议”的28个过程是：
          • 全部2个启动过程，即制定项目章程、识别相关方。
          • 15个规划过程，即制订项目管理计划、规划范围管理、规划进度管理、规划成本管理、规划质量管理、规划资源管理、规划沟通管理、规划风险管理、规划采购管理、规划相关方参与、定义活动、排列活动顺序、估算活动资源、识别风险、实施定性风险分析。
          • 4个执行过程，即指导与管理项目工作、建设团队、管理沟通、管理相关方参与。
          • 6个监控过程，即监控项目工作、实施整体变更控制、控制质量、监督沟通、监督风险、监督相关方参与。
          • 1个收尾过程，即结束项目或阶段。
      • 3.6.4 人际关系与团队技能
        • 这是一个技术组，其下属有17个技术。使用“人际关系与团队技能”的20个过程是：
          • 1个启动过程，即制定项目章程。
          • 8个规划过程，即制订项目管理计划、收集需求、定义范围、规划沟通管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对。
          • 8个执行过程。只有2个执行过程没有“人际关系与团队技能”，即指导与管理项目工作、管理质量。
          • 3个监控过程，即控制资源、监督沟通、监督相关方参与。
      • 3.6.5 数据收集
        • 这是一个技术组，其下属有9个技术。使用“数据收集”的13个过程是：
          • 全部2个启动过程，即制定项目章程、识别相关方。
          • 9个规划过程，即制订项目管理计划、规划质量管理、规划采购管理、收集需求、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、规划相关方参与。
          • 1个执行过程，即管理质量。
          • 1个监控过程，即控制质量。
      • 3.6.6 决策
        • 这是一个技术组，其下属有2个技术。使用“决策”的13个过程是：
          • 7个规划过程，即收集需求、定义范围、估算活动持续时间、估算成本、规划质量管理、规划风险应对、规划相关方参与。
          • 2个执行过程，即获取资源、管理质量。
          • 4个监控过程，即监控项目工作、实施整体变更控制、确认范围、监督相关方参与。
      • 3.6.7 项目管理信息系统
        • 使用“项目管理信息系统”的12个过程是：
          • 4个规划过程，即排列活动顺序、估算活动资源、制订进度计划、估算成本。
          • 4个执行过程，即指导与管理项目工作、管理团队、实施风险应对、管理沟通。
          • 4个监控过程，即控制进度、控制成本、控制资源、监督沟通。
      • 3.6.8 数据表现
        • 这是一个技术组，其下属有15个技术。使用“数据表现”的11个过程是：
          • 1个启动过程，即识别相关方。
          • 6个规划过程，即规划质量管理、规划资源管理、规划沟通管理、规划相关方参与、收集需求、实施定性风险分析。
          • 1个执行过程，即管理质量。
          • 3个监控过程，即控制质量、监督沟通、监督相关方参与。
      • 2～4个过程共用的工具与技术
      • 仅供一个过程使用的工具与技术
  • 第4章 项目整合管理
    • 4.1 概述
      • 4.1.1 基本概念
        • 整合是指协调、统一与综合。
          • 协调是指使各要素没有矛盾。
          • 统一是指使各要素都指向同样的目标。
          • 综合是指使各要素形成一个能发挥更大作用的新系统。
        • 项目整合管理是项目管理的核心，是为了实现项目各要素之间的相互协调，并在相互矛盾或竞争的目标中寻找最佳平衡点。
        • 整合管理涉及以下几个方面：
          • 项目内部
            • 在相互竞争的项目各分目标之间的整合
            • 在具有不同利益的各项目相关方之间的整合
            • 在项目所需要的不同专业工作之间的整合
            • 在项目管理的各过程之间的整合
            • 在管理与技术工作之间的整合
          • 项目外部
            • 项目目标与组织的战略目标之间的整合，确保项目目标符合组织战略。
            • 项目目标与组织的运营目标之间的整合，确保项目成果能够有效融入日常运营。
        • 需要整合的地方，无法一一列举，因为只要存在结合部，就需要整合。
      • 4.1.2 项目经理作为整合者
        • 项目经理在项目管理中的角色是多方面的，其中最重要的角色是整合者。作为整合者，项目经理必须看到项目的“大局图”，确保项目全局的利益。需做到：
          • 通过与项目相关方主动、充分的沟通，来了解他们对项目的需求。
          • 在相互竞争的众多相关方之间寻找平衡点。
          • 通过认真、细致的协调工作，来达到各种需求之间的平衡，实现整合。
        • 《PMBOK®指南》特别强调，项目经理必须亲自承担项目整合管理的工作，而不能把这个工作授权给任何其他团队成员去开展。
      • 4.1.3 整合管理在各知识领域中的地位
        • 项目整合管理是项目管理的管理哲学，是项目管理与传统管理的最大区别所在。“项目管理是以整合为主、分工为辅的管理”。
        • 从十大知识领域的相互关系来看，整合管理是项目管理的指导思想。
    • 4.2 各过程的输入与输出
      • 4.2.1 输入与输出的关系总览
        • 项目整合管理的实现过程包括制定项目章程、制订项目管理计划、指导与管理项目工作、管理项目知识、监控项目工作、实施整体变更控制和结束项目或阶段。这些过程通过输入与输出相互联系。前一个过程的输出往往就是后一个或几个过程的输入。
        • 项目整合管理各过程的输入与输出之间的关系
      • 4.2.2 对输入与输出的解释
        • 略
        • 整合管理是从整个项目的全局视角开展的，项目管理计划的任何内容以及任何一种项目文件都可以成为其中的执行、监控和收尾过程的输入。
    • 4.3 制定项目章程
      • 制定项目章程，是项目启动阶段的一项重要工作，以便正式启动已经选定的某个项目，确立该项目在组织中的合法地位，授权项目经理动用组织资源开展项目工作。制定项目章程过程是要对已经被选定的项目办理正式的立项手续。
      • 4.3.1 项目的前期准备
        • 在制定项目章程过程之前须完成的准备工作，包括：
          • 项目发起人提出项目的初步设想
          • 聘请专家团队对项目开展商业论证（形成商业论证报告和效益管理计划）
          • 以及与相关机构签署关于发起项目的合作协议
        • 前期准备工作通常是在项目组合管理和项目集管理的层面上开展的。前期准备工作的主要目的是，落实项目的可行性，落实项目所需资金。
        • 严格地说，前期准备工作不包括在项目管理的五大过程组之中，也不包括在项目管理的十大知识领域之中，当然也就不在项目经理的工作范畴之内。
      • 4.3.2 项目启动
        • 发起人会亲自领导整个启动阶段，直至项目章程发布。项目章程发布之后，就由项目经理来领导项目。
        • 在项目启动阶段，发起人授权候任项目经理开展以下主要工作：
          • 开展项目评估
          • 识别高层级的可交付成果
          • 确定高层级的进度和成本要求
          • 确定整体项目风险的级别及其主要来源
          • 识别主要的假设条件和制约因素
          • 识别和分析项目的主要相关方
          • 编制项目章程，获得发起人对项目章程的批准，并分发项目章程
        • 开展商业论证是为了筛选项目，而开展项目评估是为了确认可行的项目仍然可行。进入制定项目章程过程的项目一般不会被砍掉。
      • 4.3.3 项目章程
        • 项目章程是一份非常重要的、对主要项目相关方有约束力的文件，相当于项目的“宪法”。
        • 项目发起人或高级管理层可以亲自编制项目章程，也可以授权项目经理代为编制。
        • 编制项目章程，不是要无中生有，而是要收集、分析、汇编和提炼已有的各种资料，如商业论证报告、效益管理计划、合作协议和项目评估报告。
        • 项目章程必须由项目发起人或高级管理层签署，并发布给主要的项目相关方，以便各相关方都知道项目已经正式启动，都了解项目的主要目标，都了解各自在项目上的角色和职责。
        • 通常不会因项目变更而导致对项目章程的修改。万一要对项目章程进行修改（如项目目标的修改），只有发起人或高级管理层才有权修改。谁签发项目章程，谁才有权修改项目章程。
        • 项目章程应该包括以下主要内容：
          • 项目概述和产品概述
          • 项目目的或批准项目的理由
          • 可测量的项目成功标准
          • 高层级需求和相应的项目总体要求
          • 总体里程碑进度计划
          • 预先批准的财务资源
          • 整体项目风险的程度
          • 主要相关方
          • 项目审批权限
          • 项目退出标准
          • 项目经理及其权责
          • 项目章程签发者的姓名和职权
    • 4.4 制订项目管理计划
      • 把全部的分项管理计划和分项基准汇编成综合的项目管理计划。分项管理计划是后面九大知识领域中各规划××管理过程和规划相关方参与过程的输出，分项基准则是创建WBS、制订进度计划和制定预算过程的输出。
      • 4.4.1 项目管理计划的主要内容
        • 根据《PMBOK®指南》，项目管理计划由三大部分组成：分项管理计划、三大基准、项目生命周期。
          • 主要的分项管理计划包括：
            • 范围管理计划、需求管理计划
            • 进度管理计划
            • 成本管理计划
            • 质量管理计划
            • 资源管理计划
            • 沟通管理计划
            • 风险管理计划
            • 采购管理计划
            • 相关方参与计划
            • 变更管理计划、配置管理计划
          • 三大基准是范围基准、进度基准和成本基准。在制订项目管理计划过程中，要把这三大基准整合成“绩效测量基准”。基准是一种特殊版本的项目计划。其特殊性表现在以下几个方面：
            • 是项目经理据以考核项目执行情况的依据。
            • 一定是经过高级管理层和主要项目相关方批准的，而不是项目团队自编自用、无须特定批准的细节性计划。
            • 除非另行说明，都是指最新版本的项目计划，即当前基准，而不是过去曾经作为基准使用过的项目计划。
            • 如果要对基准进行变更，只有变更控制委员会才有权力批准。项目经理无权批准。
          • 项目生命周期的类型和阶段划分、计划采用的产品开发方法，以及管理层对项目进行审查的时点和内容安排。
          • 项目管理计划是综合性计划，任何单项计划都不等同于项目管理计划（除非上下文另有要求）。
      • 4.4.2 项目管理计划的作用
        • 项目管理计划是关于将如何开展项目规划、执行、监控和收尾，经过正式批准的综合性计划。一旦有了项目管理计划，后续的一切规划、执行、监控和收尾工作都必须按该计划开展。
        • 除制定项目章程和制订项目管理计划过程以外，全部47个项目管理过程都要用项目管理计划作为输入。
      • 4.4.3 项目管理计划和项目文件的区别
        • 项目管理计划是一份综合性计划，而项目文件是各种单个文件的统称，包括未经汇编的各种各样的文件。
        • 项目管理计划一定是经过高级管理层审批的，而项目文件一般无须高级管理层审批，通常是项目团队自编自用的。某些文件在经高级管理层审批之前，属于项目文件；经高级管理层审批之后，就成了项目管理计划的组成部分，如项目范围说明书、概括性进度计划。
        • 项目管理计划中的分项管理计划是程序性计划，相当于法律中的程序法（如刑事诉讼法）；而产生于规划过程组的各种项目文件都是实体性计划，相当于法律中的实体法（如刑法）。
        • 对项目管理计划的更新（修改）必须走变更流程，经高级管理层审批；而对项目文件的更新则不一定需要走变更流程；即便需要走变更流程的项目文件更新，也无须高级管理层审批。
        • 考试时，看到“项目管理计划”和“项目文件”这两个词时，要根据题意小心判断它们的覆盖范围。
      • 4.4.4 项目计划的编制者
        • 项目团队成员编制项目计划，项目经理起总负责和整合的作用。其他重要相关方也要参与项目计划的编制工作。
      • 4.4.5 项目计划的编制时间
        • 在项目执行开始之前，要编制出尽可能完整的项目计划（包括项目管理计划和项目文件）。
        • 项目计划编制无法一蹴而就、一劳永逸，而是需要在相当长的时间内不断对计划进行审查、细化、完善和更新。
        • 把后续的计划更新也考虑在内，项目计划的编制要经历以下步骤：
          • 各具体知识领域编制各自的分项计划，包括分项管理计划、分项基准和其他文件。
          • 整合管理知识领域收集各分项管理计划和分项基准，整合成项目管理计划。
          • 用项目管理计划和各种分项计划去指导项目的执行和监控工作，并在执行和监控过程中提出必要的变更请求，报实施整体变更控制过程审批。
          • 根据经批准的变更请求，更新项目管理计划和各种分项计划。
        • 通常采用滚动式规划方法编制项目计划，即对近期就要开展的工作，编制详细计划；而对远期的工作，只做粗略计划，以后再随时间推移而细化。
      • 4.4.6 项目计划的整合
        • 第一，要确定编制和整合各分项计划所需要的关键信息；
        • 第二，要收集和分析这些信息，并编制出各分项计划；
        • 第三，分析各分项计划之间的衔接关系，防止衔接不良；
        • 第四，汇编各分项计划，形成完整的项目计划；第五，确认完整的项目计划能够持续实现商业价值。
    • 4.5 指导与管理项目工作
      • 本过程是开展项目管理计划中的各种活动，来实现计划的要求，完成可交付成果，并识别必要的项目变更，提出变更请求。项目执行阶段的开始通常以“开工会议”为标志。
        • 召开开工会议通常是规划阶段的最后一项工作。如果计划编制者和执行者是不同的两批人，而执行者的就位又需要一段时间，则召开开工会议是执行阶段的第一项工作。例如，大型施工项目必须等施工队伍进点后才能召开开工会议。
      • 在项目执行中，需要使用工作授权系统。工作授权系统是整个项目管理信息系统的一个子系统。它是一系列正式书面程序的集合，用来授权项目工作的开始，以保证该工作由正确的组织在正确的时间以正确的顺序执行。
      • 除了按原定计划执行项目工作，本过程也要执行那些经批准的变更请求，包括经批准的预防措施、纠正措施与缺陷补救措施。
    • 4.6 管理项目知识
      • 本过程是知识管理学科在项目管理中的应用。
      • 知识管理的重点是把现有的知识条理化和系统化，以便更好地加以利用；同时，还要基于这些条理化和系统化的知识，以及对这些知识的实践来生成新的知识
      • 《PMBOK®指南》中特别提及了两个重要的知识管理活动：知识分享和知识集成。项目经理要创造一个很好的氛围，激励大家分享知识。
      • 在《PMP®考试大纲》中，要求为确保“项目连续性（Project Continuity）”而进行知识分享。项目连续性是指项目工作不因严重风险或问题的发生而中断。
    • 4.7 监控项目工作
      • 本过程是对项目工作进行监控，以保证实现项目管理计划所定义的项目目标。在《PMBOK®指南》中：
        • 一方面，提到了监控是贯穿项目始终的，即对启动、规划、执行和收尾工作都要进行监控；
        • 另一方面，重点讨论了针对执行工作的监控。本书下文仅讨论针对执行工作的监控。
      • 监控过程组中的“监控”，就是“监督”加“控制”。
        • 监督是指把实际执行情况与计划要求相比较，发现偏差。
        • 控制是指分析偏差，并提出和审批必要的变更请求，以便解决不可接受的大偏差。
      • 在《PMBOK®指南》中，共有12个监控过程。除了专用于审批变更请求的“实施整体变更控制过程”，其他监控过程都要把执行情况与计划要求相比较，发现并分析偏差，并为解决不可接受的大偏差提出变更请求。
      • 《PMBOK®指南》中的“变更请求”是广义的，不仅包括对正式受控的项目计划（如项目管理计划）的修改建议，而且包括纠正措施建议、预防措施建议和缺陷补救建议。
    • 4.8 实施整体变更控制
      • 本过程是对项目启动、规划、执行和监控过程中提出的变更请求进行综合评审，以便批准或否决变更请求，控制对项目的变更，维护项目基准的严肃性和完整性。
      • 本过程专用于审批各种变更请求。无论哪个过程提出的哪种变更请求，都必须提交给实施整体变更控制过程审批。本过程的主要任务是接收变更请求，评审变更请求，批准或否决变更请求。
        • 需要特别强调，本过程对变更请求的评审必须是全面、系统和综合的，必须考察一个变更可能给项目各方面带来的影响，而不能局限于考察对一两个方面的影响。
      • 对变更请求的评审必须是综合性的。只有从总体上有利于项目的变更，才能被批准。必须防止因局部利益而损害全局利益。
      • 对某个变更请求，可能既没有理由批准，也没有理由否决。在这种情况下，本过程就会做出一个临时的决定：暂时悬置变更请求。悬置的变更请求，往往要退回给变更请求的提出者，要求他们补充资料。
    • 4.9 结束项目或阶段
      • 本过程是按照正式的收尾程序，正式关闭采购合同、项目阶段或整个项目。
      • 项目无论何因何时终止，都必须用结束项目或阶段过程来正式关闭。
      • 为了关闭项目，必须开展以下行政收尾工作：
        • 完成剩余尾工，开展财务结算和决算，确保项目达到既定的完工（退出）标准。
        • 获得重要相关方对项目可交付成果的最终验收。注意：这里的验收，只是形式上的验收，而不是实质性的技术验收。
        • 项目可交付成果以及对其的照管责任移交给指定的相关方，如发起人或客户。这项工作往往与最终验收同时开展。
        • 编制和分发最终的项目绩效报告。
        • 收集各主要相关方对项目的反馈意见，了解他们的满意度。
        • 整理项目资料，开展项目后评价，总结经验教训，更新组织过程资产，为组织和以后项目提出改进建议。
        • 分享项目知识，如分发项目后评价报告，召开经验交流会。
        • 释放资源（如退还剩余的资金和材料），解散团队，宣布项目正式关闭。
    • 4.10 各过程的工具与技术
      • 4.10.1 专家判断
        • 专家判断[插图]是项目整合管理7个过程共同使用的工具与技术。
        • 专家判断是有关专家根据自己的知识与经验对问题做出判断。因为项目管理既有科学的成分，也有艺术的成分。
        • 专家判断可以来自项目执行组织内部或外部、项目团队内部或外部。
      • 4.10.2 会议
        • 在项目整合管理的7个过程中，只有管理项目知识过程没有会议这个工具：
          • 在制定项目章程过程中，需要召集主要相关方开会，讨论项目章程的主要内容并达成一致意见；还需要召开由主要相关方参加的项目启动会（InitiatingMeeting），来分发项目章程，宣布项目经理上任，宣布项目正式立项。启动会由项目发起人主持。
          • 在制订项目管理计划过程中，需要召开计划编制会议；还需要在计划编制完成时，召开项目开工会（Kick-off Meeting），来介绍项目目标和项目计划，获取主要相关方的支持，宣布项目正式进入执行阶段。
            • 开工会是很可能要考的，且往往与启动会一起考。考试中，可能把Kick-offMeeting也翻译成“启动会”。在看到“启动会”时，一定要看一下它的英文究竟是什么。
          • 在指导与管理项目工作过程中，需要召开项目状态评审会，来交流项目进展情况。
          • 在监控项目工作过程中，需要召开项目状态评审会，来评审项目进展情况，做出相关决定。因为监控和执行实际上无法截然分开，所以项目状态评审会，既是执行过程组的会，也是监控过程组的会。
          • 在实施整体变更控制过程中，需要召开变更控制会，来评审变更请求，做出批准、否决或悬置变更请求的决定。
          • 在结束项目或阶段过程中，需要召开收尾报告会、客户总结会、经验教训总结会、完工庆祝会。
        • 从会议目的来讲，可以分成：
          • 信息交流会
          • 方案产生与评审会
          • 决策制定会
        • 对于会议，项目经理应该：
          • 事先明确会议目的。
          • 事先制定会议规则，准备会议议程，并分发给相关人员。
          • 只邀请相关人员参加会议，并要求每个参会者明白自己的责任。
          • 按时开始、按时结束会议。
          • 在会议上要坚持事先制定的议程，避免跑题。
          • 除了解决特定问题，还应该使会议起到团队建设的作用。
          • 做好会议记录，并在会后及时整理和分发会议纪要。
      • 4.10.3 人际关系与团队技能
        • 制定项目章程和制订项目管理计划过程使用人际关系与团队技能，是为了解决对项目目标和计划的意见不一致，而管理项目知识过程则是为了促进知识分享和知识创造。
      • 4.10.4 数据收集
        • 数据收集是制定项目章程和制订项目管理计划过程的工具，是各种各样的数据收集技术的统称。
        • 《PMBOK®指南》为这两个过程列出了都需要使用的头脑风暴、焦点小组和访谈。
        • 对制订项目管理计划过程，《PMBOK®指南》还列出了核对单这个数据收集技术。可以用自己编制或其他标准化的核对单来检查项目管理计划是否包含了全部内容。
      • 4.10.5 数据分析
        • 数据分析是监控项目工作、实施整体变更控制和结束项目或阶段过程的工具，是用来探究变量之间的复杂关系的各种技术的统称。
        • 在监控项目工作过程中
          • 需要计算已发生的绩效偏差（挣值分析）并分析其程度（偏差分析）和原因（根本原因分析）；
          • 需要预测未来绩效（趋势分析）；
          • 还需要为纠正偏差制定和选择备选方案（备选方案分析、成本效益分析）。
        • 在实施整体变更控制过程中
          • 需要分析变更的备选方案（备选方案分析），分析变更的成本和效益（成本效益分析），以便做出批准或否决变更请求的决定。
        • 在结束项目或阶段过程中
          • 需要分析最终项目偏差的严重程度，以及究竟是哪些因素导致了项目偏差，并对项目产品未来的效益做出预测。
      • 4.10.6 决策
        • 决策是监控项目工作和实施整体变更控制过程的工具，是用于做决策的各种具体技术的统称。
        • 在监控项目工作过程中
          • 可能需要通过投票决定是否需要提出变更请求，以及需要提出怎样的变更请求。
        • 在实施整体变更控制过程中
          • 通常需要采用多标准决策分析技术，从多个方面（用多个标准）去评价某个或某几个变更方案的优劣，以便做出决定；
          • 也可以由一些专家通过投票来决定是否批准某个变更请求；
          • 特殊情况下，可以由一个人进行独裁型决策制定。
      • 4.10.7 项目管理信息系统
        • 指导与管理项目工作过程，需要使用项目管理信息系统。整个组织层面的项目信息系统，是项目的事业环境因素。
        • 这个过程要使用的项目管理信息系统，则是为某个具体项目专设的信息系统，其中包括自动化的工具，如信息收集与发布系统、项目关键绩效指标监控系统。
      • 4.10.8 知识管理
        • 知识管理是管理项目知识过程的工具，是用于促进员工分享隐性知识、集成各人的知识以及合作创造新知识的各种具体方法的统称，如人际交往、会议、研讨会、讲故事、工作跟随和跟随指导。
      • 4.10.9 信息管理
        • 信息管理是管理项目知识过程的工具，是用于促进显性知识分享的各种具体方法的统称，如图书馆服务、文献检索、经验教训登记册编制。
        • 知识管理用于在人与人之间建立联系，以便分享隐性知识（无法脱离人而存在）；信息管理用于在人和信息之间建立联系，以便分享显性知识（可以脱离人而存在）。
      • 4.10.10 变更控制工具
        • 变更控制工具是实施整体变更控制过程的工具。应该根据项目的具体情况、相关方对变更管理的要求和各种环境因素，选择合适的变更控制工具。
    • 4.11 项目变更管理（重点）
      • 4.11.1 基本概念
        • 项目变更管理是指基于拥抱变更的心态，采用合适的变更管理策略（不同的产品开发方法需要不同的变更管理策略），主动预测和开展变更，确保项目一直朝正确的方向前进。
        • 项目变更是指采取纠正措施、缺陷补救措施或预防措施，以及因计划本身的问题而修改已经批准的项目计划。
          • 如果项目执行有问题，出现了不可接受的较大偏差，就需要采取纠正措施。
          • 如果正在或已经形成的可交付成果存在范围或质量缺陷，就要采取缺陷补救措施。范围缺陷是指产品功能不全，质量缺陷是指已有的功能不符合技术要求。
          • 如果预计未来的项目绩效达不到要求，就要采取预防措施。
      • 4.11.2 变更产生的原因
        • 变更产生的基本原因包括项目计划中的缺陷，项目外界情况的变化，以及项目执行的低效。
        • 项目经理不仅应该为确保项目目标的实现而开展变更管理，而且应该协助项目集经理或其他高管人员为确保项目继续符合组织的商业需求而开展变更管理。前者属于项目内部的变更管理，后者则属于为适应外界新情况而开展变更管理。
        • 对项目变更必须进行有效的控制，防止无序、过多、过大的变更。
        • 如果变更太多、太大，就可能需要修改项目章程，甚至必须终止现行项目，而另外启动一个新项目。
      • 4.11.3 变更管理的程序
        • 变更管理的程序包括五大步骤：
          • 从源头上管理变更
            • 项目经理应该积极主动而非消极被动地工作。他要主动地对引发变更的各种因素施加影响，以避免不必要的变更。
            • 项目经理还要主动地对导致人们规避整体控制的因素施加影响，防止人们有意无意地规避对变更的综合评审。
            • 虽然《PMBOK®指南》中没有专用于从源头上管理变更的过程，但是大多数过程中都隐含着这项工作。
          • 提出变更请求
            • 任何人都可以提出变更请求。
            • 无论是书面还是口头的变更请求，都必须是正式提出的。非正式提出的变更请求，不能进入后续的变更管理程序。
            • 提出变更请求者，必须清楚地说明变更是什么、为什么要进行变更，必须初步说明变更可能产生的后果，变更可用什么方案实现。
            • 在项目计划被批准之后重复开展启动和规划过程，可能提出变更请求。
          • 评审变更请求
            • 任何变更请求，都必须提交给项目经理。项目经理收到变更请求后，立即进行形式审查，并把看似有效的变更请求写入变更日志。一旦变更请求被写入变更日志，它就进入了评审阶段。
            • PMP®考试中的“记录变更”，一般都是指把变更请求写入变更日志。
            • 先基于变更请求中的变更方案，评审变更对所在领域的影响。
            • 再基于变更请求中的变更方案，全面评审变更对项目各方面的综合影响。
            • 如果必要，再设计其他备选方案并进行评审。某个变更，也许用多个不同的方案都能够实现。
            • 变更无论大小，都必须经过综合评审，确认从总体上有利于项目，才能加以批准。
            • 在设计变更方案、进行变更评审的过程中，必须与主要相关方密切沟通，征求他们对变更的意见。
            • 应该根据变更的审批权限，由项目经理、变更控制委员会、高级管理层或项目发起人来审批变更请求，做出批准、否决或悬置变更请求的书面决定。悬置的变更请求，通常要返回给提出者补充资料。
          • 实施和跟踪批准的变更
            • 只有经过批准的变更，才能被实施、跟踪、考核和报告。如果某个变更已经发生但未经审批，必须先补办审批手续，然后才能去跟踪、考核和报告。
            • 在《PMBOK®指南》中，对变更的实施，是通过指导与管理项目工作过程来开展的；对变更实施情况的追踪，是通过控制质量过程来开展的。
          • 总结经验教训
            • 考试中可能问你，在某一个情景下，项目经理紧接着该做什么。这就需要你按照本节提示的变更管理程序来判断项目经理已做过什么、接下去该做什么。
      • 4.11.4 变更的审批权限
        • 任何人都可以提出变更请求，但不是任何人都有权批准变更的。谁有权批准什么变更，这是与变更管理程序同样重要的问题。
        • 不影响基准的变更，由项目经理审批。会影响基准的变更，项目经理无权审批，除非是紧急情况。
        • 提前终止项目的变更，是项目上可能出现的最大变更，只能由项目发起人审批。
      • 4.11.5 变更控制委员会和变更控制系统
        • 变更控制委员会由项目主要相关方正式组建，并派代表参加。项目经理可以是其中的成员，但通常不是主任。该委员会负责审查某些变更请求，批准或否决这些变更请求。对于会影响项目目标（基准）的变更，必须经过变更控制委员会的批准才能付诸实施。
        • 项目需要有效的变更控制系统。变更控制系统是关于变更管理的一系列正式的书面程序的集合，包括所需文档、跟踪要求和审批层次等。该系统不仅要规定什么变更需要哪个层次的批准，而且可以规定在什么特殊情况下可以不经批准就实施变更。
      • 4.11.6 配置管理
        • 配置管理是项目整体变更管理的组成部分。配置是会直接决定项目产品的功能的重要技术参数。为了保证项目产品能够发挥既定的功能，对项目配置及其变更的管理必须十分严格。
        • 配置管理通过以下四个步骤来完成：
          • （1）识别和记录项目产品的重要功能以及为实现这些功能所需的技术参数。
          • （2）跟踪这些参数，控制对这些参数的变更，并记录参数变更情况。
          • （3）按既定的参数（包括变更后的参数）执行项目，并记录与报告参数实现情况。
          • （4）审计项目产品，以确保所有参数都已实现，项目产品能发挥既定功能。
        • 配置管理的重点是，确定哪些是核心技术参数，并以特别严格的程序来控制对这些技术参数的变更，确保配置变更可控、在控、可追踪。
  • 第5章 项目范围管理
    • 5.1 概述
      • 5.1.1 基本概念
        • 项目范围管理旨在保证做且只做为完成项目所需的全部工作。它关注的焦点是，什么是包括在项目之内的，什么是不包括在项目之内的，以便为项目工作明确划定边界。
        • 项目范围管理需要：
          • 明确项目边界，明确什么工作是项目范围内的。
          • 明确项目必须提交的全部可交付成果。
          • 动态对项目工作进行监控，确保所有该做的工作都做了。
          • 动态对项目工作进行监控，防止发生范围蔓延。
          • 对不包括在项目范围之内的额外工作说“不”，预防做额外工作（镀金）。
          • 及时对项目可交付成果进行实质性验收。
        • 范围蔓延（Scope Creep）是指未经控制的项目范围逐渐扩大。一方面，项目范围很容易以一种不易察觉的方式逐渐扩大，等到察觉后，项目范围已经发生实质性变化；这就导致项目范围重大偏离。另一方面，项目相关方可能误认为，让项目团队多做事情能增加项目价值，从而不经过既定的申请和审批程序，就随意增加工作内容。
        • 镀金的项目是失败的，因为用于镀金的资源本可用于更有价值的事情。
      • 5.1.2 范围管理的重要性
        • 项目范围管理是项目其他各方面管理的基础。如果范围都弄不清楚，进度、成本和质量等也就无法弄清楚。
        • PMI在1983年出版的《ESA研究报告》中首次把项目范围与项目进度、成本及质量一起列作用来定义项目目标的重要维度，而且是第一个维度。在该报告中，“项目范围管理”被正式列为项目管理的一个新功能。
      • 5.1.3 产品范围与项目范围
        • 产品范围与项目范围既有联系又有区别。产品范围是指项目将要形成的项目产品的特性和功能，而项目范围是指为了完成具有既定特性和功能的项目产品而必须开展的工作。
        • 广义的项目范围，由产品范围和狭义的项目范围构成。
        • PMP®考试中，考项目范围的可能性比较大。考生应该看清楚题目中说的是“产品范围”还是“项目范围”。也有可能考产品范围与项目范围之间的联系和差别。
    • 5.2 各过程的输入与输出
      • 5.2.1 输入与输出的关系总览
        • 项目范围管理的实现过程是规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围。
      • 5.2.2 规划范围管理
        • 在项目章程的指导之下，参考项目管理计划中已有的子计划（如质量管理计划）和其他内容（如项目生命周期、开发方法），编制范围管理计划和需求管理计划。这两个管理计划将作为项目管理计划的组成部分，用于指导收集需求、定义范围、创建WBS、确认范围和控制范围过程。
      • 5.2.3 收集需求
        • 在项目章程和项目管理计划（如需求管理计划、范围管理计划、相关方参与计划）的指导之下，根据项目文件（如相关方登记册、假设日志）去收集相关方的需求。在收集需求的过程中，需要用商业文件（如商业论证）去引导相关方表述合理的需求。对于为客户做项目的乙方，还需要使用协议（合同）。
        • 重复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训。
        • 收集来的需求，必须记录下来，形成需求文件，同时编制需求跟踪矩阵。需求文件是定义、管理和控制项目范围的基础，将作为一种项目文件用作定义范围、创建WBS、确认范围和控制范围过程的输入。需求跟踪矩阵是用来动态跟踪、监控需求的实现情况的，将作为一种项目文件用作确认范围和控制范围过程的输入。
      • 5.2.4 定义范围
        • 在项目章程和项目管理计划（如范围管理计划）的指导之下，基于前一个过程所得到的需求文件（一种项目文件），依据假设日志（一种项目文件），编制项目范围说明书。项目范围说明书在经高级管理层批准之前，将作为一种项目文件用作创建WBS过程的输入。经批准之后，成为范围基准和项目管理计划的组成部分。
        • 在风险管理知识领域分析风险之后，可能要根据风险登记册（一种项目文件）来缩减项目范围，以减轻作为威胁的整体项目风险；或者扩大项目范围，以提升作为机会的整体项目风险。
      • 5.2.5 创建WBS
        • 根据项目管理计划中的范围管理计划，以及项目文件中的需求文件和项目范围说明书，编制WBS和WBS词典，并进而形成项目的范围基准。范围基准是项目管理计划的组成部分。
      • 5.2.6 确认范围
        • 根据项目管理计划中的范围管理计划、需求管理计划和范围基准，项目文件中的需求文件（含验收标准）、需求跟踪矩阵（含验收方法）和质量报告，以及工作绩效数据，对核实的可交付成果进行实质性验收。验收工作中会形成相关资料，即工作绩效信息。如果符合验收标准，就得到验收的可交付成果。如果不符合验收标准，就提出变更请求。
      • 5.2.7 控制范围
        • 把体现在工作绩效数据中的项目范围实际绩效，与体现在项目管理计划（如范围管理计划、需求管理计划、范围基准、绩效测量基准）和项目文件（如需求文件、需求跟踪矩阵）中的计划要求做比较，得到工作绩效信息。如果绩效偏差太大，就应该根据变更管理计划和配置管理计划（项目管理计划的组成部分）中的规定，提出变更请求。
    • 5.3 各过程的主要工作和成果
      • 5.3.1 规划范围管理
        • 规划范围管理过程就是要编制范围管理计划和需求管理计划。范围管理计划是关于将如何定义、制定、监控和确认产品范围与项目范围的计划。
        • 需求管理计划规定收集需求过程将如何开展，范围管理计划规定定义范围、创建WBS、确认范围和控制范围过程将如何开展。
      • 5.3.2 收集需求
        • 收集需求过程是根据范围管理计划和需求管理计划，收集项目相关方对项目的具体需求。也就是说，把相关方对项目的需要（needs）、想要（wants）与期望（expectations），转变成具体的项目需求（requirements），并记录下来。
        • 收集需求旨在使需求明确化、具体化和书面化。需求必须是可测量的、文档化的。
        • 通过需求分析，得到需求文件和需求跟踪矩阵，为项目范围管理奠定坚实基础。
          • 需求文件记录项目相关方对项目的各种具体需求（要求）。
          • 需求跟踪矩阵则说明具体需求与高层目标之间的对应关系，以及具体需求与细节层次上的项目设计、项目工作和可交付成果之间的对应关系。
        • 为了更好地管理需求，可以把需求归为以下类别：
          • 商业需求（最高层次），它要回答的问题是：“为什么要做某个项目？”
          • 相关方需求（中间层次），它要回答的问题是：“相关方想要用项目产品做什么？”
          • 解决方案需求（最低层次），它要回答的问题是：“项目团队必须开发出什么样的项目产品？”
          • 过渡和就绪需求
          • 项目需求
          • 质量需求
        • 用一定的解决方案去满足相关方需求，并通过满足相关方需求来实现商业需求。
        • 《PMBOK®指南》中还提到了项目需求（Project Requirements）和质量需求（Quality Requirements）。
          • 项目需求是对项目过程的需求，如采用什么项目管理方法、在什么时间、用多大成本完成什么工作。
          • 质量需求是项目过程或可交付成果必须达到的质量要求。
          • 质量需求与功能需求、非功能需求、过渡和就绪需求，以及项目需求都是交叉的。
      • 5.3.3 定义范围
        • 在收集需求过程中收集到的需求，不一定都要在本项目上得到实现。定义范围过程就是确定哪些需求必须在本项目上实现，并基于这些需求编制项目范围说明书，明确项目范围边界。
        • 项目范围说明书的主要内容包括：
          • 产品范围描述。细化项目章程和需求文件中的产品范围。
          • 可交付成果。项目必须提交的中间及最终可交付成果。以后还要在创建WBS过程中进一步细分。
          • 验收标准。可交付成果必须满足的标准。
          • 项目除外责任。本项目必须不做什么事情，防止相关方对项目产生不合理的期望。
        • 在定义范围过程中，还要细化制定项目章程过程所列出的制约因素和假设条件，更新假设日志。
        • 项目经理应该把必须由高层管理人员或职能经理搞定的事情列为假设条件，以便保护自己。
      • 5.3.4 创建WBS
        • 创建WBS过程就是用工作分解结构（WBS），把项目范围说明书中的项目可交付成果细分为更小、更便于完成的可交付成果，并在此基础上形成范围基准。
        • （1）WBS、WBS词典和范围基准
          • 工作分解结构，顾名思义，是把整个项目逐层分解到较小的、便于管理的要素——可交付成果。
          • 工作分解结构一般应该由产品范围和项目范围构成。项目范围中又包括技术工作和管理工作。
          • 工作分解结构中，应专列一条“项目管理”分支，使“项目管理”成为必须完成的工作之一。
          • 可交付成果是指为完成项目而必须提交的、可核实的、可测量的项目中间或最终成果，可以是有形或无形的。
          • WBS中的任何工作都是必须做的。如果有多余的，必须经过变更控制程序把它去掉，才能不做。WBS之外的任何工作都是必须不做的。如果要做，必须先经过变更控制程序把它加进去。
          • 工作分解结构的编制需要全部主要项目相关方和项目团队成员参与。
          • 工作分解结构最高层的要素，是项目名称或最终项目成果。
          • 逐层向下分解是为了提高时间和成本估算的准确性，更有效地开展项目规划、执行与控制。
          • 工作分解结构中，同一层次的各要素应该相对独立，尽量不相互交叉。
          • 在编制WBS的同时，应该编制WBS词典，对每个WBS要素进行解释。
          • 编制出WBS和WBS词典后，把这两个文件连同项目范围说明书，报给高级管理层审批。经过高级管理层审批的项目范围说明书、WBS和WBS词典，就是项目的范围基准。
        • （2）控制账户、规划包和工作包
          • 控制账户是用来进行项目范围、进度、成本和质量控制的，工作分解结构某个层次上的要素，既可以是工作包，也可以是比工作包更高层次的要素。
          • 控制账户是一种管理控制点，项目经理针对控制账户考核项目执行情况，即在控制账户的相应要素上，把项目执行情况与计划要求进行比较，评价执行情况的好坏，发现并纠正偏差。
          • 通常在项目规划阶段，就要确定项目的控制账户。
          • PMP®试题中的“控制账户”，一般都是高于工作包的WBS要素。每个工作包只能属于一个控制账户。
          • 规划包是在控制账户之下、工作包之上的WBS要素。
          • 规划包不能直接付诸执行，必须先分解成工作包。
          • 工作包必须小到这样的程度，以至于能够比较准确地对该工作包安排进度、编制预算、识别风险、分配负责人。
          • 工作包只是在本WBS中不再细分，但还可以在其他下级WBS中细分（针对子项目），或者由具体负责该工作包的人把工作包再细分为各种进度活动。
        • （3）工作分解结构的作用
          • 工作分解结构在项目管理中有极其重要的作用。项目的所有规划、执行、监控和收尾工作都必须基于工作分解结构。
          • 编制工作分解结构不仅是一项技术和管理工作，而且是重要的项目团队建设工作。
          • 编制工作分解结构的过程，能促使项目相关方尽早提出自己对项目的要求，并有效协调不同的要求。
          • 工作分解结构在项目管理中的主要作用如下：
            • 促使人们在尽可能早的时间，就周全地考虑项目范围，防止遗漏或多列某些内容。
            • 作为基础性文件，促进项目相关方之间沟通，使他们对项目范围有一致认识
            • 是编制项目进度计划、成本计划、质量计划、风险计划等的基础。
            • 是进行项目组织设计的依据之一。
            • 是进行项目执行和监控的重要依据。
            • 是考核项目是否完工的依据。
      • 5.3.5 确认范围
        • 确认范围过程是由项目发起人、客户和其他主要相关方正式验收已经完成并被核实为质量合格的可交付成果。
        • 必须在监控阶段完成对各个可交付成果的实质性验收，以便在还有时间解决问题时发现并解决问题。整个项目完工时，再开展项目产品的整体验收（形式验收），办理移交手续。
        • 注意：确认范围与控制质量是不同的，前者注重的是可交付成果的可接受性，而后者注重的是可交付成果的正确性（符合质量要求）。通常控制质量在前，确认范围在后；有时，也可以同时开展。
      • 5.3.6 控制范围
        • 控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比较，发现偏差，分析偏差，提出解决偏差的建议。
        • 注意区分控制质量过程、控制范围过程和确认范围过程。
    • 5.4 各过程的工具与技术
      • 5.4.1 规划范围管理
        • 项目经理需要邀请相关项目团队成员和主要项目相关方召开会议，来讨论项目范围管理计划、需求管理计划的编制。编制计划，通常都需要召开规划会议。
        • 备选方案分析，作为一种数据分析技术，用于分析收集需求和开展范围管理的多种备选方案，并做出选择。
      • 5.4.2 收集需求
        • 《PMBOK®指南》中列出了如下工具：专家判断、数据收集、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法。除专家判断以外，其余这些工具之间存在如下的逻辑关系：
          • 首先，使用数据收集、数据分析、人际关系与团队技能、系统交互图和原型法，收集相关方的原始需求。
          • 其次，使用数据表现来分析各种原始需求之间的关系，如因果联系和同类关系。
          • 最后，使用决策来确定对需求的归类和排序。
        • （1）收集原始需求
          • 收集原始需求，可以采用两类方法：
            • 一类是分析现有的各种各样的文件。相关方的需求会体现在他们所编制的各种文件中。这就是使用数据分析中的文件分析工具。
            • 另一类是现场调查的方法。现场调查的方法又可以分成个人调查法、小组调查法和联系对比法。
              • 个人调查法是调查每个人的需求，可以采用数据收集中的访谈、问卷和调查，人际关系与团队技能中的观察。
              • 小组调查法是调查一群人的需求，可以采用数据收集中的头脑风暴和焦点小组，以及人际关系与团队技能中的名义小组和引导。
                • 这里的引导主要是指召开引导式研讨会，包括联合应用开发、质量功能展开和用户故事会。
                  • 引导式研讨会是由主持人引导，邀请不同背景、部门或领域的相关方派代表参加，共同讨论需求，以识别一些跨界需求，并协调需求矛盾。
                  • 联合应用开发是软件开发行业常用的引导式研讨会，强调由项目开发团队和用户一起共同定义需求。
                  • 质量功能展开在制造行业的新产品研发项目中很常用。它是一种把用户需求转化成产品功能的结构化方法（通常用矩阵表格的形式），以便开发出最能满足用户需求的那些功能。
                  • 用户故事会则是参会者一起创建关于相关方需求的故事。故事通常由三部分构成：相关方的角色，相关方想要什么（需求），相关方为什么想要它（想用它获得什么利益）。
              • 联系对比法包括系统交互图、原型法以及数据收集中的标杆对照。
                • 系统交互图是指把拟建的特定系统置于大背景中，用图形直观地展示该系统与其他系统之间的接口关系，从而确定该系统应该满足什么需求。
                • 原型法是指通过开发原型、由相关方试用原型并提出反馈意见，来逐渐明确相关方的需求。
                • 标杆对照是用可比项目的最佳实践作为标杆，来确定本项目的需求。
        • （2）分析和整理需求
          • 使用数据表现中的亲和图和思维导图来分析和整理原始需求。
            • 亲和图用于对原始需求进行归类，把具有亲近关系（相似性）的各种需求归为一个更大的需求。
            • 思维导图用来找出各种原始需求之间的先后顺序关系、因果关系或隶属关系。
        • （3）做出关于需求的决定
          • 使用决策中的投票和多标准决策分析，做出关于需求归类和需求排序的决定。
            • 投票是指由一群人基于所有人一致同意、超过50%的大多数人同意或不足50%的相对多数人同意的规则，进行投票表决。
            • 多标准决策分析是指用多种标准（如需求的紧急性、实现难易度、成本效益比）对所有需求进行列表分析，排出优先顺序。
      • 5.4.3 定义范围
        • 定义范围过程要使用专家判断、产品分析、数据分析中的备选方案分析、决策中的多标准决策分析和人际关系与团队技能中的引导。
          • 首先，通过产品分析，确定项目产品应该具备的功能，即明确产品范围；
          • 其次，通过备选方案分析，设计和分析可以用来实现既定产品功能的不同项目方案，即明确可供选择的项目范围；
          • 再次，用多标准决策分析，对备选方案进行评价和打分；
          • 最后，引导项目相关方就产品功能和项目方案达成一致意见。
      • 5.4.4 创建WBS
        • 利用分解技术，把项目分解成较小的可交付成果和相关工作。分解可按下面几个步骤进行：
          • （1）识别项目的全部可交付成果。应该用多种方法识别可交付成果，防止遗漏。
          • （2）分析可交付成果之间的从属关系，确定WBS的编排方式。
          • （3）把可交付成果从大到小按隶属关系排列。
          • （4）建立WBS编号系统，对每个WBS要素编号。
          • （5）自下而上检查工作分解是否符合100%规则，做必要修改。
      • 5.4.5 确认范围
        • 在对已完成的可交付成果进行实地检查的基础上，由验收小组用决策中的投票技术来决定可交付成果能否通过验收。
      • 5.4.6 控制范围
        • 使用数据分析中的偏差分析技术来确定项目范围绩效偏离范围基准的程度和原因。还要使用数据分析中的趋势分析来预测未来的项目范围绩效。
    • 5.5 描述项目范围的主要文件
      • 5.5.1 文件种类
        • 用于描述项目范围（广义）的主要文件包括（按编制的先后顺序排列）：
          • 项目章程。其中有初步的产品范围和初步的项目范围。
          • 需求文件。用作进一步明确产品范围和项目范围的基础。
          • 需求跟踪矩阵。用来追踪项目范围和产品范围的实现情况。
          • 项目范围说明书。其中包括产品范围和项目范围，用来确定范围边界。
          • 工作分解结构。用来明确必须完成的全部可交付成果。
          • 工作分解结构词典。对WBS中的要素进行解释。
          • 范围基准。经过批准的产品范围和项目范围。
          • 采购工作说明书。即将外包的工作的范围说明书，由买方在编制采购计划时编制。
          • 合同工作分解结构。外包工作的WBS，由卖方在签订合同后编制并报买方确认。
        • 合同工作分解结构是卖方用来与买方就合同工作范围统一认识的，与卖方内部用的工作分解结构不一定完全相同。
        • 其中，项目章程是在项目启动阶段编制的，合同工作分解结构是在项目执行阶段编制的，其他的都是在项目规划阶段编制的。
        • 另外，还有两个与范围管理直接相关的文件，即需求管理计划和范围管理计划。它们是项目管理计划的重要组成部分。
      • 5.5.2 几个文件的比较
        • 各种范围文件（工作分解结构除外）都在不同程度上包括一些非项目范围的信息。
  • 第6章 项目进度管理
    • 6.1 概述
      • 在工作分解结构的基础上，针对交付工作包的需要，列出为完成项目而必须进行的全部活动，然后分析这些活动之间的逻辑关系，估算各活动所需要的持续时间（工期），制订项目进度计划，并随同项目执行对进度绩效进行监控。在开展这些工作之前，须先行编制项目进度管理计划。
      • 项目进度管理通过下列六个过程来实现：
        • 规划进度管理。编制作为项目管理计划的组成部分的进度管理计划。进度管理计划是后续各种进度管理工作的依据。
        • 定义活动。弄清楚必须做哪些进度活动才能完成工作分解结构中的工作包以及更高层的可交付成果。
        • 排列活动顺序。弄清楚活动之间的逻辑关系，并用网络图表述由这些逻辑关系所构成的项目活动的工作流。
        • 估算活动持续时间。根据活动属性和可用资源，估算完成每项活动究竟需要多长时间（工期）。
        • 制订进度计划。分析并综合前述三个过程的成果，同时考虑对进度安排构成约束的各种制约因素，编制项目进度计划。
        • 控制进度。与项目进度计划对照，监督项目进度执行情况，发现进度偏差，预测未来进度绩效，提出必要的变更请求。
      • 估算活动持续时间过程与项目资源管理知识领域中的估算活动资源过程存在密切的互动关系，通常需要循环开展这两个过程多次。
      • 编制项目进度计划旨在：
        • 弄清楚项目要进行的全部进度活动。
        • 弄清楚各活动之间的逻辑（依赖）关系。
        • 弄清楚每个活动所需的持续时间。
        • 在资源许可的情况下，把可以同时进行的活动尽量同时进行，以缩短工期。
        • 找出关键路径上的活动，即那些不允许有任何延误的活动，以便重点管理。
        • 找出完成项目的可行的最短时间。
      • 考生必须掌握手工绘制网络图的方法，以及手工计算持续时间（工期）、活动开始与结束时间、浮动时间等的方法。
    • 6.2 各过程的输入与输出
      • 6.2.1 输入与输出的关系总览
        • 项目进度管理各过程的输入与输出关系可以概括为如图6-2所示（未考虑事业环境因素、组织过程资产和各种更新）。
      • 6.2.2 规划进度管理
        • 在项目章程的指导下，参考项目管理计划中已有的范围管理计划和开发方法，编制进度管理计划。进度管理计划将作为项目管理计划的组成部分，用于指导后续的五个进度管理过程。采用不同的产品开发方法，进度管理方法也会有所不同。
      • 6.2.3 定义活动
        • 根据项目管理计划中的进度管理计划，把项目管理计划中的范围基准中的工作包分解成进度活动，得到活动清单、活动属性和里程碑清单。它们将作为项目文件用作后续相关过程的输入。
        • 在项目基准被批准后，重复开展定义活动过程，可能提出变更请求，如要求修改工作分解结构。
      • 6.2.4 排列活动顺序
        • 根据项目管理计划中的进度管理计划和范围基准，对活动清单（一种项目文件）中的活动，依据活动属性（一种项目文件）进行排序，编制项目进度网络图。需要依据里程碑清单（一种项目文件）在进度网络图中标出里程碑。
        • 排列活动顺序时，需要考虑各种假设条件和制约因素，所以会用到假设日志。
      • 6.2.5 估算活动持续时间
        • 根据项目管理计划中的进度管理计划和范围基准，以及隶属于项目文件的活动清单、活动属性和里程碑清单，估算活动持续时间，得到持续时间估算和估算依据。
        • 需要用到来自项目资源管理知识领域中估算活动资源过程和获取资源过程的相关项目文件，包括资源需求、资源分解结构、资源日历和项目团队派工单。
        • 对得到的持续时间估算，需要在风险管理知识领域分析会有多大风险不能在该持续时间内完成活动，分析结果写入风险登记册（一种项目文件）。
        • 估算持续时间时，需要考虑各种假设条件和制约因素，所以会用到假设日志。
      • 6.2.6 制订进度计划
        • 根据项目管理计划中的进度管理计划和范围基准，把本知识领域定义活动、排列活动顺序和估算活动持续时间过程所得到的输出（隶属于项目文件）综合起来，编制出项目进度计划，同时形成配套的支持文件进度数据和项目日历。
        • 因为进度计划必须有资源保证，所以还需要用到来自项目资源管理知识领域估算活动资源过程和获取资源过程的相关项目文件，包括资源需求、资源日历和项目团队派工单。
        • 编制出进度计划初稿之后，需要通过风险管理知识领域来分析风险，并把分析结果写入风险登记册（一种项目文件）。
        • 编制进度计划时，需要考虑各种假设条件和制约因素，所以会用到假设日志。
        • 重复开展本过程时:
          • （1）需要参考经验教训登记册（作为一种项目文件）中的经验教训，并可能提出变更请求；
          • （2）可能要根据协议调整进度计划。
      • 6.2.7 控制进度
        • 把体现在工作绩效数据中的进度实际绩效与体现在项目管理计划（进度管理计划、范围基准、进度基准和绩效测量基准）和各种项目文件（项目进度计划、进度数据、项目日历和资源日历）中的计划要求进行比较，发现进度绩效偏差，并记录在工作绩效信息中，同时，对未来进度绩效做出预测，得到进度预测。如果偏差太大或预测结果不理想，就提出变更请求。
        • 重复开展本过程时，需要参考经验教训登记册（一种项目文件）中记录在案的经验教训。
    • 6.3 各过程的主要工作和成果
      • 6.3.1 规划进度管理
        • 概述：规划进度管理过程旨在编制进度管理计划，规定项目进度管理工作必须遵守的程序和方法。
        • 进度管理计划的主要内容包括：
          • 进度模型的制定方法。用什么方法和工具来制定项目进度模型。
          • 版本发布和迭代长度。敏捷型项目各版产品的发布时间，以及所需迭代期固定时长。
          • 准确程度。活动及项目的工期估算应该准确到什么程度，允许有多大的误差。
          • 计量单位。用什么单位来计算资源的数量、工作的数量及活动的工期，如10个工人、100立方米土石方开挖、30个日历月。
          • 组织程序链接。项目的进度管理应该如何与执行组织的管理系统衔接。
          • 进度模型（计划）维护。在项目执行过程中，如何把实际进度绩效代入进度模型来更新进度计划。
          • 控制临界值。在项目执行中，允许出现的最大进度偏差。
          • 绩效测量规则。测量、考核和预测项目进度绩效的规则。
          • 报告格式。各种进度绩效报告的格式、内容和报送时间。
        • 把有关数据输入进度模型，即可自动生成进度计划。这个道理与浇灌混凝土构件完全一致。有时，可把进度模型理解成进度计划。
      • 6.3.2 定义活动和排列活动顺序
        • 定义活动过程旨在把工作包分解成进度活动，列出进度活动的各种属性，确定将随同一系列进度活动的完成而实现的里程碑。
        • 《PMBOK®指南》提到的两种网络图是节点图和逻辑横道图。
          • 节点图用节点表示活动，用箭线连接活动并表示逻辑关系。
          • 逻辑横道图是在传统的横道图上添加用来表示逻辑关系的箭线。
          • 在这两种网络图中，可以使用下列四种活动之间的逻辑关系：
            • 完成到开始关系（Finish to Start，FS）。紧前活动完成后，紧后活动才能开始。
            • 完成到完成关系（Finish to Finish，FF）。紧前活动完成后，紧后活动才能完成。
            • 开始到开始关系（Start to Start，SS）。紧前活动开始后，紧后活动才能开始。
            • 开始到完成关系（Start to Finish，SF）。紧前活动开始后，紧后活动才能完成或必须完成。
          • 在这些逻辑关系中，可能还有一定的“提前量”或“滞后量”。
            • 提前量是指以紧前活动的完成或开始时间为基点，紧后活动的开始或完成可以提前的时间，用公式表示：FS−3天。
            • 滞后量是指以紧前活动的完成或开始时间为基点，紧后活动的开始或完成必须推迟的时间。用公式表示：FS+3天。
          • 活动之间的逻辑关系可能是强制性或选择性的：
            • 强制性关系，也叫硬逻辑关系，是由活动的内在性质决定的，如基础建好了才能砌墙壁；项目团队无法改变这种逻辑关系。
            • 选择性关系，也叫软逻辑关系，是由项目团队基于自己的经验、偏好、习惯等，自行选择的逻辑关系。软逻辑关系完全在项目团队掌控之中。
            • 进行活动排序，要重点针对相互之间具有软逻辑关系的各种活动，以便缩短项目工期。
        • 进度网络图中可能存在路径汇聚或路径分支。路径汇聚是指两条或更多路径汇聚到同一个紧后活动上。路径分支是指一个紧前活动分出两条或更多路径指向两个或更多紧后活动。
      • 6.3.3 估算活动持续时间
        • 一个活动究竟需要多长时间才能完成，既取决于活动的性质，也取决于活动的资源配置情况。因此，应该根据活动的性质和资源配置情况来估算活动持续时间。
        • 通常，应该先估算出完成某个活动所需的工时数（Amount ofEfforts），再根据资源的可用性，计算出该活动所需的持续时间（duration）。
          • 例如，某活动需要100个工时，有2个人可用，他们每周分别为项目工作10小时，那么，该活动的持续时间就是：100工时÷20小时/周=5周。
        • 考虑到活动面临的风险，估算的结果可以是一个区间，如10±2天。
          • 如果威胁发生，该活动需要12天；
          • 如果机会发生，该活动需要8天。
          • 估算结果也可以是用概率表示的某个时间段，如有80%的概率在10天内完成。
        • 在估算活动持续时间时，通常需要考虑：
          • 收益递减规律。在资源投入到达某个点后，每个单位的投入所带来的产出会逐渐下降。
          • 最佳资源数量。选择用于开展某个活动的最佳资源数量。资源数量并非越多越好，一是因为收益递减规律，二是因为相互干扰等其他原因。
          • 技术进步。往往可以采用先进技术来缩短活动工期。
          • 人员激励。防止人们犯学生综合征（拖延症），或受帕金森定律的影响。
      • 6.3.4 制订进度计划
        • 制订进度计划过程，是在进度管理计划的指导下，把定义活动、排列活动顺序和估算活动持续时间等过程的成果综合起来，编制出项目进度计划，并把其中高层次的进度计划报给高级管理层审批，成为进度基准。
        • 在编制项目进度计划的同时，需要确定哪些数据是进度数据（Schedule Data），以便将来通过控制这些数据来控制项目进度，或者通过修改这些数据来修改进度计划。在编制项目进度计划的同时，还要编制项目日历，确定项目的工作日和非工作日。
        • 项目进度计划通常包括详细进度计划、概括性进度计划和里程碑进度计划，构成从低级到高级、从详细到粗略的层级结构，满足不同层次人员了解项目进度的需要。经高级管理层批准的概括性进度计划和里程碑进度计划，就是进度基准。
          • 详细进度计划通常用网络图（常用节点图或逻辑横道图）来表示。进度活动是在详细进度计划中被列出来的最低层级的各项活动。
          • 概括性进度计划是针对概括性活动（汇总活动），用传统的横道图编制的。至少两个进度活动所组成的更大的活动。是比详细进度计划更高层次的进度计划。
          • 里程碑进度计划，又称主进度计划、控制性进度计划或一级进度计划。里程碑本身没有工期，是项目中的重要时点或事件。
        • 在PMP®考试中，应该按如下规则来选择使用网络图、横道图或里程碑图：
          • 如须显示活动之间的逻辑关系、项目从开始到结束的工作流，用网络图。
          • 如须了解项目内外部之间的关键接口，用里程碑图。
          • 如须向管理层或客户汇报项目进度计划或实际进展情况，用里程碑图或横道图。
          • 如须追踪活动进度，用横道图。
          • 网络图的优势是表示活动之间的逻辑关系，横道图的优势是追踪活动进度，里程碑图的优势是概述项目进展情况。
      • 6.3.5 控制进度
        • 控制进度过程旨在把实际进度绩效与进度计划中的要求做比较，发现、记录并分析偏差，预测未来的进度绩效，并提出必要的变更请求。
        • 控制进度过程与控制成本过程紧密相连，需要借助挣值管理方法来实现。
    • 6.4 各过程的工具与技术
      • 6.4.1 规划进度管理
        • 采用数据分析中的备选方案分析，来分析多种可用的进度管理方法、进度计划详细程度、滚动式规划的滚动期和进度计划更新频率，并做出选择。还需要召开会议，采用专家判断。
      • 6.4.2 定义活动
        • 采用分解技术，把工作包分解成活动。不是所有的工作包都要一次分解到位，可采用滚动式规划方法对近期要完成的工作包做详细分解，对远期才完成的工作包做粗略分解，以后再逐渐细化。究竟要怎么分解，需要专家判断，还需要召开会议。
      • 6.4.3 排列活动顺序
        • 使用紧前关系绘图法绘制进度网络图，通过确定和整合依赖关系来区分强制、选择、外部与内部依赖关系，在进度网络图中须考虑活动之间的提前量和滞后量。
        • 紧前关系绘图法（也可译成“前导图法”）用节点表示活动，把活动名称及相关信息表示在节点上，所以又叫节点法（Activity-On-Node，AON）。它用位于节点的一个代号表示一个活动，所以又叫单代号法。节点法用箭线表示活动之间的逻辑关系。
        • 还有两种《PMBOK®指南》中没有提及但PMP®考试有可能考到的网络图绘制方法：条件图法和箭线绘图法。
          • 条件图法以图形评审技术（Graphical Evaluation andReview Technique，GERT）为代表。它与其他三种方法的区别：其他三种方法都不允许在网络图中出现“回路”和“有条件的路径（如果什么则什么）”，而条件图法则允许。
          • 箭线绘图法（Activity-On-Arrow，AOA）用箭线表示活动，把活动名称及相关信息表示在箭线上。它用位于两个节点的两个代号表示一个活动，所以又叫双代号法。箭线法用节点表示连接活动的“事件”（event）。
          • “活动”有持续时间，而“事件”没有持续时间，只是一个时点，作为活动（或阶段）开始或结束的标志。
        • 节点法与箭线法的比较
        • “虚活动”是实际上并不存在的虚拟活动，不消耗任何时间或其他资源，只是为了在箭线法中表示逻辑关系。
        • 如果项目有不止一个起始工作或结束工作，画网络图时就需要在网络图的两端分别增加一个“起始”节点和“结束”节点，作为网络图的起点与终点。
      • 6.4.4 估算活动持续时间
        • 有四种常用的估算技术，即类比估算、自下而上估算、参数估算、三点估算，供项目团队根据具体情况选择使用。还要用专家判断、数据分析、决策和会议。
          • 1．类比估算和自下而上估算
            • 类比估算
              • 类比估算是一种专家判断的方法，也是一种自上而下估算方法。
              • 类比估算可以针对项目、阶段或活动，根据过去类似项目、阶段或活动的实际工期，来估算本项目、阶段或活动的工期。
              • 使用类比估算，要注意项目、阶段或活动的实质相似性，还需要估算者富有经验。
            • 自下而上估算
              • 自下而上估算是与类比估算相反的方法，既可以针对整个项目或阶段，也可以针对某个活动。
              • 前者是指先对工作分解结构底层的要素进行估算，再逐层向上汇总。后者是指把活动分解成更小的组成部分，先对这些组成部分进行估算，再汇总到整个活动。
              • 汇总持续时间时，必须注意各组成部分之间可能存在的时间提前量或滞后量。
              • 通常，自下而上估算会比类比估算更加准确。
          • 2．参数估算和三点估算
            • 参数估算是一种数学模型法。基于大量的历史数据，把决定项目、阶段或活动工期的各种参数列出来，找出相互之间的数学关系，建立数学公式（模型）来计算工期。常见的两种参数估算方法是回归分析和学习曲线。
              • 回归分析
                • 是根据一个或多个自变量的数值（参数）来预测一个因变量的数值（工期）。
              • 学习曲线
                • 是指随着产品生产数量的增加，工人能不断学习、积累经验，生产每个单位产品所需要的时间会有规律地逐渐减少。
              • 考试中，如果着眼于项目、阶段或活动整体的相似性来主观估算工期，就是类比估算；如果着眼于各具体参数（如房屋建设的总面积，以及单位面积所需的建设时间）来估算工期，就是参数估算。
            • 三点估算法，也叫PERT估算法（Program Evaluation andReview Technique）
              • 在估算活动工期时考虑三种可能的情况（最坏、一般和最好），得出最悲观工期、最可能工期和最乐观工期，再据此计算出期望工期（平均工期）。
              • 用PERT法计算工期（T），必须记住下面四个公式（其中P代表最悲观工期，M代表最可能工期，O代表最乐观工期）：
              • 在PMP®考试中，只要题目中没有指明活动工期是呈三角分布的，就要假设呈贝塔分布，采用“PERT公式1”。
              • 用PERT公式计算出来的是完成某活动的平均工期，即有50%的可能性在该工期内完成。用正态统计分布图，
          • 3．数据分析
            • 数据分析中的备选方案分析，用于分析开展活动的各种备选方案，如自己做或外包，采用不同的资源配置、技术或进度压缩方法。
            • 数据分析中的储备分析，用于分析活动、阶段或项目面临的已知和未知风险，以便在持续时间中预留合理的应急储备（应急时间）。
            • 预留进度“管理储备”只能针对整个项目，而不能针对活动或阶段。
          • 4．决策
            • 为了提高估算的准确性，可以组织一群人（如团队成员或主题专家），使用决策技术来估算活动工期。对工期估算，必须取得全部人员的一致同意。为了取得一致同意，可能需要经过多轮投票。
            • 德尔菲技术也是一种常用的一致同意投票技术。
              • 德尔菲技术是用来引导众多专家就某事项达成一致意见的常用方法。德尔菲技术的使用范围很广，可以用于估算工期、估算成本、识别风险和评价风险等。
              • 使用德尔菲技术，必须遵守以下几个规则：
                • 每个专家只与主持人单线联系。
                • 专家之间完全背靠背，更不能进行讨论。为保证专家提出独立见解，甚至需要把专家分散在不同的物理地点。
                • 专家以匿名的书面形式提出意见。
                • 绝对的一人一票制，且不允许弃权。
                • 必须经过“投票—汇总—反馈”多轮循环。专家匿名投票，主持人收集和汇总意见，向专家反馈汇总情况，专家再次投票……一直到达成一致意见。
                • 在多轮投票中，专家不断修正自己的意见，以使意见逐渐趋于一致。如果后一轮的意见更分散，那就必须立即停止，宣布本次德尔菲技术应用无效。
                • 德尔菲技术有助于人们减少偏见和克服个人对结果的不合理影响
            • 应由直接负责或最熟悉某活动的团队成员来估算活动持续时间，项目经理提供支持和协调。
      • 6.4.5 制订进度计划
        • 制订进度计划过程要使用的8种工具
          • 其中6种属于进度网络分析技术，即进度网络分析、关键路径法、资源优化、数据分析、提前量与滞后量、进度压缩。其实，进度网络分析是一个更高层次的术语，包含了后面5种技术。
          • 还有2种工具则是项目管理信息系统和敏捷发布规划。项目管理信息系统中主要是用于编制进度计划的软件。
          • 各种进度网络分析技术之间的关系
            • 先用关键路径法编制出理论上可行的进度计划。
            • 再用资源优化技术把上述计划调整成实际上也可行的。
            • 再使用提前量与滞后量和进度压缩来优化进度计划（缩短工期）。
            • 对于复杂项目，还需要用数据分析（包括假设情景分析和模拟）来进一步考察进度计划的可行性，进一步优化进度计划。
          • 1．关键路径法
            • 关键路径法是指在不考虑资源限制和完工时间强制的情况下，计算各活动及整个项目理论上的开始时间和结束时间。
              • 顺推法，从项目的开始时间出发，顺时针推算，计算出各活动的最早开始时间和最早结束时间以及整个项目的完工时间。最早开始或结束时间则是指一项活动可以开始或完成的最早时间。再从完工时间出发，用逆推法逆时针推算，计算出各活动的最晚结束时间和最晚开始时间。最晚结束或开始时间是指一项活动必须开始或完成的最晚时间。
              • 通常，顺推法的终点就是逆推法的起点，除非发起人已为项目指定完工日期。在后一种情况中，就无须顺推，直接逆推计算即可。
              • 关键路径是项目进度计划中总工期最长的路径，决定着项目的最短工期。需要注意的是：
                • 项目的关键路径至少有一条，可能不止一条。
                • 项目的关键路径可能发生变化，即原来的非关键路径可能变成关键路径，原来的关键路径也可能变成非关键路径。
              • 浮动时间是指在不延误整个项目的情况下一项活动允许延误的时间。
                • 正常情况下，关键路径上的活动，其浮动时间为零。
                • 浮动时间意味着分配资源和安排项目计划的灵活性。
                • 浮动时间等于最晚开始时间减去最早开始时间，或者最晚结束时间减去最早结束时间。
                • 浮动时间的概念：
                  • 自由浮动时间。一项活动可以延误的时间，而不会导致任一紧后活动不能在最早开始时间开始。
                  • 总浮动时间。一项活动可以延误的时间，而不会导致项目不能按期完工。总浮动时间可能等于或大于自由浮动时间。
                  • 项目浮动时间。一个项目可以延误的时间，而不会导致项目不能按外界（如客户）要求的日期完工。
            • 项目进度管理的两个难点：关键路径可能不止一条，关键路径可能发生变化。
            • PMP®考试中会有进度管理方面的计算题。考生需要掌握如下基本道理：
              • 活动的持续时间是开展该活动所需的工作时间数。
              • 活动的开始是指在开工日的上班时间开始。
              • 活动的结束是指在完工日的下班时间结束。
              • 计算工期，要“彻头彻尾（包头包尾）”。
              • 某项活动在紧前活动结束后立即开始，是指在紧前活动结束日的次日的上班时间开始，如果中间有滞后量或提前量，则相应加上或减去该时间。
              • 计算某个活动的工期时，不应该考虑提前量或滞后量。但是，计算某条路径或整个项目的工期时，则应该考虑提前量或滞后量。
          • 2．资源优化
            • 在用关键路径法编制出理论上可行的进度计划后，就需要考虑资源限制了。应该采用资源优化技术，根据资源限制来调整项目进度计划，或者为了提高资源使用效率而调整项目进度计划。
              • 没有足够的资源来实施原来计划的工作任务（出现资源短缺），就需要进行资源平衡（Resource Leveling）；
              • 如果在原计划中各个时段所需要的资源数量起伏太大，就需要进行资源平滑（Resource Smoothing），使各时段所需的资源数相对平稳。
              • 广义的资源平衡也包括资源平滑。也就是说，可以把资源平滑看成资源平衡的一种特殊形式。
              • 应该先做资源平滑，再做资源平衡。
          • 3．提前量与滞后量和进度压缩
            • 实际上可行的进度计划不一定就是最优的，发起人不一定愿意接受，可能还需要优化（缩短工期）。可以通过增加活动之间的时间提前量，或减少活动之间的时间滞后量，来缩短工期。无论是增加提前量还是减少滞后量，都可能导致风险增加。所以，必须同时考虑风险，把风险控制在可接受的程度内。
            • 还可以使用进度压缩技术，包括赶工和快速跟进。赶工是指在保持活动的工作范围不变的情况下，在单位时间内投入更多的资源，如安排加班或使用额外资源，以加快工作进度。赶工只能针对关键路径上的活动。
            • 快速跟进是指把关键路径上本应按先后顺序进行的工作调整为至少部分并行。快速跟进只能针对存在软逻辑关系的活动，可能导致返工风险。
            • 一般情况下，赶工的缺点是直接成本增加，快速跟进的缺点是导致返工风险。
            • 优化（压缩）进度计划后，必须重新检查项目的关键路径，因为它可能已经发生变化。
          • 4．数据分析
            • 有两种常用的数据分析技术：假设情景分析和蒙特卡洛模拟。
              • 假设情景分析是假设某种有利或不利情况发生，考察项目进度计划的可行性。
              • 蒙特卡洛模拟是在电脑上使用软件模拟实施项目很多次，甚至成千上万次，来计算项目的全部可能工期及其概率分布。
          • 5．敏捷发布规划
            • 这是适用于敏捷项目的进度计划编制方法：
              • 项目经理先与发起人商定各个产品版本的发布时间（相当于里程碑进度计划）。
              • 再与项目团队及发起人商定为实现每一次发布所需的迭代次数和时间（相当于概括性进度计划）
              • 然后，由项目团队编制每个迭代期的进度计划（相当于详细进度计划）。
        • 工期落在平均工期一个标准差（通常用σ表示标准差）之内的概率是68.26%，两个标准差之内的概率是95.46%，三个标准差之内的概率是99.73%。 这三个概率是考生必须记住的。如果用一个标准差来估算工期，那工期就是在平均工期加减一个标准差的区间内；如果用两个标准差，则是平均工期加减两个标准差的区间内；如果用三个标准差，则是平均工期加减三个标准差的区间内。
          • 计算项目的工期，可把同一条关键路径上的全部活动（假设都是不带提前量或滞后量的完成到开始关系）的平均工期加起来，得到项目的平均工期，然后再把这些活动的方差之和开平方得到项目工期的标准差，从而计算出在指定标准差区间内的相应项目工期区间。
          • 各项活动的标准差不能相加，只有方差才能相加。
          • 补充：单点估算是只考虑一种最可能的情况，用最可能的工期作为活动的工期估算。单点估算法就是CPM（关键路径）估算法。多点估算，当然要考虑很多种可能性。蒙特卡洛模拟法是一种常用的多点估算法，往往用于整个项目而不是某个活动层面。
      • 6.4.6 控制进度
        • 在控制进度过程中，首先要考察项目的进度绩效，其次要分析偏差并预测未来绩效，最后要解决不可接受的偏差或可能发生的不利绩效。
        • 控制进度过程的7个工具就是围绕这三项工作的。这些工具的使用又需要借助项目管理信息系统中的进度管理软件。
          • 用于考察进度绩效的工具包括关键路径法，以及数据分析中的绩效审查、挣值分析和迭代燃尽图。用关键路径法审查关键路径（最长的路径）和次关键路径（第二长的路径）的进度绩效。
          • 用绩效审查来考察项目的总体进度绩效。
          • 用挣值分析来计算进度偏差、进度绩效指数等指标。
          • 用迭代燃尽图来直观地显示已经完成和还剩余的工作量。
          • 用于分析偏差的工具包括数据分析中的绩效审查和偏差分析。
          • 用于预测未来绩效的工具包括数据分析中的挣值分析和趋势分析。在挣值分析中，可以计算各种预测指标。
          • 用于解决问题的工具包括资源优化、提前量与滞后量、进度压缩，以及数据分析中的假设情景分析。出现了进度落后，首先设法在项目内部调剂资源加以解决（资源优化），其次设法通过调整提前量与滞后量来解决，再次通过进度压缩（赶工或快速跟进）来解决，最后用假设情景分析来寻找其他解决方法。如果排序靠前的方法能够解决问题，那么就无须使用后面的方法了。
  • 第7章 项目成本管理
    • 7.1 相关基础知识
      • 7.1.1 概述
        • 项目成本管理旨在确保在批准的预算内完成项目。
        • 项目成本管理主要关心项目本身的成本，也需要考虑项目决策对今后项目产品使用与维护成本的影响，即需要考虑项目产品的生命周期成本。生命周期成本包括：
          • 项目建设期的建设成本；
          • 项目产品运行期的运营和维护成本；
          • 项目产品报废时的处置成本等全部成本。
      • 7.1.2 考察项目可行性的主要财务指标
        • 现值：是指某笔未来现金在今天的价值，是考虑货币时间价值的结果。
        • 未来值：与现值相反的是未来值，如银行存款在一定时期后的本利和。
        • 净现值：收入的现值减去支出的现值，就得到净现值。净现值是用来选择项目的一个重要财务指标。从理论上讲，净现值大于零的项目都可以做。
          • 在计算净现值时，已经考虑了时间，所以项目工期或投资回收期长短通常不再需要考虑。
        • 投资回收期：是指用多长时间能把项目投资收回来，通常是项目建设期加上项目投产后累计运营利润达到投资金额所需的时间。
        • 投资回报率：是指项目投产后的年均运营利润与项目投资额之比。
        • 内部报酬率：是一种特殊的贴现率，即项目净现值等于零时的贴现率。内部报酬率代表着项目产品的盈利能力大小以及抵抗风险能力大小。
      • 7.1.3 其他重要的财务概念
        • 固定成本。不随生产量或工作量的变动而变动的成本。
        • 可变成本。随生产量或工作量的变动而变动的成本。
        • 直接成本。可以直接计入某项目的成本，通常是某项目所专用的资源的成本。
        • 间接成本。不能直接计入某项目，而需要在几个项目或该项目与运营之间进行分摊的成本，如总部管理费。
          • 直接成本和间接成本的划分会受看问题的层次的影响。如果从整个项目的层次看，全职项目经理的工资是直接成本，但如果从项目内部各工作的层次看，该项目经理的工资又是间接成本（需要由项目内部各项工作分摊）。
          • 在PMP®考试中，如果题目中没有明确说“从项目内部的层次看”，就应该“从整个项目的层次看”。
        • 机会成本。因为选择一个项目而必须放弃另一个项目，另一个项目可以带来的利益就是这个被选择项目的机会成本。
        • 沉没成本。任何已经发生的成本，与是否合理无关。决策是针对未来的，做决策时，不能考虑沉没成本。
        • 收益递减规律。在累计投入到达某个点之后，随着投入的连续增加，单位投入的产出会呈现逐渐减少的趋势。
        • 边际分析。假设投入连续增加，分析单位投入所能带来的单位产出。
        • 折旧。固定资产随时间而产生的逐渐损耗。
        • 直线折旧法。每年提取等额的折旧数。
        • 加速折旧法。在固定资产使用寿命期内，越是早期，提取的折旧数越大。
        • 价值分析或价值工程。价值分析与价值工程经常替换使用，都是指对项目的范围（功能）和成本进行分析，追求功能与成本（价格）之间的更高的性价比。
          • 如果一定要区分价值分析与价值工程，为了达到比值更高，价值分析是分子不变（范围或功能）降分母，而价值工程则可以同时改变分子和分母。旨在改进工程设计的合理化建议，是价值工程的典型例子。
      • 7.1.4 成本管理的重要做法
        • 项目成本管理必须同时考虑两个方面：
          • 一是项目的每项工作需要多少成本；
          • 二是整个项目生命周期中的每个时段（周、月、季）需要多少成本。
        • 按工作内容进行的成本管理是依据工作分解结构进行的，而按时间段进行的成本管理是按项目进度计划以现金流量表的形式进行的。
        • 项目成本管理与项目进度管理密切相关，许多做法是相通的。
        • 编制项目预算，应该采用自下而上的方法，按如下主要步骤进行：
          • 第1步，计算出各活动所需要的成本，包括应急储备。
          • 第2步，汇总得出工作包的成本，包括应急储备。
          • 第3步，把各工作包的成本汇总，得到控制账户的成本，包括应急储备。
          • 第4步，把各控制账户的成本汇总，得到项目的成本，包括应急储备。
          • 第5步，对成本汇总的结果（包括应急储备）进行验证和调整，并报领导审批，得到项目成本基准。
          • 第6步，增加一定的管理储备，得出项目预算。
          • 在自下而上汇总出项目成本之后，需要对汇总的结果进行调整，特别是调整应急储备（第5步）。这种调整又可能导致返回第1步，重新估算活动的成本。
        • 还需要注意相关以下相关内容：
          • 工作分解结构和项目进度计划都是进行成本估算的重要基础，以便提高估算的准确性。
          • 估算应该由最熟悉相应活动的人来进行，而不是项目经理或管理层（项目早期的自上而下估算除外）。
          • 历史资料（组织过程资产）对做好估算工作非常重要。
          • 扣除管理储备之后的项目预算，是用于控制项目成本的基准线。除非经过既定的变更审批程序，成本基准不能改变（范围基准、进度基准也是如此）。
          • 如果在执行过程中出现了不可接受的成本偏差，必须采取纠正措施。
          • 项目经理不能简单、被动地接受管理层对项目的成本和进度要求，而要积极主动地分析项目的实际需要，向管理层提出合理建议。
          • 应该为应对风险增加一定的储备（应急资金），但不允许单纯为保护自己而增加“水分”。储备必须明示，不能隐藏着。
    • 7.2 各过程的输入与输出
      • 7.2.1 输入与输出的关系总览
        • 项目成本管理的实现过程包括规划成本管理、估算成本、制定预算和控制成本。项目成本管理各过程的输入与输出关系如图所示。
        • 7.2.2 规划成本管理
          • 在项目章程的指导下，编制成本管理计划。因为成本管理与进度管理密切相关，所以需要参考项目管理计划中的进度管理计划。项目管理计划中的风险管理计划，有利于确定该如何开展成本管理，以便达到所需的风险管控水平。
        • 7.2.3 估算成本
          • 在项目管理计划中的成本管理计划的指导下，估算完成项目工作所需的成本，得出成本估算和估算依据。
          • 项目管理计划中的质量管理计划，有利于估算该留出多少钱去管理项目质量。项目管理计划中的范围基准，有利于根据项目的范围大小来估算成本。
          • 项目进度计划（一种项目文件）中的活动名称以及活动开展时间，对估算成本有重要影响，因为：
            • ①活动在不同时间开展，成本可能不同；
            • ②有些成本（如利息）与活动工期长短有直接关系。
          • 资源需求（一种项目文件）有利于估算开展项目工作所需资源的成本。估算成本时，需要考虑风险，故需要风险登记册（一种项目文件）。
          • 复开展本过程时，需要参考已记录在经验教训登记册（一种项目文件）中的经验教训。
        • 7.2.4 制定预算
          • 根据成本管理计划（项目管理计划的组成部分）和商业文件（列有财务指标），把各活动或工作包的成本估算（一种项目文件）汇总成成本基准，并编制配套的项目资金需求文件。汇总时，须参考前个过程得到的估算依据（一种项目文件）。
          • 资源管理计划（项目管理计划的组成部分）中的资源性质、资源价格和资源日历，有利于在项目预算中留足用于买资源的钱。范围基准（项目管理计划的组成部分）有利于把预算分配到WBS的各个要素。
          • 项目进度计划（一种项目文件）有利于把预算分配到项目的各个时间段，确定每个时间段需要多少钱。
          • 对于已经外包出去的工作，需要把协议（合同）中的合同价纳入项目预算；对于打算外包出去的工作，需要考虑预留出多少钱，即预估未来协议中的价格。
          • 制定预算时，需要考虑风险，故需要风险登记册（一种项目文件）。
        • 7.2.5 控制成本
          • 把体现在工作绩效数据中的成本实际绩效与体现在项目管理计划（成本管理计划、成本基准和绩效测量基准）和项目资金需求中的计划要求进行比较，发现成本绩效偏差，并记录在工作绩效信息中，同时，对未来成本绩效做出预测，得到成本预测。如果偏差太大或预测结果不理想，就提出变更请求。
          • 重复开展本过程时，需要参考经验教训登记册（作为一种项目文件）中记录在案的经验教训。
    • 7.3 各过程的主要工作和成果
      • 7.3.1 规划成本管理
        • 规划成本管理过程旨在编制一份用来指导后续成本管理工作的成本管理计划。它是项目管理计划的组成部分。成本管理计划的主要内容如下：
          • 测量单位。用什么单位测量项目成本。通常都用货币单位，也可以用非货币单位，如人日数。
          • 精确程度。成本估算和项目预算应精确到什么程度，如元、十元、百元或千元。
          • 准确程度。成本估算和项目预算应准确到实际成本的正负百分之几，如±5%。项目早期（如启动阶段）的成本估算可以是粗略量级估算，准确性是−25%～+75%；在规划阶段后期的成本预算，应该是确定性估算，准确性是−5%～+10%。
          • 组织程序链接。项目成本账应如何与执行组织财务账相连，项目成本管理应如何符合组织财务会计制度的要求，如成本的记账时间和方法。
          • 控制临界值。允许出现的最大成本偏差。一旦突破控制临界值，就要采取纠正措施。控制临界值应该随项目进展越来越小。
          • 绩效测量规则。主要是挣值管理规则，包括针对哪些WBS要素（控制账户）计算挣值，间隔多长时间计算挣值，采用什么挣值计算方法，如何预测未来成本绩效。
          • 报告格式。将来要编制的各种成本管理报告的格式、内容、报送时间等。
          • 其他细节。如何处理汇率变动，如何记录成本开支等。
      • 7.3.2 估算成本
        • 估算成本过程旨在估算整个项目的成本，或估算各个活动或工作包的成本。
        • 在项目规划阶段的中期，工作分解结构和进度计划的初稿编制出来后，就需要用本过程估算活动或工作包的成本。
        • 应该由最熟悉相应活动或工作包的人来估算。应该计算所需的全部资源的成本。对于免费使用的资源，也要按合理的数字计算其成本。
          • 对于免费使用的资源，也要按合理的数字计算其成本。如果不计算免费资源的成本，就会使成本估算数字失真，无法供以后类似活动或工作包的成本估算工作参考（不会总有免费资源）。
          • 对免费资源，随后在计算项目资金需求时就无须考虑。也就是说，如果有免费资源，项目资金需求就会小于项目预算。如果没有，则两者相等。
          • 除非特别指明，均默认没有免费资源。
        • 在成本估算中，应该包括所有的成本种类，如固定成本和可变成本、直接成本和间接成本，以及应急储备。如果哪种成本没有包括在成本估算中，就必须在估算依据中特别加以说明。不过，管理储备肯定不包括在活动或工作包的成本估算中，这一点无须说明。管理储备只应包括在整个项目的成本估算中。
        • 本过程的名称之所以不是“估算活动成本”而是“估算成本”，是因为它可以在项目早期用于粗略地估算整个项目的成本。
      • 7.3.3 制定预算
        • 制定预算过程是把各活动或工作包的成本逐层向上汇总，并对汇总结果进行验证和调整，报领导审批，得到项目成本基准；再增加一定的管理储备，得到项目预算。汇总的结果，不一定十分合理，所以需要用其他方法进行交叉验证，并做必要调整。这种调整会导致制定预算过程与估算成本过程之间循环。项目成本基准的准确性必须达到确定性估算的水平。
        • 成本基准需要按工作内容分配到各控制账户，需要按时间分配到项目的不同阶段。按时间段分配的成本基准，通常可表现为S形状的一条曲线。
        • 非关键路径上的活动有一定的灵活性（浮动时间），是进行资源平衡时首先要利用的。从项目进度的安排来看，我们希望所有活动都在最早开始时间开始，但从现金流的安排来看，我们又希望在最晚开始时间开始这些活动。在最早开始时间或最晚开始时间开始这些活动，特定时点的项目累计成本支出可能有很大差别，形成“香蕉图”。管进度的人会追求最早开始曲线，而管成本的人却会追求最晚开始曲线。
        • 项目预算必须有资金的保证。所以，需要编制项目资金需求文件来配合项目预算。不仅项目整体要有资金保证，而且各WBS要素和各时间段都要有资金保证。
        • 项目的成本产生与资金支出不一定同步。如果有预付款，资金支出就早于成本产生；如果有债务（应付未付款），资金支出就晚于成本产生。如果没有免费的资源，在整个项目关闭时，项目总成本与总资金支出应该完全相等。
        • 如果没有管理储备，那么项目预算就正好等于成本基准。因为“项目预算”和“成本基准”这两个词经常替换使用，所以在看到“项目预算”时，必须合理判断它的真实意思。
      • 7.3.4 控制成本
        • 控制成本过程旨在把实际成本绩效与计划要求做比较，发现、记录和分析成本偏差，对未来的成本绩效做出预测，并提出必要的变更请求。因为成本与进度密不可分，所以控制成本过程与控制进度过程通常是整合在一起开展的，借助挣值管理方法来实现。
    • 7.4 各过程的工具与技术
      • 7.4.1 规划成本管理
        • 采用数据分析中的备选方案分析，来分析多种可用的成本管理方法、预算详细程度或资源获取方法（如购买或租赁），并做出选择。还需要召开会议，采用专家判断。
        • 备选方案分析也用于考察不同的项目融资方式，确定符合特定融资方式要求的成本管理方法。不同的融资方式，通常对成本管理有不尽相同的要求。
      • 7.4.2 估算成本
        • 估算成本过程所使用的工具大多与估算活动持续时间过程相同。道理是一样的，只是针对的对象不同。
        • 本过程比较特别的工具是数据分析中的质量成本。质量成本是用于质量管理的成本，是活动、工作包或项目成本的重要组成部分。在估算成本时，需要考虑打算花多少钱去做质量管理。
      • 7.4.3 制定预算
        • 首先，要运用成本汇总，把活动或工作包的成本逐层向上汇总到控制账户和整个项目。
        • 其次，要通过历史信息审核和专家判断来验证汇总结果的合理性，决定是否需要回头调整活动或工作包的成本估算。
          • 历史信息审核可以用类比估算或参数估算的方法进行，即用类比估算或参数估算计算整个项目的成本，以便与成本汇总的结果进行比较。
          • 如果用各种方法计算出的结果差别较大，就应该认真分析原因，并做必要调整。
        • 再次，用数据分析中的储备分析来估算整个项目需要多少管理储备。
        • 最后，要对初步确定的项目预算做资金限制平衡，即根据资金限制调整项目预算，确保项目预算有资金保证。
      • 7.4.4 控制成本
        • 在控制成本过程中，需要使用数据分析中的储备分析来判断为整个项目、控制账户、工作包或活动所预留的应急储备是否仍然合理。如果不合理，就需要提出调整建议。由于随项目进展，项目的不确定性逐渐降低，因此应急储备通常应该逐渐调减。只有在特殊情况下，才会调增，如项目情况发生了很大的变化，或者原先预留的储备太少。
        • 完工尚需绩效指数，以及数据分析中的挣值分析、偏差分析和趋势分析，都是挣值管理中的内容。挣值管理是项目管理的三大核心技术之一，也是PMP®考试的重点之一。
        • 项目管理的三大核心技术：工作分解结构、网络计划技术和挣值管理技术。
    • 7.5 挣值管理
      • 挣值管理是用来综合考察项目范围、进度和成本绩效的方法，是项目整合管理的要求。挣值管理是一种把范围、进度和成本绩效整合起来考察的方法，就是要在既定的范围之下追求进度和成本绩效的综合最优。
      • 挣值管理可以在整个项目、控制账户或工作包层面上进行。这三个层面的挣值管理，道理完全一样。
      • 7.5.1 基本概念
        • “挣值”是针对“计划价值”而言的。编制项目计划时，须按不同时点对项目应该完成的工作量及其相应价值制订计划；而后在执行过程中，随着项目的实施，逐渐把“纸面上”的计划价值一点一点地“挣”回来，形成“挣值”——实际上已经实现的价值。
        • 学习挣值管理，必须掌握以下基本概念：
          • 计划价值（Planned Value，PV）。截至某时点计划要完成的工作的价值，是计划完成工作的预算价值，可以表示为：计划价值=计划要完成的工作量×预算单价。
          • 挣值（Earned Value，EV）。截至某时点实际已经完成的工作的预算价值，是实际已完工作的预算价值，可以表示为：挣值=实际已完成的工作量×预算单价。
          • 实际成本（Actual Cost，AC）。截至某时点实际已经发生的成本，是实际已完成工作的实际成本，应该可以在项目的成本账上查到，可以表示为：实际成本=实际已完成的工作量×实际单价。
          • 完工预算（Budget At Completion，BAC）。整个项目的成本基准，除非已批准进行变更，完工预算不会变化。如果是针对工作分解结构中的某个要素来计算挣值，那么就是该要素的成本基准。
          • 计划价值、挣值、实际成本和完工预算是挣值管理中最基本的概念。
      • 7.5.2 计算公式
        • 考察成本绩效的主要指标
        • 考察进度绩效的主要指标
        • 预测未来情况的主要指标
          • 对表中的“完工尚需估算”计算方法，补充说明如下：
            • 如果项目已经发生的成本偏差（绩效指数）是典型的（具有代表性），这种偏差还会在以后继续同样规模地发生，则用“（BAC−EV）÷CPI”计算。
            • 如果截至目前的成本绩效和进度绩效都未达到计划要求，而又必须按期完工，则用“（BAC−EV）÷（CPI×SPI）”计算，其中的“CPI×SPI”的结果又称“关键比率”（Critical Ratio，CR），用来考核成本与进度的综合绩效。背后的道理是：以后将以成本增加为代价进行赶工，以便按期完工。
            • 如果项目已经发生的成本偏差（绩效指数）是非典型的，这种偏差以后不会发生，且以后的工作能够完全照预算进行，则用“BAC−EV”计算。
            • 如果不属于上述三种情况，则可以采用自下而上的方式全新地估算一个数字。全新估算的数字通常更加准确，但是进行估算需要花费额外的时间和成本。
            • 在预测未来绩效时，只要题目中没有明示项目过去已发生的偏差属于“非典型”，则一律按“典型”来考虑。
        • 还可以总结出以下几点：
          • 在计算偏差的公式中，EV总是出现在公式的第一位。
          • 在计算指数的公式中，EV总是作为分子出现。
          • 在计算偏差时，正的结果是有利的，负的结果是不利的，零是正好符合计划。
          • 在计算指数时（完工尚需绩效指数除外），大于1的结果是有利的，小于1的结果是不利的，1正好符合计划。
          • 除了BAC，其他计算都要考虑“截至或在某个时点”。
          • 除非成本基准线发生了变化，BAC在整个项目执行期间保持不变。
        • 在挣值管理中，既可以计算某个时段（报告期）的挣值指标，也可以计算从开工截至目前的累计挣值指标。
        • 只要题目中未指明要计算某个时间段的指标，就要计算自开工以来累计的指标。
        • 在挣值管理中，既可以针对整个项目计算各种挣值指标，也可以针对某些工作分解结构要素（如控制账户）计算各种挣值指标。应该事先规定将针对工作分解结构中的哪些要素计算各种挣值指标。至少要针对控制账户计算。
        • 为了连续动态地跟踪项目进展情况，应该规定计算各种挣值指标的时间间隔，如每个月计算一次。
      • 7.5.3 已完工作量的测算方法
        • 测算已完工作量，应该把活动分成下列三种类型：
          • 独立型活动（Discrete Effort）。可独立开展的、直接导致项目产品形成的活动，其已完工作量可以准确地测量并计算出来。例如，在砌墙项目中，建筑工人的砌墙活动。
            • 对于独立型活动，可以用下列方法测量已完工作量：
              • 完成百分比法。实际测量已完工作量，并计算已完工作量占总工作量的百分比。
              • 加权里程碑法。对控制账户或工作包规定进度里程碑及相应权重，某个里程碑实现了，就视为完成了多少工作量。
              • 固定公式法。在控制账户或工作包开始时计算某个百分比的已完工作量，在控制账户或工作包完工时再计算剩余百分比的已完工作量。
                • 如果没有办法或不需要准确测量控制账户或工作包的实际完成状况，而只能或只须大概估计一下，就应该使用固定公式法。固定公式法中最常用的是50/50规则。
                • 工作一旦开始，就视为已完成50%的工作量；然后，在工作的整个执行期间不计算任何已完工作量，要等到工作全部完成，才计算另外50%的已完工作量。
                • 根据需要，50/50规则也可以被修改成30/70规则、20/80规则、10/90规则甚至0/100规则。
          • 依附型活动（Apportioned Effort）。无法独立开展，而是依附于独立型活动，会间接导致项目产品形成的活动，其完成情况按独立型活动的完成情况的同样百分比来计算。独立型活动完成了百分之几，依附型活动也就完成了同样的百分之几。例如，砌墙项目的监理工作。
          • 支持型活动（Level of Effort）。与项目产品形成无关，对独立型和依附型活动起支持作用的后勤工作，其完成情况按日历时间的流失来计算。只要日历时间过掉了，应该完成的支持型活动就视为全都完成了。例如，厨师为砌墙工人和监理工程师做饭。
            • 支持型活动不会出现进度偏差，既不会进度提前，也不会进度落后。
        • 一般情况下，不要直接用已经消耗的材料、人工等的数量占计划的全部数量的百分比来报告项目的进展情况。
      • 7.5.4 挣值管理练习（略）
  • 第8章 项目质量管理
    • 8.1 相关基础知识
      • 8.1.1 质量管理概述
        • 项目质量管理旨在保证项目达到既定的质量要求，保证项目产品能够发挥既定的功能，从而满足项目相关方的特定需求。它包括制定和执行质量政策、质量目标和质量职责等。
        • 质量管理不仅是一系列技术的应用，而且更重要的是，人们必须具备一系列特定的理念。质量管理，不仅是技术问题，更是理念（价值观）问题。
        • 项目质量管理的许多理念和做法与一般的质量管理相同。项目质量管理既包括对项目的产品（结果）的质量管理，也包括对项目的管理工作的质量管理。
      • 8.1.2 质量的概念
        • 质量是产品、服务或成果用于满足用户明示和潜在需求的全部特性和功能的总和。这个定义很全面，但是不太可操作。
        • 质量是指达到技术要求和适合用户使用。这个定义不全面，但更可操作。
        • 与项目范围管理反对镀金一样，项目质量管理也反对镀金。
        • 好质量的产品是符合要求的适用产品，而不是超过要求的优质产品。
        • 对项目团队外部的相关方（如项目发起人），项目经理对整个项目的质量承担最终责任。
      • 8.1.3 有效的质量管理做法
        • 最重要的是，在整个组织中建立和维护优秀的质量管理文化，使每个人在每个环节都自觉地确保工作过程的质量和工作成果的质量。
        • 在进行项目规划和产品设计时，必须认真考虑对工作过程和工作成果的质量要求，把质量融入项目规划和产品设计中。
        • 在项目执行和产品开发中，必须严格执行事先规划和设计的工作过程，并做必要的持续改进来保证质量。
        • 在交付工作成果之前，必须进行适当的检查以发现和纠正缺陷。在工作成果交付之后，还要通过用户调查等方法来了解客户满意度，包括发现和解决可能存在的产品缺陷。这都属于质量控制。
      • 8.1.4 重要的质量管理理念
        • 第一次就把事情做对。这才是最节约成本的方法，因为可以避免返工、避免废品等。
        • 质量是免费的。使质量合格所得到的回报，通常都要大于所付出的代价。
        • 预防胜于检查。
        • 持续改进或凯思恩（Kaizen）。这两个词的意思相同，后者是日本语中的“改善”的音译。通过持续不断的小改进积累成大改进，往往比瞬间的大改进更有价值。
        • 准时制（零库存）管理（Just In Time，JIT）。它本来是一个用来降低库存成本的方法，是财务会计中的概念，但也可以用来促进质量管理水平的提高。
        • 全面质量管理（Total Quality Management，TQM）。强调全过程的质量管理和全员参与质量管理。整个生产过程中的每个环节都要做好质量管理，任何一个环节出错，产品质量就会出错。
        • 管理者对质量负85%的责任，而工人只有15%的责任。
    • 8.2 各过程的输入与输出
      • 8.2.1 输入与输出的关系总览
      • 8.2.2 规划质量管理
        • 在项目章程的指导下，根据项目管理计划中已有的内容，以及多种项目文件来编制质量管理计划和质量测量指标。质量测量指标是对质量管理计划中的高层级质量标准的具体化。
        • 项目章程中的项目目标、项目成功标准、项目审批要求等内容，都会对编制质量管理计划和质量测量指标有直接影响。
        • 项目管理计划的各个组成部分对本过程的作用为：
          • 需求管理计划有利于把质量管理的方法与需求管理的方法协调起来。
          • 风险管理计划有利于明确该如何管理与质量有关的风险。
          • 相关方参与计划有利于引导相关方合理参与质量管理计划和质量测量指标的制订。
          • 范围基准有利于针对每个WBS要素制定质量测量指标。
        • 以下项目文件对本过程的作用为：
          • 假设日志。需要考虑各种假设条件和制约因素。
          • 需求文件。其中包含的需求及其验收标准，对确定质量管理方法和质量测量指标有直接影响。
          • 需求跟踪矩阵。其中的需求验收方法（如测试场景），对确定质量检查方法有直接影响。
          • 相关方登记册。有利于识别对质量管理和质量标准有特别要求的相关方。
          • 风险登记册。在确定质量标准和质量测量指标时，必须考虑风险。
        • 实际上，项目管理计划中的范围基准、进度基准和成本基准，都会直接影响质量标准和质量测量指标的确定，只是《PMBOK®指南》中没有列全。
      • 8.2.3 管理质量
        • 管理质量过程的输入与输出：
          • 执行质量管理计划（项目管理计划的组成部分）中规定的质量管理活动。
          • 按质量测量指标（一种项目文件）把质量做合格。
          • 把质量标准和质量测量指标转化成测试与评估文件，供控制质量过程使用。
          • 根据风险报告（一种项目文件）动态评审实现项目质量目标的机会和威胁，以便提出必要的变更请求（如调整质量管理方法或质量测量指标）。
          • 根据质量控制测量结果（一种项目文件）反思质量管理体系的合理性，以便提出必要的变更请求。
          • 重复开展本过程时，需要参考已记进经验教训登记册（一种项目文件）的质量管理经验教训。
          • 根据各种资料编制质量报告，向项目相关方报告项目质量绩效。
      • 8.2.4 控制质量
        • 控制质量过程的输入与输出：
          • 把体现在工作绩效数据中的质量实际绩效，与体现在质量管理计划（项目管理计划的组成部分）和质量测量指标（一种项目文件）的计划要求进行对比，得出质量控制测量结果。
          • 检查项目工作或成果的质量时，需要使用测试与评估文件（如其中的质量测试程序）。
          • 对已经完成的可交付成果进行质量检查。如果质量合格，就得到核实的可交付成果；如果不合格，就提出变更请求。
          • 检查已批准的变更请求的执行情况，把检查结果写入质量控制测量结果（是否已执行到位及其原因）。
          • 把质量控制测量结果、工作绩效数据和项目计划要求综合起来分析，得出工作绩效信息。如果工作绩效信息不理想，就提出变更请求。
    • 8.3 各过程的主要工作和成果
      • 8.3.1 规划质量管理
        • 规划质量管理过程旨在确定项目的质量标准，并决定如何通过管理质量过程与控制质量过程来达到这些标准。这些内容会包含在质量管理计划和质量测量指标中。
          • 质量管理计划描述将如何在执行组织的质量政策的指导下开展质量管理工作，以便达到项目的质量要求。
          • 质量管理计划将作为项目管理计划的组成部分，用来指导管理质量和控制质量过程。
          • 质量测量指标是对质量管理计划中的高层级质量标准的具体化和可操作化。
        • 质量管理计划的主要内容包括：
          • （1）项目的质量政策。可以直接引用组织的质量政策，也可以对组织的质量政策略加修改。
          • （2）项目的质量目标。包括项目的总体质量要求和高层级质量标准，如项目必须符合某个行业标准中的规定。
          • （3）质量角色和职责。谁应该对项目质量承担什么责任。
          • （4）质量管理程序、活动和工具。用于履行职责和实现目标的程序、活动和工具。
          • （5）对工作过程和成果的质量评审。哪些工作过程和成果必须接受质量评审？将如何进行质量评审？将如何利用评审结果？
        • 规划质量管理过程不仅要编制程序性计划（质量管理计划），而且要编制实体性计划（质量测量指标）。
      • 8.3.2 管理质量
        • 管理质量过程是把质量管理计划中的内容细化成可执行的质量管理活动，并加以执行，以在项目上落实组织的质量政策。在管理质量过程中，要做以下五件主要工作：
          • （1）让主要相关方确信项目将会达到质量要求，从而能够满足他们的需要、期望和需求。
          • （2）执行（包括细化后执行）质量管理计划中规定的质量管理活动，确保项目工作过程和工作成果达到具体质量测量指标和高层级质量标准。
          • （3）编制将用于质量控制的质量测试与评估文件。这是把质量标准和质量测量指标转化成质量测评工具（如质量核对单）。
          • （4）根据质量管理计划和质量控制测量结果（实际质量绩效），提出变更请求，实现过程改进。
          • （5）根据质量管理计划、质量测量指标、本过程的实施情况，以及质量控制测量结果，编制质量报告。
        • 每个人都需要参与管理质量过程，包括项目经理、项目团队成员、执行组织的管理人员，甚至客户。
      • 8.3.3 控制质量
        • 控制质量过程旨在检查具体的工作过程或可交付成果的质量，并记录检查结果，确定是否符合质量测量指标和高层级质量标准。如果不符合，则要找出原因，并提出纠偏建议（针对工作过程）或缺陷补救建议（针对可交付成果）。
        • 本过程要做以下四件事情：
          • （1）检查具体的工作过程的质量，并记录检查结果（质量控制测量结果）。
          • （2）检查已完成的可交付成果是否符合质量要求（技术上是否正确），并记录检查结果（质量控制测量结果）。
          • （3）检查已批准的变更请求是否实施到位，并记录检查结果（质量控制测量结果）。
          • （4）基于前述检查结果和相关计划，整理出工作绩效信息，并提出变更请求。
        • 质量控制往往由专门的质量控制人员或质量控制部门来做。
      • 8.3.4 三个过程之间的关系
        • 控制质量过程提出的“变更请求”是要求解决具体的工作过程或可交付成果中存在的质量问题，而管理质量过程提出的“变更请求”则是要求修改质量管理体系。
        • 这三个过程之间的关系可以简述为：
          • （1）在规划质量管理过程中，建立质量管理体系，包括质量标准、质量测量指标，以及将如何实现。
          • （2）在管理质量过程中，执行质量管理体系。
          • （3）在控制质量过程中，检查质量管理体系的执行结果。
          • （4）在管理质量过程中，根据控制质量过程的检查结果以及规划质量管理过程编制的计划，评价质量管理体系的合理性，提出变更请求（改进建议）。
          • （5）在变更请求（改进建议）被批准之后，回到规划质量管理过程修改（完善）质量管理体系。
        • 《PMBOK®指南》中，把旧版中的“实施质量保证过程”改成了“管理质量过程”, 质量保证和质量控制的主要区别
    • 8.4 各过程的工具与技术
      • 8.4.1 规划质量管理
        • 本过程的工具可以概述为：
          • 先使用数据收集来收集数据，再使用数据分析来分析数据，最后使用决策来做出关于质量管理方法、质量标准和质量测量指标的决定。
          • 整个过程中，需要借助专家判断，附加开展测试与检查规划（策划将如何开展质量测试和检查）。
          • 整个过程中，需要使用数据表现，借助一些可视化图形技术来更有效地规划质量管理。必要时，召开会议。
        • 1．数据收集
          • 访谈项目相关方、主题专家和团队成员等，了解他们对质量管理、质量标准和质量测量指标的意见。也可以召集相关人员进行头脑风暴。
          • 用标杆对照的方法，收集可比项目的质量管理做法、质量标准和质量测量指标，作为本项目的标杆。
        • 2．数据分析
          • 通过成本效益分析，了解各种不同质量管理方案或质量标准所需的成本和能产生的效益。在确定质量标准时，应该考虑实现质量标准所需的成本及带来的效益。可以用边际分析的方法，确定最佳质量标准。边际效益等于边际成本时的质量标准是最佳的。
          • 列入工具与技术的“质量成本”其实是“质量成本分析”。
          • 通过质量成本分析，了解各种可能的质量成本组合方案（不同种类的质量成本各占多大比重）。质量成本是为达到产品或服务的质量标准而付出的所有努力的总代价，也就是用于质量管理的成本。
          • 质量成本中既包括为保证质量符合要求所做的工作的成本，即一致性成本；也包括因质量不符合要求而产生的成本，即不一致性成本。
          • 质量成本的另一种常见分类方法，是把成本分成预防成本、评估成本和失败（缺陷）成本。
            • 预防成本是预防项目发生质量问题的成本，如质量计划编制、人员培训、设计复核等。用于规划质量管理与管理质量的成本都属于预防成本。
            • 评估成本是检查产品或生产过程，确认它们是否符合要求而发生的成本，如检查和测试成本。用于质量控制的成本属于评估成本。
            • 失败成本是进行缺陷补救所发生的成本，以及因质量缺陷而遭受的其他损失，又可分为内部失败成本和外部失败成本。
              • 前者是指在产品交给客户之前，在项目内部处理缺陷所产生的成本；
              • 后者是指产品交给客户之后，而产生的缺陷处理成本、产品召回成本和信誉损失成本等。
          • 预防成本和评估成本属于一致性成本，而失败成本则属于不一致性成本。
        • 3．决策
          • 借助多标准决策分析技术，用一系列标准（可带不同权重）对各种质量管理方法、各种质量标准或各种质量测量指标进行打分，排出优先级顺序，并据此选择排序靠前的方法、标准或指标。
        • 4．数据表现
          • 流程图：用流程图描述一个生产过程怎样从开始走到结束，以及中间各步骤之间的相互关系，有助于分析生产过程中的哪个或哪几个环节最容易出现质量问题。
          • 逻辑数据模型：逻辑数据模型（Logical Data Model）是常用于数据库开发的一种可视化技术。其详细程度介于概念数据模型和实物数据模型之间。
            • 概念数据模型只显示概念之间的逻辑关系。逻辑数据模型则在概念之下添加了一些细节信息。
            • 实物数据模型则进一步添加用于实现这些细节的技术信息。逻辑数据模型有利于防止数据不完整。
            • 如果删去任何一条逻辑关系线，就会导致最后的数据不完整。
          • 矩阵图和思维导图：矩阵图用于考察各种质量指标之间的相互关系，或者质量指标与影响因素之间的关系。
            • 有以下六种常用的矩阵图：
              • 屋顶形。用于表示同属一组变量的各个变量之间的关系。
              • L形。通常为倒L形。用于表示两组变量之间的关系。
              • T形。用于表示一组变量分别与另两组变量的关系。后两组变量之间没有关系。
              • X形。用于表示四组变量之间的关系。每组变量同时与其他两组有关系。
              • C形。用于表示三组变量之间的关系。三组变量同时有关系。
              • Y形。用于表示三组变量之间两两关系。每两组变量之间都有关系。
            • 思维导图用于把各种条件、因素等与某个核心质量要求联系起来，特别适合做个人或群体的发散性思考。
      • 8.4.2 管理质量
        • 管理质量过程的工具，从数据收集和数据分析到决策和数据表现，这些大类与规划质量管理过程一致。但是，大类下面的具体技术并不完全相同。本过程还有审计、面向X的设计、问题解决和质量改进方法。
        • 1．数据收集和数据分析
          • 因为在管理质量过程中需要收集客观数据，所以就没有用规划质量管理过程中的头脑风暴和访谈。在本过程，可以用核对单收集数据，反映该做的事情是否已做，又是否已做到符合要求。
          • 数据分析中包括备选方案分析、文件分析、过程分析和根本原因分析。
            • 备选方案分析用于分析多种可选的质量活动实施方案，并做出选择。
            • 文件分析用于分析质量控制测量结果、质量测试与评估结果、质量报告等，以便判断质量过程的实施情况好坏。
            • 过程分析用于把一个生产过程分解成若干环节，逐一加以分析，发现最值得改进的环节。
            • 根本原因分析用于分析导致某个或某类质量问题的根本原因（系统原因）。
          • 这些数据收集和分析技术也可用于控制质量过程。
        • 2．决策
          • 可用多标准决策分析技术来对多种质量活动实施方案进行排序，并做出选择。
        • 3．数据表现
          • 数据表现中包括亲和图、因果图、流程图、直方图、矩阵图和散点图。
            • 亲和图用于对导致质量问题的各种原因，根据其亲近关系进行归类。·
            • 因果图，也叫鱼刺图或石川图，用来分析导致某一结果的一系列原因；有助于人们进行创造性、系统性思维，找出问题的根源。它是进行根本原因分析的常用方法。
            • 流程图用于完整地分析某个或某类质量问题产生的全过程。
            • 直方图是一种显示各种问题分布情况的柱状图。每根柱子代表一个问题，柱子的高度代表问题出现的次数。
            • 矩阵图，如前文所述。
            • 散点图，用X轴表示自变量，Y轴表示因变量，定量地显示两个变量之间的关系，是最简单的回归分析。所有数据点的分布越靠近某条斜线，两个变量之间的关系就越密切。
          • 这些数据表现技术也可用于控制质量过程。
        • 4．审计
          • 质量审计旨在对质量管理活动进行独立的、结构化的审查，以便总结质量管理方面的经验教训。
            • 独立的审查是指审计人员应该不受干扰地开展工作，提出意见。
            • 结构化审查是指按事先规定的审查程序、方法和内容进行审查。
        • 5．面向X的设计
          • 面向X的设计中的X既可以是卓越（Excellence）的意思，也可以是产品的某种特性，如可靠性、可用性、安全性、经济性。前者追求整个产品在整个生命周期中的最优化，后者重点改进产品的某个特性。
        • 6．问题解决和质量改进方法
          • 问题解决是指用结构化的方法从根本上解决在控制质量过程或质量审计中发现的质量管理问题。从定义问题、识别根本原因，到形成备选解决方案、选择最好的方案，再到实施选定的方案、核实解决效果。
          • 在管理质量过程中，要基于过程分析的结果，用质量改进方法去做过程改进。过程改进旨在使生产过程更加顺畅、稳定，减少生产过程中的浪费或（和）降低产品缺陷率。可以用来做过程改进的方法有很多，如戴明环、六西格玛、精益生产、精益六西格玛等。
      • 8.4.3 控制质量
        • 控制质量过程的工具包括数据收集、数据分析和数据表现，还有检查、测试或产品评估，以及会议。
        • 1．数据收集
          • 在检查质量时，可用核对单和核查表收集客观数据。核对单用于打勾，了解哪些要求已经或没有达到。
          • 用统计抽样从全部产品中抽取少量样本进行检查，并根据样本的情况推论出总体（全部产品）的情况。
          • 通过问卷和调查，收集客户对产品质量的满意度，以及客户在产品使用过程中可能已经发现的质量缺陷。
        • 2．数据分析
          • 通过绩效审查，分析实际质量绩效偏离计划要求的程度和原因。用根本原因分析找出导致某个具体质量缺陷的根本原因。
        • 3．数据表现
          • 数据表现技术包括因果图、直方图、散点图和控制图。
            • 直方图（常用来控制质量），即帕累托图。帕累托图是“二八定律”（20%的原因导致了80%的问题）的图示，用来对导致问题的各种原因按发生频率从高到低排序（频率最高的排在最左边），以便人们集中精力处理最关键的少数（约20%）原因。
            • 用控制图按一定的时间间隔检查和记录质量情况，考察一个过程是否稳定。在规划质量管理时，需要确定图中目标值、控制上下限、规格上下限的位置，以及质量检查的频率。在控制质量过程中，用控制图来检查过程的质量和成果的质量。关于控制图的一些重要概念如下：
              • 控制上限和下限。通常用两条虚线表示，是需要或不需要采取纠正措施的分水岭。如果质量偏差落在控制上限和下限之内（七点规则的情况除外），项目执行过程就是受控的，不需采取纠正措施。如果落在控制上下限之外，项目执行过程就失控了，就需要调查原因并采取纠正措施。对于重复性的过程，控制上限和下限通常设在正负三个标准差。
              • 目标值。位于控制上限和下限中间的那条线，表示允许的偏差或绩效的平均值。
              • 规格上限和下限。客户要求、合同规定或法律规定的质量底线。控制上限和下限是项目管理团队自行设计的，而规格上限和下限则来自客户、合同或法律的硬性要求。质量偏差只要在规格上限和下限之内，哪怕超出了控制上限或下限，产品质量仍然是合格的，不需要缺陷补救。一旦质量偏差突破规格上限或下限，产品就是不合格的，必须进行缺陷补救。规格上限和下限通常是控制上限和下限之外的两条线，用实线表示。
              • 控制限是系统的声音（Voice of System），规格限则是客户的声音（Voice of Customer）。前者是项目经理根据一般的统计原则计算出来的，后者是客户要求的。
              • 过程失控。如果偏差超出了控制上限或下限，或者虽然在控制上限与下限之内，但是偏差分布具有非随机特性，那么，从统计意义上讲，项目执行过程失控了，就应该调查原因并采取相应措施予以纠正。
              • 七点规则。与“二八定律”相似的经验式规则。如果连续七个观测值都落在控制图目标值线的同一边（即便都在控制上限与下限之内），或者在目标值线两边呈同方向变动（越来越高或越来越低），那么也应该认为这种数据分布是“非随机”的，意味着执行过程失控了，需要及时调查原因并采取纠正措施。由随机原因引起连续七个点都落在同一边或呈同方向变化的概率是非常低的，以至于我们宁愿相信是非随机原因（特殊原因）引起的。
              • 非随机原因或特殊原因。控制图中任何需要调查分析的观测值，都是非随机原因引起的，如七个观测点在同一边或呈同方向变动、任一观测点超过控制上限或下限。非随机原因引起的偏差，意味着项目执行过程失控。
              • 随机原因或普遍原因。系统本身的内在特性决定的、可预测的偏差来源。
              • 任何随机原因引起的偏差都是可接受的，不意味着过程失控；任何非随机原因引起的偏差都是不可接受的，都意味着过程失控。
            • 结果失控（超出规格上限或下限）往往是过程失控（超出控制上限或下限，或其他非随机的变化）长期得不到解决而必然导致的。控制图的一个重要意义是：提醒人们在还有时间解决问题时发现问题并采取措施，即在结果失控之前就及时发现和解决过程失控。
            • 运用控制图，能够及时监测到项目执行过程的失控，即何时出现了非随机原因引起的偏差。但单纯依靠控制图，还不能知道为何失控。要探究失控背后的原因，还需要借助因果图、流程图等其他工具。
        • 4．其他工具
          • 开展实地检查以及测试或产品评估，核实可交付成果的质量是否合格。不同行业的项目，检查或测试方法可能有很大区别。
          • 召开会议，确认已批准的变更请求是否已经实施到位，也可回顾和总结质量管理方面的经验教训。
    • 8.5 统计概念和质量管理大师
      • 8.5.1 统计概念
        • 质量管理中常会用到统计工具，如检验偏差有没有统计上的显著意义。PMP®考试中可能考到一些基本的统计知识，例如：
          • 概率。某件事发生的可能性大小，如1%。
          • 随机抽样。总体中的每个个体都有等同的机会（概率）被抽中。
          • 统计上的独立性。两个事件之间没有任何联系，前一事件的结果丝毫不会影响后一事件的结果。
          • 统计上相互排斥。在同一次实验中，两个结果不可能同时出现。相互排斥，是在同一次实验中；而相互独立，则是在不同的实验中。
          • 六西格玛管理。西格玛是标准差的符号。六西格玛管理就是六个标准差管理，是指质量管理要达到这样的高水平：每生产100万个产品，只有3.4个有质量问题。合格率达到了99.9997%。
          • 均值、中位数和众数。均值是所有测量数据的算术平均值。通过把各数据与均值比较，而不是与中位数或众数比较，计算标准差。
          • 边际分析。分析单位质量改进能够产生的效益增加或需要支付的成本增加。最佳的质量应该是效益增加和成本增加相等时的质量。
      • 8.5.2 质量管理大师
        • 考试中可能考到以下几位质量管理大师：
          • 戴明（Deming）。重要贡献包括戴明环、质量管理14条、持续改进、预防胜于检查等。
          • 朱兰（Juran）。强调“质量是适合使用”，提出质量与等级的区别，提出质量管理三部曲（质量规划、控制和改进）。
          • 克劳斯比（Crosby）。强调“质量是符合要求”，提出零缺陷和第一次就把事情做对，提出质量可以用不一致性成本来衡量（当不一致性成本为零时，质量就是好的，所以又可以说，质量是免费的）。
          • 石川（Ishikawa）。提出质量圈和鱼刺图，总结出七种基本质量工具。
          • 田口（Taguchi）。提出质量损失函数（产品质量波动会给社会带来损失）、稳健设计方法（质量首先是设计出来的，其次才能制造出来）、实验设计方法。
      • 8.5.3 几个注意点
        • 保证质量可以提高生产率，降低成本。
        • 劣质和低等级不是一回事。前者是指质量不符合要求，有缺陷；后者是指质量没有问题，只是功能少一些。
        • 如果没有足够的成本来满足既定的项目要求，可以降低项目的等级（缩小项目范围，减少项目功能），但不能牺牲质量。
  • 第9章 项目资源管理
    • 在PMP®考试中，除非题目中的情景使你有理由选择排序靠后的解决方法，一般情况下都应选择前文排序靠前的解决方法。
      • 注意：对于团队成员之间的私人矛盾，不能用合作或面对的方法去解决，而只能用缓和的方法，即要求成员以工作为重（共同点），不要把私人矛盾（差异点）带到工作中。
    • 9.1 概述
      • 项目资源管理是指为完成项目而识别、获取和管理所需的人力资源和实物资源。
        • 人力资源是直接从事项目工作（包括管理工作和技术工作）的项目团队成员。
        • 实物资源是直接用于项目的材料、设备和设施。
      • 对于项目团队，项目经理应该：
        • 首先必须是领导者。作为领导者，他必须创建有利于合作的团队氛围，建设高效的项目团队；必须激励团队成员，培养成员和团队的工作能力，鼓励成员积极参与项目规划和决策。
        • 其次，项目经理必须是管理者。作为管理者，他必须要求团队成员遵守规范的项目管理制度，严格按要求开展启动、规划、执行、监控和收尾过程组的各种活动。
        • 领导主要靠软技能，管理主要靠硬技能。
      • 对于实物资源，项目经理必须有效地获取、分配和使用。他必须了解项目当前和未来对实物资源的需求，包括资源的种类、性能和数量；必须了解可用的实物资源供应渠道；必须在确保实物资源按时可用的同时，防止库存过多。
      • 无论是人力资源还是实物资源，都既可以来自项目执行组织内部，也可以来自项目执行组织外部。项目资源管理知识领域关注来自组织内部的资源，项目采购管理知识领域关注来自组织外部的资源。
    • 9.2 各过程的输入与输出
      • 9.2.1 输入与输出的关系总览
      • 9.2.2 规划资源管理
        • 在项目章程的指导下，根据项目管理计划中的质量管理计划和范围基准编制资源管理计划。质量管理计划和范围基准有利于确定为达到既定的质量标准和交付特定的WBS要素，而需要如何开展资源管理。
        • 虽然《PMBOK®指南》中只列出了质量管理计划和范围基准，但实际上，需求管理计划、范围管理计划、进度管理计划、成本管理计划、进度基准和成本基准（都是项目管理计划的组成部分），也会影响规划资源管理过程。
        • 应该根据项目目标以及拟用的目标实现方法来确定项目资源管理方法。
        • 本过程还需要用以下项目文件作为输入：
          • 项目进度计划。资源管理方法应该有利于项目进度计划的实现。
          • 需求文件。资源管理方法应该有利于实现既定的需求。
          • 风险登记册。开展资源管理时，应该利用与资源有关的机会，减轻与资源有关的威胁。
          • 相关方登记册。有些相关方对资源管理方法有特别的要求。
          • 本过程还需要编制团队章程。
      • 9.2.3 估算活动资源
        • 根据项目管理计划和各种项目文件编制资源需求，以及作为附件的估算依据。然后，再把用于不同工作的同种资源汇总，形成资源分解结构。
        • 项目管理计划中的资源管理计划规定了估算活动资源的方法，范围基准则有利于把活动的资源需求逐层向上汇总到工作包、控制账户和整个项目。
        • 在本过程中，也需要汇总得出整个项目的资源需求。
        • 以下项目文件是本过程的输入：
          • 活动清单、活动属性。根据活动的性质，对每个活动估算资源。
          • 假设日志。估算资源时需要考虑相关的假设条件和制约因素，如关于劳动生产率的假设。
          • 成本估算。准备花多少钱去做某个活动，会直接决定能够找什么级别的资源。
          • 风险登记册。有利于挑选合适类别的资源或使用合适数量的资源去应对风险登记册中的风险。
          • 资源日历。资源（人员、设备或设施）可用于项目的日期，会直接决定所需资源的数量。
      • 9.2.4 获取资源
        • 根据项目管理计划和各种项目文件，获取所需的人力资源和实物资源，并进行分配，得出实物资源分配单和项目团队派工单，同时需要确定资源的实际可用日期，形成资源日历。如果实际获取的资源并不完全符合原定的要求（如技能水平较低），就需要提出变更请求。
        • 项目管理计划中的资源管理计划规定了用于获取资源的方法，如人员招聘程序和渠道；采购管理计划有利于通过采购从组织外部获取资源；成本基准则有利于控制用于获取资源的总成本。
        • 以下四种项目文件，也是本过程的输入：
          • 项目进度计划。获取资源的时间、种类和数量，必须符合进度计划的要求。
          • 资源需求。按其中的规定，获取所需要的资源。
          • 相关方登记册。需要与掌握资源的相关方打交道。
          • 资源日历。根据需要资源的日期，去获取资源。
            • 资源日历，既是估算活动资源过程和获取资源过程的输入，又是获取资源过程的输出。
            • 首先，根据预订的资源日历（记录需要资源的日期）估算所需资源；其次，根据预订的资源日历去获取资源；最后，获取资源之后，确认资源的实际可用日期，得出更新后的资源日历（记录资源的实际可用日期）。
      • 9.2.5 建设团队
        • 根据项目管理计划中的资源管理计划，以及各种项目文件，开展团队建设活动，提高团队绩效。团队绩效的提高情况，需要记录在团队绩效评价中。开展团队建设活动，可能导致需要修改项目管理计划或相关的项目文件，从而需要提出变更请求。
        • 以下项目文件都是本过程的输入：
          • 项目进度计划。为实现进度计划而开展团队建设活动。
          • 项目团队派工单。针对不同岗位的成员开展不同的团队建设活动。
          • 资源日历。只能选择相关成员在项目上工作的日期开展团队建设活动。
          • 团队章程。用于指导团队建设的高层次文件。
          • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训。
      • 9.2.6 管理团队
        • 本过程旨在了解团队成员和整个团队的工作表现，解决问题和冲突，并提出必要的变更请求。
        • 项目管理计划中的资源管理计划，规定了管理团队的基本方法。
        • 成员个人和整个团队的表现好坏，需要查看团队绩效评价文件。需要根据工作绩效报告中的项目实际绩效及其与计划要求的偏离程度，来反思团队的表现。
        • 以下项目文件也是本过程的输入：
          • 团队章程。用于指导团队管理的高层次文件。
          • 项目团队派工单。对不同岗位的人员，业绩（工作表现）要求不尽相同。
          • 问题日志。根据项目所发生的问题的数量和严重性，来反思团队的表现。
          • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训。
          • 需要特别提及的是，获取资源、建设团队和管理团队这三个过程都有事业环境因素更新这个输出。
        • 为了强调项目经理应该实实在在地与团队成员打交道，而不是居高临下地以旁观者的身份去“监督”团队成员的表现，《PMBOK®指南》故意把管理团队过程放在执行过程组，而不是监控过程组。
      • 9.2.7 控制资源
        • 根据项目管理计划中的资源管理计划，把体现在工作绩效数据和问题日志中的资源获取、分配和使用的实际情况，与体现在相关项目文件中的计划要求进行比较，并把比较的结果记录在工作绩效信息中。如果结果不理想，就提出变更请求。对于按协议（合同）获取的资源，需要与协议中的规定进行比较。
        • 项目文件包括：
          • 问题日志。其中会记录与资源有关的实际问题，如资源短缺或供应延迟。也可以根据其中记录的其他问题去反思资源的使用情况。
          • 实物资源分配单、项目进度计划、资源需求、资源分解结构。这些文件都直接记录了对相关资源的计划要求，例如，何时何种资源应该就位。
          • 风险登记册。其中记录了与资源有关的风险，有利于分析资源问题产生的原因及后果。
          • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训。
    • 9.3 各过程的主要工作和成果
      • 9.3.1 规划资源管理
        • 本过程旨在编制资源管理计划，规定将如何估算、获取、使用和管理项目资源，包括人力资源和实物资源。资源管理计划的主要内容包括：
          • 同时适用于人力和实物资源的内容：资源估算方法和资源获取方法。
          • 专用于人力资源的内容：团队中应该设立的角色及其权责、团队的组织结构图、成员管理安排（如分配、考核和遣散）、成员培训安排、团队建设方法（如对团队建设活动的要求）、认可和奖励安排（如何时颁发何种奖励）。
          • 专用于实物资源的内容：资源监控方法，即如何监督和控制实物资源的获取和使用情况。
          • 对于人力资源，本过程还要制定团队章程，规定项目团队的愿景和使命，以及项目团队的核心价值观、行为规范和工作规则。团队章程使团队成员对什么行为是可接受或不可接受的，建立和保持基本一致的认识。
      • 9.3.2 估算活动资源
        • 本过程旨在估算项目工作所需的资源的类别、类型和数量，包括人力资源和实物资源。
          • 资源的类别是指资源的种类，如人力、材料、设备。
          • 资源的类型是指资源的技能水平（等级），如一级工、二级工、三级工。
          • 这些信息都需要反映在资源需求文件中。
        • 首先估算各个活动的资源需求，然后协调各个活动的资源需求（如两个活动可以共享同一个资源），并逐层向上汇总，得出工作包、控制账户、WBS分支和整个项目的资源需求。
        • 整个项目的资源需求情况可以用资源分解结构来表示。在资源分解结构中，根据资源的类别和类型把整个项目所需的资源逐层分解。
      • 9.3.3 获取资源
        • 本过程旨在以正确的方式在正确的时间获取正确的人力资源和实物资源。
        • 本过程还需要对所获取的资源进行分配，并形成相应的资源分配文件，包括实物资源分配单和项目团队派工单。
        • 对所获得的团队成员，必须仔细分析他们的性格、态度、能力、胜任力和可用性等，并基于分析结果进行工作分配，确定该采用什么领导风格和手段去启发、激励和影响他们。
      • 9.3.4 建设团队
        • 本过程旨在开展各种团队建设活动，创建和维护良好的团队氛围，提高团队成员个人的胜任力，提高整个团队的工作能力，以提高团队绩效，实现项目目标。
        • 决定一群人成为一个团队的最关键的因素是团队精神。
        • 为了取得优秀的团队绩效，在团队中需要有开放式沟通、相互信任的氛围、建设性的冲突解决、合作式的问题解决和决策制定。
        • 项目通常是跨专业和跨部门的，项目团队也就因此具有较高的多样性（多元化），即团队成员来自不同的专业、不同的部门，具有不同的背景。
        • 按照塔克曼的团队建设五阶段理论，项目团队要经过从形成、震荡、规范、成熟到解散这五个阶段。
          • 在形成阶段，团队成员抱着自己的个人目的加入团队，需要相互认识。因为成员之间还不熟悉，所以不能采用参与式领导风格，只能采用命令或指挥式领导风格。
          • 在震荡阶段，团队成员尝试合作，出现了大量矛盾，就需要磨合。项目经理应该像教练一样指导团队成员尽快完成磨合。教练型领导风格是介于命令式与参与式之间的。
          • 在规范阶段，团队建立了一系列书面规章制度，团队成员都按规章制度行事。项目经理应该给团队成员提供支持，以便他们遵守规章制度。支持型领导风格是参与式领导风格的一种。
          • 在成熟阶段，书面规章制度已经在团队成员的心里内在化了，即便不存在，也无所谓了。项目经理应该用授权型领导风格（参与式领导风格的一种），把大量工作授权给团队成员去完成。
          • 在解散阶段，不少团队成员都在找以后的出路，可能不安心本项目的工作。项目经理又要重新采用命令或指挥式领导风格。
        • 在项目团队建设的不同阶段，项目经理应该采取有所不同的领导风格。
        • 优秀的项目团队是以工作和结果为导向的，并且能够把结果做得符合要求，也就是说，团队成员把按要求完成工作任务放在第一位。
      • 9.3.5 管理团队
        • 本过程旨在跟踪团队成员和整个团队的工作表现，并把跟踪到的情况反馈给团队成员；还要预防和解决团队中出现的问题，管理团队成员的变化。
        • 在实际工作中，建设团队与管理团队肯定无法截然分开。它们之间的主要区别是：
          • 建设团队过程，是基于对什么行为能导致良好团队绩效的预测，采取这些行为来“推动”团队的发展。
          • 管理团队过程，是基于对实际行为及其效果的回顾，采取补充行为来“拉动”团队的发展。管理团队，更像一个监控过程。
      • 9.3.6 控制资源
        • 本过程旨在监督和控制实物资源的获取、分配和使用，提出必要的变更请求。
        • 应该及时发现和处理资源短缺或资源剩余，通知项目相关方资源使用情况和出现的问题，管理与资源有关的变更。
    • 9.4 各过程的工具与技术
      • 9.4.1 规划资源管理
        • 本过程的工具包括专家判断、会议、组织理论和数据表现。
          • 组织理论是关于组织中的个人、小组、团队、部门，以及整个组织应该如何行动的学问。在理论的指导下编制团队资源管理计划，效率更高（编计划更容易），效果更好（计划的质量更好）。
          • 数据表现包括用于描述项目团队的组织结构的三种主要方式：
            • 传统的层级型。层级型中又包括工作分解结构和组织分解结构。
            • 责任分配矩阵。用二维的矩阵图把每项工作分配给相应的人员或部门。
            • 文本型，如岗位说明书，主要用文字来描述哪个人或部门将对哪项工作承担什么职责。
          • 数据表现中的资源分解结构（属于层级型），则是用来展示团队和实物资源的类别、类型和数量的一种图形。
        • 在资源管理计划中需要规定将用什么方式来表示项目团队的组织结构，以及项目所需资源的分类，即需要提供相应的格式和模板。
      • 9.4.2 估算活动资源
        • 本过程的工具包括专家判断、自下而上估算、类比估算、参数估算、数据分析、项目管理信息系统和会议。几个特别的地方：
          • 自下而上估算。本过程需要把各活动的资源需求向上逐层汇总到工作包、控制账户和整个项目。
          • 数据分析。用备选方案分析来选择用于开展活动的最佳资源配置方案。不同的方案对活动的成本、工期和质量会有不同的影响。
          • 会议。估算资源时，需要与职能经理开会，因为他们是资源（特别是人力资源）的掌握者。
      • 9.4.3 获取资源
        • 本过程的工具主要是用于获取人力资源，包括预分派、决策、人际关系与团队技能，以及虚拟团队。
        • 有些关键的工作岗位，需要在项目正式启动之前就指定人选。
        • 如果项目经理对团队成员有选择权，就需要运用决策中的多标准决策分析去挑选最合适的人员。
        • 项目经理需要运用人际关系与团队技能中的谈判，与职能经理谈判，向职能经理借人；与其他项目经理谈判，争取优秀人员；与外部资源供应商谈判，获取本组织无法提供的人员。
        • 在互联网日益发达的今天，项目经理可以借助虚拟团队来提高获取人力资源的灵活性。
        • 虚拟团队需要特别好的沟通计划，需要真正的团队建设。
      • 9.4.4 建设团队
        • 中办公，无疑有利于团队建设。在虚拟团队中，应该开展临时的集中办公。在矩阵型项目组织中，不少兼职人员平常仍在各自的职能部门办公，所以临时的集中办公也就特别重要。这种临时的集中办公又称紧密式矩阵（Tight Matrix）。
        • 对于无法集中办公的成员，可以借助虚拟团队技术来建设团队，需要借助各种网络交流和沟通工具。
        • 团队建设当然需要使用沟通技术。开展正式和非正式的沟通，是团队建设的重要手段。像视频会议、在线聊天、共享网页，都是常用的沟通技术。
        • 在团队建设中，项目经理应该借助人际关系与团队技能，与团队成员打交道，激励和影响他们，并解决冲突。作为组织团队成员完成项目任务的人，项目经理必须具备很强的人际关系技能。
        • 项目经理必须具备一定的技术能力、较好的概念性能力（抽象思维能力）、很强的人际关系能力。
          • 技术能力是指从事技术工作、解决技术问题的能力。项目经理需要了解技术，但不必是技术方面的专家。
          • 概念性能力是抽象思维、把握全局、掌控方向的能力，是高层经理必须具备的能力。
        • 《PMBOK®指南》列出了以下五种人际关系技能：
          • 团队建设。开展各种各样的团队建设活动。需要有大量的成员互动和非正式沟通，以及专门开展的和融入日常工作的团队建设活动。
            • 项目管理中的许多技术工作，都不仅是技术工作，而且是很重要的团队建设活动。
          • 谈判。对工作任务安排，项目经理往往需要与团队成员谈判，做交易。
          • 激励。基于团队成员的需求，采取措施，使成员去做项目经理希望他们做的事情。
          • 影响力。不借助正式权力（职位权力）而让他人服从自己。项目经理的正式权力往往是不足的，故需要施加影响力。
          • 冲突管理。用建设性方式及时解决冲突。冲突解决得好，有利于团队建设；解决得不好，就会妨碍团队建设。
        • 在团队建设中，应该经常对团队成员的优良行为或业绩进行认可与奖励。为了使认可与奖励真正起到激励所有团队成员的作用，应该针对每个人都能够做到的行为开展认可与奖励，而不只是针对少数人能够做到的行为。
        • 如果团队成员不具备项目所需的技能，就要对他们进行培训。培训通常是团队建设中的一项重要工作。
          • 广义的培训（training）也包括教练（coach）和辅导（mentor）。表中概述了培训（狭义）、教练与辅导的主要区别。
          • 项目经理应该使用各种个人和团队评估工具，来了解团队成员的优势、劣势、喜好和厌恶等，以便有针对性地开展培训和其他团队建设活动。
          • 在团队建设中经常需要召开会议。其中的项目说明会，是指向新成员介绍项目情况和团队情况。
      • 9.4.5 管理团队
        • 本过程的工具比较简单，只有项目管理信息系统和人际关系与团队技能。以下是一些重要的人际关系技能：
          • 冲突管理。以建设性方式及时解决冲突。
          • 制定决策。通过与组织或项目团队谈判来制定决策，或者通过对组织或项目团队施加影响来制定决策。
          • 情商。能够识别、评价和管理自己和他人的情绪，也包括识别、评价和管理团队集体的情绪。
          • 影响力。不依靠正式权力而使他人服从自己。
          • 领导力。启发和激励员工做好工作，实现目标。
      • 9.4.6 控制资源
        • 本过程的工具包括项目管理信息系统、人际关系与团队技能、数据分析、问题解决。
          • 人际关系与团队技能中的谈判和影响力，有助于项目经理获取其他人（如职能经理）的支持，来解决实物资源获取和使用中的问题，如资源的工作效率达不到既定要求。
          • 数据分析中的绩效审查，用于综合分析资源使用绩效，发现偏差。其中：
            • 备选方案分析，用于分析解决资源绩效偏差的多种方案，并做出选择。成本效益分析用于选择效益成本比最好的资源绩效偏差解决方法。
            • 趋势分析用于预测未来的资源使用绩效。
          • 问题解决是指结构化的问题解决方法，用于解决资源获取、分配和使用中的问题。
    • 9.5 冲突管理
      • 9.5.1 冲突的概念
        • 冲突是指双方或多方的意见或行动不一致。有效地管理冲突，有利于加强团队建设，提高项目绩效。
        • 有效管理冲突是项目经理的重要任务之一。
        • 现代的冲突观念与传统的冲突观念的不同点：
      • 9.5.2 冲突产生的背景和原因
        • 冲突的产生往往有相应的微观、中观和宏观背景。
        • 需要注意下面四种引起冲突的原因（按常见程度排序，最常见原因排在第一位，最不常见原因排在最后）：
          • 资源稀缺。导致人们对资源的争夺。
          • 进度优先级排序。对各项工作的重要性有不同看法。
          • 工作风格差异。各人所喜欢的工作风格不同。
          • 个性（Personality）差异。人与人之间的个性不同。
        • 知道个性是引起冲突的最少见原因，有利于处理冲突时对事不对人。
      • 9.5.3 冲突的发展阶段
        • 对冲突的发展阶段，有多种不同的划分方法。较常用的一种方法是，把冲突的发展划分成如下五个阶段：
          • 潜伏阶段。冲突潜伏在相关的背景中，例如，对两个工作岗位的职权描述存在交叉。
          • 感知阶段。各方意识到可能发生冲突，例如，人们发现了岗位描述中的职权交叉。
          • 感受阶段。各方感受到了压力和焦虑，并想要采取行动来缓解压力和焦虑。例如，某人想要把某种职权完全归属于自己。
          • 呈现阶段。一方或各方采取行动，使冲突公开化。例如，某人采取行动行使某种职权，从而与也想要行使该职权的人产生冲突。在呈现阶段，冲突往往又要经过出现、升级、僵持和缓和等阶段。
          • 结束阶段。冲突呈现之后，经过或长或短的时间，得到解决。例如，该职权被明确地归属于某人。
          • 冲突潜伏在背景中，感受于意识中，呈现于言行中，结束于解决时。
      • 9.5.4 冲突解决的基本理论和原则
        • 可用于指导冲突解决的基本理论包括：
          • 利益决定立场理论。立场的冲突往往源自利益的冲突，所以要重点关注利益而不是立场。
          • 需求满足理论。冲突可能源自需求未得到满足，所以要设法使相应的需求得到满足。
          • 冲突转化理论。要设法把破坏性冲突转化为建设性冲突。
        • 可用于指导冲突解决的基本原则包括：
          • 开诚布公。冲突双方开诚布公地讨论冲突事项。
          • 对事不对人。用对事不对人的态度对待冲突。
          • 着眼于团队和项目。以最有利于团队和项目的方式解决冲突。
          • 着眼于现在和未来。从过去的阴影中摆脱出来，寻找有利于现在和未来的解决方法。
          • 当事人自己解决。冲突最好由当事人自己尽早解决，他们的直接上级可以协助。
        • 对一方违反职业道德或法律而引起的冲突，另一方必须向有关机构报告，而不能由当事人自己解决。
      • 9.5.5 解决冲突的基本方法
        • 在冲突发展的潜伏阶段和感知阶段，重点是预防冲突。在冲突发展进入感受阶段特别是呈现阶段以后，则重在解决冲突。可以用如下六种常用的方法去解决冲突：
          • 合作或解决问题。这是“双赢”的方法。
          • 面对（Confrontation）。摆在台面谈。
          • 合作是取两个现有方案的优点，形成新方案；面对是选择一个现有的方案，放弃另一个现有的方案。
          • 妥协或调解。各让一步。所以可看作“双输”，但并非不好的解决方法。
          • 缓和或包容。“求同存异”。是“双赢”的方法（但只是部分解决冲突）。
          • 撤退或回避。如把问题留到以后去解决，是“双输”的方法。
          • 强制或命令。一方强制另一方，这是最坏的解决方法，是“赢-输”的方法。
        • 西方文化鼓励“把问题摆到桌面上”——工作中的问题都应该摆到桌面上。PMP®考试要按这个观点来答题。
    • 9.6 团队工作分配与成员激励
      • 9.6.1 狭义与广义的项目团队
        • 项目经理是受项目执行组织委派，领导项目团队去实现项目目标的个人。
        • “项目团队”这个词有狭义与广义之分。
          • 狭义的项目团队，仅指一线的工作团队，从事具体的项目活动，完成相应的工作包；或者仅指项目管理团队。项目管理团队是项目团队中直接从事项目管理工作的成员的集合。项目经理是项目管理团队的一员。
          • 中观层面的项目团队，是包括项目管理团队和一线工作团队在内的。
          • 广义的项目团队，则包括项目管理团队、一线工作团队以及其他主要项目相关方。
          • 碰到“项目团队”这个词时，必须根据上下文判断其外延。如无法判断，则理解成中观层面的项目团队。
        • 项目经理、项目管理团队和一线工作团队按如下顺序出场：
          • 在项目启动阶段，项目发起人指定项目经理，项目经理正式出场。
          • 在规划阶段开始时，项目经理组建项目管理团队编制项目计划，项目管理团队正式出场。
          • 在执行阶段开始时，项目经理组建一线工作团队，一线工作团队正式出场。
      • 9.6.2 责任分配矩阵
        • 项目管理中，经常使用责任分配矩阵来分配工作任务，把各WBS要素或进度活动分配给相应的小组或个人负责。
        • 《PMBOK®指南》中列举了以RACI形式呈现的责任分配矩阵。其中：
          • R代表职责（Responsible），是执行某项工作的责任。对某项工作，可以有两个甚至更多的R。
          • A代表终责（Accountable），是对某项工作负有最终责任。对某项工作，只能出现一个A，作为该工作的唯一责任点。
          • C代表咨询（Consulting），是应该对某项工作提出意见。对某项工作，通常有多个C。
          • I代表知情（Informing），是应该了解某项工作的情况。对某项工作，通常有多个I。
        • 作为组织专家做事的人，项目经理必须善于授权。关于授权，需要注意：
          • 按团队成员的能力优势进行授权，决定授权种类和级别。
          • 按结果而非过程进行授权，即明确要求该取得的成果，而把工作过程留给被授权者掌控。
          • 授权不能消除或减轻自己对被授权工作的终责。
          • 不能把项目整合管理的工作授权出去。
          • 不能把自己不想做的事授权给下级去做。
          • 不能把颁发奖励或实施惩戒的工作授权给助手去做。
          • 把工作授权给下级去做，只是向下级转移了执行的责任，而无法转移对工作的终责。
      • 9.6.3 激励理论
        • 激励理论也是PMP®考试中的重要内容之一。激励是指因为某个行为能够满足个人的某种需要而促使一个人去从事这种行为。
        • 管理学中有多种激励理论，例如：
          • 马斯洛的需求层次理论（Maslow's Hierarchy of Needs）。
            • 人有五个层次的需求：
              • 生理需求（食物、水、空气、衣服等）
              • 安全需求（安全、稳定、免受伤害）
              • 社会需求（友爱、归属、朋友）
              • 尊重需求（成就、受到尊敬、引起别人注意）
              • 自我实现需求（学习、发展）
            • 通常，人们只有在较低层次的需求得到满足后，才会追求较高层次的需求。
            • 激励与个人的需求有关，而且只有尚未满足的需求才能起到激励的作用。
          • 麦格雷戈的X理论和Y理论（McGregor's Theory X andTheory Y）。
            • X理论认为人是消极懒惰的，设法逃避工作，缺乏进取心，总是逃避责任。
            • Y理论则相反，认为人是积极的，愿意工作，愿意进步，愿意承担责任等。
            • 传统的管理比较偏向于X理论，现代管理越来越偏向于Y理论。
          • 赫兹伯格的双因素理论（Herzberg's Theory ofMotivation）。
            • 该理论认为有两类因素会决定人的行为，即保健因素和激励因素。
              • 保健因素导致不满足感，做得不好就会损害激励，做得好却不会提高激励，如工作条件、工资、同事之间的关系、安全、职位等，相当于马斯洛的需求层次理论的较低层次的需求（生理和安全）；
              • 激励因素是导致满足感的因素，是能够真正起激励作用的，如责任、自我实现、职业发展、得到承认等，相当于马斯洛的需求层次理论的较高层次需求（尊重和自我发展）。
          • 弗鲁姆的期望理论（Vroom's Expectancy Theory）。
            • 一种行为倾向的强度取决于个人对于这种行为可能带来的结果的期望度，以及这种结果对个人的吸引力。如果一个人认为努力工作会带来成功的结果，而这种成功又会带来相应的回报，他就会受到激励而努力工作。
          • 麦克利兰的成就动机理论（McClelland's AchievementMotivation Theory），又称“三种需要理论”。
            • 该理论认为各人在不同程度上有三种需要：成就需要、权力需要和亲和需要。管理者应该根据各人更重视的需要来制定激励措施。例如，为成就需要者设立具有挑战性但可实现的目标，为权力需要者提供较能体现地位的工作环境，为亲和需要者提供合作而非竞争的工作环境。
      • 9.6.4 其他重要概念
        • 资源直方图。用来表示每个时间段（如周、月）所需资源数量的柱状图。柱子的高度代表所需资源的数量。可以用一条横线表示可用的最大资源数量。如果柱子超出横线，就是资源短缺。
        • 资源横道图。在横道图的每条横道上面或旁边，添加从事活动的人员的姓名。
        • 边际福利（Fringe Benefit）。所有员工都可享受的福利，如基础培训、失业保险、养老保险、医疗保险等，与员工的业绩好坏没有直接关系。它用来保障员工的经济安全性，使他们无后顾之忧，属于保健因素。
        • 光环效应（Halo Effect）。因为一个人在某个方面表现好，人们就理所当然地认为他在其他方面也会表现好。例如，不进行综合评价，就简单地指定一个优秀的技术专家当项目经理，很可能就是光环效应的表现。要注意防止光环效应。
        • 额外待遇（Perquisites）。给某些员工特殊奖励，如固定的停车位、靠窗的办公室、与总经理一起吃饭等。它主要用来奖励优秀员工，属于激励因素。
    • 9.7 《PMP考试大纲》中的人员管理
      • PMP®考试大纲》中的人员管理内容都可以归并到《PMBOK®指南》中的规划资源管理、估算活动资源、获取资源、建设团队和管理团队过程中。
        • 在规划资源管理过程中
          • 设定清晰的团队愿景和使命；
          • 根据组织原则确定团队基本规则、所需的成员胜任力和成员培训、考核团队绩效的关键绩效指标和向成员反馈考核结果的方法。
          • 这些内容都应该写入团队章程。
        • 在获取资源过程中
          • 从相关方获取所需的人力资源（团队成员），分析和了解团队成员（例如，用性格指数去了解成员的个性，分析虚拟团队成员对沟通时间和方式等的需求）；
          • 根据团队成员的优势来组建团队和分配工作任务（例如，让最擅长者充当特定工作的终责人，根据成员能力来确定工作授权级别）；
          • 与团队成员协商达成工作协议，确定所需的具体培训方案。
          • 对于虚拟团队，还要确定虚拟团队成员的具体工作方式。
        • 在建设团队过程中
          • 建立和维护团队共识，创建和维护团队氛围，赋能团队成员（包括使成员有权做决策和有能力做工作）；
          • 采用合适的领导风格（如仆人型风格）和高级的情商并根据团队成员的特性（如性格）去启发、激励和影响团队成员；
          • 支持团队的多样性和包容性，支持和认可团队成员的成长，支持团队成员履行工作职责和承担工作终责；
          • 开展所需培训、教练和辅导；
          • 支持成员之间的知识分享，发现和排除妨碍团队的困难和障碍，支持团队成员遵守基本规则。
          • 对于虚拟团队，则还要采取措施支持虚拟团队成员参与项目。
        • 在管理团队的过程中
          • 分析冲突的背景、原因和阶段，采用适当方法解决冲突；
          • 考核团队绩效并向成员反馈考核结果；
          • 持续评估工作终责的落实情况，分析团队绩效的改进情况，考核培训、教练和辅导的效果；
          • 持续评估团队成员的技能并提出改进建议，持续评估妨碍团队的困难和障碍的排除情况，持续评估与成员的工作协议的落实情况；
          • 发现、分析和解决成员之间的误解，发现和纠正违反基本规则的言行。
          • 对于虚拟团队，则还要持续评估虚拟团队成员参与的有效性。
  • 第10章 项目沟通管理
    • 10.1 概述
      • 10.1.1 项目沟通管理的本质
        • 项目沟通管理是要确保及时正确地产生、收集、发布、存储和最终利用项目信息。沟通是项目信息的产生、收集和利用的过程。
          • 首先，基于相关方的信息需求、项目本身的需求、可用的组织过程资产，以及相关的事业环境因素，制定项目沟通策略（关于沟通的原则性规定）；
          • 其次，制订沟通管理计划，规定用于实现沟通策略的沟通工件和沟通活动；
            • 沟通工件是由人工编制或机器生成的任何类型的信息载体，如绩效报告、电子邮件。
            • 沟通活动则是用于传递信息载体的任何活动，如发送绩效报告或电子邮件。
          • 再次，生成所需的沟通工件，开展所需的沟通活动；
          • 最后，监控沟通工件和沟通活动的绩效。
        • 需要遵循5C原则：
          • 目的明确（Clear Purpose）。基于自己和对方的需求，确定明确的沟通目的。
          • 表达正确（Correct Expression）。用词正确，语法正确，方式和方法正确。
          • 表达简洁（Concise Expression）。使用尽可能简单的词语和句子。
          • 逻辑连贯（Coherent Logic）。在书面文件中，可以使用标题或小标题明示各部分的逻辑关系。在口头沟通中，可以使用“第一点”“第二点”等来明示各部分的逻辑关系。
          • 思路掌控（Controlling Ideas）。在沟通的最后，用图形、文字或语言总结来概述思路的全貌。
      • 10.1.2 项目经理在沟通中的角色
        • 沟通能力是项目经理最重要的能力，比技术能力更重要。沟通能力也是谈判能力和团队建设能力的基础。
        • 项目经理的大多数时间（甚至高达90%）用于沟通。他要通过沟通来协调，通过协调来整合。
        • 虽然项目经理不能控制全部沟通，但是应该设法管理沟通，以尽量避免不必要的变更、误解、指示不清等。项目经理在沟通中的角色可以是整合者、协调者、促进者、领导者、谈判者、聆听者、解释者和调解者。
        • 项目经理作为项目沟通的核心，应该通过以下措施来促进有效沟通：
          • 充分认识沟通的困难，设法消除沟通障碍。
          • 充当有效的沟通者。
          • 使用紧密式矩阵。
          • 建立作战指挥部（War Room）。
          • 建立、维护和利用各种项目信息发布制度。
          • 采取各种措施提高自己及团队其他成员的沟通技巧。
          • 提高会议的效率和效果。
      • 10.1.3 沟通的种类
        • 正式沟通与非正式沟通。
          • 正式沟通是组织规章制度中明确规定的强制性的沟通，是必须做的。
          • 非正式沟通则是规章制度中未明确规定的，而是由团队成员自由选择的，是可做可不做的。
        • 官方沟通与非官方沟通。
          • 官方沟通是作为组织的正式意见而发布的信息，非官方沟通则不是组织的正式意见。
          • 官方沟通肯定是正式沟通，但正式沟通不一定就是官方沟通；
          • 非正式沟通肯定是非官方沟通，但非官方沟通不一定就是非正式沟通。
          • 有些正式沟通可能不是官方沟通。
        • 内部沟通与外部沟通。
          • 内部沟通是项目团队内部的沟通。
          • 外部沟通是项目团队与外部相关方的沟通。
          • 内部或外部是针对项目层面而言的。
        • 纵向沟通与横向沟通。
          • 纵向沟通是不同级别的人之间的沟通。横向沟通是同一级别的人之间的沟通。
          • 一般情况下，纵向沟通中的信息损耗比横向沟通更加严重。
          • 在纵向沟通中，上级应尽力把自己放在与下级平等的位置上，来减少损耗。
        • 口头沟通与书面沟通。
          • 口头沟通是以口头语言进行的沟通。
          • 书面沟通是以书面形式进行的沟通。
        • 口头语言沟通与非口头语言沟通。
          • 口头语言沟通包括讲话的内容、语音语调、声音大小等。
          • 非口头语言沟通则是以形体语言或外在器物（如信号旗）进行的。
        • 在考试中，可能有题目要求根据某个情景选择最合适的沟通方式。
        • 人与人之间的许多问题都是沟通不充分或沟通中的误解引起的。所以，与别人发生矛盾后，应该首先检查一下沟通有没有问题。
    • 10.2 各过程的输入与输出
      • 10.2.1 输入与输出的关系总览
        • 项目沟通管理的实现过程包括规划沟通管理、管理沟通和监督沟通。
      • 10.2.2 规划沟通管理
        • 在项目章程的指导下，根据项目管理计划中已有的相关内容，以及相关的项目文件，编制沟通管理计划。
        • 通常，项目章程中会列出一些最重要的相关方及其角色和职责。这些信息有利于明确该如何与他们沟通。
        • 资源管理计划（项目管理计划的组成部分）中与人力资源有关的部分，有利于规划项目团队内部的沟通。相关方参与计划（项目管理计划的组成部分）则有利于规划该如何与相关方沟通，才能引导相关方合理参与项目。
        • 作为一种项目文件，需求文件中可能包括相关方的重大沟通需求。相关方登记册则是确定该与哪些相关方沟通的依据。
      • 10.2.3 管理沟通
        • 根据项目管理计划中的沟通管理计划实实在在地开展沟通，得到项目沟通记录。
        • 应该在管理沟通过程中把工作绩效报告发送给项目相关方。应该在管理沟通过程中把各种项目文件发送给项目相关方，如质量报告、风险报告。
        • 重复开展沟通时，需要借鉴已记录在经验教训登记册（一种项目文件）中的与沟通有关的经验教训。
      • 10.2.4 监督沟通
        • 应该把体现在项目沟通记录和问题日志（都是项目文件），以及工作绩效数据中的沟通实际情况，与沟通管理计划、资源管理计划和相关方参与计划（都是项目管理计划的组成部分）中的沟通要求相比较，发现、记录并分析沟通绩效的偏差，形成工作绩效信息。如果偏差不可接受，就提出变更请求。
        • 问题日志不仅会记录与相关方沟通中出现的问题，而且有利于从发生的问题去反思沟通的效率和效果。许多问题都是沟通不合理引起的。
        • 资源管理计划有利于考察沟通是否促进了对资源的有效协调和管理。相关方参与计划有利于考察沟通是否起到了引导相关方合理参与项目的作用。
    • 10.3 各过程的主要工作和成果
      • 10.3.1 规划沟通管理
        • 规划沟通管理过程旨在了解项目相关方的信息需求、项目本身的需求，以及组织过程资产和事业环境因素，编制沟通管理计划。沟通管理计划也就是沟通计划，包括三大主体内容：
          • 关于沟通管理的程序性规定。
          • 关于将要生成的沟通工件的规定。
          • 关于沟通活动的规定。
        • 编制沟通管理计划，是非常重要的一项工作。
          • 一方面，在新成立的项目团队中，团队成员可能从未在一起工作过，项目团队与项目相关方也可能从未合作过。不熟悉的人，不可能自然地了解彼此的沟通需求，如对方需要什么信息、喜欢什么沟通方式等。
          • 另一方面，项目管理有非常明确且具有挑战性的目标，即通过许多人的合作，在规定的限制条件下完成项目任务。无效沟通会严重妨碍目标的实现。这两个方面决定了编制沟通管理计划的重要性。
          • 编制沟通管理计划的过程，本身也是项目管理团队与主要项目相关方密切沟通的过程。
        • 沟通管理计划中应该包括：
          • 需要收集什么信息
          • 在什么时候收集
          • 以什么方式收集
          • 什么时候、以什么方式、向谁发送什么信息
          • 主要项目相关方的联系方式
          • 对于关键术语的定义
          • 如何更新沟通管理计划
        • 信息既需要向项目内部的相关方（如团队成员）发布，也需要向项目外部的相关方（如政府部门、用户、媒体）发布。
        • 项目沟通管理应该贯穿于项目的整个生命周期。沟通管理计划应该尽早编制并不断审查和更新。
      • 10.3.2 管理沟通
        • 管理沟通过程旨在根据沟通管理计划，生成、收集、发布、存储、利用和最终处置项目信息。
        • 本过程不局限于发布信息，还包括前端的生成和收集信息，以及后端的确认信息发布的有效性。
        • 可以把管理沟通过程解释为实实在在地开展沟通。它得到的成果就是已经开展的、既有效率又有效果的项目沟通。
        • 在管理沟通过程中发布的一些重要信息，会成为组织过程资产的组成部分。
      • 10.3.3 监督沟通
        • 监督沟通过程旨在根据沟通管理计划，监督项目沟通情况，发现、记录和分析沟通工作中的偏差，提出变更请求。
        • 监督沟通过程经常导致重新开展规划沟通管理过程，修改沟通管理计划。
        • 规划沟通管理过程是为了开展有效率和有效果的沟通而编制计划。管理沟通过程是实实在在地开展有效率和有效果的沟通。监督沟通过程则是监控沟通的效率和效果是否达到了计划中的要求。
    • 10.4 各过程的工具与技术
      • 10.4.1 规划沟通管理
        • 本过程的工具与技术可概述为：
          • 在沟通模型的指导下，进行沟通需求分析，并选择适当的沟通技术与沟通方法；
          • 需要召开会议，运用专家判断。人际关系与团队技能及数据表现，都有助于更有效地进行沟通需求分析，选择沟通技术与沟通方法。
          • 沟通模型
            • 沟通模型是由信息发出者、信息、媒介、噪声、信息接收者和反馈意见等诸多要素所组成的一个循环。
            • 在沟通过程中，各种各样的因素会干扰信息的编码、传送、接收和解码。这些因素统称为沟通中的“噪声”。
            • 信息发出者对信息的编码和信息接收者对信息的解码，都会直接影响沟通的质量。
            • 沟通中最重要的不是你发出了什么，而是对方接收和理解了什么。
        • 沟通是需要质量控制的。信息接收者向发出者的及时反馈就是沟通中的质量控制。
        • 即便你暂时无法理解信息的意思，也必须在收到信息后立即告知收悉。
        • 应该认真进行沟通需求分析，弄清楚项目相关方在整个项目生命周期中对信息的需求，包括需要什么信息、什么时候需要、喜欢什么格式、为什么需要等。
        • 沟通网络是指信息流动的通道。有三种常见的网络类型：链式、轮式和全通道式。
          • 链式网络严格遵守正式的命令系统，只有上下级之间的纵向沟通，没有横向沟通。
          • 轮式网络严格以某个领导者为沟通的核心，一切沟通都围绕他进行。
          • 全通道网络则允许全体成员之间进行自由沟通，任何人都可以与任何人沟通。
            • 在PMP®考试中，可能考全通道沟通网络下沟通渠道数量的计算。在全通道网络下，相关方或团队成员之间的沟通渠道数量由以下公式计算：
              • 沟通渠道数量=N（N−1）/ 2。其中，N为相关方或团队成员的人数。
              • 例如，一个团队由5个人组成，则总共有5（5−1）/ 2=10条沟通渠道；
              • 如果在该团队中再增加3个人，则沟通渠道会增加18条。
              • 考试时，一定要仔细看清楚，是问你沟通渠道总共有多少条，还是增加或减少了多少条。
        • 在规划沟通管理过程中，需要根据项目的具体情况以及相关方的具体情况，为拟开展的沟通选择合适的沟通技术。被选定的沟通技术，需要写入沟通管理计划。可以按下列规则做出选择：
          • 正式书面沟通。适用于复杂、重要的事情，如发布项目章程、合同。
          • 正式口头沟通。适用于需要立即得到反馈的重要事情，如合同谈判。
          • 非正式书面沟通。适用于需要在以后查询但不太重要的事情，如用备忘录通知项目周报的提交时间从原来的周一中午12点改为周一上午10点。
          • 非正式口头沟通。适用于既不重要也无须在以后查询的事情，如私下谈话。
        • 在口头沟通中，最重要的信息传递途径并不是口头（verbal）语言（包括内容、声音大小、语音语调），而是非口头（nonverbal）语言（形体语言，如面部表情、身体之间的距离等）。
        • 在规划沟通管理过程中，需要根据项目以及相关方的具体情况选择合适的沟通方法，用于将来的沟通。被选定的沟通方法需要写入沟通管理计划。主要有以下三种沟通方法：
          • 交互式沟通。沟通双方或多方多方位地交流信息。适用条件：要沟通的信息不多，要沟通的对象不多，且需要立即获得反馈甚至达成协议。例如，开会、打电话、网络在线即时沟通。
          • 推式沟通。把信息推送给信息接收者。信息接收者处于他们的本来位置不变。适用条件（暂且不考虑电子信息推送）：信息有明确的受众，要沟通的信息和对象不多，而且无须立即得到反馈。例如，给项目相关方发送绩效报告，给别人发短信。
          • 拉式沟通。把信息放在一个固定的位置，把项目相关方拉到这个位置查看信息。适用条件：要沟通的信息很多，或者要沟通的对象不明确或数量很多。例如，张贴公告，建立项目网页。
        • 可以借助数据表现中的相关方参与度评估矩阵，分析为了填补相关方参与项目的程度的不足，需要开展什么沟通，以及该用什么沟通技术和方法。
      • 10.4.2 管理沟通
        • 管理沟通过程就是使用已选定的沟通技术与沟通方法，运用自己的人际关系与团队技能及沟通技能，实实在在地开展沟通。
        • “项目管理信息系统”和“项目报告发布”有实质性交叉；“人际关系与团队技能”与“沟通技能”也有实质性交叉。
        • 主要的人际关系与团队技能包括：
          • 积极倾听（专注听别人说话，并适时提供反馈）
          • 冲突管理（有效预防和解决与别人的冲突）
          • 政治意识（了解政治氛围）
          • 文化意识（了解文化氛围）
          • 会议管理（有效召开会议）
          • 人际交往（建立关系网络，如微信朋友圈）
        • 主要的沟通技能包括：
          • 具有沟通胜任力（针对特定事情或对象的沟通能力）
          • 能够提供反馈、使用非口头技能和进行演示
      • 10.4.3 监督沟通
        • 在监督沟通过程中，应该通过观察和交谈（属于人际关系与团队技能），以及召开会议，来了解沟通的效率和效果；
        • 应该使用相关方参与度评估矩阵（属于数据表现）来分析沟通是否达到了引导相关方合理参与项目的目的。
        • 专家判断和项目管理信息系统也是应该使用的工具。
  • 第11章 项目风险管理
    • 11.1 概述
      • 11.1.1 风险管理的必要性
        • 项目是独特的一次性事业，必然存在风险。
          • 项目经理必须积极主动地开展项目风险管理，而不只是消极被动地去应对已发生的风险。
          • 积极主动，意味着事先就认真预计可能发生的风险，分析这些风险发生的可能性和万一发生的后果，并制定和执行相应的风险应对策略和措施。
        • 项目经理应该知道，项目中的大多数风险（甚至90%的风险）都可以预测和管理。
      • 11.1.2 风险的定义
        • 有两个层面的风险，即整体项目风险、单个项目风险。
          • 整体项目风险是项目的全部不确定性来源可能对项目的综合影响。综合影响既可能是项目目标的正向变异（如提前完工），也可能是项目目标的负向变异（如推迟完工）。
          • 单个项目风险，是一旦发生会对项目目标产生积极或消极影响的不确定性事件。有积极影响的，是机会；有消极影响的，是威胁。
        • 风险既包括威胁，也包括机会。对“风险”这个词，必须根据上下文判断其真实内涵。
        • 整体项目风险是已经识别出来的所有单个项目风险加上未识别出来的全部其他不确定性来源。
        • “风险”这个词，如果前面没有任何修辞语，通常是指单个项目风险，除非上下文另有要求。
        • 风险总是与不确定性联系在一起的，既可能发生，也可能不发生。风险也总是与目标联系在一起的，如果发生，会对项目范围、进度、成本和质量的至少一个方面，有积极或消极影响。
      • 11.1.3 管理整体项目风险和单个项目风险
        • 只有先管理好整体项目风险，管理单个项目风险才会有意义。
        • 在进行项目设计、确定项目范围和其他目标时，必须考虑与此有关的整体项目风险。
        • 整体项目风险的大小，也取决于事业环境因素和组织过程资产。在一个有利或不利的环境中，项目目标发生正向或负向变异的可能性比较大。
        • 只有把整体项目风险控制在可接受的区间内，管理单个项目风险才有意义。
      • 11.1.4 风险的四要素
        • 风险会涉及事件、原因、后果和可能性。这四者合在一起，可称为风险的四要素，即风险是一个什么事件，由什么原因引起，发生后会导致什么后果，发生的可能性有多大。
        • 在上述风险的四要素中，原因又是由风险起因和风险条件联合构成的。风险起因是某个或某些风险得以存在的“土壤”。风险条件则是引发风险事件的“催化剂”。
        • 在上述风险的四要素中，可能性和后果联合决定了风险敞口（Risk Exposure）。如果把可能性和后果都量化，那么这两者的乘积就是风险敞口。风险敞口越大，风险就越严重。
      • 11.1.5 风险类别
        • 可以用不同的标准，把项目风险分成不同的类别，以便有效管理。可以用风险分解结构来展示风险的类别，为进一步识别风险提供基础（出发点）。以下是常见的风险类别。
          • 按专业分类：技术风险、组织风险、管理风险和财务风险。
          • 按内外分类：内部风险和外部风险。
          • 按与经营者的关系分类：经营风险和纯风险。
            • 前者是与经营活动密切相关的风险，发生的可能性和后果与经营者的水平和努力程度有密切关系，如市场风险，通常不能买保险；
            • 后者则是与经营者的水平和努力程度完全无关的意外事件，如自然灾害，通常可以买保险。
            • 当然，两者之间的界限并非十分明确。
          • 按已知程度分类：已知风险和未知风险。已知风险又可分为已知已知风险和已知未知风险。未知风险则是未知未知风险。
            • 已知已知风险是已经识别出并分析过的风险，人们不仅知道它们是什么风险，而且知道它们发生的可能性和后果。对已知已知风险可能造成的损失，在编制项目成本预算时，通常按计算出的风险敞口计入受影响的项目工作的直接成本。
            • 已知未知风险是已经识别出但其发生的可能性或后果还不清楚的风险，通常在项目预算和进度计划中列出一定的应急储备（包括应急资金和时间）来应对。
            • 未知风险，也叫未知未知风险，是过去从未遇到过的、完全未知的风险。未知风险，也叫突发风险（Emergent Risk），是只有实际发生后才会知道的风险。例如，第一例非典型肺炎发生前，“非典”就属于未知风险。
            • 未知未知风险通常无法预防，只能通过提高项目韧性（抵抗未知未知风险的能力）来减轻万一发生的后果。提高项目韧性的办法包括：在预算中预留充足的管理储备，采用能够灵活变通的项目管理过程，赋予项目团队灵活应变的权力和能力，在项目范围中留出应变的余地。
            • 在编制项目预算时，应该把已知已知风险可能造成的损失直接列入项目“直接成本”，把已知未知风险可能造成的损失列入“应急储备”，把未知未知风险可能造成的损失列入“管理储备”。
      • 11.1.6 风险态度、偏好、承受力和临界值
        • 风险态度（Risk Attitude）、风险偏好（Risk Appetite）、风险承受力（Risk Tolerance）和风险临界值（RiskThreshold）这四个词，既有联系又有区别。
          • 风险态度是指个人或组织认为自己应该冒多大的风险。如果实际所冒风险未超出应该冒的风险，就觉得很舒服、不紧张。
          • 风险偏好是指为了实现目标（获得利益），个人或组织愿意冒多大的风险。高风险偏好者愿意为获得大利益而冒大风险，低风险偏好者不愿意为了获得利益而冒看似很小的风险。对于不同的风险，个人或组织可能有不同的风险偏好
          • 风险承受力是指个人或组织能够承受的最高风险程度。如果实际风险水平超出风险承受力，个人或组织就会破产。通常，个人或组织愿意冒的风险（风险偏好）应该小于风险承受力。
          • 风险临界值是指个人或组织能够承受的风险程度，而不需要采取应对措施。例如，允许成本超支5%，如果成本超支预计或已经突破5%的临界值，就必须采取预防措施或应急措施。
          • 风险临界值是必须采取措施的起点，风险偏好是愿意冒的风险程度，风险承受力是能够承受的最大风险。通常，风险临界值最低，风险偏好中间，风险承受力最高。
    • 11.2 各过程的输入与输出
      • 11.2.1 输入与输出的关系总览
        • 项目风险管理的实现过程包括规划风险管理、识别风险、实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险。
      • 11.2.2 规划风险管理
        • 在项目章程的指导下，参考项目管理计划中已有的内容，编制风险管理计划。风险管理计划必须与项目管理计划中已有的内容相协调。
        • 项目文件中的相关方登记册，有助于邀请相关方参加风险管理计划的编制，有助于根据相关方的情况（如风险态度）确定本项目的风险管理该如何开展。
      • 11.2.3 识别风险
        • 因为项目的方方面面都存在可能影响项目目标的不确定性事件，所以识别风险过程的输入其实是非常多的。可以说，项目上的任何一种计划或文件，都可以作为识别风险过程的输入。识别出来的风险及其特性，都应该写入风险登记册，并汇编进风险报告。
        • 当然必须根据项目管理计划中的风险管理计划来识别风险。此外，项目管理计划中的其他子计划和项目基准，也都是识别风险的依据。
        • 《PMBOK®指南》列出了作为识别风险过程的输入的下列主要项目文件：
          • 相关方登记册。应该邀请尽可能多的相关方参与风险识别，还可以根据相关方登记册预选风险责任人。
          • 假设日志。所需的假设条件越多，所面临的制约因素越多，单个项目风险就越多，整体项目风险也会越高。
          • 需求文件。各种需求都有实现不了的风险。
          • 成本估算。有助于识别不能在规定的成本内完成项目工作的风险。
          • 持续时间估算。有助于识别不能在规定时间内完成项目工作的风险。
          • 问题日志。虽然问题本身不是风险，但是问题可能引发新的风险。
          • 资源需求。有助于识别与资源需求有关的风险。
          • 经验教训登记册。重复开展本过程时，需要参考以前的经验教训。
        • 对于外包出去的工作，协议和采购文档有助于识别与采购有关的风险。
        • 让尽可能多的相关方参与识别风险，尽可能全面地识别出项目风险。
      • 11.2.4 实施定性风险分析
        • 在风险管理计划（项目管理计划的组成部分）的指导下，对前一个过程得到的风险登记册（一种项目文件）中的所有风险都进行定性分析。在定性分析中，需要分析相关方登记册（一种项目文件）中的哪些人适合作为各种风险的责任人。作为一种项目文件的假设日志，有利于对风险进行定性分析。
      • 11.2.5 实施定量风险分析
        • 在风险管理计划（项目管理计划的组成部分）的指导下，对前一个过程得到的风险登记册（一种项目文件）中的某些风险进行定量分析，然后用这些定量分析的信息、风险登记册中的所有风险的相关信息，以及有关项目不确定性的其他信息，作为输入数据，对整体项目风险进行定量分析。定量分析的结果应该汇编进风险报告。更新后的风险报告属于项目文件更新。
        • 项目管理计划中的范围基准、进度基准和成本基准，有助于定量分析实现这些基准将面临的风险。
        • 《PMBOK®指南》还列出了作为输入的以下项目文件：
          • 风险报告。已有的风险报告，可以为当前开展整体项目风险定量分析提供依据。
          • 假设日志。项目的假设条件和制约因素，都是开展整体项目风险定量分析的依据。
          • 成本估算、持续时间估算、估算依据和资源需求。它们既是对某些单个项目风险进行定量分析的依据，也是对整体项目风险进行定量分析的依据。
          • 里程碑清单、成本预测和进度预测。应该定量分析实现里程碑、成本预测或进度预测的可能性.
      • 11.2.6 规划风险应对
        • 在风险管理计划（项目管理计划的组成部分）的指导下，针对风险登记册和风险报告（都是项目文件）中的风险情况，制定风险应对策略和措施。应对策略和措施，必须与资源管理计划（项目管理计划的组成部分）中用于应对风险的资源相对应，必须与成本基准（项目管理计划的组成部分）中用于风险应对的资金相对应。
        • 《PMBOK®指南》还列出了作为输入的以下项目文件：
          • 相关方登记册。制定应对策略和措施，应该邀请相关方参与，征求相关方的意见。
          • 项目进度计划。有助于把风险应对活动与进度计划中的相关活动协调起来。
          • 项目团队派工单。从中找出谁应该负责哪些风险应对活动。
          • 资源日历。从中了解哪些资源何时可用于风险应对。
          • 经验教训登记册。重复开展本过程时，需要参考过去的经验教训。
      • 11.2.7 实施风险应对
        • 在风险管理计划（项目管理计划的组成部分）的指导下，由风险责任人负责执行风险登记册（一种项目文件）中的单个项目风险应对策略和措施，由项目经理负责执行风险报告（一种项目文件）中的整体项目风险应对策略和措施。
      • 11.2.8 监督风险
        • 在风险管理计划（项目管理计划的组成部分）的指导下，由风险责任人监督已写入风险登记册（一种项目文件）的单个项目风险的应对策略和措施的实施情况，由项目经理监督已写入风险报告（一种项目文件）的整体项目风险的应对策略和措施的实施情况。作为一种项目文件的问题日志，有助于监督可能引发风险的各种问题的解决情况。
        • 单个项目风险的实际发生情况与预计发生情况的偏离，需要作为工作绩效信息加以记录。
        • 在监督风险过程中所产生的信息需要写入风险登记册和风险报告。更新后的风险登记册和风险报告都属于项目文件更新。
        • 后六个过程的最主要的输入是项目管理计划中的风险管理计划，以及前一个过程所得到的风险登记册和风险报告；最主要的输出则是完整程度不等的风险登记册和风险报告。
        • 需要根据监督发现的情况，提出必要的变更请求，如要求修改风险管理计划。
        • 因为存在两个层面的风险，即整体项目风险和单个项目风险，所以每个风险管理过程其实都可以分成两个不同层面的，即整体项目风险层面的和单个项目风险层面的。这两个层面的风险管理过程，既有联系又有区别。
    • 11.3 各过程的主要工作和成果
      • 11.3.1 规划风险管理
        • 本过程旨在对将来的风险管理工作做出安排，包括如何识别风险、如何进行风险分析、如何制定应对策略和措施、如何实施风险应对计划以及如何监控风险。本项目的风险管理将要怎么做、做到什么程度？将要采取什么风险管理做法，不仅取决于项目的复杂程度及规模大小，而且取决于主要相关方的需要。规划风险管理过程，应该邀请尽可能多的相关方参加。
        • 各主要项目相关方都要参与风险管理计划的编制工作。
        • 各主要项目相关方都要参与风险管理计划的编制工作。风险管理计划应该包括如下主要内容：
          • 风险管理策略。这是关于本项目的风险管理工作的原则性安排。
          • 方法论。为实现原则性安排，将采用的风险管理过程、数据资料，以及工具与技术。
          • 角色和职责安排。将设立什么风险管理的岗位，各岗位的权责和能力要求。
          • 预算和时间安排。将花多少钱和时间做风险管理（需要加到预算和进度计划中），将如何确定、使用和调整项目的应急储备。
          • 风险类别。用风险分解结构把大类别风险分解成小类别风险，作为识别风险的出发点。
          • 主要相关方的风险偏好。主要相关方对于不同的项目目标或项目风险，究竟是风险冒险者、中立者还是规避者？
          • 风险概率和影响定义。规定表示风险发生的可能性和后果的方法。例如，数字量表（0.1，0.2，0.3…）、相对量表（几乎不发生、很不可能、不可能、可能、很可能、几乎肯定发生）。同时，还要规定可能性多高才算是很高、高、低或很低，后果严重到什么程度才算是很严重、严重、一般、轻或很轻。
          • 概率和影响矩阵。根据风险敞口（可能性与后果的乘积）对风险进行分级的表格，也叫风险级别矩阵。例如，把风险分成严重、中等、轻微三个级别。相当于用来度量每个风险的严重性的统一尺子。
          • 报告格式。将来要编制的风险管理报告的格式、内容和报送时间等。
          • 风险管理跟踪。将如何记录和审查风险管理工作的开展情况。
      • 11.3.2 识别风险
        • 本过程旨在对将来的风险管理工作做出安排，包括如何识别风险、如何进行风险分析、如何制定应对策略和措施、如何实施风险应对计划以及如何监控风险。本过程要回答的问题是：
          • 本项目的风险管理将要怎么做、做到什么程度？
          • 将要采取什么风险管理做法，不仅取决于项目的复杂程度及规模大小，而且取决于主要相关方的需要。
          • 规划风险管理过程，应该邀请尽可能多的相关方参加。
        • 识别整体项目风险的来源，主要在项目启动阶段开展，而在规划和执行阶段只需要注意整体项目风险的来源的变化情况。整体项目风险的情况应该写入风险报告。
          • 识别单个项目风险，主要在项目规划阶段开展，也需要在项目的其他阶段开展。
          • 识别风险其实是一个须反复开展的过程，贯穿项目生命周期的始终。
        • 通常，风险登记册仅供项目团队内部使用，而风险报告则应该报送给主要相关方。
        • 作为识别风险过程的输出，初始的风险登记册中应该包括：
          • 风险编号。每个风险都有独一无二的编号。
          • 风险名称。每个风险都有独特的名称。
          • 风险描述。尽可能详细地描述风险。
          • 预选的风险责任人。供实施定性风险分析过程确认。
          • 初步应对措施。只是凭直觉得出的，还要在规划风险应对过程中加以分析和确认。
      • 11.3.3 实施定性风险分析
        • 本过程是对所有已识别的单个项目风险进行主观定性分析，评估其可能性、后果和其他情况，并据此进行风险排序，决定哪些风险需要进一步定量分析，哪些风险可直接进行风险应对规划，哪些只需要列入观察清单。其他情况包括风险的可监测性、紧迫性等可能影响风险排序的各种风险参数。
        • 即便使用一些数字，只要是主观的分析，仍然是定性分析。所以，从严格意义上讲，不能以是否用到数字来判断是定量还是定性分析。
        • 定性风险分析的目的是：
          • 以主观的方式评价已识别风险发生的可能性、后果和其他情况。
          • 得到基于定性分析结果的风险排序。
          • 为每个单个项目风险指定风险责任人。·确定哪些风险需要进一步定量分析，哪些风险可直接进入规划风险应对过程，哪些风险可直接列入观察清单。
          • 对风险进行归类，指出高风险的项目领域。
          • 了解风险发展趋势。多次定性分析后，可看出风险发展趋势，如发生可能性是逐渐提高的还是降低的。
        • 每个单个项目风险的责任人，在识别风险过程中预选，在定性分析过程中正式指定。
        • 定性分析的上述结果都要记入风险登记册，导致风险登记册更新；同时，在风险报告中概述上述分析结果，导致风险报告更新。
        • 在项目正式启动之前，需要对整体项目风险做定性分析，以便决定项目能否启动。在规划和执行阶段，要重新对整体项目风险做定性分析，决定项目是否需要变更或提前终止。如果整体项目风险太严重且无法减轻，就不得不提前终止项目。
      • 11.3.4 实施定量风险分析
        • 本过程需要做两件事。
          • 一是对被定性分析确认为严重且可量化的单个项目风险做客观的定量分析；
          • 二是以这些定量分析的结果和全部其他不确定性的情况作为输入数据，对整体项目风险进行定量分析，并据此确定整个项目所需的应急储备。
        • 定量风险分析并不是简单的算术计算，而是需要建立比较复杂的数学模型的。
        • 对所有项目以及已识别的全部单个项目风险，都要进行定性分析，但不是都要进行定量分析的。
        • 定量分析的结果要记入风险报告。定量分析的结果主要包括：
          • 单个项目风险的量化排序。
            • 通常是敏感性分析的结果。可用龙卷风图从大到小依次列出对项目目标有不同程度影响的单个项目风险，及其量化的影响程度。
          • 整体项目风险的情况。主要包括：
            • ①导致整体项目风险的主要因素；
            • ②项目进度和成本的概率分布（一端是最短工期或最低成本及其几乎为0的概率，另一端是最长工期或最高成本及其几乎为1的概率）；
            • ③在特定的时间和成本之内完成项目的概率；
            • ④整个项目需要预留多少应急储备，以便把项目按期按预算完工的概率提升到所需的水平。
          • 风险的发展趋势。
            • 多次定量分析后，可以看出一些单个项目风险的发展趋势，以及整体项目风险的发展趋势。
          • 风险应对建议。
            • 用于定量分析的模型，通常能够自动提出针对单个项目风险或整体项目风险的一些应对建议。
        • 实施定性风险分析过程的落脚点是单个项目风险，实施定量风险分析的落脚点则是整体项目风险。
      • 11.3.5 规划风险应对
        • 本过程旨在根据定性与定量分析的结果，考虑项目相关方的风险态度、风险偏好、风险承受力和风险临界值，制定整体项目风险的应对策略和措施，以及单个项目风险的应对策略和措施。单个项目风险的应对措施，既包括风险发生之前的预防措施或促进措施，也包括风险发生之后的应急措施或利用措施。
        • 开展本过程，通常会导致需要重新开展识别风险、实施定性风险分析、实施定量风险分析等过程。
        • 开展本过程，通常也会导致重新开展其他知识领域中的规划过程，即回头调整项目计划。
          • 一是因为原先对风险的考虑不尽合理。
          • 二是因为需要把风险应对活动及其所需的时间和成本等添加到项目计划中。
        • 规划风险应对过程的结果，需要写入风险登记册和风险报告，从而导致对这两份项目文件的更新。
          • 风险登记册更新的主要内容包括：
            • 商定的单个项目风险应对策略及措施。主要项目相关方应就应对策略和措施达成一致意见。
            • 采取应对措施所需要的时间、成本和其他资源。
            • 风险触发因素。也叫风险警告信号或风险症状。出现某种因素、信号或症状时，预示着某个风险即将发生，或者显示某个风险正在或已经发生。
            • 针对高优先级且有强烈预警信号的风险的应急预案（计划）。
            • 与应急预案配套的弹回计划。这是备用的应急预案（计划），以便在主应急预案（计划）不起作用时采用。
            • 次生风险。应对某个风险而带来的另一个风险。如果不应对原生风险，次生风险本来不存在。需要防止次生风险比原生风险更严重。
            • 残余风险。采取风险应对措施后仍然存在的风险，是没有主动应对或应对后所剩余的风险。例如，购买保险（风险应对）后，保险公司的免赔额（万一风险发生，你仍要承担这个损失）。
          • 风险报告更新的主要内容包括：
            • 针对整体项目风险的应对策略和措施，以及它们对整体项目风险的预期效果。
            • 针对高优先级单个项目风险的应对措施概述。
        • 应该定期或不定期对风险应对策略和措施进行审查和更新，以确保有效性。
      • 11.3.6 实施风险应对
        • 在本过程中，单个项目风险的责任人必须根据规划风险应对过程的结果，组织所需的资源，去实施风险应对策略和措施，以便提高机会，减轻威胁。
        • 在本过程中，项目经理作为整体项目风险的责任人，必须根据规划风险应对过程的结果，组织所需的资源，采取已商定的应对策略和措施处理整体项目风险，使整体项目风险保持在合理水平。
        • 单个项目风险的应对策略和措施的实施情况，应该记入风险登记册；整体项目风险的应对策略和措施的实施情况，应该记入风险报告。
      • 11.3.7 监督风险
        • 在本过程中，监督整体项目风险和单个项目风险的应对策略和措施的实施情况，跟踪整体项目风险和已识别的单个项目风险的变化，监测残余风险，识别和分析新风险，并评价风险管理的有效性，提出变更请求。
        • 本过程的主要工作包括：
          • 注意风险触发因素。是否出现了某种风险预警信号？
          • 追踪已识别的单个项目风险，包括应对情况。例如，发生的可能性和后果是否已经发生变化？
          • 监测与已识别的单个项目风险有关的残余风险和次生风险。
          • 附带地识别和分析一些新的单个项目风险。
          • 监督整体项目风险的应对情况。整体项目风险是变大了还是变小了？
          • 开展风险审计，评估风险管理工作的有效性。
          • 与项目相关方沟通项目风险情况。
          • 必要时提出变更请求，以便制定新的应对措施，甚至新的应对策略。
          • 收集风险资料，更新风险登记册、风险报告和组织过程资产。
        • 风险登记册和风险报告的内容都要通过各个风险管理过程来不断更新和逐渐完善。
        • 作为消极风险的威胁一旦发生，就成了“问题”；作为积极风险的机会一旦出现，就成了“利益”。对问题或利益，要及时发现，并与项目相关方密切合作，进行处置或利用。
    • 11.4 各过程的工具与技术
      • 11.4.1 规划风险管理
        • 借助数据分析、会议和专家判断，编制风险管理计划。数据分析中的相关方分析，有助于分析相关方的风险态度、偏好、临界值和承受力；也可以借助数据分析技术来分析项目失败的风险敞口。这些因素都对本项目的风险管理应该怎么做有直接影响。应该邀请主要相关方，召开风险管理规划会议，讨论项目的风险管理应该做到什么程度。
      • 11.4.2 识别风险
        • 包括头脑风暴、核对单和访谈在内的各种数据收集技术，都是识别风险时常用的技术。
          • 头脑风暴用于召集许多人通过集思广益来识别尽可能多的风险。
          • 过去项目积累下来或行业中标准化的核对单，用于判断核对单所列的各种风险在本项目上是否也存在。也可以分析核对单本身的不完整性，识别出因此而导致的风险。
          • 可以对相关人员进行访谈，识别出一些风险。
        • 包括文件分析、根本原因分析、SWOT分析、假设条件和制约因素分析等在内的数据分析技术，也是识别风险时常用的技术。
        • 无论使用数据收集还是数据分析技术，都应该借助会议、人际关系与团队技能和专家判断。
        • 提示清单则为识别风险提供出发点。
        • 应该尽可能用多种多样的方法去识别风险，并邀请众多相关方参与风险识别。
      • 11.4.3 实施定性风险分析
        • 除了专家判断、会议和人际关系与团队技能中的引导技术，其他的工具与技术，可以按下列顺序使用：
          • （1）使用数据收集中的访谈，去收集相关的风险数据。
          • （2）使用数据分析中的风险数据质量评估，来评估风险数据的质量，确保只有质量可靠的数据才用于定性分析。
          • （3）基于风险数据，使用数据分析中的风险概率和影响评估、其他风险参数评估，来评估风险发生的概率、影响和其他参数（如紧迫性、可监测性）。
          • （4）综合（3）的结果，使用数据表现中的概率和影响矩阵或层级图，对每个风险进行分级。
          • （5）按共同原因、项目部位或时间段，对各种风险进行风险分类，发现高风险的项目领域，以便更有针对性地管理项目风险。
          • 虽然概率和影响矩阵通常是由数字构成的，却是实施定性风险分析过程的工具。
      • 11.4.4 实施定量风险分析
        • 除了专家判断和人际关系与团队技能中的引导技术，其他的工具与技术可以按下列顺序使用：
          • （1）使用数据收集中的访谈，收集专家们的量化数据。
          • （2）结合访谈收集的数据和其他来源的数据，使用不确定性表现方式来生成各种适用的概率分布图。
            • 概率分布图能够展示各活动的可能工期或成本的分布情况，作为后续定量分析的基础。
            • 常用的概率分布图包括贝塔分布、三角分布、均匀分布和正态分布。
          • （3）使用数据分析中的影响图、模拟、敏感性分析和决策树分析，进行风险定量分析，得出分析结果。
        • 可以借助影响图建立与风险有关的情景，找出具有不确定性的各种因素，再用模拟或敏感性分析来分析哪些因素对项目有最显著的影响。
        • 最常用的模拟技术是蒙特卡洛模拟，即在计算机上模拟项目实施成千上万次，看看有多少次是在多少天或多少成本之内完工的。
        • 敏感性分析用来确定某一变量的单位变化对项目的影响程度。
        • 决策树分析是计算各种备选方案的预期货币价值。决策树分析是为了对将来的事情做出决策。决策树同级分支的概率之和必须等于1。
        • PMP®考试中可能考到决策树方面的计算题，所以必须彻底掌握《PMBOK®指南》中图11-15的内容。
      • 11.4.5 规划风险应对
        • 下面对除专家判断以外的工具与技术进行解释。
          • 通过数据收集技术中的访谈，了解各主要相关方对风险应对策略和措施的喜好。
          • 通过人际关系与团队技能中的引导，引导相关方对应对策略和措施达成一致意见。
          • 通过数据分析中的备选方案分析，分析多种备选的应对策略和措施。开展备选方案分析时，需要进行成本效益分析，以选择效益成本比最高的策略和措施。
          • 决策技术中的多标准决策分析，也是用来做备选方案分析的一种具体技术，即从多种标准入手对多个方案进行排序，以选择排序靠前的方案。
        • 针对威胁，可以采取五种应对策略：
          • 上报。对于应该在更高的项目集、项目组合或整个组织层面来处理的风险，项目经理应该采取上报策略。
          • 规避。通过消灭原因来消除风险，如取消高风险的工作；或者，把项目与某个风险隔离开来，如抢在雨季到来之前完成项目，使项目不受雨季的影响。采取规避策略，通常要改变项目计划。
          • 减轻。设法降低风险发生的概率或（和）后果。例如，使用成熟技术和熟练工人，对机器操作人员进行培训，开车时系好安全带。
          • 转移。用一定的代价，把应对风险的责任与风险的后果转移给第三方。通常，需要签署风险转移合同。例如，购买保险，把工作外包，业主要求承包商提交由银行出具的履约担保。
          • 接受。不主动管理风险。对于可承受的风险或无法用其他策略的风险，可以使用接受策略。接受又分成两种：
            • 一种是被动接受，即不采取任何行动，顺其自然，风险发生后再说；
            • 另一种是主动接受，即预留应急储备，以便风险发生后使用。
          • 对于整个项目的应急储备，如果没有任何可靠的依据，就按项目总成本的10%计算。这是一个经验式规则。
        • 在一个项目中，对不同的风险，通常要采用不同的应对策略。风险减轻、转移和接受策略，可以在某一个风险上组合使用，即同时采取这三种策略。
        • 对于不严重的风险（通常是采用“接受”策略的风险），不可以简单地置之不理，而需要记录下来，注意观察，防止变严重。
        • 选择风险应对策略不仅是项目经理和项目团队的事情，也是其他主要相关方的事情。大家要对风险应对策略达成一致意见。
        • 针对机会，也可以采取五种应对策略：
          • 上报。把机会上报给更高层去管理。
          • 开拓。采取措施，确保机会肯定出现。与威胁规避正好相反。
          • 分享。与其他方一起共同促进机会发生，共享机会发生的利益。
          • 提高。采取措施，提高机会出现的可能性或影响。
          • 接受。不主动促进机会发生，只是在机会自然发生时利用机会。
        • 针对整体项目风险，可以采取五种应对策略：
          • 规避。通过取消某种或某些高威胁的工作来降低整体项目风险水平。如果整体项目风险太高且无法降低，就不得不提前终止整个项目。
          • 开拓。扩大项目范围，确保抓住某种即将出现的巨大机会，以提高项目对相关方的价值。
          • 转移或分享。如果负面的整体项目风险太高，就采取转移策略；如果正面的整体项目风险很大且仅靠自身力量难以实现，就采取分享策略。
          • 减轻或提高。采取措施，降低整体项目风险（威胁）的水平，提高整体项目目标出现正向变异的可能性（如提前完工）。
          • 接受。按当前的状况继续实施项目，不采取任何主动的应对措施。
          • 在实际工作中，威胁、机会和整体项目风险的应对策略并不能截然分开，往往是交叉在一起的。
        • 应急应对策略既可以针对单个项目风险（机会或威胁），也可以针对整体项目风险，相当于我们平时所说的应急预案。对于很大且有明显预警信号的威胁或机会，可以制定应急应对策略及其启动条件。
      • 11.4.6 实施风险应对
        • 本过程的工具与技术只有三个：专家判断、项目管理信息系统、人际关系与团队技能。
          • 对于要由项目团队以外的人去实施的应对措施，项目经理就需要施展个人影响力（属于人际关系与团队技能）。
          • 影响力是指在没有正式职权的情况下使他人服从自己的能力。
        • 11.4.7 监督风险
          • 召开风险审查会（属于会议），审查应对策略和措施的实施情况，重新评估风险发生的可能性、后果和其他情况。
          • 采用数据分析技术中的储备分析，来考察项目的进度和成本绩效，判断预留的应急时间和应急资金是否仍然合理。
          • 采用数据分析技术中的技术绩效分析，来考察项目的范围和质量绩效，据此评价风险的实际影响，预判未来可能的影响。
          • 开展风险审计，总结风险管理方面的经验教训，为以后的风险管理积累新的知识。
  • 第12章 项目采购管理
    • 有关采购管理的问题都是从买方的角度提出的 。虽然业主是最经常的买方，但是买方不局限于业主。判断买方的标准是：支付金钱获得产品、服务或成果的一方。
      • 因为从外部获取货物或服务是通过合同进行的，所以采购管理也是围绕合同开展的。合同签订之前，需要做大量准备工作；合同签订之后，需要执行和管理合同；合同关闭前，需要开展合同收尾工作。
      • 需要重点掌握：
        • 合同的性质。合同是很严肃的，具有法律效力。
        • 合同当事人之间的关系。合同当事人之间是地位平等和权责对等的关系。
        • 合同签订的条件、程序。合同双方需要具备相应的权利与行为能力才能签合同；双方通过一定程序达成一致意见，才能成立合同。
        • 合同的种类、各种类的特点及适用的项目。各种合同有各自的优缺点，适用于不同的项目。
        • 合同的主要条款。只有具备这些条款，合同才能有效。
        • 合同的风险分担，即如何在当事人之间分配风险。
        • 合同绩效监控及合同变更，即如何监控合同绩效，如何管理合同变更。
        • 合同争议的解决，即对协商不能达成一致的事项，应该如何解决。
        • 合同的终止，包括未完成前的提前终止与完成时的正常终止。
    • 授标信起“承诺”的作用。在该厂商收到授标信时，合同就正式成立 ，哪怕这时还没有一页双方都在上面签过字的协议。
      • 在《PMBOK®指南》中，实施采购过程的第二个输出“协议”，理解成“合同”更合适。
    • 12.1 基础知识
      • 12.1.1 概述
        • 项目采购管理是指项目执行组织从外部获取产品、服务或成果来最优满足项目的需求。由于项目的复杂性，项目执行组织往往不可能依靠自身的力量完成全部项目工作，而是需要把某些项目工作外包给其他组织进行。外包通常是以合同的形式进行的。
        • 一个项目可能有多个执行组织。如果某个执行组织与其他执行组织之间需要签订正式的项目工作合同，就需要运用项目采购管理的知识。
        • 在PMP®考试中，除非题目另有特别要求，
      • 12.1.2 合同的性质
        • 合同是用来明确当事人双方权利义务关系的，是对双方都具有法律约束力的协议。合同肯定是协议，但协议不一定是严格意义上的合同。不具有可操作性的协议就不能成为严格意义上的合同。《PMBOK®指南》中对“协议”和“合同”这两个词的使用比较混乱，其中大多数“协议”都应理解成“合同”。
        • 通常，意向书不具有约束力，备忘录不具有正式约束力，协议具有有限约束力，合同则具有正式（法律）约束力。
        • 合同一旦签订，其中的所有条款都必须执行，除非个别条款违反法律规定。
        • 合同是双方当事人协商一致的产物，当事人处于平等地位。
        • 合同是双方当事人之间的约定，不应该涉及第三方的权利义务，除非这个第三方是其中一方当事人的代表或按法律规定所必需的。
        • 在项目的所有文件中，合同是最正式的，没有哪个文件会比合同更加正式。对合同的修改必须以正式、书面的方式进行。
        • 任何合同都是在一定的法律背景下起作用的。法律是合同效力的保障。法律也为解决合同争议提供了最后的途径，即诉讼。
        • 合同签订后，可以提出变更，但变更须经双方当事人一致同意。如无法达成一致，则按解决争议的方法解决。
      • 12.1.3 合同成立及其主要条款
        • 要约（Offer）和承诺（Acceptance）是合同成立的必要且充分条件
          • 要约，又称发盘或报价，是一方当事人向另一方当事人所做的、邀请订立合同的意思表示；
          • 承诺则是被要约人无条件、完全地同意要约人的要约，愿意按此成立合同的意思表示。
          • 合同是否成立，不取决于有无一份双方都在上面签过字的协议，而取决于是否已经完成要约和承诺。
          • 只要完成了要约和承诺，即便没有一份双方都签过字的协议，合同也已成立。
        • 合同通过许多具体条款来明确双方的权利义务关系。合同条款应该明确、齐全，便于双方全面、严格地履行合同。合同应当具备以下几个主要条款：
          • 标的（指货物、劳务、工程项目等）。没有标的，权利义务就无所指向，合同也就根本无法存在。
          • 数量和质量。这是对标的的具体要求。
          • 价款或酬金。这是一方向交付标的的另一方支付的对等代价。
          • 履行合同的期限、地点和方式。这是指当事人必须在什么时间、什么地点，以什么方式履行义务和享受权利。
          • 违约责任。这是指一方因过错不能履行或不能完全履行合同，而侵犯另一方的权利时，必须承担的经济责任。
        • 在较大的合同中，通常还有争议解决条款。也就是，由双方当事人自行约定争议的解决方式，以便他们对争议的解决有更大的自主权，而不需要一有争议就到法院打官司。
        • 针对PMP®考试，还应该了解合同中的以下重要条款：
          • 工作范围。合同规定的工作范围是什么？《PMBOK®指南》指出，买方用“采购工作说明书”明确合同的工作范围，卖方在获得合同后要及时编制“合同工作分解结构”，与买方确认工作范围。
          • 合同转让。任何一方都不能随意把合同权利或义务转让给第三方，合同转让必须征得另一方的同意。
          • 合同付款。有什么种类的付款？什么时候支付？付款的程序与条件是什么？延迟支付的利息如何计算？
          • 合同工作的验收。工作达到何种数量和质量要求、在何时完成，才是可以接受的？应该通过何种程序来验收？
          • 合同代表及其权力。谁是合同当事人的代表？有什么权力？
          • 违约。什么构成违约？违约方应承担什么责任？如规定的违约金，它是事先确定的、针对某种特定违约的赔偿金。
          • 担保。合同当事人应提供什么担保？如承包商应提供的预付款担保和履约担保，还有以保留金形式的现金担保。
          • 报告。什么时候、以什么方式、向谁提交何种报告？
          • 不可抗力。什么是不可抗力以及不可抗力的风险如何分担？不可抗力引起的损失，通常落在谁头上，就由谁承担。
          • 合同变更。变更的程序、时间、种类和谈判等。
          • 索赔。根据合同或法律，一方可以向另一方索取损失补偿。合同中需要明确索赔的条件与程序。
          • 弃权。一方以行为（有意或无意）放弃合同中的部分权利。
          • 争议解决。双方当事人协商不成，就产生“争议”。合同中可以约定争议解决办法。
          • 合同终止。包括在工作未全部完成之前终止合同以及工作全部完成后终止合同。
        • 一方违约，另一方必须在发现这种违约之后及时书面通知违约方，声明对方已经违约并保留自己的索赔权利。
    • 12.2 合同类型
      • 这是PMP®考试中的重要内容之一。考生必须弄清楚合同的类型及其特点、适用的项目。考试中可能出现情景题，让你选择最适合的合同类型。
        • 按《PMBOK®指南》，有三种基本的合同类型，即总价合同、成本补偿合同和工料合同。
        • 在实际工作中，这些合同类型可以混合使用，即在同一个合同中，有些工作采用总价合同，有些采用成本补偿合同，有些又采用工料合同。
      • 12.2.1 总价合同
        • 总价合同是指对合同工作规定一个总价。从成本风险的角度来说，业主的成本风险最低，基本没有成本风险。在这种合同下，买方必须准确定义工作范围。只有工作范围很清楚的项目，才可以采用总价合同。如果工作范围发生变化，通常允许调整总价。
        • 总价合同又可以衍生出：
          • （1）固定总价合同（Firm Fixed Price，FFP）。在既定的工作范围之下，价格是绝对固定的。除非工作范围出现变更，否则不允许调整价格。
          • （2）总价加经济价格调整合同（Fixed Price with EconomicPrice Adjustment，FPEPA）。在总价的基础上，允许根据通货膨胀情况来调整合同价格。适用于履行期较长（跨年度）的合同。合同中应该规定详细的价格调整方法，如调价系数的计算公式，以及公式中的价格指数的来源。
          • （3）总价加激励费用合同（Fixed Price Incentive Fee，FPIF）。在总价的基础上，规定相应的激励费用，以调动卖方的积极性，使买卖双方的目标趋于一致。在这种合同下，通常会规定一个最高限价。付款总数不得超过最高限价。激励费用的计算基础可以是某种绩效标准，如目标工期、目标成本、质量达标率。
            • 基于目标工期的总价加激励费用合同比较好理解，规定合同总价、提前完工奖励或延误完工罚款、最高限价，有时还会规定最低限价。
            • 基于目标成本的总价加激励费用合同比较复杂，在过去的PMP®考试中也出现过。合同中需要规定：
              • 目标成本。正常情况下项目将要花费的成本。
              • 目标费用（利润）。如果卖方以目标成本完成项目，将可以获得的利润。
              • 目标价格。目标成本与目标费用之和。
              • 最悲观成本。如果卖方没有任何管理或技术上的失误，项目可能发生的最大成本数。如果卖方实际成本超出此数，则认为超出部分是卖方失误造成的，全部由卖方独自承担。由于最悲观成本是假设的最大成本数，因此其正规术语是“Point ofTotal Assumption（PTA）”，可翻译成“总体假设点”。最悲观成本（PTA）具有如下意义：
                • 在实际成本未超过PTA之前，成本超支数由买方与卖方按事先约定的比例分担。一旦实际成本突破PTA值，卖方必须独自承担高于PTA值的全部超支数（买方不再分担）。
                • 在实际成本达到PTA时，买方向卖方支付的合同价款也就达到最高限价。这之后无论实际成本多高，买方都只向卖方支付最高限价。
                • 知道了PTA，卖方就可以更好地控制成本。随着实际成本超过目标成本，卖方的可得利润数会逐步减少。
              • 成本分担比例。卖方实际成本（不得超过最悲观成本）超过目标成本的部分，买方和卖方按比例分担。
              • 最高限价（封顶价）。买方可能向卖方支付的最高价格。无论如何，合同付款不得超出此数。
              • 其中，最悲观成本、成本分担比例和最高限价是紧密相连的，知道了其中的任意两个，就可以计算出剩余的第三个。基本的计算公式如下：
                • 最高限价=（目标成本+目标利润）+（最悲观成本−目标成本）×买方分担比例
                • 买方分担比例=（最高限价−目标价格）/（最悲观成本−目标成本）
                • 最悲观成本=［（最高限价−目标价格）/买方分担比例］+目标成本
            • 在基于目标成本的总价加激励费用合同中，买方并不分享可能的成本节约（实际成本低于目标成本的部分）。
        • 12.2.2 成本补偿合同
          • 成本补偿合同是指以卖方从事项目工作的实际成本作为付款的基础，即成本实报实销。在这种合同下，买方的成本风险最大。
            • 这种合同适用于买方仅知道要一个什么产品但不知道具体工作范围的情况，也就是工作范围很不清楚的项目。
            • 当然，成本补偿合同也适用于买方特别信得过卖方、想要与卖方全面合作的情况。
          • 卖方在获得成本补偿的基础上，还需要获得一定的利润。根据利润的计算方法不同，成本补偿合同又可分为：
            • （1）成本加固定费用（Cost Plus Fixed Fee，CPFF）。成本实报实销，买方另外向卖方支付固定金额的利润。这是最常用的成本补偿合同，对卖方有一定的制约作用。无论实际成本是多少，利润都保持不变（在合同中规定的金额）。
            • （2）成本加激励费用（Cost Plus Incentive Fee，CPIF）。买方向卖方的付款由三部分组成：实际成本、一笔固定的费用、按合同规定的方法计算的对固定费用的调整数。
              • 这种合同与“总价加激励费用合同”类似，会规定目标成本、目标费用（固定费用）和成本超支分担比例。
              • 不同的是，在成本加激励费用合同中，不会规定最高限价，但会规定成本节约的分享比例。如果卖方的实际成本低于目标成本，节约部分由双方按一定比例分享（如60/40，即买方60%，卖方40%）；
              • 如果卖方的实际成本高于目标成本，超支部分由双方按比例分担（如60/40，即买方60%，卖方40%）。
              • 在成本加激励费用合同下:
                • 如果实际成本大于目标成本，卖方可得的付款总数=目标成本+目标费用+买方应负担的成本超支。
                • 如果实际成本小于目标成本，卖方可得的付款总数=目标成本+目标费用−买方应享受的成本节约。
            • （3）成本加奖励费用（Cost Plus Award Fee，CPAF）。成本实报实销，买方再凭自己的主观感觉给卖方支付一笔利润，而卖方对利润数没有任何讨价还价的余地。
            • （4）成本加百分比（Cost Plus Percentage of Cost，CPPC）。买方在卖方实际成本的基础上，再加上以该成本的某个百分比计算的利润，向卖方付款。由于买方通常不喜欢用这种合同，《PMBOK®指南》中已删去这种合同。
            • 注意：费用（Fee）不同于成本（Cost）。在成本补偿合同中，费用主要是卖方可以得到的利润。
        • 12.2.3 工料合同
          • 工料合同，也叫“时间和手段合同”，是指按项目工作所花费的实际工时数和材料数、事先确定的单位工时费用标准（单价）和单位材料费用标准（单价）付款。
            • 这类合同适用于工作性质清楚但具体的工作量无法确定的采购。
            • 在这种合同下，买方与卖方分担成本风险，即买方承担工作量的风险，卖方承担单价的风险。
          • 需要注意的是，《PMBOK®指南》中没有提到大型土木工程经常使用的“综合单价合同”。在综合单价合同下，买方按实际工程量和合同规定的综合单价向卖方付款。综合单价是把人工费、材料费、设备费、管理费和利润都综合在一起的。工料合同中的单价不是综合单价，而是针对每种人工、材料或设备的单价，如每小时钢筋工的单价、每立方米木材的单价、每个台班设备的单价。
          • 工料合同适用于规模小、工期短、不复杂的工作，而不适用于规模大、工期长、很复杂的工作。如果对后面这种工作使用工料合同，那么合同管理工作将十分烦琐，会导致管理成本的不合理上升。
          • 项目中的另一种常用合同是订购单。非大量采购标准化产品，通常可以由买方直接填写卖方提供的订购单，卖方照此供货。因为订购单通常不需要谈判，所以又叫单边合同。
        • 在考试中，可能有题目要求选择最合适的合同种类。关于合同种类的选择：
          • 如果工作范围很明确，项目的设计已具备充分的细节，则使用总价合同。
          • 如果工作性质清楚，但工作量无法确定，而且工作不复杂，又需要快速签订合同，就用工料合同。工料合同常用于聘请咨询专家，紧急招聘人员来替代突然离职的团队成员，聘请技术专家检修机器。
          • 如果工作范围很不清楚，就用成本补偿合同。
          • 如果希望双方分担风险，就用工料合同；如果希望买方承担成本风险，就用成本补偿合同；如果希望卖方承担成本风险，就用总价合同。
          • 从买方的角度讲，除非万不得已，不要选用成本加百分比合同。
          • 如果购买标准产品，且数量不大，就用“单边合同”，即直接发出订购单。
    • 12.3 各过程的输入与输出
      • 12.3.1 输入与输出的关系总览
        • 项目采购管理的实现过程包括规划采购管理、实施采购和控制采购。
      • 12.3.2 规划采购管理
        • 规划采购管理过程的输入和输出：
          • 在项目章程的指导下编制关于采购的计划和文件。
          • 关于采购的计划和文件都必须符合商业文件（包括商业论证和效益管理计划）中的规定，有利于实现商业文件中的要求。
          • 项目管理计划中的范围管理计划，有助于策划该如何管理拟外包工作的范围；质量管理计划有助于确定拟外包工作的质量标准和质量管理方法；资源管理计划有助于确定哪些资源需要外购；范围基准有助于确定哪些WBS要素需要外包出去。
          • 项目文件中的里程碑清单有助于确定重要的可交付成果的交付日期；项目团队派工单有助于了解哪些团队成员应该对采购工作承担什么职责；需求文件有助于确定哪些需求必须依靠外购来实现；需求跟踪矩阵有助于确定为了实现特定的高层目标而必须交付哪些可交付成果；资源需求有助于确定哪些资源必须外购；风险登记册有助于确定哪些风险应该采取转移策略；相关方登记册有助于了解与采购工作有密切关系的相关方。
          • 本过程的主要输出，请见下文12.4.1节。
          • 关于采购的计划和文件编制出来后，可能需要提出变更请求，回头调整已有的项目计划。
      • 12.3.3 实施采购
        • 实施采购过程的输入和输出：
          • 根据项目管理计划中的相关内容开展实施采购过程:
            • 需求管理计划有助于识别和分析拟通过采购来实现的需求
            • 范围管理计划有助于合理确定拟外包工作的范围
            • 沟通管理计划有助于在实施采购过程中开展有效的沟通
            • 风险管理计划有助于分析和管理与采购工作有关的风险
            • 采购管理计划有助于按正确的程序实施各种采购管理活动
            • 配置管理计划有助于确定卖方必须实现的重要技术参数
            • 成本基准有助于把采购的成本控制在规定的数额内
          • 项目文件中的:
            • 项目进度计划有助于确定该在何时开展采购活动以及卖方必须在何时交付可交付成果
            • 需求文件有助于评价卖方建议书中的方案能否实现既定的需求
            • 风险登记册有助于评估与特定潜在卖方及其建议书有关的风险
            • 相关方登记册有助于邀请潜在卖方（也属于相关方）提交建议书，以及考虑各主要相关方对建议书评审的要求和期望
          • 把前一个过程所编制的各种文件归并为采购文档，作为本过程的输入。
            • 在本过程中，买方根据自制或外购决策，以及采购策略，把包含采购工作说明书在内的招标文件发给潜在卖方。
            • 然后，潜在卖方准备卖方建议书并报给买方。买方再按供方选择标准和独立成本估算对卖方建议书进行评审。
          • 买方评审卖方建议书后，选定一家中标商（选定的卖方），报给领导审批。领导审批后，买方正式与中标商签订协议（合同）。
          • 协议签订后，可能需要提出变更请求，回头修改项目计划。
          • 再次开展采购时，需要参考经验教训登记册（一种项目文件）。
      • 12.3.4 控制采购
        • 控制采购过程的输入和输出：
          • 根据项目管理计划开展控制采购过程。
            • 需求管理计划有助于有效监控合同执行是否能够有效实现既定的需求
            • 风险管理计划有助于管理与合同执行有关的风险
            • 采购管理计划有助于按既定的程序监控合同执行绩效
            • 变更管理计划有助于处理与合同有关的变更
            • 进度基准有助于监控合同执行是否能够保证项目进度目标的实现。
          • 各种项目文件是本过程的输入。
            • 假设日志有助于监督与合同执行有关的假设条件的落实情况以及制约因素是否有变化
            • 里程碑清单有助于监督卖方提交可交付成果的时间能否满足里程碑实现时间的要求
            • 质量报告有助于发现卖方的工作过程或结果的质量问题
            • 需求文件和需求跟踪矩阵有助于监控卖方的工作能否实现项目既定的需求
            • 风险登记册有助于监控合同执行中的风险
            • 相关方登记册有助于了解哪些相关方最关心合同的执行绩效
            • 重复开展本过程时，需要参考已写入经验教训登记册的经验教训。
          • 需要把体现在工作绩效数据和采购文档中的合同执行绩效，与协议和采购文档中的要求进行比较。采购文档中既有规划阶段编制的文件（如招标文件），也有执行阶段形成的文件（如买方和卖方之间的往来函件）。
          • 通过监控，发现合同执行绩效的偏差，形成工作绩效信息。如果合同执行绩效不理想，就提出变更请求。
          • 对要求修改合同的变更请求，无论是哪方提出的，都要由双方协商。协商达成一致，就变成批准的变更请求，即合同变更令。后续的控制采购过程就应该根据批准的变更请求去开展。
          • 收集本过程得到的各种文件，形成采购文档更新。再根据采购管理计划和最新的采购文档，关闭合同，得到结束的采购。
    • 12.4 各过程的主要工作和成果
      • 12.4.1 规划采购管理
        • 本过程旨在确定哪些工作要外包，编制招标采购计划和文件，为开展招标采购做好准备。本过程的输出，除了作为程序性计划的采购管理计划，其他所有输出都属于实体性计划。
        • 在本过程中，按以下基本顺序开展如下工作：
          • （1）编制采购管理计划。
            • 采购管理计划是关于将如何开展采购工作的计划，需要说明将如何做出自制或外购决策，如何识别潜在卖方，如何编写采购文件，采用何种采购方法，采用什么合同类型，如何选择卖方，如何管理合同，如何开展合同收尾。采购管理计划所包括的内容可以很多，取决于项目的需要。它是项目管理计划的组成部分。
          • （2）做出自制或外购决策。
            • 自制或外购决策是关于哪些工作要自己做、哪些工作要外包出去的决定，可以用表格列明。
          • （3）制定采购策略。
            • 采购策略是针对单次特定的采购，对采购管理计划中的相关内容的具体化。整个项目只有一份采购管理计划，但也许有多份采购策略，每份采购策略针对一次特定的采购。
            • 《PMBOK®指南》中详细规定了采购策略的三部分内容，即交付方式（如总承包方式）、合同类型（如总价合同）和采购阶段（是否分阶段采购）。
            • 采购策略中的这些内容都需要在后续的采购工作说明书、招标文件和协议（合同）中进一步具体化。
          • （4）编制采购工作说明书。
            • 采购工作说明书是对即将外包出去的那些工作的书面描述，用来告诉潜在卖方需要他们做什么工作，以便他们判断是否有能力、有兴趣承接该工作。
            • 有能力、有兴趣的潜在卖方还可以据此提出承接工作的建议书或报价。
            • 采购工作说明书相当于即将外包出去的工作的范围说明书。
          • （5）编制招标文件。
            • 招标文件用于邀请潜在卖方提交投标书、建议书或报价。《PMBOK®指南》提到了“信息邀请书”“建议邀请书”和“报价邀请书”等词语。
            • 信息邀请书，严格地讲，并不是一种招标文件，只是用于邀请厂家提供更多的信息。
            • 如果主要依据技术方案来选择卖方，就使用“建议邀请书”；如果主要依据价格选择卖方，就使用“报价邀请书”；如果同时考虑技术方案和报价，就使用狭义上的“招标文件”。例如，要采购咨询服务，通常用“建议邀请书”。
          • （6）编制独立成本估算，即俗称的“标底”。
            • 买方自己要预判一下完成合同工作将需要多少钱。
          • （7）编制供方选择标准，即评标标准。
            • 主要的评标程序和标准应该写入招标文件，详细的评标程序和标准不必写入。在价格不是唯一决定因素的采购中，评标程序和标准是非常重要的。
          • （8）汇编成招标文件包。
            • 把采购工作说明书、招标文件、主要的供方选择标准等汇编成招标文件包，以便在实施采购过程中向潜在供应商发放。
      • 12.4.2 实施采购
        • 本过程是按采购管理计划和采购策略中规定的采购方法，开展实际的招标采购（包括招标、投标、评标和授标这四个环节），签订采购合同。
        • 采购方法是多种多样的，应根据具体情况选用。例如：
          • 直接采购。直接邀请某一家厂商报价或提交建议书，没有竞争性。
          • 邀请招标。邀请一些厂家报价或提交建议书，具有有限竞争性。
          • 竞争招标。公开发布招标广告，以便潜在卖方报价或提交建议书，具有很大的竞争性。
        • 应该尽可能采用竞争招标的方式。只有在下列情况下，可以采用非竞争方式：
          • 项目的时间很紧，没有时间编制竞争招标所要求的招标文件。
          • 只有唯一的一个供应商能够提供所需货物或服务，别无选择，这种情况叫“独有来源”（Sole Source）。
          • 虽然有多个供应商能够提供所需货物或服务，但买方因确信某个特定供应商具有特别的优势，而直接向该供应商采购。这种情况叫“单一来源”（Single Source）。
          • 在非竞争的情况下，也能得到合理、有利的价格和产品。例如，规模很小的采购、不具有吸引力的采购。
        • 如果打算向过去已合作多年的厂家直接采购，即开展单一来源采购，在做出决定之前，仍然必须审查该厂家是否有资格承接本次工作任务。
        • 由政府公共资金资助的采购，通常都必须用竞争招标的方式，以保证所有合格的潜在卖方都获得公平的竞争机会。
        • 下面以竞争招标方式为例，讨论实施采购过程。
          • 招标与投标在合同成立过程中起要约邀请和要约的作用。首先，买方发出招标文件，邀请潜在卖方要约；其次，潜在卖方购买招标文件，并应邀参加投标人会议；最后，潜在卖方根据招标文件编制投标文件，进行投标，向买方要约。由于要约对要约人有约束力，因此潜在卖方在投标时需要提交投标保证金或投标担保。在规定的投标有效期内，投标文件对投标人具有约束力。他不得撤回或修改投标文件，否则投标保证金或担保就要被招标方没收。
          • 招标方收到投标文件后，就要按既定的评标程序和标准开展评标工作。评标工作通常由专门的评标委员会进行。评标委员会编写评标报告，推荐某投标商中标，并建议招标方的高级管理层授予合同。
          • 基于评标委员会的推荐，招标方的高级管理层正式批准某厂商中标，并向其发出授标信，与其成立合同。
      • 12.4.3 控制采购
        • 控制采购过程是管理合同双方的合同关系，监控合同工作绩效，管理合同变更。简单地说，就是随合同执行进行合同管理。必须从确保项目目标实现的高度来开展控制采购过程。
        • 合同签订以后，千万不要把它扔到一边，只是到迫不得已需要时才去查一查。对合同一定要熟读，一定要掌握合同的整体精神，并且在日常工作中按合同的要求去做。
        • 合同管理的目的，不仅是要促使合同双方认真履行各自的合同义务，而且是要充分协调好双方之间的合同行为，在双方之间建立一种相互支持、相互促进的伙伴型关系，以便通过严格的过程控制来达到范围、进度、成本和质量的整体最优，保证合同工作按计划有效完成。
        • 合同解释是合同管理工作中的重点和难点之一。合同解释应该遵循的几个主要原则是：
          • 主导语言原则。
            • 如果合同存在两种语言的文本，必须约定哪一种语言是主导语言。当两者不一致时，应该以主导语言文本为准。
          • 适用法律原则。
            • 确定以哪个国家的法律作为合同的适用法律。合同的解释必须根据适用法律进行。
          • 整体解释原则。
            • 合同是一个整体，不能割断各部分之间的联系，不能断章取义。
            • 在长期的合同实践中，已经形成一套公认的合同整体解释惯例。如果合同中没有其他特别规定，在出现含糊或矛盾时应该按这些惯例进行解释。
            • 一般来说，专用条件优先于通用条件，具体规定优先于笼统规定，手写条文优先于印刷条文，单价优先于总价，价格的大写（文字）优先于小写（数字），技术规范优先于图纸。
          • 公平诚信原则。
            • 在解释合同时应公平合理，兼顾双方当事人的利益。如果按上述整体解释原则进行解释后仍含混不清，则可按不利于合同起草方的原则进行解释。在这种情况下，可以理解为起草方故意使用了有歧义的词句，故应该承担相应的责任。
        • 在合同解释时需要谨慎对待“备忘录”和“意向书”。如果备忘录与合同规定不一致，合同规定的效力要高于备忘录。从本质上讲，意向书是没有法律约束力的，其效力当然就远低于备忘录和合同。
        • 采购，有集中采购与分散采购之分。
          • 前者是指由执行组织统一对外采购各项目所需的材料、设备或服务.
          • 后者是指由各项目分别对外采购各自需要的材料、设备或服务。
          • 这两种方式可在一个项目上同时存在。
        • 合同管理，也有集中合同管理与分散合同管理之分。
          • 前者是指在项目执行组织中有一个专门的职能部门，负责所有项目的合同管理工作；
          • 后者是指每个项目都有自己的合同管理人员，专门负责本项目的合同管理工作。
          • 当然，在实际工作中，经常是部分集中、部分分散的混合式合同管理。
        • 公司通过合同开展的业务越多，就越要采用集中合同管理。
      • 集中合同管理与分散合同管理各有优缺点
      • 在《PMBOK®指南》中，把关闭合同（结束采购）的工作也归入了控制采购过程。为了正式关闭合同，就需要结束合同工作以及当事人之间的合同关系，进行采购审计，并将有关资料收集归档，更新组织过程资产。
      • 无论何种原因导致合同终止，都要进行合同收尾。即便合同提前终止，也必须进行合同收尾，把合同正式关闭。
      • 合同收尾要做的主要工作包括：
        • 产品核实。是否所有合同工作都已按要求完成？产品是否符合要求？
        • 可交付成果验收。按合同规定的验收程序与标准，对合同可交付成果进行最终验收。
        • 财务结算。结算合同最终价款，支付最终款项，更新项目财务记录。
        • 退还保证金或担保函（如保留金、履约担保）。
        • 总结合同实施情况，进行采购审计，从独立、公正的第三方角度来总结采购工作的经验教训。
        • 更新合同记录，收集资料，整理合同档案，更新组织过程资产。
      • 各采购管理过程的主要工作
    • 12.5 各过程的工具与技术
      • 12.5.1 规划采购管理
        • 首先，通过市场调研来开展数据收集，了解市场情况；其次，根据市场调研所得到的资料，开展自制或外购分析（属于数据分析），确定哪些工作该外包出去。无论是做市场调研还是自制或外购分析，都需要召开会议。
        • 可以采用多种多样的方法进行市场调研，了解市场供需情况，以便合理做出与采购有关的安排。会议既包括项目团队或执行组织内部的会议，也包括项目团队或执行组织与市场上的潜在买方或其他相关方的会议，它们有助于了解市场情况，编制采购管理计划。
        • 自制或外购分析是规划采购管理过程中的一项重要工作。一个项目，也许可以全部自制、全部外购，或者部分自制、部分外购。自制或外购分析原本是管理会计中的一个重要概念，用来比较两者之间哪个成本更低。计算外购的成本，要包括外购的实际成本和外购工作的管理费用。
        • 当然，自制或外购的理由，并不局限于成本方面的考虑。例如，自己有闲置的设备或人力，或者自己想掌控这部分工作，或者这部分工作涉及一些机密的信息或程序，就应该“自制”。除了降低成本，也可以为缩短研发周期、建立长期伙伴关系等而“外购”。
        • 自制或外购分析在PMP®考试中也可能引申为购买或租赁分析。道理是一样的。
        • 在PMP®考试中，除非题目明确告诉你，如果购买该设备，本项目使用后还可以再出售或供执行组织其他工作使用，否则就不用考虑再出售或供其他工作使用。
        • 风险管理中的风险接受或转移分析，也属于自制或外购分析的延伸。
        • 在规划采购管理过程中，需要使用“供方选择分析”来确定将用什么方法来选择卖方（评标）。
          • 注：* 本表对独有来源的描述，与《PMBOK®指南》第474页的内容有所不同。《PMBOK®指南》中的“独有来源”（SoleSource）更像“单一来源”（Single Source）。前者是只有一家能提供所需的货物或服务，后者是虽然有多家能够提供所需的货物或服务，但是只认其中的某一家。要用单一来源的方式，就必须特别说明理由。
      • 12.5.2 实施采购
        • 实施采购过程包括招标、投标、评标和授标四个环节。本过程的工具与技术自然也就是用于开展这四个环节的。专家判断是四个环节都要使用的。
          • 第一是招标环节的广告。
            • 买方发布招标采购广告，让潜在卖方知道有这么一回事。当然，发广告的方式可以多种多样。
              • 竞争性招标，应该在公共媒体上发布广告。
              • 邀请招标，应该在有限范围内发布广告。
              • 直接采购，则只需要向特定厂家发出采购消息。
          • 第二是投标环节的投标人会议。
            • 潜在卖方购买招标文件之后，就根据招标文件编制投标文件。在编制投标文件的过程中，潜在卖方会对招标文件有各种疑问。招标方应该通过投标人会议，给他们提问的机会，并回答他们的问题。在投标人会议期间，招标方也应该带潜在卖方考察项目现场。
            • 在投标人会议期间，买方必须确保公平地对待每个潜在卖方，不使任何一个受到特别优待或歧视，必须确保每个潜在卖方得到完全一样的信息。
            • 在竞争性招标中，投标人会议（标前会议）必不可少。
          • 第三是评标环节的建议书评价（属于数据分析）。
            • 这是用于评标的方法。常用的评标方法包括：
              • 加权打分法。用具有不同权重的各评标标准，对各投标文件进行打分，然后加权汇总，得到各潜在卖方的排名顺序。将选择得分最高的潜在卖方中标。
              • 筛选系统，也叫过滤系统。通过多轮过滤，逐步淘汰掉达不到既定标准的投标商，直到剩下一家。用于淘汰的标准，各轮逐渐提高。最后剩下的那家，就是中标者。
              • 独立估算。把潜在卖方的报价与买方事先编制的独立成本估算（俗称“标底”）进行比较，选择与标底最接近的报价中标。
          • 第四是授标环节的谈判（属于人际关系与团队技能）。
            • 在确定中标者（正式授标）之前，需要与潜在卖方进行谈判。注意：谈判的目的不是“卡”对方，而是要与潜在卖方加深了解，得到公平、合理的价格，为以后可能的合同关系奠定良好基础。
            • 谈判是为了保护将来合同成立之后的双方关系。
            • 还要特别注意的一点是：不要设法从对方口袋里去“拿”钱，而要从减轻风险入手去“省”钱。如果想要卖方降价，最好设法为他减轻一些风险
        • 列举一些常见的谈判策略：
          • 最后期限。设定一个达成协议的最后期限。
          • 自己的权力有限，有决策权的人又不在场。声称自己无权对某些问题做出决定，需要向领导请示，而领导又不在场。
          • 拖延。以各种方式拖延对其中某个问题的讨论，甚至拖延整个谈判。
          • 撤退。故意表现出自己对某个事物没有什么兴趣，以退为攻。
          • 出乎意料。突然抛出一个全新的、出乎意料的方案，以期打对方一个措手不及。
          • 公平合理。以各种方式证明自己所提的方案是公平合理的。
          • 既成事实（Fait Accompli）。坚持某个问题已有既定的解决方案，不需要再讨论。
          • 好人坏人。参与谈判的成员中，一人当好人，一人当坏人。通常，坏人先说，好人随后来收拾局面。
        • 谈判需要遵守以下四大原则：
          • 人与事分开的原则。应该尽量理性地谈判，不要带入个人感情。
          • 关注利益而非立场的原则。因为利益决定立场，所以必须关注对方的利益。
          • 创造共赢的解决方案。上文提及的从风险入手谈价格，就符合这个原则。
          • 坚持与客观标准比较。客观标准可以是法律法规、行业标准或其他公认资料中的规定。用客观标准作为依据来说明自己的要求的合理性。
      • 12.5.3 控制采购
        • 第一，要对卖方的工作情况进行检查。买方和卖方应该共同签署日常检查记录，对检查结果达成一致，以便作为卖方申请付款和买方支付款项的依据。如果检查结果不合格，买方可以拒付款项。
        • 第二，要使用数据分析中的挣值分析来计算进度和成本绩效指标，并据此进行进度和成本绩效的趋势分析。
        • 第三，要定期或不定期地开展审计，总结合同履行方面的经验教训，提出相应的变更请求。
        • 第四，要使用数据分析中的绩效审查，确定卖方的工作绩效和工作能力是否令买方满意，以决定该卖方以后是否适合承接类似的工作。
        • 第五，要通过索赔管理去预防、记录和处理卖方向买方的索赔。
          • 索赔管理是合同管理中的一个难题。索赔是一方遭受了某种不该自己承担的实际损失（包括金钱或时间损失），而基于法律或合同规定向对方提出的补偿请求。
          • 索赔的实质是要求损失补偿，不带任何惩罚性质。
          • 虽然合同任何一方都可以向对方索赔，但一般只讨论卖方（承包商）向买方（业主）的索赔。
          • 索赔可以分成不同的类别，如工期延误索赔、赶工索赔、变更索赔、不利现场条件索赔、违约索赔。PMP®考试中可能考到工期延误索赔和买方违约索赔。工期延误又可分为：
            • 可原谅延误与不可原谅延误。前者是承包商没有过错的延误，允许承包商延长工期；后者是承包商有过错的延误，不允许延长工期。
            • 可补偿延误与不可补偿延误。前者是承包商无过错但业主有过错的延误，不仅允许承包商延长工期，还对承包商因延误而遭受的经济损失给予补偿；后者是承包商和业主均无过错的延误，允许延长工期，但不补偿承包商的经济损失。
          • 违约索赔是一方违约，另一方向违约方提出损失索赔。绝不能用“以牙还牙”的方式处理违约。一方违约后，另一方不能以另一种违约来对付。另外，除非是特别明显的恶意违约，一般只能索赔实际损失，而不能对违约方进行实质性惩罚。
        • 虽然在本过程中没有直接列出专用于关闭采购合同的工具，但是审计、绩效审查和索赔管理都可用于关闭采购合同。审计是总结采购管理的经验教训，以便以后的采购管理做得更好。绩效审查是要审查卖方的总体工作能力，以便决定它以后是否还有资格来承接类似工作。索赔管理是要通过谈判或采用替代争议解决方法解决尚未解决的索赔。
  • 第13章 项目相关方管理
    • 13.1 基本概念
      • 项目相关方是其利益会受项目活动或结果的正面或负面影响的任何个人、群体或组织，以及能对项目活动或结果施加正面或负面影响的任何个人、群体或组织。通俗地讲，与项目有直接或间接关系的任何个人、群体或组织，都是项目相关方。
      • 应该把项目相关方的外延考虑得尽可能宽一些，因为遗漏重要相关方会给项目带来很大麻烦。
      • 项目相关方管理的重要性不言而喻。一方面，项目要取得成功，离不开项目相关方的支持与参与。另一方面，做项目最终是要满足项目相关方的利益追求，让相关方满意。在《PMBOK®指南》中，特别强调了项目相关方应该在整个项目生命周期中参与项目工作。
      • 项目经理应该以各种方式调动相关方合理参与项目工作。例如：
        • 认真评估和利用相关方的知识和技能，促进项目成功。不同的相关方拥有不同的知识和技能，只要是有利于项目的，都应该加以利用。
        • 在制订沟通管理计划时，应该切实弄清楚项目相关方对项目信息的需求，并在整个项目生命周期中向他们分发各种必要的项目信息，如关于项目进展或项目变更的报告，为他们参与项目工作创造条件。
        • 鼓励项目相关方参与项目制约因素与假设条件的鉴别工作，参与项目计划编制工作，作为项目大团队的组成部分参与项目大团队建设。
        • 把某些风险分配给项目相关方，请他们担任风险责任人管理这些风险
      • 相关方参与，对取得项目成功至关重要。相关方参与，有利于他们了解项目并为项目做贡献，有利于提升他们对项目的主人翁感。
      • 对于项目相关方管理，考生应该注意：
        • 需要识别出全部的项目相关方。
        • 需要考虑全部的项目相关方的利益与影响。
        • 需要充分发挥全部的项目相关方的作用来保证项目成功。
        • 相关方管理做得不好，往往是造成项目失败的主要原因。
        • 应该尽早积极面对负面相关方，如同面对正面相关方。
        • 应该充分评价项目相关方的知识与技能，并加以充分利用。
      • 不是只考虑一个或几个项目相关方，而是全部的项目相关方，至少理论上是这样要求的。
    • 13.2 项目相关方管理的发展
      • 13.2.1 在《PMBOK®指南》中的发展
        • 发展趋势：
          • 第1版和第2版：基本不理相关方。只是简单地提及“项目相关方”这个词，并没有讨论“项目相关方管理”。
          • 第3版：被动地解决与相关方之间的问题，专列了一个“管理相关方过程”。
          • 第4版：主动地管理相关方，新增了一个“识别相关方过程”，要求在项目启动阶段就主动识别相关方。还把“管理相关方过程”改成了“管理相关方期望过程”，要求主动引导相关方对项目抱有合理的期望。
          • 第5版：提出双向式相关方管理。把项目相关方管理单列为一个知识领域，强调鼓励相关方合理参与项目。
          • 第6版：更加强调相关方参与的重要性。把第5版的“相关方管理计划”改成了“相关方参与计划”，强调主动引导相关方合理地参与项目。
      • 13.2.2 《PMP®考试大纲》中的发展
        • 2015年版《PMP®考试大纲》新增了许多与项目相关方管理直接相关的内容。
        • 2019年版《PMP®考试大纲》中直接提及项目相关方的内容，整理如下：
          • 分析相关方对项目的权力、利益和影响等，并据此对相关方进行归类。
          • 建立与相关方的信任关系，用合适的方式去领导（启发、激励和影响）相关方。
          • 赋能相关方，包括授予相关方合适的决策权限，以及通过培训、教练或辅导去提升相关方的能力。
          • 评估所需的相关方参与程度，制定引导相关方以所需程度参与项目的策略，并加以执行。
          • 让项目团队外部的相关方了解项目执行组织和项目团队的组织原则。
          • 分析相关方的沟通需求，与他们保持合适的沟通，包括沟通渠道、频率和信息详细程度等，确保相关方持续了解项目信息。
          • 与相关方合作，解决项目问题。
          • 动态评估相关方从项目上获得价值的进展情况。
    • 13.3 主要项目相关方
      • 一个项目通常有众多的项目相关方，他们在项目上有不同的利益，对项目有不同的影响，对项目成功起不同的作用。
      • 13.3.1 项目发起人
        • 项目发起人是为项目提供资金和其他重要资源的人。项目发起人在提出项目的初步设想之后，会组织一班专家开展项目商业论证，然后对可行的项目落实所需资金。项目发起人亲自领导项目启动工作。在项目正式启动之后，发起人应该授权项目经理管理项目，并充当项目最重要的高层支持者。
        • 项目发起人作用是提供资金。
        • 关于项目发起人的角色，还需要注意以下几点：
          • 发起人应该对项目及其成果提出一些原则性要求。
          • 发起人可以亲自起草项目章程或授权项目经理代为起草。
          • 发起人可以亲自签发项目章程或授权项目执行组织高级管理层签发。
          • 发起人应该与其他重要项目相关方（如客户）一起验收项目成果。
          • 应该由项目发起人或其授权人员宣布项目正式关闭（结束）。
      • 13.3.2 高级管理层
        • 高级管理层是项目执行组织中高于项目经理的全体管理者的集合。如果某个项目由某个公司发起并执行，那么该公司的管理者既是项目的发起人，也是项目的高级管理层。
        • 高级管理层又包括如下主要成员：
          • 项目治理委员会。项目的高层决策机构。
          • 项目组合经理。负责确保项目与组织战略的一致性。
          • 项目集经理。负责管理项目集中的各个项目之间的横向联系。
          • 项目管理办公室。项目执行组织中负责管理项目管理工作的常设职能部门。
      • 13.3.3 客户
        • 客户是项目成果的使用者，既包括直接使用者，也包括间接使用者。一个项目可能有多种客户。
        • 必须在起草和签发项目章程时，就明确谁是本项目的客户，了解客户对项目的重要利益追求。当然，对于项目经理来讲，发起人或高级管理层本身也是客户，至少也是客户之一。
        • 众多项目相关方之间有利益冲突。发起人、高级管理层或项目经理应该尽力协调相关方之间的利益冲突。如果实在无法协调，通常应该按有利于客户的原则处理。如果有多个客户，又应该以最终端客户的利益至上。
        • 同一个人或一群人，既可以是发起人（提供资金），也可以是高级管理层（对项目进行高层监管），还可以是客户（接受或使用项目成果）。
      • 13.3.4 项目经理
        • 项目发起人或高级管理层应该尽早指定项目经理。一般应在项目启动阶段指定，以便项目经理参与项目章程的编写，甚至在获得授权后，主持项目章程的编写。最迟要在项目规划阶段初期指定，绝对不能到规划阶段中后期或者项目执行阶段再指定。
        • 项目发起人或高级管理层应该在项目章程中赋予项目经理管理项目的权责。虽然我们也希望项目经理的权责对等，但在项目实际环境中，往往职责大于职权。
        • 项目经理应该积极主动地工作，而不是消极被动地工作。要主动预防问题的出现，并积极解决已经出现的问题。项目经理作为项目管理专业人士，必须理解并遵守项目管理的职业要求（如职业道德）。
        • 如果高级管理层要求降低成本或压缩工期，项目经理不能简单接受，而要进行专业分析，并写出分析报告提交给高级管理层，供其进一步考虑。
        • 项目经理控制着项目，但不一定控制着资源。在矩阵式组织下，项目经理对一些人力资源与非人力资源没有控制权。
        • 项目经理作为一个整合者，应该在更大程度上是一个通才而不是专才。
        • 技术专家应该关注某种技术工作的细节，而项目经理应该关注各种技术工作之间的结合部。这是项目经理与技术专家的根本区别。
      • 13.3.5 项目管理团队与项目团队
        • 在项目启动阶段，项目发起人或高级管理层指定项目经理。在项目规划阶段开始时，项目经理组建项目管理团队。在项目执行阶段开始时，项目经理组建在一线从事具体项目活动的项目团队（狭义的）。
        • 狭义的项目团队从事具体项目活动，完成各个工作包。广义上的项目团队应是项目管理团队加狭义的项目团队再加其他的主要相关方。从广义上说，项目经理应该把主要相关方都看成项目团队的组成部分，而不能把项目团队局限于自己所在组织内部的小团队。中观层面的项目团队则是项目管理团队和狭义项目团队的组合。
        • 在《PMBOK®指南》中，“项目管理团队”和“项目团队”这两个词经常替换使用，并没有严格区分开来。项目管理团队是项目团队中直接从事管理工作的人的集合。
      • 13.3.6 职能经理和职能部门
        • 为了简便起见，此处的职能经理包括运营经理或直线经理，职能部门也包括运营部门。
        • 职能部门通常是项目所需的专业技术和专业人才的蓄水池。
        • 职能经理参与项目的程度取决于项目所采用的组织形式。
        • 在采用矩阵式组织的项目中，职能经理对项目成败有重要影响。为了避免不必要的冲突，项目经理与职能经理必须充分合作。
          • 在矩阵式组织中，项目经理与职能经理的分工可以参照一个大的原则来进行，即项目经理负责“做什么、什么时候做、为什么要做、以多大代价来做”等问题，职能经理负责“具体技术工作由谁来做和怎么做”等问题。
        • 针对某个具体项目，职能经理应该：
          • 参与项目启动工作，参与制定项目目标，参与项目计划的编制和审批工作。
          • 与项目经理就项目所需的资源进行协商，分派具体人员到项目上。
          • 就自己部门的专业领域，向项目提供技术支持。
          • 告知项目经理可能影响本项目的其他项目或工作的情况。
      • 13.3.7 卖方和合作伙伴
        • 通过合同为项目提供货物、服务或其他成果的人，就是卖方。对于需要开展采购工作的项目，卖方就是重要的项目相关方。
        • 合作伙伴与项目执行组织之间通常也有协议（不一定是严格的合同），但不是卖方与买方的关系。合作伙伴关系可能是通过某种认证过程建立的。
    • 13.4 各过程的输入与输出
      • 13.4.1 输入与输出的关系总览
        • 项目相关方管理的实现过程包括识别相关方、规划相关方参与、管理相关方参与和监督相关方参与。
      • 13.4.2 识别相关方
        • 首次开展识别相关方过程时，只有商业文件、项目章程和协议这三个输入。
          • 商业文件中的商业论证报告会提及一些重要相关方，效益管理计划也会提及一些重要相关方（如受益人）。
          • 项目章程已经列出一些重要相关方。
          • 无论是联合发起项目的合作协议，还是作为承发包合同的协议，与协议有关的各方都是项目相关方。
        • 重复开展本过程时，还需要项目管理计划中的沟通管理计划、相关方参与计划作为输入，以及项目文件中的需求文件、问题日志和变更日志作为输入。
          • 沟通管理计划所列的信息发送者和接收者都是项目的相关方
          • 相关方参与计划则规定了应该在何时如何重复开展相关方识别
          • 需求文件有助于识别与特定需求有关的相关方
          • 问题日志中所记录的问题可能引出新的相关方
          • 变更日志中的变更请求的提出和处理情况可能引出新的相关方
        • 识别出来的相关方及其信息，应写入相关方登记册。重复开展本过程，识别出新的相关方，就可能需要提出变更请求。
      • 13.4.3 规划相关方参与
        • 项目章程中关于项目目的、目标和成功标准的规定，有助于规划所需的相关方参与程度。相关方参与程度必须有利于项目成功。
        • 项目管理计划中的资源管理计划有助于规划该如何与项目团队成员打交道，沟通管理计划规定了与相关方沟通的方法，风险管理计划有助于确定相关方应该如何参与风险管理。
        • 以下项目文件也是本过程的输入：
          • 相关方登记册。提供了相关方的信息。
          • 假设日志。有助于识别与特定假设条件或制约因素有关的相关方。例如，某个假设条件需要由某个相关方去落实。
          • 项目进度计划。需要把某些相关方列作进度活动的负责人、执行人或支持者。
          • 风险登记册。需要把某些相关方列作各单个项目风险的责任人，也需要考虑将受风险影响的相关方。
          • 变更日志。重复开展本过程时，需要考虑与变更有关的相关方，如变更请求的提出者、将受变更影响者，考虑该如何让他们参与变更管理。
          • 问题日志。重复开展本过程时，需要根据问题日志考虑相关方应该如何参与识别、分析和解决问题。
        • 协议有助于规划如何引导与采购有关的相关方参与项目。
        • 本过程的输出是相关方参与计划，将成为项目管理计划的一部分。
      • 13.4.4 管理相关方参与
        • 项目管理计划中的以下组成部分是本过程的输入：
          • 相关方参与计划。根据该计划实实在在地与相关方打交道。
          • 沟通管理计划。沟通是与相关方打交道的一种重要手段。
          • 风险管理计划。引导相关方合理参与风险管理。
          • 变更管理计划。引导相关方合理参与变更管理。
        • 以下项目文件是本过程的输入：
          • 相关方登记册。可以从中了解该与哪些相关方打交道。
          • 变更日志。变更请求的提出和处理情况，都需要及时通知相关方。处理变更请求，也需要邀请相关方参与。
          • 问题日志。应该与相关方协作，有效解决问题日志中的问题。
          • 经验教训登记册。重复开展本过程时，需要参考以往的经验教训。
          • 本过程可能提出变更请求。
      • 13.4.5 监督相关方参与
        • 作为一个监控过程，需要把相关方参与的实际情况与计划要求做比较。实际情况体现在工作绩效数据和作为项目文件的项目沟通记录中。计划要求体现在项目管理计划的资源管理计划、沟通管理计划和相关方参与计划中。
        • 以下项目文件是本过程的输入：
          • 相关方登记册。有助于监督相关方的变化情况，如哪些相关方已经退出，哪些是新出现的。
          • 问题日志。有助于评价相关方参与的程度是否有效地促进了问题的解决。
          • 风险登记册。有助于监督与相关方参与程度有关的风险的发展趋势和应对情况。如果相关方参与程度不足，某些风险发生的可能性会显著提高，后果会显著加重。
          • 重复开展本过程时，应该参考已记录在经验教训登记册中的经验教训。
        • 相关方实际参与程度与计划要求的偏差，记录在工作绩效信息中。如果情况不理想，就提出变更请求。
    • 13.5 各过程的主要工作和成果
      • 项目相关方管理旨在弄清楚有哪些相关方及其基本情况，策划将如何引导他们参与项目，实际与他们打交道，监督相关方参与情况并提出变更请求。
      • 13.5.1 识别相关方
        • 本过程旨在全面识别项目相关方并对他们进行分析。需要特别注意以下几点：
          • 尽早识别相关方。之所以把本过程放在启动过程组，就是要强调尽早识别。越是在项目早期，相关方对项目的影响力就越大，就越可以用较低的代价去考虑相关方的要求。
          • 在整个项目生命周期中，要定期重新识别相关方。可以删去过时的相关方，增加新出现的相关方。
          • 全面识别相关方。相关方识别要尽可能全面，防止遗漏重要项目相关方。
          • 需要众多人的参与。识别相关方不只是项目经理或项目管理团队的事情，也应该鼓励其他相关方参与。项目经理和项目管理团队可以与已识别出的相关方一起，识别出更多的相关方。
        • 相关方识别应该尽早、尽量全面、定期重复开展，且需要众多人参与。
        • 当然，实际工作中可能面临这种情况：无论怎么强调要全面识别相关方，也总会有一些相关方不能被及时识别出来。这些相关方就是潜在相关方。
        • 不仅要了解相关方的基本情况，如名称、联系方式，而且要认真分析相关方对项目的要求与期望、可能对项目施加的影响、与哪个阶段的关系最密切；不仅要特别注意相关方对项目的不同甚至冲突的要求，还要根据相关标准，对相关方进行分类。这些内容都要写入相关方登记册。相关方登记册需要在整个项目生命周期中定期更新。
      • 13.5.2 规划相关方参与
        • 本过程旨在基于相关方识别和分析的结果，确定为取得项目成功所需要的相关方参与项目的程度，以及为此而应该采取的与相关方打交道的措施。更通俗地讲，就是要确定将如何与各种相关方打交道，如何引导他们合理参与项目。
        • 本过程编制的相关方参与计划，应该同时包括程序性计划和实体性计划的内容。其主要组成部分为：
          • 来自相关方登记册的内容。
          • 相关方现有的参与项目的程度，以及所需的参与项目的程度。
          • 为了获得所需的参与程度，应该采取的与相关方打交道的策略和措施。
          • 相关方参与计划与沟通管理计划的关系。
          • 应该如何更新相关方登记册和相关方参与计划。
      • 13.5.3 管理相关方参与
        • 本过程旨在根据相关方参与计划，通过沟通及其他方法，实实在在地与相关方打交道，引导相关方合理参与项目，并解决实际出现的相关方之间的问题，以便满足相关方的需要和期望。通过这个过程，把相关方实际参与项目的程度提高到项目经理期望的程度。
        • 在这个过程中，需要把项目团队中的问题、项目团队与其他相关方之间的问题以及其他相关方之间的问题记录下来，形成问题日志更新。在这个过程中，需要提出变更请求。变更请求可能包括对相关方参与计划的修改建议，以及对项目及其成果的修改建议（也许原来误解了相关方的需求，或者相关方的需求发生了变化）。
      • 13.5.4 监督相关方参与
        • 作为一个监控过程，本过程与其他基层监控过程类似。在本过程中，把相关方实际参与项目的程度和计划所要求的参与程度进行比较，发现并分析偏差，形成工作绩效信息，并提出变更请求。变更请求可以是要求修改相关方参与计划，也可以是要求采取纠正措施或预防措施。
    • 13.6 各过程的工具与技术
      • 13.6.1 识别相关方
        • 首先，进行数据收集。可以通过问卷和调查（如焦点小组讨论），请大家识别出各种相关方。也可以通过口头的头脑风暴或书面的头脑写作，请大家集思广益，识别出各种相关方。
          • 头脑写作是所有参加者围成一圈，同时分别在规定时间内写出尽可能多的相关方，再同时把自己的这张纸传给左手边的人；每个人再以上家所列的相关方作为启发，在收到的纸张上补充新的相关方。一直进行下去，直到每个人收回自己最初传出去的那张纸。然后，把所有纸张交给主持人，进行汇总分析，得出结论。
        • 其次，进行数据分析。先分析一些现有的文件（文件分析），从中识别出一些相关方。再开展相关方分析，分析他们的兴趣、利益、权力、知识和影响等。
        • 再次，用数据表现技术（相关方映射或展现）来呈现分析的结果。可以用权力利益方格、权力影响方格、影响作用方格来呈现分析结果。
        • 在方格中，可以把相关方分成不同的四个大类别，如权力大、利益大，权力大、利益小，权力小、利益大，权力小、利益小。其中的权力是指相关方有多大的职权对项目施加干预。影响是指相关方有多强的主观愿望对项目施加干预，而作用则是相关方施加干预后能在多大程度上促使项目计划或执行做出变更。
        • 可以用凸显模型来呈现分析结果。其中的三个维度是相关方施加影响的力量（能力）、紧急性和合法性。在这个模型中，把相关方分成七种不同类型，包括只与一个维度有关的自主型、潜伏型和苛求型，与两个维度有关的支配型、危险型和依赖型，与三个维度都有关的确定型。
        • 还可以用影响方向来呈现分析的结果，包括上级相关方、下级相关方、外部相关方和横向（同级）相关方。
        • 最后，应该基于相关方分析的结果，对相关方或相关方类别进行优先级排序（一种数据表现技术），以便重点抓排序靠前的相关方的管理。
      • 13.6.2 规划相关方参与
        • 除了专家判断和会议（相关方分析会），可以按如下顺序使用各种工具与技术。
        • （1）使用数据收集技术中的标杆对照，收集先进的、可作为标杆的相关方参与方式和程度，以及用于引导相关方参与的方法。
        • （2）使用数据分析技术中的假设条件和制约因素分析，来分析与相关方特定的参与方式或程度有关的假设条件和制约因素；使用其中的根本原因分析来分析导致相关方支持或抵制项目的根本原因。
        • （3）使用数据表现技术进行进一步分析，并呈现分析结构。其中的思维导图有助于分析某个相关方的多种信息之间的联系，也有助于分析不同相关方之间的联系。相关方参与度评估矩阵有助于分析相关方实际参与项目的程度以及所需的参与程度，直观地呈现两者之间的差距。相关方参与度可从低到高分为以下五种：
          • 无知型。包括根本不知道项目存在的相关方，以及虽然知道项目存在，但是不知道项目可能对自己有影响的相关方。
          • 抵制型。知道项目及其潜在影响，但是抵制项目。
          • 中立型。知道项目及其潜在影响，既不支持也不抵制项目。
          • 支持型。知道项目及其潜在影响，而且支持项目。
          • 领导型。知道项目及其潜在影响，而且特别支持项目。
        • 支持型相关方是仅仅自己支持项目。而领导型相关方则不仅自己支持项目，还鼓动（领导）别人一起来支持项目。
        • （4）基于上述结果，使用决策技术对相关方重新进行优先级排序或分级。
        • （5）基于分析和排序的结果，编制相关方参与计划，在其中规定将如何与相关方打交道，以便维护和提升相关方参与项目的程度。
      • 13.6.3 管理相关方参与
        • 本过程就是实际与相关方打交道，获得他们对项目的支持和参与。除了专家判断，其他工具与技术包括：
          • 召开各种类型的会议，与相关方实实在在地打交道。
          • 运用沟通技能，与相关方实实在在地打交道。
          • 运用人际关系与团队技能，与相关方实实在在地打交道。包括使用其中的政治意识和文化意识（必须了解政治和文化氛围）、观察和交谈（这是与相关方打交道的手段）、谈判（通过谈判与相关方达成协议）和冲突管理（及时解决相关方之间的冲突）。
          • 与相关方打交道时，必须遵守事先制定的基本规则（基本的行为规范）。
        • 如果相关方实际参与项目的程度已经达到所要求的程度，就要设法维护他们的参与程度。如果没有达到所要求的程度，就要把他们的参与程度引导到所要求的程度。当然，也必须防止相关方实际参与项目的程度出现下降。
        • 本过程可能提出“变更请求”。
      • 13.6.4 监督相关方参与
        • 本过程的工具与技术比较多，可以做如下概括：
          • （1）使用沟通技能和人际关系与团队技能来了解相关方实际参与项目的程度。沟通技能中包括向相关方演示项目情况，以及收集相关方的反馈意见。人际关系与团队技能中包括政治意识、文化意识、积极倾听、领导力和人际交往。
          • （2）使用数据分析技术中的相关方分析，来分析在特定的监控时点，相关方的实际参与情况，包括支持或抵制项目的程度。
          • （3）使用数据表现技术中的相关方参与度评估矩阵，来评价和呈现相关方实际参与项目的程度的动态变化情况，以便据此判断用于引导相关方的策略和措施的有效性。动态变化情况和措施的有效性，都应该写入“工作绩效信息”。
          • （4）使用数据分析技术中的根本原因分析，来分析相关方参与程度不理想的根本原因；使用其中的备选方案分析，来分析多种用于解决这种不理想状况的备选方案。
          • （5）使用决策技术（包括多标准决策分析、投票）来选择最好的解决方案，并据此提出“变更请求”。
  • 第14章 五大过程组的工作要点
    • 14.1 概述
      • 下文就结合《PMBOK®指南》和《PMP®考试大纲》，来讨论在每个项目管理过程组应该开展的主要工作。所讨论的每项工作都是PMP®考试中的必考知识点。在讨论时，采用了从全局到细节的方法，以及图示和文字解释相结合的方法。
    • 14.2 五大过程组之间的关系
      • 项目管理的五大过程组是启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组虽然有一定的先后顺序，但是又并非简单地以首尾相接方式严格按顺序开展。它们之间存在着用语言无法描述清楚的交叉和循环关系。任意两个过程组之间都可能严重交叉和反复循环。
      • 项目管理五大过程组之间的基本关系
      • 在《PMBOK®指南》中，总共有49个项目管理过程，隶属于项目管理五大过程组。其中，启动过程组有2个过程，规划过程组有24个过程，执行过程组有10个过程，监控过程组有12个过程，收尾过程组有1个过程。每个过程都要用特定的工具与技术，把特定的输入转化为特定的输出。
    • 14.3 启动过程组
      • 启动过程组的工作概览
      • 解释：
        • （1）项目发起人组织一个专家团队开展项目商业论证，编制出商业文件，其中包括商业论证报告和效益管理计划。
        • （2）在开展商业论证的同时或之后，发起人可以寻求其他组织来共同为项目出资。发起人和合作组织之间签署（合作）协议。
        • （3）发起人通过以上两个步骤落实好项目的可行性和资金（完成项目的前期准备工作）以后，就会物色一名候任的项目经理，项目就进入启动过程组，办理正式的立项手续。
        • （4）启动项目时，需要考虑事业环境因素，需要利用组织过程资产。
        • （5）启动过程组的最终成果是项目章程、假设日志和相关方登记册。
      • 根据发起人的授权，候任项目经理通过制定项目章程过程，编制项目章程并报发起人签发，同时需要编制假设日志。一旦发起人批准了项目章程，项目就正式启动（立项），项目经理也就正式上任，开始领导项目工作了。紧接着，项目经理要组织开展识别相关方过程，编制出相关方登记册。
      • 启动过程组的制定项目章程过程和识别相关方过程之间的基本关系
      • 启动过程组需要开展以下主要工作：
        • （1）基于事业环境因素、组织过程资产和项目的前期准备资料（包括商业论证、效益管理计划和协议），开展项目评估，来确认以前做出的关于项目可行性的商业论证结论仍然是合理可靠的。
        • （2）在开展项目评估时，应该广泛征求相关方的意见，并与重要相关方一起分析项目效益，确认项目仍然符合组织战略，能够为组织实现拟定的变革，创造预期的商业价值。
        • （3）明确为了实现变革和创造价值，项目必须在特定范围、进度、成本和质量要求下完成的关键可交付成果。这也有利于引导相关方（特别是客户）对项目抱有合理的期望。
        • （4）分析整体项目风险，确认整体项目风险水平是可接受的。
        • （5）分析项目合规性要求，制定项目合规目标。
        • （6）识别项目的单个项目风险类别、主要制约因素和主要假设条件。
        • （7）确定项目治理结构，组建项目治理委员会，并规定其权责。
        • （8）初选适用的项目开发方法（预测型、敏捷型或混合型）。
        • （9）提出项目执行的总体要求，如项目范围设计、里程碑进度计划、所需的财务资源估计。
        • （10）对前述所有工作的成果进行整理、分析和提炼，编制出项目章程和假设日志。在这个过程中，应该保持与相关方的良好沟通，以便大家对项目章程和假设日志的内容达成一致意见。
        • （11）获得发起人对项目章程的批准，以便项目正式立项，项目经理正式上任。
        • （12）向相关方分发（可召开项目启动会）已批准的项目章程，确保他们理解项目的意义和目标，以及各自的角色和职责。
        • （13）与已有的相关方一起，开展相关方识别和分析工作，编制出相关方登记册。
    • 14.4 规划过程组
      • 规划过程组的工作概览
      • 解释：
        • （1）根据在前期准备工作中形成的商业文件和（合作）协议，编制项目计划。
        • （2）根据项目章程和假设日志编制项目计划。
          • 既要把项目章程中的项目目标逐渐具体化、可操作化，又要设计出用于实现项目目标的、具体的项目执行、监控和收尾方法。
          • 编制计划时，既需要考虑假设日志中已有的假设条件和制约因素，又需要把相关假设条件和制约因素逐渐细化。
        • （3）在编制项目计划的过程中，应该根据相关方登记册，邀请尽可能多的相关方参与，以便提高项目计划的质量，并使相关方对项目计划有强烈的主人翁感。
        • （4）在编制计划时，需要考虑事业环境因素，需要利用组织过程资产。
        • （5）项目计划由项目管理计划、项目文件（仅限各规划过程编制的各种文件）、项目资金需求，以及采购文档（仅限规划采购管理过程编制的与采购有关的计划）构成。
      • 规划过程组共有24个项目管理过程。由于项目计划的编制不可能一蹴而就，需要反复循环，因此这24个过程之间的关系非常复杂。不仅如此，各种执行过程和监控过程还会导致项目计划更新，包括项目管理计划更新、项目文件更新和采购文档
      • 不考虑可能的循环和更新，这24个过程之间的基本关系
      • 解释：
        • （1）通过各规划××管理（或参与）过程，编制各种分项管理（或参与）计划。
        • （2）通过制订项目管理计划过程，把全部分项管理（或参与）计划整合成项目管理计划。
        • （3）根据项目管理计划，开展后续的全部规划过程，编制项目计划。
        • （4）通过收集需求、定义范围和创建WBS过程，编制范围计划。
        • （5）根据范围计划中的范围基准，通过规划质量管理过程，确定各种项目工作和可交付成果的质量测量指标。
        • （6）根据范围计划中的范围基准，通过规划采购管理过程，确定哪些项目工作和可交付成果需要外包出去，并编制相应的采购计划（如招标文件）。
        • （7）通过定义活动过程，把范围基准中的工作包分解成进度活动；通过排列活动顺序过程编制项目进度网络图；根据估算活动资源过程所得到的资源需求，通过估算活动持续过程估算活动持续时间；通过制订进度计划过程，把前述成果整合成项目进度计划。
        • （8）根据资源需求和项目进度计划，通过估算成本过程估算活动成本；通过制定预算过程把各活动的成本汇总成项目预算（成本计划）。
        • （9）编制出初步的范围、进度、成本、质量和采购计划之后，通过识别风险、实施定性风险分析、实施定量风险分析和规划风险应对过程，来考虑与初步计划有关的风险；然后，根据风险情况，回头调整初步计划。可能要经过多次调整，才能得到可行的项目计划。
        • （10）高层级的项目计划是范围基准、进度基准和成本基准，需要被汇编进项目管理计划。低层级的项目计划则作为项目文件或采购文档而存在。项目资金需求，因为主要供项目发起人为项目按时按量提供资金，而非供项目团队使用，所以不归入项目文件，而是独立存在的。
      • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，规划过程组需要开展以下主要工作：
        • （1）通过规划××管理（或参与）过程，编制需求管理计划、范围管理计划、进度管理计划、成本管理计划、质量管理计划、风险管理计划、资源管理计划、沟通管理计划、采购管理计划和相关方参与计划。
        • （2）通过制订项目管理计划过程，编制变更管理计划和配置管理计划，确定项目开发方法和项目生命周期类型。
        • （3）根据需求管理计划和范围管理计划，编制范围目标计划，包括项目范围说明书、工作分解结构和WBS词典。
        • （4）根据资源管理计划、范围目标计划以及其他相关信息，估算活动和项目所需的资源，得到资源需求。
        • （5）根据进度管理计划、范围目标计划和资源需求，编制进度目标计划，包括里程碑进度计划、汇总进度计划和详细进度计划，以及相应的支持材料。
        • （6）根据成本管理计划、范围目标计划、进度目标计划和资源需求，编制成本目标计划，包括成本估算、项目预算和项目资金需求。
        • （7）根据质量管理计划、范围目标计划、进度目标计划和成本目标计划，编制质量目标计划，即质量测量指标。
        • （8）根据范围管理计划、质量管理计划、资源管理计划，以及范围、进度、成本和质量目标计划，编制采购计划，包括采购策略、采购工作说明书、招标文件和供方选择标准等。
        • （9）根据风险管理计划、其他各种管理计划和其他相关信息，对已编制出的范围、进度、成本和质量目标计划，以及采购计划，进行风险识别和分析，并制定风险应对措施。
        • （10）根据风险识别、分析和应对措施制定的结果，回头调整范围、进度、成本和质量目标计划，以及采购计划。
        • （11）根据需要，反复开展上述第3步至第10步，直到得到现实可行、令人满意的范围、进度、成本和质量目标计划，以及采购计划和风险计划（风险登记册）。
        • （12）把最终的项目范围说明书、工作分解结构和WBS词典汇编在一起报领导和主要相关方批准，得到范围基准。把最终的里程碑进度计划和汇总进度计划，报领导和其他主要相关方批准，得到进度基准。把最终的项目预算报领导和其他主要相关方批准，得到成本基准。
        • （13）把所有的分项管理计划和分项基准汇编在一起，形成项目管理计划，并报领导和其他主要相关方批准。把其他不属于项目管理计划的组成部分的内容（项目资金需求除外），归入“项目文件”或“采购文档”。
        • （14）把项目资金需求报给项目发起人，以便他据此准备和提供资金。
        • （15）召集项目开工会议，向相关方介绍项目计划和项目目标，获得相关方对项目的支持和参与，宣布项目正式进入执行阶段。
      • 在编制计划的过程中，要留意并考虑项目执行组织内外部的商业环境的动态变化，考虑如何确保项目合规、如何确保项目能够实现组织变革和创造商业价值。
    • 14.5 执行过程组
      • 执行过程组的工作概览
      • 解释：
        • （1）根据项目管理计划（高层级项目计划）、项目文件（低层级项目计划）和采购文档（采购计划）开展项目执行。其中，采购文档是签署协议（合同）的主要依据。
        • （2）一边执行，一边收集工作绩效数据。
        • （3）通过切实的执行，做出所要求的可交付成果。
        • （4）根据来自监控过程的质量控制测量结果及其他相关信息，编制质量报告。
        • （5）在执行中，及时总结和记录经验教训，形成经验教训登记册。
        • （6）在执行中，可能发现项目计划需要修改，并提出变更请求。
        • （7）经监控过程更新的风险登记册、风险报告和经验教训登记册，以及监控过程编制的工作绩效报告，需要反馈给执行过程组。
        • （8）监控过程得到的“批准的变更请求”需要交给执行过程组执行。
      • 执行过程组共有10个项目管理过程，这些过程的开展并没有严格的先后顺序，通常都是交叉在一起开展的，无法截然分开。它们之间的基本关系。如图
      • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，执行过程组需要开展以下主要工作：
        • （1）按照资源管理计划，从项目执行组织内部获取项目所需的团队资源和实物资源。
        • （2）对于团队资源，组建、建设和管理团队。对于实物资源，在正确的时间分配到正确的工作上。
        • （3）按照采购计划，开展采购工作，从项目执行组织外部获取项目所需的资源、产品或服务。
        • （4）领导团队按计划执行项目工作，随时收集能够真实反映执行情况的工作绩效数据，并完成符合范围、进度、成本和质量要求的可交付成果。
        • （5）开展管理质量过程，有效执行质量管理体系。
        • （6）执行经批准的变更请求，包括纠正措施、缺陷补救措施和预防措施。
        • （7）执行经批准的风险应对策略和措施，来降低威胁对项目的影响，提升机会对项目的影响。
        • （8）执行沟通管理计划，管理项目信息的流动，确保相关方了解项目情况。
        • （9）执行相关方参与计划，维护与相关方的关系，引导相关方对项目抱有合理期望并积极参与和支持项目。
        • （10）开展管理项目知识过程，利用现有知识，形成新知识，进行知识分享和知识转移，以便促进本项目顺利实施，以及项目执行组织发展。
        • （11）对项目团队成员和项目相关方进行培训、教练和辅导，以便他们能够更好地参与项目。
    • 14.6 监控过程组
      • 监控过程组的工作概览
      • 解释：
        • （1）监控就是把执行情况与计划要求相比较，发现偏差。所以，监控过程组的输入，既有来自规划过程组的成果，也有来自执行过程组的成果。前者包括项目管理计划、项目文件和采购文档；后者包括工作绩效数据、可交付成果、质量报告、协议、经验教训登记册和变更请求。
        • （2）把偏差记录下来，形成工作绩效信息、质量控制测量结果和工作绩效报告。因为工作绩效信息仅供监控过程组内部使用，所以没有出现在本图中。
        • （3）如果偏差超出了可接受的区间（控制临界值），就需要提出变更请求并进行审批。监控过程组提出的变更请求，需要在本过程组审批，故没有作为输出出现在本图中。
        • （4）及时审批变更请求，得到批准的变更请求。
        • （5）及时检查已完成的可交付成果是否符合质量要求和验收标准。如果符合，就得到验收的可交付成果；如果不符合，就提出变更请求。
        • （6）根据在监控中发现的问题，及时更新风险登记册、风险报告和经验教训登记册。
      • 监控过程组共有12个项目管理过程。项目整合管理知识领域的2个监控过程都是整个项目层面的全局监控过程，其中的实施整体变更控制过程专用于审批变更请求。后九大知识领域的全部10个监控过程都是基层的局部监控过程。需要注意的是，监督风险过程既包括基层的局部监控（用“工作绩效数据”作为输入，监督单个项目风险），也包括整个项目层面的全局监控（用“工作绩效报告”作为输入，监督整体项目风险）。监控过程组的各过程之间的基本关系
      • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，监控过程组需要开展以下主要工作：
        • （1）把执行情况与计划要求相比较，考核项目绩效（包括范围、进度、成本和质量绩效），识别和量化绩效偏差。
        • （2）分析偏差的程度和原因，并预测未来绩效。
        • （3）基于分析和预测的结果（如果超出了控制临界值），提出变更请求，包括纠正措施建议、缺陷补救措施建议、计划修改建议和预防措施建议。
        • （4）根据变更管理计划的规定，对变更请求进行综合评审，做出批准、否决或悬置的决定。
        • （5）除了为实现项目的既定目标而管理项目变更，还要从确保项目继续符合商业需求的高度来管理项目变更，提出修改项目目标的变更请求，并报变更控制委员会或发起人审批。
        • （6）及时审阅和处理随同项目执行而记录在问题日志中的各种问题，最小化这些问题对项目的不利影响。
        • （7）及时检查已完成的可交付成果的质量，并及时验收质量合格的可交付成果，确保项目可交付成果能够满足项目要求，实现组织变革和创造商业价值。
        • （8）监控团队成员和相关方对项目的参与情况，确保有利于项目成功。
        • （9）监控项目采购活动，确保采购工作有利于项目目标的实现。
        • （10）既要监控单个项目风险的情况，又要监控整体项目风险的情况，还要监控风险管理工作的有效性，以便降低对实现项目目标的威胁，提高对实现项目目标的机会。
        • （11）不断总结经验教训，以便持续改进。
    • 14.7 收尾过程组
      • 收尾过程组的工作概览
      • 解释：
        • （1）根据项目章程和项目管理计划，把已经通过实质性验收的可交付成果移交给项目发起人或他所指定的其他人。
        • （2）根据采购文档和协议（合同），确认项目上的所有合同都已经妥善关闭。
        • （3）根据图中的所有输入，总结经验教训，编写最终项目报告，更新组织过程资产。
        • （4）图中的“协议”，既可以是买卖方的合同，也可以是项目发起人之间关于联合出资的合作协议。
      • 《PMBOK®指南》中只有一个收尾过程，即结束项目或阶段。之所以仍然称“过程组”，是因为在实际项目工作中，项目经理可以添加所需的其他过程。
      • 《PMBOK®指南》对收尾过程组写得很简单。其总体思想是：收尾过程组不是用来解决问题的，而只是用来关闭项目或阶段并更新组织过程资产的。项目中的所有问题都必须在监控过程组发现并提出解决建议，然后通过规划过程组和执行过程组加以解决。所有问题都不能带到收尾过程组。
      • 综合《PMBOK®指南》和《PMP®考试大纲》的内容，收尾过程组需要开展以下主要工作：
        • （1）确认所有的项目合同都已经妥善关闭，没有未解决问题。
        • （2）获得主要相关方对项目可交付成果的最终验收，确保项目目标已经实现。注意：这里的验收只是形式上的验收，而不是实质性的技术验收。实质性的技术验收早就在“确认范围过程”中完成了。
        • （3）把项目可交付成果移交给指定的相关方，如发起人或客户。这件工作经常可以与最终验收同时开展。
        • （4）编制和分发最终的项目绩效报告。这份报告既有利于相关方了解项目的最终绩效，又可以成为开展项目后评价的重要依据。
        • （5）收集、整理并归档项目资料，更新组织过程资产。这是为了保留项目记录，遵守相关法律法规，供后续审计（如果需要开展）使用，以及供以后项目借鉴。
        • （6）收集各主要相关方对项目的反馈意见，调查他们的满意度。
        • （7）评估项目合规性、实现组织变革和创造商业价值的情况。
        • （8）全面开展项目后评价，总结经验教训，更新组织过程资产。
        • （9）开展知识分享和知识转移，为在后续的项目成果运营中实现商业价值提供支持。
        • （10）开展财务、法律和行政收尾，宣布项目正式关闭，把对项目可交付成果的照管和使用责任转移给指定的相关方，如发起人或客户。
  • 第15章 敏捷型项目管理方法
    • 15.1 概述
      • 所谓“敏捷”，就是主动且快速地应对甚至引领变化。敏捷型（也称适应型）项目管理方法是指采用迭代和增量的方式开发项目产品，适用于需求不明确或很容易变化且产品可以一部分一部分交付的项目（不是只能一次性完整地交付）。这种项目适合采用敏捷型开发方法（也称适应型开发方法）。
      • 《PMP®考试大纲》指出，PMP®考试中，大约一半题目考预测型项目管理方法，另一半考敏捷型或混合型项目管理方法。因为PMI另外有一个专门的敏捷项目管理师资格认证，所以PMP®考试中的敏捷型方法应该不会太深太细，而主要涉及基本概念、基本方法和基本理念。
      • PMP®考试兼考预测型、敏捷型和混合型项目管理方法。
    • 15.2 项目开发方法的种类
      • 以预测型方法为一端，敏捷型方法为另一端，构成了项目开发方法的连续区间。中间则是迭代型方法、增量型方法和混合型方法。
      • 预测型方法，也称计划驱动型方法，是指先编制出完善的项目计划，再严格照计划执行（基本无须变更）去实现目标。预测型方法相当于“想好了再做”，旨在严格按计划执行，打中静态的目标。
      • 敏捷型方法，也称变更驱动型方法，是指先编制出简略的方向性计划，再按较短时间段逐一编制和执行阶段计划（便于及时变更）去实现目标。它是迭代型方法和增量型方法的综合。敏捷型方法相当于“一边做一边变”，旨在通过不断调整，打中动态的目标。
      • “敏捷型方法”这个词，也可兼指迭代型方法或增量型方法。
        • 迭代型方法是指通过多次短期迭代（循环）来不断优化同一个或同一系列产品功能。
        • 增量型方法是指通过多次短期迭代来逐渐增加新的产品功能。在形成最终产品之前，每次迭代所得到的初级产品都叫“原型”。
      • 混合型方法则是预测型方法和敏捷型方法的混合，例如，在项目的某个阶段或某个部分用预测型方法，而在另一阶段或另一部分用敏捷型方法；对整个项目用预测型方法，而对其中的产品开发部分用敏捷型方法。
      • 所用的项目开发方法决定了项目开发生命周期的类型，也就决定了项目生命周期的类型。开发生命周期只针对产品开发，而项目生命周期的覆盖面更宽，覆盖全部的项目工作。采用预测型开发方法的项目，其开发生命周期和项目生命周期也就都是预测型的。其他方法依此类推。
    • 15.3 项目开发方法的选择
      • 选择项目开发方法，要考虑的主要因素包括：
        • 项目相关方（特别是发起人和客户）对价值实现的紧迫性。
          • 越要快速实现价值，就越要采用迭代型、增量型或敏捷型方法。采用预测型方法，是等到项目全部完成时才一次性实现价值。采用其他方法，都是分阶段或分模块来分批实现价值。
        • 项目需求的明确程度。
          • 项目需求越不明确，越易变，就越要采用迭代型、增量型或敏捷型方法。
        • 项目的复杂程度，包括技术的不确定性和项目的可分性。
          • 技术越不确定，可分性（可以分阶段或分模块开发）越高，越需要创新，就越要采用迭代型、增量型或敏捷型方法。敏捷型方法的最根本的基础就是项目产品开发的可分性。因为IT软件开发项目具有很高的可分性，所以敏捷型方法发源于这类项目。
      • 仅从项目需求和技术这两个方面来看：
        • 需求明确且技术确定，就用预测型方法。例如，普通的房屋建设项目。
        • 需求明确但技术不确定，就用迭代型方法。例如，研发治疗某种特定疾病的药物。
        • 需求模糊但技术确定，就用增量型方法。例如，公司网站建设项目。
        • 需求模糊且技术不确定，就用敏捷型方法。例如，研发可同时治疗多种疾病的药物。
      • 敏捷型方法所包含的快速应对甚至引领变化的思想、观念和技术，具有广泛的适用性，从而使它不同程度地适用于几乎所有行业的所有项目。即便传统的建设工程项目，也可以在局部应用敏捷型方法，更可以在整个项目上采用一些敏捷观念。可以说，混合型方法的应用将越来越普遍。
      • 采用敏捷型方法，对项目所在组织、项目客户和项目团队也有相应的要求。
      • 选择项目开发方法，需要考虑项目本身、所在组织和项目团队的情况。
    • 15.4 不同开发方法下的生命周期
      • 预测型生命周期的每个阶段的工作不同，阶段成果不供客户使用。项目阶段通常首尾相接，有时也可部分并行。
      • 迭代型生命周期的每个阶段（迭代期）的工作相同，通过各阶段把同样的功能做得越来越精致，阶段成果（产品原型）通常不供客户使用（也可应客户要求，把原型交付其使用）。
      • 增量型生命周期的每个阶段（迭代期）的工作不同，通过各阶段逐渐增加产品功能，阶段成果（产品原型）可供客户使用。
      • 敏捷型生命周期，是迭代型和增量型的综合，通过各阶段（迭代期）在优化同样功能的同时新增其他功能，阶段成果（产品原型）可供客户使用。图
      • 是迭代型、增量型和敏捷型生命周期示例
      • 迭代型生命周期中的原型通常不供客户使用，仅供项目团队内部评审；而增量型生命周期中的原型通常要交付客户使用。
    • 15.5 敏捷型方法下的人员管理
      • 15.5.1 项目经理
        • “引导者（Facilitator）”“教练（coach）”或“敏捷大师（Scrum Master）”。项目经理应该：
          • 在更大程度上是一个领导者，而不是一个管理者。对于团队成员，他应该主要进行启发与激励，而不是约束与控制。
          • 关注创建和维护合作式团队氛围，以及提升整个团队的工作能力，同时把具体的项目工作授权给自组织的项目团队去负责。
          • 主要采用仆人式领导风格，通过服务团队成员来启发和激励他们，帮助他们进步和成长。
          • 在项目执行之前，对项目团队和客户进行敏捷方法培训，让他们了解和掌握敏捷方法和观念。
          • 与团队成员一起识别和分析团队障碍物（impediment）或阻碍物（blocker），进行优先级排序，采取措施加以缓解或消除，并评价和确认缓解或消除的效果。障碍物会减慢团队的工作进程，阻碍物则会使项目工作完全停滞不前。这两个词也经常等同使用。
      • 15.5.2 项目团队
        • 在敏捷型方法下，项目团队需要这三种基本角色：
          • 团队引导者（Team Facilitator，相当于项目经理）
          • 产品负责人（Product Owner，充当客户代表）
          • 跨职能团队成员（Cross-functional Team Members）
        • 在敏捷方法下，项目团队应该具有自我组织、自我管理和自我决策的能力，团队成员合作解决问题。采用敏捷方法，对团队成员的自觉性和工作能力都有很高的要求。
          • 项目团队应该是小规模全功能的，即人数少（5～9人最为合适），能做所有事情。这就要求每一位成员都是多面手，即通用的专才，而不是只懂某一个领域的主题专家。
          • 在每个项目阶段（迭代期）都需要全部工种人员，如分析人员、设计人员、建造人员和测试人员，而不是不同阶段需要不同工种人员。
          • 团队成员在充分透明和合作的团队氛围中快速创造、利用和解决冲突，快速达成共识。可以说，无冲突就无敏捷、无创新。
        • 创造和利用冲突，是敏捷型方法的一大特点。
        • 团队成员具有充分的包容性，采用协作式工作方式。每个成员都能充分包容不同专业、不同背景的成员，善于与他们协作。要防止歧视与自己不同的成员，防止各专业或小组各自为政，防止形成“组织独奏（Organizational Solo）”。
        • 团队成员开展及时且充分的沟通。敏捷团队会借助各种技术来辅助沟通，例如：
          • 迭代规划会议（Sprint Planning）。
            • 也可称冲刺规划会议，因为一次冲刺也就是一次迭代。这是在每个迭代期开始之初的规划会议，会形成本迭代期的迭代任务单（SprintBacklog）。
          • 每日站立会议（Daily Standups）。
            • 在每天早上上班时召开，时间10～15分钟，交流昨天做了什么、今天要做什么以及有什么困难。
          • 看板（Kanban）。
            • 看板源自丰田生产方式（精益生产方式），是指在实体板或电子板上记录有待开始、正在进行和已经完成的工作等信息。
          • 迭代评审会议（Sprint Review）。
            • 在当前迭代期结束时向产品负责人（客户）展示成果，并收集反馈意见。
          • 迭代回顾会议（Sprint Retrospective）。
            • 项目团队在迭代期结束或其他必要时间对开发过程进行总结回顾，以便后续改进。
          • 产品未完项（Product Backlog）。
            • 按优先级罗列有待完成的产品功能（用户故事）。
          • 迭代任务单（Sprint Backlog）。
            • 对产品未完项中的用户故事再分解，列出为实现某个用户故事而需要开展的具体任务及其时间要求。
          • 信息发射源（Information Radiator）。
            • 在任何人都可以看见的公共地方用简洁易懂的方式显示项目信息，如用于显示项目进展情况的迭代燃尽图或燃烧图。
        • 在敏捷型方法下，项目团队尽量面对面集中办公，而不是以虚拟团队或分散式团队（成员在不同地点）远程办公，因为远程办公远不如面对面那样有创造性。如果不得不采用虚拟团队或分散式团队，则对团队建设会有更高的要求。
      • 15.5.3 项目相关方
        • 在敏捷型方法下，项目相关方（特别是客户）应该：
          • 在整个项目期间都频繁且深入地参与项目，包括及时提出需求、参与讨论、使用（评审）原型和提供反馈等。
          • 派代表参加项目团队，作为团队的一员参与项目工作。该成员通常是产品负责人。
          • 平等地对待项目团队及其成员。客户不能认为“项目是我出的钱，所以项目团队应该听我的”，否则，就会严重妨碍团队的创造力，使敏捷型方法完全失败。
          • 接受和配合项目团队对自己的相关培训、教练和辅导，以便更加了解敏捷型方法和项目情况，更好地参与项目工作。
        • 在敏捷型方法下，项目团队成员是自觉性高且能力很强的主人，项目经理是为成员提供服务的忠实仆人，客户则是团队成员和项目经理的有力支持者和配合者。
    • 15.6 敏捷型方法下的五大过程组
      • 无论采用什么项目开发方法，项目管理五大过程组都是适用的。在产品开发采用敏捷型方法的情况下，对整个项目的管理仍然要按项目管理五大过程组来启动、规划、执行、监控和收尾。没有任何一个项目可以不用项目管理五大过程组加以管理。
      • 在敏捷型方法下，项目管理五大过程组的应用要比预测型方法下更加灵活，例如：
        • 项目启动过程组和规划过程组都应更快速地迭代开展，而不是用较长时间一次就做到足够深入和详细的程度。
        • 五大过程组的交叉和循环更加明显，界线更加模糊，特别是规划、执行和监控过程组之间。
        • 每个迭代期结束时都要通过收尾过程组来开展原型评审和回顾总结，为下一个迭代期做好准备。
      • 严格地讲，任何应变领变都离不开一定的规矩。所以，任何项目在整个项目的层面上，都必须用预测型方法按五大过程组加以管理，没有任何项目能够百分之百地用敏捷型方法加以管理。
    • 15.7 敏捷型方法下的项目目标管理
      • 因为项目目标是用范围、进度、成本和质量来表示的，而风险则是万一发生会对其中的至少一个方面产生影响的不确定性事件，所以下面将讨论敏捷型方法下的项目范围管理、进度管理、成本管理、质量管理和风险管理。因为目标往往并非一成不变，所以还会讨论敏捷型方法下的项目变更管理。
      • 15.7.1 项目范围管理
        • 在预测型方法下，先确定项目范围目标，再确定项目进度、成本和质量；而在敏捷型方法下，则先确定项目进度目标（例如，新产品的上市日期），再确定范围、成本和质量。前者根据要做的事情来确定需要多长时间，后者根据固定的时间来确定能做多少事情。
        • 在敏捷型方法下，项目需求和范围并非一开始就全部明确，而是随项目进展，在每个迭代期逐渐明确。通常，项目需求和范围在一个迭代期内保持不变，但在两个迭代期之间有所变化。为了快速实现价值，在每个迭代期结束时，都要交付出供评审且可使用的产品原型。在设计项目范围时，应该先找出最初的产品原型，即最小可用产品（Minimum Viable Product），然后考虑在后续的迭代开发中不断增加产品功能。
        • 在敏捷型方法下，用“用户故事（User Story）”表示产品功能，一个用户故事代表一个功能。用户故事通常由三部分组成：用户，想要什么，为何想要。一系列待完成的用户故事则构成产品未完项。产品未完项中的用户故事有优先级排序，并且在每个迭代期开始时都要重新进行排序。必须最先开发出最重要（最有价值）的产品功能，再开发出第二重要的功能，以此类推。这样一来，即便第一个迭代期结束时项目就被迫终止，项目也在一定程度上是成功的，因为已经开发出最重要的功能。
        • 在敏捷型方法下，工作分解结构（WBS）的第二层通常为开发迭代期或产品版本号。在最终产品交付之前，每一个产品版本都是精致或完善程度不同的产品原型。
        • 在敏捷型方法下，在每个迭代期中，由项目团队自行开展《PMBOK®指南》中的控制范围过程；在每个迭代期结束时，项目团队与客户一起开展《PMBOK®指南》中的确认范围过程，对成果按照事先确定的“完成定义（Definition ofDone）”进行实质性评审和验收。“完成定义”用于规定成果必须满足哪些条件才能供客户使用。
      • 15.7.2 项目进度管理
        • 如前所述，在敏捷型方法下，先确定进度目标。固定的项目工期，又要被划分为时间很短且通常长度相同的多个迭代期（短至几天，长至一个月）。每个迭代期都是一个固定的、绝不能突破的“时间盒（Time Box）”。之所以要规定时间盒，是为了促使人们集中精力于最重要的少数工作，按规定时间开发出既定的功能，即通过小批量工作快速交付原型。
        • 在敏捷型方法下，用于估算所需努力程度（人力投入量）的相对最小单位是“故事点（Story Point）”。在同一个项目中，每个故事点所需的人力投入量（工时数）是相等的。在不同的项目上，则不一定相等。应该为每个用户故事估算所需的故事点，以此作为进度管理的依据。
        • 在敏捷型方法下，项目进度计划通常包括版本进度计划、发布进度计划和迭代进度计划，分别对应预测型方法下的里程碑进度计划、汇总进度计划和详细进度计划。在版本进度计划中，规定每个版本（原型）的发布时间。在发布进度计划中，规定每个版本的发布需要完成的迭代次数和时间。在迭代进度计划中，则规定在一个迭代期内所需实现的用户故事及其时间要求。迭代进度计划在每个迭代期开始时编制。
        • 敏捷型方法下的项目进度管理，应该始终贯彻“持续集成”和“持续交付”的理念。持续集成是指要经常对团队成员的工作成果进行整合（集成）和确认，持续交付是指以小步快跑的增量方式频繁地向客户交付可用的产品功能。
      • 15.7.3 项目成本管理
        • 在敏捷型方法下，因为项目需求和范围并非一开始就明确，所以无法一开始就制定较准确的项目预算。起初，只能采用轻量级估算方法来制定粗略的项目预算（留出较充分的余地），以后再随需求和范围的逐渐明确来编制详细的迭代期预算。
        • 迭代期预算的编制通常采用增量预算的方法而非零基预算的方法，即以前一个迭代期的成本为基础，经过适当调整，编制出下一个迭代期的预算。零基预算则完全不考虑过去的成本情况而编制全新的预算。
        • 敏捷型方法其实是精益思想的一种应用。精益思想中的核心观念，如关注价值、小批量生产和消除浪费，也都体现在敏捷型方法中。因此，在敏捷型方法中，对资源供应就特别强调采用“准时制”，即需要时立即送来，以消除资源的库存成本和资源的过量储备。
      • 15.7.4 项目质量管理
        • 无论用预测型还是敏捷型方法，质量都必须合格。敏捷型方法下的项目质量管理有如下几个特点：
          • 为了保证质量，可以在早期进行小批量试开发，以发现和解决质量问题，为后续大批量开发做好准备。
          • 在开发过程中，由团队成员随同开发执行，自行进行更频繁的质量检查。
          • 在每个迭代期结束时，都要通过迭代评审会议向客户展示成果，由客户评审质量是否符合要求。
          • 在每个迭代期结束后，都要通过回顾会议来总结经验教训，引导下一个迭代期的质量改进。因为迭代期的时间较短，迭代期的数量较多，所以在整个项目期间较易开展持续改进。
        • 敏捷型方法下的三重制约是确定的进度、估算的范围、合格的质量和估算的成本，不同于预测型方法下的确定的范围、合格的质量、估算的进度和估算的成本。
      • 15.7.5 项目风险管理
        • 敏捷项目的需求、范围和技术的不确定性更大，相应的风险（包括机会和威胁）也就更大。应该在每个迭代期内识别、分析和管理风险，确保开发出所需的原型。原型开发出来之后，要立即交付给客户进行使用和评审，客户要尽快提出相应的反馈意见，作为开展下一次迭代的依据之一。
        • 应该通过迭代来探索正确的技术，降低项目的技术风险（威胁）。例如，要研发某种特定疾病的治疗药物，因为用于实现治疗功能的技术手段很难确定，所以只能通过迭代去探索。应该通过增量来引导客户的需求，降低项目的需求和范围风险（威胁）。
        • 敏捷型方法中的以下做法都有利于做好风险管理：
          • 不断对需求重新排序。
          • 快速和频繁交付原型供评审。
          • 反馈路径快速和短周期。
          • 随迭代的进行不断持续改进。
      • 15.7.6 项目变更管理
        • 在敏捷型方法下，因为一次只针对当前迭代期编制计划，以及文档尽可能量少而实用，所以针对既定计划进行的变更数量较少。不过，基于对前一个迭代期的经验教训总结，以及对所开发的原型的评审而提出的工作过程变更和需求变更数量较多。从这两类变更来讲，敏捷型方法要求人们拥抱变更，把变更看成提升项目价值的机会。正如《敏捷宣言》中所说的“响应变化高于遵循计划”，以及敏捷原则中所说的“欢迎对需求进行变更，即便是在项目开发后期”。
        • 工作过程或需求变更尽可能在两个迭代期之间进行，而不是在一个迭代期内进行。例如，在第一个迭代期结束后，客户提出了四项需求（功能）变更申请。经过评审，其中的两项被批准了。接着，就要把这两项变更与原有产品未完项中的全部用户故事放在一起，重新进行优先级排序，得到变更后的产品未完项，作为下一个迭代期的工作依据。
        • 敏捷型方法要求基于价值来开展变更管理。一项变更能否被批准，取决于它能否为客户创造出应有的价值。
    • 15.8 敏捷型方法下的项目采购管理
      • 在敏捷型方法下开展项目采购管理，应该遵守《敏捷宣言》所述的“客户合作优先于合同谈判”，即合同谈判固然重要，与客户的合作却更加重要。这就要求，买方与卖方之间有更好的合作，有更加合理的风险分担。
      • 因为敏捷项目具有需求不明、需求易变和技术易变的特点，所以无法一开始就编制出详细准确的采购工作说明书，而只能编制出轻量级（简略）的采购工作说明书。鉴于此，在敏捷型方法下，往往：
        • 采用多层次合同。多层次合同由主体协议和扩展协议组成。把确定的内容放入主体协议，把不确定的、易变的内容放入扩展协议。起初，双方可以只签主体协议。随后，再签也许不止一份扩展协议。
        • 实行固定价格增量采购。按每个用户故事来确定固定价格，每增加一个用户故事就相应增加合同价格。
        • 买卖双方联合组建团队。按团队工作时间付费，而不是按工作内容付费。
        • 允许取消后续工作。例如，某病原计划治疗三个疗程，却两个疗程就治好了，那么就允许买方（病人）在向卖方（医生）支付一定费用的情况下取消第三个疗程。买方支付的费用应该确保卖方不因第三个疗程的取消而遭受经济损失。
        • 实行分阶段采购。一次只签一个阶段的合同。随着情况明朗，逐期签订后续阶段的合同。
        • 越需要敏捷的项目，就越不能把合同签死，越不能采用固定总价合同。
    • 15.9 敏捷宣言和敏捷原则
      • 敏捷型方法发源于20世纪90年代的IT软件开发行业。2001年2月，软件开发业的17位领导者在美国犹他州聚会，发布了《软件开发敏捷宣言》（Manifesto for Agile SoftwareDevelopment）（简称《敏捷宣言》）。
      • 《敏捷宣言》所推崇的四大价值观是：
        • 个人和互动优先于流程和工具。
        • 可用的软件优先于详尽的文档。
        • 客户合作优先于合同谈判。
        • 响应变化优先于遵循计划。
      • 从《敏捷宣言》派生出的12条敏捷原则是：
        • （1）我们的最高目标是，以尽早和持续地交付有价值的软件来满足客户。
        • （2）欢迎对需求进行变更，即便是在项目开发后期。我们利用需求变更来为客户建立竞争优势。
        • （3）频繁交付可用的软件，周期从几周到几个月不等，且越短越好。
        • （4）在整个项目期间，商务人员和开发人员必须每天都紧密合作。
        • （5）由被激励的个体去完成项目。为他们提供所需的环境和支持，并相信他们能够完成项目。
        • （6）无论在开发团队内部还是向开发团队传递信息，最有效率和效果的沟通方式都是面对面交谈。
        • （7）可用的软件是衡量进度的主要指标。
        • （8）敏捷过程提倡可持续开发。发起人、开发者和用户应该始终保持稳定的步调。
        • （9）通过持续关注技术卓越和设计精良来提升敏捷性。
        • （10）追求简化，即尽量减少不必要的工作。
        • （11）最好的架构、需求和设计出自自组织团队。
        • （12）团队要定期反省如何更加有效，并相应调整团队的行为。
• 做题套路
  • 情景题固定套路
    • 变更批准之后 ：变更批准后要做三件事
      • 在变更日志中记录
      • 通知相关干系人
      • 更新项目管理计划
    • 风险的情景题
      • 先判断风险识别了 ，还是风险发生了
      • 若是风险识别 ，按风险管理程序走
      • 若是风险发生 ，则应采取应急措施或权变措施 ，注意提交变更请求
    • 进度情景题
      • 先判断时间不够 ，还是资源不够
      • 时间不够 ，有三个选项可以选 ，但一般都是进度压缩
      • 资源不够 ，有两个选项可以选 ：关键链法和资源平衡
    • 沟通问题（题目中只会出现一个正确答案的 ，不存在先后问题）
      • 沟通管理计划
      • 沟通规划
      • 沟通需求分析
    • 相关方问题（相关方问题也是PMP考试中很常见的情景题 ，有4 个正确答案可以选）
      • 相关方管理计划
      • 管理相关方参与
      • 让相关方尽早参与
      • 识别相关方
    • 与供应商有争议
      • 谈判
      • ADR
      • 诉讼
    • 前一个项目 （阶段 ）。。。 ，下一个项目 （阶段 ）。。。这类题目重点是前一个项目 ，不要考虑后一个项目
    • 计算 EAC、ETC：先写出 3 个变量 ，再套两个或一个公式
  • 通过题干查找关键词
    • 1、出现 “新任项目经理”——选项中找 “项目章程”
    • 2、出现 “项目完成”或 “终止”——选项中找 “经验教训”
    • 3、出现 “团队成员能力不足”——选项中找 “培训”
    • 4、出现 “可接受行为”——选项中找 “团队章程（基本规则）”
    • 5、出现 “叙述性描述”——选项中找 “项目工作说明书”
    • 6、出现 “是否值得投资”——选项中找 “商业论证”
    • 7、出现 “根本原因”——选项中找 “因果图、石川图、鱼骨图”
    • 8、出现 “两个因素的关系”——选项中找 “散点图”
    • 9、看到 “最悲观最乐观最可能”——选项中找 “三点估算、PERT 技术”
    • 10、看到 “上限” “下限” “限值”——选项中找 “控制图”
    • 11、看到 “过程的稳定性”——选项中找 “控制图”
    • 12、看到 “最大影响”——选项中找 “敏感性分析”
    • 13、看到 “范围清楚”——选项中找 “固定价合同”
    • 14、看到 “内部资源不足”——选项中找 “招募，外包”
    • 15、看到 “复杂采购”——选项中找 “建议书评价技术，作为一个独立的过程（项目）”
    • 16、看到 “项目经理权力责任，授权”——选项中找 “项目章程”
    • 17、看到 “团队成员角色责任”——选项中找 “责任分配矩阵”
    • 18、看到 “增值活动，“政策”出现问题”——选项中找 “过程改进计划”
    • 19、看到 “非增值活动”——选项中找 “过程分析”
    • 20、看到 “制约因素”——选项中找 “项目章程”、 “项目范围说明
    • 书”或 “需求文件”
    • 21、看到 “需求 （意见 ）不一致”——选项中找 “引导（式研讨会）”
    • 22、看到 “风险” “不确定性”——选项中找 “三点估算”
    • 23、看到 “早期” “详细信息不足” “粗略的”——选项中找 “类比
    • 估算”
    • 24、看到 “数据库” “模型” “统计方法”——选项中找 “参数估算”
    • 25、看到 “虚拟团队”——选项中找 “沟通管理计划”或 “规划沟通”
    • 26、看到 “争吵” “对立”——选项中找 “震荡阶段”
    • 27、看到 “开始建立信任”——选项中找 “规范阶段”
    • 28、看到 “像一个组织有序的单位”——选项中找 “成熟阶段”
    • 29、看到 “风险管理过程的有效性”——选项中找 “风险审计”
    • 30、看到 “风险应对措施的有效性”——选项中找 “风险审计”
    • 31、看到 “如何实施风险管理活动”——选项中找 “风险管理计划”
    • 32、看到 “质量测量方法”——选项中找 “质量测量指标”
    • 33、看到 “检查可交付成果”——选项中找 “质量控制”
    • 34、看到 “修复可交付成果缺陷”——选项中找 “质量控制”
    • 35、看到 “发现大量次品”——选项中找 “管理质量”
    • 36、看到 “准备采取纠正措施”——选项中找 “帕累托”
    • 37、看到 “买方风险最小”——选项中找 “固定价合同”
    • 38、看到 “无法快速定义 SOW（范围）”——选项中找 “工料合同”
    • 39、看到 “检索 （功能或装置 ）”——选项中找 “记录管理系统”
    • 40、看到 “沟通管理计划”——选项中找 “过滤敏感信息”
    • 41、看到 “活动之间的依赖关系”——选项中找 “网络图”
    • 42、看到 “可交付成果的详细描述”——选项中找 “项目范围说明书”
    • 43、看到 “除外责任”或 “范围边界”——选项中找 “项目范围说明
    • 书”
    • 44、看到 “分配最有能力资源”——选项中找 “开拓”
    • 45、看到 “使用全新技术或方法”——选项中找 “开拓”
    • 46、看到 “外包” “买保险”——选项中找 “转移”
    • 47、看到 “更多测试”——选项中找 “减轻”
    • 48、看到 “团队绩效差”——选项中找 “识别根本原因”
    • 49、看到 “强调一致性”——选项中找 “缓解/包容”
    • 50、看到 “一定程度满意”——选项中找 “妥协”
    • 51、看到 “公开对话”——选项中找 “合作/解决问题”
    • 52、看到 “全部权力”——选项中找 “项目型”
    • 53、看到 “比较大的权力”——选项中找 “强矩阵”
    • 54、看到 “很小的权力”——选项中找 “弱矩阵”