第四章整合管理

来源:互联网 发布:人工智能类电影 编辑:程序博客网 时间:2024/05/29 08:47

项目整合全路径:

1、制定项目章程(输出项目章程);
2、制定项目管理计划(输出项目管理计划);
3、指导与管理项目工作(输出可交付成果);
4、监控项目工作(输出工作绩效报告),实施整体变更控制(输出批准的变更请求);
5、结束项目或阶段

整个项目:部件+相互关系(局部+接口)

项目整合管理包括为识别、定义、组合、统一和协调各项目管理过程组的各种过程和活动而开展的过程与活动
当过程之间发生相互作用时,整合能力尤其重要。
项目经理最重要的角色就是整合者,有接口的地方就是整合。
选择资源分配方法,平衡相互竞争的目标和方案,管理知识领域之间的依赖关系。
有接口的地方就需要整合。
项目工作说明书(sow(Statement of work)):业务需要(商业需求)、产品范围描述、战略计划

专家判断

组织内的其他部门;顾问;干系人,包括客户或发起人;专业与技术协会;行业团体;主题专家(SME);项目管理办公室(PMO)

商业论证

从商业角度论证,决定项目是否值得投资
包括业务需求与成本效益分析

净现值(NPV)(优先考虑)

净现值=未来收益的现金流折现-初始投资额
NPV考虑了风险
各阶段净现值求和,即为项目最终财务净现值
净现值大于零,方案基本可行,净现值越大,方案越优,投资效益越好
越大越好

内部收益率(IRR)

Internal Rate of Return
净现值为零时的折现率就是项目的内部收益率
IRR越大越好(至少大于行业基准内部收益率)

投资回收期(PBT)

累计的经济效益等于最初的投资费用所需要的时间
静态投资回收期:不考虑时间价值;
动态投资回收期:先折现,再计算;
越短越好

效益成本比(BCR)/投资利润率(ROI)

分子为利润、分母为成本
Benefit Cost Ratio
净利润与成本之比
越大越好

Return On Investement
投资利润率=(年)利润总额/总投资*100%
越大越好

协议

通常为外部客户做项目时,就是指的合同

引导技术

通过流程引领人们达成共同目标的艺术
发起人/项目经理
发起人引导项目章程
项目经理引导项目管理计划

引导者的注意点

严禁使用反问句、不掺杂自己的主观想法、善于确认和总结、巧妙处理冲突

制定项目章程

制定一份正式批准项目或阶段并授权PM动用资源的文件。
编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。

输入 工具和技术 输出 1、项目工作说明书(甲方来写) 1、专家判断 1、项目章程 2、商业论证 2、引导技术 3、协议(agreement) 4、事业环境因素(通常不发生变化) 5、组织过程资产(经常发生变化)

项目章程是由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理动用组
织资源开展项目活动的文件。在项目章程中记录业务需要、假设条件、制约因素、对客户需
要和高层级需求的理解,以及需要交付的新产品、服务或成果,例如:

项目目的或批准项目的原因;
● .可测量的项目目标和相关的成功标准;
● .高层级需求;
● .假设条件和制约因素;
● .高层级项目描述和边界定义;
● .高层级风险;
● .总体里程碑进度计划;
● .总体预算;
● .干系人清单;
● .项目审批要求(如用什么标准评价项目成功,由谁对项目成功下结论,由谁来签署项目结束);
● .委派的项目经理及其权责;
● .发起人或其他批准项目章程的人员的姓名和职权。

  • 明确项目边界,确立项目经理地位,高级管理层直述他们对项目的支持。
  • 最好在制定项目章程时任命项目经理,最晚也必须在规划开始之前。
  • 由项目以外的实体来启动批准。
  • 最早记录假设条件、制约因素。
  • 如何让干系人签字:充分利用假设条件、层层推进、道明不签字的后果、分而治之。
  • 项目章程的作用:批准项目正式启动、任命项目经理、授权项目经理使用资源的权利。

制定项目管理计划

对定义、编制、整合和协调所有子计划所必需的行动进行记录的过程。
定义、准备和协调所有子计划,并把它们整合为一份综合项目管理计划的过程。项目管理计划包含经过整合的项目基准和子计划。

输入 工具和技术 输出 1、项目章程 1、专家判断 1、项目管理计划 2、其他过程的输出 2、引导技术 3、事业环境因素 4、组织过程资产

项目管理计划体现了“如何去管理”
定义项目的执行、监控、收尾的方法

项目管理计划需要渐进明细

通过整体变更控制过程,项目管理计划将会得到相应的更新和修改

项目基准包括:范围基准、进度基准、成本基准
项目基准应该放到项目管理计划当中。

