在公司发展过程中，最看重的往往是收入和发展速度。在公司几个人、几十人、几百人、几千人、几万人（如果是更牛的公司，可以把这个排列继续延续）的发展过程中，没人在开始阶段就重视公司的项目管理。因为这个阶段团队规模还小，项目数量和规模都不大，只要齐心协力就能把事情做好。

但随着公司的发展壮大，人多了，项目多了，项目规模变大了。再靠着一腔热血去支撑发展就不太可能了，项目管理方面存在的问题也会逐渐暴露出来。

本文和大家一起看一下那些曾经在项目管理中出现过的问题，如果你的公司正在高速发展，不妨看一下。也许它能帮助你少掉些坑，少走些冤枉路。

1.1.1.1过度偏重理论，不符合实际的项目管理制度

在很多时候，企业对项目管理的了解并不深刻。项目管理更多是在项目出现危机或者频繁出现问题时，作为问题解决或者补救工具出现的。在这样的背景下，项目管理很少有机会能发挥作用，也不会得到高层的支持，并作为一个系统的工作来做。

一般来说，企业遇到项目管理方面的问题多半不会马上去招聘专人进来，更多的是靠企业内部的现有人员来解决。这个时候靠什么呢？都是有丰富经验的人，找一些理论支撑一下，先搞一套项目管理提升方案出来吧。找什么呢？PMP、CMMI、敏捷开发等知识理论，以及一些大企业的成功案例。不管怎样，这些是大家都认可的，整合到我们公司来，对我们的项目管理进行一下改善应该没问题，于是一套高大上的理论便提出来了。

执行的问题不重要，重要的是这个方案一定要全面，一定要高大上。方案提出来，执行肯定是没问题的。

但是，这套高大上的理论往往缺乏对自身组织的详细调研和问题分析。真正到执行的时候才发现，这是一套完全不符合公司项目管理特征的蹩脚理论。其结果就是，在大家的不断吐槽中慢慢的变成一段回忆。

在读MBA研修班的时候听过过这样一个经典案例，有一个企业家同学，公司规模不大，但发展势头良好。照这样发展下去，也许不能发展成巨头，但慢慢发展还是没问题的。但是这位老板太追求进步了，于是进入了研修班学习，整个学习过程可以说是收获满满。毕业之后心潮澎湃，感觉自己的企业上市敲钟指日可待。那些巨头成功的奥秘自己已经掌握，那无限的荣光即将属于自己。

于是，开始在企业内部大规模的改革。一年后，效果立竿见影，企业倒闭了。为什么呢？因为改革的举措太多，实在超出了企业的承受能力。在这里只举一个比较引人深思的：100多人的公司拆分成8个事业部，然后就没有然后了。能做出这样的企业变革不能说理论不正确，只能说教条主义害死人啊。

这是个公司变革的案例，但其中蕴含的道理同样适用于项目管理。如果过分崇尚项目管理的理论，而不能灵活应用，最终的结果很可能是适得其反。但这绝对不能说是项目管理理论的错，因为理论本没错。问题出在错误的时间，错误的地点，用在了错误的人身上。

1.1.1.2在公司里推行一套统一的流程、方法、规章、制度和工具

很多时候，我们会有意无意的走入“过犹不及,余犹不足”的怪圈，要么没有，要么就在公司里推动全员执行一套统一的项目管理体系。

但是公司里真的所有项目都具有相同的特征吗？比如：项目规模、项目复杂度、项目风险、以前是否做过类似的项目、项目的优先级、战略定位等。如果对于不同特征的项目，你都能用同一套管理流程、方法、规章制度搞定，只能说，你是相当生猛了，因为搞定项目的背后可能是无数兄弟的血和泪。为什么这么说，我们来分析一下。

按照一般的思路，如果制定项目管理体系，一定是以规模最大的项目为准的。这一方面是因为大项目无一例外的在公司里享有VIP待遇，受重视程度不用多说；同时还有一个大家普遍认可的理论，大项目都包进去了，支撑小项目肯定没问题的。

