问：实施时候，需求也是拖延我们实施很多时间的重要因素之一。客户迟迟不上线，不上线我们就无法验收。那我们该怎么办呢？
答：首先，你们要有一些策略的调整。你们是以什么为验收标准。以客户上线为验收标准是不科学的，因为什么算上线定论不一。我们推荐做一件事情验收一块。
如安装配置完了。验收一块。基础数据完成了，验收一块。每次培训后，验收一块。每次考试后多少人上岗了，验收一块。上岗多少人，多少天算实施结束，不同的时间有不同的费用，所以我们就不用担心客户拖延我们的时间，其实他是在消耗在他的钱，所以他肯定着急。否则就是你急他不急。
对于需求，我们不限制客户提需求。因为需求真是公说公有理，婆说婆有理。很多客户对于过去的操作习惯而不接受现有操作方式，需要改回去。既然又回到了过去，那么我们上新的系统又有何意义？但这样讲不能解决问题。
正确的解决方法是：
1首先和客户领导（不是CIO）在实施前就说清楚。上线使用肯定会遇到用户想把功能改回去的现象。首先取得客户领导的支持。这样在用户反对抱怨的时候还能继续开展下去。
2提需求，不能计算机室提需求。我们以为计算机室应该是业务和技术结合的，应该能提出适合他们本公司需要的需求。但我们在以往的项目中发现，不是这样，改完了计算机室提出的需求后，一上线发现还得改。计算机室人员毕竟不是天天实际操作真正的用户，操作功能的角度当然不一样。所以，要提需求，必须真正操作软件的用户。谁操作哪块谁提哪块的需求
3而且没使用的时候，不能提需求。你用都没有用，你什么都不了解你就提需求？而且这样的需求往往是不成熟的，到应用得心应手的时候发现还得改。企业信息化总是从浅入深的，所以需要功能的细节层次也是每个时间阶段不一样的。
4提需求不能见一个提一个，随时随地提。提需求必须以1周或2周或1个月为一个需求周期。因为，这样的周期便于客户使用深入，有时客户使用熟悉后就觉得需求不必要了，而且这个周期给我们安排修改任务也有好的安排时间。
5提需求，要写上需求的模块，提需求的部门和人和人的职位，提需求的时间，需求的内容。然后把需求内容做成DOC标准格式文件，首先送给计算机室人审核。因为最终用户提的需求站的高度仅限于自己需要，所以计算机室人员有一个综合的衡量。每个需求计算机室人员要写上需要的限制时间，如在1个星期内必须改好或必须在2天内改好。不同的修改周期要求会打乱开发部的任务安排，所以需要费用的补偿，而且开发有工作量，当然也需要费用。所以不同修改天数限制有不同的开发费用。一提到钱，客户就必须自己思考一下了。否则，需求任意提，双方没有相互约束的条件了。