项目管理项目经理的生存之道.docx

1、项目管理项目经理的生存之道项目经理的生存之道 (一) - How to survive as a project manager?到2009年为止，本人作为项目经理已经接近9年，成功完成大大小小的IT项目超过20多个。在HP也做了几年的项目管理培训（对内和对外）和PMP认证培训的工作，2008年还获得了“Star Of Year of Project Leadership”（1/3800）：项目管理年度之星。在对项目管理有诸多体会的同时，却发现自己身边有的项目经理同行们日子过得不是特别好，有菜鸟项目经理，资深的项目经理，成功的项目经理，却因为某些项目没有控制好，从而极大地影响了自己的职业发展。

2、项目结果不好，最好的情况是换一个项目，以图挽回之前失败的影响；其次的是没法再原来部门呆下去，考虑换部门；而最多的情况呢，自然是没法在组织呆下去，要不体面地走人，要不被扫地出门。什么是项目结果不好？我们先来看看项目经理这个角色，项目经理为项目的成败负责，其职责是建立并领导项目团队，全程控制项目流程（项目启动，项目计划，项目执行和项目结束），平衡项目进度，成本和范围的关系，并最终达到项目的目标。在HP的几年里，身边就有不少的项目经理因为种种的原因离开（印象深的至少有10个），其中不少还没有等到项目结束就被换掉了，也就是说压根就没有看到项目的目标是否完成。换句话讲，达成项目的目标并不是项目经理的第一

3、目标，项目经理的第一目标应该是如何活下来，至少要熬到看到目标的那一天。残酷的事实是，项目经理阵亡的比率太高了。在过去的3个月里，我身边就有2例，并且这两位还是非常有经验的项目经理。随着现在经济形势的发展，项目经理承担的项目越来越受到管理层的关注并被当成救命稻草，成功是必须的，失败是绝对不行的，稍有风吹草动，项目经理作为替罪羊的概率大大增加。回想自己过去几年的项目管理经历，过程中不乏危机时刻，如果当时我没有处理好，会发生什么事情呢？我想结局好不到哪里去，至少那个年度之星就别想了。_曾经有人问我一个很白的问题：考了PMP证书，是不是就能够把项目管好？很遗憾的是，上面提到阵亡的项目经理大多拥有PMP

4、证书。既然有PMP证书，自然是熟知项目管理的9大知识领域：项目综合管理，项目范围管理，项目时间管理，项目成本管理，项目质量管理，项目人力资源管理，项目沟通管理，项目风险管理，项目采购管理；并且我们还可以获得很多诸如项目模板（template），检查清单（checklist），历史项目资料等等对我们项目管理有用的数据和工具；我们带领的团队基本都是比较熟悉的人员，自己对项目的领域也相当的熟悉。既然这样，有理论知识，有工具，还有自己熟悉的团队，为什么项目经理还常常面临危机并可能被扫出项目呢？作为一个项目经理，是不是有它的生存之道呢？有句话说的好：一年里你对女人的一千个好，比不上重要的一天（比如她生日

5、）里的一个不好。作为项目经理，允许犯错，但是在关键的问题和事情上绝对不能犯错。这个“项目经理的生存之道”系列就是期望列出项目经理的一些雷区，总结在项目管理中的一些关键问题和关键挑战。当然，对于每一种状况的应对方法都没有标准答案，期望的是带给大家更多的思考。项目经理的生存之道（二） - 识别和管理关键项目干系人(1)主要症状这类项目经理认为，只要能够带领兄弟们埋头苦干，届时这样按时完成项目，质量还可以，成本不超就是项目大大的成功了。何为项目干系人（Project Stakeholder）是指积极参与项目的个人或者组织，并且会对项目的结果产生影响或者被项目的结果所影响；干系人可以是组织内、或者组织

