@复习！！！

启动--规划--执行--监控--收尾

WHAT     WHY     HOW

2.2 项目规划

需求（客户需要）和范围（可交付成果）的区别

2.2.1 规划范围

2.2.2 收集需求

2.2.3 定义范围

2.2.4 收集需求

2.4.10 实施变更

2.2.5 规划进度

进度管理计划--指南性质

（其他指南：需求管理计划和范围管理计划）

进度管理计划无进度！

• 计划发布和迭代长度
• 准确度
• 计量单位
• 控制临界值（允许出现偏差）
• 绩效测量规则

2.2.6 定义活动（分解工作包）---输出：活动清单\里程碑清单\变更请求\项目管理计划

WHAT：

识别和记录具体行动的过程（洗菜、切菜等）

WHY：

分解--工作包--为具体"活动"

输入

I*UT：项目管理计划

@ 范围基准--主要干系人批准baseline

• 项目范围说明书（产品范围描述、可交付成果、验收标准、除外责任）
• WBS（工作包、规划包、控制账户）
• WBS词典（可交付成果、验收标准等）

       ？控制账户

工具与技术

TT1：分解

项目经理+团队成员

TT2：滚动式规划

渐渐明细

输出

OUTPUT1：活动清单

• 全部活动的属性
• 滚动/敏捷时，此清单定期更新

OUTPUT2：里程碑清单

• 重要的时点或事件
• 强制性（合同要求）/选择性（历史信息）
• 不是活动，只是个时间点

OUTPUT3：变更请求

• 滚动/敏捷时，信息明朗，请求变更

OUTPUT4：项目管理计划更新

• 可能变更：进度基准、成本基准

2.2.7 活动排序---输出：项目进度网络图\资源需求\估算依据\资源分解结构

WHAT：

识别和记录项目”活动之间的关系“

WHY：

定义工作之间的逻辑顺序

输入

I*UT：活动清单、里程碑清单等

工具与技术

TT1：紧前关系绘图法PDM

（precedence diagramming method）

？A  B  C......E？

• 完成到开始-FS
• 完成到完成-FF
• 开始到开始-SS
• 开始到完成-SF 

TT2：确定和整合依赖关系

• 强制性（硬逻辑--法律要求、工作性质等）
• 选择性（首先、优先）--打算快速跟进？

1. 外部依赖--项目与非项目--跨项目-----项目团队不可控
2. 内部依赖--项目活动之间的紧前-----项目团队可控

可以组合：强外、强内、选外、选内

TT3：提前量和滞后量

相对于紧前，紧后要推迟：FS+6

相对于紧前，紧后要提前：FS-3

纯FS关系可以默认不写！

输出

OUTPUT1：项目进度网络图

OUTPUT2：资源需求

OUTPUT3：估算依据

OUTPUT4：资源分解结构

2.2.8 估算活动时间

1、帕金森定律----

• 只要有时间、就会有意无意的蔓延工作范围

        学生综合症：赶着ddl才做

2、墨菲定律----

• 有可能出错的事情，就会出错

3、彼得定律----

• 工作岗位总是被不能胜任的人占据的--安分干活

学习曲线

--------------------------------------

WHAT：

• 根据资源估算单项活动的所需工时
• 应该由项目团队中最熟悉具体活动的个人或小组，来提供活动持续时间估算所需的各种收入
• 安排的人多不一定效率高

需要考虑的其他因素：

• 收益递减规律
• 技术进步
• 资源数量
• 员工激励

工具与技术

TT1：类比估算

• 历史数据、相似活动
• 专家判断、整体估算、自上而下
• 成本低、耗时少、准确性低（一般启动时用）

TT2：参数估算

• 历史数据、统计关系、参数模型、基础数据、公式

TT3：三点估算

• 考虑不确定和风险
• 最乐观
• 最可能
• 最悲观
• 期望值：取3点的平均值
• 期望值：（悲+乐+能*4）/6----加权平均

TT4：自下而上估算

• 细节开始汇总
• 速度慢、准确性高

TT5：数据分析

• 备选方案
• 储备分析：

1. 应急储备--应对“已知-未知风险”、应急储备在最终基准中、项目经理可以直接使用，无需走变更流程
2. 管理储备--应对“未知-未知风险”、管理储备不在基准中、项目经理需要走变更流程

• 已知风险
• 未知风险

TT6：决策

TT7：会议

输出

OUTPUT：持续时间估算

@复习！！！

启动--规划--执行--监控--收尾