子管理计划包括:范围管理计划、进度管理计划、成本管理计划、质量管理计划、人力资源管理计划、沟通管理计划、 风险管理计划、采购管理计划、干系人管理计划
需求管理计划(范围知识域)、过程改进计划(质量管理的监控过程组)
(两个输出的子计划)(两个不输出的子计划)?

项目治理方法的内容:变更管理计划,配置管理计划

项目文件:

  • 规划过程组生成项目管理计划和项目文件
    • 项目文件是项目过程中生成的文件
    • 项目文件与项目管理计划互斥,不在项目管理计划中的文件都是项目文件

项目管理计划与项目文件的区别

项目管理计划 项目文件 变更管理计划 活动属性 项目人员分派 沟通管理计划 活动成本估算 项目工作说明书 配置管理计划 活动持续时间估算 质量核对表 成本基准 活动清单 质量控制测量结果 成本管理计划 活动资源需求 质量测量指标 人力资源管理计划 协议 需求文件 过程改进计划 估算依据 需求跟踪矩阵 采购管理计划 变更日志 资源分解结构 范围基准:项目范围说明书、WBS、WBS字典 变更请求 资源日历 质量管理计划 预测:成本预测、进度预测 风险登记册 需求管理计划 问题日志 进度数据 风险管理计划 里程碑清单 卖方建议书 进度基准 采购文件 供方选择标准 进度管理计划 采购工作说明书 干系人登记册 范围管理计划 项目日历 团队绩效评价 干系人管理计划 项目章程、项目资金需求、项目进度计划、项目进度网络图 工作绩效数据、工作绩效信息、工作绩效报告

指导与管理项目工作

执行项目,执行的是项目管理计划的内容
为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。

输入 工具和技术 输出 1、项目管理计划(原始的项目管理计划) 1、专家判断 1、可交付成果(Deliver results) 2、批准的变更请求 2、项目管理信息系统 2、工作绩效数据 3、事业环境因素 3、会议 3、变更请求 4、组织过程资产 4、项目管理计划(更新) 5、项目文件(更新)

执行项目管理计划+批准的变更
项目经理与项目管理团队一起指导实施已计划好的项目活动、管理项目内的各种技术接口和组织接口
内部的可交付成果检查属于控制质量范围
外部验收属于范围中控制范围
工作绩效报告

(批准的)变更请求

  • 变更请求(书面记录);批准的变更请求(CCB批准);
  • 变更请求可以是直接或间接的,可以由外部或内部提出,可以是自选的
  • 必须是正式的
  • 过去的数据不改变
  • 纠正措施(一定不改变基准):为了使项目的工作绩效符合项目管理计划所做的工作。
  • 预防措施(一定不改变基准):为了降低与项目风险相关的负面后果发生的可能性所做的工作。
  • 缺陷补救(不一定改变基准):识别项目组成部分的某一缺陷后形成的文件,用于如何修补该缺陷或彻底替换该组件。
  • 更新(一定改变基准):对正规受控的文件或计划等的变更,以反映修改或增加的意见或内容。

项目管理信息系统(PMIS)

事业环境因素的一部分
关键绩效指标法(Key Performance Indicator,KPI)

  • 项目管理系统
    • 工作授权系统(正确的组织、正确的时间、正确的顺序规定授权程序、防止镀金)
    • 项目管理信息系统
      • 配置管理系统
        1. 变更管理系统
        2. 版本管理系统

配置管理系统

配置控制:关注可交付成果及各过程的技术规范(功能特征(强调一致性问题)+物理特征(强调完整性问题))
变更控制:识别、记录和控制对管理计划和控制对管理计划和基准的变更
配置管理活动:配置识别、配置状态记录、配置核实与审计
三要素:文字记录、跟踪系统、变更审批级别
配置管理重点强调是对版本控制的处理,功能特征和物理特征的检查(完整性和一致性的确认)

会议

高效会议/低效会议的特点

提前整理会议议程,并让大家提前准备
控制时间、控制议题和方向
充分调动每一个人,不浪费大家的时间
能站着不座着,能不带电脑就不带
会后立刻发送会议记录
会后跟踪结果

可交付成果

在某一过程、阶段或项目完成时,必须完成的任何独特并且可核实的产品、成果或服务。
也可包含项目管理计划
3种可交付成果状态:

  • (内部行为)核实(verify)的可交付成果:质量控制
  • (外部行为)验收的可交付成果:确认范围(validation)
  • 可交付成果的移交:结束项目或阶段
    线索:可交付成果–>核实的可交付成果(内部测试(控制质量))–>验收的可交付成果(确认范围)–>最终的可交付成果移交

工作绩效数据

