http://www.cooboy.com/index.php zh-cn http://www.cooboy.com/read.php?288 大虫 <hujuan30@hotmail.com> Sun, 27 Jun 2010 17:59:56 +0000 http://www.cooboy.com/read.php?288

需要用户签字确认的项目正式交付文档主要是需求规格说明书（SRS），变更单（CR）和用户验收报告。然而要获取用户对于这些正式交付物却是非常的困难：
用户迟迟不愿意对需求签字，从而常常导致设计开发都进行一段时间了，而需求还没有最后确认，用户还在频繁的对需求进行修改，自然，这些修改可能都不算变更！
只要有缺陷，用户就不愿意在验收报告上签字，甚至试运行一段时间后都因为一些缺陷而得不到签字。
为啥会出现这样的情况？签字确认意味着将来出现状况时需要承担责任，所以所有人基于安全的角度，会尽力地拖延签字。
我们以甲方和乙方为例来描述，一旦甲方在需求上签字，那么就意味着以后所有的对需求的调整都会成为“变更”，甲方会额外支付这些变更。而对于乙方来说，一旦得到这些签字确认，那么就可以光明正大得要求甲方付款。
用户们拖延签字的理由就更是林林总总：
    1. 交付物还存在问题/不确认性；（呵呵，找出一些小问题还是很容易的，双方你来我往的讨论，很快几周时间就混过去了）
    2. 签字责任人出差；（现在通信技术这么发达，出差也能成为不签字的理由？项目那么重要，难道比不上出差吗？这个明显是个理由）
    3. 工作太忙，没有时间看；（这个就是明明白白的“拖”字诀了）
    4. 需要内部人员评审；（一看就知道，这是在拿所谓的内部流程在踢皮球）

所以不及时签字是项目进行过程中一个十分痛苦的事情。有什么解决方案吗？国内项目的实践很简单：让销售去搞定。。。所谓搞定，无外乎请客，交易，拉关系，或者请自己领导出面协调、承诺
。在国内项目管理越来越规范的大趋势下，这样的方法就略显不足了，需要有新的方法。

方法一：签字文档化整为零。（方法有效性：90%）
一个需求文档至少几十页到上百页，让用户一下或者一段时间完全签字确认整份文档十分困难。通过系统的方法把文档分为较小的部分（比如用例，模块或者子系统），用户只需要对确定的部分签字，而不确定的部分等澄清后再确认。
文档如何化整为零是需要技术的，整个框架需要有明确的逻辑性和合理性。


方法二：至下而上的签字流程。（方法有效性：80%）
签字责任人常常是负责的经理或领导，对于他们来说，很多细节可能不会特别深入或者了解，强求他们马上签字有些难度，但是如果他们看到自己的手下的签字，那么他会放心得多，也就容易签字。

方法三：安全的集体决策。（方法有效性：70%）
举行正式的交付物评审，有与会的相关项目干系人是否“原则上”同意该项交付物。请注意“原则上同意”这个词很重要，它不会给参与评审的人员太大压力，同时又是一个定调调的决议，对于后续的推进具有关键性的作用。
注意：有把握再进行这样的评审，否则被攻击而被批为“漏洞百出”会很杯具。如果关键项目干系人找理由不参加这个会议，如果这样的事情发生，那么会更杯具了，它会极大阻碍后续的签字进程。

方法四：用户充分参与交付物的编写。（方法有效性：60%）
在重要交付物的编写过程中，充分调动用户的参与性，让他们能够充分了解并参与整个过程，基于这样的并肩战斗，用户会相当信任对方以及双方的共同产出物，自然也更容易签字了。
注：用户充分参与基本上属于可遇不可求。事实上，这里强调的是同用户融洽的个人/工作关系可以一定程度上帮助获得用户的签字。

方法五：带备注的签字确认。（方法有效性：100%）
一般的签字只包括两项内容：签字人名字和签字日期。而带备注的签字就更加的灵活，比如对于一项有不确定性的需求签字可能是这样的;
----
原则上确认本项需求，确认的前提是：
    A，B，C开放的问题仍需讨论并解决。（open issues）
    D，E，F可能需要调整。（risks）
    该需求基于G条件被满足的情况下。（assumption）
