项目整合管理
项目管理中五大过程中、十大知识体系,在实际项目运行过程中是彼此交叉、关联的,在管理过程中,不能单独的考虑、解决某个领域的问题,头痛医头,脚痛医脚,需要对其进行综合考虑、管控。
项目整合管理由项目经理负责,其他领域知识可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但项目整合管理的责任不能被授权或转移
项目的方向-----项目章程
项目的计划-----项目管理计划
1. 制定项目章程
敲定项目的目标,努力很重要,选择更重要。
编写一份正式批准项目并授权项目经理在项目中使用组织资源的文件的过程
做用是明确项目与组织战略目标之间的直接联系,确立项目的正式地位的,并展示组织对项目的承诺。
输入 | 工具与技术 | 输出 |
---|---|---|
1. 商业文件(商业论证、效益管理计划) 2. 协议 3. 事业环境因素 4. 组织过程资产 | 1. 专家判断 2. 数据收集(头脑风暴、焦点小组、访谈) 3. 人际关系与团队技能(冲突管理、引导、会议) 4. 会议 | 1. 项目章程 2. 假设日志 |
项目章程由项目启动者或发起人发布的,项目章程一旦被批准,就标志着项目正式启动。在项目中,应尽早确认并任命项目经理,最好在制定项目章程时就任命,且总应在规划开始之前任命。
项目章程可以由发起人编制,或者由项目经理与发起机构合作编制。
注意:项目经理无权直接修改或批准项目章程,项目经理属于被授权
项目经理对项目章程和商业论证只有建议权
项目由项目外的人发起(发起人)
1.1 项目章程内容
项目章程由项目启动者或发起人发布,正式批准项目成立,并授权项目经理使用组织资源开展项目活动的文件。项目章程记录了关于项目与项目预期交付的产品、服务或成果的高层级信息,如:
- 项目目的
- 可测量的项目目标和相关的成功标准 -------------------- 注意区分成功标准和验收标准
- 高层级需求
- 高层级(high level)项目描述、边界定义以及主要可交付成果(粗颗粒度需求描述、范围描述)
- 整体项目风险
- 预先批准的财务资源
- 总体里程碑进度计划
- 关键相关方名单
- 项目审批要求(如用什么标准评价项目成功,由谁对项目成功下结论,由谁来签署项目结束);
- 项目退出标准(如在何种条件下才能关闭或取消项目或阶段)
- 委派的项目经理及其职责和职权
- 发起人或其他批准项目章程的人员的姓名和职权
1.2 输入文件
商业文件:项目章程包含来源于商业文件中的相关项目信息。既然商业文件不是项目文件,项目经理就不能对他们进行更改或修订,只能提出修改建议。
协议:包含合同、谅解备忘录(MOU)、服务水平协议(SLA)、协议书、意向书、口头协议、电子邮件或其他书面协议。
项目章程不等同于合同,因为其中不约定任何金钱\报酬\用于交换的对价.
事业环境因素:
组织过程资产:
1.3 工具和技术
工具本身也不是独立的,而是交叉一体的,比如头脑风暴中使用的有专家判断、冲突管理、会议管理等技术
头脑风暴(未知事件,需要集思广益时使用) —> 大胆假设 —> 亲和图(提炼) —> 名义小组(投票排序) —> 小心求证
专家判断:基于某些应用领域\知识领域、学科和行业的专业知识而做出,关于当前活动的合理性判断。专业知识可以来自具有专业学历、知识、技能、经验和培训经历的任何小组和个人。在十大知识领域中都有应用。
冲突管理:有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其它内容达成一致性意见
引导:又叫引导式研讨会,通常是跨职能团队人员一起开会讨论。是指有效引导团队活动成功以达成决定,解决方案或结论的能力。引导着确保参与者有效参与,相互理解,综合所有意见,按既定决策流程全力支持得到的结果或结论,以及所达成的行动计划和协议在之后得到合理的执行。
会议管理:包括准备议程、确保邀请每个关键相关方群体的代表,以及准备和发送后续的会议纪要和行动计划
1.4 输出
假设日志:
做事情前都会有一些默认的假设前提条件,这些条件有可能不为真,对项目造成影响
- 项目启动前编制商业论证的时候,识别高层级的战略和运营假设条件和制约因素。这些假设条件和制约因素应该纳入到项目章程中
- 较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。
- 假设日志用于记录整个项目生命周期中的所有假设条件和制约因素的单独文件
2. 制定项目管理计划
制定项目管理计划是定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合的项目管理计划的过程。本过程的主要作用是生成一份综合文件,用域确定所有项目工作的基础及其执行方式,仅开展一次或在预定义节点开展-----渐进明细
项目管理计划是前期学习的各种计划的综合,告诉我们怎么做项目、做什么内容。
项目经理牵头,由项目团队共同制定项目管理计划。
项目团队通常把项目章程作为项目的起点,项目管理计划作为规划阶段的终点 ,执行阶段的开始
项目管理计划制定后,有重要相关方批准同意,项目管理计划才能成为项目执行的基准
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目章程 2. 其他过程的输出 3. 事业环境因素 4. 组织过程资产 | 1. 专家判断 2. 数据收集(头脑风暴、焦点小组、访谈) 3. 人际关系与团队技能(冲突管理、引导、会议) 4. 会议 | 项目管理计划 |
项目管理计划应基准化,至少应规定项目的时间、范围、成本方面的基准,以便据此考核项目执行情况和管理项目绩效。
在确定基准之前,可能要对项目管理计划进行多次更新,且这些更新无需遵循正式流程,但是,一旦确定了基准,就只能通过实施整体变更控制过程进行变更
项目章程 | |||
---|---|---|---|
项目管理计划 | 开工会议 | 项目文件 | |
范围管理计划 | 范围基准 | 项目范围说明书 | |
需求管理计划 | 需求文件、需求跟踪矩阵 | ||
进度管理计划 | 进度基准 | 活动属性、活动清单、持续时间估算、里程碑清单、项目进度计划 | |
成本管理计划 | 成本基准 | 估算依据、成本估算、成本预测 | |
质量管理计划 | 质量控制测量结果、质量测量指标、质量报告、测试与评估文件 | ||
资源管理计划 | 物质资源分配表、项目日历、项目团队派工单、资源分解结构、资源日历 | ||
沟通管理计划 | 项目沟通记录 | ||
风险管理计划 | 风险登记册、风险报告 | ||
采购管理计划 | |||
相关方管理计划 | 相关方登记册 | ||
变更管理计划 | 变更日志、问题日志 | ||
配置管理计划 | |||
绩效测量基准等文件 | 假设日志、经验教训登记册 |
2.1 项目启动会(开工会议kick-off meeting)
-
在制定项目管理计划过程中,可以通过会议讨论项目方法,确定为达成项目目标而采用的工作执行方式,以及制定项目监控方法。
-
项目启动会通常意味着规划阶段结束、执行阶段开始,旨在
a. 传达项目目标
b. 获得团队对项目的承诺
c. 阐明每个相关方的角色和职责 -
项目启动会可能在不同时间点举行,对于多阶段项目,通常在每个阶段开始时都要举行一次项目启动会
区别 kick-off meeting(开工会议)和initiating meeting(启动会议)
- kick-off meeting:规划阶段结束有了项目管理计划后,执行阶段开始之前开
- initiating meeting:启动阶段有了项目章程后,规划阶段开始前开这个会
3. 指导与管理项目工作
为实现项目目标而领导和执行项目管理计划中确定的工作,并实施已批准变更的过程---------照着计划做事
主要作用是,对项目工作和交付成果开展综合管理,提高项目成功的可能性
在整个项目期间都需要开展
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目管理计划(任何组件) 2. 项目文件(变更日志、经验教训登记册、里程碑清单、项目沟通记录、项目进度记录、需求跟踪矩阵、风险登记册、风险报告) 3. 批准的变更请求 4. 事业环境因素 5. 组织过程资产 | 1. 专家判断 2. 项目管理信息系统(PMIS) 3. 会议 | 1. 可交付成果 2. 工作绩效数据 3. 问题日志 4. 变更请求 5. 项目管理计划更新(任何组件) 6. 项目文件更新(活动清单、假设日志、经验教训登记册、需求文件、风险登记册、相关方登记册) 7. 组织过程资产更新 |
3.1 问题日志
与风险不同,风险是未来可能发生的问题,可能对项目产生影响,问题是已经发生的事情,已经对项目产生了影响
在整个项目生命周期中,项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理,以免影响项目绩效。
问题日志是一种记录和跟进所有问题的项目文件,所需要记录和跟进的内容包括不限于:
- 问题类型
- 问题提出者和提出时间
- 问题描述
- 问题优先级
- 问题处理人(接单人)
- 预计解决时间
- 问题状态
- 最终解决情况
主要解决两个问题:
- 防止没人负责,遗漏
- 防止问题被过度解决,造成资源浪费
问题日志可以帮助项目经理跟踪、管理问题,确保问题得到调查和解决。尽管项目生命周期中任何时候都可能发生问题,但作为指导与管理项目工作阶段的输出,问题日志在这个阶段被创建出来。在整个项目生命周期中应该随同监控活动同步更新问题日志
使用问题日志的“时机”:
- 已经产生的问题、问题的跟踪、解决方案等都要查看/更新问题日志
- 试题中寻找“问题、缺陷、问题如何解决”等关键字
- 某些事件对项目还没产生影响,但明确将会产生影响,可以当作问题来处理
- 出现问题时,不仅要考虑问题本身,还需要考虑可能带来的风险
问题处理流程:记录–分析–计划–执行–检查–回应
问题出现—更新问题日志—分析影响找原因—解决问题
3.2 变更请求
变更请求是关于修改任何文件、可交付成果或基准的正式提议
任何项目相关方都可以提出变更请求,可以口头或书面的形式提出,但都需要书面记录下来。
应该通过实施整体变更控制过程对变更请求进行审查和处理
变更请求来自项目内部和外部,是可选或由法律(合同)强制的。
变更请求包括:
- 缺陷补救:为了修正产品或产品组件不一致进行的活动。往往是质量补救,通常是事后措施
- 纠正措施:为了使工作绩效重新与项目管理计划一致而进行的活动,通常是事中措施
- 预防措施:为了确保项目工作的未来绩效与项目管理计划一致采取的活动,通常是事前措施
- 更新:对正式受控的项目文件或计划等进行变更,以反映修改或增加的意见或内容
4. 管理项目知识
管理项目知识是使用现有知识并生成新知识,以实现项目目标,并帮助组织学习的过程。
管理项目知识主要作用是利用已有的组织知识来创造或改进项目成果,并且使当前项目创造的知识可用于支持组织运营或未来项目或阶段
在整个项目期间都需要开展管理项目知识
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目管理计划(任何组件) 2. 项目文件(变更日志、经验教训登记册、里程碑清单、项目沟通记录、项目进度记录、需求跟踪矩阵、风险登记册、风险报告) 3. 批准的变更请求 4. 事业环境因素 5. 组织过程资产 | 1. 专家判断 2. 知识管理 3. 信息管理 4. 人际关系与团队技能(积极倾听、引导、领导力、人际交往、政治意识) | 1. 经验教训登记册 2. 项目管理计划更新(任何组件) 3. 组织过程资产更新 |
4.1 知识管理
不只是将知识记录下来,重在使用和分享
在整个项目阶段中都需要进行,而不是只在项目结束的时候做经验总结
-
显性知识:易用文字、图片和数字编辑的知识,就是很容易表达出来的知识
-
隐性知识:个体知识难以明确表达,如信念、洞察力和经验等
2.1.蕴含情境难以编撰,存在于专家的脑子里
2.2 主要通过交流和互动进行流动(渗透沟通)
知识管理指管理显性知识和隐性知识两种,旨在重复使用现有的知识并生成新的知识,重点在知识分享和知识集成
从组织角度看,知识管理是确保在项目开始之前,项目运行中,项目结束之后得到运用
常见问题:
- 根本没有将隐性知识整理成显性知识的制度
- 知识管理知识将知识记录下来用于分享
- 知识管理只是在项目结束时总结经验教训,以供未来项目使用
4.2 知识管理工具
知识管理工具和知识管理技术,将人联系起来,是他们能够通过交流互动生成新的知识,分享隐性知识,以及集成不同团队成员所拥有的知识。
知识管理工具包括:讲故事、人际交往(正式、非正式)、会议,工作跟随和跟随指导,讨论论坛(如焦点小组)、知识分享活动(如专题讲座,会议)、实践社区和特别兴趣小组、研讨会(包括问题解决会议和经验教训总结会)、创造力和创意管理技术、知识展会和茶座、交互式培训
4.3 信息管理
信息管理技术和工具,创建人和知识之间的连接,可以有效的促进简单、明显的显性知识的分享
信息管理工具:
- 编撰显性知识,如确定经验教训登记册的条目
- 经验教训登记册
- 图书馆服务
- 信息收集,通过查询网络或者阅读已发表的文章
- 项目管理信息系统(PMIS)。项目管理信息系统通常包含文档管理(知识库)
4.4 经验教训登记册
本项目中的问题日志裁剪后录入经验教训登记册。项目关闭后,经验教训登记册裁剪后并入组织过程资产
包含的内容:
- 可以包含情况的类别和描述
- 可以包含与情况相关的影响、建议、行动方案
- 可以记录遇到的挑战、问题、意识到的风险和机会,或其他适用的内容
经验教训登记册在项目早期,作为本过程的输出。在整个项目期间,可以作为很多过程的输入,也可以作为输出不断更新
在项目或阶段结束时,把相关信息归入经验教训知识库,作为组织过程资产的一部分
5. 监控项目工作
监控项目工作贯穿整个项目周期,包括收集、测量和分析测量的结果,以及进行趋势预测,以便于推动过程改进
持续的监督使项目能及时发现需要特别关注的点,便于洞察项目的健康状况
控制包括指定纠正和预防措施或指定新规则,并跟踪行动计划的实施过程,以保证它们能有效的解决问题。
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目管理计划(任何组件) 2. 项目文件(变更日志、经验教训登记册、里程碑清单、项目沟通记录、项目进度记录、需求跟踪矩阵、风险登记册、风险报告) 3. 工作绩效信息 4. 协议 5. 事业环境因素 6. 组织过程资产 | 1. 专家判断 2. 数据分析(备选方案分析、成本效益分析、挣值分析、根本原因分析、趋势分析、偏差分析) 3. 决策 4. 会议 | 1. 工作绩效报告 2. 变更请求 3. 项目管理计划更新(任何组件) 4. 项目文件更新(成本预测、问题日志、经验教训登记册、风险登记册、进度预测 |
工作绩效数据:执行项目工作过程中,监督、收集到的原始观察结果或测量值,是底层级的细节数据,需要分析、提炼后才能展现价值
工作绩效信息:对工作绩效数据,结合项目管理计划组件、项目文件和项目变量进行分析提炼后,得到的叫高层级项目状态信息。便于了解项目的执行情况
工作绩效报告:使用电子或实体手段,对工作绩效信息进行合并、记录、分发。可以辅助制定决策、采取行动或引起关注。可以根据项目沟通管理计划、通过沟通过程向相关方发送工作绩效报告。-----------给领导看
5.1 数据分析
-
备选方案分析
对多个备选方案进行比较、分析,选择较优选项
-
成本效益分析
通过比较项目的全部成本和效益,评估项目的价值
-
根本原因分析
-
挣值分析
-
趋势分析
旨在审查项目绩效随时间的变化情况,判断项目绩效正在优化还是恶化
-
偏差分析
将工作绩效数据与预设基准指标进行比较,判断偏差是否处于临界值区间内
5.2 变更请求
通过比对项目运行情况和项目管理计划,发现进度、范围等方面有偏差时,通过制定计划、措施,提交变更请求,实施整体变更请求
- 缺陷补救
- 纠正措施
- 预防措施
6. 实施整体变更控制
实施整体变更控制是审查所有的变更请求、批准变更、管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程
实施整体变更控制需要考虑变更对整体项目目标的影响,防止变更加剧整个项目的风险。
变更请求可能影响项目范围、产品范围以及任一项目管理计划组织内的任一文件
实施整体变更控制会在整个项目周期开展,项目经理对此承担最终责任。
参与项目的所有相关方、项目中任何时间点都可以体变更请求(不一定会实施),项目变更的起点是基准确定后,变更的终点是终验环节
变更请求可以通过口头提出,但所有变更都需要书面记录(需要分发给相关方),并纳入变更管理和配置管理系统中,变更的书面记录在变更日志中,记录变更的全生命周期
在基准确定前,变更无需正式受控于实施整体变更控制过程,但项目基准一旦确立,所有的变更就必须通过整体变更控制过程来处理
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目管理计划(变更管理计划、配置管理计划、范围基准、进度基准、成本基准) 2. 项目文件(估算依据、需求跟踪矩阵、风险报告) 3. 工作绩效报告 4. 变更请求 5. 事业环境因素 6. 组织过程资产 | 1. 专家判断 2. 变更控制工具 3. 数据分析(备选方案分析、成本效益分析) 4. 决策(投票、独裁型决策制定、多标准决策分析) 5. 会议 | 1. 批准的变更请求 2. 项目管理计划更新(任何组件) 3. 项目文件更新(变更日志) |
6.1 变更管理系统
项目管理系统、项目管理系统系统不一定会有一个有形 的系统,而是只一个逻辑系统
配置控制重点关注可交付成果及各个过程的技术规范
变更控制着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更
6.2 变更控制流程
- 提出变更请求(一定要书面记录)
1.1 项目任何干系人都可以提出变更申请
1.2 所有变更申请都必须要有书面记录,并纳入配置管理系统
1.3 区分内部提交的变更请求还是外部提出的,内部提出的需要先分析可行性,然后提交变更请求,如果是外部(项目团队之外)提的变更则直接提交变更申请。 - 变更影响分析(项目经理或者授权人)
2.1 项目经理负责,可自己或指定人员完成 - CCB(change control board变更控制委员会)审查批准(根据影响,不同的审核人) ------- 是项目变更的决策者
3.1 每个变更申请都必须有一位责任人批准或否决,通常是项目发起人或项目经理(不涉及基准)
3.2 必要时,由CCB进行审批批准
3.3 CCB已经批准,仍然有相关方有异议------以执行CCB指令为原则 - 变更实施
4.1 变更前,需要通知对应的相关方去执行,不同时间的变更申请,涉及的实施人员也不同 - 监控变更实施
5.1 项目经理负责已批准变更得到正确实施 - 结束变更
6.1 分发新文档
6.2 成果纳入配置管理
6.3 通知干系人
变更管理计划:会记录变更的流程、变更的模板,但并不涉及变更的具体事宜。项目管理计划的组成部分。
变更日志:记录变更执行的具体信息(CCB批准或驳回的变更都需要在变更日志中记录),变更进行到每一步都需要更新变更日志
7. 结束项目或阶段
结束项目或阶段是终结项目、阶段或合同的所有活动的过程,本过程主要作用是:
- 存档项目或阶段信息-----好的、坏的经验教训,总结为组织过程资产
- 完成计划的工作
- 释放组织团队资源以开展新工作
仅开展一次或尽在项目预定义节点开展
项目结束后,通常项目团队解散,资源释放到各职能团队
输入 | 工具与技术 | 输出 |
---|---|---|
1. 项目章程 2. 项目管理计划(所有组件) 3. 项目文件(假设日志、估算依据、变更日志、问题日志、经验教训登记册、里程碑清单、项目沟通记录、质量控制测量结果、质量报告、风险登记册、风险报告) 4. 验收的可交付成果 5. 商业文件(商业论证、效益管理计划) 6. 协议 7. 采购文档 8. 组织过程资产 | 1. 专家判断 2. 数据分析(文件分析、回归分析、趋势分析、偏差分析) 3. 会议 | 1. 项目文件更新(经验教训登册) 2. 最终产品、服务或成果移交 3. 最终报告(复盘会产出) 4. 组织过程资产更新 |
结束工作 | 组织过程资产更新 |
---|---|
项目文件形成最终版(总结经验教训) | 项目文件(含经验教训登记册) |
关闭合同协议(供应商) | |
最终报告 | 最终报告 |
最终产品、服务或验收成果 | 项目或阶段收尾文件 |
移交给运营或下一阶段 | 运营和支持文件 |
提前终止 | 正式收尾文件中说明终止原因 |
释放资源 |
7.1 关闭合同协议(主要是供应商)
为关闭项目合同协议或项目阶段合同协议所必须开展的活动,相关的协商处置(谈判等),通常由采购团队跟进处置
- 确认卖方的工作已通过正式验收
- 最终处置未决索赔(协商、可参考替代争议解决方案、仲裁、司法诉讼)
- 更新记录以反映最后的结果
- 存档相关信息供未来使用
7.2 编写最终报告
用最终报告总结项目绩效
最终报告可包含如下信息:
- 项目或阶段概述
- 范围、质量、成本、进度结果
- 关于项目过程中发生的风险或问题及解决情况的概述
- 最终产品、服务或成果确认信息的总结
- 关于最终产品、服务或成果如何满足商业计划所述业务需求的概述
7.3 通过最终产品、服务或成果验收
- 确保所有文件和可交付成果都已经是最新版本,且所有问题都已得到解决
- 确认可交付成果已交付给客户并已获得客户端正式验收
- 测量相关方的满意程度
- 验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目,还可能包括部分完成或中间的可交付成果
7.4 产品移交
项目交付的产品、服务或成果可转交给另一团队或组织,并由其在整个生命周期中进行运营、维护和支持
本输出所指的正是把项目交付的最终产品、服务或成果(对于阶段收尾,则是所在阶段的中间产品、服务或成果)从一个团队转交到另一个团队
7.5 提前终止
如果项目在完工前提前终止,结束项目或阶段过程还需要制定程序,调查和记录提前终止的原因, 并把该项目已完成和未完成的可交付成果移交他人,根据情况收回甲方应支付的账款
7.6 释放资源
各回各家·