奇葩的项目进度滞后

1.前言

最近几年，我所带的三个项目，项目风险都较高，尤其这次所带的项目风险更高，目前项目风险已经转化为时间进度严重滞后的问题。

项目始于2013年年末的布局，我是在2014年上半年帮助客户做的规划和方案。那时，我所带的团队，专业技术人员超过10人。但是，直到2014年最后一个季度，上级才批复客户的规划。按照规划和实施方案，计划开发周期为5个月，开始时间点为2015年1月份，预估开发工作量为100~120人月，项目进度甘特图简图如下图所示：



先描述下项目初期系统建设方案设计时的场景，可以用设计汽车来打比方，设计目标是造运输车，可以拉集装箱、煤、蔬菜等，设计有5位参与者，其中2人是运输车设计者、1人是设计日式小轿车的、1人是设计推土机的，还有一位开运输车的老司机，这些设计者在一起讨论设计，其效率与结果可想而知，很难争论个出结果。

故事从这里就开始上演了。

项目执行不足一个月，其进度滞后就露出端倪，风险与问题接踪而来，截至五月末，投入成本滞后超过50%，什么情况呢？

2.项目进度滞后三大客观原因

2.1.人力资源投入不足的原因

项目策划阶段，原计划人力资源情况如下表所示：



预计可用资源数量为14人，其中，专业人员占比为21%。



注：由于这个人力资源计划存在兼职人员的问题，以及其他项目组空闲人员不可控问题，所以需要额外补充8名开发人员及产品厂商现场技术服务人员1~2名。

在项目开始后，由于各种原因，公司内部人力陆续减少，而招聘合作伙伴人员，又经过了2次笔试、7次筛选简历、4次面试，截止当前共计招聘补充了6人，现在人力投入情况如下表所示：



目前，项目组在岗人数为10人，其中，公司自有的专业人员为1人，占比为10%。



对比项目策划阶段与当前编码阶段，人力资源减员太多，特别是有经验、有能力的专业技术人员和开发人员的调转与流失，有江河决口的感觉。其中人员投入及工作量曲线如下图所示：



注：工时单位为人日；

有效工时是指部分人员能力不足所折算出的工作量（不够初级）；

项目中间时段人数多，是对新招聘人员进行培训、试用阶段，经优选淘汰，剩余不多。

从项目策划初期到当前，依据人力资源投入曲线，小结人力资源投入不足的问题：

（1）项目组内兼职人员过多，特别是高级人员的兼职，容易出现资源将不可控问题，也是很麻烦的问题，在兼职人员自身项目缠身时，影响范围不仅仅是其个人，还有身后所带的人员；当兼职人员撤出时，其工作无合适人员承接，原组员的压力陡增，出现了心态不平衡的问题。

兼职人员同时做多份不相关的工作，分散注意力，效率低（不同于专业分工参与不同项目，例如数据库管理员参与多个项目）；

由兼职人员身兼多份工作，必然产生资源竞争，在优先级不对等的情况下，不可控必然产生。

（2）新补充人力资源乏力，不仅从数据量上不足，人员的技术能力也明显不足，让人不得不对这种临时补充人员的模式产生怀疑，或者说，通过合作伙伴临时工方式补充开发主力人员几乎是不可能的。

从合作伙伴经营的角度来分析，不可能让有开发能力、有经验的开发人员空闲，更不可能让多名有能力的开发人员闲置；

从开发人员角度来分析，在个人职业发展的道路上，临时工所参与的项目，是应对个人发展有利的项目，一般是不愿意参与陌生的领域项目；再换个角度，有能力的开发人员有多少在以合作伙伴临时工的身份参与项目呢？即使有，估计也是以技术服务的高端角色参与。

2.2.采购流程与采购周期长的原因

2.2.1.项目相关采购流程

在公司ERP中，采购需求编制及审批流程如下图所示。



由于项目资源中的兼职人员必须在设计完成前离场，以及部分人员预计中途离场，必须通过招聘合作伙伴人员临时来补充；也由于项目的特性，需要平台厂商技术服务人员入场提供技术支持服务。对于这两个采购需求，执行情况如下：

1.项目采购平台厂商现场服务需求编制流程于立项后3个半月完成，实际操作上，平台厂商现场服务人员于第12周提前入场呢！

2.合作伙伴临时工是从第6周开始陆续招聘入场，最后1人入场是在第13周，从这儿以后再也没有招聘到人。整个过程是按先上车后买票的方式处理，已经完成了7轮筛选简历、2轮笔试、4轮面试，共计招入8人，当前剩余6人，人力资源缺口10人左右。