xxx（用户的名字）
日期
----
有了这样一份签字确认，那么可以极大的加快整体签字进程，同时这些备注也是非常重要的资料，让我们知道最近的工作重点以及将来可能的变更点。
如果是一份用户验收报告，那么部分签字的例子可能是这样的：
---
原则上验收本项需求，前提是：
   目前未解决的5个缺陷需在2010年6月30日前修改并测试正确。
   如果针对5个缺陷的版本导致其它功能错误，那么本项验收以及相关功能的验收确认无效，需完全重新进行验收测试。
---    
如何关闭这些备注呢？如果所有问题在后续过程中已解决，那么可以把调整后的部分请用户签字，或者再打印一份出来进行签字确认。

方法六：定期跟踪签字进程并在适当时候升级到更高级别管理层。（方法有效性：50%）
这个方法用于对付那么不讲道理能拖就拖的用户，定期跟踪签字进程实际是在每周的项目报告中把用户放到热锅上，每过一周温度升高一点，知道用户最后无法坚持而已。用户不得不在签字可能会承担责任/承担因为不签字而项目延迟的责任中间考虑。
注：这招只能在你方无过错，原因只是用户拖延的情况。

方法七：客户关系。（方法有效性：80%）
用户签字意味着承担责任，同时它也是一种权力，对于乙方来说，需要尊重这样的权力，必要的时候请销售/高管参与是必要的，特别是用户验收报告的签字，上述6种方法是不足够的，必须要相关人出面才能够搞定。
当然，必须得符合商业业务规则。

有了上述的7种方法，那么在寻求用户签字确认时，需要根据实际情况制定战略，并选择一个合适的组合，从而实现及时的、有效的签字确认。

阿根廷：墨西哥的比赛马上就要开始了，先写到这里吧，以后有补充再加。

Tags - 项目管理 , 用户签字 , 签字确认 , 项目管理实践 , 项目经理 ]]> http://www.cooboy.com/read.php?280 大虫 <hujuan30@hotmail.com> Tue, 18 May 2010 05:57:08 +0000 http://www.cooboy.com/read.php?280 如下图所示的死亡滑梯（The Death Spiral），项目经理一旦进入这样的悲惨状况，阵亡率是相当的高！先来看看什么是死亡滑梯。



[第一部分：什么是死亡滑梯]

第一步：出现状况（Over-run）

项目出现了状况，常见的状况是
        人力资源不能按时到位，或者关键人员离开项目组
        进度延迟
        估算不足，实际工作量远远超过估算值
        成本超支
        增加大量变更，项目范围扩大
  也许真实情况是出现上述状况之一或者多个，你收到这样的坏消息后，简单评估就会知道：如果什么都不做，那么项目绝对不会按时完工。

第二步：面对独自挽回的压力（Pressure to recover）

  一般项目经理碰到这个状况有两种选择：
       选择一：报喜不报忧，自己想办法解决，直到发现彻底崩盘，自己无法搞定为止。
   选择二：报告给自己的经理。
 中国人的传统就是报喜不报忧，绝大多数项目经理都会认为虽然出现了状况，但是却在自己控制范围之中，选择自己搞定。而报告给自己的经理，常常得到的答复是：我知道了。或者给予你更大的压力：赶快想办法搞定了！这个项目真的很重要，必须成功！于是项目经理屈服了，继续回到选择一。
  第三步：压缩进度（Compress Schedule）
  压缩进度，可以有多个选择：
       1. 加班（平时加班/周末加班/节假日加班）
       2. 将并行任务调整为串行任务
       3. 减少范围
       4. 增加资源
       5. 提升生产效率
 从技术上说，的确存在上述5种方法来压缩进度，然而绝大多数项目经理却毫不犹豫的选择了第一个选择：加班。为什么？
 首先，项目经理对加班的认识。加班似乎是“解决状况”最有效的方法，做IT的谁不加班啊，加加班有啥关系呢。
 其次，加班是最容易的方法，其它方法都很复杂，涉及到方方面面的谈判、协调和调整，但是加班就不一样，项目经理说一声，发个email，项目组成员就乖乖的加班了。
 最后，加班是可见度最高的一种方法。领导问：项目出状况了，你们怎么做的呀？答复：我们很努力，再加班加点解决！领导还能指责一个辛苦加班的团队吗？相反，领导会尽力安慰大家：同志们辛苦了！
 

第四步： 士气低落（Ruduce morale）
 一开始的加班的确效率很高，如果10个人周末统一加班一天，可以产生10个人天的工作量，但是随着长时间的加班，士气就开始低落了。
 据统计，加班能够保持士气的最长时间是1个月，换句话说，如果连续加班超过一个月，那么加班就是为了加班而加班，士气会急剧低落。为什么会低落，项目组成员看不到未来，不知道自己还要熬多久！
 加班超过一个月，项目组成员想的是：如何全身而退，离开这个鬼项目！但是每人都害怕因为退出而被当成替罪羊，于是会开始“假装”加班。
 
