只有系统真正用起来了，才可能及时发现问题和解决问题，问题发现得越早越容易解决，造成的损失也越小。
图1 SP项目的主要失误之处
系统终于上线了，作为项目负责人的我暗暗松了一口气，可是却无论如何也高兴不起来。为什么？为什么项目结束了，我的心情却愈发沉重；为什么已经竭尽全力了，用户却依然抱怨不休；为什么系统上线了，我却不敢说这是一个成功的项目。
成功离我们到底有多远？
SP项目是一个外包项目，需求由我们（发包方）提供，系统设计和代码开发由外包公司（承包方）提供，项目采用近岸开发和按工时付费的方式进行。
SP项目历时8个月，进入实施阶段后修改过至少3个版本，其开发过程可算是一波三折，尽管最后有惊无险，却也暴露出许多问题，比如：对外包项目的选择、对外包公司的筛选、对技术框架的选取、对项目整体的管控等。
SP项目在许多方面都存在着不足和失误，在很多问题的处理上还有可改进之处，应该成为其他项目的前车之鉴；此外，我们为这个项目付出的代价和得到的回报，较之最初的设想相去甚远。这些都令我们不得不在项目结束之后，转回头来仔细总结和反思。
项目选择造成被动
外包项目不同于内部开发和产品购买，在项目的选择和范围的确定上有必须要注意的问题。SP项目在最初的立项过程中忽视了这个问题，选择了一个业务流程不稳定、业务人员没有IT系统使用经验的项目来做外包，使得项目在后续过程中非常被动。
1. 业务流程不稳定
SP项目所涉及的业务一直以来都是很令人头疼的：业务流程复杂、业务人员众多、分工细而且杂，业务流程的各个环节散落在众多的业务人员当中，没有谁能说清楚整个流程的走向。
在项目立项之前，刚刚成立了一个新的部门来专门管理这块业务，所有流程都在重新整合，正是在流程的梳理和整合过程中，他们逐渐产生了对IT系统的强烈需求。
2. 业务人员没有IT系统使用经验
无论是新部门的管理者还是具体操作的业务员，都没有类似的IT系统使用经验，对IT系统可能给工作带来的变化感到惶恐和茫然，面对需求调研人员的问题显得不知所措。
因此，从项目选择开始，我们就已经把自己放在了一个十分不利的位置上，项目范围模糊，变更频繁，需求蔓延，成为日后令我们焦头烂额的罪魁。而在后来的开发过程中，我们对业务流程规范的缺乏关注和控制不力，也从另一方面助长了这些不利因素对项目的影响，使得需求一变再变，进度一拖再拖。
既选公司也选人
SP项目中的外包公司在业内的口碑很好，外包工程师的工作非常努力，但是因为项目经验较少，尤其缺乏制造企业信息化项目的经验，面对用户提出的关于流程设置、界面布局、错误提示等各方面的需求显得无所适从，甚至无法理解为什么用户会对一个输入框的摆放位置有那么多的意见。这使得开发人员与用户的想法存在差异，造成了很多额外的返工。
因此，在外包项目的招标过程中，除了应该注意外包公司是否具有相关领域的外包经验，还要特别注意对方是否能够在项目进行过程中提供最合适的人选，因为真正提供服务的是具体的开发工程师而非外包公司，无论公司的实力多强大，如果不能提供最合适的人选，一样不能保证项目的顺利进行。
框架选取—“吃螃蟹”
SP项目采用了微软的最新架构体系，该架构体系在此之前还没有类似项目的成功应用案例，我们因此成了吃螃蟹的人。
事实证明，螃蟹并不是那么容易吃的，还要自己的肠胃能够消化才行。因为是全新的架构，所以也谈不上什么经验，一切都要从头开始。外包工程师进场后的一个多月的时间都花在了熟悉新架构和新技术上，开发进展缓慢。而且，新的架构为了实现多系统整合、客户端自动更新、权限统一管理等目标，使得开发和调试变得复杂而且困难，代码可读性变差，在一定程度上也影响了开发的进度，并且给后来的维护工作埋下了隐患。