您的企业适合拥有PMO吗?——《PMO论文集(2019)》(电子版)
原创: PMO评论 特约作者:谢二菊
摘要:企业建立PMO(项目管理办公室)和PMO是否按照企业的要求产生价值是有本质区别的。首先,企业要为PMO设定清晰的目标,PMO通过分解目标,确定工作职责,然后开展工作;其次,PMO在企业中被管理层如何定位,决定了PMO开展工作的方式,高级别的定位和低级别的定位存在本质区别,最直接的项目经理对PMO认可程度就存在不同;PMO持续运转,定期或事件驱动产生了很多的成果,企业最高管理者是否关心这些成果直接决定了PMO存在的价值;PMO的投入主要是核心人员的投入,没有合适的人,工作无法推进,本质上PMO是否能介入运转的项目中是评价人员是否合适的标准,能不能介入项目也是PMO是否有价值的核心指标之一;PMO不可能立竿见影,是长期的,有步骤的,仅仅投入1~2年就希望看到重大成就比较困难,通常企业在2年开始放弃,放弃方式可能是形式上的(名存实亡)和本质上的(撤销组织)。
关键词:PMO 目标 定位 指示器

一个企业,规模发展到一定程度,从人员规模、项目数量、业务复杂度、项目模式、内部组织方式等多方面评估,可以确定是否需要组织级PMO帮助企业管理者关注、跟踪、管理、协助公司所有的项目,保证项目信息的通透、各管理者对项目状况了解的一致性、项目问题及时被发现和解决等,最终确保项目在预算范围内按照计划正常实施结束。
对于规模过小的企业,建立PMO的价值不大,毋须建立。
但是,不是所有的企业需要PMO就能拥有PMO,以下一些必要条件满足时,企业才能拥有PMO。
1. 建立PMO的目标是否清晰
1.1 目标的初解
很多企业发现项目问题频发,就开始组建PMO,简单地认为PMO是万能的,只要建立PMO,问题项目就消失了,公司所有项目就能正常运转。所以建立PMO的目标定义为——消除问题项目。
1.2 真实的目标
2005年我为公司建立PMO时,公司给PMO定义的目标是消除赤字项目,接到这个目标后,通过分析和访谈,发现公司目前控制项目成本的是中层管理者,并且他们认为由项目经理或PMO控制预算和成本不现实,PMO如何能实现该目标?
如何定义赤字项目,是第一个问题;如何减少或消除是第二个问题。我和公司最高管理者沟通目标,也提出了我的疑惑,很明显,目标是清晰的,只是运营方式的问题,是PMO自身需要解决的问题。公司同意大力支持PMO的工作。
1.3 目标的难度
消除问题项目目标太大太泛,所以这个目标是一个不可能完成的目标。可能有人认为公司给我的目标比较容易达成,不管成本的项目经理不是合格的项目经理,同样,不管成本的PMO不是合格的PMO,据我横向了解相关企业PMO状况,能参与项目成本管理的PMO凤毛麟角。为什么不管成本,原因体现在:关联组织过多(合同、财务、人力、质量等),协调困难,需要的数据过多(还有大量的保密数据),获取困难等等。
在建立PMO的过程中,我也多次同老板沟通,消灭赤字项目这个目标是否太高,我们的企业是否能实现,但老板坚持。为了说服最高管理者,我和某些熟悉的高级别的管理者和中层管理者进行了沟通,他们和我存在同样的疑惑,我们共同和最高管理者沟通,结果还是要求坚持。在后来的多次沟通中,最高管理者终于告知,对于以项目为基础的公司,每个项目的利润是有限的,存在赤字项目,意味着必须动用其他项目的利润弥补,公司的利润将大幅缩减,对公司的运转将造成直接影响,这个目标也是某大型国际软件公司的目标,是一个对企业真正适用的目标。
1.4 组织的帮助
2005年,PMO这个概念还不是很流行,从网络上能找到的帮助少之又少,为了帮助我们PMO理解目标和寻求PMO建立和运作的方法,公司最高管理者帮助寻找了很多线下的资源,对接了不少超大型软件公司(其中日本和欧美企业为主)的PMO,这些公司PMO创建时间有长有短,但建立的时间都不是很长,不过已经走过目标设置和初期建立阶段。公司最高管理者在沟通过程中亦参与其中,后来反思,所有沟通管理者都参与,对我们PMO既有好处又有坏处,好处是别的公司PMO如何建立和运作,管理者很清楚,坏处是别的公司经过“粉刷”的点,如果被管理者认可,对PMO的实施提升了难度。
1.5 目标的分解
一个公司每天同时运转上100个项目(100多个项目是我们建立PMO时的状况,后来企业同时运转的项目超过400个),几乎不可能实现0赤字项目。我们将目标实施分解,确定了赤字项目数和赤字总金额两个指标,通过对这两个指标的完成度确定目标的达成度。需要强调一点:目标清晰的另一个层面是目标可以分解,并可以定量化,否则对于PMO是灾害,PMO要求项目数据化可视化,自身目标还不能定量化,权威性直接受到质疑。
企业可以给PMO定义很高的目标,但一定要清晰,目标可能需要经过多年努力才能实现,企业要坚持,PMO在压力下也在坚持。
2. PMO定位是否准确
PMO明确的定位,可以帮助PMO确立在组织中的地位。
2.1 PMO现状
现在大部分企业的PMO都是信息收集组织,稍微好一些的参与部分项目的审查,但大部分企业对外宣称PMO监管项目。既然监管项目,首先要明确什么叫监管,组织的需求是什么,各关联角色的职责是什么,PMO需要完成哪些工作才实现了监管,为了完成这些工作,需要什么资源支撑等,这些问题不清楚,定位也就不清晰,就更不准确。作为PMO的负责人,一定要和管理层将这些问题梳理清楚,能够形成规程或文件的,要文档化制度化。
2.2 PMO地位的发展过程
PMO需要在最高管理者的同意下,给自身一个定位,这个定位和你的目标要契合。当然,可以从低价值的工作开始实施,但每年需要有所提升,每年至少新增2件可以提升PMO价值的工作,当完成的工作越来越多,越容易被组织和项目认可,这样可以离定位越来越近,如果总是原地踏步,只做一些事务工作,永远不可能达成目标定位。
作为PMO负责人,在目标清晰时,可以梳理本身的定位,通常企业对某个组织的定位是完成或达成某些条件后定义的,不要异想天开地认为企业为什么没有给PMO足够高的定位,很多时候给了定位,给了权力,PMO是不知如何处置和行使权力的。
2.3 PMO在企业中的定位
PMO在企业中的定位如表1所示。

