To B项目中，被严重低估的PMO
想象一下，你打算开着一辆普通的车穿越一片沼泽地。这时候天色突变、暴雨如注，没过多久，车子熄火了，你陷入了泥沼中。
持续震荡的互联网市场中，企业所面临的市场状况不断在变化。几年前传统广播电视还占据主导地位，现在市场份额已下滑到38%；就在一年前，苹果在中国高端智能手机领域的市场份额高达82%，最近一个季度的数据显示，华为市场份额达到48%，超过苹果的37%。
簇新的状况纷至沓来，若没有一个统一的平台对前线项目的需求和变更加以管理和支持，不能迅速分配资源，作出有效地响应和决策，那么很快就会陷入被竞争对手K.O.的局面中。
做To B项目，更是如此。
从销售经理、客户经理再到项目经理，从售前支持、售中交付再到售后服务，每个阶段里的每个环节都面临着计划变更和资源冲突的风险，每一个新项目过来似乎都像是初次谋面熟悉又陌生，不同项目之间没有一个跨组织的团队去拉通内部资源。
于是有人提倡，引入PMO吧！
PMO不是一个新概念，早在20世纪90年代初期就诞生了。彼时PMO仅用来管理和监督项目经理，并不承担实质性的指导工作。随着商业环境的震荡，企业分工的细化，跨组织的项目带来的资源冲突越来越多，企业意识到将项目放到整个企业的背景下来统一管理变得越来越重要。
然而即便如此，在很多互联网公司里，几乎都没有设置PMO这样的组织节点。且不说这些人是否有正式名份，全职做PMO的人也是少数。要么是项目经理兼任，要么是产品经理承担。
本来这也没什么，可是做to B服务的项目，项目资源少，周期长，变更多，项目经理忙得焦头烂额，但身后空落落的，没有一个背靠背的坚定支持者，为项目经理提供必需的支持。一旦项目多起来，前线的项目经理扛不住了，就只能径直拉上后方的产品团队上去灭火，炸弹包手榴弹医药箱能上一个是一个……场面越来越失控，大家都很惨。
一、PMO的生存之道
在谈项目管理办公室之前，我想先从项目谈起。
什么是项目？
PMP里对项目的标准定义如下：
与日常持续开展的工作不同，项目要有明确的目标、起止时间和有限的人力资源。
正因为项目的目标是明确的，而时间和资源又是有限的，因此项目需要有人来管理。
而项目管理是什么？
项目管理比较偏向于对单个项目的管理，一般会由项目经理来实现。
那么，相比项目经理，项目管理办公室是在企业或组织里管理所有项目的委员会，可以是一个团队，或是一些人来承担，主要负责在组织内定义和维护项目管理相关的标准。
有些企业的PMO更像是老板的第三只眼，统一追踪和收集所有项目的信息，定期汇报工作，像秘书，又像助手。PMO不对项目具体的进展和问题负责，只负责归档、审批、监控，流于表面，难以渗透到项目底层。
这活干起来没毛病，就是琐碎，没成就感。慢慢的，PMO对工作产生抵触……有抵触情绪的又何止是PMO？项目经理也会对PMO有抵触，认为其不懂业务流程和项目交付，只会纸上谈兵，无法真正为项目提供一些实质性的帮助；老板也会对PMO有质疑，一味的事务性工作，只是消耗成本的管理部门，不能创造一分效益。
于是，PMO人员流失，老板不重视，项目经理不配合，最终人去楼空。
这是谁的错？
PMO作为一个跨组织项目资源的统一调度者，需要和多方项目经理打交道。而这个组织的人员配比又比较少，好比一只鸟要领着一群牛往前走，若没有老板作为PMO坚实的后盾，那么这只鸟也就无足轻重。
如果你只是依仗老板的支持而没有实际效益和价值的输出，那么你也是无法服众的。
最后是其他团队对PMO的配合
如果把一个项目中的所有干系人比作一只只游离的鱼，那么PMO就是一张网，它要套捕所有游经它的鱼。对应到项目里，PMO是各项目信息汇集的枢纽。
众人拾柴火焰高，项目经理是得到PMO支持的第一受益者，自然需要保持积极的沟通，确保信息和问题透明；除此之外，产品研发团队、部署运维团队，在项目开展的全程中不定期地会接收到PMO的需求和调度，配合PMO以支持前线项目显得尤为重要；运营推广团队，则需要配合PMO获取客户运营数据，以便从数据中发现问题并提出解决办法。
二、PMO之路不平坦
前文提到的生存之道，我都陆续体验过一遭。从最开始由领导非官方授权的PMO职位，到现在依然没有正式名份的我，仍旧是挂着产品经理的title，左手策划产品、右手开搞产品商业化，中心大脑是项目交付支持。
庆幸的是，在这个过程中，我逐渐找到了自己的定位。
上图是一张简单的示意。不难看出，PMO在保障项目的过程中最重要的是借力打力，拉通客户、分包商和内部合作团队的资源。每个项目都有自己的特殊性，每位项目经理也都会有自己的脾性，PMO需要制定统一的项目运作规则，去规范项目过程，包括立项、交付、考核、奖惩、沟通、评审等制度。
位置找准了，我们再来看下PMO的工作框架。
下图的工作框架是我从日常的工作中提炼出来的，基于PMO的工作价值去整合资源，制定策略以推进项目平稳运行。
那么，在具体的项目交付过程中，PMO需要持续盘点所有项目所处的销售阶段和交付阶段，在每个关键环节上构建服务地图，提供项目支持，为项目保驾护航。这点我在前文有详细的展开To B路上，除了客户导向，还要服务管理，在此不加赘述。
3、修炼心法
我和其他几位PMO聊过，做这类工作时特别容易陷入一种情况：机械化的工作还在持续进行，理智告诉我这不是长久之计，情感上却还迟迟不愿割舍，俨然是“僵尸状态”。这种情况不止发生在PMO身上，在很多职场人身上都会出现这个问题。
怎么办？
跳出舒适圈吧，不要沉溺于“简单的快乐”之中。你仔细观察，绝大多数事都可以通过定义统一规范标准化沉淀下来，交由其他人、其他工具来实现。你要把精力聚焦于踮起脚尖够到的部分，去挑战下实际执行过程中的障碍，找到真正能让你觉得有成就感的内容。
当然，这不是说常规任务是无用的，它对集体而言自然是有价值的（否则改工作存在的必要性值得推敲），但对个人的能力提升帮助不大。所有这类工作都可以试着归纳演绎，沉淀到知识库里，通过标准的服务体系来约束干系人，通过标准的资料库来反馈给干系人。
虽说如此，在实际开展工作的时候总会遇到各种糟心事儿，琐碎有余，力量不足。但当我辗转于多个业务后，负责过几乎所有KA项目的管理与支持之后，对于客户业务的理解和项目管理支持的标准化沉淀，摞成一叠叠厚实的资料，再看到其他项目将其视为样板间去复制的时候，给我带来的成就感是不可比拟的。
其次是决策思维。
我们常把决策看作一个大方向、大策略。当然，方向、策略都是必须的，但其实决策就是一组具有长远影响的决定，是一系列的资源分配。
决策的过程就是选择最好的方案，以有限的资源来达到目标。划重点：
那么对照到项目的概念，项目要有明确的目标、起止时间和有限的人力资源。决策的过程本身就是一个项目，而作为项目管理办公室，你要做的就是持续提升决策思维，以支持项目经理们更好地在实际项目中作出决策。
如何培养决策思维呢？
IBM全球企业咨询服务部曾经邀请王嘉陵女士分享过关于提升决策思维的方法，她在《决策思维》一书里提出：
1）决策内容高质量GPA
可选方案（Alternatives）
2）决策过程高质量IPO
客观推理（Objective Reasoning）
秉承GPA和IPO原则，在深入项目和项目经理沟通前，心里要先摆一张谱，随时自我评估：
优先级、轻重缓急清楚吗？是不是保住了底线？是不是把资源最先投放到最重要的事？
可选方案够多吗？还有没有？不同方案实施时可能会产生什么后果？
计划开展后是否有定期的进展汇报和风险同步？定期的沟通计划和资源安排好了吗？
最后是对各类刺激的反应要灵活。
为项目保驾护航是PMO的目标，基于这个目标，PMO仅是盯着眼前的项目是远远不够的。比方说，某项目经理反馈，客户在比对友商后对我们方案的报价提出质疑，开始倾向于友商的产品。那么，此时PMO收到了项目经理的反馈，他能做些什么？走个特批降低产品在该项目里的报价，赢得客户的采购意愿？
不对。
首先是尽可能通过项目经理获悉客户选型的标准：除了价格因素，还有什么？如果是产品和服务不尽如人意，那么PMO是否可以通过汇总所有KA项目的需求和问题的反馈，提炼出通用的标准能力，作为下一个产品版本迭代的源素材？
如果客户确实对报价的意见大，那么PMO要做的是做好成本管理和利润测算，锁定服务目录，将资源聚焦于关键业务和客户易感知的系统上，引导客户正向变更需求，在下一期项目中追加投资。项目的三要素是时间、范围和成本，在成本确定后，项目的计划和验收范围也要根据成本来调整，设置客户的配合条件，做好风险转移。
三、任重而道远
老实说，在写这篇文前我试图收集PMO的相关资料，发现网上对PMO的价值颇有微词，不少企业仍是止步于对项目本身的管理，而忽视了项目思维的管理。
现在我们都在提数字中台的概念，不妨试着回想下PMO的职责。一位合格的PMO其实就是跨组织项目中的“中台”，它不会介入业务前台的开发（项目经理对项目的管理），也不会干涉业务后台的实现（产品研发团队对产品的建设）。它洞悉市场策略，制定项目管理和服务管理的规范，它的包容性和弹性是独一无二的。
因为有PMO，所有项目的干系人都可以基于共同的架构，用共同的语言来讨论我们眼前的态势。
这是PMO的愿景，也是我们努力的方向。
