1          前言
       目前国内IT公司的企业管理越来越以项目为核心，而且项目不仅仅是单一的软件项目或者系统集成项目，往往各种类型的项目并存，或者同一个客户、同一个合同要分解为若干个不同类型的项目来执行和实施，甚至要根据客户的要求来组织和管理这些项目。这样就产生了一个问题，就是如何在组织层次管理这些不同类型、不同规模、不同领域的项目，因此在组织层次建立一个组织级项目管理体系来适应这种变化就显得极为迫切。但是如何将已建立的组织级项目管理体系在组织内部各个项目中宣贯、推行呢？
本文结合我们在建立和推广基于CMM（其中了借鉴了众多的理论框架和模型方法，比如CMMI、XP、ISO9001、PMBOK、ITIL等。）的组织级的项目管理体系过程中，遇到的问题和困难做浅显的论述，希望就组织级项目管理体系的推广、实施与读者一起分享经验，共同交流和研讨。
2          正文
对于很多企业来讲，基于以下模型(如CMMI、XP、ISO9001、PMBOK、ITIL等)、结合企业内部的业务和组织的实际情况建立一套组织级的项目管理体系不是一件很难的事情，当然也需要花费很大的精力来完成。但是最重要的是企业如何有效推广和实施这个体系，这是关系到这个体系最终实际效果的非常关键的环节和步骤。很多企业往往花费了很大的人力和财力，通过了ISO9000或者CMM等的认证和评估，但是却没有为企业提高生产效率、提高产品和服务的质量起到明显的效果，充其量是拿到一纸证书。因此如何在组织中有效推广和实施组织级的项目管理体系，逐步改善和提高组织的项目管理能力，逐步通过体系建立和完善企业的核心竞争力方面就显得尤为重要。
本文是笔者在公司内部从建立、实施和推广到持续改善组织级项目管理体系的过程中遇到的种种问题，以问题和解答的形式向大家阐述，算作经验的积累。有些解决方法也是跟同业的同行专家学习到的经验，一并总结出来，可以作为企业实施和推行组织级的项目管理体系的相关人员和希望改善组织级的项目管理能力的技术和管理人员参考，更希望大家一起共同交流和学习。
       对于在一个大型的组织内部推广和实施一个组织级的项目管理体系，对在其中可能遇到的问题和阻力进行预测和分析，将会对于你的推广和实施工作带来方便和好的影响。这些问题有些可能没有标准正确的答案，但是我们可以通过分析这些问题的原因和它带来的影响来确定如何处理和面对，但是无论如何，我们都不可以忽略和轻视这些问题。
       以下将针对我们在推广组织级项目管理体系过程中遇到的九个典型的阻力和问题，以及相对应的解决方案和管理措施逐一列举介绍。
3          九大典型问题及解决办法
3.1.     为什么需要PMO？
       PMO（Project Management Office）一般称为项目管理办公室、项目管理中心或者项目管理部。PMO是提高组织管理成熟度的核心部门，它根据业界最佳实践和公认的项目管理知识体系，并结合企业自身的业务和行业特点，结合企业的商业目标，负责为本组织量身定制项目管理流程、培养项目管理人力资源、建立项目管理信息系统、对具体项目提供管理指导、帮助组织开展多项目管理等，以此确保项目成功率的提高和组织战略的有效贯彻执行。如何分配给PMO的职责和权利，也是我们在实施组织级项目管理过程中不得不面对问题。
       首先，既然要执行组织级的项目管理制度，那必须在组织层面有人来负责该工作，因此PMO就担当此任。任何工作，无论它的重要性如何，如果最后不能落实到有效的资源来执行，不能保证适合的人来做的话，那这就很可能无果而终。因此有一个专门的机构（这个机构可以是实际存在的也可以是虚拟的，可以是兼职的也可以是专职的，视组织的规模和情况而定）来负责是必要的。
       其次，让我们来看看PMO的职责：