但是这样的想法就害惨了那些小项目，本来合同金额也就10几万，公司投入的资源又有限。现在为了应付各种流程、文档占据了一大块资源不说，这些工作对项目本身的意义又不大。可以说是无聊无趣又没有价值，于是没事的时候就吐槽这些规则的制定者脑袋短路，脑袋进水。各种流行的词汇往这些人身上招呼，只有一个目的，感慨这些人能制定出这样的改进方案。

可又没有更好的办法，该执行的还是要执行。痛苦归痛苦，总还能坚持，但是一个个项目都在浪费公司的资源就着实有点可惜了。

1.1.1.3为管理而管理，增加管理成本，降低工作效率

项目的失败有千万种原因，但有一种是最奇葩的，项目经理过于专业了。当然了这个专业是要加引号的，过于专业的项目经理，会不自觉的忽略掉组织的战略、文化以及项目本身的特征。忘记了项目管理的核心目标是以更高的效率，在计划的范围内，保质保量的交付客户满意的产品。

这样就麻烦了，基于项目经理已有的经验，要求项目遵循一些毫无价值的流程，输出一些毫无价值的文档，开一些没有实际用途的会议。项目经理成功的成为了项目搅局者的角色，项目的效率更低，团队的积极性被严重破坏，产出物变得更不可保证。

笔者之前经常问自己一个问题：究竟什么样的项目管理才是有效的项目管理呢？寻找这个答案的过程也成为我到目前为止职业生涯的缩影，我想这个过程还会继续下去。因为环境在变、技术在变、市场在变、从业者在变，所以项目管理一定也会是在不断变化中的。

成为一个优秀的项目管理者不能一蹴而就，需要一个长期的积累过程，我们按年级的方式来了解：

小学阶段，这个阶段的项目管理者因为理论知识的匮乏，会倾向于读大量的书籍。感觉只要有足够的阅读量和知识积累，就可以成为一个优秀的项目管理专家。在了解了一些基本的理论后，会非常乐于把所掌握的知识应用到项目中去，但是结果往往都不尽如人意。这些时候往往认识不到自己的不足，更多的会觉得是组织的执行力以及项目管理知识欠缺。自己往往会找到一种知音难觅，怀才不遇的感觉。随着时间的推移，这种认知会慢慢发生变化，伴随这个变化我们进入初中的学习阶段。

初中阶段，最重要的认知是理论联系实际。慢慢认识到理论其实没有对错，关键看是不是能满足组织项目管理的需求。这个阶段开始关心公司项目管理中出现的问题，开始基于问去找能解决问题的理论和方法。在这个阶段如果作为项目经理，对所负责的项目是能够很好管理的。但是还不够，如果要做到能帮助公司项目管理水平的整体提升，还需要更进一步的学习，接下来我们进入高中阶段的学习。

高中阶段，最重要的进步在于归纳总结能力的提升。已经对项目管理有了更深层次的认知，可以从不同的项目中，总结归纳出适合公司各种项目的项目管理方法和知识体系。在这个阶段，可以自豪的说，自己是一名优秀的项目管理从业者了。但是距离最顶端的水平还有一定的距离，接下来我们进入下一个学习阶段，大学阶段。

在大学阶段，项目经理将完成最后一个阶段的学习。这个阶段要学习的是战略思维和领导能力的提升。在这个阶段除了关注项目外，还要关注公司的战略思维，懂得将战略变成可落地的项目计划并运用你在低年级学到的技能落地执行下去。在这个过程中，需要具备一定的领导能力。因为战略有了，计划有了，还需要一定的领导能力，来和大家一起把项目干出来，最终完美落地。这个阶段需要你用更广阔的视野去了解项目管理之外的更多的知识和技能，需要懂得更多为人处世的技巧。但要达到事业的顶峰，你还需要继续努力，因为只有到了这个阶段，你才能真正达到游刃有余的境界。

