PMO，即项目管理办公室，是项目型企业中管理和协调项目的机构。我国目前的软件企业，以中小型企业居多，而这些企业中，又以项目型企业居多。这些企业，是最需要提高项目管理水平的，而往往这类型的企业，又是最缺乏项目管理的。
我所说的中小型企业，是指50人以上，300人以下的以软件或系统集成为主业的企业。以我所见的而言，大部分企业的组织结构是以下两种：
第一种，以职能划分，按照职能分为市场部、研发部、技术部等。
第二种，按行业划分，按行业分为政府事业部、电信事业部、电力事业部等。
以我所在的公司为例，我所在公司有员工160人左右，主营业务是系统集成及软件开发，算是典型的系统集成及软件企业。在我刚刚进入公司的时候，公司采取的是第一种组织架构模式，在项目管理上，发现了许多问题，集中表现在以下几方面：
1、无人负责
当市场部发现销售机会后，往往由技术部门派出技术人员协助市场人员与客户交流，参与招标等工作，在这一阶段，项目经理实际是由市场人员担任的，而由于市场人员往往对技术不很精通，有时对技术人员难与沟通和管理，经常为此而丢单。出了问题后，大家互相推，谁也不愿负责任。
合同签订后，市场人员将该项目交给技术人员，又去做下一个项目，在这时，项目经理实际是由技术人员担任的，而客户往往将其看作纯粹的技术人员，很多问题很难与客户交流，当需要市场人员协助解决某些问题时，技术人员由于不产生直接利润，在企业中相对低位较低，市场人员会将责任全部推到技术部门，而技术部门往往心里不服。在软件项目上尤其明显，软件项目工期常常滞后，导致用户不满，而市场人员由于拿下了单子，奖金照拿，技术人员只能把责任扛下来。
2、内部协调困难
某些项目需要几个部门的合作，比如市场部门，软件部门，硬件部门，等。这时，往往是参与这个项目的人谁的职位高，资历深，谁说了算，比如某个项目硬件部门的经理参与了，项目往往是他说了算。市场人员有时想把相关技术人员叫到一起开个会都非常困难。
3、对外混乱
在写方案，提交文档时，没有统一的标准。而客户出了问题，也搞不清楚应该找谁，好像谁都负责，又好像谁都不负责。
公司发现种种问题后，随着业务的扩展，组织机构改为了第二种模式，这种模式下，内部协调相对简单，都是各事业部内部协调。但这种模式下，实际担任项目经理的是市场人员，技术人员低位仍然较低。各个技术人员分散到了各部门，资源难以统一使用，导致整体技术水平下降，当需要从其他事业部调用人员时，简直难于上青天。一般没有总经理亲自出面，是解决不了问题的。
我想，这不但是我们企业中常见的问题，恐怕很多中小企业都有类似的问题，那么，出现问题的核心在哪里呢？
我们再看看以上的的种种问题，就会发现，很多问题是由于项目经理部明确，导致大家集体负责，实际是无人负责造成的。
在早期的大型企业中，如IBM、HP等，也有类似的问题，针对这些问题，这些公司组建了不同级别的PMO，培养了专业的项目经理，由他们负责项目的管理工作。
但在目前的中小企业中，又不可能像IBM、HP那样，招聘一批专业的项目经理，这是很多企业无法承受的，也是短期内不容易解决的。但我想，不一定非要模仿大企业的PMO，可以根据企业的情况，建立不同程度的PMO，逐步解决问题，也可以从简单的PMO做起，逐步向更高层次过渡，先解决简单的问题，再解决深层次、难度较高的问题。
以我所在的公司为例，可以分几个阶段，建立适合企业自身需要的PMO。
第一阶段，提出概念，成立组织。
万事开头难，很多组织结构的改革由于面临着权力的重新分配而困难重重。如果我们一开始就要建立一个全面管理项目的PMO，恐怕会遭到大家的一致反对。而且也没有那么多的合格的项目经理来让大家信服。所以，应该低调开始，提出建立PMO的概念，把PMO建立起来再说。此时的PMO，不干涉任何项目，也不需要增加人员，而使用现有人员兼职。这样，阻力会非常小，那此时的PMO，又有什么用呢？ [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
