至于什么是“省”？当然，省钱不是项目管理中最重要的目的。一个项目该花多少钱，是早就算出来的。一般来说，如果实际的花费和预估的花费差别在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日系统内部测试；
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 