进退两难——一个项目经理的日记(精典)[转]

日记一2001年10月2日 晴

香港主题：得意的夜晚东方之珠，我爱你！

我真想打开君悦酒店的落地窗，对着维多利亚海湾的夜空喊它几嗓子，好好宣泄一下自己的兴奋。今天我忙得连轴转，上午由京抵港，下午就与盛凯公司的高层进行会晤，晚上又是签约又是庆祝宴会，回到酒店已是深夜了。累是累了点，但我们安讯终于与盛凯正式签下AHS计费软件开发的合同了，这可是我们在大陆以外地区签下的第一大单呀！盛凯找我们安讯开发计费软件真是找对人了。AHS软件是我们自主开发的，而且已是成熟软件了，在内地就已经为多家电信运营商提供过管理和计费服务。哈哈，我们安讯这次又赢定了。

今晚的宴会真隆重，盛凯总裁叶焕、副总裁兼项目总负责人井之助、项目组成员兼IT经理程万科、项目协调人宋锐鹏，还有项目所涉的三个业务部门的经理都参加了，而且还邀请了香港政界、金融界有关人士。看来盛凯对这项目可是寄予了厚望的。大家觥筹交错、推杯换盏的时候，叶焕特地把我扯到边上，让我在这项目上多多费心。我怎么可能不用心呢？但是有个现象让我觉着非常奇怪：井之助好像是个局外人似的，满脸堆笑坐在一边，但就是没人上前与他搭话。

今天，真是一个值得纪念的日子，无论是对公司还是对我自己。这是安讯第一笔在大陆之外的业务。明天公司一发布公告，在NASDAQ的股票肯定会应声而涨。对我来说，这是难得的好机会。来之前老总张慎向我透露说，公司要成立海外事业部，希望有个能干的年轻人来担纲。如果我把盛凯项目做好了，那么就等于约涸黾恿艘桓鲰缆搿?/P>

事不宜迟，我明天一早就回北京，抓紧时间把这个项目启动起来，决不能辜负张总和董事会的期望。

日记二 2001年10月8日 多云

北京主题： 招兵买马

这几天，我作为盛凯项目的负责人，一直忙着筹建项目组。经过几番精心挑选，我终于将组员名单敲定了。整个项目组下辖3个部门：产品市场部由夏飞负责，产品售后服务部由包锐龙负责，产品开发部由我直接领导。我这次选的全是安讯公司的精兵强将，张总这次在人事上可是给我一路绿灯，我选中谁他就给谁。我现在对这个项目是志在必得啊！

日记三 2001年10月18日 多云

北京主题：分歧，浮出水面

8天前，夏飞带着两位软件总体设计师去了香港，和盛凯讨论SOW*的编写，也就是说，按照AHS软件的模块划分，向盛凯解释AHS目前具有的功能，并根据他们的业务陈述确定他们的需求，再把原有功能与他们的需求相比较后确定需要新增的功能。我原本想AHS是个成熟产品，已经在内地经受了很多用户的检验，夏飞这次去香港讨论SOW不会有什么大问题，但是事实证明我们过于乐观了。

晚上，我边在公司加班边等夏飞回来。7点多钟的时候，夏飞从机场直接回到了办公室。我打电话叫了两份外卖后，正想问问他香港之行的收获，哪知他一开口，却说出了一个我根本没有想到的问题。原来夏飞他们在与盛凯讨论SOW的编写时发现，盛凯对新系统的期望远远超出了AHS所能实现的功能。AHS是为电信运营商提供用户管理计费服务的软件，主要功能是受理和保存用户资料、计算用户使用网络资源的费用，以及生成统一用户账单等；而盛凯要求AHS能够增加对其公司内部业务流程的跟踪、反馈、管理以及对相关职能部门的支持等功能。这就要求AHS在现有的结构框架上进行较大的改动，而不是对我们原先设想的稍加修改了。夏飞还说，如果我们不答应对方的要求，他们将终止合同。这种情况确实出乎我的意料，好像给了我一记闷棍。盛凯要的软件系统哪里只是计费系统啊？他们明明要的是一个办公软件系统嘛。

明天在盛凯项目汇报会上，我得把这个问题提出来，听听领导和同事是怎么想的。

日记四 2001年10月19日 阴

北京主题：打翻了五味瓶

今天在会上，我将夏飞带回来的问题向张总、其他领导及项目成员作了汇报。我话音刚落会议室就嘈杂声一片。包锐龙第一个嚷起来：不一直说是计费系统吗？怎么盛凯说加就加了？再说，我们开发办公系统的能力行吗？夏飞和两位软件总体设计师在旁边也点头附和：我们的强项是计费系统，不是办公系统。的确如此，我们过去几年做的成功案例都是计费系统，办公系统我们涉及还不多。

说心里话，我支持包锐龙和设计师们的意见，但我不能表明自己的态度。这项目是公司的希望，意义重大，所以只准成功不准失败，决不能因为双方的分歧而使它夭折。于是我在会上再次强调了这个项目的价值，委婉地批评了设计师们不敢创新、不敢探索的畏惧心理。当然，他们对我的意见也进行了回击。一番唇枪舌剑之后，最终还是张总一锤定音：这个项目对我们公司太重要了，盛凯要什么功能，我们就上什么功能。晚上拖着疲惫的身体回到家中，心情很是复杂，犹如打翻了五味瓶，既庆幸项目能够继续下去，又担心项目会遇到麻烦。

日记五 2001年11月7日 晴

北京主题：初战告捷

今天中午，眼圈发黑的夏飞找到我说，174页的SOW已经基本写完了，但是有几点还不够具体，最好还是再飞一趟香港，再听听盛凯的业务陈述。我没等他说完就打断了他，算了吧，明天你就把SOW传到香港，让他们确认一下。你们已经搞得挺详细了，以前还没有这么具体呢。况且要多留点时间给我们开发部。当他的面我没多说什么，实际上嘴上不说肚里讲，SOW搞成174页，哪个工程师会有兴趣把它全部读完呢？说一千道一万，SOW毕竟还是纸面上的东西，只要我们开发出来的软件盛凯方面基本认可了，那些停留在纸面上的细节问题留在合同执行过程中再与他们慢慢商讨也行。我们以前做的项目基本上也是这样做的。