6、外的人。项目干系人包括客户、监管机构、经理、分析师、开发者、测试者、文档编写人员、法律人员、销售、支持人员、制造人员等项目相关人员。作为项目经理，如何整理和汇总项目干系人？应当编写项目的通信录：姓名，角色，主要职责，联系信息等等如何管理项目干系人的沟通？通过项目沟通管理计划来做到，考虑When（什么时候）、What（什么信息）、Who（什么人）、How（通过什么方式发布或者获得信息）上面的大家都会，干系人很多，找出关键项目干系人更重要。怎么样识别出关键项目干系人？很多人相信自己的脑子，结果却是常常会忘掉或者漏掉一些，这里介绍一种结构化的方法：建立一个评分等级和加权，从权利、需要、兴趣、知识等方

7、面对主要干系人分析和评分，得分据前列的为关键干系人。权力：对项目的影响力需要：项目满足个人和位置(position)的需要程度，体现为对项目的关注。兴趣：对项目的参与度知识：对项目涉及专业知识的了解度接下来的步骤是列出这些关键干系人的期望，他们会直接告诉你明明白白吗？一般不会的。尽力分析出来，特别是哪些互相冲突或矛盾的期望。比如对于Time&Material的合同，客户期望能够成本尽量降低，而你的经理却希望钱收得越多越好。项目经理的重要职责就是平衡这些关键关系人的期望，并在整个项目过程中跟踪这些期望。注意：期望是会变化的！特别是组织内或组织外项目相关的人事或组织架构发生变化时，这时如果不及时调

8、整，问题就大了！除了管理干系人的期望外，还需要管理干系人，对于不同类型的关键干系人需要采取不同的策略。第一类：权力-高兴趣/需要-高知识-低在你眼里，他/她可能是客户的项目经理或者领导，也可能是你的领导，他们具备影响项目的绝对权力，参与度很高，问题是他们对于项目涉及的专业知识掌握度很低。你觉得人家水平低，人家自我感觉非常良好。水平低就算了，还特喜欢发号施令，乱指挥，你说他不对他绝对跟你急。“叉腰肌”的谢亚龙不就是这么一位么？有这样的干系人，看看项目经理们（国足教练们）最后都干成咋样了？对方是客户的领导（项目经理的领导），为了搞好关系，项目经理顺着这类干系人的思路进行项目，结果导致对方自我感觉膨

9、胀，经常左右项目的走向和决策，项目经理的好意完全没有得到尊重，被斥为“专业知识不过关”，一气之下，顶了句嘴“啥都不懂吓指挥”，客户暴怒，连公司业务也受影响，项目经理也只好黯然离去。作为项目经理，控制自己的情绪很关键，生气的时候或者接近发飙的时候，先深吸一口气，给自己3秒钟时间问自己：我真的要这样做吗？即使不进行反击，项目就能顺利进行了嘛？明显项目经理在处理这类干系人的策略不对。针对这类干系人，有以下的建议：1. 树立真正的专家形象，选择和包装自己团队的专家，并且能够震住对方，最好有什么名号。让对方了解到成为专家的困难度，自然可能会考虑知难而退。可行度：五星2. 这类型的干系人更倾向于先进、最新

10、技术、主流产品、国际标准等，在技术路线或者技术包装上需要考虑到这样的喜好倾向。场景：您的意见非常好，我们采用的是业界先进的方案，具备科学的设计和架构，.，我们可以考虑先用目前的方案，你的建议可以考虑在将来三期的时候规划。真的是“业界先进”吗？只要你能说服对方就行了。可行度：四星3. 在对方组织中寻找专家，并争取干系人可以授权给这位专家。通过这样的方式，其需要仍然很好，但是兴趣会大幅降低，从而大大减少对项目的干预度可行度：五星，很多人从这方面想过，如果从一开始就考虑到这点，可操作性是很高的。4. 既然对方对项目涉及的专业知识缺乏了解，那么不妨挖一个小坑，并且结果在控制范围内，然后让其掉下去，你再

