阳光博客社区-ShineBlog.com 
PMO运营的失败总结
2014-12-27 21:34:37

  故事发生在三年前的一个自动化公司中,公司发展正当上升期,正在准备集团化,且已经建立了新的园区,准备搬过去。虽然外部看着热热闹闹的,但是家家有本难念的经,公司内部各种矛盾和问题也发展的热热闹闹的,为了解决这些问题,成立了PMO部门。此时带队的是一位有10年的工作经验(2年的外包开发、5年的公司内网开发及维护,主要是单兵作战、3年的QA经验),在公司已经工作了8年的员工,参加过两次PMP考试,但没通过。当时的职位是QA组长,具体工作如何不太清楚,只知道在领导面前很会表现,是那种可以把6分才能表现成10分的人。

  最开始组建PMO的时候,设想的是招聘几个有经验的人,来解决公司面临的问题。实际也曾经招过几个,但没有一个待到试用期结束,离开的理由也各式各样,但结果是都离开了。这么几来几去一耽误,一年时间就过去了,在这一年的时间里具体都做了些什么事,成果如何都不太清楚,只是在我进入该公司的时候,没见过任何走了的这些人遗留下来的工作或者做的组织资产沉淀。所有人都走了之后,我进入了这个部门。开始时,做的工作主要有三部分:

  1)组织一个软件的试用情况例会:

  因为我是新来的,且之前从来没用过这个软件,所以基本上听不明白他们在讨论的是什么问题,也不太清楚使用这个工具的远景和近景如何,投入产出比如何。

  2)收集项目执行过程中的财务数据并进行分析,出月报:

  这个工作主要是每个月从财务部把各个项目的支出要来,与项目立项时的每月支出计划相比较,看看是多花了还是少花了,说是分析,也不过是把多花还是少花了明示出来而已。

  3)有规章制度要发布的时候,帮别人跑跑签字等:

  这个工作就更简单了,就是别人想发布什么规章制度(在该公司,只要经过了评审和审核,任何人都可以发起规章制度的发布活动)的时候,帮人家看看有什么不合适的地方,然后帮着跑跑腿,找相关领导签签字什么的。

  4)为公司的内网开发一些小的功能模块:

  说实话,我实在没弄明白为什么这部分工作会在刚刚成立的PMO部门中存在,公司有专门的信息服务部,就是内网的维护和开发工作,到现在我也没弄明白这部分工作是为什么做的,可能跟此时带队的人之前的工作经历有关吧。

  这三件事情,只是文秘性质的工作,没什么好坏之分,也没有什么特别的影响力,当然也没解决什么关键的问题。

  之后,也就是在我试用期过后,又过了一个多月的时间,部门的领导说要发展一下,招了三个刚毕业的学生,交给我带,同时,有一个事业部的领导也受不了内部矛盾的折磨,希望跟我们合作,帮他们解决问题。于是我将手头的所有工作都交给了新来的毕业生,自己去帮事业部的忙,同时做另外一些事情。接下来我会详细讲解这一阶段所做的事情及其结果。

  有了新鲜血液的加入,虽然只是初入职场的新人,但仍值得高兴一把,将部门的很多工作都重新做了规划。下面是我们做的主要的几件事情和取得的成果:

  1)要求公司所有研发项目提交项目周报

  执行情况:制定了项目周报模板,并进行了数次改版,给各事业部项目经理进行了宣贯,PMO部门每周收集项目经理的周报,进行统计(包括是否提交,提交上来的周报是否符合要求等),并将统计结果发送给各事业部的领导及。

  结果:除了给各项目经理增加了每周提交周报这一工作之外,似乎没解决什么实际问题。也没听说哪个事业部的领导根据周报中得到的信息做了什么工作,也没见过哪个项目经理通过周报反应什么问题。

  2)开发项目管理信息系统

  执行情况:由PMO部门的员工提需求,开发部门新招了4个刚毕业的学生开发。

  结果:提需求的人和开发的人都不是熟悉公司项目或者项目管理专业的人,信息系统的开发自然也是一波三折,直到一年以后,还没听说有什么可用的功能拿出来使用。

  3)召开研发项目汇报会

  执行情况:每季度召开一次研发项目的汇报会,会议的主要内容是每个项目经理向公司领导(包括总经理和董事长)汇报自己项目的情况,遇到过哪些问题,是如何处理的,有哪些可供别人借鉴的东西。

  结果:这算是PMO发起的工作中,评价最好的工作了,但说到底也不过只是个汇报会,只是增加了一条项目经理和高层领导的扁平沟通的渠道而已。

  4)项目财务数据相关的工作

  执行情况:主要包括年初项目预算的审核、年中调整、年底结算等。

  结果:这些工作繁琐异常,而且很容易出错,说是审核,其实也就是帮着看看是不是有什么不合要求的地方,至于项目的预算是多少,根本就不关PMO的事,都是各个事业部自己决定的,PMO做的工作只是看看项目提交的表格是否合规,然后做一下统计而已。

  5)试用项目管理工具

  执行情况:开始时主持这个工具试用的会议,出于好奇也是工作需要,曾经试用过这个工具,虽说功能超级强大,可实在是不适用,也曾经私底下问过试用的项目经理,觉得这个工具怎么样,得到的结果也差不多,但是因为PMO在主推,并且提供了一个人的技术支持,项目经理在汇报的时候也总是拣好听的说,蒙蒙领导们自然也不成问题,从领导的角度来看,自然是形势一片大好。

  结果:该工具得到推广,从PMO部门的角度看是政绩,从领导们的角度看是找到了一个好工具,但从项目组和项目经理的角度来看,真的不太清楚他们得到了什么,而且技术支持人员因为看不到发展前景在一年半后辞职,工具的推广也因此大受影响。

  6)新考核方法

  执行情况:经过很长时间的资料收集,PMO部门开发出了一套复杂的考核办法。对被考核的部门来说,用什么考核办法自然都不在乎,只要考核的结果能给大家发的工资比现在高就好。

  结果:因为考核办法太过复杂,数据的收集、核对和计算都非常繁琐且易错,该方法只在一个小部门中实行了两个季度就废止了,此后再也没有人提起过该方法。而且在此后很长一段时间内,都没人敢向高层领导提改革考核方法的事。

  7)度量数据收集分析

  执行情况:领导说,度量是我们必须做的事情,但是没人知道该怎么做,可是又不能不做,于是把现有的bug统计统计,工时统计统计,也就算是成绩了。

  结果:这样的度量,结果是出来了,可是没人用,也没人拿着度量的结果去解决什么问题,这份功夫算是白费了。

  这个阶段,做了很多事情,可是整体的感觉是,拿了个破铁非得说是金刚钻,瓷器活儿是拦回来了,可根本做不了。绝大多数的工作要么似是而非,要么白费力气,当然,年底的汇报上还是可以说的很精彩的,但是对领导来说,问题是不是还在,哪儿疼哪儿痒的毛病是不是给治好了确是清清楚楚的。于是将QA组长明升暗降,给了个副总经理的头衔,分了点工作,又重新找了个人负责PMO的工作,下一篇文章会讲一讲第二任PMO部门领导的故事。

  8)规章制度的制定和发布管理

  执行情况:尽可能的编制规章制度,作为政绩工程来抓。

  结果:因为PMO部门几乎所有人都没什么经验,制定出来的规章制度自然也都是边边角角的东西,而且公司本来就有很完善的规章制度了,且不能轻易废止已有的内容,这部分工作的成果自然是可想而知了。

  9)现有规章制度梳理

  执行情况:规章制度的编制情况不乐观,可是关于规章制度又必须得出点政绩,于是领导想到了去梳理已有的规章制度。

  结果:PMO内没人能驾驭得了整个公司的规章制度体系,自然也就是把现有的拿出来,看看哪些很久没用了,按照时间列出来,就算梳理完成,这样的梳理,自然也起不到什么作用,顶多只能算是规章制度梳理的前奏而已。

posted by 牛草草
阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志

发表评论:

    昵称:
    密码:
    主页:
    标题: