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％的工作量，才发现其中有很多工作量以前在立项时并没有完全考虑到，这些新数据让他们体会到项目延误的一些主要原因。这个阶段需要高层的支持，同时需要为项目经理在过程中提供辅导，直至三个月后才能够让这个机制成为项目经理编写立项申请书的部分工作内容，让项目经理接受及认同。

机制二：工作包建设

很多项目组都缺乏一个明确的工作分派方法，小组各成员对本身的任务及责任不明确，各小组成员按照自己的意愿随意地开始项目活动，结果做成混乱，互相推卸责任，或在后期才知道遗漏了部分工作，让其他小组未能如期完成，或需求返工，进行修正等工作。所谓工作包是工作分派方法的一种，主要是让项目中的每一个小组主管明确知道本身负责交付的工作及小组成员的组合。项目经理需要让小组负责人明确地知道他本身在这个项目中的责任，需要执行的工作，预计开始及完成日期，预估工作量，小组成员名单，个别成员工作量预估，虽要进行协调及沟通的对象，开始前所具备的条件，最终的交付及质量指标等信息，也可能包括已经知道的初步风险及说明应变措施，应该依从的技术要求及使用的工具等信息。让小组主管明确理解本身的任务，责任及交付。工作包的建设是继基线建设后的另一个挑战。如何有效采用工作架构分解（Work Breakdown Structure, 有些专业书刊翻译为工作分解架构，但我认为工作架构分解比较合适，因为WBS 的目的是把有关工作进行分解，才能够显示该工作的架构，中文跟英文的应用方式不一样，不应该按字面进行翻译，应该按整体意思进行翻译）来分派工作。基于过去大部分企业未有周详的工作计划，所以开始的数月需要不断提供训导及指示，让项目经理能够在工作包建设的过程中认识如何不断修正原计划，及与
小组主管进行协商，才能够一步一步完成工作包的建设。

机制三：进度汇报

以上两个机制的实施当然会影响项目开始时的工作交付，例如最初计划在立项后一个月内完成调研的工作，但由于立项前及立项后的计划工作需要更详细的考虑，才能够建立项目基线及工作包说明，所以必须在项目开始时跟客户进行协商，在项目启动会议时让客户理解这个项目将采用的管理方法及汇报流程，实施方案和最终效益，让客户认同及参与。大部分企业的项目都有进度周报，月报等管理机制，但这些报告的内容多未能与项目基线进行有效比较，让管理人员明确知道目前项目状况，对项目进度及资源能力进行分析。项目经理需要强制性要求项目组员定期及按时提交进度报告，国内常见的进度报告大多象编写文档的格式，组员填写有关内容，出来的结果大部分未能让项目经理有效把握进度。很多项目经理在收取进度报告后，只简单把所有的报告进行汇总，然后便上缴领导。既没有对项目的进度进行评估，也没有考虑组员是否浪费时间在一些未有计划的工作中，更没有考虑这些组员提交的报告能否提供足够信息对项目的进度全面掌握。我个人认为这个所谓进度报告应该是『项目进度更新报告』，只需要组员按工作计划编号提供简单的数据，让项目经理能够对更新后的数据进行分析。

其实一个项目经理在收到组员的进度向信息后，需要组合有关信息并对有关内容进行评估，任何疑问都应该要求组员解释清楚，让项目经理进行风险评估及进度分析，才能够全面把握项目的进度。任何可能发生的风险都需要建立应变方法，同时需要该组员或有关组员沟通，让他们知道当风险发生的时候，他们该如何实施已经建立的应变措施，及应该跟谁进行沟通，才能够有效的监管项目进度。在实施的过程中，我们为项目经理提供辅导，让他们理解进度报告中收集及整理后如何分析数据，如何利用有关数据来评估项目风险，加强部分小组的支持及提供资源，保证工作能够按计划实施。

机制四：定期评估及审核

要能够衡量机制本身能否带来价值，机制建设初期必须建立一个指标，让企业能够评估新管理机制的建设所带来的结果是否应该全面推广，还是应该进行修改来支援企业的运营方向。

我们建立了项目组每周评估会议，管理层每月审核会议，不断监控机制的应用及评估各种机制的价值，同时让企业中的技术人员明确理解这是企业的未来管理方向，受到高层的支持和参与，目的是希望能够改善企业管理文化，让技术人员能够在管理机制下更有效的执行工作。

机制五：问题提升流程
项目经理在实施过程中常碰到很多本身不能够解决的问题，每一个问题都可能延误项目的最终交付，企业管理层必须定期为项目经理提供支援，为项目经理提供指示，才能够保证项目经理执行有关决定。建立提升流程，必须建立职责及职权，我们采用以下四级分工架构，非本身职权范围的决定必须提升到上层进行处理。

企业内部必须明确各管理层及项目组织的职责及职权。职责是企业指派的工作责任，要完成这些所交付的责任，必须赋予有关职权，在职权范围内完成交付的工作。

机制建设的价值

我们在这家科技企业建立以上五种机制，开始时为企业的项目平均增加15％的管理工作，但已经慢慢降低至8％的管理工作。过去12 个月的统计，显示整体利润指标提升了13％，项目未能如期交付的比例已经从过去的56％降低至43％。延误的时间也从过去的三个月至一年降低至不超过6 个月。
迟迟未能验收的项目也有专人负责重新立项，与他们的客户进行协商，希望能够在短时间内完成终验。项目管理机制当然不是单单以上的五点便能够全面解决项目管理上的问题，我们一共建立了28 各管理机制来保证项目能够受到控制。文章只选择这五点是因为大部分企业的管理都虽要从以上五点开始，才能够保证项目能够有机会成功。机制的建设未能完全解决开发过程的返工量，未能解
决项目范围变动所带来的影响。这些都需要在项目管理体系建设完成后才能够体系项目管理的真正价值。

统一化：后建体系
项目管理体系同样是企业管理环境建设的一部分，机制与体系必须结合，提供全面的项目管理环境，项目管理专业人士才能够发挥“项目管理知识体系”（Project management Body of Knowledge, PMBoK）的理论。项目管理体系为企业提供一套项目管理规范，让项目能够按阶段或步骤实施，在各阶段或步骤执行各种管理的工作。要建立一套成熟的管理体系需要很大的投资和多年的时间，但幸好国际上已经有一套项目管理体系的标准，所以协商后这家科技企业决定采用这套标准来进行“统一化”的工作。

我们计划从六月开始，将会尝试实施PRINCE2 项目管理体系（有关PRINCE2 内容可参阅“机械工业出版社”发行的“PRINCE2－成功的项目管理”一书）的应用，并安排部分项目经理进行项目管理从业员资格认证，结合已经建立的项目管理机制，我们估计项目延误可以降低到25％至30％之间的目标，同时可以大量降低项目范围变动，开发期间技术返工的需求。让这家企业能够全面体现项目管理的应用价值。任何企业文化的改革都会带来阵痛，在企业中推动“项目管理”也不例外，企业必须明确认识到项目经理需要企业提供所需的工作环境――项目管理体系及管理机制――才能够体现科学管理的价值。

黄绍良教授
昆山泓森信息科技管理顾问有限公司执行总裁

文章来源: 网友原创

【 发表评论 0条 】