其实我本来是想找PMP考友的，但是无人应征，又看到版主的号召，所以就贴个实践经验分享贴，也找点志同道合者交流交流实践经验吧。

我的msn ccjjgg79310@msn.com
Email ccjjgg79310@yahoo.com.cn

有兴趣交流的，加我吧

先说说自己的情况，制造型企业，集团公司，比较多的下属企业（几十个吧），总部IT部门，项目一般都是实施第三方软件，所以做项目不是内部的非软件项目（比如，制度建立之类）就是实施类项目。当中也会写到一些甲方的想法，有乙方同志看到的不要怒，就当了解了解甲方的思想吧。

我自己标准的职位叫做项目管理，所以部门内的别人的项目也要管，自己也要做项目。

写得会比较凌乱，想到啥写啥，如果写得多了再回头整理，看的同志不要郁闷。此外，我可能比较多的说到失败经验，因为我自己比较喜欢分享失败的经验，觉得成长比较快。

1.选择供应商。A项目，这个项目是个集团级 的项目，总裁啥的都非常重视。分为阶段一和阶段二，但是是一个合同里的。是IT和部门C合作的。选择供应商的过程极为漫长而曲折，从3月份开始到10月份才选定。我们选供应商不是公开招投标的，虽然招标，但实际上最后是根据IT和业务部门的人一起讨论得出来的，不是那种正规做法的当场打分，然后公布结果的。当初来过交流的供应商有 a b c d f 四家，a 成名已久，大家都知道，但是在我们项目方面看起来经验最少；b 是风险投资的企业，发展很快，1年就从400人到了1500人，行业客户数量居第二，但是都是大型客户；c 是小公司；d 是小公司，但从市场占有率看来却是最高；f 是大公司，经验也还可以。

第一轮看下来，f 虽然大，但是从朋友那里打听到，他在某公司做的项目内部宣布失败，大家肯定不敢要。c 公司小，而且经验一般，加上过来演示的人实在不怎么样，说话带着浓重的口音，我们实在听不懂，加上技术构架不怎么样，里面还有非常陈旧的技术，所以第一轮基本就淘汰了 f 和c。乙方的同志，知道一个好的售前，除了业务能力还需要什么么，极好的沟通能力，形象好（这不一定是美貌，而是感觉很professional，很白骨精的样子，就是有气势了）。

当初在前期交流的时候，我的领导W就看上了d公司的售前R，要求我们的项目由R当项目经理，当初d 公司的销售总监也是答应了。所以第二轮的时候W就向部门C的领导J推荐了d 公司，和d 公司也谈妥了，d 拿到中标通知书之后，就开始干活。看起来一切顺利，我们把 J 领导签字的中标通知书给了 d 公司， d 公司也马上派了 项目经理过来做需求调研。但是问题马上出来了（1） d 公司派出来的项目经理不是当初承诺的 R ，而是另外一个沟通能力不太好的人，和客户交流了半天好像也说得不甚明白，反应比较慢 （2）d 公司在投标文件里面写到，有Oracle 的产品，但是实际交流中发现，Oracle的产品只是在开发，至少等3个月才能出来。（3）这是最重要的一点，我们希望供应商直接进场开始干活了，做完需求做实施，合同要等到详细需求调研完了确定完项目准确的难度、范围之后再签合同，时间上也会拖上1个多月，在合同没有签订的时候供应商也要干活；但是供应商觉得只能做一个简单的需求调研，只是作为合同附件用的，必须要等合同签订了才能进场。

我的领导W其实是非常讲究供应商选择和管理的，其实后来我才明白，一开始他就压供应商c 要求不签合同就拿了中标通知书开始干活，实际上也不是蛮横不讲道理，他有他的理由。

我在第一次需求调研也是第一次见d 公司的项目经理后把发现的3个问题马上报告了W，他立刻意识到问题的严重性。（1）d 公司 没有派出当初承诺的 R，来的一个人是这个公司的八大元老，沟通能力一般，说明d公司很可能是没人了。前面说过了，d 是个小公司，所以得力的人力资源一定是个问题。 （2）d 公司有欺骗行为 ，这样W想起之前有两次， d 公司承诺什么时间给出的文档都拖了时间，W是个很严谨的人，所以开始怀疑d 公司的诚信度。同时我们打电话问d公司怎么回事的时候，他们一开始的态度是抵赖。（3）其实这才是最重要的一点，同志们，相信吧，所有老板不是希望一件事做得漂亮，而是希望一件事可控，可控的失败比不可控的胜利更被他们需要。W 会要求供应商不签合同就进场的方式，是打消供应商的气焰，让他们被自己控制。但是不要误会，不会是欺压，只是可控，W其实也讲究和供应商的良好和长期合作，一开始的压是为了掌握主动权，之后其实他对供应商还是很好的，并且他承诺的东西（比如合同）是绝对说话算数的。W教育我，要供应商可控，一开始要大力打压，让他们听话，但是承诺的东西一定要做到，同时在项目过程中，要友好合作，不要欺压供应商，要以理服人，友好协商。控制供应商是为了在关键点上不要走偏了。这个问题上W没有压住供应商 d 。

于是问题（2）就成了问题（3）的一个藉口，白纸黑字的d 也跑不掉，我们召回了中标通知书。这个时候 d 公司跑来又是道歉，又是承诺可以先进场再签合同，还说项目还在接着做。整整4天，我们没有任何回应。

其实这4天当中，W还在观察d 公司，但是 d 公司的人不知道，只是Sales天天打电话，喊口号说我们还在接着做你们的项目，我们还是很有诚意的。 这4天当中，做项目的人一个也没看见，文档一篇也没有，邮件一封都没有。W 终于死心了，觉得 d 公司没有诚意。于是 d 被彻底的干掉了。

