分享

研发项目失败的分析与总结

 百战归来 2017-08-01



    几年前,笔者离开了信息产业部的研究所,来到一家民营的医疗器械企业,任研发中心的临床信息系统项目经理,但万万没想到,笔者所主持的项目失败了。一个研发项目的成败既有项目外部的因素,也有项目内部的因素。对于项目外部的因素项目组一般是难以扭转的,例如项目经费的削减,组织的业务方向的变更,客户对合同的违约等等。本文与大家分享一个失败的案例,从中我们分析失败的原因以及一些启示。


1、上层分歧给项目带来麻烦

  我刚来的时候,这个项目已经立项了,只是一直没有找到合适的人来实施。所以总觉得我是在受命组建一个新的部门,组织文化是空白的,不会有任何问题,可是上层的一些分歧却给我的工作带来了麻烦。公司的总经理和技术副总在工作上有矛盾。作为总经理招来的部门级主管,我在上班前一直没能与技术副总见面,不知道这算不算总经理犯的一个错误,虽然越级的人事安排也许有他自己的考虑。总经理介绍了他的一个同学作为我们的技术合作单位,有过一些初级的技术交流,技术副总后来得知此事,于是我就有了一大罪过:“你们探讨的问题都是代表公司的,到底谁是技术副总?”技术副总经理找我谈话时,我好半天没缓过气来。如果就数据库内某个字段的定义、用哪个芯片更好点的问题都要请示技术副总,我这个岗位还有存在的价值吗?


  于是我开始反思,认识到自己犯了一个很严重的错误:初来乍到,别人还没认清你的特点,信任度还没建立起来,怎么就没注意请示汇报呢!随后,我向副总承认了自己没有及时请示汇报的错误,并澄清了我们只是进行了一些技术交流,没有任何的越权行为。我开始注意调查,发现其实质是副总对该项目不是很热心,并因此与总经理产生了分歧,加上以前的许多事情,矛盾一下爆发了,我又是总经理招来的人,合作方又是总经理的熟人,这个事情就愈发严重了。


2、直接上司有时比董事长管用

  无奈之下,我只好把合作方砍掉,并且事事早请示晚汇报。不能在同一个地方跌倒两次,我总结发现,直属上司的支持比董事长都好使。高层只能在战略上支持,战术上还是直属上司的配合,正应了一句话“县官不如现管”。另外就是新到任的职业经理一定要对新的岗位进行认真调查,入职前与未来的上司和下属进行沟通是非常必要的。这次事件平息了,但有些事我不得不变得无所作为。很多审批权限在副总手里,于是项目一拖再拖。8个月后,在公司上层不断的施压下,项目组终于开始组建。


3、研发人员指挥生产的恶果

  产品开发过程平静而又顺利地结束了。我们决定采取用户购买后测试的方式。由于用户测试过于漫长,在进入这个测试之前,产品就归档转生产了。


  在我供职的这家民营企业,其高层和80%的中层干部都来源于一家老牌的国有医疗器械企业。这家公司长期从事手术床设备的相关业务,后来的新人也都是为那两个项目配的,所以新项目除了我和我的团队之外,无人过问。我们求教于别人,经常得到友好而又歉意的一笑。


  图纸完成了,生产部只安排了一个小伙子学习生产这个产品,没有安排专门的工艺人员转化工艺文件。这时手术床的设备产量已经不小了,并且中了几个大标,中标的机器都是成熟老机型,生产人员也较熟练,所以生产部就把主力都安排到那边去了。对生产部来讲,中标机器的生产是主要任务,我负责的机器就降到次要而又次要的地步,物流的供货也是优先别的机型。


  我太急了,太需要有一个结果来证明,急功近利的结局就是不懂生产管理流程的项目部开发工程师全力配合生产,犯了瞎指挥的错误,导致生产过程检验不规范、装机不符合要求、生产检验文档不全、零件编号混乱,一句话,乱了,一切全乱了。但是,机器还是源源不断地被发走。我暗自祷告,产量一大,我们开发的产品占主体时,一切会好起来的。


4、成也老专家,败也老专家

  在我们的团队中,有一位资深工程师、一位从业不久但业务熟练的软件工程师,另外还聘请了一位老专家作技术顾问。随后的阶段,那位老专家起到了保驾护航的作用。然而,如果没有对老专家的“过度信任”,也不会有产品推出后的狼狈局面。因为该设备要用到手术室中,手术室的电磁环境不但频率复杂,强度还不小,可惜这是产品销售后才发现的,为时已晚。开发中也曾有人提出这个问题,用不用考虑一下干扰问题,那位老专家一句话:“我们以前做过的都没什么问题。”问题是该老先生原来是做非手术室设备的,其电磁环境条件比手术室要好得多。我尝试着提了点反面意见,被很不屑地化解了。


  “阻碍社会进步的不是少年人的无知,而是老年人的固执”,终于有了切实的理解。在技术工作中,作为项目经理,别相信任何不经调查就得出“没问题”的口头保证,尤其是所谓资深老专家对新问题的结论。昨天的经验往往是明天失败的导火索。在预研阶段,要把所有可能的试验结果都呈现出来再做定夺。即使预研失败,损失也小得多。