u       开发和维护项目管理标准、方法和程序；
u       为企业提供项目管理和咨询和指导；
u       为企业提供合格的项目经理、质量经理；
u       为企业提供质量保证的手段和能力；
u       为企业提供项目管理体系的培训；
u       为企业提供项目管理的其他支持；
u       负责组织级的过程建设、组织级的财富积累、知识传递等。
       第三，组织内部必须有一个专家组织，PMO人员的素质和能力往往决定组织级项目管理能力的高低，决定组织级体系能否发挥作用的前提条件。试想如果不是一个在该领域具有专家能力的人，他们制定的体系和制度能否得到执行者的认可？因此对于PMO来说，具备相应的能力是必须的。
     第四，PMO组织机构及组成人员：
              PMO的组织机构一般分为以下几条线：
l         一是项目管理：包括项目总监、助理项目总监、高级项目经理、项目经理等；
l         二是质量管理：包括质量总监（组织级）、SQA（项目级）、审计专家、配置管理经理、配置管理工程师；
l         三是组织过程组：包括SEPG（软件工程过程组）、ISO9000内审组、度量数据分析组；
l         四是知识工具：包括知识管理人员、培训协调人、工具开发组。
3.2.     软件项目为什么有了PM和PMO还需要SQA？
       这个问题似乎很多人都对此有疑问，既然项目经理是项目的直接责任人，他负责整个项目的TQC。那么为什么还需要专职的SQA来保证项目的质量呢？回答这个问题，先让我们看一下东西方的制度和文化的不同。西方的文化强调分权、量化，这与西方的制度也有很大的关系。在他们的管理哲学中强调，不是不相信当事人，而是必须是制度来保证独立的第三方来对工作进行检查，验证。不论CMM还是ISO9001，都是我们引进的西方的管理模型和标准，因此我们就不得不考虑这些模型和标准背后的管理文化的差异。对待SQA这个角色来说就是最典型例子。
       在软件项目中，SQA正是这样的角色，他是规范过程的引导者、过程执行的监督者。是独立于项目的第三只眼睛，从不同的视角来审视项目的问题，并将此通过单独的渠道汇报给高层经理或者项目的最终负责人。
       在组织过程中，尤其对于实施CMM体系的企业，对于SQA这个角色的认识更为清楚和深刻。
       下面是PM、PMO、SQA的职责的比较：
角色 职责
PMO 更关注组织级的体系的建立、维护和改善；
关心整个组织的所有项目的成功，不是一个项目的成功；
  对组织所有的项目进行监督和监控；
为项目中的PM和SQA提供技术、工具等支持；
关心组织项目管理能力的成熟度。
PM 更侧重于关心进度、成本、开发以及技术等方面；
PM对SQA的工作提供支持；
PM更关心当前项目的成功，PM是直接责任者；
直接领导项目组成员。
SQA 侧重于过程管理，对过程进行审核，确保过程正确实现；
协助PM积累项目的过程财富；
SQA帮助PM发现并解决项目中的问题，对于不能解决的问题要及时上报；
SQA不仅仅关心当前项目的成功，还关心整个组织的过程能力；
不直接领导项目组成员。

3.3.     项目管理体系的投资与回报分析
       建立和实施项目管理体系，对企业带来哪些利益？这也是个典型的问题，任何企业的经营管理层都会对自己企业的投入能得到什么回报最为关心。因为对于企业来说，赚取最大利润是最重要的。如果企业的管理者反对或者不愿意进行某件事情，那么他就会问做这件事情会给企业带来什么经济上的效益。如果作为PMO的成员，当在遇到这样的问题时，必须小心回答，因为这将成为你工作上很大的阻力和压力。关于组织级项目管理会给企业带来什么回报我们可以从以下几个方面来解释：
       第一，从整个行业来看，或者举出其他企业的成功案例，或者找出竞争对手这样做取得良好的效果。公司的高层经理往往会关注竞争对手的进步；
       第二，从企业内部来看，做经济效益的分析
       第三，下面这个方法也许是能更加量化，向决策人更好地解释的途径：