研究生阶段，恭喜你离行业大牛又近了一步。在这个阶段你将达到见招拆招，无招即有招的境界。项目已经深入你的骨髓，在你的脑海里再也没有PMP、CMMI这些理论，但是具备一样看穿问题本质的能力。具备更强大的行业理解能力、技术理解能力，以及对项目群进行组织管理，支撑战略的能力；具备对外战略宣讲，沟通谈判的能力；具备行业与技术相结合，进行创造性思考的能力。

好了，到了目前为止，恭喜你成为了一名优秀的项目管理从业者了。

接下来我们看一个案例，来了解一下项目经理如何在实践中快速成长起来。我们从下面的图片开始，不明白这个图片的意思没关系，接着往下看你会明白的。

A公司最近几年发展的不错，业务量以及公司的人员规模快速攀升，终于在人员规模扩张了5倍业务规模扩张了10倍后，一些积蓄已久的弊端逐渐显露出来。一个很直接的问题是，公司对项目的把控能力越来越差，具体表现为：第一，没有能力承接快速成长的市场带来的更多项目；第二，对于已经承接的项目没有办法保证交付进度和质量；第三，职责分工混乱，各职能部门的员工沟通成本高。大量的时间被各种会议占据，本职工作只能在下班后加班完成；第四，对项目过滤没有可量化的标准，很多性价比高的项目被放弃，很多发展前景不好的项目被提上日程。第五，项目的盈利能力越来越差，虽然项目数量在持续增加，但是最终产生的净利润却没有明显增长。最重要的是，公司没有了之前努力拼搏的劲头，大企业病逐渐显现。

经过首席执行官的会议沟通，大家一致决定，成立PMO，提升公司的项目管理水平和项目盈利能力。经过了数轮的筛选，最终剩下两名候选人。简单来说，一个是具备丰富PMO从业经验的大牛，另一个是在小公司里混过各个岗位但没有PMO经验的菜鸟。最终公司做出了很符合常规的选择，选择了那个具备丰富PMO经验的大牛作为PMO的经理。我们称这个大牛为小A同学。好了，背景已经交代清楚，小A同学开始你的表演。

作为有着丰富PMO经验的小A同学，自然信心满满，工作马上展开。

1. 小A制定了PMO工作计划，推出了PMO模型，并最终选择打造教练型PMO。
2. 小A继承了之前工作中选用过的信息化系统，并制定了信息化系统推广计划。虽然本次的实施背景与之前的会存在一些不同。之前的PMO主要是管理内部研发项目，本次更多的侧重于对外项目。但这些对于小A来说，完全不是问题。
3. 小A制定了项目管理规章、流程、方法、制度等，当然也是吸收了之前几份工作中的成功经验。
4. 以上都具备了，但是如何在组织内推广，也是极其重要的事情。所以小A把培训也纳入了日程，制定了计划。

接下来小A招聘了项目经理，来负责公司中规模比较大的重要项目，并在前期取得了不错的效果，同时在公司中推广使用信息化系统。

但几个月过后，逐渐出现了问题，相对于PMO负责的几个重要项目，其他部门的问题并未得到有效解决，而且产生了一些新的问题。比如：人员职责依然不清晰，沟通成本仍然很高；信息化系统缺少灵活性，因为和之前的应用场景不一样，无法对现有业务进行有效支撑，甚至给大家带来了更多的工作量；大家对信息化系统的使用不规范，项目数据填报的不及时不规范，无法形成有意义的指导数据；所有的部门都觉得优化项目管理是在为其他部门做贡献，服务于其他部门的管理，未对本部门的工作带来任何提升和便利。

小A试图改变这种局面，他花更大的精力去培训，但后来参加培训的人越来越少。他花更多的精力去推广信息化系统以及项目管理方法，但是信息化系统的应用仍然混乱。他努力去向大家解释，组织流程优化是个长期的过程，但是没有人相信。简直没法沟通了，在A公司，小A遇到了前所未有的挑战。与其说是自己的问题，他更愿意相信这是因为A公司的人项目管理知识匮乏，没法建立有效的沟通。在入职满一年的时候，小A离职了。

