工期紧，活儿只能凑合了；超支，赶紧砍内容，别弄那么多；资源有限，人手奇缺，往后拖吧。

    这就是我们身边项目运作时常发生的状况。

    所有的项目经理都会做预算，都会设置检查点，都知道又要无休止的协调。但真正执行起来，千变万化的现实让他们经常无所适从。

    时间、质量、成本 难平衡!

    在纸上画一个等边三角形。在各个边上标上时间、质量、成本。我们会看到，任何一方的移动必定带动其他的变形。这个三角形中间又是什么呢？是范围管理，也就是项目范围。这个三角也就是我们常说的“项目管理三角形”。时间、成本、质量就是项目管理的三要素。有一种比喻更能说明三要素之间的关系。

    小高为了取悦新认识的女朋友，精心设计了欧洲8日游，旅游花光了他多年的积蓄，旅游结束后，他再也没有财力去继续下一步的发展了。用项目管理的话说，这就是不计成本的恶果。

    过了一段时间后，他又攒了一些钱，这次他不和新女朋友旅游了，他请这个姑娘看了场电影—《第一滴血》。看完后，女朋友觉得小高有暴力倾向，又分手了。这一次，小高败在不讲质量。

    第三次，小高知道女孩子一般喜欢看歌舞剧，他准备请第三个女朋友去看半年后才上演的《天鹅湖》，战线一直拉着，女朋友爱上了别人——时间拖得太久了。

    这个比喻形象地说明了项目管理中的难题：如何平衡三要素之间的关系？

    一般来说，管理者都希望项目完成的时间要快，完成的成本要低，完成后的质量要好。可是这三个要素是彼此互斥的。能够完美做到以上三个要素的项目，少之又少。上世纪60年代初，肯尼迪总统下令要十年内把人送上月球，并安全带回来。这个庞大的计划，要快，必须赶在前苏联之前完成；要好，绝不能出现任何差错；并且在预算上有限制。

    结果，在各方为这个项目大开绿灯之后，美国果真抢先把人类送上月球，并平安带了回来。当然，我们平常的项目不可能集所有人力、物力、财力等所有资源，并且得到至高无上的尚方宝剑。

    因此，在一般的项目上，这三个要素，彼此之间是鱼与熊掌的关系。要兼顾的难度，会按照几何级数上升。这样一个三角难题，我们怎么去解呢？可以试着从两方面着手。

    第一，先弄清楚什么是“好”，什么是“快”，什么是“便宜”。

    什么是好项目？一般来说，项目的结果使企业的收入增加、支出减少、服务加强，就是好项目。

    那么，什么是“快”？在项目管理上，时间是绝对的。项目经理最容易犯的错误，就是在完工日期的预测上，为了讨好上司而尽量乐观。同时，他们总用历史数据或别人的经验影响自己的预测，也使得项目工期的变化比较大。

    要达到预期完工的要求，项目经理要把一个规模大、时间长的项目，分成不同的阶段完成。在每个阶段，又要根据每阶段不同的重点分别来做完工预测。工程分得越细，预测的准确性就越高。这道理很普通，但需要很周详的计划和分析。

    至于什么是“省”？当然，省钱不是项目管理中最重要的目的。一个项目该花多少钱，是早就算出来的。一般来说，如果实际的花费和预估的花费差别在30%以内，是能接受的范围；超过30%，预算有问题。项目经理在预算方面遭受的压力，比什么都大，因此，在做预算的时候，必须面对现实，而且一定要掌握一个原则—项目的“涨价”必不可少，做预算时打出点富余是正经。

    三个要素互相制约，找准一个平衡点，才能让三者平衡。很多时候，由于外在和内在的压力，取舍是免不了的。要做好取舍分析，项目经理要懂得六件事：

    第一，要很清楚地了解项目冲突的基本原因；第二，重新确认项目的目的；第三，了解项目现处的环境及目前状况；第四，寻求可行的其它方法；第五，选择最佳的其他方法；第六，重新策划项目计划。 

    工作分解咋控制？ 

    “计划赶不上变化!”一个项目经理感叹道。

    的确，项目中有相当多的不确定因素，项目经理辛辛苦苦做的WBS（工作分解结构），可能因为客户的改变，甚至领导的一句话，就分崩离析了。一些公司高层没有经过仔细考虑，也没有充分征求各个方面的意见，在制定总体计划时比较随意，修改起来更是“信手拈来”。项目经理也常常借口工作忙等理由，拖延制定详细的WBS，甚至有项目经理认为，不应该制定详细的WBS。

    而没有详细WBS的危害也是明显的：造成计划与控制管理脱节，无法进行有效的进度控制管理，最终导致项目延期或成本上升。可以说，没有WBS或者是随意的不负责任的WBS的项目是一种无法控制的项目。面对各种潜在的变化，项目经理应该怎样制定WBS呢？

    首先项目经理应该对WBS有正确的认识，制定WBS就是一个对项目逐渐了解掌握的过程，通过这个过程，项目经理可以知道哪些要素是明确的，哪些是要逐渐明确的，通过渐近明细不断完善。渐近明细也是项目的一个特点，因此WBS的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。

    再者，制定WBS需要有一个现实的方法。一个大型的软件开发项目，通常是采用二次WBS方法。即根据总体WBS，在需求调研阶段结束、概要设计完成后，再专门针对详细设计或编码阶段制定二次WBS 。

    一个方面，需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的，只能据此制定总体的WBS。另一个方面，需求和编码工作分解不是一一对应的，一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块。只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS。

    例如，某系统集成公司与银行签订了一个银行前置机的软件系统的项目。合同规定，6月28日之前系统必须投入试运行。项目经理小丁组织大家制定了项目的WBS，并制订了本项目的进度计划，简单描述如下： 

    1．应用子系统：1月5日～2月5日需求分析，2月6日～3月26日系统设计和软件设计，3月27日～5月10日编码，5月11日～5月30日系统内部测试； 

    2．综合布线：2月20日～4月20日完成调研和布线；

    3．网络子系统：4月21日～5月21日设备安装、联调；

    4．系统内部调试、验收：6月1日～6月20日试运行，6月28日系统验收。 

    2月17日，小丁发现系统设计刚刚开始，由此推测3月26日很可能完不成系统设计。小丁应该如何做，以保证项目整体进度不拖延呢？

    小丁编制的这个WBS比较粗糙，不适合作为编织项目计划的基石。只有一个项目的大概框架和子系统各部分的期望完成时间。从该WBS上面可以看出最底层任务的工期至少也在半个月左右。如果任何一个任务出现了问题，就必然会出现小丁现在遇到的问题，即延期和延期发生了较长时间才知道。

    在这种情况下，小丁最好是制定二次WBS。最终分解任务的工期最好不要长于一周，否则可能出现失去控制的情况。而且，在不同阶段应该有具体直接的责任人。作为项目经理，小丁需要保持与某阶段的直接责任人沟通，了解进度、发现问题。