项目管理精华总结

老师展示的是这样的一张图：

 

这就是项目管理的九大领域：整合管理、范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理。

项目管理好像一头大象，将其大卸九块之后，要装进冰箱就容易多了。

看看书上是怎样解释这九大领域的：

• 整合管理：包括识别、确定、结合、统一与协调各项目管理过程组内不同过程与项目管理活动所需进行的各种过程和活动。
• 范围管理：确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。
• 时间管理：包括使项目按时完成必须实施的各项过程。
• 费用管理：包括涉及费用规划、估算、预算、控制的过程，以便保证能在已批准的预算内完成项目。
• 质量管理：包括保证项目满足原先规定的各项要求所需的执行组织的活动，即决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量持续改进等方针、程序和过程来实施质量体系。
• 人力资源管理：包括项目团队组建和管理的各个过程。
• 沟通管理：包括保证及时与恰当地生成、搜集、传播、存储、检索和最终处置项目信息的所需的过程。
• 风险管理：包括项目风险管理规划、风险识别、分析、应对和监控的过程。
• 采购管理：包括从项目团队外部购买或获得为完成工作所需的产品、服务或成果的过程。

3.五招四十二式

要把大象装进冰箱，分成九块还是太大了，还得切小一点。因此在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中关于项目章程有一段话是这样说的：“在多阶段项目的以后各阶段，制定项目章程过程的作用是验证原来为项目制定与颁发的章程所做的各种决定。这一过程在必要时还核准项目下一阶段并更新该章程”。原来如此，简单来说，就是看原来制定的章程还好不好使，不好使就需要更新了，算是能说得通。

同样，识别干系人也就是看干系人有没有变化了，但这与项目监控又存在一定的雷同了。我们可以设想一下，如果干系人发生了变化，我们一定需要等到一下阶段初才对做出相应的对策吗？显然不现实，我们会立即做出反应，而能随时识别变化并做出反应的过程只能是监控过程组了。

• 项目经理到底该做什么

曾经在培训课有一位老师告诉我们，项目经理主要做项目整合管理的工作。个人认为这种说法有失偏颇。

由于整合管理往往涉及多个领域，因此，由项目经理亲自把控是有道理的。但项目经理是不是只需要做项目整合管理，或者可不可以授权其他人来负责整合管理中有一部分工作，这就要视项目实际人力资源情况而定了。

如果你不幸领着一群毛手毛脚的毛头小子，那上面这个表里的工作只能全是你的了；如果你有几个得力干将，那就好办多了，授权嘛。整合管理中工作同样是可以授权的，没有谁规定一定要由项目经理来做。当然授权不等放权，绝不意味着放任不管，至于管到什么程度，只能由你自己拿捏了。

4.懂章法还要懂点心法

在武侠小说里，常有争夺剑谱之事，可是千辛万苦拿到剑谱，由于不懂“心法”，还是练不成。在项目管理领域，PMBok就好比是一本剑谱，项目经理要做什么、怎么做，书里面都有，但每个人运用起来，威力会大不相同。古人云：“运用之妙，存乎一心”，可见心法的重要性。

下面介绍一些项目管理的入门心法，帮助项目经理理解和运用书中的招式。至于高级心法在后续文章中会逐步介绍。

1.项目管理是关于做事的方法

项目管理不是什么神秘东西，要以平常心来看它，它就是人们总结出来的一种有效的做事的方法而已。这种方法有几个要点：

• 以客户为中心

以客户为中心，看上去很简单，却蕴含着项目管理的终极秘密：让客户满意。记住，是让客户满意，而不是开发一个软件，或者完成合同内容，也就是说我们的关注重点是客户需要什么，而不是软件本身。为什么那么多项目开发了大量强大功能，客户仍不满意，就是因为我们没有把关注焦点放在客户身上，去琢磨客户真正需要什么，而不是客户说要什么；去琢磨怎样满足客户的实际应用，让他们用起来更方便，而不是需求文档写着什么。

• 以目标为导向