由此说明，乙方的同志们，其实很多时候，事情并没有看上去那么绝望，如果想挽回什么就真正的表达诚意，如果4天当中，d 公司的技术人员等等真的和我们在联系、在认真工作，我相信 d 公司还是有机会的。只是d 公司自己放弃了，所谓自助者天助，d 放弃了，我们更没有理由坚持。

今天晚了，明天再接着说，还剩 a 和 b 呢。就两家了还是不消停啊

看样子说得太详细了，决定说简单点。喜欢知道细节的，想知道为什么当时会那样决定的可以再详细讨论。

直接说结果吧，当初因为 C 部门的人和我都喜欢 供应商b，所以 W 顺从了我们的意愿。选了b，但是不幸，在 是否提前进场这个问题上，W 又和 b 干上了（其实甲方和乙方的利益点是不同的，在这种问题上几乎是一定会出问题）。之后W和b 公司的高层吵了一架，大家彻底崩了。我们再度建议改为供应商 a ，但是因为许多的原因， C 部门的人选择了 供应商 b。
之后项目出了很多问题，从源头上讲，选择错了供应商是最根本的原因。我把W选择供应商的几条标准和原因告诉大家，给甲方和乙方的人一点参考。

1、高层关系良好。这是为了实现W的第一目标，供应商可控。不要觉得奇怪，我的几个老板都是这条原则优先的。W常用的几个方法，比如，供应商实施顾问在我们一开始这里不听话的时候，他会当着实施顾问的面打电话给 供应商的高层，把实施顾问臭骂一顿，声色俱厉，如果这个时候供应商的高层马上道歉，并且接着声色俱厉的把手下骂一顿，那么这个供应商基本还是可控的；反之，这个供应商非常危险。当然还会有要求提前进场一类的事情发生，W 就是要突破供应商的底线，但是前面说了，W绝对遵守承诺。

2、项目资源明确并优良。因为供应商不管多大，里面的人一定是良莠不齐的，再好的公司也有不好的实施顾问，但是公司的管理不一定跟得上，常常是项目delay了，客户忍无可忍了才被发现。业界超牛的公司做砸项目的比比皆是，而成败，常常是系于做项目的这几个人身上的，其中最重要的当然是项目经理。

3、重视案例。方法论每个公司都有，见多了绝对没啥新鲜的，方法论是必须落地的，所以案例就是方法论啊、公司的资历啊一大堆的落地表现，所以我们常常花更多的时间去了解供应商的案例情况。

4、公司成长性和稳定性。这是两个有点矛盾的要素，成长性当然是为了能跟上我们公司的发展，但是又要稳定的成长。风险投资的企业常常的问题就是发展神速，管理跟不上，我们的项目就是吃了这个亏，没人管了。所以一年规模就翻个翻的企业，其实值得甲方好好考虑。当然如果甲方足够的大，大到什么公司都不敢轻视你也不会有这个问题，但常常就是甲方只是一般的大而已，己方在发展过程中，对新员工的培训等等根本不足，大项目多，人手不足，于是一个新手就成了你的项目经理，后患无穷。

接着说，项目计划。

因为每个项目都有在需求确定情况下，都会有一个大致合理的工期，因为进度与成本的关系并非单调变化，一般呈U形，所以这个合理的工期（成本最低、效益最大）的工期是存在的，只是甲方多半是不知道的。

对甲方来说，要知道非常简单，要求供应商提供解决方案的时候就提交计划，通常说来，差别不会不靠谱（万一真的不靠谱，就在讲标的时候问，看看他们能说出什么道理来），所以取个居中的时间差不多就是这个最合理的工期。一般没事的时候，最好不要强压供应商说一定要什么什么时间完成，强压会导致供应商加人，事实上不是人加一倍，进度就快一倍，常常是人加一倍，进度只能少1/4，沟通成本、整合成本其实是在成倍增加的，所以甲方的同志，要相信乙方对时间的估算。

其实项目前期的需求分析，就是招标之前写初步需求也是一个非常重要的环节，只是这个项目失败是因为供应商选择的问题，所以先写那个了，这里补上 需求调研 环节。

做项目的需求分析，就叫RFP吧，免得和后面的供应商的需求搞混了，在企业做项目，一定要知道自己的Stake Holder（利益干系人）是谁，尤其是部门长级别的Stake Holder，一方面要知道他对这个项目的定位，也就是范围、深度，另一方面要知道他们的兴趣点是什么。现在没人会指着你做个系统就所有事情OK了，只要你解决了他头疼的2-3个问题，他就会开心了，IT部门的绩效就出现了。

不是说不关心下面人想什么，而是说要优先关心那2成的东西。事实上我的感觉是比如做10个模块，就2个是部门长感兴趣的，也是让他决定要不要说你项目有用、做得好的2个决定性的模块，或者2成的功能是他感兴趣的，项目实施过程中客户提出来的问题8成都是些不好用之类的小问题，真的有问题的就2成，看起来2/8原则基本上是处处成立的。

如果大老板们和下面的人提出的东西彼此之间可以有一定的独立性的话，建议把项目分成几个阶段（RFP里面就要告诉供应商要分阶段），不是传统说法上那种，需求-实施-测试……这种阶段，也不是一期二期那种，就是一个合同之内，一个项目之内的事情分成几个阶段。比如，打算做8个模块，就先做大老板关心的1-2个模块+报表模块，其他的再慢慢做。建议周期在3个月以上的项目都可以考虑一下分阶段。这个当然不是每个项目都成立的，有的时候很不幸几个模块彼此关联性非常大，必须一起做，这就没辙了。

分阶段实施的时候，可以第一阶段需求完成了，供应商开发的时候，就开始做第二阶段的需求，一来时间可以向前挪动一些，二来，用户和咨询顾问不会出现在开发阶段无所事事的空当期，三来，用户使用模块的周期比较长，有更多的机会在前期就暴露出开发中的问题。