晚上，我叫上项目组的其他几位同事，一起去三里屯的SWING酒吧摇滚了一把，庆祝SOW成功结稿。三里屯确实名不虚传，那里的每一寸空气都散发着魅惑。无怪乎人家说，三里屯才有北京的夜。

明天我就打电话给财务部，让他们盯着盛凯付款，按合同他们现在得付我们30%.今夜感觉就是一个字——爽，到现在还能感觉到SWING酒吧啤酒的爽劲儿。

日记六 2002年3月7日 阴

北京主题：说3种话的中国人

三月的北京静悄悄地绿了。路旁的杨树开始泛起细密的彩色光晕，而我的心中却是乍暖还寒，塞满了隆冬的风雪。事情本来一直很顺，去年秋天明确了SOW后，我们产品开发部就日以继夜、废寝忘食地工作，仅花了4个多月的时间就结束了项目开发。接下去，包锐龙的售后服务部只要到盛凯公司安装、调试好软件系统就大功告成了。

可谁知问题出现。应盛凯的要求，我们在售后服务部去香港之前与盛凯进行了一次远程演示。今天下午我们双方通过远程计算机共享和电话会议的方式开始演示，由我们主讲AHS的功能，由盛凯评论和提问。这也是双方第一次针对软件实现的具体情况进行交流。

但我没想到双方沟通起来竟会如此的困难和复杂。一场本来计划两个小时的会议竟然开了近6个小时。我觉得我们开发的系统基本已经满足盛凯的要求了，但盛凯方面仍旧反复强调他们要的不是这些。那他们要的究竟是什么呢？他们又没人能说清楚。最糟糕的是，在盛凯的项目组中，除了项目协调人宋锐鹏会说普通话外，其他人只会讲粤语和英文。而我们这儿的人英文都不好，粤语则基本听不懂，我们只有靠宋锐鹏在粤语、英文和普通话之间来回地翻译。一个下午下来双方都弄得疲惫不堪。最后，我们只好先达成初步意见，让盛凯的人员自己登陆AHS系统进行熟悉，一周后再给出他们的反馈意见。

今天IT经理程万科竟然没有参加我们的远程演示，明天我一定要给他发封Email，请他在技术上帮帮各业务部门的人，一是让他们熟悉AHS的流程，二是缓解他们对新系统的抵触情绪。

日记七 2002年3月14日 阴有雨

北京主题：成功，渐行渐远

自从上次和盛凯的电话会议后，我们陆陆续续接到盛凯各业务部门的反馈。但是我没想到这些反馈意见全是用英文写的。更要命的是，我们开发部的工程师们面对这些似是而非的提问，却不清楚问题具体出在了哪里，也不知道该如何修改。不过我敢肯定，盛凯提的问题，有相当一部分是属于对AHS系统了解不深的缘故造成的。他们怎么能这样不认真呢？为什么就不愿在这个新系统上多花点工夫呢？我真是想不通啊！

我已给程万科发了几封Email，但一直没有收到他的回复。打电话给他，多半是他不在自己位置上，就是找到了，他的回答也是支吾其词，一听就知道在那儿糊弄我、搪塞我。看来不向井之助和宋锐鹏反映反映，是搬不动他了。

我似乎感觉到就要到眼前的海外事业部现在渐行渐远了。看来下周我和夏飞有必要跑一趟香港，给盛凯进行现场演示，加深他们对AHS的认识和理解。

日记八 2002年3月31日 晴

香港主题：花开花落

到今天为止，我在香港已呆了两个星期了。在这14个日日夜夜中，我的感觉除了累便是沮丧，而后者更甚。刚才从盛凯回君悦的路上，我注意到道路两边的紫荆花渐次凋谢了。去年我签约的时候，一眼望去可是连树连枝，灿若云霞呀！真可谓花开花落终有时.紫荆花的这份凄凉触发了我心中不敢预想的结果：这项目的命运会与这花一样吗？

刚到香港演示时，我们打算将用户的思路引向AHS实现的方式，试图告诉盛凯：AHS系统实际上变相地实现了他们的要求。可两天后我发现这项工作很难进行下去。随着双方的深入接触，我发现双方分歧不在于某一个功能能否实现，而在于实现方式是否符合盛凯的业务操作习惯。在盛凯老系统的操作模式中，工作流程能够一气呵成；而在AHS中，一个完整业务流程的操作常常需要在几个界面或模块之间来回跳转。

而且，我们双方对AHS的看法也不一致。由于AHS最初作为一个计费软件，我们认为其核心是计费的灵活性、准确性，而没有过多考虑部门间工作流程的组织管理。然而宋锐鹏却坚持认为，这是系统必备的功能，他们执意要求我们按照他们的工作流程进行修改。

在接下来的1个星期里，我们干脆放弃了演示工作，索性听盛凯来讲他们的业务是什么样的，他们的工作流程是怎样的。这一次，我们听到了许多SOW中没有详细说明或没有说明的部分。我想起夏飞去年11月份在将SOW交给我时说的一番话。唉！他是对的，我们是应该多听听盛凯的业务陈述。

令人奇怪的是，那个程万科两个星期来一直没露面。向宋锐鹏一打听，他竟然去休年假了。什么时候了还去度假，他安的到底是什么心？我忍不住向宋抱怨起他的不合作。宋努努嘴做了个干笑的样子，但没吭声，分手时却扔了一句话我帮你向井之助反映一下.明天就回北京了，看来不对AHS大动一番手脚是不行了。

日记九 2002年4月7日 大风

北京主题：重整旗鼓

回到北京忙活了一个星期，总算理出了一个思路。根据新掌握的情况，我又制订了为期两个月的二次开发计划，在5月底前完成AHS的修改工作，争取6月底能在盛凯上线。在此阶段，开发和测试人员将重点放在上次现场演示时发现的问题上，重新修改实现方式，力求在界面操作流程上能符合盛凯的使用习惯和工作流程。

估计接下去我的人手要紧一些。由于公司最近又接了一个项目，张总把我们项目中的两位设计师抽调过去了。由于他们一直参与盛凯需求定义的编写工作，所以井之助与宋锐鹏对他们中途离开颇有微词，但公司也是迫不得已，盛凯项目已经占用了公司太多资源了。