当你面对上面的问题时，应该按照如下的步骤来分析答案。
              1.       列出目前影响组织中软件项目赢利的几个问题点，因为项目管理体系不可能直接创造价值，我们从相反的角度来思考这个问题；
              2.     分析一下这些点有哪些是通过过程改进和管理可以解决的；
              3.     对比实施过程改进解决这些问题所花费的成本和由此而得到的成本的节约；
              4.     考虑进去实施过程改进的其他间接获益。
              比如，下图是我们某个部门的分析，使用了石岛川的鱼骨图方法，把影响项目亏损的原因找出来。因为发现了问题才能去解决问题，只有针对问题才能对症下药。


3.4.     适用性带来的阻力
       一个新的方法和模型，总是会有人提出负面的问题，就如NAH症结（Not Applicable Here），对于一个新的方法体系，大家都觉得有道理，但是具体到一个组织、一个项目实施过程中，总是能找出消极的理由来说明这个方法在这儿是不合适的、是不适用的。大家坚信这个方法或理论对于其他的组织和单位是适用的，但是到了自己头上，往往想到的是它有哪些缺陷和不适用，对它们的优点视而不见，总是用过于批判的眼光来审视它们，这也是造成推广效果不理想的重要原因之一。
对于这种阻力，我们要从两方面来分析：
l         第一：是否是真的不合适，如果是这样，那就要从如何客户化和实例化入手，让它更适合该组织的特殊环境；
l         第二：如果仅仅是因为一些习惯或者没要说服力的理由，那就不能动摇实施推广的信心和念头，因为任何新的东西都会改变以前的某些习惯和做法，甚至会触及部分人的既得利益。
       这个问题的解决方法有两种：
l         一是强硬的策略，先僵化，再固化，然后再灵活化。通过僵化、固化，更深地了解和学习这些新的方法和理论，更深地了解到底不适用是人的问题还是方法本身的问题。然后再来定制和灵活处理。
l         第二就是针对不适合的地方进行裁剪，当然这必须基于对方法本身和自己的需求十分清楚才可以，否则容易画牛不成反类马的南辕北辙的情况。要达到目标，正确的方向和努力是两个必要的条件，但是如果方向是错误的，那努力会让目标越来越远。裁剪的策略和如何进行裁剪在整个工作过程中是最困难的，正确的策略和正确地裁剪是非常重要的。为此我们需要制订和编写详细的过程裁剪的指南和项目的生命周期的裁剪指南。
  在如何更好地适合自己组织的要求方面，也有很多好的方法可以借鉴，比如：
l         对过程进行裁剪；
l         定义不同的项目的生命周期模型，比如软件研发类、集成类、服务类等；
l         针对不同的项目进行生命周期的裁剪。
3.5.     如果人没要改变，那么一切都不会改变
       实践证明，在企业实施和推广一个组织级的项目管理体系的阻力来自公司内部、公司外部。（公司外部的因素涉及到整个行业的发展、市场因素和客户因素，在此不做描述，本文重点对企业内部的因素做分析。）因为体系的实施，需要的是组织内部的人员的工作方式和管理的改变，这种改变影响最大的就是技术和管理人员。有人说：如果人没要改变，那么一切都不会改变。因此要想获得组织级体系的实施的成功，改变体系的主体人是最直接、最重要的一项工作。
       所以在组织级体系推广时最终必须实现人人参与，项目管理本身就是一项团队活动，如果不是每个人都参与，就不会获得整个项目的成功。而且不参与的人员将会成为阻碍的力量。正如组织管理心理学中的“归因理论”，参与的重要性在于让参与的人意识到项目的成功有自己的努力在里面，从而他会更希望成功。参与的目的是通过参与改变对项目管理本身的认识和理解，了解并熟悉体系本身，学习如何在项目的实际过程中如何按照组织的要求和规范进行。进而主动遵循规范和流程，降低推广的成本。