下面是以前写的分阶段和不分阶段的比较（当初还写了个文档，哈哈，现在就把比较这段摘出来了，想问更多的再联系），不一定有道理，大家随意反驳
一、分阶段实施
1、项目时间：在供应商人力资源的充足的情况下，可以缩短项目周期
2、客户buy-in：因在短周期内可以出现可使用的成果，客户保持对项目的持续关注和忠诚
3、供应商的buy-in ：因在短周期内可以出现可使用的成果，供应商获得价值被认可的成就感，能保持对项目的忠诚度
4、项目新增需求：在分阶段的过程中，用户通过持续对产品的使用，存在提出更多需求的风险；但同时，这仅是把新增需求的风险放在了项目前面一些的阶段暴露
5、项目质量：因客户可以迭代使用软件产品，软件的二次开发也存在一个迭代的循环，所以这样开发出的产品更符合客户的需求；运行上经过了更长的时间，也更加稳定可靠
6、适用情况 ：实施周期长于一个月，需求不够清晰
二、不分阶段实施
1、项目时间：存在因客户长期处于松弛期，失去对需求的认可，提出“这不是我想要的东西”而导致需求一再变动、项目周期变长的风险
2、客户buy-in：因中间松弛期过长，客户对项目的关注度和忠诚度都较低，极端时，可能会出现“这是信息部的项目，不是我的项目”的想法
3、供应商的buy-in ：因中间松弛期过程，客户与供应商的交流不够充分，供应商逐步遗忘最初调研的需求，做出来的产品存在不够符合客户需求的风险；同时，因为过长的没有出成果的工作期，存在士气低下的风险
4、项目新增需求：因在实施的后期才进行客户测试，客户需求变动的风险较大，这会导致整个项目周期变长
5、项目质量：在实施阶段的剩下1/3部分开始的用户测试导致缺乏一个迭代的过程，软件质量验证、客户需求稳定的周期都不够长，存在较大的质量隐患。
6、适用情况 ：实施周期短，需求清晰

当初还做了个示意图，可惜不知道怎么贴图，就给个文字描述算了。

项目计划制定之初，最应该关心的资源，然后才是时间。

因为项目周期到底多少，前面说过，在招标过程中，基本上都可以圈定一个比较合理的周期。但是资源却是直接影响项目质量的人。
怎么选人，常用做法就多了，看简历，电话面试。如此种种，一定要按照自己的要求选定自己心目中的人选，然后就是确定资源到位的时间。

最近和一个乙方的朋友沟通，他提到说很多时候项目经理派下来的计划根本就是不可能完成的，（通常情况下，不可能完成主要还是资源不足），所以基本上项目还没开始就知道肯定要Delay，只是很多时候项目经理会死抗。拖到了时间才知道。而且我的感觉是，一般供应商资源不足是后台的人手，就是远程开发人员、测试人员，前台的人员因为一般还是onsite的服务，很难偷工减料，但是后台的就很容易了。

项目过程控制

计划做好了，就是启动、开工，说几个项目过程要注意的吧

1、项目一旦开始，就是例外管理和过程控制，说到底目的都一样，就是避免出现更大的篓子，在一开始就把问题扼杀在摇篮里面。所以，越是乙方项目经理说，一切OK，资源到位，进度一天不差，而你却没费什么精力的时候，就是越危险的时候。风险不是暴露在桌面上的东西，因为一旦暴露了，就是可控的，就总有办法解决它，在底下潜伏着的，不知道到底有多大多严重，这才是最危险的。所以甲方的项目经理一定要时刻悬着一颗心。做过项目的人都知道，通常前面看起来越顺利，后面问题越大，所以危机意识是要时时刻刻都有的。
甲方的项目经理在感觉到一切太顺利的时候，就要出手了，常用的办法无非是乙方的人给周报，强势一点的做法是给乙方后台的人打电话，问问进度，增加检查点，没事就给个交付物，大大小小的东西都必须有交付物，不仅有，而且要正式，不是随便谢谢忽悠一下就行。你就随时掌握了进度，可以随时找到偏离。

2、无论对待乙方还是说你的客户，根据每个人的习惯养成自己的提醒点。就是说比如 1月5日交东西，你1月3日就开始提醒他，否则你1月5日再问，他拖一下，至少3天过去了，所以一定要提前提醒才能保证进度。

3、过程中肯定是有很多事情要做，而且不是计划里面的，是为了达成目标衍生出来的很多事情。所以分配事件的时候，还是两点，谁/什么时间完成。这类事情跟踪进度的时候，绝对不能满足说“正在做”，回答就是“做到哪里了？还剩什么？有什么问题？”

4、阶段性评审很重要。我们往往做阶段性评审是为了展示成果，但是项目管理理论中说阶段性评审还是为了获得进行下一阶段的通行卡。我们往往强调前者，忽略后者，反省起来还是应该以暴露问题为主，并且设好质量关卡。实际项目中，很多时候为了赶进度，就留下长串的buglist，供应商信誓旦旦的说什么时候怎么解决，然后直奔下一阶段去了，但是因为后面的工作量也非常饱满，前面的buglist无法解决彻底，一拖再拖，最后跟滚雪球似的，上线前，雪崩了。所以说，还不如，每个阶段就是必须达到什么样的质量标准后再放行，宁愿集中几天解决这个阶段的问题，也不要说总是用承诺来换取下一阶段的冒进。当然我说的不是一个问题都没有，这就不可能，但是buglist上面，不要有重量级的问题留着。

关于烂项目

这几天和一个朋友聊天，我们都经历过烂项目，所以就一起总结了一下烂项目的特点。这个很多都是他总结的，不敢略人之美。

