某项目总结分析

　　某个项目，我经手的是上线验收和项目收尾阶段，我就这两个阶段中发生的事情整理一下思维进行总结，同时就本项目引发的问题也谈谈自己感受。

　　先谈谈本项目的上线验收阶段。

　　本项目上线验收分为一阶段上线、验收，二阶段上线、验收，终验几个阶段。

　　从项目的合同签署就知道本项目在上线验收时的困难所在。二个阶段的上线，三个阶段的验收，很多合同条款都不是非常明确，加上与客户方标书内容部分相悖，注定本项目的实施是一个过五关砍六将的艰苦过程。

　　项目的每个阶段验收和回款，都是一块让人难啃的骨头，在PK与被PK过程中，使人成长。

　　第一阶段验收，由于思想上的轻视，加上我刚刚接手项目，经验不足，准备不够，没有细致了解项目，也没有深入的了解客户各部门的实力、做事方式、部分负责人的风格，没有提前想好让客户下台(交差)的策略，导致在项目验收会议上“血雨腥风，三英战吕布”。在客户服务部的强势威逼下，在信息部门的无作为下，在我们的无可奈何下，签下了xxx有史以来最羞耻的“广州条约”《呼叫中心第一阶段遗留问题.xls》，俗称“48个问题”。这“48个问题”给我们整个 07年工作带来了非常大的代价(请看下面年工作量分析)，几乎套住了伍楚云、韩洪涛、黄志雄的整个2007年，血泪史啊，是个非常值得思考的问题。事后我想项目的验收不仅仅需要考虑验收本身，而且需要考虑签署的遗留问题将给项目带来多大的影响，不能为了验收而验收。在必要的时候动用其他关系(比如客户经理关系)等等来减少部分难完成的内容。在签下“48个问题”后我写给陈总的EMAIL中，充满了失望，现在挺过来才明白那时候自己的心态也不成熟，给领导的汇报中，带有明显的个人感情色彩，增添了领导的压力。

　　收款对我们来说是整个项目最重要的环节，也是项目的目标，关系到项目、部门以及公司层面。本项目的收款充满着曲折、辛酸，这里重点提出的是验收签字以及合同约定是回款的关键点，在回款条件上必须写的非常清晰，如果验收给客户预留太多不回款的原因，回款将是个大问题。回款的过程是需要客户经理协助的，单纯靠项目经理压力比较大(特别是本项目的客户状况，而本项目的客户经理刚刚好又离职了，也是本项目收款难的原因之一)，需要项目经理、客户经理协商，相互配合，一唱一和才能达到理想结果。

　　对于二阶段验收、终验和回款，在吸取了一阶段的经验和教训之后，项目经理在经验上、沟通上都做足了功夫，在验收会议之前与信息部达成共识是项目能够验收的前提，加上二阶段开发任务没有那么多，把握住回款契机，所以比较顺利。

　　在二阶段的验收之前，打听到客户方规定“项目验收与否和相关人员收入挂钩”这个消息(契机一)，我们把信息部拉到我们同一阵营来，为项目的验收做好各种准备。

　　具体到做法，在项目验收会议之前，对使用部门可能提出的问题进行预测、整理，并与信息部门达成共识，让信息部门整理一些必要说法，分工合作，有的放矢，对可能提出的问题分配好那些由信息部门来作答，那些由我们来解析。验收会议上，客服部门虽然依然强势，但是在我们和信息部门的密切“配合”下，验收还是顺利完成，也没有再签下“委曲求全”条约。

　　由于合同允许客户去上海进行AVAYA培训(xxx付费)，而客户实际消费与报销费用不太相符，判断存在个人利益，因此我坚持必须要在二阶段回款之后才能支付给客户，这样就把客户个人利益与项目的回款捆绑一起，使客户方人员也积极推动回款，使回款能够顺利完成(契机二)。记得韩洪涛一直和我说的一句话： “xxx就是他们的一杆枪，是他们对付我们的工具”。对于这句话我非常放在心上，在后来的工作上，对xxx进行工作上、生活上关心，同时给他分析该项目如果做了几年都没完成的话，他在xxx公司又将如何如何，如果项目不能验收我们肯定将停止给他们维护等等，把他的发展、甚至是以后工作保障都与项目联系起来。一则击中他的痛处(没有能力维护系统)，二来也让他明白项目验收对他是有好处的。虽然受xxx的EQ/IQ影响，做法打了折，但效果还是让人满意，差不多把xxx改造成另外一杆枪：xxx的枪。

　　另外我觉得我们目前做项目，在项目经理变更的时候，对客户方的项目干系人关注、交接有待加强。本项目项目每个经理接手项目后，都必须从头开始认识、熟悉客户方干系人，特别是本项目的客户方干系人都比较有特点、作风比较鲜明。对客户干系人的了解程度，直接决定项目沟通、人员相处的方式。

　　再说说交差问题，在验收的时候，我把项目几乎全部可能的文档都装订成册，共16本书，当看到xxx把这些书到提到某主管领导面前，该领导只问了一句： “是我们的手册多还是营抄手册多?”当得知我们的手册装订比营抄好而且数量比营抄多时，领导连声说好。这也是国企的一种处理风格。 项目管理者联盟，项目管理问题。

