工期紧,工作只能凑合;超支,赶紧砍内容,不要弄那么多;资源有限,人手奇缺,以后再拖。这是我们周围项目运营中经常发生的情况。所有的项目经理都会做预算,设置检查点,都知道要无休止的协调。但是,当它真正实他们往往不知所措。
平衡时间、质量成本难以平衡!
在纸上画一个等边三角形。在每个边缘标记时间、质量和成本。我们可以看到,任何一方的移动都必须驱动其他变形。这个三角形的中间是什么?它是范围管理,即项目范围。这个三角形通常被称为项目管理三角形。时间、成本和质量是项目管理的三个要素。有一个比喻可以更好地解释三个要素之间的关系。
为了取悦新女友,小高精心设计了欧洲8日游,花光了多年的积蓄。旅行结束后,他再也没有钱继续下一步的发展。用项目管理的话说,这是不计成本的后果。
过了一段时间,他又攒了一些钱。这一次,他没有和新女友一起旅行。他请女孩看电影《第一滴血》。看完之后,女朋友觉得小高有暴力倾向,又分手了。这一次,小高失去了质量。
第三次,小高知道女孩们通常喜欢看歌舞剧。他打算邀请第三个女朋友去看半年后才上演的《天鹅湖》。战线一直拉着,女朋友爱上了别人——拖得太久了。
这个比喻生动地解释了项目管理中的问题:如何平衡三要素之间的关系?
一般来说,管理者希望项目完成时间快,完成成本低,完成后质量好。但这三个要素相互排斥。很少有项目能够完美地实现上述三个要素。20世纪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。最终分解任务的工期最好不要长于一周,否则可能出现失去控制的情况。而且,在不同阶段应该有具体直接的责任人。作为项目经理,小丁需要保持与某阶段的直接责任人沟通,了解进度、发现问题。稀缺资源怎么抢?
小阎刚被任命为公司某桥梁设计项目的项目经理时,内心喜悦之情难以言表。可是才过了不到半个月,面对“沟通复杂化”、“资源争夺战”,他已愁容满面,这是怎么回事?
原来,公司为这个项目组建项目组时,人力上,核心组员一共才5人,其中还有两位由于来自公司其他部门,时常被其所在部门领导临时派活;经费上,公司没有下放任何权限,所有项目开支仍然要经过公司研发主管、财务部门、公司总裁一系列的审批程序;物质上,项目开发