1、烂项目多半都resource分配混乱。——防治策略就是你让乙方项目经理给你一个resource分配表，然后时常跟踪一下，如果当中的人，比如开发人员之类，知道自己在开发什么，下一阶段要做什么，时间点在哪，就是好的。反之，如果这些人觉得一会做这个，一会做这个，项目一会忙得要死，一会闲得要死，不知道下面要做什么，那这个项目多半迟早出问题。

2、烂项目多半都沟通不明，如果所有人都在抱怨不清楚的时候，这个项目差不多玩完了。需求人员说不知道项目范围在哪里，开发人员说需求不清楚（那他如果开发就是想当然的东西，拿到手一看绝对不是客户要的东西），客户说不知道进度在哪里，问题在哪里，项目迟早玩完。所以每个人知道自己要做什么，该怎么做，就激发了他们的内在动力，要不就成了各自为政的瞎忙乎，最后凑一起看，什么都不是。

3、客户不知道阶段目标和验收标准。这是那个朋友提出来的。是非常非常之正确的。客户一旦不知道阶段达成标准，就会过程中需求变来变去，阶段验收的时候这个也要做，那个不行也不给过，搞得来80%的时间都去搞一点点小问题了。
项目经理有很大的作用就是引导客户想明白每个阶段的验收标准。通常客户都是一句话，能用，好用，客户的描述是感性的语言，但是项目经理就有必要将它量化、明确化。以前看丰田案例，日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是
（1） 身份地位与尊容的形象
（2）高品质
（3）转售的价值
（4）性能（例如，操控、乘坐、马力）
（5）安全性
最后他根据客户这些感性的词语，翻译出了凌志的目标
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）
（4）空气动力……
（5）汽车重量……
PM同样要承担翻译者的角色，引导客户明确阶段验收标准，什么功能必须能用，系统速度多少，什么样的功能可以放一放，标准明确，并且所有人都知道，项目是很好做的。问题往往就是最终目标不明，每个环节的人都不知道轻重缓急，沟通又没有传达到位，大家各自为政了，一到环节交接的时候就完了。

4、烂项目常常在1-2个月的时候忽然大大的延期一把，并且原因不是非常成立。然后这个项目就会在后面几个月时间里一再延迟，而且每一次延迟的时间都更长，如果第一次是半个月，第二次就成了1个月，第三次就成了3个月……。所以一旦某个项目延期了第一次，感觉上比较突然，而且原因似乎都是可以协调的原因（比如，他说有个技术难题，你可要问清楚了，什么技术难题，一定要找这方面的专家问清楚了，这样的问题通常会不会花那么多时间；人力资源不足等等。很多时候，这些原因会看上去表面合理，但是一旦你深究了，就会发现不对劲，所以带着危机意识去问为什么为什么为什么是必须的），那么你要警惕了，这个项目极有可能会成为一个烂项目。

再把以前写的一点DD贴出来

利用人性的特点赢取成功

企业的项目通常都会遇到一个项目中，所有项目成员都是兼职的情况，因为项目成员的时间、精力不能保证，导致项目时间延迟。
这种情况在某企业有一个成功案例。该企业属于“领导为主”型企业，风格比较类似国企。该企业通常的项目都会因为涉及面广，项目组成员都有许多本职工作要做，而没有足够的时间按进度完成项目，大部分项目的延迟都高达80%以上，多者达到150％。但这种通常情况在该企业的一个人力资源项目（主要内容为各部门的所有人员的职务分析）上得到了转变。该人力资源项目要求的时间极为紧迫，即便是项目成员全部全职的情况下都要有50％的时间加班才有可能完成，而该项目所有成员推掉了日常工作，将其的重要性排在第一位，加班加点的按时完成了。
在研究了项目资料后，发现，该项目的做法可整理如下：
（1） 会议无论大小均发送相关项目组成员，并抄送他们的领导；会议完成后必有会议纪要，或交代事宜，或做项目例会，纪要必定抄送各大小领导；如果有项目组成员不参加会议，要求向部门长请假。
（2） 项目当中，每周召开一次项目例会，内容大抵都是谁完成了什么，没完成什么；每次项目例会必有文字记录，当中均记录如哪个部门提前完成了什么，哪个部门还有什么没有完成，各部门做得好的有表扬，做得不好的没有批评
这种做法在标准的项目管理中似乎并不新鲜，但却收到了极为良好的效果，原因何在？
该企业属于国企风格，各成员都极为重视个人在领导心目中的形象，大小会议动辄抄送领导，暗合这部分人的心理：每做一件小事都被领导看见；如果请假，却需要有十分充足的理由向部门长说明，没有万分需要的理由，也不会请假。同时每次会议必有会议纪要，抄送各大小领导，则无论事情大小均会被项目组成员、各领导以为是重要的事件，虽然各领导未必会看，但项目组成员的意识中被烙下了“重要项目”的印象，同时也有工作成果被重视的感觉，所以所有成员都不得不重视起来，项目管理者获得了他们的buy-in。
项目例会的定时定点召开在数周之后已经形成习惯，每当这个时候项目成员从本部门消失，部门人员都会自然而然知道他们是参加人力资源项目了。这在无形中形成了一种群体效应，所有的人都在谈论这个项目，询问进度。于是在外部氛围上，项目组成员再一次感受到了压力和自我价值体现感觉。
每次会议中，各部门都汇报本部门的进度，如果某个部门的进度大大落后于大家，则很容易感觉上“没有面子”，在之后发送的项目例会报告中，各部门完成了什么、没完成什么、哪个部门的谁收到了表扬都有详细阐述，这在各部门人心中形成了一个隐形的看板“kanban”。看板最初来自于精益制造理论，是个日语名词，表示一种挂在或贴在盛装在制品的容器上或一批零件上的标签或卡片，或流水线上各种颜色的小球或信号灯、电视图象等。看板是揭示牌，可以作为交流厂内生产管理信息的手段。但在这里，是一种比较看板。上面并未批评哪个部门，但之间的比较却一目了然，这种方法利用了人的好胜与自尊心作为引导他们前进的“胡萝卜”与促使他们前进的“大棒”，效果非常卓越。如果有部门长偶尔看上一眼，表扬一下或者问问“怎么别的部门都完成了，我们还没有呢？”，实际效果将更加明显。当然这个个案仅就国企而言，但中国人的心理都具有类似性，可以进一步探讨。
人天生就有爱慕虚荣（面子）、贪好功绩、喜欢成就的特点，在这里只能说是特点，因为人性的特点并没有善与恶的区别，只有一个程度的区别，而善于利用人性的特点在项目没有奖金、特殊荣誉（胡萝卜）以及批评、工资克扣（大棒）的时候显得尤为重要。利用人性来进行项目管理的方法在许多地方都有微妙的用处，需要项目管理者对于人性有深刻的理解。

