今天一朋友忿忿不平地跑来跟我吐槽。说去面试一家公司的PMO经理职位，副总说这个部门除了平时统计工时，周报，还负责报销及行政相关事宜。同时副总还表示，PMO部门对公司来说不是非要不可的部门，只是名义上需要这个部门。对公司来说，业务部门才是最重要的！接下去的事不说也罢，总之我这朋友憋屈死了。
其实说来说去，业务部门直接产生盈利，老板看到了他的价值，所以就觉得重要。而对许多不了解PMO职能的人来说，PMO就是个打杂的，收集下数据，用用Excel, Word, PPT！像朋友提到的这家面试公司，是国企与外企合资的一家子公司，又想有外企的架构，但不了解PMO的职能，于是PMO也就成了公司的鸡肋部门。
朋友的心情我很理解，人在职场，谁不想做得风声水起呢？但不可否认，PMO的尴尬确实存在于国内的许多公司。对于迷茫的小伙伴们，我也有几点建议：
1、自己要知道PMO的职能
PMO：Project Manage Office (项目管理办公室)是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织部门。
在不同的公司，PMO所处的位置不一样，权利也不一样。对项目的控制程度从低到高分别为：
支持型：支持型PMO担当顾问的角色，向项目提供模板，最佳实践，培训，以及来自其他项目的信息和经验教训。这种类型的PMO其实就是一个项目资源库。
控制型：控制型PMO不仅给项目提供支持，而且通过各种手段要求项目服从。
指令型：指令型PMO直接管理和控制项目。
——PMBOK
也许对于PMO的误解来自于支持型的定义吧，收集数据，整理文档，看上去就像办公室文员的工作。如果我们自己不看清形式，甘于做这些机械重复，但又产生不了价值的工作，那我们的工作内容只会越来越偏离项目管理，成为一个PM"O"。
2、找准自己的定位
首先不要灰心，PMO都是从支持型做起来的！其次要目标清晰，相信只要做得好，让老板看到部门为公司创造价值，自然会越来越有影响力。即以支持型做为起点，从服务项目的身份慢慢转变为领导项目的身份，即成为一名真正的"PM"O。
3、从解决问题的角度出发，努力办实事
这句话有两层含义：1，办实事，而不是走形式。2，事情不分大小，只要对项目组有帮助都可以去做。
从各种资料可以看到，PMO的工作范畴也挺多，如：编制各种制度和规范流程，普及项目管理知识体系，培训，资源协调和规划等等。建议PMO们多了解公司内部的组织环境，平时多跟项目组接触，了解项目组所急所需，有针对性的提出解决方案。而不是胡子眉毛一把抓，不仅增加了自己和项目组的工作量，还收效甚微。
失败案例：
早期我做项目经理时，总公司PMO推出了个项目管理系统超级难用，每周要在上面艰难的调着项目计划，工时，任务分配情况等。对项目组来说，即增加了工作量，在填写工时，完成任务数据时也不完全真实。从公司角度来说，也没看用这个数据做了什么决策。总之，感觉这件事情最后也只是一种形式了。
成功案例1：
早期做项目时，我还不知道怎么做需求变更控制。甲方经常口头提出需求变更，那时就比谁的嘴皮厉害。当场能回掉的就回掉了，不能回掉的也只能做了。后来一次偶然机会，跟PMO的同事聊过这个困惑，PMO同事给梳理了需求变更控制流程，还给了规范的需求变更申请表格。如此一来，自然拒掉了一批一线使用人员的需求变更。也算是给项目组人员缓解了一些压力。当然，后续PMO也给公司组织了多场项目管理培训，增强项目经理的业务能力。
成功案例2：
以前组织过程资产管理做得不好：公司一年能做好几个项目，不是所有的项目都被做成了虚拟机，而且有些虚拟机的开机密码随着人员的流失也遗失了，这造成每次公司内部需要使用历史资料都耗费比较多的精力。后来PMO与项目组合作，把能收集的虚拟机都备份好，密码一一对应的记录下来。没有虚拟机的，也尽量制作。然后把所有虚拟机都存盘好，方便项目组或市场部随时使用。这个看似繁琐的工作，却解决了公司长久以来的一个难题。
总之，无论哪个部门，只要能解决公司内部的痛点，就能体现他的价值。有些部门是开源得来的价值，有些部门是节流取得的价值。无论怎样，只要保证自己的价值，相信PMO就不再是鸡肋。
本文首发上海欣旋公众号