小A的离职说明了A公司试图建立PMO的尝试失败了。接下来如何处理，就此放弃还是继续尝试呢？如果就此放弃，显然有些对不住小B同学。从上次求职失败到现在已经一年多了，是时候到小B同学上场了。

小B同学采取了和小A同学不一样的策略，从根本认知上，他不把PMO看做自己的地盘。他的理念是PMO服务于公司各个部门，PMO的建立应该重点考虑各个部门的需求，而不是制定规则要求其他部门照章执行的独立部门。好了，下面开始小B同学的表演。

1. 组织会议，收集公司当前存在的一些急需解决的问题。并对这些问题进行优先级排序，找出最重要的三个问题，纳入立即解决的范畴，将其他问题排在后续的处理计划表里。
2. 将待解决的问题转化为可以量化的目标，并纳入年底对PMO的绩效考核范围。
3. PMO的部分项目经理负责规模较大，对项目管理的专业化要求比较高的项目，其他项目由客户经理自己负责。PMO成员负责项目管理支持，并从客户经理那里获得过程改进的建议。这同时解决了两个问题，提高了预测的准确性和对项目的把控能力，同时提升了公司对更多项目的支持能力。
4. 为了达到对PMO工作的有效推动，为首席执行官配备一名专员，用来促进相关事项的落地能力以及提升公司整体对项目管理的理解能力，毕竟老板作为榜样的力量还是相当强大的。
5. 在PMO开展工作早期，为了促进信息系统数据的规范和准确，配备一名专员，协助管理项目信息的录入工作，保证项目信息的完整和准确。这就有效解决了第三个问题，项目信息的共享和同步问题。

好了，没有那么多深奥的理论，没有那么多现成的经验助力，小B同学就这样走向了成功。不但解决了公司最为关键的问题，而且有效提升了PMO的人均单产。

我们本节内容也告一段落，这里得到的最大启发简单而直接：任何部门和组织的建立都是为了解决问题而诞生而不是为了给人添堵而诞生；理论和经验都不重要，解决问题最重要；市场不会给公司太多的时间去推出最棒的产品或服务，同样公司也不会给内部组织很长时间去慢慢做好。

1.1.1.4过早采用与企业不相适应的信息化管理工具

对于项目管理，很多人有一种简单直接的理解。花点钱上一套系统就解决了，但是真的是这样的吗？很显然，这是一个很乐观、天真的想法。

因为项目管理系统无法帮助整个团队项目管理技能得到提升，无法自动理顺公司的业务流程，无法解决沟通问题，无法自动识别风险，无法让任务分解更合理，无法让计划更有落地性，还有很多很多无法解决的问题。用一个比喻来说，就像武侠小说里的高手过招，武器绝对不是锁定胜负的绝对因素，真正决定胜负的是过招双方的武功修为。

项目管理要想成功需要的是全体成员项目管理水平的不断提升，一个团队的成员如果对项目管理都有一个正确的认知，那么即使用Excel表格也能管好项目，只是效率低一些而已。

如果整个团队缺乏项目管理的整体技能，项目管理系统最终会变成记录项目如何失败的备忘录。除了花了些钱以外，还有一个作用就是让项目组成员花更多时间来维护这套系统。维护系统的目的不是更好的完成项目，而是不被扣分，为了拿到更高的绩效。

1.1.1.5在不具备虚拟团队的管理能力时，建立虚拟团队

现在很流行虚拟团队、部署分布式组织。这可能是因为市场拓展的原因，可能是因为需要更接近客户的原因，可能是因为成本的原因。原因多种多样，我们这里不再列举。

在建立这样的组织前，建议考虑一下这几个问题：

