引论：

一、项目和项目管理和基本概念和特点:

PMI

普遍认可，良好做法

PMBOK指南、项目管理标准

裁剪：确定过程、输入、工具、技术、输出和生命周期阶段的恰当组合

优化、做匹配

通用词汇：术语表

《项目管理协会道德与专业行为规范》

责任、尊重、公正、诚实

指导单个项目如何完成：

项目集、项目组合、组织级项目管理：参考其他标准

二、项目、项目集、项目组合的区别和联合

1、项目概念

（1）渐进明细化：范围不方便变化，与范围蔓延差异

根据信息的逐渐清晰进行滚动式规划；

区域于范围潜变（范围蔓延）

（2）独特性：

人不可能两次趟过同一条河；

重复不见的存在，不影响项目的独特本质。

（3）临时性

项目不一定短暂，产生的产品和服务不算临时性的。

其他不算在内

范围蔓延：情绪愉悦，需要增加边界感

2、项目启动背景

（1）满足相关方的需求或要求

（2）执行、变更业务或技术战略

（3）符合法规、法律或社会要求

（4）创造、改进或修复产品、过程或服务（新产品）

练习

为了提高收入，培训机构研发新的课程--战略机会/业务需求

为了给新工业园区供电，建立新变电站--客户要求

电子技术升级，开发新项目生产更小巧的电脑--技术进步

为了达到相关要求，建立项目处理新型有毒药品--法律要求

应对汽油紧张。生产低油耗汽车--社会需求

降低污染，建立共享小汽车--环境考虑

向传染病高发地区提供引用水系统--社会需要

3、项目的作用-驱动变更

（1）当前状态-》将来状态

4、项目的作用-创造商业价值

（1）概念

从商业运作中获得的可量化净益（benefit）：收益

项目的商业价值指特定项目的成果能够为相关方带来的效益

（2）包含有形效益，无形效益

有形效益：钱、固定设施等

无形效益：商誉、品牌认可度、公共利益等

项目带来的效益可以是有形的、无心哥或两者兼有。

三、项目和运营的区别和联系

四、项目管理商业文件的内容

五、项目生命周期和开发生命周期的关系

课程目标：

1、建立体系架构

2、连接实战思考

3、知识全面详解

4、熟悉考试风格

一、引论

二、项目运行环境

1、事业环境因素（不能轻易改变的东西）

2、组织过程资产（不断总结利用的东西）

三、项目经理的角色

标准体系梳理项目经理角色

四、整合管理（重要）

1、接口interface

有接口的地方需要整合

2、整合管理贯穿始终

五、范围管理

1、需求收集-发散

挖到深层次需求，不然容易需求频繁变更

2、定义范围-收敛

可量化

形容词不可量化、不可验收、不可交付

确认验收标准

早期解决办法：

（1）提供demo

（2）借鉴

敏捷管理

六、进度管理：

1、项目关键路径：项目管理最长路径

2、非关键路径

3、向关键路径保时间、向非关键路径借资源

4、关注闲置人和事情，优先级

5、计算关键路径

七、成本管理：

1、留意剩余成本、剩余工作量比对关系

2、进度协同、范围考量

3、难点：挣值分析EVA

八、质量管理：（重要）

1、QA：管理质量

对过程的分析

2、QC：控制质量

对可交付成果，对结果的测试

3、使用好质量工具

4、区分QA和QC

九、资源管理

1、人力资源

（1）获取相关资源

盘点人力资源

规划人力资源

索取人力资源

A、职能性组织架构

B、矩阵性组织

（2）要人来源

职能经理（资源经理）：申请资源

（第一步：

带着你的选择，你的倾向性，你的为什么；

第二部：

领导评估）

其他团队管理人员（项目经理）：协调、勾兑

供应商（外包）

2、实物资源

十、沟通管理

1、管人，权利不大，责任大，人一般会排斥非直线经理管理

2、期望，小我诉求、实现大我目标