表1 PMO在企业中的定位
3. 最高管理者是否一直关注PMO成果
3.1 PMO是“一把手”工程
PMO原则上是谁需要谁建立,这是典型的“一把手”工程。PMO建立后,一定会产生很多的成果,显性的以文档和数据居多,隐性比显性的内容更多,但大多数是不可度量的或度量的难度较大,隐性的比显性的更有价值。比如,几乎所有的PMO都会收集项目数据,每个人都可以在权限范围内看到相应的数据,通过数据可以发现项目的状况,这也是各级管理者愿意看到的,简洁直观。但是,数据的真实性如何保障,真实的数据是否反映了项目的真实状态,这些都是PMO需要去了解和掌握的。这就诞生出两个关键点,最高管理者是否在关注,关注的内容是不是真实的。 3.2 关注与否的影响
3.2.1 不关注的后果
最高管理者关注与否,直接影响最终效果。如果不关注,即使内容是真实的,是客观的,随着时间的推移,也会逐渐变为不真实,不真实就更谈不上客观,原因很简单,没有人关注的信息是没有价值的。项目经理(有能力的)很清楚自身的项目状况,中层经理(负责的)也很清楚自己管辖的项目状况,实际上,只有最高管理者不了解(很大的原因是没有足够的精力去详细了解),只有项目发生了较大问题,如被客户投诉,最高管理者才知道公司有如此的一个项目,并且还引起了客户不满,不得不放下其他工作,和公司各级管理者及项目经理一同解决项目问题,平息客户不满情绪,这种情况下的投入通常是不记成本的投入,如果项目没有可观的利润,意味着项目将赤字。这就是不关注的后果。
3.2.2 关注的效果
最高管理者持续关注,能早期发现问题,可以在问题的初期就实施处置,这时候的成本远远低于后期被客户投诉后的处置成本和同时引起的返工成本。最高管理者的持续关注也可以让中层更细致、更全面地去关注自身所属的项目,可以更早地发现问题或风险,提前解决问题或形成解决方案,在最高管理者关注时,问题已经解决或已经有解决方式,最高管理者只需认可解决方案或依据解决方案帮助协调资源解决问题即可。另外一个方面,最高管理者的持续关注,可以让项目经理意识到公司内项目信息通路顺畅,自己的工作有价值被关注,同时可以提升项目经理的责任心。
最高管理者的持续关注,可以让PMO更加落地地“参与”到项目管理之中,PMO作为第三方,和项目经理是矛盾与共生的关系,矛盾不用过细地解释;对于共生,首先PMO需要有这样的认识,没有项目就没有PMO,PMO除了管控外,还需要帮助和协助项目经理实施项目管理,否则很难被项目经理认可,项目经理正是得到了组织层面的支持,才能认可PMO,直到项目经理意识到PMO就是“家”,就能很好地体现“共生”。PMO落地地参与到项目中,项目的真实状况完全可以掌握,数据是否真实不言而喻,通过数据得出的结论可以准确地判定,那么提供给最高管理者决策就很容易了。
3.2.3 关注案例
在实际的PMO运作中,我们发现一些有意思的现象,从项目层面收集的数据,各项质量类的指标都正常,但PMO成员了解到的项目成员经验相对偏低,该项目难易度也不是偏低的状况,如果按照通常的指示器评价该项目,只能说明人员体制方面的指示器存在问题,但PMO成员根据自身的经验,质量方面应该存在问题,于是直接到现场访谈项目经理,项目经理也认为在目前项目初期阶段质量是存在一定的问题;PMO向项目配置管理员获取了临时配置权限(公司已经给PMO授权),调取了相关的质量记录,发现经验丰富的成员(长期做该项目类似的业务)的BUG率非常低,经验较少的成员BUG率非常高,结果整体平均后变为“正常”。PMO成员和项目经理将质量指标进行了分类调整,并制定了相应的解决措施。如果最高管理者不关注,PMO通常不会投入更多的精力去深入了解项目,PMO真正的负责人是最高管理者,PMO需要对最高管理者负责,需要对企业负责。从另外一个方面思考,如果你的工作不是你老板关心的,不是企业关心的,你可能投入很多精力和热情去完成没有什么价值的工作。
3.3 最高管理者关注方式
还有另外一个核心问题,最高管理者应该如何关注项目呢?如果每个项目最高管理者都下现场绝对不可能(除非企业仅有为数不多的几个项目);所有项目领导们都一个个从数据上过一遍,也是不可能(简单计算:1个项目10分钟,100个项目就需要1000分钟;先不考虑时间是否允许,估计到后来所有人将处于一个癫狂或麻木状态)。这就需要解决通过什么方式关注项目和多长时间关注一次合适。
3.3.1 关注方式——指示器的价值
最高管理者对于完全正常的项目,关注度通常不高,对于小型项目关注度也不高,对于问题项目和大项目/超大项目(大项目的利润状况一般会决定项目型企业的年度利润,老板最终最关心的还是企业的生存,企业没有利润很难维续)老板关注度高。PMO需要帮助将所有的问题项目甄选清楚,大项目尤其超大项目最好由项目经理直接向最高管理者报告。
首先PMO需要向最高管理者报告公司整体项目状况;然后报告每一个问题或风险项目的状况(最好由项目的上级管理者报告,上级管理者有直接的资源,在问题的处置时非常有价值,另外,管理者的要求也可以直接到位,不需要经过PMO传递);最后针对所有的大项目/超大项目独立报告,至少在干系人、风险或问题、成本、质量、进度、合同等方面应该详细报告,报告过程中,项目的各上级管理者尽量都出席,所有人共同了解项目,共同解决项目的问题,作为PMO最好有第三方的观点,确保整个报告过程的“保真”和“纠偏”。
每个企业项目都不是单一化的,作为成熟的PMO,需要为不同类型的项目制定不同的指标和指示器,收集不同的数据准确地体现项目的状态。通常让最高管理者看到的仅仅需要指示器(正常、预警、异常等)即可,管理者(尤其高级管理者)不需要关注过细的细节。另外,一个企业的PMO能完全通过指示器描述项目,体现了两点,企业的成熟和PMO的成熟。指示器的表现方式如表2所示。

