SP项目所涉及的业务一直以来都是很令人头疼的：业务流程复杂、业务人员众多、分工细而且杂，业务流程的各个环节散落在众多的业务人员当中，没有谁能说清楚整个流程的走向。

    在项目立项之前，刚刚成立了一个新的部门来专门管理这块业务，所有流程都在重新整合，正是在流程的梳理和整合过程中，他们逐渐产生了对IT系统的强烈需求。

    2. 业务人员没有IT系统使用经验

    无论是新部门的管理者还是具体*作的业务员，都没有类似的IT系统使用经验，对IT系统可能给工作带来的变化感到惶恐和茫然，面对需求调研人员的问题显得不知所措。

    因此，从项目选择开始，我们就已经把自己放在了一个十分不利的位置上，项目范围模糊，变更频繁，需求蔓延，成为日后令我们焦头烂额的罪魁。而在后来的开发过程中，我们对业务流程规范的缺乏关注和控制不力，也从另一方面助长了这些不利因素对项目的影响，使得需求一变再变，进度一拖再拖。

    既选公司也选人

    SP项目中的外包公司在业内的口碑很好，外包工程师的工作非常努力，但是因为项目经验较少，尤其缺乏制造企业信息化项目的经验，面对用户提出的关于流程设置、界面布局、错误提示等各方面的需求显得无所适从，甚至无法理解为什么用户会对一个输入框的摆放位置有那么多的意见。这使得开发人员与用户的想法存在差异，造成了很多额外的返工。

    因此，在外包项目的招标过程中，除了应该注意外包公司是否具有相关领域的外包经验，还要特别注意对方是否能够在项目进行过程中提供最合适的人选，因为真正提供服务的是具体的开发工程师而非外包公司，无论公司的实力多强大，如果不能提供最合适的人选，一样不能保证项目的顺利进行。

    框架选取—“吃螃蟹”

    SP项目采用了微软的最新架构体系，该架构体系在此之前还没有类似项目的成功应用案例，我们因此成了吃螃蟹的人。

    事实证明，螃蟹并不是那么容易吃的，还要自己的肠胃能够消化才行。因为是全新的架构，所以也谈不上什么经验，一切都要从头开始。外包工程师进场后的一个多月的时间都花在了熟悉新架构和新技术上，开发进展缓慢。而且，新的架构为了实现多系统整合、客户端自动更新、权限统一管理等目标，使得开发和调试变得复杂而且困难，代码可读性变差，在一定程度上也影响了开发的进度，并且给后来的维护工作埋下了隐患。

下一篇：项目在后续过程很被动外包项目失败在哪?(3)