　　写写项目收尾。

　　可能很多同事在项目收尾阶段都有一大段的牢骚，血泪史当然是少不了的。本项目的项目收尾，也可以谈得上是xxx的世纪经典，至少可以说是产品实施咨询部项目收尾中非常典型的一个。在项目“接近”结束的时候，项目陷入困境，客户不断的提出新要求;本以为已经干完了“该干的事情”，结果拿起合同一看，天啊……客户要一项一项地对合同的话，根本就不可能验收。在项目实施期间，时时刻刻看着合同来做事，是项目验收的关键。

　　本项目收尾发现的最大问题，也就是上面提到的“48个问题”，其中以报表、大屏幕、录音为罪魁祸首。

　　报表在实施开发过程中，忽略了客户确认签字的环节，导致在项目上线验收之后，投入大量的人力来进行报表的纠正、核对，一个很重要的原因就是：我们拿不出报表核对的客户签字文件。看到客户牛气冲冲的对我说：“你们说报表数据已经核对了，请你们提出证据。”我的心啊，就像是被人狠狠的K了一下。这个问题给我们的最大教训就是：在项目实施过程中，凡是需要客户签字的文件，一个都不能少。宁愿花多些时间去完成签字，也不能漏过，免得给以后的工作造成麻烦。

　　大屏幕就不多说了，牵涉到研发也投入不少的人力，但客户满意度还是很低，也是个教训。

　　谈谈录音吧，对于xxx这样的客户，交差是最重要的，明白了这一点也就是明白了客户为什么在录音关联率这个问题上与我们玩数字游戏。90%、95%等百分比的关联率这个概念在本项目中是不能随便答应客户。本项目最大的问题就是与客户进行90%的数字问答，客户在验收后我们要收钱的时候，总是让我去测试这个问题，结论就是：如果是89%的话，都算不过，不能回款。我刚才说过这样的客户最大的问题是要让他能够交差，他们的领导会问：xxx答应是90%，没问题吧?所以如何从客户角度去想办法让客户能够交差是客户同意我们做法的关键。

　　根据PMI(美国项目管理协会)的概念，项目收尾包括合同收尾和管理收尾两部分。合同收尾就是抓起合同，和客户一项项的核对，是否完成了合同所有的要求，是否可以把项目结束掉，也就是我们通常所讲的验收。理想的情况就是“合同有的一项不能少，合同没有的一个也不能多”，但在中国做项目，基本上前半句是必须的(少数例外)，后半句就是我们努力的目标啦。管理收尾是对于内部来说的，把做好的项目文档等归档;对外宣称项目已经结束;转入维护期，把相关的产品说明转到维护组;进行经验教训总结，项目成员一起来“怀旧”学习一把。项目总结是一个非常重要的环节，但我们貌似没有足够的重视。

　　合同收尾是最容易产生问题的时候。象管理学上经常提到的80-80理论，花了计划的80%的时间以为完成了项目80%的工作，结果剩余的20%的工作又要花80%的计划时间来完成。这样的原因是什么呢?是否不能避免呢?

　　记得在seven-habits里面提到一个好习惯：“Begin with the end.”这句话对于项目经理来说确实是金玉良言。项目开始的时候是不是看着最后的合同验收来做事呢?不止一次的听说，有项目经理在合同收尾的时候，客户提出一项一项对合同来验收，他才到处去找合同。这样的项目怎么能够Begin with the end呢?

　　诚然，合同有些签得比较“离谱”，能人之不能，把项目吹得能把客户想要的一切都办得到，而且合同中写的字很多都存在模棱两可的，也没有清晰的说明一些具体情况，存在很多“全部”、“其他”等等描述。客观来说，这也不能怪业务人员，业务人员是很苦的，陪吃陪喝陪笑，打肿了脸装胖子，在客户面前信誓旦旦才能把项目签下来，就差没跪下来求客户了(摘自某业务人员之口)。他们又怎么愿意去“骗”客户呢?客户是他们的衣食父母，客户就是他们的全部，项目做得不好，最难交待的还是他们。但是项目启动之后，项目经理是否就应该好好的研究合同，与业务人员沟通，了解客户最想要的是什么，然后做好需求，重新列出项目的范围，尽可能让客户认同。这样就算不能完全避免需求不断增加不断改变的风险，也能有所改善的。 至少就项目开始阶段就明白客户可能在那些地方会“难为”我们，会拿那些问题来说事，在项目开始阶段就准备好相关的答案，而且实施各阶段任何时候能够统一口径“对付”客户，避免象本项目一样，项目经理变更之后出现对客户不一致的口径，常常被客户拿来强迫我们就范的根据。

　　现在谈谈需求控制。