11、来完美得收尾，送对方一个人情。对付不见棺材不掉泪的主特适合，但是小心操作，不然搬起石头砸了自己的脚。可行度：两星5. 了解对方真正的需要是什么，尽力作为顾问的方式为其提供多种建设性方案来满足其需要，并用实际成果说服对方信任自己。如果国足有很好的成绩，谢亚龙还会那么瞎折腾么？可行度：三星说到底，我们希望最后达到的效果是：权力-高 （高）需要-高 （让对方意识并且相信减少参与，自己的个人和位置的需要也能得到满足）兴趣-低 （降低其参与度）知识-低 （让他/她意识到这个事实）其它类型的关键干系人如何合理呢？第二类：权力-高需要-高（position的需要高）兴趣-低知识-高这一类属于最容易忽略的关键

12、干系人，也有实例证明一旦处理不当，后果是非常严重的。大家思考一下如何处理？第三类关键干系人：权力-低需要/兴趣-高知识-低下一章我会继续探讨这个问题，重点会关注2个案例：1. 第二类干系人管理2. 项目过程中客户期望发生变化时却沿用老方法处理。项目经理的生存之道（三） - 识别和管理关键项目干系人(续)上一篇文章谈到下面这一类的重要项目关系人权力-高需要-高（position的需要高）兴趣-低(项目的参与度低)知识-高为什么这类关键干系人容易忽略？这类干系人具有很高的位置（比如项目经理的老板的老板或者技术和业务专家），这个项目的成功会为其带来很好的政绩，平时却不会出现在日常项目过程中，但是很可

13、能突然有一天他/她因为种种原因跳出来给你一个大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

14、天从侧面了解项目，基于自己的知识和经验，觉得项目周报有问题，于是要求B进行整改（注意，这个阶段还没有直接跟项目经理A直接联络）。项目经理A通过自己老板B得到这样的要求后，当然说好，但是项目事情很多，这个要求又经过了自己老板B的转述，也就没有把优先级放得特别高。阶段二：C开始看第二个月的项目周报，发觉居然没有啥改进，立即question自己的下属B，B由于对本项目参与不多，好多事情也回答不出来，那么C的判断就是：A没有执行力；没人在控制这个项目。阶段三：第三个月，C十分不满，决定自己跳进去看这个案子，C这个时候进来看这个案子，基于之前的两个月的经历，对项目经理A已经是带着有色眼镜来看问题了。而我

15、们可爱的项目经理呢，他并不了解过去1个月在B和C之间发生的所有事情，也并没有了解到事情的严重性！C由于具备很强的知识，自然很轻易地找出来项目的一堆问题和潜在问题，谁是责任人呢？这个时候自然会归咎于项目经理A，为什么？因为在C的眼里，很多事情在2个月前就已经交待了，却没有得到跟进和改善！作为项目经理，我们自问：我们的项目是否都是很完美的？不会的，总会找出一堆问题来的，关键是找问题的人怎么看这些问题。项目经理A怎么看C的突然加入呢？级别高两级给他巨大的压力，C提出的事情做不做？A的回答都是“好”。阶段四：问题升级和爆发了，项目经理A对C的要求都是回答“好”，但是这是积累了好长时间的issues，哪

16、有那么容易就搞定啊，关键的是，项目经理A没有证据来支持自己为什么无法按时完成。C很紧张这个项目，现在发现项目经理A总是响应缓慢，由于又是在客户现场带项目，并不习惯经常跟C汇报。对C来说，判断就是：虽然自己介入，却由于项目经理A执行力差而无法改善，项目危险！阶段五：问题定位到人就很简单了，解决方案只有一个：换项目经理。最后结果：项目经理A被开了“绩效警告信”，为了避免被直接开除，只好1个月后黯然离职走人。就这样，刚刚3个月，项目经理A就阵亡了，至于客户是否答应这次换人，换人后新项目经理干得怎么样，就不是这个案例的内容了。 这个案例中的关键干系人是来自自己的组织的，常常更难处理的来自客户的这类人员

