|
浅谈组织级项目管理推广经验*
How to implement organizational project management system *
Abstract: How to implement organizational
project management system? And how to do it effectively? This paper
give nine problems and the solution or method for each problem.
Key words: Project management; Organizational project management; CMM; ISO9001; SPI software process improvement; Metrics; software process management.
摘 要:
本文结合笔者实际经验，向读者阐述了组织级的项目管理体系的推广过程中的问题和解决方法。如何实施和推广组织级的项目管理体系，如何有效实施和推广？文章
给出九个关于组织级项目管理实施推广的问题并给出对每个问题在实际中的解决建议和方法。
关键词: 项目管理、组织级项目管理、CMM、ISO9000、过程改进、度量、过程管理。
中图法分类号: 文献标识码: ②
目前国内IT公司的企业管理越来越以项目为核心，而且项目不仅仅是单一的软件项目或者系统集成项目，往往各种类型的项目并存，或者同一个客户、同一个合同
要分解为若干个不同类型的项目来执行和实施，甚至要根据客户的要求来组织和管理这些项目。这样就产生了一个问题，就是如何在组织层次管理这些不同类型、不
同规模、不同领域的项目，因此在组织层次建立一个组织级项目管理体系来适应这种变化就显得极为迫切。但是如何将已建立的组织级项目管理体系在组织内部各个
项目中宣贯、推行呢？
本文结合我们在建立和推广基于CMM（其中了借鉴了众多的理论框架和模型方法，比如CMMI、XP、ISO9001、PMBOK、ITIL等。）的组织级的项目管理体系过程中，遇到的问题和困难做浅显的论述，希望就组织级项目管理体系的推广、实施与读者一起分享经验，共同交流和研讨。
对于很多企业来讲，基于以下模型(如
CMMI、XP、ISO9001、PMBOK、ITIL等)、结合企业内部的业务和组织的实际情况建立一套组织级的项目管理体系不是一件很难的事情，当然
也需要花费很大的精力来完成。但是最重要的是企业如何有效推广和实施这个体系，这是关系到这个体系最终实际效果的非常关键的环节和步骤。很多企业往往花费
了很大的人力和财力，通过了ISO9000或者CMM等的认证和评估，但是却没有为企业提高生产效率、提高产品和服务的质量起到明显的效果，充其量是拿到
一纸证书。因此如何在组织中有效推广和实施组织级的项目管理体系，逐步改善和提高组织的项目管理能力，逐步通过体系建立和完善企业的核心竞争力方面就显得
尤为重要。
本
文是笔者在公司内部从建立、实施和推广到持续改善组织级项目管理体系的过程中遇到的种种问题，以问题和解答的形式向大家阐述，算作经验的积累。有些解决方
法也是跟同业的同行专家学习到的经验，一并总结出来，可以作为企业实施和推行组织级的项目管理体系的相关人员和希望改善组织级的项目管理能力的技术和管理
人员参考，更希望大家一起共同交流和学习。
对于在一个大型的组织内部推广和实施一个组织级的项目管理体系，对在其中可能遇到的问题和阻力进行预测和分析，将会对于你的推广和实施工作带来方便和好的
影响。这些问题有些可能没有标准正确的答案，但是我们可以通过分析这些问题的原因和它带来的影响来确定如何处理和面对，但是无论如何，我们都不可以忽略和
轻视这些问题。
以下将针对我们在推广组织级项目管理体系过程中遇到的九个典型的阻力和问题，以及相对应的解决方案和管理措施逐一列举介绍。
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的成
员，当在遇到这样的问题时，必须小心回答，因为这将成为你工作上很大的阻力和压力。关于组织级项目管理会给企业带来什么回报我们可以从以下几个方面来解
释：
第一，从整个行业来看，或者举出其他企业的成功案例，或者找出竞争对手这样做取得了良好的效果。公司的高层经理往往会关注竞争对手的进步；
第二，从企业内部来看，做经济效益的分析，参见下图：
组织级体系的涉众利益分析：
组织级体系的经济利益的分析：
第三，下面这个方法也许是能更加量化，向决策人更好地解释的途径：
当你面对上面的问题时，应该按照如下的步骤来分析答案。
1. 列出目前影响组织中软件项目赢利的几个问题点，因为项目管理体系不可能直接创造价值，我们从相反的角度来思考这个问题；
2. 分析一下这些点有哪些是通过过程改进和管理可以解决的；
3. 对比实施过程改进解决这些问题所花费的成本和由此而得到的成本的节约；
4. 考虑进去实施过程改进的其他间接获益。
比如，下图是我们某个部门的分析，使用了石岛川的鱼骨图方法，把影响项目亏损的原因找出来。因为发现了问题才能去解决问题，只有针对问题才能对症下药。
一个新的方法和模型，总是会有人提出负面的问题，就如NAH症结（Not
Applicable Here），对于一个新的方法体系，大家都觉得有道理，但是具体到一个组织、一个项目实施过程中，总是能找出消极的理由来说明这个
方法在这儿是不合适的、是不适用的。大家坚信这个方法或理论对于其他的组织和单位是适用的，但是到了自己头上，往往想到的是它有哪些缺陷和不适用，对它们
的优点视而不见，总是用过于批判的眼光来审视它们，这也是造成推广效果不理想的重要原因之一。
对于这种阻力，我们要从两方面来分析：
l 第一：是否是真的不合适，如果是这样，那就要从如何客户化和实例化入手，让它更适合该组织的特殊环境；
l 第二：如果仅仅是因为一些习惯或者没要说服力的理由，那就不能动摇实施推广的信心和念头，因为任何新的东西都会改变以前的某些习惯和做法，甚至会触及部分人的既得利益。
这个问题的解决方法有两种：
l 一是强硬的策略，先僵化，再固化，然后再灵活化。通过僵化、固化，更深地了解和学习这些新的方法和理论，更深地了解到底不适用是人的问题还是方法本身的问题。然后再来定制和灵活处理。
l 第
二就是针对不适合的地方进行裁剪，当然这必须基于对方法本身和自己的需求十分清楚才可以，否则容易画牛不成反类马的南辕北辙的情况。要达到目标，正确的方
向和努力是两个必要的条件，但是如果方向是错误的，那努力会让目标越来越远。裁剪的策略和如何进行裁剪在整个工作过程中是最困难的，正确的策略和正确地裁
剪是非常重要的。为此我们需要制订和编写详细的过程裁剪的指南和项目的生命周期的裁剪指南。
在如何更好地适合自己组织的要求方面，也有很多好的方法可以借鉴，比如：
l 对过程进行裁剪；
l 定义不同的项目的生命周期模型，比如软件研发类、集成类、服务类等；
l 针对不同的项目进行生命周期的裁剪。
实践证明，在企业实施和推广一个组织级的项目管理体系的阻力来自公司内部、公司外部。（公司外部的因素涉及到整个行业的发展、市场因素和客户因素，在此不
做描述，本文重点对企业内部的因素做分析。）因为体系的实施，需要的是组织内部的人员的工作方式和管理的改变，这种改变影响最大的就是技术和管理人员。有
人说：如果人没要改变，那么一切都不会改变。因此要想获得组织级体系的实施的成功，改变体系的主体人是最直接、最重要的一项工作。
所以在组织级体系推广时最终必须实现人人参与，项目管理本身就是一项团队活动，如果不是每个人都参与，就不会获得整个项目的成功。而且不参与的人员将会成
为阻碍的力量。正如组织管理心理学中的“归因理论”，参与的重要性在于让参与的人意识到项目的成功有自己的努力在里面，从而他会更希望成功。参与的目的是
通过参与改变对项目管理本身的认识和理解，了解并熟悉体系本身，学习如何在项目的实际过程中如何按照组织的要求和规范进行。进而主动遵循规范和流程，降低
推广的成本。
相反，如果不是人人参与，每个人的想法不同，以前的经验不同，甚至不同的员工以前就职的公司不同，采用不同的体系和方法，这种文化和思想上的融合是比较困难的。因此如果人没有改变，那么整个的管理就不会改变，所以体系的推广必须跟人的改变结合一起，相辅相成，互相促进。
但是人的改变不是一件容易的事情，通常应该注意的有以下几点：
l 人的改变不是去改变个人的性格、个人的思想和个人的价值观，如果这样理解就非常危险，通常会导致紧张的人际关系；
l 人的改变是大家达成共识的过程，是统一组织的价值观；
l 人的改变不是一蹴而就的，需要坚持和耐心；
l 人的改变要与公司的制度建设和组织文化建设相结合，不可单枪匹马，孤军奋战。
这往往会成为项目组乐于接受并主动欢迎的唯一的形式。因为大部分企业把培训作为一种福利或激励手段。而工具的推广一方面使得项目经理和技术人员学习到最新
的工具和方法，另一方面也可以提高项目组的成员的工作效率，为他们的日常工作提供方便，减轻日常的繁杂的工作，比如：工作量的填报、收集、问题单的填报、
跟踪、各种报告等重复性劳动等。
因此在推广组织级的项目管理体系的时候考虑相关的工具的推广是一个很好的主意。当然工具的选择、引入和推广是PMO必须考虑的，什么时候引进，引进哪些工
具？都是要慎重考虑的，因为工具的引入可能会改变已有的体系的流程和操作，包括是采购还是自行开发等都需要慎重考虑。下图是选择和引入工具的流程，供大家
参考。
 目前在软件组织常用的工具有：
