不知不觉，在项目管理这个小圈子已兜兜转转10多年，一直冲锋在项目第一线，财富没积攒多少，经验倒是积累了一些。本文将和大家分享在项目执行过程中可能会出现的一些问题，将包含如下内容：
- 没有拿到客户对方案的明确表态即开始项目，被客户牵着鼻子走。
- 只管满足需求，却没有看到需求的本质。
- 对客户过度承诺，牛皮吹起来，做不到再想办法。
- 缺乏与客户的主动沟通。
- 隐藏或者拖延项目中存在的问题。
- 过于迷信文档，团队内部缺少主动沟通。
- 在领导破坏规则时，项目经理容易妥协。
- 树立项目中的超级明星。
- 整个项目在集体信念中丧失理性，决策缓慢。
- 僵化的项目管理体系，缺乏有效应对变更的机制。
- 项目管理方法体系落实不到位，缺少宣讲和沟通。
- 高层管理者游离项目管理体系之外。
- 已经注定失败的项目，没有有效的离场机制。
- 方法体系的执行缺少有效的监督和奖励机制。
- 有限的资源承担过多项目，一个人同时做多个事情，效率低下。
1.1.1.1、没有拿到客户对方案的明确表态即开始项目，被客户牵着鼻子走
在项目交付之前什么也不说的客户
我们可能都遇到过这样的客户，沟通需求的时候，什么也不说；确认方案的时候，完全没问题；项目进行过程中，也完全信任，一切都好，态度那叫一个和蔼，相处那叫一个融洽。如果不出其他问题，感觉这个项目离顺利交付指日可待了。但现实会告诉你，天上不会掉馅饼，这么容易搞定的客户基本没有。
出现这种现象的原因无外乎如下几种：
1、这个项目在客户那里并不急迫，他有更重要的事情要做。通俗点来说，没时间搭理你。
2、这是个不愿意思考的用户，没有在结果出来之前思考产出物会是怎样的习惯。
3、自己对项目的交付物也没什么概念，等着你给出理想的逻辑和方案设计呢。
相比这样的客户，我更愿意接触的是，从开始就不断提出各种问题，对前期方案不断提出反馈意见，对交付周期不断提出要求的客户。有了这些不断的碰撞，项目在后期出现整体交付风险的几率就会小很多了。原因很简单，客户从一开始就参与进来了，而不仅仅是做一个交付成果的验收者。
所以，如果对项目前期的一切顺利喜出望外，那么后期项目的发展就只能自求多福了。当我们按照没有问题的节奏来继续项目时，现实很快会以一种很严酷的方式告诉你，兄弟，你太天真了。
接下来的戏码多数是，客户针对产出提出各种问题，然后对问题进行修改，修改后又出现问题，然后就是再提，再改……。这是很多项目经理熟悉的感觉，噩梦，绝对的噩梦。这些无休止的调整，很快让待交付的系统变得千疮百孔，甚至前后矛盾。所有的范围管理、进度管理、成本管理、质量管理全都形同虚设，项目进入痛苦的焦灼状态，整个项目组身心疲惫。
所以无论如何在项目正式投入资源开发前，一定要真真正正了解到客户的本质需求，得到客户的认可。这种认可不是求得心理安慰的简单点头认同，而是建立在客户认真参与进来，对项目交付物有了完整认知基础上的一种承诺，这种承诺可以通过签字等方式确认下来。
1.1.1.2、只管满足需求，却未看到需求的本质
直接给馒头不是更好吗？
如果你的工作方式是记录下客户的需求，进行整理，然后形成解决方案。那么可以确定你不是一个合格的需求调研员，不是一个合格的设计师，也不会是一个合格的项目经理。对，什么都不是，你需要进步和提高。
就像上图描述的一样，当客户需要两块钱的时候，我们最好弄清楚他为什么要两块钱。如果我们的客户需要两块钱去买馒头，这个时候和客户说清楚，我们可以直接提供一个馒头而不需要他再去跑腿买馒头，相信客户会觉得你更专业。当然进步没有止境，如果能进一步弄清楚客户为什么吃馒头而不是米饭，那么恭喜，你在专业的道路上更近了一步。
作为一个合格的项目经理，肩负着同样的职责，需要知道客户提出这个需求的真正痛点，然后漂亮的把这个痛点解决掉，这才是专业的做法。我们需要做到了解客户的整个业务逻辑，当客户提出一个需求的时候，知道这个需求是要解决什么样的业务问题，是否有更好的解决方式，这个需求是否合理，是否会带来与其他业务逻辑的冲突，是否会为后续系统开发带来变更的风险。
所以当客户提出变更的时候，不要抱怨。多想一想这里面是否有我们的原因，我们是否认真系统的思考过客户提出的需求。也许你会说，客户的需求客户应该自己想清楚。但是一般来说，除非专业和愿意思考的客户，他们多半都不会自己把需求系统的想清楚，整理出来，按照规范的格式交给我们。今天一个问题，明天一个想法，这就是他们的一个正常状态。
对于经常出现的变更，他们不会觉得是自己的问题。而是更多的觉得作为专业选手，你和你的团队没有提出专业的系统化建议，什么都要他们自己去想，自己提出来，这是不专业的表现。
笔者经常读一些历史书籍，每每惊叹于那些驰骋沙场，运筹帷幄的天才将领们。他们为何如此厉害，总是能先于对手预判到对手的行为。除了天赋异禀对战场天生的敏感外，一个很重要的共同点是，他们都准确的抓住了战争最本质的东西，包含：地理因素、时间因素、敌我双方的实力对比、对方将领的特点等。综合考量这些，是他们战胜对手最重要的原因。掌握同样的信息，能分析出多少，准确性有多高，那就实实在在和自身的能力以及经验相关了。
所以，在心里问候客户多事的时候，想想是否是自己出了问题，这才是解决问题的关键。这也是为什么同一个项目，有的项目经理能应付自如，而有的项目经理则被折腾得苦不堪言的重要原因，同时这也是判断项目经理能力如何的一个重要因素。
1.1.1.3、对客户过度承诺
吹不吹牛不重要，拿下项目才是关键
为了拿下单子，把牛吹上天，只要客户提出的无论是技术问题、进度问题、甚至价格问题，全都不是问题，先拿下项目再说。虽然这样的描述有些夸张，但对客户过度承诺的确是一个客观存在的事实。
针对这样的问题，我们无法给出一个对或者错的答案出来。但是从企业长远来看，这种做法不值得提倡，如果吹牛过分，而实现不了，还会给公司惹上麻烦。
作为项目经理，负责项目的具体落地，对客户的承诺就更要客观、真实。客户是上帝，但是当上帝提出的需求我们无法做到时，早说比晚说好，说了比不说好。否则当自己作出的承诺无法兑现，自己吹过的牛皮被捅破时，对上帝的尊重就变成了忽悠。可上帝不是礼拜天，让你随便忽悠随便过的，如果上帝很生气，后果是很严重的。
1.1.1.4、缺乏与客户的主动沟通
不愿与客户沟通的项目经理
很多项目经理都相信：没有消息就是好消息，如果客户不找，就决不自己主动去找麻烦。这有两方面原因：首先，因为沟通并不是个性价比很高的买卖，相比之下坐下来多写两行代码，多写点设计，多解决几个问题，更划算。其次，项目中遇到进度、技术、质量等问题，就更不愿意主动沟通了。
这个理论貌似没错，但如果真的这么操作就会发现问题了。首先，相关方没找，不证明他们对项目不关心，也不代表项目没问题。相反，很多问题都是在沟通中提前暴露出来的。其次，如果项目真的出了根本搞不定的问题，这些问题也不会因为不沟通而随着时间的推移自己消失，最终会被相关方知道的一点也不会少。而且客户越晚知道，对项目带来的危害越大。
基于多年的经验，客户的脾气不一样，也需要采取不同的沟通周期和方式。比如：有一些客户需要的是一种项目被重视的感觉，这样的客户就尽量增加沟通频率，给他的感觉是，项目组24小时都在为他努力工作；有的客户不在乎形式，但是关注项目，这样的客户需要把项目的关键信息定期沟通同步即可；有的客户不关心过程，巴不得你一直不找他，但他是项目的关键相关方。这种情况下，还是要定期同步信息，但是要尽可能简明扼要。总之，客户有很多种类型，，但不管哪种类型，定期的沟通都绝对不能少。
如果不定期沟通，就可能会出现如下问题：
- 乐观地客户会认为既然项目没找他，那么肯定是一切顺利在朝着预期的目标正常前进。在这种你好我好的氛围中，到了项目交付成果的时候。这个时候如果项目出了问题，给客户的挫败感是可想而知的。
- 关注细节和过程的客户会变得焦虑，觉得项目失去了控制，项目变成了一个黑盒。作为项目的甲方，他们没有得到足够的重视。虽然项目组一直在努力，但是客户并不知道。
这两种结果对项目经理来说，都不是什么好事。客户的焦虑会转化为对项目组的不满，而这种不满可能是吹毛求疵的直接原因。遇到急脾气的客户，直接投诉到公司里，就更是麻烦事了。辛辛苦苦埋头工作，一抬头被投诉了，你说冤不冤。这个时候不要怪客户多事，要怪就怪自己不愿沟通吧。
笔者从来都不是个喜欢做点事情巴不得全世界都知道的人，但是太多时候，你不去主动沟通同步消息，别人就是不知道的。当全世界都不知道你这个大忙人在忙的时候，被投诉也没什么奇怪的了。
1.1.1.5、隐藏或者拖延项目中存在的问题
努力一下，这个问题应该可以搞定
无论你是多么彪悍的项目经理，以下这些现象都有可能会在项目中碰到：
- 1. 项目存在着明显的延期风险。
造成延期的风险可能是由于在项目早期未曾考虑到的技术问题，业务逻辑问题，范围的变更，不断出现的质量问题以及多个团队之间因工作配合默契度带来的效率问题等。总之，就是大家拼了老命也可能无法完成了。
- 2. 项目出现了无法逾越的技术问题。
做着做着发现，之前觉得没问题的方案，就是出现了无法逾越的技术问题。这些问题不但会拖长项目的工期，甚至可能变成一个无解的问题。这就麻烦了，本来承诺客户的东西，就是搞不定了，你说气不气人。而且这种问题就是可能会出现，搞得你完全没脾气。
- 3. 相关方的沟通出现了问题。
相互之间信息不同步，同步的信息理解不一致。同一个问题反复沟通，浪费了大把的时间，却始终得不到一致的结论。工作节奏配合有问题，前置问题影响后续开发。各个相关方都不觉得是自己的问题，但是这些会直接影响项目的整体进度。
- 4. 由于前期规划不周全，项目的整体方案存在重大缺陷。
在项目中最郁闷的事情莫过于项目进行了大半，突然发现整体方案存在重大缺陷。继续做下去方案不能满足项目的整体需求，停下来调整方案，项目进度会出现严重问题，这真是折磨人的事情啊。
- 5. 由于人员离职等原因，项目无法投入计划的人力资源。
人员离职是再怎么努力也无法提前预知的事情，作为项目主管总不能闲着没事拿个本子提前统计谁想离职吧。但是人员离职的确会给项目带来一些不确定性，本来说好的事情没人做了，要么去找公司申请新的资源，要么找客户沟通调整项目进度。要怎么做，兄弟你看着办吧。
面对这些问题，不同风格的项目经理会采取不同的措施，但基本会符合以下两种思路：
其一、将消息同步给相关方，尽快解决问题。
其二、采用一个“拖”字诀，只要问题还没彻底暴露，达到不可收拾的地步，绝对不主动沟通解决。
总的来说，采用第一种解决方式的同学可能在解决问题的过程中遇到一些困难。搞不好，会在短时间内成为客户、公司甚至团队内部的批斗对象。但是兄弟坚持住，风雨过后总会见彩虹。过了这一段，大家意识到，发脾气解决不了任何问题的时候，一起努力，问题总会得以解决。损失可以控制在最小的范围内，结果虽然不一定很好，但是也不会差到哪里去。
但是如果采用第二种方法的就不一定了，虽然能守得住暂时的风和日丽，但是当所有人都以为项目一帆风顺，没有任何问题时。在最后阶段你老兄突然站出来说，项目出问题了。这个时候大家满怀期待项目上线，准备投入使用。我们的甲方已经把牛吹得呼呼响，我们的老板等着收了尾款给兄弟们发奖金呢。你敢说项目出问题？都别拦着，看我不打死你才怪呢！
1.1.1.6、过于迷信文档，缺乏有效的沟通
只要文档，不需要沟通真的可以吗？
很多领导迷信一种说法，只要文档写的清楚，团队不需要太多沟通也一样可以把事情做好。同时做好文档还有两点好处：其一，出了问题，要有文字资料可以追溯，来找到问题的原因。其二，可以有效的形成项目积累，万一哪个兄弟不想干了，后面的人也可以更方便的让项目继续下去。同时，有类似的项目开工时，也可以拿前面的项目做个参考。这想法本来挺好，但是万事都有个度，当对文档的追求过了度就会出现如下现象：
大量时间都被用来写文档。大家憋着劲不沟通，因为公司倡导以文档为准，因为沟通完了还是要写文档，而且需要10分的文档，写成9.9是不行的。一年下来，公司业绩怎么样不说，写作能力大有长进，这也算是一个副产品吧。但是会带来如下问题：
第一、忽略沟通的作用，企图写出所有人看了都不会产生歧义的文档。
这就苦了写文档的同学，要知道，如果一个需求很复杂，面对面沟通都未必能说的清楚。单凭文档让所有人达成一致意见，简直太难了。要知道，设计同学往往都不是写作方面的高手。于是乎，文档写到吐都未必让大家都满意，这真是一个苦差事啊。
第二、文档用来追溯问题的初衷变成了寻找背锅侠。
一切以文档为准，没有文档啥也进行不下去。因为一旦项目出现问题，是要通过文档追溯原因的。追溯来追溯去，事情就变了味道，从解决问题变成寻找背锅侠。于是大家对文档变得相当重视，因为万一哪天兄弟我有事情说不清楚，拿出文档来，就可以证明本人的无辜了。
第三，团队缺少活力和创新能力。
在对写作事业的执著追求中，团队的热情和创新能力，受到了毁灭性的打击。一篇篇不断修改的文档，像凉水一样，把所有的热情浇的拔凉拔凉的。
第四，组织里缺少信任。
正所谓，不信兄弟信文档。不管什么事情，拿文档来，管你平时关系怎么样，没文档不干活；管你事情大小，没文档不干活；管你客户重要不重要，时间紧不紧，没文档不干活。
综上所述，在项目中，沟通还是非常重要的。为了了解沟通的重要性，我们来分享一个案例：
A同学是鹏展公司一名智慧城市系统的资深开发工程师，在这个岗位上，他已经工作了10个年头，毫不夸张的说他就是公司这个领域最牛的人。所以很快他就接到了M城市的项目，对于没有做过项目经理也没有接受过相关培训这点，大家觉得不会成为问题。
很快A同学的项目团队组建完成，整个团队32人，分为3个小组。Y同学负责研发小组，C同学负责测试小组，S同学负责设计小组，X是这个项目的BD。A同学带领大家制定了项目计划，项目启动了，一切看起来都很正常。
很快半个月过去了，这天早晨，A同学正在和研发同事沟通方案。部门经理打来电话，语气很不友好，因为项目开始半个月了，他对M城市这个项目知之甚少，之前其他项目经理都是每天发送日报给他的，而A同学好像把这件事情抛了九霄云外。虽然不太服气，但是半个月除了一次简单的进度信息同步外，再没有同步过任何消息，而那封唯一的邮件也绝对没有超过100个字，这似乎的确不太应该了。虽然自己一直忙于项目，实在没有时间写，但这显然不是理由。
一大早挨了批，看来今天不太顺利。对了，上周和研发小组的K同学沟通过一个功能模块的开发，按计划今天应该完成了，现在去了解一下。可是找到K同学才知道，这个模块的开发根本就没有开始。过分，简直太过分了，一个星期过去了，居然还没开始，而且连个招呼都不打。A同学出离愤怒了，他想要发火，但显然K同学没打算给他这样的机会。“上周只是和你沟通了一下方案的技术可行性，当时给的时间也只是一个大概工作量，没有说过这个工作要马上开始。具体的开发工作安排请找我们的Y同学沟通，他会安排任务给我。”。无语了，彻底无语了，这次好像又是A同学自己出了问题。没办法，去找Y同学沟通安排吧，这真是个教训，以后要注意了。
回到工位平复下情绪，可刚坐下，Y同学和C同学朝自己的工位走过来，从表情来看，不像是给自己来同步好消息的。果然，C同学人还没到，声音先到了。
C同学：测试用例有问题，当时为啥不说？
Y同学：谁知道你的测试用例想表达的是那么个意思？
……
两位你来我往，沟通的好不热闹。看来短时间内，这二位的擂台争霸是不会有结果的，而且在结果出来前，这二位也没有离开自己工位的意思。可是问题总要解决啊，A同学找来了方案设计的S同学做裁判。本来以为S同学来了可以快速解决问题，但是没想到这场擂台赛由二人争霸变成了循环赛，更热闹了。对同一份设计文档，三个人居然有三种不同的看法。这场循环赛直到中午才结束，最终形成结论：“A没有就输出的文档及时组织沟通会，导致大家对文档的理解不一致，下次要注意。”。真是没了天理了，当时组织沟通，本来是你们说一切以邮件为准，邮件的内容也都理解了，不用当面沟通。可现在……，各位的甩锅水平也太高了吧。
下午一上班，A接到了客户的电话，当初制定的方案略有调整。在安排S同学去沟通后，准备把这个消息及时同步给Y同学。但是还没开口，Y同学用一个坏消息欢迎了A同学，研发组两位核心成员要离职，已经开始办离职手续。研发进度可能会受到比较大的影响，还有就是之前确定没有问题的几个开发任务也没有按时完成。
吃过晚饭，A回到工位，回味着这一天的经历，默默下定决心：“以后打死也不做项目经理了”。
1.1.1.7、当领导破坏规则时，容易妥协
在领导的世界里没有规则
在项目管理的过程中，规则的最直接破坏者往往就是公司的高层领导。这些牛人培训时不参加，执行时不遵守，我行我素，项目管理的流程、方法、规章制度在他们眼里形同虚设。他们的脑袋里只有一套逻辑，我是领导，我的事情是重要的，而重要的事情是可以逾越规则的。具体逾越哪一级的规则，那就看领导的级别了。项目总监可以逾越项目的规则，部门经理可以逾越部门的规则，至于老板嘛，他的世界里没有规则。
这就麻烦了，领导不守规则，难道要下面的兄弟们监督吗？很显然敢于拿自己的前途和钱包开玩笑的毕竟少数，反正您是领导，您高兴怎么来就怎么来吧！既然领导有特权，那么手下的兄弟们在特殊情况下申请拿过来用一下也是可以的。于是本来好好的规章制度，被这里搞一下，那里搞一下，最终就成了象征性的摆设。
所以，项目管理方法体系要想执行下去，必须得到上级领导甚至顶层领导的支持。能否得到领导的支持，能得到多少支持，就看制度制定和推广执行人的本事了。越是得到上层领导的支持，推广的难度会越小，制度成为摆设的机会也会越小。
1.1.1.8、树立项目中的超级明星
我是团队的超级明星
如果你觉得自己不够聪明，看完下面几个数据，也许会改变看法：
1、伟大的爱因斯坦智商135分。
2、智商低于90分无法完成初中学业。
3、一般人的智商在100-115左右。
可以看出，人的智商基本呈正态分布，特别聪明或者特别笨的人都是占比非常小的那一部分。虽然智商几乎一样，但是所擅长的领域却未必相同。所以要在有限的智商内有所作为，选择是非常重要的。
回到我们的团队，那些表现特别优秀的人其实也只有那么一小部分，应该不会超过整个团队的5%，而剩下的95%都是表现正常的成员。在我过去所经历过的项目中，那一小部分明星员工的确发挥了重要作用，但是没有那些普通成员的辛苦付出，光靠那一小撮明星员工，就算是累吐血也是搞不掂项目的。
所以，如果你是一个团队的Leader，那么切记，不要打造团队中的超级明星。因为把部分人头顶的光环搞得太亮，其他人就慢慢暗下去了。既然超级明星那么厉害，我们都是普通人，我们做的差不多就行了。超级明星，开始你的表演吧。
我们伟大的庄子有一句话“快马先死，宝刀先钝，良木先伐”，但项目经理经常犯的一个错误就是，喜欢用顺手的人，把这个人打造成那个红得发紫的人。遇到技术含量高的项目、时间紧的任务、质量要求高的项目，最先想到的就是这个人。这个任务是不是此人所负责不重要，重要的是任务交给你我放心啊。
这就苦了这位仁兄了，顶着超级明星的光环，像打了兴奋剂一样。新任务接了太累，不接又放不下身段，这个选择真难啊。于是熬夜、加班，累坏了身体，磨灭了激情，年纪轻轻搞了一身毛病，谁让咱是超级明星呢？
所以作为项目经理，不要去打造项目中的超级明星。每一个人的成功都是兄弟们一起协作的结果，没有了团队的协作，超级明星自己试试，看能不能搞定项目。像很多在头部大厂工作了若干年，干到一定位置的人，慢慢的就在公司的成绩簿上迷失了。周边的人觉得自己是明星，成绩有目共睹，自己也觉得不含糊。然后离开公司，去开创属于自己的盛世。但是很多人很快就折戟黄沙了，原因很简单，离开了平台，离开了公司资源，离开了团队的配合，你什么都不是。
作为项目经理，我们更应该明白这一点，才能更好的带好项目。
1.1.1.9、整个项目在集体信念中丧失理性，决策缓慢
集体信念可以让月亮变成方的
首先来看一个名词“集体信念”，我们将其分为两个部分来看，集体和信念。集体代表被团队中所有或大部分成员所接受，信念代表一种信仰、决心、价值和规范，通俗来说，就是能忽悠自己和所有人，这事无论如何都能成的理念。由此看来，集体信念这玩意有理性的一面也有感性的一面。他的强大源于这个特征，破坏性也来源于这个特征。可以让不可能完成的任务变成可能，同时也可以让本该离场的项目在错误的路线上继续前进，带来更大的损失。
鸡汤类的内容本文不做关注，我们只看一下集体信念可能会给项目带来的问题。在某些情况下，集体意识会给项目带来盲目性。在这种非理性的盲目下，那些跳出集体信念的个体会受到集体信念的排挤甚至攻击。敢和大家对着干，连点集体信念都没有，看你小子是不想混了。集体信念给人带来的紧箍咒往往有如下这些：
1、和集体信念不一致，价值观有问题。别人都说月亮是方的，你小子偏偏说是圆的。
2、对失败项目的离场建议，被当做没有信心和能力的体现。
3、害怕暴露问题，担心问题暴露会成为一个不和谐的音符，影响了集体信念。
4、选择性接收和考虑项目信息，自动过滤不好的消息。
5、将项目的失败看成个人的失败。
在这个时候，项目经理需要本着我不下地狱谁下地狱的优良作风，主动承担起责任，突破集体信念的约束。做一个强势的猛人，把项目从错误的轨道上拉回来。
1.1.1.10、僵化的项目管理，缺乏有效应对变更的机制
变更引起的连锁反应
凡是做过项目经理的都不太喜欢项目变更，尤其是一些比较大的项目。拼了半条老命，项目范围定了、进度计划定了、成本定了、投入的人员也定了，风险也摸的差不多了。这个时候谁提出变更，真的有过去踢他两脚的冲动。因为往往是牵一发而动全身，变了一处，会连带变动好多处。如果频繁的变更，光是维护这些计划也够人喝一壶的。
但是项目中总会遇到这样那样的问题，变更是不可避免的。既然无可避免，在计划制定，甚至项目管理流程、规章、制度制定的时候，就要考虑到对变更的兼容性，尽可能避免变更带来的过多的工作量。
提高对变更兼容性，可以从以下几个方面着手：
- 在项目的关键路径提前预留一定的空闲量，给变更留出一定的缓冲期。
- 多用一些技术工具来协助解决这个问题，比如排期工具，当一处排期变化时，其他工作可以自动进行顺延处理等。
- 项目注重框架管理，将框架管理和细节区分开来。实现流程框架可定制，对不同的项目采用不同的流程框架，保证流程对项目变更的可支持性。
1.1.1.11、缺少宣讲和沟通
失败的制度执行
很多时候，会出现这样的问题。一套项目管理方法推出后，有的人完全不知道，有的人有不同的认知，有的人存在不同的意见。执行起来，是相当的痛苦，简直就是遍地大坑，到处问题。
是什么原因呢？现在我们找到几位有经验的项目经理来回答一下。首先有请A同学：
我觉得原因是流程方法、规章制度在执行前没有经过系统全面的宣讲，没有宣讲自然就没人知道，大家都不知道，一下就推出这么一套东西，当然会出问题了。
好，接下来我们有请B同学：
我觉得A同学讲的没错，但是我以前在做相关宣讲的时候，很多人都不认真听，而且就算听了也未必记得住，等实际操作的时候还是会出现一堆问题。我的想法是光靠制度推出后的宣讲不能解决根本问题，而应该在制度制定的过程中就充分吸收大家的意见。让大家参与进来，最低的标准各部门的主管要参与进来。这样制定出来的东西，大家接受起来也更容易一些。
看来这个问题有点麻烦，我们有请C同学来谈谈他的想法：
以上两位同学说的都有道理，我要补充几点：第一，我们组织培训要有针对性，建议针对不同的部门相关性，每次培训确定主题，只通知相关性高的同事参加。第二，因为人数太多，只要求部门经理必须出席，其他人员可选择出席或不出席。第三，制度推行以及信息化系统的应用都没有那么快，建议在信息化系统应用的前期阶段，设置专人对项目建立以及信息维护进行跟进和纠正。等大家都养成良好习惯后，再完全交给相关同事使用。第四，在制度推行方面，建议对部门经理进行考核，由部门经理监督本部门内制度的落实。
以上同学讲的都不错，接下来我来做一下补充。这套制度及工具推出来以后，要经过一定的试用和沉淀期，在这个期间，要积极收集大家的意见。对于正确的意见，要积极的进行反馈，并把意见的采纳及所要做的相关调整计划进行告知，让大家保持积极的参与性。
总结一下一上同学的看法，简单概括为如下几点：
1、流程方法、规章制度的制定过程要大家进行积极的参与。
2、在体系推行前，要做好完整系统的培训，并且培训要有针对性。
3、在体系推行的前期，要积极听取改进建议，能优化的优化，该改进的改进。
4、信息化系统的使用早期，要做好监督和辅助，保证系统后期正确使用。
以上几点做到，制度的落实，系统的使用应该问题都不大了。
1.1.1.12、管理者游离项目管理体系之外
没有项目总监参与的项目管理制度会议
上图的场景并不罕见，我们的领导决定引入项目管理。但是，接下来的整个项目管理体系建设过程中，他们都是全程缺席的。原因很简单，领导很忙。结果是什么呢？制度制定出来，全公司对其了解最少的就是领导。
领导不了解，那就麻烦了。这种情况下，下属有两种选择。其一，从头到尾给领导来一套定制培训，辛苦和浪费时间就不说了，遇上有想法的领导，再提出一堆问题要改进就真的麻烦了。想问一句，您这早干嘛去了？其二，因为领导不知道，自然不会按照制度来执行。于是，本来可以在系统中调取的数据，领导们还是更喜欢让项目经理导出Excel来提供；本来可以在系统中看到的项目进度，还是更喜欢去询问具体的负责人；需要快速审批通过的变更，可能会停顿很长时间。
领导执行成这样，再去要求底下的兄弟们，那就有点不讲道理了。很快，所有人开始对项目管理体系视而不见。最终的结果也很好理解，项目管理方法落地失败。
1.1.1.13、已经注定失败的项目，没有及时结束
这个本该离场的项目又继续了下去
其实有很多项目，因为各种原因，做着做着就没有继续下去的价值了。原因可能是因为：市场的变化，客户战略的变化，新技术的出现，项目盈利能力的变化，项目前期规划失败导致的技术陷阱等。一句话概括，这样的项目继续干下去只能是只赔不赚的结果了。或者说，它需要寿终正寝，早日离场了。可是说的轻巧，那么多钱投入进去，那么多兄弟没日没夜干了这么长时间，你说结束就结束，疯了吗？
这是一种很正常的错误心理，投入了很多以后，再放弃，那是绝对的不甘心啊。如果说这种不甘心是一种普遍心理，促使项目不能尽快离场还有一些个人的因素，这些个人因素可能包含：
- 不愿认输，怕被人说无能的项目经理。
- 害怕失败的项目发起人。
- 不愿意承担决策失误的责任和由此带来影响的高层管理者。
- 不愿揭开伤疤，违背集体意念的内部相关方。
- 还蒙在鼓里觉得觉得一切顺利的老板。
于是，在痛苦的日子里，项目痛苦的继续着，继续花掉更多的钱，兄弟们继续在绝望中寻找着希望。直到有一天，这项目实在混不下去了，宣告失败离场。接下来是什么戏码，大家都不会陌生，往好听点说叫复盘，往直白点说，要找背锅侠。好端端的项目做成这样，总要找到原因的。然后就是该检讨的检讨，该追责的追责，但是那些浪费掉的资源和成本却没办法回来了。
所以，对有些项目是需要有离场拥护者，这个最合适的人选就是项目经理。作为这个角色，需要项目经理同时具备勇气和智慧。勇气在于顶得住大家的非议，面临可能被排除出项目组的风险，甚至在公司里的职业前途。智慧在于如何用巧妙的方式提出来，能达成目的，自己又不会被干掉。要成为合格的离场拥护者，建议做好如下几点：
1、能尽可能量化的整理好自己所持观点的证据。
2、在正确的时间正确的地点用正确的表达方式表达出来。
3、做好被群起而攻之的准备。
1.1.1.14、方法体系的执行缺少有效的监督和奖励机制
只管开会不管监督落实的会议
有一个事情作为项目经理或者组织必须要明确，跟着你奔事业的兄弟们，除了情怀，还有更重要的事情，那就是生活。除了是公司的员工，他或她可能还是一名父亲或母亲，儿子或女儿，丈夫或妻子。如果没有有效的监督和奖励机制，没有人会靠情怀把事情做好。
所以，现实一点，不要去考验人性，与方法体系对应，打造对应的考核和奖励机制。管理团队不能光靠物质奖励，但是离开了物质也绝对是不行的。
同样的道理，也不要用放纵去考验团队的自律能力，轻松愉快和放浪形骸是两个完全相反的概念。作为项目经理，有责任随时了解项目的状态以及团队成员的工作状态。在出现问题前进行预警，避免问题的发生。在发生问题后，积极的沟通进行解决。
锄头不到，草永远不会自己消失。流程方法规章制度就是除草的锄头，而要除掉草，是需要人去挥舞锄头的。
1.1.1.15、有限的资源承担过多项目，一个人同时做多个事情
一个人同时负责多个事情是效率很低的选择
如果有可能，在同一段时间，同一个人，尽量只做同一件事情，这是最有效的工作方式。为了说明这一点，我们来看一个概念。
顺流，顺流指的是一种全心全意投入到某件事情当中的状态，在这样的状态下时间过得飞快，思想高度集中，灵感像拧开的水龙头一样喷薄而出，这就是顺流。这绝对是一种很享受的状态，从低头工作的那一刻开始，不知不觉，一抬头3个小时已经过去了。在这期间周围的环境很难对你产生影响，有人拿锥子扎了你的腿估计都没啥感觉，真是比悬梁刺股还要生猛。
很多工作，比如：设计、开发等工作是需要这样的状态的，但是很少有公司能给我们提供这样的环境。只要你能接得住，头上顶个10个8个项目那绝对是正常的事情。这样就麻烦了，一会接电话，一会有人来找，一会开会，别说顺流了，能流下去就不错了。
据专家统计，一个人从被打断到进入顺流状态大概需要15分钟的时间。在这15分钟的时间里，都会对周围的环境特别敏感，张三一句话，李四从身边经过，都可能产生影响。如果从投入产出比的角度来说，同时给一个人并行安排多个项目都不是好的选择。
作为合作部门，我曾经被一个兄弟深深的感动。原因很简单，每天几乎接近凌晨下班，早晨第一个到公司，满脸的沧桑加上乱蓬蓬的头发，给人一种刚从建筑工地回来的感觉。他是公司最忙的人，也是大家最需要的人。他几乎从不拒绝任何人的需求，但是也经常放大家鸽子。约定的交付日期，对他来说，没有任何约束力。原因很简单，他太忙，已经尽力了。
综上所述，如果作为项目经理，在工作安排上需要注意哪些问题呢？
很简单，尽量不要打断兄弟们的工作，尽量不要打乱兄弟们的工作计划，尽量不要安排并行的工作，尽量给大家提供一个不受打扰的工作环境。
做好以上这些，足矣！
以上就是今天要和大家分享的内容，如果感觉还有点帮助或者启发，就请关注吧！也欢迎大家多提宝贵意见，让我们一起把项目管理做得更好！
感谢大家对本文的关注！