说说合同吧

项目管理里面合同有很多种类别，但是大家肯定都想把风险转嫁到另外一方头上，所以选择合同类型要谨慎，对自己有利，同时也要保持激励机制

1、Fixed-Price（FB）固定价格。这种合同中国人最喜欢用，因为感觉价格OK了，己方的风险就固定了。而且因为工作量评估就是IT行业评估成本的主要办法，但是工作量评估实在是不够准，尤其是一些风险看不清的项目，实际能有评估的两倍的都有。但是，我个人觉得，因为中国的很多项目都是谁做谁评估，所以大家都有习惯朝多了评估，这种方式未见是最合适的。但是如果风险非常大，或者就是不知道风险在哪里，到底多大的项目，甲方的建议用这种方式，可以转嫁风险，同时要获得乙方高层的承诺，保证即便工作量大量超出也不加钱，这样的风险的确转嫁了不少。

2、框架协议+time Material。说白了就是做多少，算多少。这种比较适合供应商在现场办公的，先有个框架协议，表示甲方和乙方的合作方式，一天多少钱等等，供应商来一天就签一个time sheet，然后最后算总账。外国的公司最喜欢这种方式。在风险比较明确的时候，而且确保供应商人品的情况下（不是诋毁供应商，但是为了避免有人磨洋工），也就是一些大公司的感觉比较Professional的那种实施顾问，而且管理比较严格一点的公司，可以采用。这样的公司比较保险，一方面可以和乙方的管理经理沟通，这样的项目大概要多少时间，他们有信誉保证，也不会冤甲方的，另外大公司项目都做不完，它都犯不着和你耗时间。为什么风险比较明确的时候用这种好一点呢，因为大公司都会有比较严格一点的人力成本核算方式，超过成本是比较严重一点的，如果采用FB的话，他们就会严格按照官方的流程来估计，比如测试三轮、啥啥N轮，这样按照官方的手册做才能保证不超支（或者说超支了才有官方的手册做借口），实际上可能风险比较明确，两轮测试就够了，但是因为一般甲方是保证效果的，如果第二轮测试就没问题了，多半也不会非做第三轮不可，从成本上说，甲方就损失了一些钱，还不如time sheet，大公司的实施人员还是有良好的职业素养的，所以这样大家都好。

3、项目管理里面的合同还有其他的我都没有用过，但是真的很鼓励大家用用，因为合同是真的有激励作用的。抄下来给大家。
a) Cost-Plus-Fixed Fee(CPFF，成本报销加固定费用)/Cost-Plus-Percentage-Fee(CPPF，成本报销加百分比费用)
用于无法确定准确价格的情况
成本变化但费用不变
卖方风险低
会没有成本控制的动机。

b)Guranteed Maximum-Shared Saving(GMSS) 确保最大限度的节省
卖方付固定价格，按实际造价报销至顶限价格
在确保线下节省部分双方共享
卖方负责超过顶限的部分
谈判合同中最好的一种形式。
这种方式看上去我觉得是风险不固定时候甲方和乙方比较共赢的方式，但是好像合同类的难度在于合同模板，没有找到一个法律上比较严密的模板。

c)Fixed-Price-Incentive-Fee(FPIP)固定价格加鼓励费用
为卖方提供固定价格加奖励费用
鼓励卖方降低成本
双方共享结余，共担风险
这种觉得长期研发的项目可以用

d)Cost-Plus-Incentive-Fee(CPIF)成本报销加鼓励
报销允许量的成本加上预先规定的奖励优越表现的奖金
如果实际成本低于目标成本，买方和卖方按规定的方法分享节省的部分
这种也觉得长期研发的项目可以用

甲方与乙方的关系

项目没有开始的时候，甲方好比挑老婆，那可要睁大眼睛看，乙方的长处、缺点、特点都要摸得一清二楚。之后就是平衡，在众多老婆中间挑一个。
合同签了，乙方都是甲方的老婆了，没有原则性错误的时候，甲方最好和乙方是一家人，大家是利益共同体。

甲方要不厌其烦的告诉乙方：项目有什么问题，你告诉我，不能协调的资源我们出面，有问题我们共同承担。乙方的人常常对自己内部不能协调的资源难以启口，好比没法说自己娘家人的不是，所以有的时候乙方会掖着藏着，或者自己拼命协调，等上面说No的时候项目又拖了不少时间了。所以甲方友好的态度很重要。

甲方还要不厌其烦的告诉乙方：我没办法帮你加钱，但是可以帮你省钱。就是说合同没法改，但是可以尽快完成项目，减少彼此的时间+人力资源费用。

虽然甲方这么想，但未必乙方这么想。所以，甲方一定还要设定自己的底线。比如，项目经理一定要符合几大要求（有责任心、沟通能力强……），某个时间一定要完成什么里程碑，诸如此类，甲方的友好是要有条件的。但是一定要态度够温和，而立场够坚定。