表2 指示器的表现方式
备注1:异常 预警 正常;指示器的内容是需要企业依据自身的需求提炼,表现方式并不是很重要,有的企业不使用红绿灯模式,使用表情包或晴雨表的都存在。
备注2:指示器判定的定义难度较大,需要根据企业内部状况确定各个一级指示器(如表2的质量、成本、进度等)需要什么数据支撑,二级指示器(如表2中的整体)如何由一级指示器判定。
备注3:最高管理者只需要关注项目3,必要时,可以关注二级指示器及数据;项目2了解原因即可,项目1可以略过。
3.3.2 关注频率
过密的关注,成本过高(包括会议成本和资料整理准备成本),过长时间关注,可能问题已经发生并变为很严重,几乎没有效果,推荐1~2月关注一次即可。除了定期的会议关注外,最高管理者需要授权PMO,在适当的时点组织事件驱动的评估/评审会议(尤其针对客户投诉项目和超大项目,地点不一定在会议室,在项目现场可能效果更好),以确保所有项目有计划有序的开展。
通过定期的关注,提前发现问题并自上而下地一同解决和关注问题,公司的项目管理机制更流畅,项目成功率更高,客户投诉会明显下降,利于公司赢得客户信任和长期的订单。
4. 是否有合适的人、是否愿意投入
4.1 投入什么样的人
多少资源做多少工作,什么样能力的人完成什么样的事。很多企业或组织将公司项目中不需要的“闲杂人员”送给PMO,包括PMO负责人也是头脑“不清醒”之人,结果可想而知。首先,PMO负责人一定有资深经历,在项目管理领域有一定建树(至少保证在公司内部资历),项目管理知识丰富,有良好的沟通能力等。PMO成员需要有较强的项目管理能力,否则和项目经理不能沟通,更有甚者被项目经理“欺负”。PMO的成员不能长期工作在PMO,需要采用轮换机制,既能提高项目经理的能力,又能使PMO成员和实际项目管理不脱节。
4.2 企业对投入的误解
PMO的投入主要是高效、能力强的人员投入,但大部分企业不愿意将优秀的项目经理投入到PMO,认为PMO不产生直接价值,更多的是浪费成本,一个好的项目经理完成一个项目就能为企业带来利润。表面上的确是这样的,但一个好的PMO项目经理如果“挽救”了一个或多个项目,其创造的价值远远高于自己亲自担任项目经理产生的价值,同时这个项目经理自身能力可以提高,另外还能帮助其他项目经理提升能力。很多公司有一种提升机制,项目经理提升为中层管理者需要担任QA或组织的质量负责人,个人认为到PMO工作一段时间更有价值。
4.3 PMO负责人的选择
每个企业建立项目管理办公室,最重要的是选择合适的PMO负责人。前面已经提到了能力要求,下面通过一个前期的工作论述负责人的价值。
PMO前期不需要太多的人,多投入是一种浪费。梳理公司现状是一个很重要的工作,建立组织级的项目管理流程是另一项很重要的工作,这些工作可以定义为准备工作。PMO负责人需要对公司业务相对熟悉,在流程方面有功底的人;如果对公司业务不是很熟悉,至少需要对行业熟悉,学习能力强可以缩短对业务和管理的理解时间。需要强调业务重要的原因:项目管理本质上依赖于业务,不理解业务,不可能和相关组织顺利沟通,不同业务的项目管理可能也存在一定的差异;我发现不少组织的PMO已经做了1~2年,还不知道企业研发哪些业务,可想PMO开展的工作被认可程度,完全不落地的实施。当然,熟悉业务不是让PMO成为每个业务的专家(当然专家更好)。举个例子:企业要对外投标,需要编写标书,在商务标书中最核心的是价格,企业承接一个项目多少价格拥有竞争力,并且项目还存在一定的利润非常重要,PMO通常横向管理所有的项目,对各类项目的合同价格都有了解,不同的业务难点在什么地方,不同的业务通常的利润率是多少都应该了解,在项目投标时,可以提供参考意见,对项目中标的概率提升有积极的影响。这种要求可能对初期的项目管理办公室要求相对较高,但是梳理和熟悉公司各个业务是一项很重要的工作,也是一项长期的工作,对于初期,可以通过访谈、项目资料查询等方式初步了解业务。
PMO负责人很重要的初期工作是建立相关流程。对于流程,一方面需要逻辑梳理能力,另一方面需要一定的文章撰写能力;这两方面大部分人都是缺乏的。我记得我曾经的总裁给我看了一份会议纪要(客户的高层通过邮件转送公司总裁),客户的观点是:公司的能力太差,先不评价专业的业务能力和技术能力,公司的项目经理完成会议纪要的能力都没有,你们的纪要第三方看不懂,不知所云。总裁很生气:作为公司的PMO,你是如何培养项目经理的?我当时的观点:公司的项目经理在项目管理和技术方面能力相对不错,但新的客户不知道,老的客户高层已经免疫,而我们提供给他们的文档资料将作为评判项目经理的直接因素,而这些方面正是公司项目经理的弱项。考察一个人的流程能力,可以对其纪要和撰写的文章作为一个直接的参考项。
组织级项目管理流程应该包含的内容参见表3。

