因此，在技术工具的选择上不能一味求新，在系统架构的设计上不能一味求全，要尽量避免“银弹”的攻击。SP项目在技术架构的选择上就吃了亏。
整体管控不力
SP项目的管理在实施阶段开始之后，慢慢变得失去了控制。变更越提越多，补丁越打越多，问题越改越多，业务人员开始失去信心，开发人员开始失去耐性，系统正式上线变得遥遥无期……原因何在？
1. 变更控制不力
由于业务负责人对流程整体情况的不了解和基层业务员对IT系统的不适应，致使很多当初出于管理目的提出的流程整合根本推行不下去，业务部门的负责人迫于无奈，只好提出需求变更；而项目组为了使系统能够顺利实施下去，也只好妥协，并为此付出很大代价。
事实上，项目组更多地应该从全局角度出发来考虑问题，面对汹涌而来的需求变更，我们应该冷静考虑：这个流程是否必要，是否一定要通过系统来实现，能否与其他流程合并处理，能为系统提供什么关键数据，是否为流程的关键控制点……通过回答这些问题，你会发现，那么复杂冗长的流程图原来可以这样简单！