项目工作收集的第一手资料线索:工作绩效数据(执行)---工作绩效数据(监控)---工作绩效报告(整合监控)

工作绩效数据:实际技术性能;实际进度绩效;实际成本绩效

监控项目工作

跟踪、审查和报告项目进展,以实现项目管理计划中确定的绩效目标和过程。

输入 工具和技术 输出 1、项目管理计划 1、专家判断 1、变更请求 2、进度预测 2、分析技术 2、工作绩效报告 3、成本预测 3、项目管理信息系统 3、项目管理计划(更新) 4、确认的变更 4、会议 4、项目文件(更新) 5、工作绩效信息 6、事业环境因素 7、组织过程资产

进度预测和成本预测用于预测报告的生成

变更:批注在前、确认在后
变更请求—>批准的变更请求—->确认的变更

变更请求: 项目变更的书面记录(第一份生成的文件)
变更日志: 对变更所有的状态记录
确认的变更: 对批准的变更执行情况的检查结果的记录

作用:让干系人了解项目的当前状态、已采取的 步骤,以及进行对预算、进度和范围的预测
贯穿整个项目周期

工作绩效报告

为制定决策,采取行动,引起关注而制定的实物/文件
包括:状态报告(关注项目状态)、备忘录、预测(通过挣值管理)、推荐意见、情况更新/进度报告

实施整体变更控制

审查所有变更请求,批准变更,并管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,对变更结果沟通的过程。
贯穿项目始终,收尾一般不做变更
确保只有经过批准的变更才可以试试
变更不论大小都要经过此过程审批
变更决策强调速度,需要快
变更通常需要跟发起人和客户确认
变更控制委员会(Change Control Board)CCB:由干系人正式组成的团队
PMI默认组织上都要有CCB

输入 工具和技术 输出 1、项目管理计划 1、专家判断 1、批准的变更请求 2、工作绩效报告 2、会议 2、变更日志(保存批准和批准的变更) 3、变更请求 3、变更控制工具 3、项目管理计划(更新) 4、事业环境因素 4、项目文件(更新) 5、组织过程资产

项目管理计划与变更请求的比较,通过变更控制工具,形成批准的变更请求。

变更产生原因

含义 举例 一个外部事件 市场环境变化、引为竞争对手举动引发的变更 产品范围定义的过失或者疏忽 软件需求分析时,某个模块定义不清楚 项目范围定义的过失或者疏忽 原来考虑的项目实施方法、遇到了技术问题,不能如期执行 一个增加值得变更 市场研发出了新的材料,可以替代原来材料,而且成本低(通常功能不变) 应对风险的紧急计划或回避计划 由于发生特定风险,需要调整项目计划

会议 召开的会议“变更控制会议”

变更控制会议,可以理解成CCB召开的会议(Change Control Meetings)
PM是CCB的成员但不是主任
大多数情况下,CCB处理与基准有关的变更
有时CCB也处理与基准无关的重大变更

变更控制流程(完成版)

1、对可能引起变更的因素施加影响,防止变更出现
2、一旦变更出现,先弄清楚变更到底是什么
3、口头变书面记录/书面申请(产生变更请求)
4、评价变更对某个直接制约因素的影响
5、全面评价变更对所有因素的综合影响
6、设计策略与应对方案
7、向CCB提交变更请求
8、CCB判断:批准或否定

批准: 不批准: 9、更新计划与项目文件(先更新计划,再更新日志) 9、记录到变更日志,继续监控 10、通知变更受影响的干系人 11、追踪变更的试试情况与效果

变更控制流程(简化版)

1、书面记录变更请求
2、分析影响
3、提交CCB进行审批
4、批准或者拒绝
5、若批准,修改计划,体现变更

结束项目或阶段

完结所有项目管理过程组的所有活动,以正式结束项目或阶段的过程

输入 工具和技术 输出 1、项目管理计划 1、专家判断 1、最终产品、服务或成果移交 2、验收的可交付成果 2、分析技术 2、组织过程资产(更新) 3、组织过程资产 3、会议

验收的可交付成果(外部,属于监控过程组生成)经过专家判断以及分析技术形成最终产品的移交。
项目如果提前终止需要更新组织过程资产。
成果移交+经验总结+文件记录/审核+资源遣散。
项目经理需要审查以前各阶段的收尾信息,确保所有项目工作都已完成,确保项目目标已实现。
如果项目提前终止,需要制定程序来调查和记录提前终止的原因,并记录项目执行的水平。
后评价一般在项目结束之后实施。

收尾程序

1、确定具体收尾程序
2、将项目成果全部移交
3、完成经验教训总结
4、文件审核/归档
5、资源遣散(PMBOK中在规划阶段考虑)