第五步：生产率降低（Reduce productivity）

 士气低落的项目组团队都会选择消极抵抗，我们来看看一个连续2个月加班的项目组成员是如何工作的：
 早上-10点半到达公司，原因是上一天加班得太晚，11点多才离开工作。
 到达公司后，先看看email，再上网看看新闻，最后看看自己程序的bug，一晃就11点多了，决定早点去吃饭。
 吃饭吃到大概12点半，一般下午1点多开始工作，于是休息一会儿，大概1点半的时候还是有点困，同同事围着办公楼转转，下午2点左右回到座位。
 下午两点，参加一个项目组会议，大家吵啊吵，最后也没啥结论，会议延长，开到三点半才结束。
 一看不行，都下午3点多了，开始改程序，做到大概5点多。
 5点多时没有心思做事，心思想着去吃饭了。
 6点多去吃饭，吃到晚上7点半。（这个时间不长，大家吃吃饭，发发牢骚，再聊聊天，时间过得很快的）。
 7点半开始晚上的工作，发觉当天的任务完成的不多，于是赶快开始工作，奋战到晚上10：30，觉得好疲惫，再收收尾到11点，哈欠连天准备打车回家，大家11点半，洗脸刷牙睡觉12点多了。
 
 我们看看这样的一天，上午基本是混过的，下午是准备工作，晚上才是真的工作时间，项目组成员足够努力吗？相当努力，基本上把一天时间中除了睡觉都贡献给了项目。真正做事的时间呢？下午2个多小时，晚上3个多小时，其效能是远不如不加班有效工作8小时的效果。
 
 第六步：状况进一步恶化（Over-run）
 生产率降低，士气低落，情况变得更加糟糕。项目经理原以为整个项目组加班可以解决问题，事实却越来越糟。这时候项目经理怎么办？捂是捂不住了，只能汇报给自己的经理。对于经理来说，虽然情况糟糕，却“似乎”在他的控制范围之内。于是问项目经理有什么要求？一般情况下是在保证进度的前提下，大量加人。
 为什么会要求加人，而不是延长进度？延长进度常常涉及到客户、涉及到业务和市场，影响非同小口，而经理别的没有，就是有人。简单衡量一下，加人是最直接的办法。为什么项目经理会接受呢？跟要求加班一样，项目经理常常相信数学。
 比如估算项目工作量缺口为10人月，剩余周期为5个月，10/5=2人，项目经理没有那么傻，现在的项目经理都看过人月神话，于是会要求增加3个人。
 新增3个人能够解决问题吗？
 首先，项目组不会因为新增3个人而取消加班。原因很简单，项目情况未好转，还在变糟，不可能不加班。
 其次，在士气低落的情况下，新增加的3个人会大幅增加项目组原有成员的沟通成本，使原有成员的有效工作时间减少，加剧抱怨。
 最后，新增人员很快发现自己进入了错误的项目，效率同样降低。
 
 就这样，项目在死亡滑梯中越滑越快，不出意外，这个项目会照这样的状况一直变糟，直到彻底崩溃为止。

[死亡滑梯的特性]
 讲到这里，大家明白了什么是死亡滑梯，其实说白了，不就是恶性循环嘛。我想强调的是，死亡滑梯有几个特性：
1. 一旦项目进入死亡滑梯，那么会非常非常困难从滑梯中出来，除非项目终止，项目失败结束；即使项目经理阵亡也不能确保从死亡滑梯中全身而退。

2. 一旦项目进入死亡滑梯，那么即使解决掉导致当初进入死亡滑梯的根本原因，仍然不能帮助项目从滑梯中出来。比如当初项目进入死亡滑梯的原因是因为成本超支，那么你大幅增加预算并不能改善项目的状况。

3. 不进入死亡滑梯的最佳方法就是在项目刚出现状况的时候确保避免进入死亡滑梯。 在一开始的时候顶住压力，不要给你团队施压，强迫他们压缩进度。如果你的经理施加压力要求压缩进度，你应该坚持一个现实而略有挑战的目标和计划。这一点正是众多的项目经理难以做到的，有时候真的要敢于说“不”。

 死亡滑梯是真实存在的，我观察过的所有红项目都居然上述的典型路线和特征，也看到很多项目经理因为进入死亡滑梯而阵亡。


