推动项目管理的阵痛

1、推动项目管理的阵痛1985 年首次为美国一家保险公司的数据中心推动项目管理的应用，最大的挑战是如何结合“项 目管理”与数据中心的“系统开发体系”（system development methodology）,让项目进度能够有效管理，当时大部分工作环绕在机制的建设，过程中不断进行挑战，任务直到1987 年底才完成，数据中心开头拥有一套本身适用的管理模式，全部项目按建立的“系统开发规范”执行。1995 年为澳大利亚一家银行集团推广method/1 的开发管理体系，银行集团本身已经有一套很成熟的管理模式，而且项目经理已经开头成为行政工作，但为了能够统一项目的执行方法，银行集团投入了数百万澳元及两年

2、多的时间，还没有成功地让这套开发管理体系成为一套规范，各项目组虽然能够大部分按时及在预算下完成，但技术人员只对本身负责的业务范围内执行任务，让资源未能有效利用，技术人员未能在需要的时候被分派及支援其他业务的项目组。这个机会让我领会到管理体系与管理机制的结合的重要性，才能够有效实施。 过去的项目管理实施经验让我能够深刻地体会目前我国企业在推动项目管理过程中的困难，更 期望跟大家一起共享去年在国内为一家企业推广项目管理的经验，让项目管理能够在国内实施。过 去数年回国后一直主见“强化”，“统一化”，及“简化”来改善我国的管理能力，去年一家科技企业为我们供应了一个很好的机会，让我们能够实践这个“三化”

