企业中PMO运作失败的经验教训总结，为什么失败？
（一）PMO运营的失败经历
故事发生在三年前的一个自动化公司中，公司发展正当上升期，正在准备集团化，且已经建立了新的园区，准备搬过去。虽然外部看着热热闹闹的，但是家家有本难念的经，公司内部各种矛盾和问题也发展的热热闹闹的，为了解决这些问题，成立了PMO部门。最开始组建PMO的时候，设想的是招聘几个有经验的人，来解决公司面临的问题。实际也曾经招过几个，但没有一个待到试用期结束，离开的理由也各式各样，但结果是都离开了。
当时带队的是一位有10年的工作经验(2年的外包开发、5年的公司内网开发及维护，主要是单兵作战、3年的QA经验)，在公司已经工作了8年的员工，参加过两次PMP考试，但没通过。当时的职位是QA组长，具体工作如何不太清楚，只知道在领导面前很会表现，是那种可以把6分才能表现成10分的人。 这么几来几去一耽误，一年时间就过去了，在这一年的时间里具体都做了些什么事，成果如何都不太清楚，只是在我进入该公司的时候，没见过任何走了的这些人遗留下来的工作或者做的组织资产沉淀。所有人都走了之后，我进入了这个部门。开始时，做的工作主要有四部分：
1)组织一个软件的试用情况例会：
因为我是新来的，且之前从来没用过这个软件，所以基本上听不明白他们在讨论的是什么问题，也不太清楚使用这个工具的远景和近景如何，投入产出比如何。
2)收集项目执行过程中的财务数据并进行分析，出月报：
这个工作主要是每个月从财务部把各个项目的支出要来，与项目立项时的每月支出计划相比较，看看是多花了还是少花了，说是分析，也不过是把多花还是少花了明示出来而已。
3)有规章制度要发布的时候，帮别人跑跑签字等：
这个工作就更简单了，就是别人想发布什么规章制度(在该公司，只要经过了评审和审核，任何人都可以发起规章制度的发布活动)的时候，帮人家看看有什么不合适的地方，然后帮着跑跑腿，找相关领导签签字什么的。
4)为公司的内网开发一些小的功能模块：
说实话，我实在没弄明白为什么这部分工作会在刚刚成立的PMO部门中存在，公司有专门的信息服务部，就是内网的维护和开发工作，到现在我也没弄明白这部分工作是为什么做的，可能跟此时带队的人之前的工作经历有关吧。
这四件事情，只是文秘性质的工作，没什么好坏之分，也没有什么特别的影响力，当然也没解决什么关键的问题。
之后，也就是在我试用期过后，又过了一个多月的时间，部门的领导说要发展一下，招了三个刚毕业的学生，交给我带，同时，有一个事业部的领导也受不了内部矛盾的折磨，希望跟我们合作，帮他们解决问题。于是我将手头的所有工作都交给了新来的毕业生，自己去帮事业部的忙，同时做另外一些事情。接下来我会详细讲解这一阶段所做的事情及其结果。
有了新鲜血液的加入，虽然只是初入职场的新人，但仍值得高兴一把，将部门的很多工作都重新做了规划。下面是我们做的主要的几件事情和取得的成果：
1)要求公司所有研发项目提交项目周报
执行情况：制定了项目周报模板，并进行了数次改版，给各事业部项目经理进行了宣贯，PMO部门每周收集项目经理的周报，进行统计(包括是否提交，提交上来的周报是否符合要求等)，并将统计结果发送给各事业部的领导及。
结果：除了给各项目经理增加了每周提交周报这一工作之外，似乎没解决什么实际问题。也没听说哪个事业部的领导根据周报中得到的信息做了什么工作，也没见过哪个项目经理通过周报反应什么问题。
2)开发项目管理信息系统 执行情况：由PMO部门的员工提需求，开发部门新招了4个刚毕业的学生开发。 结果：提需求的人和开发的人都不是熟悉公司项目或者项目管理专业的人，信息系统的开发自然也是一波三折，直到一年以后，还没听说有什么可用的功能拿出来使用。
3)召开研发项目汇报会 执行情况：每季度召开一次研发项目的汇报会，会议的主要内容是每个项目经理向公司领导(包括总经理和董事长)汇报自己项目的情况，遇到过哪些问题，是如何处理的，有哪些可供别人借鉴的东西。 结果：这算是PMO发起的工作中，评价最好的工作了，但说到底也不过只是个汇报会，只是增加了一条项目经理和高层领导的扁平沟通的渠道而已。
4)项目财务数据相关的工作 执行情况：主要包括年初项目预算的审核、年中调整、年底结算等。 结果：这些工作繁琐异常，而且很容易出错，说是审核，其实也就是帮着看看是不是有什么不合要求的地方，至于项目的预算是多少，根本就不关PMO的事，都是各个事业部自己决定的，PMO做的工作只是看看项目提交的表格是否合规，然后做一下统计而已。
5)新考核方法 执行情况：经过很长时间的资料收集，PMO部门开发出了一套复杂的考核办法。对被考核的部门来说，用什么考核办法自然都不在乎，只要考核的结果能给大家发的工资比现在高就好。 结果：因为考核办法太过复杂，数据的收集、核对和计算都非常繁琐且易错，该方法只在一个小部门中实行了两个季度就废止了，此后再也没有人提起过该方法。而且在此后很长一段时间内，都没人敢向高层领导提改革考核方法的事。
6)度量数据收集分析 执行情况：领导说，度量是我们必须做的事情，但是没人知道该怎么做，可是又不能不做，于是把现有的bug统计统计，工时统计统计，也就算是成绩了。
结果：这样的度量，结果是出来了，可是没人用，也没人拿着度量的结果去解决什么问题，这份功夫算是白费了。 这个阶段，做了很多事情，可是整体的感觉是，拿了个破铁非得说是金刚钻，瓷器活儿是拦回来了，可根本做不了。绝大多数的工作要么似是而非，要么白费力气，当然，年底的汇报上还是可以说的很精彩的，但是对领导来说，问题是不是还在，哪儿疼哪儿痒的毛病是不是给治好了确是清清楚楚的。于是将QA组长明升暗降，给了个副总经理的头衔，分了点工作，又重新找了个人负责PMO的工作，下一篇文章会讲一讲第二任PMO部门领导的故事。
7)规章制度的制定和发布管理 执行情况：尽可能的编制规章制度，作为政绩工程来抓。
结果：因为PMO部门几乎所有人都没什么经验，制定出来的规章制度自然也都是边边角角的东西，而且公司本来就有很完善的规章制度了，且不能轻易废止已有的内容，这部分工作的成果自然是可想而知了。
8)现有规章制度梳理 执行情况：规章制度的编制情况不乐观，可是关于规章制度又必须得出点政绩，于是领导想到了去梳理已有的规章制度。 结果：PMO内没人能驾驭得了整个公司的规章制度体系，自然也就是把现有的拿出来，看看哪些很久没用了，按照时间列出来，就算梳理完成，这样的梳理，自然也起不到什么作用，顶多只能算是规章制度梳理的前奏而已。
9)试用项目管理工具 执行情况：开始时主持这个工具试用的会议，出于好奇也是工作需要，曾经试用过这个工具，虽说功能超级强大，可实在是不适用，也曾经私底下问过试用的项目经理，觉得这个工具怎么样，得到的结果也差不多，但是因为PMO在主推，并且提供了一个人的技术支持，项目经理在汇报的时候也总是拣好听的说，蒙蒙领导们自然也不成问题，从领导的角度来看，自然是形势一片大好。
结果：该工具得到推广，从PMO部门的角度看是政绩，从领导们的角度看是找到了一个好工具，但从项目组和项目经理的角度来看，真的不太清楚他们得到了什么，而且技术支持人员因为看不到发展前景在一年半后辞职，工具的推广也因此大受影响。
（二）为何许多组织的PMO会失败？
我最常被企业客户与学生问到〝我们公司已有好几位PMP®了（或已有许多同仁上过项目管理的课程），有了这样的人力资源，算不算具备「成立PMO」的基本条件？〞当然，要成立PMO一定要有一些1.「称职的」、2. 「具有实务经验」与3. 「受过专业训练」的项目管理专业人才；然就算有了后两者的条件，那也只是可解决前面所说的「技术层面」的问题；而「称不称职」则是能不能解决策略性与政治性的问题。周博士在上周「顾问答客录」中列出了成立PMO看似简单的14个步骤，但里面充满了不少策略性与政治性的议题，可能就不是组织内层级不够高的一般PMP®所能handle的；而就算由高层强制推动，若无法凝聚共识与说服各主要Stakeholder 有关PMO的价值，则它的发展也难以成功。我就以下两个实例来说明。
实例二：某家游戏软件公司将十余位平均年龄不到30岁、充满企图心又工作认真的工程师送去接受项目管理的培训，其中一位刚取得PMP®的资浅经理为了实践其对项目管理学习的心得与抱负，结合了其他几位热情亦有理想的年轻PMP®向公司COO建议应该成立一个PMO来为公司建立项目管理的制度并「控管」公司各大小项目使其能顺利达成目标。COO赞同了他们的想法并要求他们成立项目小组来提出具体计划与构想。在经过一个月的资料搜集、研究、讨论与构思的努力后，项目小组发现「成立PMO」不是他们想象中根据PMBOK® Guide中的知识体来发展制度、流程即可，最重要的是他们发觉对于组织功能的定位、各相关文件与模板的设计与PMO操作执行的细节都不是以他们的经验与能力所能发展出来的。最后，在公司无法提供他们额外的预算以聘请外部顾问及得不到公司同仁普遍支持的情况下，该PMO项目只有无疾而终。
实例三：某知名上市的信息公司，在2006年时由当时的总经理(GM)拔擢了一位对项目管理相当有实务经验的资深工程师担任「研发长（CTO）」，该CTO也不负GM的期望，确实把该部门的项目管理制度建立的很好（包括他自己亲自为同仁上项目管理课程，以建立共同语言与理念），GM于是在2007年底指派该CTO负责成立PMO以全面推动全公司项目管理制度。虽然该PMO所规划执行的许多规定遭受到其他所有部门的反弹与不满，但在GM的坚持下，全公司员工均被「强制要求」地全面遵守（例如：每人的每周工时表【Timesheet】必须在周五下午四时前透过PMIS提送，否则系统会不断自动催缴，且若不遵守会影响其考核成绩）。2008年的金融海啸等其他相关因素重挫该公司的股价且整个公司营收锐减，使2009年初该GM被迫请辞；接任的GM在2009年底应董事会的要求撤换了达不到业绩标准的一级主管（该CTO亦赫然在名单中），并同时废除了接任PM认为是「功能不彰、迭床架屋」的PMO。
实例二是典型的「小孩玩大车」，虽年轻的PM们的胆识、憧憬、理想与热情是值得肯定的，但是他们太天真、太过度自信了（因为拿到PMP®，不代表就可立刻上场去「冲锋陷阵」），而成立PMO的关键条件中，「项目管理知识」只是其一，若缺乏real world 的实战经验，与处理政治性议题与Stakeholder期望的「智慧」，就会成为「误入丛林的小白兔」。实例三最吊诡的是连GM都站在第一线为何还会失败？其实道理很简单──「一个缺乏全面共识的『强制』制度，就算有领导者坚强的意识力，在它没有变成公司文化的一部份之前，任何改革都很难经得起时间的考验」，尤其是该GM与CTO没有让董事会与各部门看到PMO的真正价值与意义。
本文列举出的三个实际案例虽然都是负面的，但并非是要读者悲观地看待PMO，而只是根据我的经验提醒大家如何避免在PMO的发展过程掉入陷阱或跌到万劫不复的深渊。我在PMO的课堂上会告诉学员「如何确保PMO能顺利运作的几项重要准则」，并透过研讨与演练来加深学习印象。其次，除参加专为PMO设计的研习营外，邀请外部专业顾问以Coaching, Mentoring, Consulting方式来一步一步指导企业PMO的发展，成效通常会更高（最起码，根据我们的经验与敏锐的判断，会告诉业主以您企业的现况、条件与氛围要成立某种型式的PMO会不会成功，以及如何才可能成功）。
（三）PMO的失败之旅-QA组长带队1
讲一个发生在我任职的上一家公司的关于PMO的故事。
故事发生在三年前的一个自动化公司中，公司发展正当上升期，正在准备集团化，且已经建立了新的园区，准备搬过去。虽然外部看着热热闹闹的，但是家家有本难念的经，公司内部各种矛盾和问题也发展的热热闹闹的，为了解决这些问题，成立了PMO部门。
此时带队的是一位有10年的工作经验（2年的外包开发、5年的公司内网开发及维护，主要是单兵作战、3年的QA经验），在公司已经工作了8年的员工，参加过两次PMP考试，但没通过。当时的职位是QA组长，具体工作如何不太清楚，只知道在领导面前很会表现，是那种可以把6分才能表现成10分的人。
最开始组建PMO的时候，设想的是招聘几个有经验的人，来解决公司面临的问题。实际也曾经招过几个，但没有一个待到试用期结束，离开的理由也各式各样，但结果是都离开了。这么几来几去一耽误，一年时间就过去了，在这一年的时间里具体都做了些什么事，成果如何都不太清楚，只是在我进入该公司的时候，没见过任何走了的这些人遗留下来的工作或者做的组织资产沉淀。
所有人都走了之后，我进入了这个部门。开始时，做的工作主要有三部分：
1）组织一个软件的试用情况例会：
因为我是新来的，且之前从来没用过这个软件，所以基本上听不明白他们在讨论的是什么问题，也不太清楚使用这个工具的远景和近景如何，投入产出比如何。
2）收集项目执行过程中的财务数据并进行分析，出月报：
这个工作主要是每个月从财务部把各个项目的支出要来，与项目立项时的每月支出计划相比较，看看是多花了还是少花了，说是分析，也不过是把多花还是少花了明示出来而已。
3）有规章制度要发布的时候，帮别人跑跑签字等：
这个工作就更简单了，就是别人想发布什么规章制度（在该公司，只要经过了评审和审核，任何人都可以发起规章制度的发布活动）的时候，帮人家看看有什么不合适的地方，然后帮着跑跑腿，找相关领导签签字什么的。
4）为公司的内网开发一些小的功能模块：
说实话，我实在没弄明白为什么这部分工作会在刚刚成立的PMO部门中存在，公司有专门的信息服务部，就是内网的维护和开发工作，到现在我也没弄明白这部分工作是为什么做的，可能跟此时带队的人之前的工作经历有关吧。
这三件事情，只是文秘性质的工作，没什么好坏之分，也没有什么特别的影响力，当然也没解决什么关键的问题。
之后，也就是在我试用期过后，又过了一个多月的时间，部门的领导说要发展一下，招了三个刚毕业的学生，交给我带，同时，有一个事业部的领导也受不了内部矛盾的折磨，希望跟我们合作，帮他们解决问题。于是我将手头的所有工作都交给了新来的毕业生，自己去帮事业部的忙，同时做另外一些事情。接下来我会详细讲解这一阶段所做的事情及其结果。