[死亡滑梯的解决方案]
 那么如果发现自己项目进入了死亡滑梯，到底应该怎么办，有没有什么办法可以软着陆？  有人讲，我的项目不会进入到死亡滑梯，所以不用考虑。别忘了，你很有可能会被指派到一个进入死亡滑梯的项目担任救火队员，做项目经理。下面是我个人的建议：

 1. 让各方（包括项目组成员，客户，项目经理的经理）意识到项目已经进入了死亡滑梯，同时让各方明白现在项目进入的是第几级的死亡滑梯。说来容易，真正做到很难，没人喜欢听到坏消息，大家会倾向于认为你是过度反应。如果你之前就是该项目的项目经理，即使有很多客观原因，这相当于公开承认你个人的无能。需要魄力才能做到。
 2. 修改、调整和谈判得出一个现实的、可以达到的项目计划，这一步会要求各方都做出适当的让步才可能达到。在这一步中，适当的人员调整是必须的，必须根据情况把一些人员调整出项目。
 3. 重建信任：进入死亡滑梯项目的各方，包括客户，经理，项目组成员，项目经理之间的信任已遭到破坏，需要花较多力气重建信任。
 4. 调整加班策略。
 5. 一旦你发觉你的团队已经跳出死亡滑梯，作为项目经理，你需要更努力工作，避免团队再次进入死亡滑梯。
 

Tags - 惠普 , hp , 项目管理 , 项目经理生存之道 , 死亡滑梯 ]]> http://www.cooboy.com/read.php?261 大虫 <hujuan30@hotmail.com> Sun, 03 Jan 2010 04:13:06 +0000 http://www.cooboy.com/read.php?261 Protect yourself by wisdom, not paper.这句话是HP一位项目经理在一次经验分享时谈到的，可惜这是他离开HP前的经验分享。

之前项目经理的生存之道系列中谈到了，我们需要尽量记录下一些证据，这样可以在关键时候保护自己，这些包括了各种各样的文档：合同，SoW（工作说明书），电子邮件，会议记录，变更单等等。这些是有必要的，但是这些文档在关键时候是无法保护一个项目经理的。

为什么？如果客户存心找碴，也许从项目经理本身找不出毛病，但是你有一个项目团队啊，总是可以很容易找到弱点并相应攻击。即使找不到，也可以没有不讲道理啊，比如说“你们号称要提供高质量的交付物，为什么软件会出现这样的bug？质量太差了”，哪个软件没有bug啊，难道出现这样的bug就是质量差么？从项目经理的角度，客户是毫无道理的。但是从项目经理的老板角度来看，未必如此。这时候一堆文档能够派上什么用途呢？

文档的作用是保护团队，有了合适的文档，至少表明这个团队的工作是合格的，但是这些文档却无法说明项目经理没有错误，无法保护项目经理，这时候需要的就是智慧了。

到底是什么智慧呢，具体应该如何应对呢？那位做分享的HP项目经理并没有明白地说出来，说需要个人体会。其实，所谓智慧，就是项目经理的经验教训，应对各种复杂状况的具体做法。从我的个人角度，就是我的“项目经理生存之道”系列。

项目经理在有争议的状况下，处于非常不利的地位，如果文档不够保护自己，智慧也不够，那么项目经理何去何从呢？还有什么办法吗？

特别是客户比你更聪明，比你更有经验的时候，你就需要救命绝招了：正直和诚实。

所谓正直和诚实，就是表明你已经尽力了，你想帮忙客户，你问心无愧。到了这个地步，除非客户希望项目失败（小概率），否则他/她会意识到攻击你毫无意义。这样你有机会修复双方的关系，从而在后续的工作中处于更好的位置。


上述内容可不仅仅适用于项目管理领域噢。 ]]> http://www.cooboy.com/read.php?259 大虫 <hujuan30@hotmail.com> Mon, 13 Jul 2009 08:52:16 +0000 http://www.cooboy.com/read.php?259
我们继续来谈项目经理的生存之道，这次的主要是如何中途接手处于困境的项目。在HP，常常会用红项目（red project）来统称那些处于困境的项目。作为项目经理，把项目做红，即使结果不好也是自作自受，心安理得；但是作为项目经理去中途接手红项目，则是步步危机，稍不小心就会遭受失败的下场。