今天收到了井之助的Email.看完信才知道，程万科对AHS有很大的抵触情绪，因为他清楚AHS上线的那一天，也就是他离开的那一天。现在井之助也拿他没办法，不敢得罪他。因为万一我们安讯的AHS不行，他们还得用现有的计费系统，那么就还得依靠程万科管理现有系统。看来让这家伙来协助我们是没戏了。

日记十 2002年6月7日 闷热

北京主题：峰回路转

今年夏天来得特别早，温和的春季刚晃了晃，北京就直接迎来了火一样的盛夏，我真希望能下一场大雨，透心凉的那种。最近，同事说我瘦了许多，想不到盛凯项目还有这样的功效。

令人庆幸的是，二次开发工作终于按时完成。我们每位项目成员对更新后的AHS系统都是信心百倍，觉得可以马放南山、刀枪入库了。我心中的一块石头也落了地，毕竟在3月份我们对盛凯进行了两周的现场调研，对盛凯的业务模式已经基本了解清楚。夏飞对此也是满怀信心，AHS系统这次肯定能对他们的胃口.下星期就要去香港给盛凯做第二次演示了。这一次每个模块的开发工程师都要到盛凯去做现场演示，如果再有什么小问题，我们就当场修改，争取一鼓作气结束这个项目。说实话这项目不能再拖了，按照合同我们要在6月底完成AHS的安装使用。否则，我们安讯就会变得很被动，弄不好还得支付违约赔偿。哟，我怎么写出这么丧气的话？这项目肯定能如期结束！

好长时间没休假了，等这个项目结束后，我要去北戴河享受一下清凉的海风和蓝蓝的海水。

日记十一 2002年7月12日 酷热

香港主题：此改绵绵无绝期

我觉得好烦。来香港已经一个多月了，原打算6月底将AHS系统上线的计划也一再搁浅，看来，AHS在盛凯的投用之日似乎遥遥无期。

更让我感到郁闷的是，盛凯在这个项目上始终是一个被动的合作态度，那几个部门经理的作风是：我们问什么，他们答什么；如果我们不问，他们就什么也不说。但是碰到问题，就开始指责和抱怨了。上次提出了使用习惯和工作流程问题，这次又提出了多个部门之间的业务接口问题。

这并不全是我们的错。他们内部在业务接口的定义和部门业务划分上也是争吵不休。盛凯以前没有明确的制度将部门间的责任确定下来，现在AHS系统要将部门责任明确下来，各部门于是便明争暗斗，争权夺利，推卸责任，千方百计地想扩大自己部门的地盘。这些情况我都已向井之助反映过，但他总是哼哼哈哈，拿出来的方案也是一改再改。

我现在觉得，井之助是个没有组织能力和控制能力的人，就连他的领导权威性，也没有得到部门经理的尊重。昨天下午在井之助主持的项目协调会上，这些经理个个心不在焉，没有个开会的样子，企业服务部经理被人叫出去后再没露面。找人一问，原来经理出去见客户了。他不在，有关业务接口的讨论就无法继续，井之助一脸无奈，只好宣布会议结束。看来井之助的领导无力也影响了项目的正常进行。

今天上午，我把这些向北京总部做了一个完整的汇报，张总指示说，既然盛凯不肯妥协，那么全体项目组成员就先回来，根据这次收集到的问题再进行一次完善的开发工作。

我有一种深陷泥沼的感觉。

日记十二 2002年7月18日 阵雨

香港主题：呼啸的台风

今天天鹅台风席卷整个华南。从君悦望过去，维多利亚海湾浊浪滔天，惊涛拍岸，而我心中也是狂风大作，暗流急涌。

这个星期一，我和一个软件测试工程师再次来到香港给盛凯进行第三次现场演示。虽说这次要比前两次顺利，至少盛凯对系统提出的一些问题都基本上得到解决，但是在诸多细节上，盛凯又提出以前没有提到过的要求，比如系统要能够给市场营销部提供更强大的支持功能。

此外，前两次一直没参与我们演示的程万科也第一次露面了。在和他的讨论中，我们突然发现AHS系统存在一个重大的缺陷，这是我原来没想到的。虽然我们对此有不可推卸的责任，但是如果程万科能够早一点与我们积极合作，就不会直到现在才发现这个问题。

现在已是深夜，窗外台风依然呼啸，风势不减，我心中对AHS这次上线的希望也被台风吹得无影无踪。

日记十三 2002年10月28日 微雨

北京主题：最后通牒

上午，我收到了由盛凯总裁叶焕签发的紧急传真。客套的话语难以掩藏他对这项目的失望情绪，并且他还提出了三个问题：第一个问题是：直至今日合同仍未履行完毕，延期的损失如何处理？第二个问题是：今后的实施费由谁支付？最后一个问题则是继续履行合同的时间安排，如果安讯不能给出明确的时间承诺的话，他就建议我们及早放弃这个项目。如果现在终止项目，我们可以少付点赔偿金，否则，他们将会要求我们严格执行合同的赔偿条款。

今天张总在重庆出差，我打了个电话向他简单汇报了一下。在电话中，听得出张总很着急，他表示让我先稳一稳，他后天就提前赶回来。

不该发生的终于发生了！

日记十四 2002年10月29日 细雨

北京主题：无用的决策树

早晨刚一上班，助理小王交给我一封财务部转来的炎黄审计的信。我们核算收入的方式是采用完工百分比法，这个项目应该9月份就结束，所以所有的合同款已经记入公司收入，而盛凯实际上只付了合同款的30%.炎黄审计发现了这一问题，要求公司给予说明。财务部给出的建议是：请炎黄向盛凯发欠款确认书，以此证明安讯没有虚假账面收入。但根据昨天叶焕在传真中的口气，盛凯是不可能签署这份确认书的。

叶焕的终止项目建议虽然我一时无法接受，但确实提醒了我。我们到底还要不要把这个项目继续下去？进还是退？这也许是现在最迫切需要回答的问题。

我们已为盛凯项目花费了85％的合同金额，即使这项目成功地做下来，也已经无利可图。公司还有很多新项目需要完成，但因为盛凯项目的牵制而不能够正常开展。最头疼的是，这项目什么时候能够结束，谁也没底，因为我们无法控制盛凯内部的问题。但是终止这个项目，公司投入的资源就变成了沉没成本，这是一笔很大的数字啊！现在的AHS系统是为盛凯度身定制的，对其他公司没有利用价值；并且，我们还要面对盛凯的赔偿条款。

