项目管理知识体系指南第三版（第二部分）（AMT研究院 赖炜 编译）

在本评论的第一部分，我们综观了项目管理学会最新的项目管理知识体系指南，即第三版指南。我们重点提出了好的地方，但同时也注意到一些严重错过的机会。在此第二部分，我们将对指南的一、二两部分进行详细的研究，指出其中的值得欣赏之处和不足之处。

第一部分，项目管理框架

值得欣赏之处

指南的第一章中这样叙述：“项目交付物的一个重要特征就是唯一性。例如，成千的办公楼被建造起来，但是每个建筑物都是唯一的­­­­­——因为它们的业主不同，设计不同，位置不同，承包商不同，等等。一些重复性因素的存在并不能改变项目实质上的唯一性。”我们可以更进一步地确定，即使建筑物完全相同，举个例子来说，住宅建筑开发的标准住房，但每个住房仍然可以当作一个项目来运行。每个住房都是唯一的并不是因为交付物本身，而是因为它的时间、地点，以及更有可能是它的劳动力所致。在作为产品的交付物和创造产品的工作之间有一些混乱。工作是短暂的，但产品是永久的！我们将在接触到第三部分的第五章时对此有更多的叙述。

“项目经理也应该考察组织文化，并确定项目管理是否能被认可成为管理项目的、拥有义务和权力的正当角色。”这是一个好观点，但是当他/她发现不是这样的时候，他/她该做什么？

1.5节已经增加了项目管理团队成员潜在需要的综合管理知识和人际关系技巧。投资组合、投资组合管理和项目管理办公室（PMO）在1.6节和3.2节中被轻描淡写地提到。但是，指南清晰地将焦点集中在单一的项目上。并且，指南仍然对PMO的关键特征进行了到位的描述。

第二章——项目生命周期与组织，比之前的2000版有改进。指南指出：“项目生命周期定义了从项目开始到结束的各阶段”，并且“项目的这些阶段与第三章中详细描述的项目管理过程组并不是一回事。”“从一个阶段到另一个阶段的过渡……经常被定义通过……某种形式的技术转换或传递。”

组织在其项目管理系统、文化、类型、组织结构和项目管理办公室方面的成熟度也很能影响项目的进行。指南也举例说明了项目生命周期从“最初的阶段”开始，到“最终的阶段”结束的全过程。稍后我们将发现，这个观察结果并不像它看起来的那样不重要。

不足之处

当2004版指南关于“项目生命周期”的更新部分比2000版指南有所改进时，这部分有它自己独特的“部分”，就像项目管理程序组部分那样。之前我们说过，一个正确阐述的项目生命期，以及正确划分各主要阶段的“大门”，是发起人或施工组织的执行管理部门在整个项目管理过程中进行控制的工具。许多项目的失败可以直接归咎于缺少健全的PLS过程。就像一个评论家所说的那样，“指南已经变得更加制度化（在团队层面），并且更不以执行为导向。我担心这样增加了管理上的官僚主义，但同时提高了决策的质量。”

此外，指南认为许多项目只在一个阶段进行。每个知识领域章节都用一个标准段落直截了当地陈述：“知识领域的每个过程在每个项目中至少进行一次，并且如果项目被分成几个阶段的话，每个过程要在一个或多个项目阶段进行。”（增加的重点）。这样的观点对于项目管理来说是非常缺乏创见的吗？认为真正的项目只在它们肌爸葱小笔贝嬖诘墓鄣闶浅赂穆穑咳绻钦庋幕埃饩秃鍪恿舜庸竟芾淼氖咏巧辖邢钅抗芾淼闹匾裕灰的壳跋钅客蹲首楹瞎芾淼闹匾浴Ｒ晃黄缆奂曳⑾帧罢隽煊虬ㄖっ鳌⒂呕推舳钅浚约跋钅康娜抗芾砘疃拖钅客哦樱伎梢韵翊罅康钠渌ぷ饕谎煌贫稀！?lt;/SPAN>

或许由于同样的原因，指南没有提到“业务状况”，这种“业务状况”是公司管理层进入到“概念阶段”的理由。在概念阶段，一个构思在许多参数的制约下被提出，并进入到定义和计划阶段。同时，指南确实论述了“项目章程”，该文件的发行正式认可了项目的存在，并正式批准了资源的使用。但是，当该文件被非常详细地描述时，则更加适用于将项目释放到实施阶段。

未能认识到PLS的实质和逻辑顺序是另一个导致项目频繁失败的原因，或者至少导致在项目效益最大化方面的低效。在许多令人遗憾的实例中，项目管理非常到位，但是产品却可怜地非常失败。

顺便说一下，在指南第二章的组织结构部分，标题为“组织结构对项目的影响”，曾被沿用多年的表格被修订了。删去了旧的显示“项目工作中分配的组织全职人员的比率”是一个好主意。但这一行被重命名为“可用的资源”，并且旧的表格中，项目经理角色的一般权力这一行也被删除了。最终的结果使得表格不再有意义。

因此，在新表格的功能栏中，我们看到这样一幅景象，项目经理是一份兼职工作，他或她很少有或者没有权力，无权控制项目预算，很少有或者没有可用的资源。但他或者她确实拥有兼职的项目管理人员。我个人认为，作为一个旧表格所描述的功能型组织中的积极的项目协调人员，或者说是项目领导，我可能很乐于与团队成员一起在项目中做兼职的工作。尽管实际上他们没有任何人是全职工作，而且我也仅有一点甚至没有权力，但那样却是平等的。