我很喜欢看商业真人秀《学徒/飞黄腾达 - The Apprentice》，一到七季有很多活生生的商业案例，每次都是分成2个队伍PK，其中很多季里面常常出现一个队连续输掉并淘汰很多人，这个时候Trump会从胜利队伍中选一位到失败队伍担任项目经理。
接下来我们看见什么？新的项目经理认为知道失败队伍失败的根本原因，而自己就是救世主，最后的结果是仍然输掉，这位项目经理进War-Room，最后被PK出局。
很有意思的是，好多季都出现这样的情况，难道接手一个失败的队伍或者失败的项目就是这样的困难么？有没有什么好的方案或者思路让项目经理们熬过这一关呢？

先来看看红项目的一些特点：
1. 项目对于business非常重要，各方面的关注度非常高
重要项目的成败对于企业的业务有着巨大的影响，举例来说一个企业的集成供应链管理系统，核心网上银行系统，制造执行系统，等等，一旦项目失败，这家企业的IT部门可能会很多年不能恢复元气，CIO位置可能不保，而开发实施这些重要项目的IT企业则会在行业中名声扫地，甚至退出部分市场。即使项目没有那么重要，失败至少会影响到几个经理的前途。
最终客户（甲方），客户IT部门（甲方），销售/业务部门（乙方），开发实施部门（乙方），这些部门的高级经理可能都会参与到红项目中来，所谓“高级经理”，自然意味着拥有更多的资源，更大的权力，对项目的影响力非同小可。

2. 现有的项目经理已完全失去信任
我们谈的是中途接手，自然原有的项目经理马上要下课了。
项目变红，现有的项目经理需要付全部责任，即使有很多的客观原因，但是一旦Sponsor认为目前的项目经理不能够带领队伍挽回局面，项目经理下课是必然。
当然不少情况是，项目经理看看实在没办法，自己先逃了，留下个烂摊子让别人来收拾吧。

3. 项目组承受来至各方的巨大压力，常常顾此失彼，恶性循环
红项目一般情况下最容易看到的问题是进度延迟，并且这个延迟已经非常明显的地步。
4. 项目组加班严重，人员变化多，工作效率低，士气低落

5. 项目组流程混乱，职责不清，没人敢承担责任，只求早日熬完

6. 项目看上去问题很多，每个相关人都能说上一通，并认为这是根本原因

[态度/姿态]
项目经理要接手一个红项目，首先需要在心理上摆对位置，有一个积极、正面的态度。

第一点，低调！
我个人认为《飞黄腾达》中到失败团队的项目经理就犯了这样一个根本的错误，即使我们过去很成功，但是仍然非常可能在这个红项目中失败，没有人是救世主。即使曾经成功挽救红项目，进入一个失败团队仍然需要低调。

注：这篇文章较难，未能一气呵成，有机会再重写。
]]> http://www.cooboy.com/read.php?245 大虫 <hujuan30@hotmail.com> Sun, 19 Apr 2009 03:48:55 +0000 http://www.cooboy.com/read.php?245
<解决方案>

1. 主动申请评审（review）
方法很简单，就是在上战场后，进行一段时间后，主动邀请方方面面对自己项目进行评审，比如计划评审，质量评审，流程评审，团队成员意见反馈等等，并根据评审结果进行后续的改进工作。

很多人不愿意使用这个方法，为什么？新人很多不熟悉，事情很多，压力特别大，这个时候还去找人来提意见，这不没事找事么？

是的，就是要没事找事，才能够更好的熬过这一关，原因如下：
       能够获取到积极的帮助。        
       能够快速建立必要人脉，这样关键的时候可以帮上大忙。有这样一个道理：如果有人帮助过你，那么你有更好的机会同他/她建立其良好的人脉关系。        
       可以发现在自己层面不能发现的潜在风险和问题，减少项目失败的因素。
       低调，低调。既然选择请人评审，那么就代表自己是很谦虚的，是很低调的。
       能够尽快获得团队的支持。

但是，也有坏处：
       你的弱点被展现出来
       由于做事方式不同，你可能会被质疑，可能会因此而很没有面子


所以，在开始阶段做这样的事情，一旦你确定你已经掌控全局，那么就不要再没事找事了。

回到案例中，如果项目经理A意识到这一点并主动申请评审，甚至在评审中说说自己的困惑，相信有经验的经理或者其他相关人会积极的帮他，或者采取其他的措施来把项目成功结束。
个人英雄在一定场合中是有用的，但是如果你是新人，还是尽量避免吧。

