PMP-第4章-项目整合管理

698 阅读18分钟

4.1概述

4.1.1 基本概念

整合是指协调与统一。项目整合管理是项目管理的核心,是为了实现项目各要素之间的相互协调,并在相互矛盾或竞争的目标中寻找最佳平衡点。之所以需要整合管理,是因为项目的结合部最容易出问题。

项目内部的整合,肯定是项目经理的责任,项目外部的整合,项目经理至少要承担协助的责任。

需要整合的地方,无法一一例举,因为只要存在结合部,就需要整合。

4.1.2 项目经理作为整合者

项目经理在项目管理中的角色是多方面的,其中最重要的角色是“整合者”。

《PMBOK指南》特别强调,项目经理必须亲自承担项目整合管理的工作,而不能吧这个工作授权给任何其他团队成员去开展。

项目经理最重要的角色是整合者,必须通过沟通来协调,通过协调来整合。

4.1.3 整合管理在各知识领域中的地位

项目整合管理是项目管理的管理哲学,是项目管理与传统管理的最大区别所在。

项目管理是以整合为主,分工为辅的管理。

从十大知识领域的相互关系来看,整合管理是项目管理的指导思想。项目管理团队应该在整合管理的指导之下,去从事后面九大知识领域的管理。整合管理也是项目管理的归宿。后面九大知识领域的管理,最终是为了实现项目的整合管理,即实现项目目标的综合最优,而不只是哪个方面最优。某方面的最优也许并不利于甚至有害于实现综合最优。

整合管理是项目管理的哲学,是项目管理最本质的内容。

4.2 各过程之间的关系

4.2.1 输入输出总揽

项目整合管理的实现过程包括制定项目章程,制定项目管理计划,指导与管理项目工作,管理项目知识,监控项目工作,实施整体变更控制和结束项目或阶段。这些过程通过输入输出相互关联。

项目整合管理各过程的输入输出关系

4.2.2 对输入输出的解释

整合管理是从整个项目的全局视角开展的,项目管理计划的任何内容以及任何一种项目文件都可以成为其中的执行,监控和收尾过程的输入。

4.3 制定项目章程

制定项目章程,是项目启动阶段的一项重要工作,以便正式启动已经选定的某个项目,确立该项目在组织中的合法地位,授权项目经理动用组织资源开展项目工作。

4.3.1 项目的前期准备

在指定项目章程过程之前,必须完成项目的前期准备工作,包括项目发起人提出项目的初步设想,聘请专家团队对项目开展商业论证以及相关机构签署关于发起项目的合作协议。

前期准备工作的主要目的是,落实项目的可行性,落实项目所需资金。

严格的说,前期准备工作不包括在项目管理的五大过程组之中,也不包括在项目管理的十大知识领域之中,当然也就不在项目经理的工作范畴之内。

4.3.2 项目启动

完成前期准备,进入正式的项目启动阶段来制定和发布项目章程。通常,发起人会亲自领导整个启动阶段,直至项目章程发布。项目章程发布后,就由项目经理来领导项目。

在项目启动阶段,发起人授权候任项目经理开展以下主要工作:

  • 开展项目评估
  • 识别高层级的可交付成果
  • 确定高层级的进度和成本要求
  • 确定整体项目风险的级别及其主要来源
  • 识别主要的假设条件和制约因素
  • 识别和分析项目的主要相关方
  • 编制项目章程,获得发起人对项目章程的批准,并分发项目章程

开展商业论证是为了筛选项目,而开展项目评估是为了确认可行的项目仍然可行。进入制定项目章程过程的项目一般不会被砍掉。

4.3.3 项目章程

项目章程必须由项目发起人或高级管理层签署,并发布给主要的相关方,以便各个相关方都知道项目已经正式启动,都了解项目的主要目标,都了解各自在项目上的角色和职责。项目发起人通常召开项目启动会议来发布项目章程,宣布项目经理的任命,宣告项目正式启动。

做项目,不可以没有项目章程,否则项目就没有基本的保障。

项目章程所规定的是一些原则性要求,所以,通常不会因为项目变更而导致对项目章程的修改。万一要对项目章程进行修改(如项目目标的修改),只有发起人或高级管理层才有权修改。谁签发项目章程,谁才有权修改项目章程。