5、越俎代庖的代价

  刚开始的装机和培训,服务部门的工程师没有人特别熟悉这台机器。于是服务部的经理找到我求援,希望开发工程师能出差。为了确保机器能顺利推广开,我应承了下来,服务支持文档、服务工程师的培训就这样耽误了下来。如此周而复始,最后只要有客户咨询或投诉,就直接转到项目部,使项目部的很多具体工作进行不下去。


  这还不是最糟糕的,开发工程师并未经过服务培训,而我们项目部的工程师对那些又不了解,其安装和用户培训却又要做,可想而知,结果自然是不到位,最后对机器、服务的抱怨都集中到了项目部上。


  拆东墙补西墙的救火没能使流程理顺,这时又出现了机器抗干扰差的投诉,这原本通过预研可以提前预防,现在也是尾大难调。只好找了一所大学的教授协助解决,虽有改进,结果也不是很理想。不过我实在没精力拿用户进行试验了,加上这番折腾,这个项目的利润被服务、退货、换货耗掉了一部分,销售渠道对产品的反应也很不好,抗干扰差、服务差、发错货,等等。面对危局,我无奈建议公司决策层停掉该项目。


  这个故事结束半年了,每每回想,总是感慨:项目不是在最后才失败的,也许它一开始就是一个错误,也许它的路线方向就是错的。