相反，如果不是人人参与，每个人的想法不同，以前的经验不同，甚至不同的员工以前就职的公司不同，采用不同的体系和方法，这种文化和思想上的融合是比较困难的。因此如果人没有改变，那么整个的管理就不会改变，所以体系的推广必须跟人的改变结合一起，相辅相成，互相促进。
但是人的改变不是一件容易的事情，通常应该注意的有以下几点：
l         人的改变不是去改变个人的性格、个人的思想和个人的价值观，如果这样理解就非常危险，通常会导致紧张的人际关系；
l         人的改变是大家达成共识的过程，是统一组织的价值观；
l         人的改变不是一蹴而就的，需要坚持和耐心；
l         人的改变要与公司的制度建设和组织文化建设相结合，不可单枪匹马，孤军奋战。
3.6.     工具的推广和体系的培训
       这往往会成为项目组乐于接受并主动欢迎的唯一的形式。因为大部分企业把培训作为一种福利或激励手段。而工具的推广一方面使得项目经理和技术人员学习到最新的工具和方法，另一方面也可以提高项目组的成员的工作效率，为他们的日常工作提供方便，减轻日常的繁杂的工作，比如：工作量的填报、收集、问题单的填报、跟踪、各种报告等重复性劳动等。
       因此在推广组织级的项目管理体系的时候考虑相关的工具的推广是一个很好的主意。当然工具的选择、引入和推广是PMO必须考虑的，什么时候引进，引进哪些工具？都是要慎重考虑的，因为工具的引入可能会改变已有的体系的流程和操作，包括是采购还是自行开发等都需要慎重考虑。下图是选择和引入工具的流程，供大家参考。

       目前在软件组织常用的工具有：
l         配置管理工具：VSS、CVS、CC等；
l         缺陷跟踪工具；
l         工作量测量工具：用于工作量测量和报工、派工使用；
l         KPI考核系统；
l         分析建模工具：Rose、PowerDisigner、ERWin等；
l         测试过程管理工具；
l         需求管理工具；
l         过程管理和度量工具等。
3.7.     解决文档问题
       项目组人员抱怨文档太多是一个普遍的现象，甚至有些人把进度的延误归结为写了太多的文档。抱怨文档太多的原因有以下几个：
  1.       确实是比较多：除了技术方面必须的文档之外，用于管理的、控制的、跟踪记录的、作为报告的、度量分析等文档，文档的工作量增加了管理的成本，同时也增加了项目组的负担；
2.       重复劳动比较多：为了针对不同的读者（上级领导、客户等）对同样的内容要按照不同的模板写多次。这种情况发生在项目经理身上比较多，经常为了汇报项目情况要把相同的内容拷贝、粘贴到不同的模板交给不同的人。或者在做量化管理的时候，收集和测量一些过程数据，也存在类似的情况。有人说项目经理只要会在Word文档里Copy、Paste就可以，虽然这不是现实，但反映了项目经理的重复性劳动确实是实际存在的；
3.       习惯以前的做法：以前可能习惯不规范的开发，管理相对比较粗放，突然接受到新的规范，感觉文档太多。这种情况尤其在体系刚发布，开始推广的时候大家反应比较激烈。
解决方法：
1.     对于第1点，PMO首要的任务就是砍掉无用的文档，合并可以合并的文档，暂时管理上不需要的文档作为可选文档，不是必填的；
2.     第2条实际是一个常见的问题，项目经理疲于应付来自各个管理层的汇报请求，复制、修改成了项目经理的家常便饭。对于这种情况，有两个解决方法，一是规范汇报机制，规范沟通方式。二是使用工具，使用工具可以让项目经理从中提取数据，充分共享原始数据。比如度量工具、报工系统等；
3.     对于第三条是最让PMO头痛的，因为这种情况很容易演变为大家对体系的阻力。解决的办法主要是宣贯、培训，正如3.5的介绍。