项目章程中不再有“假设条件和制约因素”。现在用专门的“假设日志”记录在制定项目章程过程中识别的假设条件和制约因素。

项目章程至少要包括以下几个方面的内容:

  • 正式确认项目的存在,给项目一个合法的地位
  • 明确启动项目的理由,把项目与运营及战略目标联系起来
  • 规定项目的高层级目标,包括范围,进度,成本和质量要求
  • 授权项目经理动用组织资源去开展项目工作

4.4 制定项目管理计划

项目正式启动之后,就要编制项目管理计划,即把全部的分项管理计划和分项基准汇编成综合的项目管理计划。分项管理计划是后面九大知识领域中各规划xx管理过程和规划相关方参与过程的输出,分项基准则是创建WBS,制定进度计划和制定预算过程的输出。

4.4.1 项目管理计划的主要内容

项目管理计划是在其他规划过程的结果的基础上编制的。

看到“项目计划”这个词,必须根据上下文判断其外延。

项目管理计划由三大部分组成:分项管理计划,三大基准,项目生命周期。

三大基准是范围基准,进度基准和成本基准。在指定项目管理计划过程中,要把这三大基准整合成“绩效测量基准”。

基准是经过批准的,高层次的项目计划,以便作为比较的基础,据此考核项目执行情况,确定实际绩效与计划要求之间的偏差是否在可接受的区间内。可以说,基准是一种特殊版本的项目计划。

在项目管理计划中没有“质量基准”,其他部分也没有“质量基准”。这是因为高层级的质量标准通常并非由项目经理或项目执行组织自行制定,而是在法律法规或行业标准中规定的。

项目管理计划中与项目生命周期有关的主要内容是,项目生命周期的类型和阶段划分,计划采用的产品开发方法,以及管理层对项目进行审查的时点和内容安排。

项目管理计划是综合性计划,任何单个计划都不等同于项目管理计划。(除非上下文另有要求)

4.4.2 项目管理计划的作用

项目管理计划不仅要经高级管理层批准,可能还要经其他主要项目相关方批准。

一旦有了项目管理计划,后续的一切规划,执行,监控和收尾工作都必须按该计划开展。

项目执行应该是被计划管着的,而不是被领导管着的;团队成员每天该做什么,应该看计划的安排,而不是听领导的指示。只有这样,才能在项目的各种工作之间形成较好的协调,才能真正使成员做到领导在和不在一个样。

除指定项目章程和制订项目管理计划过程以外,全部47个项目管理过程都要用项目管理计划作为输入。

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

项目管理计划是一份综合性计划,而项目文件是各种单个文件的统称,包括未经汇编的各种各样的文件。

项目管理计划一定是经过高层级管理层审批的,而项目文件一般无需高级管理审批,通常是项目团队自编自用。

项目管理计划中的分项管理计划是程序性计划。

对项目管理计划的更新(修改)必须走变更流程,经高级管理层审批;而对项目文件的更新则不一定需要走变更流程。

4.4.4 项目计划的编制者

项目计划必须是自下而上编制出来的。项目团队成员要对与自己密切相关的部分编制相应的计划,并逐层向上报告和汇总。最后,由项目经理负责协调葛总细节文件,并汇编出综合性的项目管理计划。

在编制项目计划的过程中,项目经理和团队成员也要充分听取其他主要相关方的意见,以便把相关方的需求尽可能的反映在项目计划中。

项目成员编制项目计划,项目经理起总负责和整合作用。其他重要相关方也要参与项目计划的编制工作。

计划的执行者必须参与计划的编制工作。这不仅有利于提高计划质量(更加现实可行),而且能够使他们对计划有强烈的主人翁感,从而会努力按计划去执行。

4.4.5 项目计划的编制时间

在项目执行开始之前,要编制出尽可能完整的项目计划。但是,项目计划也需要在项目生命周期的后续阶段不断被审查,细化,完善和更新。

项目计划编制无法一蹴而就,一劳永逸,而是需要在相当长的时间内不断对计划进行审查,细化,完善和更新。