今天下午，我画了好一阵子决策树，希望能从中找到救命稻草，结果越画心越乱、越没谱。真要命！我该怎么办？怎么向张总交待？？安讯怎么办？？？

又是秋雨时节，在22层高楼上俯瞰落雨的长街，我觉得很冷，真的很冷。

我该如何做才好呢？

--------------------------------------------------------------------------------------------------------------------------------------
以下是评论：

评论一：SAP大中国区执行副总裁
黄骁俭专家

    专家背景：SAP大中国区执行副总裁

    观点："商用软件开发项目的本质是整个企业运营管理模式的改变、企业中部门之间的利益划分和人与人之间的权力分配。"


    商用软件行业是一个非常特殊的行业，人们从其表面上看到的只是编写的软件代码、应用的界面和输出的单据，但其本质却是整个企业运营管理模式的改变、企业中部门之间的利益划分和人与人之间的权力分配。此类项目的失败，不仅仅是项目管理没有做好的问题，而是没有把握到项目涉及的商业文化问题，按照中国人的说法，是"政治思想"工作不到位。
就此案例，我个人看来存在如下几个问题：

    第一个问题："这个项目是怎么得来的？"
    我们可以发现,在签约之前，盛凯根本不清楚AHS的功能，或者说安讯根本不清楚盛凯要什么东西。这说明合作双方对信息化项目的目标没有达成明确的共识；

    第二个问题："仅仅是语言沟通上的障碍吗？"
    看到案例中安讯的项目负责人感叹同是中国人却要用3种话进行交流的时候，实在是哭笑不得。我要说他们缺的不是哪种人文语言，而是更为重要的行业语言。
如今，商用软件的开发越来越强调行业化，所谓隔行如隔山，软件公司所掌握的技术只是软件技术的本身，而把软件变为可以在企业中实际应用的业务系统，就必须掌握应用企业的业务特征，也就是行业的特性。我们可以设想一下，如果本案中的安讯非常了解香港电信企业的运营特点和状况的话，那么它和盛凯的电话会议就不会那么费劲，即使再多几种语言也不用担心，因为大家有一个共同的"行业"语言存在。

    第三个问题："谁在主导项目？"
    既然商用软件开发项目的本质是整个企业运营管理模式的改变，以及企业中部门之间的利益划分和人与人之间的权力分配，那么谁才是项目真正的主人？盛凯总裁叶焕？副总裁兼项目总负责人井之助？还是项目中代表安讯的"我"？
大家都把涉及商务的信息化建设项目称为"一把手"工程，不言而喻，企业的一把手在项目中处于一个非常重要的地位，因为只有他才能掌控项目所涉及的权力和利益的再分配。但现实中不是这样，很多企业一把手往往只是挂帅而已，基本不会参与项目的实际进程，因此项目在关键时刻容易产生变故。

    第四个问题："安讯能走出内地市场吗？"
    在中国有成百上千个像安讯这样的公司，它们在内地市场获得了一定的成功，便很想走出国门，到国外去获得更大的发展。由于面临人才 商业环境 和资金门槛,他们的成功之路面临很多挑战.

评论二：上海交通大学安泰管理学院副院长

 徐 飞专家

    专家背景：上海交通大学安泰管理学院副院长、EMBA项目主任、战略管理学教授

    观点："作为项目领军人物的‘我'，不清楚项目经理的职责，沟通和协调能力较差，对项目管理经验不足，因此，感觉到‘很冷，真的很冷'是在所难免的。"


    安讯公司显然缺乏项目管理尤其是国际项目管理的运作经验，主要表现为：不熟悉项目管理的决策流程，在项目的实施阶段，又缺乏对软件开发和客户需求的柔性管理能力，而沟通机制的混乱更使项目的进展如履薄冰。在整个项目过程中，作为项目领军人物的"我"，不清楚项目经理的职责，沟通和协调能力较差，加上缺乏对项目管理方面的经验，因此，感觉到"很冷，真的很冷"是在所难免的。

    安讯公司承接盛凯项目的决策流程非常草率,直接导致了在项目进程中的被动.

    在项目的实施运作阶段，我们也可以看到，安讯公司缺乏对客户动态需求的管理，缺乏对客户需求的柔性或个性化定制体系。安讯公司应发挥主导作用，并在充分沟通的基础上诱导出客户的真正需求。

    安讯和盛凯双方交互过程的失败体现出整个项目的沟通机制也存在很大问题。
实施管理软件往往涉及中高阶管理人员和雇员现有利益的调整问题。从表面看，盛凯公司似乎只是上一套软件系统，本质上却必然伴随管理观念的变革、业务流程的重组和部分管理人员既得利益的调整以及人事上的变化，其中产生的利益冲突非第三方所能控制，只有争取盛凯总裁叶焕等高层管理人员的承诺和支持，并展开相关的变革管理方能推动项目的进展。程万科可以说既懂得技术，又熟悉相关的业务流程，而且知道目前系统运作存在的问题和缺陷，因此在涉及利益冲突中如何争取他的支持是问题的关键。如果和程万科这类关键人物缺乏深入细致的沟通，盛凯企业内部的深层次问题便很难超越和化解，对安讯公司而言，盛凯项目的失败几乎是注定的。此外，安讯内部的沟通也存在问题，如项目开发部没有与市场部和售后服务部相互沟通。

    本案例由点到面折射出供应商为客户提供服务尤其是为客户量身定制管理软件过程中存在的两个典型问题。第一个问题是技术与管理的分裂。客户公司的管理人员不知道软件相关的设计过程及专业背景，而软件人员则不熟悉行业知识和企业内部管理运作流程，导致设计的软件操作不方便、不合乎企业运作流程等问题；双方缺乏良好的沟通也导致软件系统难以付诸实施。第二个问题是很多企业条件不成熟就赶时髦上马OA、ERP、CRM管理软件项目，通常成功率较低。同时，企业的期望值太高，希望这些项目在短时间内实现决策、管理、生产、销售的科学化、系统化、一体化、集成化、透明化，其结果只能是欲速则不达