WHAT     WHY     HOW

2.2 项目规划（启动--规划--执行--监控--收尾）

需求（客户需要）和范围（可交付成果）的区别

2.2.1 规划范围

2.2.2 收集需求----输出：需求文件&需求跟踪矩阵

2.2.3 定义范围---输出：项目范围说明书（可交付成果、验收标准）

WHAT：

• 从需求文件中选取最终的项目需求
• 然后制定处关于项目机器产品、服务或成果的详细描述

WHY：

• 描述产品、服务或成果的边界和验收标准

输入

I*UT1：项目章程

I*UT2：项目文件---需求文件

工具与技术

TT1：数据分析

• 备选方案分析

TT2：决策

• 多标准决策分析（男女朋友？）

TT3：人际关系与团队技能

• 引导（跨职能的干系人达成共识）

TT4：产品分析

输出

OUTPUT：项目范围说明书

1、记录了项目的整个范围

2、与干系人之间就项目达成的共识

3、管理干系人期望

• 产品范围描述（细化项目章程）
• 可交付成果
• 验收标准
• 除外责任（不做的，减少期望蔓延）

2.2.4 创建WBS---输出：范围基准（项目范围说明书可交付成果、验收标准、WBS可交付成果、验收标准）

WHAT：

WBS--（work breakdown structure）

WHY：

WBS：对所要交付的内容提供架构

输入

I*UT:  项目范围说明书（菜谱）--得到WBS

工具与技术

WBS--（work breakdown structure）

• 把可交付成果和项目工作-分解成较小、易于管理的组件
• WBS--组织并定义了项目的总范围（供应商的也要纳入）
• 最底层的组成部分--工作包--是可交付的成果！！

WBS词典：WBS的详细说明

创建WBS的4个原则：

• 无遗漏100%（做且只做）
• 工作包80h
• 4-6个分层
• 责任明确--工作包只能由唯一的小组负责

输出：

OUTPUT：范围基准--主要干系人批准baseline

• 项目范围说明书（产品范围描述、可交付成果、验收标准、除外责任）
• WBS（工作包、规划包、控制账户）
• WBS词典（可交付成果、验收标准等）

？控制账户

项目文件可以改

项目管理计划最好不改---改走正式流程

2.4.10 整体变更----输出：批准变更请求\项目文件更新--变更日志\项目管理计划更新

WHAT：

审查所有变更请求、批准变更、管理变更

WHY：

只审批、管理变更

不会提出变更请求

注意点：

• 项目经理对此最终负责
• 任何干系人可以提出变更请求、必须书面形式记录
• 评估变更影响和成本
• 由变更控制委员会CCB实施变更-----注意更新变更日志

输入

！！I*UT：变更请求

1. 记录--项目经理/变更提出者（提交书面请求）--记到变更日志
2. 评估--变更影响
3. 提交--项目经理把变更请求和评估结果给CCB
4. 更新---无论是否通过
5. 通知---受影响的干系人

！！常见考法！！

1. 变更顺序（偶尔：有选前期了解原因）
2. 要不要变更（都要走流程）

！！常见关键词！！

• 处理/实施变更请求——1~5步

输出

OUTPUT1：批准变更请求

CCB！！！（PMO\发起人\项目经理等）

OUTPUT2：项目文件更新--变更日志

OUTPUT3：项目管理计划更新

@复习！！！

启动--规划--执行--监控--收尾

WHAT     WHY     HOW

2.2 项目规划--（启动、 、执行、监控、收尾）

需求（客户需要）和范围（可交付成果）的区别

2.2.1 规划范围管理

OUTPUT1：范围管理计划

OUTPUT2：需求管理计划--大指南

2.2.2 收集需求----输出：需求文件&需求跟踪矩阵

WHAT：包括发起人、客户和其他干系人的“已量化”且书面记录的需要和期望

！！前期的高层级需求---细化成具体的单一需求！！

输入：

I*UT1：干系人登记册

I*UT2：商业文件

I*UT1：协议

工具与技术：

TT1：数据收集！！

• 头脑风暴（传统项目不用--影响客户满意度）
• 访谈（直接面谈--机密信息--座位顺序？）
• 焦点小组（同职能、同领域）
• 问卷调查（受众多样、地理位置分散、快速完成）--问题设计！
• 标杆对照（内外、同行不同行、识别最佳实践、形成改进意见）

TT2：数据分析

• 分析现有文件

TT3：决策！！