3、理论。从八零年月中期开头，国外科技企业开头采用“项目管理”来负责技术交付，项目经理只是一个角色，由高级技术人员担当。但经过多年的应用，“项目管理”的价值已经被接受，在一些跨国企业中已经成为一门专业。 “项目经理”（project manager）已经被提升为一个职位。目前一些国际企业更设有“项目总监”(project director)，“首席项目官”(chief project officer，cpo）等更高级的职位。这些职位的责任便是利用项目管理的手段（techniques）来完成项目的交付。有别与“小组主管”（team leader）或“项目组主管”（project leader），这些

4、“主管”的工作除了管理小组成员的交付外，仍旧保持相当多的技术责任，负责部分技术交付。 我国项目管理的逆境 我国许多企业近数年相继推动项目管理的应用，但这些努力并没有显著地提升企业的管理能力，在聘用专职的项目经理后，项目仍旧受到延误，成本及交付时间仍旧未能受到掌握，开发期间仍旧需要不断返工，质量更不知从何说起。有些企业领导已经开头怀疑项目管理的实际价值，怀疑项目管理是否适合我国的企业文化，能否为我国企业带来经济效益。一些专业人员，在一些国际专业组织中考取了国际公认的项目管理专业资格，期望能够为单位效力，为自己的将来开展一个新的方向，但发觉在实际工作过程中，学习到的范围管理，时间管理，风险管理，资

5、源管理，质量管理，成本管理等等一大堆理论都不能够在工作中实践，要不是本身的技术背景，让自己能够拥有技术的价值外，单靠“管理”便可能连工作也没有了，倒不如全力把技术工作做好，管理工作次之的心态来连续守着这一个“项目经理”的职位。 国内企业引进项目管理 去年，我们开头为国内一家科技企业进行咨询工作，这家软件服务企业本身有一套简洁的项目管理流程，同时聘用了数名项目经理，期望项目管理能够改善项目超时，超支等问题。统计中显示过去有超过56的项目未能如期交付，项目平均延误时间从三个月到一年不等，部分项目更延误超过一年多还未能让客户验收。他们期望“项目管理”能够改善他们的项目交付，提升企业的运营效率及利润指

6、标。这家科技企业与大多数企业一样，以为聘用项目经理后，或让技术人员进行项目管理培训后便可以改善项目管理的能力，实施科学管理方法来提升企业的效益。假如一个专业潜水员穿上了深海潜水衣后一直站在甲板上，不管这名潜水员的能力有多强，缺乏身在深海中的“环境”，英雄还是没有用武之地。项目经理未能在企业中发挥其潜力，那是因为大部分企业欠缺一个能够配 合项目管理的环境。这个所谓“环境”包括企业必需拥有一套适合的“项目管理体系”（project management methodology），一套可以让项目经理执行工作的“管理机制”（management mechanism）。 强化：先建机制 每一家企业有他本

7、身的商业目标及运营特色，而最重要的是本身的管理文化，建立管理机制是强化企业的管理文化，这个过程虽要企业高层的投入及支持，否则便不能够达到预期的结果。在这里与大家共享一些企业普遍需要的管理机制。再回到那家科技企业，须然全部项目都要经过“立项”，让高层审批后才能够启动，而立项申请书的内容也包括项目概述，预估工作量，估计工期，成本预算和资源需求等基本内容，但这些内容却未能让管理人员评估其真实性，未能反映出项目本身的复杂性，困难度等等问题，未能把立项申请书成为项目的初步基线。 机制一：基线建设 缺乏一个项目基线便不能够进行比较，不能够管理进度。假设你问两个属下，从大厦一层到大厦十层要多少时间？a 君告

8、知你2 到10 分钟，b君告知你10 到15 分钟，那么你作为一个领导，如何衡量那一个的估算是比较精确呢？你该认同那一个的估算作为基线呢？或许你会自己去衡量，或许你自己估算出来的结果是5 到8 分钟。答案刚好在中间，那么你会采用那个估算做基线呢？慿你过去多年在单位上下班经验，你认为自己的估算会比较正确，所以用8 分钟作为基线，一声令下，两个属下立刻实行从一层到十层的任务。你便进行进度跟进。一分钟后，你发觉a 君原来是爬楼梯，已经究竟一层，但b 君还在一楼等电梯。在进入第四分钟后，a 君已经在四层了，但b 君还在地下一层等电梯。你开头知道他们或许都不能够在你的基线内完成任务了，但仍旧期望，只有b

9、 君能够很快进入电梯，那么还是有期望可以在3 分钟内究竟十层，在基线内完成任务。进入第六分钟了，a 君报告说现在在六层，但需要停下来休息一会，还好b 君已经进入电梯，在一层停下，因为有人出去。或许这时候你应当建议a 君利用其他的电梯完成余下的任务。进入第七分钟，你还是期望b 君能够顺当在一分钟内究竟十层，但b 君却告知你说在三层又停下来，因为三层有人把东西搬到六层及八层。这是你便理解他们都不能按你过去多年的经验在你建立的基线内完成任务。 其实作为一个项目经理，或者高层领导，在自己没有进行估算前，便应当理解属下供应的数据是如何获得，假设你能细问那两个属下，他们如何达到这个数据的估算呢？或许你便发

10、觉b 君是基于等升降机的时间，加上可能需要在各层停顿的时间估算2 到10 分钟的结果；而a 君告知你他爬楼梯，平均1 分钟到1 分半钟一层的速度，也许不会超过15 分钟的时间。有了这些信息，你才知道他们的估算是如何结算出来的。所以项目建立基线必需要有一个规范，让每一个项目组成员都能够知道假如根据这个规范处理项目的工作，是可以在基线的时间内完成任务。cocomo, function point analysis, emod 等都是规范性工作量估算方法，但我们也可以依靠本身的经验，融合到一个企业本身的开发管理体系框架中，及项目架构分解（project breakdown structure）下各工

11、作包的交付目标来建立估算的规范，便能够更精确的建立项目基线。这是企业推动项目管理最艰难的工作，基线建设规范是整个项目成败的关键，也是项目能否有效管理的根源。在推动基线建设的过程中，平均项目增加3工作量，而且在推动初期有很大阻力，当项目经理完成基线建设的时候，发觉自己以前的估计比基线少了30的工作量，才发觉其中有许多工作量以前在立项时并没有完全考虑到，这些新数据让他们体会到项目延误的一些主要原因。这个阶段需要高层的支持，同时需要为项目经理在过程中供应辅导，直至三个月后才能够让这个机制成为项目经理编写立项申请书的部分工作内容，让项目经理接受及认同。 机制二：工作包建设 许多项目组都缺乏一个明确的工

12、作分派方法，小组各成员对本身的任务及责任不明确，各小组成员根据自己的意愿随便地开头项目活动，结果做成混乱，相互推卸责任，或在后期才知道遗漏了部分工作，让其他小组未能如期完成，或需求返工，进行修正等工作。所谓工作包是工作分派方法的一种，主要是让项目中的每一个小组主管明确知道本身负责交付的工作及小组成员的组合。项目经理需要让小组负责人明确地知道他本身在这个项目中的责任，需要执行的工作，估计开头及完成日期，预估工作量，小组成员名单，个别成员工作量预估，虽要进行协调及沟通的对象，开头前所具备的条件，最终的交付及质量指标等信息，也可能包括已经知道的初步风险及说明应变措施，应当依从的技术要求及使用的工具等

13、信息。让小组主管明确理解本身的任务，责任及交付。工作包的建设是继基线建设后的另一个挑战。如何有效采用工作架构分解（work breakdown structure, 有些专业书刊翻译为工作分解架构，但我认为工作架构分解比较合适，因为wbs 的目的是把有关工作进行分解，才能够显示该工作的架构，中文跟英文的应用方式不一样，不应当按字面进行翻译，应当按整体意思进行翻译）来分派工作。基于过去大部分企业未有周详的工作计划，所以开头的数月需要不断供应训导及指示，让项目经理能够在工作包建设的过程中熟悉如何不断修正原计划，及与 小组主管进行协商，才能够一步一步完成工作包的建设。 机制三：进度汇报 以上两个机制

14、的实施当然会影响项目开头时的工作交付，例如最初计划在立项后一个月内完成调研的工作，但由于立项前及立项后的计划工作需要更具体的考虑，才能够建立项目基线及工作包说明，所以必需在项目开头时跟客户进行协商，在项目启动会议时让客户理解这个项目将采用的管理方法及汇报流程，实施方案和最终效益，让客户认同及参与。大部分企业的项目都有进度周报，月报等管理机制，但这些报告的内容多未能与项目基线进行有效比较，让管理人员明确知道目前项目状况，对项目进度及资源能力进行分析。项目经理需要强制性要求项目组员定期及按时提交进度报告，国内常见的进度报告大多象编写文档的格式，组员填写有关内容，出来的结果大部分未能让项目经理有效把

15、握进度。许多项目经理在收取进度报告后，只简洁把全部的报告进行汇总，然后便上缴领导。既没有对项目的进度进行评估，也没有考虑组员是否铺张时间在一些未有计划的工作中，更没有考虑这些组员提交的报告能否供应足够信息对项目的进度全面把握。我个人认为这个所谓进度报告应当是项目进度更新报告，只需要组员按工作计划编号供应简洁的数据，让项目经理能够对更新后的数据进行分析。 其实一个项目经理在收到组员的进度向信息后，需要组合有关信息并对有关内容进行评估，任何疑问都应当要求组员解释清晰，让项目经理进行风险评估及进度分析，才能够全面把握项目的进度。任何可能发生的风险都需要建立应变方法，同时需要该组员或有关组员沟通，让他

16、们知道当风险发生的时候，他们该如何实施已经建立的应变措施，及应当跟谁进行沟通，才能够有效的监管项目进度。在实施的过程中，我们为项目经理供应辅导，让他们理解进度报告中收集及整理后如何分析数据，如何利用有关数据来评估项目风险，加强部分小组的支持及供应资源，保证工作能够按计划实施。 机制四：定期评估及审核 要能够衡量机制本身能否带来价值，机制建设初期必需建立一个指标，让企业能够评估新管理机制的建设所带来的结果是否应当全面推广，还是应当进行修改来支援企业的运营方向。 我们建立了项目组每周评估会议，管理层每月审核会议，不断监控机制的应用及评估各种机制的价值，同时让企业中的技术人员明确理解这是企业的将来管

17、理方向，受到高层的支持和参与，目的是期望能够改善企业管理文化，让技术人员能够在管理机制下更有效的执行工作。 机制五：问题提升流程 项目经理在实施过程中常遇到许多本身不能够解决的问题，每一个问题都可能延误项目的最终交付，企业管理层必需定期为项目经理供应支援，为项目经理供应指示，才能够保证项目经理执行有关打算。建立提升流程，必需建立职责及职权，我们采用以下四级分工架构，非本身职权范围的打算必需提升到上层进行处理。 企业内部必需明确各管理层及项目组织的职责及职权。职责是企业指派的工作责任，要完成这些所交付的责任，必需赋予有关职权，在职权范围内完成交付的工作。 机制建设的价值 我们在这家科技企业建立以

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