项目管理实例（1） － 不一样的PMO

所在公司是一家软件公司，主要为电子行业、航空航天等军工企业提供信息化产品和服务。老板受他本人在制造业工作经历的影响，把一个软件公司的组织结构设置得如同工厂，几乎每项工作都是一个部门只承担一部分，不允许参与其他工作。比如售前阶段，工作说明书是咨询部负责完成，合同签订后，转到实施部，实施部的项目经理和业务顾问到客户那里进行业务调研工作，编写出业务调研报告和业务需求说明书，通过评审后才能继续传递文档至下游，下游是设计部，负责需求分析和概要设计，再下面是开发部，负责详细设计和编码.。。。。。。老板想得挺好，可是最大的问题很快就来了，软件过程中的文档很难标准化，评审难有标准。而各个环节都希望上游的产出物一定要满足下游的输入要求才行，否则下游的部门就不接！，因此，设计部埋怨项目经理和业务顾问写的业务需求不够详细，不够准确，没法做需求分析，评审一次次通过不了，同样道理，开发部门死活不认可设计部的架构师写的需求规格和概设，认为不能指导详细设计和编码工作，而架构师又认为他们只负责需求分析和概要设计，开发部要求的那些事都应当开发人员自己完成。。。。。。项目经理除了自己要写业务需求外，整天都在协调、协调，下游环节的部门不接受上游部门的产出物，项目经理也难以判断该不该传到到下一棒，需要协调的事情特别多。何况他们的文档也常常被别人狂批，似乎自己也没协调的资格。

公司前几年合同项目不多，主要精力放在做产品上，但即使是产品开发，产品经理的业务定义同样也很难往下传递。

一个项目组由各个部门的人组成，无论是产品经理，还是项目经理每推动一步都很费劲，各个部门扯皮的现象层出不穷。就是在这种情况下，老板设想成立一个公司级的综合管理部门，将公司主要的骨干，如项目经理和产品经理集中到1个部门，进行总协调和总负责。这个部门被赋予了相当大的权利，因为老板希望找一个“强势”的人能好好替他“管一管”。本人就是在这样的背景下走马上任的。我的部门被设置为PMO，与一般公司的 PMO不同，我直接领导项目经理，而且无论何人，不管是哪一个部门，什么职位，只要担任项目经理，就都归我领导。项目经理管理和考核着不属于同一个部门的的组员，即使组员是其他部门经理，甚至是技术副总监，也仍然归项目经理领导和考核。因此，本人是一个名副其实的PMO (Officer的O,不是office的O) ，管理和掌控公司所有的项目和产品，

其实不光是我们老板，业界推行CMMI，很多公司都梦想搞“软件工厂、软件蓝领、流水作业。。。。。。从上世纪90年代年开始，我呆过的、咨询过的、售前接触过的软件企业应该不算少了，还没见哪家企业能真正做到将软件开发过程搞得跟生产制造过程一样呢！但我所在的公司就是这样一个组织结构和管理方式，这样的管理方式带来了无数的质疑和争论，可是我们现在谁都无力从更高的层面去说服老板，因为谁也不敢说换一种管理方式就一定会比现在好，因为这种方式虽说协调的事情多一些，效率低下一些，但是却保证了一个项目由多人参与才能完成，因此某个人离开对项目的影响不会太大。到底怎样才更好，也许时间可以证明一切吧。

一年半过去了，最多的时候公司同时做着近20个项目，都是百万级的纯软件项目。真把我累坏了，涌现出了各种各样的问题，有失败的教训，更多的还是成功的经验。有些项目经理是我新招的，有的是公司老员工，随着一个一个问题的解决，项目经理们乃至我本人都提升了很多很多。。。。。。更多的结论只能从实践中产生，而不应去主观推断。下一篇首先谈谈“选拔项目经理的体会”