评论三 ：IBM业务咨询部合伙人
梅 昕专家

    专家背景：IBM业务咨询部合伙人

    观点："安讯的项目负责人或是沉醉于对技术的自信，或是缺乏应有的敏感，没有能够未雨绸缪，从各方面及时、合理地管控项目风险，才会造成目前难以收拾的局面。"


    本案例中安讯公司在项目中遇到的困境说明，在一个项目的进行过程中，项目管理不能仅仅停留在简单的技术层面上。
从本案例的发展来看，安讯的项目管理人员有不少机会可以发现并设法纠正项目进行过程中存在的危险苗头；但遗憾的是，安讯的项目负责人没能及时、合理地管控项目风险，从而造成目前难以收拾的局面。

    首先，从双方的沟通与投入来看。由于安讯的项目组成员对项目最重要的需求确认阶段不够重视而导致了项目组与盛凯方面的沟通障碍，因此项目初期的工作难以得到盛凯的认同也就在情理之中了。

    其次，从项目的范围和对用户期望的管理来看。安讯一味要求客户僵化地套用一个现成的计费系统，而没有考虑到盛凯公司具体的业务与管理流程的特点，这当然是难以被盛凯所接受的。这也导致安讯项目组不得不又花了两个月做二次开发。出于项目成本和安讯自身利益考虑，严格控制项目的二次开发和项目的范围当然是必要的，但同时更重要的是应该理解盛凯需要从这个项目实现的价值。

    另外，从项目中的技术开发工作与其涉及的变革的关系来看。安讯公司似乎将盛凯项目过于单纯地定位在技术开发层面。

    鉴于盛凯项目对安讯的重要意义，安讯公司应该立即采取的行动是：
对项目进行目标/效益分析，同盛凯高层达成共识；对用户需求和存在的问题进行分析，提出针对性的方案；调整双方项目的主要负责人及部分核心成员，要求盛凯保证项目在其公司范围内获得足够的支持与承诺，安讯方面需要补充有较强沟通能力、在业务流程与变革管理方面富有经验的人员；双方公司的最高领导要提高沟通的频率，及时就已出现的问题做出决策；在盛凯有关部门的积极配合下对业务需求进行充分研究、沟通后重新提交方案；重新制定项目的时间表和预算表，并注意在时间上为可能的变化预留一定的弹性，等等。

    事实上成熟、完善的项目管理是保证项目成功的关键要素之一。作为一个简单的项目管理的框架，以下6个方面是项目管理人员需要特别关注和控制的：
    项目各方高层的承诺和投入
    项目客户方的业务价值的实现
    项目内容和进度
    项目范围
    项目团队
    项目风险

评论四： 光明乳业信息总监
赵春雨专家

    专家背景：光明乳业信息总监

    观点："绝大部分项目中，相关人员的‘心理准备'或‘文化准备'时间要远远超过项目的实施时间。"


    在这个案例中，虽然苦恼的是作为乙方的安讯公司的项目负责人，但甲方盛凯公司的负责人也一定会为项目目前的进展状况而寝食难安吧。
盛凯方面在以下3个层面的问题是导致项目进退两难的主要原因。

    首先，盛凯并不清楚自己的真正需求。在实施信息化项目前，盛凯应该问自己：为什么要做这个项目？这个项目真的要做吗？在案例中，盛凯连这些问题都没有回答清楚，这是导致项目失败的最根本的原因之一。
要解决这个目标和方向不明确的问题，甲方可以在寻求软件开发商的同时再寻找一个合适的第三方的咨询公司作为项目合作伙伴之一, 帮助把握好方向。

    其次，盛凯的企业环境和企业文化都没有为这个项目的实施打好基础。我们从案例中可以看到，盛凯公司的不少员工，尤其是高层人士，没有为项目的实施做好充分的心理准备，这都说明，在项目实施前盛凯的高层没有在公司内部倡导变革的理念，营造变革的氛围。实际上，大多数项目的实施对企业来说都是一场变革，必然会改变资源和利益在部门与部门、个人与个人间的分配，因此，不具备支持变革的人文环境的企业，少有变革成功的。
要为企业变革打造坚实的基础，企业领导人自身必须有变革的理念，并积极地采取行动。实际上，绝大部分项目中，相关人员的"心理准备"或"文化准备"时间要远远超过项目的实施时间。

    最后，盛凯在执行层面上存在力度不够的问题。我们不难看出，盛凯公司在这个项目上的执行不到位。事实上，这个问题和前面两个问题息息相关，试想，公司高层在战略上对该项目没有足够的重视，对项目的方向又没有做到心中有数，执行力度从何谈起呢？
解决这个问题的办法关键在于建立起一支具备相关技能或经验的员工队伍。光明乳业针对这种问题的办法就是采用"A、B"制。即针对每一块业务或项目，除了落实项目（业务）经理之外，我们同时还会寻找两个"B角"，一位是项目副经理或主管，另一位是一个有专业基础、好学上进的年轻人，一旦项目主要负责人不能适应公司变革需要，我们有相应的人员梯队来替代他。所以，我们的项目一般不会受制于某个人的专业水平或变革心态。

max 发表于 2004-12-28 6:28 PM   

我觉得是好经典的项目管理例子

bruise lee 发表于 2004-12-28 8:29 PM   

简单一句话，公司给搂主交了学费 :-)

2001年10月8日的分工安排显然是照套经验，不过还不是致命
2001年11月7日的失误并不是没有听夏飞的建议，而是作为PM自身定位不当，潜意识中的“需求让夏飞负责需求”形成了实际风险分析工作中的盲点
之后就不知道在干什么了，太公分猪肉形式的开发分工？亲自披挂开发？

8卦一下：
如果2002年10月接下来项目结果是壮士断腕，那么楼主现在可能已经是一个很专业的职业经理人；如果是力挽狂澜，那么楼主可能已经在创业途中；不知道是否如此？

kekebird 发表于 2004-12-29 9:08 AM   

故事还没讲完阿，不过感觉这个项目最终应该是挂了，“因为我们无法控制盛凯内部的问题”。

jine 发表于 2004-12-29 10:24 AM   

y一个很好的项目管理例子

Lee 发表于 2004-12-29 1:28 PM   

深感项目实施的困难。
但也觉得奇怪，前期做需求分析的时候，不是应该大家确认签订一份合同的吗？然后根据合同来做就是了，怎么会弄得这么被动，人家说什么就改什么。

