项目管理项目经理的生存之道.docx
《项目管理项目经理的生存之道.docx》由会员分享，可在线阅读，更多相关《项目管理项目经理的生存之道.docx（22页珍藏版）》请在冰点文库上搜索。
项目管理项目经理的生存之道
项目经理的生存之道
（一）-Howtosurviveasaprojectmanager?
到2009年为止，本人作为项目经理已经接近9年，成功完成大大小小的IT项目超过20多个。
在HP也做了几年的项目管理培训（对内和对外）和PMP认证培训的工作，2008年还获得了“StarOfYearofProjectLeadership”（1/3800）：
项目管理年度之星。
在对项目管理有诸多体会的同时，却发现自己身边有的项目经理同行们日子过得不是特别好，有菜鸟项目经理，资深的项目经理，成功的项目经理，却因为某些项目没有控制好，从而极大地影响了自己的职业发展。
项目结果不好，最好的情况是换一个项目，以图挽回之前失败的影响；其次的是没法再原来部门呆下去，考虑换部门；而最多的情况呢，自然是没法在组织呆下去，要不体面地走人，要不被扫地出门。
什么是项目结果不好？
我们先来看看项目经理这个角色，项目经理为项目的成败负责，其职责是建立并领导项目团队，全程控制项目流程（项目启动，项目计划，项目执行和项目结束），平衡项目进度，成本和范围的关系，并最终达到项目的目标。
在HP的几年里，身边就有不少的项目经理因为种种的原因离开（印象深的至少有10个），其中不少还没有等到项目结束就被换掉了，也就是说压根就没有看到项目的目标是否完成。
换句话讲，达成项目的目标并不是项目经理的第一目标，项目经理的第一目标应该是如何活下来，至少要熬到看到目标的那一天。
残酷的事实是，项目经理阵亡的比率太高了。
在过去的3个月里，我身边就有2例，并且这两位还是非常有经验的项目经理。
随着现在经济形势的发展，项目经理承担的项目越来越受到管理层的关注并被当成救命稻草，成功是必须的，失败是绝对不行的，稍有风吹草动，项目经理作为替罪羊的概率大大增加。
回想自己过去几年的项目管理经历，过程中不乏危机时刻，如果当时我没有处理好，会发生什么事情呢？
我想结局好不到哪里去，至少那个年度之星就别想了。
^_^
曾经有人问我一个很白的问题：
考了PMP证书，是不是就能够把项目管好？
很遗憾的是，上面提到阵亡的项目经理大多拥有PMP证书。
既然有PMP证书，自然是熟知项目管理的9大知识领域：
项目综合管理，项目范围管理，项目时间管理，项目成本管理，项目质量管理，项目人力资源管理，项目沟通管理，项目风险管理，项目采购管理；
并且我们还可以获得很多诸如项目模板（template），检查清单（checklist），历史项目资料等等对我们项目管理有用的数据和工具；
我们带领的团队基本都是比较熟悉的人员，自己对项目的领域也相当的熟悉。
既然这样，有理论知识，有工具，还有自己熟悉的团队，为什么项目经理还常常面临危机并可能被扫出项目呢？
作为一个项目经理，是不是有它的生存之道呢？
有句话说的好：
一年里你对女人的一千个好，比不上重要的一天（比如她生日）里的一个不好。
作为项目经理，允许犯错，但是在关键的问题和事情上绝对不能犯错。
这个“项目经理的生存之道”系列就是期望列出项目经理的一些雷区，总结在项目管理中的一些关键问题和关键挑战。
当然，对于每一种状况的应对方法都没有标准答案，期望的是带给大家更多的思考。
项目经理的生存之道
（二）-识别和管理关键项目干系人
（1）
[主要症状]这类项目经理认为，只要能够带领兄弟们埋头苦干，届时这样按时完成项目，质量还可以，成本不超就是项目大大的成功了。
何为项目干系人（ProjectStakeholder）是指积极参与项目的个人或者组织，并且会对项目的结果产生影响或者被项目的结果所影响；干系人可以是组织内、或者组织外的人。
项目干系人包括客户、监管机构、经理、分析师、开发者、测试者、文档编写人员、法律人员、销售、支持人员、制造人员等项目相关人员。
作为项目经理，如何整理和汇总项目干系人？
应当编写项目的通信录：
姓名，角色，主要职责，联系信息等等
如何管理项目干系人的沟通？
通过项目沟通管理计划来做到，考虑When（什么时候）、What（什么信息）、Who（什么人）、How（通过什么方式发布或者获得信息）
上面的大家都会，干系人很多，找出关键项目干系人更重要。
怎么样识别出关键项目干系人？
很多人相信自己的脑子，结果却是常常会忘掉或者漏掉一些，这里介绍一种结构化的方法：
建立一个评分等级和加权，从权利、需要、兴趣、知识等方面对主要干系人分析和评分，得分据前列的为关键干系人。
权力：
对项目的影响力
需要：
项目满足个人和位置（position）的需要程度，体现为对项目的关注。
兴趣：
对项目的参与度
知识：
对项目涉及专业知识的了解度
接下来的步骤是列出这些关键干系人的期望，他们会直接告诉你明明白白吗？
一般不会的。
尽力分析出来，特别是哪些互相冲突或矛盾的期望。
比如对于Time&Material的合同，客户期望能够成本尽量降低，而你的经理却希望钱收得越多越好。
项目经理的重要职责就是平衡这些关键关系人的期望，并在整个项目过程中跟踪这些期望。
注意：
期望是会变化的！
特别是组织内或组织外项目相关的人事或组织架构发生变化时，这时如果不及时调整，问题就大了！
除了管理干系人的期望外，还需要管理干系人，对于不同类型的关键干系人需要采取不同的策略。
第一类：
权力->高
兴趣/需要->高
知识->低
在你眼里，他/她可能是客户的项目经理或者领导，也可能是你的领导，他们具备影响项目的绝对权力，参与度很高，问题是他们对于项目涉及的专业知识掌握度很低。
你觉得人家水平低，人家自我感觉非常良好。
水平低就算了，还特喜欢发号施令，乱指挥，你说他不对他绝对跟你急。
“叉腰肌”的谢亚龙不就是这么一位么？
有这样的干系人，看看项目经理们（国足教练们）最后都干成咋样了？
<案例一>
对方是客户的领导（项目经理的领导），为了搞好关系，项目经理顺着这类干系人的思路进行项目，结果导致对方自我感觉膨胀，经常左右项目的走向和决策，项目经理的好意完全没有得到尊重，被斥为“专业知识不过关”，一气之下，顶了句嘴“啥都不懂吓指挥”，客户暴怒，连公司业务也受影响，项目经理也只好黯然离去。
<案例分析>
作为项目经理，控制自己的情绪很关键，生气的时候或者接近发飙的时候，先深吸一口气，给自己3秒钟时间问自己：
我真的要这样做吗？
即使不进行反击，项目就能顺利进行了嘛？
明显项目经理在处理这类干系人的策略不对。
<解决方案>
针对这类干系人，有以下的建议：
1.树立真正的专家形象，选择和包装自己团队的专家，并且能够震住对方，最好有什么名号。
让对方了解到成为专家的困难度，自然可能会考虑知难而退。
可行度：
五星
2.这类型的干系人更倾向于先进、最新技术、主流产品、国际标准等，在技术路线或者技术包装上需要考虑到这样的喜好倾向。
场景：
您的意见非常好，我们采用的是业界先进的方案，具备科学的设计和架构，...，我们可以考虑先用目前的方案，你的建议可以考虑在将来三期的时候规划。
真的是“业界先进”吗？
只要你能说服对方就行了。
可行度：
四星
3.在对方组织中寻找专家，并争取干系人可以授权给这位专家。
通过这样的方式，其需要仍然很好，但是兴趣会大幅降低，从而大大减少对项目的干预度
可行度：
五星，很多人从这方面想过，如果从一开始就考虑到这点，可操作性是很高的。
4.既然对方对项目涉及的专业知识缺乏了解，那么不妨挖一个小坑，并且结果在控制范围内，然后让其掉下去，你再来完美得收尾，送对方一个人情。
对付不见棺材不掉泪的主特适合，但是小心操作，不然搬起石头砸了自己的脚。
可行度：
两星
5.了解对方真正的需要是什么，尽力作为顾问的方式为其提供多种建设性方案来满足其需要，并用实际成果说服对方信任自己。
如果国足有很好的成绩，谢亚龙还会那么瞎折腾么？
可行度：
三星
说到底，我们希望最后达到的效果是：
权力->高（高）
需要->高（让对方意识并且相信减少参与，自己的个人和位置的需要也能得到满足）
兴趣->低（降低其参与度）
知识->低（让他/她意识到这个事实）
<后续思考>
其它类型的关键干系人如何合理呢？
第二类：
权力->高
需要->高（position的需要高）
兴趣->低
知识->高
这一类属于最容易忽略的关键干系人，也有实例证明一旦处理不当，后果是非常严重的。
大家思考一下如何处理？
第三类关键干系人：
权力->低
需要/兴趣->高
知识->低
下一章我会继续探讨这个问题，重点会关注2个案例：
1.第二类干系人管理
2.项目过程中客户期望发生变化时却沿用老方法处理。
项目经理的生存之道（三）-识别和管理关键项目干系人（续）
上一篇文章谈到下面这一类的重要项目关系人
权力->高
需要->高（position的需要高）
兴趣->低（项目的参与度低）
知识->高
为什么这类关键干系人容易忽略？
这类干系人具有很高的位置（比如项目经理的老板的老板或者技术和业务专家），这个项目的成功会为其带来很好的政绩，平时却不会出现在日常项目过程中，但是很可能突然有一天他/她因为种种原因跳出来给你一个大Surprise！
拿案例说事吧。
<案例>
角色A：
项目经理
角色B：
项目经理的直接汇报经理
角色C：
B的直接汇报经理
Areportto->Breportto->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）到他们，也就是说他们必须在cclist里面。
保证的机制是在沟通计划中专门加上这一项。
如果这类干系人质疑你的项目状况，你完全可以拿出曾经发送给他/她的所有历史记录，告诉其来龙去脉。
这类关键干系人的唯一缺点就是三高一低，这低的一点就是其项目的参与度很低，根本不会去查看所有的项目信息，但是这些项目信息会暗示他/她：
项目是在受控的持续进行的，自己是"可以"掌控这个项目的。
注意：
项目报告要有持续性和一致性，不要突然出现surprise。
2.利用这类干系人成为项目解决关键问题的重要力量：
不要以为高高在上的领导们高不可攀，既然被你定义为重要干系人，就好好地把他们给用起来。
你想象一下，有一个高层的老板一直在mailloop里面，会不会给一些人压力？
有压力就好办事啊，你大可以狐假虎威吧。
再换一个角度，这是不是一个很好的escalation的机会？
当然是了，持续在项目周报里面把重要issue标注成红色，如果不能解决，字体放大2倍，你放心，有人会在上面或明或暗帮你的。
3.提升其参与度
最好提升其参与度的方法就是适时地请其帮忙，利用其专业知识进行一些指点。
这类关键干系人适度参与了之后，会大幅增加项目的认同感。
原理很简单，专业知识（技术、业务或项目管理）强的人是非常乐意自己的知识发挥作用并被得到尊重的。
4.减少不合理的干涉
减少干涉的方法很简单：
重要的技术或者业务决策是通过集体决策得到，并且有明确的记录告知给这类干系人知道。
为什么，这样大幅增加其干涉的成本，因为普通人都有从众心理，并且如果想推翻这样的决议需要说服更多的人。
国内很多项目经理常常是业务、技术、项目管理一把手，特别喜欢做决策，如果项目中存在这类关键干系人，一定要特别注意，否则项目意见的不一致会完全上升到个人能力问题。
宁愿让其相信项目团队的能力问题，而不要让其坚信全是项目经理的问题。
简单点讲，直白点讲，用集体来保护自己。
事实也是这样呀，项目又不是出了啥天大的事情，干嘛用项目经理开刀？
5.寻找支撑点
如果真的发生大Boss突然参与到你的项目里面，并且是如案例中一样的质疑态度，应该怎么办？
首先一定要知道为何而来，知道其根源，利用各种原因探听真正的原因，只有这样才能对症下药；其次，一定要搞清楚其质疑的对象，是项目本身，项目经理还是项目中其他关键角色；如果很不幸，针对的就是项目经理，那么应该寻找到支撑点。
所谓支撑点，就是要寻求项目组内外的支持：
客户：
如果是内部的老板质疑你，客户的支持就很重要，在案例中的状况，如果你能说服客户给你发一封个人或者项目的“ThankLetter（感谢信）”，即使内容不痛不痒的也行，这绝对会促使质疑你的老板重新考虑：
是不是我只看到了问题的一方面而已？
你的老板：
在外企里，跟自己的直接汇报经理沟通是最多的，关键的时候一定要他/她支持你，即使不能根本解决问题，好歹也可以争取捞一个死缓啊。
案例里面的项目经理A压根就没有争取其项目经理B的支持，老板都搞不定，做啥项目经理呢？
重置成本：
作为项目经理，你应该在项目各方面参与得很深，比如客户关系管理，团队管理，项目流程，业务/技术/质量的一个方面以上，也就是说你是不可缺少的。
即使大Boss想用莫须有的借口让你成为某个事情的替罪羊，但是他/她得考虑重置成本（更换项目经理）啊，和谐至上嘛。
如果你可有可无，哼哼，上班在混日子吧。
说了那么多，有人问，遇上这么困苦的状况，我战略撤退，申请换个项目还不行嘛？
不行的，被高层贴上了“无能”的标签就意味着你在这个组织短时间没啥好混的了。
识别和管理关键项目干系人（完），请关注项目经理的生存之道的后续章节。
项目经理的生存之道（四）-问题升级机制
什么叫问题升级机制？
英文叫做IssueEscalationMechanism，是指当项目组出现问题，而这个问题超出项目经理级别的处理范围，因此将该问题升级到更高级别处理的机制。
听上去很简单，但是这句话有两个需要琢磨的地方：
升级的是什么问题？
升级到什么级别？
先来看问题的类型，通常，导致问题出现的原因有以下几个方面：
1.质量问题：
已交付的交付物或者系统功能存在质量问题
2.需求范围（Scope）问题：
经用户确认的业务需求，后来又发现有遗漏或者又提出新的需求
3.功能问题：
方案设计的功能与确认的需求有差异
4.运行问题：
方案设计已经符合确认的需求，但可能在运行性能、可靠性、可用性方面尚存在问题，这些问题常常会在如下方面对项目产生影响：
5.技术上的问题：
系统设计可能因此而有所改变
6.进度上的问题：
项目进度计划可能因此延误
7.合同上的问题：
可能需要对合同条款进行变更处理
8.合作的问题：
合作的人员的个人能力或者态度存在问题
很明显，不同的问题升级，代表着不同的后果。
在看看升级的级别，一般原则上的上报机制是：
Level1：
项目组成员——>Level2：
项目经理——>Level3：
项目经理的经理或者负责主管——>Level4：
项目指导委员会（如果有这样的一个组织）——>项目能够到的最高级主管，比如CEOorGM（据项目而定）
我们可以想象，项目组成员或者客户就不同的问题升级到更高级别的时候，会发生什么问题？
用案例来说话吧。
<案例一>
阶段一：
项目进行到关键时候，项目出现了一些质量问题，即客户在测试中发现了一些Bug，于是客户的项目经理B直接向项目经理A的大老板C（项目经理A的老板的老板）发email做正式的抱怨：
“针对xxx功能的bug问题，我们需要发出一个正式的客户抱怨。
以一个CMMiL5的国际大公司，在xxx功能中，经过你们的测试和质量控制，最后正式交道客户手中，居然存在这样的bug，实在难以令人理解。
......”。
试问，哪个项目不会在交付后还有bug？
但是大老板C会关心这些细节么？
他只关心的是：
客户很不爽，这个抱怨已经影响到了公司的声誉，于是他回了一封信郑重道歉，然后把项目经理A的老板叫过来，一顿教训。
项目经理A的老板啥状况都不知道（他不在mailloop里面）很郁闷，于是把项目经理A抓过来，也是一顿教训。
项目经理A很委屈，但也只能安排团队加班熬夜赶快解决问题了。
阶段二：
故事还没完，客户的项目经理B一看，一封email这么有效，项目经理A现在也老实了不少，过了1个月，他故伎重演，又来了一封抱怨信，当然这次是另外的bug了。
1次是偶然状况，但是2个月里连续2次就很让人紧张了，于是检讨的检讨，背书的背书，内部一致认为这个项目组质量控制不力，项目经理A有着不可推卸的责任！
替换项目经理的事宜也提上了内部日程。
阶段三：
项目经理A被彻底击垮了，当客户的项目经理B一提bug，立即条件反射般地回答“改，改，马上改”；客户的项目经理B要增加新的需求时，原想坚持这个需求不在范围之内，对方脸一横：
上次的bug的事情，我们还没有算账呢？
赤果果的威胁啊，我们可怜的项目经理只好屈辱地同意了。
结果：
非常容易就可以猜到结果了，不是吗？
<案例二>
在客户现场办公的项目，项目组有专门的房间（projectroom），两个BA（业务分析师）就业务问题有不同看法，争执不下，即使客户项目经理在场时也不避嫌，甚至还请其评理。
客户项目经理在后来的客户反馈中评论到：
“项目组成员沟通不畅，协助中存在着矛盾和推诿。
现场办公如此，很难相信他们可以同offshore的众多开发人员可以很好的协作。
”
结果：
两位BA没有过多久就因为种种原因非正常的打道回府。
项目组内部正常的业务争论，到了客户的耳朵里却有着明显不同的解读。
<分析>
做为项目经理，你碰到过类似项目经理A的遭遇吗？
有人会讲，客户的项目经理太不给面子了，客户关系没有搞好。
如果平时在一起多吃吃饭，喝喝酒，建立起个人感情，自然可以解决这个问题。
诚然建立个人感情会起到很好的作用，但是毕竟代表着甲方和乙方，代表着不同的利益关系，常常有时候吃饭喝酒建立起的感情会特别脆弱，比如或者对方的项目经理有着很大的内部压力的时候，上面列了那么多的问题类型，难道对方找不出可以做文章的内容么？
换一个角度，如果不是对方的项目经理越级升级，而是对方的团队成员或者自己的团队成员呢？
这类的状况也是不少，一旦控制不好状况，就会造成很难处理的困难局面。
到底是什么原因导致了这个案例的局面呢？
我们应该如何预防这种状况？
如果这个状况真的发生了，我们应该如何应对？
不当的问题升级会危及到项目及项目经理的生存，我们必须思考解决方案。
具体解决方案的建议请等候下一章节。
项目经理的生存之道（五）-问题升级机制（续）
在上篇文章中谈到了问题升级机制相关的两个案例，下面我们来探讨一下解决方案。
<解决方案>
先谈一下预防机制，预防的方法就是建立有效的“问题升级机制”。
第一步，在项目启动阶段的项目启动会议上正式宣布项目的问题升级机制，即上文所述的逐级升级机制：
Level1：
项目组成员——>Level2：
项目经理——>Level3：
项目经理的经理或者负责主管——>Level4：
项目指导委员会（如果有这样的一个组织）——>项目能够到的最高级主管，比如CEOorGM（据项目而定）。
这个升级机制需要注意的内容有四点：
1.双方都知道每一个的Level的人都是谁。
2.这个机制是双方都认可的。
3.既然是项目启动会议，尽量要求机制中提到的老板们到场。
4.升级机制是双向的：
也就是说，你（乙方）是可以向对方的主管（甲方）抱怨对方的项目经理的！
很令人吃惊的观点，我们不一定这样做，但是需要有这样的权力。
如果有可能，在项目的合同和工作说明书中尽量增加一章“问题解决机制”来阐述这一的机制。
为什么要做这一步？
一旦大家了解并认可这样的机制后，特别是大老板收到项目相关的抱怨时，他首先会倾向于认为他的下属了解这个事情，否则就是对方没有走正确的流程。
第二步，使用工具来引导和执行问题升级机制
首先是针对项目组成员级别的问题，使用
升级会员 