1. 公司各部门及成员间是否已经配合的非常默契？
2. 公司的流程对虚拟团队的情况支撑如何？
3. 项目虚拟团队所做的各部分工作之间耦合性如何？
4. 这样的项目组沟通真的没有问题吗？
5. 频繁出差带来的支出足以覆盖虚拟组织带来的成本节约或者经济价值吗？

如果这几个问题的答案都是OK的话，那么我们可以试试。否则，不要轻易尝试。相对于电话和出差见面，面对面的沟通可能效率更高。空间带来的距离感，当前的技术水平还完全无法逾越。在沟通问题时，你看不到他的双手是在握拳还是手舞足蹈；你无法看到他对你发言的真实反馈；你看不到他离开会议室时的状态；你更无法和某人在会议过后针对某问题在咖啡间里进行一次面对面的交谈。即便是谷歌这样的公司也不行，否则怎么会在设计办公室时都尽量创造不同部门之间偶遇交谈的机会呢？

当然如果公司具备优秀的管理文化和良好的沟通氛围，或者项目本身有强烈需要，虚拟团队也许是个不错的选择。

最后我们看一个简单的案例，小A公司是做运营商内部支撑系统以软件开发为主的公司，采用偏重职能部门的组织架构。在西部某市设置有研发、测试相关部门，在南方某市设置有财务部门和产品研发中心，在北京设置有行政部门。当各个省接到项目后，本地成立办事处，但因为没有后续的项目保障，不会在本地大规模招聘，只招聘需求调研及设计人员，作为与研发部门和客户沟通的中间桥梁。研发同事会在项目初期出差到当地省份，与新招聘的同事及当地客户进行沟通，然后回到部门所在地开始异地项目开发。

在公司的层面来讲也许是不得以的选择，但这样的模式还是很快暴露出如下问题：

1. 因为不了解，研发同事对现场同事缺乏信任。对现场的设计工作不认可，双方经常因为设计而进行远程沟通，争论得不可开交，充满火药味，严重影响了项目进度。
2. 现场同事觉得研发同事没有用心做事，对研发进度不满意。
3. 基于语音会议沟通结果的理解经常出现偏差，到结果交付时，现场同事才发现这个结果不是客户需要的。双方互相推诿，一个觉得是对方表达有问题，一个觉得是对方理解有问题。
4. 对设计文档的要求越来越苛刻，对一些显而易见的要求也要完全再描述一遍，一个简单的需求设计稿现场同事也要修改好多遍才能被研发同事接收。很多时候现场同事觉得描述已经非常清晰了，研发同事还是觉得有问题。问题已经超出了文档本身，完全是相互之间的信任问题。
5. 通过语音的沟通方式效率比较低，沟通频率也不高，导致越来越多的理解偏差和对彼此的更多抱怨。
6. 项目整体把控困难，在客户现场的项目经理，得到的研发进度统计不准确。经常是在一切正常的情况下，在任务要交付成果时，被告知无法完成了。
7. 因为缺乏信任，一切以邮件为准。没有邮件，哪怕一丁点工作也无法有效推动。
8. 项目任务出现延期，大家都在互相埋怨，没有人觉得问题出在自己身上。
9. 经常出现的进度和交付质量问题，让客户非常不满意，多次进行投诉。

按照这样的节奏下去，项目的利润不用说，这个项目能否正常交付都成问题了。公司管理层经过多次协调未果后，决定成立本地团队，尽快完成这个项目，并对本地团队的组成提出如下要求：

1. 本地团队的招聘以经验丰富的人员为主，控制团队规模。在提升个人产出的同时，提升项目质量。
2. 加大在本地的客户挖掘力度，争取更多项目。本地项目由本地团队负责，达到本地项目有效支撑本地团队的目的。

在经过团队本地化后，项目状况终于有所改善。客户满意度慢慢提升，最终虽然有一定延期，但是项目还是顺利交付了。

好了，以上是组织流程和制度制定方面可能会出现的问题。感谢你有耐心坚持看完，下篇文章我将继续分享关于项目执行过程中会出现的问题。

如果你觉得对你有一点帮助，就点击关注吧！