表3 组织级项目管理流程
备注1:PMO越早介入项目越好,当然需要的能力越强。
很多组织建立流程依然按照单项目流程的方式建立,这主要是由于PMO负责人是由组织内的某个资深项目经理提升,通常只有单项目的管理意识造成。例子说明:大部分公司的项目结项都是中层管理者和项目经理沟通,认为项目可以结束了,将成员分派到其他项目,项目资料备份即可;比较好的企业还能要求项目经理提交项目总结;作为一个项目经理提升为PMO负责人,能将这些内容实施管理很正常。项目结项首先对项目外涉及合同和项目费用处置状况,客户后期如何应对(是否预留预算,是否需要将项目按照结转的方式处置),项目奖金或利润是否清晰;对项目内涉及项目总结是否完成(项目总结不是项目经理一个人的总结或项目经理一个人总结),项目成员绩效是否评价等;第三方是否需要评价项目等。
从上面的内容我们可以看出,PMO负责人还需要有组织管理能力和意识。
4.4. PMO体制
PMO一定是一个团队、一个组织,就需要有明确的分工和体制。至少设置PMO负责人(总监或经理)一名,PMO项目经理若干名。PMO体制设置方式如表4所示。

表4 PMO体制设置方式
备注1:很多组织采用纵向的方式设置PMO体制,即每项工作设置1个或多个人员(理由是专业),我的建议是横向设置体制,1个或多个组织设置一个PMO成员,好处在于PMO成员能全方位了解和支持/支撑项目,服务一个或多个业务,同时能全方位提升成员的能力。
备注2:PMO成员的职位设置为项目经理合适,不要设置为专员或主管,无形地拉开了和项目经理之间的距离。
备注3:PMO内部不建议设置多层级,最佳方式是所有人员平级,统一向PMO负责人负责,利于PMO负责人获取一手准确的信息和高效的管理。
4.5 PMO成员要求及其带来的价值
PMO到一定阶段后需要增加人员,前面已经提到,增加的人员能力一定有要求,比如:公司项目平均规模为30人,那么引进PMO的人员最好管理过40人的项目团队。非常庞大的项目,PMO负责人可以介入,一般项目PMO成员都可以介入,这才能监管企业所有的项目。我们在实际工作中发现,项目经理对于组织外(有的甚至项目外)的人员介入非常抵触,一般第三方介入都是项目出现问题时,通常这个时候项目经理非常繁忙和紧张,认为外部人员的介入都是增加项目负担和尤其项目经理本人负担,如果PMO成员能力不强,基本无从下“嘴”,如果再按照审查的模式介入,项目经理的态度通常是婉拒或敷衍,结论是对第三方和项目本身都没有价值。
PMO团队及成员能力强,一方面在不打扰项目经理的情况下可以了解项目状况,通过数据分析及相关文档、邮件可以发现项目真实问题;另一方面,由于能力经验的因素,对问题提出一些解决方案或建议,更能得到项目经理认可。在这种情况下,双方第一共识是解决项目问题。PMO帮助了项目经理,项目的问题解决效率得到了提升,PMO自身针对项目的报告也会有价值(落地不空洞)。举例说明:我们的项目被客户投诉后,公司最高管理者通常第一时间找PMO了解状况,并要求PMO作为第三方,向客户提交一份报告。这说明两点,一是PMO要清楚公司各个项目的状况(尤其是高风险项目),二是PMO要代表公司说明项目状况和后续监管模式,以得到客户对项目可持续完成的信任。这种情况下,PMO的报告难度远高于项目报告。报告内容通常如表5所示。