3、频率、方法、策略

十一、风险管理（重要）

1、共识过程，领导与我们认可的风险

2、风险识别的方法统一

3、规划风险管理

4、风险定性、定量

十二、采购管理

默认我们是甲方

1、一口价合同（总价合同）

2、补偿合同

3、单价合同

十三、相关方管理

十大知识领域

结构化 学习方法

十四、PMP考试

Project

考试办法：

开始快，后面慢

成绩方面：

五大过程组

启动、规划、执行、监督、收尾

如何学习PMBOK:

思路：

倒空（清空经验思维、倾听理解思路）、

阳光（）、

积极主动（尊重他人、公正、职业道德）

态度：

100（小时）、

1000（题数量）、

看书（PMBOK，必须看，重点章节需要多看）

网络：ITO

why-I，为什么要输入

HOW-T、如何使用工具

WHAT-O：输出什么，结果是什么，以终为始

80/20原则：

抓重点、

补短板

总结：

定期、

相近概念、

错题库

十五、结束语

启动：一拍大腿

规划：堪称完美

执行：伊邪那美

监控：一直放水

收尾：捉急后悔

指定进度计划：

• 编制出进度模型
• 进度模型：带数据的进度规划工具
• 进度数据：描述和控制进度的信息集合
• 进度计划：进度模型的输出
• 进度基准：经批准的进度模型

制定进度计划：

• 输出：进度基准、项目进度计划、进度数据、项目日历（项目日历越多，制约越多）
• 工具：关键路径法（向关键路径保时间，非关键借资源）、资源优化、进度压缩（赶工增加资源、快速跟进增加返工风险）

关键路径法：

• 总浮动时间通常为0，也可能为负或正
• 至少一条（越多风险越大）
• 次关键路径：需密切关注，防止变成关键路径
•  
• 总浮动时间\总时差：活动可以推迟但是不会延误项目的关键路径时间
• 自由浮动时间\自由时差：不会影响所有紧后工作最早开始的实际

资源优化技术：

• 资源平衡RL:改变关键路径，通常导致进度计划延长
• 资源平滑RS:不会改变项目的关键路径、

假设情境分析：为克服或减轻意外情况的影响而编制应急和应对计划。

模拟：蒙特卡罗方法（局部不确定，计算整体不确定；多次模拟反复迭代）

进度压缩：

• 赶工：增加资源
• 快速资源：可能返工

进度基准：

• 进度基准：是经批准的进度模型
• 进度模型：带数据的工具
• 进度数据：描述和控制进度的信息集合，为了制定和控制进度基准
• 进度计划：进度模型的输出

甘特图：相对易读

里程碑图：

项目进度网络图：详细，都有

项目日历：可能有多个项目日历，在项目日历中规定可以开展进度活动的工作日和工作班次。

控制进度：

• 管理变更
• 实施回顾性审查
• 输出：工作绩效信息
• 输入：工作绩效数据
• 工具数据分析

数据分析：

迭代燃尽图（计划、实际、预测）：

根据资源估算的结果

估算活动持续时间

• 活动持续时间估算不包括任何时间提前量和滞后量
• 可以提出一定的变动区间
• 由最熟悉活动的个人或小组提供输入
• 估算是渐进明细的。
• 需要记录各种估算假设

需要考虑的因素：

• 收益递减规律
• 资源数量
• 技术进步
• 员工激励：学生综合征（即拖延症：只有在最后一刻才会全力以赴）
• 帕金森定律：只要还有时间，工作就会不断扩展，直到用完所有的时间

风险三要素：事件、影响、概率

• 已知-已知：应对成本
• 已知-未知：应急储备
• 未知-未知（未识别到的风险）：管理储备，需向更高层面申请，项目经理无权管理

类比估算（也叫自上而下估算）：

• 项目早期阶段使用
• 同类参数或指标
• 综合利用历史信息和专家判断
• 成本低、耗时少、准确性低

