# 概述
组装合并,汇总归纳
# 核心概念
- 在项目管理中,整合兼具统一、合并、沟通和建立联系的性质,这些行动应该贯穿项目始终。
- 项目整合管理由项目经理负责,并且整合管理的责任不能被授权或者转移。
- 项目经理必须对整个项目承担最终责任。
- 项目越复杂,相关方的期望越多样化,就需要越全面的整合方法。
# 发展趋势和新兴实践
- 项目整合管理知识领域要求整合所有其他知识领域的成果。
- 与整合管理过程相关的发展趋势包括:
- 使用自动化工具(如项目管理信息系统
PMIS
) - 使用可视化管理工具(便于看到实时状态,促进知识转移,促进相关方参与到问题解决中)
- 项目知识管理(应对项目人员的流动性和不稳定性;项目人员的流动性和不稳定性越来越高,就要求采用更严格的过程,以防止知识流失。 )
- 增加项目经理的职责(项目经理被要求介入启动和结束项目,例如开展商业论证和效益管理)
项目经理可以做商业论证,尽早了解,但最终需要发起人负责审批
如果早期没有参与,中途参与了应去审查这些前期文件,做好交接工作 - 混合型方法(敏捷或其他迭代做法、商业分析技术
BA
、组织变革管理方法等混合使用)
- 使用自动化工具(如项目管理信息系统
# 在敏捷和适应型环境中需要考虑的因素
迭代和敏捷方法中:
- 团队成员以领域专家的身份参与整合管理:
- 团队成员自行制定计划
- 团队成员自行决定各个组件的整合方式
- 团队成员以领域专家的身份参与整合管理:
与传统方法的比较:
- 对项目经理的期望不变,但把对具体产品的规划和交付授权给团队。
- 项目经理的关注点在于营造一个合作型的决策氛围,确保团队有能力应对变更。团队成员有广泛技能(而不是狭窄领域),则更利于合作型决策氛围。
# 启动
制定项目章程
- 制定项目章程
- 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程
立项书+任命书
本过程的作用:
- 明确项目与组织战略目标之间的直接联系
- 确立项目的正式地位
- 并展示组织对项目的承诺
“制定项目章程” 的几个注意点:
- 项目章程在项目执行组织
乙方/团队
与需求组织甲方/客户
之间建立起伙伴关系。 - 经批准的项目章程,意味着项目的正式启动。
- 项目由项目以外的实体来启动,如发起人(一般是指乙方的)、项目集或项目管理办公室等等。
项目经理不能批,不能启动
项目经理是用来实现目标的,不是用来定目标的。 - 尽早确认并任命项目经理,项目经理应该参与项目章程的制定,以便对项目需求有基本的了解。
- 项目章程可由发起人编制,或者由项目经理与发起机构合作编制。
- 最好在制定项目章程时就任命,最晚也必须在规划开始之前。
越早越好,最晚也要在规划之前
- 通过编制项目章程,来确认项目符合组织战略和日常运营的需要。
- 在执行外部项目时,通常需要用正式的合同来达成合作协议。
- 不要把项目章程看做合同,因为其中未承诺报酬或金钱或用于交换的对价。
- 项目章程在项目执行组织
A 公司承接了一个 B 公司的外包项目,谁负责给 A 公司的项目经理提供项目章程?
A 公司承接了一个 B 公司的外包项目,谁负责给 A 公司的批准项目章程?
项目章程让 “项目” 和 “项目经理” 名正言顺,那么,发布项目章程时需要包括什么内容
- 项目的目的
- 项目的目标和成功标准
- 项目的退出标准
- 概括的(高层级的)范围、进度、成本、风险
- 项目经理的责任和职权
- 发起人的姓名和职权
制定项目章程 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
商业文件
| 专家判断 | 项目章程 |
协议 | 数据收集技术
| 假设日志 |
事业环境因素 | 人际关系技能
| |
组织过程资产 | 会议 |
# 输入
以下输入不一定都要有,有什么用什么
# 1️⃣ 商业文件
- 商业文件
- 包含关于项目目标以及项目对业务目标的贡献等相关信息的文件。
- 它包括:商业论证、效益管理计划。
- 包含关于项目目标以及项目对业务目标的贡献等相关信息的文件。
- 商业文件是在项目之前制定的,需要定期审核。
- 商业文件不是项目文件,项目经理不可以对它们进行更新或修改,只可以提出相关建议。
- 商业论证
- 文档化的经济可行性研究报告,决定项目是否值得投资,论证项目的合理性和可行性。
- 包含商业需求和成本效益分析。
- 文档化的经济可行性研究报告,决定项目是否值得投资,论证项目的合理性和可行性。
- 效益管理计划
- 描述了项目实现效益的方式和时间,以及应制定的效益衡量机制。
# 2️⃣ 协议
- 协议
- 定义了启动项目的初衷。
- 协议的形式:
- 合同(为外部客户做项目时,协议通常就以合同的形式出现)
- 谅解备忘录(MOUs)
- 服务品质协议(SLA)
- 意向书等
# 工具和技术
# 1️⃣ 专家判断
- 专家判断
- 基于某应用领域、知识领域、学科和行业等的专业知识而做出的,关于当前活动的合理判断,这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人
人人都是“砖家”
任何具备相关专业知识或接受过相关培训的个人或小组就是专家。
# 2️⃣ 数据收集技术
- 头脑风暴
更重视数量而非质量
- 短时间内获得大量创意,是典型的信息收集技术。
- 原则是:不质疑、不分析、不批判、不反对,不包含分析过程。
- 短时间内获得大量创意,是典型的信息收集技术。
- 焦点小组
Focus Group
- 召集相关方和主题专家
subject matter expert, SME
讨论相关议题,比一对一访谈更有利于互动交流- 默认同职能,同职能同领域的一群人,聚焦在某一个点开的会
- 召集相关方和主题专家
- 访谈
- 通过与相关方直接交谈来了解相关信息。
- 一对一 / 多对多,直接交谈,在信任的环境下获取机密信息。
- 通过与相关方直接交谈来了解相关信息。
# 3️⃣ 人际关系技能
- 冲突管理
- 有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑等内容达成一致意见。
- 引导
- 有效引导团队活动成功以达成决定、解决方案或结论的能力。
- 会议管理
- 不要把不同的会议混在一起开;
- 面对面的会议效果最好,有时也需要举行虚拟会议。
- 应明确每个参会者的角色,确保有效参会;
- 会议要达成共识,要有行动计划;
- 会前有明确的议程;
- 会中切题,处理会议冲突;
- 会后形成书面的会议纪要。
# 4️⃣ 会议
- 在本过程中,与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息。
# 输出
# 1️⃣ 项目章程
- 项目章程
是项目的“宪法”,是项目经理的“尚方宝剑”
- 由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理动用组织资源开展项目活动的文件。
- 包含的内容:
- 委派的项目经理及其职责和职权
项目章程中最重要的一点
- 项目的目的、目标、项目的成功标准
- 高层级的需求、高层级的项目描述、高层级的战略和运营假设条件和制约因素、边界定义及主要可交付成果
范围
- 总体里程碑进度计划
进度
- 总体预先批准的财务资源(预算)
成本
- 整体项目风险
风险
- 关键相关方名单
资源的预分派
- 项目退出标准,例如,在何种条件下才能关闭或取消项目或阶段
- 项目审批要求,发起人或其他批准项目章程的人员的姓名和职权。
- 委派的项目经理及其职责和职权
遇到高层级的、总体的、涉及到战略的、整个项目层面的,很有可能就是选择项目章程;
项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识
# 2️⃣ 假设日志
高层级的假设条件与制约因素通常纳入项目章程。
- 假设日志
限制
- 用于记录整个项目生命周期中的所有假设条件和制约因素。
- 假设条件
威胁
- 不需验证即可视为正确、真实或确定的因素。
- 同时还应描述如果这些因素不成立,可能造成的潜在影响,俗称威胁。
- 不需验证即可视为正确、真实或确定的因素。
- 制约因素
机会
- 对项目或过程的执行有影响的限制性因素。
- 制约因素如果有变化,得到了放松,会带来机会。
制约因素是事业环境因素的一种,但是与事业环境因素又有区别
事业环境因素强调的是一个大的环境,只要在这个环境里面,所有的项目都要遵守。
制约因素更多的是针对于每一个项目来说的。
为什么要做计划,做什么方面的计划,计划最终需要不需要整合
- 计划是依据,是参照,是基准(base line)
- 范围、进度、成本、质量、资源、风险、采购等等 5~13 章各个领域都要计划
- 计划需要整合
# 规划
制定项目管理计划
- 制定项目管理计划
- 定义、准备和协调项目计划的所有组成部分(范围进度、成本等),并把它们整合为一份综合项目管理计划的过程。
本过程的作用:
- 生成一份综合文件,用于确定所有项目工作的基础及其执行方式。
项目管理计划可以是概括的或详细的,详细程度取决于具体项目的要求。
项目管理计划应该
- 足够强大:
可以应对不断变化的项目环境敏捷性
,这有利于项目进展产出更准确的信息。 - 基准化
确定基准前:可进行多次更新,无需遵循正式流程;
确定基准后:只能通过实施整体变更控制过程进行更新; - 渐进明细
在项目收尾之前,该计划需要通过不断更新来渐进明细,并且这些更新需要得到控制和批准。
- 足够强大:
制定项目管理计划 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目章程 | 专家判断 | 项目管理计划 |
其他过程的输出 | 数据收集
| |
事业环境因素 | 人际关系与团队技能
| |
组织过程资产 | 会议 |
# 输入
# 1️⃣ 项目章程
项目团队把项目章程作为初始项目规划的起始点。
# 2️⃣ 其他过程的输出
- 其他规划过程所输出的子计划和基准,都是本过程的输入。
- 对这些子计划和基准的变更都可能导致对项目管理计划的相应更新。
# 工具和技术
# 1️⃣ 数据收集
- 头脑风暴、核对单、焦点小组、访谈;
- 核对单
CheckList
- 指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
- 包括需要考虑的项目、行动或要点的清单,常被用作提醒。
# 2️⃣ 人际关系与团队功能
- 冲突管理、引导、会议管理;
- 引导
- 引导者确保参与者有效参与,互相理解,便于达成一致意见。
# 3️⃣ 会议
- 开工会议 kick-off meeting
- 规划尾开,是规划阶段要做的最后一件事情,旨在:
- 传达项目目标
- 获得团队对项目的承诺
- 阐明每个相关方的角色和职责
项目管理计划应该获得主要相关方的一致认可。
initiating meeting (了解) | 开工会议 kick-off meeting | |
---|---|---|
所属过程组 | 启动过程组 | 规划过程组 |
召开时间 | 启动即将结束,规划尚未开始的时 | 规划即将结束,执行尚未开始的时 |
主要任务 | 发布项目章程、任命并授权项目经理 | 获得主要相关方(公司的职能经理、相关部门的人等)对项目管理计划的一致认可;传达项目目标、获得团队对项目的承诺; |
其他事项 | 各相关方进行认识和会面、表达决心、调动积极性 | 落实具体项目工作,阐明每个相关方的角色和职责 |
考试时注意点 | 题中出现的 “启动会议” 字样,对照英文理解,如无英文对照时默认 "kick-off meeting" |
如果相关人员没空,不能参加 kick-off meeting,则应在会前或会后单独找其碰面,一定要获得他的支持和承诺,而不能只发会议纪要。
为什么项目管理计划需要主要相关方的批准
- 让主要相关方对项目管理计划有一致的理解;
- 获得主要相关方的支持和承诺,并作为项目工作的基准和依据;
- 不能随意修改或私下修改;
- 如果需要修改,一定要走合理的变更流程,并告知相关方。
# 输出
# 1️⃣ 项目管理计划
- 项目管理计划
- 是说明项目执行、监控和收尾方式的一份文件。
- 它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。
包括 10+2+3 基准 + 3 组件:
项目管理计划的组成部分
- 指南型计划(渔)
- 是一种指南,如何去管理 XX。强调的是
How
- 九大知识领域的十个子管理计划:范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、风险管理计划、采购管理计划、相关方参与计划。
- 二个子管理计划:变更管理计划、配置管理计划。
- 实体型计划(鱼)
- 具体描述范围包括哪些,工期多久,成本多少。描述的是
What
- 三大基准:范围基准、进度基准、成本基准。
- 其他组件
- 绩效测量基准、项目生命周期描述、开发方法。
项目管理计划是 “文件”,但是不是 “项目文件”
项目管理计划需要相关方的一致认可,需要经过变更流程的审批才能修改
项目文件是团队自行维护的,更倾向于工作过程的记录
项目管理计划 | 项目文件 | |
---|---|---|
1. 范围管理计划 | 1. 活动属性 | 19. 质量控制测量结果 |
2. 需求管理计划 | 2. 活动清单 | 20. 质量测量指标 |
3. 进度管理计划 | 3. 假设日志 | 21. 质量报告 |
4. 成本管理计划 | 4. 估算依据 | 22. 需求文件 |
5. 质量管理计划 | 5. 变更日志 | 23. 需求跟踪矩阵 |
6. 资源管理计划 | 6. 成本估算 | 24. 资源分解结构 |
7. 沟通管理计划 | 7. 成本预测 | 25. 资源日历 |
8. 风险管理计划 | 8. 持续时间估算 | 26. 资源需求 |
9. 采购管理计划 | 9. 问题日志 | 27. 风险登记册 |
10. 相关方参与计划 | 10. 经验教训登记册 | 28. 风险报告 |
11. 变更管理计划 | 11. 里程碑清单 | 29. 进度数据 |
12. 配置管理计划 | 12. 实物资源分配单 | 30. 进度预测 |
13. 范围基准 | 13. 项目日历 | 31. 相关方登记册 |
14. 进度基准 | 14. 项目沟通记录 | 32. 团队章程 |
15. 成本基准 | 15. 项目进度计划 | 33. 测试与评估文件 |
16. 绩效测量基准 | 16. 项目进度网络图 | |
17. 项目生命周期描述 | 17. 项目范围说明书 | |
18. 开发方法 | 18. 项目团队派工单 |
# 执行
指导与管理项目工作
- 指导与管理项目工作
- 为实现项目目标而领导和执行项目管理计划中确定的工作,并实施已批准变更的过程
本过程的作用:
- 对项目工作和可交付成果开展综合管理,以提高项目成功的可能性;
该过程会实施以下活动:
- 实施已计划好的项目活动;
- 管理项目内的各种技术接口和组织接口;
- 回顾所有项目变更的影响,并实施已批准的变更;
- 收集工作绩效数据并传达给合适的控制过程。
指导与管理项目工作 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目管理计划
| 专家判断 | 可交付成果 |
项目文件
| 项目管理信息系统 | 工作绩效数据 |
批准的变更请求 | 会议 | 问题日志 |
事业环境因素 | 变更请求 | |
组织过程资产 | 项目管理计划更新
| |
项目文件更新
|
# 输入
# 1️⃣ 项目管理计划
- 先有计划后执行,如有变化走变更。
- 项目管理计划的任何组件都可用作本过程的输入。
# 2️⃣ 批准的变更请求
- 批准的变更请求
- 实施整体变更控制过程的输出,可能是纠正措施、预防措施或缺陷补救。
- 注意,实施 “批准的变更请求” 归属于本过程。
# 工具和技术
# 1️⃣ 项目管理信息系统 PMIS
- 项目管理信息系统
PMIS
- 为指导和管理项目工作提供自动化工具,并用于自动收集和报告关键绩效指标
KPI
- 包括:进度计划软件工具、工作授权系统、配置管理系统、信息收集与发布系统。
- 为指导和管理项目工作提供自动化工具,并用于自动收集和报告关键绩效指标
- 工作授权系统
- 用来保证项目工作由正确的组织、在正确的时间以正确的顺序执行。
- 可以防止 “镀金”
# 2️⃣ 会议
会议类型:开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、 进展跟进会议、回顾会议。
参会者:
- 项目经理
- 项目团队成员
- 以及与所讨论事项相关或会受该事项影响的相关方
# 输出
# 1️⃣ 可交付成果
- 可交付成果
- 在某一过程、阶段或项目完成时,必须产出的任何独特并可核实的产品、成果或服务能力,通常是项目结果,并可包括项目管理计划的组成部分。
- 一旦完成了可交付成果的第一个版本,就应该执行变更控制。
# 2️⃣ 工作绩效数据
- 工作绩效数据
- 在执行项目工作的过程中,从每个正在执行的活动中收集到的原始观察结果和测量值。
- 在工作执行过程中收集数据,再交由控制过程做进一步分析
# 3️⃣ 问题日志
- 问题日志
- 一种记录和跟进所有问题的项目文件。
- 在此过程被首次创建,在整个项目生命周期应该随同监控活动更新。
- 包含的主要内容,即问题日志的三要素:
- 问题描述
- 问题责任人
- 解决期限
# 4️⃣ 变更请求
不管什么东西导致了计划无法实现,计划需要调整了,那么这个时候就要提出变更请求
- 变更请求
- 是关于修改任何文档、可交付成果或基准的正式提议。
- 可以是直接或间接的,可以由外部或内部提出,可能是自选或由法律 / 合同所强制的,可口头提,但必须书面记录。
包括:
- 纠正措施 —
纠偏差
事后
- 预防措施 —
防风险
事前
- 缺陷补救 —
补质量
针对质量缺陷
- 更新 —
通常改计划
- 纠正措施 —
纠正措施、预防措施,用来维护 “某些” 基准
更新,会修改计划或基准
- 我们现在的进度已经落后于计划了。
已经落后 = 纠正措施- 下个月我们会有一个长假,这可能会导致我们的进度落后。为了避免进度落后的情况发生,所以他这个月就提交了变更请求,要求增加资源。
防止出现问题 = 预防措施- 只针对质量而做的,可交付成果有缺陷或者有 bug 要处理,怎么办好,提变更请求
进行缺陷补救- 更新就是指直接改计划
# 执行
管理项目知识
- 管理项目知识
- 使用现有知识并生成新知识,以实现项目目标,并帮助组织学习的过程。
本过程的作用:
- 利用已有的组织知识来创造或改进项目成果,并使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。
- 本过程需要在整个项目期间开展。
知识包括:
显性知识 | 隐性知识 | |
---|---|---|
定义 | 易使用文字、图片和数字进行编撰的知识 | 个体知识以及难以明确表达的知识,如信念、洞察力、经验和 "诀窍" |
特点 | 缺乏情境,可作不同解读 (不同的人有不同的理解) | 虽蕴含情境,却很难编撰 |
误解 |
|
- 知识管理注意点:
- 组织角度看:在项目开始之前、开展期间和结束之后都能使用旧知识、生成新知识。
- 最重要的环节:营造一种相互信任的氛围,激励人们分享自己的知识和关注他人的知识。
- 实践中双管齐下:
- 知识管理工具和技术(用于人际互动)
- 信息管理工具和技术(用于编撰显性知识)
管理项目知识 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目管理计划
| 专家判断 | 经验教训登记册 |
项目文件
| 知识管理 | 项目管理计划更新
|
可交付成果 | 信息管理 | 组织过程资产更新 |
事业环境因素 | 人际关系与团队技能
| |
组织过程资产 |
# 输入
# 1️⃣ 项目文件
- 经验教训登记册:提供了有效的知识管理实践。
- 项目团队派工单:说明了项目已具有的能力和经验以及可能缺乏的知识。
- 资源分解结构:有助于了解团队拥有和缺乏的知识。
- 相关方登记册:有助于了解相关方可能拥有的知识。
# 工具和技术
# 1️⃣ 知识管理
- 知识管理工具和技术将员工联系起来,使他们能够合作生成新知识、分享隐性知识,以及集成不同团队成员所拥有的知识。
- 包括:工作跟随、跟随指导、人际交往、论坛、讲故事、交互式培训。
- 面对面互动最有利于建立知识管理所需的信任关系。
- 一旦信任关系建立,可以用虚拟互动来维护这种信任关系。
# 2️⃣ 信息管理
- 信息管理用于创建人们与知识之间的联系,编撰显性知识、经验教训登记册,可以有效促进简单、明确的显性知识的分享。
- 通过增加互动要素来强化,比如:增加 “与我联系” 的功能,使用户能够与经验教训发帖者联系,并向其寻求与特定项目和情境有关的建议。从而可以向隐性知识延伸。
# 3️⃣ 人际关系与团队技能
- 积极倾听
- 有助于减少误解并促进沟通和知识分享。
- 引导技术
- 有助于有效指引团队成功地达成决定、解决方案或结论。
- 领导力
- 可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标。
- 人际交往
- 促使项目相关方之间建立非正式的联系和关系,为显性和隐性知识的分享创造条件。
- 政治意识
- 有助于项目经理根据项目环境和组织的政治环境规划沟通。
# 输出
# 1️⃣ 经验教训登记册
在项目早期创建
在整个项目期间不断更新;
在项目或阶段结束时,归入经验教训知识库。
包含的内容
- 情况的类别和描述
- 与情况相关的影响、建议和行动方案
- 遇到的挑战、问题、意识到的风险和机会,或其他适用的内容
经验教训属于组织过程资产,是为了有利于未来的项目的。
当题目说到 “当前项目如何有利于未来的项目”,一律选择 “更新组织过程资产” 或 “总结经验教训” 之类的选项。
# 监控
监控项目工作
- 监控项目工作
- 跟踪、审查和报告整体项目进展,以实现项目管理计划中确定的绩效目标的过程
- 本过程的作用:
- 让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动
- 通过成本和进度预测,让相关方了解未来项目状态
- 监控项目工作贯穿于整个项目,是唯一输出工作绩效报告的过程
监控项目工作 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目管理计划
| 专家判断 | 工作绩效报告 |
项目文件
| 数据分析
| 变更请求 |
工作绩效信息 | 决策 | 项目管理计划更新
|
协议 | 会议 | 项目文件更新
|
事业环境因素 | ||
组织过程资产 |
输入信息,得到报告
# 输入
# 1️⃣ 项目文件
- 进度预测
- 基于项目以往的绩效,用于确定项目是否仍处于进度的公差区间内,并识别任何必要的变更。
- 成本预测
- 基于项目以往的绩效,用于确定项目是否仍处于预算的公差区间内,并识别任何必要的变更。
# 2️⃣ 工作绩效信息
工作绩效数据交由控制过程做进一步分析形成工作绩效信息,工作绩效信息是本过程的重要输入。
将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。
绩效包含:范围、进度、成本、质量以及项目管理计划中定义的其他
工作绩效信息为决策提供依据。
# 工具和技术
# 1️⃣ 数据分析
- 挣值分析
- 对范围、进度、成本绩效进行综合分析,发现偏差。
- 偏差分析
- 审查目标绩效与实际绩效之间的差异
计划 vs 实际
,可涉及持续时间估算、成本估算、资源使用、资源费率、 技术绩效和其他测量指标。 - 趋势分析
- 根据以往结果,预测未来绩效,提前发现问题,提前纠偏或预防。
- 根本原因分析
root cause analysis, RCA
- 寻找偏差或潜在问题的根本原因,从根源上解决,杜绝再次发生。
- 备选方案分析
- 选择要执行的措施的最佳组合,或最佳方案。
- 成本效益分析
- 确定最节约成本的措施。
# 2️⃣ 决策
- 决策技术包括投票:一致同意、大多数同意、相对多数原则。
# 输出
# 1️⃣ 工作绩效报告
基于工作绩效信息,以实体或电子形式编制工作绩效报告,以制定决策、采取行动或引起关注。
根据项目沟通管理计划,通过沟通过程向项目相关方发送工作绩效报告(状态报告、进展报告)
# 监控
实施整体变更控制
- 实施整体变更控制
- 审查所有变更请求、批准变更、管理变更、并对变更处理结果进行沟通的过程。
本过程的作用:
- 确保对项目中已记录在案的变更做综合评审,从而降低项目风险。
- 本过程只会审批、管理变更,不会提出变更请求(我们只处理变更,不生产变更)
实施整体变更控制的几个注意点
- 实施整体变更控制过程贯穿项目始终,项目经理对此负最终责任。
- 在基准确定之前,变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准,就必须通过本过程来处理变更请求。
- 应确保只有经批准的变更才能纳入修改后的基准中。
- 任何相关方都可以提出变更请求
- 可以口头提出,必须以书面形式记录,并纳入变更管理和 / 或配置管理系统中。
- 应该评估变更对时间和成本的影响,并向这些过程提供评估结果。
- 项目经理只负责主导评估,评估不是 PM 一人,需要和相关方沟通
- 每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,应在项目管理计划或组织程序中指定这位责任人,必要时,应由变更控制委员会
CCB
来开展实施整体变更控制过程。- 默认提交给 CCB 审批,但不是所有的都需要提交给 CCB
- 以项目文件更新的形式,在变更日志中记录所有变更请求的处理情况。如有必要,需要更新项目管理计划。
- 向相关方传达变更处理结果,以便其知晓并采取后续行动。
- 实施整体变更控制过程贯穿项目始终,项目经理对此负最终责任。
- 变更控制委员会
CCB
- 一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更,以及记录和传达变更处理决定。
- 可有甲方领导,乙方领导、PM,监理方,甲方代表(代甲方管理的)、专家组成员
实施整体变更控制 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目管理计划
| 专家判断 | 批准的变更请求 |
项目文件
| 变更控制工具 | 项目管理计划更新
|
工作绩效报告 | 数据分析
| 项目文件更新
|
变更请求 | 决策
| |
事业环境因素 | 会议 | |
组织过程资产 |
# 输入
# 1️⃣ 变更请求
向变更请求的提出者了解变更的具体内容或变更的原因,告知变更的流程,防止不必要的变更。(第 0 步)
若确认必须变更则走以下 5 步流程:
实施整体变更控制全流程
- 记录:
- 书面记录变更请求
- 项目经理书面记录(变更日志)
- 或要求变更提出者提交书面的变更请求给项目经理
- 书面记录变更请求
- 评估:
- 充分了解变更,(项目经理带着团队)评估变更带来的影响
- 与相关的相关方沟通评估出的影响
项目经理不要拒绝变更,也不要接受变更,只负责评估。
- 提交:
- 提交责任人审批
注意,这里的提交是指 “项目经理” 将变更请求和评估的结果提交给 CCB。
- 更新:
- 不管变更通过还是不通过,必须更新变更日志
- 如果变更通过,更新项目管理计划(文件)
- 通知:
- 应将变更的结果通知相关(受影响)的相关方。
- 记录:
变更必须要经过变更流程控制;
如果发现没有走变更就已经做了,也要补变更流程;
如果变更最终没有被批准,甚至需要取消不良变更。
如果变更已经获得了批准,那么最终就要执行批准的变更(哪怕有相关方不同意);
如果不同意批准的变更,可以重新提交新的变更请求,走新的变更流程。
变更题的常见考法:
- 变更的顺序
- 看看现在进行到了哪一步。
- 根据顺序(1 记录、2 评估、3 提交、4 更新、5 通知)来选择下一步做什么。
- 考要不要变更
当涉及到基准的修改的时候,需要走变更流程。(考试中几乎都是要走变更流程的)
注意常见的一些说法各自代表的意思:
- 要求客户提交一份变更请求 = 1 记录
- 分析变更对进度和成本带来的影响 = 2 评估
- 处理 process 变更请求 = 1~5 全过程
- 实施整体变更控制过程 = 1~5 全过程
- 创建一份变更请求 = 1 记录
遇到纠结的说法,可以参考英文。
# 2️⃣ 项目管理计划
变更流程需要参考的输入是项目管理计划,其中包括:
- 变更管理计划:变更管理计划为管理变更控制过程提供指导,并记录 CCB 的角色和职责。
- 配置管理计划:描述如何记录和更新项目的特定信息,以及该记录和更新哪些信息,以保持产品、服务或成果的一致性和(或)有效性。
- 范围基准、进度基准、成本基准:用于作为依据,评估影响。
- 变更请求:通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。
# 工具和技术
# 1️⃣ 变更控制工具
- 配置管理系统
- 项目管理系统的子系统,由一系列正式的书面程序组成,为以下配置管理活动提供技术和管理方面的指导与监督:
一识
配置识别:识别与选择配置项规划
二记
配置状态记录:关于各个配置项的信息记录和报告执行
三审
配置核实与审计:通过核实与审计保证配置项组成的正确性,及变更被正确实施监控
- 识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
- 项目管理系统的子系统,由一系列正式的书面程序组成,为以下配置管理活动提供技术和管理方面的指导与监督:
# 输出
# 1️⃣ 批准的变更请求
变更请求批准人的选择顺序:
- 项目管理计划或组织流程中指定的责任人。
最准确的说法,但不常见
- 变更控制委员会
CCB
。考试 “默认” 变更提交给 CCB 来审批,最常见的选择
- 如题中无以上选项,则可选 “PMO”、“发起人”、“项目经理”
- 项目管理计划或组织流程中指定的责任人。
注意,“批准的变更请求” 在 “指导与管理项目工作” 子过程中实施,本过程不包含实施工作。
# 2️⃣ 项目管理计划更新
- 对基准的变更,只能基于最新版本的基准且针对将来的情况,而不能变更以往的绩效。这有助于保护基准 和历史绩效数据的严肃性
# 3️⃣ 项目文件更新
- 变更日志
- 用来记录项目过程中出现的变更,被否决的变更请求也应该记录在变更日志中。不管变更有没有被批准,都需要更新变更日志。
# 收尾
结束项目或阶段
- 结束项目或阶段
- 终结项目、阶段或合同的所有活动的过程。
本过程的作用:
- 存档项目或阶段信息
- 完成计划的工作
- 释放组织团队资源以展开新的工作
结束项目或阶段注意点:
- 在项目结束时,项目经理需要回顾项目管理计划,确保所有项目工作都已完成以及项目目标均已实现。
- 若项目在完工前就提前终止,结束项目或阶段过程还是需要制定程序,来调查和记录提前终止的原因
正常收尾:
- 获得项目整体验收
形式验收,审查报告
- 移交最终成果
- 总结和记录经验教训
- 组织过程资产更新
- 文件归档
- 释放资源
- 获得项目整体验收
项目提前终止:
- 调查并记录原因
- 移交已完成和未完成的最终成果
- 总结经验教训
- 更新组织过程资产
- 存档
- 释放资源。
相关方满意度调查和庆功会也在这个阶段。
相关方满意度调查可以插入任何一步
庆功会一般要在释放资源之前
结束项目或阶段 | ||
---|---|---|
输入 | 工具和技术 | 输出 |
项目章程 | 专家判断 | 项目文件更新
|
项目管理计划
| 数据分析
| 最终产品,服务或成果移交 |
项目文件
| 会议 | 最终报告 |
验收的可交付成果 | 组织过程资产更新 | |
商业文件
| ||
协议 | ||
采购文档 | ||
组织过程资产 |
# 输入
# 1️⃣ 项目章程
- 项目章程记录了项目成功标准和退出标准、审批要求,以及由谁来签署项目结束。
# 2️⃣ 验收的可交付成果
- 验收的可交付成果
- 包括批准的产品规范、交货收据和工作绩效文件。
- 对于分阶段实施的项目或提前取消的项目,还可能包括部分完成或中间的可交付成果。
# 3️⃣ 商业文件
- 商业论证
- 用于确定项目是否达到了经济可行性研究的预期结果。
- 效益管理计划
- 用于测量项目是否达到了计划的效益。
# 4️⃣ 组织过程资产
- 项目或阶段收尾指南或要求
- 如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资 源重新分配、团队绩效评估,以及知识传递;
- 如果不知道如何收尾,可以参考收尾指南
- 配置管理知识库
- 包括组织标准、政策、程序和项目文件的各种版本及基准。
# 工具和技术
# 1️⃣ 数据分析
- 可用于项目收尾的数据分析技术有:文件分析、回归分析、趋势分析、偏差分析
# 2️⃣ 会议
用于确认可交付成果已通过验收,确定已达到退出标准,正式关闭合同,评估相关方满意度,收集经验教训,传递项目知识和信息,以及庆祝成功。
会议的类型包括:收尾报告会、客户总结会、经验教训总结会、庆祝会。
# 输出
# 1️⃣ 最终产品、服务或成果移交
- 把项目交付的最终产品、服务或成果(对于阶段收尾,则是所在阶段的中间产品、服务或成果)从一个团队转交到另一团队或组织,并由其在整个生命周期中进行运营、维护和支持。
# 2️⃣ 最终报告
- 用最终报告总结项目绩效。
# 3️⃣ 组织过程资产更新
- 项目文件
- 运营和支持文件
- 项目或阶段收尾文件:
- 表明项目或阶段完工的正式文件
- 把可交付成果移交给他人的正式文件
- 若项目提前终止,需要:
- 在正式的收尾文件中说明项目终止的原因
- 把已完成和未完成的可交付成果移交他人
- 经验教训知识库:把历史信息和经验教训信息存入经验教训知识库,供未来项目或阶段使用。
收尾的其他注意点:
- 项目完成收尾的标志:释放资源(解散团队)、项目或阶段收尾文件
- 释放资源是收尾的最后一步,如果已经彻底完成了收尾:
- 出现问题或缺陷,那么项目经理只需要及时地协调运营部门介入。
- 客户需要新增功能,可以建议客户新开一个项目。
- 如果还没有彻底完成收尾:
- 遇到问题或缺陷,项目经理必须积极处理,甚至可能需要走变更流程。
- 遇到新增功能,可以建议客户新开一个项目,或者走变更流程。
- 如果当前项目在收尾,又被分配了新项目,项目经理优先保证当前项目的收尾
# 重点总结
- 项目章程的作用、谁批准、制定项目章程的输入、输出的项目章程中包括的内容
- 制定项目管理计划的工具 kick-off 会议,什么时候开,目的是什么,需要谁认可
- 指导与管理项目工作的两个重要输入、输出
- 管理项目知识的三个要点:信任的氛围、工具、输出
- 监控项目工作的目的
- 实施整体变更控制的流程以及对流程的理解
- 收尾的步骤,关键的输入和输出
# 敏捷相关
在敏捷或适应型环境中需要考虑的因素
迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。
在适应型环境下,《整合管理的核心概念》中所述的对项目经理的期望保持不变,但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围,并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域,那么这种合作型方法就会更加有效。
- 对应知识点:
- 自组织团队
- 仆人式领导
- T 型人才解决知识孤岛