• 投票（1、德尔菲--专家匿名、多轮、趋同；2、大多数同意超50%，人数为奇；3、相对多数同意，好几个选项）--强调结果
• 独裁
• 多标准（男女朋友？）

TT4：数据表现

• 亲和图（帮助分组、分类）
• 思维导图（整合）

TT5：人际关系与团队技能！！

• 名义小组？民意？（投票、优先、排序）--强调过程（参考好声音海选）
• 观察和交谈（旁敲侧击、挖掘说不出来的）
• 引导研讨会 （跨职能、协调干系人差异）
• 联合应用设计或开发JAD
• 质量功能展开QFD
• 用户故事

TT6：系统交互图

• 网络拓扑图（机房等）

TT7：原型法

• 模型（减少返工风险）

输出

OUTPUT1：需求文件--小概念

• 业务需求--高层级（对应项目章程的需求）
• 解决方案需求
• 项目需求
• 干系人需求
• 过渡和就绪需求
• 质量需求

OUTPUT2：需求跟踪矩阵

• 保证每个需求有商业价值
• 交付成果对应客户的需求
• 整个项目生命周期中跟踪需求

@复习！！！！！！！

1、项目生命周期和阶段：--大概念

开始--组织准备---执行---结束（概况通用）

！各种项目的划分周期不一样！

2、开发生命周期：

我们把一个项目划分成若干个阶段进行管理的时候，其中有某个/某几个阶段和可交付成果的开发有关，

那么“某个/某几个阶段”就形成了“开发生命周期”；

“开发生命周期”是项目生命周期的一部分，一个项目生命周期可能有多个“开发生命周期 ”

3、项目生命周期阶段和项目管理过程的关系

每一个阶段都看成是小项目，都需要管理，项目管理过程：

启动-

-规划-

-执行-

-！监控！（可能一直贯穿项目管理的5大过程）

-收尾

4、项目管理过程---小概念

启动-

-规划-

-执行-

！！监控！！（可能一直贯穿项目管理的5大过程）

-收尾

5、项目管理过程和项目管理过程组的关系

横向把项目管理过程（ITTO，49个过程）分组

---得到项目管理过程组（5大过程组）：裁剪使用

启动--规划--执行--监控--收尾

################################

WHAT     WHY     HOW

2.1 项目启动（规划、执行、监控、收尾）

2.1.1 制定项目章程--输出：项目章程

WHAT---批准项目并授权项目经理

WHY---明确项目与组织战略目标之间的关系，确定地位

• 建立甲乙双方的联系
• 由项目以外的---发起人等来启动
• 开展商业论证和效益管理
• 尽早任命“拟派项目经理“参与项目章程的制定（做商业论证可以，负责和审批不是他）
• 最晚必须在规划开始之前，任命好项目经理
• 需要正式合同来达成协议

HOW--ITTO

输入

I*UT1：商业文件--大

商业文件不是项目文件

项目之前制定、定期审核

项目经理可以对发起人提出建议等

1、商业论证--小---商业需求分析、成本效益分析（文档化的经济可行性研究报告）

2、效益管理计划--小--目标、战略、效益等

I*UT2：协议（合同）

谅解备忘录MOUs--甲乙双方互相谅解的备忘录

SLA、意向书等

I*UT3：事业环境因素&组织过程资产等

工具与技术

TT1：专家判断

有经验的任何小组或个人

TT2：数据收集

头脑风暴（畅所欲言）、焦点小组（主题专家SME）、访谈（直接和干系人）

TT3：人际关系与团队技能

会议管理

TT4：会议

输出

！Output1：项目章程（宏观）！

项目目标、成功\失败标准等

由项目启动者或发起人发布的

高层级、主要可交付成果、总体预算、里程碑等

项目经理及权责、干系人名单等

（注意：项目管理计划！！）

@OUTPUT：范围基准--主要干系人批准baseline

• 项目范围说明书

（产品范围描述、可交付成果、验收标准、除外责任）

• WBS

（工作包、规划包、控制账户）

• WBS词典

（可交付成果、验收标准等）

Output2：假设日志

项目的假设条件（无需验证）

和制约因素都写进去

2.1.1 识别干系人----输出：干系人登记册

定期识别干系人

输入

I*UT1：项目章程

列出干系人清单

I*UT2：商业文件

I*UT3：协议

工具与技术

TT1：头脑风暴、头脑写作--干系人基本信息

TT2：数据分析--干系人评估信息

TT3：数据表现--干系人分类--二维方格/立方体