但是，在新表格下，我认为我根本不能愉快地在功能型组织中作一个项目经理，仅有一点甚至没有可用的资源，权力也只有一丁点。我在项目上是兼职还是全职并不重要，我倾向于把项目移交给兼职的项目管理人员，让他们继续做下去。

第二部分，项目管理标准

这个部分仅由第三章组成，即项目管理过程

值得欣赏之处

过去，这部分的问题是我们不能发现任何我们确实喜欢的东西。更糟的是，封面大大地写着“项目管理标准”的标题。但现在，我们可以得出结论，作为官方学会标准，这部分成为了项目管理的要义。

不足之处

之前（错过的机会部分）我们曾指出，问题产生于五个项目管理过程组的命名，这个问题最早在1996版指南中出现。这五个正在争议的过程组分别是启动过程、计划过程、执行过程、监督和控制过程以及结束过程。监督和控制项目的活动与运营管理中的监控活动一样，是一项完全合理的重复性管理活动。

早在1916年，亨利·法约尔就在他的管理经典著作中论述了这一点。他说“管理就是预测和计划、组织、指挥、协调和控制。”除了缺少预测这个关键要素之外，指南的论述与其非常相似：“综合管理包括计划、组织、分配、执行和控制企业的运行。”

问题是指南将“启动（过程）”定义为“批准和定义一个新阶段或一个新项目的范围的过程”……以及“制定项目章程”和“制定项目初步范围说明书”的过程。指南将“结束（过程）”定义为“正式终结一个项目或一个阶段所有活动，并将完成的产品移交给其他人的过程……”结果，这两个概念和描述与指南的图2－1中所表述的一个完整的项目生命期的第一阶段和最后一个阶段看起来完全相同。因此，这就不难理解为什么人们会立刻认为过程组代表了项目生命期。实际上，不单是学生会误解这种情况，许多培训人员和项目管理知识体系的撰稿人在他们的书中和培训计划中也出现了这种误解。然而，2004版指南却并没有绝对地说明：“过程组并不是项目阶段。”

但是，在指南的一张数据流的图解中再一次显示，五个过程由作为初始投入的“人力资源组合”开始，到作为交付给客户的产出的“最终产品、服务和成果”结束。显然，这跨越了整个项目生命期，因此，人们有充分的理由可以认为这中间的步骤就等同于项目生命期的中间阶段。这显然加深了这样的误解,认为这些过程是项目生命期中的逻辑顺序,并因此代表了项目生命期的各阶段,而不是管理的控制过程组。实际上，在图解的旁边有各种指向的箭头，以及一句注释“并没有展示所有的过程间交互作用和过程中的数据流”，但这根本不能澄清误会。事实上，在指南的许多其它部分还加深了这个误解。

在上述的那张图解之前，有一幅有趣的绘画，它试图通过Deming的计划－实施－检查－行动的质量管理循环，展示出过程的循环本质。如果指南的这些论述被采纳的话，那么人们就会认为启动和结束是每个循环的一部分。确实，这在一个名为“项目管理过程组三角关系”的图表的底端被正式认可。我们的疑问是，这在实际的项目管理中是否有意义。

更进一步的图解试图把过程组与“项目边界”联系起来。这表明，项目投入是在开始阶段边界，中间是计划和执行过程的循环，结束是在项目终止阶段边界。这就明确证明了启动过程和结束过程同义于项目生命期的第一阶段和最后阶段。

指南小心地指出真相：“这并不意味着指南所论述地知识、技巧和过程能千篇一律地适用于所有项目。项目经理要与项目团队合作，负责为既定项目决定适当的过程以及各过程的严密程度。”然而，不幸的是，在看到这被PMI发展成为“项目管理标准”时，综合管理坚持认为它是所有项目的标准。至此，我们真正需要思考的问题将是：“它将像这样应用到所有的项目中去吗？”

无论如何，是否将过程以及过程严密程度的选择权交给项目经理和项目团队是值得怀疑的。这样做公然违背了项目投资组合管理的要求，即为了在投资组合的项目中正确地选择和监督，一定程度的一致性是必要的。

概括起来说就是，公司管理层以及他们的投资和方案经理们的主要焦点应该集中到，将项目生命期认真设计成拱形的外部控制工具。并且项目管理学会应该采用更为简单的Deming的计划－实施－检查－行动作为项目管理监督－控制循环的名称，这样更为适当、合理。

私下说一句，在任何关于如何管理一个项目的哲学讨论中，将管理项目管理组成部分和管理项目的技术区分开来都是很重要的。我们相信清楚地说明“在大多数时候适用于大多数项目”的“知识和实践”仅限于项目管理学科领域是可能的。但是，这不是事实，在技术管理领域，不同应用范围和不同行业之间技术的管理相去甚远。

人们可能会认为项目技术非常复杂，范围涉及从传统技术到高科技，从建筑到研发。在建筑过程中，从头到尾计划是很好的实践。在高科技一端，通过一系列迭代进行是很好的策略，这些迭代可能在一个阶段有好几个，也可能一个迭代就代表了一个完整的阶段。自从IT倾向于靠近高科技一端，在一整个系列的迭代中进行IT技术管理变得非常适合，每一次迭代都增加一个功能性的增量。

但是甚至在建筑过程中，除了在为了确认和检验设计细则而进行的实物模型、原型或测验部分，“迭代”的观念也是众所周知的。不过，我们认为很有可能在2004版指南中，专门适用于IT管理的方法并不适用于一般意义上的项目管理。

待续……

在本评论的第三部分我们将对指南的第三部分进行更详细的探讨。