要把大象装进冰箱,分成九块还是太大了,还得切小一点。因此在PMBok第四版中,又将九大知识领域细分为42个过程,这些过程可以分为5个组,启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组42个过程,就是武术中的招式,可以直接用来实战中了,因此不妨称之为“五招四十二式”。
这一节牵涉到比较多的项目管理理论知识,如果你完全没有接触的过的话,读起来可能会比较困难,建议先啃一遍PMBok,或者跳过本节。
1. 五大过程组
五大过程组与九大领域一样,同样体现了做事的逻辑,只不过角度有所不同:
●启动:确定是否要做,以及做什么●规划:打算怎么做● 执行:按照计划去做●控制:做对了没有●收尾:做完了收工
可以看出,这是一个完整的做事流程。其中启动和收尾一进一出、一头一尾,就像我们常说的“做事要善始善终”,而规划、执行和监控则是项目的主体,与著名的“戴明环”(即PDCA循环)相对应,构成了一个循环。
在PMBok中用下面这张图来描述五大过程组:
图 PMBok中的五大过程组关系图(出自PMBok)
有人将五大过程组画成这个样子:
图 网上流传的五大过程组关系图
这张图广泛流传,但它其实是有问题的,就是把监控弱化了。跟PMBok中的原图比较,在这张图中,只有执行属于监控的范围,而在原图中,启动、规划、执行和收尾都是监控的对象,很明显,原图更加严谨。
很多人分不清五大过程组与项目生命周期的关系,两个概念确实比较容易混淆。生命周期,也是就一件事物从开始到结所经历的阶段,一个人的生命周期包括婴儿、儿童、少年、青年、中年、老年等几个阶段,项目也可以这样来分。为什么五大过程组和项目生命周期容易混淆呢?关键在于大过程组看上去很像是项目的几大阶段:启动→规划→执行→收尾,然而两者之间有着巨大的差异:
●生命周期是从时间维度来描述项目管理,而五大过程组则是从职能的维度来理解的,告诉项目经理应该做哪些工作:项目经理你要做项目启动的工作、你要制定项目计划、你要组织和指导大家开展实施工作、你要监控项目、最后不要忘了做收尾工作!●五大过程组还体现在了项目的过程化思想,五大过程组本身即具有“输入-处理-输出”的关系(启动为输入,收尾为输出),而生命周期仅是前后贯通的时间序列。●生命周期是前后连接的阶段,而五大过程组是一个有进有出的环,在项目中大环套小环,有点像套娃娃。整个项目可按五大过程组的思路来开展,每个生命周期的阶段也可以,甚至一项细化的开发任务也可以。
图 项目过程组与生命周期的关系(出自PMBok)
五大过程组与生命周期同时也存在紧密的联系。实际上,启动过程组在项目生命周期的开始阶段作用最为强烈,收尾过程组主要作用于接近完成的阶段,而规划、执行和监控过程组则主要作用于项目的建设实施阶段,如下图所示:
图生命周期与项目过程组的相互作用关系(出自PMBok)
2. 四十二个过程
现在我们知道了项目管理有九大知识领域和五大过程组,那项目经理具体要做哪些事情呢?那就要看项目管理的42个过程了,做什么、用什么方法做、做出什么成果全在这里,这对于那些像无头苍蝇一样到处乱飞乱撞的项目经理来说,简直就是雪中送炭啊。然而别高兴得太早,早就听说过PMBok很难啃,它难也就难在这42个过程,每个过程都由输入、工具和技术、输出组成,千篇一律,就如同经书一般乏味,估计你看两个过程就会昏昏欲睡,所有以我也叫它“四十二章经”。
看一看42个过程的分布情况:
知识领域 |
项目管理过程组 |
合计 |
||||
启动过程组 |
规划过程组 |
执行过程组 |
监控过程组 |
收尾过程组 |
||
项目整合管理 |
制定项目章程 |
制定项目管理计划 |
指导与管理项目执行 |
监控项目工作 实施整体变更控制 |
结束项目或阶段 |
6个 |
项目范围管理 |
|
收集需求 定义范围 创建WBS |
|
核实范围 控制范围 |
|
5个 |
项目时间管理 |
|
定义活动 排列活动顺序 估算活动资源 估算活动持续时间 制定进度计划 |
|
控制进度 |
|
6个 |
项目成本管理 |
|
估算成本 制定预算 |
|
控制成本 |
|
3个 |
项目质量管理 |
|
规划质量 |
实施质量保证 |
实施质量控制 |
|
3个 |
项目人力资源管理 |
|
制定人力资源计划 |
组建项目团队 建设项目团队 |
管理项目团队 |
|
4个 |
项目沟通管理 |
识别干系人 |
规划沟通 |
发布信息 管理干系人期望 |
报告绩效 |
|
5个 |
项目风险管理 |
|
规范风险管理 识别风险 实施定性风险分析 实施定量风险分析 规范风险应对 |
|
监控风险 |
|
6个 |
项目采购管理 |
|
规划采购 |
实施采购 |
管理采购 |
结束采购 |
4个 |
合计 |
2个 |
20个 |
7个 |
11个 |
2个 |
42个 |
如果你想看每个过程的详细讲解的话,那还是得自己动口、丰衣足食——动口啃PMBok。这里我们倒是可以对其进行简要解读,避免由于食物太硬引起消化不良。
PMBok中有三个重要的词:生命周期、五大过程组、九大知识领域,其实是看待项目的三个维度,即 :时间维度、职能维度和管理对象维度。时间维度是要求项目经理将项目分成若干个阶段,逐步接近目标,项目更容易控制;管理对象维度是要告诉项目经理管什么,要关注什么,即范围、时间、成本、质量、人力资源、风险等;而职能维度则是代表要做什么,即要启动项目、规划项目等。
42个过程是按照后面两个维度进行划分的。为什么没有生命周期呢?这是因为不同类型的项目生命周期划分会千差万别,例如一个软件项目和一个房地产建设项目的阶段划分毫无疑问会相去甚远,而PMBok是适用于不同行业、不同类型项目的通用的指南,不可能将其固定下来。因此假如具体到某个软件公司,完全可以根据软件生命周期划分、参考PMBok中的过程,重新制定合乎本公司实际情况的项目过程,相信大部分软件公司的ISO9000文件正是这样干的。
主要疑惑点在于“制定项目管理计划”与“制定进度计划”、“制定进度计划”等过程之间的关系。
其实PMBok已经明确说了,它们之间是总子划和分计划的关系。在项目管理计划中,同样可以包括这些分计划的内容。也就是说,只要你愿意,完全可以把规划过程组中的所有工作放到“制定项目管理计划”这一个过程中来完成——总计划把分计划中的事全干了。
监控过程组中一共有11个过程,这11个过程的关系是比较让人迷惑的。在整合控制中有“监控项目工作”和“整体变更控制”两个过程,它们与别外八个领域的中的监控过程是什么关系呢?
通过研究各个过程的输入和输出,可以发现“监控项目工作”过程产生的的一个主要成果是批准的变更请求,而该成果又是另外八个领域中的控制过程的输入,这些控制过程又都有一个重要输出是请求的变更——该成果又是“整体变更控制”的输入。由此,各个过程的关系浮出水面,如下图所示:
从图上可以看出,“监控项目工作”主要是发现问题,提出变更请求,而“控制范围”等过程,则是确定怎样变更,真正的进行项目变更的动作是“整体变更控制”。
启动过程组在两个过程:“制定项目章程”和“识别干系人”。按照五大过程组的特点,这两个过程在项目每个阶段之初都需要执行。难道我们在设计阶段和编码阶段都需要重新制定项目章程和识别干系人吗?
这看上去有点奇怪,在实际项目中,项目章程和干系人一般不会有什么变化,每个阶段都要重新做一次这个工作似乎有点牵强。在PMBok中关于项目章程有一段话是这样说的:“在多阶段项目的以后各阶段,制定项目章程过程的作用是验证原来为项目制定与颁发的章程所做的各种决定。这一过程在必要时还核准项目下一阶段并更新该章程”。原来如此,简单来说,就是看原来制定的章程还好不好使,不好使就需要更新了,算是能说得通。
同样,识别干系人也就是看干系人有没有变化了,但这与项目监控又存在一定的雷同了。我们可以设想一下,如果干系人发生了变化,我们一定需要等到一下阶段初才对做出相应的对策吗?显然不现实,我们会立即做出反应,而能随时识别变化并做出反应的过程只能是监控过程组了。
曾经在培训课有一位老师告诉我们,项目经理主要做项目整合管理的工作。个人认为这种说法有失偏颇。
由于整合管理往往涉及多个领域,因此,由项目经理亲自把控是有道理的。但项目经理是不是只需要做项目整合管理,或者可不可以授权其他人来负责整合管理中有一部分工作,这就要视项目实际人力资源情况而定了。
如果你不幸领着一群毛手毛脚的毛头小子,那上面这个表里的工作只能全是你的了;如果你有几个得力干将,那就好办多了,授权嘛。整合管理中工作同样是可以授权的,没有谁规定一定要由项目经理来做。当然授权不等放权,绝不意味着放任不管,至于管到什么程度,只能由你自己拿捏了。