TT4：会议

输出

OUTPUT1：干系人登记册/通讯录

干系人基本信息

干系人评估信息

干系人分类

OUTPUT2：变更请求

项目管理的商业文件——商业论证：做分析--分析师；定制和维护--发起人；建议和一致--项目经理

项目终止：便利原因——甲方便利（合同里面明确提到甲方便利的某种情况下可以终止合同）

敏捷：迭代-快、增量-小、优先级

五大过程组、十大知识领域

2.2.10制定进度计划

1.输入：项目进度网络图

2.工具与技术：开始是早上，结束是晚上

2.1关键路径法CPM（完成时间=开始时间+工期-1）

• 总时差=最迟开始（结束）-最早开始（结束）：不延误项目完工
• 关键路径的总浮动时间可能为0，或正（进度加快）负数（进度落后）
• 自由时差=紧后活动的最早开始-本活动的最早结束-1：不影响紧后开始
• project工具

2.2资源优化：不改变工作量

• 资源平衡：造成关键路径延迟，一个人做多个活动
• 资源平滑：不改变关键路径，在总时差间调节开始时间

2.3假设情景分析、模拟（蒙特卡洛分析）

2.4提前量和滞后量 

2.5进度压缩：赶工（关键路径增加资源、成本）、快速跟进（并行施工-选择性依赖、风险）

3.输出：进度基准（里程碑进度计划-客户、甘特图（横道图）-管理层、项目进度网络图）、项目进度计划、项目日历

项目管理过程

项目章程

事业环境因素 ：不可控 须遵守

组织过程资产：

过程，政策和程序 

组织知识库

pmo 

支持型

控制型

指令型

项目经理

PMI人才三角

技术项目管理技能

战略和商务管理技能（行业知识）

领导力技能

1.1 项目基础 

项目的独特性

项目的临时性

项目管理的制约因素

平衡制约因素对项目的影响

项目集

项目组合

项目运营

服务于

组织战略

项目的通用生命周期

开始项目

组织与准备

执行

结束

开发生命周期

1.预测型

2.迭代型

3.增量型

4.适应型（敏捷）迭代+增量

敏捷特点：

快速迭代，较小的增量 

5.混合型

过程组

最悲观+最乐观+最可能*4

再除以6

书面记录，可以项目经理也可以提的人填表。

自己或者相关干系人评估下。

项目经理乙方把合理评估结果提交给ccb审批。

不管是否通过都是更新CR

结果通知受影响的干系人！

考试重点！！20题目！！比对。 

2.2.5规划进度管理

进度管理计划（无进度只是准则：准确度、单位、临界值、EVM）

2.2.6定义活动

1.输入：范围基准

2.工具与技术：分解（团队成员）、滚动式规划

3.输出：活动清单（定期更新）、里程碑清单（重要时点）、变更请求、项目管理计划更新（进度基准、成本基准）

2.2.7排列活动顺序

1.输入：活动清单

2.工具与技术：紧前关系绘图法（PDM、节点法、AON、前导图法、单代号法）、提前量和滞后量

3.输出：项目进度网络图

2.2.8估算活动资源（人力资源）

输入：项目文件（活动属性、活动清单、假设日志、成本估算、资源日历、风险登记册）

输出：资源需求、估算依据、资源分解结构（资源类别、资源类型）

2.2.9：估算活动时间（团队中最熟悉具体活动的个人或小组）

• 帕金森定律：只要还有时间就会多做不必要的工作-预留应对风险的时间
• 学生综合征：快到截止时间才着急做事-激励
• 墨菲定律：可能错的事情就会出错-重视风险
• 彼得定律：工作岗位总是被不能胜任的人占据
• 学习曲线：熟能生巧

工具与技术：类比估算（不准、信息不足）、参数估算（公式）、三点估算（考虑风险）、自上而下估算（最准确）、决策、会议、储备分析（应急储备、管理储备）、备选方案分析

2.2.3定义范围

1.输入：项目章程（高层级需求和可交付成果）、需求文件（单一需求）

2.工具与技术：备选方案分析、多标准决策分析、引导技能、产品分析

3.输出：项目范围说明书*（产品范围描述、可交付成果、验收标准、除外责任）

2.2.4创建工作分解结构（WBS）

定义：可交付成果和项目管理分解为组件，最底层组件称为工作包（本质也是可交付成果）

1.输入：范围说明书

2.工具与技术：分解（100%、80小时、4-6 层、责任明确）

