3.1 誰(shuí)有權確認變更

　　事先明確客戶(hù)方有權提出變更請求的人員和項目組有權受理變更的人員，并且變更請求必須有書(shū)面材料。用戶(hù)需要向客戶(hù)方項目負責人提出書(shū)面申請，由客戶(hù)方項目負責人審批后移交實(shí)施方項目經(jīng)理。

　　這樣，對所有的變更雙方的項目負責人都能做到心里有數。而且用戶(hù)在遞交書(shū)面變更申請時(shí)比較慎重，一般都在自己公司內部經(jīng)過(guò)討論后進(jìn)行，減少了因用戶(hù)內部看法不同導致的反復變更。

　　3.2 什么樣的變更需要執行

　　不是所有的變更都需要修改，更不是所有的變更都需要立刻修改。必須對客戶(hù)提出的范圍變更進(jìn)行審核，決定哪些變更需要修改和何時(shí)修改。

　　客戶(hù)一般對信息系統集成項目不甚了解，他們認為很簡(jiǎn)單的事情可能解決起來(lái)會(huì )很復雜。因此項目經(jīng)理和項目小組要冷靜地分析：用戶(hù)到底想要實(shí)現什么目的，抓住本質(zhì)的需求。如果用戶(hù)建議很難實(shí)現，可以和用戶(hù)進(jìn)行溝通，詢(xún)問(wèn)用戶(hù)是否可以用其他方式來(lái)實(shí)現其目的。

　　一般來(lái)說(shuō)，用戶(hù)的鍍金需求可以延期解決甚至不考慮，用戶(hù)的新增需求如果不是影響到核心業(yè)務(wù)的實(shí)現，也可以安排在現有功能的完善之后。

　　3.3 變更的影響多大

　　項目組成員都要認識到變更是有代價(jià)的。必須評估變更的代價(jià)和對項目的影響，并且要讓客戶(hù)了解到變更可能會(huì )發(fā)生的問(wèn)題，一起判斷變更是否依然要進(jìn)行。

　　3.4 客戶(hù)是否接受變更的代價(jià)

　　在與客戶(hù)討論過(guò)程中，需要和客戶(hù)一起判斷：“修改是沒(méi)有問(wèn)題的，但是你能接受由此引起的進(jìn)度延遲、費用增加、性能下降等嗎·”一般來(lái)說(shuō)，如果客戶(hù)認為該變更是必須的（變更非常有可能是其上級領(lǐng)導提出的），就會(huì )接受這些后果，通過(guò)與客戶(hù)的協(xié)商，項目組可能會(huì )得到回報或者即使沒(méi)有回報也不會(huì )招致公司和客戶(hù)雙方的埋怨。如果客戶(hù)認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶(hù)認為該變更可有可無(wú)，多數情況下會(huì )取消變更。

　　這時(shí)，比較穩妥的做法是讓客戶(hù)對于明顯的變更做出確認，一般是簽字確認。這樣既可防止頻繁變更，也讓客戶(hù)認識到變更帶來(lái)的工作量加大是項目延期的原因。

　　最后，變更進(jìn)行時(shí)必須保證最終方案的唯一性和完整性。同時(shí)，要對所有變更進(jìn)行跟蹤和驗證，確保變更按要求完成。范圍管理對信息系統集成項目成敗有重要影響，執行好范圍管理最重要的是建立行之有效的變更控制手段。