表5 异常项目对客户的报告
备注1:所有的报告PMO负责人都需要参与其中,通常向客户报告时PMO负责人需要参与,报告过程中,客户现场的问题部分需要PMO负责人代表公司回答或承诺,不清楚全过程可能部分承诺将为公司带来不必要的损失。
能力一般的不可能写出一份让客户和公司满意的报告,通常这份报告的价值在于短期内平息客户的“怒火”和得到客户临时的信任,可以让项目经理有更多的精力投入到项目中(非实时应对客户),更快捷地让项目从异常变为基本正常或正常。
如果企业不愿意投入,只是做形式上的PMO,我的建议是不要建立组织级的PMO,一些单纯的信息收集工作完全可以由其他组织协助完成即可。
5. 是否愿意给PMO时间
PMO的完善是一个长期的工作,短期内要实现所有的价值,难度主要在两方面,一是PMO自身是否有能力完成相应的工作,能不能被各组织认可,二是企业内各组织各项目是否可以适应大量新的变化和要求。另外,一个完善的PMO需要一套系统的支撑,从组织可研、到系统建设、到各组织都能有效地使用系统,更需要花费较长的时间。
5.1 PMO开展工作的方式
PMO既要维持现有工作的开展,又要推进新的工作。PMO在开展新的工作时,需要先选择一些组织试运行,一个合理的试运行一般需要3个月时间,推广到全公司需要6个月及以上的时间。通常一个PMO成员可以横向监管的项目大致在30个左右(大小项目平均,如果都是大项目或庞大项目,数量将大幅缩减),所以每个PMO成员能用于开展PMO新业务的时间也是有限的,这就需要PMO将每件事落地后方能开展下一项,每年能新推出2~3项工作就非常不容易了。
我们的团队在接近10年的PMO运营过程中,推进完成18件工作的落地实施,基本每年推进2项工作,成员从1个人到后期超过10人。
5.2 核心项目管理系统建设
在公司的发展过程中,一直在建设一些小型的项目管理系统,但一般使用2~3年就放弃了,公司在规模达到一定程度后,计划建立一套适合公司的项目管理系统(至少支撑5年),整个建设周期达到了1.5年,先期的系统可行性(自建还是购买(外包还是购买现成产品)),最后选择内部研发的方式,需求调研、研发、上线(可研至上线1.5年)。选择几个组织试用3个月后,全公司在使用6个月后才全员稳定使用,整体时间超过了2年。系统建设占用PMO时间随着系统的建设、试用、推广呈上升趋势,直至稳定后工作量才有所下降。
当然,有系统后,对于PMO的工作开展有划时代的意义。一个大型企业,如果没有系统,PMO的工作开展大打折扣,收集各个项目的基础数据就能让PMO崩溃,同时大量数据的真实性无从考证。在系统的基础上,我们才成功地实施了项目全成本核算,做到了最初公司对PMO的要求(消灭赤字项目)的第一阶段。为了成本核算,项目管理系统和合同系统、财务系统、人力资源系统等实施了对接,合同、财务数据是公司的核心数据,PMO如何获取这些信息就是一件相对困难的事;另外,PMO要主导项目成本核算,如果财务部实施成本核算,项目经理将很痛苦(财务科目实在不明白),核算体系需要由PMO建立,如何将合同数据和财务数据变为项目经理“可识别”数据,如何实现各系统之间的对接,最终的测试也都要求PMO负责完成。成本核算真正实现离PMO建立已经超过了6年时间。也就是PMO让公司目标足足等了6年。
5.3 不坚持的PMO的业态
公司领导层的支持,对PMO工作的推进有决定性的意义。大部分企业在PMO开展工作1~2年后基本就放弃了,认为PMO不能帮助项目和公司解决问题。
一项面对全公司所有项目的工作的每一步推进,涉及的利益相关方都很多,很容易伤害或影响了某些组织的短期利益,工作必然会受阻,如果在关键时点高层管理者不支持,不进反退,最后只能不了了之,由于工作没实现,负面的评价一定针对PMO。只要发生了几件推进不成功的状况,尤其是连续的,PMO的命运可想而知。
在上述影响下,很多公司的PMO“成功”地变为“消防队”,PMO仅仅预留几个能力较强的项目经理,什么项目出问题了,充当“救火队员”,其实这种方式在一些中小企业有一定的生存空间,但对于大型企业效果不大。还有一些公司的PMO逐级变为数据统计部门和“官方”审计部门,被公司和项目边缘化。这种边缘化PMO企业不得不实施“美工”,宣称在公司PMO做了很多有价值的工作,对项目经理的支持力度很好,各项目在公司PMO的统一要求和监管下,稳定健康地运转,客户完全可以放心。其实了解这样的PMO,只需要和项目经理沟通一次即可,PMO给企业带来了什么,只有企业的管理者知道。
总结
综上所属,企业是否拥有PMO,组织模式不重要、项目种类是否繁多不重要、组织的复杂程度不重要……,重要的是目标、定位、最高管理层的支持、资源投入和长时间的坚持。
参考文献
[1]PMI.项目管理知识体系指南第六版.北京:电子工业出版社,2017.
[2]PMI.组织项目管理成熟度模型第三版.北京:电子工业出版社,2015.
[3]PMI.组织级项目管理实践指南.北京:中国电力出版社,2015.
4德拉甘.Z.米洛舍维奇.项目、项目集和组织级项目管理案例集.北京:电子工业出版社,2013.
[5]PMI.组织变革管理实践指南.北京:中国电力出版社,2014.

