目录
【写在前面】
项目管理七步法：
（1）记录
（2）评估
（3）分析，定方案
（4）获批准
（5）更新
（6）执行
（7）跟踪
【十五至尊图】
【预测型生命周期】
0. 项目整合管理的基本概念
（1）项目整合管理
（2）整合的发展趋势
（3）项目管理过程三从四德
注：
文件：来源于5大过程组都会有文件的输出
计划：来源于规划过程组
成果：来源于执行过程组
数据：来源于执行，监控过程组
变更请求：来源于执行，监控过程组
事业环境因素：从获取资源，建设团队，管理团队三个过程输出
组织过程资产：
经验教训登记册：大多数过程都会输入输出
（4）项目整合管理实现过程（重要！！！）
注：
1. 立项，任命PM，宣布项目启动，开始项目工作
2. 根据章程，制定项目管理计划
3. 按照计划规定，逐步指导工作
4. 管理知识，总结经验教训
5. 时刻监督项目开展情况，防止偏差，及时纠正
6. 变更不可避免，需要严格控制变更，让变更走正规流程
7. 整个项目/阶段完成后，要收尾，代表项目工作的完成
1. 制定项目章程（！！！重点，必考内容）
注：
（1）这阶段做的事：立项，任命，授权
任命PM，授权PM可以使用资源来开展工作。
（2）项目章程的所有权，归发起人
（3）什么是发起人：
发起人是给项目提供资源和财务支持的人/组织。
发起人不一定是公司管理层，可能是客户。
发起人有权：立项，编写修改批准取消项目章程，批准项目，取消项目。
项目经理人可以代替（受委托）发起人制定项目章程，但所有权还是归发起人。
1.1 制定项目章程：输入
（1）商业文件
商业论证：确认项目是否具有商业价值，最常用到的工具是成本效益分析，可以界定项目的边界
效益管理计划：
（2）协议
（3）事业环境因素
（4） 组织过程资产
补充：
1.2 制定项目章程：输出
（1）项目章程 （牢记）
整个项目管理工作的核心。
12项内容，牢记。
跟6重制约有密切关系。
（2）假设日志
包含假设条件和制约因素
基于基本的假设来判断项目是否可以开展
作为很多过程的输入和输出
1.3 制定项目章程：工具与技术
（1）专家判断
（2）数据收集
头脑风暴：
言论自由，禁止评判。
应用场景：短时间，受众少，地位相对平等。
焦点小组：
基于头脑风暴的基础，多了主题专家，专家对会议进行要求和控制，围绕主题，不要跑偏。
应用场景：短时间，受众少，地位相对平等。
访谈：
应用场景：跟关键干系人获取重要信息时，预约时间，拜访，现场获取
（3）人际关系和团队技能
冲突管理
引导
会议管理
（4） 会议（启动会议）
工具的学习，主要考点是：特征，运用场景。 不关注怎么使用工具。
答题技巧：
当范围抽象时，选大范围。
任何项目都需要项目章程。
2. 制定项目管理计划
注：
整合项目管理计划，跟各个子过程中的管理计划，同步进行。
2.1 制定项目管理计划：输入
（1）项目章程
（2）其他过程的输出
（3）事业环境因素
（4）组织过程资产
2.2 制定项目管理计划：输出
（1）项目管理计划
计划是团队成员来做，项目经理来整合。
计划做好后，要确认是否得到主要相关方的批准。
计划代表全部的工作，一切都要按计划执行，按计划监控。
项目管理过程中，所有的计划文件都要得到相关方的批准。
2.3 制定项目管理计划：工具和技术
（1）专家判断
（2）数据收集
头脑风暴
核对单
焦点小组
访谈
（3）人际关系与团队技能
冲突管理
引导
会议管理
（4）会议
3. 指导与管理项目工作
注：
这一步，本质就是，按计划做。
一切工作都要按照计划来工作，计划外的工作，要走变更流程，实施批准的变更。
执行过程组的普遍性规律：做，且优化 （这就是有变更的原因）。
3.1 指导与管理项目工作：输入
（1）项目管理计划 all
（2）项目文件
需求跟踪矩阵
项目进度计划/里程碑/清单
2册（经验教训/风险）
变更日志
风险报告
项目沟通记录
（3）批准的变更请求
（4）事业环境因素
（5）组织过程资产
3.2 指导与管理项目工作：输出
（1）可交付成果
（2）工作绩效数据
（3）问题日志 （注意，这里是执行过程产生的问题日志，而不是监控阶段）
主要记录问题，问题责任人，什么时候解决。
关于问题的解决方案等，会在经验教训登记册中。
要理解：问题日志，经验教训登记册
（4）变更请求 （对项目工作做优化）
（5）项目管理计划更新all
（6）项目文件更新
需求文件
活动清单
假设日志
3登记册（经验，风险，相关方）
（7）组织过程资产更新
3.3 指导与管理项目工作：工具和技术
（1）专家判断
（2）项目管理信息系统
（3）会议
开踢会议，通常在规划阶段结束时，或执行阶段开始时。
也叫士气动员大会。
4. 管理项目知识
4.1 管理项目知识：输入
（1）项目管理计划
所有组件
（2）项目文件
经验教训登记册
项目团队派工单
资源分解结构
供方选择标准
相关方登记册
（3）可交付成果
（4）事业环境因素
（5）组织过程资产
4.2 管理项目知识：输出
（1）经验教训登记册
考试里，如果选择项中有经验教训登记册，基本都是选它。
因为经验教训登记册出现在很多过程的输入和输出中。
经验教训登记册和问题日志的区别。
（2）项目管理计划更新
（3）组织过程资产更新
4.3 管理项目知识：工具和技术
（1）专家判断
（2）知识管理
（3）信息管理
（4）人际关系与团队技能
积极倾听
引导
领导力
人际交往
政治意识
补充：
（1）多数考题中有经验教训登记册的时候，一般都选它。
（2）最重要的项目管理三大流程：
变更控制流程
问题解决流程
风险处理流程
5. 监控项目工作
注：
（1）这一步主要进行：发现偏差，找解决方案，纠正偏差。
（2）纠偏：
是否按计划进行？绩效是否达标？结果是否符合要求？
（3）16字：
比照基准或计划，分析差异，提出变更，跟踪执行
5.1 监控项目工作：输入
（1）项目管理计划
（2）项目文件
估算依据/里程碑清单
2预测（进度/成本）
2日志（假设/问题）
2登记册（风险/经验）
2报告（质量/风险）
（3）工作绩效信息
（4）协议
（5）事业环境因素
（6）组织过程资产
5.2 监控项目工作：输出
（1）工作绩效报告
（2）变更请求
（3）项目管理计划更新
组织文件
（4）项目文件更新
成本预测
进度预测
经验教训登记册
风险登记册
问题日志
5.3 监控项目工作：工具和技术
（1）专家判断
（2）数据分析
挣值分析
趋势分析
偏差分析
根本原因分析
备选方案分析
成本效益分析
（3）决策
（4）会议
6. 实施整体变更控制
注：
（1）对变更进行审批
（2） 将变更处理的结果进行沟通
6.1 实施整体变更控制：输入
（1）项目管理计划
变更/配置，管理计划
3个基准
（2）项目文件
估算依据
需求跟踪矩阵
风险报告
（3）工作绩效报告
（4）变更请求
（5）事业环境因素
（6）组织过程资产
6.2 实施整体变更控制：输出
（1）批准的变更请求
（2）项目管理计划更新
任何组件
（3）项目文件更新
变更日志
6.3 实施整体变更控制：工具和技术
（1）专家判断
（2）变更控制工具
配置管理：强调变更请求是否符合技术规范。即按照标准模板提变更。
变更管理：强调对变更的处理流程是否规范。
（3）数据分析
备选方案分析
成本效益分析
（4）决策
投票
独裁型决策制定
多标准决策分析
（5） 会议
注意：
（1）任何相关方可提变更请求。
（2）团队成员要维护项目范围，不能随意提变更。在项目管理中，识别出风险，偏差等问题时，可提。
6.4 变更态度规则（！掌握）
6.5 不同阶段变更应对策略
6.6 变更审批权限
6.7 变更控制流程（重要！！！）
注：
1. 任何相关方都可提变更请求
2. 团队跟相关方整理，确认变更请求
3. 项目经理和团队一起评估变更请求对项目的综合影响
4. 将评估结果告知提变更的相关方，然后由相关方来做判断是否继续变更
5. 如果相关方取消变更，此时仍然需要更新相关文件。
如果相关方坚持变更，此时由团队来判断是变更否涉及到基准。
如果不涉及基准，此时项目经理可以批准，或者不批准。
如果不批准，同样需要更新文件，通知相关方。如果批准，可能动用应急储备处理变更，同样，更新文件，，通知相关方，执行变更。
如果涉及基准，项目团队将变更和解决方案提交给CCB审批。
CCB批准变更，则更新相应的计划和文件，因为基准发生变更所以计划需要更新，通知相关方。
CCB不批准变更，则更新文件，通知相关方。
如果通知相关方后，相关方不能接受，那这个就不属于这个流程要处理的问题。
而是后面相关方管理，沟通管理过程需要处理的问题。
6.8 实施整体变更控制总结：变更请求线索
7. 结束项目或阶段
注：
1. 这个阶段所做的工作，都是项目的正常工作，并不意味着这里项目就彻底结束了。
2. 一旦进入收尾过程，意味着创造可交付性成果的工作结束了。
3. 进入收尾过程，提任何需求，都不再做任何调整，最多就是记录而已。
4. 对相关方来说，项目结束了。对项目团队内部来说，项目还没有结束，还有总结等工作。
7.1 结束项目或阶段：输入
（1）项目章程
（2）项目管理计划all
（3）项目文件
需求文件/质控制测量结果
估算依据/里程碑清单
3日志（假设/变更/问题）
2登记册（经验教训/风险）
2报告（质量/风险）
项目沟通记录
（4）验收的可交付成果
（5）商业文件
商业论证/效益管理计划
（6）协议
（7）采购文档
（8）组织过程资产
7.2 结束项目或阶段：输出
（1）项目文件更新
经验教训登记册
（2）最终产品，服务或成果移交
（3）最终报告 （！重要）
最终报告里不会做绩效评估（这个是在监控过程组去做），只是会对绩效好或不好的原因做说明。
会说明达标或不达标。
总结经验教训的行为，而不是在这里对绩效做评判。
（4）组织过程资产
7.3 结束项目或阶段：工具和技术
（1）专家判断
（2）数据分析
文件分析
回归分析
趋势分析
偏差分析
（3）会议
7.4 收尾流程
注：
1. 明确收尾程序：是在规划过程中明确清楚
2. 产品核实：核实产品质量是否合格，代表产品是不是正确的（通过控制质量过程判断产品质量合格，则代表质量得到验收）
3. 客户和发起人验收：在确认范围环节
4. 然后，就进入收尾过程。第一个就是移交成果，移交给客户发起人。
5. 财务收尾：付款等
6. 更新记录：相关文件内容
7. 审查项目成败，总结经验教训
8. 文件归档，包括项目报告
9. 结束采购
10. 团队成员绩效评估，这里不是考核，是评估。考核的权力在职能经理。
11. 遣散资源
12. 庆功会，结束。
【敏捷型生命周期】
1. 敏捷环境下整合分工
补充：
（1）PM在敏捷中可有可无，SM可替代。但不能说SM就是PM。
（2）PM的整合职能，在敏捷中被分割了。
（3）
PO：整合需求，整合产品功能，体现产品价值优先的原则
SM：营造氛围，教导方法，排除障碍
DT：对工作内容，范围，工作如何开展等的确定。
（4）
PB：产品待办事项列表
SB：冲刺（迭代）待办事项列表
PSI：进度绩效指数
2. 敏捷环境下整合框架
3. 敏捷章程
注：
（1）项目章程：
涉及未来的工作内容，项目目标，用来指导未来的工作开展。由DT来制定。
（2）团队章程：
工作规则，价值观。
4. 敏捷规划
补充：
（1）PB：
产品待办事项
产品的需求，功能的优先级
（2）SB：
冲刺（迭代）待办事项
代表工作开展的优先级
（3）PSI：
进度绩效指数
当前的冲刺任务
具体产品代办事项列表的清单
5. 敏捷计划 & 执行 & 监控
注：
1. 用户故事：描述业务场景，描述需求，解释需求。需求未来会转化为产品的功能。由客户或PO来编写。
2. 用户故事点：代表工作量。
6. 敏捷执行 & 监控 & 收尾
7. 敏捷环境下变更
注：
1. 敏捷里，拥抱变更。
2. 变更指的是需求的变更，由PO决定。开发团队服从响应就可以，可以提建议，但是由PO决定。
3. PO代表客户，他想要什么，是开发团队需要实现的价值。
4. 当前的迭代中，不允许需求变更。
5. 开发的工作，没有所谓的变更流程。随时调整工作节奏。开发团队本身就是工作的主导者，随时适应，随时调整。
8. 敏捷环境下收尾
注：
1. 评审会：产品的演示和验收。
演示由开发团队来，验收由PO来。
如果不能通过验收，提出意见，开发团队继续去优化产品。
2. MVP：最小化可行性产品，最小化可工作的软件。
越小，周期越短的交付，给客户带来的价值越大。
可独立进行工作，产生价值。
3. 回顾会议：总结经验教训。
89
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