参数估算：

• 统计关系做计算
• 成本较低、但无法适应变化
• 需要历史信息准确、参数容易量化、模型可按比例调整

三点估算：

• 公式基于计划评审技术PERT
• 最可能时间Tm
• 最乐观时间To
• 最悲观时间Tp
•  默认公式：贝塔分布Te=(to+4tm+tp)/6
• 
• 标准差=（Tp-To）/6 

储备分析：

• 应急储备：项目经理掌握
• 管理储备：高层掌握
• 动态调整（渐进明细）

结束项目或阶段：

1、成果移交2、经验总结3、文件记录/审核4、相关方满意度调查（新商机挖掘）5、资源遣散

2、验收发生在监控过程组；移交发生在收尾过程组

1、监控项目工作主要输出工作绩效报告。工作绩效报告包含进展报告、状态报告、预测报告。

2、实施整体变更控制，项目经理对此负责。

3、变更控制程序：防止变更出现；一旦变更出现，先弄清楚变更是什么；创建变更请求（口头变书面）；评价变更对某个直接制约因素的影响；全面评价变更对所有因素的综合影响；生成应对方案与策略；向CCB正式提交变更请求；--不批准--要记录到变更日志，继续监控--批准--更新计划与项目文件（变更日志），通知变更受影响的相关方，最总变更的实施情况与效果。

简化版

书面记录变更请求---分析影响---提交CCB进行审批---批准或者拒绝---若批准，修改计划，体现变更

指导与管理项目工作，输出

1、可交付成果。

2、工作绩效数据。（数据和计划对比形成工作绩效信息，信息汇总形成工作绩效报告）

3、问题日志。

排列活动顺序：

• 识别项目活动间的逻辑顺序，获得最高效率
• 发生：在整个项目期间开展
• AON\AOA

输出：

• 项目进度网络图（AON/AoA）
•  

PDM 紧前关系绘图法

• 强依赖关系：先泡茶再喝茶
• 选择性依赖：茶道
• 外部依赖：依赖于其他因素
• 内部依赖：紧前关系

提前量和滞后量：

• 都是针对紧后活动而言
• 时间提前量和滞后量补鞥呢改变活动的逻辑关系
• 提前负号表示
• 滞后正号表示
• 

规划进度管理：

• 输出：进度管理计划
• 输入：项目章程、项目管理计划

进度管理计划：

• 建立准则，说明如何管理进度
• 进度计划的发布和迭代长度
• 控制临界值
• 应急储备梳理
• 计量单位
• 绩效策测量规则
• 完成百分比的规则

定义活动：

• 对工作包的继续分解
• 工作包采取的具体活动。
• 输出：活动清单、活动属性（对活动清单的解释说明）、里程碑清单（选择性里程碑是为了更好实现强制里程碑而存在的）

• web分解的结果是可交付物，活动分解的结果是更细小的活动
• 让团队成员参与，由于得到更好的结果。

活动属性包括：唯一活动标识+wbs标识+活动标签\名称

里程碑：项目中的重要时点或事件

• 强制性：合同要求的
• 选择性：根据历史信息确定的
• 持续时间为0

• 快速跟进：可能导致返工（风险发生）
• 赶工：增加资源
• 将工作包分解为活动，继而进行进度管理的其他过程。
• 关键条数越多，风险越大
• 为了得到更准确的估算结果，可以使用自下而上的估算。

• 进度管理计划：how
• 进度计划：what 甘特图
• 常见估算方法：自下而行、自上而下（类比，不准确）、三点估算（1+4+1）/6默认公式

按需进度计划：看板体系

• 在大型组织中，可能同时存在小规模项目和大规模举措，需制定长期路线图。

确认范围：正式验收项目已完成的可交付成果的过程。

• 获得客户与发起人的正式验收。
• 确认范围：可交付成果的验收（外部）
• 控制质量：可交付成果是否正确、是否满足质量要求。（内部）
• 控制质量通常先于确认范围进行，也可同时进行。

