18年_PMO_实践

在18年第一季度末尾，接手PMO工作。目标是建立PMO，支持项目运作。其实这是一个较空泛的目标，具体要做哪些工作，是一项不断摸索的过程。幸而有项目总监直接指导，同时部门拥有多位十几年经验的老司机-项目经理，在18年支持型PMO算是大体成型。工作总结记录如下。

---

现状

首先是现状分析，定位了目前所处的位置，才能找到差距所在，确定接下来的工作。

项目清单

最先应维护的文档，就是项目清单。PMO作为一个运营组织，面向的对象是项目，若有多少项目、项目基本信息都无法掌握，自然也起不到管理的作用。之前所有项目的监督指导，由部门总监（项目总监）一人操盘，18年新增了十几项项目，同时还有已上线系统的运维督导、部门管理工作，难免分身乏术，精力被迫投入到项目的救火当中，无法抽身从全貌、顶层架构、流程设计上，施加影响。同时，各项目之间，缺少关联性统筹兼顾，彼此相对独立，无法发挥项目组合的威力。更严重者，系统是成功上线了，可又是一个信息孤岛，加重了业务人员手工作业量，给后期信息流打通增加了更大的困难。

项目清单结构如下，注意区分项目与任务。项目的定义：“项目是为创造独特的产品，服务或成果而进行的临时性工作”，而一个需协调多方组织配合的任务，也可当做一项目来驱动，这里没法给出统一的判断标准，需做具体分析。但对于任务和项目如何管理的区分是清晰的。任务，只需能保障闭环即可，无论是记录在系统工具或Excel中，定期更新状态，记录结果。

1. Project name
2. Project manager
3. Business area
4. Project level
5. Status
6. Issue/Risk
7. Timeline

18年大大小小项目，共33个，并行运作最多时有二十多个。可分为

1. 公司级大型项目，拥有专职的项目团队、独立办公室，非本部门主导，如PLM一期、CRM一期，都是公司最核心系统。针对此类大型项目，PMO不涵盖项目内部管理，但要求适当的项目分享，及协调与其他项目交叉的资源；

2. 本部门主导、作用于业务部门的项目，有的项目影响同样巨大，如IM替换、邮箱替换项目，皆为公司级作用域。有的是针对特定部门、或领域需求的项目，如非生产类物料采购平台；

3. 本部门主导、不直接满足业务部门需求的项目，信息安全、运维服务相关项目，大多属于此类。运维项目，如容灾，只要满足业务用户要求的RPO、RTO即可，干系人没有任何其他要求，遵循传统的瀑布式方法运作。又如ITIL项目，其实没有这个系统，业务用户不会有意见，一通电话不比系统提单来的过瘾。但为了化被动服务为主动、同时提升SLA，线上处理是必要的转变。系统上线后，所有人都会受到影响，但并没有直接满足业务部门的需求，因为没有解决业务用户的痛点（会提升服务效率，但用户很难觉察到，处理慢催促几次就行了，起码还拥有掌控感）