tan 发表于 2004-12-29 2:28 PM   

晕..中国的这种开发方式太多了..
需求变化变成了无底洞.......你怎么去改啊..

我说我说 发表于 2004-12-29 2:53 PM   

如果考虑到公司形象，该做下去；否则，终止也也不可惜，
需求分析不到位，需求理解有问题，所有的后续开发都建立在虚幻的基础上，就是把工程师累死，也解决不了问题。
如果是我，将派几个人，到香港进行业务实习，透彻理解业务模型，派公关直接做老总的工作，该项目还有救；

marcline 发表于 2004-12-29 3:04 PM   

在内部：客观上没有得到充分的授权，主观上没有有效地发挥控制力必须牢牢地把握项目组每个成员的活动

p.s. 很羡慕楼主能遇到这么大的项目，如果是我处于2004-10-29
的状态，我仍然会牢牢抓住并继续解决问题

p.s.2. 在出现这种状态的时候，就出现了分权甚至夺权的机会了

Henter 发表于 2004-12-29 4:10 PM   

全是没有深入沟通惹的祸! 导致方向性的错误!

既然原来是想在AHS的基础的小改来实现!那为什么不把AHS的现在功能演示给客户看,让他们有一感性的认识!再去了解用户的反馈! 最终提出方案,用户书面确认! 需求再变大家也好确定负责!


客户方面没有一个权威的项目跟进负责人,无形中扩大了双方间的鸿沟!(人际关系处理也是项目管理的中重要组成!)

luckywzy 发表于 2004-12-29 4:11 PM   

全是没有深入沟通惹的祸! 导致方向性的错误!

既然原来是想在AHS的基础的小改来实现!那为什么不把AHS的现在功能演示给客户看,让他们有一感性的认识!再去了解用户的反馈! 最终提出方案,用户书面确认! 需求再变大家也好确定负责!


客户方面没有一个权威的项目跟进负责人,无形中扩大了双方间的鸿沟!(人际关系处理也是项目管理的中重要组成!)

Xsara 发表于 2004-12-30 8:37 AM   

项目开始前要实现的功能还是没有让对方明确下来，以致后来出来的那么多的改动
进行中如何多沟通可能也会更好。

inethax 发表于 2004-12-30 1:05 PM   

这样的情况现实中非常多，往往是其中一方做出妥协，结束这种无休止的争执。双方的沟通应该频繁的发生在做项目需求的时候，当然很多时候这是不现实的，毕竟这里面人为的因素占着很高的比重。如何控制这样的项目状况我一直在思考，可我本身的能力却让我拿不出很好的解决方案出来。呵呵，文章文采很好，吸引我一口气读完，我到很想知道这个项目的最终结果是什么样子的。不过还是不要写出来的好，给人留下想象的空间。
一个完整的故事或许给人一些启迪，但是没有结尾的故事更能引发人的思考。

Simon 发表于 2004-12-30 3:05 PM   

我感觉与项目经理过于乐观有关，先后经历了4月，7月，10月三次大改，项目经理没有把握住7月份与港方第二次沟通机会，给人感觉全然没有项目风险及成本意识，合同要求9月份结束，7月份的二次修改应该已经列出了时间表，为什么到10月底才意识到面临违约赔偿呢？项目需求本来就是一个相互妥协的过程，几次面对如此大的范围调整，为什么一直不见北京市场部门的攻关呢？

Simon 发表于 2004-12-30 4:14 PM   

有人问：项目进度，成本，质量，三者如果硬要比较谁更重要，有人说是质量，“没法保证质量其它还谈什么?”；有人说是成本，因为它直接跟项目最终利润相关；有人说是进度，“成本，质量问题往往是进度没有保证所引起的”。我赞成是进度。

li 发表于 2004-12-30 4:22 PM   

一开始需求分析阶段就没有沟通好,导致后来恶果,这是一个典型项目管理失败的教训!

小强 发表于 2004-12-31 9:59 AM   

我完整的看了这个项目的日记；真是好经典阿！^_^
在这个项目中从一开始我就发现了好多违反项目管理规则的操作手法，例如项目流程没有确定，没有现场客户，项目发起的初衷不正确等等，但是我感觉最主要的是客户的关系没有高定，这才是这个项目致命的地方，应该由盛凯公司的一把手发起这个项目，然后对各个部门的领导进行下派领导，等等的客户关系都应该理清楚的。

--- 发表于 2004-12-31 2:07 PM   

系统运行错误信息----致命问题列表:

1. 甲方没有项目负责人(真正对项目负责的人)

2. 合同中没有项目阶段性进度及成果, 也没有阶段失败处理(早期中止合同). 就象写程序没有例外处理.

3. 乙方不知道自己的分量, 也不管水深浅, 投机心理太重

wxj_lake 发表于 2004-12-31 2:08 PM   

转贴的就应该注明啊，另外麻烦把原有的专家评注也贴上吧？

xdh666 发表于 2005-01-03 11:34 AM   

项目进展的不顺的关键在于沟通不够---项目核心人物程万科的不配合最终导致的项目的失败

勇敢的心 发表于 2005-01-03 2:24 PM   

这么重要的任务
初战应自临阵
一路居然不是一直走向成功
而是一步步发现更多的问题
走向崩溃......
失败就是失败
搂主也许不是失败的关键因素，且承担主要责任
可惜一个好的人才....

左直拳 发表于 2005-01-03 3:11 PM   

到最后还画决策树，真有点赵括重生，马稷再世的感觉。整篇文章，都在夸耀着这个总裁，那个经理，什么部门，什么师。靠，大公司，大话欺人耳。

川杨河 发表于 2005-01-03 10:05 PM   

一将无能，累死三军啊。
多年以前我也跟着楼主这样的项目经理干过，大伙干得累死累活，最后项目仍旧死去。
作为一个技术管理人员，绝不可以意气用事，随时做好最坏的准备。从这句“盛凯要什么功能，我们就上什么功能”我就觉得接下去作者要么骗人，要么项目陷入泥团。所幸楼主是个老实人。

nopattern 发表于 2005-01-04 8:53 AM   

应当有甲方负责人 签字确认 的 需求，否则开发就是无底洞 。项目经理的责任是确保项目完成，而不是使客户满意 。

