4、對待需求變更的技巧
對用戶提出的需求來說，首先項目經理要考慮變更的合理性。不合理的需求要找到推掉的理由，避免直接拒絕。比如，如果一個用戶提出的變更和系統的目標不一致的話，讓用戶自己推倒自己需求。好處是即給了用戶面子，客戶關系也能得到提高。同時避免產生了工作量。
絆字訣：先把他的招接過來，之后他腳下出一招，讓他用自己的沖力把自己摔倒。
封字訣：在我們的系統是不能實現這種功能的”。之所以用這么肯定的語氣是要斷了他要實現這種功能的念頭。封字訣是直接回絕他，清楚的告知這招是行不通的。
拖字訣：對于比較合情合理的需求，但又不是現在要解決的問題.要想辦法往后拖，不至于打亂當前的計劃。
對于客戶內部斗爭，千萬不要正面參與。有些人可能會直接拿系統做替罪羊，這個時候需要找到更上一級的領導來出面協調。借助客戶的力量來擺平。目的推到二期來做。
5、編寫需求變更申請表
編 寫要盡量詳細，并經過客戶、高層經理和項目組內部人員的認可。比如測試人員對測試的工作量要參與評估，開發人員對開發工作量要進行評估。數據來源基于基 層，確保數據的準確性。同時補充一點變更帶來的質控工作量也應該納入到變更需求表中，比如可能設計項目總結和數據統計的工作量。
客戶提交的問題要做好詳細的記錄，保證有據可查，對問題要進行面對面的確認，避免含糊其詞的用戶需求。對確認結果進行記錄。
6、變更控制流程轉
(1)、內部項目：用戶提出需求-》項目組對問題進行分析(不明確的問題要進行確認，區分問題的優先級和解決方案)-》提交變更申請表(包含估計和計劃)-》高層領導決策-》審批通過-》依照項目計劃執行。
2)、 外部項目：用戶提出需求-》項目組對問題進行分析(過濾需求是否合理、是否在本版本來做、能否放到二期、需求的必要性等)-》與客戶討價還價(把不合理的 需求、不必要在本期實現的功能推掉)-》必須要實現的需求-》提交需求變更申請(初步的計劃和解決方案)-》高層領導決策-》詳細分析需求和解決方案-》 評估工作量-》設定計劃-》客戶簽字確認-》依照項目計劃執行
以上兩者的區別在于：內部項目一般需求的控制權在高層領導中，有時候不一定關注成本，偏重于系統產生的價值，對用戶而且主要關注實用和易用性上。項目經理或團隊主要側重分析用戶需求的合理性。
外部項目首先應該考慮是公司投入的成本和獲取的收益，比如變更會給公司增加合同額或后期市場拓展的機會和對產皮的提煉(有的項目是項目型的產品)。如果上述條件不滿足，則首要考慮的是如何推掉需求。