双方都记得万万不好撕破脸。一旦撕破脸，很多时候大家都绕着走，慢慢的就会形成沟通障碍。而且越是高层越会发现障碍不可逾越，也许这就是人性的弱点，高位的人是容不得某些事情的。

一句话，有合作，有斗争。

不能控制的供应商的后果

我是东一个主题，西一个主题的胡写，想起什么说什么，主题之间未必有太大关系了。大家也就胡乱看吧。

最早之前说过的，因为F部门坚持选了一个我的老大W不能控制的供应商，后果在验收的时候就会出来。F部门希望我们可以为他们开发报表，所以我们要求供应商提供数据字典和数据流向说明，主外键关系。供应商是死活不给。然后出现供应商总是说：
1.当初我们约定初验的时候没有说那些东西，所以我们只是在说初验。
2.你们最后的一批需求我们也是说在终验前做完，但是你们初验都没做，我们就是在做最后的开发，没到终验，也就没有成果。

说白了就是供应商和我们掐上了，他们不给我们最最后的一批需求，我们不给他们初验。他们会一天打2、3个电话到F部门坚持选他们的人那里去，于是，终于连最后一个支持者都倒戈了……

可怜的F部门的原支持者，完全没有和供应商阶级斗争的经验，难过无比。

这个惨痛的项目告诉我们什么呢

1）通常来说，如果选供应商的意见不一致，可以上报，由更高级的人仲裁，如果是势均力敌的两方谁也没有依附谁的那种，就可能出现其中一方把很多责任推到选供应商的那方头上，而且承担责任多的这方又没有 PM以及和供应商斗争的经验的话，基本一开始就注定了结果是失败的。

2）高层关系重要呀重要，甲方PM和乙方PM一定会因为很多原因大打出手，还不是靠彼此高层协调。高层不合，他们就是神仙打架，我们凡人遭殃；高层琴瑟和谐，我们就是小孩子拌嘴，风轻云淡就过去了。

3）早期的高层PK就是占领心里制高点，赢了就插上自己的旗帜，万一输了，尤其是甲方输了，最好赶紧撤退，换个阵地，不要硬抗呀。

因为甲方乙方的PM都知道事情搞不定就上报，到时候就是高层PK。所以早期甲方和乙方斗争的时候就决定了胜利方掌握主动权，失败方产生心理阴影，大家都是人啊，没啥不同，想想自己就知道高层也多少都会这样的。
a) 甲方早期斗争获胜。甲方老大兴高采烈的控制住了乙方老大，如果甲方PM搞不定了，老大也会出面轻松搞定，毕竟乙方老大心理上已经输了一筹，有了心理阴影就容易听话得多。
b) 甲方早期斗争失败。甲方老大就会绕着走，不和乙方的老大接触，你们F部门当初谁选的，谁负责。老大们都是顶顶爱惜面子的，一旦失败，就不会说我脱了面子求你。事情就没法解决了，要么就是拖着，要么就是甲方的人吃了亏。


4）没有项目管理经验的职能部门，不要和IT部门硬争。善良的职能部门，长期对内工作着，不知道外面有多么险恶的供应商，不是人人都想和你搞好关系长期合作的，而且有的时候是供应商最早是想长期合作的，但是过程不尽人意，他们也知道只怕第一单就是最后一单了，所以也不怕惹急你了，收回钱才是上上策。当初惹火了自己的IT部门，焦头烂额的时候，就没有人帮忙了。
甲方的人内部团队多重要呀，咱们一定要注重内部的和谐啊，这样才是相互扶持的团队嘛。

说说人力资源的考核

最近做一个部门的考核制度，和人力资源的聊了聊，觉得很多DD也可以用到PM上来。

首先确立考核的目标，我们的考核目标是
1.压力与责任的传递
2.实现目标，执行计划
3.体现合作与分工

所以建立了考核的几个原则
1.分层执行（部门长考评组，组长考评组员），部门长平衡。
分层执行让中间层有了资源和权利，于是中间层可以实现自我管理，压力和责任又可以从中间层传递到底层。

2.关注目标与里程碑，体现整体价值。
考核是一种导向，考得越细，导向性就越强，因此考，就要考得粗。所以项目考核就考核里程碑和目标，所有的细节、activity都是为了实现目标衍生出来的。因此，关注目标、强调目标。
过程采取一种同志式、老师式的关心，帮助member解决问题，关注有什么做不到的、有什么难题，帮助他们解决，和他们站在同一战线上。不要用考核这种居高临下或者叫做立场不同者的态度来看待。赢取member的buy-in。

3.上级对下级垂直考评，体现团队合作；季度经验交流，实现共同进步。
360度的考评非常不利于团队合作，所以都是上级对下级的垂直交流，加上前面的分级管理，矛盾都是内部解决，对外就是一个团队。
季度进行一次经验共享、教训交流，大家都说自己做得好的和不好的，但一定不要对此考评，否则就会引导大家把不好的地方全部隐藏起来。鼓励交流和共同进步。


这个让我联想到PM在人力资源上可以做的一些事情
1）对项目member实行目标管理。一方面要放权，另一方面过程的监控改为过程关心，改变自己的立场，不是考核或者监督，而是帮助他们发现问题。这就是人力资源中说的激发他们的“自我管理”，这个时候他们感受到被重视，不仅会管理好自己，还会反过来帮助PM发现PM的不足。

2）过程中团队气氛的建立很重要，一种真正的交流、共享气氛是非常重要的，PM要学会做 team building，建立一种团队气氛。学会当领导。

3）如果一个团队比较庞大的时候，比如，有技术经理之类的角色的时候，分层管理是很重要的，PM要忍住掌握权利的感觉，学习“无为而治”，把权利分割和下放。如果真的要体现自己的权利，可以采用掌握资源的方式，让他们做什么资源的审批都从自己手上过，就掌握住了关键环节，千万不要用不停的换人或者安插人的方式来打击员工的积极性。

