项目经理的生存之道.doc

项目经理的生存之道 (一) - How to survive as a project manager?到2009年为止，本人作为项目经理已经接近9年，成功完成大大小小的IT项目超过20多个。在HP也做了几年的项目管理培训（对内和对外）和PMP认证培训的工作，2008年还获得了“Star Of Year of Project Leadership”（1/3800）：项目管理年度之星。在对项目管理有诸多体会的同时，却发现自己身边有的项目经理同行们日子过得不是特别好，有菜鸟项目经理，资深的项目经理，成功的项目经理，却因为某些项目没有控制好，从而极大地影响了自己的职业发展。项目结果不好，最好的情况是换一个项目，以图挽回之前失败的影响；其次的是没法再原来部门呆下去，考虑换部门；而最多的情况呢，自然是没法在组织呆下去，要不体面地走人，要不被扫地出门。什么是项目结果不好？我们先来看看项目经理这个角色，项目经理为项目的成败负责，其职责是建立并领导项目团队，全程控制项目流程（项目启动，项目计划，项目执行和项目结束），平衡项目进度，成本和范围的关系，并最终达到项目的目标。在HP的几年里，身边就有不少的项目经理因为种种的原因离开（印象深的至少有10个），其中不少还没有等到项目结束就被换掉了，也就是说压根就没有看到项目的目标是否完成。换句话讲，达成项目的目标并不是项目经理的第一目标，项目经理的第一目标应该是如何活下来，至少要熬到看到目标的那一天。残酷的事实是，项目经理阵亡的比率太高了。在过去的3个月里，我身边就有2例，并且这两位还是非常有经验的项目经理。随着现在经济形势的发展，项目经理承担的项目越来越受到管理层的关注并被当成救命稻草，成功是必须的，失败是绝对不行的，稍有风吹草动，项目经理作为替罪羊的概率大大增加。回想自己过去几年的项目管理经历，过程中不乏危机时刻，如果当时我没有处理好，会发生什么事情呢？我想结局好不到哪里去，至少那个年度之星就别想了。_曾经有人问我一个很白的问题：考了PMP证书，是不是就能够把项目管好？很遗憾的是，上面提到阵亡的项目经理大多拥有PMP证书。既然有PMP证书，自然是熟知项目管理的9大知识领域：项目综合管理，项目范围管理，项目时间管理，项目成本管理，项目质量管理，项目人力资源管理，项目沟通管理，项目风险管理，项目采购管理；并且我们还可以获得很多诸如项目模板（template），检查清单（checklist），历史项目资料等等对我们项目管理有用的数据和工具；我们带领的团队基本都是比较熟悉的人员，自己对项目的领域也相当的熟悉。既然这样，有理论知识，有工具，还有自己熟悉的团队，为什么项目经理还常常面临危机并可能被扫出项目呢？作为一个项目经理，是不是有它的生存之道呢？有句话说的好：一年里你对女人的一千个好，比不上重要的一天（比如她生日）里的一个不好。作为项目经理，允许犯错，但是在关键的问题和事情上绝对不能犯错。这个“项目经理的生存之道”系列就是期望列出项目经理的一些雷区，总结在项目管理中的一些关键问题和关键挑战。当然，对于每一种状况的应对方法都没有标准答案，期望的是带给大家更多的思考。项目经理的生存之道（二） - 识别和管理关键项目干系人(1)主要症状这类项目经理认为，只要能够带领兄弟们埋头苦干，届时这样按时完成项目，质量还可以，成本不超就是项目大大的成功了。何为项目干系人（Project Stakeholder）是指积极参与项目的个人或者组织，并且会对项目的结果产生影响或者被项目的结果所影响；干系人可以是组织内、或者组织外的人。项目干系人包括客户、监管机构、经理、分析师、开发者、测试者、文档编写人员、法律人员、销售、支持人员、制造人员等项目相关人员。作为项目经理，如何整理和汇总项目干系人？应当编写项目的通信录：姓名，角色，主要职责，联系信息等等如何管理项目干系人的沟通？通过项目沟通管理计划来做到，考虑When（什么时候）、What（什么信息）、Who（什么人）、How（通过什么方式发布或者获得信息）上面的大家都会，干系人很多，找出关键项目干系人更重要。怎么样识别出关键项目干系人？很多人相信自己的脑子，结果却是常常会忘掉或者漏掉一些，这里介绍一种结构化的方法：建立一个评分等级和加权，从权利、需要、兴趣、知识等方面对主要干系人分析和评分，得分据前列的为关键干系人。权力：对项目的影响力需要：项目满足个人和位置(position)的需要程度，体现为对项目的关注。兴趣：对项目的参与度知识：对项目涉及专业知识的了解度接下来的步骤是列出这些关键干系人的期望，他们会直接告诉你明明白白吗？一般不会的。尽力分析出来，特别是哪些互相冲突或矛盾的期望。比如对于Time&Material的合同，客户期望能够成本尽量降低，而你的经理却希望钱收得越多越好。项目经理的重要职责就是平衡这些关键关系人的期望，并在整个项目过程中跟踪这些期望。注意：期望是会变化的！特别是组织内或组织外项目相关的人事或组织架构发生变化时，这时如果不及时调整，问题就大了！除了管理干系人的期望外，还需要管理干系人，对于不同类型的关键干系人需要采取不同的策略。第一类：权力-高兴趣/需要-高知识-低在你眼里，他/她可能是客户的项目经理或者领导，也可能是你的领导，他们具备影响项目的绝对权力，参与度很高，问题是他们对于项目涉及的专业知识掌握度很低。你觉得人家水平低，人家自我感觉非常良好。水平低就算了，还特喜欢发号施令，乱指挥，你说他不对他绝对跟你急。“叉腰肌”的谢亚龙不就是这么一位么？有这样的干系人，看看项目经理们（国足教练们）最后都干成咋样了？对方是客户的领导（项目经理的领导），为了搞好关系，项目经理顺着这类干系人的思路进行项目，结果导致对方自我感觉膨胀，经常左右项目的走向和决策，项目经理的好意完全没有得到尊重，被斥为“专业知识不过关”，一气之下，顶了句嘴“啥都不懂吓指挥”，客户暴怒，连公司业务也受影响，项目经理也只好黯然离去。作为项目经理，控制自己的情绪很关键，生气的时候或者接近发飙的时候，先深吸一口气，给自己3秒钟时间问自己：我真的要这样做吗？即使不进行反击，项目就能顺利进行了嘛？明显项目经理在处理这类干系人的策略不对。针对这类干系人，有以下的建议：1. 树立真正的专家形象，选择和包装自己团队的专家，并且能够震住对方，最好有什么名号。让对方了解到成为专家的困难度，自然可能会考虑知难而退。可行度：五星2. 这类型的干系人更倾向于先进、最新技术、主流产品、国际标准等，在技术路线或者技术包装上需要考虑到这样的喜好倾向。场景：您的意见非常好，我们采用的是业界先进的方案，具备科学的设计和架构，.，我们可以考虑先用目前的方案，你的建议可以考虑在将来三期的时候规划。真的是“业界先进”吗？只要你能说服对方就行了。可行度：四星3. 在对方组织中寻找专家，并争取干系人可以授权给这位专家。通过这样的方式，其需要仍然很好，但是兴趣会大幅降低，从而大大减少对项目的干预度可行度：五星，很多人从这方面想过，如果从一开始就考虑到这点，可操作性是很高的。4. 既然对方对项目涉及的专业知识缺乏了解，那么不妨挖一个小坑，并且结果在控制范围内，然后让其掉下去，你再来完美得收尾，送对方一个人情。对付不见棺材不掉泪的主特适合，但是小心操作，不然搬起石头砸了自己的脚。可行度：两星5. 了解对方真正的需要是什么，尽力作为顾问的方式为其提供多种建设性方案来满足其需要，并用实际成果说服对方信任自己。如果国足有很好的成绩，谢亚龙还会那么瞎折腾么？可行度：三星说到底，我们希望最后达到的效果是：权力-高 （高）需要-高 （让对方意识并且相信减少参与，自己的个人和位置的需要也能得到满足）兴趣-低 （降低其参与度）知识-低 （让他/她意识到这个事实）其它类型的关键干系人如何合理呢？第二类：权力-高需要-高（position的需要高）兴趣-低知识-高这一类属于最容易忽略的关键干系人，也有实例证明一旦处理不当，后果是非常严重的。大家思考一下如何处理？第三类关键干系人：权力-低需要/兴趣-高知识-低下一章我会继续探讨这个问题，重点会关注2个案例：1. 第二类干系人管理2. 项目过程中客户期望发生变化时却沿用老方法处理。项目经理的生存之道（三） - 识别和管理关键项目干系人(续)上一篇文章谈到下面这一类的重要项目关系人权力-高需要-高（position的需要高）兴趣-低(项目的参与度低)知识-高为什么这类关键干系人容易忽略？这类干系人具有很高的位置（比如项目经理的老板的老板或者技术和业务专家），这个项目的成功会为其带来很好的政绩，平时却不会出现在日常项目过程中，但是很可能突然有一天他/她因为种种原因跳出来给你一个大Surprise！拿案例说事吧。角色A：项目经理角色B：项目经理的直接汇报经理角色C：B的直接汇报经理A report to- B report to - C一项目经理A在客户现场带项目，项目进行了2个月，客户没啥意见，项目经理的老板B由于特别忙，也没有特别关注这个问题。但是这个项目属于项目经理的老板B的老板C的重点项目，对C在2009年的业务开拓具有相当重要的意义。换句话来说，对C来说，只许成功，不能失败。而A呢，只是关注客户，关注自己的老板B，压根就没把C当成重要的项目干系人。阶段一：C看了1个多月的项目周报，项目周报总是汇报天下太平，但是有1天从侧面了解项目，基于自己的知识和经验，觉得项目周报有问题，于是要求B进行整改（注意，这个阶段还没有直接跟项目经理A直接联络）。项目经理A通过自己老板B得到这样的要求后，当然说好，但是项目事情很多，这个要求又经过了自己老板B的转述，也就没有把优先级放得特别高。阶段二：C开始看第二个月的项目周报，发觉居然没有啥改进，立即question自己的下属B，B由于对本项目参与不多，好多事情也回答不出来，那么C的判断就是：A没有执行力；没人在控制这个项目。阶段三：第三个月，C十分不满，决定自己跳进去看这个案子，C这个时候进来看这个案子，基于之前的两个月的经历，对项目经理A已经是带着有色眼镜来看问题了。而我们可爱的项目经理呢，他并不了解过去1个月在B和C之间发生的所有事情，也并没有了解到事情的严重性！C由于具备很强的知识，自然很轻易地找出来项目的一堆问题和潜在问题，谁是责任人呢？这个时候自然会归咎于项目经理A，为什么？因为在C的眼里，很多事情在2个月前就已经交待了，却没有得到跟进和改善！作为项目经理，我们自问：我们的项目是否都是很完美的？不会的，总会找出一堆问题来的，关键是找问题的人怎么看这些问题。项目经理A怎么看C的突然加入呢？级别高两级给他巨大的压力，C提出的事情做不做？A的回答都是“好”。阶段四：问题升级和爆发了，项目经理A对C的要求都是回答“好”，但是这是积累了好长时间的issues，哪有那么容易就搞定啊，关键的是，项目经理A没有证据来支持自己为什么无法按时完成。C很紧张这个项目，现在发现项目经理A总是响应缓慢，由于又是在客户现场带项目，并不习惯经常跟C汇报。对C来说，判断就是：虽然自己介入，却由于项目经理A执行力差而无法改善，项目危险！阶段五：问题定位到人就很简单了，解决方案只有一个：换项目经理。最后结果：项目经理A被开了“绩效警告信”，为了避免被直接开除，只好1个月后黯然离职走人。就这样，刚刚3个月，项目经理A就阵亡了，至于客户是否答应这次换人，换人后新项目经理干得怎么样，就不是这个案例的内容了。 这个案例中的关键干系人是来自自己的组织的，常常更难处理的来自客户的这类人员，比如一个IT开发项目进行到中途，客户的技术架构部门跳出来，说这个项目的架构不符合他们的技术要求；或者客户的高级主管突然跳进来对项目进行粗暴干涉。 这类状况的常见现象就是你突然发现你认知的”关键干系人“突然不顶事了，他们也顶不住更高干系人的压力。 项目经理A为什么会阵亡？在他个人的认知中， 客户没有问题，自己老板B没有问题，团队也没人拆台，为啥还会被钉着打？最后还死得不明不白呢？有三点：没有识别出C这个重要干系人；没有避免C直接介入；C介入后也应该顶住。 头疼啊，权力高的干系人，平时可是不容易见到的，处理好了，自然是为项目经理个人大大加分；处理不好，权力高，自然也具备直接枪毙项目经理的权力，结果如何全看人家心情了。 说点自个的事情，进HP不久后带一个重要的项目，大Boss（老板的老板）在启动阶段连续跟进了1个月，然后放心地不管了，这段时间给了其非常正面的印象，相信对日后我的升职肯定有着不小的正面影响（在外企，跨级沟通的机会并不多的）。 如果有效管理这类干系人？1. 及时告知 - 改进沟通机制 这类干系人基于自己的需要，因此期望项目是受控的，是稳定的，因此所有项目的关键信息，关键决定， 项目状态必须要知会（cc）到他们，也就是说他们必须在cc list里面。保证的机制是在沟通计划中专门加上这一项。如果这类干系人质疑你的项目状况，你完全可以拿出曾经发送给他/她的所有历史记录，告诉其来龙去脉。这类关键干系人的唯一缺点就是三高一低，这低的一点就是其项目的参与度很低，根本不会去查看所有的项目信息，但是这些项目信息会暗示他/她：项目是在受控的持续进行的，自己是可以掌控这个项目的。 注意：项目报告要有持续性和一致性，不要突然出现surprise。2. 利用这类干系人成为项目解决关键问题的重要力量： 不要以为高高在上的领导们高不可攀，既然被你定义为重要干系人，就好好地把他们给用起来。你想象一下，有一个高层的老板一直在mail loop里面，会不会给一些人压力？有压力就好办事啊，你大可以狐假虎威吧。再换一个角度，这是不是一个很好的escalation的机会？当然是了，持续在项目周报里面把重要issue标注成红色，如果不能解决，字体放大2倍，你放心，有人会在上面或明或暗帮你的。3. 提升其参与度最好提升其参与度的方法就是适时地请其帮忙，利用其专业知识进行一些指点。这类关键干系人适度参与了之后，会大幅增加项目的认同感。原理很简单，专业知识（技术、业务或项目管理）强的人是非常乐意自己的知识发挥作用并被得到尊重的。4. 减少不合理的干涉减少干涉的方法很简单：重要的技术或者业务决策是通过集体决策得到，并且有明确的记录告知给这类干系人知道。为什么，这样大幅增加其干涉的成本，因为普通人都有从众心理，并且如果想推翻这样的决议需要说服更多的人。国内很多项目经理常常是业务、技术、项目管理一把手，特别喜欢做决策，如果项目中存在这类关键干系人，一定要特别注意，否则项目意见的不一致会完全上升到个人能力问题。宁愿让其相信项目团队的能力问题，而不要让其坚信全是项目经理的问题。简单点讲，直白点讲，用集体来保护自己。事实也是这样呀，项目又不是出了啥天大的事情，干嘛用项目经理开刀？ 5.寻找支撑点如果真的发生大Boss突然参与到你的项目里面，并且是如案例中一样的质疑态度，应该怎么办？首先一定要知道为何而来，知道其根源，利用各种原因探听真正的原因，只有这样才能对症下药；其次，一定要搞清楚其质疑的对象，是项目本身，项目经理还是项目中其他关键角色；如果很不幸，针对的就是项目经理，那么应该寻找到支撑点。所谓支撑点，就是要寻求项目组内外的支持：客户：如果是内部的老板质疑你，客户的支持就很重要，在案例中的状况，如果你能说服客户给你发一封个人或者项目的“Thank Letter（感谢信）”，即使内容不痛不痒的也行，这绝对会促使质疑你的老板重新考虑：是不是我只看到了问题的一方面而已？你的老板：在外企里，跟自己的直接汇报经理沟通是最多的，关键的时候一定要他/她支持你，即使不能根本解决问题，好歹也可以争取捞一个死缓啊。案例里面的项目经理A压根就没有争取其项目经理B的支持，老板都搞不定，做啥项目经理呢？重置成本：作为项目经理，你应该在项目各方面参与得很深，比如客户关系管理，团队管理，项目流程，业务/技术/质量的一个方面以上，也就是说你是不可缺少的。即使大Boss想用莫须有的借口让你成为某个事情的替罪羊，但是他/她得考虑重置成本（更换项目经理）啊，和谐至上嘛。如果你可有可无，哼哼，上班在混日子吧。说了那么多，有人问，遇上这么困苦的状况，我战略撤退，申请换个项目还不行嘛？不行的，被高层贴上了“无能”的标签就意味着你在这个组织短时间没啥好混的了。识别和管理关键项目干系人（完），请关注项目经理的生存之道的后续章节。项目经理的生存之道（四）-问题升级机制什么叫问题升级机制？英文叫做Issue Escalation Mechanism，是指当项目组出现问题，而这个问题超出项目经理级别的处理范围，因此将该问题升级到更高级别处理的机制。听上去很简单，但是这句话有两个需要琢磨的地方：升级的是什么问题？升级到什么级别？先来看问题的类型，通常，导致问题出现的原因有以下几个方面： 1. 质量问题：已交付的交付物或者系统功能存在质量问题 2. 需求范围（Scope）问题：经用户确认的业务需求，后来又发现有遗漏或者又提出新的需求 3. 功能问题：方案设计的功能与确认的需求有差异 4. 运行问题：方案设计已经符合确认的需求，但可能在运行性能、可靠性、可用性方面尚存在问题，这些问题常常会在如下方面对项目产生影响： 5. 技术上的问题：系统设计可能因此而有所改变 6. 进度上的问题：项目进度计划可能因此延误 7. 合同上的问题：可能需要对合同条款进行变更处理 8. 合作的问题：合作的人员的个人能力或者态度存在问题很明显，不同的问题升级，代表着不同的后果。在看看升级的级别，一般原则上的上报机制是： Level1：项目组成员Level2：项目经理Level3：项目经理的经理或者负责主管Level4：项目指导委员会（如果有这样的一个组织）项目能够到的最高级主管，比如CEO or GM（据项目而定）我们可以想象，项目组成员或者客户就不同的问题升级到更高级别的时候，会发生什么问题？用案例来说话吧。阶段一：项目进行到关键时候，项目出现了一些质量问题，即客户在测试中发现了一些Bug，于是客户的项目经理B直接向项目经理A的大老板C（项目经理A的老板的老板）发email做正式的抱怨：“针对xxx功能的bug问题，我们需要发出一个正式的客户抱怨。以一个CMMi L5的国际大公司，在xxx功能中，经过你们的测试和质量控制，最后正式交道客户手中，居然存在这样的bug，实在难以令人理解。.”。试问，哪个项目不会在交付后还有bug？但是大老板C会关心这些细节么？他只关心的是：客户很不爽，这个抱怨已经影响到了公司的声誉，于是他回了一封信郑重道歉，然后把项目经理A的老板叫过来，一顿教训。项目经理A的老板啥状况都不知道（他不在mail loop里面）很郁闷，于是把项目经理A抓过来，也是一顿教训。项目经理A很委屈，但也只能安排团队加班熬夜赶快解决问题了。阶段二：故事还没完，客户的项目经理B一看，一封email这么有效，项目经理A现在也老实了不少，过了1个月，他故伎重演，又来了一封抱怨信，当然这次是另外的bug了。1次是偶然状况，但是2个月里连续2次就很让人紧张了，于是检讨的检讨，背书的背书，内部一致认为这个项目组质量控制不力，项目经理A有着不可推卸的责任！替换项目经理的事宜也提上了内部日程。阶段三：项目经理A被彻底击垮了，当客户的项目经理B一提bug，立即条件反射般地回答“改，改，马上改”；客户的项目经理B要增加新的需求时，原想坚持这个需求不在范围之内，对方脸一横：上次的bug的事情，我们还没有算账呢？赤果果的威胁啊，我们可怜的项目经理只好屈辱地同意了。结果：非常容易就可以猜到结果了，不是吗？在客户现场办公的项目，项目组有专门的房间（project room），两个BA（业务分析师）就业务问题有不同看法，争执不下，即使客户项目经理在场时也不避嫌，甚至还请其评理。客户项目经理在后来的客户反馈中评论到：“项目组成员沟通不畅，协助中存在着矛盾和推诿。现场办公如此，很难相信他们可以同offshore的众多开发人员可以很好的协作。”结果：两位BA没有过多久就因为种种原因非正常的打道回府。项目组内部正常的业务争论，到了客户的耳朵里却有着明显不同的解读。做为项目经理，你碰到过类似项目经理A的遭遇吗？有人会讲，客户的项目经理太不给面子了，客户关系没有搞好。如果平时在一起多吃吃饭，喝喝酒，建立起个人感情，自然可以解决这个问题。诚然建立个人感情会起到很好的作用，但是毕竟代表着甲方和乙方，代表着不同的利益关系，常常有时候吃饭喝酒建立起的感情会特别脆弱，比如或者对方的项目经理有着很大的内部压力的时候，上面列了那么多的问题类型，难道对方找不出可以做文章的内容么？换一个角度，如果不是对方的项目经理越级升级，而是对方的团队成员或者自己的团队成员呢？这类的状况也是不少，一旦控制不好状况，就会造成很难处理的困难局面。到底是什么原因导致了这个案例的局面呢？我们应该如何预防这种状况？如果这个状况真的发生了，我们应该如何应对？不当的问题升级会危及到项目及项目经理的生存，我们必须思考解决方案。具体解决方案的建议请等候下一章节。项目经理的生存之道（五）-问题升级机制（续）在上篇文章中谈到了问题升级机制相关的两个案例，下面我们来探讨一下解决方案。先谈一下预防机制，预防的方法就是建立有效的“问题升级机制”。第一步，在项目启动阶段的项目启动会议上正式宣布项目的问题升级机制，即上文所述的逐级升级机制：Level1：项目组成员Level2：项目经理Level3：项目经理的经理或者负责主管Level4：项目指导委员会（如果有这样的一个组织）项目能够到的最高级主管，比如CEO or GM（据项目而定）。这个升级机制需要注意的内容有四点：1. 双方都知道每一个的Level的人都是谁。2. 这个机制是双方都认可的。3. 既然是项目启动会议，尽量要求机制中提到的老板们到场。4. 升级机制是双向的：也就是说，你（乙方）是可以向对方的主管（甲方）抱怨对方的项目经理的！很令人吃惊的观点，我们不一定这样做，但是需要有这样的权力。如果有可能，在项目的合同和工作说明书中尽量增加一章“问题解决机制”来阐述这一的机制。为什么要做这一步？一旦大家了解并认可这样的机制后，特别是大老板收到项目相关的抱怨时，他首先会倾向于认为他的下属了解这个事情，否则就是对方没有走正确的流程。第二步，使用工具来引导和执行问题升级机制首先是针对项目组成员级别的问题，使用在线问题跟踪工具（online web based Issue Tracking Tool)来管理和跟踪日常的项目issue，常用的软件有很多，比如Jira, Mantis, Bug Zilla， 当然这类工具也可以用来做tasks和defect的跟踪。需求相关的，质量相关的，性能相关等类型的问题都可以放到系统里面。有系统就是好，定期可以拉出一些长期延迟没有解决的问题，并在项目周会上review如何解决，如果项目级别解决不了，那么升级给上层来解决。有了项目级别的问题跟踪工具之后，你再也不用担心项目组成员越级升级问题或者打小报告了，因为作为项目经理，你可以非常振振有词：有问题不走正常流程在项目组内部谈（在系统中登记），却找老板来压我，啥意思嘛？需要注意的是，不是所有问题都可以放系统里面的，特别是一些敏感的问题，特别是一些只能做，不能写下来的问题，那一类用excel或者用email也可以（需要email特别注明Internal Project Only）。接下来就是项目经理级别的问题机制，这里有2个工具：第一个是定期反馈机制，在每一次同客户的review会议中增加一个环节“客户反馈时间”，即询问客户在项目review这段时间里面对项目组的工作，问3个问题：1. 有任何需要提升的内容或者抱怨吗(Complaint)？2. 有任何建议吗(Suggestion)？3. 有任何表扬吗(Commendation)？ 大家知道，如果是中国人，一般情况下不会在会议上直接抱怨，或者会上说得很客气，那么跟对方约好，会后私下电话沟通。之后要做的事情是把收集的反馈记录下来（excel）。 双方达成一致：如果要升级问题，必须先告知对方。 第二个工具叫RCA（Root Cause Analysis), 问题根源分析，是跟第一个工具紧密相关的，如果客户有抱怨或者觉得不足的地方，那么找出原因和改进行动；如果客户有表扬，那么分析如何保持这样的绩效。分析好后加入到下次review会议的日程中，并一直跟踪到所有的改进行动关闭。 这两个工具有啥用？第一个用就是专业，专业地面对项目中出现的问题；第二个用就是以客户为中心；第三个用就是消灭主要的项目层面的问题，并引起上层的关注。 使用这两个工具之后，试想对方项目经理还会突然向你的大老板发信抱怨么？一般不会，因为你已经给他/她很多抱怨的机会（客户反馈环节）了，并且对他/她的每一个反馈都有非常积极认真的对待（问题根源分析），还有这些内容都有放到会议的日程中，上一级的领导都会看得到，这就减少了越级抱怨的动机。 在继续就该考虑项目经理上一级的问题了，同样，有一个很好的工具好用，叫做“CSS，Customer Satisfication Survey”，客户满意度调查，做这个调查就不是由项目经理出面了，而是由公司的质量部门或者项目经理的汇报经理或主管找对方的项目经理和对方的项目经理的主管，内容就是一个客户满意度的调查，频率一般是一个月或者一个季度，询问对项目的交付满意度，是否有抱怨或者需要提升的内容，涵盖了项目的方方面面。 通过这个工具，由于对方的项目经理有机会同你（项目经理）的主管沟通，并且这个沟通还是例行的。因此今后如果他要升级问题，第一选择就会是项目经理的主管，而非升级线路中最高的那一级。第三步，如果你想更加专业，你可以收集项目层次的问题数目，项目经理层次的问题数目，问题数量的趋势，问题解决的效率，达到这个境界，项目如果一个月啥问题都没有，做为项目经理，你反而会很心慌了。_接下来，如果上面那些预防机制都没有建立的情况下，被客户的项目经理或者团队里的成员越级升级问题，如案例所示，我们应该如何面对？面对的原则：应对这类挑战就是“危机管理”，没有什么妙方。当作为一个危机处理的时候，你是不能够抱太大的幻想把危机变成好事，你要做得就是尽量减少负面影响，然后再想办法亡羊补牢。有了这个原则和心态，结果也许会比你想象的更好一些。第一步，就事论事的承认问题，即使这个问题不是客观存在的，但是现在大家都不适当地被告知了和升级了，这本身就是问题。态度要好点，跟客户要积极承认错误。打脸不打笑脸，即使真的打，下手也会轻点的，对不？第二步，根据情况，尽力把问题转化为组织（甲方）和组织（乙方）之间的问题，千万千万不要最后搞成了对方项目经理和你（项目经理）之间的个人冲突，切记切记！内部的事情，应该在第一时间找汇报经理或项目主管汇报，让他们了解这个事情，并准备向大老板背书(所谓背书，就是按照想好的说辞向老板解释问题)。接下来，修复跟客户的关系，让对方意识到，抱怨之前应该先告知自己。亡羊补牢是必须的，建议使用上面的问题根源分析工具，方案务必在内部和外部说得通。需要注意的是，如有必要，让项目组团队的相关成员参与进来支持你，因为常常很多问题是技术或者业务相关的，千万不要孤身奋战。最后一点，面对原则问题，大是大非的问题千万不要让步。如果问题扩大并涉及到组织的根本利益，那么就应该奋起反击了，用句通俗的话，变成吵架了。你要找你“这边”的人，比如你的老板，跟客户上层关系不错的销售或者客户经理，吵的对象呢？找对方项目经理的主管来讲理。嗯，问题闹大了，是不是心里很慌？对方不按常理出牌，如果你屈服，那么肯定是悲惨的下场，斗一斗，好歹有几种可能啊：1. 对方项目经理认为不能再跟你合作，你被换掉，作为公司利益的维护者被换掉，多少还是能够挣点同情分吧？2. 不打不相识，双方达成谅解，继续合作。3. 对方项目经理怀恨在心，在以后的日子里处处为难。唉，这就是项目经理的悲惨人生啊，谁让你运气不好，碰上这么个客户呢。 就最后一点，也就是升级机制是双向的，举一个例子吧。2007年下半年，我们项目组一位资深的BA（业务分析师）跟客户的项目经理在周会时就项目的业务问题发展了激烈争吵（在会议室里），对方的项目经理十分恼火，进行了言语上的人身攻击（骂人呗），会议不欢而散。会后我们的业务分析师自然是十分不高兴的，个人跟客户的合作也变得不可能。但是针对客户的项目经理，我们认为骂人，不尊重人是不合适的，告知了对方的项目经理后，我、我的领导和销售找到了对方项目经理的主管，上报了这个事情。对方的项目经理虽然不是很爽，但是这的确是挑战了底线，作为项目经理就应该站出来维护团队的利益，当然后来再也没有发生类似不尊重我们项目组成员的情况。（关于升级机制部分 - 完）项目经理的生存之道（六） - 新人的适应时间 项目经理加入一家新公司，作为一个新人，新东家一般会给你多久的适应时间？诚然，做项目经理是一个非常好的工作，你的成功项目经验会为你的简历加分，同样你的失败经验也会为你增加不少的经验值，并且经验越丰富，你也就越值钱。换一个新单位是不是已经很容易的事情呢？未必，现在的企业都是不见兔子不撒鹰，有了具体项目才会来招项目经理，等你拿着“高薪”进公司时，项目已经等着你了，到项目里面屁股还没有坐热，已经有人在抱怨你不熟悉公司流程，项目管理混乱了，这时的你，该好好考虑考虑3个月的试用期了。遥想当年进HP的时候，第三天就去客户现场跟几十个IT客户做CMMi（软件能力成熟度模型）的培训，上午侃侃而谈3个小时，下面呼噜声一片。找到客户主管一问，他们听不太懂-_-，怎么办？午饭别吃了，征询客户的意见，同团队讨论，调整内容，选择简单易懂的部分，增加更多的互动和练习。接下来的日子里，每天都在变化，每天都在调整，当然也是状况不少，但是算是顺利成功结案。试想一下，如果没有及时的调整和适应，结果会怎么样？我想被轰回家的可能性很大。应该有完整的流程啊，入职培训，导师（mentor）制度，怎么会直接上战场呢？是的，所有的制度都有，也都在执行，但是对于项目经理这个角色来说，工作经验很丰富，怎么会有什么好的培训？导师又能够讲什么？一般都没有（我指导的项目经理除外）。一位资深的项目经理A，工作经验10年，进入公司没多久就开始管一个项目，项目是Onsite/Offshore方式，即客户现场/公司Office结合的方式，他是在客户现场。直接上战场，调整可真的不少：一般项目经理是怎么跟客户打交道的？公司办公司的团队的水平怎么样？公司有啥流程和质量约束？很快问题就暴露出来了，客户现场很多挑战，但勉强还能搞定，公司里的那一帮开发团队就搞不定了。客户压他，他就压后方的开发团队，项目一开始就出现了加班的状况，很快演变为周末两天也加班的状况。项目进行了2个月立即就变红了，招项目经理A的经理B就责无旁贷地进项目督战，很快他发现自己在看一个外公司的项目，因为项目经理A把自己在国企里面项目管理的那一套方法、模板全带进来了。但是项目进行到这个地步，整个团队天天都在熬，换项目经理？项目经理A的经理B不敢，也没有这个魄力。继续熬吧，项目继续地红。最后一根稻草是公司的质量部门的一次audit，结论大约是项目基本都没有遵守CMMi质量流程！这下事情就搞大了，项目变红的理由自然而然地被归咎到不遵循项目质量流程，项目经理A被质疑，项目经理A的经理B更是被质疑：你为什么会招他来管这个项目？结果：项目经理A在项目进行到5个月的时候被客户投诉回公司。项目最后失败，客户花大钱做的系统最终也没有上线，而公司也彻底失去了这个客户。项目经理A基本被打入冷宫，在未来的日子里再也没有得到好的项目机会，最后郁闷走人。就我的了解，项目经理A是一个成功的项目经理，所以他会被招进公司，于是乎他继续沿用曾经的成功经验，结果呢？败得一塌糊涂。失败的主要原因一定就是项目经理A吗？未必的，很多很多的原因，包括商务上的原因，但是“不熟悉公司流程和做事方式”把他死死地定在了耻辱柱上，难以翻身，从而成为当仁不让的替罪羊。项目经理A冤枉吗？从他的角度看，当然冤枉，之前没有人“详细”地跟他讲过这些要求就被派到客户现场了，哪有时间和机会来折腾啊，在前方累死累活，后方不支持就算了，还被后方不断质疑。还是承认现实吧，项目经理作为新人，就别奢望有多少的适应时间，想想怎么来应对吧。项目经理的生存之道（七） - 新人的适应时间（续） 上文谈到项目经理A进公司后直接就被扔到战场上，于是乎只好硬着头皮用自己的方法硬上，结果被内外质疑，无奈出局的案例，现在来看看解决方案。1. 主动申请评审（review）方法很简单，就是在上战场后，进行一段时间后，主动邀请方方面面对自己项目进行评审，比如计划