核实的可以交付成果——检查——验收的可交付成果。

控制范围：

• 管理范围变更
• 在整个项目期间保持对范围基准的维护。
• 整个项目期间持续开展。

控制范围：

工作绩效数据——数据分析——工作绩效信息。

偏差分析：

• 偏差大：纠正或预防
• 偏差小或无：绩效监控。

创建WPS（工作分解结构）

• 工作分解结构组织并定义项目的总范围
• WBS最底层的组成部分叫工作包
• WBS不表示逻辑关系和历时，只表示范围。
•  

创建工作分解结构（wbs）

• 输入：项目范围说明书
• 输出：范围基准、项目文件更新（假设日志、需求文件）
• 工具：分解

最底层是工作包

规划包：暂时不知道怎么分，只是放在上面

• wbs具有层次结构，由团队成员共同完成制作
• 每个控制账户可以包括1个或多个工作包，但每个工作包只能属于一个控制账户

wbs分解原则

• 100%包含原则，wbs整体包含了项目所需的所有工作。
• MECE互斥，完全穷尽
• ...

范围基准包括：

• 项目范围说明书
• wbs
• 工作包
• 规划报
• wbs词典（是最详细的范围描述）

定义范围作用：描述边界和验收标准。

定义范围：

• 输出：项目范围说明书（做什么、不做什么、验收标准）
• 输入：项目文件（假设日志、需求文件、风险登记册）

项目范围说明书：

• 产品范围描述
• 可交付成果
• 验收标准
• 项目的除外责任会生成更更详细的假设条件和制约因素。

需求是工作分解结构，成本、进度。。。的基础

收集需求：

• 输出：需求文件、需求跟踪矩阵（）
• 输入：商业文件、项目章程、项目文件、项目管理计划、协议

• 头脑风暴：速度快，但容易受影响。
• 德尔菲法：各个专家背靠背，速度慢，不容易受到别人印象，比较准确
• 访谈，一对一，获取机密信息
• 焦点小组：有一个受过专业训练的主持人。引导、比访谈更热烈、可分成不同的小组。
• 问卷调查：受众多，地理位置分散、开展统计分析。
• 标杆对照：2个项目（一个标杆一个自己的项目）、
• 文件分析:挖掘需求
• 决策：投票（一致同意、大多数同意(超过50%)，相对多数同意）
• 亲和图：分成小组，合成大组。
• 思维导图：激发新创意，放射性的想法图形化
• 名义小组技术：结构化的头脑风暴。
• 引导：强调问问题，跨职能需求收集。
• 用户故事：用于敏捷开发
• 系统交互图：用户
• 原型法：渐进明细地收集需求，

需求文件：

• 验收标准
• 质量需求
• 功能需求
• 业务需求

需求跟踪矩阵：

• 确保每一个需求都具有商业价值。
•  

如何去做

• 输出：范围管理计划（如何防止范围蔓延）、需求管理计划（如何给需求排序）
• 输入：项目章程、项目管理计划、“事环”、“组过”

• 范围管理计划：
• 如何（how）降低项目范围蔓延的风险
• 指定项目范围说明书
• 如何创建wbs

需求管理计划：

• 需求优先级排序
• 产品测量指标

• 项目范围的完成情况是根据项目管理计划来衡量的
• 工作分解结构的最底层被称为工作包。
• 验收发生在监控，移交在收尾
• 确保项目做且只做

规划过程组：

• 规划范围管理
• 收集需求
• 定义范围*（范围说明书：做什么不做什么，验收标准）
• 创建wbs

监控过程组：

• 确认范围（验收）
• 控制范围（对范围方面的变更处理）

产品范围是根据产品需求来确定的

项目范围根据项目管理计划来确定

敏捷方法：

• 把需求列入未完项
• 有目的地构建和审查原型，并通过多次发布版本来明确需求。
• 特意在项目早期缩短定义和协商范围的实际，并未持续探索和明确范围而延长创建相应过程的时间。