黄淼 发表于 2005-01-04 9:02 AM   

主要的问题，还是出在项目需求分析上，在处理客户的需求方面很乱。刚开始就是用自己相当然的方式处理，后来遇到困难，就完全按客户的想法进行。还有就是，业务流程，不是哪个人的事情，应该是整个团队的问题。我感觉，项目开始启动，你们项目小组的精英应该和客户的决策层和各个使用部门，深入沟通，了解他们的需求，开发过程中，还应该和客户不断沟通。

flymeng 发表于 2005-01-04 9:45 AM   

我认为楼主做为项目经理在项目的重要环节上出现了问题就是需求，你没有想办法让你们的相关人员充分了解用户的需求就开始项目开发，开发完了之后客户提出的问题需要修改程序，这本身对这个项目就是很大的危害。
我建议的方式是首先，用一个月到两个月的时间做充分的需求调研，不能一起开会讨论的就找相关的个人去讨论，最后需要相关人员签字确认，即使不能签字的，也要在大会上指出个人的不同需求。其次，项目成功实现的关键就是基本符合用户各方面的需求，为了基本符合用户需求我建议楼主可以先用较短的时间做一个demo版，让客户对着demo版提出问题，不断的改，这样改对最终程序不会有影响，最终demo版由用户确认之后呈报给用户的主管领导或大领导过目，没有问题后最后一步就是根据demo程序写程序，这样一般不会失败。

Hank 发表于 2005-01-04 10:22 AM   

1、典型的技术出身的项目经理的做法
2、典型的中国式项目的做法
3、“盛凯要什么功能，我们就上什么功能”这一句话就决定拉项目的失败

缘木求鱼 发表于 2005-01-04 10:45 AM   

一个非常经典的例子，也是一个最寻常的错误。。。。
很多软件开发就是这样的，客户的要求一改再改，其实很多时候客户是不能很好的表达自己的需求，知道自己想要什么，但是就说不出来，所以更多的时候需要公司的系统分析人员，深入客户内部，多一点了解，多一点沟通，一个项目的开发应该花70％的时间用在和客户沟通，做需求，做测试上面。作为一个职业经理就更应该明确的分析如果分配之间，如何更好的完成质量！

过客 发表于 2005-01-05 1:49 PM   

http://blog.blogchina.com/article_12646.327325.html
上面有专家点评

masathem 发表于 2005-01-05 4:12 PM   

沟通出了大问题，一个劲地以为自己是对的，不了解客户的现系统和企业文化，贸然开发了几个月。

softzz 发表于 2005-01-06 7:31 PM   

程序员同志们,你们看,"管理"也不是很好干呀.

与程序相伴的是劳累的一生??????????????????????

阿呆 发表于 2005-01-07 8:19 PM   

经典的失败案例，学到不少。

罗小虎 发表于 2005-01-14 11:04 AM   

既然是这样，你们再碰到这样的客户时，应修改的合同的游戏规则，变成以服务收费模式，而不是以产品收费模式，客户先列出他需要的服务，你们按年来收取服务费，而软件开发是免费的。

流浪熊 发表于 2005-01-17 3:26 PM   

我曾经做个一个这样的项目，简直和楼主的如出一辙啊，过后，我分析自己的原因，我觉得有几点是我们需要注意的：
1.需求分析
虽然我们反复强调需求，需求，但还是有太多的项目经理对需求的重要性理解不够，以为通过一个简单的文档，或者是通过表面的讨论就把

需求理解透了，这就大错特错了，我们都知道学习是个循序渐进的过程，我们在理解对方需求的过程就是向对方学习的过程，这是个延续性的

东东，不可能一步到位的，通过楼主的文章我们可以发现，他们开始启动项目的主要依据就是夏飞的文档，由于夏飞是按自己的想法写的，并

没有真正理解用户的需求，闭门造车是肯定的了。
解决的办法就是增加在理解对方需求方面的投入，一定要派专人到对方现场了解对方实际的需求，而且要求对方派专人协助需求分析的进行

，并且需要让对方理解，项目只有通过双方的共同努力才可以成功。
楼主的项目在开发的过程中，严重缺乏和对方的沟通，造成作出来的东西不符合用户的需求。
2.领导的重视程度
以上提到了，只有双方合作才能使项目成功，对于大多数企业来说，企业人员都有一种抵触情绪，人们懒的和你说业务的流程，或者即使说

也是很简单的，或者片面的。所以，这就需要我们的业务人员来通过某种方式让领导重视，让领导理解企业的信息化不是一个人，几个人的事

情，而是全公司的一件大事，让领导派专门的人员协助你和各个部门进行沟通，必要的时候需要使用行政的手段强迫对方部门配合。
3.和对方的部门人员的关系
由于在项目的开发实施过程中需要对方各部门人员的配合，和对方人员搞好关系就成了很关键的事情，关系搞好了，什么都顺利，搞不好，

处处受抵制。当然了，搞好关系的方式需要我们各显神通。

其实我觉得作为一个项目经理，主要的工作是负责疏通各方的关系，包括自己公司的，和对方公司的关系，楼主显然是没有这方面的经验，导

致项目的失败。

chiesa 发表于 2005-01-18 12:58 PM   

如lee所言，如果软件合同的签订不把需求分析作为附件，基本就是等死了。

郑昀 发表于 2005-01-18 5:16 PM   

Ping Back来自：blog.csdn.net

yun.zheng 发表于 2005-01-18 6:03 PM   

都在说这个PM缺少经验，但是谁又能拍着胸脯说：我料事如神，我能动用公司全部资源，我能搞定对方关键人物？
知易行难啊！

wj7907 发表于 2005-01-20 8:05 PM   

流浪熊
我曾经做个一个这样的项目，简直和楼主的如出一辙啊，过后，我分析自己的原因，我觉得有几点是我们需要注意的：
1.需求分析
虽然我们反复强调需求，需求，但还是有太多的项目经理对需求的重要性理解不够，以为通过一个简单的文档，或者是通过表面的讨论就把

需求理解透了，这就大错特错了，我们都知道学习是个循序渐进的过程，我们在理解对方需求的过程就是向对方学习的过程，这是个延续性的

东东，不可能一步到位的，通过楼主的文章我们可以发现，他们开始启动项目的主要依据就是夏飞的文档，由于夏飞是按自己的想法写的，并