2.2.2.合作伙伴临时工采购情况分析

首先，我们来看看用工采购流程，整个流程涉及到具体生产部门、采购部门、人力资源，以及合作伙伴。从下面的简图不难看出，一次用工招聘的周期是较长的，其中合作伙伴提供临时工的环节是很难控制的，关键是多长时间能提供出合适的人选呢！通常情况下，完成此流程需要三周时间。

Created with Raphaël 2.1.2开始合作伙伴用工预算申请用工招聘申请用工采购人员发布招聘信息合作伙伴提供简历筛选简历、笔试、面试招聘用工采购人员按招聘结果录用人员结束

本项目采购合作伙伴临时人员，是经过多轮的招聘，此过程不仅耗费大量管理成本，也消耗了、拖延了项目的宝贵时间。

其次，是合作伙伴用工标准，此标准已经执行四年了，而其中的薪资标准没有调整过。按当前用工标准，给四年前的工资标准，招聘不到人员实属正常现象，更不用说招聘到有经验的开发人员。

总结本项目合作伙伴用工采购过程，由于采购周期和薪资标准的原因，但未达到预期目标。

2.2.3.技术服务采购情况分析

技术服务采购流程与合作伙伴采购流程相近，但是也出现了未预料情况。由于技术服务采购的特殊性，往往是需要定向采购，而提供服务的厂商又不是企业既有的供应商（产品是客户购买的），由于这个主要原因，供应商的入围和招标，又占用很多时间。

2.3.项目团队技术能力不足的原因

2.3.1.技术对比

技术点	本项目平台	J2EE架构	说明
技术架构	SOA	J2EE	都是B/S结构
云计算	PaaS 平台		支持Gartner 多租户模型
服务端开发语言	Java	Java
客户端开发语言	JavaScript	JavaScript	都支持JQuery
其他数据处理技术	XML、JSON	XML、JSON
关系型数据库	Oracle、MySql	Oracle、MySql
其他数据库	MongoDB、LDap	很少用
BPM	Cordys	很少用或其他开源工作流
开发工具	Cordys 与Eclipse	Eclipse	配置管理工具
开发框架	WebAppServer	Spring+iBas+Struts	客户端界面可通用

通过技术对比，我们不难发现本项目的技术架构为SOA，具备云计算PaaS平台能力，其特有的是BPM流程（只要是流程类的应用平台，都离不开工作流，例如JBPM），其他都是通用技术。

其中，要使用BPM流程产品，须经厂商5天的培训。

2.3.2.技术原因的影响分析

技术原因的实质体现在人力资源方面，其根本就是开发人员技术能力评价及技术应用市场的原因，有技术市场就有前途。

分析项目	人员技术能力	市场
BPM培训及学习	需要学习能力，并边学边工作	由于其专业性，应用市场面较窄
转型为SOA架构	需要学习能力并转型，并边学边工作	虽然外部市场很大，但内部很少用
PaaS平台使用	需要学习能力，并边学边工作	云计算有点远，但内部很少用
设计与编码开发	可复用资源少，外部资源少	内部缺少相应的激励机制
工作成果可复用度	复用难度高	可复用的环境少

通过上述分析，再看公司内部技术人员和合作伙伴临时人员对此技术的态度，只能敬而远之。

技术原因实质上是对技术人员的激励制度，需要从薪酬和市场前景等方向进行激励。

3.应对措施

3.1.跟踪风险及反馈问题

我在项目初期，按照CMMI规范体系，制定相应的管理计划，其中项目风险及管理计划如下表所示。



通过项目周报渠道，反馈项目风险和问题，以及跟踪处理情况。当前最新的问题跟踪列表如下：

3.2.协调资源

通过领导协调公司内部资源，结果是人员陆续的离开了项目组，原因很复杂，涉及到企业改革转型等方面，不在此讨论。结果是当前剩余2个半人，再加上1位神人，耗费我管理成本的神人。

3.3.专业技能培训

针对新招聘合作伙伴临时人员不具备专业能力的现状，项目组为他们提供了为期2周的培训，并进行了实战训练。

这样的培训成本相当高，新招聘合作伙伴临时人员学习积极性也非常高，培训效果很明显，开发技术基本掌握，但是业务及开发经验反而成为瓶颈，不足以独立进行功能开发。

3.3.时间换技术能力

通过加班（截止当前为2000小时）来拟补资源匮乏、技术能力严重不足的问题（不含新招聘合作伙伴临时人员初入职半个月的时间）。

3.5.外援

对于项目组来说，外援是指项目组以外的所有可用有效资源，包括平台厂商现场技术服务、合作伙伴临时人员、公司内部其他项目组可用资源。