1.变革型是用项目将实现的变革来激励大家。

11.P65魅力型领导--例如能够激励他人；精神饱满、热情洋溢、充满自信；说服力强。讲义P59

18.P67执行整合--认知层面的整合--项目经理在选择管理项目的方法时，通常取决于项目的具体特点，包括规模、项目或组织的复杂性。讲义P60

20.P68项目的复杂性主要来源：组织的系统行为（系统行为-组成部分与系统之间的依赖关系）、人类行为（不同个体和群体之间的相互作用）以及组织或环境中的不确定性（模糊性）。讲义P60

• 作用：存档项目或阶段信息，完成计划的工作，释放组织团队资源以开展新的工作。
• 顺序：成果移交+经验总结+文件记录\审核+资源遣散
• 项目后评价或阶段结束评价
• 如果项目提前终止，需要制定程序来调查和记录提前终止原因。

• 输入：验收的可交付成果。
• 输出：最终产品、服务或成果的移交
• 验收发生在监控过程组，移交是在收尾。
• 商业文件——》最终报告

确定具体收尾程序——将项目成果全部移交——完成经验教训总结——文件审核、归档——相关方满意度调查——资源遣散。

最终报告：总结项目绩效，

监控项目工作：

• 输出：工作绩效报告、变更请求
• 输入：工作绩效信息、项目文件

工作绩效报告：

• 包括状态报告、进展报告、预测信息

实施整体变更控制：

• 确保只有经过批准的变更才可以实施。
• 基准确定前，不存在变更
• 变更过程贯穿始终，项目经理对此承担责任。
• 变更请求--》变更控制工具——》批准的变更请求。
• 变更日志。详细的变更过程信息记录。
• 变更控制委员会CCB（默认是有客户的）：由相关方正式组成的团体。
• 变更通常需要跟发起人和客户确认。
• 默认所有组织都有PMO
• 项目经理PM可以是CCB的成员但不是主人
• 评估变更的影响是会议的基本工作。

变更控制程序-完整版

1. 对可能引起变更的因素加以影响，防止变更出现。
2. 一旦变更出现，先弄清楚变更到底是什么
3. 口头边书面记录（创建变更请求）
4. 评价变更对某个直接制约因素的影响。
5. 全面评价变更对所有因素的综合影响。
6. 生成应对方案与策略
7. 向CCB正式提交变更请求
8. CCB判断：批准或否定；
9. 不批准：记录到变更日志，继续监控
10. 批准：更新计划与项目文件（变更日志）；通知变更受影响的相关方、追踪变更的实施情况与效果。
11. 

变更控制程序——简化版

书面记录变更请求——分析影响——提交CCB进行审批——批准或者拒绝——若批准，修改计划，体现变更。

整合管理计划的执行过程：指导与项目管理工作、管理项目知识

• 输入：项目管理计划、批准的变更请求
• 输出：可交付成果、工作绩效数据、问题日志、变更请求、项目管理计划更新、项目文件更新、组织过程资产更新。
• 工具：项目管理信息系统PMIS

• 项目执行过程中，需收集工作绩效数据。

批准的变更请求：

• 必须是正式的
• 必要时需经变更控制委员会CCB审查批准。可能由项目经理审查和批准（小的项目）
• 纠正措施：不改变基准
• 预防措施：不改变基准
• 缺陷补救：
• 更新：一定改变基准
• 

看到配置管理系统：想起版本管理系统（功能特征-物理特征）

• 核实的可交付成果：内部测试，控制质量；
• 验收：外部确认范围
• 

• 工作绩效数据：项目工作收集的第一手资料；
• 问题日志：可认为已发生的消极风险。

管理项目知识

• 输出：经验教训登记册、项目管理计划更新、

经验教训登记册：

• 项目早期创建，整个期间需不断更新。最终成为组织过程资产的一部分。