問：實施時候，需求也是拖延我們實施很多時間的重要因素之一。客戶遲遲不上線，不上線我們就無法驗收。那我們該怎麼辦呢？
答：首先，你們要有一些策略的調整。你們是以什麼爲驗收標準。以客戶上線爲驗收標準是不科學的，因爲什麼算上線定論不一。我們推薦做一件事情驗收一塊。
如安裝配置完了。驗收一塊。基礎數據完成了，驗收一塊。每次培訓後，驗收一塊。每次考試後多少人上崗了，驗收一塊。上崗多少人，多少天算實施結束，不同的時間有不同的費用，所以我們就不用擔心客戶拖延我們的時間，其實他是在消耗在他的錢，所以他肯定着急。否則就是你急他不急。
對於需求，我們不限制客戶提需求。因爲需求真是公說公有理，婆說婆有理。很多客戶對於過去的操作習慣而不接受現有操作方式，需要改回去。既然又回到了過去，那麼我們上新的系統又有何意義？但這樣講不能解決問題。
正確的解決方法是：
1首先和客戶領導（不是CIO）在實施前就說清楚。上線使用肯定會遇到用戶想把功能改回去的現象。首先取得客戶領導的支持。這樣在用戶反對抱怨的時候還能繼續開展下去。
2提需求，不能計算機室提需求。我們以爲計算機室應該是業務和技術結合的，應該能提出適合他們本公司需要的需求。但我們在以往的項目中發現，不是這樣，改完了計算機室提出的需求後，一上線發現還得改。計算機室人員畢竟不是天天實際操作真正的用戶，操作功能的角度當然不一樣。所以，要提需求，必須真正操作軟件的用戶。誰操作哪塊誰提哪塊的需求
3而且沒使用的時候，不能提需求。你用都沒有用，你什麼都不瞭解你就提需求？而且這樣的需求往往是不成熟的，到應用得心應手的時候發現還得改。企業信息化總是從淺入深的，所以需要功能的細節層次也是每個時間階段不一樣的。
4提需求不能見一個提一個，隨時隨地提。提需求必須以1周或2周或1個月爲一個需求週期。因爲，這樣的週期便於客戶使用深入，有時客戶使用熟悉後就覺得需求不必要了，而且這個週期給我們安排修改任務也有好的安排時間。
5提需求，要寫上需求的模塊，提需求的部門和人和人的職位，提需求的時間，需求的內容。然後把需求內容做成DOC標準格式文件，首先送給計算機室人審覈。因爲最終用戶提的需求站的高度僅限於自己需要，所以計算機室人員有一個綜合的衡量。每個需求計算機室人員要寫上需要的限制時間，如在1個星期內必須改好或必須在2天內改好。不同的修改週期要求會打亂開發部的任務安排，所以需要費用的補償，而且開發有工作量，當然也需要費用。所以不同修改天數限制有不同的開發費用。一提到錢，客戶就必須自己思考一下了。否則，需求任意提，雙方沒有相互約束的條件了。