2. 寻找你的导师（mentor）
快速融入公司的一个好方法是找到一个你的导师，这里导师是指这样的人：你可以方便的向其了解企业的方方面面，比如流程、工具、一般的做事方法，如果更有针对性，你可能还可以问到相关的性格，经验教训，技术解决方案，等等。
但是找这样的一个人要小心点，因为企业里的关系复杂，要十分小心不要站错队。所以他可能给你的信息并不正确，可能他并不喜欢告诉你这些。不过务必得找到这样的人，最好的人选是其它部门的人员，因为没有利益冲突，所以问和答都会很放心。实在不行，你的经理可以是你最后的选择。

为什么经理是最后的选择？汇报经理没有时间，你作为一个新人也不应该直接把所有底牌都让经理知道。如果还要问为什么的话，汇报经理这个人是决定你的试用期业绩的，所以要敏感一点。汇报经理在过程中好的作用是可以帮你确认和澄清你困惑的信息。

好了，找到一个好的导师，特别注意了解企业的一些所谓潜规则，了解关键成员的喜好和脾气，然后有的放矢去管理，相信会更容易得多。

回到案例中的项目经理A，其实我可以帮他，我也有能力帮他，也表明了姿态，但是对方却没有啥回应。既然这样，我何必自找无趣呢？

  3.获得你的团队成员支持

    没人愿意失败，特别是你的团队成员不愿意自己的项目经理因为不熟悉状况而将辛苦成功白费。因此当你试图寻求团队成员

  4.争取时间

   方法很简单：明确地告诉你的经理，你需要熟悉和适应时间，需要有人跟你讲讲。如果可能，跟你经理一起制定一个计划。即使安排你上战场，你表达愿意的同时，要求有一段时间的过渡期，即你需要其它人也在支持。

   可惜的是很多人不敢说NO，你担心说不会影响老板对自己的看法，另外你也非常想在一开始就好好表现，做出一番事情来。    

一般来讲，类似的企业和类似的工作需要的适应时间较少，比如HP去IBM，就会很快；而国企到HP就会很痛苦。经理把你招入公司，诚然有项目的压力，但是如果你搞砸了，再换一个人会让经理更痛苦。所以你争取时间是十分合理的，也是应该的。按照我的经验，一般情况下，只要你开口，经理都会答应，1个月的时间是合理的。

争取到了时间，那么就要好好利用这些时间。一般的企业都会给你一堆的文档让你看，别傻乎乎地天天看文档打瞌睡。文档都是人写的，文档记录的是知识，所以要把知识跟人联系起来，尽量找到相关的活生生的人去取经。

最后，再总结一点：作为项目经理，经验可能是我们的最大财富，也可能是我们自己最大的敌人，在乎你如何应用。
Tags - 项目管理 , hp , 生存之道 ]]> http://www.cooboy.com/read.php?244 大虫 <hujuan30@hotmail.com> Fri, 20 Mar 2009 07:55:58 +0000 http://www.cooboy.com/read.php?244
诚然，做项目经理是一个非常好的工作，你的成功项目经验会为你的简历加分，同样你的失败经验也会为你增加不少的经验值，并且经验越丰富，你也就越值钱。换一个新单位是不是已经很容易的事情呢？未必，现在的企业都是不见兔子不撒鹰，有了具体项目才会来招项目经理，等你拿着“高薪”进公司时，项目已经等着你了，到项目里面屁股还没有坐热，已经有人在抱怨你不熟悉公司流程，项目管理混乱了，这时的你，该好好考虑考虑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冤枉吗？从他的角度看，当然冤枉，之前没有人“详细”地跟他讲过这些要求就被派到客户现场了，哪有时间和机会来折腾啊，在前方累死累活，后方不支持就算了，还被后方不断质疑。

还是承认现实吧，项目经理作为新人，就别奢望有多少的适应时间，想想怎么来应对吧。


Tags - 项目管理 , hp , 生存之道 , 项目经理 ]]> http://www.cooboy.com/read.php?243 大虫 <hujuan30@hotmail.com> Mon, 16 Mar 2009 09:07:45 +0000 http://www.cooboy.com/read.php?243
在上篇文章中谈到了问题升级机制相关的两个案例，下面我们来探讨一下解决方案。

<解决方案>
先谈一下预防机制，预防的方法就是建立有效的“问题升级机制”。