17、，比如一个IT开发项目进行到中途，客户的技术架构部门跳出来，说这个项目的架构不符合他们的技术要求；或者客户的高级主管突然跳进来对项目进行粗暴干涉。 这类状况的常见现象就是你突然发现你认知的”关键干系人“突然不顶事了，他们也顶不住更高干系人的压力。 项目经理A为什么会阵亡？在他个人的认知中， 客户没有问题，自己老板B没有问题，团队也没人拆台，为啥还会被钉着打？最后还死得不明不白呢？有三点：没有识别出C这个重要干系人；没有避免C直接介入；C介入后也应该顶住。 头疼啊，权力高的干系人，平时可是不容易见到的，处理好了，自然是为项目经理个人大大加分；处理不好，权力高，自然也具备直接枪毙项目经理的权力，结

18、果如何全看人家心情了。 说点自个的事情，进HP不久后带一个重要的项目，大Boss（老板的老板）在启动阶段连续跟进了1个月，然后放心地不管了，这段时间给了其非常正面的印象，相信对日后我的升职肯定有着不小的正面影响（在外企，跨级沟通的机会并不多的）。 如果有效管理这类干系人？1. 及时告知 - 改进沟通机制 这类干系人基于自己的需要，因此期望项目是受控的，是稳定的，因此所有项目的关键信息，关键决定， 项目状态必须要知会（cc）到他们，也就是说他们必须在cc list里面。保证的机制是在沟通计划中专门加上这一项。如果这类干系人质疑你的项目状况，你完全可以拿出曾经发送给他/她的所有历史记录，告诉其来龙

19、去脉。这类关键干系人的唯一缺点就是三高一低，这低的一点就是其项目的参与度很低，根本不会去查看所有的项目信息，但是这些项目信息会暗示他/她：项目是在受控的持续进行的，自己是可以掌控这个项目的。 注意：项目报告要有持续性和一致性，不要突然出现surprise。2. 利用这类干系人成为项目解决关键问题的重要力量： 不要以为高高在上的领导们高不可攀，既然被你定义为重要干系人，就好好地把他们给用起来。你想象一下，有一个高层的老板一直在mail loop里面，会不会给一些人压力？有压力就好办事啊，你大可以狐假虎威吧。再换一个角度，这是不是一个很好的escalation的机会？当然是了，持续在项目周报里面把

20、重要issue标注成红色，如果不能解决，字体放大2倍，你放心，有人会在上面或明或暗帮你的。3. 提升其参与度最好提升其参与度的方法就是适时地请其帮忙，利用其专业知识进行一些指点。这类关键干系人适度参与了之后，会大幅增加项目的认同感。原理很简单，专业知识（技术、业务或项目管理）强的人是非常乐意自己的知识发挥作用并被得到尊重的。4. 减少不合理的干涉减少干涉的方法很简单：重要的技术或者业务决策是通过集体决策得到，并且有明确的记录告知给这类干系人知道。为什么，这样大幅增加其干涉的成本，因为普通人都有从众心理，并且如果想推翻这样的决议需要说服更多的人。国内很多项目经理常常是业务、技术、项目管理一把手，

21、特别喜欢做决策，如果项目中存在这类关键干系人，一定要特别注意，否则项目意见的不一致会完全上升到个人能力问题。宁愿让其相信项目团队的能力问题，而不要让其坚信全是项目经理的问题。简单点讲，直白点讲，用集体来保护自己。事实也是这样呀，项目又不是出了啥天大的事情，干嘛用项目经理开刀？ 5.寻找支撑点如果真的发生大Boss突然参与到你的项目里面，并且是如案例中一样的质疑态度，应该怎么办？首先一定要知道为何而来，知道其根源，利用各种原因探听真正的原因，只有这样才能对症下药；其次，一定要搞清楚其质疑的对象，是项目本身，项目经理还是项目中其他关键角色；如果很不幸，针对的就是项目经理，那么应该寻找到支撑点。所谓