项目管理强调项目的特性和计划都是渐进明细出来的,因为项目的各种情况是逐渐明朗的。如果一开始就强行编制详细计划,那么计划很可能不切实际。

通常采用滚筒式规划方法编制项目计划,即对近期就要开展的工作,编制详细计划,而对远期的工作,只做粗略计划,以后再随时间推移而细化。

4.5 指导与管理项目工作

为了简便起见,《PMBOK指南》对本过程的描述主要针对项目执行阶段的工作。

本过程是开展项目管理计划中的各种活动,来实现计划的要求,完成可交付成果,并识别必要的项目变更,提出变更请求。项目执行阶段通常以“开工会议”为标志。

在《PMBOK考试大纲》中,召开开工会议是规划过程组的最后一项工作。

在项目执行中,需要使用工作授权系统。

项目执行期间的许多比较重要的工作,不是到了进度计划所规定的开始时间就可以自动开始,而是还要得到正式的工作授权才能开始。工作授权系统是用来控制在什么时候,以什么顺序进行项目工作的。

4.6 管理项目知识

未经管理的知识,不仅不能很好地发挥作用,而且还会泛滥成灾。

知识管理的重点是把现有的知识条理化和系统化,以便更好的加以利用,同时,还要基于这些条理化系统化的知识,以及对这些知识的实践来生成新的知识。

《PMBOK指南》中特别提及了两个重要的知识管理活动:知识分享,知识集成。

4.7 监控项目工作

本过程是对项目工作进行监控,以保证实现项目管理计划所定义的项目目标。一方面,监控是贯穿项目始终的,即对启动,规划,执行和收尾工作都要进行监控;另一方面,重点讨论了执行工作的监控。

监控过程组中的“监控”就是监督加控制。监督是指把实际执行情况与计划要求相比较,发现偏差。控制指分析偏差,并提出审批必要的变更请求,以便解决不可接受的大偏差。监督和控制密不可分。

监控项目工作过程是整个项目层面上的高层全局监控。输出工作绩效报告和必要的变更请求。变更请求是广义的。不仅包括对项目计划的修改,而且包括纠正措施建议,预防措施建议和缺陷补救建议。

4.8 实施整体变更控制

本过程是对项目启动,规划,执行和监控过程中提出的变更请求进行综合评审,以便批准或否决变更请求,控制对项目的变更,维护项目基准的严肃性和完整性。

本过程专用于审批各种变更请求。本过程对变更请求的评审必须是全面,系统和综合的,必须考察一个变更可能给项目各方面带来的影响,而不能局限于考察对一两个方面的影响。

对变更请求的评审必须是综合性的。只有从总体上有利于项目的变更,才能被批准。必须防止因局部利益而损害全局利益。

变更有可能悬置变更请求。悬置的变更请求,往往要退回给变更请求的提出者,要求他们补充资料。

任何人都可以提出变更请求,但不是任何人都有权审批变更请求。

4.9 结束项目或阶段

本过程是按照正式的收尾程序,正式关闭采购合同,项目阶段或整个项目。

项目必须进过正式的收尾过程,才能正式关闭。即便对未实现目标就提前终止的项目,也必须经由本过程来正式关门。

项目无论何时终止,都必须用结束项目或阶段过程来正式关闭。

结束项目或阶段过程是开展行政收尾,正式关闭项目。行政收尾的最后一项工作是解散团队。一旦团队解散,就什么事也做不了了。

4.10 各过程的工具与技术

4.10.1 专家判断

专家判断是有关专家根据自己的知识与经验对问题作出判断。因为项目管理有科学的成分,也有艺术的成分,所以能够体现艺术性的专家判断就是一种极其重要的技术。实际上,几乎任何管理和技术工作都离不开专家判断。

专家判断可以来自项目执行组织内部或外部,项目团队内部或外部。

4.10.2 会议

在项目整合管理的7个过程中,只有管理项目知识过程没有会议这个工具,当然,各个过程需要召开的会议有所不同。

从会议的目的来看,可以分成信息交流会,方案产生与评审会,以及决策制定会。这三种会议最好分开来开。如果必须在一起开,也应该把整个会议分为三个阶段。