第一步，在项目启动阶段的项目启动会议上正式宣布项目的问题升级机制，即上文所述的逐级升级机制：
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（业务分析师）跟客户的项目经理在周会时就项目的业务问题发展了激烈争吵（在会议室里），对方的项目经理十分恼火，进行了言语上的人身攻击（骂人呗），会议不欢而散。
会后我们的业务分析师自然是十分不高兴的，个人跟客户的合作也变得不可能。但是针对客户的项目经理，我们认为骂人，不尊重人是不合适的，告知了对方的项目经理后，我、我的领导和销售找到了对方项目经理的主管，上报了这个事情。对方的项目经理虽然不是很爽，但是这的确是挑战了底线，作为项目经理就应该站出来维护团队的利益，当然后来再也没有发生类似不尊重我们项目组成员的情况。

（关于升级机制部分 - 完）
Tags - 项目管理 , 项目经理 , 生存之道 ]]> http://www.cooboy.com/read.php?242 大虫 <hujuan30@hotmail.com> Mon, 16 Mar 2009 05:43:35 +0000 http://www.cooboy.com/read.php?242 项目经理的生存之道（4）-问题升级机制

什么叫问题升级机制？英文叫做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的遭遇吗？

有人会讲，客户的项目经理太不给面子了，客户关系没有搞好。如果平时在一起多吃吃饭，喝喝酒，建立起个人感情，自然可以解决这个问题。诚然建立个人感情会起到很好的作用，但是毕竟代表着甲方和乙方，代表着不同的利益关系，常常有时候吃饭喝酒建立起的感情会特别脆弱，比如或者对方的项目经理有着很大的内部压力的时候，上面列了那么多的问题类型，难道对方找不出可以做文章的内容么？

换一个角度，如果不是对方的项目经理越级升级，而是对方的团队成员或者自己的团队成员呢？这类的状况也是不少，一旦控制不好状况，就会造成很难处理的困难局面。

到底是什么原因导致了这个案例的局面呢？我们应该如何预防这种状况？如果这个状况真的发生了，我们应该如何应对？不当的问题升级会危及到项目及项目经理的生存，我们必须思考解决方案。

具体解决方案的建议请等候下一章节。
Tags - 项目管理 , 生存之道系列 ]]> http://www.cooboy.com/read.php?241 大虫 <hujuan30@hotmail.com> Mon, 09 Mar 2009 11:31:01 +0000 http://www.cooboy.com/read.php?241 上一篇文章谈到下面这一类的重要项目关系人
权力->高
需要->高（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想用莫须有的借口让你成为某个事情的替罪羊，但是他/她得考虑重置成本（更换项目经理）啊，和谐至上嘛。如果你可有可无，哼哼，上班在混日子吧。

 说了那么多，有人问，遇上这么困苦的状况，我战略撤退，申请换个项目还不行嘛？不行的，被高层贴上了“无能”的标签就意味着你在这个组织短时间没啥好混的了。
 
 识别和管理关键项目干系人（完），请关注项目经理的生存之道的后续章节。
Tags - 项目管理 , 项目干系人管理 , 项目经理 , 生存之道 ]]> http://www.cooboy.com/read.php?238 大虫 <hujuan30@hotmail.com> Fri, 27 Feb 2009 23:24:19 +0000 http://www.cooboy.com/read.php?238
[主要症状]这类项目经理认为，只要能够带领兄弟们埋头苦干，届时这样按时完成项目，质量还可以，成本不超就是项目大大的成功了。

何为项目干系人（Project Stakeholder）是指积极参与项目的个人或者组织，并且会对项目的结果产生影响或者被项目的结果所影响；干系人可以是组织内、或者组织外的人。

项目干系人包括客户、监管机构、经理、分析师、开发者、测试者、文档编写人员、法律人员、销售、支持人员、制造人员等项目相关人员。

作为项目经理，如何整理和汇总项目干系人？
应当编写项目的通信录：姓名，角色，主要职责，联系信息等等
如何管理项目干系人的沟通？
通过项目沟通管理计划来做到，考虑When（什么时候）、What（什么信息）、Who（什么人）、How（通过什么方式发布或者获得信息）
上面的大家都会，干系人很多，找出关键项目干系人更重要。

怎么样识别出关键项目干系人？很多人相信自己的脑子，结果却是常常会忘掉或者漏掉一些，这里介绍一种结构化的方法：建立一个评分等级和加权，从权利、需要、兴趣、知识等方面对主要干系人分析和评分，得分据前列的为关键干系人。

