爱华网2008版《PMBOK指南》对项目管理的定义是："将知识、技能、工具与技术应用于项目活动，以满足项目的要求，项目管理通过合理运用与整合其五大过程组（启动、计划、执行、控制、结束）来实现。"这些过程组在《PMBOK指南》中有更加详细的定义，PMBOK的目的就是阐释如何在实际项目中实现项目管理。但我想强调的是，那些过程组并没有充分抓住项目管理的本质，项目管理中需要处理大量的政治问题，使团队成员的表现达到同一规定水平，为稀缺资源谈判。《PMBOK指南》的过程组并没有专门针对这些活动内容，也没有充分讨论项目管理真正的复杂性。"速食布丁"式的项目管理1999年12月，我曾在德国拜访过一位项目经理，我们讨论了美国与德国的项目管理的异同。我向他说明了我的项目管理模型──我称之为刘易斯方法，并与他的方法做了比较，我发现两种方法几乎相同。"我一直想把项目管理的理念介绍给这里的高层管理者，但是恐怕收效甚微。"他沮丧地说。"在一次会议上，我们的一位副总裁抱怨道，‘我不明白，为什么我们不去买一套微软项目管理软件来进行管理？‘他随后又说，‘当然，我的意思是我们为什么不进行项目管理。‘"我差点儿笑了出来。"在美国也是一样，那里的高层管理者同样认为，项目管理就是列进度表，他们还认为如果他们给每个人买一套进度管理工具，他们将速成为项目经理。"这时，他的表情才轻松了一些。我继续说："我们应该把进度管理软件装进一个盒子并改名为‘速成项目经理‘。在盒子的外面写上‘只需要加水、搅拌、摇动、加热，你就可以立即享用到项目经理的服务‘──就像你享用速食布丁一样。"他想了一会儿说："这就是我们在做的，进行速食布丁式的项目管理！不是吗？""是的，"我说，"并且我可以告诉你，全世界大部分地方都在使用这种方式。"工具、人和系统项目管理不仅仅是排进度表。它也不仅仅是一些工具。它也不仅仅是一个工作岗位或一个职位头衔。它也不是上述这些的总和。遗憾的是，我的经验告诉我，许多人不知道这一点，他们认为项目管理就是排进度表。他们认为，如果一个人只要懂技术（这里是指广义上的技术），那么就能够管理一个项目。这样的误解普遍存在，我们应该知道任何工作，包括项目在内，都有两个问题──做什么和怎么做。"做什么"是指要执行的"任务"，"怎么做"是指实现任务的"过程"。这里的过程也用来表示一个团队的整体运作──团队成员如何交流、沟通、解决问题、处理矛盾、决策、分配任务、开会以及其他方面。项目管理的工具，比如进度计划软件、计算机、项目日志、每日计划等，都可以用来处理"做什么"与"怎么做"两方面问题。但是，一个不懂得"怎么做"的人，即使拥有工具，也不能成为项目经理（如图1-1所示）。我想强调的是，组织与项目团队是人的集合，不管一个组织拥有多少设备、建筑、材料和其他辅助的东西，都是靠人来使用的，人使用它们来实现组织目标。图1-1 项目管理就是工具、人和系统然而，管理者往往忽略人的因素。有些管理者告诉我，他们宁愿提高电脑水平也不愿意与人打交道，这些管理者多是粗鲁、傲慢、独裁的。你也许惊讶这样的人怎么能在职场中生存，但他们的确存在。作为管理者，在任何情况下都应该明白，组织是人的集合，过程是人在处理。如果人的因素出现问题，那么过程就可能出现问题；而过程有问题，任务的完成就会大打折扣。不幸的是，我们懂得更多的是怎样提高设备的效率而不是管理人。前面我提到了，项目管理涉及工具、人和系统。工具是指工作分解结构、PERT进度计划、挣值技术、风险分析法和进度计划软件等。大多数组织机构在进行项目管理时主要关心的是工具。然而，工具只是一个成功的项目管理的必要而非充分的条件，过程或者技巧甚至更重要。因为如果你没有使用正确的管理过程，这些工具只能帮助你精准地记录错误。比如，你给一个人一辆车让他开，却没有教他如何驾驶这辆车。他只好一边试着开一边学习，等到他能熟练驾驶时（如果可能的话），他一定已经把这辆车开得不成样子了，同时，也会把别的车搞得一塌糊涂。同理，当你给人一个进度计划软件，却不训练他如何使用时，情况会一样糟糕。相反，如果你训练一个无车可开的人学驾驶，也是在浪费时间。没有车，这种训练就是徒劳。总之，如果你理解项目管理必须包含处理政治问题，发挥领导力,外加些许公关技能，那么，PMI定义的项目管理就完整了。四个项目约束条件一直以来，大家都在普遍谈论项目管理的三重约束──质量、时间和成本，换个说法，就是好、快、省。通常的说法是：好、快、省中只能选两个。就是说，三者之中你只能决定两个，第三个是个变量。当我写本书第1版时，我意识到还有第四重约束──范围。一项任务的范围或规模也与其他三项制约因素相关。我开始指出，你可以决定这四个约束中任意三个，但必须允许第四个处于变动之中。事实上，范围的变更比其他任何因素都更容易导致项目超期和预算超支，这还不算一开始就错误定义项目需求。在过去的两年里，我知道许多人都搞不清楚"质量"的含义，所以，这里我要解释一下：项目的目的是为了创造某种成果。建筑项目为人们建造居住的房屋、行走的路、供水的水利设施；产品开发项目是为了给人们提供产品；软件项目也是一样。这里有两类质量要求，合在一起被称为规范。一类是功能的要求，用来描述可交付成果的用途；另一类是技术要求，用来说明可交付成果的特征。它们可能规定了可交付成果在大小、重量、颜色、速度、马力等方面的特征。我曾是一名工程师，我过去常问的一个问题是，是否某种变更能影响到一个产品的形态、适用性或功能。你可以看出这都与我们刚刚所讲的质量相关。定义一个项目，重要的是要明确项目的各项要求。我认为，要求不明确是导致项目失败的最常见原因。一位同事曾给我讲过的一个故事就可以很好地说明这个问题：有一天，一个朋友到他家做客，他们一起修整庭院，他用手比划着离地面的高度对朋友说："看见我家门前的这棵小树了吗？把这些树枝剪到这个高度怎么样？"然后，他就到屋子后面干活去了，他的朋友独自在那里修剪树枝。等他回来一看，他的朋友刚刚完成工作。活做得很仔细，但却弄错了一个重要的细节：他的朋友按照他指定的高度砍掉了树顶的全部枝干，而他真正想让他朋友做的是把从地面到他手指高度的多余的树枝从树干上剪掉！这样的事其实很多。"剪树"的故事本身可以有多种不同的意义。我们说这是一个沟通问题。因为沟通问题经常出现，所以我们最好先认真地对我们在项目中所要完成的事达成共识。我们将在第5章详细讨论这个问题。我曾说过，项目管理就是组织实施对项目要求所必需的一切活动知识、技术、工具和手段的应用。PCTS目标定义了这些要求，它们是所有项目的制约因素，无论项目大小，你永远无法避开这些制约因素，你必须懂得它们之间是如何相互作用的。P──技术与功能方面的质量要求；C──工作中的劳动力成本（注意：主要设备与材料成本要与劳动力成本分开计算）；T──项目规定的时间；S──工作的范围与规模。这些变量间的关系可以用下式表达C＝f(P,T,S)换句话说就是："成本是质量、时间和范围的函数。"在理想情况下，可以把它写成一个精确的数学表达式，例如：C=2P+3T+4S然而，长期以来我们只能定性分析该式，定量的分析无法进行。有一种方法，就是把PCTS制约因素之间的关系看做一个三角形，如图1-2 所示。P、C和T是边长，S是面积。如果知道三个边长，就能算出面积；或者，如果知道面积及两条边长，就能算出第三条边长。图1-2 表示PCTS关系的三角形这个图示主要说明不能随意选择边长与面积。你只能决定这些约束中的三个，第四个将由事物本身的联系决定。但是，如果你试图同时确定四个因素的话，那只能碰巧。可是，在项目管理中，项目发起人或其他管理者通常想同时决定四个因素。实际上，这就是导致项目失败的普遍原因。作为一个项目经理，我的工作就是告诉项目发起人，我做的项目需要什么。所以，在一般的情况下，当P、T、S已经确定时，我能做的就是告诉发起人，要达到目标需要多少钱。现实是，如果我这么做了，项目发起人可能会心脏衰竭。通常的反应是："天哪，怎么能花这么多钱？！"紧跟着的一句就是："我们出不起！"然后，我的反应是："你告诉我能出多少，然后我告诉你用这些钱能做多少事。"这意味着，要么缩减规模，要么延长时间，一般来说，降低性能质量是无法接受的。这其实就像我们为家务事做权衡一样，有一堆事情等着我们去做：屋顶漏了需要修补、汽车开动时有异响、我13岁的女儿需要一个牙箍，这些要花很多钱，还不止这些事情。问题是，我无力支付全部开支。我该怎么办？我需要为这些事情建立优先顺序：如果汽车坏了，我就无法去工作赚钱来支付所有开销，所以，也许它应当在顺序表上的第一位；其次是屋漏的问题；天知道我什么时候能让女儿戴上牙箍，也许她长大以后能自己支付这笔费用，但现在只好等一等了。有趣的是，我们在家务事上能做出优先选择，但是在组织内，我们却总想同时做好所有的事，其结果是，资源变得捉襟见肘，最后什么也做不好。必须认识到你无法同时做好所有的事，你必须做出选择。我的工作就是提供相关项目的详尽信息，帮助我的老板或者项目发起人做出选择。时间──成本权衡在今天这个快节奏的世界，如何按时完成项目是我们每天面对的压力。由于竞争的存在，尤其是在开发新产品、新软件或新的服务方面，如果你的项目花了太长的时间，你的竞争对手就会比你领先一步进入市场，而最先进入市场的新产品通常会占据60%~70%的市场份额，留给你的市场就如同鸡肋了。另外，我们还要面对降低成本的压力，这是因为成本总是随着项目时间的延长而增加。如果你能在保持范围与性能不变的情况下更快、更节省地开发项目，你就能更快地收回投资，使你自己免受市场波动带来的冲击（这些内容将在第四部分做更详细的讨论）。现在来看图1-3所示的时间──成本权衡曲线。注意这里有一个能让成本最低的时间，即最优时间。但问题是，我们常常不知道这个时间到底在哪里，我们现在先暂不考虑这个问题。图1-3 时间──成本权衡曲线我们需要知道，当越过成本最低点后（时间延长），项目成本会因为缺乏效率而提高，这是说，你干得太慢了。在成本最低点的左边，我们要减少花在项目上的时间，用通俗的话讲，就是我们要"挤压"项目，这并不是破坏它──我们只是想做得更快。这时我们可以看到，缩减时间时，项目成本开始上升，并且是急剧上升，这是因为我们要动用更多的资源来加快速度。用句大家常说的话：我们实行的是"人海战术"。问题是，当我们把更多的人力投入到项目中，他们会互相影响，工作不可能分得更细，这时我们便会碰到所谓的边际收益递减。举个例子，如果一个人能在10小时内完成某项工作，两个人却不能在5个小时内完成同样的工作，他们也许要花6个小时才行，而4个人可能要花上4个小时。所以我们得到的收益曲线并非直线。另外，还有一个最少时间的限制，即无论你投入多少人力，你的项目都不能少于这个时间完成，我们把它称为"禁区"。通常总是有人认为，只要你投入足够的人力，便可以不花什么时间就能完成项目，而事实并非如此。甚至，有一个起源于软件项目管理的法则，叫做布鲁克斯法则："为一个已经延期的项目增加人手，只会让该项目延误更多。" （Brooks,1975）我相信，这一法则适用于所有类型的项目，而不仅仅是软件项目。更不幸的是，在错误的时间增加人手，常常会彻底毁掉一个项目，如图1-4 所示。如果你想通过增加人手来提高完成项目的可能性，此人必须能跟上项目的进度。图1-4 返工循环这意味着他需要指导和培训，谁来为他们做培训呢？很可能是你，也可能是项目组里的其他成员，而无论是谁，那个人的工作绩效都必然会降低。为了不耽误工作，她必须加班工作。而加班使她疲劳，因此效率更低，并可能因此常常出错，也就意味着她必须花时间去改正，这就是所谓的返工。随着返工次数的增加，她必须更加超时工作，才能赶上进度，从而更加疲惫，更容易出错，返工更多……这就是说，这个项目很可能因失去控制而陷入恶性循环之中。所以我们千万要小心，不要轻易尝试用增加人力的办法帮助自己按时完成任务。如果你总是做你一直在做的事现在回到我们所面临的压力上来：更快、更省地完成任务。时间──成本权衡曲线告诉我们，如果处在曲线的成本最低点前，压缩项目时间会导致更高的成本。然而，我们却被要求同时降低项目的时间和成本！我们是不是被戏弄了？也许是。有句心理学名言："如果你总是做你一直在做的事，你就会得到你一直得到的结果（种瓜得瓜，种豆得豆）。"还有一种说法，"异想天开的人总是做着一直在做的事，却期望得到不同的结果。"这是说，如果你一直努力却没有什么成效的话，你就必须改变你做事的方式，亦即你必须改变做事的"过程"。事实上，这种改变正是规范的项目管理能给予你的。长期以来，很多人都在使用不规范的、非正式的项目管理方法，我称之为"随意的"项目管理。我很了解它，因为我也那样干了大约10年时间。我们为什么会这样呢？因为我们根本不知道还有其他方法存在。虽然我也完成了任务──而且他们还挺满意。但问题是，我们没有意识到，其实我们的工作还可以做得更好。规范的项目管理（在过程中进行改变）真的能让你又快、又省地完成任务吗？
我相信可以。据估计，大约1/3的项目成本来自于返工，就像有人说过的，这相当于让每三个人中的一个什么也不干，只是重做另外两个人做错的事。当然，这样的成本会非常高。为什么会有这么多返工呢？我可以肯定地说，这是"准备──射击──瞄准"式的管理方式的结果，每个人都不想去认真充分地考察、定义和计划要做的工作，而只是一味地想着快点完成。古人说"欲速则不达"，这千真万确。但在今天这个快节奏的世界，几乎没有人有耐心把时间"浪费"在计划上，这样的结果就是返工，这才是百分之百的浪费。如果你能用心测量一下的话，就会发现，返工在你的项目中大约占到5%～40%的工作量。正如我听汤姆·彼得斯在一盘录音带里说的（我忘记是哪一盘了），"这是个坏消息，也是个好消息，坏消息是返工比例如此之高，好消息是改进的余地还很大"。监测你的返工次数，你就能很快地看到进步。可能你去做基线对比时，发现以前项目的基线数据没有保留。但你仍可以简单地画出一条趋势图来反映返工次数的减少对成本的影响（如图1-5所示）。图1-5 返工趋势图质量我一直认为，质量是项目管理中被忽略的一个方面。质量与项目的性能要求有关，如果项目的功能要求与技术要求未被满足，你所做的工作就不会有好的质量。所以，从某种意义上说，性能要求就是质量。如果你想要人们更快、更省地完成工作，并且不允许缩小项目范围，那么我敢肯定，他们会牺牲工作质量。而且，作为一位ITT的前质量经理，我也知道，如果你提高了质量，你能更快更省地完成工作。所以说，对改进生产过程的共识是，你必须改进质量，事实上，这两者是相辅相成的。过去，人们常用两种方法来定义质量：一种是，质量就是符合技术规范；另一种是，质量就是要满足消费者的需求。当然，技术规范本身就应当以符合消费者的需求为准，所以，第二个定义可以说更好些。在摩托罗拉创立六西格玛质量管理方法中，又发展出一个新的质量的定义。它把质量解释为一种状态，即为客户和商业关系中各供应商实现应得的价值（Harry & Schroeder,2000，p.6）。这个新定义考虑到了双方利益，而旧的定义只考虑了客户一方。哈里（Harry）和施罗德（Schroeder）提出，大多数组织都只是在三西格玛的标准上提供产品或服务，这里的标准是指在给定的样本中出现错误的数量。对于一个100万的样本，三西格玛标准容许2 700个错误；按六西格玛的标准，仅容许3.4个错误。同时他们还指出，三西格玛的质量标准意味着，组织的每1美分销售额中大约有25%～30%（或25美分）用来弥补由于质量问题造成的损失，即所谓的不良质量成本（COPQ）。大多数决策者原本以为COPQ只占一个很小的比例，他们不会料到会这么高。质量成本来源于三个方面：预防、检查与失败成本。预防是指我们为了防止错误发生所做的一切努力。举个例子，波音公司设计777飞机时的工程主管（现在是福特汽车公司的CEO）艾伦·穆拉利（Alan Mulally），曾经谈到玩具公司Fisher-Price如何确保他们的飞机模型能够被玩家顺利地组装成功："Fisher-Price在玩具飞机的轮子上弄个小凹槽，以确保右轮装在右边，左轮装在左边"（Sabbagh,1996）。其实，这种方法在日本的制造中已经使用许多年了。检查成本是对已完成部分的监测，以确认没有质量缺陷。质量中一条基本的法则是，你无法检测产品内在的缺陷（在产品的设计和制造过程中就已经存在的缺陷）。事实上，六西格玛质量控制程序表明，"80%的质量问题来自于产品的设计阶段，设计者根本想不到会出现这样那样的问题"（Harry & Schroeder，2000，p.36）。当问题出现在设计环节时，你是无法检测出来的。失败成本是发生在产品离开工厂到达消费者手中以后的质量成本，包括保修成本、修理成本，等等，其中最不容易量化的失败成本是客户流失成本。需要特别指出的是，提高预防方面成本会显著地减少检查和失败成本（如图1-6所示）。多数的质量成本应当花在问题的预防上，这样我们就能在其他两方面节省大笔开支。如果你想知道这笔节省会有多大，我建议你去读一下哈里和施罗德写的书。图1-6 增加预防措施会减少总的质量成本对于项目来说，如果你能改进流程提高质量，那么，你就能同时降低项目的时间和成本，因为你减少了返工（这对项目不产生任何增值）。质量的改进会给你带来很大的收益。赢得蛋糕，享用蛋糕在图1-2中，我用一个三角形来说明P、C、T与S之间的关系，并指出这是项目的四重限制。用三角形做类比时，便出现这样一个情况，假如我想保持P、C与T不变，并扩大工作的范围，在三角分析中是做不到的；假如我想扩大范围，则这个三角形至少有一个边需要延长。但是，如果我们把这个三角形画在一个球面上时，就可以做到这一点，我只要改变球体的半径，便可以改变P、C与T所围成的区域。图1-7是一个球体，上面有一个球面三角形。在这个球面三角形内部，我画了一个平面三角形。如果假设球面三角形与平面三角形边长相同，则球面三角形所围成的区域更大。这个区域代表了项目范围。从而可以说明，我们可以在保持三角形边长不变的情况下扩大范围（从严格的数学意义上讲，这种画法当然是不正确的，我只是为了尽可能简明地介绍这种思想，因为许多读者没有立体几何的基础）。球体半径代表什么呢？我想它显示的是工作流程的好坏。图1-7 显示在球面上的P、C、T、S关系也可以用另一种方法来考察这几个变量之间的关系。设想P、C、T是一个金字塔三角形底座的三个边长，如图1-8所示。现在范围是指金字塔的全面积。金字塔垂直高度的物理含义是什么？也许是P、C与T的因子。此外，它可能表示过程的好坏。如果是一个不好的流程，金字塔的高度就会不断降低，直到成为一个平面三角形（金字塔的底座）。图1-8 P、C、T、S关系金字塔这些图形帮助我们理解，通过改变项目过程，我们可以赚到更多的钱。我们可以减少返工，提高生产率，缩短时间，等等。前面我提到过艾伦·穆拉利想让777飞机设计得像Fisher-Price玩具那样便于装配，为此，波音公司改变了飞机的设计流程，这个改变包括两方面，技术方面和人员方面。技术方面的改变是采用专有的计算机三维设计。当进行二维设计时，你无法提前预知机体内部各部分之间的相互影响，你必须通过建模发现这些问题，而这种纠正问题的方法常常代价高昂。通过采用三维设计，这些问题就会提前显示在电脑屏幕上，并在样板建立之前得以纠正。当然，这种方法也不是完美的，在设计中仍然会出现各种问题，但相对于二维设计而言，这却是一个很大的进步。人员方面的改变体现在一句口号上"团结协作"。在大多数组织里，各种团体都在自己周围建立起了领地防御体系（藩篱），当矛盾发生时，他们就会界限分明地互相攻击。波音公司的做法是，消除这些藩篱，并建立起一种和谐的气氛，使大家能够理解。只有互相协作，才能取得项目的成功（Dimancescu,1992）。波音公司鼓励员工自由讨论问题，让机械师与装配工人参与到设计小组中，使设计出来的产品更易于建造和使用。波音公司的首席试飞员也与设计者密切合作，以使生产出来的飞机能为飞行员所接受。由于飞机设计已经从传统的用绳子牵引飞机襟翼与方向舵发展到电子操纵，可能会导致缺少飞行员习惯的"操控感"，因此，在设计中考虑到飞行员的主观感受是非常重要的。最重要的是，来自第一用户──联合航空公司（United Airline）的代表也成为设计小组的一部分，以确保飞机符合用户的需求。所有这些不同身份的人加入到设计讨论中来，就使这款面向21世纪的新机型考虑到了方方面面的要求，以做到精益求精（Sabbagh,1996）。最终的结果是，联合航空公司在用自己的飞行员进行第一次试飞后，便接受了777飞机！这在以前是无法相信的。这是一个世界级水准的好的项目管理的案例。组织实施我在前面说过，项目管理就是组织实施计划、进度和控制的活动过程。组织实施这个词非常重要，项目经理不是独自为团体制订计划，而是让那些实际实施业务的人参与制订计划。为什么要这样呢？有两个原因：首先，只有实施业务的人自己最清楚自己要怎么做，要花多长时间；其次，他们最有可能想到一切必要的事情。而如果让你独自制订计划，你可能会遗漏某些方面；而且，他们知道你的计划很可能有纰漏，而你又独自制定并把它"强加于人"，他们很可能拒绝接受。所以，如果你想做一个好的、而且被你的团队所接受的计划，就让他们参与到计划制订中来。如果是一个单人项目怎么办呢？我建议你最好还是让别人帮你分析一下你的计划，他们可能会指出一些被你所忽略的问题，而"遗漏"是最容易导致项目失败的12个原因之一。如果你找不到人来帮你分析，最好的替代方法（如果你能做到的话）就是让计划静静地"睡"上几天，然后，当你重新审视它时，你很可能会发现一些以前被你所忽略的问题。项目的特征项目通常要涉及多种学科，即使是一个简单的建筑房屋的项目，也会同时用到木工、管道工、电工、园艺工、屋顶工、油漆工，等等。这些不同的学科通常讲着不同的语言，互相排斥，很难合作好。另外，项目经理不可能样样都懂，尤其是高科技项目的项目经理，他们往往难以对工作进度和质量做出评估。项目同时包含不同的阶段，基本上是图1-9所示的顺序。项目开始时能使人激发起极大的兴趣，但很快情况就会变糟，就像你看到的，所有的人都在争吵，激烈的争吵过后，他才坐下来定义这个项目的需求，而这本是一开始就应当做的事。图1-9 典型的项目生命周期所以，我赞成图1-10所阐释的生命周期模式。这个模式适用于一般的项目管理，它包括五个阶段，有的模式仅包括四个阶段，即定义、启动、执行和结束。但是不要忘记，任何项目都是从某种构想开始的，并且，构想在最初常常是含糊不清的，所以，我们的工作就是去明确这个构想，并把它变成整个团队的共识。许多项目失败就是因为这一点没做好。事实上，我认为项目大多是在定义阶段就失败了。也许有些项目进行了很长时间，已经经历了其他阶段，但是，如果开始的定义是错的，他们就注定会失败。我们将在第5章讨论这个问题。图1-10 项目生命周期模型