会议是必须的,但又不能太多。如果什么事都要开会来解决,就说明工作制度不健全。

4.10.3 人际关系与团队技能

制定项目章程和制定项目管理计划过程是用人际关系与团队技能,是为了解决对项目目标和计划的意见不一致,而管理项目知识过程则是为了促使知识分享和知识创造。

4.10.4 数据收集

头脑风暴。焦点小组。访谈。核对单。

4.10.5 数据分析

4.10.6 决策

投票,独裁。

4.10.7 项目管理信息系统

4.10.8 知识管理

工作跟随,跟随指导。

4.10.9 信息管理

知识管理用于在人与人之间建立联系,以便分享隐形知识(无法脱离人而存在);信息管理用于在人和信息之间建立联系,以便分享显性知识(可以脱离人而存在)。

4.10.10 变更控制工具

4.11 项目变更管理

4.11.1 基本概念

项目变更是指采取纠正措施,缺陷补救措施或预防措施,以及因计划本身的问题修改已经批准的项目计划。项目变更是必然的。项目变更管理就是预防不必要的变更,并提出,评审,实施和总结必要的变更。

4.11.2 变更产生的原因

变更产生的基本原因包括项目管理计划中的缺陷,项目外界情况的变化,以及项目执行的低效。

虽然变更是必然的,我们不应该害怕变更,但是如果变更超出了一定的数量,一定的规模,项目就会失去有效控制。所以,对项目变更必须进行有效的控制,防止无序,过多,过大的变更。

如果项目变更太多,太大,就可能需要修改项目章程,甚至必须终止现行项目,而另外启动一个新项目。

4.11.3 变更管理的程序

变更管理的程序包括五大步骤:从源头上管理变更,提出变更请求,评审变更请求,实施和跟踪批准的变更请求,以及总结经验教训。

4.11.3.1 从源头上管理变更

项目经理应该积极主动而非消极被动的工作。他要主动地对引发变更的各种因素施加影响,以避免不必要的变更。

项目经理还要主动的对导致人们规避整体控制的因素施加影响,防止人们有意无意地规避对变更的综合评审。

虽然《PMBOK指南》中没有专用于从源头上管理变更的过程,但是大多数过程中都隐含着这一件工作。

4.11.3.2 提出变更请求

任何人都可以提出变更请求。应该尽可能用书面方式提出变更请求。

无论是书面或口头上的变更请求,都必须是正式提出的。

提出变更请求者,必须清楚的说明变更是什么,为什么要进行变更,必须初步说明变更可能产生的后果,变更可能用什么方案实现。必须防止相关方很随意的提出变更请求,不考虑后果的乱提变更请求。

在项目计划被批准之后重复开展启动和规划过程,可能提出变更请求。

4.11.3.3 评审变更请求

变更请求,提交给项目经理。进行形式审查,写入变更日志。

PMP考试中的“记录变更”,一般都是指把变更请求写入变更日志。

先基于变更请求中的变更方案,评审变更对所在领域的影响。再基于变更请求中的方案,全面评审变更对项目各方面的综合影响。如果有必要,再设计其他备选方案进行评审。

变更无论大小,都必须进过综合评审,确认从总体上有利于项目,才能加以批准。

4.11.3.4 实施和追踪批准的变更

只有经过批准的变更,才能被实施,跟踪,考核和报告。 变更请求被批准后,要及时更新项目文件和项目管理计划。要及时通知会受变更影响的相关方。这对保证变更的顺利实施是非常重要的。

4.11.3.5 总结经验教训

4.11.4 变更的审批权限

变更的审批权限

不影响基准的变更,由项目经理审批。会影响基准的审批,项目经理无权审批,除非是紧急情况。

4.11.5 变更控制委员会和变更控制系统

变更控制委员会由主要项目相关方正式组建,并派代表参加。项目经理可以是其中的成员,但通常不是主任。

项目需要有效的变更控制系统。

4.11.6 配置管理

配置管理是项目整体变更管理的组成部分。

配置管理的重点是,确定哪些是核心技术参数,并以特别严格的程序来控制对这些技术参数的变更,确保配置变更可控,在控,可追踪。

4.12 疑难问题解答