项目管理案例
（三）开发中的人员更替： 在初步估算出需要几百个工作日的开发量后，李先生深知开发任务的艰巨，于 是从公司将高级技术顾问刘先生以及另外两个技术顾问调入项目组，而在此时， 飞扬公司的几名开发人员也才刚刚从其他系统脱身介入ERP开发。按照李先生 所拟定的实施计划安排，留给刘先生的开发时间是不多的，刘先生经过几天的 分析，拟定出一个开发计划，没想到刚提交给李先生就遭到否决：“不行，开 发的日期必须缩短！否则项目怎么按时上线啊？”。但是刘先生也有他的苦衷， 因为他比谁都明白自己所面临的难处：如此巨大的开发量以及紧张的开发时间 安排；同时，他还要负责进行培训，对飞扬公司的几名开发人员进行知识转移， 以及其它技术顾问的开发跟进。 在修改了开发计划后，刘先生投入了紧张的设计、开发过程中，并将一些简单 的开发交给了飞扬公司的开发人员。然而，飞扬公司的开发人员以前都未接触 该ERP软件的开发，同时还需要维护公司其他系统，人也三心二意，因此起步 格外吃力，经常向刘先生请教开发的问题。这些问题在刘先生看来，不但简单 而且如果有心的话应该很容易上手，因此不胜其烦，加上开发的困扰，对请教 问题逐渐变得不耐烦，甚至有一次对飞扬公司的开发人员吼到：“这么简单的 问题都不会，你们真是猪脑袋！”，双方开发人员关系开始紧张起来。
项目管理案例
项目开发不慎，ERP上线搁浅 （一）好开头未必好兆头： 经过几个月的反复比较、挑选、论证，飞扬公司决定实施国外的一家大 型软件公司提供的ERP管理软件；实施方是国内相当有实力的高成咨询 公司。作为这家大型机械设备制造企业的CIO，陈先生终于可以松一口 气了：领导的大力支持，同行业相对便宜的价格，国外著名ERP软件， 实力强劲的实施公司，以及企业员工的计算机水平相对较高，所有这些 看起来，对ERP的实施应该算是开了个好头。 很快，高成公司根据合同派来了以资深顾问李先生为首的项目实施小组， 项目开始实施。为了配合项目实施，飞扬公司也成立了ERP项目小组， 除了IT部原有的实施人员外，还从业务部门抽调了熟悉财务、分销、制 造的几名业务人员。双方的项目人员配合得相对还算不错，调研，需求 分析，关键用户培训，一步一步按照项目计划在进行中。看到这么顺利 的进展，陈先生不禁喜上心头，跟项目小组放言：年底前争取上线。

项目管理案例
（四）项目开发彻底瘫痪： 面对如此尴尬的局面，陈先生不得已将IT部所有的开发力量都集中于 ERP项目，并要求开发人员加班加点，指望能够扭转颓势。但是，IT部 的一些开发人员变得非常不满，本来开发待遇就低，做相同的工作拿的 却比研发部门少得多，现在又要加班，也没有什么激励措施，干多干少 一个样，于是有的人开始消极怠工，一张报表做个十天八天，稍有难度 的开发就推给顾问。不久，高成公司的顾问逐步撤出项目，双方开始了 邮件打仗，你推给我、我推给你，一个问题解决需要很长时间。 随着时间的推移，飞扬公司的开发人员逐步变得熟练起来，开发出的程 序也慢慢变得完善了。但没过多久，随着业务部门对系统的熟悉，一些 新的需求被提了出来，面对这些需求，除了继续开发还能有什么办法吗？ IT部的一些开发人员变得更加不满，由于开发后总是需要改来改去，所 以感觉工作没什么意义，有的人开始考虑跳槽，提出了辞职；而在这个 节骨眼上提出辞职，陈先生当然不会批准，于是只能拖延，因此整个项 目开发再次陷入了停顿。

项目管理案例
事情发展下去越来越糟，飞扬公司将刘先生告到了高成公司上层，李先生不得 不警告了刘先生，要求他必须保持耐心。不久，鉴于刘先生在项目中被客户投 诉，高成公司在例行的加薪中没有给刘先生加薪，这些令刘先生怒不可遏，本 来开发就挺累的，累了还不值，公司没有重视他的价值，于是萌生了跳槽的想 法。在后来的开发中，他没有像开始那么积极和负责了，整个项目的开发开始 陷入了不正常中。 项目就在双方开发人员的三心二意中继续，本来确定的上线日期却因为开发的 未完成和项目方案的反复调整而一拖再拖。眼看如果再不上线，整个项目将严 重滞后，李先生不得不强行上线，留下一堆尚未开发完善的程序等待测试。此 时，刘先生收到了一家猎头公司发来的邀请，于是向公司提出辞职，尽管公司 竭力劝阻和利诱，但去意已定的刘先生没有动心，而是坚决辞职。高成公司不 得不从其它项目抽调技术人员来接手刘先生的活儿。项目上线后，在业务部门 的使用过程中，相关的开发程序逐渐暴露出了问题，不是今天这个报表运行出 错，就是明天那个功能计算有误，整个项目小组陷入救火当中，尽管开发人员 对前期由刘先生开发的程序进行了修修补补，但问题还是层出不穷，陈先生不 时接到业务部门的抱怨和不满，整个企业弥漫了对ERP失败的看法，原来美好）系统开发前的针锋相对： 不久，项目进行到方案设计阶段。公司老总在ERP实施前就为实施定了调：现有的业务流 程不能大改，只能逐步优化。飞扬公司业务相对复杂，有待改进和规范的业务流程不少， 估计开发量将会不小，因此顾问在同业务部门讨论解决方案前采取了如下应对策略：培训 客户尽快熟悉系统功能，劝说客户采用系统已有的相似功能，减少一些无谓的开发，系统 没有的功能则考虑开发。 当项目小组同业务部门开始就方案进行讨论时，许多业务部门提出了开发需求。李先生极 力反对对系统做大量开发，他认为该软件是在数万家企业使用的，其管理思想是非常先进 和合理的，而且大量开发不但会有开发的风险，延长了实施周期，还会对系统升级带来诸 多不便。而业务部门坚持开发的理由是：1、企业现有的流程支持公司快速发展，目前使 用的流程是经过实践检验了的，只是需要更进一步的完善；2、ERP的流程或许先进，但 不可能因为实施ERP而大改，太大的调整将导致上下衔接不顺，就连正常的运转都难以维 系，上ERP就是找死。处在中间的陈先生犯难了：开发吧，时间长、风险大；不开发吧， 业务部门的需求在老总看来是理所当然的，而且如果现在开发，那么以后就可以不开发了， 陈先生在权衡后选择了开发。就这样，实施小组和业务部门讨论、协商、争论了个把月， 一大堆的开发摆在李先生面前。令李先生为难的是，如果拒绝，实施方案没有业务部门的 签字，飞扬公司将拒付实施费。在开发和项目停顿的两难中，李先生无奈的选择了前者。 在承诺给予开发后，业务部门才陆续在实施方案上签字确认。