A 开发人员流失，项目陷入困境
在初步估算开发量后，客户深知开发任务的艰巨，于是要求库存管理系统厂商提供高级技术顾问调入二次开发项目组作技术指导和支持。在制定二次开发计划后，库存管理系统厂商开发技术顾问也投入了紧张的设计、开发过程中，并开始指导客户开发人员先进行一些简单的开发。
项目就在开发人员的三心二意中继续，本来确定的上线日期也因为二次开发的未完成和项目方案的反复调整而一拖在拖。眼看再不上线，整个项目将严重滞后，客户不得不强行上线，留下一堆尚未开发完善的程序等待测试。项目上线后，业务部门在使用中，相关的开发程序逐渐暴露出了问题，不是今天这个报表运行出错，就是明天那个功能计算有误，整个项目实施组陷入救火当中，尽管开发人员对前期的开发程序进行了修修补补，但问题还是层出不穷，不时接到业务部门的抱怨和不满，整个企业迷漫了对库存管理系统失败的看法，原来美好的愿望在现实中被击的粉碎。
然而，客户公司的开发人员以前都未接触库存管理系统的开发，同时还需要维护公司其他系统，人员也三心二意。因此，起步格外吃力。而且事情发展下去越来越糟，由于客户开发人员在库存管理系统项目中多次被投诉进度慢，客户公司在例行的加薪中没有给开发人员加薪，这些令他们怒不可遏，本来开发就挺累的，累了还不值，公司没有重视他们的价值。在后来的开发中，他们没有象开始那么积极和负责了，整个项目的开发开始陷入不正常之中。
B 大量无节制开发，系统完全变味
客户老总在库存管理系统实施前就为实施定了调：现有的业务流程不能大改，只能逐步优化。为此，针对客户的业务流程个性化需求，我估计开发量会不少。因此，作为实施顾问的我在与业务部门讨论解决方案前采取了如下应对策略：先培训客户尽快熟悉库存管理系统功能，劝说客户采用系统已有的相似功能，减少一些无谓的开发，系统没有的功能才考虑是否要开发。
然而，大量对某些不规范的个性化业务流程进行二次开发后结果是：项目延期；开发的程序不稳定，容易出错。用了一段时间后，发现还不能满足业务流程的需要，于是客户再做修改。实际上，这样二次开发就可能存在两大问题，第一是由于二次开发过多，系统变得越来越复杂，与最初期望的效果越来越远，最后猛然一看，系统已经完全“变味”了。第二，由于客户二次开发能力有限或者系统柔性度较差，造成客户在这方面的投入很大但产生的效益甚微，后者也正是客户在二次开发中陷入窘境的主要原因。
就这样，实施小组和业务部门讨论、协商、争论了个把月，结果是一大堆的二次开发需求摆在面前。让处在中间的我犯难了：开发吧，时间长、风险大；不开发吧，业务部门需求在客户老总看来是理所当然的。还有令我更为难的是，如果拒绝，实施方案没有业务部门的签字，客户将拒付实施费。在二次开发和项目停顿的两难中，我无奈的选择了前者，在同意二次开发后业务部门才陆续在实施方案上签字确认。
在与业务部门就方案讨论时，我的态度一直是极力反对对系统做大量开发，认为该软件是在数万家企业使用的，管理思想是非常先进和合理的，而且大量开发不但会有开发的风险，延长了实施周期，还会对系统升级带来诸多不便。但客户坚持开发的理由是：①现有的流程支持公司快速发展，目前使用的流程是经过实践检验了的，只是需要更进一步完善；②库存管理系统流程或许先进，但不可能因为实施库存管理系统而大改，太大的调整将导致上下衔接不顺，就连正常的运转都难以维系，上库存管理系统就是找死。
库存管理系统在实施的过程中总会遇到这样那样的问题，许多实施顾问都非常头痛的是二次开发。更不幸的是，因为客户领导一时意气用事造成过度二次开发，不但成本过高，而且越改越让项目难以实施，陷入进退两难的困境。