神州数码最佳实践之二：项目成功与盈利的关键因素——项目估算
作者：石海东
1.准确的项目估算是项目管理的前提
对于IT服务企业来说，项目估算是至关重要的基础数据。一方面，项目经理要根据估算做成本预算、资源需求、进度计划。如果估算错误，那么这些计划都是不符合实际的，项目经理、公司管理层都在一个错误的计划的基础上进行工作安排，其结果可想而知。另一方面，IT服务企业的项目报价，也是基于项目估算。根据项目估算的工作量和成本，打上公司要求的合理毛利率，最终得到基础报价。如果估算错误，报价也是无稽之谈了。
神州数码在第一次进行定量化项目考核时，就遇到估算的难题。定量化考核的结果，是有很多项目的进度、成本偏差非常好。比如原先预算200万的项目，实际只花费100万就完成了。这似乎是出色项目管理的表现——其实不然，大部分是因为项目经理在做预算时打入了太多的“余量”，或者说，项目经理严重高估了项目预算。
早期神州数码没有估算依据、没有标准估算过程，带来估算不准确的严重问题：
1.报价不准确，越大的项目报价越糊涂
很多大型软件服务项目（如千万级的项目），最终还亏钱，估算是主要祸首。通常金额越大的项目越复杂，项目估算也越难。通常项目经理倾向于“乐观估计”，尤其忽视项目过程中的风险，导致估算出来的成本大大低于实际。神州数码过去很多项目在实施的时候才发现，实际成本比报价高了几乎一倍，这种项目只有亏损一条路了。
2.销售人员与项目经理之间的冲突
在成本估算上，销售人员与项目经理本质上是冲突的。销售人员希望成本越低越好，而项目经理则希望打一些余量。在没有估算依据和标准的时候，这是一笔糊涂账。神州数码于2004年启动严格的项目利润考核与项目成本控制考核，这种考核制度进一步加剧了销售人员（对利润负责）和项目经理（对成本控制考核）的冲突。定量化考核原先是试图找到一个比较公正的考评办法，最终结果却完全走样。
3.评审人员难以确定预算合理性
作为审核预算的高级管理人员，同样面临困难。IT服务项目大多比较复杂，售前过程很长。高级管理人员没有时间深入售前过程，因此很难判断项目经理的估算规模是否准确。即使“感觉”预算过高，也仅仅是“感觉”而已，无法拿出依据。
2.软件估算是一个普遍的难题
IT服务行业的项目管理面临众多挑战，严格意义上说，IT服务行业的项目管理环境比很多传统行业要严酷。比如说房屋装修行业的项目管理，在方案提出、合同签署、工程实施开始、范围管理、变更管理诸多环节，其实是相当规范的，比很多IT服务项目管理还要规范。甚至在项目估算环节，无论是刷墙漆、铺地板、改电路，都有企业规定的估算标准，远比IT服务行业很多项目经理“拍脑袋”进行估算，要规范得多。
但是，软件服务的估算技术也是比较复杂的。在PMI的PMBOK©中，关于估算提出了一些技术参考，业内也有一些方法，如COCOMO、功能点估算等。但神州数码的研究发现很难在实际中应用诸如COCOMO等模型。
经过两年多探索，神州数码最终发展出一套比较实用的估算技术，并采用项目管理软件系统加以实现，取得了较好的效果。
3.项目估算必须基于企业历史数据
神州数码在走了很多弯路之后发现，最有效的估算依据是企业过去的历史数据。神州数码可能无法测算出标准功能点估算的数十个参数，但是历史数据是可以拿到的，而历史数据是真实能力的体现。
最终神州数码采用了三种估算方法，分别适用于不同的项目类型：
基于范围分解-历史经验数据的估算方法——适用于解决方案实施型项目
基于过程分解-历史经验数据的估算方法——适用于推广型项目
基于工作产品分解-生产率模型的估算方法——适用于纯粹软件开发项目
4.基于范围分解-历史经验数据的估算方法
对于“解决方案实施型”项目，项目的工作内容是有参照的。比如开发一个银行核心业务系统，银行核心业务系统的内容大致差不多：存款、贷款、结算等模块。或者一个ERP实施项目，ERP实施的模块也是大致差不多的。这种项目可以采用基于范围分解-历史经验数据的估算方法。
估算模型如下：
估算的核心，在于对项目范围进行分解，并分解到一个可度量、并且是能够提供历史数据的小模块。如银行系统的存款子系统，可以分解出：开户交易。而开户交易可利用过去企业其他项目的工作量经验数据。
上图是神州数码基于项目管理软件系统的估算模块界面。从上图可以看出，项目经理可以将工作范围进行分解，直至分解出某些特定的功能——而这些功能是可以从“组织估算库”中导入。
项目管理软件系统提供了：估算、估算基线化、组织估算库管理、估算库基线化、按系统分解和建立估算库等功能。神州数码建立了针对不同解决方案（系统）的功能分解估算库数据。
估算库数据的初始建立，可以选用一个大家公认的作为“标杆”的项目数据。虽然这个数据未必准确，但至少提供了一个进行估算的依据。企业可能通过逐步精化的方法，不断逼近准确的估算数据基础。
5.基于过程分解-历史经验数据的估算方法
过程分解模式也是一种估算方法。过程分解的理论依据是，采用偏过程的WBS分解方式。项目经理首先选取与当前项目类型类似的历史项目数据（记录在项目生命周期模板中），取得按项目实施阶段分布的工作量经验值，并结合项目实际情况进行调整。
这种估算方法比较适合推广型项目。比如完成了北京某局的工作，然后再做上海某局的项目。
6.基于工作产品分解-生产率模型的估算方法
纯粹软件开发项目，特别是内部研发型项目，受到客户干扰比较小，神州数码可以非常好的进行管理控制。神州数码研发部门通过了CMMI4级认证。CMMI提供了一套适合于软件开发、尤其是大规模软件开发的估算方法，其特点是首先估算软件产品的规模，然后根据一些策略估算工作量。软件的生产率是其中的一个核心参数。
7.结束语
软件服务项目的估算技术，是业内的难点，也是软件服务项目管理必须解决的问题。由于软件服务项目环境的不同，并不能简单的应用一些国际流行的估算技术（如COCOMO）能够解决问题。
神州数码认识到“解决估算问题”是一个必须完成的任务，在走了一些弯路之后，最终摸索出三种估算方法，适用于不同的项目类型，取得了很好的成效。
文章来源: http://www.visualproject.cn/news/A20070516_2.html
系列一:神州数码最佳实践之一http://www.leadge.com/publish/html/17469.html
1.准确的项目估算是项目管理的前提
对于IT服务企业来说，项目估算是至关重要的基础数据。一方面，项目经理要根据估算做成本预算、资源需求、进度计划。如果估算错误，那么这些计划都是不符合实际的，项目经理、公司管理层都在一个错误的计划的基础上进行工作安排，其结果可想而知。另一方面，IT服务企业的项目报价，也是基于项目估算。根据项目估算的工作量和成本，打上公司要求的合理毛利率，最终得到基础报价。如果估算错误，报价也是无稽之谈了。
神州数码在第一次进行定量化项目考核时，就遇到估算的难题。定量化考核的结果，是有很多项目的进度、成本偏差非常好。比如原先预算200万的项目，实际只花费100万就完成了。这似乎是出色项目管理的表现——其实不然，大部分是因为项目经理在做预算时打入了太多的“余量”，或者说，项目经理严重高估了项目预算。
早期神州数码没有估算依据、没有标准估算过程，带来估算不准确的严重问题：
1.报价不准确，越大的项目报价越糊涂
很多大型软件服务项目（如千万级的项目），最终还亏钱，估算是主要祸首。通常金额越大的项目越复杂，项目估算也越难。通常项目经理倾向于“乐观估计”，尤其忽视项目过程中的风险，导致估算出来的成本大大低于实际。神州数码过去很多项目在实施的时候才发现，实际成本比报价高了几乎一倍，这种项目只有亏损一条路了。
2.销售人员与项目经理之间的冲突
在成本估算上，销售人员与项目经理本质上是冲突的。销售人员希望成本越低越好，而项目经理则希望打一些余量。在没有估算依据和标准的时候，这是一笔糊涂账。神州数码于2004年启动严格的项目利润考核与项目成本控制考核，这种考核制度进一步加剧了销售人员（对利润负责）和项目经理（对成本控制考核）的冲突。定量化考核原先是试图找到一个比较公正的考评办法，最终结果却完全走样。
3.评审人员难以确定预算合理性
作为审核预算的高级管理人员，同样面临困难。IT服务项目大多比较复杂，售前过程很长。高级管理人员没有时间深入售前过程，因此很难判断项目经理的估算规模是否准确。即使“感觉”预算过高，也仅仅是“感觉”而已，无法拿出依据。
2.软件估算是一个普遍的难题
IT服务行业的项目管理面临众多挑战，严格意义上说，IT服务行业的项目管理环境比很多传统行业要严酷。比如说房屋装修行业的项目管理，在方案提出、合同签署、工程实施开始、范围管理、变更管理诸多环节，其实是相当规范的，比很多IT服务项目管理还要规范。甚至在项目估算环节，无论是刷墙漆、铺地板、改电路，都有企业规定的估算标准，远比IT服务行业很多项目经理“拍脑袋”进行估算，要规范得多。
但是，软件服务的估算技术也是比较复杂的。在PMI的PMBOK©中，关于估算提出了一些技术参考，业内也有一些方法，如COCOMO、功能点估算等。但神州数码的研究发现很难在实际中应用诸如COCOMO等模型。
经过两年多探索，神州数码最终发展出一套比较实用的估算技术，并采用项目管理软件系统加以实现，取得了较好的效果。
3.项目估算必须基于企业历史数据
神州数码在走了很多弯路之后发现，最有效的估算依据是企业过去的历史数据。神州数码可能无法测算出标准功能点估算的数十个参数，但是历史数据是可以拿到的，而历史数据是真实能力的体现。
最终神州数码采用了三种估算方法，分别适用于不同的项目类型：
基于范围分解-历史经验数据的估算方法——适用于解决方案实施型项目
基于过程分解-历史经验数据的估算方法——适用于推广型项目
基于工作产品分解-生产率模型的估算方法——适用于纯粹软件开发项目
4.基于范围分解-历史经验数据的估算方法
对于“解决方案实施型”项目，项目的工作内容是有参照的。比如开发一个银行核心业务系统，银行核心业务系统的内容大致差不多：存款、贷款、结算等模块。或者一个ERP实施项目，ERP实施的模块也是大致差不多的。这种项目可以采用基于范围分解-历史经验数据的估算方法。
估算模型如下：
估算的核心，在于对项目范围进行分解，并分解到一个可度量、并且是能够提供历史数据的小模块。如银行系统的存款子系统，可以分解出：开户交易。而开户交易可利用过去企业其他项目的工作量经验数据。
上图是神州数码基于项目管理软件系统的估算模块界面。从上图可以看出，项目经理可以将工作范围进行分解，直至分解出某些特定的功能——而这些功能是可以从“组织估算库”中导入。
项目管理软件系统提供了：估算、估算基线化、组织估算库管理、估算库基线化、按系统分解和建立估算库等功能。神州数码建立了针对不同解决方案（系统）的功能分解估算库数据。
估算库数据的初始建立，可以选用一个大家公认的作为“标杆”的项目数据。虽然这个数据未必准确，但至少提供了一个进行估算的依据。企业可能通过逐步精化的方法，不断逼近准确的估算数据基础。
5.基于过程分解-历史经验数据的估算方法
过程分解模式也是一种估算方法。过程分解的理论依据是，采用偏过程的WBS分解方式。项目经理首先选取与当前项目类型类似的历史项目数据（记录在项目生命周期模板中），取得按项目实施阶段分布的工作量经验值，并结合项目实际情况进行调整。
这种估算方法比较适合推广型项目。比如完成了北京某局的工作，然后再做上海某局的项目。
6.基于工作产品分解-生产率模型的估算方法
纯粹软件开发项目，特别是内部研发型项目，受到客户干扰比较小，神州数码可以非常好的进行管理控制。神州数码研发部门通过了CMMI4级认证。CMMI提供了一套适合于软件开发、尤其是大规模软件开发的估算方法，其特点是首先估算软件产品的规模，然后根据一些策略估算工作量。软件的生产率是其中的一个核心参数。
7.结束语
软件服务项目的估算技术，是业内的难点，也是软件服务项目管理必须解决的问题。由于软件服务项目环境的不同，并不能简单的应用一些国际流行的估算技术（如COCOMO）能够解决问题。
神州数码认识到“解决估算问题”是一个必须完成的任务，在走了一些弯路之后，最终摸索出三种估算方法，适用于不同的项目类型，取得了很好的成效。
文章来源: http://www.visualproject.cn/news/A20070516_2.html
系列一:神州数码最佳实践之一http://www.leadge.com/publish/html/17469.html