PMO评论特约作者:谢二菊
1998年毕业于哈尔滨工业大学,曾参与软件开发设计;作为项目经理管理项目,项目团队超过40人;为建立CMM规程并实施、帮助企业通过5级认证;作为企业事业部质量经理管理质量工作;2005年起为企业建立PMO,并持续运营近10年,对企业PMO的建立和运营有深层次的理解和落地实施,期间在大连为相关组织和企业分享PMO经验,得到广泛认可;为企业建立咨询部门并作为咨询总监开展咨询工作;2016年6月加入丹露成都网络技术有限公司担任CTO,全面负责公司研发工作的开展。
认证:PMP(Project Management Professional);CSM(Certified Scrum Master);TTT(Training the Trainer to Train)
其他:电子科技大学智慧城市研究中心客座研究员;2018年度成都市新经济百名优秀人才。

您的企业适合拥有PMO吗?——《PMO论文集(2019)》(电子版)相关推荐

  1. 对于软件价值管理的思考--《PMO论文集2019》(电子版)

    原创:PMO评论 特约作者:胡乔治 摘要:传统项目管理,无论是典型的软件销售服务公司,还是互联网软件公司,在过程管理中,通常是从需求输入开始.这当中造成的误判范围.过度承诺.信息传递变形甚至信息黑洞的 ...

  2. 结合CMMI体系的PMO组织建设研究--《PMO论文集2019》(电子版)

    原创:PMO评论 特约作者:徐立力 **摘要:**近年来越来越多的企业开始建立PMO,来帮助企业更好地管理单项目.项目集.项目组合.作为一个初创的PMO,如何可以更好地展现其价值,实现其应有的职能,为 ...

  3. 数据中台选型必读(三):什么企业适合上数据中台?

    数据中台虽然已经在口碑上跌下神坛,甚至一些企业开始拆中台.但是,笔者在客户咨询过程中经常遇到一种情况,企业仍然喜欢打着"数据中台"的名义沟通项目需求,但背后的需求很多时候都是数据统 ...

  4. 如何在大型商业银行研发中心发挥PMO作用--《PMO论文集2019》(电子版)

    来源:原创 PMO评论 特约作者:周建国 摘要:面对当前国际金融市场的激烈竞争,以及计算机.大数据等技术的飞速发展,科技引领金融业变革,加速金融现代化进程已经成为必然趋势.国有大型商业银行为了顺应时代 ...

  5. 安徽省16市什么企业适合做知识产权贯标申报好处和什么材料汇编整理

    安徽内的企业包括以下16个市的企业怎么知道自己是不是适合做知识产权贯标呢?那么申报知识产权贯标有什么好处,政策是什么呢?申报材料和申报流程步骤又是什么呢?那么来看看小编整理的项目资料,相信对你会有所帮 ...

  6. 微信小程序和微信商城的对比,看看你的企业适合做微信小程序还是微商城

    什么是微信小程序 微信小程序是一种不需要下载安装即可使用的应用,它实现了应用"触手可及"的梦想,用户扫一扫或者搜一下即可打开应用.也体现了"用完即走"的理念,用 ...

  7. OKR案例分析,哪种类型的企业适合OKR?

    OKR是整个企业紧密联结起来的重要工具,也是一种企业.团队.员工个人目标设定与沟通的方法与实践,同时,还能促进全员思考,形成员工与团队协同工作的思维模式. 从英特尔到谷歌,OKR都是作为全员使用的目标 ...

  8. 什么样的企业适合建设中台

    上一次我们分享了企业为什么建设中台.以及中台的分类.这次我们来讲讲什么样的企业才需要建设中台,中台的建设涉及到组织架构的调整和人力资源的分配,有些公司没必要,也不需要做中台,而有些公司做中台可以大大提 ...

  9. 什么样的企业适合做响应式网站

    响应式网站设计是一种网络页面设计布局,其理念是:集中创建页面的图片排版大小,可以智能地根据用户行为以及使用的设备环境进行相对应的布局. 简单来说就是可以在pc.手机.平板和终端可以自动适应屏幕尺寸显示 ...