22、支撑点，就是要寻求项目组内外的支持：客户：如果是内部的老板质疑你，客户的支持就很重要，在案例中的状况，如果你能说服客户给你发一封个人或者项目的“Thank Letter（感谢信）”，即使内容不痛不痒的也行，这绝对会促使质疑你的老板重新考虑：是不是我只看到了问题的一方面而已？你的老板：在外企里，跟自己的直接汇报经理沟通是最多的，关键的时候一定要他/她支持你，即使不能根本解决问题，好歹也可以争取捞一个死缓啊。案例里面的项目经理A压根就没有争取其项目经理B的支持，老板都搞不定，做啥项目经理呢？重置成本：作为项目经理，你应该在项目各方面参与得很深，比如客户关系管理，团队管理，项目流程，业务/技术/质量

23、的一个方面以上，也就是说你是不可缺少的。即使大Boss想用莫须有的借口让你成为某个事情的替罪羊，但是他/她得考虑重置成本（更换项目经理）啊，和谐至上嘛。如果你可有可无，哼哼，上班在混日子吧。说了那么多，有人问，遇上这么困苦的状况，我战略撤退，申请换个项目还不行嘛？不行的，被高层贴上了“无能”的标签就意味着你在这个组织短时间没啥好混的了。识别和管理关键项目干系人（完），请关注项目经理的生存之道的后续章节。项目经理的生存之道（四）-问题升级机制什么叫问题升级机制？英文叫做Issue Escalation Mechanism，是指当项目组出现问题，而这个问题超出项目经理级别的处理范围，因此将该问题升

24、级到更高级别处理的机制。听上去很简单，但是这句话有两个需要琢磨的地方：升级的是什么问题？升级到什么级别？先来看问题的类型，通常，导致问题出现的原因有以下几个方面： 1. 质量问题：已交付的交付物或者系统功能存在质量问题 2. 需求范围（Scope）问题：经用户确认的业务需求，后来又发现有遗漏或者又提出新的需求 3. 功能问题：方案设计的功能与确认的需求有差异 4. 运行问题：方案设计已经符合确认的需求，但可能在运行性能、可靠性、可用性方面尚存在问题，这些问题常常会在如下方面对项目产生影响： 5. 技术上的问题：系统设计可能因此而有所改变 6. 进度上的问题：项目进度计划可能因此延误 7. 合同

25、上的问题：可能需要对合同条款进行变更处理 8. 合作的问题：合作的人员的个人能力或者态度存在问题很明显，不同的问题升级，代表着不同的后果。在看看升级的级别，一般原则上的上报机制是： Level1：项目组成员Level2：项目经理Level3：项目经理的经理或者负责主管Level4：项目指导委员会（如果有这样的一个组织）项目能够到的最高级主管，比如CEO or GM（据项目而定）我们可以想象，项目组成员或者客户就不同的问题升级到更高级别的时候，会发生什么问题？用案例来说话吧。阶段一：项目进行到关键时候，项目出现了一些质量问题，即客户在测试中发现了一些Bug，于是客户的项目经理B直接向项目经理A的

26、大老板C（项目经理A的老板的老板）发email做正式的抱怨：“针对xxx功能的bug问题，我们需要发出一个正式的客户抱怨。以一个CMMi L5的国际大公司，在xxx功能中，经过你们的测试和质量控制，最后正式交道客户手中，居然存在这样的bug，实在难以令人理解。.”。试问，哪个项目不会在交付后还有bug？但是大老板C会关心这些细节么？他只关心的是：客户很不爽，这个抱怨已经影响到了公司的声誉，于是他回了一封信郑重道歉，然后把项目经理A的老板叫过来，一顿教训。项目经理A的老板啥状况都不知道（他不在mail loop里面）很郁闷，于是把项目经理A抓过来，也是一顿教训。项目经理A很委屈，但也只能安排团队