权力：对项目的影响力
需要：项目满足个人和位置(position)的需要程度，体现为对项目的关注。
兴趣：对项目的参与度
知识：对项目涉及专业知识的了解度

接下来的步骤是列出这些关键干系人的期望，他们会直接告诉你明明白白吗？一般不会的。尽力分析出来，特别是哪些互相冲突或矛盾的期望。比如对于Time&Material的合同，客户期望能够成本尽量降低，而你的经理却希望钱收得越多越好。项目经理的重要职责就是平衡这些关键关系人的期望，并在整个项目过程中跟踪这些期望。注意：期望是会变化的！特别是组织内或组织外项目相关的人事或组织架构发生变化时，这时如果不及时调整，问题就大了！

除了管理干系人的期望外，还需要管理干系人，对于不同类型的关键干系人需要采取不同的策略。
第一类：
权力->高
兴趣/需要->高
知识->低

在你眼里，他/她可能是客户的项目经理或者领导，也可能是你的领导，他们具备影响项目的绝对权力，参与度很高，问题是他们对于项目涉及的专业知识掌握度很低。你觉得人家水平低，人家自我感觉非常良好。水平低就算了，还特喜欢发号施令，乱指挥，你说他不对他绝对跟你急。“叉腰肌”的谢亚龙不就是这么一位么？有这样的干系人，看看项目经理们（国足教练们）最后都干成咋样了？

<案例一>
对方是客户的领导（项目经理的领导），为了搞好关系，项目经理顺着这类干系人的思路进行项目，结果导致对方自我感觉膨胀，经常左右项目的走向和决策，项目经理的好意完全没有得到尊重，被斥为“专业知识不过关”，一气之下，顶了句嘴“啥都不懂吓指挥”，客户暴怒，连公司业务也受影响，项目经理也只好黯然离去。

<案例分析>
作为项目经理，控制自己的情绪很关键，生气的时候或者接近发飙的时候，先深吸一口气，给自己3秒钟时间问自己：我真的要这样做吗？

即使不进行反击，项目就能顺利进行了嘛？明显项目经理在处理这类干系人的策略不对。

<解决方案>
针对这类干系人，有以下的建议：
1. 树立真正的专家形象，选择和包装自己团队的专家，并且能够震住对方，最好有什么名号。让对方了解到成为专家的困难度，自然可能会考虑知难而退。
可行度：五星

2. 这类型的干系人更倾向于先进、最新技术、主流产品、国际标准等，在技术路线或者技术包装上需要考虑到这样的喜好倾向。场景：您的意见非常好，我们采用的是业界先进的方案，具备科学的设计和架构，...，我们可以考虑先用目前的方案，你的建议可以考虑在将来三期的时候规划。真的是“业界先进”吗？只要你能说服对方就行了。
可行度：四星


3. 在对方组织中寻找专家，并争取干系人可以授权给这位专家。通过这样的方式，其需要仍然很好，但是兴趣会大幅降低，从而大大减少对项目的干预度
可行度：五星，很多人从这方面想过，如果从一开始就考虑到这点，可操作性是很高的。

4. 既然对方对项目涉及的专业知识缺乏了解，那么不妨挖一个小坑，并且结果在控制范围内，然后让其掉下去，你再来完美得收尾，送对方一个人情。对付不见棺材不掉泪的主特适合，但是小心操作，不然搬起石头砸了自己的脚。
可行度：两星

5. 了解对方真正的需要是什么，尽力作为顾问的方式为其提供多种建设性方案来满足其需要，并用实际成果说服对方信任自己。如果国足有很好的成绩，谢亚龙还会那么瞎折腾么？
可行度：三星

说到底，我们希望最后达到的效果是：
权力->高 （高）
需要->高 （让对方意识并且相信减少参与，自己的个人和位置的需要也能得到满足）
兴趣->低 （降低其参与度）
知识->低 （让他/她意识到这个事实）

<后续思考>
其它类型的关键干系人如何合理呢？
第二类：
权力->高
需要->高（position的需要高）
兴趣->低
知识->高
这一类属于最容易忽略的关键干系人，也有实例证明一旦处理不当，后果是非常严重的。大家思考一下如何处理？

第三类关键干系人：
权力->低
需要/兴趣->高
知识->低

下一章我会继续探讨这个问题，重点会关注2个案例：
1. 第二类干系人管理
2. 项目过程中客户期望发生变化时却沿用老方法处理。
Tags - 项目管理 , 干系人管理 , 期望管理 , 生存之道 , 惠普 , 项目管理方法论 ]]>