最新文章

  1. Python错误:AttributeError: 'generator' object has no attribute 'next'解决办法
  2. c#获取DataTable某一列不重复的值,或者获取某一列的所有值
  3. linux shell脚本写法,linux: 常用shell脚本写法
  4. Dart微基准测试第一部分
  5. Word Count作业
  6. php提交表单处理,PHP表单处理
  7. 选择编程语言前需要知道的事
  8. php权限无需验证的控制器,Thinkphp6用中间件实现多个控制器判断用户登录权限
  9. Visual Studio 创建C语言项目
  10. 【Android 逆向】APK 加壳脱壳现状 | 判断 APK 是否加壳 | APK 逆向流程
  11. Scheme语言基础之数据类型
  12. 外币兑换c语言编程,货币转换 C
  13. DustBot机器人
  14. PHP MySQL 连接数据库
  15. 店外营销吸睛,店内体验升级丨餐饮品牌如何「吃」透数据?
  16. 【React】React介绍环境搭建
  17. 打入客户内部做销售1
  18. 诺基亚安卓手机_神速!HMD公布诺基亚手机安卓10升级计划
  19. eai java实现,月光软件站 - 编程文档 - Java - 建立EAI方式与SAI方式之间的通信
  20. 利用燃尽图跟踪迭代开发进展

热门文章

  1. Unity插件NGUI制作血条--HUD的基本使用
  2. 我的世界java怎么玩起床战争_教萌新如何在我的世界起床战争获得胜利攻略
  3. 【FPGA基础】基于PWM脉宽调制的呼吸灯设计(Vivado)
  4. Java NIO Introduction
  5. Linux常用的shell命令汇总
  6. Fast and Scalable Adversarial Training of Kernel SVM via Doubly Stochastic Gradients
  7. Linux运维的必备知识和素质
  8. windows-动态端口问题
  9. 2021 ICPC Asia Regionals Online Contest (II) Problem G. Limit
  10. 重读《C primer plus》(四)