项目没有目标，就好像踢球没有球门，其重要性不言而喻。但是项目的真正目标并不一定等同于招标文件中提出的目标，招标文件是台面上的东西，是比较表面化的，而客户的真实目的也许并不在于此。因此，项目经理最好对项目的来龙去脉搞清楚，这样才能更好的把握客户心理，理解项目的重点，真正使到客户满意。

• 以计划为基础

项目计划在项目中处于非常基础的地位，项目的实施都应该按照项目计划来进开展。如果项目没有制定计划，或者虽有计划，却是说一套、做一套，那么这不叫项目管理，这叫打乱仗。没有计划，项目实施也就失去了依据，也更谈不项目监控了，项目管理中的42个过程，也就基本失效了。

• 以控制为手段

项目监控是很多人新任项目经理的薄弱环节，为什么那么多人说“计划赶不上变化”，其原因正是在于控制环节的缺失。项目不是一台机器，你只要启动马达，它就会按你设计的那样转个不停。项目的过程中产生偏差是正常现象，甚至是必然的事情，如果不加以控制，计划就会成为摆设，项目也会越偏越远，项目完工也就更加遥遥无期了。因此说控制是手段，是保证项目能按计划达到目标的手段，每个项目经理都必须主动监控项目，用好这一手段。

2.结构化分析方法

还记得什么是结构化分析方法吗？说到它，很多人会想起数据流图、数据字典等等这些工具，但其内在的精神思想，即“自顶向下、由外到内、先整体后局部、逐层分解”，这才是它留给人们最宝贵的财富，

其实结构化分析法方不只是用于软件的分析设计，在人们生活的方方面面都有其用武之地，因为它是对复杂和大型事物的分析方法，符合人们对事物的认识规律。在PMBok中同样深刻的体现了结构化分析方法的思想。

首先PMBok本身就是一个自顶向下、逐层分解的知识体系。没有分解之前，项目管理是一个混沌的整体，PMBok将其按不同的维度分解为五大过程组和九大知识领域，然后又进一步分解为42个过程，每个过程又分解为输入、工作和方法、输出三个部分，这不正是完美的体现在结构化分析的思想吗？

项目经理组织项目实施更加离不开结构化思想。42个过程中有一个非常重要的过程是“创建WBS”，所谓WBS，中文名是“工作分解结构”，它其实就是一种按照“自顶向下、逐层分解”的思想建立的一种树形的项目任务清单，这是整个项目执行和控制的基础，如果你不会使用WBS，那基本上就也就等于说你不会管项目了。

结构化方法在编写项目文档以及汇报材料时同样有其用武之地。项目文档其实也是一种交流汇报的材料，为了能让别人看懂，我们先要把事情总体的讲一下，然后将其分为几个大点，每个大点可能又分成几个小点来讲，这样别人就有对你要讲的内容搞清楚了。我看过一本专门教别人写汇报材料的书，叫《金字塔原理》，其实也就是讲如何自上而下组织材料，让汇报变得更有条理。现在你懂了结构化方法，这本书你也就可以省了。

3.过程思想

ISO9000有八项基本原则，其中一项就是“过程方法”，并将过程定义为：“一组将输入转化为输出的结果”。过程包括三要素：输入、活动、输出，对于这三要素，我想这三素对于程序员来说肯定不会陌生，因为我们在进行软件设计时，所使用的IPO图与它如出一辙，IPO图的三要素是“输入、处理、输出”，两者其实没有什么区别。也就是说，IPO图其实是表达过程的有效工具。

回到PMBok中五大过程组的那张图，它其实就是一张IPO图，它也有由输入-处理-输出组成，即启动-规划、执行、监控-收尾，由此可见，其实整个项目就是一个大的过程，同样，项目阶段也是过程。五大过程组又包含42个过程，每个过程都是由“输入、工具和技术、输出”组成，这与“输入、处理、输出”不是一回事吗？

需要说明的是每个过程并不是个独立的，而是相互关联和衔接的，前一个过程输出成为下一个过程的输入，从而形成了一个个过程链。下图是一个简要的过程链示意图：

 

图 项目管理中的过程链