项目管理知识体系中的九大知识领域

1、项目管理知识体系中的九大知识领域 项目管理知识体系中的九大知识领域 九大知识领域，是项目管理知识体系的重要内容，涉及内容非常广泛，在这里将会把各个知识领域中的主要管理内容和关键点作一介绍，如需了解更为详细的内容，请参考pmbok以及相关的专业论著。 1.4.1集成管理 集成管理是项目管理九大知识领域中的第一个领域，与其它八个知识领域相比，这个领域的内容比较特殊，它并没有提供具体的知识点和具体的操作方法，而是反复强调围绕项目的全局观，在项目内部各个部分之间、在项目内部与外部之间，对各种内容进行集成，使各个相关方面形成有机的整体，保持管理上的一致性。这个知识领域的内容对于项目经理们来说可能感觉比较

2、空泛，但对于企业级项目管理体系建设来说，则是非常具有指导意义的。 下面是项目管理中几个常见的集成方面的问题： 1、将项目计划中各个管理领域的子计划综合而成整体的项目计划。例如在整体项目计划中，要包括范围管理计划、时间管理计划、成本管理计划、质量管理计划、人力资源计划、沟通计划、风险管理计划、采购计划等，将这些不同的管理计划有机的结合起来，使整体项目计划能够有效涵盖项目管理的各个领域的管理内容并保持一致. 2、将项目的各个过程有机的集成起来。在后面我们会提到项目的五大过程启动、计划、执行、控制、收尾。这些过程在整个项目当中，在项目的各个阶段当中，都可以根据管理的需要灵活运用，但是各个过程之间的关

3、系仍然要符合基本的关系要求，这五大过程之间的关系会在后面的章节中进行介绍。 3、项目管理与企业日常运营管理的集成。不论企业是以项目方式从事主营业务，还是利用项目从事改革、创新，都存在着项目与企业日常运营之间的关系。在项目过程中通常会占用企业资源，也会对企业的日常工作产生一定的影响，如何协调资源、配合工作，同时满足两方面的需要，这就是经常遇到的一种集成管理的要求。例如在创新活动中，项目会产出成果，可能形成面向内部用户或外部客户的产品，企业就 要考虑围绕这些产品的销售、支持服务等一系列的企业运营中的问题，因此，企业往往在项目初期定义项目成果时，就要求考虑项目成果在以后的企业运营中的管理问题。 4、

4、项目生命周期与产品生命周期的集成。企业管理的核心内容都是围绕产品的（包括服务型产品），企业一定会对产品的生命周期进行管理，在产品的整个生命周期当中，产品的每一次进步，都是以项目的方式来实现的，从市场调研、可行性分析、产品设计、产品生产、市场促销、产品改进等各个不同的阶段，都可以单独成为项目。这时的项目的生命周期包含在产品的生命周期当中，项目的成果成为产品发展的阶段成果。因此，在项目管理中，还要同时兼顾产品长远发展的需要。 5、项目范围与产品范围的集成。当一个产品由不同的部分组成时，每个部分都可以单独生产时，就一定存在着项目范围与产品范围集成的要求。例如在汽车装配厂，需要从许多不同的加工厂采购不

5、同的零部件来进行装配，对于零部件加工厂来说，设计、改进零部件的创新项目，不能孤立的对待，而是要考虑该零部件与其它相关部分的配合关系，考虑对整车的影响。如果把整车涉及的全部零部件看作是产品范围，针对某个零部件的改进就是单个项目的项目范围，那么项目范围就应该与产品范围进行有效的集成。 6、不同部门的成果的集成。当一个项目涉及企业内外多个部门和单位时，特别是当项目在企业中处于职能式或弱矩阵式组织结构时，通常会出现各个部门分头完成自己所分管部分的任务，将各自的成果提交给项目，那么在项目中就必须将这些成果集成在一起，形成项目的整体成果。 7、项目中不同约束条件的集成。不同的利益干系人可能会对项目提出不同

6、要求，各种各样的外部因素会对项目形成不同的约束条件，例如外部法规的强制性要求、企业内部的管理要求、不同领导和部门的限制性要求、内部资源自身的特殊要求、项目发起者对项目本身的相关要求等，为项目管理勾画出了项目的边界，这个边界就直接反映出各个方面的约束条件的集成结果。 还有许多其它方面的集成问题，这里不能一一列举。由此可以看出，项目并不是孤立存在的，它受到来自项目内部和外部的多方面的影响，要管理好项目，就必须有很强的全局观。因此，在企业级项目管理体系建设中，就要尽可能将这些问题，通过企业级的项目管理制度加以明确并使之相对稳定，加强对各个具体项目的指导和监督。 1.4.2 范围管理 项目的范围管理，

7、是针对项目交付成果的，通过对项目交付成果的计划、跟踪、控制和获取，保证项目中的所有活动始终是围绕所要求的项目成果开展的，而且保证全部的应交付成果都已完成。可以说，范围管理是具体描述项目目标的。 在范围管理中最重要的一项内容，就是范围定义，就是对所要求的项目成果进行分解、细化，这样做的目地有三方面： 1，提高估算时间、资源、成本的准确程度。 2，定义衡量和控制项目绩效的基线。 3，明确职责分派。 将所要求的项目成果一层一层的细分，就形成了工作分解结构，简称wbs(work breakdown structure)，它是范围定义的主要输出结果。“工作分解结构”包含了三个含义： 工作：是针对成果的，

