對於這種需求天天變的客戶，你就一定要事先做好規矩：
一、統一聯繫人，客戶指定一個人和項目組進行溝通，不能張領導、王領導都來說幾句，如果他們意見不一致，那你只有得罪領導的選擇了，所以，項目的最初就要定好規矩，我項目組只認一個的意見，有什麼要求你們內部先統一再和我談，我不想捲入你們內部業務部門之間的矛盾之中；
二、所有需求變更全部要有書面文字，這點切記！這樣做好處多多：
*有書面證據，以後他還想改，你有了他以前要求的證據，告訴他：你以前可是這么說的；
*便於需求變更管理，需求如何慢慢演變的歷史可以看清楚，從而更深切地體會客戶的目的；
*對於客戶來說，嘴巴一動最方便，反正是你們做，不花他的資源，所以要求是否合理，是否和項目的目的一致，他是不負責任的。但是如果要他寫書面要求，還要簽字蓋章，他就要謹慎多了，而且一寫東西，思想就會更加深入，很多無理要求也就這樣胎死腹中了；
系統開發告一段落後，就進入客戶培訓、系統驗收階段，這個階段，我一般會注意以下幾個問題：
給客戶做培訓前，多注意一些表面功夫。很多程式設計師認為，既然很多系統採用原型法，有一個由粗到精的過程，那么系統的邏輯核心是否正確才是關鍵，至於界面如何，界面上的用詞是否準確，那是無關緊要的問題；而且培訓的時候也是空手上台、信手拈來，想到哪裡說到哪裡，下面聽講的人不知所云，雲山霧罩，培訓效果自然可以想像。我的體會是，給客戶做培訓的版本，如果你在做多次測試以後仍然不能確定邏輯是否合乎要求，那么，你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、連結的正確性等等，總之不要讓客戶看到一些他不該看到的東西，否則，僅僅因為一些無關緊要的報錯就讓客戶第一印象覺得系統不穩定，那你就真的比竇娥還冤了。如果工作再做得詳細一點，可以做一些類似flash的東西，把一些你要強調的重點用通俗易懂、輕鬆愉快的方式表達出來。文檔方面，準備至少兩個文檔：用戶手冊和培訓手冊。這兩個文檔的內容很多都是一致的，但是角度完全不同。用戶手冊往往是站在系統設計者的角度，按照自己的思路，分模組講解系統的操作和功能；而培訓手冊，一定要站在客戶業務人員的角度，根據每個角色面對不同業務的辦理，如何通過使用本系統的一系列功能來實現目標。所以，第一次培訓以前，系統界面是否完整正確、培訓文檔是否完備、培訓時所舉的例子是否有代表性都是很關鍵的因素，第一炮打不響，以後就麻煩很多。
上面講的是培訓的時候，醜媳婦要化妝好再去見公婆的問題。其實，項目實施中還有一個考驗項目經理功力的就是如何調動客戶積極性的問題。一般來說，客戶是懶的，這就是他花錢找你做事情的原因。一個項目的成敗，和客戶的配合程度很有關係。根據我的分析，一般項目中的客戶都可以分為三類：支持的、消極觀望的、牴觸的。他們人數的分布一般是一個紡錘形：支持的和牴觸的人少，觀望的人多（如果你接了一個人人都牴觸你的項目，那你還是不要做了）。首先，分析一下那些人為什麼支持你和牴觸你。很簡單，於公於私兩個方面分析，上了新系統，誰的工作量有所變化？誰的潛在利益是否受到威脅？誰的崗位是不是因為新系統而消失？傳統的利益格局因為新系統的使用而發生怎么樣的變化，這些東西，都是項目經理必須去了解的，這樣，你才能團結那些支持你的人，消減那些牴觸你的人。項目經理是一個很奇怪的角色，屬於典型的責任大、權力小的角色，他能做的只有借力打力，不管在自己公司還是在客戶那裡，一定要依靠別人才能完成自己的目的。只有了解哪些人會因為什麼而幫助你，哪些人會因為什麼而牴觸你，你才能讓客戶配合你做工作。比如上一些內部計算機輔助管理系統，其必然後果就是讓本來管理混亂時有人可以渾水摸魚的一些利益消失掉了，這樣，有些人肯定就要搗亂，到處詆毀這個系統。這時候，你就可以散布一些"誰抵制新系統就說明自己屁股上有屎"這類的論調去壓制他們，減弱他們的影響。總之，團結積極分子，打壓敵對分子，帶動大多數是你的基本策略。