抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費。
這個時候千萬不能手軟，這并作要刻意賺取客戶的錢財，而是不能讓客戶養(yǎng)成經(jīng)常變更的習慣，否則后患無窮。相對于需求來說，什么WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。
6、客觀面對需求變更
需求一定會變化，我們也不得不面對這種情況，那么用什么辦法改善這種現(xiàn)狀呢?下面我提幾點建議。
（1）、加強人員培訓
從客觀方面可以采取的措施來說，首先是加強對需求分析人員的培訓，盡可能增強軟件系統(tǒng)、行業(yè)的背景知識，提高與客戶的溝通能力，增強服務意識和責任感， 因為將要開發(fā)的系統(tǒng)直接建立在需求分析的基礎上;同時規(guī)范需求分析人員和客戶溝通的方式，以及規(guī)范需求說明的格式，如果可能的話，盡量采取用戶可以理解的圖例來對需求進行標準、規(guī)范的描述，保證雙方對需求達到共同的認識。
（2）、加強文檔管理
需求文檔是相當重要的，可是在做文檔時大家普遍流于形式，文檔也有，格式也正確，但沒有人關心文檔的真正內(nèi)容是否正確，格式是否真的合理，是否實用，很多情況下是在幾天時間里趕出來或補上去的。
結果往往是在需要文檔時，文檔找到了，完全符合格式的要求，可是在里面能找到的線索是有限的，結果還要花很長時間查找數(shù)據(jù)表結構、甚至查看數(shù)據(jù)表的內(nèi)容，詢問當時的開發(fā)人員，才分析到所要的關系。這種情況在設計文檔里也存在，所以不管是開發(fā)人員、還是項目管理人員都要注意文檔的有效性和有用性問題，甚至對文檔的格式進行一下合理性檢查。
?。?）、項目實施階段的變更控制
成功項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。項目經(jīng)理應該樹立一個理念—“需求變更是必然的、可控的、有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。
能力的提高往往不是從成功的經(jīng)驗中來，而是從失敗的教訓中來。許多項目經(jīng)理不注重經(jīng)驗教訓總結和積累， 即使在項目運作過程中碰得頭破血流，也只是抱怨運氣、環(huán)境和團隊配合不好，很少系統(tǒng)地分析總結，或者不知道如何分析總結，以至于同樣的問題反復出現(xiàn)。
事實上，項目總結工作應作為現(xiàn)有項目或?qū)眄椖砍掷m(xù)改進工作的一項重要內(nèi)容，同時也可以作為對項目合同、設計方案內(nèi)容與目標的確認和驗證。項目總結工作包括項目中事先識別的風險和沒有預料到而發(fā)生的變更等風險的應對措施的分析和總結，也包括項目中發(fā)生的變更和項目中發(fā)生問題的分析統(tǒng)計的總結。
需求變更既然不可避免，那么就必須有一套規(guī)范的處理流程。對于需求變更的處理流程應該分以下步驟:提出變更->變更評估->實施變更。圖1簡要地描述了一般需求變更的處理流程。
CMM提出“分配需求的變更被復審，并加入到軟件項目中來”，其關鍵是在需求發(fā)生變更時，沒有必要馬上把這些變更付諸于軟件開發(fā)工作之中。
實際上，堅持把需求變更付諸開發(fā)努力，企業(yè)就會形成一種混亂且不穩(wěn)定的氛圍，進而嚴重破壞項目的控制和管理。需求管理關鍵過程試圖通過把分配需求的變更囤積到可管理的組中，等到開發(fā)工作允許的時候再引入相應的方法，避免產(chǎn)生這種混亂的氛圍。結果，需求管理創(chuàng)建了一個隔絕開發(fā)工作與所有真實的、潛在無序的、來自于客戶的變更。
打破模糊的、曖昧的、沒有文檔化的需求是一種偉大的挑戰(zhàn)，但是制訂堅持遵守的