1985 年首次为美国一家保险公司的数据中心推动项目管理的应用，最大的挑战是如何结合“项
目管理”与数据中心的“系统开发体系”（System Development Methodology）,让项目进度能够有效管理，当时大部分工作环绕在机制的建设，过程中不断进行挑战，任务直到1987 年底才完成，数据中心开始拥有一套本身适用的管理模式，全部项目按建立的“系统开发规范”执行。1995 年为澳大利亚一家银行集团推广Method/1 的开发管理体系，银行集团本身已经有一套很成熟的管理模式，而且项目经理已经开始成为行政工作，但为了能够统一项目的执行方法，银行集团投入了数百万澳元及两年多的时间，还没有成功地让这套开发管理体系成为一套规范，各项目组虽然能够大部分按时及在预算下完成，但技术人员只对本身负责的业务范围内执行任务，让资源未能有效利用，技术人员未能在需要的时候被分派及支援其他业务的项目组。这个机会让我领会到管理体系与管理机制的结合的重要性，才能够有效实施。
过去的项目管理实施经验让我能够深刻地体会目前我国企业在推动项目管理过程中的困难，更
希望跟大家一起分享去年在国内为一家企业推广项目管理的经验，让项目管理能够在国内实施。过
去数年回国后一直主张“强化”，“统一化”，及“简化”来改善我国的管理能力，去年一家科技企业为我们提供了一个很好的机会，让我们能够实践这个“三化”理论。从八零年代中期开始，国外科技企业开始采用“项目管理”来负责技术交付，项目经理只是一个角色，由高级技术人员担任。但经过多年的应用，“项目管理”的价值已经被接受，在一些跨国企业中已经成为一门专业。
“项目经理”（Project Manager）已经被提升为一个职位。目前一些国际企业更设有“项目总监”(Project Director)，“首席项目官”(Chief Project Officer，CPO）等更高级的职位。这些职位的责任便是利用项目管理的手段（techniques）来完成项目的交付。有别与“小组主管”（Team Leader）或“项目组主管”（Project Leader），这些“主管”的工作除了管理小组成员的交付外，仍然保持相当多的技术责任，负责部分技术交付。
我国项目管理的困境
我国很多企业近数年相继推动项目管理的应用，但这些努力并没有显著地提升企业的管理能力，在聘用专职的项目经理后，项目仍然受到延误，成本及交付时间仍然未能受到控制，开发期间仍然需要不断返工，质量更不知从何说起。有些企业领导已经开始怀疑项目管理的实际价值，怀疑项目管理是否适合我国的企业文化，能否为我国企业带来经济效益。一些专业人员，在一些国际专业组织中考取了国际公认的项目管理专业资格，希望能够为单位效力，为自己的未来开展一个新的方向，但发觉在实际工作过程中，学习到的范围管理，时间管理，风险管理，资源管理，质量管理，成本管理等等一大堆理论都不能够在工作中实践，要不是本身的技术背景，让自己能够拥有技术的价值外，单靠“管理”便可能连工作也没有了，倒不如全力把技术工作做好，管理工作次之的心态来继续守着这一个“项目经理”的职位。
国内企业引进项目管理
去年，我们开始为国内一家科技企业进行咨询工作，这家软件服务企业本身有一套简单的项目管理流程，同时聘用了数名项目经理，希望项目管理能够改善项目超时，超支等问题。统计中显示过去有超过56％的项目未能如期交付，项目平均延误时间从三个月到一年不等，部分项目更延误超过一年多还未能让客户验收。他们希望“项目管理”能够改善他们的项目交付，提升企业的运营效率及利润指标。这家科技企业与大多数企业一样，以为聘用项目经理后，或让技术人员进行项目管理培训后便可以改善项目管理的能力，实施科学管理方法来提升企业的效益。假如一个专业潜水员穿上了深海潜水衣后一直站在甲板上，不管这名潜水员的能力有多强，缺乏身在深海中的“环境”，英雄还是没有用武之地。项目经理未能在企业中发挥其潜力，那是因为大部分企业欠缺一个能够配
合项目管理的环境。这个所谓“环境”包括企业必须拥有一套适合的“项目管理体系”（project management methodology），一套可以让项目经理执行工作的“管理机制”（management mechanism）。
强化：先建机制
每一家企业有他本身的商业目标及运营特色，而最重要的是本身的管理文化，建立管理机制是强化企业的管理文化，这个过程虽要企业高层的投入及支持，否则便不能够达到预期的结果。在这里与大家分享一些企业普遍需要的管理机制。再回到那家科技企业，须然所有项目都要经过“立项”，让高层审批后才能够启动，而立项申请书的内容也包括项目概述，预估工作量，预计工期，成本预算和资源需求等基本内容，但这些内容却未能让管理人员评估其真实性，未能反映出项目本身的复杂性，困难度等等问题，未能把立项申请书成为项目的初步基线。
机制一：基线建设
缺乏一个项目基线便不能够进行比较，不能够管理进度。假设你问两个属下，从大厦一层到大厦十层要多少时间？A 君告诉你2 到10 分钟，B君告诉你10 到15 分钟，那么你作为一个领导，如何衡量那一个的估算是比较准确呢？你该认同那一个的估算作为基线呢？也许你会自己去衡量，也许你自己估算出来的结果是5 到8 分钟。答案刚好在中间，那么你会采用那个估算做基线呢？慿你过去多年在单位上下班经验，你认为自己的估算会比较正确，所以用8 分钟作为基线，一声令下，两个属下马上实行从一层到十层的任务。你便进行进度跟进。一分钟后，你发现A 君原来是爬楼梯，已经到底一层，但B 君还在一楼等电梯。在进入第四分钟后，A 君已经在四层了，但B 君还在地下一层等电梯。你开始知道他们也许都不能够在你的基线内完成任务了，但仍然希望，只有B 君能够很快进入电梯，那么还是有希望可以在3 分钟内到底十层，在基线内完成任务。进入第六分钟了，A 君报告说现在在六层，但需要停下来休息一会，还好B 君已经进入电梯，在一层停下，因为有人出去。也许这时候你应该建议A 君利用其他的电梯完成余下的任务。进入第七分钟，你还是希望B 君能够顺利在一分钟内到底十层，但B 君却告诉你说在三层又停下来，因为三层有人把东西搬到六层及八层。这是你便理解他们都不能按你过去多年的经验在你建立的基线内完成任务。
其实作为一个项目经理，或者高层领导，在自己没有进行估算前，便应该理解属下提供的数据是如何获得，假设你能细问那两个属下，他们如何达到这个数据的估算呢？也许你便发现B 君是基于等升降机的时间，加上可能需要在各层停顿的时间估算2 到10 分钟的结果；而A 君告诉你他爬楼梯，平均1 分钟到1 分半钟一层的速度，大概不会超过15 分钟的时间。有了这些信息，你才知道他们的估算是如何结算出来的。所以项目建立基线必须要有一个规范，让每一个项目组成员都能够知道如果按照这个规范处理项目的工作，是可以在基线的时间内完成任务。COCOMO, Function Point Analysis, EMOD 等都是规范性工作量估算方法，但我们也可以依靠本身的经验，融合到一个企业本身的开发管理体系框架中，及项目架构分解（Project Breakdown Structure）下各工作包的交付目标来建立估算的规范，便能够更准确的建立项目基线。这是企业推动项目管理最艰巨的工作，基线建设规范是整个项目成败的关键，也是项目能否有效管理的根源。在推动基线建设的过程中，平均项目增加3％工作量，而且在推动初期有很大阻力，当项目经理完成基线建设的时候，发现自己以前的估计比基线少了30％的工作量，才发现其中有很多工作量以前在立项时并没有完全考虑到，这些新数据让他们体会到项目延误的一些主要原因。这个阶段需要高层的支持，同时需要为项目经理在过程中提供辅导，直至三个月后才能够让这个机制成为项目经理编写立项申请书的部分工作内容，让项目经理接受及认同。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