4）和大家一起分享，总结，引导别人的思考的同时也启发自己的思考。
听说微软的考核，分成4个等级，业绩好、说得明白的是A，业绩不好、说得明白的是B，业绩好、说不明白的是C，业绩不好也说不明白的是D。有意思的是B和C的划分，据说微软认为说得明白就是这个人能知道问题在哪里就有很大的改进空间，于是可以得B，而说不明白的这个，可能就是蒙的，也可能是外界环境好，总之似乎他没法复制自己的成功，于是就是个C。
不时的交流就是启发自己和别人的思考，知道为什么，这样成功才是可控和可以复制的，否则就是一次性的行为了。

说到底，激发员工的“自我管理”，他们爱上了自己的工作也就爱上你了，你既获得了团队的buy-in，还能游刃有余呢。

项目经理最应该具备的能力是什么？

居然开头的空格没用，看上去就不够清楚了，sigh

这个话题好像有点大了，我的理解也不过是新手冰山一角的总结，非常欢迎大家共同讨论。如果我们想成为优秀的PM，我想第一步应该是知道需要学习什么吧。

首先明确一下，PM不包括做系统的、coding、数据库、网络等等的，如果你做这些，只是说明你身兼数职了，这里说的就是PM本身的能力。

1、沟通能力。好像所有的人都会赞同沟通能力最重要，可是什么是沟通能力的内涵呢？我觉得是：清楚的表达、传递，并引导人们的表现朝你的期望发展。怎么才能沟通好呢？可以简单的分为：
A) 领导沟通
a 管理你的领导
PMBOK说PM有权利调配资源，不够就要去要。现实中，基本上我们的项目最大的限制除了钱就是资源，资源很多情况都被领导掌握，PM哪有随便调资源的权利？但是领导们都常常觉得，够了啊，总之你给我搞定。

PM要学会说不，制定计划的时候就要否定老大们不切实际的想法，但是绝对不是上去就狂喊，而是你的说法上要有技巧，说目标-步骤-难点-计划-资源，领导们会容易接受一些。就是说：我们的目标是，要达到什么效果，还有范围是什么——步骤是1、2、3、4，先做什么再做什么——难点是什么，哪个地方容易出错，不管是技术难点还是管理难点，PM都要考虑在内，比如技术上大家都没有做过，就是难点，比如管理上没有某个规则等等——因为有了这些难点和目标，我们觉得时间计划是什么（保留适当的储备）——因为要实现这个计划，我们需要什么资源。

领导们听到最后，嗯，很有道理，他就要权衡了，给你资源么，不给？不给重新讨价还价，目标要不要改，时间要不要延长，范围要不要缩小？给？给当然好了，PM要到自己的东西了。

无论是制定目标还是过程中，你需要资源的时候都可以尝试用这种方法。
虽然很多时候资源是被领导掌握，但是身为PM要记着，领导也是我们的资源，你用他的思维方式，引导他去思考。你要学会管理你的领导。


b 向领导暴露问题
就算这些资源都要到手了，我们就是承诺项目没问题吗？当然不是啦。领导们还是聪明而有经验的，他们都知道项目一定会有问题，他们不期望不出问题（他们基本都认为，不出问题的项目一定是有虚假信息，项目不可能不出问题），他们只是希望可控（问题可以被解决、知道对现有质量、进度、资源、budget的影响）。

所以PM千万不要心虚说，因为前面我要了这个那个，后面我就不可以出问题了，有问题就隐瞒。恰恰相反，PM就是要在过程中暴露问题。你说出来了，领导就是再不开心也知道解决问题最重要，所以他就会帮你解决问题，你就多了一个powerful的资源了。

暴露问题是要说：问题是什么——为什么会出——如果不解决，对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么？（或者好几个）-各自对上面6个维度影响是什么，各自都有什么局限和好处？——领导决策。

如果你也没解决方案（这样不算好的PM，但是没辙的时候也是会有的），你就做前面两步好了。问老板，怎么办啊？

但是无论是谁给的解决方案，也无论这个方案是什么，你最后都要向你的领导（当然包括你的所有stakeholder）说清楚，这样一个变更对目标、范围、进度、质量、客户满意度、预算影响是什么。

让你的领导感觉，虽然会出问题，但是你至少让问题的影响可控了。他在下一个问题出来前可以睡觉了。

c 什么时候汇报？
这个问题在2007年7月22日想起来了，所以补充一下。呵呵。好像有点晚。

虽然我认为很少有PM会犯这个错误，但是今天突然想起来了，觉得还是说一说比较好。周报是干嘛的？其实很多时候虽然是一个formal written的DD，但是最大的作用我认为是保持所有人对项目的关注度。让一些更大的BOSS、边缘的team member、边缘的stakeholders保持对项目的关注度；让 core team有成就感：我们做了那么多，还报告领导了。我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

一旦有了问题要马上汇报！当然还要考虑上级领导的风格（他是事无巨细都关注型还是抓大放小型）和PM的权利（什么样的问题有决策权）。但是一旦有了PM搞不定的问题是要马上汇报。你想周期性报告一周一次？一月一次？那时候黄花菜都凉了。所以马上汇报！不要怕你的领导。耽误了时间更可怕。

总结一下，有了PM搞不定的问题要马上汇报！周报、周会做什么用的？保持所有人（包括非core team）的关注度，这个会不是解决问题的，是讲讲总结（上一个周期干什么了）讲讲计划（下一个周期每个人要做什么）讲讲问题（上个周期出什么问题了，我们怎么解决的）和讲讲风险（下一个周期可能出什么问题，要注意什么）的，总之不是解决问题的。出了问题要随时解决、即时解决。


怎么写了那么长的？下面的先给个提纲，后面再慢慢写。

