在选型的时候，吴源比较倾向于找一个本地的供应商，他感觉crm系统比较复杂，自己公司的信息化基础也不是很好，所以项目的实施和服务至关重要。供应商在本地，沟通起来比较方便，实施和服务就会相对容易一些，成本也好控制。

　　由于需求也不是很复杂，所以选型工作进行得比较迅速，经过几番沟通和比较，吴源对其中的一家公司比较认可，这家公司在本地做过几个类似的项目，费用也比较合理，于是吴源很快就确定了这个公司作为自己的实施方。

　　接下来就是签合同、付款，对方很快就安排了一名实施人员进厂实施，一切都比较顺利，但接下来的过程就让吴源越来越痛苦了，因为，他也遇到了让所有人都非常头疼的需求变更问题。

　　需求的不断变更导致项目断断续续，持续不能完工，其中的纠纷也越来越多，公司内部、公司和供应商之间的争议越来越多。而吴源显然是这一切争议的中心，他要不断的沟通、协调，平衡两边人员做出让步。

　　由于原来的合同并没有对很多细节做出明确描述，所以这些细节怎么做就成了大家争议的焦点。编码的内容和规则，表单的数量和格式，数据流转和统计方式，一些小功能的添加和修改……所有这些都需要多方人员在现场讨论确定，甚至要反复沟通多日才能达成一致，这不但严重的影响了项目进度，也大大降低了公司人员对项目的认可度和配合度。

　　正所谓“一鼓作气，再而衰，三而竭”，公司领导和供应商都不希望拖得太久，双方都在给吴源压力。

　　公司这边希望系统尽快实施完毕，早日发挥作用，而且认为这些改动都是在需求范围内的，都是合理的，供应商理应配合做好，如果供应商配合不好，则是吴源缺乏力度。

　　厂家也希望尽快结案，好早日拿到工程款，他们拿出一张又一张的需求变更单，要吴源以及公司老总亲自签字，而且稍微跟合同内容不一致，就要吴源追加费用，这让吴源非常痛苦。因为他一方面要为需求变更不断的增加费用，一方面又要为项目不断延期承担责任。

　　吴源知道，很多需求变更是无法说清在计划内的，还计划外的，是应该做的，还是不应该做的。做吧，费用增加、工程延期;不做吧，软件用不好，各部门不满意。

　　吴源想，都说厂家最害怕用户需求变更，其实作为用户的项目主管，自己又何尝不怕需求变更呢?

　　到了09年10月份，吴源汇总了一下项目情况，工程完工了84%，已经延期3个月，费用超预算18%。项目还是马上就要完工了，但吴源知道，越到快完工的时候，小问题会越多，麻烦事会越多，双方的争议会越大，他非常担心在最终试运行的时候出现大的问题，出现双方无法协调的局面。也担心在系统上线后，再出现一些杂七杂八的需求怎么办，自己应该如何协调好公司和供应商之间的合作，有效的解决不断出现的新需求。