项目管理经典案例.docx
《项目管理经典案例.docx》由会员分享，可在线阅读，更多相关《项目管理经典案例.docx（17页珍藏版）》请在冰点文库上搜索。
项目管理经典案例
一个项目经理的困难选择
张炎正在打电话的时候，他的秘书拿进来一封总部抄送的来自德勤公司的信.张炎是益达公司的项目经理，这两年一直在负责公司在海外的项目开发业务.而此刻这封信正是关于张炎所负责的一个香港的项目。
由于益达是在NASDAQ上市的公司，每个季度的财务报表要经过德勤公司的严格审计.益达核算项目收入的方式是采用完工百分比法,即随着项目的时间进度,按比例将合同款记入公司收入。
这个项目2003年9月合同签订之日起，到2004年11月，历时1年多,合同款的80％也已经记入公司收入,而客户实际上的现金支付只有合同款的30%。
2004年12月德勤在对公司的审计中发现了这一问题，于是便寄来这封信,要求公司给予说明。
财务部给出的建议是：
请德勤向客户公司发欠款确认书，以此证明益达没有虚假账面收入。
但是客户公司会签署这份确认书吗？
张炎实在是没有把握。
益达公司和AHZ软件
益达公司成立于1992年，伴随着中国电信和因特网事业一路成长发展.其中AHZ软件是益达的核心产品，在国内为中国电信、中国移动等多家大型运营商提供对用户的管理和计费功能.
2003年香港凯业公司对益达的AHZ计费系统表示了兴趣，而益达的董事会也把这次合作看作步入海外市场的重要机遇.凯业成立于1994年，是香港首批获得允许为公众提供互联网服务的电信服务提供商之一,其主要投资方来自于日本.
2003年9月，益达公司和凯业公司签署了用户管理和计费软件开发合同，合同金额为695,000美元。
在这次项目中，益达将以AHZ产品为基础，结合凯业的业务需要，进行客户化和二次开发工作。
对益达来说，这是公司第一个海外项目，标志益达业务步入了国际市场，这一消息使益达在NASDAQ的股票价格因此上涨。
对凯业来说，购买益达的用户管理和计费软件AHZ能使他们的业务得到有效的扩展，因原计费系统AS400不能支持而不得不采用手工完成的部分计费功能将在AHZ系统中得到实现。
项目启动
为使项目顺利进行，凯业和益达均为此项目配备了相应的管理和技术人员。
凯业公司方面的项目成员包括，总负责人古田二科（由凯业日本投资方指派），IT部门经理周远，项目协调人孙文元，以及项目所涉及的三个业务部门的经理.益达方面为凯业的项目成立了专门的开发组,包括了三个部门：
产品市场部由姚辰负责，产品售后服务部由蓝辉负责，张炎被指派为负责整个项目的经理，同时他也直接领导产品开发部。
分歧，浮出水面
按照公司的分工机制，首先由产品市场部门完成用户需求调研，形成《用户需求定义书》（SCOPEOFWORK，之后简称SOW），再转移给产品开发部设计，最后由售后服务部完成软件安装和调试后就可以将项目结束了.
2003年10月8日，姚辰带着两位高级软件设计师去了香港,和凯业讨论SOW的编写。
即按照AHZ软件的模块划分，解释AHZ目前存在的功能,并根据凯业的需求，把两者相比较后确定需新增加的功能。
张炎本以为姚辰这次去香港讨论SOW不会有什么大问题，但是事实证明他过于乐观了。
姚辰从香港回来后，向张炎汇报了一个当初根本没有想到的问题。
原来姚辰他们在与凯业进行SOW编写工作研讨时发现，凯业对新系统的期望远远超出了AHZ所能实现的功能。
AHZ是为电信运营商提供用户管理计费服务的软件,主要功能是对用户资料的受理和保存，用户使用网络资源的费用计算,以及统一用户账单的生成等；而凯业要求AHZ能够增加对公司内部业务流程的跟踪、反馈、管理以及对相关职能部门支持等功能.这就要求AHZ在现有的结构框架上进行较大的改动，而不是张炎原先设想的稍加修改了.姚辰还说,"如果我们不答应他们的要求，他们将终止合同"。
这种情况确实出乎张炎的意料之外。
凯业需要的实际上是一个办公软件系统，而非计费系统。
首战告捷
在公司研发总裁齐栋主持的项目会议上，张炎就姚辰与凯业讨论的结果做了说明，并特别指出凯业对新系统的期望和AHZ实现功能上的巨大差距。
但从这个项目各种意义的考虑出发，齐栋决定：
”只要合同能继续执行，凯业需要办公系统，我们就给他们开发一套办公软件系统。
”
2003年11月初,在产品市场部的姚辰和开发部的几位软件工程师的共同努力下,终于完成了一份长达174页的SOW,并传真给凯业公司。
这也是益达公司第一次将SOW做得如此详细。
姚辰提醒张炎,在SOW中还有几点定义得还不够具体。
但是张炎认为，SOW毕竟还是纸面上的东西，只要公司开发出来的软件凯业方面基本认可了，那些停留在纸面上的细节问题留在合同执行过程中再与他们慢慢商讨也行。
公司以前的项目基本上也是这样操作的.
说3种话的中国人
2004年3月，益达对项目前期的软件开发已经基本完成.应凯业的要求,益达在软件正式安装前与凯业进行了一次远程演示工作。
双方通过远程计算机共享和电话会议的方式进行演示，由益达主讲AHZ实现的功能,由凯业进行评论和提问.这也是双方第一次针对软件实现的具体情况进行的交流。
然而双方的沟通却变得出乎意料地困难和复杂.一场本来计划2个小时的会议竟然开了近6个小时。
益达认为系统基本都已具备凯业需要的功能,但凯业方面仍旧反复强调他们要的不是这些。
可是他们要的究竟是什么呢？
却也没人能完全说清楚.凯业负责IT支持的周远没有参加这次远程演示。
最糟糕的是，在凯业的项目组中，除了项目协调人孙文元会说普通话外,其他人只会讲粤语和英文.而益达这边的人英文都不好，粤语则基本听不懂,大家只有靠孙文元在粤语、英文和普通话之间来回地翻译。
一个下午下来双方都弄得疲惫不堪。
最后，大家只好先达成初步意见,让凯业的人员自己登陆AHZ熟悉系统，一周后再给出他们的反馈意见。
困难的局面
在上次和凯业的电话会议后,益达陆陆续续接到凯业各业务部门的反馈。
但是没想到这些反馈意见全是用英文写的.更要命的是，益达开发部的工程师们面对这些似是而非的提问，却不清楚问题具体出在了哪里，也不知道该如何修改。
不过张炎可以肯定的是，凯业提的问题，有相当一部分是属于对AHZ系统了解不深的缘故造成的。
张炎给周远发了几封Email，但一直没有收到他的回复。
打电话给他，他的回答也是支吾其词,可以看得出来，他对这个新系统，其实没有抱多大的热情。
张炎决定必须要和姚辰一起去香港，给凯业进行现场演示，加深他们对AHZ的认识和理解。
新的发现
张炎本来计划用两周的时间给凯业做演示，然而两天后他发现这项工作很难再往下进行。
刚开始，张炎打算将用户的思路引向AHZ实现的方式,力图告诉凯业:
AHZ系统是如何"变相”地实现了他们的业务功能。
但随着双方越来越深入的接触,张炎发现，他们的本质分歧不是某一个功能是否实现，而是实现的方式是否符合凯业的业务操作习惯.凯业要求他们的工作流程能够被一气呵成地在这个系统中实现.而在AHZ中，一个完整业务流程的操作，常常需要在几个界面或模块之间来回跳转，不是用户习惯的原来老系统的操作模式。
此外，双方对AHZ的看法也不一致。
由于AHZ最初作为一个计费软件，张炎认为其核心是计费的灵活、准确性，而没有过多考虑部门间工作流程的组织管理.然而孙文元却坚持认为，这就是系统必须要有的功能，他们执意要求益达按照他们的工作流程进行修改.
所以，在接下来的时间里，张炎和同伴们放弃了演示工作，索性完全去听凯业来讲他们的业务是什么样子的,他们的工作流程是怎样的。
这一次,张炎又收集回来许多SOW中没有详细说明的部分，这还是益达第一次面对凯业来了解他们的业务模式和具体的需要.张炎不禁想起姚辰去年11月份在将SOW移交给他时说的一番话。
"如果我们将SOW定义得再具体一些，就不会有这么多争执了,"张炎想到，”我们是应该更早一点来听听凯业的业务陈述。
"
令张炎感到奇怪的是，周远这两个星期来一直没露面。
向孙文元一打听，他竟然去休年假了。
"什么时候了还去度假,他存的到底是什么心？
"张炎忿忿不平地想。
重整旗鼓
张炎回到北京，根据新掌握的情况，又制定了为期2个月的二次开发计划，希望在5月底前完成AHZ的修改工作,争取6月底能在凯业上线。
在此阶段,开发和测试人员将重新修改实现方式，力求在界面操作流程上能符合凯业的使用习惯和工作流程。
在这期间，张炎收到了古田二科的几封Email，了解到周远对AHZ有很大的抵触情绪，因为他清楚AHZ上线的那一天，也就是他离开的那一天.现在古田二科也拿他没办法，不敢得罪他。
因为万一益达的AHZ不行,他们还需要用现有的计费系统，那么还得依靠他管理现有系统.张炎终于明白了周远先前为什么如此不合作.
二次开发工作终于按时完成.益达每位项目成员对更新后的AHZ系统都是信心百倍。
有了3月份在凯业为时两周的现场调研，项目组对凯业的业务模式已经基本了解清楚。
经过这两个月紧张的开发工作，张炎相信目前的AHZ系统应能全面满足凯业的要求。
2004年6月，益达项目小组包括参与每个模块设计的开发工程师，都来到香港，给凯业做第二次现场演示.如果有什么微小的问题，就当场修改，争取一鼓作气结束这个项目。
事实上这项目不能再拖了,按照合同益达要在6月底完成AHZ的安装使用.否则,公司就非常被动，甚至要面临支付违约赔偿的风险。
此改绵绵无尽期
然而张炎的想法被再一次证明是过于乐观了。
项目组在香港的一个多月里,将AHZ系统上线的计划一再搁浅。
最让张炎感到气恼的是,凯业在这个项目上始终是一个被动的合作态度，各种各样的问题层出不穷.上次提出了使用习惯和工作流程问题，这次又提出了多个部门之间的业务接口问题。
这并不全是益达的错.凯业内部在业务接口的定义和部门业务划分上自己也是争吵不休.凯业以前没有明确的制度将部门间的责任确定下来，现在AHZ系统要将部门责任明确下来，各部门于是便明争暗斗，争夺权利，推卸责任,千方百计地想扩大自己部门的地盘.这些情况张炎都已向古田二科反映过,但他始终也拿不出一个有效的方案.张炎觉得古田二科是个没有组织和控制能力的人，就连他的领导权威性，也没有得到部门经理的尊重。
凯业项目组从一开始对系统就抱有一种漫不经心的态度，很大程度上也是由于古田二科没有把压力和责任传递给相关部门的经理和员工。
张炎把这些情况向北京总部做了一个完整的汇报，齐总指示说，既然凯业不肯妥协，那么全体项目组成员就先回来，根据这次收集到的问题再进行一次完善的开发工作。
致命一击
两周后，张炎再次来到香港给凯业进行第三次现场演示.虽说这次要比前二次顺利，至少凯业对系统提出的一些问题都基本上得到解决，但是在诸多细节上,凯业又提出以前没有提到过的要求，比如系统要能够给市场营销部提供更强大的支持功能。
此外,前两次一直没参与益达演示的周远也第一次露面了.在和他的讨论中，张炎突然意外地发现AHZ系统存在一个重大的缺陷。
虽然益达对此有不可推卸的责任，但是如果周远能够早一点积极与益达合作,就不会直到现在才发现这个问题.张炎突然有一种泥足深陷的感觉。
最后通牒
2004年10月，益达收到了由凯业总裁陈维贤签发的紧急传真。
客套的话语难以掩藏他对该项目的失望情绪,并且他还提出了三个问题：
第一个问题是"直至今日合同仍未履行完毕,延期的损失如何处理”；第二个问题是"今后的实施费由谁支付"；最后一个问题则是继续履行合同的时间安排,如果益达不能给出明确的时间承诺的话，他就建议益达及早放弃这个项目.如果现在中止项目，益达的赔偿金将会低于合同规定的额度，否则他们将会要求益达严格执行合同的赔偿条款。
陈维贤的”中止项目"建议虽然张炎一时无法接受，但确实提醒了张炎。
公司到底还要不要把这个项目继续下去？
继续前进还是撤退，这也许是现在最迫切需要回答的问题。
公司已为凯业项目花费了85％的合同金额,即使这项目成功地做下来，也已经无利可图;公司有很多新项目需要完成，但正因为凯业项目的牵制而不能够正常开展;最重要的是，该项目什么时候能够结束，谁也没底，一些软件工程师甚至对这个项目丧失了信心,就连齐总也开始觉得这个项目是个泥潭，希望益达能从中抽身出来。
但是如果中止了这个项目,公司投入的资源就变成了沉没成本，这是一笔很大的数字啊！
现在的AHZ系统是为凯业度身定制的，对其他公司是没有利用价值的。
并且，益达还要面对凯业的赔偿条款。
又是秋雨时节，在二十二层高楼上俯看落雨的长街，张炎觉得很冷,真的很冷。
本案例由中欧国际工商学院案例研究员陈峻松博士撰写，目的是用来做课堂讨论的题材而非说明案例所述公司管理是否有效。
为保密需要，某些名称及信息已经过调整.版权2005，中欧国际工商学院。
未经中欧国际工商学院授权，禁止以任何形式对此案例的任何部分进行复制、转载、修改、发布或存储于任何检索系统中。
益达的困难：
不仅仅是项目管理
文/楼晓寒
我们先来看这样一个故事:
一个水果小贩，接到了隔壁大楼里某公司的一单大生意：
为这个公司提供500公斤水果，作为这个公司员工的中秋节慰问品。
小贩很高兴，根据当时的水果市场行情，建议买今年刚刚上市的香梨。
公司的办公室主任也同意了。
等水果送到公司，员工们却有了意见：
香梨的个头小，没有传统的鸭梨好看;长相也不饱满，颜色有青有黄，不知道是否熟了.还有人说，分水果，分水果，现在是分梨了，是否意味着员工要和公司”分离”啊。
最后,尴尬的办公室主任只能要求小贩换成苹果。
小贩原本希望能赚一笔，最后却几乎赔了进去。
故事中的小贩和案例中的益达公司处境非常类似：
由于对客户的需求了解不清楚,在合同执行中不断变更交付内容，最终让自己付出了高昂的代价，而得到了一个谁都不满意的结果。
那么，在益达这个案例中,我们需要注意到什么呢?
谁是客户?
这个问题看似很肤浅，当然是凯业公司.但是，如果我们更加深入一层，哪个部门是这个项目的所有者？
哪些部门是项目的参与者?
谁能帮助益达了解凯业公司内部的需求?
在许多企业内，为了加强内部约束，合同签订者与最终用户往往是分开的。
对于供应方来说,除了设法签订合同外，还需要想办法了解清楚,最终用户对于合同标的物的要求。
否则,合同上标明的是买”水果"，最后客户要求的可能是"蔬菜”。
在这个项目中，益达公司就忽略了这点,从而在后面一步步陷入被动.
如果项目真的像买水果那样简单，供应方应该能比较容易了解清楚采购方的最终用户是谁。
但是,由于合同标的物是开发软件，而软件的功能、稳定性、可扩展性、界面友好等，都不容易通过简单的描述说清楚。
特别是在软件最终使用者与合同签订者及IT部门分离的情况下，对供应商的第一个挑战就是：
你的客户到底是谁？
如果简单地把采购部门作为客户,这样的项目必然会失败。
而认为买方多个部门的作用是平行的，也会产生偏差.一般来说，销售部门在合同商务条款基本确定时，就应该将己方的设计、工程服务等部门介绍进来，与对方的最终用户和技术支持部门接触，尽早定义清楚合同要求、范围、进度以及真正的关注点在什么地方等。
这样的参与，所付出的成本，会远远小于因为不了解客户是谁而产生错误的代价.
另外，对客户的认知，也有助于减少项目成功的阻碍。
通过人与人之间的沟通，让客户感受到获得了尊重，能让项目发展得到无形的收益,反之则让项目受损。
益达一开始对IT部门的忽略，使IT部门成为合同执行的一个很大障碍.
客户到底需要什么？
诚如公司名字，益达公司作为一个快速成长的软件公司,在中国大陆市场获得了良好的收益。
而且，或许是出于对产品和开发能力的信心,对避免国内市场价格战的预期，管理层对于拓展市场有着很强的欲望.凯业公司的需求，正好给了益达一个机会。
第一个海外合同能达到近六百万元人民币的金额，是相当吸引人的。
股票市场也给予了良好的反应。
也许这样的成功，让益达公司在不清楚客户是谁的情况下,一开始也不愿意去了解客户的真正需求是什么。
甚至在前期遇到了困难,益达的项目开发团队仍然没有去做应该做的事情：
需求分析。
一个项目，应该是有了客户需求分析，然后进行客户现状调查，然后是需求－现状差异分析和开发能力－需求匹配差异分析,最后再决定是否开发和如何开发。
在许多公司眼里,这样的分析不会产生效益,是浪费时间。
但是，只有在合适的分析基础上，才能完成后期的项目进度安排和资源调配计划，以及可能的成本收益预估。
益达的问题，都是出在需求分析不清楚的情况下。
另外一个方面,对于客户的要求，也要有一个合理的答复。
这个答复，并不是说,客户要求什么就能做到什么，而是有一个合理的建议。
例如，买水果真的买成蔬菜，或许还可以解决；而如果客户最后要的是一个果园，或许就应该建议客户去其他地方.在许多项目中,开发团队也许无法采取中止开发的办法,因此，项目经理更加要有技能,对客户的要求进行分析和答复，让客户的要求在合同的规定范围内发展，而不会超出。
在对用户新的需求进行合理回复的同时，项目经理还需要做的，就是判断这样的变化，能通过怎样的途径满足，是否在现有的成本范围内，或者要增加多少成本等.如果成本超出自己能管理的范围，就需要升级向上汇报。
一个项目管理有效的公司，往往会采用各种工具,例如用不同的颜色，来标明项目的安全,成本，进度等是否在可控制范围内，并由相应级别的管理人员进行决策。
如何与客户沟通？
沟通是我们常用的一个词，也是我们经常犯错误的地方。
沟通的方式、沟通的对象、沟通的内容等等，都是我们需要时刻注意和调整的。
在这个案例中，益达并没有在沟通上下功夫,也就不断地在沟通上付出高昂的成本.例如，在一个跨语言、跨文化的项目团队中,益达并没有配备具有相应语言能力的人员。
这些看似小问题，实际上却给项目带来不必要的损失。
我们平时经常能遇到的另外一个沟通问题是沟通频率。
过度与客户沟通，会让客户觉得很烦，也显得项目团队没有信心和项目开发能力；而缺乏沟通,会让客户的需求没有机会表露.沟通应该是在有计划的基础上灵活调整,这个对于整个项目团队都是一个挑战。
因为沟通并不是项目经理一个人的工作，而是整个团队的。
希望让所有人都能进行流利的沟通是不现实的，但是，让每个人能有效地沟通,是一个项目经理应该具备的能力。
在目前许多公司的运作模式中，售前队伍与售后队伍是分开的，售前人员围绕着客户转，售后人员围绕着产品转。
但是，在产品的客户化开发程度大的销售项目中，如果还是采用这样的模式，就会出现因为缺乏对客户真正目的的了解而导致项目越做越艰难的情况。
好的项目管理，不是在过程中进行控制，而是从一开始就要明确:
客户要的到底是什么?
针对益达这样的问题,在工作中常用的一种解决办法是，售后队伍的提前介入.在合同签订前，让售后队伍对于协议中的技术条款进行评估，甚至与客户方的技术人员进行交流，了解产品与客户要求之间的差距,来确定合同签订后，如何组织项目管理。
另外一种办法就是由销售队伍直接对项目交付负责，避免销售队伍为了单纯提高销售额而胡乱承诺,也可减少部门之间沟通的成本和可能的信息丢失.
项目管理的好坏，更多的功夫要花在项目开始前。
套用一句广告词：
”千万不要输在起跑线上"。
本文作者为中欧MBA04级学员、IBM全球商业服务（中国）有限公司高级顾问
学会放弃,方有所得
文/王泉庚
这是一个非常经典的企业实施IT项目的案例，不论是软件公司碰到的问题还是客户公司碰到的问题在现实中都非常普遍.项目的失败是由软件公司和企业客户双方所造成的，而项目失败的原因也基本能从本案例中找到。
因此，讨论本案例有着非常普遍的现实意义和借鉴意义.
错在多得
什么都想得到的心态，必将为项目的失败埋下隐患。
现在的软件市场，分分合合、起起伏伏。
在软件公司里，上到管理层，下到销售员，满脑子都是如何完成销售指标，如何提高市场占有率，如何快速提高市盈率,这是头等大事.于是，只要有机会，什么客户都接，什么单子都做，客户的什么需求都可以满足,当然也有公司只卖产品，客户的什么需求都不满足的。
案例中的益达公司，本来有自己的成熟产品AHZ计费软件，但为了步入海外市场，为了国际化声誉，为了提高NASDAQ股票价格,在不了解海外市场，也没有各种技能准备的情况下，就接了凯业公司的软件定单。
益达公司做的是以用户管理和计费领域为核心业务的软件，但是为了不失去合同，最后连OA系统也做了，而看一下凯业公司最后的功能需求，都已快发展成ERP软件了.
而企业客户亦是如此。
竞争激烈，不进则退，行业整合，纵横捭阖.安装或更换IT软件系统，有些是为了迅猛扩张企业规模，全面整合企业业务，解决历史所有遗留问题；也有些是为了追赶社会潮流，人家都ERP了，我们再不上就落后了。
于是一哄而上，企业所有部门都同时上软件，要一步到位，一劳永逸，彻底解决。
案例中的凯业公司,从初上一个计费软件,上升到对公司内部业务流程的跟踪、反馈、管理以及对相关职能部门支持等功能,实际上已上升到一个办公软件系统。
当软件功能按要求实现后,凯业公司又要求他们的工作流程能够被一气呵成地在这个系统中实现，完全满足员工以往的工作习惯。
当解决了使用习惯和工作流程问题后，又提出了多个部门之间的业务接口问题。
当提出的一些问题基本上都得到解决后，在诸多细节上，凯业公司又提出以前没有提到过的要求，比如系统要能够给市场营销部提供更强大的支持功能等等。
这已经是ERP软件的要求了。
正是益达和凯业公司什么都想要，导致了系统永远在建设、修改、重建中，永远没有应用的时候。
修改绵绵无期,项目陷入泥潭.
败在前期
前期的准备工作，已经决定了项目成败的80%因素.
在项目前期准备工作中，甚至是在合同签署之前，一定要做好以下几个方面的工作：
首先是，合作双方要有充分的沟通.软件企业要认真听取和了解客户的总体需求及具体业务需求，同时也要让客户充分了解你的产品功能及支持能力。
还需要与客户沟通，在项目实施策略上达成初步共识。
通过软件公司大量的实践经验及与客户的沟通，根据每个客户企业的特点定制一套实施策略与实施步骤。
而案例中的益达公司并没有这么做,益达不了解凯业的真实需求，直到项目实施的中后期才真正清楚凯业公司想要什么。
同时凯业公司也根本不了解益达公司AHZ软件的具体详细功能，项目实施后才发现AHZ软件根本就不适合自己的需要。
其次是，合作双方都要定位清楚、有一个初步规划。
作为软件企业一定要有一个定位，你的客户是谁?
你的竞争对手是谁？
你的产品相对优势集中哪里?
应该满足客户的那些需求？
作为客户企业也要有一个业务规划，企业的战略要比较清楚，业务流程也要基本理顺，IT战略如何支持业务战略也要清晰。
案例中的益达公司从一个电信行业的计费系统做到OA系统，甚至涉足了ERP领域，就是定位不清的表现。
而凯业公司连自己要什么也不清楚，业务部门之间的流程混乱，也没有明确的制度将部门间的责任确定下来，IT功能一变再变，IT战略更是不知所云，如此境况，项目自然遥遥无期。
再次是，双方都为你的项目启动准备好了吗？
软件公司在扩大业务规模或拓展新业务时,甚至接到每一个新项目时，在人员、技能、资金、项目管理等各方面都准备好了吗？
企业客户在启动新项目时，业务需求清楚吗？
高层达成一致意见了吗?
有强有力的项目负责人及实施团队吗?
有反对项目的人员吗？
所有这些准备工作都非常重要。
案例中的益达公司初涉海外业务，但并不熟悉海外规则,也没有适应海外技能的人才，如无法用英文沟通等，如何推进项目？
而凯业公司在项目启动后，业务需求不清，公司高层支持力度不够，项目负责人古田二科是个没有组织和控制能力的人，周远对AHZ项目有很大的抵触情绪。
凯业项目组从一开始就对系统抱有一种漫不经心的态度。
凯业公司内部在业务接口的定义和部门业务划分上也是争吵不休.如此的项目组和业务现状,项目焉能不败！
最后是，项目实施后可能会有哪些风险，如何防范？
任何项目都是有风险的，只是风险大小而已.软件公司在项目前就要预测风险并要有风险预警系统，当风险达到何种程度时,就要快速果断决策。
客户公司也要预测启动新项目的风险,不要老系统放弃了，而新系统又上不了,最后是"竹篮打水--一场空”。
上一个信息化项目，也是一场变革，在变革前，必须对利益相关者作一个全面分析,并有一个风险防范措施的全面部署。
案例中的益达和凯业公司在项目前都是非常乐观的，没有分析和预见到各种风险.益达公司的项目开发流程就是一个风险点,如前期SOW中的定义不明。
按照软件项目完工百分比计算收入也是风险点.对于凯业公司来说,周远就是一个风险点，古田二科也是一
升级会员 