案例点评:

  这个案子比较棘手,棘手的原因是:当一个木桶只有一个短板时,你会很容易发现这个短板并进行修补,当一个木桶每个木板都成了短板时,要你修复这个木桶并说出修复的原因,恐怕就没有那么简单了。之所以这样说,是因为这个案例给出的场景,不管是从企业管理水平来说,还是就项目经理个人能力来说,都有需要改进的地方。


  首先我们分析一下企业的研发管理建设,如果一个企业重视管理(一个成功的企业也必须重视管理),公司会有许多流程、制度、模板、指导书,这些都是一个公司的无形资产。这就像一个法制健全的国家一样,为每一类的活动都规定了如何做是合法的。这样不管是新来企业的“空降兵”,还是公司老员工,一切业务活动都有了准则,对员工来说有了这些准则,既是规定,又是业务活动的指导书。


  企业的研发管理也是一个系统工程,管理体系建设应该从产品战略、研发组织结构、研发流程、项目管理制度、研发人力资源管理几个方面进行入手,所以说,一个成功的企业,在研发管理体系建设上至少具有以下特点:


  1、公司成立了项目决策机构,名称可以是决策委员会、投资评审委员会等,是一个跨体系的公司高层组成的团队,其主要职责是投资决策评审,主要任务是产品规划评审、技术规划评审、项目投资评审等,一般来说通过会议的形式进行评审,公司总经理任评审委员会主任,在会议上各委员发表意见,最后形成评审决议;评审委员会另外一个重要的职责是为项目团队提供资源,因为这些评委是各体系的高层管理者,既然项目通过了决策评审,这些高层就要承诺为项目提供人力、物资资源以保证项目成功。但案例中的企业,从场景材料来看是没有建立这样的评审委员会,所以往往通过层层行政审批的方式行使决策的职责,也往往会出现两个高层在审批时意见不统一,让项目经理处于难办的尴尬局面,导致了“上层分歧给项目带来麻烦。”


  2、公司在研发投入应具有战略定位,未来研发投入多少资金,占销售收入多大比例,这些研发投入又有多大比例投入新产品开发,多大比例投入技术研发,多大比例用来做订制产品项目?有了这些定位,就会照顾到眼前利益和长远利益的平衡,有了这些战略定位,在规划时就会为“中标的机器”和“我负责的机器”合理分配资源,不至于出现文中所提到“对生产部来讲,中标机器的生产是主要任务,我负责的机器就降到次要而又次要的地步,物流的供货也是优先别的机型。”


  3、公司建立了跨部门的产品开发团队组织结构。为成功的开发产品,这个团队一般由研发、制造、采购、测试、市场、销售、服务、财务等体系的人员组成,他们在项目经理领导下,共同完成决策委员会授予的项目目标,共同为项目的目标成功达成负责,项目经理对项目核心组成员具有考核的权力。案例中,没有建立跨部门的项目团队,所以到了试产、服务阶段,出现了“越俎代庖”的现象,这是因为让非专业的人员(开发工程师不是制造工程师、不是服务工程师)做专业的事情(制造和服务),制造部门、服务部门在这个新产品开发项目中没有起到真正专业部门的作用。


  4、公司建立了端到端的产品开发流程。一个企业要把成功的实践活动进行总结,形成公司的智力资产。新产品开发的过程可以用一个端到端的流程描述出来,所谓端到端是指从客户的需求开始到完整地把产品交付给客户,要把所有的活动识别出来,建立流程对此类项目进行管理,一个项目经理是按照公司的流程按部就班地带领项目团队进行开发,如果有了流程,项目经理管理的难度会大大降低,因为在这个流程中已经规定了建立项目团队、制订项目计划、制订产品包需求、制订技术方案、概要设计、详细设计、产品测试、可靠性试验、产品验证、产品服务等一系列的活动,并且针对这些活动建立相应的操作指导。如果有这样的流程文件,项目经理怎么能不做产品的可靠性试验呢?能不做产品的抗干扰试验就能发货吗?


  5、公司建立了产品可靠性试验指导书,指导测试人员进行产品可靠性测试,如EMC测试、抗高低温测试、震动测试、老化测试等,在这个指导书中,会针对不同类型的产品,描述测试的方法、测试的程序、测试的内容、测试的注意事项等,有了这样的指导书,项目成员就知道一个产品在走出公司到客户手中是要经过哪些可靠性测试,送到客户手中的产品才是一个质量信得过的产品,才能保证公司的品牌价值不受影响。


  6、在公司的文档管理制度中,已经规定了产品开发项目要提交哪些技术文档。这些文档可以作为产品升级的基础,也可以作为后来人员学习的基础文件,这样也可以降低个别“牛人”对公司的影响,因为按照公司的要求,这些“牛人”脑袋中的知识已经通过技术文档转化为公司的资产,可以在公司传播,员工也比较容易学到这些技术和知识,公司“牛人”少了,对公司管理是一件好事情。


  从案例描述中我们可以看出,这个公司没有针对研发管理方面建立相应的管理体系文件,如战略规划、流程制度、操作指导,不管是从CMMI(集成能力成熟度模型)的角度来看,还是从IPD(集成产品开发)的角度来看,公司的管理成熟度处于最低级别的水平,在这个级别中,主要的特点是公司的研发管理比较混乱,没有统一的管理流程和制度,产品的成功是信赖于个人的能力,而不是基于公司的管理能力,这种企业在中国不少,如果不从管理上下功能,建立企业的研发管理体系,企业想发展壮大是比较困难的事情。


  话又说回来,一个“空降兵”降到一个企业做管理,如果企业的管理成熟度比较高,那是比较幸运的事情,但我们不能要求所有的企业都具有较高的管理成熟度,而且公司把你招过来是想立即启动项目,也不可能给你时间再去建立管理体系。这也是上面分析谈到的,在这种环境下,项目的成功要依赖于个人的能力,就是所谓的“乱世出英雄”。


  如果空降到这个企业后,如果有较好的项目管理能力,也是可能成功地实施项目。针对这个项目至少在以下方面进行管理:

  1、确定高层在项目中的职责,建议高层成立评审委员会,总经理、副总经理通过会议形式表达对项目的批示,以及承诺为项目提供资源,减少项目经理和每个高层单独沟通时高层意见不统一给项目经理带来尴尬。并建立和高层沟通的机制,如阶段性决策评审、例外决策评审、项目双周进度报告等。


  2、要和高层沟通项目在公司的地位,当订单项目和战略性项目冲突时,确定战略性项目的地位就显得尤其重要,因为这是能不能获得资源的前提条件。


  3、制订完整的端到端的项目计划,通过WBS识别项目所有的活动,和高层协商为完成这些活动所需要的资源,因此试生产活动、服务活动应是这个项目计划中的活动。作为一个项目管理者,一定要重视计划和方案,不要一启动项目就直接进入开发阶段,如果项目没有经过概念阶段和计划阶段直接进入开发阶段,将会给项目后期的实施带来无尽的协调、沟通、变更,甚至注定项目失败的命运。


  4、接手项目后,在WBS基础上,要识别参与的项目团队成员,形成项目团队,这个团队要在决策评审会上让高层批准并承诺提供资源。建立团队的职责说明,如果有可能,针对团队的管理制度一并制订出来,在项目的启动会上进行讲解。项目团队成员一定要识别全,要成为真正意义的项目经理,这里的真正意义是指,项目经理应该是产品开发全流程的项目经理,涉及的领域包括市场、研发、销售、生产、采购、服务、财务等,只要是为了完成新产品开发项目目标涉及的所有领域都要管理起来,让各领域委派代表参加到你的项目中,如果有可能对项目核心组成员要有一定的考核权(IPD模式下的矩阵管理,建立了项目经理对核心代表的考核权)。


  5、这个项目,虽然你来的时候已经立项了,概念阶段要做的事情还是没有做到位,在概念阶段,应该确定客户的使用环境,这个环境中电磁干扰强度如何,应该把客户的使用环境搞清楚,为项目范围识别打下基础。还是上面所说的,一个项目没有经过严格的概念阶段和计划阶段就进入开发阶段,为项目失败留下的隐患。


  项目管理在国外是科学,80%是有规律可循的;在国内是艺术,主要靠个人魅力、感染能力等东西。在这个案例中,企业的低等级管理成熟度和个人项目管理能力的欠缺,是导致这个项目失败的主要原因。把一个项目真正管理好,也不仅仅需要以上几点的技能,是需要企业的管理能力和个人能力统一。



                                

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多