外援分类	策划阶段	当前阶段
平台厂商现场技术服务	0	1
合作伙伴临时人员	0	6
公司内部其他项目组有效资源	6	1

注：流出支援其他项目组资源为5人。

3.6.争取客户凉解

由于本项目是升级改造类项目，存在现有系统。因此，首先需要支援运维组保障其现有系统稳定运行和新需求的开发。由于人员流动的原因，我在项目初期就支援2人顶替运维组的人力资源窟窿。

在项目执行过程中，多次在客户的要求下，支援运维组人力和工作。

上述情况，客户基本是了解的，也只能争取点儿谅解。

3.7.开拓视野

上述各项措施都不能有效的缓解项目进度滞后的问题，需要重新审视项目目标和实施计划。

3.7.1.积极方案

采用业务外包方案，通过平台厂商协助，寻找有能力承接业务外包的合作伙伴，把项目一部分整体分包给这类合作伙伴。

3.7.2.底线方案

拆东墙补西墙方式，抽调运维开发人员、其他项目组有效资源，并大幅延长工期，这样也是能完成项目的。

4.解决方案及新的计划

随着企业改革的逐步推进，新的企业发展战略逐渐清晰，本人理解战略是“由研发技术型转变为市场销售型企业”。做为项目经理，首先要完成经营目标——挣钱，然后是履行合同，信誉是靠经济基础支撑的。

下面按业务外包和延长工期来制定新的计划，并逐步展开落实。

4.1.采购再次启航

我即将走出去，扩大合作范围圈。

本地合作伙伴，由于受地域限制，符合能力要求的资源有限，这样，需要扩大合作范围。

探寻全新的合作模式，例如：项目分段外包，并由分包商承担将来的维保及新需求开发（新需求是指功能变更，以及有较大代码量的开发工作）。

4.2.新的计划

我按年末完成项目倒推排出新的进度计划，仍是不可行的计划，为什么？无实施资源。

5.总结

在投标项目时，已经识别到项目延期的风险，而且风险还很高，因此，我在公司立项第二日就编制采购厂商现场技术服务需求和采购合作伙伴临时人员的需求。但是，在项目执行过程中，发生超出项目经理职责范围的事，其结果必然导致项目进度滞后，并超出预期及可控范围。

5.1.所掌握的有效资源能否应对风险

开发团队所掌握的有效资源有：

资源名称	数量	目标占比	说明
专业技术人员	4	20%	在厂商支撑下逐步提高
平台厂商提供现场技术服务	0	10%	立项后，采购入场
合作伙伴临时开发人员	0	40%	立项后，采购入场
普通开发人员	4	20%	为平台上层开发主力
兼职开发人员	6	10%	为需求、设计主力，并由普通开发人员逐步替代

从上表可以看出，团队负责人可掌握的专业技术人员，仅占目标团队的20%，再加上普通开发人员总共才到40%，剩余60%都在风险状态中，这样的策划很不合理，风险过高，项目经理也只能接受。

解决方案是转嫁风险，通过掌握有开发能力的合作伙伴来补充整体资源，而不是通过合作伙伴提供临时开发人员。

5.2.企业管理风险是否可控

与项目管理相关的企业管理有采购流程、人力资源（激励制度），这些管理制度是否处在有效的运行状态下，以及项目经理对供应商掌握情况。

我在这里主要问题是未全面掌握供应商情况，例如：平台厂商所提供的技术服务，不在公司采购供应商目录中，这种定向采购风险很大，容易出现问题。

另外，忽略了合作伙伴采购临时工薪资标准未调整的情况，此情况是后续工作一大障碍。

5.3.技术风险是否可控

技术风险实质上是公司内部人力资源风险。

技术点	掌握人力	解决方案	当前现状
平台产品	3人	不足由平台厂商现场技术服务提供	1人
云计算	2人	不足由平台厂商现场技术服务提供	2人
MongoDB	0人	自学研究	2人掌握基本用法
PaaS平台生态环境	2人	不足由平台厂商现场技术服务提供	2人

注：人员专业技术能力由最初的4人缩减到当前2人（含项目经理）。

通过上表分析，项目策划阶段技术风险是可控的，而当前的现状是将失控，因为专业技术人员不仅没有增加，反而只剩下2人，这还得包括项目经理的情况下，很不合理。

技术风险由可控演变成失控的很大原因是缺乏员工激励，不仅没有愿意接受具有挑战性的工作，而且还要逃避。随着主力人员的流失，项目进度必然加速滞后。

解决方案是转嫁风险，通过掌握有开发能力的合作伙伴来拟补技术能力不足。