27、加班熬夜赶快解决问题了。阶段二：故事还没完，客户的项目经理B一看，一封email这么有效，项目经理A现在也老实了不少，过了1个月，他故伎重演，又来了一封抱怨信，当然这次是另外的bug了。1次是偶然状况，但是2个月里连续2次就很让人紧张了，于是检讨的检讨，背书的背书，内部一致认为这个项目组质量控制不力，项目经理A有着不可推卸的责任！替换项目经理的事宜也提上了内部日程。阶段三：项目经理A被彻底击垮了，当客户的项目经理B一提bug，立即条件反射般地回答“改，改，马上改”；客户的项目经理B要增加新的需求时，原想坚持这个需求不在范围之内，对方脸一横：上次的bug的事情，我们还没有算账呢？赤果果的威胁啊，

28、我们可怜的项目经理只好屈辱地同意了。结果：非常容易就可以猜到结果了，不是吗？在客户现场办公的项目，项目组有专门的房间（project room），两个BA（业务分析师）就业务问题有不同看法，争执不下，即使客户项目经理在场时也不避嫌，甚至还请其评理。客户项目经理在后来的客户反馈中评论到：“项目组成员沟通不畅，协助中存在着矛盾和推诿。现场办公如此，很难相信他们可以同offshore的众多开发人员可以很好的协作。”结果：两位BA没有过多久就因为种种原因非正常的打道回府。项目组内部正常的业务争论，到了客户的耳朵里却有着明显不同的解读。做为项目经理，你碰到过类似项目经理A的遭遇吗？有人会讲，客户的项目经

29、理太不给面子了，客户关系没有搞好。如果平时在一起多吃吃饭，喝喝酒，建立起个人感情，自然可以解决这个问题。诚然建立个人感情会起到很好的作用，但是毕竟代表着甲方和乙方，代表着不同的利益关系，常常有时候吃饭喝酒建立起的感情会特别脆弱，比如或者对方的项目经理有着很大的内部压力的时候，上面列了那么多的问题类型，难道对方找不出可以做文章的内容么？换一个角度，如果不是对方的项目经理越级升级，而是对方的团队成员或者自己的团队成员呢？这类的状况也是不少，一旦控制不好状况，就会造成很难处理的困难局面。到底是什么原因导致了这个案例的局面呢？我们应该如何预防这种状况？如果这个状况真的发生了，我们应该如何应对？不当的问

30、题升级会危及到项目及项目经理的生存，我们必须思考解决方案。具体解决方案的建议请等候下一章节。项目经理的生存之道（五）-问题升级机制（续）在上篇文章中谈到了问题升级机制相关的两个案例，下面我们来探讨一下解决方案。先谈一下预防机制，预防的方法就是建立有效的“问题升级机制”。第一步，在项目启动阶段的项目启动会议上正式宣布项目的问题升级机制，即上文所述的逐级升级机制：Level1：项目组成员Level2：项目经理Level3：项目经理的经理或者负责主管Level4：项目指导委员会（如果有这样的一个组织）项目能够到的最高级主管，比如CEO or GM（据项目而定）。这个升级机制需要注意的内容有四点：1. 双方都知道每一个的Level的人都是谁。2. 这个机制是双方都认可的。3. 既然是项目启动会议，尽量要求机制中提到的老板们到场。4. 升级机制是双向的：也就是说，你（乙方）是可以向对方的主管（甲方）抱怨对方的项目经理的！很令人吃惊的观点，我们不一定这样做，但是需要有这样的权力。如果有可能，在项目的合同和工作说明书中尽量增加一章“问题解决机制”来阐述这一的机制。为什么要做这一步？一旦大家了解并认可这样的机制后，特别是大老板收到项目相关的抱怨时，他首先会倾向于认为他的下属了解这个事情，否则就是对方没有走正确的流程。第二步，使用工具来引导和执行问题升级机制首先是针对项目组成员级别的问题，使用