l 配置管理工具：VSS、CVS、CC等；
l 缺陷跟踪工具；
l 工作量测量工具：用于工作量测量和报工、派工使用；
l KPI考核系统；
l 分析建模工具：Rose、PowerDisigner、ERWin等；
l 测试过程管理工具；
l 需求管理工具；
l 过程管理和度量工具等。
项目组人员抱怨文档太多是一个普遍的现象，甚至有些人把进度的延误归结为写了太多的文档。抱怨文档太多的原因有以下几个：
1. 确实是比较多：除了技术方面必须的文档之外，用于管理的、控制的、跟踪记录的、作为报告的、度量分析等文档，文档的工作量增加了管理的成本，同时也增加了项目组的负担；
2. 重
复劳动比较多：为了针对不同的读者（上级领导、客户等）对同样的内容要按照不同的模板写多次。这种情况发生在项目经理身上比较多，经常为了汇报项目情况要
把相同的内容拷贝、粘贴到不同的模板交给不同的人。或者在做量化管理的时候，收集和测量一些过程数据，也存在类似的情况。有人说项目经理只要会在Word文档里Copy、Paste就可以，虽然这不是现实，但反映了项目经理的重复性劳动确实是实际存在的；
3. 习惯以前的做法：以前可能习惯不规范的开发，管理相对比较粗放，突然接受到新的规范，感觉文档太多。这种情况尤其在体系刚发布，开始推广的时候大家反应比较激烈。
解决方法：
1. 对于第1点，PMO首要的任务就是砍掉无用的文档，合并可以合并的文档，暂时管理上不需要的文档作为可选文档，不是必填的；
2. 第2
条实际是一个常见的问题，项目经理疲于应付来自各个管理层的汇报请求，复制、修改成了项目经理的家常便饭。对于这种情况，有两个解决方法，一是规范汇报机
制，规范沟通方式。二是使用工具，使用工具可以让项目经理从中提取数据，充分共享原始数据。比如度量工具、报工系统等；
3. 对于第三条是最让PMO头痛的，因为这种情况很容易演变为大家对体系的阻力。解决的办法主要是宣贯、培训，正如3.5的介绍。
度
量的目的主要是实现精细化的管理、有效地对项目进行控制，对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑，一方面度量对于
精细化管理是必要的前提，另一方面度量体系、度量的执行需要花费大量的人力成本，而且如果没有明确的目标和有效的方法来分析和利用这些数据，度量就又陷于
无谓的劳民伤财，成为组织过程的累赘。
很多企业的度量陷于盲目，导致了很多负面的影响，进而影响整个组织对项目管理体系的理解和信任。有如下问题和误区存在：
1. 不清楚组织的需求（到底需要度量什么）；
2. 不清楚度量的用途，认为度量总是有用的；
3. 度量是不需要花费的或者投入是很小的；
4. 直接用于考核，忽视了度量的导向作用的两面性（最常见的就是代码行作为程序员的成绩，导致了代码的重用性差，无效代码增多等负面影响）；
5. 在数据分析时孤立分析数据结果，没有考虑相关的度量指标的结果；
6. 不相信数据，认为数据是没有用的。
在这里不想介绍什么样的度量体系和方法、度量的技术和流程。仅仅结合度量在实际实施过程中的好的实践列举给大家。对于上述误区有以下实践和经验可以借鉴：
1. 需要什么才度量什么，从组织的需要、项目的需要、产品的需要、过程的需要以及管理的需要等分析，根据目标来选择测量指标；
2. 度量必须用于决策并支持决策才有意义，度量必须结合组织的商业目标并为实现这个目标而努力；
3. 度量是耗时耗力的，因此测量不要花费过多的额外工作量，测量结合在工作过程中，而不是需要额外的工作，可以考虑使用工具，减少度量的成本；
4. 不要直接用于考核，从积极和正向激励的角度出发来设置度量考核，如果用于考核要结合多个指标，并将数据处理后使用，不能直接使用；
5. 数据分析要考虑影响因素和相关Metrics；
6. 保证数据的完整正确，并相信数据，如果你不相信它，那它就没有任何意义。
规范化的文化说到底是建立一种共识，有了这种共识，规范化的制度、流程才得以顺利执行，缺少这种共识，在我们推行一个体系和制度时就会困难重重，阻力和压
力会导致冲突和失败。文化相对于制度，正如道德相对于法律，对于执行来说可以大大降低成本。因此从一开始就以建立共同的共识、最终建立一个规范化的文化为
目标，会使得我们的推广行动事半而功倍。想一想，当规范和制度成为一种习惯的时候，我们的“推”行的工作还需要“推”才“行”吗？当然这个时候我们的工作
重点就是过程的改善和维护了。
如何才能建立起规范化的文化呢？我想不同的组织和不同的人的答案肯定是不同的。我们的经验就是：加强宣贯，不断强化，建立共识，形成习惯。
总结我们在实施和推广组织级的项目管理体系的过程中，决定实施推广成功的因素有以下几点：
² 有人去做 － 设立PMO或相关机构负责；
² 高层支持，下层买账 － 获得高层理解，取得下层的信任和认可；
² 人人参与 － 建立广泛的共识，消除潜在的阻力；改变人才能改变组织；
² 建立文化 － 文化的建立标记着体系的制度化和实施推广的成功。
致谢 在此，我们向对本文的工作给予支持和建议的同行、同事表示感谢。
References:
[1] 《软件过程管理》，瓦茨.S.汉弗莱。北京。清华大学出版社，2003
[2] 《CMMI3级软件过程改进方法与规范》，林锐。北京。电子工业出版社，2003
[3] 《组织管理心理学》，北京大学出版社，2004
[4] 张家浩。软件项目管理。北京。机械工业出版社。2005
[5] 《Software Assessments, Benchmarks and Best Practices》，Capers Jones，Pearson Education 2003
[6] 《CMM in Practice Processes for Executing Software Projects at Infosys》，Pankaj Jalote。India，Publishing House of Electronics Industry，2002
作者简介：李华领，男(汉族)，神州数码(中国)有限公司政府和公共事业本部项目管理部经理、高级项目经理，曾多年从事软件开发和项目管理工作，参加过三峡工程管理系统项目以及全国性的大型信息化项目的开发和管理，主要兴趣方向：项目管理、软件质量管理、CMM/CMMI等。
|
|
|
