簡介
變更控制的目的並不是控制變更的發生，而是對變更進行管理，確保變更有序進行。對於軟體開發項目來說，發生變更的環節比較多，因此變更控制顯得格外重要。IT項目中引起變更的因素有兩個：一是來自外部的變更要求，如客戶要求修改工作範圍和需求等;二是開發過程內部的變更要求，如為解決測試中發現的一些錯誤而修改源碼甚至設計。比較而言，最難處理的是來自外部的需求變更，因為IT項目需求變更的機率大，引發的工作量也大(特別是到項目的後期)。
變更控制不能僅在過程中靠流程控制，有效的方法是在事前明確定義。事前控制的一種方法是在項目開始前明確定義，否則“變化”也無從談起。工作範圍(以前章節談過);另一種方法是評審，特別是對需求進行評審，這往往是項目成敗的關鍵。需求評審的目的不僅是“確認”，更重要的是找出不正確的地方並進行修改，使其儘量接近“真實”需求。另外，需求通過正式評審後應作為重要基線，從此之後即開始對需求變更進行控制。
雖然可以事前定義好變更控制流程，但在各種壓力下真正“控制”起來其實非常困難。
內容分類
項目變更控制審查表1）項目變更控制的基本要求：
關於變更的協定；
謹慎對待變更請求；
制定變更計畫；
變更的實施: 明確界定項目變更的目標優、選變更方案、做好變更記錄及時發布變更信息
2）項目整體變更控制框架
項目整體變更的輸入： 項目計畫、項目執行報告、變更申請；
項目整體變更控制的工具和技術：項目整體變更控制系統、配置管理、績效測量、補充計畫編制、項目管理信息系統；
3）項目整體變更控制的輸出：項目計畫更新、糾正措施、經驗教訓。
2、項目輔助變更控制：範圍變更控制、進度變更控制、費用變更控制、質量變更控制、風險變更控制。
原則
為了對項目的變更進行有效地控制，成功地完成項目的目標，項目變更應遵循以下原則：把項目變更融入項目的計畫中去；
選擇影響最小的方案；
所有的變更在準備變更申請和評估之前，必須與項目經理進行商討；
及時地發布項目的變更信息。
控制程式
項目變更是正常的、不可避免的。變更控制程式如下：明確項目變更的目標；
對提出的所有變更要求進行審查；
分析項目變更對項目績效所造成的影響；
明確產出相同的各替代方案的變化；
接受或否定變更要求；
對項目變更的原因進行說明，對所選擇的變更方案給予解釋；
與所有相關團體就變更進行交流；
確保變更合理實施。
三方變更
項目變更控制這是要處理的最為重要的變更。範圍在兩個層次上得以定義——高級範圍描述項目的邊界和需要完成的主要可交付項。低級範圍則通過你認可的需求加以定義。
範圍變更管理的主要目的是確定變更，並對其進行有效管理。它還有助於保護項目團隊，避免就時間進度和預算達成一致後出現變更。
換句話說，項目團隊根據高級和詳細的範圍定義承諾一個最終期限和預算。如果在項目進行過程中可交付項發生變化（這一般意味著客戶希望附加額外的條款），最初的成本、努力和持續時間估計就會失效。
如果主辦方同意將新工作增加到項目範圍中，項目經理有權要求對當前的預算和最終期限進行修改（通常是增加預算，延長最終期限），以反映這些增加的額外工作。
這個過程最終要向主辦方提交適當的信息，允許主辦方根據商業價值和變更對項目成本和時間進度的影響，決定是否批准對預算和最終期限的修改。
配置變更
配置變更是指對所有項目資產和資產特性（元數據）進行確認、追蹤和管理。（在一些組織中，這個過程的定義更加狹窄，僅表示對物理資產進行管理。）大多數項目並不進行配置管理。不過，如果你的項目使用或建造大量的組件、零件、工具和設備等，配置變更管理就顯得非常重要。
所有其它變更
你的項目還可能發生一些變更，它們不屬於範圍變更管理或配置管理之列。這些變更可能劃歸為綜合變更管理的範疇。例如，假如一名團隊成員離職，需要有人來填補他的職位。
這個例子就不屬於範圍變更或配置變更，而屬於綜合變更。在這種情況下，你可能需要記錄所發生的資源變更情況、確定變更的影響、並制定一個變更管理計畫。在多數情況下，上述過程和範圍變更所要求完成的過程類似。
綜合變更管理和範圍變更管理的關鍵區別在於，如果一項範圍變更被要求並得到批准，你希望能夠對預算和時間進度加以修改，以適應變更的要求。你不應對它抱著和非範圍變更相同的期待。
例如，在上面的例子中，一個團隊成員的職位需要填補，這無疑是一項變更，也可能會對項目造成影響。但是，你不能指望這項變更會改變已得到批准的項目時間進度和預算。
作為一名項目經理，你應當集中精力確保對範圍變更進行有效管理，因為它是造成項目問題的主要罪魁禍首。不過，你還要認識到，你的項目也可能需要進行配置管理和綜合變更管理。有效管理這些變更可以為你免去許多麻煩。
誤區
(1) 沒有明確的授權。事先應該明確客戶方有權提出變更申請的人員和實施方有權受理變更的人員，並要控制雙方人數。這樣做才可以對變更有整體的控制。絕不能進行“私下交易”，而沒有人能完整地知道到底改了些什麼。另外，授權雙方接口人的好處是可以禁止客戶內部的矛盾，如果只有一個接口人，內部尚未達成一致時變更是無法提出來的。從實際經驗看，授權可以顯著減少變更，特別是那些因內部看法不同而導致的反覆變更。(2) 對變更沒有進行必要的審核。並不是所有的變更都要修改，也不是所有變更都要立刻修改，審核的目的就是為了決定是否需要修改和什麼時候修改。比如案例中提到的界面風格問題，就可以先不修改，或者規劃一下修改的時間待到以後進行最佳化。另外，對於核心模組的修改要嚴格審核把關，否則會引起全局問題，案例中提到的“擅自修改核心模組”造成的事故就是因為沒有審核而造成的。
(3) 對變更的影響沒有評估。變更都是有代價的，應該評估一下變更的代價和對項目的影響，要讓客戶了解變更的後果，並與客戶一起做判斷。案例中客戶最後的質問正是因為沒有事前告訴客戶變更的影響造成的。如果客戶不知道你為變更付出的代價，對你的辛苦便難以體會。
(4) 應該讓客戶確認是否接受變更的代價。在評估代價並且與客戶討論的過程中，可以請客戶一起做判斷：“我可以修改，但您能接受後果嗎?”。案例中如果王先生評估了修改界面的工作量並請客戶確認，則有三種可能：客戶預先接受延期這一後果，也就不會再質問王先生了；如果客戶認為代價太大，則王先生就不必修改了；如果認為可以縮短延期時間。