8、而不是面向过程的； 分解：对成果进行细分，直到能够满足管理的要求为止； 结构：成果被分解以后，每一小块内容并非是孤立的，而是有着内在的关联关系，这种相互之间的关系，是结构化的。 wbs中所分解出来的各个组成部分，就形成了项目的子成果，以后所有的项目活动都应该是针对如何实现这些子成果的，而不应该存在与项目目标无关的项目活动。同时，全部的子成果都被完成，是项目整体成果被完成的必要条件。也就是说，通过细化分析项目成果所包含的各个组成部分，使项目的各项行动都有了具体的目标。正是因为项目范围是针对项目成果的，项目的成果就是产品或服务，所以项目范围往往与产品工艺特性（把服务视为无形产品）有着紧密的关系，需

9、要有丰富的专业领域知识才能够做好。 明确项目目标所要求的交付成果，需要辨析有形产品和无形产品的区别，这一点非常重要的。wbs是面向交付成果的。在制定wbs时，当交付成果是有形产品时，比较容易识别交付物，因为交付物确实都可以是可见的、可验证的，而且交付物都可以表示成为名词的形式。但是当交付成果是无形产品时，往往会带来混乱。无形产品的制造和交付过程是同时的，甚至有些成果与制造过程的行动是一一对应的，所以在表示交付成果时，就难以与制造过程彻底划清界限，经常会用无形产品的制造过程的行动动词来表示交付成果，结果将交付成果与项目活动混在一起，例如在wbs中不是用“歌曲1”、“歌曲2”这样的名词来表示范围的

10、内容，而是用“演唱歌曲1”、“演唱歌曲2”这样的动词来表示，虽然这样写大家也都能理解，但是却混淆了wbs的标准，可能会导致将项目行动也写入wbs，作为项目范围进行管理，结果给项目管理带来麻烦。项目范围和项目活动之间的差别应该是大家早已熟知的，这里不再赘述。因此，对于项目交付成果，无论是产品还是服务，在wbs中都应该使用名词，而不要使用动词，即使像做广播体操这样一个强调过程体验的“项目”，在wbs中也应该使用各个动作的名称，而不是使用做这些动作的动词。 另一方面，有些项目经理是用“可见的、可验证的”作为识别交付成果的依据，对于这一点也不能过于机械，特别是当项目的交付成果是无形产品时，这种判断标准

11、有时就会产生误导。一方面，由于无形产品随着过程结束也会消失，所以其可验证的标准经常会不能满足。有人说，可以形成文档记录或者录像，这不就是可验证的了吗？这种做法固然满足了可验证的要求，但是如果简单的把文档记录作为交付成果，就可能从根本上偏离了项目目标，因为大家来听音乐会，希望得到的是音乐家的高超技艺给听众带来的享受，而根本不关心什么文档记录，项目是否成功，大家对成果的满意度不是来自苍白的文档，而是来自生动的过程，即使将文档记录作为必须的验证证据列入交付物，也不能代替根本的交付成果。在另一方面，项目中可见、可验证的东西不一定都是项目所需要的交付成果，例如，当我们要乘火车去某地的时候，其目标是人要到

12、达目的地，而非提交一张“可见、可验证”的火车票。 因此，对于交付成果的“可见、可验证”的特性，需要针对具体项目目标的要求，根据项目交付成果是属于有形产品还是无形产品来区别对待，即使在交付无形产品时使用一些辅助手段来满足大家早已习惯的“可见、可验证”的标准，也一定不要忘记项目的根本目标是什么，最主要的交付成果是什么。 利用所形成的wbs，在项目接近完成时，就可以执行项目范围确认的工作，以保证项目成果至少在内容、数量上满足了当初的范围要求，然后才是对每个具体内容的质量的检查。 下面的例子是一个组装个人计算机的工作分解结构的示例，它只需要说明一台台式计算机需要由哪些部分组成，但并不需要说明它是如何组

13、装起来的。 组装者只要按要求将上述部件都组装好，就可以认为是完成了工作。当用户在验收时，只要按照这个wbs来逐一核对，就可以比较容易的对计算配置的完整性作出确认。 wbs分解到多细、分解出多少层，这方面没有固定的标准。在上面这个例子中，如果组装者希望自己分别选择不同的机箱和电源，而不是选择已经组装好的，那么这个wbs中就还要将“机箱和电源”这一个节点继续向下分解出“机箱”、“电源”两个节点。 需要反复强调的是，范围管理是针对成果的，而不是面向过程的，只是说明项目要实现的成果是如何组成的，而不说明如何实现的过程。因此，wbs中所包含的内容，都是项目成果的组成部分，反映着项目目标的要求，而项目目标不是项目内部自己给自己定义的，是从项目外部设定的，所以wbs中的内容，对于项目来说，是必须完成的来自外部的要求，不能