　　需求的改变是项目经理最头疼的，本项目中，客户今天说要天上的大雁，明天又想吃深海的石斑，作为买方，他们没有完全付款，当然能够喜欢要什么就要什么，这本身是无可厚非的。但是做为项目经理，我们怎么控制让客户尽量少地变口味呢?除了上面所说的项目范围的锁定，还需要的就是做好沟通。有时候客户只会从结果考虑，他们想要深海石斑，不会想到抓石斑鱼是很不容易的，先要建造一条远洋渔船，结一张结实牢靠的大网，雇请有经验丰富的船员……我们先要知道的是客户最关心的是什么。如果客户希望要吃的是满汉全席，不管花多少钱，只要赶快上菜就满意了，我们可以先答应他的要求，然后告诉他们石斑对于我们来说一点难度都没有，不过需要1个月的时间去抓，那就要推迟一个月吃上满汉全席，他们说不定就放弃了。当然，这个时候项目经理谈判的技巧是很重要的，既要不吭不悲，又要理据充分，不能胡编乱造哄骗客户，客户不是傻子，他们如果怀疑你的能力和诚信，以后就更难沟通了。在难度不大改变不多的时候，我们更应该的是作出适当的退让，爽快的答应客户的要求，然后让他们知道我们作出了多大的牺牲去帮助他们实现愿望。

　　记得本项目中，有一次客户需要修改IVR转人工之后的等等音乐的时长，其实对于我们来说，简单到就是“一分钟搞定”的事情，但我是这样做的：

　　1、让客户承认该功能为变更，按合同是需要付钱的。这一点很重要，这是为下面引导客户或者让客户心存感激做好铺垫。

　　2、我答应客户是可以帮忙修改的(当然不会告诉客户这是个“一分钟搞定”的事情)，真正帮客户解决问题。

　　3、在客户不好意思的条件下，完成修改。让客户觉得欠了我们一个人情，后来引导、说服客户放弃了一个非常困难的变更。

　　本项目中客户是比较难缠的，不管你上天入地吊脖子，反正就是坚持他的要求，这样的客户就需要你花更多的心思了。人性总是有弱点的，本项目中体现部分国营企业的客户有强烈的自卑和反叛心理，觉得你们是IT公司，高科技高收入嘛，就是要你难看。二阶段就那么点内容，还收我二十几万?那我们是否可以尝试更多的让他了解你的难处，“俺也是苦命人啊，老板欺压我们，要我们没日没夜的干，你改一点东西我们全组人都一个星期睡不好觉啊。”，“去年我们xxx项目的参与人员都没有奖金啊，其他项目都有，想想我们也是很痛心啊。”，“其实我们的工资比你们还低，就是税前三千元而已”，客户也是有同情心的嘛，让他得到多点平衡，说不定对大家都有好处呢。有些客户怕你凶，你就偶尔适当地凶一下，我就对xxx某位人士拍桌子，让他明白如果再这样的话，我们就不维护项目了，那他们的责任就非常大;有些客户喜欢你温柔，你就软皮蛇一点好了，让他心情舒畅;有些客户很大男人，总是觉得自己技术很强，但又不想亲自去做，总是提出一些让你很吐血的东西，经常说的话就是“这个在技术上实现是没有任何问题的”，你不妨让他觉得你是非常尊重他的，他的“分析非常到位”、“理解、技术能力非常强”，恭维之后再诉苦，估计问题就解决啦;中国的地大物博，也给我们提供了一些难题，不同地方文化差异较大，人的性格差别很大。本项目的客户方是典型的南方国企，几乎所有参与到该项目中的客户方人员都兼顾了国企的文化和南方人的性格、作风，所以在与之沟通的时候，需要对症下药，不能按对待北方人的思维来沟通和处理问题，否则会越来越糟。夸张了一点，因地制宜、因人而异。瞎侃了这么多，其实做起来还是很难的，项目经理的经验起着决定性的作用，而我自己从这个项目学到的东西将受用一生。我们不妨抛开尊严与自信，多一点学习、研究别人的经验，试着做得更多一点，说不定会有所改进。

　　最后谈谈我在本项目中出现过的一个问题，供大家共享，估计也是其他技术出身的项目经理，很容易犯这样一个错误：把自以为简单的问题分配任务给成员时，会夹带技术细节并表露出问题的简单性。这个错误我花了很长时间，甚至到现在也没有完全改过，或者说还不够“专业”。

　　记得刚刚接手xxx项目的时候，有一次我接到客户的新需求，要求更改页面上的某个字符串。于是立刻把伍楚云叫过来，“这个需求只要把对应页面的字符串改一下就OK了，几分钟应该搞定，你赶快去改一下”。姑且不论这个问题是否真的简单，首先的问题是，我觉得自己混淆了项目经理和开发人员的界线。具体实现细节是开发人员的事，项目经理不需要关心，即使开发人员不懂如何实现，那也是技术经理的事。此外，“几分钟搞定”这种话，对开发人员来说往往是一种伤害。最常见的一种结果是，开发人员后来发现问题没这么简单，不光要修改页面文件中的字符串，还涉及到数据库中某个字段的修改，更麻烦的是，修改后单元测试一片红。几分钟的问题，最后花了几天才搞定。大家一定要切记!

　　套用一句古话结尾：项目经理当有所为，有所不为。