没有真正理解用户的需求，闭门造车是肯定的了。
解决的办法就是增加在理解对方需求方面的投入，一定要派专人到对方现场了解对方实际的需求，而且要求对方派专人协助需求分析的进行

，并且需要让对方理解，项目只有通过双方的共同努力才可以成功。
楼主的项目在开发的过程中，严重缺乏和对方的沟通，造成作出来的东西不符合用户的需求。
-----------------------------------------------------------------------
同意这位！对需求的分析和掌握是一个持续的过程，这个项目从一开始就就知道离客户需求差得比较远，但三次大的改动都是在项目已经严重偏离客户需求较远的情况下进行的？！如果要把这个项目的开发过程划条线，那是这样一条线：
/
// /
/ / / //
/ //
/
而不是：
/
......
///
/

安讯项目组在项目双方沟通上不够积极主动，与客户关系处理上明显存在问题！

xindayu 发表于 2005-01-21 6:23 PM   

客户方和供应商对要供应的产品都有自己的理解,双方在接洽时把各自的理解用相同相近的目前流行的概念语言表达出来,互相认可,这对初期意向性的洽谈是一个成功的结果,但接下来的商务谈判中关于产品的详细描述,双方必须形成一个写有准确的需求与技术实现的文件,以次为蓝本才能确保下一步的成功,这一阶段工作必须按步骤进行.
a.客户方必需组成由主要决策者领导,抽调相关业务负责人的项目小组(客户方作出开发软件的决定,他首先应该清楚这是对自己企业的一次变革很有可能是一个大变革,这样的变革只能由他领导来完成,有了这样的战略意识,才能决定他的软件开发与应用会成功;其次他应明白企业开发软件,主角是企业,软件供应商只是提供按明确需求产生的考虑客户方情况的与客户方共同研制的科学实现模式,及由此模式生产的软件产品;因此他要作好变革的准备与安排,形成目标明确的新生产模式,至于模式的具体样子将软件商辅助他共同研制),只有一个行之有效的项目小组对客户方和软件企业自己才是成功的前提.
b.我方要组成包括商务人员和技术人员的项目组,商务人员要准确把握客户方提供和未提供出的资源,并和技术人员一起作出项目可行的评估.得到客户资源就要取得配合,这在对方内部将要变革的氛围下是不容易的,思想沟通和抵触的情绪,是项目组每个人员面对的困难;在对方现有的业务工作中整理出一个业务模式,与客户共同研究,生成一个节约客户资源,提高产效的软件新模式,也就是得到明确的需求,是项目组本阶段的工作目标(软件企业自己必需明白是在为客户开发一个软件系统,这个软件为解决客户企业的问题而产生,要应用到企业,我们只有真正知道了问题才能开发,开发了要能应用才是工作完成,这个成功的结果是由一步步的阶段工作连续完成的,整个项目要进行评测,每一步工作也要进行评测(工作成果的评测,商业利益的评测都要进行),有时还会在两种评测中取舍;不评测,不控制,不领导是没有结果的).
c.双方两个项目组都有共同的目标,但如何实现目标呢,我们作为软件商该怎样让对方支持我们,协助我们,而不是他们高高兴兴签完合同,然后就静候佳音,不在认为还有什么工作能做,就等我们变出一个好用的东西来;因此现在我们要考虑软件开发的真正主角是谁了,因此,只要我们决定做了,就不要指望人家主动,要主动的是我们,我们就是主角,接下来的事情就是策划,发动一场作交易的战争.

江松霖 发表于 2005-01-28 9:32 AM   

方案成功不只是签合同，对甲方的需求分析非常重要，绝不能人家要什么我们给什么。没有法律保障！还有，整个项目好像只有一两个人去跑，其他方面部门信息沟通不足，每次都是要循序渐进，摸石头过河，最后才进行仔细分析，那已经是总结性的了。整个项目都在甲方的牵制下，被动！
对于项目的价值和意义分析不足。

henry liu 发表于 2005-01-28 4:55 PM   

需求都没搞清就签啊。

aaa 发表于 2005-01-28 4:58 PM   

合同是按需求签的，设计是评审过的，如果开发出的东西符合需求，为什么还要赔款？我觉得应该向客户索赔。

不懂瞎说 发表于 2005-01-29 1:50 PM   

客户好像总是在扯皮。
项目经理不是救火队员，很多时候需要冷静的思考，有时候需要破釜沉舟。
我遇到的问题跟你不太像：
需求很多时候不一定是来自客户，还有很多是来自领导的指使。
建议将项目改做产品走，一是挽回更多的损失，二是请业务专家执行标准流程，使自己能跟客户进行辩论。

老卒 发表于 2005-01-31 2:54 PM   

客户都不配合?
那还搞个什么劲啊, 是不是为了回扣啊?

hawkswill 发表于 2005-02-01 5:52 PM   

有点象小说。
不过项目的确如此。
需求经过客户签字认可了吗？如果认可了，新的要求可就是change request了，费用工期需要重新计算

huma123 发表于 2005-02-04 5:33 PM   

关键就在需求，肯定要调研的，并且组织甲方的项目组以及甲方的公司高层来论证这个调研报告，大家有一说一；论证会开完了，甲方就知道我们要做的是什么东西，做完后会是什么样子，而且甲方也可以在论证会上再提出或弥补前期调研的不足，这样就保证我们做出的东西是他们要的，即使有些偏差我们也不会走到“赔款”的地步，因为这些都是事先和甲方的项目组研讨过的，千万不能说“客户要什么，我们就给什么”。

岩岩猫 发表于 2005-02-16 10:32 AM   

这样的一个项目做下来很不容易，失败的原因在于过程没有控制好，其实作为项目管理来说，成本，质量，进度的控制在项目管理的不同阶段是有不同的侧重点的，项目是战略的目标，在管理过程中需要的是战术，这种问题在与政府部门的项目常会碰到。如何管理好一个项目需要去冷静的思考，还要顶得住压力。

左右手 发表于 2005-02-22 9:40 AM   

以前做产品做习惯了的项目经理来做办公软件必然会出现的问题！

左右手 发表于 2005-02-22 9:41 AM   

以前做产品做习惯了的项目经理来做办公软件必然会出现的问题！