3.输出：WBS、WBS词典、范围基准（范围说明书、WBS、WBS词典）

2.4.10实施整体变更控制（处理变更请求）

1.输入：变更请求（了解变更内容和原因）

2.变更管理计划（流程）：记录（干系人-PM，书面：变更日志、变更申请）、评估（PM）、提交（PM-CCB/PMO）、更新（变更日志）、通知

3.输出：批准的变更请求、项目文件更新（变更日志）、项目管理计划更新

附：未通过批准也要更新和通知

收集需求：

1.输入：干系人登记册、商业文件、协议

2.工具和技术：头脑风暴、访谈、焦点小组、问卷调查、标杆对照、文件分析、投票、德尔菲技术、独裁、多维决策分析、亲和图、思维导图、名义小组技术（头脑风暴结果排序）、观察、引导（联合应用设计或开发、质量功能展开、用户故事）、系统交互图（拓扑图）、原型法

3.输出：需求文件（需求规格说明书）、需求跟踪矩阵

2.1.1制定项目章程-立项

1.输入：商业文件（商业论证、效益管理计划）、协议

2.工具技术：专家判断、头脑风暴、焦点小组、访谈、引导、会议

3.输出：项目章程（高层级的。。、总体的。。）、假设日志（假设条件、制约因素）

2.1.2识别干系人

1.输入：项目章程、商业文件、协议

2.工具与技术：头脑风暴、头脑写作（基本信息）、干系人分析（评估信息）、干系人分类（权力利益方格、凸显模型、干系人立方体）、会议（引导式研讨会、指导式小组讨论会、虚拟小组讨论）

3.输出：干系人登记册、变更请求

 单个项目

项目：独特性 不确定性  可交付的成果必须要可核实（有形无形 重复） 

          临时性：明确的起点和终点   可能时间会很长 项目交付成果持久

项目终止的情况：

• 目标达成
• 达不成目标
• 资金
• 项目需求不复存在 中止（不支持不是项目中止的理由 ）
• 无人力或资源
• 法律或便利

项目驱动变革：

• 当前状态转变将来状态
• 例：超市老板 帮别人首发快递-菜鸟驿站

项目创造商业价值：

干系人：受项目影响的人

• 有形效益 （数据量化）
• 无形效益（品牌认知度 公共利益 商誉 ）扶贫 公益 标杆项目引流

范围  、进度、    成本 （相互影响相互约束）

多           慢            少

少           快            少

多            快           多

多           快             多             滚~~~~~~

多个项目：

形成项目集  （家庭） 相互关联被协调

项目组合      （小区）竞争关系 优先级

例：酒店集团——组织战略

• 项目组合：选择 优先级   酒店ABC运营 生产重复性结果的持续性的工作  
• 项目集：方式 协调与依赖 消防 装修 信息化 弱点
• 项目：
• 服务于战略组织，小于关系

生命周期：启动-完成一系列阶段

顺序 迭代 交叠

特点：收尾要快  项目进行中风险和变更的数量会变少

开发生命周期的类型：

• 预测型（瀑布型） 计划驱动   需求范围明确 充分了解产品 厚实的行业基础 
• 迭代型  重复的循环 模糊-清晰
• 增量型   渐进增加 增量 从部分到整体
• 适应型（敏捷） PB 定优先级  快速的迭代 较小的增量  小步快跑 频繁的交付 
• 混合型：多种生命周期类型

阶段和过程组的关系：

阶段       启动-计划-执行-监控-收尾

过程组 49个过程组 过程形成的小组

数据概念： 

• 工作绩效数据
• 工作绩效信息
• 工作绩效报告

头脑风暴要注意场合

访谈不适合在开放性场合进行，适合在保密的环境（会议室）

焦点小组（同职能，同一领域）

问卷调查的质量可能不好，数据不准确
（问题的设计很重要）

不同行业也能标杆对照

匿名了 多轮了就是德尔菲分析

超过50%就是多数

决策的人数一般是奇数

至少做对110道题目

有5个题不记分，但不一定

180道题一共

单选+多选（选几个），多选5-10题

6-8周出结果

需求跟踪矩阵

WBS：work breakdown structure

可交付成果和项目工作

组织并定义

WBS词典

主要交付成果：范围说明书

借鉴：文件夹的命名

分几层标准：由一个唯一的小组负责==》容易管理

最底层的本质：工作包（成果）-还是可交付成果，颗粒度更小

项目进度网络图

赶工的本质---花钱买时间，成本一定会增加。