PMO的工作内容总结起来有两大部分：首先是项目管理体系的建立和持续改进;其次则是日常项目的跟踪、监控、管理。对于新建立的PMO来说，不一定一步到位，一定要在深入了解公司情况的基础上逐步开展工作，为PMO真正发挥作用奠定一个好的基础。
1)要求公司所有研发项目提交项目周报
执行情况：制定了项目周报模板，并进行了数次改版，给各事业部项目经理进行了宣贯，PMO部门每周收集项目经理的周报，进行统计(包括是否提交，提交上来的周报是否符合要求等)，并将统计结果发送给各事业部的领导及。
结果：除了给各项目经理增加了每周提交周报这一工作之外，似乎没解决什么实际问题。也没听说哪个事业部的领导根据周报中得到的信息做了什么工作，也没见过哪个项目经理通过周报反应什么问题。
2)开发项目管理信息系统
执行情况：由PMO部门的员工提需求，开发部门新招了4个刚毕业的学生开发。
结果：提需求的人和开发的人都不是熟悉公司项目或者项目管理专业的人，信息系统的开发自然也是一波三折，直到一年以后，还没听说有什么可用的功能拿出来使用。
3)召开研发项目汇报会
执行情况：每季度召开一次研发项目的汇报会，会议的主要内容是每个项目经理向公司领导(包括总经理和董事长)汇报自己项目的情况，遇到过哪些问题，是如何处理的，有哪些可供别人借鉴的东西。
结果：这算是PMO发起的工作中，评价最好的工作了，但说到底也不过只是个汇报会，只是增加了一条项目经理和高层领导的扁平沟通的渠道而已。
4)项目财务数据相关的工作
执行情况：主要包括年初项目预算的审核、年中调整、年底结算等。
结果：这些工作繁琐异常，而且很容易出错，说是审核，其实也就是帮着看看是不是有什么不合要求的地方，至于项目的预算是多少，根本就不关PMO的事，都是各个事业部自己决定的，PMO做的工作只是看看项目提交的表格是否合规，然后做一下统计而已。
5)试用项目管理工具
执行情况：开始时主持这个工具试用的会议，出于好奇也是工作需要，曾经试用过这个工具，虽说功能超级强大，可实在是不适用，也曾经私底下问过试用的项目经理，觉得这个工具怎么样，得到的结果也差不多，但是因为PMO在主推，并且提供了一个人的技术支持，项目经理在汇报的时候也总是拣好听的说，蒙蒙领导们自然也不成问题，从领导的角度来看，自然是形势一片大好。
结果：该工具得到推广，从PMO部门的角度看是政绩，从领导们的角度看是找到了一个好工具，但从项目组和项目经理的角度来看，真的不太清楚他们得到了什么，而且技术支持人员因为看不到发展前景在一年半后辞职，工具的推广也因此大受影响。
6)新考核方法
执行情况：经过很长时间的资料收集，PMO部门开发出了一套复杂的考核办法。对被考核的部门来说，用什么考核办法自然都不在乎，只要考核的结果能给大家发的工资比现在高就好。
结果：因为考核办法太过复杂，数据的收集、核对和计算都非常繁琐且易错，该方法只在一个小部门中实行了两个季度就废止了，此后再也没有人提起过该方法。而且在此后很长一段时间内，都没人敢向高层领导提改革考核方法的事。
7)现有规章制度梳理
执行情况：规章制度的编制情况不乐观，可是关于规章制度又必须得出点政绩，于是领导想到了去梳理已有的规章制度。
结果：PMO内没人能驾驭得了整个公司的规章制度体系，自然也就是把现有的拿出来，看看哪些很久没用了，按照时间列出来，就算梳理完成，这样的梳理，自然也起不到什么作用，顶多只能算是规章制度梳理的前奏而已。
8) 规章制度的制定和发布管理
执行情况：尽可能的编制规章制度，作为政绩工程来抓。
结果：因为PMO部门几乎所有人都没什么经验，制定出来的规章制度自然也都是边边角角的东西，而且公司本来就有很完善的规章制度了，且不能轻易废止已有的内容，这部分工作的成果自然是可想而知了。
9)度量数据
执行情况：领导说，度量是我们必须做的事情，但是没人知道该怎么做，可是又不能不做，于是把现有的bug统计统计，工时统计统计，也就算是成绩了。
结果：这样的度量，结果是出来了，可是没人用，也没人拿着度量的结果去解决什么问题，这份功夫算是白费了。