B) 同级、下级、供应商
C) 解决冲突

2、全局的掌控
A）理解目标，宣导给team member
B）解决方案的全面理解
C）控制变更

B）同级、下级、供应商
a 在达不到要求时，引导member继续前进
对于同级、下级、供应商他们都是你的Team Member，不要关键时候不要搬出权利来吓唬他们了。

他们需要被夸奖。听说教育小孩的经典之一是“好孩子是夸出来”，你的member是一样的，好member是被夸出来的。只是他们不像小孩子那样可以说谎的夸，你需要认真的动脑筋想怎么夸才不会显得言不由衷。夸他们除了真的做得好之外，就是你需要他们做得更好的时候了。做得更好其实并不表示他们现在做得很好，恰恰相反，可能他们做得非常糟糕，根本达不到你的要求。

但是发火是于事无补的，甚至可能激起team member的反感，都这么大人了，谁都有个面子问题的，所以我们只是要达到目标，发火不过是手段，不到必要的时候不需要发火，一来让自己心情不好，二来偶尔发火才是杀手锏，发火多了就不值钱了，你已经没有太多可让人畏惧的东西了。

夸他们是要有技巧的，你可以说：做得好啊，我们已经实现了什么什么（他的确有做的东西）——现在该我们考虑下一步的时候了，下一步我觉得还需要做什么什么——这些由你来做？因为前面做得不错。

看上去我们在夸他们，实际上，我们在给他们下套，套住他们，让他们高高兴兴的去实现我们的目的。你不需要说太多的“但是”，这会让你听上去有点虚伪，但是你可以把你的目的拆成两个来说，他实现了第一步，那么第二步不是就该接着做了吗？


b 翻译能力
PM是什么呢？好的翻译官。客户说的都是他们的业务语言，供应商有的时候说的是技术的语言，PM是什么？多语言外交官。PM有责任将不同团队之间的语言翻译成大家都能正确理解、没有歧义的语言。

只有语言统一了，大家才有交流的基础，否则是鸡同鸭讲，彼此谁也不知道对方说什么。

还是COPY之前已经用到的例子，丰田开发凌志的案例：

日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是
（1） 身份地位与尊容的形象
（2）高品质
（3）转售的价值
（4）性能（例如，操控、乘坐、马力）
（5）安全性
最后他根据客户这些感性的词语，翻译出了凌志的目标
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）
（4）空气动力……
（5）汽车重量……

项目经理就有必要将交流的内容明确化、易于沟通，常用的就是量化和名词解释，重点说名词解释。要进入一个行业就要先了解这个行业的术语。所以供应商、客户之间说不清楚多半都是名词不了解，举个例子，我们说备份好像很easy，觉得根本没有可解释的地方，可是客户根本听都没有听过。

我们首先要察觉困惑的情绪，当一个人脸上呈现出茫然的时候，我们就可以问了？有什么不明白的么？通常他们都可以清楚的说出没听懂的地方。可以看看当中有没有专有名词，有的话，就解释一下，什么意思，最好打个比方（尤其是要客户明白IT名词的时候）——作用是什么——它的变化带来的影响是什么——我们现在讨论它是为什么——你觉得呢？

举个例子备份，备份就是把每天的数据做一个COPY保存在另外的地方，好比你把重要文件COPY在U盘上，万一你硬盘坏了，可以从U盘上COPY回来，保证文件没有丢——就是保证万一服务器坏了，我们做的历史记录都在——备份保存的时间决定你可以恢复到什么时候的数据，比如，我每天备份，备份都保留15天，如果现在是2月16日，我可以恢复到2月1日、2月2日……2月15日，任何一天的状态，但是想恢复到1月30日就不行。所以备份保存的时间就是可以被追溯的时间。——我们现在就是在讨论这个系统的数据备份应该保留多长时间——你觉得你们希望可以被追溯多少时间前的数据状态？

 

C）冲突管理

冲突在项目中定然是无处不在的。甲方和乙方虽然说是一家人，业务部门和IT部门是利益共同体，可是老婆会向着娘家，老公会向着婆家也是不争的事实，所以大家因为某些利益一定会摩擦。

a）老大观点不同，却要你传话

如果是你的老大告诉你说你要这么这么做，然后你发现乙方的老大或者业务部门的老大其实基本不同意怎么办？老大们之间常常有冲突，可是总是把我们这种小卒推到前面，我们怎么做才不会破坏自己和其他方的关系，但是又完成老大交代的任务？

其实也很简单，你直接告诉其他的头们你的老大要求你这样做，问他们怎么办？一般说来，其他的头们都会直接找你的老大沟通，你就免受夹板气了。万一他没有找你的老大，你就乖乖传话，多的事情最好不要做。

这样说毕竟有点无奈，可是本来很多事情都是我们不能左右的。

b）平级间的冲突

我过去的经验是，这种冲突有很大的概率是沟通不明。人好像都有坏习惯，明明担心某件事，但是不明说，就是绕着说，说来说去，大家就为了绕着的那个东西吵架了，目的是一点没摸着边。所以摊开问是个不错的办法，你就问他，你到底担心什么。一般说来，这样能问出80%的真实目的，当然你事先要卸载他的心理包袱，比如说，你们总部不给资源，我们也能理解，我们的项目小，你们总部不重视也是情理中的，但是不知道问题在哪里我们很难解决不是？态度要诚恳友好。

沟通中很多时候好像方式比内容重要，本来你想关心人家，结果用一种很凶的口气说，人家也不会买账的。所以表述的语气、表情一定要控制好。

问明白人家的担心顾虑是什么，常常解决方案也找到不少了。再不行还可以上报，让你的老大帮你解决。可是你知道根结所在，才能让你的上级帮助你解决吧，不知道根结就走错了方向只能越走越远了。

http://www.itpub.net/786732,10.html